Neu WaWi wurde gehackt

[dc-nico]

Man muss doch nur etwas TV sehen, um sich hier die neusten Standards anzusehen.
Aber die Gefahr ist doch hier gar nicht das feuer, sonder Hacker-Angriffe.
Und diese erfolgen auf große Server, wo eben Schaden angerichtet werden kann oder Daten gestohlen werden.
Wenn ma dann die aktuellen Konflikte sieht, liegt ein Hackerangriff gar nicht mehr so weit entfernt.
Da sind dann auch schnell ein mal die leitungen weg und Internet geht nur noch über Satellit.

Aber ist auch egal, da jeder selbst entscheidet, was hier in Frage kommt.
uwego hat ja geschrieben was passiert ist.

 

[sebjo82]

Vermutlich hast Du noch nie ein Rechenzentrum von innen gesehen. Die Server sind heute weitestgehend virtualisiert, brennt irgendwo ein Stück Hardware ab - sprich geht kaputt, bemerkt man dies als Anwender gar nicht, da die Systeme automatisch auf andere Hardware geschoben wird. Da werden keine Backups eingespielt.

Eine gutes RZ ist nach ISO27001 zertifiziert, darin sind alle relevanten Dinge wie Löschanlage, Zugangsschutz usw. klar geregelt. Wenn man dann noch eine Automatik hat die die Sicherungen noch zu einem anderen RZ (min. 500km) entfernt überträgt, ist man schon ziemlich gut dabei. Als Krönung noch das Sicherungsscript von Casitec, dann ist man extrem abgesichert.

Komisch, mein Server hat bessere Uptime als diese ganzen high-availability Systeme. Klingt alles schön in der Theorie aber mein alter Laptop bügelt die Rechenzentren easy weg. Der läuft noch nichtmal als HA, einfach Windows Server drauf und fertig

 

[Enrico W.]

Man muss doch nur etwas TV sehen, um sich hier die neusten Standards anzusehen.

Und mit ein paar Youtube-Videos spart man sich das Medizinstudium.
Sorry, das ist sicherlich etwas überzogen, soll aber zeigen, wo das Problem liegt.

Hier war der AUSLÖSER, dass die DB gehackt wurde. Das reduziert aber nicht die Gefahren.
Wenn Du Deinen PC und Deine Sicherungen im selben Raum hast, dann ist Feuer oder - je nach Lage - auch Hochwasser und Sturm sehr wohl eine große Gefahr, das ganze Geschäft zu verlieren.
Und nur weil größere Anbieter ein schöneres Ziel bieten ist man nicht sicher. Bots unterscheiden nicht zwischen kleinen Händlern und Riesen.
In sofern geht mein Rat dahin, auf die Stimmen der Vernunft zu hören.
Wenn man schon alles selbst machen will - also auch die Sicherungen - dann gehört als Mindestschutz dazu, dass die auch räumlich getrennt vom Server aufbewahrt werden.

 

[sebjo82]

Nicht nur räumlich getrennt, sondern mit dezentralen Zugangsdaten, d.h. keine Push-Methode auf die Speicherorte, sondern via Pull (nur Leserechte) auf die Endsicherungsorte ziehen lassen, damit im Falle von Kompromitierung nicht direkt alles angegriffen werden kann

 

[Enrico W.]

@sebjo82
Du hast vollkommen Recht.
Ich sprach da auch nur von einem absoluten Minimum.
Aber leider ist das Thema Sicherungen immer erst dann ein Thema, wenn das Kind in den Brunnen gefallen ist.

Oder wie ich es ausdrücken würde:
Leute die sagten "Ich kann das alleine" sagten auch "Wie kriege ich jetzt meine Daten zurück?" und "Was sage ich dem Finanzamt?".

 

[NoOne]

Nicht nur räumlich getrennt, sondern mit dezentralen Zugangsdaten, d.h. keine Push-Methode auf die Speicherorte, sondern via Pull (nur Leserechte) auf die Endsicherungsorte ziehen lassen, damit im Falle von Kompromitierung nicht direkt alles angegriffen werden kann

Nicht genug. Das steht und fällt mit der Vorbereitung des Angriffs. Da fehlen immutable Backups (! das ist mit der wichtigste Punkt. Backups die nicht geändert, überschrieben oder gelöscht werden können (auch nicht von einem admin, in der Regel Zeitbasierend) sind hier das A und O) und Versionierung. Und top-of-the-line ist nicht nur ein air-gap, sondern auch eine Offline-Kopie.

Dezentrale Zugangsdaten helfen natürlich, und auch der Pull, aber eben auch nur solange bis die Zugangsdaten zum Backupserver bekannt sind. Der muss ja trotz allem in irgendeinem Netz sein. Entweder im LAN und zugänglich über VPN oder im Internet. Sonst kann er auch nicht Pullen. Und regelmässige Rückspieltests müssen da auch sein. Ein vorhandenes Backup das nicht zurückgespielt werden kann nutzt dir nix. Für die best practice muss man schon ein bissel Aufwand betreiben.

 

[sebjo82]

Nicht genug. Das steht und fällt mit der Vorbereitung des Angriffs. Da fehlen immutable Backups (! das ist mit der wichtigste Punkt. Backups die nicht geändert, überschrieben oder gelöscht werden können (auch nicht von einem admin, in der Regel Zeitbasierend) sind hier das A und O) und Versionierung. Und top-of-the-line ist nicht nur ein air-gap, sondern auch eine Offline-Kopie.

Dezentrale Zugangsdaten helfen natürlich, und auch der Pull, aber eben auch nur solange bis die Zugangsdaten zum Backupserver bekannt sind. Der muss ja trotz allem in irgendeinem Netz sein. Entweder im LAN und zugänglich über VPN oder im Internet. Sonst kann er auch nicht Pullen. Und regelmässige Rückspieltests müssen da auch sein. Ein vorhandenes Backup das nicht zurückgespielt werden kann nutzt dir nix. Für die best practice muss man schon ein bissel Aufwand betreiben.

Es geht darum sich für den Fall abzusichern dass der zentrale Backup-Server gehackt wird. Wenn das passiert und von hier aus korrupte Backups an die Speicherorte geschickt werden und eventuell sogar alte überschrieben / gelöscht werden, haste verkackt. Dafür die Pull-Methode, dass wenn ein Server fällt, alle anderen weiterhin funktionieren und man zumindest alte Backups zur Verfügung hat, je nachdem wie früh man den Hack erkennt. Mit der Pull-Methode erreichst du Immutability quasi automatisch, da diese Methode nur versagt, wenn der Hacker gleichzeitigen Zugriff auf alle Speicher-Server bekommt, statt nur einen bei der Push-Methode. Immutability ist nicht leicht umsetzbar, Pull schon

 

[SebiW]

Ich finde es immer interessant, wie hoch die Ansprüche an lokale Systeme gestellt werden. Gleichzeitig werden die zusätzliche Anfälligkeiten von Cloudsystemen geflissentlich ignoriert.
In einem lokalen System bin ich von einer ganzen Reihe an Cloudgefahren schlicht nicht betroffen.
Das geht schon damit los, dass ich, anders als bei gehosteten Systemen, direkt das Ziel des Angreifers sein muss. Das fängt schon auf der menschlichen Ebene an. Ich bin nicht durch Angriffe auf die Mitarbeiter und Infrastruktur des Rechenzentrums angreifbar. Große Rechenzentren sind ein erheblich interessanteres Ziel als wir kleine Klitsche. Bei uns lohnt sich langatmiges spearfishing und gezielte Ausnutzung von zero day Lücken schlicht nicht. Aufwand und Ertrag stehen in keinem Verhältnis.

Außerdem fallen viele große Angriffsszenarien grundsätzlich raus. Spectre, Meltdown etc sind schlicht kein Thema wenn keine fremden Systeme auf der gleichen Hardware virtualisiert werden.
Kurz, meine externen Angriffsszenarien sind deutlich überschaubarer. Und die übrigen werden zu 99,9% durch das aktuell halten von Software abgedeckt.
Sowas hier kann mir lokal nicht passieren: https://borncity.com/blog/2026/03/2...n-ihre-jtl-wawi-daten-verloren-23-maerz-2026/

Natürlich sind Backups etc ein Thema. Wie das sinnvoll zu lösen ist wurde hier im Thread ja schon mehrfach beschrieben. Und wenn ich wirklich gar keine Ahnung von IT Infrastruktur habe sollte ich das ganze nicht unbedingt selber zusammenklöppeln. Wenn man aber halbwegs weiß was man tut und vielleicht sogar zusätzliche Faktoren ins Spiel kommen (bspw schlechte Internetanbindung) ist meiner Meinung eine lokale Instanz im Normalfall performanter, langfristig günstiger und keinesfalls unsicherer als eine Cloud Lösung. Und unsere lokalen Ausfallzeiten über 10 Jahre liegen noch immer locker unter dem was Hetzner etc für ein Jahr garantiern...

Wohlgemerkt: Ich rede hier über die Cloud. Shop hosten wir auch extern, alleine schon weil hier natürlich der entsprechende Datendurchsatz eines Rechenzentrums benötigt wird.

Edith sagt: Ich hab mal meine drölfzig "schlicht" durch ein paar andere Füllwörter ersetzt

 

[wawi-dl]

Es geht darum sich für den Fall abzusichern dass der zentrale Backup-Server gehackt wird. Wenn das passiert und von hier aus korrupte Backups an die Speicherorte geschickt werden und eventuell sogar alte überschrieben / gelöscht werden, haste verkackt. Dafür die Pull-Methode, dass wenn ein Server fällt, alle anderen weiterhin funktionieren und man zumindest alte Backups zur Verfügung hat, je nachdem wie früh man den Hack erkennt. Mit der Pull-Methode erreichst du Immutability quasi automatisch, da diese Methode nur versagt, wenn der Hacker gleichzeitigen Zugriff auf alle Speicher-Server bekommt, statt nur einen bei der Push-Methode. Immutability ist nicht leicht umsetzbar, Pull schon

Wir wollten unsere aktuelle Backup-Strategie (haben aktuell 1+2) um Backblaze B2 Cloud Storage erweitern.
Die haben ein ObjectLock Verfahren, damit RansomWare hier nicht alles kompromitieren kann.

Was hälst du denn für so etwas bzw. was nutzt du als PULL-Verfahren?

 

[FOC Solutions]

Es geht doch bei dem Thema auch um die Verhältnismäßigkeit, grundsätzlich gilt, kein System ist unangreifbar. Das Kosten/Nutzen Verhältnis muss irgendwie passen. Genau wie der allgemeine Einbruchsschutz, ich sichere mein Haus so weit ab, dass die bösen Leute lieber zum Nachbarn gehen.

Als One-Man Show kann ich mich i.d.R. nicht wirklich um meine IT-Sicherheit kümmern. Der Aufwand steht in keinem Verhältnis.
Als 2-8 Personen KMU sie es meist noch so aus wie bei der One-Man Show
Darüber hinaus habe ich langsam schon eine umfangreichere IT, so dass ich über IT Personal und entsprechende Infrastruktur nachdenken muss. Hier kann eine Inhouselösung Sinn machen.

Wenn ich jetzt sowieso IT Expertise habe, so kann ich dass auch bei kleineren Unternehmen umsetzen. Wichtig ist nur, dass man weiß was man tut.

 

[SebiW]

Das Problem mit externalisierter Expertise ist halt immer: Kann ich die Qualität der Dienstleistung nicht einschätzen bin ich auf Gedeih und Verderb dem guten Glauben überlassen. Das gilt auch für das weitere Geschäftsgebahren des jeweiligen Partners. Siehe aktuelle Preiserhöhungen beispielsweise bei Ecomdata, aber auch bei den ganz großen Fischen wie Hetzner, Strato und Ionos.

Innerhalb dieses Jahres sind bereits zwei Servicepartner / Hoster geknallt, MoSo und MIDe. Einmal Insolvenz, einmal Hacker. Solution 360 ist gerade in Insolvenz in Eigenverwaltung. Wie es aussieht machen die das gut. Zum Glück, wir haben einige tolle Plugins von denen . Aber wir reden hier auch über eine der größten JTL Partneragenturen.

Nicht wenige kleine und auch mittlere Hoster dürften von der Hand in den Mund leben. Hardware ist in den letzten Monaten EXTREM teuer geworden. Die meisten haben auch keine eigenen Serverfarmen sondern mieten bei den Großen an. Die Preissteigerungen selbiger schlagen also direkt durch. Eng kalkulierte Geschäftsmodelle kommen da schnell ins Wanken.
Es spricht wenig dafür, dass der Weg ins externe Hosting sicherer ist als eine selbst gehostete, auch nur halbwegs gescheit abgesicherte Lösung.

Ganz ehrlich, da würde ich selbst als Einzelkämpfer eher nenn gebrauchten Laptop hinstellen (und falls ich wirklich gar keine technische Kompetenz habe den halt für mich aufsetzen lassen). Sicherung in ne Hetzner Storage Box für 4 Euro im Monat und das Thema ist durch.

 

[sebjo82]

Wir wollten unsere aktuelle Backup-Strategie (haben aktuell 1+2) um Backblaze B2 Cloud Storage erweitern.
Die haben ein ObjectLock Verfahren, damit RansomWare hier nicht alles kompromitieren kann.

Was hälst du denn für so etwas bzw. was nutzt du als PULL-Verfahren?

kostet der speicher extra? wenn das überschaubar ist, ist immutable storage natürlich geil. ansonsten eine einfache pull-infra lässt sich mit ftp einrichten oder ssh mit den jeweils korrekten berechtigungen

 

[NoOne]

Es geht darum sich für den Fall abzusichern dass der zentrale Backup-Server gehackt wird. Wenn das passiert und von hier aus korrupte Backups an die Speicherorte geschickt werden und eventuell sogar alte überschrieben / gelöscht werden, haste verkackt. Dafür die Pull-Methode, dass wenn ein Server fällt, alle anderen weiterhin funktionieren und man zumindest alte Backups zur Verfügung hat, je nachdem wie früh man den Hack erkennt. Mit der Pull-Methode erreichst du Immutability quasi automatisch, da diese Methode nur versagt, wenn der Hacker gleichzeitigen Zugriff auf alle Speicher-Server bekommt, statt nur einen bei der Push-Methode. Immutability ist nicht leicht umsetzbar, Pull schon

Das war mir schon klar und ich sage dir: Das ist nicht genug. Ransomware-Angriffe laufen in den meisten Fällen nicht gegen einen einzelnen Server, sondern gegen alle gleichzeitig. Die werden vorbereitet, und zwar meist gut. Die Devise ist: Backups möglichst so zu bauen, das ein Angreifer sie auch im Erfolgsfall *nicht* zerstören kann. Also selbst wenn er Zugriff auf *alles* hat.

Wenn du Backups pullst, dann sorge ich dafür, dass du unbrauchbare Backups pullst. Ob du pushst oder pullst ist egal, wenn der Quell-Server kompromittiert ist. Wenn die Pull-Server dann soweit sind, dass sie alte Backups löschen, weil der Speicher knapp ist, dann hast du nur noch unbrauchbare Backups und dann verschlüssele ich deine Daten. Daher ist das regelmäßige Überprüfen der Funktionalität der Backups auch wichtig.

Einfach zu sagen: Jo, Pull deine Backups, dann bist du auf der sicheren Seite, ist halt gefährlich. Du musst trotzdem dafür sorgen, dass die Backups geprüft werden, die Pull-Server ordentlich absichern und restores regelmässig testen. Du verschiebst die Angriffsfläche, aber du machst dich durch einen pull nicht unverwundbar. Der Gedanke ist gefährlich.

 

[Martin1977]

Man kann das alles sehr sicher machen wenn man selber hostet. Ich drucke mir jeden Tag alle Kundenstammdaten auf DIN A4 aus, dazu alle Artikelstammdaten, die Produktbilder habe ich alle mal in 13x18cm ausdrucken lassen. All das bringe ich jeden Tag in ein Bankschließfach. Es kann also im Grunde genommen in der Atmosphäre eine Atombombe explodieren und einen EMP Impuls aussenden, nach ein paar Tagen Eintipperei bin ich wieder onlilne 🤣

 

[hula1499]

Solution 360 ist gerade in Insolvenz in Eigenverwaltung.

Danke für den Hinweis, haben zwar nur 1 Plugin von denen, aber trotzdem gut zu wissen - im Fall der Fälle.

nach ein paar Tagen Eintipperei bin ich wieder onlilne

Kein Vertrauen in die Ameise?

 

[Martin1977]

Danke für den Hinweis, haben zwar nur 1 Plugin von denen, aber trotzdem gut zu wissen - im Fall der Fälle.

Kein Vertrauen in die Ameise?

Doch, ich habe sogar sehr viel Vertrauen in meine Leistungen. In den letzten 35 Jahren eigene IT in der Firma habe ich noch nie ein Byte verloren. Habe aber auch immer gerne in gute Klamotten investiert. Aktuell habe ich
1 Hauptserver, da läuft Proxmox drauf. Windows Server wird dort regelmäßig gesichert, die Datenbank alle halbe Stunde. Sicherungen liegen auf einem QNAP Nas das sich bei mir zuhause befindet, da habe ich schon mal keine Probleme mit Feuer, Wasser usw. Zusätzlich lade ich einmal in der Nacht die Datenbank in ein Cloud Backup.
Dazu steht ein 2. alter Server bereit, der ist fast immer aus, ich pflege nur einmal im Monat das Proxmox Repository um es identisch zu halten.
Schmiert also der Server ab bin ich in wenigen Minuten wieder online. Das bekomme ich aus dem Urlaub hin so dass meine Mitarbeiter nur warten müssen bis ich da go gebe.

Vorteil ist auch dass man ohne Probleme JTL Updates installieren kann ohne sich sein ganzes System zu zerschiessen.

Für mich würde es jedenfalls nie in Frage kommen meine Firmendaten extern zu hosten, egal was es kostet.

 

[SebiW]

Wir wollen hier auch mal die Kirche im Dorf lassen. Kompetenz und Commitment eines Angreifers definieren ob ein System platzt oder nicht. Die wenigstens von uns werden als Ziele relevant genug sein um wirklich maßgeschneiderte Attacken zu fahren. Ziel muss für die meisten von uns also sein die üblichen Driveby Attacken zu vermeiden.

Dafür braucht es üblicherweise nicht viel mehr als aktuelle Systeme, vernünftige Schulung im Umgang mit Mails usw und für die dann noch offenen Probleme wie Hardwaredefekte etc ne gescheite Backupstruktur. Will ich nicht zu lange warten bis was kaputtes umgezogen ist: redundante Hardware und der ganze Summs am besten virtualisiert.

Ist das best practice für eine Cloud Hoster wie Amazon? Ganz sicher nicht. Wir werden aber zeitnah auch nicht von einem 50 Mann Trupp aus Nordkorea oder Russland mit spear fishing und social engineering attackiert werden. Die paar Euro die es hier zu holen gibt sind den Aufwand nicht wert. Die aktuellen Attacken rund um npm zeigen ja, wieviel Aufwand da dann getrieben wird.

 

[Enrico W.]

Wenn man das auf Angriffe einschränkt: Ja.
Es drohen aber noch wesentlich mehr Gefahren.
Und da ist die externe Festplatte, die gerade nicht mehr laufen will, noch eine der harmloseren.
Daher ist es in meinen Augen richtig und wichtig, das Bewusstsein dafür zu schärfen statt das ganze zu verharmlosen.
Und ja - ich habe stellvertretend durch Kunden schon alles erlebt von "Ich hab noch nie die Datenbank gesichert" über "Die Festplatte ist abgeraucht" bis hin zu "Der Rechner ist abgebrannt".

 

[FOC Solutions]

Wenn man das auf Angriffe einschränkt: Ja.
Es drohen aber noch wesentlich mehr Gefahren.
Und da ist die externe Festplatte, die gerade nicht mehr laufen will, noch eine der harmloseren.
Daher ist es in meinen Augen richtig und wichtig, das Bewusstsein dafür zu schärfen statt das ganze zu verharmlosen.
Und ja - ich habe stellvertretend durch Kunden schon alles erlebt von "Ich hab noch nie die Datenbank gesichert" über "Die Festplatte ist abgeraucht" bis hin zu "Der Rechner ist abgebrannt".

Da habe ich noch einen: "Meine Katze hat auf den Laptop gepinkelt, jetzt funktioniert er nicht mehr", tatsächlich bei einem Kunden in der vor JTL Zeit erlebt.

 

[SebiW]

Ich zitiere mich dazu mal selbst:

für die dann noch offenen Probleme wie Hardwaredefekte etc ne gescheite Backupstruktur. Will ich nicht zu lange warten bis was kaputtes umgezogen ist: redundante Hardware und der ganze Summs am besten virtualisiert.

Ist nicht so dass ich das nicht genauso sehen würde

Aber potentielle Hardwaredefekte sprechen nicht gegen lokales Hosting und relativieren in meinen Augen nicht die Nachteile von Cloudlösungen.