RSS feeds have been around for decades, once very popular with geeks as a lightweight way of keeping up with the news such as https://feeds.bbci.co.uk/news/rss.xml before we all got 1gb cable connections and 5g, not normally read raw by human eyes as such but using apps such as https://lireapp.com/, of which there are a huge variety. While still popular, I don’t expect to see more than maybe 5-10% of traffic on a website coming from them, they stand out in logs as they make GET requests to /rss.xml, /feed, /feed.xml or some slight variation. /feed is the convention for WordPress and what I will be referring to here.

RSS feeds can be a bit of burden at the best of times due to the way it pulls the latest x number of articles from the database, normally this is easily mitigated with caching, which of course can delay updates to the feed, a balance the site owner needs to find if he’s having issues.

But when a fairly busy site (2 million users per month), with that normal 5-10% of requests for /feed starts seeing a huge uptick in traffic over 24 hours, and when you drill down on it you find 80%+ requests for /feed, either thats an intentional or unintentional DDoS.

It was causing issues, grindingly slow admin pages, as the site is fairly dynamic, the cache was set to clear after every new post, about 20 times a day.

And there were dependancies as automated emailings are being sent with a daily update of all new posts, and commercial email solutions such as Constant Contact, rely on fresh/uncached /rss feeds, so its not a simple case of blocking or removing the feature.

These RSS readers may only update their feed from /feed when being viewed, but some can be configured to keep an offline version as often as every 60 seconds or a single device could have multiple rss reader apps which was also happening here, they can also be embedded in other websites, causing a refresh from the source feed on every page view to their own site, which was not the case here.

As the site was using the Sucuri WAF, it was easily mitigated, as with most firewalls, a block listing is overridden by an allow listing, so I added /feed to the block list, and add a variable such as ?some_secrets to the allow list, adding somesite.com/feed?some_secret to the mail provider and the monitoring of the rss feed at uptime robot. this being the result in the logs, being lazy, and likely static IPs are not being used at either of these providers, the some_secret method is the best answer here.

You can see here the result with a pretty map from the real time audit logs.

I can see they are getting frustrated after a couple of hours, as they just launched their hissy fit brute force DDoS attack from a single device, this from the last hour, I think he just gave up though as I have been writing this up, as he’s only hitting a JavaScript challenge, water off a ducks back.

Always interesting to find a new method of any attack type, and just so much fun to figure out a mitigation. If you don’t have a WAF, and want to do it yourself, blocking /feed, then allowing some or many secrets to allowlist, it can easily be done in Apache or Nginx, in Apaches .htaccess add:

RewriteCond %{REQUEST_URI} ^/feed$
RewriteCond %{QUERY_STRING} !^some_secret1$ [NC]
RewriteCond %{QUERY_STRING} !^some_secret2$ [NC]
RewriteRule ^ - [F,L]

And in the Nginx config, in the server block you can add:

location = /feed {
    if ($args !~* ^(some_secret1|some_secret2)$) {
        return 403;
    }
}

The reason I added multiple secrets is so trusted users can be given different secrets to bypass the block on /feed, the ? just provides a variable that will not interfere with the rss feed itself, and if ever leaked you can have a word with the cause of the disclosure.

As always, I have no idea why this site is being attacked or by who, the site owners are not criminals in anyway, not that I would ever condone a DDoS attack.

I couldn’t find any stories of intentional DDoS attacks leveraging RSS feeds, many unintentional ones which is why I wrote this up, this is not a busy site for sure, but hopefully if someone has the same issue, Google will be kind enough and point them this way.