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
(6) |
Oct
|
Nov
|
Dec
|
|
From: Kevin Z. <kev...@gm...> - 2019-02-14 19:20:31
|
Hi Toby, Glad to hear. Do you know where we can find the init.d scripts for Gentoo so that we might be able to debug the issue? I suspect it has something to do with where we write the PID file. Regards, Kevin On 2/14/19 2:49 AM, Toby Poynder wrote: > I'm running Safeguard on two Gentoo linux servers (both openrc) and > both show the status as "crashed" even when the system is running finel > > [elvis] /etc/init.d# rc-service sshguard status > * status: crashed > > Apart from this I ave no complaints - much easier to set up and use than > fail2ban. > -- > Toby Poynder > London, UK > > > _______________________________________________ > sshguard-users mailing list > ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Toby P. <to...@wh...> - 2019-02-14 10:49:35
|
I'm running Safeguard on two Gentoo linux servers (both openrc) and both show the status as "crashed" even when the system is running finel [elvis] /etc/init.d# rc-service sshguard status * status: crashed Apart from this I ave no complaints - much easier to set up and use than fail2ban. -- Toby Poynder London, UK |
|
From: Gary <li...@la...> - 2019-01-08 21:51:58
|
I have been using this blocker for about two years on the lowest level. I never blocked any legit email. I block way more spammers with this technique than I with RBLs. Even someone with a home server would have a static IP, if only to pass SPF. You really need SPF and DKIM to get most email servers to take your mail. Further some like ATT will block your email if your IP is not from a major provider. They will whitelist a static IP upon request. They would never take a dynamic IP. So even if you don't block them, a server with dynamic IP will often get rejected. Again take this up with the gurus on the postfix mailing list. The postfix author is on the list as well as the Ubuntu maintainer. These people are experts. I am extremely averse to blocking legitimate email. I only run a few RBLs that I have verified are not giving me false positives. I don't even run SpamAssassin. I set my encryption at "may" though it pains me to do so. If I believed I was blocking legitimate email with this dynamic blocker, I wouldn't use it. Original Message From: ma...@su... Sent: January 8, 2019 1:06 PM To: li...@la... Cc: kev...@gm...; ssh...@li... Subject: Re: [SSHGuard-users] posfix - bots Hi, I agree that dynamic IP's can be filtered in postfix. But in that case we could also deny legit email from servers, which are not properly configured. I was able to recreate this type of connection, which spam bots do. They connect to server and send commands: * helo * auth * quit If the auth is not enabled, than they quit the session since they have nothing more to do. Can this happen to legit session? To tell you the truth, I don't know. Maybe someone from postfix mailing list would know. Regards, Mario Quoting li...@la...: > 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: Mario B <ma...@su...> - 2019-01-08 21:06:10
|
Hi, I agree that dynamic IP's can be filtered in postfix. But in that case we could also deny legit email from servers, which are not properly configured. I was able to recreate this type of connection, which spam bots do. They connect to server and send commands: * helo * auth * quit If the auth is not enabled, than they quit the session since they have nothing more to do. Can this happen to legit session? To tell you the truth, I don't know. Maybe someone from postfix mailing list would know. Regards, Mario Quoting li...@la...: > 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: Christos C. <ch...@cr...> - 2019-01-08 14:18:54
|
> > 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 > Dear Kevin, I check the daily logs on many servers for these entries and I see only IPs that look like spambots. I am not sure if a legitimate client can generate this message. To me it looks like a spambot tries to do SMTP authentication to check if a password is valid and maybe use later this account to send spam). I think it's better to ask to pos...@po... Some examples: server44: Jan 8 14:30:49 server44 postfix-smtp/smtpd[61979]: disconnect from static-233-10-25-46.ipcom.comunitel.net[46.25.10.233] helo=1 auth=0/1 quit=1 commands=2/3 Jan 8 15:07:22 server44 postfix-smtp/smtpd[2605]: disconnect from static-233-10-25-46.ipcom.comunitel.net[46.25.10.233] helo=1 auth=0/1 quit=1 commands=2/3 server53: Jan 8 12:32:29 server53 postfix-smtp/smtpd[63822]: disconnect from dslb-088-070-049-129.088.070.pools.vodafone-ip.de[88.70.49.129] helo=1 auth=0/1 quit=1 commands=2/3 server56: Jan 8 01:45:34 server56 postfix-smtp/smtpd[8747]: disconnect from unknown[78.131.87.207] helo=1 auth=0/1 quit=1 commands=2/3 Jan 8 10:47:04 server56 postfix-smtp/smtpd[52366]: disconnect from dslb-088-070-049-129.088.070.pools.vodafone-ip.de[88.70.49.129] helo=1 auth=0/1 quit=1 commands=2/3 Jan 8 11:25:06 server56 postfix-smtp/smtpd[53914]: disconnect from dslb-088-070-049-129.088.070.pools.vodafone-ip.de[88.70.49.129] helo=1 auth=0/1 quit=1 commands=2/3 Jan 8 13:20:36 server56 postfix-smtp/smtpd[9710]: disconnect from static-233-10-25-46.ipcom.comunitel.net[46.25.10.233] helo=1 auth=0/1 quit=1 commands=2/3 Jan 8 13:25:19 server56 postfix-smtp/smtpd[9710]: disconnect from static-233-10-25-46.ipcom.comunitel.net[46.25.10.233] helo=1 auth=0/1 quit=1 commands=2/3 server6: Jan 8 01:51:40 server6 postfix-smtp/smtpd[9237]: disconnect from unknown[191.209.21.224] helo=1 auth=0/1 quit=1 commands=2/3 Jan 8 14:13:13 server6 postfix-smtp/smtpd[13008]: disconnect from static-233-10-25-46.ipcom.comunitel.net[46.25.10.233] helo=1 auth=0/1 quit=1 commands=2/3 Jan 8 15:17:46 server6 postfix-smtp/smtpd[85471]: disconnect from unknown[41.79.233.43] helo=1 auth=0/1 quit=1 commands=2/3 Jan 8 15:34:36 server6 postfix-smtp/smtpd[16609]: disconnect from static-233-10-25-46.ipcom.comunitel.net[46.25.10.233] helo=1 auth=0/1 quit=1 commands=2/3 Kind regards, Christos Chatzaras |
|
From: Christos C. <ch...@cr...> - 2019-01-08 14:16:04
|
> > 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. > Just make sure that the check_reverse_client_hostname_access or check_client_access (for newer versions of Postfix) is after permit_mynetworks and permit_sasl_authenticated else the authenticated clients from dynamic IPs will not be able to send e-mail. |
|
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 |
2 messages has been excluded from this view by a project administrator.
