dimanche 12 octobre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Articles

Liens connexes

L'article (1113 hits)
Modular Syslog (1006 hits)

Dépêche modérée par

Amaury

Articles : Vous fiez-vous à vos logs système ?

Posté par hideo (). Modéré le 12 décembre 2001.

DaemonNews fait le point sur la sécurité de vos logs systèmes. Une occasion de faire connaissance avec Modular Syslog, une solution de remplacement au démon syslog traditionnel incluant la cryptographie :)

Une technique souvent utilisée par les crackers informatiques, et les voleurs éprouvés, consiste à effacer ses empruntes digitales de la scène du crime. Celà consiste habituellement à effacer ou modifier les logs stockés sur l'ordinateur et qui les exposeraient en cas d'examen consciencieux. Des logs non protégés rendront impossibles la vérification du système dans la plupart des cas. Quand un cracker prend le contrôle d'un système, il prend également le pouvoir de lire, modifier et effacer n'importe quel log.

L'article (1113 hits)
Modular Syslog (1006 hits)

> Lire les commentaires (42 commentaires, moyenne: 7,7).

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.

C'est pas mal...

Posté par VACHOR (page perso, ) le 12/12/2001 à 17:32. (lien). Évalué à 21.

Ce doit être un procécé efficace.
Un problème, cependant :
"You can rotate logs, but you have to put them back together to make the checks. Specifically, do not erase old logs."
Faut bien enlever les vieux logs un jours, quand même ! Surtout sur un système en prod qui est bien chargé...
Un truc étrange aussi :
"Take care of key file permissions; the /var/ssyslog directory should be mode 0700 and all files inside 0600"
Si le hacker est root pour modifier les logs, il peut aller changer les permissions ???

Il faut surement un truc en plus pour chiffrer le fichier de clefs sur un password. Après il faut bien sur se souvenir du password...

[^]Re: C'est pas mal...

Posté par kael () le 13/12/2001 à 10:24. (lien). Évalué à 8.
y'a qu'un seul truc de vrai, c'est la methode subtil discret : l'imprimante sur papier listing !!

bon par contre pour l'espace de stoquage et les arbres c'est pas top.....
:)
- [^]Re: C'est pas mal...
  
  Posté par Patrice Karatchentzeff (page perso, ) le 13/12/2001 à 14:16. (lien). Évalué à 3.
  Il y a mieux : la gravure sur support non reinscriptible, genre cederom ou devederom... On gache un peu (beaucoup meme :-) ) mais c'est beaucoup plus ecologique...
  
  PK
  - [^]Re: C'est pas mal...
    
    Posté par simon () le 13/12/2001 à 15:50. (lien). Évalué à 1.
    je ne suis pas sur (voir pas du tout ) que cela soit plus écologique ... un CD est très peu biodégradable. Cela dit c'est certainement la meilleur solution ;)
    - [^]Re: C'est pas mal...
      
      Posté par Benoit Rousseau () le 14/12/2001 à 11:56. (lien). Évalué à 0.
      Bein apres tu peux toujours faire des compiles de log file avec au lieu de les jeter par la fenetre...
      Le probleme c'est qu'il faut monopoliser le graveur en permanence, et ca c'est plus ennuyeux

syslog-ng

Posté par pappy (page perso, ) le 12/12/2001 à 17:39. (lien). Évalué à 28.

Une autre alternative à syslog est syslog-ng (syslog-New-Generation) :
http://www.balabit.hu/en/downloads/syslog-ng/(...)

Aller voir l'excellente doc en Français :
http://www.hsc.fr/ressources/breves/syslog-ng.html(...)

[^]Re: syslog-ng

Posté par Mathieu Dessus (page perso, ) le 13/12/2001 à 00:19. (lien). Évalué à 9.
Et syslog-ng est tres utile ave netfilter pour separer les logs du firewall du reste du systeme.
- [^]Re: syslog-ng
  
  Posté par Manu (page perso, ) le 13/12/2001 à 10:38. (lien). Évalué à 6.
  Pas besoin.
  Tu changes le niveau de log des messages de netfilter et tu ajoutes la bonne ligne dans ton syslog.
  Moi j'ai mis le niveau alert qui ne semble quasiment pas utilisé.
  - [^]Re: syslog-ng
    
    Posté par Tame () le 13/12/2001 à 21:07. (lien). Évalué à 0.
    Encore mieux, on rajoute un truc pour dans les sources de syslogd, c'est pas bien complique :)
  - [^]Re: syslog-ng
    
    Posté par LeAg () le 14/12/2001 à 14:48. (lien). Évalué à 3.
    Tu peux aussi utiliser un niveau "Local[0-7]"
    cf. man syslog.
    
    Ils sont la, alors autant s'en servir !!!

L'article est très technique

Posté par Sébastien Koechlin () le 12/12/2001 à 17:42. (lien). Évalué à 27.

La solution proposé est un mécanisme qui permet de se rendre compte lorsque les logs ont été trafiqués.

Ça ne règle pas le problème de l'effacement des logs. Une fois que les lignes ont disparu, il est toujours impossible de savoir ce qu'il s'est produit.

On n'a pas encore fait mieux que l'universitaire (j'ai oublié son nom) traquant Pengo (le pirate allemand) avec une batterie d'imprimantes matricielles ;-)

[^]Re: L'article est très technique

Posté par DPhil (page perso, ) le 12/12/2001 à 17:48. (lien). Évalué à 12.
On peut aussi déporter ses logs vers une autre machine du réseau. Ca se fait sous BSD, je ne sais pas si on peut le faire sous Linux, mais le contraire m'étonnerait tout de même bien.
- [^]Re: L'article est très technique
  
  Posté par Thomas Cataldo (page perso, ) le 12/12/2001 à 19:16. (lien). Évalué à 22.
  Oui, c'est possible. Il y a aussi un patch pour le kernel qui permet que les logs des plantages kernels (oops) soit envoyés sur une autre machine (parce que sinon, il faut tout recopier sur un papier pour faire un bug report). Evidemment si c'est le driver de carte réseau qui a planté, ca marche pas.

[^]Re: L'article est très technique

Posté par Jerome Demeyer () le 12/12/2001 à 17:49. (lien). Évalué à 27.
il est aussi possible d'envoyer toutes les logs sur un serveurs dédié, avec du disque et un lecteur de bande pour les archiver : il suffit de rajouter la ligne "*.* @logger" à son syslog.conf (ou logger est le nom de la bécane spécialisée).

Sur le serveur de log, on sait quelle machine écrit quoi, car chaque ligne est précédée d'un timestamp et d'un hostname.

Un tel serveur de logs ne devrait pas proposer d'autres services (meme un ssh) et on ne pourrait s'y connecter que directement (sur la console).

Là, on à déjà un système bien sécurisé.
- [^]Re: L'article est très technique
  
  Posté par Jean-Michel Kelbert () le 12/12/2001 à 18:56. (lien). Évalué à 14.
  Sauf si tu as un root kit d'installer sur la bécane qui envoie de faux logs...
  C'est comme pour tripwire, il faut partir d'une basse saine avant d'installer une telle configuration. Sinon ca ne sert à rien du tout.
  - [+] [^]Re: L'article est très technique
    
    Posté par Jerome Demeyer () le 12/12/2001 à 19:03. (lien). Évalué à -3.
    Effectivement, la sécurité se pense _avant_ et pendant que l'on pense une infrastructure informatique : la sécurité doit être globale et bien pensée : la moindre brèche dans un mur met tout l'immeuble en péril...
    - [+] [^]Re: L'article est très technique
      
      Posté par woof () le 12/12/2001 à 19:20. (lien). Évalué à -2.
      la moindre brèche dans un mur met tout l'immeuble en péril...
      
      pas si c'est la dernière brique du dernier étage ;)
      
      quoi? stupide?
      rooh, -1
- [^]Re: L'article est très technique
  
  Posté par Henri () le 12/12/2001 à 21:03. (lien). Évalué à 19.
  Même mieux (d'après le vieux mais néanmoins très bon : "La sécurite sur l'internet : Firewalls" Oreilly) : une machine non connectée au réseau et reliée par série ou parallèle avec un bon prog monotâche qui écrit tout ce qu'on lui balance en entrée sur disque. Par rapport aux matricielles, pas de bruit, pas de consommables, par rapport à la solution ci-dessus : plus sûr !
  - [^]Re: L'article est très technique
    
    Posté par Laurent PELLISSIER () le 13/12/2001 à 09:24. (lien). Évalué à 9.
    Ou si l'on veut un peu plus de débit, on peut aussi faire ça avec un serveur UDP et un câble réseau 10/100 BaseT dont on aura coupé la paire TX (du côté du serveur d'archivage de log).
- [^]Re: L'article est très technique
  
  Posté par Sébastien BLAISOT () le 13/12/2001 à 12:48. (lien). Évalué à 3.
  oui, mais non, en fait.
  
  parce que si un pirate a pris la main sur ta machine qui a un "*.* @logger", qu'est-ce qui l'empche de générer un déni de service en lancant tout plein de logs sur ton serveur de logs ?
  
  voir meme, depuis l'exterieur (i.e. il a encore rien pénétré), il fait générer du log à une machine (plein de mauvaise connection ou passwd par ex).
  la machine innonde le serveur de logs, qui part en rideaux, et qui ne voit rien de la suite de l'attaque, notamment le meilleur moment, celui de la pénétration (sans arriere pensée aucune, bien entendu).
  
  De plus, le problème avec la majorité des syslogs, c'est que soit tu empeche tout le monde de te balancer des logs, soit tu autorise tout le monde a t'en envoyer. La solution que tu décris ne peux donc etre REELLEMENT utilisée en prod et secure QUE si tu protege en plus ton serveur de logs par un firewall.
  
  suis-je clair ?
  - [+] [^]Re: L'article est très technique
    
    Posté par Jerome Demeyer () le 13/12/2001 à 13:55. (lien). Évalué à -5.
    Je comprend bien la problématique des DoS que tu soulèves, mais je ne vois pas bien l'interêt du firewall...
    
    Afin de limiter les répercussion des dénis de services, plusieurs propositions :
    - Mettre pas mal de disques sur la bécane :)
    - faire un cron qui checke régulièrement la taille des logs, et qui les tournent/gzip dès qu'elles atteignent 10Megs (par exemple)
    - les logs gzippés doivent du coup être archivées dans un répertoire à part, sur un filesystème distinct
    - ce filesystem distinct est automatiquement sauvegardé sur bande dès qu'il dépasse un quota d'utilisation (par exemple de 60%). les logs archivées sur bandes sont supprimées. Les paranoïaques pourront archiver sur WORM¹ de 5.2Go.
    
    d'autres améliorations peuvent être apportées, mais le gzip divise par 100 la taille d'une log...
    
    1-WORM = Write Once, Read Many - c'est un peu comme un CDR de 1.3, 2.6 ou 5.2 Go.
    - [^]Re: L'article est très technique
      
      Posté par Sébastien BLAISOT () le 14/12/2001 à 14:20. (lien). Évalué à 3.
      Il y a en fait 2 problèmes distincts :
      
      1) quand syslog ecoute sur le réseau pour qu'on lui envoie des logs (cas du serveur de logs), il ecoute TOUT LE MONDE. c'est a dire que TOUTE machine qui a acces au serveur de logs peut lui envoyer des logs qu'il stockera.
      Pour limiter cela et pour choisir quelles machines peuvent envoyer des logs au serveur de logs, on peut soit utiliser un firewall (sur le serveur de logs ou mieux, entre le serveur de logs et le reste), soit utiliser syslog en mode inetd, en utilisant un TCPwrapper.
      De plus, tes adresses pouvant etre spoofées, et comme on est en UDP et qu'il n'y a pas de retour de connection, ce n'est qu'une protection limitée.
      
      2) le serveur peut etre innondé de logs, ce qui générera un DoS.
      un DoS ne se fait en général pas en 20 ans, mais tres rapidement.
      - mettre beaucoup de disque, c'est retarder l'échéance, mais ca ne résoud en rien le pb. le DoS prendra juste un peu plus de temps.
      - si on souhaite utiliser un script en crontab, alors il doit etre lancé tres souvent, ce qui peut impliquer d'autres problèmes.
      - gzipper un log, c'est long et ca utilise plein de ressources. si tu le fait alors meme que tu es en train de recevoir une enoooorme quantité de logs, ca va pas arranger les choses et ca risque meme d'accelerer ton DoS
      
      Evidemment, avec une machine 32 procs <mettez ici le processeur le plus puissant que vous connaissez>, 20Go de RAM et 200To de disque dur, connecté au serveur qui balance les logs par un triple lien gigabit, ca devrait deja limiter les DoS, mais tout dépend aussi du budget qu'on s'autorise.
      - [^]Re: L'article est très technique
        
        Posté par Jerome Demeyer () le 14/12/2001 à 22:30. (lien). Évalué à 2.
        1- Pour ce qui est d'écouter 'tout le monde', c'est vrai mais un serveur de logs n'est pas sensé être connecté à autre chose que le réseau interne. Donc s'il s'agit de recevoir les logs de serveurs dans une DMZ (web, ftp, etc) alors oui, il faut soit configurer le firewall, ou surout mettre la bécane sur le réseau fermé d'administration de la dmz.
        
        2- Les DoS sont très difficiles à gérer. Je propose des solutions (d'ailleurs je ne comprend pas bien la mojorité de [-] que je me suis pris pour les proposition, mais bon...), tu poses à ces solutions des limites réelles, c'est bien. J'aimerais savoir ce que tu proposes, toi qui semble avoir réfléchit au problème, parce que moi je devient à court ?
        
        Je pense que d'une part les DoS sur les logs sont assez rares, et d'autre part vaut t'il mieux qu'un serveur de logs tombe plutôt que ce soit le serveur web (ou autre). En tant qu'admin, on ne supporterais pas la moindre bécane en rade, mais le client ne préfèrerait il pas que les frontaux restes debouts, pour assurer la continuité du service ?

[^]Re: L'article est très technique

Posté par Olivier Jeannet () le 13/12/2001 à 17:04. (lien). Évalué à 3.
Ça ne règle pas le problème de l'effacement des logs. Une fois que les lignes ont disparu, il est toujours impossible de savoir ce qu'il s'est produit.

Je ne comprends pas ta remarque, tu as l'air de ne pas avoir compris le système. Le système qui est envisagé empêche d'effacer des lignes dans les logs, sinon le "check" retourne une erreur, puisque au départ on a une clef (secrète) et ensuite cette clef est recalculée avec chaque nouvelle ligne. S'il manque une ligne (ou plusieurs), on obtient une clef différente à la fin.

Log centralisés

Posté par Euclide (page perso, ) le 12/12/2001 à 17:56. (lien). Évalué à 4.

Une autre méthode simple de protection consiste a utiliser les fonctions réseau de syslogd.

et d'ajouter
*.* logserver en tete du fichier de conf de syslog.

Bon il faut évidemment que la machine logueuse soit protégée mais ca c'est pas trop compliqué.

[^]Re: Log centralisés

Posté par Sébastien BLAISOT () le 13/12/2001 à 12:55. (lien). Évalué à 6.
oui, mais il ne faut pas oublier que centraliser les logs, et en avoir plein sur une seule machine bien protégée, c'est bien, mais ca ne sert a rien sans quelqu'un qui les étudie minutieusement et REGULIEREMENT.
or, ce qu'il manque le plus souvent, c'est un admin qui mette en place un outil de filtrage/tri des logs et qui passe le temps nécessaire à étudier le résultat.

autre methode

Posté par tfing () le 12/12/2001 à 18:33. (lien). Évalué à 15.

une autre methode pour rendre les logs beaucoup plus difficile a modifier est de les mettre en mode append_only (seul l'ajout de donnees a la fin du fichier est autorise)

il y a plusieurs methodes pour cela :
- soit en utilisant chattr
- soit en utilisant les patchs du kernel LIDS (http://www.lids.org(...))

de cette maniere, un mechant pirate qui aurait pris le controle sur votre systeme ne pourrait pas enlever ses traces, seulement en ajouter (niark, niark !)

[^]Re: autre methode

Posté par Jerome Demeyer () le 12/12/2001 à 19:12. (lien). Évalué à 7.
un "chattr -a /var/log/*" semble pratique, mais se détecte facilement dès que l'on essaye de modifier une log en tant que root... et en plus la rotation des logs n'en est que plus lourdre à gérer (il faut rajouter des pre-rotate et des post-rotate pour gérer ces droits).

Par contre, mettre des attributs append_only (-a) ou immutable (-i) sur des fichiers contenus dans un chroot ou un jail spécifique à un daemon, prison ne contenant ni utilisateur root ni de binaire chattr, devient réellement intéressant, voire recommandé.

C'est même la meilleure facon de faire (à mon avis, que de préparer un filesystem chrooté par daemon sur son serveur. De plus, avec un named pipe pour écrire les logs, celles ci ne seront meme pas visibles pour le daemon, donc pour le pirate ayant réussi à faire un buffer overflow...
- [^]Re: autre methode
  
  Posté par Mathieu Dessus (page perso, ) le 13/12/2001 à 00:35. (lien). Évalué à 7.
  Il y a une possibilite; on peut au demarrage, mettre les fichiers de log en "append only" (comme propose + haut), et juste appres, supprimer la possibilite de modifier les capabilites (et oui, c'est possible).
  Par contre c'est tres chiant, car pour supprimer (ou faire tourner) ces fichiers de logs, il faut rebooter et aller sur la console !

imprimante

Posté par dcantin () le 12/12/2001 à 18:36. (lien). Évalué à 5.

Il suffit d'imprimer les log sur une vieille imprimante matricielle en continu... simple(peut être pas) et efficace.

[^]Re: imprimante

Posté par f l () le 12/12/2001 à 18:41. (lien). Évalué à 2.
Faut penser a rajouter du papier régulièrement :p

[^]Re: imprimante

Posté par woof () le 12/12/2001 à 19:22. (lien). Évalué à 15.
j'imagine pas la tête de l'admin après 1 journée d'attaque sur son serveur ..

*SCRIITCH RIITCKHREIIIITCH SCRIIIKTCHKK RIIIGTCKHCHHH* etc .. ;)

[^]Re: imprimante

Posté par gle () le 12/12/2001 à 19:59. (lien). Évalué à 3.
Plus moderne : Pourquoi pas un CD-R ?
En se limitant à ne logguer sur ce support que les problèmes graves comme une attaque en cours, on doit avoir de quoi voir venir non ?
- [+] [^]Re: imprimante / GNI ?
  
  Posté par Nico () le 12/12/2001 à 20:42. (lien). Évalué à -2.
  je vois pas trop l'interet d'archiver sur CD une attaque en cours mais bon...
  - [^]Re: imprimante / GNI ?
    
    Posté par gle () le 13/12/2001 à 08:50. (lien). Évalué à 5.
    Ben, pour garder une trace et pouvoir retrouver le coupable et la façon dont il a réussi à s'introduire avant qu'il efface les logs.
    
    Un CD-R, ou une imprimante, ça a l'immense avantage que tu peux écrire dessus, mais pas effacer, donc la trace est inaltérable.
    Parceque la méthode décrite dans l'article permet de savoir si les logs ont été altérés, mais une fois qu'on sait que les logs ont été altérés, on n'en sait pas plus sur ce qui a bien pu se passer. Bref, c'est pas vraiment instructif pour savoir où était la faille et comment patcher le trou.
    
    Hors-sujet : Pourquoi mon post au-dessus est à -1/12 ? Yeupou n'a finalement pas tort.
    - [^]Re: imprimante / GNI ?
      
      Posté par Nico () le 13/12/2001 à 09:56. (lien). Évalué à 8.
      l'avantage d'une imprimante matricielle, c'est qu'elle t'imprime les logs au fur et à mesure qu'ils arrivent (tail -f log )...
      Pour un CD, je vois mal graver 1 ligne de log ( 1 session CD ) toutes les secondes !
      Y'a quand meme des problemes de synchro !

Pas une idée toute neuve...

Posté par Le_Maudit Aime () le 12/12/2001 à 20:51. (lien). Évalué à 5.

mais si Schneier y a pensé c'est que c'est une bonne idée...

Si vous voulez une description d'une usine à gaz qui fasse tout cela d'une manière sécurisée.
cf. http://www.counterpane.com/secure-logs.html(...)

Les logs au départ c pas pour la sécurité a long terme

Posté par alenvers () le 13/12/2001 à 01:03. (lien). Évalué à 17.

Les logs au départ c'est pas pour la sécurité a long terme, ca sert à monitorer l'acces en live ce qui est bcps plus compliqué (voir impossible) à modifier pour méchant cracker.

Si on veut faire des vérifications a posteriori, il faut mettre en oeuvre d'autres techniques. Pour la détection de falsification des md5sum doivent suffire (y faut encore les stocker dans un endroit sur - autre serveur, cryptage, etc - et les générer en temps réel, immédiatement quand le log est généré).
Pour conserver les traces, il faut les stocker sur un (voir des) autre serveur et les transférer de manière sécurisée en employant des méthodes d'encryption.

Ces techniques sont simple et néanmoin lourde à mettre en oeuvre. Mais bon pour la plus part l'envoi d'un mail (sur un autre serveur) en direct lors de l'apparition de problème devrait suffir.

[^]Re: Les logs au départ c pas pour la sécurité a long terme

Posté par Aza () le 13/12/2001 à 09:12. (lien). Évalué à 4.
>Pour conserver les traces, il faut les stocker >sur un (voir des) autre serveur et les >transférer de manière sécurisée en employant des >méthodes d'encryption.

Le vrai problème que pose AMHA les logs ca n'est pas les logs en eux mêmes c'est qu'il faut les lires et savoir quoi logguer. Logguer plein de trucs ca permet certes de produire des beaux graphiques mais franchement combien de boites ont une politique efficace de verification des logs et savent s'organiser en cas de problème pour voir vraiment ce qui a été et ce qui n'a pas été ? Tres peu a mon avis.

Si un gus fait un troyen qui utilises des requetes basé sur les ports reservés au DNS pour passer le firewall (je crois que nameserver c'est le port 42 mais j'en suis plus sur du tout) il a peut de chance qu'on le voit : franchement qui regarde les logs d'un DNS ?

Bref le problème encore une fois de plus est humain, pour la sécurité des logs comme dit plus haut, il existe déja des solutions techniques.
- [^]Re: Les logs au départ c pas pour la sécurité a long terme
  
  Posté par Benoît Sibaud (Jabber id, page perso, ) le 13/12/2001 à 09:17. (lien). Évalué à 2.
  $ grep nameserver /etc/services
  nameserver 42/tcp name # IEN 116
  domain 53/tcp nameserver # name-domain server
  domain 53/udp nameserver
- [^]Re: Les logs au départ c pas pour la sécurité a long terme
  
  Posté par alenvers () le 13/12/2001 à 09:31. (lien). Évalué à 2.
  Oui, le plus gros problème c'est la lecture. C'est pour ca qu'il faut automatiser les choses avec des scripts au maximum... Comme on lit plus souvent ses mails que ses logs (c mon cas), l'envoi d'un mail en cas de problème (détection de scan important, intrusion, ...) est un bon début.
  
  PS : Pour bien faire, il faut tout logger !

Une alternative...

Posté par j () le 13/12/2001 à 15:40. (lien). Évalué à 8.

Une autre alternative a syslog : metalog. Pas de cryptage, mais tout simple a mettre en place, et ca permet d'executer des scripts quand certaines expressions rationnelles sont trouvees (genre envoi de mail quand il y a une partition pleine) .

http://metalog.sf.net(...)

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Articles : Vous fiez-vous à vos logs système ?

C'est pas mal...

[^]Re: C'est pas mal...

[^]Re: C'est pas mal...

[^]Re: C'est pas mal...

[^]Re: C'est pas mal...

syslog-ng

[^]Re: syslog-ng

[^]Re: syslog-ng

[^]Re: syslog-ng

[^]Re: syslog-ng

L'article est très technique

[^]Re: L'article est très technique

[^]Re: L'article est très technique

[^]Re: L'article est très technique

[^]Re: L'article est très technique

[+] [^]Re: L'article est très technique

[+] [^]Re: L'article est très technique

[^]Re: L'article est très technique

[^]Re: L'article est très technique

[^]Re: L'article est très technique

[+] [^]Re: L'article est très technique

[^]Re: L'article est très technique

[^]Re: L'article est très technique

[^]Re: L'article est très technique

Log centralisés

[^]Re: Log centralisés

autre methode

[^]Re: autre methode

[^]Re: autre methode

imprimante

[^]Re: imprimante

[^]Re: imprimante

[^]Re: imprimante

[+] [^]Re: imprimante / GNI ?

[^]Re: imprimante / GNI ?

[^]Re: imprimante / GNI ?

Pas une idée toute neuve...

Les logs au départ c pas pour la sécurité a long terme

[^]Re: Les logs au départ c pas pour la sécurité a long terme

[^]Re: Les logs au départ c pas pour la sécurité a long terme

[^]Re: Les logs au départ c pas pour la sécurité a long terme

Une alternative...