Showing posts with label snort. Show all posts
Showing posts with label snort. Show all posts
Monday, April 11, 2022
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.
Labels:
hacking,
Kali,
Pentest,
pentesting,
rules,
SecurityOnion,
snort,
suricata,
udemy
Friday, October 18, 2019
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?
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?
Sunday, April 28, 2019
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.
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.
Labels:
ET,
kibana,
OTX,
pulledpork,
rules,
SecurityOnion,
snort,
Splunk,
suricata
Subscribe to:
Posts (Atom)