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: Christopher E. <ce...@lc...> - 2019-10-26 10:51:24
|
On 26.10.19 10:43, @lbutlr wrote: > Is it possible for me to increase the danger level for certain users? To my knowledge, sshguard currently does not match usernames in the attack signatures, only hosts/ips. It's easy to add a fixed, escalated seriousness for a fixed (list of) username(s) (In fact, someone did some work on this a while ago [1]). Since that's neither dynamic not user-configurable, it's not really ideal as a general solution: - it could only be justified for root - even then, would mean that people who do allow root logins would see themselves rapidly blocked after mistyping a password ... However, if you're OK with building sshguard yourself, it's not too difficult to add these additional rules to your local version. Have a look at attack_(parser.y|scanner.l) in the linked PR as a guide to the necessary changes. Christopher [1] https://bitbucket.org/robohack/sshguard/commits/43c8542552e8f5a3413d5c5984555bea4d77bb7e?at=master |
From: @lbutlr <kr...@kr...> - 2019-10-26 09:01:16
|
Is it possible for me to increase the danger level for certain users? For example, my server does not allow logins on the accounts “root” or “admin” or several others, so I would like attempts to login to these accounts to instantly result in a maximal ban of the IP address and not to allow them to try to connect several times until they exceed a threshold; especially since I am seeing large attacks where an IP only tries to connect a few times an hour over the course of weeks, nearly never exceeding the thresholds, but many Its are coordinating attempts to login |
From: lists <li...@la...> - 2019-10-22 20:19:12
|
<html><head><meta http-equiv="Content-Security-Policy" content="script-src 'self'; img-src * cid: data:;"><style id="outgoing-font-settings">#response_container_BBPPID{font-family: initial; font-size:initial; color: initial;}</style></head><body style="background-color: rgb(255, 255, 255); background-image: initial; line-height: initial;"><div id="response_container_BBPPID" style="outline:none;" dir="auto" contenteditable="false"> <div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"> Just an FYI, it helps to indicate the rev of the program and your OS (uname - a). </div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">Because SSHGuard isn't in my repos, it doesn't get updated all the time. I find it occasionally breaks when I do OS updates. But if I get the latest SSHGuard, the problem is already solved. </div> <div name="BB10" id="response_div_spacer_BBPPID" dir="auto" style="width:100%;"> <br style="display:initial"></div> <div id="blackberry_signature_BBPPID" name="BB10" dir="auto"> <div id="_signaturePlaceholder_BBPPID" name="BB10" dir="auto"></div> </div></div><div id="_original_msg_header_BBPPID" dir="auto"> <table width="100%" style="background-color: white; border-spacing: 0px; display: table; outline: none;" contenteditable="false"><tbody><tr><td colspan="2" style="padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div style="border-right: none; border-bottom: none; border-left: none; border-image: initial; border-top: 1pt solid rgb(181, 196, 223); padding: 3pt 0in 0in; font-family: Tahoma, "BB Alpha Sans", "Slate Pro"; font-size: 10pt;"> <div id="from"><b>From:</b> ssh...@li...</div><div id="sent"><b>Sent:</b> October 22, 2019 12:51 PM</div><div id="to"><b>To:</b> ssh...@li...</div><div id="reply_to"><b>Reply-to:</b> ja...@ka...</div><div id="subject"><b>Subject:</b> [SSHGuard-users] sshguard) exited with status 1.</div></div></td></tr></tbody></table> <br> </div><!--start of _originalContent --><div name="BB10" dir="auto" style="background-image: initial; line-height: initial; outline: none;" contenteditable="false"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""></div>I a having an issue with SSHGuard . I have had it installed for a while and now I am getting thses error messages<div class=""><br class=""></div><div class=""><br class=""></div><div class=""><pre style="background-color:rgb( 255 , 255 , 255 )" class="">ct 22 11:53:21 triggerfish syslogd: Logging subprocess 8460 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:53:21 triggerfish syslogd: Logging subprocess 8461 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:53:59 triggerfish syslogd: Logging subprocess 8464 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:54:02 triggerfish syslogd: Logging subprocess 8467 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:54:46 triggerfish syslogd: Logging subprocess 8504 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:54:46 triggerfish syslogd: Logging subprocess 8506 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:55:00 triggerfish syslogd: Logging subprocess 8523 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:55:24 triggerfish syslogd: Logging subprocess 8528 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:55:24 triggerfish syslogd: Logging subprocess 8529 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:56:13 triggerfish syslogd: Logging subprocess 8548 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:56:19 triggerfish syslogd: Logging subprocess 8551 (exec /usr/local/sbin/sshguard) exited with status 1.</pre><div class=""> I have no idea what it s trying to tell me</div></div><div class=""><br class=""></div><div class="">Anu help woud be greatly appreciated</div><div class=""><br class=""></div><div class=""><br class=""></div><!--end of _originalContent --></div></body></html> |
From: Kevin Z. <kev...@gm...> - 2019-10-22 20:04:39
|
Hi Jason, On 10/22/19 9:07 AM, jason hirsh via sshguard-users wrote: > I a having an issue with SSHGuard . I have had it installed for a > while and now I am getting thses error messages > > ct 22 11:53:21 triggerfish syslogd: Logging subprocess 8460 (exec /usr/local/sbin/sshguard) exited with status 1. Did you recently upgrade SSHGuard? Are you running SSHGuard as a subprocess from syslogd? Starting SSHGuard is no longer supported. Check `man sshguard-setup` for details. Regards, Kevin -- Kevin Zheng kev...@gm... | ke...@be... XMPP: ke...@ee... |
From: jason h. <ja...@ka...> - 2019-10-22 16:23:52
|
I a having an issue with SSHGuard . I have had it installed for a while and now I am getting thses error messages ct 22 11:53:21 triggerfish syslogd: Logging subprocess 8460 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:53:21 triggerfish syslogd: Logging subprocess 8461 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:53:59 triggerfish syslogd: Logging subprocess 8464 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:54:02 triggerfish syslogd: Logging subprocess 8467 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:54:46 triggerfish syslogd: Logging subprocess 8504 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:54:46 triggerfish syslogd: Logging subprocess 8506 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:55:00 triggerfish syslogd: Logging subprocess 8523 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:55:24 triggerfish syslogd: Logging subprocess 8528 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:55:24 triggerfish syslogd: Logging subprocess 8529 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:56:13 triggerfish syslogd: Logging subprocess 8548 (exec /usr/local/sbin/sshguard) exited with status 1. Oct 22 11:56:19 triggerfish syslogd: Logging subprocess 8551 (exec /usr/local/sbin/sshguard) exited with status 1. I have no idea what it s trying to tell me Anu help woud be greatly appreciated |
From: Kevin Z. <kev...@gm...> - 2019-09-26 16:44:14
|
On 9/24/19 7:00 PM, Ivan Avery Frey wrote: > If I run sshguard 1.7.1 with a complete set of logs to monitor it will > replace the sshguard currently running? No. -- Kevin Zheng kev...@gm... | ke...@be... XMPP: ke...@ee... |
From: Ivan A. F. <iva...@gm...> - 2019-09-25 02:01:00
|
On Tue, Sep 24, 2019, 21:40 Kevin Zheng, <kev...@gm...> wrote: > > > What if I want to add more logs for SSHGuard to monitor; is > > there a way to tell the running daemon to monitor these additional > > logs? > > While running, no. If you care about this, SSHGuard is experimenting > with the ability to save blocks on exit, so restarting SSHGuard won't > cause you to lose existing blocks. > If I run sshguard 1.7.1 with a complete set of logs to monitor it will replace the sshguard currently running? Ivan. > |
From: Kevin Z. <kev...@gm...> - 2019-09-25 01:40:58
|
On 9/24/19 6:30 PM, Ivan Avery Frey wrote: > I'm runnng SSHGuard 1.7.1 on Debian Stretch with kernel 4.1.48-vs. > > This is a kernel running with the Linux-VServer patches. > > What happens if I run "sshguard -v"? Will it kill the daemon that is > currently running? It shouldn't; `sshguard -v` only reports the version. > Is there a configuration file like in version > 2.3.1? No, you'd have to upgrade. > What if I want to add more logs for SSHGuard to monitor; is > there a way to tell the running daemon to monitor these additional > logs? While running, no. If you care about this, SSHGuard is experimenting with the ability to save blocks on exit, so restarting SSHGuard won't cause you to lose existing blocks. -- Kevin Zheng kev...@gm... | ke...@be... XMPP: ke...@ee... |
From: Ivan A. F. <iva...@gm...> - 2019-09-25 01:30:56
|
I'm runnng SSHGuard 1.7.1 on Debian Stretch with kernel 4.1.48-vs. This is a kernel running with the Linux-VServer patches. What happens if I run "sshguard -v"? Will it kill the daemon that is currently running? Is there a configuration file like in version 2.3.1? What if I want to add more logs for SSHGuard to monitor; is there a way to tell the running daemon to monitor these additional logs? Thanks in advance, Ivan. |
From: Jos C. <ssh...@cl...> - 2019-09-02 19:22:25
|
On 30-8-19 17:05, Kevin Zheng wrote: > SSHGuard's web host suffered a catastrophic failure, and as a result the > SSHGuard web site is currently down. We're working on bringing it back up. No worries - hope you will find a solution for this. -- With both feed on the ground you will never make a step forward |
From: Kevin Z. <kev...@gm...> - 2019-08-30 15:05:14
|
Hi there, SSHGuard's web host suffered a catastrophic failure, and as a result the SSHGuard web site is currently down. We're working on bringing it back up. In spite of this, business as usual on the mailing list, Bitbucket, SourceForge, and IRC channel. Regards, Kevin -- Kevin Zheng kev...@gm... | ke...@be... XMPP: ke...@ee... |
From: Christos C. <ch...@cr...> - 2019-08-30 13:01:15
|
Hello Kevin, This error appears mostly when PHP doesn't respond to Nginx. Kind regards, Christos Chatzaras > > On 8/29/19 2:52 AM, Christopher Engelhard wrote: >> Hi, >> for a while now the project website www.sshguard.net has been >> unavailable (502 Bad Gateway). Maintenance of error? > > Thanks for the report. I haven't been paying attention -- I don't think > this is planned maintenance. > > Regards, > Kevin |
From: Kevin Z. <kev...@gm...> - 2019-08-29 15:13:26
|
On 8/29/19 2:52 AM, Christopher Engelhard wrote: > Hi, > for a while now the project website www.sshguard.net has been > unavailable (502 Bad Gateway). Maintenance of error? Thanks for the report. I haven't been paying attention -- I don't think this is planned maintenance. Regards, Kevin -- Kevin Zheng kev...@gm... | ke...@be... XMPP: ke...@ee... |
From: Christopher E. <ce...@lc...> - 2019-08-29 10:09:36
|
Hi, for a while now the project website www.sshguard.net has been unavailable (502 Bad Gateway). Maintenance of error? Best, Christopher |
From: Kevin Z. <kev...@gm...> - 2019-08-05 16:39:21
|
Hi there, SSHGuard is now in the #sshguard IRC channel on Freenode. You're welcome to join us for help, discussions, suggestions, or just to stop by and say hi. If you need help connecting to Freenode, see: https://freenode.net/kb/answer/chat Regards, Kevin -- Kevin Zheng kev...@gm... | ke...@be... XMPP: ke...@ee... |
From: Kevin Z. <kev...@gm...> - 2019-06-10 16:03:30
|
Dear SSHGuard users, SSHGuard 2.4.0 is now available. If you are running an earlier version, and had issues with SSHGuard leaving processes running after killing the wrong process, you can upgrade to get a fix. **Added** - Match "Failed authentication attempt" for Gitea **Changed** - Log human-readable service names instead of service code **Fixed** - Correctly terminate child processes when ``sshguard`` is killed **Removed** - No longer accept logs given via standard input Regards, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xEACF0F76C22E1090 XMPP: ke...@ee... |
From: Kevin Z. <kev...@gm...> - 2019-04-08 01:19:19
|
Thanks for the report. I think there's a suggestion on how to completely kill things off, but we need to test more to make sure things work consistently across all operating systems. I think eventually we'll have to rewrite the driver script in C to get some sort of consistency... I was hoping we wouldn't have to do that but shells seem to do different things across the board. On 4/7/19 3:51 PM, giant@cock.email wrote: > This is in reply to the mail thread last written to on 2019-02-14. > > I also stumbled across this issue. OpenRC can track sshguard better if > you use the --pidfile flag in start-stop-daemon, as such > > start-stop-daemon --start --wait ${SSHGUARD_WAIT} --background --quiet > --pidfile ${SSHGUARD_PIDFILE} --exec \ > /usr/sbin/sshguard -- -i ${SSHGUARD_PIDFILE} ${SSHGUARD_OPTS} > > However, referring to below excerpt from the sshguard shell-script > (/usr/sbin/sshguard on Alpine Linux), when the service is stopped, > sshg-blocker and the shell-script will be killed, but the $tailcmd and > sshg-parser will continue, orphaned. > > eval $tailcmd | $libexec/sshg-parser | \ > $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$) > > I don't know why that is. > > > _______________________________________________ > sshguard-users mailing list > ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: <gi...@co...> - 2019-04-07 23:10:12
|
This is in reply to the mail thread last written to on 2019-02-14. I also stumbled across this issue. OpenRC can track sshguard better if you use the --pidfile flag in start-stop-daemon, as such start-stop-daemon --start --wait ${SSHGUARD_WAIT} --background --quiet --pidfile ${SSHGUARD_PIDFILE} --exec \ /usr/sbin/sshguard -- -i ${SSHGUARD_PIDFILE} ${SSHGUARD_OPTS} However, referring to below excerpt from the sshguard shell-script (/usr/sbin/sshguard on Alpine Linux), when the service is stopped, sshg-blocker and the shell-script will be killed, but the $tailcmd and sshg-parser will continue, orphaned. eval $tailcmd | $libexec/sshg-parser | \ $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$) I don't know why that is. |
From: Toby P. <tob...@gm...> - 2019-02-14 22:33:15
|
Kevin - Here you go: ------------------------------------------------------------------------------------------------------ #!/sbin/openrc-run # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 depend() { after iptables use logger } SSHGUARD_PIDFILE=${SSHGUARD_PIDFILE:-/var/run/${SVCNAME}.pid} start() { ebegin "Starting sshguard" [ -z "${SSHGUARD_WAIT}" ] && SSHGUARD_WAIT=999 start-stop-daemon --start --wait ${SSHGUARD_WAIT} --background --quiet --exec \ /usr/sbin/sshguard -- -i ${SSHGUARD_PIDFILE} ${SSHGUARD_OPTS} eend $? } stop() { ebegin "Stopping sshguard" start-stop-daemon --stop -p ${SSHGUARD_PIDFILE} eend $? } ------------------------------------------------------------------------------------------------------ ------ Original Message ------ From: "Kevin Zheng" <kev...@gm...> To: "Toby Poynder" <to...@wh...> Cc: ssh...@li... Sent: 14/02/2019 19:20:30 Subject: Re: [SSHGuard-users] openrc incorrect status >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 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus |
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. |