Internet Scanner SAFEsuite™
 

If The System Is Compromised



Frequently Asked Questions (FAQ)

This FAQ contains suggestions for securing a UNIX machine after it has been compromised. Even if it has not been compromised, this FAQ provides many helpful tips for securing a machine.


Try to trace/follow the intruder back to his/her origin by looking at:

 Note: who, w, last, and lastcomm are commands that rely on /var/adm/pacct, /usr/adm/wtmp, and /etc/utmp to report the information. Some intrusion techniques will keep the intruder from being shown in these logs. With applications that are available on the Internet, it is trivial to remove any detection in these logs.
 

Install xinetd or tcp_wrapper, which logs all TCP connections to the machine, as defined by the administrator, that allow the administrator to detect potential intrusions. Forward syslogs to another machine so an intruder cannot easily detect and modify the logs. Other available applications: netlog from net.tamu.edu:/pub/security.

Consider... monitoring the intruder via an Ethernet sniffer (hardware or software implementation) to observe and review the execution of the exploit before taking corrective measures.

* Close the machine from outside access. To stop further access by the intruder, remove it from the network. If the intruder determines the administrator is privy to his/her presence, he/she may perform an rm -rf / in an attempt to destroy any evidence of his/her presence, perhaps even as an act of vengeance.
* Check the binaries against the originals. Especially, check the following binaries as they can be replaced and subsequently obtain access or re-obtain access:
Other potentials for being replaced:
netstat -- allows connections not to be detected

ps -- an potentially slow select processes to run undetected

ls -- allow files or file structures to be undetected

ifconfig -- is able to mask indications that the Ethernet interface is in a promiscuous mode
sum -- fools the checksum for binaries. It is not necessarily replaced anymore because one can change the checksum of the binaries to the correct value without modifying sum. Do NOT Rely on sum. Use ls -lac to determine the correct modification time of files. Check /etc/wtmp (if there still is one) for any system time adjustments. Check the files with the distribution media (CD or tape) or calculate MD5 checksums and compare them with the originals kept offline (Were they not calculated sometime ago?) Suggestion: compare (diff) the files with copies that are known to be good.
* Another popular intrusion method is adjusting the SUID of a common command (such as /bin/time) to allow super-user access with regular accounts. To find all suid programs consider using: find / -type f -perm -4000 -ls.
Important! To be thorough, consider reloading the entire operating system to restore the machine into a known or trusted configuration. Tripwire can prevent someone from modifying binaries and system files (such as inetd.conf) on the system, without the administrator ever knowing.
* Implement some password scheme for users to verify that passwords are changed often. Install anlpasswd, npasswd, or passwd+ in place of passwd (or yppasswd) so that users are forced to set reasonable passwords. Then run crack, which is available on ftp.cert.org:/pub/tools/crack which will ensure that the users choose non-trivial passwords. On any given network, clearing text passwords can pose a problem. Hence, a solution could be one-time password technology or point-to-point session encryption.

* Check all file structures for .rhosts and .forward and inspect their contents. If .rhosts file contains '+ +', the account can be accessed anywhere by anyone without a password. The .forward file, when possible, can be installed into the super-user’s directory in an effort to modify critical files that could be used to gain access. COPS has a script(s) for checking .rhosts. Use: find / -name .rhosts -ls -o -name .forward -ls.

* Also, examine all files created/modified in the timeframe for which the suspect the break-in took place. For example, use: find / -ctime -2 -ctime +1 -ls to find all the files modified not less than one day ago, but not more than 2 as the magnitude of information can become confusing and unwieldy.

* All .login, .logout, .profile, .cshrc files are also worth examining (at least for the modification date/time). Be sure there are no .rhosts for the locked or special accounts (like news, sundiag, sync, etc.) The shell for such accounts should be something like /bin/false anyway (and not /bin/sh) to make them more secure. Also search for directories that have values like ". ", ".. " as names. They are usually found in /tmp, /var/tmp, /usr/spool/* and any other publicly writable directory.

* Ensure the NFS exports are not world writable to everyone. NFSwatch available on harbor.ecn.purdue.edu:/pub/davy, a program by David Curry, will log any NFS transactions that are occurring. Try showmount -e to determine whether system agrees with what is being exporting and where. There are bugs in some nfsd implementations which ignore the access lists when they exceed some limit (such as 256 bytes). Also, check what is being IMPORTED!!! Use the nosuid flag whenever possible to avoid being cracked by a sysadm from another host (or a cracker there) running suid programs mounted via NFS.

* Ensure the newest version of sendmail is implemented. Old sendmail daemons allow remote execution of commands on any UNIX machine (see the computer-security/security-patch FAQ).

* Attempt to install all the security patches available from the vendor on a machine (see the computer-security/security-patch FAQ).

The following checklist outlines common ways that a machine is vulnerable:
* Do an rpcinfo -p on the machine to ensure it is not running any processes not required (such as rexd).

* Check for '+' in /etc/hosts.equiv.

* Check whether tftp is disabled on the system. If not, disable it; or at least use the -s flag to chroot it to some safe area if it must be used (mostly commonly used for booting up Xterminals, but sometimes can be avoided by NFS-mounting appropriate disks). Under no circumstances should it be run as super- user. Change the line describing it in /etc/inetd.conf similar to the following:

tftp dgram udp wait nobody /usr/etc/in.tftpd in.tftpd
-s /tftpboot
* Better yet, use the tcpd wrapper program to protect it from addresses that should not get access to tftp and to log all other connections:
tftp dgram udp wait nobody /usr/etc/tcpd in.tftpd
-s /tftpboot
* Appropriately edit /etc/hosts.allow to restrict access to in.tftpd to only those addresses that require it.

* Check crontabs and at-jobs. Ensure there are no delayed bombs which will explode after having discarded all the damaging effects an intruder leaves behind..

* Check /etc/rc.boot /etc/rc.local (SYSV: /etc/rc?.d/*) and other files crucial for the system startup. (It is best to compare them with the copies kept offline). Check all other files containing system configuration (sendmail.cf, sendmail.fc, hosts.allow, at.allow, at.deny, cron.allow, hosts, hosts.lpd, etc.) In aliases, look for aliases expanding to some unusual programs (uudecode is just one example).

* Check the inetd.conf and /etc/services files to determine whether there are any additional services set up by an intruder.

* Copy all the existing log files (pacct, wtmp, lastlog, sulog, syslog, authlog, and any additional logs that were set up earlier) to a secure place (offline) for later examination. Otherwise, do not be surprised if they disappear the next day when the cracker realizes he/she forgot to remove one of them. Be imaginative to ascertain what other traces he/she could have left in the system (What about /tmp/* files? Check them BEFORE rebooting).

* Produce a backup copy of /etc/passwd (best offline) and change all super-user passwords (after verifying that su and passwd are not the Trojan versions left by an intruder). It may sound like a formidable thing to do (especially, if there are approximately 2000 users or more) but do lock them all by placing '*' in the password field. If the intruder has copied the passwords file, he/she may possibly sooner or later guess all the passwords contained within (simply said, all passwords contained within can be guessed using a password cracking program). It is also possible that the intruder changed some account passwords. This is most likely to occur for account passwords that have been unused for a long duration of time.

* On the NIS servers check not only the real /etc/passwd, /etc/groups, etc files, but also those used for building NIS maps (if different).

* Verify that the anonymous FTP (and other services) are configured properly (see the computer-security/anonymous-ftp FAQ).

* Another method used for ousting an intruder intruder would be to install the ident daemon. Together with tcpd on a set of hosts, it can be used to find what accounts the intruder is using.

* Ensure the only 'secure' terminal is console (if at all). This prevents root logins only from the Internet. Perhaps it is insignificant, provided someone knows the super-user password; he/she may already know other peoples' passwords as well… and then again, maybe not!

* Check hosts.equiv, .rhosts, and hosts.lpd for having # as comments within those files. If an intruder changes his hostname to #, it is then considered to be a trusted host, thereby enabling him/her access to the machines.

*Remember, there are so many ways that an imposter can modified a system(s), that one must really be aware and alert to of any and all vulnerabilities.

Contact all sites that are known to be at risk. Also, contact the Computer Emergency Response Team at their Internet site: cert@cert.org. Check all the sites in the domain, institution, etc. It's usually trivial for a intruder to get to another system by a simple rlogin if the two systems have a common subset of users (and using .rhosts to make the access easier).

A preventive measure for stopping many intruders from even attempting to break-in to a network is to install a firewall.

Effects: Firewalls can be expensive and filtering often slows down a network. When using a firewall, consider blocking nfs(port 2049/udp) and portmap(111/udp) on the router. The authentication and access controls of these protocols is often minimal. Also, consider blocking all udp ports except DNS and NTP ports, killing all source routing packets, and killing all IP-forwarding packets.