From 0903536fd66a98087bff3b9a1f235d7295710298 Mon Sep 17 00:00:00 2001 From: Victor Julien Date: Mon, 8 May 2023 11:36:21 +0200 Subject: [PATCH] doc: spelling Thanks to Josh Soref. --- doc/userguide/configuration/exception-policies.rst | 2 +- doc/userguide/configuration/suricata-yaml.rst | 2 +- doc/userguide/partials/options.rst | 4 ++-- doc/userguide/reputation/ipreputation/ip-reputation.rst | 2 +- doc/userguide/rules/differences-from-snort.rst | 2 +- doc/userguide/rules/intro.rst | 2 +- doc/userguide/upgrade.rst | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/userguide/configuration/exception-policies.rst b/doc/userguide/configuration/exception-policies.rst index 21c50eaed1..ccc541c1e9 100644 --- a/doc/userguide/configuration/exception-policies.rst +++ b/doc/userguide/configuration/exception-policies.rst @@ -51,7 +51,7 @@ to disable this default, by setting the exception policies' "master switch" yaml 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 ~~~~~~~~~~~~~~~~~ diff --git a/doc/userguide/configuration/suricata-yaml.rst b/doc/userguide/configuration/suricata-yaml.rst index c91ddbe3ca..db4600babe 100644 --- a/doc/userguide/configuration/suricata-yaml.rst +++ b/doc/userguide/configuration/suricata-yaml.rst @@ -217,7 +217,7 @@ Splitting configuration in multiple files ----------------------------------------- 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. diff --git a/doc/userguide/partials/options.rst b/doc/userguide/partials/options.rst index 85a77b74c3..34f8f6a1bb 100644 --- a/doc/userguide/partials/options.rst +++ b/doc/userguide/partials/options.rst @@ -14,9 +14,9 @@ .. option:: --include - 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. diff --git a/doc/userguide/reputation/ipreputation/ip-reputation.rst b/doc/userguide/reputation/ipreputation/ip-reputation.rst index 6798fd1711..dea79811c5 100644 --- a/doc/userguide/reputation/ipreputation/ip-reputation.rst +++ b/doc/userguide/reputation/ipreputation/ip-reputation.rst @@ -8,7 +8,7 @@ IP Reputation 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`. diff --git a/doc/userguide/rules/differences-from-snort.rst b/doc/userguide/rules/differences-from-snort.rst index 9638a25d08..db56912568 100644 --- a/doc/userguide/rules/differences-from-snort.rst +++ b/doc/userguide/rules/differences-from-snort.rst @@ -565,7 +565,7 @@ Fast Pattern - 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. diff --git a/doc/userguide/rules/intro.rst b/doc/userguide/rules/intro.rst index 557db8817a..ab35f8a311 100644 --- a/doc/userguide/rules/intro.rst +++ b/doc/userguide/rules/intro.rst @@ -171,7 +171,7 @@ $HOME_NET Your setting of HOME_NET in yaml .. 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) ------------------------------ diff --git a/doc/userguide/upgrade.rst b/doc/userguide/upgrade.rst index 0732bd09c4..f1e8b7233d 100644 --- a/doc/userguide/upgrade.rst +++ b/doc/userguide/upgrade.rst @@ -68,7 +68,7 @@ Other changes 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. -- 2.47.2