Firehol DROPping INVALID

Firehol DROPping INVALID

[Mark Hindley]

Hi,

I have asked this on the Firehol lists, but got no response. Hope you
can help.

I am using kernel 2.6.6 and have firehol setting up a firewall on the
gateway machine with eth0 LAN, ppp0 dial-up link. NAT for hosts on LAN

If the ppp link is down and a host on the LAN sends a packet destined
for the outside world, the icmp-unreacahble packet does not get
returned, so the LAN host has to wait to time out.

The offending command issued by firehol seems to be: 


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

Although the comment says this is recommended in the Netfilter HOWTO, I
cannot find it.

I can get round it by adding

iptables -I OUTPUT 2  -m state --state INVALID -p icmp --icmp-type  destination-unreachable -j ACCEPT

which inserts the ACCEPT before the DROP above and means that hosts on
the LAN get an immediate icmp reply "destination-unreachable" if the
ppp link is down.

Is this wise? secure. Am I missing something.

Thanks for your help

Mark

Re: Firehol DROPping INVALID

[Antony Stone]

On Saturday 05 June 2004 9:17 pm, Mark Hindley wrote:

> Hi,
>
> I have asked this on the Firehol lists, but got no response. Hope you
> can help.

I know nothing about (have never heard of) firehol, however here's my 
observation on the rule you've quoted.

> iptables -A OUTPUT -m state --state INVALID -j DROP
>
> Although the comment says this is recommended in the Netfilter HOWTO, I
> cannot find it.

It seems like a rather strange rule to have, to me.   Why would you expect 
your own machine to be generating invalid packets (and therefore go to the 
bother of writing a firewall rule to drop them)?

I'd be interested to know the response you get from the author of firehol if 
you ask for the source of the recommendation.

I can understand why you might want to drop *incoming* invalid packets, but 
outgoing ones would seem to me to be (a) someone else's problem - they can 
decide whether to accept them or not - and (b) an indication of some more 
fundamental problem with whatever application is generating such packets, 
which should be fixed, rather than using netfilter to ignore the problem and 
pretend the packets never happened.

Therefore my recommendation would be to eliminate the above rule altogether.

Most people secure their firewall against inbound problems (INPUT for the 
firewall itself, FORWARD for machines it is routing to) - outbound problems 
should not exist.

Maybe you want to post the rest of your ruleset so we can comment on how 
sensible that seems for you?

Regards,

Antony.

-- 
"The problem with television is that the people must sit and keep their eyes 
glued on a screen; the average American family hasn't time for it."

 - New York Times, following a demonstration at the 1939 World's Fair.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Firehol DROPping INVALID

[Aleksandar Milivojevic]

Antony Stone wrote:
> On Saturday 05 June 2004 9:17 pm, Mark Hindley wrote:
> 
> 
>>Hi,
>>
>>I have asked this on the Firehol lists, but got no response. Hope you
>>can help.
> 
> 
> I know nothing about (have never heard of) firehol, however here's my 
> observation on the rule you've quoted.
> 
> 
>>iptables -A OUTPUT -m state --state INVALID -j DROP
>>
>>Although the comment says this is recommended in the Netfilter HOWTO, I
>>cannot find it.
> 
> 
> It seems like a rather strange rule to have, to me.   Why would you expect 
> your own machine to be generating invalid packets (and therefore go to the 
> bother of writing a firewall rule to drop them)?

Interesting.  Just last night I installed new Linux-based firewall 
(Fedora Core 2 bundled iptables, stock Fedora Core 2 build of 
kernel-2.6.5).  I wrote firewall rules by hand, and observed exactly the 
same behaviour.

For the initial config, I used simplified set of rules that put 
restrictions only on WAN side, LAN was left unrestricted.  The rules 
looked something like this (recreating from memory) (eth0 is LAN, eth1 
is WAN):

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
#
#   Anything invalid should be dropped and logged prompto
#
-A INPUT -m state --state INVALID -j LOG --log-prefix "INVALID INPUT "
-A INPUT -m state --state INVALID -j DROP
-A OUTPUT -m state --state INVALID -j LOG --log-prefix "INVALID OUTPUT "
-A OUTPUT -m state --state INVALID -j DROP
-A FORWARD -m state --state INVALID -j LOG --log-prefix "INVALID FORWARD "
-A FORWARD -m state --state INVALID -j DROP
#
#   Allow already established connections
#
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
#
#   Local network is unrestricted, as well as local host
#
-A INPUT -i eth0 -s 192.168.0.0/24 -m state --state NEW -j ACCEPT
-A FORWARD -i eth0 -s 192.168.0.0/24 -m state --state NEW -j ACCEPT
-A OUTPUT -m state --state NEW -j ACCEPT
#
#   Log everything else
#
-A INPUT -j LOG --log-prefix "INPUT "
-A OUTPUT -j LOG --log-prefix "OUTPUT "
-A FORWARD -j LOG --log-prefix "FORWARD "
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth1 -s 192.168.0.0/24 -j MASQUERADE

After applying these rules, I got bunch of invalid packets in output 
chain.  When I get back home I can look and post exact logs (and recheck 
that above rules are exactly what I have on the firewall).  From memory, 
source IP was firewall LAN interface (192.168.0.f), destination IP was 
Windows box on LAN (192.168.0.w).  They were ICMP unreachables for 
packet that originated from Windows box (192.168.0.w) to outside DNS 
server (142.something), if I remember correctly.

I've never seen this before.  I've spent an hour trying to find error or 
typo, and trying different things, but couldn't get rid of those invalid 
packets in output chain.

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7