What to do if Attacked

If you believe your computer is under attack as you watch, you have two choices:

If you believe the intruder is actually destroying irreplaceable data, to reboot or power-down the machine. It may be quicker to type killall -KILL rm, and in any case it's pretty unlikely the intruder is this malicious. If not, it's probably too late anyway. If your operating system has a crash dump analyzer, you should first dump the system memory.

To obtain maximum information about the attack, you should disconnect the machine from the network and do a live audit. With the network disconnected (Ethernet unplugged) an intruder cannot control his tools or interfere with your work.

Live Security Audit

The idea is to discover what the intruder is doing on your system. Various system tools may be used, for example:

netstat > netstat.log - show active network connections
ps -elxfwwww > ps.log - show running processes
strings /dev/kmem > kmem.log - look for text strings in system memory
ifstatus, ifconfig, netstat -ai (?) - check for promiscuous mode

Note: there's a good chance that an intruder has replaced some of your binaries such as ls, ps etc. with modified versions. If in doubt (checksums or timestamps don't match) use clean copies

In Linux, the proc filesystem may yield useful information. For example, suppose you see

$ ps -ux
root     10454  0.8  0.2  1884   720  ?  S   09:01   0:26 pine

and you don't think this is legitimate, you can say

$ ( cd /proc/10454/cwd ; pwd )

and maybe see something like

/home/joehacker/Mail

You may also use e.g.

$ ls -l /proc/10454/exe
lrwx------   1 root     root           64 Oct 29 09:53 exe -> [0813]:10334

and then

$ find / -inum 10334
/home/joehacker/Mail/pine

Once the maximum live information has been obtained, the system may be rebooted and the filesystem audited. The system should first be backed up to tape to preserve a record of the attack. The audit should include a check of installed system binaries against distribution media, or checksum verification, plus a search for hidden files, tools, logs etc. left by the intruder, plus any modifications made to files such as user's .rhosts files, plus configuration files typically in /etc such as passwd, inetd.conf, hosts.allow, rhosts, hosts, resolv.conf and so on. If checksums of these files are logged on a regular basis it greatly aids the discovery process. The find tool may be used to search for files and directories that have been changed; suppose an attack took place yesterday; you can use e.g.

# find /  -mtime -4 -mtime +1 -exec ls -ld {} \; | less
# find /  -ctime -4 -ctime +1 -exec ls -ldc {} \; | less

to locate files modified (inode modified) in the last four days, excluding today. Note that intruders may install files whose modification dates are older, but the directory where they are installed will show up in this time frame. Often, a disparate modification time on a program such as /bin/login compared with others in the same directory indicates a trojan horse.

All system logs, mail, ftp and webserver logs, etc. should be analyzed for traces of the intruder. They may have performed some legitimate access first such as contacting a webserver or mail daemon, which may have given them information about the system.

When the maximum offline information has been obtained, it may be prudent to reinstall the system from a clean distribution.

Contacting Other Sites

IP numbers may be looked up using whois, as follows:

Americas	whois nnn.nnn.nnn.nnn@whois.arin.net
Europe	whois nnn.nnn.nnn.nnn@whois.ripe.net
Asia	whois nnn.nnn.nnn.nnn@whois.apnic.net
US Military	whois nnn.nnn.nnn.nnn@whois.nic.mil
US Government	whois nnn.nnn.nnn.nnn@whois.nic.gov

which will usually give the ownership of a specific network block.

One may consider reporting an intrusion attempt to a network administrator of the remote site. One should take care not to report the attempt to the intruder themselves, e.g. "root" on the originating machine. In the case of a small concern with only a few hosts, this may be difficult. One should also not assume that the domain you observe the attack coming from is actually responsible - abusive messages to the technical contact may be counterproductive. Some sites may wish to receive details in encrypted form, e.g. with PGP.

Up to Security Page

A.Daviel