As of recent we have started getting problems legitimate clients/staff/users's IPs getting caught by the TCP null scan (i.e. TCP packet with no flags set) filter.
What we have detected is its finding a TCP() packet during FTP calls from FileZilla on windows 10 (Build 1607).
(FYI: it seems to only start occurring after doing the windows 10 upgrade to the anniversary build, pre-this build and with earlier versions of Filezilla it was never triggered)
the latest version (as of present) doesn't fix it (FileZilla nor Windows) and we have logged this with both providers.
My question is not about either how to fix FileZilla/windows, but more two part query with Mikrotik users:
1. A probe to see if anyone else is having the same problems of late?
2. How should we look to adjust our filter rules in order to still be "filtered" for this port scan but be less disruptive to our users behind the firewall/router.
We are using the block-address method on this detection, as follows (and referenced often as the action of choice in the wiki):
Code: Select all
/ip firewall filter add action=add-src-to-address-list address-list=blocked-addresses address-list-timeout=1d chain=sanity-check protocol=tcp tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg comment="Add TCP Null Stealth Scan <Blocked 1 Day>" log=yes log-prefix=block-tcp-null-scan::
MY thoughts are to drop or reject packet instead of block it.
but here lies my dilemma....
RFC 793 states that if a TCP segment arrives with no flags set, the receiving host should drop the segment and send an RST.
However Windows hosts do not comply with this RFC. Subsequently, you cannot use a NULL scan against a Windows machine to determine which ports are active.
When a Microsoft operating system receives a packet that has no flags set, it sends an RST packet in response, regardless of whether the port is open or closed.
With all NULL packets receiving an RST packet in response, you cannot differentiate open and closed ports.
UNIX-based systems do comply with RFC 793; therefore, they send RST packets back when the port is closed and no packet when the port is open.
So depending on the action could lead to difference interpretations of our system... hmmm.
I was thinking to apply the drop/reject to the local addresses only and leave the block on unknowns, but we have seen this with clients trying to connect to our FTP server from the wild (yes also using FileZilla ), which obviously is a much more harder thing to thwart since we do not require an ACL listing for access to this FTP server (and cannot due to the nature of our product offerings).
So looking for guidance on what would be better.