Stateful Packet Filtering

Packet state filtering can be used for any TCP flow to short-cut later filtering. The shortcuts are kept in a table, with no alterations to the list of firewall rules. Subsequent packets, if a matching packet is found in the table, are not passed through the list making packet filtering much more efficient.

For TCP flows, the filter follows the ack/sequence numbers of packets and only allows packets through that fall inside the correct window.

# Keep state for all outgoing telnet connections

# and disallow all other TCP traffic.

pass out on le1 proto tcp from any to any port = telnet keep state block out on le1 all

For UDP packets, packet exchanges are effectively stateless. However, if a packet is first sent out from a given port, a reply is usually expected in answer, in the reverse direction.

# allow UDP replies back from name servers

pass out on le1 proto udp from any to any port = domain keep state

The held UDP state is timed out in 60 seconds, as is the TCP state for entries added that do not have the SYN flag set. If an entry is created with the SYN flag set, any subsequent matching packet that does not have this flag set (that is, a SYN-ACK) causes it to be timeless. Actually the timeout defaults to five days, until either a FIN or RST flag is seen.

TCP Flags

Filtering on TCP flags is useful, but fraught with danger. Solaris IP Filter compares the flags present in each TCP packet, if asked, and matches if those present in the TCP packet are the same as in the Solaris IP Filter rule.

Flags are effective only for TCP filtering. Each of the letters possible represents one of the possible flags that can be set in the TCP header. The association is as follows:

Some IP filtering and firewall packages allow you to filter out TCP packets that belong to an established connection. This is, simply put, filtering on packets which have the ACK bit set. The ACK bit is only set in packets transmitted during the life cycle of a TCP connection. This flag must be present from either end for data to be transferred. If you were using a rule worded something like the following, allow proto tcp 10.1.0.0 255.255.0.0 port = 23 10.2.0.0 255.255.0.0 established it could be rewritten as follows:

pass in proto tcp 10.1.0.0/16 port = 23 10.2.0.0/16 flags A/A pass out proto tcp 10.1.0.0/16 port = 23 10.2.0.0/16 flags A/A

A more useful flag to filter on, for TCP connections, is the SYN flag. This is only set during the initial stages of connection negotiation, and for the very first packet of a new TCP connection, it is the only flag set. At all other times, an ACK or maybe even an URG/ PUSH flag can be set. So, if you want to stop connections being made to the internal network (l0.l.0.0) from the outside network, you might do something like the following:

# block incoming connection requests to my internal network

# from the big bad internet.

block in on eri0 proto tcp from any to l0.l.0.0/l6 flags S/SA

If you wanted to block the replies to this (the SYN-ACK flags), then you might do:

block out on le0 proto tcp from l0.l.0.0 to any flags SA/SA

where SA represents the SYN-ACK flags both being set.

The flags after the / represent the TCP flag mask, indicating which bits of the TCP flags you are interested in checking. When using the SYN bit in a check, you should specify a mask to ensure that a packet with SYN and URG flags set cannot defeat your filter.

Flag S actually equates to flags S/AUPRFS and matches against only the SYN packet out of all six possible flags, while flags S/SA allow packets that may or may not have the URG, PSH, FIN, or RST flags set.

0 0

Post a comment

  • Receive news updates via email from this site