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

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

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

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



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

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

[Jim S. <jse...@Li...>]

I'm getting the same thing on my Linux hosts.

$ cat /etc/issue
Ubuntu 14.04.5 LTS
$ sshguard -v
sshguard 1.7.0

Example from /var/log/auth.log:
Dec  2 01:35:31 mail sshguard[1222]: 1.55.63.241: blocking for 840 secs (4 attacks in 0 secs, after 1 abuses over 0 secs)
Dec  2 01:35:31 mail sshguard[1222]: 1.55.63.241: should already have been blocked
Dec  2 01:50:59 mail sshguard[1222]: 1.55.63.241: unblocking after 928 secs
Dec  2 02:00:50 mail sshguard[1222]: 1.55.63.241: blocking for 1680 secs (4 attacks in 0 secs, after 2 abuses over 1519 secs)
Dec  2 02:00:50 mail sshguard[1222]: 1.55.63.241: should already have been blocked
Dec  2 02:28:51 mail sshguard[1222]: 1.55.63.241: unblocking after 1681 secs
Dec  2 02:50:39 mail sshguard[1222]: 1.55.63.241: blocking for 3360 secs (4 attacks in 0 secs, after 3 abuses over 4508 secs)
Dec  2 02:50:39 mail sshguard[1222]: 1.55.63.241: should already have been blocked
Dec  2 03:46:48 mail sshguard[1222]: 1.55.63.241: unblocking after 3369 secs
Dec  2 07:56:07 mail sshguard[1222]: 1.55.63.241: blocking for 6720 secs (4 attacks in 0 secs, after 4 abuses over 22836 secs)
Dec  2 07:56:07 mail sshguard[1222]: 1.55.63.241: should already have been blocked
Dec  2 07:56:07 mail sshguard[1222]: message repeated 2 times: [ 1.55.63.241: should already have been blocked]
Dec  2 09:50:03 mail sshguard[1222]: 1.55.63.241: unblocking after 6836 secs

That was from yesterday.

Here's the current iptables state:

$ sudo iptables -L 
[sudo] password for <elided>: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
sshguard   all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain sshguard (1 references)
target     prot opt source               destination         
DROP       all  --  187-92-160-77.customer.tdatabrasil.net.br  anywhere         


Never used to see this until I replaced the repo version with one I
built from a tarball to get proper Postfix parsing.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.

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

[Petri R. <pet...@me...>]

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

-- 
Cheers
Petri
GSM +358 400 505 939

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

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

Houston...do we have a problem? Using sshguard with ipfw. Details
follow.

uname -a
FreeBSD theranch 10.3-RELEASE-p11 FreeBSD 10.3-RELEASE-p11 #0: Mon Oct 24 18:49:24 UTC 2016     ro...@am...:/usr/obj/usr/src/sys/GENERIC  amd64

# sshguard -v
sshguard 1.7.0

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

Here is what I could grep out of the auth.logs that were saved:
http://pastebin.com/yhcHCV4r

Here are the 186.125ers in the ipfw table:

# ipfw table 22 list | grep "186.125*"
186.125.190.156/32 0

So yeah, it is blocked, but then why the message?

Just for yucks:
# ipfw table 22 list| wc -l
    2050

Re: [SSHGuard-users] sshguard 1.7.0 with PF backend dumps core at shutdown on FreeBSD

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

Hi Neil,

On 10/04/2016 11:10, Neil Darlow wrote:
> I am using the FreeBSD security/sshguard-pf port built with
> portmaster.
> 
> sshguard is controlled by the standard RC script provided by the port
> and shutdown is usually by "shutdown -p now" although it can be done
> via the XEN or QEMU/KVM host.

I wanted to follow up about this issue. Are you still experiencing it?

Best,
Kevin

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

Re: [SSHGuard-users] [PATCH] A new rule for sendmail for consideration

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

On Fri, Nov 25, 2016 at 11:52:32AM -0800, Kevin Zheng wrote:
> On 10/16/2016 16:26, Jonathan Woithe wrote:
> > Our mail host logs a large number of repeated sendmail messages of the
> > following form:
> > 
> >   <address> did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> > 
> > :
> > Find below a patch which adds such a rule to sshguard 1.7.0. ...
> 
> Sorry for the delay. Committed with changes in 928839c, thanks!

All good.  Thanks for including it in sshguard.

> There was an issue with your patch (the "SENDMAIL_NOISSUE_PREF addr
> SENDMAIL_NOISSUE_SUFF;" line in attack_parser.y) that prevented the
> subsequent rules from being matched.

Ah, I see.  Sorry about that.  The machine I was running the original patch
on functions only as a mail server and isn't subjected to regular triggers
for the following rules so I didn't notice the lack of matches against other
rules after activating the new rule.  Thanks for noticing.

Regards
  jonathan

Re: [SSHGuard-users] [PATCH] A new rule for sendmail for consideration

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

On 10/16/2016 16:26, Jonathan Woithe wrote:
> Our mail host logs a large number of repeated sendmail messages of the
> following form:
> 
>   <address> did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> 
> While isolated messages from some addresses do appear, there are a number of
> times where multiple messages are seen from a particular address, each
> within a second or so of the previous one.  It's not entirely clear what the
> intent of these connections is, but it doesn't seem to be about sending
> mail.  To that end, blocking the offending hosts with sshguard seems to be a
> worthwhile exercise.
> 
> Find below a patch which adds such a rule to sshguard 1.7.0.  I have applied
> this to 1.6.4 and tested it successfully (I haven't deployed 1.7.0 on the
> server yet due to the now resolved hosts backend issue).  If you feel that
> this is a useful addition to sshguard, please consider applying it to the
> repo.

Sorry for the delay. Committed with changes in 928839c, thanks!

There was an issue with your patch (the "SENDMAIL_NOISSUE_PREF addr
SENDMAIL_NOISSUE_SUFF;" line in attack_parser.y) that prevented the
subsequent rules from being matched.

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

I expect this is true.  However, there's still the "Failed password..."
messages, and these should be matched by the 

  Failed XYZ for XYZ from 6.6.6.0 port 14423 ssh2

rule, right?  There were plenty of these in the 212.129.60.203 messages, but
212.129.60.203 wasn't blocked.

The other issue is that in the later 91.224.160.131 case the same pattern
of messages was logged as was seen for 212.129.60.203, but 91.224.160.131
*was* correctly blocked.  That is, from 212.129.60.203 we got 9 groups of
the following form:

  Oct 24 05:52:47 sshd[5254]: Invalid user ubnt from 212.129.60.203 port 62676
  Oct 24 05:52:47 sshd[5254]: input_userauth_request: invalid user ubnt [preauth]
  Oct 24 05:52:48 sshd[5254]: Failed password for invalid user ubnt from 212.129.60.203 port 62676 ssh2

and yet 212.129.60.203 was not blocked.  When we got 5 groups of these:

  Oct 24 01:04:19 sshd[21389]: Invalid user admin from 91.224.160.131 port 34317
  Oct 24 01:04:19 sshd[21389]: input_userauth_request: invalid user admin [preauth]
  Oct 24 01:04:19 sshd[21389]: Failed password for invalid user admin from 91.224.160.131 port 34317 ssh2

then 91.224.160.131 was blocked.  These are exactly the same message
patterns and yet sshguard seemed to treat them differently for some reason.

The only practical difference between the two cases that I can see is the
presence of "last message repeated" lines in between the 91.224.160.131
messages and a couple of 121.18.238.114 messages within the 212.129.60.203
messages.  I can't see how either of these could actively prevent the block
being activated.

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

It will certainly allow sshguard to act on the "Invalid user" messages.  As
above though, I can't see why this would be needed since sshguard should
still be acting on the "Failed password" messages in both cases, not just
one of them.

I presume this will require something along the lines of the patch at the
end of this message.

Regards
  jonathan

--- a/sshguard-1.7.0/src/parser/attack_parser.y	2016-10-26 09:28:32.071665939 +1030
+++ b/sshguard-1.7.0/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
     ;
--- a/sshguard-1.7.0/src/parser/attack_scanner.l	2016-10-26 09:28:16.783513172 +1030
+++ b/sshguard-1.7.0/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; }

[SSHGuard-users] SSHGuard 1.7.1 release announcement

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

Hi there,

SSHGuard 1.7.1 is available.

Added
- Add sample Mac OS X 10.12 style launchd.plist

Changed
- Allow multiple forward slashes in process name
- Log released addresses only when debugging

Deprecated
- Process validation (``-f`` option) is deprecated

Fixed
- Adjust TIMESTAMP_ISO8601 for Mac OS X 10.12
- Fix build error in hosts backend
- Fix empty functions in firewall scripts causing errors with Bash
- Flush stdout after every line in sshg-parser

Best,
Kevin

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

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

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

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.

Best,
Kevin

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

[SSHGuard-users] Missed detections of ssh abuses

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

Hi all

I was wondering whether anyone could provide some insight into why a
particular host was not blocked by sshguard 1.6.4 on one of my servers. 
Sshguard is run using

  /usr/local/sbin/sshguard -w <internal-lan> -l /var/log/messages \
    -a 40 -p 420 -s 1800

The content of the messages file around the time of the missed detection was
as follows.

Oct 24 05:52:44 sshd[5253]: Did not receive identification string from 212.129.60.203 port 62662
Oct 24 05:52:47 sshd[5254]: Invalid user ubnt from 212.129.60.203 port 62676
Oct 24 05:52:47 sshd[5254]: input_userauth_request: invalid user ubnt [preauth]
Oct 24 05:52:48 sshd[5254]: Failed password for invalid user ubnt from 212.129.60.203 port 62676 ssh2
Oct 24 05:52:48 sshd[5254]: Disconnected from 212.129.60.203 port 62676 [preauth]
Oct 24 05:52:56 sshd[5275]: Invalid user admin from 212.129.60.203 port 64796
Oct 24 05:52:56 sshd[5275]: input_userauth_request: invalid user admin [preauth]
Oct 24 05:52:57 sshd[5275]: Failed password for invalid user admin from 212.129.60.203 port 64796 ssh2
Oct 24 05:52:57 sshd[5275]: Disconnected from 212.129.60.203 port 64796 [preauth]
Oct 24 05:53:02 sshd[5291]: User root from 212.129.60.203 not allowed because not listed in AllowUsers
Oct 24 05:53:02 sshd[5291]: input_userauth_request: invalid user root [preauth]
Oct 24 05:53:03 sshd[5291]: Failed password for invalid user root from 212.129.60.203 port 50666 ssh2
Oct 24 05:53:03 sshd[5291]: Disconnected from 212.129.60.203 port 50666 [preauth]
Oct 24 05:53:05 sshd[5295]: Received disconnect from 121.18.238.114 port 33649:11:  [preauth]
Oct 24 05:53:05 sshd[5295]: Disconnected from 121.18.238.114 port 33649 [preauth]
Oct 24 05:53:11 sshd[5323]: Invalid user guest from 212.129.60.203 port 52019
Oct 24 05:53:11 sshd[5323]: input_userauth_request: invalid user guest [preauth]
Oct 24 05:53:12 sshd[5323]: Failed password for invalid user guest from 212.129.60.203 port 52019 ssh2
Oct 24 05:53:14 sshd[5323]: Disconnected from 212.129.60.203 port 52019 [preauth]
Oct 24 05:53:18 sshd[5327]: Invalid user admin from 212.129.60.203 port 52079
Oct 24 05:53:18 sshd[5327]: input_userauth_request: invalid user admin [preauth]
Oct 24 05:53:19 sshd[5327]: Failed password for invalid user admin from 212.129.60.203 port 52079 ssh2
Oct 24 05:53:19 sshd[5327]: Disconnected from 212.129.60.203 port 52079 [preauth]
Oct 24 05:53:22 sshd[5348]: Invalid user support from 212.129.60.203 port 52131
Oct 24 05:53:22 sshd[5348]: input_userauth_request: invalid user support [preauth]
Oct 24 05:53:23 sshd[5348]: Failed password for invalid user support from 212.129.60.203 port 52131 ssh2
Oct 24 05:53:23 sshd[5348]: Disconnected from 212.129.60.203 port 52131 [preauth]
Oct 24 05:53:26 sshd[5359]: Invalid user test from 212.129.60.203 port 52177
Oct 24 05:53:26 sshd[5359]: input_userauth_request: invalid user test [preauth]
Oct 24 05:53:27 sshd[5359]: Failed password for invalid user test from 212.129.60.203 port 52177 ssh2
Oct 24 05:53:27 sshd[5359]: Disconnected from 212.129.60.203 port 52177 [preauth]
Oct 24 05:53:31 sshd[5361]: Invalid user user from 212.129.60.203 port 52222
Oct 24 05:53:31 sshd[5361]: input_userauth_request: invalid user user [preauth]
Oct 24 05:53:31 sshd[5361]: Failed password for invalid user user from 212.129.60.203 port 52222 ssh2
Oct 24 05:53:32 sshd[5361]: Disconnected from 212.129.60.203 port 52222 [preauth]
Oct 24 05:53:34 sshd[5377]: User operator from 212.129.60.203 not allowed because not listed in AllowUsers
Oct 24 05:53:34 sshd[5377]: input_userauth_request: invalid user operator [preauth]
Oct 24 05:53:35 sshd[5377]: Failed password for invalid user operator from 212.129.60.203 port 52247 ssh2
Oct 24 05:53:35 sshd[5377]: Disconnected from 212.129.60.203 port 52247 [preauth]

Between 05:52:44 and 05:53:35, there were plenty of matches with the
sshguard rule pattern "Failed XYZ for XYZ from 6.6.6.0 port 14423 ssh2":

  05:52:48 Failed password for invalid user ubnt from 212.129.60.203 port 62676 ssh2
  05:52:57 Failed password for invalid user admin from 212.129.60.203 port 64796 ssh2
  05:53:03 Failed password for invalid user root from 212.129.60.203 port 50666 ssh2
  05:53:12 Failed password for invalid user guest from 212.129.60.203 port 52019 ssh2
  05:53:19 Failed password for invalid user admin from 212.129.60.203 port 52079 ssh2
  05:53:23 Failed password for invalid user support from 212.129.60.203 port 52131 ssh2
  05:53:27 Failed password for invalid user test from 212.129.60.203 port 52177 ssh2
  05:53:31 Failed password for invalid user user from 212.129.60.203 port 52222 ssh2
  05:53:35 Failed password for invalid user operator from 212.129.60.203 port 52247 ssh2

While other ssh rules would have failed to match due to subtle differences
between the patterns and the message content[1], these "Failed password"
matches should have provided sufficient grounds to block 212.129.60.203, but
evidently this never happened.

About an hour later there was another attack with very similar log entries,
but this one was blocked:

Oct 24 01:04:19 sshd[21389]: Invalid user admin from 91.224.160.131 port 34317
Oct 24 01:04:19 sshd[21389]: input_userauth_request: invalid user admin [preauth]
Oct 24 01:04:19 sshd[21389]: Failed password for invalid user admin from 91.224.160.131 port 34317 ssh2
Oct 24 01:04:20 sshd[21389]: Connection closed by 91.224.160.131 port 34317 [preauth]
:
Oct 24 06:58:53 sshd[12038]: Invalid user admin from 91.224.160.131 port 42027
Oct 24 06:58:53 sshd[12038]: input_userauth_request: invalid user admin [preauth]
Oct 24 06:58:53 sshd[12038]: Failed password for invalid user admin from 91.224.160.131 port 42027 ssh2
Oct 24 06:58:54 last message repeated 4 times
Oct 24 06:58:57 sshd[12038]: Received disconnect from 91.224.160.131 port 42027:11:  [preauth]
Oct 24 06:58:57 sshd[12038]: Disconnected from 91.224.160.131 port 42027 [preauth]
Oct 24 06:59:01 sshd[12049]: Invalid user admin from 91.224.160.131 port 48773
Oct 24 06:59:01 sshd[12049]: input_userauth_request: invalid user admin [preauth]
Oct 24 06:59:01 sshd[12049]: Failed password for invalid user admin from 91.224.160.131 port 48773 ssh2
Oct 24 06:59:03 last message repeated 4 times
Oct 24 06:59:05 sshd[12049]: Received disconnect from 91.224.160.131 port 48773:11:  [preauth]
Oct 24 06:59:05 sshd[12049]: Disconnected from 91.224.160.131 port 48773 [preauth]
Oct 24 06:59:11 sshd[12062]: Invalid user admin from 91.224.160.131 port 33310
Oct 24 06:59:11 sshd[12062]: input_userauth_request: invalid user admin [preauth]
Oct 24 06:59:11 sshd[12062]: Failed password for invalid user admin from 91.224.160.131 port 33310 ssh2
Oct 24 06:59:12 last message repeated 4 times
Oct 24 06:59:15 sshd[12062]: Received disconnect from 91.224.160.131 port 33310:11:  [preauth]
Oct 24 06:59:15 sshd[12062]: Disconnected from 91.224.160.131 port 33310 [preauth]
Oct 24 06:59:20 sshd[12074]: Invalid user admin from 91.224.160.131 port 50973
Oct 24 06:59:20 sshd[12074]: input_userauth_request: invalid user admin [preauth]
Oct 24 06:59:20 sshd[12074]: Failed password for invalid user admin from 91.224.160.131 port 50973 ssh2
Oct 24 06:59:22 sshd[12074]: Received disconnect from 91.224.160.131 port 50973:11:  [preauth]
Oct 24 06:59:22 sshd[12074]: Disconnected from 91.224.160.131 port 50973 [preauth]
Oct 24 06:59:22 sshguard[532]: 91.224.160.131: blocking for 6720 secs (4 attacks in 25 secs, after 4 abuses over 199489 secs)

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.

As an aside, it would be good if sshguard could recognise the "last message
repeated N times" messages and count the proceeding message N times when it
matches an sshguard rule.  This would speed up attack detections on systems
which utilise these aggregation messages.

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

Regards
  jonathan

[SSHGuard-users] [PATCH] A new rule for sendmail for consideration

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

Hi all

Our mail host logs a large number of repeated sendmail messages of the
following form:

  <address> did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

While isolated messages from some addresses do appear, there are a number of
times where multiple messages are seen from a particular address, each
within a second or so of the previous one.  It's not entirely clear what the
intent of these connections is, but it doesn't seem to be about sending
mail.  To that end, blocking the offending hosts with sshguard seems to be a
worthwhile exercise.

Find below a patch which adds such a rule to sshguard 1.7.0.  I have applied
this to 1.6.4 and tested it successfully (I haven't deployed 1.7.0 on the
server yet due to the now resolved hosts backend issue).  If you feel that
this is a useful addition to sshguard, please consider applying it to the
repo.

Regards
  jonathan

This patch against sshguard 1.7.0 adds recognition of the sendmail message

  <address> did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

--- a/sshguard-1.7.0/src/parser/attack_parser.y	2016-08-07 01:51:51.000000000 +0930
+++ b/sshguard-1.7.0/src/parser/attack_parser.y	2016-09-29 12:28:54.105184227 +0930
@@ -88,6 +88,7 @@
 /* sendmail */
 %token SENDMAIL_RELAYDENIED_PREF SENDMAIL_RELAYDENIED_SUFF
 %token SENDMAIL_AUTHFAILURE_PREF SENDMAIL_AUTHFAILURE_SUFF
+%token SENDMAIL_NOISSUE_PREF SENDMAIL_NOISSUE_SUFF
 /* postfix */
 %token POSTFIX_NO_AUTH_PREF POSTFIX_SASL_LOGINERR_PREF POSTFIX_SASL_LOGINERR_SUFF
 /* FreeBSD's FTPd */
@@ -267,7 +268,8 @@
    ;
 
 sendmailmsg:
-   SENDMAIL_RELAYDENIED_PREF addr SENDMAIL_RELAYDENIED_SUFF;
+   SENDMAIL_RELAYDENIED_PREF addr SENDMAIL_RELAYDENIED_SUFF |
+   SENDMAIL_NOISSUE_PREF addr SENDMAIL_NOISSUE_SUFF;
    | SENDMAIL_AUTHFAILURE_PREF addr SENDMAIL_AUTHFAILURE_SUFF { attack->dangerousness *= 2; } ;
    ;
 
--- a/sshguard-1.7.0/src/parser/attack_scanner.l	2016-08-07 01:51:51.000000000 +0930
+++ b/sshguard-1.7.0/src/parser/attack_scanner.l	2016-09-29 12:34:05.139946762 +0930
@@ -40,7 +40,7 @@
  /* for Login services */
 %s 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 postfix_loginerr
+%s dovecot_loginerr cyrusimap_loginerr exim_esmtp_autherr sendmail_relaydenied sendmail_authfailure sendmail_noissue postfix_loginerr
  /* for FTP services */
 %s freebsdftpd_loginerr  proftpd_loginerr  pureftpd_loginerr vsftpd_loginerr
 
@@ -169,6 +169,10 @@
 [A-Za-z0-9]+": AUTH failure ("[A-Za-z0-9-]+"): ".+"relay=".*"[" { BEGIN(sendmail_authfailure); return SENDMAIL_AUTHFAILURE_PREF; }
 <sendmail_authfailure>"]".*                                     { BEGIN(INITIAL); return SENDMAIL_AUTHFAILURE_SUFF; }
 
+ /* Sendmail */
+.*"["                                                           { BEGIN(sendmail_noissue); return SENDMAIL_NOISSUE_PREF; }
+<sendmail_noissue>"] ".*"did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA"    { BEGIN(INITIAL); return SENDMAIL_NOISSUE_SUFF; }
+
  /* dovecot */
 (imap|pop3)"-login: Aborted login (auth failed, "{NUMBER}" attempts".*"): ".+" rip=" { BEGIN(dovecot_loginerr); return DOVECOT_IMAP_LOGINERR_PREF; }
 <dovecot_loginerr>", lip=".+                                        { BEGIN(INITIAL); return DOVECOT_IMAP_LOGINERR_SUFF; }

Re: [SSHGuard-users] sshguard 1.7.0 with PF backend dumps core at shutdown on FreeBSD

[Neil D. <ne...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Kevin,

Thanks for the fast response.

I am using the FreeBSD security/sshguard-pf port built with portmaster.

sshguard is controlled by the standard RC script provided by the port and shutdown is usually by "shutdown -p now" although it can be done via the XEN or QEMU/KVM host.

Regards,
Neil Darlow
- --
Sent from my Sony Xperia™ phone with K-9 Mail.
-----BEGIN PGP SIGNATURE-----

iQG9BAEBCgAnIBxOZWlsIERhcmxvdyA8bmVpbEBkYXJsb3cuY28udWs+BQJX8/CD
AAoJELtgepPGgJD1V44L/2tTtL5hR6u/m+dcSrJ9qXOrUd/KTb1D+BxVwi4ft9OU
P2/xWqC5BPGgwOXQQbFaCudLLDwIh5+3YF8RnsPqqH7BdYzuQyGNaUSaiPVksa+L
BEjwN9bCLfW+raQJiLdFIEeu0iIqwzUcDaFubp/hHfo7+8cDs6hxBDlJ2QviZkeI
2Dpz2yzTztOVuWCGjoZGTgmJTu/Xzkysu9nCHDtU3CWEy5Dvv3iQRHJ4nIpoByvz
gW9mqiyOfm62T+QeaCZCTCwEodSRlyax2PgP0P+VcZJbPkxvp5GNmWdhk8NmDAfb
hrsSSxDwAHQvNBNrT9pDfxICV8LD4GgAalr4MnEuTEQ3XexlqYniiSeI6sLs4C0I
lTW3d3Js8QSsBk4y0iHWeZBvtFTg/HaorwfuIpghnpZbVT9IM0sQNMMkfhU/+JER
ASlWgiVCrDvAS+I6nkEyWGgFCuldVbn91vSal9JE2h/TAx1CwFEa68kZE+SipEt6
kbxI3B7998wEQGIxHL5xZw==
=x09x
-----END PGP SIGNATURE-----

Re: [SSHGuard-users] sshguard 1.7.0 with PF backend dumps core at shutdown on FreeBSD

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

On 10/04/2016 10:32, Neil Darlow wrote:
> I have raised a bug report on the FreeBSD Bugzilla #213170 and the port
> maintainer has suggested that I report it upstream.
> 
> Details are in the bug report but the TL;DR is that I have moved from
> the hosts backend to PF with the release of sshguard 1.7.0 and sshguard
> dumps core at shutdown. In all other respects it appears to operate
> correctly.

Thanks for the report. I can try reproducing this on my own, but some
more information might certainly make this easier.

Does the core dump happen when you kill SSHGuard (SIGTERM, SIGINT, etc)
or when you bring it down using the services script? (How are you
running SSHGuard?)

Thanks,
Kevin

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

[SSHGuard-users] sshguard 1.7.0 with PF backend dumps core at shutdown on FreeBSD

[Neil D. <ne...@da...>]

Hi,

I have raised a bug report on the FreeBSD Bugzilla #213170 and the port
maintainer has suggested that I report it upstream.

Details are in the bug report but the TL;DR is that I have moved from
the hosts backend to PF with the release of sshguard 1.7.0 and sshguard
dumps core at shutdown. In all other respects it appears to operate
correctly.

Regards,
Neil Darlow

Re: [SSHGuard-users] sshguard-1.7.0 and Postfix

[Jim S. <jse...@Li...>]

On Fri, 30 Sep 2016 11:38:58 +0000
Gerard Seibert <car...@ou...> wrote:

[snip]
> 
> You are certainly entitled to your opinion; however, I feel that the
> number of legitimate sites failing reverse dns is trivial.

Hardly.  IME the number of people administering networks that are
actually competent at it and conscientious about their job are
outnumbered by the number that are not either one, the other or both.

From my personal server at home, from yesterday, alone, there were 254
SMTP connections where the hostname did not resolve to the correct, or
any, IP address.  79 of those were unique hostnames, from at least
twenty TLDs from all over the world.

> You will
> notice the "whois" output below. I know no one in Vietnam 

There's no way for sshguard to "know" that :)

> and feel
> quite confident in stating that this was an example of an attempt to
> hack into my mail system.

Via Postfix' SMTPD daemon?  *snort*  Won't bloody likely encounter much
success with that.

In any event: There's nothing in the signature of those log lines to
suggest sshguard, or any other IDS, should take action.  As I wrote,
earlier: Those log lines, in and of themselves, are merely reflective
of poorly set up DNS.  That doesn't mean somebody's not trying to find
a vulnerability in your server, merely that *those* log lines don't
make the case that they are.

In the network admin/security world we tend to abide by Hanlon's Razor:

    "Never attribute to malice that which is adequately explained by
     stupidity."

(Sometimes substituting "incompetence" for "stupidity.")

[snip]
> I was advised to use
> the following in my postfix config file:
> "reject_unknown_reverse_client_hostname".

That is the weaker, and, therefor, less-likely-damaging of the two
restrictions you might have added.  I'll leave it at that, being as
Postfix configuration is OT for this mailing list.

[snip]
> 
> Thanks for your response.

You're welcome,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.

Re: [SSHGuard-users] sshguard-1.7.0 and Postfix

[Gerard S. <car...@ou...>]

On Fri, 30 Sep 2016 06:40:20 -0400, Jim Seymour stated:

>On Fri, 30 Sep 2016 10:13:44 +0000
>Gerard Seibert <car...@ou...> wrote:
>
>[snip]
>> 
>> While the IP address will change, the action is never blocked by
>> sshguard. Shouldn't sshguard recognize this as an attack and block
>> it?  
>
>I should certainly hope not.  If one took to blackholing every system
>on the 'net that had wonky DNS, they'd have a significant portion
>blocked a significant amount of the time.
>
>It may be in conjunction with an attack, but, those log entries, in and
>of themselves, do not suggest an attack.
>
>If you do not wish to accept email from such sources (I would not, but
>that's a personal/corporate/site preferance), you can use one of the
>appropriate Postfix config directives.

You are certainly entitled to your opinion; however, I feel that the
number of legitimate sites failing reverse dns is trivial. You will
notice the "whois" output below. I know no one in Vietnam and feel quite
confident in stating that this was an example of an attempt to hack into
my mail system. As I stated, I have found several hacks like this
before, with different IPs of course. I was advised to use the
following in my postfix config file:
"reject_unknown_reverse_client_hostname". I will be checking the log
file judiciously to see if in fact any legitimate sites are being
blocked.

Thanks for your response.

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

refer:        whois.apnic.net

inetnum:      118.0.0.0 - 118.255.255.255
organisation: APNIC
status:       ALLOCATED

whois:        whois.apnic.net

changed:      2007-01
source:       IANA

% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '118.71.240.0 - 118.71.255.255'

inetnum:        118.71.240.0 - 118.71.255.255
netname:        fpt-net
descr:          Vung dia chi IP cap cho dich vu IPTV tai Hai Phong
country:        vn
admin-c:        fhig1-ap
tech-c:         fhig1-ap
status:         ASSIGNED NON-PORTABLE
mnt-by:         maint-vn-fpt
changed:        hm-...@vn... 20080923
source:         APNIC

role:           FPT HANOI IPADMIN GROUP
address:        48 Van Bao, Ba Dinh
address:        Ha Noi
country:        VN
phone:          +84-4-7601060
fax-no:         +84-4-7262163
e-mail:         fte...@fp...
remarks:        send spam reports to fte...@fp...
admin-c:        TPV1-AP
tech-c:         NTT9-AP
nic-hdl:        FHIG1-AP
notify:         hm-...@vn...
mnt-by:         MAINT-VN-FPT
changed:        hm-...@vn... 20090325
changed:        hm-...@ap... 20111114
changed:        hm-...@vn... 20141113
source:         APNIC

% This query was served by the APNIC Whois Service version
1.69.1-APNICv1r0 (UNDEFINED)

-- 
Carmel

Re: [SSHGuard-users] sshguard-1.7.0 and Postfix

[Jim S. <jse...@Li...>]

On Fri, 30 Sep 2016 10:13:44 +0000
Gerard Seibert <car...@ou...> wrote:

[snip]
> 
> While the IP address will change, the action is never blocked by
> sshguard. Shouldn't sshguard recognize this as an attack and block it?

I should certainly hope not.  If one took to blackholing every system on
the 'net that had wonky DNS, they'd have a significant portion blocked a
significant amount of the time.

It may be in conjunction with an attack, but, those log entries, in and
of themselves, do not suggest an attack.

If you do not wish to accept email from such sources (I would not, but
that's a personal/corporate/site preferance), you can use one of the
appropriate Postfix config directives.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.

[SSHGuard-users] sshguard-1.7.0 and Postfix

[Gerard S. <car...@ou...>]

I have had sshguard working perfectly on my FreeBSD-11.0 system for
several months now. suddenly, I am finding the following entires in my
mail-log:

38167:Sep 30 04:52:54 scorpio postfix/smtpd[85858]: warning: hostname ip-address-pool-xxx.fpt.vn does not resolve to address 118.71.251.67:hostname nor servname provided, or not known
38346:Sep 30 04:52:54 scorpio postfix/smtpd[85858]: connect from unknown[118.71.251.67]
38428:Sep 30 04:52:55 scorpio postfix/smtpd[85858]: disconnect from unknown[118.71.251.67] helo=1 auth=0/1 quit=1 commands=2/3

While the IP address will change, the action is never blocked by
sshguard. Shouldn't sshguard recognize this as an attack and block it?

-- 
Carmel

Re: [SSHGuard-users] Support for the "hosts" firewall backend

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

On Thu, Sep 29, 2016 at 01:12:23AM -0700, Kevin Zheng wrote:
> On 09/28/2016 21:25, Jonathan Woithe wrote:
> > I personally have found the "hosts" backend to be extremely useful.  It
> > allows sshguard's actions to be firmly isolated from the rest of the
> > firewall, which is important if a complex firewall is already in place. 
> > It's also much easier to isolate sshguard from the firewall using the
> > "hosts" backend as it only needs permission to alter a single file. 
> > Collectively these details mean that it has been trivial for me to deploy
> > sshguard on a number of machines without having to take special precautions
> > to ensure it doesn't inadvertently interfere with other things on the
> > system.
> 
> Thanks for the comments. I'll re-implement support for the hosts backend
> in the next release.

Awesome - that would be fantastic.

> > It is unlikely that the majority of people using sshguard even heard about
> > this survey.  I didn't ...
> 
> The user survey was announced (twice) on the user mailing list.

I wasn't on the mailing list until I joined this afternoon in order to post.

> > As an aside, I note that rather than being deprecated in sshguard 1.7.0, the
> > "hosts" backend doesn't actually compile anymore.  So technically it was
> > effectively deprecated in 1.6.4 and removed in 1.7.0.
> 
> My fault for insufficient testing before release. In slight defense, I
> sent a call-for-testing after the commit that probably broke it, as well
> as one or two weeks before the release. Issues that came up were fixed;
> the hosts backend issue never came up.

Obviously I can't comment on this since I wasn't on the mailing list to hear
about the call.

> Most users interact with package maintainers. The only package
> maintainer that I've interacted with is Mark (from FreeBSD), who's done
> a great job of updating and pointing out bugs. I need more support from
> package maintainers.

There are probably quite a few users who, like me, grabbed the source and
compiled it locally.

> Users who aren't on the mailing list aren't heard from.
> 
> I realize it's not possible to participate in every project you use.
> Unfortunately I don't have a good solution to this problem; if you don't
> participate you aren't heard.

As you said, no one has sufficient time to subscribe to and read the user
mailing list for every piece of software they use regularly.  I suspect that
I use at least a hundred different pieces of software across any given week. 
Reading that many lists is just not feasible.  If one hears about software
that does a job that needs to be done, one obtains it, installs it and uses
it.  Generally speaking there is no option but to trust that the team
maintaining it won't reduce functionality over time or remove features that
they rely on.  It's almost like an unwritten agreement.

> > I don't mind when features are deprecated in cases where there's a clear
> > way to achieve similar behaviours with alternative configurations. 
> > Sometimes this is needed to make progress.  However, in this case there
> > isn't: none of the remaining backends offer the kind of functionality
> > previously provided by "hosts".  Unless there's a significant future
> > maintenance burden associated with the "hosts" backend I don't agree
> > with its deprecation.
> 
> After it's rewritten, it shouldn't need to be touched for a long time.

I figured this to be the case.

> > Pretty much as it was documented.  I personally chose this backend because
> > there was no way it could interfere with the existing firewall functionality
> > on the system (and conversely, the firewall management couldn't interfere
> > with sshguard).  In addition I liked the simplicity of the hosts.allow
> > approach.
> 
> Consider trying different backends. The PF and IPFW backends do not add
> rules; you add the rules yourself to the firewall, and add a directive
> that creates a table. SSHGuard populates and depopulates the table.

I'm on Linux, so the BSD PF/IPFW backend options aren't an option.  I
imagine the iptables backend uses a similar approach though.

However, getting the "hosts" backend up and running is much more straight
forward.  For niche uses such as those I have and for those who are wanting
to give it a go, the non-invasive nature of the "hosts" backend is very
attractive.  Furthermore, sshguard does not need special privileges to alter
the blocks: just write permission on /etc/hosts.allow.  Altering the
iptables tables would require higher privileges.

In any case this is a moot point since "hosts" will make a comeback in the
next release.

Regards
  jonathan

Re: [SSHGuard-users] Support for the "hosts" firewall backend

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

On 09/28/2016 21:25, Jonathan Woithe wrote:
> I personally have found the "hosts" backend to be extremely useful.  It
> allows sshguard's actions to be firmly isolated from the rest of the
> firewall, which is important if a complex firewall is already in place. 
> It's also much easier to isolate sshguard from the firewall using the
> "hosts" backend as it only needs permission to alter a single file. 
> Collectively these details mean that it has been trivial for me to deploy
> sshguard on a number of machines without having to take special precautions
> to ensure it doesn't inadvertently interfere with other things on the
> system.

Thanks for the comments. I'll re-implement support for the hosts backend
in the next release.

Support was dropped due to changes in the firewall backend. These
changes separate the backend program from SSHGuard, a stepping stone to
sandboxing SSHGuard with Capsicum or pledge(2). From several posts to
the list it seemed like nobody was using it.

> It is unlikely that the majority of people using sshguard even heard about
> this survey.  I didn't: I am only now aware of it because I went searching
> to find out the reason for the "hosts" backend being deprecated as noted in
> the 1.7.0 release notes which I've just read.

The user survey was announced (twice) on the user mailing list.

> As an aside, I note that rather than being deprecated in sshguard 1.7.0, the
> "hosts" backend doesn't actually compile anymore.  So technically it was
> effectively deprecated in 1.6.4 and removed in 1.7.0.

My fault for insufficient testing before release. In slight defense, I
sent a call-for-testing after the commit that probably broke it, as well
as one or two weeks before the release. Issues that came up were fixed;
the hosts backend issue never came up.

> I'm certainly not the only one in this situation.  The author of the article
> at
> 
>   https://forums.freebsd.org/threads/57509/ 
> 
> is in a similar situation to me, although they have obviously taken the
> deprecation notice a little harder than I.

It's true: software maintainers aren't telepathic. Most users deal with
package maintainers and not upstream, too. I admit: I know how I use
SSHGuard; I know how the users on the mailing list use SSHGuard; and I
can guess how the survey respondents use SSHGuard. Beyond that, no clue.

Most users interact with package maintainers. The only package
maintainer that I've interacted with is Mark (from FreeBSD), who's done
a great job of updating and pointing out bugs. I need more support from
package maintainers.

Users who aren't on the mailing list aren't heard from.

I realize it's not possible to participate in every project you use.
Unfortunately I don't have a good solution to this problem; if you don't
participate you aren't heard.

> There may be subtle issues in play that I'm not currently aware of, but the
> patch included at the end of this message against sshguard 1.7.0 compiles
> and might be all that's needed to get the "hosts" backend working again.

I'll take a look and get back to you.

> I don't mind when features are deprecated in cases where there's a clear way
> to achieve similar behaviours with alternative configurations.  Sometimes
> this is needed to make progress.  However, in this case there isn't: none of
> the remaining backends offer the kind of functionality previously provided
> by "hosts".  Unless there's a significant future maintenance burden
> associated with the "hosts" backend I don't agree with its deprecation.

After it's rewritten, it shouldn't need to be touched for a long time.

> Pretty much as it was documented.  I personally chose this backend because
> there was no way it could interfere with the existing firewall functionality
> on the system (and conversely, the firewall management couldn't interfere
> with sshguard).  In addition I liked the simplicity of the hosts.allow
> approach.

Consider trying different backends. The PF and IPFW backends do not add
rules; you add the rules yourself to the firewall, and add a directive
that creates a table. SSHGuard populates and depopulates the table.

Best,
Kevin

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

[SSHGuard-users] Support for the "hosts" firewall backend

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

Hi all

On 2016-08-29 18:03:05, Kevin Zheng wrote:
> If that's something people are interested in it would just involve
> translating the original hosts.c into a new sshg-fw backend.

I personally have found the "hosts" backend to be extremely useful.  It
allows sshguard's actions to be firmly isolated from the rest of the
firewall, which is important if a complex firewall is already in place. 
It's also much easier to isolate sshguard from the firewall using the
"hosts" backend as it only needs permission to alter a single file. 
Collectively these details mean that it has been trivial for me to deploy
sshguard on a number of machines without having to take special precautions
to ensure it doesn't inadvertently interfere with other things on the
system.

If the "hosts" backend is deprecated then I would probably have to either
look for an alternative piece of software or stick with the last sshguard
version to offer the feature (1.6.4).

> It's only deprecated because not many people said they were using it on
> the survey, and I wasn't going to rewrite if not many were using it.

It is unlikely that the majority of people using sshguard even heard about
this survey.  I didn't: I am only now aware of it because I went searching
to find out the reason for the "hosts" backend being deprecated as noted in
the 1.7.0 release notes which I've just read.

As an aside, I note that rather than being deprecated in sshguard 1.7.0, the
"hosts" backend doesn't actually compile anymore.  So technically it was
effectively deprecated in 1.6.4 and removed in 1.7.0.

I'm certainly not the only one in this situation.  The author of the article
at

  https://forums.freebsd.org/threads/57509/ 

is in a similar situation to me, although they have obviously taken the
deprecation notice a little harder than I.

There may be subtle issues in play that I'm not currently aware of, but the
patch included at the end of this message against sshguard 1.7.0 compiles
and might be all that's needed to get the "hosts" backend working again.

> It would be trivial to implement if we assume the whole hosts.deny is
> controlled by SSHGuard. The original implementation used comment blocks
> to separate the SSHGuard-controlled parts from the rest.

For my purposes the "hosts" backend as always worked just fine (the comment
block approach seemed perfectly reasonable to me).  I acknowledge that it's
not as flexible as other approaches and other rules in hosts.allow could
obviously interfere, but I think that's a user issue.  For many people the
"hosts" backed was simple, worked fine and did not interfere with other
things on the system.  For those who needed additional flexibility there was
always the other backends.

I would certainly urge you reconsider the deprecation of the "hosts"
backend.  I suspect there's far more people using it in the wider world than
was indicated by the survey of which you speak.

I don't mind when features are deprecated in cases where there's a clear way
to achieve similar behaviours with alternative configurations.  Sometimes
this is needed to make progress.  However, in this case there isn't: none of
the remaining backends offer the kind of functionality previously provided
by "hosts".  Unless there's a significant future maintenance burden
associated with the "hosts" backend I don't agree with its deprecation.

> Do you know how people are usually using the hosts backend?

Pretty much as it was documented.  I personally chose this backend because
there was no way it could interfere with the existing firewall functionality
on the system (and conversely, the firewall management couldn't interfere
with sshguard).  In addition I liked the simplicity of the hosts.allow
approach.

Regards
  jonathan

--- a/src/fwalls/hosts.c	2016-08-07 01:51:51.000000000 +0930
+++ b/src/fwalls/hosts.c	2016-09-29 13:48:25.401626462 +0930
@@ -146,12 +146,12 @@
     return FWALL_OK;
 }
 
-int fw_block(const char *restrict addr, int addrkind, int service) {
+int fw_block(const attack_t *attack) {
     addr_service_t ads;
 
-    strcpy(ads.addr, addr);
-    ads.service = service;
-    ads.addrkind = addrkind;
+    strcpy(ads.addr, attack->address.value);
+    ads.addrkind = attack->address.kind;
+    ads.service = attack->service;
     list_append(&hosts_blockedaddrs, &ads);
 
     return hosts_updatelist();
@@ -172,10 +172,10 @@
     return hosts_updatelist();
 }
 
-int fw_release(const char *restrict addr, int addrkind, int services) {
+int fw_release(const attack_t *attack) {
     int pos;
 
-    if ((pos = list_locate(&hosts_blockedaddrs, addr)) < 0) {
+    if ((pos = list_locate(&hosts_blockedaddrs, attack->address.value)) <
- 0) {
         return FWALL_ERR;
     }
 

Re: [SSHGuard-users] Fix For Catching Postfix "submission" Log Entry Parsing?

[Jim S. <jse...@Li...>]

On Mon, 19 Sep 2016 10:26:03 -0700
Kevin Zheng <kev...@gm...> wrote:

> On 09/13/2016 09:50, Jim Seymour wrote:
> > My lex/yacc fu is no longer very good, but I do know my way around
> > REs. I believe this can be fixed in sshguard by changing each
> > occurence of the following, in src/parser/attack_scanner.l, from
> > 
> >     {PROCESSNAME}("/"{PROCESSNAME})?
> > 
> > to either
> > 
> >     {PROCESSNAME}("/"{PROCESSNAME})*
> > 
> > or, probably better,
> > 
> >     {PROCESSNAME}("/"{PROCESSNAME}){0,2}  
> 
> Committed in 98ddee7, thanks!
> 

You're welcome, and thank *you* for the utility :)

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.

Re: [SSHGuard-users] Fix For Catching Postfix "submission" Log Entry Parsing?

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

On 09/13/2016 09:50, Jim Seymour wrote:
> My lex/yacc fu is no longer very good, but I do know my way around
> REs. I believe this can be fixed in sshguard by changing each
> occurence of the following, in src/parser/attack_scanner.l, from
> 
>     {PROCESSNAME}("/"{PROCESSNAME})?
> 
> to either
> 
>     {PROCESSNAME}("/"{PROCESSNAME})*
> 
> or, probably better,
> 
>     {PROCESSNAME}("/"{PROCESSNAME}){0,2}

Committed in 98ddee7, thanks!

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

Re: [SSHGuard-users] Fix For Catching Postfix "submission" Log Entry Parsing?

[Jim S. <jse...@Li...>]

On Wed, 14 Sep 2016 08:32:56 -0700
Kevin Zheng <kev...@gm...> wrote:

> Hi Jim,
> 
> On 09/13/2016 09:50, Jim Seymour wrote:
> > My lex/yacc fu is no longer very good, but I do know my way around
> > REs. I believe this can be fixed in sshguard by changing each
> > occurence of the following, in src/parser/attack_scanner.l, from
> > 
> >     {PROCESSNAME}("/"{PROCESSNAME})?
> > 
> > to either
> > 
> >     {PROCESSNAME}("/"{PROCESSNAME})*
> > 
> > or, probably better,
> > 
> >     {PROCESSNAME}("/"{PROCESSNAME}){0,2}  
> 
> I believe your suggested fix is correct. I'll fix it soon-ish
> hopefully and make sure everything else is still working.

Great!  Thanks.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.