Even though SLES 9 has been certified to meet the internationally recognized Common Criteria's Evaluation Assurance Level 4+ (EAL4+) security rating, it does not mean your SLES 9 server is automatically EAL4+ rated upon installation: You need to enable the various security options and features. Depending on your specific needs, enabling the full range of EAL4+ settings may be too restrictive. Additionally, these EAL4+ settings apply only to the server's security but do nothing for the overall corporate security. What you need is a set of corporate security policies. NOTE For more information about the Common Criteria security rating, see Appendix A, "Security Certifications." With the ever-increasing dependency on computer technology for ongoing business activities, it is imperative that a company has a plan to protect its computing resources and the data contained therein. This plan is normally part of a security policy. A security policy is a document that stipulates the rules for which a company's assets (such as computers) and data are to be configured, maintained, and used. It also identifies the relative value of the company's assets and data. The security policy should be reviewed and updated whenever your organization's business needs, activities, and assets change. Even if everything remains relatively static, the security policy should still be reviewed periodically, perhaps annually, to refresh your and your staff's memory on how things should be done.
NOTE Providing a thorough study of security policy development or its prerequisite requirements (such as risk analysis) is beyond the scope of this chapter and this book. You can find an excellent collection of security policy templates and related information that can help you to jump-start your security policy development at www.sans.org/resources/policies. Procedures are equally important as policies. Often, policies define what is to be protected and what are the ground rules. The procedures outline how to protect the resources or how to carry out the policies. For example, a password policy would outline password construction rules, rules on how to protect your password and how often to change them. The password management procedure would outline the process to create new passwords and distribute them, as well as the process for ensuring the passwords have changed on critical devices. A one-to-one relationship will not always exist between policies and procedures. The remainder of this chapter provides a high-level overview of some specific security policy topics as they pertain to computer networks. Within that context, you will also find some rule-of-thumb procedures that you can incorporate into your own security policies. The following topics are covered in the upcoming sections:
Following are some other policy topics that you should also consider. Although they are not covered here, some have been discussed in other chapters of this book:
You may already have in place a number of policies that were common practices but were not put down on paper. If someone came in and said, "Show me your policy," you couldn't pull out a document and say, "Here." As a result, some would then say you did not have a policy. To avoid finger-pointing, document all policies. Physical SecurityThe first aspect of security, whether computer networking related or not, is physical security. If whatever you are trying to protect isn't physically secure, unauthorized access would be possible regardless of how strict your other security measures may be. Physical security is mostly about common sense, but a few items are often taken for granted, and thus overlooked. The following list describes some of the items that you should consider when implementing physical security for your network:
The following are a few items we consider as part of physical security, but some people would instead classify them under the topic "environmental security":
Part of physical security policy overlaps that of asset management policy. You need to put in place policies and procedures on when and how a piece of networking hardware is to be installed or removed from the premises. For instance, prior to your moving a server's hard drive offsite for disposal, you should complete the following steps:
If the hard drive to be disposed of held sensitive information, you may want to be paranoid and go the extra step of having it physically destroyed after scrubbing it of all data. It would be a good idea to obtain a written confirmation from the person or company performing the task, attesting to the fact that the hard drive was indeed destroyed. User AccountsA combination of user account and password is the key to your "data kingdom." Therefore, clear policies and procedures must be in place to control their creation and revocation. An employee generally is given a user account to access a company's computing resources in two ways:
There are pros and cons to both approaches. When a new employee joins a company, he or she typically needs access to a variety of accounts and services to do his or her job effectively. It is not uncommon for employees today to have three or four different IDs for services such as group folders stored on network servers, email, enterprise portals, various databases, and more. As a business grows its IT infrastructure with a diverse mix of enterprise applications, systems, and directories, the complexity of managing and securing those resources grows exponentially. The effort of manually giving users access to the myriad disparate systems that they need not only costs the IT department significant time (and thus money), but it opens the door to human errors that may lead to security vulnerabilities in the enterprise's network. On the other hand, because the accounts are not automatically allocated but have to be requested, there is much better control over their creation and dispersion. As you can imagine, with mid-size to large organizations, the process of managing users' access to applications and services is very labor intensive and time consuming: A new employee may have to wait for up to a week to receive all required accesses. To simplify the process, these companies often implement a process known as identity provisioning. Based on predefined roles (such as an entry-level marketing sales position), identity provisioning automates the essential tasks of creating and maintaining user accounts and the associated access rights to various resources. This provides huge time and cost savings, as well as rapid deployment of user identities, applications, and services for many companies. One of the main drawbacks of such an automated process is that exceptions to the rules are difficult to handle, and often manual processing is required. NOTE For information about Novell's Nsure Identity Manager, visit www.novell.com/products/nsureidentitymanager. No matter whether you use the manual route or the identity provisioning method, you need to have policies and procedures in place for account termination. This is a very important aspect of your user account security policies and procedures. More than 50% of system break-ins can be attributed to user accounts whose owners are no longer with the company, but the accounts have not been disabled or deleted. Unless an employee's termination is a spur-of-the-moment event, Human Resources (HR) generally knows about it ahead of time. Therefore, your company should have a policy/procedure that when HR is informed of an imminent termination action, the IT department is also informed so that the user's access to company information can be removed at the same time the termination notice is given. When identity provisioning is used, all the user's accounts should be automatically disabled upon HR setting the employment termination flag in that person's record. Lastly, we would like to add a few words about system accounts that are not used by humans, but by applications. As previously discussed in Chapter 4, "User and Group Administration," and Chapter 8, "Network Services," whenever possible, system services should be run under nonprivileged accounts instead of root. Some package installations create a user account to be used by the package. In all cases, you should ensure these application accounts are not given a useable shell, to prevent them from being used by intruders to access your system. We recommend that you set the shell for these accounts to /bin/false. TIP You may want to add /bin/false to the list of available shells in /etc/shell. This way, when YaST is used to create a user, your account creation procedure for application accounts can specify that the /bin/false shell be selected from the drop-down list. Regardless of how your user accounts are created, either manually or via provisioning, ensure a clearly stipulated set of requirements exists on the minimum amount of user information that must be recorded in the user account record. For example, include location of home directory, groups the user belongs to, GECOS data (if any telephone numbers are to be included or not), and so on. Strong PasswordsStrong, secure passwords are a cornerstone of an effective security strategy. Passwords ensure that only authorized personnel will be able to gain access to system resources. Unfortunately, this is not always the case. The individuals who are utilizing these resources choose most passwords and, as a result, the words, symbols, or dates that make up the passwords usually have some personal meaning to the users so they are easier to remember. Herein lies the problem. Because of human nature, convenience is often chosen over security. As a result, users choose passwords that are relatively simple. Although this helps them to remember the passwords, it also makes the passwords much easier for hackers to crack. The first line of security defense thus becomes one of the weakest. NOTE Hackers will probe a network looking for the weak link that will give them entry, and the most notorious and easiest to exploit is a weak password. Part of your responsibility, as the system administrator, is to ensure that users are aware of the necessity of maintaining viable secure passwords. This means users must be educated about the importance of strong passwords and ways to implement them, and you need to implement measures that will ensure their passwords are adequately strong. You can accomplish both goals using the same tool as a hacker: a password-cracker.
Users are not the only guilty parties when it comes to choosing weak passwords for convenience's sake; many system administrators are also guilty of the same offense. Because they have a number of passwords to remember, system administrators often pick the same simple password for many applications. Even with PAM-enabled tools, users with root privileges can bypass the strong password enforcement. Couple this with the fact that administrators can modify or remove reminders to change passwords from their own passwords, and you have a serious problem. Finally, system administrators may often take shortcuts in the installation of software or equipment that leave applications with their default passwords. This occurrence is so common that repositories on the Internet list all these default passwords (see "Default Passwords and SNMP Community Names" in Chapter 13). This obviously creates a serious weakness in the security chain. The two small demonstrations discussed next are usually sufficient to convince users and system administrators alike that weak passwords are easily broken. First, provide your users with some simple statistics. In round numbers, assume that brute-force password-cracking software can test 5 million (clear-text) passwords (of any length) per second. This means a four-character password based on a combination of upper- and lowercase letters and the numbers from 0 to 10 (for a total of 624 or about 14 million possible combinations) would be broken in no more than 3 seconds. However, as the number of characters in the password increases, the corresponding cracking time increases exponentially, as illustrated in Table 11.1.
Bear in mind that the times listed in Table 11.1 are for cracking clear-text passwords where no computations are necessary. Breaking password hashes in which complex algorithms are involved would take much longer. NOTE It is worth remembering that certain password-hashing algorithms limit the number of characters in a password. For instance, a DES-hashed password is limited to eight characters in size. Furthermore, depending on the algorithm and the "salt" used for computing the hash, there is a remote chance that two or more different passwords will result in the same hashed value, effectively making the password easier to "crack." Given the ever-increasing speed of computers and better software algorithms always being developed, these changes give credence to the standard recommendation that a password should be at least six to eight characters in size. Furthermore, the password should be composed of printable characters (including symbols such as $ and :) available on the keyboard. Most of the people presented with the information contained in Table 11.1 instantly understand the need for lengthy passwords. However, they are not always convinced that their "favorite" passwords are vulnerable if the passwords are sufficiently long. At such times, demonstration of a password-cracker, such as Crack or John the Ripper, is necessary. Seeing is believing, and nothing drives the lesson home faster and harder than letting the users see how quickly their "secret" passwords are revealed. The most popular Linux/Unix password-cracking utility is probably Crack by Alex Muffet (www.crypticide.com/users/alecm/). Crack can be configured to periodically run and automatically email a cautionary note to the users with weak passwords, or it can be run in manual mode. Crack can also be configured to run across multiple systems and to use user-defined rules for word manipulation and mutation to maximize dictionary effectiveness. It is probably too much of a program, however, for a novice administrator to master. Another popular favorite is John the Ripper, based on the popular DOS-based Jack the Ripper. Jack had a number of easy-to-use features, and Solar Designer (www.openwall.com) took Jack's interface and developed John. As improvements over Jack, John has Crack-like rules, and the software runs on DOS, Windows, and Linux/Unix systems. You can use Crack, John the Ripper, or any of the other available password-crackers for your demonstration. The key point is to convince your users that their passwords can be broken and your password policy helps to make their passwords much more difficult to crack; thus, it helps to protect their valuable data. TIP The security scripts included with SLES 9 (such as seccheck) refer to John the Ripper, but the software is actually not included with the SLES 9 CDs. Instead, John the Ripper is included with SUSE Professional, or you can download it from ftp.suse.com/pub/suse/i386/9.2/suse/i586/john-1.6.37-21.i586.rpm or ftp.suse.com//pub/people/lrupp/john.
The level of security offered by a password is similar to that of a combination lock: If the characters are chosen truly at random, one can have millions to quadrillions of possible combinations. Furthermore, the more complicated the method required to turn this combination lock, the longer it takes to crack it. As discussed previously in Chapter 4's "Use a Strong Password-Hashing Algorithm" section, MD5 and Blowfish algorithms are much more CPU-intensive than the default DES algorithm used for hashing SLES passwords. This means given the same six-character password, a password-cracker will take a lot longer to break a Blowfish-hashed password than a DES-hashed one. Therefore, your password policy should specify a strong hashing algorithm (such as MD5 because it offers a good balance between speed and complexity) to be used for your systems. The following are some simple guidelines and recommendations you should consider incorporating into your password security policy:
A few words of caution about password cracking: Before you actually implement a procedure to check for weak passwords, you should give some thought to how best to conduct password cracking. For instance, it may be worth considering carrying out any password cracking offline to avoid any chance of the password-cracking session being sniffed by unauthorized parties. What's more, password cracking should not be undertaken without the proper authorization of senior management (and perhaps notification of the userssomething to consult your HR department about). Unless the appropriate notification is given and the required authorization received from management, questions could be raised about the credibility and trust of the person conducting the password cracking. Furthermore, fellow employees may interpret password cracking as a violation of their privacy. This could obviously cause serious problems within the workplace.
An undiscovered weak password could make everyone's data vulnerable to compromise. Therefore, it is imperative that all aspects of password assurance are included in the password security policy of the organization. The policy should stress the absolute importance of strong, secure passwords and the role of all individual users in maintaining the strength and security of their own passwords. The policy should also outline the steps that the system administrator is expected to follow (such as using strong password hashes and implementing password aging) in ensuring the security of the system through the use of passwords. Remote AccessWith the wide availability of high-speed network connectivity, users and administrators often access corporate computing resources and upload or download files and email messages to or from the office from customer sites or from home using the Internet. As you will read in Chapter 12, "Intrusion Detection," someone can easily eavesdrop on network traffic without being detected because network sniffing is passive. To ensure your data packets are not snooped by third parties while traversing networks that you have no control over (such as your Internet service provider's network or other intermediate connections), you need to have in place a remote access security policy. In the remote access security policy, you should specify how users are to access company network resources from a remote location. For instance, the policy should specifically indicate that all remote access should be made over a virtual private network (VPN) connection. However, this may not be possible for all cases because some ISPs consider VPNs business usage and require the user to pay for a higher cost connection. Therefore, in the absence of VPN, if certain remote access tools such as Telnet and FTP are not permitted, your policy should have a fallback position that lists their acceptable replacements (such as ssh and sFTP, or secure FTP). You can read more about how to secure various remote access protocols in Chapter 13. Even if you don't access network resources from across the Internet, you should still consider using secure remote access protocols when managing your servers and various network devices from within the office, especially if you use wireless networks. Also discussed in Chapter 13 is the ease in which wireless networks can be monitored from a distance. Therefore, if you manage your network via a wireless connection, someone could sniff your password and later use it to break into your network. Consequently, your remote access security policy should cover all aspects of remote access methods, ranging from Internet access to wireless connections to even modem usage. FirewallsAny network that is connected to the outside world, including remote offices, should have a firewall separating the internal network from the external one, as illustrated in Figure 11.2. There are two basic types of firewalls: packet filter firewalls and application-level firewalls. Figure 11.2. Protecting access to an internal network using a firewall.Packet filter firewalls act on IP datagrams running through them by means of rules based on the data found in an IP packet header (source address, target address, source port, target port, and flags). Because packet filter firewalls work with network layer information (see Figure 11.3), they are also known as packet filter routers or screening routers. You use rules to allow or block certain types of data packets from passing through the router (thus, the name packet filter). For instance, if you do not want anyone from the external network to access your internal Apache servers, you can specify a rule for the screening router to block all incoming packets addressed to UDP port 80. Another example is that if you don't want your users to access any external FTP servers, simply block all outgoing TCP port 21 packets at the router. Figure 11.3. A packet filter router makes routing decisions based on packet header data.An application-level firewall (sometimes referred to as an application-level gateway, ALG, or proxy server) is more "intelligent" than a screening router. An ALG works with all data within a packet, from the IP packet header information down to the actual application data contained within the packet (see Figure 11.4). A typical application-level gateway can provide proxy services for applications and protocols such as Telnet, FTP, HTTP, and SMTP. (Note that a separate proxy must be installed for each application-level service.) With proxies, security policies can be much more powerful and flexible than when using screening routers because all the information in the packets can be used to write the rules that determine how packets are handled by the gateway. It is easy to audit just about everything that happens on the gateway. You can also strip computer names to hide internal systems and evaluate the contents of packets for appropriateness and security; for example, an HTTP proxy can grant or deny access to specific websites based on the URL requested by the clients. Figure 11.4. An application-level gateway processes the data based on application-related data.TIP Firewalls can also be used to protect a department's sensitive, compartmentalized data from being accessed by other departments in the same company. For instance, the Human Resources server may be placed on its own network segment, along with its users, behind a firewall that separates the HR network from the rest of the company. If you offer publicly accessible services, such as web and FTP servers, it is best not to place those servers on your internal network. If you do, you need to open up ports on your firewall to handle their traffic. There is always a chance that, due to an oversight in your firewall rules or a vulnerability in the firewall software, an intruder may find a way to wander your internal network. Instead, it's better to put such servers in a buffer zone known generally as a demilitarized zone (DMZ). You can set up a DMZ in two ways, as illustrated in Figure 11.5. Configuration A is the traditional way of setting up a DMZ: The single firewall controls and regulates access to the three networks. This setup has a drawback similar to placing the public servers on the internal network in that the firewall is the single point of vulnerability. After a server offers its services to the public network, it becomes visible to potential attackers. As a result, if an attacker penetrates your (single) firewall, he also has open access to your internal network. Figure 11.5. Two different DMZ configurations.In larger organizations, the DMZ is often composed of two firewalls, as illustrated by Configuration B in Figure 11.5. In this setup, if an attacker is able to compromise the first firewall, he will be blocked by the second firewall, which generally has a much stricter set of rules than the first firewall because the second firewall does not need to deal with traffic directed to the public services. In either DMZ configuration, servers in the DMZ require an increased administration effort in comparison to those in the internal network. TIP When you use multilayer firewalls in the DMZ, consider using firewalls from different vendors. For instance, the public-facing firewall may be a Check Point FireWall-1, whereas the second layer is a Cisco Secure PIX Firewall. This way, the intruder would not be able to use the same vulnerability that allowed him to penetrate one firewall on the second firewall. Consider the following points for inclusion in your firewall or perimeter security policy:
NOTE You may want to include wireless access point security as part of your perimeter security policy. There are very few valid reasons why a member outside the security and network support staff would need access to firewall configuration information. Often, in a large organization, a dedicated network security group that is separate from the server and network support staff handles perimeter security (including VPN configuration). Perimeter device configuration information should never be stored on or transmitted to systems of general availability, and it should almost never be printed in hard-copy form. Acceptable Use PolicyAn acceptable use policy (AUP) is a set of rules applied by many service providers (such as your ISP) that restrict the ways in which the network may be used and what types of equipment may be connected to the network. For instance, your telephone service provider and ISP will include an AUP as one of the key provisions of their terms of service. You can find an example of an ISP's AUP at www.earthlink.net/about/policies/use. Acceptable use policy is an integral part of the network security policies. It is often common practice to ask new members of an organization to read and sign an AUP before they are given access to its information systems. For this reason, an AUP must be concise and clear, while at the same time covering the most important points about what users are and are not allowed to do with the computing resources of the organization. It should refer users to the more comprehensive security policy where relevant. It should also, and very notably, define what sanctions will be applied if a user breaks the AUP. Compliance with this policy should, as usual, be measured by regular audits. NOTE Although the IT department generally determines the do's and don'ts in an AUP, the penalties to be associated with violations of the don'ts should be made in consultation with the management staff and HR department, and perhaps the Legal department. The following are some topics, other than the obvious ones (such as no accessing nonbusiness-related websites using company resources), that you should include as part of your AUP:
You should also have an AUP, one slightly different from the end-user version, for contractors and vendors that may be accessing your network. In particular, this variant of the AUP must cover rules for data confidentiality and non-disclosure. Information ProtectionNetwork security is all about protecting data from being accessed illegally or otherwise altered or compromised over the network. Some of the topics for information protection policy can be considered to fall under AUP and some under the perimeter security topic. However, your corporate information protection policy needs to cover all angles. The following are some issues and topics you need to take into account when formulating your information or data protection policy. This policy should do the following:
You should give some extra thought to obtaining, testing, and installing operating system software patches. The YaST module offers a feature called YaST Online Update (YOU) that can automatically and periodically check for and apply system software patches (see Figure 11.6). Figure 11.6. Configuring automatic update mode for YaST Online Update.Good change management practice and common sense, however, say you should never apply changes to a production server without first testing the patches thoroughly. Therefore, part of your information protection policy should identify how server operating system software should be tested and applied. A rollback plan and procedure should be part of the policy. Incident ResponsePolicies and procedures cannot totally eliminate threats and vulnerabilities to your network; they do, however, help to minimize impact in the event of an attack. We don't want to sound like pessimists, but you need to formulate a policy and procedures on incident handling. NOTE Depending on the particular business sector you are in, there may be laws that all system intrusion incidents be recorded and reported to the proper authority, especially in light of the Sarbanes-Oxley law that came into effect on April 15, 2005. Therefore, it is essential that you have a proper incident response policy in place. For example, in case of an email-based virus attack, you should take necessary measures to minimize the impact on your company. To start, you should block your outbound email until your systems are virus free. In the mean time, if you know the source of the virus-laden email, you can block the source SMTP server and work with that server's administrator to resolve the problem. If you are unable to identify the source, it might be in your best interest to shut down your inbound and outbound email so at least you have the opportunity to decontaminate your systems and not affect other networks by sending them email with a virus attachment. NOTE Part of being a responsible network administrator and a good "network citizen" is to not only protect your own network but others' as well by not contributing to viruses, security breas collateral spam, and so on. If you have laid out a plan to follow in case of an intrusion or attack, the situation will be handled more effectively than it would be in the absence of one. Although every situation is different, the plan should be as thorough as possible to take care of any problems. One good thing to include in your plan is a policy stating that whoever is handling the incident should take very good documentation of the step-by-step procedures taken to return the network to normal. The lessons learned can serve as input for the next iteration of your disaster recovery plan. An advantage of laying out your plan this way is that it is a proactive approach to solving your problem. From the results of the risk and damage assessment, you will be able to evaluate your options and have more time to plan ahead. Here's one point of caution: Never think that whatever solution you come up with will solve all your problems. Therefore, you need to be prepared for the worst-case scenario. Your incident response policy should include the following action items:
An incident handling procedure is a definite must-have for all organizations. It is impossible to outline responses for all incidents, but you should cover the major types of incidents that might occur. Some sample types are network port scans, Denial of Service attacks, compromised hosts, compromised accounts, and inappropriate use. |