Le cloud computing a radicalement changé le scénario du serveur. De nombreuses plates-formes fournissent des serveurs cloud Linux gratuits et vous pouvez déployer vos serveurs Linux en quelques minutes via ces plates-formes cloud.
Lorsque vous lancez un nouveau serveur, en particulier s'il est visible sur Internet, il sera immédiatement disponible pour les malfaiteurs qui parcourent les serveurs exposés à la recherche de mauvaises configurations et de vulnérabilités grâce à leurs scripts de bot automatisés.
Il y a quelques choses que vous devez faire après avoir installé le serveur Linux pour vous assurer que votre serveur n'est pas compromis.
Voici une capture d'écran de ce que Fail2ban a vu récemment sur l'un de mes serveurs.
212 tentatives de connexion erronées et 6 adresses IP bloquées. Tout le trafic provenant de personnes non autorisées ou de scripts essayant de se connecter à mon serveur.
Quelques premières étapes cruciales vous aideront à protéger vos nouvelles versions de serveur contre tout compromis.
Choses recommandées à faire après l'installation d'un serveur Linux pour renforcer la sécurité
J'ai examiné ici deux des distributions de serveurs Linux les plus populaires :Ubuntu et CentOS/Red Hat. Veuillez vérifier quel Linux vous utilisez.
La plupart des conseils sont génériques ici et devraient être applicables à d'autres Linux, sauf mention spécifique.
Voici les éléments que je vous recommande de vérifier pour assurer la sécurité de votre serveur Linux. J'ai fourni des étapes individuelles, mais si vous voulez le faire rapidement, J'ai également créé un script que vous pouvez exécuter rapidement sur tout nouveau serveur que vous déployez .
1. Assurez-vous qu'un utilisateur non root est configuré
Root est tout-puissant et vous n'avez pas besoin des autorisations root tout le temps.
root est également un nom d'utilisateur valide sur presque tous les systèmes Linux. Cela signifie que s'il est activé pour l'authentification à distance, la moitié du travail de l'attaquant, l'obtention d'un nom d'utilisateur valide, est effectuée.
De plus, si un attaquant peut accéder en tant que root, aucune autre autorisation n'est requise pour faire quoi que ce soit sur le système.
Pour ces raisons, il est préférable de se connecter en tant qu'utilisateur non root et de désactiver la connexion root pour l'accès à distance à l'aide de SSH (expliqué plus loin).
Comment faire ?
Je suppose que vous êtes connecté en tant que root sur votre système.
Ajoutez un nouvel utilisateur avec la commande useradd. Remplacez
useradd <username>Configurez un mot de passe avec la commande passwd pour l'utilisateur nouvellement ajouté :
passwd <username>2. Assurez-vous que l'utilisateur non root dispose de l'autorisation sudo
Étant donné que vous vous connecterez à ce compte à distance à l'aide de Secure Shell (SSH), vous souhaiterez pouvoir effectuer des activités privilégiées nécessitant un accès root. Cela signifie que le compte doit avoir des autorisations sudo.
Comment faire ?
Le processus de création d'un utilisateur sudo sur Ubuntu et CentOS est similaire, mais le groupe auquel vous ajouterez l'utilisateur est différent.
Vous devez être connecté en tant que root pour effectuer cette étape.
Sur CentOS et Red Hat , la wheel group est le groupe standard utilisé pour donner aux utilisateurs des autorisations sudo. Ajoutez l'utilisateur à ce groupe avec la commande usermod :
usermod -aG wheel <username>
Ubuntu utilise le sudo groupe pour gérer les utilisateurs sudo.
usermod -aG sudo <username>3. Activer l'authentification SSH basée sur une clé
Il est important d'activer l'authentification par clé pour SSH afin qu'elle fonctionne lorsque nous désactivons l'authentification par mot de passe.
Les mots de passe piratés, forcés ou compromis sont un moyen très courant pour les mauvais acteurs d'accéder aux systèmes. Le spear phishing, un spam extrêmement ciblé qui incite un utilisateur peu méfiant à fournir des informations d'identification, n'est qu'une méthode courante d'obtention d'informations d'identification.
Si quelqu'un obtient votre nom d'utilisateur et votre mot de passe sur un système où l'authentification par clé est activée et l'authentification par mot de passe est désactivée pour l'accès à distance via SSH, ce mot de passe volé ne leur donnera plus accès à ce serveur.
En activant l'authentification basée sur une clé et dans une étape ultérieure en désactivant l'authentification basée sur un mot de passe, vous avez considérablement réduit vos chances que SSH soit utilisé contre vous. C'est l'un des moyens élémentaires de sécuriser le serveur SSH.
Comment faire ?
Vous avez déjà activé SSH sur votre serveur, je suppose. Ce que vous devez faire est de générer des clés SSH sur votre ordinateur personnel (d'où vous vous connecterez au serveur).
Une fois que vous avez les clés SSH, vous devez ajouter la clé publique aux clés autorisées sur notre serveur pour l'utilisateur non root.
Attention ! Ne perdez pas les clés ssh de votre ordinateur personnel. Faites une sauvegarde de ces clés. Si vous désactivez ultérieurement l'authentification par mot de passe et que vous perdez les clés SSH, vous ne pourrez plus accéder à votre propre serveur.
4. Assurez-vous que SSH est autorisé via le pare-feu ufw
Avant d'activer le pare-feu sur votre système, vous devez vous assurer que SSH est autorisé. Sinon, vous risquez de ne pas pouvoir accéder à votre système si vous y accédez à distance.
Comment faire ?
Ubuntu utilise un pare-feu non compliqué (ufw) et CentOS/Red Hat utilise firewalld.
Sur CentOS/Red Hat , utilisez la commande firewall-cmd :
sudo firewall-cmd --zone=public --add-service=ssh --permanentSur Ubuntu, utilisez la commande ufw comme ceci :
sudo ufw allow ssh5. Activer le pare-feu (uniquement après avoir autorisé SSH)
Un pare-feu garantit que seul le trafic que vous autorisez spécifiquement peut circuler sur votre serveur. Si un acteur malveillant reçoit un logiciel malveillant sur votre serveur et tente de le faire communiquer via un port non autorisé, ou si un service est accidentellement activé, il ne peut pas être utilisé pour compromettre votre serveur ou le compromettre davantage.
Comment faire ?
Sur les systèmes CentOS/Red Hat, activez le service firewalld systemd :
sudo systemctl start firewalld
sudo systemctl enable firewalldSur Ubuntu, utilisez cette commande :
sudo ufw enable6. Configurer SSH pour ne pas afficher la bannière
L'un des moyens par lesquels un attaquant peut compromettre votre serveur consiste à travers des bogues dans le logiciel exécutant vos services. Une bannière peut afficher des informations sur la version d'OpenSSH ou du système d'exploitation que vous utilisez. Ça ne sert à rien de donner des informations aux méchants. Faites-les travailler pour cela !
Comment faire ?
C'est le comportement par défaut dans CentOS/Red Hat pas pour afficher une bannière afin qu'aucune action ne soit nécessaire.
Sur Ubuntu, vous pouvez utiliser :
sudo echo "DebianBanner no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf7. Désactiver tous les transferts SSH
Bien qu'il ne soit pas rare que les administrateurs utilisent le transfert SSH pour chiffrer le trafic qui pourrait autrement transmettre du texte clair, si vous ne l'utilisez pas, vous devez le désactiver. Le transfert peut être utilisé par un acteur malveillant pour chiffrer le trafic afin qu'il soit plus difficile pour vous de le voir, ou pour faire passer le trafic qui serait autrement bloqué en utilisant un port et un service autorisés.
Comment faire ?
Sur CentOS/Red Hat, un ajoutez ce qui suit à /etc/ssh/sshd_config :
DisableForwarding yes
Sur Ubuntu, ajouter DisableForwarding yes au 10-my-sshd-settings.conf fichier :
sudo echo "DisableForwarding yes" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf8. Désactiver la connexion root via SSH
Il y a un utilisateur root sur presque tous les systèmes Linux. Les risques d'autoriser ce compte à utiliser SSH sont doubles.
- Le nom d'utilisateur est connu et fréquemment essayé par des personnes malveillantes.
- Si un attaquant accède en tant que root, il a un accès complet au système.
La désactivation de l'utilisation du compte root pour les connexions SSH annule les deux risques.
Comment faire ?
Sur CentOS/Red Hat , recherchez la ligne PermitRootLogin yes dans /etc/ssh/sshd_config et changez-le en :
PermitRootLogin no
Sur Ubuntu, ajoutez PermitRootLogin no au 10-my-sshd-settings.conf fichier :
sudo echo "PermitRootLogin no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf9. Désactiver l'authentification SSH basée sur un mot de passe
Avant de désactiver l'authentification par mot de passe dans SSH, assurez-vous que l'authentification par clé est configurée et testée comme indiqué à l'étape 3.
La désactivation de l'authentification par mot de passe empêche les acteurs malveillants qui tentent de deviner votre mot de passe ou qui vous ont socialement incité à saisir vos informations d'identification ou à les voler par quelque moyen que ce soit d'accéder à votre serveur à l'aide de SSH.
Un attaquant doit avoir vos clés publiques et privées pour accéder à votre serveur.
Comment faire ?
Sur CentOS/Red Hat , recherchez la ligne PasswordAuthentication yes dans /etc/ssh/sshd_config et changez-le en :
PasswordAuthentication no
Sur Ubuntu , ajoutez PasswordAuthentication no au 10-my-sshd-settings.conf fichier :
sudo echo "PasswordAuthentication no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf10. Ignorer les rhosts
rhosts est associé à rsh, un ancien protocole remplacé par Secure Shell. Si un utilisateur tente de créer un rhosts malveillant fichier, ce paramètre l'ignore explicitement.
Comment faire ?
Sur CentOS/Red Hat , recherchez la ligne #IgnoreRhosts yes dans /etc/ssh/sshd_config et changez-le en :
IgnoreRhosts yes
Sur Ubuntu , ajoutez IgnoreRhosts yes au 10-my-sshd-settings.conf fichier :
sudo echo "IgnoreRhosts yes" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf11. Installez fail2ban et configurez-le pour protéger SSH
Fail2ban garde un œil sur les fichiers journaux des services configurés comme SSH et empêche les adresses IP des utilisateurs malveillants de se connecter à votre serveur après un nombre défini de tentatives pendant une durée définie.
Si un attaquant fait plus de 5 tentatives infructueuses sur une période de trois heures, son adresse IP sera bloquée pendant 12 heures, par exemple.
Fail2ban peut également être configuré pour protéger d'autres services, tels que les sites Web alimentés par le serveur Web nginx ou le serveur Web Apache.
Comment faire ?
Vous pouvez suivre notre guide détaillé sur l'utilisation de Fail2Ban.
12. Configurer les mises à jour de sécurité automatiques (pour Red Hat et CentOS)
Comme mentionné précédemment, un service obsolète avec un exploit peut permettre à un attaquant d'accéder à votre serveur sans même avoir à se connecter si la vulnérabilité est suffisamment grave ! Il est crucial d'appliquer rapidement les mises à jour de sécurité pour réduire ce risque.
Comment faire ?
Pour une installation de serveur Ubuntu par défaut, les mises à jour de sécurité automatiques sont activées, aucune action n'est donc nécessaire concernant les mises à jour.
Pour configurer les mises à jour automatiques sur CentOS/Red Hat, vous allez installer une application appelée dnf-automatic et activer une minuterie à l'aide des commandes ci-dessous :
sudo dnf upgrade
sudo dnf install dnf-automatic -y
sudo systemctl enable --now dnf-automatic.timerVous pouvez vérifier le minuteur en exécutant :
sudo systemctl status dnf-automatic.timerRecherchez "chargé" sous la ligne Chargé :et "actif" sous la ligne Actif :.
Il peut y avoir plus ou moins d'étapes en fonction de vos goûts personnels et de ce que vous configurez généralement vos serveurs.
Script bonus :10 premières secondes sur un serveur Linux
Comme promis, voici le script que j'ai écrit qui effectue toutes les étapes ci-dessus que j'ai mentionnées après avoir configuré et configuré un utilisateur non root pour l'authentification par clé.
Le script peut être exécuté à la fois sur Ubuntu 20.04 et CentOS/Red Hat 8.
Veuillez noter que vous ne devez pas exécuter aveuglément des scripts shell aléatoires téléchargés sur Internet, quelle que soit la confiance que vous accordez à la source du script. Vous devez lire le script et essayer de comprendre ce qu'il fait.
L'intégralité du script est open source et accessible à tous et peut être consultée ici. Vous pouvez télécharger, lire puis exécuter le script bash.
Voici une capture d'écran après une exécution sur le serveur Ubuntu 20.04.
Voyez avec quelle facilité vous pouvez effectuer certaines étapes de base pour sécuriser vos nouvelles versions de serveur dans CentOS, Red Hat ou Ubuntu en exécutant un seul script !
Vous pouvez également nous faire part de vos commentaires sur le script ou demander des fonctionnalités.
Conclusion
Ce ne sont que quelques-unes des vérifications de sécurité les plus élémentaires, mais vous devez les effectuer après l'installation de votre serveur Linux.
Faire ces choses manuellement sur un certain nombre de serveurs peut être pénible et prendre inutilement du temps. C'est ici que vous pouvez tirer parti des scripts et utiliser mon script "10 premières secondes sur un serveur Linux" ou créer le vôtre.
Voici quelques-unes de mes recommandations. Et toi? Avez-vous quelque chose à ajouter à cette liste ? Fournissez votre suggestion dans la section des commentaires.
L'auteur Ted LeRoy est un architecte de la sécurité d'entreprise qui fournit une variété d'informations et de conseils sur la sécurité physique aux entreprises.