Hackers accessing via POST /login.php - How to stop it?

A good remote DDoS protection with layer 7 filtering could block this kind of attack. However, if it isn't too large, you could simply use fail2ban and write a custom regex for it, which matches HTTP/1.x POST /login.php and reads your access logs and then bans every IP for X minutes that matches this pattern for X times within X amount of time. Should be quite easy actually - just let me know if you need help with the regex (to write one, I would need a few of the "bad" lines from your access logs).

 

Thanks. Going to back to what DeathShadow said, perhaps if there's no referal address coming from the login_page.php then I should redirect the user?

- I know some browsers don't have referal addresses but for this matter I'm dealing with recording false logins so I guess it shouldn't matter too much.

Would this work?

 if (!empty($_SERVER['HTTP_REFERER'])){
    header("Location: ".$_SERVER['HTTP_REFERER']);}
else
{
   header("Location: index.php");
}

Code (markup):

ideally I'd want some code that checks if the user is coming from login_page.php, if they don't then the form submit won't go through or they get redirected.

Cheers

 

you can install mod_security and use WAF rules from OWASP or Comodo WAF to block some of the attack, in combination with CSF firewall you can automatically block the IPs that trying to brute force attack your website

 

Thanks, is there a way to non block IPs? If the IPs are spoofed and random anyway, then perhaps that's not the area I want to go down...

I thought this would be a common problem among you guys with random IPs/usernames trying to login into your sites?

 

then configure CSF not to block the IP permanently, CSF can block the IP temporarily

 

But the IPs are different each time - one IP per failed login.

If a log in could be defined as a "tap" to the login page - if there's X amount of general "taps" or there's a larger frequency of them in an X period then couldn't there be code to stop that?

Thanks

 

my suggestion is to install mod_security on your web server, installing CSF firewall doesn't hurt either

 

I just checked and we have this already installed ;/

 

You know, I'm kind of laughing at some of these suggestions -- his problem is in a form submit, NOT a SSH, FTP or HTTP login; introducing such to it is only over-complicating things and NOT actually a proper fix since, well... how the **** is any of that going to address the core problem? (it isn't)

Though I suspect most of this is just more sleazy shortcuts to avoid putting actual labor into handling the blocking of mass addy's -- manually doing reverse DNS and blocking address ranges (like data centers) from which no valid requests should EVER originate in the first place via ipTables... or properly handling the timeouts/ip tracking yourself.

Of course, the subject of this thread is a form -- IF you have a form exposed to the web for a login, it IS going to be brute-forced a LOT; that's just the nature of the beast. Sweating it in your logs is usually a waste of time so long as they aren't getting in...

Though crazy question: which form is having this problem? Perhaps it's an issue with how the form itself is written?

Oh, and your code for messing with HTTP_REFERRER makes no sense... not sure what you even expect that to accomplish.

 

some of the attack use a well know bot which can be blocked automatically by mod_security rule, hence my suggestion.

 

don't forget to check on https://waf.comodo.com or OWASP project for mod_security rules

 

... and that's part of the problem with suggesting it -- setting up rules for it, which to be honest is WAY outside the average site owners or beginners scope or abilities. Just because it's installed, doesn't mean it's doing anything until you set up those rules.

I really think the 'problem' and 'solution' lie elsewhere on this...

 

Thanks I'm just happy DP users take time out to reply to this thread, any suggestions are most welcome!

I couldn't see a bot associated with the hack, I did think it might come from Acunetix but they usually come from all fronts and this one was quite specific and targetted.

They are trying to log in to the username/password fields to access the content. The other x2 sections which use the same form are the contact form and request forgotten password sections - but these 2 have a capcha.

Yes I think the conclusion is not to sweat it so much, it's good I know who is trying to hack the site but the site seems to be doing its job. Just a bit worried that the false login logs will cock up the site somehow if I get another 15k failed submits in a day.

 

That many submits -- if from different IP's -- seems unlikely unless it's a botnet attack, or a single data center. Again, that's why I'd go through and see how many have the first six digits in common... then reverse lookup one of those to see who it's from. If it's something like "time warner cable" or "Comcast" it's likely coming from botnets... if it says something like GoDaddy or "Net4.in" then it's a server or series of servers from a data center, in which case you can permanantly blacklist the entire address block without fear.

 

I've kept some of the false logs and I'm not seeing a pattern other than they'd stay around say:
109.163.xxx.x
- changing the last x4 digits for a couple of tries and then go onto something different like:
110.170.xxx.xx

- There's no system based on a similar IP or a common jump between the next IP it chooses or the number of tries.

 

Yeah I didn't think to reverseIP the IPs as I thought they were spoofed anyway.

But the countries are less favourable like from Russia, Mongola and Romania ;/ I guess I should geoblock their country

 

Deny access to no referrer requests with .htaccess

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} .(login|addmore)\.php*
    RewriteCond %{HTTP_REFERER} !.*example.com.* [OR]
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L]
</ifModule>

Code (markup):

Also, here is a simple solution to keep bad robots, spiders and web crawlers away: Block Bad Bots and Spiders using .htaccess

 

1. <form name="test" action="<?php echo htmlentities($_SERVER['PHP_SELF']); ?>" method="post">

change to:

<form name="test" action="#" method="post">

you don't need to use PHP_SELF and surely do not need htmlentities().

I wrote this function, use it.

if (!function_exists('spamhaus')) {
    function spamhaus($ip) {
        $rbl = 'sbl-xbl.spamhaus.org';
        $rev = array_reverse(explode('.', $ip));
        $lookup = implode('.', $rev) . '.' . $rbl;
        if ($lookup != gethostbyname($lookup)) {
            return true;
        } else {
            return false;
        }
    }
}
if(spamhaus($_SERVER['REMOTE_ADDR'])) {
           die('SPAMMER!');
}

Code (markup):

 

It seems like, someone knowingly bugging you.

 

Thanks guys, I'm going to go with generateHash in session to see how that goes. THe htaccess thing is something I forgot about and also if I used spamhaus, how much control would I have over what potential logins could see.