4 votes

règles iptables pour bloquer les ports de transfert à distance de ssh

J'essaie de configurer une règle iptables qui bloque l'accès aux connexions ssh transférées à distance via des connexions ssh transférées à distance locales. Donc, IOW :

Client A connects to server:
ssh -R 10000:localhost:23 someserver

Client B connects to server:
ssh -L 23:localhost:10000 someserver

Je n'arrive pas à faire en sorte qu'iptables bloque ça. J'ai besoin de la redirection dans certains cas que les paramètres sshd_config ne peuvent pas couvrir (j'aurai un programme qui distribuera spécifiquement le port sur lequel un client peut rediriger, et j'espère que le programme ajoutera ensuite une règle iptables pour l'autoriser).

J'ai essayé :

iptables --flush

iptables -A INPUT -i lo -p tcp --dport 0:1024 -j ACCEPT
iptables -A OUTPUT -o lo -p tcp --dport 0:1024 -j ACCEPT
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

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

Mais cela permet toujours aux connexions ssh locales transférées d'accéder au port distant transféré. Avez-vous des idées sur la manière de faire en sorte qu'iptables gère cela ?


EDIT:J'ai essayé de changer pour :

iptables --flush
iptables --policy INPUT DROP 
iptables --policy OUTPUT DROP 

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT 
iptables -A OUTPUT -o eth1 -p tcp --sport 22 -j ACCEPT 
iptables -A INPUT -j REJECT 

Je peux quand même établir les connexions transférées. Donc apparemment ce n'était pas tout à fait ça. Merci quand même pour la réponse. Avez-vous d'autres idées pour moi ?

5voto

jjnguy Points 62123

Ne serait-il pas plus simple de désactiver la redirection ssh sur le serveur ssh ? Il suffit de modifier AllowTcpForwarding de oui à non dans votre /etc/ssh/sshd_config. Si cela ne convient pas, vous pouvez essayer quelque chose du type

iptables -A OUTPUT -o eth1 -p tcp --cmd-owner "sshd" -j DROP

1 votes

Je vais le réactiver pour les ports sélectifs sur une base par utilisateur, donc non cela ne fonctionnera pas, ce que j'ai indiqué dans ma question.

0 votes

Essayez la règle ajoutée ?

0 votes

Je n'ai pas compilé le module ipt_owner, mais j'essaie quand même de bloquer le trafic qui écoute sur des numéros de port élevés sur l'interface loopback. Il semble que cela ne devrait pas nécessiter ce module. Avez-vous une idée de la raison pour laquelle les règles générales que je configure n'interceptent pas ce trafic ?

3voto

Oliver Nelson Points 239

J'ai compris. Mon jeu de règles d'origine bloquait tout très bien. Le problème était que sur ce serveur, localhost se résout (via /etc/hosts) à ::1 (la boucle IPv6) en premier. Ces règles ne fonctionnaient pas pour cette raison. Après avoir supprimé cette entrée de mon fichier /etc/hosts, j'ai pu faire en sorte que tout fonctionne parfaitement. Mon script de test ressemble à ceci :

#!/bin/bash
iptables --flush

iptables -A INPUT -i lo -p tcp --dport 0:1024 -j ACCEPT
iptables -A OUTPUT -o lo -p tcp --dport 0:1024 -j ACCEPT
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j REJECT

#iptables -I INPUT 1 -i lo -p tcp --dport 10001 -m state --state NEW,ESTABLISHED -j ACCEPT
#iptables -I OUTPUT 1 -o lo -p tcp --dport 10001 -m state --state NEW,ESTABLISHED -j ACCEPT

Avec les deux dernières lignes activées, je peux ouvrir une connexion ssh local forwarded sur le port 10001. Si elles sont désactivées, je ne peux pas. Parfait !

0 votes

Notez qu'à ce stade, toute personne suffisamment intelligente pour transférer son port explicitement via ::1 contournera votre règle. Notez également qu'ils pourraient le faire suivre vers un socket Unix local et ensuite le transmettre à partir de là par d'autres moyens en fonction de ce qu'ils font. Notez également que si vous essayez de bloquer les transferts de fichiers, l'accès Shell que vous leur donnez est suffisant.

0voto

jammus Points 1796

Les connexions transférées proviendront du système local. Vous devez supprimer la règle ci-dessous qui autorise les connexions sortantes, puis, si nécessaire, la remplacer par quelques règles qui n'autorisent que les connexions sortantes que vous autorisez explicitement.

iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

0 votes

J'ai essayé, ça marche toujours. D'autres idées ?

0voto

Juraj Points 247

Veuillez prendre en compte le fait que l'on peut utiliser "localhost" à la place :

  • toute adresse de bouclage 127.x.x.x
  • adresse de toute interface réseau sur le serveur

et aussi vous n'avez rien écrit sur le client B qui tente de se connecter directement au client A :

ssh -L 23:clientA:80 someserver (J'ai choisi le port 80 parce que votre pare-feu l'autorise peut-être à sortir).

Je suis désolé, mais avec toutes ces options (et bien d'autres) disponibles, ainsi que vos connaissances très basiques d'iptables, il est très probable que vous laissiez des trous béants dans votre configuration. Si quelque chose de vraiment précieux est en jeu, je vous suggère de demander à quelqu'un qui s'y connaît mieux de tout faire.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X