# Gentoo Sabayon - IPTables Question

## suntzu2007

I just switched to Linux three days ago, so my apologies if this question sounds lame. Having searched the forum (and others) but being unable to find a solution, I'll try my luck here:

I would like to modify my iptables to only allow me to browse (so block everything else except 80). 53 I believe is necessary for DNS. However when executing the script, everything appears to be blocked i.e. I can't browse.

Any help or links that could clarify this would be greatly appreciated.

Thanks in advance,

```
#!/bin/sh

iptables -F 

iptables --policy INPUT DROP 

iptables --policy OUTPUT DROP

iptables --policy FORWARD DROP

iptables -A OUTPUT -p icmp -j REJECT --reject-with THIS OPERATION IS NOT PERMITTED ON THIS MACHINE

iptables -A INPUT -i lo -j ACCEPT 

iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -p tcp --sport 80 -j ACCEPT

iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT

iptables -A INPUT -p udp --dport 53 -j ACCEPT

iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
```

----------

## jonnevers

 *suntzu2007 wrote:*   

> 
> 
> ```
> #!/bin/sh
> 
> ...

 

I'm just not sure these rules make any sense. 

1) You don't need to allow incoming traffic on port 80 or 53... unless this is a web and DNS server. Request reply-backs are automatically accepted if you initiated the connection.  A server's reply to a request on port 80 won't generally come back on port 80, the server will generally grab a much higher port number for the communication beyond initial connection stuff.

2) you're blocking outgoing ICMP packets? why not just incoming packets from other machines? is this machine used by people other then you? people that you don't want to have ping access to outside machines?

3) I could be wrong here, but I think for things like DNS you need to allow through UDP *and* TCP packets. I'm fairly sure DNS will respond to either and it's up the DNS client to make the determination of which protocol to use.

4) doing what you are doing with the --policy DROP stuff is absolutely RIGHT. You set these first and if no subsequent rules apply, the communication is summarily dropped. These are important and should remain. Though I personally and completely disagree with  categorically dropping all unidentified OUTPUT connection attempts. This is a severe limitation on the computer.

----------

## Hu

 *suntzu2007 wrote:*   

> 
> 
> I would like to modify my iptables to only allow me to browse (so block everything else except 80). 53 I believe is necessary for DNS. However when executing the script, everything appears to be blocked i.e. I can't browse.
> 
> ```
> ...

 

This is a very strange request.  I think you would be better served using a security system that controls outbound connections based on the process / user making the connection, rather than the remote port of the traffic.  It is trivially easy to send traffic on an unusual port to bypass such filters.

Try this:

```
#!/bin/sh

iptables -F 

iptables --policy INPUT DROP 

iptables --policy OUTPUT DROP

iptables --policy FORWARD DROP

# Allow loopback

iptables -A INPUT -i lo -j ACCEPT 

# Allow ESTABLISHED connections to remain up

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

iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT

# Allow connections to port 80

iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

# Allow DNS over UDP

iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

```

jonnevers: you are correct with regard to (3).  DNS can be done over TCP or UDP, but it is extremely rare to see DNS-over-TCP for typical name resolution requests.  It is mostly used for transfers that move more data than can be conveniently sent over UDP, such as a zone transfer.

----------

## GNUtoo

you have the owner part that can block applications:

```
  owner

       This module attempts to match various characteristics of the packet creator, for locally-generated packets.  It is only valid in the OUTPUT chain, and even this some packets (such as ICMP ping responses) may have no owner, and hence never match.

       --uid-owner userid

              Matches if the packet was created by a process with the given effective user id.

       --gid-owner groupid

              Matches if the packet was created by a process with the given effective group id.

       --pid-owner processid

              Matches if the packet was created by a process with the given process id.

       --sid-owner sessionid

              Matches if the packet was created by a process in the given session group.

       --cmd-owner name

              Matches if the packet was created by a process with the given command name.  (this option is present only if iptables was compiled under a kernel supporting this feature)

```

----------

## desultory

Just a note due to this topic having been reported as being misplaced.

Considering that iptables should be distribution neutral this topic will remain in this section, unless there is some other reason to move it.

----------

## suntzu2007

Thanks for the help everybody.

Any more suggestions for securing the box? Or should the tables be ok like that? It still doesn't seem to work...I changed the script to accept icmp packages:

```
iptables -A OUTPUT -p icmp -j ACCEPT
```

----------

## Sadako

I've been using a similarly strict iptables ruleset which works fine for me.

Here are my rules (somewhat simplified) if you want to take a look;

```
iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT DROP

iptables -A INPUT -i lo -j ACCEPT 

iptables -A INPUT -m state --state INVALID -j DROP

iptables -A INPUT -i eth0 -p udp -m udp --sport 53 -m state --state ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0 -p tcp -m tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0 -p tcp -m tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0 -p icmp -m state --state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -m state --state INVALID -j DROP

iptables -A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT

iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT

iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT

iptables -A OUTPUT -o eth0 -p icmp -m state --state NEW -j ACCEPT
```

I recommend adding tcp traffic on port 443 for https.

Also, I have the following saved as /usr/local/sbin/esync;

```
#!/bin/bash

INCOMING="INPUT -p tcp -m tcp --sport 873 -m state --state ESTABLISHED -j ACCEPT"

OUTGOING="OUTPUT -p tcp -m tcp --dport 873 -j ACCEPT"

/sbin/iptables -A $INCOMING

/sbin/iptables -A $OUTGOING

time emerge --sync

/sbin/iptables -D $INCOMING

/sbin/iptables -D $OUTGOING     

                                

exit
```

To allow rsync traffic during an `emerge --sync` (you just run esync instead).

----------

## suntzu2007

Great, thanks. It finally works. Just one last question: what does the esync script do?

----------

## Sadako

 *suntzu2007 wrote:*   

> Great, thanks. It finally works. Just one last question: what does the esync script do?

 It opens up port 873 before an emerge --sync, and then closes it again when the sync completes.

This is required as rsync (and therefore emerge --sync) transfers occur over port 873, so you wouldn't be able to update portage without opening that port.

You could look into using emerge-webrsync as alternative, but I think the above is definitely preferable.

Anyways, glad to help.

----------

## suntzu2007

I see now. Thanks for your help.

----------

