iptables module owner : comment autoriser spécifiquement les connexions des utilisateurs

plop

Un rapide mémo/article, sur comment autoriser des connexions établit par des utilisateurs spécifiques avec iptables.
L’idée générale étant que l’on drop tout par défaut, et que l’on autorise seulement certaines connexions par ports/logiciels, le soucis étant que si l’on ne connait pas les ports de sortie de notre services sur de nouvelles connexion (cas de serveurs tor/P2P dans lesquels les ports peuvent être aléatoire), on est obligé de passer en policy accept pour profiter un maximum du service (au risque que si le service http soit compromis un hacker puisse depuis le process ouvrir une connexion inverse pour bypass le firewall en drop sur l’entrée).

Grâce au module d’iptables, on peut spécifier, des connexions sur :
– un utilisateur particulier
– un groupe d’utilisateur particulier
– un paquet associé à un socket

Ce qui permet de limiter la casse dans le cas présenté précédemment :

Logiciel Apache
Autorisation des NOUVELLES connexions entrantes sur le port 80 à l’utilisateur apache (ce n’est PAS le nom du logiciel!!Mais bien celui de l’utilisateur qui l’execute) et limitation du nombre de connexion à celle pouvant être offerte par le service en question

/sbin/iptables -A INPUT -p tcp -i eth0 --dport 80 -m owner --uid-owner apache -m state --state NEW -m limit --limit 150/s --limit-burst 200 -j ACCEPT

Pour les connexions entrantes, on est pas vraiment obligé de limiter les droits à l’utilisateur, puisque seulement un logiciel peut se bind au port 80.

Réseau tor
Autorisation de n’importe quelle connexions sortantes, du moment qu’elle provienne de l’id utilisateur 112 (chez moi l’utilisateur tor) et qu’elle soit en TCP

/sbin/iptables -A OUTPUT -o eth0 -p tcp -m owner --uid-owner 112 -m state --state NEW -j ACCEPT

Ce qui nous permet d’ouvrir des connexions n’importe où, malgré un :

/sbin/iptables -P OUTPUT DROP

depuis le processus tor, tout en dropant toute nouvelle connexion depuis le processus apache.

ça permet de se passer de divers systèmes de sécurité plus lourd (Selinux, acl grsec, …) pour des serveurs ne nécessitant pas de sécurité élevé (ça existe?? ^^).

A noter que bien entendu avec du selinux/grsec, autant gérer les droits directement par le kernel que par le firewall, cette méthode est donc inutile dans ce cas ;), mais ça peut dépanner (j’étais persuadé qu’il fallait obligatoirement des LSM/ACL pour ça, mais les auteurs d’iptables avaient pensé à tout :)).