[IPTABLES] Accepter tout les INPUT/OUTPUT depuis un process

Salut,

je viens de terminer la configuration de mon prosody (XMPP) à un détail près: Certains salons utilisent un port différent que le 5269, or je me vois mal ajouter des règles à chaque fois que je découvre qu’un salon change son port.

On m’a expliqué qu’il fallait accepter les connexions entrantes et sortantes depuis le processus (prosody) plutôt que par des ports.

J’ai trouvé ce topic: unix.stackexchange.com/questions … s-firewall

Ou si je comprend bien, je dois lancer le processus en question depuis un utilisateur particulié et accepté tout ce que l’utilisateur fera (à travers iptables j’entends).

Seulement cela ne risque t’il pas de provoquer un problème de sécurité? Auquel cas je dois m’assurer que l’utilisateur en question n’a pas de shell par exemple?

Koshicalement, Koshie

Cela peut être un utilisateur système sans shell ni connexion par mot de passe comme il en existe pour d’autres services (exim, postgresql, bind…). D’ailleurs le script de post-installation du paquet prosody crée un utilisateur et un groupe système “prosody” s’ils n’existent pas. Si le processus prosody tourne avec ces utilisateur et groupe, tu peux les utiliser pour filtrer le trafic sortant avec la correspondance “owner” d’iptables. C’est uniquement pour des connexion sortantes ?

Le risque, comme toujours, est que si le processus est compromis, il pourra servir à envoyer du spam, faire des attaques SSH par force brute… Mais tu peux mettre en place des règles iptables pour restreindre les ports autorisés à son utilisateur, notammment en lui bloquant les ports connus auxquel prosody n’est pas censé se connecter (SMTP, SSH…).

Mais en enlevant un accès à un shell, comment peut-il faire ce genre d’opération? Je sais qu’il est par exemple possible de récupérer l’accès remote depuis un exploit (faire planter le logiciel exécuté et lancer une commande par la suite, revenant au shell le pirate a accès au terminal) mais sans shell il devra juste se manger une erreur, je pense.

De plus je crois que l’idéal est de lancer le logiciel sans droit root, comme ça même avec un accès le pirate ne pourra intéragir que dans son home et sur les fichier en o+rwx. Après, bien configuré les droits sur son système empêche ce genre de chose d’arriver aussi.

Quand on dit qu’un utilisateur n’a pas de shell, cela ne veut pas dire qu’il ne peut pas lancer un shell (ou n’importe quelle autre commande) mais que l’interpréteur par défaut défini dans /etc/passwd, utilisé notamment lors d’une ouverture de session, ne donne pas accès à un shell (ex: /bin/false). Le processus compromis tourne déjà, il n’a pas besoin d’ouvrir de session.

Okay, d’où l’importance de m’assurer qu’il n’aura pas de droit root (si c’est possible, je sais que certains services le peuvent). Comme ça même en cas d’exploit je limite pas mal les dégâts potentiels.

C’est bien pour cela que certains services tournent en tant qu’un utilisateur système particulier et pas en tant que root. Vérifie si c’est le cas de prosody.

Voici la ligne dans /etc/passwd à propos de Prosody:

Si je ne m’abuse:

111 indique un UID inférieur à 500, donc c’est un utilisateur du système. De plus le /bin/false indique qu’il n’a pas de shell (donc on ne peut pas s’y connecter directement).

Est-ce qu’en lançant avec root la commande:

la main est donné à l’utilisateur prosody? Dans /etc/init.d/prosody j’ai trouvé la ligne:

À priori c’est le cas.

Si je veux autoriser toutes les connections entrantes et sortantes demandé, je peux le faire avec l’option :

dans ma ligne iptables, par contre au niveau de la syntaxe ça se passe comment? Quelque chose du genre:

Koshicalement, Koshie

Cela semble bon, mais pour être sûr tu peux vérifier avec “ps -Af”, “ps aux” ou autre option de ps qui affiche tous les processus et leur UID que le processus prosody a bien l’UID prosody.

Par contre comme je l’ai déjà dit, la correspondance “owner” d’iptables ne peut être utilisée que pour les paquets sortants, dans la chaîne OUTPUT, car on peut remonter au propriétaire du processus qui les a émis. Les paquets reçus n’ont pas encore de propriétaire car le processus qui va les recevoir n’est pas encore connu. Pour la syntaxe (cf. man iptables), voici un exemple :

Cela autorise les paquets TCP sortants émis par l’utilisateur prosody sauf ceux à destination des ports 22 (SSH) et 25 (SMTP). On peut aussi spécifier des plages de ports à exclure sous la forme xxx:yyy. Par exemple 0:1023 pour exclure tous les ports privilégiés, a priori non utilisés par XMPP (sauf le port TCP 53 pour des requêtes DNS longues, mais tu devrais déjà avoir une règle générale pour ce type de paquet).