Firewall ( Poste Bureautique)

Support Debian
#41

Bonjour,
Je me permets de mettre en avant un autre logiciel :
FirewallD
qui semble assez similaire, facile d’utilisation, avec une interface graphique assez claire
Bien documenté

Invar

#42

je ne comprends toujours pas pourquoi vous ne passez pas à nft

systemctl status nftables.service
● nftables.service - nftables
     Loaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor preset: enabled)
     Active: active (exited) since Mon 2020-12-28 08:18:04 CET; 3h 22min ago
       Docs: man:nft(8)
             http://wiki.nftables.org
   Main PID: 223 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 4298)
     Memory: 0B
     CGroup: /system.slice/nftables.service

déc. 28 08:18:04 debian systemd[1]: Finished nftables.

 nft list ruleset
table inet filter {
	chain input {
		type filter hook input priority filter; policy accept;
		iif "lo" accept
		ct state established,related accept
		tcp dport { 25, 80, 143, 443, 465, 587, 993, 8200 } ct state new accept
		udp dport { 53, 67, 68 } ct state new accept
		counter packets 190 bytes 5470 drop
	}
}

C’est le firewall par defaut de Debian depuis buster

#43

Moi aussi :slight_smile:

En tant que débutant en Firewall,
je ne veux pas apprendre des choses qui seront caduques d’ici peu,
je regarde en avant.

Maintenant il faut admettre qu’on est encore en phase de transition,
et que c’est un peu la pagaille au niveau des doc/tuto/logiciels qui n’ont pas encore évolués ou sont en cours de mutation.

Donc pour ceux qui arrivent maintenant,
le sujet déjà pas trop sympa,
devient une vraie prise de tête :frowning:

#44

La sortie de cette commande bien que courte,
sans mauvaise volonté,
elle est pour moi totalement « imbitable » :blush:

#45

no pain, no gain :laughing:
c’est l’état des règles
Globalement on accepte le dialogue sur ce dont on est à l’initiative sur l’interface local, en précisant les ports ouverts
on affiche un bilan des compteurs dont les paquets écartés (drop)
il y a plein de description de nft
je ne répète pas ce qui est ici

#46

Oui, c’est ce que disent les body-builders :wink:

La lecture du manuel de nft va bien au-delà de ça,
c’est pour les fakirs qui pratiquent la lévitation au quotidien !

… On est pas sorti d’affaire :broken_heart:

#47

sachant qu’actuellement ipables renvoie en fait vers nftables sauf tu as configuré ta debian pour utiliser iptables legacy (ce qu n’est pas la configuration par defaut).

#48

Parce qu’il faut un temps d’adaptation quand on est habitué à iptables/ebtables/arptables.
Parce que toutes les fonctionnalités de ces derniers ne sont pas encore disponibles dans nftables.

Alors pourquoi le paquet nftables n’est pas installé par défaut alors que iptables l’est ?

C’est une question d’habitude. Les règles iptables équivalentes ne seraient probablement pas plus faciles à comprendre.

Soit tu expliques très mal, soit tu n’as pas compris ces règles.

  1. Ce jeu de règles ne concerne que les paquets entrants. Il n’y a aucun filtrage des paquets sortants.
  2. La politique par défaut est d’accepter les paquets entrants.
  3. Les paquets reçus (et donc émis) par l’interface de loopback sont acceptés.
  4. Les paquets reçus appartenant ou liés à des connexions existantes sont acceptés.
  5. Les paquets TCP reçus à destination des ports 25, 80, 443… créant une nouvelle connexion sont acceptés.
  6. Les paquets UDP reçus à destination des ports 53, 67 et 68 créant une nouvelle connexion sont acceptés.
  7. Les autres paquets reçus sont comptés et bloqués.

Vu tous les ports autorisés en entrée, ce jeu de règles n’est pas adapté à un poste bureautique mais plutôt à un serveur SMTP+HTTP+POP3+IMAP+DNS+DHCP et que sais-je encore…

#49
#50

Et donc, où veux-tu en venir avec cette citation trop longue ?

#51

Pour nftables, il faut savoir que la doc n’est pas terrible et rend le passage de iptables vers nftables assez difficile.
je dirais même que c’est monstrueux, geek-only-doc.

1 J'aime
#52

Je n’ai pas encore eu le temps de m’y mettre sérieusement,
mais je crois tenir un tuto qui tient la route :

Ça devrait permettre aux utilisateurs intermédiaires de s’en sortir.

#53

Conscient de me contredire et au risque de me faire huer …

Je me rends compte, après coup,
que iptables reste une solution tout-à-fait viable,
et qu’il n’y a finalement pas d’urgence à utiliser nftables.

Donc pour celles et ceux qui ne sont pas armés pour batailler avec les Tables dans un terminal,
les solutions déjà mentionnées Shorewall, FirewallD ainsi que GUFW ,
devraient fournir des possibilités d’accéder au pare-feu "sans trop de complications"
même si simplement savoir ce qu’on doit ou pas autoriser, n’est déjà pas trop évident en soit.

… en attendant de nouveaux outils pour faciliter l’usage de nftables :wink:

Personnellement, je pense tenter d’abord le coup au plus facile avec GUFW.
Puis en marge, je testerai nft suivant le wiki d’Arch… pour ne pas mourir idiot :innocent:

#54

Les dernières versions de firewalld ont migré vers nftables. ufw peut aussi utiliser nftables. Il y a fort à parier que les autres gestionnaires de pare-feu vont suivre. De toute façon, si on utilise ces surchouches, c’est qu’on ne veut pas s’embêter avec iptables ou nftables, donc ça devrait être transparent.

2 J'aime
#55

Merci pour cette bonne nouvelle !

#56

j’ai fait une propreté , plus pour un Pc familial

cat /etc/nftables.conf

#!/usr/sbin/nft -f
# 
flush ruleset

table inet ma_table {
	chain trafic_entrant {
		type filter hook input priority 0; policy drop;
# par defaut le trafic entrant est rejeté		
		iif lo accept comment "Accepter le trafic local"
#	
#		
		ct state invalid drop comment "Rejeter les connexions invalides"
#	
		ct state established,related accept comment "Accepter le trafic dont nous sommes à l'origine"
#
		counter drop comment "Compter et rejeter tout le reste"
	}

	chain trafic_transfert {
		type filter hook forward priority 0; policy drop; 
		# Pas de transfert, on est pas un routeur 
	}

	chain trafic_sortant {
		type filter hook output priority 0; policy accept; 
		# Accepter tout ce qui sort
	}

}

Ce qui donne

root@debian:~# nft list ruleset
table inet ma_table {
	chain trafic_entrant {
		type filter hook input priority filter; policy drop;
		iif "lo" accept comment "Accepter le trafic local"
		ct state invalid drop comment "Rejeter les connexions invalides"
		ct state established,related accept comment "Accepter le trafic dont nous sommes à l'origine"
		counter packets 308 bytes 15290 drop comment "Compter et rejeter tout le reste"
	}

	chain trafic_transfert {
		type filter hook forward priority filter; policy drop;
	}

	chain trafic_sortant {
		type filter hook output priority filter; policy accept;
	}
}
root@debian:~#
#57

(message effacé)

#58

Je viens de trouver cette vidéo sur les pare feux Linux :

Pare feux Linux

https://www.youtube.com/watch?v=nZrPOsqXF8U

C’est très clair et facile a comprendre.

#59

Comment?

#60

Vérification faite, j’ai mal interprété une phrase du changelog d’ufw. Désolé.