Il m’est arrivé de détecter que fail2ban ne faisait pas bien son job avec proftpd.
En effet, un log comme suit :

déc. 08 04:26:16 xxx.sn4ky.net proftpd[20043] 127.0.0.1 (174.133.xxx.xxx[174.133.xxx.xxx]): USER Administrator: no such user found from 174.133.xxx.xxx [174.133.xxx.xxx] to 217.174.xxx.xxx:21

n’est pas correctement interprété par fail2ban (fail2ban ne parvient pas à « lire » le format de la date – date dont il se sert afin de déterminer la fréquence des tentatives de connexions).

Ceci n’est pas un problème d’une regex mal configurée, comme on peut le voir en utilisant l’outil fail2ban-regex (qui permet de valider le bon fonctionnement d’un filtre dans /etc/filter.d/profptd.conf) :

fail2ban-regex /var/log/proftpd/proftpd.logbak /etc/fail2ban/filter.d/proftpd.conf
Found a match for 'd xxx.sn4ky.net proftpd[20043] 127.0.0.1 (174.133.xxx.xxx[174.133.xxx.xxx]): USER Administrator: no such user found from 174.133.xxx.xxx[174.133.xxx.xxx] to 217.174.xxx.xxx:21
' but no valid date/time found for 'éc. 08 04:26:16'. Please contact the author in order to get support for this format

Il apparaît que le démon proftpd démarre en utilisant la valeur de la variable d’environnement LANG, définie par la locale par défaut utilisée sur le système au moment du démarrage de celui-ci :

# echo $LANG
fr_FR@euro

Une solution permet de contourner ce problème, modifier les locales afin d’utiliser un environnement en Anglais, qui serai reconnu correctement par proftpd.
MAIS, je n’aime pas trop cette solution (bien qu’efficace, changer sa locale par défaut peut parfois causer des soucis).

Une autre solution, beaucoup plus « soft » m’es venue à l’esprit :
On va tout d’abord ajouter une locale à notre système :

# dpkg-reconfigure locales

(on va ajouter une locale en anglais, par exemple en_US.UTF-8 – universelle en plus)
On ne change pas la locale par défaut, par contre, on va éditer le fichier /etc/default/proftpd.conf et y rajouter la ligne suivante :

export LANG=en_US.UTF-8

Par la suite, il ne reste plus qu’à redémarrer proftpd, puis constater, dans les logs :

déc. 10 01:50:32 xxx.sn4ky.net proftpd[8594] 127.0.0.1: ProFTPD 1.3.3a standalone mode SHUTDOWN
Dec 10 01:50:34 xxx.sn4ky.net proftpd[9237] 127.0.0.1: ProFTPD 1.3.3a (maint) (built Sun Nov 13 2011 22:40:44 UTC) standalone mode STARTUP

Miracle ! le format de sortie du log a changé !
Et cette fois, il est lisible par Fail2ban (un fail2ban-regex pour s’en convaincre, après avoir fait un petit coup de sed -i.bak 's/déc\./Dec/g' /var/log/proftpd/proftpd.log pour s’en convaincre.

En espérant en avoir dépanné plus d’un.

Pour cela, on va utiliser ce qu’on appelle les ACL, les listes de contrôle d’accès.

Avec votre gestionnaire de package préféré, installer les utilitaires fournis par le paquet « acl »

aptitude install acl

Remontez la partition que vous souhaitez contrôler avec les ACL, avec l’option adéquate :

mount -o remount,acl /home

Dans le fstab, rajouter l’option ‘acl’ au point de montage
Par exemple :

cat /etc/fstab
/dev/sdb    /home    ext3    defaults,acl        0       2

Pour finir, appliquez les ACL sur le ou les répertoires concernés !

setfacl -R -m u:sn4ky:rwX,u:www-data:rwX,d:u:sn4ky:rwX,d:u:www-data:rwX,g::r-X,o::r-X,d:g::r-X,d:o::r-X,m::rwX,d:m::rwX /home/sn4ky/public_html/blog/wp-content/

Explications :

• setfacl : le programme (installé avec acl)
• -R : récursif
• -m : modifier (ou créer) une ACL
• u:sn4ky:rwx : défini que l’utilisateur sn4ky (moi) a les droits rwx sur les fichiers et dossiers existants
• u:www-data:rwx : défini que l’utilisateur www-data (Apache) a les droits rwx sur les fichiers et dossiers existants
• d:sn4ky:rwx : défini les droits rwx sur tout fichier ou dossier nouvellement créé après la mise en place de l’ACL (default)
• d:www-data:rwx : idem
• m::rwx : masque a appliquer sur tous fichiers et dossiers courants
• d:m::rwX : masque a appliquer pour toute future création de fichiers ou de dossiers
• g::—,o::— respectivement pour group et other

n.b. : le flag X indique : excécution uniquement si l’objet est un répertoire ou s’il y a déjà les droits d’exécution pour d’autre utilisateurs (manpage : execute only if the file is a directory or already has execute permission for some user)

La réponse avec un exemple :

<location ~ "/(repertoire1|repertoire2)/.*">
	Order Deny,Allow
	Deny from all
	allow from 91.121.12.183
</location>

Alors après, vous pouvez jouer de fantaisies diverses et variées pour subvenir a vos besoins.

Configuration du serveur

Ouvrez avec votre éditeur de texte favoris le fichier de configuration du démon SSH (/etc/ssh/sshd_config pour Debian par exemple) et ajoutez ces lignes :

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

(La ligne AuthorizedKeysFile indique à sshd où aller chercher les clés publiques, %h représente le nom de l’utilisateur local du système)
Sauvegardez et fermez la config avant de relancer le démon SSH.
(Trick : un

/etc/init.d/ssh restart

ne kill pas la session SSH a partir duquel il aurait été lancé)

Création des clés

Sous Windows

Nous allons avoir besoin de l’outil PuTTYgen afin de générer les clés RSA.
Lancez le, sélectionnez RSA, et une taille de clé (1024 bits est une bonne valeur, ne descendez pas en dessous de 512 bits), et cliquez sur « Generate ».
Vous devez bouger votre souris dans le cadre prévu à cet effet, ce qui génèrera de l’entropie, afin de s’assurer que la clé sera unique.

Une fois le couple de clés crées, vous pourrez y rajouter un commentaire pour la clé (indispensable pour savoir à qui appartient la clé) et y mettre une passphrase. La passphrase va servir a encrypter la clé privée. Sans cette passphrase, impossible d’utiliser la clé.

Puis enfin, on clique sur « Save Private Key » et « Save Public Key ».
Veillez à bien ranger (voir protéger dans un répertoire Utilisateur crypté) votre clé Privée.

Les fichiers ressemblent à ça :
Clé privée

PuTTY-User-Key-File-2: ssh-rsa
Encryption: aes256-cbc
Comment: user@machinelocale
Public-Lines: 4
AAAAB3NzaC1yc2EAAAABJQAAAIEAga67iAb6FCLKzQN5O/CMwj0tD341I/GkFVQO
MK/grigk8V/qrWO+ljiMsGgZrkJ3EPqqhq3kxp83xOTBk/93DeXtnJ3PFZEwwFed
RO3Fww3V2oMAa5mbLkxwHXEKPx4V+aRcuZWaTnz8Ej7dyMRk112udJjgYsNrzzuD
xtZ+5h0=
Private-Lines: 8
CQZH1dkFNNWdaGmG+tljnUDc1/0tFWoUQO9q5Cc8uIW3l17GTTeJuSZ8QRay3/T1
2z3YQhlqfdn5UEAAnIvAFLaL4HFBbNJaaVh//44v0fxXHDpdsLcdDdOEINFVWUAA
QaQ+yMHaBhYc864kouZlKJujhZEU7lj90zNZ24Vt0YnLSngNk/3Mvw3UwTXeBOZT
7PckIKpla5ZWINu/iIG8/a+LlRYT8QbDskC7eWKSSj0f5ZDgofcYzg+B8Bxwcasr
neg1sv7b4dM7RQe7+GJAeIeHzS2RMv+l9C/gVDL8/sVhX7QXTo2w39s0xcXvNKuh
cmvFn+EvFG0LHDbi8MQxhfN9bbJ6NAVKvPUIznM5XCWhVDHRjiytycHL9fpg42u0
Z/BDYNVdB4e06uotgcK8UbFS4rTLnSBBdT5A4AiiqvJoyX7mjcZMpLca542+Gdmq
axhr/FPSEUImNEC02u5/Dg==
Private-MAC: fed2e7a78bb4ed7e566c506701cf2b5d6f701a32

Clé publique

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "user@machinelocale"
AAAAB3NzaC1yc2EAAAABJQAAAIEAga67iAb6FCLKzQN5O/CMwj0tD341I/GkFVQO
MK/grigk8V/qrWO+ljiMsGgZrkJ3EPqqhq3kxp83xOTBk/93DeXtnJ3PFZEwwFed
RO3Fww3V2oMAa5mbLkxwHXEKPx4V+aRcuZWaTnz8Ej7dyMRk112udJjgYsNrzzuD
xtZ+5h0=
---- END SSH2 PUBLIC KEY ----

(Vous noterez que la clé publique est contenue au début du fichier contenant la clé privée)

Afin de rentre compatible votre clé Publique générée, nous allons modifier quelques lignes.

• Copier le commentaire entre les guillemets, a la fin de la clé
• ajouter « ssh-rsa » en début de clé
• Supprimer les deux premières lignes
• Supprimer la dernière ligne
• Supprimer les retours à la ligne

Vous devriez vous retrouver avec un fichier qui ressemble à celui-ci :

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAga67iAb6FCLKzQN5O/CMwj0tD341I/GkFVQOMK/grigk8/qrWO+ljiMsGgZrkJ3EPqqhq3kxp83xOTB/93DeXtnJ3PFZEwwFedRO3Fww3V2oMAa5mbLkxwHXEKPx4V+aRcuZWaTnz8Ej7dyMRk112udJjgYsNrzzuDxtZ+5h0= user@machinelocale

Il ne reste qu’à copier la clé publique dans le fichier « $HOME/.ssh/authorized_keys » de du compte utilisateur sur la machine distante (une clé publique par ligne du fichier) et configurer PuTTY :

Indiquez le host sur lequel se connecter, puis renseignez le chemin de la clé privée dans « Con­nec­tion » -> « SSH » -> « Auth« . Dans la rubrique « Connection » -> « Data » il est également possible de renseigner le login a utiliser automatique à la connexion. (même effet que de mettre login@host dans la case réservée au hostname)

Sous Linux

Pour générer le couple de clés RSA, on va utiliser la commande ssh-keygen :

ssh-keygen -t rsa -b 1024 -C test@machinelocale

L’option -C défini le commentaire qu’on va attribuer à la clé publique.
Le script demandera une éventuelle (fortement recommandée tout de même) PassPhrase.

Par défaut, les clés seront générées dans ‘$HOME/.ssh/id_rsa’ et ‘$HOME/.ssh/id_rsa.pub’ pour les clés privées et publiques. (On peut noter que la clé privée a un masque en 600)

Il ne reste qu’à copier la clé publique dans le fichier « $HOME/.ssh/authorized_keys » de du compte utilisateur sur la machine distante (une clé publique par ligne du fichier).
Si vous avez enregistré votre clé publique à l’endroit par défaut, plus rien a configurer, sinon « ssh -i /path/to/rsa_key.pub ».

Désormais, lors de vos connexions à vos serveur favoris, le système vous demandera la passphrase (si vous en avez configuré une) plutôt que le mot de passe du compte Unix.

Pour aller plus loin

(parce que j’aime bien pousser les choses un peu plus)

N’autoriser la clé que pour une IP en particulier

Il est tout a fait possible de demander au serveur distant de n’autoriser la connexion pour une clé a partir d’une IP, il suffit de rajouter, devant ssh-rsa un champ supplémentaire : from= « ip » . Ainsi, on se retrouve avec :

from="217.174.206.179" ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAga67iAb6FCLKzQN5O/CMwj0tD341I/GkFVQOMK/grigk8/qrWO+ljiMsGgZrkJ3EPqqhq3kxp83xOTB/93DeXtnJ3PFZEwwFedRO3Fww3V2oMAa5mbLkxwHXEKPx4V+aRcuZWaTnz8Ej7dyMRk112udJjgYsNrzzuDxtZ+5h0= user@machinelocale

Désactivations

• On peut désactiver la connexion root par SSH (enfin il est même nécessaire de désactiver root par SSH, mais activez sudo avant…) :

aptitude install sudo
sudoedit /etc/sudoers

et rajoutez une ligne dans ce style (my_secured_account est bien sur le nom de votre compte shell) :

my_secured_account   ALL=(ALL) ALL

Puis connectez vous sur votre my_secured_account et tapez sudo -s (il vous demande un mot de passe la première fois, souvenez-vous en !!! et RTFM pour l’utilisation de sudo, mais c’est super simple.) pour obtenir un privilège root par exemple.
Enfin, désactivez le login de root dans sshd_config :

PermitRootLogin no

• On peut désactiver complètement la connexion par mot de passe :

PasswordAuthentication no
UsePAM no

ATTENTION ! Ce n’est pas ma faute si vous n’avez plus accès à votre serveur suite à ces deux dernières modifications (FACULTATIVES bien sur)

Source : Anthony Desvernois

Voici une petite astuce qui vous permettra de désactiver ce temps d’attente lorsque vous installez un module pour Firefox.

1) Allez directement dans le « about:config », pour cela ouvrez un nouvelle onglet et tapez about:config, un message va apparaitre, acceptez les risques.

Maintenant que vous êtes dans le about:config, recherchez security.dialog_enable_delay dans le case "Filtre :" comme ci-dessous :

En dessous de « Valeur », double cliquez et mettez-y 0 (zéro) comme ci-dessous :

Vous n’êtes pas obligé de redémarrer Firefox, essayez simplement d’installer un module et vous n’aurez plus de temps d’attente mais directement le message « Installer maintenant ».

Vous allez me dire que placer le -delete n’importe où dans la commande changera pas grand chose ! Et bien je vais vous répondre que si ! En fonction de l’endroit où elle est placée, elle peut engendrer de très gros problèmes pour vos fichiers !

Voyons ensemble ce que nous dit la documentation de Debian et celle de Ubuntu :

Debian (e.g : version etch) :

  -delete
         Delete  files; true if removal succeeded.
         If the removal failed, an error message is issued.
         Use of this action automatically turns on the '-depth' option.

Ubuntu :

 -delete
    Delete files; true if removal succeeded.
    If the removal failed, an error message is issued.
    If -delete fails, find's exit status  will  be
    nonzero (when it eventually exits).
    Use of -delete automatically turns on the -depth option.

    Warnings:  Don't  forget  that  the  find  command line is evaluated as an expression,
    so putting -delete first will make find try to delete
    everything below the starting points you specified.  [...]

Et là on se rend vraiment compte de la gravité des choses ! Si vous le mettez en début de ligne, find va détruire récursivement tout ce qui se trouve sur son chemin. En gros, la commande va faire exactement la même chose que si vous aviez fait un « rm -rf * ».

En revanche si vous le placez à la fin, vous vous contentez de supprimer les fichiers qu’il trouve selon les critères de recherche spécifiés…

Moralité de l’histoire : au début ça défonce tout tandis qu’à la fin ça fait son boulot !

Il semblerait que le problème soit résolu à partir de la version lenny, mais le souci c’est que Debian est pas foutu de mettre à jour la documentation du « man ».

Et je vous conseille de ne pas utiliser le -delete devant sinon vous risqueriez de perdre tous les fichiers de votre serveur de production alors que vous cherchiez juste à supprimer les fichiers Thumbs.db de vos tux !)

Nous allons voir ensemble comment exporter une base mysql et ensuite de la GZIP sans que mysqldump nous harcèle avec un mail pour nous dire tout ce qu’il vient de faire.

/usr/bin/mysqldump --lock-tables -v -h localhost -u root--password=1234 MABDD 2> /dev/null | /bin/gzip > /MONREP/backup_sql_20101129.sql.gz

Aide :
-u root : remplacer root par votre utilisateur
–password=1234 : remplacer 1234 par votre mot de passe
MABDD : remplacer MABDD par la base que vous souhaitez sauvegarder
>2 /dev/null : Sert à rediriger un contenu dont on a pas besoin, et qui ne doit pas être sauvegardé ni affiché à l’écran.
MONREP : remplacer MONREP par la destination où vous souhaitez sauvegarder votre base.

Et voilà, pas de mail, le résultat de mysql tombe directement dans /dev/null.

rename 's/\.JPG$/\.jpg/g' *.JPG

et de manière générale, pour passer le nom de ses fichiers en minuscule :

rename 'y/A-Z/a-z/' *

Supprimer les caractères accentués et les espaces dans le noms de vos fichiers :

find -type f -execdir rename 'y/éèêàâôî /eeeaaoi_/' {} \;

message="taratata voici un message bien long"
echo ${message:0:`echo $(( ${#message} - 3 ))`}

Ici voici ce que l’on opère :

${#message}

Calcule la taille de la chaine

echo $(( ${#message} - 3 ))

retourne la taille de la chaine soustrait de 3

echo ${message:0:`echo $(( ${#message} - 3 ))`}

retourne la chaine depuis le premier caractère (0) jusqu’au nombre calculé avant.

find / -type l | perl -lne 'print if ! -e'

Juste après le find vous avez un « / ». Mettez le répertoire que vous voulez scanner.