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:

1. 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.

2. 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.

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

4. 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.