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

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

[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

Re: [Sshguard-users] Blacklisting option causes 'exited with status 1'

[Jonathan G. <Jon...@ir...>]

Yes, using from ports.

Thank you.

-----Original Message-----
From: Kevin Zheng [mailto:kev...@gm...] 
Sent: Tuesday, December 09, 2014 4:51 PM
To: ssh...@li...
Subject: Re: [Sshguard-users] Blacklisting option causes 'exited with status 1'

Hi Jonathan,

On 12/09/2014 16:28, Jonathan Green wrote:
> We are running sshguard 1.5, with BSD 9.1, and pf .  When a violation 
> occurs, instead of blacklisting the IP, we get 'logging subprocess ... 
> exited with status 1'.

It sounds like you're using FreeBSD, is that correct? If so, are you using the sshguard from ports or compiling from source?

Thanks,
Kevin Zheng

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

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Blacklisting option causes 'exited with status 1'

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

Hi Jonathan,

On 12/09/2014 16:28, Jonathan Green wrote:
> We are running sshguard 1.5, with BSD 9.1, and pf .  When a violation
> occurs, instead of blacklisting the IP, we get ‘logging subprocess … 
> exited with status 1’.

It sounds like you're using FreeBSD, is that correct? If so, are you
using the sshguard from ports or compiling from source?

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] Blacklisting option causes 'exited with status 1'

[Jonathan G. <Jon...@ir...>]

Hello there:

We are running sshguard 1.5, with BSD 9.1, and pf .  When a violation occurs, instead of blacklisting the IP, we get 'logging subprocess ...  exited with status 1'.

In /etc/pf.conf:

table <sshguard> persist
block in quick on $ext_if proto tcp from <sshguard> to any port 22 label "ssh bruteforce"

In /etc/syslog.conf:

auth.info;authpriv.info     |exec /usr/local/sbin/sshguard  -b 5:/usr/local/etc/sshguard.db   -w /usr/local/etc/sshguard.whitelist


If we remove the -b option, sshguard works just fine.  However we would like to use the blacklisting feature.

Any help would be greatly appreciated.

Thank you.

Re: [Sshguard-users] Problem with blocking "strings" not being IPs

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

Hi Peter,

Sorry for the follow-up email.

SSHGuard uses regular expressions in its lexer to match attack
signatures and IP addresses. This means that if you feed it an invalid
IP address it shouldn't even try to block it.

Would it be possible for you to try using the "log sucker" option by
specifying a log file on the command line? I'm wondering if this is
something funny happening with syslog-ng.

Incorrect string handling sounds troubling; do you have snippets of logs
that we can take a look at and test?

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] Problem with blocking "strings" not being IPs

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

Hi Peter,

Sorry I haven't gotten back to you on an earlier email.

On 11/27/2014 16:54, Peter Viskup wrote:
> todays messages:
> Nov 27 23:31:25 server sshguard[25526]: Releasing  after 450 seconds.
> Nov 27 23:31:25 server sshguard[25526]: Setting environment:
> SSHG_ADDR=SSHG_ADDR=<E8>~a^GL^?;SSHG_ADDRKIND=4;SSHG_SERVICE=100.
> Nov 27 23:31:25 server sshguard[25526]: Run command "case $SSHG_ADDRKIND
> in 4) exec /sbin/iptables -D sshguard -s $SSHG_ADDR -j DROP ;; 6) exec
> /sbin/ip6tables -D sshguard -s $SSHG_ADDR -j DROP ;; *) exit -2 ;;
> esac": exited 2.
> Nov 27 23:31:25 server sshguard[25526]: Release command failed. Exited: -1

If random characters made it in, this failure isn't surprising since the
code uses the system(3) call.

> Other strange messages:
> Nov 27 23:34:16 server sshguard[25526]: Releasing  after 621 seconds.
> Nov 27 23:34:16 server sshguard[25526]: Setting environment:
> SSHG_ADDR=0;SSHG_ADDRKIND=0;SSHG_SERVICE=0.
> Nov 27 23:34:16 server sshguard[25526]: Run command "case $SSHG_ADDRKIND
> in 4) exec /sbin/iptables -D sshguard -s $SSHG_ADDR -j DROP ;; 6) exec
> /sbin/ip6tables -D sshguard -s $SSHG_ADDR -j DROP ;; *) exit -2 ;;
> esac": exited 2.
> Nov 27 23:34:16 server sshguard[25526]: Release command failed. Exited: -1

This seems like the same problem as above.

> Both examples are for rules removal. There are no messages for
> corresponding iptables inserts.

I'm baffled that there are no inserts, but removals. I'm not very
familiar with the iptables backend; if this happens frequently try
flushing the rules or the blacklist file (if any).

> I do see some strange users as inputs.
> "Failed password for invalid user rock123\r"

I'm not sure if these characters make it in or not; if they do, then
this is the culprit. This sounds dangerous, too.

> Could be that message strings are not handled appropriately and
> specially crafted user accounts lead to unexpected results. Could
> anybody have a look on that?

I'll be taking a look!

Thanks,
Kevin Zheng

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