| Summary: | Possible list bombing running via mail01.ipfire.org | ||
|---|---|---|---|
| Product: | Infrastructure | Reporter: | Peter Müller <peter.mueller> |
| Component: | Mail & Mailing Lists | Assignee: | Michael Tremer <michael.tremer> |
| Status: | CLOSED FIXED | QA Contact: | Peter Müller <peter.mueller> |
| Severity: | Security | ||
| Priority: | - Unknown - | CC: | robert.moeker, ummeegge |
| Version: | unspecified | Keywords: | Security |
| Hardware: | unspecified | ||
| OS: | Unspecified | ||
| See Also: |
https://bugzilla.ipfire.org/show_bug.cgi?id=11764 https://bugzilla.ipfire.org/show_bug.cgi?id=11635 |
||
| Attachments: | Mail queue growth | ||
|
Description
Peter Müller
2018-06-11 18:24:47 UTC
Created attachment 589 [details]
Mail queue growth
(In reply to Michael Tremer from comment #1) > Created attachment 589 [details] > Mail queue growth This looks very bad indeed. Any ideas what to do about it? No, this is a botnet. IPs from all over the place. Every IP address has only sent one single request to subscribe. So we cannot rate-limit anything. I am out of ideas. Well, we currently have 2054 mails in the queue... :-( I will have a look at the IP addresses subscribing, but at the moment there are no ideas here either. However, we definitely need to do something against it. Unfortunately I cannot see the original IP addresses since they are NATted. However, this looks like a DoS against some 50 destination mail addresses which seem to be involved with some cryptocurrency things. Since we are slowly running out of resources it might also be a slow Dos against our system. Some of them have received > 500 subscriptions during the last two days (the whole thing started at June 10 13:35:23 UTC and continues since that time). At the moment, I see the following options: - Ban the subscribed mail addresses in Mailman - Ban the IPs (if we are able to recognize them, for example via being listed in a RBL) at the webserver - I prefer this idea in general, too - Both Either way, I suggest shutting down mail subscriptions via Mailman temporarly until we ease the situation. Blocking destination mails turns out to be difficult since f*cking Mailman does not read ban_list correctly. Documentation isn't helping. Great. @Michael, *: Any idea how to do this? I manually deleted all the clutter in the queue, but "attacks" still continue and we are about 200 mails now. Temporarily banned all 50 mail addresses occuring so far by doing: /usr/lib/mailman/bin/config_list -i /tmp/bad_dst_mails.mailman [list name] Not a permanent solution (Captcha?!?), and there still seem to be some destination adresses upcoming. Giving up for today. See also: https://www.m3aawg.org/rel-WebFormHeader Mailman 2 neither supports Captcha nor Rate Limit. Mailman 3 does. I just applied this change to our installation which will stop the subscriptions: http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1371 This did not seem to help. We finally got rid of this by blacklisting any client listed in Spamhaus XBL (a possible fix for wiki/forum account creations?). However, there are some minor issues left - such as viewing the mailing list archive should be possible anyway, but this issue is closed. It's back... Mailman 2.1.27 and higher have some patches built-in for preventing clients listed in Spamhaus SBL/XBL and/or mail addresses listed in Spamhaus DBL from triggering subscriptions: https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/NEWS This would solve the problem here very elegant and might also fix #11635. However, CentOS still ships an older version. I will have a look about how to upgade this on RHEL systems. Usually RH backports certain things. But I guess since this release is already so outdated, nobody of their customer seems to be running it in production and therefore nobody is pressing them to fix certain issues. So we can either wait, or install mailman from scratch, but that would create new problems since they have patches mailman quite a lot. (In reply to Michael Tremer from comment #13) > Usually RH backports certain things. But I guess since this release is > already so outdated, nobody of their customer seems to be running it in > production and therefore nobody is pressing them to fix certain issues. I agree but it seems weird to me since Mailman is used quite often. But we all know e-mail died about 20 years ago... :-) > > So we can either wait, or install mailman from scratch, but that would > create new problems since they have patches mailman quite a lot. I did not get the problem. Do we rely on any of RHELs patches? My idea was to use the vanilla version of Mailman, and compile and install it on mail01.ipfire.org . Not very elegant, though, since it is a productive system, but the current situation blocks some things and it does not seem to get better. As I said last time, did you have a look at all the patches that are already included in the CentOS version? I am quite confident that the vanilla version will break it. Personally, I'd like to postpone this for a while. We dealt with dead mail accounts by tweaking Mailmans bounce processing (and Postfix handling of them), and subscriptions have been mitigated by RBL lookups. Let's hope the new CentOS version will bring us a more recent Mailman version. Until we have (tested) it, I suggest to close this as DEFERRED. Looks like we are going to get 2.1.29. That is the current upstream version: https://git.centos.org/rpms/mailman/blob/c8-stream-2.1/f/SPECS/mailman.spec Hi all, am currently not really in this topic nor in the Mailman internas but might it be an idea to use maybe only temporarily IPSet for this so those attempts can be stopped on a FW level ? I use the Firehol lists --> https://github.com/firehol/blocklist-ipsets/blob/f02b6547722ce72aa1027881e29648cbffbab0eb/README.md which are very extensive but good sorted (incl. beneath Spamhouse a lot more) and also very up-to-date since a couple of years now, we have had also some conversations with the Firehol developer in the forum --> https://forum.ipfire.org/viewtopic.php?f=50&t=15124&start=15#p91774 where a script has been made for cyclic updates in combination with 'update-ipsets' . Have seen that Firehol extended their logic with DNSbl --> https://github.com/firehol/firehol/wiki/dnsbl-ipset.sh which might be worth a try ? Beneath info, have deleted also a recognizable higher amount of spammers in the past weeks from the forum. It seems that before a Core update (starting at testing time) the amount grows also there. Just as another idea to ease the whole patching scenario a little Best, Erik I guess we should start looking into having a good way (including a UI) on how to block things based on an IP blacklist. That is a different topic and should have an own ticket, but the IPS would benefit from this indeed. I consider this closed since we did not have any massive spam issues recently apart from our forums. |