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

[SSHGuard-users] sshguard fails to read and understand log?

[Reshey L. <re...@gm...>]

I have tried with 3x OpenBSD pc, to get sshguard working.
I have manage to get bruteforce table to work with pf.conf and see
blocked ip with pfctl -T show - bruteforce
No result with pfctl -T show sshguard
Only time I got result with pfctl -T show sshguard was wile haveing one
xterm with sshguard in debuge mode and feed it attack signature from
sshguard.org website example list, and before closing sshguard debuge mode
running in another xterm pfctl cmd.

I have via OpenBSD irc channel at freenode heard a other using reporting
just installing, copying the table into pf.conf, and update with pfctl,
and rcctl enable sshguard, and rcctl start sshguard.

While running sshguard in debuge mode it got clear to me, It does manage to
read /var/log/authlog ... but I have problem with the content of authlog..
could this be something related to locals? These pc was setup during install
with "no" norwegian keyboard, OpenBSD 6.0.


env SSHGUARD_DEBUG=foo /usr/local/sbin/sshguard -l /var/log/authlog

I then hammered ssh from putty on a windows pc, until this happend in the
debug window
:

Stack now 0
Cleanup: discarding lookahead token WORD ()
Stack now 0
Checking to refresh sources...
Refreshing sources showed 0 changes.
Start polling.
Searching for fd 4 in list.
Starting parse
Entering state 0
Reading a token: --accepting rule at line 116 ("Jan 22 21:26:39 skylake
su:")
Next token is token SYSLOG_BANNER ()
Shifting token SYSLOG_BANNER ()
Entering state 3
Reading a token: --accepting rule at line 221 (" ")
--accepting rule at line 220 ("xxxxx")
Next token is token WORD ()
Error: popping token SYSLOG_BANNER ()
Stack now 0
Cleanup: discarding lookahead token WORD ()
Stack now 0
Checking to refresh sources...
Refreshing sources showed 0 changes.
Start polling.

[SSHGuard-users] Auth error ignored by sshguard

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

From FreeBsd auth.log:
----------------------------------
Jan 22 04:16:13 theranch sshd[48754]: fatal: Unable to negotiate with
198.50.142.115 port 57860: no matching key exchange method found. Their
offer: diffie-hellman-group1-sha1 [pre auth]
---------------------
I suppose this is an odd case for an ssh login attempt, but I figured
I'd post it for what it is worth. Sshguard didn't block the IP. Now I
suppose you can say if the key exchange method isn't supported, they
will never get it, but it seems to me that could leave the system open
to some exploit.

I'm still on rev 1.7. 

IP is  OVH. Oh, I'm shocked. ;-)

Re: [SSHGuard-users] Issue restarting sshguard

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

I will upgrade to 2.0 tonight. 

My question was more like why do MY ipfw tables get flushed upon booting while table 22 doesn't. 

A different question and not exactly on sshguard target. ;-)


  Original Message  
From: Kevin Zheng
Sent: Thursday, January 19, 2017 6:10 PM
To: ssh...@li...
Subject: Re: [SSHGuard-users] Issue restarting sshguard

On 01/18/17 15:27, Burton Strauss wrote:
> fw_flush is in finisher() which is called at the end of the program via atexit().
>
> IF it is called,
>
> static void finishup(void) {
> sshguard_log(LOG_INFO, "Exiting on %s",
> exit_sig == SIGHUP ? "SIGHUP" : "signal");
>
> if (fw_flush() != FWALL_OK) {
> sshguard_log(LOG_ERR, "fw: failed to flush blocked addresses");
> }
>
> So you would see the log message and then if the flush failed the 2nd
> message. I'm not seeing it. Next step would be to instrument the
> called code and log the call to the script and the chain at the end.

Here's my guess without looking at history and code:

If I remember correctly on 1.7.1 fw_flush() always returns FWALL_OK. 
fw_flush() sends "flush" over a pipe to sshg-fw.

If the pipe gets broken first, then flush will never happen.

2.0 fixes this by issuing "flushonexit" to sshg-fw, so that whenever 
sshg-fw exits flush is issued no matter if the pipe goes down first.

Fix is to upgrade to 2.0 or backport this.

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] Issue restarting sshguard

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

On 01/18/17 15:27, Burton Strauss wrote:
> fw_flush is in finisher() which is called at the end of the program via atexit().
>
> IF it is called,
>
> static void finishup(void) {
>     sshguard_log(LOG_INFO, "Exiting on %s",
>             exit_sig == SIGHUP ? "SIGHUP" : "signal");
>
>     if (fw_flush() != FWALL_OK) {
>         sshguard_log(LOG_ERR, "fw: failed to flush blocked addresses");
>     }
>
> So you would see the log message and then if the flush failed the 2nd
> message. I'm not seeing it. Next step would be to instrument the
> called code and log the call to the script and the chain at the end.

Here's my guess without looking at history and code:

If I remember correctly on 1.7.1 fw_flush() always returns FWALL_OK. 
fw_flush() sends "flush" over a pipe to sshg-fw.

If the pipe gets broken first, then flush will never happen.

2.0 fixes this by issuing "flushonexit" to sshg-fw, so that whenever 
sshg-fw exits flush is issued no matter if the pipe goes down first.

Fix is to upgrade to 2.0 or backport this.

Best,
Kevin

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

Re: [SSHGuard-users] Issue restarting sshguard

[Burton S. <Bu...@Bu...>]

When you run ./configure it creates sshg-fw.sh from the skeleton and whichever fw type you picked. Look in src/fwalls for the scripts.

If my iptables setup isn't having flush called, it's likely your's isn't either. Have to look in the sshguard.c source for the call to flush to see what conditions bypass it.

OK...

fw_flush is in finisher() which is called at the end of the program via atexit().

IF it is called, 

static void finishup(void) {
    sshguard_log(LOG_INFO, "Exiting on %s",
            exit_sig == SIGHUP ? "SIGHUP" : "signal");

    if (fw_flush() != FWALL_OK) {
        sshguard_log(LOG_ERR, "fw: failed to flush blocked addresses");
    }

So you would see the log message and then if the flush failed the 2nd message. I'm not seeing it. Next step would be to instrument the called code and log the call to the script and the chain at the end.




-----Burton

-----Original Message-----
From: li...@la... [mailto:li...@la...] 
Sent: Wednesday, January 18, 2017 2:39 PM
To: Kevin Zheng <kev...@gm...>; BSt...@ac...; ssh...@li...
Subject: Re: [SSHGuard-users] Issue restarting sshguard

A funny thing about sshguard on FreeBSD IPFW is table 22 isn't flushed ever as far as I can tell. When I do a reboot, the table is still there. In fact, I'd like to know how that is done. The tables I create with scripts need to be created after booting.

I'm still on 1.7. ‎I had done some program updates a few days ago and made the VPS lose networking, though it was working after the updates. I only discovered the issue after booting after a backup. A good thing I had two images!

  Original Message
From: Kevin Zheng
Sent: Wednesday, January 18, 2017 10:30 AM
To: BSt...@ac...; ssh...@li...
Subject: Re: [SSHGuard-users] Issue restarting sshguard

On 01/18/17 03:45, Burton Strauss wrote:
> If sshguard shuts down other than cleanly, and you restart it, the 
> blocklist rules get doubled.
>
> Does it hurt anything to add a flush command first? For iptables it 
> would be:

In 1.7, if SSHGuard exits cleanly it should issue a 'flush' command before exiting. In 2.0, sshg-blocker sets 'flushonexit' and sshg-fw flushes before exiting.

What version are you using? What backend are you using? If you're able to, does 2.0 fix your issue?

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] Issue restarting sshguard

[Burton S. <Bu...@Bu...>]

1.7.1 + a couple of patches
iptables
No, I can't spare the effort to switch to 1.99.x now.

I'm using systemd and systemctl stop sshguard.service or restart. And I'm
not seeing the flush command being executed.

It may be belt & suspenders, but I can't see the harm in flushing the chain
regardless.

Ultimately I want to create an sshguard and sshguard-perm chain so I can
have the perm blocks just dumped before the Shorewall even logs them. The
patch is working, but it will be cleaner to arrange the chains that way just
so sshguard doesn't see the already blocked addresses in SYN log and whine.

-----Burton

-----Original Message-----
From: Kevin Zheng [mailto:kev...@gm...] 
Sent: Wednesday, January 18, 2017 1:30 PM
To: BSt...@ac...; ssh...@li...
Subject: Re: [SSHGuard-users] Issue restarting sshguard

On 01/18/17 03:45, Burton Strauss wrote:
> If sshguard shuts down other than cleanly, and you restart it, the 
> blocklist rules get doubled.
>
> Does it hurt anything to add a flush command first? For iptables it 
> would be:

In 1.7, if SSHGuard exits cleanly it should issue a 'flush' command before
exiting. In 2.0, sshg-blocker sets 'flushonexit' and sshg-fw flushes before
exiting.

What version are you using? What backend are you using? If you're able to,
does 2.0 fix your issue?

Best,
Kevin

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

Re: [SSHGuard-users] Issue restarting sshguard

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

A funny thing about sshguard on FreeBSD IPFW is table 22 isn't flushed ever as far as I can tell. When I do a reboot, the table is still there. In fact, I'd like to know how that is done. The tables I create with scripts need to be created after booting.

I'm still on 1.7. ‎I had done some program updates a few days ago and made the VPS lose networking, though it was working after the updates. I only discovered the issue after booting after a backup. A good thing I had two images!

  Original Message  
From: Kevin Zheng
Sent: Wednesday, January 18, 2017 10:30 AM
To: BSt...@ac...; ssh...@li...
Subject: Re: [SSHGuard-users] Issue restarting sshguard

On 01/18/17 03:45, Burton Strauss wrote:
> If sshguard shuts down other than cleanly, and you restart it, the
> blocklist rules get doubled.
>
> Does it hurt anything to add a flush command first? For iptables it
> would be:

In 1.7, if SSHGuard exits cleanly it should issue a 'flush' command 
before exiting. In 2.0, sshg-blocker sets 'flushonexit' and sshg-fw 
flushes before exiting.

What version are you using? What backend are you using? If you're able 
to, does 2.0 fix your issue?

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] Issue restarting sshguard

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

On 01/18/17 03:45, Burton Strauss wrote:
> If sshguard shuts down other than cleanly, and you restart it, the
> blocklist rules get doubled.
>
> Does it hurt anything to add a flush command first? For iptables it
> would be:

In 1.7, if SSHGuard exits cleanly it should issue a 'flush' command 
before exiting. In 2.0, sshg-blocker sets 'flushonexit' and sshg-fw 
flushes before exiting.

What version are you using? What backend are you using? If you're able 
to, does 2.0 fix your issue?

Best,
Kevin

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

[SSHGuard-users] Issue restarting sshguard

[Burton S. <Bu...@Bu...>]

If sshguard shuts down other than cleanly, and you restart it, the blocklist
rules get doubled.

 

Does it hurt anything to add a flush command first? For iptables it would
be:

 

 

fw_init() {

    run_iptables "-Z sshguard"

    run_iptables "-L -n"

}

 

 

-----Burton

 

Re: [SSHGuard-users] BLACKLIST_FILE (Kevin Zheng)

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

On 01/17/17 18:24, Doug Niven wrote:
> That’d be awesome! I’m sure others would also be very happy about
> this addition!

Good idea. It's issue #59 so hopefully nobody forgets about it:

https://bitbucket.org/sshguard/sshguard/issues/59/log-output-to-file

Best,
Kevin

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

Re: [SSHGuard-users] BLACKLIST_FILE (Kevin Zheng)

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

Hi Kevin,

> Please let me know what flag I need to startup the daemon so that it
> has its own log file (which is one reason we like Fail2ban).

> It currently doesn't do that, but I think it's nice to be able to 
> configure logging output. If you'd like I'll add a config file option 
> that logs to a file.

That’d be awesome! I’m sure others would also be very happy about this addition!

Best, Doug

Re: [SSHGuard-users] sshguard-users Digest, Vol 74, Issue 3

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

On 01/16/17 11:18, Doug Niven wrote:
> Hi Kevin,
>
> You mention SSHGuard’s “own log messages” but I don’t see any mention
> of that on the man page or reference to it in the sshguard.conf
> file.

SSHGuard currently logs to syslog with facility 'auth'.

> Please let me know what flag I need to startup the daemon so that it
> has its own log file (which is one reason we like Fail2ban).

It currently doesn't do that, but I think it's nice to be able to 
configure logging output. If you'd like I'll add a config file option 
that logs to a file.

Best,
Kevin

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

Re: [SSHGuard-users] sshguard-users Digest, Vol 74, Issue 3

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

Hi Kevin,

You mention SSHGuard’s “own log messages” but I don’t see any mention of that on the man page or reference to it in the sshguard.conf file.

Please let me know what flag I need to startup the daemon so that it has its own log file (which is one reason we like Fail2ban).

Cheers, Doug


> On Jan 9, 2017, at 10:08 PM, ssh...@li... wrote:
> 
> Message: 2
> Date: Sun, 8 Jan 2017 12:59:36 -0600
> From: Kevin Zheng <kev...@gm...>
> Subject: Re: [SSHGuard-users] BLACKLIST_FILE
> To: ssh...@li...
> Message-ID: <f24...@gm...>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> On 01/06/17 20:55, Doug Niven wrote:
>> Thanks for your help getting SSHGuard working for me last weekend in
>> MacOS Sierra, it?s working well.
> 
> Glad to hear.
> 
>> 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.
> 
> I'm not sure what's going on here. If you look at SSHGuard's own log 
> messages, do you ever see 'blocking [address] forever'?
> 
>> Also: if I manually add an IP or range to the blacklist, will this
>> also be sent to PF somehow?
> 
> No. SSHGuard will only read the blacklist file when you restart it. It 
> blocks everything in the blacklist at startup.
> 
> Best,
> Kevin

[SSHGuard-users] PATCH: New heart beat facility (minimally effective)

[Burton S. <Bu...@Bu...>]

Allow me to offer a 'heart beat' patch for sshguard 1.7.1. It's not a great
heart beat, as I did not want to add any overhead such as a timer. It's
basically three counters that are checked when a message is received from
the logging facility. Thus it's quite possible on a lightly attacked system
for far longer periods to go past than the nominal seconds counter.

 

./configure --prefix= --with-firewall= --with-heartbeat=level

 

Levels are none, debug (heartbeats all attacks) and small, medium and large
- which attempt to provide a reasonable frequency of messages based on the
volume of the sshguard process. For example, large logs every 600 seconds
and/or 1,000,000 log lines and/or 1,000 attacks. Small is 180 seconds, 1,000
log lines and/or 100 attacks.

 

If you build it with --with-heartbeat=none (or no parameter), the code is
#IFDEFed out. If you build in a heartbeat, you need to enable it at runtime
with the env SSHGUARD_HEARTBEAT=fu trick just like debug.

 

The messages look like this in the log:

 

Jan 15 18:02:06 wiseowl sshguard[12091]: sshguard <3beat active 3420 seconds
(166 read, 70 attacks)

 

Recommend the typical autoreconf -i  first and then the ./configure. When
you do make, since I'm changing the lexer and parser, those both take a
while during the compiles.

 

Enjoy!

 

 

-----Burton

 

Burton Strauss III, PMP

eMail: Bu...@Bu... <mailto:Bu...@Bu...>  or
BSt...@ac... <mailto:BSt...@ac...> 

LinkedIn: http://www.linkedin.com/in/BurtonStrauss

 

 

 

 

--- /home/burton/sshguard-1.7.1/configure.ac    2016-10-11
11:24:19.000000000 -0500

+++ /home/burton/sshguard-1.7.1bs/configure.ac  2017-01-15
11:25:13.459065430 -0600

@@ -46,6 +46,45 @@

             [hostsfilepath=$withval],

             [hostsfilepath=/etc/hosts.allow])

 

+AC_ARG_WITH([heartbeat], [AS_HELP_STRING([--with-heartbeat=setting],

+            [Enable heartbeat (none, small, medium or large system, default
is none)])],

+[

+ # Substitute the correct commands into the firewall script.

+ case "$withval" in

+     none)

+        heartbeatsetting=none

+        ;;

+     debug)

+        heartbeatsetting=debug

+       heartbeatseconds=60

+       heartbeatloglines=100

+       heartbeatattacks=1

+        ;;

+     small)

+        heartbeatsetting=small

+       heartbeatseconds=180

+       heartbeatloglines=1000

+       heartbeatattacks=100

+        ;;

+     medium)

+        heartbeatsetting=medium

+       heartbeatseconds=300

+       heartbeatloglines=100000

+       heartbeatattacks=500

+        ;;

+     large)

+        heartbeatsetting=large

+       heartbeatseconds=600

+       heartbeatloglines=1000000

+       heartbeatattacks=1000

+        ;;

+     *)

+        AC_MSG_ERROR([Invalid heartbeat value (see help)])

+        ;;

+    esac

+],

+            [heartbeatsetting=none])

+

############################################################################
##

AS_BOX([Program Checks])

 

@@ -77,4 +116,12 @@

 

AC_DEFINE_UNQUOTED(HOSTSFILE_PATH, "$hostsfilepath", [Path to hosts.allow])

 

+if test "x$heartbeatsetting" != xnone; then

+  AC_DEFINE_UNQUOTED(HEARTBEAT_TYPE, "${heartbeatsetting}", [Setting of
heartbeat])

+  AC_DEFINE_UNQUOTED(HEARTBEAT, "<3beat", [heartbeat search flag in log])

+  AC_DEFINE_UNQUOTED(HEARTBEAT_SECONDS, ${heartbeatseconds}, [Number of
seconds between heartbeat loggings])

+  AC_DEFINE_UNQUOTED(HEARTBEAT_LOGLINES, ${heartbeatloglines}, [Number of
log lines (reads) between heartbeat loggings])

+  AC_DEFINE_UNQUOTED(HEARTBEAT_ATTACKS, ${heartbeatattacks}, [Number of
attacks between heartbeat loggings])

+fi

+

AC_OUTPUT([Makefile src/Makefile src/fwalls/sshg-fw])

--- /home/burton/sshguard-1.7.1/configure       2016-10-20
18:32:50.000000000 -0500

+++ /home/burton/sshguard-1.7.1bs/configure     2017-01-15
11:25:36.545880640 -0600

@@ -727,6 +727,7 @@

enable_silent_rules

with_firewall

with_hosts

+with_heartbeat

enable_dependency_tracking

'

       ac_precious_vars='build_alias

@@ -1368,6 +1369,9 @@

                           or null)

   --with-hosts=file       Path to allowed hosts file (default

                           /etc/hosts.allow)

+  --with-heartbeat=setting

+                          Enable heartbeat (none, small, medium or large

+                          system, default is none)

 

Some influential environment variables:

   CC          C compiler command

@@ -2800,6 +2804,49 @@

fi

 

 

+

+# Check whether --with-heartbeat was given.

+if test "${with_heartbeat+set}" = set; then :

+  withval=$with_heartbeat;

+ # Substitute the correct commands into the firewall script.

+ case "$withval" in

+     none)

+        heartbeatsetting=none

+        ;;

+     debug)

+        heartbeatsetting=debug

+       heartbeatseconds=60

+       heartbeatloglines=100

+       heartbeatattacks=1

+        ;;

+     small)

+        heartbeatsetting=small

+       heartbeatseconds=180

+       heartbeatloglines=1000

+       heartbeatattacks=100

+        ;;

+     medium)

+        heartbeatsetting=medium

+       heartbeatseconds=300

+       heartbeatloglines=100000

+       heartbeatattacks=500

+        ;;

+     large)

+        heartbeatsetting=large

+       heartbeatseconds=600

+       heartbeatloglines=1000000

+       heartbeatattacks=1000

+        ;;

+     *)

+        as_fn_error $? "Invalid heartbeat value (see help)" "$LINENO" 5

+        ;;

+    esac

+

+else

+  heartbeatsetting=none

+fi

+

+

############################################################################
##

$as_echo "## -------------- ##

## Program Checks ##

@@ -5161,6 +5208,34 @@

_ACEOF

 

 

+if test "x$heartbeatsetting" != xnone; then

+

+cat >>confdefs.h <<_ACEOF

+#define HEARTBEAT_TYPE "${heartbeatsetting}"

+_ACEOF

+

+

+cat >>confdefs.h <<_ACEOF

+#define HEARTBEAT "<3beat"

+_ACEOF

+

+

+cat >>confdefs.h <<_ACEOF

+#define HEARTBEAT_SECONDS ${heartbeatseconds}

+_ACEOF

+

+

+cat >>confdefs.h <<_ACEOF

+#define HEARTBEAT_LOGLINES ${heartbeatloglines}

+_ACEOF

+

+

+cat >>confdefs.h <<_ACEOF

+#define HEARTBEAT_ATTACKS ${heartbeatattacks}

+_ACEOF

+

+fi

+

ac_config_files="$ac_config_files Makefile src/Makefile src/fwalls/sshg-fw"

 

cat >confcache <<\_ACEOF

--- /home/burton/sshguard-1.7.1/src/sshguard.c  2016-10-11
11:22:37.000000000 -0500

+++ /home/burton/sshguard-1.7.1bs/src/sshguard.c        2017-01-15
16:52:00.000766396 -0600

@@ -27,6 +27,7 @@

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

+#include <sys/time.h>

 

#include "fwalls/fw.h"

#include "parser/parser.h"

@@ -41,6 +42,10 @@

 

#define MAX_LOGLINE_LEN     1000

 

+#ifdef HEARTBEAT

+int sshg_heartbeat = 0;

+#endif

+

/** Keep track of the exit signal received. */

static volatile sig_atomic_t exit_sig = 0;

 

@@ -120,12 +125,23 @@

     char buf[MAX_LOGLINE_LEN];

 

     int sshg_debugging = (getenv("SSHGUARD_DEBUG") != NULL);

+#ifdef HEARTBEAT

+    sshg_heartbeat = (getenv("SSHGUARD_HEARTBEAT") != NULL);

+#endif

     sshguard_log_init(sshg_debugging);

     yy_flex_debug = sshg_debugging;

     yydebug = sshg_debugging;

 

     srand(time(NULL));

 

+#ifdef HEARTBEAT

+    if (sshg_heartbeat)

+           sshguard_log(LOG_INFO, "sshguard version %s (%ss are %d seconds,
%d loglines and %d attack(s))",

+                       PACKAGE_VERSION, HEARTBEAT, HEARTBEAT_SECONDS,
HEARTBEAT_LOGLINES, HEARTBEAT_ATTACKS);

+    else

+#endif

+           sshguard_log(LOG_INFO, "sshguard version %s", PACKAGE_VERSION);

+

     /* pending, blocked, and offender address lists */

     list_init(&limbo);

     list_attributes_seeker(& limbo, attack_addr_seeker);

@@ -183,14 +199,46 @@

     sshguard_log(LOG_INFO, "Monitoring attacks from %s",

             opts.has_polled_files ? "log files" : "stdin");

 

+#ifdef HEARTBEAT

+    unsigned long read_count = 0, matched_count = 0, tv_delta, tv_delta_min
= 1;

+    struct timeval s_tv, e_tv;

+    if (sshg_heartbeat) {

+        gettimeofday(&s_tv, NULL);

+    }

+#endif

+

     while (log_getline(buf, &source_id) == 0) {

         attack_t parsed_attack;

 

+#ifdef HEARTBEAT

+        if (sshg_heartbeat) {

+           gettimeofday(&e_tv, NULL);

+           ++read_count;

+           tv_delta = e_tv.tv_sec - s_tv.tv_sec;

+           if ((tv_delta % HEARTBEAT_SECONDS == 0) && (tv_delta >
tv_delta_min)) {

+               sshguard_log(LOG_INFO, "sshguard %s active %u seconds (%u
read, %u attacks)",

+                   HEARTBEAT, tv_delta, read_count, matched_count);

+               tv_delta_min = ((tv_delta + HEARTBEAT_SECONDS) /
HEARTBEAT_SECONDS) * HEARTBEAT_SECONDS;

+           } else if(read_count % HEARTBEAT_LOGLINES == 0) {

+               sshguard_log(LOG_INFO, "sshguard %s read %u (%u attacks)",
HEARTBEAT, read_count, matched_count);

+           }

+       }

+#endif

+

         if (parse_line(source_id, buf, &parsed_attack) != 0) {

             // Skip lines that don't match any attack.

             continue;

         }

 

+#ifdef HEARTBEAT

+        if (sshg_heartbeat){

+            ++matched_count;

+  #if HEARTBEAT_ATTACKS > 1

+            if (matched_count % HEARTBEAT_ATTACKS == 0)

+               sshguard_log(LOG_INFO, "sshguard %s matched %u attacks",
HEARTBEAT, matched_count);

+  #endif

+       }

+#endif

         if (parsed_attack.source != 0 && procauth_isauthoritative(

                     parsed_attack.service, parsed_attack.source) == -1) {

             sshguard_log(LOG_NOTICE,

@@ -199,7 +247,13 @@

             continue;

         }

 

-        sshguard_log(LOG_DEBUG, "Attack from %s on service %d with danger
%u",

+        sshguard_log(

+#ifdef HEARTBEAT

+               sshg_heartbeat ? LOG_INFO : LOG_DEBUG,

+#else

+               LOG_DEBUG,

+#endif

+               "Attack from %s on service %d with danger %u",

                 parsed_attack.address.value, parsed_attack.service,

                 parsed_attack.dangerousness);

         report_address(parsed_attack);

@@ -376,7 +430,13 @@

         /* process hosts with finite pardon time */

         if (now - tmpel->whenlast > tmpel->pardontime) {

             /* pardon time passed, release block */

-            sshguard_log(LOG_DEBUG, "Unblocking %s after %lld secs",

+            sshguard_log(

+#ifdef HEARTBEAT

+               sshg_heartbeat ? LOG_INFO : LOG_DEBUG,

+#else

+               LOG_DEBUG,

+#endif

+                       "Unblocking %s after %lld secs",

                          tmpel->attack.address.value,

                          (long long)(now - tmpel->whenlast));

             ret = fw_release(&tmpel->attack);

--- /home/burton/sshguard-1.7.1/src/config.h.in 2016-10-20
18:32:50.000000000 -0500

+++ /home/burton/sshguard-1.7.1bs/src/config.h.in       2017-01-15
11:25:50.629303798 -0600

@@ -30,6 +30,21 @@

/* Define to 1 if you have the <unistd.h> header file. */

#undef HAVE_UNISTD_H

 

+/* heartbeat search flag in log */

+#undef HEARTBEAT

+

+/* Number of attacks between heartbeat loggings */

+#undef HEARTBEAT_ATTACKS

+

+/* Number of log lines (reads) between heartbeat loggings */

+#undef HEARTBEAT_LOGLINES

+

+/* Number of seconds between heartbeat loggings */

+#undef HEARTBEAT_SECONDS

+

+/* Setting of heartbeat */

+#undef HEARTBEAT_TYPE

+

/* Path to hosts.allow */

#undef HOSTSFILE_PATH

 

--- /home/burton/sshguard-1.7.1/doc/sshguard.8  2016-10-11
11:25:57.000000000 -0500

+++ /home/burton/sshguard-1.7.1bs/doc/sshguard.8        2017-01-15
16:58:59.350035144 -0600

@@ -80,6 +80,9 @@

.sp

Other features, attack signatures, and additional documentation can be found

at \fI\%http://www.sshguard.net/\fP\&.

+.sp

+Shorewall logs messages to facility 0 (kern) which must be included in
those

+being monitored by sshguard (auth and authpriv).

.SH OPTIONS

.INDENT 0.0

.TP

@@ -130,6 +133,8 @@

.TP

.B SSHGUARD_DEBUG

Enable additional debugging information.

+.B SSHGUARD_HEARTBEAT

+Enable heartbeat, also changes Attack and Unblock messages to log_info from
log_debug.

.UNINDENT

.SH WHITELISTING

.sp

--- /home/burton/sshguard-1.7.1/doc/sshguard.8.rst      2016-10-11
11:25:47.000000000 -0500

+++ /home/burton/sshguard-1.7.1bs/doc/sshguard.8.rst    2017-01-15
16:59:43.726977020 -0600

@@ -55,6 +55,9 @@

Other features, attack signatures, and additional documentation can be found

at http://www.sshguard.net/.

 

+Shorewall logs messages to facility 0 (kern) which must be included in
those

+being monitored by sshguard (auth and authpriv).

+

OPTIONS

=======

**-a** `thresh` (default 30)

@@ -104,6 +107,9 @@

SSHGUARD_DEBUG

     Enable additional debugging information.

 

+SSHGUARD_HEARTBEAT

+    Enable heartbeat logging, also changes Attack and Unblock messages to
log_info from log_debug.

+

WHITELISTING

============

**sshguard** supports address whitelisting. Whitelisted addresses are not

 

 

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

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

On 01/09/2017 07:57 PM, Kevin Zheng wrote:
> On 01/09/17 21:39, jungle boogie wrote:
>> I'm not a packages maintainer but I tested this out on an OpenBSD
>> machine I have.
>>
>> Aside from the known start up issues[0], I was able to install and use
>> sshguard without any issues.
>
> Glad to hear.
>
> I could only gather this from the mailing list:
>
> "It crashes when /etc/rc exits (with a blacklist db file),
> so it needs to be started after /etc/rc has finished."
>
> Any idea what's happening? It'd be nice to work it out before the next
> release :)
>

I don't know the cause, sadly. It seems users generally come up with 
their own solution and don't worry about it beyond that.


Here's it checking to see if sshguard is running, which eventually fails.

$ doas /etc/rc.d/sshguard check
+ daemon=/usr/local/sbin/sshguard
+ . /etc/rc.d/rc.subr
+ _rc_actions=start stop restart reload check
+ readonly _rc_actions
+ [ -n  ]
+ basename /etc/rc.d/sshguard
+ _name=sshguard
+ _rc_check_name sshguard
+ [ -n /usr/local/sbin/sshguard ]
+ unset _RC_DEBUG _RC_FORCE
+ getopts df c
+ shift 0
+ _RC_RUNDIR=/var/run/rc.d
+ _RC_RUNFILE=/var/run/rc.d/sshguard
+ _rc_do _rc_parse_conf
+ eval _rcflags=${sshguard_flags}
+ _rcflags=
+ eval _rcrtable=${sshguard_rtable}
+ _rcrtable=
+ eval _rcuser=${sshguard_user}
+ _rcuser=
+ eval _rctimeout=${sshguard_timeout}
+ _rctimeout=
+ getcap -f /etc/login.conf sshguard
+ > /dev/null
+ 2>&1
+ daemon_class=daemon
+ [ -z  ]
+ daemon_rtable=0
+ [ -z  ]
+ daemon_user=root
+ [ -z  ]
+ daemon_timeout=30
+ [ -n  -o check != start ]
+ [ X = XNO ]
+ [ -n  ]
+ [ -n  ]
+ [ -n  ]
+ [ -n  ]
+ [ -n  ]
+ readonly daemon_class
+ unset _rcflags _rcrtable _rcuser _rctimeout
+ pexp=/usr/local/sbin/sshguard
+ rcexec=su -l -c daemon -s /bin/sh root -c
+ [ 0 -eq 0 ]
+ rc_bg=YES
+ rc_reload=NO
+ rc_cmd check
sshguard(failed)

> Thanks,
> Kevin
>

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

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

On 01/09/17 21:39, jungle boogie wrote:
> I'm not a packages maintainer but I tested this out on an OpenBSD
> machine I have.
>
> Aside from the known start up issues[0], I was able to install and use
> sshguard without any issues.

Glad to hear.

I could only gather this from the mailing list:

"It crashes when /etc/rc exits (with a blacklist db file),
so it needs to be started after /etc/rc has finished."

Any idea what's happening? It'd be nice to work it out before the next 
release :)

Thanks,
Kevin

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

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

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

On 01/02/2017 02:19 PM, Kevin Zheng 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.
>
> 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].
>


I'm not a packages maintainer but I tested this out on an OpenBSD 
machine I have.

Aside from the known start up issues[0], I was able to install and use 
sshguard without any issues.


> Thanks,
> Kevin
>
> [1] https://sourceforge.net/projects/sshguard/files/sshguard/1.99.0/
>

Thanks,
jb

[0] http://marc.info/?l=openbsd-ports&m=148396223206682&w=2

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

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

On Mon, Jan 2, 2017, at 23:19, Kevin Zheng 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.
> 
> 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.

My Fedora 25 systems with a journalctl and firewalld setup seems quite
happy with everything, except the Ctrl+C error message I reported. That
issue is completely trivial, of course.

> The experimental code is available on SourceForge as 1.99.0 [1].
> 
> [1] https://sourceforge.net/projects/sshguard/files/sshguard/1.99.0/
-- 
Daniel Aleksandersen
https://daniel.priv.no/

Re: [SSHGuard-users] BLACKLIST_FILE

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

On 01/06/17 20:55, Doug Niven wrote:
> Thanks for your help getting SSHGuard working for me last weekend in
> MacOS Sierra, it’s working well.

Glad to hear.

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

I'm not sure what's going on here. If you look at SSHGuard's own log 
messages, do you ever see 'blocking [address] forever'?

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

No. SSHGuard will only read the blacklist file when you restart it. It 
blocks everything in the blacklist at startup.

Best,
Kevin

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

[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