Re: Question; what is this netfilter logfile entry ?

["Bo Jacobsen" <subs@systemhouse.dk>]

> >
> > Nov 14 02:24:48 WF1-HOME kernel: DENY-OUT:.IN= OUT=eth0 SRC=192.168.1.2 DST=198.41.0.4 LEN=560 TOS=0x00 PREC=0xC0 TTL=64 ID=3123 PROTO=ICMP TYPE=3 CODE=3 [SRC=198.41.0.4 DST=192.168.1.2 LEN=532 TOS=0x00 PREC=0x00 TTL=49 ID=41159 PROTO=UDP SPT=53 DPT=51981 LEN=512 ]
> > 
> > It looks like ICMP with an embedded DNS call  ?.
> 
> It's an ICMP port unreachable. Looks like 198.41.0.4 tried to send a
> reply to one of your DNS queries, took too long to respond, and by the
> time they did the port was closed. What's kind of interesting is that it
> was a full size answer so I'm guessing the truncation bit was set. This
> means that if this packet had been returned in time your system would
> have had to switch to TCP to get a full answer.
> 
> The UDP info is embedded in the payload so the remote system knows which
> port was unreachable. This is in case multiple session were running at
> the same time. Perfectly normal for an ICMP error packet.
> 
> > What is it exactly, and how would a rule to allow this look like ?
> 
> This would be permitted if you are letting "RELATED" traffic through.
> This ensures that only legit ICMP errors are passed. While you could
> define an accept rule for the ICMP type code, this would let all
> matching traffic through opening up the possibilities of a covert
> communication channel. 
> 
It has something to do with PSD. When it's "enabled" the problem arises 
trigered by  prior PSD denials to DNS traffic comming from unknown external
ip's. With no iptables PSD statements it never happens.

On our inside we have djbdns acting as an internal forwarding DNS server. 
When PSD closes trafffic of like this, this type of "traffic" is taking up all 
internet bandwith, and filling up the syslog message log. If djbdns is
killed / restarted the traffic stops, and everything works again. If just left 
alone, after a minute or two, everything goes back to normal.
Maybe djbdns starts spewing out DNS requests, and is denied the reply
because a trigered PSD will not allow any DNS response back in.

Strangely enough, we have only seen this problem when 
accessing the www.space.com

We currently run iptables 1.2.8 on a 2.4.21 kernel. We have not yet tested it with 
a 2.6 kernel.


Bo