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

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

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

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

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.

Best,
Kevin

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

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

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

Hi,

I use postfix with the optional

    -o syslog_name=postfix/submission

option in its main.cf configuration.  This causes log lines to look
like (partial):

    ... postfix/submission/smtpd[24257]: warning:
    unknown[185.110.132.134]: SASL LOGIN authentication failed: ...

rather than simply "...postfix/smtpd[24257]...

sshguard's parser fails to catch these.

This can be "fixed" by removing that option from postfix' config, but
then you lose logging detail.

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}

This does cause it to catch the missed log entries.  But, without
thorough analysis of the remainder of the parsing code, I don't know,
for sure, that it won't induce other regression errors.

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] New Attack Signature

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

On 09/10/2016 13:13, Mark Chen wrote:
> Just found this in my logs.  Notice that the spammer alternates among
> several addresses within the same class B network (in this case, two
> different class Bs) in order to avoid detection.
> 
> Any chance we could add a signature for this?

Wow, that's impressive.

I believe this discussion has happened before. I believe the conclusion
was that it's beyond the scope of SSHGuard to do reverse lookups and
block entire address ranges.

Now that SSHGuard is being split up into several helper programs this
might be doable as a sort of optional intermediate stage in the filter
pipeline. Lately I've been a bit busy so I won't be able to take a look,
but if someone's really interested in taking a whack at this I'd be
happy to help.

Best,
Kevin

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

Re: [SSHGuard-users] New Attack Signature

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

‎The data centers encourage "private links" since that get to sell more IP space. But the addresses can be anything on their ASN. ‎ 

‎http://stackoverflow.com/questions/13110386/ip-to-asn-mapping-algorithm

I guess the reverse mapping is doable, but at what cost?

BTW, I've never had sshguard find any funny business in my maillog, and it is being read as far as I can tell. That said, I would never use the same table to block ssh and email. There can be legitimate email coming from the same IP that is doing a dictionary attack on port 22. Worse yet, the IP that is dictionary attacking your email can also have legitimate email users on it. Other than the rate limiter in postfix, I'm pretty much exposed to these attacks. 

Now if sshguard detected an attack from postfix, it would make sense to block the IP from 22. That seems safe since the only way you would lock yourself out is if the attack came from behind your router, in which case you have real problems. 

  Original Message  
From: Mark Chen
Sent: Saturday, September 10, 2016 1:27 PM
To: ssh...@li...
Subject: [SSHGuard-users] New Attack Signature

Just found this in my logs. Notice that the spammer alternates among several addresses within the same class B network (in this case, two different class Bs) in order to avoid detection.

Any chance we could add a signature for this?

> Sep 10 19:11:00 smtp postfix/smtpd[27607]: connect from unknown[182.38.196.133]
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno

[SSHGuard-users] New Attack Signature

[Mark C. <pub...@ch...>]

Just found this in my logs.  Notice that the spammer alternates among several addresses within the same class B network (in this case, two different class Bs) in order to avoid detection.

Any chance we could add a signature for this?

> Sep 10 19:11:00 smtp postfix/smtpd[27607]: connect from unknown[182.38.196.133]
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno
> wn[182.38.196.133]
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.196.13
> 3] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: connect from unknown[182.38.137.123]
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno
> wn[182.38.137.123]
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.137.12
> 3] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:03 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.228]
> Sep 10 19:11:03 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno
> wn[182.38.149.228]
> Sep 10 19:11:03 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.228] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:04 smtp postfix/smtpd[27607]: connect from unknown[182.38.234.76]
> Sep 10 19:11:04 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.234.76]
> Sep 10 19:11:04 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.234.76] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:05 smtp postfix/smtpd[27607]: connect from unknown[182.38.134.177]
> Sep 10 19:11:05 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.134.177]
> Sep 10 19:11:05 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.134.177] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:17 smtp postfix/smtpd[27607]: connect from unknown[182.38.139.99]
> Sep 10 19:11:18 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.139.99]
> Sep 10 19:11:18 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.139.99] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:18 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.156]
> Sep 10 19:11:19 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.205.156]
> Sep 10 19:11:19 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.156] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:22 smtp postfix/smtpd[27607]: connect from unknown[123.170.207.50]
> Sep 10 19:11:23 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.207.50]
> Sep 10 19:11:23 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.207.50] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:24 smtp postfix/smtpd[27607]: connect from unknown[123.170.206.248]
> Sep 10 19:11:25 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.206.248]
> Sep 10 19:11:25 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.206.248] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:25 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.80]
> Sep 10 19:11:26 smtp postfix/smtpd[27607]: lost connection after EHLO from unknown[123.170.205.80]
> Sep 10 19:11:26 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.80] ehlo=1 commands=1
> Sep 10 19:11:30 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.234]
> Sep 10 19:11:30 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.149.234]
> Sep 10 19:11:30 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.234] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:31 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.156]
> Sep 10 19:11:32 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.205.156]
> Sep 10 19:11:32 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.156] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:32 smtp postfix/smtpd[27607]: connect from unknown[123.170.195.250]
> Sep 10 19:11:33 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.195.250]
> Sep 10 19:11:33 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.195.250] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:34 smtp postfix/smtpd[27607]: connect from unknown[123.170.241.118]
> Sep 10 19:11:35 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.241.118]
> Sep 10 19:11:35 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.241.118] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:35 smtp postfix/smtpd[27607]: connect from unknown[182.38.135.69]
> Sep 10 19:11:36 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.135.69]
> Sep 10 19:11:36 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.135.69] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:36 smtp postfix/smtpd[27607]: connect from unknown[182.38.138.76]
> Sep 10 19:11:36 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.138.76]
> Sep 10 19:11:36 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.138.76] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:37 smtp postfix/smtpd[27607]: connect from unknown[123.170.202.168]
> Sep 10 19:11:37 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.202.168]
> Sep 10 19:11:37 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.202.168] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:37 smtp postfix/smtpd[27607]: connect from unknown[182.38.137.123]
> Sep 10 19:11:38 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.137.123]
> Sep 10 19:11:38 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.137.123] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:38 smtp postfix/smtpd[27607]: connect from unknown[182.38.232.194]
> Sep 10 19:11:39 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.232.194]
> Sep 10 19:11:39 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.232.194] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:39 smtp postfix/smtpd[27607]: connect from unknown[182.38.195.172]
> Sep 10 19:11:39 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.195.172]
> Sep 10 19:11:39 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.195.172] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:40 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.228]
> Sep 10 19:11:41 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.149.228]
> Sep 10 19:11:41 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.228] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:41 smtp postfix/smtpd[27607]: connect from unknown[182.38.131.199]
> Sep 10 19:11:41 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.131.199]
> Sep 10 19:11:41 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.131.199] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:42 smtp postfix/smtpd[27607]: connect from unknown[182.38.233.22]
> Sep 10 19:11:42 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.233.22]

[SSHGuard-users] New Attack Signature

[Mark C. <pub...@ch...>]

Just found this in my logs.  Notice that the spammer alternates among several addresses within the same class B network (in this case, two different class Bs) in order to avoid detection.

Any chance we could add a signature for this?

> Sep 10 19:11:00 smtp postfix/smtpd[27607]: connect from unknown[182.38.196.133]
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno
> wn[182.38.196.133]
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.196.13
> 3] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: connect from unknown[182.38.137.123]
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno
> wn[182.38.137.123]
> Sep 10 19:11:01 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.137.12
> 3] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:03 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.228]
> Sep 10 19:11:03 smtp postfix/smtpd[27607]: lost connection after AUTH from unkno
> wn[182.38.149.228]
> Sep 10 19:11:03 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.228] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:04 smtp postfix/smtpd[27607]: connect from unknown[182.38.234.76]
> Sep 10 19:11:04 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.234.76]
> Sep 10 19:11:04 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.234.76] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:05 smtp postfix/smtpd[27607]: connect from unknown[182.38.134.177]
> Sep 10 19:11:05 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.134.177]
> Sep 10 19:11:05 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.134.177] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:17 smtp postfix/smtpd[27607]: connect from unknown[182.38.139.99]
> Sep 10 19:11:18 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.139.99]
> Sep 10 19:11:18 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.139.99] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:18 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.156]
> Sep 10 19:11:19 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.205.156]
> Sep 10 19:11:19 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.156] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:22 smtp postfix/smtpd[27607]: connect from unknown[123.170.207.50]
> Sep 10 19:11:23 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.207.50]
> Sep 10 19:11:23 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.207.50] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:24 smtp postfix/smtpd[27607]: connect from unknown[123.170.206.248]
> Sep 10 19:11:25 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.206.248]
> Sep 10 19:11:25 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.206.248] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:25 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.80]
> Sep 10 19:11:26 smtp postfix/smtpd[27607]: lost connection after EHLO from unknown[123.170.205.80]
> Sep 10 19:11:26 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.80] ehlo=1 commands=1
> Sep 10 19:11:30 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.234]
> Sep 10 19:11:30 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.149.234]
> Sep 10 19:11:30 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.234] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:31 smtp postfix/smtpd[27607]: connect from unknown[123.170.205.156]
> Sep 10 19:11:32 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.205.156]
> Sep 10 19:11:32 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.205.156] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:32 smtp postfix/smtpd[27607]: connect from unknown[123.170.195.250]
> Sep 10 19:11:33 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.195.250]
> Sep 10 19:11:33 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.195.250] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:34 smtp postfix/smtpd[27607]: connect from unknown[123.170.241.118]
> Sep 10 19:11:35 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.241.118]
> Sep 10 19:11:35 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.241.118] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:35 smtp postfix/smtpd[27607]: connect from unknown[182.38.135.69]
> Sep 10 19:11:36 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.135.69]
> Sep 10 19:11:36 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.135.69] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:36 smtp postfix/smtpd[27607]: connect from unknown[182.38.138.76]
> Sep 10 19:11:36 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.138.76]
> Sep 10 19:11:36 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.138.76] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:37 smtp postfix/smtpd[27607]: connect from unknown[123.170.202.168]
> Sep 10 19:11:37 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[123.170.202.168]
> Sep 10 19:11:37 smtp postfix/smtpd[27607]: disconnect from unknown[123.170.202.168] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:37 smtp postfix/smtpd[27607]: connect from unknown[182.38.137.123]
> Sep 10 19:11:38 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.137.123]
> Sep 10 19:11:38 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.137.123] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:38 smtp postfix/smtpd[27607]: connect from unknown[182.38.232.194]
> Sep 10 19:11:39 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.232.194]
> Sep 10 19:11:39 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.232.194] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:39 smtp postfix/smtpd[27607]: connect from unknown[182.38.195.172]
> Sep 10 19:11:39 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.195.172]
> Sep 10 19:11:39 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.195.172] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:40 smtp postfix/smtpd[27607]: connect from unknown[182.38.149.228]
> Sep 10 19:11:41 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.149.228]
> Sep 10 19:11:41 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.149.228] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:41 smtp postfix/smtpd[27607]: connect from unknown[182.38.131.199]
> Sep 10 19:11:41 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.131.199]
> Sep 10 19:11:41 smtp postfix/smtpd[27607]: disconnect from unknown[182.38.131.199] ehlo=1 auth=0/1 commands=1/2
> Sep 10 19:11:42 smtp postfix/smtpd[27607]: connect from unknown[182.38.233.22]
> Sep 10 19:11:42 smtp postfix/smtpd[27607]: lost connection after AUTH from unknown[182.38.233.22]

Re: [SSHGuard-users] Log entry

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

On 09/05/2016 05:16, Jos Chrispijn wrote:
> This is confusingas it reads that SSHGuard doesn't know whether it has
> been blocked or not ("should have been blocked" - human line
> interpretation).
> 
> Better(and more demanding) would be:
> Sep  5 13:23:56 ares sshguard[771]: 116.209.118.176: has already been
> blocked (forever)

Fixed and committed in 7fcc98d. Thanks!

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

[SSHGuard-users] Log entry

[Jos C. <ssh...@cl...>]

Dear team,

Just to request a slightly different line on blocking earlier blocked IP 
addresses:

Sep  5 13:23:56 ares kernel: Sep 5 13:23:56 ares sshguard[771]: 
blacklist: added 116.209.118.176
Sep  5 13:23:56 ares sshguard[771]: 116.209.118.176: blocking forever (3 
attacks in 7 secs, after 1 abuses over 7 secs)
Sep  5 13:23:56 ares kernel: Sep  5 13:23:56 ares sshguard[771]: 
116.209.118.176: blocking forever (3 attacks in 7 secs, after 1 abuses 
over 7 secs)

After blocking this ip you add this line:
Sep  5 13:23:56 ares sshguard[771]: 116.209.118.176: should already have 
been blocked
Sep  5 13:23:56 ares kernel: Sep  5 13:23:56 ares sshguard[771]: 
116.209.118.176: should already have been blocked

This is confusingas it reads that SSHGuard doesn't know whether it has 
been blocked or not ("should have been blocked" - human line 
interpretation).

Better(and more demanding) would be:
Sep  5 13:23:56 ares sshguard[771]: 116.209.118.176: has already been 
blocked (forever)

Just thinking with your,
Jos Chrispijn

[SSHGuard-users] Freebsd update to ‎ ‎sshguard-ipfw-1.7.0_1‎

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

‎Subject line says it all. 
‎
‎sshguard-ipfw-1.7.0_1‎

No problem compiling. 

Re: [SSHGuard-users] Block after one attack

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

On 08/29/2016 13:07, mai...@ne... wrote:
> maybe I did something stupid and I am not able to find the reason but after upgrading to SSHGuard 1.7.0 SSH is blocked after one wrong password input.
> 
> 
> Aug 29 21:52:27 abv sshguard[80566]: 91.10.95.96: blocking for 1200 secs (1 attacks in 0 secs, after 1 abuses over 0 secs)
> 
> sshguard_enable="YES"
> sshguard_safety_threshold="8"

sshguard_safety_threshold isn't read from the rc.d script.

> sshguard_danger_thresh="10"

This is your issue. The default is 30 (3 attempts).

Best,
Kevin

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

[SSHGuard-users] Block after one attack

[<mai...@ne...>]

Hello,

maybe I did something stupid and I am not able to find the reason but after upgrading to SSHGuard 1.7.0 SSH is blocked after one wrong password input.


Aug 29 21:52:27 abv sshguard[80566]: 91.10.95.96: blocking for 1200 secs (1 attacks in 0 secs, after 1 abuses over 0 secs)

sshguard_enable="YES"
sshguard_safety_threshold="8"
sshguard_danger_thresh="10"
sshguard_release_interval="600"
sshguard_reset_interval="7200"
sshguard_blacklist=30:/var/db/sshguard/blacklist.db
sshguard_watch_logs="/var/log/auth.log:/usr/jails/aaa/var/log/auth.log:/usr/jails/bbb/var/log/auth.log“

Is there anything I configured wrong ?

BR Marc

Re: [SSHGuard-users] SSHGuard 1.7.0 release announcement

[Mark F. <fe...@Fr...>]

> On Aug 29, 2016, at 13:02, Kevin Zheng <kev...@gm...> wrote:
> 
> On 08/29/2016 10:47, Mark Felder wrote:
>> Not sure. I was just looking for an easy hack for users of the hosts
>> backend.
> 
> If that's something people are interested in it would just involve
> translating the original hosts.c into a new sshg-fw backend.
> 
> 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 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. Do you know how
> people are usually using the hosts backend?
> 

Not sure. I've only seen one person that was using hosts file backend and noticed it is not available anymore.

--
  Mark Felder
  ports-secteam member
  fe...@Fr...

Re: [SSHGuard-users] SSHGuard 1.7.0 release announcement

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

On 08/29/2016 10:47, Mark Felder wrote:
> Not sure. I was just looking for an easy hack for users of the hosts
> backend.

If that's something people are interested in it would just involve
translating the original hosts.c into a new sshg-fw backend.

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 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. Do you know how
people are usually using the hosts backend?

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

Re: [SSHGuard-users] SSHGuard 1.7.0 release announcement

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

On 08/29/2016 10:49, Mark Felder wrote:
> On Mon, Aug 8, 2016, at 12:23, Kevin Zheng wrote:
>>
>>     Logsuck (-l option) is deprecated, use sshg-logtail instead
> 
> The problem I have with this is that now I have to provide a new rc
> script for users to have logtail, and users have to remember to start
> it. Would it be reasonable to just accept the -l option but internally
> fork off the sshg-logtail as a child process?

Yes, that's what's planned for the next version. Tentatively, the '-l'
flag will go away (replaced with positional arguments). Positional
arguments will be passed to a forked off sshg-logtail, and the regular
arguments will go to SSHGuard.

You can stick to '-l' if you haven't been having problems with it. It's
being taken out because it's had lots of bugs, from broken kqueue a
while ago to using uninitialized memory to infinite looping on systems
without a separate debug.log.

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

Re: [SSHGuard-users] SSHGuard 1.7.0 release announcement

[Mark F. <fe...@Fr...>]

On Mon, Aug 8, 2016, at 12:23, Kevin Zheng wrote:
>
>     Logsuck (-l option) is deprecated, use sshg-logtail instead

The problem I have with this is that now I have to provide a new rc
script for users to have logtail, and users have to remember to start
it. Would it be reasonable to just accept the -l option but internally
fork off the sshg-logtail as a child process?

-- 
  Mark Felder
  ports-secteam member
  fe...@Fr...

Re: [SSHGuard-users] SSHGuard 1.7.0 release announcement

[Mark F. <fe...@Fr...>]

On Mon, Aug 29, 2016, at 12:30, Kevin Zheng wrote:
> On 08/29/2016 10:18, Mark Felder wrote:
> >> Removed
> >>     Remove external hooks (-e option)
> > 
> > How does the Null backend work now?
> 
> The 'configure' script generates a sshg-fw that reads commands like
> 'block 1.2.3.4' but just prints the action instead of doing anything.
> 
> Instead of writing hooks, you can edit the sshg-fw script directly. In
> future versions the user should be able to provide a path to sshg-fw;
> right now the path is provided from the 'configure' script.
> 
> The situation now is kind of ugly (compile in a new path or edit the
> installed sshg-fw script). Suggestions?
> 

Not sure. I was just looking for an easy hack for users of the hosts
backend.


-- 
  Mark Felder
  ports-secteam member
  fe...@Fr...

Re: [SSHGuard-users] SSHGuard 1.7.0 release announcement

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

On 08/29/2016 10:18, Mark Felder wrote:
>> Removed
>>     Remove external hooks (-e option)
> 
> How does the Null backend work now?

The 'configure' script generates a sshg-fw that reads commands like
'block 1.2.3.4' but just prints the action instead of doing anything.

Instead of writing hooks, you can edit the sshg-fw script directly. In
future versions the user should be able to provide a path to sshg-fw;
right now the path is provided from the 'configure' script.

The situation now is kind of ugly (compile in a new path or edit the
installed sshg-fw script). Suggestions?

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

Re: [SSHGuard-users] SSHGuard 1.7.0 release announcement

[Mark F. <fe...@Fr...>]

On Mon, Aug 8, 2016, at 12:23, Kevin Zheng wrote:
> Greetings,
> 
> SSHGuard 1.7.0 is available:
> https://sourceforge.net/projects/sshguard/files/sshguard/1.7.0/
>
> 
> Removed
>     Remove external hooks (-e option)

How does the Null backend work now?

-- 
  Mark Felder
  ports-secteam member
  fe...@Fr...

[SSHGuard-users] Freebsd ssh guard 1.7

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

<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><style> body {  font-family: "Calibri","Slate Pro",sans-serif,"sans-serif"; color:#262626 }</style> </head> <body lang="en-US"><div>The latest rev it to ports. For some reason, "make" wouldn't make anything. I did a make clean, though in theory that shouldn't be necessary.&nbsp;</div><div><br></div><div>I've been running 1.7 for about a day and a half without incident. </div><div><br></div><div></div></body></html>