Sécurisation minimale d’un serveur dédié Kimsufi sous Ubuntu Server 14.04 LTS Administration système, GNU/Linux
Dans le cadre de la suite d’articles sur l’installation d’un serveur dédié Kimsufi sous Ubuntu Server 14.04 LTS, je vais aujourd’hui présenter quelques mesures de sécurité à mettre en place afin que le serveur soit un minimum protégé des attaques extérieures. Ce billet, tout comme mes autres articles n’ont pas vocation à être complets ni exhaustifs. Ainsi, je ne serai en aucun cas responsable de possibles problèmes de sécurité sur votre serveur.
- Pourquoi sécuriser un serveur ?
Une fois qu’un serveur est corrompu, l’attaquant pourra alors attaquer d’autres machines depuis le serveur, mettre à disposition du contenu illicite et bien d’autres activités illégales. Ainsi, votre responsabilité pourrait être engagée en cas de problème. Il est donc nécessaire de sécuriser le serveur.
- Créer un compte utilisateur
Une des premières choses à faire pour sécuriser le serveur est de créer un compte utilisateur. Ceci permet de travailler sur le serveur en toute sécurité, sans avoir tous les pouvoirs et donc créer des trous de sécurité par inadvertance. Pour ce faire, connectez vous au serveur via SSH et tapez la commande suivante en modifiant le nom d’utilisateur avec celui de votre choix:
|
1 |
root@serveur:~# useradd -m NOM_UTILISATEUR |
Ici l’utilisateur créé disposera d’un répertoire personnel. Pour pouvoir se connecter au serveur avec cet utilisateur, il faut encore disposer d’un moyen d’authentification. Nous pouvons soit mettre en place un mot de passe, soit utiliser un certificat (comme nous l’avons fais à l’installation du serveur depuis le manager de Kimsufi). Pour mettre en place un mot de passe, il suffit de taper la commande suivante en remplaçant le nom d’utilisateur:
|
1 2 3 4 |
root@serveur:~# passwd NOM_UTILISATEUR Entrez le nouveau mot de passe UNIX : Retapez le nouveau mot de passe UNIX : passwd : le mot de passe a été mis à jour avec succès |
La commande demande de saisir un mot de passe et de le confirmer.
Pour mettre en place l’authentification par certificat, il est nécessaire d’en posséder un. Pour cela, utilisez ssh-keygen comme nous l’avons vu dans un billet précédent sur l’installation d’un serveur dédié Kimsufi sous Ubuntu Server 14.04 LTS. Une fois, en votre possession, copiez le fichier contenant la clé publique sur votre serveur. Par exemple, si votre poste de travail est sous GNU/Linux, utilisez la commande scp comme ici:
|
1 |
utilisateur@poste-travail:~$ scp maclé.pub root@IP_DU_SERVEUR: |
N’oubliez pas les deux-points situés après l’adresse IP du serveur.
Ensuite, il est nécessaire de l’ajouter aux clés publiques valides pour l’utilisateur, sur le serveur, avec les commandes ci-dessous:
|
1 2 3 4 |
root@serveur:~# mkdir /home/NOM_UTILISATEUR/.ssh root@serveur:~# cat maclé.pub >> /home/NOM_UTILISATEUR/.ssh/authorized_keys root@serveur:~# chmod 600 /home/NOM_UTILISATEUR/.ssh/authorized_keys root@serveur:~# rm maclé.pub |
Au passage, nous supprimons le fichier contentant la clé publique sur le serveur puisque nous n’en n’avons plus besoin.
Enfin, pour savoir comment vous connecter au serveur, je vous renvoie vers mon billet précédent.
P.S. : Pour savoir sur quel compte vous êtes connecté, il suffit de regarder le prompt, c’est à dire le début de la ligne sur laquelle vous inscrivez vos commandes. Celui-ci indique le nom du compte et grâce au symbole juste avant votre commande, vous savez si vous êtes sous le compte root ou sous un simple compte utilisateur. Ainsi, en tant que simple utilisateur, vous aurez un prompt similaire à ceci:
|
1 |
utilisateur@serveur:~$ |
Alors qu’en tant que root, vous aurez:
|
1 |
root@serveur:~# |
Vous remarquerez que le nom de compte change et que le prompt finit par un $ (dollar) si vous êtes connecté en tant qu’utilisateur. Il finira avec un # (dièse) si vous êtes connecté en tant que root. Ainsi, dans la suite de cet article et dans mes prochains billets, dans les exemples de commandes à taper, vous saurez qu’il faut les saisir en tant que root si le prompt finit par un # (dièse), sinon en tant qu’utilisateur normal.
-
Changer le mot de passe root
Toujours pour des raisons de sécurité, il est préférable d’avoir un mot de passe différent par compte; qui plus est pour le compte root qui donne accès à tous le privilèges sur la machine. Nous allons donc le modifier de la même manière que pour l’utilisateur, à la différence qu’il n’est pas obligatoire de donner le nom d’utilisateur en argument. Ainsi, entrez la commande suivante pour changer le mot de passe root:
|
1 2 3 4 |
root@serveur:~# passwd Entrez le nouveau mot de passe UNIX : Retapez le nouveau mot de passe UNIX : passwd : le mot de passe a été mis à jour avec succès |
Bien entendu, le mot de passe doit être assez solide (voir section Sécuriser SSH de cet article).
-
Modifier le comportement de la commande sudo
Nous pouvons avoir accès au compte root depuis SSH mais également en utilisant les commandes su et sudo lorsque l’on est connecté au serveur en tant que simple utilisateur. La commande su demandera systématiquement le mot de passe root tandis que sudo est configurée, par défaut, à autoriser les comptes utilisateurs qui font partie du groupe sudo à basculer en tant qu’utilisateur root. Ainsi, si votre compte utilisateur est compromis, l’attaquant pourra facilement se connecter en tant que root et faire plus de dégâts. Pour éviter cela, nous allons modifier la configuration de sudo. Pour cela, entrez la commande suivante:
|
1 |
root@serveur:~# visudo |
Ajoutez la ligne suivante à la fin du fichier:
|
1 |
Defaults rootpw,timestamp_timeout=0 |
Ici nous modifions la configuration de sudo pour qu’il demande systématiquement le mot de passe root et fixons à zéro le délai pendant lequel il ne redemandera pas le mot de passe root. Ainsi, à chaque utilisation de la commande sudo, il sera nécessaire de fournir le mot de passe root.
Enregistrez et quittez l’éditeur (faites Contrôle-X puis O pour enregistrer le fichier et quitter sous nano).
L’utilisateur que nous avons créé plus haut ne fait pas encore partie du groupe sudo. Pour remédier à cela, entrez la commande suivante:
|
1 |
root@serveur:~# gpasswd -a NOM_UTILISATEUR sudo |
- Sécuriser SSH
Pour le moment, le seul accès possible au serveur se fait via SSH. Le protocole a beau être sécurisé, il reste possible d’attaquer un serveur. Certains attaquants utilisent des techniques d’attaques par dictionnaire ou par brute force. Les attaques de type brute force consistent à essayer tous les couples de login/mot de passe possibles. Cette technique présente l’avantage de tomber forcément sur votre mot de passe. Cependant, avec un mot de passe suffisamment solide, cette technique devient inexploitable. En effet, il faudra des millions d’années pour trouver le mot de passe. Avec par exemple, un mot de passe contenant des lettres majuscules et minuscules ainsi que des chiffres, s’il fait une longueur de 8 caractères, il peut y avoir 62 puissance 8 possibilités soit: 218 340 105 584 896 possibilités. À raison d’un test par seconde, il faudrait environ 6 923 519 années pour tester toutes les combinaisons. Un autre type d’attaques peut être plus efficace: les attaques par dictionnaire. Le principe reste le même que le brute force sauf que l’on ne teste pas toutes les possibilités de mot de passe mais juste des mots d’un dictionnaire et éventuellement des combinaisons entre eux. Ainsi, si votre mot de passe est un mot ou une phrase, il sera beaucoup plus facile à deviner. Vous pourrez trouver un script Pyton de génération de mots de passe dans mon précédent article.
Nous allons modifier la configuration du serveur SSH de votre serveur. Nous allons entre autres changer le port d’écoute de SSH qui est par défaut le port 22. En utilisant un port différent, l’attaquant devra alors trouver en plus le bon port pour tenter de se connecter au serveur. Il existe certes des scanners de ports mais ils ne sont pas systématiquement utilisés (la plupart des attaques se font sur le port 22). Ainsi, vous allez devoir choisir un numéro de port qui soit supérieur à 1024 et qui ne correspond pas à un service exécuté par le serveur. Nous allons également interdire les connexions au compte root. En effet, de nombreuses attaques visent le compte root puisqu’il s’agit du compte ayant le plus de privilèges. Pour se connecter au compte root, il faudra d’abord se connecter via le compte utilisateur créé plus haut dans cet article. Ainsi l’attaquant devra également connaître le nom d’utilisateur du compte que l’on a créé et son mot de passe ou son certificat.
Pour réaliser toutes ces opérations, sur le serveur, ouvrez et éditez le fichier /etc/ssh/sshd_config avec votre éditeur préféré, comme ici:
|
1 |
root@serveur:~# nano /etc/ssh/sshd_config |
Puis, modifiez le fichier pour avoir les lignes suivantes en remplaçant le numéro de port:
|
1 2 |
Port NUMERO_PORT PermitRootLogin no |
Enregistrez alors le fichier, et quittez l’éditeur (faites Contrôle-X puis O pour enregistrer le fichier et quitter sous nano)
Il faut ensuite redémarrer le serveur SSH en tapant la commande suivante:
|
1 |
root@serveur:~# sudo service ssh restart |
Pour vous connecter en tant que root sur le serveur, vous devrez dorénavant vous connecter avec votre compte utilisateur sur le serveur et basculer en root avec su ou sudo.
À présent, pour vous connecter au serveur, vous allez devoir préciser le port que le client SSH devra utiliser pour communiquer avec le serveur.
– Sous GNU/Linux, il suffit d’ajouter à la commande ssh le paramètre -p suivi du numéro de port, comme ici:
|
1 |
utilisateur@poste-travail:~$ ssh NOM_UTILISATEUR@IP_DU_SERVEUR -p NUMERO_PORT |
– Sous Microsoft Windows avec PuTTY, lancez PuTTY et rechargez votre session comme vu dans l’article Connexion à un serveur dédié Kimsufi via le protocole SSH. Saisissez le numéro de port dans le champ port et enregistrez la session, comme le montre la prise d’écran ci-dessous:
Sécurisation minimale d’un serveur dédié Kimsufi sous Ubuntu Server 14.04 LTS – Modification du port SSH dans PuTTY
Vous pouvez maintenant vous connecter avec le bon port et restaurer la session correctement configurée ultérieurement.
- Bannir les attaquants
Pour encore plus de sécurité, il est possible de bannir les attaquants. En effet, les journaux systèmes (logs) enregistrent toutes les tentatives de connexion au serveur. Ceux-ci gardent l’adresse IP de toute machine qui essaye de se connecter au serveur. Ainsi, s’il y a trop de tentatives de connexion en échec, il est possible de bannir l’attaquant en indiquant au pare-feu de bloquer toutes les connexions depuis l’adresse IP vers le serveur SSH. Les logiciels denyhosts et fail2ban permettent d’automatiser cette tâche. Ici, nous allons mettre en place fail2ban qui a l’avantage de protéger d’autres services que SSH, tels que FTP, le serveur Web Apache, etc…
Pour cela, il est nécessaire d’installer le paquet fail2ban sur le serveur. Toujours sur le serveur, entrez la commande suivante en tant que root:
|
1 |
root@serveur:~# apt-get install fail2ban |
Ouvrez ensuite le fichier /etc/fail2ban/jail.conf et modifiez la section [ssh], en changeant le numéro de port avec celui choisi comme port d’écoute pour SSH:
|
1 2 3 4 5 6 7 |
[ssh] enabled = true port = ssh,sftp,NUMERO_PORT filter = sshd logpath = /var/log/auth.log maxretry = 3 |
Ici, on ajoute l’écoute sur le port SFTP ainsi que le port SSH que l’on a redéfinit et on fixe le nombre d’essais possibles, avant blocage, à 3.
Lorsqu’une adresse IP est bloquée, on dit qu’elle est en prison ou en liste noire. Sous fail2ban, il existe une prison par service protégé.
Afin d’être prévenu quand une adresse IP est bloquée, un e-mail peut être envoyé depuis le serveur sur une adresse e-mail spécifiée. Pour ce faire, il faut modifier la variable destemail comme ceci:
|
1 |
destemail = adresse@email.fr |
De plus, modifiez la ligne suivante:
|
1 |
action = %(action_)s |
En:
|
1 |
action = %(action_mw)s |
Bien entendu, il est nécessaire que le serveur soit équipé d’un serveur SMTP afin qu’il puisse envoyer l’e-mail. Nous en installerons et configurerons un dans un futur article.
Il est possible de mettre en place des règles spécifiques pour éviter certaines attaques fréquentes telles que les requêtes DFind w00tw00t. Pour ce faire, ajoutez à la fin du fichier la section suivante:
|
1 2 3 4 5 6 |
[apache-w00tw00t] enabled = true filter = apache-w00tw00t action = iptables[name=Apache-w00tw00t,port=80,protocol=tcp] logpath = /var/log/apache2/access*.log maxretry = 1 |
Vous pouvez alors enregistrer et quitter l’éditeur.
Il faut ensuite créer et éditer le fichier /etc/fail2ban/filter.d/apache-w00tw00t.conf avec par exemple:
|
1 |
root@serveur:~# nano /etc/fail2ban/filter.d/apache-w00tw00t.conf |
Insérez y alors le contenu suivant:
|
1 2 3 4 5 |
[Definition] failregex = ^<HOST> -.*"GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).*".* ignoreregex = |
Vous pouvez enregistrer et quitter l’éditeur.
Afin d’être le plus efficace possible contre les attaques par brute force, on peut activer le filtre SASL. Pour cela, il faut créer le fichier/etc/fail2ban/filter.d/sasl.conf avec par exemple:
|
1 |
root@serveur:~# nano /etc/fail2ban/filter.d/sasl.conf |
Et y insérer les lignes suivantes:
|
1 2 3 4 5 |
[Definition] failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$ ignoreregex = |
Vous pouvez enregistrer et quitter l’éditeur.
Il faut maintenant recharger la configuration du service fail2ban avec la commande suivante:
|
1 |
root@serveur:~# fail2ban-client reload |
Il est possible que vous obteniez un message d’erreur du genre:
|
1 |
ERROR No file found for /var/log/apache2/access*.log |
Cela est dû au fait que le serveur Web Apache n’est pas encore installé sur le serveur. Son installation sera le sujet d’un futur article.
Pour vérifier que le service fonctionne correctement, tapez:
|
1 2 3 4 |
root@serveur:~# fail2ban-client status Status |- Number of jail: 1 `- Jail list: ssh |
Ainsi, la commande indique le nombre de prisons. c’est à dire de services protégés par fail2ban.
Attention: si vous vous trompez de login/mot de passe 3 fois, vous allez être bloqué et vous devrez redémarrer le serveur en mode rescue ou vous connecter avec une adresse IP publique différente.
Pour voir quelles adresses IP sont bannies, il faut lancer la commande suivante:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
root@serveur:~# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 22,115,NUMERO_PORT Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain fail2ban-ssh (1 references) target prot opt source destination REJECT all -- ADRESSE_IP_BLOQUÉE 0.0.0.0/0 reject-with icmp-port-unreachable RETURN all -- 0.0.0.0/0 0.0.0.0/0 |
Ainsi, on voit ici que l’adresse IP ADRESSE_IP_BLOQUÉE a été bloquée grâce à la directive REJECT du pare-feu iptables, dans la chaîne fail2ban-ssh.
Pour supprimer une adresse IP de la liste noire (par exemple, si on a bloqué une machine qui ne devait pas être bloquée), il faut utiliser la commande suivante:
|
1 |
root@serveur:~# iptables -D fail2ban-ssh -s ADRESSE_IP_BLOQUÉE -j REJECT |
Comme il existe d’autres types de prison que SSH, il faut adapter la commande en remplaçant par exemple, fail2ban-ssh par fail2ban-pure-ftpd pour utiliser la prison FTP.
- Mettre à jour le serveur
Ubuntu se compose de nombreux logiciels. Comme tout programme, ils ne sont pas parfait et comportent des bugs. Ces bugs peuvent se transformer en failles de sécurité exploitables par de potentiels attaquants et donc compromettre la sécurité du serveur. Ainsi, les développeurs de ces programmes publient régulièrement des mises à jour qui corrigent ces bugs et apportent de nouvelles fonctionnalités. Il est donc vital de disposer d’un serveur toujours à jour. Pour cela, exécutez les trois commandes suivantes sur le serveur:
|
1 2 3 |
root@serveur:~# apt-get update root@serveur:~# apt-get upgrade root@serveur:~# apt-get dist-upgrade |
La première commande va mettre à jour la liste des paquets alors que les deux dernières vont mettre à jour les paquets eux mêmes. Ces commandes sont à lancer régulièrement sur le serveur pour qu’il soit constamment à jour et protégé des failles de sécurité.
- Consulter les journaux
Même avec ces mesures de sécurité mises en place, il est nécessaire d’être vigilent. Ainsi, il est conseillé de contrôler régulièrement les fichiers journaux des différents services afin de déceler une éventuelle intrusion ou un problème sur un service qui pourrait mettre en péril la sécurité du serveur. Vous trouverez les fichiers journaux dans le dossier /var/log sur le serveur. Sachez également, que vous êtes dans l’obligation, aux yeux de la loi de conserver ces fichiers pendant au minimum un an. Pensez donc à les sauvegarder régulièrement.
Comme dit en début d’article, la sécurité informatique est un vaste domaine. Cet article n’est donc qu’une introduction à la sécurité sur les serveurs dédiés. Il est nécessaire de rester vigilant et de maintenir à jour le serveur tant au niveau des logiciels et que de leur configuration. Maintenant que le serveur est à peu près sécurisé, nous allons pouvoir installer et configurer un premier service: le serveur Web Apache. Ce sera le sujet du prochain article.
EDIT: cet article a été mis à jour suite aux remarques de ts, données en commentaire, concernant l’oubli de la commande chown qui permet de fixer le propriétaire et le groupe du fichier /home/NOM_UTILISATEUR/.ssh/authorized_keys dans la partie Créer un compte utilisateur. Une autre erreur a également été corrigée concernant le fichier /etc/fail2ban/filter.d/apache-w00tw00t.conf,voir les commentaires plus bas.
Bonsoir,
Novice mais envieux de me former, J’ai suivi depuis: « Installation d’Ubuntu Server 14.04 LTS BETA 64 bits sur un serveur Kimsufi » jusqu’à ce billet sans problème.
– J’ai crée un nouvel utilisateur.
– Je n’ai pas crée de mot de passe, je me suis dis que je n’en aurais pas besoin pour une authentification par clé.
-J’ai mis en place l’authentification par clé (que j’avais crée en même temps que celle de root (donc pas de mot de passe non plus) en la copiant sur le serveur, etc…, jusqu’à sa suppression du root.
– J’ai suivi le processus en vérifiant chacune de mes étapes dans une autre fenêtre de mon terminal.
-Quand j’essaie de me connecter en me référant au billet précédent par:
ssh NOM_UTILISATEUR@ADRESSE_IP -i CLÉ_PRIVÉE
il m’est demandé un mot de passe pour mon utilisateur, que je n’ai évidemment pas, puisque pas crée.
Je pensais qu’il allait se passer la même chose que ors de l’installation primaire, mais c’est vrai que là, pas de recours au manager de kimsufi pour y copier la clé. Bref, je suis largué sur ce point-là.
Je ne sais pas si j’ai été assez clair, et je voudrais bien trouver l’erreur que j’ai faite.
J’espère de l’aide pour pouvoir continuer ces super billets, merci beaucoup à l’auteur.
Bonjour,
il semblerait que j’ai omis une étape. Après avoir entré la commande suivante:
sur le serveur, il est nécessaire de fixer le propriétaire et le groupe du fichier /home/NOM_UTILISATEUR/.ssh/authorized_keys, avec la commande suivante:
Après cela, normalement, vous devriez pouvoir vous connecter. Merci pour votre commentaire, je vais de ce pas corriger cet article.
Quelle réactivité, merci beaucoup Justin, ça roule.
c’est là que je mesure mon niveau…mais je continue tellement ces billets sont clairs et accessibles.
Bonne continuation.
Bonjour,
je reviens dans ce billet, bien que je sois en train d’essayer de comprendre les noms de domaine et les redirections.
Mon problème se situe au niveau de fail2ban:
-la commande fail2ban-client status me retourne bien 2 jails: apache-w00t<00t et ssh
– Par contre fail2ban-client reload m'affiche: ERROR NOK: ('ssh',) uniquement.
Qu'est-ce que j'ai encore fait de travers ?
Bonjour,
désolé pour le retard. Comme ça, je ne vois pas vraiment de quoi cela pourrait venir. Je vous conseille de scruter le fichier journal de fail2ban /var/log/fail2ban.log. Pour cela, vous pouvez vous servir de la commande suivante:
Ceci permet d’afficher la fin du fichier de log. La commande attends de nouvelles données à afficher, ainsi en ouvrant un deuxième terminal connecté en SSH sur le serveur, vous pouvez redémarrer le service de fail2ban avec la commande suivante:
Et vous verez s’afficher dans le premier terminal de nouvelles informations utiles pour trouver l’origine du problème.
Merci pour votre réponse, mais j’ai tout réinstallé. Je n’ai plus la même erreur,
Cependant, toujours ERROR NOK, mais d’autres paramètres derrière…
Je vais suivre vos directives pour essayer de comprendre mon erreur et vous tiendrais au courant.
Merci encore et à la prochaine.
me revoilà avec mes soucis de fail2ban. J’ai suivi vos indications et voici les résultats:
– service fail2ban restart:
* Restarting authentication failure monitor fail2ban ERROR NOK: (‘No \’host\’ group in \’^ -.* »GET \\/w00tw00t\\.at\\.ISC\\.SANS\\.DFind\\:\\).* ».*\ »,)
– et voici le fichier journal:
2014-08-24 16:42:09,972 fail2ban.server : INFO Stopping all jails
2014-08-24 16:42:09,973 fail2ban.server : INFO Exiting Fail2ban
2014-08-24 16:42:11,498 fail2ban.server : INFO Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.11
2014-08-24 16:42:11,501 fail2ban.jail : INFO Creating new jail ‘ssh’
2014-08-24 16:42:11,610 fail2ban.jail : INFO Jail ‘ssh’ uses pyinotify
2014-08-24 16:42:11,708 fail2ban.jail : INFO Initiated ‘pyinotify’ backend
2014-08-24 16:42:11,716 fail2ban.filter : INFO Added logfile = /var/log/auth.log
2014-08-24 16:42:11,720 fail2ban.filter : INFO Set maxRetry = 3
2014-08-24 16:42:11,723 fail2ban.filter : INFO Set findtime = 600
2014-08-24 16:42:11,724 fail2ban.actions: INFO Set banTime = 600
2014-08-24 16:42:11,903 fail2ban.jail : INFO Creating new jail ‘apache-w00tw00t’
2014-08-24 16:42:11,904 fail2ban.jail : INFO Jail ‘apache-w00tw00t’ uses pyinotify
2014-08-24 16:42:11,930 fail2ban.jail : INFO Initiated ‘pyinotify’ backend
2014-08-24 16:42:11,936 fail2ban.filter : INFO Added logfile = /var/log/apache2/access.log
2014-08-24 16:42:11,939 fail2ban.filter : INFO Set maxRetry = 1
2014-08-24 16:42:11,942 fail2ban.filter : INFO Set findtime = 600
2014-08-24 16:42:11,944 fail2ban.actions: INFO Set banTime = 600
2014-08-24 16:42:11,947 fail2ban.filter : ERROR No ‘host’ group in ‘^ -.* »GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).* ».*’
2014-08-24 16:42:11,947 fail2ban.comm : WARNING Command [‘set’, ‘apache-w00tw00t’, ‘addfailregex’, ‘^ -.* »GET \\/w00tw00t\\.at\\.ISC\\.SANS\\.DFind\\:\\).* ».*’] has failed. Received RegexException(‘No \’host\’ group in \’^ -.* »GET \\/w00tw00t\\.at\\.ISC\\.SANS\\.DFind\\:\\).* ».*\ »,)
En fait, le problème d’erreur ssh semble réglé parce que ces soucis apparaissent quand je recharge fail2ban dans votre billet suivant, avec apache d’installé.
D’autre part, j’ai installé un Ubuntu sever de la même manière sur mon poste par Virtualhost et j’ai le même problème. Je dois donc faire la même mauvaise manipulation et je ne trouve pas mon erreur. Merci pour l’aide…
Question subsidiaire (ça montre le niveau): comment on sort du fichier journal?
Bonjour,
après avoir effectué quelques tests, il s’avère qu’il y a une erreur dans l’article. Le fichier /etc/fail2ban/filter.d/apache-w00tw00t.conf doit contenir la ligne suivante:
et non:
Une fois la modification faite, redémarrez fail2ban avec la commande suivante:
Je suis désolé pour l’erreur que j’ai laissé traîner. Je vais de ce pas corriger cet article. Pour votre dernière question, pour quitter la commande tail -f, il suffit d’actionner la combinaison Ctrl + C. Merci encore pour vos remarques pertinentes.
Bonjour,
c’est étrange j’ai suivi ce tuto il y a de ça un mois et mon fichier n’a pas été modifié pourtant il contient bien ceci :
[Definition]
failregex = ^ -.* »GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).* ».*
ignoreregex =
Je n’ai donc rien à corriger ?
Pardon de commenter deux fois mais ce qui est encore plus étrange c’est que je viens de copier/coller le code de mon fichier : /etc/fail2ban/filter.d/apache-w00tw00t.conf
Et je vois pas la ligne de code que je devrais avoir puisque je l’ai crée il y a un mois : failregex = ^ -.*”GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).*”.* or en editant mon fichier sous putty je vois la ligne de code déjà corrigée : failregex = ^ -.* »GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).* ».*
Est-ce un bug du blog ?
Bonjour,
la ligne que vous devez avoir dans le fichier /etc/fail2ban/filter.d/apache-w00tw00t.conf commence par failregex = ^ -.* »GET … Je ne penses pas qu’il y est un bug sur le blog lui même. J’avais fais une erreur dans l’article comme je vous l’explique dans un précédent commentaire. L’article est maintenant corrigé. Vous devriez pouvoir modifier votre fichier /etc/fail2ban/filter.d/apache-w00tw00t.conf et démarrer fail2ban sans erreur.
Oui c’est bien ça c’est le blog qui tronque le code. Je ne connais pas les balises ici pour mettre du code mais c’est bien le problème.
Bonjour,
normalement lorsque vous survolez avec la souris les exemples de code ou de commandes que je donne dans ce blog, vous devriez voir un ascenceur horizontal apparaître. Celui permet de voir la fin d’une ligne si elle est trop longue. Ainsi, si vous le glissez vers la droite, vous verez la fin de la ligne. De plus, une barre d’outils apparaît juste au dessus de l’exemple. Le dernier bouton à droite vous permet d’afficher l’exemple dans un onglet à part dans votre navigateur, comme ici:
Bonjour Justin,
faites le test par vous même en copier/coller l’ancienne et la nouvelle ligne de code dont il est question vous verrez qu’elles s’afficheront à l’identique :
L’ancienne : failregex = ^ -.* »GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).* ».*
La nouvelle : failregex = ^ -.* »GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).* ».*
Voyez par vous même mon exemple le système de commentaire à modifié ma ligne de code commençant par : « La nouvelle : failregex = »
Bonjour,
je viens de faire quelques tests et effectivement cela vient bien du système de commentaires par défaut de WordPress. Celui-ci a considéré le mot <HOST> comme une balise HTML qui n’est pas fermée et l’a donc supprimé. Je me suis rendu compte que le système de commentaires n’échappait pas du tout les balises HTML, ce qui en soit peut être dangereux (il est par exemple possible de faire du cross-site scripting). J’ai donc apporté une petite modification à ce blog afin qu’il échappe tout ce qui ressemble à une balise HTML et qu’il l’affiche directement sous forme de texte. Ainsi, le mot <HOST> devrait maintenant apparaître dans les commentaires. Désolé pour la confusion.
Bonjour,
Tout d'abord merci pour cet excellent tutoriel extrêmement complet notamment sur la partie messagerie. C'est d'ailleurs le seul qui fonctionne sur ce volet.
Ma question est : en suivant les différentes étapes j'ai tout le temps le comportement attendu sauf pour le fail2ban.
Quand je tape iptables -L -n je n'ai pas "multiport dports 22,115,NUMERO_PORT" mais uniquement "multiport dports 22" pourtant j'ai bien changer le port ssh ainsi qu'ajouter le sftp comme suit :
port = ssh,sftp,<MON_NUMERO_PORT>
J'ai zappé quelques chose ? (en fait je suis sur 14.10)
Bonjour,
je viens de faire le test sur la version 14.10 d’Ubuntu est cela fonctionne comme attendu. Avez-vous bien rechargé le fichier de configuration de fail2ban avec la commande fail2ban-client reload ? Si même après cette commande, ça ne marche pas (iptables -L -n ne retourne pas le contenu attendu), vous pouvez essayer de redémarrer complétement fail2ban avec la commande suivante:
Oui avant de poster mon message j'avais relancer fail2ban avec la commande restart. Mais aujourd'hui en relançant fail2ban avec reload ça fonctionne. J'ai bien le même résultat.
Merci beaucoup.
Du coup j'en profite pour savoir s'il y a une alternative a Postfix Admin qui est extrêmement rebutant en terme d'interface ?
Bonjour,
je suis heureux d’apprendre que vous avez pu résoudre votre problème. Concernant une alternative à Postfix Admin, la seule qui me vient en tête est éventuellement Webmin / Virtualmin. Cependant, d’après une rapide recherche, il me semble (je n’en suis pas certain car je n’ai pas creuser le sujet) que Webmin n’utilise pas le système de mapping entre Postfix/Dovecot et des tables dans une base de données MySQL. Ainsi, en choisissant cette alternative, il faudra sûrement revoir la configuration complète du serveur d’e-mails.