Wednesday, August 24, 2011

Debian GNU/Linux Postfix Server Incident - p'owned?

Reason to believe a server was compromised and it's a physical Debian GNU/Linux mail server in a production environment?  ..Sounds like fun!

Below is a short list of items to consider when responding to a incident. This is from a technical perspective and by no means a work plan for a comprehensive investigation.

If you haven't already, try to get a physical or logical image of the device. If the server can't be turned off to acquire physically, consider acquiring the logical partitions live:

1.    Attach USB
2.    mkdir /m1
3.    mount /dev/sdb1 /m1 # Substitute /dev/sdb1 for your USB device’s partition, fdisk –l helps
4.    dd if=/dev/sda1 of=/m1/my_image.img # this cmd is very basic and will dd the partition to the USB disk. If it uses logical volume manager, copy the logical partition as reconstructing the raid/lvm later could be an issue.

Identify all logs that could contain potential evidence related to the intrusion. Logs are going to be one of the key points of analysis in Linux based investigations. To that point, don't forget to inquiry about log retention polices and procedures during your scoping. For instance, are logs from the target server collected using a SIM, backed up to tape, or maybe logging is not even enabled? A good analogy is, make sure to account for ("or eat") all the crumbs that may be surrounding the cookie.

Here is a short list:

1.    /var/log/secure
2.    /var/log/secure.*
3.    /var/log/messages
4.    /var/log/messages.*
5.    /var/log/wtmp
6.    /var/log/wtmp.*
7.    /var/log/btmp
8.    /var/log/btmp.*
9.    /var/log/mail.log
10.    /var/log/mail.log.*
11.    /var/log/apache
12.    /var/log/auth.log
13.    /var/spool/
14.    Check syslog configuration (/etc/syslog.conf typically) and see if additional log files are stored
15.    If the machine is behind a firewall, check firewall (machine/appliance)logs.