Expert Core: Open Source Security

In my last post, we discussed log files and how to read them. Understanding log files is vital skill in maintaining the health and safety of your Apache-based Web site, application, and/or machine. As I noted previously, an Apache log file typically (in 99.9% of the cases) has a format known as a COMMON LOG FORMAT. You can depend on the logs containing the information in the same order every time.

In this post, we'll drill down a bit into status codes. These are reference numbers that provide clear indicators of events on your server(s). They are generally broken into five categories:

• 100 - HTTP Status Codes - Informational
• 200 - HTTP Status Codes - Successful
• 300 - Server Status Codes - Redirection
• 400 - Server Status Codes - Client Error
• 500 - Server Status Codes - Server Error

Let's look at an example. Do you recall this entry from my last post?

87.118.117.XXX - - [05/Jan/2009:19:48:20 -0700] "POST /index.php?title=Main_Page&action=submit HTTP/1.1" 200 19272 "http://mydomain.com/index.php?title=Main_Page&action=edit§ion=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

In this example, the number "200" (highlighted in red) means, "OK: The request was successfully completed." While a 200 status code does not in itself indicate a security problem or exploit, it's one of the key "clues" you'll want to check if you see malicious requests or events in your log file. A 200 code in the log entry for a malicious "GET" or "POST" request, for example, might indicate that your system has indeed been compromised.

Another code, the common 403 error, effectively means, "Forbidden: The request was understood, but is being refused. It's typically recorded when someone has tried to access prohibited or protected information on the Web site. As a security flag, a 403 error in your logs might indicate a number of potential threats. For example:

• Malicious users might be attempting to browse directories on your server. Of course, most companies routinely protect directories from browsing (and use permissions to protect the files within those directories from unauthorized access and/or changes); however, even one unprotected directory can open access to information that you don't want to share.
• There's a user authentication problem somewhere in your system. This might be indicative of a more general usability or access issue.
• Someone is attempting to exploit a cross-site scripting vulnerability inherent in older versions (pre-2.2.6) of Apache Web servers.