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
