Stateful Packet Inspection and Firewall Rules
[Index]
[Previous Chapter: Overview of the Virtual Firewall Control Panel]
[Next Chapter: Firewall Phases and Actions]
Chapter 3: Stateful Packet Inspection and Firewall Rules
The FireRack is a stateful packet inspection firewall. Unlike a more traditional packet filtering firewall which can only consider each individual network packet on its own, a stateful packet inspection firewall is also able to consider each individual packet as part of a connection, or traffic flow. This makes it much more intuitive to configure.
The recommended firewall configuration is to only allow connections to services which you need to use or make accessible. Although a connection consists of packets flowing in both directions, it is not necessary to explicitly permit the traffic in both directions. The FireRack tracks any established connections and will automatically permit any network traffic that forms part of an established connection. Therefore, it is sufficient and preferable to just allow each new connection of a required type to be initiated in a given direction.
The operation of the firewall is governed by a set of rules that you define. The rules are grouped into three different types, each handled in a separate phase of the firewall. However the basic structure and operation of the rules is the same in all phases. (The firewall phases are detailed in the next section.)
A rule essentially has two parts: a definition of what kind of traffic the rule should be applicable to, i.e. what traffic it should 'match', and an action that is done to traffic which matches the rule. The actions available depend upon which firewall phase the rule is in, and are hence described in the next section. Traffic is usually matched on the basis of its source IP address, destination IP address, source port, destination port, protocol or any combination thereof. The direction in which the connection or traffic flow was initiated is also a parameter, and its use is strongly recommended.
Rule Direction Indicators |
||
 |
 |
 |
| This symbol means the rule may only match connections entering your security zone. In other words, it may apply to any computer in the outside world (on the Internet or in other zones) that tries to initiate a connection to a computer in your security zone. | This symbol means the rule may match connections passing through your virtual firewall in any direction. | This symbol means the rule may only match connections leaving your security zone. Therefore, it can only apply to a connection initiated by a computer in your security zone. |
Within each phase of the firewall is a list of zero or more rules. The order of the rules matters: for any given network traffic, only the first rule to match it is the applicable rule, and the action corresponding to that rule is taken. In order words, the higher a rule is up the list, the higher the precedence of that rule.
As an example of where you need exploit the ordering of the rules, say that you wished to run a zone full of publicly accessible web servers. You would obviously need to tell the firewall to permit the whole world to access any HTTP servers in your zone. HTTP is a TCP based protocol that runs on port 80, so you would need to craft a general rule that matches any new TCP connections entering your zone with a destination port address of 80, and any source or destination IP addresses. The action of this rule would be to let the connection through the firewall:
That's simple enough. As you can see the direction indicator indicates this rule only applies to connections entering your zone. The green tick signifies that the action if the rule matches will be to allow the connection. However, what if you did not want the whole world to be able to access just one of those servers? Perhaps one of the servers contains your company's intranet site and you only wish to make it accessible from your company's offices.
One rather tedious approach would be to get rid of this rule, and instead have a rule for every server you do want to make world accessible. A better way would be to use more specific rules to override the general rule. Craft a rule that matches any TCP connection entering your zone that is addressed to port 80 on your intranet server, and place this immediately before the general rule. The action of this rule is to block the connections. Since this rule is more specific and occurs first, it will match and block any connections to the intranet server, but connections to other servers will not match this rule. Instead they 'fall-through' to the next rule which matches and allows them.
Note how this new rule is the same as the original rule, except for the destination address. Whereas the original rule matches traffic to 'Anywhere' (given the rule only applies to traffic entering the zone in this context it means 'Anywhere within the security zone'), the new rule matches traffic only to 'Intranet Server'. 'Intranet Server' is just a convenient name we have assigned to a particular IP address (via the 'Host & Network Names' configuration screen). The red cross signifies that the action of this rule if it is matched will be to block the connection.
As you can see, we now have world accessible web servers, except for our intranet server which is accessible from nowhere. We therefore need some extra rules that are even more specific to allow each office access to the intranet server. These are inserted above the two existing rules, and each rule should match TCP connections from one of the office's networks to port 80 on the intranet server.
Note that we have neglected to specify the destination address of the intranet server for the two new rules relating to our offices, and are instead using a destination of anywhere. Presently it makes no difference to us as there is only one restricted server. However, we may in the future wish to add more intranet server, and our assumption is that it will always be desirable to connect to them all from our own offices. By using destination addresses of 'Anywhere' we have avoided the need to make further exceptions for the offices if we inserted rules to block other intranet servers.
[Index]
[Previous Chapter: Overview of the Virtual Firewall Control Panel]
[Next Chapter: Firewall Phases and Actions]