Brute force attacks on mailman web ui
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.....
regards
Steven
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
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.)
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.
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.
- 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.gzand 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 VixieYou 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.
- 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.
- 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.
- 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
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.)
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.
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).
- 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.
- 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.
- 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.
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 CIDR<tab>network-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
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!
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
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
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!
- 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
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.
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
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
On 19-Apr-18 23:33, Stephen J. Turnbull wrote: 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.
tlhackque writes:
So you know exactly who your users are, and can pre-register them while they are not in China.
No. China may, or may not, block any given email provider without warning. They may need to provide a new address *from that address* (or their mother's, which I also don't know).
If I can figure out how they can use X.509 auth with mail or thru the web, that will do the trick for authentication, of course. I might use fwknop to conceal authenticated services.
Geographic IP address is the wrong hammer for this nail.
Yes, I understand that. Tell it to Chairman Xi, please.
GeoIP will never get you down to the level of granularity and accuracy that you want.
Sure it will. If I can block 95% of Chinese attempts to connect on SYN, that's a win.
Even if it did, people with phones move - apartment, coffee shop, etc.
Whether that means they'll be out of the geographic area allowed depends on how the provider allocates IP addresses.
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).
It's not, but no, I'm not sure I can, for the reason given above.
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.
I know how to issue such things, or can find out. What I don't know how to do is enable devices to use them, and whether I can configure once, or teach students to do it. I also wonder what Chinese immigration authorities would think of a fwknop app on an iPhone....
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.
That's a last resort. They won't use that account frequently (if at all), which really counts against it. I would want something that they use under normal circumstances that they're used to, and have some idea how to configure on a new phone, etc.
Mobile web browsers certainly support x.509 client auth.
This seems like the route to go, then. Use a nonstandard port to screen out the dumbest kiddies, or maybe fwknop.
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.
I'm not sanguine about "issue keys and you're done". There are users in the loop, and they're not terribly security-savvy. I'm not saying it's insanely difficult, but the system would be an unfamiliar one that is a SPOF. The recovery/reissue feature wouldn't be optional: the trips I'd be worrying about would be on location data-gathering trips.
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...
Well, the considerations of dealing with user-hostile environments like the Great Firewall are pretty special, but the jungle *is* general. I.e., it applies to Mailman servers too. I don't know anybody who runs a list who doesn't run into abuse from time to time.
Thanks for the ideas and software suggestions!
Steve
On 4/21/2018 11:51 AM, Stephen J. Turnbull wrote:
I also wonder what Chinese immigration authorities would think of a fwknop app on an iPhone....
They'll send your users to a re-education camp where they can learn about possession of restricted/illegal tech. Where they will also not have access to e-mail and won't be able to participate in your list.
You can skip the middle part and just not let them subscribe to begin with.
(FWIW I've recently firewalled off a bunch of Baidu IPs because their crawler was ignoring robots.txt and hitting CGI scripts that require a small-ish amount of processing... never attribute to malice that which can be adequately explained by stupidity.)
Dima
At Sat, 21 Apr 2018 12:14:26 -0500 Dmitri Maziuk dmaziuk@bmrb.wisc.edu wrote:
On 4/21/2018 11:51 AM, Stephen J. Turnbull wrote:
I also wonder what Chinese immigration authorities would think of a fwknop app on an iPhone....
They'll send your users to a re-education camp where they can learn about possession of restricted/illegal tech. Where they will also not have access to e-mail and won't be able to participate in your list.
You can skip the middle part and just not let them subscribe to begin with.
(FWIW I've recently firewalled off a bunch of Baidu IPs because their crawler was ignoring robots.txt and hitting CGI scripts that require a small-ish amount of processing... never attribute to malice that which can be adequately explained by stupidity.)
And *I* have a fail2ban rule just for BingBot. M$'s coders are somewhat clueless.
Dima
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/heller%40deepsoft.com
-- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller@deepsoft.com -- Webhosting Services
Quoting Rich Kulawiec (rsk@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).
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!
On Sun, 2018-04-15 at 22:53 +0000, 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
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 mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
At Mon, 16 Apr 2018 09:46:21 -0500 fmouse@fmp.com wrote:
On Sun, 2018-04-15 at 22:53 +0000, 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 heller@deepsoft.com -- Webhosting Services
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
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 mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
participants (13)
-
Carl Zwanzig -
David Gibbs -
ddewey＠cyberthugs.com -
Dmitri Maziuk -
Lindsay Haisley -
mailman-admin -
Mark Sapiro -
Natu -
Rich Kulawiec -
Robert Heller -
Stephen J. Turnbull -
Steven Jones -
tlhackque