== Introduction ==<\/p>\n
Suite a des probl\u00e8mes de s\u00e9curit\u00e9 (en fait, l’absence totale de mesure de s\u00e9curit\u00e9) sur mes serveurs Debian, j’ai d\u00e9cid\u00e9 de repartir \u00e0 z\u00e9ro, et de cr\u00e9er un mod\u00e8le de VM avec une CentOS 6.3 et de mettre la main \u00e0 la p\u00e2te quant \u00e0 sa s\u00e9curit\u00e9. <\/p>\n == Durant l’installation == == Compte utilisateur alternetif ==<\/p>\n CentOS contrairement \u00e0 d’autres distributions comme Ubuntu, ne cr\u00e9e pas de compte alternatif \u00e0 l’installation, mais uniquement le compte root.<\/p>\n La premi\u00e8re mesure \u00e0 prendre est de cr\u00e9er un compte alternatif avec mot de passe tr\u00e8s fort. Pour le reste de l’article, je l’appellerai srvadm par simplicit\u00e9. Pour g\u00e9n\u00e9rer le mot de passe, j’utilise le g\u00e9n\u00e9rateur inclus dans Keepass dont je me sers pour le stockage de toutes mes authentifications et cl\u00e9s.<\/p>\n == Installation de openSSH ==<\/p>\n Une fois l’installation de la CentOS termin\u00e9e, et les VMware tools install\u00e9es, s’il s’agit d’une VM sur un environnement VMware, il est temps d’installer SSH.<\/p>\n Par d\u00e9faut, la connexion de root par ssh est autoris\u00e9e. J’en profite donc pour me connecter avec Putty en SSH. A partir de l\u00e0, je vais pouvoir faire du copier-coller pour le mot de passe, jusqu’\u00e0 une \u00e9tape ult\u00e9rieur o\u00f9 on se passera de mot de passe. Je g\u00e9n\u00e8re donc un mot de passe tr\u00e8s fort et l’applique \u00e0 root depuis la connexion SSH.<\/p>\n == Authentification ssh par cl\u00e9 (sans mot de passe ==<\/p>\n === Cr\u00e9ation d’une cl\u00e9 pour Putty sous Windows === D’abord, sur le serveur, je m’authentifie comme srvadm, et je me place dans le dossier ~\/.ssh. Ensuite j’\u00e9dite le fichier authorized_keys dans lequel je mettrai ma cl\u00e9 publique.<\/p>\n Comme je suis sur Windows, je vais utiliser PuttyGen pour g\u00e9n\u00e9rer une cl\u00e9, un utilitaire de cr\u00e9ation de cl\u00e9s pour Putty.<\/p>\n Dans Puttygen, en bas, je choisis “SSH-2 RSA” et 2048 bits. Ensuite je clique Generate, et je bouge la souris sur puttygen pour g\u00e9n\u00e9rer des caract\u00e8res al\u00e9atoires comme indiqu\u00e9. Une fois ceci fait, je clique “save public key”, et “save private key”. Je vais stocker ces deux fichiers dans keepass, qui est capable de stocker des fichiers. NE GARDEZ JAMAIS LA CLE PRIVEE ET LA CLE PUBLIC ENSEMBLE !<\/p>\n Je copie ensuite dans le presse-papier le contenu du champs “Public key for pasting into OpenSSH autorized_keys file” (ce nom parle de lui-m\u00eame).<\/p>\n De retour sur le serveur, je colle le contenu du presse-papier dans le fichier authorized_keys de mon utilisateur srvadm.<\/p>\n Pour tester la cl\u00e9 depuis Putty, il faut cr\u00e9er une nouvelle connexion vers le serveur, avec le nom d’utilisateur dans l’adresse:<\/p>\n Ensuite, dans le volet de gauche, sous “Connection” > “SSH” > “Auth”, il faut s\u00e9lectionner, sous “Private key file for authentication” le fichier de cl\u00e9 priv\u00e9 qu’on vient de cr\u00e9er.<\/p>\n On retourne ensuite tout en haut du volet de gauche sous Session, on lui donne un nom et on la sauve. Il n’y a plus qu’\u00e0 cliquer sur “Open” pour tester la connexion. Si on ne vous demande pas de mot de passe, c’est dans la poche. Sinon, relisez le chapitre, vous avez du faire une erreur quelque part.<\/p>\n === Cr\u00e9ation d’une cl\u00e9 sous Linux === Sur votre ordinateur, ouvrez un terminal, et ex\u00e9cutez la commande suivante:<\/p>\n Ceci g\u00e9n\u00e8re deux fichiers, par d\u00e9faut dans ~\/.ssh: id_rsa qui est la cl\u00e9 priv\u00e9e, et id_rsa.pub qui est la cl\u00e9 publique. Collez ensuite le contenu de la cl\u00e9 public (id_rsa.pub) dans le fichier authorized_keys cit\u00e9 plus haut. Souvenez-vous: ce fichier doit \u00eatre dans le dossier ~\/.ssh de l’utilisateur d\u00e9sir\u00e9, \u00e0 savoir srvadm dans notre exemple. Il ne faut pas \u00eatre connect\u00e9 en root, mais en srvadm (si vous avez lu l’article jusqu’ici, vous ne pouvez pas avoir fait faux).<\/p>\n Une fois la cl\u00e9 en place, on teste:<\/p>\n on doit se retrouver sur le prompt utilisateur sans avoir eu besoin de mettre un mot de passe.<\/p>\n === Passphrase === == Configuration de openSSH ==<\/p>\n Maintenant que je peux me connecter sans mot de passe, gr\u00e2ce \u00e0 l’utilisation de la cl\u00e9, \u00e0 mon serveur, je vais d\u00e9sactiver l’authentification par mot de passe sur openSSH, et je vais interdire le login par l’utilisateur root.<\/p>\n Je vais \u00e9galement limiter l’acc\u00e8s SSH \u00e0 un groupe d’utilisateur dans lequel je vais mettre pour l’instant l’utilisateur “srvadm”, et ult\u00e9rieurement \u00e9ventuellement d’autres comptes qui devront pouvoir se connecter par ssh.<\/p>\n La configuration de ssh se fait dans le fichier \/etc\/ssh\/sshd_config. Il faut se loguer en root pour \u00e9diter ce fichier. Comme plus haut on a fait un su srvadm, il suffit de taper “exit” maintenant pour retourner en root.<\/p>\n L’alternative est d’utiliser notre nouvelle connexion putty avec authentification par cl\u00e9, et de se loguer en root avec la commande su:<\/p>\n On copie le mot de passe fort cr\u00e9\u00e9 pour l’utilisateur root, et le tour est jou\u00e9.<\/p>\n On \u00e9dite ensuite le fichier sshd_config:<\/p>\n Je ne vais pas faire le tour du fichier. Il y a la commande man pour \u00e7a. Voici les param\u00e8tres que j’ai mis en place. Certains de ces param\u00e8tres sont d\u00e9j\u00e0 configur\u00e9s peut-\u00eatre avec d’autre valeur. A v\u00e9rifier. Un simple copier-coller de mes param\u00e8tres n’est pas une bonne id\u00e9e.<\/p>\n Le protocole 2 est plus s\u00fbr que le protocole 1. On \u00e9vitera donc d’autoriser le 1.<\/p>\n Le param\u00e8tre suivant indique que une fois la session ssh entam\u00e9e, on a 30 secondes pour s’authentifier, sinon la session est annul\u00e9e:<\/p>\n Les param\u00e8tres suivants concernent l’authentification.<\/p>\n Le premier interdit \u00e0 root de se connecter par ssh. Le second interdit la connexion par mot de passe. Il est d\u00e8s lors indispensable d’avoir mis en place l’authentification par cl\u00e9, et d’utiliser la cl\u00e9 priv\u00e9e correspondante pour toute session vers le serveur. Enfin, le dernier n’autorise que les utilisateurs faisant partie du groupe sshusers \u00e0 se connecter par ssh.<\/p>\n Il faut donc cr\u00e9er le groupe sshusers, et mettre l’utilisateur srvadm dedans:<\/p>\n On quitte nano en sauvegardant le fichier, avec ctrl+X.<\/p>\n Il n’y a plus qu’\u00e0 red\u00e9marrer openssh. ATTENTION: Une fois ssh red\u00e9marrer, il sera impossible de se connecter par SSH ni avec root, ni par mot de passe. Il est donc INDISPENSABLE de s’\u00eatre assur\u00e9 que l’on peut se connecter SANS MOT DE PASSE et avec l’utilisateur srvadm AVANT de red\u00e9marrer ssh.<\/p>\n Il n’y a plus qu’\u00e0 faire un test depuis putty: On se connecte avec srvadm avec authentification par cl\u00e9, et si on a besoin de se mettre en root, on utilise pour l’instant su – .<\/p>\n == sudo ==<\/p>\n Je me suis pos\u00e9 la question de savoir si sudo \u00e9tait s\u00fbr… Ne souhaitant pas me prendre le chou \u00e0 entrer le mot de passe \u00e0 chaque fois, si j’installe sudo, je vais utiliser le param\u00e8tre NOPASSWD qui me permet de faire n’importe quelle commande dans mot de passe. C’est faisable mais il y a quelques gardes fous \u00e0 mettre en place. D’abord, il faut un mot de passe tr\u00e8s fort. Je l’ai dit plus haut, j’utilise un g\u00e9n\u00e9rateur de mot de passe. Mes mots de passe font 20 caract\u00e8res, et sont de ce type l\u00e0:<\/p>\n Difficilement hackable, quand m\u00eame.<\/p>\n D\u00e8s lors, je consid\u00e8re que ma connexion srvadm est tr\u00e8s s\u00fbre. Je me permets alors de mettre en place sudo, et d’autoriser srvadm, et uniquement srvadm \u00e0 utiliser sudo sans mot de passe.<\/p>\n Premi\u00e8re \u00e9tape, il faut installer sudo. On passe en root, on colle le mot de passe de root, et on install sudo avec yum:<\/p>\n Ensuite on \u00e9dite sudoers. Pour ce faire, on va utiliser visudo. Par d\u00e9faut, visudo utilise vi comme \u00e9diteur. Si on souhaite utiliser nano, on peut le param\u00e9trer en ins\u00e9rant une variable editor dans sudoers gr\u00e2ce \u00e0 la commande suivante:<\/p>\n Ensuite donc on \u00e9dite:<\/p>\n Dans sudoers, je vais emp\u00eacher root d’utiliser sudo. Il est activ\u00e9 par d\u00e9faut, et \u00e7a ne sert \u00e0 rien du tout.<\/p>\n Je vais ensuite d\u00e9finir deux variables contenant tous les shells, ainsi que su, afin de pouvoir d\u00e9finir qu’un utilisateur n’a pas le droit de les utiliser:<\/p>\n Enfin, j’autorise mon utilisateur srvadm \u00e0 utiliser sudo sans mot de passe, mais je lui interdit le sudo su (qui est dans la variable NSU) ainsi que l’ex\u00e9cution d’un shell (dans la variable NSHELLS):<\/p>\n Ainsi, si l’utilisateur veut se connecter en root, il est oblig\u00e9 d’utiliser la commande “su -” et donc de fournir le mot de passe de root. Ce qui ne serait pas le cas avec sudo su.<\/p>\n CTRL-X y pour sortir et sauvegarder si on a utiliser nano. :wq si on a utiliser vi.<\/p>\n == Installation et configuration de Fail2ban == Pour installer fail2ban sur la CentOS 6.3, il faut mettre en place le repository EPEL. Pour celui-ci, on t\u00e9l\u00e9charge d’abord la cl\u00e9 PGP, ensuite, on peut t\u00e9l\u00e9charger l’autoinstaller du repository, pour enfin installer fail2ban avec yum:<\/p>\n Une fois fail2ban install\u00e9, on va juste modifier quelques param\u00e8tres. Sinon, la config par d\u00e9faut fait bien l’affaire. Pour l’instant, il ne s’agit que de bloquer les attaques brute-force ssh<\/p>\n On va d\u00e9finir l’adresse de destination des emails, l’adresse d’exp\u00e9dition des m\u00eames emails, et personnellement, je vais augmenter le d\u00e9lai de ban de 600 \u00e0 3600 secondes. Je vais \u00e9galement mettre ma propre machine dans les IP a ignorer. A part destmail qui n’existe pas par d\u00e9faut et qu’il faut donc ajouter dans la rubrique [DEFAULT], toutes les autres variables existe, il suffit de les modifier:<\/p>\n Il faut \u00e9galement v\u00e9rifier si le log a surveiller pointe au bon endroit. En l’occurence, sous “ssh-iptables”:<\/p>\n dans le cas de CentOS 6.3.<\/p>\n Je mettrai \u00e0 jour cet article au fur et \u00e0 mesure de mon avancement.<\/p>\n Sources: == Introduction == Suite a des probl\u00e8mes de s\u00e9curit\u00e9 (en fait, l’absence totale de mesure de s\u00e9curit\u00e9) sur mes serveurs Debian, j’ai d\u00e9cid\u00e9 de repartir \u00e0 z\u00e9ro, et de cr\u00e9er un mod\u00e8le de VM avec une CentOS 6.3 et de mettre la main \u00e0 la p\u00e2te quant \u00e0 sa s\u00e9curit\u00e9.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[220],"tags":[56],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/posts\/775"}],"collection":[{"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/comments?post=775"}],"version-history":[{"count":11,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/posts\/775\/revisions"}],"predecessor-version":[{"id":997,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/posts\/775\/revisions\/997"}],"wp:attachment":[{"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/media?parent=775"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/categories?post=775"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/tags?post=775"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nPourquoi une CentOS ? Car je vais avoir un nouvel emploi dans lequel je vais tr\u00e8s probablement faire une certification RHEL. CentOS est donc le choix parfait pour me faire la main.<\/span><\/p>\n
\nDurant l’installation CentOS, il est demand\u00e9 \u00e0 l’utilisateur de param\u00e9trer un mot de passe pour le compte root. A ce stade l\u00e0, je mets un mot de passe tr\u00e8s simple, bien qu’avec majuscules et caract\u00e8res sp\u00e9ciaux, afin de pouvoir rapidement le taper lorsque j’en ai besoin pendant la phase de configuration de SSH, \u00e9tant donn\u00e9 que je ne peux pas faire de copier-coller dans la console du vSphere Client. D\u00e8s que SSH sera install\u00e9, je mettrai alors un mot de passe tr\u00e8s fort.<\/p>\nuseradd srvadm\r\npasswd srvadm<\/pre>\n
yum install openssh-server openssh-clients<\/pre>\n
passwd<\/pre>\n
\nIl est temps de mettre en place une authentification par cl\u00e9 pour l’utilisateur srvadm.<\/p>\nsu srvadm\r\ncd ~\/.ssh\r\nnano authorized_keys<\/pre>\n
srvadmin@ip_server<\/pre>\n
\nSi vous utilisez Linux, et non Windows, la proc\u00e9dure n’est pas tr\u00e8s diff\u00e9rente.<\/p>\nssh-keygen -t rsa<\/pre>\n
ssh srvadm@server_ip_address<\/pre>\n
\nPersonnellement, lors de la g\u00e9n\u00e9ration de cl\u00e9s, je ne mets pas de passphrase car ceci oblige \u00e0 entrer la passphrase \u00e0 chaque utilisation de la cl\u00e9. Mais attention: Cela implique que si qqun vole ma cl\u00e9, il pourra l’utiliser sans scrupule. Il faut donc \u00eatre s\u00fbr de o\u00f9 on la garde pour \u00e9viter que cela n’arrive. Veillez \u00e0 la mettre en s\u00e9curit\u00e9, par exemple dans keepass.<\/p>\nsu -<\/pre>\n
nano \/etc\/ssh\/sshd_config<\/pre>\n
Protocol 2<\/pre>\n
LoginGraceTime 30<\/pre>\n
PermitRootLogin no\r\nPasswordAuthentication no\r\nAllowGroups sshusers<\/pre>\n
groupadd sshusers\r\nusermod -G sshusers srvadm<\/pre>\n
service sshd restart<\/pre>\n
C.6%DK'\/uM-TRGy5U3@K<\/pre>\n
su -\r\nyum install sudo<\/pre>\n
echo Defaults editor=\/bin\/nano >> \/etc\/sudoers<\/pre>\n
visudo<\/pre>\n
# root ALL=(ALL) ALL<\/pre>\n
Cmnd_Alias NSHELLS = \/bin\/sh, \/bin\/bash, \/sbin\/nologin, \/bin\/tcsh, \/bin\/csh, \/bin\/zsh, \/bin\/k$\r\nCmnd_Alias NSU = \/bin\/su<\/pre>\n
srvadm ALL=(ALL) NOPASSWD:ALL, !NSHELLS, !NSU<\/pre>\n
\nFail2ban a pour objectif de bloquer les attaques de type “brute force”. Ce sont des attaques ou des serveurs essaient d’entrer en force en faisant une s\u00e9rie de tentative de connexions avec recherche de mot de passe sur un tas de nom d’utilisateurs potentiels.<\/p>\nsudo wget http:\/\/ftp.riken.jp\/Linux\/fedora\/epel\/RPM-GPG-KEY-EPEL-6\r\nsudo rpm --import RPM-GPG-KEY-EPEL-6\r\nsudo rm -f RPM-GPG-KEY-EPEL-6\r\nwget http:\/\/dl.fedoraproject.org\/pub\/epel\/6\/i386\/epel-release-6-7.noarch.rpm\r\nsudo rpm -Uvh epel-release-6-7.noarch.rpm\r\nsudo yum install fail2ban<\/pre>\n
sudo nano \/etc\/fail2ban\/jail.conf<\/pre>\n
destmail = monitoring@domain.ltd\r\nignoreip = 127.0.0.1 monddns.mondomaine.ltd\r\nbantime = 3600\r\n...\r\naction = iptables[name=SSH, port=ssh, protocol=tcp]\r\n sendmail-whois[name=SSH, dest=root, sender=fail2ban.monhost@mondomaine.ltd]<\/pre>\n
logpath = \/var\/log\/secure<\/pre>\n
\nS\u00e9curit\u00e9 Linux – sudo – su – ssh – cl\u00e9 … <\/a>
\nsshd_config man page<\/a>
\nThe Perfect Server – CentOS 6.3 x86_64<\/a>
\nHow to Configure EPEL Repository on CentOS 6.3
\n<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"