TITLE: Firewall.txt LFS VERSION: any Kernel >= 2.4.9 iptables >= 1.2.3 AUTHOR: Henning Rohde Henning.Rohde(at)uni-bayreuth.de SYNOPSIS: Question: What's a firewall? Answer: a fire-resistant wall separating a building into departments, designed to prevent the spread of fire And on Networks? A box that restricts the malicious (eg crackers, worms, trojans) out of your intranet. How Do I build one? fetch iptables and read the following: Personally I prefer the following definition: Answer: A wall of fire that only the Saints can pass through! @Networks: Just a box, that permits only sane packets to pass! HINT: -------------- |Introduction| -------------- The general purpose of a firewall is to save the labour of securing every box by securing a single firewall. This means that the firewall is a single point of failure, but it makes the admin's life a lot easier. But please, don't assume that having a firewall makes careful configuration redundant! If you knew every daemon or service on every machine was correctly configured and trustworthy, and trusted every user accessing your services to cause no harm, you wouldn't need to do firewalling! But if you'd like to choose which services are accessible only from your intranet, which machines or applications are allowed to have internet access, or if you don't trust some of your apps or users, you might benefit by using a firewall. When you read the word "firewall" there's more than one way to interpret it: a) "Personal Firewall": Program sold by e.g., Symantec, that is claimed to secure a home / desktop-pc with internet access. Quite relevant for users being always online with (flat rate) broadband links. b) Firewall as it was originally meant: A box placed between the internet and intranet doing, besides routing, nothing but protecting the intranet. This could include the function of masquerading: rewriting IP-headers of the packets it routes from clients with private IP-adresses onto the internet, so that they seem to come from the firewall itself. c) Firewall offering services: Some old box you may have retired and nearly forgotten, doing (B), but offering a bunch of services, e.g., web-cache, mail, etc. This may be very commonly used for home networks, but it severely violates some principles of (B). d) Firewall with a demilitarized zone [not described here]: Doing (B), but giving public access to some branch of your network, that is, because of public IP's and a physically separated structure, neither considered to be part of the inter- nor intranet. Here those servers are connected that must be easily accessible from both the inter- and intranet. The firewall protects them all. e) Packetfilter / partly accessible net [only partly described here, see (C)]: Doing (B) but permitting only selected services to be accessible, sometimes only by selected internal users or boxes; mostly used in highly secure business contexts, sometimes by distrusting employers. This was the common configuration of a firewall at the time of the Linux 2.2 kernel. It's still possible to configure a firewall this way, but it makes the rules quite complex and lengthy. ------------ |DISCLAIMER| ------------ I AM NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THIS DOCUMENT. This document is meant as an introduction to how to setup a firewall. I am not, nor do I pretend to be, a security expert. ;-) I am just some guy who still has not read enough and whose computers still like to play tricks on him if he wants to tweak them. ;-) Please, I am writing this to help people get acquainted with this subject, and I am not ready to stake my life on the accuracy of what is in here. (Taken from www.linuxdoc.org/HOWTO/Firewall-HOWTO.html, slightly modified) FIREWALL-SECURITY IS A COMPLEX ISSUE THAT REQUIRES GOOD CONFIGURATION. The scripts quoted here are not at the very least meant to give you the one and perfect firewall, being perfect until the universe collapses. They may not fit into any imaginable configuration and may not prevent any imaginable attack. The purpose of this text is simply to give you a hint on how to get started with firewalling. Customization of these scripts for your specific situation is likely to be necessary for an optimal configuration, but you should make a serious study of the iptables documentation and firewalling in general before hacking away. Have a look at Appendix I. There you'll find a list of URLs that contain quite comprehensive information about building your own firewall. -------------------------------------- |Getting a firewalling-enabled Kernel| -------------------------------------- If you want your Linux-Box to do firewalling you must first ensure that you have an appropriate kernel and the appropriate tools: But, before you do a 'make menuconfig', consider patching your kernel with the latest iptables enhancements. To get them, download the latest version of iptables from http://netfilter.samba.org. Having current kernel sources in /usr/src/linux, unpack iptables and 'cd' into its top-level directory. Now enter 'make pending-patches', as an user who is allowed to patch the kernel. There's no need to apply every patch, but e.g. the ipt_REJECT-checkentry-patch could be sensible, depending on your needs. Applying a patch may result in errors, mostly because the hooks for the patches have changed or because the runme script doesn't recognize that a patch has already been incorporated. If you do get errors don't worry too much; the important thing is that iptables has scanned the kernel for the already accepted / incorporated patches. The default kernel should be adaequate for most needs! Now configure the kernel: Personally I prefer to have a maximally modularized kernel, but for highest security you could configure the kernel with this code built in: Networking options: Network packet filtering = CONFIG_NETFILTER IP: TCP/IP networking = CONFIG_INET IP: advanced router = CONFIG_IP_ADVANCED_ROUTER IP: verbose route monitoring = CONFIG_IP_ROUTE_VERBOSE IP: TCP Explicit Congestion Notification support = CONFIG_INET_ECN IP: TCP syncookie support = CONFIG_SYN_COOKIES IP: Netfilter Configuration: every option = CONFIG_IP_NF_* BUT NO ipchains- and ipfwadm-compatibility. w\ CONFIG_IP_NF_COMPAT_* Although you are unlikely to have enabled it, please make sure not to select "Fast switching" w\ CONFIG_NET_FASTROUTE because it would currently bypass your firewalling-rules. Now compile and install your new kernel, update your bootloader and reboot. ------------------- |Building iptables| ------------------- Before compiling you might want to edit the Makefile to adapt install-dir's. Now compile and install iptables via 'make && make install'. ----------------------------------------- |Now we can start to build your Firewall| ----------------------------------------- (A) A Personal Firewall is supposed to let you access the all services offered on the internet, but keep your box secure and your data private. Below is a slightly modified version of Rusty Russel's recommendation, (http://netfilter.samba.org/unreliable-guides/packet-filtering-HOWTO): #!/bin/sh ##/etc/init.d/firewall # Insert connection-tracking modules (not needed if built into kernel). modprobe ip_tables modprobe iptable_filter modprobe ip_conntrack modprobe ip_conntrack_ftp modprobe ipt_state modprobe ipt_LOG # free output on any interface to any ip for any service (equal to -P ACCEPT) iptables -A OUTPUT -j ACCEPT # permit answers on already established connections # and permit new connections related to established ones (eg active-ftp) iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Log everything else: What's the latest exploitable vulnerability? iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT " # set a sane policy: everything not accepted > /dev/null iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP # be verbose on dynamic ip-adresses (not needed in case of static IP) echo 2 > /proc/sys/net/ipv4/ip_dynaddr # disable ExplicitCongestionNotification - too many routers are still ignorant echo 0 > /proc/sys/net/ipv4/tcp_ecn His script is quite simple, but simply surfing the internet you are unlikely to exceed its limits. Even if you have daemons / services running on your box, these should be inaccessible everywhere but on your box itself. The case to be cautious about is misconfigured daemons that could broadcast to the public to announce their service. If you have such daemons (e.g., cups, samba) running and if you are not confident in their configuration, restrict OUTPUT and INPUT, see (C) and (E). (B) A true Firewall has two interfaces, one connected to an intranet, in this example, eth0, and one connected to the internet, here, ppp0. To provide the maximum security against the box itself being broken into, e.g., by exploiting an offered service, make sure that there are no servers running on it, especially not X11 et al., and, as a principle, that it does not itself access any services: #!/bin/sh ##/etc/init.d/firewall echo echo -n "You're using the example-config " echo "for a setup of a firewall " echo -n "from the firewalling-hint " echo "written for LinuxFromScratch. " echo -n "This example is far from being " echo "complete, it is only meant " echo "to be a reference. " echo -n "Firewall security one could rely " echo "on is a complex issue, " echo -n "that exceeds the scope of the " echo "quoted configuration rules. " echo -n "You can find some quite " echo "comprehensive information " echo "about firewalling at Appendix I of " echo -n "http://hints.linuxfromscratch.org/hints/firewall.txt" echo "." echo "Be cautious!" modprobe ip_tables modprobe iptable_filter modprobe ip_conntrack modprobe ip_conntrack_ftp modprobe ipt_state modprobe iptable_nat modprobe ip_nat_ftp modprobe ipt_MASQUERADE modprobe ipt_LOG modprobe ipt_REJECT # needed for (C), example 4 # allow local-only connections iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # allow forwarding iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m state --state NEW -i ! ppp+ -j ACCEPT # do masquerading (not needed if intranet is not using private ip-adresses) iptables -t nat -A POSTROUTING -o ppp+ -j MASQUERADE # Log everything for debugging (last of all rules, but before DROP/REJECT) iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT " iptables -A FORWARD -j LOG --log-prefix "FIREWALL:FORWARD" iptables -A OUTPUT -j LOG --log-prefix "FIREWALL:OUTPUT " # set a sane policy iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP # be verbose on dynamic ip-adresses (not needed in case of static IP) echo 2 > /proc/sys/net/ipv4/ip_dynaddr # disable ExplicitCongestionNotification echo 0 > /proc/sys/net/ipv4/tcp_ecn # activate TCPsyncookies echo 1 > /proc/sys/net/ipv4/tcp_syncookies # activate Route-Verification = IP-Spoofing_protection for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done # activate IP-Forwarding echo 1 > /proc/sys/net/ipv4/ip_forward With this script your net should be sufficiently secure against external attacks: your intranet should be invisible because it's masqueraded or, at least, no one should be able to setup a new connection to its services, and your firewall should be immune because there are no services running that a cracker could attack. If you are in the need of stronger security (e.g., against DOS, connection highjacking, spoofing, etc.) see Appendix.1 and start to read a bit! (C) This scenario is not too different from (B), but you'd like to offer some services to your intranet. This gets relevant when you want to admin your box from another host on your intranet or use it as a proxy or a nameserver. Be cautious: every service you do offer and have enabled makes your setup more complex and your box less secure. See introduction to (B)! If the services you'd like to offer do not need to access the internet themselves, like an internal-only mail- or name-server, it's quite simple and should still be acceptable from a security standpoint. Just add the following lines _before_ the logging-rules of script (B): iptables -A INPUT -i ! ppp+ -j ACCEPT iptables -A OUTPUT -o ! ppp+ -j ACCEPT If your daemons have to access the web themselves, like squid would need to, you could open OUTPUT generally and restrict INPUT. iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -j ACCEPT Personally I am not so confident in the configuration of my own daemons that I would feel comportable with this, I think that this way it is too risky. Every misconfigured daemon and any trojan could easily open a connection to the public and expose private data. As a result, I prefer to restrict not only INPUT but both INPUT and OUTPUT on all ports except those that it's absolutely necessary to have open. Which ports you have to open depends on your needs: you will find them by looking at the FIREWALL-lines in your log-files. Have a look at the following examples: 1) Squid is requesting data: iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT 2) Your caching-nameserver (e.g., dnscache) does its lookups via udp: iptables -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -A INPUT -p udp --sport 53 -m state --state ESTABLISHED -j ACCEPT 3) Alternativly, if you want to ping your box to ensure it's still alive: iptables -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT iptables -A OUTPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT These are only examples to show you some of the capabilities of the new firewalling-code in Linux-Kernel 2.4. Have a look at the man-page of iptables. There you will find more of them. The port-numbers you'll need for this can be found in /etc/services, if you didn't find them in your logfile. If you add any of your offered or accessed services such as the above, maybe even in FORWARD and for intranet-communication, and delete the general clauses, you get an old fashioned packet filter, not unlike that one mentioned in (E). 4) If you are frequently accessing ftp-servers or enjoy chatting you might notice a certain delay because some oldfashioned implementations of these daemons insist on querying an identd on your box for your username. Although there's no harm in this, I wouldn't recommend using an identd, as many of them are known to be vulnerable. To avoid these delays you could reject the requests with a 'tcp-reset': iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset iptables -A OUTPUT -p tcp --sport 113 -m state --state RELATED -j ACCEPT 5) To log and drop invalid packets, mostly harmless packets that came in after netfilter's timeout, sometimes scans. iptables -I INPUT 1 -p tcp -m state --state INVALID -j LOG \ --log-prefix "FIREWALL:INVALID" iptables -I INPUT 2 -p tcp -m state --state INVALID -j DROP 6) Anything coming from the outside should not have a private address, this is a common attack called IP-spoofing: iptables -t nat -A PREROUTING -i ppp+ -s 192.168.0.0/16 -j DROP iptables -t nat -A PREROUTING -i ppp+ -s 10.0.0.0/8 -j DROP iptables -t nat -A PREROUTING -i ppp+ -s 172.16.0.0/12 -j DROP 7) To simplify debugging and be fair to anyone who'd like to access a service you have disabled, purposely or by mistake, you should REJECT those packets that are dropped. Obviously this must be done directly after logging as the very last lines before the packets are dropped by policy: iptables -A INPUT -i eth+ -j REJECT iptables -A OUTPUT -p icmp --icmp-type 3 -j ACCEPT --------- |THE END| --------- Finally, I'd like to remind you of one fact we must not forget: The effort spent attacking a system corresponds to the value the cracker expects to gain from it. If you are responsible for such valuable assets that you expect great effort to be made by potential crackers, you hopefully won't be in need of this hint! Be cautious! Henning Rohde (Henning.Rohde@uni-bayreuth.de) PS: And always do remember: SecureIT is not a matter of a status-quo but one of never stopping to take care! PPS: If any of these scripts fail, please tell me. I will try to trace any faults. -------- |THANKS| -------- Jeff Bauman jbauman(at)adsl-63-193-249-142.dsl.snfc21.pacbell.net He calls himself to be paranoid, at least in matters of security; ;-) I'd like to thank him for our discussion about security-related philosophies and furtherly for reviewing the hint and for giving not only a bit of help with the fine points of wording. ------------ |APPENDICES| ------------ (1) Nowadays, we must face the threat of denial of service attacks (DoS) even against private users (this seems to be quite common if you do online-gaming), trojans (read on IRC for commands), and worms exploiting the internet as if someone was doing a blitzkrieg. There may be ways to protect both your router and your intranet, but any solution I'm able to give here could become insufficent tomorrow and would give you a false sense of security. If you are really concerned, this is not the document to help you out! But have a look, here's where I'd suggest you start reading: http://netfilter.samba.org/unreliable-guides http://netfilter.samba.org/netfilter-faq.html http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html (IIRC outdated!) http://www-106.ibm.com/developerworks/security/library/s-fire.html +s-fire2.html http://www.interhack.net/pubs/fwfaq/ http://csrc.nist.gov/isptg/html/ISPTG-6.html http://www.linuxsecurity.com/docs/ http://www.little-idiot.de/firewall (German & outdated, but very comprehensive) http://www.linuxgazette.com/issue65/stumpel.html http://linux.oreillynet.com/pub/a/linux/2000/03/10/netadmin/ddos.html http://staff.washington.edu/dittrich/misc/ddos http://ipmasq.cjb.net/ http://www.e-infomax.com/ipmasq http://www.circlemud.org/~jelson/writings/security/index.htm http://www.securityfocus.com http://www.cert.org/tech_tips/ http://www.uni-siegen.de/security/pointers.html http://security.ittoolbox.com/ http://www.linux-firewall-tools.com/linux/ http://logi.cc/linux/athome-firewall.php3 http://www.insecure.org/reading.html http://www.robertgraham.com/pubs/firewall-seen.html If a link proves to be dead or if you think I missed one, please mail! (2) If you need to turn firewalling off, this script will do it: #!/bin/sh ##/etc/init.d/firewall.stop # deactivate IP-Forwarding echo 0 > /proc/sys/net/ipv4/ip_forward iptables -Z iptables -F iptables -t nat -F PREROUTING iptables -t nat -F OUTPUT iptables -t nat -F POSTROUTING iptables -t mangle -F PREROUTING iptables -t mangle -F OUTPUT iptables -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT (3) If you'd like to have a look at the chains your firewall consists of and the order in which the rules take effect: #!/bin/sh ##/etc/init.d/firewall.status echo "iptables.mangling:" iptables -t mangle -v -L -n --line-numbers echo echo "iptables.nat:" iptables -t nat -v -L -n --line-numbers echo echo "iptables.filter:" iptables -v -L -n --line-numbers