Imaginez avoir accès en SSH à la machine de ce noob qui ne sait pas configurer son NAT. Ou bien vous assurer que votre laptop soit toujours joignable en SSH peu importe la connexion sur laquelle il est…

Cette conférence du DEF-Con m’a interloqué : comment le mec a repris la main sur une machine qui était probablement derrière un NAT? Peut-être grâce au reverse SSH !

Principe de fonctionnement

Le principe est assez simple : c’est l’ordinateur derrière le NAT (nous l’appellerons distant) qui doit établir la première connexion. Il établit en fait un tunnel SSH vers vous (nous l’appellerons local) et ainsi en remontant le tunnel dans l’autre sens on accède très facilement à la destination.

On suppose donc que la connexion SSH vers l’ordinateur local est aisée (serveur dédié ou NAT bien configuré).

Avantages

• Plus besoin de connaître ou de modifier la configuration du réseau sur lequel est branché distant pour pouvoir y établir une connexion SSH. Tant que le port 22 est ouvert en outgoing ça fonctionnera (on peut même envisager de déplacer le serveur de local sur un port moins restreint tel que le 80 ou 443)
• Plus besoin de connaître l’IP où se trouve distant, c’est lui qui établit le contact vers local

Vérifiez la configuration du serveur SSH local

Il faut que le serveur sur local autorise les tunnels (/etc/ssh/sshd_config) :
AllowTcpForwarding yes

Let’s go!

Sur distant (la machine inaccessible), créez le tunnel :
distant$ ssh -NR 22222:localhost:22 user@local
Bien entendu local est l’IP de votre machine et user est un utilisateur qui y a accès.

Une fois le tunnel établi, il ne vous reste plus qu’à remonter le tunnel pour établir la connexion SSH depuis local :
local$ ssh -p 22222 user@127.0.0.1

Service au démarrage

Avec autossh (disponible dans le package manager de votre distro préférée) et une connexion SSH sans mot de passe, vous pouvez très facilement créer un script de démarrage sur distant pour que le tunnel soit toujours récréé sans intervention humaine :
# autossh -i /path/to/privateKey.rsa -NR 22222:localhost:22 user@local

Il vous suffit d’ajouter cette commande dans vos scripts de boot (/etc/rc.local par exemple).

Aller plus loin

Ici nous utilisons du SSH pour ouvrir l’accès à un serveur SSH, mais on pourrait envisager d’ouvrir l’accès à n’importe quel serveur qui tournerait sur distant, par exemple un serveur web pour du monitoring Munin :
distant$ ssh -NR 22280:localhost:80 user@local
local$ firefox "http://127.0.0.1:22280"

Vous l’aurez compris, vous pouvez aussi centraliser sur votre serveur (“local”) des tunnels venant de tous les n00bs que vous aidez régulièrement, l’astuce est de remplacer 22222 dans les diverses commandes citées sur cette page par un autre code de port compris entre 1024 et 65535. Et de maintenir une liste exhaustive de ceux-ci !

Si vous avez aimé ce post...

1. Serveur Lighttpd avec PHP sur iPhone
2. Facebook s’apprêterait à lancer son serveur XMPP
3. Le tunnel SSH facile

Wikileaks a aujourd’hui publié sa solution à la censure : le mirroring. Si Wikileaks est consultable sur des centaines de noms de domaine et des centaines d’IPs, il sera d’autant plus difficile de tous les faire taire.

A noter que cet article, bien qu’entièrement orienté autour de ce sujet, s’applique aussi si vous souhaitez offrir à quelqu’un un accès SSH chrooté et aux commandes limitées.

Mise à jour : Mes mesures de sécurité étaient trop optimistes : Rsync n’utilise pas du SFTP mais doit pouvoir lancer un serveur Rsync sur sa destination en SSH. Voici donc une nouvelle version de cet article, testé et approuvé.

Le problème

Pour décentraliser la chose, les administrateurs de Wikileaks demande à tous les volontaires de leur offrir un accès en SSH à leur serveur pour pouvoir y pousser un miroir de Wikileaks et le garder à jour grâce à Rsync.

Ca qui m’a dérangé c’est le fait de donner un accès SSH à des inconnus sur mon serveur. Mais la solution existe : CHROOTER ce compte à un endroit où il ne peut faire aucun mal au système. Voici comment faire.

Attention : cet article ne porte bien évidemment pas sur la sécurisation de votre serveur. Il présente juste une manière d’éviter que les administrateurs de Wikileaks (que vous ne connaissez pas) aient trop de libertés sur votre serveur (et, oui, je suis paranoïaque sur le coup).

NB : Si vous souhaitez devenir très simplement un miroir Wikileaks et que vous leur faites entièrement confiance, les étapes “Créer l’utilisateur“, “Configurer un nom de domaine et un VirtualHost” et “Soumettre votre miroir à Wikileaks” sont suffisantes.

Sécuriser OpenSSH

On va donner à Wikileaks (ou toute personne ayant leur clé RSA privée) un accès SSH sur notre serveur. Mais on ne veut prendre aucun risque : cet accès n’aura aucune autre possibilité que de déposer des fichiers là où on l’y autorise, c’est-à-dire dans sa home.

Pour cela, modifiez votre fichier /etc/ssh/sshd_config. Vérifiez d’abord que vous avez ces trois lignes qui autorisent la connexion avec une clé publique RSA.
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Dernièrement, à la fin du fichier créez une nouvelle règle d’override telle que celle-ci :
Match user wikileaks
ChrootDirectory /home/wikileaks
X11Forwarding no
AllowTcpForwarding no
Cette règle est assez explicite et fait simplement en sorte que l’utilisateur wikileaks soit Chrooté dans sa home. Redémarrez SSHd.

Créer l’utilisateur

Rien de bien sorcier :
# mkdir /home/wikileaks
# useradd -d /home/wikileaks -s /bin/bash wikileaks
# chown wikileaks:wikileaks /home/wikileaks

Ensuite autorisons la connexion des administrateurs de Wikileaks :
# su - wikileaks
$ mkdir ~/.ssh
$ wget http://wikileaks.ch/id_rsa.pub -O ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys

Pour finir, n’oublions pas de créer le répertoire où sera hébergé le miroir :
$ mkdir ~/www

Créer l’environnement chroot

Pour qu’un chroot fonctionne correctement, il faut que sa racine appartienne à root. Nous créons aussi les deux répertoires indipensables à l’exécution d’un rsync : /bin et /lib.
# chown root:root /home/wikileaks
# mkdir /home/wikileaks/bin
# mkdir /home/wikileaks/lib

Ensuite copions les binaires nécessaires pour faire un Rsync :
# cp `which bash` /home/wikileaks/bin/bash
# cp `which rsync` /home/wikileaks/bin/rsync

Pour que ces binaires fonctionnent, il faut aussi copier les librairies nécessaires. Pour lister ces librairies vous pouvez exécuter un ldd puis copiez une à une ces libraires
# ldd `which bash` `which rsync`
# cp /lib/libncurses.so.5 /home/wikileaks/lib/
...
Attention : si votre serveur est un système 64bits il faudra créer le dossier /home/wikileaks/lib64/ et le peupler avec les librairies venant de /lib64.

Au final vous devriez arriver à une structure proche de celle-ci :
bin
|- bash
|- rsync
lib
|- ld-linux.so.2
|- libacl.so.1
|- libattr.so.1
|- libc.so.6
|- libdl.so.2
|- libncurses.so.5
|- libpopt.so.0
Dès maintenant, si on se chroote dans /home/wikileaks on n’aura que très très peu de possibilités : les commandes internes à bash et rsync.

Un dummyshell

Oui, je suis d’accord, les commandes internes de bash c’est encore trop! Nous permettons un accès SSH qui pourrait potentiellement lancer une fork bomb par exemple. Nous allons donc créer un shell stupide qui ne permet que de lancer un serveur Rsync. Créez le fichier /home/wikileaks/bin/dummyshell :
#!/bin/bash
if (( $# == 0 )); then
printf "%s\n" "shell access is disabled. sorry."
exit 1
elif (( $# == 2 )) && [[ $1 == "-c" && $2 == "rsync --server"* ]]; then
exec $2
fi

Il faut ensuite le rendre exécutable et utilisé comme shell par défaut de l’utilisateur :
# chmod +x /home/wikileaks/bin/dummyshell
# ln -s /home/wikileaks/bin/dummyshell /bin/dummyshell
# usermod -s /bin/dummyshell wikileaks
C’est maintenant officiel, l’utilisateur wikileaks ne peut rien faire de plus que lancer un serveur Rsync ! Et il y a aussi la sécurité du Chroot.

Test

Je vous recommande de tester le tout, pour être sûr que Wikileaks pourra uploader son site sur votre serveur. Pour cela ajoutez votre propre clé RSA dans une nouvelle ligne de /home/wikileaks/.ssh/authorized_keys et tentez d’envoyer un fichier :
$ rsync -ave ssh test.html wikileaks@votreServeur:/www

Vous pouvez également éprouver la sécurité en tentant de vous connecter en SSH ou d’exécuter une commande en SSH -t.

Configurer un nom de domaine et un VirtualHost

Je suppose que vous vous en sortirez sur ce point-là : créez un nom de domaine (ou un sous-domaine) pour votre miroir et configurez votre serveur web en conséquence.

Le DocumentRoot à spécifier est bien /home/wikileaks/www

Profitez-en pour empêcher l’exécution de scripts sur le répertoire :

AllowOverride None
Options -ExecCGI


Soumettre votre miroir à Wikileaks

Rendez-vous sur http://46.59.1.2/mass-mirror.html et soumettez votre miroir !

Sous “absolute path where we should upload the html data” mettez simplement “/www/”.

Normalement Wikileaks pushera l’entièreté du site sur votre serveur. Félicitations, vous défendez la liberté d’expression sans risque majeur pour votre serveur !

Si vous avez aimé ce post...

1. SSH sans mot de passe
2. Choisir son keymap X.org 1.8 sans xorg.conf ni hack
3. Zeroconf : Réseaux IP sans configuration

Un attaquant vera son adresse IP inscrite dans le fichier /etc/hosts.deny l’empêchant de se logguer.

Installation

Gentoo

emerge denyhosts

Debian et dérivés

aptitude install denyhosts

Red Hat et consorts

yum install denyhosts

Configuration

/etc/denyhosts

#Doit pointer vers votre fichier logguant les tentatives de connexions
SECURE_LOG = /var/log/auth.log

#Ces dernières lignes permettent d'utiliser le partage d'IP. On peut se limiter au partage montant ou descendant
#C'est purement facultatif mais je vous le recommande.
SYNC_SERVER = http://xmlrpc.denyhosts.net:9911
SYNC_UPLOAD = yes
SYNC_DOWNLOAD = yes

Puis pour le lancer :
/et/init.d/denyhosts start

Sous Gentoo pour le lancer automatiquement au boot vous devez l’ajouter à votre « rc par défaut » :
rc-update add denyhosts default

Logs

Allons faire un tour dans les logs de DenyHosts pour voir à quoi s’attendre.

Exemple de synchro où l’on récupère des IP à blacklister :

Feb 20 04:42:43 - denyhosts : INFO received new hosts: ['217.10.117.161', '194.185.200.156', '91.75.180.114', '202.141.132.50', '60.248.91.64', '211.100.42.83', '202.165. 177.203', '211.155.227.171', '58.221.34.18', '88.191.15.133', '210.51.36.162', '220.165.28.66', '91.205.74.41', '61.178.74.43', '202.117.54.134', '74.127.18.195', '195.250.39.6 6', '216.229.160.194', '122.70.147.103', '200.195.168.194', '202.44.11.60', '94.190.187.113', '213.5.64.164', '201.116.98.210', '163.13.175.44', '119.149.189.199', '93.152.156. 13', '125.7.209.4', '210.51.48.71', '88.117.234.162', '217.97.185.35', '217.20.183.73', '117.41.228.195', '201.20.186.222', '79.39.6.98', '221.165.162.4', '211.72.171.76', '209 .255.67.10', '80.203.122.116', '12.152.124.2', '70.169.201.74', '202.5.95.205', '217.219.67.131', '65.98.97.98', '218.241.155.144', '80.14.186.105', '96.31.68.39', '218.108.247 .138', '61.138.217.19', '82.230.95.10']

Ajout d’un attaquant + upload au serveur central :

Feb 21 09:25:31 - denyhosts : INFO new denied hosts: ['81.7.171.15']
Feb 21 09:43:01 - sync : INFO sent 1 new host

Reset du compteur en cas de login réussi :

Feb 21 11:35:03 - loginattempt: INFO resetting count for: 10.0.0.3

Liens

Site officiel
Statistiques mondiales de DenyHosts

Si vous avez aimé ce post...

1. Mise en place d’un système de backup avec Rsnapshot
2. SSH sans mot de passe
3. On a testé pour vous : Ubuntu Jaunty Jackalope 9.04

Cette technique fonctionne pour tous les laptops ayant une ligne de commande SSH: Linux et Mac OS. Votre iPhone doit être jailbreaké avec OpenSSH (Cydia) installé.

Réseau WiFi Ad-Hoc

Créez un réseau WiFi Ad-Hoc sur votre laptop. C’est aisément rélisable avec NetworkManager et pas vraiment plus compliqué en ligne de commande, je ne le détaillerai donc pas. Je vous conseille une configuration IP manuelle, sans DNS ni routeur.
Adresse IP: 10.42.42.1
Broadcast: 10.42.42.255
Sous-réseau: 255.255.255.0

Connectez-vous ensuite à ce WiFi sur votre iPhone. Il est ici impératif que la configuration IP soit manuelle. Il ne faut en effet ni routeur, ni DNS.
Adresse IP: 10.42.42.2
Sous-réseau: 255.255.255.0

Tunnel SSH

Tout d’abord ouvrez une page quelconque avec Safari sur votre iPhone. Cela permettra de réécrire les routes pour que l’iPhone se connecte via l’EDGE/3G et non via sa connexion WiFi active, connexion qui ne mène à rien. Cela peut prendre quelques secondes.

Comme expliqué dans l’article sur le tunnel SSH, il vous suffit ensuite d’initier le proxy local. Le mot de passe par défaut est alpine.
ssh -ND 9999 root@10.42.42.2

Configurez ensuite vos logiciels pour utiliser le proxy SOCKS5 sur localhost:9999 et à vous l’internet partout en Belgique \o/

iPhone OS 3.0

Une des nouvelles fonctionnalités du prochain firmware de l’iPhone sera l’Internet Tethering, c’est-à-dire le partage de la connexion EDGE/3G via Bluetooth ou USB!

On en reparlera après le présentation de l’iPhone OS 3.0 au WWDC entre le 8 et le 12 juin.

Via Lifehacker (en) et MyDigitalLife (en).

Si vous avez aimé ce post...

1. iPhone OS 3.0
2. Partager la connexion de son laptop
3. Serveur Lighttpd avec PHP sur iPhone

Schéma de la solution à déployer

Avec rsnapshot il est possible de faire des backups locaux (une copie régulière d’un disque sur un autre) ou des backups distants (via une connexion SSH), soit les deux en même temps !

Principe de Rsnapshot

Basé sur SSH et rsync, rsnapshot est en fait une boite à outil. Pour ceux qui ne connaissent pas rsync, c’est un outil de synchronisation de fichiers libre et puissant qui ne copie que les différences entre deux backups, et non l’entièreté du système, pour économiser de la bande passante.

Rsnapshot est un logiciel qui tourne sur le serveur de backup. La machine qui se voit ainsi sauvegardée est totalement passive, il faut juste qu’elle ait un serveur SSH activé.

Quelques scripts rsync/ssh pourraient évidemment faire la même chose que rsnapshot, mais rsnapshot est fiable et sa configuration triviale, alors pourquoi s’en passer?

Installation

Première étape : Installez rsnapshot sur le serveur où seront stockés les backups. Je ne décris pas cette installation qui est triviale et propre à chaque distribution.

Deuxième étape : Permettez à ce serveur de se connecter automatiquement en SSH sur la machine à sauvegarder. Je vous renvoie vers l’article SSH sans mot de passe qui explique comment générer une paire de clés publique/privée afin de chiffrer la connexion SSH avec le protocole RSA.

Troisième étape (facultative) : Modifiez votre fichier /etc/hosts, qui permet d’utiliser des short-names dans la configuration de rsnapshot (c’est plus propre et plus joli).

Quatrième étape : Configurez rsnapshot dans /etc/rsnapshot.conf. Vous pouvez vous inspirer de cet exemple.

Lancer le backup

Vous êtes maintenant prêt pour votre premier backup! Lancez la commande suivante:
/usr/bin/rsnapshot -cv /etc/rsnapshot.conf daily

Si tout se passe bien, vous n’avez plus qu’à ajouter cette commande à votre crontab afin d’automatiser la procédure.

Problèmes connus

• La toute première connection ssh du serveur de backup vers la machine à backuper doit être établi manuellement.
• Le fichier rsnapshot.conf doit être réécrit en séparant les valeurs avec des tabulations. Si vous ne remplacez pas les espaces par des tabulations, rsnapshot ne fonctionnera pas.

Liens de référence

• Site du projet
• Exemple de configuration

Si vous avez aimé ce post...

1. Backup d’un compte Gmail
2. S’authentifier avec une clé USB
3. SSH sans mot de passe

Je n’ai pas trouvé de tutoriel clair et concis en français sur Google alors le voici.

Le principe

Cette astuce ne consiste pas à encoder votre mot de passe en clair quelque part sur votre poste client. Il est basé sur un échange de clés de cryptage RSA entre le serveur et le client.

Le cryptage RSA repose sur une paire de clés : une publique et une privée. Vous l’aurez compris, la clé privée reste sur votre ordinateur client et vous pouvez partager votre clé publique avec tous les serveurs sur lesquels vous souhaites vous authentifier.

Lors de chaque connexion, le serveur chiffre une chaine de caractères aléatoire avec la clé publique. Seule la clé privée est suffisante pour déchiffrer cette chaine de caractères et la transmettre au serveur (sans risque puisque les transmissions SSH sont elles-mêmes cryptées). C’est le principe de toutes les procédures d’authentification (GnuPG, BeID, cartes bancaires, …)

Générer les clés de cryptage

Il faut donc, sur le cient, générer les clés RSA qui lui permettront de signer. Il existe d’autres types de clés mais le RSA est simple et sécurisé.
$ ssh-keygen -t rsa

Une passphrase permet d’avoir un seul mot de passe pour toutes vos connexions SSH, même si le vrai mot de passe de connexion est différent sur chaque serveur. Si vous ne voulez pas utiliser de passphrase pour une connexion entièrement automatisée, tapez simplement enter.

Copier la clé publique sur le serveur

Il faut maintenant copier la clé publique générée sur le serveur SSH, pour qu’il puisse bien vérifier que c’est vous qui signez la demande de connexion. On le fait par un petit scp (copie de fichier sur SSH):
$ scp ~/.ssh/id_rsa.pub utilisateur@serveur:~/.ssh/authorized_keys

Et voilà! C’est tout! Vous pouvez maintenant vous connecter sur votre serveur SSH sans mot de passe:
ssh utilisateur@serveur

Exécuter une commande sur le SSH

Une dernière petite astuce, si vous souhaitez directement exécuter une commande sur le serveur SSH, utilisez le paramètre
-t. Par exemple, pour ouvrir votre screen IRC:
$ ssh utilisateur@serveur -t screen -x irc

Si vous avez aimé ce post...

1. Mise en place d’un système de backup avec Rsnapshot
2. Devenez miroir de Wikileaks sans risque (corrigé)
3. S’authentifier avec une clé USB

• Accéder au réseau local du serveur SSH
• Se balader sur internet avec l’IP du serveur SSH
• Contourner un firewall trop restrictif
• Sécuriser ses communications sur un réseau public douteux

Roidelapluie m’a aujourd’hui montré à quel point il était facile de créer un tunnel SSH remplissant ces fonctions.

Le serveur proxy

Prérequis : un accès utilisateur sur un serveur SSH. J’appellerai client l’ordinateur sur lequel vous êtes et serveur le serveur SSH.

L’idée générale est donc de faire tourner sur le client un serveur proxy relayant toutes les connexions vers le serveur. Cela se fait en une seule commande:
ssh -ND 9999 utilisateur@serveur
Une fois authentifié sur le serveur SSH, laissez l’invite de commande tourner. Vous avez désormais un serveur proxy SOCKS (compatible v4 et v5) tournant sur localhost:9999

Les applications clientes

Vous pouvez maintenant simplement régler votre système, votre navigateur ou toute autre application pour utiliser un serveur proxy SOCKS, uniquement SOCKS. Vous pouvez par exemple vérifier que ça a bien fonctionné pour Firefox en comparant votre IP avant et après.

Si le logiciel que vous souhaitez faire passer dans le tunnel ne supporte pas les proxys ou que vous voulez quelque chose de plus universel qu’un réglage logiciel au cas par cas, vous pouvez installer proxychains. Modifiez la dernière ligne de /etc/proxychains.conf pour qu’elle ressemble à ceci:
socks5 127.0.0.1 9999

Il suffit ensuite de lancer l’application en ajoutant proxychains avant la commande:
proxychains links2 "http://myip.dk"

Si vous avez aimé ce post...

1. Internet sur votre laptop via un iPhone
2. SSH sans mot de passe
3. Mise en place d’un système de backup avec Rsnapshot