Success

How to use snort windows program. Intrusion detection system for Dummies. Installation and Configuration of SNORT. Getting help with snort command line syntax

Billions of data packets are transmitted across corporate networks every day. Some of them are dangerous; The authors of such packages took special measures to bypass firewalls and break through the defense lines along the perimeter of networks, disrupting the operation of all systems encountered along the way. The destructive effects of packaged attacks such as Code Red, Nimda, SQL Slammer and MSBlaster are well known. All of these malware exploit trusted protocols (such as HTTP) or network traffic from Microsoft systems. Such protocols cannot simply be taken and blocked, so administrators usually try to capture dangerous traffic as quickly as possible using unauthorized access detection systems, Network Intrusion Detection System (NIDS), in order to respond to the threat in time.

There are several NIDS available commercially, varying in capabilities and cost. In general, they all work successfully. All the commercial packages I've encountered have been excellent. But what should organizations with modest budgets do if intrusion detection is not a priority? For such cases, there is Snort - a powerful free NIDS package. Unlike many open source packages, it is compatible with Windows.

Getting to know Snort

Snort's original developer, Martin Resch, made the program available to the open community under the terms of the GNU General Public License (GPL). The history of this package began in 1998, and since then it has proven its reliability more than once. Thanks to the contributions of open community members and network administrators around the world, Snort has become a very powerful product. The current version provides real-time network traffic analysis and IP traffic logging at Fast Ethernet and Gigabit Ethernet speeds.

Michael Davis ported Snort 1.7 to the Win32 platform, making it available to the Windows community. Chris Reid then took on the task of compiling new versions of Snort into ready-made executables that could be easily deployed in a Windows environment.

Administrators unfamiliar with NIDS may think of the tool as a special type of network analyzer. NIDS examines every packet passing through the interface, looking for known patterns in the payload where malicious code is typically hidden. With Snort, you can perform search and match operations on every packet passing through an organization's network and detect many types of attacks and illegitimate traffic in real time.

Snort Requirements

To run Snort, you need a Windows computer equipped with at least one network adapter. It is better to have two network adapters, one connected to the controlled network and the other to the production network; the latter forwards the reports. Snort is compatible not only with Windows 2000 Server and later versions, but also with Windows XP Professional Edition, XP Home Edition and Windows 2000 Professional. No server license is required. I connect my XP Pro laptop to many client networks every day and usually run Snort as a service. This way, the program runs in the background, detecting any attacks on my system coming from that client network. I use Snort as a portable sensor - the program acts as a NIDS for any port to which the laptop is connected.

In small networks, Snort can be deployed on an entry-level server. A dedicated high-power machine is not needed to detect unauthorized access attempts. For example, I've heard of FreeBSD-based Snort nodes with 1 GHz processors and 1 GB RAM successfully serving networks with 15,000 users and multiple T-3 WAN links. Thanks to the efficiency of Snort's source code, a very powerful machine is not required to run the program.

Where is the best place in the network to locate NIDS? The first thought is to place the device in front of the firewall. This is where NIDS will detect the most attacks, but the number of false positives will also be highest, and the administrator will receive a lot of useless warnings about the danger. You shouldn't worry about threats stopped by a firewall; it's more important to detect dangerous programs that get behind it. Therefore, it is better to place Snort behind the firewall anyway.

However, if users connect to the network through a VPN connection (over the Internet or wireless link), it makes sense to place the NIDS further behind the firewall, such as behind a VPN server or concentrator, where packets are decrypted as they exit the VPN tunnel. Otherwise, NIDS will not be able to counter malware embedded in VPN traffic, since the analyzed packets will be encrypted. The same applies to encrypted SMTP traffic, encrypted .zip files attached to email messages, and other types of encrypted data.

Ideally, NIDS should be placed far enough behind any components that encrypt traffic and close enough to the network perimeter to analyze traffic on as many segments and subnets as possible. In a switched network environment, a switch typically requires a diagnostic port to collect all packets passing through the network. As a result, NIDS has convenient access to all network traffic.

Now that you're familiar with Snort and know its hosting requirements, you can install and test NIDS. For more information about Snort, see the documents linked in the "Web Resources" sidebar. This process consists of seven stages:

Installing WinPcap
Installing Snort
Testing Snort
Setting up Snort
Setting rules
Setting up alerts and logs
Run as a service

Stage 1. Installing WinPcap

Snort is essentially a promiscuous-mode network analyzer, so it requires driver support. This support is provided by WinPcap. Loris Digioanni created WinPcap by porting the libpcap packet capture driver, widely used among Unix users, to the Windows environment. WinPcap includes a kernel-level packet filter, a low-level DLL (packet.dll) and a high-level system-independent library (wpcap.dll, based on libpcap 0.6.2).

WinPcap can be downloaded from http://winpcap.polito.it. The driver is compatible with Windows Server 2003, XP, Windows 2000, Windows NT, Windows Me and Windows 9x. WinPcap also supports the open-source Ethereal packet sniffer, which can be obtained from . Using Ethereal, you can verify that Snort is installed correctly.

After downloading the WinPcap installation file from the network, you just need to go through several screens of the installation procedure. The biggest effort on the part of the user is required by the screen where you must agree to the license terms.

Step 2: Install Snort

The next step is to install Snort. The latest version can be found on the CodeCraft Consultants Web sites ( http://www.codecraftconsultants.com/snort.aspx) or Snort.org ( http://www.snort.org). I recommend downloading Snort from CodeCraft Consultants as you can get a self-extracting executable from that site. The program even guides the user through the basic steps of installing Snort on a computer. The latest version of Snort 2.1.1, build 18 was used in preparing this article. Updated versions have since been released.

When you run the installation program, in the first dialog box you must select the database configuration mode for storing the results. If you are using MySQL or an ODBC-compatible database, you can accept the default mode (Figure 1). But if you are going to store protocols in a Microsoft SQL Server or Oracle database, then you need to select the appropriate mode and make sure that the required client program is available on the machine. The default mode was used in preparing this article.

The next step is to identify the Snort components that you want to install. The standard set (Screen 2) is fine, so I recommend accepting it and clicking Next. In the Choose Install Location dialog box, you must specify the directory where Snort will be deployed. After entering the directory name, click Next to complete the installation process.

Screen 2: Selecting Installation Components

Step 3: Test your Snort installation

After completing the installation process, Snort needs to be tested. By default, the Snort executable needs to be told two locations: where to write logs and where to find the configuration file (snort.conf). This information is provided by the user when running Snort from the command line using the -l and -c switches, respectively. For example, the command

Snort -l F:snortlog -c F:snortetcsnort.conf -A console

tells the program that logs should be written to the F:snortlog directory and that snort.conf is located in the F:snortetc directory. The -A switch specifies the method for transmitting warnings generated by the program. In this example, warnings are displayed on the console screen so that the administrator can verify that Snort is working correctly. Please note that in the article the command is printed on multiple lines, but in the command window it must be entered on one line. The same applies to the other multiline commands in this article. Many Snort command line switches are case sensitive, so you must enter commands exactly as they are typed.

If the system has multiple network interfaces, then by default Snort listens on the first interface it discovers. If the order of network interfaces on a machine is unknown, you can run the Snort command with a single -W switch. Snort lists the names and numbers of network interfaces in the order in which the program detects them. To force Snort to use a specific network interface, you must enter the -i switch with the interface number when starting Snort. After running Snort, the screen will display information similar to the one shown in screen 3 .

Once you run Snort, you can test its sensitivity by sending specially prepared traffic to NIDS. One of the easiest ways to trigger a warning is to call the command interpreter (cmd.exe) on the remote machine as part of an HTTP URL request (a common technique for Code Red and Nimda worms). To simulate this phase of the attack, access any URL and append the characters /cmd.exe to the end of the request. For example, in response to a call to http://www.a-website-that-I-can-trust.com/cmd.exe, Snort should display a warning in the command window similar in appearance to the first three warnings on screen 4. These messages are written to the F:snortlog log.

Target Web sites for testing should be selected with care. From a technical point of view, most Web site administrators would consider such actions to be a hacking attempt. This attempt will not succeed (unless there are serious errors in the server configuration), but I recommend testing only with your own server or a trusted server whose administrators are aware of the testing.

If testing is not possible, another way to test Snort is to send an unusually long echo request over the network to a server or computer with Snort running. For example, you can use the Ping command

Ping -l 32767 ip_address

where ip_address is the IP address of the target server or Snort computer. This command must send a very long packet (exact length - 32 KB), which is clearly unusual for a Ping command. Snort should detect this package, as seen in the bottom eight warnings on screen 4 .

If you receive warnings, you can begin configuring Snort for your specific conditions. Otherwise, you need to go back to the installation procedure and check if any step was skipped.

Step 4: Setting up Snort

Basic Snort configuration data is stored in the snort.conf file, which by default is located in the %systemdrive%snortetc directory. The file can be left in this folder or moved to another if you specify the path to the program on the command line.

A detailed description of all the parameters present in snort.conf could fill an entire magazine issue, since Snort is an amazingly powerful program. For now, we will consider only its main parameters.

To distinguish incoming traffic from outgoing traffic, you need to tell Snort the hosts and IP addresses of your enterprise network. To enter this information, the HOME_NET variable must be set in the snort.conf file. You should find the line

Var HOME_NET any

and replace it with a range of IP addresses. You can specify one range, for example

Var HOME_NET 192.168.0.1/24

or several ranges. When specifying multiple ranges, you must enclose the set of ranges in square brackets and separate each range with a comma. You cannot enter spaces between IP address ranges. For example, the line

Var HOME_NET

tells Snort that subnets 10.0.1.0/24, 10.0.2.0/24, and 10.0.3.0/24 belong to the enterprise network. By default, Snort treats all other addresses as external. You can explicitly specify which networks should be considered external by setting the EXTERNAL_NET variable. In the snort.config file you need to find the line

Var EXTERNAL_NET any

and replace it with the IP address of the network that should be considered external. However, it is generally best to leave the EXTERNAL_NET variable set to any to begin with.

After spending some time, you can identify the types of servers your enterprise has and their locations. This information is contained in the DNS_SERVERS, SMTP_SERVERS, HTTP_SERVERS, SQL_SERVERS, and TELNET_SERVERS variables in the following lines of the snort.conf file:

Var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var TELNET_SERVERS $HOME_NET var SNMP_SERVERS $HOME_NET

By default, all six server variables are set to $HOME_NET; this means that Snort will monitor all types of attacks on all systems in the HOME_NET range. This configuration is quite acceptable for a small network whose administrators tolerate a certain number of false alerts. But for monitoring heavy traffic, it is advisable to fine-tune Snort to check only part of the signatures for certain nodes. It makes no sense to protect a Web server running only Microsoft IIS from SQL buffer overflow attacks. To define a specific host class, you must replace $HOME_NET with a range of target server IP addresses according to the format used for the HOME_NET variable. For example, for the DNS_SERVERS variable, instead of $HOME_NET, you should substitute the range of IP addresses of DNS servers.

Tuning accuracy can be improved by identifying the ports used by servers for specific applications. For example, if Web servers use a special port 8080 for HTTP traffic instead of port 80 (this port is typically used for Web servers and browsers), you can configure Snort to monitor port 8080 by changing the HTTP_PORTS variable. In snort.conf you should find the line

Var HTTP_PORTS 80

and replace it with the line

Var HTTP_PORTS 8080

Similarly, you can change the ports for Oracle (defined by the ORACLE_PORTS variable) and other applications. Like the HTTP_PORTS variable, ORACLE_PORTS defaults to 80. If the server uses port 1521 instead, the string would look like

Var ORACLE_PORTS 1521

Thus, there are many settings that can be configured in the snort.conf file. You should review snort.conf to find the settings that are most important for your specific environment and configure them accordingly.

Stage 5. Setting the rules

One of the lines in snort.conf contains the RULE_PATH variable. An example of this line:

Var RULE_PATH ../rules

The ../rules option specifies that the rules (i.e. signatures) can be found in the rules directory, which is at the same level as the Snort binaries in the directory structure. So, for example, if you install Snort in the generic folder F:snort, the Snort binaries are in F:snortin and the rules are in F:snort ules. You can change the RULE_PATH variable if you wish, but the default option is fine.

Rules are the basis of Snort. They are sequences of bytes, attack signatures, and other types of data that, when detected, generate an alert. Snort has more than 1,500 ready-made signatures.

What does the rule look like? The rule for cmd.exe that was violated during the Snort test looks like this: alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS cmd.exe access"; flow:to_server, established; content: "cmd.exe"; nocase; classtype:web-application-attack; sid:1002; rev:5;). Let's look at the main components of the rule. The $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS link specifies that only traffic coming into the network from outside (as defined by the EXTERNAL_NET variable) should be analyzed. The content: parameter specifies the search for a sequence of cmd.exe characters in the data stream. When Snort detects such a sequence, it generates a warning specified by the msg: parameter.

As you can see from the cmd.exe example, the rules are mostly simple. You can create your own rules for any type of traffic. For example, if you want to detect unauthorized attempts to remotely access a directory on a machine through the command interpreter, you can search for volume in drive or volume serial number on ports where they are rarely found, such as outbound ports. Thanks to the flexible approach to assigning rules, administrators are provided with extensive configuration options for Snort.

Snort's 1,500 rules are stored in different files according to the types of data being analyzed. For example, the rule for cmd.exe is in the file web-iis.rules. If the enterprise does not use IIS, then the program does not need to detect IIS attacks. The web-iis.rules file can be easily removed from the configuration entirely by finding and commenting the line

Include $RULE_PATH/web-iis.rules

in the snort.conf file. To make a line a comment, precede it with a (#) symbol:

# include $RULE_PATH/web-iis.rules

By default, some types of rule files (for example, icmp-info.rules, chat.rules) are represented by comments in snort.conf. The default configuration of rules in snort.conf is quite good. After activating blocked rules, the program usually generates many unnecessary warnings.

Some files contain a number of useful rules, but a few rules generate too many unnecessary warnings. To disable a particular rule, you need to mark the corresponding line in the rules file as a comment. In the future, Snort will ignore this rule when working with the file.

When new threat sources appear, the rules file must be updated. The best resource for new rules is Snort.org. This Web site does not have an automatic update service, so the administrator will have to regularly check with it for updates when a new threat arises.

Step 6: Configure Alerts and Logs

As noted, Snort provides recording of information in MySQL, SQL Server, Oracle and ODBC-compatible databases. Simply select the appropriate database type during the Snort installation process. In order not to excessively increase the length of the article, we will consider standard logging modes using a text file and the function of writing messages to the Windows event log.

When running NIDS using the Snort command, the -A console switch causes warnings to be displayed on the screen. To forward messages to a text file, you should replace this switch with -A fast or -A full, depending on your preferred logging mode. The full parameter displays a detailed description of the threat in several lines of a text file named alerts.ids in the directory, the path to which is specified by the -l switch. This type of logging provides comprehensive details, but can be difficult to understand if there are a lot of events being logged on the network. In such “noisy” networks, it is recommended to use fast mode to add one-line entries to alerts.ids containing the main characteristics of suspicious traffic. In my opinion, working with a text file in fast mode is easier than in full mode.

The current version of Snort provides logging to the Windows event log. Many organizations have already purchased centralized event monitoring, logging, and data collection tools, and this feature would be a great addition to the Windows environment.

To write warnings to the Application event log of the system on which Snort is running, use the -E switch instead of the -A switch (parameters are optional). Figure 5 shows what a Snort event (in this case, an attempt to access cmd.exe) looks like published in the Application log. The Windows event provides the same detailed information as the console screen.

NIDS is useless if the administrator looks at event logs (or text logs) once a week. If something happens on the network, the administrator must know about it immediately. A centralized monitoring and event processing system can send messages via email, pager and other communication devices. But if there is no such system, this is not a cause for concern. NETIKUS.NET offers a free EventSentry Light package that can be used to send alerts.

EventSentry Light is a trial version of EventSentry and can be downloaded from http://www.netikus.net/products_downloads.html. With EventSentry Light, you can configure your system to monitor event logs and automatically send detailed email messages about any Snort events recorded in the log. On screen 6 shows an email message about attempts to attack cmd.exe. I received this message from EventSentry Light a few seconds after the attack took place.

As mentioned above, Snort typically generates a ton of unnecessary messages that quickly fill up the event logs. This is something to keep in mind when choosing file sizes for event logs and how to rotate them. To prevent EventSentry Light from flooding your inbox with messages about minor events, you can create a filter to search for key strings. For example, I organized a search filter for a string in the text of messages.

Step 7: Run as a service

Once you're done, you can run Snort as a service instead of having to log into your desktop computer every time you want to run the program. If you run Snort with the /SERVICE and /INSTALL options (along with other command line options), Snort is configured to run as a Windows service and automatically starts with Windows without user intervention.

Next level: expansion modules

Snort is a fully featured application. However, in some cases the program needs to be expanded. For example, if several NIDS are deployed in different parts of the network, then it is convenient to manage Snort from the graphical interface. Such capabilities are implemented in the IDScenter extension modules from Engage Security and IDS Policy Manager from Activeworx. Sometimes it is necessary to analyze the information contained in messages. You can view and analyze stored data using the Analysis Console for Intrusion Databases (ACID) module developed at Carnegie Mellon University.

Reliable protection

Snort is a full-featured program that will not harm the company's budget. By combining Snort with a powerful event monitoring application such as EventSentry Light, you can proactively prevent attacks against your network.

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 the interfaces and network addresses of the 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;sid:527;rev:8;

Let's look at the rule:

In order 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.
A detailed manual for Snort in English can be found here.
That's all! If you have any additions or comments, I’m happy to discuss them in the comments.

1. What is IDS.

Today, when a lot of sites have appeared with descriptions of hacking, as well as articles, exploits, and programs on the same topic, attempts to hack servers have become much more frequent. After all, any user who imagines himself as a hacker can try a freshly downloaded exploit on you and gain control of your server. In reality, everything is not so easy, but still...

In order to find out about attacks, or simply to keep abreast of all the events happening on the server, many administrators look through logs every day. But when the log file, for example of the Apache web server, grows by 10 Mb per day, then you have to automate the process of monitoring server security. One solution is IDS - intrusion detection systems, the effectiveness of which has increased significantly over the past few years, and they are now an integral part of any network protection.

Of the many varieties of IDS (Intrusion Detection System), two can be distinguished: based on protocol analysis(identifying packages that do not meet standards), and based on signature analysis(the attack signature is searched in packets - a string (sample) indicating that a given packet belongs to malicious traffic. Such IDSs are called NIDS (Network Intrusion Detection System). In general, the principle of operation of NIDS can be described as follows: all traffic is analyzed for the presence of packets containing malicious data, and if such a packet is found, then various signaling actions are performed (a message is displayed on the console, mail is sent, written to the log, a Winpopup message is sent, etc.) Both types of IDS have their advantages and disadvantages, for example, protocol analysis is slower due to the transformation of the packet into a form accessible for analysis. But there are much fewer false alarms, since really real deviations from standards are recorded. IDS based on signature analysis are faster, and are also easy to configure and update (I saw a new vulnerability, added it to database, and your IDS will detect it.) But it’s better to use IDS based on two analysis methods, this will give a really excellent result.

2. Brief overview of IDS

At the moment, there are a huge number of IDS, each of which has its own qualities and disadvantages. I will give a brief description of some of them (this information about the programs is taken from the website www.opennet.ru, where you can also find all these IDS):

PortSentry

A program that allows you to detect and block attempts to scan UDP and TCP server ports in real time. Hidden attempts to scan ports are also detected (SYN/half-open, FIN, NULL, X-MAS, oddball).

A system for analyzing and tracking (logging) passing packets, such attacks as “buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts” are recognized. There is the ability to real-time notify the administrator when an attack is detected

Nidsbench

A system for testing a network for typical vulnerabilities and determining the reaction of the installed system for detecting unauthorized access attempts. There is a good selection of documentation on NIDS.

TCP/IP traffic monitor, capable of keeping logs of passing traffic, detecting port scans, flooding and some types of attacks.

A library for building NIDS systems, it emulates the TCP/IP stack of Linux 2.0.x, which allows you not only to intercept packets (a chaotic set of packets), as most sniffers do (for example, libpcap, tcpdump), but also to monitor individual sessions (for example, intercept SMTP traffic and separate each SMTP session) taking into account defragmentation and assembly of TCP packet chunks. Works under Linux, *BSD and Solaris.

The program allows you to track and place in a log file all data passing through the serial port.

These are not all IDS, and not even the most famous, but these are easy to find.

Of all these programs, Snort- the one I liked the most. Why? Here are its advantages: two analysis modes, by signature and analysis of protocols, easy installation and configuration of the program, small size and system requirements, identification of a huge number of attacks.

3. Installation and configuration of Snort

First, download Snort from the website www.snort.org. Here is a direct link to the latest version at the moment http://www.snort.org/dl/binaries/linux/snort-1.9.1-1snort.i386.rpm. There are also various modifications of Snort, for example with support for MySQL, postgresql, snmp, you can download all of this from the same site, and I chose our version of the program as the easiest to install.

Installation is quite simple:

rpm –i snort-1.9.1-1snort.i386.rpm

After this, all the necessary files will be copied to the system.

Now you need to customize the program for yourself, which is what we will do now... Let's go to the directory /etc/snort, here you can find signature databases (more precisely, they can be called the rules by which Snort identifies harmful traffic) and several configuration files, we need snort.conf. Here we set up variables like HOME_NET, EXTERNAL_NET and others... It won’t be hard to figure it out, since each option is accompanied by fairly clear comments, albeit in English. At the very end of the configuration file there are plug-in signatures; unnecessary ones can be commented out to improve performance.

Here's an example of my config:

# Step #1: Setting network related variables
# Change the IP to your local network addresses
# You can specify multiple ranges, separated by commas
var HOME_NET 192.168.168.0/24
var EXTERNAL_NET !$HOME_NET
var DNS_SERVERS $HOME_NET
var SMTP_SERVERS $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var TELNET_SERVERS $HOME_NET
var ORACLE_PORTS 1521
var HTTP_PORTS 80
var SHELLCODE_PORTS !80

# Path to signatures
var RULE_PATH /etc/snort

#We include the necessary files containing the classification of the detected attack and links to
# bugtrucks

Include classification.config
include reference.config

###################################################

# Step #2: Configuring the attack detection mechanism

Preprocessor frag2
preprocessor stream4: detect_scans, disable_evasion_alerts
preprocessor stream4_reassemble
preprocessor http_decode: 80 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace
preprocessor rpc_decode: 111 32771
preprocessor portscan: $HOME_NET 4 3 portscan.log
# I had to add this option due to some specific programs used in my
# networks that often caused false positives
preprocessor portscan-ignorehosts: 192.168.168.0/24
preprocessor arpspoof
preprocessor conversation: allowed_ip_protocols all, timeout 60, max_conversations 32000
preprocessor portscan2: scanners_max 3200, targets_max 5000, target_limit 5, port_limit 20, timeout 60

####################################################################

# Step #3: Specify what signatures we need

Include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/dns.rules
include $RULE_PATH/web-cgi.rules
# I left the next option for statistics - my server is regularly scanned for IIS bugs,
# More precisely, not my server, but a range of addresses, which I also fall into :)
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-client.rules
include $RULE_PATH/web-php.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/icmp.rules
include $RULE_PATH/netbios.rules
include $RULE_PATH/misc.rules
include $RULE_PATH/attack-responses.rules
include $RULE_PATH/mysql.rules

Include $RULE_PATH/pop3.rules
include $RULE_PATH/pop2.rules
include $RULE_PATH/other-ids.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules

Now you're ready to launch Snort. Write it in inittab and it will start along with the system.

4. Adding your own signatures

Snort is a very flexible and desktop-friendly IDS. One of its qualities allows us to add attack signatures ourselves (or as I said, it's more like rules). We have such rules in *.rules files. The syntax of the rules is quite simple:

ACTION PROTO IP_ADDR1 PORT1 DIRECTION IP_ADDR2 PORT2 [ (OPTIONS) ]

Let's look at the rule fields in more detail:

The Action field has three main directives that define actions when a network packet is detected that matches a certain rule: pass, log and alert.

pass- ignore the package

log- the packet must be passed to the logging procedure to be written to the log file

alert generates a notification when a packet matching a rule is found

Packet protocol, can have the following values: tcp, udp, icmp

As is clear from the name of the option, this field means the IP address. any allows you to specify all possible addresses. Symbol! inverts the condition, i.e. !192.168.168.0/24 means anything not on the 192.168.168.0/24 subnet. You can list multiple IP addresses separated by commas

In addition to a single port number, you can specify a range of ports separated by a colon, for example, 6000:6010, symbol ! inverts the condition, and any stands for all ports

DIRECTION

Determines the direction of movement of the package:

-> (one-way) - the rule will only apply to packets going from IP_ADDR1 to IP_ADDR2;

(two-way) - the direction of movement of the package does not matter

The parameters enclosed in parentheses are an optional part of the rule, but they define the text of the threat notification message, specify additional actions when the rule is triggered, and additional conditions for the compliance of analyzed packets with this rule. Parameters are separated from each other by a semicolon, and a parameter's keyword is separated from its argument by a colon.

Parameters that specify additional conditions for matching the rule:

ttl- sets the value of the TTL field in the IP packet header;

tos- sets the value of the TOS field in the IP packet header;

id- sets the value of the fragment number field in the IP packet header;

ipopts- sets the value of the IP packet parameters field;

fragbits- sets IP packet fragmentation bits;

dsize- sets conditions for the size of the IP packet;

flags- sets conditions for the presence or absence of certain TCP flags;

seq- sets the TCP packet segment number in the sequence;

ack- sets the value of the acknowledgment field in the TCP packet;

itype- sets the value of the ICMP packet type field;

icode- sets the value of the ICMP packet code field;

icmp_id- sets the value of the ICMP ECHO ID field in the ICMP packet;

icmp_seq- sets the ICMP ECHO packet number in sequence;

content- specifies the required pattern in the contents of the package, and not in the header (the pattern can be specified both in text form and in hexadecimal);

content-list- this parameter is similar to the content parameter, except that the list of searched templates is taken from the specified file;

offset- works in conjunction with the content option to determine the offset in the packet from which the content will be analyzed;

depth- similar to the offset parameter and determines the position in the packet to which the contents will be analyzed;

nocase- disables case sensitivity when parsing package contents;

rpc- this parameter allows you to more accurately specify the characteristics of program or procedural calls to RPC services.

As you can see, the listed parameters allow you to create rules for intercepting almost any packets that could somehow threaten security. And if you consider that Snort can intercept packets at the data link layer, then its use is especially interesting on hosts protected by a firewall, since packets dropped by the firewall will still be in Snort’s field of view.

Parameters whose values make sense if the analyzed package meets all the conditions:

msg- contains the text of the message;

logto- specifies an alternative file for writing the package contents into;

session- this parameter allows you to enable a very interesting feature of Snort - extracting user data from a TCP session, for example, for subsequent analysis of what commands the user entered during a telnet session;

resp- if the packet matches the rule, then Snort will perform one of the specified actions - for example, close the connection by sending a TCP-RST packet to one of the hosts.

react- blocks websites specified in the rule, closing the connection to them and/or sending a specified message to the browser from which an attempt was made to access the site.

Here are a couple of examples of creating your own rules:

If a request to the Napster server is detected, the connection is forcibly closed. As you can see, using Snort you can organize filtering of unwanted traffic more effectively than simply closing the corresponding ports on the firewall, since it is possible to introduce an additional condition on the contents of packets.

5. Testing Snort

To test the functionality of Snort, let's take a simple example. At the command line, type ping –s 65507. Now go to /var/log/snort, logs are stored here by default. Open the alert file and see the following lines:

[**] ICMP Large ICMP Packet [**]
01/06-07:37:37.119752 192.168.168.99 -> 192.168.168.9
ICMP TTL:255 TOS:0x0 ID:18479 IpLen:20 DgmLen:63028
Type:0 Code:0 ID:512 Seq:19456 ECHO REPLY

The first line tells us what action caused the alarm, in this case an ICMP packet that was too large. The second line shows the attack class and its priority (this information is determined from the classification.config file). The third line contains the time of the attack, as well as the IP addresses of the host that sent the packet, and the host to which the packet was intended. Next come the remaining fields of the packet, such as TTL, TOS - by which, by the way, you can determine the attacker’s OS, and others...

6. Conclusion

From everything said above, it seems to me that we can conclude that Snort is extremely useful. Either way, using this program will make life a little more difficult for hackers. Isn’t this the goal that every system administrator pursues?

This article does not claim to be a complete guide to Snort, but I hope it will help you understand its installation, configuration and operation. Many thoughts are taken from various documents, mostly English, that I came across on various security sites, but mainly this is the result of my experience with Snort.

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 start!

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 are installing the latest version of Snort. Many of the repositories contain older versions. The current version of Snort is 2.9.8, and in the repositories it is 2.9.2. It's a small difference, but when we're trying to protect a "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 downloading 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. (For more information on 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 source code components need to be recompiled and then instructs it 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!

Denial of responsibility: 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.

SNORT is an open source IDS (Intrusion Detection System) that allows you to detect any suspicious network activity by comparing built-in rules for detecting malicious traffic with data passing through the organization's local network. In fact, this is how any antivirus works, but the similarities end there, because the purposes of these systems are completely different. It is very important to correctly understand the goals and objectives of IDS systems and not confuse them with other security tools.

The IDS system is designed to block the actions of an attacker at the stage of studying your network:

detect suspicious network activity,
identify known tools for analyzing and hacking networks used by an attacker
and, where possible, prevent illegal activities.

This task is usually not performed by other means, for example, a firewall, which only puts a barrier at the entrance to the local network. The antivirus catches known virus signatures, but there is no control over traffic within the local network, and in most organizations it is completely absent.

Imagine that one of the workstations on the local network is infected with a new, previously unknown Trojan. In this case, the antivirus program will not be able to track it and neutralize it, since the corresponding signature is simply not in its memory. At the same time, all Trojans are aimed at performing one task - to intercept confidential information and send it to the virus writer, and the sending of confidential information can be simply stopped using IDS SNORT. Scanning network resources in order to identify network weaknesses is also not prevented by either an antivirus or a firewall, although this is important, since reconnaissance is never carried out just like that; it is often followed by an attack.

Settings

IDS technology is free, but relatively complex to install and maintain, you probably won't be able to just install IDS SNORT (like we do with firewall and antivirus) and forget about it. The program and a basic set of detection rules are downloaded from snort.org. If you leave all system settings at default, you will receive many notifications about potentially unsafe actions on the local network, even the ping command will raise a corresponding alarm. It will take time to learn the system, understand how detection rules work and make the appropriate settings, but this will avoid many hundreds or even thousands of redundant notifications and save the system administrator from headaches.

It is necessary to train IDS SNORT to respond only to certain threats, for example, the activity of a network scanner, an attempt to transfer certain files outside the organization’s local network, and\or unauthorized access to selected network resources. IDS SNORT is a highly customizable system that allows any user to set their own set of filters, which can respond to more significant threats for a given network and ignore other, less relevant ones. A basic package of detection rules is provided by the developer; additional signatures can be purchased from other companies offering IDS systems based on SNORT, which has long become the de facto industry standard in the field of intrusion detection systems.

IDS runs on Linux, Windows, SunOS and other operating systems.

The SNORT administrator can either edit signature packages, optionally turning on and off the necessary rules, or write his own signatures, which will require some skill and experience, as well as knowledge of the SNORT syntax, which, however, is relatively simple.

Do not forget that absolute protection does not exist; the only question is the correct settings of the IDS system, which will allow you to properly respond to existing and previously unknown threats. Malware developers also do not stop there and are constantly improving their tools, so you need to regularly update IDS signatures.