Westline Athena Aegis IPS 510L V2.1

Is the product supplied as software only or as a hardware appliance? If supplied as an appliance, please provide the hardware specification (CPU, memory, network cards, etc)
The Aegis IPS 510L is supplied as a Hardware Appliance with Dual Xeon CPU, 2GB memory, 2Gbps Fibre Interfaces, 2 tri-speed (10/100/1000) Copper Interfaces, One 10/100Mbps Ethernet port as management. 

Does sensor work in-line only, or can it support passive monitoring of switch SPAN port too? If passive monitoring is supported, what is the maximum number of ports that can be monitored by a single sensor?
In-line only with Bridging mode or Gateway mode selection.  It can monitor up to 2 ports in bridging mode and 4 ports in gateway mode with 2 ports as DMZ. 

What is the maximum number of in-line connections (port pairs) that can be monitored by a single sensor?
One port pair, either Fibre port pair or Copper port pair. 

What type (copper/fibre) and speed of network connection are supported by the sensor (include default configuration plus any options)?
The hardware specification include 2 tri-speed (10/100/1000) Copper ports, 2Gbps Fibre ports, and One 10/100 Ethernet port. 

What High Availability (HA) features are built in to the product by default?
None for this model.  Dual Power Supply is available on 710P and 510P model. 

What High Availability (HA) features are available as extra cost options?
The add-on hardware Gigabit bypass card which is bypass all traffic in power or software failure. 

What is the maximum speed/network load (Mbps) claimed with zero packet loss and without blocking legitimate traffic?
200Mbps with 256byte packet size and above. 

At the maximum load, what is the maximum TCP connection rate through the device (connections per second) claimed?
Tested to setup and teardown 4000 session/s. 

What is the average latency claimed through the device (and at what load)?
150 to 1000us depending on packet size at 200Mbps. 

Management architecture (2-tier/3-tier management? Brief description)
The Aegis product series supports both 2-tier and 3-tier management architecture at the same time (hybrid) or can be configured with a pure 3-tier architecture.   

The key feature is based on the Intrusion Management Server (IMC), which can be built-in or external.   Each sensor comes with a built-in management server (built-in IMC) and by default it is enabled and allows Console to connect directly to the Sensor.  Except scheduling feature, all functions and features are available.   In this configuration, the 2-tier configuration is in a hybrid mode and thus also allows multiple external management servers (IMC) to manage and control it.  

External management server (IMC) is software that runs on Red Hat Linux server.  Each sensor comes with this software on the CD and a free single sensor management license is provided.  The aims of external management server (IMC) is to provide a scalable environment to manage multiple sensors (at additional cost) and consolidate alerts for reporting.  In the standard default configuration of the sensor, both 2-tier and 3-tier management is supported at the same time.  Alerts are stored on the Sensor’s Hard disk, and also on all the external management servers (IMC). 

It is also possible to configure a pure 3-tier management.  In this case, the built-in management server (built-in IMC) will be disabled and alerts will be logged externally only.  Multiple external management servers (IMC) can be connected.  The Console must connect to the management server (IMC) in order to configure and manage the sensor. 

What are the minimum/recommended sensor OS and hardware requirements? Is a dedicated machine required/recommended?
The Aegis IPS 510L is a preconfigured appliance. 

What are the minimum/recommended console OS and hardware requirements? Is a dedicated machine required/recommended?
The console software runs on Windows XP/2000.  The hardware requirement is Pentium-4 2.4GHz or above, 256MB or above memory. 

What are the minimum/recommended management server OS and hardware requirements (if applicable)? Is a dedicated machine required/recommended?
The management server (IMC) runs on Red Hat Linux 9 or Fedora Core 1.  The hardware requirement is Pentium-4 2.4GHz or above, 512MB or above memory, 40GB Hard disk.  RAID disk and dedicated hardware is recommended. 

List required open ports on sensor and their use
TCP 22348 - For Console connecting to the built-in IMC server.  This port will be closed in pure 3-tier configuration.

TCP 22349 - For external management server (IMC) communicating to Sensor.

TCP 9132 - For out-of-band software and signature upgrade via Console. 

List required open ports on management server (if applicable) and their use
TCP 22348 - For Console connecting to the management server. 

List required open ports on GUI/management console and their use
None. 

Communication protocol between sensor and management server
Proprietary protocol using SSL and AES encryption. 

Communication protocol between management server and GUI/console
Proprietary protocol using SSL and AES encryption. 

Encryption between sensor and management server
AES-128bit encryption. 

Encryption between management server and GUI/console
AES-128bit encryption. 

Once deployed and configured, can sensors be managed from a central console?
Yes.  The Console can connect to multiple sensors at the same time without the use of external management server (IMC).  However, in this case, alert monitoring, reports and managements are still in separate tabbed views.

Capacity of the system? How many endpoints can be monitored? Ratio of endpoints to management servers/consoles, etc.
For better performance on the management server (IMC), it is recommended that not more than 5 Consoles connect to a management server or Sensor.  One management server is recommended to monitor no more than 5 to 10 IPS sensor at the same time. 

How many management consoles can be actively logged in to the management server at the same time?
Virtually unlimited multiple read-only access.  One read-write access only at a time by acquiring the administrative token.  For performance reasons, it is recommended no more than 5 consoles actively log into the management server at the same time. 

What anti-flooding methods are employed (sensor to management server, and management server to console)?
Console can be configured to display a maximum amount of alerts on screen. No aggregation or other anti-flooding techniques are employed. 

Maximum insertion rate into alerts database
Roughly 600 alerts per second inserting into database.  This value will be higher with better hardware configuration on the external management server (IMC). 

Maximum size of database
To the maximum size of disk space available. 

Maximum number of alerts stored
To the maximum size of disk space available. 

What happens to alerts in main alert database once capacity limits exceeded (deleted/archived/etc)
New alerts will be dropped.  User is required to manually backup and purge old alerts in the database in the sensor and/or external management server (IMC). 

What is maximum recommended size of alerts database to maintain acceptable query performance?
Less than 5 million alerts is within acceptable query performance. 

When alerts are removed from main alert database, are they still available for reporting directly (i.e. can reporting tools merge current and archived alerts)
No.  Before removing alerts from alert database, user can back up and archive the database to another location.  To merge current and archived alerts, user needs to restore the archived alert back to the alert database. 

This also means customer is allowed to build a pure analyzing management server (IMC) without connecting to any sensors.  All archived alerts can be restored to it for off-line analysis purpose.   

Which database product is used for alert storage? Is schema open?
On management server (IMC), it runs with MySQL 4.1.8.  The schema is open. 

What happens when communications between sensor and management server/console are interrupted? Local logging on sensor? Maximum capacity? What happens when local sensor logs are full? Is the local repository secure?
In default 2-tier mode, alerts are stored locally and additionally to any external management server connected.  Therefore local logging will not be affected with sensor and the management server/console are interrupted.  

In the pure 3-tier mode, alerts will be lost when the communication between the management server and sensor is broken.  However, the sensor will be continuing to block malicious traffic as normal. 

When local sensor logs are full, no more new alerts will be logged.  Since the Aegis IPS 510L is an appliance, the local repository is securely logged without any SSH or Telnet access. 

Secure logon for policy management?
The Console requires the correct username/password pair in order to manage the Sensor. 

Granular access (i.e. read only/read-write/etc) granted on a per-user basis? What levels of granularity are supported (i.e. is it possible to restrict user access to specific parts of the management console, to specific appliances, etc.)?
Currently we take a single read-write user approach.  Any connected user without taking the administrative token will be in read-only mode.  Read-only user will be allowed to generate reports and perform log analysis only.  Configuration options will be greyed out for read-only users.  The user with the administrative token will prevent other users taking it, and only he can perform configuration changes. There is no role-based administration capability. 

Is it possible to define multiple policies for the sole purpose of distributing to multiple sensors with different functions?
Yes.  The sensor comes with some built-in detection policies.  User can create and copy from those built-in policies and apply to different sensors. 

How are policies distributed to sensors?
The policies are ‘installed’ to the sensor.  In the Console, user selects the appropriate detection policies and then applies it to the desired sensors via external management server (IMC).  With 2-tier mode, user can only apply the detection policies to the local sensor. 

Can policies be deployed on a per-port, per-sensor or per-group basis, or globally only?
Policies are deployed per-sensor basis.  Each policy consists of detection rules, and firewall rules. 

How are policy changes handled? Will the central console detect which sensors are using a changed policy and redeploy automatically, or does the administrator have to do this manually?
For the managing management server (IMC), the Console retrieves the policies in uses on each sensor.  When there are multiple management servers, it will be the user’s responsibility to control the policies and manually update the sensor’s policy to avoid discrepancy on the current policies status. 

When a policy is applied, it will be locked and changes are not allowed.  To modify it, user needs create a new copy of the policy in use and modify it, and then apply this new modified policy. 

Can policy deployment be scheduled?
No. 

Does the sensor remain able to detect alerts at all times during policy/signature updates? If so, explain how this is achieved. If not, for how long is it inactive, and does the sensor block all or pass all traffic whilst inactive?
When a new policy is applied to the sensor, the engine will be stopped and entered idle time for about 2 seconds.  When the sensor’s engine is in idle, all traffic is passed without inspection.  Then the new policy will be applied and the engine becomes active again and inspects all traffic. 

Can the administrator define custom attack signatures?
Yes.  User can define signature based on Source IP, Source Port, Destination IP, Destination Port, Protocol header information and a simple pattern matching string to detect in the payload.

Regex supported when creating custom signatures?
No. 

How are new vendor attack signatures obtained and deployed?
Either the sensor obtained it via our signature server via HTTP port 80 or obtained in via management server (IMC).  The management server (IMC) will download signature via HTTP port 80. 

Our management server (IMC) can also retrieve signature updates from another management server (IMC). 

It is possible to use the Console to update the sensor’s signature via signature pack (dat file).  The dat file is obtained via the normal support channel. 

Frequency of signature updates?
Roughly one week to two weeks. 

What infrastructure does the vendor have behind the signature update process (i.e. dedicated team of engineers? How many? Does it have a name?)
A dedicated Westline Security Research Team is researching and update signatures collected from Internet and customer’s requested. 

Can one signature update file be downloaded to the local network and used to update all sensors from a central location, or is it necessary to initiate a live connection to the Internet download server for each sensor/management server?
Yes.  In using external management server (IMC), the signature update actually takes place on the management server and it will deploy to all managed sensors. 

Can signature updates be scheduled and fully automated? Is automated download AND deployment to sensors supported, or just download (or neither)?
Scheduling can be done via external management server, which is free for one sensor. 

What network protocols are analysed?
IP, TCP, UDP and ICMP. 

What application-level protocols are analysed?
HTTP, FTP, SMTP, FTP, POP2, POP3, IMAP, NETBIOS, MSRPC, SUNRPC, MYSQL, Oracle, MSSQL, NNTP, FINGER, DNS, SNMP, TELNET, Instant Messaging such as MSN, Yahoo, ICQ, P2P such as Bittorrent, eXeem, Kaaza, Gnutella, Napster, Backdoor, DDOS.  

Can the product perform protocol decodes?
Yes. HTTP, Telnet and RPC and Backdoor (Currently Back Orifice only).  

Can the product perform protocol anomaly detection?
IP, TCP, UDP and ICMP protocol violation will be detected.  Reserved IP protocol, TCP and UDP packet with port 0 will be dropped silently by the built-in stateful firewall.  This option cannot be changed. 

Can sensor support both normal and asymmetric network configurations?
The sensor currently supports normal network configuration only.   Asymmetric network configuration is planned in coming release. 

Is the detection engine “stateful”? If so, please explain how this works.
The detection engine is stateful for TCP connection.  Established connections are put into state table.  SYN_SENT and HALF_OPEN connection will be tracked as well.  All established connections are kept for their life, but sessions without any traffic over 3600 seconds will be treated as IDLE sessions.  IDLE sessions will be reclaimed when the state table is full and there are no bad sessions for reclaim. 

If stateful - how many open connections can be tracked? Is this value configurable?
Max 250,000 session connections can be tracked.  When this limited is reached, no new connection can be made. 

This option is not configurable for this model. 

If stateful - for how long are partially opened connections tracked? Is this configurable?
Partially opened connections include SYN_SENT and HALF_OPEN connections are time-out for 10 seconds.  Without receiving a valid final ACK packet from the initiator, the connection will be marked as bad and repeated SYN_SENT from the client will be dropped. 

Repeated SYN_SENT packets will be blocked after receiving 9 packets. 

This option is not configurable at this moment.  Configuration will be allowed in a future release. 

If stateful - for how long are fully opened connections tracked if not used? Is this configurable?
Established connections (fully opened connections) will be marked as IDLE without receiving any valid ACK packets from either client or server in 3600 seconds.  IDLE sessions will be reclaimed when the system runs out of resources. 

This option is not configurable at this moment.  It will be configurable in a future release. 

What is the default action when system resources run low or state tables are filled - block or permit all new connections? Is this default action configurable?
When the state table is full and no bad sessions or IDLE sessions can be reclaimed, no new connections will be allowed.  Existing connections will be still allowed and inspected. 

What is the default action when power fails or the system is powered down - block or permit all traffic? Is this default action configurable?
The IPS is in fail-safe mode and all traffic is blocked during power down.  This can be changed by purchasing optional hardware add-on bypass card to become fail-open. 

What is the default action when the sensor is unavailable for any length of time (i.e. during policy download or software update - block or permit all traffic? Is this default action configurable?
During policies update, the sensor will be temporarily run into ‘idle’ whilst passing all traffic uninspected for about 2 seconds, after which the detection engine is re-enabled. 

Will the detection engine block/alert on ALL suspicious activity, or only when an attack is made against a vulnerable server? If so, please explain in detail how this works. Can this behaviour be modified (i.e. to alert on ALL attacks if required)?
Yes, the engine can be configured to alert and block all suspicious activity.  By default, IP packet anomaly and invalid TCP segmentation are turned off on alerting.  This is configurable via the Sensor properties.  Some invalid IP, TCP and UDP packets will be always silently dropped by the IPS to avoid flooding of such packets.

Are server responses monitored and alerted/blocked? Does this have an impact on performance?
Yes.  Server response is also monitored.  The IPS inspects packets both to and from the server.  The signature detection is optimized to detect traffic specifically either to and/or from server such that particular response from server could be matched more accurately.  To avoid huge performance impact on the server side for heavy downstream protocol, TCP session reassembly is disabled for server-side stream.  

Ability to monitor user-defined connections (i.e. report on an FTP connection to a specific server?)
Yes.  Our detection policies are rule-based, allowing a more precise detection based on source and destination group preferred by the customers.  By custom rules in a policy it is possible to look for particular source and/or destination host with the proper signatures. 

Detect/block network-level packet based attacks?
Yes.  Some invalid IP fragmentation attacks and invalid datagrams (mostly generated by ISIC tools) will be silently dropped by the stateful firewall as well.  This behaviour cannot be changed. 

Detect/block all types of port scans (full connect, SYN stealth, FIN stealth, UDP)?
Yes.  At TCP level the TCP stream parser will decode and check if it matches the stealth activity properties.  This is not done by signature. 

Detect/block SYN floods? Manual or automatic thresholds? Configurable? How is SYN flood protection implemented?
Yes.  The IPS uses mainly HALF-OPEN session re-use methodology in defining SYN attack to avoid the flooding of the state table on the IPS.  Any SYN_SENT only and HALF-OPEN session has a timeout of 10 seconds and it will be reclaimed once it is expired. 

For repeated SYN_SENT attacks, further repeated SYN_SENT packets will be dropped once it reaches a counter of 9.   

This option is not configurable at this moment. 

Perform packet/stream reassembly?
Yes, a TCP reassembler is available, working on all TCP flows from client to server including FTP, HTTP and even RPC.  The reassembler also detects and blocks invalid timestamp, sequence number protections and other malformed packets such as null control flags during TCP segmentations.  Once the segments are considered bad, further packets will be dropped but it will be still reassembled to see if an attack can be matched. 

Perform deobfuscation?
Yes.  De-obfuscation takes place for all URLs on HTTP sessions.  HTTP ports are preset at port 80, 8180, 8080 and 8888 only - additional ports cannot be enabled for HTTP inspection at this moment. 

Is all traffic scrubbed/normalised/reordered as it passes through the sensor?
Yes. IP fragments are reordered.  For TCP segmentations, the IPS will not reorder the packet sequence, a copy of the packets are built in the TCP reassembler.  Once a packet that rebuilt the stream matches an attack, this packet will not be delivered to the destination, rendering the attacks incomplete.  Further packets from the same session will be blocked. 

How is fragmented traffic handled by the sensor?
Yes.  The Aegis IPS 510L takes an approach that IP fragmentation will be done by the Sensor before sending out from the sensor if possible.  

List all prevention features available (alert only, drop packets, block TCP session)
The IPS allows Drop packets and silent Drop packets. 

List any other security features available (bandwidth shaping, rate limiting, etc.)
This IPS contains a stateful firewall.  By default the stateful firewall allows all packets when there is no firewall rule.  There is also a NAT feature which allows standard one-to-one mapping, TCP and UDP port forwarding in Gateway mode only. 

Packet capture capabilities? Only the trigger packet, or before and after? How are packet captures stored/viewed?
Yes. The IPS can allow packet logging based on packet or session based.  Logged packets will not appear in the alert monitor windows.  They can be retrieved via the alert analysis windows for viewing the packet details such as packet header and payload. 

During evasion attacks, any TCP segments which are part of the attack will be logged this way to prevent flooding of the alerts in the Console.  For example, an attack is detected after reassembling 8 TCP segments, only one alert (the first TCP segment) will be in the alert monitoring console.  The rest are logged as additional logged packets in the database.  This preserves all the packet details as much as possible.  Those packets can be viewed through the alert analysis windows of the Console. 

Do you track and display context data as part of each alert (i.e. for an FTP overflow, do you show which user name/password combination was used to login to the FTP server, etc?). If so, how much context data is available?
This feature is not supported yet.  

Option to record entire sessions for “forensic” investigation? Where is this data stored? How is it secured from tampering?
Yes.  Logging session traffic will be the same as packet capture capability.  Each packet logged within the session will be marked as additional logged packet and can be viewed through the alert analysis windows of the Console. 

Reporting from sensor to console - range of alert response options (detail these, i.e. log, alert, e-mail, pager, packet capture, etc)
Alert Response Option are Alert (on Console), SYSLOG and SNMP trap. 

Can alert response options be set only at a global policy level, only at individual signature level, or to groups of signatures (or a mixture of all three)?
The notification can be configured based on rules, which is a group of signatures within a policy.  Each sensor can be set up to send to different SYSLOG and/or SNMP server via the Sensor properties. 

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?
Yes.  In alert analysis of the Console, user can define filters based on date, time, source IP, source port, destination IP, destination port, severity and even signatures to extract the particular events.  The particular events include full packet headers and payload information.  The payload is also ASCII-decoded and supports copy-and-paste function. 

Can alerts from all sensors be viewed at a single console at the same time (i.e. without having to connect to separate sensors from the console)?
Yes.  The Console can connect to multiple sensors and multiple management servers at the same time.  Connecting to multiple sensors from a Single Console directly will not consolidate the alerts in one window.  Alerts from each sensor will be in separate alert monitoring consoles. 

If using the management server (IMC) to manage multiple sensors, then alerts will be consolidated for all sensors managed under the same management server (IMC).

Can the central console correlate alerts from multiple sensors (i.e. not just display alerts from multiple sensors, but attempt to infer a connection between different alerts on different sensors)? IS this offered as standard or extra-cost option?
No.  Third party software is required for ‘correlation’ based function. 

Can alerts be correlated manually by the administrator - grouped together in the database as a single event for further investigation?
No. 

Can alerts/events be annotated and tracked for investigation by multiple administrators/investigators?
No. 

Does the software offer advice on preventative action to ensure the attack does not happen again?
In the Console, a knowledge-base which is in Microsoft CHM format allows the user to view the alert’s recommendation.  Each alert generated also contains a reference tab that links to this knowledge-base as well as any external information.  A browser can be opened to connect to the web site by double clicking over it. 

What industry standards are supported - Intrusion Detection Exchange Format working group (IDWG), Intrusion Alert Protocol (IAP), Intrusion Detection Message Exchange Format (IDMEF), IDXP - and in what way?
None. 

Which third party event correlation systems are supported and in what way?
Cell CMC is a third party software which is an event correlation system that supports Athena IPS together with Check Point, Watchguard, NetScreen and Cisco PIX.  Aegis IPS is supported via SYSLOG notification. 

Integration with other scanning/IDS/prevention products?
The Aegis IPS can work with Check Point 2000 Firewall, Cisco PIX, and NetScreen Firewall for blocking by the third party firewall. 

Log file maintenance - automatic rotation, archiving, reporting from archived logs, etc.
In standard 2-tier configuration, user can simply use the Console to backup, purge and restore database to the sensor.  In the management server (IMC), the user can do whatever he wants according to the schema provided to extract the desired information and perform other database operations. 

Management reporting - range of reports/custom reports/how easy is it to filter and extract detail? Different reports for technicians and management/end users?
Management reports are provided via the Console.  Most of the reports are graphical, presenting the top 5, 10, 20, 50 100 and even ALL.  There are over 16 management reports - Top Scan source, Top Scan target, Attack by severities, Attack over time and Top signatures.  There are also CPU utilization reports plus a custom report which is for technicians. 

Technical analysis is done via the alert analysis windows of the console.  Data could be exported to TSV format for the summary information. 

Are trend/comparison reports available?
Not available yet.   

Does reporting allow customised filtering down to the level of reporting all activity on a specific network resource/object by a specific user/machine on a specific date?
Yes. Customer can filter data according to Date, Time, Sensor, Source IP, Source Port, Destination IP, Destination Port, Signature, Action and Severity. 

Report management - can they be scheduled for automatic production? Can they be e-mailed to administrators or published straight to a Web site?
Scheduled Reporting can be done via external management server (IMC) only.  Scheduled report will be in PDF format and stored in a default location, which is configurable. 

List the output formats supported for reports (HTML, text, PDF, etc)
Using Console, the report can be exported to PDF, HTML, CSV, Excel and Text for management report.  For alert analysis, report can be exported as TSV format.   Any scheduled report via management server (IMC) is exported as PDF only. 

What are the limitations and restrictions on enterprise-wide alerting and reporting? Can reports consolidate output from every 1) server, 2) detector
In standalone 2-tier configuration, Console can generate reports and alerts based only on the Sensor to which it is connected.  When using the management server there is no limitation.  Report consolidation can be done via management server (IMC). 

Ability to define custom reports?
Yes.  User can select the interesting summary information and export it into TSV format.  The summary information can include:

Time, Severity, Sensor, Interface, Signature, Src IP, Src MAC, Src Port, Dst IP, Dst MAC, Dst Port, Protocol, Event Type, Rule ID, Action and Notification. 

Provide brief description of any management software included in the base price of the product. 
The Management Software (IMC) is free for managing one sensor.  Customers who purchase one IPS will receive the software together on the product CD.  This provides all functions for one Sensor including scheduled reporting and signature download. 

Provide brief description of any additional management products available as extra cost options. 
The Management Software (IMC) is free for managing one single sensor.  To monitor multiple sensors for consolidating alerts and reports together, customers need to buy additional licenses to enable the IMC to monitor multiple sensors (from USD 4900 for 5 licenses, to USD 8600 for 20). 

Documentation provided (Hard copies available? Extra cost?)
Documentation is available on the CD (soft copy) only. 

How is the product licensed? How is the license enforced?
On Sensor, the user will obtain a new license file to renew the license for software and signature update.

On Management Server (IMC), license will control the number of sensors allowed for control. 

All licenses are controlled via Expiry date, Maintenance date and MAC address of the management interface. 

End user pricing information for product provided for test (include all sensor, management server and console costs for both hardware AND software). Include options/configurations other than those tested - ALL PRICES AS LIST PRICE ONLY!
The list price of Aegis IPS 510L is USD 31,980, which includes first year software and hardware maintenance.  It also covers the first year signature update and one sensor monitoring by external management server (IMC). 

Ongoing cost of maintenance/updates
Software maintenance (includes signature updates) - USD 4692

Hardware maintenance - USD 4797

Click here to return to vendor questionnaire index
Click here to return to the Westline Review
Click here to return to the IPS Index Section