[SOLVED] Understanding iptables rules

[p_quarles]

I've been attempting to learn myself the ins and outs of iptables, and have read a few basic tutorials. Before I decide to trust my firewall, though, I thought I'd ask for some opinions from the more experienced.

Below is the rule file. Here's what I think it does:
1) Allows established connections
2) Allows new connections from the server (and not vice versa)
3) Allows traffic on ports 22, 80, and xxxx (which I use for remote ssh).
4) Allows traffic on the loopback interface
5) Logs everything
6) Rejects all traffic that is not accepted by one of the previous rules.

I have no doubt that I used the correct rules here, but I'm curious to know if there are holes in this setup, or if there are easy workarounds that I don't know about. Thanks in advance.

# Generated by iptables-save v1.3.6 on Thu Aug 23 22:14:19 2007
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [686:87716]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 10.0.0.5 -i eth0 -m state --state NEW -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport xxxx -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -j DROP
COMMIT
EDIT: I guess I should add: no, port 22 isn't open to the world. The server is behind a dsl modem with a built-in firewall, and a NAT router. I use that only locally, and it's safely hidden from public view.

[psyburn]

Your default INPUT is ACCEPT
lets everything in...
Question: is this really needed?

EDIT: Must read again then post...
:( My bad

Anyway...
Could just set INPUT default to DROP

[koenn]

Here's how I see it :

1-
you should clarify first whether the machine these uptables rules run on is meant to be a router, or if the rules are just to protect the machine itself (your server ? your PC ?). If its all about the machine itself, you can set the FORWARD policy to DROP. If this machine should route (to other computers/networks), it is now accepting all traffic passing through - your INPUT rules only affect traffic with destination address = addres of this machine, and your FORWARD policy is ACCEPT.


2-
you've only defined INPUT rules, i.e. connections initiated by other hosts towards the machine uptables runs on - and are allowing everything and anything on OUTPUT. That means that if a malicious program on this machine initiates a connection to anywhere (say, offering a remote desktop or a shell to a cracker), it will be allowed to (cause it's on the OUTPUT chain), and the replies (from that cracker) are allowed by your INPUT -m state ESTABLISHED, RELATED -j ACCEPT.

You probably want some OUTPUT rules as well


3-
you rephrase your rules as "allow traffic" but what the rules actually say is "allow incoming connections (anything from 10.0.0.5, OR from anywhere and coming to ports 22, 80 and xxxx on this machine)". That's not exactlty the same, and I can't judge if its actually what you meant/want

Likewise, you say "1) Allows established connections" but the rule actually only allows incoming packets that belong to an established connection or are related to an existing session - outgoing packets (from any connection, established or not) are allowed under your default OUTPUT:ACCEPT policy
(see also 1-)

4-
you can replace the catch-all by a default policy DROP (re. psyburn)

[p_quarles]

First, thank you both for your responses.

Yes, I do want OUTPUT rules. The basic guides I read didn't cover that, but now I know where to look. Thank you. :)

And, yes, I did mean to open up those three ports to all traffic. That said, I understand that iptables can specify the traffic types allowed on those ports (i.e., only http requests on port 80, etc.). Am I correct in assuming that this would be the next step to take to minimize risk?

As for the NEW and ESTABLISHED,RELATED rules: Before I added those, I was able to send packets, but unable to receive them (i.e., I wasn't able to ping or use apt). My understanding here tells me that I do indeed need an INPUT policy in effect to allow this kind of traffic to reach me.

This is a fileserver/webserver, and is not being used as a router. It's already behind two hardware firewalls, both running *nix, so I'm doing this for extra security more than anything else. I will add a deny-forwarding rule, though.

NB: The catch-all policy is DROP; the first one pertains to the loopback interface only. My understanding is that this is relatively safe, since if someone were to gain access to the system, they could just as easily rewrite the firewall rules as anything else.

<EDIT>: After some more reading, I've begun to think I should change the second rule to this:
-A INPUT -s 10.0.0.5 -o eth0 -m state --state NEW -j ACCEPT
This would only accept NEW connections that originated from the NIC, correct?

I'm teaching myself this stuff as much as I can, but any feedback is very much appreciated. I just don't want to think I understand something and then find out I've made a huge and obvious mistake :D < /EDIT>

[koenn]

explain clearly and unambigouosly what your network looks like : the hosts on it, and how they're supposed to communicate with each other.
without that, it's extremely difficult to make any sense out of your iptables rules.

Right now, I've heard you talk about a server, a computer with address 10.0.0.5, a computer that "Allows new connections from the server (and not vice versa)' but it's completely unclear which is which, how many computers we're talking about (2 ? 3 ?), whether there are any other computers involved, .... , and when you say "I send" or "packets reach me" that is completely without meaning if you don't say which computer you're using at the time.

[p_quarles]

Well, like I said, this is a web server, and not a router, and not a domain controller of any kind. The iptables rules are on the web server itself. I administer it only with ssh/sftp. 10.0.0.5 is the static IP address of the server itself. So, when I refer to sending or receiving packets, I am talking about logging into the web server via ssh and running APT updates.

I use the machine for three things: to host a personal web page (behind a hardware firewall for now, until I get iptables working the way it should); to download large files without taxing my workstation; and for storing important backup files (all of which reside in in heavily encrypted disk images with a strong passphrase).

What I am looking for is a safe, minimalistic set of filtering policies that will thwart the kinds of attacks that regularly come from port scanning scripts. The only traffic that would ever legitimately go "through" the server (i.e., from any other machine to any other machine) are ssh commands and http links to other sites.

That's as clear as I can be.

Note, too, that I realized that I didn't actually need the second rule in the table above at all. What I wanted, it turns out, is accomplished by allowing ESTABLISHED,RELATED connections. Once I realized this, I deleted that rule.

[koenn]

10.0.0.5 is the static IP address of the server itself.

Note, too, that I realized that I didn't actually need the second rule in the table above at all. What I wanted, it turns out, is accomplished by allowing ESTABLISHED,RELATED connections. Once I realized this, I deleted that rule.

yep, that one really had me puzzled. " -A INPUT -s 10.0.0.5 -i eth0 -m state --state NEW -j ACCEPT " while 10.0.0.5 address of the machine where these rules run ...

I'll have another look at your ruleset in light of your clarification

[p_quarles]

yep, that one really had me puzzled. " -A INPUT -s 10.0.0.5 -i eth0 -m state --state NEW -j ACCEPT " while 10.0.0.5 address of the machine where these rules run ...

I'll have another look at your ruleset in light of your clarification
Yep. Now that I understand what that rule actually says, it makes no sense to me either :)

[garba]

unless you need some very low level ip tables feature and you just want to "get the job done" i would reccomend you take a look at shorewall, a very powerful ip tables builder

[koenn]

Well, like I said, this is a web server, and not a router, and not a domain controller of any kind. The iptables rules are on the web server itself. I administer it only with ssh/sftp. 10.0.0.5 is the static IP address of the server itself. So, when I refer to sending or receiving packets, I am talking about logging into the web server via ssh and running APT updates.

I use the machine for three things: to host a personal web page (behind a hardware firewall for now, until I get iptables working the way it should); to download large files without taxing my workstation; and for storing important backup files (all of which reside in in heavily encrypted disk images with a strong passphrase).

What I am looking for is a safe, minimalistic set of filtering policies that will thwart the kinds of attacks that regularly come from port scanning scripts.

Assuming we adhere to the policy of "block everything, then allow only what's needed", you start by setting a default policy on all chains. This is better than your catch-all DROP rule at the bottom of the list, because that catch-all would also block rules that you add interactively later on (eg when troubleshooting or experimenting) : the -A switch appends rules at the bottom.

#default policy : DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
This is how you do it from a shell. You'll have to figure out yourself how to do it in the tool your using.

Allow connections to webserver on port 80 and ssh on non-default port xxxx

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport xxxx -j ACCEPT

you already have those. the -i eth0 only makes sense if the server has multiple NICs - in that case you can specify the interface to block spoofed or suspiciously routed packets. you could also add -d 10.0.0.5 to make the rules more complete (-d : destination address)
I'm not sure you actually need the -m tcp.

you also have
iptables -A INPUT --dport 22 -j ACCEPT - I don't understand that one. Do you have sshd listening on both port 22 AND xxxx ?


you may also need similar INPUT -j ACCEPT to allow acces to samba shares.
ports :
netbios-ns 137/udp # NetBIOS Name Service
netbios-dgm 138/udp # NetBIOS Datagram Service
netbios-ssn 139/tcp # NetBIOS Session Service
( microsoft-ds 445/tcp # Microsoft Directory Service )


Allow connections from server to other hosts (eg apt via http, for updates)
you could simply allow anything out, assuming your the one starting the sessions :
iptables -A OUTPUT -j ACCEPT but this would also allow connections initiated by malware you happen to install. Or you could specify what services this server will use, eg http (80/tcp) for apt
iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT

If you're really strict about it, you can also specify ubuntu download servers (by name or ip address, with -d (estination))

Same for other services should you need them.


Then, you will need to allow replies to te requests your server receives (on INPUT) or sends out (on OUTPUT) so you probably need both
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
I'm not 100% sure on this, I use a perimeter firewall so everything is on FORWARD i.s.o. IN/OUTPUT but it seems logical. You try :)

Then, add your loopback rule.


The only traffic that would ever legitimately go "through" the server (i.e., from any other machine to any other machine) are ssh commands and http links to other sites.
I assume you mean that you connect to the server with ssh (this is INPUT) or you browse to internet hosts (this is OUTPUT). So no forwarding.


Finaly, re-order all rules. In your case, they're not dependent on each other so the order doesn't matter logically. Therefore, it makes sense to put rules that are likely to be used a lot, higher up the list so they match quickly, without having to go through the whole list.
I guess that would be something like
1) the ESTABLISHED,RELATED rules
2) the http rules
3) the ssh rules.
4) the loopback rule

I don't know about the log rule.


If you decide to get rid of your hardware firewall, you should realise that iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT would allow web access from anywhere. If your webserver is supposed to be private, you can specify which hosts are allowed to connect by adding ip-adresses/names of the PC's or the network that is allowed to access it (using -s (source address)).

I suggest you compare my sollution to yours, see if you understand the differences, check that they match your intentions about network usage / server access, and take it from there.


In addition to firewall rules, you can also use your webserver's / samba's built-in security mechanisms /access control, or look into inetd / xinetd (a "superserver" used to controll access to regular daemons). Security is usually applied in layers, and these tools add additional/complementary layers.

Have fun.

[p_quarles]

Hey, thank you so much for this extensive and thoughtful answer. This confirms that the rules I entered are doing (mostly) what I thought they were, and points to a few ways I can lock it down further so that the computer won't be able to do anything it doesn't need to.

My one point of confusion is over where the default DROP policy should go. My understanding had been that by applying that rule before any others were established (and placing it before the ACCEPT policies), I would immediately lose my ssh connection and have to lug out an old monitor and keybord. But I gather that by calling the -P option without specifying a chain, this works differently?

And, yes, ssh listens on two ports. No good reason. Just haven't gotten around to aliasing ssh to the high port on every machine. The router isn't listening on 22, though, so it's only available on the LAN.

Thanks again for the help.

EDIT: @garba I looked at shorewall a while back, and I may use it in the future. For now, though, my main goal is to understand the rulesetting procedure well enough to know what automated tools like that do. In other words, I'm too much of a geek to ever want anything to "just work." :)

[koenn]

My one point of confusion is over where the default DROP policy should go. My understanding had been that by applying that rule before any others were established (and placing it before the ACCEPT policies), I would immediately lose my ssh connection and have to lug out an old monitor and keybord. But I gather that by calling the -P option without specifying a chain, this works differently?
)
yes.
the -P (policy) statements apply if no matching rule is found. rules match by whatever you specify (interface, source/destination address, protocol, source/destination port, state, ...) and then 'jump' (-j) to an ACCEPT | DROP procedure.

So, yes, you can have them first. That is usually a good idea (at least if you use DROP ) : during startup, it immediately blocks everything, so your computer is sealed of while your ipables script continues to run and sets the jump rules.

[p_quarles]

yes.
the -P (policy) statements apply if no matching rule is found. rules match by whatever you specify (interface, source/destination address, protocol, source/destination port, state, ...) and then 'jump' (-j) to an ACCEPT | DROP procedure.

So, yes, you can have them first. That is usually a good idea (at least if you use DROP ) : during startup, it immediately blocks everything, so your computer is sealed of while your ipables script continues to run and sets the jump rules.
Okay, thanks. The information about the -P option in the man page was, umm, lacking.

Now I can start reading this (http://iptables-tutorial.frozentux.net/iptables-tutorial.html) and have some idea what I'm looking for. :)

[koenn]

Okay, thanks. The information about the -P option in the man page was, umm, lacking.

No, it's there
-P, --policy chain target
Set the policy for the chain to the given target. See the sec-
tion TARGETS for the legal targets. Only built-in (non-user-
defined) chains can have policies, and neither built-in nor
user-defined chains can be policy targets.

but you'd have to understand iptables' concepts of CHAIN and TARGET before any of it starts making sense. You're better of with a good howto and some hands-on trial and error. I see you've already found a howto :)

[garba]

EDIT: @garba I looked at shorewall a while back, and I may use it in the future. For now, though, my main goal is to understand the rulesetting procedure well enough to know what automated tools like that do. In other words, I'm too much of a geek to ever want anything to "just work." :)

i agree 100% with you, that's the same approach i follow, i know what you mean

[fusionisthefuture]

hi guys, i was wondering if someone could help me out with iptables.

i dont want to use a configuration program for iptables, just iptables itself, which i edit with a boot script.

right now, when i run my script, the firewall comes out looking like this:

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT 0 -- localhost localhost

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT 0 -- localhost localhost
ACCEPT tcp -- anywhere anywhere multiport dports ftp-data,ftp
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:www
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:domain


this works pretty well, but what im really looking for is something that will allow me to set the output policy to drop. currently, when i do this, it lets me do everything but ftp, because it needs to connect to a random port in the latter ranges for the actual file transfer. when i try it with this firewall, and the policy set to drop, it hangs at PASV, because im not allowing the server to connect to a port, generally in the 50000 range.

thanks for any input.
-arne

[koenn]

you might want to start a new threath for this, in case your problem doesn't get solved rightaway. The subject of this thread was taken care of, and it says "SOLVED".

it hangs at PASV, because im not allowing the server to connect to a port, generally in the 50000 range.
You sure about this ? In passive mode, it's your PC that sets up the data connection to the server, at a random high port assigned to you by the server. Your ACCEPT in the OUTPUT chain confirms this.

One would expect that ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED would allow such connection.
Possible problems could be
- the server doesn't support PASV
- there's some interference from a NAT router
- I'm just not seeing it
- "ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED" doesn't tell everything it does. What exact rule did you use here ?
- you need an additional iptables module (conntrack) to be able to do this
- I'm getting it all wrong