LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 06-13-2012, 10:55 AM   #1
Ormu
Member
 
Registered: Jun 2011
Location: Finland
Posts: 56

Rep: Reputation: Disabled
Iptables configuration questions


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.
 
Old 06-13-2012, 11:11 AM   #2
slugmax
Member
 
Registered: Nov 2008
Location: Northern CT
Distribution: Slackware, Debian, Ubuntu
Posts: 69

Rep: Reputation: 24
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.

Last edited by slugmax; 06-13-2012 at 11:12 AM.
 
1 members found this post helpful.
Old 06-13-2012, 12:44 PM   #3
Ormu
Member
 
Registered: Jun 2011
Location: Finland
Posts: 56

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by slugmax View Post
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.

Last edited by Ormu; 06-13-2012 at 12:45 PM.
 
Old 06-13-2012, 01:20 PM   #4
slugmax
Member
 
Registered: Nov 2008
Location: Northern CT
Distribution: Slackware, Debian, Ubuntu
Posts: 69

Rep: Reputation: 24
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.
 
1 members found this post helpful.
Old 06-14-2012, 10:28 AM   #5
Ormu
Member
 
Registered: Jun 2011
Location: Finland
Posts: 56

Original Poster
Rep: Reputation: Disabled
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.
 
Old 06-14-2012, 11:44 AM   #6
slugmax
Member
 
Registered: Nov 2008
Location: Northern CT
Distribution: Slackware, Debian, Ubuntu
Posts: 69

Rep: Reputation: 24
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.
 
1 members found this post helpful.
Old 06-14-2012, 01:21 PM   #7
Ormu
Member
 
Registered: Jun 2011
Location: Finland
Posts: 56

Original Poster
Rep: Reputation: Disabled
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
 
Old 06-14-2012, 02:12 PM   #8
slugmax
Member
 
Registered: Nov 2008
Location: Northern CT
Distribution: Slackware, Debian, Ubuntu
Posts: 69

Rep: Reputation: 24
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.
 
1 members found this post helpful.
Old 06-17-2012, 01:47 PM   #9
Ormu
Member
 
Registered: Jun 2011
Location: Finland
Posts: 56

Original Poster
Rep: Reputation: Disabled
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.
 
  


Reply

Tags
firewall, iptables, server


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Iptables Configuration? SBN Linux - Security 6 11-13-2006 09:33 PM
Iptables configuration gurl4sh25 Linux - Security 5 10-10-2006 01:20 AM
iptables configuration help mousie Linux - Security 2 09-01-2005 01:57 PM
iptables configuration props666999 Linux - Security 3 08-28-2005 02:32 PM
iptables configuration help Alien#007 Linux - Networking 1 08-12-2005 01:32 PM


All times are GMT -5. The time now is 06:42 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration