Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 27-07-2017 18:34:46

gnulux
Membre
Lieu : cambrousse
Distrib. : Debian GNU/Linux - Debian 8 / Debian 9
Noyau : Linux 4.9.0-0.bpo.3-amd64 / Linux 4.9.0-3-amd64
(G)UI : LXDE
Inscription : 26-07-2017
Site Web

VPN et pare-feu firewall ufw

Bonjour,

J’ai lu des fils et la doc du wiki de Debian-facile. J’ai appris un peu à me débrouiller avec ufw. Mais la doc sur le VPN ne m’a pas aidée à comprendre les bases du VPN.
Sur la box OVH, j’ai activé le pare-feu qui fait comme ufw par défaut:

Default: deny (incoming), allow (outgoing)



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 smile

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 20:04:52)

Hors ligne

#2 28-07-2017 00:24:57

raleur
Membre
Inscription : 03-10-2014

Re : VPN et pare-feu firewall ufw

gnulux a écrit :

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 ?

gnulux a écrit :

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.

gnulux a écrit :

Et il y a donc un firewall apparemment


Tu peux exécuter la commande iptables-save en root pour voir les règles actives.

Hors ligne

#3 28-07-2017 19:45:57

gnulux
Membre
Lieu : cambrousse
Distrib. : Debian GNU/Linux - Debian 8 / Debian 9
Noyau : Linux 4.9.0-0.bpo.3-amd64 / Linux 4.9.0-3-amd64
(G)UI : LXDE
Inscription : 26-07-2017
Site Web

Re : VPN et pare-feu firewall ufw

Coucou raleur,

As-tu seulement regardé ce qu’est Bitstream et les fournisseurs de ce logiciel de VPN? Je me suis mal exprimée en parlant des DNS de Bitmask, ce sont ceux du serveur VPN.
Ce serveur de VPN n’est pas du tout un FAI. Et il ne garde aucun log, ni celle des connexions, contrairement aux FAI français en tous cas qui y sont obligés par la loi.
Je suis d’accord qu’il faut évidemment pouvoir faire confiance au serveur de VPN et aux gens qui font Bitmask. Et en plus, c’est une version beta.

Mais je n’ai rien à cacher comme l’immense majorité des gens, donc si le service s’effondre ou disfonctionne, eh bien mon FAI me retrouve sur Debian-Facile big_smile

Par exemple, LDN (Lorraine Data Network) offre un service VPN. C’est une association qui fait FAI mais qui offre à tout le monde un service VPN payant préinstallé et paramétré sur la brique internet. Ils sont dignes de confiance. Qu’un FAI associatif du réseau FFDN voit ce que je fais ne me dérange pas car je sais qu’ils s’en fichent et pourquoi ils fournissent ce service (pas pour l’argent). Il y a une différence.

Sans VPN, je préfèrerais passer par les DNS de FDN, même si c’est barbant car la box de notre FAI ne permet pas un changement de DNS (donc, faut le faire avec resolvconf). Les DNS de certains FAI sont des DNS menteurs. Je ne passerais pas par les DNS de Google ni ceux d’OpenDNS (voir Stéphane Bortzmeyer).

En tous cas, merci beaucoup pour la commande iptables-save que je vais essayer donc smile

Hors ligne

#4 28-07-2017 20:21:39

raleur
Membre
Inscription : 03-10-2014

Re : VPN et pare-feu firewall ufw

gnulux a écrit :

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.

gnulux a écrit :

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.

Hors ligne

#5 31-07-2017 15:02:24

gnulux
Membre
Lieu : cambrousse
Distrib. : Debian GNU/Linux - Debian 8 / Debian 9
Noyau : Linux 4.9.0-0.bpo.3-amd64 / Linux 4.9.0-3-amd64
(G)UI : LXDE
Inscription : 26-07-2017
Site Web

Re : VPN et pare-feu firewall ufw

En relisant ton commentaire, j’ai compris ce que tu voulais dire, raleur. On est bien d’accord.

Bien sûr, il faut avoir confiance dans son fournisseur d’accès. Je ne peux pas vérifier les équipements de FDN mais j’ai confiance en FDN, entre autres parce que j’ai vu des conférences de Benjamin Bayart.

Est-ce qu’on peut avoir confiance dans nos FAI commerciaux, audit ou non? Bon, je comprends bien que 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.

Et au final, tu veux sans doute nous dire, que 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. Mais cela demande de bonnes compétences, parce que si on fait des bêtises sur son serveur, c’est sans doute pire que de se contenter de son FAI commercial.

Hors ligne

#6 31-07-2017 20:44:12

gnulux
Membre
Lieu : cambrousse
Distrib. : Debian GNU/Linux - Debian 8 / Debian 9
Noyau : Linux 4.9.0-0.bpo.3-amd64 / Linux 4.9.0-3-amd64
(G)UI : LXDE
Inscription : 26-07-2017
Site Web

Re : VPN et pare-feu firewall ufw

Bon, voici les résultats de la commande iptables que tu me demandais de faire, raleur.
D’abord ufw est au minimum:

ufw status verbose


Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip



Et maintenant Iptables avec ufw actif et Bitmask le VPN préconfiguré (qui n’est pas le fournisseur):

iptables-save


# Generated by iptables-save v1.4.21 on Mon Jul 31 19:57:06 2017
*nat
:PREROUTING ACCEPT [4:368]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [1:42]
:POSTROUTING ACCEPT [1:42]
:bitmask - [0:0]
:bitmask_postrouting - [0:0]
-A OUTPUT -j bitmask
-A POSTROUTING -j bitmask_postrouting
-A bitmask -d 127.0.1.1/32 -p udp -m udp --dport 53 -j ACCEPT
-A bitmask -d 127.0.0.1/32 -p udp -m udp --dport 53 -j ACCEPT
-A bitmask -p udp -m udp --dport 53 -j DNAT --to-destination 10.42.0.1:53
-A bitmask -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.42.0.1:53
-A bitmask_postrouting -p udp -m udp --dport 53 -j MASQUERADE
-A bitmask_postrouting -p tcp -m tcp --dport 53 -j MASQUERADE
COMMIT
# Completed on Mon Jul 31 19:57:06 2017
# Generated by iptables-save v1.4.21 on Mon Jul 31 19:57:06 2017
*filter
:INPUT DROP [4:368]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:bitmask - [0:0]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A OUTPUT -j bitmask
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A bitmask -d 192.168.1.0/24 -o eth0 -j ACCEPT
-A bitmask -s 192.168.1.0/24 -o eth0 -p udp -m udp --dport 53 -j ACCEPT
-A bitmask -s 192.168.1.0/24 -o eth0 -p tcp -m tcp --dport 53 -j ACCEPT
-A bitmask -d 239.255.255.250/32 -o eth0 -p udp -m udp --dport 1900 -j RETURN
-A bitmask -d 224.0.0.251/32 -o eth0 -p udp -m udp --dport 5353 -j RETURN
-A bitmask -d xxxxxx/32 -o eth0 -j ACCEPT //IP du serveur fournisseur
-A bitmask -o eth0 -j REJECT --reject-with icmp-port-unreachable
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m state --state RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m state --state INVALID -j ufw-logging-deny
-A ufw-before-input -m state --state INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m state --state RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m state --state INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m state --state NEW -j ACCEPT
-A ufw-track-output -p udp -m state --state NEW -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
# Completed on Mon Jul 31 19:57:06 2017



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:-

-A bitmask -d 127.0.1.1/32 -p udp -m udp --dport 53 -j ACCEPT
-A bitmask -d 127.0.0.1/32 -p udp -m udp --dport 53 -j ACCEPT



Sur mon ordinateur le port 53 est ouvert: DNS.
Bitmask et ufw ne traitent pas les IP multicast de la même manière:

-A bitmask -d 239.255.255.250/32 -o eth0 -p udp -m udp --dport 1900 -j RETURN
-A bitmask -d 224.0.0.251/32 -o eth0 -p udp -m udp --dport 5353 -j RETURN



-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT


Je peux pas dire que j’ai compris la page Wikipedia à ce sujet.

-A bitmask -o eth0 -j REJECT --reject-with icmp-port-unreachable


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 10:22:41)

Hors ligne

#7 31-07-2017 21:31:28

raleur
Membre
Inscription : 03-10-2014

Re : VPN et pare-feu firewall ufw

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.

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.

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...

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.
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.

Hors ligne

#8 01-08-2017 12:04:22

gnulux
Membre
Lieu : cambrousse
Distrib. : Debian GNU/Linux - Debian 8 / Debian 9
Noyau : Linux 4.9.0-0.bpo.3-amd64 / Linux 4.9.0-3-amd64
(G)UI : LXDE
Inscription : 26-07-2017
Site Web

Re : VPN et pare-feu firewall ufw

raleur a écrit :

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).

raleur a écrit :

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.

raleur a écrit :

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.

raleur a écrit :

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…

raleur a écrit :

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 smile

Hors ligne

#9 06-08-2017 12:01:18

gnulux
Membre
Lieu : cambrousse
Distrib. : Debian GNU/Linux - Debian 8 / Debian 9
Noyau : Linux 4.9.0-0.bpo.3-amd64 / Linux 4.9.0-3-amd64
(G)UI : LXDE
Inscription : 26-07-2017
Site Web

Re : VPN et pare-feu firewall ufw

Du nouveau, car j’ai lu attentivement les documents sur Bitmask: https://leap.se/en/docs/client/bitmask-firewall
Bitmask n’étant qu’une configuration clé en mains, si l’on peut dire, d’OpenVPN, les DNS sont ceux du fournisseur d’accès au service de VPN.  On n’est pas censé utilisé la démo offerte par le site de bitmask autrement que pour faire des essais.

Pour le parefeu de Bitmask, voici la page d’info: https://leap.se/en/docs/client/bitmask-firewall

Leap a écrit :

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:

Wikipedia a écrit :

Egress filtering helps ensure that unauthorized or malicious traffic never leaves the internal network.

Dernière modification par gnulux (24-08-2017 10:16:57)

Hors ligne

Pied de page des forums