OPNsense Forum
International Forums => German - Deutsch => Topic started by: dsecure on July 11, 2020, 03:52:09 pm
-
Hallo,
ich kann irgendwie nicht nachvollziehen, woher eine bestimmte DNS Anfrage kommt. Hinter meiner OPNsense ist ein Pi-Hole auf welche alle DNS Anfragen aus dem LAN per FW Regel umgeleitet werden.
LAN (192.168.0.0) -> (192.168.0.12) OPNsense (192.168.1.1) -> (192.168.1.0) -> Router -> (WWW)
Ich werde aus den Logs nicht schlau, in den FW-Logs Live-view kann ich zwar die einzelnen Verbindungen sehen die aufgebaut werden, daraus kann ich die Quelle nicht ableiten.
Die Zeitstempel vom Pi-Hole und der OPNsense lassen sich ja vergleichen aber immer wenn dieser komische Request erfolgt, steht als src die WAN Schnittstelle der Opnsense da?
Weiterhin meldet mein DNSmasq : possible DNS-rebind attack detected: unifi.**** das kommt minütlich, die unifi-AP habe ich versucht zu blockieren, bringt aber nichts :(
Das ist FW Rule dazu: (Unter FW -> Regeln -> LAN)
Block IPv4 * 192.168.0.154 * * * * *
Könnte mir das bitte jemand erklären? Zu mindestens wo ich nachsehen muss woher die Requests kommen?
Danke!
-
Zu mindestens weiß ich jetzt mit Sicherheit das der DNS Request vom Unifi AP kommt, wie kann ich die IP blocken bzw. warum funktioniert mein FW - Regel nicht?
-
Okay, mit einem Neustart hat es jetzt geklappt, dieser unerwünschte DNS Request ist verschwunden :)
Ich habe herausgefunden das man bei -> Schnittstellen: Diagnose: Paketaufzeichnung genauere Daten von empfangenen und gesendeten Paketen erhält, der Nachteil ist, dass man dort für eine bestimmte Zeit aufzeichnen muss... gäbe es da eine andere logging Methode um so detaillierte Protokolle zu erheben?
Dann habe ich seit einigen Tagen noch einen DNS Request auf die g- und e- root-server.net Server, allerdings sind die zeitlichen Abstände variable und das passiert nur alle paar Stunden, das Pi-Hole gibt an das es von 192.168.1.1 also der Opnsense kommt, jetzt wäre es gut ein detaillierteres Log zu haben :/
evtl. kann mir jemand helfen, pls?
-
Warum zeigt mein OPNsense einen meiner Clients an der WAN Schnittstelle in ARP Tabelle an?
-
Ist 192.168.0.24 eine reservierte IP oder vom DHCP vergeben?
-
Statische Client IP, die anderen IP's egal ob statisch oder dynamisch werden korrekt in der arp Tabelle angegeben.
-
Und für welche MAC ist die IP reserviert?
-
Eigentlich keine Reservierung, die 192.168.0.24 liegt außerhalb der DHCP-Leasing Range.
-
Oke, ich habe gerade nochmal auf meinen Opnsense Router drauf geschaut und siehe da, die ARP Tabelle scheint wieder in Ordnung zu sein, anscheinend braucht die Sense manchmal etwas Zeit, bis alles zu 100% läuft.
-
Aber noch mal zu dem anderen Problem was ich hatte, kann mir jemand zur detaillierten Paket Protokollierung noch einen Tipp geben?
-
Vermutlich nur, wenn du konkret eine Frage formulierst...
-
Vermutlich nur, wenn du konkret eine Frage formulierst...
Ich versuche es mal :)
Ich suche eine Möglichkeit den Traffic zu untersuchen, die standart FW Logs sind nicht detailiert genug um immer Rückschlüsse zu ziehen. Ich schrieb schon weiter oben, dass man Pakete aufzeichnen und auswerten kann, allerdings muss man das über Interface->Schnittstelle machen, das ergibt viele Details allerdings muss das jedesmall manuell gemacht werden.
Es soll quasi standardmäßig die Pakete über einen definierten Zeitraum mit geloggt werden, mit einer Detailtreue ich glaub mind. Layer 3 oder höher wäre besser, also welches Protokoll wurde mit welcher IP zu einer anderen IP übertragen (UDP oder TCP), am besten auch der Verbindungsaufbau mit Payload, sollte nachvollziehbar sein.
Damit nicht irgendwann der Speicherplatz voll ist, sollten die Logs auch nur für einen gewissen Zeitraum vorgehalten bzw. gespeichert werden, also ich denke alles was in einem Paket so drinnen steht. Ich hoffe ich habe mich verständlich ausgedrückt...
Beste Grüße
-
du kannst doch eine friewall regel erstellen die entsprechend logt.
-
> du kannst doch eine friewall regel erstellen die entsprechend logt.
Naja das wird schwer. Wenn das generell Traffic ist und nicht nur eine IP, dann ist das schnell unübersichtlich.
Ich würde da eher einen Flow Collector hinstellen. Wenn man eh schon loggt, dann sollte das auch nicht auf der Firewall selbst sein, also extra VM/Kiste mit irgendeinem Tool, welches mit Flows umgehen kann und auf der Sense die dem Flow Collector sagen, dass er sie außer für seine eigenen Insights noch intern an IP sowieso schicken soll. Da auswerten und gut ist :)
Ansonsten wenn es wirklich nur um bspw. DNS geht was man loggen will, kann man auch eine Firewallregel spezifisch für DNS Traffic machen den man erlaubt und das Loggen lassen. Dann externes syslog konfigurieren und auf eine extra VM weiterleiten und bspw. eben nur die Firewall Logs dahin schicken. Mehr will man ja anscheinend nicht. Auf dem Logsystem kann man dann Auswertung und Retention etc. definieren wie man möchte. Kann man z.B Graylog o.ä. für nehmen.
-
du kannst doch eine friewall regel erstellen die entsprechend logt.
Kannst mir kurz ein Howto verlinken oder erklären wie das geht?
> du kannst doch eine friewall regel erstellen die entsprechend logt.
Naja das wird schwer. Wenn das generell Traffic ist und nicht nur eine IP, dann ist das schnell unübersichtlich.
Ich würde da eher einen Flow Collector hinstellen. Wenn man eh schon loggt, dann sollte das auch nicht auf der Firewall selbst sein, also extra VM/Kiste mit irgendeinem Tool, welches mit Flows umgehen kann und auf der Sense die dem Flow Collector sagen, dass er sie außer für seine eigenen Insights noch intern an IP sowieso schicken soll. Da auswerten und gut ist :)
Ansonsten wenn es wirklich nur um bspw. DNS geht was man loggen will, kann man auch eine Firewallregel spezifisch für DNS Traffic machen den man erlaubt und das Loggen lassen. Dann externes syslog konfigurieren und auf eine extra VM weiterleiten und bspw. eben nur die Firewall Logs dahin schicken. Mehr will man ja anscheinend nicht. Auf dem Logsystem kann man dann Auswertung und Retention etc. definieren wie man möchte. Kann man z.B Graylog o.ä. für nehmen.
Das wäre auch eine gute Idee, lieber wäre mir fast eine leicht gewichtige Lösung auf der Sense, allerdings wenn das Log outgesourct ist, könnte ich das auch realisieren. Gibt es dazu eine Anleitung oder hast Präferenzen zu Software die das kann, am besten open source oder freeware?
-
> Gibt es dazu eine Anleitung oder hast Präferenzen zu Software die das kann, am besten open source oder freeware?
Das hängt davon ab welchen Weg man gehen will. Bei Syslog würde ich ggf. zu Graylog tendieren, weil einfacher aufzusetzen als ein ganzer ELK Stack. Bei Netflows - puh, da muss man sich anschauen worauf das laufen soll und ob man was komplett Fertiges haben will oder sich selbst was zurecht baut. Wir haben da intern was mit nfsen/nfdump selbst konstruiert. Andere nutzen kostenlose (aber keine OSS) Software bspw. unter Windows von SolarWinds oder ManageEngine.
-
> Gibt es dazu eine Anleitung oder hast Präferenzen zu Software die das kann, am besten open source oder freeware?
Das hängt davon ab welchen Weg man gehen will. Bei Syslog würde ich ggf. zu Graylog tendieren, weil einfacher aufzusetzen als ein ganzer ELK Stack. Bei Netflows - puh, da muss man sich anschauen worauf das laufen soll und ob man was komplett Fertiges haben will oder sich selbst was zurecht baut. Wir haben da intern was mit nfsen/nfdump selbst konstruiert. Andere nutzen kostenlose (aber keine OSS) Software bspw. unter Windows von SolarWinds oder ManageEngine.
Graylog schaue ich mir noch mal genauer an, auf dem ersten Blick fand ich die Website etwas unübersichtlich. Da gab bzw. gibt es doch noch ntopng käme das evtl. auch in Frage?
Wenn der Traffic eh über ein interface extern zur Analyse zur Verfühgung gestellt wird, könnte da nicht gleich ein IDS zum Einsatz kommen, als zusätzliches Feature?
-
> Wenn der Traffic eh über ein interface extern zur Analyse zur Verfühgung gestellt wird
Wird er nicht, das verstehst du falsch. Log Weiterleitung enthält lediglich Syslog Daten. Flow Collectoren arbeiten mit Netflows. Beides passiert erst, wenn es überhaupt eine Aktion auf der Firewall gab, also nachdem(!) ein potentielles IDS überhaupt was mitbekommen hat. IDS mach nachgestellt wenig Sinn bzw. nur zum Loggen vielleicht, aber dann bräuchte das System einen Mirror Port vom WAN um die Events korrekt abzubekommen. Ansonsten würde ein nachgestelltes System ja nur Daten abbekommen die bereits durch die FW gelaufen und/oder verändert wurden.
-
> Wenn der Traffic eh über ein interface extern zur Analyse zur Verfühgung gestellt wird
Wird er nicht, das verstehst du falsch. Log Weiterleitung enthält lediglich Syslog Daten. Flow Collectoren arbeiten mit Netflows. Beides passiert erst, wenn es überhaupt eine Aktion auf der Firewall gab, also nachdem(!) ein potentielles IDS überhaupt was mitbekommen hat. IDS mach nachgestellt wenig Sinn bzw. nur zum Loggen vielleicht, aber dann bräuchte das System einen Mirror Port vom WAN um die Events korrekt abzubekommen. Ansonsten würde ein nachgestelltes System ja nur Daten abbekommen die bereits durch die FW gelaufen und/oder verändert wurden.
Super danke, jetzt kapier ich auch das mit dem Collector vom Netflow Output, Ntopng wurde hier wie ich gerade gesehen habe schon mal diskutiert. Für welche Software ich mich entscheiden soll, da bin ich gerade noch am Überlegen. Das mit dem IDS kann man sich offenhalten, scheint nur wirklich sinnvoll, wenn man auch weiß was man macht^^