Use modsecurity / CSF to block all common cms logins?

I don't necessarily think it's a bad idea however writing and maintaining all those rules is going to consume a lot of your time including the research into specifically which files to block.

Serving a 404 code is pretty lightweight to the server. So having some of these is not really a big deal and since you're not actually using it poses almost no risk whatsoever.

If it annoys you what I would suggest is using the 404 block rule in csf. Say after 15 404 errors then csf will temp block the ip.

Settings for this are in the csf.conf. Search on 404 I dont recall the exact wording of it but it's easy to set up.

Don't set it too low otherwise you may get some false positives from your clients or developers.

 

This might get you started: blog.pheonixsolutions.com/block-wordpress-login-attacks-csf/

 

@GeekOnTheHill

Your mind thinks much the same as mine.
Whilst the attempted login poses no threat, I still don't want them trying.

Take a look at page 4 on here, Custom REGEX rules for CSF. - Page 4 - ConfigServer Community Forum
It also has a custom regex which may be of use to you.

 

1). Definitely not a bad idea.
These IPs are revealing to us they most likely hacked sites/servers (also likely part of a group of compromised servers with a centralized control)
An IP running dictionary attacks wp-login.php today may very well be running attacks on a newly discovered, unpatched ssh vulnerability tomorrow.
With that in mind I suggest you consider permanent blocking in csf.deny rather than temp blocking.
CSF settings for this can be found in another post at...
modsec rule 942100 not being blocked, status 200

2). Pages to block.

Code:

Wordpress
domain.com/wp-login.php

Wordpress xmlrpc
domain.com/xmlrpc.php

Joomla
domain.com/administrator

Drupal
domain.com/user/login

Magento 1
domain.com/index.php/admin/

Magento 2
domain.com/admin

3). If you are certain you do not have (and will not have in the future) any URIs on your server with the phrases (login or xmlrpc or admin) then the following rule should suit.

Code:

# Deny POST to some default CMS login pages
SecRule REQUEST_METHOD "@streq POST" \
    "msg:'Deny POST to CMS login pages rule is being hit',\
    id:19000001,\
    phase:1,\
    t:none,\
    log,\
    auditlog,\
    deny,\
    status:403,\
    chain"
    SecRule REQUEST_FILENAME "@pm login xmlrpc admin" \
        "t:none"

4). I don't recommend using the CSF 404 Block Rule set any lower than 100-200 or something as simple as a missing theme image can lock out site visitors.

5). The 2 CSF custom regex rules linked to above both do only temp blocks (1 hour) on (possibly) limited ports 80, 443

Code:

return ("Failed WordPress login from",$1,"wordpress","5","80,443","3600");

If you choose to do things that way (entirely in csf custom regex) read the example in /etc/csf/regex.custom.pm
to learn how to block permanently on all ports.

 

I think you are misunderstanding LF_PERMBLOCK.
It is a way to add a repeat temporary block offender to the csf.deny file.
If LF_PERMBLOCK_COUNT temp blocks in LF_PERMBLOCK_INTERVAL period then add IP to csf.deny.

csf.deny is limited to the number of IPs set in DENY_IP_LIMIT.
After that number is achieved the oldest entry is deleted when a new one is added.
The recommended max No. for DENY_IP_LIMIT is 1000.
I have seen a turnover time of 3 months with the limit set at 1000

Back to the logic of what you are doing here.
Your objectives can be to...
1) Restrict access by offending IPs so as to preserve server resources.
2) Restrict access by offending IPs so as to prevent those IPs carrying out hack attempts.
3) Both of the above.

Temp blocks achieve #1 and block to login attempts which GOT pointed out are no threat to your server.
They do not achieve #2.

Perm blocks achieve #1 and #2, but as you point out may block public proxies or dynamic IPs

You just have to work out which compromise is most important to you on this server.

 

As a matter of interest, if you research the owners of IPs behaving badly I would be interested in the numbers/percentages you find that are in fact listed public proxies or owned by telcos (possibly dynamic).
In my experience less than 5 in a 1000 were owned by telcos (at least from countries I am interested in allowing)
I have never checked against public proxy lists.