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

[SSHGuard-users] BLACKLIST_FILE

[Doug N. <dn...@uc...>]

Hi Folks,

Thanks for your help getting SSHGuard working for me last weekend in MacOS Sierra, it’s working well.

I do see the following in the .conf file, which I’ve uncommented:

# Colon-separated blacklist threshold and full path to blacklist file.
# (optional, no default)
BLACKLIST_FILE=90:/usr/local/etc/blacklist

However, on all of our machines, the blacklist remains empty and  untouched. Am I missing a step to make this work? These machines get hammered pretty hard, and even in my testing with SSH Brute Enforcer (https://github.com/R4stl1n/SSH-Brute-Forcer) I don’t see any changes to this file.

Also: if I manually add an IP or range to the blacklist, will this also be sent to PF somehow?

Yes, these are newbie questions but I appreciate your help!

Doug

Re: [SSHGuard-users] attack signatures different services

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

If you are going to add more triggers to sshguard, my feature suggestion is to have multiple tables of IP addresses that can be associated with each trigger. ( My terminology is from the view of ipfw.) ‎My concerned is accidentally triggering a ssh 22 block by misconfiguring some mail service or pen testing, then locking myself out of port 22. 

Port 22 is sacred! ;-) I wonder how many people run sshguard strictly for 22 then use fail2ban for other services. In my case, I don't bother with fail2ban but rather rate limit the services that can be attacked. Anvil for postfix for example.
  Original Message  
From: Kevin Zheng
Sent: Tuesday, January 3, 2017 12:12 PM
To: ssh...@li...; jungle Boogie
Subject: Re: [SSHGuard-users] attack signatures different services

On 01/03/2017 13:51, jungle Boogie wrote:
> Is there a possibility of including things like FreeSWITCH?

Yes, someone just needs to write rules for sshg-parser.

If you have an account on Bitbucket, go ahead and create an issue for 
FreeSWITCH. If not, I can open an issue for you so we don't forget.

Writing rules for sshg-parser is currently somewhat painful.

> FYI, http://www.sshguard.net/ link for sshd is now wrong, should be
> https://www.openssh.com/

Fixed, thanks for the report.

Best,
Kevin

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
sshguard-users mailing list
ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [SSHGuard-users] attack signatures different services

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

On 01/03/2017 13:51, jungle Boogie wrote:
> Is there a possibility of including things like FreeSWITCH?

Yes, someone just needs to write rules for sshg-parser.

If you have an account on Bitbucket, go ahead and create an issue for 
FreeSWITCH. If not, I can open an issue for you so we don't forget.

Writing rules for sshg-parser is currently somewhat painful.

> FYI, http://www.sshguard.net/ link for sshd is now wrong, should be
> https://www.openssh.com/

Fixed, thanks for the report.

Best,
Kevin

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

[SSHGuard-users] attack signatures different services

[jungle B. <jun...@gm...>]

Hi All,

Am I understanding correctly, the full list of what sshguard can block
is listed here:
http://www.sshguard.net/docs/reference/attack-signatures/

This amounts to ssh, mail, ftp.

Is there a possibility of including things like FreeSWITCH?

Here's an example log from a bad user:
9568ef4e-ce58-11e6-a604-736db5881309 2016-12-29 22:24:14.034837
[DEBUG] sofia.c:9851 sofia/internal/aor3=3--@68.96.222.9 receiving
invite from 163.172.125.91:57347 version: 1.9.0 git eef2313 2016-12-20
22:19:30Z 32bit
2016-12-29 22:24:14.034837 [DEBUG] sofia.c:10018 IP 163.172.125.91
Rejected by acl "domains". Falling back to Digest auth.
2016-12-29 22:24:14.054870 [WARNING] sofia_reg.c:1792 SIP auth
challenge (INVITE) on sofia profile 'internal' for
[0048678887178@68.96.222.9] from ip 163.172.125.91
9568ef4e-ce58-11e6-a604-736db5881309 2016-12-29 22:24:14.294838
[DEBUG] sofia.c:9851 sofia/internal/aor3=3--@68.96.222.9 receiving
invite from 163.172.125.91:57347 version: 1.9.0 git eef2313 2016-12-20
22:19:30Z 32bit
2016-12-29 22:24:14.294838 [DEBUG] sofia.c:10018 IP 163.172.125.91
Rejected by acl "domains". Falling back to Digest auth.
2016-12-29 22:24:14.294838 [WARNING] sofia_reg.c:2906 Can't find user
[a'or'3=3--@192.168.0.137] from 163.172.125.91
2016-12-29 22:24:14.294838 [WARNING] sofia_reg.c:1737 SIP auth failure
(INVITE) on sofia profile 'internal' for [0048678887178@68.96.222.9]
from ip 163.172.125.91
e9e650b6-ce58-11e6-a606-736db5881309 2016-12-29 22:26:35.794835
[DEBUG] sofia.c:9851 sofia/internal/aor3=3--@68.96.222.9 receiving
invite from 163.172.125.91:58453 version: 1.9.0 git eef2313 2016-12-20
22:19:30Z 32bit
2016-12-29 22:26:35.794835 [DEBUG] sofia.c:10018 IP 163.172.125.91
Rejected by acl "domains". Falling back to Digest auth.
2016-12-29 22:26:35.794835 [WARNING] sofia_reg.c:1792 SIP auth
challenge (INVITE) on sofia profile 'internal' for
[0048678887178@68.96.222.9] from ip 163.172.125.91


FYI, http://www.sshguard.net/ link for sshd is now wrong, should be
https://www.openssh.com/

Thanks!

-- 
-------
inum: 883510009027723
sip: jun...@si...

Re: [SSHGuard-users] Call for testing and feedback for SSHGuard 2.0

[jungle B. <jun...@gm...>]

Hi Kevin,
On Jan 2, 2017 2:19 PM, "Kevin Zheng" <kev...@gm...> wrote:
>
> Hi there,
>
> A lot of work to get SSHGuard working with new log sources (journalctl,
> macOS log) and backends (firewalld, ipset) has happened in 2.0.
>
> The new version also uses a configuration file.
>
> Some deprecated backends have been resurrected (hosts, ipfilter).
>
> Most importantly, SSHGuard has been split into several processes piped
> into one another (sshg-logmon | sshg-parser | sshg-blocker | sshg-fw).
> sshg-parser can run with capsicum(4) and pledge(2). sshg-blocker can be
> sandboxed in its default configuration (without pid file, whitelist,
> blacklisting) and has not been tested sandboxed in other configurations.
>

I'm going to give this a shot on that one host that had a problem. The OS
has been reinstalled so I'm hoping it will make a difference this time
around.

Can you point us to the latest documentation?

Thanks for your efforts, IMO, to make sshguard easier to use.

>
> The experimental code is available on SourceForge as 1.99.0 [1].
>
> Thanks,
> Kevin
>
> [1] https://sourceforge.net/projects/sshguard/files/sshguard/1.99.0/
>
> --
> Kevin Zheng
> kev...@gm... | ke...@be... | PGP: 0xC22E1090
>
>

[SSHGuard-users] Call for testing and feedback for SSHGuard 2.0

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

Hi there,

A lot of work to get SSHGuard working with new log sources (journalctl, 
macOS log) and backends (firewalld, ipset) has happened in 2.0.

The new version also uses a configuration file.

Some deprecated backends have been resurrected (hosts, ipfilter).

Most importantly, SSHGuard has been split into several processes piped 
into one another (sshg-logmon | sshg-parser | sshg-blocker | sshg-fw). 
sshg-parser can run with capsicum(4) and pledge(2). sshg-blocker can be 
sandboxed in its default configuration (without pid file, whitelist, 
blacklisting) and has not been tested sandboxed in other configurations.

The sshguard program is now a driver script that glues everything 
together. It's probably still a little fragile.

Some cleanup work remains. Documentation is also being updated.

I encourage package maintainers and people with suitable test 
environments to give the new code a shot and provide feedback.

The experimental code is available on SourceForge as 1.99.0 [1].

Thanks,
Kevin

[1] https://sourceforge.net/projects/sshguard/files/sshguard/1.99.0/

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

Re: [SSHGuard-users] SSHGuard not working in MacOS 10.12 (Sierra)

[Doug N. <dn...@uc...>]

Daniel, Steve, Kevin,

You guys are awesome, thanks for the quick replies and I’ll give your revised solution a spin! Very happy that this should work, SSHGuard has been a godsend.

Cheers, Doug

Re: [SSHGuard-users] SSHGuard not working in MacOS 10.12 (Sierra)

[Steve W. <st...@sw...>]

> On 2 Jan 2017, at 10:04, Daniel Aleksandersen <co...@da...> wrote:
> 
> On Mon, Jan 2, 2017, at 06:20, Kevin Zheng wrote:
>> On 01/01/2017 21:44, Doug Niven wrote:
>>> I’m pretty sure SSHGuard is unable to work in MacOS 10.12 (Sierra)
>>> because of how Apple recently changed logging in this new OS upgrade.
>>> No longer are failed SSH logins recorded in /var/log/system.log or
>>> any other system log file, because Apple has moved to “unified
>>> logging”.
>> 
>> Thanks for the report.
>> 
>>> A Terminal command like the following will show some of the
>>> information we’re after, but I’m not sure how this would need to be
>>> incorporated into SSHGuard to allow it to work as before:
>>> 
>>> % log show --predicate '(eventMessage CONTAINS "maximum
>>> authentication attempts exceeded")' --style syslog —info
>> 
>> Now, will this command be like `tail` and give us a pipe with new 
>> messages like they come in, or like dmesg and just give us a view of the 
>> buffer?
>> 
>>> If anyone has any suggestions or ideas please let me know, since I’m
>>> a big fan of SSHGuard and would to have it work in Sierra.
> 
> Doug, see this example for how to stream macOS’ sshd log to SSHGuard:
> https://bitbucket.org/sshguard/sshguard/src/e96d19f2e98c/examples/net.sshguard.plist
> 
> I tested it with the git master version just now, and it worked fine.
> Not sure if it will work with the current stable release, but you can
> let us know if it doesn’t!
> 
> Though it should be configured in the config file rather than the
> launchd service file starting with SSHGuard 2.0. I’ll opened a pull
> request for updating the documentation to match:
> https://bitbucket.org/sshguard/sshguard/pull-requests/18/
> 
>> This sounds a bit like the situation with journalctl on Linux. This is 
>> being solved by piping journalctl output to SSHGuard (see commit edd8414 
>> in what will become 2.0).

I tried moving the log command from the launch plist to sshguard.conf but had to escape the double quotes in the predicate list to get it to parse correctly.
In my case I’m monitoring sshd, dovecot and postfix.

LOGREADER="/usr/bin/log stream --style syslog --info --predicate 'processImagePath == \"/usr/sbin/sshd\" or processImagePath contains \"dovecot\" or processImagePath contains \"postfix/smtpd\"'"

This is working with the latest commit (e96d19f) on MacOS 10.12.2.

Cheers,
Steve

Re: [SSHGuard-users] SSHGuard not working in MacOS 10.12 (Sierra)

[Daniel A. <co...@da...>]

On Mon, Jan 2, 2017, at 06:20, Kevin Zheng wrote:
> On 01/01/2017 21:44, Doug Niven wrote:
> > I’m pretty sure SSHGuard is unable to work in MacOS 10.12 (Sierra)
> > because of how Apple recently changed logging in this new OS upgrade.
> > No longer are failed SSH logins recorded in /var/log/system.log or
> > any other system log file, because Apple has moved to “unified
> > logging”.
> 
> Thanks for the report.
> 
> > A Terminal command like the following will show some of the
> > information we’re after, but I’m not sure how this would need to be
> > incorporated into SSHGuard to allow it to work as before:
> >
> > % log show --predicate '(eventMessage CONTAINS "maximum
> > authentication attempts exceeded")' --style syslog —info
> 
> Now, will this command be like `tail` and give us a pipe with new 
> messages like they come in, or like dmesg and just give us a view of the 
> buffer?
> 
> > If anyone has any suggestions or ideas please let me know, since I’m
> > a big fan of SSHGuard and would to have it work in Sierra.

Doug, see this example for how to stream macOS’ sshd log to SSHGuard:
https://bitbucket.org/sshguard/sshguard/src/e96d19f2e98c/examples/net.sshguard.plist

I tested it with the git master version just now, and it worked fine.
Not sure if it will work with the current stable release, but you can
let us know if it doesn’t!

Though it should be configured in the config file rather than the
launchd service file starting with SSHGuard 2.0. I’ll opened a pull
request for updating the documentation to match:
https://bitbucket.org/sshguard/sshguard/pull-requests/18/

> This sounds a bit like the situation with journalctl on Linux. This is 
> being solved by piping journalctl output to SSHGuard (see commit edd8414 
> in what will become 2.0).
-- 
Daniel Aleksandersen
https://daniel.priv.no/

Re: [SSHGuard-users] SSHGuard not working in MacOS 10.12 (Sierra)

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

Hi Doug,

On 01/01/2017 21:44, Doug Niven wrote:
> I’m pretty sure SSHGuard is unable to work in MacOS 10.12 (Sierra)
> because of how Apple recently changed logging in this new OS upgrade.
> No longer are failed SSH logins recorded in /var/log/system.log or
> any other system log file, because Apple has moved to “unified
> logging”.

Thanks for the report.

> A Terminal command like the following will show some of the
> information we’re after, but I’m not sure how this would need to be
> incorporated into SSHGuard to allow it to work as before:
>
> % log show --predicate '(eventMessage CONTAINS "maximum
> authentication attempts exceeded")' --style syslog —info

Now, will this command be like `tail` and give us a pipe with new 
messages like they come in, or like dmesg and just give us a view of the 
buffer?

> If anyone has any suggestions or ideas please let me know, since I’m
> a big fan of SSHGuard and would to have it work in Sierra.

This sounds a bit like the situation with journalctl on Linux. This is 
being solved by piping journalctl output to SSHGuard (see commit edd8414 
in what will become 2.0).

Best,
Kevin

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

[SSHGuard-users] SSHGuard not working in MacOS 10.12 (Sierra)

[Doug N. <dn...@uc...>]

Hi Folks,

I’m pretty sure SSHGuard is unable to work in MacOS 10.12 (Sierra) because of how Apple recently changed logging in this new OS upgrade. No longer are failed SSH logins recorded in /var/log/system.log or any other system log file, because Apple has moved to “unified logging”. 

A Terminal command like the following will show some of the information we’re after, but I’m not sure how this would need to be incorporated into SSHGuard to allow it to work as before:

% log show --predicate '(eventMessage CONTAINS "maximum authentication attempts exceeded")' --style syslog —info

If anyone has any suggestions or ideas please let me know, since I’m a big fan of SSHGuard and would to have it work in Sierra.

Cheers, Doug

Re: [SSHGuard-users] Blacklist

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

On 12/28/2016 15:50, Jos Chrispijn wrote:
> Thanks, but I am not quite sure what the first three columns mean in
> that file:
>
> 1478009645|260|4|xxx.xxx.xxx.xxx

Unix time stamp of block (unused), service code (unused), IP address 
family (4 or 6), and IP address

Best,
Kevin

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

Re: [SSHGuard-users] Blacklist

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

Thanks, but I am not quite sure what the first three columns mean in 
that file:

1478009645|260|4|xxx.xxx.xxx.xxx

Are they adjusted by sshguard when needed?

thanks,
Jos

Op 25-12-2016 om 16:27 schreef Kevin Zheng:
> On 12/25/2016 07:49, Jos Chrispijn wrote:
>> I want to blacklist a certain ip address manually / ad an ip address in
>> SSHGuard's blacklist.
>> Can you tell me how I can do that? So I am not using ipfw for that (in
>> the end it has the same result, I know).
> Stop SSHGuard, edit the blacklist file using a text editor, and start
> SSHGuard again.
>
> Best,
> Kevin
>


-- With both feed on the ground you will never make a step forward

Re: [SSHGuard-users] Blacklist

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

On 12/25/2016 07:49, Jos Chrispijn wrote:
> I want to blacklist a certain ip address manually / ad an ip address in
> SSHGuard's blacklist.
> Can you tell me how I can do that? So I am not using ipfw for that (in
> the end it has the same result, I know).

Stop SSHGuard, edit the blacklist file using a text editor, and start 
SSHGuard again.

Best,
Kevin

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

[SSHGuard-users] Blacklist

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

I want to blacklist a certain ip address manually / ad an ip address in 
SSHGuard's blacklist.
Can you tell me how I can do that? So I am not using ipfw for that (in 
the end it has the same result, I know).

Thanks!

Re: [SSHGuard-users] Missed detections of ssh abuses

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

On 12/19/2016 23:09, Jonathan Woithe wrote:
> On Tue, Oct 25, 2016 at 11:04:42AM -0700, Kevin Zheng wrote:
>> On 10/24/2016 17:05, Jonathan Woithe wrote:
>>> In this case, sshguard evidently blocked 91.224.160.131 after 4 of the
>>> "Failed password" messages, as I would expect.  What I can't work out is why
>>> 91.224.160.131 was blocked while 212.129.60.203 was not, even though they
>>> generated the same messages.  The only difference is that 91.224.160.131 had
>>> the single failure around 6 hours before the main block, but this should not
>>> make a difference.
>>
>> It appears that SSHGuard is not recognizing any of the messages with
>> "port NNNN" at the end.
>>
>>> [1] For example, the "Invalid user inexu from 6.6.6.0" rule would not detect
>>> the "Invalid user guest from 212.129.60.203 port 52019" entries because our
>>> ssh logs the port number on the end of the rule.  This rule might require
>>> "arbitrary text" to be added to the end to allow for this.
>>
>> I think this is the solution.
>
> Has such a solution been implemented yet?  If not, an initial patch is
> included at the end of this email.  Please do check it for correctness: I'm
> still getting my head around the .l/.y syntax.

Committed in 4702f7f, thanks!

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

Re: [SSHGuard-users] Missed detections of ssh abuses

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

On 12/19/2016 23:09, Jonathan Woithe wrote:
> On Tue, Oct 25, 2016 at 11:04:42AM -0700, Kevin Zheng wrote:
>> On 10/24/2016 17:05, Jonathan Woithe wrote:
>>> In this case, sshguard evidently blocked 91.224.160.131 after 4 of the
>>> "Failed password" messages, as I would expect.  What I can't work out is why
>>> 91.224.160.131 was blocked while 212.129.60.203 was not, even though they
>>> generated the same messages.  The only difference is that 91.224.160.131 had
>>> the single failure around 6 hours before the main block, but this should not
>>> make a difference.
>>
>> It appears that SSHGuard is not recognizing any of the messages with
>> "port NNNN" at the end.
>>
>>> [1] For example, the "Invalid user inexu from 6.6.6.0" rule would not detect
>>> the "Invalid user guest from 212.129.60.203 port 52019" entries because our
>>> ssh logs the port number on the end of the rule.  This rule might require
>>> "arbitrary text" to be added to the end to allow for this.
>>
>> I think this is the solution.
>
> Has such a solution been implemented yet?  If not, an initial patch is
> included at the end of this email.  Please do check it for correctness: I'm
> still getting my head around the .l/.y syntax.

No. As you can see, implementing even such a "small" change turns out to 
be not so trivial. Your patch appears correct by inspection. I'll take a 
closer look soon-ish.

Thanks,
Kevin

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

Re: [SSHGuard-users] Missed detections of ssh abuses

[Jonathan W. <jw...@at...>]

On Tue, Oct 25, 2016 at 11:04:42AM -0700, Kevin Zheng wrote:
> On 10/24/2016 17:05, Jonathan Woithe wrote:
> > In this case, sshguard evidently blocked 91.224.160.131 after 4 of the
> > "Failed password" messages, as I would expect.  What I can't work out is why
> > 91.224.160.131 was blocked while 212.129.60.203 was not, even though they
> > generated the same messages.  The only difference is that 91.224.160.131 had
> > the single failure around 6 hours before the main block, but this should not
> > make a difference.
> 
> It appears that SSHGuard is not recognizing any of the messages with
> "port NNNN" at the end.
> 
> > [1] For example, the "Invalid user inexu from 6.6.6.0" rule would not detect
> > the "Invalid user guest from 212.129.60.203 port 52019" entries because our
> > ssh logs the port number on the end of the rule.  This rule might require
> > "arbitrary text" to be added to the end to allow for this.
> 
> I think this is the solution.

Has such a solution been implemented yet?  If not, an initial patch is
included at the end of this email.  Please do check it for correctness: I'm
still getting my head around the .l/.y syntax.

Regards
  jonathan

This patch against sshguard 1.7.0 adds arbitrary text to the end of "invalid
user" ssh messages.  This covers the cases where additional text is appended
to this message (most commonly the incoming port number).

--- sshguard-1.7.0-new/src/parser/attack_parser.y	2016-10-26 09:28:32.071665939 +1030
+++ sshguard-1.7.0-new2/src/parser/attack_parser.y	2016-10-26 09:22:42.997004608 +1030
@@ -69,7 +69,7 @@
 /* flat tokens */
 %token SYSLOG_BANNER TIMESTAMP_SYSLOG TIMESTAMP_ISO8601 TIMESTAMP_TAI64 AT_TIMESTAMP_TAI64 METALOG_BANNER SOCKLOG_BANNER
 /* ssh */
-%token SSH_INVALUSERPREF SSH_NOTALLOWEDPREF SSH_NOTALLOWEDSUFF
+%token SSH_INVALUSERPREF SSH_INVALDUSERSUFF SSH_NOTALLOWEDPREF SSH_NOTALLOWEDSUFF
 %token SSH_LOGINERR_PREF SSH_LOGINERR_SUFF SSH_LOGINERR_PAM
 %token SSH_VIA
 %token SSH_NOIDENTIFSTR SSH_BADPROTOCOLIDENTIF SSH_BADPROTOCOLIDENTIF_SUFF
@@ -219,7 +219,7 @@
 
 ssh_illegaluser:
     /* nonexistent user */
-    SSH_INVALUSERPREF addr
+    SSH_INVALUSERPREF addr SSH_INVALDUSERSUFF
     /* existent, unallowed user */
     | SSH_NOTALLOWEDPREF addr SSH_NOTALLOWEDSUFF
     ;
--- sshguard-1.7.0-new/src/parser/attack_scanner.l	2016-10-26 09:28:16.783513172 +1030
+++ sshguard-1.7.0-new2/src/parser/attack_scanner.l	2016-10-26 09:24:22.852473989 +1030
@@ -38,7 +38,7 @@
 
  /* Start Conditions */
  /* for Login services */
-%s ssh_notallowed ssh_loginerr ssh_reversemap ssh_disconnect ssh_badproto ssh_badkex
+%s ssh_invaliduser ssh_notallowed ssh_loginerr ssh_reversemap ssh_disconnect ssh_badproto ssh_badkex
  /* for Mail services */
 %s dovecot_loginerr cyrusimap_loginerr exim_esmtp_autherr sendmail_relaydenied sendmail_authfailure sendmail_noissue postfix_loginerr
  /* for FTP services */
@@ -123,7 +123,8 @@
 
 
  /* SSH: invalid or rejected user (cross platform [generated by openssh]) */
-[Ii]"nvalid user ".+" from "                                    { return SSH_INVALUSERPREF; }
+[Ii]"nvalid user ".+" from "                                    { BEGIN(ssh_invaliduser); return SSH_INVALUSERPREF; }
+<ssh_invaliduser>.*                                             { BEGIN(INITIAL); return SSH_INVALDUSERSUFF; }
  /* match disallowed user (not in AllowUsers/AllowGroups or in DenyUsers/DenyGroups) on Linux Ubuntu/FreeBSD */
  /* "User tinydns from 1.2.3.4 not allowed because not listed in AllowUsers" */
 "User ".+" from "                                               { BEGIN(ssh_notallowed); return SSH_NOTALLOWEDPREF; }

Re: [SSHGuard-users] sshguard on trunk with debian

[jungle B. <jun...@gm...>]

On 12 December 2016 at 10:41, Kevin Zheng <kev...@gm...> wrote:
> On 12/11/2016 22:50, jungle boogie wrote:
>> Hi Kevin,
>> On 12/11/2016 08:49 PM, Kevin Zheng wrote:
>>> On 12/09/2016 09:24, jungle Boogie wrote:
>>>> Now knowing the services file is setup correct, what else should I
>>>> review to determine why sshguard is not blocking?
>>>
>>> Check /var/log/auth.log and see if there's any relevant information.
>
> You'll want to grep for 'sshguard'.
>

No instances found in /var/log/auth.log

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



-- 
-------
inum: 883510009027723
sip: jun...@si...

Re: [SSHGuard-users] sshguard on trunk with debian

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

On 12/11/2016 22:50, jungle boogie wrote:
> Hi Kevin,
> On 12/11/2016 08:49 PM, Kevin Zheng wrote:
>> On 12/09/2016 09:24, jungle Boogie wrote:
>>> Now knowing the services file is setup correct, what else should I
>>> review to determine why sshguard is not blocking?
>>
>> Check /var/log/auth.log and see if there's any relevant information.

You'll want to grep for 'sshguard'.

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

Re: [SSHGuard-users] sshguard on trunk with debian

[jungle b. <jun...@gm...>]

Hi Kevin,
On 12/11/2016 08:49 PM, Kevin Zheng wrote:
> On 12/09/2016 09:24, jungle Boogie wrote:
>> Now knowing the services file is setup correct, what else should I
>> review to determine why sshguard is not blocking?
>
> Check /var/log/auth.log and see if there's any relevant information.
>

last few lines:
Dec 12 06:29:13 pine64 sshd[3030]: Failed password for root from 
116.31.116.48 port 49298 ssh2
Dec 12 06:29:13 pine64 sshd[3030]: Failed password for root from 
116.31.116.48 port 49298 ssh2
Dec 12 06:29:13 pine64 sshd[3032]: Failed password for root from 
116.31.116.48 port 51596 ssh2
Dec 12 06:29:13 pine64 sshd[3028]: Failed password for root from 
116.31.116.48 port 44698 ssh2
Dec 12 06:29:13 pine64 sshd[3030]: Failed password for root from 
116.31.116.48 port 49298 ssh2
Dec 12 06:29:13 pine64 sshd[3032]: Failed password for root from 
116.31.116.48 port 51596 ssh2
Dec 12 06:29:13 pine64 sshd[3028]: Failed password for root from 
116.31.116.48 port 44698 ssh2
Dec 12 06:29:13 pine64 sshd[3030]: Received disconnect from 
116.31.116.48 port 49298:11:  [preauth]
Dec 12 06:29:13 pine64 sshd[3030]: Disconnected from 116.31.116.48 port 
49298 [preauth]
Dec 12 06:29:13 pine64 sshd[3032]: Failed password for root from 
116.31.116.48 port 51596 ssh2
Dec 12 06:29:13 pine64 sshd[3028]: Failed password for root from 
116.31.116.48 port 44698 ssh2
Dec 12 06:29:14 pine64 sshd[3032]: Received disconnect from 
116.31.116.48 port 51596:11:  [preauth]
Dec 12 06:29:14 pine64 sshd[3032]: Disconnected from 116.31.116.48 port 
51596 [preauth]
Dec 12 06:29:14 pine64 sshd[3028]: Received disconnect from 
116.31.116.48 port 44698:11:  [preauth]
Dec 12 06:29:14 pine64 sshd[3028]: Disconnected from 116.31.116.48 port 
44698 [preauth]
Dec 12 06:29:14 pine64 sshd[3039]: ssh_dispatch_run_fatal: Connection 
from 116.31.116.48 port 22647: Connection refused [preauth]
Dec 12 06:29:14 pine64 sshd[3034]: ssh_dispatch_run_fatal: Connection 
from 116.31.116.48 port 17455: Connection refused [preauth]


my ssh info:
~$ ssh -V
OpenSSH_7.3p1, OpenSSL 1.0.1t  3 May 2016


> Best,
> Kevin
>

Re: [SSHGuard-users] Exiting on signal

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

On 12/08/2016 23:26, Per olof Ljungmark wrote:
> FreeBSD 10.3-STABLE #0 r306514M
> sshguard-pf 1.7.0_1
> 
> Got:
> 
> Dec  1 02:00:00 <auth.info> terrapin sshguard[28682]: Discarding partial
> log entry 'ec  1 02:00:58 <mail.i': source 3356613732 cannot starve the
> others.
> Dec  1 02:00:00 <auth.err> terrapin sshguard[28682]: Unable to read any
> more log entries
> Dec  1 02:00:00 <auth.info> terrapin sshguard[28682]: Exiting on signal
> 
> It looks like sshguard stumbled when a logfile for vsftpd was rotated at
> 02:00am. The log in question is gone so apparently som kind of clash
> happened.
> 
> vsftpd is running in a FreeBSD jail, sshguard on the host.
> 
> Any guesses  why this happened?

The old log monitor ('LogSuck') is kind of fragile. You should pipe logs
to sshguard using sshg-logmon instead.

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

Re: [SSHGuard-users] sshguard on trunk with debian

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

On 12/09/2016 09:24, jungle Boogie wrote:
> Now knowing the services file is setup correct, what else should I
> review to determine why sshguard is not blocking?

Check /var/log/auth.log and see if there's any relevant information.

Best,
Kevin

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

Re: [SSHGuard-users] sshguard on trunk with debian

[jungle B. <jun...@gm...>]

On 8 December 2016 at 16:18, Daniel Aleksandersen <co...@da...> wrote:
> On Thu, Dec 8, 2016, at 19:12, jungle Boogie wrote:
>> Hi All,
>>
>> First, I don't know how to determine the version of sshguard I'm
>> currently running, but I compiled it from master on the 5th. So it's a
>> version from around that time.
>
> You’re running an experimental build from the master branch that hasn’t
> been released . So there is no version number to refer to other than the
> latest git commit hash of the master branch when you built it. December
> 5th? Then your version is master/ff69989.

Gotcha. Thanks for the info.

>
>> It looks like this latest version now includes a config file:
>> https://bitbucket.org/sshguard/sshguard/src/1fcd467b78ea5a4ddcba6efb3920cea860839e31/examples/sshguard.conf.sample?at=master&fileviewer=file-view-default
>>
>> and a service file:
>> https://bitbucket.org/sshguard/sshguard/src/1fcd467b78ea5a4ddcba6efb3920cea860839e31/examples/sshguard.service?at=master&fileviewer=file-view-default
>
> You should set your configuration in the config file instead of in the
> service file. I’ve removed the switches from the example service file to
> encourage people to use the configuration file instead. (Making changes
> to the service file shouldn’t be necessary for anyone but distribution
> package maintainers.)
> https://bitbucket.org/sshguard/sshguard/pull-requests/17

Okay, I modified the file /etc/systemd/system/sshguard.service:

[Service]
ExecStartPre=-/sbin/iptables -N sshguard
ExecStart=/usr/local/sbin/sshguard
Restart=always

>
>> I have the service running and it's using that file:
>>  1324 ?        Ss     0:00 /bin/sh /usr/local/sbin/sshguard -w
>> /etc/sshguard.whitelist -l /var/log/auth.log -b
>> 60:/var/db/sshguard/blacklist.db
>>  1325 ?        S      0:00 /bin/sh /usr/local/sbin/sshguard -w
>> /etc/sshguard.whitelist -l /var/log/auth.log -b
>> 60:/var/db/sshguard/blacklist.db
>>
>> (don't quite know why I have two running instances)
>
> How did you start it? and under which distro?

sudo service sshguard start:
 1902 ?        Ss     0:00 /bin/sh /usr/local/sbin/sshguard
 1903 ?        S      0:00 /bin/sh /usr/local/sbin/sshguard

>
>> However, it's not actively blocking traffic and the /var/db/sshguard
>> directory doesn't exist.
>
> That would be because the -l option doesn’t exist. At least, I’ve never
> seen it before and I can’t find it anywhere but in the example service
> file. You should add the log files you want to monitor to the FILES
> option in the configuration file. Move the other options there too, it
> should be easier to maintain that way.

/usr/local/etc/sshguard.conf contains these:
BACKEND="/sbin/iptables"
BLACKLIST_FILE=/var/lib/sshguard/enemies
BLACKLIST_THRESHOLD=30
FILES="/var/log/auth.log"

running 3.10.102-2-pine64-longsleep
This is on a pine64 SoC:
https://www.pine64.org/?product=pine-a64-board-2gb


>
>> iptables:
>> -P INPUT ACCEPT
>> -P FORWARD ACCEPT
>> -P OUTPUT ACCEPT
>> -N sshguard
>> -A INPUT -p tcp -m tcp --dport 22 -j sshguard
>>
>>
>> Any suggestions on what I should do to have sshugard read the
>> /var/log/auth.log and start blocking?
>
> I do believe the issue is that SSHGuard isn’t monitoring any log files
> because of the aforementioned configuration issue.

Now knowing the services file is setup correct, what else should I
review to determine why sshguard is not blocking?


> --
> Daniel Aleksandersen
> https://www.slightfuture.com/

[SSHGuard-users] Exiting on signal

[Per o. L. <pe...@ne...>]

FreeBSD 10.3-STABLE #0 r306514M
sshguard-pf 1.7.0_1

Got:

Dec  1 02:00:00 <auth.info> terrapin sshguard[28682]: Discarding partial
log entry 'ec  1 02:00:58 <mail.i': source 3356613732 cannot starve the
others.
Dec  1 02:00:00 <auth.err> terrapin sshguard[28682]: Unable to read any
more log entries
Dec  1 02:00:00 <auth.info> terrapin sshguard[28682]: Exiting on signal

It looks like sshguard stumbled when a logfile for vsftpd was rotated at
02:00am. The log in question is gone so apparently som kind of clash
happened.

vsftpd is running in a FreeBSD jail, sshguard on the host.

Any guesses  why this happened?

Thank you,

//per