Tag Archives: site management

The Necessity of Patch Management

One aspect of site security is neglected more often than any other: Keeping your CMS software patched and up to date. We see this problem occur over and over again. Clients purchase websites with content management systems, then once we hand it off to them they do not keep it patched.

We’ll say it again: You must keep up with your website’s CMS software patches! A large number of Joomla! sites were recently compromised by a bot that specifically searched for a very commonly-installed extension which had been the subject of a security patch. The hackers knew that many people would have failed to install the path, so the bot looked for unpatched versions of the extension as a doorway into the site. It worked very well; a number of sites fell victim.

Your CMS software is no different than the software on your desktop, your notebook, your smart phone: There will be patches and maintenance releases and you must install them to keep your site safe from attackers. Also, don’t forget, many times those patches also bring with them new functionality or improved performance, so if you fail to take advantage of the upgrades, you may be missing out on enhancements that also add value to your site.

If you are not comfortable doing upgrades yourself, find someone to help, or contact us. Charges for this type of work are very low — unless of course you have neglected it for too long and you already have a problem — then it gets expensive!

Measuring Site Performance (Part 3)

Popularity metrics are a set of yardsticks by which you can judge the relative popularity of your site over time. The primary metrics are:

  • Unique Visitors
  • Visits
  • Page Views (Impressions)
  • Average Visit Length

Your web server archives the information needed to generate these numbers and many others. The raw data is stored on the server in what is known as a log file. The statistics referenced above are best accumulated through the use of a log analysis program to convert your hard-to-read server log files into an understandable format. The most popular of these programs is WebTrends (www.webtrends.com).

Let’s take a quick look at each of these popularity metrics. The number of Unique Visitors is perhaps the most vital statistic as it counts the visitors to your site and then factors out double counting. (Note that this statistic is far more meaningful to you than the oft-referred to Hits statistic.  Hits simply tells you the number of files transferred from the server to the visitors’ computers. While this initially sounds good, it falls apart when you learn that a single web page can contain a large number of individual files, each of which is counted and contributes to the total Hits count. Hence the Hits number can be easily manipulated by site owners by varying the number of individual files on any page.)

Be aware that there are limiting factors in the counting. The primary impact comes from what are known as Masked IP Addresses, that is, networks that automatically give all their users the same IP Address.

An IP Address is an identifying number given to each computer connecting over the Internet. Servers use IP addresses as a convenient way to track visitors. This brings us to an important point: Unique Visitors does not count people, it counts computers, and that is the root of the problem.

The biggest Masked IP Address villain is AOL. All AOL users share the same IP address,  so when 35 people from AOL visit your site in a week, your number of Unique Visitors stat will count only 1 visitor.

Another limiting factor is multiple users on one computer. If all four members of my family visit your site one week, you only see one visitor in the number of Unique Visitors stat.

The Visits statistics gives the total number of visits to your website during the reporting period. It is a useful metric when used to temper the Unique Visitors stat for purposes of arriving at an accurate picture of the trend of activity on your site. Remember of course to factor out double counting as one person visiting the site 25 times in a week will show 25 visits. In other words, remember this is Total Visits, not Total Visitors.

Page Views (also called “Impressions”) tells you the total number of pages viewed by site visitors during the reporting period. So, if Visitor A looks at just the Home Page, but Visitor B explores the site, visiting 9 pages before leaving, Visitors A & B would be collectively responsible for 10 Page Views (1 + 9).

The Page Views number is also susceptible to a degree of miscounting, as cache files cause undercounting and search engine robots can cause over counting.  The cache files problem is very hard to detect and according to some sources causes up to 30% undercounting. The severity of the problem depends largely on both the way your site is built and how your server is configured. This is a complex problem to solve and if it is key to your efforts it should be discussed with your IT team or vendor prior to construction of the site.

Search engine robots (or “spiders”) can be easily factored out if you use a program such as WebTrends. WebTrends maintains a separate count of visits by robots, allowing you to adjust for them with an acceptable degree of accuracy.

The final primary popularity metric is Average Visit Length. Ever wondered if your site is sticky? This is the key indicator. This should be tracked across time for a trend. Content-heavy sites, subscription sites and sites relying on ad revenues obsess on this number as it indicates pretty clearly the success of their efforts to draw and hold an audience to their site.

The numbers above are primary metrics — key indicators. You can easily go beyond these numbers for more information, but the numbers above should the first stop for inquiries relating to how the traffic on your site is moving across time. Next column, we’ll look at a variety of eBusiness metrics.

Measuring Site Performance (Part 2)

In this column we will continue with our examination of website metrics. Last column introduced the idea of performance metrics and the basics of what to measure. In this column I would like to go a little further into discussing the implications of those metrics.

From a business perspective, performance metrics are not an exercise in technical esoterics, but rather an attempt to gauge your site’s performance as it affects users of your website. For some firms, performance is mission critical. If, for example, your site includes ecommerce functionality, it is necessary to maintain an always up, always accessible website. A slow site or downtime translates into lost sales. Similarly, though of perhaps a less critical nature, if your site offers online customer service the performance of those customer facing systems is critical to maintaining customer satisfaction. But the list of those affected by poor site performance doesn’t stop there; poor performance will have a negative effect on any website. Web users tend to be impatient, and as the cliché goes, your competition is only a click away.

I am sometimes amazed by companies who tolerate under-performing web properties. Would you mail to your customers a brochure that they cannot read? Would you air a television commercial that contains only half a picture and garbled sound? Obviously not, but companies still produce similarly flawed websites — and then discuss cynically how the Web doesn’t deliver on its promises.

The web is not the problem, the sites are. While we here in Thailand must suffer on in a bandwidth desert, it doesn’t mean that Internet connections as a whole are problematic. Moreover, while we cannot do anything about our bandwidth situation, we can make sure that the sites we produce perform well, regardless of the users’ environmental constraints. We must strive for world class standards and to the extent possible offset the peculiarities of the local market with smart design.

Last week we talked about key indicators that would allow you to assess your site’s performance. I mentioned:

* system uptime
* server response times
* page download speeds
* server errors
* failed hits
* form failures
* effective bandwidth per user

What do those numbers tell you?

System Uptime tells you the percentage of time the server was available and delivering web pages to site visitors.  Down time is what we want to avoid.  Down time is an inescapable reality as servers require re-starts and re-boots due to a variety of factors, including perfectly normal operations like software upgrades. What we need to avoid is excessive frequency and long duration of any one event. This data is generally supplied to you as part of your hosting support package. To improve service in this area, look for a web host partner who gives you an uptime guarantee.  If this is mission critical to your firm, build redundancy in drives (e.g., RAID 5), in processors (multi-processor machines), and in machines (clustering).

Server Response Times tell you how quickly the server responded to a request from a site visitor. Every time a site visitor clicks on a link a request is made to the server. We want the server to respond quickly, regardless of load.  This statistic is commonly mined from stress tests in order to determine how response time varies under load. To improve this metric you must look a variety of items, including whether your code set is optimized to deliver the fewest requests possible and to retrieve the data quickly (the latter is often a database optimization issue). Another key factor is the hardware itself — is it up to the job?

Page Download Speeds will tell you, on average, how long it takes for a page to load completely. This is a metric you can benchmark yourself (click and count!) but remember that your analysis will be skewed by your local Internet connection and the browser you use. To get accurate metrics, sample from a variety of locations. The key factors here are the size of the page and the performance of dynamic content (database-driven content) on the page, if any.

Server Errors, Failed Hits and Form Errors are your key error indicators. This data can be found in your log files (or your WebTrends report, as discussed previously). Note that all errors are not created equal and that means you need to look at more than a raw count; you need also to look at the type of error generated. The type of error will help you identify server performance problems.

Form Errors data is critical as this indicates how the forms on your site are performing.  A form that fails a disproportionate percentage of the time can indicate problems with either your code on the form or with some problem in your system architecture.

The last factor mentioned, Effective Bandwidth Per User, tells you how much bandwidth is available to each site visitor and is a good indicator of whether your current hosting set up provides adequate bandwidth to support the site’s traffic. This data can be found by running a server stress test. If you find your bandwidth plateaus at unacceptably low levels, you should be looking at a bandwidth package that gives you guarantees of peak usage availability (bandwidth on demand).

That’s it for this week. Next article we move on to Popularity Metrics.

  • view Part 1 of this Artilce
  • view Part 3 of this Article

Measuring Site Performance (Part 1)

Establishing a set of reliable metrics for measuring the performance of your web site in the real world is a key success factor. In the next few articles, we will explore what can be measured, how to do it, and how to turn that data into some useful intelligence for your business.

Web site metrics can be roughly classed into three categories: performance measures, popularity measures and e-business measures. Today we will examine the first category _ performance measures.

Performance measurement is all about how well your code and hosting setup perform in actual use. Responsiveness and reliability are your goals and achieving those goals will require management of three key variables: the code set, the hardware, and the bandwidth.

In order to assess whether you’ve put together the optimal combination of the three factors, you will need benchmarks and objective indicators of the sites performance. Key indicators include:

  • system uptime
  • server response times
  • page download speeds
  • server errors
  • failed hits
  • form failures
  • effective bandwidth per user

The technophiles will wax rhapsodical about terms like throughput and latency, and certainly they are key technical indicators, but from a management perspective, the metrics are more understandable when expressed in the terms given above. That is, when expressed in terms that relate to the actual end-user experience.

Important sources of data include your Web Trends reports (or other log files), Web Check, server stress tests, and third-party services like Keynote. Server log files give you insight into server errors, form performance and the like, but will tell you nothing about download speeds, uptime, or effective bandwidth.

The industry standard for log file analysis is Web Trends (www.netiq.com/webtrends/). The Web Trends products take your log file data, organise it into useful categories, and display it in graphical formats that can be interpreted by laypeople. To get Web Trends, contact your web host, as they likely offer the service for a monthly fee. It is very affordable _ I have seen it offered for as little as US$2 per month.

Alternatively, if you own your own server, you will need to purchase a license or subscribe to Web Trends’ web-based service.

For more technical statistics, you will have to seek out the assistance of someone with the IT skills to run the tests and interpret the results. The WebCheck system is offered by CompuWare (www.compuware.com) and is a good benchmarking tool for checking a variety of data relating to the integrity of your site. It will help identify slow pages and errors in your link structures. The reports also give basic recommendations for handling problems.

CompuWare licenses aren’t cheap and as a result few firms outside of the IT arena maintain them. Try contacting your IT vendor about WebCheck, as they are likely have a licence for testing purposes.

Web server stress testing tools are another invaluable aid to measuring your performance. A server stress test will simulate loads on your server and provide analysis of effective response times, errors, and bandwidth per user. These tools tend to be quite technical but are excellent for assessing the robustness and scalability of your site. If you are planning a promotional campaign or a web-based event, a server stress tool allows you to simulate in advance load scenarios in order that you may determine whether your site is up to the job.

This year’s Superbowl provided a great lesson on the necessity of projecting loads and testing server capacity in advance of major events. Cadillac, Philip Morris and Universal Pictures were among the 17 advertisers who premiered new ads during the SuperBowl. Unfortunately for the companies, their commercials were too successful _ traffic to their web sites jumped dramatically after the commercials aired and their sites slowed to a crawl, becoming basically unavailable for the duration of the game.

In contrast, Sony, McDonalds and Levi Strauss all anticipated the load spikes and their sites remained accessible throughout the game. No executive ever wants to hear the phrase “your site’s down again,” so test it before the game!

A number of firms specialise in providing independent testing results for sites. Perhaps the best known is Keynote. The company has a large network of testing facilities globally and as a result they are able to produce snapshots of site performance and send you alerts when performance levels fall below a certain point. For a quick look at the metrics, try this link to Keynote indices:www.keynote.com/solutions/solutionspmperformanceindicestpl.html.

In the next Article I will expand on this topic as we delve further into measuring success online.

Securing the Joomla! Core

Security is not one single thing; it is a process, a set of steps that need to be taken in order to achieve a result. The process begins with your server settings and the Joomla! core files. If you fail to make this base level of the system secure, than additional steps are at the very least of limited effectiveness, at the very worst — they are pointless. Note as well, the first step towards assuring your site’s integrity is also one of the easiest: Only install the most recent version of the Joomla! core file packages found at the official download site, JoomlaCode.org. Do not download and install core file archives from other sites, as you cannot be certain of their origins, completeness, or integrity.


This article is excerpted from Ric Shreves’ upcoming title, the Joomla! Bible, from Wiley & Sons. That book is due for publication in early November and can be pre-ordered directly from the publisher at www.wiley.com. Watch this site across the coming months as we preview more from this new title. This article originally appeared on the author’s site,RicShreves.net.



There are several steps you can take to enhance the security of the directories and files on your server. The first step is adjusting the permissions to be as strict as possible without impairing use of the site. Write-protect your critical directories. As a general rule, set the directory permissions to 755 and the file permissions to 644 using either FTP or the options in the Global Configuration Manager. Note that this is best done after you have fully completed your installation of the core and all Extensions. It is possible that you may have to make these setting more permissive if you need to install Extensions in the future.

There’s a good discussion of how to set file permissions and what they all mean on the Joomla! docs site — visit the resource to learn more.

There are a number of other steps you may want to consider taking, however you should note that each of these has a trade-off, either in terms of increased admin overhead or other limitations:

  • Move the configuration.php file outside of the public HTML directory on your server and rename it. Place a new configuration.php file in the public HTML directory pointing to the new file. Make sure your new file is not writable in order to avoid it being overwritten by the Global Configuration Manager. Note that making this change will force you to modify the new configuration file manually, rather than by using the Global Configuration Manager. For more information on how to set this up, see,http://docs.joomla.org/Security_and_Performance_FAQs
  • Use .htaccess to block direct access to critical files. Note this is only applicable to servers using the Apache web server and webhosts that allow you to modify .htaccess. Make sure you backup your old .htaccess file before you try this in case you experience problems and need to restore the old file.
  • Change the default log path. Hackers sometimes look to the log files as a way to identify what Extensions you have installed, in hopes of finding an Extension that has a known vulnerability they can exploit. To help deter this bit of information fishing, alter the log path settings in the Global Configuration Manager.
  • Change the default temp directory. The contents of the temp directory can also provide information you may not wish to disclose about your site. You can alter the temp directory settings in the Global Configuration Manager.


Humans are your most common point of security policy failure. Admin passwords should be changed often. The default user name that is produced for the administrator during the installation process should also be changed immediately after the system is set up. Leaving the default user name as “admin” gives a hacker one half of the answer to the puzzle they need to solve to gain access to your site. (Note that some commentators go further and recommend that you create a new superadministrator account and delete the one that was auto-created by the Joomla! installer.) Hopefully it goes without say, but passwords should also be as secure as practicable.

In addition to controlling the access to your admin system, you need to be sensitive to the access issues that relate to your database. If you have control over the access privileges to the user accounts on your MySQL database, make sure that all accounts are set with limited access.


If you don’t need it now and you don’t intend to use it, get rid of it. Logical targets for deletion include: unused Templates and Extensions you have installed then decided not to use. Go further and disable unused core components as well. Not only does this make the site more secure (by removing one more potential access point) but it also removes unnecessary clutter from the admin interface.

If you have copied archive files to your server during the course of installation, make sure you get rid of those. Don’t forget the installation directory — don’t simply re-name the installation directory, delete it! Another candidate for deletion is the system’s XML-RPC server. If you are not using this functionality, delete it. It is located in the Joomla! root in the directory named xmlrpc/


In an ideal world, we would all have our own dedicated servers where we could control every aspect of the system. In the real world, shared hosting is the reality for many users. Shared hosting, though certainly more cost effective than a dedicated host, involves trade offs in terms of security and access privileges. Your goal should be to make the host set up as secure as possible, regardless of whether it is dedicated or shared. Exactly what you are able to do with your server varies, but you should consider the following:

  • Use Secure FTP, if available. This helps avoid the possibility that someone can determine your username and password while you are in the process of a file transfer.
  • If possible, use PHP 5. While both PHP4 and 5 are supported by Joomla!, PHP 5 is the superior solution and PHP 4 is being phased out.
  • Make sure your server does not have Register Globals enabled. Joomla! does not need it and it is a security risk.
  • If the mod_security module is installed on your Apache web server, use it. It acts as an embedded web application firewall and provides significant protection against many common attacks. Learn more about how to use it.
  • Turn safe mode off. Safe mode is not necessary for Joomla! and may cause problems with some Extensions.
  • Set Magic Quotes GPC to On.
  • Don’t use PHP allow_url_fopen. Set this option to Off.
  • Use PHP open_basedir. Set this option to On.


The Joomla! Team and Community have created and maintain a number of useful security resources.

Name of resource URL
Security Checklist: Getting Started http://docs.joomla.org/Security_Checklist_1_-_Getting_Started
Security Checklist: Hosting and Server Setup http://docs.joomla.org/Security_Checklist_2_-_Hosting_and_Server_Setup
Security Checklist: Testing and Development http://docs.joomla.org/Security_Checklist_3_-_Testing_and_Development
Security Checklist: Joomla Setup http://docs.joomla.org/Security_Checklist_4_-_Joomla_Setup
Security Checklist: Site Administration http://docs.joomla.org/Security_Checklist_5_-_Site_Administration
Security Checklist: Site Recovery http://docs.joomla.org/Security_Checklist_6_-_Site_Recovery
Joomla Security Strike Team Contact Form http://developer.joomla.org/security/contact-the-team.html
Security and Performance FAQs http://docs.joomla.org/Security_and_Performance_FAQs
Automatic Email Notification System http://feedburner.google.com/fb/a/mailverify?uri=JoomlaSecurityNews
Security RSS Feed http://feeds.joomla.org/JoomlaSecurityNews
Joomla! 1.5 Security Forum http://forum.joomla.org/viewforum.php?f=432
Vulnerable Extensions List http://docs.joomla.org/Vulnerable_Extensions_List
Security Announcements for Joomla! Developers http://developer.joomla.org/security/news.html
Joomla! Developers Security Articles and Tutorials http://developer.joomla.org/security/articles-tutorials.html