# Red Hat Linux 7.1 firewall # May, 2001 # configured by Dennis G. Allard, http://oceanpark.com # # Permission to copy is granted provided that credit is given # to the author and whatever HOWTOs are used to understand this # stuff. # # No warrenty is implied. Use at your own risk!! # This file is /etc/sysconfig/ipchains, intended for # consumption by the script /etc/rc.d/init.d/ipchains, # which makes use of the script /sbin/ipchains-restore. # In Red Hat 7.1, the man page for ipchains and for # ipchains-restore does not document the syntax of this # file. I had to read the script to understand better # what is going on. # The firewall that the Red Hat installer set up for me # in response to my request for a high level of security # was too restrictive. I couldn't find any GUI tool # in either GNOME or KDE to reconfigure the firewall, so # I manually edited this file. I forget how I found out # about all the knowledge one needs to deduce the above # file locations. Comes with the trade. # Preliminaries # ------------- # # To permit machines internal to your network to commuicate # with the internet, make sure that IP Forwarding is enabled. # Do this in Redhat by adding FORWARD_IPV4="yes" to # /etc/sysconfig/network. For example, do # # echo 1 > /etc/sysconfig/network # # Prevent 'smurfing' via: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # You can place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # For UDP, explicitly accept certain UDP packets (in # my case, DNS requests). For TCP, only accept # SYN packets for the specific services we wish to # make visible to the public internet as well as # all other TCP packets. SYN packets are specified # via the -y flag in the input rules defined below. # # DENY all other UDP packets. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets. # # In other words, we allow any TCP packet through # that is part of an established TCP connection, but # we are very selective in just which connections we # permit to be made to start off with. # # An explanation of SYN packets that I found somewhere # on the net goes as follows (and I quote): # # TCP connections require packets going in both directions # to work at all. The solution is to block only the packets # used to request a connection. These packets are called # SYN packets (ok, technically they're packets with the SYN # flag set, and the FIN and ACK flags cleared, but we call # them SYN packets). By disallowing only these packets, we # can stop attempted connections in their tracks. # # I do wonder if this permits some form of man-in-the-middle # attack that somehow hijacks an established TCP connection. # That topic is over my head for now and I will just # mention my concern and happily proceed... # oceanpark.com firewall rules (using ipchains) # --------------------------------------------- # Tell ipchains-restore what default policies to use... :input ACCEPT :forward ACCEPT :output ACCEPT # The above will accept anything not prevented by the following rules. # Deny any packet coming in on the public internet interface eth0 # which has source address of our local network (attempt to spoof an # address which should never come from any place but eth1) or which # claims to be from the reserved local loop network 127.0.0.0. -A input -i eth0 -s 198.211.65.0/24 -j DENY -A input -i eth0 -s 127.0.0.0/8 -j DENY # Accept all tcp SYN packets for protocols SMTP, HTTP, and SSH # Note, SMTP connections are further audited by my SMTP server -A input -s 0/0 -d 198.211.65.1 25 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT # Permit DNS queries... # I don't know why the following line was configured by Red Hat install # -A input -s 206.196.68.50 53 -d 0/0 -p udp -j ACCEPT # I had to add the following line to make my DNS server honor requests # from the public internet. -A input -s 0/0 -d 0/0 53 -p udp -j ACCEPT # For Costit, a custom server running here. -A input -s 0/0 -d 0/0 8080 -p tcp -y -j ACCEPT # Open up IMAP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 143 -p tcp -y -j ACCEPT # Open up FTP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 20 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT # Allow all inputs from the internal and local interfaces -A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT -A input -s 0/0 -d 0/0 -i lo -j ACCEPT # If we wanted to use masqueading (can do even for legit internal IPs) # -A forward -s 198.211.65.78 -j MASQ Finally, DENY all connection requests to any UDP port not yet provided for and all SYN connection requests to any TCP port not yet provided for. Using DENY instead of REJECT means that no 'ICMP port unreachable' response is sent back to the client attempting to connect. I.e., DENY just ignores connection attempts. Hence, use of DENY causes UDP connection requests to time out and TCP connection requests to hang. Note that there is a fundamental difference between UDP and TCP protocols. With UDP, there is no 'successful connection' response. With TCP, there is. So an attacking client will be left in the dark about whether or not the denied UDP packets arrived and will hang awaiting for a response from denied TCP ports. An attacker will not be able to immediately tell if UDP connection requests are simply taking a long time, if there is a problem with connectivity between the attacking client and the server, or if the packets are being ignored. This increases the amount of time it takes for an attacker to scan all UDP ports. Similarly, TCP connection requests will seem to take forever (literally). -A input -s 0/0 -d 0/0 -p udp -j DENY -A input -s 0/0 -d 0/0 -p tcp -y -j DENY # end of firewall rules |