Subnet matching and blocking

Issue #69 resolved
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 (11)

  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. Daniel Aleksandersen reporter

    Add support for blocking subnets in firewall backends.

    Defaults to blocking single addresses. Configurable with new IPV6_SUBNET and IPV4_SUBNET configuration options.

    Also introduce two new flag options, -N and -n, to pass subnet sizes to backend but these are undocumented in favor of config files.

    FirewallD backend uses ipset command to flush rather than recreate the ipset with FirewallD tools. Reloads firewall configuration less often.

    Partially resolves issue #69. Subnet based attack source matching not included in this work, only blocking.

    → <<cset 6da2b6a28774>>

  4. Daniel Aleksandersen reporter

    Pull request #31 implements subnet blocking.

    Subnet matching will require quite a bit more work, and can be implemented separately. The blocking code shouldn’t require any changes to support blocking matched subnets in the future.

  5. Daniel Aleksandersen reporter

    Add support for blocking subnets in firewall backends.

    Defaults to blocking single addresses. Configurable with new IPV6_SUBNET and IPV4_SUBNET configuration options.

    Also introduce two new flag options, -N and -n, to pass subnet sizes to backend but these are undocumented in favor of config files.

    FirewallD backend uses ipset command to flush rather than recreate the ipset with FirewallD tools. Reloads firewall configuration less often.

    Partially resolves issue #69. Subnet based attack source matching not included in this work, only blocking.

    → <<cset bbba99d3efed>>

  6. Daniel Aleksandersen reporter

    Add support for blocking subnets in firewall backends.

    Defaults to blocking single addresses. Configurable with new IPV6_SUBNET and IPV4_SUBNET configuration options.

    Also introduce two new flag options, -N and -n, to pass subnet sizes to backend but these are undocumented in favor of config files.

    FirewallD backend uses ipset command to flush rather than recreate the ipset with FirewallD tools. Reloads firewall configuration less often.

    Partially resolves issue #69. Subnet based attack source matching not included in this work, only blocking.

    → <<cset c4209762cba9>>

  7. Daniel Aleksandersen reporter

    Add support for blocking subnets in firewall backends.

    Defaults to blocking single addresses. Configurable with new IPV6_SUBNET and IPV4_SUBNET configuration options.

    Also introduce two new flag options, -N and -n, to pass subnet sizes to backend but these are undocumented in favor of config files.

    FirewallD backend uses ipset command to flush rather than recreate the ipset with FirewallD tools. Reloads firewall configuration less often.

    Partially resolves issue #69. Subnet based attack source matching not included in this work, only blocking.

    → <<cset 05477fca90c8>>

  8. Log in to comment