Banning port scans using --recent iptables rules

Dear all,

When under IPv4 and using Fwbuilder for iptables, I used the --recent iptables rule to ban recurring IPs being rejected. The idea is as follows:

  • When a packet is rejected on WAN input, it is flagged recent and dropped. This is done using last rule on INPUT.
  • Then the first rule on input checks ANY packet for the recent flag and if it is present, the packet is dropped.

For example:

  • An attacker is banned on TCP port 22 and flagged "recent".
  • As the attacker is flagged "recent", during a certain amount of time, any connection from his IP is being rejected.

I remind that in Ipv6, you can even use this to reject all packets from an IPv6 subnet class.

Before I try something with the recent flag, did anyone of you implement it? It is one of the most powerful Iptables features. It does not require any additional software or logging, and only requires sufficient memory to hold the list of IPs in memory.

Kind regards,

Have you considered using snort as a flexible, robust, and proven IDS?

snort - 2.9.7.2-4 - Snort is an open source network intrusion detection and prevention system.
 It is capable of performing real-time traffic analysis, alerting, blocking
 and packet logging on IP networks.  It utilizes a combination of protocol
 analysis and pattern matching in order to detect anomalies, misuse and
 attacks.

To my point about OpenWRT/LEDE being too far behind in its source code, the current release is 2.9.9.0 from last December, 7 months ago. 2.9.7.2 is from March, 2015, two and a half years ago.

recent is already packaged, you can install it easy.

With recent, implementing a honeypot is easy. You open port 22 and run SSH on 1022. Then you flag recent connections to port 22 for a week or a month. It is lean, integrated in iptables and works like a charm. But I agree there are several ways of achieving the same goal.

Snort probably works very well, but I heard that you had to purchase your detection rules:
https://www.snort.org/users/sign_in
"Sign-in to purchase your detection rules"

What I would love in the end is a dedicated DNSBL ban list being managed in a database, where you centralize all banlists. I might work on that as my next-next project if nothing arises.

Like many successful open-source projects, you can purchase support of various kinds.

Better question is why would you be running a honeypot on a server that would be a disaster to lose? Putting ssh onto another port only slows down the script kiddies briefly. Buy a Raspberry Pi or Odriod for $40, or even a RPi Zero W if you can get your hands on one as your honeypot. Your exposed hosts should only accept keyed access to SSH, not password auth.