Menu
▾
▴
sshguard-users — User questions and answers, bugs, and general support
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
(10) |
Apr
(7) |
May
(6) |
Jun
(13) |
Jul
(4) |
Aug
|
Sep
|
Oct
(17) |
Nov
(5) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
(7) |
Jul
(10) |
Aug
(4) |
Sep
(14) |
Oct
|
Nov
(1) |
Dec
(7) |
| 2009 |
Jan
(17) |
Feb
(20) |
Mar
(11) |
Apr
(14) |
May
(8) |
Jun
(3) |
Jul
(22) |
Aug
(9) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
(8) |
| 2010 |
Jan
(17) |
Feb
(9) |
Mar
(15) |
Apr
(24) |
May
(14) |
Jun
(1) |
Jul
(21) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(6) |
Dec
(9) |
| 2011 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(29) |
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(13) |
May
(4) |
Jun
(9) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(11) |
Dec
(4) |
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
(4) |
Apr
(13) |
May
(4) |
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(3) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(6) |
May
(8) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(14) |
Dec
(8) |
| 2015 |
Jan
(16) |
Feb
(30) |
Mar
(20) |
Apr
(5) |
May
(33) |
Jun
(11) |
Jul
(15) |
Aug
(91) |
Sep
(23) |
Oct
(10) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(22) |
Feb
(8) |
Mar
(6) |
Apr
(23) |
May
(38) |
Jun
(29) |
Jul
(43) |
Aug
(43) |
Sep
(18) |
Oct
(8) |
Nov
(2) |
Dec
(25) |
| 2017 |
Jan
(38) |
Feb
(3) |
Mar
(1) |
Apr
|
May
(18) |
Jun
(2) |
Jul
(16) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(14) |
| 2018 |
Jan
(15) |
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
(8) |
Jun
(12) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(13) |
Nov
(15) |
Dec
(10) |
| 2019 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(5) |
Sep
(5) |
Oct
(12) |
Nov
(4) |
Dec
|
| 2020 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
|
May
(11) |
Jun
(1) |
Jul
(3) |
Aug
(22) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
|
| 2021 |
Jan
(7) |
Feb
|
Mar
(19) |
Apr
|
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(17) |
Feb
|
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(15) |
Apr
(8) |
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <li...@la...> - 2019-01-08 07:05:14
|
Those dynamic IP addresses can be filtered in postfix. I set this up so long ago that I don't recall the details, but this is the relevant line in postfix main.cf: check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre Google digs up: http://postfix.1071664.n5.nabble.com/New-approach-with-fqrdns-pcre-file-td90262.html https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre If the original poster goes this route, I would suggest consulting the postfix mailing list. On Mon, 7 Jan 2019 23:24:54 -0600 Kevin Zheng <kev...@gm...> wrote: > Hi Mario, > > Sure. Could you explain, or point me to some documentation, that > explains what that message means? > > From taking a cursory look, it looks like postfix got HELO/ELHO, did > not authenticate, and the client quit? > > We're also interested in avoiding false positives. Could a legitimate > client also generate that message? > > Regards, > Kevin > > On 1/3/19 2:12 AM, Mario B wrote: > > > > Hi, > > > > Would it be possible to block IP addresses from bots that are only > > trying to connect and stop at the auth. > > Usually the pattern is "helo=1 auth=0/1 quit=1 commands=2/3" > > > > > > postfix log excerpt: > > > > Jan 3 07:08:58 xyz postfix/smtpd[64504]: connect from > > 59-124-9-251.HINET-IP.hinet.net[59.124.9.251] > > Jan 3 07:08:59 xyz postfix/smtpd[64504]: disconnect from > > 59-124-9-251.HINET-IP.hinet.net[59.124.9.251] helo=1 auth=0/1 > > quit=1 commands=2/3 > > Jan 3 07:10:47 xyz postfix/smtpd[64504]: connect from > > 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] > > Jan 3 07:10:47 xyz postfix/smtpd[64504]: disconnect from > > 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] helo=1 > > auth=0/1 quit=1 commands=2/3 > > Jan 3 07:12:57 xyz postfix/smtpd[64523]: connect from > > 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] > > Jan 3 07:12:58 xyz postfix/smtpd[64523]: disconnect from > > 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] helo=1 > > auth=0/1 quit=1 commands=2/3 > > Jan 3 07:22:03 xyz postfix/smtpd[64595]: connect from > > cmr-208-124-188-202.cr.net.cable.rogers.com[208.124.188.202] > > Jan 3 07:22:04 xyz postfix/smtpd[64595]: disconnect from > > cmr-208-124-188-202.cr.net.cable.rogers.com[208.124.188.202] helo=1 > > auth=0/1 quit=1 commands=2/3 > > Jan 3 07:33:12 xyz postfix/smtpd[64632]: connect from > > 202077050129.static.ctinets.com[202.77.50.129] > > Jan 3 07:33:13 xyz postfix/smtpd[64632]: disconnect from > > 202077050129.static.ctinets.com[202.77.50.129] helo=1 auth=0/1 > > quit=1 commands=2/3 > > Jan 3 07:42:05 xyz postfix/smtpd[64649]: connect from > > 218.221.208.186.yukanet.com.br[186.208.221.218] > > Jan 3 07:42:05 xyz postfix/smtpd[64649]: disconnect from > > 218.221.208.186.yukanet.com.br[186.208.221.218] helo=1 auth=0/1 > > quit=1 commands=2/3 > > Jan 3 07:46:12 xyz postfix/smtpd[64671]: connect from > > 220-130-140-22.HINET-IP.hinet.net[220.130.140.22] > > Jan 3 07:46:13 xyz postfix/smtpd[64671]: disconnect from > > 220-130-140-22.HINET-IP.hinet.net[220.130.140.22] helo=1 auth=0/1 > > quit=1 commands=2/3 > > Jan 3 07:48:21 xyz postfix/smtpd[64674]: connect from > > 210.67.144.52.cust.ip.kpnqwest.it[52.144.67.210] > > Jan 3 07:48:21 xyz postfix/smtpd[64674]: disconnect from > > 210.67.144.52.cust.ip.kpnqwest.it[52.144.67.210] helo=1 auth=0/1 > > quit=1 commands=2/3 > > > > > > > > > > Regards, > > Mario > > > > > > > > _______________________________________________ > > sshguard-users mailing list > > ssh...@li... > > https://lists.sourceforge.net/lists/listinfo/sshguard-users > > |
|
From: Kevin Z. <kev...@gm...> - 2019-01-08 05:25:18
|
Hi Mario, Sure. Could you explain, or point me to some documentation, that explains what that message means? From taking a cursory look, it looks like postfix got HELO/ELHO, did not authenticate, and the client quit? We're also interested in avoiding false positives. Could a legitimate client also generate that message? Regards, Kevin On 1/3/19 2:12 AM, Mario B wrote: > > Hi, > > Would it be possible to block IP addresses from bots that are only > trying to connect and stop at the auth. > Usually the pattern is "helo=1 auth=0/1 quit=1 commands=2/3" > > > postfix log excerpt: > > Jan 3 07:08:58 xyz postfix/smtpd[64504]: connect from > 59-124-9-251.HINET-IP.hinet.net[59.124.9.251] > Jan 3 07:08:59 xyz postfix/smtpd[64504]: disconnect from > 59-124-9-251.HINET-IP.hinet.net[59.124.9.251] helo=1 auth=0/1 quit=1 > commands=2/3 > Jan 3 07:10:47 xyz postfix/smtpd[64504]: connect from > 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] > Jan 3 07:10:47 xyz postfix/smtpd[64504]: disconnect from > 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] helo=1 > auth=0/1 quit=1 commands=2/3 > Jan 3 07:12:57 xyz postfix/smtpd[64523]: connect from > 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] > Jan 3 07:12:58 xyz postfix/smtpd[64523]: disconnect from > 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] helo=1 > auth=0/1 quit=1 commands=2/3 > Jan 3 07:22:03 xyz postfix/smtpd[64595]: connect from > cmr-208-124-188-202.cr.net.cable.rogers.com[208.124.188.202] > Jan 3 07:22:04 xyz postfix/smtpd[64595]: disconnect from > cmr-208-124-188-202.cr.net.cable.rogers.com[208.124.188.202] helo=1 > auth=0/1 quit=1 commands=2/3 > Jan 3 07:33:12 xyz postfix/smtpd[64632]: connect from > 202077050129.static.ctinets.com[202.77.50.129] > Jan 3 07:33:13 xyz postfix/smtpd[64632]: disconnect from > 202077050129.static.ctinets.com[202.77.50.129] helo=1 auth=0/1 quit=1 > commands=2/3 > Jan 3 07:42:05 xyz postfix/smtpd[64649]: connect from > 218.221.208.186.yukanet.com.br[186.208.221.218] > Jan 3 07:42:05 xyz postfix/smtpd[64649]: disconnect from > 218.221.208.186.yukanet.com.br[186.208.221.218] helo=1 auth=0/1 quit=1 > commands=2/3 > Jan 3 07:46:12 xyz postfix/smtpd[64671]: connect from > 220-130-140-22.HINET-IP.hinet.net[220.130.140.22] > Jan 3 07:46:13 xyz postfix/smtpd[64671]: disconnect from > 220-130-140-22.HINET-IP.hinet.net[220.130.140.22] helo=1 auth=0/1 quit=1 > commands=2/3 > Jan 3 07:48:21 xyz postfix/smtpd[64674]: connect from > 210.67.144.52.cust.ip.kpnqwest.it[52.144.67.210] > Jan 3 07:48:21 xyz postfix/smtpd[64674]: disconnect from > 210.67.144.52.cust.ip.kpnqwest.it[52.144.67.210] helo=1 auth=0/1 quit=1 > commands=2/3 > > > > > Regards, > Mario > > > > _______________________________________________ > sshguard-users mailing list > ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Mario B <ma...@su...> - 2019-01-03 08:33:00
|
Hi, Would it be possible to block IP addresses from bots that are only trying to connect and stop at the auth. Usually the pattern is "helo=1 auth=0/1 quit=1 commands=2/3" postfix log excerpt: Jan 3 07:08:58 xyz postfix/smtpd[64504]: connect from 59-124-9-251.HINET-IP.hinet.net[59.124.9.251] Jan 3 07:08:59 xyz postfix/smtpd[64504]: disconnect from 59-124-9-251.HINET-IP.hinet.net[59.124.9.251] helo=1 auth=0/1 quit=1 commands=2/3 Jan 3 07:10:47 xyz postfix/smtpd[64504]: connect from 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] Jan 3 07:10:47 xyz postfix/smtpd[64504]: disconnect from 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] helo=1 auth=0/1 quit=1 commands=2/3 Jan 3 07:12:57 xyz postfix/smtpd[64523]: connect from 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] Jan 3 07:12:58 xyz postfix/smtpd[64523]: disconnect from 148.red-79-158-248.dynamicip.rima-tde.net[79.158.248.148] helo=1 auth=0/1 quit=1 commands=2/3 Jan 3 07:22:03 xyz postfix/smtpd[64595]: connect from cmr-208-124-188-202.cr.net.cable.rogers.com[208.124.188.202] Jan 3 07:22:04 xyz postfix/smtpd[64595]: disconnect from cmr-208-124-188-202.cr.net.cable.rogers.com[208.124.188.202] helo=1 auth=0/1 quit=1 commands=2/3 Jan 3 07:33:12 xyz postfix/smtpd[64632]: connect from 202077050129.static.ctinets.com[202.77.50.129] Jan 3 07:33:13 xyz postfix/smtpd[64632]: disconnect from 202077050129.static.ctinets.com[202.77.50.129] helo=1 auth=0/1 quit=1 commands=2/3 Jan 3 07:42:05 xyz postfix/smtpd[64649]: connect from 218.221.208.186.yukanet.com.br[186.208.221.218] Jan 3 07:42:05 xyz postfix/smtpd[64649]: disconnect from 218.221.208.186.yukanet.com.br[186.208.221.218] helo=1 auth=0/1 quit=1 commands=2/3 Jan 3 07:46:12 xyz postfix/smtpd[64671]: connect from 220-130-140-22.HINET-IP.hinet.net[220.130.140.22] Jan 3 07:46:13 xyz postfix/smtpd[64671]: disconnect from 220-130-140-22.HINET-IP.hinet.net[220.130.140.22] helo=1 auth=0/1 quit=1 commands=2/3 Jan 3 07:48:21 xyz postfix/smtpd[64674]: connect from 210.67.144.52.cust.ip.kpnqwest.it[52.144.67.210] Jan 3 07:48:21 xyz postfix/smtpd[64674]: disconnect from 210.67.144.52.cust.ip.kpnqwest.it[52.144.67.210] helo=1 auth=0/1 quit=1 commands=2/3 Regards, Mario |
|
From: Alan A. <al...@an...> - 2019-01-01 23:32:29
|
On 01 Jan 2019, at 06:10, ssh...@li... wrote: [snip] > From: Doug Denault <do...@sa...> [snip] > The way FreeBSD jails work, is that the guest hosts share the kernel with the > base system. At the process level this is "virtually" invisible to running > process. There are some commands that depend on kernel structures that do not > work. Anyway the result of this is there can only be one IPFW as that is a > kernel process. So inetd is the only choice using sshguard. I much prefer > sshguard to fail2ban which is far too complex for my taste. I've some FreeBSD hosts running SSHguard v2.2.0 and note that version can tail arbitrary files. While a jailed SSH+SSHGuard pair may not be able to make modifications to things outside the jail, an SSHGuard process outside the jail should be able to read logs generated by the jailed SSHd. I would expect that to be able to make modification's to the host's (unjailed) PF or IPFW configurations. > In the older version it may be that all blacklist entries are removed from > hosts.allow as they normally time out and then a blacklisted IP is added back to > hosts.allow on its first attempt. If the current system does not do that, I > think that would be a nice addition. If using BerkleyDB makes that faster, that > is both a small footprint tool and at least in FreeBSD, any server other than a > stand-alone DNS server is likely to have that as a requirement. From a > performance standpoint I think anything less than 10-20k entries in a flat file > can be grep'd. In computer time it's centuries between ssh logins. If you're using the IPFW or PF backend, maybe having the jail log normally and having an SSHGuard process running outside the jail that looks at the jail's logs may do what you want? The PF version seems quite responsive, and I'd expect the IPFW variant to be similar. I would certainly expect both to be faster for very large lists when compared with TCP wrappers (i.e., libwrap). Caveat emptor, but I hope that helps. Keep in mind I likely do not understand the details of your environment because I don't have root there. ;-) -- Alan |
|
From: Kevin Z. <kev...@gm...> - 2019-01-01 15:32:21
|
Hi there, SSHGuard 2.3.1 is available. This release fixes two bugs reported after the 2.3.0 release, both because sshg-parser failed to detect some attacks that were previously detected. **Fixed** - Fix OpenSSH "Did not receive identification string" - Fix syslog banner detection on macOS Happy 2019, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Doug D. <do...@sa...> - 2018-12-31 19:03:44
|
First, thanks for the quick replies. If I understand your response, that the blacklist entries must be retained in hosts.allow (hosts.deny is no longer used, at lease in FreeBSD), that is what I see. That the blacklist must be "duplicated" in hosts.allow is different from the version that used BerkeleyDB. I am not sure how blocking is done in the old version, but it works, and the blacklisted IPs are not in hosts.allow. The way FreeBSD jails work, is that the guest hosts share the kernel with the base system. At the process level this is "virtually" invisible to running process. There are some commands that depend on kernel structures that do not work. Anyway the result of this is there can only be one IPFW as that is a kernel process. So inetd is the only choice using sshguard. I much prefer sshguard to fail2ban which is far too complex for my taste. In the older version it may be that all blacklist entries are removed from hosts.allow as they normally time out and then a blacklisted IP is added back to hosts.allow on its first attempt. If the current system does not do that, I think that would be a nice addition. If using BerkleyDB makes that faster, that is both a small footprint tool and at least in FreeBSD, any server other than a stand-alone DNS server is likely to have that as a requirement. From a performance standpoint I think anything less than 10-20k entries in a flat file can be grep'd. In computer time it's centuries between ssh logins. On Sun, 30 Dec 2018, Kevin Zheng wrote: > Hi Doug, > > Then it might be a bug in the hosts backend. I assumed (incorrectly) > that not many people were still using it, so it's been a while since > I've taken a close look. > > Like the other backends, SSHGuard should remove the entries it added > after it exits, and should re-add those that are blacklisted when it > starts up again. > > So, just to be clear: > > blacklist.db is the list of addresses SSHGuard blacklisted. While > SSHGuard is running, hosts.deny (or any other backend) should contain > all of blacklist.db (so that blacklisted hosts are actually blocked) as > well as additional hosts that get blocked while SSHGuard is running. > > Anything else is probably a bug; I'll take a look at how the hosts > backend is doing. > > Regards, > Kevin > > On 12/30/18 7:00 PM, Doug Denault wrote: >> I've configured sshguard correctly to use inetd. On host 2 it blocks >> 50k+ attempts/day. Configuration is straight forward enough. What I am >> trying to say, apparently not very well, is the IPs blacklisted are >> never removed from /etc/hosts.allow. In the older version of sshguard >> blacklisted IPs do not appear in the hosts.allow file. >> >> Out of the 3,000 or so IPs in hosts.allow all but 500-600 are duplicated >> in the blacklist file. Can a configuration error cause this behavior? >> >> I kinda assumed this was a bug, so my question was really, if I prune >> the hosts.allow file will the blacklist entries be honored. The answer >> to that is, I take from your email, yes. >> >> Maybe I have not properly turned on blacklisting. AFAIK FreeBSD jails >> are not sandboxes. E.g., a process can not ascertain if it running in a >> jail or natively. My config file: >> >> __________________sshguard.conf__________________ >> #!/bin/sh >> # sshguard.conf -- SSHGuard configuration >> >> # Options that are uncommented in this example are set to their default >> # values. Options without defaults are commented out. >> >> #### REQUIRED CONFIGURATION #### >> # Full path to backend executable (required, no default) >> BACKEND="/usr/local/libexec/sshg-fw-hosts" >> #BACKEND="/usr/local/libexec/sshg-fw-ipfw" >> #BACKEND="/usr/local/libexec/sshg-fw-pf" >> >> # Space-separated list of log files to monitor. (optional, no default) >> FILES="/var/log/auth.log /var/log/maillog" >> >> # Shell command that provides logs on standard output. (optional, no >> default) >> # Example 1: ssh and sendmail from systemd journal: >> #LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t >> sendmail -o cat" >> # Example 2: ssh from os_log (macOS 10.12+) >> #LOGREADER="/usr/bin/log stream --style syslog --predicate >> '(processImagePath contains \"sshd\")'" >> >> #### OPTIONS #### >> # Block attackers when their cumulative attack score exceeds THRESHOLD. >> # Most attacks have a score of 10. (optional, default 30) >> THRESHOLD=30 >> >> # Block attackers for initially BLOCK_TIME seconds after exceeding >> THRESHOLD. >> # Subsequent blocks increase by a factor of 1.5. (optional, default 120) >> BLOCK_TIME=120 >> >> # Remember potential attackers for up to DETECTION_TIME seconds before >> # resetting their score. (optional, default 1800) >> DETECTION_TIME=1800 >> >> # Size of IPv6 'subnet to block. Defaults to a single address, CIDR >> notation. (optional, default to 128) >> #IPV6_SUBNET=128 >> >> # Size of IPv4 subnet to block. Defaults to a single address, CIDR >> notation. (optional, default to 32) >> #IPV4_SUBNET=32 >> >> #### EXTRAS #### >> # !! Warning: These features may not work correctly with sandboxing. !! >> >> # Full path to PID file (optional, no default) >> #PID_FILE=/var/run/sshguard.pid >> >> # Colon-separated blacklist threshold and full path to blacklist file. >> # (optional, no default) >> BLACKLIST_FILE=120:/var/db/sshguard/blacklist.db >> >> >> On Sun, 30 Dec 2018, Kevin Zheng wrote: >> >>> Hi Doug, >>> >>> I noticed that you're running two different versions of SSHGuard. >>> >>> In 1.5, the port you install determines how SSHGuard blocks attacks. In >>> 2.1, you need to specify the backend you use by yourself. >>> >>> SSHGuard uses blacklist.db to keep track of hosts it has blacklisted, >>> because with firewalls like pf and ipfw, SSHGuard removes all of its >>> blocks (including those that it has blacklisted) when it exits. While >>> it's running, everything in blacklist.db should also be in hosts.allow. >>> >>> When SSHGuard exits, hosts.allow should be cleared. blacklist.db tells >>> SSHGuard what addresses to add back once it starts again. >>> >>> So, they're not redundant. Is that what you're asking? >>> >>> Regards, >>> Kevin >>> >>> On 12/30/18 2:39 PM, Doug Denault wrote: >>>> I am using sshguard with inet with FreeBSD jails. Having multiple >>>> [virtual] servers with differing blocking requirements this is really >>>> the only option. It appears to me that with the switch from BerkleyDB to >>>> a flat file that the blacklist is implemented by using the >>>> /etc/hosts.allow entries. >>>> >>>> Whether I am correct or not here is what happens on two systems: >>>> >>>> host 1: sshguard-1.5_2 >>>> blacklist: 7,151 entries >>>> hosts.allow: 30 lines; max of 270 IPs (9/line) with very little >>>> overlap >>>> >>>> host 2: sshguard-2.1.0_1 >>>> blacklist: 3,251 lines >>>> hosts.allow: 338 line; max of 3,042 entries >>>> >>>> first line in hosts.allow: >>>> ALL : 218.92.1.141 121.22.80.117 118.25.63.24 219.234.88.119 >>>> 167.114.235.137 \ >>>> 185.143.223.191 61.184.247.8 115.238.245.4 : DENY >>>> >>>> This entire line is in /var/db/sshguard/: >>>> >>>> 1544124029|100|4|218.92.1.141 December 6, 2018 7:20:29 PM >>>> 1544126972|100|4|121.22.80.117 December 6, 2018 8:09:32 PM >>>> 1544128387|100|4|118.25.63.24 | >>>> 1544130000|100|4|219.234.88.119 V >>>> 1544135312|100|4|167.114.235.137 >>>> 1544135835|100|4|185.143.223.191 >>>> 1544136112|100|4|61.184.247.8 >>>> 1544137146|100|4|115.238.245.4 December 6, 2018 10:59:06 >>>> >>>> Taking a random entry, say line 2,800 from blacklist: >>>> 1545136493|100|4|51.38.186.48 December 18, 2018 12:34:53 PM >>>> 1545136864|100|4|182.162.96.184 >>>> 1545136941|100|4|212.88.123.198 >>>> >>>> All three are in hosts.allow >>>> >>>> So is /var/db/sshguard/blacklist.db redundant or can hosts.allow be >>>> pruned? This is the better answer to me. Also as blacklist.db is a flat >>>> file I assume the epoch time is the time of the blacklisting and not the >>>> last reference. >>>> >>>> >>>> >>>> _____ >>>> Douglas Denault >>>> http://www.safeport.com >>>> do...@sa... >>>> Voice: 301-217-9220 >>>> Fax: 301-217-9277 >>>> >>>> >>>> _______________________________________________ >>>> sshguard-users mailing list >>>> ssh...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users >>> >>> >>> -- >>> Kevin Zheng >>> kev...@gm... | ke...@be... | PGP: 0xC22E1090 >>> >> >> _____ >> Douglas Denault >> http://www.safeport.com >> do...@sa... >> Voice: 301-217-9220 >> Fax: 301-217-9277 > > > -- > Kevin Zheng > kev...@gm... | ke...@be... | PGP: 0xC22E1090 > _____ Douglas Denault http://www.safeport.com do...@sa... Voice: 301-217-9220 Fax: 301-217-9277 |
|
From: Kevin Z. <kev...@gm...> - 2018-12-31 02:26:53
|
Hi Doug, Then it might be a bug in the hosts backend. I assumed (incorrectly) that not many people were still using it, so it's been a while since I've taken a close look. Like the other backends, SSHGuard should remove the entries it added after it exits, and should re-add those that are blacklisted when it starts up again. So, just to be clear: blacklist.db is the list of addresses SSHGuard blacklisted. While SSHGuard is running, hosts.deny (or any other backend) should contain all of blacklist.db (so that blacklisted hosts are actually blocked) as well as additional hosts that get blocked while SSHGuard is running. Anything else is probably a bug; I'll take a look at how the hosts backend is doing. Regards, Kevin On 12/30/18 7:00 PM, Doug Denault wrote: > I've configured sshguard correctly to use inetd. On host 2 it blocks > 50k+ attempts/day. Configuration is straight forward enough. What I am > trying to say, apparently not very well, is the IPs blacklisted are > never removed from /etc/hosts.allow. In the older version of sshguard > blacklisted IPs do not appear in the hosts.allow file. > > Out of the 3,000 or so IPs in hosts.allow all but 500-600 are duplicated > in the blacklist file. Can a configuration error cause this behavior? > > I kinda assumed this was a bug, so my question was really, if I prune > the hosts.allow file will the blacklist entries be honored. The answer > to that is, I take from your email, yes. > > Maybe I have not properly turned on blacklisting. AFAIK FreeBSD jails > are not sandboxes. E.g., a process can not ascertain if it running in a > jail or natively. My config file: > > __________________sshguard.conf__________________ > #!/bin/sh > # sshguard.conf -- SSHGuard configuration > > # Options that are uncommented in this example are set to their default > # values. Options without defaults are commented out. > > #### REQUIRED CONFIGURATION #### > # Full path to backend executable (required, no default) > BACKEND="/usr/local/libexec/sshg-fw-hosts" > #BACKEND="/usr/local/libexec/sshg-fw-ipfw" > #BACKEND="/usr/local/libexec/sshg-fw-pf" > > # Space-separated list of log files to monitor. (optional, no default) > FILES="/var/log/auth.log /var/log/maillog" > > # Shell command that provides logs on standard output. (optional, no > default) > # Example 1: ssh and sendmail from systemd journal: > #LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t > sendmail -o cat" > # Example 2: ssh from os_log (macOS 10.12+) > #LOGREADER="/usr/bin/log stream --style syslog --predicate > '(processImagePath contains \"sshd\")'" > > #### OPTIONS #### > # Block attackers when their cumulative attack score exceeds THRESHOLD. > # Most attacks have a score of 10. (optional, default 30) > THRESHOLD=30 > > # Block attackers for initially BLOCK_TIME seconds after exceeding > THRESHOLD. > # Subsequent blocks increase by a factor of 1.5. (optional, default 120) > BLOCK_TIME=120 > > # Remember potential attackers for up to DETECTION_TIME seconds before > # resetting their score. (optional, default 1800) > DETECTION_TIME=1800 > > # Size of IPv6 'subnet to block. Defaults to a single address, CIDR > notation. (optional, default to 128) > #IPV6_SUBNET=128 > > # Size of IPv4 subnet to block. Defaults to a single address, CIDR > notation. (optional, default to 32) > #IPV4_SUBNET=32 > > #### EXTRAS #### > # !! Warning: These features may not work correctly with sandboxing. !! > > # Full path to PID file (optional, no default) > #PID_FILE=/var/run/sshguard.pid > > # Colon-separated blacklist threshold and full path to blacklist file. > # (optional, no default) > BLACKLIST_FILE=120:/var/db/sshguard/blacklist.db > > > On Sun, 30 Dec 2018, Kevin Zheng wrote: > >> Hi Doug, >> >> I noticed that you're running two different versions of SSHGuard. >> >> In 1.5, the port you install determines how SSHGuard blocks attacks. In >> 2.1, you need to specify the backend you use by yourself. >> >> SSHGuard uses blacklist.db to keep track of hosts it has blacklisted, >> because with firewalls like pf and ipfw, SSHGuard removes all of its >> blocks (including those that it has blacklisted) when it exits. While >> it's running, everything in blacklist.db should also be in hosts.allow. >> >> When SSHGuard exits, hosts.allow should be cleared. blacklist.db tells >> SSHGuard what addresses to add back once it starts again. >> >> So, they're not redundant. Is that what you're asking? >> >> Regards, >> Kevin >> >> On 12/30/18 2:39 PM, Doug Denault wrote: >>> I am using sshguard with inet with FreeBSD jails. Having multiple >>> [virtual] servers with differing blocking requirements this is really >>> the only option. It appears to me that with the switch from BerkleyDB to >>> a flat file that the blacklist is implemented by using the >>> /etc/hosts.allow entries. >>> >>> Whether I am correct or not here is what happens on two systems: >>> >>> host 1: sshguard-1.5_2 >>> blacklist: 7,151 entries >>> hosts.allow: 30 lines; max of 270 IPs (9/line) with very little >>> overlap >>> >>> host 2: sshguard-2.1.0_1 >>> blacklist: 3,251 lines >>> hosts.allow: 338 line; max of 3,042 entries >>> >>> first line in hosts.allow: >>> ALL : 218.92.1.141 121.22.80.117 118.25.63.24 219.234.88.119 >>> 167.114.235.137 \ >>> 185.143.223.191 61.184.247.8 115.238.245.4 : DENY >>> >>> This entire line is in /var/db/sshguard/: >>> >>> 1544124029|100|4|218.92.1.141 December 6, 2018 7:20:29 PM >>> 1544126972|100|4|121.22.80.117 December 6, 2018 8:09:32 PM >>> 1544128387|100|4|118.25.63.24 | >>> 1544130000|100|4|219.234.88.119 V >>> 1544135312|100|4|167.114.235.137 >>> 1544135835|100|4|185.143.223.191 >>> 1544136112|100|4|61.184.247.8 >>> 1544137146|100|4|115.238.245.4 December 6, 2018 10:59:06 >>> >>> Taking a random entry, say line 2,800 from blacklist: >>> 1545136493|100|4|51.38.186.48 December 18, 2018 12:34:53 PM >>> 1545136864|100|4|182.162.96.184 >>> 1545136941|100|4|212.88.123.198 >>> >>> All three are in hosts.allow >>> >>> So is /var/db/sshguard/blacklist.db redundant or can hosts.allow be >>> pruned? This is the better answer to me. Also as blacklist.db is a flat >>> file I assume the epoch time is the time of the blacklisting and not the >>> last reference. >>> >>> >>> >>> _____ >>> Douglas Denault >>> http://www.safeport.com >>> do...@sa... >>> Voice: 301-217-9220 >>> Fax: 301-217-9277 >>> >>> >>> _______________________________________________ >>> sshguard-users mailing list >>> ssh...@li... >>> https://lists.sourceforge.net/lists/listinfo/sshguard-users >> >> >> -- >> Kevin Zheng >> kev...@gm... | ke...@be... | PGP: 0xC22E1090 >> > > _____ > Douglas Denault > http://www.safeport.com > do...@sa... > Voice: 301-217-9220 > Fax: 301-217-9277 -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Doug D. <do...@sa...> - 2018-12-31 01:01:04
|
I've configured sshguard correctly to use inetd. On host 2 it blocks 50k+ attempts/day. Configuration is straight forward enough. What I am trying to say, apparently not very well, is the IPs blacklisted are never removed from /etc/hosts.allow. In the older version of sshguard blacklisted IPs do not appear in the hosts.allow file. Out of the 3,000 or so IPs in hosts.allow all but 500-600 are duplicated in the blacklist file. Can a configuration error cause this behavior? I kinda assumed this was a bug, so my question was really, if I prune the hosts.allow file will the blacklist entries be honored. The answer to that is, I take from your email, yes. Maybe I have not properly turned on blacklisting. AFAIK FreeBSD jails are not sandboxes. E.g., a process can not ascertain if it running in a jail or natively. My config file: __________________sshguard.conf__________________ #!/bin/sh # sshguard.conf -- SSHGuard configuration # Options that are uncommented in this example are set to their default # values. Options without defaults are commented out. #### REQUIRED CONFIGURATION #### # Full path to backend executable (required, no default) BACKEND="/usr/local/libexec/sshg-fw-hosts" #BACKEND="/usr/local/libexec/sshg-fw-ipfw" #BACKEND="/usr/local/libexec/sshg-fw-pf" # Space-separated list of log files to monitor. (optional, no default) FILES="/var/log/auth.log /var/log/maillog" # Shell command that provides logs on standard output. (optional, no default) # Example 1: ssh and sendmail from systemd journal: #LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t sendmail -o cat" # Example 2: ssh from os_log (macOS 10.12+) #LOGREADER="/usr/bin/log stream --style syslog --predicate '(processImagePath contains \"sshd\")'" #### OPTIONS #### # Block attackers when their cumulative attack score exceeds THRESHOLD. # Most attacks have a score of 10. (optional, default 30) THRESHOLD=30 # Block attackers for initially BLOCK_TIME seconds after exceeding THRESHOLD. # Subsequent blocks increase by a factor of 1.5. (optional, default 120) BLOCK_TIME=120 # Remember potential attackers for up to DETECTION_TIME seconds before # resetting their score. (optional, default 1800) DETECTION_TIME=1800 # Size of IPv6 'subnet to block. Defaults to a single address, CIDR notation. (optional, default to 128) #IPV6_SUBNET=128 # Size of IPv4 subnet to block. Defaults to a single address, CIDR notation. (optional, default to 32) #IPV4_SUBNET=32 #### EXTRAS #### # !! Warning: These features may not work correctly with sandboxing. !! # Full path to PID file (optional, no default) #PID_FILE=/var/run/sshguard.pid # Colon-separated blacklist threshold and full path to blacklist file. # (optional, no default) BLACKLIST_FILE=120:/var/db/sshguard/blacklist.db On Sun, 30 Dec 2018, Kevin Zheng wrote: > Hi Doug, > > I noticed that you're running two different versions of SSHGuard. > > In 1.5, the port you install determines how SSHGuard blocks attacks. In > 2.1, you need to specify the backend you use by yourself. > > SSHGuard uses blacklist.db to keep track of hosts it has blacklisted, > because with firewalls like pf and ipfw, SSHGuard removes all of its > blocks (including those that it has blacklisted) when it exits. While > it's running, everything in blacklist.db should also be in hosts.allow. > > When SSHGuard exits, hosts.allow should be cleared. blacklist.db tells > SSHGuard what addresses to add back once it starts again. > > So, they're not redundant. Is that what you're asking? > > Regards, > Kevin > > On 12/30/18 2:39 PM, Doug Denault wrote: >> I am using sshguard with inet with FreeBSD jails. Having multiple >> [virtual] servers with differing blocking requirements this is really >> the only option. It appears to me that with the switch from BerkleyDB to >> a flat file that the blacklist is implemented by using the >> /etc/hosts.allow entries. >> >> Whether I am correct or not here is what happens on two systems: >> >> host 1: sshguard-1.5_2 >> blacklist: 7,151 entries >> hosts.allow: 30 lines; max of 270 IPs (9/line) with very little >> overlap >> >> host 2: sshguard-2.1.0_1 >> blacklist: 3,251 lines >> hosts.allow: 338 line; max of 3,042 entries >> >> first line in hosts.allow: >> ALL : 218.92.1.141 121.22.80.117 118.25.63.24 219.234.88.119 >> 167.114.235.137 \ >> 185.143.223.191 61.184.247.8 115.238.245.4 : DENY >> >> This entire line is in /var/db/sshguard/: >> >> 1544124029|100|4|218.92.1.141 December 6, 2018 7:20:29 PM >> 1544126972|100|4|121.22.80.117 December 6, 2018 8:09:32 PM >> 1544128387|100|4|118.25.63.24 | >> 1544130000|100|4|219.234.88.119 V >> 1544135312|100|4|167.114.235.137 >> 1544135835|100|4|185.143.223.191 >> 1544136112|100|4|61.184.247.8 >> 1544137146|100|4|115.238.245.4 December 6, 2018 10:59:06 >> >> Taking a random entry, say line 2,800 from blacklist: >> 1545136493|100|4|51.38.186.48 December 18, 2018 12:34:53 PM >> 1545136864|100|4|182.162.96.184 >> 1545136941|100|4|212.88.123.198 >> >> All three are in hosts.allow >> >> So is /var/db/sshguard/blacklist.db redundant or can hosts.allow be >> pruned? This is the better answer to me. Also as blacklist.db is a flat >> file I assume the epoch time is the time of the blacklisting and not the >> last reference. >> >> >> >> _____ >> Douglas Denault >> http://www.safeport.com >> do...@sa... >> Voice: 301-217-9220 >> Fax: 301-217-9277 >> >> >> _______________________________________________ >> sshguard-users mailing list >> ssh...@li... >> https://lists.sourceforge.net/lists/listinfo/sshguard-users > > > -- > Kevin Zheng > kev...@gm... | ke...@be... | PGP: 0xC22E1090 > _____ Douglas Denault http://www.safeport.com do...@sa... Voice: 301-217-9220 Fax: 301-217-9277 |
|
From: Kevin Z. <kev...@gm...> - 2018-12-30 21:36:48
|
Hi Doug, I noticed that you're running two different versions of SSHGuard. In 1.5, the port you install determines how SSHGuard blocks attacks. In 2.1, you need to specify the backend you use by yourself. SSHGuard uses blacklist.db to keep track of hosts it has blacklisted, because with firewalls like pf and ipfw, SSHGuard removes all of its blocks (including those that it has blacklisted) when it exits. While it's running, everything in blacklist.db should also be in hosts.allow. When SSHGuard exits, hosts.allow should be cleared. blacklist.db tells SSHGuard what addresses to add back once it starts again. So, they're not redundant. Is that what you're asking? Regards, Kevin On 12/30/18 2:39 PM, Doug Denault wrote: > I am using sshguard with inet with FreeBSD jails. Having multiple > [virtual] servers with differing blocking requirements this is really > the only option. It appears to me that with the switch from BerkleyDB to > a flat file that the blacklist is implemented by using the > /etc/hosts.allow entries. > > Whether I am correct or not here is what happens on two systems: > > host 1: sshguard-1.5_2 > blacklist: 7,151 entries > hosts.allow: 30 lines; max of 270 IPs (9/line) with very little > overlap > > host 2: sshguard-2.1.0_1 > blacklist: 3,251 lines > hosts.allow: 338 line; max of 3,042 entries > > first line in hosts.allow: > ALL : 218.92.1.141 121.22.80.117 118.25.63.24 219.234.88.119 > 167.114.235.137 \ > 185.143.223.191 61.184.247.8 115.238.245.4 : DENY > > This entire line is in /var/db/sshguard/: > > 1544124029|100|4|218.92.1.141 December 6, 2018 7:20:29 PM > 1544126972|100|4|121.22.80.117 December 6, 2018 8:09:32 PM > 1544128387|100|4|118.25.63.24 | > 1544130000|100|4|219.234.88.119 V > 1544135312|100|4|167.114.235.137 > 1544135835|100|4|185.143.223.191 > 1544136112|100|4|61.184.247.8 > 1544137146|100|4|115.238.245.4 December 6, 2018 10:59:06 > > Taking a random entry, say line 2,800 from blacklist: > 1545136493|100|4|51.38.186.48 December 18, 2018 12:34:53 PM > 1545136864|100|4|182.162.96.184 > 1545136941|100|4|212.88.123.198 > > All three are in hosts.allow > > So is /var/db/sshguard/blacklist.db redundant or can hosts.allow be > pruned? This is the better answer to me. Also as blacklist.db is a flat > file I assume the epoch time is the time of the blacklisting and not the > last reference. > > > > _____ > Douglas Denault > http://www.safeport.com > do...@sa... > Voice: 301-217-9220 > Fax: 301-217-9277 > > > _______________________________________________ > sshguard-users mailing list > ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Doug D. <do...@sa...> - 2018-12-30 21:11:34
|
I am using sshguard with inet with FreeBSD jails. Having multiple [virtual]
servers with differing blocking requirements this is really the only option. It
appears to me that with the switch from BerkleyDB to a flat file that the
blacklist is implemented by using the /etc/hosts.allow entries.
Whether I am correct or not here is what happens on two systems:
host 1: sshguard-1.5_2
blacklist: 7,151 entries
hosts.allow: 30 lines; max of 270 IPs (9/line) with very little overlap
host 2: sshguard-2.1.0_1
blacklist: 3,251 lines
hosts.allow: 338 line; max of 3,042 entries
first line in hosts.allow:
ALL : 218.92.1.141 121.22.80.117 118.25.63.24 219.234.88.119 167.114.235.137 \
185.143.223.191 61.184.247.8 115.238.245.4 : DENY
This entire line is in /var/db/sshguard/:
1544124029|100|4|218.92.1.141 December 6, 2018 7:20:29 PM
1544126972|100|4|121.22.80.117 December 6, 2018 8:09:32 PM
1544128387|100|4|118.25.63.24 |
1544130000|100|4|219.234.88.119 V
1544135312|100|4|167.114.235.137
1544135835|100|4|185.143.223.191
1544136112|100|4|61.184.247.8
1544137146|100|4|115.238.245.4 December 6, 2018 10:59:06
Taking a random entry, say line 2,800 from blacklist:
1545136493|100|4|51.38.186.48 December 18, 2018 12:34:53 PM
1545136864|100|4|182.162.96.184
1545136941|100|4|212.88.123.198
All three are in hosts.allow
So is /var/db/sshguard/blacklist.db redundant or can hosts.allow be pruned? This
is the better answer to me. Also as blacklist.db is a flat file I assume the
epoch time is the time of the blacklisting and not the last reference.
_____
Douglas Denault
http://www.safeport.com
do...@sa...
Voice: 301-217-9220
Fax: 301-217-9277
|
|
From: Jos C. <ssh...@cl...> - 2018-12-24 22:42:44
|
Hi Kev, On 16-12-18 4:08, Kevin Zheng wrote: > SSHGuard 2.3.0 is now available! Great news - any donation possible on PayPal? Have a great Season's Holiday! Jos |
|
From: Kevin Z. <kev...@gm...> - 2018-12-16 03:08:35
|
Hi there, SSHGuard 2.3.0 is now available! **Added** - Add signatures for Courier IMAP/POP and OpenVPN - Add signatures for TLS failures against Cyrus IMAP - Match more attacks against SSHD, Cockpit, and Dovecot - Update SSH invalid user signature for macOS **Changed** - Add to and remove from ipfw table quietly - Reduce "Connection closed... [preauth]" score to 2 - Switch ipsets to hash:net **Fixed** - Don't recreate existing ipsets - Match more log banners (Fix greedy SYSLOG_BANNER) -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Kevin Z. <kev...@gm...> - 2018-12-12 06:08:10
|
Hi folks, There are some minor changes to ipsets and some signatures contributed by Christopher Engelhard that warrant a release near the end of this year. Around then I'll also circulate a second user survey. Looking at our outstanding issues, it looks like most are parser issues and improvements, fixing some issues with the SSHGuard pipeline, and being able to configure parts of the parser without recompiling. Not mentioned here is the 'remember attacks between SSHGuard restarting' feature that was hacked together but never quite completed. As always, comments to guide where the priorities should be are always welcome. OpenBSD users: the port is still on 1.5? Also, curious to see if the pledge() stuff still works after what sound like some changes. In other news, `make dist` which was broken for a while is now fixed, and Bitbucket now has CI enabled which just runs `make distcheck`. Regards, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Kevin Z. <kev...@gm...> - 2018-12-03 20:15:43
|
On 12/3/18 11:48 AM, @lbutlr wrote: > It’s possible that my rsyslog is causing this? > > *.err;kern.warning;auth.notice;mail.crit //var/log/console.log > *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages > security.* /var/log/security > auth.info;authpriv.info /var/log/auth.log > console.info /var/log/console.log It could be. Did you check the two log files you're monitoring using SSHGuard yourself for messages that appear in both logs? -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: @lbutlr <kr...@kr...> - 2018-12-03 20:07:31
|
When checking my logs I am seeing that sshguard attack log lines are tripled in my logs, once in auth.log, console.log, messages, and security auth.log:Dec 3 12:36:49 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. auth.log:Dec 3 12:37:06 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. auth.log:Dec 3 12:37:18 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. console.log:Dec 3 12:36:49 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. console.log:Dec 3 12:37:06 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. console.log:Dec 3 12:37:18 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. messages:Dec 3 12:36:49 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. messages:Dec 3 12:37:06 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. messages:Dec 3 12:37:18 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. security:Dec 3 12:36:49 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. security:Dec 3 12:37:06 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. security:Dec 3 12:37:18 mail sshguard[53698]: Attack from "66.42.114.146" on service 100 with danger 10. My sshguard config is pretty basic: BACKEND="/usr/local/libexec/sshg-fw-pf" FILES="/var/log/auth.log /var/log/mail.log" THRESHOLD=30 BLOCK_TIME=1200 DETECTION_TIME=18000 WHITELIST_FILE=/usr/local/etc/sshguard.whitelist It’s possible that my rsyslog is causing this? *.err;kern.warning;auth.notice;mail.crit //var/log/console.log *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security auth.info;authpriv.info /var/log/auth.log console.info /var/log/console.log -- And there were all the stars, looking remarkably like powered diamonds spilled on black velvet, the stars that lured and ultimately called the boldest towards them… |
|
From: Alan A. <al...@an...> - 2018-11-03 01:54:53
|
On 02 Nov 2018, at 07:12, ssh...@li... wrote: [snip] > From: Christopher Engelhard <ce...@lc...> > To: ssh...@li... > Subject: [SSHGuard-users] Log human-readable service IDs instead of > numbers? > Message-ID: <ba3...@lc...> [snip] > 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. TL;DR: Probably no real reason to not do it other than it's going to require some work to integrate the change. The only reasons that come to mind for not doing so relate to something you brought up later in this thread, i.e., "where one program handles multiple standard services" (from your message dated Sat, 3 Nov 2018 00:55:00 +0100) seem minor to me. The numeric code is a nice, fixed-width token that can make automated log parsing of SSHGuard's output simpler, but a well defined log format that's easily tokenized can mitigate that problem pretty easily. There's also the matter of what to do if/when a program/package gets renamed, e.g., if Postfix gets renamed to "s00per 3mail deliberator!" then tracking name changes is possibly a problem. A potentially more serious problem are any assumptions about the enumerated type "service" in attack.h, i.e., if something else in SSHGuard expects the token to be a specific size. What might be the easiest way to do this is have a separate lookup for the service token and simply insert it into or append it to the current message, e.g., Attack from "192.0.2.1" on service 210 (dovecot) with danger 10. Like I said, I think these are very minor problems. I think they could be overcome pretty easily. There may be reasons for separating things by port number, too, e.g., it could be nice to know that a specific Postfix listener on 587/tcp is being attacked instead of just Postfix in general, but a quick perusal of logs suggests that's more problematic. Postfix, for example can have its submission port listener log with a different name than its SMTP port listener (e.g., by setting syslog_name in master.cf), but that doesn't directly report a port number. Also, since there's no standard on service naming, I think trying to account for all possible names is a pointless endeavor. There is no standard for such naming in logs (or, at least [citation needed]), and I can't think of another way for SSHGuard to track port numbers that's easily portable and lightweight. Port number reporting might be useful for people who run services on unusual ports, e.g., like SSHd on port 2222/tcp. However, I don't see why SSHGuard needs to do this. Anyone running SSHd on a non-standard port should be able to get any needed port information directly from the log, i.e., from messages like Nov 2 20:29:17 somehost sshd[59351]: Connection from 192.0.2.2 port 19654 on 192.0.2.201 port 22 For what it's worth, I think human-readable service identifiers are a good idea. -- Alan |
|
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 > |
|
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: 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: 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: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: 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: 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-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: 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 |
2 messages has been excluded from this view by a project administrator.
