[English]Beunruhigende Informationen, die mich gerade erreicht haben. Nicht auf dem aktuellen Patchstand befindliche Microsoft Exchange On-Premises-Server sind anfällig für Angriffe über die ProxyNotShell-Schwachstellen. Vor Weihnachten gab es dann die Information, dass die Hackergruppe FIN7 seit längerem eine automatisierte Angriffsplattform zum Eindringen in verwundbare Exchange-Server aufgesetzt habe. Und nun erreicht mich die Information, dass möglicherweise bis zu 70.000 Exchange-Server weltweit verwundbar für FIN7 ProxyNotShell-Angriffe sind. Ich habe mal für Deutschland nachgeschaut, mit über 13.000 Systemen sind wir "Spitzenreiter" in Europa.
Anzeige
Exchange und ProxyNotShell
Ende September 2022 wurde eine neue 0-Day-Exploit-Methode (ProxyNotShell) für On-Premises Exchange Server gefunden, für die Microsoft im Oktober 2022 gleich mehrere URL-Rewrite-Regeln als vorläufigen Schutz veröffentlichte (siehe Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333 und die restlichen Artikel am Beitragsende). Microsoft hat dann im November 2022 ein Sicherheitsupdate zum Schließen der Schwachstellen veröffentlicht (siehe Exchange Server Sicherheitsupdates (8. November 2022)).
Auf Microsoft Exchange-Servern, die nicht auf dem neuen Patch-Stand sind, besteht das Risiko, dass Angreifer die ProxyNotShell-Schwachstellen CVE-2022-41040 und CVE-2022-41082 als Eintrittsvektor für Microsoft Exchange Server missbrauchen. Vor Weihnachten hatte ich über einen vermuteten neuen Angriffsvektor berichtet, den die Play Ransomware-Gruppe für erfolgreiche Angriffe über die ProxyNotShell-Schwachstellen benutzt (siehe Microsoft Exchange: Neue OWASSRF-Exploit-Methode (ProxyNotShell) durch Play-Ransomware).
FIN7-Gruppe erstellt Auto-Angriffsplattform
FIN7 ist eine russische Advanced Persistent Threat (APT) Gruppe, die seit Mitte 2015 verstärkt den US-Einzelhandels-, Restaurant- und Gastgewerbesektor ins Visier nimmt. Ein Teil von FIN7 wird von der Scheinfirma Combi Security und Bastion Secure betrieben, wie AVAST in diesem Beitrag offen legt. Es gab zwar Verhaftungen von Gruppenmitgliedern im Jahr 2018 – Sicherheitsforscher von Kaspersky haben aber weitere Angriffe und auch eine Kooperation mit der auf Banken spezialisierten Carbanak-Cybergang beobachtet.
Von Prodraft gibt es einen Artikel vom 22. Dezember 2022, der viele interne Abläufe der Gruppe offen legt. Die Kollegen von Bleeping Computer haben dann diese Erkenntnisse in diesem Beitrag aufbereitet. Die Kurzfassung: Von Prodraft wurde ein "Checkmarks" getauftes automatisches Angriffssystem entdeckt, welches einen Scanner für Microsoft Exchange-Schwachstellen wie CVE-2021-34473, CVE-2021-34523 und CVE-2021-31207 enthält. Die Gruppe verwendet den Scanner, um Exchange Server aufzuspüren, die hinsichtlich obiger Schwachstellen angreifbar sind.
Anzeige
Die Schwachstellen ermöglichen die Ausführung von Remotecode und die Erhöhung von Berechtigungen. Über verschiedene Exploits versucht FIN7 sich dann Zugang zu den Zielnetzwerken über die angegriffenen Exchange-Server zu verschaffen. Die Checkmarks-Angriffsplattform enthält auch ein SQL-Injektionsmodul, das SQLMap verwendet, um nach potenziell ausnutzbaren Schwachstellen auf der Website eines Ziels zu suchen.
Auf diese Weise gefundene, neue Opfer werden automatisch zu einem zentralen Panel hinzugefügt. Dort können FIN7-Hacker zusätzliche Details über den kompromittierten Endpunkt abfragen. In weiteren Schritten ergänzen weitere Team-Mitglieder die Einträge um "Marketing"-Material wie Einkünfte der Opfer, Anzahl der Mitarbeiter, Details zum Unternehmen etc. Wird ein Unternehmen als lukrativer Kandidat eingestuft, geben Pentester Hinweise für einen möglichen Angriff. Die FIN7-Gruppe verfügt also über eine ausgeklügelte Organisationsstruktur, um ihre Angriffsziele auszuwählen.
Laut Prodaft wurde die Checkmarks-Plattform von FIN7 bereits genutzt, um 8.147 Unternehmen (aus 1,8 Millionen gescannter Ziele) zu infiltrieren. Dabei laufen 16,7 % der infizierten Systeme in den USA. Inzwischen gibt es einen Bericht der Sentinel Labs von November 2022, dass die FIN7-Gruppe mit der Black-Basta-Ransomware-Bande in Verbindung steht. Und das Sicherheitsunternehmen Mandiant hat bereits im April 2022 FIN7 mit Darkside-Operationen in Verbindung gebracht.
Darüber hinaus fanden Sicherheitsforscher in den abgerufenen Jabber-Protokollen zahlreiche Beweise für die Kommunikation mit mehreren Ransomware-Gangs, darunter Darkside, REvil und LockBit. FIN7 und deren "Checkmarks" Angriffssystem haben also das Potential für größere Ransomware-Angriffswellen auf über per Sicherheitslücken angreifbare Exchange Server.
ProxyNotShell: 70.000 verwundbare Exchange-Server
Und dann ist mir von Shadowserver noch ein Tweet unter die Augen gekommen, die das Internet nach für die ProxyNotShell-Schwachstelle CVE-2022-4108 anfälligen Microsoft Exchange-Servern scannen.
Das Ergebnis dieser Scans ist, dass fast 70.000 Exchange Server weltweit gefunden wurden, die wohl keine Patches zum Schließen der ProxyNotShell-Schwachstelle CVE-2022-4108 bekommen haben. Es gibt zwar eine gewisse Unsicherheit, weil nur bestimmte Versionsinformationen abgefragt wurden. Ich hatte kürzlich im Blog-Beitrag Ärger: Schweizer NCSC informiert Kunden über unsicherere Exchange Server (Dez. 2022) berichtet, dass es bei einigen Kunden in der Schweiz da bezüglich einer Warnung der Schweizer Sicherheitsbehörde NCSC gab.
Sind die Exchange-Server nicht auf dem Patchstand von November 2022, sollte aber vorsorglich davon ausgegangen werden, dass sie bereits angegriffen und kompromittiert wurden. Das gilt auch, wenn die von Microsoft vorgeschlagenen URL-Rewrite-Regeln zur Abwehr von ProxyNotShell-Angriffen gesetzt sind. Denn ich hatte im Artikel Microsoft Exchange: Neue OWASSRF-Exploit-Methode (ProxyNotShell) durch Play-Ransomware erwähnt, dass diese Regeln durch neue Exploit-Methoden wohl umgangen werden können.
Aktuelle Daten angreifbarer Exchange Server lassen sich im Shadowserver-Dashboard abrufen. Ich habe in obigem Bild die Zahlen vom 27. Dezember 2022 für Europa anzeigen lassen. Mit über 13.000 Einträgen liegt Deutschland weit vor anderen EU-Ländern an der Spitze. Bleibt zu hoffen, dass die On-Premises Exchange Server der Blog-Leserschaft gepatcht und sauber sind.
Ähnliche Artikel:
Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)
Exchange Server: Neue 0-day (nicht NotProxyShell, CVE-2022-41040, CVE-2022-41082)
Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333
Neues zur Exchange Server 0-day-Schwachstelle ZDI-CAN-18333: Korrekturen, Scripte und EMS-Lösung
Exchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einschätzungen (3. Oktober 2022)
Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (5. Oktober 2022)
Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (8. Oktober 2022)
Exchange Server Sicherheitsupdates (11. Oktober 2022)
Exchange Server Sicherheitsupdates (8. November 2022)
Ransomware-Angriff für Ausfall der Rackspace-Exchange-Instanzen im Dez. 2022 verantwortlich
Ärger: Schweizer NCSC informiert Kunden über unsicherere Exchange Server (Dez. 2022)
Microsoft Exchange: Neue OWASSRF-Exploit-Methode (ProxyNotShell) durch Play-Ransomware
Anzeige
Läuft ja wieder bei MS…
Was hat es mit MS zu tun, wenn die Leute ihre Server nicht gepatcht bekommen? Sorry, jeder Admin, der jetzt noch nicht die Sicherheitsupdates installiert hat, verdient es befallen zu werden.
MS könnte nach vielen Jahre jetzt so langsam endlich mal eine fehlerfreie Software hinbekommen?
richtig. Alternativ könnte man ja auch vorübergehend den Exchange bzw. OWA nicht direkt ins Internet stellen mittels Portweiterleitung. Dann fällt er schon mal unter dem Radar durch.
Ohne vorgeschalteten ReverseProxy? Wer macht den so etwas?
Irgendwie vermisse ich den TMG von damals, damit konnte man Exchange, Sharepoint usw. relativ einfach veröffentlichen, *die gute alte Zeit* :-)
+1
Weil für jede geschlossene Lücke zwei neue aufpoppen, Du Schlaumeier.
Noch vor Weihnachten alles gepatched..Davor nur die selbst erstellte und von MS aktivierten URL Regeln drin gehabt..
Sollte wohl hoffentlich reichen, Health checker zeigt zumindest an das diese CVEs geschlossen sind..Wer weiß was vorher passiert ist..
Womit MS "zufällig" bewiesen hat, dass die Cloud sicherer ist und noch Kosten für kompetentes Personal spart, weil ja nur die selbst betriebenen Systeme gefährdet sind…
Das erinnert mich an ein Rabulistik-Beispiel:
Der in Rabulistik geschulte Kellner wird nach der Essensbestellung nicht nur fragen, "Darf ich Ihnen dazu etwas zu trinken bringen" sondern : "Wünschen Sie einen Rosee oder oder Mosel dazu? "
Dem Gast wird garnicht die Möglichkeit gegeben, zu sagen, er möchte garnichts trinken.
Diesen Bauernfänger-Trick benutzt das NS Marketing.
Wenn, wird doch nur noch diskutiert, ob on premise oder in der Cloud, aber nicht, welche anderen alternativen Produkte es gäbe…
Und wenn das Geld mal nicht so fließt, könnte man mit einem on premise system noch ein paar Wochen/Monate arbeiten. Wie kulant ist Microsoft in solchen Fällen?
Dazu kommt, on premise habe ich eine feste Kalkulation der Kosten für Zeitraum X. In der Cloud kann MS nächsten Woche ankündigen das das Produkt ab Zeitpunkt X 20% teurer wird und man kann die Kröte nur schlucken.
Nicht umsonst hat MS die on premise Lösungen quasi um 100% verteuert indem die Supportdauer 50% reduziert wurde. Siehe Office 2016 von 10 Jahre Support, auf nur noch 5 Jahre Support ab Office 2019, was zur irrwitzigen Konstellation führt das Office 2016 und 2019 zeitgleich aus dem Support fallen.
Was hat das mit Microsoft zu tun?
Da könntest du auch einen Schloßhersteller an den Pranger stellen, weil der verantwortliche Mitarbeiter die Türen nicht abschließt.
Der Patch ist seit jetzt 7 Wochen draußen.
Wer seine Server jetzt noch nicht gepatcht hat, verdient es nicht anders!
Im Grunde verdienen die verantwortlichen ITler, die ihre Systeme nicht zeitnah gepatcht haben, eine Abmahnung, da sie die Sicherheit der Firmen-IT grob fahrlässig vernachlässigen.
"Was hat das mit Microsoft zu tun?" Ernsthaft???
Also, ich weiß nicht, was dazugehört, dass man ein Produkt, welches schon derart lange am Markt ist, sicherheitstechnisch nicht abgedichtet bekommt?
Alleine, dass es anscheinend schon vom Design her derart viele Angriffspunkte beinhaltet, ist schon eine echte 'Meister-Leistung'… – aber schon interessant, dass viele MS anscheinend alles 'verzeihen'. Würde hier eine Produkt-Haftung greifen, dann wäre es schnell vorbei…
"Wer seine Server jetzt noch nicht gepatcht hat, verdient es nicht anders!"
Was soll das? Weißt Du, inwieweit Dein Exchange nach den November-Patches WIRKLICH SICHER ist..? Welche 'Einfallstore' schlummern denn immer noch -selbst nach den November-Patches- unter der Haube?
Vielleicht sind ja schon wieder einige Lücken bekannt (nur bis jetzt unbemerkt) und die Hacks gegen die November-gepatchten Server laufen schon..?
"…eine Abmahnung, da sie die Sicherheit der Firmen-IT grob fahrlässig vernachlässigen."
Ja, bestimmt, weil die ITler ja auch dieses Produkt programmiert haben (also dafür verantwortlich sind)..? Wer vernachlässigt die Sicherheit? Die ITler, oder der Hersteller?
Denk' mal bitte darüber nach… – wünsche einen 'Guten Rutsch!'
Dass Exchange am besten eingestampft und neu gemacht gehört hat er ja garnicht bezweifelt. Niemand weiss welche Untiefen seine Webschnittstelle noch bereit hält.
Das entbindet den zuständigen IT'ler aber nicht davon die Kiste verdammt nochmal rechtzeitig mit aktuellen Patches zu versorgen und bei ausreichendem Mistrauen gegenüber Microsofts Programmierkünsten hinter weitere Sicherungen zu stellen.
Man kann es drehen wie man will, am Ende kommt man immer wieder an die Säulen die das Universum tragen: Kranplätze müssen verdichtet und Sicherheitspatches eingespielt werden.
Frohe Ostern und ein gutes Neues.
Wer in der IT Welt zuhause ist, der sollte wissen, dass es in der IT keine Produkte gibt, die 100% fehlerfrei sind und für die es keine Sicherheitslücken gibt.
Ich weiß auch gar nicht, ob es realistisch ist anzunehmen, Softwareprodukte zu entwickeln, die keine Fehler enthalten. Sollte zwar immer das Ziel sein, ist aber eben unrealistisch.
Ernsthaft!
das liegt aber daran das es für Software keine Produkthaftung gibt! Hätten wir diese sähe das komplett anders aus! Sicherheit geht nämlich sehr wohl nur kann man dann nicht jeden Scheiß einfach so auf die Welt klatschen (siehe Chinascheiß). Das würde nämlich Zeit und Geld brauchen bevor man das auf den Markt wirft.
Produkthaftung erschlägt auch nicht alle Fehler, wie Produktrückrufe immer wieder beweisen, aber es erschlägt 95% der Fehler, weil diese Fehler den Hersteller teuer kommen.
Stellt Software endlich unter eine Produkthaftung!
Keine Software ist zu 100% sicher, auch nicht OpenSource.
Und kann auch gar nicht zu 100% sicher gemacht werden.
Dazu ist das viel zu komplex und groß.
Exchange hat mehrere Millionen Zeilen Programmcode. da kannst du auch ein Team von 100 Leuten anstellen, um nach Lücken zu suchen, es werden immer Lücken übersehen.
Und oft kommen mit neuen Versionen auch neue Lücken rein.
Beispielsweise gabs 2021 einen Patch für eine Sicherheitslücke in Exchange 2013-2019, aber nicht für 2010.
Grund: Die von der Lücke betroffene Funktion gabs bei 2010 noch gar nicht, ergo war 2010 von der Sicherheitslücke gar nicht betroffen.
Regelmäßig werden auch in OpenSource-Sachen Sicherheitslücken gefunden.
Und Exchange ist noch rel. sicher, da werden doch rel. wenig Sicherheitslücken gefunden.
Auch Windows ist deutlich besser als sein Ruf.
Gefundene Sicherheitslücken 1999-2019:
Android = 2563
Linux Kernel = 2357
MacOS = 2212
Mozilla Firefox (ist OpenSource!) = 1873
Windows 7 = 1283
etc.
Aber die Lücken in den anderen Systemen werden in der Presse nahezu totgeschwiegen, weshalb jeder nur die Lücken in Windows sieht.
Zu Android: Auch da gibt es wie bei Windows einen monatlichen Patchday. Aber wieviele Gerätehersteller rollen die Patches auch tatsächlich zeitnah auf ihre Geräte aus?
Die allermeisten machen das nicht. Da bekommt man, wenn man Glück hat, 2-3 mal im Jahr Patches. Man läuft also monatelang mit ungepatchten Geräten herum.
> Auch Windows ist deutlich besser als sein Ruf.
> Gefundene Sicherheitslücken
Und die nicht gefundenen/geheim gehaltenen Sicherheitslücken/Backdoors?
Diese Zahlen sind leider wertlos.
Und dann würde ich als IT-ler das Handtuch freiwillig abgeben. Ich sehe hier im Landkreis wenige Firmen, die genügen IT-ler haben. IT-Dienstleister mit wenig Man-Power gibt's ebenfalls, die dann erstmal 30 andere Server patchen müssen und dann erst intern ran können. Ich muss sagen bei uns war er auch erst nach über 3 Wochen gepatcht. Microsoft könnte es den IT-ler auch einfacher machen und nicht mit diesen dämlichen CUs umherfuchteln, bei der ein Server 1,5 – 2 Stunden Downtime hat. Ganz zu schweigen von Bugs, die beim IT-ler eher mal eine Woche wartet bzw. erstmal das ganze in einer Testumgebung testet. Klar, der Server sollte zusätzlich noch abgesicherte werden, genau wegen solchen Dingen, aber man könnte es uns auch einfacher machen, weil wir auch nicht 24h arbeiten können. Zumal ein Exchange Server entsprechende Voraussetzungen hat und nicht irgendwelche Bloatware installiert ist wie auf einem PC oder Laptop, da könnte man schon etwas mehr Bugfreiheit verlangen. Oder ein vernünftiges Updates Atem, aber klar deinstallieren, ulinstallieren und wiedereinbinden der Datenbank ist natürlich die einfachste (Anfänger)-Methode
Das MS den Überblick verloren hat, das MS nichts mehr selbst testet, sondern irgendwelchen ungeprüften Schrott an Kunden liefert.
Wie blöde darf ein MS Mitarbeiter denn sein, einen Patch zu releassen, der kompleltt wirkungslos ist, weil der MS-Depp(tm) vergessen hat zu sagen, das man Regular Expressions aktivieren muß… Und dies erst Tage später richtig stellt.
Damit hat MS garnichts zu tun?
Ich erinnere mich mit grausen an das alte OS für Mac.
Völlig kaputt was den Speicher betraf.
Apple hat dann das einzig richtige getan, und den Schrott komplett entsorgt ubd und ist auf BSD umgestiegen.
MS ist ein totes Pferd.
Leider mit einem guten Marketing.
Wenn jeder Programmierer von MS verhältnismässig auch nur halb so viele Tippfehler machen würde, wie in diesem kurzen Text vorhanden sind, gäbe es sicher bedeutend mehr Schwachstellen in Windows.
Sorry, aber das musste ich einfach mal loswerden; hier im Blog bei den Kommentaren geht es genauso um eine Veröffentlichung – wenn auch von geringer Tragweite. Was man da zum Teil liest, ist einfach nur schockierend.
Zurück zum Thema:
Ja, Microsoft könnte besser testen, damit nicht jeder Bug veröffentlicht würde. Aber bei der Menge an Code ist es normal (menschlich), dass manche Fehler übersehen werden.
Nicht jeder tippt die Texte hier an einer physikalischen Tastatur…
Ich könnte einen Schoss Hersteller an den Pranger stellen, wenn dieser sein Hochsicherheits Krypto Bluetooth Schloß so unsäglich dumm und billig konstruiert hat, das man es, zerstörungs und spurenlos mit einem kräftigen Neodyn Magneten öffnen kann, weil es nur eine magnetisch ungeschützte Spule zum entriegeln benutzte…
Den Kunden wurde ein kostenpflichtiges Update angeboten nachdem das Problem auf dem CCC bekannt gemacht wurde.
Nein, man hat nicht etwa die billige Spule durch einen "teueren" Spindelantrieb ersetzt, wie es heute üblich ist, sondern eine Mimik eingebaut, die den Magnet-Angriff angezeigt hätte, so das die Versicherung zahlen mußte…
Wer hat da wohl Mist gebaut?
Der Planer der diese angeblich sicheren Schlösser in die Vorräume eingebaut har? Die Sparkassen, die nicht einsahen ein neues Schloss zu kaufen, der Hersteller, der auf Tests verzichtete und die billigste Möglichkeit, eine Spule mit Eisenkern einbaute und kein vernünftiges Upgrade anbot?
Wenn ich es richtig in Erinnerung habe, muss der Angreifer doch noch immer Authentifizierter Benutzer sein?!
Klar kann dies immer sein..
Oder ist es mittlerweile möglich eine webshell abzulegen wie es im März 2021 war?
Wird auf jeden Fall it-mäßig ein spannender Jahreswechsel. Mal sehen, was an Hiobsbotschaften in den ersten Januar-Tagen kommt.
Erinnert mich jetzt irgendwie wirklich an Popkorn-Kino…
War doch beim letzten Jahreswechsel in Verbindung mit Exchange schon der Knüller. Erinnert sich noch jemand an den Typ-Umwandlungsfehler der Exchange erstmal in eine teilweise Blockade geschickt hat? (Aus der Jahreszahl bzw. den letzten beiden Ziffern wurde in Verbindung mit anderen Daten eine Int32 generiert und MaxInt überschritten). Ist an sich bereits ein Vorgehen, das extrem fehlernfällig ist. Aber dieses "Problem" hatte bei Microsoft überhaupt niemand (mehr) auf dem Schirm bzw. der ToDo-Liste. Und das ist das eigentliche Problem: an diesem "Produkt" haben mehrere Generationen von Entwicklern gearbeitet und die aktuellen Entwickler dürften den Code in nicht unerheblichem Maße nicht mehr überblicken, und schon gar nicht mehr voll verstehen.
Ein Upgrade auf ein neues CU ist da jedes Mal an Spannung kaum zu überbieten. Man kann es nur anwerfen und ab da ist man Passagier und muss beten, dass der "Flieger wieder sanft landet". Ohne ein volles aktuelles Backup und/oder erhebliche Redundanz geht da gar nichts.
Yess, ich erinnere mich ;-) Waren die Beiträge hier im deutschen Blog (Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can't Convert "2201010001" to long (1.1.2022)) und im englischen Blog doch zeitnah (1.1.2022, 10:21 Uhr) veröffentlich und wohl weltweit die ersten. Der deutsche Beitrag hat über 24.000 Abrufe, der englische über 40.000.
Und dann gab es ja noch den Patchday vom Januar 2022 mit dem DC Boot Loop sowie einigen anderen Goodies. Aber das ist ja bald Geschichte und wir beamen uns ins Jahr 2023 – neues Spiel, neues Glück.
Du weißt, wie viele gephishte Zugangsdaten im Netz kursieren?
Dann muß man aber noch irgendwie ins LAN kommen.
Es gibt doch wohl keine Knalltüten mehr, die immer noch OWA oder irgendwen, der jemals auf die Idee gekommen wäre einen Exchange Server mit einem Fuss ins Internet zu stellen? Das war doch schon aus performance Gründen Tabu, wenn man mehr als 10 Leute hatte…
Oder sind das etwa diese 13000?
Ich verstehe das Problem nicht. Microsoft hat das Patch vor über einem Monat veröffentlicht. Inaktuelle Exchange-Server zu unterhalten ist wie immer grob fahrlässig. die Admins stehen in der Pflicht. Auch sollte eine Exchange in einem eigenen Netzwerksegment betrieben werden, eine Kompromittierung also Übergriffe auf andere, wichtigere, Bereiche unmöglich sein.
PS: Die Hälfte der gescannten vulnerablen Systeme sind vermutlich Honeypots, also zu vernachlässigen.
35.000 Honeypots weltweit? Über 6.000 Honyepots alleine in Deutschland? Ich melde Zweifel an …
[…] eigenes Netzwerksegment […]
Der Exchange Server benötigt aber Zugriff auf das AD, ohne Zugriff auf das AD geht da nichts. In der Grundinstallation hat er (leider?) ziemlich hohe Rechte beim Zugriff darauf. Natürlich kann man da eingreifen und ihn beschneiden, aber ganz trivial ist das nicht, Nebenwirkungen möglich bzw. wahrscheinlich. Und auch wenn er eingeschränkte Rechte hat — er modifiziert Teile des AD. Wenn ein Exchange Server übernommen wird, ist nicht nur das darunter liegende System selber nicht mehr vertrauenswürdig, auch das AD ist erstmal — zumindest in Teilen — kaputt. Einen Exchange mit ausschließlich der Edge-Rolle in eine eigene Zone zu packen, dürfte wiederum erheblich leichter sein.
@Günther
Von den 6.000 gehören 2 mir. ;-)
@M.D.
Es hat keiner gesagt, dass es einfach ist. Die Kunst ist es nicht einen Exchange-Server zu installieren und konfigurieren. Die Kunst ist es heute, diesen im Zeiten von ZeroTrust und Micro Segmentierung sicher unterbringen. Hier kann ein Exchange Admin zeigen, was sie/er kann.
Heutzutage würde ich nicht mal einen Exchange-Server im LAN ohne Firewall/WAF zur Verfügung stellen. Wenn ich sehe wie oft in der Woche ein Client eine Malware gefunden wird…
Es war einmal ein Betriebssystem, erfunden von einem grandiosen Aufschneider und Hochstapler.
Dort konnte man keine großen PDF ausdrucken, weil, der spooler pool zu klein war.
Klar konnte man den vergrößern, aber das erforderte ein reboot des ganzen Servers.
Es scheint nicht besser geworden zu sein.
Klar das Admins nicht sofort Patsche ein spieln wenn die einen Reboot erfordern.
Aber das das hat nix mit den Fähigkeiten von MS zu tun, das sind einfach nur dumme Admins…
Und was ist an einem Reboot so schlimm?
Hier läuft der Exchange auf SSDs und ein Reboot des Systems dauert selten länger als 5 Minuten.
Und auf dem System läuft als einzige Anwendung der Exchange.
Durch den Reboot ist also nichts anderes betroffen.
Und rebootet wird zudem außerhalb der regulären Arbeitszeit.
Zum Admin-Job gehört es nun einmal, das man manchmal auch z.B. am Wochenende in der Firma ist oder nach regulärem Feierabend.
Admin sein und Dienst nach Stechuhr machen passt nicht zusammen!
Oh das mit der Arbeitszeit sehe ich aber anders. Wenn das Unternehmen die Mehrarbeit nicht zahlt oder anderweitig vergütet und man als IT eh immer der Affe ist, dann gibts auch mal 30 Minuten Downtime, weil der Server alle Exchange-Dienste während dem Exchangesicherheitsupdate beendet. Hat nichts mit Böswilligkeit oder so zu tun, ich würde das auch außerhalb machen, aber ne das sehe ich nicht ein.
Zauberwort: Aufgabenplanung, ist Bestandteil vom OS :)
Wir rebooten 99% der Server außerhalb der Geschäftszeiten darüber, dafür muss man keine Mehrarbeit leisten, ggf. am Folgetag etwas früher anfangen um zu prüfen ob alles funktioniert und dann natürlich eher in den Feierabend verschwinden.
Das ist alles keine Zauberei, mit ein wenig Bash/CMD und Powershell kann das meisten automatisieren ohne überall eine teure Managementlösung zu implementieren.
Bei etwas größeren Unternehmen hat man das meiste eh im HA laufen, da kannst auch während der Arbeitszeit patchen, beim Exchange musst nur auf dem einen Server den Wartungsmodus einschalten, dann verschluckt sich Outlook einmal kurz, Patches einspielen, rebooten und aus dem Wartungsmodus rausnehmen, dann kannst den nächsten patchen.
Das ist alles kein Hexenwerk und erfordert auch kein super duper Spezialwissen. Wenn man sich an so kleine Regeln wie "Pro Dienst ein Server" hält, ist der Aufwand und ggf. damit die verbundene Downtime sogar überschaubar, lässt man das Customizen an Core-System en zusätzlich außen vor, laufen die meisten Updates auch alle ohne Probleme durch.
Wir ziehen Core Systeme immer auf die aktuellste Version hoch die Verfügbar und freigegeben ist.
Für das zeitgesteuerte automatische Einspielen von Patches und dem Reboot braucht es noch nicht einmal die Aufgabenplanung.
Das kann man auch in den Updateeinstellungen konfigurieren.
das kommt darauf an …
wenn die neuen Arbeitszeitregeln so unfreundlich sind wird:
– unangekündigt mitten im Betrieb die Updates eingespielt und rebooted …
die GF will es nicht anders … umsonst wird nicht gearbeitet
Ich habe in meiner Firma 24/7 Zugang.
Und natürlich wird grundsätzlich die Arbeitszeit erfasst (wurde sie schon vor dem EU-Urteil) und auch bezahlt, auch inkl. Wochenend- und Nachtarbeitszuschlägen.
dann sei froh …
Ich kenne Firmen …
da wird jede Minute außerhalb der vorgegebenen Arbeitszeit ersatzlos gestrichen …
zusätzlich wird zu AN Ungunsten auf die nächsten 5 Minuten auf/abgerundet
Zuschläge gibts erst recht nicht
Ich könnte einen Schoss Hersteller an den Pranger stellen, wenn dieser sein Hochsicherheits Krypto Bluetooth Schloß so unsäglich dumm und billig konstruiert hat, das man es, zerstörungs und spurenlos mit einem kräftigen Neodyn Magneten öffnen kann, weil es nur eine magnetisch ungeschützte Spule zum entriegeln benutzte…
Den Kunden wurde ein kostenpflichtiges Update angeboten nachdem das Problem auf dem CCC bekannt gemacht wurde.
Nein, man hat nicht etwa die billige Spule durch einen "teueren" Spindelantrieb ersetzt, wie es heute üblich ist, sondern eine Mimik eingebaut, die den Magnet-Angriff angezeigt hätte, so das die Versicherung zahlen mußte…
Wer hat da wohl Mist gebaut?
Der Planer der diese angeblich sicheren Schlösser in die Vorräume eingebaut har? Die Sparkassen, die nicht einsahen ein neues Schloss zu kaufen, der Hersteller, der auf Tests verzichtete und die billigste Möglichkeit, eine Spule mit Eisenkern einbaute und kein vernünftiges Upgrade anbot?
Sag das, das ein Scherz ist.
Bitte.
Es kann doch nicht sein, das Admins so sehr MS hörig sind und für jeden Dienst einen eigenen Server hochziehen, weil MS bei jedem Update einen Reboot machen muss, weil sie die Übersicht verloren haben? Wie willst du diesen Sack Flöhe denn verwalten?
Wenn Du die Updates nur in der arbeitsfreien Zeit machen darst, weil Du sonst hunderte Leute aus ihren Applikationen kippst?
Wenn Du als Admin Deine Freizeit opfern musst um due Kollegen nicht zu stören?
Was bekommt so ein Admin für eine 20 Stunden Woche? 20000 a Euro?
Dann dauert der Update aller Server doch Tage.
Und das finden Windows Admins normal?
Hallo?
Heute ist doch nicht der erste April.
erm – doch?! Das machen wir selbst mit Linux Systemen, das hat nichts mit MS zu tun. Du willst doch nicht eine ganze Litanei an Diensten ausfallen lassen, weil du z.B. nur den Dienst für die ERP updaten willst. Bei Linux wiederrum willst du ja nicht dutzende Dienst mit neustarten nur weil der Apache ein Update brauchte. Und das geht auch meistens Tagsüber, da dann ggf. nur ein (kleiner) Teil der Kollegen betroffen ist und wenn man das Kommuniziert ist das auch kein Problem.
Sicherheitstechnisch: wenn z.B. der IIS eine Sicherheitsproblem hat, dann sollte davon nicht auch direkt der DB Server oder die DHCP betroffen sein, es macht durchaus Sinn, für jeden Service einen eigenen Server zu installieren.
Und warum sollte das mehrere Tage dauern? Du kannst selbst auf dutzenden Server parallel alles via Skripte & GPO steuern, vor allem was die normalen Windows Updates betrifft.
Das einzelne Bereitstellen macht natürlich Kostentechnisch nur Sinn, wenn man im MS Umfeld Datacenter Lizenzen hat, ansonsten gebe ich dir recht: das würde sehr teuer werden bei einer hohen Anzahl Services+Server.
So ist es:
Pro Dienst ein Server, egal was für ein BS da genutzt wird.
Crasht da mal ein Server, ist nur diese eine Dienst betroffen.
Muß man den Server patchen, hat man nur bei diesem einen Dienst eine Downtime, etc. etc.
Und natürlich nimmt man dann Datacenter-Lizenzen.
So eine Datacenter-Lizenz lohnt kostenmäßig schon, wenn man nur 6 Server hochziehen will. UVP einer Datacenter-Lizenz ist das 5,7-fache einer Standardlizenz.
Nicht nur Wartung ist ein Argument. Wer konsequent Micro Segmentierung umsetzt, wird früher oder späte Services und Dienste trennen müssen. Anderenfalls ist der Sicherheitsgewinn kaum vorhanden. Aber das muss man wollen und auch leben.
Unabhängig davon wenn der Service einen hohen Stellenwert hat, muss er redundant aufgebaut werden. Ich kann auf der einen Seite nicht den Kosten drücken und zu gleich sollen die ITler nachts oder am Weekend ran. Dann sollte man sich nicht wundern, wenn man niemanden mehr findet oder ein Schwund da ist. Das geht heute einfach nicht mehr…