Freunde, hallo!
Es gibt viele Möglichkeiten, von zu Hause aus auf den Arbeitsplatz im Büro zuzugreifen. Eine davon ist die Verwendung von Microsoft Remote Desktop Gateway. Dies ist RDP über HTTP. Ich möchte hier nicht die Einstellungen des RDGW selbst behandeln, ich werde nicht diskutieren, warum es gut oder schlecht ist, betrachten wir es einfach als eines der Werkzeuge für den Remote-Zugriff. Ich möchte über den Schutz Ihres RDGW-Servers vor dem bösen Internet sprechen. Als ich die RDGW-Server einrichtete, machte ich mir sofort Gedanken über den Schutz, insbesondere über den Schutz vor Passwort-Überprüfungen. Ich war überrascht, dass ich im Internet keine Artikel fand, wie man das machen kann. Na gut, dann muss ich es selbst machen.
An sich hat das RDGW keinen Schutz. Ja, man kann es ungeschützt mit einer einfachen Benutzeroberfläche im offenen Netzwerk betreiben, und es wird gut funktionieren. Aber ein richtiger Administrator oder Sicherheitsexperte wird sich dabei unwohl fühlen. Es wird auch helfen, eine Situation der Kontosperrung zu vermeiden, wenn ein nachlässiger Mitarbeiter das Passwort des Unternehmensaccounts auf seinem Heimcomputer gespeichert hat und dann sein Passwort geändert hat.
Ein guter Weg, interne Ressourcen vor der externen Umgebung zu schützen, sind verschiedene Proxys, Publikationssysteme und andere WAF. Denken wir daran, dass das RDGW letztlich http ist, dann liegt es nahe, eine spezialisierte Lösung zwischen internen Servern und dem Internet zu installieren.
Ich weiß, dass es tolle F5, A10, Netscaler(ADC) gibt. Als Administrator eines dieser Systeme kann ich sagen, dass es auch möglich ist, den Schutz vor Passwort-Überprüfungen auf diesen Systemen einzurichten. Und ja, diese Systeme schützen Sie nebenbei auch vor jedem Syn-Flood.
Aber nicht jede Firma kann es sich leisten, eine solche Lösung zu erwerben (und einen Administrator für ein solches System zu finden :), wobei man sich dabei um die Sicherheit kümmern kann!
Es ist durchaus möglich, eine kostenlose Version von HAProxy auf einem kostenlosen Betriebssystem zu installieren. Ich habe es auf Debian 10 getestet, im stabilen Repository ist die Version haproxy 1.8.19. Ich habe auch die Version 2.0.xx aus dem Testing-Repository überprüft.
Die Einrichtung von Debian selbst lassen wir außerhalb des Artikels. Kurz gesagt: Schalten Sie an der offenen Schnittstelle alles außer Port 443 ab, an der grauen Schnittstelle - gemäß Ihrer Richtlinien, beispielsweise ebenfalls alles außer Port 22. Öffnen Sie nur das, was notwendig ist für den Betrieb (zum Beispiel VRRP für die Floating IP).
Zunächst habe ich HAProxy im SSL-Bridge-Modus (auch bekannt als HTTP-Modus) konfiguriert und das Logging aktiviert, um zu sehen, was im RDP vor sich geht. Sozusagen bin ich mittendrin eingestiegen. Dabei fehlt der in „allen“ Artikeln zur Konfiguration des RDGateways angegebene Pfad /RDWeb. Alles, was vorhanden ist, sind /rpc/rpcproxy.dll und /remoteDesktopGateway/. Standard-GET/POST-Anfragen werden dabei nicht verwendet; es wird ein eigener Anfrage-Typ RDG_IN_DATA, RDG_OUT_DATA genutzt.
Nicht viel, aber besser als nichts.
Lass uns testen.
Ich starte mstsc, gehe zum Server und sehe in den Logs vier Fehler 401 (unauthorized). Dann gebe ich Benutzernamen/Passwort ein und erhalte die Antwort 200.
Ich schalte ab, starte neu und sehe in den Logs wieder die gleichen vier Fehler 401. Ich gebe falsche Benutzernamen/Passwort ein und sehe erneut vier Fehler 401. Das ist genau, was wir brauchen. Das werden wir aufzeichnen.
Da es mir nicht gelungen ist, die Login-URL zu bestimmen, und ich außerdem nicht weiß, wie man in HAProxy speziell den Fehler 401 aufzeichnen kann, werde ich alle 4xx-Fehler aufzeichnen (tatsächlich nicht aufzeichnen, sondern zählen). Das ist auch in Ordnung für die Lösung des Problems.
Der Schutz wird darin bestehen, dass wir die Anzahl der 4xx-Fehler (im Backend) über einen bestimmten Zeitraum zählen und wenn sie den angegebenen Grenzwert überschreitet, alle weiteren Verbindungen von dieser IP für die angegebene Zeit ablehnen (im Frontend).
Technisch gesehen wird dies kein Schutz gegen das Brute-Forcing von Passwörtern sein, sondern ein Schutz vor 4xx-Fehlern. Wenn man beispielsweise häufig eine nicht existierende URL (404) anfordert, wird auch dieser Schutz aktiv.
Die einfachste und funktionierende Methode ist es, im Backend zu zählen und zu blockieren, wenn etwas Überflüssiges auftritt:
frontend fe_rdp_tsc
bind *:443 ssl crt /etc/haproxy/cert/desktop.example.com.pem
mode http
...
default_backend be_rdp_tsc
backend be_rdp_tsc
...
mode http
...
# Tabelle erstellen, vom Typ string, 1000 Einträge, läuft nach 15 Sekunden ab, Anzahl der Fehler in den letzten 10 Sekunden speichern
stick-table type string len 128 size 1k expire 15s store http_err_rate(10s)
# IP merken
http-request track-sc0 src
# Verweigern bei HTTP-Fehler 429, wenn in den letzten 10 Sekunden mehr als 4 Fehler aufgetreten sind
http-request deny deny_status 429 if { sc_http_err_rate(0) gt 4 }
...
server rdgw01 192.168.1.33:443 maxconn 1000 weight 10 ssl check cookie rdgw01
server rdgw02 192.168.2.33:443 maxconn 1000 weight 10 ssl check cookie rdgw02
Nicht die beste Variante, komplizieren wir es. Zählen werden wir im Backend, aber blockieren im Frontend.
Mit dem Angreifer werden wir rigoros umgehen und die TCP-Verbindung abreißen.
frontend fe_rdp_tsc
bind *:443 ssl crt /etc/haproxy/cert/ertelecom_ru_2020_06_11.pem
mode http
...
#eine Tabelle für IP-Adressen erstellen, 1000 Elemente, läuft nach 15 Sekunden ab, speichert aus dem globalen Zähler
stick-table type ip size 1k expire 15s store gpc0
#Quelle erfassen
tcp-request connection track-sc0 src
#tcp-Verbindung ablehnen, wenn globaler Zähler >0
tcp-request connection reject if { sc0_get_gpc0 gt 0 }
...
default_backend be_rdp_tsc
backend be_rdp_tsc
...
mode http
...
#eine Tabelle für IP-Adressen erstellen, 1000 Elemente, läuft nach 15 Sekunden ab, speichert die Anzahl der Fehler über 10 Sekunden
stick-table type ip size 1k expire 15s store http_err_rate(10s)
#zu viele Fehler, wenn die Anzahl der Fehler über 10 Sekunden 8 übersteigt
acl errors_too_fast sc1_http_err_rate gt 8
#Angriff im globalen Zähler markieren (Zähler erhöhen)
acl mark_as_abuser sc0_inc_gpc0(fe_rdp_tsc) gt 0
#globalen Zähler zurücksetzen
acl clear_as_abuser sc0_clr_gpc0(fe_rdp_tsc) ge 0
#Quelle erfassen
tcp-request content track-sc1 src
#ablehnen, markieren, dass es sich um einen Angriff handelt
tcp-request content reject if errors_too_fast mark_as_abuser
#erlauben, Angriff-Flag zurücksetzen
tcp-request content accept if !errors_too_fast clear_as_abuser
...
server rdgw01 192.168.1.33:443 maxconn 1000 weight 10 ssl check cookie rdgw01
server rdgw02 192.168.2.33:443 maxconn 1000 weight 10 ssl check cookie rdgw02
das Gleiche, aber höflich, wir werden den HTTP-Fehler 429 (Zu viele Anfragen) zurückgeben
frontend fe_rdp_tsc
...
stick-table type ip size 1k expire 15s store gpc0
http-request track-sc0 src
http-request deny deny_status 429 if { sc0_get_gpc0 gt 0 }
...
default_backend be_rdp_tsc
backend be_rdp_tsc
...
stick-table type ip size 1k expire 15s store http_err_rate(10s)
acl errors_too_fast sc1_http_err_rate gt 8
acl mark_as_abuser sc0_inc_gpc0(fe_rdp_tsc) gt 0
acl clear_as_abuser sc0_clr_gpc0(fe_rdp_tsc) ge 0
http-request track-sc1 src
http-request allow if !errors_too_fast clear_as_abuser
http-request deny deny_status 429 if errors_too_fast mark_as_abuser
...
Ich prüfe: Ich starte mstsc und beginne, Passwörter willkürlich einzugeben. Nach dem dritten Versuch innerhalb von 10 Sekunden werde ich ausgesperrt, und mstsc gibt einen Fehler aus. Das ist auch in den Logs zu sehen.
Erklärungen. Ich bin kein Experte für haproxy. Ich verstehe nicht, warum zum Beispiel
http-request deny deny_status 429 if { sc_http_err_rate(0) gt 4 }
es erlaubt, etwa 10 Fehler zu machen, bevor es greift.
Ich verliere den Überblick über die Zählernummern. Experten für haproxy, ich wäre dankbar, wenn ihr mich ergänzen, korrigieren oder verbessern könntet.
In den Kommentaren könnt ihr andere Schutzmethoden für RD Gateway vorschlagen, ich würde mich freuen, darüber zu lernen.
Zum Thema Windows Remote Desktop Client (mstsc) ist anzumerken, dass er TLS1.2 nicht unterstützt (zumindest nicht unter Windows 7), weshalb ich TLS1 belassen musste; er unterstützt keine aktuellen Cipher, weshalb ich ebenfalls die alten belassen musste.
Für diejenigen, die nichts verstanden haben und gerade lernen, aber schon gut machen wollen, hier ist die gesamte Konfiguration.
haproxy.conf
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
# Standardstandorte für SSL-Materialien
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# Siehe: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
#ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE
-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
#ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
ssl-default-bind-options no-sslv3
ssl-server-verify none
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 15m
timeout server 15m
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend fe_rdp_tsc
bind *:443 ssl crt /etc/haproxy/cert/dektop.example.com.pem
mode http
capture request header Host len 32
log global
option httplog
timeout client 300s
maxconn 1000
stick-table type ip size 1k expire 15s store gpc0
tcp-request connection track-sc0 src
tcp-request connection reject if { sc0_get_gpc0 gt 0 }
acl rdweb_domain hdr(host) -i beg dektop.example.com
http-request deny deny_status 400 if !rdweb_domain
default_backend be_rdp_tsc
backend be_rdp_tsc
balance source
mode http
log global
stick-table type ip size 1k expire 15s store http_err_rate(10s)
acl errors_too_fast sc1_http_err_rate gt 8
acl mark_as_abuser sc0_inc_gpc0(fe_rdp_tsc) gt 0
acl clear_as_abuser sc0_clr_gpc0(fe_rdp_tsc) ge 0
tcp-request content track-sc1 src
tcp-request content reject if errors_too_fast mark_as_abuser
tcp-request content accept if !errors_too_fast clear_as_abuser
option forwardfor
http-request add-header X-CLIENT-IP %[src]
option httpchk GET /
cookie RDPWEB insert nocache
default-server inter 3s rise 2 fall 3
server rdgw01 192.168.1.33:443 maxconn 1000 weight 10 ssl check cookie rdgw01
server rdgw02 192.168.2.33:443 maxconn 1000 weight 10 ssl check cookie rdgw02
frontend fe_stats
mode http
bind *:8080
acl ip_allow_admin src 192.168.66.66
stats enable
stats uri /stats
stats refresh 30s
#stats admin if LOCALHOST
stats admin if ip_allow_admin
Warum gibt es zwei Server im Backend? Damit kann eine Fehlertoleranz erreicht werden. Haproxy kann auch zwei Server mit einer schwebenden IP-Adresse einrichten.
Rechenressourcen: Man kann mit „zwei Gigabyte, zwei Kerne, Gaming-PC“ beginnen. Laut das ist mehr als ausreichend.
Links:
Quelle: habr.com
