existe t il des parefeu applicatif (c'est comme ca qu'on dit ?) pour unix ?
Sous Unix tout court, ce n'est pas possibles, les API n'existent pas. Sous certains Unix, probablement ; sous Linux, par exemple, iptables a un module et une règle --cmd-owner.
Mais dans l'absolu, c'et une protection d'efficacité douteuse : il suffit qu'une application ait des droits d'accès pour que les autres tournant avec le même UID puissent en hériter, avec des ptrace ou équivalents bien sentis.
Thomas wrote in message
<fantome.forums.tDeContes-3DD364.13363902062005@news15-e.proxad.net>:
existe t il des parefeu applicatif (c'est comme ca qu'on dit ?) pour
unix ?
Sous Unix tout court, ce n'est pas possibles, les API n'existent pas. Sous
certains Unix, probablement ; sous Linux, par exemple, iptables a un module
et une règle --cmd-owner.
Mais dans l'absolu, c'et une protection d'efficacité douteuse : il suffit
qu'une application ait des droits d'accès pour que les autres tournant avec
le même UID puissent en hériter, avec des ptrace ou équivalents bien sentis.
existe t il des parefeu applicatif (c'est comme ca qu'on dit ?) pour unix ?
Sous Unix tout court, ce n'est pas possibles, les API n'existent pas. Sous certains Unix, probablement ; sous Linux, par exemple, iptables a un module et une règle --cmd-owner.
Mais dans l'absolu, c'et une protection d'efficacité douteuse : il suffit qu'une application ait des droits d'accès pour que les autres tournant avec le même UID puissent en hériter, avec des ptrace ou équivalents bien sentis.
Pascal Bourguignon
Nicolas George <nicolas$ writes:
Thomas wrote in message :
existe t il des parefeu applicatif (c'est comme ca qu'on dit ?) pour unix ?
Sous Unix tout court, ce n'est pas possibles, les API n'existent pas. Sous certains Unix, probablement ; sous Linux, par exemple, iptables a un module et une règle --cmd-owner.
Mais dans l'absolu, c'et une protection d'efficacité douteuse : il suffit qu'une application ait des droits d'accès pour que les autres tournant avec le même UID puissent en hériter, avec des ptrace ou équivalents bien sentis.
Mais peut-être peut-on se contenter du filtrage par port. Un port identifiant une application, par exemple, le 80 identifiant l'application "Web", le 25 l'application "Mail", etc.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. -- Georges W. Bush
Nicolas George <nicolas$george@salle-s.org> writes:
Thomas wrote in message
<fantome.forums.tDeContes-3DD364.13363902062005@news15-e.proxad.net>:
existe t il des parefeu applicatif (c'est comme ca qu'on dit ?) pour
unix ?
Sous Unix tout court, ce n'est pas possibles, les API n'existent pas. Sous
certains Unix, probablement ; sous Linux, par exemple, iptables a un module
et une règle --cmd-owner.
Mais dans l'absolu, c'et une protection d'efficacité douteuse : il suffit
qu'une application ait des droits d'accès pour que les autres tournant avec
le même UID puissent en hériter, avec des ptrace ou équivalents bien sentis.
Mais peut-être peut-on se contenter du filtrage par port. Un port
identifiant une application, par exemple, le 80 identifiant
l'application "Web", le 25 l'application "Mail", etc.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
existe t il des parefeu applicatif (c'est comme ca qu'on dit ?) pour unix ?
Sous Unix tout court, ce n'est pas possibles, les API n'existent pas. Sous certains Unix, probablement ; sous Linux, par exemple, iptables a un module et une règle --cmd-owner.
Mais dans l'absolu, c'et une protection d'efficacité douteuse : il suffit qu'une application ait des droits d'accès pour que les autres tournant avec le même UID puissent en hériter, avec des ptrace ou équivalents bien sentis.
Mais peut-être peut-on se contenter du filtrage par port. Un port identifiant une application, par exemple, le 80 identifiant l'application "Web", le 25 l'application "Mail", etc.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. -- Georges W. Bush
Stephane Dupille
Mais peut-être peut-on se contenter du filtrage par port. Un port identifiant une application, par exemple, le 80 identifiant l'application "Web", le 25 l'application "Mail", etc.
Le filtrage par port, c'est parfait quand on veut protéger un serveur. Car dans ce cas, on connait l'association port/applicatif.
Si on veut protéger une machine de bureau, ou plus généralement une machine qui ne fait tourner que des applicatifs clients, alors le filtrage par port est inefficace, et très difficile à mettre en ½uvre. C'est dans ce cas là que le filtrage applicatif prend tout son sens.
-- les AAV-type de l'UVV sont prévus pour une gestion semi-manuelle et semi-automatique. ma gestion du vote est 100 % manuelle afin de garantir un bon déroulement du scrutin -+- BenC in <http://www.le-gnu.net>- Neuneu ne manque pas de Coffe -+-
Mais peut-être peut-on se contenter du filtrage par port. Un port
identifiant une application, par exemple, le 80 identifiant
l'application "Web", le 25 l'application "Mail", etc.
Le filtrage par port, c'est parfait quand on veut protéger un
serveur. Car dans ce cas, on connait l'association port/applicatif.
Si on veut protéger une machine de bureau, ou plus généralement une
machine qui ne fait tourner que des applicatifs clients, alors le
filtrage par port est inefficace, et très difficile à mettre en ½uvre.
C'est dans ce cas là que le filtrage applicatif prend tout son sens.
--
les AAV-type de l'UVV sont prévus pour une gestion semi-manuelle et
semi-automatique. ma gestion du vote est 100 % manuelle afin de
garantir un bon déroulement du scrutin
-+- BenC in <http://www.le-gnu.net>- Neuneu ne manque pas de Coffe -+-
Mais peut-être peut-on se contenter du filtrage par port. Un port identifiant une application, par exemple, le 80 identifiant l'application "Web", le 25 l'application "Mail", etc.
Le filtrage par port, c'est parfait quand on veut protéger un serveur. Car dans ce cas, on connait l'association port/applicatif.
Si on veut protéger une machine de bureau, ou plus généralement une machine qui ne fait tourner que des applicatifs clients, alors le filtrage par port est inefficace, et très difficile à mettre en ½uvre. C'est dans ce cas là que le filtrage applicatif prend tout son sens.
-- les AAV-type de l'UVV sont prévus pour une gestion semi-manuelle et semi-automatique. ma gestion du vote est 100 % manuelle afin de garantir un bon déroulement du scrutin -+- BenC in <http://www.le-gnu.net>- Neuneu ne manque pas de Coffe -+-
Vincent Bernat
OoO Peu avant le début de l'après-midi du jeudi 02 juin 2005, vers 13:36, Thomas disait:
existe t il des parefeu applicatif (c'est comme ca qu'on dit ?) pour unix ?
cad, un parfeu qui filtre les flux sortants par application, comme le fait kerio sous windows
Tu peux regarder systrace, c'est plus général qu'un pare-feu applicatif car cela surveille absolument tous les appels systèmes. C'est disponible au moins sous Linux et sous OpenBSD.
A partir de ça, il existe des firewalls applicatifs, comme Fireflier : <URL:http://fireflier.sf.net>
L'autre solution pour Linux, c'est d'utiliser la cible QUEUE de Netfilter qui permet de valider les paquets en userland. C'est utilisé par NuFW (qui n'est pas un firewall applicatif, mais un firewall authentifiant). Je ne connais pas de firewall applicatif qui utilise ceci, mais je n'ai pas beaucoup cherché. <URL:http://www.nufw.org> -- J'a -+- PM in GGE - Je vous ai tous grillés sur cette réponse -+-
OoO Peu avant le début de l'après-midi du jeudi 02 juin 2005, vers
13:36, Thomas <fantome.forums.tDeContes@free.fr> disait:
existe t il des parefeu applicatif (c'est comme ca qu'on dit ?) pour
unix ?
cad, un parfeu qui filtre les flux sortants par application,
comme le fait kerio sous windows
Tu peux regarder systrace, c'est plus général qu'un pare-feu
applicatif car cela surveille absolument tous les appels
systèmes. C'est disponible au moins sous Linux et sous OpenBSD.
A partir de ça, il existe des firewalls applicatifs, comme Fireflier :
<URL:http://fireflier.sf.net>
L'autre solution pour Linux, c'est d'utiliser la cible QUEUE de
Netfilter qui permet de valider les paquets en userland. C'est utilisé
par NuFW (qui n'est pas un firewall applicatif, mais un firewall
authentifiant). Je ne connais pas de firewall applicatif qui utilise
ceci, mais je n'ai pas beaucoup cherché.
<URL:http://www.nufw.org>
--
J'a
-+- PM in GGE - Je vous ai tous grillés sur cette réponse -+-
OoO Peu avant le début de l'après-midi du jeudi 02 juin 2005, vers 13:36, Thomas disait:
existe t il des parefeu applicatif (c'est comme ca qu'on dit ?) pour unix ?
cad, un parfeu qui filtre les flux sortants par application, comme le fait kerio sous windows
Tu peux regarder systrace, c'est plus général qu'un pare-feu applicatif car cela surveille absolument tous les appels systèmes. C'est disponible au moins sous Linux et sous OpenBSD.
A partir de ça, il existe des firewalls applicatifs, comme Fireflier : <URL:http://fireflier.sf.net>
L'autre solution pour Linux, c'est d'utiliser la cible QUEUE de Netfilter qui permet de valider les paquets en userland. C'est utilisé par NuFW (qui n'est pas un firewall applicatif, mais un firewall authentifiant). Je ne connais pas de firewall applicatif qui utilise ceci, mais je n'ai pas beaucoup cherché. <URL:http://www.nufw.org> -- J'a -+- PM in GGE - Je vous ai tous grillés sur cette réponse -+-
Thomas Baruchel
Le 03-06-2005, Stephane Dupille <sdupille+ a écrit :
Si on veut protéger une machine de bureau, ou plus généralement une machine qui ne fait tourner que des applicatifs clients, alors le filtrage par port est inefficace, et très difficile à mettre en ½uvre. C'est dans ce cas là que le filtrage applicatif prend tout son sens.
Je viens de lire cela après m'être donné la peine d'installer IPF sur ma FreeBSD :-( Pourquoi est-ce inefficace ? Je bloque tous les appels entrants (sauf pour le DHCP) et bloque tous les appels sortants saufs sur les quelques ports correspondant à un usage courant (POP3, SMTP, NNTP, HTTP, etc.) et lorsque ces ports n'ont aucune raison d'être utilisés pour des machines distantes absentes d'une brève liste (serveurs POP, SMTP, NNTP de mon FAI) je bloque également tout sauf ces quelques situations. Je pensais avoir fait quelque chose de solide :-( Pourquoi est-ce inefficace ?
Cordialement,
-- Thomas Baruchel
Le 03-06-2005, Stephane Dupille <sdupille+news@teaser.fr> a écrit :
Si on veut protéger une machine de bureau, ou plus généralement une
machine qui ne fait tourner que des applicatifs clients, alors le
filtrage par port est inefficace, et très difficile à mettre en ½uvre.
C'est dans ce cas là que le filtrage applicatif prend tout son sens.
Je viens de lire cela après m'être donné la peine d'installer IPF sur
ma FreeBSD :-( Pourquoi est-ce inefficace ? Je bloque tous les appels
entrants (sauf pour le DHCP) et bloque tous les appels sortants saufs
sur les quelques ports correspondant à un usage courant (POP3, SMTP,
NNTP, HTTP, etc.) et lorsque ces ports n'ont aucune raison d'être
utilisés pour des machines distantes absentes d'une brève liste
(serveurs POP, SMTP, NNTP de mon FAI) je bloque également tout sauf
ces quelques situations. Je pensais avoir fait quelque chose de solide :-(
Pourquoi est-ce inefficace ?
Le 03-06-2005, Stephane Dupille <sdupille+ a écrit :
Si on veut protéger une machine de bureau, ou plus généralement une machine qui ne fait tourner que des applicatifs clients, alors le filtrage par port est inefficace, et très difficile à mettre en ½uvre. C'est dans ce cas là que le filtrage applicatif prend tout son sens.
Je viens de lire cela après m'être donné la peine d'installer IPF sur ma FreeBSD :-( Pourquoi est-ce inefficace ? Je bloque tous les appels entrants (sauf pour le DHCP) et bloque tous les appels sortants saufs sur les quelques ports correspondant à un usage courant (POP3, SMTP, NNTP, HTTP, etc.) et lorsque ces ports n'ont aucune raison d'être utilisés pour des machines distantes absentes d'une brève liste (serveurs POP, SMTP, NNTP de mon FAI) je bloque également tout sauf ces quelques situations. Je pensais avoir fait quelque chose de solide :-( Pourquoi est-ce inefficace ?
Cordialement,
-- Thomas Baruchel
Stephane Dupille
Je viens de lire cela après m'être donné la peine d'installer IPF sur ma FreeBSD :-( Pourquoi est-ce inefficace ? Je bloque tous les appels entrants (sauf pour le DHCP) et bloque tous les appels sortants saufs sur les quelques ports correspondant à un usage courant (POP3, SMTP, NNTP, HTTP, etc.) et lorsque ces ports n'ont aucune raison d'être utilisés pour des machines distantes absentes d'une brève liste (serveurs POP, SMTP, NNTP de mon FAI) je bloque également tout sauf ces quelques situations.
Bonne idée.
Je pensais avoir fait quelque chose de solide :-(
Oui, c'est solide, mais incomplet.
Pourquoi est-ce inefficace ?
Parce que le but du firewall n'est pas seulement de filtrer ce qui entre, mais aussi ce qui sort. Hors, sur une machine de bureau, on peut vouloir faire sortir des requêtes web. Et donc, ouvrir les connexions depuis la machine vers le reste du monde, sur le port 80.
Hors, cette ouverture permet non seulement l'accès au web, mais aussi à n'importe quoi : il n'y a pas que du HTTP qui peut passer sur le port 80.
Pour se prémunir de ça, il faut soit utiliser un proxy par port ouvert, qui va vérifier le contenu de ce qui est échangé, soit utiliser un proxy applicatif, qui permet un boulot plus fin que le simple filtrage de ports. Par exemple, on peut vouloir interdire que le lecteur de mail échange du contenu web par le port 80.
L'intérêt du filtre applicatif sur une machine desktop n'est pas de sécuriser la machine (car un FW classique suffit, comme tu l'as fait), mais surtout de se prémunir de ce qui va sortir de la machine, et en particulier pouvoir filtrer les spywares éventuels.
cdlt, -- C>Faisons le point une bonne fois. tu m'as un peu irrité en affirmant C>que le point G n'existait pas. Je peux te le prouver si tu veux. Te fatigue pas, j'ai un clitoris qui fait l'affaire. -+- GL in <http://www.le-gnu.net> - Toutes options montées en série -+-
Je viens de lire cela après m'être donné la peine d'installer IPF sur
ma FreeBSD :-( Pourquoi est-ce inefficace ? Je bloque tous les appels
entrants (sauf pour le DHCP) et bloque tous les appels sortants saufs
sur les quelques ports correspondant à un usage courant (POP3, SMTP,
NNTP, HTTP, etc.) et lorsque ces ports n'ont aucune raison d'être
utilisés pour des machines distantes absentes d'une brève liste
(serveurs POP, SMTP, NNTP de mon FAI) je bloque également tout sauf
ces quelques situations.
Bonne idée.
Je pensais avoir fait quelque chose de solide :-(
Oui, c'est solide, mais incomplet.
Pourquoi est-ce inefficace ?
Parce que le but du firewall n'est pas seulement de filtrer ce qui
entre, mais aussi ce qui sort. Hors, sur une machine de bureau, on
peut vouloir faire sortir des requêtes web. Et donc, ouvrir les
connexions depuis la machine vers le reste du monde, sur le port 80.
Hors, cette ouverture permet non seulement l'accès au web, mais
aussi à n'importe quoi : il n'y a pas que du HTTP qui peut passer sur
le port 80.
Pour se prémunir de ça, il faut soit utiliser un proxy par port
ouvert, qui va vérifier le contenu de ce qui est échangé, soit
utiliser un proxy applicatif, qui permet un boulot plus fin que le
simple filtrage de ports. Par exemple, on peut vouloir interdire que
le lecteur de mail échange du contenu web par le port 80.
L'intérêt du filtre applicatif sur une machine desktop n'est pas de
sécuriser la machine (car un FW classique suffit, comme tu l'as fait),
mais surtout de se prémunir de ce qui va sortir de la machine, et en
particulier pouvoir filtrer les spywares éventuels.
cdlt,
--
C>Faisons le point une bonne fois. tu m'as un peu irrité en affirmant
C>que le point G n'existait pas. Je peux te le prouver si tu veux.
Te fatigue pas, j'ai un clitoris qui fait l'affaire.
-+- GL in <http://www.le-gnu.net> - Toutes options montées en série -+-
Je viens de lire cela après m'être donné la peine d'installer IPF sur ma FreeBSD :-( Pourquoi est-ce inefficace ? Je bloque tous les appels entrants (sauf pour le DHCP) et bloque tous les appels sortants saufs sur les quelques ports correspondant à un usage courant (POP3, SMTP, NNTP, HTTP, etc.) et lorsque ces ports n'ont aucune raison d'être utilisés pour des machines distantes absentes d'une brève liste (serveurs POP, SMTP, NNTP de mon FAI) je bloque également tout sauf ces quelques situations.
Bonne idée.
Je pensais avoir fait quelque chose de solide :-(
Oui, c'est solide, mais incomplet.
Pourquoi est-ce inefficace ?
Parce que le but du firewall n'est pas seulement de filtrer ce qui entre, mais aussi ce qui sort. Hors, sur une machine de bureau, on peut vouloir faire sortir des requêtes web. Et donc, ouvrir les connexions depuis la machine vers le reste du monde, sur le port 80.
Hors, cette ouverture permet non seulement l'accès au web, mais aussi à n'importe quoi : il n'y a pas que du HTTP qui peut passer sur le port 80.
Pour se prémunir de ça, il faut soit utiliser un proxy par port ouvert, qui va vérifier le contenu de ce qui est échangé, soit utiliser un proxy applicatif, qui permet un boulot plus fin que le simple filtrage de ports. Par exemple, on peut vouloir interdire que le lecteur de mail échange du contenu web par le port 80.
L'intérêt du filtre applicatif sur une machine desktop n'est pas de sécuriser la machine (car un FW classique suffit, comme tu l'as fait), mais surtout de se prémunir de ce qui va sortir de la machine, et en particulier pouvoir filtrer les spywares éventuels.
cdlt, -- C>Faisons le point une bonne fois. tu m'as un peu irrité en affirmant C>que le point G n'existait pas. Je peux te le prouver si tu veux. Te fatigue pas, j'ai un clitoris qui fait l'affaire. -+- GL in <http://www.le-gnu.net> - Toutes options montées en série -+-
Thomas Baruchel
Le 03-06-2005, Stephane Dupille <sdupille+ a écrit :
Hors, cette ouverture permet non seulement l'accès au web, mais aussi à n'importe quoi : il n'y a pas que du HTTP qui peut passer sur le port 80.
Mais dans la pratique, quel genre de situation correspond à cela ? Un cheval de Troie déjà en place ? Puis-je sans m'en rendre compte (en utilisant un navigateur pour des besoins ordinaires) faire quelque chose qui créerait une faille dans la sécurité du système ? Quelle est la probabilité et quels sont les risques ?
-- Thomas Baruchel
Le 03-06-2005, Stephane Dupille <sdupille+news@teaser.fr> a écrit :
Hors, cette ouverture permet non seulement l'accès au web, mais
aussi à n'importe quoi : il n'y a pas que du HTTP qui peut passer sur
le port 80.
Mais dans la pratique, quel genre de situation correspond à cela ?
Un cheval de Troie déjà en place ? Puis-je sans m'en rendre compte
(en utilisant un navigateur pour des besoins ordinaires) faire
quelque chose qui créerait une faille dans la sécurité du système ?
Quelle est la probabilité et quels sont les risques ?
Le 03-06-2005, Stephane Dupille <sdupille+ a écrit :
Hors, cette ouverture permet non seulement l'accès au web, mais aussi à n'importe quoi : il n'y a pas que du HTTP qui peut passer sur le port 80.
Mais dans la pratique, quel genre de situation correspond à cela ? Un cheval de Troie déjà en place ? Puis-je sans m'en rendre compte (en utilisant un navigateur pour des besoins ordinaires) faire quelque chose qui créerait une faille dans la sécurité du système ? Quelle est la probabilité et quels sont les risques ?
-- Thomas Baruchel
Eric Masson
Thomas Baruchel writes:
Mais dans la pratique, quel genre de situation correspond à cela ?
Vers, spyware, trojan, rootkit.
Un cheval de Troie déjà en place ? Puis-je sans m'en rendre compte (en utilisant un navigateur pour des besoins ordinaires) faire quelque chose qui créerait une faille dans la sécurité du système ?
Les outils de chez Mozilla ont présenté les failles suivantes ces derniers temps : http://www.mozilla.org/projects/security/known-vulnerabilities.html
Donc, si une de ces failles a été exploitée, la compromission de la machine est tout à fait possible.
ipf permet l'implémentation d'une forme de filtrage applicatif en utilisant les fonctionnalités auth et preauth, voir : /usr/src/contrib/ipfilter/samples/userauth.c et les archives de la mailing list ipfilter.
Éric Masson
-- L'attitude qui consiste a rappeler a un contributeur que sa poste est contraire a la charte du NG, me parait pedante, anale et probablement aussi "hors-sujet". Ce qui m'enerve plus qu' une poste sur le TeX... -+- Dr NV in GNU : Les a(nale)ventures de Docteur Juste Tex. -+-
Thomas Baruchel <archaiesteron@laposte.net> writes:
Mais dans la pratique, quel genre de situation correspond à cela ?
Vers, spyware, trojan, rootkit.
Un cheval de Troie déjà en place ? Puis-je sans m'en rendre compte
(en utilisant un navigateur pour des besoins ordinaires) faire
quelque chose qui créerait une faille dans la sécurité du système ?
Les outils de chez Mozilla ont présenté les failles suivantes ces
derniers temps :
http://www.mozilla.org/projects/security/known-vulnerabilities.html
Donc, si une de ces failles a été exploitée, la compromission de la
machine est tout à fait possible.
ipf permet l'implémentation d'une forme de filtrage applicatif
en utilisant les fonctionnalités auth et preauth, voir :
/usr/src/contrib/ipfilter/samples/userauth.c
et les archives de la mailing list ipfilter.
Éric Masson
--
L'attitude qui consiste a rappeler a un contributeur que sa poste est
contraire a la charte du NG, me parait pedante, anale et probablement
aussi "hors-sujet". Ce qui m'enerve plus qu' une poste sur le TeX...
-+- Dr NV in GNU : Les a(nale)ventures de Docteur Juste Tex. -+-
Mais dans la pratique, quel genre de situation correspond à cela ?
Vers, spyware, trojan, rootkit.
Un cheval de Troie déjà en place ? Puis-je sans m'en rendre compte (en utilisant un navigateur pour des besoins ordinaires) faire quelque chose qui créerait une faille dans la sécurité du système ?
Les outils de chez Mozilla ont présenté les failles suivantes ces derniers temps : http://www.mozilla.org/projects/security/known-vulnerabilities.html
Donc, si une de ces failles a été exploitée, la compromission de la machine est tout à fait possible.
ipf permet l'implémentation d'une forme de filtrage applicatif en utilisant les fonctionnalités auth et preauth, voir : /usr/src/contrib/ipfilter/samples/userauth.c et les archives de la mailing list ipfilter.
Éric Masson
-- L'attitude qui consiste a rappeler a un contributeur que sa poste est contraire a la charte du NG, me parait pedante, anale et probablement aussi "hors-sujet". Ce qui m'enerve plus qu' une poste sur le TeX... -+- Dr NV in GNU : Les a(nale)ventures de Docteur Juste Tex. -+-
Stephane Dupille
'Lut Éric !
Mais dans la pratique, quel genre de situation correspond à cela ? Vers, spyware, trojan, rootkit.
Oui, entre autre joyeusetés. Sans compter le cas tout bête : si je met un firewall, c'est que je suis parano, et si je suis parano, alors il faut tout protéger. Il est hors de question dans ce cadre que mon lecteur de mail puisse se connecter sur le web. Et il n'a pas le droit de se connecter à autre chose que son serveur POP/IMAP.
Quitte à être parano, autant l'être totalement.
ipf permet l'implémentation d'une forme de filtrage applicatif en utilisant les fonctionnalités auth et preauth, voir : /usr/src/contrib/ipfilter/samples/userauth.c et les archives de la mailing list ipfilter.
Si jeune m'abuse, c'est un FW authentifiant, ça. Non ?
-- J'utilise Outlook Express comme serveur de news et de courrier. -+- Laury in GNU : Chez MS, le client est roi... des neuneux. -+-
'Lut Éric !
Mais dans la pratique, quel genre de situation correspond à cela ?
Vers, spyware, trojan, rootkit.
Oui, entre autre joyeusetés. Sans compter le cas tout bête : si je
met un firewall, c'est que je suis parano, et si je suis parano, alors
il faut tout protéger. Il est hors de question dans ce cadre que mon
lecteur de mail puisse se connecter sur le web. Et il n'a pas le droit
de se connecter à autre chose que son serveur POP/IMAP.
Quitte à être parano, autant l'être totalement.
ipf permet l'implémentation d'une forme de filtrage applicatif
en utilisant les fonctionnalités auth et preauth, voir :
/usr/src/contrib/ipfilter/samples/userauth.c
et les archives de la mailing list ipfilter.
Si jeune m'abuse, c'est un FW authentifiant, ça. Non ?
--
J'utilise Outlook Express comme serveur de news et de courrier.
-+- Laury in GNU : Chez MS, le client est roi... des neuneux. -+-
Mais dans la pratique, quel genre de situation correspond à cela ? Vers, spyware, trojan, rootkit.
Oui, entre autre joyeusetés. Sans compter le cas tout bête : si je met un firewall, c'est que je suis parano, et si je suis parano, alors il faut tout protéger. Il est hors de question dans ce cadre que mon lecteur de mail puisse se connecter sur le web. Et il n'a pas le droit de se connecter à autre chose que son serveur POP/IMAP.
Quitte à être parano, autant l'être totalement.
ipf permet l'implémentation d'une forme de filtrage applicatif en utilisant les fonctionnalités auth et preauth, voir : /usr/src/contrib/ipfilter/samples/userauth.c et les archives de la mailing list ipfilter.
Si jeune m'abuse, c'est un FW authentifiant, ça. Non ?
-- J'utilise Outlook Express comme serveur de news et de courrier. -+- Laury in GNU : Chez MS, le client est roi... des neuneux. -+-
Eric Masson
Stephane Dupille <sdupille+ writes:
'Lut Stéphane,
Oui, entre autre joyeusetés. Sans compter le cas tout bête : si je met un firewall, c'est que je suis parano, et si je suis parano, alors il faut tout protéger. Il est hors de question dans ce cadre que mon lecteur de mail puisse se connecter sur le web. Et il n'a pas le droit de se connecter à autre chose que son serveur POP/IMAP.
Quitte à être parano, autant l'être totalement.
Effectivement, c'est une solution parano :)
Si jeune m'abuse, c'est un FW authentifiant, ça. Non ?
Euh, comme ça, je te répondrais non, un fw authentifiant ce serait plutôt pf avec son shell authpf, mais bon je me gourres peut-être : http://www.openbsd.org/faq/pf/authpf.html
Dans le cas du mot clé auth sur une régle ipf, ipf passe le paquet à une appli userland qui va prendre la décision de pass/block.
Cette application, dans le cas d'un paquet émis par un processus local peut tout à fait déterminer quel processus est à l'origine du paquet et demander à l'utilisateur concerné quelle décision prendre quand au sort du paquet.
Avec un poil de taf, il doit être possible d'implémenter une interface Zone Alarm like pour gérer ce que les applications locales ont le droit de faire (le problème des performances de l'appli userland à laquelle se réfèrent les règles auth ne doit pas être négligeable)
Éric
-- j'ai découvert récemment les webcams, mais elles restent fixent. Quels réglages faut'il réaliser pour les voir en dynamiques ? -+-GT in : <http://www.le-gnu.net> - Silence, on tourne -+-
Oui, entre autre joyeusetés. Sans compter le cas tout bête : si je
met un firewall, c'est que je suis parano, et si je suis parano, alors
il faut tout protéger. Il est hors de question dans ce cadre que mon
lecteur de mail puisse se connecter sur le web. Et il n'a pas le droit
de se connecter à autre chose que son serveur POP/IMAP.
Quitte à être parano, autant l'être totalement.
Effectivement, c'est une solution parano :)
Si jeune m'abuse, c'est un FW authentifiant, ça. Non ?
Euh, comme ça, je te répondrais non, un fw authentifiant ce serait
plutôt pf avec son shell authpf, mais bon je me gourres peut-être :
http://www.openbsd.org/faq/pf/authpf.html
Dans le cas du mot clé auth sur une régle ipf, ipf passe le paquet à
une appli userland qui va prendre la décision de pass/block.
Cette application, dans le cas d'un paquet émis par un processus local
peut tout à fait déterminer quel processus est à l'origine du paquet et
demander à l'utilisateur concerné quelle décision prendre quand au sort
du paquet.
Avec un poil de taf, il doit être possible d'implémenter une interface
Zone Alarm like pour gérer ce que les applications locales ont le droit
de faire (le problème des performances de l'appli userland à laquelle se
réfèrent les règles auth ne doit pas être négligeable)
Éric
--
j'ai découvert récemment les webcams, mais elles restent fixent.
Quels réglages faut'il réaliser pour les voir en dynamiques ?
-+-GT in : <http://www.le-gnu.net> - Silence, on tourne -+-
Oui, entre autre joyeusetés. Sans compter le cas tout bête : si je met un firewall, c'est que je suis parano, et si je suis parano, alors il faut tout protéger. Il est hors de question dans ce cadre que mon lecteur de mail puisse se connecter sur le web. Et il n'a pas le droit de se connecter à autre chose que son serveur POP/IMAP.
Quitte à être parano, autant l'être totalement.
Effectivement, c'est une solution parano :)
Si jeune m'abuse, c'est un FW authentifiant, ça. Non ?
Euh, comme ça, je te répondrais non, un fw authentifiant ce serait plutôt pf avec son shell authpf, mais bon je me gourres peut-être : http://www.openbsd.org/faq/pf/authpf.html
Dans le cas du mot clé auth sur une régle ipf, ipf passe le paquet à une appli userland qui va prendre la décision de pass/block.
Cette application, dans le cas d'un paquet émis par un processus local peut tout à fait déterminer quel processus est à l'origine du paquet et demander à l'utilisateur concerné quelle décision prendre quand au sort du paquet.
Avec un poil de taf, il doit être possible d'implémenter une interface Zone Alarm like pour gérer ce que les applications locales ont le droit de faire (le problème des performances de l'appli userland à laquelle se réfèrent les règles auth ne doit pas être négligeable)
Éric
-- j'ai découvert récemment les webcams, mais elles restent fixent. Quels réglages faut'il réaliser pour les voir en dynamiques ? -+-GT in : <http://www.le-gnu.net> - Silence, on tourne -+-
