Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pages : 1
Parce que je pense que nos FAI n’ont pas à savoir ce que nous faisons, je commence à utiliser le VPN Bitmask (leap.se). C’est très simple à installer et à utiliser (avec quelques caveats, il faut le surveiller car il est en beta). C’est de l’Openvpn. C’est analogue à ce qu’offre la brique internet mais la brique est plus simple encore.
Pas sûr que je comprends bien ce qui se passe.
Si je comprends bien, le VPN court-circuite la box. L’IP publique en passant par le VPN, ce n’est plus celle de ma box, ce serait celle de mon ordinateur carrément, comme si on était en IPv6?
Si je regarde mon IP en utilisant le VPN, ce n’est bien sûr pas l’IP publique (statique chez OVH) que j’ai donc toujours. J’en ai une autre, qui elle aussi semble statique (pas du tout comme avec TorBrowser) qui est un peu différente de l’IP du VPN (du fournisseur).
Donc, je ne sais pas comment il faudrait régler ufw pour utiliser ce VPN sans risque.
Merci de vos lumières 
Peut-être cet extrait d’une page de bitmask.net peut nous éclairer:
DNS
Domain Name Service (DNS) is the system that allows your computer to resolve domain names like “bitmask.net” to find the real internet address of the appropriate computer. Unfortunately, DNS has many problems:
Most DNS is very insecure, and an attacker can easily forge DNS responses in order to send you to an incorrect server.
DNS doesn’t use secure connections, so an eavesdropper can easily record a history of what internet sites you visit.
Most DNS servers also keep a historical log of all the sites you visit.
For these reasons, Bitmask will ensure that all DNS requests that your computer makes are rerouted to the DNS server of the provider.
This means that you will not be able to make a DNS request to any other DNS server, even if you want to. For example, the command host bitmask.net 8.8.8.8 will not use the nameserver 8.8.8.8 to resolve the name bitmask.net, because the request will get rewritten to use the DNS server of your provider.
You will also not be able to run a local nameserver that attempts to connect directly to the root DNS zone. The packages bind9 or unbound are configured this way by default. These requests will get rewritten to the provider’s DNS server and will fail. Bitmask is compatible with dnsmasq however.
If you wish to disable this behavior for debugging purposes, you can run the command sudo bitmask-root firewall stop although doing so may allow some traffic to bypass the VPN and escape your computer unencrypted.
…
In rare cases, your computer might get stuck in a mode that blocks all network traffic. Try this:
You can run sudo bitmask-root firewall stop to remove all the Bitmask firewall rules that prevent traffic from leaking insecurely.
Deux bonnes choses: en utilisant ce VPN, on passe par les DNS de Bitmask et pas ceux de notre FAI (bon on ne peut pas utiliser ceux de FDN)
Et il y a donc un firewall apparemment qui remplace celui de la box ou ufw?
Dernière modification par gnulux (27-07-2017 19:04:52)
Hors ligne
Parce que je pense que nos FAI n’ont pas à savoir ce que nous faisons
Et ton fournisseur de VPN, tu crois que ce n'est pas un FAI ?
Deux bonnes choses: en utilisant ce VPN, on passe par les DNS de Bitmask
Très bonne chose pour Bitmask qui voit toutes tes requêtes DNS, oui.
Et il y a donc un firewall apparemment
Tu peux exécuter la commande iptables-save en root pour voir les règles actives.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
As-tu seulement regardé ce qu’est Bitstream et les fournisseurs de ce logiciel de VPN?
Je n'ai pas besoin de regarder ce qu'est Bitstream pour savoir qu'un serveur VPN qui fournit un accès à l'internet public via ce VPN est par définition un fournisseur d'accès à internet. Le VPN, c'est juste un tuyau comme l'est une ligne ADSL, une fibre optique ou une connexion wifi à un hot spot.
Je me suis mal exprimée en parlant des DNS de Bitmask, ce sont ceux du serveur VPN.
Peu importe. Ceux qui opèrent ces serveurs voient toutes tes requêtes DNS.
Quant au fait de garder ou pas des logs, à moins de pouvoir auditer leurs équipements, on doit les croire sur parole.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Et maintenant Iptables avec ufw actif et Bitmask le VPN préconfiguré (qui n’est pas le fournisseur):
Je ne comprends pas l’essentiel, qui est de savoir si le parefeu (celui de Bitmask ou de ufw) fait qqchose d’utile ou non.
Ce que je comprends:-
Sur mon ordinateur le port 53 est ouvert: DNS.
Bitmask et ufw ne traitent pas les IP multicast de la même manière:
Je peux pas dire que j’ai compris la page Wikipedia à ce sujet.
Ici, apparemment, Bitmask rejette les ping qui seraient faits vers ma carte ethernet. Ce que ne fait pas ufw, si je comprends bien (pas prévu pour le faire dans sa config par défaut)
Dernière modification par gnulux (24-08-2017 09:22:41)
Hors ligne
Est-ce qu’on peut avoir confiance dans nos FAI commerciaux, audit ou non?
Non. On peut juste avoir confiance que si ça peut leur rapporter plus que cela leur coûte de stocker, traiter, revendre nos données, alors ils le feront.
tu veux dire que ce n’est pas la peine d’éviter Orange pour se jeter chez un fournisseur aussi ou encore pire, sous prétexte que le VPN est tentant.
Je n'ai rien dit de tel. Il faut arrêter d'être hypocrite, dans la plupart des cas les VPN ont une seule utilité : se cacher de HADOPI.
si on n’est pas soi-même maître de son serveur (dans sa maison, pas un data center), on est sûr de rien
Même dans ce cas, on n'est sûr de rien. Rien ne dit que le FAI n'intercepte pas ton trafic DNS pour l'enregistrer ou le rediriger vers ses propres serveurs. Tiens, d'ailleurs, c'est justement ce que font les règles iptables de Bitmask...
Je ne comprends pas l’essentiel, qui est de savoir si le parefeu (celui de Bitmask ou de ufw) fait qqchose d’utile ou non
"Utile", ça dépend du point de vue. Pour un pare-feu "au minimum", je trouve qu'ufw génère beaucoup de règles et de chaînes.
Quant à Bitmask, je n'appelle pas ça un pare-feu. Il installe ses règles avant celles d'ufw pour qu'elles traitent les paquets avant (car un paquet accepté ou bloqué par une règle l'est définitivement quelles que soient les règles suivantes). Le plius important est ce qui se passe dans la table "nat", dans les premières lignes. En résumé, il redirige les requêtes DNS sortantes vers 10.42.0.1 qui, je suppose, est un serveur DNS du fournisseur de VPN. Plus loin, il laisse passer le trafic en sortie avec le réseau local et l'UPnP en multicast sur le réseau local, et bien sûr le trafic vers le serveur VPN, et bloque tout le reste (pas seulement le ping) en sortie par l'interface ethernet.
Il vaut mieux montrer que raconter.
Hors ligne
gnulux a écrit :Est-ce qu’on peut avoir confiance dans nos FAI commerciaux, audit ou non?
Non. On peut juste avoir confiance que si ça peut leur rapporter plus que cela leur coûte de stocker, traiter, revendre nos données, alors ils le feront.
Ils ont aussi des obligations légales (rétention des données). On parlait aussi de boîtes noires, je ne sais pas où ça en est mais ça concernerait sans doute les gros FAI seulement (comme une fois, l’injonction de bloquer tel site en France n’a pas concerné OVH, ni FDN, par exemple, seulement les très gros FAI).
gnulux a écrit :tu veux dire que ce n’est pas la peine d’éviter Orange pour se jeter chez un fournisseur aussi ou encore pire, sous prétexte que le VPN est tentant.
Je n'ai rien dit de tel. Il faut arrêter d'être hypocrite, dans la plupart des cas les VPN ont une seule utilité : se cacher de HADOPI.
Je pense que c’est un apriori. Je me fiche bien d’Hadopi. Mais comme beaucoup de gens qui utilisent GNU/Linux au quotidien, je ne me fiche pas de la surveillance généralisée qui n’apporte rien de bon, comme le soulignent la Quadrature du Net et LDN (Lorraine Data Network) en particulier.
gnulux a écrit :si on n’est pas soi-même maître de son serveur (dans sa maison, pas un data center), on est sûr de rien
Même dans ce cas, on n'est sûr de rien. Rien ne dit que le FAI n'intercepte pas ton trafic DNS pour l'enregistrer ou le rediriger vers ses propres serveurs. Tiens, d'ailleurs, c'est justement ce que font les règles iptables de Bitmask...
Si j’ai bien compris, nos FAI enregistrent notre traffic DNS et conservent les logs, c’est la loi française qui les y oblige même s’ils n’en avaient pas envie. Un fournisseur de VPN aussi si les serveurs sont dans un pays avec une loi analogue.
gnulux a écrit :Je ne comprends pas l’essentiel, qui est de savoir si le parefeu (celui de Bitmask ou de ufw) fait qqchose d’utile ou non
"Utile", ça dépend du point de vue. Pour un pare-feu "au minimum", je trouve qu'ufw génère beaucoup de règles et de chaînes.
Bon, c’est un point à approfondir. Ufw est donné comme une façon simple de paramétrer Iptables…
Quant à Bitmask, je n'appelle pas ça un pare-feu. Il installe ses règles avant celles d'ufw pour qu'elles traitent les paquets avant (car un paquet accepté ou bloqué par une règle l'est définitivement quelles que soient les règles suivantes). Le plius important est ce qui se passe dans la table "nat", dans les premières lignes. En résumé, il redirige les requêtes DNS sortantes vers 10.42.0.1 qui, je suppose, est un serveur DNS du fournisseur de VPN. Plus loin, il laisse passer le trafic en sortie avec le réseau local et l'UPnP en multicast sur le réseau local, et bien sûr le trafic vers le serveur VPN, et bloque tout le reste (pas seulement le ping) en sortie par l'interface ethernet.
Donc, c’est normal qu’il installe ses règles avant ufw, autrement, les régles propres à Bitmask ne pourraient pas marcher. Pourrait-il faire autrement?
Pourquoi ce n’est pas un parefeu? Il laisse passer des trucs pas bons (l’UPnP en multicast sur le réseau local)? (je peux désactiver l’UPnP sur la box de notre FAI).
C’est bien de bloquer tout le reste en sortie, non? ou c’est pas bien de le bloquer par l’interface ethernet?
Pour moi, VPN, Tor, tout ça, ça m’apprend plein de choses. Merci de ta patience, raleur
Hors ligne
The bitmask firewall is egress only. It does nothing to protect the client device from incoming network packets.
Some people may prefer to make bitmask firewall block egress traffic to the local network. This should be made available as an option in the future.
Pour egress filtering, j’ai trouvé dans Wikipedia une définition simple:
Egress filtering helps ensure that unauthorized or malicious traffic never leaves the internal network.
Dernière modification par gnulux (24-08-2017 09:16:57)
Hors ligne
Pages : 1