IDS News

- Previous Post >>

IDS used as a Network Forensic Tool

Note: This is the second post of a two parts series on how to use IDS in a different way.

Intrusion Detection Systems are traditionally seen as Defensive tools. They can however be used for different purposes than initially designed for as highlighted in the previous post , where we discussed how IDS could be used as an offensive tool.
The popularity of pre-configured/packaged IDS environments such as SELKS or Security Onion provide various software packages and Graphical User Interfaces to navigate through large volume of data by parsing/categorising/filtering it automatically.

More importantly, such systems are starting to provide more than just traditional IDS data (i.e.: Security info), they also provide context data, in the form of non security related information such as HTTP traffic, network flow, DNS data, TLS data, etc. This can help getting a better picture of a given network snapshot.

When looking at an IDS that way, it can be of great help in analysing a network capture and even a greater help the larger that network packet capture is.
Traditionally, one would use a tool such as Wireshark to conduct network forensic. It is arguably the best tool for such activity but it can also be very time consuming and when dealing with multiple pcap files, very hard to get the whole picture.

This is where using an IDS environment in a VM can help, by replaying previously captured pcap files you get an automated analysis of that network traffic with reports on timeline activities, files extraction, web activities, etc.
You can of course go back to a more manual and in-depth pcap inspection through Wireshark if required, but if you are dealing with a few days worth of network packet captures, getting that automated IDS analysis and activity timeline visualisation is a great way to quickly identify points of interests (time, hosts, protocols, etc).

There are however a few tricks to bear in mind when using usch an environment:

  • Your IDS VM should be cleared before each pcap replay and you should not monitor any live NIC. This is to ensure no external or historical network artefact pollutes your analysis.
  • When using tcpreplay, you may want to speed up the replay speed, especially if you have days worth of capture! This will obviously change your timeline. Doing it too fast means you may loose a visual sequence of event. I am using the following command but sometimes lower the multiplier option (M) depending of the dataset (the eth10 will make sense later): tcpreplay -i eth10 -M10 your.pcap
  • Beware of VM architecture. With Vmware at least, if your NIC is not live/connected to a cable then although your linux VM will display your NIC as up and your tcpreplay will report a successful run, no packets will be played on that standbye/disconnected NIC, and your IDS will not see any network activities. To fix this issue, you need to create a dummy network interface instead:
    sudo modprobe dummy
    sudo ip link set name eth10 dev dummy0
    sudo ifconfig eth10 up

    All you need to do before running tcpreplay, is to configure your IDS to monitor eth10 and only that interface.

    Congratulations, you now have a portable network forensic VM that will save you hours when analysing pcap.
    This can also be used as part of a more offensive activity (Pen Test/Red Team exercise), as highlighted in this previous post where a potential victim network traffic has been captured, and where network forensic takes a different meaning!

  • - Previous Post >>