Re: [gull] HTTPS en home hosting - restreindre la diffusion du certificat X.509
On Fri, Apr 06, 2018 at 12:24:41PM +0200, Frederic Dumas wrote: > Je l'avais consulté en lisant ton mail précédent. Mais mon IP n'y faisant > apparaitre aucun résultat, Le problème est que je ne sais pas comment ils constituent ces bases de données, ma supposition est qu'il s'agit de collecte de données (p.ex. via les moteurs de recherche), suivies de requêtes DNS forward (A/), avec utilisation de tous les enregistrements rencontrés (tous les noms de domaine des serveurs DNS, des serveurs de mail, etc). Donc une énumération partielle du DNS. Le DNS n'est pas `énumérable' en totalité, avec des serveurs DNS bien configurés, comme tu l'écris: > Veux-tu dire que ces bases de données sont alimentées par force brute Ca, je je ne crois pas. Il y a *peut-être* utilisation de dictionnaires simples ou d'analogies (domaine populaire toto.com., alors recherche de toto.$top. pour tous les top domains existants). Il ne faut pas oublier que ceux qui utilisent ces services de recherche sont justement ceux qui font du domain parking, pour acquérir du trafic et donc de la pub. D'un autre côté, je trouve marrant que certains des domaines que ce site trouve pour 46.140.72.222 ne sont pas vraiment référencés nul part. Ce qui me fait penser à une découverte par dictionnaire, mais je n'en ai pas de preuve. Il y en a aussi qu'il n'a pas trouvé parmi ces sites `pas référencés'. > Nous parlons ici de home hosting. Apache n???y fait tourner que quelques > applications web à usage privé. Les domaines dirigeant vers chacun des > virtual hosts ne sont donc connus que du DNS faisant autorité, mais non du > web en général. Dans ce cas, il y aura des scannages à partir de l'adresse IP, pour déterminer les versions des logiciels et alimenter des bases de données comme celle de http://shodan.io/ Il y aura des tests de vulnérabilités des services (serveur DNS, Web, etc). Si la page par défaut de http://ton-adresse-ip/ et https://ton-adresse-ip donne des noms de domaines, ils seront également scannés. Si tu as bien verrouillé tout cela, y compris le /server-status de ton Apache, ça devrait être bon. L'idée de verrouiller le SNI est alors assez bonne, effectivement. > J'ai le lointain souvenir qu'au siècle dernier, les DNS étaient ouverts Oui, tout à fait. Si ton serveur DNS et celui de ton registry n'est pas énumérable, c'est bon. Les autres bases comme WHOIS ne sont probablement pas énumérables facilement non plus. Tant que ton domaine n'est référencé nulle part. Si tu fais du domain parking, alors il se peut qu'il soit référencé. > piste SNI que tu m'as d'abord indiqué. SNI à titre personnel: non verrouillage SNI comme proposé: non plus. Toutefois, il me semble qu'il y a pas mal de tutoriaux pour le SNI, et ensuite il n'est pas très difficile de tester l'effet de la config comme proposée. Tu peux toujours revenir ici avec des problèmes concrets concernant la mise en place. ___ gull mailing list gull@forum.linux-gull.ch http://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] HTTPS en home hosting - restreindre la diffusion du certificat X.509
Bonjour Marc, Bonjour à tous, Je mets de coté la discussion sur la résolution inverse, qui ne nous concerne pas dans le cas présent. Il n’existe aucun enregistrement PTR pour l’IP considérée. > Consulte l'exemple: > >http://viewdns.info/reverseip/?host=46.140.72.222&t=1 Je l’avais consulté en lisant ton mail précédent. Mais mon IP n’y faisant apparaitre aucun résultat, j’y avais trouvé plutôt confirmation qu’un domaine peut rester inconnu à celui qui n’accède au serveur que par sa seule adresse. Nous parlons ici de home hosting. Apache n’y fait tourner que quelques applications web à usage privé. Les domaines dirigeant vers chacun des virtual hosts ne sont donc connus que du DNS faisant autorité, mais non du web en général. > En effet, des gens semblent scanner l'ensemble du DNS forward (pas > reverse) et compiler des bases de données permettant de retrouver > tous les domaines hébergés sur une adresse IP C’est une info intéressante (on utilise vraiment beaucoup d’énergie électrique pour atteindre des buts discutables de nos jours). Veux-tu préciser ce que tu entends par « scanner l’ensemble du DNS forward » ? J’ai le lointain souvenir qu’au siècle dernier, les DNS étaient ouverts, c’est à dire livraient au client qui le leur demandait, la liste complète de tous les champs A pour lesquels ils avaient autorité. Le temps m’a fait oublier les détails, mais surtout, ce fonctionnement a été abandonné je crois, précisément pour éviter que des indiscrets ne reconstruisent un peu trop facilement toute une topologie de réseau. Je suppose donc que tu ne fais pas référence à ça, quand tu utilises le terme « scan ». Veux-tu dire que ces bases de données sont alimentées par force brute ou par dictionnaire, c’est à dire que pour tout domaine référencé quelque part sur le web, des crawlers testent auprès des DNS toutes les combinaisons imaginables de sous-domaines ? Si tel est le cas, mon IP n’est pas totalement à l’abri de leurs agissements, mais le risque de la voir soudain apparaître sur ou similaire me paraît pourtant faible. J’aimerai donc suivre la piste SNI que tu m’as d’abord indiqué. Avez-vous, toi ou d’autres personnes du Gull, l’expérience de sa mise en oeuvre ? Merci. Frédéric. ___ gull mailing list gull@forum.linux-gull.ch http://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] HTTPS en home hosting - restreindre la diffusion du certificat X.509
On Wed, Apr 04, 2018 at 07:00:21PM +0200, Frederic Dumas wrote: > Je ne comprends pas bien, dès lors qu???on a pris soin de ne pas enregistrer > de résolution inverse pour cette IP dans le DNS, de quel énumération veux-tu > parler ? La résolution inverse n'est en général pas énumérable (un seul PTR, même si plusieurs A dans l'autre sens). Consulte l'exemple: http://viewdns.info/reverseip/?host=46.140.72.222&t=1 et tu verras que verrouiller via SNI semble bien illusoire ... En effet, des gens semblent scanner l'ensemble du DNS forward (pas reverse) et compiler des bases de données permettant de retrouver tous les domaines hébergés sur une adresse IP, sans besoin de lire les certificats wildcards ou aliasés. ___ gull mailing list gull@forum.linux-gull.ch http://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] HTTPS en home hosting - restreindre la diffusion du certificat X.509
Merci Marc pour ta réponse. > Donc, il est autorisé d'aborter la négociation TLS/SSL si le nom indiqué > dans SNI n'est pas reconnu. > Cependant, Apache2 semble avoir une configuration: SSLStrictSNIVHostCheck > qui permet de restreindre les clients non SNI, Ce que tu décris semble répondre à ce que je cherche. Voudrais-tu m’aider à re-écrire mon fichier de configuration pour passer à SNI ? > Cela n'empêchera pas l'énumération, en > particulier si un scan du DNS a été fait et une liste de tous les > domaines hébergés par une adresse IP construite[4], mais au moins > l'énumération du certificat ne sera pas possible sans l'énumération > du DNS au départ. Je ne comprends pas bien, dès lors qu’on a pris soin de ne pas enregistrer de résolution inverse pour cette IP dans le DNS, de quel énumération veux-tu parler ? Frédéric. ___ gull mailing list gull@forum.linux-gull.ch http://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] HTTPS en home hosting - restreindre la diffusion du certificat X.509
On 04. 04. 18 16:27, Frederic Dumas wrote: Pourriez-vous me conseiller une façon de restreindre la diffusion de son certificat X.509 par un serveur web en home hosting ? Ben... le certificat X.509 contient la clef publique... et les données permettant de définir si l'on peut faire confiance à ce certificat ou pas. C'est aussi utilisé lorsque l'on examine la CRL (Certification Revocation List). Empêcher la diffusion des données contenues dans X.509 me semble donc contre-productif. Comment alors vérifier si un certificat est valide ou pas ? Ou suis-je dans l'erreur ? Un rewrite dans la configuration d'Apache reformule toute requête HTTP reçue sur le port 80 en requête HTTPS sur le port 443. Oui, mais la requête stipule bien https... donc il veut établir une connexion sécurisée en utilisant SSL : "After the secure connection is made, the session key is used to encrypt all transmitted data. Browser connects to a web server (website) secured with SSL (https). Browser requests that the server identify itself. Server sends a copy of its SSL Certificate, including the server's public key." Par ailleurs, le certificat renferme le nom du domaine pour lequel il a été signé, il dit donc explicitement au visiteur quel domaine correspond à l'adresse IP que celui-ci est en train d'interroger, malgré l’absence d'enregistrement reverse dans les DNS. Cela fait partie des données qui sont comparées entre le CA et celles contenues dans le CA. C'est la raison pour laquelle on ne peut transporter un certificat entre plusieurs serveurs avec des adresse IP différentes. On cherche à établir une connexion sécurisée avec un serveur dûment enregistré sur internet. Cela fait donc partie d'une information essentielle à la vérification et à l'établissement d'une connexion de "confiance" (trsuted). J’aimerai mieux sécuriser le serveur contre les balayages d’IP, Quel genre de balayage IP ? Le scan des ports ? le "header" du serveur ? Le scan des ports peut être restreint en utilisant une (ou des) règle 'itpables' et le "header" peut être modifié dans la config d'Apache. et lui interdire de communiquer ce certificat X.509 à un visiteur se connectant directement sur son adresse IP ou se connectant en résolvant cette adresse IP à travers un domaine fictif. N'importe qui faisant une requête "GET /" en mode HTTPS va recevoir les données permettant de vérifier que le certificat est bien lié au serveur concerné. C'est un peu la base de HTTPS :-) Installer un firewall (iptables), n'ouvrir que les ports nécessaires, ne pas avoir d'accès ouvert sans mot de passe (au minimum), etc. est déjà un bon obstacle à toutes sortes d'attaques, mais on doit bien laisser une porte d'entrée pour le serveur web... De toute façon, il existe des robots qui scannent tous les domaines existants en permanence, quoi que l'on fasse. Il suffit même de scanner le port 80 de chaque domaine, échappant ainsi au "scan detection" de 'iptables'. une fois un port 80 reconnu, les robots/pirates essaient de toute façon de balancer n'importe quel type de requête au serveur. Ces requêtes sont des tentatives d'accéder à des services connus, comme phpmyadmin, phpbb, wordpress, etc. Cela représente pas mal de requêtes et ne cesse jamais. On peut avoir un process qui lit les logs en permanence et met immédiatement les adresses IP en quarantaine, mais ces tentatives recommencerons ensuite avec d'autres sources IP quelques heures après ou le lendemain... J'avais mis ce genre d'outil en place sur un serveur et effectivement cela limite bien le volume des requêtes, mais les pirates peuvent alors identifier vos blocage et décider d'utiliser alors d'autres techniques. Idéalement, il ne faut rejeter ces requêtes ou les bloquer, mais il faut les ralentir... car alors il est beaucoup plus difficile au pirate de reconnaître qu'il a été détecté. D'autant que les requêtes sont effectuées à partir de système piratés (principalement des PC sous W*) et faisant partie de botnets. A noter aussi que la mise en quarantaine d'adresse ip avec 'iptables' passe par l'utilisation de 'ipset' qui permet de gérer des listes d'IP en "hasing", plutôt que de balayer une liste de manière séquentielles, ce qui engendre un comportement algorithmique du style O(n), plutôt que O(1) avec 'ipset'. dc ___ gull mailing list gull@forum.linux-gull.ch http://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] HTTPS en home hosting - restreindre la diffusion du certificat X.509
On Wed, Apr 04, 2018 at 04:27:30PM +0200, Frederic Dumas wrote: > J???aimerai mieux sécuriser le serveur contre les balayages d???IP, et lui > interdire de communiquer ce certificat X.509 à un visiteur se connectant > directement sur son adresse IP ou se connectant en résolvant cette adresse IP > à travers un domaine fictif. C'est une bonne question. J'ai l'impression que ce n'est pas possible de cacher les serveurs hébergés sur une adresse IP, rien qu'à cause du DNS (voir [4] par exemple). La meilleure réponse serait une adresse IP par type de service, de préférence dans une autre plage à chaque fois. Une idée serait de prendre une VM Amazon, Hetzner ou autre et de faire un redirecteur TCP sur une adresse IP non autrement accessible, et un numéro de port différent s'il y a plusieurs certificats pour éviter de montrer le même certificat. D'un autre côté, quelqu'un fera peut-être un jour une base de données des certificats, par scan. Une idée "parfaite" serait un hidden service tor. Mais cela pose d'autres problèmes (performance, etc). En ce qui concerne le problème mentionné: Par défaut, le certificat SSL sera présenté sur le port 443 lors de toute connexion. En effet, le modèle classique est un certificat par adresse IP, envoyé par le serveur avant que le client n'envoie sa requête! L'établissement d'une session SSL/TLS est indépendante du virtual host considéré. On servait plusieurs certificats en utilisant plusieurs adresses IP (ou numéros de port, mais pas très transparent pour l'utilisateur), ou en indiquant plusieurs domaines dans le certificat X.509 (dépendant des règles de l'autorité de certification). C'est justement ce que SNI (RFC-4366, [3] avec du joli ASN.1) a amélioré, en ajoutant une indication avant TLS du domaine considéré, qui permet d'envoyer le bon certificat, et donc d'avoir une adresse IP et un port pour plusieurs certificats différents. La norme [3] dit: "If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal)." Donc, il est autorisé d'aborter la négociation TLS/SSL si le nom indiqué dans SNI n'est pas reconnu. Cela n'empêchera pas l'énumération, en particulier si un scan du DNS a été fait et une liste de tous les domaines hébergés par une adresse IP construite[4], mais au moins l'énumération du certificat ne sera pas possible sans l'énumération du DNS au départ. Toutefois, Wikipedia dit: "Lorsque le navigateur ne gère pas le SNI, le serveur fournit le certificat par défaut," [1]. Cependant, Apache2 semble avoir une configuration: SSLStrictSNIVHostCheck qui permet de restreindre les clients non SNI, et peut-être ainsi d'éviter une énumération [2], à contrôler si cela présente effectivement aucun certificat / interdit la connexion TLS/SSL. [1] https://fr.wikipedia.org/wiki/Server_Name_Indication [2] http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstrictsnivhostcheck [3] https://tools.ietf.org/html/rfc4366#section-3.1 [4] http://viewdns.info/reverseip/?host=46.140.72.222&t=1 ___ gull mailing list gull@forum.linux-gull.ch http://forum.linux-gull.ch/mailman/listinfo/gull
[gull] HTTPS en home hosting - restreindre la diffusion du certificat X.509
Bonjour à tous, Pourriez-vous me conseiller une façon de restreindre la diffusion de son certificat X.509 par un serveur web en home hosting ? La machine héberge quelques applications à usage privé, type NextCloud, tournant sous Apache. Toutes sont accessibles en HTTPS, chacune par son propre sous-domaine. 1er virtual host : https://piero.example.com 2nd virtual host : https://frangin.example.com 3eme virtual host : https://tralala.example.com Un rewrite dans la configuration d'Apache reformule toute requête HTTP reçue sur le port 80 en requête HTTPS sur le port 443. Un seul certificat wilcard <*.example.com> est installé pour tous les virtual hosts. Le module SNI n’est pas activé. Le reste de l’infrastructure en home hosting est classique: le serveur est accessible depuis l'Internet par un NAT et aucun reverse-DNS n’existe pour cette adresse IP publique. L’accès Internet ne dispose que d’une seule adresse IP publique fixe. En HTTPS, le certificat X.509 est systématiquement délivré à n’importe quel visiteur, au tout début de la tentative de connexion, même si celui-ci accède au serveur par son adresse IP, ou même si celui-ci forge n’importe quel domaine dans le header de sa requête HTTP (par exemple en enregistrant localement un domaine quelconque fictif pour cette adresse IP dans son fichier host). A ma connaissance, la façon dont sont configurés les virtual hosts n’y change rien. Par ailleurs, le certificat renferme le nom du domaine pour lequel il a été signé, il dit donc explicitement au visiteur quel domaine correspond à l'adresse IP que celui-ci est en train d'interroger, malgré l’absence d'enregistrement reverse dans les DNS. J’aimerai mieux sécuriser le serveur contre les balayages d’IP, et lui interdire de communiquer ce certificat X.509 à un visiteur se connectant directement sur son adresse IP ou se connectant en résolvant cette adresse IP à travers un domaine fictif. Existe-t-il un moyen d’y parvenir ? Merci ! ___ gull mailing list gull@forum.linux-gull.ch http://forum.linux-gull.ch/mailman/listinfo/gull
