Linux : controler les applications accedant au reseau ?
2 réponses
Arnaud ARZUFFI
Salut !
Je suis presque entièrement satisfait de la solution IPtables (Linux) : elle
permet efficacement de filtrer les paquets entrants et sortants, définir
des ensembles de machines locales ou distantes et leur appliquer des regles
spécifiques... Cependant, imaginons le scénario suivant : un utilisateur de
la machine télécharge un programme malveillant, l'installe et l'execute...
2 possibilites :
1. le programme essaie de devenir serveur sur un port spécifique inutilisé
par les serveurs autorisés sur cette machine ; alors IPtables bloquera
cette tentative (arretez moi si je me trompe ?)
2. le programme essaie de devenir serveur (par exemple) sur le port 22, et
un serveur SSH est autorise sur cette machine ; IPtables l'empechera pas,
et le programme pourra envoyer des informations vers une machine distante
!!
Comment configurer IPtables (ou alors quel outil utiliser) pour configurer
des filtres par application en supplement des filtres par ports
"classiques" ?
D'ailleurs, hormis l'aspect sécurité, je trouve que cette possibilité
pratique... Une application souhaite devenir serveur (un logiciel de
messagerie instantanee pour un transfert de fichier par exemple) :
l'utilisateur décide : autoriser, refuser ? pour cette session, toujours,
jamais ? ... Ou alors cette solution séduisante présente un problème de
sécurité énorme auquel j'aurais pas réfléchi ?
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
Xavier Henner
Salut !
Je suis presque entièrement satisfait de la solution IPtables (Linux) : elle permet efficacement de filtrer les paquets entrants et sortants, définir des ensembles de machines locales ou distantes et leur appliquer des regles spécifiques... Cependant, imaginons le scénario suivant : un utilisateur de la machine télécharge un programme malveillant, l'installe et l'execute... 2 possibilites :
1. le programme essaie de devenir serveur sur un port spécifique inutilisé par les serveurs autorisés sur cette machine ; alors IPtables bloquera cette tentative (arretez moi si je me trompe ?)
non IPTable n'empeche pas le bind(). Par contre, il peut interdire les paquets entrants qui viennent vers ce port.
2. le programme essaie de devenir serveur (par exemple) sur le port 22,
pour ca, il faut etre root, ce qui limite.
et un serveur SSH est autorise sur cette machine ; IPtables l'empechera pas, et le programme pourra envoyer des informations vers une machine distante
non, il pourra recevoir des connexions de l'extérieur.
pour sortir, tout dépend de la configuration iptables mise en place.
sur une machine avec conf parano par défaut (toute connexion entrante bloquée, toute connexion sortante bloquée) et des regles utilisant le state et jouant sur le sens de connexion, on peut autoriser certains serveurs, et donc pour les port > 1024, il faut faire gaffe a ce que des serveurs soient bien en place et autoriser les utilisateurs a utiliser tel ou tel service.
D'ailleurs, hormis l'aspect sécurité, je trouve que cette possibilité pratique... Une application souhaite devenir serveur (un logiciel de messagerie instantanee pour un transfert de fichier par exemple) : l'utilisateur décide : autoriser, refuser ? pour cette session, toujours, jamais ? ... Ou alors cette solution séduisante présente un problème de sécurité énorme auquel j'aurais pas réfléchi ?
Ca doit etre possible avec le module owner, qui est classé EXPERIMENTAL
Pour le popup, ca doit pouvoir se bricoler avec ULOG et un démon kivabien
-- Xavier Henner
Salut !
Je suis presque entièrement satisfait de la solution IPtables (Linux) : elle
permet efficacement de filtrer les paquets entrants et sortants, définir
des ensembles de machines locales ou distantes et leur appliquer des regles
spécifiques... Cependant, imaginons le scénario suivant : un utilisateur de
la machine télécharge un programme malveillant, l'installe et l'execute...
2 possibilites :
1. le programme essaie de devenir serveur sur un port spécifique inutilisé
par les serveurs autorisés sur cette machine ; alors IPtables bloquera
cette tentative (arretez moi si je me trompe ?)
non
IPTable n'empeche pas le bind(). Par contre, il peut interdire les
paquets entrants qui viennent vers ce port.
2. le programme essaie de devenir serveur (par exemple) sur le port 22,
pour ca, il faut etre root, ce qui limite.
et
un serveur SSH est autorise sur cette machine ; IPtables l'empechera pas,
et le programme pourra envoyer des informations vers une machine distante
non, il pourra recevoir des connexions de l'extérieur.
pour sortir, tout dépend de la configuration iptables mise en place.
sur une machine avec conf parano par défaut (toute connexion entrante
bloquée, toute connexion sortante bloquée) et des regles utilisant le
state et jouant sur le sens de connexion, on peut autoriser certains
serveurs, et donc pour les port > 1024, il faut faire gaffe a ce que des
serveurs soient bien en place et autoriser les utilisateurs a utiliser
tel ou tel service.
D'ailleurs, hormis l'aspect sécurité, je trouve que cette possibilité
pratique... Une application souhaite devenir serveur (un logiciel de
messagerie instantanee pour un transfert de fichier par exemple) :
l'utilisateur décide : autoriser, refuser ? pour cette session, toujours,
jamais ? ... Ou alors cette solution séduisante présente un problème de
sécurité énorme auquel j'aurais pas réfléchi ?
Ca doit etre possible avec le module owner, qui est classé EXPERIMENTAL
Pour le popup, ca doit pouvoir se bricoler avec ULOG et un démon kivabien
Je suis presque entièrement satisfait de la solution IPtables (Linux) : elle permet efficacement de filtrer les paquets entrants et sortants, définir des ensembles de machines locales ou distantes et leur appliquer des regles spécifiques... Cependant, imaginons le scénario suivant : un utilisateur de la machine télécharge un programme malveillant, l'installe et l'execute... 2 possibilites :
1. le programme essaie de devenir serveur sur un port spécifique inutilisé par les serveurs autorisés sur cette machine ; alors IPtables bloquera cette tentative (arretez moi si je me trompe ?)
non IPTable n'empeche pas le bind(). Par contre, il peut interdire les paquets entrants qui viennent vers ce port.
2. le programme essaie de devenir serveur (par exemple) sur le port 22,
pour ca, il faut etre root, ce qui limite.
et un serveur SSH est autorise sur cette machine ; IPtables l'empechera pas, et le programme pourra envoyer des informations vers une machine distante
non, il pourra recevoir des connexions de l'extérieur.
pour sortir, tout dépend de la configuration iptables mise en place.
sur une machine avec conf parano par défaut (toute connexion entrante bloquée, toute connexion sortante bloquée) et des regles utilisant le state et jouant sur le sens de connexion, on peut autoriser certains serveurs, et donc pour les port > 1024, il faut faire gaffe a ce que des serveurs soient bien en place et autoriser les utilisateurs a utiliser tel ou tel service.
D'ailleurs, hormis l'aspect sécurité, je trouve que cette possibilité pratique... Une application souhaite devenir serveur (un logiciel de messagerie instantanee pour un transfert de fichier par exemple) : l'utilisateur décide : autoriser, refuser ? pour cette session, toujours, jamais ? ... Ou alors cette solution séduisante présente un problème de sécurité énorme auquel j'aurais pas réfléchi ?
Ca doit etre possible avec le module owner, qui est classé EXPERIMENTAL
Pour le popup, ca doit pouvoir se bricoler avec ULOG et un démon kivabien
-- Xavier Henner
Pierre BETOUIN
1. le programme essaie de devenir serveur sur un port spécifique inutilisé par les serveurs autorisés sur cette machine ; alors IPtables bloquera cette tentative (arretez moi si je me trompe ?) (...)
Ca doit etre possible avec le module owner, qui est classé EXPERIMENTAL
Pour le popup, ca doit pouvoir se bricoler avec ULOG et un démon kivabien
grsec te permettra de gérer assez finement à l'aide d'acl, les droits d'utilisateurs, de groupes, de programmes, etc, etc. Tu peux par ex. interdire à un certain GID de binder (entre autres).
http://www.grsecurity.org/
-- °°°°°°°°°----------------°°°°°°°°° Pierre BETOUIN
°°°°°°°°°----------------°°°°°°°°°
1. le programme essaie de devenir serveur sur un port spécifique
inutilisé par les serveurs autorisés sur cette machine ; alors
IPtables bloquera cette tentative (arretez moi si je me trompe ?)
(...)
Ca doit etre possible avec le module owner, qui est classé EXPERIMENTAL
Pour le popup, ca doit pouvoir se bricoler avec ULOG et un démon kivabien
grsec te permettra de gérer assez finement à l'aide d'acl, les droits
d'utilisateurs, de groupes, de programmes, etc, etc.
Tu peux par ex. interdire à un certain GID de binder (entre autres).
http://www.grsecurity.org/
--
°°°°°°°°°----------------°°°°°°°°°
Pierre BETOUIN
soulrider@unsigned.ath.cx
°°°°°°°°°----------------°°°°°°°°°
1. le programme essaie de devenir serveur sur un port spécifique inutilisé par les serveurs autorisés sur cette machine ; alors IPtables bloquera cette tentative (arretez moi si je me trompe ?) (...)
Ca doit etre possible avec le module owner, qui est classé EXPERIMENTAL
Pour le popup, ca doit pouvoir se bricoler avec ULOG et un démon kivabien
grsec te permettra de gérer assez finement à l'aide d'acl, les droits d'utilisateurs, de groupes, de programmes, etc, etc. Tu peux par ex. interdire à un certain GID de binder (entre autres).
http://www.grsecurity.org/
-- °°°°°°°°°----------------°°°°°°°°° Pierre BETOUIN
