After a very extended absence, I have finally returned. There have been no updates to the site since before March because I have been caught up with real life. For the record, I am in the Army Reserve and I needed to attend training for my specific Miltary Occupational Specialty. It took a long time and during that time, I was not able to make any specific updates to the site. My impending absence was the original reason that I moved all my web sites and other items to a dedicated hosting provider rather than continue to host them from my location.

The Web Server has been moved to a new hosting provider.

The mod_security module for Apache is one of the most versatile and easiest ways to provide a lot of security for Apache without too much effort. The hardest part of implementing mod_security is matching up the actual rules to your particular webserver so that you are blocking potential exploits but allowing traffic that is expected and necessary. For instance, there are a lot of PHP exploits that can be used against Apache, however, in most cases, you will only be running one or two of the potential PHP applications that those exploits are targeting. Normal security precautions would recommend that you limit your exposure by making sure that you keep current with security packages for those applications while disallowing all other PHP application traffic. This is where it becomes necessary to customize rules for mod_security to distinguish between normal expected requests and requests that you know are exploits.

Caveats: I run Mandriva 2006 and this howto assumes that you are running Apache 2 within the Mandriva 2006 version of the distribution. If you are not, you will need to check and alter paths as needed. Also, this howto assumes that you already have a working installation of mod_security.

Often when you hook up a new and sometimes expensive LCD Monitor under Linux, you may be underwhelmed by the result. If fact, in many cases, you will notice major discrepancies between the quality of the display under an OS like Windows and that provided by Xwindows under Linux. This is usually not the fault, necessarily of Linux. Manufacturers provide specific settings to Microsoft for inclusion in their OS, and even when they don't, they can provide an information file that tells Windows all of the details about the settings of the Monitor. Also, there is a specific technology that Monitors use to communicate their settings to the OS.

Extended Display Identification Data is a VESA standard data format that contains basic information about a monitor and its capabilities, including vendor information, maximum image size, color characteristics, factory pre-set timings, frequency range limits, and character strings for the monitor name and serial number. However, that sometimes doesn't work well with Linux and can either confuse the x-windows system, or cause x-windows to be overly conservative in configuring the display. Here is a way around that.

As a follow-up article to yesterday's article on blocking Referral spam with mod_security, I thought that I would include a discussion and copy of a script that I am currently using as a proactive addition to help with blocking referral spam. First, we should discuss why it might be necessary to take additional steps beyond simply blocking with mod_security, and then I will discuss the specific steps that I take.

Blocking wth mod_security will stop ongoing referral spam by causing the spammer to receive an error code and stopping him from infecting your blog or website with his referral spam. However, there are several other unwanted effects from referral spam and the mod_security solution does little to stop those. These include, using your excess bandwidth by hitting your site with multiple attempts to leave referral spam especially since referral spammers often use bots, including distruibuted zombie nets and they don't monitor the results of their traffic. Also, your log files will still fill with the errors caused by this traffic.

What can we do about that?