7 mesures de sécurité pour protéger vos serveurs

Avec SSH, tout type d'authentification, y compris l'authentification par mot de passe, est complètement crypté. Toutefois, lorsque les connexions par mot de passe sont autorisées, des utilisateurs malveillants peuvent tenter à plusieurs reprises d’accéder au serveur. Avec la puissance de calcul moderne, il est possible d'accéder à un serveur en automatisant ces tentatives et en essayant les combinaisons successives jusqu'à ce que le bon mot de passe soit trouvé.

La configuration de l'authentification par clé SSH vous permet de désactiver l'authentification par mot de passe. Les clés SSH contiennent généralement beaucoup plus de bits de données qu'un mot de passe, ce qui signifie qu'il y a beaucoup plus de combinaisons possibles qu'un attaquant devrait exécuter. De nombreux algorithmes de clé SSH sont considérés comme insaisissables par le matériel informatique moderne simplement parce qu’ils nécessiteraient trop de temps pour passer en revue les correspondances possibles.

Les clés SSH sont très faciles à configurer et constituent le moyen recommandé de se connecter à distance à tout environnement de serveur Linux ou Unix. Une paire de clés SSH peut être générée sur votre ordinateur et vous pouvez transférer la clé publique sur vos serveurs en quelques minutes.

Pour savoir comment configurer les clés, suivezthis guide. Si vous pensez toujours avoir besoin d'une authentification par mot de passe, envisagez d'implémenter une solution telle quefail2ban sur vos serveurs pour limiter les devinettes de mot de passe.

Les pare-feu sont une partie essentielle de toute configuration de serveur. Même si vos services eux-mêmes implémentent des fonctionnalités de sécurité ou sont limités aux interfaces sur lesquelles vous souhaitez les exécuter, un pare-feu constitue une couche supplémentaire de protection.

Un pare-feu correctement configuré restreindra l'accès à tout sauf aux services spécifiques dont vous avez besoin pour rester ouverts. L'exposition de quelques logiciels seulement réduit la surface d'attaque de votre serveur et limite le nombre de composants vulnérables à l'exploitation.

Il existe de nombreux pare-feu disponibles pour les systèmes Linux, dont certains ont une courbe d'apprentissage plus abrupte que d'autres. En règle générale, toutefois, la configuration du pare-feu ne devrait prendre que quelques minutes et ne devrait se faire que lors de la configuration initiale de votre serveur ou lorsque vous apportez des modifications aux services proposés sur votre ordinateur.

Un choix simple est leUFW firewall. D'autres options sont d'utiliseriptables ou lesCSF firewall.

Utiliser des réseaux privés plutôt que publics pour la communication interne est presque toujours préférable, étant donné le choix entre les deux. Toutefois, étant donné que d'autres utilisateurs du centre de données peuvent accéder au même réseau, vous devez toujours mettre en œuvre des mesures supplémentaires pour sécuriser la communication entre vos serveurs.

L'utilisation d'un réseau privé virtuel est un moyen efficace de définir un réseau privé que seuls vos serveurs peuvent voir. La communication sera entièrement privée et sécurisée. D'autres applications peuvent être configurées pour transmettre leur trafic sur l'interface virtuelle exposée par le logiciel VPN. De cette manière, seuls les services destinés à être consommés par les clients sur Internet public doivent être exposés sur le réseau public.

Utiliser des réseaux privés dans un centre de données doté de cette fonctionnalité est aussi simple que d’activer l’interface lors de la création de votre serveur et de configurer vos applications et votre pare-feu pour utiliser le réseau privé. N'oubliez pas que les réseaux privés du centre de données partagent un espace avec d'autres serveurs utilisant le même réseau.

En ce qui concerne le VPN, la configuration initiale est un peu plus complexe, mais la sécurité accrue en vaut la peine dans la plupart des cas d'utilisation. Chaque serveur sur un réseau privé virtuel doit disposer des données de sécurité et de configuration partagées nécessaires pour établir la connexion sécurisée installée et configurée. Une fois le VPN opérationnel, les applications doivent être configurées pour utiliser le tunnel VPN. Pour en savoir plus sur la configuration d'un VPN pour connecter en toute sécurité votre infrastructure, consultez nosOpenVPN tutorial.

L'établissement d'une autorité de certification et la gestion des certificats pour vos serveurs permettent à chaque entité de votre infrastructure de valider l'identité des autres membres et de chiffrer leur trafic. Cela peut empêcher les attaques intercepteurs lorsqu'un attaquant imite un serveur de votre infrastructure pour intercepter le trafic.

Chaque serveur peut être configuré pour faire confiance à une autorité de certification centralisée. Ensuite, tout certificat signé par l'autorité peut être implicitement approuvé. Si les applications et les protocoles que vous utilisez pour communiquer prennent en charge le cryptage TLS / SSL, il s'agit d'un moyen de crypter votre système sans la surcharge d'un tunnel VPN (qui utilise également souvent SSL en interne).

La configuration d'une autorité de certification et la configuration du reste de l'infrastructure à clé publique peuvent nécessiter beaucoup d'effort initial. En outre, la gestion des certificats peut créer une charge administrative supplémentaire lorsque de nouveaux certificats doivent être créés, signés ou révoqués.

Pour de nombreux utilisateurs, la mise en place d'une infrastructure à clé publique à part entière sera d'autant plus utile que leurs besoins en infrastructure augmentent. Sécuriser les communications entre les composants utilisant VPN peut constituer une bonne mesure d’espacement jusqu’à ce que vous atteigniez un point où l’ICP valait les coûts d’administration supplémentaires.

Les serveurs lancent de nombreux processus à des fins internes et pour gérer des clients externes. Chacun de ceux-ci représente une surface d'attaque étendue pour les utilisateurs malveillants. Plus vous utilisez de services, plus il y a de chances que votre logiciel accessible soit vulnérable.

Une fois que vous avez une bonne idée des services réseau en cours d'exécution sur votre ordinateur, vous pouvez commencer à analyser ces services. Voici quelques questions que vous voudrez vous poser:

Ce type d’audit de service doit être une pratique courante lors de la configuration d’un nouveau serveur dans votre infrastructure.

Faire un audit de service de base est incroyablement simple. Vous pouvez découvrir quels services écoutent les ports sur chaque interface en utilisant la commandenetstat. Voici un exemple simple montrant le nom du programme, le PID et les adresses utilisées pour écouter le trafic TCP et UDP:

Vous verrez une sortie qui ressemble à ceci:

Les principales colonnes auxquelles vous devez faire attention sontProto,Local Address etPID/Program name. Si l'adresse est0.0.0.0, le service accepte les connexions sur toutes les interfaces.

Semblable à l'audit de niveau de service ci-dessus, si vous voulez vraiment sécuriser un système, il est très utile de pouvoir effectuer des audits au niveau des fichiers de votre système. Cela peut être effectué périodiquement par l'administrateur ou dans le cadre d'un processus automatisé dans un IDS.

Ces stratégies sont parmi les seuls moyens d’être absolument sûr que votre système de fichiers n’a pas été altéré par un utilisateur ou un processus quelconque. Pour de nombreuses raisons, les intrus souhaitent souvent rester cachés afin de pouvoir continuer à exploiter le serveur pendant une période prolongée. Ils pourraient remplacer les fichiers binaires par des versions compromises. Effectuer un audit du système de fichiers vous indiquera si l’un des fichiers a été modifié, ce qui vous permettra d’avoir confiance en l’intégrité de l’environnement de votre serveur.

L'implémentation d'un IDS ou la réalisation d'audits de fichiers peuvent être un processus assez intensif. La configuration initiale implique d'informer le système d'audit de toutes les modifications non standard apportées au serveur et de définir les chemins à exclure pour créer une lecture de base.

Cela rend également les opérations quotidiennes plus impliquées. Cela complique les procédures de mise à jour car vous devrez revérifier le système avant d'exécuter les mises à jour, puis recréer la base de référence après l'exécution de la mise à jour afin de détecter les modifications apportées aux versions du logiciel. Vous devrez également décharger les rapports vers un autre emplacement afin qu'un intrus ne puisse pas modifier l'audit pour couvrir ses traces.

Bien que cela puisse augmenter votre charge d’administration, la possibilité de vérifier votre système par rapport à une copie réputée bonne est l’un des seuls moyens de s’assurer que les fichiers n’ont pas été modifiés à votre insu. Certains systèmes populaires d'audit / de détection d'intrusions de fichiers sontTripwire etAide.

Isoler vos processus dans des environnements d’exécution individuels augmente votre capacité à isoler tous les problèmes de sécurité pouvant survenir. De la même manière quebulkheads et les compartiments peuvent aider à contenir les brèches de coque dans les navires, la séparation de vos composants individuels peut limiter l'accès d'un intrus à d'autres éléments de votre infrastructure.

Selon le type de confinement que vous choisissez, l'isolement de vos applications peut être relativement simple. En conditionnant vos composants individuels dans des conteneurs, vous pouvez rapidement obtenir une certaine isolation, mais notez que Docker ne considère pas sa conteneurisation comme une fonctionnalité de sécurité.

La configuration d'un environnementchroot pour chaque pièce peut également fournir un certain niveau d'isolation, mais ce n'est pas non plus une méthode d'isolation infaillible car il existe souvent des moyens de sortir d'un environnementchroot. Le transfert de composants vers des machines dédiées constitue le meilleur niveau d'isolation. Dans de nombreux cas, il peut s'avérer le plus simple, mais peut coûter plus cher pour les machines supplémentaires.