Assessing Your Security Needs

Service Assessment

Depending on your paranoia level and the ignorance level of your upper management, you will take different stances on what your users will be able to access. Many IT managers take the stance that their internal users have the freedom to access any service available on the Internet. This certainly simplifies your security policy, and will reduce the amount of future modifications necessary to support the newest whiz-bang, business-critical service offered by Datek Online and ESPN.

It will also be very likely that your users will grumble about your firewall. The desire to access all their sensitive data from any computer on the Internet with little or no hassle might conflict with your desire to keep it safe from intruders. Sometimes, a firm hand is necessary.

Many organizations will take a more restrictive approach. The userbase will have access to only basic services such as HTTP/HTTPS, FTP, and email on standard well-known ports. Additional services, such as DNS, which are necessary to support these protocols are also permitted. Many organizations do not see the value of Napster, Gnutella, Telnet, AOL Instant Messenger, Real Media, and Java streaming stock tickers. By allowing specific services and denying everything else, you can increase your security, increase your available bandwidth by eliminating non-business related traffic, increase your administrative load, and frustrate your users in a single policy decision.

Allowing your users unrestricted access to Internet services is the easiest stance to take, and because it simplifies the security policy, it will be used as the basis for the first example. Allowing specific services and denying everything else will be illustrated in packet filter routers. You should be able to easily see how quickly the complexity of security policies increases.

Which method is right for your organization? That is something you will need to decide with management and your organizational policies and procedures. Most academic and research-related organizations will opt for the more open and simpler security policy. Most businesses, especially those in the financial districts, will opt for the more controlling security policy.

Serving the World

Deciding which services to offer the world will be easy. Whatever the objectives are, connecting your organization to the Internet will almost directly dictate what your security policies will be. If you are hosting DNS and email, those are the services to allow in through your security gateways. DNS and email are pretty much considered mandatory. Additional services you might be offering include Web, News, and FTP.

If you are allowing Web traffic generated dynamically from a database, you will allow the Web traffic through, but not open access to your database ports. Common sense reigns securely here. Things get more complex if you are serving streaming media or networked Java applications that must open network ports back to your servers. Most streaming media servers, such as Real Network's Real Server and Apple's QuickTime Streaming Server provide tech documents specifically for supporting streaming media through firewalls. There might be instances when those servers cannot sit behind a firewall and might need to be on the unprotected side of the DMZ. In those instances, your only protection is to harden the box, as discussed later.

The only other major service you might be offering to the world at large is Virtual Private Network (VPN) access to your internal network for traveling users, remote office locations, telecommuters, or business partners. By allowing VPN into your network, you reduce or eliminate the costs associated with dedicated leased lines between locations. You can also eliminate analog modem or digital ISDN-based dial-up remote access servers.

Many users will lean toward implementing Microsoft's Point-to-Point Tunneling Protocol (PPTP) because it is already built into all modern Microsoft operating systems, and does not add additional expense. However, you shouldn't use PPTP, not because the recent revision of the specification has any inherent problems, but rather Microsoft's implementation is not secure. Look into an IPSec-based VPN. IPSec is an industry standard authentication and encryption protocol suite. IPSec implementations are available for cross-platform solutions for Microsoft Windows operating systems, Mac OS, and most UNIXes. Recent operating system releases of Windows 2000, Solaris 8, OpenBSD, FreeBSD, and some Linux distributions (SuSe to name one) include native IPSec support.

IPSec is a large and complex suite of protocols. There are three primary components of IPSec that you are most likely to encounter when deploying IPSec based VPNs: IKE, ESP, and AH.

IKE, or Internet Key Exchange protocol, is responsible for setting up IPSec ESP and AH connections. Automated key exchange between two parties is an extremely complex procedure. There are myriad parameters necessary to establish identity, encryption algorithms, keys, and connection lifetimes. And although the Tao of security is simplicity, many parts of IPSec seem to fly in the face of that philosophy. This explains why many vendors do not implement all options of the IPSec protocol suite, to reduce the complexity of their products and the chance that you might misconfigure it. IKE, defined in RFC 2409, combines the following protocols:

• ISAKMP, or the Internet Security Association and Key Management Protocol (RFC 2408)—ISAKMP is often used interchangeably with IKE by vendors.

• IPSec DOI for ISAKMP, the IPSec Domain of Interpretation for ISAKMP, RFC 2407—IKE was developed over years of constant arguing in the IETF working groups. IPSec DOI for ISAKMP endeavors to fill in the details that are missing from the ISAKMP specification.

• Oakley key determination protocol (RFC 2412) uses the Diffie-Hellman protocol to create keys for IPSec Security Associations (SAs).

IPSec AH is the Authentication Header, as defined in RFC 2402. IPSec AH is IP protocol 51 and is neither TCP or UDP, thus there are no ports associated with AH. The job of AH is to authenticate the IP packet so that you can ensure the integrity of the packet has not been compromised between security gateways. The authentication data is actually generated by using a 96-bit Message Digest Algorithm (MD5) or Secure Hash Algorithm (SHA) over the payload and immutable IP header information. The IP Time To Live (TTL) field is decremented for each router hop, and thus is not authenticated. For most implementations of IPSec, AH is not necessary, and it is unlikely that you will use it when deploying a VPN. The one large exception to this is IPv6. IPv6 implementations are required to include IPSec AH and ESP.

IPSec ESP is the Encapsulated Security Payload, as defined in RFC 2406. ESP includes both data privacy in the form of encryption, and data integrity in the form of authentication. Like AH, ESP is IP protocol 50, is neither TCP or UDP, and therefore has no concept of ports. ESP can be combined with AH, if so desired, for additional authentication. However, because simplicity is key for security, there is normally no need to make things more complex than necessary. Currently in the real world if you are using different vendor's implementations of IPSec, the more options you use, the more likely there might be an interoperability problem with the configuration.

ESP has the option to choose from many encryption algorithms, including none (Null encryption), DES, and 3DES. There is little use in using ESP with both Null and DES encryption algorithms. Both are insecure when trying to hide data, and even worse, DES gives the illusion of being safe. 3DES is the de facto standard for IPSec secure interoperability between different vendor implementations. When an AES candidate is selected, most vendors will implement the winning algorithm.

Services Allowed from the Internet

As previously discussed, you have a choice of allowing generally unrestricted access to services from the Internet or to identify those services your users need and allow those only.

If you decide to allow unrestricted access, you can still block certain services by blocking the servers they rely on. A perfect example of this is AOL Instant Messenger. By dropping all traffic destined for the AOL Instant Messenger servers, you effectively disable that service. Because of their multiple numbers of database servers, services such as Napster and Gnutella, unfortunately, cannot be stopped by packet filtering or even dropping traffic to all the catalog servers *.napster.com. The only way to truly stop Napster-type traffic is with content-inspection type of firewalls/proxies. Examples of such content-inspection systems are the new 3.5.x version of IP Filter (not yet available at publication time), and a commercial package called PacketHound by Palisade Systems, Inc. Commercial Firewalls are likely to get content-inspection plugins as well.

If you are providing specific services and denying all others, be prepared to revisit and modify your rulebase often. It is inevitable that someone will rise from the ranks of userland with a business-critical service he needs to access, most likely at 4:30 p.m. on the Friday before a long weekend. Those services might be one-offs, such as "I need SQL*net access to this vendor's public database;" or vague and all-encompassing, such as "The new SOAP application using BXXP as the transport protocol isn't working. Can you find out why?"

The point here is to be careful about where and when you add rules to allow services. A misplaced or misconfigured rule can render useless the rules that follow it.

With all the warnings out of the way, be prepared to do some footwork and tweaking of the rulebase to support the services you want to enable for your users. Make a list of the supported services you want your users to access from the Internet (see Table 1). Additionally, poll the users and managers in the various departments to gather application requirements.

Table 1: Example Applications and the Protocol/Ports Used

Application	Service	Protocol	Port
World Wide Web	HTTP	TCP	80
Secure WWW	HTTPS	TCP	443
Electronic Mail	SMTP	TCP	25
	IMAP4	TCP	143
	POP3	TCP	110
Name Resolution	DNS	UDP	53
	DNS	TCP	53
File Transfer	FTP	TCP	20, 21
Terminal Emulation	TELNET	TCP	23
Encrypted Telnet	SSH	TCP	22
Usenet News	NNTP	TCP	119
Time Synchronization	NTP	TCP	123
Virtual Private Network	IPSec	ESP	N/A
	IPSec	AH	N/A
	IKE	UDP	500
Streaming Media	RTSP	TCP	554
	RTP	UDP	6970-7170

Identifying the Internet applications your users need will dictate your initial outbound security policy. Most Internet Application services have specific, well-known protocol and port definitions that allow the client software to connect to the servers providing those services. The problematic services are those that remote procedure call (RPC) and portmapping services.

Portmapped services attach themselves to a randomly available unprivileged port and then register with a port mapping service. Clients wanting to use those portmapped services first contact the portmap service and request the port of the service they are seeking. The client will then initiate a connection to the service running on the port, as returned by the portmapper. Examples are the Microsoft Exchange server message retrieval and address book services. Each start/stop of the service, including reboots, causes the services to usually bind to a different port. This makes portmapped services extremely difficult to securely support with packet filter routers and most firewalls.

Similar problems arise with distributed network-aware programming such as Java's Remote Method Invocation (RMI) and CORBA's Internet Inter-Orb-Protocol (IIOP).

Even if you are able to get your packet filter router or firewall to support such services, they will be passing over the Internet in the clear. This is not the wisest course for mission-critical distributed applications. The best method is to investigate encrypted tunneling of the RMI/IIOP calls (such as HTTPS), or to use a VPN.

The Special Case of FTP

TCP/IP and the related protocols provide the underpinnings of network services used on both local networks and the Internet. Among those services, FTP seemed much more complicated than the rest. FTP is the bane of many a network administrator's existence to properly support. FTP servers are often the focal point of automated script kiddie attacks. This is unfortunate because many FTP servers at one point or another have had root-compromise exploits. Offering secure, publicly available FTP servers requires a lot of effort on the part of the administrator. Many believe the designers of the FTP protocol must have been on the same hallucinogens that inspired the duck-billed platypus.

From a firewall/packet-filtering perspective, there are two major problems with FTP. Those problems are, of course, different depending on whether you are supporting outgoing client connections or incoming server connections.

For Outbound Client Connections

The problem for outbound client connections is that there are two types of FTP transfer modes, active and passive. Remember that for Active FTP, the PORT command causes the FTP server to initiate a data connection back to the client on port 20. In Passive FTP, the PASV command causes the FTP server to reply with an available port for the client to open a connection to. The passive server-supplied available port is unprivileged, meaning that it is always greater than 1,023, but less than 65,536.

That is a very large range to open up for TCP connections to any FTP server. To support passive FTP using a packet filter router or firewall without state table support, you must essentially allow any unprivileged TCP traffic out of your network. This is almost certainly not what you want.

You can avoid this problem by only supporting Active FTP sessions to the outside world. The main problem with this is that most FTP transfers are now done with Web browsers as the clients. Most Web-browsing clients today default to passive FTP, so this might confuse your users when FTP doesn't work through their Web browsers.

A better way of handling this is to set up an internal proxy. By setting up an internal proxy, all clients establish connections to the proxy first, and the proxy opens the FTP connection on behalf of the client. That way, you can support passive FTP; just restrict the permit rule to the IP address of the proxy server. Microsoft's Proxy Server and Squid (found at http://squid-cache.org) are two popular proxy products.

The downside to this is that all the clients must be configured to use the proxy. Client configuration can be mitigated by server-side and automatic proxy configuration. Recent versions of Internet Explorer and Netscape Communicator both support automatic proxy configuration, either through scripts, or DNS tricks.

The best way to handle FTP is to not rely on packet filter on a router, but to use a firewall that has FTP support.

For Inbound Server Connections

The same support conundrum exists for offering the service of an inbound FTP server, except, of course, that to make things easier the problem is exactly opposite that of supporting the outbound client.

Handling the Active FTP transfer mode for an inbound FTP server is significantly easier than supporting passive FTP sessions. Inbound connections go to port 21 of your FTP server, and you must only permit port 20 traffic back out from your FTP server.

Passive FTP transfers are more difficult because the client will be initiating a connection to an unprivileged TCP port on your FTP server. On most packet-filtering routers and firewalls without specific passive FTP state table support, you have no other option than to allow any unprivileged TCP traffic to your FTP server. This will open your server up to additional attacks, and is generally not the best approach.

A better but still inefficient workaround is to configure your FTP server to use a predetermined range of ports to assign for passive FTP transfers. Using a known small window of PASV ports, you can shrink the packet filter/firewall range of open port addresses from 1,024–65,535 to say 15,000–15,500.