OpenWrt Router-Firewall für ein sichereres Praxisnetz

[bofh]

Die sicherste Lösung ist ein gänzlich vom Internet isoliertes Praxisnetz. Dies ist de facto nicht mehr praktikabel.

Die "großen" Praxen und Versorgungszentren halten sich eine IT-Abteilung. Aber was kann eine kleine Praxis (mit begrenztem Budget - es wird mit jedem neuen EBM immer weniger) tun?

Ein in Kleinpraxen häufig anzutreffender Fall dürfte eine Fritz!Box als Internetrouter sein. Dahinter kommt dann das LAN, das über einen seriell installierten Konnektor mit dem Praxis-Netz verbunden ist. Bei einer parallelen Konnektorinstallation sind LAN und Praxis-Netz identisch.

Es wird also ein gut konfigurerbarer Router mit Firewall zwischen LAN und Praxis-Netz (und gegebenenfalls TI-Komponenten und Praxis-Netz) benötigt. Diesen bekommt man für kleines Geld, indem man z.B. das OpenWrt Projekt (https://openwrt.org/) auf eine geeignete Hardware aufspielt. Damit lässt sich dann auch die ausgehende Kommunikation einschränken. Ich will ja schon wissen, wohin z.B. über TCP Port 443 kommuniziert wird und dies nur in den notwendigen Fällen erlauben.

Bei mir bewährt hat sich dafür der E1700 Router von Linksys (https://www.linksys.com/de/p/P-E1700/). Die Wireless-Hardware im Router wird von OpenWrt nicht unterstützt. Diese benötigt man aber für den vorgesehenen Fall auch nicht.

Die Installation des OpenWrt Images ist unproblematisch, siehe https://openwrt.org/toh/linksys/e1700 Es gibt dabei jedoch zwei kleine Fallen.

1. Es muss zuvor ein Downgrade der Original-Firmware auf Version 1.0 durchgeführt werden.
Die Firmware-Datei FW_E1700_v1.0.00.081_20131220.bin mit der md5 Prüfsumme 68f9f63de22d508bdd699a749bcdc2d0 kann bei Linksys runtergeladen werden: https://downloads.linksys.com/downloads ... 131220.bin

2. Entgegen der Angabe auf der OpenWrt Seite wird nicht das sysupgrade image sondern das squashfs-factory image bei der erstmaligen Umstellung auf OpenWrt installiert.
http://downloads.openwrt.org/releases/1 ... actory.bin

Für das Einrichten der Firewall und der Software kommt man um einige Kommandozeileneingaben mittels SSH nicht herum. Nur mit der Web-Oberfläche kommt man nicht weit genug.


Falls Interesse besteht, kann ich gerne weiter berichten.

[c-it]

Das ist prinzipiell eine gute Sache. Aber eine https-Whitelist zu pflegen kann aufwändig sein! Heute ist fast
jede Seite per https erreichbar, von Microsoft-, Antivirensoftware- und was-weiß-ich-noch-Updates ganz
zu schweigen. Den erhofften Nutzen den Verkehr ins KV-Safenet zu sehen gibt es so nicht: Der Tunnel
beginnt/endet in der Kocobox und geht nicht über den Router.
Aber man kann sehr schön OpenVPN in den Router integrieren, falls man von Zuhause mal was machen will ...

Schönen Abend
c-it

[bofh]

Das mit der Whitelist kann man auch etwas weiter fassen, wenn man Wildcards benutzt. Wenn man z.B. microsoft.com und windowsupdate.com inclusive aller dazugehörigen Subdomains zulässt, dann klappt das Windows-Update. Das ist jetzt zwar nicht die Minimallösung, aber der Aufwand ist noch tragbar. Generelles surfen im I-Net soll ja gerade verhindert werden.

Man kann das interne Netz in 3 Segmente teilen: LAN, TI-Infrastruktur (= Kartenleser + Konnektor) und Praxis-Netz. Dann hätte man auch das KV-Safenet (und gegebenenfalls die SIS) im Griff. Der Router sollte auch 3 Segmente problemlos bedienen können. Ich habe es aber noch nicht ausprobiert.

[nmndoc]

Also gleich vorweg - ich habe mich zu dem Themenkomplex ja schon mehrfach und ausführlich ausgelassen.
Kurz gesagt: Ich halte die Lösung für die meisten Praxen nicht für geeignet*. Wenn es für Sie eine gute Lösung ist, ok.

Randbemerkungen:
"Generelles surfen" für die PCs nicht zu erlauben würde ja relativ problemlos mti jedem Router oder komfortabel via FritzBox gehen.
Updates können die PCs vom Server beziehen, der ZB als Einziger raus darf.
"Günstige DMZ" bzw Segmentierung geht auch mit zwei Routern, hintereinander.
*.microsoft etc auf die Whitelist setzen: hab in der Doku nicht auf Anhieb erkennen können, ob DNS-Objekte direkt unterstützt werden. Pflege vom IP-Listen dürfte gerade bei solchen Anbietern, die gerne auch aus Gründen des Lastausgleichs "Horden" von IPs sehr dynamisch verwenden, sehr aufwändig und fehleranfällig werden.

*) Nicht geeignet weil eine derartige Bastellösung mit SSH, VLAN, Trick hier und da ... das Wissen der meisten Praxisbetreiber übersteigen dürfte. Am Ende ist man sicher froh, wenn man es "irgendwie" doch zum Laufen gebracht hat + nie wieder anfassen. Das ist aber genau das Gegenteil von "Sicherheit".
Ich würde empfehlen, zu einer professionellen Lösung zu greifen - angepaßt an das Budget und den Bedarf. Das Ganze dann vorzugsweise von einem Dienstleister Ihres Vertrauens einrichten und warten lassen.

[bofh]

Ich stimme Ihnen zu: Diese Lösung ist für die meisten Praxen nicht geeignet. Einmal einrichten und dann vergessen funktioniert hier nicht. Softwareupdates müssen regelmäßig (von Hand) vorgenommen werden. Es hat schon einen Grund, warum eine professionelle Lösung nicht für einen Apfel und ein Ei zu bekommen ist.

Schadsoftware im Praxisnetz oder auf dem Server (so vorhanden) soll gerüchteweise hin und wieder mal vorkommen. Ich will (so gut es geht) verhindern, dass diese sensible Daten nach draußen schleusen kann. Ein Whitelisten der erlaubten Kommunikationspartner erscheint mir daher (als ein Baustein der Maßnahmen) geboten.

Für mich besteht das wesentliche Problem des Whitelistens nicht in dem "Wie mache ich das?" sondern im "Was muss ich freigeben?". Auch wenn ich einen professionellen Router kaufe, benötige ich dennoch diese Information. URL-basiert Domains und Subdomains freizugeben ist nicht das Thema.

Woher bekommt man die Information, welche Domains oder auch IP-Adressen (für die es keine URL gibt) z.B. für TCP Port 443 freizugeben sind? TurboMed, CGM-Connect, CGM-Remote-Support (AnyDesk), IFAP, Click-Doc und Konsorten lassen freundlich grüssen. Jedesmal den Netzwerkverkehr zu analysieren kann nicht die Lösung sein. Nach dem nächsten S/W-Update ist möglicherweise eine andere IP-Adresse hart codiert.

[nmndoc]

Für mich besteht das wesentliche Problem des Whitelistens nicht in dem "Wie mache ich das?" sondern im "Was muss ich freigeben?". Auch wenn ich einen professionellen Router kaufe, benötige ich dennoch diese Information. URL-basiert Domains und Subdomains freizugeben ist nicht das Thema.

Woher bekommt man die Information, welche Domains oder auch IP-Adressen (für die es keine URL gibt) z.B. für TCP Port 443 freizugeben sind? TurboMed, CGM-Connect, CGM-Remote-Support (AnyDesk), IFAP, Click-Doc und Konsorten lassen freundlich grüssen. Jedesmal den Netzwerkverkehr zu analysieren kann nicht die Lösung sein. Nach dem nächsten S/W-Update ist möglicherweise eine andere IP-Adresse hart codiert.

Also - ein Router ist eben keine Firewall. Und Firewall ist auch nicht gleich Firewall. Das ist eben genau der Punkt, wenn man mehr benötigt als entweder Extern > Intern > Drop und Intern > Extern > Any bzw zB nur der Server darf ins Internet und die PCs nicht.

Sofern es keinen DNS-Namen gibt (DNS-Name ist nicht gleich URL - da URL ich ja auf das Protokoll - also http/https etc - bezieht) landet man eben bei den IPs. Gute Hersteller dokumentieren das ohnehin, was freigeschaltet werden muss. Dann gibt es noch Firmen wie CGM - da muss man evtl nachfargen ("das weiß ich nicht ... nur die Anwenderhotline ... an den Servicepartner" - und wieder zurück) oder selbst rausfinden. Normale Hersteller werden tunlichst nicht mit hart-codierten IPs arbeiten und wenn doch - die möglichst niemals ändern. Dann gibt es noch so Hersteller wie CGM ...
Ja - so ist das eben. Bequem ist nicht gleich IT-Sicherheit. Aber wenn ich zB die Möglichkeit habe, auf DNS- und Anwendungsebene Freischaltungen zu machen (zB https typ "Windows-Update" oder Ziel *microsoft.com; Traffic vom Typ Anydesk zu Internet; etc) tue ich mich einfacher und "sehe" auch deutlich mehr.