Snort 1.8.1

Brief product description��
Snort is an open source network intrusion detection system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more. Snort uses a flexible rules language to describe traffic that it should collect or pass, as well as a detection engine that utilises a modular plugin architecture. Snort also has a modular real-time alerting� capability, incorporating alerting and logging plugins for syslog,� ASCII text files, UNIX sockets, WinPopup messages to Windows clients using Samba's smbclient, database� (Mysql/PostgreSQL/Oracle/ODBC), XML or SNMP.

Architecture
Snort can be deployed as a single point network IDS sensor or in a distributed fashion. It's really up to the user how it's deployed - due to its open source nature Snort is generally deployed in a "roll your own" style. There are known deployments of Snort that use distributed sensors with centralised management in extremely large deployments (in government and industry). The most popular configurations of Snort include centralised logging and data analysis with tools like ACID (http://acidlab.sourceforge.net), SnortSnarf (http://www.silicondefense.com/snortsnarf) and Demarc (http://demarc.org).�

Distributed sensor management is generally performed via SSH and text editors.�

At what layer of the protocol stack is the product working?
Snort is capable of performing traffic analysis from the network layer to the application layer.

Documentation
A vast array of documentation is available both in the distribution and at http://www.snort.org. There is a FAQ, getting started guide, manual, rules creation guide, etc. For people truly interested in the inner workings of the system, the source code is also available.

What are the minimum/recommended console OS and hardware requirements? Is a dedicated machine required/recommended? Will it work on Windows 2000?
Any management console will be a roll your own exercise. A MySQL database running on Linux is frequently used as a central console along with ACID on PHP/Apache. Generally, something on the order of a 300MHz Celeron with 64 MB of RAM is adequate for this configuration. For more high performance (many sensors, high event load, etc) configurations, more horsepower will be required.

What are the minimum/recommended agent OS and hardware requirements? Is a dedicated machine required/recommended? Will it work on Windows 2000?
Minimum recommendations are dependent on the network being monitored.� Absolute minimums would probably be a Pentium 133 with 32MB of RAM and an Ethernet card with Linux. Snort runs on ~25 platforms currently, including Windows 2000 (and MacOS X).

A dedicated machine is not required and Snort's system overhead is generally quite low. For high performance environments a dedicated machine with a lot more power is recommended.

What components are installed on a detector
Snort binary and libpcap are the minimum requirements. Other libraries may be required depending on options that are compiled into a particular build of Snort.

Which network types are supported
Token Ring, FDDI, 10/100/1000 Ethernet, SLIP, PPP, PPPoE, Linux SLL and ISDN are supported in the default install. Gigabit Ethernet is possible, but packet capture mechanisms must be heavily modified to enable Snort to process more than 300Mbps successfully.

Any specific recommendations for monitoring Gigabit networks with your product?
Without extensive software modifications (libpcap is a bottleneck and needs to be modified for highest performance), the best method will be to load balance several sensors with a layer 7 switch and selectively tune rules/configuration.

Which OS platforms are actively monitored?
Any platform on the network.

Can sensors/detectors be deployed and configured initially from a central console?
Roll your own.

Once deployed and configured, can sensors/detectors be managed from a central console?
Roll your own. Alerts can be viewed/managed from a central console with relative ease and there are a variety of remote management scripts and tools available.

Authentication between console and engines � Is it available? What algorithm/key lengths?
Tools like SSH, stunnel and Free S/WAN can be integrated with the existing tools easily.

Secure logon for policy management?
SSH.

How are policies distributed to engines?
SSH/scp, ftp, cron jobs, etc.

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?
All policy changes are handled manually or through scripts.

How many attack signatures?
1257 + 34 event generation conditions in the preprocessor system.

Can the administrator define custom attack signatures?
Yes.

How are new attack signatures obtained and deployed?
Daily updates are available on snort.org, diffs are available from the Snort CVS archives.

Frequency of signature updates? Provide dates of all updates in the last year.
Updates are daily/weekly. Rules management was moved to CVS this past March, update info is available from that time frame:

A 03/10 15:42 +0000 roesch 1.1 backdoor.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 ddos.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 dns.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 dos.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 exploit.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 finger.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 ftp.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 icmp.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 info.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 local.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 misc.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 netbios.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 policy.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 rpc.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 rservices.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 scan.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 smtp.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 telnet.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 web-cgi.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 web-coldfusion.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 web-frontpage.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 web-iis.rules snort == <remote>
A 03/10 15:42 +0000 roesch 1.1 web-misc.rules snort == <remote>
M 03/17 05:08 +0000 roesch 1.2 exploit.rules snort == <remote>
M 03/17 05:15 +0000 roesch 1.3 exploit.rules snort == <remote>
M 03/17 05:58 +0000 roesch 1.2 scan.rules snort == <remote>
M 03/26 02:00 +0000 roesch 1.2 dns.rules snort == <remote>
M 03/26 02:00 +0000 roesch 1.2 local.rules snort == <remote>
M 03/26 02:00 +0000 roesch 1.2 misc.rules snort == <remote>
M 03/26 02:00 +0000 roesch 1.2 rpc.rules snort == <remote>
M 03/29 23:00 +0000 roesch 1.3 misc.rules snort == <remote>
M 04/07 22:55 +0000 roesch 1.5 misc.rules snort == <remote>
M 04/16 02:13 +0000 roesch 1.2 x11.rules snort == <remote>
M 04/17 05:31 +0000 roesch 1.8 exploit.rules snort == <remote>
M 04/27 06:06 +0000 roesch 1.5 ddos.rules snort == <remote>
M 05/09 03:42 +0000 roesch 1.5 telnet.rules snort == <remote>
M 05/09 03:42 +0000 roesch 1.6 policy.rules snort == <remote>
M 06/11 05:49 +0000 roesch 1.6 telnet.rules snort == <remote>
M 06/21 22:22 +0000 roesch 1.10 misc.rules snort == <remote>
M 06/26 02:14 +0000 roesch 1.8 telnet.rules snort == <remote>
M 06/28 14:49 +0000 roesch 1.3 shellcode.rules snort == <remote>
M 06/28 16:43 +0000 roesch 1.4 shellcode.rules snort == <remote>
M 07/05 02:47 +0000 roesch 1.12 misc.rules snort == <remote>
M 07/19 21:30 +0000 roesch 1.3 local.rules snort == <remote>
M 07/19 21:30 +0000 roesch 1.4 local.rules snort == <remote>
M 07/25 03:13 +0000 roesch 1.9 telnet.rules snort == <remote>
M 07/25 03:27 +0000 roesch 1.10 telnet.rules snort == <remote>
M 07/25 03:28 +0000 roesch 1.11 telnet.rules snort == <remote>
M 08/07 02:18 +0000 roesch 1.17 web-iis.rules snort == <remote>
M 08/09 00:16 +0000 roesch 1.10 dos.rules snort == <remote>
M 08/13 15:21 +0000 roesch 1.9 icmp.rules snort == <remote>

What infrastructure do you have behind the signature update process
The Snort user community, consisting of tens of thousands of users, generates rules continuously. There are 5 people who dedicate most of their time on the project to rules management and creation. Quality control is maintained by myself and one other "gatekeeper" to the official rule set.

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?
Updates can be downloaded and distributed to sensors from a single point.

Can signature updates be scheduled and fully automated?
Yes, via scripting and cron jobs. There are scripts already created to do this.

What network protocols are analysed?
ARP, IP, TCP, UDP, ICMP, all application layer protocols can be analysed, as well as transport layers beyond tcp/udp/icmp.

What application-level protocols are analysed?
Snort uses a pattern matching system to analyse the application layer, so in theory all non-encrypted application layer protocols can be analysed.

Can the product perform protocol decodes?
Yes.

Can the product perform session recording on suspect sessions?
Yes, via the tagging rules option.

Block/tear down session?
Yes.

Ability to monitor user-defined connections (i.e. report on an FTP connection to a specific server?)
Yes.

Monitor changes in critical system files?
Possibly, depends on available attack vectors (i.e. network vectors only).

Monitor changes in user-defined files?
As above.

Monitor changes in Registry?
As above.

Monitor unauthorised access to files?
As above.

Monitor administrator activity (creation of new users, etc)?
As above.

Monitor excessive failed logins?
As above.

List any other resources/locations that are monitored.
All network accessible resources may potentially be monitored.

Track successful logins, monitoring subsequent file activity, etc?
As above.

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?
Yes.

Perform packet reassembly? Resistance to known IDS evasion techniques?
Yes.

Reconfigure firewall? If so, which firewall(s) and how?
Yes, iptables/ipchains. OPSEC module is in development.

Option to record everything for �forensic� investigation? Where is this data stored? How is it secured from tampering?
Implementation dependent. Recording option is available, data can be stored in any suitable device. Anti-tampering may be achieved with encrypted filesystems, tripwire-like cryptographic checksumming, etc.

Reporting from engine to console - range of action/alert options
Syslog, SNMP, email, pager, database, XML, and pcap formats are available.

What provision is made for temporary communications interruption between detector and console? Where are alerts stored? Is the repository secure?
Reports can be stored on the sensor or sent to the remote management point. There is no built-in auto-recovery mechanism for downed communications channels. Since the output system is modular and open, adding a more robust system can certainly be done by the end user or the Snort developers community.

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. Events can be extracted via the standard interfaces (i.e. ACID, SnortSnarf, etc) or with standard shell tools (grep, sed, etc).

Does the software offer advice on preventative action to ensure the attack does not happen again?
Not at this time, although links to external databases such as Bugtraq and arachNIDS are contained within much of the alert data.

Integration with other scanning/IDS products?
The Nessus tool can generate Snort rules and there are currently discussions under way with the IpTables and ipfilter guys to support interoperability between our products.

Log file maintenance � automatic rotation, archiving, reporting from archived logs, etc.
Yes, there are a variety of mechanism available to perform these tasks.

Management reporting � range of reports/custom reports/how easy is it to filter and extract detail? Different reports for technicians and management/end users?
Extraction and filtration of Snort data is quite easy and there are a variety of tools available to accomplish this. There are also some reporting tools available like SnortSnarf and SnortReport.

Report management � can they be scheduled for automatic production? Can they be e-mailed to administrators or published straight to a Web site?
Yes, all scripted by the users (nothing built in at this time).

What are the limitations and restrictions on enterprise-wide alerting and reporting? Can reports consolidate output from every 1) server, 2) detector
Limitations are available bandwidth, network topology, and console performance capabilities. Reports can be consolidated via available tools.

Define custom reports?
Roll your own.

How is it licensed? How is the license enforced?
GPL licensed, enforcement is by peer pressure and the standards of acceptable conduct.

Any other unique selling points?
Only open source solution available, massively flexible, high performance, extensible.

End user pricing information in USD and GBP
Open source � free for non-commercial use

Ongoing cost of maintenance/updates
Contact Silicon Defense for pricing

Click here to return to the Snort 1.8.1 Review
Click here to return to Snort 1.8.1 Results
Click here to return to the IDS Index Section