On Mon, Apr 16, 2018 at 09:08:43AM +0200, mailman-admin wrote: > Brute Force attempts can only be mitigated by e.g. fail2ban.
Nope. There are other ways. Brute force attacks can be pre-emptively blocked by nearly everyone operating a Mailman instance. (I say "nearly" for specific reasons that will become clear below.) 1. You'll need a firewall, either in front of your Mailman instance or onboard the same system, that can handle a significant number of IP ranges in CIDR format. I highly recommend "pf", which is part of OpenBSD (among others) and is easily the best firewall available. However, you can do this with other firewalls such as iptables just as readily. 2. Get the Spamhaus DROP (Don't Route Or Peer) list, along with the EDROP list: http://www.spamhaus.org/drop/drop.txt http://www.spamhaus.org/drop/edrop.txt They're small. Take a look at them. The DROP/EDROP lists are well-curated and consist of blocks that are known to be hijacked and known to belong to malicious actors. You should *bidirectionally* block *all* traffic to/from the networks listed on them: HTTP, SMTP, DNS, everything. Update them by fetching new copies once a month. 3. The next step depends on the intended audience for your mailing lists. If you're operating one for a bowling league in Akron, Ohio, then you probably don't need to accept subscription attempts from Peru, Pakistan, or Portugal. If on the other hand you're operating one with global reach then you'll need a different approach. In either case, you'll want ipdeny.com's list of all network blocks by country: http://ipdeny.com/ipblocks/data/countries/all-zones.tar.gz and you may want the Okean lists of blocks for China and Korea: http://www.okean.com/chinacidr.txt http://www.okean.com/koreacidr.txt (In theory, the list of CN and KR blocks in ipdeny's compilation should exactly match Okean's. In practice, there are slight differences that tend to resolve over time. I think if you're only configuring for CN and KR, use the latter; if you need more, use the former. But we'll get to that.) By the way, if you use these, you should update them once a month just like the DROP/EDROP lists. 3a. If your list is localized to one country or two or six, then use the ipdeny data to configure your firewall to block *all* HTTP traffic to your mailman instance and then only allow traffic from the countries that you need. This usually takes a huge bite out of incoming abuse. 3b. If your list is global or nearly so in scope, then block as many countries as you can. Look at your logs, see where the attacks are coming from, see where real subscriptions are coming from, and figure out the disjoint set. (The utility "grepcidr" is often very helpful.) If you have, let's say, zero subscriptions from FR over the past nine years but do have a parade of attacks: firewall it out. I recommend, in doing this analysis, that you start by looking at CN and KR. Why? Because two decades of careful logging and analysis of data from quite a few sites indicates that these are #1 and #2 on the hit parade of attackers. There's no point in trying to file complaints in the hope that some responsible professional will take remedial action and make it stop: just firewall and forget. (Next on the list are RU and IN. Same problems.) Comment on 3a and 3b: Yes, this is draconian. That's a good thing. Let me quote for you what I think is arguably the best thing ever said on NANOG, and given the tens of thousands of years of accumulated network experience represented there, that's saying a lot: If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well". --- Paul Vixie You can either get to work with a firewall or you can continue to be a victim. Choose. If you want to continue to allow SMTP traffic from these countries so that users can subscribe/unsubscribe/etc. via mail that's your call. I've tailored my configuration to suit the lists that I run and in some cases, that includes configuring the MTA to deny traffic from the same ranges as the web server; in others, it includes denying traffic from the TLD; in others, both. The key to all of this is understanding (a) what you need to allow in order for your lists to function as intended and (b) what your own logs are telling you about what attacks/abuse are coming from. 4. Supplement this by blocking operations that are unlikely to originate any valid subscriptions but are likely to originate abuse. For example, Amazon's cloud -- due to the negligence and incompetence of the people running it -- is a notorious source of nonstop brute-force attacks. They not only refuse to do anything about it, they refuse to even accept complaints. So you might want to firewall AWS outright. (By the way, you most certainly want to block it from any ssh services you run.) Digital Ocean is similar. And there are others. I have compiled full/partial network blocks for these if you want them. Yes, this is also draconian. But I'm done playing around with ignorant newbie lusers -- like the ones at Amazon -- who can't or won't run their networks properly. And I'm not interested in pathetic excuses like "we're too big to watch our own network" or even more feeble ones like "we get too many complaints". Can't handle Operations 101? Shut down the systems, turn off the power, lock the doors, and go home. You're. Not. Good. Enough. 5. Supplement all of this with individual blocks as the need arises. Watch your own logs and look for patterns. If you want to drop individual IP addresses into the firewall, sure, but since attacks generally originate from multiple addresses on a network, it's usually faster, easier, and more efficient to just plonk entire networks. I have some of these compiled as well, although the ones attacking my resources may not be the same as the ones attacking yours. "whois -h whois.arin.net" is your friend. Hint: if you watch your logs long enough and pay attention to what's in them, you'll probably notice that many attack patterns are localized. One of the quick-and-dirty approaches that is often quite effective is to assume that each attacking IP address is part of a /24 (even though is might really be a /28 or a /16) and block the entire putative /24. Yes, this assumption is often wrong, BUT it usually doesn't matter if it's wrong, because the goal here is to stop the attacks from getting through. (Why a /24? Because in some implementations, network blocks that size or larger are handled more efficiently than smaller ones. For example, I never block anything smaller than a /24 in the sendmail access file.) Folks who've never done this before and haven't looked at their logs often think this is too much. It's not. If you spend enough time looking at the data, it becomes apparent in most cases that if you're seeing attacks from one IP address on a network, it's only a matter of time until the second and third and forty-second show up. Might as well block them now and avoid the annoyance. 6. Yes, all of this can be bypassed with proxies and VPNs and Tor and botnets and and and. It's not a panacea. But it does take the edge off, and that in turn makes the remaining problem more tractable. If you do this diligently, you'll find that you'll steadily have less to do. And pre-emptive blocking like this is vastly more effective that reactive blocking like fail2ban, if for no other reason than it makes your logs smaller and easier to deal with. I wish none of this was necessary. It *shouldn't* be necessary. But a lot of operations are run by negligent, incompetent people, and others are run by people who are deliberately allowing attackers and abusers to use their networks. We are well past the time when asking either of these nicely if just maybe they'd like to show some professional responsibility and run their networks properly: there is no point in it. Firewall and forget. ---rsk ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org