Select your language

What makes a website a target of attack?  Is your website a potential target?  Do you know if your website is being targeted?

I don’t know what makes a website particularly attractive to hackers.  Some people just have too much time on their hands, I guess.  The purpose of this article is to share some ideas about how to be forewarned to the possibility that your Joomla website is in the cross-hairs of cyber-hackers and, therefore, if site owners may need to implement additional security measures that site owners have put in place (or not put in place) to prevent such attacks.

All too frequently we read stories on internet discussion forums from people asking about the source of successful attacks on their websites (including the discovery they've made about “peculiar”—meaning odd/unexplained—files that have been added to their websites).  Usually and unfortunately, these questions are raised after websites have been hacked and vandalised.

After years of operating their website(s), a lot of people puzzle over why other people might be interested in attacking them.  People also ask how they may be fore­warned of im­pen­ding dan­ger.

I don’t have all the answers to these questions.  No-one should ever be complacent about site security, of course, but we must all remain vigilant to possibility—and, in the worst case, the eventual success—of attack.

Indications of possible site attacks

If you are an experienced website owner, the source of possible attacks is usually located in the server logfiles for your website(s).  This isn’t the only place you should look but it may give you an indication of suspicious activity occurring on your site(s).  When someone (or something) plans an attack they may visit a site to see what kind of software is being used.  One early indication that your website is being probed may begin with innocuous-looking URLs in the sitelog,  such as attempts to access a URL like this:*

Another way to see if a website is being probed is to see if your site is returning “404” response codes.  Fortunately there’s a more “user-friendly” mechanism built into Joomla to help you see what URLs are generating “404s” and what kinds of URLs are being used.

Screenshot of J! redirects plugin showing spamdexing/phantom URLsMost people don't use Joomla’s Components » Redirects feature:  to use this feature requires enabling the System - Redirect plugin.  As an experiment, I enabled the plugin and, within the space of less than 48 hours, the Redirects component had collected a lot of odd-looking URLS (see the image at right)).  Where did these things originate?  Now that’s the $64,000 question!

What we know is that people or automated processes run through a script of known exploits to see if a website returns a HTTP “success” code.

Although the Redirects component in Joomla is not a guaranteed method of detecting possible attacks, it is useless in the event of a sustained attack where a website is continually bombarded by enough requests that makes it impossible for the site to continue to operate at all!  This form of attack is usually referred to as a denial-of-service.  Now that we’ve got this out of the way, let’s dig further to see what we can do with the Redirects component.

Enabling the System - Redirect plugin adds new records to the _redirect_links database table whenever a “404” is encountered.  It’s probably a good idea to keep an eye on how the list of “404s” is growing; normally the growth rate is slow and, after a few weeks, you may not see more than a couple of dozen entries added to the _redirect_links table if everything is running smoothly.  If, however, there’s a surge in “404” activity, it may be an idea to purge the entries in the Redirects component and disable the plugin pending further investigation.

Unfortunately, the one “feature” that’s lacking in the Redirects component is the information about where these URLs are coming from.  As I men­tioned earlier, that information is stored in the server logfiles and it will be the subject of a future article where I may discuss how you can leverage this information in a more con­ven­ient way instead of dumping the logfile to search for these “404” entries yourself.

What you can do if someone is snooping around your website

If your website is being probed sporadically—between 1 and 10 times a day, say—you can use the Redirects component to redirect these URLs to a different target (e.g. redirect those URLs to  If you were so inclined, you could redirect the URLs to a procedure you design yourself that traps the information, sends you an email or logs the details of the originating IP address.  How you use the Redirects component is entirely your business.

If all this random spying is beginning to worry you, the main thing is don’t panic.  There are ways to block unwanted visitors from viewing your website (including crawling by search engines); sometimes you may need to harden your .htaccess file with a few extra rules, such as

RewriteCond %{REQUEST_URI} /wp\-
RewriteRule ^ [L,R]

or possibly

Deny from

if these things really get up your nose!

The main point is that there are ways to detect suspicious activity on your website; there are many ways that you can prevent this suspicious activity turning into a nightmare.  As always, a critical part of keeping your website secure is to ensure that the software is up-to-date and that you’re not using software that is known to be vulnerable to attack.  It is better to be forewarned than to be ignorant.  The fate of your website is in your hands.  Don’t allow yourself to become another statistic, a victim of a successful attack on your website.


While there’s some truth in the adage “a little bit of knowledge can be a dangerous thing”—this is certainly true from the viewpoint of a cyber-terrorist who will use any know­ledge they have about your website(s)—there is an equally important saying:

The only good is knowledge; the only evil is ignorance.Herodotus, c. 484-425 BC


*  This is the syntax used on Wordpress sites to access a user login form.  Websites created in Joomla or other CMS applications do not use these URLs and will normally return a HTTP 404 - Page Not Found response if someone tries them.  If the website returns a HTTP 200 - Success response it could mark the beginning of a brute force attack on the site.

No comments