ipfw in FreeBSD
Introduction
ipfw is the user interface for controlling the ipfirewall(4) and the dummynet(4) traffic shaper in FreeBSD.
A firewall configuration is made of a list of numbered rules, which is scanned for each incoming or outgoing IP packet until a match is found and the relevant action is performed. Depending on the action and cer- tain system settings, packets can be reinjected into the firewall at the rule after the matching one for further processing. All rules apply to all interfaces, so it is responsibility of the system administrator to write the ruleset in such a way as to minimize the number of checks.
A configuration always includes a DEFAULT rule (numbered 65535) which cannot be modified, and matches all packets. The action associated with the default rule can be either deny or allow depending on how the kernel is configured.
If the ruleset includes one or more rules with the keep-state or limit option, then ipfw assumes a stateful behaviour, i.e. upon a match it will create dynamic rules matching the exact parameters (addresses and ports) of the matching packet.
These dynamic rules, which have a limited lifetime, are checked at the first occurrence of a check-state or keep-state rule, and are typically used to open the firewall on-demand to legitimate traffic only. See the RULE FORMAT and EXAMPLES sections below for more information on the stateful behaviour of ipfw.
All rules (including dynamic ones) have a few associated counters: a packet count, a byte count, a log count and a timestamp indicating the time of the last match. Counters can be displayed or reset with ipfw commands.
Rules can be added with the add command; deleted individually with the delete command, and globally with the flush command; displayed, option- ally with the content of the counters, using the show and list commands. Finally, counters can be reset with the zero and resetlog commands.
Table Descriptions
filter Table
The filter table is the default table for any rule. It is where the bulk of the work in an iptables firewall occurs. Avoid filtering in any other table as it may not work. It has three commonly used builtin chains. Those chains are INPUT, OUTPUT, and FORWARD. Packets destined for the host traverse the INPUT chain. Packets created by the host to send to another system traverse the OUTPUT chain. Packets received by the host that are destined for another host traverse the FORWARD chain.
nat Table
The Network Address Translation or nat table is used to translate the source or destination field in packets. A system with a static IP should use Source Network Address Translation (snat) since it uses fewer system resources. However, iptables also supports hosts with a dynamic connection to the Internet with a masquerade feature. Masquerade uses the current address on the interface for address translation.
mangle table
The mangle table is used to alter certain fields in the headers of IP packets. It can be used to change the Time to Live or TTL, change the Type of Service or TOS field, or mark packets for later filtering.
Packet Path
Forwarded Packets
A packet that is intended for another host is called a forwarded packet. It first passes through the PREROUTING chain in the mangle table. It then traverses the PREROUTING chain in the nat table. This is where dnat rules are applied. The packet then traverses the FORWARD chain in the filter table. This is the only chain where filtering rules should be applied to the packet. The packet then passes to the POSTROUTING chain in the nat table. In this chain, snat and masquerading rules are applied. The packet then passes out the outgoing interface.
Received Packets
Packets addressed to the localhost first traverse the PREROUTING chain in the mangle table. Next they pass through the PREROUTING chain in the nat table. This is where dnat rules are applied. After the dnat rules, a routing decision must be made. If the packet is really intended for the localhost, the INPUT chain in the filter table is traversed. All filtering is done in this chain. Packets that are accepted are then passed to the local process or application for which it is intended.
Sent Packets
Packets that are generated on the localhost first traverse the OUTPUT chain of the mangle table. They then pass through the OUTPUT chain of the nat table. Next, they pass through the OUTPUT chain of the filter table. Once the packet has passed those chains, the system must determine where the packet should be routed. Once that decision is made, the packet traverses the POSTROUTING chain in the nat table. This where snat and masquerading rules are applied. The packet then passes through the appropriate network interface.
Firewall Generator
The firewall scripts generated by this program use several conventions. Filter table rules are mostly divided among several user-defined rule chains. This is intended to make the firewall easier to follow and to minimize the number of rules each individual packet must traverse. Bad packets are defined as packets in an INVALID state or any packets other than syn packets that are in a NEW state. Packets that are in an ESTABLISHED or RELATED state are accepted. They are part of an ongoing session. Inbound TCP, UDP, and ICMP packets are passed to a separate chains to determine if they should be accepted. By default, they are accepted from the internal interface and dropped from the external interface. TCP requests from the internal network for forwarding are passes through an outbound chain to see if it should be refused. By default, those requests are accepted.
Redhat installation instructions
Ensure that ipchains will not automatically start.
chkconfig --level 0123456 ipchains off
This will make sure that the ipchains init.d script is not linked to an S file in any of the rc directories.
Stop ipchains if it’s running.
service ipchains stop
Execute lsmod to see if the ipchains kernel module is still loaded. If it is, use rmmod to unload it.
Have the system link the iptables init.d startup script into run states 2, 3, and 5.
chkconfig --level 235 iptables on
Save this script and execute it to load the ruleset from this file. You may need to run the dos2unix command on it to remove carraige returns.
Save the ruleset to /etc/sysconfig/iptables. This can be done two ways.
service iptables save
iptables-save > /etc/sysconfig/iptables
The ruleset will be restored by the /etc/init.d/iptables script on boot.
NOTE: The /etc/init.d/iptables script can be modified to run this script instead. If you do so, save a copy so you can reapply your modifications after upgrading the iptables package. The advantage of using this script for the ongoing operation of the firewall is it gives you greater control over the modules and rulesets used. The above is simpler, however.