Antoine Beaupr : PSA: Mailman used to harrass people
It seems that Mailman instances are being abused to harrass people
with subscribe spam. If some random people complain to you that they
"never wanted to subscribe to your mailing list", you may be a victim
to that attack, even if you run the latest Mailman 2.
TL;DR: IKR! HOW DO I FIX THIS!?
Make sure you have
TL;DR: IKR! HOW DO I FIX THIS!?
Make sure you have SUBSCRIBE_FORM_SECRET set in your mailman configuration:
SECRET=$(tr -dc 'A-Za-z0-9' < /dev/urandom head -c 30)'
echo "SUBSCRIBE_FORM_SECRET = '$SECRET'" >> /etc/mailman/mm.cfg
This will add a magic token to all forms in the Mailman web forms that
will force the attacker to at least get a token before asking for
registration. There are, of course, other ways of performing the
attack then, but it's more expensive than a single request for the
attacker and keeps most of the junk out.
Other solutions
I originally deployed a different fix, using referrer checks and an IP
block list:
RewriteMap hosts-deny txt:/etc/apache2/blocklist.txt
RewriteCond $ hosts-deny:% REMOTE_ADDR NOT-FOUND !=NOT-FOUND [OR]
RewriteCond $ hosts-deny:% REMOTE_HOST NOT-FOUND !=NOT-FOUND [OR]
RewriteCond % HTTP_REFERER !^https://lists.torproject.org/$ [NC]
RewriteRule ^/cgi-bin/mailman/subscribe/ - [F]
# see also https://www.w3.org/TR/referrer-policy/#referrer-policy-origin
Header always set Referrer-Policy "origin"
I kept those restrictions in place because it keeps the spammers from
even hitting the Mailman CGI, which is useful to preserve our server
resources. But if "they" escalate with smarter crawlers, the block
list will still be useful.
You can use this query to extract the top 10 IP addresses used for
subscription attempts:
awk ' print $NF ' /var/log/mailman/subscribe sort uniq -c sort -n tail -10 awk ' print $2 " " $1 '
Note that this might include email-based registration, but in our logs
those are extremely rare: only two in three weeks, out of over
73,000 requests. I also use this to keep an eye on the logs:
tail -f /var/log/mailman/subscribe /var/log/apache2/lists.torproject.org-access.log grep -v 'GET /pipermail/'
The server-side mitigations might also be useful if you happen to run
an extremely old version of Mailman, that is pre-2.1.18, but it's now
over 6 years old and part of every supported Debian release out there
(all the way back to Debian 8 jessie).
Why does that attack work?
Because Mailman 2 doesn't have CSRF tokens in its forms by default,
anyone can send a POST request to /mailman/subscribe/LISTNAME to
have Mailman send an email to the user. In the old "Internet is for
nice people" universe, that wasn't a problem: all it does is ask the
victim if they want to subscribe to LISTNAME. Innocuous, right?
But in the brave, new, post-Eternal-September, "Internet is for
stupid" universe, some assholes think it's a good idea to make a form
that collects hundreds of mailing list URLs and spam them through an
iframe. To see what that looks like, you can look at the rendered
source code behind samedyfreeday.co.uk (not linking to avoid
promoting it). That site does what is basically a distributed
cross-site scripting attack against Mailman servers.
Obviously, CSRF protection should be enabled by default in Mailman,
but there you go. Hopefully this will help some folks...
(The latest Mailman 3 release doesn't suffer from such idiotic
defaults and ships with proper CSRF protection out of the box.)
SECRET=$(tr -dc 'A-Za-z0-9' < /dev/urandom head -c 30)'
echo "SUBSCRIBE_FORM_SECRET = '$SECRET'" >> /etc/mailman/mm.cfg
RewriteMap hosts-deny txt:/etc/apache2/blocklist.txt
RewriteCond $ hosts-deny:% REMOTE_ADDR NOT-FOUND !=NOT-FOUND [OR]
RewriteCond $ hosts-deny:% REMOTE_HOST NOT-FOUND !=NOT-FOUND [OR]
RewriteCond % HTTP_REFERER !^https://lists.torproject.org/$ [NC]
RewriteRule ^/cgi-bin/mailman/subscribe/ - [F]
# see also https://www.w3.org/TR/referrer-policy/#referrer-policy-origin
Header always set Referrer-Policy "origin"
I kept those restrictions in place because it keeps the spammers from
even hitting the Mailman CGI, which is useful to preserve our server
resources. But if "they" escalate with smarter crawlers, the block
list will still be useful.
You can use this query to extract the top 10 IP addresses used for
subscription attempts:
awk ' print $NF ' /var/log/mailman/subscribe sort uniq -c sort -n tail -10 awk ' print $2 " " $1 '
Note that this might include email-based registration, but in our logs
those are extremely rare: only two in three weeks, out of over
73,000 requests. I also use this to keep an eye on the logs:
tail -f /var/log/mailman/subscribe /var/log/apache2/lists.torproject.org-access.log grep -v 'GET /pipermail/'
The server-side mitigations might also be useful if you happen to run
an extremely old version of Mailman, that is pre-2.1.18, but it's now
over 6 years old and part of every supported Debian release out there
(all the way back to Debian 8 jessie).
I upgraded my home internet connection to fibre (FTTP)
I did try out RouterOS to start with, but I didn t find it particularly compelling. I m comfortable configuring firewalling and routing at a Linux command line, and I run some additional services on the router like my
Like
I'm happy to announce I handed out my Master's Thesis last Monday. I'm not
publishing the final copy just yet











Previously: 