Hi, I enabled ufw yesterday, and am finding log entries like:
Jun 30 13:07:51 xxxx kernel: [15702368.296557] [UFW BLOCK] IN=eth1 OUT= MAC=00:22:19:5e:8f:23:00:0c:db:fc:8b:00:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=47632 PROTO=TCP SPT=58875 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0

What is puzzling is I did the command: ufw allow 80. Anyone know what might be going on?

Can you cross-reference this with your HTTP server's log files?

Was the source address making authorized use of your server? If so, what was the time/date range?

Interesting, they're all links to our newsletter banner, and seem legit, just accessed through email instead of a browser. Actually, I should say, the links preceeding the blocked ones. They come a couple of minutes before the blocked timestamps.

I don't use ufw, but I just installed it on a test box to see what the default rule set looks like, and after a quick glance I saw it filters packets in state INVALID (and it applies the "[UFW BLOCK]" prefix to the log entries when it does so, just like you're seeing). So basically, one possibility is that these packets are being sent to DROP because they are in state INVALID, which would imply that the relevant IPs were not in the state table any more. Perhaps the clients are using buggy software and/or awkward termination methods (the packet has the FIN and ACK bits set)? In any case, it should be easy for you to verify whether that is what is happening by manually inserting a LOG rule for packets in state INVALID at the top of your INPUT chain, then comparing it to what ufw is generating:If it does turn out to be the INVALID match at work here (I don't know why ufw doesn't make log file entries more specific), then maybe you can find a common denominator amongst the different IPs which are causing these entries? Like, maybe they are the same OS or user agents?

I did add that log entry like you said, and couldn't find anything similar about the entries at all, except that they were all either "ACK FIN" "ACK RST" and one was "ACK PSH". I found on google this person writing in response to someone asking about ACK FIN dropped packets (sorry I lost the link):

"Yes, I would agree with the above - blocking RST-ACK does no harm whatever,
and is often an accidental consequence of using stateful firewalls - they see

the RST packet (and pass it on), then drop the details from the connection
tracking table, so by the time the RST-ACK comes along in response, the
firewall thinks "this isn't part of any established connection, so I'm going

to drop it" (and maybe log it too if you are logging dropped packets).

Either way, the connection gets dropped as required, and both ends are happy,
because the end which sent the RST has said bye-bye anyway, and the end which

recieved it has taken the hint and gone quiet too.

The other thing you see logged quite often for similar reasons is FIN-ACK
packets - the reply FIN-ACK is regarded as optional by many systems, so
netfilter often ends up logging (and dropping) the second one to come along.

No harm done though, because the first one has done the job."

That's great, it means the test was successful (you confirmed the packet is being filtered somewhere else).

No worries. Here it is: http://lists.netfilter.org/pipermail...ne/053782.html

Yeah, that sounds like what I was thinking (that the packet was coming from a non-hostile IP which was simply not in the state table anymore). It would have been nice if he would have elaborated a bit - perhaps hinted at which systems are known for doing this.

1 members found this post helpful.