Mischief-makers are constantly searching and scanning the Internet for vulnerable systems. They could be snooping recreationally, conducting espionage, looking for free bandwidth, attempting to vandalize a system, or to sabotage an entire network. There are two classes of these people: the experts and the “script kiddies”. The experts have an in-depth understanding of operating systems, networks, databases, and programming. Script kiddies do not necessarily have in-depth knowledge or experience, but they do have the tools that have been written by the experts. If an expert has more expertise than the best in your enterprise, then you may be in for trouble regardless of what you do. On the other hand, some experts and most script kiddies may just be looking for an easy target. It is the responsibility of every enterprise to be a difficult target.
If you follow the ten well-known practices discussed in this paper, you will be able to prevent the majority of attacks. The purpose of this paper is simply to remind the reader of the basics. This paper will not be a highly technical discourse on how to protect systems, nor will it be introducing new and sophisticated methods of protecting networks.
1) Use Secure Passwords
One of the most important defenses against an attack is to use good passwords across all servers. This includes test servers as well as production servers. Never use names, dates, or words that can be found in a dictionary (English or foreign). These types of passwords can be easily guessed. People need to be aware that password guessing software is widely available. Processing power is dirt cheap and available to everyone. With an inexpensive computer, downloaded software, and a list of words, names, commonly used passwords, and character combinations, it’s not difficult to “harvest” passwords. John the Ripper is one of the better-known password crackers. It can “guess” millions of passwords in a single minute.
On most operating systems, passwords are stored in encrypted form. This is done by an “irreversible hash”. This means that a password in cleartext can be mathematically encrypted into a hash. The math doesn’t allow the hash to be converted back into cleartext, even when the encrypting algorithms are well known (which they are). A password-guessing program can encrypt a “guess” and compare it to an already hashed password. When they match, it has “guessed” a password.
Since technology makes it easy to “guess” passwords, it’s important to keep encrypted passwords in non-public directories. In some UNIX systems, passwords are readable by anyone with a login, i.e. /etc/passwd. UNIX has been around for years, long before computers with sufficient power to guess passwords were widely available. These days, it’s more common to store passwords in /etc/shadow which is not publicly accessible.
Since passwords are encrypted on most operating systems, even the systems administrator does not have direct access to unencrypted passwords. However, they do have access to encrypted passwords. With a password cracker, they can eventually guess your password. One might ask, in most cases if the systems administrator has access to everything on the system anyway, what does it matter? The answer: In this day and age, computers are everywhere. Most computers require some type of password. A systems administrator or I/T professional can have access to a dozen or more computers. That’s quite a few passwords to remember. It’s common (but poor) practice to use the same password across multiple systems. Unless the user uses a different password on every single system, an unscrupulous systems administrator can “harvest” passwords for systems that s/he shouldn’t have access to.
It may be impractical or unreasonable to ask people to use a different password on every system but at the very least keep the following in mind:
Test systems should have the same level of security as production systems. If encrypted passwords are protected on production systems and not on test systems, then production passwords can become compromised. Even if corporate policy states that employees should use different passwords on every system, unless the policy can be software enforced, some people likely will violate the policy. People should NEVER use their corporate passwords on servers outside of company control.
As stated before, password crackers can easily guess millions of passwords every minute. Even with this processing power, it can take a very long time to guess a password. Crackers use word lists to narrow down the choices. The best way to create an un-guessable password is to not use words that can be found in a dictionary or cracker word list (e.g. abcdef, qwerty, 123456, etc.). Be aware that crackers are smart enough to guess common word-number combinations such as password1 or secret2 etc. Therefore, wherever possible use nonsensical passwords containing both upper and lower-case letters, numbers, and punctuation characters. Password complexity rules should be software enforced where possible, such as the NT/W2K system policy editor. Rules that enforce password complexity on other systems will be dependent upon the operating system and software.
Another important password security measure is to require people to change passwords at periodic intervals. How often will depend upon a number of factors but generally the interval should be about 45 – 90 days. Also, don’t forget to delete or disable a person’s logins immediately after s/he leaves the organization.
When managing passwords, it’s important to keep close tabs on vendor and default accounts. For example, staff should take precautions to activate vendor accounts only when necessary to solve a specific problem and to de-activate the account immediately afterwards. Furthermore, do not allow vendors to use standard passwords on their accounts (i.e. insist that vendor passwords be unique to your site). Finally, change default passwords and/or disable default accounts immediately after installing new software. This should go without saying. Even so, negligent system administrators often fail to change default passwords. Hackers already know the default passwords. Default password information can easily be found with a simple Google search or getting a list of defaults from a site such as: http://www.phenoelit.de/dpl/dpl.html