Stealth port scanning protection

RouterOS General
1

Hi everyone,

We are using the following port scanning script on input and forward chains, and it works ok if someone is trying to scan all ports and generates a lot of traffic.



add chain=input protocol=tcp psd=21,3s,3,1 action=add-src-to-address-list address-list=“port scanners” address-list-timeout=2w comment="Port scanners to list " disabled=no
add chain=input protocol=tcp tcp-flags=fin,!syn,!rst,!psh,!ack,!urg action=add-src-to-address-list address-list=“port scanners” address-list-timeout=2w comment=“NMAP FIN Stealth scan”
add chain=input protocol=tcp tcp-flags=fin,syn action=add-src-to-address-list address-list=“port scanners” address-list-timeout=2w comment=“SYN/FIN scan”
add chain=input protocol=tcp tcp-flags=syn,rst action=add-src-to-address-list address-list=“port scanners” address-list-timeout=2w comment=“SYN/RST scan”
add chain=input protocol=tcp tcp-flags=fin,psh,urg,!syn,!rst,!ack action=add-src-to-address-list address-list=“port scanners” address-list-timeout=2w comment=“FIN/PSH/URG scan”
add chain=input protocol=tcp tcp-flags=fin,syn,rst,psh,ack,urg action=add-src-to-address-list address-list=“port scanners” address-list-timeout=2w comment=“ALL/ALL scan”
add chain=input protocol=tcp tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg action=add-src-to-address-list address-list=“port scanners” address-list-timeout=2w comment=“NMAP NULL scan”
add chain=input src-address-list=“port scanners” action=drop comment=“dropping port scanners” disabled=no

Unfortunately we see that nothing gets flagged when someone is using stealth scanning or trying certain ports:

nmap -sS -Pn 192.168.0.1 -p 3380,80,5060,8291,22

PORT STATE SERVICE REASON
22/tcp filtered ssh no-response
80/tcp filtered http no-response
3380/tcp filtered sns-channels no-response
5060/tcp filtered sip no-response
8291/tcp open unknown syn-ack ttl 56

Is there something that can be tweaked more in order catch attempts?

Please advise

Thank you

Please add basic portScan tool ( port scanner scan )
2

I just use:

chain=input action=add-src-to-address-list protocol=tcp psd=21,3s,3,1 address-list=Port_Scanner address-list-timeout=4w2d in-interface=1-Internet log=no log-prefix="" 
chain=input action=drop protocol=tcp src-address-list=Port_Scanner log=no log-prefix="Port_Scan Drop rule in effect"
3

When reading firewall manual, one has to understand what do parameters of psd property mean … psd takes 4 parameters:

  1. WeightThreshold
    total weight of the latest TCP/UDP packets with different destination ports coming from the same host to be treated as port scan sequence
  2. DelayThreshold
    delay for the packets with different destination ports coming from the same host to be treated as possible port scan subsequence
  3. LowPortWeight
    weight of the packets with privileged (<1024) destination port
  4. HighPortWeight
    weight of the packet with non-priviliged destination port

In your example you set WeightThreshold to 21 and the sum of weights, result of port scanning, should exceed this setting to add source address to the list of port scanners.
Now, your port scan did the following: it scanned total of 5 ports, of those 3 are high ports (2260,560 and 8291) each with weight of 1, and 2 are low ports (80,22) each with weight 3. So weights summed up are merely 9 and don’t exceed threshold of 21.

The next thing is Delay Threshold … manual states it is “delay for the packets with different destination ports coming from the same host to be treated as possible port scan subsequence” … now, when potential attacker performs stealth (a.k.a. SYN) scan and target ports are filtered (ROS wirewall drops packets), sender sends SYN packet and then waits for some period of time and if SYNACK is not received, it re-sends SYN packet and waits again. Different TCP stacks might implement different TCP timeouts and attacker might opt for shorter timeouts, but linux default timeouts are usually longer than 1 second. Thus with shown setting Delay Threshold might not trigger when potential attacker moves on to next port (setting of 3 seconds should usually be fine though).

4

My “DelayThreshold” is even set to a whopping 12 hours. So basically anyone probing my WAN-IP from the same IP on ports not related to DNAT etc within a 12h time-span are registered.
I have a constant 450-500 IP’s on that list which remains quite stable.

5

In this case you have to be careful with ordering of rules … If you have more than a handful of different ports forwarded, the rule which detects port scanning and adds source address to the list should be after the rule which accepts dst-nated connections … or else legitimate users of exposed services could get on the list as well in case when they use more than one service within DelayThreshold …

What I’m trying to say is that one has to think carefully how to set the psd parameters so that it does detect attackers but doesn’t block legitimate users. Blindly applying someone else’s settings may work but might fail as well.

6

Very true, but for that PSD-rule I used the flag !dnat so I would think inbound (legit) packets for a DNAT-stream are not affected or “in scope” to be thrown on the list. That seems to work. I only have some public available DNAT’s for Torrents and they don’t seem to suffer.
All other services are hidden behind a complex “port knock” sequence (and that port-knock sequence is ABOVE my "catchrule with PSD-attributes)

It seems to work fine for my purposes, I have been tweaking & tuning … a lot!

7

@jvanhambelgium … that’s what I was trying to explain … one has to be careful and understand things. If OP blindly applied your setting of DelayThreshold=12h without knowing background of you extensively tweaking other FW settings things might bite him mightly.

8

:sunglasses: :smiley:

9

Port scan detection works in input chain, while dstnated packets are accepted in forward chain :slight_smile:

10

Indeed.

11

So my question is simple!

How much better performance (positive impact) is ‘created’ with port scanning rules VICE simply
DROP ALL ELSE at end of input chain and forward chain.

Is it worth it??


(Plus if it is found to be of sufficient extra value, is it better to detect in input chain and drop in raw vice drop in input chain?)

12

Off course a more simple rule would be more efficient. For me, this RouterOS box is just to play around with. Various rules allow for granular logging-tags which I feed into Splunk again to learn about these tools.
If I was to run production/corporate devices, for sure I would not be toying around with this and have a simple drop at the end and follow the KISS principle.

13

Disclaimer: I don’t bother with port scanning detection.

The idea might be the following: a potential attacker might first use port scanning to build inventory of services on target device. Then it would try to exploit the detected services.

Now, with PSD in place (and working), it is possible to prevent attacker from getting full service inventory (if they get blocked during the scanning process) … and it is possible to protect exposed services from being accessed by attackers. The block-the-rest doesn’t do either of them.

Now my reason for not doing port scanning detection: I strongly believe that majority of service attacks (and misuses) are targeted at single service at the time and PSD wouldn’t trigger on them. Which means one has to protect exposed services (on app level) and PSD doesn’t help whole lot at it. If services are not meant for general public, then normal firewall rules should do the trick.

Further more, there are services which attacker doesn’t have to probe for existence … such as DNS servers (one can do some parsing of public databases to get an extensive list of domains and use public DNS servers to get IP addresses of relevant DNS servers) or SMTP servers (information source is again DNS). Some smart use of internet search engines reveals plenty of FQDNs for HTTP/HTTPS servers. Etc.

At the end of the day it might appear that PSD is not a very strong tool and relying on it might even lead firewall admin to do sub-optimal job.

In corporate environment one would run proper IDS system instead of playing around with toys such as PSD.

14

Interesting discussion. I tend to agree, one will not be the FOCUS of an attack unless there is something of value to the hacker. If you do then commensurate resources should be spent on protecting that data.
For most fly by night trolling, hacker will tend to look for common ports and most of us don’t have any open.
The only port some might consider probing and thus using as a capture to block is the default MT winbox port, so a scan detect on that, may be useful(obviously no admin would still use the default port or leave it open to the net :wink:)