Zone‐Based
Firewalls.
IPS
&
IDS.

10‐nov‐2009

What
this
lecture
is
about:


  Zone‐based
firewalls

  IPS
&
IDS


2

LimitaEons
of
CBAC


  Does
not
have
a
hierarchical
implementaEon.

  Complex

  Many
inspecEon
features
on
many
interfaces
create
complex

scenarios.

  Policies
cannot
be
Eed
to
a
group
of
hosts
or
a
subnet

  All
rules
apply
to
all
the
traffic
on
one
interface.

  Relies
on
ACLs


3

Zone‐based
policy
firewalls
(ZPF)

  Zone‐based
policy
firewall

  Recently
introduced
in
IOS

  Interfaces
are
assigned
to
zones

  Traffic
is
inspected
as
it
passes
between
zones

  Not
dependent
on
ACLs

  The
router
blocks
everything
unless
explicitely
allowed


  This
type
of
inspecEon
also
supports:

  Stateful
packet
inspecEon

  ApplicaEon‐layer
inspecEon

  URL
filtering

  DoS
miEgaEon

4

Zones


DMZ

Private Public
Internet

  Each
interface
belongs
to
one
zone.

  MulEple
interfaces
connected
to
the
same
zone
can
pass
traffic

between
each
other.

  Zone‐specific
policies
are
applied
to
all
interfaces
belonging
to
a

zone.

5

CBAC
and
ZPF


  Can
coexist
on
the
same
router

  Cannot
coexist
on
the
same
interface

  One
interface
cannot
be
a
security
zone
member
and

configured
for
inspecEon
at
the
same
Eme.


6

Simple
two‐zone
ZPF
scenario


  The
internal
network
should
be
able
to
access
web,
e‐mail

and
DNS
services.

  The
public
network
should
not
have
any
inbound
access.


7

ZPF
design
steps

  Determine
the
zones

  Each
zone
has
a
specific
security
level

  Zones
are
designed
regardless
of
physical
implementaEon

  The
enEre
infrastructure
must
be
separated
into
zones


  Establish
policies
between
zones

  For
each
“source‐desEnaEon”
pair
between
two
zones

  Define
accessible
desEnaEons

  Define
services
that
can
be
requested

  IdenEfy
session
protocols
(TCP,
UDP,
ICMP)

  No
physical
setup
is
involved


8

ZPF
design
steps
conEnued

  Design
the
physical
infrastructure

  Take
into
account
security
and
availability
requirements

  Decide
the
number
of
devices
between
the
least
secure
zones

and
the
most
secure
zones.

  Consider
redundancy.


  IdenEfy
zone
subsets

  A
zone
can
have
subsets

  All
subsets
are
indirectly
connected
to
the
same
firewall

interface.

  The
need
for
an
inter‐subset
per‐device
security
policy
is

needed.

9

ZPF
design
model:
LAN
to
Internet


  No
special
zones
involved.

  All
policies
implemented
on
a
single
firewall.

  Simple
physical
setup:

  One
trusted
interface
for
the
LAN

  One
untrusted
interface
for
the
Internet

10

ZPF
design
model:
Public
servers
on
interface


  The
DMZ
interface
is
associated
with
a
special
zone.

  The
DMZ
zone
is
accessible
from
the
outside.

  Policies
prohibit
the
DMZ
from
contacEng
the
local

network
in
case
it
becomes
compromised.

11

ZPF
design
model:
Public
servers
on
segment



  Traffic
between
the
untrusted
zone
and
the
trusted
one

must
pass
through
the
DMZ.

  Two
firewalls
involved.

  Can
be
implemented
using
layered
security.

  MulEple
points
of
failure.

  Different
policies
for
the
two
locaEons.

12

ZPF
design
model:
Redundant
firewalls


  One
DMZ
for
one
or
several
Internet
connecEons.

  All
interfaces
belonging
to
the
same
area
implement
the

same
policies.

  Layered
approach
without
single
points
of
failure.

  Load‐balancing
opportunity.

13

ZPF
design
mode:
Complex
firewall


  MulEple:

  Interfaces

  Policies

  Security
levels

  Single
point
of
failure

14

ZPF
acEons

  The
Cisco
IOS
zone‐based
firewall
can
take
three
acEons:

  Inspect

  Similar
to
“ip
inspect”
from
CBAC

  Can
handle
applicaEon
sessions

  Drop

  Similar
to
“deny”
in
ACLs

  Dropped
packets
can
be
logged

  Pass

  Similar
to
“permit”
in
ACLs

  ConnecEon
state
is
not
tracked

  One‐way
only


15

Rules
of
interfaces
and
zones

  Configure
the
zone
before
assigning
any
interfaces.

  For
traffic
to
flow
between
all
interfaces,
each
must

belong
to
a
zone.

  An
interface
can
belong
to
only
one
security
zone.

  Interfaces
of
the
same
zone
allow
all
traffic
between

them.


16

Rules
of
interfaces
and
zones
conEnued

  Traffic
flows
between
different
zones
(and
interfaces)

must
be
permi_ed
or
inspected
by
a
policy.


  The
pass,
inspect
and
drop
acEons
can
be
applied
only

between
zones.


  Interfaces
not
assigned
to
a
zone
can
run
CBAC.


  If
an
interfaces
does
not
need
any
special
policies
but
has

to
pass
traffic,
it
can
be
assigned
to
a
zone
with
an
all‐
pass
policy
(dummy
policy).

17

Quick
test


Source
interface
 Des3na3on
interface
 Zone‐ Is
there
a
 Result


member
of
zone?
 member
of
zone?
 pair
is
 policy
in

defined?
 place?

NO
 NO
 N/A
 N/A

Normal
flow


YES
(zone
1)
 YES
(zone
2)
 N/A
 N/A
 PASS


YES
 NO
 N/A
 N/A
 DROP

NO
 YES
 N/A
 N/A
 DROP

YES
(zone
1)
 YES
(zone
2)
 NO
 N/A
 DROP

YES
(zone
1)
 YES
(zone
1)
 YES
 NO
 DROP

YES
(zone
1)
 YES
(zone
2)
 YES
 YES

Policy
acEon


18

Router’s
traffic

  A_aching
a
router’s
interface
to
a
zone
causes
all
hosts
in
that

network
to
become
members
of
the
zone.

  But
the
router’s
interface
is
not
controller
by
the
zone’s
policies

  Neither
inbound
nor
outbound
traffic


  All
router’s
interfaces
are
part
of
the
“self”
zone.

  To
filter
traffic
going
to
or
originaEng
from
the
router,
policies

between
other
zones
and
the
“self”
zone
must
be
implemented.

  In
the
absence
of
any
policy,
all
traffic
is
permi_ed.

  This
“self”
policy
does
not
apply
to
traffic
traversing
the
router.

  The
“self”
zone
is
the
only
excepEon
to
the
default
“deny
all”

policy.

19

Steps
for
configuring
ZPF

  Create
the
zones

  Define
traffic
classes

  Define
firewall
policies

  Assign
policy
maps
to
zone
pairs

  Assign
router
interfaces
to
zones


20

1.
CreaEng
the
zones

  Create
the
zones
from
a
security
perspecEve

  Interfaces
with
similar
security
need
should
be
placed
in
the

same
zone.

  Different
security
policies
will
require
mulEple
zones.


Firewall(config)#zone security INSIDE

Firewall(config-sec-zone)#desc
Firewall(config-sec-zone)#description Our local network
Firewall(config-sec-zone)#exit
Firewall(config)#zone security OUTSIDE
Firewall(config-sec-zone)#description Internet connection

21

2.
Define
traffic
classes

  Traffic
classes
allow
you
to
define
traffic
flows
in
a

granular
fashion.

Firewall(config)#class-map type inspect EXAMPLEMAP
Firewall(config-cmap)#match access-group 101
Firewall(config)#access-list 101 permit ip 192.168.0.0 0.0.0.255 any

  The
syntax
for
creaEng
ZPF
traffic
classes

  InspecEng
layers
3
and
4:

Firewall(config)# class-map type inspect [match-any | match-all]
class-map-name

  InspecEng
the
applicaEon
layer:

Firewall(config)# class-map type inspect protocol-name [match-
any | match-all] class-map-name

22

2.
Defining
applicaEon‐layer
protocols

Firewall(config)#class-map type inspect ?
WORD class-map name
aol Configure CBAC class-map for IM-AOL protocol
edonkey eDonkey
fasttrack FastTrack Traffic - KaZaA, Morpheus, Grokster...
gnutella Gnutella Version2 Traffic - BearShare, Shareeza, Morpheus ...
http Configure CBAC class-map for HTTP protocol
imap Configure CBAC class-map for IMAP protocol
kazaa2 Kazaa Version 2
match-all Logical-AND all matching statements under this classmap
match-any Logical-OR all matching statements under this classmap
msnmsgr Configure CBAC class-map for IM-MSN protocol
pop3 Configure CBAC class-map for POP3 protocol
smtp Configure CBAC class-map for SMTP protocol
sunrpc Configure CBAC class-map for RPC protocol
ymsgr Configure CBAC class-map for IM-YAHOO protocol

23

2.
Defining
ACLs
as
filters

Firewall(config)#class-map type inspect EXAMPLEMAP
Firewall(config-cmap)#match access-group 101
Firewall(config)#access-list 101 permit ip 192.168.0.0 0.0.0.255 any

  The
syntax
for
referencing
an
ACL
from
the
class
map:

Firewall(config-cmap)# match access-group {access-group |
name access-group-name}

  Matching
protocols
from
within
the
class
map:

Firewall(config-cmap)# match protocol protocol-name

  Matching
other
class
maps
from
within
the
class
map:

Firewall(config-cmap)# match class-map class-map-name

24

3.
Define
firewall
policies

  Example:

Firewall(config)#policy-map type inspect INSIDE_TO_OUTSIDE
Firewall(config-pmap)#class type inspect EXAMPLEMAP
Firewall(config-pmap-c)#?
Policy-map class configuration commands:
drop Drop the packet
exit Exit from class action configuration mode
inspect Context-based Access Control Engine
no Negate or set default values of a command
Policy

pass Pass the packet
opEons

police Police
service-policy Deep Packet Inspection Engine
urlfilter URL Filtering Engine
<cr>

Firewall(config-pmap-c)#inspect
%No specific protocol configured in class EXAMPLEMAP for inspection. All
protocols will be inspected

  The
default
class
matching
all
remaining
traffic:

Firewall(config-pmap)#class class-default
25

4.
Assign
policy
maps
to
zone
pairs

  The
firewall
policies
are
applied
to
traffic
between
two

zones
(a
“zone‐pair”).

  Zone
creaEon
example:

  Define
the
source
and
desEnaEon
zones:

Firewall(config)#zone-pair security IN_OUT_ZONE_PAIR source
INSIDE destination OUTSIDE

  “self”
can
be
used
as
a
zone
name
here


  Add
a
descripEon
for
the
zone‐pair:


Firewall(config-sec-zone-pair)#description Going outside

  Map
this
zone‐pair
to
the
configured
policy‐map:

Firewall(config-sec-zone-pair)#service-policy type inspect
INSIDE_TO_OUTSIDE
26

5.
Assigning
interfaces

  Interfaces
must
be
assigned
to
the
appropriate
security

zones:

Firewall(config)#interface FastEthernet0/0
Firewall(config-if)#zone-member security INSIDE

Firewall(config-if)#interface Serial0/1/1
Firewall(config-if)#zone-member security OUTSIDE

27

ZPF
final
configuraEon

  Access
list
to
define
traffic
for
inspecEon:

access-list 101 permit ip 192.168.0.0 0.0.0.255 any

  Class
map
defining
a
traffic
class
using
the
access‐list:

class-map type inspect match-all EXAMPLEMAP
match access-group 101

  Policy
map
segng
the
“inspect”
acEon
on
the
specified

traffic
class:

policy-map type inspect INSIDE_TO_OUTSIDE
class type inspect EXAMPLEMAP
inspect
class class-default

28

ZPF
final
configuraEon
conEnued

  Defining
two
security
zones:

zone security INSIDE
description Our local network

zone security OUTSIDE

description Internet connection

  Defining
a
zone
pair
between
these
two
zones
to
specify
a

policy
map
for
all
traffic:

zone-pair security IN_OUT_ZONE_PAIR source INSIDE
destination OUTSIDE
description Going outside
service-policy type inspect INSIDE_TO_OUTSIDE

29

TesEng
ZPF

  Session
established
aher
a
successful
Telnet
a_empt

through
the
firewall:

Firewall#show policy-map type inspect zone-pair sessions
Zone-pair: IN_OUT_ZONE_PAIR

Service-policy inspect : INSIDE_TO_OUTSIDE

Class-map: EXAMPLEMAP (match-all)

Match: access-group 101
Inspect
Established Sessions
Session 65DA2000 (192.168.0.2:59848)=>(199.0.0.2:23) telnet SIS_OPEN
Created 00:00:04, Last heard 00:00:02
Bytes sent (initiator:responder) [37:80]

Class-map: class-default (match-any)

Match: any
Drop (default action)
0 packets, 0 bytes
30

 IDS
&
IPS


Feel
the
beat…


31

Network
intrusions


MARS
Zero-day exploit ACS
VPN attacking the network
Remote Worker
Firewall

VPN

VPN
Iron Port
Remote Branch LAN

Servers

32

Zero‐day

  A
zero‐day
a_ack/threat/exploit
a_acks
vulnerabiliEes

unknown
(yet)
to
the
sohware
vendor.


  During
the
Eme
it
takes
the
sohware
vendor
to
develop

and
release
a
patch,
all
networks
are
vulnerable
to
this

exploit.


  A
firewall
can
only
protect
against
known
and
well‐
documented
threats
and
anomalies.

  Defending
against
these
kind
of
a_acks
requires
a

different
perspecEve.

33

How
to
detect
a_acks?

  One
approach:
pay
someone
to
look
through
your
logs

24/7.

  Not
scalable

  Time‐consuming
(and
boring)

  Slow
(by
the
Eme
the
logs
get
read,
the
a_ack
was
completed

a
long
Eme
ago)

  Expensive


34

Sorry,
we’re
not
hiring

  Another
approach:
use
a
machine

  Copy
(or
“mirror”)
the
traffic
stream
from
your
network

  Send
it
to
a
device

  Let
the
device
analyze
it
in
real
Eme

  Trust
the
device
to
let
you
know
when
something
seems
fishy…

  An
IDS
works
this
way

  It
is
considered
a
passive
device
(it
only
listens)

  Runs
in
promiscuous
mode
(reveices
all
traffic)

  DOES
NOT
analyze
the
actual
forwarded
packets

  Only
copies
of
them

  What
does
this
mean?

  It
can
ONLY
DETECT,
NOT
PREVENT
a_acks!

35

IDS
behaviour

  1:
An
a_ack
is
launched
from
outside
the

network.
Traffic
si
mirrored
and
sent
to
the

sensor,
too.


  2:
The
IDS
sensor
matches
the
traffic
with
a
 1

signature
and
sends
the
switch
a
command

to
deny
further
similar
traffic.

 Switch

  The
IDS
experiences
the
same
a_ack
as
the
 2

hosts
in
the
network.

Sensor

3


  3:
The
IDS
sensor
sends
a
log
message
to
a

management
console.

Management Target
36
 Console
IPS,
this
Eme

  An
IPS
device
does
mainly
what
an
IDS
does,
too.

  Except
it
is
located
elsewhere:


  An
IPS
is
located
inline
with
the
traffic
flow.


  The
IPS
can
block
traffic
by
itself.

  It
applies
deep
inspecEon
algorithms
to
all
packets.


  The
IPS
responds
immediately
to
a
threat,
by
blocking

traffic.

  The
IDS
cannot
block
traffic

  The
IDS
only
barks,
but
does
not
bite


37

IPS
behaviour

  1:
An
a_ack
is
launched
from
outside

the
network.
Traffic
goes
directly
to
 1

the
sensor.


  2:
The
IPS
sensor
analyzes
the

packets.
If
a
signature
matches,
traffic

2

is
stopped
immediately.
 4

Sensor

  3:
The
IPS
sensor
noEfies
a

management
console
of
the
event.

Bit Bucket
3

  4:
Further
traffic
in
violaEon
of
certain

policies
can
be
dropped
immediately.


Target
Management
38
 Console
IPS
&
IDS
characterisEcs

  A
sensor
can
be
implemented
as:

  A
router
configured
with
Cisco
IOS
IPS
sohware

  A
dedicated
device
that
provides
IPS/IDS
services

  A
network
module
installed
in
an
ASA,
switch
or
router.


  They
both
rely
on
signatures
to
detect
potenEal
harmful

traffic
pa_erns.


  Pa_erns
detected
can
be:

  Atomic
–
single
packets
idenEfied
as
a_acks

  Composite
–
sequences
of
packets
that
form
an
a_ack

  More
on
pa_erns
and
signatures
later.

39

IDS
advantages
and
disadvantages

  Zero
impact
on
normal
   Cannot
stop
a_acks.

network
performance.
   Fast
response
Eme

  No
impact
on
network
 required.

performance
if
the
sensor
   More
vulnerable
to

fails.
 network
evasion

  No
impact
on
network
 techniques.

performance
if
the
sensor

is
overloaded.


40

IPS
advantages
and
disadvantages

  Can
stop
malicious
traffic.
   Single
point
of
failure

  Can
apply
stream
   Sensor
issues
affect

normalizaEon
techniques.
 network
traffic
(failures

  Abnormal
streams
can
be
 of
overloading)

used
to
confuse
an
IDS/IPS.
   Fine‐tuned
policy
required

  And
IPS
can
track
TCP
 to
avoid
false
posiEves.

streams
and
accept
only

valid
data.

  Some
impact
on
network

performance


41

Deployment
methods:
NIPS
and
HIPS


  NIPS
–
Network‐based
IPS
implementaEon

  Analyze
network‐wide
acEvity

  Located
between
trusted
and
untrusted
networks

  Deployed
using
ASA,
routers
and
switches


  HIPS
–
Host‐based
IPS
implementaEon

  Installed
on
individual
computers
as
a
sohware
agent

  Supervise
network
acEvity,
file
systems,
OS
resources

  Detects
using
signatures
and
anomalies

  Acts
like
a
network/applicaEon
firewall+anEvirus
sohware

  Example:
Cisco
Security
Agent
(CSA)

42

NIPS
deployment
example


MARS
ACS
VPN

Remote Worker
Firewall IPS

VPN

VPN
Iron Port
Remote Branch LAN

Servers

43

NIPS


  NIPS
implemented
as
a
dedicated
hardware
device
requires:

  A
NIC
(Network
Interface
Card)
adequate
to
the
network
medium

(FastEthernet,
Gigabit,
etc)

  Processor:
real‐Eme
pa_ern
matching
between
traffic
and
signatures

require
processing
power

  Memory:
intrusion
detecEon
analysis
is
memory‐intensive.


  The
device
is
transparent
to
the
network
and
its
users

  Is
not
dependent
on
network
operaEng
systems

  More
cost‐effecEve


  Cannot
examine
encrypted
traffic

  Does
not
know
whether
an
a_ack
was
successful
or
not

44

HIPS
deployment
example


MARS
ACS
VPN

Remote Worker
Firewall

VPN

VPN
Iron Port
Remote Branch LAN

Servers

45

HIPS

  A
sohware
applicaEon
running
on
top
of
the
OS

  Can
query
the
user
for
specific
acEons

  Requires
complete
administraEve
access
to
the
system

  Must
be
run
on
every
system
on
the
network

  Each
decision
affects
only
the
local
system


  Can
immediately
determine
the
success
or
failure
of
an
a_ack.

  Traffic
received
by
HIPS
is
unencrypted.


  OperaEng
system
dependent.

  Hosts
are
visible
to
the
a_ackers.

  Cannot
detect
lower
level
network
events.

  Runs
with
limited
resources
(one
host)

46

Cisco
Security
Agent
components

Security agents

Firewall

Untrusted

Network

Security agents
Management Servers
center
Security agents

  Management
center:
installed
on
central
server,

managed
by
system
administrator.

  Security
agents:
installed
on
all
host
systems

  Constant
monitoring
acEvity


47

IPS
signatures

  To
stop
an
a_ack,
you
must
be
able
to
idenEfy
it.

  How
to
tell
apart
an
a_ack
from
regular
network
traffic?


  Signatures

  A
set
of
rules
used
by
IPS
and
IDS
to
detect
typical
intrusive

acEviEes

  They
“describe”
a_acks
such
as:

  Viruses,
worms

  DoS
a_acks

  Flooding
a_acks

  Spoofing
a_acks

  Known
exploits


48

Signature
types

  Atomic

  Single
packet
or
event

  Does
not
require
state
informaEon
tracking

  Ex:
spoofed,
malformed
packet

  Composite

  Stateful
signature
–
tracks
an
enEre
connecEon

  Time
to
track
a
connecEon:
event
horizon

  The
event
horizon
must
be
limited:
hardware
resources


  Components
of
a
signature:

  Type
(classificaEon)

  Trigger
(what
kind
of
traffic
triggers
the
signature
acEon)

  AcEon
(the
acEon
taken
with
the
specific
traffic)

49

IPS
signature
characterisEcs

  Signatures
are
stored
in
signature
files.

  These
files
are
uploaded
to
IPS
devices
periodically.


  SME
(Signature
Micro‐Engines)
are
compiled
groups
of

signatures

  Used
by
Cisco
IOS
to
improve
scanning
speed
by
seaching
for
mulEple

signatures
at
once.


  Signature
files
can
be
published
weekly
or
even
hours
aher
an

a_ack
idenEficaEon.

  Each
incremental
update
includes
all
previous
signatures

  Example:
IOS‐S361‐CLI.pkg
aher
IOS‐S360‐CLI‐pkg


50

IPS
signature
alarms

  The
alarm
triggers
the
signature’s
response.

  It
is
comprised
of
certain
packet
parameters
or
a
packet

sequence
that
indicates
a
known
a_ack.


  Cisco
IPS
and
IDS
sensors
can
use
four
types
of
signature

triggers:

  Pa_ern‐based
detecEon

  Anomaly‐based
detecEon

  Policy‐based
detecEon

  Honeypot‐based
detecEon


  All
types
can
be
applied
to
both
atomic
and
composite

signatures.

51

Pa_ern‐based
detecEon

  Simplest
detecEon
mechanism.

  Searches
for
a
predefined
pa_ern.


  Network
traffic
is
cross‐referenced
with
a
database
of

known
a_acks
and
triggers.


  Atomic
example:

  DetecEng
an
ARP
request
with
the
FF:FF:FF:FF:FF:FF
source

address.

  Composite
example:

  Searching
for
a
character
string
in
a
sequence
of
TCP
Telnet

packets.

52

Anomaly‐based
detecEon

  Requires
defining
a
profile
that
is
considered
“normal”

  Regarding
traffic
amount,
protocol
types,
session
iniEaEon

frequency,
etc.

  The
network
must
be
free
of
a_acks
when
being
iniEally

inspected.


  Can
detect
new
and
unpublished
a_acks.

  Can
also
generate
many
false
posiEves.

  As
the
network
evolves,
the
definiEon
of
“normal”
must

be
constantly
updated.

  Harder
to
track
down
the
specific
a_ack

  Only
indicates
that
abnormal
traffic
pa_erns
were
detected.

53

Policy‐based
detecEon


  Similar
to
pa_ern‐based
detecEon

  Includes
pa_erns
that
define
suspicious
traffic
based
on

historical
analysis.


  Filters
certain
applicaEons
or
types
of
traffic
that
have

previously
caused
problems
within
the
network.


  Example:
a
client
trying
to
access
a
server
without
proper

authenEcaEon
credenEals.


54

Honeypot‐based
detecEon

  Uses
a
dummy
server
to
a_ract
a_acks.

  From
the
outside,
the
server
looks
like
a
vulnerable
host,

ready
to
be
compromised.

  The
server
concentrates
and
logs
all
a_acks.


  The
logs
can
be
analyzed
to
create
new
types
of

signatures.


55

IPS
signature
acEons

  Generate
an
alert

  Store
locally
or
send
an
event
through
the
network.

  Log
the
acEvity

  Log
a_acker,
vicEm
or
both
types
of
packets.

  Drop
or
prevent
acEvity

  Temporarily
or
permanently
deny
further
traffic.

  Drop
on
a
per‐packet
basis
or
forcefully
close
TCP
connecEon.

  Block
future
acEvity

  A
request
to
a
switch
or
router
can
be
sent
to
deny
a
certain

type
of
traffic.

  Allow
traffic


56

 Configuring
Cisco
IOS
IPS


57

Steps
for
implemenEng
IOS
IPS

  1:
Download
the
IOS
IPS
file

  2:
Create
an
IOS
IPS
configuraEon
directory
in
Flash

  3:
Configure
an
IOS
IPS
crypto
key

  4:
Enable
IOS
IPS

  5:
Load
the
IOS
IPS
signature
package
into
the
router


58

Downloading
the
IOS
IPS
file:
Cisco.com


  IOS‐Sxxx‐CLI.pkg
–
the
signature
package

  realm‐cisco‐pub‐key.txt
–
the
public
crypto
key
used
by
IOS
IPS

59

Create
a
configuraEon
directory
in
Flash

  Create
a
directory
in
Flash
to
store
the
signature
files
and

configuraEons:

R1#mkdir ips
Create directory filename [ips]?
Created dir flash:ips
R1#dir flash:
Directory of flash:/

2 -rw- 1652 Aug 13 2009 11:59:54 +00:00

pre_autosec.cfg
3 -rw- 1015 Nov 6 2009 16:30:22 +00:00 srs_ac.cfg
5 drw- 0 Nov 7 2009 16:28:16 +00:00 ips
4 -rw- 30588892 Nov 10 2007 16:13:02 +00:00 c2801-
advipservicesk9-mz.124-9.T.bin

64016384 bytes total (33415168 bytes free)

60

Configure
an
IOS
IPS
crypto
key


  Copy
the
public
key
file’s
contents
and
paste
it
into
global

configuraEon
mode.

  Removing
a
key:

no crypto key pubkey-chain rsa
no named-key realm-cisco.pub signature

61

Enabling
IOS
IPS
‐
rules

  Create
an
IPS
rule
names
IOSIPS:

R(config)#ip ips name IOSIPS

  OpEonally,
specify
an
ACL
to
filter
traffic:

R(config)#ip ips name IOSIPS2 list ACL

  Specify
the
locaEon
of
the
IPS
file:

R(config)#ip ips config location flash:ips

62

Enabling
IOS
IPS
‐
logging

  SDEE
(Security
Device
Event
Exchange)
is
a
protocol

running
between
IPS
clients
and
servers.

  Relies
on
HTTP/HTTPS
protocols.


R(config)#ip http server

R(config)#ip ips notify sdee
R(config)#ip ips notify log

  IPS
can
also
noEfy
via
syslog
(for
configured
syslog

desEnaEons).


63

Enabling
IOS
IPS:
signature
categories

  Signatures
are
grouped
into
hierarchical
categories.

  Common
categories:
all,
basic,
advanced.

  A
category
can
be:

  ReEred:
not
compiled
by
IOS,
unused

  Not
reEred:
compiled
and
used
to
scan
traffic

R(config)#ip ips signature-category
R(config-ips-category)#category all
R(config-ips-category-action)#retired true
R(config-ips-category-action)#exit
R(config-ips-category)#category ios_ips_basic
R(config-ips-category-action)#retired false
R(config-ips-category-action)#exit
R(config-ips-category)#exit
Do you want to accept these changes? [confirm] y
R(config)#
64

Enabling
IOS
IPS:
assign
the
rule
to
an
interface


  Applying
the
IOS
IPS
rule
to
an
interface:

R3(config-if)#interface FastEthernet0/0
R3(config-if)#ip ips IOSIPS in

  The
rule
can
be
applied
inbound,
as
well
as
outbound,
on

the
same
interface:

R3(config-if)#interface Serial0/1/1
R3(config-if)#ip ips IOSIPS in
R3(config-if)#ip ips IOSIPS out

65

Altering
individual
signatures

  ReEring
an
individual
signature
with
id
6130
and

subsignature
id
10:


R1(config)# ip ips signature-definition

R1(config-sigdef)# signature 6130 10
R1(config-sigdef-sig)# status
R1(config-sigdef-sig-status)# retired true
R1(config-sigdef-sig-status)# exit
R1(config-sigdef-sig)# exit
R1(config-sigdef)# exit
Do you want to accept these changes? [confirm] y
R1(config)#

66

Altering
categories

  UnreEre
an
enEre
category:


R1(config)# ip ips signature-category

R1(config-ips-category)# category ios_ips basic
R1(config-ips-category-action)# retired false
R1(config-ips-category-action)# exit
R1(config-ips-category)# exit
Do you want to accept these changes? [confirm] y
R1(config)#

67

Changing
a
signature’s
acEon

R1(config)# ip ips signature-definition
R1(config-sigdef)# signature 6130 10
R1(config-sigdef-sig)# engine
R1(config-sigdef-sig-engine)# event-action produce-alert
R1(config-sigdef-sig-engine)# event-action deny-packet-inline
R1(config-sigdef-sig-engine)# event-action reset-tcp-connection
R1(config-sigdef-sig-engine)# exit
R1(config-sigdef-sig)# exit
R1(config-sigdef)# exit
Do you want to accept these changes? [confirm] y
R1(config)#

  The
alert
states
that
signature
6130
with
subsignature
10

will
generate
an
alert,
drop
packets
and
close
the
TCP

connecEon
when
triggered.

68

Verifying
configuraEon


  The
show ip ips
privileged
EXEC
command
can
be
used
with
several

other
parameters
to
provide
specific
IPS
informaEon.


  The
show ip ips all command
displays
all
IPS
configuraEon
data.


  


  The
show ip ips configuration command
displays
addiEonal

configuraEon
data
that
is
not
displayed
with
the
show running-
config
command.



  The
show ip ips interface command
displays
interface


configuraEon
data.
The
output
from
this
command
shows
inbound
and

outbound
rules
applied
to
specific
interfaces.


69

“Expecting the world to treat you fairly
because you are a good person is a little like
expecting a bull not to attack you because
you are a vegetarian.”

Dennis
Wholey


70

 Goodbye
detected!


71