Author Profile - Tony Fortunato is a Senior Network Specialist with experience in design, implementation, and troubleshooting of LAN/WAN/Wireless networks, desktops and servers since 1989. His background in financial networks includes design and implementation of trading floor networks. Tony has taught at local high schools, Colleges/Universities, Networld/Interop and many onsite private classroom settings to thousands of analysts. Tony is an authorized and certified Fluke Networks and Wireshark Instructor. His Pine Mountain Group CNA Level I and II certification demonstrates his vendor neutral approach to network design, support and implementations. Tony has architected, installed and supported various types of Residential Wireless High Speed as well as hundreds of WIFI hotspots. Tony uses a variety of technologies from Powerline, Wireless and wired technologies to find the most cost-efficient and reliable solution for his customers. Tony combines custom programs, open source and commercial software to ensure a simple support infrastructure.
All It Takes Is One Loose End
As part of troubleshooting, I always suggest we ‘clean-up’ and refresh or validate the customers documentation. I can’t remember how many times this simple exercise resulted in ‘fixing’ a problem. I love watching the look of confusion in the customer’s face as he mutters, “that’s not supposed to be connected to that”, “this was supposed to be decommissioned a long time ago”, or the ever popular, “who plugged this in?”.
I still remember the computer connected to the corporate DMZ. Nothing malicious, just never removed after a troubleshooting exercise.
Can't believe everything you read
In this case, I noticed some switches did have labels indicating the IP address of the switch. Great, a label, not a common site, and I was impressed. The odd thing about the label was that I noticed it wasn’t within their addressing range. I asked if they had a management VLAN with a different IP addressing scheme, to which the customer replied, “yes”. When I probed a bit deeper and queried if the address on the label was within the Management VLAN addressing, the answer was, No.” Of course the IP address on the label was not reachable, nor within the customer’s addressing ranges.
One of the technicians recognized the ip address as the the LAB. The LAB techs labelled everything when they were testing and configuring the switches, but the labels were never removed when the equipment was deployed to the production environment. Very simple explanation.
Leaving the key under the doormat
This one is becoming my favourite; As I worked towards
cleaning up a computer room, I noticed this curled up label on the core switch
and similar labels on other equipment.
Can you guess what the labels were?
Hold on to your socks, it was the telnet/enable passwords of the
equipment. AND THEY WORKED!!!!
When I asked the customer why they thought this was a good practice, they said this was done because the analysts kept forgetting the passwords, so it was easier to put them on a label. He added that since the computer room has restricted access, having the passwords written on the labels posed no security risk. I'm a bit more paranoid than that. After looking around the room, I noticed the servers are in there as well as some new desktops and laptops. That tells me that the server staff and PC techs have access and can easily get access to the network equipment.
This next part is so crazy, its believable. I telnetted into the switch and this was the default login prompt;
The telnet and enable password was part of the banner configuration. Hmmmmmmmmmmmmm…. No comment.
Checklist
I put this checklist together for a customer when they asked for a basic framework or checklist of things they should configure within their network equipment regardless of vendor.
I thought that this was a great idea and came up with this;
· Standard host name for this device
· IP information; address, mask and gateway
· Current software version
· Dhcp relay, dhcp helper or port forward addresses/ports
· SNMP version READ and WRITE strings, and authentication info, if applicable
o SNMP standard Contact and Location information
o SNMP Trap destination addresses
· Syslog destination addresses
· telnet, enable or administrator password
· IP TCP/UDP filters or access lists
· SMTP or NTP Time server addresses, timezone offset settings
· Leave layer 2 discovery protocols enabled? Ie CDP, LLDP
· Leave Spanning tree enabled; specific configuration changes
· Log login times or attempts
· Ethernet port speed and duplex settings
Recent Comments