tagged with the ``loadbalancer`` section is used with a modulo on the CPU count to know in
which socket the packet has to be send.
-An implementation of a simple symetric IP pair hashing function is provided in the ``lb.bpf``
+An implementation of a simple symmetric IP pair hashing function is provided in the ``lb.bpf``
file.
Copy the resulting eBPF filter as needed ::
For Manual Configuration the Napatech streams are created by running NTPL
commands prior to running Suricata.
-Note that this option is provided primarily for legacy configuations as previously
+Note that this option is provided primarily for legacy configurations as previously
this was the only way to configure Napatech products. Newer capabilities such as
flow-awareness and inline processing cannot be configured manually.
Note that these "port-pairings" are also required for IDS configurations as the hardware
needs to know on which port(s) two sides of the connection will arrive.
-For configuations relying on optical taps the two sides of the pairing will typically
+For configurations relying on optical taps the two sides of the pairing will typically
be different ports. For SPAN port configurations where both upstream and downstream traffic
are delivered to a single port both sides of the "port-pair" will reference the same port.
-For example tap configuations have a form similar to this::
+For example tap configurations have a form similar to this::
ports[0-1,2-3]
-Whereas SPAN port configuations it would look similar to this::
+Whereas SPAN port configurations it would look similar to this::
ports[0-0,1-1,2-2,3-3]
pass tcp any 443 <> any any (msg: "SURICATA Test rule"; bypass; sid:1000001; rev:2;)
-Suricata will evaluate the inital packet(s) of the flow and program the flow
+Suricata will evaluate the initial packet(s) of the flow and program the flow
into the hardware. Subsequent packets from the flow will be automatically be
shunted from one port to it's peer.
- napa_dispatch_drop.pkts, napa_dispatch_drop.byte:
The total number of packets/bytes that were dropped at the hardware as
- a result of a Suricata "drop" bypass rule or other ajudication by
+ a result of a Suricata "drop" bypass rule or other adjudication by
Suricata that the flow packets should be dropped. These packets are not
delivered to the application.
- napa_bypass.active_flows:
- The number of flows actively programmed on the hardware to be forwared or dropped.
+ The number of flows actively programmed on the hardware to be forwarded or dropped.
- napa_bypass.total_flows:
----------
The inline IDS is almost the same as the IPS setup above, but it will not
-enfore ``drop`` policies.
+enforce ``drop`` policies.
::
flow as normal, without inspection limitations or bypass.
The option has replaced the ``no-reassemble`` option. If ``no-reassemble`` is
-present, and ``encrypt-handling`` is not, ``false`` is intepreted as
+present, and ``encrypt-handling`` is not, ``false`` is interpreted as
``encrypt-handling: default`` and ``true`` is interpreted as
``encrypt-handling: bypass``.
of the Suricata instance. These values should not be depended on, and
are simply used to ensure uniqueness.
-These ``fileinfo`` records are idential to the ``fileinfo`` records
+These ``fileinfo`` records are identical to the ``fileinfo`` records
logged to the ``eve`` output.
See :ref:`suricata-yaml-file-store` for more information on
Make normalized body data available to the script through
HttpGetRequestBody and HttpGetResponseBody.
-There no guarantees that all of the body will be availble.
+There no guarantees that all of the body will be available.
Example:
end
Here we define a `tls-cnt` Flowint that can now be used in output or in a
-signature via dedicted functions. The access to the Flow variable is done by
+signature via dedicated functions. The access to the Flow variable is done by
index so in our case we need to use 0.
::
=====================
Lua scripting can be used in two components of Suricata. The first is in
-output an the second one in rules in the detection engine.
+output and the second one in rules in the detection engine.
Both features are using a list of functions to access to data extracted by
Suricata. You can get the list of functions in the :ref:`lua-functions` page.
into the traffic.
If VLAN QinQ (IEEE 802.1ad) is used be very cautious if you use **cluster_qm**
-in combinatin with Intel drivers and AF_PACKET runmode. While the RFC expects
+in combination with Intel drivers and AF_PACKET runmode. While the RFC expects
ethertype 0x8100 and 0x88A8 in this case (see
https://en.wikipedia.org/wiki/IEEE_802.1ad) most implementations only add
0x8100 on each layer. If the first seen layer has the same VLAN tag but the
- Using Hyperscan as the MPM matcher (``mpm-algo`` setting) for Suricata
can greatly improve performance, especially when it comes to fast pattern
matching. Hyperscan will also take in to account depth and offset
- when doing fast pattern matching, something the other algorithims and
+ when doing fast pattern matching, something the other algorithms and
Snort do not do.
- :ref:`rules-keyword-fast_pattern`
Configuration Updates
~~~~~~~~~~~~~~~~~~~~~
-New versions of Suricata will occationally include updated config files:
+New versions of Suricata will occasionally include updated config files:
``classification.config`` and ``reference.config``. Since the Suricata
installation will not overwrite these if they exist, they should be manually
updated. If there are no local modifications they can simply be overwritten
projects / thirdparty / suricata.git / commitdiff
