Q: How can I stop bots from abusing my public list subscription forms?

By Jacob Haller
Senior Support Engineer, L-Soft

A number of customers have been impacted by bots that abuse the public subscription pages in LISTSERV to bombard users with bogus subscription confirmation requests. If you're in that situation, then the upcoming LISTSERV 17.5 has some powerful new features that allow you to limit or even eliminate these attacks. There are some approaches to dealing with these issues even if you're using an older LISTSERV version, which will also be discussed in this tech tip.

Rate Limiting Features (LISTSERV 17.5)

Starting in LISTSERV 17.5, you can limit the number of subscription requests that LISTSERV will allow via the web interface in a given amount of time. The default is 50 subscription requests per hour.

This is done by setting the new RATE_LIMIT_SUBSCRIBE site configuration variable under "Server Administration" > "Site Configuration". You can use the "Configuration Variable" field at the top of the page, or click on the "Web Interface" tab and find the setting there.

The value of this setting is the number of requests you want to allow, followed by a slash, followed by the unit of time. The supported units are S (Second), M (Minute), H (Hour) and D (Day). A value of 0 disables the rate-limiting feature. So, for instance, setting this to 25/H would allow up to 25 subscription requests in an hour, while 2/M would allow two per minute. These settings are just examples and may not be appropriate for your own setup.

Once the limit is met, any additional requests will return a "Rate limit exceeded. Please try again later" error. This error message can be customized under "Server Administration" > "Mail Templates" by modifying the MSG_RATE_LIMIT_EXCEEDED template. Note that this same template is also used in other situations where a rate limit has been exceeded (for example, login attempts or new password requests) and not just subscription requests.

Determining a reasonable value for this setting may require some experimentation. As a good starting place, you can look at a recent LISTSERV log file from a date on which no attack was going on and see what a normal rate of subscription requests are over the course of a given time period (day, hour or whatever makes sense). Then, set RATE_LIMIT_SUBSCRIBE to some number above that.

To get a count of these requests, you can search the LISTSERV logs for the X-CONFIRM commands described in the "Other Ways of Handling Subscription Attacks" section of this tech tip below.

Note that only subscription requests that are submitted using the web interface count toward the limit. Emailed subscription requests aren't affected by this setting.

LISTSERV 17.5 also introduces a few other rate-limiting options (RATE_LIMIT_LOGIN, RARE_LIMIT_OK and RATE_LIMIT_PW). I won't discuss them here, but once LISTSERV 17.5 is installed, you can also find them under the "Web Interface" tab on the Site Configuration screen. You can click on each setting to get more information about it.

Protecting Yourself Using a Captcha Solution (LISTSERV 17.5)

Captcha solutions allow a web page to require users to pass some test before they can access the functionality of the page, with the idea that humans will be better able to pass these tests than bots. If you've ever been asked to click on photos that contained a motorcycle or traffic lights when you tried to log in to a site, then you've encountered a Captcha.

By making it difficult for bots to access the pages, securing a site via Captcha makes it less attractive as a target for bot-based attacks and decreases the chance that such attacks will be effective.

Starting with LISTSERV 17.5, LISTSERV has built-in support for several Captcha-type solutions, which can be used to secure access to the public login, new password request and subscription functions. At present, LISTSERV can integrate with three of the most popular Captcha solutions: reCAPTCHA, hCaptcha and Cloudflare Turnstile. All of the relevant settings can be found under the "Web Interface" tab on the Site Configuration screen.

To set up a Captcha solution for your LISTSERV site, follow these steps:

Step 1:

Sign up for the Captcha service of your choice. Then copy and paste the unique site key into WWW_CLOUDFLARE_SITEKEY, WWW_HCAPTCHA_SITEKEY or WWW_RECAPTCHA_SITEKEY, depending on the service that you're using.

Step 2:

Create a secret LISTSERV Captcha Badge to use with your Captcha solution. This is done using the WWW_CAPTCHA_BADGE setting. If defined, the login, new password and subscription screens will not accept any requests without this badge or key. This prevents bots from bypassing any Captcha challenge since they will not know what the secret badge is.

This secret Captcha badge can also be used without a Captcha solution but will be less effective as the badge won't be protected by Captcha, and the bots could, in theory, be able to retrieve it from the source code of the subscription page.

The secret badge can be any alphanumeric combination of letters and numbers. It cannot contain spaces or other special characters. For maximum security, we recommend using a randomly generated string. It will not be necessary for any administrators, list owners or users to type in the code manually.

WWW_CAPTCHA_BADGE=3A444B6

Step 3:

In the WWW_ARCHIVE_DIR location (look under "Server Administration" > "Site Configuration" to find this setting), there should be a subfolder named "captcha". In this location, edit the file named default.keys and update it with your LISTSERV domain name, your LISTSERV Captcha Badge from above, and your unique secret key. Note that the secret key is always different from the site key, so double-check that you are using the right key in the right place. Then save this edited file in the same directory under the name captcha.keys.

Step 4:

Find the WWW_CAPTCHA_VENDOR setting on the Site Configuration screen, and use the pulldown menu to select your desired Captcha solution. If this configuration variable is not set, then no Captcha solution will be used. Don't set this until all other steps have been completed, or else the login, new password, and subscription pages will stop working.

Once you have saved your new configuration settings, the public login, new password and subscription screens will automatically use the Captcha solution of your choice, and by defining a secret LISTSERV Captcha Badge, bots will be unable to bypass the Captcha validation, offering the best protection against abuse of your forms.

Other Ways of Handling Subscription Attacks (LISTSERV 17.0)

There are also some tools available in earlier LISTSERV versions, which may still be useful in LISTSERV 17.5.

First, a common feature of these sorts of bot-based attacks is that they will use a limited number of computers (say, 100) at a time to issue thousands of requests. If you find and block the IP addresses of the computers that are issuing the requests, then that will prevent the requests from getting through.

The botnets are likely to shift the IP addresses that they are attacking from over time, so, unfortunately, this is not a one-time solution. You will likely have to perform this maintenance regularly.

To find the IP addresses, you can look in the LISTSERV log file for entries containing X-CONFIRM commands to find these sorts of subscription requests. These will look like this:

30 Mar 2024 03:22:11 From [ANONYMOUS]: X-LOGCK - ORGINFO(139.98.23.15) WM: X-CONFIRM ***GUI*** email@example.com CHARS (...)

You should see one of these whenever a subscription attempt is made using the web interface from an address that isn't logged in. Note that this contains the IP address that LISTSERV sees the request as coming from, and the email address the subscription request was for (this may sometimes be truncated). If you see the same IP address repeated for many subscription requests, then that IP is a good candidate for blocking.

Things get more complicated if LISTSERV is behind a proxy server because then the only IP address recorded in the logs is the IP address of the proxy. In that case, you will have to look at the proxy server to determine where the requests are coming from. Unfortunately, subscription requests are sent via POST, and many proxy servers don't record the contents of POST requests. However, if you see the same address sending lots of POST requests, then that could be suspicious behavior.

Another way to approach this would be to look at the addresses being attacked. If the same addresses are appearing over and over in the subscription requests, then you can also issue the following type of commands:

serve email@address off drop

This tells LISTSERV to ignore all commands and emails from that address. The commands can be issued via using the LISTSERV web interface, under "Server Administration" > "LISTSERV Command", or they can be issued in the body of a plain text email to the listserv@yourdomain address.

You can't use this approach to block requests from entire domains – the SERVE command only works on individual email addresses. It's possible to use the TRAPOUT site configuration variable under the "Anti-Spam" tab on the Site Configuration screen to prevent LISTSERV from sending mail to those domains:

TRAPOUT *@example.net *@sample.com *@badaddress.tv

Note, however, that in that case, LISTSERV would instead send the messages to the postmaster, so the site administrators would need to be aware that they are likely to get a lot of new mail. Additionally, all mail sent to these domains will be affected, so I would only filter domains that you do not expect any legitimate requests to come from in this way.

Finally, another concern is that the subscription requests expire after a couple of days, after which LISTSERV normally sends a new notification to let people know that they didn't confirm in time. To prevent this, go under "Server Administration" > "Mail Templates", and edit the SUBSCRIBE_CONFIRM2 and CONFIRM2 mail templates. Replace their contents with the single line:

.qq

This will prevent these follow-up messages from being sent.