Recently, I have been involved in configuring an Intrusion Detection System IDS (IDS) with full packet capture using the SecurityOnion distribution (distro) in the production environment. Previously, I had set up a SOHO IDS environment when I was learning during the first Compromise, Detect and Respond (CDR) project. But that IDS deployment was done using a different distro and it also did not have the full packet capture capabilities. So in order to better familiarize myself with SecurityOnion, I decided to do a quick post about it.
Just in case you are not familiar with SecurityOnion, you can check out their awesome page here. I am not going to try to explain much about the distro itself because my explanation will not do it enough justice. Besides, their website has a whole lot more information than I can provide. They do a great job in explaining how you can start from scratch and have a system up and running in no time. They even go over how you can customize it for your specific environment and maintain the system going forward.
I followed the installation steps here and the post-installation guide here and within an hour, give or take, I had the IDS up and running (including the time it took to download the 1.3GB ISO image over my home connection). And just like my previous labs, the whole setup here was very simple: I used my laptop’s VMware Workstation for the SecurityOnion and placed the network interface in promiscuous mode to capture traffic from the host and also from other virtual machines—and, yes, using this method results in a significant packet loss, but you get the idea.
After finishing the IDS configuration, my Snorby screen looked like the above. You will notice that there isn’t much activity here compared to what we saw during the first CDR project. The main reason for this is that in the previous setup we had Metasploit running and we were playing around with some exploits, but this setup is pretty vanilla. But still, it’s pretty sweet to be able to get basic IDS up and running easily and quickly.
Now we can select any of the above alerts to view the packet details. Here are the steps for that: Select the event that you want to analyze > Select “Packet Capture Options” on the top right-hand corner > select “Custom” and then “Fetch Packet“.
After you have completed the above steps, you will be presented with a new page: “capME!”
After logging into the new interface above, you will be able to view the assembled packet behind the event. Pretty cool, huh?!
But our IDS interface is only displaying events that have some potential malicious behavior associated with them. However, there are a whole lot of packets stored in the back end of our SecurityOnion server that we can review via the following path: /nsm/sensor_data/seconion-virtual-machine-eth0/dailylogs:
You will now see logs broken up into multiple files. Depending on the volume, you may see several files for each day. In my case, there are only two files (2014-11-27 is the latest and has the most amount of data).
We can open the snot.log.xxxxxxxxx file using a number of tools, e.g. Wireshark, TCPdump, SiLK, Netwitness, etc. I opened mine using Wireshark (depending on the file size and your machine’s power, this may take some time).
TOR traffic was definitely the loudest, making up most of the logs:
And when we try to reassemble it, this is what we get:
But by looking at the Protocol Stats, we notice that there is a bunch of other traffic in this capture as well:
Wireshark Protocol Hierarchy ]
Now, we will do some SiLK kung-fu and see what we can pull out of this capture.
The first step is to open the snot.log.xxxxxxxxx file using Wireshark (or any similar tool) and save it as a new .pcap file. In the second step, I used SiLK’s rwp2yaf2sillk to convert our newly created .pcap file into flow format.
# rwp2yaf2silk –in=1417046408.pcap –out=1417046408.silk
Now, we will go through the basic analysis on our capture using various SiLK commands.
5 largest senders of bytes of data:
5 TCP connection per source and destination IP:
Show all records from the capture with either a source or destination IP of TOR:
TCP flows with a source IP of our VM and determines the top 5 destination ports by the number of flow records:
Per above output, the majority of our destination ports are 443, with the second largest being port 9001 with 15 total records. Let’s see the amount of data associated with this port:
Now, as the last step, we will go back to Wireshark and see if we can find the data that is going to port 9001:Based on the above, it seems like the traffic generated on port 9001 (default TOR port) are simply connection synchronization attempts followed by erupt connection resets.
Anyway, this concludes my quick walk through to setting up IDS with full packet capture using the SecurityOnion distro. I also used Wireshark and SiLK to do a basic triage of the packets. Super cool!