Michael Wheeler

Two features of modern switches and routes is auto negotiation and auto mdix.

Auto Negotiation provides an easy way for network engineers to configure ports, allow automatic detection of speed and duplex settings. In an ideal world auto negotiation would be used on both ports, but in some cases (eg, when a network engineer only has access to one of the devices), a network engineer cannot tell if the port is statically set, or set to auto negotiation.

If a port is set statically on one device, and not the other, the auto negotiation process will detect the speed, but no the duplex. By the IEEE standard, if duplex can’t be detected for 10M or 100M then the duplex by default is set to half. Starting at 1G the duplex is set to full.

So what ends up happening is one port set to half duplex, and the other set to full. This causes a duplex mismatch, resulting in a slow link with packet loss. This leaves two simple solutions, set both to a static setting or set both to auto.

This is all well and good, and you end up statically setting the speed and duplex. Duplex is set to full, and 100 on both sides, and suddenly the link won’t come back up. Why is this?

Well on newer switches and devices, a feature called auto mdix allows network engineers to be lazy and use straight through cables where crossover cables are needed and vice versa. Some implementations even allow use of other pairs of wire when cables are damaged.

In Cisco devices when speed and duplex are set, auto mdix is disabled. Therefore if a network engineer has statically set the speed and duplex on one side, and has used the wrong cable, the link will fail.

Long story short…

• Use the right cable types when connecting devices
• Set duplex and speed the same on each device
• If you can’t swap the cable, use auto on both sides

SSH is a wonderful protocol / tool which I use every day. It allows a user secure communication between hosts. Amongst it’s many features it allows people to securely to execute commands, copy files and tunnel net traffic. Using SSH rather than telnet to configure and access devices is a great step up, and unlike telnet, passwords and secure information is encrypted.

But just because you’ve enabled SSH on all your devices doesn’t mean your network is any more secure. SSH is only one in many changes that need to be changed in order to have a secure network.

Network Management, most network management software still access your devices using insecure techniques (some of which are listed below). What’s the use of using SSH, when you network management polls it every 5 minutes insecurely

Keys
A simple think overlooked in most SSH setups, is that keys are never logged / saved, nor are private/public key authentication. So when you have 500 network devices, when you connect to one, people start getting into the habit of just accepting ssh keys without looking at them. A simple ARP man in the middle attack could allow a user to grab your password without any work.

File Transfer
So you need to upload a config file. Simple I’ll just TFTP or FTP it. Maybe you might even HTTP it across. Well there you go, all the work of installing SSH on all your devices has been wasted. This can easily be fixed with either SCP, HTTPS or FTPS.

SNMP
Commonly used SNMPv2 and v1 has no encryption support. It is common that most devices are setup with SNMPv2 and v1 rather than the SNMPv3 which support encryption. SNMP can be used to monitor, and set configuration options on most devices.

Vulnerabilities in software
Sounds pretty stupid, but why would an attacker bother with SSH when they can just exploit a page. It’s annoying, but IOS and other software need to stay updated.

Routing Protocols
Routing protocols really need to stay on routed links. Having OSPF running on general access VLANs is not a good idea. Very easy to make a man in the middle attack.

Spanning Tree
Spanning Tree can easily be disturbed, and be used for malicious activities. BPDU GUARD really needs to be enabled on access ports, otherwise you’ll be in trouble.

Theses simple fixes will in fact make your network more secure than SSH would.

melissa_sucks – Cisco IP Phone ft. HELLO KITTY

Cisco make some damn nice products, but they also make some products that make my life hell. Here is my list.

Things Cisco does right:

Cisco Switches, Routers, and Access Points

Cisco switches, rouners and access points are amazing pieces of equipment. They have lots of features, fast, secure and easy to configure. All are simple to configure using IOS and most devices can be configured to do many tasks.

Cisco VoIP Devices

Cisco phones are easy to use, customizable, and support various backends. The range includes phone that can be configured for any task.

IOS

IOS has to be the best / most usable operating system for switches that I’ve seen. It has a small foot print allowing for low lag, yet is still feature packed. It’s a shame that there are still devices floating around not running IOS (eg voice gateways and old aironet devices).

Standards

If there is a need for a protocol or standard Cisco will make one to suit the need, which gets the market moving.

Things that Cisco should be banned from developing:

Client Software

Cisco makes the crappiest client software round at times. Why does their software phone have to act / feel like a real phone. Their software is typically hard to install, hard to use, and breaks easily.

Server Software

Just like the client software, Cisco server software is hard to install, hard to maintain and hard to use. The software usually installs several services, most without descriptions, contains lots of memory leaks, bugs and security flaws and breaks with OS updates.

Web Sites

Most of Cisco software and devices contain built in web servers for easy management. The menus are hard to use, and are designed purely for IE 6 running on Windows, and break if you use another browser. Cisco websites usually contain numerous exploits.

Even worse than their devices and software, Cisco’s own website struggles. While the look actually seems appealing, their site is impossible to navigate (thank the lord for Google). A simple task of finding a firmware is impossible without reading the “Navigating Cisco Website for Dummies” book. Old content has disappeared, pages full of broken links and missing files, and new content disappearing. Finding what devices / firmware support what SFPs is impossible.

Java

Any Cisco product that requires Java requires a specific version. I am required to be running 4 different versions of Java because of this. Java software is slow to use, and usually leaves me with no memory for other programs.

Drivers

If you have used an Aironet card, you’ll understand why. The GUI is hard to use and the software can get fairly confusing.

Standards

While Cisco will make a standard to fill a gap, it usually won’t disclose the standard to any other companies without large sums of money. This forces companies to make their own, creating compatibility issues between devices.

Brian’s Eye – Cisco’s One Millionth Catalyst 3750 Switch

Below is a simple bash script which uses snmpwalk to find out which ports on a Cisco switch (It should work on other as well) aren’t being used, over a period of time. It works by checking if the port is up or down, if it’s up it’ll remove it from the list of ports. For best results, set the script up for a crontab of about 5 to 15 minutes, and then come back in a few weeks to see which ports are inactive.

#!/bin/bash
date
WORKDIR=/root/
IPs=( 10.0.0.1 10.0.0.2 ) #IP addresses seperated by spaces
# Start making indexes if file doesn't exist
for IP in ${IPs[@]} #Loop through list of IPs
do
        if [ ! -f $WORKDIR$IP.index ] #If the ip.index file doesn't exist then create it.
        then
                snmpwalk -v1 -c snmpass $IP  1.3.6.1.2.1.2.2.1.2 > $WORKDIR$IP.index
# We walk this snmp value to get the names of the interface so we can find them on the switch easier
        fi
        INTERFACES=`cat $WORKDIR$IP.index | sed 's/IF-MIB::ifDescr.//' | sed 's/ = STRING.*//'`

 #Get a list of interface IDs
        for INTERFACE in $INTERFACES
#Loop though each interface ID
        do
                if [ `snmpwalk -v1 -c snmpass $IP 1.3.6.1.2.1.2.2.1.8.$INTERFACE | \
sed 's/IF-MIB::ifOperStatus\.[0-9]* = INTEGER: //' | sed 's/([0-9])//'` == "up" ]
#We then sed the snmp results to get up or down state
                then
                        echo Success $IP / $INTERFACE is UP - Removing from list
#We echo if an interface is up
                        mv $IP.index $WORKDIR$IP.index.tmp
#We need a temp file since we can't read and write at the same time in a pipe
                        cat $WORKDIR$IP.index.tmp | \
sed "s/IF-MIB::ifDescr.$INTERFACE.*//" > $WORKDIR$IP.index
#remove the interface that is up and pipe it to the index file
                        rm $WORKDIR$IP.index.tmp #remove the temp index file
                fi
        done
done

rm $WORKDIR*.index.tmp >/dev/null 2>&1
#Do a quick clean up incase we left some files behind. This should always return an error

Cisco – queued

Cisco messages can be annoying when you are working a switch that logs ACL rules on a Cisco switch, so something that I’ve found quite useful is editing the line configuration to make the command you are typing in on a Cisco switch be re-printed below the log message.

It’s pretty simple to use, and all you need to do is this, in “configure terminal”.


line con 0
logging synchronous
line vty 0 4
logging synchronous
line vty 5 15
logging synchronous


Another handy tip is enabling SSH. SSH is secure unlike telnet, meaning passwords or important information can’t be seen if an attacker was able to log packets.

SSH is fairly easy to enable, first off make sure you have a username configured or radius, enable the ssh transport under the lines, set a domain-name and then generate some keys.


line vty 0 15
login local
transport input telnet ssh
!
username admin password god
ip domain-name internaluse.net
! out of config mode run
crypto key generate rsa


Make sure you put down 1024 for the RSA keys, other most SSH clients will turn you down.