| You can adopt one of several models of security for your system, based on your system's setup and use patterns and your philosophy toward the security needs the system presents. The security model you choose will dictate how careful you must be about certain administrative duties, such as password policies, open services, encrypted traffic, and so on. Here's a short list of some security models, each defined by a general statement that sums up the administrator's assessment of security risks: I trust everybody on the Internet. Most certainly an inadvisable model under any circumstances, this is nonetheless the philosophy that guides the lack of security safeguards surrounding many amateur servers, and the administrators of those systemswho seldom maintain them properlyultimately pay the price for it. Often found on university systems, especially those that have been around since before the Internet became so rich in hacker activity, systems administered with this philosophy have many open services, don't require encrypted logins, have loose account and password policies, and are easy targets for hack attacks. I trust anybody on my system's network. This philosophy is common in small enterprise networks where the server is protected from the general Internet by a firewall or NAT router, and the internal network is made up of employees of a single company or department at a university. In this model, malicious users on the internal network are rare, especially if the organization is small, so the system can afford to provide unencrypted services, give accounts to anybody who asks for them, and even have disabled login security and passwords. Unfortunately, in large organizations, it has become the case that attacks on servers maintained under this modelattacks from within the network, by people who are supposed to be trustworthyare more frequent than attacks from outside. If your organization is large, you must assume that you cannot trust everybody on your system's network, and instead choose a different security model. I trust my local users. Administrators who maintain this philosophy tend to be more paranoid than administrators of the systems described previously in this list's first two models. This security model is characterized by a tight network security policy: screening of users before new accounts are granted, encrypted network services (either required or encouraged), unnecessary services turned off, and crack-resistant passwords. However, local users are allowed to access internal services and see sensitive information (such as encrypted password strings). The idea is that once users are approved and given accounts, they can have the run of the system, and betrayal of that trust is grounds for removal from the system. This model is appropriate for hobbyist systems that serve a "low-risk" audience (for example, a fan website or community email service), or for high-profile commercial Internet servers where only a few trusted people actually have user accounts. I trust only myself and other administrators. The model favored by the most paranoid system administrators, this model not only has tight network security as in the preceding model, but tight local security as well. Regular users are denied access to system configuration files and server-side program code through carefully crafted permissions, Access Control Lists, and even Mandatory Access Control (MAC) labels (an advanced mechanism for controlling user access to files, sockets, and processes throughout the system). The administrator must watch each user carefully to make sure nothing unauthorized is being done, and special measures (such as custom shells, chroot jails, and the disabling of certain commands) are often taken to restrict each user's access to the system's resources. This model is useful for high-profile servers that provide email or web hosting services to hundreds or thousands of users from indeterminate or anonymous backgrounds.
After you've decided what model is appropriate for you and your system for network and user-level security, you need to decide where the risk areas are for that model and what you can do to combat the exploitability of those areas. |
