Snort upgrade and now only alertintg not blocking?
-
Hi,
EDIT: After changing to inline mode I did a speed-test and I was losing over 540Mbps using inline. I verified this by doing a speed-test from different PC's in my house all of them were getting between 90-94Mbps. My ISP delivered speed is 150Mbps. I reset to legacy all interfaces and I was back up to 150Mbps. Why such a speed loss using inline; I was under the impression it was faster not slower.
Eitherway, all the rules are still be set to alert and not block? Not sure what to do to fix this?
I updated to the new snort version. After the update literally all my rules have change to alert only.
I have WAN interface set to legacy / blocking but all rules are set to alert only
I have changed LAN/LAN2 to inline and enabled a connectivity policy and selected the checkbox to alert or drop based on snort subscriber rules meta data - I subscribe to snort rules.
At this point I am not sure if snort is blocking anything at all, there seems to be IP's listed in the blocked tab - assuming this means at least these IP's are being blocked, but still on the alerts tab all the alerts have the "alert" symbol next to them and not the block symbol. This is quite different than before the upgrade when on the alerts tab the alerts all have a block symbol.
I either have something configured incorrectly or snort is broken...not sure which it is or even where to start finding out?
Anyone can help me with this?
-
Do entries appear in the snort2c table?
-
@1OF1000Quadrillion said in Snort upgrade and now only alertintg not blocking?:
Hi,
EDIT: After changing to inline mode I did a speed-test and I was losing over 540Mbps using inline. I verified this by doing a speed-test from different PC's in my house all of them were getting between 90-94Mbps. My ISP delivered speed is 150Mbps. I reset to legacy all interfaces and I was back up to 150Mbps. Why such a speed loss using inline; I was under the impression it was faster not slower.
The above comment is very confusing. Have you gone back and read what you actually posted? You say you lost 540 Mbps of speed with Inline Mode, but then you go on later to say that your ISP delivered speed is 150 Mbps. So how can you lose 540 out of a total of 150?
Inline mode is not necessarily faster. It totally depends on the hardware you have and the number of enabled rules. The advantage of Inline IPS Mode is no leakage of packets and the ability to have more granular control by setting some rules to ALERT and select others to DROP.
Eitherway, all the rules are still be set to alert and not block? Not sure what to do to fix this?
I updated to the new snort version. After the update literally all my rules have change to alert only.
I have WAN interface set to legacy / blocking but all rules are set to alert only
I have changed LAN/LAN2 to inline and enabled a connectivity policy and selected the checkbox to alert or drop based on snort subscriber rules meta data - I subscribe to snort rules.
At this point I am not sure if snort is blocking anything at all, there seems to be IP's listed in the blocked tab - assuming this means at least these IP's are being blocked, but still on the alerts tab all the alerts have the "alert" symbol next to them and not the block symbol. This is quite different than before the upgrade when on the alerts tab the alerts all have a block symbol.
I either have something configured incorrectly or snort is broken...not sure which it is or even where to start finding out?
Anyone can help me with this?
So in light of the "edit" you put at the top of your original post, are the above changes to your WAN and LAN/LAN2 now moot and you are using Legacy Mode everywhere?
The mode an interface is running in determines how rule actions are shown. With Legacy Mode there is no mechanism for distinguishing between DROP and ALERT, so all rule actions show as ALERT. With Legacy Mode, every alert is treated the same as a drop (meaning it results in blocked traffic). When running in Legacy Mode, all blocked hosts will be shown on the BLOCKED tab. But with Inline IPS Mode, nothing will be shown on the BLOCKED tab for that interface. Instead, dropped traffic (or blocked if you prefer) is shown with red text on the ALERTS tab.
-
I bet that is 54Mbps
-
I wonder if the test was also done over wifi.
-
The only change in this new Snort package version was an addition by one of the pfSense developer team members of a test for netmap compatible interfaces before saving interface IPS mode changes. So the new package will not let you save "Inline IPS Mode" operation for interfaces whose physical NIC is not currently supported for netmap operation in the version of FreeBSD on the firewall. This list of compatible NICs is different for pfSense-2.4.5 and pfSense-2.5 due to the change in the underlying FreeBSD operating system for the two pfSense versions.
That is the ONLY change in the new package. And the only way to trigger the new code is to go to the INTERFACE SETTINGS tab for a configured Snort interface and save a change. During the save operation, the physical NIC for the interface is checked against a list of netmap-compatible interfaces. If the NIC is not in the list, an error message is printed at the top of the page when saving.
Here is a link to the actual commit on Github: https://github.com/pfsense/FreeBSD-ports/commit/8899953c264fd8e3b7ab3cd33954240c43c9cd02.
-
@bmeeks said in Snort upgrade and now only alertintg not blocking?:
The only change in this new Snort package version was an addition by one of the pfSense developer team members of a test for netmap compatible interfaces before saving interface IPS mode changes. So the new package will not let you save "Inline IPS Mode" operation for interfaces whose physical NIC is not currently supported for netmap operation in the version of FreeBSD on the firewall. This list of compatible NICs is different for pfSense-2.4.5 and pfSense-2.5 due to the change in the underlying FreeBSD operating system for the two pfSense versions.
That is the ONLY change in the new package. And the only way to trigger the new code is to go to the INTERFACE SETTINGS tab for a configured Snort interface and save a change. During the save operation, the physical NIC for the interface is checked against a list of netmap-compatible interfaces. If the NIC is not in the list, an error message is printed at the top of the page when saving.
Here is a link to the actual commit on Github: https://github.com/pfsense/FreeBSD-ports/commit/8899953c264fd8e3b7ab3cd33954240c43c9cd02.
Thank you, @bmeeks. Shouldn't LAGG interfaces also be added to the list of supported interfaces?
-
@Paint said in Snort upgrade and now only alertintg not blocking?:
Thank you, @bmeeks. Shouldn't LAGG interfaces also be added to the list of supported interfaces?
No, per my understanding there is no in-kernel support for LAGG and the netmap device. LAGG uses its own type of psudeo-driver that currently has no support for netmap operation (at least that is my understanding).
-
Edit: I have 3 RE nics and 2 more to put in if I have a need
Hey Everyone,
Sorry had work, to busy at work to monitor here.
I didn't mean to put that huge font..my bad, not sure how I did it?
Eitherway, I didn't want to generate a big hubba loo either. So, this is what I did. I saw there was an update for snort. So I did that.After receiving the "all successful" message from the upgrade I made sure all the interfaces had snort started. I have mostly server blocking stuff on WAN, and everything else on LAN/LAN2. I had turned of the set policy (connectivity, balanced, etc and was just enabling rules manually). Anyhoo, I then checked the alerts and noticed the yellow triangle with the exclamation mark next to all the alerts whereas before the upgrade there was always a big red x.
I thought it was because of changes to legacy vs inline sniffing / blocking so I tried to manually change a rule to block instead of alert. Although it seemed to work, the big yellow triangle remained.
I looked in the block list and there were entries.
I cleared that list and surfed for 10 minutes or so, then looked and again there were entries in the block list. So, stuff is/was being blocked.
I just now checked again, there is stuff in the block list. But literally all the alerts have the little yellow triangle as it is not being blocked, just alerted.
Now, in an attempt to resolve this, I DID enable the blocking policy and selected the connectivity option just because I had to leave for work and didn't want the three people working from home to be mysteriously blocked from a work site.
When I did that I also tried the inline mode - just to see what the difference wad between it and legacy, and apparently, the difference on my PC is about 50Mbps less for inline.
At this point I may try the balanced option and see if anyone starts whining:-)
BUT I still do not know why an upgrade would radically change my settings like that. I swear to god it was blocking literally every alert generated was blocked, now it is just the reverse every rule is alerted...
-
I just did a full restore from just before I did the upgrade. Everything restored beautifully, except snort.
Maybe something was borked about snort anyways, I was still getting S5 Session Exceeded errors when I did the upgrade, silly me, I had just woken up and saw upgrade available, button pushing happy crappy day:-).
I think this happened last time I restored from backup also..I had to clear the locks, that didn't work, so I fund something on the web that allowed for a manual clearing of the locks and reinstall of snort...sigh
-
ps -p PID did not display a package owner/process that had pkg locked - or at least "killall whatIthoughtwaspackageowner"returned an error
so I did kill PID and then I was able to reinstall snort
some long drawn out steps found online to do this, wonder if I got lucky doing kill PID and having it work?
Anyways, all is back to normal and snort is blocking again. The yellow alert is still there, but I have legacy mode and block offenders checked so all being blocked now..I wasn't sure if I had change to inline blocking, the restore from backup showed me I had not. Hopefully the S5 issue will go away also...
Thanks all.