Shorewall users - May 2002 - bad packets

I''ve been seeing quite  a few of these messages in my log.  The SRC
address is my ISP''s pop server and the DST is a box on my internal net
that''s running fetchmail.
 
May  9 18:44:35 FW72 kernel: Shorewall:badpkt:DROP:IN=ppp0 OUT=eth0
SRC=165.212.11.120 DST=192.168.110.101 LEN=52 TOS=0x00 PREC=0x00 TTL=31
ID=9121 PROTO=TCP SPT=110 DPT=4137 WINDOW=33120 RES=0x00 ACK URGP=0 OPT
(000000000DBEACBF00825855)
 
I''m not competent to completely analyze the message beyond fact that
it''s a bad tcp packet headed from the pop server pop service back to my
box.  Could someone point me at the appropriate doco that will let me
understand what''s wrong with the packet?  (or just explain it).
 
Once I understand I may try to let the ISP know if it looks like a
problem on their end.  (although dealing with Telstra in Australia is
like trying to convince the Taliban that an occasional beer is a good
thing).
 
 
Thanks;
 
Roy

On Thu, 9 May 2002, Roy Barkas wrote:
> I''ve been seeing quite  a few of these messages in my log.  The
SRC
> address is my ISP''s pop server and the DST is a box on my internal
net
> that''s running fetchmail.
>  
> May  9 18:44:35 FW72 kernel: Shorewall:badpkt:DROP:IN=ppp0 OUT=eth0
> SRC=165.212.11.120 DST=192.168.110.101 LEN=52 TOS=0x00 PREC=0x00 TTL=31
> ID=9121 PROTO=TCP SPT=110 DPT=4137 WINDOW=33120 RES=0x00 ACK URGP=0 OPT
> (000000000DBEACBF00825855)
>  
> I''m not competent to completely analyze the message beyond fact
that
> it''s a bad tcp packet headed from the pop server pop service back
to my
> box.  Could someone point me at the appropriate doco that will let me
> understand what''s wrong with the packet?  (or just explain it).
>
These messages should be accompanied by a second cryptic message that 
indicates what the Netfilter ''unclean'' module thinks is wrong
with the
packet. In this case, it looks like the TCP options are hosed -- a null 
byte terminates the options and there should be no non-null bytes 
following the first null; clearly that is not the case in the above 
packet so you should see something like "TCP option 0D after end".


Problems of this sort are by far the most common cause of
''unclean'' packet
reporting. A similar one that I''ve seen a lot is where an
implementation
uses null padding to align timestamps (which are 8 bits) when it should be
using 0x01 as a padding byte. I think there''s still a link on my web
site
to a patch that I wrote that turns off this whole check.

I don''t recommend using the ''dropunclean'' option on a
production firewall.
If you want to check on unclean packets, use ''logunclean'' so
that the
packets are logged but not dropped. The log messages can be useful
sometimes to understand why a connection is slow or mis-behaving but there
are just too many broken IP stacks out there to drop packets that have
these minor cosmetic problems.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ teastep@shorewall.net