Traitement d'incident: analyse Computing Element

1. Traitement d'incident: analyse Computing Element Pierre Girard (pierre.girard@in2p3.fr) French ROC deputyCC-IN2P3 administrator Activité SA1: “European Grid Support, Operation and Management”

2. Plan • Rappel du fonctionnement du LCG-CE • Installation et vérification du CE • Suivi d’incident sécurité • Conclusion 2

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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 girardpi@ccali41# 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 girardpi@ccali39# 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 girardpi@ccali39# 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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