# Use explicitely 3 threads and don't compute number by using
# Use explicitly 3 threads and don't compute number by using
# detect-thread-ratio variable:
# threads: 3
prio:
@ -1182,7 +1182,7 @@ Suricata inspects traffic in a sliding window manner.
..image:: suricata-yaml/inline_mode.png
**Example 13 Normal/IDS (reasembly on ACK'D data)**
**Example 13 Normal/IDS (reassembly on ACK'D data)**
..image:: suricata-yaml/Normal_ids_ack_d.png
@ -1488,7 +1488,7 @@ use of libhtp.
# detection change between runs. It is set to 'yes' by default.
#randomize-inspection-sizes: yes
# If randomize-inspection-sizes is active, the value of various
# inspection size will be choosen in the [1 - range%, 1 + range%]
# inspection size will be chosen in the [1 - range%, 1 + range%]
# range
# Default value of randomize-inspection-range is 10.
#randomize-inspection-range: 10
@ -1980,7 +1980,7 @@ be found in other capture interfaces. The individual items contain the usual con
such as `threads`/`copy-mode`/`checksum-checks` settings. Other capture interfaces, such as AF_PACKET, rely on the user that NICs are appropriately configured.
Configuration through kernel does not apply to applications running under DPDK. The application is solely responsible for the
initialization of NICs it is using. So, before the start of Suricata, NICs that Suricata uses, must undergo the process of initialization.
As a result, there are extra extra configuration options (how NICs can be configured) in the items (interfaces) of the `dpdk.interfaces` list.
As a result, there are extra configuration options (how NICs can be configured) in the items (interfaces) of the `dpdk.interfaces` list.
At the start of the configuration process, all NIC offloads are disabled to prevent any packet modification.
According to the configuration, checksum validation offload can be enabled to drop invalid packets.
@ -114,7 +114,7 @@ is completed (NFS, SMB), it is possible to create a level of abstraction to hand
This is controlled by implementing progress states. In Suricata, those will be enums that are incremented as the parsing
progresses. A state will start at 0. The higher its value, the closer the transaction would be to completion. Due to how
the engine tracks detection accross states, there is an upper limit of 48 to the state progress (it must be < 48).
the engine tracks detection across states, there is an upper limit of 48 to the state progress (it must be < 48).
The engine interacts with transactions' state using a set of callbacks the parser registers. State is defined per flow direction (``STREAM_TOSERVER`` / ``STREAM_TOCLIENT``).
@ -1442,7 +1442,7 @@ The optional "client" field is a sub-object that may contain the following:
* "capabilities": List of any of the following: "support_errinfo_pdf", "want_32bpp_session", "support_statusinfo_pdu", "strong_asymmetric_keys", "valid_connection_type", "support_monitor_layout_pdu", "support_netchar_autodetect", "support_dynvc_gfx_protocol", "support_dynamic_time_zone", "support_heartbeat_pdu".
* "id": Client product id string.
* "connection_hint": Possible values are "modem", "low_broadband", "satellite", "high_broadband", "wan", "lan", "autodetect".
* "physical_width": Numeric phyical width of display.
* "physical_width": Numeric physical width of display.
* "physical_height": Numeric physical height of display.
* "desktop_orientation": Numeric angle of orientation.
* "scale_factor": Numeric scale factor of desktop.
@ -2163,7 +2163,7 @@ Some of the possible request messages are:
Examples
~~~~~~~~
The two ``pgsql`` events in this example reprensent a rejected ``SSL handshake`` and a following connection request where the authentication method indicated by the backend was ``md5``::
The two ``pgsql`` events in this example represent a rejected ``SSL handshake`` and a following connection request where the authentication method indicated by the backend was ``md5``::
Suricata can alert via sylog which is a very handy feature for central log collection, compliance, and reporting to a SIEM. Instructions on setting this up can be found in the .yaml file in the section where you can configure what type of alert (and other) logging you would like.
Suricata can alert via syslog which is a very handy feature for central log collection, compliance, and reporting to a SIEM. Instructions on setting this up can be found in the .yaml file in the section where you can configure what type of alert (and other) logging you would like.
However, there are different syslog daemons and there can be parsing issues with the syslog format a SIEM expects and what syslog format Suricata sends. The syslog format from Suricata is dependent on the syslog daemon running on the Suricata sensor but often the format it sends is not the format the SIEM expects and cannot parse it properly.
Some people made nice tools to plot graphs of the statistics file.
* `ipython and matplotlib script <https://github.com/regit/suri-stats>`_
* `Monitoring with Zabbix or other <http://christophe.vandeplas.com/2013/11/suricata-monitoring-with-zabbix-or-other.html>`_ and `Code on Github <https://github.com/cvandeplas/suricata_stats>`_
* `Monitoring with Zabbix or other <http://christophe.vandeplas.com/2013/11/suricata-monitoring-with-zabbix-or-other.html>`_ and `Code on GitHub <https://github.com/cvandeplas/suricata_stats>`_
Victor Julien
3 years ago