Increasing volume of distributed subscription attacks (was Blocking or holding subscribe requests when email address contains "+")
David Gibbs wrote:
I've been getting a lot of subscribe requests from bogus email addresses that look like: adfslij+32987234 at gmail.com.
You're not alone. The subscriptions have also moved on to include addresses at SMS gateways after we added filters similar to what the thread suggested.
In case others are also dealing with this at volume, some background on what the IETF mailman admin is doing:
https://mailarchive.ietf.org/arch/msg/tools-development/p4iI5kxO-J1LZR5CQLer... and https://mailarchive.ietf.org/arch/msg/tools-development/P9mDSeRrvgUAD_tFzYqg...
If anyone has a mitigation strategy that's working well, please let me know.
RjS
On 09/17/2015 11:38 AM, Robert Sparks wrote:
If anyone has a mitigation strategy that's working well, please let me know.
I think much of this has appeared earlier in this thread, but we have seen large volumes of these at mail.python.org. These have all been web subscribes, and in spite of the fact that we have enabled the SUBSCRIBE_FORM_SECRET feature which requires that the web subscribe POST data contain a token which requires that it be a submission of a form retrieved at least SUBSCRIBE_FORM_MIN_TIME (default 5 seconds) and no more than FORM_LIFETIME (default 1 hour) earlier, the bots were sometimes slow enough that even when I increased SUBSCRIBE_FORM_MIN_TIME to 8 seconds, many subscribe requests still succeeded.
I then implemented a GLOBAL_BAN_LIST to supplement the individual, per list ban_list. We have been using the regexp
^.*\+.*\d{3,}@
in the GLOBAL_BAN_LIST and this is effective so far. Note that this could just as well be '^.*\+.*\d{3}@'. It is what it is because it evolved from '^.*\+\d{3,}@' after we saw a few of the form 'some.words+more-words123456@gmail.com' type addresses.
Note that since these are web subscribes and the address is banned, there is no backscatter. There is just a 'address is banned' notation on the web response.
For those interested, the GLOBAL_BAN_LIST implementation is at <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1574>.
Also, there is a withlist script at <https://www.msapiro.net/scripts/add_banned.py> (mirrored at <http://fog.ccsf.edu/~msapiro/scripts/add_banned.py>) which can be used to add an address or pattern to the ban_list if all lists in lieu of implementing a GLOBAL_BAN_LIST.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 09/17/2015 11:38 AM, Robert Sparks wrote:
If anyone has a mitigation strategy that's working well, please let me know.
I think much of this has appeared earlier in this thread, but we have seen large volumes of these at mail.python.org. These have all been web subscribes, and in spite of the fact that we have enabled the SUBSCRIBE_FORM_SECRET feature which requires that the web subscribe POST data contain a token which requires that it be a submission of a form retrieved at least SUBSCRIBE_FORM_MIN_TIME (default 5 seconds) and no more than FORM_LIFETIME (default 1 hour) earlier, the bots were sometimes slow enough that even when I increased SUBSCRIBE_FORM_MIN_TIME to 8 seconds, many subscribe requests still succeeded.
I then implemented a GLOBAL_BAN_LIST to supplement the individual, per list ban_list. We have been using the regexp
^.*\+.*\d{3,}@
in the GLOBAL_BAN_LIST and this is effective so far. Note that this could just as well be '^.*\+.*\d{3}@'. It is what it is because it evolved from '^.*\+\d{3,}@' after we saw a few of the form 'some.words+more-words123456@gmail.com' type addresses.
Note that since these are web subscribes and the address is banned, there is no backscatter. There is just a 'address is banned' notation on the web response.
For those interested, the GLOBAL_BAN_LIST implementation is at <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1574>.
Also, there is a withlist script at <https://www.msapiro.net/scripts/add_banned.py> (mirrored at <http://fog.ccsf.edu/~msapiro/scripts/add_banned.py>) which can be used to add an address or pattern to the ban_list if all lists in lieu of implementing a GLOBAL_BAN_LIST.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Mark Sapiro -
Robert Sparks