significant rise in fail2ban alerts for ssh abuse
Dear all, we receive a significant rise of ssh login abuse mails which reach us and unfortunately our providers. By significant I mean an amount that starts flooding our abuse inbox. All abuse emails are structured the same way and point to Fail2Ban as originator. Do we have just bad luck and someone uses our severs to brute force all of SSH out there OR is there a new Fail2Ban or Linux distribution release which fosters or enables this fail2ban abuse mails be default ? As far as I know the functionality of Fail2Ban is old. If there would be a Linux distribution which enables this I would like to talk to the maintainer and let him know that he at least tries to read the correct abuse entry from ripe instead of bothering our provider as well. For a limited time we will now reject port 22. But really do not like this solution. I would rather like to find out the source of this rise in numbers. best regards Dirk Example 1 ---- Dear Sir/Madam, We have detected abuse from the IP address 1.1.1.x, which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate. Log lines are given below, but please ask if you require any further information. (If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was generated by Fail2Ban.) Note: Local timezone is +0300 (MSK) Aug 6 08:35:23 srv sshd[3534]: Invalid user admin from 1.1.1.x Aug 6 08:35:25 srv sshd[3534]: Failed password for invalid user admin from 1.1.1.x port 50789 ssh2 Aug 6 08:35:25 srv sshd[3534]: Connection closed by 1.1.1.x [preauth] Aug 6 12:26:03 srv sshd[28169]: Invalid user admin from 1.1.1.x Aug 6 12:26:05 srv sshd[28169]: Failed password for invalid user admin from 1.1.1.x port 35677 ssh2 Aug 6 12:26:06 srv sshd[28169]: Connection closed by 1.1.1.x [preauth] Example 2 ---- Dear Sir/Madam, We have detected abuse from the IP address 1.1.1.x, which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate. Log lines are given below, but please ask if you require any further information. (If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was generated by Fail2Ban.) Note: Local timezone is +0200 (CEST) Aug 7 17:41:14 vps3xxx sshd[32746]: Invalid user admin from 1.1.1.x Aug 7 17:41:14 vps3xxx sshd[32746]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=1.1.1.x Aug 7 17:41:16 vps3xxx sshd[32746]: Failed password for invalid user admin from 1.1.1.x port 60497 ssh2 Aug 7 17:41:16 vps3xxx sshd[32746]: Connection closed by 1.1.1.x port 60497 [preauth]
I can‘t talk about the source, but there are indeed more and more script kiddies out there who use Tor or VPNs just to test around. They hook up Linux Kali and thinking they are becoming the next big hacker. I‘ve read from another provider which supports tor exit, that they only accept exits if mail, irc and ssh ports are blocked, because they are the biggest vectors for abuse messages. So i guess you are not alone...
On Thu, Aug 10, 2017 at 4:15 PM, Keepyourprivacy <keepyourprivacy@protonmail.ch> wrote:
I can‘t talk about the source, but there are indeed more and more script kiddies out there who use Tor or VPNs just to test around. They hook up Linux Kali and thinking they are becoming the next big hacker. I‘ve read from another provider which supports tor exit, that they only accept exits if mail, irc and ssh ports are blocked, because they are the biggest vectors for abuse messages. So i guess you are not alone...
I also got endless complaints about port scans until I removed port 22 from cmutornode's exit policy. Tried turning it back on a few times, and the complaints started up again immediately. It's sad, because ssh-over-tor is actually quite valuable. zw
Hello, maybe I expressed it wrong. We are quite used to the usual abuse mails based on ssh brute forcing since we have several years of operation with several exits out of Switzerland. The astonishing thing is that now every one seems to have an Fail2Ban configuration which does automatic abuse response to the abuse box and the network operator abuse address. I rather think this is driven by a software release which does a lot of this automatic or semi automatic. And I would like to find the maintainer and convince him only to write to the offical abuse email address than additionally to the network operator. Any hint where this improved fail2ban config comes from is welcome. best regards Dirk On 10.08.2017 22:15, Keepyourprivacy wrote:
I can‘t talk about the source, but there are indeed more and more script kiddies out there who use Tor or VPNs just to test around. They hook up Linux Kali and thinking they are becoming the next big hacker. I‘ve read from another provider which supports tor exit, that they only accept exits if mail, irc and ssh ports are blocked, because they are the biggest vectors for abuse messages. So i guess you are not alone...
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
This is not any kind of evidence to suggest a rise in abuse mails resulting from fail2ban. Keepyourprivacy:
I can‘t talk about the source, but there are indeed more and more script kiddies out there who use Tor or VPNs just to test around. They hook up Linux Kali and thinking they are becoming the next big hacker. I‘ve read from another provider which supports tor exit, that they only accept exits if mail, irc and ssh ports are blocked, because they are the biggest vectors for abuse messages. So i guess you are not alone...
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi Drik, hi List On 10.08.2017 21:34, Dirk wrote:
As far as I know the functionality of Fail2Ban is old. If there would be a Linux distribution which enables this I would like to talk to the maintainer and let him know that he at least tries to read the correct abuse entry from ripe instead of bothering our provider as well.
I took a look into the Fail2ban source code[0] today. Although I now have a better understanding of how Fail2ban works I can not really provide the problem source. * The feature that causes abuse mails is called 'complain'[1]. * Since Feb 2014 Fail2ban is using a web service called abusix.com[2] to get abuse contacts. They run a DNS based abuse contact info service, e.g.: Absuse Contact for example.com / 93.184.216.34 looks like this: $ dig +short TXT 34.216.184.93.abuse-contacts.abusix.org * As response they provide one abuse mail contact, which is in our case always our ISPs abuse address. abusix.com in turn gets their information from the RIPE API[3]. e.g.: curl https://stat.ripe.net/data/abuse-contact-finder/data.json?resource=93.184.21... This answers the question of why Fail2ban is using our ISPs abuse contact instead of only ours. It also answers the question how they get this abuse contact. But in all those samples the abuse notice was sent to our ISPs abuse contact and to ours. So far I can not say why they use both contacts.
From checking the source I can not find the whois lookup that would parse our abuse contact out of our RIPE object record.
I also checked the commit history for the following keyword: abuse: last occurrence 19. Feb 2014 whois: last occurrence 27. Mar 2015 mail : nothing related in the last two years My findings let me assume that Fail2ban itself is not necessary the source of our problem (increasing 22/ssh abuse mails). Possible other problem causer could be: * Fail2ban OS specific configuration files * a (new?) popular Fail2ban how-to-guide which promotes the 'complain' configuration * Maybe neither of both changed something and we just had bad luck in the past weeks? Maybe someone else has real world experiences with Fail2ban and can help us out here? I posted all this to the list in the hope they will help someone else in the future. Regards Pascal [0] https://github.com/fail2ban/fail2ban [1] https://github.com/fail2ban/fail2ban/blob/0.11/config/action.d/complain.conf [2] https://github.com/fail2ban/fail2ban/commit/31f4ea59cb86fb91221778902b7e6776... [3] https://github.com/fail2ban/fail2ban/issues/612
On 15 Aug 2017, at 02:57, Ryru <ryru@addere.ch> wrote:
Hi Drik, hi List
On 10.08.2017 21:34, Dirk wrote:
As far as I know the functionality of Fail2Ban is old. If there would be a Linux distribution which enables this I would like to talk to the maintainer and let him know that he at least tries to read the correct abuse entry from ripe instead of bothering our provider as well.
I took a look into the Fail2ban source code[0] today. Although I now have a better understanding of how Fail2ban works I can not really provide the problem source.
* The feature that causes abuse mails is called 'complain'[1].
...
My findings let me assume that Fail2ban itself is not necessary the source of our problem (increasing 22/ssh abuse mails).
Possible other problem causer could be: * Fail2ban OS specific configuration files * a (new?) popular Fail2ban how-to-guide which promotes the 'complain' configuration * Maybe neither of both changed something and we just had bad luck in the past weeks?
Maybe someone else has real world experiences with Fail2ban and can help us out here?
Our experience is that our email provider took a few months to identify Fail2ban emails as spam, and automatically delete them. We haven't seen any since then. It's no great loss. Perhaps there have been changes to Fail2ban that have evaded some automated filters, or your email provider changed their spam filter config. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
participants (6)
-
Dirk -
Duncan -
Keepyourprivacy -
Ryru -
teor -
Zack Weinberg