OPNsense kann keine Regeln von FireHOL runterladen

[MarkusK]

Hallo,

ich habe nach dieser Anleitung versucht eine Blocklist von FireHOL einzubinden: https://blog.dannykorpan.de/archives/1-Cyber-Angriffe-abwehren-durch-FireHOL-Blocklist-in-OPNsense.html

Allerdings kann meine OPNsense anscheinend den Link zu der angegebenen Liste nicht herunterladen. Im Systemlog finden sich folgende Einträge:

Code: [Select]

2022-05-19T14:07:01
/update_tables.py fetch alias url https://github.com/firehol/blocklist-ipsets/blob/master/firehol_level3.netset (lines: 69985)
2022-05-19T14:05:01
/update_tables.py alias resolve error FireHOL (error fetching alias url https://github.com/firehol/blocklist-ipsets/blob/master/firehol_level3.netset)
2022-05-19T14:05:01
/update_tables.py error fetching alias url https://github.com/firehol/blocklist-ipsets/blob/master/firehol_level3.netset
2022-05-19T14:05:01
/update_tables.py fetch alias url https://github.com/firehol/blocklist-ipsets/blob/master/firehol_level3.netset (lines: 69985) (lines: 69985)

Habt ihr einen Tipp woran das liegen könnte und wie ich das Problem lösen könnte?

Markus

Edit: Eine identischer Alias nur mit einer Spamhaus-URL funktioniert 1a.

[tiermutter]

Moin,

mit dem hier geht das:

Code: [Select]

https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level3.netsetWichtig ist dass

Code: [Select]

raw.githubusercontent.com verwendet wird.

Firehol L3 ausgehend ist aber manchmal Mist, die würde ich nur eingehend anwenden

[MarkusK]

Danke @tiermutter, genau das war es. 

Die Regel ist doch nur eingehend laut der Anleitung (Direction = in). Oder täusche ich mich da?

[tiermutter]

Habe ich mir nicht im Detail angeschaut, schaue ich später ggf nochmal hin

[tiermutter]

Die Seite/ Anleitung ist Käse.
1. Nutzt man floating rules, wenn eine Regel auf alle Interfaces zutreffen soll wie da beschrieben wird "alle WAN und LAN Interfaces".
2. Sollten die Regeln für LAN und WAN unterschiedlich aussehen. Das meine ich mit eingehend und ausgehend. Auf dem LAN wird das Ziel geblockt (ausgehend), auf dem WAN wird die Quelle geblockt (eingehend). Laut Anleitung wird auch auf dem WAN das Ziel geblockt, das macht für mich zumindest keinen Sinn.

[MarkusK]

Danke @tiermutter für die Hinweise.

Wenn ich das mit den Floatingregeln richtig verstehe, werden diese Regeln für alle Schnittstellen angewendet ohne das ich für jede einzelne eine erstellen muss, oder? Zumindest verstehe ich das in den Docs so.

Das mit dem Unterschied zwischen LAN und WAN ist auch interessant. Macht man das mit der DMZ genau so?

[tiermutter]

Bei den Floating rules kannst Du angeben, auf welche Interface die Regel angewendet wird.
Aber Obacht: Floatings werden immer vor den Interface Regeln angewendet. Wenn also Interface Regeln vor der Blocklist Regel greifen muss, muss die Regel separat für das Interface erstellt werden, statt über Floating.

Ob das für die DMZ auch gelten soll kommt halt drauf an, adhoc spricht nichts dagegen, aber das kommt auch auf die Liste an... Firehol Level 1 kannst Du da zB nicht verwenden, da sie die Full Bogons (private Netze) beinhaltet.

[MarkusK]

Danke für das Feedback.

Habe die Regeln (FireHOL, Spamhaus) bei den Interfaces jetzt mal rausgeschmissen und Floatings für das WAN (eingehend) und LAN, DMZ (ausgehend) erstellt.

[tiermutter]

Wunderbar, hoffe es läuft
Welche Listen hast Du jetzt im Einsatz?

[MarkusK]

Ich nutze die FireHOL Level 3 sowie Spamhous Drop und EDrop.
Zusätzlich nutze ich noch GeoIP block.

[Patrick M. Hausen]

Ausgehende Regeln braucht man praktisch nie. Kannst du mal eine davon posten? Nur wenn du willst, natürlich.

[tiermutter]

Sorry, das "ausgehend" und "eingehend" habe ich wohl etwas unverständlich reingebracht...

Mit ausgehend meine ich "Clients aus dem LAN (und co) dürfen nicht zu IPs auf den Listen sprechen".
Mit eingehend meine ich "IPs auf den Listen dürfen nicht zu Clients im LAN / der Sense sprechen".
Auf den Interfaces wirken aber alle Regeln inbound.

Bei mir sieht das dann so aus:


Wobei alle Regeln* wo die Listen als Source angegeben sind auf WAN Interfaces wirken (eingehend) und alle Regeln wo die Listen als Destination angegeben sind auf LAN/ VPN/ interne Interfaces wirken (ausgehend).

*Firehol L1 wirkt nur auf ein WAN Interface, da ich am LTE if ein LTE Modem hängen habe, was sonst geblockt werden würde.

[MarkusK]

Hier mal mein Screenshot...

[tiermutter]

Warum je zwei mal Firehol und Spamhaus? Beides bei der Quelle, aber inbound/outbound.
Das ist so nicht korrekt, aber mein Fehler, dass ich das so unglücklich formuliert habe, siehe mein letzter Post.

[tiermutter]

BTW:
Die können alle auf v4 only als Protokoll stehen... keine der Listen beinhaltet v6 Adressen. Für v6 gibt es nur Spamhaus DROPv6