sshguard-users — User questions and answers, bugs, and general support

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

[Vjaceslavs K. <vkl...@gm...>]

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] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

[Barry M. <bmu...@ga...>]

>
> found this (line 146) in "attack_scanner.l":


 /* wrong password for valid user @ FreeBSD, Debian */
"error: PAM: "[aA]"uthentication "(error|failure)" for "("illegal user
")?.+" from "            { return SSH_LOGINERR_PAM; }

which seems to be the appropriate pattern...
is there a quick way I can add to that pattern to keep it from spazzing out
when it gets the "via xx.xx.xx.xx"   ????

Re: [Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

[Willem J. W. <wj...@di...>]

On 2-2-2015 20:44, Bradley Giesbrecht wrote:
> On Feb 2, 2015, at 11:05 AM, Barry Muldrey <bmu...@ga...> wrote:
> 
>> sshd is producing the following in my system.log:
>>
>>     Feb  2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication error for root from 115.239.228.9 via 10.0.1.100
>>
>> sshguard is not recognizing the threat (debug output below).
>> If I submit the following, the attack is recognized:
>>
>>     Feb  2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication error for root from 115.239.228.9
>>
>> (please note "Error: popping nterm text ()" at the end of parser output...)
>>
>> Ideas, anyone??
> 
> I'm seeing the same thing. No answer but your not alone.
> 
> Regards,
> Bradley Giesbrecht (pixilla)

The parsing trace tells you that it accepts the ipnr as ipnr, but then
then next word is unexpected in the grammar.
So the via 10.0.1.100 is creating a "syntax error"

This is inherent to the way the syntax rules are build.
And the syntax rules are only modifiable at compile time.
And need to be written 101% matching, otherwise the line will be skipped.

I'm still not very shure if this is really a desired concept for logfile
parsing. E.g. openssh changes its log format, and "all of a sudden" log
output is no longer generating desired reactions.

It requires "flexible" ways of specifying scanner and parser input,
which is not really a trivial thing.

--WjW

Re: [Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

[Bradley G. <pi...@ma...>]

On Feb 2, 2015, at 11:05 AM, Barry Muldrey <bmu...@ga...> wrote:

> sshd is producing the following in my system.log:
> 
>     Feb  2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication error for root from 115.239.228.9 via 10.0.1.100
> 
> sshguard is not recognizing the threat (debug output below).
> If I submit the following, the attack is recognized:
> 
>     Feb  2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication error for root from 115.239.228.9
> 
> (please note "Error: popping nterm text ()" at the end of parser output...)
> 
> Ideas, anyone??

I'm seeing the same thing. No answer but your not alone.

Regards,
Bradley Giesbrecht (pixilla)

[Sshguard-users] OS X 10.10 (Yosemite) and "authentication error for <user> from <ip> via <ip>"

[Barry M. <bmu...@ga...>]

sshd is producing the following in my system.log:

    Feb  2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication
error for root from 115.239.228.9 via 10.0.1.100

sshguard is not recognizing the threat (debug output below).
If I submit the following, the attack is recognized:

    Feb  2 13:45:59 myhost.local sshd[8027]: error: PAM: authentication
error for root from 115.239.228.9

(please note "Error: popping nterm text ()" at the end of parser output...)

Ideas, anyone??


######################
# BEGIN DEBUG OUTPUT
######################

Feb  2 13:45:59 crackfox.local sshd[8027]: error: PAM: authentication error
for root from 115.239.228.9 via 10.0.1.100
Starting parse
Entering state 0
Reading a token: --accepting rule at line 110 ("Feb  2 13:45:59
crackfox.local sshd[8027]: ")
Next token is token SYSLOG_BANNER_PID ()
Shifting token SYSLOG_BANNER_PID ()
Entering state 1
Reading a token: --accepting rule at line 146 ("error: PAM: authentication
error for root from ")
Next token is token SSH_LOGINERR_PAM ()
Shifting token SSH_LOGINERR_PAM ()
Entering state 9
Reading a token: --accepting rule at line 201 ("115.239.228.9")
Next token is token IPv4 ()
Shifting token IPv4 ()
Entering state 50
Reducing stack by rule 23 (line 203):
   $1 = token IPv4 ()
-> $$ = nterm addr ()
Stack now 0 1 9
Entering state 56
Reducing stack by rule 34 (line 279):
   $1 = token SSH_LOGINERR_PAM ()
   $2 = nterm addr ()
-> $$ = nterm ssh_authfail ()
Stack now 0 1
Entering state 32
Reducing stack by rule 27 (line 264):
   $1 = nterm ssh_authfail ()
-> $$ = nterm sshmsg ()
Stack now 0 1
Entering state 30
Reducing stack by rule 11 (line 169):
   $1 = nterm sshmsg ()
-> $$ = nterm msg_single ()
Stack now 0 1
Entering state 28
Reducing stack by rule 9 (line 163):
   $1 = nterm msg_single ()
-> $$ = nterm logmsg ()
Stack now 0 1
Entering state 46
Reducing stack by rule 5 (line 138):
   $1 = token SYSLOG_BANNER_PID ()
   $2 = nterm logmsg ()
-> $$ = nterm syslogent ()
Stack now 0
Entering state 24
Reducing stack by rule 1 (line 122):
   $1 = nterm syslogent ()
-> $$ = nterm text ()
Stack now 0
Entering state 23
Reading a token: --accepting rule at line 221 (" ")
--accepting rule at line 220 ("via")
Next token is token WORD ()
Error: popping nterm text ()
Stack now 0
Cleanup: discarding lookahead token WORD ()
Stack now 0

[Sshguard-users] OSX - sshguard 1.5 not picking up all attack signatures

[Alan S. <st...@le...>]

Dear all,

I’m using the macports version (1.5.0) of sshguard under OSX 10.9.5 and it appears from the logs to successfully be picking up a number of attacks but not all. I have run the code in debug mode with the following outcomes

Using an example of an attack that does not trigger shhguard directly from the system.log file (I’ve replaced some text with x and the ip of the ‘via’ machine):

Jan 27 06:17:07 xxx.xxx.xxx.uk sshd[14815]: error: PAM: authentication error for root from 115.239.228.7 via 127.0.0.1

there’s a whole bunch of output and finally...

Stack now 0
Entering state 23
Reading a token: --accepting rule at line 223 (" ")
--accepting rule at line 222 ("via")
Next token is token WORD ()
Error: popping nterm text ()
Stack now 0
Cleanup: discarding lookahead token WORD ()
Stack now 0

if i use

error: PAM: authentication error for root from 115.239.228.7 via 127.0.0.1

I get a similar outcome to above (i.e. the final text is the same as above)

but if I try just the following text

error: PAM: authentication error for root from 115.239.228.7

I get (again after a bit of other output)

Now at end of input.
Stack now 0 23
Cleanup: popping nterm text ()
Matched address 115.239.228.7:4 attacking service 100, dangerousness 10.
Purging stale attackers.

If I then repeat the last version (i.e. error: PAM: authentication error for root from 115.239.228.7) a further three times

I get First abuse of '115.239.228.7', adding to offenders list.
Offender '115.239.228.7:4' scored 40 danger in 1 abuses.
Blocking 115.239.228.7:4 for >630secs: 40 danger in 4 attacks over 133 seconds (all: 40d in 1 abuses over 133s).
Setting environment: SSHG_ADDR=115.239.228.7;SSHG_ADDRKIND=4;SSHG_SERVICE=100.
No ALTQ support in kernel
ALTQ related functions disabled
1/1 addresses added.
Run command "/sbin/pfctl -Tadd -t sshguard $SSHG_ADDR": exited 0.

and one further time I get

Matched address 115.239.228.7:4 attacking service 100, dangerousness 10.
Purging stale attackers.
Asked to block '115.239.228.7', which was already blocked to my account.

Any thoughts on what I have setup incorrectly (if anything) or solutions?

regards

Alan

Re: [Sshguard-users] Thought I had this working (OS X)

[LuKreme <kr...@kr...>]

On Jan 23, 2015, at 1:37 PM, Bradley Giesbrecht <pi...@ma...> wrote:
> 
> What happens when you use SSHGUARD_DEBUG:
> http://www.sshguard.net/docs/faqs/#debugging

Sorry, I was being stupid. The router was redirecting the ssh connections to another computer and I’d not noticed.

-- 
Anybody who tells me what happens to me after I'm dead is either a liar
or a fool because they DON'T KNOW

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

[Vjaceslavs K. <vkl...@gm...>]

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

[Kevin Z. <kev...@gm...>]

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

[Mark F. <fe...@fe...>]

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

[Vjaceslavs K. <vkl...@gm...>]

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] Thought I had this working (OS X)

[Bradley G. <pi...@ma...>]

On Jan 22, 2015, at 6:09 PM, LuKreme <kr...@kr...> wrote:

> But maybe 10.10.2 etas broke something?
> 
> All I see /var/log/system for sshguard are lines like:
> 
> /var/log/system.log:Jan 22 00:02:03 Jaka.local sshguard[158]: Source '/var/log/system.log' reappeared. Reloading.
> /var/log/system.log.0.gz:Jan 21 15:08:08 Jaka.local sshguard[175]: Source '/var/log/system.log' reappeared. Reloading.
> /var/log/system.log.0.gz:Jan 21 15:16:44 Jaka.local sshguard[158]: Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan.
> /var/log/system.log.1.gz:Jan 21 00:00:15 Jaka-2.local sshguard[162]: Source '/var/log/system.log' reappeared. Reloading.
> 
> $ psa sshg
> root              158   0.0  0.0  2473568   1604   ??  S    Wed03PM   0:02.23 /opt/local/sbin/sshguard -l /var/log/system.log -w /opt/local/etc/sshguard/whitelist
> root              151   0.0  0.0  2463068   1008   ??  S    Wed03PM   0:00.00 /bin/sh /opt/local/libexec/sshguard/sshguard-options-wrapper
> root               60   0.0  0.0  2469232   1080   ??  Ss   Wed03PM   0:00.01 /opt/local/bin/daemondo --label=sshguard --start-cmd /opt/local/libexec/sshguard/sshguard-options-wrapper ; --pid=exec

What happens when you use SSHGUARD_DEBUG:
http://www.sshguard.net/docs/faqs/#debugging


Regards,
Bradley Giesbrecht (pixilla)

[Sshguard-users] Thought I had this working (OS X)

[LuKreme <kr...@kr...>]

But maybe 10.10.2 etas broke something?

All I see /var/log/system for sshguard are lines like:

/var/log/system.log:Jan 22 00:02:03 Jaka.local sshguard[158]: Source '/var/log/system.log' reappeared. Reloading.
/var/log/system.log.0.gz:Jan 21 15:08:08 Jaka.local sshguard[175]: Source '/var/log/system.log' reappeared. Reloading.
/var/log/system.log.0.gz:Jan 21 15:16:44 Jaka.local sshguard[158]: Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan.
/var/log/system.log.1.gz:Jan 21 00:00:15 Jaka-2.local sshguard[162]: Source '/var/log/system.log' reappeared. Reloading.

$ psa sshg
root              158   0.0  0.0  2473568   1604   ??  S    Wed03PM   0:02.23 /opt/local/sbin/sshguard -l /var/log/system.log -w /opt/local/etc/sshguard/whitelist
root              151   0.0  0.0  2463068   1008   ??  S    Wed03PM   0:00.00 /bin/sh /opt/local/libexec/sshguard/sshguard-options-wrapper
root               60   0.0  0.0  2469232   1080   ??  Ss   Wed03PM   0:00.01 /opt/local/bin/daemondo --label=sshguard --start-cmd /opt/local/libexec/sshguard/sshguard-options-wrapper ; --pid=exec



-- 
"I can't see the point in the theatre. All that sex and violence. I get
enough of that at home. Apart from the sex, of course." -  Baldrick

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

[Willem J. W. <wj...@di...>]

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

[Kevin Z. <kev...@gm...>]

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

[Willem J. W. <wj...@di...>]

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

[Kevin Z. <kev...@gm...>]

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

[Vjaceslavs K. <vkl...@gm...>]

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?
>

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

[Vjaceslavs K. <vkl...@gm...>]

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

[Kevin Z. <kev...@gm...>]

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

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

[Vjaceslavs K. <vkl...@gm...>]

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] New install

[Kevin Z. <kev...@gm...>]

On 12/15/2014 00:39, LuKreme wrote:
>> Using the default settings, it takes 4 failed attempts. Each
>> failed attempt adds 10 "points", and after 40 "points" the
>> offending IP is blocked. You can configure this threshold.
> 
> Thanks. I haven't found instructions on how to configure that stuff
> yet (there's nothing in the default pf.log for example), but at least
> I know the defaults are sensible.

You can configure SSHGuard by passing it options from the command line;
type `sshguard -h` for a list of options.

Depending on your operating system and how you run SSHGuard, you will
need to pass these command line options differently.

Blocked addresses are released after a certain amount of time, unless
you have blacklisting enabled.

Best,
Kevin Zheng

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

Re: [Sshguard-users] New install

[LuKreme <kr...@kr...>]

> On Dec 14, 2014, at 20:55, Kevin Zheng <kev...@gm...> wrote:
> 
> Using the default settings, it takes 4 failed attempts. Each failed
> attempt adds 10 "points", and after 40 "points" the offending IP is
> blocked. You can configure this threshold.

Thanks. I haven't found instructions on how to configure that stuff yet (there's nothing in the default pf.log for example), but at least I know the defaults are sensible.

-- 

Re: [Sshguard-users] New install

[Kevin Z. <kev...@gm...>]

On 12/14/2014 21:50, LuKreme wrote:
> When does it block an IP? How many failed attempts does it take, and
> is that configurable,. Do IPs ever expire from the block list?

Using the default settings, it takes 4 failed attempts. Each failed
attempt adds 10 "points", and after 40 "points" the offending IP is
blocked. You can configure this threshold.

> Do I need to be concerned about the following?
> 
> No ALTQ support in kernel ALTQ related functions disabled

No, this is a message indicating that ATLQ was not compiled into your
firewall. ALTQ is pf's traffic shaping module.

Best,
Kevin Zheng

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

[Sshguard-users] New install

[LuKreme <kr...@kr...>]

I have sshguard installed and running, but I still have a few questions.

When does it block an IP? How many failed attempts does it take, and is that configurable,. Do IPs ever expire from the block list?

Do I need to be concerned about the following?

No ALTQ support in kernel
ALTQ related functions disabled


(OS X 10.10, macports install of sshguard 1.5)

-- 
The real world was far too real to leave neat little hints. It was full
of too many things. It wasn't by eliminating the impossible that you got
at the truth, however improbable; it was by the much harder process of
eliminating the possibilities. --Feet of Clay