Alors, oui, sur un réseau pas sûr il faut prendre des précautions
Si t’as Free tu as un VPN (pas que chez Free d’ailleurs) 
On peut ajouter un serveur DNS correct (j’utilise NextDNS qui me fait une sorte de pi-hole, mais les puristes proposent parfois d’autres solutions).
Il est aussi judicieux de sécuriser son navigateur (entre autres en désactivant les punycodes)
Ta Debian est déjà sécurisée. Le règles sont toujours les mêmes :
- faire les mises à jour dès qu’elles ont disponibles (surtout celles de sécurité) ;
- éviter d’installer de trucs en dehors des dépôts officiels Debian ;
- éviter d’installer des services que l’on ne maîtrise pas du tout ;
- …
Tant que tu ne t’amuse pas à installer des logiciels serveurs web, ftp, courrier etc. (et encore) tu n’as aucunement besoin de pare-feu.
La pare-feu n’est d’aucune utilité dans ce cas. Quand on est pas sur un réseau de confiance on fait bien attention à utiliser des protocoles sécurisés : HTTPS systématiquement par exemple.
Analogie foireuse. Tant qu’il n’y a aucun service en écoute vers l’extérieur sur ta machine, il n’y a aucune porte.
Relis mon lien sur la RFC 7228 et parcours un peu les forums pour voir tous les problèmes de partage de fichiers ou d’imprimante sur un réseau local qui sont dus à la présence de pare-feu sur toutes les machines.
Tiens : il y a tout le Bénin (156.0.xx.xx) qui frappe à la porte chez moi, dis donc (je ne suis pas du tout au Bénin, ni n’utilise un FAI béninois, ni ne suis en Afrique)
~]$ sudo netstat -apet | grep root
tcp 0 0 localhost:domain 0.0.0.0:* LISTEN root 24606 717/nextdns
tcp 0 0 localhost:ipps 0.0.0.0:* LISTEN root 23082 715/cupsd
tcp 0 334 ordi1.local:57407 156.0.214.34:25842 FIN_WAIT1 root 0 -
tcp 0 0 ordi1.local:52232 46.235.231.150:https TIME_WAIT root 0 -
tcp 0 0 ordi1.local:39572 fra16s14-in-f14.1:https TIME_WAIT root 0 -
tcp 0 160 ordi1.local:57517 156.0.212.20:27672 FIN_WAIT1 root 0 -
tcp 0 0 ordi1.local:52334 46.235.231.150:https TIME_WAIT root 0 -
tcp 0 0 ordi1.local:48928 fra15s17-in-f13.1:https TIME_WAIT root 0 -
tcp 0 0 ordi1.local:51378 aur.archlinux.org:https TIME_WAIT root 0 -
tcp 0 69 ordi1.local:53769 ptr-178-50-168-17:53730 FIN_WAIT1 root 0 -
tcp 0 69 ordi1.local:54341 156.0.213.2:52873 FIN_WAIT1 root 0 -
tcp 0 255 ordi1.local:43565 156.0.212.28:14972 FIN_WAIT1 root 0 -
tcp 0 0 ordi1.local:40886 vmi443919.contabo:https TIME_WAIT root 0 -
tcp 0 0 ordi1.local:40818 vmi443919.contabo:https TIME_WAIT root 0 -
tcp 0 69 ordi1.local:58953 156.0.212.28:14972 FIN_WAIT1 root 0 -
tcp 0 606 ordi1.local:43123 m213-101-14-165.cu:5524 FIN_WAIT1 root 0 -
tcp 0 0 ordi1.local:56616 178.255.153.47:https ESTABLISHED root 3944351 -
tcp 0 69 ordi1.local:59151 156.0.212.20:27672 FIN_WAIT1 root 0 -
tcp 0 471 ordi1.local:49795 ptr-178-50-235-99:53722 FIN_WAIT1 root 0 -
tcp 0 69 ordi1.local:41469 156.0.212.28:14972 FIN_WAIT1 root 0 -
tcp 0 69 ordi1.local:46181 156.0.213.2:52873 FIN_WAIT1 root 0 -
tcp 0 69 ordi1.local:55945 223.27.246.180:24981 FIN_WAIT1 root 0 -
tcp 0 0 ordi1.local:59572 web.npulse.net:https TIME_WAIT root 0 -
tcp 0 119 ordi1.local:33759 223.27.246.180:24981 FIN_WAIT1 root 0 -
tcp 0 69 ordi1.local:37665 156.0.214.34:25842 FIN_WAIT1 root 0 -
tcp 0 0 ordi1.local:52402 46.235.231.150:https TIME_WAIT root 0 -
tcp 0 457 ordi1.local:41577 ptr-178-50-168-17:53730 FIN_WAIT1 root 0 -
tcp 0 69 ordi1.local:56173 156.0.214.34:25842 FIN_WAIT1 root 0 -
tcp 0 69 ordi1.local:36925 223.27.246.180:24981 FIN_WAIT1 root 0 -
tcp 0 536 ordi1.local:44509 156.0.213.2:52873 FIN_WAIT1 root 0 -
C’est l’autrichien ( 178.255.xx.xx) avec une connexion établie qui me titille un peu plus (là suis sur ma Manjaro)
Ma Debian est moins fréquentée mais pas moins titillante :
~$ sudo netstat -apet | grep root
tcp 0 0 localhost:ipp 0.0.0.0:* LISTEN root 20930 665/cupsd
tcp 0 0 192.168.1.54:47462 any-in-2615.1e100:https ESTABLISHED root 41988 735/nextdns
tcp 0 0 192.168.1.54:47938 194.110.115.97:https ESTABLISHED root 41587 735/nextdns
tcp 0 32 192.168.1.54:51388 ec2-34-216-198-14:https FIN_WAIT1 root 0 -
tcp 1 0 192.168.1.54:40666 192.168.1.25:ipp CLOSE_WAIT root 28166 726/cups-browsed
tcp 0 0 192.168.1.54:53494 ec2-44-236-152-85:https TIME_WAIT root 0 -
tcp6 0 0 [::]:domain [::]:* LISTEN root 22804 735/nextdns
tcp6 0 0 localhost:ipp [::]:* LISTEN root 20929 665/cupsd
tcp6 0 0 2a02:a03f:46a1:fe:60994 2a0d:5642:115:197:https ESTABLISHED root 44531 -
whois 156.0.214.34
Organization: African Network Information Center (AFRINIC)
City: Ebene
address: Avenue Jean Paul II Immeuble ETISALAT BENIN
Avenue JP2 les voies du seigneur sont impénétrables 
whois 46.235.231.150
descr: AMS colocated customers
country: NL
whois 178.255.153.47
role: ANEXIA RIPE NCC Role Handle
etc,etc
C’est vrai que c’est assez marrant de voir ce qui est ouvert sur un ordi
Sur ma session sans activité, tout va bien
root@debian:~# netstat -apet
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat Utilisatr Inode PID/Program name
tcp 0 0 0.0.0.0:sunrpc 0.0.0.0:* LISTEN root 10875 1/systemd
tcp 0 0 localhost:domain 0.0.0.0:* LISTEN root 21811 6230/dnsmasq
tcp 0 0 0.0.0.0:ipp 0.0.0.0:* LISTEN root 20989 6184/cupsd
tcp 0 0 localhost:smtp 0.0.0.0:* LISTEN root 21182 6636/exim4
tcp6 0 0 [::]:sunrpc [::]:* LISTEN root 10879 1/systemd
tcp6 0 0 [::]:ipp [::]:* LISTEN root 20990 6184/cupsd
root@debian:~#
Dès que je lance Firefox sur la page d’accueil je vois du google (whois 34.107.221.82) et de l’Amazon (whois 99.84.41.70) , c’est infernal 
Il y a de quoi s’amuser avec / sans extensions, sur un profil vierge…
Je lis que netstat est obsolète, alors il y a d’autres jouets :
sudo ss -r | grep -v '*'
et
sudo lsof -u root | grep -i listen
par exemple.
Mais ça ne dit pas forcément si c’est légitime
c’est souvent affirmé sur des blogs mais tant que l’outil est disponible dans Debian je m’en servirai, son compte-rendu est beaucoup plus lisible pour moi.
Mon dieu quand on utilise un navigateur web on observe des connexions vers d’autres machines !
Vite un pare-feu, un anti-virus, un anti-malouère, et pleins d’anti-trucs ! 
Probablement un truc que tu as installé (extension du navigateur ou autre) lié au DNS
⇒ *.nextdns.io
Sinon à voir autant de connexions vers des ports non privilégiés, cela suggère la présence d’une application fonctionnant en P2P (torrent ?).
La sortie de ss est certes parfois un peu moins lisible que celle de netstat mais elle peut donner d’autres informations utiles grâce aux très nombreuses options.
Arf ouiche ! c’est NextDNS (dont le but, comme dit plus haut est de me protéger des DNS menteurs et de quelques listes d’indésirables)
Il est d’ailleurs amusant de voir ce que ça fait :
-
les ordis
-
le téléphone
Ça permet de voir :
- que le DNSSEC dont on nous rebat parfois les oreilles est anecdotique
- que même sous des ordis purs Linux, M$ se présente partout sur le net
- que par contre la téléphonie Apple est très efficace à éradiquer M$
Question de politique de sécurité. Si tu as beaucoup de PC qui partagent des données alors tu met un serveur de fichier.
Le partage de fichier sur les poste de travail est toujours une porte ouverte et souvent la cause de bien des problèmes de sécurité (à minima).
Ensuite, quelques petites lignes de codes dans une page web suffisent à ouvrir un port d’écoute, un trojan en quelque sorte, sur linux comme sur windows. Sans parefeu, le pc est instantanément accessible. Quand en plus c’est sur un réseau ouvert c’est encore pire. Par ailleurs, sur un réseau autre que le sien, rien ne permet d’affirmer qu’on ne passe pas par un proxy/portail captif ou autre qui espionnes les requetes/données/etc… et qui pourra ainsi polluer les pages web pour y inserer du code de type trojan.
Dans ces cas, le parefeu n’empechera pas le trojan d’etre présent, mais le parefeu lui bloquera les accès sur le port ainsi ouvert.
la règle simple du Exterieur vers PC interdit, pc vers exterieur autorisé est la règle minimale.
Ensuite, pour les histoires de partage de fichier, n’existe-t-il pas une fonctionnalité qui ouvre les ports nécessaires quand on créée un partage (comme sous windows).
Enfin, les VPN ne sont pas forcement autorisés partout. Chez moi par exemple, ils sont interdit à moins d’être explicitement autorisés.
C’est surtout parce qu’il n’est pas implémenté. Les DNS sont parmi les services les plus mal protégés sur internet.
Donc tu ne pourrais pas accéder à un VPN privé genre une box Free ?
Et quid des proxys ?
mettre une extension dans firefox pour gérer ses dns?? burp
j’ai choisi un dns serieux, je le mets dans la conf reseau de mon pc, toujours la même logique: en itinérance je ne vaux pas être tributaire de l’hôte
nmcli | grep DNS -A1
DNS configuration:
servers: 127.0.0.1 64.6.64.6 80.67.188.188
Il faut distinguer les usages domestiques ou en TPE des usages professionnels. Le partage de fichiers depuis un poste de travail (NFS ou Samba) n’est pas un problème s’il est correctement configuré et limité au réseau local.
Si un pare-feu est nécessaire il doit se situer entre l’Internet et le réseau local (box de l’opérateur ou machine dédiée), pas sur les postes de travail !
Montre-nous le code.
Et s’il était si facile d’installer un cheval de Troie sur une machine, il serait alors tout aussi simple pour celui-ci de désactiver ou de contourner les règles du pare-feu.
Uhh, qui met une extensions dans FF pour gérer ses DNS ? (il y a bien un réglage DNS dans FF mais très insuffisant)
de mon pc se connecter à une box free chez qqn d’autre en vpn tu ne peux pas en effet; pour les proxy? utiliser un proxy externe, pareil si ce n’est pas explicitement paramétré. ceci dit j’ai le mien de proxy.
Pas besoin d’en connaitre le code, il suffit der savoir que ça existe. L’exemple des Tojan Miner est en lui même suffisamment explicite. Un lien, mais il y en a plein d’autre https://www.malekal.com/bitcoin-monetisation-de-botnet/
Et non, il est plus facile d’ouvrir un port que de contourner un pare-feu.
Ça c’est clair et c’est le minimum. Pour ce qui est des postes de travail, je reviens à ce que je disais, c’est une question de politique de sécurité donc de choix. J’applique chez moi la même chose que ce que j’appliquerais dans une entreprise et tous les PC ont un pare-feu.
sauf pour des personnes comme toi ou moi ça sera peut être le cas, 95% du temps ça ne l’est pas, et pas seulement en usage domestique malheureusement.
Ah et puisque tu y tiens, voici un bout de code python pour faire un listener (ce qu’est un trojan):
''' Simple socket server using threads
'''
import socket
import sys
HOST = '' # Symbolic name, meaning all available interfaces
PORT = 5500 # Arbitrary non-privileged port
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print 'Socket created'
#Bind socket to local host and port
try:
s.bind((HOST, PORT))
except socket.error as msg:
print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1]
sys.exit()
print 'Socket bind complete'
#Start listening on socket
s.listen(10)
print 'Socket now listening'
#now keep talking with the client
while 1:
#wait to accept a connection - blocking call
conn, addr = s.accept()
print 'Connected with ' + addr[0] + ':' + str(addr[1])
s.close()
Pour ton coté St Thomas, comme tu peux le voir, ça ne représente pas grand chose.
1 J'aime
Salut le monde ! 
C’est cool tout ça, mais on s’éloigne terriblement de la Q? de départ.
Les Gros Nulls comme moi qui suivent ce fil avec anxiété,
dans l’attende d’au moins un début de réponse pratique,
restent sur leur soif d’une solution à mettre en œuvre.
Grâce à la métaphore de la maison on a compris de quoi on parle.
Perso j’en suis (après avoir lorgné quelque foufounette velue qui traînait par-là – merci ;-)) à :
- nftables -> Installé
- Exemple de conf -> copié mais rien pigé (ça serait pas pire en binaire)
- service activé -> Bien
Mais là j’ai vraiment l’impression que ça tire court !
Donc à partir de là on fait quoi concrètement
pour utiliser nftables avec des outils de nouvelle génération
(comme on ne sait déjà pas utiliser iptable 
)
et si possible, faciles d’accès pour un bipède basic 
L’idéal serait une interface graphique intuitive ou au moins explicite pour commencer à définir des règles simples pour nftables
histoire de prendre sereinement la mesure du truc,
et de premières bonnes habitudes.
… Y-a ça dans nos dépôts ?
En fouinant un peu,
j’ai croisé fwbuilder,
c’est fait pour nftables ?.. ça vaut le coup d’être installé ?
Merci
enf ait en dehors du legacy, iptables n’est « détourné » vers nftables. Donc ne te poses pas la question, fait ton iptables sans te poser de questions. En tout cas pour le moment.
FWbuilder n’est plus maintenu depuis longtemps et donc n’integre plus les modifications qui ont pu avoir lieu et ce depuis de nombreuses années.
personnellement pour faire plus simple que iptables, j’utilise shorewall. c’est assez simple à utiliser (bien que la moindre erreur de syntaxe soit sanctionné par un non fonctionnement).
En gros, dans shorewall, comme d’aillerus dans un certain nombre de méthode liées à la sécurité tu travaille en utilisant des zones. dans une configuration simple d’un PC, il y a le PC lui-même, soit la zone fw puis il y a l’extérieur: net .
Mais tu pouait avoir sur une machine à plusieurs interfaces, net pou rinternet (l’exterieur), loc pour le local, le LAN, dmz pour la zone que tu attribue à la dmz, wifi pour le réseau wifi etc…
A chaque zone doit impérativement être attribué une interface (sauf pour fw evidement.
une fois le fichier zones, tu définies l’appartenance de tes interfaces à chacune d’entre elle dans le fichier interfaces
Ensuite tu défini les polituqe par defaut de tes zones. De base, les zones à risque (net et dmz) n’ont pas le droit d’acceder au parefeu (fw) ou au réseau local (loc, wifi, etc). cela se traduit dans un fichier policy. dans ce fichier tu aura en gros:
fw net ACCEPT # les accès à partir du firewall (donc du pc) sont acceptées
net fw DROP $LOG # les accès de l'exterieur vers le fw sont rejetté dans info (c'est à dire que les paquets sont purement et simplement ignorés)
loc net ACCEPT # le reseau local a accès au net (pour un fw qui sert de routeur/passerelle)
loc fw REJECT$LOG # les paquet sont rejetté avec indication (les paquet recoivent un message TCP comme quoi la connection est refusée)
net loc DROP $LOG (pas d'accès de l'internet ver le reseau local)
all all DROP $LOG # tous les autres cas non spécifiquement précisés sont rejettés. CETTE REGLE DOIT TOUJOURS ETRE LA DERNIERE
Ce ne sont que des exemples. Mais dans les packages de Shorewall il y a une documentation avec des exemple de machine à une, deux ou trois interfaces qui permettent de comprendre les principes.
enfin, il ne te suffit plus qu’à faire les regles specifiques dans le ficheirs rules pour permettre des accès qui ne sont pas prévus par la policy. Par exemple de pouvoir accéder au fw en provenance de net en SSH:
SSH(ACCEPT) net $FW
si le parefeu sert de serveur dhcp
ACCEPT loc $FW dhcp-client
ACCEPT $FW loc dhcp-server
Si tu prend l’exemple pour une configuration à une seule inteface, tu n’as quasiment rien à faire sauf:
- mettre la bonne interfaces dans le fichiers /etc/shorewall/interfaces
- mettre les éventuelles règles d’accès à ton PC pour le SSH par exemple dans le fichiers /etc/shorewall/rules
- si tu as un partages, ajouter la règles ou les règles nécessaires à l’utilisation du partage en fonction du procole de partage utilisé.
Dans tous les cas, chaque fois qu’une ligne sera indiqué avec des logs, tu les retrouveras (blocages ou autres) dans /var/log/syslog par defaut, ou dans un autre fichier si tu configure rsyslog ou ulogd.
Même s’il est pensable que les rejets d’accès peuvent faire un volume de logs important, il faut impérativement (toujours) tracer les paquets DROP et REJECT.
Voici les exemples pour une machine à une seule interface:
/etc/shorewall/zones:
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv4
/etc/shorewall/interfaces:
#ZONE INTERFACE
#
net enp0s3
/etc/shorewall/policy:
#SOURCE ZONE DESTINATION ZONE POLICY LOG LEVEL LIMIT:BURST
$FW net ACCEPT
net all DROP info
all all REJECT info