Sécurisation de votre serveur SSH

Il est essentiel de protéger vos données. Aspera® vous encourage vivement à prendre des mesures supplémentaires pour installer et configurer votre serveur SSH de manière à le protéger contre les attaques courantes.

Procédez comme suit :

Modification du port d' TCP.
Restriction de l'accès des utilisateurs.

Modification du port d' TCP

La plupart des robots automatisés tentent de se connecter à votre serveur SSH sur le port 22 en tant que root avec diverses combinaisons de force brute et de dictionnaire afin d'accéder à vos données. De plus, les robots automatisés peuvent imposer une charge énorme à votre serveur en effectuant des milliers de tentatives pour pénétrer dans votre système. Cette rubrique traite des mesures à prendre pour sécuriser votre serveur SSH contre les menaces potentielles, notamment en modifiant le port par défaut des connexions SSH de TCP/22 à TCP/33001.

On sait que les serveurs SSH écoutent les connexions entrantes sur le port 22 d' TCP. Ainsi, le port 22 est soumis à d'innombrables tentatives de connexion non autorisées de la part de pirates informatiques qui tentent d'accéder à des serveurs non sécurisés. Une méthode de dissuasion très efficace consiste simplement à désactiver le port 22 et à exécuter le service sur un port apparemment aléatoire supérieur à 1024 (et jusqu'à 65535). Afin de normaliser le port utilisé pour les transferts de l' Aspera, nous recommandons d'utiliser TCP/33001.

Remarque : les connexions d'applications d' Aspera s à distance tentent d'établir une connexion SSH en utilisant le port par défaut 33001. Cependant, si la connexion échoue, l'application tente la connexion en utilisant le port 22.

Les étapes suivantes expliquent comment changer le port SSH en 33001 et prendre des mesures supplémentaires pour sécuriser votre serveur SSH. Toutes les étapes nécessitent des privilèges d'accès root.

Localisez et ouvrez le fichier de configuration SSH de votre système.
Le fichier de configuration SSH se trouve à l'emplacement suivant :
```
/etc/ssh/sshd_config
```
Ajouter un nouveau port SSH.
Remarque : Avant de modifier le port par défaut pour les connexions SSH, vérifiez auprès de vos administrateurs réseau que le port TCP/33001 est ouvert.
La suite d' OpenSSH s incluse dans le programme d'installation utilise TCP/22 comme port par défaut pour les connexions SSH. Aspera recommande d'ouvrir TCP/33001 et de désactiver TCP/22 pour éviter les failles de sécurité de votre serveur SSH.
Pour permettre l' TCP/33001, pendant que votre organisation migre d' TCP/22, ouvrez le port 33001 à partir de votre fichier d' sshd_config s (où SSHD écoute sur les deux ports). Comme le démontre cet exercice, SSHD est capable d'écouter sur plusieurs ports.
```
...
Port 22
Port 33001
... 
```
Une fois que vos utilisateurs clients ont été informés du changement de port (de TCP/22 à TCP/33001 ), vous pouvez désactiver le port 22 dans votre fichier d' sshd_config . Pour désactiver TCP/22 et utiliser uniquement TCP/33001, commentez « Port 22 » dans votre fichier sshd_config .
```
...
#Port 22
Port 33001
...
```
```
$ ascp -P 33001 ...
```
Désactiver le tunneling SSH non-admin.
Remarque : les instructions suivantes supposent qu' OpenSSH 4.4 ou une version plus récente est installée sur votre système. Pour les versions OpenSSH, 4.4 et les versions plus récentes, la directive Match permet de remplacer de manière sélective certaines options de configuration si des critères spécifiques (basés sur l'utilisateur, le groupe, le nom d'hôte et/ou l'adresse) sont remplis. Si vous utilisez une version d' OpenSSH antérieure à 4.4, la directive Match n'est pas disponible; mettez à jour vers la dernière version.
Dans les versions d' OpenSSH 4.4 et plus récentes, désactivez le tunneling SSH pour éviter les attaques potentielles; n'autorisez ainsi que le tunneling des utilisateurs root. Pour désactiver le tunneling SSH non-admin, ouvrez votre fichier de configuration du serveur SSH, sshd_config, avec un éditeur de texte.
Ajoutez les lignes suivantes à la fin du fichier (ou modifiez-les si elles existent) :
```
...
AllowTcpForwarding no
Match Group root
AllowTcpForwarding yes
```
Selon votre fichier d' sshd_config , vous pouvez avoir des instances supplémentaires d' AllowTCPForwarding , définies par défaut sur Yes. Vérifiez votre fichier d' sshd_config s pour d'autres instances et désactivez-les.
Notez que la désactivation du transfert de courrier électronique TCP n'améliore pas la sécurité, sauf si l'accès au shell est également refusé aux utilisateurs, car ceux-ci peuvent toujours installer leurs propres programmes de transfert. Vérifiez vos autorisations d'utilisateur et de fichier, et consultez les instructions suivantes pour modifier l'accès au shell.
Mettre à jour les méthodes d'authentification.
L'authentification par clé publique peut empêcher les attaques par force brute sur le protocole SSH si toutes les méthodes d'authentification par mot de passe sont désactivées. Pour cette raison, désactiver l'authentification par mot de passe dans le fichier sshd_config et activer l'authentification par clé privée/publique. Pour ce faire, ajoutez ou décommentez PubkeyAuthentication yes et commentez PasswordAuthentication yes.
```
...
PubkeyAuthentication yes
#PasswordAuthentication yes
PasswordAuthentication no
...
```
Remarque : Si vous choisissez de laisser l'authentification par mot de passe activée, veillez à conseiller aux créateurs de compte d'utiliser des mots de passe forts. Veillez également à ce que l'option « PermitEmptyPasswords » soit désactivée.
```
PermitEmptyPasswords no
```
Désactiver la connexion en tant qu'administrateur.
OpenSSH autorise par défaut les connexions en tant qu'utilisateur racine; cependant, la désactivation de l'accès en tant qu'utilisateur racine vous aide à maintenir un serveur plus sécurisé. Aspera recommande de commenter la ligne PermitRootLogin yes dans le fichier sshd_config et d'ajouter PermitRootLogin No.
```
...
#PermitRootLogin yes
PermitRootLogin no
...
```
Les administrateurs peuvent ensuite utiliser la commande su si des privilèges root sont nécessaires.

Redémarrez le serveur SSH pour appliquer les nouveaux paramètres.

Lorsque vous avez terminé la mise à jour de la configuration de votre serveur SSH, vous devez redémarrer ou recharger le service SSH pour appliquer vos nouveaux paramètres. Notez que le redémarrage ou le rechargement de SSH n'a aucun impact sur les utilisateurs actuellement connectés.

Pour redémarrer ou recharger votre serveur SSH, exécutez les commandes suivantes :

Version SE	Commandes
Red Hat® zLinux	`$ sudo service sshd restart`
Red Hat (recharger)	`$ sudo service sshd reload`
Debian (redémarrage)	`$ sudo /etc/init.d/ssh restart`
Debian (recharger)	`$ sudo /etc/init.d/ssh reload`

Vérifiez régulièrement vos journaux pour détecter les attaques.
Consultez régulièrement votre journal SSH pour détecter les signes d'une éventuelle attaque. Localisez et ouvrez votre syslog, par exemple /var/log/auth.log ou /var/log/secure. Selon la configuration de votre système, le chemin d'accès et le nom de fichier de syslog peuvent varier.
Recherchez les utilisateurs non valides dans le journal, en particulier une série de tentatives de connexion avec des noms d'utilisateur communs provenant de la même adresse, généralement par ordre alphabétique. Exemple :
```
...
Mar 10 18:48:02 sku sshd[1496]: Failed password for invalid user alex from 1.2.3.4 port 1585 ssh2
...
Mar 14 23:25:52 sku sshd[1496]: Failed password for invalid user alice from 1.2.3.4 port 1585 ssh2
...
```
Si vous identifiez des attaques, procédez comme suit :
- Vérifiez les paramètres de sécurité SSH dans cette rubrique.
- Signalez les attaques à l'adresse e-mail de votre FAI pour les signalements d'abus (souvent abuse@your_isp.com).

Configuration de l'authentification du serveur de transfert

Ouvrez le fichier d' aspera.conf s du serveur de transfert.
Le fichier se trouve à l'emplacement suivant :
```
/opt/aspera/etc/aspera.conf
```
Localisez la section " <server> " et ajoutez l'option " <ssh_host_key_fingerprint> " ou " <ssh_host_key_path> ".
Remarque : lorsque la fonctionnalité de repli HTTP est activée et que le client « replie » vers HTTP, une spécification d'empreinte digitale dans aspera.conf impose la validation du certificat SSL du serveur ( HTTPS ). La validation échoue si le serveur possède un certificat auto-signé; un certificat correctement signé est requis.
- <ssh_host_key_fingerprint>
  Utilisez cette option pour spécifier l'empreinte elle-même :
```
<ssh_host_key_fingerprint>fingerprint</ssh_host_key_fingerprint>
```
  Pour récupérer l'empreinte SSH, localisez la clé publique ou privée du serveur de transferts et exécutez la commande suivante sur un ordinateur Linux®, Mac, Isilon ou autre UNIX™ :
```
# cd /etc/ssh
# cat ssh_host_rsa_key.pub | cut -d' ' -f2 | base64 -d | sha1sum | cut -d' ' -f1
```
  Voici un exemple d'empreinte SSH :
```
43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8
```
  Par convention, Aspera utilise une chaîne hexadécimale sans les deux-points ( : "). Par exemple,
```
435143a1b5fc8bb70a3aa9b10f6673a8
```
  Le paramètre d' aspera.conf s de cette clé serait alors le suivant :
```
<ssh_host_key_fingerprint>435143a1b5fc8bb70a3aa9b10f6673a8
</ssh_host_key_fingerprint>
```
- <ssh_host_key_path>
  Utilisez l'option de chemin d'accès à la clé pour spécifier le fichier de clé publique ou privée du serveur de transfert et son emplacement. L'empreinte digitale est extraite automatiquement.
```
 <ssh_host_key_path>key_file</ssh_host_key_path> 
```
  Sur la plupart des systèmes d' Linux, les clés SSH se trouvent dans /etc/ssh. Sur OSX, les clés SSH se trouvent dans /etc. L'exemple suivant utilise la clé publique RSA d'un serveur Linux :
```
<ssh_host_key_path>/etc/ssh/ssh_host_rsa_key.pub</ssh_host_key_path>
```
Après avoir modifié aspera.conf, redémarrez le service de nœud en exécutant asperanoded:
```
# /etc/init.d/asperanoded restart
```