Good practices

Good Practices pour votre Debian exposé sur le net

(article à constamment améliorer)

Réduire la surface d'attaque cloisonnement applicatif rediger des procedures les logs

1. Les accès

On va parler ici surtout des accès via SSH. Donc SSH, SFTP, SCP etc...

Le minimum est de refuser tout connexion avec un login root. Déjà parce que c'est un compte commun a toutes les machines linux et donc une chose en moins a chercher pour le margoulin qui voudrait vous truander votre serveur, et ensuite parce que putain, root quoi... après c'est open bar. On va donc préconiser un compte nominatif, différent pour chaque personnes se connectant a la machine. Dans l'idéal on va aussi limiter l’accès au compte root lui même et éventuellement privilégié des comptes "sudoer". L'utilisation de la commande sudo permet aussi de se loguer en root (sudo su), cela peut avoir un intérêt de le bloquer.

Maintenant se loguer avec seulement un login et un mot de passe, c'est un peu léger et ça va pas résister au brute force indéfiniment. Dans le doute, mettez un mot de passe badass. 64 caractères, chiffres, lettres, majuscules, minuscules, caractères spéciaux et pourquoi pas certains qui sont même pas sur le clavier! Utilisez votre coffre a mot de passe préféré pour le stocker (keepass par exemple) Bref, le renforcement de l’accès passe par l'utilisation d'une paire de clef public/privé (différents algo possible, RSA/ed25519/etc..). Il est d'ailleurs possible de limiter les algos de clef pour la connexion, moins d'algo, une exigence technique plus élevée. Vous allez pouvoir générer une paire de clef pour protéger votre accès. Cette clef pourra elle aussi avoir un mot de passe et vous pourrez garder ou non en plus le mot de passe de votre login a saisir. Le niveau max étant donc un login perso, la clef plus sa passphrase pour la déchiffré et le mot de passe lié a votre login. Évidement interdire un login ssh sans clef. A partir de la et selon le degré d'exposition de votre serveur, vous pouvez régler tout ça a un niveau intermédiaire, exemple juste une clef chiffré avec le login pour se connecter, le second mot de passe étant un peu contraignant. Mais histoire d’éviter le brute force, on va aussi utiliser un fail2ban qui va s'occuper d'analyser les logs du serveur et donc les tentative de connexion afin de bannir quelques personnes malveillantes et un peu insistante. Une couche supplémentaire, changer le port par default de son serveur SSH ainsi que le message d'accueil qui donne des informations sur la version de ssh et du serveur. On peut également mettre un envoie de mail dans le ''.bashrc'' pour programmer l'envoie d'un mail en cas de connexion. Ça spam, mais ça peut être pratique.

Résumé:

• pas de log root en SSH
• des comptes personnalisé pour chaques users
• Utlisation de sudo
• Logging des commandes SUDO
• Configurer des limites d'utilisation de sudo
• Empecher les sudoers de se loger en root (sudo su)
• Connexion obligatoire avec une clef RSA chiffré
• Changer le port par defaut de SSH
• Changer le message d'accueil de SSH
• Limiter les algo de clef authorisé a la connexion
• Installer Fail2Ban
• Envoie d'un mail au login via ''.bashrc''

2. iptables

Il faut protéger les ports de sa machine et pour ça si vous avez pas de firewall dédié a cela, le minimum c'est iptable. Vous trouverez une configuration basique [[iptables_config|ICI]]. On peut faire beaucoup mieux et beaucoup plus sécurisé, mais ça viendra un jour!

3. Les services

Comme dit précédemment, fail2ban, c'est efficace pour des raisons déjà cités, installez le. Pour tous vos services que vous exposerez, n’hésitez pas a changer le port par défaut si c'est possible. par exemple pour un serveur FTP c'est une bonne idée, ça l'est pas vraiment si c'est pour héberger un site web! Surveiller ce que vos applis publies sur le net. Les messages d'accueil sont parfois très bavard par défauts et donne des indications précieuses tel que le nom de l'appli et sa version. Autant dire que c'est un avantage non négligeable quand vous cherchez a exploiter une faille potentielle.

3.1 Le cas d'Apache2

Vous allez trouvez des informations sur la page dédié....

3.2 Isolation des services

4. Autres

• Limiter les paquets inutiles
• Faites vos mises a jours régulièrement surtout de vos services avec des ports ouverts