Sécuriser un serveur ssh

[Seagate]

Bonjour à tous,

Voilà je me suis lancé dans l'apprentissage de linux, et je suis en train de mettre en place un serveur SSH. J'ai donc fait quelques recherches, et je suis tombé sur openclassroom, j'ai donc suivi la démarche et j'ai installé openssh-server.
Esuite de quoi, j'ai mis en place une authentification par clé avec une passphrase assez longue (63 char). Mais ensuite ?

Je peux changer le port oui, mais lister les ports ouvert sur une machine n'est pas bien compliqué, et définir à quoi sert ce port prendra juste plus de temps, mais cela reste possible. Est-ce qu'il y a une autre solution que changer le port ? J'ai entendu parler de port-knocking, mais je n'en sais pas plus.

Ensuite les clés de connexions sont stockée dans le répertoire ~/.ssh, admettons qu'on parvienne à rentrer sur mon PC, comment faire pour que ce dossier sécurisé ? un chmod 0600 suffit-il vraiment ?

Merci d'avance pour vos réponse ou redirection :-)

[fred]

En règle général tu dois avoir un fichier permettant de surveiller les connexions (extension log en général), rien n'empêche d'automatiser la lecture de ce fichier (toutes les secondes par exemple) pour t'avertir d'une connexion inconnue et douteuse... Après j'utilise pas de serveur SSH, donc je peux me tromper.

[Seagate]

J'ai mis en place le port knocking, cela me semble une solution efficace :-)
Il y n'y a qu'un souci pour le moment, c'est que nimporte qui connaissant la séquence peut ouvrir le port, et avec un sniff réseau, c'est faisable, mais ça limite déjà pas mal car le port n'est ouvert que lorsque j'en ai besoin, en dehors de ces moment il est fermé :-)

[DreAmuS]

Salut,

Je te renvoie ici : http://www.alsacreations.com/tuto/li...-iptables.html

Iptables c'est pas comme les antibiotiques la c'est systèmatiques.

Perso, j'ai toujours suivis ce type de process et ça m'avais réussis sur Leaseweb.

[T3hty]

Le port knocking est certe intéressant mais ça reste de l'obfuscation, si le moyen est découvert, tu perds toute sécurité, et en plus gêne plus au niveau utilsation que l'attaquant.

Pour bien sécuriser ssh, il faut avoir une bonne configuration du serveur. Si tu veux vraiment durcir ton serveur ssh, je te renvoi vers ce lien qui donne des astuces pour notamment renforcer le chiffrement de ssh, plus deux ou trois autres configurations http://www.reddit.com/r/netsec/comme..._secure_shell/ .

Enfin pour ce qui est de ta clef de connexion, si un attaquant arrive sur ton pc, soit il est connecté avec ton compte, et pourra de toutes façon lire ta clef privée, et dans tout les cas cherchera à passer root, et là aucune protection ne pourra l'arrêter pour y accéder.
Cependant, si tu dis avoir chiffré cette passphrase avec un mot de passe de 63 char, il lui faudra un certain temps avant de casser le chiffrement de cette clef, au moins le temps que tu découvres l'attaque et est changé la clef.

Le seul problème que je vois là, c'est que tu n'as pas précisé la taille de ta clef privée, les standards actuels préconise 2048 bits pour une clef RSA qui serait valable jusqu'en 2030, 3072 et 4096 valable au moins jusqu'en 2030, voir beaucoup plus.

[_42_]

Bonsoir,

Au port Knocking, il existe une solution alternative qui me semble mieux - mais que je n'ai pas encore réussi à mettre sur mon serveur, c'est fwknop !
De ce que j'ai compris, c'est du "Port Knocking chiffré". Le service ssh apparaît closed, jusqu'à ouverture du service par fwknop ! -si j'ai bien compris-
Il est possible d'utiliser des correspondances matérielles, avec des clés symétriques ou asymétriques, injecter des règles de filtrages firewall, ...

Perso, il faut que je fasse d'autres essais ...

Pour en revenir, à ta configuration SSH, il y a certaines choses, en effet à absolument paramétrer ...
- changer le port par défaut - mais ne pas croire que c'est la réponse ... un coup de sniff, peut révèler le port utilisé
- Protocol 2 only
- ne pas permettre l'accès root
- n'utiliser que des clés d'authentification ...
sont un minimum ;-)

[DreAmuS]

Merci _42_ pour fwknop que je ne connaissais pas, je vais me renseigner dessus.

[_42_]

Avec plaisir ;-)

Pour mon serveur SSH, j'ai rajouté le serveur MySecureShell que je trouve bien plus agréable à utiliser ...
Attention la directive "Subsystem sftp /usr/lib/openssh/sftp-server" du fichier de config du serveur SSH a à-priori même but !

La configuration de MySecureShell est aisé à comprendre, par contre, il faut bien veiller à ce que les utilisateurs SSH et pour sh(ell), celui de MySecureSSH !
Tu peux vraiment faire des config poussées "aux petits oignons"

[Seagate]

Merci _42_, je vais regarder les alternatives dont tu parles

[_42_]

Merci _42_, je vais regarder les alternatives dont tu parles

Attention, MySecureShell n'est pas une alternative - c'est plus comme un greffon à OpenSSH ;-)

Fwknop-server est bien une alternative, méconnue, au "Port Knocking".

Concernant la securisation de ton serveur OpenSSH, tu as de bonnes recommandations dans la documentation Debian, qui sont applicables bien-sur, même si tu ne fonctionne pas avec cet OS :
https://www.debian.org/doc/manuals/s...rvices.fr.html <= lis le chapitre Securisation de SSH.

[Creased]

Bonjour, si jamais ça peut servir voici en général la configuration minimale pour mon service SSH (sans parler de netfilter, fail2ban et du port knocking):

#### Création d'un nouvel utilisateur ####
adduser Creased --force-badname
usermod -s /bin/bash Creased

visudo
# Modifier la liste des sudoers, pour éviter tout risque retirer le sudo (apt-get purge sudo)
Creased ALL=(ALL:ALL) ALL

#### SSH ####
apt-get -fy install openssh-server

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
cat /dev/null >/etc/ssh/sshd_config

cat /etc/ssh/sshd_config <<EOF
# Exemple, à modifier selon la disponibilité (à titre d'info, les scans furtifs sont effectuées la plupart du temps en dessous des ports >1024 pour conserver un bon rapport discrétion/efficacité/efficience)
Port 54367
Protocol 2
AddressFamily inet
X11Forwarding no
TCPKeepAlive no
ClientAliveInterval 600
ClientAliveCountMax 3
# A modifier selon la mutualisation dudit serveur
ListenAddress 0.0.0.0
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
PermitBlacklistedKeys no
# Remplacer par l'utilisateur crée ci-dessus
AllowUsers Creased
LoginGraceTime 60
StrictModes yes
PermitRootLogin no
IgnoreRhosts yes
HostbasedAuthentication no
IgnoreUserKnownHosts yes
PermitEmptyPasswords no
UsePAM no
ChallengeResponseAuthentication no
PasswordAuthentication no
UseLogin no
SyslogFacility AUTH
LogLevel INFO
PrintLastLog yes
MaxAuthTries 2
MaxStartups 10:30:60
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
Banner /etc/issue

EOF

# Ajout d'un message d'avertissement pour éviter tout problème en cas de procédures judiciaires suite à un piratage
nano /etc/issue
AVERTISSEMENT: L'accès à ce système est restreint aux seuls utilisateurs autorisés à s'y connecter.

# Création des jeux de clés pour l'authentification par clé privée
rm /etc/ssh/ssh_host_*
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa
su Creased
mkdir ~/.ssh
cd ~/.ssh
ssh-keygen -t rsa -b 2048
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/authorized_keys 
chmod 700 ~/.ssh
exit
/etc/init.d/ssh restart

Il ne restera plus qu'à conserver de manière sécurisée la clé privée générée (ici par exemple, elle s'appelle id_rsa) et vous souvenir de la passphrase permettant à l'agent d'authentification de SecureSHell de lire votre clé privée.

Cette solution reste perfectible en utilisant le fameux "port knocking" vous permettant de cacher de manière plus ou moins performante le port d'écoute de votre service, fail2ban afin d'éviter les attaques par DoS ou Bruteforce qui permettrait à un pirate de faire du token hijacking (technique exploitée avec succès à la defcon), iptables pour dissimuler les services en écoute tel que les services FTP ou autre (à noter que vous pourrez utiliser le SSH Tunneling pour router vos paquets dans un tunnel sécurisé, ainsi vous pourrez accéder à tout les services locaux une fois la session SSH démarrée).

Voilà voilà, si jamais vous avez des améliorations, je suis tout ouïe.

[_42_]

Merci à toi Creased.

Personnellement, je t'invite a baisser sérieusement la valeur de la variable LoginGraceTime à 30, voire 10 secondes - mieux -
10 secondes, ça laisse vraiment le temps, plus que nécessaire ... et, encore 10 secondes, c'est vraiment long.

La variable 'UsePAM' je la basculerait à Yes ... comme ça le système SSH ferait la correspondance le système de gestion des droits PAM.

Je vois que tu ulitises la variable AllowUsers. Très bien, cela signifie dans ton cas, qu'il n'y a qu'un seul utilisateur qui a le droit de se connecter.
C'est un renseignement intéressant, précieux - reste plus qu'à tenter un bruteforce
Pour ne pas donner ce renseignement, utilises plutôt AllowGroups groupssh - nom de groupe donné pour l'exemple -, que tu auras préalablement créé, sans droits particuliers, auquel tu ajouteras ton user ;-)

Ensuite, contrairement à ton script, je ne ferais pas l'erreur de donner tous les droits systèmes à ton user en question !
Tu te connectes, avec ... et, après si tu as de l'administration à faire, tu montes en droit administrateur, avec un véritable compte root qui n'a aucunement le droit de se connecter à SSH.

La deuxième ligne de ton script est ABSOLUMENT non nécessaire, car si tu as vraiment besoin de spécifier un autre shell, que celui par défaut de ton OS GNU/Linux, tu as justement l'option --shell qui remplit EXACTEMENT cette fonction, à-propos de la commande 'adduser'.


Après, je peux me tromper ... ;-)

[Creased]

Je t'invite a baisser sérieusement la valeur de la variable LoginGraceTime à 30, voire 10 secondes

10 secondes pour un passkey long peut être très juste à mon gout (surtout lorsque j'utilise JuiceSSH Android, car le clavier n'est pas très adapté aux mots de passe forts), mais j'en tiens compte et l'ai donc baissé à 20, un équilibre entre tes valeurs

La variable 'UsePAM' je la basculerait à Yes

Le PAM permet de s'authentifier au niveau d'un hôte, ici il s'agit d'une authentification par jeu de clé, je doute donc qu'il soit nécessaire de l'activer d'autant plus que l'authentification par mot de passe est refusée avec :

PasswordAuthentication no

S'il s'agit d'un paradigme de traçabilité, la journalisation des authentifications de SSH est faite via syslog:

SyslogFacility AUTH
LogLevel INFO

reste plus qu'à tenter un bruteforce

C'est pourquoi je parlais de fail2ban Mais merci pour le

AllowGroups

je dois bien avouer que je ne connaissais pas

je ne ferais pas l'erreur de donner tous les droits systèmes à ton user en question !

Voilà un point qui en effet me gène dans ma configuration. Le mode strict étant sur YES, les droits de modification de cette clé doivent appartenir uniquement à cet utilisateur, mais il est possible de lui révoquer, j'ai testé à l'instant et cette configuration fonctionne:

chmod 400 ~/.ssh/id_rsa
chmod 400 ~/.ssh/authorized_keys 
chmod 500 ~/.ssh

L'édition de ces clés est alors uniquement possible dans un contexte d'exécution privilégié (root)

Pour ceux qui ne comprennent pas, voici un tableau très facile à retenir qui permet de définir les droits :

Read (2²)	Write (2¹)	eXecution (2º)	Valeur décimale
0	0	0	0
0	0	1	1
0	1	0	2
0	1	1	3
1	0	0	4
1	0	1	5
1	1	0	6
1	1	1	7

Les droits seront donc dépendants de ces valeurs et s'attribueront en décimal de cette manière :

chmod <val_decimale_utilisateur><val_decimale_groupe><val_decimale_autres> <fichier>

La deuxième ligne de ton script est ABSOLUMENT non nécessaire, car si tu as vraiment besoin de spécifier un autre shell, que celui par défaut de ton OS GNU/Linux, tu as justement l'option --shell qui remplit EXACTEMENT cette fonction, à-propos de la commande 'adduser'.

En effet elle est inutile dans le cas présent, il s'agit plus d'un réflexe mnémotechnique que j'ai pris en apprenant les commandes basiques de Linux (l'idée était d'apprendre toutes les commandes nécessaires à l'administration) ...

Merci pour tes conseils, j'en prends bonne-note

[_42_]

10 secondes pour un passkey long peut être très juste à mon gout (surtout lorsque j'utilise JuiceSSH Android, car le clavier n'est pas très adapté aux mots de passe forts), mais j'en tiens compte et l'ai donc baissé à 20, un équilibre entre tes valeurs

Utilises donc un gestionnaire de mot-de-passe tel que KeePass ... Tu verras que 10 secondes, c'est largement suffisant !
Quitte à retenter une nouvelle fois, la connexion ;-)

[_42_]

Une documentation ANSSI intéressante à ce propos :

http://www.ssi.gouv.fr/uploads/IMG/p...H_NoteTech.pdf