Corporate Security Policies

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.

SECURITY AND SARBANES-OXLEY

A few years ago, the health-care organizations in the United States were legislated to comply with the Health Insurance Portability and Accountability Act (HIPAA), which protects patient privacy and records. As of April 15, 2005, all U.S. companies also have to comply with the Sarbanes-Oxley Act.

The Sarbanes-Oxley Act, more commonly referred to as Sarbanes-Oxley, was named for the two Congressmen who sponsored it. On the surface, it doesn't seem to have much to do with IT security. The law was passed to restore the public's confidence in corporate governance by making chief executives of publicly traded companies personally validate financial statements and other information. President George W. Bush signed it into law on July 30, 2002. All companies have to comply by April 15, 2005.

The law mainly deals with many corporate governance issues, including executive compensation, off-book transactions, the use of independent directors, and so on. IT security was not directly mentioned. However, there is a provision in the law mandating that company executives attest to their companies' having proper "internal controls." As you will readily agree, it's hard to sign off on the validity of data if the systems maintaining it aren't secure.

Sarbanes-Oxley doesn't mandate specific internal controls such as strong authentication or the use of encryption, but if someone can easily get in your system because you have a weak password, that is a sign of noncompliance. Consequently, upper-level management and their security staff need to ensure that proper and auditable security measures are in place and enforced. A set of comprehensive corporate security policies, such as those discussed in this chapter, would go a long way with Sarbanes-Oxley compliance. Even if you are not required to comply with Sarbanes-Oxley or HIPAA (because you are not located in the United States), it is still good business practice to ensure that your data is safe from prying eyes.

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:

• Physical security

• User accounts

• Strong passwords

• Remote access

• Firewalls

• Acceptable use policy

• Information protection

• Incident response

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:

• Email usage and policy regarding email forwarding to offsite addresses

• Data backup, retention, and offsite storage (see Chapter 10, "Data Backup and Disaster Recovery")

• Laptop usage and security

• Wireless security (see Chapter 13, "System Security")

• Change management process

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 Security

The 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:

• Servers and critical network components, such as routers and switches, should be kept under lock and key. Authorized access to the areas where these devices are kept should be restricted to a short list of personnel.

• In situations when extreme confidential data is stored on the server, access to the server room should be possible via magnetic card access only, where each authorized individual has a separate access card. This way, chronological who-entered-when entry records can be maintained.

• Unused ports on your hubs and switches should not be connected to the wiring patch panels. This prevents unauthorized connection of a sniffer, for instance, onto your network from an unoccupied office.

• Server cases should be locked using built-in locks to deter hard disk theft. Although these types of locks are easily picked (without using special tools), someone spotted "fiddling" with the locks would draw attention.

• BIOS bootup passwords can be used on the server. This practice is debatable because most, if not all, administrators find that the password is easily disabled and that it makes autorestart of servers impractical. Some companies actually make a policy that BIOS passwords not be used.

  CAUTION

  Don't confuse the bootup password with the configuration password. Many networking devices, such as routers, require you to supply a password to make configuration changes. Such passwords should be used. As a matter of fact, your password management policy should mandate that the default passwords for such devices be changed before they are put into production.

  
  

• If you are using wireless access points, ensure they are not servicing areas outside your office space, such as an adjacent office building. A separate policy on wireless security may be warranted. (See Chapter 13 for more information about wireless security.)

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":

• Servers and critical network components should be connected to uninterruptible power supply (UPS) units to ensure they are not subjected to sudden power spikes and that they are properly and automatically shut down after a prolonged power outage with the help of software such as PowerChute (www.apcc.com/products/management/pcp_linux.cfm). At the very least, power surge protection devices should be utilized. (Policies and procedures should be in place to periodically test the effectiveness of the connected UPS units.)

• Putting UPS units in wiring closets may be unnecessary, but it is a good idea to have the hubs/switches connected to power surge protectors.

• If you have distributed wiring closets on your premises, redundant links should be run between them and the central wiring hub/switch (which is usually located in the computer room), as illustrated in Figure 11.1.

  Figure 11.1. Redundant links from wiring closets back to the computer room.

  

  
  

• When wires are run between floors (such as between the 12^th floor and the computer room on the 5^th floor), they should be placed inside conduits. Depending on the local building safety codes and the type of wiring being used, the conduits may have to be sealed and pressurized with nitrogen gas.

  TIP

  If your local safety code doesn't require you to use conduits for running wires between floors, it is still a good idea to do so. This will make unauthorized tapping into your network a lot more difficult when the wires located in the shared closet areas are protected inside a pipe.

  
  

• Servers and network devices should be placed off the floor level. If you have a dedicated computer room, chances are good that you have a raised floor. Otherwise, you should purchase server racks where you can put your servers and network components. At the very least, put them on tables. In more than one instance, we have seen servers or computing devices (such as switches in a wiring closet) being damaged by water, either due to broken pipes or an accidental spill.

• Computer rooms should not use water sprinklers for fire-fighting purposes. As a matter of fact, building safety codes in many cities stipulate what nonwater-based fire-fighting measure is to be used in such installations.

• Wiring closets should be well ventilated and have temperature sensors that provide you with a warning should their temperature rise past a certain threshold.

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:

• Scrub the drive of all data (see the "Information Protection" section later).
  
  
• Update the inventory tracking database.
  
  
• Notify the personnel in the appropriate departments (such as Shipping or Front Desk) so they know this specific hard drive is leaving the company property with authorization.
  
  

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 Accounts

A 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:

• The employee's manager or supervisor submits a request to IT Support, specifying the list of shared folders and databases and the type of access (such as read-only or read-write) required for the user account.

• The account is created via "user account provisioning." User account or identity provisioning is an automated process of creating and enabling access to all needed applications and services for any end user.

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 Passwords

Strong, 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.

PASSWORD-CRACKER: A DOUBLE-EDGED SWORD

Some people believe that password-cracking software could be used only for criminal purposes by hackers. This is far from the truth. System administrators can also use password-crackers to ensure that users are implementing strong passwords. You can use password-cracking tools to test the strength of your users' passwords and then notify those users whose passwords are found to be weak.

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 62⁴ 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.

Table 11.1. Password-Cracking Times Based on Five Million Guesses Per Second

LENGTH	NUMBER OF POSSIBLE PASSWORD COMBINATIONS	CRACKING TIME
1	62	12 microseconds
2	3,844	770 microseconds
3	238,328 (quarter of a million)	50 milliseconds
4	14,776,336 (14 million)	3 seconds
5	916,132,832 (almost one billion)	3 minutes
6	56,800,235,584 (56 billion; 56x109)	3 hours
7	3,521,614,606,208 (3.5 trillion; 3.5x1012)	8 days
8	218,340,105,584,896 (200 trillion; 200x1012)	1.4 years
9	13,537,086,546,263,552 (13 quadrillion; 13x1015)	85.85 years
10	839,299,365,868,340,224 (840 quadrillion; 840x1015)	53 centuries
11	52,036,560,683,837,093,888 (52 quintillion; 52x1018)	330 centuries
12	3,226,266,762,397,899,821,056 (3 sextillion; 3x1021)	20.5 million years

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.

QUICK-START STEPS TO JOHN THE RIPPER

After downloading and installing the John the Ripper RPM package, you can find all the necessary files in /var/lib/john. Download the wordlist file from ftp.suse.com//pub/people/lrupp/john; additional wordlists (in different languages) can be found at www.openwall.com/wordlists, ftp.ox.ac.uk/pub/wordlists, and ftp.cerias.purdue.edu/pub/dict/wordlists. Concatenate your desired wordlists into a single file and append it to /var/lib/john/password.lst.

John works with the /etc/passwd file. However, because SLES uses a shadow password file, you (as root) need to "unshadow" it before unleashing John on it:

 $ cd /var/lib/john $ unshadow /etc/passwd /etc/shadow > passwords.dat $ chmod 600 passwords.dat $ john passwords.dat 

The chmod command ensures the recombined password file (passwords.dat) is accessible only by the owner (root) and no one else; you don't want users to stumble across that file accidentally and make a copy of it so they can perform their own crack.

John runs silently without displaying anything to indicate how it is doing. This permits you to run it as a background task; you may want to use the nice command so the process does not hog the CPU too much. When running in the foreground of your terminal session, press any key to obtain a one-line status message telling you the run duration and a few statistics, or press Ctrl+C to abort the session. You can resume an aborted session using the john --restore command.

Cracked passwords are written into the file john.pot, and the cracked username/password pairs can be shown with the --show switch:

 $ john --show passwords.dat 

You can instruct John to crack passwords of only certain users or groups with the --users: and --groups: switches. For instance, to crack passwords only for root and members of the Admin and Helpdesk groups, enter the following:

 $ john --users:root --groups:admin,helpdesk passwords.dat 

Running John with no options prints usage information. You can find additional documentation in /usr/share/doc/packages/john; the file EXAMPLES contains tips on ways you can use John's features.

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:

• Do not use the default DES password hashing algorithm; use MD5 or Blowfish instead (you can do this either during the server installation (as outlined in the "System Configuration" section of Chapter 1, "Installing SUSE Linux Enterprise Server"), or you can change it later as discussed in the section " Use a Strong Password-Hashing Algorithm" in Chapter 4).

• Make sure user passwords are a minimum of 8 characters long; system administrator passwords should be a minimum of 10 characters long.

• Do not use all punctuation, all digits, or all alphabetic characters for a password; the password should include a combination of punctuation, digits, and letters.

• Use mixed-case letters in passwords.

• Choose a phrase or a combination of words to make the password easier to remember.

• Do not use a word that can be found in any dictionary (including foreign language dictionaries).

• Do not use a keyboard pattern such as qwertyui or oeuidhtn (look at a Dvorak keyboard).

• Do not repeat any character more than once in a row like zzzzzzzz.

• Do not base the password on information that can be easily determined such as telephone numbers; car license plates; names of friends, relatives, or family pets; or any date.

• Never use your account name as its password.

• Use different passwords for different systems, unless a central authentication server (such as LDAP) is used.

• Enforce password aging so passwords are changed regularly; the aging frequency for system administrators should be set higher than for users.

• Do not reuse passwords or attempt to reuse them by appending or prepending a digit or punctuation mark to the old passwords.

• Do not write down passwords; when you must, ensure they are carried on your person and not left out in the open (such as stuck to the monitor or under the keyboard).

  TIP

  One exception about not writing down passwords may be the root password. Because it is the most important password for your server, it needs to be "strong." This means the root password tends to be long (10 characters or more) and hard to remember. Some organizations store a hard copy of the root password in a secure location, such as the company safe or a bank safety deposit box, so there is still a way into the system if the system administrator is unavailable.

  
  

• Disable unused or nonlogin application accounts by setting an invalid password hash.

• Do not use default passwords for any applications. Some applications' installation procedures automatically assign a password; change it immediately after installation.

• Do not use default password or SNMP community names for any network devices (such as a router).

• Enforce use of strong passwords by periodically checking for weak passwords using a password-cracker.

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.

WARNING

You should check to ensure that the act of password cracking does not contravene any local laws. In particular, if you are a consultant asked to audit a server for weak passwords, ensure you obtain the proper clearance from the company's senior management in writing prior to even getting a copy of the password file. In some jurisdictions, the possession of the /etc/passwd file belonging to a server that you do not manage is considered theft. Therefore, get your authorizations in order before doing any password cracking.

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 Access

With 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.

Firewalls

Any 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:

• Describe, in general, how and what perimeter security is maintained; for instance, list what external services users are allowed to access and what services will be denied.

• Indicate who is responsible for checking and maintaining the security.

• Describe how hardware and software changes (such as firmware upgrades) to perimeter security devices are managed and how changes are requested and approved.

• List the procedure to request a firewall device configuration change and how the request is approved.

• Indicate who can grant privileged access to perimeter security systems, and how and who can obtain privileged access.

• Indicate how and who is allowed to obtain information regarding the perimeter configuration and access lists.

• Specify review cycles for perimeter device system configurations.

• If you allow users to access your network remotely, you should require that these remote systems (such as home computers and laptops) have a host-based personal firewall (such as ZoneAlarm) installed.

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 Policy

An 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:

• Ways the users should safeguard their system passwords and other access tokens (such as magnetic access cards) that would grant them access to the network resources

• Ways to handle data confidentiality.

• Policy regarding softwarefor instance, users should not copy, install, or remove any application from their company-provided workstations without explicit permission.

• Policy regarding changing of desktop configuration and settings.

• Ways the user can use the company email systemfor example, what types of file attachments are permitted and if email and data should be encrypted before being sent.

• Categories of company data that may be taken offsite (such as on a laptop or PDA) and how (for example, whether they need to be encrypted first).

• Rules for using wireless devices.

• Clear policy on how company equipment may be used, if users are provided with such equipment, such as laptops.

• Restrictions on what type of data may be exchanged and how, if you permit users to access your network from home.

• Rules for using packet sniffers, network scanners, and password-crackers.

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 Protection

Network 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:

• Define who can have access to sensitive information.

• Have categories of data (or levels of sensitivity) such that users can be granted access based on a need to know, special circumstances, nondisclosure agreements, and so on.

• Define how sensitive information is to be stored and transmitted, such as if the data needs to be encrypted and what types of encryption cipher it should use, or if it should be stored on an encrypted filesystem on the server. Export laws need to be taken into consideration when formulating policy for transmitting encrypted data across country boundaries because certain encryption technologies are not accessible on a worldwide basis.

• Identify on which systems sensitive information can be stored and whether it should be stored using filesystems (such as Reiser) that do not permit undelete.

• Discuss what levels of sensitive information can be printed on physically insecure printers.

• Specify how sensitive information is removed from systems and storage devices, such as degaussing of storage media (such as backup tapes), scrubbing of hard drives (as discussed in Chapter 6, "Filesystem Security"), and shredding of hard-copy output and CDs/DVDs.

• Discuss any default file and directory permissions defined in system-wide configuration files.

• Provide baseline requirements for implementing and using virus protection software.

• Provide guidelines and procedures for reporting and containing virus infections.

• Discuss requirements for scanning email attachments, both inbound and outbound.

• Detail specific policies for downloading and installing software.

• Detail specific policies for the use of thumb/flash memory devices and CD/DVD burners.

• Discuss testing and implementation procedures for new software and software patches.

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 Response

Policies 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:

• Define how to handle anomaly investigation and intruder attacks.

• Specify areas of responsibility for members of the response team.

• Determine what information to record and track and how.

• Specify a list and the order of people to notify and when.

• Define who can release information (for example, the shift supervisor) and the procedure for releasing that information and to whom. This same person may also act as liaison to outside agencies (such as the police or FBI) and organizations (such as the press and the company's business partners).

• Define how a follow-up analysis should be performed and who will participate.

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.