I am working on a ip tables firewall for linux. Can anyone help me with what I need to complete my firewall. This is a web server. 1) I want to block all incoming ports, block all forward ports and leave open all outgoing ports 2) I want to prevent bomb attacks 3) I want to prevent denail of service attacks 4) I want to leave open only the ports I want to be used Does anyone have any suggestions as to how I can change this kind of firewall configuration to be what I need for an Internet web server. # IPTABLES Firewall Example (you are here) # Red Hat Linux firewall using iptables # Revised December, 2002 # configured by Dennis G. Allard and Don Cohen, http://oceanpark.com # This script has been used on servers running Red Hat 7.3 and 8.0 # # Permission to copy is granted provided that credit is given # to the author and whatever HOWTOs are used to understand this # stuff. # # No warranty is implied. Use at your own risk!! # Using this script # ----------------- # # I save this file as /etc/sysconfig/iptables-precursor # and then source it and run iptables-save to create # /etc/sysconfig/iptables, which is an input file # consumed by the script /etc/rc.d/init.d/iptables, # which in turn makes use of the script /sbin/iptables-restore. # # Before mucking with setting up iptables, you should # disconnect the machine from the internet. Examine # and understand the current set of iptables rules # before you reconnect to the internet. # # To configure the set of iptables rules: # # /etc/rc.d/init.d/iptables stop # source /etc/sysconfig/iptables-precursor # # To save the current set of iptables rules for use at next reboot: # # iptables-save > /etc/sysconfig/iptables # # To dynamically restart iptables after modifying /etc/sysconfig/iptables: # # /etc/rc.d/init.d/iptables restart # # Note that /etc/rc.d/init.d/iptables is a script. You can read it to # gain understanding of how iptables uses iptables-restore to restore # iptables firewall rules at reboot. # # To examine the current set of rules in effect: # # /etc/rc.d/init.d/iptables status # # However, I prefer to show the current set of rules via: # # iptables -nvL -t filter # iptables -nvL -t nat # # or # # iptables -vL -t filter # iptables -vL -t nat # # # To configure iptables to be used at next system reboot: # # chkconfig --add iptables # # To see if iptables is currently configured to start at boot, do: # # chkconfig --list iptables # # (You might have to do chkconfig --del ipchains to remove ipchains) # # The rest of this file is derived from my old ipchains script. # # A word about routing # -------------------- # # Note that this web page does not discuss routing decisions. Routing # (see the 'ifconfig' and 'route' commands) decides which interface an # incoming packet will be delivered to, i.e. if a given packet will be # 'input' to this machine or be 'forwarded' to some interface for # delivery to another machine, say on an internal network. You should # have your routing configured before you attempt to configure your # firewall. # The network # ----------- # # This firewall is running on a gateway machine having multiple ethernet # interfaces, a public one, eth0, which is a DSL connection to an ISP, # and one or more internal ones, including eth1, which is assigned to # 192.168.0.1, an IP number on my internal private network. My public # network has static IP numbers 66.14.136.144 through 66.14.136.148. # Currently, all of my static IP numbers are assigned as virtual IPs to # interface eth0 of the firewall machine itself. For this reason, most # of the rules below are INPUT rules. Were I to route some of my public # static IP numbers to interfaces on one or more machines inside the # firewall on the internal network, I would modify certain rules to be # FORWARD rules instead of INPUT rules. I show some examples below of # FORWARD rules. # # The gateway at my ISP is 66.14.136.1. I run a few web servers on # 66.14.136.148, a DNS server on 66.14.136.144, and sendmail (someday # hopefully soon to be qmail) on 66.14.136.145. I sometimes run dnscache # on 66.14.136.145. # # Using this file in a more complex network would require some # modifications. Particular attention would need to be given to using # the right the IP numbers and interfaces, among other things. # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I 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: # # ACCEPT all UDP packets for certain UDP services # # Currently the only UDP connections I accept are to my secure DNS # server, tinydns. For an explanation of why tinydns is secure, see: # http://www.faqts.com/knowledge_base/view.phtml/aid/8739/fid/699. # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # # SYN packets are specified via the -syn flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets that are part of existing connections # # DENY 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. # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. This is done via 'Stateful Packet Inspection' provided by the # netfilter functionality added to linux as of kernel 2.4. By stopping all # other packets in their tracks, we limit attempts to attack our internal # network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3- inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/tutorials/blueflux/iptables- tutorial.html # # begin oceanpark.com firewall rules (using iptables) # --------------------------------------------------- # Here we go... # Configure default policies (-P), meaning default rule to apply if no # more specific rule below is applicable. These rules apply if a more specific rule below # is not applicable. Defaults are to DROP anything sent to firewall or internal # network, permit anything going out. iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # Flush (-F) all specific rules iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT # iptables -F -t nat # The rest of this file contains specific rules that are applied in the order # listed. If none applies, then the above policy rules are used. # Forward all packets from eth1 (internal network) to eth0 (the internet). # iptables -A FORWARD -i venet0 -o eth0 -j ACCEPT # Forward packets that are part of existing and related connections from eth0 to eth1. # iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED - j ACCEPT # Permit packets in to firewall itself that are part of existing and related connections. # iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # Note, in the above two rules, a connection becomes ESTABLISHED in the # iptables PREROUTING chain upon receipt of a SYNACK packet that is a # response to a previously sent SYN packet. The SYNACK packet itself is # considered to be part of the established connection, so no special # rule is needed to allow the SYNACK packet itself. # Allow all inputs to firewall from the internal network and local interfaces # iptables -A INPUT -i venet0 -s 0/0 -d 0/0 -j ACCEPT # iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT # Enable SNAT functionality on eth0 # # SNAT is used to map private IP numbers of interfaces on the internal LAN to one of # my public static IP numbers. SNAT performs this mapping when a client running # on one of the internal machines initiates a TCP connection (SYN) through eth0. # iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth0 -j SNAT --to- source 66.14.136.144 # Alternative to SNAT -- MASQUERADE # # If your firewall has a dynamic IP number because it connects to the # internet itself via DHCP, then you probably cannot predict what the IP # number is of your firewall's interface connected to the internet. In # this case, you need a rule like the following that assigns the (an) IP # number associated with eth0 to outgoing connections without you needing # to know in advance (at time of writing this rule) what that IP number is: # # iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE # # Note that the above SNAT and MASQUERADE rules are applicable # independent of how a host on the internal network is assigned its own # internal IP number. The host could be assigned a static IP number on # an internal nonpublic network (e.g. 10. or 192.168.) or it could be # itself assigned a dynamic IP number from your own DHCP server running # on the firewall, or it could even have a public static IP number. # However, it seems unlikely that one would want to assign a public IP # number to a host and then proceed to hide that number from the public. # Deny any packet coming in on the public internet interface eth0 # which has a spoofed source address from our local networks: # iptables -A INPUT -i eth0 -s 66.14.136.144/32 -j DROP # iptables -A INPUT -i eth0 -s 66.14.136.145/32 -j DROP # iptables -A INPUT -i eth0 -s 66.14.136.146/32 -j DROP # iptables -A INPUT -i eth0 -s 66.14.136.147/32 -j DROP # iptables -A INPUT -i eth0 -s 66.14.136.148/32 -j DROP # iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP # iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP # Accept all tcp SYN packets for protocols SMTP, HTTP, HTTPS, and SSH: # (SMTP connections are further audited by our SMTP server) iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 1 -- syn - j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 20 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 21 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 22 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 25 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 43 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 53 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 63 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 70 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 80 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 110 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 443 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 465 -- syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d xxx.xxx.xxx.xxx --destination-port 3306 -- syn -j ACCEPT # Notice that the above rules are all INPUT rules. My current network # does not require me to make use of FORWARD rules, since I run all # publicly accessible servers directly on my firewall machine. But I # promised above in the description of my network to give examples of # rules used when there are servers running on machines on the internal # network. Following are examples of FORWARD rules I would use if I ran # mail, web, and ssh servers on machines on the internal network inside # the firewall. # # iptables -A FORWARD -p tcp -s 0/0 -d 66.14.136.145/32 --destination-port 25 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d 0/0 --destination-port 80 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d 0/0 --destination-port 443 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # The first of the above four rules would be used if my routing # delivered packets having destination 66.14.136.145 to any interface # connected to my internal network. The second through fourth of the # above four rules would be used if I my routing delivered packets # having some public static IP as destination to some internal interface # running a server listening to HTTP, HTTPS, or SSH ports. The # difference between an INPUT rule and a FORWARD rule is that an INPUT # rule applies to packets that are 'input' to this machine (the machine # on which these iptables rules are installed), whereas a FORWARD rule # applies to packets that are being 'fowarded', i.e. to packets that are # passing through this machine to some other machine, such as a machine # on my internal network. # # If I ran my mail server on an internal machine, I would no longer # need my previous INPUT rule for 66.14.136.145 and would use the above # FORWARD rule instead # 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. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # 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 # waiting 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 to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP port unreachable' response. #-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 iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP # end oceanpark.com firewall rules (using iptables) -- Greg Tibbetts AAGT Hosting
