# Simple IPtables setup

## psic

Hi, I've been trying to get IPtables up and running on a local server. I've been reading the forum

and the wiki but I just need a very simple setup - block everything except a few ports (ssh, samba,

ftp...). I've been following this site on the wiki, specifically the part of the '/etc/iptables.bak' file, but for some reason the command 'iptables-restore /etc/iptables.bak' it gives me the error 'iptables-restore: line 1 failed' (in the case that I comment out the first line, it says the same thing for the second, third, etc.). Adding commands directly seems to work - by this I mean 'iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT'.

I've compiled everything which is listed in the wiki in the kernel itself, along with some other options (to be on the safe side). 

Any ideas? Can I just add the relevant rules to /var/lib/iptables/rules-save? Most how-tos I've come across explain how to setup a firewall that stands between a WAN and LAN, but I just want something simple  :Smile: 

Thanks in advance.

----------

## alex.blackbit

please post the content of your iptables.bak.

if you want something simple, try shorewall, i like it very much.

there is also a second helper... i think the name is firestarter.

----------

## boris_qd

I downloaded the following script from the internet somewhere and it does what i want (close all ports except ssh for non localhost connecitons, leave ports open for localhost).

Not sure if it's useful to you or not.

```

iptables -F

iptables -P INPUT DROP

iptables -P OUTPUT ACCEPT

iptables -P FORWARD DROP

export WAN=eth0

#Then we lock our services so they only work from the LAN

iptables -A INPUT -i lo -s 127.0.0.1 -j ACCEPT

# Accept previously established connections

#iptables -A INPUT -i ${WAN} -m conntrack --cstate ESTABLISHED -cproto ssh -m recent --remove

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#iptables -A INPUT -p tcp --dport ssh -i ${WAN} -m state --state NEW -m recent --update --seconds 60  --hitcount 3 -j DROP

iptables -A INPUT -p tcp --dport ssh -i ${WAN} -m state --state NEW -m recent --set

iptables -A INPUT -p TCP --dport ssh -i ${WAN} -m state --state NEW -j ACCEPT

#Drop everything else by default

iptables -A INPUT -j DROP

#Tell the kernel that ip forwarding is OK

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

for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done

#This is so when we boot we don't have to run the rules by hand

/etc/init.d/iptables save

```

----------

## Hu

 *boris_qd wrote:*   

> 
> 
> ```
> 
> #Then we lock our services so they only work from the LAN
> ...

 

This line is incorrect.  You should not specify a source address when specifying the rule to permit traffic on lo.

----------

## boris_qd

Could you elaborate what you mean by incorrect?

The script does what i want: It allows outgoing/established connections, incoming for ssh, and everything from localhost.

I've explicitly checked that all ports except ssh are closed for non localhost connections.

So what do you mean by incorrect?  Is it overdefined? underdefined?  Why does it work?  What do you think it does?  Can i just delete that line?

Thanks.

----------

## mmoufid

 *Hu wrote:*   

>  *boris_qd wrote:*   
> 
> ```
> 
> #Then we lock our services so they only work from the LAN
> ...

 

 *boris_qd wrote:*   

> So what do you mean by incorrect?

 

I am also curious what you mean by "incorrect" because I have been using similar rules:

```
iptables -A INPUT -i lo -s 127.0.0.1     -j ACCEPT

iptables -A INPUT -i lo -s <exterior IP> -j ACCEPT
```

Since iptables accepts these rules with no complaints of syntax and such, I suppose you mean "incorrect" in terms of security practice.

It would seem to me that the most "correct" thing to do in terms of security would be to deny (-P INPUT DROP or REJECT) and then allow select trusted sources (e.g. 127.0.0.1). This would ensure that only you, i.e. 127.0.0.1, have access to local services, e.g. the CUPS administration page (http://localhost:631/).

psic: Since you're just looking for something simple, I agree with alex.blackbit's suggestion of using Shorewall: Gentoo Wiki page.

----------

## Hu

 *boris_qd wrote:*   

> Could you elaborate what you mean by incorrect?
> 
> The script does what i want: It allows outgoing/established connections, incoming for ssh, and everything from localhost.
> 
> I've explicitly checked that all ports except ssh are closed for non localhost connections.
> ...

 

Your rule only allows incoming localhost connections when you use the loopback IP address.  Suppose that eth0 has an IP address of 1.2.3.4.  Running ssh 1.2.3.4 results in an incoming connection with a source address of 1.2.3.4 and an incoming interface of lo.  Your rule would not match that connection, and the ssh would be denied even though it was a connection from the machine to itself.

 *mmoufid wrote:*   

>  *Hu wrote:*    *boris_qd wrote:*   
> 
> ```
> 
> #Then we lock our services so they only work from the LAN
> ...

 

You demonstrate my point.  Since you are specifying the source address, you need to track your external address(es) and add rules for each of them.

 *mmoufid wrote:*   

> Since iptables accepts these rules with no complaints of syntax and such, I suppose you mean "incorrect" in terms of security practice.

 

It is fine from a security perspective.  It is simply less convenient to do it your way.  I am not aware of any practical security gain from your way instead of mine.

 *mmoufid wrote:*   

> It would seem to me that the most "correct" thing to do in terms of security would be to deny (-P INPUT DROP or REJECT) and then allow select trusted sources (e.g. 127.0.0.1). This would ensure that only you, i.e. 127.0.0.1, have access to local services, e.g. the CUPS administration page (http://localhost:631/).

 

Agreed, it is safer to use a default deny policy.  I disagree in the use of a fixed source address instead of restricting the traffic by interface.

----------

## psic

A big thank-you for the shorewall suggestion, I kind of figured that was a GUI app., but I see that it is exactly what I'm looking for. The comments about that script are exactly what I've been stumbling across since I started. Someone gives a script that works (for them anyways), but there is a huge follow-up of add-ons, comments, other scripts, etc. This is exactly what I was trying to avoid.

Thanks again.

----------

## alex.blackbit

maybe i should have made clear that "frontend" does not mean gui.

----------

