Community discussions

MikroTik App
 
MetUys
newbie
Topic Author
Posts: 31
Joined: Mon Mar 17, 2014 1:19 pm

TCP Null Scan (aka NMAP Scan)

Thu Jan 26, 2017 9:58 am

Hi all,

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):
/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::
(Aside): note that the wiki has this filter rule used throughout it in mean script dumps, but some of these there is a slight "commenting" misalignment with the TCP XMAS scan and the Null/NMAP scan... -> look at the flags and it will make sense. Ours is definitely the "TCP null / TCP() / no flags set" filter being triggered.

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 :P), 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.
 
R1CH
Forum Guru
Forum Guru
Posts: 1099
Joined: Sun Oct 01, 2006 11:44 pm

Re: TCP Null Scan (aka NMAP Scan)

Thu Jan 26, 2017 8:18 pm

Why bother checking for this specific packet in the first place? Filter SYN as appropriate and let the OS handle fragments or other weird packets. You can use conntrack "invalid" to match invalid packets for drop, but you should never add such packets to an address list (easy self-DoS with spoofed IP).

Who is online

Users browsing this forum: emunt6, TheCat12 and 79 guests