March 4th, 2010 §
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.
August 8th, 2009 §
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.
May 6th, 2009 §
#!/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
February 11th, 2009 §
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.
February 9th, 2009 §
TCP has lots of features, like error recovery and acknowledgment which UDP doesn’t support. Both use “ports” and both have error detection. So why use UDP?
I’ve linked to a flickr scan of TCP header. As you can see a TCP header is 20 Bytes long, without it’s payload, where as if you look at a UDP header it’s only 8 Bits long. UDP already has the advantage of being smaller in size, but what really makes UDP useful is it’s lack of error recovery.
In services like VoIP , Video Conferencing and Gaming, by the time TCP has detected an error, sent a request for the missing packet, and continued on it’s way it has interrupted the call, making TCP a bad choice. Since UDP doesn’t have error handling, it doesn’t matter if a packet was lost or damaged, because UDP won’t request (or check) for the missing packet and continue on it’s merry way. Thus keeping the call at low latency.
Ps. Now that I have gotten half way through the first Cisco CCNA book I might share a few other network tips, tricks or info.