Endpoint Protection

by Phil Kostenbader, CISSP, and Bob Donnelly, CISM, CISSP

The idea of a common desktop firewall policy in any size organization is a very good thing. It makes responses to external or internal situations such as virus outbreaks or network-oriented propagation of viruses more predictable. In addition to providing a level of protection against port scanning, attacks or software vulnerabilities, it can provide the organizations local security team a baseline or starting point in dealing with such events.

The purpose of this article is to discuss the need for a desktop firewall policy within an organization, determine how it should be formed, and provide an example of one along with the security benefits it provides an organization.

The Problem

The trick to a good desktop firewall policy is to provide a balance between security and the networking requirements of the applications needed by the organization. It's possible the organization may not yet have a complete knowledge of these requirements. This should make the first attempt to define a standard/global policy interesting, depending on the level of protection one is trying to provide and the situation or environment the desktops may be in.

One thought on an initial policy is to provide a port-based firewall with all inbound ports blocked on the desktop. On the other hand, an old school of thought might involve one blocking only the ports that need to be blocked, by estimating software network requirements and then combining this with an effort to also block the most obvious of possible vulnerabilities or services. Evaluating FTP, Windows IIS or NetBIOS requirements might provide a first pass at a standard global policy. Our old school of thought again would leave the balance tipped toward the (as yet unknown) network requirements of the software, and less toward protection. In other words, offer functionality over security. While providing consistency, cases where the desktop (or laptop) is located off site may not fully satisfy security requirements of the organization.

Location awareness may be a feature of the desktop firewall that one could use to design a policy that changes to better fit a user's location. Some personal firewall solutions provide location awareness as a feature. Location selection could be automatically selected depending on a successful Windows domain login, specific IP address, DNS server address, network adaptor type, or it could be based on the client firewall's ability to connect to a policy manager.

If location awareness is not a built-in feature of the firewall, the policy could be designed around the organization's internal IP address range or, if available, be configured around the DNS domain name. For example:

Issues with a "block all" inbound policy

A block all inbound policy while connected offsite would seem to present the least amount of risk, but might not be completely possible while onsite. The first issue may be caused by the firewall itself. Depending on the vendor, characteristics of the firewall may impact application functionality while using a block all inbound policy. This may include UDP, complex protocols like FTP, NFS, applications running in a service mode, and problems with a Intrusion Prevention System if one is provided with the firewall. Each of these issues will be discussed below.

UDP, being a stateless protocol, is difficult for any firewall to handle. A simple UDP based service may run on port 1313, or example. The UDP client (running the desktop firewall) would attempt to connect to 1313, and assign a port for a reply. There may or may not be a reply; if there is, it won't be easy for the firewall to determine whether or not to allow it. Either the firewall needs to attempt to keep state of all outbound UDP traffic on its own, or UDP port requirements must be known and the firewall must be configured to allow the reply on a case-by-case basis.

An example of a facility requiring UDP might be printer or scanner client that issues a UDP broadcast and then awaits a reply. That reply would come from a scanner or printer the user may want to access, and it might include its status or availability.

FTP could cause another possible issue with the firewall. In some cases the firewall may not support active FTP, which is unusual as Microsoft Windows doesn't support passive mode. Active FTP is where the ftp server will initiate a connection back to the client to do the actual transfer of data. Oddly, FTP is still used and sometimes even embedded within other software. Fixes for active FTP on firewalls can be ugly and may end up being one of the first application-based rules.

Applications running in a service mode can have one of two solutions: either the firewall requires an application-based rule where the application's network access is restricted to predefined ports, or one can simply allow the open port, possibly with some other restricting criteria. Restrictions by IP address or time of day are possible as well, and may be desired.

An Intrusion Prevention System may be an additional feature of a desktop firewall within an enterprise. This would allow the firewall to detect possible attacks by examining the inbound packet and matching data and port usage against a list of known attack signatures. The IPS may be configured to respond by blocking the inbound packet or allowing it and sending an alert. False positives on a firewall supporting IPS could mistakenly block inbound traffic and would need to be analyzed and adjusted on case-by-case basis. Logging the event and allowing the traffic may be the quickest and easiest way to deal with false positives.

The Environment

In this part of the article, we detail what is needed to create an environment where software requirements are known and our corporate standards are enforced:

1. a desktop firewall This is the tool used to enforce restrictions on network access by limiting port and protocol access. The firewall should limit the user's ability to change its configuration, yet provide enough function such that the user can identify issues that may be caused by the firewall policy. The firewall should support port- and application-based filtering.
2. A security policy This will define what is or is not permitted to or from the network, on a standard desktop. Typically this would be generated by a high-ranking security group or set of officials in the organization, and would be generalized into a non-technical document (it could be as simple as block all inbound rule).
3. Knowledge of existing port requirements or a baseline of requirements These would be taken standard or default desktop operating system configuration used in the organization. Typically an organization would have an install tailored to its own requirements, and it may include patches, anti-virus, and common software required by all users. This, combined with the security policy, would form the basic desktop firewall policy.
4. Ability to deploy a single global firewall solution to all desktops This means deploying the solution to all desktops in the organization with a consistent or single policy. Enforcement and tracking of deployment would also be necessary.
5. Facility to provide and update the firewall policy Some firewalls can be centrally managed directly. Depending on the needs or structure of the organization, the minimum requirements would require a common/global firewall policy that can be updated, for example through the replacement of a configuration file. Obviously some form of central software management would need to be in place.
6. Large plastic bat to handle upset users
7. Tools to aid in the analysis of the networking requirements For example, this might include Ethereal for monitoring traffic, the ability to analyze firewall logs, Perl scripts to test firewall rules, Nmap for port scanning, and so on.

"Software Networking Standards" – A potential benefit

If the organization knows the networking requirements of its applications, a policy could easily be created. Then the idea of software networking standards could be enforced through the policy.

An example

In order to provide a firewall policy for the examples below, let's first assume that a policy is designed and configured to block all inbound TCP/UDP, and allow all outbound TCP/UDP. We will also assume the firewall does not properly handle outbound UDP or complex protocols such as FTP. Some known software requirements in this environment may be obvious, for example support the organization permits file sharing. This would require inbound TCP port 445 open . A rule is created to support inbound 445 and also restrict the rule to a range of IP address (192.168.4.0 through 192.168.20.255 in this example, with the understanding that this private IP address range could be used by other organizations such as hotels as well, creating a potential hole for traveling users). Finally, ICMP is allowed for troubleshooting. A sample policy might thus be configured to:

• Allow all inbound and outbound ICMP
• Allow inbound TCP 445 from hosts 192.168.4.0 – 192.168.20.255
• Block all inbound TCP
• Block all inbound UDP
• Allow all outbound TCP
• Allow all outbound UDP

Let's now look at the benefits of using our sample policy.

Benefits of a desktop firewall policy

• The ability to predict the impact of security-related events is enhanced. An event could have many characteristics and take on many different forms. If some of those characteristics involve network port access, the policy may offer an initial form of protection. In addition, network-oriented responses to these events become more predictable. For example, the application of router and network firewall ACLs are sometimes used to deter the propagation of virus and worms. The problem is, the implementation of ACLs could impact production software, in cases where both applications and a security event have similar port requirements. Depending on the characteristics of the event, the example policy may make ACLs unnecessary on some network segments.

   

• Provide consistent software solutions (as opposed to multiple solutions that provide the same function). Two departments requiring a similar service may deploy two different software solutions. While it is best that departments in any organization coordinate development and deployment in software solutions, the reality is, this doesn't always happen. The policy defined above offers some hurdles for new applications. If the policy happens to conflict with the network requirements of the application a request for a policy enhancement would be required. At this point, if not already, the application becomes known to the organization.

   

• Restrict the ability for network-oriented programs from hitting the desktop until evaluated. Again, the policy may offer some new hurdles for applications, depending on their requirements. A recent example could be Microsoft's Activesync 4.0 software. The example policy above would require modifications, which could carry the concept of being loose or tight. (Visit Microsoft's Activesync page for the requirements.) The policy impacts the application in several areas: inbound port requirements, backend network construction, and these involve the use UDP along with TCP. A modification of the policy may include a fairly tight rule that binds the local ports to the application for the backend network only, such as:

   

  • allow 169.254.2.1 inbound access to the { required ports } AND { executables }

  Analysis of the application through the use of Nmap can verify the port requirements on the backend network, but also reveals activity on the primary network. In this case a ‘status' port that is TCP 999 becomes active on the primary network when the handheld that uses Activesync is cradled. In theory one could execute a single port scan against port 999 on a subnet and identify all IP address which currently are ‘syncing' a handheld. Depending on the firewall internals and given the policy defined, Nmap may indicate ‘closed' for port 999. Some firewalls can be configured to drop an inbound packet for a port that is blocked, which would return nothing in this case.

   

• Restrict the use of service-oriented software. Individuals involved or concerned with security have to be interested and even frustrated with this. Software running on an ordinary desktop (as opposed to a ‘server') that requires a port used for listening could be susceptible to coding errors allowing inbound access or backdoors. They should be avoided.

   

• Software using unusual protocols will become known (such as systems using the streaming protocol IGMP). While the use of protocols other than IP isn't itselft an issue, it's an advantage to know they are in use. Some firewalls will not pass these protocols, and isolation of their use could be difficult. It's now common for the software provider or vendor to make their networking requirements available for organizations supporting a desktop firewall.

   

• Track the use of broadcast-oriented software which usually runs as UDP. The example policy in this article would disable the response to a UDP broadcast. A good standard for any organization is to define service-oriented equipment, such as printers and scanners, using static IP addresses, and make the user aware of the names and IP addresses of these facilities that are in their area. The security issue in this case is that the service could be spoofed. A phony print server could be created to capture and forward printouts to the actual server.

   

• Track the use of backend networks or dual-homed machines. The example policy may reveal a backend, depending on what it is being used for. The use of backend networks won't directly cause security concerns, but their existence and use should be identified. For example, asset and patch management could be impacted, and real vulnerability assessment would also not be possible.

   

• Software and desktop support can be impacted and simplified. The example policy offers some limitations on what software can do on the network. Software requiring modifications to the policy obviously becomes known, and the specific policy modifications would help create a consistent deployment.

   

• The example policy would help in the enforcement of the organization's security policies or detection of software which might break this policy. For example, it may be part of the security policy to prohibit the use of database, web, ftp or P2P servers on ordinary desktops. The policy in this example would block those services.

   

• A global policy could help enforce an organizations specific standards; such as the use of a remote access VPN or streaming media solution. The example policy would most likely require modifications to support VPN. Typically the software requirements of VPN would differ between vendors as well.

   

• The policy could be used to limit access to services running over non-standard ports. For example, assume that only minimum outbound internet access restrictions are in place and a policy and mechanism exists to monitor and log Internet web access. Typically web access is done using TCP port 80. However it is possible for a user to access an external anonymous web proxy (such as www.proxyblind.org; there are many others) that may run on a port other than 80. This usage would bypass logging and allow the user to surf the web anonymously. A modification to our example policy restricting iexplorer.exe to outbound TCP port 80 could be created. Limitations on other ports commonly used to support anonymous web proxies could also be created (for example, these are often found on TCP ports 3128, 8000 and 8080)

Summary

A common desktop firewall policy could lead to, or help in the enforcement of, software networking standards. If this is something an organization wants, there are clear benefits. Depending on whether the organization is running a firewall with a consistent policy or not, networking standards at some level may already be enforced. New applications may or may not be compatible with this policy, and changes or modifications would need to be requested. Those who deploy new software may need to be a bit more familiar with the network requirements of their software, to be able to adhere to policy.

The desktop firewall, typically just one piece of desktop security, often is combined with patch management, anti-virus and software deployment/management facilities to form a complete security solution. As part of that solution, the desktop firewall's job is to simply block network traffic and detect attacks. Yet the reality is, it can do more than this although added features may not be quite as tangible as the supplying desktop protection.

The implementation and maintenance of a desktop firewall can be a stressful and frustrating experience – particularly for those organizations who do not have a full understanding of their own network requirements. It can cause existing software to become disabled. It could require deployment dates to be extended due to additional development time required to isolate compatibility issues. It may require additional resources or steps to get software to the desktop.

Conclusion

In this article we discussed the need for a desktop firewall policy within an organization. It was discussed how such a policy should be formed, and then an example was provided – along with a detailed discussion of the security benefits it provides an organization.

An old school of thought would resist any restrictions placed on internal network access. But today the stakes are a higher, and security is paramount. At some point in the history of networked computing, an organization has become more accountable for its network traffic and legality of the software it chooses to run. Not many options are available for limiting the use of the network (beyond simply blocking it at the usual choke points, which doesn't allow for the controlling of specific applications). This approach needs to change, as more and more attacks and security concerns come from the soft underbelly of the organization's internal network.

This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.