Protect your network against HSRP attacks!

As in my earlier post, I’m writing a series of postings to help protect your network against attacks. A good hacker will always find a way to hurt your network. But with the recommendations described in this series of postings it will be more difficult for the hacker to find a way in.

In this post I will describe the hacking of HSRP operations and off course I will describe a solution to this problem.

As always I use GNS3. Below the topology and the configuration of multilayer switch R2.
topology

R2
!
interface FastEthernet0/0
switchport mode trunk
!
interface FastEthernet0/5
switchport access vlan 13
no cdp enable
!
interface Vlan10
ip address 10.0.0.253 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.253 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.253 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.253 255.255.255.0
standby 13 ip 192.168.80.254
!

HSRP
The cisco.com website explains HSRP as follows:

“HSRP is Cisco’s standard method of providing high network availability by providing first-hop redundancy for IP hosts on an IEEE 802 LAN configured with a default gateway IP address. HSRP routes IP traffic without relying on the availability of any single router. It enables a set of router interfaces to work together to present the appearance of a single virtual router or default gateway to the hosts on a LAN. When HSRP is configured on a network or segment, it provides a virtual Media Access Control (MAC) address and an IP address that is shared among a group of configured routers. HSRP allows two or more HSRP-configured routers to use the MAC address and IP network address of a virtual router. The virtual router does not exist; it represents the common target for routers that are configured to provide backup to each other. One of the routers is selected to be the active router and another to be the standby router, which assumes control of the group MAC address and IP address should the designated active router fail.”

So in short, HSRP provides a virtual default gateway. And that’s the problem, when someone or something finds a way to hack into the HSRP operations it is possible to change the default gateway and reroute networktraffic or blackhole the networktraffic. This turns out to be very simple with Kali. Below a simple explanation how to change the behaviour of HSRP operations.

Start Kali, start yersinia, click the HSRP tab, choose to become active router, give in an ip address and that’s al there is:
hsrp_att

hsrp ip

 

When you have enable terminal monitor on your switch, you’ll see a state change
state change
Now check the HSRP settings with “show standby vlan 13” and you’ll see that the gateway has changed to 10.10.10.10
sh stand vlan 13

When you look closer to the config you’ll notice something else:
config change
For Yersinia to be able to take over the HSRP operations, it alters the config by entering a static entry to the mac address table!

Again this al there is to! To prevent this, make sure u use authetication on your HSRP interfaces as described in the following example:

First create a key-chain
key chain

 

Then configure the authentication on the vlan interface. If your are in a production network. First configure the standby unit, then the active unit. Otherwise the actions are disruptive!

 

stand auth

Now try the HSRP attack again and you’ll see it will not work this time!
stand vlan 13 auth

 

And to make it even more clear, when terminal monitor is enabled you’ll get the message depicted in the picture below
bad auth

 

 

 

Advertisements

Protect your network against CDP attacks!

As a network consultant/engineer you should be aware of network security risks. Today it is fairly simple to take down a network with the use of Kali Linux. There, it has been said: Kali Linux. This Linux distro is a hackers dream. It has all the necessary tools on board to damage a network very very hard! A hacker only needs a free outlet that is patched to a switch. Within minutes a company can be down on it’s knees!

First of all I’m writing this series of postings to point out the need for security on the network layer, not to make a hackers life easy! In this post I will describe how to use Kali Linux, but more important are the security solutions I give to prevent attacks on your network. This post will be about protecting your network against CDP attacks.

How do I test Kali, you probably guest it already when you read my earlier posts, I use GNS3 for it. Below the topology I use for testing.
topology

R1 and R2 are configured as two multilayer switches, with several (routed) vlan’s. For reference below the config of R1.

R1
!
interface FastEthernet0/0
description Trunk to R2
switchport mode trunk
!
!
interface FastEthernet0/4
switchport access vlan 11

!
!
interface Vlan10
ip address 10.0.0.252 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.252 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.252 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.252 255.255.255.0
standby 13 ip 192.168.80.254
!

CDP Flooding
CDP (Cisco Discovery Protocol) is a great tool when you have to make documentation of a network and most cases CDP is globally enabled on every switch en every switchport on the network. Great, but then a any given moment you check the cdp status on your switch and see this:

cdp_flood

and this:
proc_cpu

As you can see the cdp table is flooded with bogus entry’s and because of the ongoing stream of bogus cdp packets, the cpu spikes to 100%. It’s just a matter of time before the switch will reboot. Problem is, when the switch is rebooted it will be just the same because the stream of cdp packets just keeps going on.

How is this possible you think, well it’s really easy. Install Kali Linux, start the Yersinia program and click attack. Is it that easy I hear you think? Yes it’s that easy! Check it out:

Start Kali Linux:
kali

Start Yersinia
start yersinia

Click the cdp tab, click Launch Attack, choose “flooding CDP table” and click “OK”.
start attack

 

That’s it, your cdp table will be flood with bogus cdp packets. Now check your switch with the “show cdp table”, “show cdp traffic” and “show proc cpu sorted” command:
cdp_flood

proc_cpu

cdp traffic

Within two minutes my switch crashed and rebooted, so this is a real threat to the stability of your network.
To prevent this kind of attacks a couple of things can be done:

First of all, place switchports that are not in use in a dummy vlan and give them an admin down
Second, disable cdp on switchports that don’t need it. For example access ports that only contain a computer or a IP phone which don’t need the CDP protocol to function!
Third, ports that can’t be disabled, configure Port Security on them!

 

 

MPLS VPN (Part 1)

A part of my CCIE study is MPLS VPN’s. This week I read some MPLS books, like “MPLS Fundamentals” and “MPLS and VPN Architectures, Volume II”. So to test my knowledge of the subject I found a useful case study online.

In the picture beneath the topolgy is shown:

MPLS VPN

Goal of this case study is to ping from Workstation “PC-COMPA-01” which resides in Company_A-West (as of now “West”) to “PC-COMPA-02” which resides in Company_A-North (as of now “North”).
The Provider core has to be free of BGP and has to be MPLS enabled. The core has to make use of a dynamic routing protocol.

I started with the dynamic routing configuration of the “Provider Core” which exists of the following routers : R1, R3, R2 and R4. Below is the configuration of R1 (R2, R3 and R4 are almost the same):

R1_config

After configuring the other routers, the routing table of R1 looks like the picture beneath:

ip route

The above steps are needed, because on the PE routers (R6 and R9) BGP will be configured. BGP makes use of the core network, so the routing needs to be in order.
Routers R6 and R9 will also make use of the eigrp protocol. So make sure it is possible to ping from R6=6.6.6.6 to R8=8.8.8.8.
In the picture below the configuration of the eigrp configuration of router R6:

Config R6

If this works, the BGP configuration can be made. As we all know BGP makes use of TCP, because of that it is important there is L3 connection from R6 to R8 and everthing in between.
Below the BGP configuration on R6 and R8.

BGP

To confirm that BGP functions as intended, use the “show ip bgp neighbors” command. Below the output of the command on R6.

Sh ip bgp neig

 

Before creating the VRF’s MPLS can be configured. Just give the “mpls ip” (Yes it’s really as simple as that!) command on the interfaces which have to take part in MPLS.
To confirm MPLS is active use the “show mpls forwarding-table” command. Below is the ouput of R1.

sh mpls forwa

Now it’s time to create the VRF’s, VRF stands for “Virtual Routing and Forewarding”. It’s like a virtual routing table which makes it possible to have the same ip subnets on one router. Which, in turn, makes it possible to have different customers with the same ip subnets on one router (or infrastructure for that matter).
To make communication possible between West and North, two VRF’s are created. One on R6 named “Customer_A-West” and one on R8 named “Customer_A-North”. Add the interfaces facing the CE router to the correct VRF.
Below the configuration needed.

VRF

 

Once the VRF’s are created, some changes have to be made on the BGP configuration, to let BGP know there is a VRF. Below the config of R6. The configuration for R8 is the same, only use the R8 ip addresses etc.

bgp vrf

 

As can be seen in the above picture, a static route has to be configured to make communications possible between routers R6 and R9 and also between R8 and R10. This static route will be configured in the VRF routing table, not in the global routing table! To test connectivity use the “ping VRF <vrf name>” command. With this command the ping originates from within the VRF and not from the global routing table!

Once the above configurations are made, R9 and R10 have to be configured. It’s a pretty straightforward configuration. Below the configuration of R9.

R9

Configure the clients with the correct ip addresses and test the connection between the workstations with the ping command:

pingR9-R10 ping R10 - R9

That’s basically all there is to make a MPLS VPN work!

Check for more info about MPLS VPN’s http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/15-mt/mp-l3-vpns-15-mt-book/mp-bgp-mpls-vpn.html

 

Redistribution and Route-Maps (part 2)

In part two of this post I will explain how to make use of route-maps to influence the redistribution process of routing protocols.

First take a look again at the network topology.
Network Layout

As can be seen the redistribution point is between R4 and R5. The actual redistribtion configuration is done on R5.
With the configuration made in part 1 of this post, all routes are known to all routers in the topology. For whatever reason, sometimes you don’t want that all routes are vissible. This is where a route-map comes in handy.
With the use of route-maps I can influence a lot of things, like traffic flow and in this case the redistribution of routes.

Let’s assume the network administrator wants to exclude the ip-address of router R7 (7.7.7.7) from the routing table in the OSPF cloud. To make this happen the next configuration has to be made.

First of all make a standard ACL, in which you permit the 7.7.7.7 traffic
ACL

Then configure the route-map. Give it a name that makes sense to you (document this to make sure future colleagues understand it to!).
route_map

The “deny 10” does what it say’s, deny everything what comes after this line. The “match ip address 1” matches the traffic that hits access-list 1. The “route-map Redis permit 15” is not explicitly necessary, but to make things clear I added it nevertheless.

Now we have to tell the routing protocol to look at the “Redis” route-map. Otherwise the traffic will just flow as before
OSPF_redis
As you can see in the screenshot above, you just make an addition to the redistribution command.

Now take a look at the routing table of let’s say, router R1
Route_table_RM
As you can see there is no entry to the 7.7.7.7 route anymore
To be totally sure, do a ping test to 7.7.7.7
R1_ping_aft_RM

Route maps can be used for a lot of things and influence alsmost everthing. Check the Cisco documentation for more options!

Redistribution and Route-Maps (part 1)

This post will be about redistribution and the use of route-maps to influence the redistribution process.

When companies merge, the network has to merge too. Often the networks don’t use the same routing protocols. Sometimes it’s possible to migrate a netwerk from let’s say OSPF to EIGRP, but when the company’s don’t use Cisco only, it’s is hard to migrate.

To tackle this problem it’s is possible to redistribute the OSPF routes into EIGRP and also the other way around. This means that all the routes from OSPF are known in the EIGRP cloud, and al the EIGRP routes are known in the OSPF cloud. Sometimes it is not necessary for the EIGRP cloud to know al the OSPF routes. That’s when route-maps come in. With a route-map it is possible to make sure certain routes will never get to the routing table.

In the next section a configuration example.

First have a look a the network layout:

Network Layout

Al routers have two intfaces to connect to their neighbours and one loopback interface to identify the router.
Below an example of router R3:

Interfaces R3

After that configure OSPF:

EIGRP_redistribute R3

Make sure you configure these steps on all the OSPF routers.
To make sure the configuration is correct, check if the “show ip ospf neighbours” command shows two neighbours
OSPF_neighbours R3

 

After configuring the correct interfaces, configure EIGRP:

EIGRP R6

The initial configuration is done. Now the redistribution part can be configured. To make redistribution possible there has to be a redistribution point, in other words, there has to be a router which has an interface (or interfaces) in the OSPF aswell as the EIGRP cloud. In this example R5 is the redistribution point.

Below an example of the redistribution between OSPF and EIGRP on R5:

OSPF_redistribute EIGRP_redistribute R3

As shown in the examples the redistribution command has some options. The default values are enough to make the redistribution work.

To make sure the redistribution works, use the command show ip route on for example router R4.

Routes R4 after redistribution

As can be seen in the above example the EIGRP routes are learned as E2 routes. To make sure the connectivity is correct, use the ping command. As can be seen in the next example, the ping command is succesfull from router R1 to router R7.

ping

 

In part 2 I will describe the route-map configuration.

 

 

Cisco stackport admin down

Lately one of our customers Cisco 3750 switch stacks has a syslog entry that states that one of the stackports is administratively down. About 10 seconds later the port comes up again. Because the redundant stackcables, the stack’s functionality is as usual. While troubleshooting it became clear to me it is possible to administratively shutdown a stack port.

I never knew that a stackport could be configured as administrativly down. After some research in the Cisco 3750 config guide I found out it is absolutly possible.
Normally a switchport is brought administratively down in the “interface configuration” mode. A stackport can be brought administratively down in the “privileged EXEC” mode, with the following command:

Switch01# switch <switch number> stack port <stack port number> disable/enable

Be carefull with this command, because if you shut the wrong stack port it’s possible that traffic is disrupted.

 

 

SLB Loadbalancing

Since I’ve started with my CCIE study, I encountered a lot of interesting stuff. So I decided to make a series of blogposts on those interesting things. The first part is about “SLB Loadbalancing”.

A real loadbalancer can do a lot more, but for a small company SLB Loadbalancing is fine solution.

So let´s look at the network diagram:

NAT_SLB Diagram

As shown above server01, server02 and server03 are the real servers which have to be reachable via the virtual IP address.

First take a look at the vlan and interface configuration, this is pretty straightforward:

Vlan Interfaces

Now the interesting part of the configuration. First of all we have to configure a so called serverfarm in which the real IP address of the servers are defined:

SLB Serverfarm

As you can see above, you have to define a name, in this example I called the farm “TELNET”.
The “nat server” command makes sure the servers don´t have to be configured with the virtual IP address. The servers are totally unaware of the loadbalancing mechanism.

Now it’s time to create the virtual part. First of all the virtual address has to be created, including the “service” that has to be reachable. In this example the loadbalanced servers have to be reachable at port tcp 23, or telnet.
vserver
Don’t forget the inservice commando, this tells the router to activate the loadbalancing.

There are a lot of configuration options available, but with the above mentioned configuration the SLB meganism functions.

Telnet

To verify the working of the SLB mechanism the following commands can be used:

SLB confirm