Wuff! Mahlzeit, finde ich auch! 😂
Moin,
da ich jetzt immer einen Blick auf den blau hinterlegten Hinweis habe und dann in die (unnötige) Arbeitsfalle tappe:, meine Bitte:
Wäre es möglich, beim Hinweis ein Datum mit anzugeben?
Wenn wie heute z. B. die Hotfixes vom 16.12. bereits installiert sind, gibt's ja nichts Neues. Da schaut man dann zwei- dreimal hin und prüft danach den InstMan oder zumindest das verlinkte Dokument, hat nichts Aktuelleres und hat dann gute Chancen nicht jeden Tag zu prüfen und dann wichtige Updates zu übersehen.
Im Voraus vielen Dank und schon mal vorbeugend alles Gute für die Feiertage, mögen Menschen und Technik gesund und munter bleiben!
WF
Ergänzung Datum ist gebongt ✔️
Änderung der Farbe für die Zukunft ist für die nächsten Anpassungen (frühestens im Januar) in Auftrag gegeben.
Hallo zusammen,
danke für das Feedback zu dem Banner, der dafür eigentlich nie gedacht war 😉
Die Farbe werden wir überarbeiten und aufmerksamkeitsstärker gestalten, wahrscheinlich irgendwas in Richtung Orange.
Der Hinweis selbst wird aktuell auf jeder Inhaltsseite angezeigt, manuell gepflegt und gesteuert. Mit einem Klick landet man bei der Zielseite, das kann wie aktuell ein Hilfe-Dok sein, kann aber auch eine Community-Diskussion oder ein anderes geeignetes Ziel sein, welche in der Regel selbst eine "Zuletzt aktualisiert am"-Info beinhalten. Den einen Klick muss man dann schon machen. Denn eine Datums- / Zeitangabe hier, in einem vom Linkziel unabhängigen System, würde unweigerlich zu Abweichungen und damit zu Verwirrungen führen.
*keep it simple*
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.
Danke für die Info's.
Ist angedacht von Java Abstand zu nehmen?
Ich hab zwar keine große Ahnung von programmieren, aber wenn man etwas die IT-Welt verfolgt ist Java seit Jahrzehnten eine "etwas" kritische Dauerlücke.. mal mehr, mal weniger.
Seitdem Artikel von Herr Müller:
https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html
habe ich zumindest eine ungefähre Ahnung, warum das so ist.
Kurzum: gerade in den Cloudanwendungen vermutlich höchst problematisch.
@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.
Hat schon jemand den aktuellen Hotfix von heute installiert? Kann das während des laufenden Betriebes passieren oder erfordert es einen Neustart?
Eigentlich soll es ja keinen Neustart bei Hotfixes geben, aber beim letzten wurde bei mir auch einer angefordert. Andere Benutzer haben davon ebenfalls berichtet.
Also hier erfordert es einen Neustart.
@Steuermann10 schrieb:Hat schon jemand den aktuellen Hotfix von heute installiert? Kann das während des laufenden Betriebes passieren oder erfordert es einen Neustart?
Eigentlich soll es ja keinen Neustart bei Hotfixes geben, aber beim letzten wurde bei mir auch einer angefordert. Andere Benutzer haben davon ebenfalls berichtet.
Auf sauber gepflegten Systemen ist eigentlich kein Neustart notwendig - das haben unsere Tests eben nochmal bestätigt.
Ich vermute aber mal, dass Sie in der aktuellen Situation einfach sehr viele Updates von allen möglichen Anwendungen auf Ihre Systeme bekommen und dadurch in Summe dann Neustarts notwendig werden.
Guten Tag Frau Herold,
sind die Hotfixe zwingend über die Hotfix-Installation zu machen oder kann ich sie an den Rechnern auch manuell starten?
Viele Grüße
Inga
Danke Frau Herold,
aber gleich wieder fix Hotfix bereit stellen, dass hätte aus meiner Sicht nicht unbedingt sein müssen ;-).
Es hilft ja nix und lieber über die Community sehr zeitnah informiert werden als zu spät oder gar nichts machen.
LG
WF
PS.: Kann es sein, dass nicht für alle Nutzer heute wieder Hotfixes bereit gestellt wurden? Zumindest konnte ich nicht keine downloaden, werde aber immer mal wieder nachprüfen.
Hallo @id_norderstedt ,
wir empfehlen, die Hotfixes über die entsprechenden Assistenten zu installieren.
Eine Beschreibung dazu finden Sie in unserem Hilfe-Center: Benutzerdefinierte Hotfix-Installation
Im Assistent kann ausgewählt werden, ob man die Hotfixes nur auf diesem Rechner installieren möchte oder (wenn vorhanden) im gesamten Netzwerk.
Hier ist natürlich auch unsere Empfehlung, die Hotfixes schnellstmöglich im ganzen Netzwerk zu installieren.
Moin nochmal,
ein weiterer Versuch und ich konnte denn Hotfix ...-01760 downloaden. Auch hier wurde bei der Installation ein Neustart (auf dem PtPServer) gefordert.
LG
WF
PS: Anzeige bei Installation sinngemäß "Workstation braucht keinen Hotfix", an der WS dann aber "Installation ist vorgesehen" und startet auch den Hotfix incl. Neustart des Rechners. Eigentlich waren m. E. n. die Rechner auf neuem Stand.
@Dirk_Jendritzki schrieb:
... Der Hinweis selbst wird aktuell auf jeder Inhaltsseite angezeigt, ...
... der Hinweis taucht zwar auf jeder Inhaltsseite und in jedem Thread auf, allerdings nur ganz oben.
Threads können aber sehr lang sein, viele Bildschirmseiten, bis zu 50 Posts (einstellbar).
... ob man dann den wichtigen Hinweis gaaaanz oben entdeckt, ist eher Glücksache, von der Auffälligkeit mal abgesehen.
... ich selbst springe normalerweise meist nur direkt zu den letzten ungelesenen Posts, wo aber dieser Hinweis nicht 'auftaucht'.
... ideal wäre, wenn solche wichtigen (akuten) Nachrichten automatisch bei bestimmten Aktionen eingeblendet würden, z.B. für 2-3 sec, oder wenn wenigstens ein auffälliges und anklickbares Symbol permanent zu sehen wäre, z.B. rechts oben zusätzlich zu den 3 vorhandenen Buttons
@vogtsburger schrieb:
@Dirk_Jendritzki schrieb:
... Der Hinweis selbst wird aktuell auf jeder Inhaltsseite angezeigt, ...
... ich selbst springe normalerweise meist nur direkt zu den letzten ungelesenen Posts, wo aber dieser Hinweis nicht 'auftaucht'.
Von der Startseite aus, richtig? Aber da ist der Hinweis ja auch zu sehen.
Jetzt lassen Sie uns erst Mal die Farbe machen 😉
Wir hatten gestern die Hotfixes installiert. Neustart erforderlich.
Heute den neuen Hotfix installiert. Neustart erforderlich.
Liebe Frau @Stefanie_Herold ,
ich finde es toll, wie Sie und die dahinter stehende Mannschaft das Thema hier betreuen und wie schnell sie den wirklich sinnvollen Vorschlag zur Verbesserung der "Banner-Mitteilung" umgesetzt haben.
Zu dem aktuellen Hotfix (heute seit 14:00 Uhr) muss ich Ihnen allerdings widersprechen!
Es ist in einer virtualisierten und am Sonntag 19.12. vollständig upgedateten und durchgerooteten Umgebung auf jedem Server (Win 2016 neuestes Patchlevel) ein Neustart nötig geworden.
Das ist natürlich nicht schlimm, aber sollte vorsichtshalber insoweit berücksichtigt werden, dass bei sofortiger Installation die Mitarbeitenden "gewarnt" und ggf. mit "Nicht-EDV-Tätigkeiten" (sofern es solche in der Kanzlei noch gibt) betraut werden.
Ich konnte den automatischen Neustart nach (glaub 50 sek) grade noch abbrechen und für ein geordnetes Abmelden der Mitarbeitenden Sorge tragen. Den nächsten Hotfix mach ich vorsichtshalber nach Dienstschluss.
Hallo,
kann ich bestätigen, auch hier wurde bei jedem Server ein Neustart verlangt.
Ich hab meine Kollegen zum Thema Neustart nach den Hotfixes nochmal gequält.
Anscheinend ist es so, dass wenn die DLLs, die ausgetauscht werden sollen, gerade durch eine Anwendung in Benutzung sind, dies zum Neustart führt.
Genauer konnte ich es noch nicht rauskriegen und melde mich dazu morgen nochmal.
Installation nach Dienstschluss scheint dann aber auf jeden Fall ein guter Plan zu sein 👍
Viele Grüße und einen schönen Abend 🌟
Stefanie Herold
@Softwareprüfer schrieb: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.
Hallo @Softwareprüfer,
damit ich Ihnen antworten kann, musste ich mich erstmal bei ein paar Kollegen technisch aufschlauen 😊
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?
An der Ecke kann ich Sie in insofern beruhigen, als dass wir vor dem Download den Hashwert der angeforderten Dateien überprüfen und erst nach Übereinstimmung der eigentliche Download stattfindet.
Viele Grüße
Stefanie Herold
@Dirk_Jendritzki schrieb:
... Von der Startseite aus, richtig? ..
... manchmal ja, ........ oft aber auch nein
... da ich oft "eingeloggt bleibe", sind i.d.R. bereits 1 oder mehrere Fenster mit Community-Threads dauerhaft geöffnet.
Ich springe dann nur zu den neuesten (ungelesenen) Posts oder ich lasse den "Benachrichtigungs-Feed" anzeigen (Symbol "Glocke") und springe dann von dort direkt zum entsprechenden Post
... aber mein eigenes Nutzungsverhalten ist natürlich nicht unbedingt repräsentativ für die Mehrheit der Community-Mitglieder
... wenn die Meisten hier keinen Optimierungsbedarf sehen oder wenn die Änderung programmiertechnisch zu aufwändig wäre, dann ist das auch ok ...
... jeder hat eben seinen eigenen, individuellen 'Tunnelblick' und seine eigenen 'Trigger'
edit:
... man könnte eben zukünftig auch andere wichtige "ad hoc"-Nachrichten ("breaking news") auf diese Weise schnell 'an den Mann oder an die Frau bringen', z.B. auch aktuelle Störungen im RZ oder Sonstiges
@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
Nachtrag:
... bei der Farbwahl für das weiß-blaue Hinweisfenster muss sicher auch berücksichtigt werden, dass weiß-blau in Bayern 'eine gewisse Bedeutung' hat.
... vielleicht gibt es ja auch entsprechende Verwaltungsvorschriften 😎
... habe soeben einem selbstbuchenden Mandanten (stolzer Anwender von "Mittelstand Faktura mit Rechnungswesen") beim Download und beim Installieren der Hotfixe per Fernbetreuung geholfen.
... es war zunächst unklar, ob wieder ein Riesenpaket von 2,x GB heruntergeladen werden muss
... nein, es waren nur die kleinen Hotfixe
... irritierend war aber, dass nach dem Anklicken von "Arbeitsplatzinstallation" der Hotfixe zunächst 'Ruhe im Karton' war. Es passierte einfach nichts, null, nada, niente ...
... erst nach einem freiwilligen manuellen Neustart begann die Hotfix-Installation, die danach mit einem erneuten Neustart 'belohnt' werden wollte.
... insgesamt zeitlich nur sehr wenig Aufwand, das war positiv ...
Hallo zusammen,
ich habe mich zum Thema Neustart nach Installation der DATEV-Hotfixes nochmal mit meinen Kollegen ausgetauscht.
In weiteren Test hat sich folgende Erkenntnis herauskristallisiert:
In Summe lässt sich also sagen, dass in der aktuellen Zeit durch sehr viele Updates es praktisch in vielen Fällen zu einem Reboot kommen wird und es auf jeden Fall eine gute Idee ist, die Installation entweder in der Mittagspause oder nach Arbeitsende anzustoßen.
Das macht uns mit der Hotfix-Installation dann zum Überbringer der Reboot-Botschaft 😔
Viele Grüße
Stefanie Herold
Muss ich die Hotfixes vom 20.12. auf dem DATEV-Server, der kein Arbeitsplatz ist, ebenfalls einspielen?
Hallo,
wenn es im Inst.Manager angezeigt wird würde ich es auf jede Fall installieren - und bei mir am Server (ebenfalls kein Arbeitsplatz) wurde das Hotfix BK140029-01760 angezeigt.
Hallo @Softwareprüfer,
die elektronische Softwareauslieferung nutzt wie schon gesagt ein Hashwertverfahren, welches eine Prüfsumme über die RZ-Kommunikation, also auf einem zweiten gesicherten Weg erhält. Damit ist eine Verfälschung der ausgelieferten Programmpakete nur durch zwei von einander unabhängige erfolgreiche Angriffe möglich.
DATEVnet liefert zusätzliche allgemeine Sicherheits-Features, die die Wahrscheinlichkeit eines erfolgreichen Angriffs auf ein Minimum reduzieren:
Alles Weitere würde hier technisch zu sehr in die Tiefe führen. Ich kann Ihnen aber einen persönlichen Austausch mit unseren Experten anbieten. Wenn Sie daran Interesse haben, senden Sie mir bitte Ihre Kontaktdaten über eine persönliche Nachricht.
Viele Grüße
Stefanie Herold