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