MSS Logo Web
Descriptif
· Basique
· Complet
Installation
· Packages
· Mac OS X
· Scripts
· Manuelle
Configuration
· MSS Graphical Tool
· Manuelle
· Directives
Utilisation
· Exemples
· Clients compatibles
Téléchargements
· SourceForge
· Historique
Support
· Faq
· Forum
Extras
· Sécurité
· Personnalise
· Traductions
· Publicité

Sécurité


1 - Peut on bloquer des intrusions après un certain nombre de tentatives ? (éviter le SSH Brute Force)

2 - Bloquage par le module d'authentification

3 - Bloquage par le firewall

4 - Bloquage par le module d'authentification

5 - Comment limiter le nombre de connexions simultanées non authentifiées ?

6 - Comment utiliser l'authentification par clefs à la place des mots de passe ?

7 - Crèation et chargement et de Clefs sous Unix

8 - Création et chargement de Clefs sous Windows

1 - Peut on bloquer des intrusions après un certain nombre de tentatives ? (éviter le SSH Brute Force)

Le logiciel MySecureShell ne gére pas ceci, cependant nous allons voir comment bloquer avec un module d'authentification, avec un firewall ou bien avec Fail2ban.
Retour au sommaire

2 - Bloquage par le module d'authentification

Il est possible de bloquer ces intrusions à l'aide du module d'authentification appellé "pam_tally". Pour savoir si vous le possédez, tapez la commande "locate pam_tally" :

locate pam_tally
/lib/security/pam_tally.so
/usr/sbin/pam_tally



Il existe des systèmes où il ne sera pas installé par défaut. Sur Mac par exemple où il n'existe pas du tout. En effet le portage de "pam_tally" sur certains systèmes est assez fastidieux, c'est pourquoi il n'existe pas forcément.

- Suivant les distributions, les fichiers peuvent avoir un autre nom. Voilà ce qu'il faut faire sur une distribution de type Debian (Ubuntu, Knoppix...), pour les autres, regardez quelques lignes plus bas.
- Dans le fichier "/etc/pam.d/common-auth", il faut rajouter la ligne :

auth required pam_tally.so onerr=fail no_magic_root



puis dans le fichier "/etc/pam.d/common-account", il faut rajouter la ligne :

account required pam_tally.so onerr=fail deny=3 reset no_magic_root



- Passons maintenant sur d'autres distributions du type Fedora Core(Red Hat...) :
- Dans le fichier "/etc/pam.d/system-auth", il faut rajouter la ligne :

auth required /lib/security/pam_tally.so onerr=fail no_magic_root
account required /lib/security/pam_tally.so deny=3 no_magic_root reset



Voici les options que vous pouvez modifier:
- deny=3 : bloque le compte à partir de 3 identifations échouées.
- magic_root : permet à "root" de faire un "su" sur l'utilisateur même si le compte est "banni".

Pour afficher les utilisateurs blacklistés, tapez "faillog -a".

faillog -a
invite



Maintenant, pour supprimer cette personne de la "blacklist", faites "faillog -r -u username".

faillog -r -u invite

Retour au sommaire

3 - Bloquage par le firewall

L'autre moyen de bloquer est par firewall. Ici nous allons voir avec Iptables comment bloquer les attaques. Vous devez également avoir installé Ulog pour les logs.
Avant de commencer, il faut vous assurer que le module "ipt_recent" est bien compilé ou qu'il est intégré dans votre noyau (kernel). Sinon il faudra recompiler celui-ci.
Pour savoir s'il est présent sur votre système, tapez "cat /boot/config-x.x.x-x | grep -i recent" :

cat /boot/config-x.x.x-x | grep -i recent
CONFIG_IP_NF_MATCH_RECENT=m



- x.x.x-x : correspond à votre version du kernel.

La réponse de "CONFIG_IP_NF_MATCH_RECENT" peut être :
- "=m" : qui signifie compilé comme un module.
- "=y" : intégré dans le noyau.

Une fois que vous avez vérifié l'existence sur votre système, renseignez ces lignes dans votre configuration d'iptables :

Vous devez créer une première chaîne personnalisée :

iptables -N SSH_WHITELIST



Puis ensuite ajouter une "Whilelist" pour les hôtes.

iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT



Maintenant ajoutez ces lignes qui vont permettre de paramétrer le bloquage et les logs contre le Brute Force SSH :

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP



- seconds 60 : c'est le temps que la personne reste "banni".
- hitcount 4 : c'est le nombre d'essais avant de se faire bannir.
- --ulog-prefix SSH_brute_force : c'est l'entête pour les logs.

La ligne qui suit est optionnelle si vous en possédez déjà une identique ou équivalente.

iptables -A INPUT -p tcp --dport 22 -j ACCEPT



Vous pouvez maintenant le tester ! Pour voir les logs, ils sont dans "/var/log/ulog/syslogemu.log". Tapez ceci pour les voir:

cat /var/log/ulog/syslogemu.log | grep SSH_brute_force



Si vous avez des hôtes qui appraissent "Blacklistés" et que vous voulez les faire appartenir à la "Whitelist", vous pouvez utiliser ceci:

iptables -A SSH_WHITELIST -s x.x.x.x -m recent --remove --name SSH -j ACCEPT



- x.x.x.x : mettre l'addresse IP à whitelister.

Vous pouvez également consulter cette liste en faisant ceci :

iptables -L SSH_WHITELIST

Retour au sommaire

4 - Bloquage par le module d'authentification

Pour parler de Fail2ban, le site officiel du projet est Fail2ban.
Le soft peut être éléchargé sur SourceForge sous forme de Sources, RPMs ou DEB. Ipcop et Gentoo ne sont pas en reste.

La configuration par défaut est suffisante pour se protéger des attaques brute force et c'est d'ailleurs la force de Fail2ban. A son lancement, le deamon se charge d'informer Iptables sur les régles adopter en cas d'attaques. Fail2ban a choisi d'étendre sa protection aux services ftp et apache ce qui fait apparaître trois paragraphes intitulés vsftp, apache et ssh dans le fichier de configuration.
A l'administrateur donc de définir quel service il veux protéger en renseignant la ligne enabled = true (activer) ou false (pas activer) dans le paragraphe du serveur concerné.

Nous allons ici voir un exemple pour protéger son serveur MySecureShell. On édite le fichier de configuration :

sudo vi /etc/fail2ban.conf
# Puis, dans le paragraphe :
[SSH]

# Pour activer la protection.
enabled = true
# Pour sauver les logs
logfile = /var/log/auth.log
Les paramètres de protection par défaut sont dans:
[DEFAULT]

# On autorise 3 connexions echoues par adresse IP distante
maxfailures = 3
# Le temps de bannissement sera de 900s
bantime = 900
# Laps de temps entre chaque tentative de connexion
findtime = 600s



Voilà, on peut vérifier que Fail2ban est en fonctionnement :

/etc/init.d/fail2ban status
Satus of fail2ban: fail2ban is running



Pour arrêter/démarrer le deamon après une modification dans la configuration :

/etc/init.d/fail2ban stop
Stopping fail2ban: .done
/etc/init.d/fail2ban start
Starting fail2ban: .done



Pour ceux qui souhaitent plus de documentation sur ce projet, voici quelques liens :
- Le site web officiel de Fail2ban
- http://www.the-art-of-web.com/system/fail2ban

Et enfin, si vous voulez voir d'autres moyen de contrer les attaques SSH (tel que tcp_wrappers par exemple), je vous conseil de jetter un oeil sur ce site :
http://la-samhna.de/library/brutessh.html
Retour au sommaire

5 - Comment limiter le nombre de connexions simultanées non authentifiées ?

Il est possible de limiter en éditant le fichier "sshd_config" se trouvant généralement dans "/etc/ssh" et d'y insérer cette ligne :

MaxStartups 5



- MaxStartups 5 : Pas plus de 5 connexions non authentifiées parallèlement sur votre serveur.
Retour au sommaire

6 - Comment utiliser l'authentification par clefs à la place des mots de passe ?

Il est possible de se connecter par clef et non plus par mots de passe. L'avantage est que l'on améliore énormément la sécurité !
Nous allons commencer par configurer le serveur SSH via le fichier "/etc/ssh/sshd_config". Editez-le et modifiez les lignes comme ceci:

PubkeyAuthentication yes
PermitEmptyPasswords no



Ensuite, les comptes utilisateurs dont vous voulez l'authentification par clef, devront être configurés SANS mots de passe. Pour ce faire, éditez le fichier "/etc/shadow" et remplacez le champ contenant le mot de passe par un "*" comme ceci:

invite:mot_de_passe_crypté:13031:0:99999:7:::



Remplacez par ceci:

invite:*:13031:0:99999:7:::



Dans la configuration d'SSH nous venons d'interdire l'authentification des mots de passe vide. Dans ce cas là, l'utilisateur invite ne possède plus de mot de passe puisqu'il est vide. La seule façon maintenant pour lui de s'authentifier est par une clef.

Nous allons voir 2 façons de créer et charger des clefs :
1 - Sous un système de type unix (Linux, Mac OS X...)
2 - Sous Windows
Retour au sommaire

7 - Crèation et chargement et de Clefs sous Unix

Nous allons créer une clef publique et une clef privée. Pour ce faire, utilisez la commande qui suit :

ssh-keygen -t dsa



Vous pouvez rajouter l'argument "-b" suivi du nombre de bits que vous voulez pour augmenter ou diminuer l'encryption.
Entrez ensuite le lieu où la clef va être stockée (laissez par défaut) puis tapez une "passphrase" (tapez une phrase).
Ensuite il faut envoyer la clef qui vient d'être crée vers le serveur.

cat .ssh/id_dsa.pub | ssh utilisateur@hote_distant "cat >> .ssh/authorized_keys"



Si cela a fonctionné, lorsque vous vous connectez, il vous demande une "passphrase" et non un mot de passe.

ssh utilisateur@hote_distant



Enter passphrase for key '.ssh/clients':
Il va maintenant falloir lancer l'agent SSH. Il s'occupera de vous demander la "passphrase" une bonne fois pour toute.

ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-SOX10636/agent.10636; export SSH_AUTH_SOCK;
SSH_AGENT_PID=10636; export SSH_AGENT_PID;
echo Agent pid 10636;



Les 3 lignes qui suivent votre commande sont à exécuter. Utilisez copier/coller par exemple.
Pour lancer l'agent tout en exportant les variables, il vous faut exécuter cette commande:

eval `ssh-agent`



Maintenant l'agent est lancé et l'environnement exporté ! Il ne reste plus qu'à ajouter la clef:

ssh-add ~/.ssh/id_dsa



Voilà, c'est terminé. Maintenant si vous essayez de vous connecter, vous n'aurez plus aucune demande.

Pour vérifier si un agent tourne sur le système, il faut un logiciel de type "keychain". Il vérifiera si un agent tourne; si ce n'est pas le cas, il en lancera un. Sur Mac, il existe un logiciel qui fait office de "keychain" qui s'appelle sshLogin. Il suffit de le télécharger et de l'installer (pas de configuration à faire, juste un redémarrage).

Si vous n'êtes pas sous Mac OS X, alors vous devez installer "keychain". Ensuite suivant votre "shell", vous devez insérer 2 lignes dans votre fichier de configuration du shell:
.bash_profile (bash), .zprofile (zsh) ou .cshrc (compatible csh)

keychain ~/.ssh/id_dsa
source ~/.ssh-agent-csh-${HOSTNAME}



Si vous utilisez un autre shell compatible "bash" vous devez insérer ces lignes :

keychain ~/.ssh/id_dsa
. ~/.ssh-agent-${HOSTNAME}



Cette fois-ci c'est terminé !
Retour au sommaire

8 - Création et chargement de Clefs sous Windows

Pour créer une clef, vous devez utiliser PuTTyGen.
Une fois téléchargé et lancé, cliquez sur "Generate". Vous devrez alors bouger la souris pour créer un code aléatoire.
Là où est écrit: "Public key for pasting into OpenSSH authorized_keys file:", c'est qu'il faut copier toute la clef si dessous, sur le serveur, à la suite du fichier "autorized_keys". Ensuite, entrez une "passphrase". Sauvegardez la clef publique et la clef privée en cliquant sur les boutons "Save public key" et "Save private key".

Maintenant il faut charger la clef. Téléchargez Pageant et lancez le.
Une fois lancé, il se trouve en bas à droite. Double cliquez dessus pour l'ouvrir et cliquez sur "Add key". Chargez ensuite la clef privée que vous avez exportée et entrez la "passphrase" précédement générée.

Pour charger automatiquement Pageant au démarrage placez un raccourci dans "Démarrer/Programmes/Démarrage". Ensuite éditez le raccourci et placez à la fin de la ligne, le lien complet de la clef privée (entre guillemets).

"C:\Program Files\PuTTY\pageant.exe" "C:\privatekey.ppk"



Note : Vous pouvez convertir des clefs fabriquées sur un système Unix pour Pageant avec l'utilitaire PuTTyGen. Il vous suffit de convertir la clef comme ceci: "Conversions/Import key". Il ne vous reste plus qu'à sauvegarder la clef privée et à la charger dans Pageant.
Retour au sommaire

Valid XHTML 1.1!