From: Kevin Z. <kev...@gm...> - 2018-11-02 21:05:32
|
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 |