- Building an Adaptable Infrastructure
- The Tao of Security: Simplicity
- Service Assessment
- Rules, Rulesets, and Rulebases
- Turning Security Policy into Security
Turning Security Policy into Security
The following section illustrates taking a simplistic set of security policies, formulating it into a security architecture, and then explaining what that means in terms of ruleset implementation.
Security Policy
For this example, the simplest useful policy is used. You can be completely secure by allowing nothing to pass and dropping all inbound traffic, but then there wouldn't be much sense in connecting to the Internet:
Provide internal users with unrestricted access to Internet resources.
Allow access to the Company-hosted Web Server, DNS server, and email server.
Deny everything else.
Notice how this doesn't imply anything about the architecture of the Internet connection. Selecting a working architecture will be discussed shortly.
Default Stance
The default stance is your policy on what action is taken for a packet that doesn't match any of the previously defined rules. Normally, for securing a site, the default policy will be to DROP the packet.
Security Architecture
Defining a security architecture is the process of converting security policies into technical implementation. The security architecture is where you decide the following:
Whether you are hosting your servers on one or many demilitarized zone (DMZ) LANs or being dangerous and hosting them on your internal network
Whether you are using just a packet-filtering router or a firewall in conjunction with the router, and so on
The first part of the security policy is to allow any internal network traffic outbound to the Internet. This really doesn't impact any security architecture you might choose.
Hosting Web, DNS, and email services on-site will provide intruders a handhold to access your internal network resources. To protect both your servers and your internal resources, choose to host them on a DMZ. The security gateway, whether it is a packet-filtering router or a firewall, will then be the first line of defense against intruders attacking your servers.
Next, a dedicated firewall system is deployed that connects the internal network to the unprotected network on the router. Additionally, there is a single DMZ segment on which the Web server, DNS server, and mail server will reside. The DMZ is a protected network segment that allows access from both the Internet and the internal network. However, because Internet users will be accessing those servers, the servers can't be trusted. Making the assumption that the servers could be compromised at any time helps define another policy: Any connections initiated from those servers to the internal network will be refused.
Because DNS provides host, server, resource, and internal organizational information, you should use a split DNS. The split DNS provides a minimal subset of the necessary information for external users to contact and interact with the DMZ-protected servers. An internal DNS server on the internal network will carry the full zone information. This qualifies as security through obscurity, but there is no real need to give intruders a map of your network to focus their attacks on.
The mail server will be configured as a queuing mail-hub. This allows internal hosts to relay mail out to the Internet, and it allows the internal mail server to periodically poll the DMZ mail server for queued email. The mail server will not allow unauthorized relaying, the act of forwarding email destined for another domain through your server. This is not only courteous, but helps reduce spam and email abuse. Speaking of which, the mail-hub will also be configured to reject email coming from sites in the Mail Abuse Prevention System (MAPS) Realtime Blackhole List (RBL). The MAPS RBL contains sites that have been used to relay spam, and have refused to take any action against preventing the spammers from relaying through their sites.
Administration of all the boxes will be provided by Secure Shell. As previously discussed, SSH provides both secure terminal emulation and secure file transfer capabilities replacing rsh, rlogin, telnet, and ftp. There's no point in passing your account and passwords in the clear (see Figure 1).
){kind=link}
Figure 1. Internet connection with packet filter router, firewall, and DMZ hosted servers.
Security Architecture to Rulebase
The next step is to take our modified security policy and security architecture, and convert them into rulesets that make up our firewall rulebase. This step is generally firewall-agnostic and doesn't depend on any special features such as stateful inspection or built-in support for specific application services such as FTP. The actual implementation of these generic rules for a specific firewall is where the details of such joy will fall out.
Start Free and Clear
First and foremost, flush all existing rules, and reset all existing firewall properties. This ensures that there are no existing holes, gaps, misconfigurations, or surprises that you weren't expecting.
Remember simplicity: It is better for your firewall to err conservatively and block needed traffic than it is to allow unwanted traffic. Starting with a clean slate by blocking all traffic assures that you at least start out secure with the goal of remaining that way.
Allow Internal Network Traffic Outbound to the Internet
Allow all internal network traffic outbound to the Internet. This rule becomes more complex the more non-contiguous internal networks you need to represent. Because the point of having a DMZ is to host servers that are not trusted, you must ensure that the internal users are not normally accessing the DMZ servers directly. To accomplish this, allow all internal network traffic to any destination except the DMZ. Most all firewalls have the negation operator that allows you to express this rule easily.
Protect the Firewall
Drop all traffic destined for the firewall itself. You don't want people succeeding in sending traffic to the firewall proper. This won't hide the firewall from intruders, but it will generally deny packets and responses directly accessing the firewall. There is a way to hide the firewall, but it's specific to a firewall implementation. Here is where rule order starts to become important because this rule must go prior to the Allow Outbound rule. If the order were to be reversed, internal hosts could access the firewall.
Allow Only Internal Admin Access to the Firewall
Although the firewall needs to be managed, it should be managed only by the firewall administrators. Administrative access should be restricted to which machines the administrators use and types of network traffic required to access and to manage the firewall. For example, UNIX-based firewalls should allow access only by encrypted SSH sessions. Commercial firewalls such as Checkpoint's FireWall-1 have specific firewall administrative ports (256, 257, and 258) that are accessed via encrypted sessions through their management console. This rule must go prior to the drop everything destined for the firewall rule, or even administrative traffic will be dropped.
Default Policy of Drop Everything
The default stance of that which is not explicitly allowed should be denied needs to be implemented. In addition to dropping all other packets, a useful diagnostic method enables logging of the dropped packets. This provides you with the means to troubleshoot firewall issues, and to audit the attempted intrusions. This rule generally goes last.
Drop Traffic You Do Not Want Logged
Broadcasts, Multicasts, and other traffic your firewall sees but you do not want logged should have a rule defined that drops or rejects the traffic, but does not log. This prevents excessive, unnecessary logging that would otherwise clutter up your logfiles. Reviewing your logfiles will be difficult enough without having to wade through page after page of NetBIOS, RIP, OSPF, or DHCP requests. This rule needs to be ordered prior to the protect the firewall rule.
Services Provided to the Internet
You need to allow Internet users access to the servers and services that you are providing to the Internet. This includes DNS name lookups, Web (HTTP/HTTPS), and mail (SMTP):
Allow DNS name lookups (UDP/53) from any network, but allow the internal networks to the DMZ name server only. The internal users should be using the internal DNS servers. If your ISP is acting as a secondary for your external DNS name server, you would need to add an additional rule allowing DNS zone transfers (TCP/53) between the ISP's name server and the DMZ name server.
HTTP (TCP/80), and HTTPS (TCP/443) if necessary, access from anywhere to the DMZ Web server will be allowed. To enable HTTP/HTTPS access from the internal network, this rule must be before the allow-outbound-to-everywhere-but-the-DMZ rule.
SMTP (TCP/25) access from anywhere to the DMZ mail server will be allowed. To enable SMTP access from the internal mail server, this rule must also be before the allow-outbound-to-everywhere-but-the-DMZ rule.
Drop DMZ-Initiated Traffic
The servers on the DMZ should never initiate a connection to the internal network. If this occurs, there is a good chance that one of your servers has been compromised. The rule that governs this activity should deny and log the occurrence. If you have the ability to trigger an alert, that certainly is timely and valuable information to have.
Additional Rules
If you want to block additional services, such as ICQ or AOL's Instant Messenger, rather than block the ports, block the destination hosts. AIM can use Telnet, HTTP, SMTP, or HTTP Proxies to access the AIM servers:
Block all TCP traffic to login.oscar.aol.com
Block all TCP traffic to toc.oscar.aol.com
Change Management
Comments in a comments field or in the firewall startup script are necessary forms of documentation that allows organizations to better manage and maintain the integrity of their firewall rulebases. The following information, at a minimum, should be logged with a rulebase change:
Name of admin modifying the rule
Date/time change implemented
Reason for the rule change
Be sure to log your changes; this advice can't be stressed enough. You will appreciate it when there are problems, which there will be. Even better, have your firewall rulebase or script under revision control. This could be something as simple as a backup copy of the file with the date in the filename to Revision Control System (RCS)- or Source Code Control System (SCCS)-enabled archives.
Harden All Your Servers
Hardening is about minimizing risk and increasing robustness. Hardening refers to the process of disabling unnecessary services, ensuring that all security patches have been applied, and paying careful attention to file system permissions. Hardening a server that is Internet accessible includes, but is not necessarily limited to, the following tasks:
Reducing the number of network services that are running and accessible to the Internet.
Removing unnecessary software and features, which reduces the overall complexity of the system. This includes removing additional protocols such as IPX, AppleTalk, NetBIOS, DLC, LAT, and DecNET.
Removing software that allows access to internal system information, such as SNMP.
Removing insecure remote control software, such as X Window or the ADMIN$ share for remote Windows NT administration.
Applying all known security updates and service packs. Oftentimes, security exploits in necessary software, such as DNS, are resolved in a simple configuration change or security patch.
Enabling traffic filters, if available. Windows NT and most UNIX systems have built-in or freely available software that allows more control of the kinds and sources of IP traffic that are accepted.
Removing unnecessary accounts on the system. Rename existing administrative or root accounts to something unique and hard to guess.
Removing unnecessary and overly generous file permissions for both accounts and the file system.
The details of such tasks are operating system-specific, not only to vendor, but also to version. An overall guide to hardening several flavors of operating systems can be found at the following URL: http://advice.networkice.com/Advice/OS/default.htm
Microsoft Windows NT and 2000 operating systems have a well-known source of information to help you harden your servers. Although these documents are IIS-specific, many of the steps to harden your server that do not include IIS are extremely useful. Visit http://www.microsoft.com/technet/security/iischk.asp for Windows NT 4.0 information, and visit http://www.microsoft.com/technet/security/iis5chk.asp for Windows 2000 information.
Drop Source Routed Traffic
Normally, an IP packet leaves the client with only the source and destination addresses. All routing decisions are made by routers on the way. There is an IP option that allows you to specify what routes to take, which are specified from the sending machine. Thus, it is source routed rather than router routed.
You might ask yourself why the sending node would want to specify routing information rather than let the network routers make those decisions. Well, it's useful for performing network diagnostics. Traceroute can be used to specify source-routed traffic, and traceroute is useful. Unfortunately, source-routed traffic can also be used to override packet filter routers and firewall rulebases.
There are actually two forms of source-routed traffic: Strict Source Routed and Loose Source Routed. The differences aren't that important, because all source-routed traffic needs to be dropped. Dropping source-routed traffic should be done on the edge routers and any capable security gateways.
Drop Directed Broadcast Traffic
IP networks normally have two reserved IP addresses: the network address, which is the host portion of the IP address filled with all zeros; and the broadcast address, which is the host portion of the IP address filled with all ones.
If an ICMP echo reply, easily generated by a ping, is sent to either the network or broadcast address, each node on that network would respond. This originally was used to determine the status of network nodes; however, more recently, this is used to create denial of service attacks.
A simple denial of service attack is to send an ICMP echo request to the broadcast address of a network of hosts with a spoofed address. All the hosts on that subnet respond with an echo reply to the spoofed address. Each ping is multiplied by the number of hosts on the subnet, which generates instant traffic.
Now, imagine a user on a 56Kbps dial-up modem sending spoofed ICMP echo requests to a subnet of 100 hosts. Those 100 hosts generate 100 ICMP echo replies that are sent to the IP address in the spoofed packets. That is 53Kbps x 100, or 5,300Kbps. That is three times the size of a T1, all generated from a dial-up user.
This type of attack and others like it can be defeated by disabling directed broadcasts on the edge routers and servers exposed to the Internet. Further information can be found in RFC 2267, Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing.
Lock Down Your DNS Servers
DNS servers are often the focus of root-compromise exploits. To reduce the probability that you will be a target, there are some simple configuration options to consider for your DNS server:
Run the newest stable release of the name server. All prior versions of both BIND and Microsoft's DNS server have vulnerabilities. If you are using the Internet Software Consortium's version of BIND, which is used on almost every installation of UNIX, make sure that you are using 8.2.2pl5 or newer. For Microsoft Windows NT, make sure that your DNS server is running at least Service Pack 4. Service Pack 6a is now available.
Restrict zone transfers to known secondary servers. This reduces additional information that can be gathered by potential intruders. The important thing to keep in mind here is to not allow zone transfers from the secondary servers. There is no point locking down the primary servers if the intruders can just do a zone transfer from a secondary server.
Do not use dynamic updates on external DNS servers. None of your Internet-accessible servers should be using dynamic IP addresses. Therefore, there is no need for dynamic updates. It should be obvious why it is a security risk to allow intruders to send dynamic updates to your DNS server.
If possible, restrict the queries that the DNS server will do recursive queries for. There is no reason why your DNS servers should do recursive DNS queries for anyone other than your internal network hosts. Create an access control list (ACL) to restrict queries to internal hosts.
Disable Relaying and Other Information Features on Your SMTP Server
As previously discussed, it is bad netiquette to allow email relaying through your mail server. Many mail servers have built-in support to reject email coming from sites in the Mail Abuse Prevention System (MAPS) Realtime Blackhole List (RBL) or similar lists. To prevent abuse of your mail server and other people's resources, block mail relaying and spam.