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

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

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

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

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

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

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

You should probably state your OS and rev. I only got the strcpy warning. That was on freebsd 10.2 with the ipfw option.

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

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

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

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

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

Re: [SSHGuard-users] Feedback needed on 1.7.0

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

Once the install to tmp is done, I should do a service sshguard stop. I gather I should find the options used by the daemon used by 1.6.4 and then run the binary in tmp using those options.

Here is a reminder on how to build for those who stumble on those auto tools that seem anything but auto to me:
http://www.sshguard.net/docs/setup/compile-install/‎

As an aside, I've seen a major uptick in hacking starting last Thursday. Without naming names, a country that recently thwarted a coup has been running masscan (something like zmap). I have obvious scripts been run on port 80. The exact same sequence of hacks originating from all over the place, which I assume are compromised systems. 

You should never have your guard down, but now seems like a bad time. So if there are problems, I want to switch back to the existing sshguard pronto.
‎

  Original Message  
From: Kevin Zheng
Sent: Monday, July 25, 2016 7:59 PM
To: li...@la...; ssh...@li...
Subject: Re: [SSHGuard-users] Feedback needed on 1.7.0

On 07/25/2016 19:51, li...@la... wrote:
> Since this is a major change, can 1.7.0 be tested without being the
> daemon? That build the code, but don't do the make install step, then
> run the code from where it was built.

You'll need to run `make install` because SSHGuard looks for the helper
script sshg-fw in PREFIX.

However, you can install to a different prefix:

$ ./configure --prefix /tmp/sshguard
$ make install

SSHGuard will be installed using /tmp/sshguard as a prefix, which means
you don't even have to be root to run `make install`. To test, running
/tmp/sshguard/sbin/sshguard will suffice.

> While I have your ear, is there some way to flush/reset table 22?
> Mine seems to be on permanent block.

As root, run:

# ipfw table 22 flush

If this results in an error we'll have to troubleshoot.

Best,
Kevin

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

Re: [SSHGuard-users] Feedback needed on 1.7.0

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

On 07/25/2016 19:51, li...@la... wrote:
> Since this is a major change, can 1.7.0 be tested without being the
> daemon? That build the code, but don't do the make install step, then
> run the code from where it was built.

You'll need to run `make install` because SSHGuard looks for the helper
script sshg-fw in PREFIX.

However, you can install to a different prefix:

$ ./configure --prefix /tmp/sshguard
$ make install

SSHGuard will be installed using /tmp/sshguard as a prefix, which means
you don't even have to be root to run `make install`. To test, running
/tmp/sshguard/sbin/sshguard will suffice.

> While I have your ear, is there some way to flush/reset table 22?
> Mine seems to be on permanent block.

As root, run:

# ipfw table 22 flush

If this results in an error we'll have to troubleshoot.

Best,
Kevin

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

Re: [SSHGuard-users] Feedback needed on 1.7.0

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

Since this is a major change, can 1.7.0 be tested without being the daemon? That build the code, but don't do the make install step, then run the code from where it was built.

While I have your ear, is there some way to flush/reset table 22? Mine seems to be on permanent block.


  Original Message  
From: Kevin Zheng
Sent: Monday, July 25, 2016 4:23 PM
To: ssh...@li...
Subject: [SSHGuard-users] Feedback needed on 1.7.0

Dear SSHGuard users,

SSHGuard 1.7.0 was planned for August, bringing bug fixes, backend
changes, and minor attack signature improvements. Some of these changes
need feedback and testing, and the release won't happen without you!

In no particular order, items that need feedback:

Backends have been rewritten. PF is well-tested, IPFW should work, but
iptables is untested because I don't have a Linux box handy.

The hosts backend should work but needs more testing. If it turns out
that nobody cares about testing/running it I'll drop it from 1.7.0.

Does process validation still work? Should it be dropped from 1.7.0?

LogSucker is deprecated. If you're having issues, use sshg-logtail to
monitor your logs and pipe it into SSHGuard. In future releases "-l" may
just be a convenience flag that invokes sshg-logtail.

External hooks are gone. If you need hooks, edit the sshg-fw script.

sshg-fw and sshg-parser are installed in libexec. Only sshg-fw is
currently needed for SSHGuard to run, but sshg-parser is useful for
checking if your logs are correctly parsed.

To test, check out the 'master' branch from SSHGuard's Bitbucket
repository. If there's anything I can do to make testing easier, please
let me know.

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

[SSHGuard-users] Feedback needed on 1.7.0

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

Dear SSHGuard users,

SSHGuard 1.7.0 was planned for August, bringing bug fixes, backend
changes, and minor attack signature improvements. Some of these changes
need feedback and testing, and the release won't happen without you!

In no particular order, items that need feedback:

Backends have been rewritten. PF is well-tested, IPFW should work, but
iptables is untested because I don't have a Linux box handy.

The hosts backend should work but needs more testing. If it turns out
that nobody cares about testing/running it I'll drop it from 1.7.0.

Does process validation still work? Should it be dropped from 1.7.0?

LogSucker is deprecated. If you're having issues, use sshg-logtail to
monitor your logs and pipe it into SSHGuard. In future releases "-l" may
just be a convenience flag that invokes sshg-logtail.

External hooks are gone. If you need hooks, edit the sshg-fw script.

sshg-fw and sshg-parser are installed in libexec. Only sshg-fw is
currently needed for SSHGuard to run, but sshg-parser is useful for
checking if your logs are correctly parsed.

To test, check out the 'master' branch from SSHGuard's Bitbucket
repository. If there's anything I can do to make testing easier, please
let me know.

Thanks,
Kevin

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

Re: [SSHGuard-users] Odd block

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

On 22/07/16 00:32, li...@la... wrote:
> I decided to dig into this block given the odd name of the domain. Now
> if I am reading this correctly, the getaddrinfo is part of sshd, not
> sshguard. The IP 188.166.242.102 comes back to Digital Ocean, a VPS
> company. Where did poke.diarbag.us come from?
>
> Jul 21 14:07:16 theranch sshd[73068]: Did not receive identification string from 188.166.242.102
> Jul 21 14:13:07 theranch sshd[73095]: reverse mapping checking getaddrinfo for poke.diarbag.us [188.166.242.102] failed - POSSIBLE BREAK-IN ATTEMPT!
> Jul 21 14:13:07 theranch sshd[73095]: Invalid user vagrant from 188.166.242.102
> Jul 21 14:13:07 theranch sshd[73095]: input_userauth_request: invalid user vagrant [preauth]
> Jul 21 14:13:08 theranch sshd[73095]: Received disconnect from 188.166.242.102: 11: Bye Bye [preauth]
> Jul 21 14:13:08 theranch sshguard[809]: blacklist: added 188.166.242.102
>
> ------------------------------------------------------------------------------
> 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
>
Hi: reverse mapping does the following:

1. Get the DNS hostname of the IP address which is connecting to you.
2. From the DNS hostname get - via DNS again - the IP address.
3. Compare if it is the same, if not: POSSIBLE BREAK-IN ATTEMPT!

You can emulate this on the commandline, I'll show it with nslookup, 
which is available on Linux (unix) and Windows systems:
- - -
  jorge@pwx:~$ nslookup
 > 188.166.242.102
Server:		192.168.173.1
Address:	192.168.173.1#53

Non-authoritative answer:
102.242.166.188.in-addr.arpa	name = poke.diarbag.us.

Authoritative answers can be found from:
242.166.188.in-addr.arpa	nameserver = ns2.digitalocean.com.
242.166.188.in-addr.arpa	nameserver = ns3.digitalocean.com.
242.166.188.in-addr.arpa	nameserver = ns1.digitalocean.com.
ns2.digitalocean.com	internet address = 173.245.59.41
ns2.digitalocean.com	has AAAA address 2400:cb00:2049:1::adf5:3b29
ns3.digitalocean.com	internet address = 198.41.222.173
ns3.digitalocean.com	has AAAA address 2400:cb00:2049:1::c629:dead
ns1.digitalocean.com	internet address = 173.245.58.51
ns1.digitalocean.com	has AAAA address 2400:cb00:2049:1::adf5:3a33
 > poke.diarbag.us
Server:		192.168.173.1
Address:	192.168.173.1#53

Non-authoritative answer:
*** Can't find poke.diarbag.us: No answer
 >
- - -
Result is, that there doesn't even exist a DNS entry for poke.diarbag.us.

The owner of the attackers IP address has not set up correctly his/her 
DNS records.  The attack still could come from a different host on the 
Internet, spoofing to be 188.166.242.102.

Poor Diar Bagus most probably has nothing to do with the attack. 
Complaints should go to digitalocean, they should know to whom they lend 
the attackers IP address.

Best Regards,

   Georg Lehner

Re: [SSHGuard-users] Odd block

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

On 22-7-2016 09:07, li...@la... wrote:
> On Fri, 22 Jul 2016 08:51:03 +0200
> Willem Jan Withagen <wj...@di...> wrote:
> 
>> On 22-7-2016 08:32, li...@la... wrote:
>>> I decided to dig into this block given the odd name of the domain.
>>> Now if I am reading this correctly, the getaddrinfo is part of
>>> sshd, not sshguard. The IP 188.166.242.102 comes back to Digital
>>> Ocean, a VPS company. Where did poke.diarbag.us come from?
>>>
>>> Jul 21 14:07:16 theranch sshd[73068]: Did not receive
>>> identification string from 188.166.242.102 Jul 21 14:13:07 theranch
>>> sshd[73095]: reverse mapping checking getaddrinfo for
>>> poke.diarbag.us [188.166.242.102] failed - POSSIBLE BREAK-IN
>>> ATTEMPT! Jul 21 14:13:07 theranch sshd[73095]: Invalid user vagrant
>>> from 188.166.242.102 Jul 21 14:13:07 theranch sshd[73095]:
>>> input_userauth_request: invalid user vagrant [preauth] Jul 21
>>> 14:13:08 theranch sshd[73095]: Received disconnect from
>>> 188.166.242.102: 11: Bye Bye [preauth] Jul 21 14:13:08 theranch
>>> sshguard[809]: blacklist: added 188.166.242.102
>>
>> How about:
>> # host 188.166.242.102
>> 102.242.166.188.in-addr.arpa domain name pointer poke.diarbag.us.
>>
>> --WjW
>>
> 
> I see, but 
> http://www.ip2location.com/188.166.242.102
> leads to Digital Ocean. 
> 
> So on cloudflare, where diarbag.us has its DNS, they set up
> poke.diarbag.us to go to Digital Ocean? Does ip2location have some
> secret sauce? Does it pierce the reverse proxy of Cloudflare?
> 
> Doing a whois, the owners name is Diar Bagus, so the domain name is,
> well, clever. I don't think anyone knocks on port 22 using their
> real name, so maybe the server is hacked.

Different questions, Different tools, different answers :)
Host gives you DNS
whois gives you the owner of the IP-number
Which can be different as you found out.

--WjW

# whois 188.166.242.102
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

refer:        whois.ripe.net

inetnum:      188.0.0.0 - 188.255.255.255
organisation: Administered by RIPE NCC
status:       LEGACY

whois:        whois.ripe.net

changed:      1993-05
source:       IANA

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '188.166.0.0 - 188.166.255.255'

% Abuse contact for '188.166.0.0 - 188.166.255.255' is
'ab...@di...'

inetnum:        188.166.0.0 - 188.166.255.255
netname:        EU-DIGITALOCEAN-20090605
country:        NL
org:            ORG-DOI2-RIPE
admin-c:        PT7353-RIPE
tech-c:         PT7353-RIPE
status:         ALLOCATED PA
mnt-by:         RIPE-NCC-HM-MNT
mnt-lower:      digitalocean
mnt-routes:     digitalocean
mnt-domains:    digitalocean
created:        2014-11-17T16:36:42Z
last-modified:  2016-04-14T09:45:15Z
source:         RIPE # Filtered

organisation:   ORG-DOI2-RIPE
org-name:       Digital Ocean, Inc.
org-type:       LIR
address:        101 Ave of the Americas
                10th Floor
address:        New York
address:        10013
address:        UNITED STATES
phone:          +1 888 890 6714
mnt-ref:        digitalocean
mnt-ref:        RIPE-NCC-HM-MNT
mnt-by:         RIPE-NCC-HM-MNT
abuse-mailbox:  ab...@di...
abuse-c:        AD10778-RIPE
created:        2012-11-29T14:59:01Z
last-modified:  2015-11-19T16:11:55Z
source:         RIPE # Filtered

person:         Network Operations
address:        101 Ave of the Americas, 10th Floor, New York, NY 10013
phone:          +13478756044
nic-hdl:        PT7353-RIPE
mnt-by:         digitalocean
created:        2015-03-11T16:37:07Z
last-modified:  2015-11-19T15:57:21Z
source:         RIPE # Filtered
org:            ORG-DOI2-RIPE

% This query was served by the RIPE Database Query Service version
1.87.4 (DB-1)

Re: [SSHGuard-users] Odd block

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

On Fri, 22 Jul 2016 08:51:03 +0200
Willem Jan Withagen <wj...@di...> wrote:

> On 22-7-2016 08:32, li...@la... wrote:
> > I decided to dig into this block given the odd name of the domain.
> > Now if I am reading this correctly, the getaddrinfo is part of
> > sshd, not sshguard. The IP 188.166.242.102 comes back to Digital
> > Ocean, a VPS company. Where did poke.diarbag.us come from?
> > 
> > Jul 21 14:07:16 theranch sshd[73068]: Did not receive
> > identification string from 188.166.242.102 Jul 21 14:13:07 theranch
> > sshd[73095]: reverse mapping checking getaddrinfo for
> > poke.diarbag.us [188.166.242.102] failed - POSSIBLE BREAK-IN
> > ATTEMPT! Jul 21 14:13:07 theranch sshd[73095]: Invalid user vagrant
> > from 188.166.242.102 Jul 21 14:13:07 theranch sshd[73095]:
> > input_userauth_request: invalid user vagrant [preauth] Jul 21
> > 14:13:08 theranch sshd[73095]: Received disconnect from
> > 188.166.242.102: 11: Bye Bye [preauth] Jul 21 14:13:08 theranch
> > sshguard[809]: blacklist: added 188.166.242.102
> 
> How about:
> # host 188.166.242.102
> 102.242.166.188.in-addr.arpa domain name pointer poke.diarbag.us.
> 
> --WjW
> 

I see, but 
http://www.ip2location.com/188.166.242.102
leads to Digital Ocean. 

So on cloudflare, where diarbag.us has its DNS, they set up
poke.diarbag.us to go to Digital Ocean? Does ip2location have some
secret sauce? Does it pierce the reverse proxy of Cloudflare?

Doing a whois, the owners name is Diar Bagus, so the domain name is,
well, clever. I don't think anyone knocks on port 22 using their
real name, so maybe the server is hacked.

[SSHGuard-users] Odd block

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

I decided to dig into this block given the odd name of the domain. Now
if I am reading this correctly, the getaddrinfo is part of sshd, not
sshguard. The IP 188.166.242.102 comes back to Digital Ocean, a VPS
company. Where did poke.diarbag.us come from?

Jul 21 14:07:16 theranch sshd[73068]: Did not receive identification string from 188.166.242.102
Jul 21 14:13:07 theranch sshd[73095]: reverse mapping checking getaddrinfo for poke.diarbag.us [188.166.242.102] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul 21 14:13:07 theranch sshd[73095]: Invalid user vagrant from 188.166.242.102
Jul 21 14:13:07 theranch sshd[73095]: input_userauth_request: invalid user vagrant [preauth]
Jul 21 14:13:08 theranch sshd[73095]: Received disconnect from 188.166.242.102: 11: Bye Bye [preauth]
Jul 21 14:13:08 theranch sshguard[809]: blacklist: added 188.166.242.102

[SSHGuard-users] Call for testing: SSHGuard 1.7.0

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

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

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

Re: [SSHGuard-users] Inconvenient logging with SSHGUARD_DEBUG=yes

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

On 07/07/2016 22:20, Georg Lehner wrote:
> Information from the sshguard package:
> 
> Package: sshguard
> Version: 1.5-5
> Installed-Size: 333
> Maintainer: Julián Moreno Patiño <dar...@gm...>
> ...
> - - -
> 
> running sshguard -v:
> 
> shguard 1.5.0

I'm not exactly sure what happened between then and now that caused this
issue to surface. 1.5.0 didn't recognize socklog messages at all.

In any case, the issue should be fixed now. Thanks again!

Best,
Kevin

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

Re: [SSHGuard-users] Inconvenient logging with SSHGUARD_DEBUG=yes

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

On 07/07/16 23:15, Kevin Zheng wrote:
> On 07/07/2016 15:09, Georg Lehner wrote:
>> When testing the recent sshguard with debugging on it started to
>> feedback itself into an endless loop, by writing messages to the syslog
>> with facility auth.debug.
>>
>>    auth.debug: Jul  7 23:43:26 sshguard[5840]: Read line from
>> '/var/log/socklog/main/current'.
>>
>> This did not happen with the precompiled sshguard (Debian Squeeze).
>> Maybe debug logging should go to another facility, e.g. daemon, user or
>> local0.
>
> What version is the packaged SSHGuard? I wonder which change caused this
> issue to surface?
>
> I never caught this issue because my system syslog facility has a rule
> that sends all debug output to a separate file.
>
> A fix was committed in b89b706. Thanks for the report!
>
> Best,
> Kevin
>

Information from the sshguard package:

Package: sshguard
Version: 1.5-5
Installed-Size: 333
Maintainer: Julián Moreno Patiño <dar...@gm...>
...
- - -

running sshguard -v:

shguard 1.5.0

Copyright (c) 2007,2008 Mij <mi...@ss...>
This is free software; see the source for conditions on copying.

- - -

Best Regards,

   Georg Lehner

Re: [SSHGuard-users] Inconvenient logging with SSHGUARD_DEBUG=yes

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

On 07/07/2016 15:09, Georg Lehner wrote:
> When testing the recent sshguard with debugging on it started to 
> feedback itself into an endless loop, by writing messages to the syslog 
> with facility auth.debug.
> 
>    auth.debug: Jul  7 23:43:26 sshguard[5840]: Read line from 
> '/var/log/socklog/main/current'.
> 
> This did not happen with the precompiled sshguard (Debian Squeeze). 
> Maybe debug logging should go to another facility, e.g. daemon, user or 
> local0.

What version is the packaged SSHGuard? I wonder which change caused this
issue to surface?

I never caught this issue because my system syslog facility has a rule
that sends all debug output to a separate file.

A fix was committed in b89b706. Thanks for the report!

Best,
Kevin

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

Re: [SSHGuard-users] socklog lines not captured

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

Hi Georg,

On 07/07/2016 15:03, Georg Lehner wrote:
> After trying all else I checked out current sources. Where socklog is 
> mentioned attack_scanner.l gives example loglines:
> 
>    * "2015-05-27T04:31:28.10040 auth.info: May 27 04:31:28 sshd[30993]: "
>    * "2015-05-27T04:31:28.10040 auth.info: sshd[30993]: "
> 
> So, my socklog does not insert timestamps in front of the logged messages.

Thanks for reporting this issue and providing a patch. The fix was
committed in 1da08e5 and is attached here as well.

Best,
Kevin

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

[SSHGuard-users] socklog lines not captured

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

Hello List!

I am operating some Debian/Linux servers (Squeeze/ 7.x) where Syslog is 
replaced by socklog.

This week I tried out sshguard, but got no matches on my logfiles.

My socklog's loglines look like this:
- - -
auth.info: Jul  7 20:54:30 sshd[24329]: User root from 218.205.161.10 
not allowed because not listed in AllowUsers
auth.info: Jul  7 20:54:30 sshd[24329]: input_userauth_request: invalid 
user root [preauth]
auth.info: Jul  7 20:54:30 sshd[24329]: Connection closed by 
218.205.161.10 [preauth]
- - -

After trying all else I checked out current sources. Where socklog is 
mentioned attack_scanner.l gives example loglines:

   * "2015-05-27T04:31:28.10040 auth.info: May 27 04:31:28 sshd[30993]: "
   * "2015-05-27T04:31:28.10040 auth.info: sshd[30993]: "

So, my socklog does not insert timestamps in front of the logged messages.

Find below a patch to make the timestamp optional.  Since I have an 
"old" iptables (1.4.14) I needed to remove the "-w" option for iptables 
in commands_iptables.h.

Best Regards,

   Georg Lehner

diff --git a/src/fwalls/command_iptables.h b/src/fwalls/command_iptables.h
index aea039c..9b659e4 100644
--- a/src/fwalls/command_iptables.h
+++ b/src/fwalls/command_iptables.h
@@ -26,8 +26,8 @@

  #include "../config.h"

-/* backwards compatible with -w  */
-#define IPTBLCMD "TBL=iptables; if [ x$SSHG_ADDRKIND = x6 ]; then 
TBL=ip6tables; fi; iptblscmd() { " IPTABLES_PATH "/$TBL -w $@; r=$?; if 
[ $r -eq 2 ]; then exec " IPTABLES_PATH "/$TBL $@; fi; exit $r; }; 
iptblscmd "
+/* removed -w for old iptables (1.4.14  */
+#define IPTBLCMD "TBL=iptables; if [ x$SSHG_ADDRKIND = x6 ]; then 
TBL=ip6tables; fi; iptblscmd() { " IPTABLES_PATH "/$TBL $@; r=$?; if [ 
$r -eq 2 ]; then exec " IPTABLES_PATH "/$TBL $@; fi; exit $r; }; iptblscmd "

  /* for initializing the firewall (+ make sure we have sufficient 
credentials) */
  #define COMMAND_INIT       IPTBLCMD "-L -n"
diff --git a/src/parser/attack_scanner.l b/src/parser/attack_scanner.l
index 9b43f31..9dc3382 100644
--- a/src/parser/attack_scanner.l
+++ b/src/parser/attack_scanner.l
@@ -113,13 +113,16 @@ FACLEVEL (<[a-zA-Z0-9]+\.[a-zA-Z0-9]+>)
    *
    * Some strip the redundant timestamp, eg
    * "2015-05-27T04:31:28.10040 auth.info: sshd[30993]: "
+  *
+  * Other don't timestamp lines at all:
+  * "auth.info: May 27 04:31:28 sshd[30993]: "
    */
-{TIMESTAMP_ISO8601}" "{WORD}.{WORD}": "({TIMESTAMP_SYSLOG}" 
")?{PROCESSNAME}("/"{PROCESSNAME})?"["{NUMBER}"]: "{SOLARIS_MSGID_TAG}? {
+({TIMESTAMP_ISO8601}" ")?{WORD}.{WORD}": "({TIMESTAMP_SYSLOG}" 
")?{PROCESSNAME}("/"{PROCESSNAME})?"["{NUMBER}"]: "{SOLARIS_MSGID_TAG}? {
          yylval.num = getsyslogpid(yytext, yyleng);
          return SOCKLOG_BANNER_PID;
          }

-{TIMESTAMP_ISO8601}" "{WORD}.{WORD}": "({TIMESTAMP_SYSLOG}" 
")?({PROCESSNAME}("/"{PROCESSNAME})?":")?   { return SOCKLOG_BANNER; }
+({TIMESTAMP_ISO8601}" ")?{WORD}.{WORD}": "({TIMESTAMP_SYSLOG}" 
")?({PROCESSNAME}("/"{PROCESSNAME})?":")?   { return SOCKLOG_BANNER; }


   /* SSH: invalid or rejected user (cross platform [generated by 
openssh]) */

[SSHGuard-users] Inconvenient logging with SSHGUARD_DEBUG=yes

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

Hello List!

When testing the recent sshguard with debugging on it started to 
feedback itself into an endless loop, by writing messages to the syslog 
with facility auth.debug.

   auth.debug: Jul  7 23:43:26 sshguard[5840]: Read line from 
'/var/log/socklog/main/current'.

This did not happen with the precompiled sshguard (Debian Squeeze). 
Maybe debug logging should go to another facility, e.g. daemon, user or 
local0.

Best Regards,

    Georg Lehner