1. sshguard
  2. sshguard
  3. sshguard
  4. Issues
Issue #69 new

Subnet matching and blocking

Daniel Aleksandersen
created an issue

SSHGuard needs to be able to recognize an attack originating from a given subnet.

The current recommendation is delegating /64 to a residential network means one source IP can switch to another IP address and never be recognized by SSHGuard. A simpler attack could keep an IP address up until it is blocked, and then switch to another address and continue the attack at no cost. All the lightbulbs and bathroom scales in my home theoretically have access to 18 446 744 073 709 551 61 IPv6 addresses and they can change address as fast as their sockets can handle it. That are a lot of potential attackers.

The firewall integration should be fairly simple for at least some firewalls like pf, ipset, ipfilter, and firewalld. Just slap a CIDR notation at the end of the address to block and you’re done (172.27.5.10/24).

Matching a subnet in the requires some reworking for the lexer. Frankly, I’m not entirely sure what the best approach here would be. I’d suggest that adjusting the IPv4 and IPv6 lexer rules based on a INET_SUBNET="24" or INET6_SUBNET="64" option so the matched result would be transformed to a implicit subnet (10.10.10.0). Not entirely sure how to acheive this as the lexer is a bit of a mystery to me.

I’m setting the priority on this to critical as I’m seeing several attacks from /24 and especially /64 on my own opublic facing server every week. SSHGuard either fails to detect these entirely, or when it does see them: blocking becomes ineffectual.

Ideas? comments? implementors?

Comments (3)

  1. Kevin Zheng

    I think this is a desirable feature. I'm undecided whether this should be default on or off; there should definitely be a way to disable this, though.

    The tricky part is deciding on the size of the subnet to block. Thanks to CIDR, we either have to guess the subnet (as you mention above) or do some sort of lookup.

    First step is to update sshg-fw to deal with blocks correctly. Most firewalls should work without changes; some might need some tweaking. I know pf and ipfw are fine; what about the others?

  2. Daniel Aleksandersen reporter

    Most firewalls should work without changes; some might need some tweaking,

    Then all but iptables are fine with CIDR notations. From some quick Google searches, it looks like iptables needs a 10.10.10.10/255.255.255.0 to block a /24. Since everyone else agrees on CIDR notations, I’d say we change the address that is output by sshg-blocker to the backend to append a CIDR notation when a when the subnet option is specified. The iptables backend will need some lines of custom code to write a CIDR notation to its own format, but this is trivial.

    The tricky part is deciding on the size of the subnet to block.

    This isn’t difficult at all. The default endpoint delegation for residential ISPs is /32 for IPv4 and /64 for IPv6. Hosting providers seem to use the same delegation. I’d say we enable /64 by default for IPv6 and leave the option disabled but with a default suggestion of /24 for IPv4.

  3. Log in to comment