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

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

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

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

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.

> 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

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

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

> 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.
-- 
Daniel Aleksandersen
https://www.slightfuture.com/

[SSHGuard-users] sshguard on trunk with debian

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

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.

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

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)

However, it's not actively blocking traffic and the /var/db/sshguard
directory doesn't exist.

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?

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

Re: [SSHGuard-users] "should have already been blocked"

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

On 4-12-2016 08:11, li...@la... wrote:
> On Sat, 3 Dec 2016 21:14:59 +0100
> Willem Jan Withagen <wj...@di...> wrote:
> 
>> On 3-12-2016 21:05, li...@la... wrote:
>>> I block 22 pretty early in the rc.firewall
>>> ${fwcmd} add  550 deny log all  from 'table(22)' to any dst-port 22
>>>
>>> A quick check to see if sshguard is working:
>>> # bzgrep -e "ipfw: 550 Deny TCP " security* | head -n 1
>>> security:Dec  3 20:00:01 theranch kernel: ipfw: 550 Deny TCP
>>> 116.31.116.4:25559 redacted:22 in via vtnet0
>>>
>>> and
>>>
>>> # ipfw table 22 list | grep "116.31.116.4"
>>> 116.31.116.4/32 0
>>> 116.31.116.41/32 0
>>> 116.31.116.43/32 0
>>> 116.31.116.47/32 0  
>>
>> 'ipfw show' should tell you if the rule is really working.
>> Like:
>>
>> 03500        371         22260 deny ip from table(22) to any
>>
>> If the first numbers are zero, then it does not get hit.
>>
>> --WjW
> 
> I'm not sure I understand your comment, but here is the relevant line
> from ipfw list:
> 00550 deny log ip from table(22) to any dst-port 22
> 
> Now  I don't block all ports because possible the hacker is on a
> hosting company with an email server.  I suppose I could add blocks for
> the browser, 587, and 143.

The difference was to use 'ipfw show' which gives you a first indication
if you firewall is ever being hit.
if the counters are 0, then one way or another you would have an error
in your firewall.

My firewall got hit 371 times.

--WjW

Re: [SSHGuard-users] "should have already been blocked"

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

On Sat, 3 Dec 2016 21:14:59 +0100
Willem Jan Withagen <wj...@di...> wrote:

> On 3-12-2016 21:05, li...@la... wrote:
> > I block 22 pretty early in the rc.firewall
> > ${fwcmd} add  550 deny log all  from 'table(22)' to any dst-port 22
> > 
> > A quick check to see if sshguard is working:
> > # bzgrep -e "ipfw: 550 Deny TCP " security* | head -n 1
> > security:Dec  3 20:00:01 theranch kernel: ipfw: 550 Deny TCP
> > 116.31.116.4:25559 redacted:22 in via vtnet0
> > 
> > and
> > 
> > # ipfw table 22 list | grep "116.31.116.4"
> > 116.31.116.4/32 0
> > 116.31.116.41/32 0
> > 116.31.116.43/32 0
> > 116.31.116.47/32 0  
> 
> 'ipfw show' should tell you if the rule is really working.
> Like:
> 
> 03500        371         22260 deny ip from table(22) to any
> 
> If the first numbers are zero, then it does not get hit.
> 
> --WjW

I'm not sure I understand your comment, but here is the relevant line
from ipfw list:
00550 deny log ip from table(22) to any dst-port 22

Now  I don't block all ports because possible the hacker is on a
hosting company with an email server.  I suppose I could add blocks for
the browser, 587, and 143.

> 
> 
> > 
> > 
> > 
> > On Sat, 3 Dec 2016 11:38:57 +0200
> > Petri Riihikallio <pet...@me...> wrote:
> >   
> >>> Cliff notes version:
> >>> -----------------
> >>> auth.log.2.bz2:Nov 19 23:07:13 theranch sshguard[803]: blacklist:
> >>> added 186.125.190.156 auth.log.2.bz2:Nov 19 23:07:13 theranch
> >>> sshguard[803]: 186.125.190.156: blocking forever (3 attacks in 2
> >>> secs, after 1 abuses over 2 secs) auth.log.2.bz2:Nov 19 23:07:13
> >>> theranch sshguard[803]: 186.125.190.156: should already have been
> >>> blocked ----------------    
> >>
> >> Have you run 
> >>   ipfw "add 55000 deny ip from table(22) to me”
> >> It should be in your startup scripts someplace. Without it SSHGuard
> >> works, but the collected IPs aren’t used anywhere.
> >>
> >> This baffled me first when I started using SSHGuard. The FreeBSD
> >> port doesn’t add that automatically, because it doesn’t want to
> >> mess your firewall setup. The rule number depends on your existing
> >> rules. 
> > 
> > 
> > ------------------------------------------------------------------------------
> > 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] "should have already been blocked"

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

On 3-12-2016 21:05, li...@la... wrote:
> I block 22 pretty early in the rc.firewall
> ${fwcmd} add  550 deny log all  from 'table(22)' to any dst-port 22
> 
> A quick check to see if sshguard is working:
> # bzgrep -e "ipfw: 550 Deny TCP " security* | head -n 1
> security:Dec  3 20:00:01 theranch kernel: ipfw: 550 Deny TCP 116.31.116.4:25559 redacted:22 in via vtnet0
> 
> and
> 
> # ipfw table 22 list | grep "116.31.116.4"
> 116.31.116.4/32 0
> 116.31.116.41/32 0
> 116.31.116.43/32 0
> 116.31.116.47/32 0

'ipfw show' should tell you if the rule is really working.
Like:

03500        371         22260 deny ip from table(22) to any

If the first numbers are zero, then it does not get hit.

--WjW


> 
> 
> 
> On Sat, 3 Dec 2016 11:38:57 +0200
> Petri Riihikallio <pet...@me...> wrote:
> 
>>> Cliff notes version:
>>> -----------------
>>> auth.log.2.bz2:Nov 19 23:07:13 theranch sshguard[803]: blacklist:
>>> added 186.125.190.156 auth.log.2.bz2:Nov 19 23:07:13 theranch
>>> sshguard[803]: 186.125.190.156: blocking forever (3 attacks in 2
>>> secs, after 1 abuses over 2 secs) auth.log.2.bz2:Nov 19 23:07:13
>>> theranch sshguard[803]: 186.125.190.156: should already have been
>>> blocked ----------------  
>>
>> Have you run 
>>   ipfw "add 55000 deny ip from table(22) to me”
>> It should be in your startup scripts someplace. Without it SSHGuard
>> works, but the collected IPs aren’t used anywhere.
>>
>> This baffled me first when I started using SSHGuard. The FreeBSD port
>> doesn’t add that automatically, because it doesn’t want to mess your
>> firewall setup. The rule number depends on your existing rules. 
>>
> 
> 
> ------------------------------------------------------------------------------
> 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] "should have already been blocked"

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

I just shut down that PC, but will double check later. However, the security log does show the rule blocking some IP, which I then verified is in the table 22.


  Original Message  
From: Willem Jan Withagen
Sent: Saturday, December 3, 2016 12:15 PM
To: li...@la...; Petri Riihikallio
Cc: ssh...@li...
Subject: Re: [SSHGuard-users] "should have already been blocked"

On 3-12-2016 21:05, li...@la... wrote:
> I block 22 pretty early in the rc.firewall
> ${fwcmd} add 550 deny log all from 'table(22)' to any dst-port 22
> 
> A quick check to see if sshguard is working:
> # bzgrep -e "ipfw: 550 Deny TCP " security* | head -n 1
> security:Dec 3 20:00:01 theranch kernel: ipfw: 550 Deny TCP 116.31.116.4:25559 redacted:22 in via vtnet0
> 
> and
> 
> # ipfw table 22 list | grep "116.31.116.4"
> 116.31.116.4/32 0
> 116.31.116.41/32 0
> 116.31.116.43/32 0
> 116.31.116.47/32 0

'ipfw show' should tell you if the rule is really working.
Like:

03500 371 22260 deny ip from table(22) to any

If the first numbers are zero, then it does not get hit.

--WjW


> 
> 
> 
> On Sat, 3 Dec 2016 11:38:57 +0200
> Petri Riihikallio <pet...@me...> wrote:
> 
>>> Cliff notes version:
>>> -----------------
>>> auth.log.2.bz2:Nov 19 23:07:13 theranch sshguard[803]: blacklist:
>>> added 186.125.190.156 auth.log.2.bz2:Nov 19 23:07:13 theranch
>>> sshguard[803]: 186.125.190.156: blocking forever (3 attacks in 2
>>> secs, after 1 abuses over 2 secs) auth.log.2.bz2:Nov 19 23:07:13
>>> theranch sshguard[803]: 186.125.190.156: should already have been
>>> blocked ---------------- 
>>
>> Have you run 
>> ipfw "add 55000 deny ip from table(22) to me”
>> It should be in your startup scripts someplace. Without it SSHGuard
>> works, but the collected IPs aren’t used anywhere.
>>
>> This baffled me first when I started using SSHGuard. The FreeBSD port
>> doesn’t add that automatically, because it doesn’t want to mess your
>> firewall setup. The rule number depends on your existing rules. 
>>
> 
> 
> ------------------------------------------------------------------------------
> 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
>