0

I'm looking for ways to confuse port scanners. I do realize it is not that useful, but it is mostly to slow down attackers, and also to avoid ending up on websites like Shodan (or at least make the data irrelevant).

I came up with the following nftables rule (some details were omitted) :

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state invalid drop comment "early drop of invalid packets"

    # ICMP (rate limit to prevent icmp flood)
    ip protocol icmp ct state new limit rate 5/second counter accept comment "accept rate limited ICMP requests"
    ip protocol icmp counter drop

    # Accept already established/related connections
    ct state {established, related} accept comment "accept all connections related to connections made by us"

    # Log any failed inbound traffic attempt
    log flags all prefix "FIREWALL REJECTED INPUT: " counter

    # Send a random ICMP rejection type to confuse port scanners
    numgen random mod 16 == 0 reject with icmp type 0
    numgen random mod 16 == 0 reject with icmp type 1
    numgen random mod 16 == 0 reject with icmp type 2
    numgen random mod 16 == 0 reject with icmp type 3
    numgen random mod 16 == 0 reject with icmp type 4
    numgen random mod 16 == 0 reject with icmp type 5
    numgen random mod 16 == 0 reject with icmp type 6
    numgen random mod 16 == 0 reject with icmp type 7
    numgen random mod 16 == 0 reject with icmp type 8
    numgen random mod 16 == 0 reject with icmp type 9
    numgen random mod 16 == 0 reject with icmp type 10
    numgen random mod 16 == 0 reject with icmp type 11
    numgen random mod 16 == 0 reject with icmp type 12
    numgen random mod 16 == 0 reject with icmp type 13
    numgen random mod 16 == 0 reject with icmp type 14
    numgen random mod 16 == 0 reject with icmp type 15
  }

It works quite well against nmap. Many errors are thrown in nmap output ("unexpected ICMP type/code"), the output is very messy and hard to exploit, and the overall scan is way slower.

However I'd like to know if:

  1. There's a better way to write the random rejection part, something like {0-15} (which doesn't work), also I think it will generate up to 16 random numbers though I need only one. I tried to define a variable but it didn't manage to make it work.
  2. It can significantly slow down my machine (entropy exhaustion?)
  3. It can cause issues to other machines on my network (I'm thinking about multicast protocols which would receive these random responses)
  4. You think it's worth it overall (let's say for an internet facing server)

Related article: https://nmap.org/book/nmap-defenses-firewalls.html

0

You must log in to answer this question.

Browse other questions tagged .