| Follow me on:

Secure HSRP configuration

July 25th, 2008 | No Comments

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.

eSafe Configuration Restore

July 25th, 2008 | No Comments

Some of our customers use eSafe as forwarding proxy for SMTP and HTTP scanning. Today I had to restore an eSafe, which is configured in NitroInspection II Router mode. I had created a backup configuration file from the running eSafe server and installed a new eSafe server with the default settings.

After the installation I connected my laptop to the eSafe server and opened the default browser page:

https://<IP Addr>:37233

After logging in with the default username (admin) and password (esafe), I browsed to the backup configuration file and started restoring to this configuration. The eSafe appliance needs to reboot after the restore.

I know noticed that after the initial restore and reboot, the eSafe server lost the IP configuration from both NIC’s in the server. I had to restore the IP settings manually, which can be done by editing the following files:

  1. /etc/sysconfig/network-scripts/ifcfg-eth0
  2. /etc/sysconfig/network-scripts/ifcfg-eth1

I always forget the syntax when editing the networking files, so I had to search the internet for the correct syntax. Below the configuration of eth0.

DEVICE=eth0
IPADDR=192.168.3.2
NETMASK=255.255.255.0
NETWORK=192.168.3.0
BROADCAST=255.255.255.0
GATEWAY=192.168.3.1
ONBOOT=yes

After rebooting the network service (/etc/init.d/network restart) I was able to communicate with the eSafe server and everything looked normal, but it wasn’t. I noticed that the service eSafe wasn’t able to start.

Contacting eSafe resulted in re-installing the eSafe appliance from scratch. Manually configure the correct IP settings through the web interface and only restore the file /opt/eSafe/eSafeCR/esafecfg.ini. Next I rebooted the server and this time the configuration was restored and the service was running.

eSafes technical personnel told me that the problem could arise, when restoring the tar.gz file to different hardware, and that’s exactly what I tried.

Serious DNS Vulnerability

July 24th, 2008 | No Comments

I guess you already read about it, but if not here a short outcome.

Despite Dan Kaminsky’s efforts to keep a lid on the details of the critical DNS vulnerability he found, someone at the security firm Matasano leaked the information on its blog yesterday, then quickly pulled the post down. But not before others had grabbed the information and reposted it elsewhere, leading Kaminsky to post an urgent 0-day message on his blog reading, “Patch. Today. Now. Yes, stay late.”

 

Hackers are furiously working on an exploit to attack the vulnerability. HD Moore, creator of the Metasploit tool, says one should be available by the end of the day [...]

Source

You can read about this vulnerability on many different blogs, so be careful in the next couple of days when accessing websites, which ask to enter personal information.

IBM Blade with Nortel and HP switches

July 23rd, 2008 | No Comments

Today I had to troubleshoot an IBM Blade system. The customer was complaining that all servers, except one, weren’t able to communicate with the rest of the network. The blade system contains two Nortel switches. Each Nortel switch is connected with a 3 Gbps LACP channel to separate HP switches. The HP switches are the core switches of the network and have VRRP configured between them. The servers have two network card, which are configured in an active / standby team configuration.

I started troubleshooting by simply pinging between the different servers in the blade system. The servers were able to ping each other. Next I tried to ping the default gateway. Only the working servers could ping the default gateway, the other servers couldn’t.

Looking at the active / standby team configuration, I noticed that the active NIC communicates with the Nortel switch connected to the VRRP slave switch. So the servers weren’t able to ping the VRRP master switch (default gateway), but they were able to ping the VRRP slave switch, but the VRRP master switch and VRRP slave switch could ping each other.

I look at the VLAN tagging configuration on the Nortel and HP switches, but all the ports had the correct VLAN tagging, so this couldn’t be the problem. I changed the teaming and made the secondary NIC the active one. Now all the servers were able to communicate with the rest of the network. I switched everything back to the previous configuration and the problem returned again.

Looking at these symptoms I could only point out the LACP channel as the cause of all the problems. Maybe something went wrong when establishing the LACP channel. I guess the load balancing algorithm used is MAC based, maybe destination MAC based. So all packets to the default gateway or another VLAN would use the MAC address of the VRRP master switch and these packets would be lost in a UDLD link. So I decided to disable to ports on the HP switch and only leave one port enabled.

After that all the switches could communicate with the rest of the network. I decided to disable that port and enable another single port. The servers were still able to communicate with the rest of the network. I tried using the last port and still everything was working perfectly. I decided to add the other two ports to the LACP channel. This time, by having the 3 Gbps LACP channel active, every was working perfectly.

In my opinion something went wrong during the establishment of the LACP channel. I found it difficult to troubleshoot the environment, because there aren’t a lot of troubleshooting methods for the HP switches and especially for the Nortel blade switches.

Auto Backup Configurations

July 21st, 2008 | No Comments

Till recently I didn’t have a decent way to backup configurations from routers and switches without using some kind of management tool, like Cacti or Nagios. I wanted to automatically backup configurations by only using a TFTP or FTP server on a network.

I started looking and found the solution by using the archive and kron configurations. I decided to look for methods to backup configurations when one of the following occurrences happen:

  1. Somebody enters the save running-config to startup-config command (write memory);
  2. A certain time of day threshold is reached;

The following example configuration shows both occurrences.

archive
path tftp://192.168.1.100/C2960-01/$h
write-memory

!

kron occurrence SCHEDULE-TO-BACKUP-CONFIG at 20:00 recurring
policy-list BACKUP-CONFIG
!
kron policy-list BACKUP-CONFIG
cli write memory

The configuration above copies the configuration to TFTP server 192.168.1.100 at 20:00h every day. The configuration is also copied to the TFTP server after issuing a write memory. The syntax of the file name on the TFTP server is hostname-seq.number (e.q. SWITCH01-1, the following file would be SWITCH01-2).

I used it several times now and it works great. I use Tftpd32 as TFTP server on Windows, because it is freeware and can be configured as service.