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

[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

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

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

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

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

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

On 26/07/16 17:22, Kevin Zheng wrote:
> On 07/26/2016 15:57, Georg Lehner wrote:
>> I tried to step forward with iptables testing, but am unable to compile
>> sshguard.  After following
>> http://www.sshguard.net/docs/setup/compile-install/ I get the below errors.
>>
>> Note: this has not been an issue about two weeks before.
>
> Thanks for the report. I've pushed some changes to 'master' that should
> fix this issue. I have another report [1] that sshg-fw fails at run-time
> with the iptables backend. Let me know if you hit this issue, and if you
> know how to fix it.
>
> Thanks,
> Kevin
>
> [1] https://bitbucket.org/sshguard/sshguard/issues/39/
>

Hi!

Finally I have come around to pull the changes.  sshguard compiles w/o 
errors now.  First tests:

GNU/Linux, Debian 7.11, Bison, GCC

After make install I run:

/usr/local/libexec/sshg-logtail /var/log/socklog/main/current \
   |sudo env SSHGUARD_DEBUG=1 /usr/local/sbin/sshguard  2>&1 \
   |tee /tmp/sshguard.log


- The sshg-fw script stops with syntax error, a patch with some
   improvements (hopefully) is attached.
- Shortly after startup the following error message is shown,
   processing continues

     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.

I recommend to add a 'ping' or 'version' command to the sshg-fw 
interface, so that sshguard can check for sanity on startup.

- - -

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.

- - -

Best Regards,

   Georg Lehner

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

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

Looking at the log, 162.144.102.19 is worthy of blocking, but it wasn't
blocked.

FreeBSD theranch 10.2-RELEASE-p18 FreeBSD 10.2-RELEASE-p18 #0: Sat May
28 08:53:43 UTC 2016

# ipfw table 22 list
23.96.234.230/32 0
123.57.174.156/32 0
180.153.88.54/32 0
182.18.34.76/32 0

Jul 28 04:48:34 theranch sshd[16612]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul 28 04:48:35 theranch sshd[16612]: Connection closed by 162.144.102.19 [preauth]
Jul 28 04:52:03 theranch sshd[16629]: Received disconnect from 121.18.238.29: 11:  [preauth]
Jul 28 05:00:00 theranch sshguard[1242]: Reloading rotated file /var/log/maillog.
Jul 28 05:04:34 theranch sshd[16695]: Received disconnect from 121.18.238.22: 11:  [preauth]
Jul 28 05:09:54 theranch sshd[16735]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul 28 05:09:54 theranch sshd[16735]: Connection closed by 162.144.102.19 [preauth]
Jul 28 05:28:35 theranch sshd[16813]: Received disconnect from 221.194.44.216: 11:  [preauth]
Jul 28 05:31:02 theranch sshd[16825]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul 28 05:31:03 theranch sshd[16825]: Connection closed by 162.144.102.19 [preauth]
Jul 28 05:37:51 theranch sshd[16851]: Received disconnect from 221.194.44.194: 11:  [preauth]
Jul 28 05:52:22 theranch sshd[16917]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul 28 05:52:22 theranch sshd[16917]: Connection closed by 162.144.102.19 [preauth]
Jul 28 06:00:00 theranch sshguard[1242]: Reloading rotated file /var/log/dovecot.log.
Jul 28 06:00:50 theranch sshd[16994]: Did not receive identification string from 23.96.234.230
Jul 28 06:05:36 theranch sshd[17014]: Invalid user z from 23.96.234.230
Jul 28 06:05:36 theranch sshd[17014]: input_userauth_request: invalid user z [preauth]
Jul 28 06:05:36 theranch sshd[17014]: Received disconnect from 23.96.234.230: 11: Bye Bye [preauth]
Jul 28 06:05:37 theranch sshguard[1242]: blacklist: added 23.96.234.230
Jul 28 06:05:37 theranch sshguard[1242]: 23.96.234.230: blocking forever (3 attacks in 287 secs, after 1 abuses over 287 secs)
Jul 28 06:14:12 theranch sshd[17062]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul 28 06:14:12 theranch sshd[17062]: Connection closed by 162.144.102.19 [preauth]
Jul 28 06:17:24 theranch sshd[17069]: fatal: Read from socket failed: Connection reset by peer [preauth]
Jul 28 06:18:24 theranch sshd[17073]: Received disconnect from 121.18.238.19: 11:  [preauth]
Jul 28 06:35:23 theranch sshd[17150]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul 28 06:35:23 theranch sshd[17150]: Connection closed by 162.144.102.19 [preauth]
Jul 28 06:56:47 theranch sshd[17210]: reverse mapping checking getaddrinfo for 162-144-102-19.unifiedlayer.com [162.144.102.19] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul 28 06:56:47 theranch sshd[17210]: Connection closed by 162.144.102.19 [preauth]

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

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

On 26/07/16 17:27, li...@la... wrote:
> You should probably state your OS and rev. I only got the strcpy warning. That was on freebsd 10.2 with the ipfw option.
>

Sorry, here comes uname -a

Debian 8.5:
Linux pwx 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) 
i686 GNU/Linux

Debian 7.11
Linux thummim 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u3 i686 GNU/Linux

Using Bison and GCC

Will check fixes later.

Best Regards,

   Georg Lehner

>   Original Message
> From: Georg Lehner
> Sent: Tuesday, July 26, 2016 3:59 PM
> To: ssh...@li...
> Subject: Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0
>
> On 12/07/16 19:05, Kevin Zheng wrote:
>> Hi there,
>>
>> Some non-trivial firewall backend changes have landed in the 'master'
>> branch of SSHGuard. I've been able to test the pf and ipfw backends, but
>> the iptables backend needs testing!
>>
>> Briefly, SSHGuard now controls the firewall using a script, 'sshg-fw'
>> that reads commands from standard input (e.g. 'block 1.2.3.4') and runs
>> the appropriate firewall commands. This should make adding new backends
>> as well as custom hooks easier.
>>
>> If you're able and willing to test, your feedback is appreciated!
>>
>> Best,
>> Kevin
>>
> Hello,
>
> I tried to step forward with iptables testing, but am unable to compile
> sshguard. After following
> http://www.sshguard.net/docs/setup/compile-install/ I get the below errors.
>
> Note: this has not been an issue about two weeks before.
>
> Best Regards,
>
> Georg Lehner
>
> - - -
> Making all in src
> make[1]: Entering directory '/home/jorge/progs/sshguard/src'
> make all-am
> make[2]: Entering directory '/home/jorge/progs/sshguard/src'
> CC parser/attack_parser.o
> parser/attack_parser.y: In function ‘yyparse’:
> parser/attack_parser.y:192:25: warning: implicit declaration of function
> ‘strcpy’ [-Wimplicit-function-declaration]
> strcpy(attack->address.value, $1);
> ^
> parser/attack_parser.y:192:25: warning: incompatible implicit
> declaration of built-in function ‘strcpy’
> parser/attack_parser.y:196:25: warning: incompatible implicit
> declaration of built-in function ‘strcpy’
> strcpy(attack->address.value, $1);
> ^
> parser/attack_parser.y: In function ‘yyerror’:
> parser/attack_parser.y:299:1: error: number of arguments doesn’t match
> prototype
> static void yyerror() { /* do nothing */ }
> ^
> parser/attack_parser.y:34:13: error: prototype declaration
> static void yyerror(attack_t *attack, const char *msg);
> ^
> Makefile:606: recipe for target 'parser/attack_parser.o' failed
> make[2]: *** [parser/attack_parser.o] Error 1
> make[2]: Leaving directory '/home/jorge/progs/sshguard/src'
> Makefile:342: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory '/home/jorge/progs/sshguard/src'
> Makefile:335: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

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

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

On 07/26/2016 16:38, li...@la... wrote:
> Ah, should I expect the strcpy warning to go away with a new git clone?

Yes. If you don't have local changes, running a `git pull` from inside
the source directory should be fine.

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

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

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

Ah, should I expect the strcpy warning to go away with a new git clone?


  Original Message  
From: Kevin Zheng
Sent: Tuesday, July 26, 2016 4:31 PM
To: ssh...@li...
Subject: Re: [SSHGuard-users] Call for testing: SSHGuard 1.7.0

On 07/26/2016 16:27, li...@la... wrote:
> You should probably state your OS and rev. I only got the strcpy
> warning. That was on freebsd 10.2 with the ipfw option.

It's a combination of Bison and GCC. I didn't get your strcpy warning
because I was using yacc. I didn't get the GCC warning because I was
running clang.

I'll have to remember to test with different yaccs and compilers.

Thanks,
Kevin

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

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
sshguard-users mailing list
ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users