pfBlockerNG-devel v3.0.0_15

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.