/etc/network/if-up.d/ sous wheezy

Support Debian
#1

Bonjour,

Je croyais que les scripts présents dans le répertoire /etc/network/if-up.d/ s’exécutaient automatiquement.
Mais celà ne semble pas le cas.

J’ai testé /etc/network/if-post-up.d/ sans plus de succès.

Au final, j’ai utilisé post-up dans le fichier interfaces et ca marche.

Quelqu’un a une idée de ce qui cloche ?

#2

Je doute que tu aies un dossier if-post-up.d… :wink:

$ ll /etc/network/ total 20K drwxr-xr-x 2 root root 4,0K 2012-11-16 13:17 if-down.d drwxr-xr-x 2 root root 4,0K 2012-10-24 01:47 if-post-down.d drwxr-xr-x 2 root root 4,0K 2012-10-24 01:47 if-pre-up.d drwxr-xr-x 2 root root 4,0K 2012-11-27 22:42 if-up.d -rw-r--r-- 1 root root 283 2012-10-23 16:59 interfaces lrwxrwxrwx 1 root root 12 2012-05-19 14:13 run -> /run/network

Sûrement quelque chose que tu as mal fait, mais tu nous en dis tellement long sur ce que tu as réellement fait que ma boule de cristal en reste muette.

#3

Il manque peut-être une des conditions requises par run-parts (cf. man) : droit d’exécution, nommage, shebang…

#4

@syam : Comme le script dans if-up.d ne marchait pas, j’ai essayé en créant if-post-up.d et j’y ai mis mon script pour voir.

Autrement mes 2 scripts fonctionnent en les appelant spécifiquement dans le fichier interfaces :

iface eth0 inet4 static
...
   post-up /etc/network/if-post-up.d/firewall4 
...

iface eth0 inet6 static
...
   post-up /etc/network/if-post-up.d/firewall6 
...

La piste du run-parts me semble bonne, mais je n’ai pas trouvé l’appel pour le moment. Je continue mes recherche pour trouver ou sont appelés ces #?£@ de scripts dans Debian (revu par OVH ?).

#5

Comme l’a dit Pascal, donne nous :

  • le nom exact du script que tu as essayé de mettre en place ainsi que ses droits (ls -lA)
  • son contenu

Pour info :

  • if-pre-up.d = avant le démarrage d’une interface
  • if-up.d = après le démarrage d’une interface (ce que tu crois être if-post-up.d)
  • if-down.d = avant l’arrêt d’une interface
  • if-post-down.d = après l’arrêt d’une interface
#6

Les noms, on les a : firewall4 et firewall6 (ok pour run-parts, pas de caractère interdit).
Les droits doivent être bons puisque les scripts s’exécutent avec post-up, mais à confirmer quand même.
Reste à vérifier que la première ligne des fichiers contient #!/bin/sh ou autre interpréteur selon le type de script.

Note : l’option post-up est équivalente à l’option up (et pre-down à down), c’est la raison pour laquelle les répertoires if-post-up.d et if-pre-down.d n’existent pas.

#7

Juste un commentaire : j’ai honte… mais bon, si j’étais meilleur je ne posterai pas.

Par contre, le script se lance 4 fois : lo/eth0 x inet4/inet6. Je vais creuser de ce coté, mais je suis preneur de conseils. Je m’oriente vers la solution intégration dans interfaces en stockant les scripts ailleurs.

#8

A ta décharge, cette contrainte sur le shebang n’est pas documentée dans la page de manuel de run-parts. Je ne sais même plus comment je l’ai connue…

Normal. Regarde dans la page de manuel d’interfaces, des variables d’environnement sont passées en fonction des conditions d’appel du script, notamment :

IFACE physical name of the interface being processed LOGICAL logical name of the interface being processed ADDRFAM address family of the interface METHOD method of the interface (e.g., static) MODE start if run from ifup, stop if run from ifdown PHASE as per MODE, but with finer granularity, distinguishing the pre-up, post-up, pre-down and post-down phases.

#9

Quel est le bonne endroit pour insérer le lancement d’un firewall ?

Mes 2 scripts font un bête iptables-restore/ip6tables-restore.

A priori, je dirai avant le lancement du réseau. Comme je n’ai qu’une interface, avant le lancement de eth0.

#10

Bonne question. Ma règle de base est qu’il ne devrait pas y avoir d’intervalle de temps entre l’activation d’une interface et l’activation du pare-feu pendant lequel du trafic non désiré pourrait passer. En pratique, comme toujours, la réponse est : ça dépend. De quoi ? Du jeu de règles, des interfaces à protéger, si elles sont statiques, dynamiques (leur nom aussi bien que leur configuration IP)…

Le cas le plus simple et classique, c’est un jeu de règles fixes mis en place avant l’activation des interfaces réseau. C’est approprié si toutes les informations nécessaires sont connues à l’avance, notamment si on applique les mêmes règles à toutes les interfaces extérieures (l’interface de loopback étant un cas particulier) indépendamment de leur type, nom ou configuration IP. Comme il n’y pas de règles créées spécifiquement pour une interface donnée, on n’a pas besoin de script lancé par ifupdown qui connaîtrait le nom de l’interface, pourrait récupérer son adresse IP…

Sur mon routeur, le jeu de règles est divisé en plusieurs parties :

  • un ensemble de règles fixes, communes à toutes les interfaces ou concernant les interfaces pour lesquelles tout est connu à l’avance, mises en place avant l’activation du réseau ; c’est notamment là que sont définies le politiques par défaut des chaînes (DROP pour la table filter évidemment) ;
  • des ensembles de règles spécifiques à chaque interface créées lors de leur activation et effacées lors de leur désactivation ; c’est notamment nécessaire car le nom et la configuration IP de certaines interfaces dynamiques (PPP) n’est pas connu à l’avance. A noter que toutes les interfaces ne sont pas gérées par ifupdown (interfaces PPP ou VPN, interfaces gérées par network manager…), donc la façon dont les règles relatives à une interface sont créées ou supprimées peut varier. Que les règles soient créées juste avant ou juste après l’activation d’une interface n’a pas d’importance puisque par défaut le trafic est bloqué.

Entre les deux, on peut imaginer toutes les variations possibles. En revanche, ré-exécuter le même script qui recrée les mêmes règles à l’activation de chaque interface n’a aucun sens.

#11

J’ai choisi de lié mes règles à pre-up de eth0 dans le fichier interfaces en séparant le script pour IPv4 et IPv6.

Je n’ai qu’une seule interface : eth0 (hors lo) et je n’ai pas de règle spécifique à une adresse (hors 127.0.0.1 et ::1).

#12

Quelles règles spécifiques à 127.0.0.1 et ::1 as-tu ? Je demande parce que dans la plupart des cas, je n’en vois pas l’utilité.

#13

Comme j’interdis tout, j’autorise ce qui concerne lo.

# Vider les tables actuelles
iptables -t filter -F
# Vider les règles personnelles
iptables -t filter -X
# Interdire toute connexion entrante et sortante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
# Ne pas casser les connexions etablies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Autoriser loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
# ICMP (Ping)
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
# --- Logiciels à autoriser
# SSH Out
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT
...

C’est le script d’initialisation des règles, pour automatiser j’utilise iptable-save/iptable-restore lorsque les règles me semble bonne.

En fait j’autorise les flux sortant suivant mes besoins lorsque je coince (app-get qui lit les sources en ipV6 par exemple). Et pour les flux entrant lorsque j’installe un serveur que je souhaite accessible de l’extérieur.

Le port smtp par exemple est ouvert en sortie, mais pas en entrée pour pouvoir envoyer des mails, mais pas en recevoir ou servir de relais.

Pour ssh, serveur utilisé ponctuellement, j’utilise knockd pour ouvrir/fermer le port entrant pendant 10 secondes. Juste le temps de me connecté. Mais je pense changer pour l’ouvrir pour mon adresse perso pour pouvoir faire des transferts de fichier plus facilement.

#14

Mais aucune règle spécifique à 127.0.0.1 et ::1, contrairement à ce que tu avais écrit.