 |
|
|
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 PC’s 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 & 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. 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 eliminating 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. CyberGuard KnightSTAR CyberGuard was one of the first firewall products to achieve the rigorous ITSEC E3 classification, and for a long time this made it the product of choice for sensitive Government and military applications in the UK. It is still the only commercially available Firewall to ever achieve the even more rigorous Orange Book B1 certification, and has since added B2 functionality and is (at the time of writing) under evaluation for Common Criteria EAL 4. This white paper examines the new KnightSTAR premium network appliance, a complete hardware and software firewall appliance running on the Unix version of CyberGuard 4.3. On the hardware front, KnightSTAR comprises a 17” rack-mount unit with a lockable front cover hiding the floppy and 48x CD-ROM drive. The latter is particularly useful since it provides a rapid recovery mechanism (less then 30 minutes for a complete reinstall of all software including the OS) via a pre-staged installation image (using Norton Ghost) burned onto bootable CDR media. Two sizes are available – 2U and 4U – with the 4U providing nine Ethernet interfaces as standard and two free PCI slots (for a maximum of 16 network interfaces) against the 2U capacity of five interfaces as standard and one free PCI slot (for a maximum of nine network interfaces). The 4U device also includes dual power supplies, but in all other respects they are identical, sporting dual Pentium III processors, 256MB RAM, 9GB hard drive, CD-ROM and floppy drive. A high availability option is also available, with two identical KnightSTAR devices linked via a dedicated heartbeat cable providing fully-automatic fail-over. Although it doesn’t need one to operate, a keyboard and mouse can be attached for local configuration, and other hardware options include an IPSec VPN crypto accelerator card, FDDI card, Token Ring card, ATM card and RS-422 serial port card. The underlying operating system, a hardened version of SCO UnixWare, is actually a B2-compliant secure system, and provides a robust and secure platform for the firewall code itself. CyberGuard can also be supplied as a software-only product, of course, together with installation assistance and training. CyberGuard is one of the new breed of hybrid firewalls that effectively combines all three firewall architectures in a single package. With support for up to 32 host interfaces, KnightSTAR provides tremendous flexibility in defining internal, external, and DMZ networks. It is also possible to combine multiple physical network interface controller (NIC) ports into one logical network interface, thus providing increased reliability, via redundancy, and/or increased throughput. Installation is totally painless, since KnightSTAR comes pre-staged and configured out of the box (even the customers own DNS and network interface configuration can be pre-loaded at the factory) ready for custom rules to be applied. The fact that it is only necessary to connect a few Ethernet leads to get it up and running makes KnightSTAR ideal for large-scale remote deployment, since the plug and play approach means anyone can physically install the device, following which all major configuration and management can be performed via an SSL-encrypted browser-based console. It is also possible for a central administrator to provide a “personality file” (created via a browser-based JavaScript utility) on floppy disk that contains pre-defined parameters for critical components of the KnightSTAR system which are read on first boot. This boots the firewall fully configured to talk securely on the network (or Internet) to a remote administrator for initial configuration.
A complete image of a pre-installed KnightSTAR system is also provided on a bootable CD-ROM along with Norton Ghost software, thus providing a simple means to restore a unit back to “factory” condition in under thirty minutes simply by inserting the CD and power cycling. Finally, the remote administration capabilities are completed with the Automatic System Update feature. This provides the ability for a firewall administrator to update a system with firewall and operating system patches automatically via a secure remote download rather than manually via media such as floppy disk, tape, or CD-ROM The management interface is entirely graphical, and very intuitive - not at all what you would expect from a Unix-based system. The documentation is excellent too. All configuration is performed directly at the server console, though there is an optional remote management package available that utilises a secure encryption mechanism. With the latest release, firewall administrators can be authenticated via a RADIUS server, and different roles or duties can be assigned to different administrative personnel. This makes it possible to administer every CyberGuard firewall in an organisation (whether Unix or NT-based) from any single console. The Central Commander, as it is known, allows you to define rules and configurations and export these to individual firewalls or groups over an encrypted link. The central commander can also be configured in a redundant management scheme to facilitate non stop security and management across geographically independent network operation centres. Using the remote management option, it is also possible to take over a remote console and configure it on the fly. All alerts and alarms generated by the remote firewalls can also be sent back to the Central Commander console.
All changes made to the firewall configuration are also tracked by a secure “ticketing” or version control system, thus allowing a complete audit trail of all configuration amendments. As with any good firewall, CyberGuard is set to deny everything by default. Below the proxy servers in the stack operates a full packet filter firewall, incorporating the usual static filters as well as the more flexible dynamic filters, often called “Stateful Inspection” by other firewall vendors. The CyberGuard packet filter is as far removed from a router-based system as it is possible to get, however. An intuitive icon and menu-driven utility allows you to specify whether individual services should be permitted, denied or proxied, and on which network interfaces, based on the source or destination host addresses, network service and protocol - no esoteric command-line stuff here. The ability to define user-friendly names for networks and hosts (and logically bundle them together into named groups) ought to make the rules that much easier both to define initially, and analyse later. However, the user-friendly names do not actually appear in the packet filter definition window. Using stateful rules-based packet filtering techniques, it is possible to enforce connection time-out periods, maintain an audit trail of connections, force port matching and validate source addresses (to protect against IP spoofing). Unlike other stateful-type architectures, however, CyberGuard’s stateful packet filter implementation is not susceptible to ACK flooding. It is also possible to implement TCP SYN flood protection with different timeout periods for every packet filter rule.
At the highest layer of the OSI stack, there are a number of smart application proxies, including circuit gateway, authenticating and contents enforcement proxies. Circuit gateways proxies (such as SOCKS) provide a relay connection between the public and private networks, ensuring that only well-formed requests traverse the firewall. Authenticating proxies require users to authenticate or log on to the firewall before allowing connections to traverse it, thus ensuring that a valid user is identified before allowing, say, an FTP connection. It is then possible to determine the individual activities permitted or denied - FTP Get or Put, for example - on a per user basis. If a proxy is not defined as requiring authentication, then it is completely transparent to the end user, and no client configuration is necessary. Finally, content enforcement proxies examine the content of network connections and control the actions or information travelling through the firewall. The HTTP proxy, for example, is capable of scanning inbound connections for ActiveX, Java, JavaScript or VBScript content and quarantining that content if required. Proxies are provided for the following services:
The generic proxy allows administrators to define source port, destination port and destination server to allow traffic through the firewall where it is necessary to provide more protection than is available through packet filtering, but where there is not a specific proxy available. The only proxy that is in the NT product but missing here is POP3.
The Split Domain Name System (DNS) hides critical information when the firewall is configured as the network DNS server. A separate DNS server can be configured for each network interface, responding to DNS queries only for its own interface and hiding all others. Although internal host requests can be configured to resolve external host names, DNS requests from external hosts cannot resolve internal names. Together with address translation (where the external network sees only a single firewall IP address, no matter how many internal hosts are behind it), this permits the utilisation of unregistered IP addresses within the customer’s private network. Whilst on the subject of addresses, both static and dynamic Network Address Translation is allowed on any of the interfaces installed in the firewall. The combination of Static NAT, Dynamic NAT and integral Split DNS provides enormous flexibility when it comes to hiding the internal network from would-be intruders. Creating the rules for the firewall is very straightforward, since the graphical user interface is very intuitive and the documentation is excellent. The ability to duplicate existing rules in order to make minor modifications, and to re-order rules quickly and easily using up and down arrow buttons makes rules configuration as quick and painless as possible. One of the nicest features is that configuring a proxy server automatically creates the appropriate packet filter rules which are then available for examination or further manual modification in the packet filter rules window. This does cause a few problems depending on how you define your DMZ, however. Given that there is no specific interface definition for DMZ, you have to designate it either as “internal” or “external”. Since many of the auto-generated rules from the proxies allow access from “all internal” interfaces, you may find yourself providing access to somewhere from your DMZ which you had not intended. This can be solved by designating the DMZ as an “external” interface and maybe opening a couple of extra paths to it using manual packet filer rules, but I would prefer to see a specific DMZ interface within CyberGuard and have the auto-generated rules treat it sensibly. CyberGuard also includes a unique user-based authentication feature called Passport One, which allows the administrator to define rules on a per-user basis rather than by IP address, thus eliminating the risk of users gaining access to unauthorised services by logging on at another machine. Users can be defined at the CyberGuard console to authenticate with a simple password, RADIUS, SecurID or SecureNetKey technologies. Each user can be restricted to a single source address, have their connection time limited, and have their FTP operations restricted to certain commands. Effectively this feature allows the administrator to build “virtual firewalls”, since the rules only exist after the user properly authenticates. Then, when the user has completed his session, the rules are removed. Hence the term “virtual firewall” – it is not possible to hack a rule if it does not exist in the rule base! Auditing and reporting capabilities of CyberGuard are amongst the best we have seen. It is possible to specify in fine detail which activities should be logged by the firewall, including all packets processed, only denied packets, only permitted packets, login attempts, session completion, system updates and proxy activity. IDS alerts can also be set on suspicious or abnormal activity such as failed logon attempts, disk full, packet forwarding attacks, LAND attacks, Ping of Death attacks, SYN Flood attacks, spoofing attempts and port scanning attempts. Alerts can be shown in real time in an alert summary window as well as being logged to disk. The extensive activity reports can filter on any of these alert events, or a more specific user-defined filter can be applied. With the latest release, logs files can be archived automatically to a remote archive server or locally on the firewall. A wide range of media is supported, including tape device, file system on the firewall or FTP server, and the log files can be encrypted during the archive process. With the latest release, CyberGuard now supports CVP for anti virus Scanning, typically using the popular Symantec anti virus package. A key feature which will be of interest to large enterprise users and ISP’s is High Availability, essential for continuous operation and security of a critical business firewalls. Many organisations keep a standby firewall ready configured in case of system failure, but there is still some down time while the hardware is swapped. CyberGuard HA+ Firewalls provide automatic fail-over detection and switch-over from one firewall to another when failed services are detected. When a Firewall failure is detected, a transparent process initiates commands that will allow another Firewall to become the active (primary) Firewall. Fail-over on an average will take place in less than a minute without rebooting. Heartbeat Ethernet interfaces are used to provide dedicated communication between the fail-over firewalls. IP addresses are migrated across Firewalls when a fail over occurs so the IP will not change to the outside world, and CyberGuard can be configured to fail-over without losing connections CyberGuard HA+ Firewall will also replicate important firewall command files that are critical to security so that every aspect in the highly available environment will remain secure. The replication of critical files will be synchronised between the active and inactive firewall to insure that the identical security rules and attributes are maintained. Finally, it is worth noting that CyberGuard allows the administrator to monitor the health of key servers behind the firewall, thereby offering a degree of higher availability for the entire network. CyberGuard remains one of the market leaders by continuing to offer a wide range of proxies coupled with both static and dynamic packet filtering capabilities in a B2-compliant ITSEC E3-certified system. By maximising performance in multi-processor systems, CyberGuard also provides high levels of performance even when operating as a proxy server. It offers just about every feature you are ever likely to want in a firewall with a flexible and easy to use management interface. One of the things we particularly liked about CyberGuard is that there are usually multiple ways of achieving the same ends. Whereas many firewalls will force you down a particular path or impose a particular way of working to suit their architecture, CyberGuard will usually incorporate all the options and offer the administrator the choice. This makes it one of the easiest firewalls we have come across to configure for an existing environment, and means that it should never be necessary to requiring the administrator to modify the corporate security policy in order to meet the limitations of the firewall. In bundling of the CyberGuard software with a dedicated hardware platform, CyberGuard has produced an excellent firewall appliance that offers high levels of performance and is remarkably easy to use. The resulting package makes light works of deployment across large-scale enterprises, making it ideal for larger organisations and ISP environments. At the same time, it offers almost a “plug and play” experience for the smaller-scale user. CyberGuard KnightSTAR earns the “NSS Approved” award.
Contact:
CyberGuard Europe Ltd
|
 |
Send mail to webmaster
with questions or
|
