 |
|
|
Dragon Sensor is a packet-based Network Intrusion Detection System (NIDS) based on the Unix platform. Originally from Network Security Wizards, the product is now supplied by Enterasys (a Cabletron company), and is distributed in the UK by Portcullis Computer Security Ltd. As of version 4.2, the supported operating systems consist of several Unix variants on both the Intel and Sparc platforms, including FreeBSD, OpenBSD, Linux, HP-UX and Solaris. Network media supported include Ethernet, FDDI, ATM and Token Ring. A host-based version of the product � called Dragon Squire�� is also available, but was not put forward for testing. Dragon Sensor switches the host network card into promiscuous mode in order to collect all traffic from the subnet (or switch port) to which it is attached. At a high level, Dragon takes two configuration files named dragon.net and dragon.sigs and uses them to determine rules for saving captured traffic for local logging to the hard drive.
It is important to note that Dragon uses local network APIs to collect traffic and not third-party libraries such as libpcap, and this provides it with very high levels of performance. Dragon can also operate in a �stealth� mode, when it is deployed on a host PC with two network interface cards. The IP stack can be removed from the monitoring interface, making it very difficult to detect with remote IP scans or target with DoS attacks. The second interface connects to a secure out-of-band network with the IP protocol. And this is used for management and reporting. It is possible to employ a single Dragon Sensor in a stand-alone mode and manage it either from the command line or built-in Web interface. Reporting can also be carried out on the Sensor itself, and this makes it a good choice for those organisations wishing to place a single network sensor on a shared segment. However, most organisations will deploy multiple Sensors across multiple routed or switched subnets or ports, and so the ability to control a number of Sensors from a single central console is important. This is provided via the Dragon Rider component, which consists of a client for each of the remote Sensors and a Server component. These are used to forward events to the central Server and send configuration information down to the Sensors. According to �official� sources, a target ratio to ensure reasonable performance is 25 Sensors to one Server. However, ratios of 200 to 1 are currently employed out in the field � your mileage may vary. Communications between the client and server components are encrypted using the Blowfish algorithm, secured by a shared secret key specified at install time. Client-server communications occur over fixed TCP ports which can be changed at install time, and the Dragon Rider server also includes IP-level security to protect against spoofed IP connections. It is important to keep the Dragon Sensor host secure, since neither the shared secret file nor the Dragon database are encrypted. Once the Dragon Client engines connect to the Dragon Server, it is possible to deploy the two key configuration files from a central location to all Sensors on the network. As the Sensors detect potential attacks, they will send the appropriate alert events back to the Server as they occur, and as fast as possible. The down-side to this approach is, of course, that if a network is under attack, the frantic reporting of alerts from Dragon Rider Client to Server will obviously burden the network with an additional load right at the point it could do without it. If a link fails or simply becomes congested, however, the Dragon engines will attempt a configurable back-off approach for reconnection. Once alerts have been received by the Server, they are stored in date-named subdirectories under the /usr/dragon/DB directory. From here they can be processed by the numerous command line analysis tools that make up the Dragon IDS package, or via the Dragon Fire Web interface. In the standard Dragon package, there is currently no way to consolidate reports across multiple Dragon Servers. Portcullis � the UK distributor - is working on an additional reporting tool (in beta at the time of writing) to provide just such enterprise-wide consolidation capabilities, and this will find its way into the standard Dragon distribution once released. Heartbeat packets are transmitted between Dragon Rider Clients and Servers at regular intervals, ensuring that the administrator quickly finds out should a Sensor suddenly become unavailable for any reason. The same heartbeat packets are also used to transmit Sensor performance statistics to the central console. Installation � whilst not quite the InstallShield we know and love from the Windows world � is very straightforward even for those with limited Unix experience. The documentation is truly excellent, the user guide covering all the Dragon components and provided in both hard copy (well done Enterasys) and electronic formats. The sections of the manual covering Dragon Server and Sensor are particularly extensive, provided a wealth of detail on all the configurable parameters of the Dragon system. Installing the appropriate package for your Unix environment (ours was Red Hat Linux 7.1) creates the directory structure and places the files appropriately. A Perl install script is created for the Dragon Rider components and it is important to use the installation script provided so that a preliminary configuration file is built. After the installation, however, the configuration can be modified by editing the Dragon Rider client configuration file (driderc.cfg) if required. For anyone au fait with Unix and happier with a command line than a GUI, Dragon can be configured and run entirely from the command line if required. For mere mortals, a Web-based interface is provided, and this in itself is split into two separate components: Dragon Rider for configuration and Dragon Fire for reporting. Dragon Rider provides a Web-based administration interface to the Dragon Rider Server component, enabling remote Sensor (both network and host based) configuration and performance reporting. The first task can be a bit laborious in large networks, in that it is necessary to manually add details of each Sensor to the Dragon Rider console � it would be nice to see some form of auto-detection here to ease deployment across larger networks.
There is a comprehensive range (over 1050 at the time of writing) of attack signatures available within dragon. These signatures identify unique data patterns in network traffic which can be used to identify network attacks, misuse and vulnerabilities, and a subset of these can be applied via the dragon.sigs file. It has to be a subset, because each Sensor can have a maximum of 1500 signatures applied to it, and this limit is hard coded. Now that the �master� library contains over 1100 signatures itself, and as hardware gets more and more powerful, the restriction is being removed in Version 5 and a more performance-related limit is replacing this functionality. Signatures are split into a number of different �libraries�, covering a number of different alert and attack possibilities such as DNS, FTP, Web, Denial of Service, e-mail, games, back-door/Trojans, and even porn. Each signature consists of up to eleven fields specifying direction of traffic, protocol, binary or text, port number, event name and a search string, amongst other things. T D A S 10 20 80 WEB:CGI-PHF get/20/2fcgi-bin/2fphf | | | | | | | | | | | | | | | | | | | | | | | | | | SEARCH STRING | | | | | | | EVENT NAME | | | | | | | | | | | | | PORT | | | | | | | | | | | COMPARE BYTES | | | | | | | | | DYNAMIC LOG | | | | | | | BINARY OR STRING | | | | | PROTECTED NETWORKS | | | DIRECTION | PROTOCOL Figure 3 - Defining new signatures These fields can be defined quickly and easily via the Dragon Rider Web interface in order to change existing signatures or create brand new ones specific to a particular corporate environment. For instance, it would be a simple matter to watch for a packet containing logon information to a sensitive area of a restricted Web server and mark it as an alert if an attempted login comes from outside a particular subnet. Custom signatures can be added to a special custom signature file which is loaded after the standard Dragon signatures (though the maximum 1500 signatures per Sensor still applies until the release of Version 5). As an example of how flexible Dragon can be, there are even a small number of Virus signatures included. Whilst Dragon is not intended as an anti virus scanner, it would provide the means for an administrator to incorporate a quick-and-dirty defence against certain types of viruses on the network whilst waiting for an update to the corporate AV software. The administrator can pick and choose individual libraries of signatures to apply to a particular detector or group of detectors, and then queue them up for deployment from Dragon Rider. Signature libraries are updated regularly, and certain libraries may be designated as �auto update� if required. With auto update, a Web site is queried nightly and new signatures downloaded for review by the administrator before they are actually applied. Dragon does not rely solely on a library of signatures for its anomaly detection, however. There are also a number of anomaly signatures pre-defined in the Dragon program which are designed to detect many layer three or protocol violations.� Examples include port scan, port sweep, suspicious fragmentation, IP source routing and many other types of multiple packet behaviours. This allows Dragon to perform advance packet reassembly if required in order to outwit all of the currently available IDS evasion techniques. Also included in this section are a number of complex application-specific protocol decodes such as FTP hijacking, finger bounce attacks, suspect RIP packets, NT logon events, SYN bombs, Ping of Death and various other DOS attacks.
Unfortunately, because there are no specific signatures for each DOS attack, this generic network layer detection produces a single alert to cover a range of attacks, and leaves the administrator to figure out what the attack was. Of course, if you care more about the fact that you have been attacked, rather than what the attack actually was, this is not an issue. In response to attacks and suspected port scans, the Dragon Sensor can selectively terminate suspect sessions and also emit false responses from servers to confuse scanners and act as a lightweight firewall. It can also be configured to dynamically log a certain number of packets following a suspected attack, perhaps grabbing a complete suspect FTP session. Whereas signatures are fairly easy to get to grips with, the network section of Dragon is incredibly complicated. There is extensive help both in the documentation and in the program itself when it comes to setting the network-related parameters, but it is a fact that you really need to have a good idea of what you are doing before you wander in to this part of the program � it took us a few attempts to get the IDS evasion features working correctly, for example. One wrong setting and you could end up overloading Dragon by asking it to log absolutely everything, and thus causing it to miss legitimate attacks. There are some rules in there that will help improve performance too, and here the opposite could be the case � that if you are not careful, you could actually exclude traffic that you should be monitoring. Not all the defaults are sensible either, and so we would have to conclude that Dragon out of the box is not the easiest of IDS� to configure compared to most of the others we have looked at here. On the other hand, it is one of the most flexible and configurable, so this is a real swings and roundabouts call, balancing power and ease of use. Once the appropriate signatures have been chosen for download to the Sensor, and the appropriate network parameters have been specified, the administrator can choose one or more Sensors from the GUI interface (and these can be grouped where necessary for ease of administration) whereupon Dragon Rider queues the two configuration files.
When the �push configuration� option is selected, the files are compressed and encrypted before being transferred securely to the appropriate Sensors. Dragon Rider client will automatically stop the Dragon engine, load the new configurations and report back any problems should they occur. If a problem does occur, the Dragon Rider client will copy the original configuration files back and attempt to restart the Dragon engine, thus ensuring continuity of coverage. Dragon has a complex set of rules that are applied to each captured packet, and when a rule matches a particular packet or data stream, the information is logged. When attacks occur, Dragon attempts to collect as much information as possible on the subsequent network traffic, although there is obviously a limit to the amount of traffic that can be realistically collected. There are two types of logging. The first type is a 'syslog' style log containing all of the relevant information for each captured event, stored in a text-based file called dragon.log. The second type of logging stores a binary copy of each packet in a proprietary database in the DB directory for more extensive analysis. A new subdirectory is created automatically each day, and that day�s logs are stored within it. Once the day is over, Dragon never accesses the particular subdirectory again allowing the contents to be deleted, moved or archived for long term storage. Tools to alert on low disk space are available at the customer support site. A variety of command line tools are included as part of the Dragon package to process the logged data and report on the contents in various ways. Some tools are designed to quickly identify problems, whereas others are designed to extract specific information about network events. It's up the administrator to decide how much analysis is required. A number of Perl scripts are provided to drive these reporting and analysis tools, and obviously they can be driven from custom scripts if required to automate the entire reporting process.
For those who prefer a more interactive form of reporting away from the rigours of the command line, the Dragon Fire utility provides a Web-based front end for the command line tools. A menu bar down the left of the screen allows the administrator to specify which Sensor (or group of Sensors) are to be reported on, a date range, and which reporting tool to use. Output can then be further filtered or sorted as required, and some tools have multiple reporting options. For example, when running a query for all of the events from a particular IP address, the result may be displayed line by line or packet by packet. In other cases, particularly with the sum_event tool, a higher level view of the data may be used to represent groups of events, such groupings making use of the configuration information contained in the dragon.conf file. The higher level groupings allow for easier drill-down of collected events, and will often include graphical as well as text-based data. Once a basic report has been displayed, it is possible to drill down to more detailed levels via a number of on-screen hyperlinks if required. For instance, having displayed a summary of attacks, clicking on an attack name will produce a list of individual packets. Clicking on one of those packets can show packet contents, source and destination details, and a detailed description of the attack itself, including Bugtrack and CVE information.
Clicking on the source or destination address will show all other recorded packets collected in relation to that address. Following the links in this way allows the administrator to perform a more detailed forensic examination of the log file contents following a suspected attack. Unfortunately, there is no information given on how to fix problems, and there is certainly no �auto fix� capability. Nor, is there a specific print option available, so it is necessary to run the report and then use the print function within the browser (unless you revert to using the command line version of the tools, of course). Probably our biggest gripe, however, would be the confusing way some attacks are reported, presenting the administrator with three or four different alerts from a single attack and leaving him to deduce exactly what has happened. As we said before, at least Dragon is detecting the attacks, but they way it presents its results could be a little friendlier in places. There are also some minor problems with the Dragon Fire interface when run from Internet Explorer, where selecting certain menu options results in script errors (although they are more of an irritation than a �show stopper�). We realise that Dragon is designed with Unix in mind, so Netscape is probably the browser of choice for its developers, but this is no excuse for patchy support for IE, which is the most popular browser in use on the Web. Neither Dragon Server nor Dragon Fire send or receive any SNMP traps, SYSLOG messages or email alerts. Instead, all of this functionality is available in an add-on utility known as Alarmtool. This utility watches the dragon.log file, or the Dragon Server Export log and raises alerts based on a complex set of filtering rules. Alerts can be sent via SNMP, SYSLOG or SMTP. Dragon IDS is a strange product in some ways. It is unlikely to appeal immediately to sites that do not have Unix expertise, but it would be unwise to let that put you off. True, you would get the best out of the product by knowing something about Unix and by being willing to experiment with some of the advanced command line options. But for most situations, you could do everything you need to do via the Web-based interfaces Dragon Rider and Dragon Fire. There are one or two rough edges to smooth out � the patchy support for Internet Explorer, an auto-detect mechanism for the Sensors, and the occasionally confusing method of reporting alerts, for example. However, these are fairly minor gripes compared to the potential of the product. A bewildering array of configuration options may leave the uninitiated feeling a little punch drunk and daunted, but they provide tremendous power and flexibility in allowing you to make Dragon behave in exactly the way you want it. Dragon is also fairly sensitive to the platform on which it is installed when handling high network loads, and we would recommend adhering closely to the minimum hardware requirements as suggested by Enterasys, and treating these as absolute minimums. Sparc systems would be the preferred choice, but if Pentium PCs are all you have, we would recommend using OpenBSD and Intel network cards. Once a stable configuration is achieved, however, it should perform flawlessly, since it demonstrated excellent attack recognition capabilities as well as a complete resistance to all currently known IDS evasion techniques. Company: Enterasys
Networks Click here
to return to the Enterasys Dragon Sensor 4.2 Results�
|
 |
Send mail to [email protected] with
|
