I was seeing the same thing until I modified the 'helo' plugin
https://forums.contribs.org/index.php?topic=53223.15 to block connections during 'helo' instead of allowing them to attempt authentication first. This works for me, but could block roaming or remote users in some instances.
I've also implemented the
emerging threats blocklists on my server along with the
firehol update-ipsets block lists on my firewall. (My notes on this are somewhat tangled at present, and might not be particularly useful...)
Here are my recent stats:
Queued: 1374 (2 marked as spam)
Denied: 589
HELO/EHLO rfc: 408 (69 %)
Greylisting: 76 (13 %)
Naughty (DNSBL): 72 (12 %)
Early Talker: 16 ( 3 %)
RHSBL: 10 ( 2 %)
Failed Authentication: 3 ( 1 %)
Resolvable FromHost: 3 ( 1 %)
Relaying Denied: 1 ( 0 %)
SMEOptimizer: 0 ( 0 %)
Naughty: 0 ( 0 %)
DNSBL: 0 ( 0 %)
URIBL: 0 ( 0 %)
Invalid Host: 0 ( 0 %)
Spamassassin: 0 ( 0 %)
Virus: 0 ( 0 %)
TLS/SSL Problem: 0 ( 0 %)
Unrecognized Commands: 0 ( 0 %)
Server Overloaded: 0 ( 0 %)
Blacklists:
Spamhaus: 46 (56 %)
Gbudb: 21 (26 %)
Dnsbl: 12 (15 %)
Spamcop: 2 ( 2 %)
@400000005cd4f9f921dafff4 28796 (deny) logging::logterse: ` 73: 1 ( 1 %)
Most active IP addresses:
108.174.200.214: 291
192.168.200. 1: 20
89. 38.150.163: 10
94.177.241.246: 6
89. 36.213. 74: 6
94.177.240.167: 5
187. 60.216.196: 4
92. 87. 41. 93: 4
201.158. 37.116: 4
105.228.132. 92: 4
(The oddball entry under 'blacklists' is due to a misconfiguration of the barracudacentral DNSBL service, I hope...)
My current theory on failed login attempts goes like this:
- Criminal organizations, governments, or others maintain databases of internet-accessible system fingerprints - what services are running, what versions, etc. These databases will accrete information from any system that leaks information to which the monitoring organization has access. If they can hack your ISP, the database would include logs of online services visited from your network, possibly usernames, email correspondents, etc. They might use google or facebook ads, or compromised websites, to harvest information on your systems and users for their database. It is important to realize that none of this may be targeted specifically at you - the objective is 'google-esque' - gather information from everywhere, correlate what can be correlated, and save the rest in case it correlates with some other data in the future.
- These orgs then setup processes to monitor the systems and users cataloged in their database - the monitoring system generates the failed logins while serving several simultaneous functions:
1) allowing a slow-motion dictionary attack
2) allowing compromised credential databases to be targeted where appropriate (since they could have harvested your users' facebook usernames and associated email addresses, if they get their hands on facebook's password database they can immediately try your users' facebook usernames and passwords on your server)
3) development of a 'social network' for your server - who communicates with whom and what they talk about. This information can be used in social engineering attacks ("hey jim - check out this PDF", etc)
4) monitoring that the identified services remain accessible so that new data or vulnerabilities can be applied immediately.
5) attack debugging -- if the database includes 1000 systems with the same service exposed, an attack under development can be debugged against a small subset of systems, fine-tuned, re-tried on another subset, etc.
- When a zero day vulnerability surfaces, or a new credential database is hacked, your server (if vulnerable) or users (if included in the credential database) will be attacked according to the priority that has been assigned to your resources in the attacker's database. Minutes or hours, rather than days or weeks as we are accustomed to thinking.
My conclusions from this
paranoid theoretical scenario:
- security patches must be installed as quickly as possible (within hours of release, if possible)
- fail2ban may not be quick enough to block an attack -- if an attacker already has a profile of my server and becomes aware of a new vulnerability the attacker may need only a single connection to effect a compromise.
- IP blocklists such as emergingthreats and the firehol update-ipsets lists give me the best chance to block traffic from malicious hosts based on the experience of others before the attackers get around to my server.
- Traditional passwords cannot be trusted to provide real security. 2FA or device fingerprinting plus passwords should be implemented as quickly as feasible.
- Users must be trained to identify social engineering attempts
[apologies for hijacking your post...]