Index: Evil Twin Skippy's Guide to Linux | Back: Who is Evil Twin Skippy?

Howto: Basic Lockdown using IPTABLES

Ok, so here's the situation. You have a linux box. You know no one has done any kind of security survey on it. You've peered through example after example, and after concluding that you are not trying to create a poor man's cable router, nor trying to start the space program, you throw up your hands in disgust. Then you copy and paste the most coherent sounding example and pray that it works.

You are not alone.

This tutorial will do more than throw code at you. I will explain the entire process. You will leave with an understanding of how to do it, but why its done that way.

The best thing to do us start with a clean slate. By the time you get here, you probably have either no firewall, or the well meaning one from your OS, or a sorta implementation that you think is working...

This is a universal "back it up and start it over" script for IP tables. 


###
# Clear out any and all existing rules
# Copied and pasted from time enternal
# It's uber-overkill, but hey, what good script isn't?
###
for a in `cat /proc/net/ip_tables_names`; do
/sbin/iptables -F -t $a
/sbin/iptables -X -t $a

if [ $a == nat ]; then
   /sbin/iptables -t nat -P PREROUTING ACCEPT
   /sbin/iptables -t nat -P POSTROUTING ACCEPT
   /sbin/iptables -t nat -P OUTPUT ACCEPT
elif [ $a == mangle ]; then
   /sbin/iptables -t mangle -P PREROUTING ACCEPT
   /sbin/iptables -t mangle -P INPUT ACCEPT
   /sbin/iptables -t mangle -P FORWARD ACCEPT
   /sbin/iptables -t mangle -P OUTPUT ACCEPT
   /sbin/iptables -t mangle -P POSTROUTING ACCEPT
elif [ $a == filter ]; then
   /sbin/iptables -t filter -P INPUT ACCEPT
   /sbin/iptables -t filter -P FORWARD ACCEPT
   /sbin/iptables -t filter -P OUTPUT ACCEPT
fi
done

Ok, so now that that's done we can get to business. Lets start with a simple web server: 


/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -s 192.231.162.0/23 -j ACCEPT

/sbin/iptables -P INPUT -j DROP
/sbin/iptables -P FORWARD -j REJECT
/sbin/iptables -P OUTPUT -j ACCEPT

What does that script do? It has 2 parts. In the beginning we say: What the first half giveth, the second half taketh away:

So, why do I DROP on INPUT and REJECT on FORWARD? DROP and REJECT do essentially the same thing: deny access to traffic. The difference is that DROP will simply not respond. REJECT will send the proper "I'm not listening to you" message. I say "proper" with clenched teeth. While it is useful for debugging, politeness can be used against you. Port scanners can see a "REJECTED" port, and my evil counterpart will know you are are trying to hide something.

With DROP (s)he not only gets no feedback at all, it takes a port scanner a longer time to handle a drop because they wait for the return that never comes. A REJECT gives them instant gratification.

Security is like poker, never show your cards. If a blackhat sees that you have a copy of MySQL or Samba running (although blocked) on the box, he or she may think there is something to plunder. You don't leave a laptop on front seat of your car, you don't leave ports visible that you don't intend to be used.

So, after all this spiel about DROP on INPUT, why do I REJECT on FORWARD? FORWARD is used when your box tries to redirect traffic on behalf of another computer. While a normal web server doesn't have to deal with this, if you ever employ a VPN tunnel or a PPP connection, your kernel may or may not have to "FORWARD" traffic to make the magic happen properly. When diagnosing problems the feedback from a REJECT versus the silence of DROP is the difference between a quick tweak to an afternoon of frustration until you remember how you locked the machine down. Besides, blackhatters who try to forward through your box do get the idea after the first couple of attempts.

Now you aren't completely out of the woods yet. There are a lot of attacks against SSH on the default port, so be sure to read up on my later chapter "SSH on a non-standard port".

You are also going to need some way of restoring this IPTABLE firewall once your operating system reboots. See my later chapter "Firewalls on Startup".

Index: Evil Twin Skippy's Guide to Linux | Back: Who is Evil Twin Skippy?