Bonjours,

Merci bcp pour ces precisions bien utiles. Je trouve qu'il est vraiment
important de rappeler qu'il faut porter plainte, les gens ne le font
jamais et c'est bien domage.

Question mainteant: je suppose que le disque physique fait office de preuve ultime.
Personellement, une procedure comme suit me semble +- correct.

- noter l'heure.
- prendre un temoin.
- connecter a la machine.
- dump memoire (dd | netcat).
- dump hdd (dd | netcat).
- eteindre la machine.
- extraire les disques.
- les mettre dans un contenant avec scelles.
- Les mettre a l'abris (coffre fort, que sais je).
- mettre de nouveaux hdd.
- remettre l'image de backup.
- relancer le service.

Le point du contenant etant clairement le moins clair quand aux
obligations legales: y a il des regles / produits officiellement
reconnus pour ce genre de choses ? 

La prise d'info du hdd est clairement faite pour commencer les
investigations "en interne" puisqu'une penetration du permimetre est
peut etre signe d'un probleme plus grave. A mon sens ce genre de
procedure semble assez compatible avec les besoins de la CCU (ils ont le
hdd original, non touche), et ont potentiellement des indications
apportees par l'analyse forensic; ainsi que ceux de la societe
qui doit remettre le service en place le + vite possible.

Finalement, y a il des dispositions legales quand a la reglementation de
la prise de preuves ? Je sais que dans d'autres pays, bcp de travail est
fait dans ce sens; quand est il de la belgique ?

Cordialement,

Jean-Francois Dive

On Sun, Oct 03, 2004 at 09:01:40PM +0200, Christophe Monniez wrote:
> 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

-- 
--

-> Jean-Francois Dive
--> [EMAIL PROTECTED]

  I think that God in creating Man somewhat overestimated his ability.
    -- Oscar Wilde
_______________________________________________________
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

Répondre à