some new questions (hope you not tired of me)

got some questions and possibly some quick work for you till

1 - I'm seeing in my /var/log/httpd/access log a clear attack:
78.153.206.70 - - [26/Mar/2014:08:53:17 -0400] "POST /administrator/index.php HTTP/1.0" 500 1185 "-" "-"
78.153.206.70 - - [26/Mar/2014:08:53:18 -0400] "GET /administrator/index.php HTTP/1.0" 200 3872 "-" "-"
78.153.206.70 - - [26/Mar/2014:08:53:18 -0400] "POST /administrator/index.php HTTP/1.0" 500 1185 "-" "-"
78.153.206.70 - - [26/Mar/2014:08:53:18 -0400] "GET /administrator/index.php HTTP/1.0" 200 3872 "-" "-"
78.153.206.70 - - [26/Mar/2014:08:53:18 -0400] "POST /administrator/index.php HTTP/1.0" 500 1185 "-" "-"
78.153.206.70 - - [26/Mar/2014:08:53:19 -0400] "GET /administrator/index.php HTTP/1.0" 200 3872 "-" "-"
78.153.206.70 - - [26/Mar/2014:08:53:19 -0400] "POST /administrator/index.php HTTP/1.0" 500 1185 "-" "-"
78.153.206.70 - - [26/Mar/2014:08:53:19 -0400] "GET /administrator/index.php HTTP/1.0" 200 3872 "-" "-"
78.153.206.70 - - [26/Mar/2014:08:53:20 -0400] "POST /administrator/index.php HTTP/1.0" 500 1185 "-" "-"
78.153.206.70 - - [26/Mar/2014:08:53:20 -0400] "GET /administrator/index.php HTTP/1.0" 200 3872 "-" "-"

from some ip address in Ireland.

now I can drop this ip with route add -host xxxxxxxxxxx reject
(already done so) but obviously with an attack like this the ips will change (and I already see an earlier ip address doing the same thing?
any way fail2ban can be configured to recognize get/post pairs like above? and is there any benign explanation?

I guess I could write a python script that parsed the access file and looked for these lines and issued the route commands, but I like the idea of unblocking them later in case thats just some poor unsuspecting fool whos cpu has been zombified.

has anyone come up with a clever solution?

SECOND - and I think might be some paid work (how cheap are you??) I moved a joomla 2.5 site to my ispconfig3 server. I used akeeba, and some of the $!#@! extensions had the old server path (/srv/www etc) hard coded. found and fixed all of those for the new server. I manually installed the new mysql database in ispconfig3, and imported it successfully from old site.
now - FRONT END apparently works fine. back end - I get the admin login page but when I log in (and my account is accepted properly if I give bogus credentials I get username error) - I get a COMPLETELY blank page.
and NO php errors. not in logs, not when I put display errors in the index.php.
not when I tell it to display 'maximum' errors in the joomla config.
that only gives me lost of 'strict compliance' warnings that obviously dont mean anything - NO error anywhere.

You all expert in Joomla? I'm sure its some extension blowing up, but again, NO php errors seem apparent. now the old site was hosted at 1and1 and I have NO idea what their server setup was except it was using nginx. I have the site setup in ispconfig3 with fastcgi. as I said front end works fine as much as I've checked it out - so at least most of the extensions are now working properly. but why would front and back end differ like this? what would kill the back end without errors - but let front end work?
any ideas? and if you want to take a whack at this what do you think you would need?

inquiring minds and all that!

cdb.
ps Love Ispconfig3 and I've been sharing the news with several others in the area building up their own servers

 

partially answering my own question

re failtoban you can put a jail for apache flood attacks as follows:

in jail.conf:
---snip---

[apache-postflood]

enabled = true
filter = apache-postflood
action = iptables[name=httpd, port=80,protocol=tcp]
sendmail-whois[name=post_block, [email protected], [email protected]]
logpath = /var/log/httpd/access_log
findtime = 10
maxretry = 10
---snip---

and the file in filter.d (apache-postflood.conf)
---snip---
[Definition]
#
failregex = ^<HOST> -.*"POST.*
#
ignoreregex =
---snip---

this is supposed to detect 10 posts in 10 seconds and block accordingly
if so it would have certainly blocked the attack above methinks.