Introduction

A port scan probes multiple TCP or UDP ports to identify exposed services. RouterOS can classify a TCP scanning pattern with the psd matcher, add the source address to a Dynamic Address List, and then drop later input traffic from that address. This is a supplementary control, not a substitute for allowing only required management access.

Prerequisites

  • A current RouterOS configuration backup and verified out-of-band, local, or allowlisted management access.
  • A correctly defined public interface or Interface List named WAN.
  • Connection Tracking enabled and a reviewed input-chain firewall policy.

01 — Scope the protection correctly

The input chain processes packets whose destination is the router itself. It does not process packets merely passing through the router; those use the forward chain. For port-scan protection of RouterOS management services, scope the rule to input and the public WAN interface or WAN Interface List.

Do not apply this detection blindly to LAN interfaces. Internal security tools, monitoring systems, or normal administrative activity can otherwise produce false positives and block legitimate users.

02 — Connection Tracking and psd

Connection Tracking maintains state information for tracked connections and supports several firewall features. The psd matcher is a heuristic port-scan detector: its parameters express a weight threshold, a delay window, and separate weights for low and high ports. Tune it for the actual exposure and traffic patterns rather than treating one value as universal.

RouterOS
/ip firewall connection tracking print
/ip firewall connection print

03 — Add the detection and drop rules

The first rule identifies a new TCP pattern from WAN and dynamically adds its source to port_scanners for one day. The second rule drops source addresses already on that list. Replace WAN with the correct Interface List name if your configuration uses another name.

RouterOS
/ip firewall filter
add chain=input in-interface-list=WAN protocol=tcp connection-state=new psd=21,3s,3,1 \
action=add-src-to-address-list address-list=port_scanners \
address-list-timeout=1d comment="Detect TCP port scanners from WAN"

add chain=input in-interface-list=WAN src-address-list=port_scanners \
action=drop comment="Drop detected port scanners from WAN"

04 — Rule order, logging, and review

Firewall filters are evaluated in rule order. Keep established and related input acceptance before detailed new-connection analysis where it matches the reviewed policy. Place the scanner detection before the drop rule, and place both before a final WAN input drop. Retain explicit allow rules for approved management sources and required services before the final deny rule.

A logging rule can be placed immediately before the terminating drop rule for investigation, but it must be rate-limited to avoid excessive CPU, storage, or log noise during an attack.

Optional rate-limited logging
/ip firewall filter
add chain=input in-interface-list=WAN src-address-list=port_scanners \
action=log log-prefix="port-scan " limit=5/1m,5 comment="Log detected scanners"

05 — Test safely

  1. Export or back up the current firewall configuration and preserve a trusted management path before changing rules.
  2. Verify that a normal approved management connection from an allowlisted source remains available.
  3. In an authorized isolated lab, generate a controlled test that matches the intended policy, then inspect the Dynamic Address List, rule counters, and rate-limited logs.
  4. Wait for the configured address-list timeout or remove only the specific test entry after verifying the result.

Troubleshooting

  • No matches: verify that traffic is actually destined for the router, reaches the selected WAN interface, uses TCP, and meets the psd threshold within its delay window.
  • False positives: review the address-list entries and logs, then narrow the interface scope, raise the threshold, shorten the timeout, or allowlist approved management systems according to policy.
  • Unexpected lockout: use the pre-verified console or trusted management path, inspect rule order, and restore the approved configuration rather than making blind changes from WAN.

Best Practices

  • Expose no router management service to WAN unless there is an explicit need; restrict allowed services and sources first.
  • Apply scanner detection only to the intended public ingress path and review Dynamic Address List entries periodically.
  • Use logging sparingly and rate-limit it; monitor firewall counters and logs rather than relying on one detection rule alone.

Frequently Asked Questions

Does an input rule protect LAN clients?

No. The input chain protects traffic addressed to the router itself. Traffic passing through the router is evaluated in the forward chain.

Is psd a complete protection against attacks?

No. It is a heuristic detector for a pattern. Pair it with minimal exposed services, source restrictions, strong authentication, updates, and monitoring.

Conclusion

A WAN-scoped RouterOS input policy can use psd to identify a scanning pattern, place the source in a timed Dynamic Address List, and drop subsequent router-directed traffic. Protect management services with explicit allow rules and final deny rules first, then tune and monitor scan detection to control false positives.

Official references

Share