Firewall sortant par application: comment ca marche ? Et sous unix ?
33 réponses
Yannick Patois
Bonjour,
J'ai lu que certains firewall sous windows etaient capable de donner
acces au reseau en selectionnant application par application les
autorisations.
J'aimerais savoir comment est fait ce mecanisme (comment le firewall
sait-il quelle application a cree le paquet a envoyer) et s'il est
facile a contourner (creer un binaire avec le meme nom, etc.).
Je serais surtout interesse par savoir si l'equivalent peut etre fait
sous unix (et linux en particulier), si cela a ete fait (les fw que je
connais ne le font pas) et quels sont les methodes permettant d'y
arriver eventuellement.
Merci.
Yannick
--
_/ Yannick Patois \___________________________________________________
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: patois@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |
Donc, être capable de le modifier, c'est être root, et être root, c'est être capable d'altérer les règles de firewalling.
Pas forcément. Avec un noyau patché comme il faut (par exemple un vserver), root est loin d'avoir tous les droits.
-- Arnaud
Cedric Blancher
Le Thu, 27 May 2004 16:17:07 +0000, Arnaud Gomes-do-Vale a écrit :
Pas forcément. Avec un noyau patché comme il faut (par exemple un vserver), root est loin d'avoir tous les droits.
Sauf que sur un noyau patché comme il faut, tu peux filtrer les accès à tous les appels systèmes, donc les appels au réseau, et tu peux filtrer les applications à ce niveau là. LIDS fait ceci.
Bref, je ne vois pas l'intérêt de vérifier les hashes d'applis que seul root (ou le super root) peut modifier. Mais bon, moi ce que j'en dis...
-- BOFH excuse #132:
SCSI Chain overterminated
Le Thu, 27 May 2004 16:17:07 +0000, Arnaud Gomes-do-Vale a écrit :
Pas forcément. Avec un noyau patché comme il faut (par exemple un
vserver), root est loin d'avoir tous les droits.
Sauf que sur un noyau patché comme il faut, tu peux filtrer les accès à
tous les appels systèmes, donc les appels au réseau, et tu peux filtrer
les applications à ce niveau là. LIDS fait ceci.
Bref, je ne vois pas l'intérêt de vérifier les hashes d'applis que seul
root (ou le super root) peut modifier. Mais bon, moi ce que j'en dis...
Le Thu, 27 May 2004 16:17:07 +0000, Arnaud Gomes-do-Vale a écrit :
Pas forcément. Avec un noyau patché comme il faut (par exemple un vserver), root est loin d'avoir tous les droits.
Sauf que sur un noyau patché comme il faut, tu peux filtrer les accès à tous les appels systèmes, donc les appels au réseau, et tu peux filtrer les applications à ce niveau là. LIDS fait ceci.
Bref, je ne vois pas l'intérêt de vérifier les hashes d'applis que seul root (ou le super root) peut modifier. Mais bon, moi ce que j'en dis...
-- BOFH excuse #132:
SCSI Chain overterminated
Kevin
Le 27 May 2004 16:02:38 GMT, Cedric Blancher a ecrit: |> Ok. Aucun mecanisme de hash n'est prevu dans iptables dans un proche |> futur pour n'autoriser que le programme prevu et pas un autre? |> un genre de fichier /etc/hash-iptables |> avec des lignes: |> mozilla HJ45HJ45HJ45 | | Non, parce que ce n'est pas utile. | | Supposons que je veuilles empêcher un utilisateur d'utiliser autre chose | que le Mozilla qui se trouve dans /usr/bin/mozilla. Dans la mesure où on | est capable de vérifier que c'est bien ce fichier qui est exécuté | (match du chemin complet ou de l'inode), il ne sert à rien de vérifier | son intégrité parce que seul root peut le modifier. | Bon, mais comment fonctionne le systeme de fw perso des windows?
On peut imaginer le meme principe, en droits utilisateur restreints: Lors du premier lancement reseau, une demande de confirmation est faite pour autoriser ou non l'appli. Si plus tard, une appli veut sortir sans demander l'avis --> boum, interdit.
ca m'interroge sur les fw persos de windows. Qu'est ce qui interdit une appli de se mettre elle-meme dans le fichier "applis reseaux autorisees" et d'aller gambader sur internet a l'insu de l'utilisateur?
donc re: est-ce que le filtrage par applis possede un interet?
| Donc, être capable de le modifier, c'est être root,
on peut imaginer des droits limites par un wrapper quelconque.
| et être root, c'est | être capable d'altérer les règles de firewalling. | Oui.
-- Kevin Repetes moi ce que signifie l'option '-r' de rm. -+- Les 100 choses que vous n'aimez pas entendre de la part du sysadmin -+-
Le 27 May 2004 16:02:38 GMT, Cedric Blancher a ecrit:
|> Ok. Aucun mecanisme de hash n'est prevu dans iptables dans un proche
|> futur pour n'autoriser que le programme prevu et pas un autre?
|> un genre de fichier /etc/hash-iptables
|> avec des lignes:
|> mozilla HJ45HJ45HJ45
|
| Non, parce que ce n'est pas utile.
|
| Supposons que je veuilles empêcher un utilisateur d'utiliser autre chose
| que le Mozilla qui se trouve dans /usr/bin/mozilla. Dans la mesure où on
| est capable de vérifier que c'est bien ce fichier qui est exécuté
| (match du chemin complet ou de l'inode), il ne sert à rien de vérifier
| son intégrité parce que seul root peut le modifier.
|
Bon, mais comment fonctionne le systeme de fw perso des windows?
On peut imaginer le meme principe, en droits utilisateur restreints:
Lors du premier lancement reseau, une demande de confirmation est
faite pour autoriser ou non l'appli. Si plus tard, une appli veut sortir
sans demander l'avis --> boum, interdit.
ca m'interroge sur les fw persos de windows. Qu'est ce qui interdit une
appli de se mettre elle-meme dans le fichier "applis reseaux autorisees" et
d'aller gambader sur internet a l'insu de l'utilisateur?
donc re: est-ce que le filtrage par applis possede un interet?
| Donc, être capable de le modifier, c'est être root,
on peut imaginer des droits limites par un wrapper quelconque.
| et être root, c'est
| être capable d'altérer les règles de firewalling.
|
Oui.
--
Kevin
Repetes moi ce que signifie l'option '-r' de rm.
-+- Les 100 choses que vous n'aimez pas entendre de la part du sysadmin -+-
Le 27 May 2004 16:02:38 GMT, Cedric Blancher a ecrit: |> Ok. Aucun mecanisme de hash n'est prevu dans iptables dans un proche |> futur pour n'autoriser que le programme prevu et pas un autre? |> un genre de fichier /etc/hash-iptables |> avec des lignes: |> mozilla HJ45HJ45HJ45 | | Non, parce que ce n'est pas utile. | | Supposons que je veuilles empêcher un utilisateur d'utiliser autre chose | que le Mozilla qui se trouve dans /usr/bin/mozilla. Dans la mesure où on | est capable de vérifier que c'est bien ce fichier qui est exécuté | (match du chemin complet ou de l'inode), il ne sert à rien de vérifier | son intégrité parce que seul root peut le modifier. | Bon, mais comment fonctionne le systeme de fw perso des windows?
On peut imaginer le meme principe, en droits utilisateur restreints: Lors du premier lancement reseau, une demande de confirmation est faite pour autoriser ou non l'appli. Si plus tard, une appli veut sortir sans demander l'avis --> boum, interdit.
ca m'interroge sur les fw persos de windows. Qu'est ce qui interdit une appli de se mettre elle-meme dans le fichier "applis reseaux autorisees" et d'aller gambader sur internet a l'insu de l'utilisateur?
donc re: est-ce que le filtrage par applis possede un interet?
| Donc, être capable de le modifier, c'est être root,
on peut imaginer des droits limites par un wrapper quelconque.
| et être root, c'est | être capable d'altérer les règles de firewalling. | Oui.
-- Kevin Repetes moi ce que signifie l'option '-r' de rm. -+- Les 100 choses que vous n'aimez pas entendre de la part du sysadmin -+-
Cedric Blancher
Le Thu, 27 May 2004 21:50:45 +0000, Kevin DENIS a écrit :
Bon, mais comment fonctionne le systeme de fw perso des windows?
Cf. mon article dont j'ai posté le lien précédemment.
On peut imaginer le meme principe, en droits utilisateur restreints: Lors du premier lancement reseau, une demande de confirmation est faite pour autoriser ou non l'appli. Si plus tard, une appli veut sortir sans demander l'avis --> boum, interdit.
Oui, tout à fait. Mais personnellement, si je rentre dans un cadre d'utilisation restreinte, c'est l'administrateur qui fixe les droits et les utilisateurs subissent. Point.
ca m'interroge sur les fw persos de windows. Qu'est ce qui interdit une appli de se mettre elle-meme dans le fichier "applis reseaux autorisees" et d'aller gambader sur internet a l'insu de l'utilisateur?
À priori pas grand chose.
donc re: est-ce que le filtrage par applis possede un interet?
Oui, mais son utilisation efficace s'accommode mal à l'utilisateur lambda, dans la mesure où ce dernier ne doit pas avoir la possibilité de modifier quoi que ce soit à la configuration de l'outil pour éviter qu'une application exécutée en son nom puisse en modifier à son insu la configuration.
on peut imaginer des droits limites par un wrapper quelconque.
Qu'est-ce qui m'oblige à passer par le wrapper ?
-- panic("Tell me what a watchpoint trap is, and I'll then deal with such a beast..."); 2.2.16 /usr/src/linux/arch/arch/sparc/kernel/traps.c
Le Thu, 27 May 2004 21:50:45 +0000, Kevin DENIS a écrit :
Bon, mais comment fonctionne le systeme de fw perso des windows?
Cf. mon article dont j'ai posté le lien précédemment.
On peut imaginer le meme principe, en droits utilisateur restreints:
Lors du premier lancement reseau, une demande de confirmation est
faite pour autoriser ou non l'appli. Si plus tard, une appli veut sortir
sans demander l'avis --> boum, interdit.
Oui, tout à fait. Mais personnellement, si je rentre dans un cadre
d'utilisation restreinte, c'est l'administrateur qui fixe les droits et
les utilisateurs subissent. Point.
ca m'interroge sur les fw persos de windows. Qu'est ce qui interdit une
appli de se mettre elle-meme dans le fichier "applis reseaux autorisees" et
d'aller gambader sur internet a l'insu de l'utilisateur?
À priori pas grand chose.
donc re: est-ce que le filtrage par applis possede un interet?
Oui, mais son utilisation efficace s'accommode mal à l'utilisateur
lambda, dans la mesure où ce dernier ne doit pas avoir la
possibilité de modifier quoi que ce soit à la configuration de l'outil
pour éviter qu'une application exécutée en son nom puisse en modifier à
son insu la configuration.
on peut imaginer des droits limites par un wrapper quelconque.
Qu'est-ce qui m'oblige à passer par le wrapper ?
--
panic("Tell me what a watchpoint trap is, and I'll then
deal with such a beast...");
2.2.16 /usr/src/linux/arch/arch/sparc/kernel/traps.c
Le Thu, 27 May 2004 21:50:45 +0000, Kevin DENIS a écrit :
Bon, mais comment fonctionne le systeme de fw perso des windows?
Cf. mon article dont j'ai posté le lien précédemment.
On peut imaginer le meme principe, en droits utilisateur restreints: Lors du premier lancement reseau, une demande de confirmation est faite pour autoriser ou non l'appli. Si plus tard, une appli veut sortir sans demander l'avis --> boum, interdit.
Oui, tout à fait. Mais personnellement, si je rentre dans un cadre d'utilisation restreinte, c'est l'administrateur qui fixe les droits et les utilisateurs subissent. Point.
ca m'interroge sur les fw persos de windows. Qu'est ce qui interdit une appli de se mettre elle-meme dans le fichier "applis reseaux autorisees" et d'aller gambader sur internet a l'insu de l'utilisateur?
À priori pas grand chose.
donc re: est-ce que le filtrage par applis possede un interet?
Oui, mais son utilisation efficace s'accommode mal à l'utilisateur lambda, dans la mesure où ce dernier ne doit pas avoir la possibilité de modifier quoi que ce soit à la configuration de l'outil pour éviter qu'une application exécutée en son nom puisse en modifier à son insu la configuration.
on peut imaginer des droits limites par un wrapper quelconque.
Qu'est-ce qui m'oblige à passer par le wrapper ?
-- panic("Tell me what a watchpoint trap is, and I'll then deal with such a beast..."); 2.2.16 /usr/src/linux/arch/arch/sparc/kernel/traps.c
Benjamin Pineau
Le 27 May 2004 18:58:38 GMT, Cedric Blancher écrivais:
Le Thu, 27 May 2004 16:17:07 +0000, Arnaud Gomes-do-Vale a écrit :
Pas forcément. Avec un noyau patché comme il faut (par exemple un vserver), root est loin d'avoir tous les droits.
Sauf que sur un noyau patché comme il faut, tu peux filtrer les accès à tous les appels systèmes, donc les appels au réseau, et tu peux filtrer les applications à ce niveau là. LIDS fait ceci.
... ou sans patche, avec le noyau du bon OS ;)
Le 27 May 2004 18:58:38 GMT,
Cedric Blancher <blancher@cartel-securite.fr> écrivais:
Le Thu, 27 May 2004 16:17:07 +0000, Arnaud Gomes-do-Vale a écrit :
Pas forcément. Avec un noyau patché comme il faut (par exemple un
vserver), root est loin d'avoir tous les droits.
Sauf que sur un noyau patché comme il faut, tu peux filtrer les accès à
tous les appels systèmes, donc les appels au réseau, et tu peux filtrer
les applications à ce niveau là. LIDS fait ceci.
Le 27 May 2004 18:58:38 GMT, Cedric Blancher écrivais:
Le Thu, 27 May 2004 16:17:07 +0000, Arnaud Gomes-do-Vale a écrit :
Pas forcément. Avec un noyau patché comme il faut (par exemple un vserver), root est loin d'avoir tous les droits.
Sauf que sur un noyau patché comme il faut, tu peux filtrer les accès à tous les appels systèmes, donc les appels au réseau, et tu peux filtrer les applications à ce niveau là. LIDS fait ceci.
... ou sans patche, avec le noyau du bon OS ;)
Benjamin Pineau
Le 27 May 2004 14:12:15 GMT, Gilles RONSIN écrivais:
Je ne peux te parler que de Kerio 2.1.5. Il identifie le programme en vérifiant avant communication de sa signature MD5, donc même un pouillème de différence empècherait la confusion. Par contre ce
Et la signature de toutes les bibliothèques dynamiques utilisées (ou susceptibles de l'être) par l'appli ? -> je n'ose pas imaginer la lenteur ;)
Le 27 May 2004 14:12:15 GMT,
Gilles RONSIN <nomail@please.invalid> écrivais:
Je ne peux te parler que de Kerio 2.1.5. Il identifie le programme en
vérifiant avant communication de sa signature MD5, donc même un
pouillème de différence empècherait la confusion. Par contre ce
Et la signature de toutes les bibliothèques dynamiques utilisées (ou
susceptibles de l'être) par l'appli ? -> je n'ose pas imaginer la
lenteur ;)
Le 27 May 2004 14:12:15 GMT, Gilles RONSIN écrivais:
Je ne peux te parler que de Kerio 2.1.5. Il identifie le programme en vérifiant avant communication de sa signature MD5, donc même un pouillème de différence empècherait la confusion. Par contre ce
Et la signature de toutes les bibliothèques dynamiques utilisées (ou susceptibles de l'être) par l'appli ? -> je n'ose pas imaginer la lenteur ;)
Cedric Blancher
Le Sun, 30 May 2004 02:00:41 +0000, Benjamin Pineau a écrit :
Sauf que sur un noyau patché comme il faut, tu peux filtrer les accès à tous les appels systèmes, donc les appels au réseau, et tu peux filtrer les applications à ce niveau là. LIDS fait ceci. ... ou sans patche, avec le noyau du bon OS ;)
Ouais, mais le but, c'est quand même de se servir de l'ordinateur. Et si on pense au même OS, pour les serveur, tip-top, mais comme station de travail...
-- Est-ce que «AutoWolf» avait fait le même genere de déclarations lors de son départ? -+-RG in GNU: L'oeuf qui voulait se faire plus gros que le robt de FS -+-
Le Sun, 30 May 2004 02:00:41 +0000, Benjamin Pineau a écrit :
Sauf que sur un noyau patché comme il faut, tu peux filtrer les accès à
tous les appels systèmes, donc les appels au réseau, et tu peux filtrer
les applications à ce niveau là. LIDS fait ceci.
... ou sans patche, avec le noyau du bon OS ;)
Ouais, mais le but, c'est quand même de se servir de l'ordinateur. Et si
on pense au même OS, pour les serveur, tip-top, mais comme station de
travail...
--
Est-ce que «AutoWolf» avait fait le même genere de déclarations
lors de son départ?
-+-RG in GNU: L'oeuf qui voulait se faire plus gros que le robt de FS -+-
Le Sun, 30 May 2004 02:00:41 +0000, Benjamin Pineau a écrit :
Sauf que sur un noyau patché comme il faut, tu peux filtrer les accès à tous les appels systèmes, donc les appels au réseau, et tu peux filtrer les applications à ce niveau là. LIDS fait ceci. ... ou sans patche, avec le noyau du bon OS ;)
Ouais, mais le but, c'est quand même de se servir de l'ordinateur. Et si on pense au même OS, pour les serveur, tip-top, mais comme station de travail...
-- Est-ce que «AutoWolf» avait fait le même genere de déclarations lors de son départ? -+-RG in GNU: L'oeuf qui voulait se faire plus gros que le robt de FS -+-
Francois Le Gad
Benjamin Pineau a formulé ce dimanche :
Je ne peux te parler que de Kerio 2.1.5. Il identifie le programme en vérifiant avant communication de sa signature MD5, donc même un pouillème de différence empècherait la confusion. Par contre ce
Et la signature de toutes les bibliothèques dynamiques utilisées (ou susceptibles de l'être) par l'appli ? -> je n'ose pas imaginer la lenteur ;)
Quelle lenteur ? Il n'y a pas de ralentissement notable avec Kerio. Il ne contrôle que les .exe qui tentent d'établir une communication. Il ne faut pas le confondre avec un antivirus.
-- François
Benjamin Pineau a formulé ce dimanche :
Je ne peux te parler que de Kerio 2.1.5. Il identifie le programme en
vérifiant avant communication de sa signature MD5, donc même un
pouillème de différence empècherait la confusion. Par contre ce
Et la signature de toutes les bibliothèques dynamiques utilisées (ou
susceptibles de l'être) par l'appli ? -> je n'ose pas imaginer la
lenteur ;)
Quelle lenteur ? Il n'y a pas de ralentissement notable avec Kerio. Il
ne contrôle que les .exe qui tentent d'établir une communication. Il ne
faut pas le confondre avec un antivirus.
Je ne peux te parler que de Kerio 2.1.5. Il identifie le programme en vérifiant avant communication de sa signature MD5, donc même un pouillème de différence empècherait la confusion. Par contre ce
Et la signature de toutes les bibliothèques dynamiques utilisées (ou susceptibles de l'être) par l'appli ? -> je n'ose pas imaginer la lenteur ;)
Quelle lenteur ? Il n'y a pas de ralentissement notable avec Kerio. Il ne contrôle que les .exe qui tentent d'établir une communication. Il ne faut pas le confondre avec un antivirus.
-- François
Cedric Blancher
Le Sun, 30 May 2004 11:27:29 +0000, Francois Le Gad a écrit :
Quelle lenteur ? Il n'y a pas de ralentissement notable avec Kerio. Il ne contrôle que les .exe qui tentent d'établir une communication. Il ne faut pas le confondre avec un antivirus.
Je pense qu'il voulait en venir au fait qu'on peut très bien pourrir un exécutable en corrompant des bibliothèques qu'il utilise, ce qui ne modifie pas pour autant son MD5, mais clairement son fonctionnement. Et pour remédier à cela, il faudrait signer les bibliothèques et que l'application vérifie toutes les signatures lorsqu'il les charge pour s'assurer de leur intégrité.
-- BOFH excuse #70:
nesting roaches shorted out the ether cable
Le Sun, 30 May 2004 11:27:29 +0000, Francois Le Gad a écrit :
Quelle lenteur ? Il n'y a pas de ralentissement notable avec Kerio. Il
ne contrôle que les .exe qui tentent d'établir une communication. Il ne
faut pas le confondre avec un antivirus.
Je pense qu'il voulait en venir au fait qu'on peut très bien pourrir un
exécutable en corrompant des bibliothèques qu'il utilise, ce qui ne
modifie pas pour autant son MD5, mais clairement son fonctionnement. Et
pour remédier à cela, il faudrait signer les bibliothèques et que
l'application vérifie toutes les signatures lorsqu'il les charge pour
s'assurer de leur intégrité.
Le Sun, 30 May 2004 11:27:29 +0000, Francois Le Gad a écrit :
Quelle lenteur ? Il n'y a pas de ralentissement notable avec Kerio. Il ne contrôle que les .exe qui tentent d'établir une communication. Il ne faut pas le confondre avec un antivirus.
Je pense qu'il voulait en venir au fait qu'on peut très bien pourrir un exécutable en corrompant des bibliothèques qu'il utilise, ce qui ne modifie pas pour autant son MD5, mais clairement son fonctionnement. Et pour remédier à cela, il faudrait signer les bibliothèques et que l'application vérifie toutes les signatures lorsqu'il les charge pour s'assurer de leur intégrité.
-- BOFH excuse #70:
nesting roaches shorted out the ether cable
Emmanuel Florac
Le Sun, 30 May 2004 10:41:30 +0000, Cedric Blancher a écrit :
Ouais, mais le but, c'est quand même de se servir de l'ordinateur. Et si on pense au même OS, pour les serveur, tip-top, mais comme station de travail...
Personnellement j'utilise Linux exclusivement depuis 2 ans, je ne vois pas ce qu'il lui manque.
-- Quidquid latine dictum sit, altum sonatur
Le Sun, 30 May 2004 10:41:30 +0000, Cedric Blancher a écrit :
Ouais, mais le but, c'est quand même de se servir de l'ordinateur. Et si
on pense au même OS, pour les serveur, tip-top, mais comme station de
travail...
Personnellement j'utilise Linux exclusivement depuis 2 ans, je ne vois pas
ce qu'il lui manque.
Le Sun, 30 May 2004 10:41:30 +0000, Cedric Blancher a écrit :
Ouais, mais le but, c'est quand même de se servir de l'ordinateur. Et si on pense au même OS, pour les serveur, tip-top, mais comme station de travail...
Personnellement j'utilise Linux exclusivement depuis 2 ans, je ne vois pas ce qu'il lui manque.
