Pare-feu dysfonctionnel

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 :

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

*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

Bug connu. Il ne faut pas oublier qu’il y a des inconvénients à utiliser testing. Cf.
http://forums.debian.net/viewtopic.php?f=10&t=145228
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949739

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

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.

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

Je ne connais pas particulièrement Debian Bullseye, la testing du jour.

Mais déjà avec Buster lorsque le paquet 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, 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).

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

Je ne fais ici que répéter les différentes informations exprimées dans les bug reports.


AnonymousCoward

Pour vérifier si nftables est en cours

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

Dorénavant je n’ai plus de iptable

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

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

uname --all
Linux debian 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux

Pour avoir la commande nft , il faut impérativement installer le package nftables .

Sans ce package, Buster ou Bullseye fonctionnent bel et bien sous nftables mais c’est masqué.


AnonymousCoward

Merci AnonymousCoward et grandtoubab,
effectivement mon OS fonctionnne avec nftables :

ls -l /etc/alternatives/iptables

lrwxrwxrwx 1 root root 22 nov 23  2018 /etc/alternatives/iptables -> /usr/sbin/iptables-nft

nft list ruleset

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