FireBrick - Firewalls, Bonding ADSL, Routers, Traffic Shaping...
FireBrick FB6000
Session tracking and fire-walling
Session tracking is key to a number of features of the FB6000 series routers. It is included in all models to provide some basic IPv6/4 NAT mapping. In some models the full fire-walling features are included.
Session tracking allows fire-walling (blocking or rejecting some traffic), address mapping (NAT, port mapping, IPv6/4 mapping), protocol specific routing, and traffic shaping (allocating traffic to a speed lane).
Note: some of these features are still in development.
How session tracking works
Session tracking means correlating packets that belong to a session. For some protocols like TCP this is relatively simple as the session has a well defined start and end, and way to identify what packets are in a session (by IPs and ports). Some are harder, such as UDP, where IPs and ports identify the session but there is no defined start and end. Some cannot be tracked by anything more than just IP addresses.
All types of session tracking use time-outs. There are two values that can be specified, an initial time-out and an ongoing time-out. When the session starts it has the initial time-out but as soon as a packet goes the other way (a reply) the time-out changes to the ongoing time-out.
For TCP the time-out starts small, a few seconds, but as soon as there is a reply the time-out changes to a long time-out (e.g. an hour). This is because TCP had a defined end. Once a FIN or RST is received then the time-out drops to a few seconds.
For UDP the time-out starts longer, e.g. 10 seconds, and when there is a reply it gets shorter, e.g. a second.
The time-outs can be fine tuned in the configuration for specific protocols and ports and IP addresses. The actual time-out used is one taken from a list of pre-defined time-out values that is at least the one specified in the config.
When session tracking applies
Session tracking applies to all traffic to/from the FB6000 itself. It also applied to traffic to and from specific interfaces where track="true" is specified. On a model with FB105 tunnels, each tunnel can have track="true" set. On models with L2TP the tracking can be set by RADIUS response on a per session basis. Packets that are not session tracked bypass all fire-walling and mapping rules.
Some models are specifically provided for firewalling, such as the FB6402. In this case the defaults may be different, i.e. tracking enabled by default unless explicitly turned off.
Rule sets
- The configuration consists of an ordered list of rule-sets each of which has an order set of rules.
- The rule-sets are considered in order, and within each rule-set the rules are considered in order.
- Each rule-set has entry criteria, and if these do not match the rule-set is not considered. Checking moves on to the next rule-set
- Each rule has a set of matching criteria in the same way. Once a rule is found that matches its criteria then no further rules in the rule-set are considered. i.e. only one matching rule in each rule-set is applied.
- The matching rule has actions which are processed. If a rule-set meets the entry criteria but no rule in a rule-set matches then there are actions on the rule-set itself that are used.
- The actions change things, like IP addresses or the overall action (allow/drop/reject). These changed parameters are then used to check the criteria for the next rule-set and its rules. I.e. changes accumulate as checking continues from one rule-set to the next. Once all rule-sets have been checked the final outcome applies.
Examples
NAT private IPs
This rule-set on it's own without the encompassing rule would cause all traffic from any RFC1918 addresses to have nat-source set to true, which is generally what you want. i.e. Private IPs are NATed. However, the embedded rule says that traffic that is also to an RFC1918 address will not have nat-source set. This allows two interfaces that use RFC1918 addresses to talk to each other without using NAT.
You will note the rule does not say nat-source="false". It does not have to, as the actions in the rule-set do not apply at all if the rule matches, and the actions in the rule do not contain nat-source. This does mean that if some previous rule causes nat-source to be set to true, this would not change that even for RFC1918 to RFC1918 traffic.
<rule-set name="private IP NAT" nat-source="true" source-ip="192.168.0.0/16 172.16.0.0/12 10.0.0.0/8"> <rule target-ip="192.168.0.0/16 172.16.0.0/12 10.0.0.0/8"/> </rule-set>
Matching criteria
- Routing table
- Source IP address
- Target IP address
- Source or Target IP address (i.e. one check for either)
- Protocol ID, e.g. 6 for TCP, 17 for UDP
- Source port, where applicable. If the protocol in use has no ports then it will not match any source port list specified
- Target port, where applicable. If the protocol in use has no ports then it will not match any target port list specified
We plan to extend the matching criteria to include checks on source interface and target interface as well.
Rule actions
- Action: Allow, block or reject
- Change routing table
- Change target IP, including changing between IPv4 and IPv6
- Change source IP
- Change target port where applicable
- Change source port where applicable
- Set NAT source mode, when the source IP and port will be changed to a local one (done at the end)
- Logging control, indicating if the start and end of the session is to be logged.
Obviously reply traffic is mapped back, but you have to ensure that replies will be routed via the FB6000. If NAT source has been set then the source port is changed to one from a pool of source ports. If NAT source is set and no source IP has been specifically defined then the source IP is set to one of the FB6000's IPs based on the target interface/subnet. This ensures using NAT will send traffic back to the FB6000 to be un-mapped.
Names IP and protocols
We plan to provide a means to name a list of IP ranges and use the name in the rules and rule-sets as part of the list of IPs.
We also plan to allow sets of source/target ports and protocol IDs to be defined with a name to be used in rules and rule-sets.
Special cases
There are a number of special cases that are built in to the session tracking system.
In these examples we use A, B, etc, to be the IP and port and protcol and table, etc, for one end. E.g. a packet make be A-B, i.e. traffic from A's IP and port to B's IP and port. This might be mapped, e.g. A-B:C-B meaning traffic A-B is mapped C-B, and the reverse traffic B-C is mapped B-A.
Default action
The default action is currently to allow all. This is likely to change for products that are primarily firewall products. In such cases it is likely that track will default to true on interfaces and the default action default to drop. However, in this case the default will be set to allow for traffic to/from the FireBrick itself to allow access to the FireBrick in a virgin config. In the case of products with a defined WAN and LAN this would only be for access to the FireBrick from the LAN. The exact rules are not yet defined. As such we recommend a simple <rule-set action="drop"/> at the start of your rule-sets to define the default action (in this case drop).
Drop/Reject
For a new packet, e.g. A-B, if the rules define it should be dropped or rejected then a one-sided session is created with a one second timeout, and no reverse mapping. This means further packets A-B are dropped or rejected immediately without re-checking the rule-sets. However if a packet was received B-A (unlikely as this would logically be a reply to a packet that was never sent) then that is considered independently via the rules.
ICMP handling
ICMP (and ICMPv6 for IPv6) are processed specially. If they contain a non-error packet then they are treated like any other protocol that does not have ports and so can match a rule for the protocol.
If they contain an error, then they have a payload which quotes the initial bytes of a packet to which the error relates. In this case the content of this packet is checked against the rules instead of the ICMP itself.
However, an ICMP error can never start a session. This prevents an error packet being checked against outbound rules and creating a reverse path through the firewall. If there is no established session the ICMP packet is dropped.
Y routing
It is possible to create a session, e.g. A-B:C-B, which is a case where traffic A-B is mapped to C-B, and in this case C is usually NAT source (i.e. the FireBrick's address and an ephemeral port). In this case reply traffic B-C is mapped back to B-A.
However if a packet B-A is received, i.e. matching exactly the IPs and ports as a reply to the original packet, then this is checked against firewall rules. If it is allowed it would create a non-mapped session B-A:B-A. However, doing this would make a "Y" set of sessions. Packets A-B would not know if they should match A-B:C-B and change to C-B, or map the reverse on B-A:B-A and just be allowed as a B-A packet. If this scenario happens then the new session is simply not allowed and the B-A packet is dropped.
Restoring routes
If the FireBrick is restarted then all sessions are lost. In this case packets that arrive, even if continuing a previously valid session, are checked against the firewall rules. If they are allowed then a new session is made. If they are not then a one-sided block/reject session is made.
Imagine if originally there was A-B:A-B session, i.e. A-B is allowed (and not changed). Replies B-A are allowed. Once sessions are lost, B-A is not allowed so makes a one-sided dropping session. But then a packet A-B is sent (maybe resending as no reply, etc). In this case a session clash happens very much like the "Y" routing above. However, as one side of the session is one-side, the one-sided session is discarded and the new session made. The A-B traffic flows and further B-A replies are then allowed - restoring the session after a firewall restart.
This really only works where there is no dynamic mapping such as nat-source
Mapped TCP
A TCP session can start based on any packet (as above, restoring sessions). However, if the packet would cause a nat-source session and teh packet is not the first in the TCP glow (i.e. SYN and no FIN) then that makes no sense as the dynamic nat-source will be different this time. In such cases a one-side reject session is made.
Triangular routes
A triangular route applies where traffic takes one route A to B and a different route B to A. Such routing is allowed in IP, and allowed on the FireBrick. Once established a session can continue on any interfaces (though it does have to match routing tables, which are interface specific).
However, if a triangular route has the FireBrick in one direction and not in the other, then this can cause issues. Any form of IP or port mapping cannot work in such cases as the mapping is not un-done when the reply goes via a different route. However, using nat-source always sets the new source IP to one allocated to the FireBrick itself and so reply traffic will hopefully go back via the FireBrick and avoid triangular routing.
Whilst such triangular routing it is not a problem where mapping is not done and the FireBrick is simply fire-walling. It does typically mean there is a route past the fire-wall, which is generally bad. It also means session time-outs and tracking do not work correctly causing sessions to drop more often and have to be restarted, or continue for longer and not be dropped. Both of these are less efficient than usual session tracking.
IPv6/4 NAT
A implicit final rule-set applies if an IPv6/4 NAT block is configured. This is an IPv6 prefix (at least /96). By arranging for this to be routed to the FireBrick (e.g. static or BGP announced) then traffic to this block is mapped to an IPv4 address based on the last 32 bits. Using a DNS proxy such as trick or treat daemon to return IPv6 addresses where a host only has an IPv4 address this allows IPv6 only hosts to access IPv4 internet.
The rule only applies where port mapping and nat-source can sensibly applied, i.e. protocols with ports like TCP and UDP as well as ICMP for pings, etc. The rule blocks attempts to map to 0.0.0./8, 127.0.0.0/8 and 224.0.0.0/3