Version imprimable
Bonjour,
Je souhaite bloquer l'accès à Facebook dans un réseau local. Mon soucis est mon routeur ne me permet que de le bloquer en HTTP et non en HTTPS. Je souhaite donc savoir s'il existe un moyen de bloquer en HTTPS avec un type de routeur spécifique ou avec un serveur particulier à installer dans le réseau?
C'est quoi comme routeur ? Je suis surprisCitation:
Envoyé par vg-matrix
Sinon, tu as un DNS interne ? Tu peux redéfinir facebook.com en 127.0.0.1. Cela n'empêchera pas les utilisateurs de taper l'adresse IP directement mais tu vas embêter la vie de ceux qui ne savent pas.
Pour cela, il faut un DNS interne et surtout que tu obliges tes utilisateurs à passer par ce DNS interne (donc 1 filtre DNS sur le routeur)
Une autre possibilité, un proxy (genre squid) et tu obliges tes utilisateur à passer par ce proxy (donc filtre à mettre dans le routeur)
Et sinon, un vrai routeur (Cisco ou Juniper ou autre), ceux là savent filtrer le HTTP et le HTTPS. Ils ont même des fonctions supplémentaires (IPS, antivirus, listes blanches et noires pour les accès WWW, ...). Par contre, il va falloir casser un peu la tirelire.
Bonsoir Raymond,
Il suffit à l'utilisateur de rentrer les IP de facebook dans le fichier hosts et cette mesure sera contournée.Citation:
Pour cela, il faut un DNS interne et surtout que tu obliges tes utilisateurs à passer par ce DNS interne (donc 1 filtre DNS sur le routeur)
Concernant le filtrage web sur un routeur Cisco c'est possible en http mais pas en https à ma connaissance.
Il me semble que la meilleure solution c'est un proxy web comme Squid.
Alain
C'est vrai aussi (mais cela limite)Citation:
Envoyé par ciscowarrior
Je ne sais pas ce que tu entends avec le filtrage web, moi je pensais à une ACL TCP port 443 à destination des adresses facebook (je ne sais pas combien il y a d'adresses à bloquer).Citation:
Envoyé par ciscowarrior
C'est clairement la meilleure alternative et en plus, c'est évolutif, c'est à dire que le jour où tu veux bloquer twitter aussi, c'est facile. Et puisque je viens de finir la gabarisation de l'article il n'y a pas longtemps, un peu de littérature : Squid et SquidGuardCitation:
Envoyé par ciscowarrior
NBAR ou zone based firewall en utilisant des expressions régulières.Citation:
Je ne sais pas ce que tu entends avec le filtrage web, moi je pensais à une ACL TCP port 443 à destination des adresses facebook (je ne sais pas combien il y a d'adresses à bloquer).
Le problème des ACLs c'est que si Facebook change ses IP cela ne fonctionnera plus
Alain
Je ne connaissais pas cette fonctionnalité, c'est donc plus un filtrage applicatif qu'un filtrage par ACL au niveau 3 ou 4Citation:
Envoyé par ciscowarrior
C'est vrai :P donc ==> proxy foreverCitation:
Envoyé par ciscowarrior
Oui c'est du filtrage d'URL au niveau applicatifCitation:
Je ne connaissais pas cette fonctionnalité, c'est donc plus un filtrage applicatif qu'un filtrage par ACL au niveau 3 ou 4
Alain
Le trafic étant crypté, les seules informations "en clair" dont tu disposes avec l'htpps, ce sont les ips et les mac ( grosso modo )
Justement, c'est là que je ne comprends plus.Citation:
Envoyé par becket
Dans un navigateur, lorsque l'on tape "https://www.mon-site.com:443/bonjour/toi-meme.php", la partie "www.mon-site.com" n'est pas dans la partie chiffrée du protocole, elle se trouve dans le header IP (après résolution DNS bien sûr). De même que le numéro de port se trouve dans le header TCP.
Donc la partie filtrage URL ne devrait traiter que la partie "/bonjour/toi-meme.php" qui elle est chiffrée et dans le cas de HTTPS, je comprends qu'elle ne soit pas accessible.
Donc un filtre du genre "www.facebook.com:443 deny" (peut importe la syntaxe) devrait pouvoir être accepté même en HTTPS.
Ou alors l'URL complète est répétée/dupliquée dans la partie HTTP et le filtrage ne se base que sur la partie URL de la requête HTTP (qui est chiffrée et donc inaccessible en HTTPS)
Je me trompe peut être. Pour moi, lorsque tu fais une rêquete http.
Au niveau ip, tu as ceci :
Internet Protocol Version 4, Src: 192.168.42.34 (192.168.42.34), Dst: 208.97.177.124 (208.97.177.124)
et au niveau applicatif, tu as ceci :
GET / HTTP/1.1
Host: perdu.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
et la partie qui contient le get ( mais surtout le host ) est cryptée
OK, donc l'information Host destination est dupliquée.
On la retrouve dans le header niveau 3 (IP) ==> 208.97.177.124 = perdu.com après résolution DNS
et dans la requête HTTP Host = "perdu.com"
En plus, c'est totalement normal sinon, le muti hosting (plusieurs serveurs WWW sur la même IP) ne fonctionnerait pas
Personnellement, je ne vois pas les choses comme ça. Pour moi le host n'est pas dupliqué, tu ne le retrouve que dans le header de la requete.Citation:
Envoyé par ram-0000
Dans la partie IP, tu n'as pas trace du host, tu as juste l'ip du serveur à joindre. Et, comme tu le souligne, dans le cas du multi-hosting on ne peut pas faire de lien direct serveur<->host.
Par contre, ici, dans le cas de Facebook, le problème est autre puisque inverse. Pour un host donné, on a potentiellement plusieurs serveurs (plusieurs IP) y répondant (un seul pour une requête donnée, mais pas forcément le même d'une requête à l'autre).
Donc pour bloquer Facebook, au niveau de l'IP, il faudrait connaitre l'ensemble des IP des serveurs qu'utilise Facebook. Avec le risque en plus de faire du surblocage dans le cas de serveurs multi-hosting (peu probable pour ceux de Facebook, mais c'est un cas particulier)
Merci pour vos suggestions.
J'avoue que c'est pas si simple que ça. Dans tous les cas, je teste le proxy avec Squid et je vous fais un retour.