Articles précédents : Livre
- [32] Python in a Nutshell
- [14] Éditions Libres
- [36] Un article et un livre sur Linux
- [101] Mandrake se lance dans l'édition
- [9] Un chapitre censuré dans le livre de Kevin Mitnick
- [5] La nostalgie des pingouins
- [21] Prentice Hall va publier des livres Libres grâce à Bruce Perens
- [19] Développer pour Mozilla : livre en Open Content
- [4] Note de lecture du livre « PostgreSQL - Services Web professionnels avec PostgreSQL et PHP/XML »
- [7] Nouvelle édition du YAGIL disponible
Livre : Comment conduire votre propre audit de sécurité ?
Posté par Jules Vo-Dinh (page perso, ). Modéré le 04 avril 2003.
![[en]](../../../images/en.png)
Net-Security (2016 hits)
> Lire les commentaires (9 commentaires, moyenne: 4,1).
Re: Comment conduire votre propre audit de sécurité ?
60euro chez eyrolles :)
http://www.eyrolles.com/php.informatique/Ouvrages/9780471229469.php(...)
Contents
PART I. Building a Multisystem Tiger Box
* Basic Windows 2000/Server Installation and Configuration
* Basic Linux and Solaris Installations and Configurations
* Mac OS X Tiger Box Solutions
* Installing and Configuring a Testing Target
PART II. Using Security Analysis Tools for your Windows-Based Tiger Box Operating System
* Cerberus Internet Scanner
* CyberCop Scanner
* Internet Scanner
* STAT Scanner
* TigerSuite 4.0.
PART III. Using Security Analysis Tools for *NIX and Mac OS X
* hping/2
* Nessus Security Scanner
* Nmap
* SAINT
* SARA
PART IV. Vunerability Assessment
* Comparative Analysis
Appendix
* Appendix A. Linux/UNIX Shortcuts and Commands
* Appendix B. What's on the CD-ROM
Re: Comment conduire votre propre audit de sécurité ?
A noter que le premier chapitre du livre intitulé "Basic Windows 2000/Windows 2000 Server Installation and Configuration" est en libre téléchargement (au format pdf) sur le site.
Je suis sûr que tout le monde se sent concerné ici ;-)
-
[^]Re: Comment conduire votre propre audit de sécurité ?
Posté par LupusMic (page perso, ) le 04/04/2003 à 08:02. (lien). Évalué à 5.J'en suis convaincu, car c'est la diversité des horreurs qui permet de s'amuser en informatique ;)
Un autre lien intéressant:
Voilà la référence pour un ouvrage que j'ai utilisé pour sécuriser Linux (principalement pour les versions 6.x et 7.x de RedHat.
http://www.openna.com/products/books/books.php?e=0,1,13(...)
Le livre s'appelle "Securing & Optimizing Linux: The Hacking Solution (v.3.0)", est écrit par Gerhard Mourani et explique à mon sens comment réellement arriver à utiliser un serveur sécurisé dans un environnement de production.
Nous avons plusieurs de ces serveurs en production avec un uptime de plusieurs centaines de jours, sans aucun problème, sans interruption de service ou hack des machines.
Pas de troll sur la version de Linux installée ... le choix était fait avant que je commence à y travailler ;o)
Olivier
-
[^]Re: Un autre lien intéressant:
Posté par Silence (page perso, ) le 04/04/2003 à 08:18. (lien). Évalué à 3.Centaine de jours ?
Ca me fait toujours tout drole d'entendre l'uptime comme argument d'efficacite quand on parle de securite...
C'est pas le noyau Linux (2.2 et 2.4) dans lequel ont a decouvert une faille y a pas longtemps ?
Je dit ca comme ca, mais j'aimerais bien connaitre le sentiments que ca fait de savoir que les super serveur de prod inviollable, ont un noyau troue.
Dans c'est ca la ou fait quoi ? ou fait confiance aux autres mesure de securite ?--
^d^c-
[^]Re: Un autre lien intéressant:
Posté par Mickael Villers () le 04/04/2003 à 10:28. (lien). Évalué à 3.faille locale et non exploitable à distance, Si seuls les admins/personnes de confiance ont des comptes sur la machine, t'en as rien à faire, c'est pas urgent
-
[^]Re: Un autre lien intéressant:
Posté par Mathieu Pillard (page perso, ) le 04/04/2003 à 12:13. (lien). Évalué à 2.... faut aussi avoir confiance dans les softs que tu as installes, parceque si ya une faille dans apache par exemple permettant d'avoir un acces a un user local (au hasard celui d'apache) bah tu feras moins le malin...
[remplacez apache par tout ce que vous voulez...]-
[^]Re: Un autre lien intéressant:
Posté par Mickael Villers () le 04/04/2003 à 15:41. (lien). Évalué à 2.là, j'suis d'accord,
mais remplacer apache dans les 20mins suivant la publication de la faille, c'est ne nuit pas à l'uptime :)
-
-
-
[^]Re: Un autre lien intéressant:
Posté par Olivier () le 04/04/2003 à 10:55. (lien). Évalué à 7.L'uptime n'est pas un argument de sécurité mais de fiabilité et de disponibilité. On trouve régulièrement des failles et il y a des mises à jour à faire mais il faut toujours analyser un peu ce qui a été trouvé comme faille et voir l'impact sur l'environnement déployé. A ce niveau là, la règle de l'installation la plus minimale possible procure un avantage important puisqu'il ne faut pas suivre "l'actualité" de centaines de packages. Un exemple peut-être stupide mais qui explique un peu le sens de ma démarche ... sur une machine de production où se trouvent un minimum d'applications, en cas de problème ou de débugging à faire ... une connexion ssh, installation de telnet et tcpdump (en général celà suffit pour avoir une idée de ce qu'il se passe) et on enlève les deux packages une fois que c'est terminé. Personnellement je trouve ça simple et efficace. Olivier
-
Cette page a été générée par Templeet en 0.0759s (dont 0.0091 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.