pfBlockerNG-devel v3.0.0_15

BBcan177

@jwj
They are behind CloudFlare, so I can't say exactly what tools/mechanisms they use to rate-limit. But my guess, is that that you are hitting them too hard, and potentially rate-limiting the IP.

A Former User

@bbcan177 Yup, for sure. Having a short wait is not an issue for my application. This all started for me when I was asked to come up with a quick way to block some stuff (Twitter/Facebook) during school hours only. I wrote a little python script to grab the routed prefixes and do the block on a schedule (ubiquity edgerouter, not pfsense). Easy enough.

Then it kind of grew out of control. It's been a few years since I had done anything with python, I do real work in Rust and Julia, so I just kept adding stuff. Kinda fun. I'm more or less over it now, but python is fun.

pftdm007

@bbcan177 The ASN update frequency was already at 24hrs, I changed it to 1 week. Lets see if this will help!

For the other issue (unbound not restarting automatically), issue 11398 seems to indicate the install of pfblocker halts and never finishes (or I misread the ticket?) which is not my case. For me it seems that pfblockerNG is successfully installed, IP blocklists work but unbound doesnt restart automatically and need to be "jump started" manually... Not a big issue IMO since I do package updates "manually" and I always do a walk around to see if all the services are up & running.

10101000

Basic ASN update (using bgpview.io) is broken for me without a sleep (especially with more than a few). The frequency doesn't matter in this case, nor does changing my public IP. Failures result in the ip_placeholder addresses. Can I request that this be configurable in the GUI? It would also be nice if there was better alerting to failures. Thanks for your hard work @BBcan177

--- /usr/local/pkg/pfblockerng/pfblockerng.sh.2021-01-17        2021-01-07 15:09:37.000000000 -0700
+++ /usr/local/pkg/pfblockerng/pfblockerng.sh   2021-01-17 12:20:47.367047000 -0700
@@ -755,6 +755,7 @@
                        bgp_url="https://api.bgpview.io/asn/${asn}/prefixes"
                        "${pathcurl}" -s1 "${bgp_url}" | "${pathjq}" -r ".data.ipv${_bgp_type}_prefixes[].prefix" >> "${pfborig}${alias}.orig"
                fi
+                sleep 1
        done
 }

BBcan177

@10101000

Have been working on this, download the patched file:

curl -o /usr/local/pkg/pfblockerng/pfblockerng.sh "https://gist.githubusercontent.com/BBcan177/3aabea5edf7b40554d93085bff380b6f/raw"

A Former User

As best I can tell the rate-limiting is just how it is:

        try:
            # BGPView rate-limits, try 5 times then give up
            re_try = 0
            while re_try < 5:
                response = ASN.manager.request(
                    "GET", "https://api.bgpview.io/asn/" + self.asn + "/prefixes")
                if response.status == 503:
                    re_try += 1
                    sleep(re_try / 2)
                else:
                    break
        except (HTTPError, PoolError):
            ASN.manager.clear()
            return

        if response.status != 200:
            ASN.manager.clear()
            return

Sleeps for 0.5 seconds on the first re-try, that appears to be sufficient.

10101000

@bbcan177 said in pfBlockerNG-devel v3.0.0_15:

@10101000

Have been working on this, download the patched file:
curl -o /usr/local/pkg/pfblockerng/pfblockerng.sh "https://gist.githubusercontent.com/BBcan177/3aabea5edf7b40554d93085bff380b6f/raw"

It works perfectly, thanks!

jvamos

I updated and rebooted and seem to get some packetloss. 2-5%
I removed the package and the problem was resolved.
Pinging the router was fine but sites visited at the WAN really have a degradation in performance.

Gertjan

@jvamos pfBlokcerNG uses very few CPU resources.

But, if loaded up with many feeds (thousands of IP's, thousands of hostnames) unbound can start stressing.
Which could impact overall system performances.
Equally distributes over all NICs, not only "WAN".

Packet loss normally means : invest in the WAN part of your network wiring => must often this means : call your ISP.

Xentrk

@bbcan177

Unable to filter Alerts by the Source IP field. After entering the Source IP, I select the "Apply Filter" button. Search results are not filtered and web page "spins". Have to press the "X" in the browser to make the web page usable.

Gertjan

@xentrk

Like this :

.....

and way below, a couple of thousand lines lower :

It took far less then a second to generate the 'page'.

Btw : My Samsung TV insist on calling 8.8.8.8, even when it's off (sleep mode). Still wonder what it has to tell to Google .....

Xentrk

@gertjan

Yes, the Source IP field. I let the page spin for four minutes. Eventually it timed out with a 504 Gateway Time-out error.

Gertjan

I think that this is the file used for all the IP blocked :

/var/unbound/var/log/pfblockerng/ip_block.log

What is the size of that file ?
How many "source IP" can you find in that file ?

I've 1777 times my "192.168.1.34".

DaddyGo

@xentrk

Hi,

Is this a coincidence or are you really using this?
pfSense 2.4.4_2

RonpfS

@xentrk If you have huge log files, the Report Alert Filter may timeout. Grep the log files from a Shell instead.