ZFS Datenträger läuft voll

Started by heiligst, July 02, 2024, 06:32:00 PM

Previous topic - Next topic
Danke für euren bisherigen Input - werde mir das heute/morgen mal ansehen.

Interessant ist halt, dass ich das Problem erst seit Kurzem habe und ich selber nicht geändert habe => vermutlich wieder irgendwo etwas durch ein Update "verpfuscht"!?

August 05, 2024, 09:30:59 PM #46 Last Edit: August 05, 2024, 09:33:43 PM by heiligst
So, hoffe ich habe alles.

grober Aufbau:

Kabelmodem im "bridge-modus" - stellt also nur das "Internet" zur Verfügung - Rest (DHCP,....) läuft alles über OPNSense.

Schnittstelle igb0 = vlan1 = mein lokales Heimnetzwerk (Notebooks / Server / .....)
opt2 = vlan20 = eigenes Netzwerk für Drucker
opt1 = vlan30 = eigenes Netzwerk für HomeOffice/Gäste - voller Zugriff aufs Internet und auf die Drucker

unbound läuft auf Port 5335 - dies ist auch so bei ADH hinterlegt (also: 192.168.1.1:5335)


Regeln fürs LAN/Heimnetzwerk (VLAN1)


Ich bin gespannt, was die versierteren Kollegen sagen, aber für mich sieht es so aus, dass du den IP-Adressen von Spam-House exklusiven Zugriff auf dein Netzwerk gewährst. Sprich: bei mir gehen die Alarmglocken an, dass sich bei angedachter Blockregel kein Block-Symbol aka X befindet. Wahrscheinlich wirst du auch alle externen IP-Adressen auf Ubound in dieser Blockliste finden.

Exakt - die 3 WAN-Regeln sind ja alle allow statt deny. Das Netz ist weit offen und zwar ausgerechnet für die externen Adressen, die auf den 3 Listen drauf sind ...
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

August 06, 2024, 03:45:01 PM #52 Last Edit: August 06, 2024, 03:58:43 PM by Baender
Ich frage einfach mal, um für mich hier auch was mitzunehmen:
1. Wenn hier keine Floating Rules vorhanden wären, wäre die Auswirkung der falsch gesetzten WAN-Regel gleich 0? Weil Floating Rules (nach internen) als 2. Regelgruppe bearbeitet werden und diese über alle Interfaces hinweg gelten, kommt es hier überhaupt erst zu einem Problem?
2. Wäre es möglich, dass durch das Anlegen einer weiteren NAT, bei der ich von der WAN-IP auf die LAN-IP NAT'e, externe IP-Adressen Zugriff auf mein gesamtes Netzwerk im LAN hätten? Ich überlege, wie es noch schlimmer gehen könnte. Weil aktuell (aus Frage 1 heraus) kann ich ja nicht auf Geräte im bspw. LAN zugreifen oder?

Edit: Wobei ich mich etwas korrigieren müsste. Die Floating Rules nennen 192.168.1.1 als Ziel. Das ist vermutlich der Gateway von LAN. Wie könnte dann das NAT für alle Netzwerke außer LAN funktionieren? Selbst wenn ich unter Interfaces zahlreiche Netzwerke angeben, wird das NAT doch nur für das Netzwerk funktionieren, für das der GW 192.168.1.1 ist oder?
Wie kommt dann eine WAN IP zu Unbound?

Quote from: Baender on August 06, 2024, 03:45:01 PM
1. Wenn hier keine Floating Rules vorhanden wären, wäre die Auswirkung der falsch gesetzten WAN-Regel gleich 0?
Nein, sie wären genau so katastrophal.

Quote from: Baender on August 06, 2024, 03:45:01 PM
Weil Floating Rules (nach internen) als 2. Regelgruppe bearbeitet werden und diese über alle Interfaces hinweg gelten, kommt es hier überhaupt erst zu einem Problem?
Die Floating-Regeln haben aber nur für sich genommen kein Implicit Deny. Es gibt nur ein Implicit Deny ganz am Ende der Regel-Bearbeitung:

Floating --> Interface Group --> Interface --> Deny.

Sonst könnte man ja gar keine Regeln anlegen, wenn "nix" bei Floating quasi alles dicht machen würde.
Wenn die Regeln "quick" sind, gilt die Reihenfolge oben, die erste Regel, die matcht, wird genommen und die Aktion (allow/deny) ausgeführt.

Quote from: Baender on August 06, 2024, 03:45:01 PM
2. Wäre es möglich, dass durch das Anlegen einer weiteren NAT, bei der ich von der WAN-IP auf die LAN-IP NAT'e, externe IP-Adressen Zugriff auf mein gesamtes Netzwerk im LAN hätten? Ich überlege, wie es noch schlimmer gehen könnte. Weil aktuell (aus Frage 1 heraus) kann ich ja nicht auf Geräte im bspw. LAN zugreifen oder?
Dazu würde es eingehendes Port-Forwarding brauchen, damit man das LAN erreicht, wenn das LAN ein RFC-1918-Netz verwendet. Allerdings ist das LAN im Moment über IPv6 weit offen. Da findet ja kein NAT statt.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Bezieht sich deine Aussage von "Nein, sie wären genau so katastrophal." exklusiv auf den Umstand mit IPv6? Anders gefragt, welcher Schaden entstünde bei einem reinen IPv4-Anschluss und der expliziten Deaktivierung der IPv6-Funktionalität in OPNsense?

Quote from: Baender on August 06, 2024, 04:09:34 PM
Bezieht sich deine Aussage von "Nein, sie wären genau so katastrophal." exklusiv auf den Umstand mit IPv6? Anders gefragt, welcher Schaden entstünde bei einem reinen IPv4-Anschluss und der expliziten Deaktivierung der IPv6-Funktionalität in OPNsense?
Ein allow all auf WAN nur mit IPv4 und mit einem RFC-1918-Netz intern wäre schwieriger auszunutzen und evtl. gar nicht. Es gibt in IP seit RFC 791 eine Source-Routing Option. D.h. man kann dem Paket eine Ziel-Adresse aber auch einen oder mehrere Zwischenstationen mitgeben.

Wenn der ISP das nicht raus filtert, dann könnte man also ein Paket mit Ziel 192.168.1.<internerserver> an 1.2.3.4 (WAN-Adresse) werfen und gucken, was passiert.

Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

August 06, 2024, 04:46:15 PM #56 Last Edit: August 06, 2024, 04:54:13 PM by heiligst
Quote from: Patrick M. Hausen on August 06, 2024, 01:53:14 PM
Exakt - die 3 WAN-Regeln sind ja alle allow statt deny. Das Netz ist weit offen und zwar ausgerechnet für die externen Adressen, die auf den 3 Listen drauf sind ...


Hm, sch.. - stimmt.
"rein" in die FW sollten ja genau diese Adressen "gesperrt" werden...
:o

Hab das vor einiger Zeit mal nach einem HowTo eingerichtet - mal sehen ob ich das noch finde - ob das dort dann falsch war, oder ob ich mich da irgendwo/irgendwie "verhaut" habe!

Danke!


D.h. diese 3 "WAN-in-Regeln" auf "block" - dann sollte es wieder passen.


In AGH sollten dann bei den Clients eigentlich nur mehr meine Geräte stehen, oder?

LG

Eigentlich schon.

Aber nochmal im Ernst: was erhoffst du dir von diesen drei Regeln auf WAN? Der Effekt - wenn das die einzigen Regeln sind, und sie korrekt auf "block" stehen - ist nämlich absolut Null.

Ganz ohne jede Regel auf WAN wird doch sowieso alles geblockt.

Nur wenn du unter den drei Block-Regeln dann irgendwelche Allow-Regeln hast für eingehende Dienste, ergibt das Ganze überhaupt einen Sinn.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

WireGuard habe ich bei den "fließenden Regeln" hinterlegt - das fällt ja dann auch da rein, oder nicht?

Generell (abgesehen von meinem "allow" Fehler) wird das bei den HowTo's/Videos auch so eingerichtet.
Möchte halt die entsprechenden gefährlichen IP-Adressen/Länder blocken.


LG

Floating wird vor den Interface-Regeln abgearbeitet, also kann man WireGuard auch von den ganzen geblockten Adressen aus kontaktieren und der Block auf WAN ist ein No-Op, weil ja sowieso alles geblockt wird, was nicht erlaubt ist.

Vergiss Videos. Mehr als 90% sind völliger Müll. Zieh die WireGuard Regel von Floating nach WAN und zwar hinter die Block-Regeln um, wenn das ganze irgendeinen Sinn haben soll. Beschäftige dich mit Firewall-Grundlagen. Mit Büchern.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)