PfBlockerNG list alerts are logged under the incorrect rule\alias
-
The following is being observed on v2.4.1-amd64 and 2.4.2-amd64.
My pfBlockerNG setup has two IPv4 aliases - one for production lists and the other for test lists. The prodAlias has several lists while the testAlias currently has only one list - "alien".
The test procedure is as follows: (A) prodAlias = ENABLED, testAlias = DISABLED; alerts logged properly; (B) prodAlias = ENABLED, testAlias = ENABLED; alerts logged to incorrect alias; (C) go back to prodAlias = ENABLED, testAlias = DISABLED; alerts go back to being logged properly.
Also, there were several pre-existing alerts that, prior to enabling the testAlias, were all logged properly as belonging to the prodAlias. After enabling the testAlias, all of the pre-existing alerts were magically changed to as belonging to the testAlias. Then if I go back and disable the testAlias, the pre-existing alerts go back to as belonging to the prodAlias.
I have triple-checked that the "alien" list is not in the prodAlias. I have also scoured the UI to find any setting that indicates a knob for this behavior - did not find anything.
What is even stranger is that both aliases do show hits in the pfBlockerNG widget and when I click on the "Packets" link in the widget, I do get some hits for the "alien" list but using the proper alias.
Really strange behavior here…
I presume this is a defect? Has anyone else seen or heard of this?
-
Hi,
The Alerts tab takes its data from the pfSense Firewall log. The Firewall log doesn't contain any additional data that is specific to pfBlockerNG. So each time you reload the Alerts Tab, it searches the /deny/ and /native/ folders for the list that contains the IP. If you add/remove Lists, then it will show what List the IP is in currently, and not exactly the IP that caused the original blocked event. Also ensure that Deduplication is enabled, or the query results can be stange on finding an exact match for the events.
That said, the new upcoming version has an improved logging functionality that will collect all of the details that caused the event and store that in a new log format. Then when you review the events in the Alerts tab it will show the event details as they occured at the time the event took place. It will also show if the IP/Domain is not listed any longer, and if the IP/Domain is now in a different List then from the logged event.
Hope that makes sense …
-
Ahhh…ok...so at present, the Alerts tab doesn't have actual logged IP <–> list data - it does a xref lookup for the IP in a given set of lists and first hit - BAM - that's the one it shows. Yeah, that gets kinda dicey when trying to understand what's really going on especially when these lists contain a bunch of dups.
Sounds like this is being resolved though int he next version where, if I understand you correctly, the actual hit data will be what's logged and therefore, what is present to the user…is that correct?
-
When Deduplication is enabled you will have better results, even with the upcoming release. Plus I don't really see a reason not to enable Deduplication…. There are some use cases for an "Alias Native" which doesn't use deduplication.
So with the existing Released version, if a Blocked IP Event occured, the Alerts Tab will show the List that contains the IP now... So even tho it was blocked by a different List name, the IP was still blocked.... If this IP was not listed any longer, then it will show as "Unknown"...
But yes, it will be improved upon in the next version...
-
When Deduplication is enabled you will have better results, even with the upcoming release. Plus I don't really see a reason not to enable Deduplication…. There are some use cases for an "Alias Native" which doesn't use deduplication.
So first, De-dup was NOT enabled - I chg'd this and now have much better results - THANK YOU. Next, you read my mind - as when to not use de-dup. You mentioned "Alias Native" which I can research here but please also feel free to discuss that or other situations where de-dup would\should not be used.
Thanks again…really appreciate the help...OH, by the way - pfB really does kick ass...killer package...one of the reasons I choose pfSense...there are many reasons why but pfB is definitely one of the tops...
-
So first, De-dup was NOT enabled - I chg'd this and now have much better results - THANK YOU. Next, you read my mind - as when to not use de-dup. You mentioned "Alias Native" which I can research here but please also feel free to discuss that or other situations where de-dup would\should not be used.
Thanks again…really appreciate the help...OH, by the way - pfB really does kick ass...killer package...one of the reasons I choose pfSense...there are many reasons why but pfB is definitely one of the tops...
You could also use "Alias Deny" which will use deduplication….
Sometime you might add a Feed to block an ASN for a particular segment of the LAN, so using Alias Native will create its own isolated aliastable without deduplication taking effect and affecting the IPs in the other blocklists... Just one example...
