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

Re: [SSHGuard-users] Log human-readable service IDs instead of numbers?

[Ryan R. <rr...@ro...>]

Kevin,

If you are using "Internet" based services for what you are doing I
suggest you follow the rules in RFC's that outline how IANA, etc handle
these issues.  If you are running private networks for telecommuncations
services that don't need to be or use any Internet standards but are
fine if your customer do but won't help them police your customers or
are considering it then you probably shouldn't be the one to give IANA
and the IETF and ARIN, etc... a double handled middle fingers salute and
should leave that to an expert.

Ryan

On 11/2/2018 10:41 AM, Kevin Zheng wrote:
> Hi Ryan,
>
> While it might be useful to cross-reference these internal
> representations with an external database like /etc/services, right now
> we're just focused on the internal representation.
>
> There should be no functional change with this suggested change, except
> that the log messages get better because they would come up as readable
> strings instead of "service codes".
>
> Regards,
> Kevin
>
> On 11/2/18 10:35 AM, Ryan Root wrote:
>> Kevin,
>>
>> It would be a normal programming decision to decide to take that info
>> from a systems default "/etc/services" file which can be modified by a
>> user or look to other databases.  The decision to override or not
>> override a local system administrators decisions about modifications
>> that could be correct for common port names in services is one of the
>> programming and process issues that are considered with your question. 
>> At least with FreeBSD that is the default file location
>> "/etc/services".  However, until some of the things about fingering are
>> fixed in the default FreeBSD install in the hosts.allow file some are
>> not going to be able to use that database of service numbers to common
>> names.  However, keep in mind.  Those are just port numbers and can be
>> easily faked so it's only helpful to some degree...
>>
>> Does OpenBSD and other distributions have similar inappropriate finger
>> references in hosts.allow?
>>
>> Ryan
>>
>> On 11/2/2018 9:36 AM, Kevin Zheng wrote:
>>> On 11/2/18 3:59 AM, Christopher Engelhard wrote:
>>>> Hi,
>>>> currently, SSHGuard repots attacks as 'Attack from service <number> from
>>>> ...'. Though over time I have learned the numbers of the various
>>>> services, it would be much more helpful to the user if this were changed
>>>> to something like 'Attack from service <short service name> from ...'.
>>>>
>>>> AFAICT, SSHGuard mostly uses SERVICE_<NAME> constants internally anyway,
>>>> and those are assigned a number in attack.h.
>>>>
>>>> Is there a technical reason for mapping SERVICE_<NAME> to numbers
>>>> instead of a name? I'd be happy to attempt a patch to change this, but
>>>> of course only if it actually makes sense to do so.
>>> No technical reason, and it's a change we've discussed and wanted but
>>> just haven't gotten around to making. Go ahead if you'd like!
>>>
>>
>>
>> _______________________________________________
>> sshguard-users mailing list
>> ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>
>

Re: [SSHGuard-users] Log human-readable service IDs instead of numbers?

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

Hi Ryan,

While it might be useful to cross-reference these internal
representations with an external database like /etc/services, right now
we're just focused on the internal representation.

There should be no functional change with this suggested change, except
that the log messages get better because they would come up as readable
strings instead of "service codes".

Regards,
Kevin

On 11/2/18 10:35 AM, Ryan Root wrote:
> Kevin,
> 
> It would be a normal programming decision to decide to take that info
> from a systems default "/etc/services" file which can be modified by a
> user or look to other databases.  The decision to override or not
> override a local system administrators decisions about modifications
> that could be correct for common port names in services is one of the
> programming and process issues that are considered with your question. 
> At least with FreeBSD that is the default file location
> "/etc/services".  However, until some of the things about fingering are
> fixed in the default FreeBSD install in the hosts.allow file some are
> not going to be able to use that database of service numbers to common
> names.  However, keep in mind.  Those are just port numbers and can be
> easily faked so it's only helpful to some degree...
> 
> Does OpenBSD and other distributions have similar inappropriate finger
> references in hosts.allow?
> 
> Ryan
> 
> On 11/2/2018 9:36 AM, Kevin Zheng wrote:
>> On 11/2/18 3:59 AM, Christopher Engelhard wrote:
>>> Hi,
>>> currently, SSHGuard repots attacks as 'Attack from service <number> from
>>> ...'. Though over time I have learned the numbers of the various
>>> services, it would be much more helpful to the user if this were changed
>>> to something like 'Attack from service <short service name> from ...'.
>>>
>>> AFAICT, SSHGuard mostly uses SERVICE_<NAME> constants internally anyway,
>>> and those are assigned a number in attack.h.
>>>
>>> Is there a technical reason for mapping SERVICE_<NAME> to numbers
>>> instead of a name? I'd be happy to attempt a patch to change this, but
>>> of course only if it actually makes sense to do so.
>> No technical reason, and it's a change we've discussed and wanted but
>> just haven't gotten around to making. Go ahead if you'd like!
>>
> 
> 
> 
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
> 


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

Re: [SSHGuard-users] Log human-readable service IDs instead of numbers?

[Ryan R. <rr...@ro...>]

Kevin,

It would be a normal programming decision to decide to take that info
from a systems default "/etc/services" file which can be modified by a
user or look to other databases.  The decision to override or not
override a local system administrators decisions about modifications
that could be correct for common port names in services is one of the
programming and process issues that are considered with your question. 
At least with FreeBSD that is the default file location
"/etc/services".  However, until some of the things about fingering are
fixed in the default FreeBSD install in the hosts.allow file some are
not going to be able to use that database of service numbers to common
names.  However, keep in mind.  Those are just port numbers and can be
easily faked so it's only helpful to some degree...

Does OpenBSD and other distributions have similar inappropriate finger
references in hosts.allow?

Ryan

On 11/2/2018 9:36 AM, Kevin Zheng wrote:
> On 11/2/18 3:59 AM, Christopher Engelhard wrote:
>> Hi,
>> currently, SSHGuard repots attacks as 'Attack from service <number> from
>> ...'. Though over time I have learned the numbers of the various
>> services, it would be much more helpful to the user if this were changed
>> to something like 'Attack from service <short service name> from ...'.
>>
>> AFAICT, SSHGuard mostly uses SERVICE_<NAME> constants internally anyway,
>> and those are assigned a number in attack.h.
>>
>> Is there a technical reason for mapping SERVICE_<NAME> to numbers
>> instead of a name? I'd be happy to attempt a patch to change this, but
>> of course only if it actually makes sense to do so.
> No technical reason, and it's a change we've discussed and wanted but
> just haven't gotten around to making. Go ahead if you'd like!
>

Re: [SSHGuard-users] Log human-readable service IDs instead of numbers?

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

On 11/2/18 3:59 AM, Christopher Engelhard wrote:
> Hi,
> currently, SSHGuard repots attacks as 'Attack from service <number> from
> ...'. Though over time I have learned the numbers of the various
> services, it would be much more helpful to the user if this were changed
> to something like 'Attack from service <short service name> from ...'.
> 
> AFAICT, SSHGuard mostly uses SERVICE_<NAME> constants internally anyway,
> and those are assigned a number in attack.h.
> 
> Is there a technical reason for mapping SERVICE_<NAME> to numbers
> instead of a name? I'd be happy to attempt a patch to change this, but
> of course only if it actually makes sense to do so.

No technical reason, and it's a change we've discussed and wanted but
just haven't gotten around to making. Go ahead if you'd like!

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

[SSHGuard-users] Log human-readable service IDs instead of numbers?

[Christopher E. <ce...@lc...>]

Hi,
currently, SSHGuard repots attacks as 'Attack from service <number> from
...'. Though over time I have learned the numbers of the various
services, it would be much more helpful to the user if this were changed
to something like 'Attack from service <short service name> from ...'.

AFAICT, SSHGuard mostly uses SERVICE_<NAME> constants internally anyway,
and those are assigned a number in attack.h.

Is there a technical reason for mapping SERVICE_<NAME> to numbers
instead of a name? I'd be happy to attempt a patch to change this, but
of course only if it actually makes sense to do so.

Best,
Christopher

Re: [SSHGuard-users] Portscanners

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

<html><head><meta http-equiv="Content-Security-Policy" content="script-src 'self'; img-src * cid: data:;"><style id="outgoing-font-settings">#response_container_BBPPID{font-family: initial; font-size:initial; color: initial;}</style></head><body style="background-color: rgb(255, 255, 255); background-image: initial; line-height: initial;"><div id="response_container_BBPPID" style="outline:none;" dir="auto" contenteditable="false"> <div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"> The "anvil" feature of Postfix works well in throttling pesky servers.&nbsp;</div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">I don't use the email features of SSHGuard at all. Less is more. All I want are those useless ssh attempts throttled.&nbsp;</div>                                                                                                                                      <div name="BB10" id="response_div_spacer_BBPPID" dir="auto" style="width:100%;"> <br style="display:initial"></div>                            <div id="blackberry_signature_BBPPID" name="BB10" dir="auto">     <div id="_signaturePlaceholder_BBPPID" name="BB10" dir="auto"></div> </div></div><div id="_original_msg_header_BBPPID" dir="auto">                                                                                                                                             <table width="100%" style="background-color: white; border-spacing: 0px; display: table; outline: none;" contenteditable="false"><tbody><tr><td colspan="2" style="padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);">                           <div style="border-right: none; border-bottom: none; border-left: none; border-image: initial; border-top: 1pt solid rgb(181, 196, 223); padding: 3pt 0in 0in; font-family: Tahoma, &quot;BB Alpha Sans&quot;, &quot;Slate Pro&quot;; font-size: 10pt;">  <div id="from"><b>From:</b> ssh...@cl...</div><div id="sent"><b>Sent:</b> October 14, 2018 9:27 AM</div><div id="to"><b>To:</b> ssh...@li...; jse...@Li...</div><div id="subject"><b>Subject:</b> Re: [SSHGuard-users] Portscanners</div></div></td></tr></tbody></table> <br> </div><!--start of _originalContent --><div name="BB10" dir="auto" style="background-image: initial; line-height: initial; outline: none;" contenteditable="false"><div><div class="moz-cite-prefix">On 14-10-2018 15:43, Jim Seymour wrote:<br>
    </div><blockquote type="cite">Can sshguard
      do that? That would be pretty sophisticated rule
      <pre class="moz-quote-pre">interpretation.</pre>
    </blockquote><p>If the same IP address tries to connect 60 times in a minute
      there is definitely more going on than just a trial on error.<br>
    </p><p>CONNECT and DISCONNECT is a logic response to such 'initiatives'.
      In this case it is all about the number of tries per minute rather
      than the log display this causes.</p><p>&gt; Personally, I wouldn't worry about it.</p><p><br>
    </p><p>-- With both feed on the ground you will never make a step
      forward
    </p></div>
<!--end of _originalContent --></div></body></html>

Re: [SSHGuard-users] Portscanners

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

On 14-10-2018 15:43, Jim Seymour wrote:
> Can sshguard do that? That would be pretty sophisticated rule
> interpretation.

If the same IP address tries to connect 60 times in a minute there is 
definitely more going on than just a trial on error.

CONNECT and DISCONNECT is a logic response to such 'initiatives'. In 
this case it is all about the number of tries per minute rather than the 
log display this causes.

 > Personally, I wouldn't worry about it.


-- With both feed on the ground you will never make a step forward

Re: [SSHGuard-users] Portscanners

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

On Sat, 13 Oct 2018 11:38:20 -0700
Kevin Zheng <kev...@gm...> wrote:

> On 10/13/18 11:20 AM, Jos Chrispijn wrote:
> > Was this a stupid question or is there a way to solve this?
> > 
> > On 7-10-2018 16:41, Jos Chrispijn wrote:  
> >>
> >> Would it be possible to put this behaviour as being abusive and
> >> put on the blacklist as well?
> >>
> >> Oct  7 16:32:39 myserver postfix/postscreen[54284]: CONNECT from
> >> [221.225.107.228]:56134 to [x.x.x.x]:25
> >> Oct  7 16:32:40 myserver postfix/postscreen[54284]: DISCONNECT
> >> [221.225.107.228]:56134
> >> Oct  7 16:32:41 myserver postfix/postscreen[54284]: CONNECT from
> >> [221.225.107.228]:56149 to [x.x.x.x]:25
> >> Oct  7 16:32:42 myserver postfix/postscreen[54284]: DISCONNECT
> >> [221.225.107.228]:56149
> >> Oct  7 16:32:42 myserver postfix/postscreen[54284]: CONNECT from
> >> [221.225.107.228]:56168 to [1x.x.x.x]:25
> >> Oct  7 16:32:44 myserver postfix/postscreen[54284]: DISCONNECT
> >> [221.225.107.228]:56168
> >>
> >> thanks, Jos
>
> Not a stupid question; I (or someone else) just needs to sit down
> and write the rules for this new attack signature.
> 

CONNECT and DISCONNECT messages are normal.  They do not indicate an
authentication failure of any type.  To write a rule for this,
sshguard would have to be able to understand that "X number of
repeated CONNECT/DISCONNECT messages w/in one second of each other
is bad."

Can sshguard do that?  That would be pretty sophisticated rule
interpretation.

Besides which, a CONNECT, followed by an immediate DISCONNECT, is not
a *security* threat, per se.  In fact it might well be no more than
TCP stack or firewall brain-damage:

    http://postfix.1071664.n5.nabble.com/meaning-of-connect-immediately-followed-by-disconnect-in-mail-log-td32773.html

Personally, I wouldn't worry about it.

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

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

Not a stupid question; I (or someone else) just needs to sit down and
write the rules for this new attack signature.

On 10/13/18 11:20 AM, Jos Chrispijn wrote:
> Was this a stupid question or is there a way to solve this?
> 
> On 7-10-2018 16:41, Jos Chrispijn wrote:
>>
>> Would it be possible to put this behaviour as being abusive and put on
>> the blacklist as well?
>>
>> Oct  7 16:32:39 myserver postfix/postscreen[54284]: CONNECT from
>> [221.225.107.228]:56134 to [x.x.x.x]:25
>> Oct  7 16:32:40 myserver postfix/postscreen[54284]: DISCONNECT
>> [221.225.107.228]:56134
>> Oct  7 16:32:41 myserver postfix/postscreen[54284]: CONNECT from
>> [221.225.107.228]:56149 to [x.x.x.x]:25
>> Oct  7 16:32:42 myserver postfix/postscreen[54284]: DISCONNECT
>> [221.225.107.228]:56149
>> Oct  7 16:32:42 myserver postfix/postscreen[54284]: CONNECT from
>> [221.225.107.228]:56168 to [1x.x.x.x]:25
>> Oct  7 16:32:44 myserver postfix/postscreen[54284]: DISCONNECT
>> [221.225.107.228]:56168
>>
>> thanks, Jos
>>
> 
> 
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
> 


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

Re: [SSHGuard-users] Portscanners

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

Was this a stupid question or is there a way to solve this?

On 7-10-2018 16:41, Jos Chrispijn wrote:
>
> Would it be possible to put this behaviour as being abusive and put on 
> the blacklist as well?
>
> Oct  7 16:32:39 myserver postfix/postscreen[54284]: CONNECT from 
> [221.225.107.228]:56134 to [x.x.x.x]:25
> Oct  7 16:32:40 myserver postfix/postscreen[54284]: DISCONNECT 
> [221.225.107.228]:56134
> Oct  7 16:32:41 myserver postfix/postscreen[54284]: CONNECT from 
> [221.225.107.228]:56149 to [x.x.x.x]:25
> Oct  7 16:32:42 myserver postfix/postscreen[54284]: DISCONNECT 
> [221.225.107.228]:56149
> Oct  7 16:32:42 myserver postfix/postscreen[54284]: CONNECT from 
> [221.225.107.228]:56168 to [1x.x.x.x]:25
> Oct  7 16:32:44 myserver postfix/postscreen[54284]: DISCONNECT 
> [221.225.107.228]:56168
>
> thanks, Jos
>

[SSHGuard-users] Portscanners

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

Would it be possible to put this behaviour as being abusive and put on 
the blacklist as well?

Oct  7 16:32:39 myserver postfix/postscreen[54284]: CONNECT from 
[221.225.107.228]:56134 to [x.x.x.x]:25
Oct  7 16:32:40 myserver postfix/postscreen[54284]: DISCONNECT 
[221.225.107.228]:56134
Oct  7 16:32:41 myserver postfix/postscreen[54284]: CONNECT from 
[221.225.107.228]:56149 to [x.x.x.x]:25
Oct  7 16:32:42 myserver postfix/postscreen[54284]: DISCONNECT 
[221.225.107.228]:56149
Oct  7 16:32:42 myserver postfix/postscreen[54284]: CONNECT from 
[221.225.107.228]:56168 to [1x.x.x.x]:25
Oct  7 16:32:44 myserver postfix/postscreen[54284]: DISCONNECT 
[221.225.107.228]:56168

thanks, Jos

-- With both feed on the ground you will never make a step forward
	

Re: [SSHGuard-users] Blacklisting attempts on root?

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

On Fri, 5 Oct 2018 18:47:25 -0700
James Harris <jam...@gm...> wrote:

> I have had a similar idea about offline processing.  Instead of
> banning people that are trying to brute force with default
> usernames, I was thinking about blocking subnets or whole network
> providers by determine the AS (autonomous system) associated with
> the IP.
[snip]

The people who run the servers that supply the ASN data may not
appreciate the traffic if many people started doing that.

I used to run an automated blocklisting system that worked like this:

    . One (1) spam got you blocklisted for time T with a probationary
      period P
    . Repeated spams after T expired, but w/in P, re-blocklisted with
      incremented T and P
    . T would increment to infinity after N relistings
    . A script ran every 24 hours that would count the number of
      unique listed IP addresses w/in each /24.  More than X unique IP
      addresses w/in a /24 got the entire /24 listed.
    . I had two manual netblock lists:
        . A list that, any IP address w/in the list that spammed me
          earned immediate infinite listing
        . A manual list that was an immediate listing of the entire
          netblock

(I'd briefly considered the ASN thing, too.  But the ASN server abuse
thing was a bit of a show-stopper.)

Let me tell you how effective all that was: I stopped running it long
ago.  Of all the spam blocked by the various mechanisms I used, my
system accounted for a fraction of a percent.  (Mainly what all that
effort did was give me a heckuva education in some pretty nifty RDBMS
methods.)

I never got around to running an analysis of sshguard repeat
offenders on my systems, but, if the results of my efforts at creating
my own spam blocklist is any guide: Probably relatively low.  There
are *a lot* of IP addresses out there.

The truth is there are so many infected systems out there, so many
systems ripe for infection--due to poor code, poor administration or
both, and so many bad actors exploiting all that, that no automated
system beyond what sshguard is already doing will have much
incremental effect.

IMO: To *really* improve the efficacy of sshguard, many, many
instances of sshguard, across the 'net, would have to be "meshed."
Heuristics and trust mechanisms, similar to those employed by NTP,
would have to be developed.  (I actually once considered doing that
between my systems a few years ago.)

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] Blacklisting attempts on root?

[James H. <jam...@gm...>]

I have had a similar idea about offline processing.  Instead of banning
people that are trying to brute force with default usernames, I was
thinking about blocking subnets or whole network providers by determine the
AS (autonomous system) associated with the IP. I often see brute force
attempts originating by IPs close to each other.  The script would take a
look at all the IPs and suggest rules to block entire networks not only
would it be proactive against IPs likely to be used in the future for
attacks but it would also reduce the number of firewall rules thus taxing
the system less.

On Fri, Oct 5, 2018 at 6:30 PM @lbutlr <kr...@kr...> wrote:

> On 05 Oct 2018, at 11:38, @lbutlr <kr...@kr...> wrote:
> > I’m more comfortable writing a bash script to run on occasion and add
> the IPs to the blacklist myself, but I don’t know how sshguard tracks the
> permanent list as opposed to the timed list.
>
> I have a cunning plan.<1>
>
> If I use a facility like log rotate to create multiple log lines for the
> connection attempts I want to permaban, will sshguard be fooled into seeing
> one attempt as, say, 16 attempts in the same second?
>
> <1> http://blackadderquotes.com/i-have-a-cunning-plan
>
> --
> All great truths begin as blasphemies.
>
>
>
>
>
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>


-- 
James Harris
Software Engineer
jam...@gm...

Re: [SSHGuard-users] Blacklisting attempts on root?

[@lbutlr <kr...@kr...>]

On 05 Oct 2018, at 11:38, @lbutlr <kr...@kr...> wrote:
> I’m more comfortable writing a bash script to run on occasion and add the IPs to the blacklist myself, but I don’t know how sshguard tracks the permanent list as opposed to the timed list.

I have a cunning plan.<1>

If I use a facility like log rotate to create multiple log lines for the connection attempts I want to permaban, will sshguard be fooled into seeing one attempt as, say, 16 attempts in the same second?

<1> http://blackadderquotes.com/i-have-a-cunning-plan

-- 
All great truths begin as blasphemies.

Re: [SSHGuard-users] Blacklisting attempts on root?

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

On 10/5/18 10:38 AM, @lbutlr wrote:
> On 05 Oct 2018, at 10:31, Kevin Zheng <kev...@gm...> wrote:
>> If you're comfortable compiling from source I can help you hack
>> this together and see how well it works.
> 
> I’m more comfortable writing a bash script to run on occasion and add
> the IPs to the blacklist myself, but I don’t know how sshguard tracks
> the permanent list as opposed to the timed list.

That doesn't make a difference, the username detection would currently
require a compile-time change.

There's a planned change from the permanent list vs timed list to one
persistent list, and I can put more work into that if there's actually
interest.

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

Re: [SSHGuard-users] Blacklisting attempts on root?

[@lbutlr <kr...@kr...>]

On 05 Oct 2018, at 10:31, Kevin Zheng <kev...@gm...> wrote:
> If you're comfortable compiling from source I can help you hack this
> together and see how well it works.

I’m more comfortable writing a bash script to run on occasion and add the IPs to the blacklist myself, but I don’t know how sshguard tracks the permanent list as opposed to the timed list.

-- 
Nothing like grilling a kosher dog over human hair to bring out the
subtle flavors.

Re: [SSHGuard-users] Blacklisting attempts on root?

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

On 10/4/18 5:01 PM, @lbutlr wrote:
> Is it possible to confuse sshguard to instantly block anyone  who tries to login as ‘root’ or ‘admin’ or some predefined list of users? There is no possibility that any legitimate connection will ever try to logon as root, admin, toor, user*, pi, guest, test, Dave, sshuser, ftpuser, and quite a few others that I see over and over again.
> 
> Anyone who tries to ssh in as one of these accounts I just want permabanned.
> 
> Possible?

Currently, no. But it wouldn't be too hard to hack together.

It'd be slightly harder to get this working nice with the rest of
SSHGuard; specifically, not requiring you to recompile to enable/disable
this functionality and change the list of blacklisted users.

If you're comfortable compiling from source I can help you hack this
together and see how well it works.

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

[SSHGuard-users] Blacklisting attempts on root?

[@lbutlr <kr...@kr...>]

Is it possible to confuse sshguard to instantly block anyone  who tries to login as ‘root’ or ‘admin’ or some predefined list of users? There is no possibility that any legitimate connection will ever try to logon as root, admin, toor, user*, pi, guest, test, Dave, sshuser, ftpuser, and quite a few others that I see over and over again.

Anyone who tries to ssh in as one of these accounts I just want permabanned.

Possible?

-- 
The "H" in Jesus H Christ comes from "Harold be Thy name" in the Lord's
Prayer.

Re: [SSHGuard-users] More debugging output

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

On 9/28/18 1:28 AM, Frank Steiner wrote:
>> Have you tried running sshg-parser in libexec? The output is currently a
>> bit cryptic, but it'll tell you which rule was matched.
> 
> Hmm, if I feed journalctl to sshg-parser I only get lines like
> 100 x.x.x.x 4 10
> 100 x.x.x.x 4 3
> 
> These are two different rules, the first one is the unknown user, the
> second one the maximum reached as I patched that one to score 3.

Sorry, it's not indicating which rule is being matched. 100 is just a
code corresponding to a service defined in src/common/attack.h.

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

Re: [SSHGuard-users] More debugging output

[Frank S. <fst...@bi...>]

Kevin Zheng wrote:

> On 9/27/18 2:55 AM, Frank Steiner wrote:
>> Hi,
>>
>> just a little proposal for an improvment: trying to figure out why certain
>> actions get the matches/score they do, it would be very helpful if the
>> "Attack from..." messages could contain the rule that matched. Like
>> "Attack from xxx on service 100 (SSH_MAXAUTH) with danger.."
>>
>> I had to patch that myself to figure out why so many rules matched
>> for my ssh, but I just added stupid print statements in attack_scanner.c,
>> so I cannot offer a valid patch for this.
> 
> Have you tried running sshg-parser in libexec? The output is currently a
> bit cryptic, but it'll tell you which rule was matched.

Hmm, if I feed journalctl to sshg-parser I only get lines like
100 x.x.x.x 4 10
100 x.x.x.x 4 3

These are two different rules, the first one is the unknown user, the
second one the maximum reached as I patched that one to score 3.

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] More debugging output

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

On 9/27/18 2:55 AM, Frank Steiner wrote:
> Hi,
> 
> just a little proposal for an improvment: trying to figure out why certain
> actions get the matches/score they do, it would be very helpful if the
> "Attack from..." messages could contain the rule that matched. Like
> "Attack from xxx on service 100 (SSH_MAXAUTH) with danger.."
> 
> I had to patch that myself to figure out why so many rules matched
> for my ssh, but I just added stupid print statements in attack_scanner.c,
> so I cannot offer a valid patch for this.

Have you tried running sshg-parser in libexec? The output is currently a
bit cryptic, but it'll tell you which rule was matched.

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

[SSHGuard-users] More debugging output

[Frank S. <fst...@bi...>]

Hi,

just a little proposal for an improvment: trying to figure out why certain
actions get the matches/score they do, it would be very helpful if the
"Attack from..." messages could contain the rule that matched. Like
"Attack from xxx on service 100 (SSH_MAXAUTH) with danger.."

I had to patch that myself to figure out why so many rules matched
for my ssh, but I just added stupid print statements in attack_scanner.c,
so I cannot offer a valid patch for this.

cu,
Frank


-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] Scoring problems

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

Hi Frank,

Thanks for the comments.

On 9/26/18 7:38 AM, Frank Steiner wrote:
> Thus, four attacks with score 10 each are counted, giving a score of 40
> for two wrong passwords. That happens because in addition to the two
> wrong passwords (SSH_LOGINERR_PAM, I've patched the scanner to see
> which rules matched) sshguard also counts the "maximum authentication
> attempts exceeded" (ssh_maxauth) and the "Failed keyboard-interactive/pam
> for someuser" (SSH_LOGINERR_PREF).
> 
> This really makes it hard to configure sshguard in a reasonable way.
> Two wrong ftp passwords are score 20, two wrong ssh passwords are
> 40. For my config it wouldn't be neccessary to count the
> "failed keyboard-interactive" or the "max attempts" when I already
> count each wrong password.

I agree this is bad.

> I saw in the comments that the rule SSH_LOGINERR_PREF was meant for
> Ubuntu, the SSH_LOGINERR_PAM for FreeBSD/Debian, but for our SuSE
> system they match both.

As you point out, it's hard to keep the rules generally applicable but
also avoid duplicates.

> I see only two ways to solve this problem in general: Either you
> define groups of commands that mean the same  and are only counted
> as one attack. But it might  be very hard to figure out e.g which
> pam messages belong to with sshd parent process if several connections
> are done in parallel.

Exactly.

> Or you allow users to define which rules should be counted with
> which score in the config file. E.g. setting sth. likle this
> in sshguard.conf:
> 
> SSH_LOGINERR_PREF=0
> SSH_MAXAUTH=3
> 
> That would sshguard cause to ignore the "Failed keyboard-interactive/pam"
> and counting the "max attempt" message with score 3 only.
> 
> This would allow every admin to adjust scoring to his/her specific
> needs, even different settings for several hosts.

Perhaps this is the better solution.

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

[SSHGuard-users] Scoring problems

[Frank S. <fst...@bi...>]

Hi,

trying to make my sshguard config valid against the currently running
ssh attacks I stepped again on the problem of multiple counts of the
same action with ssh.

Here's an example. Our ssh config has MaxAuthTries=3. Invalid ssh keys
are counted as failed try and our default is that every user has one
key for hosts inside our network. For some hosts keys are not allowed,
so ssh will accept two password tries to login.

Assuming that both are wrong, here's what journalctl shows:

Sep 26 16:14:33 galois sshd[19429]: Postponed keyboard-interactive for someuser from x.x.x.x port 39022 ssh2 [preauth]
Sep 26 16:14:36 myhost sshd[19431]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=someuser
Sep 26 16:14:38 myhost sshd[19429]: error: PAM: Authentication failure for someuser from x.x.x.x
Sep 26 16:14:38 myhost sshguard[17898]: matched SSH_LOGINERR_PAM
Sep 26 16:14:38 myhost sshguard[17903]: Attack from "x.x.x.x" on service 100 with danger 10.
Sep 26 16:14:38 myhost sshd[19429]: Postponed keyboard-interactive for someuser from x.x.x.x port 39022 ssh2 [preauth]
Sep 26 16:14:38 myhost sshd[19434]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=someuser
Sep 26 16:14:40 myhost sshd[19429]: error: PAM: Authentication failure for someuser from x.x.x.x
Sep 26 16:14:40 myhost sshd[19429]: Failed keyboard-interactive/pam for someuser from x.x.x.x port 39022 ssh2
Sep 26 16:14:40 myhost sshguard[17903]: Attack from "x.x.x.x" on service 100 with danger 10.
Sep 26 16:14:40 myhost sshd[19429]: error: maximum authentication attempts exceeded for someuser from x.x.x.x port 39022 ssh2 [preauth]
Sep 26 16:14:40 myhost sshd[19429]: Disconnecting: Too many authentication failures [preauth]
Sep 26 16:14:40 myhost sshguard[17903]: Attack from "x.x.x.x" on service 100 with danger 10.
Sep 26 16:14:40 myhost sshguard[17898]: matched SSH_LOGINERR_PAM
Sep 26 16:14:40 myhost sshguard[17898]: matched SSH_LOGINERR_PREF
Sep 26 16:14:40 myhost sshguard[17898]: matched SSH_ADDR_SUFF
Sep 26 16:14:40 myhost sshguard[17898]: matched ssh_maxauth
Sep 26 16:14:40 myhost sshguard[17898]: matched SSH_ADDR_SUFF
Sep 26 16:14:40 myhost sshguard[17903]: Attack from "x.x.x.x" on service 100 with danger 10.


Thus, four attacks with score 10 each are counted, giving a score of 40
for two wrong passwords. That happens because in addition to the two
wrong passwords (SSH_LOGINERR_PAM, I've patched the scanner to see
which rules matched) sshguard also counts the "maximum authentication
attempts exceeded" (ssh_maxauth) and the "Failed keyboard-interactive/pam
for someuser" (SSH_LOGINERR_PREF).

This really makes it hard to configure sshguard in a reasonable way.
Two wrong ftp passwords are score 20, two wrong ssh passwords are
40. For my config it wouldn't be neccessary to count the
"failed keyboard-interactive" or the "max attempts" when I already
count each wrong password.

I saw in the comments that the rule SSH_LOGINERR_PREF was meant for
Ubuntu, the SSH_LOGINERR_PAM for FreeBSD/Debian, but for our SuSE
system they match both.

I see only two ways to solve this problem in general: Either you
define groups of commands that mean the same  and are only counted
as one attack. But it might  be very hard to figure out e.g which
pam messages belong to with sshd parent process if several connections
are done in parallel.

Or you allow users to define which rules should be counted with
which score in the config file. E.g. setting sth. likle this
in sshguard.conf:

SSH_LOGINERR_PREF=0
SSH_MAXAUTH=3

That would sshguard cause to ignore the "Failed keyboard-interactive/pam"
and counting the "max attempt" message with score 3 only.

This would allow every admin to adjust scoring to his/her specific
needs, even different settings for several hosts.

cu,
Frank


-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] configure-script does not honour --libexecprefix

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

On 9/18/18 5:57 AM, Christopher Engelhard wrote:
> I'm trying to install sshguard to a non-standard location and stumbled
> upon the following problem: When setting the location using ./configure
> --prefix=<location>, sshguard installs to the specified path, but when
> executed looks for the sshg-...-binaries in /usr/local/libexec
> nonetheless. The same happens when the various paths are specified
> individually via --libexecdir=... etc. This appears to exclusively
> affect libexecdir, not e.g. sysconfdir.
> 
> Running sshguard-2.2.0 on Fedora Server 28
> Steps to reproduce:
> 1) Run ./configure --prefix=/opt && make && make install
> 2) copy example config file to /opt/etc/sshguard.conf and set backend
> 3) execute /opt/sbin/sshguard
> 
> SSHGuard will fail with the following error:
> "sshguard: '/usr/local/libexec/sshg-fw-iptables' is not executable"

Could you show your sshguard.conf?

I suspect what happened here is that you uncommented the default BACKEND
without changing it.

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