Hallo @janm ,   ich hoffe, Sie haben meine Beiträge vollständig gelesen, denn genau das reicht leider seit der Umstellung von DATEV nicht mehr aus, bzw. ist es sogar kontraproduktiv.   DATEV und Trojaner/Viren nutzen jetzt die gleichen Serveradressen (Dafür kann DATEV natürlich überhaupt nichts) :   Der DATEV Installationsmanager ruft neue Software jetzt über die DNS Adresse swdownload-aws.datev.de ab. Diese wird standardmäßig als Alias von 4 redundanten, aber häufig wechselnden Adressen aufgelöst, die alle über folgende Namenskonvention verfügen : xxxxxxxxxxxxxx.cloudfront.net Die gleichen Adressen werden leider auch von Trojanern,Viren und Expoits über gekaperte Amazon Accounts verwendet, um Programmteile nachzuladen. Damit ist ein Whitelisting von cloudfront.net ziemlich gefährlich. Und da diese Adressen über keinen Reverse DNS Eintrag zu datev.de verfügen, darf eine sicher eingestellte Whitelisting Firewall auch keine positive Entscheidung treffen. Früher wäre es noch möglich gewesen, über die DNS Abfrage zu datev.de die IP Adressen eine zeitlang mit Datev zu verknüpfen, aber seit DNSSEC ist auch dieses nicht mehr ohne Sicherheitseinbußen möglich.   Eigentlich hätten ALLE korrekt und sicher eingestellten Whitelist Firewalls seit der Änderung von Datev keinen schnellen Programmabruf aus dem Installationsmanager mehr machen dürfen (Es gab am Anfang noch einen Fallback auf einen echten DATEV Server, der aber beim Abruf extrem langsam war)   So schön die Redundanz bei Amazon Cloud auch ist, so problematisch ist sie für eine sichere Firewall Konfiguration.   ... Mehr anzeigen

@Stefanie_Herold  schrieb:   Wenn ich es richtig verstanden habe, geht es Ihnen um den Fall, dass wir mit dem Softwareabruf im Installationsmanager über die uns bekannten IP-Adressen der AWS-Plattform kompromittierte Installationsdateien herunterladen und dann über DATEVnet nur den Folgeschaden verhindern könnten. Richtig? Hallo @Stefanie_Herold ,   erstmal vielen Dank für die schnelle Rückmeldung und den Versuch, dieses brisante Problem zu verstehen und an die richtige Stelle weiterzuleiten, da die bisherigen Versuche über den Firstlevel Support von DATEV leider komplett gescheitert sind.   Es geht nicht um die Absicherung oder Überprüfung der Downloads, sondern um die Absicherung der Netzwerkverbindungen von und zu DATEV.   Vor der Umstellung durch DATEV auf Amazon AWS war es einfach möglich, über eine Firewall den ein- und ausgehenden Netzwerkverkehr des DATEV Systems auf sichere Gegenstellen (DATEV, Elster & Co) zu beschränken. Damit konnte das Nachladen und die Kommunikation von Trojanern oder das Ausnutzen eines ZeroDay Exploids wie Log4j auf den Datev Systemen nahezu zu 100% ausgeschlossen werden. (Es sei denn ,die DATEV wird selbst infiziert, was ich hoffe, ausschließen zu können)   Dieses Sicherung ist seit der Auslagerung auf Amazon AWS aus 2 Gründen fast unmöglich bzw. sogar teilweise kontraproduktiv geworden :   1. Die von Amazon und damit neuerdings auch von Datev verwendeten IPV4 Adressen sind weit über 1000 und es kommen ständig neue hinzu. Was für andere Anwendungen wie Telegram & Co von Vorteil ist, weil sie damit in totalitären Systemen schwer geblockt werden können, ist bei der Absicherung von DATEV Systemen ein riesengroßer Nachteil. Ich will nicht zu fachlich werden, aber ein weiteres Problem für die Firewall ist die fehlende Reverse DNS Auflösung der AWS Server in Richtung DATEV. Eine externe Firewall kann also nicht so einfach erkennen, ob es sich um ein reguläres DATEV Ziel handelt.   2. AWS Server wurden leider in der Vergangenheit auch häufiger schon für das Nachladen und die Kommunikation von Trojanern benutzt, da kompromittierte AWS Konten dafür misbraucht werden konnten. Dadurch reißen die von DATEV im Installationsmanager zwingend erforderlichen Freigaben für die AWS Gegenstellen ein großes Loch in die lokale Firewall. Dieses Problem müsste eigentlich auch DATEVnet genauso betreffen.   Der Vorteil für Datev durch diese Umstellung dürfte in keinem Verhältnis zum Nachteil bei der Absicherung von DATEV Systemen stehen, denn diese Art von Schwachstellen werden in der Zukunft mit Sicherheit eher noch zunehmen und damit eine gut eingestellte Firewall immer wichtiger werden.   Viele Grüße ... Mehr anzeigen

@Gelöschter Nutzer@agmü  https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html Über diesen Artikel kann man auch komplett anderer Meinung sein.   Ich versuche mal, es für alle technisch nicht ganz so versierten Mitleser an einem Beispiel klarzumachen :   Wenn Sie im Auto einen USB Anschluss für das Abspielen von Musik haben und dort einen USB Stick anschließen, auf dem zusätzlich auch noch eine HTML Datei (Webseite) abgelegt ist, dann erwarten Sie auch nicht, dass diese vom Mediensystem des Autos „geparst“ und dann auf dem Display des Navis angezeigt wird. Aber genau so etwas Ähnliches ist passiert bei Log4J. Diese zusätzliche Eigenschaft mag für einige Situationen sinnvoll erscheinen, sicherheitstechnisch ist sie eine absolute Katastrophe und ich finde, ein Programmierer, der nur die Log4J Bibliothek benutzt, muss nicht unbedingt damit rechnen, dass hier ein solches Parsing existiert. (Natürlich sollte er es prüfen) Inzwischen ist die Funktion ja auch komplett entfernt und damit ersichtlich, dass sie für die normale Funktion überhaupt nicht notwendig ist. Von daher finde ich den Artikel vor allem für Nicht-Programmierer zum Teil ziemlich irreführend.   Bei dem Rest bin ich zu 100% bei Ihnen. Java ist eine Dauerbaustelle und Cloudanwendungen sind generell viel anfälliger für solche Lücken. ... Mehr anzeigen

@Stefanie_Herold DATEVnet bietet einen grundsätzlichen Schutz gegen Angriffe von außen und prinzipiell auch gegen Angriffe über die Log4j-Lücke Es tut mir leid, Ihnen hier widersprechen zu müssen, aber der Angriff bei Log4j erfolgt ja normalerweise gerade nicht über den sonst oft benutzten Weg des direkt eingehenden Netzwerkverkehrs. Auch ist diesmal kein ausgehender Zugriff auf ein "bösartiges" System für einen erfolgreichen Angriff notwendig. Das bedeutet, dass die bisherigen Filter von DATEVnet wie auch von anderen Firewallsystemen eine Infektion so einfach nicht verhindern können. Der einzige Nutzen läge im späteren Unterbinden der Kommunikation mit einen C&C Server, wenn nach erfolgreicher Kompromittierung des Systems die Schwachstelle nicht direkt ausgenutzt wird, sondern eine Hintertür eingebaut werden sollte, was bei dieser Art der Lücke nicht unwahrscheinlich ist (ich würde es zumindest als Hacker so machen). Dann wäre die Hintertür eventuell durch Filtermaßnahmen auf Netzwerkebene und damit auch wieder für DATEVnet oder andere Firewalls blockierbar. Aber dann ist es eigentlich schon viel zu spät und das System unter fremder Kontrolle. Bis vor kurzem war es noch relativ einfach möglich, DATEV Systeme vernünftig zumindest von der "bösen" Außenwelt abzuschotten. Leider ist das seit der Nutzung der Amazon Cloud durch DATEV selbst im Installationsmanager nahezu unmöglich geworden, da AWS/Cloudfront auch immer wieder zum Nachladen von Trojanern genutzt wird und damit eine normale DNS/IP basierte Sperre seine Wirkung komplett verliert. Das ist sehr schade, da DATEV für ihre eigenen Programme bisher einen eigenen IP Adressbereich genutzt hat, was in den unterschiedlichsten Firewallarchitekturen relativ gut und einfach zu pflegen war. Da wird ein geringer Nutzen für DATEV (Netzwerkauslastung, aber auch nur, weil die Programme immer größer werden!) zu einem riesigen sicherheitsrelevanten Problem für Steuerberater und deren Mandanten. Leider zeigen sich solche Probleme meist erst, wenn es schon zu spät ist. Es wäre schön, wenn DATEV die Konsequenzen solcher Auslagerungen besser analysiert oder sie am besten vorher zur Diskussion stellt und nicht einfach integriert, um an der falschen Stelle (aus meiner Sicht) ein paar Ressourcen einzusparen oder auszulagern. ... Mehr anzeigen

Ja, es gab den ganzen Abend eine große Störung beim Login auf "login.datev.de/openid/authorize?".Der Dienst war erreichbar, antwortete aber die ganze Zeit mit "503 Service Unavailable". Davon betroffen waren fast alle Datev Online Dienste, die einen erstmaligen oder erneuten Login über Smartcard oder SmartLogin erforderten.   Glücklicherweise läuft seit ca. 23:45 Uhr alles wieder. 😅   Es kamen natürlich sofort schlimme Erinnerungen an den 08.10.  hoch, aber ich hoffe, dass das Problem heute endgültig behoben wurde und es morgen keine weiteren Störungen gibt. Ein Ausfall am Abend ist ja nicht so katastrophal wie eine Störung tagsüber.   Allerdings finde ich es nicht gerade transparent, wenn ein solcher Ausfall nicht unter den behobenen Störungen der letzten 3 Tage erwähnt wird, da es doch schon ein größerer Fehler mit weitreichenden Auswirkungen war und die Fehler teilweise wieder sehr unterschiedlich waren und nicht immer eindeutig auf einen Fehler im RZ hinwiesen.   ... Mehr anzeigen