From: Jeff Lucovsky Date: Wed, 17 Jun 2020 14:15:41 +0000 (-0400) Subject: doc: Correct typos X-Git-Tag: suricata-6.0.0-beta1~285 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b116a56a324a0608c291d3120ab1eb32325bff53;p=thirdparty%2Fsuricata.git doc: Correct typos --- diff --git a/doc/userguide/capture-hardware/ebpf-xdp.rst b/doc/userguide/capture-hardware/ebpf-xdp.rst index 5654868472..97354df6c2 100644 --- a/doc/userguide/capture-hardware/ebpf-xdp.rst +++ b/doc/userguide/capture-hardware/ebpf-xdp.rst @@ -229,7 +229,7 @@ With any logic implemented in the eBPF filter. The value returned by the functio 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 :: diff --git a/doc/userguide/capture-hardware/napatech.rst b/doc/userguide/capture-hardware/napatech.rst index bdfd98228f..1c01ca300e 100644 --- a/doc/userguide/capture-hardware/napatech.rst +++ b/doc/userguide/capture-hardware/napatech.rst @@ -198,7 +198,7 @@ Example Configuration - Manual Configuration 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. @@ -268,15 +268,15 @@ upstream and downstream traffic E.g.:: 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] @@ -326,7 +326,7 @@ pass traffic matching a given signature. For example, given the rule:: 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. @@ -358,7 +358,7 @@ On flow-aware products the following counters are also available: - 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. @@ -371,7 +371,7 @@ On flow-aware products the following counters are also available: - 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: diff --git a/doc/userguide/capture-hardware/netmap.rst b/doc/userguide/capture-hardware/netmap.rst index 3f0b24bf04..9ee25f58d4 100644 --- a/doc/userguide/capture-hardware/netmap.rst +++ b/doc/userguide/capture-hardware/netmap.rst @@ -207,7 +207,7 @@ Inline IDS ---------- The inline IDS is almost the same as the IPS setup above, but it will not -enfore ``drop`` policies. +enforce ``drop`` policies. :: diff --git a/doc/userguide/configuration/suricata-yaml.rst b/doc/userguide/configuration/suricata-yaml.rst index b7e866412e..e3d9841e77 100644 --- a/doc/userguide/configuration/suricata-yaml.rst +++ b/doc/userguide/configuration/suricata-yaml.rst @@ -2171,7 +2171,7 @@ Finally, if ``encrypt-handling`` is set to ``full``, Suricata will process the 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``. diff --git a/doc/userguide/file-extraction/file-extraction.rst b/doc/userguide/file-extraction/file-extraction.rst index 6c4a18b5bb..e6b8ac9b3b 100644 --- a/doc/userguide/file-extraction/file-extraction.rst +++ b/doc/userguide/file-extraction/file-extraction.rst @@ -98,7 +98,7 @@ stored file to be closed and ```` is a unique ID for the runtime 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 diff --git a/doc/userguide/lua/lua-functions.rst b/doc/userguide/lua/lua-functions.rst index 98ee284ba5..9b5fb48d44 100644 --- a/doc/userguide/lua/lua-functions.rst +++ b/doc/userguide/lua/lua-functions.rst @@ -175,7 +175,7 @@ HttpGetRequestBody and HttpGetResponseBody. 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: @@ -798,7 +798,7 @@ init function: 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. :: diff --git a/doc/userguide/lua/lua-usage.rst b/doc/userguide/lua/lua-usage.rst index 8d83f3b9cf..32b562ca62 100644 --- a/doc/userguide/lua/lua-usage.rst +++ b/doc/userguide/lua/lua-usage.rst @@ -2,7 +2,7 @@ Lua usage in Suricata ===================== 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. diff --git a/doc/userguide/performance/analysis.rst b/doc/userguide/performance/analysis.rst index 433f1a7b94..28886f271f 100644 --- a/doc/userguide/performance/analysis.rst +++ b/doc/userguide/performance/analysis.rst @@ -111,7 +111,7 @@ There are several advanced steps and corner cases when it comes to a deep dive 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 diff --git a/doc/userguide/rules/differences-from-snort.rst b/doc/userguide/rules/differences-from-snort.rst index d26fe7a5e1..1457f2c2ff 100644 --- a/doc/userguide/rules/differences-from-snort.rst +++ b/doc/userguide/rules/differences-from-snort.rst @@ -550,7 +550,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 - 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` diff --git a/doc/userguide/upgrade.rst b/doc/userguide/upgrade.rst index 3a91c169b1..7af08fceb7 100644 --- a/doc/userguide/upgrade.rst +++ b/doc/userguide/upgrade.rst @@ -21,7 +21,7 @@ this means passing the same ``--prefix``, ``--sysconfdir``, 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