Meilleures pratiques de sécurité des serveurs Windows

AVIS DE NON-RESPONSABILITÉ POUR LES CLIENTS DES OPÉRATIONS GÉRÉES

Pour vous assurer que Rackspace a accès à votre serveur en cas de besoin, nous vous demandons de ne pas modifier les configurations suivantes lorsque vous tenez compte des meilleures pratiques de sécurité :

Lors de la connexion à votre serveur, Rackspace Support se connecte en tant qu'utilisateur rack en utilisant la connexion Bureau à distance à l'adresse IP publique sur le port 3389.
La reconstruction de serveurs existants ou la création d'un nouveau serveur à partir d'un instantané nécessite que les connexions administrateur soient activées et que le port 445 ne soit pas bloqué dans le pare-feu Microsoft® Windows®.

Si vous devez modifier ces valeurs, contactez un administrateur de Rackspace pour effectuer les modifications d'une manière qui n'affecte pas notre capacité à vous fournir une FanaticalExperience ®.

Cet article fournit quelques bonnes pratiques de sécurité générales à prendre en compte lorsque vous configurez un serveur Microsoft Windows qui interagit avec l'Internet public. Bien que ces meilleures pratiques s'appliquent à n'importe quel serveur en général, cet article traite spécifiquement des serveurs RackspacePublic Cloud fonctionnant sous Windows.

Utiliser les règles de pare-feu locales

Par défaut, les serveurs Rackspace Public Cloud n'ont pas de dispositif de pare-feu. Pour les serveurs qui interagissent avec l'Internet public sans dispositif de pare-feu, le pare-feu Windows est la seule protection entre les ressources de votre serveur et vos données privées et toute personne ayant accès à une connexion Internet.

Désactivez autant de règles que possible sur le pare-feu. La désactivation des règles signifie que moins de ports sont ouverts et écoutent sur l'interface publique, ce qui limite l'exposition du serveur à quiconque tente d'y accéder.

Pour les ports qui doivent être ouverts, limitez l'accès au serveur en ajoutant des adresses IP à la liste blanche dans ces règles spécifiques. Ajoutez l'adresse IP de votre ordinateur domestique ou de bureau local à la liste blanche, même si votre fournisseur de services Internet (FAI) fournit des adresses IP publiques dynamiques qui changent au fil du temps. Vous pouvez apporter des modifications aux règles de pare-feu selon vos besoins à partir du panneau de configuration du cloud en vous connectant au serveur à distance via la console et en ajoutant une nouvelle adresse IP.

En limitant l'accès au serveur via la liste blanche d'adresses IP, vous pouvez vous assurer que les utilisateurs qui ont besoin d'accéder au serveur l'ont, mais ceux qui n'en ont pas sont bloqués sur ces ports ouverts. Les ports les plus courants qui doivent être ouverts dans le pare-feu Windows pour l'hébergement Web sur un serveur cloud sont les suivants :

Port	Service
80 HTTP	Sites IIS ou application Web
443 HTTPS	Sécuriser les sites IIS ou les applications Web avec SSL

Nous vous recommandons de verrouiller les ports suivants via une liste blanche d'adresses IP sur l'interface publique afin de limiter les attaques par force brute ou les tentatives d'exploitation contre des comptes ou des services couramment nommés sur le serveur :

Port	Description
3389	Connectivité Bureau à distance, pour se connecter à distance au serveur
21 FTP	Pour le transfert sécurisé des données entre les emplacements géographiques locaux et le serveur cloud
990 FTP (Windows)	Pour le transfert sécurisé des données entre les emplacements géographiques locaux et le serveur cloud intégrant un certificat SSL
FTP 5000-5050	Ports passifs pour la communication FTP
SQL 1433	Port par défaut utilisé pour la communication SQL
53 DNS	Port par défaut utilisé pour les requêtes DNS

Considérez quelles données sont disponibles pour les autres via le partage de fichiers. Nous vous déconseillons d'activer le partage de fichiers Windows car les ports ouverts sur le pare-feu (ports445 et 139) exposent le serveur à des tentatives de connexion indésirables.

Certains clients utilisent leurs serveurs pour héberger des logiciels de back-office tels que QuickBooks®, PeachTree, Microsoft Office® (Outlook® pour les sessions Remote Desktop) ou d'autres solutions logicielles tierces. Parfois, les clients souhaitent configurer des lecteurs réseau mappés pour leur permettre de déplacer facilement des données de leurs ordinateurs locaux vers leur serveur cloud au moyen d'une lettre de lecteur sur l'ordinateur local. Cependant, nous ne recommandons pas cette pratique. Votre serveur est aussi sûr que le mot de passe le plus faible.

De plus, faites attention aux logiciels que vous autorisez vos utilisateurs à télécharger et à installer sur votre serveur. Chaque progiciel installé augmente l'exposition de votre serveur aux attaques.

Politique de mot de passe

Que vous ayez ou non provisionné un serveur cloud avec un pare-feu matériel, comme indiqué précédemment, votre serveur est aussi sécurisé que le mot de passe le plus faible qui y a accès. Suivez ces conseils pour les mots de passe :

Utilisez des mots de passe forts d'au moins 12 à 14 caractères comprenant des lettres majuscules et minuscules, des chiffres et des caractères spéciaux (tels que !, #, $ et %). L'attribution de mots de passe simples est extrêmement dangereuse, en particulier pour un serveur cloud disponible sur l'Internet public.
Définissez une date d'expiration pour le mot de passe de chaque utilisateur. Bien qu'il soit peu pratique de devoir se souvenir périodiquement d'un nouveau mot de passe, cette pratique peut rendre vos données plus sûres.

Étant donné que nos processus d'automatisation post-construction dépendent du compte d'utilisateur par défaut de l'administrateur, nous vous déconseillons de modifier ce nom d'utilisateur sur vos serveurs cloud exécutant Windows.

Faites attention à qui a accès au serveur via le compte Administrateur. Si plusieurs utilisateurs ont besoin d'un accès administrateur au serveur, créez plusieurs comptes avec un accès administrateur. Il est plus facile de suivre les utilisateurs dans les fichiers journaux en recherchant un compte utilisateur spécifique que d'essayer de déchiffrer plusieurs entrées de fichier journal sous le compte administrateur.

Plusieurs instances de Event Id 4625 dans le journal de sécurité ou Event Id 1012 dans le SystemLog peut signifier que quelqu'un essaie de pirater votre serveur car ces événements sont liés à des tentatives de connexion infructueuses.

Pour les utilisateurs qui se connectent via une connexion Bureau à distance (RDC), assurez-vous qu'ils se déconnectent du serveur pour libérer toutes les ressources utilisées au lieu de simplement fermer leurs fenêtres RDC, ce qui laisse la session ouverte sur le serveur.

Active Directory

Nous déconseillons généralement d'exécuter Active Directory sur un serveur cloud car la seule protection contre les intrusions est le pare-feu Windows et Active Directory introduit des problèmes dans un environnement de serveur cloud. Active Directory est généralement mieux utilisé dans un environnement de serveur dédié où les serveurs sont placés derrière des pare-feu physiques et connectés via un tunnel VPN via ce dispositif de pare-feu.

Rackspace prend en charge un réseau privé virtuel (VPN) uniquement s'il passe par un pare-feu matériel dans une solution appelée RackConnect. Il est plus facile d'implémenter cette configuration de pare-feu physique avant de créer des serveurs car, au moment où cet article a été écrit, le processus qui connecte le pare-feu et les serveurs est automatisé pendant le processus de construction. Les pare-feu physiques ne sont pas provisionnés aussi rapidement que les serveurs cloud et doivent être demandés via nos équipes hybrides. Pour plus d'informations sur les pare-feux physiques et RackConnect, voir https://www.rackspace.com/cloud-connectivity/rackconnect/.

Si vous installez Active Directory sur un serveur cloud, nous vous recommandons d'exécuter deux contrôleurs de domaine au cas où l'un échouerait (la création d'image n'est actuellement pas disponible pour les contrôleurs de domaine). Nous vous recommandons également de verrouiller le DNS pour empêcher les attaques par amplification DNS.

Instances SQL Server

Pour les serveurs exécutant Microsoft SQL Server®, verrouillez le port SQL 1433 pour écouter uniquement sur l'interface interne, de préférence en écoutant uniquement les connexions à partir d'une liste d'adresses IP connues d'autres serveurs ayant besoin d'accéder à SQL Server sur le serveur. Vous pouvez autoriser le port SQL 1433 à écouter sur l'interface publique, mais vous devez limiter cette règle aux seules adresses IP des ordinateurs sur lesquels les développeurs se connectent aux bases de données sur le serveur.

Si vous ne limitez pas ces connexions au serveur, le port 1433 est exposé et les hackers extérieurs le feront tenter une attaque par force brute sur le serveur via ce port. Ces types d'attaques entraînent un trafic réseau élevé, ralentissent les performances du serveur et provoquent même des pannes de sites si un compte important est verrouillé. En limitant l'accès à ce port, vous atténuez ces problèmes avant qu'ils ne surviennent.

Pour les serveurs exécutant les éditions SQL Server Standard ou SQL Server Web, nous vous recommandons de configurer des plans de maintenance pour vider les données des fichiers de base de données en direct dans des fichiers plats que vous pouvez sauvegarder hors du serveur et pour nettoyer les sauvegardes afin qu'elles ne remplissent pas votre disque dur.

Mises à jour Windows

Assurez-vous que les mises à jour Windows sont activées et tenez compte de l'état de votre serveur. Assurez-vous que votre système d'exploitation Windows est corrigé. Le Patch Tuesday, qui a lieu le deuxième mardi de chaque mois en Amérique du Nord, est le jour où Microsoft publie régulièrement des correctifs de sécurité. Les clients doivent décider de la meilleure façon de mettre en œuvre une stratégie de correctifs qui maintienne leurs serveurs à jour. Par défaut, les serveurs Rackspace Cloud vérifient les mises à jour entre 2h00 et 4h00 tous les jours.

Sauvegardes du serveur

Mettre en place un certain type de plan de reprise après sinistre. Une option que nous proposons consiste à créer des images de serveur cloud la nuit et à les écrire dans vos conteneurs Cloud Files avec une rétention par défaut de sept jours. Vous prenez un instantané du serveur et stockez l'image dans Cloud Files pour l'utiliser dans la création de nouvelles instances de serveur ou la reconstruction du serveur existant à partir de cette image.

Nous proposons également une sauvegarde au niveau des fichiers via Cloud Backups. Nous ne recommandons pas de sauvegarder l'intégralité de C: lecteur parce que les fichiers actifs qui sont verrouillés entraînent la fin de la tâche de sauvegarde avec des erreurs. De plus, les fichiers système Windows sont contenus dans les images de base que nous fournissons ou dans toute image personnalisée prise des serveurs, vous n'avez donc pas besoin de sauvegarder ces données quotidiennement. Nous vous recommandons de sauvegarder le C :\inetpub (IIS) et toutes les autres données utilisateur qui doivent être sauvegardées. De plus, si vous avez configuré des plans de maintenance SQL Server pour vider les données en direct dans des fichiers plats pour les sauvegardes, nous vous recommandons d'inclure également ces répertoires dans la sauvegarde.

Vérifiez les tâches de sauvegarde pour vous assurer qu'elles se terminent avec succès et que les sauvegardes sont valides. Créez une nouvelle instance de serveur à partir d'une image pour vous assurer que l'image est valide et restaurez un fichier à partir de Cloud Backups pour vérifier que les données sauvegardées sont restaurées.

Remarque :tous les serveurs ne peuvent pas bénéficier de Cloud Images. Plus précisément, vous ne pouvez pas imager les serveurs qui utilisent Boot from Volume configurations. De plus, bien qu'une image de serveur puisse être utile, les images ne doivent jamais être considérées comme la seule source de sauvegarde car le processus d'image ne vérifie pas l'intégrité des fichiers. Rackspace recommande fortement les sauvegardes au niveau des fichiers pour vos données les plus importantes. Ainsi, vous devriez envisager la meilleure solution de reprise après sinistre pour votre entreprise. Vous pouvez passer en revue les différences entre les images de serveur et la sauvegarde dans le cloud dans cet article :Rackspace Cloud Backup vs Cloud Server Image Backups

Code

La dernière surface d'attaque exposée à Internet est le code. Vous et vos développeurs devez vous assurer que votre code applique une authentification et une autorisation appropriées. Par exemple, vous ne devez pas autoriser l'exécution d'une application Web avec des privilèges de niveau administrateur. L'autorisation de fichier doit être soigneusement définie et toutes les entrées sur l'application doivent avoir la meilleure validation possible pour empêcher les pirates d'exploiter l'application Web et de prendre le contrôle du serveur.

Les sites suivants fournissent des informations sur l'amélioration de la sécurité ASP.NET :

https://www.asp.net/web-forms/pluralsight
https://www.iis.net/configreference/system.webserver/security/requestfiltering
https://blogs.iis.net/wadeh/archive/2008/12/18/filtering-for-sql-injection-on-iis-7-and-later.aspx

Conclusion

Selon le cas d'utilisation, les clients peuvent avoir d'autres besoins plus spécifiques à résoudre lorsqu'ils utilisent notre service de serveurs cloud pour répondre à leurs besoins d'hébergement. Cependant, ces recommandations générales sont un bon début lorsque vous envisagez la sécurité lors de la création de serveurs Windows, cloud ou autres.