Après plusieurs mois de travail, Hal Burgiss a terminé la première version de son guide sur la Sécurité Linux. Une version Red Hat existe également. A découvrir d'urgence :)
Note du modérateur: Guide étudié pour les débutants. Vraiment intéressant.
J'ai cliqué sur le chapitre 6.2 et déjà je suis complètement absorbé. J'adore le «You may be unwittingly participating in criminal activity», on se croirait dans un bon roman de Tom Clancy!
De la lecture pour le week-end, parce que, au boulot...
Souvent, la sécurité est aussi une affaire de suivi. Lecture quotidienne de http://www.securityfocus.com(...) recommandée pour tous ceux qui ont un ou plusieurs systèmes connectés 24x7 :)
J'ai oublié : l'exemple à ne pas suivre : http://www.securityfocus.com/news/281(...) , où MS avec 5 autres boîtes estiment qu'il vaut mieux limiter la diffusion des failles de sécurité ! Même si cela pourrait protéger de quelques scripts-kiddies, ce serait une aubaine pour les vrais "pirates" !
Le probleme, puisque tu revient sur ce point est que la diffusion des failles de securite, meme de maniere tres detaille, est profitable dans le cas ou la correction est rapide.
Generalement quand un patch est disponible, on peut considerer que la correction est rapide.
A moins que l'application du patch doit etre teste en production, la ca ralonge le delai d'exposition de plusieur jours.
Maintenant penser (utopiquement) que limiter la diffusion des ces dite failles a des personnes de confiance, permetra de gagner du temps... Ca pourrait etre vrai.
Cela dit c'est prendre le probleme a l'envers. La securite DOIT etre considerer comme un tache continue, suivi par quelqu'un, autrement dit, garantir un delai de reaction rapide.
Du cote de l'editeur du patch, il est evident qu'il est dans sont interet d'etre REACTIF. Visiblement Microsoft a des probleme de ce cote, il s'excuse comme ils peuvent (on peut le comprendre quand c'est la premiere fois que ca arrive).
Mais encore une fois, je pense qu'ils prennent le
a l'envers.
C'est le delais de reaction qui doit etre ameliore, pas le temps de propagation.
Ca permet au interreser, mais sans solution a long terme, de se premunir. On pourrais prendre l'exemple du SIDA, pas de remede, mais des preservatif histoire de pouvoir...hmmm...continuer a fonctionner ;) Evidement le but des 'entreprises' etant de faire des enfants, ca n'est pas LA solution ;)
De plus ce genre de comportement, pour en revenir a nos moutons, reduit la liberte d'expression de maniere sournoise, ce qui VRAIMENT inadmissible.
Mais je m'enflamme ;)
Si tu cherches une version papier d'un doc sur la sécurité et l'optimisation d'un serveur linux, il existe un _Excellent_ bouquin de Gerhard Mourani
sur le sujet, orienté RedHat mais applicable à pratiquement toutes les distribs linux, dont le titre est tout simplement "Securing and Optimizing Linux".
Ce bouquin va des principes de base (inetd, rtools...) aux modifications du kernel par vi, en passant par le paramètrage fin de _chaque_ démon de ton système... c'est impressionant et on y apprend sur tous les chapitres !
De toutes facons, la simple lecture de la table des matières donne envie de lire tout le doc, ca s'imprime au boulot (~500 pages !), c'est en anglais et c'est pour moi une référence.
Ce guide reprend tous les points de base sur la sécurité Unix/Linux : wrapper TCP/IP, vérif intégrité, détection d'intrusion, FW... C'est une réference avec une liste très complète d'outils.
le lien sur linuxdoc n'est plus valable : il n'y est plus hébergé.
Lu sur linuxdoc :
Removed at the request of the author (book is now more "dynamic"). Please access the Linux Administrator's Security Guide at the following location: http://www.seifried.org/lasg/(...)
Bon, j ai pas eu beaucoup de temps pour regarder le guide. Par contre, j ai remarqué que c etait gravement pompé sur un autre bookin 'Linux sécurité' chez campus press référence avec quelques petits exemples pratiques en plus ... (apparamment le bouquin lui etait plus theoriquement complet)....
Ça doit etre le créneau , tout les guides se ressemblent, non ????
>Ça doit etre le créneau , tout les guides se ressemblent, non ????
Bah ca devrait te rassurer : il n'y a pas 36000 facons différentes de sécuriser un unix en général, ou un linux en particulier...
Donc oui, on retombre souvent dans les meme schémas, les memes conseils et finalement ce qui va changer d'une doc à l'autre c'est l'orientation vers une distribution, la recherche d'exhaustivité d'un doc, ou encore l'adaptation à un niveau de compétences prédéfini.
# En voilà une bonne idée !
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 1.
De la lecture pour le week-end, parce que, au boulot...
# Savoir et suivre
Posté par Henri . Évalué à 1.
[^] # Re: Savoir et suivre
Posté par Henri . Évalué à 1.
[^] # Re: Savoir et suivre
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Savoir et suivre
Posté par jojolapin . Évalué à 1.
[^] # Re: Savoir et suivre
Posté par Yohann (site web personnel) . Évalué à 1.
Generalement quand un patch est disponible, on peut considerer que la correction est rapide.
A moins que l'application du patch doit etre teste en production, la ca ralonge le delai d'exposition de plusieur jours.
Maintenant penser (utopiquement) que limiter la diffusion des ces dite failles a des personnes de confiance, permetra de gagner du temps... Ca pourrait etre vrai.
Cela dit c'est prendre le probleme a l'envers. La securite DOIT etre considerer comme un tache continue, suivi par quelqu'un, autrement dit, garantir un delai de reaction rapide.
Du cote de l'editeur du patch, il est evident qu'il est dans sont interet d'etre REACTIF. Visiblement Microsoft a des probleme de ce cote, il s'excuse comme ils peuvent (on peut le comprendre quand c'est la premiere fois que ca arrive).
Mais encore une fois, je pense qu'ils prennent le
a l'envers.
C'est le delais de reaction qui doit etre ameliore, pas le temps de propagation.
Ca permet au interreser, mais sans solution a long terme, de se premunir. On pourrais prendre l'exemple du SIDA, pas de remede, mais des preservatif histoire de pouvoir...hmmm...continuer a fonctionner ;) Evidement le but des 'entreprises' etant de faire des enfants, ca n'est pas LA solution ;)
De plus ce genre de comportement, pour en revenir a nos moutons, reduit la liberte d'expression de maniere sournoise, ce qui VRAIMENT inadmissible.
Mais je m'enflamme ;)
[^] # Re: Savoir et suivre
Posté par Yann Hirou . Évalué à 1.
http://www.securitybugware.org(...) , http://www.packetstormsecurity.org(...) , http://www.linuxsecurity.com(...) , et encore quelques autres... mais c'est déjà un bon début :)
# une version imprimable...
Posté par thomas . Évalué à 1.
a mois qu'il existe deja, mais je n'ai pas trouve sur linuxdoc.org ...
[^] # Re: une version imprimable...
Posté par Benoît Sibaud (site web personnel) . Évalué à 1.
http://linuxdoc.org/guides.html(...) (en fait http://www.seifried.org/lasg/(...) )
[^] # Re: une version imprimable...
Posté par un nain_connu . Évalué à 1.
[^] # Re: une version imprimable...
Posté par schyzomarijks . Évalué à 1.
C'est vraiment parce que c'est toi et que je l'avais déjà fait pour moi ;-)
[^] # Re: une version imprimable...
Posté par Jerome Demeyer . Évalué à 1.
sur le sujet, orienté RedHat mais applicable à pratiquement toutes les distribs linux, dont le titre est tout simplement "Securing and Optimizing Linux".
Ce bouquin va des principes de base (inetd, rtools...) aux modifications du kernel par vi, en passant par le paramètrage fin de _chaque_ démon de ton système... c'est impressionant et on y apprend sur tous les chapitres !
De toutes facons, la simple lecture de la table des matières donne envie de lire tout le doc, ca s'imprime au boulot (~500 pages !), c'est en anglais et c'est pour moi une référence.
A lire d'urgence, et c'est disponible ici : http://www.linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edi(...)
ou ca s'achète ici (par exemple) : http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=09700330(...) ou là http://www.amazon.com/exec/obidos/ASIN/0970033001/qid=1006560699/sr(...)
[^] # Re: une version imprimable...
Posté par Jean-Philippe Prime (site web personnel) . Évalué à 1.
Version imprimable en PDF :
http://linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition(...)
Version HTML en tar.gz:
http://linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition(...)
[^] # Re: une version imprimable...
Posté par Jean-Philippe Prime (site web personnel) . Évalué à 1.
Linux Security Quick-Start HOWTO :
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_sing(...)
Security Quick-Start HOWTO for Red Hat
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_sing(...)
il doit bien exister un processus HTMLTOPDF quelque part ??
# Linux Administrator Security Guide
Posté par Foxy (site web personnel) . Évalué à 10.
Ce guide reprend tous les points de base sur la sécurité Unix/Linux : wrapper TCP/IP, vérif intégrité, détection d'intrusion, FW... C'est une réference avec une liste très complète d'outils.
On peut le trouver aux URL : http://www.seifried.org/lasg/(...) et http://www.linuxdoc.org/LDP/lasg/(...)
[^] # Re: Linux Administrator Security Guide
Posté par Xavier Poinsard . Évalué à 1.
Lu sur linuxdoc :
Removed at the request of the author (book is now more "dynamic"). Please access the Linux Administrator's Security Guide at the following location: http://www.seifried.org/lasg/(...)
# Linux Securité ???? Pompe pompe shadock !!!
Posté par Code34 (site web personnel) . Évalué à 1.
Ça doit etre le créneau , tout les guides se ressemblent, non ????
@++
Code34
[^] # Re: Linux Securité ???? Pompe pompe shadock !!!
Posté par hideo . Évalué à 1.
ça me rappelle une chansson d'assassin "qui s'inspire de qui ???" :)
pour ma part si les 2docs était très différent je sentirais comme un probleme :)
h_n
[^] # Re: Linux Securité ???? Pompe pompe shadock !!!
Posté par Jerome Demeyer . Évalué à 1.
Bah ca devrait te rassurer : il n'y a pas 36000 facons différentes de sécuriser un unix en général, ou un linux en particulier...
Donc oui, on retombre souvent dans les meme schémas, les memes conseils et finalement ce qui va changer d'une doc à l'autre c'est l'orientation vers une distribution, la recherche d'exhaustivité d'un doc, ou encore l'adaptation à un niveau de compétences prédéfini.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.