Managing alerts - changes to disablesid.conf not working

[Scott Ellis]

I have added the lines (plus a few more in a similar vein):
1:2101411 # GPL SNMP public access udp
1:2001329 #ET POLICY RDP connection request
1:2001330 #ET POLICY RDP connection response

to the file:
sudo vi /etc/nsm/pulledpork/disablesid.conf
on my master server

and have run:
sudo /usr/bin/rule-update

Unfortunately, rule 1:2101411 is still generating alerts as are the others. From a troubleshooting standpoint, what should I look at next? I ran
sudo salt ‘*”’ test.ping and all sensort responded.

[Wes]

Scott,

Have you tried running /usr/bin/rule-update on the sensor?

If you're running salt, this info should be replicated from the master to the sensors every 15 minutes:

https://github.com/Security-Onion-Solutions/security-onion/wiki/Salt

Have you waited at least 15 minutes since modifying disablesid.conf?

Thanks,
Wes

[Scott Ellis]

Wes,

I'll take a look at this later this morning, but it appears that Salt is not working properly on one of the sensors. Is there a procedure you can point me to that will help me troubleshoot it?

Also, with respect to Salt, and in the interest of security, i ran visudu and made an edit that would prompt users to enter the password whenever they execute as "sudo". It would appear that Salt undoes my changes. This change may also have coincided with salt breaking on the one sensor which, in a strange matter of coincidence, happens to be the one server to retain my sudo behavior change. Either salt has always been broken, or the change i made broke it(?).

Thanks,
Scott

Sent from my iPhone

> --
> Follow Security Onion on Twitter!
> https://twitter.com/securityonion
> ---
> You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/cv1gJAzcCag/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.

[Doug Burks]

On the sensor in question, run "sudo salt-call state.highstate" and
check for errors.

> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.

> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.

--
Doug Burks

[Scott Ellis]

Here is the result...is there a way to test from the affected server that it is properly connecting to the server? Does "sudo salt-call state.highstate" make any changes to Salt to repair any problems it finds? the output had a couple of interesting lines in it. 

Summary

-------------

Succeeded: 16

Failed:     0

-------------

Total states run:     16

sellis@Rphal:~$ 

[Scott Ellis]

And....then I run it on the correct machine and here is your error:

[ERROR   ] The Salt Master has cached the public key for this node, this salt minion will wait for 10 seconds before attempting to re-authenticate

Minion failed to authenticate with the master, has the minion key been accepted?

[Doug Burks]

Run "sudo salt-key -L" on the master server to check for the minion key.

For more information, please see:
https://github.com/Security-Onion-Solutions/security-onion/wiki/Salt

[Scott Ellis]

I am pretty sure I fixed the issue with salt, but it's been 30 + minutes and i am still receiving alerts on the "disabled" IDs in my disabledsid.conf file.  i went onto one of the sensors that I know is throwing the alerts, and I checked the sudo vi /etc/nsm/pulledpork/disablesid.conf file and none of the IDs have updated into that file on the sensor...should they be somewhere else?  Where should I check to see that the updates should be updating to? 

Thanks

[Doug Burks]

salt does not replicate disablesid.conf down to the sensors. Your
master server runs PulledPork which processes the ruleset using
disablesid.conf and writes out the rules to
/etc/nsm/rules/downloaded.rules. salt replicates the /etc/nsm/rules/
directory to the sensors.

You could test as follows:

sudo salt '*' cmd.run 'grep 2101411 /etc/nsm/rules/downloaded.rules'

If PulledPork disabled that SID correctly and salt replicated
downloaded.rules correctly, then that rule should be commented out on
all sensors like this:
# alert udp $EXTERNAL_NET any -> $HOME_NET 161 (msg:"GPL SNMP public
access udp"; content:"public"; fast_pattern:only;
reference:bugtraq,2112; reference:bugtraq,4088;
reference:bugtraq,4089; reference:cve,1999-0517;
reference:cve,2002-0012; reference:cve,2002-0013;
classtype:attempted-recon; sid:2101411; rev:12;)

[Doug Burks]

Looks like one of your sensors does NOT have the rule commented out so
I would check to see if salt is running correctly there.

If you're still receiving alerts for that rule on sensors where the
rule IS commented out, is it possible that you have a backlog of
alerts from when the rule was still enabled?

On Mon, Feb 22, 2016 at 12:49 PM, Scott Ellis <scor...@gmail.com> wrote:
> here is the output:
>
> #######@########:~$ sudo salt '*' cmd.run 'grep 2101411
> /etc/nsm/rules/downloaded.rules'
>
> ######:

>
> # alert udp $EXTERNAL_NET any -> $HOME_NET 161 (msg:"GPL SNMP public
> access udp"; content:"public"; fast_pattern:only; reference:bugtraq,2112;
> reference:bugtraq,4088; reference:bugtraq,4089; reference:cve,1999-0517;
> reference:cve,2002-0012; reference:cve,2002-0013; classtype:attempted-recon;
> sid:2101411; rev:12;)
>

> ######:

>
> # alert udp $EXTERNAL_NET any -> $HOME_NET 161 (msg:"GPL SNMP public
> access udp"; content:"public"; fast_pattern:only; reference:bugtraq,2112;
> reference:bugtraq,4088; reference:bugtraq,4089; reference:cve,1999-0517;
> reference:cve,2002-0012; reference:cve,2002-0013; classtype:attempted-recon;
> sid:2101411; rev:12;)
>

> #######:

>
> alert udp $EXTERNAL_NET any -> $HOME_NET 161 (msg:"GPL SNMP public
> access udp"; content:"public"; fast_pattern:only; reference:bugtraq,2112;
> reference:bugtraq,4088; reference:bugtraq,4089; reference:cve,1999-0517;
> reference:cve,2002-0012; reference:cve,2002-0013; classtype:attempted-recon;
> sid:2101411; rev:12;)
>

> #######:

>
> # alert udp $EXTERNAL_NET any -> $HOME_NET 161 (msg:"GPL SNMP public
> access udp"; content:"public"; fast_pattern:only; reference:bugtraq,2112;
> reference:bugtraq,4088; reference:bugtraq,4089; reference:cve,1999-0517;
> reference:cve,2002-0012; reference:cve,2002-0013; classtype:attempted-recon;
> sid:2101411; rev:12;)
>

> ######@#######:~$
>
> I am still seeing alerts, across the board, on this rule and all the others
> I have disabled. Please let me know if you have any further suggestions.
> Perhaps I should I try restarting everything, but I was under the impression
> that the update command would take care of reloading the rules.
>
> Thanks
>
> S

[Scott Ellis]

I noticed that after I posted - after digging a little deeper it seems that Salt is still failing on that server. This all started (I think) when we made a change to sudo to force passwords when users ssh'd in.

I'll be working through reinstalling Salt minion on that server later this AM.