ADFS Hardening

Da mit dem Token Signing Zertifikat das SAML Token signiert wird, sollte dafür ein dediziertes Zertifikat eingesetzt werden. Wildcard Zertifikate können technisch zwar eingesetzt werden, aber sind aus dem oben genannten Grund nicht zu empfehlen. Zudem sollte beim Token Signing Zertifikat mindestens der gleiche Standard gesetzt werden wie bei den Webzertifikaten:

• • Lifetime max. 1 Jahr
  • RSA 4096
  • SHA-256

Da bei den Webserver Zertifikaten & den Token Singing Zertfikaten der ADFS Server die gleichen Standards angewendet werden, kann man für die beiden Zwecke auch das gleiche Zertifikat einsetzen. Bei höheren Schutzanforderungen kommt der nächste Absatz zum Tragen.

Microsoft hat den Windows Systemen einen geschützten Bereich für das Hinterlegen von Zertifikaten mit Private Keys gegeben. Dieser Schutz ist Software basiert und daher anfälliger für Angriffe wie Hardware geschützte Speicher. Als Beispiel kann genannt werden, dass jeder lokale Administrator des Systems an das Maschinenzertifikat mit dem Private Key herankommt und entwenden kann. So auch beim ADFS Server. Zum Schutz des Token-Signing Zertifikats kann es auf ein Hardware Security Modul, kurz HSM, ausgelagert werden. Ein HSM ist für den hohen Schutz von Zertifikaten und der Ausführung von kryptographischen Operationen gemacht. Tiefere Einblicke des HSMs ist im Blog-Post meines Kollegen beschrieben: Was ist ein Hardware Security Module. Wenn die sichere Auslagerung des Token-Signing Zertifikates gewünscht ist, sollte sich natürlich das Webserver Zertifikat vom Token Signing Zertifikat unterscheiden. Die Implementierung des HSMs ist herstellerspezifisch. Daher stellen in der Regel die Hersteller Anleitungen zur Verfügung, wie das SAML Token Signing Zertifikat des ADFS Servers zum HSM ausgelagert werden kann.

Wie bei allen Webservern sollte die TLS & Cipher-Suite Auswahl nicht dem Hersteller überlassen werden. Die gezielte Auswahl von TLS Protokollen und Cipher-Suites erhöht die Vertraulichkeit und Integrität der HTTPS Verbindung zum Webserver.

ADFS wurde mit Hilfe von Microsoft .NET Framework entwickelt. Daher sind die TLS Protokolle und Cipher-Suites Steuerung im Microsoft .NET Framework zu finden. SSL, RC4, TLS 1.0 und TLS 1.1 sollten deaktiviert werden. Aktuell (Stand Februar 2021) kann TLS 1.3 für ADFS nicht aktiviert werden. Denn das Windows 10 v21H1 wird die erste Windows Version sein, welche TLS 1.3 unterstützt. Ähnlich wie die Protokolle können auch die Cipher-Suites gesteuert werden.

Wer will, kann zudem seine WAP Server einem SSL Server Test unterziehen lassen. Dieser Online Test (www.ssllabs.com/ssltest/) wird von Qualys angeboten und ist kein Produkt der AVANTEC AG. Er überprüft und bewertet das Web Zertifikat, SSL / TLS Protokolle sowie die verwendeten Cipher-Suites. Zudem werden unterschiedliche Handshakes simuliert. Die zeigen auf, auf welchem System und mit welchem Browser welches Protokoll und Cipher-Suite ausgehandelt wird. Damit kann auch die Abwärtskompatiblität überprüft werden.

Mithilfe der WAP Server kann vom Internet her die Dienstleistung der ADFS Server genutzt werden. Ein Angreifer kann das Ausnutzen und somit die ADFS Server zur Überlast zwingen. Die Mitarbeiter könnten sich dann nicht mehr bei ihren Applikationen, Webseiten und anderen Diensten anmelden. Hier wird einem plötzlich die Abhängigkeit solch zentraler Dienste wie die der ADFS Server bewusst. Um das zu verhindern, bietet der WAP Server einen sogenannten ADFS Überlastschutz an. Dabei untersucht der WAP Server wie viel Zeit der ADFS Server für seine Anfrage benötigt. Wird der Schwellwert überschritten, leitet der WAP Server seine Anfragen von extern nicht mehr weiter.

Eine ähnliche Angriffsmethode soll nicht die ADFS Server zur Überlast zwingen, sondern das AD Benutzer Konto sperren. Für den Benutzer X werden so viele Authentisierungsversuche über die WAP Server durchgeführt, bis das AD Konto gesperrt wird. Um dies zu verhindern, kann eingestellt werden, nach wie vielen Versuchen keine weiteren Anmeldungen mehr über die WAP Server für das entsprechende Konto gemacht werden können. Nicht nur die Anzahl der Authentisierungsversuche, sondern auch die Sperrfrist kann entsprechend eingestellt werden. Bei der Konfiguration des Sperrungsschutzes von Konten sollte die Security Konfiguration vom Active Directory berücksichtigt werden.

Auf dem ADFS Server kann gesteuert werden, dass für externe Benutzer, die sich über die WAP Server anmelden, strengere Authentisierungsrichtlinien gefordert sind, als wenn die Benutzer sich von intern anmelden. Beispielsweise reicht es, wenn der interne Benutzer sich am ADFS Server per Kerberos authentisiert, aber für die Authentisierung über den WAP Server Two Factor Authentication (2FA) notwendig ist. Es kann sein, dass bei den externen Benutzern in diesem Beispiel Smart Card Authentication gefordert ist. Die Unterscheidung kann auch pro Relaying Party Trust also pro Service Provider gemacht werden.

Wie eine sichere Authentisierung in einer Azure Hybrid Umgebung konfiguriert wird, ist im Artikel Azure Hybrid – wie wird sicher authentisiert beschrieben. Da die ADFS Server im Tier-0 sind, sollten diese Server, wie alle anderen Server, nur den notwendigen Risiken ausgesetzt werden. Wenn die Authentisierung über die ADFS Server nur von internen Netzwerken benötigt wird, so kann auf die WAP Infrastruktur verzichtet werden, sodass die ADFS Server nicht vom Internet her erreichbar sind.

Das Härten ist aber nur ein Aspekt. Schliesslich sollte wie bei allen Tier-0 Systemen nicht nur deren Verfügbarkeit, sondern auch die Authentizität von Systemen und Diensten überwacht werden. Ganz nach dem Prinzip: „Vetrauen ist gut, Kontrolle ist besser.“