Alert Flooding
-
@jlw52761 ::1 is "localhost" and ::1010101 is presumably a typo or other error . That looks like a NAT rule. Do you have any packages installed? Otherwise, not sure what would be listening on the pfSense (::1) on that port.
-
@steveits I do have pfBlocker and Snort installed. Didn't think about those being a problem...
-
@jlw52761 Possibly pfBlocker is doing that for the DNSBL feature? We have generally not used that feature so I can't say.
You might try disabling and re-enabling that feature. Or if nothing else manually edit or remove the NAT rule by exporting/editing/importing the config file.
-
@steveits Well, looking at the NAT rules it's staring me right in the face
Now, how to remedy this issue...
-
@steveits said in Alert Flooding:
::1010101
Hmm, yeah that's..... all wrong!
What pfSense version are you running? What pfBlocker version?
How do you have it configured to generate those rules?
Steve
-
pfSense: CE 2.5.2
pfBlocker-NG: devel 3.1.0I have no idea what settings are generating that config. In pfBlocker for Port I do have 65437 and SSL port is 65438. "no AAAA" under Firewall > pfBlockerNG > DNSBL is unchecked, but it was checked earlier I believe.
Now 10.10.10.1 is my Virtual IP for DNSBL Web Server, so that kinda makes sense that it's NAT'ting to that.
I'm running a force update now to see if those rules go away after unchecking the no AAAA option.
-
Mmm, sure looks like it's interpreting IPv6 wrong there....
-
What are your settings here :
I have no NAT rules what so ever, probably because :
Just think about a it : most, if not any web traffic, is TLS these days. The good old day of 'http" is over.
You could place a test rule on you firewall, and see for yourself how much http (destination any, TCP and port 80) traffic goes out the the internet.
It's close to none.
Now, only this traffic can be redirected to the pfBlockerNG page that shows that the page visited was "blocked"
https traffic will not get redirected to the pfBlockerNG web server.
If you (your web browser) wants to visit "www.your-bank.com" and it gets back a site called "https://your-pfsense.tld/pfblocker/......." you browre well yell - refuse show anything except cryptic warnings.So, consider the "pfBlockerNG blocker page" a functionality to be removed entirely very soon. De activate it.
Me, you and every body else can't break "https".
Actually : nobody wants to break it, as the Internet will die if this happens. -
Hmm, the issue there seems to be the ruleset generated by the NAT rules. However I'm unsure why those NAT rules are present at all. The service listens on the VIPs directly anyway.
I haven't yet found the toggle in DNS-BL that creates those NAT rules so I can test... -
@stephenw10 Under the DNSBL configuration is the Permit Firewall Rules, which seems to be the trigger for wither the rules are created or not. Under the DNSBL Webserver Configuration, the IPv6 trigger lives, and I did disable that (unchecked it) and I no longer get that error message flooding my logs. Now while I don't have IPv6 specifically disabled in my network, nor do I have any 6to4 configuration setup, I basically am ignoring the existence of IPv6 at this time. So to me it does seem like this is a bug in the pfBlocker package in how it's writing to the rules file for the IPv6 config. The IPv6 rules do look very strange, but I always chalked that up to my lack of familiarity with IPv6.
-
@gertjan I'm not sure where you are going with this in relation to the original question to be honest.
I don't think that we are worried about decrypting the TLS traffic, just looking at what the DNS query is and if it matches something in the block list then send back the IP defined in the local web server config instead of the actual IP. There's no TLS decryption needed, and even TLS sends clear text DNS queries. Now I am blocking DoH (DNS over HTTPS) so that the DNBL engine doesn't get bypassed because DoH doesn't send what would be a standard DNS query, but an encrypted packet. -
Ah, found it. You actually have to set a 'Web Server Interface' other than localhost to create the port forwards.
The floating firewall rules created by 'Permit Firewall Rules' are OK.And after digging into it I find it's a known bug that's already fixed:
https://redmine.pfsense.org/issues/12330But just leaving the 'Webserver set as localhost avoids it.
Steve
-
@jlw52761 said in Alert Flooding:
I'm not sure where you are going with this in relation to the original question to be honest.
I explained (was trying to explain) why this won't work :
@jlw52761 said in Alert Flooding:
I don't think that we are worried about decrypting the TLS traffic, just looking at what the DNS query is and if it matches something in the block list then send back the IP defined in the local web server config instead of the actual IP. There's no TLS decryption needed, and even TLS sends clear text DNS queries.
Yes, the clear DNS requests (not DoH, as you can't decrypt it anyway) of a blocked domain name get blocked = replaced by 10.10.10.1
And No : the web browser was asking for, example, www.facebook.com (you blocked www.facebook.com) and your browser will not open the https::/10.10.10.1/.... instead to show the user that "www.facebook.com" has been blocked by the 'admin.You can not redirect a https site ! Your browser wants a cert that says the site is "www.facebook.com".
Worse : https::/10.10.10.1/.... will return a self signed cert, not accepted at all by your browser.Long story short : this works only for "http" sites :
.... and http sites don't exist any more.
Even shorter : don't use functionality. Just "Log and zero drop".
-
@gertjan I guess that is the "nuclear" option to the original issue, remove the underlying functionality that caused the log entries to begin with...
