concepts.txt
connectors.txt
daq.txt
- daq_readme.txt
dcerpc.txt
differences.txt
enviro.txt
applications and the modular nature allows you to build new modules for
other platforms.
-The DAQ library is provided as a separate package on the official Snort
-download site (https://snort.org/downloads) and contains a number of DAQ
-modules including PCAP, AFPacket, NFQ, IPFQ, Netmap, and Dump implementations.
+The DAQ library exists as a separate repository on the official Snort 3 GitHub
+project (https://github.com/snort3/libdaq) and contains a number of bundled DAQ
+modules including AFPacket, Divert, NFQ, PCAP, and Netmap implementations.
Snort 3 itself contains a few new DAQ modules mostly used for testing as
described below. Additionally, DAQ modules developed by third parties to
facilitate the usage of their own hardware and software platforms exist.
=== Building the DAQ Library and Its Bundled DAQ Modules
-Refer to the README in the LibDAQ source tarball for instructions on how to
+Refer to the READMEs in the LibDAQ source tarball for instructions on how to
build the library and modules as well as details on configuring and using the
bundled DAQ modules.
-A copy of the README from LibDAQ has been included in the Reference section of
-this manual for convenience. For the most up-to-date information, please refer
-to the version that came with your installation's source code.
-
=== Configuration
As with a number of features in Snort 3, the LibDAQ and DAQ module
-configuration may be controlled using either the command line options or direct
-Snort module configuration.
+configuration may be controlled using either the command line options or by
+configuring the 'daq' Snort module in the Lua configuration.
DAQ modules may be statically built into Snort, but the more common case is to
use DAQ modules that have been built as dynamically loadable objects. Because
of this, the first thing to take care of is informing Snort of any locations it
should search for dynamic DAQ modules. From the command line, this can be done
-with one or more invocations of the --daq-dir option, which takes a path to
-search as its argument. All arguments will be collected into a list of
-locations to be searched. In the Lua configuration, the 'module_dirs' property
-of the 'daq' Snort module is a list of paths for the same purpose.
-
-Next, one must select which DAQ module they wish to use by name. This is done
-using the --daq option from the command line or the 'module' property of the
-'daq' Snort module. To get a list of the available modules, run Snort with the
---daq-list option making sure to specify any DAQ module search directories
-beforehand. If no DAQ module is specified, Snort will default to attempting to
-find and use the 'pcap' DAQ module.
+with one or more invocations of the --daq-dir option, which takes a
+colon-separated set of paths to search as its argument. All arguments will be
+collected into a list of locations to be searched. In the Lua configuration, the
+'daq.module_dirs[]' property is a list of paths for the same purpose.
+
+Next, one must select which DAQ modules they wish to use by name. At least one
+base module and zero or more wrapper modules may be selected. This is done
+using the --daq options from the command line or the 'daq.modules[]' list-type
+property. To get a list of the available modules, run Snort with the --daq-list
+option making sure to specify any DAQ module search directories beforehand. If
+no DAQ module is specified, Snort will default to attempting to find and use a
+DAQ module named 'pcap'.
Some DAQ modules can be further directly configured using DAQ module variables.
All DAQ module variables come in the form of either just a key or a key and a
value separated by an equals sign. For example, 'debug' or 'fanout_type=hash'.
The command line option for specifying these is --daq-var and the configuration
-file equivalent is the 'variables' property of the 'daq' Snort module.
+file equivalent is the 'daq.modules[].variables[]' property. The available
+variables for each module will be shown when listing the available DAQ modules
+with --daq-list.
The LibDAQ concept of operational mode (passive, inline, or file readback) is
-not directly configurable but instead inferred from other Snort configuration.
-The DAQ module acquisition timeout is always configured to 1 second and the
-packet capture length (snaplen) is configured by the -s command line option and
-defaults to 1514 bytes.
+automatically configured based on inferring the mode from other Snort
+configuration. The presence of -r or --pcap-* options implies 'read-file', -i
+without -Q implies 'passive', and -i with -Q implies 'inline'. The mode can be
+overridden on a per-DAQ module basis with the --daq-mode option on the command
+line or the 'daq.modules[].mode' property.
+
+The DAQ module receive timeout is always configured to 1 second. The packet
+capture length (snaplen) defaults to 1518 bytes and can be overridden by the -s
+command line option or 'daq.snaplen' property.
Finally, and most importantly, is the input specification for the DAQ module.
In readback mode, this is simply the file to be read back and analyzed. For
input specification as required by the DAQ module to understand what to operate
upon. From the command line, the -r option is used to specify a file to be
read back and the -i option is used to indicate a live interface input
-specification. Both are covered by the 'input_spec' property of the 'daq'
-Snort module.
+specification. Both are covered by the 'daq.inputs[]' property.
+
+For advanced use cases, one additional LibDAQ configuration exists: the number
+of DAQ messages to request per receive call. In Snort, this is referred to as
+the DAQ "batch size" and defaults to 64. The default can be overridden with
+the --daq-batch-size command line option or 'daq.batch_size' property. The
+message pool size requested from the DAQ module will be four times this batch
+size.
+
==== Command Line Example
snort --daq-dir /usr/local/lib/daq --daq-dir /opt/lib/daq --daq afpacket
---daq-var debug --daq-var fanout_type=hash -i eth1:eth2
+--daq-var debug --daq-var fanout_type=hash -i eth1:eth2 -Q
+
==== Configuration File Example
'/usr/local/lib/daq',
'/opt/lib/daq'
},
- module = 'afpacket',
- input_spec = 'eth1:eth2',
- variables =
- {
- 'debug',
- 'fanout_type=hash'
- }
- }
-
-==== Interaction With Multiple Packet Threads
-
-DAQ configuration can become much more complicated as additional packet threads
-are introduced. To allow for more flexibility in configuring DAQ module
-instances, each packet thread can be configured with its own input
-specification and/or DAQ module variables, which creates two classes of each:
-instance-specific and global. Global DAQ module variables are those defined
-before any -i option on the command line or in the top-level 'variables'
-property demonstrated in the previous section. The global input specification
-is defined by either the first -i option on the command line (which doubles as
-the input specification for instance 0) or the top-level 'input_spec' in the
-i'daq' Snort module. Instance-specific input specifiers are configured on the
-command line by giving multiple -i options. In the same way, instance-specific
-DAQ module variables on the command line are declared normally but follow and
-apply only to the instance operating on the last -i option. When configuring
-through Lua, the 'instances' property of the 'daq' Snort module is a list of
-tables, each defining instance-specific configuration for a given instance ID.
-
-Each packet thread will create an instance of the chosen DAQ
-module using the global interface specification and global set of DAQ module
-variables *unless* they were overridden with instance-specific values. When
-DAQ module instances are configured, any global DAQ modules will be set and
-then any instance-specific DAQ variables. This means that an instance will
-"inherit" the global DAQ modules and can override those by specifying them
-again with different values or add to them by specifying new variables
-entirely.
-
-Here is the configuration for a hypothetical AFPacket DAQ module that has been
-modified to loadbalance based on DAQ variables (lb_total is the total number of
-instances to loadbalance across and is set globally, and lb_id is the
-instance's loadbalancing ID within that total and is set per-instance) across 4
-packet processing threads within Snort:
-
- daq =
- {
- module_dirs =
- {
- '/usr/local/sf/lib/daq'
- },
- module = 'afpacket',
- input_spec = 'eth1',
- variables =
- {
- 'lb_total=4'
- },
- instances =
+ modules =
{
{
- id = 0,
+ name = 'afpacket',
+ mode = 'inline',
variables =
{
- 'lb_id=1',
+ 'debug',
+ 'fanout_type=hash'
}
- },
- {
- id = 1,
- variables =
- {
- 'lb_id=2',
- }
- },
- {
- id = 2,
- variables =
- {
- 'lb_id=3',
- }
- },
- {
- id = 3,
- variables =
- {
- 'lb_id=4',
- }
- },
- }
+ }
+ },
+ inputs =
+ {
+ 'eth1:eth2',
+ },
+ snaplen = 1518
}
-The equivalent command line invocation would look like this (made uglier by the
-lack of needing a different input specification for each thread):
+The 'daq.snaplen' property was included for completeness and may be omitted if
+the default value is acceptable.
- snort --daq-dir /usr/local/sf/lib/daq --daq afpacket --daq-var lb_total=4 -i
-eth1 --daq-var lb_id=1 -i eth1 --daq-var lb_id=2 -i eth1 --daq-var lb_id=3 -i
-eth1 --daq-var lb_id=4 -z 4
+
+==== DAQ Module Configuration Stacks
+
+Like briefly mentioned above, a DAQ configuration consists of a base DAQ module
+and zero or more wrapper DAQ modules. DAQ wrapper modules provide additional
+functionality layered on top of the base module in a decorator pattern. For
+example, the Dump DAQ module will capture all passed or injected packets and
+save them to a PCAP savefile. This can be layered on top of something like the
+PCAP DAQ module to assess which packets are making it through Snort without
+being dropped and what actions Snort has taken that involved sending new or
+modified packets out onto the network (e.g., TCP reset packets and TCP
+normalizations).
+
+To configure a DAQ module stack from the command line, the --daq option must
+be given multiple times with the base module specified first followed by the
+wrapper modules in the desired order (building up the stack). Each --daq
+option changes which module is being configured by subsequent --daq-var and
+--daq mode options.
+
+When configuring the same sort of stack in Lua, everything lives in the
+'daq.modules[]' property. 'daq.modules[]' is an array of module configurations
+pushed onto the stack from top to bottom. Each module configuration *must*
+contain the name of the DAQ module. Additionally, it may contain an array of
+variables ('daq.modules[].variables[]') and/or an operational mode
+('daq.modules[].mode').
+
+If only wrapper modules were specified, Snort will default to implicitly
+configuring a base module with the name 'pcap' in 'read-file' mode. This is a
+convenience to mimic the previous behavior when selecting something like the
+old Dump DAQ module that may be removed in the future.
For any particularly complicated setup, it is recommended that one configure
via a Lua configuration file rather than using the command line options.
+=== Interaction With Multiple Packet Threads
+
+All packet threads will receive the same DAQ instance configuration with the
+potential exception of the input specification.
+
+If Snort is in file readback mode, a full set of files will be constructed from
+the -r/--pcap-file/--pcap-list/--pcap-dir/--pcap-filter options. A number of
+packet threads will be started up to the configured maximum (-z) to process
+these files one at a time. As a packet thread completes processing of a file,
+it will be stopped and then started again with a different file input to
+process. If the number of packet threads configured exceeds the number of
+files to process, or as the number of remaining input files dwindles below that
+number, Snort will stop spawning new packet threads when it runs out of
+unhandled input files.
+
+When Snort is operating on live interfaces (-i), all packet threads up to the
+configured maximum will always be started. By default, if only one input
+specification is given, all packet threads will receive the same input in their
+configuration. If multiple inputs are given, each thread will be given the
+matching input (ordinally), falling back to the first if the number of packet
+threads exceeds the number of inputs.
+
+
=== DAQ Modules Included With Snort 3
==== Socket Module
but it is still inspected.
Each read from a socket of up to snaplen bytes is passed as a packet to
-Snort along with a DAQ_SktHdr_t pointer in DAQ_PktHdr_t->priv_ptr.
-DAQ_SktHdr_t conveys IP4 address, ports, protocol, and direction. Socket
+Snort along with the ability to retrieve a DAQ_UsrHdr_t structure via ioctl.
+DAQ_UsrHdr_t conveys IP4 address, ports, protocol, and direction. Socket
packets can be configured to be TCP or UDP. The socket DAQ can be operated
in inline mode and is able to block packets.
-The socket DAQ uses DLT_SOCKET and requires that Snort load the socket
-codec which is included in the extra package.
+Packets from the socket DAQ module are handled by Snort's stream_user module,
+which must be configured in the Snort configuration.
To use the socket DAQ, start Snort like this:
- ./snort --plugin-path /path/to/lib/snort_extra \
+ ./snort --daq-dir /path/to/lib/snort_extra/daq \
--daq socket [--daq-var port=<port>] [--daq-var proto=<proto>] [-Q]
<port> ::= 1..65535; default is 8000
==== File Module
-The file module provides the ability to process files directly w/o having
-to extract them from pcaps. Use the file module with Snort's stream_file
-to get file type identification and signature services. The usual IPS
-detection and logging etc. is available too.
+The file module provides the ability to process files directly without having
+to extract them from pcaps. Use the file module with Snort's stream_file to
+get file type identification and signature services. The usual IPS detection
+and logging, etc. is also available.
You can process all the files in a directory recursively using 8 threads
with these Snort options:
$packet <addr> <port> -> <addr> <port>
- $sof <i32:ingressZone> <i32:egressZone> <i32:ingressIntf> <i32:egressIntf> <s:srcIp> <i16:srcPort> <s:destIp> <i16:dstPort> <u32:opaque> <u64:initiatorPkts> <u64:responderPkts> <u64:initiatorPktsDropped> <u64:responderPktsDropped> <u64:initiatorBytesDropped> <u64:responderBytesDropped> <u8:isQosAppliedOnSrcIntf> <timeval:sof_timestamp> <timeval:eof_timestamp> <u16:vlan> <u16:address_space_id> <u8:protocol>
- $eof <i32:ingressZone> <i32:egressZone> <i32:ingressIntf> <i32:egressIntf> <s:srcIp> <i16:srcPort> <s:destIp> <i16:dstPort> <u32:opaque> <u64:initiatorPkts> <u64:responderPkts> <u64:initiatorPktsDropped> <u64:responderPktsDropped> <u64:initiatorBytesDropped> <u64:responderBytesDropped> <u8:isQosAppliedOnSrcIntf> <timeval:sof_timestamp> <timeval:eof_timestamp> <u16:vlan> <u16:address_space_id> <u8:protocol>
+ $sof <i32:ingressZone> <i32:egressZone> <i32:ingressIntf> <i32:egressIntf> <s:srcIp> <i16:srcPort> <s:destIp> <i16:dstPort> <u32:opaque> <u64:initiatorPkts> <u64:responderPkts> <u64:initiatorPktsDropped> <u64:responderPktsDropped> <u64:initiatorBytesDropped> <u64:responderBytesDropped> <u8:isQosAppliedOnSrcIntf> <timeval:sof_timestamp> <timeval:eof_timestamp> <u16:vlan> <u16:address_space_id> <u8:protocol>
+ $eof <i32:ingressZone> <i32:egressZone> <i32:ingressIntf> <i32:egressIntf> <s:srcIp> <i16:srcPort> <s:destIp> <i16:dstPort> <u32:opaque> <u64:initiatorPkts> <u64:responderPkts> <u64:initiatorPktsDropped> <u64:responderPktsDropped> <u64:initiatorBytesDropped> <u64:responderBytesDropped> <u8:isQosAppliedOnSrcIntf> <timeval:sof_timestamp> <timeval:eof_timestamp> <u16:vlan> <u16:address_space_id> <u8:protocol>
Client and server are determined as follows. $packet -> client indicates
to the client (from server) and $packet -> server indicates a packet to the
$sof and $eof commands generate Start of Flow and End of Flow metapackets
respectively. They are followed by a definition of a Flow_Stats_t data structure
-which will be fed into Snort via the metadata callback.
+which will be fed into Snort via the metadata callback.
Strings may contain the following escape sequences:
+++ /dev/null
-Snort 2.9 introduces the DAQ, or Data Acquisition library, for packet I/O. The
-DAQ replaces direct calls to libpcap functions with an abstraction layer that
-facilitates operation on a variety of hardware and software interfaces without
-requiring changes to Snort. It is possible to select the DAQ type and mode
-when invoking Snort to perform pcap readback or inline operation, etc. The
-DAQ library may be useful for other packet processing applications and the
-modular nature allows you to build new modules for other platforms.
-
-This README summarizes the important things you need to know to use the DAQ.
-
-
-==== Building the DAQ Library and DAQ Modules
-
-The DAQ is bundled with Snort but must be built first using these steps:
-
- ./configure
- make
- sudo make install
-
-This will build and install both static and dynamic DAQ modules.
-
-Note that pcap >= 1.5.0 is required. pcap 1.8.1 is available at the time
-of this writing and is recommended.
-
-Also, libdnet is required for IPQ and NFQ DAQs. If you get a relocation error
-trying to build those DAQs, you may need to reinstall libdnet and configure it
-with something like this:
-
- ./configure "CFLAGS=-fPIC -g -O2"
-
-You may also experience problems trying to find the dynamic dnet library
-because it isn't always named properly. Try creating a link to the shared
-library (identified by its .x or .x.y etc. extension) with the same name but
-with ".so" inserted as follows:
-
- $ ln -s libdnet.1.1 libdnet.so.1.1
- $ ldconfig -Rv /usr/local/lib 2>&1 | grep dnet
- Adding /usr/local/lib/libdnet.so.1.1
-
-Alternatively, you should be able to fix both issues as follows:
-
- libtoolize --copy --force
- aclocal -I config
- autoheader
- autoconf
- automake --foreign
-
-When the DAQ library is built, both static and dynamic flavors will be
-generated. The various DAQ modules will be built if the requisite headers and
-libraries are available. You can disable individual modules, etc. with options
-to configure. For the complete list of configure options, run:
-
- ./configure --help
-
-
-==== PCAP Module
-
-pcap is the default DAQ. If snort is run w/o any DAQ arguments, it will
-operate as it always did using this module. These are equivalent:
-
- ./snort -i <device>
- ./snort -r <file>
-
- ./snort --daq pcap --daq-mode passive -i <device>
- ./snort --daq pcap --daq-mode read-file -r <file>
-
-You can specify the buffer size pcap uses with:
-
- ./snort --daq pcap --daq-var buffer_size=<#bytes>
-
-Immediate (less-buffered or unbuffered) delivery mode can be enabled with:
-
- ./snort --daq pcap --daq-var immediate=1
-
-This immediate delivery mode can be particularly useful on modern Linux systems
-with TPACKET_V3 support. LibPCAP will attempt to use this mode when it is
-available, but it introduces some potentially undesirable behavior in exchange
-for better performance. The most notable behavior change is that the packet
-timeout will never occur if packets are not being received, causing the poll()
-to potentially hang indefinitely. Enabling immediate delivery mode will cause
-LibPCAP to use TPACKET_V2 instead of TPACKET_V3.
-
-* The pcap DAQ does not count filtered packets. *
-
-
-==== AFPACKET Module
-
-afpacket functions similar to the pcap DAQ but with better performance:
-
- ./snort --daq afpacket -i <device>
- [--daq-var buffer_size_mb=<#MB>]
- [--daq-var debug]
-
-If you want to run afpacket in inline mode, you must craft the device string as
-one or more interface pairs, where each member of a pair is separated by a
-single colon and each pair is separated by a double colon like this:
-
- eth0:eth1
-
-or this:
-
- eth0:eth1::eth2:eth3
-
-By default, the afpacket DAQ allocates 128MB for packet memory. You can change
-this with:
-
- --daq-var buffer_size_mb=<#MB>
-
-Note that the total allocated is actually higher, here's why. Assuming the
-default packet memory with a snaplen of 1518, the numbers break down like this:
-
-* The frame size is 1518 (snaplen) + the size of the AFPacket header (66
- bytes) = 1584 bytes.
-
-* The number of frames is 128 MB / 1518 = 84733.
-
-* The smallest block size that can fit at least one frame is 4 KB = 4096 bytes
- @ 2 frames per block.
-
-* As a result, we need 84733 / 2 = 42366 blocks.
-
-* Actual memory allocated is 42366 * 4 KB = 165.5 MB.
-
-NOTE: Linux kernel version 2.6.31 or higher is required for the AFPacket DAQ
-module due to its dependency on both TPACKET v2 and PACKET_TX_RING support.
-
-===== Fanout (Kernel Loadbalancing)
-
-More recent Linux kernel versions (3.1+) support various kernel-space
-loadbalancing methods within AFPacket configured using the PACKET_FANOUT ioctl.
-This allows you to have multiple AFPacket DAQ module instances processing
-packets from the same interfaces in parallel for significantly improved
-throughput.
-
-To configure PACKET_FANOUT in the AFPacket DAQ module, two DAQ variables are
-used:
-
- --daq-var fanout_type=<hash|lb|cpu|rollover|rnd|qm>
-
-and (optionally):
-
- --daq-var fanout_flag=<rollover|defrag>
-
-In general, you're going to want to use the 'hash' fanout type, but the others
-have been included for completeness. The 'defrag' fanout flag is probably a
-good idea to correctly handle loadbalancing of flows containing fragmented
-packets.
-
-Please read the man page for 'packet' or packet_mmap.txt in the Linux kernel
-source for more details on the different fanout types and modifier flags.
-
-
-==== NFQ Module
-
-NFQ is the new and improved way to process iptables packets:
-
- ./snort --daq nfq \
- [--daq-var device=<dev>] \
- [--daq-var proto=<proto>] \
- [--daq-var queue=<qid>]
-
- <dev> ::= ip | eth0, etc; default is IP injection
- <proto> ::= ip4 | ip6 |; default is ip4
- <qid> ::= 0..65535; default is 0
-
-This module can not run unprivileged so ./snort -u -g will produce a warning
-and won't change user or group.
-
-Notes on iptables are given below.
-
-
-==== IPQ Module
-
-IPQ is the old way to process iptables packets. It replaces the inline version
-available in pre-2.9 versions built with this:
-
- ./configure --enable-inline
-
-Note that layer 2 resets are not supported with the IPQ DAQ:
-
- config layer2resets[: <mac>]
-
-Start the IPQ DAQ as follows:
-
- ./snort --daq ipq \
- [--daq-var device=<dev>] \
- [--daq-var proto=<proto>] \
-
- <dev> ::= ip | eth0, etc; default is IP injection
- <proto> ::= ip4 | ip6; default is ip4
-
-This module can not run unprivileged so ./snort -u -g will produce a warning
-and won't change user or group.
-
-Notes on iptables are given below.
-
-
-==== IPFW Module
-
-IPFW is available for BSD systems. It replaces the inline version available in
-pre-2.9 versions built with this:
-
- ./configure --enable-ipfw
-
-This command line argument is no longer supported:
-
- ./snort -J <port#>
-
-Instead, start Snort like this:
-
- ./snort --daq ipfw [--daq-var port=<port>]
-
- <port> ::= 1..65535; default is 8000
-
-* IPFW only supports ip4 traffic.
-
-Notes on FreeBSD and OpenBSD are given below.
-
-
-==== Dump Module
-
-The dump DAQ allows you to test the various inline mode features available in
-2.9 Snort like injection and normalization.
-
- ./snort -i <device> --daq dump
- ./snort -r <pcap> --daq dump
-
-By default a file named inline-out.pcap will be created containing all packets
-that passed through or were generated by snort. You can optionally specify a
-different name.
-
- ./snort --daq dump --daq-var file=<name>
-
-The dump DAQ also supports text output of verdicts rendered, injected packets,
-and other such items. In order to enable text output, the 'output' DAQ
-variable must be set to either 'text' (text output only) or 'both' (both text
-and PCAP output will be written). The default filename for the text output is
-inline-out.txt, but it can be overridden like so:
-
- ./snort --daq dump --daq-var output=text --daq-var text-file=<filename>
-
-dump uses the pcap daq for packet acquisition. It therefore does not count
-filtered packets (a pcap limitation).
-
-Note that the dump DAQ inline mode is not an actual inline mode. Furthermore,
-you will probably want to have the pcap DAQ acquire in another mode like this:
-
- ./snort -r <pcap> -Q --daq dump --daq-var load-mode=read-file
- ./snort -i <device> -Q --daq dump --daq-var load-mode=passive
-
-
-==== Netmap Module
-
-The netmap project is a framework for very high speed packet I/O. It is
-available on both FreeBSD and Linux with varying amounts of preparatory
-setup required. Specific notes for each follow.
-
- ./snort --daq netmap -i <device>
- [--daq-var debug]
-
-If you want to run netmap in inline mode, you must craft the device string as
-one or more interface pairs, where each member of a pair is separated by a
-single colon and each pair is separated by a double colon like this:
-
- em1:em2
-
-or this:
-
- em1:em2::em3:em4
-
-Inline operation performs Layer 2 forwarding with no MAC filtering, akin to the
-AFPacket module's behavior. All packets received on one interface in an inline
-pair will be forwarded out the other interface unless dropped by the reader and
-vice versa.
-
-IMPORTANT: The interfaces will need to be up and in promiscuous mode in order to
-function ('ifconfig em1 up promisc'). The DAQ module does not currently do
-either of these configuration steps for itself.
-
-===== FreeBSD
-
-In FreeBSD 10.0, netmap has been integrated into the core OS. In order to use
-it, you must recompile your kernel with the line
-
- device netmap
-
-added to your kernel config.
-
-===== Linux
-
-You will need to download the netmap source code from the project's repository:
-
- https://code.google.com/p/netmap/
-
-Follow the instructions on the project's homepage for compiling and installing
-the code:
-
- http://info.iet.unipi.it/~luigi/netmap/
-
-It will involve a standalone kernel module (netmap_lin) as well as patching and
-rebuilding the kernel module used to drive your network adapters. The following
-drivers are supported under Linux at the time of writing (June 2014):
-
- e1000
- e1000e
- forcedeth
- igb
- ixgbe
- r8169
- virtio
-
-TODO:
-- Support for attaching to only a single ring (queue) on a network adapter.
-- Support for VALE and netmap pipes.
-
-
-==== Notes on iptables
-
-These notes are just a quick reminder that you need to set up iptables to use
-the IPQ or NFQ DAQs. Doing so may cause problems with your network so tread
-carefully. The examples below are intentionally incomplete so please read the
-related documentation first.
-
-Here is a blog post by Marty for historical reference:
-
- http://archives.neohapsis.com/archives/snort/2000-11/0394.html
-
-You can check this out for queue sizing tips:
-
- http://www.inliniac.net/blog/2008/01/23/improving-snort_inlines-nfq-performance.html
-
-You might find useful IPQ info here:
-
- http://snort-inline.sourceforge.net/
-
-Use this to examine your iptables:
-
- sudo /sbin/iptables -L
-
-Use something like this to set up NFQ:
-
- sudo /sbin/iptables
- -I <table> [<protocol stuff>] [<state stuff>]
- -j NFQUEUE --queue-num 1
-
-Use something like this to set up IPQ:
-
- sudo iptables -I FORWARD -j QUEUE
-
-Use something like this to "disconnect" snort:
-
- sudo /sbin/iptables -D <table> <rule pos>
-
-Be sure to start Snort prior to routing packets through NFQ with iptables.
-Such packets will be dropped until Snort is started.
-
-The queue-num is the number you must give Snort.
-
-If you are running on a system with both NFQ and IPQ support, you may
-experience some start-up failures of the sort:
-
-The solution seems to be to remove both modules from the kernel like this:
-
- modprobe -r nfnetlink_queue
- modprobe -r ip_queue
-
-and then install the module you want:
-
- modprobe ip_queue
-
-or:
-
- modprobe nfnetlink_queue
-
-These DAQs should be run with a snaplen of 65535 since the kernel defrags the
-packets before queuing. Also, no need to configure frag3.
-
-
-==== Notes on FreeBSD::IPFW
-
-Check the online manual at:
-
- http://www.freebsd.org/doc/handbook/firewalls-ipfw.html.
-
-Here is a brief example to divert icmp packets to Snort at port 8000:
-
-To enable support for divert sockets, place the following lines in the
-kernel configuration file:
-
- options IPFIREWALL
- options IPDIVERT
-
-(The file in this case was: /usr/src/sys/i386/conf/GENERIC; which is platform
-dependent.)
-
-You may need to also set these to use the loadable kernel modules:
-
- /etc/rc.conf:
- firewall_enable="YES"
-
- /boot/loader.conf:
- ipfw_load="YES"
- ipdivert_load="YES"
-
- $ dmesg | grep ipfw
- ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based
- forwarding disabled, default to deny, logging disabled
-
- $ kldload -v ipdivert
- Loaded ipdivert, id=4
-
- $ ipfw add 75 divert 8000 icmp from any to any
- 00075 divert 8000 icmp from any to any
-
- $ ipfw list
- ...
- 00075 divert 8000 icmp from any to any
- 00080 allow icmp from any to any
- ...
-
-* Note that on FreeBSD, divert sockets don't work with bridges!
-
-Please refer to the following articles for more information:
-
-https://forums.snort.org/forums/support/topics/snort-inline-on-freebsd-ipfw
-http://freebsd.rogness.net/snort_inline/
-
-NAT gateway can be used with divert sockets if the network environment is
-conducive to using NAT.
-
-The steps to set up NAT with ipfw are as follows:
-
-1. Set up NAT with two interface em0 and em1 by adding the following to
-/etc/rc.conf. Here em0 is connected to external network and em1 to host-only
-LAN.
-
-
- gateway_enable="YES"
- natd_program="/sbin/natd" # path to natd
- natd_enable="YES" # Enable natd (if firewall_enable == YES)
- natd_interface="em0" # Public interface or IP Address
- natd_flags="-dynamic" # Additional flags
- defaultrouter=""
- ifconfig_em0="DHCP"
- ifconfig_em1="inet 192.168.1.2 netmask 255.255.255.0"
- firewall_enable="YES"
- firewall_script="/etc/rc.firewall"
- firewall_type="simple"
-
-2. Add the following divert rules to divert packets to Snort above and
-below the NAT rule in the "Simple" section of /etc/rc.firewall.
-
- ...
- # Inspect outbound packets (those arriving on "inside" interface)
- # before NAT translation.
- ${fwcmd} add divert 8000 all from any to any in via ${iif}
- case ${natd_enable} in
- [Yy][Ee][Ss])
- if [ -n "${natd_interface}" ]; then
- ${fwcmd} add divert natd all from any to any via
-${natd_interface}
- fi
- ;;
- esac
- ...
- # Inspect inbound packets (those arriving on "outside" interface)
- # after NAT translation that aren't blocked for other reasons,
- # after the TCP "established" rule.
- ${fwcmd} add divert 8000 all from any to any in via ${oif}
-
-
-==== Notes on OpenBSD::IPFW
-
-OpenBSD supports divert sockets as of 4.7, so we use the ipfw DAQ.
-
-Here is one way to set things up:
-
-1. Configure the system to forward packets:
-
- $ sysctl net.inet.ip.forwarding=1
- $ sysctl net.inet6.ip6.forwarding=1
-
- (You can also put that in /etc/sysctl.conf to enable on boot.)
-
-2. Set up interfaces
-
- $ dhclient vic1
- $ dhclient vic2
-
-3. Set up packet filter rules:
-
- $ echo "pass out on vic1 divert-packet port 9000 keep-state" > rules.txt
- $ echo "pass out on vic2 divert-packet port 9000 keep-state" >> rules.txt
-
- $ pfctl -v -f rules.txt
-
-4. Analyze packets diverted to port 9000:
-
- $ ./snort --daq ipfw --daq-var port=9000
-
-* Note that on OpenBSD, divert sockets don't work with bridges!
-
include::plugins.txt[]
-=== LibDAQ and DAQ Modules
-
-include::daq_readme.txt[]
-
=== Limitations
include::reload_limitations.txt[]
Required:
-* autotools or cmake to build from source
+* cmake to build from source
-* daq from http://www.snort.org for packet IO
+* daq from https://github.com/snort3/libdaq for packet IO
* g\++ >= 4.8 or other recent C++11 compiler
export my_path=/path/to/snorty
mkdir -p $my_path
-* If you are using a github clone with autotools, do this:
+* If LibDAQ was installed to a custom, non-system path:
- autoreconf -isvf
+ export PKG_CONFIG_PATH=/libdaq/install/path/lib/pkgconfig:$PKG_CONFIG_PATH
* Now do one of the following:
./configure_cmake.sh --prefix=$my_path
cd build
- make -j 8
+ make -j
make install
ln -s $my_path/conf $my_path/etc
projects / thirdparty / snort3.git / commitdiff
