Menu
▾
▴
sshguard-users
|
From: <li...@la...> - 2016-07-28 07:20:52
|
Looking at the log, 162.144.102.19 is worthy of blocking, but it wasn't blocked. FreeBSD theranch 10.2-RELEASE-p18 FreeBSD 10.2-RELEASE-p18 #0: Sat May 28 08:53:43 UTC 2016 # ipfw table 22 list 23.96.234.230/32 0 123.57.174.156/32 0 180.153.88.54/32 0 182.18.34.76/32 0 Jul 28 04:48:34 theranch sshd[16612]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT! Jul 28 04:48:35 theranch sshd[16612]: Connection closed by 162.144.102.19 [preauth] Jul 28 04:52:03 theranch sshd[16629]: Received disconnect from 121.18.238.29: 11: [preauth] Jul 28 05:00:00 theranch sshguard[1242]: Reloading rotated file /var/log/maillog. Jul 28 05:04:34 theranch sshd[16695]: Received disconnect from 121.18.238.22: 11: [preauth] Jul 28 05:09:54 theranch sshd[16735]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT! Jul 28 05:09:54 theranch sshd[16735]: Connection closed by 162.144.102.19 [preauth] Jul 28 05:28:35 theranch sshd[16813]: Received disconnect from 221.194.44.216: 11: [preauth] Jul 28 05:31:02 theranch sshd[16825]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT! Jul 28 05:31:03 theranch sshd[16825]: Connection closed by 162.144.102.19 [preauth] Jul 28 05:37:51 theranch sshd[16851]: Received disconnect from 221.194.44.194: 11: [preauth] Jul 28 05:52:22 theranch sshd[16917]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT! Jul 28 05:52:22 theranch sshd[16917]: Connection closed by 162.144.102.19 [preauth] Jul 28 06:00:00 theranch sshguard[1242]: Reloading rotated file /var/log/dovecot.log. Jul 28 06:00:50 theranch sshd[16994]: Did not receive identification string from 23.96.234.230 Jul 28 06:05:36 theranch sshd[17014]: Invalid user z from 23.96.234.230 Jul 28 06:05:36 theranch sshd[17014]: input_userauth_request: invalid user z [preauth] Jul 28 06:05:36 theranch sshd[17014]: Received disconnect from 23.96.234.230: 11: Bye Bye [preauth] Jul 28 06:05:37 theranch sshguard[1242]: blacklist: added 23.96.234.230 Jul 28 06:05:37 theranch sshguard[1242]: 23.96.234.230: blocking forever (3 attacks in 287 secs, after 1 abuses over 287 secs) Jul 28 06:14:12 theranch sshd[17062]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT! Jul 28 06:14:12 theranch sshd[17062]: Connection closed by 162.144.102.19 [preauth] Jul 28 06:17:24 theranch sshd[17069]: fatal: Read from socket failed: Connection reset by peer [preauth] Jul 28 06:18:24 theranch sshd[17073]: Received disconnect from 121.18.238.19: 11: [preauth] Jul 28 06:35:23 theranch sshd[17150]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT! Jul 28 06:35:23 theranch sshd[17150]: Connection closed by 162.144.102.19 [preauth] Jul 28 06:56:47 theranch sshd[17210]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT! Jul 28 06:56:47 theranch sshd[17210]: Connection closed by 162.144.102.19 [preauth] |
|
From: Kevin Z. <kev...@gm...> - 2016-07-28 19:34:50
|
On 07/28/2016 00:20, li...@la... wrote: > Looking at the log, 162.144.102.19 is worthy of blocking, but it wasn't > blocked. This is not technically a bug because the code is behaving as written. I think the bug is in the policy itself. Here's what's going on: The "POSSIBLE BREAK-IN ATTEMPT" is not considered an attack. This message shows up when a reverse DNS lookup doesn't match, but the actual attack is the "Connection closed" line. They're not two separate attacks. Attackers are purged 30 minutes after their *first* attack, not their most recent attack. The first attack was at 04:48:34, and so by the time the third attack that would have triggered a block rolled around (05:31:03), the attacker's earlier attacks were already forgotten. This latter issue is something worth fixing. Suggestions? Perhaps it's better to change the policy to purge 30 minutes after the most *recent* attack. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: <li...@la...> - 2016-07-28 19:57:16
|
I think you have a "number of attacks" per some time period criteria. I think a simple lockout after the most recent attack is fine. But you must of had a reason for the more complicated criteria. I suppose if some IP attacked every 30 minutes until the end of time, it would be wrong to allow that behavior. How about the release time is based from the last attack, but if there is a trigger prior to release, the timer gets increased by say 15 minutes. Well no, that won't work because the attacker would just wait 30 minutes between attacks and never increase the time period. How about a simple 30 minute lockout, no fancy time increase, but the program makes a log for suggested blacklisting based on persistent attacks. Original Message From: Kevin Zheng Sent: Thursday, July 28, 2016 12:35 PM To: ssh...@li... Subject: Re: [SSHGuard-users] rev 1.7.0 not blocking all worthy of blocking On 07/28/2016 00:20, li...@la... wrote: > Looking at the log, 162.144.102.19 is worthy of blocking, but it wasn't > blocked. This is not technically a bug because the code is behaving as written. I think the bug is in the policy itself. Here's what's going on: The "POSSIBLE BREAK-IN ATTEMPT" is not considered an attack. This message shows up when a reverse DNS lookup doesn't match, but the actual attack is the "Connection closed" line. They're not two separate attacks. Attackers are purged 30 minutes after their *first* attack, not their most recent attack. The first attack was at 04:48:34, and so by the time the third attack that would have triggered a block rolled around (05:31:03), the attacker's earlier attacks were already forgotten. This latter issue is something worth fixing. Suggestions? Perhaps it's better to change the policy to purge 30 minutes after the most *recent* attack. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 ------------------------------------------------------------------------------ _______________________________________________ sshguard-users mailing list ssh...@li... https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Georg L. <jor...@ma...> - 2016-07-28 20:23:05
|
On 28/07/16 13:34, Kevin Zheng wrote: > On 07/28/2016 00:20, li...@la... wrote: >> Looking at the log, 162.144.102.19 is worthy of blocking, but it wasn't >> blocked. ... > Attackers are purged 30 minutes after their *first* attack, not their > most recent attack. The first attack was at 04:48:34, and so by the time > the third attack that would have triggered a block rolled around > (05:31:03), the attacker's earlier attacks were already forgotten. > > This latter issue is something worth fixing. Suggestions? Perhaps it's > better to change the policy to purge 30 minutes after the most *recent* > attack. > > Best, > Kevin > Hello, Attacks as I observer them typically are spread over time. I guess, that attackers already know, that they get more attention if they blindly hammer on the same host, so they distribute the attacks and better come back later to give it a try. I have set the -s option to 70 minutes instead of 30 and consider setting -p to 5 minutes to take care of this. Using the most recent attack time instead of the first, only shifts the time window, so in the next corner case the attacker gets forgotten. If I had a wish, I would like to be able to specify the coefficient for the (exponential?) back-off time. Currently it seems to be set fixed to 1.5 (man page, -p option). - - - Another idea: sshg-parse could be used for creating time series of the attacks, which can then be analyzed by statistical tools. Eventually we end up with an adaptive Kalman Filter or so ... - - - Best Regards, Georg Lehner |
|
From: Kevin Z. <kev...@gm...> - 2016-07-28 20:31:37
Attachments:
attacks.txt
attacks2txt
|
On 07/28/2016 13:21, Georg Lehner wrote: > If I had a wish, I would like to be able to specify the coefficient for > the (exponential?) back-off time. Currently it seems to be set fixed to > 1.5 (man page, -p option). I can do that. > Another idea: sshg-parse could be used for creating time series of the > attacks, which can then be analyzed by statistical tools. Eventually we > end up with an adaptive Kalman Filter or so ... The intent of splitting up the parser into a separate binary was to make it possible to plug it into other tools :) I actually have some data I collected. It's a bit limited in usefulness because SSHGuard blocks the attacker after 3 attempts. I've attached it here in case anyone wants to play with the data. Briefly, each line represents the attacks from an attacker. Each entry is the time of an attack (Unix time). -1 represents a block by SSHGuard. I've also included a script that breaks this data up into groups of 3 attacks that you can import into IPython. Have fun, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
Thanks for helping keep SourceForge clean.
X