odd incoming packets

[James R. Van Zandt]

dsr wrote:
>On Fri, Sep 12, 2003 at 09:40:27PM -0400, James R. Van Zandt wrote:
>> I'd like to understand these entries in my syslog:
>> 
>> vanzandt:/var/log# grep Drop syslog|tail -6
>> Sep 12 20:19:14 vanzandt kernel: Dropping packet: IN=eth0 OUT=
>> MAC=00:50:ba:48:13:d8:00:06:25:dc:ad:a9:08:00 SRC=204.127.204.8
>> DST=192.168.1.102 LEN=78 TOS=0x00 PREC=0x00 TTL=242 ID=55166 DF
>> PROTO=UDP SPT=53 DPT=56639 LEN=58
>
>A UDP packet sent from port 53 to a random port on your system would be
>a DNS reply.
>
>> ...how are those packets getting through my router?
>
>The magic of NAT. Remember that UDP is not session oriented, and so a
>non-stateful packet filter has to let it in if it looks legit.


Okay, then why is my firewall complaining?  I'm using iptables, as
follows:

  ## Create chain which blocks new connections unless coming from inside.
  /sbin/iptables -N block
  /sbin/iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
  /sbin/iptables -A block -m state --state NEW -i ! eth0 -j ACCEPT
  ## drop IDENT requests silently
  /sbin/iptables -A block -i eth0 -m state --state NEW \
  	  -p tcp --destination-port 113 -j DROP
  ## permit SSH connections
  /sbin/iptables -A block -i eth0 -m state --state NEW \
          -p tcp --destination-port 22 -j ACCEPT
  ## log any other bad packets
  /sbin/iptables -A block -i eth0 -m limit -j LOG \
  	  --log-level warning --log-prefix "Dropping packet: "
  /sbin/iptables -A block -j DROP
  ## Jump to that chain from INPUT and FORWARD chains.
  /sbin/iptables -A INPUT -j block
  /sbin/iptables -A FORWARD -j block

As I understand it, the "RELATED" keyword is supposed to set up a
stateful packet filter, so I would expect DNS replies to be accepted
just like ftp data transfers.  In fact, DNS queries are working fine,
and at least some of the time they don't generate warnings:

  vanzandt:~ $ nslookup www.debian.org
  Server:  ns13.attbi.com
  Address:  204.127.204.8
  
  Non-authoritative answer:
  Name:    www.debian.org
  Address:  192.25.206.10
  
I'm using a 2.4.22 kernel.  In ip_conntrack_proto_udp.c, I see

  #define UDP_TIMEOUT (30*HZ)
  #define UDP_STREAM_TIMEOUT (180*HZ)

Maybe if the reply takes more than 30 sec (or 180 sec), the filter no
longer thinks it's "related"?

And the router's packet filter isn't stateful, so it allows anything
with a source port of 53?  Or maybe it just has a longer timeout?

	      - Jim Van Zandt