On 4/6/2013 2:13 PM, Max Pyziur wrote:
On Sat, 6 Apr 2013, Reindl Harald wrote:
if it is some ISP from a country far away -> block it if it is the fivth attempt from this ISP -> block the whole subnet
if it is a major ISP of the country i live (asutria) -> only absue mail to the ISP
I understand the logic; I set a low threshold to label something being a threat for anything originating in China; the threshold is higher for things closer to home, since most of the traffic to the one server I control is from there.
The problem with a non-automated system, such as manually blocking China, is that it does not easily and quickly adapt.
Both of the following I have experienced:
- Excessive spam and hacking from China. I blocked China. Then I got a client that did business in China and had a branch office there. Suddenly I cannot block login attempts from China. And the users complains loudly about the excessive reject rate of legitimate emails from Chinese customers due to the spam filters. Also, legitimate users in China pick weak passwords which get hacked. Convincing the customer to improve passwords, security, use a VPN for Chinese users to access email so I can block China again were unsuccessful.
While this is a bit beyond the scope of this list, the underlying problem is that in many far east countries, hacking is not illegal and thus there is no fear of getting caught, since there is no punishment. The real solution is to change those laws and have those countries enforce the laws. Good luck with that, however.
- I tried compiling a list of IPs used for hacking. As a test, I manually put them into the firewall to see if that stops anything. Results were that a single IP will attempt to brute force several hundred passwords, but then I never hear from that IP again, so the firewall block was pointless. However another, seemingly unrelated IP, takes up the brute force attack. Without an automated system, like fail2ban, I am just playing Whack-A-Mole and never actually manage to block any attempts.
In a different scenario, I also see 1-2 attempts from each IP in a group of thousands of IPs. These IPs do have legitimate users within them, so I cannot block whole IP ranges.
All these indicate that the brute force attacks are being implemented on zombie nets.
I do not see a perfect solution, or even a good one. A mediocre solution is a combination of fail2ban (which I have implemented), and enforcing strong passwords.
A feature that would be nice is if Dovecot could detect that X bad attempts for a given User ID happen in Y time, then that User ID is blocked (always gives back a bad authentication, even if the correct password is entered) for Z time. Also, Dovecot could slow down its reply, much like a tarpit. These would be configurable.
For example, if 3 bad password attempts are received for user@domain.com within 2 minutes, then the user is blocked for 10 minutes. That with strong passwords will make the system reasonably safe from zombie net attacks. Also, the tarpit feature would slow down the attacks and ease the bandwidth issue.
I am very willing to work with anyone on a solution that works better than these methods. As I see it, in order for a blacklist to work, it has to be large and distributed, like the spam blacklists are. Dovecot would need to report to the blacklist cloud, any IPs that it detects are being used to launch attacks. This is a big undertaking.
Dem