Il s'agit de la dernière tranche de «Mesures de sécurité efficaces et simples pour les serveurs Web». Le personnage principal cette fois est Linux, c'est-à-dire les mesures de sécurité du système d'exploitation.
À ce jour, 70% des services Web dans le monde utilisent Linux. Cela signifie que Linux est déjà largement utilisé. L'augmentation du nombre d'utilisateurs signifie que les vulnérabilités Linux seront découvertes plus tôt.
En effet, au cours des cinq dernières années environ, il est également vrai que nous avons vu beaucoup de noyaux Linux exposés à de sérieuses vulnérabilités CVE.
Mais je ne pense pas que ce soit une mauvaise chose. Puisque Linux lui-même est open source, toutes les vulnérabilités CVE trouvées seront corrigées immédiatement. Je pense que c'est une incarnation d'une écologie vivante.
Pour assurer la sécurité de votre serveur Linux, nous devons nous-mêmes maintenir de bonnes pratiques de sécurité.
Vous pouvez éviter les dernières vulnérabilités en mettant fréquemment à jour votre noyau Linux et vos packages.
J'utilise généralement une version stable de Linux Distro (Ubuntu LTS, Debian Stable, CentOS, etc.) qui suppose la stabilité, le noyau ne met à jour que de petites versions, et il n'y a pas de mise à niveau directe vers le dernier noyau, donc le noyau Ne vous inquiétez pas des bogues causés par les mises à jour ou des problèmes de compatibilité.
Mise à jour du système ou du package:
Debian/Ubuntu
apt-get update && apt-get upgrade -y && apt-get autoremove -y && apt-get clean -y
Ou:
apt update && apt upgrade -y && apt autoremove -y && apt clean -y
CentOS
yum update -y && yum upgrade -y
Bien sûr, vous pouvez également profiter des mises à jour automatiques sur diverses distributions Linux.
La sécurité SSH est sans doute l'une des mesures de sécurité Linux les plus importantes. La plupart des cas de piratage de serveurs Linux sont dus à un mot de passe SSH fissuré.
La première chose à faire pour assurer la sécurité de votre serveur Linux est de garantir SSH.
Habituellement, beaucoup diraient que Fail2ban est utilisé pour la protection SSH afin d'empêcher les mots de passe SSH d'être détruits. Cependant, il s'est avéré qu'un intrus illégal a utilisé beaucoup d'IP proxy pour pénétrer en SSH à peu près. En conséquence, Fail2ban ne peut plus être efficacement protégé.
Par conséquent, l'utilisation de Fail2ban pour protéger SSH n'est pas particulièrement efficace et n'est pas recommandée. Inversement, Fail2ban occupe également de nombreuses règles iptables, ce qui a un impact sur les performances d'iptables.
Alors, comment protégez-vous SSH? Nous recommandons les méthodes suivantes:
La fissuration par force brute dans SSH est essentiellement tentée avec un dictionnaire cryptographique faible. Par conséquent, j'ai dû changer le mot de passe SSH en un mot de passe plus fort.
Habituellement, le mot de passe est changé en 12 caractères ou plus, et les nombres sont ajoutés avec des symboles spéciaux. Cela empêche grandement le mot de passe d'être fissuré grossièrement.
Comment changer votre mot de passe:
passwd root
Les scanners malveillants pour SSH analysent généralement uniquement le port 22.
Vous pouvez donc empêcher cette partie du scanner malveillant en changeant simplement le port par défaut de SSH en un autre port.
Comment changer le port par défaut:
vim /etc/ssh/sshd_config
Port 22322 # <---- Veuillez sélectionner votre port préféré
iptables -A INPUT -p tcp --dport 22322 -j ACCEPT
/etc/init.d/ssh restart
Vous pouvez utiliser un certificat SSH pour vous connecter afin d'éviter que votre mot de passe SSH ne soit piraté par Brute Force. Parce que je n'ai pas du tout de mot de passe. Comment craquer sans mot de passe?
Ici, le générateur de certificats de PuTTY est utilisé pour générer les clés publiques et privées et les stocker après génération.
Ici, on suppose que la clé publique a été téléchargée dans "/etc/ssh/key/public.key".
Ensuite, définissez la clé publique sur les autorisations système appropriées:
chmod 700 /etc/ssh/key
chmod 600 /etc/ssh/key/public.key
Ouvrez le fichier de configuration SSH:
vim /etc/ssh/sshd_config
Modifiez les paramètres suivants:
......
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile /etc/ssh/key/public.key
PermitEmptyPasswords no
AllowTcpForwarding no
X11Forwarding no
PasswordAuthentication no
......
/etc/init.d/ssh restart
Il s'agit de la connexion SSH la plus sécurisée. C'est encore plus sécurisé que la connexion par certificat SSH.
Le certificat SSH peut être compromis, mais la façon dont seule l'adresse IP spécifiée peut se connecter à SSH est pratiquement incassable.
Cependant, uniquement si vous avez un serveur proxy fixe et que les mesures de sécurité du serveur proxy sont solides.
Personnellement, j'utilise des grilles de protection pour me connecter à mon réseau avant d'accéder à Internet. Mon adresse IP d'exportation est donc fixe.
Ainsi, tous mes serveurs sont limités à mon IP de sortie pour les connexions SSH.
Nous vous recommandons de définir deux adresses IP pour votre serveur proxy en tant que liste blanche. Un des serveurs proxy comme sauvegarde. Nous recommandons également que les deux serveurs proxy se trouvent dans des régions différentes.
Définir la liste blanche:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j ACCEPT
iptables -A INPUT -s xxx.xxx.xxx.xxx -p TCP --dport 22322 -j ACCEPT
iptables -A INPUT -p tcp --dport 22322 -j DROP
Enregistrer les paramètres iptables (Debian / Ubuntu):
/etc/init.d/netfilter-persistent save
/etc/init.d/netfilter-persistent reload
Même dans PuTTY, les fichiers PuTTY téléchargés sur de nombreux sites Web non officiels ont une porte dérobée qui peut voler illégalement le mot de passe SSH d'un utilisateur.
Normalement, le port utilisé par le serveur Web est fixe. Par exemple, port HTTP 80 ou port HTTPS 443. Autoriser uniquement les connexions à ces ports empêche la survenue d'attaques inconnues.
Il convient de noter en particulier ici le port DNS. Tout le monde sait que DNS utilise le protocole UDP, mais UDP n'a pas les capacités de rétention de connectivité du protocole TCP. Par conséquent, ouvrez le port 53 pour une résolution DNS appropriée.
Cependant, à part la résolution DNS, les serveurs Web classiques ne nécessitent pas le protocole UDP. Donc, pour éviter les attaques DDoS, je bloque généralement tous les protocoles UDP. Cependant, il ne protège pas contre toutes les attaques DDoS. J'expliquerai comment se protéger contre les attaques DDoS dans un prochain article.
Utilisez iptables pour limiter les ports:
iptables -A INPUT -i lo -j ACCEPT # <-Autoriser l'interface de bouclage local (c'est-à-dire effectuer un accès local à la machine locale) iptables -A INPUT -m state --state ESTABLISHED, RELATED -j ACCEPT # <-Autoriser le passage des connexions établies ou liées iptables -A OUTPUT -j ACCEPT # <-Autoriser tous les accès sortants locaux iptables -A INPUT -s xxx.xxx.xxx.xxx -p TCP --dport 22322 -j ACCEPT # <-Autorise uniquement l'adresse IP spécifiée à se connecter au port SSH iptables -A INPUT -p tcp --dport 80 -j ACCEPT #<-- HTTP iptables -A INPUT -p tcp --dport 443 -j ACCEPT #<-- HTTPS iptables -A INPUT -p udp --dport 53 -j ACCEPT #<-- DNS iptables -A INPUT -j REJECT # <-Interdit l'accès à d'autres règles non autorisées iptables -A FORWARD -j REJECT # <-Interdit l'accès à d'autres règles non autorisées
Ceci conclut le didacticiel de la série «Mesures de sécurité efficaces et simples pour les serveurs Web».
Fondamentalement, vous pouvez protéger votre serveur Web en suivant les mesures de sécurité que j'ai introduites.
Cependant, afin d'assurer une sécurité à 100% des serveurs, il est également nécessaire de sensibiliser à la sécurité des serveurs personnels. Vous devez toujours être prêt à faire face aux futures menaces de sécurité.
c'est tout.
Recommended Posts