Seguridad en Unix y Redes

5,407 views
5,331 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
5,407
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Seguridad en Unix y Redes

  1. 1. SEGURIDAD EN UNIX Y REDES Versi´n 1.2 o Antonio Villal´n Huerta o 2 de octubre de 2000
  2. 2. 2
  3. 3. 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.
  4. 4. ii
  5. 5. ´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
  6. 6. 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
  7. 7. ´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
  8. 8. 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
  9. 9. ´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
  10. 10. 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
  11. 11. ´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
  12. 12. x ´ INDICE DE FIGURAS
  13. 13. ´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
  14. 14. xii ´ INDICE DE TABLAS
  15. 15. 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
  16. 16. 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.
  17. 17. 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
  18. 18. 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
  19. 19. ´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.
  20. 20. 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.
  21. 21. ´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
  22. 22. 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.

×