Créer une passerelle sécurisée avec un Raspberry Pi

raspberry_pi_authentification_chiffrement_600

Qu’il s’agisse de domotique, de vidéo-surveillance ou de simple partage de fichiers, les besoins de se connecter à un équipement se trouvant à l’intérieur de notre maison à travers Internet se multiplient. Bien que ces systèmes soient de plus en plus généralisés et faciles à mettre en place, la question de la sécurité est souvent reléguée au second plan.

Comment s’assurer que personne ne nous espionne avec nos caméras IP installées dans notre salon ? Comment empêcher une personnes curieuse, voire malveillante, de jouer avec notre centrale domotique ?

Dans l’ensemble de mes articles, j’ai toujours insisté sur l’importance de sécuriser ces accès. Aujourd’hui, je vous propose de voir comment créer un point d’accès sécurisé grâce à un Raspberry Pi.

Contexte

camera_ipPrenons l’exemple d’une caméra IP. Ce type de caméra dispose généralement d’une interface web qui vous permet de la configurer et de visionner les images. Vous vous connectez à cette interface web grâce à un navigateur en vous connectant sur une URL du type http://192.168.0.17:8080. (192.168.0.17 étant l’adresse IP de votre caméra sur le réseau interne à votre maison).

Cela signifie que le service (c’est à dire le logiciel) qui vous permet d’interagir avec votre caméra, est disponible sur le port 8080/TCP. Si vous voulez pouvoir accéder à votre caméra depuis l’extérieur de votre maison, c’est à dire en passant par Internet, vous allez devoir configurer votre box, modem ou routeur, pour autoriser les flux sur ce même port 8080/TCP à destination de l’adresse IP interne de votre caméra. Votre box agit alors comme un « aiguilleur », qui lorsqu’il recevra une connexion depuis l’extérieur de votre réseau sur le port 8080/TCP redirigera le flux vers votre caméra IP.

Le hic, c’est que cela fonctionnera avec vous, mais aussi avec tout le reste de la planète ! N’importe qui connecté à internet peut se connecter à votre caméra !

Vous me direz : « Oui, mais il y a un mot de passe !« . En effet, il reste à trouver le mot de passe (si vous en avez un, et qu’il est suffisamment compliqué) pour pouvoir vous espionnez. Gardez cependant à l’esprit que de l’extérieur (comprenez depuis Internet), si vous pouvez vous connecter à votre caméra/box domotique/serveur de fichiers, alors tout le monde peut s’y connecter également.

Notions et principes de base en sécurité informatique

Pour sécuriser l’accès à un service (logiciel) à travers un réseau tel qu’Internet, il y a trois choses à mettre en place :

  • protéger l’accès grâce à un mot de passe : réserver l’accès à ceux qui connaissent le mot de passe
  • vérifier l’identité de la personne qui se connecte : s’assurer que la personne qui tente de se connecter est bien une personne autorisée
  • chiffrer les informations et les données lorsqu’elles transitent sur le réseau : empêcher que quelqu’un intercepte votre mot de passe et vos données personnelles

En effet, un mot de passe seul ne suffit pas car il peut être découvert ou volé. Et si vous pensez que personne ne peut vous voler votre mot de passe, détrompez vous ! La chose à garder en tête, c’est que lorsque vous êtes à l’extérieur de votre maison, vous utilisez un réseau que vous ne maîtrisez pas (WiFi publique, réseau 3G/4G de votre opérateur mobile, réseau de votre entreprise, etc…). Sur ces réseaux, vous n’avez absolument aucune garantie que personne n’observe ce que vous faites. On peut même dire que vous avez la certitude que vos données peuvent être lues par quelqu’un. Pour résumer : Si vous saisissez votre mot de passe quelque part, il sera visible par les équipements du réseau que vous utilisez.

Si vous n’êtes toujours pas convaincu par cette fragilité, je vous conseille vivement de lire le dossier dédié à ce sujet dans le dernier Canard PC Hardware (n° 23) http://www.canardpc.com/news-53226-cpc_hardware_n__23_est_disponible__.html. Vous verrez avec quelle facilité il est possible de récupérer vos mots de passe.

Comment faire pour se protéger ?

La solution pour éviter que votre mot de passe soit intercepté, est de chiffrer (comprenez crypter) les flux entre vous (votre navigateur, votre smartphone), et l’appareil auquel vous vous connectez (caméra ip, box domotique,…). Nous verrons plus loin comment mettre cela en place.

Enfin, pour nous assurer que notre accès est sécurisé, il convient de mettre en place un « contrôle d’identité« . Dans la vraie vie, pour contrôler que vous êtes bien la personne que vous prétendez être, on vous demande votre Carte Nationale d’Identité. Cette carte d’identité garantie que vous êtes bien vous en s’appuyant sur deux choses : la première c’est que vous la possédez (vous prouvez votre identité en étant détenteur de votre carte) ; la seconde est qu’elle a été faite par une autorité suprême, à savoir l’Etat, qui a préalablement réalisé les contrôles nécessaires avant de vous délivrer votre carte d’identité qui indique que vous êtes vous (Une carte réalisée par le boulanger du coin n’aurait pas la même authenticité). Pour résumer : Vous possédez une carte d’identité, et c’est l’Etat (entité de confiance) qui atteste que c’est bien vous. Vous pouvez donc récupérer votre colis à La Poste, puisque c’est l’Etat qui garantie que vous êtes bien vous. Retenez bien ce principe, car il est très important pour comprendre la suite.

Dans le monde de la sécurité, on parle d’authentification forte lorsqu’il est nécessaire de présenter au moins deux choses pour vous connecter : quelque chose que vous connaissez (un mot de passe), et quelque chose que vous possédez (une carte, un badge, un certificat) ou que vous êtes (une empreinte digitale, une empreinte vocale…).

Certificats

httpsEn informatique, pour désigner l’équivalent d’une carte d’identité, on parle de certificat. Lorsque vous allez sur un site internet utilisant un certificat, vous voyez généralement un petit cadenas dans la barre d’adresse et l’URL commence par https. En cliquant sur le cadenas, on peut afficher le certificat utilisé par le site :

certificat

Nous voyons que ce certificat a été émis par VeriSign qui est une autorité de certification reconnue dans le monde de l’Internet (à l’instar de l’Etat pour nos CNI). Ce certificat à été émis pour le site www.paypal.com de la société PayPal. Le site de Paypal présente donc un certificat qui atteste de son identité, et que cette identité à été vérifiée par VeriSign. Nous avons donc l’assurance qu’il s’agit bien du site de PayPal 🙂

Il s’agit là d’un certificat serveur, pour que les clients puissent vérifier qu’il s’agit bien d’un serveur légitime. Pour notre passerelle sécurisée, nous ajouterons un certificat client, pour que le serveur puisse valider que le client est bien légitime également.

A retenir

Pour garantir la sécurité d’un accès au travers d’un réseau il est nécessaire vérifier que vous êtes vous, que vous connaissez le mot de passe, et que ces données transitent chiffrées (cryptées) sur le réseau.

Pardonnez la longueur de ces explications, mais il nécessaire de bien comprendre les tenants et les aboutissants de ces éléments pour mettre en place un système fiable et sécurisé. Ceci étant dit, passons au choses sérieuses en réalisant un système qui mette tout ceci en œuvre. Procédons 🙂

Le matériel nécessaire

Rien de bien compliqué, un pack de base (Raspberry Pi, alimentation, carte SD et boitier) suffit. Je conseille toutefois le choix d’un modèle équipé d’un port Ethernet.

Raspberry_Pi_2Le Raspberry Pi 2 étant vendu au même prix que le B+, ne nous en privons pas !

Construction de la passerelle sécurisée : schéma global

raspberry_pi_passerelle_securisee

Le principe global est de mettre la passerelle sécurisée dans une DMZ (zone démilitarisée) et de bloquer les accès directs grâce au firewall (pare-feu) de la box Internet (ou du modem/routeur). De cette manière, tous les flux provenant de l’extérieur (Internet) sont redirigés vers la passerelle qui se charge de chiffrer les flux et de vérifier l’identité du visiteur. Ces deux étapes s’appuient sur des certificats. Si tout est ok, la passerelle redirige à son tour les flux vers l’équipement ciblé (On peut imaginer plusieurs équipement, caméras, une box domotique, un serveur de fichier,… ). L’authentification par mot de passe est assuré par l’équipement lui même en dernier ressort.

Note : Si votre box Internet ne permet pas de créer une DMZ, vous pouvez vous contenter de placer la passerelle directement dans votre réseau local. Il s’agira alors de configurer le firewall de la box pour rediriger tous les flux externes vers la passerelle.

Installation et configuration

Dans un premier tant il convient d’installer une Raspbian en bonne et due forme. Une fois démarré et la configuration de la carte réseau effectuée, nous aurons besoin d’installer Apache.

apt-get install apache2

Création des certificats

Nous allons donc créer un certificat serveur, et un certificat client (notez que vous pouvez créer autant de certificats client que vous le souhaitez, pour plusieurs personnes par exemple). Pour que ces certificats soient valides, nous devons les faire signer par une autorité de certification qui en attestera l’authenticité. Vous pouvez trouver ces services chez de nombreux fournisseurs reconnus, mais cela à un prix. Nous allons donc créer notre propre autorité de certification. Notez que cela n’est pertinent uniquement parce que travaillons sur nos environnements personnels, car l’autorité de certification que nous allons créer ne sera reconnue que par nous même.

L’outil qui permet de faire cela est openssl. Il est installé de base sur Raspbian.

Création de l’autorité de certification ou CA

Créez un fichier openssl.cnf et placez y cette configuration :

[ req ]
default_md = sha1
distinguished_name = req_distinguished_name

[ req_distinguished_name ]
countryName = Country
countryName_default = FR
countryName_min = 2
countryName_max = 2
localityName = Locality
localityName_default = France
organizationName = Organization
organizationName_default = Raspberry
commonName = Common Name
commonName_max = 64

[ certauth ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true
crlDistributionPoints = @crl

[ server ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
nsCertType = server
crlDistributionPoints = @crl

[ client ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = clientAuth
nsCertType = client
crlDistributionPoints = @crl

[ crl ]
URI=ca.crl

Créer le certificat auto-signé de l’autorité de certification en exécutant la commande suivante :

openssl req -config ./openssl.cnf -newkey rsa:2048 -nodes -keyform PEM -keyout ca.key -x509 -days 3650 -extensions certauth -outform PEM -out ca.cer

Ceci va générer deux fichiers ca.cer le certificat de l’autorité de certification et ca.key la clé qui sert au chiffrement du certificat.

Création du certificat serveur

Créez dans un premier temps une nouvelle clé :

openssl genrsa -out server.key 2048

Puis créez une CSR (Certificat Signing Request) ou une demande de signature de certificat (c’est l’équivalent du formulaire que vous remplissez en mairie pour faire votre carte d’identité) :

openssl req -config ./openssl.cnf -new -key server.key -out server.req

Vous devrez saisir certains paramètres dont le Common Name qui doit correspondre au nom de votre serveur (ou le nom de domaine que vous utiliserez pour vous y connecter).

Enfin, signez la CSR avec le certificat de l’autorité de certification pour obtenir votre certificat serveur :

openssl x509 -req -in server.req -CA ca.cer -CAkey ca.key -set_serial 100 -extfile openssl.cnf -extensions server -days 3650 -outform PEM -out server.cer

Trois fichiers seront générés, server.req qui est la CSR et que vous pouvez supprimer, ainsi que server.cer et server.key, respectivement le certificat et la clé du certificat.

Création du certificat client

Comme pour le certificat serveur, il faut commencer par générer une nouvelle clé :

openssl genrsa -out client.key 2048

Puis émettre une CSR :

openssl req -config ./openssl.cnf -new -key client.key -out client.req

Et signer la CSR avec la CA pour obtenir le certificat client :

openssl x509 -req -in client.req -CA ca.cer -CAkey ca.key -set_serial 101 -extfile openssl.cnf -extensions client -days 3650 -outform PEM -out client.cer

Note : si vous créez plusieurs certificats, incrémentez le numéro de série qui est ici de 101 et qui était de 100 pour le certificat serveur.

Pour que vous puissiez installer votre certificat client dans votre navigateur internet ou votre smartphone, il convient de le convertir au format pkcs12. Le fichier pkcs12 contient à la fois la clé et le certificat :

openssl pkcs12 -export -inkey client.key -in client.cer -out client.p12

Nous obtenons ainsi le fichier client.p12 qui contient le certificat client. Vous devez installer ce fichier dans votre smartphone en vous l’envoyant par mail, ou dans votre navigateur sur votre PC en passant par les paramètres avancés.

Pour aller plus loin, nous pourrions créer une CRL ou liste de « révocation » ; il s’agit d’une liste dans laquelle est inscrit tous les certificats que nous souhaitons interdire. Si par exemple vous vous faites voler votre smartphone, vous pouvez ajouter le certificat qui était installé sur votre smartphone à cette liste de révocation pour en interdire l’accès. Vous obtiendrez plus d’information sur les certificats et les listes de révocation en suivant ce lien.

Apache et reverse-proxy

Il s’agit ici de mettre en place un proxy, ou plus précisément, un reverse proxy. Sa fonction première est de gérer l’aiguillage des flux vers la caméra ou la box domotique par exemple. En parallèle il assurera le chiffrement du flux ainsi que la vérification du certificat client (la carte d’identité de l’utilisateur).

Editez le fichier /etc/apache2/site-enabled/000-default et remplacez son contenu par la configuration suivante en remplaçant le chemin vers les certificats du serveur et de la CA :

<VirtualHost *:443>
  
  SSLEngine On # activation https
  SSLCertificateFile /chemin/server.cer # certificat serveur
  SSLCertificateKeyFile /chemin/server.key # clé du serveur
  SSLVerifyClient require # force le serveur à vérifier le certificat client
  SSLVerifyDepth 1 # le certificat client doit être signé par la même autorité de certification
  SSLCACertificateFile /chemin/ca.cer # certificat de l'autorité de certification
  ProxyRequests Off # désactive les requêtes proxy
  
  # redirige camera1 sur l'adresse IP et le port de la caméra 1
  ProxyPass /camera1/ http://192.168.0.17:8080/
  ProxyPassReverse /camera1/ http://192.168.100.17:8080/

  # redirige camera2 sur l'adresse IP de le port de la camera 2
  ProxyPass /camera2/ http://192.168.0.18:8080/
  ProxyPassReverse /camera2/ http://192.168.0.18:8080/
  <Proxy *>
    Order allow,deny
    Deny from all
    allow from all
  </Proxy>
  LogLevel warn
  ErrorLog ${APACHE_LOG_DIR}/rproxy_error.log
  CustomLog ${APACHE_LOG_DIR}/rproxy_access.log combined
</VirtualHost>

Firewall

Puisque nous sommes vigilants, nous allons configurer des règles firewall sur notre passerelle sécurisée pour nous assurer que seul le port 433/TCP soit accessible de l’extérieur. Nous utiliserons pour cela iptables qui est installé de base sur Raspbian.

Créez le fichier /etc/init.d/firewall.sh :

#! /bin/bash

### BEGIN INIT INFO
# Provides: firewall
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Gateway firewall script
# Description: Enable service provided by daemon.
### END INIT INFO

tables_start()
{
iptables -N INPUT_LOG_ACCEPT
iptables -A INPUT_LOG_ACCEPT -j LOG --log-prefix "INPUT_ACCEPT -> "
iptables -A INPUT_LOG_ACCEPT -j ACCEPT

iptables -N INPUT_LOG_DROP
iptables -A INPUT_LOG_DROP -j LOG --log-prefix "INPUT_DROP -> "
iptables -A INPUT_LOG_DROP -j DROP

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT # accepte toutes les connexions en provenance du réseau local
iptables -A INPUT -p tcp --dport 433 -j INPUT_LOG_ACCEPT # on n'accepte que les connexions sur les port 433/TCP depuis l'extérieur
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state NEW,INVALID -j INPUT_LOG_DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -j ACCEPT
}

tables_clear()
{
iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
}

tables_stop()
{
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -j REJECT
iptables -A OUTPUT -j REJECT
iptables -A FORWARD -j REJECT
}

tables_usage()
{
echo "usage: $0 [ start | stop | clear ]"
}

case "$1" in
stop)
echo " Stoping firewall ..."
tables_clear
tables_stop
exit 0
;;
clear)
tables_clear
exit 0
;;
start)
echo " Starting firewall ..."
tables_clear
tables_start
exit 0
;;

-h|--help)
tables_usage
exit 0
;;
*)
tables_clear
tables_start
exit 0
;;
esac

exit 1

Modifiez les droits d’exécution de ce script, puis lancez le automatiquement au démarrage du système :

chmod 755  /etc/init.d/firewall.sh
cd /etc/init.d
update-rc.d firewall.sh defaults

Redémarrez votre Pi, tout est prêt 🙂

Le mot de la fin

Il est difficile de proposer une solution « clé en main » pour ce type de système car il faut l’adapter à son réseau et à ses besoins. Dans tout les cas, le plus important à retenir est le principe de centraliser tous les accès sur une passerelle sécurisée avec une authentification forte et un chiffrement des flux.

La sécurité informatique est un sujet très vaste et complexe qui fait intervenir de nombreuses technologies et une multitude de concepts. J’espère vous avoir permis de mettre un pied dedans en vous aidant à protéger l’accès à vos équipements.

Dans cet article j’ai pris l’exemple d’une caméra IP, car c’est un exemple « choquant » en terme de sécurité (on peut être espionné à l’intérieur de chez soit), mais cette passerelle sécurisée peut être utilisé pour tout type d’équipement et projet comme par exemple :

N’hésitez pas à intervenir en commentaire pour proposer des améliorations à cette passerelle sécurisée 😉

64 réflexions au sujet de « Créer une passerelle sécurisée avec un Raspberry Pi »

  1. Jérémy

    Très bon guide comme d’habitude! 🙂
    Si j’ai bien compris, pour accéder à la caméra 1 depuis l’extérieur il faut entrer l’URL https://[domaine]/camera1 c’est bien ça?
    Du coup est-il possible d’utiliser cette méthode pour d’autres protocoles? Pour protéger un accès ssh ou autre. Le but pour moi serait de créer une passerelle sécurisée pour protéger un serveur avec plusieurs services utilisant plusieurs protocoles différents et donc plusieurs ports différents. Apache en reverse proxy peut-il gérer ça?

    Merci!

    Répondre
    1. Olivier Auteur de l’article

      Hello 🙂
      Oui tout fait, on peut s’en servir pour gérer l’accès à différents services.
      SSH est un cas particulier puisqu’il permet de fait la même chose qu’Apache dans ce domaine (reverse-proxy + chiffrement + certificat).

      Répondre
  2. Kikouk

    Merci pour ce guide.

    [Mode feignant ON]
    Même si d’un point de vue connaissance informatique, je suis apte à réaliser tout cela, existe-il des softs ou des équipements qui permettent de réaliser la même fonction tout ça au sein d’une interface graphique conviviale ?
    [Mode feignant OFF]

    Répondre
  3. Kikouk

    Il y a une chose que je n’ai compris sur la configuration du firewall: pourquoi ouvrir le port 433/TCP ? Est-ce juste pour l’exemple avec une valeur arbitraire ? Un service particulier se cache-t-il derrière ?
    Autre chose : est-il aisé de mettre en place un système de notification par e-mail pour chaque tentative de connexion à un service géré par cette passerelle ? Je pense que c’est un moyen supplémentaire de détecter des tentatives d’intrusion. Merci à toi.

    Répondre
    1. Olivier Auteur de l’article

      Le firewall doit permettre les connexions sur le port 443/TCP car le reverse proxy Apache écoute sur ce port (Cf conf du reverse proxy Apache).
      Effectivement, il serait intéressant de mettre en place un système d’alerte. Le plus simple est d’installer logwatch qui va envoyer des mails régulièrement avec les connexions enregistrées.
      Pour aller plus loin, on peut également utiliser fail2ban, qui bannira automatiquement une adresse IP après quelques tentatives de connexion échouées 🙂

      Répondre
      1. Kikouk

        Merci Olivier c’est plus clair. J’essaierai de faire un retour quand j’aurai mis en oeuvre ton article sur mes équipements avec le système d’alerte en plus.

        Répondre
          1. kikouk

            Salut. J’ai réalisé la première étape de mon projet: mettre en oeuvre ton tuto dans une distro Fedora 21 virtualisée sous VMWare ESxi 5.5. Je n’ai de RPi disponible et je suis plus à l’aise avec Fedora.
            Avant de passer à une signalisation des connexions par e-mail, j’aurai aimé reconfigurer une appli android (tel IP Cam Viewer ou tinyCam Monitor Pro) mais je bloque: j’accède correctement à ma caméra via son interface web mais dès qu’il s’agit de récupérer le flux vidéo en MJPEG ou même de lire son status via Tasker en appelant une page .cgi (caméra FOSCAM) je ne parviens pas à trouver la bonne configuration.
            Ou bien ces applications doivent gérer le certificat installé: en effet, Google Chrome pour Android m’a demandé de sélectionner mon certificat à la 1ère connexion. Une idée ? Merci d’avance.

          2. Olivier Auteur de l’article

            Effectivement, si vous utilisez une appli autre qu’un navigateur, il faut s’assurer que cette appli sache manger le certificat client.

          3. Kikouk

            C’est bien ce qui’il me semblait (avec ma petite expérience en sécurité informatique). Je vais écrire à l’auteur de tinycam monitor pro. Dans sa dernière version, il indique que les certificats auto-signés sont supportés en décochant une option. En revanche, je n’ai rien trouvé qui me propose d’importer mon certificat dans ma configuration caméra. Je reviendrais compléter mon commentaire pour la partie signalisation via e-mail.

  4. philippe_PMA

    Grosse erreur dans ton script iptables : la règle « iptables -A INPUT -j ACCEPT » autorise tout.
    Du coup, même si tu a un DROP par défaut (« iptables -P INPUT DROP ») tout va passer en INPUT.
    J’imagine que c’est un oublie suite à un déverminage.

    Répondre
    1. Olivier Auteur de l’article

      Oula ! Oui en effet, grosse coquille !
      Merci de l’avoir signalé 🙂

      Répondre
  5. issa

    Bonjour,

    super tuto !!

    mais pourquoi ne pas priviligié un openVpn ?

    car comme ça on accède à tout le réseaux de la maison de façon sécurisé ?

    (en fait j’aimerais bien avoir un tuto sur l’installation et la configuration, d’un openVpn)

    🙂

    Répondre
    1. Olivier Auteur de l’article

      L’idée en passant par un reverse proxy c’est de pouvoir accéder à ses services avec un simple navigateur, peu importe la plate forme, et sans logiciel tiers 🙂

      Répondre
  6. Kikouk

    Salut Oliver, je reviens donner des nouvelles de la mise en oeuvre de ton tuto sur ma plateforme à base de Fedora 21.
    Je bute toujours sur le problème que les applications Android de gestion de caméra IP ne semble pas gérer les certificats où alors c’est moi qui ne sais pas faire. Pour tinyCam Monitor Pro, je n’ai pas eu de réponse à mon mail, pour IP CamViewer, impossible de s’inscrire sur le forum, je l’ai signalé mais pas de retour, et pour myLiveCams (http://eggmantechnologies.com/) les auteurs sont en congés jusqu’à fin du mois.
    Pour une connexion au travers d’un navigateur, tout fonctionne.

    Je vais tenter la solution stunnel (qui d’ailleurs réglerait des problème de flux audio) voir VPN (je n’y connais rien je ne sais pas si ça peut être sécurisé avec des certificats).

    Un avis sur Stunnel et/ou VPN ? Merci de ton aide.

    Répondre
    1. Olivier Auteur de l’article

      Hello,
      Effectivement, c’est toujours un peu compliqué de s’appuyer sur des applications tierces… C’est pour cela que je préfère passer par un navigateur qui est toujours plus ou moins standard 🙂
      Reste effectivement la solution du tunnel SSH qui est très simple à mettre en place. Une connexion avec une redirection de port, exactement comme dans cet article (mais dans l’autre sens) et hop, tout roule 🙂
      La mise en place d’un véritable VPN est, AMHA, un peu lourde… Même en pptp c’est vite « chiant » ^^
      Bonne continuation 🙂

      Répondre
      1. maroon

        après refaire se tuto je ne peux plus se connecté on ssh !!! je crois que du fichier firewall.sh

        Répondre
        1. Olivier Auteur de l’article

          Bonjour,
          Il convient d’adapter le script iptables à votre réseau. Il est prévu pour fonctionner sur la plage 192.168.0.0/24.
          Bonne continuation 🙂

          Répondre
  7. Amélie

    Attention, WebRTC n’est qu’un soucis parmi d’autres concernant l’anonymat et les VPN ! Il est impératif de soigner sa configuration afin d’éviter DNS leak et IPv6 leak. Peu de gens connaissent ces points faibles aujourd’hui…

    Répondre
  8. Gregpouet

    Salut ! Superbe article que je suivrai certainement 😉
    J’ai toutefois une petite question : aujourd’hui je me connecte à mon réseau local en utilisant un vpn installé sur mon raspberry. Est ce que c’est compatible avec l’installation d’une passerelle ? Si oui, est-il preferable d’installer le vpn sur la passerelle ou sur un autre raspberry du reseau local ?
    Merci.

    Répondre
    1. Olivier Auteur de l’article

      Hello,
      L’idée d’une « passerelle » est de créer un lien sécurisé entre l’intérieur et l’extérieur de ton réseau. Par principe, il vaut mieux avoir un seul point d’entrée et donc installer le your sur un seul Pi 🙂

      Répondre
  9. julienletraveller

    Bonjour,
    N’y a t’ilboas une histoire de changer le port du serveur car les robot des hackers scannent le port 22 par exemple.
    Pourrais tu rajouter cela a ton tuto ou alors me dire comment faire svp

    PS super tes tutos!!!

    Répondre
    1. Olivier Auteur de l’article

      Hello,
      Merci bcp 🙂
      Effectivement, le port standard 22/TCP peut être la cible de robots. Cependant, ce port n’a pas vocation à être directement accessible depuis internet. En principe, votre box ne doit pas forwarder les connexions de ce port vers votre Pi.
      Toutefois, si vous souhaitez tout de même modifier le port par défaut de SSH, voici comment faire :

      Editez le fichier /etc/ssh/sshd_config, et modifier la ligne :
      Port 22
      (mettez de préférence un port supérieur à 1024 pour éviter les conflits).
      Enregistrez puis redémarrez SSH avec la commande suivante :
      service ssh restart

      Répondre
      1. julienletraveller

        Re-bonjour,
        Il faus que je fasse ça sur l’interface utilisateur de ma box ( free). Donc je dois ajouter un nouveau port et ce que tu m’a dis est ce que c’est pour les changements au niveau du pi?

        Répondre
        1. Olivier Auteur de l’article

          Oui en effet, la manip que je t’ai donné c’est pour changer le port de SSH sur ton Pi. Si après tu veux pouvoir y accéder de l’extérieur de chez toi, il faut aller sur ta box et forwarder ce port vers ton Pi.

          Répondre
  10. shllghst

    Hello, coole ce tuto.
    J’ai décidé d’acheter un caméra IP pour tester. Malheureusement il me reste un problème avec le firewall.

    Si j’active le firewall (/etc/init.d/firewall.sh start), sur le Pi donc, je ne peux plus accéder à l’internet via les autres ordinateurs du LAN.
    J’utilise également mon Pi comme server DNS et DHCP (dnsmasq) et ma FreeBox est paramétrer pour forwarder le trafic vers mon Pi qui représente donc la DMZ.
    Je ne suis pas expert en netfilter/iptables. Quelqu’un aurait-il une piste ?

    Ma FreeBox est connecté (côté publique) à un switch et le Pi ainsi que mes autres ordinateurs sont connectés à ce switch.

    Merci d’avance!

    Répondre
  11. Haeris

    Bonjour,

    Merci pour cet excellent tuto sur SSL.

    Par contre, je bute complétement sur la création des CRL.

    J’ai à chaque fois le message « variable lookup failed for ca::default_ca ».

    Du coup, j’ai commencé à rajouter dans le fichier de conf toute la section sur le « Default CA » mais à partir de ce moment là, j’ai des erreurs partout.

    Peux tu m’aider stp?

    Merci

    Répondre
    1. Olivier Auteur de l’article

      Hello,
      Difficile de répondre à l’aveugle :/
      Peux tu nous préciser quel os tu utilises, quelle version d’Apache et copier/coller ta conf Apache ?

      Répondre
      1. Haeris

        Apache 2.4.7
        Ubuntu 14.04.3 LTS

        La conf apache est celle par defaut.
        http://pastebin.com/2CmcLPku

        Ne manquerait il pas des infos nécessaire à la generation de la CRL dans le fichier « openssl.conf »?

        De plus, voici les commandes que j’exécute pour creer ma CRl vide:
        openssl ca -config openssl.cnf -gencrl -keyfile ca.key -cert ca.cer -out revoke.crl.pem
        openssl crl -inform PEM -in revoke.crl.pem -outform DER -out revoke.crl

        Répondre
          1. Olivier Auteur de l’article

            En fait je parlais de la conf de ton vhost apache dans laquelle tu configures les certificats etc

  12. Ping : Rasp | Pearltrees

  13. Ping : Rasp | Pearltrees

  14. Ping : Raspberry - Remote things | Pearltrees

  15. mathias

    Apres avoir fais toute les modifications j’ ai une erreur au démarrage de mon raspberry « Invalid command ‘SSLEngine’, perhaps misspelled or defined by a module not included in the server configuration
    Action ‘configtest’ failed »
    je n’ arrive plus à y accéder en ssh et mon serveur apache ne fonctionne plus avez vous une solution ?

    Répondre
    1. Olivier Auteur de l’article

      Pour que le SSL fonctionne, il faut activer le module Apache idoine.
      Pour SSH, est ce que le service tourne toujours ? Que donne la commande « netstat -tlnp » ?

      Répondre
      1. mathias

        la commande me retourne »
        (Not all processes could be identified, non-owned process info
        will not be shown, you would have to be root to see it all.)
        Active Internet connections (only servers)
        Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
        tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN –
        tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN –
         »
        sinon comment faire pour vérifier si le service ssh tourne toujours je sais qu’ il est activer mais je ne sais pas comment vérifier si il fonctionne en arrière plan
        PS je suis un zéro avec le raspberry et linux

        Répondre
        1. Olivier Auteur de l’article

          Il semble bien que SSH tourne, comme l’indique la commande netstat avec un socket en écoute sur le port 22/tcp

          Répondre
          1. mathias

            serait il possible de restaurer entièrement apache2 à sa date d’ installation ? Merci pour des réponses aussi rapides.

          2. Olivier Auteur de l’article

            En faisant une désinstallation complète : apt-get remove –purge apache2

  16. Ping : Réseau | Pearltrees

  17. Manu

    Merci pour ce tutoriel, je m’en suis inspirer pour construire à mon tour mon reverse proxy avec ssl + certificat client (ou basic auth si pas de certificat client). Il me reste à voir la partie firewall.

    Attention cependant il me semble que tes commandes génèrent un certificat SHA1 et non SHA2. Si le certificat généré vas plus loin que fin 2016 cela va générer un message d’erreur ou d’avertissement dans le navigateur…

    J’ai modifié les commandes pour obtenir un certificat valide en SHA2. voir ici : http://domoticz.web2diz.net/?p=488

    A+

    Répondre
  18. Ping : Raspberry secure proxy with SHA2 SSL and client cert | Domotic and stupid geek stuff – EN

  19. Ping : SHA 2 SSL certificate with trusted Apache web server | Domotic and stupid geek stuff – EN

  20. Sun

    Hello,

    Super tuto et très bien expliqué. Je me posait quand même une question. j’ai un rasphberry qui me sert de box domotique avec jeedom et ma question était, si j’ai mon rpi sous resbian avec jeedom pour le côté domotique, je peux utiliser le même rpi pour la partie apache ?

    A+

    Répondre
    1. Olivier Auteur de l’article

      Hello,

      Oui tu peux utiliser le même RPi mais le principe d’une passerelle c’est de faire l’étanchéité entre Internet et ton réseau local :p

      Répondre
      1. Sun

        D’accord merci de la réponse. Donc il vaut mieux que je prenne un autre rpi, pour avoir mà domotique sur un et la passerelle sur l’autre. Je vais essayer tous ça ; )

        A+

        Répondre
  21. Ping : Raspberry - Remote things | Pearltrees

  22. bdiar

    Très bon tuto.
    Tout marche nickel pour moi sauf le flux vidéo qui ne s’affiche !!
    A priori l’erreur semble venir du Web Plugin ActiveX installé sur le client. J’ai une TP Link NC220 et le plugin est franchement de mauvaise qualité (même pas disponible pour Chrome). Quelqu’un a une solution ou bien une référence de caméra plus adapté…

    Répondre

Laisser un commentaire