Pfblocker blocks 8.8.8.8
-
@bolvar , this happens when cron source updated their block ip addresses lists. What you can do to unblocked it, press [+] button next to 8.8.8.8.
-
@AKEGEC said in Pfblocker blocks 8.8.8.8:
press [+] button next to 8.8.8.8
That is not really a good solution.. And also doing so you would also need to make sure its above your pfblocker rule.
The correct solution is to remove it from pfblocker block list. Not sure what list would block one of the most popular dns IPs on the planet? That makes no sense.
Until that list owner fixes their list, which I would assume would be soon - after the massive amounts of complaints prob getting.. Would be to whitelist it in pfblocker.
If your going to use an easy rule to allow it, you will need to make sure its above any automatic rules you have setup in pfblocker adding which default to being on the very top of the rules. So evaluated first.
-
Hi,
It's blocked by this list:
hxxps://isc.sans.edu/api/sources/attacks/1000/30?textYou will found it under Firewall ---> pfBlockerNG ---> IP ---> IPv4
-
that is a horrible list to use... That is anyone reporting anything up.. Its just people uploading their firewall logs..
-
Not long ago 1.1.1.1 was blocked by PRI1, so I couldn't use it for outgoing blocking anymore.
@CiscoX thanks for claryfing it, so I could just disable this one feed.
@BBcan177 It really shouldn't be part of PRI1 anymore.
-
There is a thread in the correct section. ;-)
https://forum.netgate.com/topic/157037/isc_1000_30-added-google-dns-8-8-8-8-Rico
-
@johnpoz indeed, I guess that list needs demoting from pri1, which is supposed to be the safest set of lists. :)
-
@chrcoluk said in Pfblocker blocks 8.8.8.8:
which is supposed to be the safest set of lists. :)
Safe in what sense ;) Safe that sense that you would block possible bad IPs.. You could see pulling in a list of every known IP that has been reported as "bad" could be safe.
Or safe in the sense that it won't have false entries ;) If that is how you want to use the word, then no including every tom dick and harry IP that anyone reports is bad, is prob not a good idea ;)
That is not really a block list provided by isc, that is just a feed of IPs gotten through their API.. Just the top 1000 IPs reported? There is no validation of said IPs.. Just what has been reported.. That is asking for problems.. Only lists that are maintained and validated in some way should be used to be honest.. Even when they are wrong entries can be made.. Using some automated list of IPs that have been reported is going to be full of false entries.
-
Safe from false entries of course, the list itself even says it's not a block list, so not sure what it is doing under the pri1 section of pfblockerng.
-
Is it listed there.. I only see these under the ISC pri1 list
I don't see 8.8.8.8 in any of those..
What exact default list is it under? I don't use pfblocker to do any sort of auto rules.. What specific "default" that pfblocker list uses.. Happy to look and see.. There have been a few of these posts.. And not exactly which is the feed that contains this.. Its not under the ISC pr1 feed.
Should a list of top 1000 reported IPs be under what is termed a "safe" feed to use (pr1) - I would agree that would be a bad idea. But pfblocker doesn't really have control over what the maintainer of some list might add to its feeds.. It can only lists feeds you can use if you want.
And there is a big warning where you pick which lists you want to use
"Disclaimer: Use of the Feed(s) below are at your own risk! " -
@johnpoz It is or was the already mentioned one and pri1 shouldn't include this.
-
Which pri1 includes this?
I do not see any list called ISC_1000_30 on my pri1 lists?
-
-
I am curious if once the feed is removed from the possible PR1 feeds, does it auto remove it from your specific selections, or will users have to make sure they remove it from their selection feeds?
I would assume the latter
-
@johnpoz said in Pfblocker blocks 8.8.8.8:
I am curious if once the feed is removed from the possible PR1 feeds, does it auto remove it from your specific selections,
The answer to that is NO, since pfBlocker downloads/updates from the URL specified for the source website for that list.
or will users have to make sure they remove it from their selection feeds?
YES. since pfBlocker updates from the URL specified for the source website for that list.
-
@jdeloach @johnpoz True, just tested it myself. I installed a backup from yesterday, then enabled that list and made updates. After that I installed the update of pfBlocker, but it looked to me, that the "faulty" feed was already gone before that update... but sure not in my installation of pfBlocker, so I had to remove it manually.
-
John it is in internet storm centre, but my pfblockerng has an outstanding update so maybe thats why I still see it there, its good if it got moved off it.
-
yeah must of changed, because that is no longer the case..
Im running 2.2.5_36 of pfBlockerNG-devel
None of those should really have ever been any sort of feed you could use.. They clearly state they only provide 1 block list.
https://isc.sans.edu/xml.html
Why Should I Not Use the "Top 100" data as blocklist?Our primary purpose is to collect data for network security research. In order to fullfill this role, we collect data "as is" with little filtering. Filters are applied to the raw data for specific purposes, but we can not delete data from our raw database without compromissing the data integrity.
Our data does include false positives, and we will not remove them. It would make it harder to observe long term trends. If a report is a false positive or not depends to a large extend on the question being asked.
We offer one blocklist, and one blocklist only (https://isc.sans.edu /block.txt). Unlike for our other lists, we will remove IPs from this blocklist if asked to.
-
I think you should not upgraded your pfblockerng before you install the new pfsense version (like 2.5).
-
Hy
Im have not upgraded my pfsense, my pfblocker was not the latest, but now i have upgraded it, and the problem is still exist.2.2.5_36.
The problem still exist, if i unlock the ip, it works for the next cron update...I dont get it why the google dns block is now okay.
