SecurityOnion 16.04 - Squild

  Interesting issue arose today while trying to validate an installation of SecurityOnion 16.04.  I was not seeing any traffic except SURICATA rules (even though ET PRO is installed).  I decided to make my own rule in local.rules.  

Get ready for some fun here, cause about 6Gb of ingest and I decided to write this without thinking:

alert any any -> any any (msg:"TEST TEST"; flow:established; classtype:misc_attack; sid:"999999"; rev:1;)

Then I ran sudo rule-update

Not starting that any any will just about kill the system as it alerts everything, but I also think the SID number was too low to use, which might have caused other issues.  

Five minutes into it and I am seeing in Squert 1K alert, 10 minutes I am at 40K alerts, but interesting enough some ET PRO rules also are now firing.     I removed the local.rules alert, reran sudo rule-update (no more TEST rules). 

TEST Alert is now showing 150K in Squert.  

Here are the commands I typed (From Suricata gone wild)

1. sudo so-sguild-stop
2. sudo mysql --defaults-file=/etc/mysql/debian.cnf -Dsecurityonion_db
3. SELECT COUNT(*) AS cnt, signature, signature_id FROM event WHERE status=0 GROUP BY signature ORDER BY cnt DESC LIMIT 20;   (Top 20)

Interesting find here now under uncategorized events : 

TEST Rule 150K    999999

Snort Alert [1:999999:1]  999999

So I have two alerts now for the same issues (This is because mid-stream I removed the TEST rule from my local.rules which deleted it out of my download.rules

1. UPDATE event SET status=1, WHERE event.status=0 and event.signature LIKE 'TEST%';
2. exit
3. sudo so-squid-start

This cleaned up the TEST alert, but I still had the Snort Alert. I wanted to wait for full processing then delete the Snort Alert to see if it came back

About an hour later I validated that traffic was done processing and that Snort Alert was still there.

1. sudo so-sguild-stop
2. sudo mysql --defaults-file=/etc/mysql/debian.cnf -Dsecurityonion_db
3. UPDATE event SET status=1, WHERE event.status=0 and event.signature_id='999999';
4. exit
5. sudo so-squid-start

My system was now clean from the ghost SID.  

Udemy: Snort Intrusion Detection

The other day I started a Udemy course: Snort Intrustion Detection, Rule Writing, and PCAP Analysis. In the lesson they use VirtualBox, I chose to use VMware, as that is what I have installed currently on my machine. Second was that a few of the sections were about setting up SecurityOnion and Kali (Both of which I already have active VMs for). That enabled me to shave off some of the time running through the training as they were setup as vanilla load, the only exception is that I have been using Suricata vice Snort, but for the most part I did not have an issue. One of the first rules was about SPAM, which we created a basic rule, and then added offset, and depth which he was able to explain. Suricata did not like the depth talked about in the video, stating it was shorter then the content (+1) to that number, and seemed to work with no ill effect. I need to read up more about offset/depth with reguards to Suricata, and see if it was just something I was doing wrong, or if there is a true differance between Snort and Suricata. Following that we did some other rules, and validated rules against VMs with known vulernabilities. I think this course helped a bit in understanding how the rulesets work, and will help with my current job.

Working with Snort.Conf

I spent the better part of today creating variables in a snort.conf for test deployment. We finally decided on all the IP ranges we needed this morning for this event, and so it was left up to me to get the configuration created. I used the template snort.conf from Snorts website, and from there created about 40 variables, not sure if that too much, not enough? First time really working on this side of it.


I did some basic googling before starting and thought I had read somewhere that you could set ipvar with a - between IP addresses, say 192.168.1.1-192.168.3.254, well let me tell you that does not work. (btw just using 192 ip scheme for the post)


So I thought I was stuck in typing out 192.168.1.1, 192.168.1.2, 192.168.1.3, etc till I input all 800ish IPs, and that was going to take a while. First thoughts were to use Excel to start with one IP and drag across to auto populate the IPs required and then export to CVS. This worked, but it was making the variables gigantic, and if there was an issue with one IP, it was hard to look through all the IPs in the list.


Next, I found a site that converts IP to CIDR, and I know that snort.conf accepts CIDR as inputs in the ipvar variable. So it's easy if its say 192.168.1.0/24, but what about if it's 192.168.1.55-192.168.1.254. Using the website I created a list of CIDR addresses like this


ipvar phones [192.168.1.55/32,192.168.1.56/29,192.168.1.64/26,192.168.1.128/26,192.168.1.192/27,192.168.1.224/28,192.168.1.240/29,192.168.1.248/30,192.168.1.252/31,192.168.1.254/32]


Well, this worked as it was ingested during a restart of the sensors on SecurityOnion, after that, it was more of just cleaning up the snort.conf. I had a few missing spaces, a few extra spaces, after each edit I would run sudo nsm-sensor-ps_restart to restart the sensors which would show me if it errored out.


With the error report (snortu.log) I could see the line number that was causing the issue and go and troubleshoot what was going on, it's nice that it's pretty informative of what the issue is with the line in reference to being ingested by Snort.

After all of this, from my understanding, it's now up to the Analyst to create the rules-based on the variables created, or I guess I could try and create a few rules based on the new variables?   Would you set HOME_NET=$Custom Variables (all of them), or just say the CIDR for your network?  

Index or Lookup Emerging Threats or AlienVault OTX

Currently I have my Emerging Threats being run through Suricata, and the OTX being run through Zeek on my SecurityOnion which then feeds to my Splunk instance.  I seem to have already broken my Kibana (will have to research that next - side panels run, but its all white space where the actual data should be). 

After reading a few articles: 
Malware Analysis
IDS alert challenge
Splunk Enterprise Security
IDS rules for PulledPork

Now I know that SecurityOnion uses pulledpork currently for its rule management, but I believe in future versions it will be moving to Suricata-update (well at least for Suricata).  But that does not matter currently. 

Emerging Threats updates a file called downloaded.rules, and OTX created a file called otx.dat, these both hold the rules which can be either parsed into an index or TSV/CSV out into a lookup table. 

Currently, I am trying to decide which way would be the most beneficial to most me, and other users of my system. 

I also think there is at least another file that goes with the Snort VRT which goes into further details based on the SID and is called the opensource.gz  For Emerging Threats it is called SID-Descriptions-ETOpen.json.gz which I think provides the same information for that rule set.

I am leaning towards putting the rules into an index, but I could be swayed either way, or to not even try this, but I think this has potential for analysts who try and hunt, to be able to look back at what signatures are hit on, and not have to Google every one of them.