Il n'y a pas (� ma connaissance) d'obligation en mati�re de preuve. Par exemple, en roulage les constatations de l'agent qualifi� font foi jusqu'� preuve du contraire. Pas encore en mati�re judiciaire MAIS le bon sens et la logique sont de rigueur.
Il arrive tr�s r�guli�rement (et croyant bien faire) que des gestionnaire syst�mes nous "apporte la preuve sur un plateau" d�s notre arriv�e sur les lieux. A savoir, des logs d�j� filtr�s par leurs soins. A savoir �galement, les logs ne sont pas tout (ce n'est pas suffisant). Les HD ne sont pas tout non plus. Nous r�digeons des proc�s-verbaux dans lesquels nous indiquons un maximum de d�tails de nos constatations, ce qui permet de corroborer les faits et les preuves que nous d�couvrons. Nous d�crivons aussi le contexte (y compris la configuration des lieux. Les locaux sont ils ferm�s � clefs, qui � les clefs, les badges, qui a badg� ...) Nous devons �galement �valuer rapidement la situation, faut il couper les serveurs, les laisser tourner. Si il faut les couper, faut il d�brancher la machine ou utiliser un "shutdown" normal ... Chaque situation est diff�rente et doit �tre �valu�e. Donc, si je peux me permettre de donner quelques conseils : - essayer de ne pas "tripoter" vous m�me dans les logs. Je pr�f�re des logs entiers que d�j� filtr� (en effet, il se peut que l'auteur ait utilis� plusieurs machines pour effectuer son m�fait, qu'il ait fait des reconnaissances 5 jours avant (ou plus) qu'il ait commis d'autre fait annexes que vous n'avez pas vu ...) - essayer de manipuler au minimum la machine compromise (voire pas du tout si possible). Dans le cas contraire, noter toute vos actions afin de que lors de nos constatations on puisse faire la diff�rence entre les actions de l'auteur et celle du gestionnaire. (ne pas oublier de noter la date et l'heure exacte des action effectu�es) - Ne pas effacer les traces laiss�es par l'auteur. souvent, les gestionnaire sont press�s par leurs chefs hi�rarchiques pour r�-installer rapidement un serveur op�rationnel pour les client. Il faut savoir ce que l'on veut, on ne peut avoir le beurre et l'argent du beurre. Essayez dans ce cas de changer le(s) disque(s) dur (m�me si c'est du RAID ou du LVM) - Contacter rapidement un CCU pour d�poser plainte (la plainte n'est pas encore dans les moeurs de toutes les entreprises � cause de l'image de marque, c'est pas � nous de convaincre les patrons mais personnellement, en tant que client, j'aurais plus confiance dans une entreprise qui avoue avoir �t� "pirat�e" que dans une entreprise qui me cacherait la chose. T�t ou tard, �a se saura de toute fa�on.) - Pour finir, je dirais qu'il faut toujours essayer de s'imaginer un fait concret par analogie pour chercher � rester logique. Par exemple, s'imaginer un meurtre : La preuve est elle meilleure si l'arme du crime est apport�e par un t�moin (m�me s'il n'a pas touch� l'arme avec les doigts et qu'il l'a emball�e dans un sac plastique ...) que si elle est d�couverte � l'endroit du crime par un policier ? Ne pas oublier que le policier qui constate n'a normalement aucun int�r�t dans l'affaire pour laquelle il fait des constatations. Par contre, il serait facile de critiquer un gestionnaire syst�me qui ferait une partie de l'enqu�te � la place de la police (filtrer les logs, faire du forensic ...) puisqu'il est impliqu� dans l'affaire, qu'il le veuille ou non. Christophe Monniez Enqu�teur au FCCU section Op�rations Le jeu 23/09/2004 � 16:30, Jean-Francois Dive a �crit : > la seule peuve qui vaut vraiment kkchose, se sont les HDD de la machine > hackee. quand on forensic, on essaye d'avoir un dump de la memoire, on > prends un dump du disque, et on eteint la chose, on prends les HDD, on > les met dans de beaux sachets scelles et on commence a partir des dump > (dd /dev/XXX | netcat ...) . > Ce se serait pas logique que les logs decentralises soient pris comme preuves > comme tel. > > Mais bon, un avocat specialise est la seule personne a meme a repondre > aux questions a mon sens, ou alors un membre de votre CCU locale la plus > proche (computer crime unit). > > J. > > On Thu, Sep 23, 2004 at 04:12:34PM +0200, gotfish wrote: > > >> Or, si un jour on se fait haquer, comment certifier nos DB pour que > > >> > > >> son contenu soit exploitable devant les tribunaux? Y a t'il des > > >> > > >> "OSI" quelque chose specifiant ce qui doit etre fait et comment? > > >> > > > Aucune idee. Mais est-ce meme seulement necessaire ? Si tu devais > > > deoser une plainte un jour, elle serait fondee sur tes logs qui te > > > > Mhhhaaaa nee, je n'y crois pas. Quelle est la difference entre un log > > reellement cree suite a un evenement et un log bidon? Preuve bidon > > alors? Quelque chose ne colle pas! > > > > Juste un peu d'imagination... le type qui est appelle devant les > > tribunaux ne pourrait il pas dire au juge: Mais? Non? Qui vous garantit > > que le serveur de log est fiable? > > > > Qui (et comment?) peut garantir cela? > > > > Il doit y avoir des certifications (ou alors il faut vite les inventer) > > decrivant comment faire ce serveur ou qui appeller pour "certifier" la > > proceudre? > > > > Merci :) > > > > /robert > > > > > > > > _______________________________________________________ > > Linux Mailing List - http://www.unixtech.be > > Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > > Archives: http://www.mail-archive.com/[EMAIL PROTECTED] > > IRC: chat.unixtech.be:6667 - #unixtech _______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: chat.unixtech.be:6667 - #unixtech
