DNSBLIP_v4 possible bug or am I not getting it?
-
OK this is probably a simple question and I wish we had a chat to get a quick answer but anyways..
So I have pfB installed without automatic rule creation (all feeds are NATIVE ALIAS, in both IP and DSBL). I was tired of my firewall rules jumping around and the separators moving all the time.
My issue is that an IP (namely a cloudflare reverse proxy) is being blocked by DNSBLIP_v4. My understanding is that this alias is created by DNSBL scraping all FQDN's in its feeds and all potential IP they may contain, and creating a huge IP table called "DNSBLIP_v4". If this is wrong please correct me but for now I'll assume this is correct....
This cloudflare IP is obviously resolved from one of the DNSBL feeds.
I tried adding this cloudflare IP to an IP feed used in a PASS firewall rule but somewhow, it is still blocked although the PASS rule is BEFORE the block rule using the DNSBLIP_v4 alias...
Here is the Alert entry in pfB showing the destination IP blocked by DNSBLIP_v4 but somehow also shown in my IP PASS alias:
Here is the firewall rules on the interface showing the pass rule BEFORE the DNSBLIP_v4 bock rule.. Somehow the IP still gets blocked as shown on the pfB alert report....
What am I not understanding here? Does it really matter where the IP is coming from as long as the FW rules are in the right order and the aliases contain the proper IP's shouldnt this work? -
@pftdm007 said in DNSBLIP_v4 possible bug or am I not getting it?:
Does it really matter where the IP is coming from
Must match the green blop :
Hiding RFC1918
And yes, the rule didn't match ....@pftdm007 said in DNSBLIP_v4 possible bug or am I not getting it?:
This cloudflare IP is obviously resolved from one of the DNSBL feeds.
If the IP is in an DNSBL, it will be resolved to 0.0.0.0 (perfect) or 10.10.10.1 (ok-ish).
Not to the real IP.
If the 172.64.80.1 IP is the one you don't want to be blocked, click on the black (green) "+" and whitelist it !?!
-
Sorry I censored the local IPs instinctively... However the traffic does come from the "green blop"! ;)
Moreover when I hover on the "pfB_pass_IP_MediaServices_v4", I can see the 172.64.80.1 IP being listed....
So I still dont get why this rule is not matched...
@Gertjan said in DNSBLIP_v4 possible bug or am I not getting it?:
If the IP is in an DNSBL, it will be resolved to 0.0.0.0 (perfect) or 10.10.10.1 (ok-ish).
Not to the real IP.OK so if IP's are found in the DNSBL lists (lets say the originator added IP's mixed with FQDN's, these IP will be resolved to 0.0.0.0 or 10.10.10.1... ??
@Gertjan said in DNSBLIP_v4 possible bug or am I not getting it?:
If the 172.64.80.1 IP is the one you don't want to be blocked, click on the black (green) "+" and whitelist it !?!
OK fair, but why is my pass rule not working? This is only happening with this DNSBLIP_v4 alias... none else of the other IP aliases from pfB are causing similar issues....
I tried reloading, updating, flushing tables and states, rebooting,......
The other wish I have is to centralize the management of my whitelists.... Per my other thread where I tried to use the same whitelists in Snort and pfB, things are slowly becoming messy and confusing in my opinion... Maintaining a simple alias in pfB and manually creating my riules should work, no?
Other than quickly whitelisting/suppressing an IP from pfB's functions, whats the point of this section if adding the IP to a IPv4 feed attached to a firewall PASS rule would work? (and it should!), especially with the so-called "Alias Native" option for manual rule creation...
Just to be fully transparent, my inquiry is a mixture of constructive criticism, and trying to better understand how all these moving parts are working together.
EDIT: "As a proof of concept" I just tried supressing the IP in pfB's alert tab, and it offered me the choice of suppression, or CREATING a pfB alias and adding the IP in there, but this is what I've already done manually in the "pass_IP_mediaServices_v4"! :)
-
@pftdm007 said in DNSBLIP_v4 possible bug or am I not getting it?:
OK so if IP's are found in the DNSBL lists (lets say the originator added IP's mixed with FQDN's, these IP will be resolved to 0.0.0.0 or 10.10.10.1... ??
If (oversight from me) you use DNSBL.
The list called pass_IP_MediaSer.... is an IP list and not as I was presuming a DNSBL list.@pftdm007 said in DNSBLIP_v4 possible bug or am I not getting it?:
I tried reloading, updating, flushing tables and states, rebooting,......
Use packet capturing ?
Like :
and hit start.
If some device on a LAN is going to "172.64.80.1" you'll know who it is. What port it used etc.
Be ware : it's a cloudflare IP. If it was a resolved IP, it can be 172.64.80.1 for 60 seconds, and something else the next moment.
And sorry, don't use snort here. 99 % (more ?) of all my traffic is TLS so snort can't do much more as looking at ports and IP address ...
-
@Gertjan said in DNSBLIP_v4 possible bug or am I not getting it?:
If (oversight from me) you use DNSBL.
The list called pass_IP_MediaSer.... is an IP list and not as I was presuming a DNSBL list.Both correct (I do use DNSBL, and yes pass_IP..... is a pure IP list)
For the packet capture, I tried it but I already know which machine is trying to connect to the CF rev proxy and this is intended!
15:38:39.451948 IP 192.168.150.70.33548 > 172.64.80.1.443: tcp 0 15:39:17.094802 IP 192.168.150.70.58504 > 172.64.80.1.443: tcp 0 15:39:18.107295 IP 192.168.150.70.58504 > 172.64.80.1.443: tcp 0 15:39:20.155528 IP 192.168.150.70.58504 > 172.64.80.1.443: tcp 0 15:39:24.187365 IP 192.168.150.70.58504 > 172.64.80.1.443: tcp 0 15:39:32.699993 IP 192.168.150.70.58504 > 172.64.80.1.443: tcp 0 15:39:49.083904 IP 192.168.150.70.58504 > 172.64.80.1.443: tcp 0 15:40:21.341109 IP 192.168.150.70.58504 > 172.64.80.1.443: tcp 0 15:40:57.207602 IP 192.168.150.70.60454 > 172.64.80.1.443: tcp 0 15:40:58.267427 IP 192.168.150.70.60454 > 172.64.80.1.443: tcp 0 15:41:00.315355 IP 192.168.150.70.60454 > 172.64.80.1.443: tcp 0 15:41:04.348331 IP 192.168.150.70.60454 > 172.64.80.1.443: tcp 0 15:41:12.541397 IP 192.168.150.70.60454 > 172.64.80.1.443: tcp 0Unless supressed in pfB's suppression section, there's curretly nothing that can be done to whitelist this IP..... This is very weird IMO. Firewall logs confirm DNSBLIP_v4 is blocking it and the pass rule is ignored. I will continue investigating....
-
On what interfaces (WAN LAN Floating etc) did you place what rules ?
