Mes 5 premières minutes sur un serveur Debian

Date: 14/03/2013 | Catégories: Open-source,Planet-libre,raspberry,Systeme | Tags: ,,

sam

Sur une idée originale pompée honteusement sur le blog de Bryan Kennedy.

La virtualisation ou la possibilité d'acheter des machines à bas prix comme le Raspberry implique le fait que l'installation de serveurs devient une tâche de plus en plus fréquente. Afin d'éviter les grossières erreurs qui peuvent rapidement devenir fatales si la machine est exposée au réseau Internet, voici les actions que j'effectue systématiquement sur mes systèmes d'exploitations Debian ou Ubuntu Server.

Si vous suivez ce blog, vous savez que je suis un gros fainéant pour ce genre de tâches récurrentes. J'ai donc écrit un ensemble de scripts permettant d'effectuer les actions de "post installation". J'ai également commencé à regarder du coté des systèmes de gestion de configuration comme Puppet qui sont des solutions à utiliser en priorité si vous avez un parc informatique important.

L'objectif de ce billet est donc pédagogique pour partager avec vous les actions à effectuer et, je l'espère, en apprendre de nouvelles.

Assez de palabres, place au clavier...

1) S'occuper de ses comptes

Je parle bien évidemment ici des comptes utilisateurs qu'il va falloir sécuriser. On commence par le compte root qui ne sera PAS (jamais, c'est mal) utilisé directement pour vous connecter sur votre machine. Lors de l'installation du système, il faut saisir un mot de passe sécurisé, c'est à dire assez long avec un mélange de lettres, de chiffres et d'autres caractères mais sans utiliser des mots connus ou des suites de chiffres. Vous n'avez pas besoin de connaitre ce mot de passe par coeur mais il faudra le conserver bien au chaud.

Une fois logué sur la machine (on durant la phase d'installation du serveur), on commence par créer un utilisateur principal que l'on utilisera pour se connecter à la machine.

J'ai choisi morpheus pour illustrer mon billet.

La suite des opérations sera donc faite à partir de cet utilisateur.

2) S'occuper de ses portes d'entrées avec SSHd

SSH est devenu le mode d'accès le plus utilisé pour accéder aux serveurs GNU/Linux. Par défaut, il propose un contrôle d'accès par nom d'utilisateur et mot de passe. J'essaye au maximum d'éviter cette solution. J'utilise le système d'authentification par clé publique qui est un peu plus lourde à mettre en oeuvre et à administrer mais qui offre un niveau de sécurité plus important.

Pour ajouter la clé publique de mon PC avec lequel je vais me connecter au serveur, il suffit de lancer la commande suivante à partir de cette machine:

Puis on force l'utilisation de l'authentification par clé publique et on ferme ensuite cette porte à l'utilisateur root:

Attention: l'authentification par  nom d'utilisateur / mot de passe sera désactivée pour les accès SSH. 

On relance ensuite le daemon SSH:

3) Contrôler les entrées avec Fail2ban

Une fois le daemon SSH sécurisé, il faut ensuite ajouter une couche permettant de contrôler plus finement les accès. J'utilise pour cela Fail2ban que j'ai abordé plus précisément dans un précédant billet. Dans notre sujet du jour, je vais configurer Fail2ban pour bloquer, pendant 5 minutes, l'accès à SSH à un utilisateur qui se trompe 3 fois de mot de passe.

On commence par installer fail2ban:

On va ensuite éditer le fichier /etc/fail2ban/jail.conf pour le configurer comme l'on souhaite:

On relance ensuite le service pour prendre en compte la configuration:

4) Fermer les fenêtres (de votre Firewall)

Comme nous l'avons vu dans le point précédant, Fail2ban utilise le Firewall IPtable qui part défaut laisse passer l'ensemble des flux. J'applique systématiquement une configuration beoucoup plus restrictive qui autorise les flux SSH entrant (pour l'accès à distance) et HTTP/HTTPs/DNS sortant (pour la mise à jour de mon serveur).

J'utilise pour cela un script de démarrage maison:

que je lance au démarrage de la machine (et aussi immédiatement):

Il est bien sûr possible d'adapter ce script à vos besoins de flux entrants et sortants en éditant les lignes suivantes:

5) Prendre soin de ses fondations en tenant son système à jour

Maintenir à jour ses serveurs est une tâche à la fois indispensable et rébarbative. Il y a ici deux écoles possibles. La première est d'utiliser un logiciel comme unattended-upgrades qui va installer automatiquement pour vous les mises à jours de sécurités ou même l'ensemble de votre système. C'est une solution élégante mais qui n'est pas sans risque si un pépin arrive suite à une mise à jour alors que vous êtes loin de vous machines. J'opte donc pour la seconde solution, basée sur cron-apt, qui va me notifier par mail les mises à jours à effectuer sur mes machines.

On installe cron-apt avec la commande:

Puis on configure l'adresse mail de destination des messages de notifications dans le fichier /etc/cron-apt/config:

Note: comme vous pouvez le lire, j'utilise une adresse Gmail bibi@gmail.com pour la réception de mes notifications. J'y ajoute +monserveur (qui sera ignoré par Gmail) afin de pouvoir facilement les filtrer.

On relance le service pour prendre en compte la configuration:

Les notifications seront envoyés par défaut toutes les nuits à 4h du matin.

6) Surveiller le tout avec Logwatch

A ce stade vous avez un serveur disposant d'une sécurité de base qui va le protéger de la grande majorité des attaques que l'on peut trouver sur Internet. Il ne reste plus qu'à installer Logwatch, un outil permettant d'analyser les logs et ainsi de remonter par mail des rapports permettant d'analyser des tentatives d'intrusions éventuelles.

La mise en place est assez simple.

Puis on configure l'adresse mail de destination des messages de notifications dans le fichier /etc/cron-apt/config:

On relance le service pour prendre en compte la configuration:

Les notifications seront envoyés par défaut toutes les nuits.

7) Conclusion

Nous arrivons à la fin de ce billet avec une machine à l'épreuve d'une exposition à Internet sans risque de se faire hacker par le premier "script kiddie" venu.

A vous de nous faire partager vos techniques, méthodes que vous appliquez sur vos nouveaux serveurs !

  • Nicolas KAROLAK

    Merci des conseils !

    Une petite question cependant, tu veux dire quoi par « vous n’avez pas besoin de connaître ce mot de passe par coeur mais il faudra le conserver bien au chaud » ? Sur un bout de papier dans le fond d’un tiroir par exemple ?

    • Je pensais plus à un post-it directement sur l’écran… 🙂

      Plus sérieusement dans logiciel de gestion de mot de passe comme KePassX: http://www.keepassx.org/

      • Nicolas KAROLAK

        Sur l’écran ce n’est pas très recommandé voyons ! Sous le clavier c’est mieux… 🙂

        Ok merci, je me disais bien…

      • Visiteur

        Ok, j’avais pas compris :/ J’avais mis le post-it au chaud… dans la cheminée 🙁
        Petite erreur à l’étape 6 : je doute qu’on redémarre logwatch avec « sudo service cron-apt restart » 🙂

  • J’aurais ajouté une modification du numéro de port ssh (à reporter dans la config ssh et firewall) : vieille habitude que j’avais avant de connaître fail2ban.

    question : est-on obligé de redémarrer le service sshd avec la police Georgia ou si ça marche aussi avec DejaVu ? 😉

    • Georgia ou sinon le service ne redémarre pas 🙂 (c’est corrigé)

  • Florian Lacrampe

    Merci pour ces conseils très utiles ! Je pense que ça ne fait pas de mal de rappeler les classiques 😉

  • Merci pour cette page.. c’est simple, pas-à-pas. Ca donne envie d’acheter un Rasp.

  • Edouard

    useradd -m ? ou c’est volontaire (eviter les skells?)

  • Marrant on fait exactement la même chose. Je rajoute un petit portsentry perso.

  • Corgumolax

    Merci pour ce petit aide mémoire bien pratique.

    Une question concernant logwatch toutefois: ne crée-t-il pas à son installation une tâche dans /etc/cron.daily par défaut? Pourquoi aller la reconfigurer avec celle définie pour cron-apt?

    (Petite erreur de typo également dans cette partie: –detail hight => –detail high )

  • Anthony

    Merci pour cet article.

    Il me semble que tu as une balise qui a sauté après :
    « Attention: l’authentification par nom d’utilisateur / mot de passe sera désactivée pour les accès SSH. »

  • Gepeto

    Merci pour toutes ces bonnes astuces et conseils !

    Depuis peu j’utilise ‘unattended-upgrades’ pour la mise à jour automatique de serveurs avec envoie de mail. J’ai trouvé via le site http://blog.chriskankiewicz.com/post/158/setting-up-an-ubuntu-web-server/

    Je trouve ce soft très pratique mais je n’ai pas vraiment de recul. As-tu un avis sur ce programme ? Une réticence ?

  • kaliko

    Àmha, l’utilisation de adduser est peut être préférable à useradd (cf. man 8 useradd: « On Debian, administrators should usually use adduser(8) instead. »).

    De plus concernant le filtrage de ssh, je passe désormais par iptables. C’est une solution plus bas niveau (le serveur ssh ne voit même pas la requête) et moins gourmande en ressource que la solution python/fail2ban.

    Le module recent de ip(6)tables permet de garder une liste d’IP. Si on construit celle ci sur les requête SYN sur le port SSH on peut facilement détecter les tentatives d’attaques par la force brute et réagir en aiguillant la requête sur un DROP. Beaucoup de doc est dispo sur le web quant à cette méthode.

    kaliko

    • kaliko

      Un avantage de la solution iptables/ip6talbes par rapport à fail2ban est la possibilité de filtrer IPv6, je n’utilise plus fail2ban depuis longtemps, cependant avant de que le projet soit de nouveau maintenu, fail2ban ne gérait pas encore IPv6.

  • J’ajouterai la notification email à chaque connexion http://blogmotion.fr/systeme/notification-connexion-ssh-4246

  • François
  • Pingback: DEBIAN SERVEUR | Pearltrees()

  • Un précédent article de blog sur le même sujet :
    http://plusbryan.com/my-first-5-minutes-on-a-server-or-essential-security-for-linux-servers
    Est-ce la saison ?

  • Je fais à peu près la même chose également.

    Pour la partie iptables au démarrage du système, je passe plutôt par /etc/network/if-pre-up.d/iptables, suites au recommendations du wiki debian (actuellement injoignable à l’instant).

    J’installe également glances, ça peut toujours servir 😉

  • Arka

    « Dans notre sujet du jour, je vais configurer Fail2ban pour bloquer, pendant 5 minutes, l’accès à SSH à un utilisateur qui se trompe 3 fois de mot de passe. » Disons plutôt l’utilisateur qui utilise une mauvaise clé (vu que tu as désactivé l’authentification par mot de passe).

  • Pingback: Nono’s Vrac 91 « m0le'o'blog()

  • Pour le firewall je préfère ufw vraiment plus simple:

    sudo apt-get install ufw
    sudo ufw allow 22
    sudo ufw allow 80
    sudo ufw allow 443
    sudo ufw enable

    sinon article très sympa

  • Pingback: AdminRézo – Que faire après l’installation d’un serveur Debian ?()

  • Pingback: AdminRézo – Que faire après l’installation d’un serveur Debian ?()

  • Matux

    Bonjour, j’ai un petit pépin à l’étape n°6

    quand je fais « sudo service cron-apt restart » pour rebooter le service j’ai la réponse suivante « cron-apt: unrecognized service » quelqu’un aurait t’il la possibilité de m’aider

    Merci d’avance

    Matux

  • J’utilise aussi denyhost, qui permet de synchroniser plusieurs serveurs entre eux. Ainsi, un serveur qui subit une attaque par une IP, cette ip est bannie par tous les serveurs. Il existe aussi une base centrale très utile.

    http://www.blog-des-telecoms.com/article68/pourquoi-installer-denyhosts-sur-son-serveur

  • Dangleterre Michaël

    Merci pour logwatch 🙂
    De mon côté, j’installe Docker en plus de tout ça…ça m’évite de pourrir complètement le système avec des installes foireuses.
    Et pour ma boîte, j’ai dû documenter l’installation/utilisation de fail2ban et shorewall.