OPNsense Forum
International Forums => German - Deutsch => Topic started by: kalteVollmilch on October 26, 2017, 03:29:11 pm
-
Hallo zusammen :),
ich möchte gerne, dass OPNsense die ausgehenden "genatteten" Verbindungen remote loggt, finde aber leider keine Möglichkeit dazu.
Aussehen sollte das Ganze im Idealfall wie in der Web GUI unter "Firewall -> Diagnostics -> States Dump" bzw. die Ausgabe in der Konsole nach
pfctl -s states
Die NAT Regeln habe ich bereits von automatisch nach manuell umgestellt, wobei die manuellen Regeln identisch mit den automatischen sind mit der Ausnahme, das Logging aktiviert ist.
In den Firewall Logs selbst habe ich leider nichts dergleichen gefunden, sodass diese für mich mehr oder weniger nutzlos sind.
Schonmal vielen Dank im Voraus.
Gruß, die Vollmilch :D
-
System -> Settings -> Logging
[ x ] Send log messages to remote syslog server
Remote Syslog Servers: Server1 "deinserver"
Remote Syslog Content: [ x ] Firewall Events
-
Hi Nils,
danke für deine Antwort, aber das habe ich bereits probiert und das bringt nicht wirklich viel, da
- ich nicht weiß, wie ich in dieser Logdatei die Nat-Events finde oder
- da tatsächlich keine Nat-Events in diesem Logfile geloggt werden
Zumindest die Ausgabe, wie ich sie in meinem ursprünglichen Post beschrieben habe, kann ich damit leider nicht erzeugen.
Gruß die Vollmilch
-
Du willst doch nicht jeden einzelnen State loggen? Das ist nicht vorgesehen, m.W.
Ich lasse mir auf einer pfSense die States zu einzelnen lokalen IPs mehrfach am Tag als eMail zusenden, aber dauerhaft ALLE States, wie soll das gehen? Einen Cron Job alle Minute? :-D
Das Komando is ähnlichen deinem:
/sbin/pfctl -ss | grep <IP_of_interest>
...ick gloobe es gibt aber kein Mailpaket für OPNsense, oder täusch ich mich da gerade? :-)
Was in aller Welt willst du mit allen States in einem Log?
-
Ja, ich will tatsächlich jeden einzelnen State loggen :D
Das von OPNsense aufgespannte LAN wird in einer Uni verwendet, und da sind wie man auch erwarten würde, eine ganze Menge Clients verbunden.
Wenn dann jemand mal Quatsch anstellt, gibt es eine Meldung der Art "[WAN IP von OPNsense : genatteter Port] hat Mist gebaut, macht was!", und dann muss rückverfolgbar sein, welche LAN IP das war.
Lokal brauche ich die Logfiles auch nicht unbedingt, lediglich remote sollte das komplette log verfügbar sein.
Immerhin gibt es dafür auch einen extra Server.
Wenn das nicht gehen würde, wäre das zwar kein Beinbruch aber zumindest sehr schade.
-
...aber zur Zuordnung der IP brauchst du doch eher die DHCP-Logs...
-
aber die DHCP Logs verraten mir doch nur die LAN IP der Clients :o
Wenn so eine Meldung kommt, wird in dieser nur die genattete IP genannt, worauf ich in der Lage sein muss, dieser genatteten IP die LAN IP zuzuordnen
Beispiel:
Client hat im LAN die IP 10.149.64.128
Client schickt Anfrage an 8.9.10.11
OPNsense schickt die Anfrage als 192.168.4.5:12345 weiter an 8.9.10.11 (durch NAT logischerweise; 192.. ist die IP Adresse von dem Rechner mit OPNsense im WAN)
Schock: Dieser Verbindungsaufbau war "schadhaft" (wie auch immer sei jetzt erstmal irrelevant)
-> es kommt eine Meldung bei mir an: "Die Verbindung von 192.168.4.5:12345 um 14:48:25 war böse"
ich schaue in dem NAT Log nach: 192.168.4.5:12345 war zu dem Zeitpunkt die genattete IP von 10.149.64.128
-> ich kann den Client verwarnen etc..
Ich hoffe, zumindest mein Anwendungsbeispiel ist jetzt deutlicher.
So wie ich das sehe, dürften mir die DHCP Logs hier nicht wirklich weiterhelfen. Oder habe ich hier gerade einen gewaltigen Denkfehler?
Abgesehen davon schonmal vielen Dank für deine Bemühungen, chemlud! :)
-
> war zu dem Zeitpunkt die genattete IP von 10.149.64.128
Und woher weißt du wer zu der Zeit die IP war? DHCP Log bspw. sagt nicht unbedingt, wann/ob der Client noch da war oder zu der Zeit noch der selbe der vorher konfiguriert war. Ggf. hat sich da statisch die IP vergeben - gerade an einer Uni basteln die gerne mal selbst. Wenn du das als Beweis für irgendwas / Verwarnung nutzen willst, ist das IMHO SEHR dünnes Eis! Ich als Student oder sonstwer der sowas bekommt würde das sehr fix anfechten.
Entweder du machst das Logging via einem Portal wo klar(er) ist, wann wie lange jemand verbunden war (auch wegen MAC Adresse dann eindeutiger als ne IP) oder via Proxy. Aber simpel einfach nur das NATting von einer IP? Das wäre IMHO kein sinnvoller Beweisträger.
Gruß
-
erstmal vielen Dank für die Antwort, JeGr.
Ich gebe dir Recht, das Ganze ist nicht unbedingt hieb- und stichfest, aber so gewünscht. Ich mache die Regeln an dieser Stelle nicht, ich befolge sie einfach nur.
Zum Thema Zuordnung gibt es zumindest noch das Accounting via Radius, welches vielleicht eher aussagekräftig ist. Desweiteren erfolgt auch nicht sofort eine Sperrung, sondern erstmal eine Mail bzw. ein Gespräch, in dem man sich erklären kann - und demzufolge auch wehren.
Anyway, ich möchte hier nicht über Sinnhaftigkeit bzw. Sinnlosigkeit dieser Methode diskutieren (auch wenn die Punkte natürlich stimmen!), ich habe eher gehofft, dass es für mein Problem eine mehr oder weniger einfache Lösung gibt.
Hat nicht doch jemand eine Idee? :)
-
Falls es jemanden interessiert, ich habe jetzt eine Lösung gefunden, so ein Logfile nachzubauen:
Man fügt bei der Firewall sowohl bei dem WAN- als auch bei dem LAN-Interface eine neue Regel ganz am Ende ein, welche allen Traffic erlaubt, aber mitloggt.
Da vorher alle Regeln, welche Traffic möglicherweise blockieren, bereits geprüft wurden, stellt diese Regel kein Sicherheitsproblem dar.
Im Logfile der Firewall kann man dann ganz einfach z. B. nach der Ziel-IP suchen und erhält unmittelbar aufeinanderfolgend 2 Einträge: einmal mit der internen IP als Quelle und einmal mit der genatteten IP
-
> Man fügt bei der Firewall sowohl bei dem WAN- als auch bei dem LAN-Interface eine neue Regel ganz am Ende ein, welche allen Traffic erlaubt, aber mitloggt.
> Da vorher alle Regeln, welche Traffic möglicherweise blockieren, bereits geprüft wurden, stellt diese Regel kein Sicherheitsproblem dar.
Auf dem WAN? Eine Regel die alles erlaubt und loggt? :o
Also klar, wenn du auf dem WAN vorher schon alles reingelassen hast, OK, aber WAN ist im Normalfall "Block all"? Beim LAN kann ich das bedingt noch nachvollziehen.
-
Ups, mein Fehler, da war ich zu ungenau :-X
Bei der Regel im WAN ist als Source "This Firewall" eingestellt. Soweit ich das einschätzen kann, werden damit ausgehende Pakete erlaubt, die ja sowieso erlaubt werden.
Eingehende ungewünschte Pakete werden nach wie vor weiter blokiert.
Möglicherweise könnte man als Destination noch WAN net einstellen, doch dazu sehe ich keine wirkliche Notwendigkeit
-
> Bei der Regel im WAN ist als Source "This Firewall" eingestellt. Soweit ich das einschätzen kann, werden damit ausgehende Pakete erlaubt, die ja sowieso erlaubt werden.
Auf dem WAN hast du eine Regel mit Source "this firewall"? Welche Pakete soll die denn loggen? Oder ist das eine Floating Regel? Andernfalls macht es nur begrenzt Sinn, denn Pakete werden auf dem WAN nur auftauchen mit einer Source Adresse von extern/Internet, aber nicht mit "this firewall" also einer der Firewall IPs. AUSgehender Traffic wird durch EINgehende Regeln doch gar nicht erfasst! :) Daher die Frage - denn auf den Interface Reitern werden nur eingehende Regeln (pass/block/reject IN) erstellt - zumindest soweit mir bekannt ;) Wenn du wirklich ausgehende Verbindungen erfassen wolltest, müsste man das IMHO als Floating Regel mit Direction OUT auf dem WAN erstellen, aber das könnte dann etwas abenteuerlich werden :)
-
Ich weiß, dass ich nichts weiß :o
denn auf den Interface Reitern werden nur eingehende Regeln (pass/block/reject IN) erstellt
Ich muss zugeben, das wusste ich bis jetzt nicht :D
Aber: es funktioniert. Ich bin dank den Logs in der Lage, IPs zurückzuverfolgen, und das auch definitiv aufgrund der beiden FW Regeln, denn der Rest der Regeln erstellt keine Logeinträge mehr.
Scheinbar muss ich mich in die Materie später nochmal umfangreicher einlesen, aber für den Moment reicht es ersteinmal so, wie es ist.
Gruß, die Vollmilch :)
-
"als Floating Regel mit Direction OUT auf dem WAN erstellen,"
Bidde wie? Ich dachte floating ist immer ALLE Interfaces?!?
Und den Rest: Bitte nicht nachmachen. Wenn da was schief geht, ist die ganze Firewall ein einziges Loch im Internet...
-
"als Floating Regel mit Direction OUT auf dem WAN erstellen,"
Bidde wie? Ich dachte floating ist immer ALLE Interfaces?!?
Nö, Floating heißt ja an der Stelle nur, dass es keinem Interface per se schon zugewiesen ist. Das kann dann eine Regel sein, die für alle oder nur selektierte Interfaces gilt oder eben nur eines. Ich dachte da an etwas wie die Regel im Attachement, da Floating Rules die einzigen sind, bei denen die Richtung (out) angegeben werden kann. Andernfalls sind es immer nur inbound, also ankommende Pakete, die gefiltert werden. Alles andere ist stateful (bzw. wird intern von der sense automatisch erzeugt). Außerdem kann man die Floating Rules auch einstellen, ob sie quick sind oder nicht :) (also sofort anwenden oder weiter durchlaufen à la ipchains/iptables).
Rein vom "pf" selbst (also dem Paketfilter) gehört zu jeder Regel immer eine pass in auf dem eingehenden und ein pass out auf dem ausgehenden Interface. Der pass out Teil wird aber durch UI und Programmierung einfach automatisch auf allen Interfaces gesetzt. Würde man die Regel selbst schreiben, würden das immer Regel-Paare aus "pass in quick on <wan>" und "pass out quick on <lan>" werden. Als Beispiel :)
Grüße