Digital Forensics is moving award from traces of activity toward network forensics, where the key information about activity is contained within network traces. Unfortunately these network traces are often extremely verbose, where a typical user might generate hundreds of data packets every minute. Thus, in order to detect a range of threats we need to understand what the traces of activity look like so that we can create network rules which detect the activity. For this we can use an Intrusion Detection System (IDS) to monitor a range of network traffic, and create events for the system manager to analyse.
Key features of an IDS
One of the key things about an IDS is how specific we make the rules. If we make it too specific we will miss threats which vary slightly from the signature, where if we make it too general, we may get swamped by alerts, which can often desensitise the administrator to the alerts. Thus we try to balance the sensitivity of the rules that we create. In some cases, such as for a specific virus, we can be extremely focused, and actually capture a small and unique section from the binary footprint of the executable code. Otherwise, if it is a human-launched threat, then a human will often change their activity in order to avoid detection. For these we define the number of times that the IDS detects a threat correctly as true-positive, while one which causes an alert, but is incorrectly identified, is known as a false-positive. If it misses a threat, and does not alert the system, it is then a true-negative. In a well run system we want to maximum the ratio of true-positives to false-positives.
Understanding the Protocols
The greatest problem with network forensics is that there are so many protocols to understand, and many of these were created as single pin-point solutions, without any real thought of how they would integrate into the Internet. But, it must be said, that the reason the Internet has been so successful was this distributed approach to its development, where standards were quickly drafted as RFC (Request For Comments) and then adopted by industry. An Internet designed by a committee or a standards agency would never had happened, as there would be so many vested interests involved.
So to understand network protocols, I’ve created a lecture:
and have created a Web site in which you can analyse a whole range of network traces here.
Understanding More Advanced Traces
Often we not only have to understand the network trace, we also have to create signatures for the network of threats. For this, I have created a presentation which outlines some key threats, such as password cracking, DoS attacks, system scanning, and so on:
and I’ve created a Web page in which you can analyse these traces here.
Finally, once we have the traces, and have analysed it for a signature for the threat, we can now analyse using Snort. For this we run Snort with a network capture and use some rules to see if we can detect the threat. This can be time consuming, so we can also analyse it off-line, with a capture trace:
and then I’ve setup a Web page where you can analyse Snort alerts with various example traces and rule files here, where the following is a demo:
We learning networks forensics is all about learning about everything that happens on the Internet … and as we move increasing to the Cloud, it is one of the key skills for now, and for the future. Luckily I learnt all the protocols when I wrote my handbooks, pouring over RFCs, but now, with Wireshark and Snort, you can use these tools to learn them. Please enjoy … it’s great fun to learn, and you’ll use your knowledge in some many ways.