Debian User Forums

by **chrismortimore** » 2007-06-18 10:23

Sorry it took so long, I've had some personal things to work through over the last few weeks. But here it is.

Introductory blurb
I've elected to do three separate guides for iptables that will cover three topics. These will be as follows:

Basic protection, granting access to services based on IP and/or MAC address, and Debian integration
Protection against port scanning, and blacklisting addresses that "misbehave"
Port knocking

In the true style of Debian, they'll be posted when they are ready

First things first
Make sure you have the "iptables" package installed. Use your favourate package manager to do it, I won't tell you how.

Big fat notes

This guide only deals with filtering. It will not deal with routing or mangling. If you don't know what these are, don't worry I intend this guide to be for people who just want to protect their desktop/laptop from nasty people.
When building a firewall, you should know exactly what you want to do with it from the outset. Firewalls take thought and planning. By all means, keep reading if you havn't a clue, and you might get some ideas, but it isn't the kind of thing where you just throw in commands and play around.
All of the commands need to be ran with root privilages. Amend them as you need to (be it prefixing sudo, or whatever). I just use a root console myself, but hey, I'm old fashioned.
If you set up your firewall badly, things will probably stop working. IP tables doesn't save the tables itself, so if you reboot, it will clear everything. This could save you. However, if you are doing this on a remote machine, that could be easier said than done
If this guide scares you, then a GUI firewall builder might be better for you. There are many out there that are only a search away. I personally like kmyfirewall.
Read this guide before you do it. In fact, read any guide before you do it. It's just good sense.

IP tables basics
There are three types of packets you will normally encounter when filtering:

INPUT - these are inbound packets. Things like people trying to access yours. This includes you trying to access your own services. Remember that last bit, it is important.
FORWARD - These are routing packets. As said earlier, I won't deal with those, thus we will just block them.
OUTPUT - These are packets that you send.

There are three things you can do with the packets when they get processed by IP tables:

ACCEPT - allow the packet to do it's business.
REJECT - send the packet back to source with a little note saying that it isn't allowed in the system.
DROP - ignore the packet.

Remember these six terms. They are not exactly taxing to remember, so it isn't that much to ask

Now, lets get down to how IP tables actually works. Each type of packet (INPUT, FORWARD and OUTPUT) are processed separately, but in the same manner. IP tables has a "table" of rules for each of the three packet types. For each table, there is what is termed the "Default Policy", which is either ACCEPT, REJECT or DROP. It literally starts at the top of the table, and works down until something matches the packet. If none of the rules in the table match the packet, then the default policy is applied. Make sense? Probably not, but hopefully it will shortly. On top of the three tables that IP tables gives you by default, you can make custom tables that you can use. This lets you group related rules together, and make it a bit tidier. They arn't needed, but it's nice to keep things clean.

Now, lets look at how rules are constructed. There are three parts to a rule: the table, the match criteria, and the target. The table is simply what table the rule gets inserted into (INPUT, FORWARD, OUTPUT or a custom table). The match criteria describe the situations that you want the rule to apply to (which are things like ports, addresses, and so on), but we'll cover these later on. The target is a little more interesting. The IP tables matches a rule, it sends the packet to a particular "target". These targets can be other tables, for additional processing, or it can be one of ACCEPT, REJECT and DROP. This is probably clear as mud just now, but once you see some rules, you'll be able to see how it comes together.

But what does it look like?
If you run "iptables" from a terminal, you'll get a lovely message saying "no command specified". Not what we're really after if we want to see the current table. We can do this using the "-L" option (L for list). This is what a blank table looks like:

Code: Select all: marbles:~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination

Here you can see the three basic tables (INPUT, FORWARD, and OUTPUT), and their default policies (ACCEPT for all of them). Very secure, everything gets in and out. But the default is not meant to imped your work, hence why it is that forgiving. If you put a table name after the -L option (such as INPUT), it will only print out that table. We'll use this later on.

Bringing it all together
So, we've covered how tables are processed and how rules are made in a very hand-waving "take my word for it" kind of way. Now comes the fun bit.

I work by this philosophy: nobody should be in my computer except me, and I don't want to be restricted in my surfing. This should imply to you that we want to keep as much of the incoming traffic out of the computer while letting everything leave the computer, which should start the cogs turning. Obvious candidates for the default policies are ACCEPT for OUTPUT, and either REJECT or DROP for INPUT. See where I got this from? If not, then I'd recommend a GUI firewall builder. Seriously.

Whether you use REJECT or DROP is purely a matter of preference. REJECT tells the source that a computer is there and that their packet has been blocked, but with DROP the source computer doesn't have a clue what has happened (but can probably guess). I personally favour DROP, because I like to be "invisible"

So DROP will be used in this guide, but you can swap it for REJECT if you wish.

So we've dealt with the INPUT and OUTPUT default policies, but what about FORWARD? As this guide ignores routing, we want the computer to follow suit, so we'll have the FORWARD policy as DROP.

To set our default policies, we use the "-P" option (P for policy) on each table, like so:

Code: Select all: iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT

The first line reads as "Set the default policy of INPUT to DROP". The other two are in the same light. Now, if we look at our table, you'll see it has changed from the default:

Code: Select all: Chain INPUT (policy DROP) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination

The first two default policies are now DROP, wooyay! The program is doing what we want it to!

Some basic input exceptions
So now we have locked down our computer. What about everything that had connections before? Things like current SSH connections (which might include the one you are currently accessing the computer with

) will suddenly stop. Because if this, we need to add our first rule, which is a bit complicated, but needed.

IP tables lets us check the "state" of connections, i.e. whether it is a new connection, an existing connection, related to an existing connection and so on. What we want to do is allow all existing connections, and any connections that relate to the existing connections. Confused? Good

Basically, we don't want to disconnect anyone that is currently connected to the computer. This is the rule that we use to do this:

Code: Select all: iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

This reads as "If the incoming connection is existing when we start the firewall, or related to an existing connection, then accept it". Because it is our first rule, we'll break it down into the three parts I mentioned earlier:

"-A INPUT" sets the table. It reads as "Append to the INPUT table"
"-m state --state RELATED,ESTABLISHED" is our matching criteria. It literally reads as "Use the state module, and match related or established connections"
"-j ACCEPT" is our target. It literally reads as "If the matching criteria fits, jump to ACCEPT". This is basically, if we match, accept the packet.

Basically all rules can be broken down like this, it is just a case of knowing what part is what. If we run this command, our table now looks like this:

Code: Select all: marbles:~# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination

See our little rule at the top of the INPUT table? Doesn't it just look lonely? Let's give it another friend.

The next rule I always use is to allow any local incoming packets. Ever wondered what your loopback device ("lo" in ifconfig) is for? It is used when you access a service locally, such as SSH into yourself, view your own web server, access your local IMAP server, etc. So, if we want to be able to get to our own services (which you usually want to do), we need to add a rule that "trusts" the loopback device. Here goes:

Code: Select all: iptables -A INPUT -i lo -j ACCEPT

This reads as "If the packet comes from the loopback device, accept it". I'm sure you can break it down into the three parts if you want. We also have a new option, the "-i" option. This is the network interface that the packet was received on.

Now, if we look at our table, you'll see the most useless line ever:

Code: Select all: arbles:~# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT 0 -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination

The second rule looks like it is accepting everything. We need to tell IP tables to print the table in a more verbose way, so we use the old favourate "-v" option.

Code: Select all: marbles:~# iptables -vL Chain INPUT (policy DROP 91 packets, 8249 bytes) pkts bytes target prot opt in out source destination 59 5901 ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED 11 660 ACCEPT 0 -- lo any anywhere anywhere Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 131 packets, 9383 bytes) pkts bytes target prot opt in out source destination

There we go. In the "in" column, you can see that the loopback device is listed in the second rule, so it is doing what we want it to *phew*. Also note that the rules are listed in the table in the order that they are added using the "iptables" command. This is also the order that they are processed. In this guide, the order doesn't matter too much, but in the next two it will. But we'll save those for a later day

With this table, you now have a pretty secure system. You can send out what you like, but nobody else will get in. Nice

Read on for how to open ports.

Allowing access
There are three matching criteria that I think are useful when allowing packets in: port (which is set by the "--dport" option), source IP address (which is set by the "-s" option), and source MAC address (which is a little more complicated). You can use any combination of the three to build your firewall, and the order doesn't matter because they all need to match. For matching ports and such like, you need to also match the protocol using the "-p" option. This will be either "-p tcp" or "-p udp". Lets do some examples.

I want all computers to be able to access my webserver, which runs on TCP port 80. Hopefully now, you'd be able to give making this rule a bash yourself, because it is pretty simple. Here is the rule:

Code: Select all: iptables -A INPUT -p tcp --dport 80 -j ACCEPT

And looking at the INPUT table, we get this:

Code: Select all: marbles:~# iptables -L INPUT Chain INPUT (policy DROP) target prot opt source destination ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT 0 -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:www

As you can see, the last line says "ACCEPT any packets that are for port 80".

Now, I want only my laptop to be able to access SSH. My laptop always has IP address 192.168.0.3, and lets say it's MAC address is 00:11:22:33:44:55. An appropriate rule would be this:

Code: Select all: iptables -A INPUT -p tcp -m mac --mac-source 00:11:22:33:44:55 --dport 22 -s 192.168.0.3 -j ACCEPT

Because this line is a little different, I'll break it down. You may have noticed that little "-m" argument that we used in the state rule from earlier, and I kind of just washed over it because we were quite early on. Lets get down to the nitty of it all. IPtables supports modules (not the kernel ones, but a similar idea), which means happy programmers can write their own plugins for matching rules in their own magical (and usually stupid or specialised) way. If you open the iptables man page, you'll see a huge list of the modules available (in the "MATCH EXTENSIONS" section). It's pretty straight forward really, here is the part of the man page for MAC address matching:

Code: Select all: mac --mac-source [!] address Match source MAC address. It must be of the form XX:XX:XX:XX:XX:XX. Note that this only makes sense for packets coming from an Ethernet device and entering the PREROUTING, FORWARD or INPUT chains.

From this, you can see the module name is "mac" (which we pass to the "-m" argument), and it also lists all arguments the module itself accepts, and how to use them. Cunning, isn't it?

And as always, it makes our table look like this:

Code: Select all: Chain INPUT (policy DROP) target prot opt source destination ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT 0 -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:www ACCEPT tcp -- 192.168.0.3 anywhere MAC 00:11:22:33:44:55 tcp dpt:ssh

By now, I'd hope you'd be able to figure out how this line relates to the rule, so I'll stop spoon feeding

Just for completeness, if you only want to allow access by IP address, and not bother with MAC filtering, you would use:

Code: Select all: iptables -A INPUT -p tcp --dport 22 -s 192.168.0.3 -j ACCEPT

And likewise, you can filter only by MAC address, but I'll let you figure that out for yourself as well

What about allowing access from a particular range of IP addresses? Perfectly reasonable thing to ask, and it took me ages to figure out. Say you want to allow port 80 to addresses 192.168.0.2 through to 192.168.0.8. From what I have above, that would be 7 rules. But what if you want to do everyone from 192.168.0.2 to 192.168.0.200? "Eek" is an appropriate word here, so we use the "iprange" module like so:

Code: Select all: iptables -A INPUT -p tcp -m iprange --src-range 192.168.0.2-192.168.0.200 --dport 80 -j ACCEPT

Simple, isn't it? Say you want to do the same thing, but with multiple ports (that arn't consecutive, I'll cover consecutive in the next section), go look up the "multiport" module in the MATCH EXTENSIONS section of the manage, and it'll give you the low down, and you just use them in the same way we used iprange, mac filtering, and state matching. Easy as pie

Something that isn't just tcp
Bittorrent is a prime example of how what I've covered so far doesn't work, because I've only done TCP so far, and Bittorrent uses TCP and UDP. For arguments sake, by Bittorrent client is configured to use ports 10000 to 10020. Don't ask why, I can't even remember why I picked them. I digress.. Anyway, here is the line we would use for the TCP part:

Code: Select all: iptables -A INPUT -p tcp --dport 10000:10020 -j ACCEPT

Clever isn't it? And now you know how to use dport to set a range of consecutive ports as well

But what about the UDP part I hear you cry? Now, I've never got one rule to work for both TCP and UDP packets, there might be a way of doing it, but I don't know. But I have a simple solution, so simple an idiot could (and did) think of it:

Code: Select all: iptables -A INPUT -p udp --dport 10000:10020 -j ACCEPT

Yup, duplicate the rule and use "udp" instead of "tcp". Not the best method, but it works.

But that's not all! What about flood pings?
Having covered TCP and UDP, we've missed one out, our old friend ICMP! For those of you that don't know what ICMP is used for, the best description I've ever come up with is "It's used for pings and stuff". I personally don't like pings. Once your network is working, the only thing they are useful for is flood pinging each other for fun (or for evil purposes). So lets block them completely!

Code: Select all: iptables -A INPUT -p icmp -j DROP

This blocks all pings quite nicely. But this could be a little harsh for you, because maybe you use pings every now and then to see if a computer is on (on those days when you can't be bothered going and checking). You can also use the "limit" module to limit how many are allowed. You could use these two lines instead:

Code: Select all: iptables -A INPUT -p icmp -m limit --limit 1/second --limit-burst 5 -j ACCEPT iptables -A INPUT -p icmp -j DROP

I now refer you to the limit part of the man page for how the arguments set it all up:

Code: Select all: limit This module matches at a limited rate using a token bucket filter. A rule using this extension will match until this limit is reached (unless the ‘!’ flag is used). It can be used in combination with the LOG target to give limited logging, for example. --limit rate Maximum average matching rate: specified as a number, with an optional ‘/second’, ‘/minute’, ‘/hour’, or ‘/day’ suffix; the default is 3/hour. --limit-burst number Maximum initial number of packets to match: this number gets recharged by one every time the limit speci- fied above is not reached, up to this number; the default is 5.

Now lets break it all down. The first rule says "ACCEPT the first 5 ICMP packets regardless of how often they occur, and then after that, ACCEPT only one per second". For everything that is outside of these limits, the second rule matches, which is simply our drop rule. This allows people to ping us, but not quickly enough that it disturbs our day.

You can of course mix this with anything else described above. I, for example, allow any pings (be them flood or not) from my laptop by matching IP address and MAC address, and every other computer on the network is only allowed to ping me once every second. This is just combining what we already know and getting the order right like this:

Code: Select all: iptables -A INPUT -p icmp -m mac --mac-source 00:11:22:33:44:55 -s toaster -j ACCEPT iptables -A INPUT -p icmp -m limit --limit 1/second --limit-burst 1 -j ACCEPT iptables -A INPUT -p icmp -j DROP

Saving and loading rules
We use the two commands "iptables-save" and "iptables-restore" to do this. They don't work quite as I ever expected, but are still very handy. If I run "iptables-save" just now using the last example (SSH from my laptop), I get this:

Code: Select all: marbles:~# iptables-save # Generated by iptables-save v1.3.6 on Mon Jun 18 11:05:39 2007 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [15605:1128558] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -s 192.168.0.3 -p tcp -m mac --mac-source 00:11:22:33:44:55 -m tcp --dport 22 -j ACCEPT COMMIT # Completed on Mon Jun 18 11:05:39 2007

So the obvious way to save this, is using that nice ">" thingy, like so:

Code: Select all: iptables-save > mysuperrules

"iptables-restore" just reads the rules from STDIN and sets them as needed, so you can then reload them using this command:

Code: Select all: iptables-restore < mysuperrules

Thats about it really.

Debian Integration
Debian doesn't have any "proper" way of setting iptables rules, but it's quite easy to make it do it for us. First, I like to make a place to keep my rules (I have a few rules for different scenarios, such as laptop in the house, laptop roaming, that kind of thing). You're choice, I use /etc/iptables/ to save them. So lets say our rules are saved in the file /etc/iptables/myrules. Just now, my /etc/network/interfaces file looks like this:

Code: Select all: auto lo eth0 iface lo inet loopback iface eth0 inet dhcp

Little bare, but it nicely starts eth0 on boot using DHCP. To make it load our rules, simply change it to this:

Code: Select all: auto lo eth0 iface lo inet loopback iface eth0 inet dhcp pre-up /sbin/iptables-restore < /etc/iptables/myrules

This will load our rules before eth0 is started, so we are protected from the word go. Nice

Conclusion
Well, thats basically it for now. We have covered locking down the computer and then granting access by IP address and MAC address, TCP, UDP and ICMP filtering, filtering by consecutive and non-consecutive ports, limiting packet rates, packet states, and getting it all to work with Debian nicely. I'd say experiment and read the man page now, just so you get a feel of just how powerful this program really is. Remember, if you mess it up, iptables resets when you restart your machine, so it isn't the end of the world.

Next time: portscan protection and blacklisting

Cheers,

Chris

by **sinical** » 2007-06-18 10:35

Welcome back .. nice novel :wink:

by **chrismortimore** » 2007-06-18 10:38

sinical wrote:Welcome back .. nice novel

Cheers, good to be back

by **GMouse** » 2007-06-18 13:29

Wow, impressive!

by **plb** » 2007-06-18 13:37

Thanks for this nice little howto...keep up the good work

by **Pobega** » 2007-06-18 14:03

Thanks for the awesome HowTo, but I'm still having trouble blocking pings on my laptop. No matter what rules I try, I'm still able to be pinged from my friends. My current ruleset is:

Code: Select all: Chain INPUT (policy DROP 2 packets, 64 bytes) pkts bytes target prot opt in out source destination 178 56600 ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT 0 -- lo any anywhere anywhere 0 0 DROP icmp -- any any anywhere anywhere 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:webcache 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:15000 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 36390 packets, 3233K bytes) pkts bytes target prot opt in out source destination

by **chrismortimore** » 2007-06-18 14:24

Pobega: is that the output from iptables after you've been pinged? Because if it is, the pings are matching on the first rule (the state one), as shown by it being the only one that has > 0 in the pkgs column. Bring down the network interface (ifconfig eth0 down), reconfigure iptables from scratch, and start your network interface again after iptables is going, and see if that solves anything. And lets cross our fingers

by **Pobega** » 2007-06-18 14:30

I put the IMCP rule above the state rule, but it's not working still.

Code: Select all: root:~# iptables -L Chain INPUT (policy DROP) target prot opt source destination DROP icmp -- anywhere anywhere ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT 0 -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:webcache ACCEPT tcp -- anywhere anywhere tcp dpt:15000

root:~# ping pobega.ath.cx
PING pobega.ath.cx (71.125.23.227) 56(84) bytes of data.

--- pobega.ath.cx ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms

But, from my friend's Windows PC:

C:\Documents and Settings\Jorge Fuentes>ping pobega.ath.cx
Pinging pobega.ath.cx [71.125.23.227] with 32 bytes of data:

Reply from 71.125.23.227: bytes=32 time=14ms TTL=59
Reply from 71.125.23.227: bytes=32 time=14ms TTL=59
Reply from 71.125.23.227: bytes=32 time=12ms TTL=59
Reply from 71.125.23.227: bytes=32 time=122ms TTL=59

Ping statistics for 71.125.23.227:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 122ms, Average = 40ms

by **hash** » 2007-06-18 17:03

thx chrismortimore.
neat intro

Will try it sometime an thank you again.

by **chrismortimore** » 2007-06-19 10:12

Pobega wrote:I put the IMCP rule above the state rule, but it's not working still.

Interesting... And unexpected... Leave this with me, I'll play around with my setup and see if I can find you a solution. But I'm going to shower first

by **plb** » 2007-06-19 12:45

This should drop all pings...

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

although I don't know why that iptables rule doesn't work...

by **llivv** » 2007-06-20 00:24

what can I say?

netfilter

= meat

= potatoes

= gravy

You deserve free ale :wink:

by **GMouse** » 2007-06-26 21:48

Not to be needy or anything, but...

could you write up the basic rules that would be required for some NAT on a system with two interfaces?

by **chrismortimore** » 2007-06-26 21:55

GMouse wrote:Not to be needy or anything, but... could you write up the basic rules that would be required for some NAT on a system with two interfaces?

I would if I'd ever done that kind of thing

If you can wait until August, my girlfriend is moving to Spain for a year of studying abroad, so I'll have nothing to do. I'm quite happy to then play around in VMware and see if I can cobble something together for you if you want. But it might take a while, because I will be moving to a new flat in August, have a lot of hospital appointments, and be preparing for my next year of uni. So yeah, patience is a virtue

by **GMouse** » 2007-06-26 22:18

If I must. :wink:

I should have a nice break in late August, when my summer classes end, so that'd actually work out quite nicely. You've been a great help so far. I'll be taking my finance courses between now and then, so if you want some info, etc. from there, feel free to ask.

Debian User Forums

HOWTO: iptables (part one of three)

HOWTO: iptables (part one of three)

tcp/ip tables

Who is online