Comment arrêter les attaques par force brute sur Terminal Server (Win2008R2)?

23

Je connais mieux les outils Linux pour arrêter les attaques par force brute, j'ai donc du mal à trouver des outils appropriés pour Windows. J'utilise Windows Server 2008 R2 avec Terminal Server et j'aimerais bloquer une IP après plusieurs tentatives de connexion via RDP. Des indices?

windows-server-2008  terminal-server  brute-force-attacks 
— onik
source
3
Avez-vous vraiment besoin de gérer cela sur votre serveur Windows? Avez-vous envisagé de limiter le débit sur votre périphérique périphérique (pare-feu / routeur)?
— Zoredache
2
La boîte Windows est un VPS géré par une société d'hébergement, donc je n'ai pas accès aux périphériques réseau.
— onik
Vous pouvez configurer un événement de planification des tâches sur les connexions ayant échoué pour lancer un script PS; le PS Svript devrait compter le nombre de fois où une IP a essayé, puis le bloquer avec une règle de pare-feu. Je n'ai pas un tel script mais il serait possible de le créer.
— Chris S
@Chris S: C'est plus ou moins ce que fait mon script ts_block, sauf qu'il s'exécute comme un journal des événements "récepteur" et reçoit un rappel chaque fois que de nouveaux événements sont enregistrés. En tant que tel, il s'exécute plus ou moins en temps réel.
— Evan Anderson
Utilisez VPN - installez par exemple. OpenVPN sur le routeur. Ne jamais mettre Windows Box directement sur Internet - c'est dangereux.
— integratorIT

Réponses:

5

pour arrêter les tentatives de connexion rdp, comme déjà dit, vous avez besoin du contrôle de votre pare-feu pour isoler une adresse IP particulière. Vous pouvez définir certains paramètres dans Outils d'administration -> Gestionnaire des services Terminal Server, mais vous ne pouvez rien faire pour arrêter une adresse IP de cette manière. Peut-être que vous devez envisager un script par lots pour écouter le port rdp et contrôler les échecs de connexion, donc s'il y avait une tentative totale (vous choisissez le numéro ...) par la même IP, alors aucune autre tentative pendant une période connue ne pourrait être. Je ne sais pas si c'est possible, mais ça pourrait être un moyen ...

— Nicola Boccardi
source
1
D'accord, c'est comme je le pensais. Je dois étudier l'Observateur d'événements pour voir si je peux exporter les adresses IP dans un fichier pour un traitement par lots. Pour le moment, je dois les récupérer à partir de décharges .csv générées manuellement
— onik
5
Modifiez le port sur lequel RDP répond.
— JohnThePro
Le plus drôle, c'est que je veux restreindre les adresses IP, mais l'échec de la connexion ne rapporte pas l'adresse IP
— Csaba Toth
Changer le port obscurcit seulement. Ils trouveront le nouveau port avec un logiciel de numérisation de port intelligent.
— TheLegendaryCopyCoder du
@CsabaToth Le journal des événements n'enregistre pas d'informations utiles par défaut. Vous pouvez activer la journalisation détaillée dans le service netlogon à partir d'un contrôleur de domaine ou d'un ordinateur recevant les demandes RDP pour obtenir des informations supplémentaires. Vous pouvez activer la journalisation du pare-feu Windows pour déterminer l'adresse IP.
— Michael Steele
25

Vous devriez vraiment bloquer ces tentatives sur votre pare-feu de périphérie, ne serait-ce qu'avec une limitation de débit. Si vous n'avez pas la possibilité de le faire, lisez la suite.

Si vous ne pouvez pas bloquer au niveau du pare-feu périphérique et que RDP n'est ouvert qu'à un sous-ensemble d'Internet, utilisez les fonctionnalités intégrées du pare-feu Windows pour verrouiller les connexions entrantes.

Enfin, si vous devez vraiment ouvrir RDP à l'intégralité d'Intenet, vous pouvez consulter la version modifiée de mon programme de blocage de force brute SSH pour Windows que j'ai dans un référentiel github . Ce script, ts_block, bloque les tentatives d'ouverture de session des services Terminal Server par force brute sur Windows Server 2003, 2008 et 2008 R2. Malheureusement, en raison des modifications apportées aux événements consignés par Windows lors de l'utilisation de la couche de sécurité TLS / SSL pour RDP, ce script devient de plus en plus inefficace . (Pourquoi Microsoft a choisi d'omettre l'adresse IP de l'hôte qui tente de s'authentifier me dépasse. On dirait que ce serait une chose assez importante pour se connecter, hein?)

— Evan Anderson
source
1
J'utilise la page ts_block ici et c'est incroyable! Mon serveur Windows (2008 R2) ralentissait sous de nombreuses attaques par force brute mais plus maintenant! TS_BLOCK est écrit en vbscript - et peut / doit être installé en tant que service Windows - mais n'utilisez pas la version MSI, éditez simplement le code .vbs et installez-vous avec l'utilitaire nssm. Vous n'avez pas besoin des entrées de registre car le code .vbs a les valeurs par défaut en dur. <p> J'ai édité le code et il bloque CHAQUE connexion échouée immédiatement - comme étant mon propre serveur Web, il ne devrait y avoir AUCUNE tentative de connexion échouée. Donc le script
C'est assez gentil, Evan. J'ai la moitié de l'idée de le réimplémenter en C # afin que vous puissiez l'exécuter en tant que service Windows natif plutôt que de pirater avec srvany et autres. Si jamais je le fais, je vais le jeter sur Github ou quelque chose aussi.
— Ryan Bolger
1
@RyanBolger: J'ai un faible pour VBScript et les langues interprétées en général. Je trouve que l'utilisation de "Non-Sucking Service Manager" permet une expérience assez indolore en exécutant des programmes VBScript en tant que services.
— Evan Anderson
ts_block est incroyable c'est exactement ce que je cherchais "Merci Evan Anderson" Quand j'ai placé mon premier serveur virtuel Terminal directement sur le web en un jour, j'ai eu plus de 10 000 connexions échouées. Quand j'ai le temps, je pourrais le modifier et ajouter un blocage permanent en fonction du nombre de blocs précédents. Par exemple: IP est banni 4 fois en une journée. (À moins qu'il n'ait déjà été créé)
Basé sur un ts_blockscript, voici une solution qui utilise fail2bansur la passerelle pour bloquer les attaquants: wqweto.wordpress.com/2013/12/10/…
— wqw
3

J'ai un programme C # qui fait exactement cela. J'ai eu un problème sur Server 2008 R2 où le journal des événements ne répertoriait pas toujours les adresses IP de l'utilisateur (s'ils se connectaient à partir des clients Remote Desktop les plus récents). Certains services implémentent leur propre fournisseur de vérification des informations d'identification qui ne fournit pas toutes les informations souhaitées.

http://cyberarms.net/security-insights/security-lab/remote-desktop-logging-of-ip-address-%28security-event-log-4625%29.aspx

Cependant, pour le Bureau à distance, j'ai découvert qu'entrer dans "Configuration d'hôte de session Bureau à distance" et changer la connexion RDP-TCP pour avoir la couche de sécurité de "Couche de sécurité RDP" au lieu de "Négocier" ou "SSL (TLS 1.0)" ramena le Adresses IP.

Que vous souhaitiez vraiment le faire est une autre question pour vous, "Si vous sélectionnez la couche de sécurité RDP, vous ne pouvez pas utiliser l'authentification au niveau du réseau."

J'ai trouvé que http://www.windowsecurity.com/articles/logon-types.html était utile. J'ai utilisé EventLogWatcher et lié à "* [System / EventID = 4625 ou System / EventID = 4624]" afin que je puisse réinitialiser un mauvais compte en cas de succès si l'utilisateur venait vraiment de se tromper de mot de passe. J'ai également ajouté à la liste blanche: 1, 0.0.0.0, 127.0.0.1 et "-". Vous pouvez ou non souhaiter mettre sur liste blanche les IP LAN / gestion.

J'utilise Forefront TMG, j'ai donc utilisé l'API pour ajouter de mauvaises adresses IP à un groupe d'adresses IP de cette façon et j'ai demandé à Cisco d'ajouter un accès API à l'un de leurs routeurs SMB (ce qu'ils m'ont assuré qu'ils pourraient bien faire!)

Si vous souhaitez utiliser le pare-feu Windows natif pour les bloquer, jetez un œil à l'API pour cela ("netsh advfirewall").

J'autorise x nombre de tentatives avant d'interdire et un succès réinitialise le décompte.

— Matthew1471
source
2

Essayez-vous d'empêcher les effractions ou les journaux encombrés? Si vous essayez d'empêcher les introductions par effraction, Windows a un moyen intégré de bloquer les tentatives de connexion. Il existe un paramètre de stratégie de groupe de seuil de verrouillage de compte dans Configuration ordinateur -> Stratégies -> Paramètres Windows -> Paramètres de sécurité -> Politique de compte -> Politique de verrouillage de compte.

Les attaquants utiliseront des noms d'utilisateur courants comme Administrateur, et ils les verrouilleront certainement. Vous auriez besoin d'un compte séparé pour l'administration réelle, ce qui est probablement conseillé de toute façon.

Le blocage automatique au niveau du pare-feu nécessitera une lecture de journal scriptée avec mise à jour automatique des règles de pare-feu. Vous devriez pouvoir ajouter des règles basées sur l'adresse IP de cette façon. C'est essentiellement ce que fait iptables dans un système Linux.

Cela peut être un peu évident, mais avez-vous également envisagé d'exécuter les services Bureau à distance sur un port non standard ? Cela a été très efficace pour moi pour contrecarrer les effractions.

— Joel E Salas
source
Bloquer les tentatives de connexion répétées sur le pare-feu est une bonne pratique, mais supposer que les attaques par force brute ne se produiront pas "derrière le pare-feu" n'est pas une très bonne hypothèse. Une brute basée sur l'hôte pour le bloc est à mon avis une assez bonne idée. L'utilisation du verrouillage de compte est certainement une bonne idée, mais j'aime aussi l'idée de supprimer les tentatives de force brute pour garder les journaux plus propres.
— Evan Anderson
1
Je suis déjà en cours d'exécution sur un port non standard, et ma plus grande préoccupation est que mon serveur soit effectivement déconnecté en raison du grand nombre de tentatives de connexion.
— boomhauer
Une option consiste à désactiver complètement l'accès au Bureau à distance via le pare-feu, mais à avoir un service en cours d'exécution sur le serveur qui reconfigure le pare-feu pour autoriser le trafic RDP, ce service est protégé par mot de passe et n'autorise peut-être que l'accès à partir d'une source IP "de confiance" ( comme la plage IP d'un téléphone mobile ou votre bureau). Il introduit des tracas, mais fonctionne.
— Dai
1

Il existe également quelques autres solutions si vous souhaitez plutôt avoir une solution basée sur une interface graphique et créer réellement différents ensembles de règles pour différents événements. Le plus simple serait RDPGuard (hxxp: //www.rdpguard.com), mais dans un environnement d'entreprise, vous voudrez probablement plus de rapports, comme la provenance de l'attaque (pays, origine) et le nom d'utilisateur utilisé afin que vous puissiez rapidement décidez si c'est l'un de vos propres utilisateurs qui se bloque accidentellement ou tente de se connecter là où vous ne le savez pas.

Personnellement, j'aime Syspeace (hxxp: //www.syspeace.com) qui fait tout cela pour nous mais j'avais pensé que je les mentionnerais quand même

— Juha Jurvanen
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.