Renforcement simple du serveur | Journal Linux – Monter un serveur MineCraft

De nos jours, il est plus important que jamais de renforcer la sécurité sur vos serveurs, mais si vous regardez plusieurs durcissements officiels guides, ils lisent comme s'ils avaient été écrits pour Red Hat 2005. C'est parce qu'ils étaient écrit pour Red Hat en 2005 et mis à jour ici et là au fil des ans. Je suis tombé sur l'un de ces guides quand je faisais référence à certains repères de durcissement officiels pour un audit PCI et réalisé si d'autres débutants en administration de serveurs Linux devaient parcourir le même guide, ils seraient probablement submergés par toutes les étapes obscures. Pire encore, ils passeraient probablement des heures effectuer des réglages sysctl obscurs et se retrouver avec un ordinateur qui n'était pas plus protégé contre une attaque moderne. Au lieu de cela, ils auraient pu passer un quelques minutes effectuant quelques étapes de durcissement simples et se sont retrouvés avec un ordinateur plus sécurisé à la fin. Donc, dans cet article, je décris un quelques étapes de durcissement qui offrent le meilleur rapport qualité-prix. Ces conseils ne devrait prendre que quelques minutes, mais pour cet effort, vous devriez obtenir un système beaucoup plus sécurisé à la fin.

Durcissement classique Avant de parler de quelques recommandations de durcissement, je me suis dit que je commencerais en mettant en évidence certaines de ces étapes de sécurité classiques, vous êtes probablement à voir dans ces anciens guides de durcissement. Maintenant, cela ne veut pas dire que tout de ces étapes sont nécessairement de mauvais conseils, c'est juste que dans de nombreux cas les conseils se réfèrent aux systèmes obsolètes ou décrivent les étapes que les distributions de serveurs Linux modernes ont pris par défaut pendant des années.

Par exemple, de nombreux guides de durcissement passent beaucoup de temps à se concentrer sur tcpwrappers, un service Linux classique qui vous permet de restreindre les adresses IP pouvant accéder à des services particuliers. De nos jours, la plupart des administrateurs utilisent iptables règles de pare-feu pour restreindre l'accès aux ports à la place. Vous serez également conseillé d'activer l'utilisation de mots de passe cachés et de désactiver les shells sur comptes de rôle communs (comme les utilisateurs mail, bind, www et mysql). Bien que ce n'est pas un mauvais conseil, le fait est que toutes les distributions Linux faites cela pour vous hors de la boîte.

Une autre astuce que vous verrez généralement dans un guide de renforcement est de désactiver tous les services inutiles, et en particulier, les guides vous diront de désactiver telnet, diurne, chargen et un certain nombre d'autres inetd obscurs des services qui non seulement n'ont pas été activés par défaut depuis longtemps, mais dans de nombreux cas, ils ne sont même plus installés par défaut. Le fait est que la plupart des distributions de serveurs sont livrées avec tous les services réseau à part de SSH désactivé. En parlant de SSH, maintenant que j'ai parlé un peu quelques conseils de durcissement classiques, permettez-moi de discuter de quelques conseils de durcissement modernes commençant par SSH.

SSH Comme je l'ai mentionné, à peu près tous les serveurs que vous rencontrerez activent SSH par défaut, et il est supposé que vous l’utiliserez pour l’administration à distance. Ici Voici quelques modifications simples que vous pouvez apporter à votre fichier / etc / ssh / sshd_config cela ne prend qu'une seconde mais le rend plus sûr.

Tout d'abord, désactivez les connexions root et assurez-vous que vous utilisez uniquement le protocole SSH 2 (les protocoles précédents ont des vulnérabilités connues). Dans de nombreuses distributions (en particulier de nombreuses images cloud), ces étapes peuvent déjà être effectuées pour vous:

PermitRootLogin non Protocole 2

Beaucoup de gens se concentrent beaucoup trop, à mon avis, sur la force brute SSH attaques quand ils parlent de durcissement du serveur. C'est vrai que si vous mettre un serveur Linux sur Internet, l'une des premières choses que vous voir dans vos journaux est un flux constant de tentatives de force brute SSH. Beaucoup les administrateurs système vont à des longueurs qui, je pense, se situent quelque part entre inefficaces, absurde et exagéré, y compris le déplacement de SSH vers un port aléatoire (sécurité par obscurité) ou en utilisant un système comme fail2ban. Avec fail2ban, votre système lit les tentatives de connexion infructueuses et crée des règles de pare-feu pour bloquer les attaquants après quelques tentatives infructueuses. Cela semble raisonnable en surface, mais a quelques problèmes:

Cela arrête uniquement les attaquants qui ont une seule machine – la plupart ont des botnets et propager des attaques par force brute sur de nombreuses adresses IP.

Si vous avez un mot de passe faible et facilement devinable et un nom d'utilisateur commun, ils pourraient deviner le mot de passe avant que fail2ban ne se déclenche.

Il est risqué de laisser les attaquants effectuer une action qui met à jour les règles de pare-feu de votre système.

Les réseaux internes sont généralement sur liste blanche – les attaquants peuvent toujours utiliser la force brute vous attaquer à partir d'une autre machine compromise sur votre réseau.

Au lieu de suivre toutes ces étapes pour atténuer les attaques par force brute SSH, je vous recommande d'éliminer complètement l'attaque: désactivez l'authentification par mot de passe et utilisez uniquement les clés SSH. Avant toi activez cette option, assurez-vous que tous ceux qui se connectent à cette machine (ou au moins les administrateurs) ont généré et testé la connexion en utilisant les clés SSH, vous ne voudriez pas être verrouillé. Quand tu es prêt, changer la PasswordAuthentication dans votre sshd_config pour:

PasswordAuthentication no

La dernière étape de durcissement rapide de SSH consiste à restreindre la cryptographie suites de chiffrement et algorithmes à utiliser, afin que vous n'utilisiez que ceux qui sont considéré comme sûr par les normes d'aujourd'hui. Je ne suis pas un cryptographe, mais je ne doit pas être un pour regarder les recommandations des cryptographes et copiez-les et collez-les dans ma configuration SSH:

Chiffres [email protected],[email protected], [email protected], aes256-ctr, aes192-ctr, aes128-ctr

KexAlgorithms [email protected], ↪diffie-hellman-group-exchange-sha256

MAC [email protected],[email protected], [email protected],[email protected], ↪hmac-sha2-512,   hmac-sha2-256, hmac-ripemd160,[email protected]

Une fois que tous ces paramètres sont en place, redémarrez le service SSH pour les utiliser.

Renforcement du compte Pour un durcissement général des comptes système, la meilleure recommandation Je peux faire est de désactiver complètement le compte root et d'utiliser seulement sudo. Vous devez également éviter la connexion directe à tout partage comptes, que ce soit c'est le compte root ou un compte de rôle comme un utilisateur qui gère votre application ou serveur Web. En obligeant les utilisateurs à se connecter comme eux-mêmes puis sudo jusqu'aux comptes root ou de rôle, vous fournissez une belle piste d'audit pour qui a fait quoi, et vous simplifiez la révocation de l'accès lorsque les utilisateurs ne plus besoin d'un compte, car les comptes partagés n'auront pas de mot de passe, vous n'avez pas à les changer à chaque fois qu'un membre de l'équipe part; à la place, vous pouvez simplement supprimer le compte de cet utilisateur.

La plupart des distributions incluent actuellement sudo, et certaines aussi désactiver le compte root par défaut ou vous permettre de le désactiver pendant installation. Sinon, vous pouvez simplement modifier votre fichier / etc / shadow et remplacez le mot de passe que vous avez en place pour l'utilisateur root par un * symbole. Assurez-vous simplement que sudo fonctionne en premier avec au moins un pour ne pas vous enfermer.

Lorsque vous utilisez sudo, vous devez suivre quelques méthodes pour vous aider. gardez-le en sécurité. Premièrement, alors que l’utilisation de NOPASSWD règles sudo (règles qui ne vous obligent pas à entrer un mot de passe) sont quelque peu inévitables pour dæmons qui peuvent exécuter des tâches cron comme des tâches de sauvegarde, vous devez restreindre NOPASSWD règles sudo à seulement ces comptes de rôle démon et nécessitent tous de vrais utilisateurs pour taper un mot de passe. Autant que possible, vous devez également suivre le principe du moindre privilège et accorder aux utilisateurs l'accès sudo uniquement aux commandes spécifiques dont ils ont besoin au lieu de leur accorder l'accès à l'exécution toutes les commandes en tant qu'utilisateur particulier (en particulier l'utilisateur root). Enfin, si vous vous trouvez accorder aux utilisateurs l'accès à une commande à usage général pour faire quelque chose de spécifique (comme leur accorder l'accès au service ou systemctl pour pouvoir redémarrer un seul service), pensez à créer un simple shell script qui exécute la commande avec uniquement les paramètres spécifiques que vous souhaitez et en leur accordant l'accès sudo à ce script à la place.

Bien que ces étapes de durcissement ne soient pas les seules choses à faire pour verrouiller votre serveur, ils sont un bon début et devraient prendre seulement quelques minutes. Dans mon prochain article, je vais ajouter une autre série de simples des conseils de renforcement, notamment les étapes de renforcement du client SSH et de renforcement du cloud, et je terminerai avec quelques recommandations générales.

Click to rate this post! [Total: 0 Average: 0]