[SOLVED] Iptables configuration questions

Ormu · 06-13-2012, 10:55 AM

I tried to follow some templates to create rules for iptables... and this is what I came up with:

Code:

#default policies
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT

#loopback
-A INPUT -i lo -j ACCEPT

#accepting established incoming connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT


#game server
-A INPUT -p tcp --dport <gamePort> -j ACCEPT
-A INPUT -p udp --dport <gamePort> -j ACCEPT

#ssh
-A INPUT -p tcp --dport <sshPort> -j ACCEPT

#logging
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

COMMIT

Will this work properly if I put it into use as instrcuted here (distro is Debian 6.0):
http://www.routermods.com/2008/11/30...ubuntu-server/

Is there any important options missing? Should I do something special to SYN packets? I want to block most incoming traffic but allow connections to SSH and a game server.

slugmax · 06-13-2012, 11:11 AM

Yes, that will work. I would only add a state NEW match to your game server and SSH tcp rules (see below), SYN packets will get matched by these rules, and subsequent packets will get picked up by the rule that accepts state ESTABLISHED,RELATED packets.

Code:

-A INPUT -p tcp -m state --state NEW --dport <sshPort> -j ACCEPT

I have some iptables scripts you may want to look at and steal bits and pieces from here:

http://www.unixlore.net/learning-net...l-scripts.html

In particular, you may want to limit the source IP address for connections to your SSH or game server.

Ormu · 06-13-2012, 12:44 PM

Quote:

Originally Posted by slugmax

Yes, that will work. I would only add a state NEW match to your game server and SSH tcp rules (see below), SYN packets will get matched by these rules, and subsequent packets will get picked up by the rule that accepts state ESTABLISHED,RELATED packets.

Code:

-A INPUT -p tcp -m state --state NEW --dport <sshPort> -j ACCEPT

Ok, thanks. I'm going to try with those additions. But just for curiosity; what advantages does this type of rule have over a simple rule like: -A INPUT -p tcp --dport <sshPort> -j ACCEPT

Quote:

I have some iptables scripts you may want to look at and steal bits and pieces from here:

http://www.unixlore.net/learning-net...l-scripts.html

In particular, you may want to limit the source IP address for connections to your SSH or game server.

Restricting the IPs for SSH access is unfortunately infeasible for me. I need to log in from many places and computers, most of which have a dynamic IP address. Sometimes I may even log in via mobile broadband. I have to stick with the usual SSH security tweaks (non-default port, root access disabled etc.) and possibly fail2ban.

slugmax · 06-13-2012, 01:20 PM

Quote:

Ok, thanks. I'm going to try with those additions. But just for curiosity; what advantages does this type of rule have over a simple rule like: -A INPUT -p tcp --dport <sshPort> -j ACCEPT

The end result will be the same as far as opening up your server to connections on those ports. However, the simpler rule accepts anything to that port, even if it is unrelated to a current connection. Using the NEW state match narrows this to only accept what is needed to start the connection. This is in line with good network security practice, which is to accept just what is needed and drop the rest.

Ormu · 06-14-2012, 10:28 AM

I tried to enable those rules according to this guide but for some reason I can't get it to work. When I use iptables-restore it always gives an error message:

Code:

iptables-restore: line 2 failed

Using iptables -L after this will give the default rules so nothing has been added:

Code:

# 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

I have tried to define the default policies in a different way (-A FORWARD -j DROP) but it still fails. Should I add something to the beginning of the rules file?
In this example there's a line *filter in the beginning.
Another example suggests removing all existing rules with iptables -F first.

slugmax · 06-14-2012, 11:44 AM

I don't typically write firewall scripts in the iptables-save format, I just write a standard shell script, run it to load the ruleset, then run iptables-save (e.g., 'iptables-save > iptables.out') to get the correct format that I can then tweak or reference from a startup script with iptables-restore. The iptables-save format looks like this:

Code:

# Generated by iptables-save v1.4.13 on Thu Jun 14 12:21:25 2012
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
...
COMMIT
# Completed on Thu Jun 14 12:21:25 2012

There will be a section for each chain - referenced as '*filter', '*nat' and '*mangle', and a COMMIT after each chain's rules are defined.

It seems more intuitive to me to use a shell script that explicitly references the iptables commands (but YMMV). That is also the syntax you'll see in the iptables man page. I do flush the various chains and NAT tables with this at the start of my shell scripts:

Code:

IPT="/sbin/iptables"
# Clear the builtin chains and delete any user-defined chains
$IPT -F
$IPT -X

# Flush the nat and mangle tables
for table in nat mangle
do
        $IPT -t $table -F
        $IPT -t $table -X
done

One advantage to using iptables-restore is that is flushes the tables and packet counters for you automatically.

Ormu · 06-14-2012, 01:21 PM

Ok, thanks for help. I created a shell script which sets the rules - everything successful. Then I dumped the rules into a file with iptables-save, and added this line to /etc/network/interfaces (under the loopback section):

Code:

...
auto lo
iface lo inet loopback
pre-up iptables-restore < /etc/iptables.ready
...

So now it should load the rules during boot, right?

Output of iptables -L here - seems to be OK(?). Nmap shows most ports as "filtered" so it seems to work. But does the logging option work properly (i.e. log only denied connections)?

Code:

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  localhost            anywhere
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:<gamePort>
ACCEPT     udp  --  anywhere             anywhere            udp dpt:<gamePort>
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:<sshPort>
LOG        all  --  anywhere             anywhere            limit: avg 5/min burst 5 LOG level debug prefix `iptables denied: '

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

I added an option -s 127.0.0.1 to the command that sets loopback rules, without the option there was an entry like this in the list and I wasn't sure if this would only allow loopback traffic:

Code:

ACCEPT     all  --  anywhere             anywhere

slugmax · 06-14-2012, 02:12 PM

Quote:

So now it should load the rules during boot, right?

Yes, that will work.

Quote:

But does the logging option work properly (i.e. log only denied connections)?

Yes, check /var/log/messages to be sure.

Quote:

I added an option -s 127.0.0.1 to the command that sets loopback rules, without the option there was an entry like this in the list and I wasn't sure if this would only allow loopback traffic:

Code:

ACCEPT     all  --  anywhere             anywhere

Try 'iptables -L -nvx'. That willl turn off name resolution (-n), show verbose output (-v), and display packet and byte counters next to each rule (-x), so you can see which rules get hit. More importantly here, -v also displays the interface that applies to a rule, under a column labeled 'in' or 'out'. I assume you have a rule like this in your script?

Code:

iptables -A INPUT -i lo -j ACCEPT

If so, you'll see this without -v, which is misleading:

Code:

ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

but with -vx, you will see something like this:

Code:

    pkts    bytes target     prot opt in     out     source               destination
   46857  7952439 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0

Which tells you the rule is indeed only for packets coming into the loopback interface, so the '-s 127.0.0.1' is not needed.

Ormu · 06-17-2012, 01:47 PM

Thanks for help, it's now working. I checked some logs and noticed that it seems to block something coming from the local area network.. maybe the router/DSL modem sends some packets around the network.