Executive Summary

This report shows an in-depth analysis of intrusion detection logs gathered between the months of August and November 2002.

The data analyzed shows signs of intrusions and machines compromised by backdoors and worms. The following findings need immediate attention; the analysis in this report gives the necessary details and support for calling the attention to these incidents:

• Multiple machines in the internal network are compromised by a worm. The compromised machines are actively trying to infect other vulnerable machines (see Section 3.1).
• At least one machine is compromised by an FTP attack (see Section 3.1 under ``FTP CWD overflow attempt). We recommend taking these machines offline immediately.
• External sources are utilizing reconnaissance mechanisms to gather information about the internal networks (see Section 3.2).
• It seems that a DoS attack is targeting a number of internal machines (see Section 3.5^1.1). These findings have to be confirmed with some additional source of information. In case of a positive confirmation, ACLs on the border devices should be configured to block all the aggressors.
• Peer to peer traffic was detected by the IDS (see Section 3.5). We recommend to possibly block peer to peer traffic at the border. If this is not a possibility, an awareness session with all the internal users should help reduce this type of activity.

Whereas the above finding should be immediately addressed, there are some more recommendations that should be addressed:

• The Snort signatures should be tuned. We will see all throughout the report, that the number of false positives is immense.
• We were only given log files from one Snort instance. The amount and type of attacks this sensor can capture is very limited. We recommend deploying more sensors, especially in the internal network. We will see later how another sensor could help us verifying some of the attacks.
• Given the high number of false positives, it would make sense to utilize some kind of a correlation software or even a security information management (SIM) solution. The additional context that a SIM could add to an event would greatly improve their accuracy.
• As we will see later, there do not seem to be any access control devices deployed at all. Even if this is an academic environment, where networks have to be as open as possible, we recommend to filter certain traffic, such as peer to peer that can be abused for illegal purposes (see Section 3.5).
• To limit the amount of malicious traffic (e.g., peer to peer, irc servers, etc.), we recommend to first issue a security policy which disallows these services and second to enforce the policy.

We found that the data sets were already analyzed by many other GCIA students. Instead of repeating their analysis, we decided to approach the problem slightly different, by emphasizing the ways of analyzing such a data set. The paper is therefore a little weaker on the analysis of specific incidents and focuses more on the approach of getting a handle of a big data set. We will first give a very generic overview of the data found in the log files. After determining the topology, we will outline some anomalies (Chapter 2) and then establish some hypotheses on how to find suspicious behavior in a generic way (see Chapter 3).

We had to take two Sections out of this paper as it grew too big. We did not want to loose our main Sections where we came up with interesting ways of analyzing the data but put some of the ``ordinary'' analysis Sections on a Web page: http://raffy.ch/projects/Raffael_Marty_GCIA_Additional_Chapters.pdf.

Before I forget: Thanks to Christian for helping me with AfterGlow[14] and Colby for having a quick glance at the paper before submission.