(/ etc / sysconfig / iptables) "La personnalisation manuelle de ce fichier n'est pas recommandée." Pourquoi?

Modification directe de ce fichier

/etc/sysconfig/iptables 

peut me faire économiser tant de maux de tête tant de temps et ainsi de suite ...

et pourtant, tout en haut du fichier, il est dit ..

Manual customization of this file is not recommended.

voici le '/ etc / sysconfig / iptables' qui vient d'être livré avec un tout nouveau serveur cloud centos 6.4.

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

pour ouvrir le port 80, je peux simplement cloner la ligne ..

    -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

puis changez "22" en "80" puis enregistrez ce fichier puis redémarrez l'ensemble du système.

cela m'ouvrira le port 80.

c'est une opération assez simple. et pourtant le fichier indique que l'édition manuelle n'est pas recommandée.

pourquoi devrais-je suivre les conseils?

Parce que l’outil appelé system-config-firewall(ou son frère basé sur ncurses system-config-firewall-tui) gère ce fichier. Chaque fois que vous utilisez cet outil pour créer de nouvelles règles iptables, il est écrasé /etc/sysconfig/iptables.

Page de manuel associée: 28.1.16. / etc / sysconfig / iptables-config

C'est pourquoi ce n'est pas recommandé, mais pas interdit . La meilleure façon de sauvegarder vos règles à l'aide de CentOS ou de toute autre version EL 6 est d'utiliser le service iptables après avoir ajouté des règles sur la mémoire:

# service iptables save

Question connexe: pourquoi iptables ne récupère pas les informations de / etc / sysconfig / iptables sur centOs?

Raisons de ne pas modifier /etc/sysconfig/iptablesdirectement ce fichier ( ):

• Parce que c'est un fichier généré automatiquement. Son contenu provient du script / démon /etc/init.d/iptables.
• Certaines actions comme la réinitialisation ou l'arrêt du démon iptables peuvent entraîner une perte de données, car elles écraseront le fichier. Variables intéressantes à ce sujet: IPTABLES_SAVE_ON_STOP=""et IPTABLES_SAVE_ON_RESTART=""à l'intérieur du /etc/sysconfig/iptables-configfichier. Peut-être que les ajuster rendra vos modifications internes /etc/init.d/iptablespersistantes.
• Parce que la documentation le dit .Red Hat conseille que c'est la meilleure méthode pour utiliser leur infrastructure de pare-feu.

Une solution alternative à cette "écraser mes règles de pare-feu" mindf *** est de désactiver totalement ces scripts et de s'appuyer sur une méthode personnalisée de gestion du pare-feu, comme celle exposée par goldilocks .

et pourtant, tout en haut du fichier, il est dit ..

Hmmm, c'est étrange. Au sommet du mien, il est écrit:

# Manual customization of this file is strongly encouraged.

Quelqu'un a dû le changer;) Et en fait, il a même été déplacé /etc/sysconfigpour qu'il ne soit pas «auto non personnalisé» par le gestionnaire de paquets ou quoi que ce soit d'autre;);)

Je pense que le point ici en général avec de tels fichiers de configuration est que si vous ne savez pas ce que vous faites, ne le faites pas. Parfois, il y a aussi l'avertissement que le fichier est écrasé par le système de temps en temps. Cela pourrait être par le gestionnaire de paquets sur les mises à niveau - bien que parfois le PM notera qu'un fichier a été modifié manuellement et ne le remplace pas, ni n'en enregistre une copie, etc. - et il pourrait s'agir d'un autre outil responsable de cette configuration dans particulier (voir la réponse de nwildner ).

Une partie de «savoir ce que vous faites» consiste à être conscient d'angles comme celui-ci. J'ai également personnalisé le service init pour iptables afin d'utiliser un emplacement différent pour le fichier de configuration, et surtout: je suis le seul à utiliser cet ordinateur.

En supposant qu'il y a d'autres personnes avec un accès root, je ne le ferais pas sur un serveur dont je suis responsable à moins qu'il n'y ait une meilleure raison que "je préfère de cette façon", car cela entraînera probablement de la confusion et donnera mal à la tête à quelqu'un d'autre. à un moment donné. Mais si vous êtes le seul utilisateur et que personne d'autre ne dépend du système, vous êtes libre de faire ce que vous voulez. Ma "méthode préférée" pour configurer le pare-feu ressemble à ceci:

#!/bin/bash

if [[ ! -n "$IPTSET_FILE" ]]; then
        IPTSET_FILE=/etc/iptables.current
fi

if [[ ! -e $IPTSET_FILE ]]; then
        echo "$IPTSET_FILE does not exist!"
        exit 1
fi

vim $IPTSET_FILE
iptables-restore < $IPTSET_FILE

/etc/iptables.currentest créé au démarrage par copie /etc/iptables(que le service iptables est configuré pour charger initialement). De cette façon, je peux modifier les choses à la volée tout en maintenant un point de référence à partir duquel le système démarre.

Ce qui nous amène à un point important, si vous voulez vous amuser avec des configurations qui contiennent ce type d'avertissement: créez toujours une copie de sauvegarde de l'original en premier.