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

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

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

On Thu, Dec 8, 2016, at 19:12, jungle Boogie wrote:
> Hi All,
> 
> First, I don't know how to determine the version of sshguard I'm
> currently running, but I compiled it from master on the 5th. So it's a
> version from around that time.

You’re running an experimental build from the master branch that hasn’t
been released . So there is no version number to refer to other than the
latest git commit hash of the master branch when you built it. December
5th? Then your version is master/ff69989.

> It looks like this latest version now includes a config file:
> https://bitbucket.org/sshguard/sshguard/src/1fcd467b78ea5a4ddcba6efb3920cea860839e31/examples/sshguard.conf.sample?at=master&fileviewer=file-view-default
> 
> and a service file:
> https://bitbucket.org/sshguard/sshguard/src/1fcd467b78ea5a4ddcba6efb3920cea860839e31/examples/sshguard.service?at=master&fileviewer=file-view-default

You should set your configuration in the config file instead of in the
service file. I’ve removed the switches from the example service file to
encourage people to use the configuration file instead. (Making changes
to the service file shouldn’t be necessary for anyone but distribution
package maintainers.) 
https://bitbucket.org/sshguard/sshguard/pull-requests/17

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

How did you start it? and under which distro?

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

That would be because the -l option doesn’t exist. At least, I’ve never
seen it before and I can’t find it anywhere but in the example service
file. You should add the log files you want to monitor to the FILES
option in the configuration file. Move the other options there too, it
should be easier to maintain that way.

> iptables:
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N sshguard
> -A INPUT -p tcp -m tcp --dport 22 -j sshguard
> 
> 
> Any suggestions on what I should do to have sshugard read the
> /var/log/auth.log and start blocking?

I do believe the issue is that SSHGuard isn’t monitoring any log files
because of the aforementioned configuration issue.
-- 
Daniel Aleksandersen
https://www.slightfuture.com/

[SSHGuard-users] sshguard on trunk with debian

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

Hi All,

First, I don't know how to determine the version of sshguard I'm
currently running, but I compiled it from master on the 5th. So it's a
version from around that time.

It looks like this latest version now includes a config file:
https://bitbucket.org/sshguard/sshguard/src/1fcd467b78ea5a4ddcba6efb3920cea860839e31/examples/sshguard.conf.sample?at=master&fileviewer=file-view-default

and a service file:
https://bitbucket.org/sshguard/sshguard/src/1fcd467b78ea5a4ddcba6efb3920cea860839e31/examples/sshguard.service?at=master&fileviewer=file-view-default

I have the service running and it's using that file:
 1324 ?        Ss     0:00 /bin/sh /usr/local/sbin/sshguard -w
/etc/sshguard.whitelist -l /var/log/auth.log -b
60:/var/db/sshguard/blacklist.db
 1325 ?        S      0:00 /bin/sh /usr/local/sbin/sshguard -w
/etc/sshguard.whitelist -l /var/log/auth.log -b
60:/var/db/sshguard/blacklist.db

(don't quite know why I have two running instances)

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

iptables:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N sshguard
-A INPUT -p tcp -m tcp --dport 22 -j sshguard


Any suggestions on what I should do to have sshugard read the
/var/log/auth.log and start blocking?

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

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

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

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

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

My firewall got hit 371 times.

--WjW

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

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

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

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

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

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

> 
> 
> > 
> > 
> > 
> > On Sat, 3 Dec 2016 11:38:57 +0200
> > Petri Riihikallio <pet...@me...> wrote:
> >   
> >>> Cliff notes version:
> >>> -----------------
> >>> auth.log.2.bz2:Nov 19 23:07:13 theranch sshguard[803]: blacklist:
> >>> added 186.125.190.156 auth.log.2.bz2:Nov 19 23:07:13 theranch
> >>> sshguard[803]: 186.125.190.156: blocking forever (3 attacks in 2
> >>> secs, after 1 abuses over 2 secs) auth.log.2.bz2:Nov 19 23:07:13
> >>> theranch sshguard[803]: 186.125.190.156: should already have been
> >>> blocked ----------------    
> >>
> >> Have you run 
> >>   ipfw "add 55000 deny ip from table(22) to me”
> >> It should be in your startup scripts someplace. Without it SSHGuard
> >> works, but the collected IPs aren’t used anywhere.
> >>
> >> This baffled me first when I started using SSHGuard. The FreeBSD
> >> port doesn’t add that automatically, because it doesn’t want to
> >> mess your firewall setup. The rule number depends on your existing
> >> rules. 
> > 
> > 
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most 
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > _______________________________________________
> > sshguard-users mailing list
> > ssh...@li...
> > https://lists.sourceforge.net/lists/listinfo/sshguard-users
> >   
> 

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

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

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

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

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

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

--WjW


> 
> 
> 
> On Sat, 3 Dec 2016 11:38:57 +0200
> Petri Riihikallio <pet...@me...> wrote:
> 
>>> Cliff notes version:
>>> -----------------
>>> auth.log.2.bz2:Nov 19 23:07:13 theranch sshguard[803]: blacklist:
>>> added 186.125.190.156 auth.log.2.bz2:Nov 19 23:07:13 theranch
>>> sshguard[803]: 186.125.190.156: blocking forever (3 attacks in 2
>>> secs, after 1 abuses over 2 secs) auth.log.2.bz2:Nov 19 23:07:13
>>> theranch sshguard[803]: 186.125.190.156: should already have been
>>> blocked ----------------  
>>
>> Have you run 
>>   ipfw "add 55000 deny ip from table(22) to me”
>> It should be in your startup scripts someplace. Without it SSHGuard
>> works, but the collected IPs aren’t used anywhere.
>>
>> This baffled me first when I started using SSHGuard. The FreeBSD port
>> doesn’t add that automatically, because it doesn’t want to mess your
>> firewall setup. The rule number depends on your existing rules. 
>>
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
> 

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

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

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


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

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

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

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

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

--WjW


> 
> 
> 
> On Sat, 3 Dec 2016 11:38:57 +0200
> Petri Riihikallio <pet...@me...> wrote:
> 
>>> Cliff notes version:
>>> -----------------
>>> auth.log.2.bz2:Nov 19 23:07:13 theranch sshguard[803]: blacklist:
>>> added 186.125.190.156 auth.log.2.bz2:Nov 19 23:07:13 theranch
>>> sshguard[803]: 186.125.190.156: blocking forever (3 attacks in 2
>>> secs, after 1 abuses over 2 secs) auth.log.2.bz2:Nov 19 23:07:13
>>> theranch sshguard[803]: 186.125.190.156: should already have been
>>> blocked ---------------- 
>>
>> Have you run 
>> ipfw "add 55000 deny ip from table(22) to me”
>> It should be in your startup scripts someplace. Without it SSHGuard
>> works, but the collected IPs aren’t used anywhere.
>>
>> This baffled me first when I started using SSHGuard. The FreeBSD port
>> doesn’t add that automatically, because it doesn’t want to mess your
>> firewall setup. The rule number depends on your existing rules. 
>>
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
> 

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