fail2ban parsing errors on insert of [apache-xmlrpc] jail filter.

Posted May 1, 2016 4.7k views

Hey guys & girls

Am running apache 2.4.7 on Ubuntu Server 14.04 and Wordpress 4.5. ,PHP5.x? (Zend) sourced from a Bitmani LAMP Stack.

My apache web server is logging relentlessly attacks by what I presume are bots trying to brute force hack their way in through the xmlrpc php vulnerability:

I’ve followed the seemingly simple install and config of ‘failtoban’ which adds the IP of repeat offenders to you Iptables server firewall by analyzing the apache2 access log.
So followed the widely available instructions and created a .local copy of /etc/failtoban/jail.conf and inserted the following jail space conditions.


enabled = true
port = http, https
filter = apache-xmlrpc
action = iptables[name=XMLRP, port=http, protocol=tcp]


logpath = /opt/lampstack-5.5.30-1/apache2/logs/access_log
maxretry = 3
bantime = 28800

However when I try to restart with 'failtoban'with this section is I get the following error:

ERROR Failed during configuration: File contains parsing errors: /etc/fail2ban/jail.local
[line 211]: ’ enabled = true\n’
[line 212]: ’ port = http, https\n’
[line 213]: ’ filter = apache-xmlrpc\n’
[line 214]: ’ action = iptables[name=XMLRP, port=http, protocol=tcp]\n’
[line 216]: ’ logpath = /opt/lampstack-5.5.30-1/apache2/logs/access_log\n’
[line 217]: ’ maxretry = 3\n’
[line 218]: ’ bantime = 28800\n’

If I take OUT this section is starts fine but obviously will not be protecting me against these attacks.

Do you the think this is due to something weird in the way I’ve inserted the section in the editor with the newline \n append OR is there is problem with filter: /etc/fail2ban/filter.d/apache-xmlrpc.conf which is set-up like this OR is their a problem with resolving the waht I presume in the <HOST> environment variable?

failregex = ^<HOST> .POST .xmlrpc.php.*
ignoreregex =

The issue is that I 'think’ its the route cause of a proliferation of apache forked child processes and that are causing my VPS to run out of memory. I think there are plugins at the WordPress level that will at least defend your application: but it seems like neater solution just to block these f**kers at the server firewall level.

I’m an amateur when it comes of Linux sysadmin so any ideas most gratefully received?


These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

Hi there!

I actually found this guide for xmlrpc + fail2ban. I tested it and it’s working great for me :)

If you have any further questions, do feel free to ask!

Kind Regards,

  • Hey Jarland - Thanks man. I’m thrilled to get your response. It’s very rare I get any response from these kind of postings: either they are too dumb, too complicated/specific to my setup, or just too boring. Looking back at this one posted 3 weeks ago it was certainly dumb and definitely boring.... and therefore whether you are a DO employee or a community member I think you serve some ‘hero points’ for taking a moment to respond.

    Obviously, in hindsight, my original problem was just a case of 'fat thumbs’ and 'dodgy editors’ inserting and hiding control characters - hence the binary couldn’t read its own conf file. I managed to fix this by going nerdolon “(i.e. doing all the editing via vi” and hey presto it seems to be working. Look what I caught Failtoban reports it has jailed in just this mornings log:

    2016-05-22 13:32:27,547 fail2ban.actions: WARNING [apache-xmlrpc] Ban
    2016-05-22 21:32:27,585 fail2ban.actions: WARNING [apache-xmlrpc] Unban
    2016-05-23 12:51:48,249 fail2ban.actions: WARNING [apache-xmlrpc] Ban

    This means it’s successfully reading the Apache access log and jailing IP’s that repeatedly try to brute force their way in through [apache-xmlrpc] . You can see one IP being jailed and let free after serving its 8 hour sentence ( Well I’m a humanitarian!).

    If we grep the Access Log we see the tell-tale evidence of the crime. - - [23/May/2016:12:51:42 +0100] “POST /xmlrpc.php HTTP/1.0” 200 370 - - [23/May/2016:12:51:38 +0100] “POST /xmlrpc.php HTTP/1.0” 200 370 - - [23/May/2016:12:51:40 +0100] “POST /xmlrpc.php HTTP/1.0” 200 370 - - [23/May/2016:12:51:37 +0100] “POST /xmlrpc.php HTTP/1.0” 200 370

    Which stops from the moment Failtoban Arrests and detains! The is known as 'the proof in the pudding’. Nevertheless, it would be nice to be able to see the ban in IPTables. I’m no Unix Administrator but if I run 'iptables -L INPUT -v -n’ I find that Failttoban has created a load of new (sub) chains so anything arriving on 80 or 443 will be diverted.

    target prot opt source destination

    fail2ban-apache-xmlrpc tcp – multiport dports 80,443
    fail2ban-apache-overflows tcp – multiport dports 80,443
    fail2ban-apache-noscript tcp – multiport dports 80,443
    fail2ban-apache-multiport tcp – multiport dports 80,443
    fail2ban-apache tcp – multiport dports 80,443
    fail2ban-ssh tcp – multiport dports 22

    However the fail2ban chain seem to just be generic returns… so the xmlrpc entry just reads:

    Chain fail2ban-apache-xmlrpc (1 references)
    target prot opt source destination

    RETURN all –

    Perhaps it means that the blocking is not being effected by through IPtables? I’m curious but not curious enough to waste anymore time delving deep into the 'dark magic’. I think If I read this article thoroughly it might tell me:

    But you know what: the point is: it seems to be effective. It seems to have reduced the number of spawned sub-processes from Apache which in turn has reduced memory consumption which in turn has reduced the failure of MySQL that at the moment seems to be spawning new threads each time some bot subscribers to my site. (Even though its a two step process with Recaptcha on the confirmation - the initial sign-up logs that request in a database table which seems enough to justify a new thread.)

    Anyway, I’m rambling. But it’s all good. And thanks for the response.