Documenting the features used by le Cr@ns
ds-ac
parent
44f4a8fb34
commit
c098cb63c9
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
`NFTables` est un outil permettant de de gérer une partie de la gestion des
|
||||
paquets réseaux dans une machine Linux. Cet outil supplante ses prédécesseurs
|
||||
xtables (iptables, ip6tables, arptables, ...) et son support ets inclus dans les
|
||||
xtables (iptables, ip6tables, arptables, ...) et son support est inclus dans les
|
||||
noyaux Linux modernes. Lorsqu'un paquet traverse, sort de ou entre sur votre
|
||||
machine, il parcourt un certain chemin de prises de décisions afin de décider de
|
||||
son sort (jeté, accepté (= intouché), modifié, ...).
|
||||
|
|
@ -125,7 +125,7 @@ configuration suivant :
|
|||
|
||||
```
|
||||
table <type> <nom de la table> {
|
||||
[contenu de la table (chaînes)]
|
||||
[contenu de la table (chaînes)]
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -160,8 +160,8 @@ configuration textuelle suivant :
|
|||
|
||||
```
|
||||
chain <nom de la chaîne> {
|
||||
type <type> hook <crochet> priority <priorité> ; policy <verdict par défaut>;
|
||||
[contenu de la chaîne]
|
||||
type <type> hook <crochet> priority <priorité> ; policy <verdict par défaut>;
|
||||
[contenu de la chaîne]
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -180,17 +180,175 @@ Dans la définition d'une règle, il est possible d'indiquer :
|
|||
udp` (type : `ip protocol` représentant le champ du protocole de couche 4 dans
|
||||
un paquet IPv4, valeur `tcp`).
|
||||
|
||||
Remarque: Il est possible de nier une condition.
|
||||
Remarque': Il est possible d'utiliser des ensembles dans les conditions (voir
|
||||
plus bas).
|
||||
|
||||
Les types peuvent être décrits par `nft describe <type>`.
|
||||
|
||||
* des actions, parmi lesquelles "compter les paquets" (`counter`), logger les
|
||||
paquets (`log prefix ...`).
|
||||
|
||||
|
||||
|
||||
Pour ajouter une règle, il est possible d'utiliser `nft add rule <type de la
|
||||
table> <nom de la table> <nom de la chaîne> '<règle>'`, ou d'ajouter la règle
|
||||
sur une ligne dans la configuration textuelle.
|
||||
|
||||
|
||||
## Ensembles et applications
|
||||
|
||||
### Ensembles
|
||||
|
||||
Il est courant d'utiliser des ensembles lors de la définition d'un pare-feu, non
|
||||
seulement parce qu'ils permettent de réduire le nombre de règles à écrire, mais
|
||||
aussi parce qu'ils sont plus efficaces, NFTables pouvant gérer les tests
|
||||
sous-jacents luiel(de crapaud)-même.
|
||||
|
||||
Un ensemble peut être :
|
||||
|
||||
* anonyme (eg: `{ A, B, C}`). Dans ce cas, l'ensemble est statique.
|
||||
|
||||
* nommé. Dans ce cas, l'ensemble peut être dynamique et avoir diverses options
|
||||
et paramètres associés (eg: permettre de stocker des intervalles, associer
|
||||
une durée de vie aux éléments (avec éventuellement un délai par défaut),
|
||||
compter des paquets, une taille).
|
||||
|
||||
L'appartenance à un ensemble `E` est un critère valide noté `{...} @E` (sa
|
||||
négation est notée `{...} != @E`).
|
||||
L'ajout ou retrait d'un élément à un ensemble `E` est une action valide (si
|
||||
l'ensemble n'est pas constant) et se note `(add|delete) @E {...}`.
|
||||
|
||||
Dans un fichier de configuration, un ensemble est déclaré (dans une table)
|
||||
par :
|
||||
```
|
||||
set <nom de l'ensemble> {
|
||||
type <type d'éléments>;
|
||||
}
|
||||
```
|
||||
Le type des éléments peut être donné explicitement ou à l'aide de `typeof
|
||||
...`, ou `...` est un critère valide (eg: `typeof tcp dport` est équivalent à
|
||||
`type inet_service`).
|
||||
Il est également possible de réaliser des produits cartésiens de types. Par
|
||||
exemple, le type `ipv4_addr . inet_service` est le type des pairs d'adresse
|
||||
IPv4 et des ports.
|
||||
|
||||
Il y a de nombreuses options utiles lors de la déclaration d'un ensemble :
|
||||
|
||||
- Le nombre d'éléments max (`size <nombre>`). La valeur par défaut est 65536.
|
||||
|
||||
- Les drapeaux (`flags ...`), dont `timeout` ou `intervals`
|
||||
|
||||
- Les éléments initiaux (`elements = { e0, ..., en }`)
|
||||
|
||||
|
||||
|
||||
|
||||
### Applications
|
||||
|
||||
TODO: `nft (add|...) map ...`
|
||||
|
||||
|
||||
## Interaction avec le pare-feu
|
||||
|
||||
Il est souvent pratique d'ajuster les règles d'un pare-feu (ajout d'un service,
|
||||
de règles, réordonnancement des règles, ...). Un moyen naïf pour faire cela est
|
||||
de réinitialiser le pare-feu et de charger un nouveau fichier de configuration.
|
||||
L'inconvénient est que cela :
|
||||
|
||||
* vide les ensembles et applications remplis dynamiquement
|
||||
|
||||
* permet à des intrus d'établir des connections illicites si elles sont
|
||||
initialisées durant la remise à zéro (moins important car la recharge d'un
|
||||
fichier de configuration est rapide).
|
||||
|
||||
### La commande `nft`
|
||||
|
||||
La commande `nft` permet certes d'ajouter des tables, des chaînes et des règles
|
||||
dynamiquement, comme expliqué ci-dessus. Mais elle permet également de corriger
|
||||
des erreurs, ce qui peut être pratique par moments.
|
||||
|
||||
* Suppression ou remplacement d'une règle par une autre :
|
||||
|
||||
- Pour la suppression : `nft delete rule <type de la table> <nom de la
|
||||
table> <nom de la chaîne> handle <numéro e la poignée (du handler en
|
||||
anglais)>`
|
||||
|
||||
- Pour le remplacement : `nft replace rule <type de la table> <nom de la
|
||||
table> <nom de la chaîne> handle <numéro de la poignée (du handler en
|
||||
anglais)> <new_rule>`.
|
||||
|
||||
__Cas d'usage :__
|
||||
|
||||
- si vous utilisez un ensemble anonyme pour gérer quels ports
|
||||
sont ouverts aux nouvelles connections TCP, vou spouvez le mettre à jour
|
||||
facilement.
|
||||
|
||||
- si vous voulez qu'une règle filtrant les accès TCP permette aussi l'UDP,
|
||||
vous pouvez par exemple souhaiter remplacer `tcp dport` par `meta l4proto
|
||||
{ tcp, udp} td dport`
|
||||
|
||||
* Ajout d'une règle à un endroit précis dans le pare-feu :
|
||||
Cela peut être fait avec les règles
|
||||
`nft <add|insert> rule <type table> <nom table> <nom chaîne> handle <numéro>
|
||||
<règle>`.
|
||||
|
||||
`add` permet d'insérer la règle après la poignée spécifiée. Si aucune poignée
|
||||
n'est spécifiée, la règle est ajoutée à la fin de la chaîne.
|
||||
|
||||
`insert` permet d'insérer la règle avant la poignée spécifiée. Si aucune
|
||||
poignée n'est spécifiée, la règle est ajoutée au début de la chaîne.
|
||||
|
||||
* Options pratiques (`nft -option_pratique ...`) :
|
||||
|
||||
- `-t` permet de ne pas afficher le contenu des ensembles et applications
|
||||
dans la sortie de la commande qui suit
|
||||
|
||||
- `-a` permet d'afficher les numéros de poignée
|
||||
|
||||
- `-n` permet d'afficher les noms des services plutôt que les ports
|
||||
(déconseillé car la fonction des ports dans les noms de service n'est pas
|
||||
injective)
|
||||
|
||||
|
||||
|
||||
## Journalisation et surveillance
|
||||
|
||||
### Journalisation
|
||||
|
||||
Il peut être intéressant d'écrire des entrées dans le journal d'un routeur. Il
|
||||
est d'usage au Cr@ns de noter toutes les nouvelles connections.
|
||||
|
||||
Cela peut être fait grâce à l'action `log prefix "..."`, ou `"..."` est le
|
||||
préfixe à utiliser dans le journal du système.
|
||||
|
||||
|
||||
|
||||
### Surveillance
|
||||
|
||||
Il est possible de demander à NFTables d'afficher des messages de débogage,
|
||||
liés entre autre aux changements, retraits ou ajouts de règles, de tables, ... à
|
||||
l'aide de la commande `nft monitor`
|
||||
|
||||
* __Changements__ :
|
||||
|
||||
- Changements précis : `nft monotor ...
|
||||
<rules|chains|ruleset|tables|sets|elements>`, où `...` peut être rien,
|
||||
`destroy` ou `add` selon si l'on veut tout entendre, n'entendre que les
|
||||
retraits ou les ajouts.
|
||||
|
||||
- Changements quelconques : `nft monotor` pour tout entendre (y compris les
|
||||
parcours des paquets marqués décrits ci-dessous).
|
||||
|
||||
* __Débogage__ :
|
||||
À des fins de débogage, il est parfois pratique de savoir par quelles règles
|
||||
un paquet donné est passé et quelle verdict il a subit. À cette fin, NFTables
|
||||
permet de marquer le paquet à l'aide de l'action `meta nftrace set 1`.
|
||||
|
||||
Les événements internes de NFTables concernant ce paquet peuvent ensuite être
|
||||
affichés avec la commande `nft monitor trace`.
|
||||
|
||||
|
||||
## Divers
|
||||
|
||||
* `nft flush ruleset` vide la table
|
||||
|
|
@ -200,7 +358,13 @@ sur une ligne dans la configuration textuelle.
|
|||
* `systemctl reload nftables` a le même effet que `nft -f /etc/nftables.conf` si
|
||||
le service existe.
|
||||
|
||||
* La famille d'une table peut être omise dans age de la commande `nft` s'il n'y
|
||||
a pas d'ambigüité.
|
||||
|
||||
* Si aucune chaîne / table / règle n'est traversée, le paquet est accepté par
|
||||
défaut (si on ne filtre pas, tout passe)?
|
||||
défaut (si on ne filtre pas, tout passe)
|
||||
|
||||
* Il est possible d'utiliser des variables dans un fichier de configuration.
|
||||
Leur valeur sera substituée lors de la lecture du fichier. Un exemple est
|
||||
donné dans le fichier `services/firewall.md`.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue