Pfblockerng suddenly starts associating lists to rules incorrectly

bbrendon

Okay, so I'm guessing that the rule has to be enabled for these commands to work…

I set badIPs alias to deny both.
Then clicked force update
then clicked force cron
the click force reload

The 199.67 grep yields no results.
The 199 grep yields lots of results http://pastebin.com/gEgj3gi8

Using the command below, I don't see any subnets that would cause the deny, though I just looked manually. I don't know of a program to do it.

 grep "^199\." /var/db/pfblockerng/deny/* | grep '/[0-9]' | awk -F":" '{print $2}'|sort

and the output… http://pastebin.com/26L7Ugkz

BBcan177

I don't see anything either that would trigger an alert to that IP… Try to run the same commands in this folder?

/var/db/aliastables/*

These are the aliastable files that pfSense uses to block with.

BTW:

Force Update: will download any Lists that have not been downloaded.
Force Cron: will download any list that is within the "Frequency" setting to be downloaded or any list that has not been previously downloaded.
Force Reload: Reloads the originally downloaded file and if not found downloads a new copy of the list.

So you don't need to hit all of those buttons :)

If you browse to 199.67.137.5 or 199.47.217.34 or 199.67.137.5 do you get any new blocked alerts?

bbrendon

: grep "^199.67." /var/db/aliastables/*
/var/db/aliastables/pfB_goodCountries.txt:199.67.0.0/17
/var/db/aliastables/pfB_goodCountries.txt:199.67.128.0/18
/var/db/aliastables/pfB_goodCountries.txt:199.67.192.0/21
/var/db/aliastables/pfB_goodCountries.txt:199.67.200.0/23
/var/db/aliastables/pfB_goodCountries.txt:199.67.202.0/24
/var/db/aliastables/pfB_goodCountries.txt:199.67.204.0/22
/var/db/aliastables/pfB_goodCountries.txt:199.67.208.0/20
/var/db/aliastables/pfB_goodCountries.txt:199.67.224.0/19

: grep "^199." /var/db/aliastables/* | sort
http://pastebin.com/k80XxSk1

Okay, now if I goto the website that I couldn't before its coming up as IP 192.193.103.145.
That shows its blocked by badIP-sigma_1.

199.67.137.5 is blocked by badIP-countryUS
199.47.217.34 is blocked by badIP-countryUS
199.67.137.5 is blocked by badIP-countryUS (you asked the same one twice)

I wonder if the problem is that the IP is in the sigma list but there is a bug in the log reporting?

bbrendon

@bbrendon:

I wonder if the problem is that the IP is in the sigma list but there is a bug in the log reporting?

Guess not. I could only find: 199.67.128.0/18 pfB_goodCountries.txt
…which references to the 199.67.137.5

I wonder if there is an auto-update that was installed that broke something. This is super bizzare.

I also rummaged through the syslog server for anything reported from the FW recently... I didn't find anything interesting.

BBcan177

Did you change the "goodCountries" alias to "Alias Permit"? Are you sure that you set the firewall rules for this to "Permit"? Re-check your firewall rules including the Floating tab? I don't expect there to be any issue with how pfSense or pfBNG is handling the reporting. If you are still having issues, post more screenshots of what your doing? Its only going to block on the rules that you have enabled as "Block/Reject" and only on the IPs that are listed in those aliastables.

I also suggest to disable all Sigma lists and follow that with a "Force Reload".

bbrendon

It appears removing sigma is fixing it (or a workaround, depending on the interpretation. heh)

If I disable BadIP auto-rule in the firewall rules area (WAN/LAN), then things work correctly. There must be a bug somewhere in the reporting though (or elsewhere), because it says a different alias (goodCountries) is the cause of the block. If I enable/disable that one, there is no change in the blocking, so its obviously mistaken.

The only other thing I can think of is the rule goodCountries rule… it says "if NOT goodCountries", then block. Maybe the "if not" is somehow exposing a bug? goodCountries is an "alias native" type in pfblockerng.

bbrendon

I'm still baffled. I searched for 199.67.137.5 in the sigma lists very thoroughly and I guarantee you its not in there. Maybe the alias has too many lists and its too big causing some kind of problem?

Please tell me I'm crazy or there is a bug somewhere. I need closure :)

These are this lists, and Sigma isn't at fault here.

sigma_1
https://blocklist.sigmaprojects.org/api.cfc?method=getlist&lists=webexploit,drop,spyware,pedophiles

sigma_atma
https://blocklist.sigmaprojects.org/api.cfc?method=getlist&lists=atma

sigma_antiInfr
https://blocklist.sigmaprojects.org/api.cfc?method=getlist&lists=anti-infringement

RonpfS

I don't know why you remove the blocklist's URL in the picture…
But looking at https://blocklist.sigmaprojects.org/, it seems these lists are generated by http://list.iblocklist.com, so why not use the iblocklist directly?

I downloaded the atma list, and I got a CRC error in 7-zip when I extracted it.
As you mention you use "Alias Native", this maybe be part of your problem.

Take a look at the files in /var/db/pfblockerng/* to debug what is happening with these tables.

bbrendon

Is the crc error maybe causing the problem? I couldn't uncompres one of the files on Linux and winrar didn't report a problem. Seemed odd but I was hunting for IPs.

What am I looking for in the alias native list? That one appears to be working fine.

BBcan177

bbrendon,

Just like Ronpfs has said, it makes no sense to use Sigma Lists. I even stated that several times in this thread… See the following thread from February 10, 2015:
https://forum.pfsense.org/index.php?topic=86212.msg488934#msg488934

Not to mention that their website code hasn't been updated in over 2 years:
https://github.com/sigmaprojects/cf-blocklist

From this link you posted earlier:
https://blocklist.sigmaprojects.org/api.cfc?method=getlist&lists=webexploit,drop,spyware,pedophiles

With a gunzip command it fails with the following error: gunzip: invalid compressed data–length error

There seems to be some issue with how Sigma Lists is compiling the four selected lists. If you drop any one of those lists from the URL, it doesn't seem to corrupt the file.

pfBlockerNG uses PHP gzopen/gzgets commands to extract this file and doesn't seem to show any errors when extracting this file and continues to processes the file. I assume that when Sigma Lists is compiling the four lists that you selected (webexploit,drop,spyware,pedophiles) that Sigma is stripping some data from a line between one of those sigma lists.

I went thru the file and found this line:

222.161.212.114/3 (Start IP: 192.0.0.0 End IP: 223.255.255.255).

So i would assume that it should be a /32 mask instead of a /3. So with this address in the blocklist, you will now understand that it would block 199.67.137.5 and 192.193.103.145 as its within the blocked range above. Its actually going to block anything from 192.0.0.0 to 223.255.255.255.

I will look for a better solution to check gz files, probably just a (gunzip -t) command before attempting to extract the file so that it just reports a download failure instead of extracting a bad file.

The other issue that you have is that you put the Country file in the "Alias Native" format instead of "Alias Permit" format.

Hope this resolves this once any for all…. :) So please change the Alias format and Remove all reference to Sigma lists....

bbrendon

In this case I wasn't concerned about the sigma list because I thought you meant by being unreliable it generated false positives, not corruption. We proved it wasn't the IPs in the list that were the problem, so I dismissed sigmalist as the problem. I didn't expect corruption to join the party. I guess it's good you discovered it because this could potentially happen with any other list, not just sigma.

That was very good sleuthing! When I extracted the file on windows the smallest network in the list was a /10.

Can I add a bug/feature report somewhere to add corruption checking on compressed lists?

The country file is in the alias native so I can customize the order. see image i sent you. I''m assuming this is okay.

EDIT: What about the sigma block showing up as a goodCountries alias in the log? Is this resolved because of the corruption or is this caused because of the way I'm using aliases? (or is there a 3rd option?)

EDIT2: I couldn't stand that /3 got by me so I re-added them to pfSense and you're right. (should I be surprised I got a different result on windows?) . Wish I sorted by network size to begin with!

EDIT3: Dug in some more to see whats up with the Alerts tab. I'm not sure how this works but based on how slow the page loads, I'm guessing that the block list information isn't stored in a logfile but instead the blocked IP is matched to a list dynamically so depending on how that works, I'm guessing a corrupt list could cause the log to malfunction. It seems to be working fine as of now. I looked through a few pages and looks like I would expect.
https://s3.amazonaws.com/uploads.hipchat.com/9809/24877/2tOJuorc3rqUbcv/upload.png