2015-08 Snort 2.9.6.0, Network Miner 1.5, Autopsy
Installing Snort
Snort is an open source intrusion detection system available for most major platforms. It can generate alerts when it sees traffic patterns that match its list of signatures. A sequence of malicious traffic that does not match any existing signature will not generate an alert (false negative), while it can also be the case that perfectly legitimate traffic may match a signature and be flagged as malicious (false positive).
Snort generates alerts only for traffic that it collects, so when deploying a snort sensor it is important to know what traffic it will see. In our laboratory class environment, note that VMWare internally uses essentially a hub for network traffic; thus a virtual machine running Snort will see all of the traffic directed to/from either the host or any of the guests running on that physical host.
In these notes, we will install the current version of Snort on our CentOS 6.2 x64 machines. Though this machine is being designed primarily as a sensor, it is possible to install Snort on machines dedicated to other tasks. We also note that Snort can be installed on Windows systems. The installation process is somewhat different, but the configuration is the same.
After seeing the difficulties we had with SELinux on our web server, we start by setting SELinux to permissive mode. You probably don’t want to do this on a production system, but this will greatly simplify our installation process. Remember, to so this we edit /etc/selinux/config and making the necessary changes. These changes will take effect only on the next reboot. To make the temporary but immediate change, simply run
[root@hermes~]# echo 0 >/selinux/enforce
Before we can install snort, we will need a few packages that we did not install as part of the default image for class. Umm, more than just a few actually, and it looks like I made a teensy error earlier in the semester.
The first group of packages we want to install are needed for Snort to compile, they include gcc-c++ flex bison pcre-devel zlib-devel libpcap-devel automake and libtool. All of these (except for libpcap-devel) are on the first install DVD, so all we need to to is run
[root@hydra~]# yum --disablerepo=\* --enablerepo=c6-media install gcc-c++ flex bison pcre-devel zlib-devel automake libtool
There is one catch though. At some point when I was working with the virtual machines and before I put them on the lab share, I updated the version of gcc to 4.4.7 from 4.4.6. It was not intentional, but there you have it. If you try to run this command on the original base image on the labshare, it will fail. I have put an updated version of the CentOS 6.2 image on the labshare which will work.
I also want to add a few packages to enable database support and SSL support for Snort
[root@hydra ~]# yum --disablerepo=\* --enablerepo=c6-media install mysql mysql-devel postgresql postgresql-devel openssl-devel
There is one more required package, but it lives on the second install DVD, so change discs and run
[root@hydra ~]# yum --disablerepo=\* --enablerepo=c6-media install libpcap-devel
to get it set up.
Next we need a few tools that are not part of the standard install. First up is libdnet (1.12). The source code is available either from the labshare or online. Copy it to a convenient directory (say /usr/local/src), then configure, compile, and install the tool in the usual fashion:
[root@hydra ~]# cd /usr/local/src/ [root@hydra src]# tar -xzvf /home/zathras/Desktop/libdnet-1.12.tgz [root@hydra src]# cd /usr/local/src/libdnet-1.12/ [root@hydra libdnet-1.12]# ./configure [root@hydra libdnet-1.12]# make [root@hydra libdnet-1.12]# make install
where the output has been omitted for the sake of brevity.
We repeat this with daq (2.0.2). It is available on the labshare and online.
[root@hydra ~]# cd /usr/local/src/ [root@hydra src]# tar -xzvf /home/zathras/Desktop/daq-2.0.2.tar.gz [root@hydra src]# cd daq-2.0.2/ [root@hydra daq-2.0.2]# ./configure [root@hydra daq-2.0.2]# make [root@hydra daq-2.0.2]# make install
Finally, grab snort itself (2.9.6.0) either from the labshare or online. Lather, Rinse, Repeat.
[root@hydra daq-2.0.2]# cd /usr/local/src/ [root@hydra src]# tar -xzvf /home/zathras/Desktop/snort-2.9.6.0.tar.gz [root@hydra src]# cd snort-2.9.6.0/ [root@hydra snort-2.9.6.0]# ./configure [root@hydra snort-2.9.6.0]# make [root@hydra snort-2.9.6.0]# make install
Basic testing
To check that snort is running, let it simply sniff packets and print the TCP/IP headers to the screen:
[root@hydra ~]# snort -v
Running in packet dump mode
--== Initializing Snort ==--
Initializing Output Plugins!
pcap DAQ configured to passive.
Acquiring network traffic from "eth0".
Decoding Ethernet
--== Initialization Complete ==--
,,_ -*> Snort! ff02::c:1900
UDP TTL:1 TOS:0x0 ID:0 IpLen:40 DgmLen:194
Len: 146
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:18:55.034625 fe80::91c5:feb9:74b2:e536:56704 -> ff02::1:3:5355
UDP TTL:1 TOS:0x0 ID:0 IpLen:40 DgmLen:74
Len: 26
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:18:55.034652 10.0.2.2:49900 -> 224.0.0.252:5355
UDP TTL:1 TOS:0x0 ID:1927 IpLen:20 DgmLen:54
Len: 26
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:18:55.234659 10.0.2.2:137 -> 10.0.255.255:137
UDP TTL:128 TOS:0x0 ID:1928 IpLen:20 DgmLen:78
Len: 50
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:18:55.336612 fe80::91c5:feb9:74b2:e536:54035 -> ff02::1:3:5355
UDP TTL:1 TOS:0x0 ID:0 IpLen:40 DgmLen:74
Len: 26
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:18:55.336633 10.0.2.2:55962 -> 224.0.0.252:5355
UDP TTL:1 TOS:0x0 ID:1929 IpLen:20 DgmLen:54
Len: 26
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:18:55.984395 10.0.2.2:137 -> 10.0.255.255:137
UDP TTL:128 TOS:0x0 ID:1930 IpLen:20 DgmLen:78
Len: 50
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:18:56.734469 10.0.2.2:137 -> 10.0.255.255:137
UDP TTL:128 TOS:0x0 ID:1931 IpLen:20 DgmLen:78
Len: 50
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:18:57.680666 fe80::91c5:feb9:74b2:e536:65320 -> ff02::c:1900
UDP TTL:1 TOS:0x0 ID:0 IpLen:40 DgmLen:194
Len: 146
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
^C*** Caught Int-Signal
===============================================================================
Run time for packet processing was 6.162485 seconds
Snort processed 9 packets.
Snort ran for 0 days 0 hours 0 minutes 6 seconds
Pkts/sec: 1
===============================================================================
Memory usage summary:
Total non-mmapped bytes (arena): 925696
Bytes in mapped regions (hblkhd): 12640256
Total allocated space (uordblks): 671120
Total free space (fordblks): 254576
Topmost releasable block (keepcost): 250960
===============================================================================
Packet I/O Totals:
Received: 9
Analyzed: 9 (100.000%)
Dropped: 0 ( 0.000%)
Filtered: 0 ( 0.000%)
Outstanding: 0 ( 0.000%)
Injected: 0
===============================================================================
Breakdown by protocol (includes rebuilt packets):
Eth: 9 (100.000%)
VLAN: 0 ( 0.000%)
IP4: 5 ( 55.556%)
Frag: 0 ( 0.000%)
ICMP: 0 ( 0.000%)
UDP: 5 ( 55.556%)
TCP: 0 ( 0.000%)
IP6: 4 ( 44.444%)
IP6 Ext: 4 ( 44.444%)
IP6 Opts: 0 ( 0.000%)
Frag6: 0 ( 0.000%)
ICMP6: 0 ( 0.000%)
UDP6: 4 ( 44.444%)
TCP6: 0 ( 0.000%)
Teredo: 0 ( 0.000%)
ICMP-IP: 0 ( 0.000%)
IP4/IP4: 0 ( 0.000%)
IP4/IP6: 0 ( 0.000%)
IP6/IP4: 0 ( 0.000%)
IP6/IP6: 0 ( 0.000%)
GRE: 0 ( 0.000%)
GRE Eth: 0 ( 0.000%)
GRE VLAN: 0 ( 0.000%)
GRE IP4: 0 ( 0.000%)
GRE IP6: 0 ( 0.000%)
GRE IP6 Ext: 0 ( 0.000%)
GRE PPTP: 0 ( 0.000%)
GRE ARP: 0 ( 0.000%)
GRE IPX: 0 ( 0.000%)
GRE Loop: 0 ( 0.000%)
MPLS: 0 ( 0.000%)
ARP: 0 ( 0.000%)
IPX: 0 ( 0.000%)
Eth Loop: 0 ( 0.000%)
Eth Disc: 0 ( 0.000%)
IP4 Disc: 0 ( 0.000%)
IP6 Disc: 0 ( 0.000%)
TCP Disc: 0 ( 0.000%)
UDP Disc: 0 ( 0.000%)
ICMP Disc: 0 ( 0.000%)
All Discard: 0 ( 0.000%)
Other: 0 ( 0.000%)
Bad Chk Sum: 0 ( 0.000%)
Bad TTL: 0 ( 0.000%)
S5 G 1: 0 ( 0.000%)
S5 G 2: 0 ( 0.000%)
Total: 9
===============================================================================
Snort exiting
From this listing, you can see that snort picked up some UDP traffic, a mix of UDP and UDP over IP v6. If you are really good, you recognize what you see as Simple Service Discovery [from the multicast IP address ff02::c port 1900], Multicast name resolution [from the multicast addresses 224.0.0.252 and ff02::1:3 port 5355] and some NetBIOS broadcast packets [from the broadcast address 10.0.255.255 port 137]. This snort run was ended with a control-C.
To print the application data, try
[root@hydra ~]# snort -vd
Running in packet dump mode
--== Initializing Snort ==--
Initializing Output Plugins!
pcap DAQ configured to passive.
Acquiring network traffic from "eth0".
Decoding Ethernet
--== Initialization Complete ==--
,,_ -*> Snort! ff02::c:1900
UDP TTL:1 TOS:0x0 ID:0 IpLen:40 DgmLen:194
Len: 146
4D 2D 53 45 41 52 43 48 20 2A 20 48 54 54 50 2F M-SEARCH * HTTP/
31 2E 31 0D 0A 48 6F 73 74 3A 5B 46 46 30 32 3A 1.1..Host:[FF02:
3A 43 5D 3A 31 39 30 30 0D 0A 53 54 3A 75 72 6E :C]:1900..ST:urn
3A 4D 69 63 72 6F 73 6F 66 74 20 57 69 6E 64 6F :Microsoft Windo
77 73 20 50 65 65 72 20 4E 61 6D 65 20 52 65 73 ws Peer Name Res
6F 6C 75 74 69 6F 6E 20 50 72 6F 74 6F 63 6F 6C olution Protocol
3A 20 56 34 3A 49 50 56 36 3A 4C 69 6E 6B 4C 6F : V4:IPV6:LinkLo
63 61 6C 0D 0A 4D 61 6E 3A 22 73 73 64 70 3A 64 cal..Man:"ssdp:d
69 73 63 6F 76 65 72 22 0D 0A 4D 58 3A 33 0D 0A iscover"..MX:3..
0D 0A ..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:34:44.423125 10.0.2.18:37437 -> 10.0.2.100:53
UDP TTL:64 TOS:0x0 ID:41853 IpLen:20 DgmLen:61
Len: 33
DF D6 01 00 00 01 00 00 00 00 00 00 07 61 63 68 .............ach
65 72 6F 6E 04 63 6F 73 63 02 74 75 00 00 01 00 eron.cosc.tu....
01 .
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:34:44.423422 10.0.2.100:53 -> 10.0.2.18:37437
UDP TTL:64 TOS:0x0 ID:43375 IpLen:20 DgmLen:130
Len: 102
DF D6 85 80 00 01 00 01 00 02 00 01 07 61 63 68 .............ach
65 72 6F 6E 04 63 6F 73 63 02 74 75 00 00 01 00 eron.cosc.tu....
01 C0 0C 00 01 00 01 00 00 01 2C 00 04 0A 00 02 ..........,.....
64 C0 14 00 02 00 01 00 00 01 2C 00 02 C0 0C C0 d.........,.....
14 00 02 00 01 00 00 01 2C 00 0B 08 64 61 6D 6F ........,...damo
63 6C 65 73 C0 14 C0 4B 00 01 00 01 00 00 01 2C cles...K.......,
00 04 0A 00 02 65 .....e
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:34:46.472627 10.0.2.2:17500 -> 10.0.255.255:17500
UDP TTL:128 TOS:0x0 ID:2207 IpLen:20 DgmLen:209
Len: 181
7B 22 68 6F 73 74 5F 69 6E 74 22 3A 20 31 30 35 {"host_int": 105
36 37 32 31 32 37 35 2C 20 22 76 65 72 73 69 6F 6721275, "versio
6E 22 3A 20 5B 31 2C 20 38 5D 2C 20 22 64 69 73 n": [1, 8], "dis
70 6C 61 79 6E 61 6D 65 22 3A 20 22 22 2C 20 22 playname": "", "
70 6F 72 74 22 3A 20 31 37 35 30 30 2C 20 22 6E port": 17500, "n
61 6D 65 73 70 61 63 65 73 22 3A 20 5B 32 34 36 amespaces": [246
31 32 32 35 36 30 2C 20 32 34 33 32 32 39 37 39 122560, 24322979
34 2C 20 34 35 37 39 35 34 35 37 32 2C 20 31 34 4, 457954572, 14
36 32 32 32 38 35 39 2C 20 32 39 31 31 36 35 31 6222859, 2911651
33 32 2C 20 33 31 37 35 36 38 39 37 33 2C 20 33 32, 317568973, 3
31 31 39 37 35 35 33 39 2C 20 33 33 36 36 38 35 11975539, 336685
31 34 33 5D 7D 143]}
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/23-08:34:47.711629 fe80::91c5:feb9:74b2:e536:65320 -> ff02::c:1900
UDP TTL:1 TOS:0x0 ID:0 IpLen:40 DgmLen:194
Len: 146
4D 2D 53 45 41 52 43 48 20 2A 20 48 54 54 50 2F M-SEARCH * HTTP/
31 2E 31 0D 0A 48 6F 73 74 3A 5B 46 46 30 32 3A 1.1..Host:[FF02:
3A 43 5D 3A 31 39 30 30 0D 0A 53 54 3A 75 72 6E :C]:1900..ST:urn
3A 4D 69 63 72 6F 73 6F 66 74 20 57 69 6E 64 6F :Microsoft Windo
77 73 20 50 65 65 72 20 4E 61 6D 65 20 52 65 73 ws Peer Name Res
6F 6C 75 74 69 6F 6E 20 50 72 6F 74 6F 63 6F 6C olution Protocol
3A 20 56 34 3A 49 50 56 36 3A 4C 69 6E 6B 4C 6F : V4:IPV6:LinkLo
63 61 6C 0D 0A 4D 61 6E 3A 22 73 73 64 70 3A 64 cal..Man:"ssdp:d
69 73 63 6F 76 65 72 22 0D 0A 4D 58 3A 33 0D 0A iscover"..MX:3..
0D 0A ..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
^C*** Caught Int-Signal
===============================================================================
Run time for packet processing was 6.569467 seconds
Snort processed 5 packets.
Snort ran for 0 days 0 hours 0 minutes 6 seconds
Pkts/sec: 0
===============================================================================
Memory usage summary:
Total non-mmapped bytes (arena): 925696
Bytes in mapped regions (hblkhd): 12914688
Total allocated space (uordblks): 671120
Total free space (fordblks): 254576
Topmost releasable block (keepcost): 250960
===============================================================================
Packet I/O Totals:
Received: 5
Analyzed: 5 (100.000%)
Dropped: 0 ( 0.000%)
Filtered: 0 ( 0.000%)
Outstanding: 0 ( 0.000%)
Injected: 0
===============================================================================
Breakdown by protocol (includes rebuilt packets):
Eth: 5 (100.000%)
VLAN: 0 ( 0.000%)
IP4: 3 ( 60.000%)
Frag: 0 ( 0.000%)
ICMP: 0 ( 0.000%)
UDP: 3 ( 60.000%)
TCP: 0 ( 0.000%)
IP6: 2 ( 40.000%)
IP6 Ext: 2 ( 40.000%)
IP6 Opts: 0 ( 0.000%)
Frag6: 0 ( 0.000%)
ICMP6: 0 ( 0.000%)
UDP6: 2 ( 40.000%)
TCP6: 0 ( 0.000%)
Teredo: 0 ( 0.000%)
ICMP-IP: 0 ( 0.000%)
IP4/IP4: 0 ( 0.000%)
IP4/IP6: 0 ( 0.000%)
IP6/IP4: 0 ( 0.000%)
IP6/IP6: 0 ( 0.000%)
GRE: 0 ( 0.000%)
GRE Eth: 0 ( 0.000%)
GRE VLAN: 0 ( 0.000%)
GRE IP4: 0 ( 0.000%)
GRE IP6: 0 ( 0.000%)
GRE IP6 Ext: 0 ( 0.000%)
GRE PPTP: 0 ( 0.000%)
GRE ARP: 0 ( 0.000%)
GRE IPX: 0 ( 0.000%)
GRE Loop: 0 ( 0.000%)
MPLS: 0 ( 0.000%)
ARP: 0 ( 0.000%)
IPX: 0 ( 0.000%)
Eth Loop: 0 ( 0.000%)
Eth Disc: 0 ( 0.000%)
IP4 Disc: 0 ( 0.000%)
IP6 Disc: 0 ( 0.000%)
TCP Disc: 0 ( 0.000%)
UDP Disc: 0 ( 0.000%)
ICMP Disc: 0 ( 0.000%)
All Discard: 0 ( 0.000%)
Other: 0 ( 0.000%)
Bad Chk Sum: 1 ( 20.000%)
Bad TTL: 0 ( 0.000%)
S5 G 1: 0 ( 0.000%)
S5 G 2: 0 ( 0.000%)
Total: 5
===============================================================================
Snort exiting
Here we see seven packets fly by; we recognize most of them as a standard DNS query. You can also see a DropBox broadcast packet looking for other local DropBox servers. Yep- I use DropBox.
To print even more information, try
[root@hydra ~]# snort -vde
Rather than printing the data to the screen, we can log the packets as they go by. Create a directory named log in the current directory and run instead
[root@hydra ~]# snort -dev -l ./log/
You can, of course, replace the name of the directory with any other name; you can specify the directory name absolutely or relatively (as we have done).
Let snort run for a while, then stop it. The resulting file in the log directory is not a text file, but rather is a packet dump. This can then be opened in e.g. Wireshark to view the traffic. Would this be a better approach to logging packet data during an exercise? Why or why not?
For a complete list of command line switches and their significance, see /usr/local/share/doc/snort/README
Set up the IDS Environment
We want to do more than simply run snort as a command line packet sniffer; we want snort to run as a service under its own user. First we set up the directories we will use to hold the configuration files and the log files:
[root@hydra ~]# mkdir /etc/snort [root@hydra ~]# mkdir /var/log/snort [root@hydra ~]# touch /var/log/snort/alert
Create a user and group to run our service; we are sure to create these as system accounts (-r) that do not allow the account to log in (-s /sbin/nologin)
[root@hydra ~]# groupadd snort [root@hydra ~]# useradd -r -g snort -s /sbin/nologin snort
Verify that the user and group is correctly created by checking /etc/group, /etc/passwd, and /etc/shadow.
Set the permissions on the log directories & files
[root@hydra ~]# chown snort:snort /var/log/snort/ [root@hydra ~]# chown snort:snort /var/log/snort/alert [root@hydra ~]# chmod 600 /var/log/snort/alert
Rule Installation
Before we can use snort as an intrusion detection system, we need to install an appropriate rule set. Snort provides two sets of rules, one is for paid subscribers the second for registered users. The rule set for registered users is a 30-day delayed feed of the rules provided to subscribers. Snort rules are provided under a license that prohibits their commercial re-use; see https://www.snort.org/vrt/license-agreement/ for the complete details.
Grab the rules set, and drop it in the /etc/snort directory created earlier
[root@hydra ~]# tar -xzvf /home/zathras/Desktop/snortrules-snapshot-2960.tar.gz -C /etc/snort/
The contents of the /etc/snort/etc directory need to be moved into /etc/snort.
[root@hydra ~]# cp /etc/snort/etc/* /etc/snort/
Many of the rules in snort are provided in a plan text format- this makes them easy to read and modify. However, some rules are provided as precompiled shared objects (.so files). We need to move these files to the location the snort binary wants to find them.
[root@hydra ~]# mkdir /usr/local/lib/snort_dynamicrules [root@hydra ~]# cp /etc/snort/so_rules/precompiled/RHEL-6-0/x86-64/2.9.6.0/*.so /usr/local/lib/snort_dynamicrules/ [root@hydra ~]# cat /etc/snort/so_rules/*.rules >> /etc/snort/rules/so-rules.rules
Starting Snort as an Intrusion Detection System
All of these settings may look to be a bit of a mystery, but now that we are ready to start configuring the system, all will become a bit clearer. Start by taking a look at the configuration file /etc/snort/snort.conf. If you jump down to lines 104-106, you will see where snort tries to load its rules files; let’s give snort the choices we made:
var RULE_PATH /etc/snort/rules var SO_RULE_PATH /etc/snort/so_rules var PREPROC_RULE_PATH /etc/snort/preproc_rules
This is why we earlier added a number of rules to the file /etc/snort/rules/so-rules.rules
Further, if you are wondering why we built the directory /usr/local/lib/snort_dynamicrules and added some rules there, take a look at line 249 of the configuration file.
# path to dynamic rules libraries dynamicdetection directory /usr/local/lib/snort_dynamicrules
Before we can start snort though, a few more changes need to be made. The default snort.conf file uses a reputation preprocessor that requires additional rules for its use. Since we are still testing the install, comment out lines 502-507 that relate to this preprocessor:
# Reputation preprocessor. For more information see README.reputation #preprocessor reputation: \ # memcap 500, \ # priority whitelist, \ # nested_ip inner, \ # whitelist $WHITE_LIST_PATH/white_list.rules, \ # blacklist $BLACK_LIST_PATH/black_list.rules
Verify that your installation is correct so far by running
[root@hydra ~]# snort -c /etc/snort/snort.conf
You will see quite a lot of output, but it should all start without throwing any errors. [Warnings, well, that’s a different matter.]
At this point, we know it is running, but we don’t know if it is working. Next, we create a simple rule that will fire off whenever we visit a web page; this way we can be sure that snort is reading our data correctly.
Open the file /etc/snort/rules/local.rules in a text editor, and add the following line:
alert tcp any any <> any 80 (msg: "Web Testing Rule"; sid:1000001; rev:1)
This tells snort to fire off an alert on any TCP packet from any IP and any source port sent to any IP with destination port 80; if it sees such a packet it should include the message "Web Testing Rule", it will refer to this rule through its ID, namely 1000001 which is in the range for user generated rules.
We need to restart snort for the rule changes to take effect, so kill your running snort process and start it again as above. Then visiting a web page like Google will start to fill up /var/log/snort/alert with messages like
[**] [1:1000001:0] Web Testing Rule [**] [Priority: 0] 03/23-09:30:54.583952 10.0.2.100:33751 -> 74.125.225.145:80 TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:40 DF ***A**** Seq: 0xA7A871E5 Ack: 0x78D0B94 Win: 0x3FAE TcpLen: 20
This alert should fire when any virtual machine on this host visits a web page; in particular you should test your configuration by visiting a web page with a guest that is different from your intrusion detection system to be sure it is catching all of the needed data.
Now we want snort to run as a service, so we copy the startup script from the installation directory to /etc/init.d and give it the right permissions:
[root@hydra ~]# cp /usr/local/src/snort-2.9.6.0/rpm/snortd /etc/init.d/ [root@hydra ~]# chmod a+x /etc/init.d/snortd
That script looks for snort in /usr/sbin/snort (take a look at the script, say around line 106), so lets provide the necessary link:
[root@hydra ~]# ln -s /usr/local/bin/snort /usr/sbin/snort
Next, we copy over the configuration file from the installation directory to /etc/sysconfig
[root@hydra ~]# cp /usr/local/src/snort-2.9.6.0/rpm/snort.sysconfig /etc/sysconfig/snort
If you take a look at that file, you will see that it specifies a number of things, like the user name and group name snort will run under, the location of the configuration file snort.conf as well as the location of the log directory. This is why we set those variables the way we did earlier during the install process.
Finally, we manually set up snort to start automatically (in modes 3 and 5) and to shutdown cleanly (in modes 0 and 6):
[root@hydra ~]# ln -s /etc/init.d/snortd /etc/rc3.d/S99snortd [root@hydra ~]# ln -s /etc/init.d/snortd /etc/rc5.d/S99snortd [root@hydra ~]# ln -s /etc/init.d/snortd /etc/rc0.d/K99snortd [root@hydra ~]# ln -s /etc/init.d/snortd /etc/rc6.d/K99snortd
Now you can start snort in the usual fashion for a service
[root@hydra ~]# /etc/init.d/snortd start
Starting snort: Spawning daemon child...
My daemon child 50434 lives...
Daemon parent exiting (0)
[ OK ]
Note however, that snort can throw errors that the initialization script will not catch; you may end up with the happy green [ OK ] but snort might not have started correctly. Always be sure to take a look at /var/log/messages to be sure everything started correctly. You should see something like
Mar 23 09:51:22 hydra snort[50434]: --== Initialization Complete ==-- Mar 23 09:51:22 hydra snort[50434]: Commencing packet processing (pid=50434)
in your logs indicating a successful startup.
Before we leave, take another look at /etc/sysconfig/snort. Note also that line 15 specifies that snort will listen only on eth0; if you copied your virtual machine and did not correctly update the system settings so that you no longer have an eth0, well, you won’t be seeing much traffic.
At this point, the snort should be running correctly (test it!) and will start on system boot. Note that there can be a lag of a minute or two between when snort detects alerts and when they appear in the file /var/log/snort/alert.
Tuning Snort
Running snort is more complex than simply getting the program to run however. Snort, like all intrusion detection systems must be tuned- this will reduce the number of false positives the system generates as well as ensure that traffic is being analyzed correctly. All of these changes will need to be made in /etc/snort.conf.
Lines 45-96 describe your network, and should be modified appropriately. The variable HOME_NET (line 45) is used to determine which machines you are protecting. Being precise with this variable will help reduce the number of false positives.
To add a single address, simply enter the IP
ipvar HOME_NET 10.0.2.18
To specify a collection of addresses, list them and enclose them in square brackets, without spaces
ipvar HOME_NET [10.0.2.18,10.0.2.2]
To specify a range, use CIDR notation
ipvar HOME_NET 10.0.2.0/24
Ranges can be included in lists
ipvar HOME_NET [10.0.1.0/24,10.0.2.0/24]
The EXTERNAL_NET (is the list of machines that are considered to be external to your network. Again, precision will reduce the number of false positives.
To negate a value, precede it by an exclamation point:
ipvar EXTERNAL_NET !10.0.2.0/24
Variables can be included, provided they are preceded by a dollar sign
ipvar EXTERNAL_NET !$HOME_NET
Most remaining network variables are self-explanatory. Remember- precision here will reduce false positives, but errors will allow potential intrusions to go undetected.
The variable SHELLCODE_PORTS is used to specify which port(s) should be examined for the presence of a NOP sled, which may indicate the use of shellcode.
SIP servers are used for Internet telephony.
GTP is a tunneling protocol to carry radio data (e.g. 3G, LTE) over IP.
AIM refers to the AOL instant messaging service; the IP ranges listed are AOL servers.
Lines 104-106 specify the location of your snort rules; we have already modified these to match our installation.
Lines 120-141 specify how snort will respond to TCP packets that may be malformed. You can leave these variables alone. Details of this process are found in /usr/local/src/snort-2.9.4.1/doc/README.decode. When snort encounters a packet, it is first decoded; as part of that process it looks at checksums and the like for evidence that the packet is malformed. If it finds a malformed packet, snort can then raise an alert.
Alerts can be raised for malformed packets altogether, for bad IP options, for experimental or obsolete TCP options, for bad T/TCP options (c.f. RFC 1644) and for various combinations. See the documentation for details. We should not need to make any changes in this section.
Line 148 configures the maximum number of flowbits. These are a way for snort to relate the contents of one packet to another. A rule can see a particular pattern in a packet, and then set a flowbit. If another rule sees a different pattern and if the flowbit is set, then the second rule can fire an alert. Do not simply uncomment the line however, as the community ruleset provided actually required 122 flowbits- more than the 64 specified in the configuration file. This can be left in its commented out default state.
Line 151 would be used to configure the use of snort as an active responder. If snort is inline- between the traffic’s source and destination, snort can be used to modify the traffic or even reset the connection. However, we did not enable this feature when we compiled snort, and so for us it can be ignored.
Further, because we do not plan on using snort inline, we can also ignore the DAQ options for inline operations (lines 153-163).
The UID and GID for snort to run as were specified in /etc/sysconfig/snort, so we can ignore lines 167-168. Notice that if you run a ps aux command, you can see that the user & group for snort were specified on the command line
[root@hydra ~]# ps aux | grep snort snort 2752 0.0 24.2 610580 245376 ? Ssl 10:02 0:00 /usr/sbin/snort -A fast -b -d -D -i eth0 -u snort -g snort -c /etc/snort/snort.conf -l /var/log/snort root 2778 0.0 0.0 103300 852 pts/0 S+ 10:04 0:00 grep snort [root@hydra ~]#
The section “Configure PCRE match limitations” (lines 190-191) provide the limits on the use of regular expressions; see the snort manual, p. 39. There is no need to modify these values.
The section “Configure the detection engine” (line 198) determines the algorithm snort uses for pattern matching; see the snort manual, pp. 33-36. There is no need to modify this variable. There is also no need to modify the value for the event queue (line 201), which is described in the snort manual on p. 37.
Since we will not be using GTP, that section (line 208) can be ignored and left commented out.
We can also pass over the technical configuration directives for latency, perf, and protocol aware flushing.
Section 4, lines 237-249 give the path to the various snort libraries. You may recall earlier that we moved the dynamic rule shared objects to the directory /usr/local/lib/snort_dynamicrules/; the configuration directive on line 253 now makes the rationale for that choice clear.
Lines 256-265 in Section 5 cover the preprocessor for GTP and more configuration for snort in an inline configuration. Since neither apply to use, they can be ignored; indeed lines 265-269 can even be commented out.
Lines 268-269 configure the frag3 preprocessor. One approach to evading an intrusion detection system is to fragment the packets. Individually the different fragments may be inoffensive, but when reassembled they are malicious.
Different operating systems may reassemble fragmented packets in different ways; this is especially the case when the fragmented packets are malformed. This preprocessor reassembles fragmented packets so that they can be evaluated. See the snort manual, pp. 40-43 for details.
Notice that the default policy here is to assume that all targets are Windows based systems. Suppose that most of the systems in our network are Linux systems, but we have Windows systems at 10.0.2.7 and 10.0.2.11. We should replace the frag3_engine directive with
preprocessor frag3_engine: bind_to [10.0.2.7,10.0.2.11], policy windows detect_anomalies overlap_limit 10 min_fragment_length 100 timeout 180 preprocessor frag3_engine: policy linux detect_anomalies overlap_limit 10 min_fragment_length 100 timeout 180
Here we have specified the Windows policy only applied to the Windows machines. Since the second directive does not specify an IP range, it would be applied to any IP address not already matched.
Lines 271-287 configure the stream5 preprocessor. This reassembles both TCP and UDP streams for subsequent analysis. See the snort manual, pp. 43-48 for details.
Notice that the TCP reassembly process does depend on the underlying OS; the default rule (line 283) in /etc/snort/snort.conf specifies that snort should use the same rules that Windows does for reassembly. If we continue to suppose that most of our network is Linux with just two Windows machines, we might try using a bind_to directive as we did with the frag3 preprocessor. However, stream5_tcp will not accept a list of IP addresses, attempt to do so, and you will get an error in your logs:
Mar 23 11:44:51 hydra snort[3777]: FATAL ERROR: /etc/snort/snort.conf(286) => Invalid Stream5 TCP Policy option. IP lists are not allowed.
If the individual systems are not grouped in CIDR ranges, then you can simply use multiple directives:
preprocessor stream5_tcp: bind_to 10.0.2.7, policy windows, detect_anomalies, require_3whs 180, overlap_limit 10, small_segments 3 bytes 150, timeout 180 preprocessor stream5_tcp: bind_to 10.0.2.11, policy windows, detect_anomalies, require_3whs 180, overlap_limit 10, small_segments 3 bytes 150, timeout 180 preprocessor stream5_tcp: policy linux, detect_anomalies, require_3whs 180, overlap_limit 10, small_segments 3 bytes 150, timeout 180
Note also the the default rule provided a list of ports on which the TCP reassembly is performed. If you are running a service on a nonstandard port- like splunk or TCP syslog, and you want to specify the monitored ports, then you should be sure that your port(s) are on your list.
Lines 292-324 cover the http_inspect preprocessor. This reassembles HTTP streams for subsequent analysis. See the snort manual, pp. 58-72 for details. Note that the http_inspect preprocessor can be tuned differently for different IP addresses through the use of the server directive (manual, pp. 60-61). Note that the rule in the provided default /etc/snort/snort.conf is applied globally; this probably should be modified depending on your network.
The http_inspect preprocessor can be tuned differently for different types of web servers through the use of the profile directive. Available values include all, apache, iis, iis5.0, and iis4.0; see the manual, p. 61. This variable should also be tuned for your environment.
The http_inspect preprocessor only decodes traffic on the ports specified. Note that the values specified in the /etc/snort/snort.conf file should be trimmed to only those ports on which a web server actually listens to avoid false positives.
HTTPS traffic is encrypted, and cannot be decoded with http_inspect; thus port 443 and other SSL protected ports should not be included in the list of ports for http_inspect.
As an example, suppose that 10.0.2.16 and 10.0.2.17 were running an Apache Web server, only on the standard port 80. Then you could use a directive like
preprocessor http_inspect_server: server { 10.0.2.16 10.0.2.17 } \
profile apache \
ports { 80 } \
extended_response_inspection \
enable_cookie \
inspect_gzip \
unlimited_decompress \
normalize_javascript \
server_flow_depth 0 \
client_flow_depth 0 \
post_depth 65495 \
allow_proxy_use \
oversize_dir_length 300 \
normalize_headers \
normalize_cookies \
normalize_utf \
max_headers 100
This would be in addition to the default policy.
Line 327 covers the preprocessor for RPC traffic. See the snort manual, pp. 54 for the syntax. Note that this only covers ONC-RPC traffic; i.e. RPC traffic for Linux / Unix type machines- not Windows.
Line 334 starts the back orifice preprocessor. Back orifice is an antique remote windows administration tool once commonly used in trojan horses; the original was released in 1998 and an updated version (BO2K) in 1999. This preprocessor is meant to normalize traffic sent to/from back orifice tools. In 2005, it was noted that the version of the bo preprocessor that shipped with snort 2.4.0 – 2.4.3 was vulnerable to a buffer overflow that could result in an attacker obtaining root privileges on the snort sensor; exploit code was released and is even available for metasploit. What is the lesson here? Never run unnecessary services! In 2005 Back Orifice was not a priority threat. Are you worried about it today? Should you enable the preprocessor?
Lines 333-379 describe the FTP preprocessor; this preprocessor also normalizes telnet traffic. It is described in the snort manual on pp. 81-88. The telnet preprocessor is enabled on a global level, through you can specify the ports it checks. The ftp_server preprocessor lets you specify the ip address(es) and port(s) of FTP servers. Note that the configuration in /etc/snort/snort.conf applies to traffic to any IP address, on ports 21, 2100, and 3535. These values should be tuned to your particular network. Snort can also normalize traffic from FTP clients.
Lines 382-410 configure the SMTP preprocessor; it is described in the snort manual on pp. 72-77. This should be tuned for your network (since we are not running SMTP servers).
Line 413 holds a (commented out) configuration for the portscan module. This module is covered in the snort manual, pp. 48-53. Simply uncommenting the line will not produce any results, as no log file is specified. To specify the location where portscan alerts are sent, simply use the logfile directive; e.g.
preprocessor sfportscan: proto { all } \
memcap { 10000000 } \
sense_level { medium } \
logfile { pscan }
will send the results of the portscan module to the file /var/log/snort/pscan.
An nmap scan of the box will then yield results in that file like
[root@hydra ~]# cat /var/log/snort/pscan Time: 03/23-11:58:44.078686 event_ref: 0 10.0.2.250 -> 10.0.2.100 (portscan) TCP Filtered Portscan Priority Count: 0 Connection Count: 200 IP Count: 1 Scanner IP Range: 10.0.2.250:10.0.2.250 Port/Proto Count: 199 Port/Proto Range: 21:55600
Some of the more clever of you have suggested that, with the classroom laboratory being isolated and on its own private network, that you should have the opportunity to play some fun ARP spoofing games. I said no- then.
Lines 416-417 are the (commented out) lines to configure snort to detect ARP spoofing; they are covered in the snort manual on pp. 92-93. Suppose you want to look for ethernet inconsistencies and to be sure that the mappings of MAC address to IP address are consistent for the host 10.0.2.2 and the gateway 10.0.2.254. This can be done with a set of configurations like
preprocessor arpspoof preprocessor arpspoof_detect_host: 10.0.2.2 00:0C:29:C2:89:83 preprocessor arpspoof_detect_host: 10.0.2.254 00:1e:e5:3f:69:91
Lines 420-426 configure the SSH preprocessor; this is discussed in the snort manual on pp. 88-90. Because SSH traffic is encrypted, snort can do little with the data;
however it is able to scan for certain attacks (Challenge-Response overflow and CRC 32) that involve sending very large payloads immediately after the SSH authentication completes.
Lines 429-433 are for the configuration of the SMB DCD-RPC preprocessor. This normalizes traffic to and from SMB services, including windows based RPC calls and Samba servers. The syntax is discussed in the snort manual, on pp. 93-107. You may wish to update the policy variable to match your network; available choices include Win2000, Win2003, WinXP, WinVista, and various Samba versions.
Line 440 configures the DNS anomaly preprocessor; see the snort manual p. 90 for details. This preprocessor only checks for three specific vulnerabilities- DNS Client RData Overflow, Obsolete Record Types, and Experimental Record Types
Line 439 configures the SSL/TLS preprocessor; this is described in the snort manual on pp. 90-92. In general, you want snort to ignore SSL encrypted traffic, as it
cannot read the data, and may cause false positives. This module is configured to only track traffic until the data is encrypted. Note also the large collection of default ports for this directive; this should be tuned for your particular network.
Line 442 configures the sensitive personal data preprocessor; this is discussed in the snort manual on pp. 107-110. This preprocessor allows for the creation of rules that can fire if certain types of data are noted, including credit card numbers, email addresses and social security numbers.
There are a number of additional preprocessors, including SIP, IMAP, POP, Modbus, DNP3, and the Reputation preprocessor. Since we are not running email, VoIP or these other esoteric services, most of these can be ignored. The reputation preprocessor can be used to block/drop/pass traffic based on IP whitelist and blacklists; however this is of value only if snort is inline. Recall that we commented out the reputation preprocessor earlier in our installation process.
Lines 514-530 describe how snort is to store the results. Note that, by default in this install, files have been logged to /var/log/snort. This is controlled by the startup script /etc/init.d/snortd, which uses the configuration file /etc/sysconfig/snort. That file specifies the log directory; it also specifies the keeping of the binary packet logs we have already examined in Wireshark.
Most of the more interesting uses of snort start by passing the results of snort to a database. These results can then be parsed by a number of different applications to enable the results to be better visualized. Since we have not (yet) covered databases, we will leave this discussion for a later date.
Lines 541-657 contain the include statements for the various signature files that snort uses for its standard rules, while lines 675-692 contain the include statements for the signature files for the various shared object rules. Be sure to enable those rules that are appropriate for your environment, and be sure to include both types.
Using Snort
Many students think that intrusion detection systems, well, catch intrusions. After all, it is in the name, isn’t it?
Well, Snort is only as good as its rules and what its rules will catch. Try out some exploits, and see what snort notices. One good example is the MS 13-055 CAnchor attack.
Before you run that attack, be sure that the browser-ie.rules file is enabled, and be sure to take a look at lines 495++ of that file.
After the attack, grab a shell and interact with the system. Once you are done with that, take a look at /var/log/snort/alert. Do you see what what you expected?
Packet Captures
You may wish to collect all of the packets from a particular host or hosts for later analysis. The simplest way to do so is to use the tcpdump tool. Run from the command line with the syntax
[root@hydra~]# tcpdump -i eth0 -s0 -C4 -Z root -w capture
this will result in
- All packets from the interface
eth0being captured - Because the snaplength has been set to zero (
-s0) the entire packet will be captured - Up to 4 million bytes (3.9 Mb) will be stored in the file capture. Subsequent data will be stored in the file capture2, then capture3 and so on.
- Capturing will be done as the user root.
When the capture is complete, you can open these for subsequent analysis in Wireshark. You can use Wireshark to combine multiple files into a single larger file.
You can also run the packet captures through snort with the syntax
[root@hydra ~]# snort -r capture
Finally, you may want to use the Windows tool Network Miner. This Windows tool can start with a packet capture, and extract lists of files, hosts, credentials, and images for subsequent analysis.
Most cool.
Autopsy
Suppose that you will want to perform a more detailed forensics analysis of a system that was part of one of our class exercises. There are a number of tools that can be used, and in this short lesson we will discuss using Autopsy from The Sleuth Kit. The currently released version is 3.0.5, and runs only on Windows.
Autopsy works on raw disk images, and the process of obtaining these images is not as simple as one might first expect, especially given some of the limitations in our classroom environment. In the lab, all the work must be done on virtual machines, as you are not allowed to install software on the hosts. The sheer size of a disk image file makes using them in a virtual environment quite a challenge, and finally there is the nature of VMWare virtual machines themselves to add to the mix.
That said, there is a solution, and I will demonstrate it by applying it to a version of our Exercise Control system. This is a Linux system (CentOS 6.2), running email, NTP, Nagios, and a PHP web application that let attackers score points for the shells they obtained on the students. Good times.
One thing about this process though- it will take some time. We will be moving and analyzing files of tens of gigabytes in size, and this does not happen quickly. You can do other things while the various tools churn on the data, but budget at least a few hours to let the automated tools do their things.
Preparing the Virtual Machine
Take the virtual machine to be analyzed, and copy the files to a convenient location on your hard drive. This is a duplicate of the original virtual machine, as we want to be careful not to modify the original.
Load the machine in VMWare, but do not start it. Before we can perform our analysis, we need to remove all of the snapshots that have been taken. Start Snapshot Manager in VMWare by navigating VM → Snapshot → Snapshot Manager, or simply pressing CTRL+M.
Each time a VMWare Snapshot is taken, VMWare records the state virtual disk as well. We need a single disk image to proceed, so we start by deleting all of the snapshots. As this is done, VMWare will merge the various virtual dist states into the needed single disk. In this example, I had five snapshots; deleting all five took about 20 minutes, deleting the most recent snapshot first and moving back in time.
Once all of the snapsnots are deleted, visit the directory that contains the virtual machine. There you will see a number of files, including the .vmx file that contains the configuration information for the virtual machine, and the various .vmdk files that contain the virtual disk.
As only the virtual disk is relevant to us, we can delete all but the .vmdk files (remember this is a copy of your original virtual machine). One of the .vmdk files is a small (1KB) file that does not end with a number; that too can be deleted as it contains configuration information rather than the disk image. Go ahead and open that file in a text editor to see its contents before you delete it!
# Disk DescriptorFile version=1 encoding="windows-1252" CID=1758f873 parentCID=ffffffff isNativeSnapshot="no" createType="twoGbMaxExtentSparse" # Extent description RW 4192256 SPARSE "CentOS 64-bit-s001.vmdk" RW 4192256 SPARSE "CentOS 64-bit-s002.vmdk" RW 4192256 SPARSE "CentOS 64-bit-s003.vmdk" RW 4192256 SPARSE "CentOS 64-bit-s004.vmdk" RW 4192256 SPARSE "CentOS 64-bit-s005.vmdk" RW 4192256 SPARSE "CentOS 64-bit-s006.vmdk" RW 4192256 SPARSE "CentOS 64-bit-s007.vmdk" RW 4192256 SPARSE "CentOS 64-bit-s008.vmdk" RW 4192256 SPARSE "CentOS 64-bit-s009.vmdk" RW 4192256 SPARSE "CentOS 64-bit-s010.vmdk" RW 20480 SPARSE "CentOS 64-bit-s011.vmdk" # The Disk Data Base #DDB ddb.virtualHWVersion = "7" ddb.longContentID = "aa6c2274dab6dff20cf38a821758f873" ddb.uuid = "60 00 C2 9f ee e0 1c d5-65 8b ce 41 73 6d 41 39" ddb.geometry.cylinders = "2610" ddb.geometry.heads = "255" ddb.geometry.sectors = "63" ddb.adapterType = "lsilogic" ddb.toolsVersion = "8328"
The Joy of DEFT
With the virtual disk of the target prepared, the next step is to convert the result to a raw disk image for analysis. The easiest tool to do so is called qemu-img, however this is a Linux based tool. To make your lives somewhat simpler, I have installed qemu-img on a DEFT virtual machine.
DEFT Linux is an Italian Linux distribution that focuses on computer forensics and incident response; it has a number of tools (including Autopsy) that can be used to analyze a system. You can even use DEFT to perform a live analysis of a system by booting it off a CD-ROM (or a CD-ROM .iso).
Log on to the provided virtual machine as root; the password is "deft".
Now I know what you are thinking- how can we copy the entire virtual hard drive from one virtual machine to another? Well, we are not going to do that at all, actually. Instead we are going to use VMWare’s Host-Guest File System (HGFS).
From the DEFT virtual machine, navigate VM → Settings, then select the Options tab, and highlight the Shared Folders entry.
Select Add, and use the Wizard. The Host path is the location on the host where we stored the copy of the .vmdk files for our virtual machine. The Name will be used to determine where the result will be on the DEFT Linux guest. If the Name is set to "Forensics", then the directory /mnt/hgfs/Forensics in the virtual machine will be mapped to the Host path location in the host; in this example to C:\Users\mike\Documents\2013 Case Studies\VMs\Forensics.
Enable the share, and be sure you do not mark it read-only.
To make your lives even simpler, I have provided a short Bash script on the Desktop of the DEFT image on the labshare that will work convert each of the .vmdk files to a raw image. Just copy that file to the location inside /mnt/hgfs/Forensics that contains your virtual disk, and run it.
[On my system, I have separate directories inside C:\Users\mike\Documents\2013 Case Studies\VMs\Forensics for each system to be analyzed, so the location of my virtual disk for the Exercise control system is C:\Users\mike\Documents\2013 Case Studies\VMs\Forensics\ExerciseControl. You can organize your set-up as you see fit.]
Just run the script from the proper directory, and go get a coffee. Or lunch. Or something.
deftvapp ~ % cp /root/Desktop/convert /mnt/hgfs/Forensics/ExerciseControl/ deftvapp ~ % cd /mnt/hgfs/Forensics/ deftvapp /mnt/hgfs/Forensics % ls convert ExerciseControl Fermus Trantor deftvapp /mnt/hgfs/Forensics % cd ExerciseControl/ deftvapp ../ExerciseControl % ./convert CentOS 64-bit-s001.vmdk CentOS 64-bit-s002.vmdk CentOS 64-bit-s003.vmdk CentOS 64-bit-s004.vmdk CentOS 64-bit-s005.vmdk CentOS 64-bit-s006.vmdk CentOS 64-bit-s007.vmdk CentOS 64-bit-s008.vmdk CentOS 64-bit-s009.vmdk CentOS 64-bit-s010.vmdk CentOS 64-bit-s011.vmdk deftvapp ../ExerciseControl %
See, this part takes a while. It has some 25 G of data to generate, and that does not happen quickly. On my system, it took about 10 minutes to process each full .vmdk file. Since only the first two files were full, the whole process took half an hour. I have seen it take two or three times as long, especially when the disk is big.
At this point, your directory has both .vmdk and .raw files for the hard drive. You can dispose of the .vmdk files at this point, as all we need to do is to combine the various .raw files into a single whole.
[Why do I continually recommend deleting intermediate files in this lesson? Because if you do not, you can run out of disk space. At this point in the example, we have used 24 GB of space, and that does not include the virtual machines.]
Combining the files
You can use a simple cat command in Linux to combine all of these files, but my experience has been that the VM environment slows the process down considerably. Instead, I used the copy command from the Windows host, with the /b switch.
C:\Users\mike\Documents\2013 Case Studies\VMs\Forensics\ExerciseControl>copy
/b *.raw disk.img
CentOS 64-bit-s001.raw
CentOS 64-bit-s002.raw
CentOS 64-bit-s003.raw
CentOS 64-bit-s004.raw
CentOS 64-bit-s005.raw
CentOS 64-bit-s006.raw
CentOS 64-bit-s007.raw
CentOS 64-bit-s008.raw
CentOS 64-bit-s009.raw
CentOS 64-bit-s010.raw
CentOS 64-bit-s011.raw
1 file(s) copied.
Again, be patient. This took about 20 minutes on my system.
Oh yes- don’t forget to delete the intermediate .raw files. We have our disk image, and that is all we need.
Now the smart among you have noticed a few things. We started by saying that we wanted to use Autopsy to do the analysis, and hey, it is one of the tools available in DEFT- navigate d → DEFT → Analisys tools. But didn’t we say that this is a Windows only tool? Well, it is, and frankly it does not run well on my Virtual Machine. There is the browser option though. I tried, it, but found it hard to use.
My recommendation is that we go back and load up the disk image in a Windows version of Autopsy. After trying the different alternatives, I think that you will agree. Moreover, the hosts in the lab already come with Autopsy installed, so life is good.
Since we no longer need DEFT, we can shut that VM down, but before we leave it, let me encourage you to look around and try some of the other tools it provides. It is a nice distribution, and I wish we had more time to explore it all in detail.
Image Analysis with Autopsy
Start Autopsy, and select "Create New Case". You may wish to consider all of the hosts from a single exercise as a single case, as Autopsy is able to analyze data from multiple hosts as part of the same case. This would better let you detect evidence that occurred across multiple systems.
The Base Directory will be used to store the information about the case; I simply set that you a folder on the desktop in this example. I did not choose a serial number or provide an examiner name.
With the case started, you will be asked to provide your first disk image. Give it the name of the full disk image you have created; be sure that you point it to the correct place!
I recommend that you enable all of the ingest modules.
Once the image is loaded, Autopsy will begin processing it. Again, this will take some time; you may want to budget roughly an hour for the whole process.
Once the analysis is complete, you will be able to search the entire drive for information.
The key here is that Autopsy indexes and searches the complete drive. Deleted and orphan files may still be present on the disk, even though they have been deleted from the file system; Autopsy still includes these files in its analysis.
You can also modify the list of keywords to be searched to include URLs, IP addresses, and email addresses. Remember though, that these are simple regular expression type searches, and as such they are vulnerable to returning many (many) false positives.
Note also that once these changes are made, Autopsy begins working through the disk image file again, and this can not only take some time, but it can lock up the program. That said, once the indexing is complete, you can find out quite a bit about the system. For example, here is a search for the IP address 10.1.2.33, and you can see from the screesnshot, that Autopsy picked up the use of that IP address in a deleted file, in what looks to be a snippet from a Nagios configuration.
If that is not sufficiently righteous and cool, you should navigate Tools →
Make Timeline (Beta). As you no doubt expect by now, this is not a speedy process. The results however, may prove helpful. Take a look at this screenshot, at notice how we can isolate what files were created, modified, or deleted on a day by day basis.
How much help this will provide to you depends on what Red Team did to your system- if the did not touch the hard drive, then this sort of analysis will not help. It will also depend on the types of questions you ask. Like all tools, especially all forensics tools, the tool does not provide the answers; it does not even provide the questions. However, it is a great resource.
Darknet
- Best EDR Of The Market (BEOTM) – Endpoint Detection and Response Testing Tool
- AgentSmith HIDS – Host Based Intrusion Detection
- padre – Padding Oracle Attack Exploiter Tool
- Privacy Implications of Web 3.0 and Darknets
- DataSurgeon – Extract Sensitive Information (PII) From Logs
- Pwnagotchi – Maximize Crackable WPA Key Material For Bettercap
- HardCIDR – Network CIDR and Range Discovery Tool
- Socialscan – Command-Line Tool To Check For Email And Social Media Username Usage
- CFRipper – CloudFormation Security Scanning & Audit Tool
- CredNinja – Test Credential Validity of Dumped Credentials or Hashes
Windows Security
- An error has occurred; the feed is probably down. Try again later.
Security Focus Vulnerabilities
- An error has occurred; the feed is probably down. Try again later.
Security Bloggers Network
- An error has occurred; the feed is probably down. Try again later.
Krebs on Security
- Patch Tuesday, May 2024 Edition
- How Did Authorities Identify the Alleged Lockbit Boss?
- U.S. Charges Russian Man as Boss of LockBit Ransomware Group
- Why Your VPN May Not Be As Secure As It Claims
- Man Who Mass-Extorted Psychotherapy Patients Gets Six Years
- FCC Fines Major U.S. Wireless Carriers for Selling Customer Location Data
- Russian FSB Counterintelligence Chief Gets 9 Years in Cybercrime Bribery Scheme
- Who Stole 3.6M Tax Records from South Carolina?
- Crickets from Chirp Systems in Smart Lock Key Leak
- Why CISA is Warning CISOs About a Breach at Sisense
CyberOperations 