Traitement d incident analyse computing element
This presentation is the property of its rightful owner.
Sponsored Links
1 / 14

Traitement d'incident: analyse Computing Element PowerPoint PPT Presentation


  • 60 Views
  • Uploaded on
  • Presentation posted in: General

Traitement d'incident: analyse Computing Element. Pierre Girard ( [email protected] ) French ROC deputy CC-IN2P3 administrator Activité SA1: “European Grid Support, Operation and Management”. Plan. Rappel du fonctionnement du LCG-CE Installation et vérification du CE

Download Presentation

Traitement d'incident: analyse Computing Element

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Traitement d incident analyse computing element

Traitement d'incident: analyse Computing Element

Pierre Girard ([email protected])

French ROC deputyCC-IN2P3 administrator

Activité SA1: “European Grid Support, Operation and Management”


Traitement d incident analyse computing element

Plan

  • Rappel du fonctionnement du LCG-CE

  • Installation et vérification du CE

  • Suivi d’incident sécurité

  • Conclusion

2


Fonctionnement du lcg ce

Fonctionnement du LCG-CE

  • Soumission classique

1) soumission de job sur une queue

2811

TCP PORT RANGE

2170

2119

gridftp

GRIS/BDII

Jobmanager

gatekeeper

4) Fork avec l’utilisateur choisi

LCAS

LCMAPS

5) Soumet au batch et suit la progression du job

3) Authorisation

2) Authentification

3


Fonctionnement du lcg ce1

Fonctionnement du LCG-CE

  • Fork d’un programme sur le CE

1) globus-job-run/submit en mode fork

2811

TCP PORT RANGE

2170

2119

gridftp

GRIS/BDII

Jobmanager

gatekeeper

4) Fork avec l’utilisateur choisi

LCAS

LCMAPS

JeFaisCeQueJeVeux.sh

3) Authorisation

2) Authentification

4


Fonctionnement du lcg ce2

Fonctionnement du LCG-CE

  • Accès au système de fichiers du CE

1) globus-url-copy/edg-gridftp-ls gsiftp://monce.fr/…

2811

TCP PORT RANGE

2170

2119

gridftp

GRIS/BDII

Jobmanager

gatekeeper

4) Accès au FS avec l’utilisateur choisi

LCAS

LCMAPS

Système de fichiers du CE

3) Authorisation

2) Authentification

5


Installation et v rification du ce

Installation et vérification du CE

  • Doit être paranoïaque car le lcg-CE est perméable

  • Quelques vérifications ne font pas de mal

    • Droits d’accès utilisateurs réglés sur « Strict Minimum »

      • $HOME des comptes grille peuvent contenir les proxies

      • ~glite/.certs/ contient une copie du certificat serveur

      • Petites vérifications

        • find /home \( -type f -o -type d \) -perm -\a+r -ls 2>/dev/null

    • Attention à ce que vous mettez et aux droits dans des répertoires comme /tmp

    • Un outil « tripwire »-like est indispensable pour les invariants

    • Un petit « ps » de temps en temps pour voir ce qui tourne

  • Réglage des logs

    • Si possible avec redirection sur une machine

      • Syslogd –r; syslod-ng; etc.

    • Rétention de 90 jours des logs

6


Suivi d incident s curit

Suivi d’incident sécurité

  • Use Case: vol d’un certificat

    • Vous disposez du DN

      • /O=GRID-FR/C=FR/O=CNRS/OU=CC-LYON/CN=Pierre Girard

    • De la période supposée du vol

  • Actions

    • Bannissement du DN (LCAS)

    • Etablir l’historique d’utilisation

    • Faire des autopsies quand « core » du délit il y a

    • Nettoyer

    • Communiquer

  • Acteurs

    • coordinateur sécurité

      • Coordonne le suivi d’incident, connaît les procédures et les réseaux de sécurité

    • Ingénieur système

      • Connaît l’installation des machines, intervient dessus et sait les faire parler, fournit des informations sur l’utilisation de la machine

    • Ingénieur réseau

      • Fournisseur d’information sur les connexions de et vers les machines visitées

7


Suivi d incident s curit1

Suivi d’incident sécurité

  • Bannissement du DN (LCAS)

    • Sur le CE

      cclcgceli07_root# echo '"/O=GRID-FR/C=FR/O=CNRS/OU=CC-LYON/CN=Pierre Girard"' >> /opt/glite/etc/lcas/ban_users.db

    • Resultat (depuis une UI)

      # Creation du proxy

      [email protected]# voms-proxy-init --voms dteam

      Enter GRID pass phrase:

      Your identity: /O=GRID-FR/C=FR/O=CNRS/OU=CC-LYON/CN=Pierre Girard

      Creating temporary proxy ...................................... Done

      Contacting voms.cern.ch:15004 [/DC=ch/DC=cern/OU=computers/CN=voms.cern.ch] "dteam" Done

      Creating proxy .................................... Done

      Your proxy is valid until Thu Apr 2 11:13:33 2009

      # Soumission

      [email protected]# globus-job-run cclcgceli07.in2p3.fr:2119/jobmanager-bqs-short /bin/hostname

      GRAM Job submission failed because authentication with the remote server failed (error code 7)

      # Accès gridftp

      [email protected]# edg-gridftp-ls gsiftp://cclcgceli07.in2p3.fr/

      /opt/edg/libexec/edg-gridftp-base-ls: error globus_ftp_client: the server responded with an error

      530 530-Login incorrect. : globus_gss_assist: Error invoking callout

      530-globus_callout_module: The callout returned an error

      530-an unknown error occurred

      530 End.

8


Etablir l historique d utilisation

Etablir l’historique d’utilisation

  • /var/log/globus-gatekeeper.log

    • Mélange de logs

      • Globus-gatekeeper (format sur 2 lignes)

      • LCAS et LCMAPS

      • Globus-jobmanager

    • Plus facile à exploiter avec syslog: 

      • Manque de doc pour les règles du syslog

      • Ex.:

        • daemon.* => globus-gatekeeper + globus-jobmanager

    • On y trouve par commande reçue

      • Type (ping, jobmanager-<lrms>, jobmanager-fork)

      • DN de l’utilisateur

      • IP de la machine cliente

      • Mapping vers le compte et groupe local

      • EDG_WL_JOBID (si existe)

        • https://grid02.lal.in2p3.fr:9000/aDLqxhIdEwsIiGnU_FPQPw

9


Etablir l historique d utilisation1

Etablir l’historique d’utilisation

  • Logs du serveur GRID-FTP

    • Ce qu’un utilisateur a lu ou écrit sur votre CE

    • 2 fichiers de logs, plutôt redondants, mais complémentaires

      • /var/log/globus-gridftp.log (presque tout)

        • Action (TYPE: STOR, RETR, NLST)

        • Compte local (USER)

        • IP du client (DEST)

        • Fichier ou directory (FILE)

          DATE=20090401223721.481476 HOST=cclcgceli07.in2p3.fr PROG=globus-gridftp-server NL.EVNT=FTP_INFO START=20090401223721.431880 USER=dteam001FILE=/tmp BUFFER=0 BLOCK=262144 NBYTES=167 VOLUME=/ STREAMS=1 STRIPES=1 DEST=[134.158.240.61]TYPE=NLST CODE=226

      • /var/log/gridftp-session.log (important pour les comptes partagés)

        • DN de l’utilisateur

        • Compte local

        • Hostname du client

        • Ce qui a été accédé (mais pas comment)

10


Etablir l historique d utilisation2

Etablir l’historique d’utilisation

  • Les logs du LRMS

    • Exemple LCG-CE PBS (@Eygene Ryabinkin)

      • /opt/edg/var/gatekeeper/grid-jobmap_*: summaries of job run by lcgpbs and friends.

      • /var/spool/pbs/server_priv/accounting/*: Torque logs that carry most activity traces, we are mainly interested in start/end events.

      • /var/spool/pbs/server_logs/*: carry more verbose Torque logs, but exist only on the Torque server, not necessarily on the CE.

    • Doit vous permettre de retrouver l’historique des jobs sur les WNs

      • Facilite la vie si à la soumission le DN est « attaché » au job

11


Autopsie de tout ce qui a t trouv

Autopsie de tout ce qui a été trouvé

  • L’analyse des logs et la concertation entre acteurs

    • Identifier le ou les comptes locaux utilisés

    • Identifier les machines « visitées »

    • Identifier les actions entreprises via le MW

    • Trouver des « résidus »

  • Sur chaque machine impactée

    • Pratiquer des autopsies (si possible, « in vivo »)

      • « lsof » sur les process de l’intrus

      • « strings » des binaires

      • Sauvegarde des logs et fichiers de l’intrus

      • Etc.

    • Vérifier s’il a pu avoir accès à des « proxies » (ex.: myvo-sgm)

    • Vérifier les services systèmes: cron, mail, etc.

    • Faite un rapport d’autopsie

12


Nettoyer et communiquer

Nettoyer et communiquer

  • Nettoyer (Vous savez faire)

    • « kill » des process du ou des comptes utilisés

    • Suppression (après sauvergarde) des fichiers de l’utilisateur que vous avez identifiés

    • Nettoyage des configurations (ex.: crontab)

    • Etc.

  • Communiquer (coord. sécurité)

    • Rapport circonstancié aux instances de coordination « sécurité »

      • Description de l’utilisation de votre site

      • Liste exhaustive des machines externes contactées

      • Liste exhaustive des (DN, CA)s potentiellement exposés

    • Prévenir et obtenir des informations de vos confrères dont le site a été identifié comme « utilisé »

      • Ex.: Utilisation d’un WMS externe, son administrateur pourra vous fournir l’IP de l’UI

    • Contacter CA et VO, si vous suspectez le vol de certificats ou proxies

      • Ex.: Probable lors d’un mapping sur un compte partagé (dteamsgm)

13


Conclusion

Conclusion

  • LCG-CE est un agrégat de services

    • Tracer les agissements d’un individu demande de croiser les données sur le CE

    • Mais c’est faisable, voire automatisable (« parsing » de logs)

  • Si vous centralisez les logs

    • Vous pouvez analyser plusieurs machines d’un coup

    • N’hésitez pas à fouiller avant la période supposée de l’incident

      • La grille a une certaine inertie…

  • Vivement le « non-LCG »-CE

    • CREAM CE: plus de fork possible sur le CE

  • Service SCAS en cours de tests (avec glexec)

    • Permet de gérer la politique d’authentification/authorisation de façon centralisée

    • Et donc de bannir un DN plus simplement

14


  • Login