Passerelle MS Remote Desktop, HAProxy et deviner les mots de passe

Salut les amis!

Il existe de nombreuses façons de se connecter de la maison à un lieu de travail dans un bureau. L'un d'eux consiste à utiliser Microsoft Remote Desktop Gateway. Il s'agit de RDP sur HTTP. Je ne veux pas aborder la configuration de RDGW elle-même, je ne veux pas discuter de pourquoi il est bon ou mauvais, traitons-le comme l'un des outils d'accès à distance. Je veux parler de la protection de votre serveur RDGW contre le mal Internet. Lorsque j'ai configuré le serveur RDGW, j'ai immédiatement été préoccupé par la protection, en particulier la protection par mot de passe. J'ai été surpris de ne pas avoir trouvé d'articles sur Internet sur la façon de procéder. Eh bien, vous devez le faire vous-même.

RDGW lui-même n'a aucune protection. Oui, il est possible d'exposer une interface de rail nue dans un filet blanc et cela fonctionnera très bien. Mais le bon administrateur ou IB'shnik en sera inquiet. De plus, cela permettra d'éviter la situation de blocage d'un compte lorsqu'un employé négligent se souvient du mot de passe du compte d'entreprise sur l'ordinateur personnel, puis change son mot de passe.

Un bon moyen de protéger les ressources internes de l'environnement externe consiste à utiliser divers mandataires, systèmes de publication et autres WAF. Rappelons que RDGW est tout de même http, alors il supplie directement de coller une solution spécialisée entre les serveurs internes et Internet.

Je sais qu'il y a des F5, A10, Netscaler (ADC) sympas. En tant qu'administrateur de l'un de ces systèmes, je dirai qu'il est également possible de configurer une protection contre les interruptions sur ces systèmes. Et oui, ces systèmes vous protégeront de toute inondation syn en cours de route.

Mais toutes les entreprises ne peuvent pas se permettre d'acheter une telle solution (et trouver l'administrateur d'un tel système :), mais elle peut prendre soin de la sécurité!

Il est possible d'installer la version gratuite de HAProxy sur un système d'exploitation gratuit. J'ai testé sur Debian 10, dans la version de référentiel stable de haproxy 1.8.19. J'ai également vérifié la version 2.0.xx du référentiel de tests.

La configuration de debian elle-même dépasse le cadre de cet article. En bref: sur l'interface blanche, fermez tout sauf 443 ports, sur l'interface grise - selon votre politique, par exemple, fermez tout sauf 22 ports. Ouvrez uniquement ce qui est nécessaire pour le travail (VRRP par exemple, pour une IP flottante).

Tout d'abord, j'ai configuré haproxy en mode de pontage SSL (aka mode http) et activé la journalisation pour voir ce qui se passe à l'intérieur de RDP. Pour ainsi dire, grimpé au milieu. Ainsi, le chemin d'accès / RDWeb spécifié dans «tous» les articles sur la configuration de RDGateway est manquant. Tout ce qu'il y a est /rpc/rpcproxy.dll et / remoteDesktopGateway /. Dans ce cas, les requêtes GET / POST standard ne sont pas utilisées, son propre type de requête est RDG_IN_DATA, RDG_OUT_DATA.

Pas grand chose, mais au moins quelque chose.

Testons.

Je démarre mstsc, vais sur le serveur, je vois quatre erreurs 401 (non autorisées) dans les journaux, puis j'entre le login / mot de passe et je vois la réponse 200. Je

m'éteins, je recommence, je vois les mêmes quatre erreurs 401 dans les journaux. J'entre le mauvais nom d'utilisateur / mot de passe et j'en vois à nouveau quatre erreurs 401. Ce dont vous avez besoin. C'est ce que nous attraperons.

Puisqu'il n'a pas été possible de déterminer l'URL de connexion, et d'ailleurs, je ne sais pas comment détecter l'erreur 401 dans haproxy, je vais attraper (pas réellement attraper, mais compter) toutes les erreurs 4xx. Aussi heureux de résoudre le problème.

L'essence de la protection sera que nous comptons le nombre d'erreurs 4xx (sur le backend) par unité de temps et si elle dépasse la limite spécifiée, puis rejetons (sur le frontend) toutes les autres connexions de cette ip pendant la durée spécifiée.

Techniquement, ce ne sera pas une protection par mot de passe, ce sera une protection contre les erreurs 4xx. Par exemple, si vous demandez fréquemment une URL inexistante (404), la protection fonctionnera également.

Le moyen le plus simple et le plus efficace consiste à compter et à battre sur le backend, si quelque chose de superflu est apparu:

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
    ...

    # , , 1000 ,   15 ,  -    10 
    stick-table type string len 128 size 1k expire 15s store http_err_rate(10s)
    # ip
    http-request track-sc0 src
    #  http  429,    10   4 
    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

Pas une bonne option, compliquez. Nous compterons sur le backend, et le bloquerons sur le frontend.

Nous agirons grossièrement avec l'attaquant, nous lui abandonnerons la connexion TCP.

frontend fe_rdp_tsc
    bind *:443 ssl crt /etc/haproxy/cert/ertelecom_ru_2020_06_11.pem
    mode http
    ...
    #  ip , 1000 ,   15 ,    
    stick-table type ip size 1k expire 15s store gpc0
    # 
    tcp-request connection track-sc0 src
    # tcp ,    >0
    tcp-request connection reject if { sc0_get_gpc0 gt 0 }
	
    ...
    default_backend be_rdp_tsc


backend be_rdp_tsc
    ...
    mode http
    ...
	
    #  ip , 1000 ,   15 ,  -   10 
    stick-table type ip size 1k expire 15s store http_err_rate(10s)
    # ,  -   10   8
    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
	
    ...
    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

la même chose, mais poliment, nous retournerons l'erreur http 429 (Too Many Requests)

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
    ...

Vérifiez: exécutez mstsc et commencez à saisir des mots de passe au hasard. Après la troisième tentative, il me donne un coup de pied en 10 secondes et mstsc donne une erreur. Comme on peut le voir dans les journaux.

Explications Je suis loin d'être un maître haproxy. Je ne comprends pas pourquoi, par exemple,
http-request deny deny_status 429 si {sc_http_err_rate (0) gt 4}
vous permet de faire environ 10 erreurs avant de fonctionner.

Je suis confus dans la numérotation des compteurs. Maîtres haproxy, je serai heureux si vous me complétez, corrigez-moi, faites mieux.

Dans les commentaires, vous pouvez jeter d'autres moyens de protéger RD Gateway, il sera intéressant d'étudier.

En ce qui concerne le client Windows Remote Desktop (mstsc), il convient de noter qu'il ne prend pas en charge TLS1.2 (au moins dans Windows 7), j'ai donc dû quitter TLS1; ne prend pas en charge le chiffrement actuel, j'ai donc également dû quitter les anciens.

Pour ceux qui ne comprennent rien, qui apprennent juste, et qui veulent déjà bien faire, je vais donner toute la config.

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

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # See: 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


Pourquoi deux serveurs sur le backend? Parce que c'est ainsi que la tolérance aux pannes peut être effectuée. Haproxy peut également faire deux avec ip blanc flottant.

Ressources informatiques: vous pouvez commencer avec "deux concerts, deux cœurs, un PC de jeu". Selon Wikipédia, cela suffira avec une marge.

Liens:

Configuration de rdp-gateway à partir de HAProxy Le seul article que j'ai trouvé où j'étais gêné par le craquage de mot de passe

All Articles