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

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

[Shadowbq <sha...@gm...>]

Ryan

You are now trolling. Please be more respectful. 

- shadowbq

> On Nov 2, 2018, at 8:10 PM, Ryan Root <rr...@ro...> wrote:
> 
> Are you two some of the actual programmers on this project?  Not only do
> you not know what the hell you are talking about when you get caught in
> lie you make up a bunch of crap as if you are smarter than someone who
> caught you.
> 
>> On 11/2/2018 5:07 PM, Ryan Root wrote:
>> Bullshit!
>> 
>>> On 11/2/2018 4:55 PM, Christopher Engelhard wrote:
>>> Hi all,
>>> what Kevin has described is exactly what I meant. And no, that does not
>>> involve redefining 'ssh 22/tcp' as 'craftbeer' for the fun of it.
>>> Maybe me referencing "services" is what caused the confusion. 'Programs'
>>> might have been clearer - sshguard just happens to currently name what
>>> it matches a 'service'.
>>> 
>>> So, to hopefully fully clarify what I'm proposing:
>>> 1) sshguard does not match against services like IMAP/POP3/FTP etc., but
>>> against the log output of *programs* like Pure-FTPd or Postfix.
>>> 2) currently, it assigns each program whose log output it understands a
>>> number internally and reports this number in the logs. This is not very
>>> helpful to the user, who will probably not know that 'Attack from <IP>
>>> on service 320' refers to the Pure-FTPd FTP daemon.
>>> 3) I propose to instead log the actual name of the program as defined by
>>> upstream (I'm all in favour of following standards) instead, i.e.
>>> 'Attack from <IP> on Pure-FTPd'. If internally service ID numbers are
>>> still used, one could log these as well, e.g. '<name> (<number>')
>>> 
>>> If I understand you, Ryan, correctly, you're proposing logging standard
>>> internet service names instead, e.g. mapping internal matches for
>>> Dovecot, Courier, Exim to 'Attack on IMAP'/'... POP' etc., correct?
>>> 
>>> That is not without merit. However, this
>>> - would mean that the log no longer really represents what SSHGuard is
>>> actually doing, which is bad for tracking down errors when something
>>> doesn't work as expected
>>> - might not be possible in cases where one program handles multiple
>>> standard services (e.g. IMAP/POP/SMTP submission for Dovecot), depending
>>> on how exactly the given program decides to format its logs
>>> - would mean inconsistency or a significant loss of information in the
>>> special case of the various attacks of webservices - these would all be
>>> reported as "attack on www", as I don't think there is a RFC for the
>>> Django login page
>>> 
>>> It might be a good idea to include the service in the message, e.g.
>>> 'Attack on WWW (Wordpress)' or 'Attack on IMAP/POP (Dovecot)', though.
>>> 
>>> 
>>> I hope that clears things up.
>>> 
>>> Best,
>>> Christopher
>>> 
>>> 
>>> _______________________________________________
>>> sshguard-users mailing list
>>> ssh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>> 
>> 
>> 
>> _______________________________________________
>> sshguard-users mailing list
>> ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>> 
> 
> 
> 
> _______________________________________________
> 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?

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

Are you two some of the actual programmers on this project?  Not only do
you not know what the hell you are talking about when you get caught in
lie you make up a bunch of crap as if you are smarter than someone who
caught you.

On 11/2/2018 5:07 PM, Ryan Root wrote:
> Bullshit!
>
> On 11/2/2018 4:55 PM, Christopher Engelhard wrote:
>> Hi all,
>> what Kevin has described is exactly what I meant. And no, that does not
>> involve redefining 'ssh 22/tcp' as 'craftbeer' for the fun of it.
>> Maybe me referencing "services" is what caused the confusion. 'Programs'
>> might have been clearer - sshguard just happens to currently name what
>> it matches a 'service'.
>>
>> So, to hopefully fully clarify what I'm proposing:
>> 1) sshguard does not match against services like IMAP/POP3/FTP etc., but
>> against the log output of *programs* like Pure-FTPd or Postfix.
>> 2) currently, it assigns each program whose log output it understands a
>> number internally and reports this number in the logs. This is not very
>> helpful to the user, who will probably not know that 'Attack from <IP>
>> on service 320' refers to the Pure-FTPd FTP daemon.
>> 3) I propose to instead log the actual name of the program as defined by
>> upstream (I'm all in favour of following standards) instead, i.e.
>> 'Attack from <IP> on Pure-FTPd'. If internally service ID numbers are
>> still used, one could log these as well, e.g. '<name> (<number>')
>>
>> If I understand you, Ryan, correctly, you're proposing logging standard
>> internet service names instead, e.g. mapping internal matches for
>> Dovecot, Courier, Exim to 'Attack on IMAP'/'... POP' etc., correct?
>>
>> That is not without merit. However, this
>> - would mean that the log no longer really represents what SSHGuard is
>> actually doing, which is bad for tracking down errors when something
>> doesn't work as expected
>> - might not be possible in cases where one program handles multiple
>> standard services (e.g. IMAP/POP/SMTP submission for Dovecot), depending
>> on how exactly the given program decides to format its logs
>> - would mean inconsistency or a significant loss of information in the
>> special case of the various attacks of webservices - these would all be
>> reported as "attack on www", as I don't think there is a RFC for the
>> Django login page
>>
>> It might be a good idea to include the service in the message, e.g.
>> 'Attack on WWW (Wordpress)' or 'Attack on IMAP/POP (Dovecot)', though.
>>
>>
>> I hope that clears things up.
>>
>> Best,
>> Christopher
>>
>>
>> _______________________________________________
>> sshguard-users mailing list
>> ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>
>
>
> _______________________________________________
> 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?

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

Bullshit!

On 11/2/2018 4:55 PM, Christopher Engelhard wrote:
> Hi all,
> what Kevin has described is exactly what I meant. And no, that does not
> involve redefining 'ssh 22/tcp' as 'craftbeer' for the fun of it.
> Maybe me referencing "services" is what caused the confusion. 'Programs'
> might have been clearer - sshguard just happens to currently name what
> it matches a 'service'.
>
> So, to hopefully fully clarify what I'm proposing:
> 1) sshguard does not match against services like IMAP/POP3/FTP etc., but
> against the log output of *programs* like Pure-FTPd or Postfix.
> 2) currently, it assigns each program whose log output it understands a
> number internally and reports this number in the logs. This is not very
> helpful to the user, who will probably not know that 'Attack from <IP>
> on service 320' refers to the Pure-FTPd FTP daemon.
> 3) I propose to instead log the actual name of the program as defined by
> upstream (I'm all in favour of following standards) instead, i.e.
> 'Attack from <IP> on Pure-FTPd'. If internally service ID numbers are
> still used, one could log these as well, e.g. '<name> (<number>')
>
> If I understand you, Ryan, correctly, you're proposing logging standard
> internet service names instead, e.g. mapping internal matches for
> Dovecot, Courier, Exim to 'Attack on IMAP'/'... POP' etc., correct?
>
> That is not without merit. However, this
> - would mean that the log no longer really represents what SSHGuard is
> actually doing, which is bad for tracking down errors when something
> doesn't work as expected
> - might not be possible in cases where one program handles multiple
> standard services (e.g. IMAP/POP/SMTP submission for Dovecot), depending
> on how exactly the given program decides to format its logs
> - would mean inconsistency or a significant loss of information in the
> special case of the various attacks of webservices - these would all be
> reported as "attack on www", as I don't think there is a RFC for the
> Django login page
>
> It might be a good idea to include the service in the message, e.g.
> 'Attack on WWW (Wordpress)' or 'Attack on IMAP/POP (Dovecot)', though.
>
>
> I hope that clears things up.
>
> Best,
> Christopher
>
>
> _______________________________________________
> 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?

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

Hi all,
what Kevin has described is exactly what I meant. And no, that does not
involve redefining 'ssh 22/tcp' as 'craftbeer' for the fun of it.
Maybe me referencing "services" is what caused the confusion. 'Programs'
might have been clearer - sshguard just happens to currently name what
it matches a 'service'.

So, to hopefully fully clarify what I'm proposing:
1) sshguard does not match against services like IMAP/POP3/FTP etc., but
against the log output of *programs* like Pure-FTPd or Postfix.
2) currently, it assigns each program whose log output it understands a
number internally and reports this number in the logs. This is not very
helpful to the user, who will probably not know that 'Attack from <IP>
on service 320' refers to the Pure-FTPd FTP daemon.
3) I propose to instead log the actual name of the program as defined by
upstream (I'm all in favour of following standards) instead, i.e.
'Attack from <IP> on Pure-FTPd'. If internally service ID numbers are
still used, one could log these as well, e.g. '<name> (<number>')

If I understand you, Ryan, correctly, you're proposing logging standard
internet service names instead, e.g. mapping internal matches for
Dovecot, Courier, Exim to 'Attack on IMAP'/'... POP' etc., correct?

That is not without merit. However, this
- would mean that the log no longer really represents what SSHGuard is
actually doing, which is bad for tracking down errors when something
doesn't work as expected
- might not be possible in cases where one program handles multiple
standard services (e.g. IMAP/POP/SMTP submission for Dovecot), depending
on how exactly the given program decides to format its logs
- would mean inconsistency or a significant loss of information in the
special case of the various attacks of webservices - these would all be
reported as "attack on www", as I don't think there is a RFC for the
Django login page

It might be a good idea to include the service in the message, e.g.
'Attack on WWW (Wordpress)' or 'Attack on IMAP/POP (Dovecot)', though.


I hope that clears things up.

Best,
Christopher

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

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

Kevin,

It doesn't seem like your explanation at this point is at all a
reasonable interpretation of what Christopher originally wrote.  I don't
have an interest in dialoguing about this anymore.

Ryan

On 11/2/2018 2:05 PM, Kevin Zheng wrote:
> Ryan,
>
> To clarify:
>
> I echo your sentiments about following relevant Internet standards. We
> will keep standards in mind when making improvements to SSHGuard.
>
> Right now, we are discussing the representation of an internal data
> structure that'll make it easier for people to read their logs. To the
> best of my knowledge, no particular RFC specifies a protocol for
> handling internal data structures, because they are internal.
>
> These "service identifiers" are not mappings to port numbers, but rather
> classifiers for particular log messages; for instance, multiple
> implementations of IMAP servers use the standard IMAP protocol and port
> number. We are trying to represent the former, not latter.
>
> Should RFCs specify implementation details like how to represent
> enumerated types in computer programs, please do bring it to our attention.
>
> Thanks again,
> Kevin
>
> On 11/2/18 1:49 PM, Ryan Root wrote:
>> 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...>]

Ryan,

To clarify:

I echo your sentiments about following relevant Internet standards. We
will keep standards in mind when making improvements to SSHGuard.

Right now, we are discussing the representation of an internal data
structure that'll make it easier for people to read their logs. To the
best of my knowledge, no particular RFC specifies a protocol for
handling internal data structures, because they are internal.

These "service identifiers" are not mappings to port numbers, but rather
classifiers for particular log messages; for instance, multiple
implementations of IMAP servers use the standard IMAP protocol and port
number. We are trying to represent the former, not latter.

Should RFCs specify implementation details like how to represent
enumerated types in computer programs, please do bring it to our attention.

Thanks again,
Kevin

On 11/2/18 1:49 PM, Ryan Root wrote:
> 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
>>>
>>
> 


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

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