Use modsecurity / CSF to block all common cms logins?

Good morning.

One of my cPanel servers hosts only a few domains owned by the same client, none of which use a CMS. All of the sites are hand-coded in PHP.

We get an absurd number of requests on non-existent default CMS login pages (wp-login.php, for example). I have to assume that they're all malicious, so I'd like to use modsecurity and CSF to temp block every IP address that attempts to access those pages even once. There's no legitimate reason why anyone would be trying to access them, and we have no plans to ever implement a CMS on this server; so I figure I may as well block them at the firewall.

First question: Is this a bad idea?

Second question: If it's not a bad idea, which pages should I block? I personally don't use CMSs except for one WP installation on another server, so I really have little knowledge of them other than that WordPress seems to be the most popular.

Third question: Assuming this isn't a horrid idea, any suggestions for the rule itself would be appreciated. I have little experience or familiarity with writing custom rules, so I'd rather ask than break something.

Thanks,

Richard

 

Thanks.

My reason for considering an outright block is that a person attempting to access a well-known but non-existent login page is almost certainly a malicious actor, and blocking them completely would prevent them from trying any other tricks from that IP for the duration of the block.

Of course, a targeted human attacker could always use a different IP and avoid accessing that particular page on subsequent tries; but most of these attacks are scripted, and I doubt that too many robots have the presence of mind to figure out what's going on when they're blocked.

Richard

 

Thank you.

Richard

 

Exactly. They're up to no good, so just block them and be done with it.

Thank you.

Richard

 

Thank you very much.

I'm wary of permanently blocking an IP because it may be a dynamic address or a public proxy. But than again, I believe the default PERMBLOCK is actually only 24 hours anyway.

Something like this, with certain safeguards built in, might actually be a basis for a useful honeypot to generate a rotating malicious IP RBL.

Richard

 

Okay, thanks for clarifying that. I'll have to look up the logs and do some math to come up with something reasonable. I don't want to forever block "innocent" IPs that just happened to be used by a malicious individual on a given day, but I would like to completely restrict those IPs for enough time for the malicious actor to move on. I'm definitely going to have to give this some thought before implementing it.

Thanks again,

Richard

 

Okay; although I must say, I get hundreds of them a day between failed WP, WHM, and SSH login attempts, so I can't promise anything.

Some months, the number one page served is the 404 page; and when I check the raw logs, they're all CMS login attempts. The client actually asked me about that once, thinking I must have had a bad link somewhere on the site. But they were all from miscreants trying to access non-existent login pages.

Richard

 

Sorry I disappeared for a while. I had a few high-priority jobs. One was especially interesting: coding a custom blog from scratch. It wasn't all that hard. It was just something I hadn't done before.

Anyway, back to the original topic. I decided last night to at least get started on this project. I resurrected my dormant AbuseIPDB account, created some keys, and coded a honeypot page. I made entries in .htaccess to redirect all the hits on wp-login.php, xmlrpc.php, admin.php, and login.php to the honeypot page.

What the honeypot does is stash the information about every request for the page in a database, checks that database to prevent reporting the same IP more than once every 15 minutes (that's an AbuseIPDB rule), and sends the report to AbuseIPDB. Of course, the database also is a record of all the events that I can use for whatever else I decide to do with it.

I installed the script on a handful of sites last night. Here's who it's caught so far:

GeekOnTheHill - AbuseIPDB User Profile

As for what I can do with the information on my end, I have a lot of options to consider. Because these IP's tend to be ephemeral, something immediate and short-term would be nice, possibly with the ability to flag repeat offenders for longer-term banishment. The quick-and-dirty way would be to use sudo or ssh2 to manually add the IP to iptables. I'm thinking about more elegant solutions, though.

I don't want to block access to those pages completely. I'd rather use them as honeypots, for whatever good it does. That part is accomplished. Now I just have to decide what to do locally with the data now that I'm collecting it.

Richard

EDIT:

Maybe now would be a good time to use a REGEX, since all the abused URLs wind up on the same page and it's easy to add new ones in .htaccess if I want to. Any IP that accesses the honeypot would get denied for a time. That's probably the easiest way.

 

Please see Post 15.

Richard

 

I think the solution turned out to be a simple one: Just include a proper 401 page at the end of the honeypot, and then use LF_APACHE_401 and LF_APACHE_401_PERM to do the blocking.

Yeah, I know there's supposed to be an authentication failure for a 401. But these are bad bots and a handful of human miscreants. If they want to sue me for giving them a 401 rather than a 403, then so be it.

Richard