Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Insufficient interactive session detection during rule update #1650

Closed
bitskri3g opened this issue Oct 14, 2019 · 6 comments
Assignees
Projects

Comments

@bitskri3g
Copy link

@bitskri3g bitskri3g commented Oct 14, 2019

The changeset implemented to address #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 Security-Onion-Solutions/securityonion-rule-update@8038355). 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

This comment has been minimized.

Copy link
Contributor

@dougburks dougburks commented Oct 15, 2019

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

This comment has been minimized.

Copy link
Author

@bitskri3g bitskri3g commented Oct 15, 2019

@dougburks That would work fine!

@dougburks dougburks self-assigned this Oct 15, 2019
@dougburks dougburks added this to To do in 16.04.6.3 via automation Oct 15, 2019
dougburks added a commit to Security-Onion-Solutions/securityonion-rule-update that referenced this issue Oct 17, 2019
@dougburks dougburks moved this from To do to In progress in 16.04.6.3 Oct 17, 2019
@dougburks

This comment has been minimized.

Copy link
Contributor

@dougburks dougburks commented Oct 17, 2019

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!

@dougburks dougburks moved this from In progress to In Testing in 16.04.6.3 Oct 17, 2019
@weslambert

This comment has been minimized.

Copy link
Collaborator

@weslambert weslambert commented Oct 18, 2019

Looks good from my testing 👍

@dougburks dougburks moved this from In Testing to Tested in 16.04.6.3 Oct 18, 2019
@dougburks

This comment has been minimized.

@dougburks dougburks closed this Oct 21, 2019
16.04.6.3 automation moved this from Tested to Done Oct 21, 2019
@bitskri3g

This comment has been minimized.

Copy link
Author

@bitskri3g bitskri3g commented Oct 23, 2019

This has been resolved - thanks @dougburks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
16.04.6.3
  
Done
3 participants
You can’t perform that action at this time.