Page 1 of 1

How to Simulate a Login Failure

Posted: 09 Mar 2019, 14:09
by GeekOnTheHill
Hello, I have an idea and I'm wondering if it's practical. It would require CSF Firewall considering every access of a PHP page to be a login failure, even though there was no actual login.

My idea is simple. Almost all my sites are hand coded, so there does not exist (for example) a page named "wp-login.php." I want to redirect all those requests for non-existent CMS or forum logins to a single PHP page, which in turn would register a login failure that CSF would use as a basis for blocking the offending IP according to its configured lfd rule set.

I think this would be preferable to executing a script as root from the page. CSF already has lfd built-in, so simulating a failed login would be a safer way to do it.

Thanks,

Richard

Re: How to Simulate a Login Failure

Posted: 26 Sep 2019, 08:57
by OldFart
I believe there are tons of ways of doing so...

Not saying this would work or that i even tried it but have you tried maybe the simplest, just returning a 401 Unauthorized for all of them locations matches that you don't want accessed?

Check out this if you for more infos on 401. Official Moz "401 Unauthorized" Page

This could just do what you need and also add a 401 code to your access logs which in turn, would hypothetically get processed by this thing

If you have more specific questions that can't be answered by a forum browse, 10-12 minute serious google-FOO session and a trip down stackoverflow, then please ask because i'd love to help if i can.

You are encouraged to share your results after you decided to do either way. This will help others like you in the future i'm very sure! Thanks

Re: How to Simulate a Login Failure

Posted: 26 Sep 2019, 10:05
by GeekOnTheHill
Thanks for your reply.

What I decided to do (well, part of it anyway) is just use .htaccess to redirect the bad hits. First they go to a script that collects the IP and some other data and stashes it a database so it can be used to compile blocklists that can be shared; and that script in turn includes an actual 401 page with proper headers after it's done collecting the data.

The .htaccess entries look something like this:

Code: Select all

# Honeypot for non-existent login attempts
RewriteCond %{REQUEST_URI} /wp-login.php [NC,OR]
RewriteCond %{REQUEST_URI} /wp-config.php [NC,OR]
RewriteCond %{REQUEST_URI} /wp-contacts.php [NC,OR]
RewriteCond %{REQUEST_URI} /xmlrpc.php [NC,OR]
RewriteCond %{REQUEST_URI} /webconfig.txt.php [NC,OR]
RewriteCond %{REQUEST_URI} /admin.php [NC,OR]
RewriteCond %{REQUEST_URI} /login.php [NC,OR]
RewriteCond %{REQUEST_URI} /adminer.php [NC,OR]
RewriteCond %{REQUEST_URI} /lequ.php [NC,OR]
RewriteCond %{REQUEST_URI} /install.php [NC,OR]
RewriteCond %{REQUEST_URI} /setup.php [NC,OR]
RewriteCond %{REQUEST_URI} /shell.php [NC,OR]
RewriteCond %{REQUEST_URI} /user.php [NC,OR]
RewriteCond %{REQUEST_URI} ^/install/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/setup/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/plus/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/data/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/inc/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/.git/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/templates/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/fckeditor/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/config/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/administrator/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/admin/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/manager/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/cms/(.*)$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-admin/(.*)$ [NC]
RewriteRule .* https://www.[domain-name].com/busted.php?req=%{REQUEST_URI} [L]
The above is installed on many sites that I own or manage. The exact entries change from time to time, mainly in response to newly-discovered exploits. Obviously, none of the entries correspond to pages that actually exist.

busted.php in turn collects information such as the date, time, IP, name of the page originally sought (using a single line of php:

Code: Select all

$origRequest =  $_GET['req'];
), and so forth. It then stashes the data in a database, which in turn is used to compile the blocklists. The databases are pruned regularly, so all IP's are automatically rehabilitated in a few days if they stop misbehaving.

In addition, the script checks whether the IP has hit any of the honeypots or otherwise misbehaved within the past 900 seconds, and if not, reports it to AbuseIPDB. So the misbehaving IP's are available on both the lists I compile and from AbuseIPDB.

My free blocklists are available to anyone in the Internet-connected world and are updated daily. I also have paid (but inexpensive) blocklists that draw from the same database but are updated hourly.

The site itself is ad-monetized so I don't know if I'm allowed to link it here. But if you search Google for "Recently Misbehaving IP Addresses" you should find it. Feel free to use the lists if you like.

Richard