MS Remote Desktop Gateway, HAProxy en wagwoord brute force

Vriende, hallo!

Daar is baie maniere om van die huis af na jou kantoorwerkspasie te koppel. Een daarvan is om Microsoft Remote Desktop Gateway te gebruik. Dit is RDP oor HTTP. Ek wil nie aanraak oor die opstel van RDGW self hier nie, ek wil nie bespreek hoekom dit goed of sleg is nie, kom ons behandel dit as een van die afstandtoegangnutsmiddels. Ek wil praat oor die beskerming van jou RDGW-bediener teen die bose internet. Toe ek die RDGW-bediener opstel, het ek dadelik bekommerd geraak oor sekuriteit, veral beskerming teen wagwoord brute force. Ek was verbaas dat ek geen artikels op die internet gekry het oor hoe om dit te doen nie. Wel, jy sal dit self moet doen.

RDGW self het geen beskerming nie. Ja, dit kan met 'n kaal koppelvlak aan 'n wit netwerk blootgestel word en dit sal uitstekend werk. Maar dit sal die regte administrateur of inligtingsekuriteitspesialis onrustig maak. Boonop sal dit jou toelaat om die situasie van rekeningblokkering te vermy, wanneer 'n sorgelose werknemer die wagwoord vir 'n korporatiewe rekening op sy tuisrekenaar onthou en dan sy wagwoord verander het.

'n Goeie manier om interne hulpbronne teen die eksterne omgewing te beskerm, is deur verskeie gevolmagtigdes, publiseringstelsels en ander WAF's. Kom ons onthou dat RDGW steeds http is, dan vra dit net om 'n gespesialiseerde oplossing tussen interne bedieners en die internet te koppel.

Ek weet daar is cool F5, A10, Netscaler(ADC). As 'n administrateur van een van hierdie stelsels, sal ek sê dat dit ook moontlik is om beskerming teen brute geweld op hierdie stelsels op te stel. En ja, hierdie stelsels sal jou ook beskerm teen enige syn vloed.

Maar nie elke maatskappy kan bekostig om so 'n oplossing aan te koop (en 'n administrateur vir so 'n stelsel te vind nie :), maar terselfdertyd kan hulle sorg vir sekuriteit!

Dit is heeltemal moontlik om 'n gratis weergawe van HAProxy op 'n gratis bedryfstelsel te installeer. Ek het getoets op Debian 10, haproxy weergawe 1.8.19 in die stabiele bewaarplek. Ek het dit ook op weergawe 2.0.xx van die toetsbewaarplek getoets.

Ons sal die opstel van debian self buite die bestek van hierdie artikel laat. Kortliks: op die wit koppelvlak, maak alles toe behalwe poort 443, op die grys koppelvlak - sluit byvoorbeeld volgens jou beleid ook alles behalwe poort 22. Maak slegs oop wat nodig is vir werk (VRRP byvoorbeeld vir drywende ip).

Eerstens het ek haproxy in SSL-oorbruggingsmodus (ook bekend as http-modus) gekonfigureer en logging aangeskakel om te sien wat binne RDP aangaan. So te sê, ek het in die middel gekom. Dus, die /RDWeb-pad gespesifiseer in "alle" artikels oor die opstel van RDGateway ontbreek. Al wat daar is, is /rpc/rpcproxy.dll en /remoteDesktopGateway/. In hierdie geval word standaard GET/POST-versoeke nie gebruik nie; hul eie tipe versoek RDG_IN_DATA, RDG_OUT_DATA word gebruik.

Nie veel nie, maar darem iets.

Kom ons toets.

Ek begin mstsc, gaan na die bediener, sien vier 401 (ongemagtigde) foute in die logs, voer dan my gebruikersnaam/wagwoord in en sien die antwoord 200.

Ek skakel dit af, begin dit weer, en in die logs sien ek dieselfde vier 401-foute. Ek voer die verkeerde login/wagwoord in en sien weer vier 401-foute. Dis wat ek nodig het. Dit is wat ons sal vang.

Aangesien dit nie moontlik was om die aanmeld-url te bepaal nie, en ek weet boonop nie hoe om die 401-fout in haproxy op te vang nie, sal ek alle 4xx-foute opvang (nie eintlik vang nie, maar tel). Ook geskik om die probleem op te los.

Die kern van die beskerming sal wees dat ons die aantal 4xx-foute (op die agterkant) per tydeenheid sal tel en as dit die gespesifiseerde limiet oorskry, verwerp dan (op die voorkant) alle verdere verbindings vanaf hierdie ip vir die gespesifiseerde tyd .

Tegnies sal dit nie beskerming teen brute krag van wagwoorde wees nie, dit sal beskerming teen 4xx-foute wees. Byvoorbeeld, as jy dikwels 'n nie-bestaande url (404) versoek, dan sal die beskerming ook werk.

Die eenvoudigste en doeltreffendste manier is om op die agterkant te reken en terug te rapporteer as iets ekstra verskyn:

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

Nie die beste opsie nie, kom ons kompliseer dit. Ons sal reken op die agterkant en blok op die voorkant.

Ons sal die aanvaller onbeskof behandel en sy TCP-verbinding laat vaar.

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

dieselfde ding, maar beleefd sal ons die fout http 429 (Te veel versoeke) terugstuur.

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

Ek kontroleer: ek begin mstsc en begin lukraak wagwoorde invoer. Na die derde poging, binne 10 sekondes, skop dit my terug, en mstsc gee 'n fout. Soos gesien kan word in die logs.

Verduidelikings. Ek is ver van 'n haproxy-meester af. Ek verstaan ​​nie hoekom bv
http-versoek weier ontken_status 429 as { sc_http_err_rate(0) gt 4 }
laat jou toe om ongeveer 10 foute te maak voordat dit werk.

Ek is verward oor die nommering van die tellers. Meesters van haproxy, ek sal bly wees as julle my aanvul, regstel, my beter maak.

In die opmerkings kan u ander maniere voorstel om RD Gateway te beskerm, dit sal interessant wees om te bestudeer.

Wat die Windows Remote Desktop Client (mstsc) betref, is dit opmerklik dat dit nie TLS1.2 ondersteun nie (ten minste in Windows 7), so ek moes TLS1 verlaat; ondersteun nie huidige syfer nie, so ek moes ook die oues los.

Vir diegene wat niks verstaan ​​nie, net leer en reeds goed wil doen, sal ek jou die hele konfigurasie gee.

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

Waarom twee bedieners op die agterkant? Want dit is hoe jy foutverdraagsaamheid kan maak. Haproxy kan ook twee maak met 'n drywende wit ip.

Rekenaarhulpbronne: jy kan begin met "twee gig, twee cores, speletjie-rekenaar." Volgens Wikipedia dit sal genoeg wees om te spaar.

verwysings:

Stel rdp-gateway vanaf HAProxy op
Die enigste artikel wat ek gevind het waar hulle die moeite gedoen het om die wagwoord brute-force te maak

Bron: will.com