rc.firewall.iptables.X
Example IPTables 1.2.1 firewall scripts for a multi/dual homed firewall.
[email protected]

------------------------------------------------------------------------------
I've tried here to provide some brief documentation for the IPTables firewall
scripts contained in this directory. If you're not familiar with IPTables
functionality and usage, then you may also want to check out some of the URLs
listed at the top of the firewall scripts(HOWTOs, etc).

I hope you find these scripts useful, if you have any comments or suggestions
please feel free to email me.

## User-defined Chains ##

Chain KEEP_STATE
The KEEP_STATE chain holds a few rules for generic stateful packet filtering.
This chain is called from many of the INPUT/OUTPUT chains to DROP "INVALID"
and perhaps "UNCLEAN" packets and allow other packets from "RELATED" or
"ESTABLISHED" connections.

CHECK_FLAGS
The CHECK_FLAGS chain contains a few rules to filter based on TCP flags.
These rules do indeed filter mainly bogus/malicious traffic(scans, etc). It
would be a good idea to keep an eye on what these rules send to the logs.
Null scans are also logged and dropped, in the mangle table.

DENY_PORTS
The DENY_PORTS chains contains a few rules to DROP and/or LOG packets based
on the source and/or destination port number of the packet.

Packets destined to/from the following ports are dropped by default in the
script. These are just some examples of some commonly used ports that
certain daemons/trojans/DDoS agents may utilize.

## TCP ##
137:139 SMB
2049 NFS
6000:6063 X
20034 Netbus 2 Pro
12345:12346 Netbus
27374 SubSeven
27665,27444,31335 Trinoo
10498,12754 Mstream

## UDP ##
2049 NFS
31337 BO2k
27444,31335 Trinoo
10498 mstream

These are just examples to stare at. They guarantee no real protection
against the associated trojans.

For more common port numbers check out:
http://www.sans.org/newlook/resources/IDFAQ/oddports.htm

ALLOW_PORTS
The ALLOW_PORTS chain simply ACCEPTs packets based on port number. If you have
a default FORWARD policy of DROP, then you would need to utilize a chain like
this if you are DNATing/routing connections behind the firewall or perhaps
running services on(!!!) the firewall.

ALLOW_ICMP
The ALLOW_ICMP chains simply allows packets based on ICMP type. Currently
the firewall allows the flow of the following ICMP types:
Echo Reply (pong)
Destination Unreachable
Echo Request (ping)
TTL Exceeded (traceroute)

SRC_EGRESS && DST_EGRESS
The SRC_EGRESS and DST_EGRESS chains filter packets that have a source or
destination IP address matching an array of private or reserved subnets.

TOS_OUTPUT
The TOS_OUTPUT chain exists in the mangle table and mangles the TOS(Type
of Service) field in the IP header of locally generated, outgoing packets.

TOS_PREROUTING
The TOS_PREROUTING chain exists in the mangle table and mangles the TOS(Type
of Service) field in the IP header of packets being routed through the firewall.

The following user-defined chains are pretty obvious. The firewall script is
designed to have a user-defined INPUT and OUTPUT chain for every available
interface. From these user-defined chains are called the user-defined chains
mentioned above, which I call "Special Chains". The chains below are then
called by the built-in INPUT/OUTPUT/FORWARD chains. This isn't really the
rule, of course, alot of the user-defined chains mentioned above are called
directly from the built-in INPUT/OUTPUT/FORWARD chains. This is done to
assure proper flow of the packets through the filters.

EXTERNAL_INPUT
INTERNAL_INPUT
DMZ_INPUT
LO_INPUT
EXTERNAL_OUTPUT
INTERNAL_OUTPUT
DMZ_OUTPUT
LO_OUTPUT

Other Notes:

Optimization -
Yes, there are a bunch of ways to optimize this ruleset, and please feel free
to do so. One major optimization is within the user-defined chains
SRC_EGRESS/DST_EGRESS and the "RESERVED_NET" array. I've left the array in
its standard form for readability, but please read the following post on ways
to optimize this portion of the ruleset:
http://lists.samba.org/pipermail/netfilter/2000-December/006197.html

Thanks to Tuomas Heino([email protected]) for this.