IDS and IPS: the theory and practical use - Standard Digibooks

mexicanmorningData Management

Dec 16, 2012 (4 years and 5 months ago)

295 views

IDS: the theory and practical use


Nowadays, the basi
c
s

of information safety

and security

of any level necessarily should include
a subsystem of detection of attacks and intrusions. This could be done by

implementing special
software

for
gathering and th
e later

analysis

of the data. Such systems are called IDS, what stands
for Intrusion Detection System


the system which takes the responsibility of detecting of intrusions.
The primary goal of IDS software is monitoring of hostile operations of any level
, either human
(hackers, crackers) or program (viruses, Trojan horses)
. IDS can function on a definite server or in
the whole segment of a network.


Likely, the market of IDS related softw
are is pretty wide now. From the other hand, it’s hard
to find def
inite tool, which will work better for your specific case. That is why the IDS software has
been categorized into several classes:


1.

Application
-
based Intr
usion Detection System (AIDS).
AIDS

is a software complex which
monitors the functionality of the de
finite applications (or services).

2.

Host
-
based

Intrusion

Detection

System

(
HIDS
).
HIDS

is

a

software

cluster
,
which

consists

of

auditor

software

of

the

file

system, the log file analyzers,
the operational system monitor and
the monitor of software ch
anges.
S
ometimes it includes several AIDS tools.


3.

Network
-
based Intrusion Detection System (
NIDS
).
анализаторы

сетевой

активности

(
трафика
).


I’d like to dwell upon the most popular non
-
commercial IDS solutions.


AIDS.

The most popular AIDS tools are honeypots.

The honeypot is special software, which
allows system administrator
to monitor actions of t
he intruder. Honeypot regulary includes some
tools for registering of hack attempts, as well as you can use any external IDS for that.



The most popular network services emulation software is
honeyd
.

You can use
any
other IDS
software (like as
Snort
, f
or example) along aside with
honeyd
.



Talking about Web applications,
very popular AIDS software is a
mod_security
.
m
od_security
is an open source intrusion detec
tion and prevention engine for W
eb applications.
Operating as an Apache Web server mo
dule,
the purpose of
mod_security

i
s to increase W
eb
application security, protecting
W
eb applications from known and
sometimes
unknown attacks.

The
home site of
mod_security

is
http://modsecurity.org
.

I’ll stop on pract
ical use of
mod_security

later in this article.


HIDS. The HIDS software is

running locally on every server and
are used for detecting of a
alien (or not welcome) changes in the local configuration files or services functionality.

HIDS
software

is divided

into System Integrity Verifiers (SIV),
Log File Monitors (LFM)

and operational
system

patches

(also called as OS extenders)
, which are adding additional functionality to
the
set of
OS functions.


The
A
IDE

(Advanced Intrusion Detection Environment)

is
t
ypi
cal SIV software. This is

utility
for monitoring of the file system changes. It uses the checksum technology, the directory structure
dumps, it also checks for the size and attribute settings of files
.
It generates a database that can be
used to check th
e integrity of files on server. It uses

regular expressions for determi
ning which files
get added to the database. You can use several message digest algorithms to ensure that the files
have not been tampered with.

AIDE

is a free replacement for
Tripwire

.
The home site of
AIDE

is
http://sourceforge.net/projects/aide
.


sXid

is an all in one suid/sgid

bit

monitoring program designed to be run from cron on a
regular basis.
Using the suid/sgid bit attribut
es on the executable files, the local user (intruder) can
gain privileged priorities, what is very dangerous.
Basically
,

sXid

tracks any changes in your
s
u
id/s
gid

bit

files and folders. If there are any new ones, ones that aren't set any more, or they have

changed bits or other modes then it reports the changes in an easy to read format via e
-
mail or on
the command line.


C
hrootkit

is

a
shell script that checks system binaries for
rootkit

modification.

chkrootkit

l
ooks for known "signatures" in T
rojaned sys
tem binaries.

It knows more then 50 Trojan programs
(
rootkit
) and runs on a numerous platforms. The home site of
chrootkit
is here at
http://www.chrootkit.org
.



As a rule, all operational systems already includ
e some tools for the basic IDS monitoring.
Among them are different scripts and executable program
s
, which are
designed to run regulary (from
the cron). In example, FreeBSD

operational system

(
http://www.freebsd.org
)
has a special security
scripts, which are running daily and are called
/etc/periodic/daily/450.status
-
security

and
others
.



Besides
, it’s not hard to make such scripts yourself: you can use different programs for getting
file checksums

(
md5
)
, and the
suid/sgid bit monitoring can be easily done using the internal
program
find
.

Look at the example of getting of file checksum:


white@dragon:~>md5 postfix
-
delete.sh

MD5 (postfix
-
delete.sh) = 9ed41add22f840c3311dd30b4f045d6b


And that’s giv
e you a list of f
iles with suid and
sgid bit set:


white@dragon:/etc>find /usr/bin
-
perm
-
6000
-
print
-
ls


8280 272
-
r
-
sr
-
sr
-
x 1 uucp dialer 123888 Jul 23 2001 /usr/bin/cu


7943 190
-
r
-
sr
-
sr
-
x 1 uucp dialer 96752 Jul 23 2001 /usr/bin/uustat


8250 46
-
r
-
sr
-
sr
-
x 1 root daemon 22728 Jul 23 2001 /usr/bin/lpq


8251 52
-
r
-
sr
-
sr
-
x 1 root daemon 26216 Jul 23 2001 /usr/bin/lpr

8252 44
-
r
-
sr
-
sr
-
x 1 root


daemon 21676 Jul 23 2001 /usr/bin/lprm


logcheck

is typical LFM software.

logcheck

he
lps spot problems and security violations in
your log

files automatically and will send the results to you in e
-
mail.

Also, a lot of SIV HIDS already
include their own versions of log checking software.



logsurfer

is a log checking and
auditing tool simil
ar to
logcheck
,

but with the capability of
handling multi
-
line messages and dynamically adapting the rule

set. It is written in portable C, well
documented, fast, and flexible. It works on any
plain
-
text

file or st
andard input
, can be run at
intervals or c
ontinuously, and has timeouts and resource limits.

It
s home site is at
http://www.cert.dfn.de/eng/logsurf/
.


Swatch

(
Simple Watch Daemon
)

is a program for UNIX system logging,
o
riginally written
in
Per
l programming language
to actively monitor messages as they are written to a log file via the
UNIX
syslog

utility.
Sw
atch

was designed to keep system administrators from being overwhelmed
by large quantities of log data. It monitors log files and acts to f
ilter out unwanted data and take one
or more simple user specified actions based upon patterns in the log.
Swatch

can monitor
information as it is being appended to the log file and alert system administrators immediately to
serious system problems as they

occur.



Talking about operational system patches (extenders) I should say that these HIDS are
complete OS
-
dependent a
nd the most
of them have been written for the Linux OS.


LIDS

stands for

Linux Intrusion Detection System. This is a complex of patches
for the Linux
kernel and utilities, which are increasing the security level and lower the possibility of gaining
privileged rights in the system. It also includes support for Mandatory Access Control (MAC), the
port scan detection system and file and proc
esses protection system.

As the result of implementing
this software patches, even super
-
user (and his processes) will be limited in his actions according to
rule sets, implemented earlier. You should be very
accurate before installing and ena
bling these

patches.



OpenWall

is one of the most popular Linux patches.

This

is a cluster of

patch
es

which is a

collection of security
-
related features for the Linux kernel
, all configurable via the new
Security
options

configuration section. In addition to the new

features, some versions of the patch contain
various security fixes.
The home site of the
OpenWall

project is at
http://www.openwall.com/linux
.
These Linux patches are the part of the
Owl

(
Openwall GNU/*/Linu
x
) is a security
-
enhanced
operating system with Linux and GNU software as its core, compatible with other major distributions
of
GNU/*/Linux
. It is intended as a server platf
orm.



SELinux
stands for
Security
-
Enhanced Linux

and this is a project of
US Nati
onal Security
Agency.
The security mechanisms implemented in the system provide flexible support for a wide
range of security policies. They make it possible to configure the system to meet a wide range of
security requirements. The release includes a gene
ral
-
purpose security policy configuration designed
to meet a number of security objectives as an example of how this may be done. The flexibility of the
system allows the policy to be modified and extended to customize the security policy as required for
a
ny given installation.

The home site for
SELinux

is placed at
http://www.nsa.gov/selinux/
.

SELinux

is known as an effective solution for protecting against even unknown attacks.



MAC Framework
is a
Mandatory A
ccess Control Framework
.
The 5
th

branch of
FreeBSD
operational system
introduced new security extensions from the TrustedBSD project
(
http://www.trustedbsd.org
)
. Two of the most significant new security mechanism
s are file s
ystem
Access Control Lists (ACL
) and Mandatory Access Control (MAC) facilities. Mandatory Access Control
allows new access control modules to be loaded, implementing new security policies. Some provide
protections of a narrow subset of the syst
em, hardening a particular service, while others provide
comprehensive labeled security across all subjects and objects.
The
MAC
Framework

is much
similar to the
SELinux
project.
The

MAC Framework

is very good documented in FreeBSD
Handbook at
http://www.freebsd.org/doc/en_US.ISO8859
-
1/books/handbook/mac.html
.



g
rsecurity

is a Linux
-
based project and

an innovative approach to security utilizing a multi
-
layered detection, pr
evention, and containment model. It is licensed under the GPL.

grsecurity

is
also a set of patches which for Linux kernel and utilities.

The most interesting features of it are

Role
-
Based Access Control
(RBAC),
c
hroot restrictions,
a
ddress space modificat
ion protection

and different
auditing features
.
The
grsecurity

has a home site at

http://www.grsecurity.net/download.php
.



NIDS are also divided into several categories, which are Firewalls, Port Sca
n Detectors (PSD)
and Sniffers.



The most
typical representatives of
NIDS

software are the common packet filters


F
irewalls
-


ipf
and
ipfw

in FreeBSD,
iptables
in Linux,
pf

in OpenBSD, etc
etera,

which has an options of
logging. This allows to make an a
nalysis of the network traffic which comes through the router or a
server.


PortSentry

is PSD
-
related software, and
is a program designed to detect and respond to port
scans against a target host in real
-
time. It runs on TCP and UDP sockets and works on mo
st UNIX
systems. Advanced stealth detection modes are available under Linux
OS
only and detect SYN, FIN,
NULL, XMAS, and Oddball packet scans. All modes support real
-
time blocking and reporting of
violations.
All modes support real time alerting and blocki
ng.


scanlogd

also is a Port Scan Detector from the Solar Designer.

scanlogd
is a TCP port scan
detection tool originally designed to illustrate various attacks an IDS developer has to deal with. It is
designed to be safe to use, and will recognize all of
the latest
nmap

scans.
Now it’s a part of
OpenWall

project (mentioned above) and its home page can be found at
http://www.openwall.com//scanlogd
.


Sniffers is a so
-
called software, which are designed for

listen for the network traffic. The most
popular of them are
tcpdump, ethereal

and
Sniffit.

They are not IDS, but we can parse the results
of their work, which can be used later for protecting the system against intrusions and attacks.


Snort

is the mos
t known
Open Source Network Intrusion Detection System
. It is based on
the
libpcap

library and can make an analysis of the protocols as well as of the signatures. Using the
numerous extenders it can control firewalls for blocking of the unwanted traffic
(in example, you can
use the
fwsnort

application, which allows you to control

iptables

rules in Linux). The
Snort
can be
interconnected with the SQL server (MySQL or PostgreSQL) and with the PHP
-
console
acid
, and is
one of the most advanced NIDS nowadays
.

The home site of the
Snort

can be found at
http://www.snort.org
.




Prelude

is an innovative Hybrid Intrusion Detection

(HID)

system designed to be very
modular, distributed, rock solid and fast.
Prelude

benefits fr
om its ability to find traces of malicious
activity from different sensors (
Snort
,
honeyd
,
Nessus

Vulnerability Scanner,
Samhain
, over 30
types of systems logs, and many others) in order to better verify an attack and in the end to perform
automatic correl
ation between the various events.

The home site is placed here at
http://www.prelude
-
ids.org
.



As one can easily see now, the IDS is not just a simple system, which can be used for keeping
our servers safe. N
owadays, the IDS has become a popular slogan which hides
behind its ba
ck the
various kinds of systems and e
very
particular
case requires its own IDS solution.



Note that

the IDS systems
already
are
trying to become
the I
ntrusion
P
revention
S
ystems
(IPS)
.

In our
quick time sometimes people are not fast enough
to protect themselves, even, if they
have powerful monitors and detectors. And we’re trying to give some possibilities for the I
DS to
make an analysis and
also
changes.
As I’ve already mentioned

abo
ve
, the
Snort

already has
modules to communicate with Firewalls, so some others
also
do.




Now, once we’re familiar with what we’re going to work with, I’d like to stop on the several
common examples of the IDS uses.



The first example I’d like to stop
on is Application
-
based
IDS and would like to discuss the
problems of securing of the Web sites.

The most common Web sites are running under the Apache
Web server (
http://httpd.apache.org
) and written in PHP (
http://www.php.net
).

Lets imagine that
we already running such a site (or a number of sites) and we want to make it secure with the help of
IDS.

And it

goes without saying, that just installing of IDS wouldn’t help us a lot,

if we’d not
configure the system properly.




So
as the basics of protecting our Web site we want to do the following
:


1.

The Apache server should block all queries (GET and POST) which have a special HTML tags,
apostrophe signs and
double inverted commas.

G
etting rid of HTML tags will keep us safe
from
cross
-
site scripting
attacks
and specials signs are the potential SQL
-
injection attack.

Cross
-
site scripting attacks (XSS) occur when an attacker injects HTML or (and) Javascript
code in the Web pages and tha
n they code is being executed by other users.


2.

We should have a possibility of logging of all incoming GET and POST queries in the separate
text file, which will allow us to use an external HIDS, like a
Swatch.


Likely, we can use a
mod_security



an Apach
e module, which works
as
internal IDS

and
have a possibility to block unwanted actions or call external procedures
.




The home site of
mod_security

software is
http://modsecurity.org
. You can easily find

a
Download

section there.


root@artiste:/usr/local/src>fetch
-
v
\

http://www.modsecurity.org/download/mod_security
-
1.8.4.tar.gz

looking up www.modsecurity.org

connecting to www.modsecurity.org:80

requesting http://www.modsecurity.org/download/mod_security
-
1.8.4.tar
.gz

remote size / mtime: 351172 / 1091101387

mod_security
-
1.8.4.tar.gz 100% of 342 kB 125 kBps


root@artiste:/usr/local/src>tar zxf mod_security
-
1.8.4.tar.gz



The distribution includes simple
INSTALL

text file which explains the two
ways of installing this
module


as a DSO module or a static one.

We’ll choose DSO.


root@artiste:/usr/local/src/mod_security
-
1.8.4/apache1>/usr/local/apache/bin/apxs
-
\

-
cia mod_security.c

gcc
-
DHARD_SERVER_LIMIT=512
-
DBUFFERED_LOGS
-
DDYNAMIC_MODULE_LIM
IT=256
-
funsigned
-
char
-
DMOD_SSL=208119
-
DMOD_ACCEL
-
DMOD_ACCEL_CACHEMGR
-
DEAPI
-
DEAPI_MM
-
DUSE_EXPAT
-
I../lib/expat
-
lite
-
O6
-
fomit
-
frame
-
pointer
-
fpic
-
DSHARED_MODULE
-
I/usr/local/apache/include
-
c mod_security.c

gcc
-
shared
-
o mod_security.so mod_secu
rity.o

[activating module `security' in /usr/local/apache/conf/httpd.conf]

cp mod_security.so /usr/local/apache/libexec/mod_security.so

chmod 755 /usr/local/apache/libexec/mod_security.so

cp /usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd.co
nf.bak

cp /usr/local/apache/conf/httpd.conf.new /usr/local/apache/conf/httpd.conf

rm /usr/local/apache/conf/httpd.conf.new



Don’t forget to restart Apache server.



Once the installation has finished, now we need to properly setup Apache configuration fil
es to
enable
mod_security

and to gain our targets.

The distribution has included samples of
httpd.conf

configuration file for the different configurations:
httpd.conf.example
-
minimal, httpd.conf.regression
-
v1
and

httpd.conf.regression
-
v2
.

That’s our s
i
mpl
e configuration:


<IfModule mod_security.c>

SecFilterEngine DynamicOnly


DynamicOnly



analysis of

only requests generated dynamically at runtime.

Using this
option will prevent your web server from using precious CPU

cycles on checking access
to static fi
les.


SecFilterScanPOST On




Scanning of the POSTs.


SecFilterCheckURLEncoding On


This option checks the
URL Encoding validation

according to the RFC 1738. You can
remember it at
http://www.ietf.org/r
fc/rfc1738.txt
.



SecFilterForceByteRange 1

255


We are forcing
requests to consist only of bytes from a certain byte range.
There are
n
ull byte attacks
which
try to confuse C/C++ based software and trick it into thinking
that a

string ends sooner than

it actually does.


SecServerSignature "Microsoft
-
IIS/5.0"


Normally this is not needed, but sometimes a little bit paranoid system administrators
are happy hiding their real Web server name by the other.



SecAuditEngine RelevantOnly

SecAuditLog logs
/audit_log




This two options enable very verbose audit logging

to
logs/audit_log
.


SecFilter "<[[:space:]]*script"

SecFilter "<.+>"


The first filter will protect only against

Javascript injection with the <script>

tag.

The
second filter is more general,

and disallows any HTML code in parameters.

Basically,
this is a typical XSS attack protection.


SecFilter "delete[[:space:]]+from"

SecFilter "insert[[:space:]]+into"

SecFilter "select.+from"


Protection from SQL
-
injection attacks. Nobody can do DELETE

F
ROM
, INSERT

INTO

or
SELECT

FROM

in the query.


</IfModule>



As you can see, the configuration looks like pretty simple, but increases our protection a lot.

mod_security

has a lot more options and features, which are well documented in the mod_security
Reference Manual. It also comes in basic distribution and named
modsecurity
-
manual.pdf
.



My next example is going to cover Host
-
based
and Network
-
based
IDS

both
. I’d like to stop
on the problem
of brute
-
force password scans, using the SSH, telnet or FTP
. One can hardly agree,
that you never can be 100% sure that all of the users in your system have a correct and non
-
dictionary password.
So such brute
-
force attacks can easily find that silly user and gain access to his
account.

So, we need to run such

software (N
IDS

or HIDS
) which will be able to detect such
attempts and block them in any possible way.



I will use
Snort

and
ipfw

firewall (FreeBSD). The installation of
Snort

and
ipfw

are pretty
easy

and I would not stop much on them
. The

ipfw

should
be enabled in the FreeBSD kernel
configuration file (
option IPFIREWALL
)

and
Snort

can be easily installed from the ports.


root@artiste:/usr/local/etc/rc.d>cd /usr/ports/security/snort

root@artiste:/usr/ports/security/snort>make && make install



Please, k
eep in mind that
Snort

must be enabled at

/etc/rc.conf

by

adding

the following
options like

snort_enable=”YES”

and
snort_interface=”fxp0”

(where fxp0


is interface to listen on
your server).

The configuration file will be placed at
/usr/local/etc/snort.c
onf
.

The RULE_PATH
variable by default is configured to
/usr/local/share/snort
,
and
that i
s a correct place where to add
our own rule sets.



Do not forget to create a log directory for
Snort
’s logs:


root@artiste:~/snort>mkdir
-
p /var/log/snort/



If thi
s is your first install, start the
Snort

manually by executing
/usr/local/etc/rc.d/snort.sh start
.

If everything is configured correctly
and your system has
/dev/bpf0

configured in kernel,
it

will start up

successfully
.

Otherwise, it’ll fail with an erro
r:



Running in IDS mode with inferred config file: /usr/local/etc/snort.conf

Log directory = /var/log/snort


Initializing Network Interface xl0

ERROR: OpenPcap() device xl0 open:


(no devices found) /dev/bpf0: Device not configured

Fatal Error, Qu
itting..


If you don’t have
/dev/bpf0

in kernel, add
pseudo
-
device
bpf

to your kernel configuration file
and rebuild the kernel.


Running in IDS mode with inferred config file: /usr/local/etc/snort.conf

Log directory = /var/log/snort


Initializing Network
Interface xl0



--
== Initializing Snort ==
--

Initializing Output Plugins!

Decoding Ethernet on interface xl0

Initializing Preprocessors!

Initializing Plug
-
ins!

Parsing Rules file /usr/local/etc/snort.conf


+++++++++++++++++++++++++++++++++++++++++++
++++++++

Initializing rule chains...

No arguments to frag2 directive, setting defaults to:


Fragment timeout: 60 seconds


Fragment memory cap: 4194304 bytes


Fragment min_ttl: 0


Fragment ttl_limit: 5


Fragment Problems: 0


Self preserv
ation threshold: 500


Self preservation period: 90


Suspend threshold: 1000


Suspend period: 30

Stream4 config:


Stateful inspection: ACTIVE


Session statistics: INACTIVE


Session timeout: 30 seconds


Session memory cap: 8388608 bytes


State alerts: INACTIVE


Evasion alerts: INACTIVE


Scan alerts: ACTIVE


Log Flushed Streams: INACTIVE


MinTTL: 1


TTL Limit: 5


Async Link: 0


State Protection: 0


Self preservation threshold: 50


Self preservation period: 90


Suspend threshold: 200


Suspend period: 30

Stream4_reassemble config:


Server reassembly: INACTIVE


Client reassembly: ACTIVE


Reassembler alerts: ACTIVE


Zero out flushed packets: INACTIVE


flush_data_diff_size: 500


Ports: 21 23
25 53 80 110 111 143 513 1433


Emergency Ports: 21 23 25 53 80 110 111 143 513 1433

rpc_decode arguments:


Ports to decode RPC on: 111 32771


alert_fragments: INACTIVE


alert_large_fragments: ACTIVE


alert_incomplete: ACTIVE


alert_multip
le_requests: ACTIVE

Using LOCAL time

Conversation Config:


KeepStats: 0


Conv Count: 32000


Timeout : 60


Alert Odd?: 0


Allowed IP Protocols: All


Portscan2 config:


log: /var/log/snort/scan.log


scanners_max: 3200


targets_max: 5000


target_limit: 5


port_limit: 20


timeout: 60

1 Snort rules read...

1 Option Chains linked into 1 Chain Headers

0 Dynamic rules

+++++++++++++++++++++++++++++++++++++++++++++++++++



+
-----------------------
[thresholding
-
config]
-------------------
---------------

| memory
-
cap : 1048576 bytes

+
-----------------------
[thresholding
-
global]
----------------------------------

| none

+
-----------------------
[thresholding
-
local]
-----------------------------------

| gen
-
id=1 sig
-
id=2001219 type=Thres
hold tracking=src count=3 seconds=60

+
-----------------------
[suppression]
------------------------------------------

-------------------------------------------------------------------------------

Rule application order:
-
>activation
-
>dynamic
-
>alert
-
>pas
s
-
>log



--
== Initialization Complete ==
--


-
*> Snort! <*
-

Version 2.1.3 (Build 27)

By Martin Roesch (roesch@sourcefire.com, www.snort.org)



Now I’ll write own rule set file, which will be used for detecting SSH brute force attempts.

Why SSH? Fir
st of all, it’s not that trivial, for the second,
Snort

includes rule sets for telnet brute
force attempts in the default distribution and they are
really
simple.


Here comes our
ssh
.rules

file. I’ll put it at
/home/white/snort/ssh.rules

and add
include

o
ption

of it to the
Snort
’s configuration file at
/usr/local/etc/snort.conf

like:


include /home/white/snort/ssh.rules



And that’s the rule set itself

(
/home/white/snort/
ssh.rules
)
:


alert tcp any any
-
> $HOME_NET 22 (

\


msg:"Potential SSH Brute Fo
rce Attack";

\


f
low:to_server
;

\


flags:S;

\


threshold:type threshold, track by_src, count
3
, seconds 60;

\


classtype:attempted
-
dos;

\


sid:2001219;

\


rev:4;

\


resp:rst
-
all;
\

)



This rule set file wil
l
send TCP_RST packets in both directions once somebody will try to
perform more than 3 connections during the 60 seconds. According to that the default and usual
number of tries of password in SSH is 3 tries, this is very
strange that somebody couldn’t r
emember
his password in 6 tries.



More than that,
Snort

will also log this attempt:


root@artiste:/var/log/snort>tail /var/log/snort/alert


[**] [1:2001219:4] Potential SSH Brute Force Attack [**]

[Classification: Attempted Denial of Service] [Priority: 2
]

10/20
-
09:11:35.582914 10.0.185.98:3294
-
> 10.0.185.115:22

TCP TTL:64 TOS:0x0 ID:8481 IpLen:20 DgmLen:60 DF

******S* Seq: 0xC5A27561 Ack: 0x0 Win: 0xE000 TcpLen: 40

TCP Options (6) => MSS: 1460 NOP WS: 0 NOP NOP TS: 43538876 0



And it also will create

a special directory, which will keep the TCP session information of each
attempt:


root@artiste:/var/log/snort>ls
-
al /var/log/snort/10.0.185.98

total 22

drwx
------

2 root wheel 512 Oct 20 09:11 .

drwxr
-
xr
-
x 5 root wheel 512 Oct 20 08:54 ..

-
rw
---
----

1 root wheel 9336 Oct 20 08:54 TCP:1371
-
22

-
rw
-------

1 root wheel 353 Oct 20 08:58 TCP:2650
-
22

-
rw
-------

1 root wheel 353 Oct 20 09:00 TCP:2791
-
22

-
rw
-------

1 root wheel 353 Oct 20 09:11 TCP:3294
-
22

-
rw
-------

1 root wheel 353 Oc
t 20 08:56 TCP:4004
-
22



Now, using all these logged information, you can use
ipfw

for complete or particular blocking
access from the destination host, which has tried some many times to guess a password. Using
ipfw

policy routing (
option

IPFIREWALL_FORW
ARD
) you can

redirect the attacker to your h
oneypot or you
can just block an access for him for a definite time.




For example, here is a sample command, which
adds a blocking rule and then adds a job to
remove a block after the 30 minutes (you can run p
ut it into the script, and run it from the cron
program, if it’ll find a new file in the
/var/log/snort/10.0.185.98
):


root@artiste:/var/log/snort>ipfw add 10 reset tcp from 10.0.185.98 to 10.0.185.115 22

00010 reset tcp from 10.0.185.98 to 10.0.185.115 22

root@artiste:/var/log/snor
t>echo ipfw delete 10 | at now+30
m

Job 1 will be executed using /bin/sh

root@artiste:/var/log/snort>atq

Date Owner Queue Job#

10:03:00 10/20/04 root c 1


It goes without saying
,

that

using
Sw
atch
could be much easier in this situation.
For example,
it

knows how to make an external ca
ll to a program one the rule has happened and
Snort

doesn’t
(for the moment of writing this article).

From the other hand,
Snort

i
s much flexible, but definitely
,
with the less intuitive syntax
.



More than that
, it worths thinking twice before giv
ing such powerful possibility for

block
ing
access to a
Swatch

-

it can easily lockout our server

just because of a single typo
.

Sometimes it’s a
good approach of letti
ng your software do your job, but not when it deals with the only way in


SSH
or telnet.


As a very important note
,
I’d like to aware everybody of using of the examples, which I used
in this article. I’ve been trying to show you the possibilities and fle
xibility of the IDS systems, but
not the correctly planned IPS. Please, never
try to
use these examples on a pro
duction system until
you’re
pe
rfectly underst
ood that
, because you may get a false
confidence that your system is safe,
when it is not.





As

a conclusion, I should say that I
ntrusion
D
etection and Prevention
S
ystems

are very
powerful helpers in securing your servers
.
But

you should always keep in mind that no system cou
ld
perfectly fit your needs. And if you want to keep your server secure as it’s only possible
you should
be ready
tha
t

it

will require your personal touch and scripting.


Copyright © 2004 Alexander Prohorenko


Flow Injection Analysis Systems