En fait, il me semble qu'un pare-feu n'est efficace que tant qu'il a des
privilèges strictement supérieurs à ceux déjà obtenus par l'attaquant. Je
me trompe ?
Inversement, ça veut donc dire qu'un pare-feu doit toujours s'exécuter avec
les privilèges les plus élevés possible. Je ne connais plus trop ouinedoze,
mais est-ce réellement ce qui s'y passe normalement ? (À l'époque où
j'utilisais, je ne faisais pas attention à qui était le propriétaire du
processus pare-feu. Aujourd'hui j'utilise linux où ça me paraît plus
clair : le filtrage semble intervenir directement au niveau du routage IP
dans du noyau.)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thierry
"mpg" a écrit dans le message de news: fk9bf8$297o$
Inversement, ça veut donc dire qu'un pare-feu doit toujours s'exécuter avec les privilèges les plus élevés possible.
Ben non, juste le niveau dont il a besoin.
Je ne connais plus trop ouinedoze, mais est-ce réellement ce qui s'y passe normalement ? (À l'époque où j'utilisais, je ne faisais pas attention à qui était le propriétaire du processus pare-feu
En general il n'y a pas un unique processus mais : - une interface pour l'utilisateur avec peu de privileges necessaires qui cause à - un service au sens windows qui tourne en general sour le compte "System" qui - pilote un driver appliquant les régles definies et remontant les alertes.
"mpg" <manuel.pg@free.fr> a écrit dans le message de news:
fk9bf8$297o$2@talisker.lacave.net...
Inversement, ça veut donc dire qu'un pare-feu doit toujours s'exécuter
avec
les privilèges les plus élevés possible.
Ben non, juste le niveau dont il a besoin.
Je ne connais plus trop ouinedoze,
mais est-ce réellement ce qui s'y passe normalement ? (À l'époque où
j'utilisais, je ne faisais pas attention à qui était le propriétaire du
processus pare-feu
En general il n'y a pas un unique processus mais :
- une interface pour l'utilisateur avec peu de privileges necessaires qui
cause à
- un service au sens windows qui tourne en general sour le compte "System"
qui
- pilote un driver appliquant les régles definies et remontant les alertes.
"mpg" a écrit dans le message de news: fk9bf8$297o$
Inversement, ça veut donc dire qu'un pare-feu doit toujours s'exécuter avec les privilèges les plus élevés possible.
Ben non, juste le niveau dont il a besoin.
Je ne connais plus trop ouinedoze, mais est-ce réellement ce qui s'y passe normalement ? (À l'époque où j'utilisais, je ne faisais pas attention à qui était le propriétaire du processus pare-feu
En general il n'y a pas un unique processus mais : - une interface pour l'utilisateur avec peu de privileges necessaires qui cause à - un service au sens windows qui tourne en general sour le compte "System" qui - pilote un driver appliquant les régles definies et remontant les alertes.
mpg
Le (on) mercredi 19 décembre 2007 12:44, Thierry a écrit (wrote) :
Inversement, ça veut donc dire qu'un pare-feu doit toujours s'exécuter avec les privilèges les plus élevés possible.
Ben non, juste le niveau dont il a besoin.
Oui, j'avais vu les choses de façon pas très fines sur ce coup.
En general il n'y a pas un unique processus mais : - une interface pour l'utilisateur avec peu de privileges necessaires qui cause à - un service au sens windows qui tourne en general sour le compte "System" qui - pilote un driver appliquant les régles definies et remontant les alertes.
Vu. Du coup, je me demandais, si un utilisateur logué en administrateur exécute une application malveillante, peut-on imaginer que celle-ci commence par stopper le « service au sens windows » qui pilote le driver, et prenne elle-même la main sur le pilotage de ce driver, à son avantage bien sûr ? D'un point de vue théorique ça me semble possible, est-ce que c'est le cas, et si oui, cela est-il réaliste en pratique ?
C'est que récemment, je discutais avec un utilisateur de windows qui se loggue toujours en admin mais s'estime « protégé » parce qu'il a installé l'internet security suite de je ne sais quel éditeur de logiciel. J'essayais de le convaincre que ce n'est pas raisonnable, et j'ai pensé à cet argument : avais-je tort ?
Manuel.
Le (on) mercredi 19 décembre 2007 12:44, Thierry a écrit (wrote) :
Inversement, ça veut donc dire qu'un pare-feu doit toujours s'exécuter
avec
les privilèges les plus élevés possible.
Ben non, juste le niveau dont il a besoin.
Oui, j'avais vu les choses de façon pas très fines sur ce coup.
En general il n'y a pas un unique processus mais :
- une interface pour l'utilisateur avec peu de privileges necessaires qui
cause à
- un service au sens windows qui tourne en general sour le compte "System"
qui
- pilote un driver appliquant les régles definies et remontant les
alertes.
Vu. Du coup, je me demandais, si un utilisateur logué en administrateur
exécute une application malveillante, peut-on imaginer que celle-ci
commence par stopper le « service au sens windows » qui pilote le driver,
et prenne elle-même la main sur le pilotage de ce driver, à son avantage
bien sûr ? D'un point de vue théorique ça me semble possible, est-ce que
c'est le cas, et si oui, cela est-il réaliste en pratique ?
C'est que récemment, je discutais avec un utilisateur de windows qui se
loggue toujours en admin mais s'estime « protégé » parce qu'il a installé
l'internet security suite de je ne sais quel éditeur de logiciel.
J'essayais de le convaincre que ce n'est pas raisonnable, et j'ai pensé à
cet argument : avais-je tort ?
Le (on) mercredi 19 décembre 2007 12:44, Thierry a écrit (wrote) :
Inversement, ça veut donc dire qu'un pare-feu doit toujours s'exécuter avec les privilèges les plus élevés possible.
Ben non, juste le niveau dont il a besoin.
Oui, j'avais vu les choses de façon pas très fines sur ce coup.
En general il n'y a pas un unique processus mais : - une interface pour l'utilisateur avec peu de privileges necessaires qui cause à - un service au sens windows qui tourne en general sour le compte "System" qui - pilote un driver appliquant les régles definies et remontant les alertes.
Vu. Du coup, je me demandais, si un utilisateur logué en administrateur exécute une application malveillante, peut-on imaginer que celle-ci commence par stopper le « service au sens windows » qui pilote le driver, et prenne elle-même la main sur le pilotage de ce driver, à son avantage bien sûr ? D'un point de vue théorique ça me semble possible, est-ce que c'est le cas, et si oui, cela est-il réaliste en pratique ?
C'est que récemment, je discutais avec un utilisateur de windows qui se loggue toujours en admin mais s'estime « protégé » parce qu'il a installé l'internet security suite de je ne sais quel éditeur de logiciel. J'essayais de le convaincre que ce n'est pas raisonnable, et j'ai pensé à cet argument : avais-je tort ?
Manuel.
Aris
Bonjour,
Vu. Du coup, je me demandais, si un utilisateur logué en administrateur exécute une application malveillante, peut-on imaginer que celle-ci commence par stopper le « service au sens windows » qui pilote le driver, et prenne elle-même la main sur le pilotage de ce driver, à son avantage bien sûr ? D'un point de vue théorique ça me semble possible, est-ce que c'est le cas, et si oui, cela est-il réaliste en pratique ?
Totalement possible.
C'est que récemment, je discutais avec un utilisateur de windows qui se loggue toujours en admin mais s'estime « protégé » parce qu'il a installé l'internet security suite de je ne sais quel éditeur de logiciel. J'essayais de le convaincre que ce n'est pas raisonnable, et j'ai pensé à cet argument : avais-je tort ? A partir du moment où une application malveillante s'execute en
administrateur, la machine est perdue. Il faut la formater et reinstaller avec des backups sains. L'histoire d'internet security machin sert à empecher des programmes malveillants de s'executer. Comme detecter un programme malveillant est un problème impossible (indécidable), et que tout utilisateur qui se respecte finit forcement par un jour vouloir installer un screensaver harry potter ou star wars, il executera un programme venant d'internet.
Son antivirus ne le protège que des menaces connues et encore. Se logguer en tant qu'utilisateur non privilégié aide à ne pas se faire infecter (malware qui ne fonctionne qu'en tant qu'administrateur) mais surtout à nettoyer les degats après infection.
Bref, si il veut être "protégé" il n'y a qu'une seule solution, c'est tirer la prise.
Manuel.
Bonjour,
Vu. Du coup, je me demandais, si un utilisateur logué en administrateur
exécute une application malveillante, peut-on imaginer que celle-ci
commence par stopper le « service au sens windows » qui pilote le driver,
et prenne elle-même la main sur le pilotage de ce driver, à son avantage
bien sûr ? D'un point de vue théorique ça me semble possible, est-ce que
c'est le cas, et si oui, cela est-il réaliste en pratique ?
Totalement possible.
C'est que récemment, je discutais avec un utilisateur de windows qui se
loggue toujours en admin mais s'estime « protégé » parce qu'il a installé
l'internet security suite de je ne sais quel éditeur de logiciel.
J'essayais de le convaincre que ce n'est pas raisonnable, et j'ai pensé à
cet argument : avais-je tort ?
A partir du moment où une application malveillante s'execute en
administrateur, la machine est perdue. Il faut la formater et
reinstaller avec des backups sains.
L'histoire d'internet security machin sert à empecher des programmes
malveillants de s'executer. Comme detecter un programme malveillant est
un problème impossible (indécidable), et que tout utilisateur qui se
respecte finit forcement par un jour vouloir installer un screensaver
harry potter ou star wars, il executera un programme venant d'internet.
Son antivirus ne le protège que des menaces connues et encore. Se
logguer en tant qu'utilisateur non privilégié aide à ne pas se faire
infecter (malware qui ne fonctionne qu'en tant qu'administrateur) mais
surtout à nettoyer les degats après infection.
Bref, si il veut être "protégé" il n'y a qu'une seule solution, c'est
tirer la prise.
Vu. Du coup, je me demandais, si un utilisateur logué en administrateur exécute une application malveillante, peut-on imaginer que celle-ci commence par stopper le « service au sens windows » qui pilote le driver, et prenne elle-même la main sur le pilotage de ce driver, à son avantage bien sûr ? D'un point de vue théorique ça me semble possible, est-ce que c'est le cas, et si oui, cela est-il réaliste en pratique ?
Totalement possible.
C'est que récemment, je discutais avec un utilisateur de windows qui se loggue toujours en admin mais s'estime « protégé » parce qu'il a installé l'internet security suite de je ne sais quel éditeur de logiciel. J'essayais de le convaincre que ce n'est pas raisonnable, et j'ai pensé à cet argument : avais-je tort ? A partir du moment où une application malveillante s'execute en
administrateur, la machine est perdue. Il faut la formater et reinstaller avec des backups sains. L'histoire d'internet security machin sert à empecher des programmes malveillants de s'executer. Comme detecter un programme malveillant est un problème impossible (indécidable), et que tout utilisateur qui se respecte finit forcement par un jour vouloir installer un screensaver harry potter ou star wars, il executera un programme venant d'internet.
Son antivirus ne le protège que des menaces connues et encore. Se logguer en tant qu'utilisateur non privilégié aide à ne pas se faire infecter (malware qui ne fonctionne qu'en tant qu'administrateur) mais surtout à nettoyer les degats après infection.
Bref, si il veut être "protégé" il n'y a qu'une seule solution, c'est tirer la prise.
Manuel.
Thierry
"mpg" a écrit dans le message de news: fkggaa$lvk$
(réponse tardive, mais puisque le fil a été relancé..)
Vu. Du coup, je me demandais, si un utilisateur logué en administrateur exécute une application malveillante, peut-on imaginer que celle-ci commence par stopper le « service au sens windows » qui pilote le driver, et prenne elle-même la main sur le pilotage de ce driver, à son avantage bien sûr ?
Si l'utilisateur est admin l'appli malveillante peut tout faire, donc arreter le FW... Sauf si un anti virus la reconnait et la bloque.
C'est que récemment, je discutais avec un utilisateur de windows qui se loggue toujours en admin mais s'estime « protégé » parce qu'il a installé l'internet security suite de je ne sais quel éditeur de logiciel. J'essayais de le convaincre que ce n'est pas raisonnable, et j'ai pensé à cet argument : avais-je tort ?
ISS doit contenir un anti virus.. Je ne sais pas ce qu'il vaut et me méfie en general de ces usines a gaz qui pretendent pourvoir "sécuriser" le PC dans toutes les conditions mais qu'au final on ne sait pas trop ce qu'elles font. Donc dans le doute : bosser en utilisateur simple, lancer une console en tant qu'admin et y lancer les applis qui ont besoins de droits.
"mpg" <manuel.pg@free.fr> a écrit dans le message de news:
fkggaa$lvk$1@talisker.lacave.net...
(réponse tardive, mais puisque le fil a été relancé..)
Vu. Du coup, je me demandais, si un utilisateur logué en administrateur
exécute une application malveillante, peut-on imaginer que celle-ci
commence par stopper le « service au sens windows » qui pilote le driver,
et prenne elle-même la main sur le pilotage de ce driver, à son avantage
bien sûr ?
Si l'utilisateur est admin l'appli malveillante peut tout faire, donc
arreter le FW...
Sauf si un anti virus la reconnait et la bloque.
C'est que récemment, je discutais avec un utilisateur de windows qui se
loggue toujours en admin mais s'estime « protégé » parce qu'il a installé
l'internet security suite de je ne sais quel éditeur de logiciel.
J'essayais de le convaincre que ce n'est pas raisonnable, et j'ai pensé à
cet argument : avais-je tort ?
ISS doit contenir un anti virus.. Je ne sais pas ce qu'il vaut et me méfie
en general de ces usines a gaz qui pretendent pourvoir "sécuriser" le PC
dans toutes les conditions mais qu'au final on ne sait pas trop ce qu'elles
font.
Donc dans le doute : bosser en utilisateur simple, lancer une console en
tant qu'admin et y lancer les applis qui ont besoins de droits.
"mpg" a écrit dans le message de news: fkggaa$lvk$
(réponse tardive, mais puisque le fil a été relancé..)
Vu. Du coup, je me demandais, si un utilisateur logué en administrateur exécute une application malveillante, peut-on imaginer que celle-ci commence par stopper le « service au sens windows » qui pilote le driver, et prenne elle-même la main sur le pilotage de ce driver, à son avantage bien sûr ?
Si l'utilisateur est admin l'appli malveillante peut tout faire, donc arreter le FW... Sauf si un anti virus la reconnait et la bloque.
C'est que récemment, je discutais avec un utilisateur de windows qui se loggue toujours en admin mais s'estime « protégé » parce qu'il a installé l'internet security suite de je ne sais quel éditeur de logiciel. J'essayais de le convaincre que ce n'est pas raisonnable, et j'ai pensé à cet argument : avais-je tort ?
ISS doit contenir un anti virus.. Je ne sais pas ce qu'il vaut et me méfie en general de ces usines a gaz qui pretendent pourvoir "sécuriser" le PC dans toutes les conditions mais qu'au final on ne sait pas trop ce qu'elles font. Donc dans le doute : bosser en utilisateur simple, lancer une console en tant qu'admin et y lancer les applis qui ont besoins de droits.
Malcom
En fait, le privilège du pare-feu n'influe pas pour l'attaque "entrante". Le privilège influe pour l'attaque sortante une fois la machine compromise par une faille de sécurité.
Oupala ! que neni ! je me permets de rapeller que le pare-feu est un logiciel comme les autres soumis aux même imperfections de codage (1 faille toutes les 1000 lignes de codes en moyenne). Par conséquent, si une faille est découverte dans l'interprétation effectuée par le pare- feu du trafic réseau, on peut très bien imaginer la mise en oeuvre d'un exploit permettant l'exécution d'un code malveillant avec les droits utilisés par le pare-feu. C'est pour cela que les analiseurs de trames de haut niveau (types Wireshark/ethereal) ne doivent pas être exécutés sous les droits root. On conseille d'effectuer la capture avec des utilitaires basics et surs comme tcpdump puis d'effectuer ensuite l'analyse des trames avec Wireshark (plusieurs vulnérabilités ont été découvertes dans ce logiciel). C'est également pour cela que des communautés réputées en sécurité comme OpenBSD refusent catégoriquement de mélanger les genres en ajoutant des fonctionnalités en couche haute à leur firewall (PaquetFilter qui se contente de travailler sur la couche IP un point c'est tout...).
Maintenant, il est évident que si le code malveillant (voir l'utilisateur malveillant...) est déjà installé sur la machine avec les droits administrateurs, que ton pare-feu soit en user-mode ou kernel-mode ne changera rien au fait qu'il sera facile de le désactiver ! Le problème de se connecter en administrateur c'est que si il double- clik sur un code malveillant par mégarde, celui-ci aura tout loisir de s'installer sur son PC et de l'infecter. Tandis qu'en tant que simple utilisateur, on peut espérer que la protection Windows protège le système (on peut rêver...). Enfin en tout cas c'est ce qui se passe sous Unix...
En fait, le privilège du pare-feu n'influe pas pour l'attaque "entrante".
Le privilège influe pour l'attaque sortante une fois la machine compromise
par une faille de sécurité.
Oupala ! que neni ! je me permets de rapeller que le pare-feu est un
logiciel comme les autres soumis aux même imperfections de codage (1
faille toutes les 1000 lignes de codes en moyenne). Par conséquent, si
une faille est découverte dans l'interprétation effectuée par le pare-
feu du trafic réseau, on peut très bien imaginer la mise en oeuvre
d'un exploit permettant l'exécution d'un code malveillant avec les
droits utilisés par le pare-feu.
C'est pour cela que les analiseurs de trames de haut niveau (types
Wireshark/ethereal) ne doivent pas être exécutés sous les droits root.
On conseille d'effectuer la capture avec des utilitaires basics et
surs comme tcpdump puis d'effectuer ensuite l'analyse des trames avec
Wireshark (plusieurs vulnérabilités ont été découvertes dans ce
logiciel).
C'est également pour cela que des communautés réputées en sécurité
comme OpenBSD refusent catégoriquement de mélanger les genres en
ajoutant des fonctionnalités en couche haute à leur firewall
(PaquetFilter qui se contente de travailler sur la couche IP un point
c'est tout...).
Maintenant, il est évident que si le code malveillant (voir
l'utilisateur malveillant...) est déjà installé sur la machine avec
les droits administrateurs, que ton pare-feu soit en user-mode ou
kernel-mode ne changera rien au fait qu'il sera facile de le
désactiver !
Le problème de se connecter en administrateur c'est que si il double-
clik sur un code malveillant par mégarde, celui-ci aura tout loisir de
s'installer sur son PC et de l'infecter. Tandis qu'en tant que simple
utilisateur, on peut espérer que la protection Windows protège le
système (on peut rêver...). Enfin en tout cas c'est ce qui se passe
sous Unix...
En fait, le privilège du pare-feu n'influe pas pour l'attaque "entrante". Le privilège influe pour l'attaque sortante une fois la machine compromise par une faille de sécurité.
Oupala ! que neni ! je me permets de rapeller que le pare-feu est un logiciel comme les autres soumis aux même imperfections de codage (1 faille toutes les 1000 lignes de codes en moyenne). Par conséquent, si une faille est découverte dans l'interprétation effectuée par le pare- feu du trafic réseau, on peut très bien imaginer la mise en oeuvre d'un exploit permettant l'exécution d'un code malveillant avec les droits utilisés par le pare-feu. C'est pour cela que les analiseurs de trames de haut niveau (types Wireshark/ethereal) ne doivent pas être exécutés sous les droits root. On conseille d'effectuer la capture avec des utilitaires basics et surs comme tcpdump puis d'effectuer ensuite l'analyse des trames avec Wireshark (plusieurs vulnérabilités ont été découvertes dans ce logiciel). C'est également pour cela que des communautés réputées en sécurité comme OpenBSD refusent catégoriquement de mélanger les genres en ajoutant des fonctionnalités en couche haute à leur firewall (PaquetFilter qui se contente de travailler sur la couche IP un point c'est tout...).
Maintenant, il est évident que si le code malveillant (voir l'utilisateur malveillant...) est déjà installé sur la machine avec les droits administrateurs, que ton pare-feu soit en user-mode ou kernel-mode ne changera rien au fait qu'il sera facile de le désactiver ! Le problème de se connecter en administrateur c'est que si il double- clik sur un code malveillant par mégarde, celui-ci aura tout loisir de s'installer sur son PC et de l'infecter. Tandis qu'en tant que simple utilisateur, on peut espérer que la protection Windows protège le système (on peut rêver...). Enfin en tout cas c'est ce qui se passe sous Unix...
