Section 19.13 Sealing the Crack | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

19.13 Sealing the Crack

Now that you have determined what the cracker has added, removed, and changed, you can undo these to repair the damage using your backups or the installation CD-ROMs. Again, first you need to disable any programs that the cracker altered so that you do not accidentally invoke them and add more holes.

After studying the diffs and added files, you need to decide which files to restore. In the previous example, several programs in /bin, several device files in /dev, and a library file were altered. Recall that your current working directory is /mnt2. The following commands will restore the system:

 /bin/rm -f \    bin/date bin/ls bin/su dev/hdb7 \    dev/null dev/tty lib/libc.so.6 /bin/tar -xf /dev/rmt0 \    bin/date bin/ls bin/su dev/hdb7 \    dev/null dev/tty lib/libc.so.6

Another tar -d and find sequence might be worthwhile to ensure that nothing was missed. Following this, remove the floppy, do a normal reboot, and you will be back in business.

19.13.1 The Trail of Compromised Data

What about confidential data? Unless you can prove otherwise, you must assume that a cracker saw, recorded, and altered all confidential data that his level of breach allowed access to. If he obtained root access, that means everything. Clearly, passwords must be changed and the previous ones never used again. Each of your users also must be warned that if his password also was used on other systems, the other systems also need the password changed. You also must investigate these other systems on the possibility that they were also broken into, using the compromised passwords or other data compromised from the original system.

Back in my student days at Berkeley, an early and experimental UNIX networking facility, that was the forerunner of rsh, required the remote system's password to be stored in clear text. Yup. Someone broke into one of the Computer Center's UNIX systems and I had to assume that this password was compromised. Even though it was the one that Ken Thompson could not crack and it was easy to remember, I do not use it to this day!

You must assume that any other data was compromised and take appropriate action. This includes any customer and vendor data, such as credit card numbers. A variety of techniques can make use of this information to commit theft. This one is common and relies on the criminal having enough information to convince the victim that he is who he says he is. "Hi. I'm from Pentacorp and we accidentally deleted our copy of your credit card number on your order of September 29 for 100 widgets to be shipped to you at 123 Maple Street. If you can give it to me now, we can ship today." Even though you protect customer credit card numbers as discussed in "One-Way Credit Card Data Path for Top Security" on page 302, this thief got the data anyway and applied charges to your customer's card.

A failure to notify has liability implications. Publicity has other implications. It is best to have an approved written plan prior to the breach, because you will want to act quickly and do not want to risk being the scapegoat by getting accused of taking the wrong action in the heat of battle.

Top