KoCoBox parallel an Fritz!Box

[lcer]

1) mein Router ist nicht aus China.

2) was taugt ein Zertifikat der Gematik? Ich weiß dann, dass das Gerät genau so funktioniert wie die Gematik es will. Wer hat gleich nochmal 51% übernommen?

3) wir sind verantwortlich dafür, dass unsere Patientendaten weder Kriminellen, noch behördlichen Einrichtungen in die Hände fällt.

4) Haben Die denn Daten, dass Ihre Daten besser gesichert sind, wenn ein statt einer aktuellen Firewalllösung und sicherem Netzdesign die Gematikbox die Absicherung übernimmt?


Grüße

lcer

[danspie]

zu 3) wir sind gesetzlich verpflichtet die TI einzuführen - ob ich anderer Meinung bin, als der Gesetzgeber ist unerheblich. Dafür trägt dann der Gesetzgeber die Verantwortung, wenn auf diesem Wege Daten ausspioniert werden.
zu 4) nochmals Entschuldigung, aber sie behaupten doch, dass die Daten in der seriellen Installation schlechter geschützt sind als in der paralellen und fordern jetzt von mir Belege, dass dies nicht so ist - in meiner Welt ist es immer noch so, dass derjendige, der eine Behauptung aufstellt den Beweis oder zumindest Anhalt dafür schuldet - aber ich bin über 50 und damit wohl zu alt um die heutige Welt zu verstehen!
In der aktuellen Diskussion über unsicheren Schutz der Daten in Praxen geht es meines Wissens nur um parallele Installationen - klar kann man eine parallele Installation ausreichend sicher machen, aber in vielen Praxen wird halt geschlampt. Und in dieser Hinsicht sollte man nicht mit unbelegten Verschwörungstheorien (und für das halte ich die Behauptung, dass Gemantik-Zertifizierungen den Aktionären - sprich Staat - Daten zuschanzt - wobei die Daten die ins Internet gehen sowieso zugänglich sind) vom eigentlichen Problem ablenken -> wenn parallele Installation, dann ordentlcihe Installation von jemand mit Sachverstand und nicht den Standard für ein Netz zu Hause!
Nichts für ungut
A. Spiegl

[lcer]

Hallo,

zu 3) wir sind gesetzlich verpflichtet die TI einzuführen - ob ich anderer Meinung bin, als der Gesetzgeber ist unerheblich.

Ich habe ja auch nicht gegen die TI, wir haben sie relativ schnell nach Verfügbarkeit eingeführt.

Dafür trägt dann der Gesetzgeber die Verantwortung, wenn auf diesem Wege Daten ausspioniert werden.

Würde ich mich auf den Staat verlassen wollen, wäre ich angestellter Arzt. Ich bin aber Freiberufler.

zu 4) nochmals Entschuldigung, aber sie behaupten doch, dass die Daten in der seriellen Installation schlechter geschützt sind als in der paralellen und fordern jetzt von mir Belege, dass dies nicht so ist - in meiner Welt ist es immer noch so, dass derjendige, der eine Behauptung aufstellt den Beweis oder zumindest Anhalt dafür schuldet - aber ich bin über 50 und damit wohl zu alt um die heutige Welt zu verstehen!

Nein, die Reihenfolge der vorgetragenen Ansichten spielt keine Rolle für den Auseinandersetzung mit den Tatsachen.

In der aktuellen Diskussion über unsicheren Schutz der Daten in Praxen geht es meines Wissens nur um parallele Installationen - klar kann man eine parallele Installation ausreichend sicher machen, aber in vielen Praxen wird halt geschlampt.

Nun, bei uns nicht. Man kann das vielleicht wie folgt erklären:

Serielle Installation:
Der gesamte Datenverkehr ins Internet geht über den Konnektor. Der Konnektor und die dahinterliegende Telematikinfrastruktur sind technisch in der Lage, Telemetrieprofile des Datenverkehrs zu erstellen und Verbindungen zu analysieren. Da ich dem Staat und der Gematik grundsätzlich nicht vertraue (siehe oben, bin ja nicht angestellt) habe ich hier bedenken. Wenn Sie das mit Ihren 50 Jahren nicht nachvollziehen können, sind sie vermutlich in einem anderen Gesellschaftssystem sozialisiert worden, als ich.

Parallele Installation - rumgebastelt und unsicher installiert:
Hier besteht kein Schutz vor gar nichts. Darum dreht sich die aktuelle Sicherheitsdiskussion bezüglich der Telematik.

Parallele Installation mit "richtiger" Sicherheitsstruktur (so haben wir das gelöst) bedeutet:
- "richtige" Firewall (nicht nur NAT auf dem Router)
- Absicherung auch der Clients im lokalen Netz durch entsprechende ggf. Endpoint-Firewall, mindestens Antivirus-Software
- Sauber Rechtevergabe, Verschlüsselung etc. im internen Netz z.B. korrekt eingerichtete Windows Domäne
- kann man alles schön beim BSI - Stichwort Grundschutzkatalog nachlesen.

Ein wichtiger Punkt dabei ist die Netzsegmentierung: nachzulesen hier: https://www.bsi.bund.de/DE/Themen/ITGru ... esign.html Soll heißen, dass für Computersysteme mit unterschiedlichen Sicherheitsanforderungen unterschiedliche Netzwerke genutzt werden sollen: Beispiele für solche System wären:
- Identitätsserver (Domäncontroller)
- Produktive Server (Turbomedserver)
- Verwaltung von Infrasturkturgeräten (Router, Firewall, switches …)
- Fremdsysteme!

Der Konnektor ist ein Fremdsystem, dass nicht vollständig von mir verwaltet werden kann. Nach der Logik des BSI ist ein solches System hinter einer Firewall zu platzieren und vom restlichen Netz zu trennen. Das ist bei uns passiert. Nur explizit von meiner Firewall erlaubte Kommunikation zum Konnektor bzw. Lesegerät ist zugelassen. Alles was da nicht hin muss, gelangt da auch nicht hin. Auch kein Datenverkehr ans Internet.

Es tut mir leid, ich traue weder der Gematik, den Telematik-Betreibern, dem Internet-Provider und auch nicht CGM. Die Absicherung unserer Daten bleibt unsere Verantwortung.

Und in dieser Hinsicht sollte man nicht mit unbelegten Verschwörungstheorien (und für das halte ich die Behauptung, dass Gemantik-Zertifizierungen den Aktionären - sprich Staat - Daten zuschanzt - wobei die Daten die ins Internet gehen sowieso zugänglich sind) vom eigentlichen Problem ablenken -> wenn parallele Installation, dann ordentlcihe Installation von jemand mit Sachverstand und nicht den Standard für ein Netz zu

Da gebe ich Ihnen recht. Sachverstand ich hier gefragt. Aber bitte eine saubere Risikoanalyse nicht gleich mit Verschwörungstheorien abtun. Das hier ist eine technische Diskussion, keine Mainstream-Anti-Trump oder ich-meine-es-gut Diskussion.

Nichts für ungut.

Falls es jemanden interssiert, die Konfiguration zum separieren der Telematikgeräte ist gar nicht so kompliziert wenn man geeignete Hardware benutzt (mit der Fritzbox geht es nicht!). Ich kann das bei Gelegenheit mal posten.

Grüße

lcer

[lcer]

Nachtrag - ein Problem das ich mit der zertifizierten Gematik Firmware des Konnektors habe:

https://www.heise.de/ct/artikel/Hinweis ... 35791.html
https://www.ingenico.de/binaries/conten ... v8.6.1.pdf

Der Konnektor ist ein letztlich ein VPN-Router. Die Firmware, das Betriebssystem des Konnektors enthält diverse Komponenten (Softwarebibliotheken), die Fehler (Bugs) haben können. Für die KocoBox habe ich keine Aufstellung der verwendeten Open Source Komponenten gefunden. Möglicherweise werden hier kommerziell verfügbare Softwarebibliotheken genutzt.

Als Beispiel sei die OpenSSL-Bibliothek aufgeführt. Diese ist eine weit verbreitetet Grundlage vieler wichtiger Kryptographie-Umsetzungen im Internet, zum Beispiel im Bereich VPN. (in der Telematikinfrastruktur erfolgt die Absicherung ebenfalls über SSL - die berühmten Zertifikate auf den diversen Chipkarten zählen dazu - allerdings werden je nach Hersteller unterschiedliche Softwarebibliotheken eingesetzt.)

Eine Übersicht für die Sicherheitspatches der Open Source SSL-Bibliothek findet man hier: https://www.openssl.org/news/vulnerabilities.html.
Infos zu den Updates der Kokobox hier: https://www.kocobox.de/support.de.jsp

Was fällt auf?
In der gleichen Zeit gab es deutlich mehr Sicherheitspatches für die Open Source SSL-Bibliothek als für den Konnektor. Kann man daraus schließen, dass der Konnektor besser programmiert ist? Nun, dass kann jeder für sich entscheiden. Einen Einstieg zum Thema findet man in einem aktuellen Artikel bei Heise https://www.heise.de/security/meldung/D ... 79682.html

Nach meiner Meinung werden sicherheitsrelevante Softwareupdates durch die zentrale Organisation der Telematik eher ein verzögert als konsequent durchgezogen. Jedes Update muss ja neu zertifiziert werden, das kostet Zeit und Geld.

Ausserdem dürfte der zentrale Fokus der Gematik auf dem Schutz der eigenen Telematikinfrastukturnetze liegen. Der Schutz unseres Praxisnetzes ist da sicher nachrangig.

Daher - Telematik da, wo wir müssen. Das muss aber jeder für sich entscheiden.


Grüße

lcer

[danspie]

... auch wir haben den Konnektor in einem eigenen Netz, da wir ihm nicht trauen. Aber mir ist es letztendlich vond er Sicherheit her egal, ob die Daten ins Internet über den Konnektor oder unseren Router gehen, da sehe ich weiterhin keine wesentliche Unterschiede......
Schönen Abend
A. Spiegl

[torsten2]

Um das Thema nochmal aufzuwärmen: Icer hatte ja angeboten, Details zu posten, wie man den Konnektor in ein eigenes Subnetz bekommt. Ich wäre da sehr interessiert. Insbesondere die Kommunikation zu den Lesegeräten und dem Server bzw. den Arbeitsstationen.

[lcer]

Hallo,

https://administrator.de/forum/tis-konn ... nt-1370738

Grüße

lcer

[nmndoc]

habe das o.g. nur überflogen, aber letztlich ist das Vorgehen ja immer gleich: Sie trennen die Netze über ein Gerät Router/Firewall, dass mehrere Netze unterstützt - am besten über wirklich unterschiedliche Ports, sonst via VLan.
Die FritzBox könnte die Netze über die Gastnetzfunktion trennen - man kann da ja Port 4 oder 5 m.E. als Gastnetz einrichten - allerdings weiß ich nicht, ob die FB den Zugriff vom LAN in das Gastnetz erlaubt und man hat hier im Zweifelsfall keine großeb Einflußmöglichkeiten (IP-Bereich zB fest vorgegeben).
Daher vielleicht am besten in der Art, wie Icer beschrieben hat - zwei Router hintereinander, dh das externe Interface/Port des "inneren" Routers hängt dann an einem LAN-Port der FB (dann aber keine Gastnetz-Funktion verwenden).
Das Telematik-Zeug gehört dann direkt andie FB, die Praxisrechner an/hinter den inneren Router.

dh dann auch:

Default gateway für Konnektor etc: FB
Default gw innerer Router: FB
default GW LAN/Praxisnetz: innerer Router.

via NAT sollte das ganze so eigentlich funktionieren. Insbesondere sollte es nicht nötig sein, auf der FB Routen in die internen Netze einzutragen - wohl aber die zu KV-Safenet. UND auf dem Konnektor muss man unter interne Netze evtl. das Praxis-Netz hinterlegen - vielleicht geht es dan NAT aber auch ohne.

[torsten2]

Ich habe bisher einen Rechner mit einer Quad-Netzwerkkarte mit CentOS und die Firewall mit fwbuilder konfiguriert. Leider wird die Software nicht mehr weiterentwickelt. Da ich was Ordentliches will und auf die Kosten achte möchte ich mir nun das "Blech" von HUNSN kaufen (4-8 Ports, auch SFP wenn gewünscht) und darauf die Endian Community Version installieren.

Die Fritzbox Kabel wird nur als Transfernetz genutzt. Hier sind nur nicht vertrauenswürdige Geräte (EC-Cash, Wartezimmer-TV) angeschlossen. Man könnte auch noch das Gastnetz aktivieren und die CoKoBox exklusiv an LAN-4 anschließen. Das hier das Netz festgelegt ist, stört ja nicht. Man müßte dann nur im Filter der Fritzbox noch bissel was freischalten.

Was mich schon die ganze Zeit bei IAG gestört hat ist, daß man den WAN Port nicht verwenden kann. Wenn mit der Variante KEINER der Wan-Port geht, wär das ein großer Fortschritt. Aussperren kann man sich ja da auch nicht.

Ich habe sowieso schon eine Route hinzugefügt, funktioniert gut. Wenn man Die Weiterleitung von BLOCK auf REDIRECT stellt, akzeptiert die Box auch die Subnetze. Das sollte es auch einfaches Routing tun, NAT brauchts dann eingentlich nicht.

Laut TM Techniker bei der Installation müssen die Geräte und Arbeitsstationen im gleichen Subnetz sein, sonst funktioniert es nicht. Hat es denn jemand so in Betrieb?

Unbenannt-1.jpg

Sry, Freihand mit dem Grafiktablett gezeichnet...

Was mich jetzt interessiert ist, was passiert, wenn ich die IP des Konnektors ändere? Wo muß ich die Änderung (Server, Arbeitsstationen) überall eintragen?

[lcer]

Laut TM Techniker bei der Installation müssen die Geräte und Arbeitsstationen im gleichen Subnetz sein, sonst funktioniert es nicht. Hat es denn jemand so in Betrieb?

Deswegen das NAT. Dann glaubt der Konnektor, er wäre im selben Subnetz. Das einzige was nicht geht ist das kocobox Tool von CGM, das starte ich dann auf einer VM im Konnektor Subnetz, falls überhaupt erforderlich.

Grüße

lcer

[lcer]

Die IP muss nur im TM Server eingestellt werden. Ggf. Muss man noch die Lesegeräte neu pairen.

Grüße

lcer

[hofeBY]

@Torsten2

Schöne Zeichnung,
aber wie tauschen denn der TM-Server und die KocoBox Daten aus,
was aus meiner Erfahrung zwingend erforderlich ist ?

An der KocoBox WAN Schnittstelle sollte das ja aus Sicherheitsgründen nicht gehen.


HofeBY

[torsten2]

Ich dachte andersrum, dann würden alle Arbeitsstationen von derselben IP kommen... Das kann ja keiner auseinanderhalten. Wenn vom Konnektor aus NAT vom DMZ ins LAN gemacht wird, ergibt das ganze Sinn. Vielen Dank, jetzt hab ich's.

[lcer]

@Torsten2

Schöne Zeichnung,
aber wie tauschen denn der TM-Server und die KocoBox Daten aus,
was aus meiner Erfahrung zwingend erforderlich ist ?

An der KocoBox WAN Schnittstelle sollte das ja aus Sicherheitsgründen nicht gehen.


HofeBY

Die "Firewall" ist natürlich auch ein Router; der kümmert sich darum, dass Daten vom Praxisnetz und Kocoboxnetz kommen - und zurück.

Grüße

lcer

[lcer]

Ich dachte andersrum, dann würden alle Arbeitsstationen von derselben IP kommen... Das kann ja keiner auseinanderhalten. Wenn vom Konnektor aus NAT vom DMZ ins LAN gemacht wird, ergibt das ganze Sinn. Vielen Dank, jetzt hab ich's.

Das NAT muss an die LAN-Schnittstelle zwischen "Firewall" und Kocoboxnetz. Aus Sicht des Konnektors kommen alle Pakete von Turbomed & Arbeitsstationen der selben IP, das NAT kümmert sich darum, das auseinanderzuhalten. siehe https://de.wikipedia.org/wiki/Netzwerka ... m_Beispiel Man kann sich das so vorstellen, dass der Konnektor quasi im öffentlichen (nicht-privaten) Netz läge und das lokale Netz per NAT vor dem Konnektor verschleiert wird.

Grüße

lcer

[torsten2]

@hofeBy: Der Hauptgrund ist ja, daß ich die beiden auf verschiedenen Interfaces habe. Nur dann kann ich in der Firewall Rules erstellen. Außerdem wird der gesamte Traffic durch die Firewall erzwungen, sonst kann ich ja gar nix kontrollieren oder filtern. Der HUNSN ist gekauft, werde das Projekt dann mal angehen.

[DocET]

@Icer:
War ein neues Pairing von KocoBox und Kartenterminals erforderlich, nachdem diese Geräte in die DMZ ausgelagert worden sind?

Ich finde die Idee bestechend, die KocoBox und die Kartenterminals aus dem Praxis-LAN herauszulösen (siehe auch Bild, Dank an thorsten2). Allerdings würde ich die IPs im Praxis-LAN wegen der vielen Geräte dort gern im jetzigen Zustand belassen.
Kann folgender Ansatz funktionieren?
- Zusatzrouter mit NAT auf Praxis-LAN-Seite -> bekommt alte KocoBox-IP -> dann keinerlei Umstellung von TurboMed notwendig?
- KocoBox und die Kartenterminals -> aus Praxis-LAN herausnehmen in ein neues Subnetz hinter dem Zusatzrouter

Dank für kurzes Feedback, viele Grüße von DocET

[torsten2]

Da die Hardware solange gebraucht hat und auch das System etwas zickig beim Installieren war, habe ich es erst diese Woche in Betrieb genommen. Dabei habe ich feststellen müssen, dass die Endian fast alles kann, aber snat leider nur auf dem untrusted Interface ins Internet - oder ich bin zu dämlich es zu finden... Die Qualität der Foren im Netz sind mit dem hier leider nicht zu vergleichen Jedenfalls sind solche Konstruktionen wie in fwbuilder z.B.
echo "Rule 2 (NAT)"
#
# KV-Safenet
$IPTABLES -t nat -A POSTROUTING -o eth0 -d 188.144.0.0/15 -j SNAT --to-source 192.168.xxx.xxx

irgendwie nicht möglich. Ich habe dabei aber eine viel charmantere Lösung gefunden. Die ersten drei physischen Ports wurde gebridged und als internes Netz eingerichtet, also im Prinzip ein Switch. Das sieht dann so aus:

connections.jpg

In den Firewall Rules kann man jedoch auf jedes Interface eth0-2 einzeln zugreifen. Die CocoBox ist intern einzeln an einem Port, der Server an einem anderen und das restliche Netz am dritten. Der Datenflow muss also zwingend durch die Firewall, ich kann da auch sehr feingranuläre Regeln erstellen.
Vorteil:
1.Ich kann das interne Subnetz lassen wie es ist.
2. Ich kann auch den kompletten Verkehr von Server und KoCoBox sehen und blockieren
3. Wenn die Firewall mal ausfällt, steck ich die Geräte zurück an den Hauptswitch und kann erstmal weiterarbeiten.
4. Die KoCoBox steht auf "Anbindungsmodus Internet: keiner" und hat ein eigenes WAN Subnet ins Internet. Auch das geht über die übrigen Ports der Firewall und ich sehe ebenfalls genau was hier passiert.

[lcer]

Hallo,

@Icer:
War ein neues Pairing von KocoBox und Kartenterminals erforderlich, nachdem diese Geräte in die DMZ ausgelagert worden sind?

Dürfte nicht sein. Aber die IP muss angepasst werden.

Ich finde die Idee bestechend, die KocoBox und die Kartenterminals aus dem Praxis-LAN herauszulösen (siehe auch Bild, Dank an thorsten2). Allerdings würde ich die IPs im Praxis-LAN wegen der vielen Geräte dort gern im jetzigen Zustand belassen.
Kann folgender Ansatz funktionieren?
- Zusatzrouter mit NAT auf Praxis-LAN-Seite -> bekommt alte KocoBox-IP -> dann keinerlei Umstellung von TurboMed notwendig?

Das ist nicht das empfohlene Setup und dürfe wegen der Firewall der Kocobox nicht funtkionieren. Das NAT ist quase andersherum, nicht die Kocobox wird maskiert, sondern das Praxisnetz. Allerdings ist das Umstellen eigentlich auch kein Problem. Der Konnektor ist das einzige Gerät, das mit Turbomed kommuniziert. Alle Einstellungen finden sich im Turbomed unter Sonstiges/Praxisdaten/eGK Nur wenn Zusatzanwendungen aktiviert sind (KIM) kann es sein, dass die Konnektor-IP noch an anderer Stelle geändert werden muss.

- KocoBox und die Kartenterminals -> aus Praxis-LAN herausnehmen in ein neues Subnetz hinter dem Zusatzrouter

Vorausgesetzt, das NAT ist richtig herum, trägt man dann im Turbomed (s.o.) die neue Konnektor-IP ein. Die Kartenterminals müssen nirgendwo eingetragen werden. Die kommunizieren ausschließlich mit dem Konnektor.

Hinweis: das Koco-Servicetool kann den Konnektro dann nicht mehr aus dem Praxisnetz erreichen. Das Tool kann man dann aber auf einem PC/Laptop/VM starten, den man kurzfristig zu wartungszwecken ins Konnektornetz hängt.

Grüße

lcer

[torsten2]

Funktioniert das vollständig?
Bei mir wird angezeigt, daß der Konnektor(Source) zum Server(Destination) und teilweise den Arbeitsstationen eine Verbindung 45001 tcp aufbaut. Das ginge ja dann nicht mehr. Andererseits habe ich das auch nirgendwo dokumentiert gefunden. Weiß jemand was das ist und ob die Verbindung notwendig ist?