pfBlockerNG sperry eine IP der Shellycloud

[Fidibus]

Moin,
nach dem Update der pfsenseCE auf 2.9.0 fällt mir im Log ein deny meine shellys auf:

Sep 23 07:13:40

LAN

pfB_PRI1_v4 auto rule (1770006073)

192.168.18.16:6259

23.251.142.183:6011

TCP:S

Ob das unmittelbar mit dem Update zusammenhängt, ich glaube es ehr nicht, aber zumindest ist es mir vorher nicht aufgefallen.
Ich habe gestern mit der KI einige Ansätze versucht, das Problem zu lösen, da ich annehme, dass diese Verbindung schon seine Sinn hat, wenn die Shellycloude genutzt werden soll.
Nach einer gewissen Zeit der Erfolglosigkeit, hat sich die KI im Kreis gedreht.
Es ist mir bisher nicht gelungen, eine Ausnahme in pfBlocker einzupflegen, den Portrange (6022, 6011, 6021, 6012, 6013, 6015, 6020, 80) dafür zu definieren, der dann auch dauerhaft ein Reload vom pfBlocker sinnvoll übersteht.
Hat einer von euch einen Ansatz?

 

[blurrrr]

Moin,

PTR ist halt ...googleusercontent.com, vielleicht wird das ja schon geblockt Kannst Du nicht etwas in Richtung Whitelist (Alias) konfigurieren (mit FQDNs) und die Einträge entsprechend erlauben (vermutlich dann als permit outbound)? Da ich pfblockerng nicht nutze... vielleicht ist der Part hier auch noch interessant diesbezüglich:

pfBlocker always moves its rules to the top, how can I stop this?:
Change rule action to Alias only and then apply custom rules using pfBlockeraliases with an arbitrary sequence.

Quelle: https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html#faq

Aber vielleicht hast Du das ja sowieso schon so konfiguriert

 

[Fidibus]

Danke dir, ja, da war ich schon durch. Ich konnte beim pfBlocker letztendlich kein Ziel definieren...nur any, die bewußte IP hat er als Quelle eingebaut :-/
Egal wie...white-list, Regel...

 

[blurrrr]

Weiss ja nicht, wie Du es bisher so konfiguriert hast, aber ich nehme doch mal an, dass Du eine (oder mehrere) Listen erstellt hast. Irgendwelche Automatismen würde ich da persönlich wohl eher raus lassen und die Listen - wie auch schon im Zitat erwähnt - einfach nur als Alias definieren und dann die Regeln manuell setzen (halt je nachdem ein-/ausgehend). Dabei kannst Du halt noch explizit eine Allow-Regel erstellen (für die Shelly-Sachen), welche eben "vor" der "deny"-Regel der div. Listen/Aliase steht. Somit sollte diese Regel auch vor den anderen Regeln greifen und Dein Problem sollte erledigt sein.

pfB_PRI1_v4 auto rule (1770006073)

Besagt ja schon, dass es eine "automatisch" erstellte Regel ist.

 

[Fidibus]

Ich mache da wohl was Entscheidendes falsch:

Reaktion im Log:

 

[the other]

Moinsen,
geht es denn, wenn du die auto-Rule mal (kurz) deaktivierst?

 

[Fidibus]

mal (kurz) deaktivierst

Mich verwirrt da gerade das nun geloggte Absender-IF....
Das Logging ist auf der allowed Rule am LAN-IF.

 

[the other]

Moinsen,
ein paar Fragen dazu:
warum hast du eine Floating rule für das LAN Interface (IF), wenn du dort ebenfalls eine gleiche Regel hast (oder interpretiere ich das falsch)?
Warum (wie ja @blurrrr schon meinte) nutzt du die auto-rules? Alternative (und vielfach als besser befunden) wäre es, eine eigene Alias Regel dafür anzulegen, die kannst du dann einfacher da anbringen, wo sie wirken soll (zB direkt am Interface, an dem sich die shellys befinden).

Ich nutze hier zB gar keine Floating rules. Finde die immer so als Schattenregelwerk...da ich aber auch nur 11 produktiv genutzte Subnetze hier habe (also auch 11 IFs) ist der Aufwand vertretbar, die Regeln direkt als Interfaceregeln zu erstellen.
Mit pfblocker nutze ich explizit eben KEINE autorules (eben weil die im Hintergrund werkeln), sondern nutze besagte Alias Regel:

Dann beim gewünschten Interface eine neue Regel anlegen, hier bei Destination "Alias" auswählen und die Regel einfügen...
Und schließlich darüber (!) dann die Ausnahme für die shelly cloud IP...das sollte dann eigentlich funzen.

 

[Fidibus]

@the other :
Die Floating Rules sind bei der Nutzung des pfBlockers alleine "mit entstanden".
(Weiter, weiter, Fertigstellen )
Die Regeln werden bei jedem Update sozusagen "neu" erzeugt - zumindest hab ich das so verstanden und erlebt.
Ggf. bin ich ja auch falsch beim Auswählen der Interface für den pfBlocker - muss ich noch mal abtauchen.
Die Regel für die Shellys liegt direkt auf dem entsprechenden IF, hier LAN.
Ich habe dann, wie beschrieben, bei der Kontrolle nach dem Update, festgestellt, dass die Shellys auf eine IP halt neu wollten. Beim Erweitern der Bestandsregel blieb der deny halt bestehen.
Irgendwo im pfBlocker ist in einem Range wohl die IP mit drin - ich hab noch nicht gefunden, wo.
Wäre auch egal, beim nächsten auto-Update wäre der Bereich eh wieder komplett.
Ich schaue mir den Weg, den du vorschlägst mal an.

 

[the other]

Moinsen,
pfblocker macht mit den automatischen Regeln eben das, was eigentlich dann ja auch Sinn macht: generiert eine Automatische Regel unter den floating rules und setzt diese bei jedem Update wieder ganz nach oben (damit sich nix Böses davor einnisten kann). Das nervt dann aber eben auch, da ja floating rules eh schon priorisiert bearbeitet werden...da kannste dann am IF nix mehr drehen.

Also: gut überlegen, wann und ob automatische deny Regeln gesetzt werden sollen...besser eben ein alias native anlegen und dann da einfügen (IF und Regelhierarchie), wo es Sinn macht.
Hast du mal versucht, per ALLOW IP mit pfblocker die IP quasi auf die whitelist zu setzen? Denn die werden (so meine Info laut pfblocker) nochmal priorisiert, also sollten dann eben IMMER erlaubt sein...

 

[Fidibus]

ALLOW IP mit pfblocker die IP quasi auf die whitelist

Habe ich probiert, ein Fehler dabei war mir nicht bewusst, hat kein Erfolg gebracht.

 

[blurrrr]

Mach doch einfach mal wie bereits gesagt... Schalte alles automagische einfach AUS (ggf. kannst Du die Regeln ja auch einfach nur temporär deaktivieren), nutze pfblockerng um gewünschte Aliase zu erstellen und diese packst Du dann manuell in Firewall-Regeln und achtest da bitte auch auf die Reihenfolge (s. https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html#rule-processing-order).

Wobei ich die Frage ja interessanter finde, "warum" pfblockerng der Meinung ist, dass diese IP schädlich ist. Dem würde ich mitunter zunächst nachgehen. Da hat pfblockerng doch bestimmt irgendwas in Richtung Logs/Reports (muss ggf. auch erst noch aktiviert werden, k.a., nutze es nicht). Dort solltest Du dann aber (hoffentlich) auch sehen können, welche der eingebundenen Listen einen Treffer für die Shelly-IP erzeugt.

 

[Fidibus]

Moin,
Zwischenmeldung: aktuell greifen die Shellys nicht mehr da hin, Test ist also schwierig.

 

[blurrrr]

Test ist also schwierig

Eigentlich nicht... könntest die gleiche Regel ja theoretisch mal umstellen auf Dein LAN (Quelle) und dann mit Deinem Rechner einfach mal https://<betroffene IP> aufrufen. Dort sollte dann eine Zertifikatsfehlermeldung kommen:

Das Zertifikat gilt nur für folgende Namen: *.shelly.cloud, shelly.cloud

Wenn das funktioniert, kannst Du in der Firewall-Regel als Quelle wieder die Shelly angeben und jut ist

 

[Fidibus]

Getestet:

Sep 25 15:39:42

LAN

pfB_PRI1_v4 auto rule (1770006073)

192.168.18.109:62870

23.251.142.183:6011

TCP:S

Sep 25 15:40:14

LAN

pfB_PRI1_v4 auto rule (1770006073)

192.168.18.109:55301

23.251.142.183:443

TCP:S

Danke für deinen Tipp, hab ich gar nicht dran gedacht.

Aber vielleicht hat Shelly auch was korrigiert, da ich von den Geräten aktuell keinen dey bekomme.

 

[Fidibus]

Moin,
Frust!
Es hat soweit alles geklappt mit der Einrichting Whitelist, alias etc, alles im normalen pfBlocker flow drin.
Test hat geklappt mit shelly-port 6011.
Allerdings hat da auch die Gesamtheit aller Interface gegriffen, die im pfBlocker konfiguriert sind. Ich wollte aber explizit nur das IF, wo die shellys hinter sind.
Da komme ich definitiv auf Halt, alles sieht gut aus, aber es blockt die default-Regel :-(


Zurück, global white-list:


So eine Schei.....

 

[blurrrr]

Ich wollte aber explizit nur das IF, wo die shellys hinter sind.

Sind die denn auch alle hinter dem "LAN"-Interface (wie vermutlich Dein Rechner), oder ist das mitunter ein anderes Interface? Im Screenshot der vorherigen Nachricht (Test mit Rechner) hast Du ja das LAN-Interface angegeben.

 

[the other]

Moinsen,
wenn

Ich wollte aber explizit nur das IF, wo die shellys hinter sind.

dann warum eine Floating Regel? Mach die da doch weg (also unter pfblocker die autorule rausnehmen, sonst kommt die ja immer wieder beim cronjob update zurück und nach ganz oben...). Stattdessen dann eine alias native anlegen und diese dann unterm dem LAN IF reinbauen...

 

[the other]

Moinsen,
sorry, muss nochmal fragen:

Es hat soweit alles geklappt mit der Einrichting Whitelist, alias etc, alles im normalen pfBlocker flow drin.
Test hat geklappt mit shelly-port 6011.
Allerdings hat da auch die Gesamtheit aller Interface gegriffen, die im pfBlocker konfiguriert sind. Ich wollte aber explizit nur das IF, wo die shellys hinter sind.

Hast du diese dann wieder unter die floating rules gesetzt?
War die automatische Regel plötzlich wieder da? Hattest du das unter pfblocker zuvor nicht gelöscht oder wenigstens deaktiviert?

Daher:
1. unter pfblocker die "auto" rule für PRI4 löschen oder auf alias native ändern.
2. force reload/update auslösen (eigentlich sollte das dann schon die auto Regeln unter dem floating tab entfernen, besser nachschauen und ggf manuell die Regel pausieren oder direkt entfernen.
3. eine "alias native" in pfblocker erzeugen für PRI4.
4. Diese dann unter allen Interfaces manuell anlegen. (Ja, da wäre floating eleganter, aber...geht ja eben nicht so, also mehr Mühe aber dafür einfacher für die Interface Regelhierarchie).
5. Dann einfach (ohne pfblocker) im gewünschten Interface eine "allow" Regel anlegen mit der IP und Port Angabe als Ziel und ggf. den shellys mit ihren IPs als Quelle.
6. Diese dann oberhalb der PRI4 Regel einfügen.

Damit sollten dann auch weiterhin alle Interfaces (bzw die Geräte dahinter) in den Genuss der PRI4 IP Blockliste kommen, diese ist dann aber a) nicht mehr auto und damit nicht mehr priorisiert und b) nicht mehr floating, und auch dadurch nicht mehr priorisiert. Steht aber ggf. bei allen Tabs sehr weit oben...
...und damit sollte dann auch gewährleistet sein, dass in dem EINEN Interface Tab die allow > shelly IPort Regel wirkt...

Aber vorher eben alle Reste der alten auto PRI4 Regelung löschen / sicher deaktivieren.