Vous fiez-vous à vos logs système ?

Posté par hideo le 12 décembre 2001 à 18:13. Modéré par Amaury.

Étiquettes : aucune

déc.

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.

Aller plus loin

L'article (32 clics)
Modular Syslog (26 clics)

# C'est pas mal...

Posté par VACHOR (site web personnel) le 12 décembre 2001 à 18:32. Évalué à 10.

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 décembre 2001 à 11:24. É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 freePK le 13 décembre 2001 à 15:16. É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 décembre 2001 à 16:50. É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 décembre 2001 à 12:56. É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 (site web personnel) le 12 décembre 2001 à 18:39. Évalué à 10.

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 (site web personnel) le 13 décembre 2001 à 01:19. É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 (site web personnel) le 13 décembre 2001 à 11:38. É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 décembre 2001 à 22:07. É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 décembre 2001 à 15:48. É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 décembre 2001 à 18:42. Évalué à 10.

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 (site web personnel) le 12 décembre 2001 à 18:48. Évalué à 10.
  
  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 (site web personnel) le 12 décembre 2001 à 20:16. Évalué à 10.
    
    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 décembre 2001 à 18:49. Évalué à 10.
  
  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 Jiquem le 12 décembre 2001 à 19:56. Évalué à 10.
    
    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 décembre 2001 à 20:03. É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 décembre 2001 à 20:20. É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 décembre 2001 à 22:03. Évalué à 10.
    
    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 décembre 2001 à 10:24. É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 décembre 2001 à 13:48. É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 décembre 2001 à 14:55. É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 décembre 2001 à 15:20. É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 décembre 2001 à 23:30. É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 décembre 2001 à 18:04. É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 (site web personnel) le 12 décembre 2001 à 18:56. É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 décembre 2001 à 13:55. É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 décembre 2001 à 19:33. Évalué à 10.

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 décembre 2001 à 20:12. É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 (site web personnel) le 13 décembre 2001 à 01:35. É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 décembre 2001 à 19:36. É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 décembre 2001 à 19:41. Évalué à 2.
  
  Faut penser a rajouter du papier régulièrement :p
- [^] # Re: imprimante
  
  Posté par woof le 12 décembre 2001 à 20:22. Évalué à 10.
  
  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 décembre 2001 à 20:59. É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 décembre 2001 à 21:42. É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 décembre 2001 à 09:50. É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 décembre 2001 à 10:56. É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 décembre 2001 à 21:51. É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(...)
# Commentaire supprimé

Posté par Anonyme le 13 décembre 2001 à 02:03. Évalué à 10.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Les logs au départ c pas pour la sécurité a long terme
  
  Posté par Aza le 13 décembre 2001 à 10:12. É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 (site web personnel) le 13 décembre 2001 à 10:17. Évalué à 2.
    
    $ grep nameserver /etc/services
    nameserver 42/tcp name # IEN 116
    domain 53/tcp nameserver # name-domain server
    domain 53/udp nameserver
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 13 décembre 2001 à 10:31. Évalué à 2.
    
    Ce commentaire a été supprimé par l’équipe de modération.
# Une alternative...

Posté par j le 13 décembre 2001 à 16:40. É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(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.