.
This is a page of tidbits regarding Linux/UNIX server security.
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.
We recommend the following scripts:
First, denyhosts, which does exactly what it should - watching your security log and denying IP addresses any access to port 22 (SSH) to anyone who seems to be trying to break in. It is easy to configure, so you can set it up as a very quick shut-down system - as little as a single bad try at the root password can knock out an evildoer's access to your server's command line, while still providing port 80 (Web site) access. This is great especially if you want people in India, China, and Russia to see your Web pages! Not only does denyhosts provide a great deal of configurability, which is relatively easy to understand, but it also provides understandable documentation (now, how often do we get that?) and can run as a command-line program, as a cron job, or as a daemon. As a daemon, the best way to run it, it checks your logs every thirty seconds, quickly eliminating brute-force hacking attempts. This program installed quickly and easily and worked exactly as advertised. It does, however, require Python, which most servers have.
If you don't have Python, you can try LogWatcher, which we found to be less successful and flexible. It also only blocks those who try to get in via SSH.
We should note that we have taken many routine precautions, including shutting off telnet and FTP entirely (and removing all FTP software), along with closing down SMB (Samba) and numerous other easy-to-break-into or insecure features.
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:
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.
Check for even subtle intrusions by installing chkrootkit and rkhunter (root-kit hunter) and running them at least once a week. They can be set up as cron jobs. Remember to check for updates periodically!
Addition: we recently ran across a third root kit detector, RootCheck, which checks some things the others do not (each has its own strengths and weaknesses, but RootCheck actually looks at permissions, Apache configuration, shell access given to standard users such as mailman and MySQL, and more!). Install it with these commands:
Root kit detectors tend to generate false positives with the combination of Tomcat and Macromedia Publishing System.
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).
Backups aren't just for desktops, nor should they be entrusted entirely to your service provider. We strongly suggest backing up your server's key files regularly, onto another machine - including any databases, configuration files, and other changing material! See our main backups page.