Hello Sumukha,
I am assuming there is no inc.php and no xml.php on your server and I am a wondering why they look like redirects. Do you know why there is a 301 (redirect) response code on those URLs? If you are not sure, you should check to make sure those files don’t exist.
When you know some URLs that should not be accessed by anyone you can go to Options/Other Options in Wordfence menu and add these URLs to the setting “Immediately block IP’s that access these URLs:”. An example of what you could put in there for your case
/inc.php, /xml.php
This will cause anyone who tries to access those to be blocked immediately. This can be very efficient to stop people who are trying to find entry points for exploits. Just make sure you don’t put any legit URLs in here.
Hi Wfasa,
thanks for your comment and advice.
There are no files like this on the server.
I will block these culprits the way you described.
Thanks again!
Very much apprechiate your help and the quality of this plugin.
Just upgraded to premium.
Glad I was able to help Sumukha. I’m setting this topic to resolved now. You are welcome to make a new thread in the forum if you have more questions.
Hey Sumukaha, can you tell the rest of us how those requests brought down your server? Did the server just crash because of too much traffic, or did you get an actual intrusion and subsequent hack? Thanks, MTN
Hello,
scanning did not reveal anything about modified or new files.
The amount of requests (about 10 per sec) put a very heavy load on the whole server which responded with a 500 error.
I still don’t understand what the 301’s are doing in the log. Seems that those requests are being redirected to the homepage.
I also wonder if this is a typical response that the whole VPS server – all the other sites on it included – goes 500.
Hosting with A2.
Thx
Yes Sumukha, regarding the 301s it would seem that 404s are redirected to your frontpage instead of returning a 404. It is a bit odd but you could try putting that URL in to your browser while keeping a browser console open and see what response the browser receives.
Found the reason: When we switched to https, one of our guys actually made an entry in the .htaccess file to redirect all port 80 requests to https…
No wonder the 404 protection did not kick in!
Thanks. Information is power.
Still want to thank the Wordfence team for their awesome work.
You are the best!
Thanks for reporting back Sumukha!
