Guten Tag,
ich will mein internes LAN und WLAN etwas "sichere" machen.
Aktuell gibt es jeweils eine Standrad-Regel die intern alles erlaubt, also im LAN sowie im WLAN.
Das will ich jetzt ändern und nur die Ports erlauben die ich für "empfohlen" halten.
Ich bin noch Anfänger und habe mich etwas eingelesen.
Es funktioniert z.B. über Aliases.
Bei Typ wähle ich Ports aus und bei Content trage ich z.B. 80 443 68 usw. ein
Ich nehme in der Firewall die Standard-Erlaube-Alles Regel raus und erstelle einen neue Regel, die Erlaubt und wo ich den erstellten Alias auswähle.
Dazu habe ich drei Fragen.
1.)Besteht die Gefahr das ich mich vom Web-Interface der opnsenese aussperre?
Also wenn ich den Port 443 z.B. vergesse, das ich nicht mehr auf meine opnsense komme?
2.) Auf dem WLAN Interface habe ich ein DHCP Server laufen.
Muss ich diesen auch dann erlauben? Ist das dann Port 68?
Sowie ich auch den DNS Port erlauben muss?
3.) Wie stelle ich das am besten an um herauszufinden welche Apps auf dem Smartphone welche Ports benötigen?
Z.B. bei whatsapp oder telegram
Vielen Dank
Moin,
Grundregel bei Firewalls ist im Normalfall:
Es ist alles verboten, was nicht explizit erlaubt ist.
Das sollte deine Frage beantworten :-)
Du hast leider nicht geschrieben, wohin du dei Limitierungen machen will - zwischen einzelnen Netzen oder vom LAN ins Internet ?.
Es gibt eine Destination-Einstellung in den Regeln, "This Firewall", damit regelt du den Zugriff aus dem LAN auf die Firewall.
Mein Rat, vom internen LAN ins Internet würde ich nichts blocken, weil das ein heillosen Unterfangen ist, ständig für Anwendungen usw. die Ports nach zupflegen - gerade bei Smartphones kaum machbar.
Ohne ein Mit-Tracen des Daten-Verkehrs kaum realisierbar und selbst dann ist es nur eine Momentaufnahmen.
Arbeite hier lieber mit FIltersysteme wie PiHole oder Adguard, welche dir z.b. den ganzen Werbemüll wegfiltern und selbst damit wirst du immer wieder Domains usw. auf die Whitelist setzen müssen, weil irgentwas plötzlich nicht mehr geht.
AdGuard kann z.b. auch Dienste wie Facebook usw. direkt sperren, bei Pihole kann man noch weiter gehen und spezielle Filterregeln für einzelne Clients / Clientgruppen erstellen - z.b. Geräte der Kinder.
Mein Rat - und so mache ich es bei mir zuhause und bei Bekannten die OPNSense nutzen - richte dir VLAN's ein, wenn deine Switche das können und packe alle Geräte, die z..b nichts ins Internet dürfen, in ein VLAN rein und sperre dann dafür den Internetzugang.
Ich hab z.b. VLAN für "privat" ( Notebooks, Smartphone usw. ), Media ( AppleTV, Amazon Echo usw. ), Smarthome ( alle Smarthome-Systeme ), Server ( alle Server, NAS usw. ), IoT ( alle IoT Geräte wie ESP8266 usw. ).
Zwischen den VLAN habe ich dann Filterregeln auf der Firewall, der die Zugriffe limitiert. IoT und Smarthome kommt z.b. nicht ins Internet, aber auf einzele Server, genauso wie mein Smarthome-Server die Geräte abfragen kann.
Das kann man dann wunderbar mit Aliases bauen.
Ich werde da bei mir aber jetzt auch mal ausmisten und viele zusammenfassen, weil das Regelwerk schon stark angewachsen ist.
Zu 1: Was das Aussperren angeht: Es gibt eine Anti-Lockout-Regel, die genau das verhindern soll.
Zu 2: Das hängt davon ab, was Deine Regeln verbieten. Du kannst ja z.B. alle Zugriffe auf die Firewall selbst erlauben und alle Zugriffe ins Internet verbieten. Damit würden Firewall-Dienste wie DNS, DHCP, NTP usw. weiter funktionieren.
Zu 3: +1 wegen der portbasierten Regeln ins Internet... die würde ich mir auch sparen:
- Du administrierst Dich zu Tode
- Was bringt's? Wenn eine Malware "nach Hause telefonieren" will, kann sie das jederzeit auch über "empfohlene" Ports wie 443 o.ä. tun. Das wird sie auch, weil sie das dann verschlüsselt tun kann.
- Es ist interessanter, Zugriffe von / auf bekannte böswillige Ziele auszuschließen, z.B. mit Firehol (https://iplists.firehol.org/). Den Rest übernimmt der Virenscanner auf Deinen Client-PCs.
Die "Anti lock-out rule" gibt es ootb nur auf dem ersten (LAN) Interface (ganz oben in der Liste der Regeln, "Automatically generated rules", nicht auf den weiteren Interfaces. Den Zugriff auf die GUI kannst du auch generell abschalten (der Webserver lauscht dann gar nicht mehr auf diesen Interfaces).
Für solche Experimente gerne ssh und/oder Konsole (VGA/seriell) bereithalten. Schadet sowieso nicht, einen physikalisch gesicherten Backup-Zugang zu haben und nutzen zu können...
Nur wenige Ports in's Interweb freizugeben würde ich nur in einem Extranetz mit wirklich schutzbedürftigen Rechnern machen. Wenn du Kiddies, Gäste etc. im selben Netz hast, wird vieles nicht wie gewohnt funktionieren...
Vielen Dank für die Unterstützung :-)
Das mit dem portbasiert werde ich dann nicht machen.
Weil da habt Ihr Recht, viel zu viele Ports und dann ändert sich das auch ständig.
Das mit dem firehol klingt interessant.
Was macht das denn genau?
Werden alle Anfragen von den IP's auf der Liste dann bei mir blokiert, bzw. eine Verbindung von meinem LAN da hin wird unterbunden? z.B. die Liste von firehol_level1 die meyergru verlinkt hat?
https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level1.netset
Die trage ich dann als Alias ein als TYP URL Table (IP) und setze dann z.B. auf dem WAN Interface eine BLOCK-Regel?
Ich muss noch mal blöd nachfragen.
Ich habe jetzt einen Alias erstellt als TYP URL Table (IP) und dann https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level1.netset als CONTENT eingetragen.
Eine Block-Regel auf WLAN und LAN erstellt wo ich diesen Alias dann verwende.
Durch diese Regel wird mir aber dann auch der DNS geblockt, folglich klappt mein Internet dann nicht mehr.
Das verstehe ich jettzt überhaupt nicht.
Wo habe ich da den Denkfehler?
Das steht dann im LOG drin:
WLAN 192.168.2.2 192.168.2.1 53
Also der AccessPoint (192.168.2.2) wird auf Port 53 (DNS) auf dem WLAN Interface (192.168.2.1) der opnsense geblockt.
Verstehe ich nicht, weil das steht ja gar nicht in der firehol Liste drin!!!
Quote from: ziegler on August 23, 2022, 06:51:12 PM
Ich habe jetzt einen Alias erstellt als TYP URL Table (IP) und dann https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level1.netset als CONTENT eingetragen.
Eine Block-Regel auf WLAN und LAN erstellt wo ich diesen Alias dann verwende.
Soweit ich weiß sind in der Level_1 Liste alle Privaten IP-Netze (192.168.0.0/16 -> also auch dein AP mit der 192.168.2.2) somit musst du entweder deine Allow DNS Regel vor die FireHol Regel stellen oder eben die Level_2 Liste nehmen
Exakt. Bei Firehol muss man sich sehr gut anschauen, was man blockt. Ich verwende z.B. https://iplists.firehol.org/?ipset=firehol_level3. Die verschiedenen Listen mit ihrem Inhalt sind links aufgeführt. Speziell mit Listen, die auch RFC1918-Bereiche enthalten, muss man vorsichtig sein.
Ich verstehe das Prinzip dahinter noch nicht.
z.B. bei der Level1 Liste.
Ich habe gesehen, ja da ist mein Privater IP Bereich drin. Deshalb wird das gesperrt. Logisch für mich.
Aber warum sollte man überhaupt Private IPs sperren. Wo ist da der Sinn drin?
So sperre ich mich ja nur selber aus.
Mein Englisch reicht da wohl leider nicht ganz aus.
Was sind denn genau die Unterschiede zwischen den Level 1 bis 4? Ich verstehe das auf der Seite leider nicht.
Es macht für manche Listen schon Sinn, RFC1918 zu enthalten, z.B. wenn es um Verbindungen vom WAN zum LAN geht - da will man das ja gerade.
Ansonsten ist auf jeder Seite doch genau erklärt, aus welchen Quellen sich die List speist, wie viele IPs da drin sind, wie hoch die Retention Time ist, wie sich die über die Welt verteilen.
Ich muss mich da mal intensiver einlesen. Dann kapier ich das hoffentlich auch :-)
Ich habe mir jetzt eine Liste gegen malware als Alias eingerichtet:
https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_webclient.netset
und bin nach dieser Anleitung vorgegangen:
https://www.heimnetz.de/anleitungen/firewall/opnsense/opnsense-ip-blocklisten-einrichten/
Habe eine floating Regel erstellt, für LAN und WLAN.
Einmal dann für eingehend und eine für ausgehend.
Bei ausgehend bin ich mir aber etwas unsicher. In der Anleitung wird geschrieben, die Liste nicht bei Source eintragen,
sondern bei Destination.
Ich hätte bei Direction einfach von IN auf OUT gestellt.
Wäre das verkehrt geswesen?
Weil meine Clients (von innen aus dem LAN/WLAN) dürfen ja nicht auf die IP's in der Liste von aussen zugreifen.
IN und OUT meinen die Verbindung vom jeweiligen Interface aus gesehen. Und man benötigt praktisch nur IN Regeln.
Verbindungen von deinem LAN ins Internet sind an diesem LAN Interface IN - sie gehen ja in die Firewall hinein und dann weiter. Und genau dort erlaubst oder blockierst du sie.
Umgekehrt sind Verbindungen vom Internet z.B. auf den selbst betriebenen Minecraft Server am WAN Interface IN. Sie kommen ja dort von draußen rein. Und genau dort erlaubt man sie. Alles andere ist auf WAN per Standard geblockt.
Den Rest macht die OPNsense bzw. deren Paketfilter automatisch richtig. Also wenn die Verbindung von deinem PC zu einem Webserver mal erlaubt ist (Regel auf LAN, IN), dann dürfen natürlich auch die Antworten des Webservers in umgekehrter Richtung zu deinem PC. Die brauchen dann keine Regel, das macht der Gerät für dich.
Hdh, Patrick
Nur wozu gibt es dann den Punkt OUT und any dort noch?
Ich muss noch mal zum Verständnis nachfragen:
Ich habe ja eine Liste als Alias eintragen, gegen malware.
Eine FW Regel habe ich so eingestellt das meine Clients nicht auf diese IPs auf der Liste zugreifen dürfen, also eine ausgehende Regel. Das ist mir auch logisch.
Dann habe ich aber auch noch eine eingehenede Regel anhand dieser Liste erstellt fürs LAN und WLAN.
War in der Anleitung auch so.
Nur jetzt verstehe ich das ja so, wenn dann kommt die Verbindung von "aussen" aus dem Internet und muss erst mal durch das WAN Interface der opnsense um dann ins LAN zu gelangen.
Das WAN Interface blockt eh standardmäßig die Verbindungen.
Also ist die eingehende Regel auf meinem LAN Interface doch nutzlos, oder?
Wenn dann auf dem WAN Interface? Aber da wird sowas ja standardmäßig schon eh geblockt?
Quote from: ziegler on August 24, 2022, 08:25:05 AM
Eine FW Regel habe ich so eingestellt das meine Clients nicht auf diese IPs auf der Liste zugreifen dürfen, also eine ausgehende Regel. Das ist mir auch logisch.
Eine Verbindung von deinem LAN ins große böse Internet kommt zuallererst zum LAN Interface herein. Deshalb LAN IN blocken.
Quote from: ziegler on August 24, 2022, 08:25:05 AM
Nur jetzt verstehe ich das ja so, wenn dann kommt die Verbindung von "aussen" aus dem Internet und muss erst mal durch das WAN Interface der opnsense um dann ins LAN zu gelangen.
Das WAN Interface blockt eh standardmäßig die Verbindungen.
Das WAN Interface blockt alle Verbindungen, die
von außen aufgebaut werden, richtig.
Aber wenn ein Client in deinem LAN etwas von $BADSERVER abruft, baut ja der Client (Browser) die Verbindung von innen auf. Per Default ist auf dem LAN ein "allow any IN", richtig? Ist die Verbindung dann mal aufgebaut, weil erlaubt, ist die "deny" Regel auf dem WAN egal. Die Firewall hat in Ihrer Zustands-Tabelle einen Eintrag, dass diese Verbindung nun erlaubt ist. Der erste Match zählt.
Also um Clients im LAN bestimmte Server zu verbieten, brauchst du eine "deny $BADSERVER IN" auf deinem LAN.
Gruß
Patrick
Vielen Dank :-)
Jetzt verstehe ich das Prinzip.
Dann habe ich es auch so richtig eingestellt auf den beiden Interfaces LAN und WLAN.
Firewall und Sicherheit ist schon ein hochkomplexes Thema wie ich finde.
Aber auch sehr interessant.
Ich versuche mich da mehr einzuarbeiten und einzulesen.