UNIX System Administration Handbook - Evi Nemeth [386]
Your site’s security policy should specify how sensitive information is handled. See Chapter 27, Policy and Politics, and RFC2196 (the Site Security Handbook) for some suggestions.
• Plug holes that hackers can use to gain access to your system. Monitor the security bulletins from your vendor and the security mailing lists discussed in this chapter to learn about patches as they become available. Turn off unnecessary services.
• Don’t provide places for hackers to build nests on your system. Hackers often break into one system and then use it as a base of operations to get into others. World-writable anonymous FTP directories, group accounts, and accounts with poorly chosen passwords all encourage nesting activity.
• Set traps to detect intrusions and attempted intrusions. Tools such as tripwire, tcpd, and crack (described starting on page 663) will help keep you abreast of potential problems.
• Monitor the reports generated by these security tools. A minor problem that is ignored in one report may grow into a catastrophe by the time the next report is sent.
• Teach yourself about UNIX system security. Any number of high-priced security consultants will happily come to your site and instill terror in you and your management about the insecurity of your systems. They’ll explain that for only $250K they can make your site secure.
Unfortunately, their solutions will often leave you with dead mice in your walls and kill your users’ productivity. Traditional know-how and common sense are the most important parts of a site security plan.
• Prowl around looking for unusual activity. Investigate anything that seems unusual, such as odd log messages or changes in the activity of an account (more activity, activity at strange hours, or perhaps activity while the owner is on vacation).
21.2 HOW SECURITY IS COMPROMISED
The sections below discuss some common UNIX security problems and their standard countermeasures. But before we leap into the details, we should take a more general look at how real-world security problems tend to occur. Most security lapses stem from one of the following types of problems:
• Unreliable wetware:The human users (and administrators) of a computer system are often the weakest links in the chain of security. For example, America Online used to be notorious for being infested by hackers who posed as AOL employees. The hackers sent email to potential victims asking them to send back their passwords as part of a “system test” or “to verify your account.” Unsophisticated users often didn’t (and still don’t) know any better than to comply.
There are countless variations on this ploy. As an administrator, part of your job includes teaching users about proper security hygiene. Many users are still very new to the Internet, and they often have no idea how many scams and freaks are afoot. Tell them how to select and defend good passwords, how to protect their work, and how not to talk to strangers. Make sure your instructions cover non-email communication, too; a telephone can be a hacker’s best friend.
• Software bugs:Over the years, countless security-sapping bugs have been discovered in UNIX software (including software from third parties, both commercial and free). By exploiting subtle programming errors or context dependencies, hackers have been able to manipulate UNIX into doing whatever they want. What can you as an administrator do to prevent this? Very little, at least until a bug has been identified, fixed by the vendor, and addressed in a patch. Keeping up with patches and security bulletins is an important part of most administrators’ jobs.
• Open doors:Many pieces of software can be configured securely or not-so-securely. Unfortunately, not-so-securely is often the default. Hackers frequently gain access by exploiting software features that would be considered helpful and convenient in less treacherous circumstances: accounts without passwords, disks shared with the world, and remote logins