blog.atwork.at

news and know-how 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