Shorewall users - Dec 2002 - Strange log messages, "SPT=80 DPT=0" ?

Hello,

I am running shorewall locally on a webserver. Recently I have seen a few of
these messages, I cannot locate any commentary on them elswhere, except:

http://mail.shorewall.net/pipermail/shorewall-users/2002-January/000009.html

In the archived shorewall mailing list message (above) Tom mentions orphaned
DNS replies, but the cause of such packets was apparently service (DNS)
related.

Dec 12 03:02:24 carter kernel: Shorewall:all2all:REJECT:IN= OUT=eth0
SRC=216.xxx.xxx.20 DST=151.204.98.127 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=0
DF PROTO=TCP SPT=80 DPT=0 WINDOW=5840 RES=0x00 ACK SYN URGP=0

Dec 12 01:53:43 carter kernel: Shorewall:all2all:REJECT:IN= OUT=eth0
SRC=216.xxx.xxx.20 DST=151.204.100.73 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=0
DF PROTO=TCP SPT=25 DPT=0 WINDOW=5840 RES=0x00 ACK SYN URGP=0

Anyone seen these types of messages, ie, rejected packets with a DPT=0 ?
Know what they are / might be?

Thanks,
alex@rettconsulting.com

--On Friday, December 13, 2002 01:07:07 PM -0800 Alex Martin 
<alex@rettconsulting.com> wrote:
> Hello,
>
> I am running shorewall locally on a webserver. Recently I have seen a few
> of these messages, I cannot locate any commentary on them elswhere,
> except:
>
> http://mail.shorewall.net/pipermail/shorewall-users/2002-January/000009.h
> tml
>
> In the archived shorewall mailing list message (above) Tom mentions
> orphaned DNS replies, but the cause of such packets was apparently
> service (DNS) related.
>
> Dec 12 03:02:24 carter kernel: Shorewall:all2all:REJECT:IN= OUT=eth0
> SRC=216.xxx.xxx.20 DST=151.204.98.127 LEN=44 TOS=0x00 PREC=0x00 TTL=64
> ID=0 DF PROTO=TCP SPT=80 DPT=0 WINDOW=5840 RES=0x00 ACK SYN URGP=0
>
> Dec 12 01:53:43 carter kernel: Shorewall:all2all:REJECT:IN= OUT=eth0
> SRC=216.xxx.xxx.20 DST=151.204.100.73 LEN=44 TOS=0x00 PREC=0x00 TTL=64
> ID=0 DF PROTO=TCP SPT=25 DPT=0 WINDOW=5840 RES=0x00 ACK SYN URGP=0
>
> Anyone seen these types of messages, ie, rejected packets with a DPT=0 ?
> Know what they are / might be?
I''ve not seen this before.

Given that IN=<empty> and the "ACK SYN", these appear to be your
server''s
responses to the first stage of the 3-way TCP session establishment 
protocol. It would be interesting to know if the original SYN packets had 
SPT=0 -- that might indicate some new form of SYN attack and since your 
servers appear to be responding to it, it could be effective.

I can concoct a trap for SYNs with SPT=0 if you are willing to try it -- 
what version of Shorewall are you running?

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net

On Saturday 14 December 2002 01:31, you wrote:
> --On Saturday, December 14, 2002 12:44:03 AM +0000 Steven Jan Springl
>
> <shorewall@springl.fsnet.co.uk> wrote:
> > I have managed to recreate this type of log entry with a program
called
> > hping2. So far I have only been able to do so by issuing the command
from
> > the  firewall itself.
>
> Have you tried sending a SYN packet:
>
> a) From a system outside the firewall
> b) To the firewall
> c) With SPT=3D0
> d) With the firewall configured to accept net connections on the
> destination port; and
> e) With the firewall configured to reject all outbound traffic (except the
> RELATED,ESTABLISHED rule that Shorewall provides)
>
> The log message in the original post looks like it was a response to a SYN
> from outside. The original SYN entered the firewall through the
''net''
> interface which means that traffic through that interface is fairly well
> restricted.
>
> My theory (totally untested) is that source port 0 on an inbound SYN packet
> may trigger something in NetFilter connection tracking that prevents the
> connection from being properly entered in the connection tracking table; or
>
> The inbound connection is properly entered into the connection tracking
> table but the response (SYN ACK) isn''t correctly associated with
that
> connection because of the bogus destination port number in the response=2E
>
> -Tom
Hi Tom.
    Sorry for taking so long with this, unfortunatly I have not been able to=20
recreate this error. The interesting thing that I found was that a policy of=20
(all  all DROP) will not drop an outbound (SYN ACK) packet from the firewall,=20
even if it is not related to a previous inbound SYN  packet. I had to add a=20
rule of (DROP fw all tcp)  to drop the packet. (note this applies to all=20
ports not just 0)  =20
I also found that adding logunclean to the interface produced a kernel error=20
message stating that port 0 is inavlid.

During the testing the ability to specify a rule that just logs packets=20
without accpeting, rejecting or dropping them would have been vey useful. eg
LOG0:info  fw  wan tcp 0
LOG1:info  wan fw  tcp 0
this would produce a log entries with LOG0  and LOG1 as an identifiers.
I don''t know how easy it would be to add this feature or if anybody
else would=20
find it useful.=20

Regards Steven.

--On Monday, December 16, 2002 08:41:14 PM +0000 Steven Jan Springl 
<shorewall@springl.fsnet.co.uk> wrote:
>     Sorry for taking so long with this, unfortunatly I have not been able
> to  recreate this error. The interesting thing that I found was that a
> policy of  (all  all DROP) will not drop an outbound (SYN ACK) packet
> from the firewall,  even if it is not related to a previous inbound SYN
> packet.
It will if you set NEWNOTSYN=No.
> I had to add a  rule of (DROP fw all tcp)  to drop the packet.
> (note this applies to all  ports not just 0)
> I also found that adding logunclean to the interface produced a kernel
> error  message stating that port 0 is inavlid.
What do you mean "kernel error"? Was this logged by the ipt_unclean
module?
If so, that''s what it does -- it produces messages when it finds
something
about a packet that it doesn''t like.
>
> During the testing the ability to specify a rule that just logs packets
> without accpeting, rejecting or dropping them would have been vey useful.
> eg LOG0:info  fw  wan tcp 0
> LOG1:info  wan fw  tcp 0
> this would produce a log entries with LOG0  and LOG1 as an identifiers.
> I don''t know how easy it would be to add this feature or if
anybody else
> would  find it useful.
>
I''ll give it some thought...

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net

On Monday 16 December 2002 21:09, you wrote:
> --On Monday, December 16, 2002 08:41:14 PM +0000 Steven Jan Springl
>
> <shorewall@springl.fsnet.co.uk> wrote:
> >     Sorry for taking so long with this, unfortunatly I have not been
able
> > to  recreate this error. The interesting thing that I found was that a
> > policy of  (all  all DROP) will not drop an outbound (SYN ACK) packet
> > from the firewall,  even if it is not related to a previous inbound
SYN
> > packet.
>
> It will if you set NEWNOTSYN=3DNo.
Yes I agree, I was testing with NEWNOTSYN=3DYes.
But why the discrepancy between the way the policy and the rule
work?
>
> > I had to add a  rule of (DROP fw all tcp)  to drop the packet.
> > (note this applies to all  ports not just 0)
> > I also found that adding logunclean to the interface produced a kernel
> > error  message stating that port 0 is inavlid.
>
> What do you mean "kernel error"? Was this logged by the
ipt_unclean module?
> If so, that''s what it does -- it produces messages when it finds
something
> about a packet that it doesn''t like.
Yes it was an ipt_unclean module. I was suggesting it as a possible way of=20
detecting the inbound SYN packet rather than you writing a trap, as Alex=20
Martin did not mention seeing these messages.
>
> > During the testing the ability to specify a rule that just logs
packets
> > without accpeting, rejecting or dropping them would have been vey
useful.
> > eg LOG0:info  fw  wan tcp 0
> > LOG1:info  wan fw  tcp 0
> > this would produce a log entries with LOG0  and LOG1 as an
identifiers.
> > I don''t know how easy it would be to add this feature or if
anybody else
> > would  find it useful.
>
> I''ll give it some thought...
>
> -Tom
Steven.

--On Monday, December 16, 2002 09:30:42 PM +0000 Steven Jan Springl 
<shorewall@springl.fsnet.co.uk> wrote:
> On Monday 16 December 2002 21:09, you wrote:
>> --On Monday, December 16, 2002 08:41:14 PM +0000 Steven Jan Springl
>>
>> <shorewall@springl.fsnet.co.uk> wrote:
>> >     Sorry for taking so long with this, unfortunatly I have not
been
>> >     able to  recreate this error. The interesting thing that I
found
>> > was that a policy of  (all  all DROP) will not drop an outbound
(SYN
>> > ACK) packet from the firewall,  even if it is not related to a
>> > previous inbound SYN packet.
>>
>> It will if you set NEWNOTSYN=No.
> Yes I agree, I was testing with NEWNOTSYN=Yes.
> But why the discrepancy between the way the policy and the rule work?
NEWNOTSYN=Yes allows for connection tracking to resume after a reboot of 
the firewall. To make that happen (more or less) reliably, I''ve found
that
ACK packets need to be ACCEPTed even when they are not part of an 
established connection. I can try changing the rule to not pass SYN ACK and 
see how that works.
>>
>> > I had to add a  rule of (DROP fw all tcp)  to drop the packet.
>> > (note this applies to all  ports not just 0)
>> > I also found that adding logunclean to the interface produced a
kernel
>> > error  message stating that port 0 is inavlid.
>>
>> What do you mean "kernel error"? Was this logged by the
ipt_unclean
>> module? If so, that''s what it does -- it produces messages
when it finds
>> something about a packet that it doesn''t like.
> Yes it was an ipt_unclean module. I was suggesting it as a possible way
> of  detecting the inbound SYN packet rather than you writing a trap, as
> Alex  Martin did not mention seeing these messages.
I see. Turns out that I''ve added a SPT=0 test to the
''tcpflags'' option and
Alex has installed it. Thanks for pointing out that
''logunclean'' also
detects this case.

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net

--On Monday, December 16, 2002 02:43:34 PM -0800 Tom Eastep 
<teastep@shorewall.net> wrote:
>
> NEWNOTSYN=Yes allows for connection tracking to resume after a reboot of
> the firewall. To make that happen (more or less) reliably, I''ve
found
> that ACK packets need to be ACCEPTed even when they are not part of an
> established connection. I can try changing the rule to not pass SYN ACK
> and see how that works.
>
After I sent this post, I began reflecting on the history of NEWNOTSYN:

o Shorewall originally implemented behavior similar to NEWNOTSYN=Yes

o Rather abruptly, I switched to behavior resembling NEWNOTSYN=No. That
  resulted in several complaints, so I added the NEWNOTSYN option. I
  personally prefer NEWNOTSYN=Yes behavior so that is what I use.

o At various times, I experienced:

	a) repeated attempts by my server to send a SYN ACK packet which
	   Shorewall was rejecting/logging.
	b) RSTs being dropped/rejected/logged.

o I realized that my new NEWNOTSYN=Yes ruleset did not include two
  traditional rules in the common chain:

	iptables -A common -p tcp --tcp-flags ACK ACK -j ACCEPT
	iptables -A common -p tcp --tcp-flags RST RST -j ACCEPT

o I released a change that adds these two rules when NEWNOTSYN=Yes

It is the first of these that causes SYN ACK packets to be accepted even 
though there is a policy in force that drops such packets.

Given that ''NEWNOTSYN=No'' gives you the choice of rejecting
such packets, I
think I will leave the ruleset the way it is.

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net