Revert "resolve merge conflicts"

This reverts commit 4600ce6, reversing changes made to 898aafc.
Security-Onion-Solutions · May 29, 2024 · 4160e6d · 4160e6d
1 parent eae01a3
commit 4160e6d
Show file tree

Hide file tree

Showing 30 changed files with 113 additions and 629 deletions.
diff --git a/airgap.rst b/airgap.rst
@@ -14,11 +14,11 @@ Airgap mode works as follows:
 
 - During the install, all of the necessary RPM packages are copied from the ISO image to a new repo located in ``/nsm/repo/``. All devices in the grid will now use this repo for updates to packages.
 
-- :ref:`suricata` NIDS rules from Emerging Threats (ET) are copied to ``/nsm/rules/suricata``.
+- :ref:`nids` rules for :ref:`suricata` are copied to ``/nsm/rules/suricata``.
 
-- Yara rules for :ref:`strelka` are copied to ``/nsm/rules/yara``.
+- :ref:`yara` rules for :ref:`strelka` are copied to ``/nsm/rules/yara``.
 
-- Sigma rules for :ref:`playbook` are copied to ``/nsm/repo/rules/sigma``.
+- :ref:`sigma` rules for :ref:`elastalert` are copied to ``/nsm/repo/rules/sigma``.
 
 - When updating the system, :ref:`soup` will ask for the location of the latest ISO media and will then update using that media rather than pulling from the Internet.
 

diff --git a/architecture.rst b/architecture.rst
@@ -138,8 +138,6 @@ Search nodes connect to both the manager and receiver nodes and pull events from
 
 If you have a manager or managersearch that is under heavy load due to handling a high volume of events, then system resources can be freed by directing the Elastic Agent to only output events to the receiver node(s) in the environment. Once all configurable and advanced settings are enabled, this feature can be set in SOC Configuration UI under ``elasticfleet > enable_manager_output``. Setting this to ``False`` will prevent the Elastic Agent from sending events to the manager, managersearch, or standalone nodes.
 
-If you have a manager or managersearch that is under heavy load due to handling a high volume of events, then system resources can be freed by directing the Elastic Agent to only output events to the receiver node(s) in the environment. Once all configurable and advanced settings are enabled, this feature can be set in SOC Configuration UI under ``elasticfleet > enable_manager_output``. Setting this to ``False`` will prevent the Elastic Agent from sending events to the manager, managersearch, or standalone nodes.
-
 Receiver nodes need to be close to the search nodes because when you add a new receiver node to the grid, the search nodes add the :ref:`redis` service as an input in their configs automatically. If you were to place a receiver node at a remote site, then ALL of your search nodes would be trying to access that :ref:`redis` queue remotely. You do not save any bandwidth by placing a receiver node at a remote site.
 
 There are a couple of things to be aware of regarding receiver nodes and Elastic Agents. The first is Fleet which handles things like updating the agents and scheduling searches. The other is the Elastic Agent log output, which in this case is :ref:`logstash` running on the manager or receiver node. Due to limitations in Elastic licensing we can only have a single output policy. That means that when you add a receiver or a fleet node it gets added to a list that is distributed to the agents. The agents go down that list and stop after a successful connection. The only way to direct agents to specific receivers is to use firewall rules to block agents to certain receivers. Again keep in mind that there is no bandwidth savings here because the search nodes still need to empty the :ref:`redis` queue on the receiver nodes.

diff --git a/attack-navigator.rst b/attack-navigator.rst
@@ -19,13 +19,6 @@ To access Navigator, log into :ref:`soc` and then click the Navigator hyperlink
 .. image:: images/97_navigator.png
   :target: _images/97_navigator.png
 
-Default Layer - Playbook
-------------------------
-
-The default layer is titled ``Playbook`` and is automatically updated when a Play from :ref:`playbook` is made active/inactive. This allows you to see your Detection Playbook coverage across the ATT&CK framework.
-
-Right-clicking any Technique and selecting ``View Related Plays`` will open Playbook with a pre-filtered view of any plays that are tagged with the selected Technique.
-
 Configuration
 -------------
 

diff --git a/bpf.rst b/bpf.rst
@@ -57,7 +57,7 @@ For example:
 Adding Comments
 ~~~~~~~~~~~~~~~
 
-Starting in Security Onion 2.4.30, comments can be added to the filters via the SOC UI. For example:
+To provide more context to your filters, you can add comments. For example:
 
 ::
 

diff --git a/curator.rst b/curator.rst
diff --git a/docker.rst b/docker.rst
@@ -47,6 +47,12 @@ The manager node runs a Docker registry. From https://docs.docker.com/registry/r
 
     If you have multiple instances of Docker running in your environment (e.g., multiple physical or virtual machines, all running the Docker daemon), each time one of them requires an image that it doesn’t have it will go out to the internet and fetch it from the public Docker registry. By running a local registry mirror, you can keep most of the redundant image fetch traffic on your local network.
 
+If you see errors relating to ``so-dockerregistry`` (Docker Registry), then please take a look at the following discussions to see if your symptoms match and if their solutions may help you:
+
+https://github.com/Security-Onion-Solutions/securityonion/discussions/12078
+
+https://github.com/Security-Onion-Solutions/securityonion/discussions/12635
+
 Networking and Bridging
 -----------------------
 
@@ -86,38 +92,6 @@ VMware Tools
 
 If you have VMware Tools installed and you suspend and then resume, the Docker interfaces will no longer have IP addresses and the Elastic stack will no longer be able to communicate. One workaround is to remove ``/etc/vmware-tools/scripts/vmware/network`` to prevent VMware suspend/resume from modifying your network configuration.
 
-Dependencies
-------------
-
-Playbook
-~~~~~~~~
-
-| ``so-playbook`` - REQ - Playbook Web App
-| ``so-navigator`` - OPT - Navigator Web App
-| ``so-soctopus`` - REQ - Automation
-
-SOCtopus
-~~~~~~~~
-
-| ``so-soctopus`` - REQ - SOCtopus App
-| ``so-elasticsearch`` - OPT - Automation
-
-Suricata
-~~~~~~~~
-
-| ``so-suricata`` - REQ - Suricata app
-
-Kibana
-~~~~~~
-
-| ``so-kibana`` - REQ - Kibana Web App
-| ``so-elasticsearch`` - REQ -
-
-Zeek
-~~~~
-
-| ``so-zeek`` - REQ - Zeek app
-
 More Information
 ----------------
 

diff --git a/elastic-fleet.rst b/elastic-fleet.rst
@@ -159,6 +159,12 @@ The section provides details such as:
 
     We do NOT recommend changing these settings, as they are managed by Security Onion.
 
+If you want more granular control over which Fleet Server an Agent will send logs to, there are two options:
+
+- The first option is to use firewall rules to only allow certain agents. Suppose you have two Fleet Server Nodes, one at 192.168.55.25 and the other at 192.168.58.25. If you want your endpoints in the 192.168.58.0/24 subnet to only connect to the Fleet server at 192.168.58.25, you would add custom firewall rules via :ref:`administration` --> Configuration --> firewall --> hostgroups --> elastic_agent_endpoint. Select the 192.168.58.25 Fleet Node and add ``192.168.58.0/24``. Endpoints in that subnet will still attempt to connect to the Fleet Server Node at 192.168.55.25, but since it is not accessible (no firewall rules that enable communication), they will connect to the Fleet Node at 192.168.58.25.
+
+- The second option is to purchase an Elastic license. A paid Elastic license offers the ability to customize different Outputs per Agent Policy.
+
 Custom FQDN URL
 ---------------
 

diff --git a/faq.rst b/faq.rst
@@ -194,10 +194,10 @@ Should I backup my Security Onion box?
 
 Security Onion automatically backs up some important configuration as described in the :ref:`backup` section. However, there is no automated data backup. Network Security Monitoring as a whole is considered "best effort". It is not a "mission critical" resource like a file server or web server. Since we're dealing with "big data" (potentially terabytes of full packet capture) of a transient nature, backing up the data would be prohibitively expensive. Most organizations don't do any data backups and instead just rebuild boxes when necessary.
 
-How can I add and test local rules?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+How can I add local rules?
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Please see the :ref:`local-rules` section.
+Please see the :ref:`detections` section.
 
 Can I connect Security Onion to Active Directory or LDAP?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

diff --git a/grid.rst b/grid.rst
@@ -18,7 +18,7 @@ Starting at the top of the page, there is a ``Grid EPS`` value in the upper-righ
 
   The ``EPS`` column represents Events Per Second consumed, so it will only be relevant on nodes that ingest data. Pure sensors do not ingest events, so those nodes will show 0 EPS. If you want to identify sensors that are generating large volumes of events, you can sort by the ``Mgmt Out`` column, which shows the outbound traffic throughput on the management network interface.
 
-Starting in Security Onion 2.4.40, there is a new checkbox in the options dropdown near the top of the page. This checkbox will show additional sensor-related columns in the table. You can use these sortable columns to help identify sensors that may be underperforming or due for a hardware upgrade. As these additional columns take up significant screen area, they will only be visible on wide displays where the SOC web browser window is wide enough to show a large number of tabular columns.
+The options dropdown near the top of the page includes a checkbox which will show additional sensor-related columns in the table. You can use these sortable columns to help identify sensors that may be underperforming or due for a hardware upgrade. As these additional columns take up significant screen area, they will only be visible on wide displays where the SOC web browser window is wide enough to show a large number of tabular columns.
 
 .. image:: images/76_grid_options.png
   :target: _images/76_grid_options.png
@@ -30,10 +30,6 @@ Node Status
 
 The ``Node Status`` section displays many different fields relating to each node's status.
 
-.. note::
-
-  Starting in Security Onion 2.4.40, a significant number of new metrics are included in the ``Node Status`` section. Older versions will not have all of the metrics shown below.
-
 .. note::
 
   If a node has not checked in recently then the metrics and statuses for that node will be slightly grayed out, to indicate that the values are stale.

diff --git a/hardware.rst b/hardware.rst
@@ -90,7 +90,7 @@ Please see the :ref:`architecture` section for detailed deployment scenarios.
 Standalone Deployments
 ----------------------
 
-In a standalone deployment, the manager components and the sensor components all run on a single box, therefore, your hardware requirements will reflect that. You'll need at minimum 16GB RAM, 4 CPU cores, and 200GB storage. At the bare minimum of 16GB RAM, you will need swap space to avoid issues. We recommend a minimum of 24GB of RAM if you plan on monitoring traffic. The more traffic you plan on monitoring this RAM requirement will also increase. 
+In a standalone deployment, the manager components and the sensor components all run on a single box so your hardware requirements will reflect that. You'll need at minimum 16GB RAM, 4 CPU cores, and 200GB storage. At the bare minimum of 16GB RAM, you will need swap space to avoid issues. We recommend a minimum of 24GB of RAM if you plan on monitoring even a small amount of network traffic. More network traffic means higher hardware requirements.
 
 This deployment type is recommended for evaluation purposes, POCs (proof-of-concept) and small to medium size single sensor deployments. Although you can deploy Security Onion in this manner, it is recommended that you separate the backend components and sensor components.
 

diff --git a/idh.rst b/idh.rst
@@ -45,7 +45,7 @@ OpenCanary logs can be found through :ref:`dashboards`, :ref:`hunt`, or :ref:`ki
 
      event.dataset: idh
 
-Sigma Plays within :ref:`playbook` look for certain logs emitted by OpenCanary to generate alerts, which can be viewed in the :ref:`alerts` interface.
+Sigma rules within :ref:`detections` look for certain logs emitted by OpenCanary to generate alerts, which can be viewed in the :ref:`alerts` interface.
 
 Services Configuration
 ----------------------

diff --git a/index.rst b/index.rst
@@ -26,12 +26,12 @@ Security Onion Documentation
    accounts
    services
    customizing
-   tuning
    tricks
    utilities
    help
    pro
    security
+   telemetry
    release-notes
    appendix
    cheat-sheet
diff --git a/introduction.rst b/introduction.rst
@@ -95,11 +95,6 @@ CyberChef
 .. image:: images/68_cyberchef.png
   :target: _images/68_cyberchef.png
 
-Playbook
-~~~~~~~~
-
-:ref:`playbook` allows you to create a Detection Playbook, which itself consists of individual plays. These plays are fully self-contained and describe the different aspects around the particular detection strategy.
-
 Workflow
 --------
 
@@ -112,7 +107,6 @@ All of these analysis tools work together to provide efficient and comprehensive
      - If any of those alerts or logs look interesting, you might want to pivot to :ref:`pcap` to review the full packet capture for the entire stream.
      - Depending on what you see in the stream, you might want to send it to :ref:`cyberchef` for further analysis and decoding.
      - Escalate alerts and logs to :ref:`cases` and document any observables. Pivot to :ref:`hunt` to cast a wider net for those observables.
-     - Develop a play in :ref:`playbook` that will automatically alert on observables moving forward and update your coverage in :ref:`attack-navigator`.
      - If you have the :ref:`elastic-agent` deployed, then you might want to search for additional host logs or run live queries against your endpoints using :ref:`osquery<osquery-manager>`.
      - Finally, return to :ref:`cases` and document the entire investigation and close the case.
 

diff --git a/kibana.rst b/kibana.rst
@@ -17,7 +17,7 @@ Kibana Dashboards
 
 We've included a simple set of dashboards in Kibana. These Kibana dashboards are not as comprehensive as those in SOC :ref:`dashboards`.
 
-Once you log into Kibana, you should start on the ``Security Onion - Home`` dashboard. Notice the visualization in the upper left is labeled ``Security Onion - Navigation``. This navigation panel contains links to other dashboards and will change depending on what dashboard you're currently looking at. For example, when you're on the ``Security Onion - Home`` dashboard and click the ``Alert`` link, you will go to the ``Security Onion - Alerts`` dashboard and the Navigation panel will then contain links to more specific alert dashboards for :ref:`playbook` and :ref:`suricata`. When you're done looking at alerts, you can click the ``Home`` link in the navigation panel to go back to the main ``Security Onion - Home`` dashboard.
+Once you log into Kibana, you should start on the ``Security Onion - Home`` dashboard. Notice the visualization in the upper left is labeled ``Security Onion - Navigation``. This navigation panel contains links to other dashboards and will change depending on what dashboard you're currently looking at. For example, when you're on the ``Security Onion - Home`` dashboard and click the ``Alert`` link, you will go to the ``Security Onion - Alerts`` dashboard and the Navigation panel will then contain links to more specific alert dashboards for :ref:`suricata`. When you're done looking at alerts, you can click the ``Home`` link in the navigation panel to go back to the main ``Security Onion - Home`` dashboard.
 
 If you ever need to reload Kibana dashboards, you can run the following command on your manager:
 

diff --git a/local-rules.rst b/local-rules.rst
diff --git a/logs.rst b/logs.rst
@@ -13,7 +13,6 @@ Once logs are generated by network sniffing processes or endpoints, where do the
    redis
    elasticsearch
    elastalert
-   curator
    data-fields
    alert-data-fields
    elastalert-fields