VonDoczuDoc.de

Folgendes Phänomen. Wenn ich in der Firewall für einen einzelnen Computer (nicht das ganz Netzwerk) den Port 80 und 443 sperre, funktioniert das Ausstellen der E-Rezepte nicht mehr zuverlässig.

Um zu verhindern, das über einen Computer in das Internet gegangen wird, wurde der Zugang komplett in der Firewall gesperrt. Vor der Sperre gab es keine Probleme, auch nicht mit eAU oder E-Rezept. Nach einigen Experimenten scheint es die Port’s 80 und 443 zu sein, die bei einer Sperre Probleme machen.

Nach der Sperre gibt es auf einmal Probleme mit dem Ausstellen von E-Rezepten. Das Merkwürdige ist, nicht sofort, und nicht komplette. Nach der Sperre dauert es zwischen ein paar Minuten bis zu 2 Stunden, bis das Problem auftritt. Es gibt die Fehlermeldung das ein TI Dienst nicht erreichbar ist. Wiederholt man den Vorgang 2 - 4 Mal, so geht das E-Rezept dann irgendwann doch durch. Nimmt man die Speere der Ports heraus, so funktioniert es sofort wieder ohne Probleme. Das Problem habe ich an verschiedenen Computern in 3 Praxen nachvollziehen können.

Arbeitstheorie: Irgendein Prozess versendet Daten über das Internet (und nicht über den Weg der Koco-Box), z.B. irgendeine Statistik. Das wird aber nicht bei jeder Ausstellung eines E-Rezeptes gemacht, sondern in bestimmten Zeitintervallen. Werden die Ports blockiert, so blockiert der Prozess die Ausstellung des E-Rezeptes so lange, bis es im Ablauf irgendwo ein „Time Out“ gibt. Wenn man es mehrmals hintereinander versucht ist der Time Out des senden Prozesses vielleicht mal minimal kürzer, so das die Ausstellung des E-Rezeptes ab und an gelingt.

Bevor ich jetzt anfange, mit Wireshark Netzwerkverkehr zu analysieren, hat jemand eine Idee was da nach Hause telefoniert?

Jens

Hallo,

1) wenn Sie doch schon eine Firewall verwenden (oder sprechen wir hier von der Windows-Firewall?) dann können Sie doch in den Logs einfach nachsehen, was (von wo nach wo) geblockt wurde was dann ggf Rückschlüsse zuläßt

2) Bitte prüfen ob Sie wirklich zum INTERNET blockieren oder in alle Netze (dh aus in das Telematiknetz - das ist aber nicht Internet)

3) CGM schreibt dass sie Zugriff auf https://hashandurl.f-vpnzugd.telemed-ti.net Port 80 und https://hashandurl.d-vpnzugd.telemed-ti.net ebenfalls 79 benötigen. Allerdings sind die angegebenen IPs andere / lösen bei mir anders auf als die, die in der Doku angegeben sind - aber zumindest aus dem selben /24 Netz - in dem Fall 185.188.x bzw 185.188.2.x

Nachtrag - irgendwo stand auch ein Hinweis auf CRL die abgefragt wird - evtl download.crl.ti-dienste.de oder so

Port 443 ist bei mir in der Hardwarefirewall gesperrt.
eRP und eAU laufen aber perfekt.

Das alles ist vor ca. 2 Jahren bei mir eingerichtet worden und der IT-Mensch hat grob 5 Stunden gebraucht, um es geregelt zu bekommen.

Allerdings geht bei geschlossenem Port 443 auch keine Fernwartung von TM über Anydesk mehr. Da ich mit diesen Fernwartungen sehr schlechte Erfahrungen gemacht hatte, stört es mich nicht. Und wenn ich es doch mal brauche, hat mir mein IT-Mensch eine Ausnahmeregel in der Firewall eingerichtet.

Einzelheiten zu den notwendigen Ports kann ich leider nicht machen, da das mein IT-Verständnis übersteigt, könnte aber bei Interesse einen Kontakt zu meinem IT-Menschen vermitteln.

Viele Grüße vom Augendoc

Ich habe mich ja effektiv von meiner TM-Schrottsammlung getrennt.
Für die ganzen Löcher, die das System in die FW bohrt gibt es aber NW - Monitore:
zB dieser auch als Freeware nutzbare: https://www.paessler.com/de/prtg/download
Insgesamt hinterlässt TM+TI einen Schweizer Käse in der FW. Somit kann man sich diese passive Defense echt sparen.
Nach den letzten Cloud/Azure usw. Desastern reicht schon MS um sich zu kompromittieren.
Nur Tontäfelchen und Keilschrift sind sicher - seit über 10000 Jahren evidence Data.
Manche sind so hochverschlüsselt, dass selbst Ai / QC die Vorfahreninfos noch nicht entschlüsseln konnte

nmndoc hat geschrieben: ↑Sonntag 11. August 2024, 21:13 Nachtrag - irgendwo stand auch ein Hinweis auf CRL die abgefragt wird - evtl download.crl.ti-dienste.de oder so

Das wird es sein. Die CRL werden begrenzt zwischengespeichert, so dass meist nach 60 oder 120 Minuten ein erneuter Download erfolgt. Die CRL müssen über das öffentliche Internet abgerufen werden. Dementsprechend Domain-Whitelist erforderlich (z.B. download.crl.ti-dienste.de). Manche xxx.ti-dienste.de sind TI-intern, andere öffentlich. Daher das unsägliche SplitDNS.

Das ist also am Ende kein Telefonat nach Hause, sondern Standardverhalten. Genau genommen wäre es kontraproduktiv, die CRL, TSL, Root- und Intermediate-Zertifikate nur innerhalb der TI anzubieten.