# [Iptables] Filtre de programmes

## Jamesbch

Bonsoir à tous,

Actuellement j'utilise iptables pour mon parfeu, il fonctionne très bien en forwarding, il filtre bien. Il fait tout ce que je demande sauf une chose. J'ai fais quelques recherches sur internet et j'ai pas vraiment trouvé ce que je cherchais. J'aimerais bien filtrer avec un module les connexions créées par une application. Cela ressemblerait au parfeu qu'on à l'habitude de voir sous Windows notamment, qui accepte les connexions des logiciels fiables et bloque le reste.

Je verrais bien quelque chose du style :

```
iptables -a INPUT -m process -process rtorrent --destination-port 5001 -i eth0 -j ACCEPT

iptables -a INPUT --destination-port 5001 -i eth0 -j DROP
```

Dans mon cas, c'est rtorrent qui a un port exprès pour lui (port ouvert sur Internet en entrée sur routeur). Malheureusement le port est ouvert en permance même si rtorrent n'est pas lancé. Ce qui veut dire que quelqu'un sur Internet pourrait se connecter au port (une porte d'entrée). Le but serait de limiter l'ouverture du port seulement si c'est rtorrent qui l'ouvre. C'est pour cela que je cite l'exemple du parfeu qui fonctionne selon les applications.

Sinon, j'ai découvert un module nommé "owner" mais je ne sais pas s'il peut m'aider dans mon problème.

----------

## Temet

A ma connaissance, ce type de firewall n'existe pas sous Nux.

Après, je ne suis pas expert réseau!  :Mr. Green: 

----------

## gglaboussole

Salut,

Je ne suis pas un expert réseau non plus mais avoir un port ouvert alors qu'aucune appli n'écoute derrière ne me paraît pas bien risqué

----------

## ppg

Hum, je sais pas si je réponds à côté de la plaque, mais inetd ou xinetd peuvent t'aider. J'ai utilisé xinetd pour lancer un serveur TFTP uniquement sur demande d'un client (quand une requête arrive sur le bon port). Par contre aucune idée de :

- l'intégration avec iptable,

- la possibilité de lancer rtorrent avec.

----------

## geekounet

Si le port est ouvert mais qu'aucune application n'écoute dessus, les connexions sont simplement refusées et voilà... aucun risque de connexion à ta machine par ce port là.

----------

## Jamesbch

 *geekounet wrote:*   

> Si le port est ouvert mais qu'aucune application n'écoute dessus, les connexions sont simplement refusées et voilà... aucun risque de connexion à ta machine par ce port là.

 

Salut à tous,

vous voulez plutôt dir qu'il est rejeté (REJECT) ou plutôt droppé (DROP) ? le premier est détectable et l'autre pas. Bon je suis pas mal paranoïque sur ce coup, je pense qu'il n'y a aucun risque c'est vrai. Par contre ne pas pouvoir bloquer de quelque manière ce soit les paquets entrant DANS une application, ça ça me surprend. Sortant on peut avec Iptables (-m owner) si on a l'uid ce qui est un peu compliqué faut bidouiller, faire un script pour le trouver, enfin bref pas très transparent. Cependant on peut bloquer les paquets d'un utilisateur, c'est assez pratique je pense mais qu'en sortie (il me semble).

Par contre il serait toujours possible de faire un programme lancé par xinetd qui drop les paquets, genre petit firewall avec xinetd. Ca c'est une idée qui m'est venue mais pas très propre, c'est du bricolage. Et surtout inutile.   :Laughing:  J'ai fais un test en ligne de sécurité, j'ai fait un test sur le port ouvert en question et il me dit qu'il n'y a pas de réponse (drop?), même pas de reject (Est-ce que c'est le cas vraiment ? Le port est invisible donc ?)

----------

## nurachi

SI tout le monde faisait des REJECT ce serait beaucoup plus facile de flooder son voisin...

Xinetd en lui meme a certainement tout pour te plaire. Il supporte pas mal d'options réseaux similaire à tcpd (only_from, no access, etc). Il pourra firewaller ce qui rentre dans ton application. Voir man xinetd.conf.

----------

## bob1977

Bonjour a tous,

  Avec firehol, c'est possible de filtrer en sortie par le nom de la commande http://firehol.sourceforge.net/commands.html?#cmd. Je n'ai pas testé mais ça doit surement marcher. Firehol est une surcouche de netfilter donc c'est lui qu'il faut configurer et plus iptables. C'est simple et puissant. Il y a des exemples et tutoriaux sur son site.

 *Quote:*   

> Cela ressemblerait au parfeu qu'on à l'habitude de voir sous Windows notamment, qui accepte les connexions des logiciels fiables et bloque le reste

  Il me semble que les parefeux classiques de windows bloquent les connexions sortantes d'applications non autorisées, pas les entrantes.

----------

## tmasscool

l7-filter

Permet de filtrer la couche application du modèle OSI  :Wink: 

Ça devrait répondre à vos besoins

 *l7-filter wrote:*   

> L7-filter is a classifier for Linux's Netfilter that identifies packets based on application layer data. It can classify packets as Kazaa, HTTP, Jabber, Citrix, Bittorrent, FTP, Gnucleus, eDonkey2000, etc., regardless of port. It complements existing classifiers that match on IP address, port numbers and so on.

 

----------

## sd44

merci pour l'info, mais l7-filter filtre suivant le protocole, mais pas sur une application particuliere, si on veut que seulement firefox et wget utilise http ? une idée ?

----------

## bob1977

Dans ce cas, utiliser firehol me parait une bonne idée. Autrement, il existe nufw ( dans portage) qui permet ce genre de choses et bien plus mais il m'avait paru compliqué et surtout pas dans portage a l'epoque.

----------

## sd44

nufw est tres interressant pour le filtrage utilisateur, firehol lui apparament n'est qu'un générateur de script iptables. c'est sure que iptables + l7filter + nufw est une solutuion assez complete sur un réseau d'entreprise, j'en utilise d'ailleur deja une partie mais sur mon poste perso, je voudrait autoriser seulement firefox et wget pour http par exemple,

 je ne veux pas qu'une autre appli (etc) pour diverse raison utilise ce protocole, et la je comprend bien le probleme netfilter <-> pid, existe t'il une solution sans bidouiller ?

----------

## El_Goretto

 *Jamesbch wrote:*   

> Dans mon cas, c'est rtorrent qui a un port exprès pour lui (port ouvert sur Internet en entrée sur routeur). Malheureusement le port est ouvert en permance même si rtorrent n'est pas lancé. Ce qui veut dire que quelqu'un sur Internet pourrait se connecter au port (une porte d'entrée). 

 

Ben et un script de 3 lignes qui fait l'ouverture de port et lance rtorrent? Et l'inverse à l'arrêt? C'est trop complexe?  :Smile: 

Quant à la problématique du port ouvert en permanence, mouais, quelque chose me dit qu'une personne qui utilise rtorrent n'est pas précisément quelqu'un qui est sur un site dont les systèmes ont à craindre un DoS... Donc vouloir absolument droper le paquet plutôt que le laisser vivre sa vie quand aucun service n'écoute derrière... C'est vous qui voyez.

 *Jamesbch wrote:*   

> Sinon, j'ai découvert un module nommé "owner" mais je ne sais pas s'il peut m'aider dans mon problème.

 

Euh, je ne vois pas ce que cela changerait, que tu identifies ton appli par son port propre ou son owner, vu qu'il est unique. Je me sers du module owner pour "grouper" des applications et faire de la QoS simplement dessus, pas du filtrage.

Et je ne comprends rien à cette histoire de xinetd tout çà, et ce que cela va t'apporter (overkill!!). Déjà, xinetd (et inetd) c'est le mal, c'est une couche en plus.

Nan, sérieusement, un script de 3 lignes?  :Smile: 

----------

## Jamesbch

Bonjour à tous,

 *nurachi wrote:*   

> SI tout le monde faisait des REJECT ce serait beaucoup plus facile de flooder son voisin... 

 

C'est sûr, c'est pour ça que j'étais finalement pas très sûr sinon ça pose un gros problème de sécurité.

 *bob1977 wrote:*   

> Avec firehol, c'est possible de filtrer en sortie par le nom de la commande http://firehol.sourceforge.net/commands.html?#cmd. Je n'ai pas testé mais ça doit surement marcher. Firehol est une surcouche de netfilter donc c'est lui qu'il faut configurer et plus iptables. C'est simple et puissant. Il y a des exemples et tutoriaux sur son site.

 

Je vois que c'est par protocole? Si c'est le cas c'est peu adpaté car un même programme peut faire appel à plusieurs protocoles ou un programme peut très bien chiffrer ses données comme le fait rtorrent (si option activée, comme chez moi). Dans ces cas il est impossible d'utiliser le filtrage par protocole. J'ai bien peur qu'il ne soit pas adapté.

 *bob1977 wrote:*   

> Il me semble que les parefeux classiques de windows bloquent les connexions sortantes d'applications non autorisées, pas les entrantes.

 

Pour ce qui est des firewalls Windows, ceux-ci sont totalement capable de gérer les connexion entrantes !!! Excepté celui de Windows XP, celui de Vista est capable me semble-t-il. Ce genre de firewall est capable de bloquer, accepté les connexions sortantes et/ou entrantes destinées à une applications bien précises (type de firewall interactif). Pour ce qui est des paquets à destination d'aucune application, je n'en ai pas la moindre idée... C'est là toute la différence entre Ipfilter et ce type de firewall. C'est sûr que d'avoir les deux possibilités, c'est bien plus intéressant.

 *tmasscool wrote:*   

> Permet de filtrer la couche application du modèle OSI  
> 
> Ça devrait répondre à vos besoins

 

Si c'est aussi par protocole, dommage également. Ca pourrait toujours être utile, bon à savoir donc !

 *sd44 wrote:*   

> je ne veux pas qu'une autre appli (etc) pour diverse raison utilise ce protocole, et la je comprend bien le probleme netfilter <-> pid, existe t'il une solution sans bidouiller ?

 

nufw ne te convient pas ? Moi je pense que c'est une solution très puissante et à première vue on peut se passer d'ip fixe, en contre partie on a l'obligation d'avoir un serveur LDAP et une application qui tourne sur le client. Pour la flexibilité qu'il propose je pense que ça en vaut la peine.

 *El_Goretto wrote:*   

> Ben et un script de 3 lignes qui fait l'ouverture de port et lance rtorrent? Et l'inverse à l'arrêt? C'est trop complexe?  
> 
> Quant à la problématique du port ouvert en permanence, mouais, quelque chose me dit qu'une personne qui utilise rtorrent n'est pas précisément quelqu'un qui est sur un site dont les systèmes ont à craindre un DoS... Donc vouloir absolument droper le paquet plutôt que le laisser vivre sa vie quand aucun service n'écoute derrière... C'est vous qui voyez.

 

Le but n'est pas de lancer rtorrent quand un paquet "pourrait"* lui être adressé, mais plutôt de bloquer (DROP) le paquet. (*car le port pourrait être modifié)

 *El_Goretto wrote:*   

> Euh, je ne vois pas ce que cela changerait, que tu identifies ton appli par son port propre ou son owner, vu qu'il est unique. Je me sers du module owner pour "grouper" des applications et faire de la QoS simplement dessus, pas du filtrage.

 

C'est pas faux et possible mais comment tu fais pour bloquer le paquet quand l'application est pas lancée ? D'où le débat lancé. C'est peut-être ce que tu voulais dire par grouper avec le module owner, je n'ai pas vraiment compris,... grouper ? Tu utilises un utilisateur qui lance ces applications... oui c'est pas mal mais c'est un contournement du problème, un utilisateur peut lancer l'application depuis son utilisateur (et si on bloquait l'éxecution et partager l'utilisateur [...] non pourquoi se compliquer ?)

 *El_Goretto wrote:*   

> Et je ne comprends rien à cette histoire de xinetd tout çà, et ce que cela va t'apporter (overkill!!). Déjà, xinetd (et inetd) c'est le mal, c'est une couche en plus. 
> 
> Nan, sérieusement, un script de 3 lignes?

 

Si xinted c'est le mal, alors toutes les couches ajoutées au kernel le sont ? C'est sûr que xinetd ne devrait pas être un firewall, je suis d'accord.

Je vais de cas pas aller jeter un oeil sur nufw même si ça à l'air lourd comme mise en place avec LDAP et l'application sur chaque poste. Sinon je tient à vous remercier pour vos avis, la discussion est très intéressante !

Désolé pour la lisibilité qui laisse à désirer.

----------

## Temet

http://olivieraj.free.fr/fr/linux/information/firewall/fw-03-11.html

C'est ptet pas du tout neuf, mais ça symbolise bien ma pensée : le firewall applicatif existe surtout sous Windows car les applis de cet ersatz aiment te trahir...

Il y a néanmoins une solution proposée, que j'espère toujours existante. En tout cas, ça ressemble furieusement à ce que tu voulais.

----------

## El_Goretto

 *Jamesbch wrote:*   

>  *El_Goretto wrote:*   Ben et un script de 3 lignes qui fait l'ouverture de port et lance rtorrent? Et l'inverse à l'arrêt? C'est trop complexe? 
> 
> Le but n'est pas de lancer rtorrent quand un paquet "pourrait"* lui être adressé, mais plutôt de bloquer (DROP) le paquet. (*car le port pourrait être modifié)

 

C'est bien ce qu'il me semblait, tu prends le problème à l'envers... Le but n'est pas de lancer un service quand un paquet arrive (çà, c'est du (x)inetd) mais d'ouvrir le port quand un service se lance... Je sais, c'est si simple que ça choque parfois  :Smile: 

 *Jamesbch wrote:*   

> C'est peut-être ce que tu voulais dire par grouper avec le module owner, je n'ai pas vraiment compris,... grouper ? 

  En fait, je passe par un groupe système pour identifier les applis lancées par des comptes systèmes. Pour de la QoS, pas du filtrage, donc criticité faible.

 *Jamesbch wrote:*   

> Si xinted c'est le mal, alors toutes les couches ajoutées au kernel le sont ?

 

Oui, c'est çà l'idée. Moins il y en a, moins y a de risque. Pareil pour les trucs activés dans la quenelle. KISS comme on dit  :Smile:  Sans compter que xinetd n'a vraiment plus aucun intérêt de nos jours (l'objectif initial était l'économie de ressources).

----------

## Jamesbch

Tu as tout à fait raison El_Goretto. Temet, sait-tu s'il est possible de se faire un petit programme sans interface graphique ?

Sinon j'ai regardé au niveau d'iptables le module owner qui a/avait --cmd-owner, il semblerait que :

 *Quote:*   

> xt_owner: PID, SID and command matching is not supported anymore

 

je comprend pas pourquoi ??? Ca a l'air bien pratique cette option, surtout que le PID est plus supporté non plus !!! Donc il n'y a aucun moyen ou alors j'ai mal compris et on peut toujours l'utilisé ? si oui comment ?

----------

## Temet

Euh, c'est toujours possible ... mais ne compte pas sur moi, j'ai même pas netfilter d'installé dans le noyau!  :Mr. Green: 

----------

## alligator421

plop !

 *Quote:*   

> 
> 
> je comprend pas pourquoi ??? Ca a l'air bien pratique cette option, surtout que le PID est plus supporté non plus !!! Donc il n'y a aucun moyen ou alors j'ai mal compris et on peut toujours l'utilisé ? si oui comment ?
> 
> 

 

Oui, c'est bien pratique mais c'est fini. Pour la petite histoire, les développeurs noyaux ont découverts à l'époque un bug dans le code de ipt_owner, genre race condition qui se produit uniquement quand on a une machine SMP. Au lieu de corriger le bug, ils ont simplement enlevé tout le code qui permettait le filtrage par programme de netfilter !   :Rolling Eyes:  Il a été argumenté que de toute facon, ca pronait un modèle de securité erroné.

Tous les firewall wrapper de netfilter tel que firehol ne fonctionnent pas vu que --cmd-owner de netfilter n'est plus implementé dans le noyau.

A ce que j'ai vu, seul nuFW sait filtrer sur base du programme et n'utilise pas ipt_owner (ou xt_owner). Le problème c'est que nuFW, c'est la patate à configurer (architecture client/serveur) et qu'il ne sait pas filtrer les paquets udp client sur linux (sous win oui) pour le moment.

Pour ma part, j'ai backporté ipt_owner sur les noyaux que j'utilise (pas SMP). Mais la, ca devient lourd avec xt_truc, ils ont meme changé les structures C des noyaux recents, je vais avoir dur pour modifier ca, je capte le C mais pas trop le code noyau.

----------

## sd44

je ressort ce topic car je viens de trouver ça dans le man d'iptables :

owner

Ce module tente d'établir une correspondance avec différentes caractéristiques du créateur d'un paquet, pour les paquets générés localement. Il est valide uniquement dans la chaîne OUTPUT, et même si certains paquets sans propriétaire (comme les réponses ICMP d'un ping) ne correspondront jamais.

--uid-owner id_utilisateur

    Établit une correspondance si le paquet a été créé par un processus avec l'identifiant d'utilisateur donné. 

--gid-owner id_de_groupe

    Établit une correspondance si le paquet a été créé par un processus avec l'identifiant de groupe donné. 

--pid-owner id_du_processus

    Établit une correspondance si le paquet a été créé par un processus avec le numéro de processus donné. 

--sid-owner id_de_session

    Établit une correspondance si le paquet a été créé par un processus dans le groupe de session donné. 

--cmd-owner nom_de_commande

    Établit une correspondance si le paquet a été créé par un processus avec le nom de commande donné (cette option n'est disponible que si iptables a été compilé avec un noyau acceptant cette particularité). 

 bien sûr dans le cadre d'un firewall en local. quelqu'un utilise deja ça ?

----------

