# Gentoo firewall example questions...

## The_Great_Sephiroth

I am always looking to improve my firewalls, and currently I drop everything on input except SSH and SAMBA. I also allow everything on "lo". Now, the example Gentoo firewall on the wiki has stuff that seems less secure.

```

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT

iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT

iptables -A INPUT -p icmp --icmp-type 12 -j ACCEPT

iptables -A INPUT -p tcp --syn --dport 113 -j REJECT --reject-with tcp-reset

```

First, why are we allowing these ICMP types in? What do they do? Next, Why are we rejecting IDENT requests instead of dropping them? Rejection tells the attacker that I am there, on whatever address.

*EDIT*

Here is my firewall script. I run this on new Gentoo workstations and then do "rc-service iptables save && rc-service ip6tables save".

```

#!/bin/bash

# Configure IPv4 firewalling

iptables -F

iptables -X

iptables -Z

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT ACCEPT

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p tcp -m state --state NEW -m multiport --dports ssh,135,139,445,3389 -j ACCEPT

iptables -A INPUT -p udp -m state --state NEW -m multiport --dports 137,138 -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT

# Configure IPv6 firewalling

ip6tables -F

ip6tables -X

ip6tables -Z

ip6tables -P INPUT DROP

ip6tables -P FORWARD DROP

ip6tables -P OUTPUT ACCEPT

ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ip6tables -A INPUT -i lo -j ACCEPT

```

I do not use IPv6 yet, so I did not worry with allowing Samba and SSH in it.

----------

## cboldt

The ICMP holes admit pings, traceroute/tracepath, and messages that inform your system about how the (outside) network is operating.

There is a reasonable argument that REJECT instead of DROP results in less total network traffic.  Yeah, the attacker knows you are there (but random attempts will occur even without that knowledge), but if the firewall and apps are secure, so what?  I recently changed my firewall from DROP to REJECT, and the net result is fewer persistent attempts.

----------

## Hu

If you allow any inbound connection attempts, an attacker can discover you using one of those ports.  Traditionally, ident was handled with REJECT to compensate for badly behaved IRC servers that would hang your client connection until they finished an ident lookup on you.  By using REJECT, you ensure that the ircd gets an immediate negative response, so that the ircd allows the IRC client to proceed to the next stage.  If you used DROP, then such IRC servers would not let you do anything until the TCP connect timeout expired.

----------

## cboldt

Are the workstations behind a router?  I run Samba here too, and the firewall is setup so only local network IP addys get through to Samba ports on any machine.  That is redundant or superfluous, because the router doesn't allow 137-139 or 445 through from the outside, but I notice that looking at your firewall alone, it opens Samba to the outside world.  If that is in fact what you have, I'd be monitoring the Samaba logs.

----------

## The_Great_Sephiroth

The systems at my home are behind a router running DD-WRT. At the office we have Wathguard routers, but are about to switch to Netgear routers with DD-WRT. So yes, we have decent firewalls. I also firewall everything the network both for added security and to prevent things like viruses on the Windows machines from spreading as easily.

The laptop I use as a Dell Latitude E6400 and it travels a lot. It runs Gentoo 64bit and the firewall I posted above. It travels to client locations, all of which have Wathguard routers or routers running DD-WRT. I normally do NOT use public WiFi because Linux does not appear to support network locations like Windows, yet. I would love for my system to be able to figure out which network I am on and apply the correct firewall like Windows, but I do not believe this is possible yet.

Again, this firewall is for workstations on a LAN, not for a router or for use on a public network.

----------

## cboldt

It's possible to have the firewall established based on the local network.  I've been doing it that way for years.  Not the standard "Gentoo" way, and don't get the benefit of fast save and restore from iptables-save / iptables-restore.

Use a script to set up the firewall.  Mine is called "establish-iptables"  This script runs AFTER the network is brought up, using the postup() function in /etc/conf.d/net.

```
postup() {

[ "${IFACE}" != lo ] && /etc/iptables/establish-iptables

}
```

The script gathers network configuration using `ifconfig` and `route` along with grep and awk to pick out the pertinent details; then runs iptables commands to build the firewall.  An alternative to "roll your own," one of the notes in my script claims that ipkungfu obtains (or more accurately, can be configured to obtain) some network configuration information dynamically, and quick inspections of ipkungfu tells me this is still true.

----------

## Hu

I suggest using iptables-restore to load the rules, rather than running multiple iptables commands.  The rules to load are provided on stdin, so you can provide different rules by choosing different rule template files based on what network you are on.

----------

## cboldt

That's a very good suggestion, using iptables-restore rather than multiple invocations of iptables.  The rationale and suggestions for how to do so can be found online, for example at http://www.iptables.info/en/iptables-save-restore-rules.html

----------

## CaptainBlood

These last three posts seem quite promising.

I've wondering how to for a while now...

I'll dig out if any of the suggested clues could match my requirements.

Thks 4 ur attention, interest & support

----------

## The_Great_Sephiroth

I believe ICMP type 8 is ping, not type 3, 11, or 12. The document linked below seems to confirm this. So why do I need "Destination Unreachable", "Time Exceeded", or "Parameter Problem" into my machine? I now have the following setup, pending an explanation here.

ICMP Type Codes

```

-P INPUT DROP

-P FORWARD DROP

-P OUTPUT ACCEPT

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT

-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT

-A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 113 --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with tcp-reset

-A INPUT -p tcp -m state --state NEW -m multiport --dports 22,135,139,445,3389 -j ACCEPT

-A INPUT -p udp -m state --state NEW -m multiport --dports 137,138 -j ACCEPT

-A INPUT -i lo -j ACCEPT

```

So, I understand the REJECT, but those ICMP types have me wondering. What say the networking gurus?

----------

## szatox

 *Quote:*   

>  So why do I need "Destination Unreachable", "Time Exceeded", or "Parameter Problem" into my machine?

  to let routers inform you about problems on links you're trying to use? Or, for example let you use traceroute?

----------

## The_Great_Sephiroth

That does not make sense. This is an inbound filter. Why would some router, out of the blue, contact my system to throw an ICMP error? If I have made a request and the router needs to respond, it should be able to due to the related/established rule. That is why I am asking.

----------

## The_Great_Sephiroth

New issue. My old, more basic firewall worked with PPTP VPN servers. This one does not. What am I doing wrong with this one?

----------

## The_Great_Sephiroth

I solved the PPTP issue. I had to specify the GRE protocol be allowed in. My firewall is now as follows.

```

-P INPUT DROP

-P FORWARD DROP

-P OUTPUT ACCEPT

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT

-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT

-A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 113 --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with tcp-reset

-A INPUT -p gre -j ACCEPT

-A INPUT -p tcp -m state --state NEW -m multiport --dports 22,135,139,445,3389 -j ACCEPT

-A INPUT -p udp -m state --state NEW -m multiport --dports 137,138 -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -i ppp0 -m state --state NEW -j ACCEPT

```

That one change allowed my PPTP VPN to work again. I am still looking for an explanation as to why I need those ICMP codes allowed IN.

----------

## cboldt

My firewall allows type 8 (ping) as new,related,established, type 0 as related,established; and if there is any other icmp traffic, it's logged (and allowed), basically for learning purposes.  In the past month, I've had a handful (six to be exact) of Type 3, Code 10.  I allow ping for internal (LAN) purposes, the router handles my desired reaction to ping requests from outside the LAN.

The worst that happens if you close those holes is less than preferred network operation, and if you log some fraction of icmp traffic (whatever you don't expressly allow), you'll get a handle on which type of packet tends to arrive in other than established,related condition.

My gut reaction is that you can close those holes, especially for new/syn packets.

----------

