Le minimum vital pour sécuriser son serveur Linux

Un verrou, synonyme de confidentialité

Un verrou, synonyme de confidentialité.

Salut à toi chez internaute,

Aujourd’hui je sais ce qui ta poussé à lire cet article, cette profonde angoisse de voir l’intimité de son serveur Linux violé. Administrant mon serveur Debian depuis un an, je ne suis certes pas encore un professionnel, mais j’ai tout de même acquis quelques réflexes afin de protéger ma parcelle d’Internet.

Tout d’abord, il faut ‘cacher’ nos propres accès à notre serveur, je parle bien évidemment des protocoles FTP, SSH voir VNC ou RDP si vous les utilisez. Les ports d’accès de ces protocoles sont évidemment bien connus de tous ( le port 22 pour SSH ou le 21 pour FTP par exemple ). Un des risques auxquels sera confronté votre serveur sera les scans de plage d’ip lancés automatiquement par des scripts malveillants. Une fois votre serveur détecté, il risque de subir multiples tentatives de bruteforce voir d’exploits envers votre serveur FTP qui n’aurais pas été à jour.
Un moyen très simple existe afin de diminuer drastiquement le risque de hack par cette manière, c’est le fait de changer les ports par defauts de vos accès SSH & FTP par des ports de valeurs élevés. Ainsi une tentative de connexion par SSH sur le port 22 de votre serveur sera automatiquement refusé. Le port que vous aurez choisi agit en quelques sortes comme un 2ème mot de passe.
Toujours en rapport aux ports reseaux, un script Iptables pourra vous permettre de bloquer tout les ports que vous n’utilisez pas, réduisant ainsi la surface d’attaque potentielle de votre serveur.

Si vous hébergez un serveur Linux il est fort probable que vous y disposiez d’un serveur web, contenant peut-être des pages d’identifications à divers services. Il est donc indispensable d’empêcher quiconque de bruteforcer ces fameuses pages d’identifications, potentiellement sensibles.
Pour cela, le soutien de Fail2Ban vous sera tout simplement indispensable.
En effet, une fois correctement configuré ( pour cela je vous laisse vous remettre à la doc d’Ubuntu par exemple ) il surveillera une variété de services allant du serveur SSH aux pages de connexions d’Apache afin de détecter tout tentative d’intrusion. En effet après un certains nombre d’échecs de connexions, il bannira l’ip en question pour une période que vous aurez tout le soin de définir.
Ce qui coupera net un éventuel bruteforce.

Une fois ces quelques mesures mise en place, votre serveur sera ‘blindé’ contre les bruteforces en tout genre. Mais il existe des manières bien plus subtiles de prendre le contrôle d’une machine connecté à Internet.
Vous aurez donc intérêt à être bien au courant de ce qu’il se passe sur votre serveur. Pour cela, un programme nommé Logwatch va vous aider à garder un oeil sur vos fichiers de logs.
Tout les jours, Logwatch vous enverra un résumé de ce qu’il s’est passé sur votre serveur. Cela inclut tout les connexions, réussis ou infructueuses, les potentielles erreurs de certains services, l’état de votre stockage, .. Enfin bref, il sera vos yeux et vos oreilles sur votre serveur et vous semblera très vite indispensable.

Malgrès toutes ces mesures, il se pourrait malgrès tout qu’un hacker particulièrement doué parviennent à s’infiltrer sur votre serveur. Si c’est le cas, il tentera sûrement d’installer une backdoor afin de pouvoir revenir plus tard à sa guise. Pour cela, je ne peux que vous conseiller d’installer Rkhunter. Rkhunter est un programme qui va comparer le hash des programmes installés afin de vérifier leurs intégrité. Il sera en mesure de détecter d’éventuels exploits, rootkit ou autres backdoor.

Une fois toute ces mesures prises, ne vous croyez surtout pas en sécurité ! Vous devez faire particulièrement attention aux permissions de vos fichiers ainsi que maintenir votre infrastructure à jour, sous peine de vous retrouver vulnérables à de nouvelles failles récemment découvertes.
Aussi, s’il vous arrive d’héberger des CMS, veillez à toujours modifier l’url des panels d’administrations de sorte que, si votre base de données s’avérer avoir été dumpé à cause d’une requête SQL mal sécurisé, le pirate ne parviendrait pas à trouver le panel pour se connecter.

Aussi, si vous faites régulièrement des backups de votre serveur ( ce que je vous conseille très vivement ), tachez de les exporter rapidement hors de votre serveur. Les backups contiennent en général des informations sensibles ( fichiers de configurations de CMS contenant le mots de passe d’une DDB par exemple ).

Voilà voilà, cet article n’avait pas la prétention de vous apprendre à sécurisé un serveur à la perfection, je n’ai pas parler des permissions par exemple, mais juste de partager avec vous mon expérience personnelle.
Et surtout n’oubliez pas, un hack parfait c’est celui que personne n’a remarqué.