Skip to main content

Mastering in Intrusion Detection System Part - 4


Configuring Snort as an Intrusion Prevention System

Introduction

In this module, we will focus on the Intrusion Prevention part of Snort. This would be a bit short script in comparison with the previous module of this workshop.

Pre-requisites

  It is highly recommended that you should first complete the installation of Snort (recommended on the normal machine) and completed the previous modules.

Snort as Intrusion Prevention System (Inline Mode)

     Considering the differences between IDS and IPS, the deployment of these two systems is designed according to their role in the network.

  Intrusion Detection Systems plays the role of monitoring. They must be able to sniff the traffic that interests them while not compromise the overall network throughput. However, on the other hand, intrusion prevention systems must take immediate action to suspicious packets.

  Now, the deployment needs to enable Intrusion Prevention System to look at each packet and dealn with suspicious packet in real-time. Typically making all traffic pass through IPS could achieve the deployment requirement. This is so-called in-line deployment.

   IBM has demonstrated the following design for deployment of Snort based intrusion prevention system.



Configure Snort as Intrusion Prevention System (IPS)

   Although SNORT is commonly used as an intrusion detection tool, but it has an enhanced capability that could make it act as an Intrusion Prevention System.

Settings to be considered for making Snort as an IPS

• Network Deployment Method
• In-line deployment: The inline deployment enable SNORT to look at each packet and deal with suspicious packet directly
• Advanced Network Configuration with -iptables
• SNORT Mode Configuration should be in-line mode
• SNORT’s rule Actions drop/reject/sdrop


Now configure and run Snort as basic intrusion prevention system as explained.

Change the rules type in the Snort configuration i.e. in the rule file open the http or telnet rule file and change the alert to drop as shown below:

drop tcp any any -> any 23 (msg: “Drop telnet packets”; sid: 1000001)
     pass ip any any -> any any

Now, edit the configuration file my-snort.conf as follows:

config daq_dir: /usr/lib64/daq
config daq: nfq
config daq_mode: inline
config policy_mode: inline
output alert_full: stdout
include /etc/snort/rules/snort.rules

Now simply run the snort with the following options as shown below:

$ snort -c /etc/snort/my-snort.conf -Q --alert-before-pass

iptabes configuration

   Package filter (iptables) can be configured to pass received package form kernel level to user space where it will be handled by 3rd party application and turned back to kernel level.
 
  In our case 3rd party app is SNORT. As it is configured to work with numbered queue (NFQUEUE) we should route traffic to this queue:

iptables -t nat -A PREROUTING -p tcp --dport 8080 -j NFQUEUE --queue-num 2


Pre-routing explanation

    In iptables process model, received package is routed to PREROUTING queue before any routing rules applied. Using Snort on this stage allows us to decide the process locally or redirect somewhere else, e.g. using NAT. The benefit of using numbered queues it that you can create a number of them and pass each of them to individual rule set.

  But the disadvantage is that if SNORT fell, the service it protects became unavailable. This happens because there is none to pass data between kernel and user space.

 This is a quick representation of how you can configure Snort as an IPS 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...
Read more

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 pa...
Read more

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 ...
Read more