I have a logging entry before the drop all on my input chain. Every(?) HTTP request creates an entry like this:
DROP input: in:DSL out:(none) … proto TCP (ACK,RST), web.server.ip.address:80->mikro.tik.ip.address:someport, len 40
I’ve also noticed that the byte/packet count for the Accept established and accept related connections is 0
It looks like it might have something to do with this rule:
add chain=sanity-check protocol=tcp tcp-flags=rst action=jump jump-target=drop comment=“Drop TCP RST”
As RST packets are part of normal TCP operations I wouldn’t drop them. They’re only a problem if they’re combined with other flags such as SYN which is illegal and can indicate a port scan.
Regards
Andrew
Andrew,
Thanks! I got that from the Dmitry on firewalling Mikrotik Wiki
There was also this rule. Any idea if it is a keeper?
add chain=sanity-check protocol=tcp tcp-flags=fin,syn action=jump jump-target=drop comment=“Drop TCP SYN+FIN”
SYN & FIN together is an illegal combination. You can safely drop those.
Regards
Andrew
I’m still getting tons of these entries. I also noticed my “sanity check” rule that accepts related connections gets no hits on bytes or packets.
[quote]I also noticed my “sanity check” rule that accepts related connections gets no hits on bytes or packets[quote]
That’s probably normal. FTP data connections are the only things I’ve noticed that trigger these rules.
SYN/FIN packets are a good indication of a port scan. Do some checks on the IP addresses generating these packets, see if you can identify the computers.
Regards
Andrew
Andrew,
Thanks for the info re: related packets. This makes sense.
Unfortunately, the IPs that are associated with the SYN/FIN packets appear to be web servers (i.e. Google, msn.com, etc). I’ve noticed these entries when web surfing + the traffic seems to be originating from HTTP responses (i.e. source port is 80)…
in:DSL out:(none) … proto TCP (ACK,RST), web.server.ip.address:80->mikro.tik.ip.address:someport, len 40
in:DSL out:(none) … proto TCP (ACK,RST), web.server.ip.address:80->mikro.tik.ip.address:someport, len 40
That isn’t a SYN/FIN packet. Let’s see some examples along with the traffic that immediately preceeded it.
Regards
Andrew
Sorry – I wasn’t very clear. I had theorized that the traffic could have something to do with the SYN/FIN FW rule I posted earlier. I really ought to study up on how TCP works, but I’m more of a software engineer than a network engineer 
I’ll see if I can get a Wireshark trace of the whole enchilada. Thanks for your help BTW!
-Ian