Menu
▾
▴
sshguard-users — User questions and answers, bugs, and general support
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
(10) |
Apr
(7) |
May
(6) |
Jun
(13) |
Jul
(4) |
Aug
|
Sep
|
Oct
(17) |
Nov
(5) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
(7) |
Jul
(10) |
Aug
(4) |
Sep
(14) |
Oct
|
Nov
(1) |
Dec
(7) |
| 2009 |
Jan
(17) |
Feb
(20) |
Mar
(11) |
Apr
(14) |
May
(8) |
Jun
(3) |
Jul
(22) |
Aug
(9) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
(8) |
| 2010 |
Jan
(17) |
Feb
(9) |
Mar
(15) |
Apr
(24) |
May
(14) |
Jun
(1) |
Jul
(21) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(6) |
Dec
(9) |
| 2011 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(29) |
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(13) |
May
(4) |
Jun
(9) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(11) |
Dec
(4) |
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
(4) |
Apr
(13) |
May
(4) |
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(3) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(6) |
May
(8) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(14) |
Dec
(8) |
| 2015 |
Jan
(16) |
Feb
(30) |
Mar
(20) |
Apr
(5) |
May
(33) |
Jun
(11) |
Jul
(15) |
Aug
(91) |
Sep
(23) |
Oct
(10) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(22) |
Feb
(8) |
Mar
(6) |
Apr
(23) |
May
(38) |
Jun
(29) |
Jul
(43) |
Aug
(43) |
Sep
(18) |
Oct
(8) |
Nov
(2) |
Dec
(25) |
| 2017 |
Jan
(38) |
Feb
(3) |
Mar
(1) |
Apr
|
May
(18) |
Jun
(2) |
Jul
(16) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(14) |
| 2018 |
Jan
(15) |
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
(8) |
Jun
(12) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(13) |
Nov
(15) |
Dec
(10) |
| 2019 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(5) |
Sep
(5) |
Oct
(12) |
Nov
(4) |
Dec
|
| 2020 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
|
May
(11) |
Jun
(1) |
Jul
(3) |
Aug
(22) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
|
| 2021 |
Jan
(7) |
Feb
|
Mar
(19) |
Apr
|
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(17) |
Feb
|
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(15) |
Apr
(8) |
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kevin Z. <kev...@gm...> - 2016-09-14 15:33:02
|
Hi Jim,
On 09/13/2016 09:50, Jim Seymour wrote:
> My lex/yacc fu is no longer very good, but I do know my way around
> REs. I believe this can be fixed in sshguard by changing each
> occurence of the following, in src/parser/attack_scanner.l, from
>
> {PROCESSNAME}("/"{PROCESSNAME})?
>
> to either
>
> {PROCESSNAME}("/"{PROCESSNAME})*
>
> or, probably better,
>
> {PROCESSNAME}("/"{PROCESSNAME}){0,2}
I believe your suggested fix is correct. I'll fix it soon-ish hopefully
and make sure everything else is still working.
Best,
Kevin
--
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090
|
|
From: Jim S. <jse...@Li...> - 2016-09-13 16:50:14
|
Hi,
I use postfix with the optional
-o syslog_name=postfix/submission
option in its main.cf configuration. This causes log lines to look
like (partial):
... postfix/submission/smtpd[24257]: warning:
unknown[185.110.132.134]: SASL LOGIN authentication failed: ...
rather than simply "...postfix/smtpd[24257]...
sshguard's parser fails to catch these.
This can be "fixed" by removing that option from postfix' config, but
then you lose logging detail.
My lex/yacc fu is no longer very good, but I do know my way around
REs. I believe this can be fixed in sshguard by changing each
occurence of the following, in src/parser/attack_scanner.l, from
{PROCESSNAME}("/"{PROCESSNAME})?
to either
{PROCESSNAME}("/"{PROCESSNAME})*
or, probably better,
{PROCESSNAME}("/"{PROCESSNAME}){0,2}
This does cause it to catch the missed log entries. But, without
thorough analysis of the remainder of the parsing code, I don't know,
for sure, that it won't induce other regression errors.
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.
|
|
From: Kevin Z. <kev...@gm...> - 2016-09-11 06:52:23
|
On 09/10/2016 13:13, Mark Chen wrote: > Just found this in my logs. Notice that the spammer alternates among > several addresses within the same class B network (in this case, two > different class Bs) in order to avoid detection. > > Any chance we could add a signature for this? Wow, that's impressive. I believe this discussion has happened before. I believe the conclusion was that it's beyond the scope of SSHGuard to do reverse lookups and block entire address ranges. Now that SSHGuard is being split up into several helper programs this might be doable as a sort of optional intermediate stage in the filter pipeline. Lately I've been a bit busy so I won't be able to take a look, but if someone's really interested in taking a whack at this I'd be happy to help. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: <li...@la...> - 2016-09-10 21:29:55
|
The data centers encourage "private links" since that get to sell more IP space. But the addresses can be anything on their ASN. http://stackoverflow.com/questions/13110386/ip-to-asn-mapping-algorithm I guess the reverse mapping is doable, but at what cost? BTW, I've never had sshguard find any funny business in my maillog, and it is being read as far as I can tell. That said, I would never use the same table to block ssh and email. There can be legitimate email coming from the same IP that is doing a dictionary attack on port 22. Worse yet, the IP that is dictionary attacking your email can also have legitimate email users on it. Other than the rate limiter in postfix, I'm pretty much exposed to these attacks. Now if sshguard detected an attack from postfix, it would make sense to block the IP from 22. That seems safe since the only way you would lock yourself out is if the attack came from behind your router, in which case you have real problems. Original Message From: Mark Chen Sent: Saturday, September 10, 2016 1:27 PM To: ssh...@li... Subject: [SSHGuard-users] New Attack Signature Just found this in my logs. Notice that the spammer alternates among several addresses within the same class B network (in this case, two different class Bs) in order to avoid detection. Any chance we could add a signature for this? > Sep 10 19:11:00 smtp postfix/smtpd[27607]: connect from unknown[182.38.196.133] > Sep 10 19:11:01 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno |
|
From: Mark C. <pub...@ch...> - 2016-09-10 20:31:51
|
Just found this in my logs. Notice that the spammer alternates among several addresses within the same class B network (in this case, two different class Bs) in order to avoid detection. Any chance we could add a signature for this? > Sep 10 19:11:00 smtp postfix/smtpd[27607]: connect from unknown[182.38.196.133] > Sep 10 19:11:01 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno > wn[182.38.196.133] > Sep 10 19:11:01 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.196.13 > 3] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:01 smtp postfix/smtpd[27607]: connect from unknown[182.38.137.123] > Sep 10 19:11:01 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno > wn[182.38.137.123] > Sep 10 19:11:01 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.137.12 > 3] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:03 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.228] > Sep 10 19:11:03 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno > wn[182.38.149.228] > Sep 10 19:11:03 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.228] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:04 smtp postfix/smtpd[27607]: connect from unknown[182.38.234.76] > Sep 10 19:11:04 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.234.76] > Sep 10 19:11:04 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.234.76] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:05 smtp postfix/smtpd[27607]: connect from unknown[182.38.134.177] > Sep 10 19:11:05 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.134.177] > Sep 10 19:11:05 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.134.177] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:17 smtp postfix/smtpd[27607]: connect from unknown[182.38.139.99] > Sep 10 19:11:18 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.139.99] > Sep 10 19:11:18 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.139.99] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:18 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.156] > Sep 10 19:11:19 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.205.156] > Sep 10 19:11:19 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.156] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:22 smtp postfix/smtpd[27607]: connect from unknown[123.170.207.50] > Sep 10 19:11:23 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.207.50] > Sep 10 19:11:23 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.207.50] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:24 smtp postfix/smtpd[27607]: connect from unknown[123.170.206.248] > Sep 10 19:11:25 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.206.248] > Sep 10 19:11:25 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.206.248] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:25 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.80] > Sep 10 19:11:26 smtp postfix/smtpd[27607]: lost connection after EHLO from unknown[123.170.205.80] > Sep 10 19:11:26 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.80] ehlo=1 commands=1 > Sep 10 19:11:30 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.234] > Sep 10 19:11:30 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.149.234] > Sep 10 19:11:30 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.234] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:31 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.156] > Sep 10 19:11:32 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.205.156] > Sep 10 19:11:32 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.156] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:32 smtp postfix/smtpd[27607]: connect from unknown[123.170.195.250] > Sep 10 19:11:33 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.195.250] > Sep 10 19:11:33 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.195.250] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:34 smtp postfix/smtpd[27607]: connect from unknown[123.170.241.118] > Sep 10 19:11:35 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.241.118] > Sep 10 19:11:35 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.241.118] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:35 smtp postfix/smtpd[27607]: connect from unknown[182.38.135.69] > Sep 10 19:11:36 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.135.69] > Sep 10 19:11:36 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.135.69] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:36 smtp postfix/smtpd[27607]: connect from unknown[182.38.138.76] > Sep 10 19:11:36 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.138.76] > Sep 10 19:11:36 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.138.76] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:37 smtp postfix/smtpd[27607]: connect from unknown[123.170.202.168] > Sep 10 19:11:37 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.202.168] > Sep 10 19:11:37 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.202.168] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:37 smtp postfix/smtpd[27607]: connect from unknown[182.38.137.123] > Sep 10 19:11:38 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.137.123] > Sep 10 19:11:38 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.137.123] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:38 smtp postfix/smtpd[27607]: connect from unknown[182.38.232.194] > Sep 10 19:11:39 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.232.194] > Sep 10 19:11:39 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.232.194] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:39 smtp postfix/smtpd[27607]: connect from unknown[182.38.195.172] > Sep 10 19:11:39 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.195.172] > Sep 10 19:11:39 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.195.172] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:40 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.228] > Sep 10 19:11:41 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.149.228] > Sep 10 19:11:41 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.228] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:41 smtp postfix/smtpd[27607]: connect from unknown[182.38.131.199] > Sep 10 19:11:41 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.131.199] > Sep 10 19:11:41 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.131.199] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:42 smtp postfix/smtpd[27607]: connect from unknown[182.38.233.22] > Sep 10 19:11:42 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.233.22] |
|
From: Mark C. <pub...@ch...> - 2016-09-10 20:26:51
|
Just found this in my logs. Notice that the spammer alternates among several addresses within the same class B network (in this case, two different class Bs) in order to avoid detection. Any chance we could add a signature for this? > Sep 10 19:11:00 smtp postfix/smtpd[27607]: connect from unknown[182.38.196.133] > Sep 10 19:11:01 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno > wn[182.38.196.133] > Sep 10 19:11:01 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.196.13 > 3] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:01 smtp postfix/smtpd[27607]: connect from unknown[182.38.137.123] > Sep 10 19:11:01 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno > wn[182.38.137.123] > Sep 10 19:11:01 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.137.12 > 3] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:03 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.228] > Sep 10 19:11:03 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno > wn[182.38.149.228] > Sep 10 19:11:03 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.228] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:04 smtp postfix/smtpd[27607]: connect from unknown[182.38.234.76] > Sep 10 19:11:04 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.234.76] > Sep 10 19:11:04 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.234.76] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:05 smtp postfix/smtpd[27607]: connect from unknown[182.38.134.177] > Sep 10 19:11:05 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.134.177] > Sep 10 19:11:05 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.134.177] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:17 smtp postfix/smtpd[27607]: connect from unknown[182.38.139.99] > Sep 10 19:11:18 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.139.99] > Sep 10 19:11:18 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.139.99] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:18 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.156] > Sep 10 19:11:19 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.205.156] > Sep 10 19:11:19 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.156] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:22 smtp postfix/smtpd[27607]: connect from unknown[123.170.207.50] > Sep 10 19:11:23 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.207.50] > Sep 10 19:11:23 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.207.50] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:24 smtp postfix/smtpd[27607]: connect from unknown[123.170.206.248] > Sep 10 19:11:25 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.206.248] > Sep 10 19:11:25 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.206.248] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:25 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.80] > Sep 10 19:11:26 smtp postfix/smtpd[27607]: lost connection after EHLO from unknown[123.170.205.80] > Sep 10 19:11:26 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.80] ehlo=1 commands=1 > Sep 10 19:11:30 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.234] > Sep 10 19:11:30 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.149.234] > Sep 10 19:11:30 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.234] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:31 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.156] > Sep 10 19:11:32 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.205.156] > Sep 10 19:11:32 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.156] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:32 smtp postfix/smtpd[27607]: connect from unknown[123.170.195.250] > Sep 10 19:11:33 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.195.250] > Sep 10 19:11:33 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.195.250] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:34 smtp postfix/smtpd[27607]: connect from unknown[123.170.241.118] > Sep 10 19:11:35 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.241.118] > Sep 10 19:11:35 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.241.118] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:35 smtp postfix/smtpd[27607]: connect from unknown[182.38.135.69] > Sep 10 19:11:36 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.135.69] > Sep 10 19:11:36 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.135.69] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:36 smtp postfix/smtpd[27607]: connect from unknown[182.38.138.76] > Sep 10 19:11:36 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.138.76] > Sep 10 19:11:36 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.138.76] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:37 smtp postfix/smtpd[27607]: connect from unknown[123.170.202.168] > Sep 10 19:11:37 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.202.168] > Sep 10 19:11:37 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.202.168] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:37 smtp postfix/smtpd[27607]: connect from unknown[182.38.137.123] > Sep 10 19:11:38 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.137.123] > Sep 10 19:11:38 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.137.123] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:38 smtp postfix/smtpd[27607]: connect from unknown[182.38.232.194] > Sep 10 19:11:39 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.232.194] > Sep 10 19:11:39 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.232.194] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:39 smtp postfix/smtpd[27607]: connect from unknown[182.38.195.172] > Sep 10 19:11:39 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.195.172] > Sep 10 19:11:39 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.195.172] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:40 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.228] > Sep 10 19:11:41 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.149.228] > Sep 10 19:11:41 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.228] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:41 smtp postfix/smtpd[27607]: connect from unknown[182.38.131.199] > Sep 10 19:11:41 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.131.199] > Sep 10 19:11:41 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.131.199] ehlo=1 auth=0/1 commands=1/2 > Sep 10 19:11:42 smtp postfix/smtpd[27607]: connect from unknown[182.38.233.22] > Sep 10 19:11:42 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.233.22] |
|
From: Kevin Z. <kev...@gm...> - 2016-09-06 23:29:52
|
On 09/05/2016 05:16, Jos Chrispijn wrote:
> This is confusingas it reads that SSHGuard doesn't know whether it has
> been blocked or not ("should have been blocked" - human line
> interpretation).
>
> Better(and more demanding) would be:
> Sep 5 13:23:56 ares sshguard[771]: 116.209.118.176: has already been
> blocked (forever)
Fixed and committed in 7fcc98d. Thanks!
--
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090
|
|
From: Jos C. <ssh...@cl...> - 2016-09-05 12:16:26
|
Dear team,
Just to request a slightly different line on blocking earlier blocked IP
addresses:
Sep 5 13:23:56 ares kernel: Sep 5 13:23:56 ares sshguard[771]:
blacklist: added 116.209.118.176
Sep 5 13:23:56 ares sshguard[771]: 116.209.118.176: blocking forever (3
attacks in 7 secs, after 1 abuses over 7 secs)
Sep 5 13:23:56 ares kernel: Sep 5 13:23:56 ares sshguard[771]:
116.209.118.176: blocking forever (3 attacks in 7 secs, after 1 abuses
over 7 secs)
After blocking this ip you add this line:
Sep 5 13:23:56 ares sshguard[771]: 116.209.118.176: should already have
been blocked
Sep 5 13:23:56 ares kernel: Sep 5 13:23:56 ares sshguard[771]:
116.209.118.176: should already have been blocked
This is confusingas it reads that SSHGuard doesn't know whether it has
been blocked or not ("should have been blocked" - human line
interpretation).
Better(and more demanding) would be:
Sep 5 13:23:56 ares sshguard[771]: 116.209.118.176: has already been
blocked (forever)
Just thinking with your,
Jos Chrispijn
|
|
From: <li...@la...> - 2016-08-30 08:22:09
|
Subject line says it all. sshguard-ipfw-1.7.0_1 No problem compiling. |
|
From: Kevin Z. <kev...@gm...> - 2016-08-29 22:05:18
|
On 08/29/2016 13:07, mai...@ne... wrote: > maybe I did something stupid and I am not able to find the reason but after upgrading to SSHGuard 1.7.0 SSH is blocked after one wrong password input. > > > Aug 29 21:52:27 abv sshguard[80566]: 91.10.95.96: blocking for 1200 secs (1 attacks in 0 secs, after 1 abuses over 0 secs) > > sshguard_enable="YES" > sshguard_safety_threshold="8" sshguard_safety_threshold isn't read from the rc.d script. > sshguard_danger_thresh="10" This is your issue. The default is 30 (3 attempts). Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: <mai...@ne...> - 2016-08-29 20:08:00
|
Hello, maybe I did something stupid and I am not able to find the reason but after upgrading to SSHGuard 1.7.0 SSH is blocked after one wrong password input. Aug 29 21:52:27 abv sshguard[80566]: 91.10.95.96: blocking for 1200 secs (1 attacks in 0 secs, after 1 abuses over 0 secs) sshguard_enable="YES" sshguard_safety_threshold="8" sshguard_danger_thresh="10" sshguard_release_interval="600" sshguard_reset_interval="7200" sshguard_blacklist=30:/var/db/sshguard/blacklist.db sshguard_watch_logs="/var/log/auth.log:/usr/jails/aaa/var/log/auth.log:/usr/jails/bbb/var/log/auth.log“ Is there anything I configured wrong ? BR Marc |
|
From: Mark F. <fe...@Fr...> - 2016-08-29 18:04:26
|
> On Aug 29, 2016, at 13:02, Kevin Zheng <kev...@gm...> wrote: > > On 08/29/2016 10:47, Mark Felder wrote: >> Not sure. I was just looking for an easy hack for users of the hosts >> backend. > > If that's something people are interested in it would just involve > translating the original hosts.c into a new sshg-fw backend. > > It's only deprecated because not many people said they were using it on > the survey, and I wasn't going to rewrite if not many were using it. > > It would be trivial to implement if we assume the whole hosts.deny is > controlled by SSHGuard. The original implementation used comment blocks > to separate the SSHGuard-controlled parts from the rest. Do you know how > people are usually using the hosts backend? > Not sure. I've only seen one person that was using hosts file backend and noticed it is not available anymore. -- Mark Felder ports-secteam member fe...@Fr... |
|
From: Kevin Z. <kev...@gm...> - 2016-08-29 18:03:05
|
On 08/29/2016 10:47, Mark Felder wrote: > Not sure. I was just looking for an easy hack for users of the hosts > backend. If that's something people are interested in it would just involve translating the original hosts.c into a new sshg-fw backend. It's only deprecated because not many people said they were using it on the survey, and I wasn't going to rewrite if not many were using it. It would be trivial to implement if we assume the whole hosts.deny is controlled by SSHGuard. The original implementation used comment blocks to separate the SSHGuard-controlled parts from the rest. Do you know how people are usually using the hosts backend? -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Kevin Z. <kev...@gm...> - 2016-08-29 17:56:02
|
On 08/29/2016 10:49, Mark Felder wrote: > On Mon, Aug 8, 2016, at 12:23, Kevin Zheng wrote: >> >> Logsuck (-l option) is deprecated, use sshg-logtail instead > > The problem I have with this is that now I have to provide a new rc > script for users to have logtail, and users have to remember to start > it. Would it be reasonable to just accept the -l option but internally > fork off the sshg-logtail as a child process? Yes, that's what's planned for the next version. Tentatively, the '-l' flag will go away (replaced with positional arguments). Positional arguments will be passed to a forked off sshg-logtail, and the regular arguments will go to SSHGuard. You can stick to '-l' if you haven't been having problems with it. It's being taken out because it's had lots of bugs, from broken kqueue a while ago to using uninitialized memory to infinite looping on systems without a separate debug.log. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Mark F. <fe...@Fr...> - 2016-08-29 17:49:49
|
On Mon, Aug 8, 2016, at 12:23, Kevin Zheng wrote: > > Logsuck (-l option) is deprecated, use sshg-logtail instead The problem I have with this is that now I have to provide a new rc script for users to have logtail, and users have to remember to start it. Would it be reasonable to just accept the -l option but internally fork off the sshg-logtail as a child process? -- Mark Felder ports-secteam member fe...@Fr... |
|
From: Mark F. <fe...@Fr...> - 2016-08-29 17:47:31
|
On Mon, Aug 29, 2016, at 12:30, Kevin Zheng wrote: > On 08/29/2016 10:18, Mark Felder wrote: > >> Removed > >> Remove external hooks (-e option) > > > > How does the Null backend work now? > > The 'configure' script generates a sshg-fw that reads commands like > 'block 1.2.3.4' but just prints the action instead of doing anything. > > Instead of writing hooks, you can edit the sshg-fw script directly. In > future versions the user should be able to provide a path to sshg-fw; > right now the path is provided from the 'configure' script. > > The situation now is kind of ugly (compile in a new path or edit the > installed sshg-fw script). Suggestions? > Not sure. I was just looking for an easy hack for users of the hosts backend. -- Mark Felder ports-secteam member fe...@Fr... |
|
From: Kevin Z. <kev...@gm...> - 2016-08-29 17:30:41
|
On 08/29/2016 10:18, Mark Felder wrote: >> Removed >> Remove external hooks (-e option) > > How does the Null backend work now? The 'configure' script generates a sshg-fw that reads commands like 'block 1.2.3.4' but just prints the action instead of doing anything. Instead of writing hooks, you can edit the sshg-fw script directly. In future versions the user should be able to provide a path to sshg-fw; right now the path is provided from the 'configure' script. The situation now is kind of ugly (compile in a new path or edit the installed sshg-fw script). Suggestions? -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Mark F. <fe...@Fr...> - 2016-08-29 17:18:28
|
On Mon, Aug 8, 2016, at 12:23, Kevin Zheng wrote: > Greetings, > > SSHGuard 1.7.0 is available: > https://sourceforge.net/projects/sshguard/files/sshguard/1.7.0/ > > > Removed > Remove external hooks (-e option) How does the Null backend work now? -- Mark Felder ports-secteam member fe...@Fr... |
|
From: <li...@la...> - 2016-08-29 14:22:55
|
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><style> body { font-family: "Calibri","Slate Pro",sans-serif,"sans-serif"; color:#262626 }</style> </head> <body lang="en-US"><div>The latest rev it to ports. For some reason, "make" wouldn't make anything. I did a make clean, though in theory that shouldn't be necessary. </div><div><br></div><div>I've been running 1.7 for about a day and a half without incident. </div><div><br></div><div></div></body></html>
|
|
From: Kevin Z. <kev...@gm...> - 2016-08-23 05:29:49
|
On 08/22/16 08:14 PM, li...@la... wrote: > # pkg version -v | grep sshguard > sshguard-ipfw-1.6.4_1 = up-to-date with index > # uname -a > FreeBSD 10.2-RELEASE-p18 FreeBSD 10.2-RELEASE-p18 #0: Sat May 28 08:53:43 UTC 2016 Poke the maintainer. Offer beer and chocolates. Mark is CC'd. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: <li...@la...> - 2016-08-23 03:14:14
|
# pkg version -v | grep sshguard sshguard-ipfw-1.6.4_1 = up-to-date with index # uname -a FreeBSD 10.2-RELEASE-p18 FreeBSD 10.2-RELEASE-p18 #0: Sat May 28 08:53:43 UTC 2016 |
|
From: Kevin Z. <kev...@gm...> - 2016-08-17 18:54:43
|
Hi there, The latest code in 'master' has SSHGuard split into four parts: - sshg-logtail: monitor system logs - sshg-parser: logs -> attack data - sshg-blocker: attack data -> block/release actions - sshg-fw: do things with the firewall The 'sshguard' command has been replaced with a script that does some option handling but simply pipes these programs together: sshg-logtail $logs | sshg-parser | sshg-blocker $flags | sshg-fw (note that sshg-blocker currently directly popen()'s sshg-fw, so the last part isn't actually in the 'sshguard' script) Both sshg-parser and sshg-blocker are candidates for privsep. Capsicum sandboxing (for FreeBSD) is available. pledge() support on OpenBSD is welcome, as is sandboxing/privsep for other operating systems. Here's something that someone could do with this: provide an alternative implementation of sshg-parser that runs the parser part of fail2ban (fail2ban-regex?). That way we get their attack signatures in SSHGuard while hopefully adding privsep to avoid their bugs. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Kevin Z. <kev...@gm...> - 2016-08-12 23:11:27
|
On 08/12/2016 14:47, jungle Boogie wrote: > It means after I reboot, I need to login and run the same command above. > Would putting that in /etc/init.d as a script be good enough to have > it launch after reboots? I'm not the Linux expert here. If you installed via a distribution's package manager, there should be startup scripts for SSHGuard. If you use systemd, there's a sample unit file in examples/sshguard.service. Throwing it into init.d/ should also work, but check your distribution's documentation. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: jungle B. <jun...@gm...> - 2016-08-12 21:47:28
|
On 12 August 2016 at 14:11, Kevin Zheng <kev...@gm...> wrote: > What do you mean it doesn't work after rebooting? Is it that the logs > don't get monitored, attackers need to be re-blocked, or something else? Sorry for not being clear enough. It means after I reboot, I need to login and run the same command above. Would putting that in /etc/init.d as a script be good enough to have it launch after reboots? -- ------- inum: 883510009027723 sip: jun...@si... |
|
From: Kevin Z. <kev...@gm...> - 2016-08-12 21:11:41
|
On 08/12/2016 14:00, jungle Boogie wrote: > Where can I find information about sshg-logtail? > Do you have a working example of sshguard + iptables + persistent log > monitoring? Using '-l' should be fine. > Right now I'm doing: > /usr/local/sbin/sshguard -a 10 -l /var/log/auth.log -p 6000 & > > This works but won't work after rebooting. What do you mean it doesn't work after rebooting? Is it that the logs don't get monitored, attackers need to be re-blocked, or something else? Thanks, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
2 messages has been excluded from this view by a project administrator.
