 |
|
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)
NFR�s IDS system consists of three components:
� Sensor (appliance). Customer can either supply their own sensor hardware or purchase sensors from NFR. NFR offers three base models:
o NID-310
o NID-315
o NID-320
� Central Management Server (�CMS�) database
� Administration Interface (�AI�) console
As mentioned previously, the NID-310 sensor is supplied both as �software only� or as a hardware appliance. The CMS and AI are supplied as software only. All three components are mandatory.
The NID-310 sensor �software only� minimum hardware specification:
The sensor hardware appliance hardware specification as supplied by NFR: NFR�s model NID-310 sensor.
What
is the maximum speed/network load (Mbps) claimed with zero packet loss?
100Mbps
At
the maximum load, what is the maximum TCP connection rate (connections per
second) claimed?
Varies
depending on network characteristics and which backends are interested in the
data for those connections.
Product architecture (2-tier/3-tier management? Brief
description)
We are a multi-tier system. We have clients and sensors which
talk to server processes. The server processes then store data in both local
file systems and third-party database engines.
What are the minimum/recommended sensor OS and hardware
requirements? Is a dedicated machine required/recommended?
Sensor OS: NFR (based on FreeBSD)
Hardware requirements: NFR model NID-310 sensor.
A dedicated machine is required.
What are the minimum/recommended console OS and hardware
requirements? Is a dedicated machine required/recommended?
The
recommended AI configuration:
A dedicated machine is not required, but is recommended.
What are the minimum/recommended management server OS and
hardware requirements (if applicable)? Is a dedicated machine
required/recommended?
The CMS will run either under Linux or Solaris.
The recommended Linux configuration:
A dedicated machine is not required but is highly recommended for optimum performance.
The recommended Solaris configuration:
A dedicated machine is not required but is highly recommended for optimum performance
List required open ports on sensor and their use
TCP/1968. UDP/123 also required if optional time synchronization feature is
enabled.
List required open ports on management server (if applicable) and
their use
TCP/1968 & TCP/2010 are required. There is also one additional port which is
user configurable.
List required open ports on GUI/management console and their use
N/A
Communication protocol between sensor and management server
Proprietary protocol over TCP/IP.
Communication protocol between management server and GUI/console
TCP/IP
Encryption between sensor and management server
DES
Encryption between management server and GUI/console
DES
Once deployed and configured, can sensors be managed from a
central console?
Yes.
Capacity of the system? How many endpoints can be monitored?
Ratio of endpoints to management servers/consoles, etc.
Unlimited. The NFR IDS System can scale as required. Depending on configuration
setting, NFR recommends 10-20 sensors per CMS.
What
anti-flooding methods are employed (sensor to management server, and management
server to console)?
N/A
Maximum insertion rate into alerts database
4000 per second
Maximum size of database
Configurable based upon available disk space.
Maximum number of alerts stored
User configurable.
What happens to alerts in main alert database once capacity
limits exceeded (deleted/archived/etc)
The CMS includes a space management utility will operates on a
FIFO principal. As the database reaches capacity the user can elect to either
a). discard older records to make room for new records, or b). stop recording
new records until more space is made available. NFR also provides users with a
data extraction utility called �DBExport� which facilitates the archival of CMS
records to external data stores.
What is maximum recommended size of alerts database to maintain
acceptable query performance?
Dependant on system specification.
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. The NFR reporting tools are configured to work only with data
stored in the CMS.
Which database product is used for alert storage? Is schema open?
NFR proprietary. The schema is available from NFR.
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?
During install, the Sensor can be configured to send alert
traffic to a primary or a backup CMS. If the primary CMS should suddenly become
unavailable the sensor will automatically route traffic to the backup CMS.
These two CMS�s are treated as equals. If neither CMS is reachable, the sensor
will hold the data locally and forward later when able to. Capacity is limited
to available disk space (minus 10%). If no more space remains, new messages are
discarded.
Secure logon for policy management?
Yes
Granular access (i.e. read only/read-write/etc) granted on a
per-user basis? What levels of granularity are supported?
Yes. User permissions include:
Is it possible to define multiple policies for the sole purpose
of distributing to multiple sensors with different functions?
No
How are policies distributed to sensors?
Mirroring process utilising proprietary protocol over TCP/IP
Can policies be deployed on a per-sensor or per-group basis, or
globally only?
Per sensor or globally. Groups are not supported.
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?
Manually.
Can policy deployment be scheduled?
No
Does the sensor remain able to detect alerts at all times during
policy/signature updates? Explain how this is achieved.
No
Can the administrator define custom attack signatures?
Yes
Regex supported when creating custom signatures?
N/A.
How are new vendor attack signatures obtained and deployed?
User can access NFR�s package server via the console application.
Frequency of signature updates?
As needed, recommended period is weekly.
What infrastructure does the vendor have behind the signature
update process (i.e. dedicated team of engineers? How many? Does it have a
name?)
NFR�s Rapid Response Team (�RRT�)
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
sensor/management server?
Yes to the first question.
Can signature updates be scheduled and fully automated?
No
Which network types are supported by the sensor?
What network protocols are analysed?
IPv4 protocols analyzed include FTP, SNMP, TFTP, UDP, POP, ICMP,
IMAP, IP, TCP, RPC, SMTP, etc. IPv6 protocol support will be fully supported in
v4.0
What application-level protocols are analysed?
Signatures, anomaly detection and protocol state machines exist for telnet,
rlogin, SSH, DNS, finger, FTP, AUTH, IMAP, IRC, LPD, MSRPC, Sun RPC, NETBIOS,
POP, Rcommands, SMB, SMTP, SNMP, SSL, TFTP, X-Windows, MS-SQL and many
additional protocols.
Can the product perform protocol decodes?
Yes � See the answer above for a sampling of decoded protocols
Can the product perform protocol anomaly detection?
Yes - Each protocol state machine also performs anomaly detection
Is the detection engine �stateful�? If so, please explain how
this works.
Yes. State is kept in the engine for IP fragments and TCP sessions to facilitate
IP reassembly and TCP stream reconstruction. For IP, all fragments are kept
until a packet can be fully reassembled, along with other pieces of information
like packet size, number of fragments received, number of holes remaining in the
reassembly, etc. For TCP, seqs and acks are kept along with segments awaiting
to be acked from the other side of the connection. In addition to layer 3 and
below state tracking, our signature set tracks application level state for
protocols listed above.
If stateful - how many open connections can be tracked? Is this
value configurable?
Varies from
10,000�s to many 1,000,000�s.
The stack does not have a predetermined "high water mark". Instead, we will allocate state until all memory resources are exhausted, and then a memory pressure system is used to prune state that the engine determines is stale or more expendable than other state.
If stateful - for how long are partially opened connections
tracked? Is this configurable?
The engine has 5 configurable timeouts for different states of TCP connections
(defaults are in parens):
If
stateful - for how long are fully opened connections tracked if not used? Is
this configurable?
Defaults to 60 seconds, configurable through the NCode nfrconfig() interface,
e.g.: nfrconfig("tcpopensessiontimeout", 600);
sets it to 5 minutes.
If stateful � explain the behaviour of the system when the state
tables are filled
The "state table" is a mostly balanced red-black tree. It does not have a max
size like hash tables and cannot be trivially DoSed like hash chaining. When the
system runs out of memory, NFR will apply pressure to the system in order to
satisfy the memory request. First, NFR prunes the several hundred caches
(various things are cached for speed), then NFR pre-emptively discards enough
TCP connections or fragment reassembly trees until we have enough memory to run
for awhile.
Will the detection engine 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)?
It depends. There are situations where this is true, however
this is usually disabled by default.
The Apache attacks and the IIS attacks are good examples of this. By default, every HTTP request is compared against all Apache and all IIS attacks. However, if the variable www:MONITOR_SERVER is set to 1, the variable www_apache:ALERT_ON_APACHE_ATTACKS is set to 1, and the variable www_iis:ALERT_ON_IIS_ATTACKS is set to 1, then we will look at the HTTP header in the server reply. Based on that information, A non-IIS server will not have the IIS checks done, and a non-Apache server will not have the Apache checks done. All NID detection signature code is available to the customer and can be tuned via modifying package variables or by modifying the detection code itself. As of this writing, over 1300 user configurable tuning variables are available to modify attack detection and alerting behaviour.
Are server responses monitored and alerted upon?
Yes � for certain protocols and attacks.
Ability to monitor user-defined connections (i.e. report on an
FTP connection to a specific server?)
Our Policy package allows a customer to specify firewall-like rule set policies
and alert on attempts violate this policy.
Detect network-level packet based attacks?
Yes
Detect all types of port scans (full connect, SYN stealth, FIN
stealth, UDP)?
Yes
Detect SYN floods? Manual or automatic thresholds? Configurable?
Yes. Configurable thresholds.
Perform packet/stream reassembly?
Yes
Perform deobfuscation?
Yes
List all �prevention� features available (TCP reset, ICMP
unreachable, firewall reconfiguration, drop packets (in-line only))
TCP reset, firewall reconfiguration
Packet capture capabilities? Only the trigger packet, or before
and after? How are packet captures stored/viewed?
This feature is in the v4.0 release which is currently in test. The feature will
capture the trigger packet and subsequent server response packets. The packets
are written to libpcap file and are viewable within the console application and
also exportable.
Option to record entire sessions for �forensic� investigation?
Where is this data stored? How is it secured from tampering?
No
Reporting from sensor to console - range of alert response
options (detail these, i.e. log, alert, e-mail, pager, packet capture, etc)
Yes. Alert, SNMP, Email, Custom Scripts, etc.
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)?
Mixture of all three.
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. Filtering is configurable according to response options
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
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)?
No
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?
Yes
Does the software offer advice on preventative action to ensure
the attack does not happen again?
Each alert includes detailed �alert help� information with references to
supporting information related to the attack itself, vendor and researcher
advisories and other useful resources.
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?
N/A
Which third party event correlation systems are supported and in
what way?
Third party correlation agents are available from ArcSight, Micromuse, HP
OpenView, Tivoli Risk Manager, NetForensics, and GuardedNet (among others).
Integration with other scanning/IDS products?
N/A
Log file maintenance � automatic rotation, archiving, reporting
from archived logs, etc.
Automatic Rotation
Management reporting � range of reports/custom reports/how easy
is it to filter and extract detail? Different reports for technicians and
management/end users?
Limited - via third party tools recommended
Are trend/comparison reports available?
Yes
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
Report management � can they be scheduled for automatic
production? Can they be e-mailed to administrators or published straight to a
Web site?
No - can be accomplished via third party tools.
What are the limitations and restrictions on enterprise-wide
alerting and reporting? Can reports consolidate output from every 1) server, 2)
detector
No limitations providing using third party tools. No consolidation by default -
requires third party tools.
Ability to define custom reports?
No - third party tools required
Provide brief description of any management software included in
the base price of the product.
AI: NFR Administration Interface (AI) is a Windows-based tool used to administer
NID Sensors. AI also has facilities for analysis, querying and reporting of
alerts. (Cannot be used without CMS)
Provide brief description of any additional management products available as extra cost options. CMS: NFR Central Management Server (CMS) is a powerful facility that allows administrators to centrally manage distributed NID Sensors. It consolidates data from these NID Sensors and forwards it to databases for analysis and reporting
Documentation provided
All product documentation is provided in electronic (PDF) form. Each license
also includes 1 hard copy of documentation provided at N/C upon request.
Additional hard copies are provided for a fee.
How is the product licensed? How is the license enforced?
Each copy of the software includes an object code software license. The license
is enforced via a license key mechanism.
End user pricing information
NID-320: $18,000
AI & CMS: $5,000 (for the pair)
Ongoing cost of maintenance/updates
23% of product purchase price billed annually.
Click here to return to
the NFR NID-310 Review
Click here to return to the NFR NID-310
results
Click here to return to the IDS Index Section
Send mail to webmaster
with questions or
|