Accepter RELATED, ESTABLISHED pour toutes les sources dans iptables est-il considéré comme «trop ouvert»?

9

J'ai souvent vu la règle -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTappliquée. Bien que je ne sois pas un expert, cette ligne particulière me concerne. Il est assez évident que la règle autorise tout le trafic à la seule exception que la connexion doit avoir été établie ou liée à une connexion établie.

Scénario

Je vais autoriser les connexions au port SSH par défaut à 22partir du LAN des serveurs dans le sous-réseau 192.168.0.0/16ou autre.
SuperInsecureApp®expose quelque chose sur le port 1337, que j'ajoute à ma INPUTchaîne.
J'ai ajouté la conntrackrègle d'accepter ESTABLISHEDet RELATEDde toutes les sources
La politique de la chaîne est DROP

Donc, fondamentalement, cette configuration devrait autoriser les connexions SSH à partir du LAN uniquement, tout en autorisant le trafic entrant sur le port 1337 en provenance du monde.

C'est là que ma confusion fleurit. Est-ce que conntrackcela exposerait d'une manière ou d'une autre une faille de sécurité qui permettrait d'obtenir une connexion établie sur 1337 (car il est ouvert au monde), puis d'utiliser cette connexion pour accéder au port SSH (ou à tout autre port d'ailleurs)?

security iptables ip tcp

— Dencker
source

8

Je ne considérerais pas le trafic ÉTABLI et ASSOCIÉ trop ouvert. Vous pouvez peut-être omettre RELATED, mais vous devez certainement autoriser ESTABLISHED. Ces deux catégories de trafic utilisent des états conntrack.

Les connexions ESTABLISHED ont déjà été validées par une autre règle. Cela rend beaucoup plus simple l'implémentation de règles unidirectionnelles. Cela vous permet uniquement de poursuivre les transactions sur le même port.

Les connexions RELATED sont également validées par une autre règle. Ils ne s'appliquent pas à beaucoup de protocoles. Encore une fois, ils rendent la configuration des règles beaucoup plus simple. Ils assurent également un bon séquencement des connexions là où elles s'appliquent. Cela rend en fait vos règles plus sécurisées. Bien que cela puisse permettre de se connecter sur un port différent, ce port ne devrait faire partie que d'un processus connexe comme une connexion de données FTP. Les ports autorisés sont contrôlés par des modules conntrack spécifiques au protocole.

En autorisant les connexions ESTABLISHED et RELATED, vous pouvez vous concentrer sur les nouvelles connexions que vous souhaitez que le pare-feu accepte. Il évite également les règles brisées destinées à autoriser le trafic de retour, mais qui permettent de nouvelles connexions.

Étant donné que vous avez classé le programme sur le port 1337 comme non sécurisé, il doit être démarré à l'aide d'un ID utilisateur non root dédié. Cela limitera les dommages que quelqu'un peut faire s'ils parviennent à casser l'application et à obtenir un accès amélioré.

Il est très peu probable qu'une connexion sur le port 1337 puisse être utilisée pour accéder au port 22 à distance, mais il est possible qu'une connexion au port 1337 puisse être utilisée pour proxy une connexion au port 22.

Vous pouvez vous assurer que SSH est sécurisé en profondeur:

Utilisez hosts.allow pour limiter l'accès en plus des restrictions du pare-feu.
Empêchez l'accès root, ou du moins exigez l'utilisation de clés et limitez leur accès dans le fichier authorized_keys.
Audit des échecs de connexion. Un scanner de journaux peut vous envoyer des rapports périodiques d'activité inhabituelle.
Envisagez d'utiliser un outil tel que fail2ban pour bloquer automatiquement l'accès en cas d'échecs d'accès répétés.

— BillThor
source

Bien que ce soit un exemple arbitraire, la première chose que je fais sur les nouveaux serveurs est toujours de désactiver l'accès root et l'authentification en clair dans sshd - c'est un très bon conseil. Fail2ban est également déjà installé sur la configuration réelle dont l'exemple a été inspiré. "Les connexions ÉTABLIES ont déjà été validées par une autre règle" était exactement la chose dont je n'étais pas sûr et répond parfaitement à ma question. Merci pour votre réponse très claire!

— Dencker

Question secondaire: Du point de vue des performances, cela change-t-il quelque chose si la conntrackrègle se trouve au début ou à la fin de la chaîne? D'après ce que je comprends iptables, il devrait traiter toutes les règles sur les connexions établies si c'était à la fin, et seulement cette règle unique si elle était placée au début?

— Dencker

@Dencker Vous voulez d'abord la règle ESTABLISHED, RELATED. Il acceptera de loin le plus de trafic. Au-delà de cela, vous voudrez peut-être avoir les règles qui acceptent le plus de trafic, bien qu'il soit préférable de peser lourdement sur la lisibilité. Mes règles sont groupées, sensibles à la latence, à fort trafic (groupées par type), autres. Iptables a des compteurs qui vous permettent de voir combien de trafic chaque règle traite. J'utilise Shorewall, qui ajoute des valeurs par défaut utiles et a un fichier de règles facile à lire pour construire mes pare-feu.

— BillThor

2

ESTABLISHED et RELATED sont des caractéristiques du filtrage de paquets "avec état", où le filtrage ne dépend pas seulement d'un ensemble de règles statiques mais aussi du contexte, dans lequel les paquets sont considérés. Vous avez besoin d'ETABLISHED pour permettre aux connexions de fonctionner et vous avez besoin de RELATED pour les messages ICMP pertinents. Le filtrage avec état permet de filtrer plus précisément par rapport aux règles statiques "sans état".

Regardons d'abord ETABLISHED. Par exemple, considérez TCP sur le port 22. L'initiateur (client) envoie un SYNà serverIPaddr:22. Le serveur revient SYN+ACKau client. C'est maintenant au tour du client d'envoyer un ACK. A quoi devrait ressembler la règle de filtrage sur le serveur, de sorte que seule la "correspondance" ACKsoit acceptée? Une règle générale apatride ressemblerait à

-A INPUT --proto tcp --port 22 -j ACCEPT

ce qui est plus libéral que la règle de l’état qui l’accorde La règle sans état autorise des segments TCP arbitraires, par exemple ACKou FINsans avoir préalablement établi une connexion. Les scanners de ports peuvent exploiter ce type de comportement pour les empreintes digitales du système d'exploitation.

Voyons maintenant RELATED. Ceci est utilisé pour les messages ICMP, principalement les messages d'erreur. Par exemple, si un paquet du serveur vers le client est abandonné, un message d'erreur est envoyé au serveur. Ce message d'erreur est "lié" à la connexion précédemment établie. Sans la règle RELATED, il faudrait soit autoriser les messages d'erreur entrants en général (sans contexte), soit, comme c'est la coutume pour de nombreux sites, supprimer complètement ICMP et attendre les délais d'attente sur la couche de transport. (Notez que c'est une mauvaise idée pour IPv6; ICMPv6 joue un rôle plus important pour IPv6 que ICMP pour l'héritage IP.)

— contre-mode
source