Ich gehe davon aus, dass die Zahl der Leser, die noch Solarwinds-Produkte in ihrem Umfeld haben, gering sein dürfte. Gestern ist mir ein Fundsplitter untergekommen, die in hier im Blog einstellen möchte. Einem Benutzer sind Hunderte von fehlgeschlagenen Anmeldeversuchen aus der Solarwinds-VM seines Unternehmens zu anderen internen Servern aufgefallen. Könnte eine mögliche System-Kompromittierung sein, weshalb er den Fall im Internet diskutiert hat. Ich habe das mal kurz Überflogen: Fall von IT aus der Hölle – keiner weiß da Bescheid, und mir stellt sich die Frage, "ob dies der Standard da draußen ist".
Anzeige
Das Ganze ist mir auf BlueSky in nachfolgendem Tweet untergekommen – der Fall wird auf reddit.com im Thread Getting hundreds of failed login attemps from our solarwinds VM to all other servers and VMs. This is not normal, right? diskutiert.
Die Person war neu im Unternehmen und dort war man dabei SIEMs (Security Information and Event Management) und IDPS (Intrusion Detection and Prevention System) zu implementieren. Da schaut man dann mal genauer hin, und dabei ist aufgefallen, dass es Hunderte von Anmeldeversuchen gibt, die von einer Solarwinds-VM auf die anderen Server, darunter unser E-Mail-Server, Dateiserver usw., erfolgen.
Die Arbeitstheorie ist, dass die Maschine kompromittiert ist, und was dort auch immer werkelt (Hacker / Malware) versucht, auf andere Systeme über Brute-Force zuzugreifen. Er selbst kennt das Solarwinds-System nicht (wurde als Legacy-System von früheren IT-Team implementiert).
Anzeige
Das Ganze ist ein Alptraum, denn der Benutzer schreibt, dass niemand der IT-Mitarbeiter je mit dem Solarwinds-System in der VM gearbeitet habe. Niemand weiß, wozu das gut ist und was es macht. Das gesamte Team, welches das ursprüngliche System aufgesetzt hat, hat inzwischen das Unternehmen verlassen. Der einzige Grund, warum der Server noch läuft, seit, ist, dass die Leute zu viel Angst haben, etwas kaputt zu machen, wenn sie ihn abschalten. Denn keiner der Angestellten hat die Zugangsdaten für ein Login an der betreffenden VM. Die VM sei auch "seit Jahren" nicht mehr gepatcht worden.
Fall von "IT aus der Hölle". Nun fragte der betreffende Mitarbeiter bei reddit.com nach, ob es eine legitime Erklärung für dieses Verhalten der Solardwinds-VM gebe. Ein Nutzer meint, dass es ein altes Passwort im Solarwinds Oorion Credential Manager sein könne, welches für die gescheiterten Anmeldeversuche zuständig ist. Der Thread ist jetzt zwei Tage alt – aber eine Lösung (z.B. VM abgeschaltet, nix passiert) habe ich noch nicht gesehen.
Frage: Ist das die "Arbeitsumgebung" die ihr als IT-Freelancer oder Administratoren draußen bei den Unternehmen vorfindet – oder ist das alles sauber dokumentiert? Ich frage für einen Freund, der vom "Job als Systemadministrator träumt, ganz viel dicke Kohle verdienen und einen Porsche fahren will", und dem ich erzählt habe, dass Firmen und Organisatoren reihenweise gehackt werden.
Anzeige
Was für ein Solarwinds-Produkt ist es denn? Es gibt ja schon recht viele… Wir haben auch ein Monitoring-System im Netz, nicht von Solarwinds, dort kann man sowas auch einstellen, dass es versucht über TCP 135/445/…, also die typischen SMB/RPC/Remote-PS-Ports in den bekannten VLANs scannt und versucht, so Systeme zu erfassen, um sie zu katalogisieren, mit dem Bestand im AD abzugleichen oder gar eine Alarmierung bei verdächtigen Aktivitäten ausgehend von diesem System auszulösen.
Wenn ich mich nicht verlesen habe, wurde das nie angegeben – es weiß ja niemand mehr, wozu das gut ist. Ein Mutterunternehmen hat die VM wohl aufgesetzt und die Tochter ist inzwischen eigenständig – und irgendwo läuft die VM vor sich hin. Ich vermute, der Mitarbeiter wird die VM suspendieren müssen und kann dann schauen, ob was nicht mehr läuft.
Ich würde vorsichtiger erst einmal nur den Netzwerkverkehr der VM blockieren, die Maschine aber weiter laufen lassen. Wer weiß denn, ob das Suspend/Resume alle laufenden Dienste klaglos überstehen bzw. nach einem Neustart alle Dienste automatisch korrekt starten?
Und ich würde alle Hebel in Bewegung setzen um wenigstens einen der damals Verantwortlichen zu finden, der zur Aufklärung beitragen kann.
Kluger Vorschlag, mit der Blockade des Netzwerkverkehrs. Zum "alle Hebel in Bewegung setzen" – ich weiß nicht, ob es in den USA spielt, aber da sind die Leute dann nach einigen Jahren in alle Winde verstreut – vielleicht kann der Betroffene über Facebook oder LinkedIn nachforschen, ob er die Mitarbeiter von damals ausfindig machen kann. Wenn ich mir aber mal vergegenwärtige, dass ich noch Details für Test-VMs, die ich vor sieben, acht Jahren aufgesetzt habe, nennen soll, sehe ich schwarz. Was nicht in meiner Kladde steht, ist halt verloren …
Was ein Chaos!
Aber wenn man die VM auf einem eigenen Host hat, kann man ja mal gucken, ob man wenigstens auf dem Hypervisor einen Kommentar in den VM-Eigenschaften findet, oder ob man mal auf die Konsole kommt, um zu schauen, was sie da meldet und behauptet zu sein…
warum nicht einfach die vm clonen und den clone ohne virtuelle nic analysieren? hätte sogar den vorteil den attacker mit analysen zu alarmieren.
zu der frage ob das normal sei… zu oft ja.
Ja, das ist – vielleicht nicht ganz so krass – Realität. Dokumentation ist eher selten, und alte Systeme aus "Sicherheitsgründen" nicht anzufassen ist auch usus.
Und dicke Kohle, Porsche als Sysadmin? Herrje, ich mache ganz offenkundig was falsch…
Nun ja, dat mit dem Porsche war nur ein Teaser. Spoiler: Es gab mal einen kleinen Stift namens Günni, der saß schwitzend und fluchend als Elektriker in Nähe eines Brennofens in einer Ziegelei und musste Kabel verlegen (dürfte so 1971 gewesen sein). Da fuhr jemand im feinen Zwirn im Porsche vor und erklärte dem Meister, was er zu tun habe. Dem kleinen Elektrolehrling war klar "dat is een Porsche und dat im feinen Zwirn is ein Engineeeer". Und so manifestierte sich der Gedanke: "Junge, dat willst Du auch", also nach der Lehre den Arsch auf die Schulbank gehievt und nach so 5 Jahren war man auch Ingenieur. Nur irgendwann im Studium den "IT-Virus aufgeschnappt", auf die falsche Bahn geraten und als nichtsnutziger Blogger geendet.
Nix Scheiß – ich habe es als (Be)/Erkenntnis mal drüben im Beitrag Der Jung soll was anständiges lernen offen gelegt. Ist mein Beitrag zur Chaos-Theorie: "Irgendwo fährt jemand mit einem Porsche vorbei, macht mächtig Wind, und Jahre später fällt ein junger Ingenieur mit Porsche vom Fließband". Ob das immer klappt? Lässt sich nach Chaos-Theorie nie so genau sagen – manchmal fällt ein Porsche auch einem Baum zum Opfer. Aber hey, der Porsche war uns nach Erreichen des ersten Ziels janz egal – oder wie der Kölner sagt "et kütt, wie et kütt". Nur jemand, der die Schulbank als Nachbar gedrückt hat, erzählt mir vor einigen Jahren, dass er sich als Ingenieur einen Porsche geleistet habe ;-).
Wir setzen den SolarWinds Access Rights Manager, ehemals 8man ein.
Sehr umfangreiches Rechte und User Managementsystem und wesentlich einfacher zu konfigurieren als Tenfold.
Das setzt aber zum Glück nicht auf die Orion Plattform und ist somit auch von dem SupplyChain vor ein paar Jahren nicht betroffen.
Da es sich bei 8Man (ehemals protected networks) um ein deutsches Produkt handelt könnte ich mir vorstellen, dass es gar nicht so selten im Einsatz ist. Auch wenn es nun auf SolarWinds umgelabelt wurde.
Zu deiner Frage, ob ein derartiges Chaos üblich ist:
Also jedenfalls im Mittelstand ist das wohl eher der Regelfall. Selbst bei uns (und wir sind m. E. für die Zahl der Büroarbeitsplätze noch vergleichsweise gut aufgestellt) bin ich in den paar Jahren, die ich jetzt hier die IT mitbetreue, schon über diverse Stellen gestolpert, von uralter Software über Systeme und Systemfunktionen, bei denen irgendwelche Passwörter hinterlegt sind, die niemand kennt – weder der Kollege, der die Sachen zuvor alleine betreut hat, noch der "Haus-und-Hof"-IT-Dienstleister. Inklusive automatisch erstellte Config-Backups für kritische Systemkomponenten, die mit einem PW verschlüsselt werden, welches niemand kennt. Oder Systeme mit kryptischen Namen in der Domäne, die initial niemand zuordnen kann. Und ähnliche Geschichten… Dokumentation gibt es wenig bis gar nicht.
Nur mal als Referenz für die Relevanz unseres Betriebes: Größenmäßig fallen wir als mittleres Unternehmen unter NIS2 (die Branchendefinition hingegen ist noch nicht geklärt).
Ja, das ist leider normal geworden. Firmen liegt nichts mehr an der langfristigen Bindung zu Mitarbeiten. Die lassen lieber jemand gehen, als Inflationsausgleich (nicht Gehaltserhöhung!) korrekt zu machen.
Ich habe zuletzt in einem großen Forschungsinstituten gearbeitet. Ein Aushängeschild der Republik Österreich. Innerhalb von 4 Jahren sind dort 6 von 8 Kollegen und 2 Teamleiter gegangen. Management und IT waren eine Katastrophe. Überall Systeme, die nicht dokumentiert waren. IT Leiter hatte Einfälle wie "Ich habe ein Testsystem am Wochenende aufgesetzt. Bringt das in Produktion!". Völlig irre, ohne Planung, Schulung, Doku usw
Einuge Zeit nachdem ich weg war, wurden sie gehackt, das war nur eine Frage der Zeit. Derzeit liegt die Verweildauer in der IT bei 8 Monaten. Bisher nicht gegangen: IT Leiter und Administrativer Direktor. Die tragen ja nur die Verantwortung….
Naja wenn in der IT Leute gehen hat das nicht unbedingt mit Mängel seitens der Firma zu tun. Gut ich habe nur ein kleines Unternehmen (30 Angestellte).
Im Schnitt sind die Mitarbeiter 10+ Jahre in der Firma, außer in der IT! DA ist viel Spreu dabei, manchmal überstehen die nicht mal die Probezeit, aber was sich da als ITler bezeichnet… Pech halt auch wenn der Cheffe vom Fach ist ;-P
Wenn das das Monitoring ist, dann ist das normal. Scant wahrscheinlich das Netzwerk nach neuen Nodes.
"Black Boxen" wie diese sind in vielen Firmen leider auch normal. Fehlende Dokumentation, weil dafür nie Zeit war und auch kein Wert darauf gelegt wurde.
Ich wurde mehrmals wegen meiner Fähigkeit, gut und gerne zu dokumentieren, eingestellt. Aber das geht nicht immer gut, vor allem, wenn es den Chef bloßstellt, der selbst gar nichts dokumentiert. Oft, um das eigene Unwissen zu kaschieren. Das sind dann die, die alles können – und sich in Wahrheit nur gut verkaufen können. Vielen Führungskräften gefällt das aber, und so hat man am Ende viele Blender in der IT, die sich gegenseitig decken. Dokumentation ist da natürlich der Feind.
> Vielen Führungskräften gefällt das aber, und so hat man am Ende viele Blender in der IT, die sich gegenseitig decken.
Gute Zusammenfassung. Ein Elfenbeinturm voller "alternativloser" Lemminge.
Schön ist natürlich auch, wenn man extra jemanden einstellt zum Dokumentieren – aber nur mit kurzer Sachgrundbefristung. Wenn alles fertig dokumentiert ist, kann der wieder gehen, Job ist ja erledigt. "Wie, wir sollen fortlaufend auch alle neuen Prozesse und Veränderungen dokumentieren? Ne, das ist jetzt erledigt, das reicht jetzt."
Ich habe solche Dinge in kleinen und großen Unternehmen erlebt. Dokumentation ist fast immer lückenhaft, geht aber auch mir teilweise so, dass in Projekten unter Zeitdruck nicht alles dokumentiert wird. Man ist dann immer der Meinung, dass das Wesentliche festgehalten wurde und stellt dann ein paar Jahre später fest, dass ein entscheidendes Detail fehlt.
Im konkreten Fall könnte man aber schon mit ein paar Infos mehr weiterkommen, da ist noch etwas Analyse notwendig und auch möglich:
– Ist das immer der gleiche User, sind das wenige User oder viele verschiedenen User (höchste Alarmstufe!!), die da Anmeldeversuche generieren?
– Schon mal auf die Console der VM geschaut, was da für ein OS läuft, vielleicht sieht man da auch das Produkt?
– Über welche Protokolle laufen die Anmeldeversuche?
– Kommuniziert die VM mit dem Internet?
Einfach noch etwas strukturierte Analyse der Daten durchführen, im Zweifelsfall könnte auch ein Blick auf die LAN-Pakete der VM helfen.
(Ich habe jetzt nicht die kompletten Kommentare im Reddit gelesen…)
Wenn es sich um eine VM handelt, dann sollte doch die Möglichkeit bestehen über den Hypervisor eine Kopie der Machine zu ziehen. Veeam B+R kann z.B. im Rahmen von SureBackup auch eine Datensicherung in einer isolierten Umgebung als lauffähige Maschine starten, so dass die Funktion getestet werden kann.
Eine solche Kopie wäre eine gute Grundlage für weitere Untersuchungen und Tests:
– Welches OS läuft in der VM
– Sind die Platten verschlüsselt oder nicht
– usw.
Dann kann man sehen wie man wieder Zugriff auf die VM bekommt. Bei Windows kann man lokale User oder Admins sehr leicht knacken, wenn man Zugriff auf die Platte hat. Dazu könnte man z.B. die Festplatte an eine andere VM mounten und dann entsprechend modifizieren. Da man auf einer Kopie arbeitet, ist auch ein Fehlschlag nicht schlimm. Einfach mit einer sauberen Kopie nochmal starten.
Asap abschalten, völlig egal für was das System gut ist. Die Jungs können dann nur auf Anrufe warten. In der Zwischenzeit alle anderen Systeme forensisch untersuchen.
Alternativ vom LAN trennen und auf Probleme warten.
Letzteres ist dem Abschalten auf jeden Fall vorzuziehen.
Wenn nicht bekannt ist, ob die entsprechende VM irgend eine Aufgabe im LAN übernimmt, würde ich die Maschine möglichst nicht manipulieren, also kein Suspend/Restore und kein Shutdown/Boot sondern eher die Netzwerkanbindung im HV blockieren und dann die anderen Maschinen im LAN hinsichtlich Problemen im Auge behalten. Je mehr Tage vergehen, ohne dass es irgendwo zu Problemen kommt, desto geringer wird das Risiko, die VM komplett außer Betrieb zu nehmen.
Sogar das Blockieren der LAN-Anbindung könnte in der VM und folgend im LAN zu ungeahnten Problemen führen, z.B. weil Dienste, die auf eine funktionierende Anbindung angewiesen sind, nach x Stunden/Fehlschlägen sich beenden und nicht mehr vom System gestartet werden.
Das ganz große Los wäre ein ehemals Verantwortlicher, der sich noch erinnern kann, was es mit dem Ding auf sich hat und vielleicht sogar noch ein Passwort hat oder einen Ansatz zu einem Passwort liefern kann.
Wenn die Maschine kompromittiert sein sollte, müsste man das an Datenverkehr erkennen können, der von der VM ins Internet geht. So ganz autark ohne regelmäßige Verbindungen zu einem Kontroll-Server dürfte ein gehacktes System auf Dauer nicht auskommen.
Also die Idee einen Ex-Kollegen zu fragen ist eher müssig. Es ist erstaunlich wie schnell man etwas vergisst das man nicht braucht.
Ich wurde auch Mal gefragt, ob ich das Passwort für eine uralte Maschine wusste. Damals war es noch üblich Passwörter in unkopierbarer Microschrift auf Papierzettelchen (teilweise) zu notieren und immer bei sich zu tragen und nicht etwa in irgendwelchen Passwort managern, ohne die dazu gehörigen User und Rechner Namen (einem Kollegen ist die Geld Börse mit diesem Zettel drin gestohlen worden, es gab nie einen Hackversuch). Da dieser Zettel irgendwann zu voll geworden ist gab's es immer wieder einen neuen.
Irgendwie hatte noch so einen Zettel mit dem uralten Passwort. Wäre ich Ex gewesen hätte ich das natürlich nicht gesagt. Ich hätte ja nicht begründetn können, weshalb ich noch den Zettel habe….
Also die Mühe kann man sich sparen.
Und 'mal unter die Schreibtischunterlage gucken?
Ich würde das Teil abschalten.
Es kann jederzeit der Host hart neu booten oder in dem System irgendwie was schief laufen.
Wenn es dann irgendwo anders knackt, dann wüsste ich wo die Ursache liegen könnte, wenn ich das selbst abgeschaltet habe.
Es ist unwahrscheinlich das danach die Firma steht.
Und wenn doch,wird Cheffecklar, das es eine Regel geben muss:
Ein System für den es keinen Mainterner gibt muss abgeschaltet werden.
Ein System für das es keine Doku gibt mit dem ein Dritter Admin das System zu mindest im Notfall wieder beleben kann, wird abgeschaltet.
Hört sich hart an, aber alles andere ist fahrlässig.
"Aber wir brauchen das System doch"
Aber das kann nicht akzeptiert werden.
An "kein Backup keine Gnade" ist ebenso akzeptiert wie"Kein Backup?Dann waren die Daten wohl nicht so wichtig".
Warum?
Der allwissende Admin könnte morgen früh einen tödlichen Unfall haben, was dann, ohne jede Doku?
BTST, zum Glück gab es ne Doku so dass der Motorrad Unfall des Admins mit wochenlangem Koma keine Folgen für die Firma hatte.
"Kein Doku, System deaktivieren" verhindert auch den naiven Mitarbeiter Trick: Wenn ich nichts dokumentiere können die mich nicht feuern.
Das hat noch nie funktioniert.
Jeder ist ersetzbar.
Wenn der Oberadmin (extern) das undokumentierte System droht abzuschalten wird sich wer melden.
Und wenn nicht, dann war es auch nicht wichtig.
Mit dieser harten Regel wäre es kaum möglich, dass ein Testsystem an der Peripherie "vergessen" wird.
Das soll ja bei einem Bekannten Software Hersteller passiert sein.
Auch könnte kein System weiterlaufen, dessen Passwort nicht geändert wurde nachdem der Kollege die Firma verlassen hatte.
Ja, so ein externer Oberadmin, der ständig nach der Doku guckt kostet. Aber Sicherheit kostet in der Regel Geld, aber weniger als ein wochenlanger Produktionsausfall. Ich weiß jetzt gar nicht was das BSI da empfiehlt, wie man das Erstellen von Doku erzwingen kann…
Ich würde nach der Regel handeln und das System anhalten. Das kann Nebenwirkungen haben, ja. Dann weiß ich aber woher die kommen.
Aber wenn es dann nicht wieder hoch fährt?
Das kann jederzeit auch nach einem Stromausfall passieren. Aber man hätte keinen Hinweis wo das Problem liegt.
Ich würde vorher noch einen Switch vor den Host mit der VM klemmen und das Mirroring aktivieren.
Schauen ob da seltsame Verbindungen nach draußen oder zu anderen Rechnern im LAN erfolgen (die dann nach außen gehen. So könnte man evtl. sehen das das gutartig ist oder nicht.
Due VM abschalten kann zur Folge haben, das eine böse Software aus den Speicher fliegt. Ob da ein Back der VM hilft?
> Einem Benutzer sind Hunderte von fehlgeschlagenen Anmeldeversuchen aus der Solarwinds-VM seines Unternehmens zu anderen internen Servern aufgefallen. … Niemand weiß, wozu das gut ist und was es macht.
Es geht wohl um den Thread unter reddit.com/r/cybersecurity/comments/1bbq34w/getting_hundreds_of_failed_login_attemps_from_our/?sort=new.
Was macht der Benutzer beruflich? Fachinformatiker/in für Systemintegration 2. Woche?
Da nicht von fehlenden adminstrativen Zugangsdaten gesprochen wird, gehe ich davon aus, dass der Anfragende auf der VM als S-1-5-21–500, Mitglied von S-1-5-32-544 (1) oder anderweitig ausreichend Privilegierter unterwegs ist.
(2) und evtl. noch (3) an den Start gebracht und die Analyse kann beginnen. Alles kein Hexenwerk.
—
(1) learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab
(2) learn.microsoft.com/en-us/sysinternals/
(3) telerik.com/fiddler/fiddler-everywhere
bei Reddit ist doch eine schöne mögliche Ursache gegeben worden.
Man hat,wie es sich gehört, nach jedem Admin Wechsel die Passwörter der administrierten Maschinen gewechselt. Dabei hat man leider vergessen, dies der SolarWindVM mitzuteilen.
Daher benutzt sie immer noch die alten Passwörter um sich bei den Rechnern anzumelden.
Das schlägt natürlich fehl.
Da das was diese VM macht eh egal ist und man das Passwort der VM nicht mehr wusste hat man es so gelassen. Es störte ja niemanden wenn da ein bisschen geloggt wurde
War ja klar warum.
Also mal gucken was für ein Betriebssystem auf der VM läuft ( virtuelle platte read only mounten und da mal schauen was sich so in der Etc finden lässt.
Dann Google password recovery password forgotten suchen und hoffen das es etwas gibt.
Mir ist auch schon ein alleinwissrnder, teamunfähiger Admin untergekommen, der für ein System Tool seinen User Account verwendet hat.
Er hatte keinen Bock dafür einen Funktions-Account zu erzeugen. Als er gegangen ist, wurde sein User Account deaktiviert…
Da das was die VM da machte nur die IT in der Konzern-cZentrale interessierte, und die nicht mehr zuständig war, war auch niemand mehr da, den die Login Probleme störte.
Und wenn sie nicht gebootet wurde, loggt sie sich immer noch mit dem alten User Account ein, resp. versucht es.
Das kann auch schon in Folge der Abspaltung passiert sein, als man alle Accounts der Zentrale natürlich gelöscht hat. Die VM hat man einfach vergessen abzuschalten. Störte ja niemanden und das Passwort hatte die Zentrale. Da wollte man nicht fragen, aber traute sich auch nicht das Teil abzuschalten oder hatte das Teil gar nicht auf dem Tablet.
So könnte das Herr Occam gesehen haben.
Bei der Konzernzentrale nachfragen, was die Box gemacht hat und ob das weg kann.
Vielleicht haben die da dokumentiert.
ich habe ihn so verstanden, dass er gar nicht auf die VM kommt, weil inzwischen das Team komplett erneuert würde und niemand mehr das Passwort kennt. Vielleicht ist die gar nicht (mehr) im AD?
Aber hast Recht. Eigentlich kann man als root auf jede VM….Schon seltsam. Aber ist halt Windows.
DAS ist vielleicht die SIEM VM, die per Penetration versucht, wie gut die Kennwörter oder die Systeme sind :-) Ansonsten isolieren, polizeiliche Anzeige gegen unbekannt und dann einen Forensiker drauf lassen.
:'D herrlich
wo ist hier der Daumen nach Oben Button?
Bedauerlicherweise ist so etwas keine Seltenheit.
In den letzten 10 Jahren habe ich so viele VMs oder gar alte Rechner (welche im Serverraum nebenher laufen und alte Dongels am Start haben um noch ältere Programme mit den nötigen Lizenzen zu versorgen…) gesehen ohne irgendwelche vorhandenen Dokumentationen oder Wissen was da noch läuft, das geht auf keine Kuhhaut mehr.
Selbstredend sind auch meistens die Admins, welche das irgendwann mal aufgesetzt haben, längst nicht mehr dabei, weil die Halbwertszeit bei den meisten Mittelständischen in der IT aus guten Gründen entsprechend gering sind…
Ich sehe übrigens auch nicht dass sich das zeitnah ändert, Fachkräftemangel plus weiterhin den Gedanken dass IT zu funktionieren hat, aber man dafür so wenig wie möglich auszugeben hat, wird auch weiterhin dazu führen dass insbesondere Deutschland sich weiter über einen Hackingfall nach dem Nächsten freuen darf.
und dann war da noch das Uni Rechen Zentrum das in einen Raum um ziehen sollte.
Der alte Raum war leer, im neuen lief noch gar nichts.
Groß war die Verwunderung, als jemand berichtete, das er ein Anfrage per Email bekommen hat.
wie ging das, so ohne Mailserver? Der Rechnerraum war ja leer.
Eine Verfolgung der Netzwerkkabel ergab dann, das jemand den Mail Server vorbei Jahren in den Lüftungs Hohlboden gepfeffert hatte und der da lustig weiterarbeite, einsam und vergessen..
Das ist aber schon lange her, das man mit einem Rechner den gesamten Email Verkehr stemmen konnte…
Aber Rechner "vergessen" gab es schon immer.
Später Kommentar auf einen alten Thread:
Um das Ganze noch irgendwie aus der Applikationssicht aufzuklären, die einzige "Solarwinds VM"-Appliance ist der Security Event Manager. https://www.solarwinds.com/security-event-manager
Das system ist eine "geschlossene" appliance auf die man nur mit einem management User kommt, aber keinen Root zugriff hat. Die meiste Administration für die Applikation findet über die Web-Console statt, oder wenn es eine ganz alte Maschine ist, über ein "management tool".
Die Appliance hat auch Agenten/Connectoren, die remote Daten sammeln können.
Da werden vermutlich irgendwelche Accounts hinterlegt sein, die abgelaufen sind, wie hier auch schon bemerkt wurde.