Le sujet de la sécurité des serveurs Windows a été soulevé plusieurs fois, y compris sur ce blog. Néanmoins, je voudrais à nouveau rafraîchir la mémoire des anciennes méthodes de défense et en parler de nouvelles peu connues. Bien sûr, nous utiliserons au maximum les outils intégrés.

Supposons donc que nous ayons une petite entreprise qui loue un serveur de terminaux dans un centre de données distant.

Lorsque vous concevez une protection, vous devez commencer par un modèle de menace - contre qui ou quoi, en fait, nous défendrons. Dans notre configuration typique, je construirai une défense contre les pirates externes malveillants, des utilisateurs incompétents (et peut-être un peu malveillants). Commençons par le périmètre extérieur de la défense - le pare-feu.

Derrière toi comme un mur de feu

À l'époque de Windows 2003, le pare-feu intégré était une vision misérable, et s'il était impossible d'utiliser des outils tiers, vous deviez utiliser IPSec. Un exemple d'une telle configuration est discuté, par exemple, dans le document Secure Windows Servers using IPSec Firewall .

Maintenant, avec l'avènement de WFP ( Windows Filtering Platform ), les choses se sont améliorées. En principe, chaque administrateur système Windows est probablement tombé sur ce pare-feu d'une manière ou d'une autre, donc configurer l'accès à distance au serveur uniquement à partir de certaines adresses IP ne devrait pas être difficile. Je ferai attention à certains "chips", qui sont rarement utilisés.

Par défaut, le pare-feu bloque toutes les connexions entrantes, à l'exception de celles explicitement autorisées, mais les sorties permettent toutes les connexions sauf celles explicitement interdites. Cette politique peut être modifiée en ouvrant la gestion du pare-feu via wf.msc et en sélectionnant "Propriétés".

Paramètres du pare-feu.

Maintenant, si nous voulons empêcher les utilisateurs du serveur Terminal Server d'accéder à Internet à partir de ce serveur, nous réussirons.

Il convient de noter que lors de la configuration des règles d'accès au serveur (connexions entrantes), la création explicite de règles pour le trafic sortant n'est pas nécessaire. En termes d'iptables, établis et liés sont toujours autorisés.

Pour les connaisseurs de la ligne de commande, vous pouvez configurer le pare-feu dans le contexte de netsh advfirewall. Vous pouvez lire les commandes dans l'article " Pare-feu Windows 7 avec sécurité avancée ". J'ajouterai que le blocage des connexions entrantes et sortantes est activé par la commande:

netsh advfirewall set currentprofile firewallpolicy blockinbound,blockoutbound 

Une autre caractéristique du pare-feu Windows est que tout programme ou paramètre modifie ses règles sans notification. Par exemple, vous avez désactivé toutes les règles de notre grand-père, une seconde est apparue à proximité, vous avez créé un réseau local entre elles, mis en place un accès partagé et ... soudain, vous avez activé smb pour tout le monde et tout avec toutes les conséquences.

Il y a essentiellement deux sorties et demie (permettez-moi de vous rappeler que nous ne parlons que d'outils intégrés): vérifiez régulièrement si les règles ont changé et utilisez le bon vieux IPSec ou, pour moi, l'option la plus raisonnable est de configurer le pare-feu avec la stratégie de groupe. Les paramètres sont définis dans Configuration ordinateur - Configuration Windows - Paramètres de sécurité - Moniteur de pare-feu Windows Defender dans Advanced Security.

Configuration d'une stratégie de groupe de pare-feu.

De plus, en utilisant le pare-feu Windows, vous pouvez implémenter un fail2ban simple. Il suffit d'activer l'audit des tentatives de connexion infructueuses et, en cas de plusieurs échecs consécutifs, de bloquer l'adresse IP source. Vous pouvez utiliser des scripts auto-écrits, ou vous pouvez utiliser des outils prêts à l'emploi, dont j'ai parlé dans l'article « Comment donner des chiffreurs pour couler une entreprise ».

Si le pare-feu intégré ne suffit pas et que vous souhaitez utiliser quelque chose de plus sérieux, vous pouvez installer un logiciel tiers. Il est dommage que la plupart des solutions bien connues pour Windows Server soient payantes. Une autre option serait de placer un routeur devant le serveur. Il est clair qu'une telle installation convient si nous utilisons la colocation et que nous ne louons pas un serveur quelque part loin, très loin à l'étranger. Si le centre de données étranger est notre choix, vous pouvez utiliser la virtualisation - par exemple, Hyper-V intégré - et installer GNU \ Linux ou FreeBSD familier dans la machine virtuelle.

La question se pose: comment faire en sorte que la machine virtuelle ait un accès direct à Internet, mais pas le serveur? De plus, que l'adresse MAC du serveur ne brille pas sur l'hébergeur et ne nécessite donc pas l'achat d'une autre adresse IP.

Attention Il est préférable d'effectuer d'autres actions via IP-KVM!

Pour cela, la machine virtuelle doit être équipée de deux adaptateurs réseau. L'une est pour la connexion directe à Internet, pour cela nous allons faire un switch virtuel de type «externe» et décochez la case permettant au système d'exploitation d'interagir avec ce switch. Avec cette coche, nous privons le serveur d'un accès direct à Internet (il est préférable de configurer le pare-feu virtuel à l'avance), et son MAC ne s'allumera pas sur l'hôte.

Configurez un commutateur virtuel externe.

Un autre commutateur virtuel doit être de type «interne» pour l'interaction entre la machine virtuelle et le serveur. Il doit déjà configurer l'adressage local. Cela va créer un routeur virtuel qui se tient devant le serveur et le protège.

Dans le même temps, vous pouvez configurer votre VPN préféré pour le bureau ou les employés distants sur cette machine virtuelle sans se soucier du rôle de «Routage et accès distant» ou avec IPSec intégré, comme je l'ai décrit dans l'article « Comment j'ai caché la base 1C en Allemagne ». L'essentiel est de ne pas oublier de vérifier le démarrage de cette machine virtuelle au démarrage du système.

Vous pouvez vous connecter à un tel serveur à l'aide de RDP standard ou utiliser des clients HTML5 avec une authentification à deux facteurs. En cas de force brute, il vaut la peine de s'occuper des deux solutions fail2ban et de bloquer le compte pendant un certain temps avec plusieurs tentatives infructueuses d'autorisation consécutive.

Dehors, nous avons plus ou moins protégé le serveur, passons à la protection interne.

Protection interne: arrêtez et ne lâchez pas

Bien sûr, pour protéger le serveur de l'intérieur, je veux vraiment installer une sorte d'antivirus - on ne sait jamais ce que les utilisateurs du serveur accumulent ou pompent depuis Internet. Mais en pratique, l'antivirus sur le serveur peut faire plus de mal que de bien. Par conséquent, j'utilise généralement des mécanismes de blocage de lancement de logiciels non mis en liste blanche - en particulier, le mécanisme SRP (stratégies de restriction logicielle), que j'ai également mentionné dans l'article « Comment permettre aux chiffreurs d'inonder une entreprise ».

Je m'attarderai plus en détail sur un écueil, que nous oublions souvent lorsque vous activez SRP avec des paramètres standard, lorsque tout est bloqué, à l'exception des dossiers Windows et Program Files. En effet, cela filtre presque tous les logiciels malveillants. Mais cela ne fonctionne pas vraiment avec la malveillance des employés, car dans les dossiers système, il existe des sous-dossiers avec le droit de créer des objets par les utilisateurs. Par exemple, vous pouvez consulter le dossier C: \ Windows \ Temp.

Autorisations pour le dossier qui est sur liste blanche.

Et un tel dossier n'est pas le seul. Vous pouvez, bien sûr, auditer vous-même les dossiers système, ou vous pouvez faire confiance à des personnes qui l'ont déjà fait. Par exemple, un spécialiste de Stefan Kanthak sur son blog (il y a un virus de test EICAR par référence, un antivirus peut fonctionner) parcourt de manière plutôt agressive les méthodes de protection antivirus et Windows et propose en même temps un package de paramètres SRP déjà assemblé qui bloquera également ces dossiers suspects. Sur demande, l'auteur fournit un programme pour convertir ces paramètres de registre en fichiers de stratégie locale.

Si vous préférez utiliser le mécanisme AppLocker avec des paramètres plus flexibles, la solution AaronLocker peut vous aider.

Les éditeurs ne recommandent pas d'utiliser et d'installer des scripts et d'autres programmes à partir d'Internet sans les avoir d'abord étudiés.

Si AppLocker est apparu pendant longtemps et que l'âge de SRP a dépassé 15 ans, alors une alternative relativement récente est WDAC (Windows Defender Application Control). En effet, depuis Security Essentials, l '«antivirus» intégré a acquis de nombreuses fonctionnalités intéressantes. Par exemple, WDAC est le module responsable des politiques d'accès aux applications et aux bibliothèques. Auparavant, il faisait partie de Device Guard (protection d'un ordinateur, y compris en utilisant des technologies de virtualisation), et un peu de sa configuration était décrite dans l'article " Le principe du mode S dans Windows 10 et la configuration de Device Guard de vos propres mains ." Plus de détails sur toutes les subtilités peuvent être trouvés dans la documentation officielle, mais je peux ajouter quelques inconvénients qui le distinguent des solutions classiques comme SRP et AppLocker:

• Il n'y a pas de configuration graphique, tout au long des applets de commande PowerShell.
• Il n'y a pas de paramètres dans la tranche utilisateur, uniquement pour l'ordinateur.
• La configuration est assez inhabituelle - un fichier xml est préparé, qui est ensuite converti en binaire et distribué aux ordinateurs.

Mais il est possible de configurer l'application dans une tranche: par exemple, si vous souhaitez donner à cmd.exe l'accès à votre script, et non à un virus tiers, cela peut être implémenté. De plus, la politique peut être appliquée avant de démarrer le système à l'aide d'UEFI.

Verrou Chrome via WDAC.

En général, en raison de la configuration douloureuse, l'impression était que WDAC n'était plus positionné seul pour gérer les ordinateurs, mais comme un outil qui vous permet de vous intégrer à des systèmes MDM centralisés comme Microsoft Intune . Mais en même temps, le développement du bon vieux SRP a été interrompu dans Windows 10 1803.

Si nous parlons de Windows Defender, vous ne pouvez pas vous empêcher de mentionner Credential Guard et Remote Credential Guard.

Le premier outil utilise à nouveau la virtualisation, démarrant le composant LSA (Local Security Authority) dans un processus isolé du système d'exploitation, ce qui complique grandement le processus de vol de hachages de mots de passe et de tickets Kerberos. En savoir plus sur la technologie dans la documentation officielle. Pour que le processeur fonctionne, il doit prendre en charge la virtualisation et le système doit avoir le démarrage sécurisé activé et le module TPM pour lier les informations d'identification à l'équipement. Vous pouvez activer Credential Guard via la stratégie de groupe Configuration ordinateur - Modèles d'administration - Système - Device Guard - Activer la sécurité basée sur la virtualisation.

Activation de Credential Guard.

Le deuxième outil sert à protéger les informations d'identification transmises (en particulier l'administrateur!) Pour la connexion à distance, par exemple, via le même RDP. Auparavant, le mécanisme du mode administrateur restreint était proposé à ces fins, mais il limitait la connexion à un seul serveur. Une fois connecté au serveur, il était impossible d'utiliser uniquement les ressources réseau, les droits d'administrateur étaient appliqués à un seul serveur à la fois sur le compte Système local.

Remote Credential Guard vous permet de transférer des informations d'identification de la machine locale vers un serveur distant sans entrer de mot de passe explicite, ce qui, en plus d'une sécurité avancée, offrira également la commodité de la connexion aux serveurs (SSO). Vous pouvez en lire plus dans la documentation , mais j'ajouterai que pour que le mécanisme fonctionne, il suffit d'activer sa prise en charge sur le serveur - par exemple, via le registre avec la commande:

 reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 

Et puis connectez-vous au serveur avec la commande:

 mstsc.exe /remoteGuard 

Maintenant, les informations d'identification sont sécurisées et le serveur est assez sécurisé. Certes, dans le matériel, je n'ai pas consciemment abordé les questions de protection contre un hébergeur malveillant, mais ici, cela se résume à une chose en général - au chiffrement du disque.