traitement d incident analyse computing element
Download
Skip this Video
Download Presentation
Traitement d'incident: analyse Computing Element

Loading in 2 Seconds...

play fullscreen
1 / 14

Traitement d'incident: analyse Computing Element - PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Traitement d'incident: analyse Computing Element' - omar-scott


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”

slide2
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-, 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

ad