Tech Preview: Citrix App Delivery and Security Service mit AWS

Citrix hat bereits im September angekündigt einen App Delivery Service zu implementieren, auf dem Field Kickoff wurde der Service gleich an prominenter Stelle (in der Keynote) mehrmals erwähnt, es ist also vielleicht an der Zeit sich den Service einmal anzusehen. Seit dem Field Kickoff besteht die Möglichkeit sich über den Citrix Cloud Service Zugang (cloud.com) für ein Tech Preview freischalten zu lassen. Momentan kann der Service nur Amazon Web Services (AWS) Datenströme verarbeiten, somit wird derzeit zwingend ein AWS Konto zur Verknüpfung benötigt, später soll der Service aber auch MS Azure Datenströme bereitstellen können.

Neue Kachel im Citrix Cloud Service (bereits freigeschalteter Preview läuft hier noch 52 Tage)

Citrix hängt die Latte für den App Delivery and Security Service (ADS) ganz schön hoch, er soll Intent-based sein, Always Learning, Always Adapting und Always Protecting (vergl. Introducing intent-based Citrix App Delivery and Security Service | Citrix Blogs).

Die „Intent based“ Konfiguration stellt eine Art Wizard dar, der die Konfiguration stark vereinfacht ermöglicht. Des weiteren soll der Service kontinuierlich den Netzwerkstatus des Internets monitoren und lernen und so eine End-to-End Experience Map erstellen können. Über die Netzwerkmessungen wird erstmals ein „internet-state aware GSLB“ implementiert schreibt Citrix (vergl. Whitepaper Citrix App Delivery and Security Service, A paradigm shift for IT modernization, Seite 9). Der Service soll weiter fehlerhafte Applikationsserver aus dem Load Balancing entfernen können und durch den Rollout weiterer ADC Ressourcen im Hintergrund in die breite Skalieren können. In der Intent based Konfiguration lassen sich an vielen Stellen wenig Details konfigurieren bzw. es sind nicht alle ADC Funktionen direkt nutzbar, andere wiederum werden im Hintergrund automatisch konfiguriert wie z.B. die SSL Settings, welche vom Service optimiert werden. Die WAF kann momentan manuell eingeschaltet und konfiguriert werden.

Nach der Freischaltung des Services wird dieser mit AWS verknüpft und ermöglicht dann eine Konfiguration, welche auf Knopfdruck in das AWS und die ADS Elemente ausgerollt (deployed) wird. Es wird im Startbildschirm nach Application oder Multi-Site Application unterschieden, welches die Unterscheidung zwischen Loadbalancer/ Content Switching Geschäft und DNS basiertem GSLB (bzw. etwas vergleichbarem) darstellt.

Als ich mit meinen Tests begann, lies der Menüpunkt „Deliver an Application“ (welcher die Intent based Konfiguration startet) noch zu auf einen Classic Modus umzuschalten, welcher alternativ ADC-like zu bedienen war. Allerdings mussten die Objekte hier ohne Erklärung manuell erzeugt werden und über die Eintragung in Freitextfelder verknüpft werden. Diese noch nicht ganz fertige Funktion wurde im Laufe meiner Tests ausgeblendet. Auch gab es am Anfang die Möglichkeit eine ADC Konfiguration zu laden, dort einzelne Virtual Server auszuwählen, zu extrahieren und übernehmen zu können. Diese Funktion war aber nur in der Lage einfache Konfigurationen übernehmen zu können, bei komplexeren Konfigurationen gab es Fehler beim Parsing. Die im Folgenden zu sehenden Screenshots stammen daher von der Intent based „Modern“ Konfigurationsmöglichkeit.

Erstellen Cloud Access Profile

Zuerst muss die Anbindung der Citrix Cloud Services an die AWS-Plattform erfolgen, dies geschieht über ein Cloud Acsess Profile. Dafür muss ein Skript im AWS ausgeführt werden, welches einen Cloud Formation Stack erzeugt und auch die entsprechenden Berechtigungen im AWS setzt.

Screenshot von der Validation bzw. Update des Stacks / JSON Vorlage

Der obige Screenshot ist von der Validation eines Cloud Formation Stacks, bei der Erstausführung ist ganz unten noch ein Feld eingeblendet, in das der durch AWS zurückgegebene RoleARN eingetragen werden muss. In diesem Dialog muss der obige JSON Code kopiert werden oder die Datei über den Link „Download“ heruntergeladen werden.

Erstellen des Stacks über eine Vorlagendatei (die zuvor gespeicherte JSON Datei)

Der gerade erstellte Stack muss geöffnet werden um den RoleARN anzuzeigen, welcher in den Citrix Dialog eingefügt werden muss.

Der oben genannte RoleARN aus der Job Ausgabe wird kopiert und in die Citrix Console eingefügt. Danach kann das Cloud Environment erzeugt werden.

Erzeugen Cloud Environment

Ein Cloud Environment ist ein Bereich in den der Citrix Service Deployed werden kann. In ihm sind die Region, Availability Zones und die zu benutzende Virtual Private Cloud definiert.

Danach kann das Deployment des Environments erfolgen. Mit dem „View More Details“ Schalter in der Mitte wird die Ausgabe detaillierter und lässt erahnen, was Citrix mit der Role im AWS erzeugt.

Erzeugte Objekte im AWS / Citrix geht „Xlarge“ einkaufen

Es werden pro Availability Zone zwei m5.xlarge Instances erzeugt

Dazu kommen noch NAT Gateways und Elastic IPs

Achtung: In unserer Testumgebung haben die von Citrix erzeugten Objekte mindestens 6$ pro Tag gekostet (realistisch für 24 Stunden eher 16$) und im ausgeschalteten Zustand noch etwa 3$, da die NAT Gateways pro Stunde abgerechnet werden (vergl. Logisch isolierte virtuelle private Cloud – Amazon VPC Preise – Amazon Web Services)!

Einrichten einer Testapplikation (LAMP)

Als Backend für die Testapplikation wurde eine Linux Maschine mit LAMP Stack ausgerollt als t3.micro Instanz (diese sind im kostenlosen Kontingent enthalten; vergl. Limits des kostenlosen Kontingents für AWS – AWS-Fakturierung (amazon.com)).

Die Möglichkeiten in der Intent based Konfiguration liegen weit hinter dem was der darunterliegende ADC kann.

Testlamp Application 5 / Beispiel Responder

Auch beim Responder kann derzeit nur ein Subset genutzt werden von dem, was der ADC eigentlich ermöglicht. Mangels der Möglichkeit mit einer Webseite zu antworten, haben wir im Test einen Error zurückgegeben.

Testlamp Application 6 / Leere WAF Konfiguration

Testlamp Application 7 / Laufende Applikation

Unterstützte Features

Feature	Citrix App Delivery and Security service Advanced	Citrix App Delivery and Security service premium
SSL/Load balancing/content switching	Yes	Yes
Content rules	Yes	Yes
Authentication	Yes	Yes
GSLB	Yes	Yes
Caching and compression	Yes	Yes
Analytics	Yes	Yes
Lifecycle management	Yes	Yes
ITM based GSLB	Yes	Yes
Security (WAF, BOT management)	No	Yes
ICA Proxy	No	No
Gateway SSL VPN	No	No

Tabelle der derzeit unterstützten Features lt. Hersteller

Abrechnung / Entitlements

Der obige Screen zeigt die Möglichkeit die Trafficnutzung nach Art der genutzten Bandbreite (Premium Bandbreite = Premium Features wie z.B. WAF) anzeigen zu können. Im SaaS Model wird Bandbreite von zuvor abgeschlossenen Entitlements genutzt werden.

Entitlement type	Deployment type
Standalone entitlements	Citrix App Delivery and Security Service – Citrix Managed
Trial entitlements	Citrix App Delivery and Security Service – Citrix Managed
Pooled SaaS Bundle entitlements	Citrix App Delivery and Security Service – Citrix Managed

Entitlements

Edition type	Entitled to
Advanced	300 TB bandwidth + 25 million DNS queries
Advanced	1200 TB bandwidth + 100 million DNS queries
Advanced	4800 TB bandwidth + 500 million DNS queries
Advanced	2000 TB bandwidth + 2 billion DNS queries
Premium	300 TB bandwidth + 25 million DNS queries
Premium	1200 TB bandwidth + 100 million DNS queries.
Premium	4800 TB bandwidth + 500 million DNS queries
Premium	2000 TB bandwidth + 2 billion DNS queries

Entitlements / Pakete

Es wird voraussichtlich auch zusätzliche DNS Pakete geben.

Quelle und mehr Informationen: Entitlements | Citrix App Delivery and Security service

Fazit

Der Service bietet einen interessanten Ansatz, da die darunterliegende Infrastruktur von Citrix betrieben und somit auch geupdatet wird. Momentan ist das Feature Set noch recht klein, wenn dieses aber für die Intent Based Konfiguration erweitert wird und die weiteren Möglichkeiten wie die Classic Konfiguration oder der Import von „ns.conf“ Kommandos wieder dazukommen (aktuell nicht oder zumindest nicht mehr in meinem Tech Preview), könnte sich eine interessante Alternative zum Aufbau kompletter Instanzen im AWS oder Azure ergeben.

Zu den Möglichkeiten des Einsatzes eines Citrix ADC in einer Cloud Umgebung sprechen sie uns gerne an, wir zeigen ihnen die unterschiedlichen technischen Möglichkeiten der Realisierung und erklären ihnen die Unterschiede in der kaufmännischen Abbildung mit dem neuen Citrix ADS Service, ihren vorhanden Lizenzen, den Subscriptions wie Pooled Licensing oder auch unserem eigenen sehr flexiblem ADCaaS Produkt.

Links ADS Service:

Introducing intent-based Citrix App Delivery and Security Service | Citrix Blogs

App Delivery and Security Service – Citrix Germany

Citrix App Delivery and Security Service, A paradigm shift for IT modernization

Entitlements | Citrix App Delivery and Security service

Links zu AWS:

Limits des kostenlosen Kontingents für AWS – AWS-Fakturierung (amazon.com)

Logisch isolierte virtuelle private Cloud – Amazon VPC Preise – Amazon Web Services

27. Oktober 20212. November 2021

How To: Performanceanalysen

Möglicherweise kennt man noch die Sanduhr, den Ladebalken oder einfach eingefrorene Sitzungen in Citrix- oder Microsoft-RDP-Umgebungen. Das muss aber nicht sein. Lange Ladezeiten und hohe Latenzen bei der Datenübertragung können Anzeichen für ein unperformantes Netzwerk sein. Der Grund dafür muss nicht immer an einer zu hohen Auslastung der Hardware liegen. Von verschmutzten Lichtwellenleitern, gebrochenen Kupferkabeln zu Netzwerkloops über falsch konfigurierte Routen bis hin zum unbemerkten Ausfall einzelner Komponenten ist alles dabei. Auch Unstimmigkeiten im Verhalten der Virtualisierungs-Umgebung auf Basis von VMware vSphere oder Microsofts HyperV sowie Engpässen im SAN oder an zentralen / dezentralen Speichersystemen können so lokalisiert, eingegrenzt und entschärft werden. Um diesem meist unübersichtlichen, ggf. langwierigen Troubleshooting eine Struktur zu geben, hat sich bei der michael wessel ein Standardvorgehen etabliert. Davon profitieren Sie als Auftraggeber vor allem durch Struktur, Transparenz und eine Vergleichbarkeit der Ergebnisse.

Wer nicht neugierig ist, erfährt nichts.
Johann Wolfgang von Goethe

Ablauf einer Performanceanalyse

Wie läuft so etwas ab? Um unnötige Aufwände zu vermeiden, wird sich zuerst auf die bestehende Dokumentation und die problembehaftete Verbindung konzentriert. Daraus und ggf. weiterer Hintergrundrecherche werden gemeinsam individuelle Testszenarien aufgestellt und eine Abgrenzung zu angrenzenden Themen geschaffen, um im gesamten Vorgehen durchgehende Transparenz gewährleisten zu können.

Wir messen im Anschluss die Performance Ihres Netzwerkes und analysieren die Gegebenheiten, um Ihnen im Nachgang eine fundierte Handlungsempfehlung vorzustellen. Die Handlungsempfehlung erhalten Sie, begleitet durch Erläuterung im Abschlussgespräch, in digitaler Form.

Definieren von Testszenarien

Gemeinsam definieren wir Strecken, auf welchen die Performance spürbar eingeschränkt ist oder auf der es zu sporadischen Leistungseinbrüchen kommt. Diese Strecken werden in einem Aufnahmegespräch immer weiter analysiert, die eingesetzten Anwendungen und deren Eigenheiten bedacht und in einem Testszenario oder sofern zielführend mehreren Testszenarien zum Schaffen einer Vergleichbarkeit zusammengefasst.

Schaffen von Abgrenzungen

Wer einen klaren Blick auf die eigentliche technische Herausforderung benötigt, muss Inhalte und Verhaltensweisen abgrenzen können. Deshalb ist die Abgrenzung von technischen wie inhaltlichen Themen fester Bestandteil des Analyseprozesses. Man kennt es aus der Tierwelt – ein Turmfalke im Anflug auf die Beute zählt auch nicht die Wolken und Blätter an den Bäumen um ihn herum, er fokussiert seine Beute, blendet alles irrelevante aus, schärft seine Sinne. Nur, dass in diesem Fall die Infrastruktur fokussiert wird.

Transparenz im Vorgehen

Im Fokus der Analyse steht die Transparenz der geplanten Szenarien und eingesetzten Tools. Diese werden gemeinsam abgestimmt und zur Bestätigung von beiden Seiten vor Beginn jeder Messung oder eines Belastungstests unterzeichnet. Somit wird eine detaillierte Analyse nicht zum allumfassenden Infrastruktur-Review, sondern bleibt fokussiert. Wie der Turmfalke auf der Jagd. Jederzeit nachvollziehbar, mit höchster Konzentration.

Durchführung der Performance-Messung

Im Anschluss der Definition von Testszenarien und der eindeutigen Abgrenzung wird die Performance-Messung selbst durchgeführt. Im Idealfall kann anhand der gewonnenen Daten bereits jetzt eingegrenzt werden, an welcher Stelle im Netzwerk sich der Flaschenhals befindet. Sollte die Messung noch nicht zielführend gewesen sein, können zusätzlich weitere Auswertungen zu Statistiken, Logs und weiteren Parametern stattfinden. In diesem Zuge werden auch Konfigurationsunstimmigkeiten und weitere Möglichkeiten zur Performance-Optimierung aufgedeckt. Dies bedeutet meist einen deutlich geringen Aufwand im Vergleich zu einer möglicherweise nicht notwendigen Neuanschaffung der Hardware und schafft zusätzliche Transparenz im eigenen Netz, was wiederum künftiges Troubleshooting erheblich vereinfacht.

*Nach Definition von Testszenarien beginnt die eigentliche Messdatengewinnung zur tiefergehenden Analyse*

Auswertung der Ergebnisse

Die Auswertung der gesammelten Ergebnisse wird im Nachgang durchgeführt. Um falsche Schlussfolgerungen aufgrund eines ungewöhnlichen Verhaltens vorzubeugen, werden mehrere Fachkollegen mit einbezogen. Die Erstellung der aufbereiteten Handlungsempfehlung erfolgt stets mindestens im Vier-Augen-Prinzip und wird erst nach Review zur Veröffentlichung freigegeben.

Handlungsempfehlung und Abschlussgespräch

Daraus ergibt sich eine Handlungsempfehlung, die zum Abschluss gemeinsam besprochen wird und wo konkrete Möglichkeiten zur Verbesserung aufgezeigt werden. Oftmals bewirken schon geringe Konfigurations- oder Designänderungen die ersten spürbaren Verbesserungen, auch der Tausch von Kabeln und Transceivern kann manchmal wahre Wunder wirken.

*Nur eine nachvollziehbare Handlungsempfehlung ist eine gute Handlungsempfehlung. Darum besprechen wir die Ergebnisse und die daraus abgeleiteten Empfehlungen ausführlich mit Ihnen.*

Ein möglicher Handlungsschritt bei z.B: unnötig großen Netzen wäre unter anderem die Minimierung von Broadcastdomänen. Auch ein verlässliches Spanning-Tree-Konzept sowie dessen Umsetzung können die Netzwerkperformance und -stabilität erhöhen. Des Weiteren kann durch die Optimierung einzelner Verbindungen und das auflösen von Netzwerkkaskaden die Produktivität in Ihrem Unternehmen gesteigert werden.

Bei Bedarf kann neben dem Netzwerk auch die Server- und Storage-Performance, sogar Wireless-Infrastrukturen geprüft werden. Für die Analyse von drahtlosen Infrastrukturen liegt aufgrund der hohen Komplexität der möglichen Störquellen genormtes Testequipment und ungeahntes, im Kopf schlummerndes Know How unserer Wireless-Experten parat. Weitere Informationen zu WLAN-Ausleuchtungen finden Sie hier.

… und dann?

In möglichen Folgeprojekten können Sie natürlich auch auf unsere Expertise setzen. Von punktuellem Troubleshooting in der Tiefe, der Durchführung von Infrastrukturmodernisierungen oder der Entwicklung einer Cloud- oder einer Digitalstrategie bietet sich ein weites Themen-Spektrum bei fachlicher Tiefe im Hause der michael wessel. Sie beherrschen Ihr Business, wir unseres.

15. Juli 202115. Juli 2021

Aruba AOS-CX: Patches für mehrere Schwachstellen veröffentlicht

Der Hersteller HPE hat für die Produkte der Aruba-Sparte Mitte dieser Woche mehrere Updates für kabelgebundene Switch-Produkte mit AOS-CX veröffentlicht. Diese schließen mehrere Sicherheitslücken. Wir haben Ihnen hier die Wichtigsten Informationen zusammengefasst.

Um welche Sicherheitslücken handelt es sich?

In den Patches werden insgesamt vier Schwachstellen betitelt.

SAD DNS Vulnerability (CVE-2020-25705)
Remote Code Execution Via External Storage (CVE-2021-29143)
PHY Firmware Local Bypass Security Restrictions (CVE-2021-29149)
Path-relative Stylesheet Import (PRSSI) (CVE-2021-29148)

Bei der Schwachstelle SAD handelt es sich um einen Bug, der sich auf die Art und Weise, wie Antworten von ICMP-Paketen im Linux-Kernel behandelt werden. Dieser kann ausgenutzt werden um ein sogenanntes DNS Cache-Poisoning durchzuführen. Dabei kann eine Domain (zb. www.google.de) auf eine andere IP-Adresse weitergeleitet werden und ermöglicht potentiellen Angreifern so, bekannte Domains auf selbst erstellte oder kompromittierte Sites weiterzuleiten.

Für die zweite und dritte Sicherheitslücke werden administrative Zugangsdaten benötigt, weshalb diese hier nicht weiter erläutert werden.

Die letzte PRSSI-Schwachstelle bezieht sich auf eine Schwachstelle in der Web-GUI der Geräte. Aufgrund der Konfiguration der webbasierten Verwaltungsoberfläche können relative URLs innerhalb von HTML-Seiten das falsche Ziel weitergeben. Dadurch wird möglicherweise die angezeigte Benutzeroberfläche (UI) verändert und man könnte auf bösartige Webseiten geleitet werden.

Sind die Geräte in meinem Unternehmen betroffen?

Die Switche aus der Aruba 8400/8360/8325/8320 und Aruba 6400/6300/6200F Serie mit den unten stehenden Firmware-Ständen sollten umgehend auf einen aktuellsten Stand gebracht werden.

Betroffene Firmware Versionen von AOS-CX:

10.04.xxxx – Versionen vor 10.04.3070
10.05.xxxx – Versionen vor 10.05.0070
10.06.xxxx – Versionen vor 10.06.0110
10.07.xxxx – Versionen vor 10.07.0001

Was kann ich tun wenn ich betroffen bin?

Schnellstmöglich sollte auf eine aktuelle Firmware Version aktualisiert werden. Die Versionen, welche entsprechende Fixes mit sich bringen sind:

10.05.0070 und höher
10.06.0110 und höher
10.07.0001 und höher

Achtung!

Betroffene Aruba-Produkte mit einer 10.04.xxxx Firmware Version müssen auf 10.05.0070 aktualisiert werden, um alle Schwachstellen zu beheben.

Benötigen Sie Unterstützung bei der Prüfung oder Umsetzung der Firmware-Updates? Ist Ihre Umgebung nicht mehr leistungsstark genug oder sind einfach Ihre Anforderungen gewachsen? Sprechen Sie uns an, wir helfen Ihnen gerne.

Weitere Informationen zu den Sicherheitslücken finden Sie auf der Herstellerseite unter:

https://www.arubanetworks.com/support-services/security-bulletins/

7. Juni 20219. Juni 2021

Citrix ADC/ Netscaler Full-VPN mit Client Choices

Neben der Nutzung des ADC als Load Balancer und Content Switch oder Gateway für Virtual Apps and Desktops, bietet die Lösung auch die Möglichkeit echtes SSL VPN zu implementieren.

Falls ein bestehender Gateway Virtual Server konfiguriert ist, kann dieser mit wenigen Schritten oft um ein wahlweises SSL VPN erweitert werden.

Voraussetzungen

Netscaler Gateway Virtual Server muss im Smart Access Modus sein („IcaOnly = false“)
Es müssen ausreichend Universal Licenses vorhanden sein, für alle Verbindungen zu diesem Gateway Virtual Server

Einbau in ein bestehendes Gateway

Am einfachsten lässt sich das Full-VPN in ein bestehendes Gateway implementieren, wenn man über eine Gruppenmitgliedschaft einem teil der Benutzer die selektive Auswahl des Full VPN als Alternative zum Virtual Apps and Desktops anbiete. Hierzu gibt es idealerweise in der LDAP Policy des Gateways eine funktionierende Group Extraction. Der ADC wird dann beim Login eines Benutzers versuchen LDAP Gruppenmitgliedschaften auf ADC Gruppenmitgliedschaften (hier: CitrixFullVPN) zu übersetzen.

add aaa group CitrixFullVPN

An diese Gruppe können wir nun den gewünschten Client IP-Bereich für das VPN binden und eine entsprechende Policy, welche die Benutzerauswahl („-Client Choices ON“) einblendet und die VPN Funktion zusätzlich konfiguriert:

add vpn sessionAction AC_VPN -splitDns REMOTE -splitTunnel OFF -transparentInterception ON -defaultAuthorizationAction ALLOW -SSO ON -ssoCredential PRIMARY -icaProxy OFF -wihome "https://store.mycompany.de/Citrix/StoreWeb" -ClientChoices ON -ntDomain mycompany -clientlessVpnMode OFF -iconWithReceiver OFF
add vpn sessionPolicy PL_VPN-classic ns_true AC_VPN
bind aaa group CitrixFullVPN -intranetIP 192.168.1.0 255.255.255.0
bind aaa group CitrixFullVPN -policy PL_VPN-classic -priority 100

Bei der Konfiguration kann über die Parameter „-splitTunnel“ und „-splitDns“ angegeben werden, ob der komplette Traffic in den Tunnel geleitet werden soll oder nur ein Teil des Traffics. Eine ähnliche Konfiguration ist für DNS möglich. Im obigen Beispiel, wird der komplette Traffic nach dem VPN Verbindungsaufbau in den Tunnel geleitet und DNS Remote, also über den Netscaler abgewickelt.

Routing

Es ist theoretisch möglich die Full VPN Funktionalität ohne einen zusätzlichen Adressbereich zu nutzen, der Netscaler lässt dann alle Clients per Übersetzungstabelle über die SNIP kommunizieren. In der Praxis hat sich gezeigt, das einige Backendsysteme damit nicht klarkommen und der Traffic außerdem in einer Firewall selektiver behandelt werden kann, wenn ein zusätzlicher Adressbereich genutzt wird. Zu diesem Adressbereich wiederum wird dann über die bestehende SNIP des Netscalers geroutet. Es ist also auf einer zentralen Firewall oder einem Gateway eine Route analog dem folgenden Beispiel zu konfigurieren:

route add 192.168.1.0 255.255.255.0 <NetscalerSNIP>

Benutzeransicht

Weitere Möglichkeiten

Das Netscaler Gateway Plugin beherrscht neben den klassischen primären und sekundären Faktoren auch die Anzeige der Netscaler NFactor Faktoren/ eines Flows im Plugin und kann somit auch damit kombiniert werden.

Die Verbindungen innerhalb des VPNs können mittels Authorization Policies pro Benutzer oder Gruppe eingeschränkt werden.

Citrix Dokumentation:

Full VPN setup on Citrix Gateway

18. Mai 202118. Mai 2021

WLAN-Sicherheitslücke Fragattack

Vor wenigen Tagen hat der IT-Sicherheitsexperte Mathy Vanhoef eine Vielzahl an Sicherheitslücken in den WLAN-Standards der IEEE aufgedeckt. Laut Vanhoef sind vermutlich nahezu alle WLAN-Geräte mindestens von einer dieser Sicherheitslücken betroffen. Er selbst hat die Schwachstellen an 75 unterschiedlichen Geräten getestet. Zusammengefasst werden sie unter dem Begriff Fragattack. Dieser hat seinen Ursprung in der Funktionsweise der Angriffe bzw. des hier missbräuchlich ausgenutzten Kommunikationsverfahrens im IEEE 802.11-Standard, dem Fragmentieren der Anfragen.

Funktionsweise und betroffene Geräte

Die Sicherheitslücken betreffen alle WLAN-Sicherheitsstandards einschließlich des relativ jungen WPA3-Standards. Ermöglicht werden diese Exploits durch die Funktionsweise von WPA:

Anfragen können in mehrere Datenpakete aufgeteilt (fragmentiert) und dann beim Empfänger wieder zusammengefügt werden. Dieses Protokoll-Design ermöglicht es Hackern, manipulierte Authentifizierungsanfragen an das Netzwerk zu stellen.
Dabei entspricht nur das erste Paket einer echten Anfrage, während die darauffolgenden Pakete manipulierte Daten enthalten. Bei dem Zusammenbau dieser Datenpakete erkennt das Netzwerk die Zugehörigkeit dieser Teilpakete. Dadurch kann ein Angreifer ohne Kenntnis des WLAN-Passwortes oder Entschlüsselung manipulierte Daten in das Netzwerk schleusen.
Diese manipulierte Daten können dann eingesetzt werden, um beispielsweise Ports für versteckte externe Verbindungen zu öffnen oder unverschlüsselten Datenverkehr abzufangen bzw. zu manipulieren.

Vanhoef hat vor der öffentlichen Enthüllung dieser Designschwäche mit Hardwareentwicklern neun Monate im Voraus zusammengearbeitet, um diese Exploits zu beheben. Die daraus resultierende Patches sollen die Sicherheitslücken beheben, einige sind bereits seit März veröffentlicht. Problematisch sind jedoch die Netzwerkteilnehmer, die keine bzw. nur sporadische Sicherheitsupdates bekommen, wie etwa IoT-Geräte (z.B. Smart-Home Geräte). Die Hersteller raten zu einer kurzfristigen Aktualisierung der Firmware aller Geräte. Zudem sollte möglichst unverschlüsselter Datenverkehr in WLAN-Netzen vermieden oder administrativ unterbunden werden, sofern möglich.

Pikant ist zudem, dass gleichermaßen PSK/SAE- wie auch Enterprise-Authentifizierung der Geräte von den Schwachstellen betroffen sind. Viele sonst bekanntgewordene Schwachstellen im WLAN-Umfeld betrafen meist die eher unsicheren PSK-/SAE-Authentfiizierung über einen gemeinsamen Netzwerkschlüssel aller mit dem WLAN verbundenen Geräte, wie man es von zuhause kennt. Im Fall dieser Schwachstelle schützt die Authentifizierung via IEEE 802.1x daher Geräte nicht erheblich besser, als in vielen anderen Fällen.

Weiterführende Informationen zur Funktionsweise finden sich auf der von Vanhoef veröffentlichen Website (https://www.fragattacks.com/) und vor allem in einer seiner Präsentationen (Siehe Link), wo die Schwachstellen genau aufgezeigt werden.

Wie kam es dazu?

Im IEEE-Standard 802.11 (Abschnitt 10.6) ist das Fragmentieren der Anfragen beschrieben. Es wird nicht vor der Manipulation gewarnt und eine Konformität erfordert keine Überprüfung der erneut zusammengesetzten Pakete nach der Übertragung von Fragmenten.

"If security encapsulation has been applied to the fragment, it shall be deencapsulated and decrypted before the fragment is used for defragmentation of the MSDU or MMPDU."

CVE-Codes & BSI-Mitteilungen zu FragAttacks

Das BSI hat eine Warnung zu der Schwachstelle veröffentlicht, die hier (Link zur BSI-Warnung) abgerufen werden kann.

Liste der CVE-Codes zu FragAttacks:

CVE-2020-24588: Aggregation attack (accepting non-SPP A-MSDU frames)
CVE-2020-24587: Mixed key attack (reassembling fragments encrypted under different keys)
CVE-2020-24586: Fragment cache attack (not clearing fragments from memory when (re)connecting to a network)
CVE-2020-26145: Accepting plaintext broadcast fragments as full frames (in an encrypted network)
CVE-2020-26144: Accepting plaintext A-MSDU frames that start with an RFC1042 header with EtherType EAPOL (in an encrypted network)
CVE-2020-26140: Accepting plaintext data frames in a protected network
CVE-2020-26143: Accepting fragmented plaintext data frames in a protected network
CVE-2020-26139: Forwarding EAPOL frames even though the sender is not yet authenticated (should only affect APs)
CVE-2020-26146: Reassembling encrypted fragments with non-consecutive packet numbers
CVE-2020-26147: Reassembling mixed encrypted/plaintext fragments
CVE-2020-26142: Processing fragmented frames as full frames
CVE-2020-26141: Not verifying the TKIP MIC of fragmented frames

Was kann ich tun, um meine Geräte zu schützen?

In erster Linie sollte man sich ein paar Grundsätze wieder bewusst machen und zur Gewohnheit machen:

Regelmäßige Software- und Firmwareupdates auf allen Geräten einspielen.
Wo möglich aus Gründen der Sicherheit und Stabilität das Patchkabel dem WLAN bei sicherheitskritischer Kommunikation vorziehen.
Möglichst auf verschlüsselte Kommunikation achten (https:// in der Browserzeile). Hilfreich ist hier auch das Browserplugin https-everywhere (siehe Link) , was jede Browserkommunikation zu verschlüsseltem https zwingt.

Sollten Sie Unterstützung bei der Aktualisierung Ihrer Geräte benötigen, oder eine Überprüfung auf die Schwachstelle wünschen, wenden SIe sich gerne vertrauensvoll an uns.

25. September 20191. April 2021

Neueröffnung des HPE Pointnext Education Services vLABs-Centers

Unser Fokus-Partner Hewlett Packard Enterprise eröffnete das innovative Training & vLabs Center auf etwa 900 Quadratmeter am deutschen Hauptstandort in Böblingen. Die michael wessel wurde dabei vor Ort aus dem Consulting durch David Yoel Wandschneider sowie unseren Teamleiter des Teams Datacenter Infrastructure, Daniel Lengies, vertreten. Im Dialog konnte die Zusammenarbeit partnerschaftlich gestärkt werden, Gespräche und Präsentationen lieferten einige – teils neue, teils bereits von uns in unseren Services enthaltenen Aspekte in der Weiterentwicklung IT-gestützter Prozesse und der chancenreichen Digitalisierung.

Wir haben im Folgenden unsere Eindrücke aus den Bereichen Technoligieentwicklung, Mobility, IoT und VR-Guidance, sowie Prozessoptimierung und Mitarbeiterawareness zusammengefasst.

13. September 201918. September 2019

Ein neuer Certified Ethical Hacker bei michael wessel

Unser Kollege und Leiter des Teams Datacenter Infrastructure, Daniel Lengies, hat nun seine Zertifizierung zum Certified Ethical Hacker (EC Council) bestanden. Diese beinhalteten umfangreiche Schulungsmaßnahmen mit hohen Praxisanteilen. Darüber hinaus musste er viele Kenntnisse über Sicherheitssystemtechniken beweisen. Darunter auch solcher Techniken, die Gegenmaßnahmen gegen Hackingangriffe enthalten.

9. September 201911. September 2019

Nils Kaczenski auf der Storage2Day 2019

Nächste Woche vom 17.-19. September findet die Storage2Day in Heidelberg statt. Die Konferenz für Speichernetze und Datenmanagement.

6. September 201918. September 2019

WLAN-Infrastruktur Setup in wenigen Minuten?

Sicheres WLAN für Ihre Endgeräte
Indoor und Outdoor-fähige Access Points
Einfache Verwaltung per App

Kunden oder Gäste fragen Sie immer wieder nach einem WLAN-Zugang, den Sie bisher nicht anbieten konnten?

Sie haben das Thema WLAN bisher vermieden, weil virtuelle Netzwerke, IP-Adressen und Subnetzmasken Fremdwörter für Sie sind? Sie haben die hohen Aufwände für Installation und Betrieb einer performanten WLAN-Infrastruktur gescheut? Ihre IT besteht nur aus Ihnen und Sie müssen die gesamte Infrastruktur betreiben? Fühlen Sie sich angesprochen, sollten Sie diesen Blogpost nun mit erhöhter Aufmerksamkeit lesen!

Pages: 1 2

24. April 201925. April 2019

W-LAN wird mit IEEE802.11ax (WiFi6) endlich effizienter

Was bringt der neue Standard und wann lohnt ein Umstieg?

Der IEEE-Standard 802.11ax wurde von der WIFI-Alliance mit dem Titel WIFI6 versehen, da es sich um die sechste Generation WLAN handelt, die damit ausgerufen worden ist. Es soll damit vorwiegend im Consumer-Bereich eine einfachere Unterscheidung der WLAN-Generationen herbeigeführt werden. Während man mit der vorherigen Generation in voller Ausbaustufe (IEEE 802.11ac WAVE2) bereits das theoretisch physikalische Maximum an Bandbreite ausgereizt hat, orientiert sich der Standard 802.11ax vorwiegend an der Effizienzsteigerung und dem Erhöhen der realistischen Bandbreitenwerte. Die Maximalwerte in Sachen Performance sind stets orientiert an einem Optimum, was Entfernung Signaldämpfung und Empfangsgerät betreffen, was leider nie der Realität entspricht. Um das Brutto-Netto-Verhältnis, also die effektive Durchsatzausbeute anzuheben, wird im neuen Standard ein neues Verfahren namens OFDMA (Orthogonal Frequency Division Multiple Access) eingesetzt, welches Netzen mit vielen Clients und hoher Dichte eine enorme Steigerung der Effizienz verspricht. An der Performance wurde ebenfalls durch eine komplexere Signalmodulation geschraubt. Es kommt nun 1024-QAM zum Einsatz. Durch die vierfache Modulation konnten auch die theoretischen Datenraten vervierfacht werden.

OFDM vs. OFDMA: Gleichzeitige Verteilung von Zeitslots an mehrere Nutzer statt an einen je Zeitslot. Quelle: https://www.arubanetworks.com/assets/so/ReferenceGuide_80211ax.pdf