 |
|
|
Symantec ManHunt (formerly from Recourse Technologies, who were acquired by Symantec mid-2002) is described as a �threat management solution� by its developers, rather than simply a Network IDS. It is currently provided as a software-only product for customers to install on their own hardware, or as a turnkey appliance via the Symantec partnership with Sun Microsystems. Symantec ManHunt combines network intrusion detection, and incident or event management capabilities in one product, providing a three-armed approach: detection, analysis, and response. The following diagram describes the general architecture:
Symantec ManHunt detects a variety of threats using a layered detection model that includes protocol anomaly detection (PAD), stateful signatures, custom signatures, and traffic rate monitoring. ManHunt can also integrate event data from third-party devices, and receives event data through mobile Switch Port ANalyser (SPAN) ports and network taps. Roaming detection interfaces enable ManHunt to provide wide coverage in a switched network. The various layers of the detection model are as follows: Protocol Anomaly Detection (PAD) - Protocol anomaly detection is performed at the application protocol layer and focuses on the structure and content of the communications. Many attacks target protocols such as Telnet, HTTP, RPC, SMTP, and Rlogin for example. When protocol rules are modelled directly in the sensors, it is easy to identify traffic that violates the rules, such as unexpected data, extra characters, and invalid characters. Protocol-based IDS have the potential to detect �zero day� exploits (i.e. exploits which have not been seen before) because they model the various protocols exactly as they are reflected in the RFCs. In addition, they are better able to model the �normal� way in which those protocols are used. Where a new attack violates the RFC or fall outside the norm in some other identifiable way, it will be flagged by ManHunt as an exploit without the need for a custom signature. Stateful signatures - Of course, not every exploit violates an RFC or even depends on a higher level protocol. Many exploits work at the network layer, for example, or will target a weakness within a specific application whilst fully conforming to the underlying protocols. The only way to detect such exploits is via some form of pattern matching. Stateful signatures provide just such a mechanism for detecting non-anomalous attacks. They apply to specific protocols and are updated by product upgrades. The mechanism works by passing packets to the protocol state engine, along with associated flow and state data. ManHunt then compiles state models to optimise executable code, and the engine iterates through the patterns one at a time, using a matching algorithm. Some data, such as partially matched patterns and payloads, can be stored for later use. Custom signatures - ManHunt provides the ability for the administrator to define and apply custom signatures. Based on a subset of Snort syntax options, the custom signatures provide a flexible mechanism for making short-term updates during rapid outbreaks. Custom signatures can be viewed and managed from the ManHunt console. Traffic rate monitoring - ManHunt sensors also incorporate a statistical or rate counter component to identify traffic shapes that indicate DDoS or flooding attacks. This element is designed to be self-tuning, recognising that different environments and even different organisations within an ISP or company infrastructure may experience vastly different types of traffic. Legitimate volumes of a certain type of event in one location would be considered a flood attack in another location. ManHunt detects malicious flow and traffic shape, tracks attacks back to their source to identify the ingress point, and communicates with upstream routers to continue tracking an attack beyond its domain. DoS detection - Passive traffic monitoring is provided on all detection interfaces to allow ManHunt to detect a variety of DoS attacks such as flooding, resource reservation, and malformed traffic. Scan detection - ManHunt detects a variety of reconnaissance efforts, such as various forms of port scans, stealth scans, ports sweeps, and so on External EDP - The Event Dispatch Protocol (EDP) provides a generalised framework for sending events to a ManHunt node for correlation, investigation, analysis, and response. Using EDP, ManHunt can collect security data not only from its own sensors, but also from third-party sources such as firewalls, IDS sensors, and host-based IDS devices. The process of integrating a third-party sensor generally involves three steps: collection, conversion, and transmission. First, the data is collected from the third-party sensor in its usual collection format, such as flat text files, SNMP, or via source APIs. Next, the data is converted from the native format to the ManHunt canonical form. Finally, the converted security data is transmitted to the ManHunt node. ManHunt provides event grouping, or correlation in real time, using a heuristic function to judge the similarities between events, based on multiple criteria such as time, type, location, source, and destination. The analysis mechanism consists of: Refinement - ManHunt detects both known and unknown (zero-day) attacks, using multiple detection technologies concurrently. Event refinement - a new feature - provides rules to extend ManHunt's Protocol Anomaly Detection capabilities to provide less �generic� alerts for certain exploits. ManHunt matches generic anomalies against a database of refinement rules and, for known attacks, reclassifies an anomaly event by retagging it with its specific name. This allows the administrator to see much more specific alerts from a generic protocol anomaly, but because refinement is done post-detection, this does not impact performance in any way. Aggregation - Aggregation includes collecting event data from third-party log files, SNMP, source APIs, normalising event stream via ManHunt Smart Agents (MSAs), and sending to the ManHunt node via an encrypted, authenticated protocol. This allows ManHunt to act as an aggregation point for multiple security devices. Correlation - Symantec ManHunt shares event and incident data between ManHunt nodes during cross-node correlation, and categorises events to incidents in increments for users to manage more easily. All events from both local and remote sources are collected by the event manager, which organises the events into a single, rate-controlled stream. It compares new events to existing event groups, using a scoring heuristic to judge similarity. All events and analysis results are written to a local database, evaluated against policy rules, and actions taken if appropriate. A response policy is a collection of rules configured to detect specific events, and to take specific actions in response to them. Response rules can be configured to react automatically and immediately to contain and respond to intrusion attempts, even if an administrator is not available. The response mechanism includes the following: Policy application - ManHunt applies policy on individual events that are either logged as new, or aggregated into an existing event. To do this, ManHunt iterates through the list of policy rules that have been defined by the system administrator, comparing each event against the configurable match parameters. If a match occurs on all parameters, it then executes the specified action. After ManHunt processes one rule, it proceeds to one of three alternatives: to the rule indicated by the Next parameter; to a following rule beyond the Next rule; or it stops policy application altogether for this event. Automated response - Symantec ManHunt's automated policy-based response system includes alerting, pinpoint traffic recording, flow tracing, session resetting, QoS ACL suggestion, and custom responses on both the ManHunt node and the ManHunt console. ManHunt generates responses based on multiple criteria such as event targets, attack types or categories, event sources, and priority or severity. The administrator can configure multiple responses for the same event type, and specify the order in which Symantec ManHunt executes the responses. The ManHunt console manages incident and event filtering, drill-down incident analysis, full packet capture, detailed event descriptions, and allows event annotations and incident marking for incident tracking and management. The console provides an interface from which the administrator can monitor events and devices, edit parameters, configure response rules, view log data and generate reports. Four pre-defined roles provide granular management. Roles are sets of permissions for specific management operations, and each user's login identity determines their role and permission assignment during an administrative session. ManHunt installs with a SuperUser account, which includes permissions to configure user accounts, topology objects, response rules, custom signatures, configurable parameters, reporting, and redundancy to the master node. The StandardUser account (also installed by default) includes permissions to read events, incidents, topology map, policy information, reports, logs, and custom signatures, but allows only limited ability to configure them. The SuperUser can add users with two additional pre-defined roles: Administrator and RestrictedUser. The ManHunt console enables encrypted and authenticated communication using password-protected 1024-bit Diffie-Hellman key exchange and 256 bit AES encryption. The ManHunt node contains a variety of tools and techniques that work together to gather attack information, analyse the attacks, and initiate responses appropriate to specific attack circumstances. The following diagram illustrates the basic architecture:
The components of the ManHunt node architecture include: Alert Manager - The Symantec ManHunt Alerting Manager provides three types of alerts or notifications: a console action alert, an e-mail alert, and an SNMP trap alert. Sensor Manager - The Sensor Manager maintains a pool of sub-processes to manage sensor-related functionality. This includes sensor processes for event detection, traffic recording, and FlowChaser sub-processes that handle network device configuration, start, stop, steering, and TrackBack, a response mechanism that traces a DoS attack or network flow back to its source.
Handoff Manager - ManHunt nodes in separate clusters use the Handoff Manager to communicate with each other. The Handoff Manager alerts ManHunt nodes in separate clusters or autonomous systems of possible attacks so those nodes can coordinate attack responses. The Handoff Manager provides the attack information in a secure computer-readable message for automated handling, and in a human-readable message, that is particularly useful if the connecting network does not have a ManHunt node. Only the necessary information is passed across network boundaries, so as to avoid compromising security at any particular point. The Handoff Transmitter and Receiver are components of ManHunt that communicate with peer ManHunt modules either within a network or intranet, or between autonomous systems. When the source of an attack is from outside the local network, the Handoff Transmitter can send notifications about the attack to a peer ManHunt in the upstream administrative domain. The Handoff Receiver in the upstream peer ManHunt receives the event data and passes it along to its own Analysis Framework. The peer ManHunt Analysis Framework then picks up where the original ManHunt left off, and gathers and processes further information about the attack. In some cases, a Symantec ManHunt node cannot communicate directly with another Symantec ManHunt node, such as if the firewall does not allow UDP traffic. In these cases, the node communicates via email to inform the SuperUser or Administrator in the upstream network that an attack has been tracked to that network. Authentication between nodes in separate Manhunt clusters during handoff is conducted securely via the use of digital certificates. ManHunt nodes in separate clusters or autonomous systems must register with one another to verify their identities before they can handoff messages to each other. The digital certificate enables each host to verify its identity to the other. Administration Service - ManHunt sends secure communications during an attack using multiple methods - the QSP Proxy within a cluster, and the Handoff Coordinator between separate clusters. The QSP Proxy is a proprietary protocol that enables secure, encrypted communication between the master node and the ManHunt console, and between ManHunt nodes within the same cluster. Analysis Framework - Because ManHunt nodes have access to information collected by other ManHunt nodes - and even other IDS systems deployed on the network - attack analysis and response can be coordinated across a distributed network, enabling a rapid global attack response.
The ManHunt Analysis Framework (AF) aggregates event data on possible attacks from all event sources. This means that multiple related events are correlated and presented as a single �incident� at the console, making it much easier for the administrator to sort high priority alerts from those which are less important. The Analysis Framework also performs statistical correlation analysis on events to identify event patterns that vary significantly from usual network activity and to identify individual events that are highly related, such as a port scan followed closely by an intrusion attempt. The grouping of several low priority alerts together in a single incident - based on event type, source or destination - thus makes it easier to spot when several exploits are being employed one after the other in a concerted attack. When an event is received from the sensors, the Analysis Framework considers its characteristics to decide if it is part of an existing incident. If it is, it is added to that incident - if not, a new incident is created. All further analysis is then based upon the current incidents and not on the individual events. If no new events are added to an incident for a predetermined period of time, the incident expires and is moved to the historical incident list. Incidents are extremely valuable in the determination of malicious activities because individual events may or may not be important by themselves, until other related events take place and build a profile of activity. For example, a port scan is not an important enough event to send a notification at 3:00 in the morning. But, rather than throwing away that information, an incident will hang on to it to see if more activities follow. An invalid login on an open port also is not necessarily a significant event. Incidents allow these activities to be associated such that the priority may be increased. After a certain number of invalid logins, the priority for the incident may be high enough to take action. This allows for a much more granular approach to attack response, so that no one is bothered when the threat severity is low, but resources can be allocated rapidly when necessary. Databases - ManHunt uses multiple databases to store information about attacks, the network topology, and configuration information, including:
Event Stream Provider - The Event Stream Provider (ESP) prevents flood invasions by categorising events and treating them as a single unit when it sends them to the Analysis Framework to be analysed. The ESP can also monitor bi-directional traffic. When the ESP monitors an event, it generates a message hash and a destination hash of the event. The ESP uses the values of these two hashes to select the queue into which to place the event. The ESP then pushes the queued events to the Analysis Framework at a rate configured by the administrator. The ESP checks each queue in turn and pushes one event to the Analysis Framework from each queue containing events. Given this architecture, if multiple identical events bombard the network, as in a DoS attack, ManHunt will assign the same message and destination hashes for all of the DoS attack events and place them in the same queue. This prevents the Analysis Framework from becoming overloaded with the DoS events, because the ESP sends only one event at a time from each queue. If there is an attack hidden beneath the DoS attack, the message and destination hashes for the events related to the hidden attack will differ from the DoS event hashes. The ESP, therefore, places these events in separate queues. The Analysis Framework can then analyse the events related to the hidden attack. Sensor - The ManHunt sensor handles many of the tasks associated with detection, such as packet capture, flow assembly, and lower-level packet analysis. The sensors allow ManHunt to effectively monitor many ports, either by monitoring a hub, or by monitoring one or more SPAN (Switch Port ANalyser) ports. ManHunt is capable of controlling certain switches directly and so can reconfigure SPAN ports dynamically (varying the ports which are mirrored to the SPAN port as required), or �roam� from SPAN port to SPAN port using a single sensor. Roaming is a method where 100 per cent of traffic on a port may be monitored for a period of time, generally providing at least enough time to evaluate the full state machine of all communications on that port. If there is nothing of interest taking place on that port, ManHunt will select another one to monitor. The selection of the subsequent port is based on a combination of random numbers and the user-configured priority of the port. By selecting a higher or lower priority for a port, in relation to others, resources are focused exactly where they are needed.
Roaming is a powerful option that gives ManHunt users tremendous flexibility in how resources are distributed for maximum security coverage with minimal resources, since it is possible to monitor multiple switches and SPAN ports using a single NIC in a single sensor. Roaming port monitoring may be used in combination with static port monitoring, and in whatever quantity is supported by the monitored switch. MSA Receiver - The MSA Receiver enables ManHunt to accept event data in real time from external sensors, such as a Symantec Decoy Server, as well as from third-party sensors (either directly, via a custom agent, or via SNMP traps). The MSA Receiver collects event data from log files, SNMP, and source APIs, and then sends this data to the Analysis Framework for aggregation and correlation with all other ManHunt events. ManHunt Smart Agents (MSAs) enable ManHunt to collect data from third-party host and network IDS products as well as other Symantec products, including Symantec Host IDS, Symantec Decoy Server, Snort, ISS RealSecure, Enterasys Dragon, Cisco IDS, Check Point Firewall-1, NetScreen, Cisco/Okena Stormwatch and Tripwire. Using MSAs as the bridge between ManHunt and other intrusion detection and firewall products, management of events and incidents can be centralised from the ManHunt console. FlowChaser - FlowChaser serves as a data source in coordination with ManHunt's TrackBack (a response mechanism that traces a DoS attack or network flow back to its source) and Handoff (a negotiation mechanism between peer Symantec ManHunt nodes). FlowChaser receives network flow data about attacker and victim hosts from multiple devices, such as ManHunt's sensors and Availability Monitor, and Cisco/Juniper routers. FlowChaser stores the flow data in an optimised fashion that the analysis and correlation engine uses to accelerate TrackBack, DoS protection, and advanced responses. FlowChaser also recommends Quality of Service (QoS) measures to take if the availability of network resources suddenly falls, to allow discrimination in favour of historical traffic. FlowChaser accelerates TrackBack's functionality, the response mechanism that traces a DoS attack or network flow back to its source, regardless of forged IP source addresses. Providing a company has the cooperation of peer ISPs, TrackBack can trace an attack that originated beyond the edges of the corporate domain. When ManHunt detects suspicious traffic that matches trace criteria, it initiates FlowChaser to track the attack back to the ingress point of the enterprise network. ManHunt forwards the attack data to any ManHunt installations in cooperating upstream ISPs, using Handoff to communicate securely across the administrative boundaries. The upstream ManHunt automatically continues to trace the attack flow to its source. ManHunt can also send copies of the flow data to the upstream ISP ManHunt node. Within a network, multiple ManHunt nodes can work together across multiple network segments and network locations - this is called a ManHunt cluster. Attack data is correlated across all ManHunt nodes in the cluster. By default, the first ManHunt installation in a cluster is designated to be the primary master node, and all subsequent ManHunt installations are designated to be slave nodes. Changes made on a master node will propagate automatically to all other nodes in a cluster. It is possible to configure slave nodes to be master nodes after they have been installed. These master nodes can then be designated as sync nodes to help distribute the database synchronisation load, as well as provide backup administration if the primary master node fails. All ManHunt nodes in the cluster can be administered from a single administration console. From this same interface, the system administrator can also view all attack activity being logged by any ManHunt node in the cluster. Although it is possible to run more than one master node in a cluster, only one should be used as the administration node on which the topology tree, policies and cluster configuration parameters are updated. Care must be taken with a multi-master configuration - especially where different administrators administer different nodes - since it is possible for one master node to overwrite changes made on another master node in the same cluster. To maintain the integrity and usability of the log files, ManHunt nodes can participate in time synchronisation with other nodes in the cluster. One point worth bearing in mind is that ManHunt is a two-tier architecture - unusual amongst today�s IDS products. Each ManHunt sensor stores its own configuration and alert data locally. The clustering feature takes care of replicating topology and configuration data throughout the system, whilst viewing alerts and running reports requires the central Console to retrieve data from multiple sensors each time a query is run. Symantec is intending to introduce a three-tier architecture management system in a future release. ManHunt provides the ability use backup ManHunt machines to ensure constant coverage in the case of unforeseen failures. A common fail over group deployment would have a master ManHunt node as the dominant node and a secondary master node as the backup node. The backup node will process the same data, perform the same analysis, and evaluate the same response policies as the dominant ManHunt node, but it will not execute duplicate responses. If the dominant node fails, the backup node becomes the new master. To communicate with the backup nodes, ManHunt uses a fail over heartbeat protocol which is transported using AES-encrypted, authenticated tunnels. ManHunt is primarily a software product that requires a dedicated machine - a supported Sun Solaris SPARC, Solaris Intel or Red Hat Linux platform. Symantec has also established a partnership with Sun Microsystems a ManHunt-based appliance called the iForce IDS Appliance. We installed ManHunt on a dual 2.4 GHz Xeon processor Dell PowerEdge 2650 with 4GB RAM and a dual copper port Intel/Pro-1000 card used for sniffing. The recommended hardware is a function of the amount of traffic to be monitored and the network configuration. The sensor will contain a primary network interface that will be used for administrative communication as well as communication with other ManHunt nodes and various network devices, as necessary. There will be additional network interface cards (NICs) installed in the host machine, including Gigabit interfaces to monitor Gigabit links, connected directly to monitored switches. The number of additional interfaces depends on the number of devices to be monitored, as well as the capabilities and limitations of the hardware. Up to twelve Fast Ethernet or six Gigabit Ethernet network cards can be installed in a single ManHunt Sensor. Combine this with the port roaming capability and it becomes feasible to monitor an entire multiple switch network from a single point. The ManHunt node software and administration console should be installed on separate machines. Threat analysis is done on the ManHunt node, and therefore it is recommended that it is installed on a dedicated multiple-CPU computer in order to provide optimum performance. The ManHunt installation process itself is reasonably straightforward, especially when the excellent Installation Guide is followed to the letter. The installation and hardening of the underlying Solaris operating system is by far the most time consuming part of the entire operation when installing a sensor. Installation of the Java-based management GUI is also a simple task, which can be performed on one or more Windows clients located on the same administrative network as the ManHunt sensor(s). One small improvement we would like to see would be a dedicated administrative account on the sensor which restricts the administrator to a text-based menu system for basic network configuration tasks - at present, setting IP address and default gateways for the management interface is more difficult than it should be. It is nice to see that for Version 3.0, Symantec has done away with the iButton �dongle� which used to provide authentication and license functions. Both licensing and inter-node authentication are now handled adequately via software. The Installation Guide and Administration Guide are provided as both electronic and hard copy versions, and the quality of the documentation is, overall, excellent. Both manuals are extremely comprehensive, well indexed, and very easy to read. With previous versions of ManHunt which relied totally on Protocol Anomaly Detection (PAD), the product was one of the easiest IDS� to configure that we have come across - real plug �n� play stuff. Now, of course, with the use of hybrid-mode signatures to broaden signature coverage, it is up to the administrator to determine which signatures should be applied to which sensors. However, providing the underlying hardware platform has enough power, there is little more to be done than simply selecting all signatures and leaving the PAD to get on with what it does best. Things are complicated slightly when there are multiple sensors installed, but this is because of the network-oriented configuration required to support the correlation engine. The Java-based Administration Console has two main tabs, headed Monitored Devices and Incidents. The Incidents tab, as its name suggests, is used to monitor individual alerts and incidents. The Monitored Devices tab is used to monitor the performance of individual ManHunt Sensors (displaying aggregate bit rate, aggregate packet rate and percentage of packets dropped), as well as to configure the topology of the network on which the ManHunt sensors reside. In addition to information on its own network, each ManHunt node also requires relevant data regarding connections to other networks, whether they are autonomous systems or other portions within a distributed network. In a large distributed implementation, the population of the network topology tree, if done properly, is probably the most arduous task faced by the ManHunt administrator. There is no auto-discovery process, and so all the information needs to be entered by hand, and maintained in the same way as new sensors, switches, hubs and subnets are created or relocated.
The ManHunt administration console displays the network topology as a tree with nodes representing the following:
The network can be mapped logically (such as by department) or physically (such as by building), and it is necessary to include nodes for all devices and device interfaces that ManHunt should monitor, as well as all those through which ManHunt should be able to track attacks. The topology database must be populated on a master node, which subsequently synchronises the databases on all other nodes in the cluster to the master�s topology database. This means that even for the largest distributed network, the topology database needs defining in one place only. It may seem superfluous to have to define actual network devices such as switches and routers rather than simply defining the ManHunt nodes and the subnets they will monitor. However, ManHunt is capable of some clever trickery when it comes to network devices. ManHunt divides switches into three categories: steerable SMON, steerable non-SMON, and non-steerable. ManHunt can roam over the interfaces on the SMON and non-SMON switches by logging into the switches and setting monitored interfaces on the various interfaces. �Non-steerable� means that a monitored interface has been set manually on the switch and the administrator does not want ManHunt to log into the switch. It is also possible to define external sensor nodes - ManTrap deception hosts or other IDS systems for example - from which ManHunt can accept and correlate security events.
Once the topology database has been populated, the bulk of the configuration work is done. The other main configuration step is to configure the response policies which determine how the Manhunt system responds to individual alerts. Any number of response rules can be created, each one matching on source, destination, event type and priority. When a response rule matches, an alert is sent to the ManHunt Administration Console and one of several additional actions can be taken:
Any number of response rules can be created, and although each rule can only have one response, the rule base is traversed from top to bottom whenever an alert is raised. This means that multiple rules - triggering multiple responses - can be matched for a single alert. It would be nice, however - and much easier - to allow each rule to have more than one response allocated to it.
To trace an attack back to the source, ManHunt uses a component called FlowChaser to retrieve the NetFlow data provided by Cisco routers to accomplish flow detection and analysis of the flow. Detection sensors will be typically connected directly to switch ports within the network infrastructure and can dynamically reconfigure monitored interfaces as necessary if the switch is SMON capable (this can also be achieved via Telnet or SSH where supported by the switch). The Cisco NetFlow technology is a proprietary source of device information that provides the metering base for a key set of applications including network traffic accounting, usage-based network billing, network planning, network monitoring and data mining capabilities for both service provider and enterprise customers. ManHunt�s FlowChaser uses the NetFlow data to provide TrackBack with additional traffic shape information that is analysed to quickly determine the ingress point of a DDoS attack within the network infrastructure. The tracing functionality in FlowChaser is designed as an additional analysis tool to aid in the automatic trace back of flow traffic generated by an attacker. In the ISP or enterprise environment, the FlowChaser uses its knowledge of the network topology to make intelligent decisions regarding which devices to interrogate about the attack stream. Rather than eliminating possible paths, it simply prioritises them using minimal resources and minimises impact on the processing of normal network traffic. The tracing feature can supposedly deal with DDoS attacks in which data streams are directed towards a victim from multiple locations, usually with untraceable forged IP source addresses. Unfortunately we were unable to evaluate this fully in our test environment. As far as configuration goes, there is not much else to do. There are a couple of parameter screens which enable the administrator to define such things as maximum log size, sensor alert delays (to prevent flooding), and maximum event per incident on both a global and a per-sensor basis. These screens are also where the administrator will switch on and configure features such as fail over, TrackBack and FlowChaser. Having configured the topology and response policies, all the changes are propagated to every slave node in the cluster automatically. Changes only need to be made in one place for them to be available from every administration console in the organisation. Despite the fact that there is extensive configuration required for the topology database, there is not much to do in the way of configuring clusters. All that is really required to make two nodes part of a cluster is to allocate the same management port and password to both of them. The administrator authenticates to the Administration Console using a login name and password, and specifies the IP address and management port of the master node. All other nodes using the same port and password combination are automatically available to be managed from that console. If it is required to manage another cluster, it is necessary to initiate another instance of the console, and log in to a separate master node with a separate management port and set of login credentials. Four different user levels provide varying degrees of access to the Console and ManHunt configuration data. ManHunt relies on protocol anomaly detection and the various state engines, one each for:
No configuration is required - or possible - for these state engines, and performance is completely unaffected by all of them being active all of the time. The problem is, of course, that not all attacks exploit anomalies in the various network protocols. Some may exploit lower level vulnerabilities, whilst others may target vulnerabilities in applications. For this reason, ManHunt provides hybrid mode operation of each sensor (one of the few configurable parameters regarding the sensor itself). The configuration of hybrid mode is one of the things that has been improved significantly in the latest release. Gone is the clumsy method of pre-compiling the signatures and loading the resulting file into the sensor. Instead, hybrid mode signatures are now contained within one of the main databases, and are automatically compiled and deployed when selected for each sensor. These signatures are now distributed as part of the normal signature update packs, and are automatically loaded into the ManHunt database via the normal sensor update operation. Although these rules are based on the popular Snort rule language, not all of the Snort keywords are currently supported. Some work is therefore required to tweak standard Snort rules before they can be compiled by the ManHunt rule compiler. Administrators who wish to write their own signatures will also find that the ability to load custom signatures into the ManHunt database has been streamlined in a similar way, whereby the administrator simply selects a text file containing his signatures and loads them via a manual update procedure within the Console.
Once the signatures are loaded into the database, they are available for selection. Signatures are divided into groups of exploits (HTTP, FTP, SMTP, and so on), and it is possible to select and deselect individual signatures, entire groups, or the complete signature library. One slight omission here is that custom signatures are not placed in a �Custom� group, meaning that to enable or disable the entire group of custom signatures can require a significant number of mouse clicks. Another, more major, omission is the lack of any form of policy definition. Signature selection and deployment is purely on a per sensor basis, which can be quite repetitious with large number so sensors, especially if each sensor requires slightly different signatures depending on its location or function. It would be far more efficient to allow the administrator to create policies, each with different signatures enabled depending on the intended use for that policy - DMZ, Apache Web server, IIS, Web Server, and so on (or perhaps just a single policy for the entire organisation). Those policies could them be applied to sensors in a single operation. It is early days for the use of signatures of this type within ManHunt, and we are informed that improved policy creation capabilities are planned for the next release. One thing we did notice during this round of testing was that now that there are over 300 signatures supplementing the operation of the PAD engine, there is a noticeable impact on performance when all those signatures are enabled. Whereas previous versions of ManHunt could handle Gigabit traffic levels with relatively low-powered hardware, that is no longer the case (unless you wish to use PAD only, of course, and ignore the hybrid mode signatures). However, the dual-processor Dell PowerEdge 2650 provided as the platform for this test coped admirably with all our test scenarios, even with all hybrid-mode signatures enabled, and this is the minimum level of hardware we would recommend to handle a saturated Gigabit network. Once the console has been fired up, the Monitored Devices tab provides a quick view of all incidents currently occurring at and under the location node currently selected in the topology tree. It is possible to restrict individual Consoles to viewing events from certain ManHunt nodes only.
The Incidents tab provides the main view on current and previous incidents, both active and idle. Incidents are actually a collection of individual events, grouped together by the ManHunt correlation engine based on a sophisticated algorithm that takes into account things like event type, source, destination, and so on. The result is a vastly reduced amount of information for the administrator to sift through in order to determine the most important events to be investigated. Even though individual event types can be quite different, ManHunt is reasonably adept at determining which of them are related, and raising the priority and response status depending on how an incident develops. The top level heading of each incident always reflects the highest priority event within that incident. For example, low priority port scans and other reconnaissance probes are usually followed by more invasive probes, and eventually by a serious exploit attempt. ManHunt will consider port scans as low priority, and - depending on the response policy in place - will usually not alert the administrator directly. As the intruder moves on to more invasive techniques, however, the overall priority of the incident may be raised to a level which causes an e-mail or pager alert to be raised. This correlation is performed across all ManHunt nodes in a cluster, and this - coupled with the lower incidence of false positives thanks to the protocol anomaly detection - makes the product one of the more useful IDS in terms of alert handling. Active incidents are those to which new events are still being added. Incidents to which no new events have been added for a given amount of time are considered idle, so ManHunt closes them. The display can be filtered to exclude closed events if required, leading to an uncluttered display of data which is of immediate interest. The closed events remain available for further analysis if required, and can be restored to the main display at the click of a mouse button.
The Incidents table allows the administrator to view incidents detected by all ManHunt nodes or only those detected by a particular ManHunt node. Information displayed includes date and time, event type, source, destination, event count, priority, device, and current state (active or idle). To keep track of which incident descriptions have been viewed, it is possible to select the Mark Incident check box in the Incident Details dialogue. The Marked column of the incident will then display a red hash mark to indicate that it has been viewed. Selecting any incident from the Incident Table lists all the events that make up that incident in the bottom half of the Incidents screen. A single line is displayed for each event, consisting of date and time, event type, source, destination, priority, severity, reliability, event number (within that incident), and a unique incident ID. The priority level is a function of the severity and reliability levels. An incident's severity is a measure of the potential damage that an incident can cause, whilst the reliability level indicates the level of certainty that a particular incident is actually an attack. If the incident is merely suspicious, then its assigned reliability level is low. If ManHunt collects more data on the incident to substantiate its reliability, the reliability is adjusted upward.
Double-clicking any individual event brings up the event details dialogue. This repeats all the event details from the list on the first tab, along with a list of the source and destination IP addresses and ports that have been involved in that incident. If flow status collection is enabled on the monitored interfaces, then ManHunt can also display information about network flows to and from each address. The Advanced tab shows detailed packet content data, whilst the long description shows in-depth exploit info, with cross reference links such as CVE, BugTraq, etc. ManHunt provides an extremely intuitive means to drill down quickly from high level data to packet contents, allowing an administrator to investigate incident and events in detail and with a high degree of effectiveness. Where events are determined to be false positives or not worthy of further investigation, it is possible to add them to the Drop Filter List. This instructs ManHunt to completely ignore that particular event from that point onwards, and can be achieved by manually editing the Drop Filter List text file, or by filtering a particular event from the event details dialogue. Events can be filtered on event type, source or destination. Note that a drop filter does not prevent ManHunt from analysing a particular event on the wire, it merely prevents it from being reported to the Console. Another extremely useful event management feature is the ability to annotate incidents and events. Administrators can add multiple comments to incidents and events by clicking the Annotation button in the Incident Details or Event Details dialogue respectively. Each annotation is time stamped and lists the author of the annotation. If there are multiple annotations for an event, they can be sorted by time stamp in ascending or descending order. The Annotation box in the Annotation dialogue displays a default template which prompts for information, such as ticket number, owner and the last action taken in response to the event. Note that all the event and incident data is actually stored on the individual ManHunt nodes and is only transferred to the console as required for alerting and reporting. This can make some operations very slow as a console attempts to gather large numbers of incidents and events from multiple ManHunt nodes across a network. The upside to this approach is that with no single central database there is no single point of failure or single performance bottleneck. Another advantage for those organisations that have round the clock incident monitoring on a �follow the sun� basis (i.e. in different time zones) is that any administrator logging on to a cluster from any console around the global network has instant access to the identical data that was being worked on by all the other administrators before him. All in all, the incident handling capabilities of ManHunt are very impressive. The ability to handle large quantities of data are vital in a Gigabit IDS system, especially when it is possible to include events from third party sensors, and ManHunt acquits itself with honours in this area. Summary reporting is well catered for within ManHunt, with a range of built in graphical and text reports, though it is not possible to customise them in any way (other than to select a date range). For more detailed reporting, data can be exported to a SQL database. Any ManHunt node can generate daily e-mail reports that contain detailed incident log information for all ManHunt nodes in the cluster. The report time period is always the last 24 hours leading up to the report generation time. The e-mail reports include the following information:
Reports generated at the Console consist of data collected from all ManHunt nodes in the cluster. The data collection is performed as the report is running, and so can be quite slow when large numbers of nodes are involved.
Most reports are presented in graphical format initially, with a choice of bar charts, column charts or pie charts. Selecting any one of the columns of data on a chart allows the administrator to drill down to the next level. If, for example, the report is Incidents Per Month, selecting one of the individual columns drills down to that particular day and presents incidents per hour. Selecting one of the columns on that graph will drill down to the incidents that occurred within that hour, from where it is possible to generate other drill-down reports, such as a Top Event Types report to view the types of events that occurred most frequently during that hour. Eventually, it is possible to drill down to the individual incidents and events. This approach makes it very easy to filter out unnecessary data and quickly drill down to the data which is of most interest, providing a more focussed level of detail. All console reports can be printed directly or saved as HTML, PostScript or PDF files if required. A new feature in this latest release enables multiple report schedules to be created to run reports - either singly or as groups - at regular intervals. Scheduled reports run directly on any ManHunt node in a cluster, and the finished reports can be e-mailed to an administrator or secure copied to a report server elsewhere on the network. Regardless of which node is running the reports, ManHunt gathers data form all nodes to generate a comprehensive cluster-wide report.
Reports available include:
There are two active logs used by ManHunt - incidentdb and eventdb. The incident log contains incident end event entries which indicate the end of attacks. The event log contains all sensor event data. The event log is also signed periodically and can, therefore be verified at any time to ensure the log has not been tampered with or altered in any way. Command line tools are provided to view the logs on the ManHunt node, convert them to text, or export the data to an Oracle database for further analysis.
Both the incident and event logs are periodically rotated and/or compressed based on the file size or cron job entry. ManHunt manages to combine very high levels of performance with an excellent correlation engine and good reporting and analysis capabilities across multiple sensors. The ability to correlate data from third-party IDS and firewall products makes it particularly attractive in larger enterprise deployments, whilst the reduction in false positives and enhanced protection against zero-day exploits offered by the protocol anomaly detection architecture makes it attractive in any environment. Signature coverage has improved significantly for this latest release with the incorporation of a number of stateful signatures out of the box, and new ones appearing at regular intervals via the standard update procedure. Stateful signatures are used by Symantec to provide coverage in areas not suitable for pure Protocol Anomaly Detection, as well as to offer a rapid response to new exploits prior to updating a protocol engine. The downside to the more widespread use of these signatures is the requirement for a more powerful hardware platform (as well as an increased propensity for raising false positive alerts). It is nice to see that since Symantec took control there has been a reduction in price at all bandwidth levels, though it is more significant at lower levels. The price of the higher bandwidth licenses, however, need to be balanced against the possible port density. With a maximum of six monitoring ports for the 1Gbps license, for example, the price per port is less than $11,000. Of course, if you only require a single monitoring port, the 1Gbps and 2Gbps licenses can still appear on the high side. ManHunt�s greatest strength lies in its incident management capabilities. The tremendous challenge of sorting through volumes of network traffic requires an organisation to more efficiently manage the flow of incident information. ManHunt's correlation engine combines multiple events from multiple sensors into single incidents, making it much easier to sort genuine alerts from the irrelevant. The TrackBack and FlowChaser features are interesting, though they may be of limited use in smaller deployments of the product. The ability to annotate, mark and sort incidents with ManHunt provides the security specialist with the means to effectively identify specific incidents that have been resolved and remove them from the current �view�. This provides a form of incident �To-Do� list, and clearly indicates incidents that require immediate attention. Annotation capabilities allow an organisation to more thoroughly track the progress of investigation into an incident, even when that investigation is spread across multiple administrators and multiple time zones. ManHunt rates as a true Gigabit IDS product in our tests, although performance is only part of the story with Gigabit IDS. Given the potential volumes of traffic that will be seen on high speed networks, and the resulting volume of alerts that could be generated, the ability to more effectively manage those alerts is essential. ManHunt has one of the better approaches to this problem, and is worthy of consideration for any large scale IDS deployment. Company
name:
Symantec Corporation |
Send mail to webmaster
with questions or
|