Faire cohabiter Apache et OpenVPN sur le 443

Hier, je me suis expérimenté à installer OpenVPN sur un serveur tout neuf … Ou plus ou moins une récup d’un vieux PC de @Codeur_Fou x)

Et je dois dire que c’était plutôt simple quand on a un bon tuto. Et c’est là que je vous renvoie à l’excellent billet de Nico Largo sur le sujet.

Il y a juste une toute petite chose qui manque sur son tutoriel. Il utilise le port 443, port qui je le rappel est utilisé communément par le HTTPS.

Comment donc faire cohabiter Apache et OpenVPN pour qu’ils délivrent les pages demandés en HTTPS et le VPN tranquilou ni vu ni connu j’t’embrouille wesh ?

EDIT : Comme me l’a signalé Kahas, je me base sur Debian, mais les modifications sont tout à fait applicables sur d’autres systèmes Linux, il vous suffira d’adapter les commandes. De plus, je modifie Apache, mais la configuration d’Nginx et autres serveurs web sera sensiblement la même.

Le bateau n’est pas dans ce port ? Changeons la destination !

L’idée est en fait toute simple, il suffisait juste d’y penser. C’est @KLMP200 sur Twitter qui m’a donné la piste. Cependant, le tutoriel qu’il m’a envoyé est beaucoup beaucoup trop dense et comprends pleins de modifications inutiles (toucher aux interfaces réseaux ? NO WAY !)

Première chose à faire, ajouter UNE ligne dans le fichier /etc/openvpn/server.conf (en violet, le reste venant du tuto de Nico Largo, remplacez les XXX.XXX.XXX.XXX par l’IP de votre serveur) :

# Serveur TCP/443
mode server
proto tcp
port 443
port-share XXX.XXX.XXX.XXX 4443
dev tun

Un petit redémarrage d’OpenVPN et nous en avons fini avec lui :

sudo service openvpn restart

Ce que vous venez d’ajouter va dire à OpenVPN de rediriger tout le flux qui n’est pas un packet VPN vers un autre port, choisi arbitrairement 4443 (vous pouvez mettre celui qui vous chante x) )

La migration des indiens

Il nous reste plus donc qu’à modifier Apache pour qu’il écoute sur ce nouveau port. Et là, il y a pas mal de fichiers à éditer. C’est parti !

Tout d’abord, /etc/apache2/ports.conf :

<IfModule mod_ssl.c>
NameVirtualHost *:4443
Listen 4443
</IfModule>
<IfModule mod_gnutls.c>
Listen 4443
</IfModule>

Ensuite, /etc/apache2/sites-available/default-ssl (une seule ligne à changer) :

<VirtualHost _default_:4443>

Et enfin vos virtual hosts. Changez tout les *:443 que vous aurez mis par *:4443

Un petit redémarrage d’Apache et ce sera fini 😀

sudo service apache2 restart

Voilà, ce fut rapide, mais bon, je suis particulièrement content que ce genre de choses soit possible, je me demande même pourquoi je n’avais pas utilisé cette technique quand j’étais à Supinfo à l’époque ><

7 réflexions au sujet de « Faire cohabiter Apache et OpenVPN sur le 443 »

  1. Je ne penses pas que ça soit une bonne idée de changer les ports de services sensibles sur des numéros de ports supérieurs a 1024, tout simplement parce que n’importe quel user peut utiliser ses ports.

    Imagine que, pour une raison X ou Y , un de tes services est troué ( on es jamais a l’abris d’un trou de sécu ) et que le apache qui écoute bien le 4443, comme dans ton exemple, crash. N’importe quel user peur alors lancer n’importe quoi sur 4443 et écouter tout ce qui passe .

    Certes il faut une série de « coïncidences » pour qu’un vrai problème soi présent. Mais j’voulais juste ton avis la dessu

  2. Ton exemple est en effet valable pour les serveurs mutualisés ou plusieurs personnes ont la possibilité d’exécuter des scripts comme un serveur web python à l’arrache et intercepter les données qui arrivent.
    N’ayant installé OpenVPN que sur des machines à usage personnel pour le moment, je ne m’étais jamais vraiment posé la question.

    Donc oui, dans le cas d’une machine avec plusieurs utilisateurs, il est envisageable d’utiliser un port ne pouvant être lié qu’avec root (donc en dessous de 1024).
    Après, rappelons-le, ton serveur web n’est pas censé tomber normalement hein ?
    Il faudra forcément qu’il soit éteint pour qu’une attaque telle que tu l’as présenté intervienne.
    Un utilisateur ne pourra jamais se lié au port 4443 si celui-ci est déjà occupé par Apache/Nginx.

  3. A ce stade les machines clientes vont pouvoir se connecter au serveur VPN. Par contre impossible d’aller plus loin que ce dernier car l’adresse 10.8.0.x ne sera par routée en dehors de votre serveur. Il faut donc configurer le serveur pour qu’il joue le rôle de routeur entre l’interface VPN (tun0) et l’interface physique (eth0) et de NATeur entre les adresses en 10.8.0.x et son adresse IP réelle.

    • Bonne remarque, j’avoue ne jamais avoir essayé et à mon avis, il ne devrait pas y avoir de soucis (sauf si OpenVPN gère mal ses propres routes, dans ce cas, une boucle locale se produira, entrainant un timeout).

      Je suis passé récemment sur Nginx et SSLH, rendant ce billet « obsolète », mais rien ne t’empêche de tester, tu n’as pas grand-chose à perdre x)
      Si « localhost » ne fonctionne pas, essaie 127.0.0.1, la résolution de nom peut faire des siennes.

      Promis, je vais gratter un truc sur SSLH un de ces quatre 🙂

Laisser un commentaire