Quick Snort Setup Instructions for New Users
-
Quick question, I have snort setup and running, but I find if I restart or shutdown or restart snort, the interface does not start automatically.
But if I click on it, it will start and operate.
Is this normal or did I miss some setting .
Thanks in advance
David
-
Depending on RAM and the amount of Rules enabled, Snort can take some time to Stop and Start.
When you Re-Start Snort from the Services Menu, it will restart all of the Enabled Interfaces Automatically. You dont need to click the start Interface again.
If you make configuration changes to a Snort Interface, Click the Green Enabled Interface and it can take some time to shutdown. You can refresh the page or click the snort interfaces tab until it stops. Then click it once again to re-enable.
From an SSH shell, you can run the following command to see if you have any duplicate PIDS for Snort. There should only be one PID per Enabled Interface. or from the Diagnostics:Command Prompt.
pgrep snort
If there are duplicate PIDS, you could run pkill snort and then Restart the Snort Services.
-
A couple more general questions about the Snort package:
-
I verified that a rule is not on the Auto-Flowbit list. I then clicked on the red “x” to disable it, and restarted the PFSense. The rule is now showing up with a yellow “x” (Rule forced to a disabled state). But Snort still triggers and blocks on this rule. What am I doing wrong?
-
Upon pfSense reboot the list of blocked hosts is erased. Is this correct behavior or is something broken in my install? If this is correct, is there an option somewhere to make the blocked hosts list survive reboot?
Thank you.
-
-
@G.D.:
- I verified that a rule is not on the Auto-Flowbit list. I then clicked on the red “x” to disable it, and restarted the PFSense. The rule is now showing up with a yellow “x” (Rule forced to a disabled state). But Snort still triggers and blocks on this rule. What am I doing wrong?
Is the alert in the "Alerts" Tab or the "Blocked" Tab? If its only in the Blocked Tab, it could be from a different rule?
Which Rule, can you provide any more details?
- Upon pfSense reboot the list of blocked hosts is erased. Is this correct behavior or is something broken in my install? If this is correct, is there an option somewhere to make the blocked hosts list survive reboot?
In the "Global Settings" tab there are options to configure the Block table. I don't recall this being an issue from my boxes that I use. I only have "Keep Snort Settings After Deinstall" setting enabled in that section. I also set the remove Blocks to "Never"
Are you running pfSense on an embedded machine or Full Blown Hardware?
-
The rule is “1:2017015 ET POLICY DropBox User Content Access over SSL.” It shows up both on the Blocked tab, and on the Alerts tab with a yellow “x” next to it.
I am running the symmetric multiprocessing kernel on full-blown hardware.
Thank you.
Update: I noticed I could not trigger the rule anymore after a while. Now I re-enabled the rule, and restarted Snort, but even though the interfaces went green, I still cannot trigger the rule.
Is just that something rebuilds on the background and the enabled/disabled rules start functioning or not functioning after a while, even after interfaces show running?
-
@G.D.:
The rule is “1:2017015 ET POLICY DropBox User Content Access over SSL.” It shows up both on the Blocked tab, and on the Alerts tab with a yellow “x” next to it.
I am running the symmetric multiprocessing kernel on full-blown hardware.
Thank you.
Update: I noticed I could not trigger the rule anymore after a while. Now I re-enabled the rule, and restarted Snort, but even though the interfaces went green, I still cannot trigger the rule.
Is just that something rebuilds on the background and the enabled/disabled rules start functioning or not functioning after a while, even after interfaces show running?
Enabling or disabling rules should only take a few seconds (well, maybe as long as minute or so if you have a lot of rules, a lower horsepower CPU and not much RAM). When you click the icon on the ALERTS tab to disable a rule, the Snort process is sent a "reload configuration" command. This is a kind of warm restart where Snort reads all the rules again and updates its in-memory copy.
Bill
-
If you see this behaviour again, run a shell cmd
[ pgrep snort ]
and ensure that you only have pids for the number of enabled snort interfaces.
-
Enabling or disabling rules should only take a few seconds (well, maybe as long as minute or so if you have a lot of rules, a lower horsepower CPU and not much RAM). When you click the icon on the ALERTS tab to disable a rule, the Snort process is sent a "reload configuration" command. This is a kind of warm restart where Snort reads all the rules again and updates its in-memory copy.
I have re-enabled the rule on the WAN interface over 25 minutes ago, and the WAN interface is not alerting on it yet. The rule was always enabled all day today on the LAN interface, and it is alerting as it should.
The computer is powerful with plenty of memory free, but I have a lot of the rules enabled on the WAN interface (all of them, practically, both VRT and ET, except those disabled by default). It takes a couple of minutes for the WAN interface to go green after restart. LAN is almost instant, as I have just a few rules enabled there, for testing.
-
I restarted the PFSense box yesterday and frolicked with it for another hour or so, trying to trigger the re-enabled rule. It would not trigger.
I left the box to sit overnight, and in the morning the rule was working again.
So, it appears that, for rule disabling/enabling to take effect it takes a while for something somewhere to reset/reload/reshape.
-
@G.D.:
I restarted the PFSense box yesterday and frolicked with it for another hour or so, trying to trigger the re-enabled rule. It would not trigger.
I left the box to sit overnight, and in the morning the rule was working again.
So, it appears that, for rule disabling/enabling to take effect it takes a while for something somewhere to reset/reload/reshape.
Did you remember to remove the block that would have been inserted from the first rule firing (assuming you have block offenders enabled)? Where did you disable the rule? Was it on the RULES tab or using the little icon beside the SID on the ALERTS tab? If on the RULES tab, you must click the icon to disable, then click APPLY to save the changes and actually restart Snort. If you did not do that, then the change in the rule did not happen until maybe the nightly rules update (since that restarts Snort). Other than the scenario I just described, it should be almost immediate (as in 30 to 60 seconds).
Bill
-
Did you remember to remove the block that would have been inserted from the first rule firing (assuming you have block offenders enabled)? Where did you disable the rule? Was it on the RULES tab or using the little icon beside the SID on the ALERTS tab? If on the RULES tab, you must click the icon to disable, then click APPLY to save the changes and actually restart Snort. If you did not do that, then the change in the rule did not happen until maybe the nightly rules update (since that restarts Snort). Other than the scenario I just described, it should be almost immediate (as in 30 to 60 seconds).
I removed the block. All blocks are cleared on reboot anyway.
I flipped the rule using the little icon beside the SID on the ALERTS tab.
Thank you.
-
How can I update the blocked URL message?
That is instead of the generic squid error.
-
How can I update the blocked URL message?
That is instead of the generic squid error.
If you are asking about customizing Snort alert event messages, that can only be done by manually editing the specific rule text. I don't recommend it. First, it's something you would have to redo with each rule update (potentially daily), and it quite easy to insert typos that can stop Snort from starting.
Perhaps, I've misunderstood your question, though ???
Bill
-
How can I update the blocked URL message?
That is instead of the generic squid error.
If you are asking about customizing Snort alert event messages, that can only be done by manually editing the specific rule text. I don't recommend it. First, it's something you would have to redo with each rule update (potentially daily), and it quite easy to insert typos that can stop Snort from starting.
Perhaps, I've misunderstood your question, though ???
Bill
Thanks, Bill. That was a wonderful response. And I can see where i should've taken my time and phrased it better.
What i am asking is when a specific rule triggers an alert, blocks a host and then a user tried to access an http site with that host, they are presents with a generic error page. I was hoping to alter this to be a bit more descriptive on what is being blocked and why, this was I have an easy reference on what I need to change or fix and users are not freaking out that the whole of the internet is crashing down.
-
How can I update the blocked URL message?
That is instead of the generic squid error.
If you are asking about customizing Snort alert event messages, that can only be done by manually editing the specific rule text. I don't recommend it. First, it's something you would have to redo with each rule update (potentially daily), and it quite easy to insert typos that can stop Snort from starting.
Perhaps, I've misunderstood your question, though ???
Bill
Thanks, Bill. That was a wonderful response. And I can see where i should've taken my time and phrased it better.
What i am asking is when a specific rule triggers an alert, blocks a host and then a user tried to access an http site with that host, they are presents with a generic error page. I was hoping to alter this to be a bit more descriptive on what is being blocked and why, this was I have an easy reference on what I need to change or fix and users are not freaking out that the whole of the internet is crashing down.
Hmm…that would be quite a challenge because the IPS (Snort or Suricata) and the web proxy (Squid) don't know what the other did. By that I mean Squid only knows the web site did not load because the TCP traffic stopped or never got started. The IPS may well have blocked the traffic, but on the other hand, the IPS does not necessarily know which service on a given host initiated that outbound traffic. So there is no way to "connect the dots" and pop up a pinpoint error message.
If you were willing to dive into a lot of custom programming inside both packages (Snort and Squid), then you could perhaps pull this off. But it would not be a trivial task.
Bill
-
I am having problems getting the Home Net defined properly. The drop down box does not allow me to select anything other than default. I have a firewall alias for home net.
I have also gone into the ip lists in the services->snort section. I checked the snort.conf that is auto generated, and renamed it to force a new one and it still created $HOME_NET as default.
Thanks,
Christina
-
goto the Firewall:Alias Tab and create an Alias. Enter the IPs that you would like to have in the Home_Net.
See the text from the Home Net GUI Screen:
Note: Default Home Net adds only local networks, WAN IPs, Gateways, VPNs and VIPs.
Hint: Create an Alias to hold a list of friendly IPs that the firewall cannot see or to customize the default Home Net.Click on "View List" to see what it is currently being set to.
Usually this can be left as default.
-
I tried this myself and I can't seem to add an "Alias" either. Its the same issue in Suricata.
I'm sure Bill Meeks (Package Maintainer) will reply with a fix or a solution.
-
After further review, I think this is done by Design by the pfSense Devs. You should be able to create a new Pass List and at the bottom of the passlist, you can add an "Alias" there.
Hope this helps.
-
I am having problems getting the Home Net defined properly. The drop down box does not allow me to select anything other than default. I have a firewall alias for home net.
I have also gone into the ip lists in the services->snort section. I checked the snort.conf that is auto generated, and renamed it to force a new one and it still created $HOME_NET as default.
Thanks,
Christina
Because the default $HOME_NET is sufficient for probably 99% of the user base, there is no facility to directly add an Alias to $HOME_NET via the drop-down. Instead, if you have to customize $HOME_NET, go create a PASS LIST and give it a name that you can mentally link as HOME_NET. You can select whichever of the normal PASS LIST defaults you want (WAN IP, locally-attached networks, DNS servers, etc.). Then at the bottom of the page you can add an Alias. That Alias can be a group consisting of additional aliases if necessary. You have to create any of these Aliases first under Firewall…Aliases before you can use them in Snort or Suricata.
While the procedure outlined above is admittedly not intuitive, it does allow you to accomplish the goal if you have an advanced need. In a future release I will reconsider adding the option to directly add an existing alias to $HOME_NET.
Bill
