Assignment

Please read chapter 2 of MF, pp. 93-120.

Unix/Linux, learning what is where

• Simple unifying concepts back most of the Unix/Linux world.
• Files as bytestreams
• Processes are simple reifications that have well-defined state.

What kind of state is available?

• Like Windows, (useful) state and caching of state generally are found in (1) memory and (2) file structured areas. In Unix/Linux, such file-structured areas can include raw disk drives, aggregations of disk space such as RAID (and RAID can either be hardware or software, or even a mix!), CD/DVD/Blue Ray, USB flash drives, and state is held remotely, such as by NFS or sshfs sessions.

Live system tool derived state

• The first category of state that we will look at is that of "Live system tool derived state", just as we did for Windows.
• How can we carry out these queries? Here we start running into forensics issues: just as with Windows, we should be leery of trusting the system to answer these questions. Whatever programs we use to extract such state from the system themselves should be considered carefully. For live forensics, popular approaches include running programs from some sort of removable media, such as a CD or a USB memory key.

"Shopping List" for volatile information

• What kind of information are we going to look at? Following Chapter our Windows work, let's put at least together a Unix/Linux "shopping list".

Date/time information

• Date/time information. We could use something like

  	    uptime
  	  

  or we could use the same perl code that we used for Windows!

  	    print "Local time " . localtime() . "\n";
  	    print "GM time " . gmtime() . "\n";
  	    #
  	    # Now try to query an NTP server and see how far off we are:
  	    #
  	    print "Attempt to contact ntp server ...\n";
  	    system("sntp.exe pool.ntp.org");  # sntp.pl is a simple ntp date/time
  	                                      # retrieval script from kloth.net 
  	    print "... ending ntp attempt\n";
  	    # 
  	  

  [Note, however, that we have just added networking state with the latter! It would probably be better to hold off on this step until we have profiled the networking state...]
• Reminder: you can find the sntp.exe script at http://www.kloth.net/software/sntp.php.

Memory acquisition

• As with Windows, it is a good idea to copy memory very early on — MF recommends on page 9 that you copy it immediately after you do a time check. Fortunately, with Unix/Linux, this is almost always easy to do: you can use the dd program to copy memory. MF also recommends the Coroner's Toolkit (TCT) program memdump on page 100. Also, as MF notes on the same page, grabbing a copy of the /proc/meminfo to get a layout of memory is a good idea.
• Also, there are many programs that can show you what processes are in the system: ps -alxwwww

System identification

In the Unix/Linux environment, you can use hostname, whoami, uname -a, and possibly cat /etc/SOMEFILE (SOMEFILE depending on the operating system &mdash for instance, in Redhat, it would be redhat-release. Another candidate is the previously mentioned uptime. MF suggests both tools from CTC and from Helix. You can also write a simple "profiler" in Perl to collect volatile information from the /proc pseudo-files. Also, you might want to just copy everything from the /etc/ and /usr/local directories — these are considered to embody the "personality" of a Linux/Unix system.

Who is using the system? Login sessions.

• w,who are two of the classics (but note that some of these classic programs do not show full usernames if the username is longer than 8 characters. You can copy off such information from files such as /var/log/
• You can also answer the question "who was using the system" with programs such as last.
• Of course, like Windows, these are only going to show proper user sessions; if "backdoors" have been set up or record files compromised, then such use won't show up in these tools.

Who is using the system? Open files.

• In the Unix/Linux world, we have the excellent lsof program to show exactly what files each process is using.

What else might be scheduled?

• The Unix/Linux world has used cron as its scheduler of preference for a long time. Look for a crond in the process table. Generally, cron files are stored in both /etc/ and in /var/spool/cron.

NFS and sshfs

• Remote state can be mounted from other servers using NFS and sshfs. While you can widely access NFS state when doing an investigation as "root", unless you have a password or private ssh key, you won't be able to easily access remote sshfs information.

Network connectivity

• Like Windows, one of the most useful tools is netstat -ano which will let you see which PID created a connection.
• Don't forget grab a copy of the ARP table; like Windows, you can use arp -a to do this. Remember, the ARP table provides the mappings from IP numbers to MAC addresses, and malefactors.
• Also, try a portscan with nmap. As with Windows, this can help avoid the problems of using internal structures that might be manipulated or obscured by malware by looking at an "outward" view.

Keyboard history

• In the Unix/Linux world, it is far more likely that a malefactor will use a command shell. You can look for files such as .bash_history to find a history of bash commands.