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

Re: [SSHGuard-users] FreeBSD still at rev 1.71

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

On 01/23/2017 06:28 PM, li...@la... wrote:
> I just did a portsnap to double check. Rev 2 isn't in ports. I use
> sshguard-ipfw.
>

Makes sense. 2.0 is not released yet:
https://bitbucket.org/sshguard/sshguard/downloads?tab=tags

Re: [SSHGuard-users] FreeBSD still at rev 1.71

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

On 01/23/17 18:28, li...@la... wrote:
> I just did a portsnap to double check. Rev 2 isn't in ports. I use
> sshguard-ipfw.

2.0.0 hasn't been released yet. Blocking on a pull request and keeping 
the configuration file format.

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

[SSHGuard-users] FreeBSD still at rev 1.71

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

I just did a portsnap to double check. Rev 2 isn't in ports. I use
sshguard-ipfw.

Re: [SSHGuard-users] Auth error ignored by sshguard

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

Ha, I am the only legitimate client. ;-) Besides, if I don't support the standard, nothing will get through. I caught some OVH VPS hammering my email server with an outmoded crypto, which was related to poodle and/or heartbleed.
http://disablessl3.com/
‎
SHA1 is out of favor these days. Commercially they won't issue certs with SHA1.
http://arstechnica.com/security/2016/05/microsoft-to-retire-support-for-sha1-certificates-in-the-next-4-months/

One of those Chinese certs was "illegally" (as if certs have any legal standing) issuing SHA1 certs. WoSign I think.

My philosophy is if someone is doing goofy stuff, block them. Today you can repel them, but tomorrow there may be a zero day. In any event, these clowns can flood a service. 

I've been reluctant to use the ipfw table 22 the sshguard generates for anything other than port 22, but I think I will add Web and email rules. Just not port 25 because that would probably block some legitimate email. 

‎I have a number of blocks on email other than port 25, and some days block 30 or so IP addresses trying to hack the ports. I traced one supposed hacker to a (cough cough) research team claiming to be doing a survey on email ports. They provided CIDRs, so I guess they were really doing research.‎ On the other hand, the University of Michigan attempts to  mess with my imap on a daily basis, and attempts to contact them via email go nowhere. Obviously they get firewall blocked now except on 25.


  Original Message  
From: Daniel Aleksandersen
Sent: Sunday, January 22, 2017 1:55 PM
To: ssh...@li...
Subject: Re: [SSHGuard-users] Auth error ignored by sshguard

On Sun, Jan 22, 2017, at 11:53, li...@la... wrote:
> >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.

Hm. Wouldn’t that potentially block some legitimate clients that are
trying to negotiate a connection?

> I'm still on rev 1.7. 
> 
> IP is OVH. Oh, I'm shocked. ;-)
-- 
Daniel Aleksandersen

------------------------------------------------------------------------------
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] Auth error ignored by sshguard

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

On Sun, Jan 22, 2017, at 11:53, li...@la... wrote:
> >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.

Hm. Wouldn’t that potentially block some legitimate clients that are
trying to negotiate a connection?

> I'm still on rev 1.7. 
> 
> IP is  OVH. Oh, I'm shocked. ;-)
-- 
Daniel Aleksandersen

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

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

On Sun, Jan 22, 2017, at 21:52, Reshey L. wrote:
> 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.


Could you please provide a log sample?



SSHGuard has no problem with my Norwegian locale under Linux, but I’m
using the 2.0 development branc. Could you please test your setup
against the current master branch? You can obtain the source and install
instructions from:
https://bitbucket.org/sshguard/sshguard/src



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

>
-- 

Daniel Aleksandersen

[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