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