Menu
▾
▴
sshguard-users
|
From: Christopher E. <ce...@lc...> - 2018-11-02 11:16:16
|
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 |
|
From: Kevin Z. <kev...@gm...> - 2018-11-02 16:36:20
|
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 |
|
From: Ryan R. <rr...@ro...> - 2018-11-02 17:35:27
|
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! > |
|
From: Kevin Z. <kev...@gm...> - 2018-11-02 17:41:32
|
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 |
|
From: Ryan R. <rr...@ro...> - 2018-11-02 20:49:50
|
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 >> > |
|
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 |
|
From: Ryan R. <rr...@ro...> - 2018-11-02 21:19:54
|
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 >>>> > |
|
From: Christopher E. <ce...@lc...> - 2018-11-02 23:55:14
|
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 |
|
From: Ryan R. <rr...@ro...> - 2018-11-03 00:07:31
|
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 > |
|
From: Ryan R. <rr...@ro...> - 2018-11-03 00:10:20
|
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 > |
|
From: Shadowbq <sha...@gm...> - 2018-11-03 00:25:46
|
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 |
|
From: Ryan R. <rr...@ro...> - 2018-11-03 00:26:14
|
no On 11/2/2018 5:25 PM, Shadowbq wrote: > 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 |
|
From: Ryan R. <rr...@ro...> - 2018-11-03 00:28:25
|
Whoever the coward "shadowbq" is, I have used sshguard and may use it in the future. I have a right to investigate the integrity and technical competence of people making decisions about it's future. If you don't like this list you get lost. Ryan On 11/2/2018 5:26 PM, Ryan Root wrote: > no > > On 11/2/2018 5:25 PM, Shadowbq wrote: >> 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 > > > > _______________________________________________ > sshguard-users mailing list > ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > |
|
From: Chris J. <joh...@as...> - 2018-11-03 00:33:09
|
Please take this "discussion" to a slack channel or something. I (and probably many others on this list), do not find this a helpful discourse at all. Chris On Fri, Nov 2, 2018 at 5:28 PM Ryan Root <rr...@ro...> wrote: > Whoever the coward "shadowbq" is, > > I have used sshguard and may use it in the future. I have a right to > investigate the integrity and technical competence of people making > decisions about it's future. If you don't like this list you get lost. > > Ryan > > > On 11/2/2018 5:26 PM, Ryan Root wrote: > > no > > > > On 11/2/2018 5:25 PM, Shadowbq wrote: > >> 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 > > > > > > > > _______________________________________________ > > 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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X