 |
|
|
StoneSoft StoneGate by Bob Walder Table of Contents Introduction With the whole of the networking world moving toward inhabiting a single global village, we inevitably have to start thinking about locking our doors and bolting our windows. It has to be recognised that no computer system can ever be 100 per cent secure, but it has to be secure enough to deter the casual hacker � we don�t want some spotty adolescent spiriting away our corporate secrets from his bedroom using nothing more than a cheap PC, a modem and a few lines of code downloaded from the �Hackers �R� Us� Web site. One in five respondents to a recent survey admitted that intruders had broken into, or had tried to break into, their corporate networks, via the Internet, during the preceding twelve months. This is even more worrying than it sounds, since most experts agree that the majority of break-ins go undetected. For example, attacks by the Defence Information Systems Agency (DISA) on 9,000 US Department of Defence computer systems had an 88 per cent success rate but were detected by less that one in twenty of the target organisations. Of those organisations, only five per cent actually reacted to the attack (Source: NCSA). The first step in securing our networks is not to rush out and buy the best firewall or encryption software we can find, however. Instead, some thought and effort should be put into developing a comprehensive, yet manageable, corporate security policy. This needs to cover everything from anti-virus protection to business recovery strategy. It should cover network access, password policy, authentication methods and how and when encryption should be employed. It should also cover physical security aspects too, such as building access, shredding of sensitive documents, and physical security of PCs and file servers. When it comes to implementing the security policy, one of the major tools available to the network administrator is the firewall. There are a number of definitions of the firewall, but perhaps the simplest is �a mechanism used to protect a trusted network from an untrusted network�. A firewall is a system, or group of systems that enforces an access control policy between two networks, and thus should be viewed as an implementation of policy. The bottom line, therefore, is that a firewall is only as good as the Security Policy it supports. However, it is also true to say that a completely secure firewall is not always transparent to the user, and this can often lead to problems of users trying to circumvent the corporate security policy to get around some unpopular restriction imposed by the firewall. In addition to providing protection from outside attacks, many firewalls today can present just a single IP address to the outside world (known as Network Address Translation, or NAT), thus hiding the real structure of your network from prying eyes. They will also usually provide full auditing and reporting facilities. One thing to bear in mind right from the outset is that a firewall is not simply for protecting a corporate network from unauthorised external access via the Internet, it can also be used internally to prevent unauthorised access to a particular subnet, workgroup or LAN within a corporate network. Figures from the FBI suggest that 70 per cent of all security problems originate from inside an organisation. Thus, for example, if your Research and Development department has its own server, you could protect it and the department�s workstations behind a firewall, whilst still allowing them to remain a part of the corporate-wide network. One caveat here, however. Be aware that there are few firewalls on the market today that can provide wire speed throughput even at 100Mbps, let alone Gigabit speeds. Whilst this is not always an issue when the firewall is sitting in front of a slow Internet link, it can cause some serious bottlenecks if you try to put it on a Gigabit backbone! With recent advances in processing speeds and multi-processor implementations we are beginning to see dedicated appliances that can provide wire speed throughput on a Fast Ethernet network with a proxy server architecture, and even higher speeds when configured as stateful inspection devices. Careful network design and load balancing across multiple firewall devices are still prerequisites for Gigabit networks and above, however. When looking at today�s firewall products, there are three main architectures currently in use : Working at the Network Layer of the OSI stack, packet filters make simple deny or permit choices depending on the source/destination network address and port number contained within the packet, determined by a number of rules defined by the administrator. Packet filtering is fast, transparent (no changes are required at the client), flexible and cheap (most routers will provide packet filtering capabilities, pure packet filter firewalls do not require powerful hardware on which to run). However, packet filter firewalls are traditionally difficult to configure and provide relatively poor logging capabilities. Dynamic Packet Filtering/Stateful Inspection Some vendors are touting this as the �third generation� of firewall architectures, but it is really just an extension of the basic packet filtering architecture employed by most routers, and is becoming more and more common in even the most basic firewall products. With the release of version 2.4 of the Linux kernel, stateful packet filtering is even available in your basic Linux distributions. Stateful Inspection occurs at the MAC or Network Layer, thus making it fast and preventing suspect packets from travelling up the protocol stack. Unlike static packet filtering, however, Stateful Inspection is capable of making its decisions based on all the data in the packet (corresponding to all the levels of the OSI stack), although it is rare that all seven layers are examined in any great depth in practice. The state of the connection is monitored at all times (hence Stateful Inspection), allowing the actions of the firewall to vary based on the administrator-defined rules and the state of previous conversations. In effect, the firewall is capable of remembering the state of each ongoing conversation across it and dynamically modifying the packet filter rules to suit (hence Dynamic Packet Filtering), thus allowing it to more effectively determine which inbound packets are part of an existing session and which are �rogue� packets. A Proxy Server firewall acts as an intermediary for user requests, setting up a second connection to the desired resource either at the application layer (an application level gateway) or at the session or transport layer (a circuit level gateway). A strong application proxy works at all seven layers of the OSI model, performing such tasks as verifying the RFC-required three-way handshake which are normally omitted by pure stateful inspection devices. It will also ensure that protocol header lengths meet with RFC guidelines, hence preventing an entire class of buffer overrun attacks. Proxy code actually �stands in� for both client and server operations, relaying valid requests between the trusted and untrusted networks via the proxies. Unlike Packet Filter and Stateful Inspection firewalls, a direct connection is never allowed between the two networks. It is important to note that the application proxy actually builds a new datagram from scratch, only copying known acceptable commands to the new datagram before forwarding it to the server behind the firewall. The datagram that enters the firewall from the outside is thus not the datagram that is delivered to the server, and thus the proxy effectively breaks the client server model (but in a �good way�). With other technologies such as packet filtering there is still a direct connection between the client and server, albeit one that is monitored closely for abnormalities in a Stateful Inspection architecture. However, the nature of the direct connection does still provide the means for attackers to either hide data in unused datagram headers or to bury dangerous commands within the data area. This is simply not an issue with Proxy Servers. The penalties paid for this level of security, however, are performance (Proxy Server firewalls have large processor and memory requirements in order to support many simultaneous users), and flexibility (since the introduction of new Internet applications and protocols can often involve significant delays while new proxies are developed specifically to support them). Once again, recent advances in processor speeds and SMP platforms are beginning to provide effective arguments against the performance criticism in well-designed systems, whilst the provision of �generic� proxies can allow unsupported protocols to be handled by the firewall. Whilst static packet filtering alone is usually confined to the router these days and not considered strong enough for enterprise class firewall devices, the differences between the remaining two architectures are negligible in most real world environments. True proxy servers are undoubtedly the safest, but can impose a severe overhead in heavily loaded networks if not designed properly. Dynamic packet filtering is definitely faster, though most of the high-end firewalls are hybrids these days, incorporating elements of all three architectures and, arguably, the �best of all worlds�. One final consideration is the underlying operating system. Good firewall code will not help if the OS on which the firewall is running is itself not secured. Whilst a dedicated firewall OS could be considered the best solution to this problem, general purpose operating systems can offer a secure platform providing they are �hardened� sufficiently before the firewall is installed. However, at the end of the day, it is just as important to ensure that you have a comprehensive security policy in place and that your firewall is configured and managed effectively, as it is to have a firewall in the first place. After all, a badly configured firewall could lead to a false sense of security � and that could be worse than leaving yourself unprotected. StoneGate is an unusual product in that it is designed from the ground up for the demands of high-availability and high-throughput environments. Stonesoft made its name by producing high-availability clustering solutions for other firewalls � such as Checkpoint FireWall-1 � before deciding to produce its own firewall product. As a result, StoneGate includes clustering capabilities out of the box at no extra cost. StoneGate is a distributed firewall that consists of four separate components: Engine � this is the stateful multi-layer inspection firewall that runs on � and is bundled with � a hardened version of Linux (based on the Debian distribution). No Linux knowledge is required since the stripped and hardened OS is installed automatically with the engine and is then controlled via the management system. Management Server � This is the heart of the three-tier management system. The Management Server stores configuration information for the various Engines under its control, and can push security policies and configuration information to those Engines en masse or individually across a secure link. Log Server � The Log Server retrieves and stores log information from the firewall Engines and provides it on demand to the management GUI. During normal operation the secure link is active, so logs are transferred to the Log Server immediately. If, however, the connection to the Log Server is not available, then log data is stored locally on each firewall node and transmitted to the Log Server once the secure link becomes active again. Client � The Client is the Java-based GUI administration and reporting interface to the Management and Log Servers. The Client will often reside on the same host as the Management Server, but can reside on any host and communicates with servers under its control via a secure, encrypted link. All of the StoneGate servers on a network can be managed from a single Client if required, or multiple Clients can manage a single engine from different locations. The final three components collectively are known as the StoneGate Management System (SMS). They can be installed together on a single host, or spread across multiple hosts to facilitate remote management and increase performance. All the SMS components are Java-based, and can thus run on a wide range of platforms, including Windows 2000/NT, Solaris or Linux. An optional IPSec VPN component is also available at extra cost. One of the more unusual features of the StoneGate product is that it includes full clustering capabilities out of the box. Up to 16 Engines can be clustered together to form a unified entity using a dedicated control network and clustering protocol. Each engine host requires an additional network card dedicated to the clustering protocol and �heartbeat�. A firewall in a StoneGate cluster is capable of failing over all sessions to other firewalls, including VPN tunnels and VPN client connections. A StoneGate cluster also provides load balancing capabilities, meaning that all traffic is balanced as evenly as possible between the Engines in a cluster. Whenever a node comes online or goes offline for any reason, the load is redistributed across the working nodes. The dynamic load balancing option also allows for moving a part of the network traffic from an overloaded Engine to the remaining nodes without losing state or connection information. This functionality is based on a common knowledge of the cluster state shared by all firewall nodes, and a special load balancing filter. The Engines within a cluster use the clustering protocol to communicate and maintain an identical view of the cluster status. This is possible because the nodes periodically exchange information � always incorporating in their own view the views of the other nodes � as part of a special �heartbeat protocol�. Other information which is exchanged regularly includes: Current connections Which nodes are online What is the capacity of each online node How much data each node is handling The clustering protocol is also used to detect node failures, separate failed nodes for the cluster automatically, and to synchronise load balancing decisions so that the filtering is changed simultaneously on all nodes.
There are two types of IP and MAC addresses used in a StoneGate cluster � one �virtual� and one �real�. All nodes in the cluster share common gateway IP and MAC addresses on what is known as the Cluster Virtual Interface (CVI). CVI addresses are available only when the firewall is online, and the CVI always has a unicast IP address, whereas its MAC address can be either multicast or unicast. The directly connected routers and hosts always use the CVI as the gateway IP address, since the CVI addresses the cluster as a whole. If a connection is opened using the CVI as the destination, the peer can be any one of the online firewalls, and in this case, the source IP address of the reply packets is the address of the CVI. In addition to the CVI, each firewall node can have Node Dedicated Interface (NDI) addresses associated with each interface. NDI addresses are the �real� addresses, and enable communication with a particular node within a cluster. If the multicast address of a CVI is used, the NDI addresses are also available in an offline state. The NDIs also ensure that reply packets belonging to connections from the firewall itself reach the appropriate firewall node. NDIs are always mapped to a unicast MAC address. If a unicast MAC address is used also for the CVIs, then all the firewall nodes within a cluster have the same CVI MAC address. In this case, the NDI IP addresses are configured to the load balancing filter, since filtering is required to pass packets to the NDI addresses on the correct node. In the case of a multicast CVI MAC address, the NDI IP address is mapped to a unique unicast MAC address on each node, and therefore no additional filtering is required This all sounds a little complicated, but it is necessary to get to grips with this aspect of the StoneGate system since the use of multicast or unicast MAC addresses can affect the use and configuration of switches and routers around the firewall cluster. Note that none of this is applicable if clustering is not used, and management of the StoneGate firewall is identical - via the Client � whether it is a stand alone Engine or part of a cluster. High availability is also enhanced by another feature � known as Multi-Link Technology � which appears to be unique to StoneGate. Multi-Link allows a firewall to be connected to multiple ISPs via multiple interfaces or via a single interface with multiple ISP connections. StoneGate can then load balance between connected ISPs, with load balancing applied to all outbound and inbound traffic, including VPN tunnels. For outbound connections and VPN tunnels, StoneGate always chooses the fastest available ISP connection. Looking at the extensive Installation Guide (both Installation and Administrator Guides are provided in both hard copy and electronic format � a rarity these days), you would be forgiven for thinking that the installation of StoneGate is complicated. Whilst there may be several steps involved in installing a distributed or clustered system compared with a simple Windows-based firewall, however, there is certainly nothing inherently complex about the procedure. Following the step-by-step Installation Guide results in a smooth installation, and it takes longer to read about it that it does to actually do it once you are familiar with the process. A basic installation might see the Client, Management Server and Log Server installed on one host, managing a stand alone Engine which is installed on another. More complex deployments might see Client, Log and Management Servers installed on separate machines, perhaps controlling a mixture of stand-alone and clustered Engines. Whilst installation of the latter might involve a few more steps and a little more planning (especially where communications between different components occur across remote WAN links or firewalls), it is really not much more complex. There are two basic types of installation: Single firewall � A single firewall has only one node, and cannot, therefore, support load balancing or high availability for firewall activity. A single firewall element includes the definition of a single node, optional advanced settings and manual ARP entries. Firewall cluster � A cluster supports 2-16 nodes able to work together as a single entity, and the configuration of the firewall cluster is installed on each node. Each node of the cluster must enforce the same security policy created by the Management System, and each cluster can be configured to perform dynamic load balancing or to be a hot standby solution.
The system is provided on two CDs, one for the StoneGate Management System (SMS) and one for the Engine. The SMS installation installs the Java Runtime Environment that is used by the Java-based Management System, the core Management System itself, and prompts the administrator to install one or more of the individual SMS components. During installation, a set of dialogue boxes prompt the administrator for the location of the various databases (Solid is used as the underlying database system) and IP addresses of other components of the Management System. Once the Management System has been installed, the Engine(s) can follow. The Engine is provided on a separate CD, since that CD has to be bootable. This is because the installation process is designed to run on a dedicated machine where any existing OS and disk partitions will be wiped and replaced by the hardened Linux OS running the StoneGate Engine software. This is a highly automated process with few parameters to be input at the console, other than keyboard layout, network device drivers (these must be known, since there is no auto-sensing capability), time zone, and so on. Finally, once the Engines have been installed, the Management System is used to perform the initial configuration. This is probably the most complicated part of the installation procedure, especially when implementing a cluster. The various interfaces are defined on each firewall node (including NDI or CVI mode, unicast or multicast MAC address, etc.), and the cluster properties are specified. During this procedure, the configuration parameters for each Engine can be saved to floppy disk, which also includes the IP address and public digital certificate of the Management Server, and a one-time password used for the initial connection between Engine and Server. Once this information has been imported to each node in the cluster, the system is ready for the definition and application of the security policy. StoneGate has a three-tier management system. Administrators access it via the management GUI, which is connected to Management Servers and Log Servers. The Management Servers update configuration information to the firewall Engines, and the Log Servers retrieve log information from the firewalls. Multiple Log Servers can be deployed if required for performance reasons, though each cluster can only log to a single Log Server. The Log Server provides a dedicated service to the firewall, which enables the system to provide real-time tracking and statistical analysis. The management GUI is Java-based, and includes tools for maintaining the rule base templates as well as extensive log filtering and pruning capabilities. The GUI is separate from the Management Server itself, and multiple instances of the GUI can access a single Management Server from remote locations, if required. It also enforces multiple administrator levels, enabling different administrators to be restricted to different tasks. The management system also has a number of automated features built in, such as automated log data processing and built-in backup capabilities of both data and configuration files. All communications between the management systems and the firewall Engines is securely encrypted, and the configuration data is fully protected and tamper proof. Definition of the security policy and distribution to all nodes in a cluster is carried out from the management GUI. The basic architecture of a security policy relies on the definition of network elements (services, hosts, routers, users, groups, firewalls, and so on) and dedicated rules and sub-rules contained in rule bases. Network elements are defined for the purpose of using them as rule components (as sources or destinations) and both elements and rules are displayed in an easy-to-follow hierarchical tree structure within the GUI.
The GUI provides a number of different views to simplify administration as much as possible: Repository View � displays all network elements by their type (host, router, etc.) Routing View � a connection-oriented view that allows the administrator to define available routes on each firewall interface Anti-Spoofing View � this is generated based on information in the Routing View, and allows the administrator to specify which IP addresses behind each firewall interface are allowed for incoming traffic through that interface Search View � to search for elements by name, IP address, type or category Service View � lists commonly used available services by protocol Protocol Agent View � Protocol Agents are extensions to the core firewall engine, assisting in the handling of application level information by validating application level data, modifying application level data when required (i.e. Network Address Translation (NAT)), or opening and closing connections when required. Examples of Protocol Agents would be FTP (which can handle both active and passive FTP connections as well as redirect traffic to a separate content screening server), and HTTP (which can redirect Web traffic to a separate content screening server to intercept viruses and inappropriate content for inbound connections, and perform URL blocking for outbound connections). User View � to add, copy, delete or clear users, groups or domains Authentication Service View � displaying a list of authentication services (RADIUS or TACACS+) containing authentication servers Rule definition follows a similar path to most other packet filter or stateful inspection firewalls. Each line of the rule base contains a set of parameters which are compared against packets which pass through the firewall, and a set of Protocol Agents is also provided to tune the filtering of traffic according to the protocols in use. Where a match is found for IP address, port number, and protocol then one or more actions are effected. The action specifies if the packet is allowed through the firewall, refused, discarded, or if a VPN tunnel is to be created. The action can also be �continue�, which forces further rule matching to be performed, or a jump to a group of �sub-rules� can be effected. This latter feature is a very useful capability that is designed to speed the matching process during� firewall traversal, since whole sections of the rule-base can be taken out of the matching process based on the results of one rule. It also makes large and complex rule bases much easier to follow, much as subroutines make computer programs easier to read.
Once defined, the same rule base must be shared by each node of a firewall cluster after loading it into the Engine. Editing and updating rule bases is done according to administrator privileges and permissions, and consistency across the network is afforded by the use of template rule bases. These are special rule bases which are set up by the main administrator and then �locked�. The rules contained within are not editable by any other administrators, but each template contains an insert point where new rules and sub-rules can be added to suit the individual requirements of different firewalls. Once updated, a rule base can be propagated to every firewall to which it applies, where it is installed automatically. Whilst the firewall is running, a real-time monitoring screen in the GUI provides extensive information on the state of the cluster and individual nodes within that cluster (or on individual firewalls where clustering is not in use). On the left-hand side of the monitoring screen is a hierarchical tree view of all the clusters or nodes which are available, and clicking on any entry in the tree brings up a number of tables and graphs on the right hand side of the screen.
State tables provide information on status, load and capacity of clusters or nodes, with indications of which nodes are active within a cluster and how the load is being distributed amongst nodes. Separate statistics tables provide current and historical performance data, and a performance graph shows the same data in a constantly updated graphical form. Log data is produced from multiple firewall engines and collected by the Log Server from multiple gateway hosts. Data in the log server can be viewed and processed immediately after it is received by using the Log Browser. In a large, distributed network with a number of firewalls and clusters deployed, monitoring network activity can be a time consuming business. Since it is simply not possible to scrutinise every single log entry, StoneGate provides several tools for filtering, viewing and managing the log data. Numerous filters can be created to allow log file data to be viewed in different ways. Certain critical conditions and thresholds can be specified against which real-time alerts are raised, and these are handled by the Alert Notification Manager. There are two types of alerts: System alerts � these are defined by the system by default, and can be modified but not removed Custom alerts � these are defined by administrators and can be referenced in access rules. All alerts should be acknowledged by administrators, and the Recent Alert Notification Browser gives him the ability to view the fifty most recent alerts stored by the management server.
An archiving procedure, also filter-based, keeps log file sizes manageable. Archival operations can be executed upon request, or they can be scheduled for regular operation. StoneGate provides an IPSec-compliant VPN as an extra-cost option, which supports both LAN-to-LAN and client-to-LAN secure communications. The StoneGate VPN provides the following functions: Authentication � public key exchanges and certificates ensure the positive identification of communicating parties Access Control � VPN access is restricted by the firewall traffic filter and rule bases Confidentiality � encryption protects tunnelled data whilst in transit across public networks Data integrity � digital signatures ensure that tunnelled data cannot be tampered with Whilst not the simplest firewall to configure � especially when implementing clusters � the centralised management capabilities makes life easy for the administrator once the initial configuration has been tackled. A product of this sophistication is unlikely to be selected by a novice administrator anyway. Performance is excellent, whether single node or clustered, and the firewall passed all our penetration tests with flying colours. In the lab we created a test network with two StoneGate firewall Engines arranged in a single cluster in order that we could also test the high availability and load balancing capabilities. Both outbound and inbound connections appeared to be balanced equally between the two nodes, and when we deliberately failed one node, communications continued uninterrupted via the remaining one. Even existing sessions (both inbound and outbound) were transferred seamlessly with no apparent loss of state. StoneGate provides a wide range of features out of the box that would normally be an additional cost with other products � and some of those features are simply not available with other products. Whilst StoneGate will work well in a smaller environment with one or two single-node firewalls, it really comes into its own in larger enterprise situations where the more advanced features such as distributed management, clustering and load balancing can be exploited to their full extent. An excellent product, overall - Stonesoft StoneGate 1.5.17 earns the �NSS Approved� award.�
Contact:
Stonesoft Corp.����
|
 |
Send mail to webmaster
with questions or�
|
