The wonderful world of iptables[Was: Samba help]

[Bevan C. Bennett]

Andrew Robinson wrote:

> Please explain. OK, this is a request for an iptables tutorial. And BTW, 
> I'm buying, but I'm still asking for the sales pitch ;).

There's a few good (if occassionally complex) ones out there already, 
particularly:

http://iptables-tutorial.frozentux.net/iptables-tutorial.html

You may want to skip to chapter 3 and go from there.
Chapter 4 explains how connection tracking works for both TCP and UDP 
packets.

For a quick quick overview, lets go over the default FC1 iptables and 
what it does for us.

-A INPUT -j RH-Firewall-1-INPUT
# send all incoming packets through the RH-Firewall-1-INPUT chain.
-A FORWARD -j RH-Firewall-1-INPUT
# ditto for any incoming packets that we plan to forward out another 
interface.

# Now we start the RH-Firewall-1-INPUT chain. Packets will pass through 
this from top to bottom, trying to match each rule in turn. When a 
packet does match, it's sent to wherever -j (jump) tells it to go, which 
in a simple filter will be either ACCEPT, REJECT or DROP.
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
# allow anything coming in my loopback interface. (I trust me)
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
# allow any ICMP packets
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
# allow any packets of protocol type 50 or 51. /etc/protocols says these 
are:
ipv6-crypt      50      IPv6-Crypt      # Encryption Header for IPv6
ipv6-auth       51      IPv6-Auth       # Authentication Header for IPv6
So if you aren't doing any IPv6 stuff you could safely remove those rules.
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# allow any packet that's part of an established connection, for example 
a reply to a packet we sent. The 'RELATED' bit gets a little fancier and 
tries to figure out things like if a new ftp-data connection request is 
related to your existing ftp-control connection. This is what allows 
your system to function as a client.
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
# this rule matches anything, and says to reject the connection by 
sending an appropriate ICMP reply to the originator. We've also 
specified that we want to send a reply of 'prohibited' rather than the 
default of 'port unreachable' (more on this later).

That's it for the default... pretty tight.
Most people these days will, however, also have the following:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j 
ACCEPT
# If it's a NEW TCP packet heading for port 22 (ssh), let it in. This 
rule is always listed after the -m state --state ESTABLISHED,RELATED 
rule, which means that, since there are only four possible states, all 
packets below this point are either NEW or INVALID. By specifying that 
the packet must be NEW, all we're really doing here is saying that it 
shouldn't be INVALID. The -m tcp says that we're going to be using the 
tcp matching rules, but -m tcp is automatically implied by -p tcp, which 
means it's not strictly neccessary.

If you want to run servers on your box they need to respond to NEW 
packets, and you'll need to add one or more lines like this to your 
configuration, depending on what ports that server uses.

For example, if we wanted to run ssh (tcp port 22), smtp (tcp port 25) 
and http (tcp port 80), we might have the following:

-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state INVALID -j DROP
-A RH-Firewall-1-INPUT -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 80 -j ACCEPT

I chose here to explicitly drop INVALID packets rather than repeating 
the NEW test over and over. Incidently, if you wanted to restrict ssh so 
that only certain systems can connect, you could do that with rules like 
this:
# only the system with IP 10.1.2.3
-A RH-Firewall-1-INPUT -p tcp --dport 22 -s 10.1.2.3 -j ACCEPT
# any system in the 10.1.2.x network
-A RH-Firewall-1-INPUT -p tcp --dport 22 -s 10.1.2.0/24 -j ACCEPT
# any system NOT in the 10.1.2.x network
-A RH-Firewall-1-INPUT -p tcp --dport 22 -s ! 10.1.2.0/24 -j ACCEPT

Are we having fun or what?

One thing some people noticed earlier on this list, is that traceroute 
output to a fedora system looks odd, with !<10> showing up in the 
results. That indicates that traceroute received an unexpected type of 
reply, ICMP reject code 10 "administratively prohibited". This is 
because traceroute by default sends not ICMP ping packets (which would 
have been accepted by our icmp rule) but UDP packets to the usually 
unused ports 33434 and up. It expects to get an ICMP 'port unreachable' 
reply, which would be the default if we hadn't overridden it. You can 
make your system "traceroute friendly" by removing "--reject-with 
icmp-host-prohibited" from that last line, or by inserting the following 
line directly above it:
-A RH-Firewall-1-INPUT -p udp --dport 33434:33534 -j REJECT

In the case of SAMBA, it's a complex server that deals with several 
different protocols on several different ports, so you need to open them 
all up.
-A RH-Firewall-1-INPUT -p udp --dport 137:138 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 139 -j ACCEPT

You cannot say something like:
-A RH-Firewall-1-INPUT --dport 137:139 -j ACCEPT # WRONG
because --dport is only enabled by the -m tcp or -m udp matching filters 
  (the appropriate one is incorporated automatically when we do a -p tcp 
or -p udp, as mentioned earlier).

Since MS protocols are dangerous stuff, I'd recommend restricting those 
to the network that your local clients are on using -s.

And that's probably enough iptables babble for one evening...