1

I get DDoS by the Wordpress Pingback BOTNET, now I want to block all client who contain Wordpress in there Useragents. For example:

WordPress/4.0; http://vk.lokos.net; verifying pingback from 107.158.239.82

I need to block for both HTTP port 80 and HTTPS port 443. How can I do this?

3
  • test -m string – PersianGulf May 9 '15 at 23:54
  • You could do that with iptables for traffic on port 80 but traffic on 443 is encrypted so no (easy) way to filter it using iptables. Better go with Otheus's solution. – Paolo May 10 '15 at 20:49
  • Was my answer helpful? – Otheus May 29 '15 at 14:14
4

First: You don't want to do it this way, as I describe below.

Second: a very similar problem is answered here http://spamcleaner.org/en/misc/w00tw00t.html . I'm relaying their solution to your specific question. There is an iptables string module which you can use to match the browser agent. However, iptables will then inspect every packet ... we can optimize this with the connmark module. I haven't tried it so my answer is only a nudge in the right direction:

<other rules>
iptables -t mangle -A PREROUTING -m connmark --mark 0xBAD1 -j DROP
iptables -t mangle -A PREROUTING -m connmark --mark 0xBAD0 -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -m string --string "User-Agent: " -j CHECK_UAGENT
iptables -t mangle -A CHECK_UAGENT -m string --string "User-Agent: WordPress/4.0" -j CATCH
iptables -t mangle -A CHECK_UAGENT -j CONNMARK --set-xmark 0xBAD0
<otherrules>
iptables -t mangle -N CATCH 
iptables -t mangle -A CATCH -j LOG --log-level alert --log-prefix "WordPress attack "
iptables -t mangle -A CATCH -j CONNMARK --set-xmark 0xBAD1
iptables -t mangle -A CATCH -j DROP

Here's the idea. The connmark module and associated target will mark a packet as you wish, and any ensuing packets in that connection stream will be similarly marked. So we look for packets headed toward port 80 and have a "User Agent" string. If they have the undesirable User Agent, we mark it as 0xBAD1 -- blaclisting it. We then log it and drop it. Otherwise, once we see "User Agent" but not the undesirable one, it gets whitelisted with 0xBAD0. By whitelisting it, we reduce the load on the packet inspector (it's an optimization step). Otherwise, we'd be searching in every packet of every uploaded picture -- a pointless waste.

** Why the above is a bad idea** One: HTTPS cannot be decoded at the packet-filter level. Two: Because a DDOS attack with the above is possible. The connection starts, opens a connection on your web-server, then disappears (from your webserver's standpoint). It will wait for a long time before giving up on the client which is no longer allowed to get any more packets through. Meanwhile, more attempts will come through. Eventually, HTTP will run out of resources and no requests get through. (One way to fix that problem is by using the recent module. A more thorough way is to have a process monitoring the logfile for "WordPress attack", having it note the remote IP and port, and either forcing the connection to be closed with cutter, or cross-referencing that connection with the server PID associated with it and then killing that process. )

A similar question was posed and answered with : use a reverse proxy. That's the best option but requires lots of reconfiguration and maybe an intervening server.

Do it this way instead Use mod_rewrite (in Apache/*ngnx) to match the User-Agent string, set an environment variable for logging purposes, and return 403 error status. That shuts up the remote side. Now, to make it more permanent, have a separate process monitoring that log-file for such dropped connections, and add the remote-ip to the recent table, which iptables will drop new connections from for the next 5 minutes. So...

# Apache config
RewriteCond %{HTTP_USER_AGENT}  ^WordPress/4\.0
RewriteRule - [L,R=403,E=WordPress]
LogFormat "%t\t%a\t%{remote}p\t%{User-Agent}i"
CustomLog wordpress wordpress.log env=WordPress

The custom log format makes it easier for our external process to decode. The IPtables is just one rule:

iptables -A INPUT --syn -m recent --name WordPress --rcheck --seconds 300 -j DROP

and the external process (running as root) looks like this:

#!perl 
open(STDIN,"tail -f /var/log/http/wordpress.log|")
while (<>) {
   my ($time,$ip,$port,$useragent)=split('\t');
   open(RECENT,"> /proc/net/xt_recent/WordPress")
   print RECENT "+$ip\n"
   close RECENT
}

The timestamp and user-agent string are just so you can verify things are working/not-working as you expect. I will add that with the mod-rewrite way of doing things, you have lots more flexibility of what to reject/ban.

1

Running the following commands will block this specific attack:

iptables -N Wordpress-PingVerify
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /' -j Wordpress-PingVerify
iptables -A Wordpress-PingVerify -p tcp --dport 80 -m string --to 80 --algo bm ! --string 'User-Agent: WordPress/' -j RETURN
iptables -A Wordpress-PingVerify -p tcp --dport 80 -m string --to 300 --algo bm --string 'verifying pingback from' -j DROP
iptables -A Wordpress-PingVerify -j RETURN

The above rules assume that the attack is destined to HTTP (port 80).

As an alternative, you can use these rules to block ALL WordPress pingback requests – this will block not only the pingback verifications but pingbacks as well:

iptables -N Wordpress-PingBacks
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /' -j Wordpress-PingBacks
iptables -A Wordpress-PingBacks -p tcp --dport 80 -m string --to 80 --algo bm ! --string 'User-Agent: WordPress/' -j RETURN
iptables -A Wordpress-PingBacks -p tcp --dport 80 -j DROP
iptables -A Wordpress-PingBacks -j RETURN

Source : https://sysadminblog.net/2016/05/blocking-wordpress-pingback-verification-ddos/

1
  • The HTTPS part is invalid, you can't filter HTTPS data – Shocker Oct 3 '16 at 20:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.