FTP sessions triggering port scanning rules...

I have a port scan rule that adds IPs to a “black list” for a period of time when detected. The rule based on:

PSD
Weight Threshold 21
Delay Threshold 00:00:03
Low Port Weight: 3
High Port Weight: 1

gets triggered when FTPing to remote hosts. Any suggestions on how I can tune this rule to avoid this?

have you tried adding the mikrotik default firewall rules which includes allowing established and related connections under the input chain?

This is for people who are behind the firewall and are (via SNAT) connecting to external FTP servers. This should be hitting the Forward chain.

In either case, we do allow established/related connections in both the INPUT and FORWARD chains…

could you perhaps copy and past the script for the port scan rule? here is the script from the wiki which ive tested
and works perfectly,tried give this one a go and see if you problem persists…

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

This is the rule that was causing the problems.

The difference between what I did and this is that I have this rule running in both the INPUT and FORWARD chains (i.e. I believe the wiki example only runs on the INPUT chain). I thought it would be good idea to look for port scans that were going across interfaces, but perhaps that was flawed thinking?!

if you put that rule under the input chain, it spans across all interfaces by default,eliminating the need to add it to any other
interfaces manually,hope it helps :slight_smile:

We tried using a 21 weight in 3 seconds as shown for the Port Scan and found it would flag pretty much anyone downloading a directory full of small files. Passive FTP uses a unique port # on each file transfer, and CuteFTP Pro defaults to 5 concurrent connections, as you can imagine a weight of 21 can be achieved very easily in this setup. Even a 42 weight was hit multiple times by clients connecting to their FTP sessions. We are currently experimenting with a weight of 84, in hopes that a legitimate client doesn’t actually retrieve 84 files in 3 seconds (28 files a second).