Packet Matching

In addition to the basic parameters, such as Source and Destination IP Address, FireRack also supports more unusual and quite powerful matching parameters.

Available matches (in no particular order):

• Connection state

  This match parameter allows you to specify the "state" of connection, according to the Connection Tracking system. For instance, a rule can be written to allow FTP data connections, where the source and destination ports are unpredictable and are only known to the connection-tracking system.

• Port scan detection

  The parameters for this match are user definable. You specify a score for connection attempts to different port ranges, a time frame, and a maximum score allowed within that time frame. If attacker exceeds your score within the timeframe, this match is triggered.

• Time of day

  You specify a start time and end time for the rule. You can also select the days of the week when you wish the rule to apply.

• Dynamic Group Membership

  This is a very powerful feature, which is far too complicated to fully describe in this section. Suffice to say, FireRack can dynamically add IP addresses to a Dynamic Group in response to certain events. Once an IP address is added to the group, you can make use of it by matching against that Dynamic Group as either a source or a destination address in a firewall rule.

• Static Host/Subnet Group Membership

  Most firewalls only allow a rule to match a certain IP address or subnet as a source or destination. With FireRack, you can create arbitrary groups of IP addresses and subnets and use the group as the source or destination for your rule. (e.g. You could make a group called "All mail servers", containing a list of appropriate IP addresses)

• String Match

  This match examines the payload of a packet and performs a simple string search. If the string is present, the match is triggered.

• TTL (Time To Live)

  Every IP packet has a TTL field, which is reduced by 1 for  each router through which the packet passes on the way to its destination. The initial TTL assigned to a packet as it leaves the originating host is quite predictable. This makes it possible to detect the use of unauthorised routers (or NAT gateways) on your network.

• MAC Address <-> IP Address Match

  FireRack support a very sophisticated MAC-IP matching engine. Thousands of valid MAC-IP pairs can be loaded into the firewall's memory, and it can check every packet originating on the LAN to ensure that the packets have originated from an authorised IP address. Combined with Ethernet switches which can lock MAC addresses to ports, this is a very effective defence against local spoofing.

• User defined Packet Mark

  Packets can be "marked" by a user in one part of the firewall rule set, and this mark can then be matched against in a later part of the rule set. This allows the creation of complex AND and OR conditions on packets.
  

• User defined Connection Mark

  This is similar to, but more powerful than, the packet mark. Once a connection has been assigned a Connection mark (for whatever reason), all subsequent packets in that connection carry that same mark. This match allows you to identify those packets.

Firewall Rule "Targets"

When all aspects of a firewall rule completely match the properties of a packet, that rule is triggered. The outcome of this event is determined by the "target" of that rule.

Typically you would expect a firewall to have the following targets:

• Accept - Let the packet through
• Drop - Silently discard the packet
• Reject - Discard the packet and send an ICMP message to the sender

In addition to these targets, FireRack supports the following more advanced targets:

• Add to Dynamic Group

  When a rule, such as the "port-scan detection" rule identifies an attacker, you may wish to add the attacker IP address to a blacklist. Or, when a "string match" tells you that a user is using an unauthorised web browser; you may want to add that IP address to an offenders list. Dynamic Groups can also be used for whitelisting. The scope of a Dynamic list is only limited by the imagination of the network administrator. You can also use rules to remove IP addresses from dynamic groups.
  

• Tarpit

  This causes FireRack to pretend to accept a packet, but send the connection into a "tarpit". A Tarpit keeps a connection alive as long as it can, while preventing any data from flowing. This can dramatically slow down the progress of a port scan, and tie an attacker or spammer's computer up for many hours.

• Log

  A custom log message is written to syslog, with a user-defined string. This can also be combined with any other target.
  

• Mark Packet

  A mark is placed on the packet for use in subsequent firewall rules.

• Connection Mark

  This and all subsequent packets will carry a user-defined mark, allowing specialised handling if that connection.

• Redirect

  This allows connections to be redirected to a different port and/or host.

• Reroute

  This allows the overriding of the firewall's routing table, via firewall rules. For instance, if an organisation had multiple ADSL lines, this target would allow the routing of web traffic over one ADSL lines and SMTP over another. Given the wide range of matches available with FireRack (see above) this allows very powerful and fine-grained control over routing.