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. Jem'é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
...
stick-table type string len 128 size 1k expire 15s store http_err_rate(10s)
http-request track-sc0 src
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
...
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 }
...
default_backend be_rdp_tsc
backend be_rdp_tsc
...
mode http
...
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
...
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.confglobal
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
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
-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 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 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