Est-il possible d'interdire une adresse IP après le nombre X de tentatives de connexion infructueuses à un serveur Windows? Pas à un compte particulier, ce que je sais faire, mais à la machine entière.
Nous sommes très durement frappés par des attaques par force brute qui tentent de deviner les noms d'utilisateurs. Cela aiderait donc beaucoup à alléger le serveur.
windows
brute-force-attacks
HeavyWave
la source
la source
Réponses:
Vous pouvez le faire avec Powershell et le gestionnaire de tâches. Ce n'est probablement pas une solution parfaite, mais cela fonctionne assez bien et j'ai environ 100 adresses IP bloquées en deux mois. J'ai écrit un script qui sélectionne un événement spécifié par EventLog ("audit failure"). Si de nombreuses adresses IP ont échoué, il est ajouté à la règle de pare-feu (créée manuellement) nommée "BlockAttackers" qui bloque tout trafic vers les adresses IP spécifiées.
Script PS1:
Créez une tâche dans le planificateur et définissez le déclencheur sur l'événement 4625 (connexion Windows, y compris les services de terminal). Cependant, vous pouvez configurer le déclencheur pour qu'il s'exécute, par exemple, deux fois par heure afin d'éviter un chargement inutile du serveur.
et après le déclencheur, exécutez le script powershell. Vous devez également définir des privilèges plus élevés pour exécuter ce script, sinon il échouera avec une exception de sécurité.
Vous pouvez également lier ce script à d'autres événements de sécurité.
la source
Je sais que cette question est ancienne, mais c’est en fait le premier message de forum que j’ai trébuché lorsque j’ai commencé à essayer de faire exactement la même chose il ya deux semaines. J'ai réussi à créer un script qui analyse les journaux d'événements 24 heures en arrière pour les entrées de journal d'événements de connexion incorrectes, récupère celles ayant plus de 10 connexions incorrectes, puis les place dans une liste de filtres ipsec à l'aide du commande netsh. Ensuite, j'ai écrit un fichier de commandes avec cette ligne
powershell .\*scriptname.ps1*
et créé une tâche planifiée pour exécuter le fichier de commandes toutes les 24 heures (pour une raison quelconque, il ne serait pas exécuté directement).Je sais que ce script est probablement inefficace, mais lorsque j'ai commencé à travailler là-dessus, je n'avais absolument aucune expérience de PowerShell. Mon habileté à optimiser les scripts laisse donc beaucoup à désirer. Cependant, malgré ce fait, j'ai pensé partager cela avec tous ceux qui pourraient l'utiliser.
Je remercie Remunda de m'avoir donné l’idée initiale, c’est cette affiche qui m’a fait comprendre l’idée d’utiliser PowerShell pour effectuer une recherche dans les journaux des événements.
la source
Ce script s'appuie sur la réponse de remunda et va un peu plus loin https://serverfault.com/a/397637/155102 Il explique que la règle "BlockAttackers" n'a pas encore d' adresse IP entrée (ce qui retourne un "*" sous forme de chaîne). Il écrit également un commentaire dans un fichier journal pour vous indiquer quand l’adresse IP a été ajoutée à la règle.
Un bon conseil est de créer la règle "BlockAttackers" qui bloque les adresses IP MAIS le rendre désactivé au début. Ensuite, exécutez ce script une fois manuellement pour qu’il puisse renseigner le champ "RemoteAddresses" avec les adresses IP à bloquer. Examinez ces adresses IP pour vous assurer qu'aucun élément essentiel n'a été ajouté, puis activez la règle de pare-feu. Ajoutez cette règle à votre pare-feu comme décrit précédemment.
Le git pour ce script
la source
Je ne peux pas prendre crédit pour cette réponse, mais https://serverfault.com/users/7200/evan-anderson a mentionné son projet http://opensource.wellbury.com/projects/windows_sshd_block/newest-release/.
la source
Ce n'est généralement pas une bonne idée de laisser quelqu'un d'autre contrôler vos règles de pare-feu. C'est essentiellement ce que vous demandez ici.
la source
C'est un vieux sujet. J'utilisais le script fourni par kevinmicke en 2014-2015. Ensuite, il a juste cessé de fonctionner. J'ai donc dû le modifier un peu pour adopter l'authentification Windows Network Security qui ne laisse pas les adresses IP dans le journal de sécurité. De plus, comme je n'ai pas de FTP courant, j'ai supprimé cette partie car elle causait des erreurs car il n'y avait pas de dossier de journal. Le principal changement concerne la source des événements RDP.
Le script ci-dessus fonctionnera sous Windows 2012. Si vous utilisez toujours Remote Desktop avec une authentification au niveau d'accès réseau sous Windows 2008, vous devrez peut-être suivre l'astuce suivante. Windows 2008 n'a pas d'adresse IP dans le journal de sécurité et ne semble pas en avoir dans le journal Microsoft-Windows-RemoteDesktopServices-RdpCoreTS. J'ai donc dû utiliser 2 journaux - associer les événements du journal de sécurité aux tentatives d'accès réussies au port 3389 dans le journal du pare-feu. C'est un travail approximatif, mais il semble détecter les attaques par mot de passe. Voici la partie qui recueille les IP violant:
REMARQUE: N'oubliez pas d'activer les journaux du pare-feu. NOTE 2: Je ne suis pas un expert en PowerShell. Ce serait donc bien que certains gourous puissent corriger / améliorer mon code.
la source
J'utilise ts_block freeby.
En gros, il s'agit d'un "programme VBScript qui agit en tant que récepteur d'événements WMI pour recevoir les événements consignés par Windows en réponse à des ouvertures de session des services Terminal Server non valides".
Semble fonctionner parfaitement, et le script est simple si vous avez besoin de le modifier. Vous pouvez soit laisser le journal enregistrer les tentatives, puis interdire en fonction du nombre de tentatives autorisées, et / ou vous pouvez coder en dur les noms de connexion auxquels vous ne voulez pas donner accès.
Je me suis fait prendre en ajoutant accidentellement le même nom deux fois et le service passe simplement dans une boucle sans fin qui redémarre toutes les 1500 ms, mais très facile à corriger / modifier si vous êtes d'accord avec vbs.
Mes paramètres actuels ne sont qu’une nouvelle tentative et vous êtes banni pendant 2 jours. Des noms de connexion du type «admin», «Admin», «Administrateur», «invité», etc. sont automatiquement bannis. Devrait être simple à changer pour ip?
Un peu addictif pour voir quelles créatures ont été interdites du jour au lendemain ...
la source
Voulez-vous dire vous connecter au serveur / domaine ou vous connecter à un site Web fonctionnant sur le serveur? Si vous parlez de vous connecter au serveur / domaine, la réponse est non. Windows n'a aucun concept de blocage d'adresses IP basé sur des tentatives d'ouverture de session infructueuses, car les adresses IP ne sont pas des entités de sécurité. Il peut y avoir des outils tiers qui peuvent faire cela, mais je n'en connais aucun, car je n'y ai jamais jeté un œil.
la source
Si un serveur Web est attaqué, vous pouvez installer l' extension de restrictions IP dynamiques . S'il s'agit d'une authentification standard sur le serveur, vous devriez pouvoir implémenter une isolation de domaine et de serveur qui limiterait la portée des attaques aux ordinateurs appartenant à un domaine et pourrait être configurée pour autoriser uniquement les tentatives des systèmes auxquels vous avez besoin d'accéder. le serveur. Dans Windows, la prévention des attaques par force brute consiste à définir la stratégie de verrouillage du compte sur 10 minutes et une stratégie de mot de passe incorrect sur 3 tentatives. Cela signifie que le compte attaqué serait verrouillé pendant 10 minutes après 3 tentatives. Les connexions IP ne sont pas verrouillables par défaut dans Windows. (En passant, je suis également curieux de savoir combien de tentatives de connexion cela prend par seconde pour avoir un impact sur le système)
la source
http://nerderies.blogspot.co.at/2012/12/automatically-banning-ips-with-windows.html
la source
En utilisant le script génial de Remunda comme point de départ, j’ai ajouté une chose qui manquait: le blocage des adresses IP à partir des connexions FTP ayant échoué . Windows Server n'enregistre pas l'adresse IP dans le journal de sécurité lorsqu'un utilisateur ne parvient pas à se connecter via FTP. Il définit plutôt "Adresse réseau source" sur un tiret. Le FTP étant un vecteur d’attaque très courant pour les attaques par force brute, j’ai ajouté à son script la possibilité d’analyser les journaux FTP du jour pour rechercher les échecs de connexion multiples et de bloquer également les adresses IP.
Mise à jour 2014/02/07: Lorsque j'ai apporté quelques modifications à cette question pour traiter tous mes anciens journaux FTP, je me suis rendu compte que, lorsqu'elles avaient un nombre de tentatives immense (plus de 50 000), les baies créées étaient énormes et rendaient le traitement extrêmement lent. Depuis, je l'ai réécrit pour le rendre beaucoup plus efficace lors du traitement des journaux FTP.
J'ai également découvert qu'il existe une limite absolue arbitraire de 1 000 pour le nombre d'adresses IP pouvant figurer dans une règle de pare-feu Windows. À cause de cette limite, j'avais besoin de créer automatiquement une nouvelle règle lorsque la dernière est remplie. Il le fait maintenant et crée également la règle de pare-feu initiale (si vous ne créez pas la vôtre) de sorte que la seule configuration à faire consiste à l'ajouter au planificateur afin qu'il soit exécuté lorsqu'il y a un événement 4625.
Voici le code qui a été testé sur Windows Server 2008 R2 et Windows 7:
la source
Set-ExecutionPolicy RemoteSigned
pour pouvoir exécuter des scripts locaux. Sinon, vous obtiendrez une erreur: "blockattackers.ps1 ne peut pas être chargé car l'exécution des scripts est désactivée sur ce système."Le script de remuda , édité par kevinmicke (7 février à 21h59) n'a pas vérifié le canal de contrôle du FTP, qui possède un propre dossier sur mon système (Windows Server 2008 R2). De plus,
530 11001
-events n'a pas été reconnu, ce qui semble apparaître lorsque le pirate tente uniquement d'accéder au canal de contrôle. J'ai donc ajouté quelques lignes dans le script pour vérifier un deuxième dossier FTP-log-folder:Le nom du dossier du journal FTP
FTPSVC*
sur la ligne 54 doit être complété. Dans les lignes 115 et 116, vous devez entrer l'adresse IP de votre serveur (IPv4 et IPv6), sinon l'adresse IP de vos propres serveurs pourrait être ajoutée cent fois à la règle de pare-feu. La variable que$int_block_limit
je mets à 1 sur mon serveur, le script bloque donc une attaque de pirates informatiques provoquant un événement 4625 en moins de deux secondes. Je pense toujours à exécuter le script en plus des événements 4625 survenus dans un laps de temps de quelques minutes. Bien entendu, il serait également possible de séparer les scripts et de laisser un script vérifier les 4625 événements déclenchés par l'événement 4625 et un autre les dossiers de journalisation du FTP vérifiant périodiquement toutes les 5 ou 10 minutes, même avec une règle de pare-feu distincte. et fichier journal.la source
J'ai ajouté le mien pour SQL
Ensuite, vous devrez ajouter le tableau dans ips_all
la source