PfBlockerNG DNSBL downloads fail mit cURL Error: 56
-
adaway.org/hosts.txt sometimes report 404 you just need to try later, the website is probably congested or under update
google translate
adaway.org/hosts.txt meldet manchmal 404, die Sie nur später ausprobieren müssen. Die Website ist wahrscheinlich überlastet oder wird aktualisiert -
@JeGr
Vielen Dank für die Antwort.Stimmt, ich sollte vielleicht vorher mal etwas über die Versionen sagen:
MaxMind_BD_Proxy_v4, Spamhaus_Drop_v4 und ISC_1000_30_v4 sind im Bereich Firewall -> pfBlockerNG -> Feeds als Pre-defined Alias/Group/Feeds eingetragen. Ob man sich da anmelden muß, kann ich aus der Beschreibung nicht erkennen. Möglicherweise habe ich hier noch einen zusätzlichen Fehler.
Im Wesentlichen ging es mir um die Einträge im Bereich Firewall -> pfBlockerNG -> DNSBL -> DNSBL Groups
Die nachfolgenden Sourcen trägt man ja manuell ein und die habe ich vorher überprüft und konnte sie im Browser auch ohne Probleme laden, beim Update über pfsense kommt es aber zu dem angegebenen cURL Fehler und der entsprechende Eintrag wird gelb markiert. Testweise habe ich adaway.org auch über die FW gepingt, was auch problemlos möglich war (siehe untere Grafik)
-
Ping sagt nichts über die Erreichbarkeit des Feeds aus. Ein 407 ist ein Credentials Fehler oder ein Server Fehler, bei dem der Webserver dir die Antwort verweigert! Er ist nicht überhaupt nicht erreichbar, sondern er sagt "DU nicht!" Daher die Frage ob du nur im Browser die Feed URL aufrufen kannst.
Sicher, dass dir die pfSense da irgendwas "gelb" markiert? Das sieht mir mehr nach deinem Browser aus. Ich kann da zigfach in die Liste reingehen, egal ob was fehlschlägt oder nicht, und bei mir wird da nichts markiert. Zumal auch nur die Header/Label Felder markiert sind - die ja überhaupt nichts aussagen.
Mich wundert das alles etwas, zumal ich jetzt mal spaßeshalber selbst die DNSBLs reingenommen habe und keinerlei Fehler bekomme. Ich denke daher eher, dass da ggf. deine IP geblockt wird oder ein Rate Limit im Spiel ist.
-
@JeGr
Die gelbe Markierung ist im pfblockerng beschrieben:
Das scheint auch zu stimmen, denn im Verzeichnis /var/db/pfblockerng/dnsbl sind die gelben Einträge mit der Endung .fail beschrieben.Per Browser kann ich die Seiten erreichen (siehe unten). Als Beispiel habe ich mal den zweiten Eintrag genommen, der bei mir als BBcan1 beschrieben ist:
https://gist.githubusercontent.com/BBcan177/4a8bf37c131be4803cb2/raw/d3cc8fb23c52701732a18c663777b26888468a9d/MS-2Trotzdem gibt die pfsense den Fehler cURL 56 raus.
Das Fehlerlog sagt dazu:
[ DNSBL_Feeds - Bbcan1 ] Download FAIL [ 04/11/20 13:00:59 ] Firewall and/or IDS (Legacy mode only) are not blocking download.Das Protokoll des Updates:
[ BBcan1 ] Downloading update [ 04/16/20 21:03:15 ] . cURL Error: 56 Received HTTP code 407 from proxy after CONNECT Retry in 5 seconds... . cURL Error: 56 Received HTTP code 407 from proxy after CONNECT Retry in 5 seconds... . cURL Error: 56 Received HTTP code 407 from proxy after CONNECT Retry in 5 seconds... .. unknown http status code | 0 [ DNSBL_Feeds_neu - BBcan1 ] Download FAIL [ 04/16/20 21:03:31 ] Firewall and/or IDS (Legacy mode only) are not blocking download.Der Webbrowser zeigt an, dass er die Seite laden kann:
-
Hallo,
hatte einmal ein ähnliches Problem, folgender Befehl brachte den Erfolg:
/usr/local/bin/curl -s -A "Mozilla/5.0" <URL>Sprich über Cron lädt curl die Liste runter und pfB lädt die von lokal.
-
@root32
Über die Konsole habe ich den Befehl ausführen können und die Webseite konnte auch aufgerufen werden. Das geht eigenartigerweise.
Mir ist allerdings nicht klar, wie ich pfblockerNG dazu bewegen kann den Inhalt auch zu lesen. Die Dateien in /var/db/pfblockerng/dnsbl haben ein leicht anderes Format. -
Ich lade die Datei mittels cron herunter und binde die lokale Datei in pfblockerNG ein.
Sieht bei mir so aus:
P.S. Ich vermute, dass die Website einen Bot-/DDoS-Schutz verwendet, der den User-Agent überprüft. Daher funktioniert es mit dem modifizierten User-Agent im curl
-
@root32
Vielen Dank, das funktioniert als Workaround!
Ich habe eine kleine Modifikation vorgenommen, falls das mal jemand anderes auch als Problem hat:/usr/local/bin/curl -s -A "Mozilla/5.0" <gewünschte URL> >/tmp/hosts.txt
Und sollte noch jemand eine Idee haben, warum pfblockerNG das nicht selber macht, freue ich mich über weitere Antworten.
-
Weil es nicht OK ist und pfBlocker sich sauber mit Curls Header zu erkennen gibt. Ich habe hier auch keinerlei Probleme die Listen abzurufen, daher schrieb ich schon, dass das entweder ein Blacklisting von dir oder ein Ratelimit ist. Wenn du bestimmte Listen zu häufig abrufst kannst du geblockt werden. Einfach aus Schutz um die Last normal zu halten.
Das ganze dann lokal hinzubasteln halte ich für einen cruden Hack, dann würde ich lieber hingehen und das im pfBlocker Unter-Forum nochmal posten, da du bspw auch BBCANs EIGENEN Feed auflistest als 407. DEN kann er wohl am besten selbst debuggen und wird wohl kaum seinen eigenen User-Agent Header abgeschaltet haben ;)
-
@JeGr
Ich habe jetzt mal testweise von täglicher Aktualisierung auf wöchentliche umgestellt, um ein Ratelisting auszuschließen. Falls es daran liegt, gebe ich später eine Rückmeldung.
Ein Blacklisting hätte ich spontan ausgeschlossen, weil alle (!) Listen davon betroffen sind und ich zumindest nicht bewußt oder manuell Blacklists eingetragen habe. Ich wäre auch davon ausgegangen, dass ich ein Blacklisting meinerseits ausschließen kann, wenn sich die Listen über die Konsole laden lassen. Oder liege ich mit dem Gedanken falsch? -
Nicht unbedingt falsch, nein. Es könnte aber auch ein rate-limiting für Prozesse sein (wie Curl) das man dann durch anderen User-Agent aushebelt. Hatte pfBlocker mit einer bestimmten Liste schon mal (weiß gerade nicht mehr welche), die Änderung auf anderen User-Agent hatte dann aber nur ein paar Wochen was gebracht, weil das dann ausgeweitet wurde (die sehen das in den Logs ja trotzdem!). Da aber BBCans eigene Liste mit in deiner Aufführung drin stand, würde ich da in seinem Unterforum nochmal gezielt nachhaken und das Debuggen, denn wie gesagt, es kann nichts allgemeingültiges sein, da mein Test-pfB die Listen bspw. problemlos abrufen konnte. Also ist da mutmaßlich irgendwas im Zusammenspiel am Danebengreifen :)
