Security Onion Policy Customization

So I've got my environment all setup and purring away, which I will discuss in the next home lab blog. After security onion was all setup nice and collecting all sorts of lovely data, it is absolutely spewing alerts. It's quite fun to dig through the alert and determine if the activity is malicious or not, but once you do that you'll want to modify the policy itself in most cases to stop getting that event. For example, I'm getting some Docker alerts: Normally it would be nice to see this, but I'm running docker on almost every host so there's going to be a ton of this and info/warning messages aren't that interesting by themselves to me. The documentation recommends first looking at the number of rules in each category and disabling entire categories that don't apply to your environment.

$ cut -d\" -f2 /opt/so/rules/nids/all.rules | grep -v "^$" | grep -v "^#" | awk '{print $1, $2}'|sort |uniq -c |sort -nr
  12400 ET MALWARE
   5597 ET WEB_SPECIFIC_APPS
   2280 ET PHISHING
   1695 ET EXPLOIT
   1378 ET INFO
   1202 ET POLICY
   1193 ET EXPLOIT_KIT
   1192 ET ADWARE_PUP
   1053 ET HUNTING
    923 ET MOBILE_MALWARE
    918 ET TOR
    795 ET WEB_CLIENT
    732 ET WEB_SERVER
    676 ET ATTACK_RESPONSE
    532 ET ACTIVEX
    418 GPL NETBIOS
    321 ET USER_AGENTS
    313 ET SCAN
    309 GPL SQL
    231 ET CURRENT_EVENTS
    162 ET SHELLCODE
    135 ET JA3
    116 GPL RPC
    112 ET DOS
    111 ET P2P
    100 ET CINS
     94 GPL FTP
     90 GPL EXPLOIT
     84 ET GAMES
     67 GPL WEB_SERVER
     66 GPL ICMP_INFO
     60 GPL MISC
     59 ET CHAT
     56 ET NETBIOS
     47 GPL SCAN
     39 GPL ICMP
     37 ET DROP
     35 ET DNS
     33 GPL IMAP
     32 ET 3CORESec
     31 GPL CHAT
     29 ET COINMINER
     25 ET CNC
     24 GPL SHELLCODE
     21 ET FTP
     20 GPL POP3
     20 GPL POLICY
     18 ET SCADA
     17 GPL SNMP
     17 ET WORM
     17 ET VOIP
     16 ET SNMP
     16 ET INAPPROPRIATE
     15 GPL ATTACK_RESPONSE
     14 GPL WEB_CLIENT
     14 GPL DNS
     14 ET COMPROMISED
     13 GPL SMTP
     12 GPL TFTP
     12 ET Threatview.io
     10 ET SMTP
      9 GPL INAPPROPRIATE
      8 GPL P2P
      8 ET TFTP
      5 GPL TELNET
      5 ET TELNET
      4 GPL VOIP
      3 GPL WEB_SPECIFIC_APPS
      2 GPL WORM
      2 GPL DOS
      2 GPL ACTIVEX
      2 ET SQL
      2 ET MISC
      1 GPL MALWARE
      1 GPL GAMES
      1 ET RPC

So, I'd like to completely silence this one! There are two categories I think I could forego:

• SCADA
• VOIP But they make up such a small number of rules, I'm going to just leave them. Next they throw you into how to modify NIDS rules, and how to modify HIDS rules. There are then two places and format to modify alert rules:
• Wazuh via /opt/so/rules/hids/local_rules.xml
• so-rule via SID and /opt/so/saltstack/local/pillar/global.sls

Modify OSSEC Wazuh Rules

The alert is coming from ossec, so we can tune these rules in /opt/so/rules/hids/local_rules.xml. First I need to find and copy the existing rule. rule.uuid from the alert drilldown is 86001. So, let's fine where that bad boy is:

$ grep -rnw '/opt/so/rules/hids/ruleset/rules' -e 'id="86001"'
/opt/so/rules/hids/ruleset/rules/0455-docker_rules.xml:21:    <rule id="86001" level="1">

cat /opt/so/rules/hids/ruleset/rules/0455-docker_rules.xml | grep -e 'id="86001"' -B 5 -A 5

    <!--
    time="2017-02-18T08:48:04.269962983Z" level=info msg="Text"
    Oct 25 12:19:15 localhost dockerd[1759]: time="2017-02-18T08:48:04.269962983Z" level=info msg="Text"
    -->
    <rule id="86001" level="1">
        <if_sid>86000</if_sid>
        <field name="docker.level">info</field>
        <description>Docker: Information message</description>
        <group>docker-info,</group>
    </rule>

Awesome, so now we're supposed to copy this to /opt/so/rules/hids/local_rules.xml, place it inside a <group> tag and give it a name. Then, update the <rule> section with noalert="1" and overwrite="yes". Here is the original local_rules.xml:

<!-- Local rules -->
<!-- Modify it at your will. -->
<!-- Copyright (C) 2015-2020, Wazuh Inc. -->
<!-- Example -->
<group name="local,syslog,sshd,">
  <!--
  Dec 10 01:02:02 host sshd[1234]: Failed none for root from 1.1.1.1 port 1066 ssh2
  -->
  <rule id="100001" level="5">
    <if_sid>5716</if_sid>
    <srcip>1.1.1.1</srcip>
    <description>sshd: authentication failed from IP 1.1.1.1.</description>
    <group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>
  </rule>
</group>

That example seems useless so I removed that, and made the changes i think I need:

<!-- Local rules -->
<!-- Modify it at your will. -->
<!-- Copyright (C) 2015-2020, Wazuh Inc. -->
<!-- Docker -->
<group name="docker,">
    <!-- Disable docker info logs alerting -->
    <rule id="86001" level="1" noalert="1" overwrite="yes">
        <if_sid>86000</if_sid>
        <field name="docker.level">info</field>
        <description>Docker: Information message</description>
        <group>docker-info,</group>
    </rule>
</group>

I did the same for Docker warning.

Modify All Other Rules

Here's another one that I've dove into and am willing to filter out of my alerts: The traffic is only coming from one machine on my Wifi, which happens to be my only windows machine. Here is a packet capture: This is a domain operated by Microsoft, it's used on Windows hosts to determine if there is an internet connection available. This can safely be filtered out. To modify Wazuh rules, we need the SID which is nested in the message payload. It is 2031071. You can search/view the original policies like this:

grep SID /opt/so/rules/nids/all.rules

Now we need to write a 'pillar' which is going to suppress this. What I want to do, is make sure I get a notification if all of a sudden there are a ton of these requests leaving my windows endpoint. So...

2031071:
  - rate_filter:
      gen_id: 1
      track: by_src
      count: 10
      seconds: 60
      new_action: pass
      timeout: 60

I added this to my /opt/so/saltstack/local/pillar/global.sls. To update the rules, execute: so-suricata-restart Read the output as it confirms the changes you've made! Here is documentation for how I figured all this out:

• https://docs.securityonion.net/en/2.3/managing-alerts.html#suppressions
• https://docs.securityonion.net/en/2.3/managing-alerts.html#identifying-rule-categories
• https://suricata.readthedocs.io/en/suricata-6.0.0/configuration/global-thresholds.html#threshold-event-filter

Covering a ton of rules

There was a particular group of SID's that I wanted to filter out for a specific host. There were well over 1000 SID's that I wanted the same rule to apply for. The config format here doesn't allow for any regex selection or anything fancy, it just has to contain a rule for every SID... So I quickly wrote something with just bash and echo to generate this for me.

#!/bin/bash
START=$1
END=$2
for i in $(seq $1 $2); do
    echo "    $i:"
    echo "      - suppress:"
    echo "          gen_id: 1"
    echo "          track: by_src"
    echo "          ip: 10.200.0.2/32"
done

Disabling a Rule Entirely

Customizing the rules is a little involved, we can actually disable a rule, or a set of rules by regex with SO CLI. For example, I'm getting a ton of alerts for SID 2013504 'ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management'. This is just my linux nodes auto-updating, and this is going to happen A LOT. The merit of having this would be if my systems had a specific update window and this was outside of it, or perhaps I had no linux machines in the environment so it would be an anomaly. If someone were to gain access to one of my servers, and try to install a package I'm sure there would be many other IOC's to dive into outside of this, so I think it is safe to disable this.

so-rule disabled add 2013504

so-rule disabled list
Disabled rules:
  - 2013504