OPNsense Forum
International Forums => German - Deutsch => Topic started by: bewue on April 10, 2018, 10:48:29 pm
-
Moin Leute,
ich würde gerne alle neuen Pakete die aus dem Internet auf dem WAN Interface
ankommen loggen. Für die Pakete für die am WAN Interface kein Portforwarding konfiguriert ist
scheint das auch zu funktionieren.
Das Portforwarding zu Hosts im LAN sorgt dafür dass erst an dem entsprechenden
LAN Interface eine Lognachricht generiert wird. Diese kann ich dann aber nicht mehr generisch zuordnen.
Kann man nicht einfach alles "neue" eindeutig loggen was am WAN Interface ankommt?
Grundsätzlich würde ich dafür Netflow nehmen, aber das scheint nur Pakete zu beachten die am WAN Interface
durch die Firewall erlaubt sind.
-
Bisher habe ich über das GUI eine Floating rule dafür angelegt:
block in log on igb2 reply-to ( igb2 x.x.x.x ) inet from !$Private to {any}
Wie erwähnt machen aber die Port Forwardings auf dem WAN Interface Probleme.
Für die weitergeleiteten Ports werden keine Logs über die Regel oben geschrieben,
da die NAT-Regeln vor den Floating-Regeln abgearbeitet werden.
Macht es Sinn hierzu die Regeln unter der Haube manuel zu bearbeiten (die Reihenfolge),
bzw. geht das überhaubt?
Oder ist mein Ansatz zur Lösung des Problems schon von Grund auf Falsch?
-
> LAN Interface eine Lognachricht generiert wird. Diese kann ich dann aber nicht mehr generisch zuordnen.
Wenn du in der durch NAT erzeugten Firewall Regel ein "Log" Haken reinmachst, hast du es am WAN wieder. Und da NUR das geNATtet wird, was du in den NAT Regeln definiert hast, wird alles andere mit Zieladresse <WAN Adress> trotzdem als generischer Block in den Filtern auftauchen. Verstehe daher nicht, was gemeint ist, mit "erst am LAN". Wenn es am LAN auftaucht ist es bereits ein Match auf deine NAT Regel gewesen und dann potentiell wohl auch gewollter Traffic und kein Block?
-
Warum kann ich die durch NAT erzeugte Firewall Regel nicht editieren?
Auch die automatische Block Regel für z. B. "RFC 1918 networks" kann ich nicht editieren und somit
hier das Logging nur für alle oder kein Interface aktivieren.
Aber auch wenn ich selber eine Regel erstelle und Logging aktiviere, bleibt das Problem
bestehen, da nur der geforwardete Port in der Lognachricht auftaucht.
Zudem ist die Zieladresse nicht <WAN Adress> sondern die des Hosts zu dem geforwardet wurde.
-
Warum kann ich die durch NAT erzeugte Firewall Regel nicht editieren?
Die Regel wird dynamisch abhängig von den NAT-Einstellungen erzeugt. Du kannst das aber mit einer eigenen Regel lösen indem du sagst, dass du keine zugehörige Filterregel willst und diese selber erzeugst (falls das noch geht).
Aber auch wenn ich selber eine Regel erstelle und Logging aktiviere, bleibt das Problem
bestehen, da nur der geforwardete Port in der Lognachricht auftaucht.
Zudem ist die Zieladresse nicht <WAN Adress> sondern die des Hosts zu dem geforwardet wurde.
DNAT muss VOR dem Filtern passieren, sonnst würde ja die Firewall mit falschen Daten arbeiten. Was soll den überhaupt der Sinn sein, die Quellports vor dem DNAT zu verwenden, da sich dieser Port ja durch die NAT-Regel ergibt?
-
DNAT muss VOR dem Filtern passieren, sonnst würde ja die Firewall mit falschen Daten arbeiten. Was soll den überhaupt der Sinn sein, die Quellports vor dem DNAT zu verwenden, da sich dieser Port ja durch die NAT-Regel ergibt?
Ich will sehen was am WAN Interface von außen ankommt, unabhängig von meinen aktuellen Portforwardings.
Über Syslog will ich die Firewall-Logs dann an mein Elastic-Stack schicken um das ganze zu visualisieren.
Für die "neuen" Packete aus dem Internet benötige ich haupsächlich die Quell-IP und den Ziel-Port.
Der Ziel-Port z. B. soll der aus dem ursprünglichen Packet sein was am WAN ankommt, alles andere würde
die Daten in den Visualisierungen verfälschen.
Mich interessiert was die Leute im Internet anfragen und nicht was meine Firewall mit den Packeten noch macht!
Das gehört für mich zum grundsätzlichen Traffic Monitoring.
Vermutlich wäre eine Lösung eine Custom Regel vor den NAT-Regeln zu platzieren.
Dazu gibt es aber anscheinend keine Möglichkeiten im GUI.
Gibt es unter der Haube eine Stelle wo man hier was machen könnte, oder etwas grundsätzlich anderes?
-
Dann visualisiere dir das ganze nicht mit irgendwelchen Firewall Logs, sondern lass dir die Flows auf dem WAN auslesen und schicke die an deinen Elastic Stack. Der kann auch mit Flows umgehen und du bekommst was das WAN sieht. Ob in den Flows aber dann die Forwards in internen IPs oder exernen stehen (wann also der Flow greift) kann ich auswendig nicht sagen.
Verstehe aber den Use Case bei den Forwards nicht. Wenn ich die einzeln visualisieren will dann greif ich sie eben noch zusätzlich ab. :)
> Gibt es unter der Haube eine Stelle wo man hier was machen könnte, oder etwas grundsätzlich anderes?
Könnte schwierig werden, da wie gesagt Rewrites logisch vor dem Filtering kommen müssen. Verstehe aber nicht wirklich wo das Problem ist wenn die Forwardings in deiner Statistik nicht auftauchen. Bzw. du kannst die auch extra loggen und siehst dann deren Traffic. Aber die meisten Dashboards die meine Use Cases sind oder wollen, wollen entweder sehen, was alles einschlägt -> dann wäre das alles was geblockt wird o.ä. oder alles an project/customer traffic -> dann sind es eh alles erlaubte Verbindungen und die kann man mit Flows + Netzangaben etc. eh besser abgreifen und pro project/customer darstellen.
Hängt also schon von deinem Use Case ab :)