Skip to contentSkip to conversation

state new with SYN not set

DISCUSSION Aleksander 3 participants 4 messages Feb 13, 2006

lore
Share & tools
lore

Aleksander

author
#0 lore raw

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

#1 lore raw
Quoted 15 lines · 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

Quoted 7 lines

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.

Quoted 4 lines

Thanks,
Alex

--
Stephen J Smoogen.
CSIRT/Linux System Administrator

author
#2 lore raw
Quoted 12 lines · Stephen J. Smoogen

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.

Quoted 4 lines

--
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

#3 lore raw

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 <[email protected]>:

Quoted 38 lines
Quoted 12 lines · Stephen J. Smoogen

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.

Quoted 4 lines

--
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