La majorité des systèmes d’informations hébergent des systèmes dit Open (Unix, Unix-Like) et la méthode d’administration se fait via (Open)SSH. Un excellent protocole chiffré qui permet d’avoir accès à son serveur de façon sécurisé si on respecte quelques règles de bases. Pour PCI DSS, l’auditeur vérifiera que les serveurs SSH installés soient bien conformes à la documentation de durcissement et surtout appliqués sur l’ensemble des machines. Ce mini guide permet de mettre en conformité vos systèmes Linux, AIX, HP-Ux, Solaris….
Bref rappel pour les admin Windows 🙂 …. SSH est normalisé par des RFC (Request For Comments) allant du 4250 à 4254. Ils expliquent le chiffrement supportés.
Bien entendu, les protocoles Telnet, RSH, RLOGIN sont désactivés. Ne pas hésiter à dés-installer les services du système (Obligation dans le cas de PCI DSS).
Je n’aborde pas le durcissement de Putty et PuttyGen qui seront étudiés dans un prochain guide de durcissement.
La majorité des opérations présentées vont s’effectuer dans le fichier /etc/sshd/sshd_config
Etape N°1: Forcer le service SSH en version 2.
On édite le fichier situé dans /etc/ssh/sshd_config
Etape N°2: Un utilisateur unique et identifié par un compte nominatif
On retire l’accès ssh au compte root par défaut il est à yes.
# Authentication: LoginGraceTime 120 PermitRootLogin yes StrictModes yes
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
Etape N°3: Qui s’est connecté avant vous en ssh
On affiche à l’utilisateur (c’est pas madame Michu qui se connecte en SSH) la précédente connexion et grâce à l’usage de compte nominatif il peut voir qui s’est connecté à son système.
Etape N°4 : Qui peut se connecter et à partir d’ou ?
Le service SSH permet d’autoriser un certain nombre d’utilisateurs et d’IP associées pour autorisé la connexion à celui-ci. Cette méthode est à privilégiée pour une machine fortement exposée. Les directives utilisées sont AllowUsers et AllowGroups.
Etape N°5 : On change le port de connexion
Pour éviter les accès par script, on modifie le port d’écoute du service SSH. Il y a deux politiques sur le sujet. Mettre le port d’écoute en dessous de 1024 ou au dessus.
Etape N°6 : Le port Forwarding
Dans le fichier de configuration du service SSH, il existe une directive AllowTCPForwarding. Cette directive permet de rediriger un flux à travers le serveur ssh. La redirection des flux doit être désactiver sauf exception fortement justifié…c’est une porte ouverte à toutes les attaques par rebond.
On fait la même chose pour X11 (On n’installe pas X11 sur un serveur…on n’est pas sous Windows 🙂 ).
X11Forwarding no
Etape N°7 : On arrête les connexions par identifiants et mots de passe
Les systèmes sont configurés par défaut pour se connecter par userID + mot de passe, c’est pas mal comme méthode mais cela n’est pas vraiment digne de confiance au niveau PCI DSS, ni au niveau d’une PSSI qui tient la route.
Combien de compte existe avec admin/admin & admin/123456. On ne rigole pas je viens de le voir chez un client sur des systèmes critiques….sous contrat d’infogérance de SSII au CAC40 sur une plateforme à plusieurs centaines de K€.
le risque est fort. On va donc créer des clés ssh de confiance entre le client et le service SSH (le serveur).
Il existe pas mal de tuto sur le net qui explique comment faire…juste pour l’info j’ai fait ça sur mon mac. J’ai bien entendu détruit cette clé due à l’information FingerPrint 🙂
# ssh-keygen -t rsa -C "root@localhost.fr" Generating public/private rsa key pair. Enter file in which to save the key (/var/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /var/root/.ssh/id_rsa. Your public key has been saved in /var/root/.ssh/id_rsa.pub. The key fingerprint is: 2d:a9:f4:d3:df:2e:ca:28:1d:e0:83:91:91:bd:1e:d6 root@localhost.fr The key's randomart image is: +--[ RSA 2048]----+ | o | | o . | | o o | | o = Eo | | *.oS . | | ..+o.o | | .oo.. | | . .+ ... | | .. o..oo | +-----------------+ #
La génération des clés et des algorithmes utilisés doivent suivre les recommandations suivantes:
- Avoir une clé minimal de 2048 Bits pour RSA.
- Avoir une clé minimal de 256 Bits pour ECDSA
- Ne pas utiliser de clé DSA (Recommandation ANSSI).
Si votre serveur SSH supporte les algorithmes ECDSA, celui-ci doit être privilégié.
Notre fichier de configuration doit maintenant contenir les directives suivantes :
# What ports, IPs and protocols we listen for Port 1024 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Restreint ’admin’ aux adresses IP d’un réseau d’administration # (192.168.10.0/24) et ’user’ aux adresses d’un réseau Intranet (10.10.30.0/24) AllowUsers admin@192.168.10.0/24 user@10.10.30.0/24 # Même chose, mais avec un groupe ’wheel’ et ’users’ AllowGroups wheel@192.168.10.0/24 users@10.10.30.0/24 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin no StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords PasswordAuthentication yes AllowTcpForwarding no X11Forwarding no X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM no
Voila, on peut aussi chrooter l’environnement SSH et définir plus finement les privilèges pour retarder les compromissions mais là on a déja grandement réduit la surface d’attaque ainsi que le risque de compromission de son service SSH.
1 comment for “PCI DSS – Guide de durcissement SSH”