Learn Linux Series (#6) - Attack Detection System Snort

vitusc (54)in #utopian-io • 7 years ago (edited)

What will I learn?

What is Snort

How to install Snort

How to correctly configure Snort

How can you prepare for attack

What kind of attack you will be prepared for

How to manually download and install Snort Rules updates

What is Snor's preprocessor

Requirements

Linux system installed

ACID installed

Database

Also It is recommended to get a server that supports PHP

Difficulty

Indermediate

Learn Linux Series (#6) - Attack Detection System Snort

What is Snort?

Snort is a very powerful network-based attack detection system that provides a wide range of detection mechanisms that can real-time perform traffic analysis and packet logging in IP / TCP / UDP / ICMP based networks. Snort can analyze packet streams, search for and match suspicious content, and detect multiple attacks and anomalies, such as buffer overflows, stealth port scans, attacks on web services, SMB, attempts to detect the operating system, and more.
Snort and ACID installation

Once we have the database and web server with PHP, we install the followin packages.

# poldek -i snort acid

Before configuring the NIDS environment, we assume two databases, for Snort and for the alarm archive.

# mysql -u mysql -p
Enter password:
mysql> create database snort_log;
Query OK, 1 row affected (0.01 sec)
mysql> create database snort_archive;
Query OK, 1 row affected (0.01 sec)
mysql> quit

We add tables in the same way for both databases.

# gzip -d /usr/share/doc/snort-{version}/create_mysql.gz
# mysql -D snort_log -u mysql -p < \
    /usr/share/doc/snort-{version}/create_mysql
# gzip -d /usr/share/doc/acid-{version}/create_acid_tbls_mysql.sql.gz
# mysql -D snort_log -u mysql -p < \
    /usr/share/doc/acid-{version}/create_acid_tbls_mysql.sql

# mysql -D snort_archive -u mysql -p < \
    /usr/share/doc/snort-{version}/create_mysql
# mysql -D snort_archive -u mysql -p < \
    /usr/share/doc/acid-{version}/create_acid_tbls_mysql.sql

Then (by the easiest way: using phpMyAdmin) we create a user and give him permissions for created databases.

We are going to edit the file in which we add parameters for connecting to the databases.

[...]
/* Alert DB connection parameters */
[...]
$alert_dbname   = "snort_log";
$alert_host     = "localhost";
$alert_port     = "3306";
$alert_user     = "login";
$alert_password = "password";

/* Archive DB connection parameters */
$archive_dbname   = "snort_archive";
$archive_host     = "localhost";
$archive_port     = "3306";
$archive_user     = "login.;
$archive_password = "password";
[...]

Now the interface page is available at http://your_ip/acid. Of course, for security, it is recommended to use SSL for communication with the resource and authorization via the apache-mod_auth package.

Depending on the environment in which it operates, Snort can generate a large number of unnecessary alerts, the more important you can transfer to the second database using ACID, for general transparency.

Snort configuration

To work as a network intrusion detection system, Snort need to specify the rules for the operation of the whole in the main configuration file snort.conf. In previous versions of the system, all options, including attack rules, were in one file. Continuous development of Snort, increasing number of signatures and general functionality, forced the separation of some configuration parts, including the rules of attacks. Transparency and consistency of snort.conf has been restored using the 'include' command, which appends the appropriate set of signatures and other configuration parts, e.g.

include: file_path/name

The rule bases are characterized by the file format .rules, the first part of the name contains the type of service or type of attack that the set applies to.

The other configuration files are:

classification.config - containing the classifiers for the types of attacks with priority given to the threat, as below:


config classification: web-application-attack,Web Application Attack,1

reference.config - shortcuts of addresses to the organization's websites with a database of attack descriptions, e.g.

config reference: bugtraq http://www.securityfocus.com/bid/

threshold.conf - methods of easing many, false alarms
unicode.map - a set of coded unicode characters, for the needs of the http_inspect preprocessor.

The main configuration file can be divided into four sections. The first one is responsible for determining variable var, used in the syntax of attack rules.

Suppose that Snort is to monitor two subnets with addresses 192.168.1.0/24 and 192.168.2.0/24, its configuration files are located directly in the /etc/snort directory, and the rules in /etc/snort/rules.

# Local network adress
var HOME_NET [192.168.1.0/24,192.168.2.0/24]
# External network adress
var EXTERNAL_NET !$HOME_NET
# List of server addresses located in the protected zone
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
# Port list
var HTTP_PORTS 80
var SHELLCODE_PORTS !80
var ORACLE_PORTS 1521
# List of chat servers, messengers
var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,]
# Path to the directory with attack rules
var RULE_PATH /etc/snort/rules

In the same section there is a set of runtime parameters starting with the expression config.

config interface: eth0

The second part of the main configuration file contains preprocessor settings. The default parameters will not be shown in the description below. A complete list of options can be found in the Snort documentation. Here are some examples of preprocessor settings:

Frag2:

# detect_state_problems . returns an alarm when overlapping fragments.
preprocessor frag2: detect_state_problems

Stream4, Stream4_reassemble:

# disable_evasion_alerts - no alarms when overlapping
#pakietow TCP, detect_scans - silent scan detector
# detect_state_problems - detector of unnatural package behavior
preprocessor stream4: disable_evasion_alerts \
    detect_scans detect_state_problems
# both - submission of TCP sessions in both directions between the client and the server
# ports - a list of ports on which disassemblies should work
preprocessor stream4_reassemble: both ports [ 21 25 80 143 110 ]

Http_inspect:

# iis_unicode_map - it points to a file with unicode encoding and chooses a standard one
preprocessor http_inspect: global is_unicode_map unicode.map 1252
# profile - choice of profile settings for iis servers, apache and all.
preprocessor http_inspect_server: server adres_MS_IIS_server_IP \
 profile iis \
 ports { 80 }
preprocessor http_inspect_server: server adres_Apache_server_IP \
 profile apache \
 ports { 80 }

The above example shows the possibility of profiling settings for individual servers that are protected. IIS and Apache servers work in a different way, and also have other vulnerabilities used during attacks. The adjustment operation focuses the protection mechanisms on the appropriate attack methods for a given type of server or group of them in a given protected network.

RPC_decode, Back Orfice, Telnet_decode, Arpspoof, Performance Monito:

# alert_fragments . turns on the alarm when fragmenting RPC packets,
# Default ports: 111 i 32771.
preprocessor rpc_decode: 111 32771 alert_fragments
preprocessor bo
preprocessor telnet_decode
preprocessor arpspoof
preprocessor arpspoof_detect_host: IP_adresses \
    MAC_addresses_assigned_to_them
# console . displaying statistics on the screen,
# flow i events . statistics of the surveyed movement and matched numbers
rules
# time . data update every 10s.
preprocessor perfmonitor: console flow events time 10

Flow i Flow-portscan:

# stats_interval . saving statistics, 0 - off, hash. choice of mixing methods.
preprocessor flow: stats_interval 0 hash 2
# server-watchnet . IP addresses on which flow will conduct research,
# server-learning-time . time to maintain points for a given IP address,
# server-scanner-limit . the number of inquiries deciding about the status of scanning from a given address,
# src-ignore-net, dst-ignore-net . list of ignored destination and source addresses.
preprocessor flow-portscan: \
 server-watchnet [xxx.xxx.xxx.xxx/xx] \
 server-learning-time 14400 \
 server-scanner-limit 10 \
 src-ignore-net [xxx.xxx.xxx.xxx/xx, xxx.xxx.xxx.xxx/xx] \
 dst-ignore-net [xxx.xxx.xxx.xxx/xx]

The third section snort.conf contains methods for configuring output modules, i.e. different ways of logging results and so-called. rule shares. For the purposes of this description only the example of login to the MySQL database will be listed.

output database: alert, mysql, user=login password=password \ 
dbname=snort_log host=127.0.0.1

Using action rules, you can create your own types of reactions to a detected event, e.g.

ruletype red_alert
 {
 type log
 # write to the syslog daemon, local
 output alert_syslog: LOG_ALER
 }
# Example rule:
red_alert $HOME_NET any -> $HOME_NET 6667 (msg:"Internal \
    IRC Server";)

The fourth and last part of the main configuration file contains references to sets of rules and previously described files, classification.config, reference.config, threshold.conf (example below)

include classification.config
include reference.config

include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/dos.rules
(...)
# an additional set of Bleeding Snort rules - 
# http://www.bleedingsnort.com
include $RULE_PATH/bleeding.rules
include threshold.conf

Adjusting Snort to your needs includes, next to the configuration of preprocessors, first of all decisions, which sets of rules are to be taken into account (ie what files with rules should be attached using the include command). In an environment where all web servers are Apache, the rules protecting the IIS server will generate totally unnecessary alarms. If we do not provide FTP, rules describing attacks on this service will only slow down the entire system. This is obvious, but it takes a lot of work to properly adapt NIDS to your needs. Choosing the right rules for the given environment is crucial for the entire system, a large number of false alarms not only consumes resources (each rule must be analyzed), but can also very effectively "darken" the image, making the real attack go unnoticed in flood of information of little importance. The current database of signatures has about 2,500 rules and is practically every day enriched with new descriptions of attacks. For an approximation of the signature categories present in the database, I will write down what types of attacks detect:

attack-responses
backdoor
bad-traffic
chat
ddod, dos
deleted
dns
experimental
exploit
icmp-info, icmp
imap, pop2, pop3, smtp
info
local
misc
multimedia
mysql, sql, oracle
netbios
nntp
other-ids
p2p
policy
porn
rpc
finger, rservices, telnet
scan
shellcode
snmp
tftp, ftp
virus
web-attacks, web-misc, web-client, web-cgi, web-php, web-coldfusion, web-frontpage, web-iis
x11