Intrusion
Detec-on
&
SNORT
Fakrul
Alam
[email protected]
Some-mes,
Defenses
Fail
• Our
defenses
aren’t
perfect
– Patches
weren’t
applied
promptly
enough
– An-virus
signatures
not
up
to
date
– 0-‐days
get
through
– Someone
brings
in
an
infected
USB
drive
– An
insider
misbehaves
• Now
what?
• Most
penetra-ons
are
never
detected
– This
allows
con-nuing
abuse,
and
helps
the
aNackers
spread
elsewhere
Unexpected
Ac-vity
• There
could
be
an
intruder
even
if
you
have
security
prac-ce
in
place
Addi-onal
Monitoring
• Ac-vity
in
your
network
Intruder
• To
confirm
security
Detec-ng
System
What
can
IDS
realis-cally
do
• Detect
successful
aNacks
• Look
for
various
things
that
shouldn’t
be
there
– Infected
files
– ANacks
on
other
machines
– Packets
that
shouldn’t
exist
– Strange
paNerns
of
behavior
• Contain
aNacks
before
they
spread
further
• Clean
up
penetrated
machines—because
you’ll
know
they’re
infected
• Recogni-on
of
paNern
reflec-ng
known
aNacks
• Sta-s-cal
analysis
for
abnormal
ac-vites
What
IDS
can’t
do
• Compensate
for
weak
authen-ca-on
&
iden-fica-on
mechanisms
• Inves-gate
aNacks
without
human
interven-on
• Guess
the
content
of
your
organiza-on
security
policy
• Compensate
for
weakness
in
networking
protocols,
for
example
IP
Spoofing
Monitoring
Point
• More
specific
rules
can
be
applied
for
a
point
close
to
end
nodes
• Generic
ac-vi-es
can
be
found
on
network
Internet
Generic
Specific
Network
and
Host
IDS
host
IDS
Network
IDS
host
IDS
Internet
host
IDS
Generic
Specific
IDS
Technology
landscape
Preven-ve
Real
Time
Alert
• You
may
receive
tons
of
millions
of
alerts
– Depending
on
your
detec-on
rules
– There
are
many
suspicious
ac-vi-es
in
the
Internet
today
• You
should
no-ce
a
cri-cal
one
at
least
– Detec-on
rule
is
important!
Alert
• False
Posi-ve
/
Type
I
Error:
– is
the
incorrect
rejec-on
of
a
true
null
hypothesis
– is
when
a
system
raises
an
incorrect
alert
• False
Nega-ve
/
Type
II
Error:
– is
the
failure
to
reject
a
false
null
hypothesis
– is
when
an
aNack
pass
undetected
Types
of
Detec-on
• Signature
Based
– Match
paNerns
against
known
aNacks
– Catch
the
intrusions
in
terms
of
the
characteris-cs
of
known
aNacks
or
system
vulnerabili-es
• Anomaly
Based
– Look
for
unusual
behavior
– Detect
any
ac-on
that
significantly
deviates
from
the
normal
behavior
Intrusion
Detec-on
for
ISPs
• Monitor
your
own
network—but
that’s
no
different
than
any
other
enterprise
• Monitor
your
customers
– Good:
you
can
help
them
by
detec-ng
problems
– Good:
you
can
prevent
them
from
clogging
your
infrastructure
– Bad:
it
can
be
privacy-‐invasive
SNORT
• Snort
is
an
open
source
IDS,
and
one
of
the
oldest
ones
• Hundreds
of
thousands
of
users
• Ac-ve
development
of
rules
by
the
community
make
Snort
up
to
date,
and
o`en
more
so
than
commercial
alterna-ves
• Snort
is
fast!
It
can
run
at
Gbit/s
rates
with
the
right
hardware
and
proper
tuning
Geang
Snort
to
see
the
network
• You
could
run
Snort
in
mul-ple
ways
– As
a
device
“in
line”
behind
or
a`er
the
firewall/
router
• But
this
adds
one
more
element
that
can
fail
in
your
connec-vity
– Or
you
could
use
a
span/mirror
port
to
send
traffic
to
Snort
– Or
you
can
use
an
“op-cal
spliNer”
to
“mirror”
or
“tap
into”
traffic
from
a
fiber
op-c
link
• This
method
and
the
previous
are
the
most
recommended
Geang
Snort
to
see
the
network
O
SWITCH
SNORT
I
Geang
Snort
to
see
the
network
• Be
careful
not
to
overload
your
switch
port
–
If
you
mirror
a
gigabit
port
to
another
gigabit
port,
the
monitoring
port
(the
receiving
port)
can
drop
packets
if
the
total
traffic
exceeds
1
Gbit/s
Monitoring
Port…
• On
Cisco
Catalyst,
this
is
a
“SPAN”
port
• You
can
SPAN
one
port
to
another,
a
group
of
ports
to
one
port,
or
an
en-re
VLAN
to
a
port
• Sample
config:
interface FastEthernet 0/1
# port monitor FastEthernet 0/2
• This
would
copy
any
packet
received
on
F0/2
to
F0/1
Snort
configura-on
file
• By
default,
/etc/snort/snort.conf
• It’s
a
long
file
–
900+
lines
• If
you
browse
it,
you
will
no-ce
many
“preprocessor”
entries
• Snort
has
a
number
of
“preprocessors”
which
will
analyze
the
network
traffic
and
possibly
clean
it
up
before
passing
it
to
the
rules
Snort
rules
• Snort
rules
are
plain
text
files
• Adding
new
rules
to
snort
is
as
simple
as
dropping
the
files
into
/etc/snort/rules/
• Groups
of
rules
can
be
loaded
from
snort.conf
using
the
“include”
statement
• Rules
can
match
anything
• Technical
–
web
aNacks,
buffer
overflow,
portscan,
etc…
• Policy/user
oriented
–
URL
filtering,
keyword,
forbidden
applica-ons,
etc…
Tailoring
the
rules
• Not
all
rules
will
make
sense
in
your
network
• You
will
want
to
customize
which
rules
you
want
to
run
• Otherwise
you
will
get
many
false
posi-ves,
which
will
lead
you
to
ignore
Snort,
or
simply
turn
it
of…
• It
doesn’t
help
to
have
logs
full
of
junk
alerts
you
don’t
want
• To
avoid
this,
rules
can
be
suppressed
(disabled)
Upda-ng
Snort
rules
• The
commercially
maintained
snort
rules
are
available
for
free
with
a
30
day
delay
from
hNp://www.snort.org/start/rules
• Other
rules
are
maintained
by
some
volunteers
at
emerging
threats:
hNp://
rules.emergingthreats.net/open/
• The
upda-ng
of
rules
can
be
automated
with
a
tool
called
“Pulled
Pork”,
which
is
located
at
hNp://code.google.com/p/pulledpork/
Snort
rules
• Snort
rules
are
divided
into
two
logical
sec-ons:
– Rule
Header
:
The
rule
header
contains
the
rule's
ac-on,
protocol,
source
and
des-na-on
IP
addresses
and
netmasks,
and
the
source
and
des-na-on
ports
informa-on.
– Rule
Op-ons
:
The
rule
op-on
sec-on
contains
alert
messages
and
informa-on
on
which
parts
of
the
packet
should
be
inspected
to
determine
if
the
rule
ac-on
should
be
taken.
Snort
rules
alert tcp $EXTERNAL_NET any ->
$HOME_NET 22 (msg: "SSH
Detected"; sid:10; rev:1;)
The
text
up
to
the
first
parenthesis
is
the
rule
header
and
the
sec-on
enclosed
in
parenthesis
contains
the
rule
op-ons.
The
words
before
the
colons
in
the
rule
op-ons
sec-on
are
called
op-on
keywords.
Snort
rules
header
• alert
-‐
generate
an
alert
using
the
selected
alert
method,
and
then
log
the
packet
• log
-‐
log
the
packet
• pass
-‐
ignore
the
packet
• ac-vate
-‐
alert
and
then
turn
on
another
dynamic
rule
• dynamic
-‐
remain
idle
un-l
ac-vated
by
an
ac-vate
rule
,
then
act
as
a
log
rule
• drop
-‐
block
and
log
the
packet
• reject
-‐
block
the
packet,
log
it,
and
then
send
a
TCP
reset
if
the
protocol
is
TCP
or
an
ICMP
port
unreachable
message
if
the
protocol
is
UDP.
• sdrop
-‐
block
the
packet
but
do
not
log
it.
Snort
rules
:
The
Direc-on
Operator
• The
direc-on
operator
-‐>
indicates
the
orienta-on,
or
direc-on,
of
the
traffic
that
the
rule
applies
to.
• There
is
no
<-‐
operator.
• Bidirec-onal
operator
<>
Snort
rules
:
sid
• The
sid
keyword
is
used
to
add
a
“Snort
ID”
to
rules
– Range
0-‐99
is
reserved
for
future
use
– Range
100-‐1,000,000
is
reserved
for
rules
that
come
with
Snort
distribu-on
– All
numbers
above
1,000,000
can
be
used
for
local
rules
Snort
rules
:
classtype
• Rules
can
be
assigned
classifica-ons
and
priority
numbers
to
group
and
dis-n-‐
guish
them
– /etc/snort/classification.config
config classification: DoS,Denial of Service Attack,2
Name
Descrip-on
Priority
• You
can
dis-nguish
between
high-‐
and
low-‐
risk
alerts
Sample
rules
alert tcp msg:"MYSQL root login attempt";
flow:to_server,established; content:"|0A 00 00 01 85 04
00 00 80|root|00|"; classtype:protocol-command-decode;
sid:1775; rev:2;)
alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 3306
(msg:"MYSQL show databases attempt";
flow:to_server,established; content:"|0F 00 00 00 03|
show databases"; classtype:protocol-command-decode;
sid:1776; rev:2;)
alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 3306
(msg:"MYSQL 4.0 root login attempt";
flow:to_server,established; content:"|01|"; within:1;
distance:3; content:"root|00|"; within:5; distance:5;
nocase; classtype:protocol-command-decode; sid:3456;
rev:2;)
Repor-ng
and
logging
• Snort
can
be
made
to
log
alerts
to
an
SQL
database,
for
easier
searching
• A
web
front-‐end
for
Snort,
BASE,
allows
one
to
browse
security
alerts
graphically
BASE
(Basic
Analysis
and
Security
Engine)
BASE
(Basic
Analysis
and
Security
Engine)
References
and
documenta-on
• Snort
preprocessors:
– hNp://www.informit.com/ar-cles/ar-cle.aspx?
p=101148&seqNum=2
• Snort
documenta-on
– hNp://www.snort.org/docs
• An
install
guide
for
Ubuntu
10.04:
– hNp://www.snort.org/assets/158/014-‐
snor-nstallguide292.pdf
• Wri-ng
SNORT
Rules
– hNp://manual.snort.org/node27.html
Exercise
SNORT
Setup
• Follow
lab
manual
to
install
SNORT
and
check
the
basic
SNORT
rules.
Exercise
:
1
• Write
a
rules
to
check
XMAS
scan
on
your
server
– Clue
XMAS
scan
sets
the
FIN,
PSH,
and
URG
flags
– Check
the
rules
with
nmap
• nmap -sX SERVER_IP
Exercise
:
2
• Write
a
rules
to
check
any
external
network
access
your
webserver
/admin
pages
– Match
content
Exercise
:
3
• Write
a
rules
to
check
SSH
brute
force
aNack
and
log
IP
trying
to
connect
more
than
3
-mes
in
60
seconds.
– threshold:type
threshold,
track
by_src,
count
3,
seconds
60;