4.4 Creating tables in Snort and Archive databases

We will use the Snort schema to layout the Snort and Archive databases.

# cd /usr/share/doc/snort-mysql # zcat create_mysql.gz | mysql -u -h localhost -p snort # zcat create_mysql.gz | mysql -u -h localhost -p archive

4.5 Confirmation of the creation of databases and newly created tables.

Login to the MySQL server and check the databases we just created and the tables hosted in those databases. If everything was created successfully, you will see four (4) databases (mysql, test, snort and archive) in the mysql databases and approximately 16 tables in each database.

# mysql -u root -p mysql> show databases; mysql> use snort; mysql> show tables; mysql> use archive; mysql> show tables; mysql> exit

4.6 Testing Snort

In terminal mode, type the command: # snort -c /etc/snort/snort.conf

If everything went well, you should see the response in ascii codes.

To end the test press ctrl + c

5. Configuring Apache2

The Apache2 package must already be installed on your computer.

Using your favorite text editor, create a file called test.php in the /var/www/ folder.

# vim /var/www/test.php

Write in it:

Save your changes and close this file.

Edit the /etc/php5/apache2/php.ini file

# vim /etc/php5/apache2/php.ini

Under the "Dynamic Extensions" line, add the following:

Extension=mysql.so extension=gd.so

Restart Apache2.

# /etc/init.d/apache2 restart

Get the IP address of your work computer.

# ifconfig -a

Open your web browser and go to http://YOUR_IP_ADDRESS/test.php.

If everything went well, PHP information will be displayed.

6. Configuring folders

Move ADOdb to the /var/www folder.

# mv /usr/share/php/adodb /var/www/

Create a folder called web in www and move ACIDBASE to it.

# mkdir /var/www/web # mv /usr/share/acidbase /var/www/web/

Temporarily allow writing to the acidbase database folder to install it.

# chmod 777 /var/www/web/acidbase

# cd /var/www/web/acidbase # mv base_conf.php base_conf.old

To work in ACIDBASE, run the command:

#pear install Image_Color

7. Installing ACIDBASE for Snort and Archive databases

7.1 Installing the Snort database via a web browser

Step 1 of 5:

Enter the path to ADODB. This is /var/www/adodb.

Step 2 of 5:

Main Database type = MySQL
Database name = snort
Database Host = localhost (Local location of the Snort database),
Database username =<ваше_имя_пользователя>(Snort database username)
Database Password =<ваш_пароль>(Password for Snort database)

Archive Database type = MySQL (Archive Database Type),


Database username =<ваше_имя_пользователя>
Database Password =<ваш_пароль>

Step 3 of 5:

If you want to use authentication, enter your username and password (user:<ваше_имя>, password:<ваш_пароль>).

Step 4 of 5:

Click Create BASE AG.

Step 5 of 5:

When step 4 is completed, at the bottom, click: Now continue to step 5.

Bookmark this page.

7.2 Create a folder for the Archive ACIDBASE database

For the archive database to work correctly, an archive folder must be created in the ACIDBASE folder.

# mkdir /var/www/web/acidbase/archive # cd /var/www/web/acidbase # cp -R * /var/www/web/acidbase/archive # chmod 777 /var/www/web/acidbase/archive

Rename the existing base_conf.php file to base_conf.old .

# cd /var/www/web/acidbase/archive # mv base_conf.php base_conf.old

7.3 Installing the Archive database via a web browser.

Open a web browser and go to http://YOUR_IP_ADDRESS/web/acidbase/archive/setup.

On the first page, click Continue.

Step 1 of 5:

Enter the path to ADODB. This is /var/www/adodb. >

Step 2 of 5:

Archive Database type = MySQL
Database name = archive (Database Archive),
Database Host = localhost (Local location of the Archive database),
Database username =<ваше_имя_пользователя>(Archive database username),
Database Password =<ваш_пароль>(Password for Archive database)

Step 3 of 5:

If you want to use authentication, enter your username and password(user:<ваше_имя_пользователя>, password:<ваш_пароль>).

Step 4 of 5:

Click on Create BASE AG.

Step 5 of 5:

When step 4 is completed, click at the bottom: Now continue to step 5 (Now go to step 5).

8. Launch Snort and check the status of services.

To run Snort, type in terminal mode:

# snort -c /etc/snort/snort.conf -i eth0 -D

This command starts snort using the eth0 interface in demo mode.

You can verify that the service is running using the following command:

# ps aux | grep snort

If the service is running, you will see something similar to the following snort -c /etc/snort/snort.conf -i eth0 -D .

Verify that all required services are running by running the following commands:

# /etc/init.d/mysql status # /etc/init.d/apache2 status # /etc/init.d/snort status

If the services are running, you will see a response message .

If necessary, run the command
# /etc/init.d/ restart
for each of the services that needs to be restarted.

Introduction

The main goal of this work is to describe and study the popular IDS application Snort. Snort is a large open source project that is used by many network administrators to capture malicious signatures and alert them when their network is under attack. Snort intercepts all traffic from network interfaces, checking packets for suspicious requests and intrusion attempts.

Its main advantage is its accessibility and the ability to edit its work to suit your specific work network. The program is designed to work in both small and large organizations. Also important is the ability to edit your own unique rules based on the security requirements of a particular organization (for example, a ban on staff access to social networks).

The disadvantages include the inconvenience of setup and installation on some operating systems (for example, Windows), the lack of a single, sufficiently complete and detailed description of setup and the development of your own set of rules.

Also, it is very difficult to cut off false alarms, since different enterprises often have different restrictions, and quite fine-tuning of the rules is required. Many modes for launching an application using case-sensitive keys are very difficult to remember and can lead to erroneous output.

The main task of this work is to understand the functional features of IDS Snort and check the operation of the application by carrying out various types of network attacks on it. Find out if there are similar IDS in a more convenient format. How Snort interacts with databases. Develop several unique rules and test them for functionality.

Installation and configuration of IDS Snort

Snort: Installation on Windows XP

When installing Snort on a Windows operating system, you may encounter some difficulties. Therefore, this work focuses on a fairly detailed part of the installation and configuration options. First you need to download the required programs onto your work computer.

Rules for Snort.

All of the above is downloaded from the official websites of these applications.

Winpcap is an application that captures and filters packets at the kernel level. This is analogous to the built-in Unix libpcap driver. The installation will not cause any particular inconvenience; it is launched through a regular installer. After this, you need to download the IDS itself from the official website, after which we download the latest archive with the rules from there. The next step will be to completely copy all the folders that were in the archive with the rules to the root directory of the application, completely replacing the contents where required. Then, for the program to work correctly, you will need to make important changes to the configuration file.

var RULE_PATH c:snort ules

var SO_RULE_PATH c:snortso_rules

var PREPROC_RULE_PATH c:snortpreproc_rules

dynamicpreprocessor directory c:snortlibsnort_dynamicpreprocessor

dynamicengine c:snortlibsnort_dynamicenginesf_engine.dll

#dynamicdetection directory /usr/local/lib/snort_dynamicrules

We find similar lines in the configuration file and replace them with those provided above. After that, we try to test the application. Launch the command line and go to the application directory in the “bin” section. Enter the command "snort -W"

Rice. 1.1.

With this command we check the functionality of the application to view our interfaces. After making sure that there is more than one of them, we select the one that is connected to the working network to begin intercepting packets and monitoring the operation of the IDS.

C:Snortinsnort -i 3 -c C:snortetcsnort.conf -l C:snortlog -A console

Let's now look at the command we entered. "- i 3" means that we will look at the interface that has ID= 3 in the list of our interfaces. Then we specified the path to the configuration file and the path to the directory where the “log” of intercepted packets should be written. "-A console" means that alarm packets will be detected in our console. If any problems arise during processing, we eliminate them as they are identified. Snort indicates the string and type of build error. If everything worked, then we will not see anything until one of the running rules is triggered. To use one of them, let's try to simulate a network attack and launch a suspicious packet over our local network. To do this, for example, open the command line and enter the following: “Ping 192.168.1.16”. Snort will intercept an attempt to listen to the host at 192.168.1.1624 and display a message and information about the suspicious activity on the network. Unfortunately, such IDS systems have a serious drawback - false positives. In this regard, in order for Snort to be useful and not misleading, it is necessary to sufficiently and clearly define the rules and differentiate the networks being viewed in order to avoid these false positives.

Rice. 1.2.

Now in the console where our IDS is running, messages about a suspicious packet that resembles “listening” will appear. This rule involved showed that Snort was fully functional. Let's consider its operating modes and the syntax of rules for further work.

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:

1. Installing WinPcap
2. Installing Snort
3. Testing Snort
4. Setting up Snort
5. Setting rules
6. Setting up alerts and logs
7. 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 to 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"; classtype:web-application-attack; sid:1002;). 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.

MINISTRY OF EDUCATION AND SCIENCE OF THE RUSSIAN FEDERATION

State educational institution of higher professional education

"ST. PETERSBURG STATE UNIVERSITY
AEROSPACE INSTRUMENT ENGINEERING"

COURSE WORK (PROJECT)
PROTECTED WITH RATED EXCELLENT

SUPERVISOR

WORK COMPLETED)

St. Petersburg 2011

1.. What is Snort?. 2

2. Sniffer mode: 2

3. Packet logging mode. 6

4. Network intrusion detection mode. 6

1. What is Snort?

Snort is a lightweight intrusion detection system. Snort is usually called a “lightweight” NIDS / decrypt, translate / - because it is designed primarily for small networks. The program can perform protocol analysis and can be used to detect a variety of attacks.

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.

Snort can work in 3 main modes:

· Sniffer mode: allows you to simply catch packets from the network and display them on the screen (usually the console)

· Packet logging mode: allows you to save packages to your hard drive

· Intrusion Detection System (NIDS) mode is the most sophisticated and customizable configuration that allows you to analyze network traffic based on a user-defined set of rules.

2. Sniffer mode:

In packet sniffing mode, Snort simply reads packets coming from the network and displays them on the screen. To display TCP/IP packet headers, you must run:

snort –v

This command displays IP and TCP/UDP/ICMP packet headers. You can see where the packets were sent from, where, to how many /addresses?/. The figure/drawings must be numbered for reference. There is no link - that means the picture is not needed / it is clear that there are two outgoing addresses. / where can you see it from? Decipher the formats of the entries in the figure or at least refer to the line number /

To understand what these addresses are, just run the command

systeminfo

From the picture / already - pictures. and not drawings? Uniformity must be maintained within the document! Or is it something else?/ It becomes clear what these outgoing addresses are. /well, list them - or at least indicate them. that their numbers are given in square brackets/

In order to see the data contained in the packages, you must enter:

snort-vd

https://pandia.ru/text/78/320/images/image004_112.jpg" alt=" detailed_output.jpg" width="589" height="338">!}

The switches can be given in any form, for example: "snort - vde", "snort - d - ev" and "snort - e - v -d".

Snort will continue to collect information until it is interrupted. To complete packet capture, you must press Ctrl-C. After pressing Ctrl-C, a report of captured packets will be displayed. Below is the report after running Snort for about a minute.

From the snapshot you can see that most of the analyzed packets are TCP/IP packets. UDP packets were also captured.

3. Packet logging mode

Packet logging mode allows you to record a stream of information to disk. This is useful when performing analysis over a period of time or checking for changes in settings and security policies.
You need to create and specify a directory for logs, and Snort will automatically switch to packet logging mode.

Example: creating a directory logs and run:

snort - dev - l../log

As a result of the operation /where, where to look for it, how to indicate the desired location?/ the file snort. log.. The numbers at the end of new file names are timestamps, which helps avoid conflicts when creating files. /an example of a log file is desirable/

4. Network intrusion detection mode

The third mode of Snort is the Network Intrusion Detection (NIDS) mode.

In its basic form, a Snort rule /where are they stored?/ has two parts: a header and parameters. Below is an example of a rule.

alert tcp any any -> any any (content: "www."; msg: "Someone is visiting youtube now"; sid:1000002; rev:1)

Can the rule structure model be represented? Is it hard-coded or can it be changed? we hope that the elements in square brackets are optional. known. But are there special separators between them? / according to the following scheme:

<действие_правила> <протокол> <порт> <оператор_направления>

<порт>([meta_data] [package_contents_data]

[data_in_header] [action_after_detection])

Rule actions are divided into the following categories:

1. alert - Create an alert using the selected method and report the information to the logging system.

2. log - Use a logging system to record package information.

3. pass - Ignore the package.

4. activate - Use another dynamic rule.

5. dynamic - After the active rule is executed, the rule with the logging procedure is activated.

6. drop - Drop the packet using a software firewall and report the information to the logging system

7. sdrop - Drop the packet using a software firewall and do not use the logging system.

8. reject - Using a firewall, discard the packet if the protocol is TCP, or write a message to the log file: ICMP port is unavailable if the packet arrives via UDP protocol

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/ header 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.

sid – a unique label identifying the rule. This option must be used with the option rev .

<100 зарезервировано для дальнейшего использования

100-999,999 already reserved rules

>=1,000,000 user defined rules

rev- value of the rule version. Using rev rules interpreter

Snort determines the version of the written rule.

You can run Snort in IDS mode with the command:

snort - c "D:\Program Files\Snort\etc\snort. conf" - l " D:\Program Files\Snort\log" - A console - i 1

key -With means that IDS mode is enabled

key – l enables recording mode to the hard disk indicating the path to the file

key – A shows that all warnings will be duplicated by console output

key – i indicates the index number of the interface we are interested in

to find out the supported interfaces you need to run the command:

snort – W

File contents snort. conf

File contents *****les:

In the file snort. conf you can connect rules using the keyword include .

Result of the command:

It can be seen that Snort detected an attempt to get to a “dangerous” site.

There is no information about the source where the distribution was taken from, or about the OS on which the research was conducted

Overall the work is very interesting. /