Secure connections to your web server

This is a page where we post things we've experienced, but haven't had time to really describe or flesh out yet. Most have to do with Linux web servers.

Also see our security tidbits section!

Redirection of http://domain.com to http://www.domain.com

Given that Google seems to treat web sites differently depending on the full URLs, it may be helpful to push visitors over to a single URL - either with or without the www. Here's a quick script that can be added to your Apache .htaccess file (if you don't have one, you can create one - if you have shell access, I strongly recommend doing it from the shell; the file will be at the top level of your public Web space, and may be invisible to your ftp program or shell since it starts with a period), thanks to expat from the excellent and useful DigitalPoint forums:

RewriteEngine on
Options +FollowSymLinks
RewriteCond %{HTTP_HOST} ^weborial\.com
RewriteRule ^(.*)$ http://www.weborial.com/$1 [R=permanent,L]

(In our experience, Options +FollowSymLinks is optional.)

You can also put this into your Apache configuration file, but modified a little so the last line becomes:

RewriteRule ^(.*)$ http://www.weborial.com$1 [R=permanent,L]

Use your domain name instead of weborial...

Quick and easy security script

With the script kiddies doing brute-force attempts at all sorts of logins, we decided it was imperative to block access to the server for anyone who tries to break in. However, we don't want to start losing people who are legitimate. So the following script, which only blocks tries to get in via SSH, is great:

http://scripts.nomadcf.com/info.php?program=log_watcher

We should note that we have taken many routine precautions, including shutting off telnet and FTP entirely, along with closing down SMB (Samba) and numerous other easy-to-break-into or insecure features.

Web stats software

We looked at three Web stats packages out there, all server-based and free, and here are our conclusions:

Webalizer is a great overall package; it works fairly quickly and provides excellent, useful charts and a good overview of traffic. It's also very easy to customize via the webalizer.conf file. We ended up using Webalizer because:
- It's very, very, very easy to install!
- It works quite quickly, not that the others are slow or anything
- The charts are easiest to read because you get individual graphs for visits, visitors, and hits
- Output is dumped into Excel-readable files (optional) and into easily accessible, static html pages (by default)
AWStats provides much more detail than Webalizer and has a nice "compress files when done" feature which can really save server time and space. The charts are not nearly as easy to read as Webalizer's; rather than providing separate charts for different aspects of traffic, everything is stuck into the same place. But the detail is definitely good to have and is a major improvement on Webalizer. We tried AWStats, but kept running into permissions and other issues, and the program isn't nearly as easy to deal with as Webalizer. In short, we strongly recommend it - but if you're in a hurry, Webalizer's a lot easier to set up.
Analog provides a lot of detail but seems to love pie charts and overall is the least useful of the three, though not bad on its own. Still, there's not much, if anything, to recommend it over Webalizer.

404_IGNORE_THIS_REQUEST statements in server logs

We've been seeing 404_IGNORE_THIS_REQUEST.html in the server logs for all of our sites, and suspect you have seen a few too. We do not know the origin of this, but they are coming from different originating IP addresses. Here are some theories:

Someone is conducting a mass survey of web sites to see what their missing-page-error behavior is (standard 404 message, custom page, etc.) Why? Who knows?
A cracker is collecting these to see which web sites have which software in a rather roundabout way. An automated 404 message may tell what system it is coming from.
There is a new cracker/script kiddie program which is doing this automatically for some probably-not-good reason.
Some other odd thing is happening.

My response has been to put pages with that name onto my sites, essentially just copies of the standard 404 error page (you do have one, right?). If it continues, I will make those pages as slow-loading as I can to protect others.

Useful commands

These are handy commands to know - these work on my Red Hat 9 system but since Linux distributions vary so much... by the way, I don't recommend using Red Hat 9 since it doesn't seem to play nice with MySQL. Use a newer version or use the current Fedora - or another system. (I stopped recommending Debian because the stable is so far behind, people end up just using unstable releases...!)

For these to work, you may have to put the word "sudo" in front, as in sudo apachectl graceful.

To get to the point where these work, you will need to open up a terminal window (if you actually work from your Web server) or, more often, an SSH or (not recommended!) Telnet window. (We don't recommend Telnet because passwords are sent in plain text. See our SSH/secure password page.) Once you've logged in, you can just type at the command line. (Note that in most systems, pressing the arrow up key will show you the last command entered - and you can keep doing it!)

First, let's try some start/restart items:

Command	What it does
apachectl graceful	Restarts apache gently. Useful mainly for applying changes to the configuration file (generally named apache.conf or httpd.conf). If this fails, try apachectl restart.
/etc/init.d/named restart	Restarts the BIND name server - if you've had a problem or added a new domain name. (There are other, more specific commands for changes to a single domain name.)
/usr/bin/safe_mysqld	Starts up MySQL if it stopped for some reason. Starts it in safe mode.
service sendmail start	or restart, or stop.
service mysql restart	Restarts MySQL if needed.
apachectl status	Provides details on Apache

Now, some other items:

Command	What it does
cat /proc/version	Tells you what version you're using
my isamchk -r [path to MySQL library]/*.MYI	Recovers really bad MySQL errors from a particular MySQL database. You have to enter the path to the MySQL library in the brackets. For me, this is (for example) myisamchk -r /var/lib/mysql/toy/*.MYI ... this is not to be used unless you've already tried other methods of fixing your tables! (e.g. phpmysqladmin)
update tablename set field = replace(field,'search_for_this','replace_with_this');	Search and replace syntax for MySQL (useful from eskewl or phpmysqladmin) - example: changing all time_offset values 0 to -5 within the ag_members table: `update ag_members set time_offset = replace(time_offset,'0','-5');`
chkrootkit / rkhunter	Install these and run them at least once a week to check for root-kit compromises (for security).

I just can't get the hang of vi or vim.

For heaven's sake, don't even try. Type nano at the command line and see if it comes up. You'll love it. If nano isn't available, try installing it OR try typing pico, which is a less featured word processor with fewer features. (But we really suggest that you install nano because you will want the additional features). Nano and pico have near-identical interfaces which are rather similar to ordinary word processors, rather than being UNIX holdovers. They are not as powerful as vi but the power they do have is easier to reach; options are shown at the bottom of the screen with their keyboard-command (control-whatever). As with vi, to open a particular file, you can type nano filename or you can open the file within nano.

Problem: Portsentry ERROR: could not bind UDP socket: 32773 showing up in the logs.

Solution: Some other service is using a socket that PortSentry wants to check up on, so PorteSentry is telling you it can't do it. The solution is first to check to make sure everything's all right on your server, no compromises or anything, using chkrootkit, last, and other methods; then configure PortSentry to stop checking that socket (using Webmin or something like that).

Problem: The log file is getting filled with errors about SV wanting to respawn too fast.

Solution: Go to /etc/inittab and comment out the line(s) starting with "SV" - in my case, I needed to remove both. SV is a supervisor program and probably not a virus or worm. Perhaps an expert will let us know why this happens?