Default Passwords and What You Can Do About Them - Page 3
Ultimately, all these solutions require some degree of user education. You could solve the problem by using a technical solution such as tokens, but this would create other problems (what happens when you lose the token? what about distributed administration?), and is generally not feasible.
A company should have a policy for setting passwords and so on for hardware and software devices and packages that are being installed. The person or group responsible for the item should be given the task of assigning the password, keeping it recorded somewhere (preferably on a machine that is not networked) and generally taking care of the item (such as upgrades, configuration and so on). The password should be recorded, since people leave companies, get run over by trucks, forget things, and so on. Alternatively, if the device supports it, you should use token- or smartcard-based authentication systems. This way you can easily share the PIN number or password needed to access the smartcard or token, but by keeping the smartcard or token physically secure not have to worry as much about someone leaking the PIN number or password. Unfortunately, the vast majority of network- based equipment that can be remotely managed is done so via telnet, which means attackers can easily sniff passwords or hijack sessions.
So what can you, as a network administrator, do? Well, for starters, check that all remotely manageable devices (routers, switches, servers, etc.) have strong passwords set. Also check the list of default passwords to see if you own any equipment or software listed on it, and also check with employees to see if they have such devices at home, and make sure the issue is made clear (you're not angry at your employees for not setting the password; you want to help themplaying the blame game is useless). Find out who is responsible for each item and make a list (this is a good idea in the long term when you have problems with them). Many IDS systems are easily extensible and you can add checks for the default usernames and passwords such as "PASSWORD" and "CHANGE_ON_INSTALL DBA + ". You should also firewall any access to these devices from the Internet, and if you must manage devices at a remote site, consider using VPN software to create a secure tunnel between your site and the remote one.
|"Long term, I think the solution is to implement authentication schemes that provide stronger control than simply usernames and passwords."|
Long term, I think the solution is to implement authentication schemes that provide stronger control than simply usernames and passwords. Already companies are deploying smartcards, tokens, biometric-based systems and so on. There are also much better mechanisms than telnet for logging into remote equipment. Ideally, support for SSH, Kerberos and other strong authentication systems should be built into products. When buying equipment, ask the vendor if they plan to support such things, and if not, why not. Cisco, for example, now has SSH on their 7200, 7500 and 12000 series equipment. This is a good startas a Cisco customer, you can exert some influence, and if enough customers demand SSH support on other Cisco products, chances are that it will happen.
Kurt Seifried (firstname.lastname@example.org om) is a security analyst and the author of the Linux Administrators Security Guide, a source of natural fiber and Linux security, part of a complete breakfast.
SecurityPortal is the world's foremost on-line resource and services provider for companies and individuals concerned about protecting their information systems and networks.
The Focal Point for Security on the Net (tm)