iptables, stratégie par défaut vs règles

Y a-t-il une différence dans la suppression des paquets non appariés avec la stratégie par défaut vs -j DROPà la fin?

Comme:

iptables -P INPUT DROP
iptables -A INPUT --dport 80 -j ACCEPT

contre

iptables -A INPUT --dport 80 -j ACCEPT
iptables -A INPUT -j DROP

La raison pour laquelle je m'en soucie est parce que je ne peux pas créer de chaîne avec log et l'assigner comme stratégie par défaut, donc je devrais utiliser le deuxième exemple.

D'un point de vue technique, non. Le paquet est abandonné de toute façon.

Mais Sirex est tout à fait correct en ce sens que cela peut être un peu douloureux si vous oubliez quelque chose d'important lorsque vous changez les règles par défaut de la table.

Après avoir passé du temps avec IPTables, vous trouverez probablement une préférence et construirez vos systèmes autour de cela dans votre environnement.

Oui. Si vous utilisez une stratégie DROP, puis vous connectez via SSH et videz la table ( iptables -F), vous vous verrouillez car la stratégie par défaut n'est pas vidée.

Je l'ai fait sur un système distant. Ça fait mal.

(Autre leçon apprise, si vous voulez vous débarrasser du pare-feu pendant un certain temps, utilisez service iptables stop, pas iptables-F + service iptables reload)

Une politique par défaut est probablement plus sûre d'être plus facile à gérer. Vous ne pouvez pas oublier de l'ajouter à la fin.

Peut-être une autre chose à ce sujet pour ceux qui ont besoin de ces informations comme moi il y a quelques heures.

La dernière façon:

iptables -A INPUT --dport 80 -j ACCEPT
iptables -A INPUT -j DROP

ne vous permet pas d'ajouter une règle plus tard (car la règle ajoutée apparaîtra après la règle de suppression universelle et n'aura donc aucun effet), vous devrez insérer la règle avec une déclaration explicite de la position souhaitée:

iptables -I INPUT 1 --dport 8080 -j ACCEPT

au lieu de

iptables -A INPUT --dport 80 -j ACCEPT

En fonction de vos besoins, cela peut aider un peu la sécurité en vous obligeant ou tout autre ajout ultérieur de la règle pour vraiment passer par les règles existantes et non pas simplement l'ajouter comme d'habitude.

Cette connaissance que j'ai acquise hier en vérifiant pendant vingt minutes pourquoi mon service nouvellement installé ne répondra pas même si tout est opérationnel.

Les politiques par défaut sont assez limitées, mais constituent un bon filet de sécurité pour garantir que les paquets non traités sont traités de manière appropriée.

Si vous devez (voulez) enregistrer ces paquets, vous avez besoin d'une règle finale. Il peut s'agir d'une chaîne qui enregistre et applique la stratégie. Vous pouvez également simplement vous connecter et laisser la stratégie s'en occuper.

Tenez compte de ces approches de la politique et de la règle de politique finale.

• utiliser et accepter la stratégie et remplacer la stratégie souhaitée comme règle finale. Cela peut vous protéger lorsque vous gérez un hôte à distance. Si vous abandonnez vos règles, il ne vous reste plus que votre ligne de défense secondaire telle que hosts.allow. Si vous abandonnez votre règle finale, vous vous retrouvez dans une configuration principalement ouverte ou entièrement ouverte.
• définissez la stratégie souhaitée et sauvegardez-la avec une règle de stratégie finale. Cela peut être plus sécurisé lorsque vous avez un accès physique ou console à un hôte. Si vous abandonnez vos règles, vous perdez l'accès à tous les services, sauf si la politique est ACCEPTER. Si vous abandonnez votre règle finale, vous êtes toujours protégé.