Meine ersten Schritte mit MikroTik RouterOS (Teil 4)

Leser dieses Blogs wissen, dass ich ein bekennender Freund von OpenWRT bin. Doch ein Blick über den Tellerrand schadet ja nicht – und so habe ich mich die letzten Wochen auf Empfehlung zweier Freunde hin näher mit RouterOS von MikroTik befasst und eine Basiskonfiguration aufgesetzt, die ich in der folgenden Serie näher vorstellen möchte.

Teil 4 befasst sich mit der Einrichtung der Firewall.

Die Lektüre von Teil 1, Teil 2 und Teil 3 wird empfohlen, da die folgende Anleitung darauf aufbaut. Auch nach einigen Wochen ist RouterOS für mich immer noch Neuland – aber gerade beim Thema Firewall sollte man sprichwörtlich nicht mit dem Feuer spielen, weswegen die Nutzung der gezeigten Firewall-Regeln auf eigene Gefahr geschieht. Über konstruktive Rückmeldungen und Hinweise auf Fehler freue ich mich immer!

Die hier genannten Befehle sind mit RouterOS bis einschließlich Version 6.40.x getestet. Ab Version 6.41 ändert sich insbesondere die Konfiguration der Bridges, sodass die Kommandos ggf. angepasst werden müssen. Einen Überblick über die Neuerungen gebe ich in einem separaten Blogposting.

Einführendes

Zwar haben wir in Teil 1 der Serie unser Gerät durch die Installation des entsprechenden Pakets schon für IPv6 vorbereitet, allerdings machen wir vorerst noch keinen Gebrauch davon. Einige Konzepte von IPv6 unterscheiden sich doch deutlich von IPv4 und auch die Firewall kann nicht 1:1 übernommen werden. Deswegen werde ich dem Thema IPv6 einen eigenen Blogpost widmen.

Im Folgenden unterscheide ich zwischen zwei Gerätearten – Switches und Access Points auf der einen und Router auf der anderen Seite. Der Unterschied zwischen den beiden Klassen ist, dass der Router sowohl nach innen als auch nach außen gerichtete Ports kennt (Internet und lokales Netzwerk) und die Firewall spezielle Regeln für Paketweiterleitungen braucht, während Switches und Access Points in meinem Setup nur das interne Netzwerk kennen und daher mit einer einfacheren Firewall auskommen.

Eine Firewall nutze ich also auch bei internen Geräten. Auch, wenn wir in Teil 3 der Serie schon alle unerwünschten Dienste deaktiviert haben, sollten interne Komponenten dennoch über eine Firewall geschützt werden. Das bewahrt zum einen davor, bei falschen Konfigurationen mehr Ports zu öffnen als nötig – und zum anderen wächst dank WLAN-, Smart Home- und Drittgeräten das eigene Netzwerk ständig, somit auch die Angriffsmöglichkeit auf Netzkomponenten.

Kettenreaktion

Wer sich etwas mit iptables auskennt, wird auch in RouterOS gängige Konzepte wiederfinden. Die Firewall besteht aus mehreren Ketten (Chains), am relevantesten sind:

• die INPUT-Chain: alle ankommenden Pakete, die jedoch nicht zur Weiterleitung an andere Geräte im eigenen Netz bestimmt sind, also nicht weitergeroutet werden
• die OUTPUT-Chain: alle ausgehenden Pakete, die jedoch nicht von anderen Geräten im eigenen Netz zur Weiterleitung geschickt wurden, also nicht nach außen geroutet werden
• die FORWARD-Chain: alle Pakete, die von oder an Geräte im eigenen Netz zur Weiterleitung geschickt wurden, d.h. geroutet werden
• die NAT-Chain: Regeln zur Umschreibung von IP-Adressen für NAT (Network Address Translation)

Am Switch und Access Point sind nur die INPUT- und OUTPUT-Chain relevant, FORWARD und NAT spielen hier im Normalfall keine Rolle. Zwar leitet gerade ein Switch ja durchaus Pakete weiter, allerdings erst einmal nicht geroutet über die Firewall.

Das Abarbeiten des Regelwerks geht jeweils von oben nach unten bis hin zur ersten zutreffenden Regel. Die Standard-Regel für jede Kette wird deshalb ganz am Schluss definiert und ist entsprechend weitreichend – wenn keine andere Einstellung einschlägig ist, dann sollte diese letzte Regel greifen. Am Schluss steht bei mir immer eine Verbotsregel, d.h. alles, was vorher nicht explizit erlaubt ist, das ist verboten.

Beim Einrichten der Firewall kann man sich schnell selbst aussperren. Durch den Layer-2-Zugriff (MAC-Winbox) ist aber auch in solchen Fällen ein Zugang möglich, in denen die Firewall auf IP-Ebene sperrt. Ich empfehle daher, die Konfiguration immer lokal vorzunehmen und nicht übers Internet, denn von dort funktioniert dieser Rettungsanker nicht.

Firewall für Switches und Access Points

Am Switch und Access Point ist das Ziel, die eingehenden Verbindungen (INPUT-Chain) auf das Notwendige zu beschränken, keine Weiterleitung zu erlauben (FORWARD-Chain) und nahezu alle ausgehenden Pakete zuzulassen (OUTPUT-Chain).

Zuerst erlauben wir bereits bestehende Verbindungen – die Regel steht ganz oben, um das ressourcenaufwändige Durchspielen der gesamten Firewall für jedes einzelne Paket zu vermeiden. Ist eine Verbindung einmal als erlaubt klassifiziert, dürfen dazugehörige Pakete frei passieren. Zudem verbieten wir ungültige Pakete:

/ip firewall filter add chain=input action=accept connection-state=established,related comment="accept established,related"

/ip firewall filter add chain=input action=drop connection-state=invalid comment="drop invalid"

Anschließend werden bestimmte ICMP-Befehle durchgelassen (“Ping”). ICMP stellt eine Vielzahl von Optionen bereit, wir lassen jedoch nur einige wenige zu. Diese Regel ist schon etwas restriktiver – nur solche Pakete sind erlaubt, deren Quelle und deren Ziel im lokalen Netzwerk (192.168.x.y) liegen, denn wenn es sich um ein internes System handelt, dann darf von außen gar kein ICMP-Paket dort ankommen. Ob das Ganze nicht zu restriktiv ist, muss ich selbst erst noch in der Praxis testen:

/ip firewall filter add chain=input action=accept protocol=icmp icmp-options=0:0 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept ICMP echo reply"

/ip firewall filter add chain=input action=accept protocol=icmp icmp-options=3:0-1 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept ICMP destination unreachable"

/ip firewall filter add chain=input action=accept protocol=icmp icmp-options=8:0 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept ICMP echo request"

/ip firewall filter add chain=input action=accept protocol=icmp icmp-options=11:0 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept ICMP time exceeded"

Danach erlauben wir den Zugriff für die Fernwartung- SSH, die Weboberfläche und WinBox sind schon aus Teil 3 der Serie bekannt:

/ip firewall filter add chain=input action=accept protocol=tcp dst-port=22 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept SSH"

/ip firewall filter add chain=input action=accept protocol=tcp dst-port=443 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept HTTPS"

/ip firewall filter add chain=input action=accept protocol=tcp dst-port=8291 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept WinBox"

Als letzte Regel für die INPUT-Chain verwerfen (drop) wir Pakete, die nicht explizit erlaubt sind – theoretisch können diese auch zurückgewiesen werden (reject), was der Gegenstelle eine schnellere Rückmeldung liefert, ich bevorzuge aber das Verwerfen:

/ip firewall filter add chain=input action=drop comment="drop"

Die FORWARD-Chain ist schnell erledigt, denn alle Pakete, die zur Weiterleitung bestimmt sind, sollen ebenfalls verworfen werden:

/ip firewall filter add chain=forward action=drop comment="drop"

Auch die OUTPUT-Chain benötigt nur eine Regel – es ist alles erlaubt, außer ungültige Verbindungen:

/ip firewall filter add chain=output action=drop connection-state=invalid comment="drop invalid"

Firewall für Router

Die Firewall für den Router folgt ähnlichen Konzepten, muss aber wie eingangs erwähnt zwischen Internet und lokalem Netzwerk unterscheiden und auch die FORWARD- und NAT-Chain berücksichtigen.

Zwei Hinweise vorab:

• Bislang habe ich diese Firewall nur auf einem dedizierten Router getestet, ohne integriertes WLAN. Vermutlich genügt es für den Betrieb an einem Kombigerät, ether2 einfach durch bridge1 zu ersetzen, um sowohl die Netzwerkanschlüsse fürs interne Netz als auch das WLAN zu berücksichtigen – testen konnte ich das jedoch noch nicht.
• Zum anderen gehe ich im Beispiel davon aus, dass der Internetzugang per DHCP über ether1 erfolgt, beispielsweise via Kabelmodem. Bei einer PPPoE-Verbindung, beispielsweise via DSL, muss das Interface ggf. angepasst werden, damit die Regeln auch greifen. Das konnte ich bislang allerdings noch nicht testen.

Adressliste pflegen

Zuerst erstellen wir eine Adressliste mit privaten IP-Adressen, die nicht routebar sind (“Bogons”). Solche sollten zwar schon gar nicht vom Provider zum heimischen Internetzugang geroutet werden, auf jeden Fall soll sie unser Gerät am entsprechenden Interface aber umgehend verwerfen. Als Basis nutze ich dabei den entsprechenden Wikipedia-Artikel. Je nach lokalem Netzaufbau muss diese Liste ggf. noch gekürzt werden – ich gehe davon aus, dass RouterOS direkt eine öffentliche IPv4-Adresse bezieht und kein doppeltes NAT, Carrier Grade NAT o.ä. vorhanden ist. Die Liste erstellen wir mit:

/ip firewall address-list add list=bogons address=0.0.0.0/8
/ip firewall address-list add list=bogons address=10.0.0.0/8
/ip firewall address-list add list=bogons address=100.64.0.0/10
/ip firewall address-list add list=bogons address=127.0.0.0/8
/ip firewall address-list add list=bogons address=169.254.0.0/16
/ip firewall address-list add list=bogons address=172.16.0.0/12
/ip firewall address-list add list=bogons address=192.0.0.0/24
/ip firewall address-list add list=bogons address=192.0.2.0/24
/ip firewall address-list add list=bogons address=192.168.0.0/16
/ip firewall address-list add list=bogons address=198.18.0.0/15
/ip firewall address-list add list=bogons address=198.51.100.0/24
/ip firewall address-list add list=bogons address=203.0.113.0/24
/ip firewall address-list add list=bogons address=240.0.0.0/4

INPUT-Chain

Die ersten beiden Regeln der INPUT-Chain sind analog zum Beispiel von weiter oben – bestehende Verbindungen und dazugehörige Pakete dürfen passieren, ungültige Pakete werden verworfen:

/ip firewall filter add chain=input action=accept connection-state=established,related comment="accept established,related"

/ip firewall filter add chain=input action=drop connection-state=invalid comment="drop invalid"

Auch die ICMP-Regeln sind dem vorhergehenden Beispiel entlehnt, nur dass diesmal noch eine weitere Unterteilung nach Netzwerkschnittstellen und Adressen vorgenommen wird. Erlaubt sind wiederum bestimmte ICMP-Pakete, die vom Internet (ether1) hereinkommen, allerdings nur dann, wenn weder Quell- noch Zieladresse im lokalen Netzwerk liegen:

/ip firewall filter add chain=input action=accept in-interface=ether1 protocol=icmp icmp-options=0:0 src-address=!192.168.0.0/16 dst-address=!192.168.0.0/16 comment="accept ICMP echo reply->WAN"

/ip firewall filter add chain=input action=accept in-interface=ether1 protocol=icmp icmp-options=3:0-1 src-address=!192.168.0.0/16 dst-address=!192.168.0.0/16 comment="accept ICMP destination unreachable->WAN"

/ip firewall filter add chain=input action=accept in-interface=ether1 protocol=icmp icmp-options=8:0 src-address=!192.168.0.0/16 dst-address=!192.168.0.0/16 comment="accept ICMP echo request->WAN"

/ip firewall filter add chain=input action=accept in-interface=ether1 protocol=icmp icmp-options=11:0 src-address=!192.168.0.0/16 dst-address=!192.168.0.0/16 comment="accept ICMP time exceeded->WAN"

Dieselben ICMP-Pakete sind auch vom lokalen Netzwerk (ether2) erlaubt, aber nur gerade dann, wenn sie lokale Adressen zum Gegenstand haben:

/ip firewall filter add chain=input action=accept in-interface=ether2 protocol=icmp icmp-options=0:0 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept ICMP echo reply->LAN"

/ip firewall filter add chain=input action=accept in-interface=ether2 protocol=icmp icmp-options=3:0-1 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept ICMP destination unreachable->LAN"

/ip firewall filter add chain=input action=accept in-interface=ether2 protocol=icmp icmp-options=8:0 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept ICMP echo request->LAN"

/ip firewall filter add chain=input action=accept in-interface=ether2 protocol=icmp icmp-options=11:0 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 comment="accept ICMP time exceeded->LAN"

Unser Router arbeitet zugleich als DNS-Server, der die Anfragen an den Provider weiterleitet. DNS wird über Port 53 via UDP und TCP angeboten und soll ausschließlich aus dem lokalen Netz erreichbar sein:

/ip firewall filter add chain=input action=accept in-interface=ether2 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 protocol=udp dst-port=53 comment="accept DNS-UDP->LAN"

/ip firewall filter add chain=input action=accept in-interface=ether2 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 protocol=tcp dst-port=53 comment="accept DNS-TCP->LAN"

Die Administration per WinBox, SSH und HTTPS soll ebenfalls nur aus dem lokalen Netzwerk erreichbar sein:

/ip firewall filter add chain=input action=accept in-interface=ether2 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 protocol=tcp dst-port=22 comment="accept SSH->LAN"

/ip firewall filter add chain=input action=accept in-interface=ether2 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 protocol=tcp dst-port=443 comment="accept HTTPS->LAN"

/ip firewall filter add chain=input action=accept in-interface=ether2 src-address=192.168.0.0/16 dst-address=192.168.0.0/16 protocol=tcp dst-port=8291 comment="accept WinBox->LAN"

Schlussendlich weisen wir die Firewall an, alle anderen Pakete in der INPUT-Chain zu verwerfen:

/ip firewall filter add chain=input action=drop comment="drop"

FORWARD-Chain

In der FORWARD-Chain wird konfiguriert, wie der Router mit weitergeleiteten Paketen umgehen soll – sprich: das eigentliche Routing. Analog zur INPUT-Chain werden gleich zu Anfang alle Pakete erlaubt, die zu einer gültigen Verbindung gehören. Dafür nutzen wir folgende Doppelregel:

/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related comment="fasttrack established,related"

/ip firewall filter add chain=forward action=accept connection-state=established,related comment="accept established,related"

Für Details zur genutzten Hardwarebeschleunigung fürs Routing empfehle ich die entsprechende Seite im MikroTik-Wiki.

Der nächste Regelsatz legt fest, welche Verbindungen nicht erlaubt sind:

/ip firewall filter add chain=forward action=drop connection-state=invalid comment="drop invalid"

/ip firewall filter add chain=forward action=drop in-interface=ether1 src-address-list=bogons comment="drop bogons<-WAN"

/ip firewall filter add chain=forward action=drop in-interface=ether1 connection-state=new connection-nat-state=!dstnat comment="drop ->WAN w/o DSTNAT"

/ip firewall filter add chain=forward action=reject out-interface=ether1 protocol=tcp dst-port=25 comment="reject SMTP->WAN"

Verboten sind ungültige Pakete, Pakete von den vorgenannten “Bogons” (d.h. privaten und nicht routebaren IP-Adressen), eingehende Verbindungen ins LAN ohne NAT und – aus Sicherheitsgründen und zur Vermeidung von Spam – ausgehende Verbindungen auf Port 25 (SMTP). Diese werden direkt rejected und nicht gedroppt. Wer einen eigenen Mailserver hinter seinem Router betreibt, der muss die letzte Regel ggf. anpassen.

Erlaubt hingegen sind Pakete aus dem internen Netzwerk ins Internet, sofern die Adressen stimmen:

/ip firewall filter add chain=forward action=accept in-interface=ether2 out-interface=ether1 src-address=192.168.0.0/16 dst-address=!192.168.0.0/16 comment="accept LAN->WAN"

Alle anderen Verbindungen werden verworfen:

/ip firewall filter add chain=forward action=drop comment="drop"

OUTPUT-Chain

Die OUTPUT-Chain wird analog zum Beispiel weiter oben konfiguriert – alle Verbindungen sind erlaubt, es sei denn, sie sind ungültig:

/ip firewall filter add chain=output action=drop connection-state=invalid comment="drop invalid"

NAT-Chain

Bis jetzt sind zwar zahlreiche Firewall-Regeln in Kraft, die lokalen Clients haben aber noch keinen Zugang zum Internet. Zum einen, weil noch gar kein Internetzugang hergestellt wurde, zum anderen aber auch, weil NAT noch nicht aktiv ist. NAT steht für Network Address Translation und ist das Umschreiben bzw. Übersetzen von internen IP-Adressen.

Der Hintergrund ist einfach: Von seinem Internetprovider erhält man in der Regel genau eine öffentliche IPv4-Adresse, mit der jedoch das gesamte interne Netzwerk angebunden werden soll. Intern werden IP-Adressen wie beispielsweise 192.168.x.y vergeben – die schon mehrfach erwähnten nicht routebaren, privaten Adressen. Um nun trotzdem mit jedem einzelnen Client eine Verbindung nach draußen aufbauen zu können muss der Router “natten”, d.h. die privaten Adressen auf die öffentliche umschreiben und sich zugleich merken, welche Verbindung für welchen Client bestimmt ist. Dafür benötigen wir folgende Regel:

/ip firewall nat add chain=srcnat action=masquerade out-interface=ether1 src-address=192.168.0.0/16 dst-address=!192.168.0.0/16 comment="masquerade LAN->WAN"

Das war’s! Unsere erste Firewall ist fertig!

Ausblick

Die obige Basis-Firewall zeigt nur einen Bruchteil der Fähigkeiten von RouterOS – so lassen sich beispielsweise einzelne Protokolle filtern, Bandbreitenbegrenzungen einführen und vieles mehr, das ich vielleicht in einem späteren Blogposting beleuchten werde.

Was uns jetzt noch fehlt, das ist die eigentliche Internetverbindung, d.h. die “Einwahl” sowie die Konfiguration des lokalen DHCP- und DNS-Servers. Dem widmen wir uns dann in Teil 5 der Serie.