|
From: Christophe M. <chr...@me...> - 2016-02-16 08:54:08
|
Le 16/02/2016 03:15, Kevin Zheng a écrit : > On 02/14/2016 10:14, dt...@gm... wrote: >> (1) config file used to input/add to/change the regular expressions used to >> trigger blocks > This would be a pretty significant change since most of SSHGuard's > functionality is compiled into the binary. I'll keep this in mind, > though; it needs to be a lot easier to add more attack signatures. > > If this is something people are interested in, please comment! I would vote for this because it would significantly extend the application domain of sshguard. I would also suggest to change the application name because at first I thought sshguard was only for ssh. >> (2) A good number of attackers figure out the blocking parameters and then >> make a large number of requests at a rate that does not trigger >> blocking. I use sshguard on closed systems (no external users) and open >> systems, so my setting are very different as must (of my) users do not >> use keys and mistype their passwords. > Yes, there needs to be a better way to classify attackers. I'm confronted to such use case. An attacker has a script that tries to authenticate on my port 25 (Postfix) with a few minutes interval between each attempts. Although authentication on port 25 is not allowed he keeps hitting his head on the door. I wish it was possible to ban these attempts with a lower threshold and much longer period than the default. Fail2ban doesn't allow that. But this is not as bad as the one trying many hundreds of time per minutes. Fail2ban handles these well. I must admit I'm currently using fail2ban, but I keep an eye on sshguard. > >> A nice addition would be a trigger that more than <n> failures per day >> would trigger a block. The duration should also be optional but at >> least a day. It could be <n> attempts on more than <m> users. >> >> And on a much lower priority: a utility to prune the black list. Now I use the >> blacklist only on closed systems. > My thinking right now is to remove "blacklisting" as a special case and > simply treating them as a really like (say, 24 hour block). The > blacklist file could be replaced with a "SSHGuard state" file that saves > all current blocks so they can be reloaded if SSHGuard restarts. > > Best, > Kevin > -- Bien cordialement, Ch.Meessen |