Re: [SSHGuard-users] Feature request and suggested patch to merge attacks from subnets

[hvjunk <hv...@gm...>]

I do agree that with IPv6, you ctually want to score and block based on /64 (perhaps /80 minimum) to decide to block as that is the size allocated to a user/client/host typically. For memory/etc. reasons, I’d say to use a (variable?) minimum subnet size and when there had been $threshold attacks from that subnet, block that subnet, you could log it IPv6 addresses, but block on the subnet.

going bigger than /64 (and similar for IPv4), a sort of AI/learning mechanism where you should be looking at the attacks, and start to agregate from the bottom up, ie. if half the address space generated attacks originate in a single /24 (ie. 128 of 256) then it’s a good idea to block the /24. 

My concern with the above: it’ll either be crude (and blocking too many false positives) or too fine grained overburdening the CPU.
In essence, something I’ve been thinking about, is sshguard pulling (and submitting) from (configurable) servers IP list of attacks, then that server can correlate and aggregate/etc. 

> On 10 Jan 2021, at 12:51 , Testudo Aquatilis <tes...@po...> wrote:
> 
> Hello James,
> 
> I agree with you regarding IPv4. Here typically a machine gets a single address and subnet blocking is done manually after seeing a larger amount of attacks from a given subnet. But with IPv6 even single machines often get a /64 prefix assigned and thus can choose one of so many addresses to send from, that blocking could be ineffective or even circumvented.
> 
> My main goal was to allow this for IPv6, IPv4 was just added for consistency. But to not break existing functionality I would then suggest a second set of config variables and command line switches for the merge-prefix size (which then should be >= the existing subnet to block value).
> 
> So here an updated patch providing the attack-merge feature as separate option without breaking existing functionality (added -m/-M switches for the merge-prefix size in blocker). So if left at default sshguard behaves as before and if IPV6_MERGE_PREFIX and IPV6_SUBNET are set to e.g. 64 the described merging can be activated based on the assumption that an individual attacker has a /64 prefix assigned.
> 
> Regards,
> 
> Andreas
> 
> Am 10.01.21 um 01:22 schrieb James Harris:
>> Andreas,
>> 
>> I have been thinking about this type of change for a while. I don't know that threats come from clean subnets of similar sizes.  My guess is that threats are more strongly correlated to autonomous systems than just subnets.  I would guess fixed subnet sizes will just limit the number of rules proportional to the size of the subnetting.  I wonder if one approach might be to score based on AS then block all IPs associated with that AS. Similarly instead of a fixed subnet size pick some weights that allow a bigger subnet if there are enough attacks compared to the number of IPs represented in that group.  As these weights and subnet sizes vs number of firewall rules might need a significant amount of tuning I was thinking this might be an offline operation where the admin needs to approve the proposed ruleset.   
>> 
>> It might be better to gather real log data, possibly filtered to just remote IP for privacy reasons. Then simulate the different approaches on those data sets and determine what number of rules we get.  Finally run those rules through a few of the popular backend firewalls to determine performance impact.  
>> 
>> On Sat, Jan 9, 2021 at 2:40 PM Testudo Aquatilis <tes...@po...> wrote:
>> Hello,
>> 
>> as sshguard already has the feature to block subnets after an attack, I
>> would suggest to also merge attacks of the configured subnets.
>> Especially for IPv6 this would be quite useful because attackers might
>> have larger subnets available and could otherwise flood with attacks
>> from individual IPv6 addresses without getting blocked, as attacks are
>> counted individually.
>> 
>> The attached patch implements this to the best of my knowledge, so a
>> review would not harm. It basically uses arpa/inet.h functions, which
>> are also used in sshguard_whitelist.c. It parses the IP address into
>> integer format, applies the mask and writes the resulting address back
>> before further handling the attack.
>> 
>> The patch does what I would like to have as behavior when setting the
>> subnet config-variables, so using the same subnet-size for blocking and
>> merging is a feature from my point of view. But if this conflicts with
>> other use-cases, it might be considered to have 2 separate subnet-size
>> command-line flags and config variables for merging and for blocking.
>> 
>> Best regards,
>> Andreas
>> _______________________________________________
>> sshguard-users mailing list
>> ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>> 
>> 
>> -- 
>> James Harris
>> Software Engineer
>> jam...@gm...
> <0001-Blocker-allow-merging-of-attacks-from-subnets.patch>_______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users