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?
No comments:
Post a Comment