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

Re: [SSHGuard-users] Failed to block

[Jos C. <ssh...@cl...>]

In een bericht van 1-8-2016 20:50:

> I'll hazard a guess that SSHGuard is being started before the firewall
> has been brought up.
>
> Can you try adding 'ipfw' to the REQUIRE line in
> /usr/local/etc/rc.d/sshguard and testing again?

I will and let you know, thanks.

BR, Jos

Re: [SSHGuard-users] Failed to block

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

On 08/01/2016 11:08, Jos Chrispijn wrote:
>> Ahh, so you're running 1.6.4 from ports? How are you starting SSHGuard?
>> Via the rc.d script or syslog?
> 
> sshguard_enable="YES"
> sshguard_blacklist="40:/var/db/sshguard/blacklist.db"
> sshguard_whitelistfile="/usr/local/etc/sshguard.whitelist"
> 
>> Does this message only appear when the machine is starting up?
> Yes that is correct. Only then (not on the system prompt after)
> 
> Does it show up when you restart SSHGuard without restarting the system?
> Nope

I'll hazard a guess that SSHGuard is being started before the firewall
has been brought up.

Can you try adding 'ipfw' to the REQUIRE line in
/usr/local/etc/rc.d/sshguard and testing again?

Best,
Kevin

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

Re: [SSHGuard-users] Failed to block

[Jos C. <ssh...@cl...>]

In een bericht van 1-8-2016 20:00:

> Ahh, so you're running 1.6.4 from ports? How are you starting SSHGuard?
> Via the rc.d script or syslog?

sshguard_enable="YES"
sshguard_blacklist="40:/var/db/sshguard/blacklist.db"
sshguard_whitelistfile="/usr/local/etc/sshguard.whitelist"

> Does this message only appear when the machine is starting up?
Yes that is correct. Only then (not on the system prompt after)

Does it show up when you restart SSHGuard without restarting the system?
Nope

Best regards,
Jos

Re: [SSHGuard-users] Failed to block

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

On 08/01/2016 10:56, Jos Chrispijn wrote:
> What is displayed in dmesg is the text that is display during a system 
> restart - no address blocking required as the server is in its startup 
> phase.

Ahh, so you're running 1.6.4 from ports? How are you starting SSHGuard?
Via the rc.d script or syslog? Does this message only appear when the
machine is starting up? Does it show up when you restart SSHGuard
without restarting the system?

Best,
Kevin

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

Re: [SSHGuard-users] Failed to block

[Jos C. <ssh...@cl...>]

Hello Kevin,

In een bericht van 1-8-2016 17:46:
> On 08/01/2016 02:42, Jos Chrispijn wrote:
>> After restarting my server for maintenance, I saw this in dmesg file:
>>
>> /Jul 31 18:08:39 ares sshguard[720]: fw: failed to block (-1)/
>>
>> Can you tell me what this means?
>
> SSHGuard failed to flush its pipe to sshg-fw when trying to block an
> address. Did you run `make install`?
>
> Some more information like 'configure' command line would be useful for
> figuring out what went wrong.

What is displayed in dmesg is the text that is display during a system 
restart - no address blocking required as the server is in its startup 
phase.

How do I use the configure sshguard? I did install it running make 
config first (resulting in "No options to configure") and then running 
make install clean.

I have sshguard-ipfw-1.6.4_1 up-and-running currently.

Best regards,
Jos

Re: [SSHGuard-users] Failed to block

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

On 08/01/2016 02:42, Jos Chrispijn wrote:
> After restarting my server for maintenance, I saw this in dmesg file:
> 
> /Jul 31 18:08:39 ares sshguard[720]: fw: failed to block (-1)/
> 
> Can you tell me what this means?

SSHGuard failed to flush its pipe to sshg-fw when trying to block an
address. Did you run `make install`?

Some more information like 'configure' command line would be useful for
figuring out what went wrong.

Thanks,
Kevin

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

[SSHGuard-users] Failed to block

[Jos C. <ssh...@cl...>]

After restarting my server for maintenance, I saw this in dmesg file:

/Jul 31 18:08:39 ares sshguard[720]: fw: failed to block (-1)/

Can you tell me what this means?

Thanks,
Jos

Re: [SSHGuard-users] Port updates

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

On 07/31/2016 12:09, li...@la... wrote:
> Other than doing portsnap fetch portsnap update I assume  we are at
> the mercy of the port maintainers.

The FreeBSD port is usually updated pretty quickly. The version in ports
is currently the latest version (1.6.4).

If you're looking for upgrade instructions, check the Handbook:

https://www.freebsd.org/doc/en/books/handbook/ports-using.html

> Sshguard does eventually get updated in ports. Even though I run
> sshguard as beta often, when the ports release the new code, I go
> back and bold it from ports just to verify the ports work.

It's tricky getting the release process right. Generally, you should
track 'master' if you want to run the latest code or if you're
interested in participating with the project (like discussing new
features on mailing lists, submitting attack signatures, or even just
testing the latest code).

Releases are intended for people who want to run SSHGuard but want
minimal involvement in the project. I tend to fall into this category
for most of the software I use.

So, if you want to contribute to SSHGuard, simply running 'master' and
being loud when something breaks is well appreciated!

Best,
Kevin

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

Re: [SSHGuard-users] Port updates

[<li...@la...>]

Other than doing
portsnap fetch
portsnap update
I assume  we are at the mercy of the port maintainers.  

Sshguard does eventually get updated in ports. Even though I run sshguard as beta often, when the ports release the new code, I go back and bold it from ports just to verify the ports work. 

As an aside, I run
pkg version -v | grep needs
after doing the portsnap update to highlight the programs that need updating. 

‎
  Original Message  
From: Jos Chrispijn
Sent: Sunday, July 31, 2016 12:00 PM
To: ssh...@li...
Subject: [SSHGuard-users] Port updates

[SSHGuard-users] Port updates

[Jos C. <ssh...@cl...>]

Dear team,
Just for my information- see that SSHGuard is updated on a regular 
scheme. Since I used this great program I though never ran into a port 
update of it.
Can you advise how/where to obtain the port update of SSHGuard?

Thanks,
Jos Chrispijn

Re: [SSHGuard-users] Adedd and 'should have been added'

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

Hi Jos,

On 07/31/2016 09:21, Jos Chrispijn wrote:
> As you see the ip address has been blocked @ (1), but in the same run I
> get twice another display line, saying the the ip should have been
> blocked (as it was in (1)).
> Can you explain how we should interprer the (2) lines or is it a display
> bug?

The attacker was blacklisted (and blocked) in (1), so the attacker was
disconnected by the firewall. Disconnects also cause sshd to log the
message you saw, which SSHGuard saw and warned that an attack was
recognized, even though it assumed the attacker was already blocked.

You can safely disregard this message. The purpose of this message was
to warn when the firewall failed to block, in which case lots of these
messages would appear.

Best,
Kevin

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

[SSHGuard-users] Adedd and 'should have been added'

[Jos C. <ssh...@cl...>]

Dearteam,

Just saw following in my all.log file:

-- cut --

Jul 31 18:12:56 ares sshguard[720]: blacklist: added 98.174.187.19
Jul 31 18:12:56 ares kernel: Jul 31 18:12:56 ares sshguard[720]: 
blacklist: added 98.174.187.19
(1) Jul 31 18:12:56 ares sshguard[720]: 98.174.187.19: blocking forever 
(3 attacks in 256 secs, after 1 abuses over 256 secs)
(1) Jul 31 18:12:56 ares kernel: Jul 31 18:12:56 ares sshguard[720]: 
98.174.187.19: blocking forever (3 attacks in 256 secs, after 1 abuses 
over 256 secs)
Jul 31 18:12:56 ares postfix/smtpd[2492]: lost connection after AUTH 
from wsip-98-174-187-19.ok.ok.cox.net[98.174.187.19]
Jul 31 18:12:56 ares postfix/smtpd[2492]: disconnect from 
wsip-98-174-187-19.ok.ok.cox.net[98.174.187.19] ehlo=1 auth=0/1 commands=1/2
(2) --> Jul 31 18:12:56 ares sshguard[720]: 98.174.187.19: should 
already have been blocked
(2) --> Jul 31 18:12:56 ares kernel: Jul 31 18:12:56 ares sshguard[720]: 
98.174.187.19: should already have been blocked

-- cut --

As you see the ip address has been blocked @ (1), but in the same run I 
get twice another display line, saying the the ip should have been 
blocked (as it was in (1)).
Can you explain how we should interprer the (2) lines or is it a display 
bug?

Keep up the good work,
Jos Chrispijn

Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

[Georg L. <jor...@ma...>]

On 28/07/16 19:08, Kevin Zheng wrote:
> On 07/28/2016 10:27, Georg Lehner wrote:
>> - The sshg-fw script stops with syntax error, a patch with some
>>   improvements (hopefully) is attached.
>
> Thanks for the patch. Just to make sure, what does 'iptables -w -v' do?
> I can't seem to tell from the man page [1] what the default action is.
>
> [1] http://linuxmanpages.net/manpages/fedora21/man8/iptables.8.html
>
Hello Kevin,

It should be `-V` (--version), instead of `-v`.

I'm sure you remember, that I have a system with an old `iptables` which 
does not understand the `-w` switch.

Since I have a system with a new `iptables`too, I was able to find a 
way, to detect non-intrusively if `-w` is supported.

`iptables -w -V` will exit with an error and a message on stderr if it 
is an old `iptables`.  If it is a new `iptables` it will show its 
version on stdout and exit with success.

I proposed: `if $cmd -w -v 2>/dev/null; then ...` in my patch, however 
it better be:

`if $cmd -w -V 2>&1 >/dev/null; then ...`

to suppress the version string too.

Best Regards,

   Georg Lehner

Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

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

On 07/28/2016 10:27, Georg Lehner wrote:
> - The sshg-fw script stops with syntax error, a patch with some
>   improvements (hopefully) is attached.

Thanks for the patch. Just to make sure, what does 'iptables -w -v' do?
I can't seem to tell from the man page [1] what the default action is.

[1] http://linuxmanpages.net/manpages/fedora21/man8/iptables.8.html

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

Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

[Jef P. <je...@ma...>]

>What's the purpose of the 'x' in lines like these?
>
>if [ "x$2" = "x6" ]; then
>
>Since the string literals are provided, there shouldn't be an error when
>the provided strings are empty. Isn't the 'x' there to guard against an
>empty string?

That's a common idiom in shell script programming. It's to
guard against the string being check having a flag argument
that the [ command, a.k.a. test, would interpret. This
is really due to test having poorly thought out argument
syntax but what are you gonna do.

Another common idiom is to merely reverse the order of
the strings being checked:

  if [ "6" = "$2" ]; then

Putting the variable second means test won't try to interpret
it as a flag.

Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

[Georg L. <jor...@ma...>]

On 28/07/16 16:19, Kevin Zheng wrote:
> On 07/28/2016 10:27, Georg Lehner wrote:
>> - The sshg-fw script stops with syntax error, a patch with some
>>   improvements (hopefully) is attached.
>
> What's the purpose of the 'x' in lines like these?
>
> if [ "x$2" = "x6" ]; then
>
> Since the string literals are provided, there shouldn't be an error when
> the provided strings are empty. Isn't the 'x' there to guard against an
> empty string?

Force of habit.  Consider somebody calling the function without the 
second parameter, you'd get a syntax error and the script dies or 
behaves erratically.

...
>> I noticed, that the sshg-fw script is wrapped together by './configure'
>> and not by 'make'.  To rebuild it, you need to 'make distclean' and than
>> './configure' again.  I propose either to build the script with make, or
>> document the procedure.
>
> I agree. I'll see what I can do. The main issue is that the Makefiles
> don't know what firewall backend you chose.
...

Well, my auto{conf,make}-fu is very weak, but I guess that there is a 
Makefile.in which can be mangled by ./configure in a way, that the 
--with-iptables parameter slips in at the right place in the respective 
Makefile.

Best Regards,

   Georg Lehner

Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

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

On 07/28/2016 15:24, Jef Poskanzer wrote:
>> What's the purpose of the 'x' in lines like these?
>>
>> if [ "x$2" = "x6" ]; then
>>
>> Since the string literals are provided, there shouldn't be an error when
>> the provided strings are empty. Isn't the 'x' there to guard against an
>> empty string?
> 
> That's a common idiom in shell script programming. It's to
> guard against the string being check having a flag argument
> that the [ command, a.k.a. test, would interpret. This
> is really due to test having poorly thought out argument
> syntax but what are you gonna do.

Ahh, I see. I'm glad someone is looking over my shell scripts.

> Another common idiom is to merely reverse the order of
> the strings being checked:
> 
>   if [ "6" = "$2" ]; then
> 
> Putting the variable second means test won't try to interpret
> it as a flag.

I think I like this better.

Thanks,
Kevin

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

Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

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

On 07/28/2016 10:27, Georg Lehner wrote:
> - The sshg-fw script stops with syntax error, a patch with some
>   improvements (hopefully) is attached.

What's the purpose of the 'x' in lines like these?

if [ "x$2" = "x6" ]; then

Since the string literals are provided, there shouldn't be an error when
the provided strings are empty. Isn't the 'x' there to guard against an
empty string?

> - Shortly after startup the following error message is shown,
>   processing continues
> 
>     sh: 1: exec: NONE/libexec/sshg-fw: not found

Working on this one.

> - After some processing sshguard stops because of a broken pipe.
>   See the attached sshguard.log for the error messages.
> 
> My guess: sshg-fw is not run (first error), and when the first attacker
> should be added the half-open pipe breaks.

Should be fixed in 'master' now.

> I noticed, that the sshg-fw script is wrapped together by './configure'
> and not by 'make'.  To rebuild it, you need to 'make distclean' and than
> './configure' again.  I propose either to build the script with make, or
> document the procedure.

I agree. I'll see what I can do. The main issue is that the Makefiles
don't know what firewall backend you chose.

Best,
Kevin

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

Re: [SSHGuard-users] rev 1.7.0 not blocking all worthy of blocking

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

On 07/28/2016 13:21, Georg Lehner wrote:
> If I had a wish, I would like to be able to specify the coefficient for 
> the (exponential?) back-off time.  Currently it seems to be set fixed to 
> 1.5 (man page, -p option).

I can do that.

> Another idea: sshg-parse could be used for creating time series of the 
> attacks, which can then be analyzed by statistical tools.  Eventually we 
> end up with an adaptive Kalman Filter or so ...

The intent of splitting up the parser into a separate binary was to make
it possible to plug it into other tools :)

I actually have some data I collected. It's a bit limited in usefulness
because SSHGuard blocks the attacker after 3 attempts. I've attached it
here in case anyone wants to play with the data.

Briefly, each line represents the attacks from an attacker. Each entry
is the time of an attack (Unix time). -1 represents a block by SSHGuard.
I've also included a script that breaks this data up into groups of 3
attacks that you can import into IPython.

Have fun,
Kevin

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

Re: [SSHGuard-users] rev 1.7.0 not blocking all worthy of blocking

[Georg L. <jor...@ma...>]

On 28/07/16 13:34, Kevin Zheng wrote:
> On 07/28/2016 00:20, li...@la... wrote:
>> Looking at the log, 162.144.102.19 is worthy of blocking, but it wasn't
>> blocked.
...
> Attackers are purged 30 minutes after their *first* attack, not their
> most recent attack. The first attack was at 04:48:34, and so by the time
> the third attack that would have triggered a block rolled around
> (05:31:03), the attacker's earlier attacks were already forgotten.
>
> This latter issue is something worth fixing. Suggestions? Perhaps it's
> better to change the policy to purge 30 minutes after the most *recent*
> attack.
>
> Best,
> Kevin
>
Hello,

Attacks as I observer them typically are spread over time.  I guess, 
that attackers already know, that they get more attention if they 
blindly hammer on the same host, so they distribute the attacks and 
better come back later to give it a try.

I have set the -s option to 70 minutes instead of 30 and consider 
setting -p to 5 minutes to take care of this.

Using the most recent attack time instead of the first, only shifts the 
time window, so in the next corner case the attacker gets forgotten.

If I had a wish, I would like to be able to specify the coefficient for 
the (exponential?) back-off time.  Currently it seems to be set fixed to 
1.5 (man page, -p option).

- - -

Another idea: sshg-parse could be used for creating time series of the 
attacks, which can then be analyzed by statistical tools.  Eventually we 
end up with an adaptive Kalman Filter or so ...

- - -

Best Regards,

   Georg Lehner

Re: [SSHGuard-users] rev 1.7.0 not blocking all worthy of blocking

[<li...@la...>]

I think you have a "number of attacks" per some time period criteria. I think a simple lockout after the most recent attack is fine. But you must of had a reason for the more complicated criteria. 

I suppose if some IP attacked every 30 minutes until the end of time, it would be wrong to allow that behavior. 

How about the release time is based from the last attack, but if there is a trigger prior to release, the timer gets increased by say 15 minutes. 

Well no, that won't work because the attacker would just wait 30 minutes between attacks and never increase the time period. 

How about a simple 30 minute lockout, no fancy time increase, but the program makes a log for suggested blacklisting based on persistent attacks.


  Original Message  
From: Kevin Zheng
Sent: Thursday, July 28, 2016 12:35 PM
To: ssh...@li...
Subject: Re: [SSHGuard-users] rev 1.7.0 not blocking all worthy of blocking

On 07/28/2016 00:20, li...@la... wrote:
> Looking at the log, 162.144.102.19 is worthy of blocking, but it wasn't
> blocked.

This is not technically a bug because the code is behaving as written. I
think the bug is in the policy itself. Here's what's going on:

The "POSSIBLE BREAK-IN ATTEMPT" is not considered an attack. This
message shows up when a reverse DNS lookup doesn't match, but the actual
attack is the "Connection closed" line. They're not two separate attacks.

Attackers are purged 30 minutes after their *first* attack, not their
most recent attack. The first attack was at 04:48:34, and so by the time
the third attack that would have triggered a block rolled around
(05:31:03), the attacker's earlier attacks were already forgotten.

This latter issue is something worth fixing. Suggestions? Perhaps it's
better to change the policy to purge 30 minutes after the most *recent*
attack.

Best,
Kevin

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

------------------------------------------------------------------------------
_______________________________________________
sshguard-users mailing list
ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [SSHGuard-users] rev 1.7.0 not blocking all worthy of blocking

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

On 07/28/2016 00:20, li...@la... wrote:
> Looking at the log, 162.144.102.19 is worthy of blocking, but it wasn't
> blocked.

This is not technically a bug because the code is behaving as written. I
think the bug is in the policy itself. Here's what's going on:

The "POSSIBLE BREAK-IN ATTEMPT" is not considered an attack. This
message shows up when a reverse DNS lookup doesn't match, but the actual
attack is the "Connection closed" line. They're not two separate attacks.

Attackers are purged 30 minutes after their *first* attack, not their
most recent attack. The first attack was at 04:48:34, and so by the time
the third attack that would have triggered a block rolled around
(05:31:03), the attacker's earlier attacks were already forgotten.

This latter issue is something worth fixing. Suggestions? Perhaps it's
better to change the policy to purge 30 minutes after the most *recent*
attack.

Best,
Kevin

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

Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

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

On 07/28/2016 11:41, li...@la... wrote:
> 
> http://www.sshguard.net/docs/setup/compile-install/
> 
> The prefix requirement is in the ‎instructions above. IIRC, Kevin
> added a lot of verbiage on the page for me because I kept screwing it
> up. ;-)

Although the documentation suggests that you should use '--prefix', I
consider the breakage without a '--prefix' a bug.

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

Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

[Georg L. <jor...@ma...>]

On 28/07/16 12:41, li...@la... wrote:
>
> http://www.sshguard.net/docs/setup/compile-install/
>
> The prefix requirement is in the ‎instructions above. IIRC, Kevin added a lot of verbiage on the page for me because I kept screwing it up. ;-)
>
...
You are right, I did not rtfm.

To my excuse: ./configure --help told me, that the default prefix was 
/usr/local.

Please Kevin, add --prefix=/your-location to the examples in the section 
on "COMPILING AND INSTALLING" lower down the page too.

Regards,

   Georg Lehner

Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

[<li...@la...>]

http://www.sshguard.net/docs/setup/compile-install/

The prefix requirement is in the ‎instructions above. IIRC, Kevin added a lot of verbiage on the page for me because I kept screwing it up. ;-)

  Original Message  
From: Georg Lehner
Sent: Thursday, July 28, 2016 11:28 AM
To: ssh...@li...
Subject: Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

On 28/07/16 11:27, Georg Lehner wrote:
...
>
> sh: 1: exec: NONE/libexec/sshg-fw: not found
>
> - After some processing sshguard stops because of a broken pipe.
> See the attached sshguard.log for the error messages.
>
> My guess: sshg-fw is not run (first error), and when the first attacker
> should be added the half-open pipe breaks.
>
...

In fact, the auto{make,configure} machinery does not supply a default 
prefix. After doing:

./configure --prefix=/usr/local --with-firewall=iptables

I got a working sshguard.

Running now in production, any findings will be reported.

Best Regards,

Georg Lehner



------------------------------------------------------------------------------
_______________________________________________
sshguard-users mailing list
ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users