Connecting the world…

WireShark

AOS – WireShark: remote capture

AOS switches have the option to monitor / copy traffic from port A to port B. You also have the option to send the monitor traffic to a remote switch or even to a remote host. When the remote host is running WireShark, the monitored traffic can be analysed on the remote host.

First you need to configure the switch to send a copy of the traffic to a remote host. Use the following commands to create a monitor session to a remote host. In this case the switch is using IP adres 172.18.9.3 with source port UDP/10999 and the remote host has IP adres 172.18.11.233.

ASW-C01# conf t
ASW-C01(config)# monitor 
 mac                   MAC address.
ASW-C01(config)# mirror 
 endpoint              Remote mirroring destination configuration.
 <1-4>                 Mirror destination number.
ASW-C01(config)# mirror 1 
 name                  Mirroring destination name string.
 port                  Mirroring destination monitoring port.
 remote                Remote mirroring destination configuration.
ASW-C01(config)# mirror 1 remote 
 ip                    Remote mirroring destination configuration.
ASW-C01(config)# mirror 1 remote ip 
 IP-ADDR               Enter an IP address.
ASW-C01(config)# mirror 1 remote ip 172.18.9.2 
 <1-65535>             Remote mirroring UDP encapsulation port.
ASW-C01(config)# mirror 1 remote ip 172.18.9.2 10999 
 IP-ADDR               Remote mirroring UDP encapsulation destination ip addr.
ASW-C01(config)# mirror 1 remote ip 172.18.9.2 10999 172.18.11.233 
 truncation            Enable truncation for Remote mirroring.
 <cr>
ASW-C01(config)# mirror 1 remote ip 172.18.9.2 10999 172.18.11.233 
The destination switch must be configured before proceeding.

Has the remote switch been configured (y/n)? y

Next you need to configure the interface for which you would like to analyse the traffic.

ASW-C01(config)# int 4/3
ASW-C01(eth-4/3)# monitor 
 all                   Monitor all traffic.
 <cr>
ASW-C01(eth-4/3)# monitor all both 
 mirror                Mirror destination.
ASW-C01(eth-4/3)# monitor all both mirror 1 
 no-tag-added          Don’t add VLAN tag for this untagged-port
 <1-4>                 Mirror destination number.
 <cr>
ASW-C01(eth-4/3)# monitor all both mirror 1 

Traffic from port 4/3 is now send to the remote host. Now start WireShark on the remote host and create a capture filter to capture only packets for port UDP/10999.

WireShark displays packets like below, which are useless to analyse traffic. The packets are encoded as HP ERM packets.

So the final step is to decode the traffic. Just right click on a packet and choose the option “Decode As…”. You could also choose from the menu Analyze >> Decode As…

Change the column Current from (none) to HP_ERM from the drop down list and choose OK.

HP ERM, Hewlett-Packard Encapsulated Remote Mirror protocol is used by the HPE (Hewlett-Packard Enterprise) switches based on ProVision ASICs formerly of the ProCurve family, now branded under Aruba Networks, a Hewlett Packard Enterprise company. Unlike Cisco RSPAN, HP ERM encapsulates the frames to be mirrored inside UDP datagrams with a proprietary header, allowing it to be transported over any IP network (like Cisco ERSPAN)

Now the packets should be “readable” for traffic analysis.

Cisco ASA: multiple context and capture

Packet captures are very useful for troubleshooting purposes. The Cisco ASA supports packet captures even in multiple context mode. I normally configure packet captures on CLI level. This can be done by configuring an access-list to match the specific traffic you would like to capture. Add the access-list and the specific interface in a capture command. Mostly I download the capture in raw format for further analysis with a tool like WireShark. The capture can be downloaded via TFTP or via a secure connection (HTTPS) to the Cisco ASA firewall.

When running a Cisco ASA in multiple context mode, I always disable the ability to connect directly to a context for management purposes. That way you have to access the admin context for management access, but this also denies the option to download the capture via a secure connection directly from the Cisco ASA traffic context.

The easiest way to download the capture in multiple context mode is via a TFTP transfer from the system context. Check the example command below. The capture is made within the context named contextA and the capture has the name captureA. The following command can be used to download the capture in raw (pcap) format.

copy /pcap capture:contextA/captureA tftp://10.10.10.10/captureA.pcap

You can now analyse the capture with WireShark

Secure HSRP configuration

A friend of mine works for a well known auditing and penetration testing company in the Netherlands. Recently we were talking about how he starts looking for flaws in network infrastructures. My friend told me that the first thing he does is simply starting WireShark and start looking at all the packets he receives.

By default packets like DTP (Dynamic Trunking Protocol), CDP (Cisco Discovery Protocol) and HSRP (Hot Standby Routing Protocol) are broadcasted through all the different edge ports of a switch. Tools like Yersinia can be used by hackers to exploit these packets.

Normally when I configure a switch I always stop the broadcasting of DTP and CDP on normal edge ports, at least if possible. CDP is often used in conjunction with IP phones. I prevent broadcasting DTP and CDP with the following commands:

no cdp enable

switchport nonegotiate

To be honest, I never thought about the broadcasting of HSRP packets. I created a simple test environment with one Cisco Catalyst 3750G switch and configured VLAN 1 with HSRP, like shown below.

interface Vlan1
ip address 10.10.10.2 255.255.255.0
standby 1 ip 10.10.10.1
standby 1 priority 150
standby 1 preempt
end

This is the most default way of configuring HSRP. By using a tool like Yersinia, somebody could take over the role of active HSRP router by spoofing HSRP packets with a higher priority then the current active HSRP router. So I added a simple authentication text string to the configuration with the following command:

standby 1 authentication HSRP@ICT

This is no success, because when I start WireShark the authentication string is sent in clear text. The picture below shows an example:

HSRP-auth-string

In most recent software version you can protect HSRP by using MD5 Authentication. MD5 authentication provides greater security than plain text authentication. This feature allows each HSRP group member to use a secret key to generate a keyed MD5 hash of the packet that is part of the outgoing packet. A keyed hash of an incoming packet is generated and if the generated hash does not match the hash within the incoming packet, the packet is ignored.

To configure MD5 authentication in the previous example, I added the following configuration to interface VLAN 1:

standby 1 authentication md5 key-string hsrp@ictivity=secure,Ihope timeout 60

Now, when looking at the WireShark output, the key-string is composed of a hash and cannot be easily read by an hacker.

HSRP-auth-MD5

The timeout option is important when configuring a new key-string amongst all the members in an HSRP group. The timeout value is the period of time that the old key string will be accepted to allow configuration of all routers in a group with a new key.

So HSRP MD5 Authentication is another way of making our network components and network infrastructure more secure against “evil” attacks and hackers.