On 16-Apr-18 07:38, Rich Kulawiec wrote: > 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. Good advice.ï¿½ But use httpS: (and make sure the UA validates the server certificate). Unless you fancy experimenting with DOS attacks. > 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.) Yup.ï¿½ And iran and afghanistan & the other former soviet countries.
But the biggest source of attacks, by far, is the US.ï¿½ Unfortunately, while some people run business that don't interact with the US, in most cases a non-country based approach is necessary for that :-) > 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. If you have iptables, you also might want to look at https://github.com/tlhackque/BlockCountries A new release that provides better management is overdue -- but hopefully soon. BlockCountries manages the by-country blocking, and the next release will support fetching the spamhaus (and other) non-country lists.ï¿½ It handles both the "block these" and "permit only these" paradigms, and does a fair amount of optimization of the rulesets.ï¿½ It also handles IPv6 & has a bunch of options that let you avoid most of the hassle of working directly with iptables for exceptions. You do need to be careful to balance reducing your attack surface with your business' need for access.ï¿½ Also, be aware that the "by-country" blocking lists of ipdeny come from the regional registries.ï¿½ They are not exact.ï¿½ They don't necessarily reflect the server's actual current physical location for a number of reasons.ï¿½ But they are a reasonable approximation.ï¿½ Just be sure that you have an easy way to introduce exceptions when one of your customers is blocked. I also recommend https://zeustracker.abuse.ch/blocklist.php (add?download=badips for the data). > > 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. The best defense for ssh is to configure it for certificate authentication only. The script kiddies will make their 10,000 login attempts - while they're busy annoying you, they're not attacking someone else.ï¿½ Or so one hopes.ï¿½ï¿½ fail2ban is also useful if you're not so civic minded... [I'm not kidding; I do see lists of 10K+ attempts from "adam adam", "adam password" thru "zeke password" "zeke zeke"...] If you keep up your lists of cloud services' network blocks & have them on a publicly accessible website, I'll add them to my list of optional block lists.ï¿½ (Hopefully you use a standard format - e.g. ipaddress[/netmask or length] with # or ; comments...) > 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. Whatever lists you use, it's really important to stay up to date.ï¿½ (I generally recommend weekly or monthly.)ï¿½ The attackers are mobile and adapt.ï¿½ That cuts both ways: if you block a specific attack today, tomorrow they may well have moved to another host.ï¿½ Then you have to block them again.ï¿½ And, the block that they vacate may be assigned to a legitimate use - that you don't want to block. Be very careful not to block your customers or users; it is easy to be overly aggressive, which can be career limiting. > 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 > Sadly, this is true.ï¿½ However, e-mail to abuse@<provider> can be effective if you provide details... -- This communication may not represent my employer's views, if any, on the matters discussed. ------------------------------------------------------ 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