Insufficient interactive session detection during rule update

Security-Onion-Solutions / security-onion

Security Onion 16.04 - Linux distro for threat hunting, enterprise security monitoring, and log management

https://securityonion.net

3.06k stars 521 forks source link

Insufficient interactive session detection during rule update #1650

Closed bitskri3g closed 4 years ago

bitskri3g commented 4 years ago

The changeset implemented to address https://github.com/security-onion-solutions/security-onion/issues/724 doesn't accurately detect interactive sessions not created by an actual user, e.g. when initiated by cloud-init:

            #!/bin/bash
            ...
            cat > "/root/sosetup.conf" << __EOF__
            # ANSWERFILE generated by sosetup -w option
            # Generation date: Sun Oct 13 15:26:45 EDT 2019
            # Generated on host test-so-master-rq7xgvcecfct
            #
            # These fields were computed automatically
            #IP=172.17.0.1
            #CORES=4
            #ALL_INTERFACES=ens3
            #NUM_INTERFACES=1
            #
            # This field is specific to reading an answer file
            SNIFFING_INTERFACES='ens3'
            #
            # These fields were generated from your answers
            SERVER=1
            SERVERNAME=localhost
            SSH_USERNAME=''
            SGUIL_SERVER_NAME=securityonion
            SGUIL_CLIENT_USERNAME='$username'
            SGUIL_CLIENT_PASSWORD_1='$userpass'
            XPLICO_ENABLED=no
            OSSEC_AGENT_ENABLED=yes
            OSSEC_AGENT_LEVEL=5
            SALT=yes
            SENSOR=0
            BRO_ENABLED=yes
            IDS_ENGINE_ENABLED=yes
            SNORT_AGENT_ENABLED=yes
            BARNYARD2_ENABLED=yes
            PCAP_ENABLED=yes
            PCAP_AGENT_ENABLED=yes
            PRADS_ENABLED=no
            SANCP_AGENT_ENABLED=no
            PADS_AGENT_ENABLED=no
            HTTP_AGENT_ENABLED=no
            ARGUS_ENABLED=no
            IDS_RULESET='ETOPEN'
            OINKCODE=''
            PF_RING_SLOTS=4096
            IDS_ENGINE=Suricata
            IDS_LB_PROCS=1
            BRO_LB_PROCS=1
            EXTRACT_FILES=yes
            PCAP_SIZE=150
            PCAP_RING_SIZE=64
            PCAP_OPTIONS='-c'
            WARN_DISK_USAGE=80
            CRIT_DISK_USAGE=90
            DAYSTOKEEP=30
            DAYSTOREPAIR=7
            LOGSTASH_OUTPUT_REDIS=no
            LOGSTASH_INPUT_REDIS=no
            ELASTIC=yes
            FORWARD=
            LOG_SIZE_LIMIT=15000000000
            __EOF__

            sosetup -y -f /root/sosetup.conf
            $signal_master_complete
            ...

When cloud-init executes the above, it is done interactively by the daemon, but tty -s exits nonzero, so it waits a random amount of minutes between 1 and 50 (as described in https://github.com/Security-Onion-Solutions/securityonion-rule-update/commit/80383559525982ed87b358f6bd8d374d2a29a804). This is not ideal when you're bootstrapping a new installation in a cloudy environment. Killing the sleep at the terminal lets the installation continue as expected.

I think a --force-update flag in sosetup would be appropriate here, which would let you run rules-update immediately, even if tty -s has a nonzero exit.

dougburks commented 4 years ago

Hi @bitskri3g ,

How about if we default rule-update to always running immediately with no delay? Then have a check to see if the word cron is being passed as a parameter and only then add the random delay. The only time that would ever happen is when called from our cron job, so that should resolve this issue for your use case, right?

bitskri3g commented 4 years ago

@dougburks That would work fine!

dougburks commented 4 years ago

securityonion-rule-update - 20151201-1ubuntu1securityonion20 is now available at ppa:securityonion/test.

Please test/verify as follows:

start with a 16.04.6.2 box
snapshot the VM if possible

add the test PPA:

sudo add-apt-repository -y ppa:securityonion/test

install all updates:
```
sudo soup -y
```
verify that /etc/cron.d/rule-update now calls rule-update with the cron option:
```
cat /etc/cron.d/rule-update
```
run rule-update with cron option and verify delay to avoid overwhelming rule download sites:
```
sudo rule-update cron
```
run rule-update with no options and verify no delay:
```
sudo rule-update
```
note that sensors running salt won't run rule-update at all but simply call salt
anything else we missed?

Thanks in advance for your time and effort!

weslambert commented 4 years ago

Looks good from my testing 👍

dougburks commented 4 years ago

Published: https://blog.securityonion.net/2019/10/securityonion-rule-update-20151201.html

bitskri3g commented 4 years ago

This has been resolved - thanks @dougburks!