Merge pull request #174 from Security-Onion-Solutions/dev

2.4.200

Author: TOoSmOotH

airgap.rst

@@ -25,8 +25,10 @@ Airgap mode works as follows:
 Rule Updates
 ------------
 
-Our ISO image includes the Emerging Threats (ET) ruleset. When :ref:`soup` updates an airgap system via ISO, it automatically installs the latest ET rules as well. If you would like to switch to a different ruleset like Emerging Threats Pro (ETPRO), then you can manually copy the ETPRO rules to ``/nsm/rules/suricata/emerging-all.rules`` using a command like:
+Our ISO image includes the latest version of various rulesets and will automatically install them when an airgap system is SOUP'ed via ISO:
 
-::
+- :ref:`nids`: Emerging Threats (ETOPEN). If you would like to switch to a different ruleset like Emerging Threats Pro (ETPRO), refer to our Ruleset config documentation :ref:`nids`
 
-  cat /path/to/ETPRO_rules/*.rules > /nsm/rules/suricata/emerging-all.rules
+- :ref:`yara`: Most recent rules from our repo
+
+- :ref:`sigma`: Most recent rule packages from the SigmaHQ repo

architecture.rst

@@ -45,10 +45,10 @@ For more information, please see the :ref:`desktop` section.
 Distributed
 -----------
 
-A standard distributed deployment includes a **manager node**, one or more **forward nodes** running network sensor components, and one or more **search nodes** running Elastic search components. This architecture may cost more upfront, but it provides for greater scalability and performance, as you can simply add more nodes to handle more traffic or log sources.
+A standard distributed deployment includes a **manager node**, one or more **sensor nodes** running network sensor components, and one or more **search nodes** running Elastic search components. This architecture may cost more upfront, but it provides for greater scalability and performance, as you can simply add more nodes to handle more traffic or log sources.
 
 -  Recommended deployment type
--  Consists of a manager node, one or more forward nodes, and one or more search nodes
+-  Consists of a manager node, one or more sensor nodes, and one or more search nodes
 
 .. note::
 
@@ -102,12 +102,12 @@ A manager search node runs the following components:
 -  :ref:`elastalert`
 -  :ref:`redis`
 
-Forward Node
+Sensor Node
 ~~~~~~~~~~~~
 
-A ``forward node`` forwards alerts and logs from :ref:`suricata` and :ref:`zeek` via :ref:`elastic-agent` to :ref:`logstash` on the manager node, where they are stored in :ref:`elasticsearch` on the manager node or a search node (if the manager node has been configured to use a search node). Full packet capture recorded by :ref:`stenographer` or :ref:`suricata` remains on the forward node itself.
+A ``sensor node`` forwards alerts and logs from :ref:`suricata` and :ref:`zeek` via :ref:`elastic-agent` to :ref:`logstash` on the manager node, where they are stored in :ref:`elasticsearch` on the manager node or a search node (if the manager node has been configured to use a search node). Full packet capture recorded by :ref:`stenographer` or :ref:`suricata` remains on the sensor node itself.
 
-Forward nodes run the following components:
+Sensor nodes run the following components:
 
 -  :ref:`zeek`
 -  :ref:`suricata`

build.sh

@@ -1,7 +1,8 @@
 BUILDDIR=/tmp/securityonion-docs/autobuild
+rm -rf $BUILDDIR
 python -m venv .venv
 source .venv/bin/activate
 python -m pip install pip
 pip install -r requirements.txt
 pip install sphinx-autobuild
-sphinx-autobuild --port 4444 -b html -d $BUILDDIR/doctrees -T -j auto -W . $BUILDDIR/html
+sphinx-autobuild --port 4444 -b html -d $BUILDDIR/doctrees -T -j auto -W --pre-build "rm -rf $BUILDDIR/html/_static" --watch . . $BUILDDIR/html

cloud-amazon.rst

@@ -190,7 +190,7 @@ If connecting sensors through the VPN instance you will need to add the inside i
     Location: Remote    Location: Remote                Location: AWS    Location: AWS
     192.168.33.13       192.168.33.10                   10.55.1.10       10.55.1.20
 
-In order to add the Remote Network Forward Node to the Grid, you would have to add ``10.55.1.10`` to the ``sensor`` firewall hostgroup.
+In order to add the Remote Network Sensor Node to the Grid, you would have to add ``10.55.1.10`` to the ``sensor`` firewall hostgroup.
 
 This change can be done in the SOC Configuration screen. Then, either wait up to 15 minutes for the scheduled configuration sync to run, or force a synchronization immediately via the SOC Configuration Options. Once the firewall hostgroup configuration has been synchronized your Manager will be ready for remote minions to start connecting.
 

cloud-google.rst

@@ -225,7 +225,7 @@ If connecting sensors through the VPN instance you will need to add the inside i
     Location: Remote    Location: Remote                Location: Googe  Location: Google
     192.168.33.13       192.168.33.10                   10.55.1.10       10.55.1.20
 
-In order to add the Remote Network Forward Node to the Grid, you would have to add ``10.55.1.10`` to the ``sensor`` firewall hostgroup.
+In order to add the Remote Network Sensor Node to the Grid, you would have to add ``10.55.1.10`` to the ``sensor`` firewall hostgroup.
 
 This change can be done in the SOC Configuration screen. Then, either wait up to 15 minutes for the scheduled configuration sync to run, or force a synchronization immediately via the SOC Configuration Options. Once the firewall hostgroup configuration has been synchronized your Manager will be ready for remote minions to start connecting.
 

configuration.rst

@@ -36,7 +36,7 @@ Standalone is similar to Evaluation in that it only requires a single box, but S
 Production Server - Distributed Deployment
 ------------------------------------------
 
-If deploying a distributed environment, install and configure the manager node first and then join the other nodes to it. For best performance, the manager node should be dedicated to just being a manager for the other nodes (the manager node should not do any network sniffing, that should be handled by dedicated forward nodes). 
+If deploying a distributed environment, install and configure the manager node first and then join the other nodes to it. For best performance, the manager node should be dedicated to just being a manager for the other nodes (the manager node should not do any network sniffing, that should be handled by dedicated sensor nodes).
 
 Build the manager by running Setup, selecting the ``DISTRIBUTED`` deployment option, and choosing the ``New Deployment`` option. You can choose either ``MANAGER`` or ``MANAGERSEARCH``. If you choose ``MANAGER``, then you must join one or more search nodes (this is optional if you choose ``MANAGERSEARCH``) and you will want to do this before you start joining other node types.
 

detections.rst

@@ -30,7 +30,8 @@ Here is the list of possible status messages and what they mean:
 - **Migration Failed**: A failure occurred during the migration. The migration will stop on the first error and will not attempt to migrate to newer versions until the issue is resolved.
 - **Synchronizing**: A rule synchronization is in progress. This occurs daily, to ensure the Security Onion grid has the latest rules. 
 - **Sync Failed**: A failure occurred during the synchronization procedure. The next sync will retry within a few minutes.
-- **Rule Mismatch**: An integrity check process detected a mismatch between the deployed rules and the enabled rules. The SOC log will note the specific mismatched rules. One possible reason for this is if you had previously added custom rules to /opt/so/saltstack/local/salt/idstools/rules/local.rules and, if this is the case, then you can remove the rules from that file and re-add them using the Detections interface. Another possible reason is that :ref:`elasticsearch` has reached its disk watermark setting and is no longer allowing updates to the Detections indices.
+- **Sync Blocked**: Rule synchronization is currently blocked.
+- **Rule Mismatch**: An integrity check process detected a mismatch between the deployed rules and the enabled rules. The SOC log will note the specific mismatched rules. One possible reason is that :ref:`elasticsearch` has reached its disk watermark setting and is no longer allowing updates to the Detections indices.
 - **OK**: No known issues with the rule engine.
 
 .. tip::
@@ -147,8 +148,8 @@ Elastalert/Sigma
   - Immediate change in the UI and on disk
 
 Suricata/NIDS
-  - UI Bulk and Individual: Immediate change in the UI, disk change once the `idstools` state runs again
-  - Regex: UI and disk change once the `soc` state runs again and the :ref:`suricata` engine syncs
+  - UI Bulk and Individual: Immediate change in the UI and on disk
+  - Regex: UI and disk change once the :ref:`suricata` engine syncs
 
 Strelka/YARA
   - Immediate change in the UI, disk change once the `strelka` state runs again
@@ -160,7 +161,7 @@ Elastalert/Sigma
   - Immediate change in the UI and on disk
 
 Suricata/NIDS
-  - Immediate change in the UI, disk change once the `idstools` state runs again
+  - Immediate change in the UI and on disk
 
 Strelka/YARA
   - N/A
@@ -173,9 +174,7 @@ Elastalert/Sigma
   - Git repo (https or disk): UI and disk change once the `soc` state runs again and the :ref:`elastalert` engine syncs
 
 Suricata/NIDS
-  - ETOPEN/ETPRO: UI and disk change once the `soc` and  `idstools` states run again and the :ref:`suricata` engine syncs
-  - Custom URL: UI and disk change once the `soc` and `idstools` states run again and the :ref:`suricata` engine syncs
-  - Custom Local File: UI and disk change once the `soc` and `idstools` states run again and the :ref:`suricata` engine syncs
+  - All ruleset sources (ETOPEN, ETPRO, custom URL, local directory): UI and disk change once the :ref:`suricata` engine syncs
 
 Strelka/YARA
   - Git repo (https or disk): UI and disk change once the `soc` state runs again and the :ref:`strelka` engine syncs

elastic-agent.rst

@@ -11,7 +11,7 @@ Each Security Onion node uses the Elastic Agent to transport logs to :ref:`elast
 
 .. note::
 
-   In order to receive logs from the Elastic Agent, Security Onion must be running :ref:`logstash`. Evaluation Mode and Import Mode do not run :ref:`logstash`, so you'll need Standalone or a full Distributed Deployment. In a Distributed Deployment, forward nodes do not run :ref:`logstash`, so you'll need to configure agents to send to your manager or receiver nodes. For more information, please see the :ref:`architecture` section.
+   In order to receive logs from the Elastic Agent, Security Onion must be running :ref:`logstash`. Evaluation Mode and Import Mode do not run :ref:`logstash`, so you'll need Standalone or a full Distributed Deployment. In a Distributed Deployment, sensor nodes do not run :ref:`logstash`, so you'll need to configure agents to send to your manager or receiver nodes. For more information, please see the :ref:`architecture` section.
 
 To deploy an Elastic agent to an endpoint, go to the :ref:`soc` :ref:`downloads` page and download the proper Elastic agent for the operating system of that endpoint.