Menu
▾
▴
Re: [SSHGuard-users] Feature request and suggested patch to merge attacks from subnets
|
From: Testudo A. <tes...@po...> - 2021-01-10 10:51:33
|
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... <mailto: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... > <mailto:ssh...@li...> > https://lists.sourceforge.net/lists/listinfo/sshguard-users > <https://lists.sourceforge.net/lists/listinfo/sshguard-users> > > > > -- > James Harris > Software Engineer > jam...@gm... <mailto:jam...@gm...> |
