Enterasys Dragon Sensor 4.2

Brief product description
Dragon IDS is a system for your network to detect Intrusion on your network. It does this by monitoring network traffic and key files upon servers. There are three main parts, Dragon Sensor (NID), Dragon Squire (HID) and Dragon Server (management console).

Architecture
Dragon is made up of Host and network sensors which all report to a central management machine, which used to configure all sensors. The server is also where are the logged information is stored and can also send alerts either as email, snmp or syslog.

At what layer of the protocol stack is the product working?�
The NID works at the Network layer, so that it can analyse all network traffic

Documentation
There is an Installation guide and documentation all available the Web plus PDF versions of the online documentation are included on the CD. Hard copies are available upon request.

What are the minimum/recommended console OS and hardware requirements?�
The minimum specs of the Server depends on the speed of the network and the number of sensors it has to manage but should be at least a P3 500 with 128mb ram and 10 gb hard disk and a dual P3 700 and 256 mb of ram and 40 gb hard-disk for a set up of 30 sensors and 100 squires. The OS has to be either Linux, OpenBSD, FreeBSD, Solaris (sparc or intel) and HP-UX.�

Is a dedicated machine required/recommended?�
Recommended

Will it work on Windows 2000?�
No but you can manage it remotely using a web browser on a w2k box

What are the minimum/recommended agent OS and hardware requirements? Is a dedicated machine required/recommended?�
As above but the sensor (NID) depends on the link it�s monitoring from a P2 for a T1/10 mbs to a P3 700 for a 100 mbs connection. Squire is designed to run with minimum impact so there isn�t a minimum spec.�

Will it work on Windows 2000?�
There should be a version of Squire (HID) for NT/2000, hopefully available by the end of 2000.

What components are installed on a detector�
On the detectors there are two daemons running, one that does the work and one that communicates to the Server.

Which network types are supported
Ethernet and Gigabit Ethernet are currently supported and the Token Ring and FDDI support will be available shortly (currently in beta testing).

Any specific recommendations for monitoring Gigabit networks with your product?
For Monitoring Gigabit Ethernet the machines have to be high spec and you will need multiple sensors. It is also advisable not to overload the sensor with too many signatures to enable it to keep up.

Which OS platforms are actively monitored?�
The HID is designed to protect the OS it�s installed, currently on the UNIX's mentioned above. The NID can detect Windows based attacks and Unix based attacks.

Can sensors/detectors be deployed and configured initially from a central console?
No

Once deployed and configured, can sensors/detectors be managed from a central console?�
Yes

Authentication between console and engines � Is it available? What algorithm/key lengths?�
Yes, a Blowfish encrypted link that authenticates with a shared secret.

Secure logon for policy management?�
The Interface for Management is web based, and it recommended by us that this is secured with SSL so that you have to authenticate to the server to remote administrate the Central Server.

How are policies distributed to engines?�
The Policies are �Pushed� to all the remote sensors from the Central Server over the blowfish encrypted link.

How are policy changes handled? Will the central console detect which agents are using a changed policy and redeploy automatically, or does the administrator have to do this manually?�
The central console knows the configuration of each sensor but any changes to the policy must by done manually on the server and re �pushed�, the human step therefore ensures that the policy change can be properly reviewed.

How many attack signatures?��
Currently 1101 NID signatures and squire has about 550 signatures.

Can the administrator define custom attack signatures?
Yes

How are new attack signatures obtained and deployed?�
They can downloaded from the Internet or can be automatically downloaded to the Server. They are deployed by the user on the Server and sent out to the sensors.

Frequency of signature updates? Provide dates of all updates in the last year.
Signatures are updated as and when new attacks are published, this is a continuous process and is therefore difficult to give exact dates of when these updates occur.

What infrastructure do you have behind the signature update process�
The signatures are written by a team of NSW in house engineers also because of the open nature of the signature, many customer write their own signatures and send them back to the developers where they can be included in the signature libraries.

Can one signature update file be downloaded to the local network and used to update all IDS engines from a central location, or is it necessary to initiate a live connection to the Internet download server for each engine?�
All the signature libraries can be downloaded to the central server where they can be easily distributed to the sensors connected.

Can signature updates be scheduled and fully automated?�
Yes, the signatures can be scheduled to download to the Central server but it will not automatically send them to the sensors. This is so they can be checked first before sending them out.

What network protocols are analysed?
IP, TCP, UDP, RIP,RPC and Netbios�

What application-level protocols are analysed?
All IP protocols such as TELNET, FTP, HTTP,etc.

Can the product perform protocol decodes?
No

Can the product perform session recording on suspect sessions?�
Yes, follows on packets are logged depending on the signature, so that the session is logged and can viewed later.

Block/tear down session?�
Dragon can respond to certain events or IPs with reset packets therefore terminating the session.

Ability to monitor user-defined connections (i.e. report on an FTP connection to a specific server?)�
Yes dragon can be configured to log traffic on a certain IP and port. Plus custom signatures can be written to fit the needs of your network.

Monitor changes in critical system files?�
Dragon Squire will checksum and monitor changes in key system files such as /etc/passwd and /var/log/messages.

Monitor changes in user-defined files?�
Yes, Squire can monitor any file you define.

Monitor changes in Registry?�
As there is no Registry under UNIX then no. However hopefully when the NT/2000 version is available this will monitor registry changes.

Monitor unauthorised access to files?��
Under Unix you will be unable to access file you don�t have permission to without escalating your privileges and Dragon would notice this.

Monitor administrator activity (creation of new users, etc)?�
Yes as this would change key files such as /etc/passwd.

Monitor excessive failed logins?�
Yes as failed logins get reported in /var/log/messages and there are signatures for this file.

List any other resources/locations that are monitored.�
Cisco messages can be report to a Syslog server and with Squire it can monitor messages from your router and PIX firewall. Also it can look in the logs of Apache web servers, SQUID, SSH, ipfilter, ipchains and IPFW etc.

Track successful logins, monitoring subsequent file activity, etc?�
Doesn�t normally monitor successful logins but it could be made to with a custom signature.

Detect network-level packet based attacks?�
Yes

Detect all types of port scans (full connect, SYN stealth, FIN stealth, UDP)?�
Yes

Detect and report on nmap OS fingerprinting?�
Nmap is a port scanner and Dragon detects port scanning. It does not however directly detect nmap. Nmap used to have unique flaws in it artificial packets which could be used to ID its use, but Dragon basically picks up on all forms of port scanning and sweeping whether it is slow, fragmented, randomised or spoofed with multiple decoy scans. As for OS fingerprinting, this usually involves sending TCP flags with odd combinations or sending traffic to port zero. Dragon picks up on this.� Subtle attempts to id an OS based on frag reconstruction time-out, maintaining the don�t-frag bit set, or padding data in ICMP unreachable pings are not supported though.

Perform packet reassembly? Resistance to known IDS evasion techniques?�
Both

Reconfigure firewall? If so, which firewall(s) and how?�
No

Option to record everything for �forensic� investigation? Where is this data stored? How is it secured from tampering?�
Yes, it is stored on the central server but could be exported to a SQL database for long term storage. There is no anti-tempering as such but a third party program such as Tripwire could be used on the data.

Reporting from engine to console - range of action/alert options (detail these)�
All events logged are forwarded to the Central Server where they can be analysed centrally. From here the alerting can be done for any events you want to be alerted on. Alerts can be SNMP,SMTP or SYSLOG.

What provision is made for temporary communications interruption between detector and console? Where are alerts stored? Is the repository secure?�
Dragon sensor stores all information locally and can lag the forwarding of the events if the network is overloaded. These are stored in databases just like on the Server and can even be accessed remotely if dragon fire is installed on the sensor.

Can alerts be reported to the central console in real time without the use of third party software? How easy is it to filter and extract individual events?�
All events are forwarded to the Server in real time and using the Dragon fire interface it�s easy to filter and analyse these events.

Does the software offer advice on preventative action to ensure the attack does not happen again?�
The events all have description of what they mean and will give the relevant Bugtraq or CVE web link (if known) so you can find more about the problem and if necessary guide you in fixing the problem.

Integration with other scanning/IDS products?�
Not yet, there are plans for the dragon server to receive SNMP alerts from other IDS.

Log file maintenance � automatic rotation, archiving, reporting from archived logs, etc.�
This can be done with a variety of scripts available on the Customer support site.

Management reporting � range of reports/custom reports/how easy is it to filter and extract detail? Different reports for technicians and management/end users?�
Better reporting including 2d/3d reporting for management and non-technical staff is to be included in the Server in the near future.

Report management � can they be scheduled for automatic production? Can they be e-mailed to administrators or published straight to a Web site?
No

What are the limitations and restrictions on enterprise-wide alerting and reporting? Can reports consolidate output from every 1) server, 2) detector�
On the server you able to choose a particular sensor� and view the events logged for it and produce reports for each sensor. You all also can produce a report based on all sensor to give a complete picture, the limitation of this is that the report is usually very big and would take longer to analyse.

Define custom reports?�
Dragon can present data in different ways using the different analysis tools and summarising tools, in the future there will be a 2D/3D tool that will be able to customise and present the data in a easy to read and non-technical way.

How is it licensed? How is the license enforced?�
The license is per server and sensor, a key file is needed for every sensor and server.

End user pricing information�
Dragon Sensor:
1 - 10 units : $8,097
10 + units : $POA
Dragon Server:
1 - 10 units : $10,589
10 + units : $POA�

Ongoing cost of maintenance/updates
The First year of maintenance is included in the initial price. Additional maintenance contracts are available at 20% per annum, of the then current list price.�

Click here to return to the Enterasys Dragon Sensor 4.2 Review
Click here to return to Enterasys Dragon Sensor 4.2 Results
Click here to return to the IDS Index Section