Bonjour,
Je loue un serveur physique chez un herbergeur, il est sous Debian Wheezy.
J’ai mis en place quelques règles iptables, pour bloquer tous les accès non souhaités.
Pour les opérations de mises à jour et installation de paquets. Que conseiller vous ?
1 - Arrêter le pare-feu le temps des opérations.
2 - Avoir une règle permanente ouverte sur les ports utilisés par les installations/mises à jour.
3 - Modifier les règles juste le temps des opérations.
Merci.
Je vais peut-être dire une bêtise, à cette heure-ci du soir, mais les màj systèmes se font et passent par les ports 80, voire 443, certes ils peuvent se faire par ftp, ssh, voire connexion tor … quoiqu’il en soit, fais le nécessaire pour que quand tu exécutes les commandes nécessaires, selon ta configuration de sources.list, tu puisses accèder au service correspondant.
À un détail près, tu auras aussi besoin d’accéder au service hkp (11371 en TCP), utilisé par la commande ‘apt-key’ pour pouvoir interroger les serveurs de clés, actions parfois nécessaires, sachant qu’il est possible de rediriger ses interrogations sur le port 80, voire 443
Bref, pas besoin d’arrêter le pare-feu, de modifier les règles de celui-ci juste pour cela 
Sachant que tu ne te mouilles pas trop dans le cas présent, puisque c’est toi qui contactes un serveur de mises à jour. Tu auras donc juste à accepter les paquets sortants (OUTPUT) et la connexion active qui en résulte.
Merci à vous 2.
Il me semblait avoir lu qu’on pouvait faire exécuter des scripts arbitraires à APT avant et après d’effecturer ses actions, mais je ne retrouve plus l’information. Cela permettrait d’ajouter les règles iptables nécessaires au téléchargement des mises à jour puis de les supprimer ensuite.
Non, justement, j’ai vu ces options Dpkg::Pre-Invoke et Dpkg:Post-Invoke lors de ma recherche mais elles ne sont appliquées qu’avant et après l’invocation de dpkg par APT (au passage dpkg a ses propres options pre-invoke et post-invoke indépendamment d’APT). Ces options peuvent être utiles par exemple pour temporairement remonter en lecture-écriture les systèmes de fichiers comme /usr ou /boot qui peuvent être habituellement montés en lecture seule pour sécuriser le système.
Ici, il faudrait des options exécutées lors des accès aux miroirs par exemple lors d’un apt-get update, upgrade ou install, qui n’ont rien à voir avec l’invocation de dpkg.
Exact, ça permet un déclenchement post-mise à jour, mais ça ne se déclenchera pas avant l’accès aux serveurs de mise à jour 
.
Exact @PascalHambourg. C’est ce dont je me sers pour redonner les droits en écriture des partitions nécessaires à ce moment-là, et pour les enlever après. J’y applique aussi un script qui utilise l’outil chattr pour rendre immuable ou non certains répertoires/partitions.
Je n’aurais pas pensé à utiliser cette fonctionnalité pour interférer avec iptables.
Néanmoins, considérant les cas habituels, que sont l’usage des outils apt sur le port 80, voire 443 … qui sont généralement ouvert en sortie. Quel degré de pertinence cela aurait lieu d’agir ainsi ?!
@seb-ksl: en fait, cela ne se déclenche pas lors de l’usage de l’option ‘update’, mais bien sur les autres options.
Ce qui en soit est normal, parce que durant l’update, on ne fait que mettre-à-jour les infos alors que pour les autres options, on touche au FS.
Pas pour un serveur qui n’est pas censé faire des accès web.
C’est là, où je diverge d’avec toi …
Rien qu’une chose pour exemple, les mises-à-jours système : il te faut bien un accès à internet.
À minima, un accès sur les ports 80/TCP, et domain.
Non ?!
Oui, mais uniquement lors des mises à jour, pas en permanence.
D’où l’intérêt qu’il y aurait à exécuter des commandes avant et après les téléchargements d’APT.
Idéalement il faudrait aussi restreindre ces accès aux miroir Debian utilisés, mais ils peuvent changer d’adresse IP donc cela ne se prête pas bien à des règles iptables permanentes qui ne comprennent que les adresses IP (les noms de domaine sont convertis en adresses lors de la création des règles et non lors de leur application aux paquets).
Ahhh, là, on est d’accord 
Merci !
C’est tout le défaut d’Iptables !
Je ne sais pas ce qu’il en est de Netfilter au-travers de son nouveau projet - dont je ne sais plus le nom, ce soir.
PF, d’OpenBSD, lui en est très capable …
Ce n’est pas parfait, parfait, mais il s’en sort.
Si c’était le seul défaut d’iptables…
Je ne sais pas non plus ce qu’il en est de nftables auquel je ne me suis pas encore intéressé, si c’est ce dont tu parles.
A ma connaissance le noyau Linux ne fait pas de DNS, donc toujours pas possible à moins de passer en espace utilisateur.
Merci, oui c’est bien à lui que je pensais.
Pour ceux que cela pourrait intéresser, suite à la lecture de notre topic :
pas forcément si tu passes par un serveur de mise à jour ou apt-cacher pour éviter de charger ta bande passante et interdire les serveurs à se connecter à internet