Skip to main content

Mastering in Intrusion Detection System Part - 2



Understanding the Snort Architecture

Introduction

Welcome to the module 2 of this workshop, in the previous module, we have discussed the core concepts of intrusion detection & prevention systems. In this module, we will discuss Snort as a defacto standard in the intrusion detection & prevention system. We will be exploring Snort architecture i.e. the building blocks of Snort.

Pre-requisites

It is strongly recommended that you should first complete the module 1 before reading this module in case you don’t have prior understanding of what we have been discussing in the module one.

What is Snort?

“It is an open source intrusion prevention system capable of real-time traffic analysis and packet logging” (Sourcefire)
”Snort is a Sourcefire product, and it has gained the market and in a couple of past years Sourcefire was acquired by Cisco Inc. so you can say that Snort is a Cisco product! But it is not labeled as Cisco because Snort is an opensource product and comes under opensource license.

Snort is also treated as a sniffer, a packet logger, forensic analysis tool and a well-known and established network intrusion detection system.

How Snort works is based on the how the data flow by Snort, data flow diagram is available in the below figure which gives a quick highlight of the process.



Snort Architecture

Snort architecture comprise of multiple components. These components work together to detect specific attacks and to generate the output in the required format as detected by the system. The architecture of Snort based Intrusion Detection & Prevention System typically consists of following major components as listed below.

• Packet Decoder
• Preprocessors
• Detection Engine
• Logging and Alerting System
• Output Modules

In the below figure, these components are shown on the basis of when which component is required to act and do the work for us. This shows a bit detailed architecture than what we have presented in the previous figure.



  First and foremost, let’s have an understanding on each of these components. This is to help us get a better overview of the overall Snort architecture and which component do what in this Intrusion detection system.

Packet Decoder

  The main job of the packet decoder is to take packets from different types of network interfaces and to prepare the packets to be pre-processed or to be sent to the detection engine. These interfaces may be Ethernet, SLIP, PPP and many more.

Preprocessors

  Preprocessors are one of the main components or plug-ins used with Snort to arrange or modify data packets before the detection engine performs any operation to find out if an intruder is using the packet.

 Some preprocessors also perform detection by finding anomalies in packet headers and generating alerts. Preprocessors are very important for any IDS in preparing data packets for analysis against rules in the detection engine.

  Preprocessors in Snort can defragment packets, decode HTTP URI, re-assemble TCP streams and many more. They function as an important part of the intrusion detection system.

Detection Engine

  The most important part of the Snort architecture is the detection engine; this is responsible for detecting if any intrusion activity exists in the packet. Snort packet engine use signatures to detect intrusion; the detection engine is also the time critical part of Snort depending upon how powerful your hardware machine is and how many rules you have defined in the configuration. It may take a different amount of time to respond to different packets.

There are factors on which the load on the detection engine is dependent on and below is a list of factors.


• Number of rules you have configured
• Power of your hardware machine on which your Snort is running
• Speed of the internal bus used in Snort hardware machine
• Load on the network Snort is configured to detect intrusions

  These factors basically should be considered at the time of designing the architecture of network intrusion detection system.

Logging and Alerting System

Depending upon what detection engine is going to find as intrusion inside a packet, the packet may be used to log the activity or generate alerts. Logs in Snort are kept in a simple text files in a topdump style or format.

Output Modules

Depending on how you want to save the output generated by the logging and alerting system, the output module job is to perform accordingly. The output module can perform the following types of operations based on the configuration:

• Simple logging to a log file
• Send SNMP traps
• Sending messages to syslog
• Log to database server
• Generate XML Output
• Modify configuration on routers and firewalls
• Send SMB messages to Microsoft Windows based machines

Placement of Intrusion detection systems

Different strategies of connecting or placing intrusion detection systems within your network exists we will show different scenarios that can be helpful in understanding where your intrusion detection system will be best fit in the network.

Multiple Sensors Design


Snort without IP Address

You can also use Snort on an interface where no IP address is assigned. For example, on a Linux machine, you can bring up interface eth0 using command “ifconfig eth0 up” without assigning an actual IP address. The advantage is that when the Snort host doesn’t have an IP address itself, nobody can access it. You can configure an IP address on eth1 that can be used to access the sensor itself.

  
  These were the architecture level components of snort.We feel it’s worthwhile to present the snort directory tree view so that you can have a quick view of all the snort rules and configuration files in oneb window. Below is a tree view representation of snort f file structure installed on CentOS Linux Machine.



















































Popular posts from this blog

Haking On Demand_WireShark - Part 5

Detect/Analyze Scanning Traffic Using Wireshark “Wireshark”, the world’s most popular Network Protocol Analyzer is a multipurpose tool. It can be used as a Packet Sniffer, Network Analyser, Protocol Analyser & Forensic tool. Through this article my focus is on how to use Wireshark to detect/analyze any scanning & suspect traffic. Let’s start with Scanning first. As a thief studies surroundings before stealing something from a target, similarly attackers or hackers also perform foot printing and scanning before the actual attack. In this phase, they want to collect all possible information about the target so that they can plan their attack accordingly. If we talk about scanning here they want to collect details like: • Which IP addresses are in use? • Which port/services are active on those IPs? • Which platform (Operating System) is in use? • What are the vulnerabilities & other similar kinds of information. • Now moving to some popular scan methods and ho

Bypassing Web Application Firewall Part - 2

WAF Bypassing with SQL Injection HTTP Parameter Pollution & Encoding Techniques HTTP Parameter Pollution is an attack where we have the ability to override or add HTTP GET/POST parameters by injecting string delimiters. HPP can be distinguished in two categories, client-side and server-side, and the exploitation of HPP can result in the following outcomes:  •Override existing hardcoded HTTP parameters  •Modify the application behaviors   •Access and potentially exploit uncontrollable variables  • Bypass input validation checkpoints and WAF rules HTTP Parameter Pollution – HPP   WAFs, which is the topic of interest, many times perform query string parsing before applying the filters to this string. This may result in the execution of a payload that an HTTP request can carry. Some WAFs analyze only one parameter from the string of the request, most of the times the first or the last, which may result in a bypass of the WAF filters, and execution of the payload in the server.  Let’s e

Bypassing Web Application Firewall Part - 4

Securing WAF and Conclusion DOM Based XSS DOM based XSS is another type of XSS that is also used widely, and we didn’t discuss it in module 3. The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie, and it is also a security feature that limits scripts on different domains from obtaining cookies for other domains. Now, the XSS attacks based on this is when the payload that we inject is executed as a result of modifying the DOM environment in the victim’s browser, so that the code runs in an unexpected way. By this we mean that in contrast with the other two attacks, here the page that the victim sees does not change, but the injected code is executed differently because of the modifications that have been done in the DOM environment, that we said earlier. In the other XSS attacks, we saw the injected code was