THIRD PARTY EXPERT ANALYSIS
March 10, 2000
The WinRoute Firewall: Robust Security Features Elegantly Packaged
The first firewalls were built using toolkits hand-crafted to the needs of the system administrator. This intimate access to the low-level functionality of the firewall afforded a great deal of flexibility and control over security. Over the last twenty years, the firewall has evolved to suit the needs of modern companies: ease of deployment, cost, manageability, and so on have all become a requirement in the competitive marketplace for firewall products. Adherence to the main purpose of the firewall – security – can be lost in the glitz of fancy bolt-on functionality such as URL filtering and other non-essential features.
WinRoute Pro 4.1 provides the same sort of flexibility of the early firewall toolkits combined with the well-known simplicity of the Windows platform. The following analysis of the main security-related features and capabilities of WinRoute Pro 4.1 confirms that it is a secure, robust, and elegant platform upon which to build rich network access control functionality for modern small-to-medium sized enterprises.
MAJOR SECURITY-RELATED FEATURES
Firewalls are typically built on hardened platforms and the software itself is typically difficult to circumvent. However, a major weakness in many network security devices is during the brief window of time between when the hardware is actively capable of routing traffic and when the software takes over control of the network interfaces. Within this critical juncture, security can be completely compromised.
WinRoute’s driver, or Engine, activates as the core files of the Windows operating system (the kernel) load themselves into memory; specifically, the engine loads before the NDIS (Network Device Interface Specification) modules are loaded, so that no network connectivity is supported before WinRoute is active. Thus, protection of all interfaces is active before malicious traffic or other attacks can be mounted on the system. This compares favorably to standalone intrusion-detection-type products that run as a service and are not active until after the system has booted.
WinRoute “wraps” NDIS in a proprietary fashion such that all TCP/IP traffic is shunted from the network interface card (NIC) driver to the Engine before it proceeds up the network communications stack to the operating system itself.
This low-level insertion into the operating system allows the WinRoute Engine a unique perspective on all network traffic arriving on any interface (whether inbound or out). As with many enterprise-class firewall products such as Check Point’s Firewall-1, WinRoute is allowed to make the first decision about whether to allow or deny a given packet. Once again, this prevents malicious attacks against other aspects of the operating system or other software that could bypass the security offered by a firewall. This is certainly desirable for externally-facing Internet gateways, but can also provide great benefits to standalone hosts with high security or anonymity requirements, such as an intrusion detection system. Intrusion detection software such as Real Secure from Internet Security Systems (ISS) would be practically invisible on a host protected by WinRoute.
Lastly, the WinRoute Engine takes over all communications routing functionality from the underlying Windows operating system (whether it be Windows 9x, NT, or 2000). This ensures that if for some reason the WinRoute Engine were to fail, no traffic would be routed between networks. This “fail-closed” stance has been the traditional default for firewall configurations for many years, and serves to protect private networks in the case of common system failures.
The primary function of a firewall is to provide access control over communications (usually in the form of digital “packets” of data) passing between networks controlled by the firewall. WinRoute provides several layers of access control to protect sensitive data from unauthorized access.
NAT – Network Address Translation
Network Address Translation, or NAT, is one of WinRoute’s most powerful security features. NAT is an Internet draft standard protocol for “hiding” private network addresses behind a single address or multiple addresses. A version of NAT called “IP Masquerading” has been popular for many years with the Linux community, and WinRoute is one of few products for the Windows platform to actually provide entry-level NAT functionality.
NAT can be implemented in many ways, but essentially it creates a nearly unlimited private address space for internal networks that is “translated” by WinRoute so that communications can pass to and from public networks without revealing information about sensitive internal systems. Absent knowledge of the private address space on the internal interface of a WinRoute firewall, it is practically impossible to directly attack a system on the NAT-ed internal network.
Winroute can perform NAT on any interface, in contrast to some all-in-one firewall appliance devices that only allow it on the LAN/internal network. The following screen capture illustrates how to configure an external network interface for NAT.
For organizations that have public IP addresses but still want to take advantage of the additional security offered by NAT, WinRoute can be configured to translate specific public server addresses into specific protected internal addresses. This is called “one-to-one NAT,” and is available via the Settings | Advanced | NAT… menu selection within the WinRoute Administration management console, as shown in the following screen capture.
Port redirection is often convenient for companies that wish to use address translation and still offer internal services to the public. For example, a Lotus Notes SMTP server could be protected by the firewall and still serve Internet mail for employees. Port Mapping allows the WinRoute firewall to listen on an unreserved port (say 5555) and relay external connections to this port to a well-known port on an internal system (say port 44333, the WinRoute Remote Administration Protocol).
The heart of any firewall access control mechanism is, of course, the technology by which it permits or denies packets destined for protected networks. WinRoute implements one of the most commonly used technologies for network access control: packet filtering. Although WinRoute does implement other access control mechanisms, such as an integrated caching proxy server for HTTP, FTP, and Gopher protocols, this is primarily intended as an outbound performance enhancing element and not a security feature.
Packet filtering has a long tradition in the security community, and is still implemented widely in products such as Cisco’s IOS network device operating system. Configured properly, packet filters can be made quite secure, and are particularly appropriate for high-volume Internet sites as they provide the best performance benefits.
It is important to note that sophisticated attacks have been devised to circumvent traditional packet filtering firewalls under certain conditions (for a discussion of these techniques, see http://www.insecure.org/nmap/p51-11.txt). However, in our testing of WinRoute using a commercial tool designed to emulate the most popular forms of these attacks (Network Associates Cybercop Scanner running the Custom Audit Scripting Language Firewall/Filter Checks module), we were unsuccessful in passing traffic beyond a well-configured WinRoute packet filter.
Our test configuration was similar to the diagram shown next:
Our test protocol essentially involved launching CyberCop’s extensive battery of Firewall/Filter checks against the listening Sentry daemon behind the WinRoute firewall (configured with a standard set of rules similar to the Sample Basic Packet Filter Rule sets found later in this document). The Sentry daemon is designed to record all packets that successfully evade the firewall filters. In our testing, no packets were received by the Sentry daemon (baseline testing was performed beforehand without the intervening firewall to ensure proper Sentry daemon functionality).
WinRoute Packet filtering in practice
Despite theoretical issues surrounding packet filtering, the primary point of failure for modern firewall systems is misconfiguration, especially by inexperienced administrative staff. WinRoute makes configuration of filters simple and yet flexible enough so that even the novice network administrators can implement a secure configuration with a little knowledge of TCP/IP and a few mouse clicks, as illustrated in the following screen capture.
As shown above, filter rules may be applied on a per-interface basis to all of the following entities:
a single IP address
an administrator-defined list of IP addresses
an entire network or subnet
It is also important to note here that filters can be set for both incoming and outgoing traffic.
These capabilities allow granular tailoring of access rules to the security needs of almost any organization. For example, a group of Web developers could be granted access to specific external resources such as anonymous FTP staging servers, or a specified list of internal addresses can be designated accessible to external partner networks for drop-off of electronic files. The inbound/outbound configuration allows protection from malicious “inside-out” attacks such as Back Orifice (BO) or distributed denial of service (DDOS) servlets that attempt to communicate over unreliable protocols back out through the firewall with external attackers.
Rules can either Permit, Drop, or Deny the specified traffic; the “Drop” action gives away the least information about the firewall to potential attackers, as it does not send an ICMP Administrative Prohobited Filter or a TCP Reset/Acknowledge response to a TCP SYN packet (the 1st step in the standard three-way TCP handshake sequence).
Rules may be prioritized to act in a specific, user-defined order upon incoming or outgoing packets. The most popular use of this capability is to add so-called “cleanup rules” to filter lists that block all traffic not specifically allowed by previous rules that have higher priority in the list (for an example of a clean-up rule, see the Sample Basic packet Filter Rule sets, later in this document).
Protocols supported by WinRoute packet filters include raw IP, seven ICMP types (or All), TCP, UDP, or PPTP. The ability to permit or block raw specific ICMP types or raw IP protocols is invaluable to network administrators faced with an ever-growing list of application requirements to support. In particular, relatively new VPN protocols such as IPSec travel over raw IP protocols 51 and 52, which would be impossible to filter using some of the more limited firewall products on the market today that are only capable of controlling TCP or UDP-based protocols.
In addition, WinRoute provides anti-spoofing capabilities, which prevents packets with invalid source addresses from originating within a network. Anti-spoofing could have prevented the ICMP smurf attacks reported in February 2000 with the distributed denial of service attacks on such major Web sites as Yahoo and Buy.com. WinRoute users can rest comfortably knowing that their networks are unlikely sources of such attacks if they implement this feature.
The following set of packet filter rules are offered as a basic configuration for new WinRoute administrators to get up and running quickly with a simple and secure configuration.
Sample Basic Packet Filter Rule Set
Incoming rules (make sure they are in this order)
Protocol Source Destination ICMP Types Action Log Description
UDP Any Address, Port = 53 Any Address, Port > 1023 Permit Allows outbound DNS resolution
TCP Any Address, Any Ports Any Address, Port > 1023 Permit- established TCP Allows all TCP traffic initiated by localhost coming back
ICMP Any Address Any Address Echo Reply Permit To allow you to ping others but them not to ping you
IP Any Address Any Address Drop To window Cleanup rule blocking all traffic not included above.
Note: This last “cleanup rule” will interfere with any network packet capture tools used on this host.
Sample Basic Packet Filter Rule Set for inbound HTTP and FTP
Protocol Source Destination ICMP Types Action Log Description
TCP Any Address, Any port [this host], Port = 80 Permit (optional) Allows inbound HTTP (Web server) access to this host
TCP Any address, Any port [this host], Port = 21 Permit (optional) Allows inbound FTP control channel to this host
TCP Any address, Any port [this host], Port = 20 Permit (optional) Allows inbound FTP data channel to this host (active FTP only, passive FTP requires opening of all ports > 1023 – not good)
Domain Name System (DNS) Configuration
One of the historical obstacles faced by firewall architects is dealing with DNS. Organizations often want to publish address information about publicly accessible hosts, while at the same time deny access to information about private systems. Traditionally, this has been accomplished using a so-called a “split DNS” setup.
With split DNS, the name-to-address mappings for public servers is stored on a secondary DNS server (often the firewall itself), separate from the main internal DNS system. Thus, external users can only access information about specific, publicly accessible hosts.
WinRoute implements two mechanisms to deal securely with DNS, as shown in the following screen capture and described in the subsequent table:
This setting allows organizations without their own DNS infrastructure to leverage external DNS services. Requests are forwarded to an external server for resolution.
Simple DNS Resolution
This is nearly equivalent to a split DNS setup. WinRoute will attempt to find the lookup request in the local Hosts file before forwarding it on to an external DNS server.
This provides maximum flexibility for organizations with different needs to implement DNS securely.
One of the most powerful features of any network device is remote manageability. Unfortunately, securing the communications channel used for management traffic is often an afterthought.
WinRoute provides remote management capabilities over a proprietary protocol running on TCP and UDP port 44333. Remote management traffic is encrypted using CAST and the session keys are distributed using the Diffie-Hellmann algorithm. Close examination of management traffic with a network eavesdropping tool reveals very little that an attacker could leverage for a successful attack against a WinRoute firewall.
Attempts to brute force guess Administrator passwords is feasible against the fixed port number, but a simple packet filter rule can be used to restrict connections to specific hosts or networks (this is highly recommended). Logging could be additionally enabled for this rule to identify if a brute force password guessing attack has occurred. The following screen capture illustrates what such a filter might look like:
One consideration should be made for remote management of WinRoute. WinRoute’s default password (following first installation) is NULL. Users should make sure to change this to a suitably complex password of at least 8 characters, preferably with numeric and special characters (such as &*^%). Non-printable characters (such as [NUM LOCK] ALT-255) can also be used to further lower the chances that a password can be guessed using standard dictionary-based attacks.
A critical function of any security product is the ability to record events at all times in a sufficiently detailed fashion. WinRoute records six different logs of traffic that impacts the firewall, including packets that pass through it, user activities, filter actions, and so on. A description of each log is shown in the following table:
Displays only HTTP data passing through the WinRoute Proxy server; includes source IP address and username, time stamp, and HTTP queries and responses
Records all operations of the WinRoute’s built-in mail server; records SMTP an POP3 send/receive activities
Shows all activities defined as “Log to window/file” in packet filter rules (see below for detailed description of items recorded)
Records usage information for dial-up interfaces monitored by WinRoute
A la carte settings to record all ARP, ICMP, UDP, TCP, and/or DNS packets that physically cross any interface of the WinRoute router; granular configuration available under Settings | Advanced | Debug Info, Debug tab.
Displays all unsuccessful operations occurring in any running WinRoute module
Logging can be displayed to the console of the WinRoute Administrator, or written to a file, or both. The log files are stored in \%installroot%\Logs, which is only accessible to the NT/2000 accounts within Administrators, Server Operators, SYSTEM, and the CREATOR OWNER who installed WinRoute.
Packet Filter rule impacted
Action (Permit, Drop, Deny)
Source IP address and TCP port
Destination IP address and TCP port
Testing under adverse high-traffic conditions does not affect the WinRoute logging capability. This is critical to avoid loss of valuable forensic data as well as to alleviate potential denial-of-service situation where firewall functionality shuts down if the logging system is overwhelmed.
In our testing, we noted that additional fault tolerance and convenience could be achieved if Winroute stored its log on a separate machine or allowed you to write the logfile to a mapped drive.
Internal Account management
WinRoute can be programmed with individual user accounts that can be grouped (configured under the Settings | Accounts… | Users tab). Existing Windows NT/2000 users can be imported via the Advanced tab under the Settings | Accounts… menu. This allows user- and group-specific packet filter creation to address organizational roles. For example, the human resources department may be granted access to the payroll database server network, while the line staff would be denied access.
Virtual Private Networking
As mentioned previously, WinRoute is fully capable of passing traffic from the two most popular VPN protocols in use today: the IP Security protocol (IPSec) proposed by the IETF, and the Point-to-Point Tunneling protocol, made popular in recent years due to its inclusion with Microsoft Windows client operating system software.
Third-Party Interoperability & Integration
WinRoute support many proprietary protocols and applications, including H.323, ICQ, CUSeeMe, CITRIX Metaframe, Symantec PC Anywhere, and many others.
CASE STUDY :KOKOSING CONSTRUCTION
How do Win Route’s security features perform in the real world? Kokosing Construction, the largest privately held construction company in Ohio, has been using WinRoute for over one year to provide security for multiple offices within their company. Their experience with WinRoute is illustrative of the major strengths of the product described to this point.
When initially assessing the firewall market, Kokosing was discouraged by the expense of the two market-leading firewall products, Check Point Technologies Firewall-1 and Cisco’s PIX. Kokosing initially deployed Microsoft’s Proxy Server product as a lower-cost alternative to these options, but were soon disappointed by the difficulty of maintaining Proxy in their environment: set up proved technically challenging, and they were briefly concerned by the unauthorized use of their Proxy server to launder connections for external parties in foreign countries (this issue was subsequently fixed by a configuration adjustment).
When a trusted consultant recommended WinRoute as an alternative to higher-priced solutions and proxy-based alternatives, Kokosing elected to try it out. They were immediately impressed with the low cost and ease of configuration. At around $700 for unlimited users, and limited hardware costs (Kokosing deployed WinRoute on an unused 150 MHz Pentium with 128M RAM and 2 network interface cards), they obtained nearly all of the flexibility of higher-end solutions without the complexity of proxy-based products.
WinRoute continues to provide reliable Internet gateway security for Kokosing today. Outbound traffic from approximately 300 internal PCs has not been interrupted in the year since they deployed the WinRoute firewall, and it continues to meet their inbound application needs (thanks to built-in port mapping, support for PPTP, and Citrix MetaFrame). Kokosing’s remote offices can share in these benefits since they have implemented Winroute Lite on their gateways.
Kokosing’s IT management continue to feel confident in the security of their infrastructure behind the WinRoute firewall, primarily because of its simplicity and flexibility. They can take advantage of all that the Internet has to offer without undue fear of potential exposures to unauthorized activity.
WinRoute will continue to evolve with customers’ network access control needs. In the immediate term, the International Computer Security Association (ICSA) is taking WinRoute through its firewall certification process. ICSA certifies many of the top firewall products, and its certification has come to be regarded as a required pre-sales qualification for many organizations. Tiny Software also continues to bring new flexibility to the product, including a planned mail antivirus checking capability and enhanced Windows NT user authentication.
This paper has demonstrated the fundamental strengths of the WinRoute security architecture and demonstrated its major security functionality. WinRoute is aptly suited for deployment in a wide variety of environments where its user-friendliness and flexibility make it a strong choice for a firewall purchase.
For information on implementation and general background, see the WinRoute 4.0 Administrator’s Manual.