# Pare-feu dysfonctionnel **URL:** \ **Category:** Support Debian\ **Created:** [Février 13, 2020, 1:45 UTC](https://www.debian-fr.org/t/pare-feu-dysfonctionnel/81236 "2020-02-13T13:45:05Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![invar](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/6de8d8/32.png) [@invar](https://www.debian-fr.org/u/invar)\ **Post date:** [Février 13, 2020, 1:45 UTC](https://www.debian-fr.org/t/pare-feu-dysfonctionnel/81236/1 "2020-02-13T13:45:06Z")
Bonjour à tous, Je suis en testing. Depuis une mise à jour récente de iptables j’ai ce problème : lxdm se bloque (écran noir), je n’ai plus accès à internet … pour pallier cela, je suis obligé de taper la commande “_`ufw disable`_” si je tape “_`ufw enable`_” les problèmes resurgissent et j’ai ce message d’erreur : ```nohighlight ERROR: problem running ufw-init iptables-restore: COMMIT expected at line 21 iptables-restore: line 2 failed iptables-restore: COMMIT expected at line 19 iptables-restore: line 2 failed ip6tables-restore: COMMIT expected at line 21 ip6tables-restore: line 2 failed ip6tables-restore: COMMIT expected at line 19 ip6tables-restore: line 2 failed Problem running '/etc/ufw/user.rules' Problem running '/etc/ufw/user6.rules' ``` Je crois comprendre qu’il manque la commande `COMMIT` à certains lignes dans le fichier `user(6).rules` Supposition correcte ? **copie de mon fichier _`user.rules`_** (jai gommé tous les numéros de port) : ```nohighlight *filter :ufw-user-input - [0:0] :ufw-user-output - [0:0] :ufw-user-forward - [0:0] :ufw-before-logging-input - [0:0] :ufw-before-logging-output - [0:0] :ufw-before-logging-forward - [0:0] :ufw-user-logging-input - [0:0] :ufw-user-logging-output - [0:0] :ufw-user-logging-forward - [0:0] :ufw-after-logging-input - [0:0] :ufw-after-logging-output - [0:0] :ufw-after-logging-forward - [0:0] :ufw-logging-deny - [0:0] :ufw-logging-allow - [0:0] :ufw-user-limit - [0:0] :ufw-user-limit-accept - [0:0] ### RULES ### ### tuple ### allow udp [....] 0.0.0.0/0 any 0.0.0.0/0 in -A ufw-user-input -p udp -m multiport --dports [....] -j ACCEPT ### tuple ### allow tcp [....] 0.0.0.0/0 any 0.0.0.0/0 in -A ufw-user-input -p tcp -m multiport --dports [....] -j ACCEPT ### tuple ### allow udp [....] 0.0.0.0/0 any 0.0.0.0/0 in -A ufw-user-input -p udp -m multiport --dports [....] -j ACCEPT ### tuple ### allow udp [....] 0.0.0.0/0 any 0.0.0.0/0 out -A ufw-user-output -p udp -m multiport --dports [....] -j ACCEPT ### tuple ### allow tcp [....] 0.0.0.0/0 any 0.0.0.0/0 in -A ufw-user-input -p tcp -m multiport --dports [....] -j ACCEPT ### tuple ### allow tcp [....] 0.0.0.0/0 any 0.0.0.0/0 out -A ufw-user-output -p tcp -m multiport --dports [....] -j ACCEPT ### tuple ### allow tcp [....] 0.0.0.0/0 any 0.0.0.0/0 in -A ufw-user-input -p tcp --dport [....] -j ACCEPT ### END RULES ### ### LOGGING ### -A ufw-after-logging-input -j LOG --log-prefix "[UFW BLOCK] " -m limit --limit 3/min --limit-burst 10 -A ufw-after-logging-output -j LOG --log-prefix "[UFW ALLOW] " -m limit --limit 3/min --limit-burst 10 -A ufw-after-logging-forward -j LOG --log-prefix "[UFW BLOCK] " -m limit --limit 3/min --limit-burst 10 -A ufw-logging-deny -m conntrack --ctstate INVALID -j LOG --log-prefix "[UFW AUDIT INVALID] " -m limit --limit 3/min --limit-burst 10 -A ufw-logging-deny -j LOG --log-prefix "[UFW BLOCK] " -m limit --limit 3/min --limit-burst 10 -A ufw-logging-allow -j LOG --log-prefix "[UFW ALLOW] " -m limit --limit 3/min --limit-burst 10 -I ufw-before-logging-input -j LOG --log-prefix "[UFW AUDIT] " -m conntrack --ctstate NEW -m limit --limit 3/min --limit-burst 10 -I ufw-before-logging-output -j LOG --log-prefix "[UFW AUDIT] " -m conntrack --ctstate NEW -m limit --limit 3/min --limit-burst 10 -I ufw-before-logging-forward -j LOG --log-prefix "[UFW AUDIT] " -m conntrack --ctstate NEW -m limit --limit 3/min --limit-burst 10 ### END LOGGING ### ### RATE LIMITING ### -A ufw-user-limit -m limit --limit 3/minute -j LOG --log-prefix "[UFW LIMIT BLOCK] " -A ufw-user-limit -j REJECT -A ufw-user-limit-accept -j ACCEPT ### END RATE LIMITING ### COMMIT ``` J’en profite pour poser des **questions générales** : - quand on fait “`ufw disable`” c’est toutes les règles `iptables` qui sont désactivées ou seulement celles introduites via gufw ? - un pare-feu est-il utile alors qu’il y en a un actif dans le modem-router du FAI ? Merci d’avance aux spécialistes iptables de m’éclairer … cordialement à tous invar ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Février 13, 2020, 3:01 UTC](https://www.debian-fr.org/t/pare-feu-dysfonctionnel/81236/2 "2020-02-13T15:01:38Z")
Bug connu. Il ne faut pas oublier qu’il y a des inconvénients à utiliser testing. Cf. > **[Loading...](https://forums.debian.net/viewtopic.php?f=10&t=145228)** > **[\#949739 - iptables: ufw fails with iptables 1.8.4-2 - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949739)** > [@invar](#): > > quand on fait “`ufw disable`” c’est toutes les règles `iptables` qui sont désactivées ou seulement celles introduites via gufw ? La question est sans objet. Quand on utilise un gestionnaire de pare-feu comme `ufw`, on ne doit pas mélanger avec d’autres règles `iptables` > [@invar](#): > > un pare-feu est-il utile alors qu’il y en a un actif dans le modem-router du FAI ? Réponse de Normand : ça dépend de - ce que fait le pare-feu du routeur, - la confiance qu’on peut avoir dans un équipement qui est sous le contrôle d’un tiers (le FAI en principe, mais ce n’est pas comme si une box n’avait jamais été piratée), - ce qu’on attend d’un pare-feu. ---
**Author:** ![invar](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/6de8d8/32.png) [@invar](https://www.debian-fr.org/u/invar)\ **Post date:** [Février 14, 2020, 9:20 UTC](https://www.debian-fr.org/t/pare-feu-dysfonctionnel/81236/3 "2020-02-14T09:20:18Z")
Merci Pascal pour votre réponse, Je me penche sur les rapports de bug (c’est ardu …). Merci pour ces références. Ceci dit je reste sur ma faim concernant ma deuxième question : quand on désactive ufw, reste-t-il une protection de fond ? ou n’y a-t-il plus aucun pare-feu actif ? Certains textes laissent entendre que testing est passé en nftables ; comment le vérifier sur son propre système ? J’avoue que je maîtrise mal ce domaine. Merci encore cordialement invar ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Février 14, 2020, 2:04 UTC](https://www.debian-fr.org/t/pare-feu-dysfonctionnel/81236/4 "2020-02-14T14:04:01Z")
Je ne connais pas particulièrement Debian Bullseye, la testing du jour. Mais déjà avec Buster lorsque le paquet [iptables](https://packages.debian.org/buster/iptables) est installé, on peut voir dans la liste des fichiers du paquet que pour une commande donnée genre `iptables` , le système possède les commandes `iptables-nft` et `iptables-legacy` . Et en fait, via le système des [alternatives](https://wiki.debian.org/DebianAlternatives), la commande `iptables` est un lien vers `iptables-nft` . Tu peux le constater avec la commande `ls -l /etc/alternatives/iptables` . Ce que cela veut dire c’est que les règles configurées via iptables sont converties en règles pour nftables (via la librairie [libnftnl11](https://packages.debian.org/buster/libnftnl11)). Ton problème avec UFW vient du fait qu’il y a un léger bug dans la traduction entre le langage pour iptables parlé par UFW et nftables. Si tu souhaites absolument continuer à utiliser UFW, tu dois reconfigurer les alternatives pour que `iptables` pointe vers `iptables-legacy` au lieu de `iptables-nft` : [reddit - UFW and nftables](https://www.reddit.com/r/debian/comments/d5495x/can_i_still_use_ufw_to_manage_the_firewall_now/) Je ne fais ici que répéter les différentes informations exprimées dans les bug reports. – AnonymousCoward ---
**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\ **Post date:** [Février 14, 2020, 3:25 UTC](https://www.debian-fr.org/t/pare-feu-dysfonctionnel/81236/5 "2020-02-14T15:25:29Z")
Pour vérifier si nftables est en cours ```plaintext sudo 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 { 80, 443, 8200 } ct state new accept udp dport { 53, 67, 68 } ct state new accept counter packets 16618 bytes 7370061 drop } } ``` je me suis contenté des règles par défaut avec quelques ports en plus > **[Pare-feu: nftables](https://bidouilledebian.wordpress.com/2019/02/19/pare-feu-nftables/)** > > Comme nftables va devenir le pare-feu par défaut dans Debian, j’ai activé l’outil. Dorénavant je n’ai plus de iptable ```plaintext apt list --installed | grep iptable WARNING: apt does not have a stable CLI interface. Use with caution in scripts. apt list --installed | grep nftable WARNING: apt does not have a stable CLI interface. Use with caution in scripts. libnftables1/testing,unstable,now 0.9.3-2 amd64 [installé, automatique] nftables/testing,unstable,now 0.9.3-2 amd64 [installé] ``` NB Testing est très solide ```plaintext lsb_release --all No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux bullseye/sid Release: testing Codename: bullseye ``` je lui mets le dernier kernel venant de sid ```plaintext uname --all Linux debian 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux ``` ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Février 14, 2020, 5:00 UTC](https://www.debian-fr.org/t/pare-feu-dysfonctionnel/81236/6 "2020-02-14T17:00:34Z")
Pour avoir la commande nft , il faut impérativement installer le package [nftables](https://packages.debian.org/bullseye/nftables) . Sans ce package, Buster ou Bullseye fonctionnent bel et bien sous nftables mais c’est masqué. – AnonymousCoward ---
**Author:** ![invar](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/6de8d8/32.png) [@invar](https://www.debian-fr.org/u/invar)\ **Post date:** [Février 14, 2020, 7:08 UTC](https://www.debian-fr.org/t/pare-feu-dysfonctionnel/81236/7 "2020-02-14T19:08:55Z")
Merci [**AnonymousCoward**](https://www.debian-fr.org/u/AnonymousCoward) et [**grandtoubab**](https://www.debian-fr.org/u/grandtoubab), effectivement mon OS fonctionnne avec `nftables` : **`ls -l /etc/alternatives/iptables`** ```nohighlight lrwxrwxrwx 1 root root 22 nov 23 2018 /etc/alternatives/iptables -> /usr/sbin/iptables-nft ``` **`nft list ruleset`** ```nohighlight table ip filter { chain INPUT { type filter hook input priority filter; policy accept; } chain FORWARD { type filter hook forward priority filter; policy accept; } chain OUTPUT { type filter hook output priority filter; policy accept; ip daddr 127.0.0.1 counter packets 40 bytes 3417 accept ip daddr 192.168.0.0/16 counter packets 11940 bytes 19733761 accept ip daddr 10.0.0.0/8 counter packets 0 bytes 0 accept ip daddr 172.16.0.0/12 counter packets 0 bytes 0 accept } } ``` Donc ça fonctionne bien sans `ufw` cependant il me faudra être vigilant : si j’ai utilisé `ufw` c’est qu’il y en avait la nécessité. Il me faudra la comprendre et j’espère qu’alors `ufw` sera utilisable avec `nftables` … du boulot en vue ! merci encore invar