> Am 01.03.2015 um 10:25 schrieb Reindl Harald <h.rei...@thelounge.net>: > Am 01.03.2015 um 08:53 schrieb Jim Pazarena: >> I wonder if there is an easy way to provide dovecot a flat text file of >> ipv4 #'s which should be ignored or dropped? >> >> I have accumulated 45,000+ IPs which routinely try dictionary and >> 12345678 password attempts. The file is too big to create firewall >> drops, and I don't want to compile with wrappers *if* dovecot has an >> easy ability to do this. If dovecot could parse a flat text file of IPs >> and drop connections it would sure put a dent in these attempts. > > hence i asked month ago for RBL support because such lists are easy to feed > into http://www.corpit.ru/mjt/rbldnsd.html - sadly i got no reply than use > fail2ban and what not irrelevant if there is already a local dnsbl
I absolutely agree with Harald Reindl's findings on the advantages of DNSBL, but you have to see the big picture. Though I’ll speak about DNSBL a lot in this text, this is about blocking IPs in general. In my opinion, the *only* valid setup to use DNSBL are MTAs that accept mail from unauthenticated clients. That is because in such scenarios there are several heuristics you can safely use to distinguish the good from the bad. One of the most important aspects has to do with the distinction between mail submission and transmission. If you don’t want an open relay, you normally let your users authenticate before they can submit their mail. In any other case it’s safe to assume that the client is another MTA wanting to push a message over to you. We are talking about server systems here, not end users. Servers that should have a valid hostname, a static IP with no NAT in between etc. Blocking one IP in this case *should* really only block that one bad computer system. In the end, it’s perfectly OK to block clients that are either not authenticated, have no valid hostname, use dynamically assigned IPs etc. from accessing your MTA. Once having checked that one may put single IPs on a private block list to speed things up. In the case of HTTP, IMAP, etc. things are not so easy. Just think about NAT and CGN. You as a service provider *can* never know that there’s no collateral damage when you block an IP address. Every single IP out there could be a gateway to a private or even carrier grade network with hundreds or thousands of computers behind it. Some of them might be infected by malware or controlled by a bad guy. Some others might be those your clients use to download their mail. You’d lock them all out—just because you want to safe some server resources? Is it really worth it? Imagine one of your customers traveling abroad, using unusual POPs to access your dovecot instance. If the gateway IP that your server sees is blocked, you lock out your own customer. It’s the old tale. Some words of advice: (1) There’s no point in listing thousands of IPs without proper TTL. And that TTL should be short! If there really were 45 000 single /32 IPs that were behaving rude at some point in the past, how can you be sure these addresses are still doing so? Moreover, with IPv4 addresses being rare and IPv6 only being deployed slowly, CGN happens to be used more often than in the past. Even with IPv6, where prefixes were initially meant to be static, there are many ISPs that don’t give their line customers static IPv6 prefixes. That means attackers as well as your customers might end up using many different addresses over time. (2) If you run your own block list and were to add another IP, there should be sufficient knowledge about the origin of the attack. Always check the RIR whois databases, look at the delegated address range the IP is in, the country, the owner of the network, hostnames... Monitor your log files and try to detect patterns. [Honestly, I’d not be willing to invest the time ;-) ] (3) Use a scoring system. If there are other DNSBLs that list the IP or network in question, the likelihood of causing more harm than good is a bit lower than if you are the only one suffering an attack. Community based DNSBLs are commonly a good thing. You see, blocking IPs just because it’s simple and effective (for the moment) might not be what you want. I’d rather let my users choose stronger passwords, strongly enforce TLS and scale up my server systems to handle the bad traffic. Surely, it depends on your own case, just don’t be naïve and think that blocking IPs is a general solution to anything nowadays. It might very well work for you if you don’t have a lot of customers, though. Speaking about dovecot, I doubt direct DNSBL integration will happen upstream because dovecot already supports access lookups. You can use dovecot's tcpwrap and configure your /etc/hosts.deny to lookup an external ACL program that in turn consults your DNSBL. See man hosts_options, section RUNNING OTHER COMMANDS. Look for »aclexec«.[1] I guess that should get you on track. Just be warned that this solution (a) spawns a new tcpwrap instance for each new client connection, and (b) also spawns a new process of your custom acl program. Cheers, Felix [1] http://manpages.ubuntu.com/manpages/quantal/man5/hosts_options.5.html
signature.asc
Description: Message signed with OpenPGP using GPGMail
