Re: [Mailman-Users] Brute force attacks on mailman web ui
On 19-Apr-18 23:33, Stephen J. Turnbull wrote: > tlhackque via Mailman-Users writes: > > > I'm not sure what you are looking for. > > I'm looking for anything that will help block swaths of Chinese > spammers and possibly attacks, while allowing me to do a better job of > serving students vacationing at home in China than treating them the > way the Chinese government does. A unicorn, or failing that, a pony. So you know exactly who your users are, and can pre-register them while they are not in China. Geographic IP address is the wrong hammer for this nail. Block the country, open pinholes for the users. > No, I want to identify good actors and block the rest. The problem > I've had in the past is that I can't depend on static IPs because I'm > dealing with people using telephones, mostly. GeoIP will never get you down to the level of granularity and accuracy that you want. Even if it did, people with phones move - apartment, coffee shop, etc. > > One option is to provide a website for registering your users, then > > allow them access via some convenient token. > > I'm not sure what you're suggesting. That's what is being attacked > here. If you're seeing webserver attacks, you'll also see mailserver AUTH attacks. I assumed both. It's easier to protect a website than a mailserver. Plus, registration is a one-time activity. And in your scenario, you can block all of China, since you can register your students while they are at your school (which presumably is not in China). So use the registration website to issue an X.509 certificate, register a hardware token, issue fwknop key - whatever you choose as your token (credential). Then use that token to protect routine access to the mailman web ui AND mail servers. Even if you allow registration from China, you can make the registration website available at limited times. E.g. odd days of the month from 1341 to 1417. This drastically reduces your attack surface. You tell your users the algorithm for when they can use it to register, or more likely, invalidate a lost key & get a new one, etc. Change it every semester. > > Or provide a VPN (with just your web or email server as an > > endpoint). > > I believe the Chinese have outlawed VPNs, I assume they allow TLS > still, though, given the size of ecommerce there. I believe you are correct. They may use spoofing on TLS, so unless you use some form of pinning, assume MITM. > > Or use X.509 client authentication - note that you can use this > > with your mailserver. > > That's an interesting idea, but again my users will be mostly using > phones, so I don't think this will work with mail very well, and I'm > not sure how to set that up on a phone. Mobile MUAs not my area of expertise, but it ought to be possible. Both sendmail and postfix allow it to be configured. Even if you don't have a native MUA, you can provide a web-based e-mail account on your server for your users - e.g. squirrelmail, roundcube, etc. Put client auth on that (easy); allow that server access to your e-mail server, perhaps just on localhost. Mobile web browsers certainly support x.509 client auth. If you go this route, you only need to open a TLS port; you don't need IMAP/POP3/SMTP/Submission. You will still get kiddie script attempts, but TLS will block them for lack of a (valid) client certificate. These are less common, and combined with fail2ban should work reasonably well. From your revised description, fwknop seems to be a good choice. It's cheap, transparent, easy to setup, and should traverse the great firewall. (No direct experience, but the technology is hard to block, especially if you overlay it on a web or mail server.) You can use it to protect both. Issue their keys before they go home, and you're done. Optionally, provide some form of recovery/reissue for the "I lost my phone" case. Or just say "don't lose your phone; if you do, you're out of luck for the rest of your trip." Providing an e-mail service as outlined above is more expensive, but provides an additional service for your users. In any case, I think we've probably exhausted the patience of mailman-users since we're off into the general problem of keeping our servers alive in the jungle... Good luck. -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
tlhackque via Mailman-Users writes: > I'm not sure what you are looking for. I'm looking for anything that will help block swaths of Chinese spammers and possibly attacks, while allowing me to do a better job of serving students vacationing at home in China than treating them the way the Chinese government does. A unicorn, or failing that, a pony. > There are a number of geolocating services that attempt to turn IP > addresses into specific locations; for example maxmind offers a series > of databases of increasing precision for increasing prices (starting > with free). I'll try their free offering. Thank you! > But the problem is that unless you know exactly where your users (and > potential users) are located, this won't help. Do you have a list of > cities? Streets? I can frequently get down to the street level for valid users, yes, at least after first contact. > What you probably want is to identify the specific bad actors; No, I want to identify good actors and block the rest. The problem I've had in the past is that I can't depend on static IPs because I'm dealing with people using telephones, mostly. > As previously noted, fail2ban is one reactive means of dealing with > these - it reads log files and dynamically blocks IP addresses that > generate errors. It can be resource intensive, especially if you want a > reasonably fast reaction time. And specifying bad behavior is somewhat > of an art. I wouldn't call it art, but a few years ago I had a 1MB .procmailrc. :-) > One option is to provide a website for registering your users, then > allow them access via some convenient token. I'm not sure what you're suggesting. That's what is being attacked here. > Or provide a VPN (with just your web or email server as an > endpoint). I believe the Chinese have outlawed VPNs, I assume they allow TLS still, though, given the size of ecommerce there. > Or use X.509 client authentication - note that you can use this > with your mailserver. That's an interesting idea, but again my users will be mostly using phones, so I don't think this will work with mail very well, and I'm not sure how to set that up on a phone. > For this purpose, you want your own CA for X.509. Sure. > However, if you're trying to attract people who don't know if they > are interested, the cost of connecting with you would probably turn > many away. The prospect of graduate study outside of China seems to be a strong motivator so far. We'll see if it interests people in conforming to practices that increase my security. Interesting thoughts, anyway. Steve -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
Quoting Rich Kulawiec (r...@gsp.org): > 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.) Great writeup. This is exactly how I've had my firewall configured for some time, with the drop/edrop and country block lists. I monitor for breakin attempts and add country blocks as needed... it's interesting that this seems to be somewhat cyclical in my experience, in that one month 80% of my brute force attacks are from Turkey, then the next month it shifts to Brazil (as examples, but I have both of these countries blocked now). -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
On Thu, 2018-04-19 at 10:08 -0700, Natu wrote: > On 04/17/2018 08:27 PM, Carl Zwanzig wrote: > > On 4/17/2018 7:20 AM, Rich Kulawiec wrote: > >> I stood up a new server last fall with *no* valid ssh access and logged > >> about 750,000 attempts in a month. Similar patterns. > > > > There's a reason I don't put sshd on port 22; moving it elsewhere and > > blackhole-ing 22 cut the auth log tremendously. > > > > ( > > If you have no users logging in remotely or if users are technical > enough, consider using fwknop for ssh and other services. I also use > openvpn or openvpn with fwknop to access the vpn. I've found fwknop to > be rock solid, and I've never had even a single attack on services that > use fwknop. http://www.cipherdyne.org/fwknop/ Once again, do yourself a favor and check out fail2ban. It's in use on my company's server and works wonders on stopping brute force attacks on ALL services affected. -- Lindsay Haisley | "The first casualty when FMP Computer Services | war comes is truth." 512-259-1190 | http://www.fmp.com| -- Hiram W Johnson -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
On 04/17/2018 08:27 PM, Carl Zwanzig wrote: > On 4/17/2018 7:20 AM, Rich Kulawiec wrote: >> I stood up a new server last fall with *no* valid ssh access and logged >> about 750,000 attempts in a month. Similar patterns. > > There's a reason I don't put sshd on port 22; moving it elsewhere and > blackhole-ing 22 cut the auth log tremendously. > > ( If you have no users logging in remotely or if users are technical enough, consider using fwknop for ssh and other services. I also use openvpn or openvpn with fwknop to access the vpn. I've found fwknop to be rock solid, and I've never had even a single attack on services that use fwknop. http://www.cipherdyne.org/fwknop/ Natu -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
On 19-Apr-18 02:46, Stephen J. Turnbull wrote:
> So here's my problem. A lot of my constituency resides in CN,
> occasionally including people at frequently problematic domains like
> 163.com. Do you know any resources (or keywords to start googling
> even!) at subnational levels? KR and CN breakdowns would be most
> useful to me; breakdowns for RU and former USSR would be appreciated
> by many of my colleagues.
>
I'm not sure what you are looking for.
Blocking by geography is a very crude tool - it turns out to be useful
in that many hosts serve limited geographies, and it's pretty easy to
identify countries that generate a lot of "bad" traffic. E.g. RU & CN
are widely believed to support intrusions by (pseudo/)government actors,
and rarely prosecute.
As you discovered, below that level, you need to use other tools.
There are a number of geolocating services that attempt to turn IP
addresses into specific locations; for example maxmind offers a series
of databases of increasing precision for increasing prices (starting
with free).
You can use these databases with your webserver (e.g. apache mod_geoip)
and name server (BIND for sure). There is also a GeoIP module for
iptables. (I use (and maintain) BlockCountries because it is more
flexible and easier to use. YMMV).
But the problem is that unless you know exactly where your users (and
potential users) are located, this won't help. Do you have a list of
cities? Streets? I don't think that the criminal element has easily
identifiable geographies.
What you probably want is to identify the specific bad actors; for that
the spamhaus and other "block lists" ("RBL") are helpful. Most of these
are distributed via DNS - which means that they aren't practical for
firewalls. You can configure your email server (e.g. sendmail/postfix)
to use them. But this happens inside your firewall. These lists are
fairly well curated, but certainly aren't perfect.
As previously noted, fail2ban is one reactive means of dealing with
these - it reads log files and dynamically blocks IP addresses that
generate errors. It can be resource intensive, especially if you want a
reasonably fast reaction time. And specifying bad behavior is somewhat
of an art.
One option is to provide a website for registering your users, then
allow them access via some convenient token. A Captcha will help to
reduce fraudulent registrations. E.g., if they have a static IP
address, register that. Or provide a VPN (with just your web or email
server as an endpoint). Or use X.509 client authentication - note that
you can use this with your mailserver. For this purpose, you want your
own CA for X.509. You can revoke abused tokens. If your community is
small (or willing to pay), you can look at hardware tokens, such a yubikey.
That will work if you have a reasonably sized community - and people
really want to use your service. However, if you're trying to attract
people who don't know if they are interested, the cost of connecting
with you would probably turn many away.
It's a balancing act, and your business (community, etc) needs will
determine what is best for you.
Note that I'm not exclusively endorsing any of the products/services
mentioned - there are alternatives, and you need to evaluate what each
offers against your needs.
Unfortunately, there's no universal answer.
Good luck.
--
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
Re: [Mailman-Users] Brute force attacks on mailman web ui
Rich Kulawiec writes: > 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.) Nice summary! > 3. The next step depends on the intended audience for your mailing > lists. So here's my problem. A lot of my constituency resides in CN, occasionally including people at frequently problematic domains like 163.com. Do you know any resources (or keywords to start googling even!) at subnational levels? KR and CN breakdowns would be most useful to me; breakdowns for RU and former USSR would be appreciated by many of my colleagues. > 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. This is helpful regardless of whether there are subnational breakdowns. I got the point the first time! :-) Regards, Steve -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
On 4/17/2018 7:20 AM, Rich Kulawiec wrote: I stood up a new server last fall with *no* valid ssh access and logged about 750,000 attempts in a month. Similar patterns. There's a reason I don't put sshd on port 22; moving it elsewhere and blackhole-ing 22 cut the auth log tremendously. (Nothing to do with mailman, though.) z! -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
On Mon, Apr 16, 2018 at 02:05:35PM -0400, tlhackque via Mailman-Users wrote: > Good advice.??? But use httpS: (and make sure the UA validates the server > certificate). > Unless you fancy experimenting with DOS attacks. Yep. You're exactly right. > 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 :-) Yes. There's no question that the US is a huge source of attacks, and if I were running a mailing list for birdwatchers in Australia, I'd seriously consider blocking it. But you're right, that bumps into all kinds of hosting/infrastructure issues and so blocking the whole country will likely have unpleasant side effects. > https://github.com/tlhackque/BlockCountries > A new release that provides better management is overdue -- but > hopefully soon. That...is cool. Thanks for the pointer. > The best defense for ssh is to configure it for certificate > authentication only. >The script kiddies will make their 10,000 login attempts [...] True, but I find the clutter in logs annoying. ;) So in situations where I know a priori that a valid login attempt will never originate from an operation, I just firewall it and let them eat dropped packets. > [I'm not kidding; I do see lists of 10K+ attempts from "adam adam", > "adam password" thru "zeke password" "zeke zeke"...] I stood up a new server last fall with *no* valid ssh access and logged about 750,000 attempts in a month. Similar patterns. > 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...) I keep them in CIDRnetwork-name but honestly I'm not diligent enough about maintaining them. As a result, they're always under-inclusive (very rarely over-inclusive). That works for what I use them for, but I'm hesitant to inflict my laziness on others. Let me see if I can locate someone who's doing a better job than I am. ---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
Re: [Mailman-Users] Brute force attacks on mailman web ui
On Mon, 2018-04-16 at 11:06 -0700, Mark Sapiro wrote: > On 04/16/2018 10:45 AM, Lindsay Haisley wrote: > > > > Apache will log the access, with IP addresse, but to the best of my > > knowledge it won't log a Web UI login failure since this is an internal > > matter for Mailman. > > > As I said in my prior reply, Sorry, Mark. I've been running about and missed your reply. > all Mailman login failures return a 401 > status. Just look in the Apache logs for Mailman URLs with a 401 status. In which case, fail2ban should be able to parse these from log files quite reliably. It's a very effective security tool which parses log files of your choice, looking for strings (by regular expression) of your choice, and writes rules to the system firewall (via iptables in the case of Linux). Your challenge with fail2ban is writing the search rules. fail2ban allows very flexible criteria for determining what constitutes an attack, how long a blocking rules should last, etc. I use it for many kinds of attacks and probes such as ssh brute force attacks, Apache attempts to access non-existent pages, WordPress login failures (via the "Fail2ban Redux" plugin), FTP login failures, and a couple of others. As along as there's a log file which provides a basic unique failure string, and an IP address source for the failure, fail2ban will manage blocking. -- Lindsay Haisley | "The first casualty when FMP Computer Services | war comes is truth." 512-259-1190 | http://www.fmp.com| -- Hiram W Johnson -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
On 04/16/2018 10:45 AM, Lindsay Haisley wrote: > > Apache will log the access, with IP addresse, but to the best of my > knowledge it won't log a Web UI login failure since this is an internal > matter for Mailman. As I said in my prior reply, all Mailman login failures return a 401 status. Just look in the Apache logs for Mailman URLs with a 401 status. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
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 t
Re: [Mailman-Users] Brute force attacks on mailman web ui
On Mon, 2018-04-16 at 13:26 -0400, Robert Heller wrote: > > > Is there anything / feature that Mailman has that can be used to > > > watch/monitor it? > > > > A related question would be whether there's any way to correlate failed > > web UI login attempts with IP addresses. It doesn't appear that at > > present Mailman 2 logs failed web UI attempts at all, although I may be > > missing something. > > They might be in Apache's logs. Apache will log the access, with IP addresse, but to the best of my knowledge it won't log a Web UI login failure since this is an internal matter for Mailman. The connecting IP address is available in the environment to any web application and it shouldn't be difficult to set up logging for login failures. -- Lindsay Haisley | "The first casualty when FMP Computer Services | war comes is truth." 512-259-1190 | http://www.fmp.com| -- Hiram W Johnson -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
At Mon, 16 Apr 2018 09:46:21 -0500 fmo...@fmp.com wrote: > > On Sun, 2018-04-15 at 22:53 +, Steven Jones wrote: > > We are currently under brute force attack on our mailman server's web > > ui. > > > > > > Is there anything / feature that Mailman has that can be used to > > watch/monitor it? > > A related question would be whether there's any way to correlate failed > web UI login attempts with IP addresses. It doesn't appear that at > present Mailman 2 logs failed web UI attempts at all, although I may be > missing something. They might be in Apache's logs. > > If this were possible, a system-level utility such as fail2ban could be > used to monitor logs and establish kernel filter rules to block these > IPs. > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
On 04/16/2018 07:46 AM, Lindsay Haisley wrote: > > A related question would be whether there's any way to correlate failed > web UI login attempts with IP addresses. It doesn't appear that at > present Mailman 2 logs failed web UI attempts at all, although I may be > missing something. Mailman responds to invalid login attempts from the admin, admindb, options and private CGIs with a 401 Unauthorized status. These are (or should be) logged by the web server along with the IP address and other info. In addition, if a list's membership is private, i.e. available only to members or the admin, failed attempts to log in to the options page or obtain a password reminder are logged by Mailman in the mischief log, but only login failures have the IP address. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
On Sun, 2018-04-15 at 22:53 +, Steven Jones wrote: > We are currently under brute force attack on our mailman server's web > ui. > > > Is there anything / feature that Mailman has that can be used to > watch/monitor it? A related question would be whether there's any way to correlate failed web UI login attempts with IP addresses. It doesn't appear that at present Mailman 2 logs failed web UI attempts at all, although I may be missing something. If this were possible, a system-level utility such as fail2ban could be used to monitor logs and establish kernel filter rules to block these IPs. -- Lindsay Haisley | "The first casualty when FMP Computer Services | war comes is truth." 512-259-1190 | http://www.fmp.com| -- Hiram W Johnson -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
On 4/15/2018 5:53 PM, Steven Jones wrote: We are currently under brute force attack on our mailman server's web ui. Is there anything / feature that Mailman has that can be used to watch/monitor it? Can you elaborate on how they are attacking? If it's a detectable pattern, I suggest you investigate fail2ban (as Christian suggested). david -- IBM i on Power Systems: For when you can't afford to be out of business! I'm riding 615 miles (Yes, you read that right) in the American Diabetes Association's Tour de Cure to raise money for diabetes research, education, advocacy, and awareness. You can make a tax deductible donation to my ride by visiting https://gmane.diabetessucks.net. You can see where my donations come from by visiting my interactive donation map ... https://gmane.diabetessucks.net/map (it's a geeky thing). I may have diabetes, but diabetes doesn't have me! -- 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
Re: [Mailman-Users] Brute force attacks on mailman web ui
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 comp
Re: [Mailman-Users] Brute force attacks on mailman web ui
Hi Am 16.04.2018 um 00:53 schrieb Steven Jones: > Hi, > > We are currently under brute force attack on our mailman server's web ui. > Is there anything / feature that Mailman has that can be used to > watch/monitor it? > Sadly I think we'll have to remove it off the Internet. > > This is not a mailman specific problem. Brute Force attempts can only be mitigated by e.g. fail2ban. It monitors your log files and will block access for IPs that try to login too often with invalid credentials for a short time. This will only catch IPs which try multiple times. A DDoS with constantly changing IPs will still hurt you. Kind regards, Christian Mack -- 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
