IPTABLES est lent après l'ajout de '-A INPUT -j DROP' à la liste des règles

Je commence juste avec iptables et suis tombé sur quelque chose que je ne comprends pas vraiment.

Pour info, j'ai suivi les instructions de IptablesHowTo du wiki d'Ubuntu .

Les tables nat et mangle sont vides, je travaille uniquement avec la table de filtre pour le moment.

Le problème

Si j'ajoute les règles iptables suivantes:

iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -j DROP

... alors j'ai toujours accès à ma machine via ssh, cependant toutes les commandes iptables prennent environ une minute ou deux pour s'exécuter. Ce n'est pas un problème DNS, -nne le change pas.

La solution

Si je vide la table et ajoute ces trois règles à la place, tout fonctionne bien:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -j DROP

Quelqu'un peut-il m'expliquer pourquoi la première règle a un si grand impact sur iptables? Je comprends qu'il permet aux sessions établies de recevoir du trafic, mais pourquoi en ai-je besoin si ssh est ouvert?

iptables

— mohrphium
source

Dans certains cas, les sudorecherches DNS sont-elles effectuées et si celles-ci sont bloquées, la commande sera lente. Toutes vos autres iptablescommandes sont-elles préfixées sudo?

— Ladadadada

Exécutez sudo strace …(à partir d'un shell racine) pour voir sur quoi il bloque.

— Gilles 'SO- arrête d'être méchant'

Réponses:

Il effectue une recherche DNS et comme la réponse est bloquée, il faut un certain temps pour expirer.

Essayez de faire iptables -n ... pour empêcher la recherche DNS.

Le conntrack permet de recevoir des connexions sur le port éphémère qui a été créé pour les réponses aux requêtes lancées par votre machine (dans ce cas la requête DNS). Sans autoriser les connexions ESTABLISHED ou RELATED, même les réponses à vos demandes sont bloquées.

EG: Si vous tentez d'accéder à un site Web, même si vous pouviez envoyer la demande pour le site Web, la réponse du site Web serait bloquée.

— user2371745
source

Avec

iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -j DROP

votre machine supprimera chaque paquet entrant, sauf s'il provient du port SSH. C'est une bonne idée si vous souhaitez que cette machine communique uniquement via SSH. Sinon, vous devez ajouter

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

cela vous assurera que vous allez vous connecter à un serveur Web plutôt que de vous connecter à quelqu'un.

— edmz
source

Bien que ce soit un bon conseil en général, cela ne répond pas à la question qui était réellement posée.

— Shadur

@Shadur conntrack fait la différence. Cela s'oppose à tout abandonner.

— Nils

Si vous envoyez une demande générique à un serveur Web via une machine comme dans ce cas, cette dernière n'affichera rien car le pare-feu ne permet pas d'envoyer des paquets à une machine avec une connexion établie.

— edmz

Mais même si je n'autorisais ssh qu'à utiliser les deux premières commandes, pourquoi les commandes iptables prennent-elles autant de temps qu'avec la règle conntrack ... Et la règle conntrack signifie-t-elle que je pourrais me connecter à un serveur web? Cela ne rendrait-il pas la règle du drop inutile?

— mohrphium

Non, ce ne serait pas le cas. Avec -m conntrackvous, vous pouvez avoir une autre "chance" que les paquets soient acceptés avant qu'ils ne soient abandonnés à coup sûr. Sur la machine cliente, vous devez en avoir iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT si vous voulez voir une réponse. Côté serveur, autorisez simplement la connexion entrante SSH et supprimez tout le reste (si le serveur agit uniquement comme SSH). J'espère que tout est clair.

— edmz