Austausch unter IT-Professionals - Erfahrungen, Tipps, Fachsimpelei

Daaaaaaaaaaaanke für Euren Hinweis. Mein Überstundenzettel macht auch gerade nen freudigen Luftsprung. Man wird das Gefühl nicht los, dass MS die OnPrem-User in Richtung Cloud "bewegen" will hust hust
 
  • Gefällt mir
Reaktionen: konkretor und xCtrl
xCtrl schrieb:
Edit: ich habe jetzt im Durschnitt 15 Min pro Exchange benötigt für die Anwendung des Workarounds.
Dito. Chef sagt bei solch kleinen Sachen immer "Schreib 2 Std. auf" :D
 
  • Gefällt mir
Reaktionen: xCtrl
Ich hab keine Bock mehr auf diese Scheisse...

Was kommt wohl 2022 von MS? Ein auskommentiertes #get-disk | clear-disk -force das aus irgendeiner RCA zu Verschlüsselungstrojanern den Weg in ein CU gefunden hat wo die Raute nicht geparst und überspringen wird weil Schaltjahr und das falsche .net installiert ist?
IIS vergisst einfach dass da ein Zertifikat auf 443 gehört? Ach nee, hatten wir schon.

Maaaan.
 
  • Gefällt mir
Reaktionen: evilhunter, Toyota Corolla, xCtrl und 2 andere
@t-6

stimmt, Mitte des Jahres gab es ja ein abgelaufendes internes Zertifikat, was OWA und ECP lahmgelegt hat. Glaube mir, ich habe auch keinen Bock mehr auf den Mist, aber als angestellter IT-Dienstleister wirds schwer von jetzt auf gleich umzuschwenken auf alternativen. Im heimischen Netz wird bereits versucht umzustellen - teils erfolglos natürlich 😅
 
Mac_Leod schrieb:

Zum Glück nicht.
Was uns bei einen der letzten Exchange 2013 Updates passiert ist, dass die Updates uns die EX Server Zertifikate gelöscht haben. Allerdings nicht sofort sondern am nächsten Tag (Zeitzonen…)… Joah und wir haben uns erst gewundert warum das DAG nach und nach weggestorben ist 😂

paperw_ngs schrieb:
https://www.borncity.com/blog/2022/...oad-cant-convert-2201010001-to-long-1-1-2022/

Ich packe das mal einfach hier rein. Wenn ihr einen geliebten Exchange Admin kennt, so weckt ihn doch auf.

Danke für die Warnung. Dann wird Montag ja schön lustig ..,
Wobei ich bin mir gerad nicht sicher ob der FIP FS überhaupt aktiv ist, weil wir da noch ein Drittanbieter Produkt haben.
 
Zuletzt bearbeitet von einem Moderator:
Ja, in letzer Zeit ist das wirklich, wirklich extrem geworden. Da steckt sicherlich auch ein Aspekt von dem drin was @Towatai sagt, das MS die Kunden in der Cloud haben will.
Aber irgendwie kann mir das als "Ausrede" nicht reichen. Es ist ja nicht so, als ob die Cloud Sachen wirklich gut laufen. Die Teams GUI spricht Baende, und 365 ist ja schon laenger als <360 bekannt.
Das dann auch noch Features wild hin- und hergewuerfelt werden sorgt fuer weiteren Frust.

Alleine das Teams auf Laptops, PCs und virtuellen Maschinen teilweise, aber nicht immer, anders aussieht... Von der Performance mal ganz abgesehen.

Ich glaube da wird aktuell massiv vom Ruf gelebt. Mal schauen wielange es dauert bis erste Firmen sich ernsthafte Alternativen anschauen.
 
  • Gefällt mir
Reaktionen: evilhunter
Shit happens, ob Cloud oder on-Prem und egal bei welchem Hersteller. Ein Datum in einen Int32 zu knallen ist aber schon next Level Dilettantismus. 🥴
 
  • Gefällt mir
Reaktionen: Chris_S04
Ich behaupte mal, dass es sogar gang und gäbe ist Zeit als Integer zu speichern.
Nennt sich Unix timestamp und wird die IT-Branche vermutlich Januar 2038 alle richtig hart f.... weil irgendwo in irgendwelchen Tools/Scripten oder dann 20 Jahre alten python-Modulen der Überlauf passiert. :o

Mag sein, dass es da inzwischen bessere Möglichkeiten gibt, aber das wird sicherlich auf breiter Front noch so gemacht. Erster Hit bei Google als Beispiel:
https://www.google.com/search?client=firefox-b-d&q=php+how+to+save+date
 
Blutschlumpf schrieb:
Nennt sich Unix timestamp und wird die IT-Branche vermutlich Januar 2038 alle richtig hart f.... weil irgendwo in irgendwelchen Tools/Scripten oder dann 20 Jahre alten python-Modulen der Überlauf passiert. :o
Danke, dass du mich erinnerst, dass ich in der Woche vom 18.1. - 22.1.38 Urlaub einzureichen! :daumen:

Kann es sein, dass Log4J am Ende heißer gekocht wurde, als es war? Wir hatten zwar betroffene Anwendungen, aber scheinbar keine Infektion (oder die Angreifer haben Mitleid und zeigen Ihre Aktivität erst ab morgen)...
 
Waren die Anwendungen überhaupt öffentlich erreichbar? Wenn nicht, wäre das Risiko "nur" aus dem internen Netzwerk durch infizierte Geräte, böswillige MA oder öffentlich erreichbare Netzwerkanschlüsse zu vermuten.

Selbst wenn sie öffentlich erreichbar waren, hast du eine WAF davor? Die kann das auch schon weggefiltert haben. Ansonsten bleibt selbst wenn nicht noch die Möglichkeit das man einfach Glück hatte und noch niemand deine IP gescannt hat und sich das zu nutze gemacht hat, gibt/gab schließlich genügend potentielle Ziele.
 
@holdes Ja, war von außen erreichbar und was meinst du mit WAF (Application Firewall?)? Firewall war vorhanden, was die filtert? Keine Ahnung! Das machen die Kollegen, ansonsten war noch ein Reverse Proxy davor, allerdings hab ich damals bei einer spontanen Suche keine Infos gefunden, inwiefern der Reverse Proxy schützt. Wenn ich richtig informiert bin, kann ja auch schon ein manipulierter User Agent ausreichen und der wird doch vom Reverse Proxy durch gereicht, oder?
 
kernel panic schrieb:
...was meinst du mit WAF (Application Firewall?)?

Jap, Web Application Firewall aber dafür gibts viele Namen. Die meisten hatten die Signaturen für Log4J Angriffe schnell drin und wären selbst bei einem öffentlich erreichbarem Dienst sicher gewesen ;).

kernel panic schrieb:
Firewall war vorhanden, was die filtert? Keine Ahnung! Das machen die Kollegen, ansonsten war noch ein Reverse Proxy davor, allerdings hab ich damals bei einer spontanen Suche keine Infos gefunden, inwiefern der Reverse Proxy schützt. Wenn ich richtig informiert bin, kann ja auch schon ein manipulierter User Agent ausreichen und der wird doch vom Reverse Proxy durch gereicht, oder?

Wenn der Reverse Proxy nicht explizit Muster erkennt und filtert kann ich mir kaum vorstellen, dass er alleine Schutz bietet. Eine WAF besteht ja im Grunde auch nur aus eben diesem Proxy nur mit dem Unterschied, dass die dort noch IPS und andere Dinge macht.

Da ihr aber besagte Firewall bzw. UTM? davor habt denke ich nicht das jemand was angestellt hat, je nach Hersteller und Updatezeitraum der Signaturen bleibt einem Angreifer auch recht wenig Zeit. Bei uns hab ich die Logs mal durchgesehen und versucht hat es da zumindest niemand ;).

Eine reine Firewall arbeitet ja nur Regeln ab, die schützt vor so etwas natürlich nicht aber Firewall nutzt man als Begriff meistens für Geräte die weit mehr als das sind.
 
  • Gefällt mir
Reaktionen: kernel panic
holdes schrieb:
Jap, Web Application Firewall aber dafür gibts viele Namen. Die meisten hatten die Signaturen für Log4J Angriffe schnell drin und wären selbst bei einem öffentlich erreichbarem Dienst sicher gewesen ;).
Naja ich hatte nur gelesen, dass irgendein CDN mit dem Filtern Probleme hatte und dachte dann, dass die üblichen Firewalls damit ebenfalls Probleme hatten, auch wenn die Kollegen mir bestätigt hatten, dass die Firewall alles blockt...
holdes schrieb:
Wenn der Reverse Proxy nicht explizit Muster erkennt und filtert kann ich mir kaum vorstellen, dass er alleine Schutz bietet. Eine WAF besteht ja im Grunde auch nur aus eben diesem Proxy nur mit dem Unterschied, dass die dort noch IPS und andere Dinge macht.
Genau das war auch mein Stand. 👍
holdes schrieb:
Da ihr aber besagte Firewall bzw. UTM? davor habt denke ich nicht das jemand was angestellt hat, je nach Hersteller und Updatezeitraum der Signaturen bleibt einem Angreifer auch recht wenig Zeit. Bei uns hab ich die Logs mal durchgesehen und versucht hat es da zumindest niemand ;).
Jup, Firewall ist vor den Systemen, dahinter wäre schon blöd. :D
 
kernel panic schrieb:
Jup, Firewall ist vor den Systemen, dahinter wäre schon blöd. :D

War eher gemeint ob wir von einer "Firewall" oder von einer "UTM" sprechen. Das sie davor ist, sollte klar sein :D. Viele nutzen heutzutage aber Firewall als Synonym für sämtliche Security Hardware/Software ;).
 
  • Gefällt mir
Reaktionen: Towatai und Chris_S04
Zurück
Oben