SOLVED: Automated DDoS, phpBB Forum Posting And Registration Spam Attacks

[s]

Script kiddies are writing software to automatically register and post spam to phpBB forums. Those scripts rely on automated moderation or lack of moderation. Posts, topics and replies are always irrelevant to the subject and contain links to websites. These retarded spammers desire back links to boost their search engine ranking and get traffic. Therefore the easiest way to stop forum spam is manual moderation of posts and registrations every time anything changes, and preventing posting links may help, too. However, this will not solve the bigger problem caused by aggressive forum posting scripts that turn quickly into DDoS attacks eating all traffic quota, CPU time, and filling up memory. Forums use databases and session handling which require many computations and eat up a lot of resources. Normally bots, crawlers and spiders can be identified from User Agent strings. This allows forum administrators to detect automated scripts and switch off session handling for them to reduce the load. This helps tremendously, but only if bots declare themselves. This kind of automatic forum posting for backlinks happened to this forum a few weeks ago. CPU usage and load peaked because of the database server handling huge amount of request. Finally the server became unresponsive until the attackers were blocked on the web server level. It does not help banning such IP addresses and users because as long as they can access your forum, they will cause excessive load with automated and frequent requests. Request execute many scripts and queries which will overload the forum and web server.

How to find out where the attack is coming from?

If you have web server access logging on, you can find the sources from those logs. I personally prefer to have logging disabled to guarantee absolute privacy and reduce web server load. You can find from the access log the sources of traffic, frequency of visits as well as User Agent string. If you count the number of requests from each IP address excluding legitimate bots who identify themselves, you will find out the sources. Those requests that try post to your forum, login, register and often clear cookies, are the most promising. When there are hundreds or thousands of request coming every hour, those can not originate from users so they must be caused by malicious scripts.

Here are some simple *nix commands for NGINX web server you can use to find out the sources.

Find how many times the top 20 IP addresses have accessed forum:

Code: Select all

awk '{print $1}' YOUR_HTTP_ACCESS_LOG | sort | uniq -c | sort -nr | head -20

The same query but with User Agent strings that do not announce themselves as bots:

Code: Select all

grep -i  -Ev 'bot|spider|crawler' YOUR_HTTP_ACCESS_LOG |  awk -F' - |\"' '{print $1" - "$7}'  | sort | uniq -c | sort -nr | head -20

The same but with only those trying to post, register, login or delete cookies:

Code: Select all

grep -e posting -e registration -e delete_cookies -e login YOUR_HTTP_ACCESS_LOG |  awk -F' - |\"' '{print $1" - "$7}'  | sort | uniq -c | sort -nr | head -20

How to block the attackers?

After you have found out where the malicious traffic comes from, you can block it in your web server configuration. The principle is universal and available in all web servers. The following examples are written for NGINX. You could deny access from your web server, but that would cause your web server to send 403 error page which would still generate traffic and eat your server's resources. Another, smarter option is just to cut the connection immediate by returning error 444 "No Response". This will cut the connection immediately. Alternatively you can block those IP addresses from your firewall.

In NGINX you can do this by editing your web server configuration file:

/etc/nginx/sites-available/YOUR_WEBSITE

Add to the beginning of the configuration file a GEO block like this with malicious IP addresses:

Code: Select all

geo $block_spambots {
    default         0;
    47.236.134.202 1; # agressive DDoS forum posting bot
    47.82.0.0/16 1; # agressive DDoS forum posting bot
    47.79.0.0/16 1; # agressive DDoS forum posting bot
    87.120.166.175 1; # forum registration bot
    147.45.66.176 1; # forum registration bot
    3.1.218.249 1;   # a bot searching for wordpress vulnerabilities
    172.173.151.173 1; # a bot trying to run cron
}

Then go the server section that starts with "server {" and add there this configuration:

Code: Select all

if ($block_spambots) {
    return '444';
}

After that you need to reload your NGINX configs so that the changes take effect. If the reload fails, you will have to look for the errors from the logs. If your configs have errors when you start or restart the server, NGINX will stop working until you fix the errors. I personally found that annoying and wrote the following script to first test that the configs are OK before reloading NGINX and if not, it will show immediately you the errors in configurations.

Code: Select all

#!/bin/bash
#
# Test NGINX configuration and reload NGINX them if configuration is OK
# Public domain, 2025

# Functions
ok() { echo -e '\e[32m'$1'\e[m'; } # Green
die() {
    echo -e '\e[1;31m'$1'\e[m'
    exit 1
}

# Sanity check
[ $(id -g) != "0" ] && die "Script must be run as ROOT."
[ $# != "0" ] && die "Usage: $(basename $0)"

# Test NGINX configuration
/usr/sbin/nginx -t
if [[ $? == 0 ]]; then
  ok "Testing NGINX configuration"
else
  die "Testing NGINX configuration failed, error $?"
fi

# Reload NGINX
/usr/bin/systemctl reload nginx.service
if [[ $? == 0 ]]; then
  ok "Reloading NGINX configuration"
else
  die "Reloading NGINX configuration failed, error $?"
fi

ok "NGINX reloaded, all good"

Feel free to use and share it, I hereby release it into the public domain.

Happy hacking,

Santeri

[s]

Here is another forum suffering from the same attack. I found a universal fix that does not require blocking any IPs, bots or countries. I am currently testing it on this forum. So far so good.

Cheers,

s

[s]

These bots leave the TCP connection open. I had over 1000 connections just waiting. To mitigate the issue reminding of Slowloris attack, I made this fix: SOLVED: How to disable tcp-keepalive persistently in Debian?

To make it even more effective, you should add this configuration to your website's nginx config file:

Code: Select all

reset_timedout_connection on;

When this setting is on, NGINX will cut the connections immediately after returning 444. Both fixes together solve the lingering connection issue which may starve your TCP sockets making your server inaccessible.

I also find a universal and permanent fix to block all the current spam traffic without resorting to blocking individual IPs, IP ranges, or countries, or using services like Cloudflare which I do not trust. If you are interested, reply to this post with your contact or register to my forum for sending private messages, and I will help you to stop the bots once and for all. The fix is so simple and therefore easy to workaround that I will not release it publicly at the moment.

Happy hacking,

s