iewb sc vol i v5ddd.section.4.ips.012

8/11/2019 Iewb Sc Vol i v5ddd.Section.4.Ips.012

1/103

Accessed by rohitparda [email protected] from 115.240.81.217 at 20: 26:40 Nov 23,2009

CCIE Security Lab Workbook Volume I Version 5.0 IPS

Copyright 2009 Internetwork Expert www.INE.com 1

Copyright Information

Copyright 2009 Internetwork Expert, Inc. All rights reserved.

The following publication, CCIE Security Lab Workbook Volume I Version 5.0, was developed by Internetwork Expert,Inc. All rights reserved. No part of this publication may be reproduced or distributed in any form or by any meanswithout the prior written permission of Internetwork Expert, Inc.

Cisco, Cisco Systems, CCIE, and Cisco Certified Internetwork Expert, are registered trademarks of CiscoSystems, Inc. and/or its affiliates in the U.S. and certain countries.

All other products and company names are the trademarks, registered trademarks, and service marks of therespective owners. Throughout this manual, Internetwork Expert, Inc. has used its best efforts to distinguishproprietary trademarks from descriptive names by following the capitalization styles used by the manufacturer.


2/103




Disclaimer

The following publication, CCIE Security Lab Workbook Volume I Version 5.0, is designed to assist candidates in thepreparation for Cisco Systems CCIE Security Lab Exam. While every effort has been made to ensure that allmaterial is as complete and accurate as possible, the enclosed material is presented on an as is basis. Neither theauthors nor Internetwork Expert, Inc. assume any liability or responsibility to any person or entity with respect to loss

or damages incurred from the information contained in this workbook.

This workbook was developed by Internetwork Expert, Inc. and is an original work of the aforementioned authors. Any similarities between material presented in this workbook and actual CCIE lab material is completely coincidental.


3/103




Table of Contents Intrusion Prevention ............................................................................ 4

4.1 IPS Initial Setup ............................................................................... 4 4.2 Configuring Inline VLAN Pair ........................................................... 4 4.3 Creating Custom Signature.............................................................. 5 4.4 Event Counting ................................................................................ 5 4.5 Inline Blocking.................................................................................. 5 4.6 IPS VLAN Groups and Virtual Sensors............................................ 5 4.7 IPS Event Summarization ................................................................ 6 4.8 IPS Event Processing ...................................................................... 6 4.9 IPS Blocking and Rate-Limiting ....................................................... 6

4.10 IPS Application Inspection and Control............................................ 6 4.11 IPS META Engine............................................................................ 6 4.12 IPS Anomaly Detection .................................................................... 7 4.13 IOS IPS............................................................................................ 7

Intrusion Prevention Solutions ............................................................ 8 4.1 IPS Initial Setup ............................................................................... 8 4.2 Configuring Inline VLAN Pair ......................................................... 11 4.3 Creating Custom Signature............................................................ 14 4.4 Event Counting .............................................................................. 17 4.5 Inline Blocking................................................................................ 20

4.6

IPS VLAN Groups and Virtual Sensors.......................................... 22

4.7 IPS Event Summarization .............................................................. 30 4.8 IPS Event Processing .................................................................... 44 4.9 IPS Blocking and Rate-Limiting ..................................................... 55 4.10 IPS Application Inspection and Control.......................................... 72 4.11 IPS META Engine.......................................................................... 79 4.12 IPS Anomaly Detection .................................................................. 85 4.13 IOS IPS.......................................................................................... 95


4/103




Intrusion Prevention

NoteLoads the Inline IPS initial configuration and refer to the diagram below for thescenarios that follow.

4.1 IPS Init ial Setup Set up the IPS hostname to IPS. Configure IP addressing for management interface as per the diagram, set

default gateway to 10.0.0.254. Configure a management access-list to permit only host 10.0.0.100. Enable management via telnet server and set the login banner to Welcome to

IPS. Set the system clock. Configure the switches so that the AAA/CA server is on the same segment as the

IPS management interface.

4.2 Configuring Inline VLAN Pair Create a new subinterface number 1 and map VLANs 101 and 102 as VLAN pair

for this subinterface. Assign the subinterface to the analysis engine.


5/103




4.3 Creating Custom Signature Create new signature number 60005 that triggers on the strings % Bad

passwords found in Telnet sessions responses.

This signature should fire an alarm on every occurrence of the string.

4.4 Event Counting Tune the signature 60005 settings to alert only if three consecutive events occur

during the 3 minutes interval span.

4.5 Inline Blocking Change signature 60005 settings to deny attackers inline upon signature firing.

Note

Load the IPS Promiscuous Mode - GUI initial configuration prior to starting the followingtasks. Use the diagram below when working with the scenarios that follow.

4.6 IPS VLAN Groups and Virtual Sensors Ensure the IPS sensor monitors the traffic between R1/R2 and R3/R4. The traffic between the respective pairs should be inspected by different virtual

sensors in the IPS.


6/103




4.7 IPS Event Summarization Tune the ICMP echo signature so that it generates an alarm for every match

when detected between R1 and R2. For the traffic between R3 and R4, every ICMP echo packet should be reported

only if the amount of packets within 30 seconds does not exceed 15. Once the amount of ICMP packets exceeds 15 per 30 second, configure the IPS

to present only the maximally condensed report every 30 seconds.

4.8 IPS Event Process ing Configure the IPS sensor so that all ICMP echo packets sent to R2s Loopback0

subnet generate a host block request. If the ICMP packet is sourced from R1s Loopback0 interface, the block request

should be suppressed. Make sure the source/destination IP addresses for R1/R2 Loopback0 subnets

appear as meaningful names R1_LO0 and R2_LO0.

4.9 IPS Blocking and Rate-Limiting Configure the IPS sensor to block any fragmented ICMP echo packets towards

R3s Loopback0 subnet at R3s VLAN 34 interface. As soon as there is an ICMP flood detected between R3 and R4, configure R4 to

rate-limit the attacker to 25% of the input interface bandwidth.

4.10 IPS Application Inspection and Control Log any use of the HTTP CONNECT method and FTP DELETE command on the

segment between R1 and R2. Make the inspection as precise as possible and use the most specific engines.

4.11 IPS META Engine Configure the IPS to generate an alarm, once there is a group of ICMP pings of

10 packets generated towards R2s Loopback0 interface within 3 seconds

followed by a telnet session to the same IP that fails to authenticate at least twotimes in 60 seconds.

These two events should occur sequentially within 120 seconds at least.


7/103


8/103




Intrusion Prevention Solutions

4.1 IPS Init ial Setup Set up the IPS hostname to IPS. Configure IP addressing for management interface as per the diagram, set

default gateway to 10.0.0.254. Configure a management access-list to permit only host 10.0.0.100. Enable management via telnet server and set the login banner to Welcome to

IPS. Set the system clock. Configure the switches so that the AAA/CA server is on the same segment as the

IPS management interface.

Configuration

Note

For basic configuration of the sensor, you can also use the setup command on the IPSsensor, and step through the basic configuration. Also, this section configured a bannerfor logging into the device. For a production environment, it is not recommended tohave a login banner that may appear to be welcoming a potential intruder.

IPS: I PS# conf tI PS( conf i g) # ser vi ce hostI PS( conf i g- hos) # net work- set t i ngsI PS( conf i g- hos- net ) # host - name I PSI PS( conf i g- hos- net ) # host - i p 10. 0. 0. 10/ 24, 10. 0. 0. 254I PS( conf i g- hos- net ) # t el net - opt i on enabl edI PS( conf i g- hos- net ) # l ogi n- banner - t ext Wel come t o I PSI PS( conf i g- hos- net ) # access- l i st 10. 0. 0. 100/ 32I PS( conf i g- hos- net ) # exi tI PS( conf i g- hos) # exi tAppl y Changes: ?[ yes] : yesI PS( conf i g) # exi tI PS# cl ock set 17: 07 J anuar y 5 2010


9/103




Verification

Note

Make sure the management host is reachable and check your settings in the IPS:

IPS# ping 10.0.0.100PI NG 10. 0. 0. 100 ( 10. 0. 0. 100) : 56 dat a byt es64 byt es f r om 10. 0. 0. 100: i cmp_seq=0 t t l =128 t i me=2. 1 ms64 byt es f r om 10. 0. 0. 100: i cmp_seq=1 t t l =128 t i me=1. 8 ms64 byt es f r om 10. 0. 0. 100: i cmp_seq=2 t t l =128 t i me=0. 7 ms64 byt es f r om 10. 0. 0. 100: i cmp_seq=3 t t l =128 t i me=0. 5 ms

- - - 10. 0. 0. 100 pi ng s t at i s t i cs - - -4 packet s t r ansmi t t ed, 4 packet s r ecei ved, 0% packet l ossr ound- t r i p mi n/ avg/ max = 0. 5/ 1. 2/ 2. 1 ms

IPS# exit

Wel come t o I PSI PS l ogi n: cisco Passwor d:Last l ogi n: Fri J an 5 23: 49: 20 on t t yS0** *NOTI CE***

Thi s pr oduct cont ai ns cr ypt ogr aphi c f eat ur es and i s subj ect t o Uni t ed St at esand l ocal count r y l aws gover ni ng i mpor t , expor t , t r ansf er and use. Del i ver yof Ci sco cr ypt ogr aphi c pr oduct s does not i mpl y thi r d- par t y aut hor i t y t oi mpor t ,expor t , di st r i but e or use encrypt i on. I mpor t er s, expor t er s, di st r i but or s anduser s ar e r esponsi bl e f or compl i ance wi t h U. S. and l ocal count r y l aws. Byusi ngt hi s pr oduct you agr ee t o compl y wi t h appl i cabl e l aws and r egul at i ons. I f youar e unabl e t o compl y wi t h U. S. and l ocal l aws, r et ur n t hi s producti mmedi at el y.

A summar y of U. S. l aws gover ni ng Ci sco cr ypt ogr aphi c pr oduct s may be f ounda t :ht t p: / / www. ci sco. com/ wwl / expor t / crypt o/ t ool / st qr g. ht ml

I f you requi r e f ur t her assi st ance pl ease cont act us by sendi ng emai l t oexpor t @ci sco. com.

***LI CENSE NOTI CE** *

There i s no l i cense key i nst al l ed on t he sys t em. The sys t em wi l l cont i nue t o operat e wi t h t he cur r ent l y i nst al l edsi gnat ur e set . A val i d l i cense must be obt ai ned i n or der t o appl ysi gnat ur e updat es. Pl ease go t o ht t p: / / www. ci sco. com/ go/ l i censet o obt ai n a new l i cense or i nst al l a l i cense.I PS#


10/103




Note

Check the IP addressing

I PS# conf tI PS( conf i g) # ser vi ce hostI PS( conf i g- hos) # net work- set t i ngsI PS( conf i g- hos- net ) # show set t i ng

net wor k- set t i ngs- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

host - i p: 10. 0. 0. 10/ 24, 10. 0. 0. 254 def aul t : 10. 1. 9. 201/ 24, 10. 1. 9. 1host - name: I PS def aul t : sensort el net - opt i on: enabl ed def aul t : di sabl edaccess- l i st ( mi n: 0, max: 512, cur r ent : 1)- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

net work- addr ess: 10. 0. 0. 100/ 32- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -f t p- t i meout : 300 seconds l ogi n- banner - t ext : Wel come t o I PS def aul t :


11/103




4.2 Configuring Inline VLAN Pair Create a new subinterface number 1 and map VLANs 101 and 102 as VLAN pair

for this subinterface.

Assign the subinterface to the analysis engine.

Configuration

Note

Create an inline VLAN pair first

IPS:I PS# conf tI PS( conf i g) # ser vi ce i nt er f aceI PS( conf i g- i nt ) # physi cal - i nt er f aces Gi gabi t Et her net 0/ 0I PS( conf i g- i nt - phy) # subi nt er f ace- t ype i nl i ne- vl an- pai rI PS( conf i g- i nt - phy- i nl ) # subi nt er f ace 1I PS( conf i g- i nt - phy- i nl - sub) # vl an1 101I PS( conf i g- i nt - phy- i nl - sub) # vl an2 102I PS( conf i g- i nt - phy- i nl - sub) # exi tI PS( conf i g- i nt - phy- i nl ) # exi tI PS( conf i g- i nt - phy)# admi n- st at e enabl edI PS( conf i g- i nt - phy) # exi tI PS( conf i g- i nt ) # exi tAppl y Changes: ?[ yes] : yes

Note Assign the respective subinterface to the analysis engine

I PS( conf i g) # ser vi ce anal ysi s- engi neI PS( conf i g- ana) # vi r t ual - sensor vs0I PS( conf i g- ana- vi r ) # physi cal - i nt er f ace Gi gabi t Et her net 0/ 0 subi nt er f ace-number 1I PS( conf i g- ana- vi r ) # exi tI PS( conf i g- ana) # exi tAppl y Changes: ?[ yes] : yesI PS( conf i g) #


12/103




Verification

Note

In the output of show events below, you may see the ICMP alarm fire multiple times.You may also see other events, like the ARP reply - 7102. When done, press Control-Cto return to the prompt. There are also signatures available for ICMP echo and echo-reply, but those are not enabled by default.

R2#ping 136.1.12.1 repeat 100

Type escape sequence t o abor t .Sendi ng 100, 100- byt e I CMP Echos t o 136. 1. 12. 1, t i meout i s 2 seconds:. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !Success r at e i s 99 per cent ( 99/ 100) , r ound- t r i p mi n/ avg/ max = 4/ 4/ 20 ms

IPS# show events alert past 00:01:00

evI PSAl er t : event I d=1167967799445317083 sever i t y=medi um vendor=Ci scoor i gi nat or :

host I d: I PSappName: sensor AppappI nst anceI d: 331

t i me: 2007/ 01/ 05 03: 25: 23 2007/ 01/ 05 03: 25: 23 UTCsi gnat ur e: descr i pt i on=I CMP Fl ood i d=2152 ver si on=S1

subsi gI d: 0i nt er f aceGr oup:vl an: 102

par t i c i pant s :at t acker :addr : l ocal i t y=OUT 136. 1. 12. 2

t ar get :addr : l ocal i t y=OUT 136. 1. 12. 1os: I PSour ce=unknown r el evance=r el evant t ype=unknown

r i skRat i ngVal ue: at t ackRel evanceRat i ng=r el evant t arget Val ueRat i ng=medi um 85t hr eat Rat i ngVal ue: 85i nt er f ace: ge0_0pr ot ocol : i cmp

IPS# show interface GigabitEthernet0/0MAC st at i st i cs f r om i nt er f ace Gi gabi t Et her net 0/ 0

St at i s t i cs Fr om Subi nt er f ace 1St at i st i cs From Vl an 101

Tot al Packet s Recei ved On Thi s Vl an = 293 Tot al Byt es Recei ved On Thi s Vl an = 25120 Tot al Packet s Tr ansmi t t ed On Thi s Vl an = 108 Tot al Byt es Tr ansmi t t ed On Thi s Vl an = 12545

St at i st i cs From Vl an 102 Tot al Packet s Recei ved On Thi s Vl an = 108 Tot al Byt es Recei ved On Thi s Vl an = 12545 Tot al Packet s Tr ansmi t t ed On Thi s Vl an = 293


13/103




Tot al Byt es Tr ansmi t t ed On Thi s Vl an = 25120I nt er f ace f unct i on = Sensi ng i nt er f aceDescr i pt i on =Medi a Type = TXDef aul t Vl an = 0I nl i ne Mode = I nl i ne- vl an- pai rPai r St at us = N/ AHar dwar e Bypass Capabl e = NoHar dwar e Bypass Pai r ed = N/ ALi nk St at us = UpLi nk Speed = Aut o_100Li nk Dupl ex = Aut o_Ful lMi ss ed Packet Percent age = 0


14/103




4.3 Creating Custom Signature Create new signature number 60005 that triggers on the strings % Bad

passwords found in Telnet sessions responses. This signature should fire an alarm on every occurrence of the string.

Configuration

Note

In this section, the IPS is watching for a string in a telnet session. Here, we are lookingfor the string % Bad passwords. In the telnet session, this will be sent from the devicein response to three failed password attempts. Since this is traffic coming from thedevice to which we are trying to connect, the direction is from-service, and the trafficflow from that device will have a source port of 23. If we wanted to catch something that

was being typed in on the device trying to connect, the direction would be to-service.One additional item to consider for this type of attack notification is the swap-attacker-victim option under the signature. Looking at the output of the show events on the IPSabove, you can see that R2 is listed as the attacker. R2 is the device that is triggeringthe signature, but R2 is not the malicious device that we are trying to identify. Byadding the swap-attacker-victim option, the IPS will swap the two, and list R1 as theattacker, and R2s port 23 as the target.

IPS:I PS# conf tI PS( conf i g) # ser vi ce si gnat ur e- def i ni t i on si g0

I PS( conf i g- si g) # si gnat ur es 60005 0I PS( conf i g- si g- si g) # engi ne st r i ng- t cpI PS( conf i g- s i g- s i g- s t r ) # ser vi ce- por t s 23I PS( conf i g- s i g- s i g- s t r ) # di r ec t i on f r om- ser vi ceI PS( conf i g- si g- si g- st r ) # r egex- st r i ng % Bad passwor dsI PS( conf i g- s i g- s i g- s t r ) # exi tI PS( conf i g- si g- si g) # al er t - f r equencyI PS( conf i g- si g- si g- al e) # summar y- mode f i r e- al lI PS( conf i g- s i g- s i g- al e- f i r ) # exi tI PS( conf i g- s i g- s i g- al e) # exi tI PS( conf i g- s i g- s i g) # exi tI PS( conf i g- si g) # exi tAppl y Changes: ?[ yes] : yes


15/103




Verification

Note

Simulate the attack event using a telnet session fail IOS password authenticationthree times.

Rack1R1>telnet 136.1.12.2 Tr yi ng 136. 1. 12. 2 . . . Open

User Access Ver i f i cat i on

Passwor d: aPasswor d: aPasswor d: a

% Bad passwor ds[ Connect i on t o 136. 1. 12. 2 cl osed by f or ei gn host]

IPS# show events alert past 00:01:00

evI PSAl er t : event I d=1168711179445317231 sever i t y=medi um vendor=Ci scoor i gi nat or :

host I d: I PSappName: sensor AppappI nst anceI d: 331

t i me: 1993/ 04/ 16 05: 54: 51 1993/ 04/ 16 05: 54: 51 UTCsi gnat ur e: descr i pt i on=My Si g i d=60005 ver si on=cust om

subsi gI d: 0si gDet ai l s : My Si g I nf o

i nt er f aceGr oup:vl an: 102par t i c i pant s :

at t acker :addr : l ocal i t y=OUT 136. 1. 12. 2por t : 23

t ar get :addr : l ocal i t y=OUT 136. 1. 12. 1por t : 11002

cont ext :f r omTar get :

000000 FF FB 01 FF FB 03 FF FD 18 FF FD 1F 0D 0A 0D 0A . . . . . . . . . . . . . . . .

000010 55 73 65 72 20 41 63 63 65 73 73 20 56 65 72 69 User Access Ver i000020 66 69 63 61 74 69 6F 6E 0D 0A 0D 0A 50 61 73 73 f i cat i on. . . . Pass000030 77 6F 72 64 3A 20 FF FE 20 FF FD 21 FF FA 21 00 wor d: . . . . ! . . ! .000040 FF F0 FF FE 18 0D 0A 50 61 73 73 77 6F 72 64 3A . . . . . . . Passwor d:000050 20 0D 0A 50 61 73 73 77 6F 72 64 3A 20 . . Pass wor d:

f r omAt t acker :000000 FF FD 03 FF FB 20 FF FB 1F FF FB 21 FF FD 01 FF . . . . . . . . . . ! . . . .000010 FC 18 FF FA 1F 00 50 00 18 FF F0 FF FC 20 61 0D . . . . . . P. . . . . . a.000020 0A 61 0D 0A 61 0D 0A 0D 0A 25 20 42 61 64 20 70 . a. . a. . . . % Bad p


16/103




000030 61 73 73 77 6F 72 64 asswor d


17/103




4.4 Event Counting Tune the signature 60005 settings to alert only if three consecutive events occur

during the 3 minutes interval span.

Configuration

Note

Event counting allows for triggering an alarm only when a certain amount of eventsoccur during a specified interval. The alarms may further be summarized.

IPS: Rack1I PS# conf tI PS( conf i g) # ser vi ce si gnat ur e- def i ni t i on si g0I PS( conf i g- si g) # si gnat ur es 60005 0I PS( conf i g- si g- si g) # event - count erI PS( conf i g- si g- si g- eve) # event - count 3I PS( conf i g- s i g- s i g- eve) # spec i f y- al er t - i nt er val yesI PS( conf i g- si g- si g- eve- yes) # al er t - i nt er val 180! Exi t and appl y changes


18/103




Verification

Note

Simulate the attack event using a telnet session fail IOS password authenticationthree times.



Passwor d:Passwor d:Passwor d:

% Bad passwor ds[ Connect i on t o 136. 1. 12. 2 cl osed by f or ei gn host]



Passwor d:Passwor d:Passwor d:% Bad passwor ds

[ Connect i on t o 136. 1. 12. 2 cl osed by f or ei gn host]




[ Connect i on t o 136. 1. 12. 2 cl osed by f or ei gn host]


19/103




IPS# show events alert past 00:03:00 evI PSAl er t : event I d=1257561556185116142 sever i t y=medi um vendor=Ci sco

or i gi nat or :host I d: I PSappName: sensor App

appI nst anceI d: 383t i me: 2010/ 01/ 06 00: 50: 01 2010/ 01/ 06 00: 50: 01 UTCsi gnat ur e: descr i pt i on=My Si g i d=60005 ver si on=cust om

subsi gI d: 0si gDet ai l s : My Si g I nf omar sCat egory: I nf o/ Mi sc

i nt er f aceGr oup: vs0vl an: 102par t i c i pant s :

at t acker :addr : l ocal i t y=OUT 136. 1. 12. 1por t : 47794

t ar get :addr : l ocal i t y=OUT 136. 1. 12. 2por t : 23os: I PSour ce=unknown r el evance=r el evant t ype=unknown

cont ext :f r omTar get :

000000 FF FB 01 FF FB 03 FF FD 18 FF FD 1F 0D 0A 0D 0A . . . . . . . . . . . . . . . .000010 55 73 65 72 20 41 63 63 65 73 73 20 56 65 72 69 User Access Ver i000020 66 69 63 61 74 69 6F 6E 0D 0A 0D 0A 50 61 73 73 f i cat i on. . . . Pass000030 77 6F 72 64 3A 20 FF FE 20 FF FD 21 FF FA 21 00 wor d: . . . . ! . . ! .000040 FF F0 FF FE 18 0D 0A 50 61 73 73 77 6F 72 64 3A . . . . . . . Passwor d:000050 20 0D 0A 50 61 73 73 77 6F 72 64 3A 20 . . Pass wor d:

f r omAt t acker :000000 FF FD 03 FF FB 20 FF FB 1F FF FB 21 FF FD 01 FF . . . . . . . . . . ! . . . .000010 FC 18 FF FA 1F 00 50 00 18 FF F0 FF FC 20 61 0D . . . . . . P. . . . . . a.

000020 0A 61 0D 0A 61 0D 0A 0D 0A 25 20 42 61 64 20 70 . a. . a. . . . % Bad p000030 61 73 73 77 6F 72 64 asswor dr i skRat i ngVal ue: at t ackRel evanceRat i ng=r el evant t arget Val ueRat i ng=medi um 66t hr eat Rat i ngVal ue: 66i nt er f ace: ge0_0pr ot ocol : t cp

Wait for counters to reset (3 minutes) and fail logging just once:





20/103




4.5 Inline Blocking Change signature 60005 settings to deny attackers inline upon signature firing.

Configuration

Note

Inline blocking is only possible in the inline mode and in general is the most effectiveway to prevent an attack.

IPS: I PS# conf tI PS( conf i g) # ser vi ce si gnat ur e- def i ni t i on si g0I PS( conf i g- si g) # si gnat ur es 60005 0I PS( conf i g- si g- si g) # engi ne st r i ng- t cpI PS( conf i g- si g- si g- st r ) # event - act i on deny- at t acker - i nl i ne

I PS( conf i g- s i g- s i g- s t r ) # exi tI PS( conf i g- s i g- s i g) # exi tI PS( conf i g- si g) # exi tAppl y Changes: ?[ yes] : yes


21/103




Verification

Note

Simulate the attack event using a telnet session:

Rack1R1#telnet 136.1.12.2 Tr yi ng 136. 1. 12. 2 . . . Open


Passwor d:Passwor d:Passwor d:

IPS# show statistics denied-attackersDeni ed At t acker s and hi t count f or each.

136. 1. 12. 2 = 11St at i s t i cs f or Vi r t ual Sensor vs0

Deni ed At t acker s wi t h per cent deni ed and hi t count f or each.At t acker Addr ess Vi ct i m Addr ess Por t Prot ocol Request ed

Per cent age Act ual Per cent age Hi t Count136. 1. 12. 2 100

100 11

Note

In a testing environment, clearing all denied attackers may be a quick fix to be able to

test again. In an actual environment, you may want to specify a single attackeraddress, rather than clearing all entries.

Depending on how you configured the prior sections, you may see slightly differentresults. If you did not remove the event count from the prior section, you will need toconnect multiple times before the event is triggered, and the attacker is denied. Also,depending on whether you configured the swap attacker victim option, the attackermay be seen as either R1 or R2.

IPS# clear denied-attackersWar ni ng: Execut i ng t hi s command wi l l del et e al l addr esses f r om t he l i st of

at t acker s cur r ent l y bei ng deni ed by t he sensor .Cont i nue wi t h cl ear ? [ yes] : yes


22/103




4.6 IPS VLAN Groups and Virtual Sensors Ensure the IPS sensor monitors the traffic between R1/R2 and R3/R4. The traffic between the respective pairs should be inspected by different virtual

sensors in the IPS.

Configuration

Note

VLAN groups is a new addition in IPS 6.x code. It allows for partitioning the monitoringinterface into logical groups, where each group is a collection of VLANs. This impliesthat the traffic mirrored to the IPS appliance should be tagged with VLAN headers. Thebenefit of using VLAN groups is that you may associate the group with a subinterfaceand later assign the subinterface to a virtual sensor. With the ability to use multiplevirtual-sensor, VLAN groups allow for effective virtualization, by partitioning traffic

streams in logical groups. Cisco IPS supports 802.1q encapsulation for VLAN groups all untagged frames or frames with ISL encapsulation are mapped to a special VLANgroup called unassigned. This special group could be assigned to a subinterace aswell.

In order to create a VLAN group, enter the physical interface configuration mode, usingthe commands service interface and physical-interfaces . Makesure you entered the command admin-state enabled to bring the physicalinterface up. After that, enter the subinterace configuration mode using the commandsubinterface-type vlan-group this will put you in the VLAN group configuration mode.Here you should create logical subinterface and map VLAN groups to them. Thecommands are

subi nt er f ace vl ans r ange VLAN1, , VLANn

subi nt er ace vl ans r ange VLAN1, , VLANn

You may use the command vlans range unassigned to map all VLANs notexplicitly selected to a subinterface. This includes untagged frames, such as framesreceived on the native 802.1q VLAN and frames tagged with ISL encapsulation. Bydefault, all such frames are reported as belonging to VLAN 0 in the IPS output. You maychange the default VLAN number using the following command:

ser vi ce i nt er f acephysi cal - i nt er f aces Gi gabi t Et her net 0/ 0

def aul t - vl an 1- 4095


23/103




When you configure monitoring in Catalyst switches, make sure the destination port isconfigured with encapsulation dot1q option this will ensure tagging on theframes dumped to the monitoring interface. In order to create a flow of tagged traffic,you either need to monitor a trunk port as a source, monitor multiple interface indifferent VLANs or monitor multiple source VLANs. For example:

monitor session 1 source interface FastEtherent 0/3 both where Fa0/3 is a trunk;

monitor session 1 source interface Fa 0/1 , Fa 0/2 both where Fa0/1 and 0/2 are in different VLANs;

monitor session 1 source vlan 101 , 102, 103 rx captures traffic onmultiple VLANs in the switch. There is a special trick to monitor multiple VLANs alongwith RSPAN VLAN.

Generally, when you specify monitoring source from RSPAN VLAN, you can monitor just that VLAN: monitor session 2 source remote vlan 100 ; however, if youwant to combine RSPAN traffic with local VLAN traffic, you may simply add the RSPANVLAN to VLAN list using the command monitor session 1 source vlan 100,999 where 999 is an RSPAN VLAN.

Now lets briefly discuss virtual sensors. Since version 6.0 you may partition theanalysis engine into multiple virtual sensors, with the default sensor being vs0. Everyvirtual sensor has its own policy: signature definition, event action rules and anomalydetection. Every sensor may be associated with a group of physical interface and orlogical subinterface. The command to map the subinterface to a virtual sensor are as

follows:

ser vi ce anal ysi s- engi nevi r t ual - sensor vs0

physi cal - i nt er f ace Gi gabi t 0/ 0 subi nt er f ace- number 1vi r t ual - sensor vs1

physi cal - i nt er f ace Gi gabi t 0/ 0 subi nt er f ace- number 2

The benefit is that you may implement multiple IPS policies in the same appliance, e.g.policies for pre-firewall and post-firewall traffic, which usually require separate IPSes.There are some restrictions to the virtual sensors, though. Basically, you need to make

sure that a virtual sensor sees all packets for every flow inspected. That means, youneed to make sure that a packets enters the IPS sensors and maps to one vritualsensor, and the returning packet maps to a different virrtual sensor. This may happenwith asymmetric routing enabled in you network, where the returning flows are not inline with the initiated flows.


24/103




SW1: vl an 999

r emot e- span!moni t or sessi on 1 sour ce vl an 12 r xmoni t or sessi on 1 dest i nat i on r emot e vl an 999 r ef l ect or - por t gi gabi t Et her net

0/ 1SW2: vl an 999

r emot e- span!moni t or sessi on 1 sour ce vl an 34 , 999 r xmoni t or sessi on 1 dest i nat i on i nt er f ace f ast Et her net 0/ 10 encapsul at i on dot1q

IPS: !! Configure sensor management !sensor # conf tsensor ( conf i g) # ser vi ce hostsensor ( conf i g- hos) # net wor k- set t i ngssensor ( conf i g- hos- net ) # host - i p 10. 0. 0. 10/ 24, 10. 0. 0. 1sensor ( conf i g- hos- net ) # access- l i st 10. 0. 0. 100/ 32sensor ( conf i g- hos- net ) # access- l i st 10. 0. 0. 200/ 32sensor ( conf i g- hos- net ) # exi tsensor ( conf i g- hos) # exi tAppl y Changes?[ yes] : yes

!! Configure VLAN groups. Notice the use of VLAN 999! for the first group, as VLAN12 has been RSPANed to SW2 !

sensor ( conf i g) # ser vi ce i nt er f acesensor ( conf i g- i nt ) # physi cal - i nt er f aces gi gabi t Et her net 0/ 0sensor ( conf i g- i nt - phy) # admi n- st at e enabl edsensor ( conf i g- i nt - phy) # subi nt er f ace- t ype vl an- gr oupsensor ( conf i g- i nt - phy- vl a) # subi nt er f ace 1sensor ( conf i g- i nt - phy- vl a- sub) # vl ans r ange 999sensor ( conf i g- i nt - phy- vl a- sub) # exi tsensor ( conf i g- i nt - phy- vl a) # subi nt er f ace 2sensor ( conf i g- i nt - phy- vl a- sub) # vl ans r ange 34sensor ( conf i g- i nt - phy- vl a- sub) # exi tsensor ( conf i g- i nt - phy- vl a) # exi tsensor ( conf i g- i nt - phy) # exi tsensor ( conf i g- i nt ) # exi tAppl y Changes?[ yes] : yes


25/103




!! Associate VLAN groups with virtual sensors !sensor ( conf i g) # ser vi ce anal ysi s- engi nesensor ( conf i g- ana) # vi r t ual - sensor vs0sensor ( conf i g- ana- vi r ) # physi cal - i nt er f ace gi gabi t Et her net 0/ 0 subi nt er f ace-number 1sensor ( conf i g- ana- vi r ) # exi tsensor ( conf i g- ana) # vi r t ual - sensor vs1sensor ( conf i g- ana- vi r ) # physi cal - i nt er f ace gi gabi t Et her net 0/ 0 subi nt er f ace-number 2sensor ( conf i g- ana- vi r ) # exi tsensor ( conf i g- ana) # exi tsensor ( conf i g) # exi t


26/103




Verification

Note

To verify your configuration, run the IDM from the Test PC by connecting tohttps://10.0.0.10 . Check the virtual sensor status and notice the VLAN groups mappedto the sensors.


27/103




Note

Now enable the signature number 2004 (ICMP Echo) in the sig0 signature rulesdefinition. This is the default signature policy used by all virtual sensors. After this, go toR1 and ping a network at R2. This should trigger an informational alarm in the IPS.


28/103




Rack1R1#ping 150.1.2.2

Type escape sequence t o abor t .Sendi ng 5, 100- byt e I CMP Echos t o 150. 1. 2. 2, t i meout i s 2 seconds:! ! ! ! !Success r at e i s 100 per cent ( 5/ 5) , r ound- t r i p mi n/ avg/ max = 1/ 3/ 4 ms

Note

Now go to Monitoring > Events > View and check for the latest IPS events forvs0 virtual sensor. After this, repeat the test with R3 and R4 and check that there is anevent generated for vs1.


29/103







30/103




4.7 IPS Event Summarization Tune the ICMP echo signature so that it generates an alarm for every match

when detected between R1 and R2. For the traffic between R3 and R4, every ICMP echo packet should be reported

only if the amount of packets within 30 seconds does not exceed 15. Once the amount of ICMP packets exceeds 15 per 30 second, configure the IPS

to present only the maximally condensed report every 30 seconds.

Configuration

Note

Event summarization is an important feature of IPS signature alerting, as it allowsreducing the load of information and protecting against IPS evasion tools, such as Stick.These tools attempt to create a huge load of non-relevant IPS events, overloading thesensor and hiding the actual attack within the decoy alerts. To resist this type of attack,Cisco IPS implements event counting and summarization, effectively performing two-level summarization.

The first summarization level is known as event counting. Its purpose is to countrepetitive events, and fire an alarm only when the certain threshold is reached. An eventis defined as repetitive if it triggers the same signature and parameters specified by theevent-count-key match. Event count key is essentially a mask that selects fields forcounting unique events from the following list attacker IP, attacker port, victim IP, victimport.

For example key Axxx would select just the attacker IP address to define repeatingevents. If two attackers generate ICMP echo events, than those two will be countedseparately; but no matter how many targets they would ping, there will be just two seriesof events counted. If the key is xxxB than it selects the victim IP address, and the seriesof events will be generated based on unique victim addresses. For example if tenattackers generate packets to three victims, then only two separate series of countingwill occur, for every victim. The other two keys are AxBx and AaBb meaning attackerIP/victim port and attacker/victim IP/ports, with the later generating the most amountof separate event series.

Every time a signature fires, the IPS starts counting the events until the value specifiedby the variable event-count is reached, and generates an aggregated alarm afterthis, reporting the total number of repetitive event for every unique sequence tracked.By default event-count=1 , and thus every signature match generates an event. Afterthis, the event counter is reset back to zero.


31/103




In addition to unconstrained counting, it is possible to define a time-interval over whichto perform counting. With the interval defined, the event counter for a given signature isreset to zero every alert-interval , which is a signature attribute. This allows fortriggering an alarm only if the rate of repetitive events exceeds the threshold. Forexample, you may only want to trigger an alarm if there are 100 ICMP echo packetssend within the interval of 20 seconds. You set event-count to 100 and alert-interval to 20 seconds. There will be no event triggered unless the rate gets above100/20 hits/second. Look at the figure below for a sample configuration with event-count=3 .

After the event counting procedure follows event summarization, which is the secondlayer of aggregation. It applied fixed time intervals and summarizes information forevents within this interval into a single report. For every signature, you may selectdifferent alarm summarization mode. The first and most simple one, called Fire-Allwould generate an alarm for every event produced by event counting.

The next and the default mode is known as summarize . When this mode is configuredfor a signature, the special parameter known as summary-interval is used toperform aggregation. The IPS counts every summary-interval seconds for thesignature, and detects the first alert during the interval. This first alert is reportedimmediately. All subsequent hits within the interval are delayed, and reported only whenthe summary-interval expires. If there are events in subsequent intervals, they will

have only ONE summary event generated, until there is an interval with NO events atall. After this, the IPS will get back to generating an alert for the first event and summaryfor the interval.


32/103


33/103




The final report for every summary-interval is condensed based on the summary-key setting for the signature. The concept of key is widely used for aggregationpurposes. Here it defines the fields that could be aggregated and ignored amongdifferent events detected. Effectively, the key is the mask that selects relevant fieldsfrom attacker/victim IP address/ports pairs and stores them while performingsummarization or counting. Here are the key values and the diagram to illustrate theireffect when performing event summarization:

Axxx means that events are summarized using the attackers IP address as the key. A summary report will be generated for every attackers IP address, and all otherinformation, including the attackers port, victims IP address and port will besummarized and ignored. For example, if you take the figure from above, there will be 3entries in the summary event, one for every attacker

Axxb means the attackers IP and the victim ports are the key. For every combinationof an attacker IP address and victim port a summary report is generated. If we return tothe figure, there could be from 3 to 6 entries in the resulting report, based on whether

the ports used for attack are the same or all different.

AxBx the summary events are created for every attacker/victim address pair detectedduring the summary-interval. Referring to the figure, this key will result in 6 entries in thereport.


34/103




AaBb the summary report will contain an entry for every combination of attacker/victimIP/port addreses. This form of report contains the most amount of information and wouldgenerate from 6 to 36 entries for the above report, with 36 being the case when allsource and destination ports are different.

xxBx creates an entry in the summary report for every victim. This is the opposite to Axxx and would generate two entries in the report for the firgure above.

Notice that summary-keys are pre-configured for every signature and should not bemodified unless that is really needed.

The next summarization mode is knows as Fire-Once . During the summary-interval , there will be one alert generated for every unique event based on thesummary-key to define uniqueness For example, if the key is Axxx there will be one

alarm generated for every attacker IP address; If the key is Axxxb there will be onealarm generated for every first matching packet with uniques attacker source and victimport address.

The most intense alert summarization mode is known as global-summarize . Thismode will report a summary at the end of every summary-interval, with just the generalinformation about the attack, like the number of packets matched, and no informationstored about the attackers or victims.

The alarm summarization modes described above where fixed, i.e. their behavior doesnot change with time. However, it is possible to configure a signature to switch between

the summarization modes, based on the amount of alarms generated. This allows forautomatic adaption to the attack behavior, damping the amount of events aggressivelywhen the there is a flood of the attacks, and allowing for more detailed view when theload is low. This is know as variable summarization. It is implemented as follows: forevery summary mode selected, you may configure a threshold level of alarms thatshould be reached during the current summary-interval in order to change the summarymode. Changing the summarization mode is called upgrading the summarization modein IPS term. It is possible to do the following upgrade sequences:

Fi r e- Al l - > Summar i ze - > Gl obal - Summar i zeFi r e- Once - > Gl obal - Summar i ze

Summar i ze - > Gl obal - Summar i ze


35/103




The upgrades are performed based on the two thresholds set for a signature:summary-threshold and global-summary-threshold . For example, assume thatyou have a signature configured as follows:

Summar y Mode: Fi r e- Al lSummar y- I nt er val : 300 secondsSummar y- Threshol d: 100Gl obal - Summar y- Thr eshol d: 200

Lets assume that during the first summary-interval there were 50 events. That meansthat the next interval will not use any upgrades and continue using Fire-All mode.Now, assume that the second interval produced 120 events. That means that the thirdinterval will upgrade and use the Summarize method to produce alarms. If there wouldbe above 200 events during the thirds interval, the summarization mode will change toglobal-summarize . If during some interval the amount of events will fall below both

thresholds, the signature will return to normal summarization mode.


36/103




Note

We are going to use IDM for this tasks configuration. The first thing is to create a copyof the signature defignition sig0 and call it sig1. The second set is then assigned to thevirtual sensor vs1. We start by running the IDM and navigration to Configuraiton >Policies > Signature Definition . On the screen that appears, select sig0signature definition and click the Clone button name the new set as sig1 .


37/103


38/103




Note

Now edit the summary mode for the ICMP Echo signature in sig0 signature set. Go toConfiguration > Policies > Signature Definition > sig0 and locate theICMP Echo signature which is 2004. Make sure it is enabled and change the summarymode to Fire All.


39/103




Note

Next edit the summary mode for the ICMP Echo signature in sig1 signature set. Go toConfiguration > Policies > Signature Definition > sig1 and locate theICMP Echo signature which is 2004. Make sure it is enabled and change the summarymode to Fire All. After this, edit the signature settings per the screenshot below (noticethe red fields that have changed).


40/103




Verification

Note

First, generate some ICMP traffic between R1 and R2. Check the IDM event viewer forlast minute events right after that ( Monitoring > Events ) There should be fiveevents generated for every occurrence of an ICMP packet.




41/103




Note

Now generate the same 5 packet ping traffic between R3 and R4. Check the events forthe last minute in the IPS event viewer.

Rack1R3#ping 150.1.4.4 repeat 5



42/103




Note

Now wait for about a minute, and generate 10 pings packets. Wait about 30 secondsand generate another set of 10 packets. Get back to the event view in the IDM, andcheck the events that occurred last minute. There should be 10 events fired during thefirst interval, and one summary event generated for the second interval, due to thesummarization upgrade.


43/103




Note

Check the details for the summary event, and notice that it only contains the victims IPaddress (target/addr).


44/103




4.8 IPS Event Process ing Configure the IPS sensor so that all ICMP echo packets sent to R2s Loopback0

subnet generate a host block request. If the ICMP packet is sourced from R1s Loopback0 interface, the block request

should be suppressed. Make sure the source/destination IP addresses for R1/R2 Loopback0 subnets

appear as meaningful names R1_LO0 and R2_LO0.

Configuration

Note

Once a signature generates and event, the event goes through a series of eventprocessing rules. These rules define whether to actually trigger and event and whataction to associate with it. Here are the key concepts used in event processing:

1) Event Variables (allow for macro variables to be used with event processing)2) Target Value Rating (TVR, defines the importance of a particular resource)3) Event Action Override (change the action for a specific event)4) Event Action Filters (damp specific events)

Event Variables

These are normal variables that could be used the even output, i.e. the output you seein the IPS logs. For example, you may want to give meaningful names to your networkranges, such as MANAGEMENT to 10.0.0.0/24 and SALES to 10.0.1.0/24. You coulddefine these macro variables by going to Configuration > Event Action Rules> Event Variables . So far, all variable are of type address.

Target Value Rating

This value specifies the importance of a particular network resource, and used whencalculating a Risk Rating (RR) for a particular event. You assign TVR to an IP addressrange, using the values Mission Critical (200), High (150), Medium (100), Low (75). Youmay use the variables defined previously when working with TVR configuration. We willsee how TVR is used later for RR computations.


45/103




Event Action Override

This feature allows for changing the default signature action (e.g. produce event todeny attacker inline) if the event Risk Rating (RR) falls within a certain range. Thisallows for accounting for user-defined TVR assigned to corporate assets and changingthe event action if the event appears to be more dangerous than it looked originally.Here is the formula for RR calculations:

RR = (ASR*TVR*SFR )/10000 + ARR PD

ASR Attack Severity Rating. Taken from the Severity field for signature configurationand could take the following values: 25 (Information), 50 (Low), 75 (Medium), or 100(High). This is configured by Cisco by default for all signatures.

TVR Target Value Rating discussed previously, ranges from 75 to 200.

SFR Signature Fidelity Rating, defines how much is the signature accurate, i.e. whatis the risk of a false positive. This field is assigned to every signature and takes valuesfrom 0 to 100. You should not change the default values assigned by Cisco unlesswhen its really needed.

ARR Attack Relevance Rating. This value is calculated by IPS automatically, for agiven event and victim IP address. The IPS correlates the operating system passivelydetected for the victim system and the list of vulnerable OSes configured for thesignature. Based on this, the relevance rating is calculated. For example, an IIS attackis probably not relevant for the UNIX server.

PD Promiscuous Delta; this value is set for every signature and specifies the amountof points that should be deducted from RR if the IPS is in promiscuous monitoringmode. The idea is that promiscuous monitoring is less reliable than inline, and thus theoverall risk might be overestimated. The range for PD is from 0 to 30.

Every event action override rule defines a range of RR value, and the action to producewhen the events risk rating falls within this range. For example, you may configure sothat

90 < Risk Rating < 100 => deny packet inline (the default Cisco rule).

Defining an actual range requires understanding of the RR formula and manipulation ofTVRs set for network resources. In order to create an action override rule, go toConfiguration > Policy > Even Action Rules > Event ActionOverride and click the Add button. You will have to define the action and the RRrange.


46/103




OS Identification

As mentioned previously, IPS automatically calculates ARR based on the OS typedetected for the victim. The detection is based on passive OS fingerprintin or POSFPprocedure. In addition to automatic detection, you may provide OS informationmanually, by going to Configuration > Policies > Event Action Rules >OS Identification and add OS to IP address block association manually. You mayaso enable passive OS fingerprinting under the same tab. Like we said previously,every signature has a list of vulnerable OSes and this list is used to calculate the ARR.

Event Action Filtering

The idea of action filtering, is subtracting the action associated with an event, if theevent matches certain criteria. Among the criteria, there is signature ID, risk ratingrange, attacker/victim IP addresses/ports and so on. Every filter also has the action tosubtract from the matching event. For example, you may want to delete the deny-attacker-inline action for all events with RR in range 30-50. Event filtering applies afterevent overriding, so you have a change to decline the decision made at the previousstep.

To create a new Event Action Filter go to Configuration > Policies > Event Action Rules > Event Action Filter from within the IDM menu.


47/103




As for the task solution. Normally, ICMP Echo is informational signature with highfidelity:

Thus, if we look at the formula for RR, we already have some values defined:

RR = 25*TVR*100/ 10000 + ARR = TVR/ 4 + ARR.

Now it is apparent that the RR could be at maximum 200/4+ARR=50+ARR. If we set the

RR range to 50..60 and set the TVR to Mission-Critical this will catch the event. Inaddition to that, the new event action rule should define action host block request.

Next, we should create an event filtering rule, that matches the source of R1sLoopback0 and RR range 50..60 for ICMP Echo signature. We should configure thisrule to subtract the block-host action.


48/103




Note

Start the configuration process by defining Event Variables R1_LO0 and R2_LO0 underConfiguration > Policies > Event Action Rules > Event Variables


49/103




Note

Assign the maximum TVR to R2s Loopback0 subnet. Go to Configuration >Policies > Event Action Rules > Target Value Rating.


50/103




Note

Creat an Event Action Override rule. Set the ristk rating range to 50-60 and settheaction to Request Block Host.


51/103




Note

Finally, create an Event Action Filter, that matches the signature 2004 and attackeraddress range 150.1.1.1-150.1.1.254 and subtracts the previously defiened blockaction.


52/103




Verification

Note

First, ping R2s Loopback0 from R1. After this, check the events for the last one minute.Notice that there are 5 alerts and one error notifying you that there are no blockingdevices. This means, that the action has been overridden.


Type escape sequence t o abor t .Sendi ng 5, 100- byt e I CMP Echos t o 150. 1. 2. 2, t i meout i s 2 seconds:! ! ! ! !Success r at e i s 100 percent ( 5/ 5) , r ound- t r i p mi n/ avg/ max = 1/ 2/ 4 m


53/103




Note

Next, ping R2s Loopback0 sourcing packets off R1s Loopback0 interface. Notice thatnow there are five alerts in the event log. Check the details for any of the latest alerts.

Rack1R1#ping 150.1.2.2 source loopback 0

Type escape sequence t o abor t .Sendi ng 5, 100- byt e I CMP Echos t o 150. 1. 2. 2, t i meout i s 2 seconds:Packet sent wi t h a sour ce addr ess of 150. 1. 1. 1! ! ! ! !Success r at e i s 100 per cent ( 5/ 5) , r ound- t r i p mi n/ avg/ max = 1/ 3/ 4 ms


54/103




Note

Here you can see the Risk Rating of 60 (due to the addition of ARR=10) andattacker/target addresses mapped to the locality names we defined in the IPS: R1_LO0and R2_LO0.


55/103




4.9 IPS Blocking and Rate-Limiting Configure the IPS sensor to block any fragmented ICMP packets towards R3s

Loopback0 subnet at R3 VLAN 34 interface. As soon as there is an ICMP flood detected between R3 and R4, configure R4 to

rate-limit the attacker to 25% of the input interface bandwidth.Configuration

Note

In promiscuous mode, the IPS has three basic ways to actively prevent a networkattack: block the attacker, rate-limit the attacker flow or send a TCP reset. Theseactions are performed by the system component known as Attack Response Controlleror ARC. Generally, the IPS communicates with external devices such as routers,firewalls and switches to implement the blocking action. Communications are performed

using telnet or SSH as transport protocols. The IPS emulates a user session andconfigures devices for attack response actions.

In order to add network devices under IPS control, you need to perform the followingsteps:

1) Configure Network Devices.2) Add Device Login Profiles to the IPS.3) Add Blocking Devices to the IPS.4) Configure Blocking Interfaces.5) Configure Signature Actions respectively.

Configure Network Devices.

During this step, you configure the routers and firewall with the necessary settings toallow remote access. The IPS could use either Telnet or SSH protocols to access theremote devices. You may need to create a separate user in the devices for the IPSappliance. Based on your device configuration, you may need just one password toaccess the route remotely and drop into enable mode instantly, or have a separateenable password required.


56/103




Add Device Login Profiles to the IPS .

This is where you create objects representing device access credentials to the IPS. Toadd a new profile, go to Configuration > Blocking > Device LoginProfiles and click the Add button. Every profile has a login name and password andthe enable password. In some situations, you may not need the login name orpassword, such as when the router is configured to authenticate just using the linepassword.

Add Blocking Devices to the IPS.

At this step, you add the objects representing remote devices to the IPS. Follow toConfiguration > Blocking > Blocking Devices to access this feature. Everyblocking device has an IP address, a Device Login Profile associated, DeviceType (Cisco router, PIX/ASA, Catalyst 6000), list of capabilities (block/rate-limit) and the

protocol to use for communicating with the device (Telnet or SSH). Naturally, theprotocol selected and the device type should match the remote device settings. Somedevices may not support the rate-limiting capability, as this one is typically associatedwith Cisco routers only. Notice the special setting called Sensors NAT Interface .When the IPS sensor applies blocking to a device, it makes sure its own IP address isnot affected by the blocking configuration. The IPS automatically discovers its own IPaddress, but in case when the IPS control interface is behind a NAT device, this isimpossible. In such situation you should configure the post-NAT IP address for theparticular device manually, and this IP address will always remain unblocked.

If you are using SSH for device communication, make sure you requested and accepted

the SSH RSA server keys. Without this step, the IPS will reject the remote host identity.In real life, you are supposed to check the public key received and make sure it belongsto the correct device. This step could be done using IDM by going to Configuration> SSH > Known Host Keys , clicking the Add button and entering the remote deviceIP address.


57/103




Configure Blocking Interface.

With Cisco routers, the IPS applies blocking configuration to an interface that you selectat this step. On contrary, shunnig is global on devices such as PIX/ASA and those donot require blocking interfaces selected. When you navigate to Configuration >Blocking > Router Blocking Devices Interfaces you may add an interface,specify it name (no spaces) and associate it with a blocking device. Notice that you mayspecify the direction to apply blocking (inbound or outbound) which actually means thedirection to apply an access-list or service policy. In addition to this, you may alsospecify the device-specific access-lists that should be merged with the access-listconstructed by the IPS. For example, if you already had an access-list configured on theinterface, you may want it to be prepended to the list applied by the IPS. In this case, itis the pre-block ACL. If you want the local access-list to be appended to the IPS ACL,configure the list name as a post-block ACL.

Configure Signature Actions.

You may want to tune some of your signatures to apply the blocking or rate limitingactions in addition to simply reporting an event. Finally, remember that the IPSappliance is not aware of the network topology. Thus, it will apply blocking or rate-limiting actions to all capable devices, when responding to an event. Assuming this, youmay want to adjust the number of network devices controlled by a given IPS to be inimmediate proximity to the IPS controlled zone.


58/103




Note

Start by configuring both routers for SSH and creating the necessary user for remoteaccess. After this, add the SSH public keys to the IPS know hosts database.

R3 & R4: username ci sco passwor d ci sco!i p domai n- name I NE. comcr ypt o key gener at e r sa modul us 768 gener al!l i ne vt y 0 4

l ogi n l ocal


59/103




Note

In the IDM, go to Configuration > SSH > Know Host Keys and click the Add button. Enter the IP address of 10.0.0.3 and click the Retrieve Host Key button. Repeatthis procedure with the IP address 10.0.0.4.


60/103




Continue adding R3 as the blocking device to the IPS. In the IDM, navigate toConfiguration > Blocking > Device Login Profiles and click the Add button.


61/103




Note

Repeat the same step with R4, but configure this device for rate-limiting.


62/103




Note

Now go to Configuration > Blocking > Router Blocking DeviceInterfaces and add interfaces for R3 and R4. Use the interface nameFastEthernet0/1 and Inbound direction for this.


63/103




Note

Locate the Apache signature go to Configuration > Policies > SignatureDefinition > sig1 (we configure vs1 virtual sensor) and select the Web Serversignature group. Locate the signature 2004, and click the Clone button. This will createnew custom signature 60000. Edit the Fragment Status field for the new signatureand set it to Fragmented and change the Event Action attribute to Request BlockHost and Produce Alert


64/103





65/103




Note

Now select the DoS signature group and locate the signature 2152 ICMP Flood.Change the signature action to request rate limit and set the bandwidth limit to 25%.


66/103




Verification

Note

Generate a flood of packets from R3 to R4.

Rack1R3#ping 150.1.4.4 repeat 100

Type escape sequence t o abor t .Sendi ng 100, 100- byt e I CMP Echos t o 150. 1. 4. 4, t i meout i s 2 seconds:! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !Success r at e i s 100 per cent ( 100/ 100) , r ound- t r i p mi n/ avg/ max = 1/ 4/ 76 ms

Note

Go to Monitoring > Events and check the Show Attack Response Controllerevents checkbox. Request the latest events and notice that there are a few Rate LimitRequest events. Look at any of these events in details:


67/103





68/103




Note

Now login to R4 and check the VLAN34 interface configuration. Notice the rate-limitingservice policy applied to the interface, and check the policy parameters.

Rack1R4#sh running-config interface fastEthernet 0/1Bui l di ng conf i gur at i on. . .

Cur r ent conf i gur at i on : 137 byt es!i nt er f ace Fast Et her net 0/ 1

i p address 136. 1. 34. 4 255. 255. 255. 0dupl ex aut ospeed aut oser vi ce- pol i cy i nput I DS_RL_POLI CY_MAP_1

end

Rack1R4#show policy-map interface fastEthernet 0/1Fast Et her net 0/ 1

Ser vi ce- pol i cy i nput : I DS_RL_POLI CY_MAP_1

Cl ass- map: I DS_RL_CLASS_MAP_i cmp- xxBx- 8- 25_1 ( mat ch- any)0 packet s, 0 byt es5 mi nut e of f er ed r at e 0 bps, drop r at e 0 bpsMat ch: access- gr oup name I DS_RL_ACL_ i cmp- xxBx- 8- 25_1

0 packet s, 0 byt es5 mi nut e r at e 0 bps

pol i ce:ci r 25 %

ci r 25000000 bps, bc 781250 byt esconf ormed 0 packet s, 0 byt es; act i ons:

t r ansmi texceeded 0 packet s, 0 byt es; act i ons:

dr opconf or med 0 bps, exceed 0 bps

Cl ass- map: cl ass- def aul t ( mat ch- any)0 packet s, 0 byt es5 mi nut e of f er ed r at e 0 bps, drop r at e 0 bps

Rack1R4#show ip access-lists IDS_RL_ACL_icmp-xxBx-8-25_1Ext ended I P access l i st I DS_RL_ACL_i cmp- xxBx- 8- 25_1

10 per mi t i cmp any host 150. 1. 4. 4 echo


69/103




Note

Ping R3 from R4 with fragmented packets and check the Event Log, including the ARCevents. Notice the alerts produced and the block requests originated by the sensor.

Rack1R4#ping 150.1.3.3 repeat 5 size 1600



70/103




Note

Now check the active host blocks in the sensor and check the configuration applied toR3: in the IDM navigate to Monitoring > Active Host Block and notice that R4sIP address is there.


71/103




Rack1R3#sh running-config interface fastEthernet 0/1Bui l di ng conf i gur at i on. . .

Cur r ent conf i gur at i on : 140 byt es!i nt er f ace Fast Et her net 0/ 1

i p address 136. 1. 34. 3 255. 255. 255. 0i p access- gr oup I DS_Fast Et her net 0/ 1_i n_0 i ndupl ex aut ospeed aut o

end

Rack1R3#show ip access-listsExt ended I P access l i st I DS_Fast Et her net 0/ 1_i n_0

10 permi t i p host 10. 0. 0. 10 any20 deny i p host 136. 1. 34. 4 any ( 27 mat ches)30 per mi t i p any any


72/103




4.10 IPS Application Inspection and Control Log any use of the HTTP CONNECT method and FTP DELETE command on the

segment between R1 and R2. Make the inspection as precise as possible and use the most specific engines.

Configuration

Note

HTTP is probably one of the most popular protocols used in modern networks, and thisis why it is such popular target to exploitation. The primary goal of attackers is exploitingHTTP application vulnerabilities or using HTTP to hide malicious activity. FTP is theother popular protocol, which has a long history of security issues. Since version 5.xCisco IPS supports two advanced application inspection and control engines for HTTPand FTP protocols. These engines support deep protocol inspection, allowing for policyenforcement at Level 7 of the OSI model, using the properties and commandsassociated with FTP and HTTP protocols. Specifically, here is the list of the featuressupported with HTTP AIC:

1) Detection of non-HTTP traffic tunneling through port 802) Ensuring RFC compliance of HTTP methods3) Filtering traffic based on MIME types4) Control of permitted traffic via user-defined policies, .e.g. based on regularexpression.

Using a destination port of 80 for traffic that is not related to HTTP is known as tunnelingtraffic through port 80. You may see some instant messengers using this technique orsome proxy programs. The IPS may check the HTTP requests and compare theirformat with the standard requirements. This also allows for detecting of protocol abusesor malformed messages. Filtering on MIME types allows you blocking certain types oftraffic, such as video or audio or gzip-compressed content, which might be used to hidea virus. You can regulate which HTTP methods are allowed based on your securitypolicy. For instance, your security policy may prohibit the use of TRACE or HEADmethods, or the CONNECT method that may be used for tunneling.

As for FTP, the IPS provides a large set of signature to match almost legit FTPcommand, or an unrecognized command. This allows you for enforcing security policybased on the commands allowed for FTP.


73/103




If you want to configure an AIC signature, you may find the list by running the IDM andgoing to Configuration > Policy > Signature Definition and searchbased on the Engine AIC HTTP or AIC FTP. Select the signature you need from thelist and enable/tune it if needed. Notice that by default the signatures are configured toproduce an alert and deny connection inline, so you may want to change this behavior.The HTTP signatures are grouped as follows HTTP Request Method signatures,HTTP Content-Type Signature (based on the MIME types used in HTTP response)and HTTP Transfer Encoding Signatures. As for FTP, there are signatures for FTPcommands.

Prior to tuning any of the above mentioned signatures, you may want to go toConfiguration > Policies > Signature Definition select the propersignature set and click the Miscellaneous tab. Under this tab you should set the

Application Policy > HTTP Policy > Enable HTTP and ApplicationPolicy > Enable FTP attributes to Yes in order to make the respective engines

active. Under the same tab, you may also edit the AIC Web Ports attribute if you wantto change the ports that the HTTP AIC engine is using. FTP engine always uses port 21for inspection.

Note

Run the IDM and navigate to Configuration > Policy > SignatureDefinition and select the sig0 signature definition set (we should be configuring vs0

sensor which monitors between R1 and R2). Select the signatures matching the engine AIC HTTP and find the one for the CONNECT method. Enable this signature andremove the Deny Connection Inline action.


74/103





75/103




Note

Repeat the same action with the signature corresponding to FTP DELE command. Nowenable the HTTP and FTP AIC engines by going to Configuration > Policies >Signature Definition > sig0 > Miscellaneous .


76/103




Verification

Note

Enable HTTP server in R2 using the command ip http server . After this, simulatean HTTP CONNECT request to R2

Rack1R1# telnet 150.1.2.2 80 Tr yi ng 150. 1. 2. 2, 80 . . . OpenCONNECT 150. 1. 3. 3: 443 HTTP/ 1HTTP/ 1. 1 400 Bad RequestDat e: Thu, 25 J un 2009 13: 14: 03 GMTSer ver : ci sco- I OSAccept - Ranges: none

400 Bad Request

[ Connect i on to 150. 1. 2. 2 cl osed by f or ei gn host ]Rack1R1#


77/103




Note

Now check the IPS event log in the IDM and notice that there is an event triggered bymatching the Define HTTP Request Method CONNECT Signature:


78/103





79/103




4.11 IPS META Engine Configure the IPS to generate an alarm, once the

iewb sc vol i v5ddd.section.4.ips.012

Documents