The wonderful world of iptables[Was: Samba help]
dalen
dalen at czexan.net
Fri Jan 9 04:43:44 UTC 2004
Bevan C. Bennett wrote:
> 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...
>
>
Bevan,
Thanks for the excellent iptables howto in a reply! It was very good
(not babble at all).
Thanks,
Dale
More information about the fedora-list
mailing list