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] GSOC idea: mail server/DNS server/mailing list healthcheck
On 17-Apr-18 10:28, Rich Kulawiec wrote: > The idea for this comes from some of the web sites that perform this; > unfortunately most of them are "upgrading" from simple, fast, easy > checks to bloated ones that use a ton of Javascript, can't be scripted, > and are increasingly behind signups/paywalls/etc. > > The concept is simple: given a domain, check its DNS, mail, etc. > setup for correctness and consistency. For example: > > - does it have an A record? > - is that valid hostname? > - does it have an record? > - is that valid hostname? > - does it have MX records? > - are the MX records *not* CNAMEs? > - are they valid hostnames? > - do those hostnames resolve to public IP addresses? > - are any of those MX records duplicates? > - are all the MX responding? > - are the MX weights valid? > - do all MX's pass FCrDNS check? > - does it have NS records? > - are they valid hostnames? > - do they have A, records? > - are they in public IP space? > - are the NS records *not* CNAMEs? > - do all NS pass FCrDNS check? > - are any of those NS records duplicates? > - does the list of NS match the list of authoritative NS? > - do all the NS return the same list of NS? > - do all the NS return the same list of MX? > - do the NS *not* allow recursion? > - are any of the NS lame? > - are any of the NS missing? > - are all the NS responding? > - is there a working postmaster address? > - is there a working abuse address? > - is there a working hostmaster address? > - if not is there a working address that matches the one in the SOA? > - is the domain's SOA sane? (e.g. plausible serial number, > refresh, retry, etc.) > - do all the NS return the same SOA with the same serial number? > - is there ASN diversity among the NS? > - and so on There are plenty of tools for this. Don't re-invent the wheel. Here are a few (free) web-based tools (in no particular order); each has its niche: http://www.digwebinterface.com/ https://www.ssllabs.com/ssltest/ https://www.huque.com/bin/danecheck https://dane.sys4.de/ https://mxtoolbox.com/ # many non-mx tests too https://www.dnsstuff.com/ http://dnscheck.iis.se/ https://www.zonemaster.net/ http://dnsviz.net https://www.ultratools.com/tools/asnInfo # and many other tools. http://www.kitterman.com/spf/validate.html https://www.dmarcanalyzer.com/ # Tools. All but DMARC Analyzer are free; it's freemium Yes, there is a trend toward heavy UIs, but these are not frequent tests. If you set things up properly, it's not set and forget - but set & validate changes need not be frequent enough to care. If you maintain a few domains, it's not worth scripting. If you maintain a lot, the key is picking reputable providers for whatever you don't do yourself. If you have decent providers, there's not much for you to monitor. If you don't, you have bigger problems. curl will let you script access to most, or you can use libraries such as Perl's LWP, WWW::Mechanize::Firefox, WWW::Scripter, WWW::Selenium - the last few support Javascript by running a browser. It's better to maintain an interface to tests that someone else maintains than to try to create & maintain all the tests - many seem easy, but you'll find it becomes a serious time sink. In the long term, there is no such thing as a "small" P.roject. > Those are the sort of checks that pertain to the operation of any domain > and its nameservers and mail exchangers. But in addition, if run on a > Mailman 2 or 3 host: > > - what mailing lists are public? > - what mailing lists are private? > - does every list have a working -request address? > - does every list have a working -owner address? > - does every list have a working -bounces address? > - if any list supports the optional -subscribe address, > does it have a -unsubscribe address? > - if any list supports the optional -join address, > does it have a -leave address? > - and so on These are more interesting for mailman-users. V3 has an API - but it can be quite painful to navigate; I opened quite a few issues before concluding that V3 isn't ready for (my) primetime. V2 has some CLI tools in /usr/lib/mailman/bin - parsing output can get you a lot of information. In either case, it's not particularly interesting what Mailman THINKS is configured; more things go wrong with bitrot in mailserver configuration than in Mailman. So you need to script something that actually tests each action, receives list mail. And while you (and I) may use the CLIs, most users will use a GUI. You have to test what the customer uses. So again, curl and company are your friends. > Note: command-line tool. It has to be, because then it can be scripted > and run via cron and so on. Besides,
[Mailman-Users] GSOC idea: The central scrutinizer ;)
I have a partially-completed spec for a module that will examine messages for various issues but my Python-fu is likely not sufficient to realize it and I'm busy writing anyway. This is probably a GSOC-size and GSOC-scope project, so if anybody is game, below is a poorly-written and large incomplete description of what I have in mind. 1. As I've said for years, anti-abuse controls should be layered and should start at the network perimeter (with things like the Spamhaus DROP list in border routers). Additional layers may be in firewalls, in the MTA, in the MLM (such as Mailman). No one layer can catch everything because it doesn't have contextual knowledge, e.g., the firewall doesn't know who the members of a mailing list are or even that a particular SMTP connection it's allowing contains traffic for a mailing list. Unfortunately, email accounts have been hijacked by the billions (and that's just counting Yahoo). The new owners of those accounts likely enjoy the same SMTP reachability that the old owners did and can thus drop messages onto mailing lists. (I'm going to omit the long explanation about why context-sensitive measures in the MTA are not only inadequate to stop this, but are also highly undesirable.) To put it another way: we don't have many defenses against our friends. But we need them. 2. We all have our own views on proper netiquette for mail/mailing lists, and of course, mine are the only correct ones. ;) But regardless of those, it'd be useful to have a mechanism to scrutinize messages for things like "800 lines of quoted digest with one top-posted line above it". Of course some of this is easy to see and hard to code, but I think a modest attempt in this direction would be helpful. (Besides, if the action taken on detection of these is to merely hold the message, then little harm is done by false positives.) 3. 1 and 2 are related. The same kinds of criteria that are useful in detecting and putting a hold on spam are useful in detecting undesirable content in messages, like URL shorteners and third-party tracking links. So it makes sense to have a highly configurable module that comes with a minimal/loose default configuration that can be salted to taste. So what I have in mind is a module that scrutinizes messages based on a set of (enabled/disabled) criteria, each one of which is configurable. I know that's not very clear. Let me make up an example and see if that helps. Let's suppose we call this module the Central Scrutinizer (CS) because oblique tributes to Frank Zappa are always in order. The CS might have a list of dozens of checks like this: - URL shorteners (1) - tracking links (2) - full digest quoting (3) Check (1) would consult a list of known URL shortening domains and do pattern matching of any URLs in the message against them. Check (2) would attempt to detect tracking links/"web bugs". Check (3) would check messages to see if it includes an entire quoted digest. Each one of these would be associated with an action -- and I strongly think that "hold" would be best, because these tests are going to make lots of mistakes for a while. The results would be presented to list owners (in email notifications and in the browser interface) with something like: Central scrutinizer report: - URL shorteners - fail, example.net detected - tracking links - pass, none detected - full digest quoting - pass, none detected with appropriate presentation so that it's easy to read and so that when a test fails, it reports *why* it failed. Let me note that the MTA is wrong place to do this stuff for a whole bunch of reasons. Among other things, lots and lots of people want different policies applied to mailing list traffic (which will result in outbound mail traffic) than they due to local traffic (which won't). This is a serious issue for anybody concerned with their mail system's reputation, which is based on what it emits, not what it accepts. Of course not everyone will agree with every check, and not every check is appropriate on every mailing list. (For example, a one-way announce-only list is unlikely to need most of these.) But if this is modular, and if individual checks can be switched on/off readily, then it can ship with everything off and folks can enable whatever subset they find palatable. Let me also note that the motivation for this comes not just from things I've bumped into while running lists, but things I've seen on other lists. (And I'm on rather a lot of them.) I've been thinking about this for years, but have become convinced in the last six months or so that the problem has now reached a point where a solution is worth constructing. ---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:
[Mailman-Users] GSOC idea: mail server/DNS server/mailing list healthcheck
The idea for this comes from some of the web sites that perform this; unfortunately most of them are "upgrading" from simple, fast, easy checks to bloated ones that use a ton of Javascript, can't be scripted, and are increasingly behind signups/paywalls/etc. The concept is simple: given a domain, check its DNS, mail, etc. setup for correctness and consistency. For example: - does it have an A record? - is that valid hostname? - does it have an record? - is that valid hostname? - does it have MX records? - are the MX records *not* CNAMEs? - are they valid hostnames? - do those hostnames resolve to public IP addresses? - are any of those MX records duplicates? - are all the MX responding? - are the MX weights valid? - do all MX's pass FCrDNS check? - does it have NS records? - are they valid hostnames? - do they have A, records? - are they in public IP space? - are the NS records *not* CNAMEs? - do all NS pass FCrDNS check? - are any of those NS records duplicates? - does the list of NS match the list of authoritative NS? - do all the NS return the same list of NS? - do all the NS return the same list of MX? - do the NS *not* allow recursion? - are any of the NS lame? - are any of the NS missing? - are all the NS responding? - is there a working postmaster address? - is there a working abuse address? - is there a working hostmaster address? - if not is there a working address that matches the one in the SOA? - is the domain's SOA sane? (e.g. plausible serial number, refresh, retry, etc.) - do all the NS return the same SOA with the same serial number? - is there ASN diversity among the NS? - and so on Those are the sort of checks that pertain to the operation of any domain and its nameservers and mail exchangers. But in addition, if run on a Mailman 2 or 3 host: - what mailing lists are public? - what mailing lists are private? - does every list have a working -request address? - does every list have a working -owner address? - does every list have a working -bounces address? - if any list supports the optional -subscribe address, does it have a -unsubscribe address? - if any list supports the optional -join address, does it have a -leave address? - and so on Note: command-line tool. It has to be, because then it can be scripted and run via cron and so on. Besides, anyone running name servers, mail servers, etc., had better be able to work at the command line. Note: should work on systems that aren't running Mailman: just can't analyze Mailman then, of course. This leaves open the door for people using other MLMs to write checks that work with those. And maybe that'd be a nice thing to do. Note: should have varying levels of verbosity, including one that explains why something is wrong by referencing RFCs/BCPs/manual by chapter and verse. Note: the second set of checks (above) are outside the scope of what Mailman checks inside itself. That is, they require correlating what Mailman thinks should be in place versus what's actually in place in the MTA. ---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, 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
