Einfache Gebrauchsanleitung der Interfaces und Regeln für OPNsense

[stefan21]

Hallo,

ich bin Umsteiger vom IPCop und tue mich etwas schwer, die Logik von OPNsense zu verstehen.

Wie wird z. B. ausgehender Verkehr definiert? Müssen dazu nur Regeln für das LAN-Interface definiert werden? Oder auch für das WAN-Interface? Was genau macht Portforwarding, was genau ist Outbound, müssen dazu zusätzliche Regeln definiert werden? Usw.

In der Doku sind Fallbeispiele sehr gut erklärt. Was mir jedoch fehlt, ist eine Art Bedienungsanleitung, die die grundlegende Logik von OPNsense erklärt. Wenn man so will, OPNsense für Dummies. Gibt es so etwas?

Vielen Dank für jede Info.
stefan

[fabian]

Ausgehend (OUT) ist standardmäßig alles erlaubt - gefiltert wird, was bei einer Schnittstelle hinein kommt (IN). Ausnahme: .Floating rules - da kann man das überschreiben!
OUT wird generell nur SNAT durchgeführt (außer du stellst was um) oder verwendest Floating rules, die da noch greifen.
DNAT wird ausgeführt, bevor die Filterregeln (IN) angewendet werden.

[chemlud]

Hi!

Einfachster Fall, 2 Interfaces:

WAN

LAN

Grundregel: sense überprüft jedes Paket, welches von einem Netz in ein anderes will, mit den Regeln für das Interface, wo es ANKOMMT. Pakete aus dem Inet: WAN interface-Regeln gelten (Standard: alles VERBOTEN), Pakete aus deinem Netzwerk: LAN-Regeln gelten (Standard alles erlaubt).

Grundregel: was nicht erlaubt ist, ist verboten (es gibt sozusagen eine unsichtbar DENY any any Regel). Daher bei den WAN Regeln steht nix, bei den LAN Regeln eine "ALLOW any any". Regeln werden VON OBEN NACH UNTEN in der Liste abgearbeitet, bis eine passende Regel (kann allow oder deny sein) gefunden ist, und entsprechend bearbeitet.

Folgendes vorgehen:

Schreibe ein paar einfache Regeln für's LAN und deaktiviere die ALLOW any any Regel:

(Geschmackssache: bei mir ganz oben: Deny any any IPv6, dann bleibt der ganze IP6 spam schon mal bei mir lokal und funkt nicht nach Hause)

Allow any any PORT 80

dann können alle Rechner im LAN mit HTTP in'S Netz


Dann machst du noch eine solche Regel für HTTPS und für eMail (SMTP, und was du für deinen Provider zum Abrufen brauchst, z.B. IMAPs).

Dann hast du schon mal viel Müll weggehauen, der aus deinem LAN einfach so nach Hause funkt. Wenn du willst, blockst du z.B. Windows Telemetry (machst ein Alias für bekannte MS-Server und eine Block-Regel dazu auf dem LAN-Interface).

Wenn es klagen gibt, dass Anwendung XYZ nicht geht, schaust du in deinem Firewall-Protokoll (Logging für die Default deny rule aktiviert!) und siehst, auf welchem Port das Programm raus in's Inet will. Dann kannst du den freigeben (auf LAN), wenn du willst ;-)

Fragen? :-)

[stefan21]

@fabian und chemlud,

vielen Dank für die Info's.

Gut, ich habe die allow any Regel im LAN deaktiviert, und ein paar einfache Regeln definiert.

Im LAN sind 2 Server die jetzt keinen Datenverkehr mehr dem DNS der OPNsense haben. Port 53 ist ja nicht erlaubt. Verstehe ich richtig, dass ich eine Regel definieren muss, die als Quelle die 2 Server, und als Ziel die OPNsense, Quell- und Zielport jeweils 53 haben muss? Auch die Clients haben als DNS die OPNsense. Also auch für die eine Regel? Oder eine DNS-Regel für das LAN?

[fabian]

würde auf lan folgende Regel erstellen

pass
protocol tcp/udp
from lan net:any
to self:dns

MfG

Fabian

[stefan21]

Hallo Fabian,

vielen Dank für den Input.

Ich habe jetzt mal folgende Regel definiert:

1. einen Alias (lan_datenverkehr), in dem ich alle Ports für den internen LAN-Datenverkehr eingegeben habe. Darunter ist auch der Port 53 (DNS).

2. IPv4 TCP/UDP    LAN net    *    LAN net    lan_datenverkehr     *       Datenverkehr im LAN

Ist das so o.k.? Auf jeden Fall scheint es zu funktionieren.

stefan

[stefan21]

Beim Einrichten eines WEB-Proxys bin ich auf eine Ungereimtheit gestossen:

https://docs.opnsense.org/manual/how-tos/cachingproxy.html

Weshalb soll eine https://docs.opnsense.org/manual/how-tos/cachingproxy.html#firewall-rule-no-proxy-bypass

Firewall Rule No Proxy Bypass für das https-Protokoll eingerichtet werden, wenn der SSL-Proxy in dem HOW-TO nicht aktiviert/eingerichtet wird?

Für den http-Port macht es ja Sinn... oder verstehe ich da was falsch?

[fabian]

Das passt schon so:

Wenn du mit einem HTTP-Proxy (explizit) raus willst, musst du bei anderen Protokollen mit CONNECT einen TCP-Tunnel anfordern.
Bei HTTPS baust du also eine HTTP-Verbindung zum Proxy auf und fragst ihn, ob er dich zum eigentlichen host auf Port 443 verbinden kann. Wenn er Ja sagt, kommt ein ganz normaler TLS-Handshake und die Verbindung ist (hoffentlich) Ende-zu-Ende (Dein Computer zu Webserver) verschlüsselt. Der Proxy kann in diesem Fall nicht mitlesen.

[stefan21]

Hallo fabian,

danke für Deine Hilfe. Aber irgendetwas ist bei mir falsch bzw. funktioniert nicht. Die Regeln sehen wie folgt aus:

Achtung: Im Default ist im LAN nichts erlaubt.

1. Web Proxy --> Forward Proxy --> Enable Transparent HTTP proxy angekreuzt. Und dann Add a new firewall rule

2.) Der Automatismus hat folgende Regel angelegt:
Firewall: NAT: Port Forward
LAN    TCP    LAN net    *    *    80 (HTTP)    127.0.0.1    3128    redirect traffic to proxy

und

3.) Firewall: Rules --> LAN
IPv4 TCP    LAN net    *    127.0.0.1    3128    *       NAT redirect traffic to proxy    

Die Clients können weder mit dem http noch mit dem https Protokoll surfen. Die Firewall blockt den Port 3128.

Was mache ich da blosß falsch?

[stefan21]

Mit folgender Änderung funktioniert das Surfen sowohl auf http als auch auf https:

Firewall: NAT: Port Forward
LAN    TCP    LAN net    *    *    80 (HTTP)    192.168.XX.1    3128    redirect traffic to proxy

und

Firewall: Rules --> LAN
IPv4 TCP    LAN net    *    192.168.XX.1    3128    *       NAT redirect traffic to proxy

wird automatisch mit geändert. Ich habe die IP 127.0.0.1 mit der der Firewall ersetzt.

Ist das so o.k., und macht das Sinn?

Vor allem unter Berücksichtigung, dass beim Einrichten des FTP-Proxys https://forum.opnsense.org/index.php?topic=3868.0 die 127.0.0.1 eingetragen wird, und da funktioniert es mit der IP des localhost.

[monstermania]

Moin Stefan,
schau mal in den Fred rein: https://forum.opnsense.org/index.php?topic=4230.msg15666#msg15666
Da sind eigentlich schon sehr viele Fragen beantwortet worden.

Dann empfehle ich Jedem Einsteiger das folgende Tutorial: https://www.administrator.de/wissen/preiswerte-vpn-f%C3%A4hige-firewall-eigenbau-fertigger%C3%A4t-149915.html
Da finden sich extrem viele nützliche Hinweise auch und gerade, was man generell so mit einer Firewall machen kann. Vieles davon lässt sich auch 1zu1 für die OPNSense umsetzen.

Gruß
Dirk

[stefan21]

Hallo Dirk,

vielen Dank für den Input. Ich lese mir das durch.

stefan

[Oxygen61]

So eine Gebrauchsanleitung fehlt leider wirklich für den Good Practice den wirklich der überwiegende Teil der OPNsense Nutzer zu Hause hat (vielleicht?). Wahrscheinlich sowas ähnliches wie hier:

[Internet] - VDSL2 Modem - [WAN] OPNsense
                                                          |             |
                                                      [LAN]     [WLAN]
                                                          |                |
                                        Clients mit oder         Access Point
                                        ohne VLAN Switch

Ich meine man findet sich schon zurecht irgendwie. Aber wenn man mit keinerlei Vorkenntnissen vorbei kommt,
kann ich mir vorstellen, dass das Übermaß an Optionen überwältigend sein kann.

Schöne Grüße,
Oxy

[stefan21]

Hallo Oxygen61,

ich habe den IPCop in der Firma durch die OPNsense ersetzt. Daher gibt es da noch ein wenig mehr Peripherie. WLAN nicht, aber wenn man restriktiv an die Sache herangeht, dann muss man erstmal lernen, was da so für Protokolle im LAN herum schwirren, und welche Ports zum Arbeiten tatsächlich benötigt werden.

Heute morgen habe ich z. B. gelernt, dass der Port 3000 sehr wichtig ist. Wenn ich erstmal alles verbiete, dann geht natürlich auch das Online-Banking nicht... Dann gibt es Netzwerkdrucker mit IPP, ClamAV auf mehreren Servern, die jetzt kein Update mehr hinter dem Proxy können, usw.

Tja, es gibt ja mittlerweile jede Menge Literatur im EDV-Bereich für Dummies. Ich würde sofort so ein kleines Büchlein kaufen.

stefan

[Oxygen61]

Hey stefan21,

(Weiß gerade nicht ob das hier schon gesagt wurde oder in einem anderen Thread) aber du kannst einfach ans Ende deines Regelwerks ein DENY ANY ANY setzen und das Loggen dieser Regel aktivieren. Schaust du dann bei "Log Files" beim "Firewall" Reiter nach und klickst dort auf die Kreuze kommen Meldungen hoch, die sagen welche Regel angewendet wurde. Steht da "DENY ANY ANY" weißt du, welche Protokolle durch die letzte Regel weggehascht werden.
Aber das hast du sicher eh schon gemerkt.

Ich glaube heutzutage hat das wirklich nichts mehr mit "dummies" zu tun.
Die Vielfalt der Möglichkeiten werden größer. Bezogen auf die Security, könnte man für jeden kleinen Aspekt zusätzlich zur eigentlichen Funktion noch ein Buch raus bringen.
Wer will die denn alle lesen?

Schöne Grüße,
Oxy