Single-Sign-On mit Kerberos Constrained Delegation, Teil 2 - Debugging
Hallo liebe Leser, in meinem letzten Beitrag bin ich auf die Kerberos Constrained Delegation Konfiguration eingegangen und hatte darin bereits versprochen, in diesem Beitrag das Debugging als Thema zu wählen. Dadurch, dass wir Abhängigkeiten mit anderen Komponenten haben, wird das Debuggen sicher nicht einfacher. Grundsätzlich sollte im Fehlerfall aber überprüft werden, ob die BIG-IP denn die Active Directory (AD) Infrastruktur erfolgreich erreichen kann und ob die Zeit der BIG-IP auch gleich der des Key Distribution Center (KDC) ist. Hier hilft auf dem Command Line Interface (CLI) der Befehl „ntpq –pn“ um zu überprüfen, ob die Zeit richtig ist: Die Namensauflösung ist enorm wichtig bei Kerberos, da es davon abhängig ist. Ebenso auch die Reverse-DNS Auflösung, da dies auch verwendet wird um den SPN (Service Principal Name) für jeden Server nach der Loadbalancing Entscheidung zu bestimmen. Sollten die Namen nicht richtig im DNS eingetragen sein, so kann man diese auch auf der BIG-IP statisch hinterlegen. Das ist aber nur ein Workaround und sollte eigentlich vermieden werden. Hier ein Beispiel um einen Eintrag zu setzen: # tmsh sys global-settings remote-host add { server1 { addr 1.1.1.1 hostname sven } } Natürlich ist das auch über die GUI möglich. Hier nun ein paar Beispiele, wie man die Namensauflösung überprüfen kann. Der Befehl „nslookup“ hilft einem dabei: [root@bigip1-ve:Active] config # nslookup www.example.com Server: 10.0.0.25 Address: 10.0.0.25#53 Name: www.example.com Address: 10.0.0.250 [root@bigip1-ve:Active] config # nslookup 10.0.0.250 Server: 10.0.0.25 Address: 10.0.0.25#53 250.0.0.10.in-addr.arpa name = www.example.com. [root@bigip1-ve:Active] config # nslookup w2008r2.example.com Server: 10.0.0.25 Address: 10.0.0.25#53 ** server can't find w2008r2.example.com: NXDOMAIN [root@bigip1-ve:Active] config # nslookup 10.0.0.26 Server: 10.0.0.25 Address: 10.0.0.25#53 26.0.0.10.in-addr.arpa name = win2008r2.example.com. Da Kerberos SSO sich für die KDC-Ermittlung auf DNS verlässt (sofern hier keine Adresse in der SSO Konfiguration eingetragen wurde), sollte der DNS-Server auch SRV-Records haben, die auf den KDC-Server für den Realm der Domain zeigen. Wir erinnern uns hier, dass ich dies in der Konfiguration des letzten Blogs eingetragen habe. Die Begründung war, dass es dann schneller geht: Schließlich erspart man sich genau diese Auflöse-Prozedur an der Stelle. [root@bigip1-ve:Active] config # nslookup -type=srv _kerberos._tcp.example.com Server: 10.0.0.25 Address: 10.0.0.25#53 _kerberos._tcp.example.com service = 0 100 88 win2008r2.example.com. [root@bigip1-ve:Active] config # nslookup -type=srv _kerberos._udp.example.com Server: 10.0.0.25 Address: 10.0.0.25#53 _kerberos._udp.example.com service = 0 100 88 win2008r2.example.com. Sind diese grundlegenden Konfigurationen nun überprüft und korrekt, aber es funktioniert noch nicht, hilft ein Blick in das APM Logfile. Vorher sollte aber der Debug-Level höher eingestellt werden. Dies bitte nur während des debuggens machen und anschließend wieder zurück stellen. Im Menü kann man unter System/Logs/Configuration/Options den Level einstellen. „Informational“ ist hier ein guter Start. „Debug“ kann man sicher auch verwenden, aber der Level ist schon extrem gesprächig und in der Regel reicht „Informational“ vollkommen. Schauen wir uns doch mal einen Ausschnitt eines Anmeldeprozesses an. Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:862 Initialized UCC:user1@EXAMPLE.COM@EXAMPLE.COM, lifetime:36000 kcc:0x8ac52f0 Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:867 UCCmap.size = 1, UCClist.size = 1 Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1058 S4U ======> - NO cached S4U2Proxy ticket for user: user1@EXAMPLE.COM server: HTTP/win 2008r2.example.com@EXAMPLE.COM - trying to fetch Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1072 S4U ======> - NO cached S4U2Self ticket for user: user1@EXAMPLE.COM - trying to fetch Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1082 S4U ======> - fetched S4U2Self ticket for user: user1@EXAMPLE.COM Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1104 S4U ======> trying to fetch S4U2Proxy ticket for user: user1@EXAMPLE.COM server: HTTP/win2008r2.example.com@EXAMPLE.COM Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1112 S4U ======> fetched S4U2Proxy ticket for user: user1@EXAMPLE.COM server: HTTP/win2008r2.example.com@EXAMPLE.COM Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1215 S4U ======> OK! Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:236 GSSAPI: Server: HTTP/win2008r2.example.com@EXAMPLE.COM, User: user1@EXAMPLE.COM Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:278 GSSAPI Init_sec_context returned code 0 Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:316 GSSAPI token of length 1451 bytes will be sent back Hilfreich ist es natürlich auch die Logfiles des IIS anzuschen. Hier kann man sich auch den Usernamen anzeigen lassen (C:\inetpub\logs\LogFiles\W3SVC1): #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken 2011-10-27 21:29:23 10.0.0.25 GET / - 80 EXAMPLE\user2 10.0.0.28 Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+Trident/5.0) 200 0 0 15 Eine weitere Fehleranalysemöglichkeit ist natürlich sich anzuschauen, was denn für Daten über die Leitung gehen. Tcpdump und Wireshark sind hierbei unsere Freunde, # tcpdump –i internal –s0 –n–w /tmp/kerberos.pcap host 10.0.0.25 -i: das VLAN, die es zu belauschen gilt. Wählt man hier „0.0“ wird auf allen Schnittstellen gesniffert und man sieht die Pakete entsprechend oft. bzw. auch die Veränderungen, die ein Paket ggf. beim Durchlaufen der BIG-IP erfährt. -s0: bedeutet, dass das gesamte Paket aufgezeichnet werden soll -n: keine Namensauflösung -w /tmp/kerberos.pcap: Die Aufzeichnungen in die Datei /tmp/kerberos.cap speichern host 10.0.0.25: nur Pakete mit der Quell- oder Ziel-IP 10.0.0.25 aufzeichnen. Im Wireshark sieht eine Aufzeichnung dann etwa so aus: Wireshark versteht das Kerberos Protokoll und gibt somit gute Hinweise auf mögliche Probleme. Da APM die Kerberos Tickets cached, kann dies natürlich beim Testen zu unerwünschten Effekten führen. Das bedeutet es macht durchaus Sinn, während der Tests die Ticket Lifetime von standardmässig 600 Minuten runter zu setzen. Zudem kann man auch den Cache mit folgenden Befehl leeren: # bigstart restart websso Zum guten Schluß möchte ich dann noch ein paar Fehlermeldungen erläutern, die man im Log bei Problemen finden kann: Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Cannot find KDC for requested realm (-1765328230) – Hier sollte man überprüfen ob DNS funktioniert und der DNS Server alle SRV/A/PTR Records der involvierten Realms hat. In der Datei /etc/krb5.conf auch bitte überprüfen, ob dns_lookup_kdc auf True gesetzt ist. Den Eintrag findet man in dem Bereich [libdefaults]. Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Preauthentication failed (-1765328360) – Das Delegation Account Passwort ist falsch. Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Client not found in Kerberos database (-1765328378) – Der Delegation Account existiert nicht im AD. Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Clients credentials have been revoked (-1765328366) – Der Delegation Account ist im AD abgeschaltet. Kerberos: can't get TGT for host/apm.realm.com@realm.com - KDC reply did not match expectations (-1765328237) – Der Realm Name in der SSO Konfiguration muss groß geschrieben sein. Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - A service is not available that is required to process the request (-1765328355) – Die Verbindung mit dem KDC ist nicht möglich. Gründe können z.B. sein: Firewall, TGS Service auf dem KDC läuft nicht oder es ist der falsche KDC angegeben… Kerberos: can't get S4U2Self ticket for user a@REALM.COM - Client not found in Kerberos database (-1765328378) – Es gibt den User 'a' nicht in der Domain REALM.COM. Kerberos: can't get S4U2Self ticket for user qq@REALM.COM - Ticket/authenticator don't match (-1765328348) – Der Delegation Account hat die Form UPN/SPN und entspricht nicht der verwendeten REALM Domain. Achtung, wenn man hier mit Cross-Realms arbeitet! Kerberos: can't get S4U2Self ticket for user aa@realm.com - Realm not local to KDC (-1765328316) – Das KDC Feld muss leer gelassen werden in der SSO Konfiguration, wenn man mit Cross-Realm SSO arbeitet. Also wenn ein User einen Server in einem anderen Realm erreichen muss. Kerberos: can't get S4U2Proxy ticket for server HTTP/webserver.realm.com@REALM.COM - Requesting ticket can't get forwardable tickets (-1765328163) – Der Delegation Account ist nicht für Constrained Delegation und/oder Protocol Transition konfiguriert. Kerberos: can't get S4U2Proxy ticket for server HTTP/webserver.realm.com@REALM.COM - KDC can't fulfill requested option (-1765328371) – Der Delegation Account in REALM.COM hat keinen Service für webserver.real.com in seiner Konfiguration. Damit Sie Kerberos auf der Windows Seite debuggen können, hilft vielleicht dieser Artikel: • http://www.microsoft.com/downloads/details.aspx?FamilyID=7DFEB015-6043-47DB-8238-DC7AF89C93F1&displaylang=en So, ich hoffe natürlich, dass Sie keine Probleme bei der Konfiguration des SSO mit Constrained Delegation haben, aber falls doch, hilft Ihnen hoffentlich dieser Blog-Beitrag, um dem Problem schneller auf die Spur zukommen. Ihr F5-Blogger, Sven MüllerSingle-Sign-On mit Kerberos Constrained Delegation
Hallo liebe Leser, als heutiges Thema möchte ich über ein weiteres Single-Sign-On Verfahren sprechen: Kerberos Constrained Delegation. Was bedeutet das? Nun was hier passiert, ist dass der User sich am Access Policy Manager (APM) anmeldet. Hier können natürlich verschiedene Verfahren verwendet werden, wie z.B. Client-zertifikatsbasierte Anmeldung, oder Username/Passwort, die Kombination aus beiden oder eben auch andere Methoden. Entscheidend jedenfalls ist, dass sich der User authentifiziert und der Access Policy Manager (APM) anschließend ein Ticket für den User vom Key Distribution Center (KDC) erhält. Dieses Ticket wird dann dem User-Request hinzugefügt, damit am Backend-Server die entsprechende Authentifizierung mittels Kerberos erfolgreich verläuft. Anwendung findet dieses Verfahren häufig, wenn User aus dem „externen“ Netz zugreifen und somit keine Möglichkeit haben, selber ein Ticket vom KDC zu erhalten. Damit die BIG-IP aber überhaupt ein Ticket für den User bekommt, muss ein entsprechender Delegation-Account auf dem Domain Controller (DC) angelegt sein. Windows Administratoren fühlen sich hier vermutlich zu Hause. Für alle anderen ein paar Screenshots, die bei dieser Konfiguration hoffentlich helfen: Der „Advanced View“ im „Active Directory Users and Computers“ ermöglicht es den Attribute Editor unter User Properties auszuwählen. Nun legen wir einen User-Account an: User logon name = host/apm.example.com User logon name pre Windows 2000 = apm.example Der servicePrincipial Name muss dem DC hinzugefügt werden, bevor man in den Delegation Reiter des User wechselt. Dies kann mit dem Tool „setspn“ oder „adsiedit“ durchgeführt werden: run adsiedit.msc Nun den Usernamen auswählen, Properties wählen, und den Eintrag servicePrincipalName auswählen und „host/apm.example.com“ hinzufügen. Oder man fügt den Principial Name über den Attribute-Editor in den User Eigenschaften hinzu: Schließt man nun das Property Fenster und öffnet es wieder, hat man Zugriff auf den Delegation Tab. Hier kann man nun die Delegationsrechte für den User auf einen bestimmten Service freigeben. In meinem Beispiel ist es „WIN2008R2.example.com“. Übrigens das ist der Name meines Backend-Servers. Hat man mehrere müssen diese ebenfalls hinzugefügt werden. Unter den Account Options sollte man nun nochmal überprüfen, dass keine Account Optionen gesetzt sind. Der Delegation User brauch nur Mitglied der „Domain User“ zu sein. Um zu überprüfen, dass es keine Konflikte in der Kerberos Konfiguration gibt, kann man „setspn –x“ aufrufen: Wichtig bei dem Thema Kerberos ist, dass man alle DNS Einträge richtig gesetzt hat. Hier bitte alle Adressen und Namen die in dem Zusammenhang verwendet werden in beide Richtungen auflösen. Das kann einem so manches Debugging ersparen. Ganz wichtig auch: die Zeit! NTP sollte auf der BIG-IP auf jeden Fall eingestellt sein und synchron zum DC sein! DNS sollte natürlich auch funktionieren. Fassen wir kurz zusammen: Wir haben nun also einen User im DC konfiguriert, der für einen bestimmten Service im Namen eines anderen Nutzers ein Kerberos Ticket erstellen darf. Das ist noch nicht viel, kommen wir nun also zur Konfiguration der BIG-IP. Übrigens die Kerberos Konfiguration des IIS überlasse ich erstmal komplett dem Windows-Admin ;-). Als erstes richten wir auf der BIG-IP eine Kerberos SSO-Konfiguration ein: Unter „SSO Configurations“ findet man auch schon die passende Option. Was gibt es hier zu beachten? Ich habe bei mir den KDC eingetragen, das muss nicht sein. Ist in der Praxis aber etwas schneller, da der KDC nicht erst discovered werden muss. Namen können hier natürlich auch eingesetzt werden. Spannend ist immer der SPN Pattern. Per default, also wenn nichts eingetragen ist, wird hier HTTP/%s@REALM verwendet. Wobei das %s für den Namen des ausgewählten Backend-Server steht. Kurz zusammengefasst: Der Request trifft bei der BIG-IP ein, es wird die Authentifizierung durchgeführt und bevor der Request an den Backend-Server weitergereicht wird, muss dieser über das Balancing-Verfahren ausgewählt werden. Die IP-Adresse des Ziel-Servers wird über DNS Reverse-Lookup aufgelöst und der Name wird als SPN verwendet. Das bedeutet natürlich auch, dass für den Delegation-Account auch die entsprechenden Namen hinzugefügt werden müssen (s.o.). Alternativ kann man auch statt mit „Host-based“ mit „Domain Account-based“ Zugriff arbeiten und würde unter dem SPN Pattern einen Eintrag der Form „http/www.example.com“ vornehmen. Natürlich muss die Konfiguration der IIS-Server auch entsprechend angepasst werden. Als Credential Source müssen die Variablen genommen werden, in denen nachher auch die entsprechenden Informationen enthalten sind. Kommen wir zum nächsten Schritt. Dem Anlegen einer Access-Policy: Hier wählen wir das übliche Vorgehen. Unter Access Profiles klicken wir auf das „Plus-Zeichen“, geben der Policy einen Namen, fügen eine Sprache hinzu und vergessen nicht unter „SSO Configuration“ unser eben angelegtes Kerberos-SSO Objekt auszuwählen. Für den ersten Test sollte das reichen, Timeout-Werte etc. können später noch entsprechend angepasst werden, falls notwendig. Öffnen wir nun der „Visual Policy Editor“ (VPE). Eine User Authentifizierung gegen das AD habe ich in einem vorigen BLOG-Beitrag schon gezeigt, daher denke ich, lassen wir den User sich diesmal mittels Client Zertifikat ausweisen. Damit das auch funktioniert, müssen wir unserem Client-SSL-Profil noch eine Eigenschaft hinzufügen. Nämlich, dass ein Client-Zertifikat benötigt oder wie in diesem Screenshot zu sehen angefragt (request) wird. Geprüft wird es dann gegen die entsprechende CA. Die Frage lautet nun sicher, warum ich das vorhanden sein eines validen Client Zertifikat, nicht auf „require“ gesetzt habe. Nun, da spricht nichts gegen, aber ich will die Kontrolle dessen, in der Access-Policy abfangen und genau da hin kommen wir jetzt. In meiner Policy füge ich als erstes nun das „On-Demand-Cert-Auth“ Objekt ein. Hier muss das Client-Zertifikat nun auch vorhanden sein. Übrigens wird hier ein SSL-Rehandshake durchgeführt. Ist das Client-Zertifikat nun valide, ist der User autorisiert, auf den Backend-Server zuzugreifen. Vorher brauchen wir aber noch ein Kerberos-Ticket für ihn. Das bedeutet aus dem Zertifikat müssen wir den Usernamen extrahieren. Dieser kann in verschiedenen Feldern des Zertifikates stehen. Mit Hilfe des „Variable Assigns“ und ein wenig TCL können wir aber ziemlich flexibel auf alles eingehen. Fügen wir als erstes also das Objekt „Variable Assign“ in unseren „Successful“-Branch ein. Mit Hilfe des Variable Assign können wir neue Variablen erstellen, oder bestehende verändern. Wir erinnern uns an unsere Kerberos-SSO Konfiguration. Dort haben wir angegeben, dass der Username aus der Variablen session.logon.last.username genommen werden soll und die Domain aus session.logon.last.domain. Das bedeutet, wir müssen nun dafür sorgen, dass diese Variablen auch entsprechend gefüllt sind. Ein Blick in die bereits existierenden Session Variablen nach einem ersten Einloggen verrät, dass in meinem Fall der Username in der Variablen session.ssl.cert.x509extension gespeichert ist und er dort nun aus der recht langen Zeile extrahiert werden muss. Was es angenehm macht, mein Username ist in meiner Mail-Adresse enthalten und steht begrenzt von den Zeichen UPN<sven.mueller@example.com> Also kann ich die Mailadresse mit ein wenig Regular Expression schnell rausfiltern. Zur Erklärung: set f1 [mcget {session.ssl.cert.x509extension}] Speichert den Inhalt der Session Variablen in die temporäre Variable f1, mit der im Folgenden gearbeitet wird. regexp {(.*)UPN<(.*)>(.*)} $f1 matched sub1 sub2 sub3 Verwende Regular Expression und speichere alles was in der ersten runden Klammer matched, in die Variable sub1. Das sind alle Zeichen (.*) bis zur Zeichenfolge „UPN<“. Alles was dann an Zeichen kommt, bis zum Zeichen „>“ (und das ist die Mailadresse) speichere in die Variable sub2. Der Rest soll in die Variable sub3 gespeichert werden. Das Ganze soll angewendet werden, auf den Inhalt der Variablen f1, also session.ssl.cert.x509extension. return $sub2 Weist den Inhalt der Variablen sub2 (also die Mailadresse) und die Session Variable session.logon.custom.username zu. Soweit so gut. Nun muss der Username, also der Teil vor dem „@“ Zeichen noch extrahiert werden und der Domain Teil muss auch noch in eine Session-Variable geschrieben werden. Also fügen wir dem Variablen Assign noch zwei Einträge hinzu: session.logon.last.username expr {[lindex [split [mcget {session.logon.custom.username}] "@"] 0]} Hier zerlegen wir den Inhalt der Variablen session.logon.last.username in ein Array und als Trenner soll das „@“ Zeichen dienen. Somit steht im 0-ten Feld des Array unser Unsername. session.logon.last.domain expr {[lindex [split [mcget {session.logon.custom.username}] "@"] 1]} Im 1-ten Feld des Array steht die Domain und die weisen wir nun auch einer Session Variablen zu. Perfekt! Schon ist alles fertig. Policy applyen, dem entsprechenden virtuellen Server zufügen und testen. J Falls es nun doch noch nicht auf Anhieb funktioniert, so werde ich in meinem nächsten Beitrag auf das Debuggen eingehen. Bis dahin aber erstmal viel Erfolg und Spaß bei der Konfiguration. Ihr F5-Blogger, Sven Müller
Sind Sie vor DDoS Attacken sicher?
In der Presse hört man vermehrt von DDoS Attacken. Jeden Tag entnehmen wir den Nachrichten von neuen Unternehmen, die Opfer einer DDoS-Attacke wurden. Die Wahrheit ist, dass Organisationen immer ausgefeilteren Attacken ausgesetzt sind, die automatisierte Systeme nutzen, um Webapplikationen zu verzögern oder lahm zu legen. Durch jeden neuen Skandal, werden die Fragen der IT Verantwortlichen lauter: · Wären wir gewappnet gewesen? · Weiss mein Team, wo die Applikationen Schwachstellen haben? · Haben wir die richtige Lösung, um Massen an http-Datenverkehr zu meistern? · Wie könnten wir eine Attacke abwehren und gleichzeitig die Verfügbarkeit von Applikationen für unsere Kunden sicherstellen? Gehen Sie kein Risiko ein und ersparen Sie Ihrem Unternehmen diese ungewollte und vor allem negative PR. In unserem Whitepaper geben wir Ihnen einen Überblick, wie Sie Ihre Applikationen vor derlei Gefahren und DDoS-Attacken schützen. Download des Whitepapers: In drei Schritten zum Schutz Ihrer Applikationen gegen DDoS-Attacken mit F5's BIG-IP ASM.
Denn Sie wissen nicht, dass Sie gehackt wurden
Sind Sie sicher, dass Ihre IT sicher ist? Im Data Breach Investigations Report (DBIR) 2013 analysiert Verizon Angriffe auf die IT und greift dabei auf sechs Jahre Erfahrung und umfangreiche Daten zurück. Es wurden mehr als 47.000 Vorfälle untersucht und 621 bestätigte Datenlecks aus 27 Ländern unter die Lupe genommen. Die Daten stammen von 19 internationalen Organisationen wie Exekutivorganen, nationalen Entitäten, Forschungseinrichtungen und privaten Sicherheitsfirmen. Die Ergebnisse sind kurz gesagt alarmierend. Schon die pure Zahl der gemeldeten Vorfälle ist besorgniserregend hoch, da keine Meldepflicht von Cyber-Attacken besteht, ist die Dunkelziffer wahrscheinlich sehr viel höher. Dabei waren Organisationen aller Größen das Ziel von Cyber-Attacken. Die meisten Angriffe zielen auf klassische Geräte wie Geldautomaten, Desktops, File-Server und Laptops ab. Sie denken vielleicht, dass alle Alarmsysteme anspringen, wenn Ihre IT kompromittiert werden würde. Leider ist dem nicht so, im Gegenteil fließen Daten lange Zeit unbemerkt ab. In 84 Prozent der Fälle dauerte es nur Stunden, bis die Angreifer einen Zugang hatten, in 66 Prozent aller Fälle dauerte es jedoch Monate oder sogar Jahre, bis das Leck entdeckt wurde. Leck entdeckt, Leck gefixt, Daten wieder sicher? So einfach ist es leider auch nicht, in 22 Prozent der Fälle dauerte es Monate, bis das entdeckte Leck geschlossen werden konnte. Dazu passt auch, dass 69 Prozent der Datenlecks nicht von der eigenen IT sondern von externen Personen oder Organisationen entdeckt wurden - neun Prozent davon sogar von Kunden. Wollen Sie von Ihren Kunden auf eine Sicherheitslücke angesprochen werden? Was die wenigsten beachten: Nicht nur direkte Angriffe sind ein Problem. Wenn beispielweise Teile Ihrer Supply Chain gehackt werden, kann der Dominoeffekt für Ihre Organisation genauso schlimm sein wie, als wenn Sie selbst gehackt worden wären. Schlimmer noch: Sie könnten die Marschroute für eine Attacke auf einen Ihrer Kunden sein. Der DBIR teilt die Angreifer in drei Gruppen ein: Aktivisten oder Hacktivisten nutzen einfache Methoden, sind opportunistisch, treten in hoher Zahl auf und wollen ihren Opfern größtmögliche Schäden und Peinlichkeiten bereiten. Kriminelle wollen Geld ergaunern, agieren mit fortgeschritteneren Techniken als die Hacktivisten und wählen ihre Ziele sorgfältig aus. Nachdem sie Zugriff erlangt haben, schnappen sie sich alle Daten, die finanziell verwertbar erscheinen. Die Gruppe der Spione wird oft von Nationalstaaten finanziert und nutzt die ausgefeiltesten Hacker-Methoden. Spione gehen extrem präzise und unermüdlich vor und wissen genau, welche Daten sie wollen. Man sollte ja meinen, dass Spione nur Regierungen, Militäreinrichtungen und sehr prominente Organisationen angreifen, aber die Ergebnisse des DBIR zeigen, dass auch andere Organisationen Opfer von Spionen werden. Die meisten Angriffe von Kriminellen kommen aus den USA und Osteuropa. Von Spionen ausgeführte Attacken betrafen Organisationen auf der ganzen Welt – insofern ist davon auszugehen, dass Spione aus der ganzen Welt involviert waren. In vielen Branchen ist es weiterhin am wahrscheinlichsten, von Cyber-Angriffen von Kriminellen oder von Personen mit Rachemotiv attackiert zu werden – die Wahrscheinlichkeit von Spionageangriffen ist dagegen gering. Insgesamt wurden 19 Prozent aller analysierten Attacken von Spionen verübt. Es gibt auch gute Nachrichten: Zwar steigt die Zahl der ausgefeilteren Angriffe, allerdings könnten die meisten Datenlecks recht einfach verhindert werden. Weniger als ein Prozent der im diesjährigen DBIR analysierten Attacken entspricht dem höchsten Grad an Hacker-Können – 78 Prozent der Angriffe fallen in die Kategorie niedrig und sehr niedrig. Mehr als Dreiviertel der Attacken (76 Prozent) basierten auf schwachen oder gestohlenen Anmeldedaten. Durch strikte Policies lässt sich diese Sicherheitslücke effektiv verschließen. Generell ist auch ein Wandel der IT-Bedrohungen festzustellen. Laut Gartner werden zwar 90 Prozent der Budgets immer noch auf Netzwerk-Ebene im Bereich Sicherheit getätigt, allerdings finden 75 Prozent aller Angriffe auf der Applikationsebene statt. Neuen Bedrohungen begegnet der IT-Verantwortliche von heute daher logischerweise mit neuen Maßnahmen. F5 empfiehlt: zentralisierte, flexible Access Policy Control, der umfassenden Schutz bietet und die Produktivität der Anwender aufrecht erhalten eine DNSSEC-Lösung, welche Sicherheit, verbesserte Performance und globale Verfügbarkeit bietet eine sichere Web Application Firewall und eine umfassende, Policy-basierte Herangehensweise bezüglich der Sicherheit von Web-Applikationen, wodurch Sicherheitsbedrohungen auf Application-Level adressierbar werden Gegen DDoS-Attacken empfiehlt F5 einen kombinierten Schutz für Network Layer DDoS-Attacken (L2-L4) mit DDoS-Attacken auf Application-Layer-Ebene (L5-L7). Die IT-Sicherheit beinhaltet immer eine menschliche Komponente, wie auch im DBIR betont wird. Viele Datenlecks kommen beispielweise aus Versehen zu Stande. Die Mitnahme von Informationen nach Hause, Kopieren von Daten auf einen USB-Stick, das Vergessen eines Laptops im Taxi: Daraus können Datenlecks entstehen. Bei 29 Prozent der Angriffe kamen zudem Social Tactics zum Einsatz – hier werden E-Mail, Telefonanrufe und soziale Netzwerke genutzt, um Informationen über Individuen zu sammeln. Wenn Sie Ihre IT-Sicherheit nun auf den Prüfstand stellen, sollten Sie neben Hard- und Software-Lösungen von F5 oder anderen auch den Wissensstand Ihrer Mitarbeiter berücksichtigen. Technorati Tags: Security
Unternehmensanwendungen sind nicht für Geschwindigkeit ausgelegt
Eine der Lektionen, die ich bereits früh in der IT-Branche gelernt habe, war, dass sich in der Anwendungsentwicklung die Wartungsfreundlichkeit und ein einfaches Management meist negativ auf die Leistung einer Anwendung auswirkt. Anwendungen werden oft nicht im Hinblick auf Performance-Optimierung entwickelt, sondern um spezielle Funktionen und Aufgaben auszuführen. Im Betrieb fällt dann meist erst auf, daß die Leistung der Anwendung recht niedrig ist, wobei „die Anwendung neu zu schreiben“ keine Option ist. Das ist kostspielig und die notwendigen Änderungen stünden vermutlich im Konflikt mit dem vorrangigen Ziel. Selbst moderne, auf das Internet konzentrierte Unternehmen wie Twitter und Facebook hatten bereits Leistungsprobleme, die auf sehr früh getroffene Architekturentscheidungen zurückgehen. Viele Menschen erinnern sich zweifellos an die oft sehr technischen Diskussionen hinsichtlich des Designs und der Interaktion von Twitter mit seiner Datenbank als Ursprung von Leistungsproblemen, bei denen hunderte von Experten Ratschläge anboten und Kritik übten. Durch Anwendungsoptimierung kann die Leistung enorm verbessert werden Dies ist einer der Hauptgründe, warum der Bereich der Anwendungsbereitstellung (Application Delivery) existiert: die Kompensierung von Problemen innerhalb der Anwendung, die nicht durch die Modifikation der Anwendung selbst behoben werden können. Anwendungsbeschleunigung, WAN-Optimierung und Lastverteilung bilden eine leistungsstarke Ebene von Anwendungsbereitstellungsdiensten innerhalb des Rechenzentrums. Lastverteilung kann sich enorm positiv auf die Leistungsfähigkeit und somit der User-Akzeptanz der Anwendung auswirken. Techniken für die Anwendungsbeschleunigung verbessern die Bereitstellung und Auslieferung von applikationsbezogenen Inhalten und Objekten durch Caching, Komprimierung, Umwandlung und Verknüpfung. Services zur WAN-Optimierung behandeln Bandbreitenbeschränkungen und Latenzproblemen, besonders die mit hohem Daten- und Inhaltsumfang. Obwohl Entwickler Anwendungen an sich modifizieren könnten, um Inhalte neu anzuordnen oder die bereitgestellte Datengröße zu reduzieren, ist dies nur selten praktikabel oder rentabel. Gleichermaßen ist es nicht rentabel oder praktikabel, Entwickler darum zu bitten, Anwendungen zur Entfernung von Verarbeitungsengpässen zu modifizieren, die zu unlesbarem Code führen könnten. Unternehmensanwendungen werden nicht für die Geschwindigkeit entwickelt, obwohl genau das die Benutzer von ihnen erwarten. Beide Bedürfnisse müssen erfüllt werden, und die Einführung einer Anwendungsbereitstellungsebene in der Architektur kann dazu dienen, die Balance zwischen Leistung, Wartungsfreundlichkeit und einfachem Management zu liefern, indem dynamisch Beschleunigungsservices angewendet werden. Auf diese Weise müssen Anwendungen nicht modifiziert werden, aber die Leistung und Skalierung werden stark verbessert. Technorati Tags: Application Delivery,PerformanceReibungsloser Datenfluss in der mobilen Welt von heute
Geht es Ihnen auch so? Es scheint, als könne man heutzutage keine Technologie-Website mehr besuchen, ohne mit Neuigkeiten zu Mobilität, BYOD (Bring Your Own Device) oder 4G-Netzwerken bombardiert zu werden, die ultraschnellen Internetzugang für Millionen von mobilen Mitarbeitern im ganzen Land versprechen. Doch während für die meisten Benutzer nur wichtig ist, das neueste Gerät zu besitzen und unterwegs über eine funktionierende Internetverbindung zu verfügen, müssen die Service Provider hinter den Kulissen sehr viel mehr leisten. Die steigende Zahl an Benutzern, die heutzutage ununterbrochen eingeschalteten Geräte und die dadurch entstehenden immensen Datenmengen, wie auch die enorme Anzahl an Abrechnungsinformationen bereiten den Service Providern Kopfzerbrechen. Hier bei F5 sind wir uns dieser Problematik bewusst. Die verfügbaren Funktionen für mobile Benutzer werden immer komplexer und ausgereifter, was eine zusätzliche Last für die Netzwerke bedeutet. Das Problem liegt darin, dass viele dieser Netzwerke und Infrastrukturen veraltet sind und errichtet wurden, bevor die ultraschnellen Netzwerke und fortschrittlichen Mobilgeräte von heute verfügbar waren. Dies führt in manchen Fällen also zu einer Beeinträchtigung der Leistung und der Sicherheit. Einige Anwendungen bringen nicht die volle Leistung, wenn es zu verstärktem Datenverkehr auf den Netzwerken kommt. Darüber hinaus können viele Anwendungen aus dubiosen Quellen zu einem Sicherheitsrisiko für den Benutzer, das Unternehmen und den Service Providern werden. Aus diesem Grund setzen wir auf eine anwendungsorientierte Vorgehensweise bei der Sicherheit sowie auf zentrale Verwaltung und Richtlinienkontrollen geachtet wird. Das bedeutet, dass Richtlinien und Schutzmaßnahmen auf jede einzelne Anwendung und jedes Unternehmen individuell zugeschnitten werden und durch die Zentralisierung der Verwaltung gleichzeitig Zeit und Kosten bei der Erarbeitung und Umsetzung von Richtlinien eingespart werden können. Der Schlüssel dazu ist im Wesentlichen die Sicherstellung einer reibungslosen und einfachen Verwaltung im Hintergrund, damit Benutzer einen schnellen, zuverlässigen und sicheren mobilen Service erhalten, und der Leistungsdruck auf die Service Provider verringert wird. Mit unseren neuesten Entwicklungen im Bereich Firewall können wir mobile Serviceanbieter unterstützen. Klicken Sie hier, um mehr zu erfahren. Technorati Tags: Access,Security80-percent aller Web-Applikationen sind offen fur Attacken - Ihre auch?
Technorati Tags: Security Evaluieren Sie Ihr Risiko mit F5's Angebot zu einem kostenfreien Scan Ihres Netzwerks. Ein Klick und Sie sehen, wo Ihr Netzwerk verwundbar ist. F5 bietet integrierte Lösungen mit den führenden Schwachstellen-Scanning-Technologien von Cenzic und WhiteHat: · Sicherheit und Hochverfügbarkeit für Ihre Applikationen: Nutzen Sie einen umfassenden Geolocation-Schutz vor Layer 7 Distributed Denial of Service (DDoS) und OWASP Top Ten Attacken. · Reduzieren Sie Ihr Risiko und Ihre Kosten: Im Durchschnitt benötigt man 60 Tage und mehr, um ernsthafte Bedrohungen in der Programmierung zu reflektieren. Der F5 BIG-IP Application Security Manager kann 80% der bekannten Schwachstellen direkt ausmerzen, so Ihr Risiko eingrenzen und schont gleichzeitig die Zeit Ihrer Programmierer. · Einfache Integration in den Software Development Lifecycle (SDLC): Entwickeln Sie ein umfassendes Sicherheitskonzept für Ihre Webseiten, das eine Entschärfung von Attacken und Schutz Ihrer Anwendungen als Teil Ihres Software Development Lifecycles (SDLC) ermöglicht. · Erreichen Sie Konformität: Erfüllen Sie alle regulatorischen Vorgaben, wie zum Beispiel PCI DSS. Testen Sie die Lösung. Kostenfreier Scan mit dem Anbieter Ihrer Wahl: Cenzic oder WhiteHat.Lösen von Nachweisen mit SAML
Organisationen stellen verteilte Hybridarchitekturen bereit, die mehrere Sicherheitsdomänen umfassen können. Jederzeit könnte ein Benutzer auf das Datenzentrum des Unternehmens, die Cloud-Infrastruktur der Organisation oder sogar auf die #SaaS-Webanwendung eines Drittanbieters zugreifen. #SAML kann die Identifikationsdaten anbieten, die für die Implementierung einer unternehmensweiten Single-Sign-On-Lösung notwendig sind. Das Überprüfen der Identität einer Person kann im echten Leben einfach durch das Vorzeigen eines Führerscheins oder eines Ausweises durchgeführt werden. Wenn das Foto mit dem Gesicht übereinstimmt, wird normalerweise nichts mehr für die Überprüfung der Identität benötigt. Diese Bestätigung der Identität ist eine physikalische Form von Authentifizierung, und je nach Situation ist die Person anschließend berechtigt, etwas zu empfangen oder zu tun, z. B. einen Barcode eingeben, einen Kauf durchführen usw. In der digitalen Welt kann man dem Computermonitor nicht einfach einen Führerschein zur Identitätsüberprüfung zeigen. Um Zugriff zu erlangen, müssen Sie Informationen wie einen Namen, ein Passwort oder eine zufällig generierte Tokennummer (etwas, das Sie besitzen, wissen oder sind) angeben, um zu beweisen, dass Sie die richtige Person sind. Zugriff auf Unternehmensgeräte zu erhalten, verläuft nicht anders. Viele Organisationen verwenden viele unterschiedliche Ressourcen-Portale, allerdings verlangt jedes davon einen digitalen Identitätsnachweis. Ihre Benutzer müssen möglicherweise auch auf Partnerportale, Cloud-basierte SAAS-Anwendungen (Software as a Service) oder verteilte Hybridinfrastrukturen zugreifen, die sich über mehrere Datenzentren erstrecken und jeweils einen einzigartigen Benutzernamen und ein einzigartiges Passwort benötigen. Darüber hinaus muss sich der durchschnittliche Angestellte ca. 15 verschiedene Passwörter für private und geschäftliche Identitäten merken, wobei viele dieser Passwörter auch für soziale Medien und andere riskante Dinge verwendet werden. Statistiken belegen, dass 35 bis 50 Prozent der Helpdesk-Anrufe mit Passwortproblemen zusammenhängen, wobei dem Unternehmen jeder Anruf zwischen 25 und 50 US-Dollar pro Anfrage kostet. Security Assertion Markup Language (SAML) ist ein XML-basierter Standard, der sichere Web-Domains zum Austausch von Benutzerauthentifizierungen sowie Autorisierungsdaten ermöglicht. Er geht das Problem direkt an, wie man den Benutzern eines Internetbrowsers die Bequemlichkeit von Single-Sign-On (SSO) bieten kann. Mit SAML kann ein Online-Serviceanbieter einen separaten Anbieter für Onlineidentitäten kontaktieren, um Benutzer zu authentifizieren, die auf sichere Inhalte zugreifen möchten. Vielleicht möchte sich ein Benutzer z. B. bei Salesforce.com anmelden, aber Salesforce (der Serviceanbieter) besitzt keine Möglichkeit, um den Benutzer zu überprüfen. Salesforce würde dann eine Anfrage an den Identitätsanbieter senden, z. B. F5 BIG-IP® Access Policy Manager (APM), um die Identität des anfragenden Benutzers zu überprüfen. BIG-IP APM Version 11.3 unterstützt die SAML-Federation und dient entweder als Service- oder als Identitätsanbieter, verbessert die Online-Erfahrung des Kunden und reduziert unter Umständen Tickets mit Passwortproblemen beim Helpdesk. BIG-IP APM Version 11.3 kann entweder als SAML-Serviceanbieter oder als SAML-Identitätsanbieter dienen und ermöglicht innerhalb eines Unternehmens Federation sowie SSO. BIG-IP APM als Serviceanbieter Wenn ein Benutzer eine Anfrage von einem SAML-IDP sendet und die Ressourcen, wie z. B. eine interne SharePoint-Site, von BIG-IP APM geschützt werden, nimmt BIG-IP APM diese SAML-Forderung auf und überprüft deren Vertrauenswürdigkeit. Dies ermöglicht dem Benutzer am Ende, auf die Ressource zuzugreifen. Wenn sich der Benutzer direkt an BIG-IP APM wendet (als Serviceanbieter), um auf eine Ressource (wie z. B. SharePoint) zuzugreifen, dann wird er zur Authentifizierung und für den Erhalt einer Forderung zum Identitätsanbieter weitergeleitet. Sobald ein Benutzer mit einem SAML-IDP authentifiziert ist und hinter BIG-IP APM auf eine Ressource zugreift, muss er sich nicht erneut authentifizieren. BIG-IP APM als Identitätsanbieter Vorausgesetzt, es gibt einen Dienstanbieter, der Forderungen akzeptiert, kann sich ein Benutzer mit BIG-IP APM authentifizieren, um eine Forderung zu erstellen. BIG-IP APM authentifiziert den Benutzer und zeigt die Ressourcen an. Wenn der Benutzer auf die Anwendung klickt, generiert BIG-IP APM eine Forderung. Diese Forderung kann an den Dienstanbieter weitergegeben werden, wodurch ohne weitere Authentifizierungen ein Zugriff auf die Ressource ermöglicht wird. Wenn der Benutzer zuerst den Dienstanbieter besucht, wird der Vorgang vom Dienstanbieter gestartet. Wenn sich der Benutzer für die Authentifizierung zunächst direkt an den Identitätsanbieter wendet (in diesem Fall BIG-IP APM), wird der Vorgang vom Identitätsanbieter gestartet. BIG-IP APM in einer SAML-Federation SAML kann verwendet werden, um eigenständige BIG-IP APM-Systeme zu verbinden. Dadurch kann ein Benutzer eine Verbindung mit einem BIG-IP-Gerät herstellen, sich authentifizieren und transparent auf andere teilnehmende BIG-IP-Geräte übergehen. Sitzungsreplikation ist kein Teil von SAML, allerdings können Administratoren Sitzungsinformationen auf teilnehmenden Systemen verbreiten. Dies bedeutet, dass die BIG-IP-Geräte-Federation nicht die Verwendung einer einzelnen Sitzung innerhalb der Federation ermöglicht. Es ist nur ein Informationsaustausch zwischen mehreren Mitgliedern der Federation möglich. Jedes teilnehmende BIG-IP-Gerät verfügt über seine eigene Sitzung mit dem Kunden, und jedes Gerät besitzt seine eigenen Zugriffsrichtlinien, die separat und unabhängig ausgeführt werden. Teilnehmende Federation-Mitglieder können bei Bedarf Informationen mit anderen Federation-Mitgliedern außerhalb von Sitzungen austauschen. Eine übliche Konfiguration besteht darin, über ein dediziertes BIG-IP-Gerät als primäres Mitglied zu verfügen, bei dem Benutzer authentifiziert sind, und das Informationen für andere Mitglieder bietet. Dies ermöglicht einer Vielzahl von anderen BIG-IP-Geräten, mit diesem primären Mitglied zusammenzuarbeiten. Das primäre Mitglied dient als Identitätsanbieter, die anderen teilnehmenden Mitglieder als Dienstanbieter. Vorteile Zu den Vorteilen der Bereitstellung von BIG-IP APM als SAML-Lösung gehören sicherlich eine bessere Passwortverwaltung, weniger Helpdesk-Anrufe und ein verbessertes Benutzererlebnis, aber BIG-IP APM kann bei Anfragen auch einen zusätzlichen Zusammenhang hinzufügen. Es können beispielsweise Ergebnisse für Endpunktprüfungen als Attribute enthalten sein, um die Anwendung über den Sicherheitsstatus des Kunden zu informieren. Darüber hinaus müssen IT-Administratoren Anwendungen nicht umändern (z. B. benötigen.NET-Anwendungen kein Kerberos-Claims-Plug-In). Ein weiterer Vorteil ist die umfangreiche Unterstützung von Sitzungsvariablen, die es Organisationen ermöglicht, jede Benutzersitzung anzupassen. BIG-IP APM kann SAML zu Ressourcen und Anwendungen mit minimalen – oder gar keinen – Back-End-Änderungen bringen. All diese Vorteile ergänzen den Wert von BIG-IP APM für das gesamte Trafficmanagement der IT-Infrastruktur einer Organisation. IT-Infrastrukturen haben sich in den letzten Jahren dramatisch verändert, und viele Anwendungen wurden zu Cloud-basierten Diensten übertragen. Angestellte bei Unternehmen haben sich auch zu einer mobilen Belegschaft gewandelt, die jederzeit von überall aus mit jedem Gerät sicheren Zugriff auf diese Infrastruktur benötigt. Das Überbrücken der Identitätskluft zwischen physikalisch und logisch getrennten Diensten ermöglicht es Organisationen, in dieser sich ständig wandelnden Umgebung flexibel zu bleiben, und verleiht Benutzern den sicheren Zugriff, den sie rund um die Uhr benötigen. BIG-IP APM Version 11.3 bietet neben der Bereitstellung einer hohen Verfügbarkeit und dem Schutz wichtiger Geräte von Organisationen auch eine SAML 2.0-Lösung, die den notwendigen Identitätsübergang zur Verwaltung des Zugriffs in verschiedenen Systemen bereitstellt. Technorati Tags: SAML,APMInterview zum Thema Marktentwicklung PCs vs. Tablets mit Ralf Sydekum
Ralf Sydekum, Manager Field Systems Engineering erklärt in einem Interview auf www.sysbus.eu, was die letzten Marktzahlen besagen, warum die Verkäufe von PCs immer mehr in den Keller gehen, während gleichzeitig die Verkaufszahlen im Tablet-Bereich – vor allem bei den Android-Tablets – neue Rekordmarken erreichen. Welche Auswirkungen hat dieser Trend auf Unternehmensumgebungen?” Das komplette Interview finden Sie hier.
