Hiding (filtering) a specific user from reporting in Cisco ISE

I ran into an interesting problem preparing for an 802.1x deployment – the authentications report in Cisco ISE was full of all the network devices checking to make sure ISE was still available (health checks). As seen below the load balancer’s keep alive fill the logs pretty much on their own, imagine trying to troubleshoot a login issue!1 YUCK!

Something else I found interesting that my Google Foo (or knowledge of ACS and how to filter out a certain user) was no match for trying to find a solution for my issue. Because of this, I decided a quick how-to on this would be helpful (I can’t be the only person who will want to filter out such an annoying problem).

First Navigate to Administration > System > Logging:2

Once in the System Settings for Logging, navigate to “Collection Filters”:3

At this point, the rest is pretty straight forward. But for completeness I am going to finish the whole process, so click “Add”:4

After that just fill in the type of attribute you want to filter (Username, Policy Set Name, NAS IP Address, Device IP Address, or MAC Address), the Value for the selected attribute, and the Filter Type (Filter All, Filter Passed, FIlter Failed, or Bypass Suppression [with time limit]). Finally, click “Submit”!


For me, it made the most sense to filter the username used for the monitors, and to only filter on passes for that username. This allows me to use the least amount of filters, and if a health monitor fails for any reason will show up in the reporting still.

Final result (don’t mind the old logs, I was too impatient to wait for them to clear):


Happy troubleshooting!


Attacking HSRP and how to protect it

I covered HSRP (Hot Standby Router Protocol) in a previous post that went into great detail on how HSRP functioned and a few enhancements to it. This time around I figured it would be fun to see what we could do to a typical HSRP deployment, and then research ways to further protect it.

For this scenario the following topology will be used:


. The topology includes a basic HSRP configuration between two routers (R01 and R02), a basic layer 2 switch (sw1) and a webserver sitting on the “Internet”. For verification purposes, the active HSRP router is checked:  12

With the verification completed its now time to start the reconnaissance. For this Kali Linux was used along with a hand full of tools running on it. This post is not intended to explain how to use the tools and will not go over them, a simple Google search will give you all the information you need for that…

A quick wireshark trace shows there is in fact HSRP traffic flowing on the subnet:Screenshot from 2015-07-19 09_37_13

The attack is launched and a new HSRP takes over as active:

Screenshot from 2015-07-19 09_41_253

Executing the attack alone is enough to cause a DDoS event for that subnet. All traffic is routed to the rouge Active HSRP “router” and if it is not setup properly will cause all traffic destined for an outside subnet to be dropped:4

For some a DDoS is the end goal of the attack, but that’s not as fun as being able to be in the middle of the traffic without users even knowing. For the MITM to be successful a few things needed to be configured on the kali Linux device in order to get traffic flowing properly. Once setup traffic was able to leave the subnet:


Now that the attacker is in the middle of all traffic leaving the subnet, it is possible to sniff any traffic going through with wireshark. If anything is sent in clear text (unencrypted) the attacker is able to see it in wireshark including login information:Screenshot from 2015-07-19 10_05_10

The easiest way to add a layer of protection onto HSRP is to utilize MD5 authentication. This can be accomplished through key chains, key strings, or a mixture of the two. The configuration to use a key string is very straight forward. On all routers participating in HSRP for that group add the single command line: standby [HSRP group #] authentication text  [Authentication String]. Once configured, all devices will use the string to hash message data. If a router attempts to join the HSRP group with a incorrect key the following warning is seen:


SNMP traps can be setup so that an alert is sent immediately if the bad authentication is seen allowing for network staff to investigate the issue.

Lets just go ahead and use DTP & VLAN 1… Part 1: Attacking DTP – getting those server files

In my previous post, I discussed the vulnerabilities introduced from using the defaults of DTP and VLAN1 along with ways to mitigate the vulnerabilities. In this post a basic example of attacking DTP will be reviewed.

To make things easier to follow the following diagram will be used throughout the series:VH

Before the attack, for demonstration purposes, we verify that the attacker’s switchport (fa 0/14) is not a trunk:


We will also verify the inability of the attacker to access the target server (due to the router’s ACL):a1

Now that we have verified the inability for the attacker to gain access to the server we can begin the attack.

The first phase of the attack will be to trick the switch into thinking its connected to another switch and negotiate a trunk link. This will be completed through spoofing DTP packets, which can be seen below:at1

We can see the switch port flap as it resets, and then its verified that the attacker’s port is now a trunk:Untitled3

Now that the switch believes its connected to another switch via a trunk connection its now possible to create virtual interfaces for any VLAN allowed across the trunk (all by default):at2

As can be imagined, with the attacker able to successfully trick the connected switch into thinking s/he is also a switch almost anything is possible. For today, we will simply pull a file off of the server which is supposed to be protected by an ACL on the router:


With DTP enabled on a port it takes a matter of seconds to trick a switch into thinking its connected to another switch, this is why its very important to configure any port that is not a trunk port in use as an access port with other appropriate security configurations.

Lets just go ahead and use DTP & VLAN 1… Part 0: What using DTP & VLAN 1 means

By default, DTP auto negation is enabled on Cisco switches on all layer 2 ports and they are placed in VLAN 1. These two defaults allow for an easy way to just deploy a switch, or attach another switch to gain more port density, without needing any configuration knowledge. While this is very helpful, the use of VLAN 1 and leaving DTP auto negation on has been widely accepted as standard use for data ports and in turn has left the ability for someone with physical access to gain access to other VLANs and the devices in them.

In part 0 of this series we are going to go over the theory of why the use of DTP and VLAN 1 could be used to allow for an attacker to execute a VLAN hopping attack.


Dynamic Trunking Protocol (DTP) is a Cisco proprietary protocol used to allow for trunks to automatically form between switches without requiring any configuration knowledge when they are plugged into each other. DTP sends updates every 60 seconds over links with DTP enabled and includes the switch’s DTP type, interface status, and VTP domain.

Attacking DTP:

While there really isn’t much to say about DTP (even at a technical level) having DTP on allows for a security hole that can easily be exploited to allow full access to any VLANs the switch has access to. There are two different ways to take advantage of DTP both of which are pretty straight forward.

The first method involves simply plugging in another Cisco switch, that the attacker has control over, with DTP enabled. Once the two switches form a trunk, the attacker can then configure the switch they control and put a device in any VLAN that’s allowed across the trunk (which is all by default). SS

Figure 1 – Adding a third switch

The second method involves forging DTP frames to trick the victim switch into forming a trunk with the attackers computer. Once the trunk is formed, the attacker can forge other frames and packets that will allow them deeper access into the network similar to having their own switch but without the hassle of having a switch on-site for the attack. ST

Figure 2 – Switch Spoofing

Mitigating DTP attacks:

Just as DTP and the attacks associated with the protocol are simple, so are the steps for mitigating the attacks.

1. Set any port not used as a trunk explicitly as an access port
SW-1 (config)# interface fa 1/0/1
SW-1 (config-if)# description Access Port
SW-1 (config-if)# switchport mode access

2. On ports that are trunks, disable DTP negotiation
SW-1 (config)# interface gig 1/0/1
SW-1 (config-if)# description Trunk to SW-2
SW-1 (config-if)# switchport trunk encapsulation dot1q
SW-1 (config-if)# switchport mode trunk
SW-1 (config-if)# switchport nonegotiate

SW-2 (config)# interface gig 1/0/1
SW-2 (config-if)# description Trunk to SW-1
SW-2 (config-if)# switchport trunk encapsulation dot1q
SW-2 (config-if)# switchport mode trunk
SW-2 (config-if)# switchport nonegotiate

Unlike Cisco proprietary ISL, standards based 802.1Q does not encapsulate the original frame. Instead it adds a 32-bit field between the source MAC address and the EtherType/length fields. Another difference between ISL and 802.1Q is the concept of a native VLAN. While ISL doesn’t have a native VLAN in 802.1Q a native VLAN will not be tagged when frames for that VLAN are flowing over a trunk link by default.

Attacking the native VLAN:

The use of the native (untagged) VLAN allows for an attack called VLAN hopping. This attack allows for an attacker to craft frames that are “double tagged” which have two 802.1Q tags in the frame. The attack itself would be performed in the following manner:


Figure 3 – Double Tagging

1. The attacker crafts a frame with two 802.1Q tags, the first tag will be for the native VLAN 1 (in this case the default VLAN 1) and the second tag will be for the target VLAN (in this case VLAN 10).

2. SW-1 receives the frame on a port set as the native VLAN and strips the first 802.1Q header. Next, it will forward the frame out any trunk links it has that are set for native VLAN 1. In this case the frame will be forwarded to SW-2 over its trunk link.

3. SW-2 receives the frame on its trunk and see that it is destined for a device in VLAN 20. Assuming the target’s MAC address is already in the MAC table, the frame has its second 802.1Q header removed (because its going to be forwarded over an access port which doesn’t allow 802.1Q headers) and forwarded to the target.

As can be seen above, the attack does require two switches to be trunked together in order to allow for it to be successful.

Protecting the native VLAN:

There are three easy ways to protect against VLAN hopping attacks, only one is required but the use of all three is highly recommended.

1. Do not use the native VLAN on any access port
SW-1 (config)# interface fa 1/0/1
SW-1 (config-if)# description Access Port
SW-1 (config-if)# switchport access vlan 20

2. Set the native VLAN to an unused VLAN (must be configured on both switches of a trunk)
SW-1 (config)# interface gig 1/0/1
SW-1 (config-if)# description Trunk to SW-2
SW-1 (config-if)# switchport trunk native vlan 999

SW-2 (config)# interface gig 1/0/1
SW-2 (config-if)# description Trunk to SW-1
SW-2 (config-if)# switchport trunk native vlan 999

3. Tag native VLAN traffic (must be configured on both switches of a trunk)
SW-1 (config)# interface gig 1/0/1
SW-1 (config-if)# description Trunk to SW-2
SW-1 (config-if)# switchport trunk native vlan tag

SW-2 (config)# interface gig 1/0/1
SW-2 (config-if)# description Trunk to SW-1
SW-2 (config-if)# switchport trunk native vlan tag


While defaults are wonderful to have and make certain tasks easier, it must be taken into consideration what those defaults actually enable what type of holes could be opened in a security plan when used. My next post will go into greater detail of using these vulnerabilities as a jumping off point on gaining access to other systems on a network.