Bug 131568

I found some issues with the ipf docs.

Sorry, I couldn't find the source in CVSweb, and http://www.freebsd.org/tutorials/docproj-primer/ is currently a 404.

Also, 'interrogation' is misused in a few places -- 'matching' would be better, since it's not an active conversation.


The bit about firewalls having 2+ interfaces isn't correct for the single-host case using ipf just to protect itself from Internet traffic.

Fix: 

30.5.12 Stateful Filtering 

Packets destined to go out the interface connected to the public Internet are first checked against the dynamic state table; if the packet matches the next expected packet in an active session conversation, then it exits the firewall and the conversation flow is updated in the dynamic state table; then the next packet gets checked against the outbound rule set.

Packets coming in from the interface connected to the public Internet are first checked against the dynamic state table; if the packet matches the next expected packet in an active session conversation, then it exits the firewall and the state conversation flow is updated in the dynamic state table, then the next packet gets checked against the inbound rule set.


30.5.13 Inclusive Rule Set Example

The following rule set is an example of how to code a very secure inclusive type of firewall. An inclusive firewall only allows packets matching 'pass' rules through, and blocks all others by default. All firewalls have at least two interfaces, which must have their own rules to allow the firewall to function.


In cases where one or more NICs are connected to private network segments behind the firewall, those interfaces may require rules to allow packets originating from those LAN interfaces transit to each other and/or to the outside (Internet).


The rules should be first organized into three major sections: first trusted interfaces, then the public untrusted interface outbound, and last the public untrusted interface inbound.

The rules in each of the public interface sections should have the most frequently matched rules placed before less commonly matched rules, with the last rule in each section blocking and logging all packets in that category.

The Outbound Section in the following rule set only contains 'pass' rules which contain selection values that uniquely identify the service that is authorized for public Internet access. All the rules have the 'quick', 'on', 'proto', 'port', and 'keep state' options set. The 'proto tcp' rules have the 'flag' option included to identify the session start request as the triggering packet to activate the stateful facility.

The Inbound section has all the blocking of undesirable packets first, for two different reasons. The first is that malicious packets may be partial matches for legitimate traffic; if they're malicious we need to discard them rather than allowing them in based on their partial matches for 'allow' rules. The second reason is that known uninteresting rejects can be blocked silently, rather than being caught and logged by the last rule in the section. This last rule in the section, which blocks and logs all packets that have not already been allowed or dropped, helps record malicious activity for future analysis and to create legal evidence for prosecution of attackers.

Another thing to note is that these rules do not return any response to any undesirable traffic -- such packets simply get dropped and vanish. This way the attacker has no knowledge of whether their packets have reached your system. The less the attackers can learn about your system, the more time they must invest before actually doing something bad.

We suggest logging the first inbound "nmap OS fingerprint" attempt, because this a common indication of an attack beginning.

Any time you see messages logged for a rule with "log first", use the "ipfstat -hio" command to see the number of times the rule has been matched; large numbers of matches indicate a flood / attack.

When you see packets with port numbers you do not recognize, look them up in /etc/services or at http://www.securitystats.com/tools/portsearch.php.


You have to change the dc0 interface name in every rule to the interface name of the NIC that connects your system to the public Internet. For user PPP it would be tun0.


#################################################################
# Interface facing Public Internet (Outbound Section)
# Match session start requests originating from behind the
# firewall on the private network
# or from this gateway server, destined for the public Internet.
#################################################################


# Allow in secure ssh and scp (telnet/ftp/rlogin replacements) from public Internet
pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state


# Block and log only first occurrence of all remaining traffic
# coming into the firewall. The logging of only the first
# occurrence avoids filling disk with Denial of Service logs.
# This rule enforces the block all by default logic.
block in log first quick on dc0 all
################### End of rules file #####################################
How-To-Repeat: 30.5.12 Stateful Filtering 

Packets destined to go out the interface connected to the public Internet are first checked against the dynamic state table, if the packet matches the next expected packet comprising in a active session conversation, then it exits the firewall and the state of the session conversation flow is updated in the dynamic state table, the remaining packets get checked against the outbound rule set.

Packets coming in to the interface connected to the public Internet are first checked against the dynamic state table, if the packet matches the next expected packet comprising a active session conversation, then it exits the firewall and the state of the session conversation flow is updated in the dynamic state table, the remaining packets get checked against the inbound rule set.


30.5.13 Inclusive Rule Set Example


The following rule set is an example of how to code a very secure inclusive type of firewall. An inclusive firewall only allows services matching pass rules through and blocks all other by default. All firewalls have at the minimum two interfaces which have to have rules to allow the firewall to function.


In cases where one or more NICs are cabled to private LANs behind the firewall, those interfaces must have a rule coded to allow free unmolested movement of packets originating from those LAN interfaces.


The rules should be first organized into three major sections: all the free unmolested interfaces, the public interface outbound, and the public interface inbound.

The rules in each of the public interface sections should have the most frequently matched rules placed before less commonly matched rules, with the last rule in the section blocking and logging all packets on that interface and direction.

The Outbound section in the following rule set only contains 'pass' rules which contain selection values that uniquely identify the service that is authorized for public Internet access. All the rules have the 'quick', 'on', 'proto', 'port', and 'keep state' option coded. The 'proto tcp' rules have the 'flag' option included to identify the session start request as the triggering packet to activate the stateful facility.

The Inbound section has all the blocking of undesirable packets first, for two different reasons. The first is that these things being blocked may be part of an otherwise valid packet which may be allowed in by the later authorized service rules. The second reason is that by having a rule that explicitly blocks selected packets that I receive on an infrequent basis and that I do not want to see in the log, they will not be caught by the last rule in the section which blocks and logs all packets which have fallen through the rules. The last rule in the section which blocks and logs all packets is how you create the legal evidence needed to prosecute the people who are attacking your system.

Another thing you should take note of, is there is no response returned for any of the undesirable stuff, their packets just get dropped and vanish. This way the attacker has no knowledge if his packets have reached your system. The less the attackers can learn about your system, the more time they must invest before actually doing something bad. The inbound 'nmap OS fingerprint' attempts rule I log the first occurrence because this is something a attacker would do.

Any time you see log messages on a rule with 'log first'. You should do an ipfstat -hio command to see the number of times the rule has been matched so you know if you are being flooded, i.e. under attack.

When you log packets with port numbers you do not recognize, look it up in /etc/services or go to http://www.securitystats.com/tools/portsearch.php and do a port number lookup to find what the purpose of that port number is.


You have to change the dc0 interface name in every rule to the interface name of the Nic card that connects your system to the public Internet. For user PPP it would be tun0.


#################################################################
# Interface facing Public Internet (Outbound Section)
# Interrogate session start requests originating from behind the
# firewall on the private network
# or from this gateway server destine for the public Internet.
#################################################################


# Allow in secure FTP, Telnet, and SCP from public Internet
# This function is using SSH (secure shell)
pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state


# Block and log only first occurrence of all remaining traffic
# coming into the firewall. The logging of only the first
# occurrence stops a .denial of service. attack targeted
# at filling up your log file space.
# This rule enforces the block all by default logic.
block in log first quick on dc0 all
################### End of rules file #####################################