state new with SYN not set

state new with SYN not set

[Aleksander]

Hello list,

My firewall drops packets, which state is NEW, but no SYN bit is set. 
Now I started logging these dropped packets and there are loads of them. 
All connecting to the 443 port from random IP's (legitimate clients). 
The service is https. The service works fine, but I'm still worried 
about the dropping.

The rules:
${IPTABLES} -t filter -A bad_tcp_packets -p tcp --tcp-flags ! SYN SYN -m 
state --state NEW -j LOG --log-prefix "BAD PACKET N
EW+!syn: "
${IPTABLES} -t filter -A bad_tcp_packets -p tcp --tcp-flags ! SYN SYN -m 
state --state NEW -j DROP

An example, from the FORWARD chain:
Feb 13 11:18:38 myname kernel: BAD PACKET NEW+!syn: IN=eth1 OUT=eth0 
SRC=1.2.3.4 DST=192.168.111.34 LEN=75 TOS=0x00 PREC=0x00 TTL=56 ID=47503 
DF PROTO=TCP SPT=36086 DPT=443 WINDOW=32942 RES=0x00 ACK PSH FIN URGP=0

What should I think of this?

Thanks,
    Alex

Re: state new with SYN not set

[Stephen J. Smoogen]

On 2/13/06, Aleksander <aleksander@krediidiinfo.ee> wrote:
> Hello list,
>
> My firewall drops packets, which state is NEW, but no SYN bit is set.
> Now I started logging these dropped packets and there are loads of them.
> All connecting to the 443 port from random IP's (legitimate clients).
> The service is https. The service works fine, but I'm still worried
> about the dropping.
>
> The rules:
> ${IPTABLES} -t filter -A bad_tcp_packets -p tcp --tcp-flags ! SYN SYN -m
> state --state NEW -j LOG --log-prefix "BAD PACKET N
> EW+!syn: "
> ${IPTABLES} -t filter -A bad_tcp_packets -p tcp --tcp-flags ! SYN SYN -m
> state --state NEW -j DROP
>
> An example, from the FORWARD chain:
> Feb 13 11:18:38 myname kernel: BAD PACKET NEW+!syn: IN=eth1 OUT=eth0
> SRC=1.2.3.4 DST=192.168.111.34 LEN=75 TOS=0x00 PREC=0x00 TTL=56 ID=47503
> DF PROTO=TCP SPT=36086 DPT=443 WINDOW=32942 RES=0x00 ACK PSH FIN URGP=0
>
> What should I think of this?
>

Many times this is because of late packets getting to your server. It
might be because the server has finished the session (it saw a FIN or
RST on its side) and so has closed down the session.. or it might be
that the client didn't get the servers RST/FIN and is sending a second
ACK/PSH/FIN to make sure the session is closed.

There are probably other reasons for this, but this has been my
biggest number. There are some probe tools that just send ACK-PSH-FIN
packets to see what they get back from firewalls.


> Thanks,
>     Alex
>
>


--
Stephen J Smoogen.
CSIRT/Linux System Administrator

Re: state new with SYN not set

[Aleksander]

Stephen J. Smoogen wrote:

>Many times this is because of late packets getting to your server. It
>might be because the server has finished the session (it saw a FIN or
>RST on its side) and so has closed down the session.. or it might be
>that the client didn't get the servers RST/FIN and is sending a second
>ACK/PSH/FIN to make sure the session is closed.
>
>There are probably other reasons for this, but this has been my
>biggest number. There are some probe tools that just send ACK-PSH-FIN
>packets to see what they get back from firewalls.
>  
>
>
>--
>Stephen J Smoogen.
>CSIRT/Linux System Administrator
>
Thanks for the explanation!

I got another one:
Feb 13 15:39:10 myyr kernel: BAD PACKET syn+ack: IN=eth0 OUT=eth1 
SRC=192.168.111.34 DST=1.2.3.4 LEN=48 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF 
PROTO=TCP SPT=80 DPT=4081 WINDOW=5840 RES=0x00 ACK SYN URGP=0

 From my web server to a client, matched from:
${IPTABLES} -t filter -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK 
SYN,ACK -m state --state NEW -j DROP

I guess this can be ignored as well, it's just that it's originating 
from my web server on the LAN. I can't imagine any packets being caught 
by the firewall but then being lost on the way to the webserver. It's a 
decent 100Mbit link with only one switch on the way. There's not much 
network load either.

Alex

Re: state new with SYN not set

[David Vogt]

Maybe there is a problem with the network hardware? I don't really
know a lot about iptables, just crossed my mind while reading this.

David

2006/2/13, Aleksander <aleksander@krediidiinfo.ee>:
> Stephen J. Smoogen wrote:
>
> >Many times this is because of late packets getting to your server. It
> >might be because the server has finished the session (it saw a FIN or
> >RST on its side) and so has closed down the session.. or it might be
> >that the client didn't get the servers RST/FIN and is sending a second
> >ACK/PSH/FIN to make sure the session is closed.
> >
> >There are probably other reasons for this, but this has been my
> >biggest number. There are some probe tools that just send ACK-PSH-FIN
> >packets to see what they get back from firewalls.
> >
> >
> >
> >--
> >Stephen J Smoogen.
> >CSIRT/Linux System Administrator
> >
> Thanks for the explanation!
>
> I got another one:
> Feb 13 15:39:10 myyr kernel: BAD PACKET syn+ack: IN=eth0 OUT=eth1
> SRC=192.168.111.34 DST=1.2.3.4 LEN=48 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF
> PROTO=TCP SPT=80 DPT=4081 WINDOW=5840 RES=0x00 ACK SYN URGP=0
>
>  From my web server to a client, matched from:
> ${IPTABLES} -t filter -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK
> SYN,ACK -m state --state NEW -j DROP
>
> I guess this can be ignored as well, it's just that it's originating
> from my web server on the LAN. I can't imagine any packets being caught
> by the firewall but then being lost on the way to the webserver. It's a
> decent 100Mbit link with only one switch on the way. There's not much
> network load either.
>
> Alex
>
>