Snort 2.9.4.1 pkg v.2.5.8

marcosasjr

@marcosasjr:

Thx Bill,

snort.conf atached.

marcosasjr:

I found a line-break problem in the file attached to your last post, but it was not in the section where you were getting the error. It's further down at line 130 in the {http_methods} section. There is a newline in the file you posted at the end of the parameter CCM_POST in that section. It should not be there. I don't know if that happened during file transfer and attaching to the forum post, or if the original file on your firewall has the same issue.

Have you tried these steps? This will force a rebuild of the snort.conf file on your setup.

1. From the Snort Interfaces tab, click the green icon to toggle Snort "off". The icon will turn into a red X.

2. Click the icon to edit the Snort interface and then click the Save button on the interface edit tab.

3. This will return you to the Snort Interfaces tab. Click the red X to start Snort. If successful, it will turn green in a few seconds.

4. If that doesn't work, try an uninstall and reinstall. Click the Global Settings tab and be sure the checkbox near the bottom of the page is checked so Snort will save settings upon a deinstall. Next, go to the Installed Packages tab (under the System…Packages menu) and click the X icon to completely remove Snort. When the uninstall finishes, go to the Available Packages tab and install it again fresh.

5. You can also have Snort locally verify the configuration file. Run this command sequence from a console prompt on the firewall. These are two separate commands with ENTER pressed after typing each one:
cd /usr/local/etc/snort/snort_61463_msk0
/usr/local/bin/snort -T -c ./snort.conf
Snort will read and validate the configuration file. It will report any error and the line number where the error was.

Report back and let me know if any of the above worked.

Bill

Hi Bill,

Thx for help,

I tried this steps and again now the step 4…

follows attached the archive "test snort.txt" from step 5 and snort.conf on "snort.txt".

[test snort.txt](/public/imported_attachments/1/test snort.txt)
snort.txt

bmeeks

@marcosasjr:

Hi Bill,

Thx for help,

I tried this steps and again now the step 4…

follows attached the archive "test snort.txt" from step 5 and snort.conf on "snort.txt".

I do not visually see anything wrong in the attached snort.conf file. This one is really puzzling. I will make a fresh 2.0.3 64-bit VM, import your file, and test with it to see if I can reproduce the problem. Give me a day for troubleshooting.

Thanks,
Bill

marcosasjr

@bmeeks:

@marcosasjr:

Hi Bill,

Thx for help,

I tried this steps and again now the step 4…

follows attached the archive "test snort.txt" from step 5 and snort.conf on "snort.txt".

I do not visually see anything wrong in the attached snort.conf file. This one is really puzzling. I will make a fresh 2.0.3 64-bit VM, import your file, and test with it to see if I can reproduce the problem. Give me a day for troubleshooting.

Thanks,
Bill

Hi Bill,
Thanks for great help,
I'll be watching the topic.

bmeeks

@marcosasjr:

Hi Bill,
Thanks for great help,
I'll be watching the topic.

marcosasjr:

I created a clean 2.0.3 64-bit install on a VMware Workstation virtual machine and imported the snort.conf file you sent. I did have to edit the file to change the interface names, but I changed nothing anywhere else in the file. It validated fine, and Snort started just fine on the VM. I even selected the rule categories you listed in a previous post, and everything worked.

By the way, are you aware that those rule categories you had selected are basically empty of rules? You can see what I mean by viewing them on the RULES tab. Select each one, and any rules present in the file will show up below. The Snort VRT folks have restructured the rules files a bit and many of the old names are now empty shells. A number of those you listed are empty shells. That's not your problem with Snort not starting, but just pointing out that with those selected you have basically zero protection from Snort. Much better to check the "Use IPS Policy" checkbox and choose either "Connectivity, Balanced or Security". I suggest "Connectivity" if you are just starting out with Snort.

Now back to the topic and your problem – at this point I really have no idea what is wrong on your end. The file you sent me was fine. As far I know, you are the only user to experience this problem. So that indicates to me it is something unique with your installation.

What language setup do you have on your box and what browser are you using? Try taking the exact file you sent me and copying it back to the firewall. Download it fresh from your post here, then copy it back to the firewall on top of the original and try to start Snort. Instead of trying to start from the GUI, execute this command at a console prompt to start Snort. This sequence will not rebuild the snort.conf file prior to starting. The GUI start will always rebuild the snort.conf from scratch.

Command to start Snort without rebuilding snort.conf file:

/usr/local/etc/rc.d/snort.sh start

As a last resort, you can clear the box for Snort to save settings and then remove Snort from the firewall. Reboot the firewall, then install Snort fresh again. You will have to reconfigure all the Snort settings, but maybe that will fix it.

Bill

Nukama

@bmeeks:

@Nukama:

Hey Bill,

thanks for this great package!

The alert tab in this version overlaps the IPv6 addresses over columns.

The fix for this is now posted. The Snort Package version number was not incremented, but you can pick up the fix by simply reinstalling the GUI components. Go to System…Packages and then the Installed Packages tab. Click the XML icon next to Snort to reinstall the GUI files. That should do it.

Bill

Thanks Bill,

this patch does introduce line breaks in alert tab.
Copy and pasting is problematic when a parser is the next step.
Good work for this fixed width limitation.

bmeeks

@Nukama:

Thanks Bill,

this patch does introduce line breaks in alert tab.
Copy and pasting is problematic when a parser is the next step.
Good work for this fixed width limitation.

Yeah, I knew copy and paste could be a problem given the inserted zero-width characters. It was the best option I could find. I never could find any tricks to tell the browser to break on something other than spaces or hyphens.

Bill

shinzo

I am noticing that if i disable a few rules in current events, and then click on apply. It Disables the interface but the pid is still running. I then click start on the interface and it just makes a new one pid on top of the old one.

fragged

~~I've recently changed from subscriber to paid Snort rules and have disabled the community rules download from update tab, but the rules tab of my interface shows this error:~~


The following input errors were detected:

    GPLv2_community.rules seems to be missing!!! Please verify rules files have been downloaded, then go to the Categories tab and save the rule set again.

~~The drop down list still shows the community rules, but it's obviously empty. Shouldn't the category have been removed when I no longer have the community rules downloaded at all?~~

Editing rules category tab and restarting Snort cleared the empty community rules selection from the rules tab and the error is no more.

bmeeks

@shinzo:

I am noticing that if i disable a few rules in current events, and then click on apply. It Disables the interface but the pid is still running. I then click start on the interface and it just makes a new one pid on top of the old one.

I just tested this scenario and could not reproduce the issue. When you are looking at the icons on the Snort Interfaces tab, remember that starting with this new 2.5.8 package they were swapped so that the green arrow means "Snort is running" and the red X means "Snort is stopped" on the interface. The tooltip text was updated to reflect this. If you hover over the icon for a few seconds the tooltip will appear and show the current state of Snort.

When you say "disabled", are you talking about the text displayed next to the icon? If so, wait several seconds on the page and then hit the refresh button for your browser. See if that changes the display.
Bill

shinzo

Yeah i am aware of the color change. When i say disabled, i mean that in the snort interface, it goes to red. I am not sure if the interface restarts itself after i click apply in the wan rules tab. I will retry what i was doing to see if i can reproduce the issue.

bmeeks

@shinzo:

Yeah i am aware of the color change. When i say disabled, i mean that in the snort interface, it goes to red. I am not sure if the interface restarts itself after i click apply in the wan rules tab. I will retry what i was doing to see if i can reproduce the issue.

No, it should not restart by itself. The APPLY button on the Rules tab simply rebuilds the enforcing rules file and rewrites the snort.conf file. I monitored the active processes during my test and never saw but one running Snort process.

That rule set is a bit large, and it takes several seconds for the process to complete. This can be even longer on a less capable piece of hardware. Make sure you wait until the browser "activity indicator" stops spinning. IE has a spinning icon in the Address Bar, and Firefox also has some kind of status icon but I forget what it is at the moment. Make sure any spinning status indicators or hourglass goes away before you navigate away from the Rules tab.

Bill

shinzo

@bmeeks:

@shinzo:

Yeah i am aware of the color change. When i say disabled, i mean that in the snort interface, it goes to red. I am not sure if the interface restarts itself after i click apply in the wan rules tab. I will retry what i was doing to see if i can reproduce the issue.

No, it should not restart by itself. The APPLY button on the Rules tab simply rebuilds the enforcing rules file and rewrites the snort.conf file. I monitored the active processes during my test and never saw but one running Snort process.

That rule set is a bit large, and it takes several seconds for the process to complete. This can be even longer on a less capable piece of hardware. Make sure you wait until the browser "activity indicator" stops spinning. IE has a spinning icon in the Address Bar, and Firefox also has some kind of status icon but I forget what it is at the moment. Make sure any spinning status indicators or hourglass goes away before you navigate away from the Rules tab.

Bill

I went back and couldn't reproduce it. I think what was happening was when i was trying out the Snort Community and vrt rules yesterday , some where along the line snort didn't restart properly. Since there seemed to be two instances of snort running. when ever i hit apply after removing some of the current_events rules. I would jump over and notice that in the interface window, it was red so i would click to start it again and would spawn another pid.

I will continue messing with it and let you know if anything happens, I also wanted to ask something about what i read the other day.
Would it be better to have 1 wan interface with the wan ip and lan address or separate them and have 1 wan and then 1 lan? and thanks again

bmeeks

@shinzo:

I also wanted to ask something about what i read the other day.
Would it be better to have 1 wan interface with the wan ip and lan address or separate them and have 1 wan and then 1 lan? and thanks again

If we are talking about a typical home network with NAT, then it depends on whether or not you want to identify specific hosts on the LAN side. Here's what I mean. When you have NAT, then Snort sees everything on the WAN in terms of your WAN IP address and then whatever Internet hosts are being contacted. Snort does not see the internal LAN private IPs. It will still block offending traffic by blocking the SRC (assuming you have that configured for the WAN interface). But the logs will show everything in the local network as having the WAN IP address.

So if you want to see your LAN private IP addresses in the logs and thus be able to identify which specific LAN host might contain the latest nasty online banking Trojan, then you would run an instance of Snort on your LAN interface. This is what I do. I have Snort on the WAN configured with some basic ET-CIARMY and ET-RBN rules, then run the Snort VRT IPS-Balanced policy on my LAN interface. I configured my LAN interface to block BOTH (source and destination). The auto-whitelisting feature that adds the LAN to the whitelist means my LAN IPs never get blocked, but if any LAN IP tries to "phone home" to a BOT C-n-C server on the web, then the DST would get blocked because of the BOTH setting. So I am protected either way (whether my LAN host initiates the conversation or the far-end host does). Plus, my logs now show me the internal LAN private IP of the infected or potentially infected host.

P.S. – while you can do it, it would be sort of pointless and a waste of resources to run a duplicate set of rules on both the WAN and LAN interfaces in a scenario like I described. I prefer the setup where known bad hosts are blocked right away at the perimeter (the WAN). I get this from those ET-CIARMY and RBN rules. Then my LAN side interface is the next layer of protection and contains the richer rule set.

Bill

shinzo

@bmeeks:

@shinzo:

I also wanted to ask something about what i read the other day.
Would it be better to have 1 wan interface with the wan ip and lan address or separate them and have 1 wan and then 1 lan? and thanks again

If we are talking about a typical home network with NAT, then it depends on whether or not you want to identify specific hosts on the LAN side. Here's what I mean. When you have NAT, then Snort sees everything on the WAN in terms of your WAN IP address and then whatever Internet hosts are being contacted. Snort does not see the internal LAN private IPs. It will still block offending traffic by blocking the SRC (assuming you have that configured for the WAN interface). But the logs will show everything in the local network as having the WAN IP address.

So if you want to see your LAN private IP addresses in the logs and thus be able to identify which specific LAN host might contain the latest nasty online banking Trojan, then you would run an instance of Snort on your LAN interface. This is what I do. I have Snort on the WAN configured with some basic ET-CIARMY and ET-RBN rules, then run the Snort VRT IPS-Balanced policy on my LAN interface. I configured my LAN interface to block BOTH (source and destination). The auto-whitelisting feature that adds the LAN to the whitelist means my LAN IPs never get blocked, but if any LAN IP tries to "phone home" to a BOT C-n-C server on the web, then the DST would get blocked because of the BOTH setting. So I am protected either way (whether my LAN host initiates the conversation or the far-end host does). Plus, my logs now show me the internal LAN private IP of the infected or potentially infected host.

P.S. – while you can do it, it would be sort of pointless and a waste of resources to run a duplicate set of rules on both the WAN and LAN interfaces in a scenario like I described. I prefer the setup where known bad hosts are blocked right away at the perimeter (the WAN). I get this from those ET-CIARMY and RBN rules. Then my LAN side interface is the next layer of protection and contains the richer rule set.

Bill

i haven't even considered a setup like that, thanks for your input

Supermule

Hi Bill.

Can you test a client IP header rule that triggers in this scenario?

The way NAT reflection works is that the packets go to the firewall, and are then sent from the firewall to the NAT target, changed to appear as if they came from the firewall, so that replies go back through the firewall.

There is no security issue there, unless you count the loss of the client IP from the perspective of the NAT target/server. The server sees the firewall itself as the "client", not the actual IP of the client.

bmeeks

@Supermule:

Hi Bill.

Can you test a client IP header rule that triggers in this scenario?

The way NAT reflection works is that the packets go to the firewall, and are then sent from the firewall to the NAT target, changed to appear as if they came from the firewall, so that replies go back through the firewall.

There is no security issue there, unless you count the loss of the client IP from the perspective of the NAT target/server. The server sees the firewall itself as the "client", not the actual IP of the client.

Supermule:

I'm not sure I understand what you are asking me to do. If in reference to my previous post, the point of that post to Shinzo was simply to show a mechanism to see the pre-NAT LAN IP addresses in the Snort logs. If you run Snort on just the WAN (and you are using NAT), then Snort logs all "local" traffic as originating from the WAN IP. Here is an example. Suppose host 192.168.0.1 on the LAN communicates with a BOT C-n-C server somewhere on the web. Snort will see and log that traffic, but what you will see in the ALERT log for the Source IP is your WAN IP and then the Destination IP of the BOT C-n-C server. So while you will know that you have an infected host on your LAN, you won't know from the Snort logs which one it is.

However, with my scheme (Snort on LAN), then you will see in the ALERT log the local pre-NAT LAN IP of the infected host (192.168.0.1 in my example) as well as the Destination IP of the C-n-C server. You can then tell which LAN host is the problem.

Bill

Supermule

I understand :)

AhnHEL

@bmeeks:

P.S. – while you can do it, it would be sort of pointless and a waste of resources to run a duplicate set of rules on both the WAN and LAN interfaces in a scenario like I described. I prefer the setup where known bad hosts are blocked right away at the perimeter (the WAN). I get this from those ET-CIARMY and RBN rules. Then my LAN side interface is the next layer of protection and contains the richer rule set.

Bill

Whats your recommendation then for this setup in regards to duplicate settings on the Preprocessors tab? Are they unnecessarily redundant?

masli

Thanks for the new snort interface.

Ok , my problem is…..

Base on my understanding with snort blocking capabilities

LAN setting - I can block both LAN@internal and External IP with selection of new whitelist setting which i have uncheck the "Add firewall Local Networks to the list (excluding WAN)." option. Block setting "both"

WAN setting - I can block external setting , wth default whitelist setting. Block setting "both"

Both LAN and WAN setting will have different categories selection base on my need and requirement.

For the above setting , I manage to

WAN Setting - block external IP
LAN Setting - block only external IP (supposely to block both internal@LAN ip and external IP)

When I view the whitelist IP with "view list" function , in the new whitelist setting, the local IP still there , sort nothing happened with the uncheck action I have done?

Bug? or I missed something?

4 am here, since yesterday morning, I will need to have some rest first. Really appreciate if any one can advice me the next action.

pareddefuego13

2.1-BETA1 (amd64)
built on Fri May 17 16:45:31 EDT 2013
FreeBSD 8.3-RELEASE-p8
Snort v2.9.4.1 pkg v. 2.5.8

Hello,

Ever since I enabled Snort on my LAN interface, my firewall logs have been flooded with the alerts on the attached screen shot. Is there any way to get rid of these alerts? I've been running snort just on the WAN interface for a few good months now and never had these alerts on the firewall logs before. I started to test Snort on the LAN interface a couple of days ago and noticed my firewall log was full of those alerts. I do have IPv6 disabled on the WAN and LAN interfaces. BTW, thanks for this package bmeeks you’ve done a great job with it.

Capture.PNG_thumb