atwork.blog

news and infos about microsoft, technology, cloud and more

Gedanken zur Datensicherheit

Derzeit sind die Themen Datensicherheit und Prism top-aktuell in allen Medien vertreten. Es ist anzunehmen und höchst wahrscheinlich, dass wohl alle Geheimdienste und staatliche Agenturen dieser Welt hinter allen nur möglichen elektronischen Daten her sind, diese analysieren und protokollieren. Technisch gesehen ist das der” Anwendungsfall für Big Data” …

Wie Sie von Exchange Online Protection mit einem On-Premises Server zu Office 365 wechseln

Exchange Online Protection ist das Antispam- und Antivirenservice von Microsoft, welches auch viele Kunden mit ihren On-Premises Exchange Servern verwenden. Das hat viele Vorteile, garantiert Exchange Online Protection (EOP, vormals FOPE, vormals EHS) ja 100% Mailvirenschutz und 98% Spamschutz. Lange Jahre begleitet mich dieses Produkt nun schon und egal wie es gerade heißt, es ist einfach immer noch sehr sehr gut. Wenn man jedoch seinen eigenen Mailserver (endlich) aufgibt und zu Office 365 wechselt, sind hierbei ein paar Schritte zu beachten. Zunächst einmal würde ich vorbereitend die TTL des MX Records bereits eine Woche vor dem Wechsel auf 5 Minuten stellen (oder 1 Minute). Den eigentlichen Umstellungszeitpunkt wähle ich dann immer entweder gegen Wochenende oder Abends oder an einem Feiertag, damit sicher gestellt ist, dass hier wenig Mailtraffic erfolgt. Dann im FOPE Administration Center anmelden und im Menüpunkt Verwaltung / Domänen die Domain deaktivieren die in Zukunft über Office 365 verwaltet wird. Danach wechseln Sie zum Punkt deaktivierte Domänen und löschen die Domain komplett aus FOPE . Ich warte dann immer rund 30 Minuten um sicher zu gehen, dass die Änderungen überall durchgeführt werden. (Keine Sorge, in dieser kurzen Zeit gehen Mails nicht sofort als unzustellbar zurück). Wenn Sie jetzt erst Ihr Office 365 Account eröffnen, können Sie in diesen 30 Minuten das Office 365 Abo kaufen und die Domain hinzufügen, validieren und die MX-Records ändern. Sobald diese validiert werden, haben Sie Office 365 und EOP im Einsatz! Wichtig: FOPE wird ab April 2013 in EOP integriert, bzw. die Services werden ab April konsolidiert. Für Administratoren bedeutet das, dass die Verwaltung einfacher wird, da damit auch EOP über https://portal.microsoftonline.com verwaltet werden kann. Für Kunden, die bereits Office 365 verwenden erfolgt die Umstellung im Rahmen der Transition zu Office 365 W15. Bei Kunden mit einem On-Premises Mailsystem erfolgt die Transition ab dem 3. Quartal 2013. Die FOPE Einstellungen werden automatisch in EOP auf Office 365 umgestellt. Alle Kunden erhalten mindestens 30 Tage vorher eine Info bezüglich der Transition.

Der WebReady Document Viewing-Dienst wurde vom Administrator für Ihre Organisation deaktiviert in Office 365 und Exchange Online

In Exchange Online gibt es die Möglichkeit, Microsoft Office Dateianlagen (docx, pptx, xlsx, etc.) direkt innerhalb der Outlook Web App Applikation anzusehen. Diese Möglichkeit wird durch die Web Access Components bereit gestellt, die ebenfalls durch die Office Web Apps genutzt werden. Um PDF Dateianlagen direkt aus der Outlook Web App anzusehen, wird WebReady Document Viewing verwendet. Dieses Feature wurde von Microsoft Ende August 2012 in den Online Services aus Sicherheitsgründen deaktiviert, da Microsoft Online Services Operations eine Sicherheitslücke in einer 3rd Party Komponente festgestellt hat. Amir Haque (Sr. Program Manager, Product Quality) hat dies in einem Community Beitrag mitgeteilt. Was bedeutet das für die Benutzer von Outlook Web App? Wenn Sie ein PDF-Attachment direkt im Browser ansehen möchten, sehen Sie folgende Fehlermeldung: "Der WebReady Document Viewing-Dienst wurde vom Administrator für Ihre Organisation deaktiviert." An einem Patch wird gearbeitet und das Feature wird wieder frei gegeben, sobald dieser ausgerollt ist. Für jene mit einem On-Premise Exchange Server: hier finden Sie die Konfiguration von WebReady Document Viewing.

Defense Against the Dark Ages: Your Old Web Apps Are Trying to Kill You #TEE12

Auf TechEd Europe 2012 hielt Aaron Margosis von Microsoft eine Session mit diesem reißerischen Titel. Dabei geht es vor allem darum, alte Applikationen (Legacy Apps) sicher zu machen und sicher zu betreiben. Hier wurden nicht die üblichen Top-sicherheitslösche wie Cross Site Scripting und SQL Injection & Co betrachtet, sondern Sicherheits-Themen, die weniger bekannt sind.

Microsoft kündigt Fix für ASP.NET #hashDoS an-Azure wird automatisch gefixt

Wie gestern in "Workaround gegen Denial of Service Attacke in ASP.NET #hashDoS #28C3" gewarnt, besteht bei Webservern (Windows Servern mit IIS) eine Verwundbarkeit gegen "hash collision attacks" #hashDoS. Angreifer können mit speziell präparierten HTTP-Requests eine Hash-Tabelle mit einer großen Zahl von Werten befüllen, deren Keys in demselben Hash-Code aufgelöst werden - damit sinkt die Performance der HashTable auf eine simple Linked List. Das kann bei repetitiven Requests zu einer Überlastung des Webservers führen, sinngemäß so: Betroffen ist auch ASP.NET. Microsoft arbeitet bereits an einem Fix, so schreibt ScottGu in seinem Blog: Ab heute, 29. Dezember, etwa 19h (unsere Zeitzone) wird ein Fix verfügbar sein! ASP.NET Security Update Shipping Thursday, Dec 29th ..."We are releasing the security update via Windows Update and the Windows Server Update Service.  You can also manually download and install it via the Microsoft Download Center. We will release the update on Thursday, December 29th at approximately 10am Pacific Time (US and Canada). We are announcing it ahead of time to ensure that administrators know that the security update is coming, and are prepared to apply it once it is available." Der Fix wird per Windows Update, Windows Server Update Service und im Microsoft Download Center verfügbar sein. Gestern bekannt gegeben - heute gefixt. Wow, das nenn ich wirklich rasch! Achja, betrifft die #hashDoS Verwundbarkeit Windows Azure Kunden? Nein, ScottGu schreibt: "Customers on Azure that have their Hosted Services OS servicing policy set to "Auto" (which is the default) will have their environments automatically updated to include the security update. There is no action required for this." Sehr praktisch, diese Cloud Services... Alle IT-Pros mit eigenen Webservern: Bei Verfügbarkeit Fix einspielen!!

Workaround gegen Denial of Service Attacke in ASP.NET #hashDoS

Achtung Web-Developer und Web-Hoster! Seit kurzem ist eine DoS-Attacke gegen Webserver bekannt, die zur Überlastung von Websites führen kann. Die Verwundbarkeit läuft unter #hashDoS und #28C3, sie führt "hash collision attacks" gegen Websites durch. Wie funktioniert #hashDoS? Technisch gesehen werden durch einen HTTP Request "teure" Hash Table Berechnungen ausgeführt, die - selbst auf sehr leistungsfähigen CPU´s - abertausende Form-Werte berechnen und so zu einer Überlastung = Stillstand des Webservers führen können. Selbst kleine HTTP-Requests können sehr rechenintensiv werden: Die Verwundbarkeit kann von anonymen Angreifern ausgenutzt werden, um in ASP.NET einen speziell präparierten HTTP-Request mit beispielsweise 100kB abzusetzen. Dieser Angriff kann eine CPU zu 100% auslasten und zwischen 90 und 110 Sekunden dauern. Durch mehrfache Wiederholung der Angriffe kann ein Stillstand erzeugt werden. (siehe 3.) CPU-Grafik von 3. Hier liegt die CPU-Last eines 4-Core Servers kontinuierlich bei 25% - nur durch einen WorkerProcess. Weitere Informationen finden Sie in 4. Wen betrifft es? Eigentlich alle Webserver im Internet. Alle Versionen des .NET Frameworks sind verwundbar. (siehe 1.) #hashDoS betrifft nicht nur Microsoft-Technologie (ASP.NET), sondern es sind alle Systeme gefährdet: Java, Python, Ruby 1.8, PHP, etc. Wann sind Windows Server betroffen? Verwundbar sind Windows-Systeme mit IIS-Rolle, wenn ASP.NET Websites mit diesen Content-Types (siehe 2.) verwendet werden: "application/x-www-form-urlencoded" oder "multipart/form-data" Andernfalls droht keine Gefahr durch #hashDoS. Wie können ASP.NET Websites geschützt werden? Eigentlich simpel - durch Limitierung des HTTP-Requests: Hier die Empfehlungen aus TechNet: Wenn Ihre Applikation ViewState verwendet: In web.config die maximale HTTP-Request Größe auf 200KB beschränken: <configuration> <system.web>   <httpRuntime maxRequestLength="200"/> </system.web> </configuration> Wenn kein ViewState verwendet wird: In web.config die maximale HTTP-Request Größe auf 20KB beschränken: <configuration> <system.web>   <httpRuntime maxRequestLength="20"/> </system.web> </configuration> ...abhängig vom Szenario. Nicht vergessen: Eventuelle File Uploads in der App! Die Empfehlung: Wenn Sie befürchten, Ziel eines Angriffs durch #hashDoS zu werden, führen Sie obige Schritte durch. (siehe 3.) Gibt es einen Fix? Ein Fix ist in Arbeit: "Our teams are working around the clock worldwide to develop a security update of appropriate quality to address this issue." (siehe 1.). Auch an Forefront wird gearbeitet. Es werden zwei neue "Rules" hinzugefügt werden, welche den Content Type prüfen und die Anzahl der Form values im HTTP-Request prüfen (> 1000 = Deny): "Microsoft's own Forefront Threat Management Gateway (TMG) will receive an update containing a signature for this issue today. (Vulnerability: Win/ASPNET.POST.DoS!NIS-2011-0001)" (siehe 3.) Hier alle Links mit weiterführenden Informationen gesammelt: Microsoft releases Security Advisory 2659883, offers workaround for industry-wide issue TechNet: Microsoft Security Advisory (2659883) -  Vulnerability in ASP.NET Could Allow Denial of Service More information about the December 2011 ASP.Net vulnerability Eine sehr feine Erklärung liefert Effective DoS attacks against Web Application Plattforms - #hashDoS Allgemein: Microsoft Security Response Center (MSRC) Home

Die Cloud ist nicht sicher....

...und meine Daten müssen bei mir bleiben. Eines der vielen Argumente, die ich im Rahmen von Office 365 Anfragen und Cloud Diskussionen immer wieder höre. Alles was rund um Rechenzentren, wo liegen meine Daten und Sicherheit passiert, ist in diesem Sommer ein häufig diskutiertes Thema, nicht zuletzt wegen der Hackerangriffe, vor denen auch Österreich nicht verschont geblieben ist. Gerade ist mir über einen Newsletter ein Bericht aufgefallen, der damit titelt: "Heimische Betriebe gehen zu unvorsichtig mit Daten um." Vor allem Klein- und Mittelbetriebe investieren manchmal erst nach einem Angriff in Ihre IT-Security. Dazu möchte ich einen kurzen aktuellen Anlassfall aus der Praxis beschreiben, anhand dem mir wieder so richtig bewusst geworden ist, wie sehr es leider immer noch stimmt, dass wir unvorsichtig mit Daten umgehen. Es handelte sich hier um eine ganz normale Kundenanfrage zum Thema Office 365, der Kunde wollte laut eigener Definition alle Serverdaten in die Cloud legen, da das eigene Serversystem nicht mehr optimal funktioniert und befürchtet wurde, dass der Server in Kürze "eingehen" wird. Bevor das aber passiert, sollte geprüft werden, wie viele Daten überhaupt vorhanden sind und ob diese in SharePoint Online ausgelagert werden könnten. Der Servercheck sollte remote durchgeführt werden, um dies festzustellen. Die Ausgangssituation ist ein SBS 2003, also nicht ungewöhnlich, bei nur 4 Usern auf Office 365 umzusteigen. Sicherheitswarnung Nr. 1: Das Administrator Kennwort wurde telefonisch bekannt gegeben, obwohl die Ansprechperson, die den Check vereinbart hatte, gar nicht vor Ort war und bestätigen konnte, dass es sich hierbei um eine reelle Anfrage handelte. Sicherheitswarnung Nr. 2: Ein 15 Minütiger Check des Servers war ausreichend um die Ursache des "Eingehens" festzustellen: der Server wurde unter anderem als Workstation verwendet, die Exchange Logfiles zeigten an bestimmten Tagen (Wochenende) eine - für vier User - sehr ungewöhnliche Größe. Die Ursache für die großen Logfiles wurde ebenfalls sehr rasch gefunden. Ein Hacker, der dieses System als Zombie für seinen Spamversand verwendete, hatte sich nicht einmal die Mühe gemacht, seine Spuren zu verstecken: Direkt im Root des Servers lag eine - konfigurierbare - Datei, wo man Absender und Inhalte des Mailversandes bequem einstellen konnte. Sicherheitswarnung Nr. 3: Bitte vertrauen Sie Experten! In diesem konkreten Fall war es weder dem lokalen IT Betreuer noch dem Kunden bewusst, was da passierte. Unsere Empfehlung war dann doch eine etwas weitreichendere als nur eine Umstellung auf Office 365: Firewall, Security Check, Einsatz von Windows Intune, usw. Prompt kam auch zwei Tage später der Anruf: Der Server steht (nein, er ist nicht gestanden, er musste nur gerade ca. 2 Millionen Spam-E-Mails abarbeiten...). - Ein Tag später: "Es ist nicht mehr so eilig, der Server geht jetzt wieder (an diesem Tag war der Server mit dem Versand der E-Mails fertig, deswegen war ein Zugriff wieder möglich). Eine gut organisierte IT und Basis-Sicherheitsmaßnahmen sollten jedem von uns ein Anliegen sein! Helfen Sie mit, indem Sie sichere Kennwörter verwenden, einen Virenschutz einsetzen, regelmäßig Sicherheitsupdates durchführen, keine illegal heruntergeladene Software installieren, eine professionelle IT-Betreuung haben oder anbieten und jene Dienste, die Sie nicht notwendigerweise selbst betreiben müssen oder wollen, in Hände von Experten geben! Dieses Unternehmen hat mit der Wahl auf Office 365 sicher kein unsicheres Service gewählt sondern zumindest erste Schritte gesetzt! Trotzdem, die Anschaffung einer Firewall (aus Kostengründen?) wurde jedoch abgelehnt.