Filtering of ports and system service calls on a single computer operating system

Packet-filtering firewalls

Packet-filtering firewalls provide a way to filter IP addresses by either of two basic methods:

Allowing access to known IP addresses

Denying access to IP addresses and ports

By allowing access to known IP addresses, for example, you could allow access only to recognized, established IP addresses, or, you could deny access to all unknown or unrecognized IP addresses.

By denying access to IP addresses or ports, for example, you could deny access to port 80 to outsiders. Since most HTTP servers run on port 80, this would in effect block off all outside access to the HTTP server.

According to a report by CERT, it is most beneficial to utilize packet filtering techniques to permit only approved and known network traffic to the utmost degree possible. The use of packet filtering can be a very cost-effective means to add traffic control to an already existing router infrastructure.

IP packet filtering is accomplished by all firewalls in some fashion. This is normally done through a packet-filtering router. The router will filter or screen packets traveling through the router's interfaces that are operating under the firewall policy established by the enterprise. A packet is a piece of information that is being transmitted over the network. The packet filtering router will examine the path the packet is taking and the type of information contained in the packet. If the packet passes the firewall policy's tests, it is permitted to continue on its path. The information the packet filtering router looks for includes (1) the packet source IP address and source TCP/UDP port, and (2) the destination IP address and destination TCP/UDP port of the packet.

Some packet-filtering firewalls will only be able to filter IP addresses and not the source TCP/UDP port, but having TCP or UDP filtering as a feature can provide much greater maneuverability, since traffic can be restricted for all incoming connections except those selected by the enterprise.

Packet-filtering firewalls are generally run on either general purpose computers that act as routers or on special-purpose routers. Both have their advantages and disadvantages. The main advantage of the general purpose computer is that it offers unlimited functional extensibility, whereas the disadvantages are average performance, a limited number of interfaces, and operating system weaknesses. The advantages of the special-purpose router are the greater number of interfaces and increased performance, whereas the disadvantages are reduced functional extensibility and higher memory requirements.

Although packet-filtering firewalls are less expensive than other types, and vendors are improving their offerings, they are considered less desirable in maintainability and configurability. They are useful for bandwidth control and limitation but are lacking in other features such as logging capabilities. If the firewall policy does not restrict certain types of packets, the packets may go unnoticed until an incident occurs. Enterprises utilizing packet-filtering firewalls should look for devices that can provide detailed logging, a simplified setup, and firewall policy checking.

Proxy-server or application gateway

Proxy servers, also known as application proxy or application gateway, use the same method as a packet filter in that they examine where the packet is being routed and the type of information contained in the packet. The application proxy, however, does not simply let the packet continue to its destination; it delivers the packet for you.

An application-proxy firewall is a server program that understands the type of information being transmitted—for example, HTTP or FTP. It functions at a higher level in the protocol stack than do packet-filtering firewalls, thus providing more opportunities for the monitoring and control of accessibility. In dispatching messages from internal clients to the external world, an application gateway acts much like a distributor and modifies the source identification of the client packets. This accomplishes two purposes: First, it disguises the internal client to the rest of the Internet, and second, it acts as a proxy agent for the client on the Internet.

By hiding the address of all internal computers, the risk of hackers gathering information about an enterprise's internal data is lessened. In the past, the use of proxy-type servers has resulted in reduced performance and transparency of access to other networks. Newer models, however, have addressed some of these issues.

Application gateways have addressed some of the weaknesses associated with packet-filtering devices in regard to applications that forward and filter connections for services such as Telnet and FTP. Application gateways and packet-filtering devices do not have to be used independently, however. Using application-gateway firewalls and packet-filtering devices in conjunction can provide higher levels of security and flexibility than using either of the two alone. An example for this would be a web site that uses a packet-filtering firewall to block out all incoming Telnet and FTP connections and routs them to an application gateway. Through the use of an application gateway, the source IP address of incoming Telnet and FTP packets can be authenticated and logged, and if the information contained in the packets passes the application gateway's acceptance criteria, a proxy is created and a connection is allowed between the gateway and the selected internal host. The application gateway will allow through only those connections for which a proxy has been created. This form of firewall system allows only those services that are considered trustworthy of passing through to the enterprise's internal systems and prevents mistrusted services from passing through without the monitoring and control of the firewall system administrators.

The advantages offered by application gateways are numerous. By hiding the source IP address of a client to external systems, additional protection is provided from the prying eyes of hackers intent on extracting information from your internal systems. The use of logging and authentication features serves to identify and authorize external services attempting to enter your internal network. Unwanted and unwelcomed guests can be recognized and kept out. This is also a very cost-effective approach, as any third-party devices for authenticating and logging only need to be located at the application gateway. Application gateways also permit the use of simpler filtering rules. Instead of having to route application traffic to several different systems, it only need be routed to the application gateway; all other traffic can be rejected.

Many types of application gateways also support e-mail and other services in addition to Telnet and FTP. Since application gateways route many forms of application traffic, they enable security policies that are based not only on source and destination IP addresses and services, but the actual data contained in the application packets can be evaluated as well.

In the case of an application gateway that is gathering and routing e-mail among an Intranet, the Extranet and Internet would view all internal users under a form based on the name of the e-mail application gateway—for example, [email protected] The e-mail application gateway will route mail from the Extranet or Internet throughout the internal network. Internal users can send mail externally either directly from their hosts or via the e-mail application gateway that directs the mail to the destination host. Application gateways can also monitor and weed out e-mail packets containing viruses and other unwanted forms of commercial e-mail from penetrating through to the internal areas of your business.

As in the case of packet-filtering firewalls, application gateways are generally run on either general purpose computers that act as routers or on special-purpose proxy servers.

Packet-filtering devices are by and large faster performers than application gateways but characteristically lack the security offered by most proxy services.

Given the additional complexity of application gateways over packet-filtering firewalls, the additional computing resources and cost of supporting such a system should be considered when you are assessing the firewall needs for your enterprise. As an example, depending on your requirements, the host may have to support hundreds to thousands of proxy processes for all of the concurrent sessions in use on your network. As with most business decisions, the greater the performance demanded, the higher the costs that will be incurred for attaining that added performance.

Circuit-level gateways

A circuit-level gateway is similar to an application gateway, except that it does not need to understand the type of information being transmitted. For example, SOCKS servers can act as circuit-level gateways. “SOCKS” is a protocol that a server utilizes to accept requests from a client in an internal network so that it can dispatch them across the Internet. SOCKS uses sockets to monitor individual connections.

Circuit-level gateways perform the stateful inspection or dynamic packet filtering for making filtering decisions. Although circuit-level gateways are sometimes grouped with application gateways, they belong in a separate category since they perform no extra evaluation of data in a packet beyond making the approved connections between the outside world and the internal network.

The stateful inspection is a circuit-level gateway function that allows for more robust screening than that offered by packet-filtering devices, in that both packet content and prior packet history are used to establish filtering decisions. This inspection is an “add-on” function, so the circuit-level gateway device also serves as a router.

This add-on functionality provides increased performance over application proxies by compromising between performance and security criteria.

Circuit-level gateways, then, offer increased security monitoring capabilities over packet-filtering firewalls, but still rely on a well-laid-out core routing structure, and, like application proxies, can be set up to specify advanced accessibility decision making.

Per-rule HTTP Filtering

ISA Server 2004's HTTP policy allows the firewall to perform deep HTTP stateful inspection (application layer filtering). You can configure the extent of the inspection on a per-rule basis. This means that you can configure custom constraints for HTTP inbound and outbound access. With ISA Server 2000, HTTP filtering had to be performed globally, using a version of URLscan installed with Feature Pack 1 for ISA Server 2000.

Ability to Block Access to All Executables

You can configure ISA Server 2004's HTTP policy to block all connection attempts to Windows executable content, regardless of the file extension used on the resource. This blocks all responses in which the first word of the downloaded binary is MZ. You can also block by file extension (see the next subsection).

WARNING

Blocking all Windows executables does not necessarily block all file types that can be dangerous. For example, .pif and .com files are not blocked by this filter because the first two bytes of the binaries are not MZ. You can block these other potentially dangerous file types by configuring filters to block by file extension.

NOTE

The first two bytes of the file contain its file signature. The MZ file signature, originally used for MS-DOS executable files, stands for the name of Microsoft programmer Mark Zbikowski.

Ability to Control HTTP Downloads by File Extension

ISA Server 2004's HTTP policy makes it easy for you to allow all files extensions, allow all except a specifiedgroup of extensions, or block all extensions except for a specifiedgroup. This gives you a lot of flexibility in controlling what types of files can be downloaded by users, especially since this is done on a per-rule basis. This means you can apply the blocking of certain extensions to specific users orgroups.

Application of HTTP Filtering to All Client Connections

ISA Server 2000 was able to block content for Web Proxy clients based on HTTP and FTP connections by MIME type (for HTTP) or file extension (for FTP). With ISA Server 2004's HTTP policy, you can control HTTP access for all ISA Server 2004 client connections, regardless of client type. There was no deep inspection of outbound connections, out of the box, with ISA Server 2000.

Control of HTTP Access Based on Signatures

ISA Server 2004's deep HTTP inspection also allows you to create “HTTP Signatures” that can be compared to the Request URL, Request headers, Request body, Response headers, and Response body. This allows you to exercise extremely precise control over the content that internal and external users can access through the ISA Server 2004 firewall.

A signature is a character string for which ISA Server will search the request body, request header, response body, and/or response header. If the string is found, the data will be blocked. You can search for either a text or binary string. Blocking based on text signatures can only be done if the HTTP requests and responses are UTF-8 encoded.

Control Over Allowed HTTP Methods

You can control which HTTP methods are to be allowed through the firewall by setting access controls on user access to various methods. For example, you can limit the HTTP POST method to prevent users from sending data to Web sites using the HTTP POST method. You can select to allow all methods, allowed selected methods, or block specified methods and allow all others.

NOTE

HTTP methods are commands that tell the server what action to perform on a given request. They are also sometimes referred to as “HTTP verbs” because they consist of action words: GET (retrieve the data identified by the URI), PUT (store the data under the URL), POST (create an object linked to the specified object), and so on.

Ability to Force Secure Exchange RPC Connections

ISA Server 2004's Secure Exchange Server Publishing Rules allow remote users to connect to the Exchange server by using the fully functional Outlook MAPI client over the Internet. However, the Outlook client must be configured to use secure RPC so that the connection will be encrypted. ISA Server 2004's RPC policy allows you to block all non-encrypted Outlook MAPI client connections.

With traditional firewalls, you have to open a number of ports to enable remote access to Exchange RPC services with the Outlook MAPI client, creating a security risk. With ISA Server 2004, the RPC filter solves this problem.

Policy-based Control Over FTP

You can configure ISA Server 2004's FTP policy to allow users to upload and download via FTP, or you can limit user FTP access to download only. This gives you more control over FTP activity and moregranular security. By selecting Read Only on the Protocols tab when you configure FTP filtering, you block FTP uploads.

The FTP access filter is more functional than a user-defined FTP protocol because it dynamically opens specified ports for the secondary connection and can perform the address translation that is required by the secondary connection. The filter is also able to differentiate between read and write permissions, so you cangranularly control access.

Link Translation

Some of your published Web sites might include references to the NetBIOS names of computers. Only the ISA Server 2004 firewall and external namespace, and not the internal network namespace, is available to external clients. That means when external clients try to access the sites via these links, these references will appear to be broken links.

ISA Server 2004 includes a link translation feature, which allows you to create a dictionary of definitions for internal computer names that map to publicly-known names. This is especially useful, for example, when publishing SharePoint Web sites. The link translation directory can also translate requests that are made to ports other than the standard ports, and the link translator will include the port number when it sends the URL back to the client.

NOTE

Although link translation was not available as a feature of ISA Server 2000 out of the box, it can be added to ISA 2000 by installing Feature Pack 1.

TIP

By default, link translation only works with HTML documents, but you can add other content groups if you wish.

WARNING

If your document contains internal links that have not been mapped to their appropriate external links in the link translation dictionary, the internal NetBIOS names will be exposed to external users. This can pose a security risk because it allows outsiders to know what the internal computer names are.