Thread: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

Intelligently block brute-force attacks by aggregating system logs

Brought to you by: mijio, partmedia

sshguard-users

[Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Vjaceslavs K. <vkl...@gm...> - 2015-01-06 01:59:21

Hi,
I've recently switched some Internet facing machines from
"publickey,keyboard-interactive" to "publickey" only authentication.
On OpenSSH_6.7p1, that is achieved by setting

PasswordAuthentication no

in the sshd config. Server has HPN patches, so full version string
is OpenSSH_6.7p1-hpn14v5. I've noticed that sshguard no longer blocks
bruteforce attempts (like it used to when keyboard-interactive was
enabled). This is what appears in the logs:

Jan  5 10:32:51 pulley sshd[24107]: SSH: Server;Ltype: Version;Remote:
103.41.124.32-48688;Protocol: 2.0;Client: PUTTY
Jan  5 10:32:51 pulley sshd[24107]: SSH: Server;Ltype: Kex;Remote:
103.41.124.32-48688;Enc: aes128-ctr;MAC: hmac-sha1;Comp: none [preauth]
Jan  5 10:32:51 pulley sshd[24105]: SSH: Server;Ltype: Authname;Remote:
103.41.124.29-53907;Name: root [preauth]
Jan  5 10:32:51 pulley sshd[24105]: Received disconnect from 103.41.124.29:
11:  [preauth]

Any ideas on how to achieve blocking in this case?

[Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Vjaceslavs K. <vkl...@gm...> - 2015-01-19 19:43:41

Hi,
I've recently switched some Internet facing machines from
"publickey,keyboard-interactive" to "publickey" only authentication.
On OpenSSH_6.7p1, that is achieved by setting

PasswordAuthentication no

in the sshd config. Server has HPN patches, so full version string
is OpenSSH_6.7p1-hpn14v5. I've noticed that sshguard no longer blocks
bruteforce attempts (like it used to when keyboard-interactive was
enabled). This is what appears in the logs:

Jan  5 10:32:51 pulley sshd[24107]: SSH: Server;Ltype: Version;Remote:
103.41.124.32-48688;Protocol: 2.0;Client: PUTTY
Jan  5 10:32:51 pulley sshd[24107]: SSH: Server;Ltype: Kex;Remote:
103.41.124.32-48688;Enc: aes128-ctr;MAC: hmac-sha1;Comp: none [preauth]
Jan  5 10:32:51 pulley sshd[24105]: SSH: Server;Ltype: Authname;Remote:
103.41.124.29-53907;Name: root [preauth]
Jan  5 10:32:51 pulley sshd[24105]: Received disconnect from 103.41.124.29:
11:  [preauth]

Any ideas on how to achieve blocking in this case?

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Vjaceslavs K. <vkl...@gm...> - 2015-01-19 20:44:32

Oops, my apologies.

What I really meant to say is based on your advice I compiled dev version
and it blocks based on that pattern like a charm.

FYI, I looked at how Gentoo compiles the binary to make sure I am not
missing anything important and discovered that patch

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/sshguard/files/sshguard-1.5-day-starts-with-0.patch?view=markup

is being applied to fix

https://bugs.gentoo.org/show_bug.cgi?id=518988

Thank you.


On Mon, Jan 19, 2015 at 11:43 AM, Vjaceslavs Klimovs <vkl...@gm...>
wrote:

> Hi,
> I've recently switched some Internet facing machines from
> "publickey,keyboard-interactive" to "publickey" only authentication.
> On OpenSSH_6.7p1, that is achieved by setting
>
> PasswordAuthentication no
>
> in the sshd config. Server has HPN patches, so full version string
> is OpenSSH_6.7p1-hpn14v5. I've noticed that sshguard no longer blocks
> bruteforce attempts (like it used to when keyboard-interactive was
> enabled). This is what appears in the logs:
>
> Jan  5 10:32:51 pulley sshd[24107]: SSH: Server;Ltype: Version;Remote:
> 103.41.124.32-48688;Protocol: 2.0;Client: PUTTY
> Jan  5 10:32:51 pulley sshd[24107]: SSH: Server;Ltype: Kex;Remote:
> 103.41.124.32-48688;Enc: aes128-ctr;MAC: hmac-sha1;Comp: none [preauth]
> Jan  5 10:32:51 pulley sshd[24105]: SSH: Server;Ltype: Authname;Remote:
> 103.41.124.29-53907;Name: root [preauth]
> Jan  5 10:32:51 pulley sshd[24105]: Received disconnect from 103.41.124.29:
> 11:  [preauth]
>
> Any ideas on how to achieve blocking in this case?
>

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Kevin Z. <kev...@gm...> - 2015-01-19 21:08:41

Hi Vjaceslavs,

On 01/19/2015 14:44, Vjaceslavs Klimovs wrote:
> What I really meant to say is based on your advice I compiled dev
> version and it blocks based on that pattern like a charm.

I'm glad it works, thanks for testing it and reporting back!

> FYI, I looked at how Gentoo compiles the binary to make sure I am not
> missing anything important and discovered that patch
> 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/sshguard/files/sshguard-1.5-day-starts-with-0.patch?view=markup
> 
> is being applied to fix 
> 
> https://bugs.gentoo.org/show_bug.cgi?id=518988

Thanks for bringing this to my attention. Unfortunately right now
bugs/reports that are submitted wind up in what essentially amounts to a
black hole -- a non-public bug database that nobody can see.

I've applied the patch in the development repository.

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Willem J. W. <wj...@di...> - 2015-01-20 09:21:45

On 2015-01-19 22:08, Kevin Zheng wrote:
> Hi Vjaceslavs,
>
> On 01/19/2015 14:44, Vjaceslavs Klimovs wrote:
>> What I really meant to say is based on your advice I compiled dev
>> version and it blocks based on that pattern like a charm.
>
> I'm glad it works, thanks for testing it and reporting back!
>
>> FYI, I looked at how Gentoo compiles the binary to make sure I am not
>> missing anything important and discovered that patch
>>
>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/sshguard/files/sshguard-1.5-day-starts-with-0.patch?view=markup
>>
>> is being applied to fix
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=518988
>
> Thanks for bringing this to my attention. Unfortunately right now
> bugs/reports that are submitted wind up in what essentially amounts to a
> black hole -- a non-public bug database that nobody can see.
>
> I've applied the patch in the development repository.

Which explains that all the things I've suggested thru the website 
actually go into nowhere...

I'll see if I can get some of those suggestions back to you (or the 
list) Especially syslogd on FreeBSD can have extra fields, which make 
sshguard ingore everything.

--WjW

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Kevin Z. <kev...@gm...> - 2015-01-21 00:21:40

On 01/20/2015 03:06, Willem Jan Withagen wrote:
>> Thanks for bringing this to my attention. Unfortunately right now
>> bugs/reports that are submitted wind up in what essentially amounts to a
>> black hole -- a non-public bug database that nobody can see.
>>
>> I've applied the patch in the development repository.
> 
> Which explains that all the things I've suggested thru the website 
> actually go into nowhere...

Actually, they do go into a database which the admins can see, but that
means it takes a while for developers to act on them. It might be
worthwhile to look at making the database public.

> I'll see if I can get some of those suggestions back to you (or the 
> list) Especially syslogd on FreeBSD can have extra fields, which make 
> sshguard ingore everything.

For the time being the best place for patches is the mailing list.

I'm running FreeBSD, too. Quite frankly, I haven't been paying attention
to what SSHGuard has been picking up or not, but I'd be more than happy
to look at/test patches.

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Willem J. W. <wj...@di...> - 2015-01-21 10:35:34

On 2015-01-21 1:21, Kevin Zheng wrote:
> On 01/20/2015 03:06, Willem Jan Withagen wrote:
>>> Thanks for bringing this to my attention. Unfortunately right now
>>> bugs/reports that are submitted wind up in what essentially amounts to a
>>> black hole -- a non-public bug database that nobody can see.
>>>
>>> I've applied the patch in the development repository.
>>
>> Which explains that all the things I've suggested thru the website
>> actually go into nowhere...
>
> Actually, they do go into a database which the admins can see, but that
> means it takes a while for developers to act on them. It might be
> worthwhile to look at making the database public.
>
>> I'll see if I can get some of those suggestions back to you (or the
>> list) Especially syslogd on FreeBSD can have extra fields, which make
>> sshguard ingore everything.
>
> For the time being the best place for patches is the mailing list.
>
> I'm running FreeBSD, too. Quite frankly, I haven't been paying attention
> to what SSHGuard has been picking up or not, but I'd be more than happy
> to look at/test patches.

Right,

I'm using FreeBSD ipfw but in a different way other than sshguard-ipfw, 
which was easy to do with the dev version. I build sshguard with none 
backend, and now use a script which I hacked:
	/usr/local/sbin/sshguard-ipfwtable
to do the ipfw work.

That script uses a table to insert and delete blocked ipnrs.
The advantage of that is that one can insert the
	ipfw add deny any from table(xx) to any
anywhere in the firewall code. So it is no longer fixed at 5000, or 
something like that.

The 2nd advantage of that is that the list survives a
	'service ipfw restart'

--WjW

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Vjaceslavs K. <vkl...@gm...> - 2015-01-26 09:03:40

Hi Kevin,
I have discovered additional problem. It seems whatever pattern is suppose
to catch that case only matches when the bot presents some username, like
this one:

Jan 26 00:50:14 pulley sshd[5378]: SSH: Server;Ltype: Version;Remote:
72.14.226.9-57385;Protocol: 2.0;Client: OpenSSH_6.6.1
Jan 26 00:50:15 pulley sshd[5378]: SSH: Server;Ltype: Kex;Remote:
72.14.226.9-57385;Enc: aes128-ctr;MAC: hma...@op...;Comp: none
[preauth]
Jan 26 00:50:15 pulley sshd[5378]: SSH: Server;Ltype: Authname;Remote:
72.14.226.9-57385;Name: vklimovs [preauth]
Jan 26 00:50:15 pulley sshd[5378]: Invalid user vklimovs from 72.14.226.9
Jan 26 00:50:15 pulley sshd[5378]: input_userauth_request: invalid user
vklimovs [preauth]
Jan 26 00:50:15 pulley sshd[5378]: Connection closed by 72.14.226.9
[preauth]

That get's detected successfully. However actual bots do not present any
username at all, they drop at preauth phase, presumably upon learning that
keyboard-interactive is not supported:

Jan 26 00:58:27 pulley sshd[7061]: SSH: Server;Ltype: Version;Remote:
103.41.124.17-57034;Protocol: 2.0;Client: PUTTY
Jan 26 00:58:27 pulley sshd[7061]: SSH: Server;Ltype: Kex;Remote:
103.41.124.17-57034;Enc: aes128-ctr;MAC: hmac-sha1;Comp: none [preauth]
Jan 26 00:58:28 pulley sshd[7061]: SSH: Server;Ltype: Authname;Remote:
103.41.124.17-57034;Name: root [preauth]
Jan 26 00:58:28 pulley sshd[7061]: Received disconnect from 103.41.124.17:
11:  [preauth]

That's all they leave in the logs (no "invalid user" and
"input_userauth_request:" lines), and that does not get detected.

Presumably, the second case should be detected too?

On Mon, Jan 19, 2015 at 1:08 PM, Kevin Zheng <kev...@gm...> wrote:

> Hi Vjaceslavs,
>
> On 01/19/2015 14:44, Vjaceslavs Klimovs wrote:
> > What I really meant to say is based on your advice I compiled dev
> > version and it blocks based on that pattern like a charm.
>
> I'm glad it works, thanks for testing it and reporting back!
>
> > FYI, I looked at how Gentoo compiles the binary to make sure I am not
> > missing anything important and discovered that patch
> >
> >
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/sshguard/files/sshguard-1.5-day-starts-with-0.patch?view=markup
> >
> > is being applied to fix
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=518988
>
> Thanks for bringing this to my attention. Unfortunately right now
> bugs/reports that are submitted wind up in what essentially amounts to a
> black hole -- a non-public bug database that nobody can see.
>
> I've applied the patch in the development repository.
>
> Thanks,
> Kevin Zheng
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Kevin Z. <kev...@gm...> - 2015-01-26 19:48:41

Hi Vjaceslavs,

On 01/26/15 03:03, Vjaceslavs Klimovs wrote:
> Jan 26 00:58:28 pulley sshd[7061]: Received disconnect from
> 103.41.124.17 <http://103.41.124.17>: 11:  [preauth]
> 
> That's all they leave in the logs (no "invalid user" and
> "input_userauth_request:" lines), and that does not get detected.
> 
> Presumably, the second case should be detected too?

The "Received disconnect" and "[preauth]" message should be detected as
an attack. SSHGuard does not use simple regex matching, but instead a
parser, so I'll have to check how I implemented this one.

I suspect that it's the "11:" throwing it off, but I'll have to check. I
will get back to you on this soon.

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Vjaceslavs K. <vkl...@gm...> - 2015-01-26 20:41:50

I am happy to test code from SVN or provide more raw logs if needed.

On Mon, Jan 26, 2015 at 11:47 AM, Kevin Zheng <kev...@gm...> wrote:

> Hi Vjaceslavs,
>
> On 01/26/15 03:03, Vjaceslavs Klimovs wrote:
> > Jan 26 00:58:28 pulley sshd[7061]: Received disconnect from
> > 103.41.124.17 <http://103.41.124.17>: 11:  [preauth]
> >
> > That's all they leave in the logs (no "invalid user" and
> > "input_userauth_request:" lines), and that does not get detected.
> >
> > Presumably, the second case should be detected too?
>
> The "Received disconnect" and "[preauth]" message should be detected as
> an attack. SSHGuard does not use simple regex matching, but instead a
> parser, so I'll have to check how I implemented this one.
>
> I suspect that it's the "11:" throwing it off, but I'll have to check. I
> will get back to you on this soon.
>
> Thanks,
> Kevin Zheng
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Vjaceslavs K. <vkl...@gm...> - 2015-02-02 23:02:21

Hi Kevin,
Just a quick ping on this one, did you have a chance to look at this?

On Mon, Jan 26, 2015 at 12:41 PM, Vjaceslavs Klimovs <vkl...@gm...>
wrote:

> I am happy to test code from SVN or provide more raw logs if needed.
>
>
> On Mon, Jan 26, 2015 at 11:47 AM, Kevin Zheng <kev...@gm...>
> wrote:
>
>> Hi Vjaceslavs,
>>
>> On 01/26/15 03:03, Vjaceslavs Klimovs wrote:
>> > Jan 26 00:58:28 pulley sshd[7061]: Received disconnect from
>> > 103.41.124.17 <http://103.41.124.17>: 11:  [preauth]
>> >
>> > That's all they leave in the logs (no "invalid user" and
>> > "input_userauth_request:" lines), and that does not get detected.
>> >
>> > Presumably, the second case should be detected too?
>>
>> The "Received disconnect" and "[preauth]" message should be detected as
>> an attack. SSHGuard does not use simple regex matching, but instead a
>> parser, so I'll have to check how I implemented this one.
>>
>> I suspect that it's the "11:" throwing it off, but I'll have to check. I
>> will get back to you on this soon.
>>
>> Thanks,
>> Kevin Zheng
>>
>> --
>> Kevin Zheng
>> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>
>
>

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Mark F. <fe...@fe...> - 2015-01-26 17:04:45


On Mon, Jan 26, 2015, at 03:03, Vjaceslavs Klimovs wrote:
> Hi Kevin,
> I have discovered additional problem. It seems whatever pattern is
> suppose
> to catch that case only matches when the bot presents some username, like
> this one:
> 
> Jan 26 00:50:14 pulley sshd[5378]: SSH: Server;Ltype: Version;Remote:
> 72.14.226.9-57385;Protocol: 2.0;Client: OpenSSH_6.6.1
> Jan 26 00:50:15 pulley sshd[5378]: SSH: Server;Ltype: Kex;Remote:
> 72.14.226.9-57385;Enc: aes128-ctr;MAC: hma...@op...;Comp:
> none
> [preauth]
> Jan 26 00:50:15 pulley sshd[5378]: SSH: Server;Ltype: Authname;Remote:
> 72.14.226.9-57385;Name: vklimovs [preauth]
> Jan 26 00:50:15 pulley sshd[5378]: Invalid user vklimovs from 72.14.226.9
> Jan 26 00:50:15 pulley sshd[5378]: input_userauth_request: invalid user
> vklimovs [preauth]
> Jan 26 00:50:15 pulley sshd[5378]: Connection closed by 72.14.226.9
> [preauth]
> 
> That get's detected successfully. However actual bots do not present any
> username at all, they drop at preauth phase, presumably upon learning
> that
> keyboard-interactive is not supported:
> 
> Jan 26 00:58:27 pulley sshd[7061]: SSH: Server;Ltype: Version;Remote:
> 103.41.124.17-57034;Protocol: 2.0;Client: PUTTY
> Jan 26 00:58:27 pulley sshd[7061]: SSH: Server;Ltype: Kex;Remote:
> 103.41.124.17-57034;Enc: aes128-ctr;MAC: hmac-sha1;Comp: none [preauth]
> Jan 26 00:58:28 pulley sshd[7061]: SSH: Server;Ltype: Authname;Remote:
> 103.41.124.17-57034;Name: root [preauth]
> Jan 26 00:58:28 pulley sshd[7061]: Received disconnect from
> 103.41.124.17:
> 11:  [preauth]
> 
> That's all they leave in the logs (no "invalid user" and
> "input_userauth_request:" lines), and that does not get detected.
> 
> Presumably, the second case should be detected too?
> 

I could see that blocking monitoring tools which are checking for the
SSH banner. However, you should probably have those addresses
whitelisted if possible...

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Kevin Z. <kev...@gm...> - 2015-02-03 01:27:31

Hi Vjaceslavs,

On 02/02/2015 17:02, Vjaceslavs Klimovs wrote:
> Just a quick ping on this one, did you have a chance to look at this?

Thanks for the ping, otherwise, I may have forgotten about it!

SSHGuard (in the current development version) correctly detects the
following message as an attack:

Received disconnect from 103.41.124.17: 11:  [preauth]

Is this the line you intended?

Just as a sanity check, the development version is here:
https://bitbucket.org/sshguard/sshguard

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Vjaceslavs K. <vkl...@gm...> - 2015-02-03 20:48:19

I suppose this very the root of the problem was, I was pulling the source
from
https://sshguard.svn.sourceforge.net/svnroot/sshguard/trunk/

Code from https://bitbucket.org/sshguard/sshguard definitely blocks on
Received disconnect from 103.41.124.17: 11:  [preauth]

Thank you.

On Mon, Feb 2, 2015 at 5:27 PM, Kevin Zheng <kev...@gm...> wrote:

> Hi Vjaceslavs,
>
> On 02/02/2015 17:02, Vjaceslavs Klimovs wrote:
> > Just a quick ping on this one, did you have a chance to look at this?
>
> Thanks for the ping, otherwise, I may have forgotten about it!
>
> SSHGuard (in the current development version) correctly detects the
> following message as an attack:
>
> Received disconnect from 103.41.124.17: 11:  [preauth]
>
> Is this the line you intended?
>
> Just as a sanity check, the development version is here:
> https://bitbucket.org/sshguard/sshguard
>
> Thanks,
> Kevin Zheng
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] using sshguard to block attempts at hpn enabled publickey only server

From: Kevin Z. <kev...@gm...> - 2015-01-06 03:03:29

Attachments: patch-preauth-disconnect.diff

Hi Vjaceslavs,

On 01/05/15 19:59, Vjaceslavs Klimovs wrote:
> in the sshd config. Server has HPN patches, so full version string
> is OpenSSH_6.7p1-hpn14v5. I've noticed that sshguard no longer blocks
> bruteforce attempts (like it used to when keyboard-interactive was
> enabled). This is what appears in the logs:
> 
> Jan  5 10:32:51 pulley sshd[24107]: SSH: Server;Ltype: Version;Remote:
> 103.41.124.32-48688;Protocol: 2.0;Client: PUTTY
> Jan  5 10:32:51 pulley sshd[24107]: SSH: Server;Ltype: Kex;Remote:
> 103.41.124.32-48688;Enc: aes128-ctr;MAC: hmac-sha1;Comp: none [preauth]
> Jan  5 10:32:51 pulley sshd[24105]: SSH: Server;Ltype: Authname;Remote:
> 103.41.124.29-53907;Name: root [preauth]
> Jan  5 10:32:51 pulley sshd[24105]: Received disconnect from
> 103.41.124.29 <http://103.41.124.29>: 11:  [preauth]
> 
> Any ideas on how to achieve blocking in this case?

Attack patterns are compiled into SSHGuard, which means that adding new
signatures requires some lex/yacc changes and a recompile.

This particular signature has been added in the development version.
I've attached a patch against the latest source tarball that should
detect this. If you are able to apply this patch and recompile, let me
know how it works.

Best,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090