Default Passwords and What You Can Do About Them - Page 3

By Kurt Seifried | Posted Oct 16, 2000
Page 3 of 3   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

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.

Attackers can be expected to conduct sweeps of your network looking for devices that are remotely manageable, and then use automated tools to try to log into them using the default passwords. There are two primary methods. The first is to use a tool such as nmap to identify which hosts are up, identify the OS they are running (via TCP-IP fingerprinting), and then try the specific defaults for each device. The second is to simply pound on each device that has telnet open and try every default user and password (if they just wanted to target 3Com equipment, this would be about a dozen username and password pairs). Needless to say, they could very quickly go through your network and hijack any 3Com equipment that still has default passwords left in it. You can also be sure that products like CyberCop and Nessus will integrate these checks into new versions of their software (and of course the bad guys have access to these tools).

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.


Related Links

http://www.securi typaradigm.com/defaultpw.htm



Kurt Seifried (seifried@securityportal.c 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.
http://www.SecurityPortal.com
The Focal Point for Security on the Net (tm)

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter