After experiencing a very high amount of hits on my 404 page, I've started monitoring my website's Error Log. There I've found that through-out the day, there are several attempts at accessing admin folders and editors on my website that I does not exist. For instance, there are attempts at accessing Word Press and fckeditor's admin folders, but I don't have either.

Any thoughts as to what I should do about these attempts, and if they should be a cause of worry or not?

Examples from my Error Log:

[Mon Jun 23 16:17:17 2014] [error] [client] File does not exist: /home/[snipped]/public_html/admin, referer: [snipped].com/admin/editors/fckeditor/editor/filemanager/upload/test.html
[Mon Jun 23 16:16:39 2014] [error] [client] File does not exist: /home/[snipped]/public_html/administrator
[Mon Jun 23 16:16:39 2014] [error] [client] File does not exist: /home/[snipped]/public_html/wp-login.php
[Mon Jun 23 10:39:13 2014] [error] [client] File does not exist: /home/[snipped]/public_html/admin
[Mon Jun 23 08:31:49 2014] [error] [client] File does not exist: /home/[snipped]/public_html/fckeditor
[Mon Jun 23 05:34:19 2014] [error] [client] File does not exist: /home/[snipped]/public_html/editor
[Mon Jun 23 05:34:17 2014] [error] [client] File does not exist: /home/[snipped]/public_html/admin
[Mon Jun 23 05:34:16 2014] [error] [client] File does not exist: /home/[snipped]/public_html/FCKeditor
[Mon Jun 23 05:34:12 2014] [error] [client] File does not exist: /home/[snipped]/public_html/editor
[Mon Jun 23 05:34:10 2014] [error] [client] File does not exist: /home/[snipped]/public_html/admin
[Mon Jun 23 05:34:06 2014] [error] [client] File does not exist: /home/[snipped]/public_html/Fckeditor

At last, does anyone know how where I can get more information about some of the errors reported in cPanel X's Error Log? For instance, I have lots of entries for

File does not exist: 405.shtml

but I have no idea what page or link has generated them, so I don't know where to go to fix the source of the problem.

6 Answers 6


This is unlikely to be "visitors" (real people) but is likely to be automated software testing for vulnerabilities in the software run by your website. I've seen these types of requests for years. The most common for my servers is requests for WordPress administration pages and Microsoft FrontPage extensions.

If you are not running the software, these requests should have very little impact or risk for your website.

The standard advice for keeping your software secure applies to web software as well: Keep the software up to date. Security vulnerabilities in content management systems are discovered often. My web host even offers to automatically upgrade WordPress for me when new versions come out.

  • Thank you so much for your reply. I didn't even know what fckeditor was before seeing it in my error log, so I'm definitely not using that software. Thanks for the advice :) Commented Jun 23, 2014 at 18:34
  • 3
    @SaraC.Schwpz If I see a trend, where the requests are coming from the same IP over a span of days, I will often lookup the IP and see where it is coming from. I've found some attempts coming from universities, so I contact the IT administration at the organization with a copy of my logs so they can potentially take further action. In many countries, the mere attempt at exploiting or unauthorized access to a computer system is a crime.
    – Chris
    Commented Jun 23, 2014 at 19:03

Unfortunately general website security is too broad for this "Pro Webmasters Stackexchange" format. How you handle this depends entirely on the size of your company and what you're trying to secure.

If its a simple website without confidential data, just ignore them and make sure any control panels are hard to find / ip restricted.


  1. Change the admin panel from website.com/admin to website.com/schwpzhashkey
  2. Put ip restrictions in the web server configuration to only allow control panel access to certain ip addresses.
  • Thank you so much for your answer. I hadn't thought about placing IP restrictions to vulnerable areas - awesome suggestion! Commented Jun 23, 2014 at 18:29

There is likely nothing you have done. Welcome to the world of hackers.

This is something I research.

There are many software packages designed to landscape and hack websites. The access for admin, wordpress, and so on are at the very least landscaping attempts to figure out what systems you are using and what vulnerabilities exist for your site. Some accesses may be actual hack attempts.

Looking at the log snippets you provided, these are landscaping attempts. They are attempting to access various possible vulnerable PHP software. I say possible, because at this point, they are trying to figure out what is installed. That is step 1. Step 2 is to then probe any software you have installed for version which is then compared to a vulnerability database to determine what vulnerabilities that they can attempt next. Step 3 are actual hack attempts whether it is successful or not.

Most of the time, these are Trojan horse software from systems that are compromised. The hacker is working through an anonymous proxy to give hack commands/code to these Trojan systems.

I would highly advise you to keep an eye on your log files and begin blocking any domain names and IP addresses immediately.

Update: I had to run away earlier- one of my contractors showed up early.

There are some security tools out there, but for web servers the best seems to be mod_security found at https://www.modsecurity.org/. I will get back to this in just a second.

The advice to update your software often is not always a good one. New installs can open new vulnerabilities. Ironically, the safer installs can be older ones. Case in point the Heart Bleed vulnerability was due to a recent update, however, if you had not updated right away, there was no vulnerability. Another example are older installs of RedHat 6.2 with Apache 1.2 which do not seem to be compromised like newer installs. You have to take this on a case by case basis. A blanket update your software has the potential to be dangerous advice. Hackers are almost always looking for recent vulnerabilities, or vulnerabilities that are likely still installed. There is a moving window style view of security. As newer versions of software comes out, older ones are less likely to be hacked.

Still, all and all, it is a good idea to keep in mind any update for software and check to see if a vulnerability exists on your system before installing an update. It is often wise to defer an update if there is nothing to fix from an security or feature perspective. Make it a habit to check for updates and vulnerabilities. The best way to do this is to check http://web.nvd.nist.gov/view/vuln/search?execution=e2s1 from time to time (actually frequently) to see if there are issues. There is an e-mail list somewhere that I am trying to find. The e-mail list keeps you up to date immediately With the web address you can find all the known details there are. Again, only install updates that are vulnerable or needed.

Back to mod_security. Mod_security is like a WWW firewall. It can block most if not all hack attempts but you do have to maintain it. It is wise to install software like this to prevent the attack attempts from reaching your web server. You can also use an HTTP filter in your firewall if you have one. If you are familiar with regular expressions, this is a very powerful option for you. The point is, the hack should not reach your web server, PHP, PHP application. Mod_security is a far more powerful option than updating several PHP applications, PHP as they come out which is the most frequently hacked platform there is by a huge margin. In fact, PHP is textbook what not to do when writing a secure software platform.

Remember- this is what I do for a living and have for a long time for all of the major telecoms and research for security protocols for the nations infrastructure. Pay attention to security if not each day, several times a week and set up alerts for announcements where you can.

  • Thank you for your reply. That explains the attempted connections to software I don't even use. I'm not entirely convinced about the suggestion of blocking IP addresses though. The requests seems to come from several different IP ranges, and if it is as you wrote, that they originate from hackers working through anonymous proxies, would IP banning actually have an impact at all? Commented Jun 23, 2014 at 18:39
  • Yes. And no. But mostly yes. It is almost a daily chore, but hackers tend to use a few proxies once the software starts. The software may not always update with new proxies, though some do this automatically, sometimes the proxies have to be maintained manually. You will see in your log file accesses from several IP addresses for a period, but then it can change. Since generally all hack attempts actually come through compromised systems, the IP addresses do not change too often. Between the proxies and compromised systems, it is actually not too hard to block by IP address.
    – closetnoc
    Commented Jun 24, 2014 at 0:22
  • I updated the answer. It will explain a bit more. I have been doing security work for 30 years for all the major telecoms and now I research automated adaptive methods and keep my heart open for the poor webmaster who is often ignored in the security world. Plus- I like webmasters! I have no idea why, but I do. You all are a special group of people.
    – closetnoc
    Commented Jun 24, 2014 at 1:19

I have the same problem, so I wrote a custom 404 page that parses the requested URL, then based on patterns I choose (from my log files), either displays the standard 404 page, or adds their IP address to a file that's checked before any of my pages are displayed. The very next time they try to access ANY page in my site they're just redirected back to their own IP. It's a quick and dirty fix but it keeps them from seeing any further into my system after just one or two tries instead of thousands.


I redirect those attack pages like "wp-login.php" to our security page.

  • You can implement the redirect, but it isn't likely to change anything. The requests are generally automated by programmed robotic scanners. No human will be looking at your security page because of it. Commented Aug 9, 2016 at 18:22
  • Would this stop them from entering the log? I'm concerned that my error/access log will be full of bogus requests. Commented Aug 7, 2018 at 13:53

I get a lot of these on my site. Since I already have a system in place that lets me easily block IPs on my firewall on the fly, from PHP, I've started blocking people that hit any of these urls for 7 days.

If you can't or don't want to make a system like this, you could also try various techniques to lessen the bandwidth used. Of course you'd only want to bother with this if you were getting thousands of these hits per day. You could maintain a list of "bad urls", and on your 404 page, see if the actual requested URL is on the blacklist. And if so, "exit;" right away without sending any data. This would be pretty pointless for a handful of hits per day, but not a terrible idea if you're getting thousands.

Since I already have my blacklist in mysql, I made a second table for unknown 404s. Any requested url that is a 404, and is not in my blacklist, gets added to this list. This way I can keep an eye on what URLs are being requested, and how often. If something is getting a lot of hits, I can add it to the blacklist and bye bye.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.