HOWTO Iptables for newbiesFrom Gentoo Linux WikiIptables is a userspace command line program that can plug into netfilter (a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. ) Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel.
ContentsIntroductionI found the iptables documentation available to be severely newbie unfriendly. Most assumed a more than working knowledge of ipchains and pretty much picked up from there. Usually my approach to a new endeavor is that I want the option of getting up and going quickly, with minimal explanation. Afterwards I go back to read over more advanced options. This howto is designed with that in mind. It will show you how to setup basic functionality get you connected quickly and then it will incrementally show how to add policies and rules that can help a safe connection.
QuickStart GuideCreate basic iptable functionality.
Kernel SupportCheck to see if you have kernel support for netfilter / iptables
zgrep -i netfilter /proc/config.gz
CONFIG_NETFILTER=y
or
grep -i netfilter /usr/src/linux/.config
CONFIG_NETFILTER=y
If not then you'll need to compile iptables support into the kernel.
You can either do this manually with the kernel sources:
cp /usr/src/linux/.config /etc/linux-config.bak
emerge sync && USE=symlink emerge -nk gentoo-sources
cd /usr/src/linux
cp /etc/linux-config.bak /usr/src/linux/.config
make menuconfig
Warning: These commands can be considered as being "bad practice" and should not be used relentlessly. You might consider doing a make oldconfig before the make menuconfig, but it's still not recommended to copy configurations from one kernel version to another.
Alternatively, you will probably find it easier to use genkernel. Either way, once you get to the menu configuration you will need to enable to following:
Linux Kernel Configuration: Netfilter
|
|
Select the IPv6 option only if you need it.
Linux Kernel Configuration: Netfilter
|
|
Edit Above (Kernel 2.6.20): "Reject Target Support" needs to be also enabled or the rules below will not load.
Linux Kernel Configuration: Netfilter
|
|
If you intend to load iptables as a module,
Linux Kernel Configuration: Loadable Module Support
|
|
Build the kernel:
make && make modules_install
If you're just a newbie (hence this guide) then just go ahead and enable all of the options as modules - if you don't upgrade the
kernel you won't even have to reboot to use iptables. Enable the various target/match support options also.
Because you'll likely want the iptables module to load every time you boot:
echo "ip_tables" >> /etc/modules.autoload.d/kernel-2.6
echo "iptable_filter" >> /etc/modules.autoload.d/kernel-2.6
echo "nf_conntrack" >> /etc/modules.autoload.d/kernel-2.6
echo "nf_conntrack_ipv4" >> /etc/modules.autoload.d/kernel-2.6
echo "xt_state" >> /etc/modules.autoload.d/kernel-2.6
echo "xt_tcpudp" >> /etc/modules.autoload.d/kernel-2.6
echo "ipt_REJECT" >> /etc/modules.autoload.d/kernel-2.6
update-modules
The first two lines enable basic iptables support; the remaining lines load modules required for specific matching and state tracking rules.
Basic iptables ConfigurationYou'll need to get the userland utilities. Don't forget to
modprobe ip_tables and
modprobe iptable_filter if you have built them as a module.
emerge iptables
The average home user might want something that accepts certain incoming connections but blocks everything else.
1. Save your current firewall rules iptables-save > /etc/iptables.bak
2. Open /etc/iptables.bak in your favorite text editor
3. Add the following rule(s) in appropriate order (according to your existing rules).
4. Restore all rules to be part of your current configuration
iptables-restore /etc/iptables.bak
5. Save the configurations:
/etc/init.d/iptables save
And then back up your working configuration in case you break something later you can quickly revert:
cp /var/lib/iptables/rules-save /var/lib/iptables/rules.working
Now check up your iptables start-up script before adding iptables to your default runlevel:
/etc/init.d/iptables start; /etc/init.d/iptables stop; /etc/init.d/iptables start
The reason we start, then stop, then start again is because we haven't yet started the iptables script...so we must set the “initialized” status before stopping. Stopping essentially erases all settings and puts you back to zero.
If everything works well and you don't seem to have lost access to the server, then you can add iptables to the default runlevel:
rc-update add iptables default
GUI AlternativesOr if you are so inclined, you can also configure iptables using the firestarter GUI (for GNOME users).
emerge firestarter
Note: net-firewall/firestarter in portage is masked, marked for removal on the 29th June 2007
or kmyfirewall (for KDE users)
emerge kmyfirewall
Another alternative is to use guarddog (QT).
emerge guarddog
Firewall HardeningIn the following, we're going to further secure our now functional firewall. By the time we are through we should have a set of tested rules and policies that will prevent not only attacks to our own computer, but also attacks from our computer to the internet. Protecting others from the possibility of being attacked by one of our compromised computers is an essential and often overlooked aspect of security and common internet courtesy. I would even say for the SOHO network this is the most important aspect. Normally virus infection is only a minor nuissance to a small network and rarely results in data loss....for us 100% *nix users it practically doesn't even exist. However, since small soho networks are often less secure than larger ones they are a favorite target for crackers looking for a “launchpad” for DoS attacks or other underhanded skullduggary.
The following is offered in a piecemeal fashion in a sequence that enables the easiest step by step testing. Each step may require that something be inserted before, after, or in the middle of our existing script. This was done so that (hopefully) your network will only go down for a brief period during setup. I've done it this way because I have assumed many of you (like me) have a standalone linux firewall/server. Since my preferred method is ssh, the network going down can be a PITA involving crawling under tables and such. If you're daring, you can just copy the script at the end and run it. It should be fully functional, but I have only tested it on my system so ymmv.
Setting up environment variablesWe will define our networks interfaces and various tools used in the script:
iptables ACCEPTSOk now we're going to set up the ACCEPTs which will allow us to communicate with our server. In reality this is very ill advised. A solid firewall policy should DENY then ACCEPT. But if you do that you lose all connections while you're testing so you're not sure if your ACCEPT rules work at all. So, though we are entering this first, it will be the second to last rule set in the final script.
File: accepts-firewall.sh
|
|
iptables DROP & REJECTNext we are going to define a couple of custom chains which will log DROP and REJECT events. This way we don't have to enter a separate line for each command entered. The logs will be sent to where your syslog default log messages are sent (usually /var/log/messages). Later I'm going to write a grep/sed script that will parse and organize these for easy viewing and set it as a daily cron job.
This should be inserted immediately after the above definitions. When you are done, run the script again. It should have no affect on functionality of the network since we're just setting definitions. But it will ensure that we have no errors thusfar.
File: logging-firewall.sh
|
|
iptables flushingOk, now that we see our devices are being detected properly, we are going to insert a flush commands. So that when our rules are assigned it will be done cleanly. These lines should be inserted after our utilities definitions, the last one being:
Local interfacesNow we're ready to start laying down some rules. First we are going to accept all packets from our loopback device if the ip address matches that of any of our local interfaces:
$IPT -A INPUT -i $LPDIF -s $LPDIP -j ACCEPT
$IPT -A INPUT -i $LPDIF -s $EXTIP -j ACCEPT
$IPT -A INPUT -i $LPDIF -s $INTIP1 -j ACCEPT
$IPT -A INPUT -i $LPDIF -s $INTIP2 -j ACCEPT
Blocking broadcastingNow we will block broadcasts both incoming and outgoing. This can prevent DoS attacks against us, as well as preventing our clients from being used to DoS someone else. This is part of what's called "Egress Protection". It's a do unto your neighbour sort of philosophy. If all SysAdmins followed this policy, than many of the more severe and costly DoS attacks would either not have occurred or been extremely limited.
# Blocking Broadcasts
$IPT -A INPUT -i $EXTIF -d $EXTBC -j DROPl
$IPT -A INPUT -i $INTIF1 -d $INTBC1 -j DROPl
$IPT -A INPUT -i $INTIF2 -d $INTBC2 -j DROPl
$IPT -A OUTPUT -o $EXTIF -d $EXTBC -j DROPl
$IPT -A OUTPUT -o $INTIF1 -d $INTBC1 -j DROPl
$IPT -A OUTPUT -o $INTIF2 -d $INTBC2 -j DROPl
$IPT -A FORWARD -o $EXTIF -d $EXTBC -j DROPl
$IPT -A FORWARD -o $INTIF1 -d $INTBC1 -j DROPl
$IPT -A FORWARD -o $INTIF2 -d $INTBC2 -j DROPl
Now test the script once more to ensure we have no syntax errors. Also notice that we are using our newly defined DROPl chain. This means that the dropped packets will be logged.
Block WAN to LANNext we are going to block WAN access to our LAN if not specifically intended for our ISP assign IP:
# Block WAN access to internal network
# This also stops nefarious crackers from using our network as a
# launching point to attack other people
# iptables translation:
# "if input going into our external interface isn't being sent to our isp assigned
# ip address, drop it like a hot potato"
$IPT -A INPUT -i $EXTIF -d ! $EXTIP -j DROPl
Tightening the internal LANWe're going to apply the same logic to our internal LAN. In other words, any packets not originating from our predefined internal network will be rejected:
# Now we will block internal addresses originating from anything but our
# two predefined interfaces.....just remember that if you jack your
# your laptop or another pc into one of these NIC's directly, you'll need
# to ensure that they either have the same ip or that you add a line explicitly
# that IP as well
# Interface one/internal net one
$IPT -A INPUT -i $INTIF1 -s ! $INTNET1 -j DROPl
$IPT -A OUTPUT -o $INTIF1 -d ! $INTNET1 -j DROPl
$IPT -A FORWARD -i $INTIF1 -s ! $INTNET1 -j DROPl
$IPT -A FORWARD -o $INTIF1 -d ! $INTNET1 -j DROPl
# Interface two/internal net two
$IPT -A INPUT -i $INTIF2 -s ! $INTNET2 -j DROPl
$IPT -A OUTPUT -o $INTIF2 -d ! $INTNET2 -j DROPl
$IPT -A FORWARD -i $INTIF2 -s ! $INTNET2 -j DROPl
$IPT -A FORWARD -o $INTIF2 -d ! $INTNET2 -j DROPl
Next we do some more Egress checking of outgoing packets and stop all icmp requests except for pinging:
# An additional Egress check
$IPT -A OUTPUT -o $EXTIF -s ! $EXTNET -j DROPl
# Block outbound ICMP (except for PING)
$IPT -A OUTPUT -o $EXTIF -p icmp --icmp-type ! 8 -j DROPl
$IPT -A FORWARD -o $EXTIF -p icmp --icmp-type ! 8 -j DROPl
Ok, where moving along now and we should test the script for errors.
PortsAssuming an all clear we're going to start plugging some of the more bothersome port holes:
# COMmon ports:
# 0 is tcpmux; SGI had vulnerability, 1 is common attack
# 13 is daytime
# 98 is Linuxconf
# 111 is sunrpc (portmap)
# 137:139, 445 is Microsoft
# SNMP: 161,2
# Squid flotilla: 3128, 8000, 8008, 8080
# 1214 is Morpheus or KaZaA
# 2049 is NFS
# 3049 is very virulent Linux Trojan, mistakable for NFS
# Common attacks: 1999, 4329, 6346
# Common Trojans 12345 65535
COMBLOCK="0:1 13 98 111 137:139 161:162 445 1214 1999 2049 3049 4329 6346 3128 8000 8008 8080 12345 65535"
# TCP ports:
# 98 is Linuxconf
# 512-515 is rexec, rlogin, rsh, printer(lpd)
# [very serious vulnerabilities; attacks continue daily]
# 1080 is Socks proxy server
# 6000 is X (NOTE X over SSH is secure and runs on TCP 22)
# Block 6112 (Sun's/HP's CDE)
TCPBLOCK="$COMBLOCK 98 512:515 1080 6000:6009 6112"
# UDP ports:
# 161:162 is SNMP
# 520=RIP, 9000 is Sangoma
# 517:518 are talk and ntalk (more annoying than anything)
UDPBLOCK="$COMBLOCK 161:162 520 123 517:518 1427 9000 9 6346 3128 8000 8008 8080 12345 65535"
After defining the environment variables all we have to do is a simple for loop to assign rules to them all:
echo -n "FW: Blocking attacks to TCP port"
for i in $TCPBLOCK;
do
echo -n "$i "
$IPT -A INPUT -p tcp --dport $i -j DROPl
$IPT -A OUTPUT -p tcp --dport $i -j DROPl
$IPT -A FORWARD -p tcp --dport $i -j DROPl
done
echo ""
echo -n "FW: Blocking attacks to UDP port "
for i in $UDPBLOCK;
do
echo -n "$i "
$IPT -A INPUT -p udp --dport $i -j DROPl
$IPT -A OUTPUT -p udp --dport $i -j DROPl
$IPT -A FORWARD -p udp --dport $i -j DROPl
done
echo ""
Ok, now with iptables each time we run the script it simply appends these to already existing chains...so things are probably getting a bit messy. For that reason we're going to jump to the beginning of our script....right after the enviroment variables for sed and grep, but before those of EXTIP and EXTBC and add a loop that deletes and flushes. This ensure we're working from a clean state. We didn't want to do that before because we couldn't have tested our script without either shutting down our connection or dropping our firewall completely. This script first sets all policies to DROP, than flushes and deletes our chains. In order to ensure that we can still ssh back into our server after a script restart we are going to append an INPUT chain for ssh. This should always be placed at the end of the script for now. This done in order to prevent a window from opening up while we reset rules which is a common error made:
# Deny than accept: this keeps holes from opening up
# while we close ports and such
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
# Flush all existing chains and erase personal chains
CHAINS=`cat /proc/net/ip_tables_names 2>/dev/null`
for i in $CHAINS;
do
$IPT -t $i -F
done
for i in $CHAINS;
do
$IPT -t $i -X
done
$IPT -A INPUT -i $INTIF1 -p tcp --dport 22 --syn -m state --state NEW -j ACCEPT
Sysctl'sRight afterwards we are going to activate the sysctl's for tcp_syncookies, icmp_echo_ignore_broadcasts, rp_filter, and accept_source_route. Heretofore many of the rules we've been "testing" haven't been able to actually work. In essence we were simply doing syntax error tests. Now our rules will be "for real":
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Source Address Verification
for f in /proc/sys/net/ipv4/conf/*/rp_filter;
do
echo 1 > $f
done
# Disable IP source routing and ICMP redirects
for f in /proc/sys/net/ipv4/conf/*/accept_source_route;
do
echo 0 > $f
done
for f in /proc/sys/net/ipv4/conf/*/accept_redirects;
do
echo 0 > $f
done
echo 1 > /proc/sys/net/ipv4/ip_forward
Now we're going to add ftp connection tracking so that we won't get PASV errors when emerging packages:
# Opening up ftp connection tracking
MODULES="ip_nat_ftp ip_conntrack_ftp"
for i in $MODULES;
do
echo "Inserting module $i"
modprobe $i
done
Basic Service NATNow back to end of our script, we are going to open up services for systems behind our firewall. I have included services such as IRC, MSN, ICQ, and NFS, FTP, domain, and time. And some others. The important thing to note is that these will ONLY be availabe BEHIND the firewall. So this will not enable someone to ftp into your LAN:
IRC='ircd'
MSN=1863
ICQ=5190
NFS='sunrpc'
# We have to sync!!
PORTAGE='rsync'
OpenPGP_HTTP_Keyserver=11371
# All services ports are read from /etc/services
TCPSERV="domain ssh http https ftp ftp-data mail pop3 pop3s imap3 imaps imap2 time $PORTAGE $IRC $MSN $ICQ $OpenPGP_HTTP_Keyserver"
UDPSERV="domain time"
echo -n "FW: Allowing inside systems to use service:"
for i in $TCPSERV;
do
echo -n "$i "
$IPT -A OUTPUT -o $EXTIF -p tcp -s $EXTIP --dport $i --syn -m state --state NEW -j ACCEPT
$IPT -A FORWARD -i $INTIF1 -p tcp -s $INTNET1 --dport $i --syn -m state --state NEW -j ACCEPT
$IPT -A FORWARD -i $INTIF2 -p tcp -s $INTNET2 --dport $i --syn -m state --state NEW -j ACCEPT
done
echo ""
echo -n "FW: Allowing inside systems to use service:"
for i in $UDPSERV;
do
echo -n "$i "
$IPT -A OUTPUT -o $EXTIF -p udp -s $EXTIP --dport $i -m state --state NEW -j ACCEPT
$IPT -A FORWARD -i $INTIF1 -p udp -s $INTNET1 --dport $i -m state --state NEW -j ACCEPT
$IPT -A FORWARD -i $INTIF2 -p udp -s $INTNET2
done
echo ""
Now we're done all that's left is allowing us to ping the outside world by opening up pinging out of the firewall:
# Allow to ping out
$IPT -A OUTPUT -o $EXTIF -p icmp -s $EXTIP --icmp-type 8 -m state --state NEW -j ACCEPT
$IPT -A FORWARD -i $INTIF1 -p icmp -s $INTNET1 --icmp-type 8 -m state --state NEW -j ACCEPT
$IPT -A FORWARD -i $INTIF2 -p icmp -s $INTNET2 --icmp-type 8 -m state --state NEW -j ACCEPT
# Allow firewall to ping internal systems
$IPT -A OUTPUT -o $INTIF1 -p icmp -s $INTNET1 --icmp-type 8 -m state --state NEW -j ACCEPT
$IPT -A OUTPUT -o $INTIF2 -p icmp -s $INTNET2 --icmp-type 8 -m state --state NEW -j ACCEPT
Now we are going to default to DROP and Log anything that's left in case we overlooked something. The ACCEPT entry's we made at the very beginning would come right before this in the final script:
# Log & block whatever is left
$IPT -A INPUT -j DROPl
$IPT -A OUTPUT -j REJECTl
$IPT -A FORWARD -j DROPl
And you're done. I had a friend nmap and nessus my connection with this rule set and as far as both of them were concerned the only thing it was even slightly sure about was that the ip existed...other than that nothing. I can IRC, MSN, ICQ, ane emerge sync to my hearts content.
PART III will cover setting up some essential SOHO services like NFS and CUPS in a security conscious manner.
ScriptsA couple scripts.
The full scriptNow here's the full script from the above information in all its glory (I also put the ssh forwarding in a more appropriate place):
Another iptables startup scriptAnother iptables startup script designed for a local linux router / linux server.
File: /etc/init.d/iptables
|
|
Note the following file is an EXAMPLE - DO NOT USE IT WITHOUT MODIFICATION
File: /etc/conf.d/iptables
|
|
Author's Original ScriptNote: This script was written by someone on another forum....I've since lost the address to the thread or forum..., but thanks goes to him.
It can be found on: HOWTO_Iptables_and_stateful_firewalls
Reset iptablesiptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -X
Hardware Related InformationInterface configurationThe author created this document is using a PPPoE connection to the internet and the 2.6.x kernel.
However, the only adaptation that would need to be made is to replace 'ppp0' with 'eth0' (or whatever NIC you have facing the internet -- this will become clear later).
In my set up, I have three NIC's, one is connected to the WAN through PPPoE, the other two to my internal network. In order for them all to play nicely with iptables and masquerading (NAT'ing), they must be set to different subnets. For example, the two NIC's connected to my internal computers, e.g., the “internal NIC's”, are assigned: 192.168.1.1 and 192.168.2.1 respectively. It should be noted here that it is perfectly acceptable to connect these internal NIC's to any network capable device, such as a switch or hub. For pppoe connections we make sure the NIC connected to the outside world, e.g. the external NIC is not assigned any ip....its entries in /etc/conf.d/net should be left blank. This is due to pppoe acting as a virtual device which handles bringing up the NIC. We must also assign proper netmasks and broadcast values to these interfaces. Your /etc/conf.d/net should look like these:
The gateways for the clients are set to the internal ip's of the NIC on the server as should be expected. Now add all the interfaces to the default run level and restart connections:
Start network cardsrc-update add net.eth1 default; rc-update add net.eth2 default; rc-update add net.ppp0 default;
/etc/init.d/net.eth1 restart; /etc/init.d/net.eth2 restart; /etc/init.d/net.ppp0 restart;
Now verify that you are connected to the internet on the server machine (the clients will not be.....yet) and that all the interfaces can ping each other.
Serverping www.google.com;
ping 192.168.1.78
ping 192.168.2.78
ping 192.168.1.77
ping 192.168.2.77
Next ensure that your clients have appropriate DNS's set in your
/etc/resolv.conf.
TroubleshootingFailure on COMMIT linesiptables failures will nearly always occur on the COMMIT lines. This is because while the rules are read earlier, iptables does not check the match (-m) option until this point. The actual error will be somewhere between the COMMIT line where the error occurred and the previous COMMIT line.
The first things to check for when you get errors are typos and that you have the correct modules loaded (if you're unsure, the easiest way is to build all the features into the kernel - you might want to skip features marked experimental for this as they may cause issues and you're unlikely to be using them).
One way to locate the line causing the problem is to disable all your rules (this can be done by commenting them out by placing a # at the beginning of the line) and then re-enabling them one-by-one until the error occurs.
