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

Is there a way of stopping hackers using post and get on our php based site?

No one's hacked the site, but I'm seeing the 1000's of row of failed attempted logins per hour and it's getting annoying.

- Any tips?

Thanks

 

try to check ip and block it for 15 - 60 mins if three or more time fails to enter the correct password.

If the login is private, emant only for some people then also password protect your directory. and give each private user their username and password.

 

The only way to really stop it is to completely remove the ability to login -- probably not an option for you

Other than that, the best you can hope for is to slow them down, as Sugavanas suggested, by tracking failed logins by IP address and blocking that IP for an hour or so should they fail more than three times in a row.

 

Thanks guys, its actually what I'm doing at the moment - which is now to block the 2nd failed login for 45 minutes (a bit harsh!), but even then I'm now seeing 1000 fake IDs per IP per second.

I thought if someone is trying to access the post /login.php directly - then I should be able to do something in htaccess? The actual login page is at login_page.php but the code is in login.php

 

you could use HTTP_REFERER and stop people from directly accessing the login page but this could be a problem too in soem cases

 

That's why you block the IP, NOT the login name for that period of time.

You also might want to reverse DNS some of those IP's to see if they're coming from known ranges... if they say... resolve to a data center in Nigeria; just ban the whole address block at the OS level with ipTables.

 

ya as @deathshadow said, try blocking the usernames for sometime as well as also block the all ip blocks. In most cases the ip should be from the same subnet so block it in whole.

Try getting about the ips details and if it's online from a host, you can write in a phising issue to them.

I have received some phising requests from my host to another site and i have banned them immediately. So they may help you as well.

 

@misohoni Add Re-captcha ...

 

when hacker using proxy there is no usefull by blocking ip. you just try captcha security. when some on passed captcha then only query work.

 

Cheers capcha is probably the best option then, each failed login comes from it's own IP, so there's 1000's of them. I think it comes from Acunetix but not 100%

 

rename the login.php to logon.php.

 

Its a good idea but may make users go mad with it. Entering it everytime when they log in.

Like in simply debrid, i have to enter the password eveytime and they don't have a remember me option.

Please send me some of the ips. I will check. If they are from same subnet, they shudn't be a problem

 

What program/cms/forum is this happening with? Most major packages have a huge variety of anti-spam add-ons.

 

Try to work with .htaccess, as example, to access that link you have to provide another one password (written in .htaccess)

 

That's a VERY good question... if we could see the form in question, and possibly also the back-end code handling it, we might be able to weigh in better on solutions. Tying in a blacklist like that provided by stopforumspam, spamhaus or spamcop for your forbidden IP's could go a long ways towards neutering bad traffic.

It's also why I have my own list of IP's blocked via IPTables that get the DELTA approach. Don't Even Let Them Aboard -- as opposed to TWA, Those Wacky Arabs.

You might be even able to chop them off at the knees by simply adding a unique session hash to each form with it's own expiration; crazy as it is many bots fall flat on their face for that as they don't bother making a form request for every attempt. As also mentioned checking HTTP_REFERER can work too -- really if it makes it so some people can't use the form, my response to that would be OH WELL. It's easy enough to fake, but most spammers don't bother (or don't know how). A hidden honeypot for rejection is yet another approach -- There are a great number of things I would try before going for a captcha, as that REALLY should be left as a last resort.

But without seeing exactly where you're at, it's hard to say what the next best step is.

 

Sort of solving my own question here, but what if I contained the form's action (which is basically the file being targetted) on the actual page using - Using PHP_SELF in the action field of a form?

If I used

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

Code (markup):

would this be better and have a php inset above the form?

 

Would have zero effect, the ACTION is the ACTION, changing how you echo it out to the markup doesn't change anything. AT ALL.

 

I've looked into this further guys, changing login.php to something else DID work for 12 hours or so - now I'm getting potential username/password hacks every few seconds.

The system I use blocks an IP automatically after 2 failed logins. The logins that are coming into the site use a different IP each time, even different usernames and passes - so I couldn't setup a table to check and auto-block/blacklist them.

I think there is some legs with HTTP_REFERER but wouldn't know where to begin. I checked the logs and there's no actual refer from a bot coming into the site. Has anyone else suffered something like this?

- Perhaps at the end of the day, it's nothing because I'm recorded all the failed logins (which perhaps you guys don't do?) - but after seeing 14k failed records in one day it's a little nerve wracking.

 

I used to own a medium sized forum a few years back and had several issues with this, bot SQL injection attempts etc. The best advice is to implement the security features that won't impact your actual users-or impact them as little as possible. You can combine several things such as captcha after failed login attempts, IP region blocking, etc.

How's your server load/bandwidth holding up with 14k failed records/day?

 

I think the failed login thing is ok, it blocks users for X amount of time. But I guess I'm seeing a new form of bot with different IPs, no http referer and blasting every second.

I've got GeoIP blocking on certain countries too..

The server load is holding up ok ;/