Firewalls are one of the symbols of security. If you say firewall, everyone knows you are talking about security. Although firewalls are indeed a good method to secure your network, you should be aware they can be a pain in the ass.
While disallowing certain traffic from an insecure network, it could be your rule is to restrictive and drops traffic you wanted to let in.To get an understanding of why traffic is dropped, i am first going to explain how a firewall works.
A firewall filters network traffic based on rules you define. When a package arrives at the firewall, the firewall inspects the packed to sort out what kind of packet arrived from the network.
Most firewalls can filter based on port numbers, source and destination ip or mac addresses.
Mac adress filtering on firewalls isn’t often used, although it is much safer to use ( an ip adress is easely changed, an mac adress less easy changed because it is burned in to ROM memory on the Network Interface Card (NIC). ) it creates a huge burden on the administrator to add these adresses to the firewall because it doens’t have an hierarchy.
For example: In a firewall you could filter an entire IP range by specifing the network address and it’s subnet mask:
filtering 192.168.1.1 with the mask 255.255.0.0 will filter all IP traffic in the 192.168.x.x range without typing in all the adresses.
When using mac adresses, you have to type in all mac adresses because there is no pattern in all the mac adresses in your network.
One PC could have mac: 00:03:0f:03:03:0F
and another could have: F3:23:E8:D1:0f:1D
More complicated firewalls can filter based on protocols, application, and sessions, which i will explain in an other article
So, when a packet arrives it checks out what kind of packet it is.
Then it compares the information gathered to the the rules in the firewall.
There are different implementations of walking through the rules, so you should be aware of how your firewall software ( or hardware ) does this.
Most firewalls though, loop through the rulelist and when they find a rule that matches theire packet they simply stop looking in the list of rules and perform the action stated in the list.
In these kind of firewalls, the order of adding rules is extremly important because overlapping rules could result in an unexpected result of denying or allowing packages which should’t be allowed or denied.
Another example:
You create a firewall rule to allow all traffic from network 192.168.1.0 but, you want to deny traffic that travels over port 1992:
Allow IP 192.168.1.0 255.255.255.0 any
Deny IP any any port 1992
Now, you start your application that runs on port 1992 and it CONNECTS to it’s destination which it wasn’t suppose to do, because the first firewall rule states that ALL IP traffic from 192.168.1.0 can travel to anywhere.
Since the firewall stops looking after the first match, it simply ignores the statement after the first rule.
A second method of walking through the lists is by maintaining a kind of state table. With this method, the firewall walks through all the rules and keeps a record of what it should do with the packet. When a rule states it should allow the packet, it flips the status to allow. When a rule states it should deny the packet, it denies it. The last rule who flips the status, “wins” and decides what to do with the packet.
A second oftenly overseen problem, is the implicit deny any any rule. Some firewalls ( all Cisco’s do ) have on the end of each accesslist ( firewall-ruleset ) an implicit deny rule. This means, that if an packet has been compared to all the rules and it did not match to anything, it will be denied.
If you have a very restrictive firewall, this is a good thing. But if you would just like to deny a few ports or protocols you could forget to explicitly ALLOW all other traffic into your network, because if you denied the traffic you wanted to deny to implicit deny blocks it also blocks all other traffic.
An Allow IP Any any statement in your firewall ruleset whould do the job ( make sure you do this on the end, otherwise you will get the problem of allowing unwanted traffic into your network ( as discribed above ).
A third problem dat often occurs is mapping the firewall to the wrong side of the interface.
This is less of a problem in Windows environments, because you usually just have two interfaces and you don’t have to decide to map it to the inside or outside.
On Hardware routers/firewalls this can sometimes a problem. For example, with Cisco devices you have to specify if you want to map it to the in or outside of the interface. Mapping it to the rigth interface, but in the wrong direction makes your ruleset in the best scenario completly worthless because the view of source and destination is turned upsite down of what you had in mind.
Source adresses have become destinations adresses, and visa versa
So, to give you some guidelines setting up your firewall:
– Create a document / excel sheet with which traffic you will allow or deny
– try not to overlap rules when not nessecary
– Place them in such an order they overlap the right way
– Make sure you apply the ruleset to the right interface, in the right direction
– Test your configuration by generating traffic from and to your network