Voila! No machines can connect to your machine with TCP, but you can make outbound connections and the associated packets will be allowed back in. You can't be a server (no SSH to your machine, for example) but all outbound TCP stuff should work fairly well.

Well, that's true about most 'well behaved' TCP-based protocols. Some protocols like to use more than one port. FTP is the classic example of a bastardly-designed protocol. Each time you type 'get', 'put', or 'ls' a new TCP connection is initiated to snag the data.

Note also that even though outsiders can't connect to your TCP ports, scanning tools such as Nmap will be able to see that the port is open if they are used in any mode other than straight TCP connection scanning. Newer Nmap versions use stealth scanning by default when run as root.

If the protocol you use wants to have the client (your newly firewalled machine) make an additional connection to the server, then your --syn firewall won't be a problem. However if it wants to have the server contact the client, these connections will be denied.

Protocols that create these ephemeral side connections include many P2P protocols, and most notably FTP. Most of these offer both a 'client connects to server' and 'server connects back to client' option. In the case of FTP, the former is called "Passive", while the latter is called "Active". Active was the original (really annoying for firewalls and proxies) model, and Passive has been favoured for some time now. Most FTP clients let you choose Passive if it's not already the default. For example typing pftp instead of ftp on the command line, or including --passive-ftp as an argument to wget.[3]

Now, to be a bit more restrictive, let's block UDP as well. UDP is a connectionless protocol, so it's harder to proxy and firewall. However it's also less commonly used. DNS is the the most important UDP protocol. Without DNS you're going to need to memorise many IP addresses, so we best open this up.

DNS servers live on UDP port 53.[4] Our machine will need to send packets to port 53 on one or more DNS servers, and receive packets that come from port UDP 53. So, restricting on the source port (the port on the DNS server) you'd have

  # iptables -A INPUT -p udp --source-port 53 -j ACCEPT

This will allow any DNS servers to reply to you, which may be helpful if you get your DNS servers from DHCP and want to be lazy. If you want to hard code your DNS server's IP addresses to be most restrictive, you can use the following

  # iptables -A INPUT --source DNS.SVR1.IP.ADDR -p udp --source-port 53 -j ACCEPT
  # iptables -A INPUT --source DNS.SVR2.IP.ADDR -p udp --source-port 53 -j ACCEPT

If your machine needs to get an IP address from the network using BOOTP or DHCP, then you'll need the following rule as well:

  # iptables -A INPUT -p udp --destination-port 68 -j ACCEPT

Any packets that aren't for DNS or BOOTP/DHCP will be dropped by the INPUT chain's policy.

What services are likely to brake when you're blocking UDP? Most streaming media uses UDP for it's highest-speed connections, but may offer TCP based connections as well. Filesharing protocols such as NFS may die, but again may offer TCP versions that get around this limitation. It all depends on your setup.

Now we haven't listed which interfaces these rules apply on. If you want them to apply to all interfaces, this is probably good. However you should allow packets that go on the localhost interface to work universally, lest you break some daemons that expect to be able to communicate within your machine, or features like SSH port forwarding. So, as the very first rule, you should include the following:

  # for interface in /proc/sys/net/ipv4/conf/*/rp_filter
      do
          echo 1> $interface
      done

  # iptables -A INPUT -i lo -j ACCEPT

The iptables rule says "allow any packets that come into localhost without any filtering". The for loop sets Reverse Path filtering on all interfaces, which will block packets that come in from the wrong interface.[5]

Lastly, we can lock down allowed ICMP packets, which are used in conjunction with TCP and UDP protocols to indicate error conditions and the like. Here I'll be a bit more permissive than may be necessary in order to fit the needs of a wider audience. To get a full list of possible ICMP codes, run iptables -p icmp --help. We'll allow the following types for greatest network stability:

 # iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
 # iptables -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
 # iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
 # iptables -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
 # iptables -A INPUT -p icmp --icmp-type redirect -j ACCEPT
 # iptables -A INPUT -p icmp --icmp-type router-advertisement -j ACCEPT
 # iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
 # iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

You may wish to exclude some of these, such as echo-request (prevent your machine from being pinged), redirect and router-advertisement (if you have only one router, and no dynamic routes.)

Next week I'll bring this all together in one big script and show you how to let these rules be created at reboot automatically.[6]

NOTES:

[1] I much prefer to have my firewall rules explicitly define what packets are allowed to go in *and go out*. This helps block outbound access that could be created by trojans, viruses, or evil hax0rs.

[2] Iptable's predecessors and other firewall/filtering products have also used this trick for years.

[3] Netfilter has modules that you can load as well to support specific protocols such as FTP or IRC that do wacky things like this.

[4] They may also listen on TCP port 53 for larger queries and DNS zone transfers, but outbound TCP is already covered by our previous --syn rule.

[5] For more information about this and other helpful /proc interface files, see Firewalling proc entries

[6] I understand the irony of having a 10 minute firewall discussion spread out over two weeks...

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. In the rare times where he gets uninterrupted time to write, he never seems to stop. The muses smiled upon him today. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2003

This is the July 03, 2003 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.