Thanks to Josh Soref.
config option to ``ignore``.
**In IDS mode**, setting ``auto`` mode actually means disabling the
-``master-swtich``, or ignoring the exception policies.
+``master-switch``, or ignoring the exception policies.
Specific settings
~~~~~~~~~~~~~~~~~
-----------------------------------------
Some users might have a need or a wish to split their suricata.yaml
-file in to separate files, this is available via the 'include' and
+file into separate files, this is available via the 'include' and
'!include' keyword. The first example is of taking the contents of the
outputs section and storing them in outputs.yaml.
.. option:: --include <path>
- Additional configuration files to include. Multiple additonal
+ Additional configuration files to include. Multiple additional
configuration files can be provided and will be included in the
- order specified on the command line. These additonal configuration
+ order specified on the command line. These additional configuration
files are loaded as if they existed at the end of the main
configuration file.
The purpose of the IP reputation component is the ranking of IP Addresses within the Suricata Engine. It will collect, store, update and distribute reputation intelligence on IP Addresses. The hub and spoke architecture will allows the central database (The Hub) to collect, store and compile updated IP reputation details that are then distributed to user-side sensor databases (Spokes) for inclusion in user security systems. The reputation data update frequency and security action taken, is defined in the user security configuration.
-The intent of IP Reputation is to allow sharing of intelligence regarding a vast number of IP addresses. This can be positive or negative intelligence classified into a number of categories. The technical implementation requires three major efforts; engine integration, the hub that redistributes reputation, and the communication protocol between hubs and sensors. The hub will have a number of responsibilities. This will be a separate module running on a separate system as any sensor. Most often it would run on a central database that all sensors already have communication with. It will be able to subscribe to one or more external feeds. The local admin should be able to define the feeds to be subscribed to, provide authentication credentials if required, and give a weight to that feed. The weight can be an overall number or a by category weight. This will allow the admin to minimize the influence a feed has on their overall reputation if they distrust a particular category or feed, or trust another implicitly. Feeds can be configured to accept feedback or not and will report so on connect. The admin can override and choose not to give any feedback, but the sensor should report these to the Hub upstream on connect. The hub will take all of these feeds and aggregate them into an average single score for each IP or IP Block, and then redistribute this data to all local sensors as configured. It should receive connections from sensors. The sensor will have to provide authentication and will provide feedback. The hub should redistribute that feedback from sensors to all other sensors as well as up to any feeds that accept feedback. The hub should also have an API to allow outside statistical analysis to be done to the database and fed back in to the stream. For instance a local site may choose to change the reputation on all Russian IP blocks, etc.
+The intent of IP Reputation is to allow sharing of intelligence regarding a vast number of IP addresses. This can be positive or negative intelligence classified into a number of categories. The technical implementation requires three major efforts; engine integration, the hub that redistributes reputation, and the communication protocol between hubs and sensors. The hub will have a number of responsibilities. This will be a separate module running on a separate system as any sensor. Most often it would run on a central database that all sensors already have communication with. It will be able to subscribe to one or more external feeds. The local admin should be able to define the feeds to be subscribed to, provide authentication credentials if required, and give a weight to that feed. The weight can be an overall number or a by category weight. This will allow the admin to minimize the influence a feed has on their overall reputation if they distrust a particular category or feed, or trust another implicitly. Feeds can be configured to accept feedback or not and will report so on connect. The admin can override and choose not to give any feedback, but the sensor should report these to the Hub upstream on connect. The hub will take all of these feeds and aggregate them into an average single score for each IP or IP Block, and then redistribute this data to all local sensors as configured. It should receive connections from sensors. The sensor will have to provide authentication and will provide feedback. The hub should redistribute that feedback from sensors to all other sensors as well as up to any feeds that accept feedback. The hub should also have an API to allow outside statistical analysis to be done to the database and fed back into the stream. For instance a local site may choose to change the reputation on all Russian IP blocks, etc.
For more information about IP Reputation see :doc:`ip-reputation-config`, :doc:`/rules/ip-reputation-rules` and :doc:`ip-reputation-format`.
- 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
+ matching. Hyperscan will also take into account depth and offset
when doing fast pattern matching, something the other algorithms and
Snort do not do.
.. note::
Please note that the source and destination address can also be matched via the ``ip.src`` and ``ip.dst`` keywords (See :ref:`ipaddr`). These
- keywords are mostly used in conjuction with the dataset feature (:ref:`datasets`).
+ keywords are mostly used in conjunction with the dataset feature (:ref:`datasets`).
Ports (source and destination)
------------------------------
Logging changes
~~~~~~~~~~~~~~~
-- Protocol values and their names are built-in to Suricata instead of using the system's ``/etc/protocols`` file. Some names and casing may have changed
+- Protocol values and their names are built into Suricata instead of using the system's ``/etc/protocols`` file. Some names and casing may have changed
in the values ``proto`` in ``eve.json`` log entries and other logs containing protocol names and values.
See https://redmine.openinfosecfoundation.org/issues/4267 for more information.
projects / thirdparty / suricata.git / commitdiff
