Sécuriser un intranet

Support Debian
#1

Bonjour à tous.

Je souhaiterai savoir comment faire pour sécuriser un site intranet, pour un accès de l’extérieur (web)

Je m’explique:

J’ai monté un serveur apache au travail que je n’utilise qu’en local. Il tourne sur une debian sqeeze et n’accepte que les requêtes locales (via le fichier de conf d’apache). Bien qu’en local, j’utilise le protocole https.
Pour pouvoir travailler de mon domicile, j’ai rajouté (dans le fichier de conf d’apache) mon IP externe.

J’aimerai pouvoir me connecter via mon iphone ou ipad au serveur: comment faire pour sécuriser la connexion ?
(les données étant sensibles = cabinet médical !)

OpenVPN ? Comment faire ? service tierce ou serveur vpn sur le serveur apache web dédié ?

Un peu d’aide (explication ou lien vers tuto) serait appréciable.

#2

Bonjour,

J’ai peur de ne pas comprendre la question… Les périphériques doivent se connecter sur le serveur (TELNET/SSH) ou sur l’application web du serveur (HTTP/HTTPS) ?

Pour accéder depuis l’extérieur à un site il faut faire du NAT dans le routeur. C’est à dire expliqué que lorsqu’on accède au port 80 de l’adresse IP publique (celle à l’entré du routeur, coté FAI) il la redirige sur le port de l’adresse IP privé du réseaux interne (coté ordinateur du routeur).
Le rôle NAT se configure sur le routeur.

Des architecure DMZ (voir “DMZ en sandwich”) sont particulièrement efficace pour protéger un intranet/extranet !

Hormis si je me trompe, si le site web est en HTTPS il n’y pas de raison que la liaison ne soit pas sécurisé et à part un “Man In The Middle” et la conception même du site je ne vois pas trop le risque.

Après, à ce que j’ai toujours entendu dire, la solution de sécurité parfaite n’existe pas… Il y aura toujours un petit malin (génie ?) pour trouver une faille/exploit. Surtout sur des systèmes fermé tel que I-Choses !

Je sais pas si j’ai pu aider…

#3

Le pc debian est accessible de l’extérieur via ssh et HTTPS (selon ip) via un port forwarding du routeur…
Je trouve mon pc en bidouillant mon fichier /etc/hosts, chose que je ne peux pas faire sur les i-bidules (excepté jailbreak…)

Une connexion HTTPS est-elle suffisamment sécurisée ?
Pas besoin d’encapsuler la connexion via un tunnel SSH ou VPN ?

Quoiqu’il en soit toute réponse aide :wink:

#4

HTTPS : C’est bien avec un organisme de certification (thawte, etc, qui coute cher)
Le S de HTTPS vient de SSL qui rajoute une couche de chiffrement au protocole HTTP :http://fr.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure
Pour info SSh c’est grosso modo un TELNET avec une couche SSL donc faire passer du HTTPS en SSH c’est un peu redondant :smiley:

En tapant nomdedomainequivaabien dans Safari de l’I-Truc ca marche pas ? (je crois que j’ai toujours pas compris…)

#5

Ben justement. J’ai pas véritablement de DNS, histoire de ne pas être “catalogué” ou du moins référencé…
donc j’ai :
monsite.org défini en local… via /etc/hosts défini en local.
Je ne peux donc pas faire correspondre l’ip externe et local vers le serveur apache.

Je ne sais pas si je suis clair ?

#6

je pense que tu auras une idée de réponse via ce lien:
http://httpd.apache.org/docs/trunk/fr/ssl/ssl_howto.html#intranet

L’idée est de diriger tous les flux d’Internet ou le flux sécurisé (ssl) sur une connexion ssl (port 443) et de vérifier que la personne a bien un certificat pour se connecter (cela évite d’avoir à taper un mot de passe. Seul hic, ne pas se faire piquer son certificat)

Donc Paramétrage d’Apache selon le lien ci dessus…
Il faut bien entendu que tu autorises le monde entier à se connecter à ton site (du moins pour la parti sécurisé en ssl)
Redirection du port 443 vers ta machnie sur ton routeur/Firewall/Box…

Connaitre son adresse ip pour l’acces (dans ces cas la, pas besoin de dns)
Mettre les certificats qui von bien dans tes appareils (iphone, tablette…)

accéder au site via adresse.ip.de.ton.site

Voila pour la théorie…

Cordialement,

#7

A ouais… super !
Je viens de comprendre un point fondamentale: le certificat ssl créer pour le site https peut servir à l’autentification des “clients”. Je vais étudier ça.

Ainsi, je vais utiliser l’accès en VPN que j’ai sur mes i-bidules pour limiter les ip avec lesquels je vais me connecter , depuis l’extérieur à mon serveur https… ce qui fera 4 sécurités (vpn -> https -> login -> certificat)

Right ?

Edit : Le site en question est bati sur le framework codeingniter. Les adresses internes étant basé sur monsite.org, si je fais de l’extérieur ip_externe_du_server je n’accède pas correctement à ma page…

#8

cf http://fr.wikipedia.org/wiki/R%C3%A9seau_priv%C3%A9_virtuel

Ca veut dire vulgairement qu’une fois connecté via VPN, c’est comme si tu étais dans ton réseau local sur ton site. (Je mets un bémol car la stabilité de ta connections dépend très fortement du réseau que tu utilises pour te connecter.)

Je ne suis pas sure de te suivre pour “https -> login -> certificat” car HTTPS utilise déjà un certificat.

Pour rappel, HTTPS n’est pas loin du VPN dans le principe. HTTPS est la combinaison du HTTP avec une couche de chiffrement comme SSL ou TLS. Vas voir Wikipédia: http://fr.wikipedia.org/wiki/HTTPS

Ca veux donc dire que tu fait un premier tunel avec ton vpn et ensuite dans ce tunel, tu fait un deuxième tunel pour te logger de manière sécurisé.

La dernière partie (certificat) n’a pas vraiment de sens.

#9

Question certificat… j’ai bien peur de ne pas avoir tout compris…

PARTIE 1 (partie déjà mise en place):
Quand je me connecte à mon site https, il me dit automatiquement que le site est sécurisé (avec un certificat autosigné…) et me demande si je veux accepter la connexion… Le client récupére donc le certificat… non ?
donc tout le monde à accès au certificat ?

    Allow from 192.168.1.0/24 88.XXX.XXX.XXX      // <- ip externe (unique) du domicile (internet)
    SSLCertificateFile /path/to/www.example.com.cert
    SSLCertificateKeyFile /path/to/www.example.com.key

Partie 2 (A mettre en place):
Mais pour obtenir un accès complet au site, le serveur apache devra vérifier l’existence d’un autre certificat client (non ?)

    Allow from 192.168.1.0/24 XXX.XXX.XXX.0/24      // <- ip externe du vpn (internet)
# exige un certificat client signé par le certificat de votre CA
# contenu dans ca.crt
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile conf/ssl.crt/ca.crt

Certificat, qui sera donc attribué aux i-bidules, pour en permettre l’accès quelque soit l’ip externe (internet) utilisé, limité par plage d’ip selon s’il est utilisé un vpn.

Ainsi, que ce soit avec le pc du domicile ou un i-bidule en exterieur, je tombe sur la page initiale du site qui me demande login/password/captcha. La connexion se fera par concordance des 3 et par la présence du certificat sur le client, le tout passant par le tunnel VPN, tout en étant crypté htpps…

Trop farfelu ?

Bon, je comprends que VPN et Https soit un peu redondant, mais d’un côté, je ne peux pas garder un Service VPN seul car effectivement les ruptures de connexion créeraient des failles de sécurité, mais permet un filtrage d’ip comme si j’étais en local… tandis que https tout seul m’oblige à laisser accessible le site à tout le monde… (ou du moins la page initiale… à moins d’utiliser une page “fake” pour tromper l’utilisateur, sans certificat par exemple…)

Faisable or not ?
Comment fait-on le “certificat” qui permettra la connexion des i-bidules ?
et comment faire pour pas se le faire voler ?

J’ai été un peu long… mais cela doit être un peu plus clair… (ou du moins j’espère).
:wink:

PS: en vous souhaitant une bonne nuit !

#10

Pour la partie 1:

client récupére donc le certificat… non? => oui, s’il est autorisé à établir une connexion (cf. Allow from 192.168.1.0/24 88.XXX.XXX.XXX)
donc tout le monde à accès au certificat ? => Non, seulement ceux autorisés à se connecter.

Pour la partie 2:

Plus d’info ici sur comment créer ton certificat.
Pour être honnête, je ne l’ai pas encore fait. Mais il semble que tu sois dans la bonne direction.
Avec la config que tu donne, il semble qu’Apache ne distribue pas la clef publique mais la demande (SSLVerifyClient require).
Dans la création de ton certificat, tu va avoir des fichiers *.cert et *.key.
*.cert => clef priver à garder et protéger
*.key => clef publique à utiliser pour authentifier. c’est celle la que tu dois distribuer à tes i-biduels…
Par contre il faut savoir si tes i-bidules sont capables de gérer ces clefs et ou il faut les mettre.

Je fini après manger, à toute

#11

[quote]Pour la partie 1:

client récupére donc le certificat… non? => oui, s’il est autorisé à établir une connexion (cf. Allow from 192.168.1.0/24 88.XXX.XXX.XXX)[/quote]
Il récupère quoi comme certificat ? le .key ?

Reste donc sur le serveur.

…

#12

Re bonjour,

Désolé pour le temps pris dans la réponse.

*.cert => clef priver à garder et protéger, celle qui reste sur ton serveur.
*.key => clef publique à utiliser pour l’authentification. c’est celle la que tu dois distribuer à tes i-biduels… ou que tes clients récupèrent.

Je ne sais pas si tu as remarqué, mais ta partie 1 et 2 sont différentes.
Dans la partie 1, tu renseignes:

Je pense que cette ligne permet la distribution du certificat publique.

Dans la partie 2, tu as:

[quote]SSLVerifyClient require
SSLVerifyDepth 1[/quote]
Je pense que par le biais de ces lignes, Apache demande aux clients d’avoir le certificat publique qui correspond à la partie du certificat privé qui est sur ton serveur et renseigné via la ligne:SSLCACertificateFile conf/ssl.crt/ca.crt

Est-ce plus claire?

#13

Ca commence à être un peu plus clair… mais je n’arrive pas à tout comprendre.

Si je me connecte… je récupère automatiquement le certificat (clé public) pour pouvoir accéder au site. donc pourquoi apache doit-il vérifier si le certificat est bien en la possession du client puisque initialement il lui la envoie ?
De même si j’acquière le certificat en me connectant, il est donc inutile de copier/coller ce certificat sur les i-bidules ?

il y a 3 éléments ?
*.cert
*.crt
*.key

…?

#14

Désolé, Je me suis lamentablement trompé,
J’avais éris:

[quote]*.cert => clef priver à garder et protéger
*.key => clef publique à utiliser pour authentifier. c’est celle la que tu dois distribuer à tes i-biduels…[/quote]

Mais en fait c’est:
*.cert => clef publique à utiliser pour authentifier. c’est celle la que tu dois distribuer à tes i-biduels…
*.key => clef priver à garder et protéger

cf: http://httpd.apache.org et le wiki ici

*.cert et *.crt => ca a l’air d’etre la meme chose, cf ce site

#15

Super merci pour ton aide, tes liens… J’ai plus qu’à potasser tout ça !

Je commence à cerner ce qu’il est nécessaire de faire…

Merci également à ZENITUDE pour avoir lancer le post.

K.