action block - virusprot overload table - firehol alias und rules

[opnforumuser]

Hallo,
ich habe gestern auf unserer FW zwei Alias angelegt

•   Firehol mit der url https://iplists.firehol.org/files/firehol_level3.netset 
•   Private_IP_Networks [10.0.0.0/8] [172.16.0.0/12] [192.168.0.0/16]

In Firewall - Rules - Floating zwei rules hinzugefügt

• Block Source = Firehol  Destination = ! Private_IP_Networks
• Block Destination = ! Private_IP_Networks Source = Firehol

Nach jetzt rund einem Tag werden Verbindungen vom meiner DMZ1(10.10.10.0) zur DMZ2 10.20.20.0) geblockt mit dem label virusprot overload table
Auf die Schnelle habe ich die Regeln dekativiert und die FW neu gestartet.

Frage: Was ist die Ursache für das Problem und wie kann es vermeiden?

[JeGr]

>   Firehol mit der url https://iplists.firehol.org/files/firehol_level3.netset

Warum gerade die Firehol 3 und nur diese?
Eigentlich nutzt man aktiv Firehol1 und 2 und 3 bei Bedarf, da sich bei der 3er gern auch mal ein paar false positives einschleichen (da 30-Tage Schnittmenge).

> 2. Private_IP_Networks

Einfach RFC1918 nennen, ist kürzer und eindeutiger

> In Firewall - Rules - Floating zwei rules hinzugefügt

Warum in den Floatings? Bringt dir welchen Vorteil statt die auf WAN und oder LAN zu konfigurieren? Hast du ordentlich quick/in/out konfiguriert? Sind die Richtungen klar und was du mit quick ja/nein tust?

Darum empfehle ich nie Floating, da es meist viel zu konfus wird mit den anderen Regeln und hinterher keiner mehr weiß was wovor Vorrang hat. IMHO gibt es kaum gute Gründe Floating zu nutzen ohne sich die Regelhierarchie und -übersicht zu versauen.

> virusprot overload table

Das ist aber eine andere Regel. Wenn du nicht in deine Description genau das reingeschrieben hast, waren die Blocks nicht durch die Regeln sondern die genannte virusprot Regel. Aber ohne mehr Details zum Ruleset und Co ist das schwer zu sagen.

[opnforumuser]

Danke schon mal für die Infos.

Die Firehol3 hatte ich aus einem TK Webinar entnommen und wollte das testen, so nach dem Motto "es wäre ja schön, wenn man einen Großteil der Probleme verursachenden IP in der Welt aussperren könnte"

Daher kommt auch die Positionierung der Rules in Floating.
Eigentlich gingen in dem TK Beitrag beide rules firehol3 an/von any aber da wurden halt teilweise auch meine 10er Adressen gesperrt und es kam zu der Änderung "RFC1918" ;-)

Da die Probleme "virusprot overload table" erst danach aufgetreten sind, "Ein Problem ist aufgetaucht, was hat sich geändert?" habe ich es erstmal auf diese Änderung geschoben.

Ich denke aber, es hat etwas damit zu tun, das das Loging der beiden regeln eingeschaltet war und da möglicherweise "Hint: the firewall has limited local log space. Don't turn on logging for everything. " etwas übergelaufen ist.

Gefunden habe ich aber noch nichts zu dem Thema "was macht die opnsense, wenn der local log space überläuft?"

[JeGr]

> Die Firehol3 hatte ich aus einem TK Webinar entnommen und wollte das testen, so nach dem Motto "es wäre ja schön, wenn man einen Großteil der Probleme verursachenden IP in der Welt aussperren könnte"

Ist auch nicht verkehrt Muss man nur wissen, dass in level3 eben schonmal false positives drin sein können. Level1 und 2 sind recht safe dagegen.

> Eigentlich gingen in dem TK Beitrag beide rules firehol3 an/von any aber da wurden halt teilweise auch meine 10er Adressen gesperrt und es kam zu der Änderung "RFC1918" ;-)

Wird in level1 auch direkt thematisiert, dass man da bitte drauf achten soll, weil in level1 bspw. private RFC1918, Multicast und Bogons enthalten sind.

Ich glaube auch nicht ganz dass das Log Probleme sind oder an der virusprot lag, aber du kannst es ja wieder aktivieren und dann mal in die Diagnostics von den Tabellen schauen, je nachdem was abgehend geblockt wird schau einfach mal was in den Tabellen drinsteht - da kann man ja auch suchen