[ Please CC all replies to me, as I dont read this list as often as I should ]
Hi all, I am setting up a linux firewall using IP firewall chains. However, I am having difficulty understanding an example that is given in the IPchains HOWTO. The example (4.2) is included below. What I don't get, is that the default rule for the input chain is DENY, with exceptions only for connections from anywhere to the local ftp port, or from anywhere originating at the ftp-data port. Wouldn't this mean that trying to, say, telnet out of the box would fail, as the remote machine could not return any data? Why would ftp in work if it can only access the ftp port - I thought connections only began at a certain port, then moved into the upper port range? I know I am probably missing something important - but I don't know what. Thanks for any help, advice, tutoring..... Best regards, Chris ---------------------http://www.rustcorp.com/linux/ipchains/HOWTO-4.html 4.2 Useful Examples I have a dialup PPP connection (-i ppp0). I grab news (-p TCP -s news.virtual.net.au nntp) and mail (-p TCP -s mail.virtual.net.au pop-3) every time I dial up. I use Debian's FTP method to update my machine regularly (-p TCP -y -s ftp.debian.org.au ftp-data). I surf the web through my ISP's proxy while this is going on (-p TCP -d proxy.virtual.net.au 8080), but hate the ads from doubleclick.net on the Dilbert Archive (-p TCP -y -d 199.95.207.0/24 & -p TCP -y -d 199.95.208.0/24). I don't mind people trying to ftp to my machine while I'm online (-p TCP -d $LOCALIP ftp), but don't want anyone outside pretending to have an IP address of my internal network (-s 192.168.1.0/24). This is commonly called IP spoofing, and there is a better way to protect yourself from it in the 2.1.x kernels and above: see How do I set up IP spoof protection?. This setup is fairly simple, because there are currently no other boxes on my internal network. I don't want any local process (ie. Netscape, lynx etc.) to connect to doubleclick.net: # ipchains -A output -d 199.95.207.0/24 -j REJECT # ipchains -A output -d 199.95.208.0/24 -j REJECT # Now I want to set priorities on various outgoing packets (there isn't much point in doing it on incoming packets). Since I have a fair number of these rules, it makes sense to put them all in a single chain, called ppp-out. # ipchains -N ppp-out # ipchains -A output -i ppp0 -j ppp-out # Minimum delay for web traffic & telnet. # ipchains -A ppp-out -p TCP -d proxy.virtual.net.au 8080 -t 0x01 0x10 # ipchains -A ppp-out -p TCP -d 0.0.0.0 telnet -t 0x01 0x10 # Low cosr for ftp data, nntp, pop-3: # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 ftp-data -t 0x01 0x02 # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 nntp -t 0x01 0x02 # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 pop-3 -t 0x01 0x02 # There are a few restrictions on packets coming in the ppp0 interface: let's create a chain called `ppp-in': # ipchains -N ppp-in # ipchains -A input -i ppp0 -j ppp-in # Now, no packets coming in ppp0 should be claiming a source address of 192.168.1.*, so we log and deny them: # ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY # I allow UDP packets in for DNS (I run a caching nameserver which forwards all requests to 203.29.16.1, so I expect DNS replies from them only), incoming ftp, and return ftp-data only (which should only be going to a port above 1023, and not the X11 ports around 6000). # ipchains -A ppp-in -p UDP -s 203.29.16.1 -d $LOCALIP dns -j ACCEPT # ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 1024:5999 -j # ACCEPT # ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 6010: -j # ACCEPT # ipchains -A ppp-in -p TCP -d $LOCALIP ftp -j ACCEPT # Finally, local-to-local packets are OK: # ipchains -A input -i lo -j ACCEPT # Now, my default policy on the input chain is DENY, so everything else gets dropped: # ipchains -P input DENY # NOTE: I wouldn't set up my chains in this order, as packets might get through while I'm setting up. Safest is usually to set the policy to DENY first, then insert the rules. Of course, if your rules require DNS lookups to resolve hostnames, you could be in trouble. ----------------------------------- -- ---------------------------------------------------------------------- REALITY.SYS corrupted: Reboot universe? (Y/N/Q) ....Debian GNU/Linux ---------------------------------------------------------------------- Reply with subject 'request key' for PGP public key. KeyID 0xA9E087D5