Est-il sûr de redémarrer un serveur ouvert à Internet?

Plus précisément

J'ai un ensemble de règles iptables défini sur un serveur exécutant CentOS. Suis-je garanti / puis-je garantir / comment puis-je garantir que lorsque la mise en réseau est en ligne (soit au démarrage de la machine, soit après le redémarrage du service réseau), le jeu de règles iptables est déjà appliqué (et si iptables n'a pas pu démarrer ou n'a pas appliqué le jeu de règles l'interface réseau ne parviendra pas à apparaître)?

(Je sais que c'est une question noob, mais je n'ai jamais exécuté de serveur sur autre chose que des réseaux de confiance derrière un NAT DHCP masqué et un pare-feu, alors ... attendez-vous à des questions noob de noobs.)

— Flèche du Parthe
source

Vraiment pas une question noob du tout. C'est essentiellement la façon dont les pirates sont entrés sur le réseau PlayStation en 2011, provoquant 24 jours de panne et 15 millions de dollars en règlements. Lorsque leurs pare-feu ont redémarré (comme ils l'ont fait tous les mois), le pare-feu s'est ouvert pendant quelques instants - apparemment assez longtemps.

— Chris S

@ChrisS La chose la plus étrange à ce sujet, pour moi, serait que je suis sûr que les administrateurs système responsables de ce réseau seraient presque certainement assez intelligents pour rechigner si quelqu'un proposait d'éteindre le pare-feu, mais ne se cinglait pas dessus, tous les mois , en l'éteignant ... puis en le rallumant. Je ne sais pas quelle combinaison de ces éléments pourrait l'expliquer, cependant.

— Parthian Shot

Une autre option consiste à désactiver le port sur le commutateur réseau jusqu'à ce que le serveur soit complètement démarré - si vous êtes sur site et avez accès au commutateur. Ce n'est pas idéal, mais cela fonctionnerait certainement, sauf si le serveur avait une dépendance réseau telle que NFS.

— jftuga

@jftuga Eh bien, bien sûr. Mais alors le serveur ne serait pas connecté à Internet, et donc cette solution ne relève techniquement pas de la question. Si je suis sur place, je pourrais simplement débrancher le câble Ethernet lors du redémarrage. Et le problème sous-jacent resterait de toute façon la solution de blocage de port; qu'un autre ordinateur attaquant sur le réseau ne serait pas arrêté par le pare-feu local. Si le routeur est piraté, ou fonctionne mal, ou si quelqu'un d'autre sur le réseau local est compromis, le jeu est toujours terminé.

— Parthian Shot

@jftuga En fait, le problème est encore pire que cela. En supposant que quelqu'un a déjà obtenu un logiciel pour s'exécuter sur la machine locale, mais mon pare-feu filtre les sorties, disons que la règle est que les paquets sortants ne sont autorisés que s'ils sont établis ou liés, et les nouvelles connexions entrantes ne sont autorisées qu'au port 80 Normalement, cela empêcherait un shell inversé d'un compte non privilégié. Mais si la connexion est établie au démarrage, elle sera maintenue par l'initialisation du pare-feu. Je suppose que cela signifie également que les règles du pare-feu devraient changer, mais c'est une erreur facile à faire.

— Parthian Shot

Réponses:

Dès la sortie de la boîte, vous êtes assuré que iptables démarrera avant que l'interface ne soit lancée par l'ordre des scripts de démarrage. Regardez la ligne "chkconfig" dans chaque script de démarrage et vous verrez les niveaux d'exécution sur lesquels il est "activé", l'ordre de démarrage et l'ordre d'arrêt.

Vous n'êtes pas assuré que l'interface ne sera pas affichée si l'ensemble de règles iptables n'a pas été appliqué correctement (ou pas du tout).

Exemple:
chkconfig: 2345 08 92
Cette ligne indique que le service en question sera actif dans les niveaux d'exécution 2, 3, 4 et 5, et commencera à 8 et s'arrêtera à 92. Tout ce qui a une valeur "start" plus élevée ne démarrera qu'après la fin de ce script, mais ce script en erreur est considéré comme terminé et n'empêchera pas les scripts en aval de s'exécuter.

Veuillez noter que cette réponse s'applique à CentOS 6 et versions antérieures, pas nécessairement à CentOS 7. Je n'ai pas personnellement recherché 7 suffisamment pour répondre à cette question pour 7.

— John
source

+1 Et ... de ne pas regarder un cheval cadeau dans la bouche, car votre réponse est très utile, mais ... Connaissez-vous un moyen standard de donner aux services un ordre de dépendance, de sorte que si l'un échoue au début de la chaîne, les suivants ne commencent pas? Ooh- et aussi si quelqu'un réussit à planter le pare-feu (d'une manière ou d'une autre) que l'interface réseau "descendra avec le vaisseau"? Idéalement, je voudrais que tout échoue en toute sécurité, même sur la chance que quelqu'un ait un jour pour faire le pare-feu ...

— Parthian Shot

Avec les scripts de démarrage SysV (c'est-à-dire CentOS 6 et versions antérieures), il n'y a pas de bon moyen de le faire. CentOS 7 fait les dépendances comme vous le souhaitez - si B dépend de A et A échoue, B ne démarre pas. Pour 7, pour voir l'utilisation des dépendances systemctl list-dependencies --all(je viens de regarder la page de manuel pour cela il y a 30 secondes).

— John

Bien que cette nouvelle soit un peu décevante (j'en suis à 6 pour le moment), au moins je sais maintenant que la modification des scripts d'initialisation est un hack terriblement acceptable.

— Parthian Shot

Soyez très prudent lorsque vous modifiez des scripts d'initialisation - cela pourrait provoquer de fausses alarmes sur tout logiciel de détection d'intrusion que vous pourriez avoir en place, et les modifications seront écrasées si le initscriptspackage est mis à jour (par exemple une version errata). Je ne recommande vraiment pas de faire ça.

— John

Je n'ai pas encore configuré d'IDS, donc les fausses alarmes ne sont pas un problème pour le moment (le serveur n'est pas encore en ligne, et je sais que je suis loin d'être prêt à déployer; cette question fait partie de ma préparation. Mais je vais mettre un HIDS). Je serai aussi prudent que possible, et s'il y a un moyen qui n'implique pas de modifier manuellement les parties centrales de la configuration d'init, je le fais définitivement.

— Parthian Shot

Vous pouvez également utiliser l'option ifup-post dans centos:

/ etc / sysconfig / network-scripts / ifup-post

Appelé lorsqu'un périphérique réseau SAUF un périphérique SLIP apparaît. Appelle / etc / sysconfig / network-scripts / ifup-routes pour afficher les routes statiques qui dépendent de ce périphérique. Appelle / etc / sysconfig / network-scripts / ifup-aliases pour afficher des alias pour ce périphérique. Définit le nom d'hôte s'il n'est pas déjà défini et un nom d'hôte peut être trouvé pour l'IP de ce périphérique. Envoie SIGIO à tous les programmes qui ont demandé la notification des événements du réseau.

Peut être étendu pour corriger la configuration du service de noms, appeler des scripts arbitraires, etc., selon les besoins.

Ce script s'exécute et après ce qui précède (ifup-route et ifup-aliases), il recherche ifup-local

if [ -x /sbin/ifup-local ]; then
   /sbin/ifup-local ${DEVICE}
fi

Vous pouvez donc créer ce fichier et vous assurer qu'il appelle à nouveau iptables, par exemple en utilisant iptables-restore:

iptables-restore < /etc/sysconfig/iptables

— Moti
source

Un petit addenda: pour vous assurer que les règles nécessaires seront là la prochaine fois que vous démarrerez le serveur, enregistrez-le avec

sudo sh -c "iptables-save > /etc/iptables.rules"

— manu
source