Security

Jan 10 2009

ISIS Security part 2 – Video

A while ago I wrote a post on ISIS security. Here is a video to accompany the post.

Consider the topology below.

isis-security

There are five ways to configure ISIS authentication.  The methods differ in which packets they authenticate.  Some authentication methods will tear down ISIS adjacencies if there is an authentication mismatch, others will remove any ISIS routes.

In summary we said the following 5 authentication configuration options were available in IOS.

1-area-password command

2-domain-password command

3-isis authentication key command

4-authentication key command

5-isis password command.

We can group the 5 methods into 2 categories, those which authenticate ISIS hello packets and those which authenticate ISIS LSP, CSNP and PSNP packets.

The isis-authentication key and isis password commands are used to authenticate ISIS hello packets.

The area-password, domain-password and authentication key commands are used to authenticate ISIS LSP, CSNP and PSNP packets.

The video below shows how to configure the above options.  Click here to download and watch the video on your iPod.

The Flash plugin is required to view this object.

By Zarar • CCIE SP, iPod, IS-IS, Security • 0 • Tags: , ,

Dec 30 2008

Prefix Lists

IP Prefix lists can be used with BGP to permit or deny specific prefixes from being advertised or learnt to or from a neighbor.

Consider the topology below.

prefix-lists

We will carry out three exercises.

  1. configure a prefix list to match 192.168.1.0/24
  2. configure a prefix list to match 192.168.1.0/24, 192.168.1.0/25, 192.168.1.0/26.
  3. configure a prefix list to match 192.168.1.0/25 and 192.168.1.0/26

Exercise 1

We configure the following prefix list and attach it to the bgp neighbor 10.0.0.2 using the commands below.

ip prefix-list slash-24-only seq 5 permit 192.168.1.0/24

router bgp 1
!
neighbor 10.0.0.2 prefix-list slash-24-only in

Exercise 2

We configure the following prefix list and attach it to the bgp neighbor 10.0.0.2 using the commands below.

ip prefix-list UP-TO-SLASH-26 seq 5 permit 192.168.1.0/24 le 26

router bgp 1
!
neighbor 10.0.0.2 prefix-list UP-TO-SLASH-26 in

Exercise 3

We configure the following prefix list and attach it to the bgp neighbor 10.0.0.2 using the commands below.

ip prefix-list GE-LE seq 5 permit 192.168.1.0/24 ge 25 le 26

router bgp 1
!
neighbor 10.0.0.2 prefix-list GE-LE in

Now let me try and explain what these 3 prefix lists are actually doing.

Prefix list 1 – slash-24-only

ip prefix-list slash-24-only seq 5 permit 192.168.1.0/24

This is pretty straight forward.  This prefix list will match on the exact prefix as configured in the prefix list ie 192.168.1.0/24.

Prefix list 2 – UP-TO-SLASH-26

ip prefix-list UP-TO-SLASH-26 seq 5 permit 192.168.1.0/24 le 26

For a prefix to be permitted by this prefix-list the first 24 bits must match the first 24 bits of 192.168.1.0.

The le 26 then adds a subnet clause which states that the subnet mask being advertised must be less than or equal to 26 bits in length.

Lets consider a bunch of prefixes and see if they would be permited by the above prefix list.

  1. 192.168.1.0/24
  2. 192.168.1.4/30
  3. 192.168.1.128/25
  4. 192.168.1.0/23
  5. 192.168.1.0/27

Prefix 1 matches both criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list and the subnet mask is less than 26 bits.

Prefix 2 matches the first criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list, however the subnet mask is greater than 26 bits.

Prefix 3 also matches both criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list and the subnet mask is less than 26 bits.

Prefix 4 is an invalid prefix, I’ll let you work out why.

Prefix 5 matches the first criteria but fails on the subnet mask length criteria and as such the prefix is denied.

Prefix list 3 – GE-Le

ip prefix-list GE-LE seq 5 permit 192.168.1.0/24 ge 25 le 26

Now this is an interesting beast.  This prefix-list had 2 match clauses.

  1. The prefix must match the first 24 bits on the prefix in the prefix list
  2. The subnet mask must be between 25 and 26 bits in length

Lets consider a bunch of prefixes and see if they would be permited by the above prefix list.

  1. 192.168.1.0/24
  2. 192.168.1.4/30
  3. 192.168.1.128/25

Prefix 1 matches the first criteria ie the first 24 bits match, however the subnet mask is the wrong length.

Prefix 2 matches the first criteria ie the first 24 bits match, however the subnet mask is the wrong length.

Prefix 3 matches both criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list and the subnet mask is greather than 25 bits buts still less than 26 bits.

I hope that makes sense.  Anyhow, here is a video showing how to put it all together or alternativley click here to download and watch it on your iPod.

The Flash plugin is required to view this object.

By zismail • BGP, CCIE, CCIE SP, CCIP, CCNP, iPod, Security • 0 • Tags: , ,

Dec 25 2008

Source Based RTBH

Consider the topology below.

rtbh-src

PC1 sends a syn flood attack using source IP 192.168.1.1 to PC2 destination address 172.16.1.1.

The network engineer at ZeeNet spots the attack and quickly logs onto the trigger router.  He adds a static route to the trigger router which states that the next hop for 192.168.1.1/32 is Null0.  This static route is then redistributed into BGP and advertised using iBGP to R1.  When the static route is redistributed into iBGP, the route-map attached to the redist static command changes the next hop to 192.0.2.1.

R1 has a static route which states to get to 192.0.2.1 go via the null0 interface.

R1 has Unicast Reverse Path Forwarding (URPF) configured on fa1/1.  URPF is a cool technology.  When a packet enter fa1/1 URPF checks the source address of the packet to see whether it has an entry in the local routing table.  If there is no entry in the local routing table or the entry points to a different interface or if the entry points to null0 then the packet is dropped.

In our case, there is an entry in the local routing table for 192.168.1.1/32 which points to null0.  Therefore URPF will drop the packet.

Once again, you have to understand the implications of using this approach, if for example an attacker is sending a syn flood attack to PC2 and he is spoofing address 10.10.10.1/32 for example and you black hole 10.10.10.1/32 using source based RTBH, then the actual user 10.10.10.1/32 will be black holed.

Now lets look at how to configure Source based RTBH below, or alternatively click here to download it and watch it on your iPod.

The Flash plugin is required to view this object.

The commands used to configure Source based RTBH are as follows.

R1

! To configure URPF on interface facing attacker.

interface FastEthernet1/1
ip verify unicast reverse-path

! Black hole static route.

ip route 192.0.2.1 255.255.255.255 Null0

Trigger router

! route-map which matches tagged static routes and sets the ip next hop as well as add a no-export community.

route-map BLACK-HOLE permit 10
match tag 100
set ip next-hop 192.0.2.1
set community no-export

! Attach the route map to redist static command under BGP.

router bgp 1
redistribute static route-map BLACK-HOLE

! Also you add a static route which you would like to black hole.

ip route 192.168.1.1 255.255.255.255 Null0 tag 100

! Black hole static route.

ip route 192.0.2.1 255.255.255.255 Null0

By zismail • CCIE SP, iPod, Security • 0 • Tags: ,

Dec 24 2008

Destination Based RTBH

Chirag, this ones for you dude.

Consider the topology below.

rtbh-dest1

PC1 sends a syn flood attack using source IP 192.168.1.1 to PC2 destination address 172.16.1.1.

The network engineer at ZeeNet spots the attack and quickly logs onto the trigger router.  He adds a static route to the trigger router which states that the next hop for 172.16.1.1/32 is Null0.  This static route is then redistributed into BGP and advertised using iBGP to R1.  When the static route is redistributed into iBGP, the route-map attached to the redist static command changes the next hop to 192.0.2.1.

R1 has a static route which states to get to 192.0.2.1 go via the null0 interface.

All traffic destined to 172.16.1.1 is then black holed.  You might be thinking, Whats the point of that ie ZeeNet has actually black holed the end user.  This is true, but at the same time we have removed a lot of unwanted traffic from the ZeeNet network.

The above is a simple example, imagine a scenario where an attacker uses thousands of machines to generate an attack.  This could amount to gigabits worth of attack traffic.  ZeeNet need to protect their own infrastructure otherwise a lot more of their users will feel the attack.

Now lets look at how to configure destination based RTBH

The Flash plugin is required to view this object.

By zismail • CCIE SP, Security • 0 • Tags: ,

Dec 24 2008

Remotely Triggered Black Hole (RTBH) destination and source based introduction

RTBH is a method of creating black holes in your network, preferably at your network edge to drop any unwanted incoming traffic usually some kind of attack traffic.

There are two types of black holes you can configure in RTBH, one is source based and the other is destination based.

The black holes are created by simply forwarding the unwanted traffic towards a null0 interface.  Null0 is a pseudo interface i.e. a logical interface that is always up and can never forward or receive traffic.

RTBH itself is not a feature in IOS which you turn off|on, rather it is a security model which is configured through the use of the other IOS features such as iBGP, uRPF etc.

RTBH can prevent the following types of attacks:-

  • DOS and DDOS attacks
  • Blacklist filtering

Destination based RTBH allows you to filter traffic based on the destination.  This methods does not prevent a DOS or DDOS on an end user, but it can remove a lot of unwanted traffic from your network by dropping it at the network edge.

Source based RTBH allows you to filter traffic based on the source.  This method can prevent a DOS attack on a particular end user by black holing the source of the attack.  This methods works well but if a DOS attack is coming from a user who is changing the source addresses of the attack randomly then black holing many sources NOT only doesn’t scale well but may actually black hole the real owners of that address space.

Both methods of RTBH have their merits and can most definitely add value to your network.  But like most things you just need to understand where to position it and the associated Do’s and Dont’s.

By zismail • CCIE SP, Security • 1 • Tags: ,