Menu
▾
▴
sshguard-users
|
From: <dt...@gm...> - 2016-02-14 18:37:04
|
I just filled out the survey. Some things I did not see and would really find
helpful:
(1) config file used to input/add to/change the regular expressions used to
trigger blocks
(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.
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.
I have a system sorely in need of updating because of access limitations. On
that system I have some scripts to sorta do what sshguard does. That system
gets an order (or more) in magnitude more attacks. I look forward to getting
there and updating that system.
_____
Douglas Denault
http://www.safeport.com
do...@sa...
Voice: 301-217-9220
Fax: 301-217-9277
|
|
From: Kevin Z. <kev...@gm...> - 2016-02-16 02:15:11
|
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! > (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. > 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 -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
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 |
|
From: Kevin Z. <kev...@gm...> - 2016-02-17 00:01:37
|
On 02/16/2016 00:53, Christophe Meessen wrote: > 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. The strategy I'm thinking about is to keep timestamps of the last few, say, 6 failed attempts from each address. Those with highly regular intervals between attacks would be considered attackers, as should those with very little delay between attempts. I would have to collect some data and see if this is viable, though. > 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. Thanks for your suggestions! Best, Kevin -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: <li...@la...> - 2016-02-16 08:57:35
|
If you look at the table 22 block list, you can spot IP addresses that are from the same organization. That is the IP addresses are close. You can prove the relation using www.ip2location.com or similar service. My point here being they could be used as a botnet to slow down the login attempts from any one IP address in the group, but the group all together can be sending login attempts at a high rate. (Basically there could be a distributed attack where each IP doesn't trigger sshguard.) I'm not really sure how you would alter sshguard to catch botnets since there is no requirement for every IP address an organization possesses to be clustered. For the services that sshguard protects, they don't have a particularly large attack surface as compared to say a Web server. (Obviously nothing is more critical than ssh, but there are only so many ways to knock on the door.) I'm just pointing this out as food for thought since there may be some nuance to networking to see these related attackers. I'd like to see sshguard protect all the common network services except for the web. As an aside, I saved one table 22 from sshguard as a snapshot to examine. Mostly for curiosity sake, but I have been adding all the VPS, colos, hosting companies, etc. caught by sshguard to my blocking list for nginx. I don't block ISPs and universities. The majority of the attempts are not from ISPs. If you add a regex scheme, I'd like to see a test mode flag for each regex. That is, see what is would like to block before actually enabling the blocking. I rarely get anything but the simplest regex correct on the first try. Original Message From: Kevin Zheng Sent: Monday, February 15, 2016 6:15 PM To: ssh...@li... Reply To: ssh...@li... Subject: Re: [Sshguard-users] configuration options 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! > (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. > 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 -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Sshguard-users mailing list Ssh...@li... https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Kevin Z. <kev...@gm...> - 2016-02-17 00:03:27
|
On 02/16/2016 00:57, li...@la... wrote: > If you add a regex scheme, I'd like to see a test mode flag for each > regex. That is, see what is would like to block before actually > enabling the blocking. I rarely get anything but the simplest regex > correct on the first try. Could you elaborate more about what you mean with this? Something like 'sshg-parser', which is currently built but installed, that only parses and classifies attacks from standard input without blocking? Thanks, Kevin -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
Thanks for helping keep SourceForge clean.
X