Snort Security Platform (SnortSP) 3.0 Beta with Snort 2.8.2 Detection Engine Copyright (C) 2008 Sourcefire Inc. Author: Martin Roesch [ 0.0 - PREFACE ] The Snort 3.0 architecture is a ground-up rewrite of the Snort IDP technology. The architecture of this system is very different than Snort 2.x and has a lot of new features and a different feel. The major features you may notice immediately include the debut of a command shell and the ability to interact with the system while it runs. There is one very large architectural change that long-time Snort users will notice: Snort has been essentially split into two components. The first component is the "Snort Security Platform 3.0" or SnortSP. SnortSP is designed to perform essentially as an "operating system" for packet-based network security applications. It provides common functionality that all programs that deal with packets need such as configuration loading, logging and event generation, data acquisition, decoding and validation, flow management and so on. This is the core of the Snort 3.0 architecture. The second major component are "engines" which is really more of a term to define the analysis modules that plug into SnortSP. SnortSP is designed to be able to run one or more engines, passing them traffic, processing their output and even taking action upon the traffic streams in real-time. The SnortSP beta comes with one engine module, the Snort 2.8.2 detection engine and preprocessors implemented as a SnortSP engine module. There may be more engine modules released down the road. Under the covers there are many advances including a multithreaded execution model, hooks for hardware acceleration, improved flow management, native support for IPv6, pluggable data acquisition modules, pluggable decoders, and better abstraction between subsystems in general. In aggregate there should be performance advantages to this design although it's still variable based on the system configuration. There's a bunch of other stuff too, take a look at my blog if you're interested in a more exhaustive listing (at http://securitysauce.blogspot.com). Snort (still) isn't very hard to use but there are (still) a lot of command options and combinations that are useful to know as you get comfortable with the new technology. This file aims to make getting acquainted with SnortSP easier for everyone. For the purposes of this beta test there are two main modes in which Snort can be configured: sniffer and intrusion detection/prevention system. Sniffer mode simply reads the packets off the network and displays them for you in a continuous stream on the console. In SnortSP it contains several more output modes that provide more or less data about the network traffic being observed. Network intrusion detection/prevention is the more complex and configurable operational mode, allowing SnortSP to analyze network traffic for matches against a user defined rule set and perform actions based upon what it sees. The purpose of this beta release is to allow people to get exposure to the technology and to use the code in real-world environments and to get feedback on the design and user experience of the new Snort code. All feedback on the beta should go to sspbeta@snort.org until further notice. A word on terminology: Sometimes you may see references to "the framework" and "analytics". The "framework" is the same thing as SnortSP, the platform which the network analyzers plug into. The "analytics" are another name for the engine modules that we use in Snort 3, the 2.8.2 engine module being the one set of "analytics" that's included in this release. [ 1.0 - BUILDING SNORTSP ] Requirements: * Lua 5.1.1 or better - http://www.lua.org. * Libdnet 1.10 or higher - http://libdnet.sf.net * A recent Libpcap * A UUID library. Depending on which OS you're running it may already be built in or you may need to load it as an external dependency. For example, OpenBSD 3.9 needs to have the uuid package from the ports tree installed. If your system doesn't seem to include a UUID library or you can't find one for your OS I suggest installing the e2fsprogs software from http://e2fsprogs.sf.net. NOTE: Lua and libdnet are available in the 3rdparty directory. You need to install Lua 5.1+, Libdnet 1.10+ and libpcap to build SnortSP. If you want to try out the scripts in the "etc/dir.lua" file you need to install the lfs module for Lua located at http://www.keplerproject.org/luafilesystem/index.html. Once you have all that installed, build SnortSP with the standard "./configure && make && make install" commands. After the SnortSP framework is built, the snort analytic shared object can be built. The configure command within the src/analysis/snort directory, among others, accepts the --with-platform-includes and --with-platform-libraries options. Use these to instruct the build process where to find the SnortSP framework include files and library files, respectively. The default install directory prefix is /usr/local. The includes option should be ${prefix}/include/snortsp and the libraries option should be ${prefix}/lib. Once you've established the location of those files you should execute (from the top Snort source directory): cd src/analysis/snort ./configure --with-platform-includes=/usr/local/include/snortsp --with-platform-libraries=/usr/local/lib make make install The SnortSP framework can be run by executing ${prefix}/bin/snortsp and can be controlled through the Lua command console or by executing ${prefix}/bin/snortsp_tool to connect to the UNIX socket SnortSP provides for command and control. [ 2.0 - GETTING STARTED ] SnortSP requires root privileges to startup; get root privileges and type 'snortsp'. When you start SnortSP you will see a bunch of startup text and then this: ,,_ -*> SnortSP! <*- o" )~ Version 3.0.0.b.0 (Build 9) [BETA] '''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html (C) Copyright 2008 Sourcefire Inc. snort> For those of you who have been using Snort for the past 9 years you're probably noticing that a command prompt follows the banner. SnortSP uses a command shell as its user interface now due to one of its primary design principles: it's designed to run continuously without the need to restart the entire program to load a new configuration. The command processor backing the CLI is a scripting language called Lua. Lua is a powerful light-weight programming language designed for extending applications. For more info on Lua check out http://www.lua.org. Probably the most important command to know when you're in a new interactive shell for the first time is how to quit. In Snort 3 you can simply issue the following command ssp.shutdown() The basic idea in SnortSP is to instantiate data source, engine, analyzer and output modules, link them together and then start the engine. Once the engine is running you can manage it via the command shell interface. [ 2.1 - COMMAND LINE ] Unlike Snort 2.x, there are only a few command line parameters in Snort 3. snortsp [switches] Switches: -C No Console Mode. Start without the CLI console, offer only the socket interface. You can connect to the socket interface with the ssp_tool -D Run as a daemon. -P Set the name of the PID file to , default is /var/run/SnortSP.pid. -q Run in quiet mode (suppress console output). -S Set the socketname to , default is /var/run/SnortSP.sock. -d Run in debug mode (verbose console output). -M Add a directory to search for DAQ modules. -V Print the SnortSP version and exit. -L Provide a lua script to execute at startup. -? Print the SnortSP switches and exit. [ 3.0 - SNIFFER MODE ] When you execute the snortsp command it will automatically search ./etc, /etc/snort or /usr/local/snortsp/etc (in order) for a snort.lua file and execute it when found. There's a default snort.lua that comes with the source code archive in the etc directory that contains a number of useful functions and configuration elements. To try out Sniffer mode is very straight forward, simply type: sniff("") and press [enter]. You should see something like this: snort> sniff("eth1") Creating new data source Flow manager created with 16384 flow capacity Engine "e1" created Linking engine "e1" to data source "src1" Calling engine_start() init_pcap: Initializing network interface eth1 [*] Data Source Config: Name: src1 Type: pcap Interface: eth1 Filename: Snaplen: 1514 Flags: 0x00000002 Display: None (0) Filter command: DAQ: 0x8078500 User Context: 0x80ea7d0 Max flows: 16384 Max idle: 60 Memcap: 10000000 [*] Flow Manager Config: Max flows: 16384 Max idle: 60 Memcap: 10000000 [*] DAQ config: Interface: eth1 Snaplen: 1514 Datalink: 1 Count: 0 Packet Count: 0 Promisc flag: 1 File flag: 0 pcap ptr: 0x80ea940 analysis context ptr: 0xb7252008 [*] Spawning engine thread! e1 thread running - -1222304880 (11012) Under the covers the following Lua function is being executed: function sniff (interface) dsrc1 = {name="src1", type="pcap", intf=interface, flags=2, snaplen=1514, maxflows=16384, maxidle=60, display="none", flow_memcap=10000000} dsrc.new(dsrc1) eng.new("e1") eng.link({engine="e1", source="src1"}) eng.start("e1") end This function is doing a few simple things. First off it's instantiating a configuration data structure (or array to the Lua users out there) called dsrc1 that has nine configuration parameters. Next it instantiates a new "data source" using that configuration structure. In Snort 3 the data source is the set of subsystems that handle data acquisition (e.g. pcap, af_packet), decode, flow management and IP defragmentation. Once the data source is instantiated a new engine called "e1" is instantiated. An engine contains the control logic for interfacing data sources with analysis engines such as Snort and managing data flow and the engine threads that perform any packet analysis. The next step is to link the engine to the data source, as you can see the arguments are being handed in as a configuration structure, in Lua you can hand an array to a function call as a named object as with the dsrc1 and dsrc.new() function call at the top of the function or directly as parameters to a function call as in the eng.link() call. Once the engine has been linked to the data source then the sniffing process is started with an eng.start() call. The first thing that you'll notice upon starting sniffer mode is that once the initial burst of configuration data is generated nothing happens. This is intentional since the command prompt is sharing the same console space that the sniffer output goes to, if the sniffer output is shown then your command prompt will quickly scroll off the screen. This is okay, you can still issue commands without a visible command prompt, you're just going to have to be able to type without seeing any feedback! If you'd like to see some output, you can issue a command to the program to get it to generate output (or even change its output mode) while it's running. This highlights one of the biggest changes in SnortSP: it's multithreaded so you can interact with it while it's running! To generate "classic" Snort output to the screen, simply issue the command eng.set_display({engine="e1", display="classic"}) Note that once again the parameters to the function call is an array. Once you enter this command you'll quickly lose your shell prompt, if you want to turn it back off just type eng.set_display({engine="e1", display="none"}) A smart thing to do if you've got readline/libedit/libeditline installed on your system is to type in the "display=none" command first then enter the "display=classic" command afterwards, you'll be able to use two up-arrows and an [enter] to turn the packet screen output off instead of having to type it manually. There are 5 output modes available: none, basic, classic, plus, max. To get runtime stats from the running engine you can enter eng.stats("e1") To stop the engine enter eng.stop("e1") One more thing. All of the command subsets in the Lua shell support a help function. The top level system function is called "ssp" so to see its help output just type ssp.help() There is a function reference for the entire system in section 4. [ 3.0 - NETWORK INTRUSION DETECTION/PREVENTION MODE ] Since we're still running the Snort 2.8.2.x engine under the covers for detection functionality your existing rules will still work with SnortSP. A separate document has been written to deal with migrating your existing configuration to the new platform, please read the README.bridge file for an overview of using the system in IDP mode. Please note that if you want to run inline, it is supported out of the box in SnortSP. The Beta release only supports AF_PACKET for inline operation at this time. There is an IPQ data acquisition module (DAQ) but it is untested and at the time of this writing was believed to not be in a usable state. Other inline DAQ modules may become available in the future to support other inline interfaces such as divert sockets. [ 5.0 - FUNCTION REFERENCE ] There are five groups of "system" commands available in SnortSP 3.0 for this beta: [ 5.1 - SSP ] - functions that control the operation of SnortSP. SnortSP Commands: [+] ssp.help() - Print out a list of commands available from the ssp command group. Example: snort> ssp.help() [*] SnortSP Commands: help() set_log_level( [debug|info|notice|warn|error|critical] ) shutdown() Available subsystems within SnortSP have their own help() methods: dsrc - Data Source eng - Dispatcher/Engine analyzer - Analytics Modules output - Output Modules For example: dsrc.help() will call the Data Source help function [+] ssp.set_log_level( ) - Set the level of the system logging commands that will be displayed. Available level arguments are debug, info, notice, warn, error, critical Example: snort> ssp.set_log_level("critical") [+] ssp.shutdown() - Shutdown all threads, print statistics and exit. Example: snort> ssp.shutdown() [*] ACTIVE data source src1 received 188 packets on eth1 Analyzed: 188 (100.000%) Dropped: 0 (0.000%) Idle Cycles: 192 [-] Ethernet Stats: Count: 197 [-] ARP Stats: Count: 66 [-] IPv4 Stats: Count: 134 [-] TCP Stats: Count: 128 Bad Csum: 59 [-] UDP Stats: Count: 10 Bad Csum: 1 [-] Raw Stats: Count: 159 Bytes: 6933 [*] Data Source Config: Name: src1 Type: pcap Interface: eth1 Filename: Snaplen: 1514 Flags: 0x00000002 Display: None (0) Filter command: DAQ: 0x8078500 User Context: 0x80ea7d0 Max flows: 16384 Max idle: 60 Memcap: 10000000 [*] Flow Manager Config: Max flows: 16384 Max idle: 60 Memcap: 10000000 [*] DAQ config: Interface: eth1 Snaplen: 1514 Datalink: 1 Count: 0 Packet Count: 269 Promisc flag: 1 File flag: 0 pcap ptr: 0x80ea940 analysis context ptr: 0xb729f008 e1 thread exiting - -1221989488 (22127) [*] INACTIVE data source src1 received 284 packets on eth1 Analyzed: 284 (100.000%) Dropped: 0 (0.000%) Idle Cycles: 281 [-] Ethernet Stats: Count: 280 [-] ARP Stats: Count: 66 [-] IPv4 Stats: Count: 210 [-] TCP Stats: Count: 200 Bad Csum: 94 [-] UDP Stats: Count: 10 Bad Csum: 1 [-] Raw Stats: Count: 189 Bytes: 8789 defrag statistics for mgr 0x0xb729f06c Total Fragments: 0 Total Trackers: 0 Trackers Active: 0 Trackers Released: 0 Reassembled Packets: 0 Fragments Stored: 0 Fragments Released: 0 Discards: 0 Timeouts: 0 Overlaps: 0 Anomalies: 0 Calling s_list_free_all for decoder_list Control thread exiting - -1211491440 (22127) [ 5.2 - DSRC ] - Functions to manage data sources. Data sources are a core element of SnortSP 3.0, they acquire traffic from the network, decode it, put it into the flow table subsystem and then hand it on to the rest of the analysis and reporting elements within a processing thread. DSRC commnands: [+] dsrc.new( ) - Create a new data source object using the data stored in . The is simply a Lua table with some explicit members. Example: snort> dsrc1 = {name="src1", type="pcap", intf=interface, flags=2, snaplen=1514, maxflows=16384, maxidle=10, display="max", flow_memcap=10000000} snort> dsrc.new( dsrc1 ) Creating new data source Flow manager created with 16384 flow capacity [+] dsrc.delete( ) - Delete the named data source object. Example: snort> dsrc.delete("src1") defrag statistics for mgr 0x0xb72ab06c Total Fragments: 0 Total Trackers: 0 Trackers Active: 0 Trackers Released: 0 Reassembled Packets: 0 Fragments Stored: 0 Fragments Released: 0 Discards: 0 Timeouts: 0 Overlaps: 0 Anomalies: 0 [+] dsrc.list() - Show a list of instantiated data sources. Example: snort> dsrc.list() [*] 1 data sources configured Name: src1 DAQ: pcap interface: eth1 Idle [+] dsrc.list_daq_modules() - Show a list of available data source types. Example: snort> dsrc.list_daq_modules() The following is a list of the available DAQ modules: pcap Use eth or bond<0> as the intf parameter or the filename parameter Packet based Capable of reading live interfaces Capable of reading a capture file file Use the filename parameter, the intf parameter is not used Packet based Capable of reading a capture file afpacket Use eth[:eth]... as the intf parameter Packet based Capable of reading live interfaces Capable of operating in inline mode [+] dsrc.show( ) - Show the configuration of the named data source. Example: snort> dsrc.show("src1") [*] Data Source Config: Name: src1 Type: pcap Interface: eth1 Filename: Snaplen: 1514 Flags: 0x00000002 Display: None (0) Filter command: DAQ: 0x8078500 User Context: 0x80ea7f8 Max flows: 16384 Max idle: 60 Memcap: 10000000 [*] Flow Manager Config: Max flows: 16384 Max idle: 60 Memcap: 10000000 [*] DAQ config: Interface: eth1 Snaplen: 1514 Datalink: 1 Count: 0 Packet Count: 301 Promisc flag: 1 File flag: 0 pcap ptr: 0x813add0 analysis context ptr: 0xb726c008 [+] dsrc.help() - Print out a list of commands available via the dsrc group. Example: snort> dsrc.help() [*] Data Source Config Structure = {name = , type = , intf = , flags = [1|2|8], command = , snaplen = , maxflows = , maxidle = , flow_memcap = , filename = , max_count = , display = , gtp_support = [enable] defrag = { policy = <>, max_trackers = <>, timeout = <>, memcap = <> } } name: User string used to refernce the instantiated data source object. If no name is provided a UUID is generated. type: Name of the DAQ module to use. The list of available DAQ modules can be obtained using the dsrc.list_daq_modules() command. intf: Name of the interface to use for traffic acquisition. flags: Bitwise OR of available mode flags for a given DAQ. Some modes may not be available on all DAQs. Generally you will want to use either mode 1, 2 or 8. Default is 0. To enable inline mode use a value of 10. Available modes are: 1 = FILE READ MODE 2 = PROMISC MODE 8 = INLINE MODE command: BPF filter or other filter command for DAQs that support them. Default is no filtering. snaplen: Max bytes to capture per packet. Default is 0. maxflows: Max number of flows to keep in the flow manager at one time. If this number is exceeded the least recently used flow is purged. Default is 8192. maxidle: Number of seconds a flow can be idle before being timed-out and removed from the flow table. Default is 60. flow_memcap: Max number of bytes to allow to be used by the flow table. Default is 16MB. filename: In file playback mode, specifies the name of the file to run through the SnortSP instance. max_count: Number of packets to process before stopping this thread. Default is 0, which is unlimited. display: Name of the display mode for printing packets as they are processed. Available modes are: none = Don't print packets at runtime. basic = Display basic packet info on one line. classic = Display packets using the classic tcpdump format. plus = Classic mode + MAC header printout. max = Full printout of every packet header field, one field per line. Default is none. gtp_support: Activate support for the GTP protocol. Default is disabled. defrag: Specifies the IP/IPv6 defragmentation paramters. policy: Reassmebly policy for overlapping fragments. Avaliable modes are: Default is bsd. max_trackers: The maximum number of unique packets in the process of being reassembled at a at any given time. Default is 8192. timeout: The maximum time in seconds for a fragmented packet to receive all fragments. Default is 60. memcap: Maximum number of bytes to allow to be used for fragment reassembly. Default is 32MB. [*] Data Source Commands new( ) - Instantiate a new data source object delete( ) - Delete a data source object list() - List all of the instantiated data source objects list_daq_modules() - List all of the available DAQ modules show( source_name ) - Show the config of the named object help() - Print this message For example, the following commands will create a data source using the afpacket DAQ in inline mode bridging the eth2 and eth3 interfaces allowing 262144 flows to occupy 10 MBs of memory while timing out flows after 5 minutes of idle time: dsrc1 = {name="src", type="afpacket", intf="eth2:eth3", flags=10, snaplen=0, maxflows=262144, maxidle=300, flow_memcap=10000000} dsrc.new(dsrc1) [ 5.3 - ENG ] - Functions to manage engines. Engines are the central organizing mechanism in SnortSP, an engine has a data source, analyzer(s), output manager and so on. ENG Commands: [+] eng.help() - Show a list of available engine commands. Example: snort> eng.help() [*] Engine Commands help() new( engine_name ) delete( engine_name ) link( {engine=, source=} ) unlink( engine_name ) start( engine_name ) stop( engine_name ) show( ) stats( engine_name ) run_file( engine_name, filename ) set_display( {engine=, display=} ) set_max_count( engine_name, packets ) add_analyzer( {engine=, module=, analyzer=, order=, [data=], [lb={index=, total=}], [bpf=]} ) rm_analyzer( {engine=, analyzer=} ) cfg_analyzer( {engine=, analyzer=, data=} ) show_analyzer( {engine=, analyzer=} ) add_output( {engine=, output=} ) rm_output( {engine=, output=} ) test( engine_name ) [+] eng.new( ) - Create a new engine with the name contained in . If no name string is supplied it will automatically generate a UUID and assign that as the name. Example: snort> eng.new( "eng1" ) Engine "eng1" created [+] eng.delete( ) - Delete the engine object with the name contained in . The engine should be stopped and should have unlinked its data source (i.e. you do that) before the delete operation is performed. Example: snort> eng.delete( "eng1" ) Deleting engine "eng1" [+] eng.show() - List the engine objects that are currently instantiated within SnortSP. Example: snort> eng.show() [*] 2 engine(s) configured Name: eng3 Engine: 0x307400 data_src: 0x0 running Name: eng2 Engine: 0x306e30 data_src: 0x0 idle [+] eng.link( {engine=, source=} ) - Link the named data source to the named engine. This step is needed before you can issue an eng.start() directive to an instantiated engine. Example: snort> eng.link({engine="eng1", source="dsrc1"}) Linking engine "eng1" to data source "dsrc1" [+] eng.unlink( ) - Unlink the data source from the named engine. The engine must be idle. Example: snort> eng.unlink("eng1") [+] eng.start( ) - Start the named engine. The engine must have a linked data source before it can start. Example: snort> eng.start("eng1") [*] Data Source Config: Name: src Type: pcap Interface: file Filename: /var/tmp/test.pcap Snaplen: 0 Flags: 0x00000001 Display: None (0) Filter command: DAQ: 0x80a5200 User Context: 0x812c258 Max flows: 262144 Max idle: 300 Memcap: 10000000 [*] Flow Manager Config: Max flows: 262144 Max idle: 300 Memcap: 10000000 [*] DAQ config: Interface: reading from file... Readback filename: /var/tmp/test.pcap Snaplen: 65535 Datalink: 1 Count: 0 Packet Count: 0 Promisc flag: 0 File flag: 1 pcap ptr: 0x8148250 analysis context ptr: 0xb7a96008 [*] Spawning engine thread! [+] eng.stop( ) - Stop the named engine. Example: snort> eng.stop("eng1") e1 thread exiting - 3076 (17778) [*] INACTIVE data source src1 received 0 packets on eth3 Analyzed: 0 (0.000%) Dropped: 0 (0.000%) Idle Cycles: 1932 [+] eng.stats( ) - Print out packet stats for the named engine. Example: snort> eng.stats("eng1") [*] ACTIVE data source src1 received 0 packets on eth3 Analyzed: 0 (0.000%) Dropped: 0 (0.000%) Idle Cycles: 15 [+] eng.run_file( , ) - Run the named file through the named engine. The engine must be instantiated and have a linked data source with an interface type set to "file". Example: snort> eng.run_file("eng1", "foo.pcap") [+] eng.set_display( {engine=, display=} ) - Set the run mode of the named engine to . Available modes include none, basic, classic, plus and max. Note that the arguments are supplied as a Lua array so the curley braces are required as are the field names. This can be used to change the packet dump output format on a running engine. Example: snort> eng.set_display({engine="eng1", display="max"}) Setting runtime display flags to 4 [+] eng.set_max_count( , ) - Have the named engine stop after processing packets. Example: snort> eng.set_max_count("eng1" , 1000) [+] eng.add_analyzer( {engine=, module=, order=, analyzer=, [data=], [lb={index=, total=}], [bpf=]} ) - Add an analyzer instance with the given name and configuration to the named engine using the given execution order relative to the other engine analytics. Example: snort> snort="/usr/local/ssp/lib/snort/snort.so" snort> opttab={ >> dynamic_engine_lib="/usr/local/ssp/lib/snort/sf_engine.so", >> dynamic_preprocessor_lib_dir="/usr/local/ssp/lib/snort/snort_preproc", >> M="true", Q="true", c="ssp.conf", Z="/var/tmp/now", l="/var/tmp"} snort> eng.add_analyzer({engine="eng1", module=snort, order=1, analyzer="snort", data=opttab}) Adding analyzer "snort" to engine "eng1" ,,_ -*> Snort Analytic! <*- o" )~ Version 3.0.0 (Build 16) pc '''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html (C) Copyright 1998-2007 Sourcefire Inc., et al. Using PCRE version: 6.4 05-Sep-2005 Rules Engine: SF_SNORT_DETECTION_ENGINE Version 1.8 Preprocessor Object: SF_FTPTELNET (IPV6) Version 1.1 Preprocessor Object: SF_DCERPC (IPV6) Version 1.1 Preprocessor Object: SF_SMTP (IPV6) Version 1.1 Preprocessor Object: SF_SSLPP (IPV6) Version 1.0 Preprocessor Object: SF_SSH (IPV6) Version 1.1 Preprocessor Object: SF_DNS (IPV6) Version 1.1 [*] Spawning analyzer thread - 0/0! [+] eng.rm_analyzer( {engine=, analyzer=}) - Remove the given analyzer instance from the named engine. Example: snort> eng.rm_analyzer({engine="eng1", analyzer="snort"}) Removing analyzer "snort" from engine "eng1" Run time for packet processing was 77.951628 seconds Pkts = 0, Secs = 78 /usr/local/ssp/lib/snort/snort.so thread exiting - 2051 (19534) Snort processed 0 packets. [+] eng.cfg_analyzer( {engine=, analyzer=, data=} ) - Configure the given analytic instance of the named engine with the given configuration data. Example: snort> eng.cfg_analyzer({engine="eng1", analyzer="snort", data={cmd="stats"}}) Snort processed 0 packets. [+] eng.show_analyzer( {engine=, analyzer=} ) - Show the configuration of the given analytic instance of the named engine. Example: snort> eng.show_analyzer({engine="eng1", analyzer="snort"}) [*] Snort Version 3.0.0 Build(16) [*] snort = 0 Snort processed 0 packets. [+] eng.add_output( {engine=, output=} ) - Add the given output instance of the named engine. Example: snort> eng.add_output({engine="eng1", output="unified2"}) Adding output "unified2" to engine "eng1" [*] Spawning output thread! dispatcher output thread running - 4101 (22354) [+] eng.rm_output( {engine=, output=} ) - Remove the given output instance from the named engine. Example: snort> eng.rm_output({engine="eng1", output="unified2"}) Removing output "unified2" from engine "eng1" Dispatcher output thread exiting - 4101 (22354) [+] eng.test( ) - Start the named engine and don't return until the data source has completed packet processing. The data source must have a packet limit or be reading from a file. Example: snort> eng.test("eng1") daq_init: Opening file "/var/tmp/test.pcap" [*] Data Source Config: Name: src1 Type: file Interface: file Filename: /var/tmp/test.pcap Snaplen: 0 Flags: 0x00000001 Display: None (0) Filter command: DAQ: 0x80a5700 User Context: 0x8122d40 Max flows: 262144 Max idle: 300 Memcap: 10000000 [*] Flow Manager Config: Max flows: 262144 Max idle: 300 Memcap: 10000000 [*] DAQ config: Filename: /var/tmp/test.pcap Snaplen: 1514 Datalink: 1 Count: 0 Packet Count: 0 File ptr: 0x817ae08 analysis context ptr: 0xb7a8e008 [*] Spawning engine thread! e thread running - 4101 (22571) e thread exiting - 4101 (22571) [*] INACTIVE data source src received 1018323 packets on file Analyzed: 1018323 (100.000%) Dropped: 0 (0.000%) Idle Cycles: 1 [-] Ethernet Stats: Count: 1023780 [-] ARP Stats: Count: 1408 [-] IPv4 Stats: Count: 1012853 Bad version: 50 Bad field: 124657 [-] IPv6 Stats: Count: 23 Bad version: 22 Bad field: 1 [-] TCP Stats: Count: 765345 Long: 1 Bad Csum: 1913 Bad field: 62 [-] UDP Stats: Count: 42481 Runts: 531 Long: 101 Bad Csum: 5252 Bad field: 1 [-] ICMP Stats: Count: 13703 Runts: 6 Bad Csum: 10 [-] Raw Stats: Count: 502998 Bytes: 186820010 [ 5.4 ANALYZER ] - Functions to manage analytics. Analyzers are the modules that analyze the packet data and generate the appropriate events. ANALYZER Commands: [*] analyzer.help( [ ) - Show a list of available analyzer commands if no module is specified, otherwise show the help message for the given analyzer module. Example: snort> analyzer.help() [*] Analyzer Commands help([]) cfgtest({module=, order=, [bpf=], [lb={index=, total=}], [data={}] }) [+] analyzer.cfgtest( {module=, order=, [bpf=], [lb={index=, total=}], [data={}]} ) - Instantiate the given analyzer module with the given configuration. This reports errors within the given configuration, but does not result in an actual analytic instance. Example: snort> opttab={ >> dynamic_engine_lib="/usr/local/ssp/lib/snort/sf_engine.so", >> dynamic_preprocessor_lib_dir="/usr/local/ssp/lib/snort/snort_preproc" >> , M="true", Q="true", c="ssp.conf", Z="/var/tmp/now", l="/var/tmp"} snort> analyzer.cfgtest({module="/usr/local/ssp/lib/snort/snort.so", order=1, data=opttab}) ,,_ -*> Snort Analytic! <*- o" )~ Version 3.0.0 (Build 16) pc '''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html (C) Copyright 1998-2007 Sourcefire Inc., et al. Using PCRE version: 6.4 05-Sep-2005 Rules Engine: SF_SNORT_DETECTION_ENGINE Version 1.8 Preprocessor Object: SF_FTPTELNET (IPV6) Version 1.1 Preprocessor Object: SF_DCERPC (IPV6) Version 1.1 Preprocessor Object: SF_SMTP (IPV6) Version 1.1 Preprocessor Object: SF_SSLPP (IPV6) Version 1.0 Preprocessor Object: SF_SSH (IPV6) Version 1.1 Preprocessor Object: SF_DNS (IPV6) Version 1.1 Snort processed 0 packets. [ 5.5 - OUTPUT ] - Functions to manage outputs. Outputs are modules that can be configured to output events generated by the analytic instances. OUTPUT Commands: [+] output.help( [ ) - Show a list of available output commands if no module is specified, otherwise show the help message for the given output module. Example: snort> output.help() [*] Output Commands help() new( {module=, name=} ) destroy( name ) show( name ) config( {name=, data=} ) list() [+] output.new( {module=, name=} ) - Create a new output instance of the given module with the given name. Example: snort> output.new({module="/usr/local/ssp/lib/snortsp/unified2.so", >> name="unified2"}) [+] output.destroy( ) - Destroy the named output instance. Example: snort> output.destroy( "unified2" ) [*] output.show( ) - Show the configuration of the named output instance. Example: snort> output.show( "unified2" ) [*] unified2 output Base name: unified2.bin Timeout: 86400 Size limit: 20971520 [+] output.config( {name=, data=}) - Configure the named output instance with the given output specific configuration data. Example: snort> output.config( {name="unified2", data={basename="snort.bin"}} ) [+] output.list() - Show the list of output instances. Example: snort> output.list() [*] 1 output module(s) Module: /usr/local/ssp/lib/snortsp/unified2.so Output: 0xa432f504