How to read and write Snort rules to bypass network intrusion detection systems. Snort: Network Attack Detection Tool Standard Keywords

Intrusion detection system for Dummies. Installation and Configuration of SNORT.

Alexander Antipov

Snort is a lightweight intrusion detection system. Snort is usually called a “lightweight” NIDS because it is designed primarily for small networks. The program can perform protocol analysis and can be used to detect a variety of attacks and investigate problems such as buffer overflows, hidden port scans, CGI attacks, OS detection attempts, etc. Snort uses "rules" (specified in "rules" files) to know which traffic to allow and which to block. The tool is flexible, allowing you to write down new rules and follow them. The program also has a "discovery engine" that uses a modular plug-in architecture whereby certain additions to the program can be added to or removed from the "discovery engine".

Snort can operate in three modes:
1. As a packet sniffer, similar to tcpdump
2. As a package logger
3. How to develop an intrusion detection system
In this article we will talk in detail about the Snort installation, its architecture, and learn how to create and manage rules.

Platform:
Linux 2.2.*,
Snort 1.7(http://www.snort.org/)
Sparc: SunOS 4.1.x, Solaris, Linux, and OpenBSD
x86: Linux, OpenBSD, FreeBSD, NetBSD, and Solaris
M68k/PPC: Linux, OpenBSD, NetBSD, Mac OS X Server

Requirements:
Tcpdump (www.tcpdump.org)
Libpcap (Snort is based on the libpcap library, commonly used in most TCP/IP sniffers and analyzers) - you can download it from here:

Today, the security of wireless networks is often talked about a lot, but network hacking is perceived as something very distant. We already published material on how to crack WEP security. Moreover, after some time it came out continuation about how to protect your network. Today our attention will be devoted to tools for checking wireless network security. And also attack detection systems - a kind of “fire alarm” for your WLAN.

By the way, if we talk about WLAN hacking, then users of home and small office networks seem especially vulnerable to us. This is primarily due to the fact that they have other tasks than protecting their wireless network. Yes and, unlike large companies, they do not have the opportunity to hire professionals.

However, not everything is as sad as it seems. In nature, there are ways to assess the security of a wireless network, despite the seeming absurdity of the combination of the words “security” and “wireless network”. Intrusion Detection Systems (IDS) allow you to detect possible ways invasions before they even happen, while the enemy is looking for an opening. Of course, such systems cannot guarantee complete security (and what, by the way, can?), but in combination with firewalls and other security measures they can be very useful. It is generally accepted that IDS is a kind of security alarm: that is, it only notifies about an attack, leaving the work with the attacker to other systems and means (even physical ones).

Rice. 1. Snort IDS.

Rice. 3. Linksys WRT54G.

Below we will give examples based on WRT54G with firmware OpenWRT RC 2(codenamed "White Russian"). In fact, there are many Linux distributions For wireless routers, but we settled on the OpenWRT firmware because it is simple, “lightweight” and comes in a package like Debian Linux.

Rice. 4. OpenWRT at work.

Warning. Loading OpenWRT, Snort Wireless or other alternative firmware versions into the WRT54G will void the warranty. Before you start flashing an alternative version of firmware, we recommend download a copy of the current firmware version

We will not go into detail about installing OpenWRT, since you can find it on the OpenWRT website excellent installation guide. After the installation is complete, you can connect to the router using Telnet () and enjoy the result.

After installing OpenWRT on the router, you can download and install the program Snort Wireless. All this can be done through the mentioned OpenWRT package system - run the command ipkg with the following parameters.

ipkg install http://nthill.free.fr/openwrt/ipkg/testing/20041204/snort-wireless_2.1.1-1_mipsel.ipk

Some may not like that this package is over a year old. But there's nothing wrong with that, because everything necessary functions IDS are present here, and all later Snort rules can also be downloaded via ipkg (more details: OpenWRT tracker page). If you decide to organize an access point on a PC, you can download the Snort Wireless source code and compile it directly on your computer. Note that you should add the flag --enable-wireless, otherwise the Wi-Fi preprocessors will not work.

Snort Wireless works like regular Snort, but is specifically designed for wireless access points, allowing you to effectively protect them from attacks. Specifically, it contains a new rules protocol called wifi and allowing the IDS to properly isolate wireless traffic typical of common WLAN attacks. For example, the same attacks using Netstumbler or attempts to crack WEP. Using the wifi protocol in Snort Wireless is very similar to setting up the normal rules for Snort, with one exception: instead of entering the IP addresses and ports of the first and second nodes, you should use their MAC addresses.

At this point we have a working Snort Wireless. Let's move on to setting it up for use on the selected network. When you run ipkg, Snort is installed in the directory /etc/snort on the router. Like other Unix programs, Snort uses an editable configuration file where you can specify information about your network environment and the various attack patterns you want to monitor. The file is called snort.conf (Rice. 5) and is located in the directory /etc/snort. It needs to be opened in any text editor (if your router doesn’t have one, download it using ipkg).

Rice. 5. Snort.conf configuration file.

Now you can configure all the necessary network parameters, including the name of the access point on which the IDS is running and the MAC addresses of the clients that you want to monitor. There are a lot of settings you can configure here, so review all of them carefully to make sure you don't miss anything.

In particular, look at the Wi-Fi-specific preprocessors in Snort Wireless. They include preprocessors to detect passive network scanning by programs like NetStumbler and MAC address spoofing attempts. We decided to consider important preprocessors separately.

Rice. 6. AntiStumbler preprocessor allows you to notify about recon attacks.

AntiStumbler. Programs such as NetStumbler and MacStumbler ( Rice. 6), use null SSIDs to detect access points. These SSIDs act as broadcasts and force other access points to send their SSIDs to the requesting node. This feature is useful when searching for available wireless networks. The AntiStumbler preprocessor recognizes that too many null SSIDs are being sent from one MAC address and may raise an alarm.
Note. This preprocessor does not allow the definition of programs such as Kismet, since they only passively listen to 802.11 frames and do not send requests.
DeauthFlood. This attack was described in detail in our material about WEP hacking. Used to disconnect hosts from access points and force a reconnection attempt, which provides additional packets for analysis during WEP cracking. In addition, the attack can be used to “denial of service” (DoS) of an access point. The DeauthFlood preprocessor recognizes this type of attack by counting the number of deauthentication frames per unit of time and, if necessary, raises an alarm.
AuthFlood. The attack is similar to the previous one, but the AuthFlood preprocessor detects too many authentication attempts, that is, attempts by clients to connect to the wireless network, which can be used as a DoS attack on the access point.
MacSpoof. One of the most effective ways restricting access to an access point is creating a list of MAC addresses of allowed clients. Unfortunately, an attacker can spoof their machine's MAC address and connect to the access point. The MacSpoof preprocessor checks packet numbers and, if any inconsistencies are detected, indicating a possible MAC address spoofing, raises an alarm.
RogueAP. Alien (“enemy”) access points are disguised as regular ones so that the user mistakenly connects to them and transfers any personal data. This preprocessor not implemented yet, however, in future releases it will be able to report the proximity of other people's access points.

In addition, Snort Wireless includes many predefined rules for a huge number of situations. Depending on your network configuration, some of the rules may be very convenient. For example, all web rules, if a web server is running on your network. To activate a rule, simply uncomment the corresponding line in the Snort configuration file. Individual rule sets are saved in a directory by default /etc/snort/rules, and any of them can be viewed using a text editor. The rules in the sets are set in exactly the same way as in Snort itself. By the way, following the examples, you can easily write a rule yourself.

Rice. 7. The Snort rule detected a port scanning machine.

In progress

When the file snort.conf ready, you can launch Snort. At startup, you can specify many parameters that determine everything from output to operating mode. First, let's run Snort with the following parameters (in the Telnet options).

snort -D -A full

This command runs Snort as background process, so you can continue to work with the shell in peace. When an alarm is triggered, complete information will be recorded in the log.

Now that Snort is working, you can think of additional ways to secure your wireless network. Let's say you can contact Kismet- a utility similar to Snort that can be deployed as an additional intrusion detection system. Snort works only at the third layer of the OSI model - the network layer, which is responsible for IP and other traffic. And Kismet works at the second level - the channel level, responsible for Ethernet frames. Thus, deploying both systems in pairs will significantly increase overall security.

Rice. 8. Kismet at work.

You can configure Snort to write logs to a database, making further analysis easier. Daniel Walther wrote management on how to set up recording in MySQL databases and PostgreSQL. If you are using Gentoo Linux on a machine that acts as an access point, then you can go further: install Apache and configure the display of logs via the web. On the website Gentoo Wiki can be found detailed description similar setting.

Rice. 9. View Snort logs via MySQL, ACID and Apache.

Conclusion

We have only touched on the basic principles of how Snort works. In principle, based on the materials in the article, you can configure the system on an access point. However, Snort has many more features than described in the article. In particular, you can create rules independently, which will help integrate Snort deeper into the network.

Finally, don't forget that for effective protection The wireless network needs to keep both Snort and rules updated. Don't forget to visit regularly Snort Wireless, and also ipkg package tracker(for OpenWRT installations) or Snort rules page(for the rest).

Like other security tools, Snort is not a panacea for protecting your network. This is just one of the bastions of your fortress. But in the defense complex it works very well.

The article will consider an example of implementing an IDS system based on OS Debian and Snort for monitoring the internal network perimeter, including the following subsystems:
— Snort intrusion detection service;
— MySQL database server for storing records of attack events, received from Snort;
— interface for analysis, processing and visualization of Snort events (nginx, php5-fpm, BASE).

Installation and initial setup

Network interface optimization

Let's optimize network interfaces using the ethtool utility. To avoid network interface failures under heavy loads, let’s disable the CPU load reduction functions:

# apt-get install ethtool
# nano /etc/rc.local

Ethtool --offload eth1 rx off tx off ethtool -K eth1 gso off ethtool -K eth1 gro off ...

where “—offload eth1 rx off tx off” — disables checksum detection for incoming and outgoing packets; and “gso (generic segmentation offload) off” and “gro (generic receive offload) off” disable the function of transmitting and receiving a packet without CPU participation.

Database preparation

All information about attacks recorded by Snort will be stored in the MySQL database. Let's perform its initial setup:

# mysql -u"root" -h"MYSQL_SERVER_IP" -p"ROOT_PASSWORD"

Mysql> create database snort; mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@"SNORT_SERVER_IP_ADDRESS"; mysql> SET PASSWORD FOR snort@"SNORT_SERVER_IP_ADDRESS"=PASSWORD("SNORT_USER_PASSWORD"); mysql> exit;

Installing Snort

After the initial database setup, let's begin installing Snort with MySQL support:

# apt-get install snort-mysql

During the installation process, you must specify the Snort launch mode (boot by default), as well as interfaces and network addresses internal network. If necessary, you can specify multiple interfaces or addresses separated by a space. For example:

Eth1 eth2 eth3 192.168.1.0/24 192.168.2.0/24 192.168.3.1/32

We activate the “promiscuous mode” mode, allowing Snort to view the contents of packets passing through the interfaces, and also specify the parameters for connecting to the database.

Let's create the Snort database structure:

# cd /usr/share/doc/snort-mysql
# zcat create_mysql.gz | mysql -u"snort" -h"MYSQL_SERVER_IP" -p"SNORT_USER_PASSWORD" snort

When finished, delete the file:

# rm /etc/snort/db-pending-config

and let's start setting up the web interface.

Setting up a web server

We use a combination of nginx and php5-fpm as a web environment. To build graphs you will also need the php5-gd component.

# apt-get install nginx-light php5-fpm libphp-adodb php5-gd php-pear
# pear install --alldeps Image_Canvas channel://pear.php.net/Image_Canvas-0.3.5
# pear install --alldeps Image_Graph channel://pear.php.net/Image_Graph-0.8.0

Let's set TIMEZONE in php5-fpm settings:

# nano /etc/php5/fpm/php.ini

Date.timezone = Europe/Moscow

and also replace the line:

Error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

Error_reporting = E_ALL & ~E_NOTICE

Let's configure vhost:

# cd /etc/nginx/sites-enabled
# mv default snort
#nano snort

Server ( listen 8080; server_name snort; root /var/www/snort-base; index index.php; location @rewrite ( rewrite ^/(.*)$ /index.php?_url=/$1; ) location ~ \. php$ ( fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include /etc/nginx/fastcgi_params; ) )

Visualization of attacks using BASE

To visualize detected attacks, install BASE (Basic Analysis and Security Engine):

# wget http://sourceforge.net/projects/secureideas/files/BASE/base-1.4.5/base-1.4.5.tar.gz -qO- | tar xvzpf - -C /var/www/ && mv /var/www/base-1.4.5 /var/www/snort-base
# chmod -R 0770 /var/www/snort-base && chown -hR www-data:www-data /var/www/snort-base

Let's restart web services:

# /etc/init.d/php5-fpm restart
# /etc/init.d/nginx restart

Let's connect to BASE and perform initial initialization:

Let's run snort:

# service snort start

Now attacks recorded by Snort will be saved in the database and accessible through the BASE web interface.

At this point, the process of installation and initial configuration of the system can be considered complete.

Advanced Snort setup

I’ll start with a quote: “The main problem of information security, as a rule, is not associated with the presence of information security systems, but with the processing and analysis of the results of their work.” Let's try to figure out how and by what criteria Snort generates events and optimize their output and processing, eliminating all unnecessary things.

Snort configuration files are located in the /etc/snort directory. Information about the interfaces that Snort listens on, as well as network addressing information specified during installation of the utility, is stored in the snort.debian.conf file. Data for connecting to the database is in the database.conf file. Information about Snort rules is in the snort.conf file. Let's take a closer look at it.

snort.conf

The configuration file consists of sections:

Let's look at the main sections.

1. Network settings and variables
In this category, you can indicate, for example, network addresses of the internal and external networks, services used in our network, as well as group such services or hosts, facilitating subsequent parsing of events.

In addition, the section indicates the location of the Snort rules directory, as well as White and Black sheets. We'll come back to this a little later.

Var RULE_PATH /etc/snort/rules ... var WHITE_LIST_PATH /etc/snort/rules var BLACK_LIST_PATH /etc/snort/rules

2. Decoders
One of the first processes that Snort performs on a packet is processing by decoders, whose task is to determine the base protocol in the packet (ETHERNET, IP, TCP, etc.), however, the contents of the packet are not processed, but are transferred for further processing to preprocessors and detection engines.

Example. Let's exclude packets with incorrect IP options from the decoder:

Config disable_ipopt_alerts

and packets addressed to the DNS server:

Config ignore_ports: 53

3. Setting up the detection engine
The detection engine can use PCRE, a Perl-compatible pattern search library. IN this section You can optimize the search parameters, as well as its method.

5. Setting up preprocessors
I should have announced this at the very beginning, but I’ll tell you now - Snort can work in 2 modes - inline (IPS) and promiscuous mode (IDS). In the first case, Snort can control packets passing through it (change, block), in the second, it can only monitor and alert in case of suspicious activity. In the preprocessor settings, some options work only in inline mode, for example, the preprocessor normalize_ip4 option normalizes (so to speak) packets - corrects TTL, TOS, etc. Since in the context of this article we are talking about IDS, we will omit such options.

Preprocessor works directly with the contents of the package, using sets of rules such as http_inspect_server, which defines the http method, ports, the need for cookie analysis, valid special characters, etc. Profiles for web servers are also available.

6. Output settings
Snort has quite flexible output functionality in syslog, unified2, prelude, tcpdump, etc. format.
By default, data is written in tcpdump (pcap) format to the tcpdump.log file. Let's comment out the line:

Output log_tcpdump: tcpdump.log

It would be a good idea to set up line-by-line logging of alerts to a file using alert_fast:

Output alert_fast: snort.log 10M

But, since we have logging configured in MySQL, this section is not very relevant for us.

7. Enabling/disabling Snort rules
This section allows you to enable and disable Snort rules. The $RULE_PATH variable defined in the first section is used as the directory for placing the rules. So, we've looked at the config, let's try to figure out the rules.

Snort rules

As we understand, the rules are located in the /etc/snort/rules directory. Let's look at the example of an alert for sending multicast requests:

Having expanded the alert record, we determine the sid of the rule that generated the alert.

In this case, sid is 527. Let's search for the rule:

# grep "sid:527" -R /etc/snort/rules/

/etc/snort/rules/bad-traffic.rules:alert ip any any -> any any (msg:"BAD-TRAFFIC same SRC/DST"; sameip; reference:bugtraq,2666; reference:cve,1999-0016; reference:url,www.cert.org/advisories/CA-1997-28.html; classtype:bad-unknown; rev:8;

Let's look at the rule:

To exclude a host from the rule, just add!. Let's exclude the multicast address from the rule:

Alert ip any any -> ! any (msg:"BAD-TRAFFIC same SRC/DST"; sameip; reference:bugtraq,2666; reference:cve,1999-0016; reference:url,www.cert.org/advisories/CA-1997-28.html; classtype:bad-unknown;sid:527;rev:8;

Let's restart Snort:

# service snort restart

Let's consider another example - an attempt to access the backup directory on a web server:

The rule looks like this:

Alert tcp $EXTERNAL_NET any ->

Let's add administrator hosts to the exception:

Alert tcp! $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC backup access"; flow:to_server,established; uricontent:"/backup"; nocase; classtype:attempted-recon; sid:1213; rev:5;)

You can also specify the administrators' IP addresses as a variable in snort.conf and use such a variable to exception the rules. In addition, Snort uses white\black sheets in which you can specify IP addresses of hosts and networks. Example:

Preprocessor reputation: \ blacklist /etc/snort/default.blacklist whitelist /etc/snort/default.whitelist

P.S.
The standard set of Snort rules (community-rules) is distributed free of charge, an expanded set containing the most current signatures of known attacks is available for a paid subscription.
Detailed manual for Snort at English can be found at the link.
That's all! If you have any additions or comments, I’m happy to discuss them in the comments.

Snort for Windows requires Windows 2000 or XP; execution is not possible on NT, 98 or 95. The WinPcap libraries must also be installed. If they were installed for programs described earlier in this book, such as Ethereal or WinDump, then you are ready. Otherwise, you can take them to:

netgroup-serv.polito.it/winpcap

You may also need a MySQL database if you plan to import the results into a database. The specific MySQL configuration for this purpose is described in Analysis and Management Tools.

In order for Snort for Windows to perform as well as the UNIX version, you will need more powerful hardware. A machine with a 700 MHz processor is the minimum, but a 1 GHz or higher processor is better. You should also make sure that the Windows server is well protected, running a minimum of services and removing processor-intensive programs such as IIS. Use the Services window from the Administrative tools of Control Panel to check if anything unnecessary is running.

Installing Snort for Windows

To install Snort for Windows, grab the binary from the CD that came with the book or from http://www.snort.org. Do it on it double click mouse and it will install automatically. You will be asked if you need a specific database or additional modules such as the Responsive module.

Setting up Snort for Windows

The setup process for the Windows version of Snort is quite similar to the UNIX setup. All configuration and rules files are located in the same relative subdirectories. Enter the snort.conf file in the etc subdirectory of your Snort installation. Change and edit it as suggested in the UNIX version section. Then go to the rules files and make changes there. After this, you will be ready to launch Snort. Refer to the Running Snort for UNIX section for more information on using Snort for Windows, since all the commands are the same. Additional settings and placement recommendations are the same as for the original UNIX version.

Flamy Tech Coders Corner

Writing Custom Snort Rules

While the standard rulesets that Snort comes with provide sufficient protection against attacks with known signatures, you can create some custom rules specific to your network to get the most out of your intrusion detection system. You can write rules for:

tracking incoming and outgoing access for specific servers;
Search for specific file types or names specific to your organization;
monitoring certain types of traffic that are foreign to your network;

Learning how to write rules for Snort is easy; this will allow you to quickly increase the functionality of the program even in the absence of extensive programming knowledge. As you've seen, all Snort rules are simply text instructions in one of the rules files.

If you want Snort to detect specific behavior that would be considered suspicious on your network, you can quickly code a rule and immediately test that behavior. Snort rules are essentially single lines of text starting with an action (usually alert) followed by several arguments. IN latest version(2.0 and above) you can add multiple lines by simply placing a \ (backslash) at the end of every line except the last one. In more difficult cases you can also call other programs using the enable instruction. But in its basic form, a Snort rule has two parts: a header and parameters. Below is an example of a rule.

alert tcp any any 192.168.0.0/24 \ (content:"|00 05 A4 6F 2E|";msg: "Test Alert")

The title is the part before the first parenthesis. This instruction contains an action (in our case - alert), a protocol, as well as addresses and ports of the sender and recipient. The action will be executed if the condition specified by the rule is true. In this case, an alarm will be generated. Other options are Log, Pass, Activate and Dynamic.

Protocols can be tcp, udp, icmp or ip, which means any IP protocol. (In the future, non-IP based protocols such as IPX may be supported. The source and destination ports are self-explanatory. The source address comes first and is specified in standard slash notation for the IP range. You can also list multiple individual addresses and networks, separating them with a comma without spaces and enclosing them in square brackets, for example: alert tcp any< 80 \ (content: "|00 05 A4 6F 2E|"; msg : "Test Alert";)

This instruction is focused on traffic coming from any address, directed to machines with addresses 192.168.1.1, 192.168.1.5 and 192.168.1.10 on port 80. Assuming these are your web servers, the above rule will look for traffic going there that contains the specified hexadecimal data in the content section.

The second part of the Snort rule is the options that specify additional details of the detected traffic. You can search by a set of fields in the TCP/IP header (see descriptions in "Network Analyzers") or by the packet payload. Each option must be followed by quotation marks and the value being sought. You can add multiple options by separating them with a semicolon. The following are valid options.

msg	Provides a text description of the alarm
logto	Writes the package to a user-specified file instead of the standard output file
ttl	Checks the value of the TTL field in the IP header
tos	Checks the value of the TOS field in the IP header
id	Compares the value of a field fragment ID in the IP header with the specified value
ipoption	Looks for IP option fields with specific codes
fragbits	Checks fragmentation bits in the IP header
dsize	Compares the packet payload size with specified value
flags	Checks TCP flags against certain values
seq	Compares a TCP sequence number field to a specific value
ack	Checks a TCP acknowledgment field against a specific value
itype	Checks an ICMP type field against a specific value
icode	Checks an ICMP code field against a specific value
icmp_id	Checks the ICMP ECHO ID field against a specific value.
icmp_seq	Checks the ECHO ICMP sequence number against a specific value
content	Looks for a specific pattern in the packet payload
content-list	Looks for a specific set of patterns in the package payload
offset	Modifier for content option. Specifies the offset to start pattern matching
depth	Modifier for content option. Sets the maximum search depth for pattern matching
nocase	Compares the previous content chain in a case-insensitive manner
session	Output application level information for a given session
rpc	Monitors RPC services to identify specific application/procedure calls
resp	Active response. Closes a connection (for example, by breaking it)
react	Active response. Responds with programmed behavior (for example, blocking certain Web sites)
reference	External attack link IDs
sid	Snort Rule ID
rev	Rule version number
classtype	Classification ID of the rule
priority	Rule Severity ID
uricontent	Pattern matching on the URI portion of the package
tag	Additional steps for logging for rules
ip_proto	Protocol value in IP header
sameip	Determines if the source and destination IP addresses are not equal
stateless	Applicable regardless of flow state
regex	Pattern matching using metacharacters
byte_test	Numeric comparison
distance	Forces relative pattern matching to skip a certain number of bytes in a packet.
byte_test	Numeric pattern matching
byte_jump	Numerical pattern matching and bias adjustment

More detailed information You can find information about each rule option in the online help. Below are some examples of using these options to create custom Snort msg rules, the label that appears in signal logs. The fact is that we are interested in any traffic on any port. Any access to accounting servers originating from outside world, since any external traffic to these servers is expected to be considered malicious.

Example 2 of an individual rule

Based on the scenario in Example 1, assume that you should allow some external access to the accounting servers, but still ensure that no one copies certain files. Let's assume that there is a file called payroll.xls that contains all the payroll data (a top secret file, both inside and outside the organization). You can write a rule that will monitor any traffic, internal or external, directed to these servers and containing the name of a secret file. This can be done using the content option, which searches the actual contents of the packages. The rule will look something like this:

alert tcp! any< any (content: "payroll.xls";msg: "Попытка доступа к файлу зарплат")

Note that the operation sign! again means that we are interested in traffic directed to the accounting servers from anywhere other than those servers. This eliminates the signaling of inter-server traffic. Note also that the \ symbol allows you to write multi-line rules, and the content option allows you to search for payroll.xls text in packages. As a result, server machines can access the Internet, but if this specific file will ever be unloaded from them, you will be notified about this.

Using other options, you can write rules to detect almost any type of traffic. If your rules may be of interest to other organizations, it is worth sending them to the Snort developers for inclusion in the official set of distributed rules. If you decide to do this, try to use all means documenting, such as msg, sid, rev, classtype and priority. Also test your rules thoroughly to ensure they actually cover all the activity you're trying to catch and don't produce false positives.

Welcome back my hackers!

In the world of information security, the most common intrusion detection system (IDS) that you will eventually encounter is Snort. As you most likely already know, IDS works similarly to antivirus software - it tries to identify malicious software on your network and alerts you to its presence.

Snort, created by Martin Roesch in 1999, became so popular that networking giant Cisco acquired it in 2014. Therefore, you are likely to see it on almost all Cisco devices in the near future. And since Cisco is the manufacturer of the most popular network devices, you will soon find Snort everywhere.

Even if your organization never uses Cisco products (which is unlikely) or Snort, you should understand how this IDS works, since most other intrusion detection systems work in a similar way.

We've published a few articles about Snort recently, but we thought it would be good to do a whole series of articles on this topic. In this series, we'll look at how to use Snort from start to finish, including installing, configuring, managing output, writing rules, and monitoring alerts.

Let's get started!

Method 1: Install Snort from the repositories

Installing Snort is easy if you have Snort in your system's repositories. Unfortunately, it's no longer available in Kali, so our first step is to add a repository that has Snort. In this case we will add some Ubuntu repositories.

Open the file /etc/sources.list. We can do this using any text editor (here we will use Leafpad).

Kali> leafpad /etc/apt/sources.list

As you can see in the screenshot above, we have added several Ubuntu repositories, which are also listed below. Since Ubuntu is a fork of Debian (the main Linux distribution on which Kali is built), most Ubuntu packages will work on Kali.

Deb http://ch.archive.ubuntu.com/ubuntu/ saucy main limited deb-src http://ch.archive.ubuntu.com/ubuntu/ saucy main limited deb http://httpredir.debian.org/debian jessie main deb-src http://httpredir.debian.org/debian jessie main

In order to update the list of our repositories, after saving the file, we need to update the list of packages themselves. We can do this by typing in the console:

Kali> apt-get update

Once our packages are updated, we can install the Snort package from the repository using the command:

Kali> apt-get install snort

That's all there is to it. Snort is installed and ready to go! To check this, simply enter in the console:

Kali> snort -V

In our case, Snort displayed its version number (in this case, 2.9.2).

Method 2: Install Snort from source

Installing Snort from source is a more complex and time-consuming task, but the advantage of this method is that Snort will be compiled specifically for your specific hardware and software configuration.

This will give you better overall performance. As with any IDS, performance is critical. Lower IDS performance will either slow down your overall networking ability or result in packet drops. In the first case, you will have unhappy clients or users, and in the second, you are putting your network security at risk.

When using Snort in a secure production environment, installing from source is highly preferable. Additionally, installing from source ensures that you install latest version Snort. Many of the repositories contain older versions. Current version Snort is 2.9.8, and in the repositories it is 2.9.2. A small difference, but when we are trying to protect the “treasure”, every detail will be useful.

Let's start by creating a directory in Kali where we'll upload the source code.

Kali> mkdir snort_source

Then let's go to this directory

Kali> cd snort_source

Before you download Snort, you must install the Data Acquisition library or DAQ. DAQ has several dependencies that we need to install.

Kali> apt-get install -y bison flex

Now we can download and install DAQ from the Snort website.

Kali> wget https://www.snort.org/downloads/snort/daq-2.0.6.tar.gz kali> tar -xvzf daq-2.0.6.tar.gz

Then let's go to the daq directory.

Kali> cd daq-2.0.6

Finally, let's configure DAQ and call the make command.

Kali> ./configure kali> make kali> install kali> wget "https://snort.org/snort/snort-2.9.8.0.tar.gz"https://snort.org/snort/snort-2.9.8.0 .tar.gz

After it is downloaded, you will need to unpack it. (To receive additional information For information about the tar command, see our Linux Basics article).

Kali>tar -xvzf snort-2.9.8.0.tar.gz

Let's go to the directory where the new Snort files are located.

Kali> cd /snort-2.9.8.0

You need to configure it.

Kali> ./configure --enable-sourcefire

After this we need to use the make command, which determines which of the components source code must be recompiled, and then gives the command to do so.

Kali>make

And finally, we do the installation (make install). This command takes the recompiled program components and places them in the appropriate directories.

Kali> make install

Since we installed new library files during the installation process, we need to update the shared libraries. To do this, enter the following command in the console:

Kali>ldconfig

To run Snort from any directory, you can make a symbolic link to the binary (executable) files in /usr/local/bin/snort and place it in the /usr/sbin directory, calling it snort. Since /usr/sbin is in our PATH, we can enter Snort anywhere on the operating system to start using IDS.

Kali > ln -s /usr/local/bin/snort /usr/sbin/snort

Let's check if Snort installed normally. To do this, type in the console:

Kali> snort

As we can see, Snort has started and is working successfully in packet dump mode or the so-called sniffer mode.

Now that we have successfully installed Snort, let's continue configuring it to detect malware. That will be in our next article in this series, so be sure to check back!

Disclaimer: This article is written for educational purposes only. The author or publisher did not publish this article for malicious purposes. If readers would like to use the information for personal gain, the author and publisher are not responsible for any harm or damage caused.