 |
|
|
Network ICE BlackICE Sentry 2.1 ICEpac is a suite of products from Network ICE Corporation that offers a choice of Network IDS and Network Node IDS in the same product – the first, to our knowledge, that provided this feature – along with centralised reporting, management and installation capabilities. The key components in ICEpac are: BlackICE Agent – provides high performance end node intrusion detection, hacker identification, and protection for all Windows 9x and NT systems (a Windows 2000 version will be available shortly). Because of its very small memory footprint and efficient use of CPU resources, BlackICE Agent has minimal impact on the performance of the end system. BlackICE Sentry – provides high performance intrusion detection and hacker identification for non-Windows based systems (though it still requires a dedicated Windows-based host on which to run), or anywhere where the use of an end-node agent is not desired. BlackICE Sentry is a probe-based solution for use on shared segments or connected to the monitoring port on Ethernet switches. When installed on a properly configured PC system, BlackICE Sentry can detect intrusions on a heavily loaded Ethernet network. ICEcap Manager– a browser based reporting, alerting, and protection system to provide large-scale data collection, automated report generation, intrusion alerting, and distributed protection for all BlackICE Agent systems. All BlackICE Agents and BlackICE Sentry probes can be configured to be controlled by an ICEcap console, and ICEcap stores the information in a MS-SQL/Access database. ICEcap has a browser-based interface so it can be accessed remotely from anywhere on the Internet by authorised users. It also has several different alerting options, including pager and email alerts and can remotely install and update BlackICE Agents and BlackICE Sentry probes in many situations. ICEcap also includes the InstallPac utilities described below. InstallPac – a set of three utilities used to automatically install, update, or remove BlackICE Agents from end systems. These utilities can be used to easily install or update BlackICE Agent on a single system, a Microsoft Workgroup, an NT Domain, or on a range of IP addresses. This installation or update is invisible to the end user, and does not impact their current activities on their computer. Thus, all BlackICE Agents can be easily updated with new detection algorithms without impacting the end users. InstallPac can be installed on the ICEcap system, or on any other system within the corporate network to ease the installation of BlackICE Agents. Pattern Matching v Protocol Analysis One of the main architectural differences between BlackICE (the agent code) and competing Network IDS products is that BlackICE performs full seven-layer protocol analysis rather than simple pattern matching. This approach comes from the fact that the founders of Network ICE are all ex-Network General employees who worked on the original Sniffer product. You may think that a full protocol decode on every packet would be slow, and it is compared with a straight pattern match on a single packet. However, as the number of attack signatures grows (some products have in excess of 1000 signatures in their attack database) it takes longer and longer for a packet to be compared against the ever larger signature database, and this poses problems for the standard pattern matching architectures. The usual answer is to install multiple IDS sensors and have each sensor watch for a subset of the available attack signatures The advantage that BlackICE has is that many attacks are nothing more than variations on a theme. Since protocols and operating systems are built around standards, the protocol analysis engine understands how to process a packet. Unlike pattern matching, the algorithm decodes the suspicious packet and inspects them dynamically for protocol correctness. For example, hackers will often use variable size buffer overflows to evade traditional IDS systems, and some pattern matching software will miss these “new” attacks because it is looking for a static buffer overflow size. Each small change to an attack requires a new signature in a pattern matching system – and every signature imposes additional overhead on the detection process. On the other hand, a protocol analysis algorithm can dynamically identify all “incorrect” or “oversize” packets – no matter what size the buffer overflow -� and drop the packet before it reaches the TCP/IP stack. Of course, when new undiscovered vulnerabilities, attacks, or exploits are found, Network ICE still needs to update the protocol analysis algorithm by adding a new protocol to watch, or by changing a variable to the algorithm that is specific to a certain protocol. The downside of this approach is that it can sometimes take longer to do this than to add a new pattern matching attack signature to a database. However, updates to Network ICE are needed far less often for most new attacks and exploits because they are often variants of older attacks. Using a protocol analysis approach thus takes less updating and patching, and is capable of higher levels of performance as “traditional” IDS’ struggle with larger and larger attack signature databases. Of course, the other vendors have spotted the same problem, and so we are seeing an increase in systems that pattern match against “generic” signatures in an attempt to improve performance and reduce the number of updates required to accommodate new attacks. This approach may not always be as accurate or as highly performing as the full-blown protocol decode – it has to say something that BlackICE is the only product we looked at that automatically enabled every signature in its database for checking without having to worry about the performance hit, even when working as a Network Node IDS. The other advantage is that the protocol decode approach allows BlackICE to handle out-of-order and fragmented packets better than some of the competition. Unless session state is maintained and monitored over multiple packets, and unless packets are reordered correctly and fragments reassembled, pattern matching simply does not work. Packet reassembly is an integral part of BlackICE, whereas some of the competition is now having to modify their products to handle this. All ICEpac components are provided as single executable files to be downloaded from the Network ICE Web site. Installation is usually a matter of simply running the executable and accepting the defaults. For BlackICE Sentry installations, Network ICE recommends installing the software onto a dual-processor machine – one processor dedicated to packet capture and the second dedicated to protocol analysis – with two network interface cards. This requires a few additional steps following installation of the Agent software. Firstly, the processor affinity needs to be set in NT to ensure that each processor is dedicated to its allotted task. Secondly, the NIC which is to be used for packet capture should be removed from the NT network configuration and put into promiscuous mode in the BlackICE Sentry configuration file. The second NIC should be given an address on a private “management” only network on which the ICEcap server is located. Thus, the packet capture NIC becomes “invisible” on the main network, and management and reporting traffic is kept to a second network which would not be vulnerable to attack. Network ICE is looking at automating these additional procedures in a future release. Centralised Deployment via InstallPac In larger corporate environments, InstallPac can be used to install agent software onto target hosts remotely, thus removing the need to perform individual installations. For NT systems, the InstallNet push program works very effectively for installing and automatically starting BlackICE Pro on a large number of systems simultaneously. For Windows 9x systems that have not been configured for remote disk access, the AgentUpdate pull program allows those systems to “pull” a copy of BlackICE Agent. The AgentUpdate program can be included in a logon script on a network server, so that Windows 9x clients automatically pull the software the next time they log in to the server. ICEpac documentation is only available on-line as PDF files, not as hard copy. The documentation is comprehensive, however, and includes a Getting Started Guide for the ICEpac suite, a User Guide for the BlackICE Agent, Administrator Guides for ICEcap and InstallPac, and a Reporting and Reference Guide for ICEcap. With the basic BlackICE Agent installation there is virtually nothing required in the way of configuration before the product will run. Whereas other IDS products require the administrator to define security policies containing the attack signatures to look for and the hosts to be monitored, BlackICE Sentry simply looks at every packet on the wire and always watches for every attack in its database. Although there is limited scope for configuration via the graphical interface, there are some key text-based configuration files that can be edited manually (by those who know what they are doing) to fine tune the operation of BlackICE. Whilst it is not possible to define new attack signatures per se (since BlackICE does not use pattern matching) it is possible to modify the behaviour of the protocol decode by defining new “rules” that can specify what objects or resources the engine should monitor. For instance, it is a simple matter to have BlackICE watch a specific file, directory or Windows registry key for tampering (and a number of sensible defaults are included in the standard configuration). It is also possible to alter settings such as failed login counts or SYN flood thresholds to suit the characteristics of your own network. It would be nice to see the GUI developed further to provide the means to modify these parameters within the application rather than via editing text files, however. The default installation includes a simple graphical interface on the host PC with a number of different tabbed views. The Attacks window shows details of all attacks including date and time, attack name, intruder ID, victim ID and a count of the number of attacks seen. Unfortunately, we found the count information to be one of the less accurate of the IDS systems tested, but this is not due to BlackICE missing packets. Because it is designed to operate at high speeds (it can handle 100 per cent network load of 148800 packets per second on a 100Mbit network) there is a certain amount of what is known as “pre-filtering” and “coalescing” of events when a serious attack is underway. The most obvious result of this is that multiple attacks will begin to be shown on a single line with a source IP address of 0.0.0.0 instead of on separate lines, and the count information seems to be approximate at best once this starts to happen.
Additional columns can be added to the Attacks display (attack parameters, attack ID, severity, etc) by right-clicking on the column headers, and columns can be re-ordered and re-sorted as required. Each severity level is colour coded (red, yellow, or green) and audio-visual alerts can be triggered at the console depending on the severity. By selecting any attack, a brief description is displayed at the bottom of the GUI. A more detailed description – including further reference material and occasionally suggestions for fixing the problem – can be obtained by clicking on the “Advice” button. Unfortunately, none of this information is installed locally – BlackICE has to go off to the Network ICE Web site to retrieve it (which might be a problem if the attack has brought down your Internet connection). The next tab is the Intruders display, which displays a list of attackers, together with any details BlackICE has been able to determine by means of “back tracing”. This feature, which can be disabled if performance is paramount, enables BlackICE to trace back to the attacker in an attempt to discover as much about him as possible. Along with the IP address (which could be spoofed, of course), BlackICE will display the DNS name, NetBIOS name, Windows Workgroup/Domain name, node name, and even the MAC address if they can be determined.
The third tab is the History tab, which displays graphs of attacks, suspicious activity and network traffic over a user-selectable period of time. When BlackICE installation is controlled by InstallPac, it is possible to install a “silent” version of the Agent with no GUI. This makes the Agent completely invisible to users of the host machine, whilst still allowing control of the Agent from the ICEpac management console. Unlike most other IDS systems, BlackICE also incorporates a firewall. This can operate as a personal firewall, with BlackICE Agent, or as a network perimeter firewall with BlackICE Sentry when installed on a dual-NIC host. There are two parts to BlackICE protection: the standard protection filter, and the dynamic protection filter. Standard protection filtering stops many common attacks before they can get started. This includes blocking corrupt packets, badly fragmented packets, and other potentially damaging transmissions. The standard filters include configurable filters for IP addresses, TCP and UDP ports. Dynamic protection filtering works much like an IP address filter used on routers and other network devices. When a malicious attack is detected, BlackICE adds the hacker’s IP address to a dynamic address table, following which, any traffic from the hacker’s IP address is rejected at the network stack level. Right clicking on any attack or intruder in the BlackICE display allows the user to immediately trust or block a user, and ignore or block an attack. Ignoring attacks or trusting certain IP addresses provides the means to run automated scanning tools on the network without triggering false alarms on all the BlackICE Agents. In addition to the trusting and blocking settings, the only other parameters that can be configured via the GUI interface relate to packet logging and evidence logging. When packet logging is enabled, BlackICE Agent records all system traffic into log files, the size of the files and rotation characteristics controlled via the Packet Log tab in the BlackICE settings. It is important to note that packet logging keeps track of ALL system traffic, not just intrusions, which can result in some large files. Packet logs are encoded as “sniffer” style trace files, and will require a decoding application (which is not included) to view the contents. If you want to be more selective in what is recorded, you can employ evidence files, which are also controlled via the BlackICE settings. Whenever an attack is detected, BlackICE Agent captures network traffic specific to the attack in progress and stores that information in an evidence file. These files also require a trace file decoder to view the contents. Although each BlackICE Agent or BlackICE Sentry can be managed via the GUI interface, larger networks will benefit from the use of ICEcap to centralise the management and reporting tasks, thus providing the means to track trends and issue network-wide security measures. Once an Agent has been configured to report to an ICEcap server it is no longer possible to configure anything locally. Centralised control also allows deployment of “silent” Agents with no GUI, making them invisible to the user of the host PC. The ICEcap Management Console is a flexible Web-based administrative system that integrates with BlackICE Agents, gathering, storing and analysing intrusion data from all the Agents on the network. Although the individual Agents will continue to report attacks on the local GUI (unless they are “silent” Agents), from a single browser-based interface the administrator can run security reports that show hacking statistics across the entire network. And because ICEcap has an “enterprise-wide” view of network intrusions it can identify hacking activities that a single BlackICE agent might miss. ICEcap can also command remote BlackICE Agents to block or permit network transmissions for a specific IP address or network port. For example, let’s say a hacker attempts to break into your web server. BlackICE detects the hacker, back traces his IP address and raises an alert. With a few configuration changes and the click of a button, a single network administrator can command all BlackICE agents on the network to block any traffic from the hacker’s machine. Even if the hacker should make it through the corporate firewall, none of the computers running BlackICE will allow the hacker access. Communication between Agents and the ICEcap server is ensured by regular transmission of encrypted HTTP packets between them, known as “heartbeats”. The bi-directional nature of these heartbeats could cause problems in some networks, however, particularly across dial-up or on-demand links which may only operate in one direction. ICEcap can be configured to show alerts as they are reported from the various BlackICE Agents around the network in the browser window. Since it is not always convenient to logon to ICEcap and pull up a report, however, ICEcap also includes a basic Alerter utility. The Alerter is a miniature browser window that checks the ICEcap server every ten seconds for an alert. When an alert is detected, the browser window flashes.
Computers can be logically bound together in Groups under ICEcap for administrative and reporting purposes, and the administrator can create Policies (which associate an event with a severity level) and Enforcements (which bind Policies to Groups). This allows certain events and hosts to be designated higher or lower priority as required. These policies are then automatically applied to all BlackICE Agents in a particular Group. When ICEcap issues an alert it can send an e-mail, a page, an SNMP trap, or invoke an executable file. Alerts are issued based on events received that meet the Alert Threshold defined for each account. Contacts identify what ICEcap should do when issuing an alert (for instance, defining the e-mail or pager address of the administrator for a particular Group), and it is possible to establish more than one contact for an account (which would allow you to send both an e-mail to the Group administrator, and a pager message to the ICEcap administrator for a particularly serious alert). Default Agent configurations can be named and saved within ICEpac too, allowing the administrator to specify all the parameters for how an Agent is installed on a remote system. This includes such information as default login account, installation path, blocked addresses and the state of features like� packet logging, evidence logging, back tracing and so on. The Agent Configuration Record (ACR) also allows the administrator to override the per-Agent text-based configuration parameters we mentioned earlier.
Once an ACR has been created and associated with a Group, it can automatically be distributed to the hosts within that group and installed – usually without even rebooting the target machines. Any number of ACR’s can be created and associated with Groups which can contain anything from one host to an entire subnet, thus allowing configurations to be applied in a fine-grained or broad-based manner as required. Changes to, and removal of, BlackICE Agents are handled in exactly the same way, allowing the administrator to handle all the installation, configuration, security and removal of BlackICE software from a single point. InstallPac can also be employed to achieve the same ends, but via a command line interface. Although there is extensive on-line help and the documentation is fairly good, we found the ICEcap interface to be confusing and not particularly intuitive. The biggest problem is with its Web-based nature which, although it does allow it to be run from anywhere on the network via a standard browser, makes it all too easy to get lost within the various screens as you follow the numerous hyperlinks. This is one area that could be improved. Having said that, the remote management, installation and configuration features makes ICEpac well worth the trouble to get to know. Without ICEcap, the BlackICE Agent or Sentry modules provide only the most basic reporting and alerting capabilities via the GUI interface. There is certainly no means to provide historical or trend reporting without employing the services of ICEcap.
All data is reported back to the ICEcap server under specific accounts. There is one master account – iceman – and only this account is capable of consolidating and reporting on data across all the other accounts. This means that it is possible to have different sections of your network reporting back to ICEcap independently of each other, and administrators in each of those sections would only be able to view their own data. Only the ICEcap administrator would have the capability to see everything. Reports are divided into interactive and periodic: interactive reports work on the live data, whilst periodic reports work from regularly scheduled “snapshots”. There are a number of reports available, including:
All reports are presented in a clear, easy to read tabular format in the browser window, and certain columns are re-sortable in ascending or descending order. This allows many of the reports to be edited “live” in order to present the information in the most meaningful format. Many of the entries on each row of the report are also live hyperlinks, enabling the administrator to drill down to acquire more detail. For instance, in a list of alerts, the victim’s IP address will be a hyperlink, and clicking on the link will bring up details of that particular host, whilst clicking on the hyperlink of the attack name will bring up detailed information on the attack itself.
Some fields will also contain a golden key icon. Clicking on this icon against the victim’s IP address will bring up another report detailing all the attacks made against that particular address. Clicking on the same icon against the attack name, however, will bring up a report of all the attack of that particular type made within the requested time period. This flexible means of resorting and drilling down into ICEcap reports makes for a powerful reporting environment. Once again, the use of the browser-based interface with multiple hyperlinks on a page can make it confusing when running reports. However, the biggest problem with ICEcap’s reporting is that the output is to the browser window only, with no means to provide a nicely formatted printed output or export facility. This is another area that requires improvement, although the actual content of the reports is more than adequate. Overall, ICEpac is an extremely impressive IDS, combining as it does powerful Network IDS and Network Node IDS components, along with firewall and remote management capabilities.� There are one or two minor niggles, such as the need for an improvement in the BlackICE Agent/Sentry GUI to allow more extensive configuration of the Agent software without having to resort to editing text files. We also found the browser-based interface in ICEcap to be confusing, and there is a definite requirement for a properly formatted printed output, as well as an export facility to other file formats. If we were to get really picky, we would like to see the detailed attack information installed locally rather than accessed purely over the Web, and feel that a product of this quality deserves a hard copy documentation set. But the most important part of any IDS is the ability to capture packets, accurately identify attacks and report on them, even under conditions of heavy load. This ICEpac does extremely well, thanks to the protocol analysis-based architecture and highly optimised network drivers. This meant that the BlackICE Sentry machines were capable of detecting all attacks, even with a network load of 148000pps on our 100Mbit test LAN, whilst the BlackICE Agent machines could handle high levels of attacks against a particular host without consuming excessive amounts of CPU power. This latter feature, together with the “silent” mode of remote installation via ICEcap, means that you could have a BlackICE Agent installed on every single desktop in your organisation and your users wouldn’t even know it. Highly recommended, and we are looking forward to seeing Agents appear for Linux (currently in the development pipeline) Company name:
Network ICE Corporation Network ICE
International and EMEA Headquarters Click here
to return to the Network ICE Questionnaire
|
 |
Send mail to webmaster
with questions or�
|
