modules Netfilter : integres au noyau ou en Modules ?
8 réponses
Guillaume Kaddouch
Bonjour,
sur le web on trouve quelques docs sur la comparaison en général d'intégrer
des fonctionalités dans le kernel ou bien de les laisser sous forme de
module lors de la compilations, et d'apres ces docs il y a plus d'avantages
a mettre en Module ( [M] à la place de [*] )
Mais a propos de NetFilter, n'est ce pas plus sécurisé d'intégrer toutes ses
fonctionalités dans le noyau ?
Quels sont les avantages ?
A propos des inconvénients je crois que si un modules est buggué il peut
faire crasher le système... y en a t il d'autres ?
Je test actuellement ce procédé sur le noyau 2.4.21, et tout ce qui est
compilé directement dans le kernel est toujours utilisé dans les regles de
filtrage (pas de chargements en mémoire inutiles).
Il me semble qu'il y a avait il y longtemps un thread sur ce sujet mais il
semble ne plus être sur le serveur.
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
Jacques
A propos des inconvénients je crois que si un modules est buggué il peut faire crasher le système... y en a t il d'autres ?
Il y a un inconvénient certain à utiliser les modules, mais il faut quand même relativiser. Il existe des rootkit qui s'installe en tant que module dans le noyau, suivi généralement d'un second module pour dissimuler le premier. Donc, un noyau compilé pour utiliser les modules présente le risque d'être vulnérable à ce type d'attaque (il faut déjà être passé root, puis avoir chargé le module, mais cela laisse une jolie porte une fois installé), alors qu'un noyau ne supportant pas les modules y reste invulnérable.
Cela ne répond pas directement à la question, mais c'est un point à ne pas négliger non plus.
Jacques
A propos des inconvénients je crois que si un modules est buggué il peut
faire crasher le système... y en a t il d'autres ?
Il y a un inconvénient certain à utiliser les modules, mais il faut
quand même relativiser.
Il existe des rootkit qui s'installe en tant que module dans le noyau,
suivi généralement d'un second module pour dissimuler le premier.
Donc, un noyau compilé pour utiliser les modules présente le risque
d'être vulnérable à ce type d'attaque (il faut déjà être passé root,
puis avoir chargé le module, mais cela laisse une jolie porte une fois
installé), alors qu'un noyau ne supportant pas les modules y reste
invulnérable.
Cela ne répond pas directement à la question, mais c'est un point à ne
pas négliger non plus.
A propos des inconvénients je crois que si un modules est buggué il peut faire crasher le système... y en a t il d'autres ?
Il y a un inconvénient certain à utiliser les modules, mais il faut quand même relativiser. Il existe des rootkit qui s'installe en tant que module dans le noyau, suivi généralement d'un second module pour dissimuler le premier. Donc, un noyau compilé pour utiliser les modules présente le risque d'être vulnérable à ce type d'attaque (il faut déjà être passé root, puis avoir chargé le module, mais cela laisse une jolie porte une fois installé), alors qu'un noyau ne supportant pas les modules y reste invulnérable.
Cela ne répond pas directement à la question, mais c'est un point à ne pas négliger non plus.
Jacques
Eric Belhomme
Jacques wrote in news:be9lb1$2bcv$:
Cela ne répond pas directement à la question, mais c'est un point à ne pas négliger non plus.
Je pense que ca répond parfaitement à sa question, au contraire !
Cedric te répondait qu'un firewall de prod basé sur netfilter _doit_ avoir le support des modules désactivé, pour seule raison que tu évoques !
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
Jacques <jacques@chez.moi> wrote in news:be9lb1$2bcv$1@biggoron.nerim.net:
Cela ne répond pas directement à la question, mais c'est un point à ne
pas négliger non plus.
Je pense que ca répond parfaitement à sa question, au contraire !
Cedric te répondait qu'un firewall de prod basé sur netfilter _doit_ avoir
le support des modules désactivé, pour seule raison que tu évoques !
--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/
Cela ne répond pas directement à la question, mais c'est un point à ne pas négliger non plus.
Je pense que ca répond parfaitement à sa question, au contraire !
Cedric te répondait qu'un firewall de prod basé sur netfilter _doit_ avoir le support des modules désactivé, pour seule raison que tu évoques !
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
Coq
Julien Salgado wrote:
Donc, un noyau compilé pour utiliser les modules présente le risque d'être vulnérable à ce type d'attaque (il faut déjà être passé root, puis avoir chargé le module, mais cela laisse une jolie porte une fois installé), alors qu'un noyau ne supportant pas les modules y reste invulnérable.
Il est possible d'insérer des modules sur un noyau ne le supportant pas c'est essentiellement à la structure ELF du noyau. Il faut donc être prudent et surtout empêcher la lecture de /dev/kmem pour bloquer le chargement des modules. ET il peut être utile d'utiliser des méthodes de renforcement du noyau (kernel hardening) comme grsecurity, LIDS ou RSBAC.
Ajoutons à ce titre un lien explicitant la modification de noyau en dur (Kernel Static Patching): <http://www.phrack.org/phrack/60/p60-0x08.txt>
et des précisions sur /dev/kmem: <http://www.phrack.org/phrack/58/p58-0x07>
Relisons les classiques en attendant Aout.
Coq
Julien Salgado wrote:
Donc, un noyau compilé pour utiliser les modules présente le risque
d'être vulnérable à ce type d'attaque (il faut déjà être passé root,
puis avoir chargé le module, mais cela laisse une jolie porte une fois
installé), alors qu'un noyau ne supportant pas les modules y reste
invulnérable.
Il est possible d'insérer des modules sur un noyau ne le supportant pas
c'est essentiellement à la structure ELF du noyau. Il faut donc être
prudent et surtout empêcher la lecture de /dev/kmem pour bloquer le
chargement des modules. ET il peut être utile d'utiliser des méthodes de
renforcement du noyau (kernel hardening) comme grsecurity, LIDS ou
RSBAC.
Ajoutons à ce titre un lien explicitant la modification de noyau en dur
(Kernel Static Patching):
<http://www.phrack.org/phrack/60/p60-0x08.txt>
et des précisions sur /dev/kmem:
<http://www.phrack.org/phrack/58/p58-0x07>
Donc, un noyau compilé pour utiliser les modules présente le risque d'être vulnérable à ce type d'attaque (il faut déjà être passé root, puis avoir chargé le module, mais cela laisse une jolie porte une fois installé), alors qu'un noyau ne supportant pas les modules y reste invulnérable.
Il est possible d'insérer des modules sur un noyau ne le supportant pas c'est essentiellement à la structure ELF du noyau. Il faut donc être prudent et surtout empêcher la lecture de /dev/kmem pour bloquer le chargement des modules. ET il peut être utile d'utiliser des méthodes de renforcement du noyau (kernel hardening) comme grsecurity, LIDS ou RSBAC.
Ajoutons à ce titre un lien explicitant la modification de noyau en dur (Kernel Static Patching): <http://www.phrack.org/phrack/60/p60-0x08.txt>
et des précisions sur /dev/kmem: <http://www.phrack.org/phrack/58/p58-0x07>
Relisons les classiques en attendant Aout.
Coq
Olivier Croquette
On 07 Jul 2003 09:03:42 GMT, Julien Salgado wrote:
L'utilisation des modules est surtout intéressante si on a un grand parc à gérer. Sinon ça ne vaut pas le coup de l'utiliser.
<Un peu HS> Parfois on a pas le choix. Il m'est déjà arrivé d'être obligé d'utiliser des modules, car les fonctionnalités correspondantes nécessitaient le passage de paramètres des modules. Si je me rappelle bien, c'était une carte son. Mon noyau était jusque alors en tout statique et j'ai du activer leur support. </Un peu HS>
-- Olivier
On 07 Jul 2003 09:03:42 GMT, Julien Salgado wrote:
L'utilisation des modules est surtout intéressante si on a un grand parc
à gérer. Sinon ça ne vaut pas le coup de l'utiliser.
<Un peu HS>
Parfois on a pas le choix.
Il m'est déjà arrivé d'être obligé d'utiliser des modules, car les
fonctionnalités correspondantes nécessitaient le passage de paramètres
des modules.
Si je me rappelle bien, c'était une carte son.
Mon noyau était jusque alors en tout statique et j'ai du activer leur
support.
</Un peu HS>
On 07 Jul 2003 09:03:42 GMT, Julien Salgado wrote:
L'utilisation des modules est surtout intéressante si on a un grand parc à gérer. Sinon ça ne vaut pas le coup de l'utiliser.
<Un peu HS> Parfois on a pas le choix. Il m'est déjà arrivé d'être obligé d'utiliser des modules, car les fonctionnalités correspondantes nécessitaient le passage de paramètres des modules. Si je me rappelle bien, c'était une carte son. Mon noyau était jusque alors en tout statique et j'ai du activer leur support. </Un peu HS>
-- Olivier
Guillaume Kaddouch
Je test actuellement un tel noyau (monolithique on dit ?) et pour l'instant ca à l'air de tenir la route. Mais apparemment vous me dite que même avec le support des modules désactivés les astuces par LKM sont quand même possible, on peut quand meme toucher au noyau ? Dans ce cas un :
chmod 000 /dev/kmem
n'est pas suffisant ? (peut être une instabilité système?) j'avoue être intéréssé par le grsecurity mais si il est possible de se protéger des modules malicieux sans patch, c'est plus pratique.
La solution donné sur un des liens proposé ici même est le patch suivant :
Je ne comprend pas comment appliqué ce patch, c'est censé couler de source apparemment mais je ne sais pas comment faire... Comment appliquer kmem-ro.diff ?
Guillaume.
Je test actuellement un tel noyau (monolithique on dit ?) et pour l'instant
ca à l'air de tenir la route.
Mais apparemment vous me dite que même avec le support des modules
désactivés les astuces par LKM sont quand même possible, on peut quand meme
toucher au noyau ?
Dans ce cas un :
chmod 000 /dev/kmem
n'est pas suffisant ? (peut être une instabilité système?) j'avoue être
intéréssé par le grsecurity mais si il est possible de se protéger des
modules malicieux sans patch, c'est plus pratique.
La solution donné sur un des liens proposé ici même est le patch suivant :
Je ne comprend pas comment appliqué ce patch, c'est censé couler de source
apparemment mais je ne sais pas comment faire...
Comment appliquer kmem-ro.diff ?
Je test actuellement un tel noyau (monolithique on dit ?) et pour l'instant ca à l'air de tenir la route. Mais apparemment vous me dite que même avec le support des modules désactivés les astuces par LKM sont quand même possible, on peut quand meme toucher au noyau ? Dans ce cas un :
chmod 000 /dev/kmem
n'est pas suffisant ? (peut être une instabilité système?) j'avoue être intéréssé par le grsecurity mais si il est possible de se protéger des modules malicieux sans patch, c'est plus pratique.
La solution donné sur un des liens proposé ici même est le patch suivant :
Je ne comprend pas comment appliqué ce patch, c'est censé couler de source apparemment mais je ne sais pas comment faire... Comment appliquer kmem-ro.diff ?
Guillaume.
Eric Belhomme
"Guillaume Kaddouch" wrote in news:bed131$15d$:
n'est pas suffisant ? (peut être une instabilité système?) j'avoue être intéréssé par le grsecurity mais si il est possible de se protéger des modules malicieux sans patch, c'est plus pratique.
LIDS rulez !
Je ne comprend pas comment appliqué ce patch, c'est censé couler de source apparemment mais je ne sais pas comment faire... Comment appliquer kmem-ro.diff ?
# cd /usr/src/linux
# patch -p1 < kmem-ro.diff
et hop...
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
"Guillaume Kaddouch" <gkweb@wanadoo.fr> wrote in
news:bed131$15d$1@news-reader5.wanadoo.fr:
n'est pas suffisant ? (peut être une instabilité système?) j'avoue
être intéréssé par le grsecurity mais si il est possible de se
protéger des modules malicieux sans patch, c'est plus pratique.
LIDS rulez !
Je ne comprend pas comment appliqué ce patch, c'est censé couler de
source apparemment mais je ne sais pas comment faire...
Comment appliquer kmem-ro.diff ?
# cd /usr/src/linux
# patch -p1 < kmem-ro.diff
et hop...
--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/
n'est pas suffisant ? (peut être une instabilité système?) j'avoue être intéréssé par le grsecurity mais si il est possible de se protéger des modules malicieux sans patch, c'est plus pratique.
LIDS rulez !
Je ne comprend pas comment appliqué ce patch, c'est censé couler de source apparemment mais je ne sais pas comment faire... Comment appliquer kmem-ro.diff ?
# cd /usr/src/linux
# patch -p1 < kmem-ro.diff
et hop...
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
Julien Salgado
Guillaume Kaddouch a écrit :
Je test actuellement un tel noyau (monolithique on dit ?) et pour l'instant ca à l'air de tenir la route. Mais apparemment vous me dite que même avec le support des modules désactivés les astuces par LKM sont quand même possible, on peut quand meme toucher au noyau ? Dans ce cas un :
chmod 000 /dev/kmem
n'est pas suffisant ? (peut être une instabilité système?)
Non, car si je suis méchant, la première chose que je ferai c'est un chmod 640 /dev/kmem
j'avoue être intéréssé par le grsecurity mais si il est possible de se protéger des modules malicieux sans patch, c'est plus pratique.
La solution donné sur un des liens proposé ici même est le patch suivant :
Je ne comprend pas comment appliqué ce patch, c'est censé couler de source apparemment mais je ne sais pas comment faire... ... Comment appliquer kmem-ro.diff ?
Soit en rajoutant les quelques lignes à la main dans mem.c. Soit en utilsant la commande patch depuis le rérpertoire des sources du noyau : patch -p3 <kmem-ro.diff
Le 3 correspond à la profondeur de /usr/src/linux dans les entêtes du patch.
Guillaume.
-- Julien
Guillaume Kaddouch a écrit :
Je test actuellement un tel noyau (monolithique on dit ?) et pour l'instant
ca à l'air de tenir la route.
Mais apparemment vous me dite que même avec le support des modules
désactivés les astuces par LKM sont quand même possible, on peut quand meme
toucher au noyau ?
Dans ce cas un :
chmod 000 /dev/kmem
n'est pas suffisant ? (peut être une instabilité système?)
Non, car si je suis méchant, la première chose que je ferai c'est un
chmod 640 /dev/kmem
j'avoue être
intéréssé par le grsecurity mais si il est possible de se protéger des
modules malicieux sans patch, c'est plus pratique.
La solution donné sur un des liens proposé ici même est le patch suivant :
Je ne comprend pas comment appliqué ce patch, c'est censé couler de source
apparemment mais je ne sais pas comment faire...
... Comment appliquer kmem-ro.diff ?
Soit en rajoutant les quelques lignes à la main dans mem.c.
Soit en utilsant la commande patch depuis le rérpertoire des sources du
noyau :
patch -p3 <kmem-ro.diff
Le 3 correspond à la profondeur de /usr/src/linux dans les entêtes du
patch.
Je test actuellement un tel noyau (monolithique on dit ?) et pour l'instant ca à l'air de tenir la route. Mais apparemment vous me dite que même avec le support des modules désactivés les astuces par LKM sont quand même possible, on peut quand meme toucher au noyau ? Dans ce cas un :
chmod 000 /dev/kmem
n'est pas suffisant ? (peut être une instabilité système?)
Non, car si je suis méchant, la première chose que je ferai c'est un chmod 640 /dev/kmem
j'avoue être intéréssé par le grsecurity mais si il est possible de se protéger des modules malicieux sans patch, c'est plus pratique.
La solution donné sur un des liens proposé ici même est le patch suivant :
Je ne comprend pas comment appliqué ce patch, c'est censé couler de source apparemment mais je ne sais pas comment faire... ... Comment appliquer kmem-ro.diff ?
Soit en rajoutant les quelques lignes à la main dans mem.c. Soit en utilsant la commande patch depuis le rérpertoire des sources du noyau : patch -p3 <kmem-ro.diff
Le 3 correspond à la profondeur de /usr/src/linux dans les entêtes du patch.
Guillaume.
-- Julien
Guillaume Kaddouch
Ceci est un sujet très intéressant, mais très déconcertant aussi !
1 - Je sais que l'on peut lancer des LKM malicieux, donc il faut désactiver le support des LKM dans le noyau 2 - même avec le support des LKM désactivé, il est possible de lancer un LKM en écrivant dans /dev/kmem, donc il faut appliquer un patch pour mettre /dev/kmem en lecture seule. 3 - même avec tout ceci j'apprend dans ce lien http://www.securiteam.com/unixfocus/5IP0H2A75Q.html qu'il y a encore un autre moyen en écrivant directement dans le mémoire ?
Donc il n'y a rien à faire ?? même le patch grsecurity ne comble pas ce trou de sécurité, aucun patch n'existe contre cette méthode ? :'(
Guillaume.
Ceci est un sujet très intéressant, mais très déconcertant aussi !
1 - Je sais que l'on peut lancer des LKM malicieux, donc il faut désactiver
le support des LKM dans le noyau
2 - même avec le support des LKM désactivé, il est possible de lancer un LKM
en écrivant dans /dev/kmem, donc il faut appliquer un patch pour mettre
/dev/kmem en lecture seule.
3 - même avec tout ceci j'apprend dans ce lien
http://www.securiteam.com/unixfocus/5IP0H2A75Q.html qu'il y a encore un
autre moyen en écrivant directement dans le mémoire ?
Donc il n'y a rien à faire ?? même le patch grsecurity ne comble pas ce trou
de sécurité, aucun patch n'existe contre cette méthode ? :'(
Ceci est un sujet très intéressant, mais très déconcertant aussi !
1 - Je sais que l'on peut lancer des LKM malicieux, donc il faut désactiver le support des LKM dans le noyau 2 - même avec le support des LKM désactivé, il est possible de lancer un LKM en écrivant dans /dev/kmem, donc il faut appliquer un patch pour mettre /dev/kmem en lecture seule. 3 - même avec tout ceci j'apprend dans ce lien http://www.securiteam.com/unixfocus/5IP0H2A75Q.html qu'il y a encore un autre moyen en écrivant directement dans le mémoire ?
Donc il n'y a rien à faire ?? même le patch grsecurity ne comble pas ce trou de sécurité, aucun patch n'existe contre cette méthode ? :'(
