MS Remote Desktop Gateway, HAProxy och lösenordsåterställning

Hej vänner!

Det finns många sätt att ansluta hemifrån till arbetsplatsen på kontoret. Ett av dem är att använda Microsoft Remote Desktop Gateway. Detta är RDP över HTTP. Jag vill inte gå in på hur man konfigurerar själva RDGW, eller diskutera varför det är bra eller dåligt, låt oss se på det som ett av verktygen för fjärråtkomst. Jag vill prata om hur man skyddar din RDGW-server från det onda internet. När jag ställde in RDGW-servrarna blev jag genast bekymrad över säkerheten, särskilt skyddet mot lösenordsattacker. Jag blev förvånad över att jag inte hittade några artiklar på nätet om hur man kan göra detta. Nåväl, jag får göra det själv.

RDGW i sig har inga skydd. Ja, man kan placera det med en öppen gränssnitt i det offentliga nätet och det kommer att fungera bra. Men en riktig administratör eller säkerhetsspecialist kommer att känna sig obekväm med det. Dessutom kan detta förhindra situationen där ett konto blockerats när en oansvarig anställd har sparat sitt företagskontolösenord på sin hemmadator och sedan ändrat sitt eget lösenord.

Ett bra sätt att skydda interna resurser från den externa miljön är genom olika proxyservrar, publiceringssystem och andra WAF. Kom ihåg att RDGW trots allt är http, så det är självklart att sätta en specialiserad lösning mellan de interna servrarna och internet.

Jag vet att det finns fantastiska F5, A10, Netscaler (ADC). Som administratör av ett av dessa system kan jag säga att det också är möjligt att konfigurera skydd mot lösenordsattacker på dessa system. Och ja, dessa system skyddar er också från olika syn-floods.

Men inte varje företag har råd att köpa en sådan lösning (och hitta en administratör för ett sådant system :), men de kan ändå ta hand om säkerheten!

Det är fullt möjligt att installera gratisversionen av HAProxy på ett gratis operativsystem. Jag testade på Debian 10, i det stabila arkivet finns version haproxy 1.8.19. Jag testade också på versionerna 2.0.xx från testing-arkivet.

Konfigurationen av själva Debian lämnar vi utanför artikeln. Kort sagt: stäng allt på den offentliga gränssnittet, förutom port 443, på det grå gränssnittet - enligt din policy, till exempel stänga allt utom port 22. Öppna bara det som är nödvändigt för driften (VRRP till exempel, för fluktuerande ip).

Först och främst har jag konfigurerat haproxy i SSL bridging-läge (även känt som mode http) och aktiverat loggning för att se vad som egentligen händer inne i RDP. Man kan säga att jag har satt mig mitt emellan. Så, den väg som anges i "alla" artiklar om RDGateway, /RDWeb, saknas. Det som finns där är bara /rpc/rpcproxy.dll och /remoteDesktopGateway/. Standard GET/POST-förfrågningar används inte, utan en egen typ av förfrågningar: RDG_IN_DATA, RDG_OUT_DATA.

Inte mycket, men åtminstone något.

Låt oss testa.

Jag startar mstsc, går till servern och ser fyra fel 401 (obehörig) i loggarna. Sedan anger jag användarnamn/lösenord och ser svaret 200.

Jag stänger ner, startar om och ser de samma fyra felen 401 i loggarna. Jag anger felaktigt användarnamn/lösenord och ser återigen fyra fel 401. Det är något att bygga vidare på. Detta ska vi fånga.

Eftersom jag fortfarande inte lyckats bestämma login-URL:en, och dessutom inte vet hur man fångar exakt fel 401 i haproxy, kommer jag att fånga (egentligen räkna) alla 4xx-fel. Det kommer också att fungera för att lösa problemet.

Skyddet kommer att bestå av att vi räknar antalet 4xx-fel (på backend) per tidsenhet och om det överskrider den angivna gränsen, kommer vi att avvisa (på frontend) alla vidare anslutningar från den IP-adressen under den angivna tiden.

Tekniskt sett kommer detta inte att vara ett skydd mot lösenordsattacker, utan ett skydd mot 4xx-fel. Till exempel, om man ofta begär en icke-existerande URL (404), kommer skyddet också att aktiveras.

Det enklaste och fungerande sättet är att räkna och blockera på backend om något extra dyker upp:

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

    # skapa en tabell, av string-typ, 1000 element, utgår på 15 sekunder, spara antalet fel under de senaste 10 sekunderna
    stick-table type string len 128 size 1k expire 15s store http_err_rate(10s)
    # kom ihåg IP
    http-request track-sc0 src
    # förbjuda med http-fel 429 om mer än 4 fel under de senaste 10 sekunderna
    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

Inte den bästa lösningen, vi gör det mer komplicerat. Vi kommer att räkna på backend och blockera på frontend.

Vi kommer att hantera angriparen grovt, genom att bryta TCP-anslutningen.

frontend fe_rdp_tsc
    bind *:443 ssl crt /etc/haproxy/cert/ertelecom_ru_2020_06_11.pem
    mode http
    ...
    # skapa en IP-adress-tabell, 1000 element, som går ut efter 15 sekunder, spara från den globala räknaren
    stick-table type ip size 1k expire 15s store gpc0
    # hämta källa
    tcp-request connection track-sc0 src
    # avvisa TCP-anslutning om den globala räknaren >0
    tcp-request connection reject if { sc0_get_gpc0 gt 0 }
	
    ...
    default_backend be_rdp_tsc


backend be_rdp_tsc
    ...
    mode http
    ...
	
    # skapa en IP-adress-tabell, 1000 element, som går ut efter 15 sekunder, spara antal fel under 10 sekunder
    stick-table type ip size 1k expire 15s store http_err_rate(10s)
    # många fel om antalet fel under 10 sekunder överskrider 8
    acl errors_too_fast sc1_http_err_rate gt 8
    # markera attacken i den globala räknaren (öka räknaren)
    acl mark_as_abuser sc0_inc_gpc0(fe_rdp_tsc) gt 0
    # nollställ den globala räknaren
    acl clear_as_abuser sc0_clr_gpc0(fe_rdp_tsc) ge 0
    # hämta källa
    tcp-request content track-sc1 src
    # avvisa, markera som attack
    tcp-request content reject if errors_too_fast mark_as_abuser
    # tillåt, nollställ attackflaggan
    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

samma sak, men artigt, vi kommer att returnera fel http 429 (För många begärningar)

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

Jag testar: startar mstsc och börjar oordnat ange lösenord. Efter tredje försöket inom 10 sekunder blir jag utsparkad, och mstsc ger ett fel. Vilket syns i loggarna.

Förklaringar. Jag är långt ifrån en expert på haproxy. Jag förstår inte varför, till exempel
http-request deny deny_status 429 if { sc_http_err_rate(0) gt 4 }
tillåter omkring 10 fel innan det slår till.

Jag förvirrar mig när det gäller räknarnumreringen. Mästarna av haproxy, jag skulle uppskatta om ni kompletterar mig, korrigerar, eller gör det bättre.

Ni kan gärna lista andra sätt att skydda RD Gateway i kommentarerna, det skulle vara intressant att studera.

Gällande Windows Remote Desktop Client (mstsc) är det värt att notera att den inte stöder TLS1.2 (i alla fall i Windows 7), så jag var tvungen att använda TLS1; den stöder inte aktuella cipher, så jag var också tvungen att använda äldre.

För de som inte förstod något och bara lär sig, och redan vill göra det bra, här är hela konfigurationen.

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

        # Standardinställningar för SSL-material
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

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

Varför två servrar på backend? För det gör det möjligt att skapa redundans. Du kan också ha HAProxy med två flytande vita IP-adresser.

Beräkningsresurser: man kan börja med "två gigabyte, två kärnor, en speldator". Enligt Wikipedia detta kommer att vara tillräckligt med marginal.

Länkar:

Konfiguration av rdp-gateway för HAProxy
Den enda artikeln jag har funnit där man har oroat sig över lösenordsåterställning.

Källa: habr.com