TunnelSSHAvecProxyHTTP

Cet article à pour objectif de montrer comment passer à travers la sécurité mise en place par les services informatiques.

Hypothèse

Vous êtes dans une entreprise qui n'autorise pas les sorties directes sur Internet (blocage via un firewall par exemple). Seuls les ports 80 (http) et 443 (https) en sortie vers l'extérieur sont autorisés et de surcroit via un proxy HTTP.

Donc pour pouvoir faire passer le flux de n'importe quel service à travers le proxy, il va être nécessaire de mettre en place un tunnel (crypté de préférence) dans lequel les informations passeront et ne seront pas filtrées.

Besoins

• un client SSH
• un serveur SSH
• authentification par rapport à une personne/machine "physique" (utilisation d'une clé asymétrique)

Configuration du serveur SSH (exemple sous linux)

Le serveur SSH est celui fourni par la distribution Linux Debian : OpenSSH. Il doit écouter sur un des ports que le proxy laisse passer : ici prenons le port 443. Les directives utilisées pour configurer les serveur sshd sont les suivantes (dans /etc/ssh/sshd_config) :

Port 443
ListenAddress 0.0.0.0
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes
PubkeyAuthentication yes                        <- obligatoire pour une authetification par clé asymétrique
AuthorizedKeysFile      %h/.ssh/authorized_keys <- obligatoire pour une authetification par clé asymétrique
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts yes
PermitEmptyPasswords no
PasswordAuthentication no <- permet de désactiver l'authentification par userid/password
UsePAM no                 <- permet de désactiver l'authentification par userid/password
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
Subsystem sftp /usr/lib/openssh/sftp-server
ClientAliveInterval 300   <- permet d'envoyer un keepalive toutes les 300 secondes afin que la connexion reste active en permanence

Génération de la clé asymétrique (utilisation de Puttygen sous windows)

Lancer puttygen et cliquer sur Generate avec les paramètres SSH-2 RSA et 1024 bits. Pour que la génération soit complètement aléatoire, puttygen utilise les mouvements de la souris. Il suffit de se placer dans la zone Key et de bouger la souris aléatoirement...

Cliquer sur Save private key pour sauvegarder la clé privée. La clé privée (portant obligatoirement l'extension ppk doit être stockée à un endroit sûr et accessible seulement par vous. La clé publique est affichée dans la zone Key. Il suffit de faire un copier/coller de cette zone dans le fichier authorized_keys. Ce dernier sera positionné dans le home directory de l'utilisateur utilisé pour la connexion dans le répertoire ssh

Remarque importante : le répertoire ~/.ssh doit avoir les droits 700 (lecture/ecriture/exécution seulement pour l'utilisateur : drwx------). Le fichier authorized_keys doit avoir les droits 600 (lecture/ecriture seulement pour l'utilisateur : rw

Il est recommandé de sauvegarder cette clé publique pour pouvoir l'utiliser sur un autre serveur SSH par exemple.

• key-comment permet de mettre un commentaire (pour dire à quoi sert la clé par exemple).
• key-passphrase permet de protéger l'utilisation de la clé. C'est un mot/phrase/code correspondant à un mot de passe. Plus il est long mieux c'est. Le passphrase n'est pas obligatoire. Si ce champ est renseigné, lors de la connexion au serveur SSH, le passphrase sera demandé.

Intérêt de l'utilisation d'une clé asymétrique

La clé asymétrique va permettre au couple client/serveur SSH :

• d'échanger de manière sûre une clé symétrique générée aléatoirement et renouvelable de manière périodique permettant de chiffrer le tunnel,
• de s'assurer que la machine distante est bien celle qui prétend l'être (en effet, si la clé privée reste protégée, seul son propriétaire pourra s'en servir et s'authentifier avec, et seul le possesseur de la bonne clé publique pourra déchiffrer ses données. Toute utilisation frauduleuse d'une mauvaise clé privée sera automatiquement détectée et la communication sera rejetée).
• Il n'y a plus d'authentification avec le couple userid/passwd

Configuration du client SSH (sous windows)

Le client utilisé est putty.

Dans la section Category on renseigne les champs Hostname (1.2.3.4) et Port (443) qui correspondent à l'adresse et au port du serveur SSH.

Dans la section Connection->Data renseigner le nom de login utilisé dans le champ Auto-login username (c'est dans le home directory de cet utilisateur dans ~/.ssh/authorized_keys que devra être copiée la clé publique).

Dans la section Connection->Proxy on sélectionne le type de proxy (HTTP), et on renseigne les champs Proxy Hostname (proxy) et Port (8080). Ces informations sont celles utilisées par le navigateur Internet pour se connecter à Internet. Si une authentification est nécessaire au niveau du proxy, il faudra alors remplir les champsUsername et Password avec les bonnes valeurs.

Mise en place de la transmission de données dans le tunnel

Le client SSH (Putty) et le serveur SSHd vont se comporter comme un transmetteur/redirecteur de flux. Il va écouter sur un port local donné (champ Source port et le transmettre dans le tunnel SSH sur le port distant (champ Destination de la machine serveur SSHd. Ces réglages se font dans la section Connection->SSH->Tunnels

Bien entendu, il est nécessaire qu'un service écoute le port souhaité (ici 3128) sur la machine qui fait serveur SSHd. Par exemple, lancer son proxy HTTP (Squid pour Linux) sur le port 3128.

Configuration d'un client

Pour pouvoir surfer en toute liberté avec son navigateur préféré, il suffit de renseigner dans le champ adresse du proxy 127.0.0.1 port 3128.

• Sous Firefox : Outils->Options->Paramètres de connexion->Configuration manuelle du proxy
• Sous Internet Explorer : Outils->Options Internet->Onglet Connexions->Paramètres réseau->Zone serveur proxy->Utiliser un serveur proxy pour votre réseau local.

Il peut être fait de même pour MSN Messenger, un client IRC, un serveur FTP, etc...

Renforcement de la sécurité

La mise en place d'un service de type SSH ouvert sur Internet n'est pas ce qu'il est de plus recommandé de faire. Donc il est nécessaire de prendre un maximum de précautions afin de ne pas être sujet à des attaques. Ci-dessous une petite liste d'idées pour renforcer un minimum la sécurité du serveur SSH :

• Configurer le filtre de paquet (iptables sur Linux) pour n'accepter sur le port 443 que les connexions des machines à partir desquelles vous serez amené à vous connecter.

# Regles pour les attaques de type brute force sur SSH
$IPTABLES -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
$IPTABLES -A INPUT -p tcp --dport ssh -m state --state NEW -j tcp_packets
$IPTABLES -A INPUT -p tcp --dport ssh -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 ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

# Machines autorisées à se connecter
$IPTABLES -A tcp_packets -p TCP -s @IP/32 --dport 443 -j allowed

• Rendre obligatoire l'authentification par clé asymétrique en désactivant l'authentification par le couple userid/passwd (directive UsePAM à no, PasswordAuthentication à no dans le fichier /etc/ssh/sshd_config)
• Utiliser un mode de connexion sans priviège tant que la phase d'authentification n'est pas validée en positionnant la directive UsePrivilegeSeparation à yes dans le fichier /etc/ssh/sshd_config