Sign in

Event Detail - Understanding a NIDS Event

This article assumes you understand TCP/IP in detail.  If you don't please reference this IBM redbook.

When an analyst reviews a Network Intrusion Detection System (NIDS) event they first get an overview of what they can glean from the event details.

Here is an example -- What is this telling you?

  • The event was caught by an Emerging Threats 'Open' rule. You can see the "ET" and not "ETPRO".  The ET DROP Spamhaus rules basically calling out known risky IP addresses.
  • The event 'tripped' on an 'inbound' connection -- an external IP talking to one of the assets on our internal network.   Why, because the source is Ukraine and the destination port is a well known port (TCP port 80 HTTP)
  • The internal asset is and may be accessible on the Internet via an external IP address.


  • As you page down on the event detail you can also see the rule that the packet tripped on.  A good analyst can look at the rule logic and determine if they think it is a good, bad or just OK rule.  A good rule is tight and will not cause a lot of false positives.  To understand these rules you need to understand 'byte_test' and you can read more about that here and here.  You will also need to know a bit about regular expressions--more here21.png
  • Here is a bit of detail about a rule:
    • Rule Header

      Let's start by examining the first part of a rule (note that this example does not apply to the example above) from the beginning to the first starting parenthesis. This initial part of the rule is referred to as the header, and ours looks like this:

      Breaking Down the Rule Header

      • alert - This the action. It can be alert, log, or pass (drop).
      • tcp - This the protocol of the traffic the rule is looking for. It can be tcp, udp, and icmp.
      • $EXTERNAL_NET - This the source IP or network of the malicious packets. It can be set as a variable in the snort.conf.
      • any - This the source port of the malicious traffic. This can set as a single port, multiple ports, or a range of ports.
      • -> - This is the direction of the traffic. In this case, we are looking for traffic moving from the EXTERNAL_NET to the internal or HOME_NET.
      • $HOME_NET - This the destination IP address that the traffic is moving to. As with the EXTERNAL_NET, it can be set as a variable in the snort.con
      • any - This the destination port. It can also contain specific ports, like 80, or a variable containing a list of ports


    • Snort Rule Options

      Now let's take a look at the part of the rule that falls between the parentheses. This is referred to as the rule options. This part of the Snort rule is comprised of a couplet with a keyword, a colon, and the argument.


      Our example rule options look like this:

      Breaking Down the Rule Options

      • msg - This is the message that's sent to the sysadmin if the rule is triggered. In this case, Snort reports to the sysadmin "SCAN SYN FIN".
      • flow - This option allows the rule to check the flow of the traffic. It can have a number of values including established (TCP established), not established (no TCP connection established), stateless (either established or not established), etc. In our example, the rule is triggered on traffic with or without an established TCP connection.
      • flags - This couplet checks for TCP flags. As you know, TCP flags can be SYN, FIN, PSH, URG, RST, or ACK. This rule is looking for traffic that has both the SYN and FIN flags set (SF) and in addition, has the two reserved bits in the flags byte set (12).
      • reference - This section is for referencing a security database for more information on the attack. In our example, we can find more info on this attack in the arachnids database, attack 198.
      • classtype - All the rules are classified into numerous categories to help the admin understand what type of attack has been attempted. In our example, we can see that it is classified as an "attempted-recon".
    • If you want to go really deep on these rules you can find more here.
  • Here you can also go to the asset view to see if there are other alarms being triggered by this asset OR if a NetAgent is installed you can clean other information such as what products are installed on the asset or other inventory information.


  • You should then review other events that have occurred around the same time that the ET DROP event occurred to see if you can see any patterns.  To do this got to the "Related events" section and choose 'Within 1 Hour' and press the search button:


Now lets dig a little deeper.

If you right click on the external IP you have a menu of other tools to gain information on the IP source or the Hostname source.


Here are just a few examples that can give you additional information on the source:





Now press the 'additional event info' link and you will see both the header of the packet (if we can get it and if its relevant) and the NETFLOW analytics data for the entire session.   Here you can see how many packets were inbound and outbound on that session.   In this example you might be asking why there was so much traffic to a known bad IP...

For a detailed understanding of Neflow see this great article.


Now that we know how many packets were in and out lets try to download the entire session PCAP.   On the section titled 'Pcap files Info (Full Session)' choose the '+Create file request' button and press 'send request' to ask the sensor to return the session pcap.   This session pcap can be extremely valuable to an analyst as it will tell them entire conversation between the source IP and destination IP.   Once the file is returned (takes about a minute for a small session pcap) you can press the 'Download as pcapNG' link and the file will be downloaded locally.   

Note that all of these packets need to still be on the hard drive of the sensor (it does a rolling packet capture).  If the packets have rolled off you will get an error.



Open the file up in WireShark and start to analyse the conversation (i like to use 'follow' HTTP stream if it's an HTTP conversation).



Now you have enough information to begin to formulate your approach to forensics. 



Powered by Zendesk