Next: Seguridad del entorno de
Up: Índice de Tablas Previous: Notas del autor Índice General
Subsecciones
Hasta finales de 1988 muy poca gente tomaba en serio el tema de la seguridad en
redes de computadores de propósito general. Mientras que por una parte
Internet iba creciendo exponencialmente con redes importantes que se adherían
a ella, como BITNET o HEPNET, por otra el auge de
la informática de consumo (hasta la década de los ochenta muy poca
gente se podía permitir un ordenador y un módem en casa) unido a
factores menos técnicos (como la película Juegos de Guerra,
de 1983) iba produciendo un aumento espectacular en el número de piratas
informáticos.
Sin embargo, el 22 de noviembre de 1988 Robert T. Morris protagonizó el
primer gran incidente de la seguridad informática: uno de sus programas
se convirtió en el famoso worm o gusano de Internet. Miles de ordenadores
conectados a la red se vieron inutilizados durante días, y las pérdidas
se estiman en millones de dólares. Desde ese momento el tema de la seguridad
en sistemas operativos 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 podía entrañar
un fallo o un ataque a los sistemas informáticos estadounidenses (en general,
a los sistemas de cualquier país) la agencia DARPA (
Defense Advanced Research Projects Agency) creó el 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 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ía se hace patente la preocupación
por los temas relativos a la seguridad en la red y sus equipos, y también
se hace patente la necesidad de esta seguridad. Los piratas de antaño casi
han desaparecido, dando paso a 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 Hacker's Quartely o Phrack son quizás las más
conocidas, pero no las únicas). Todo esto con un objetivo principal: compartir
conocimientos. Si hace unos años cualquiera que quisiera adentrarse en
el mundo underground casi no tenía más remedio que conectar
a alguna BBS donde se tratara el tema, generalmente con una cantidad de información
muy limitada, hoy en día tiene a su disposición gigabytes de información
electrónica publicada en Internet; cualquier aprendiz de pirata 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ía Juegos de Guerra creó una nueva generación
de piratas, en la segunda mitad de los noventa películas como The Net,
Hackers o Los Corsarios del Chip han creado otra generación,
en general mucho menos peligrosa que la anterior, pero cuanto menos, preocupante:
aunque sin grandes conocimientos técnicos, tienen a su disposición
multitud de programas y documentos sobre seguridad (algo que los piratas de los
ochenta apenas podían imaginar), además de ordenadores potentes
y conexiones a Internet baratas. Por si esto fuera poco, se ven envalentonados
a través de sistemas de conversación como el IRC ( Internet Relay
Chat), donde en canales como #hack o #hackers presumen
de sus logros ante sus colegas.
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ían
catalogar como confidenciales (nóminas, expedientes, presupuestos...)
o al menos como privados (correo electrónico, proyectos de investigación,
artí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 simplemente
de una cuestión de imagen: según el Computer Security Institute,
en su encuesta de 1998, las pérdidas económicas ocasionadas por
delitos relacionados con nuevas tecnologías (principalmente accesos internos
no autorizados) sólo en Estados Unidos ascienden anualmente a más
20.000 millones de pesetas, cifra que cada año se incrementa en más
del 35%; los delitos informáticos en general aumentan también de
forma espectacular año tras año, alcanzando incluso cotas del 800%
([Caj82]).
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 estudio 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 funcionamiento de
sus mecanismos, y su correcta utilización. También se hablará,
en menor medida, sobre temas menos técnicos pero que también afectan
directamente a la seguridad informática, como puedan ser el problema del
personal o la legislación vigente.
El objetivo final de este proyecto sería marcar unas pautas para conseguir
un nivel de seguridad aceptable en los sistemas Unix conectados en cualquier
red, entendiendo por 'aceptable' un nivel de protección suficiente para
que la mayoría de potenciales intrusos interesados en los equipos de nuestra
organización fracasara ante un ataque contra los mismos. Obviamente, es
imposible 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 es que cualquier
persona sea capaz de atacar con éxito un equipo simplemente por haber visto
una película, descargado un par de páginas web y ejecutado
un programa que ni ha hecho ni entiende.
Por supuesto, este proyecto no pretende ser en ningún momento una ayuda
para la gente que esté interesada en atacar máquinas Unix o subredes
completas, ni tampoco una invitación a hacerlo. Aunque por su naturaleza
la información aquí presentada puede ser utilizada para dañar
sistemas informáticos (como cualquier información sobre seguridad
informática), no es ese su propósito sino, como hemos dicho, incrementar
la seguridad de los sistemas Unix y las redes en las que éstos se ubican.
Por tanto va a intentar estar escrito de forma que no se pueda utilizar fácilmente
como una 'receta de cocina' para crackers; si alguien quiere un
documento sobre cómo atacar sistemas, puede dejar de leer este trabajo
y buscar en Internet información sobre ese tema. Conseguir romper la seguridad
de un sistema de forma no autorizada es, en la mayoría de los casos, un
sí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 hecho ni es capaz de entender,
que revise sus principios, y si tras hacerlo aún piensa lo mismo, que 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 seguros. Eso
es seguridad informática, y no lo que habitualmente se nos quiere hacer
creer: la seguridad informática no consiste en conocerse todos los
bugs de un sistema operativo, con sus 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ía cambie.
Podemos entender como seguridad una característica de cualquier
sistema (informático o no) que nos indica que ese sistema está libre
de todo peligro, daño o riesgo, y que es, en cierta manera, infalible.
Como esta característica, particularizando para el caso de sistemas operativos
o redes de computadores, es muy difícil de conseguir (según la mayoría
de expertos, imposible), se suaviza la definición de seguridad
y se pasa a hablar de fiabilidad (probabilidad de que un sistema se comporte
tal y como se espera de él) más que de seguridad; por tanto,
se habla de sistemas fiables en lugar de hacerlo de sistemas seguros.
A grandes rasgos se entiende que mantener un sistema seguro (o fiable)
consiste básicamente en 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 confiabilidad, entendida como el
nivel de calidad del servicio ofrecido. Consideran la disponibilidad como un aspecto
al mismo nivel que la seguridad y no como parte de ella, por lo que dividen esta
última en sólo las dos facetas restantes, confidencialidad e integridad.
En este trabajo no seguiremos esa corriente por considerarla minoritaria.
¿Qué implica cada uno de los tres aspectos de los que hablamos?
La confidencialidad nos dice que los objetos de un sistema han de ser
accedidos únicamente por elementos autorizados a ello, y que esos elementos
autorizados no van a convertir esa información en disponible para otras
entidades; la integridad significa que los objetos sólo pueden
ser modificados2.1 por elementos autorizados, 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 servicio. 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 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 prioridad a un cierto aspecto de la seguridad. Por ejemplo,
en un sistema militar se antepondrá la confidencialidad de los datos almacenados
o transmitidos sobre su disponibilidad: seguramente, es preferible que alguien
borre información confidencial (que se podría recuperar después
desde una cinta de backup) a que ese mismo atacante pueda leerla, o a
que esa información esté disponible en 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 unidad, pero que esa misma unidad no sea leída por usuarios autorizados
va a suponer una pérdida de tiempo y dinero. En un entorno bancario, la
faceta que más ha de preocupar a los responsables del sistema es la integridad
de los datos, frente a su disponibilidad o su confidencialidad: es menos grave2.2
que un usuario consiga leer el saldo de otro que el hecho de que ese usuario pueda
modificarlo.
Los tres elementos principales a proteger en cualquier sistema informático
son el software, el hardware 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 (cintas, CD-ROMs, diskettes...) o tarjetas de red. Por software
entendemos el conjunto de programas lógicos que hacen funcional al
hardware, tanto sistemas operativos como aplicaciones, y por datos
el conjunto de información lógica que manejan el software
y el hardware, como por ejemplo paquetes que circulan por un cable de
red o entradas de una base de datos. Aunque generalmente en las auditorías
de seguridad se habla de un cuarto elemento a proteger, los fungibles
(elementos que se gastan o desgastan con el uso contínuo, como papel de
impresora, tóners, cintas magnéticas, 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ícil de
recuperar2.3: con toda seguridad una máquina Unix
está ubicada en un lugar de acceso físico restringido, o al menos
controlado, y además en caso de pérdida de una aplicación
(o un programa de sistema, o el propio núcleo de Unix) este software
se 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 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ícil devolver los datos al estado en
que se encontraban antes de la pérdida.
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 amenazas. Generalmente, la taxonomía
más elemental de estas amenazas las divide en cuatro grandes grupos: interrupción,
interceptación, modificación y fabricación. Un ataque se
clasifica como interrupción si hace que un objeto del sistema se
pierda, quede inutilizable o no disponible. Se tratará de una interceptación
si un elemento no autorizado consigue un acceso a un determinado objeto del sistema,
y de una modificación si además de conseguir el acceso consigue
modificar el objeto; algunos autores ([Olo92]) consideran un caso especial de la modificación:
la destrucción, entendiéndola como una modificación
que inutiliza al objeto afectado. Por último, se dice que un ataque es
una fabricación si se trata de una modificación destinada
a conseguir un objeto similar al atacado de forma que sea difícil distinguir
entre el objeto original y el 'fabricado'. En la figura 1.1 se muestran estos tipos de ataque de una forma gráfica.
Figura: Flujo normal de información
entre emisor y receptor y posibles amenazas: (a) interrupción, (b)
interceptación, (c) modificación y (d) fabricación.
|
|
En la gran mayoría de publicaciones relativas a la seguridad informática
en general, y especialmente 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 a los atacantes únicamente
como personas; esto tiene sentido si hablamos por ejemplo de responsabilidades
por un delito informático. Pero en este trabajo es preferible hablar de
'elementos' y no de personas: aunque a veces lo olvidemos, nuestro sistema puede
verse perjudicado por múltiples entidades aparte de humanos, como por ejemplo
programas, catástrofes naturales o, por qué no, 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 haya abducido un disco duro...
A continuación se presenta una relación de los elementos que potencialmente
pueden amenazar a nuestro sistema. No pretende ser exhaustiva, ni por supuesto
una taxonomía formal (para este 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á en aspectos de algunos de los elementos presentados
aquí.
No podernos engañarnos: la mayoría de ataques a nuestro sistema
van a provenir en última instancia de personas que, intencionada o inintencionadamente,
pueden causarnos enormes pérdidas. Generalmente se tratará de piratas
que intentan conseguir el máximo nivel de privilegio posible aprovechando
alguno (o algunos) de los riesgos lógicos de los que hablaremos a continuación,
especialmente agujeros del software. Pero con demasiada frecuencia se
suele olvidar que los piratas 'clásicos' no son los únicos que amenazan
nuestros equipos: es especialmente preocupante que mientras que hoy en día
cualquier administrador mínimamente preocupado por la seguridad va a conseguir
un sistema relativamente fiable de una forma lógica (permaneciendo atento
a vulnerabilidades de su software, restringiendo servicios, utilizando
cifrado de datos...), pocos administradores tienen en cuenta factores como la
ingeniería social o el basureo a la hora de diseñar una polí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 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.
- Personal
Las amenazas a la seguridad de un sistema provenientes del personal de la
propia organización 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 personal ajeno a la infraestructura informática (secretariado, personal
de seguridad, personal 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 los sistemas...y sus debilidades),
lo normal es que más que de ataques se trate de accidentes
causados por un error o por desconocimiento2.4 de las normas básicas de seguridad: un empleado
de mantenimiento que corta el suministro eléctrico para hacer una reparación
puede llegar a ser tan peligroso como el más experto de los administradores
que se equivoca al teclear una 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í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 datos perdidos ni para restaurar un hardware
dañado o robado.
- Ex-empleados
Otro gran grupo de personas potencialmente interesadas en atacar nuestro sistema
son los antiguos empleados del mismo, especialmente los que no abandonaron
el entorno por voluntad propia (y en el caso de redes de empresas, los que
pasaron a la competencia). Generalmente, se trata de personas descontentas
con la organización que pueden aprovechar debilidades de un sistema
que conocen perfectamente para dañarlo como venganza por algún
hecho que no 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 simplemente conectarse
al sistema como si aún trabajaran para la organización (muchas
veces se mantienen las cuentas abiertas incluso meses después de abandonar
la universidad o empresa), conseguir el privilegio necesario, y dañarlo
de la forma que deseen, incluso chantajeando a sus ex-compañeros o
ex-jefes.
- Curiosos
Junto con los crackers, los curiosos son los atacantes más
habituales de sistemas Unix en redes de I+D. Recordemos que los equipos están
trabajando en entornos donde se forma a futuros profesionales de la informática
y las telecomunicaciones (gente que a priori tiene interés
por las nuevas tecnologías), y recordemos también que las personas
suelen ser curiosas por naturaleza; esta combinación produce una avalancha
de estudiantes o personal intentando conseguir mayor privilegio del que tienen
o intentando acceder a sistemas a los que oficialmente no tienen acceso. Y
en la mayoría de ocasiones esto se hace simplemente para leer el correo
de un amigo, enterarse de cuánto cobra un compañero, copiar
un trabajo o comprobar que es posible romper la seguridad de un sistema concreto.
Aunque en la mayoría de situaciones se trata de ataques no destructivos
(a excepción del borrado de huellas para evitar la detección),
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, 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, 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 de utilizar un escáner de seguridad contra el dominio
completo y luego atacar mediante un 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 nivel de conocimientos, desde los más novatos (y a veces
más peligrosos) hasta los expertos, 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.
- 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 simplemente por causar algún tipo de daño
en él. Por ejemplo, alguien puede intentar borrar 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ípicos ataques son la destrucción
de sistemas de prácticas o la modificación de páginas
web de algún 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 habitual en redes normales; suele afectar más a las
grandes - muy grandes - empresas o 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 parte2.5 generalmente para robar secretos (el nuevo diseño
de un procesador, una base de datos de clientes, información confidencial
sobre las posiciones de satélites espía...) o simplemente para
dañar la imagen 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 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ía de 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 experto en seguridad Cliff Stoll describe cómo piratas
pagados por el KGB soviético utilizaron redes y sistemas Unix dedicados
a I+D para acceder a organismos de defensa e inteligencia estadounidenses.
Bajo la etiqueta de 'amenazas lógicas' encontramos todo tipo de programas
que de una forma u otra pueden dañar a nuestro sistema, creados de forma
intencionada para ello ( software malicioso, también conocido como
malware) o simplemente por error ( bugs o agujeros). Una excelente
lectura que estudia las definiciones de algunas de estas amenazas y su implicación
en el sistema Unix se presenta en [GS96]; otra
buena descripción, pero a un nivel más general, se puede encontrar
en [Par81].
- Software incorrecto
Las amenazas más habituales a un sistema Unix provienen de errores
cometidos de forma involuntaria por los programadores de sistemas o de aplicaciones.
Una situación no contemplada a la hora de diseñar el sistema
de red del kernel o un error accediendo a memoria en un 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 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
contra nuestra máquina sin ni siquiera saber cómo funciona y
sin unos conocimientos mínimos de Unix; incluso hay exploits
que dañan seriamente la integridad de un sistema (negaciones de servicio
o incluso acceso root remoto) y están preparados para ser
utilizados desde MS-DOS, con lo que cualquier pirata novato (comúnmente,
se les denomina Script Kiddies) puede utilizarlos contra un servidor
y conseguir un control total de una máquina de varios millones de 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 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 útiles a ser peligrosas cuando las utilizan crackers
que buscan información sobre las vulnerabilidades de un host
o de una red completa.
La conveniencia de diseñar y distribuir libremente herramientas que
puedan facilitar un ataque es un tema peliagudo; incluso expertos reconocidos
como Alec Muffet (autor del adivinador de contraseñas Crack)
han recibido enormes críticas por diseñar determinadas herramientas
de 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 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 el esfuerzo que han realizado
(y nos han ahorrado) en pro de sistemas más seguros.
- Puertas traseras
Durante el desarrollo de aplicaciones grandes o de sistemas operativos es
habitual entre los programadores insertar 'atajos' en los sistemas habituales
de autenticación del programa o del núcleo que se está
diseñando. A estos atajos se les denomina puertas traseras, y con 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 se necesiten cuatro claves diferentes
de diez caracteres cada una pueden insertar una rutina para conseguir ese
acceso mediante una única 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 nos importa el método
que utilice para hacerlo) va a tener un acceso global a datos que no debería
poder leer, lo que obviamente supone un grave peligro para la integridad de
nuestro sistema.
- Bombas lógicas
Las bombas lógicas son partes de código de ciertos programas
que permanecen sin realizar ninguna función hasta que son activadas;
en ese punto, la función que realizan no es la original del programa,
sino que generalmente se trata de una acción perjudicial.
Los activadores más comunes de estas bombas lógicas pueden ser
la ausencia o presencia de ciertos ficheros, la ejecución bajo un determinado
UID o la llegada de una fecha concreta; 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á
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 traducciones) son canales de comunicación que permiten a un proceso
transferir información de 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.
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; sin embargo, es posible
su existencia, y en este caso su detección suele ser difícil:
algo tan simple como el puerto finger abierto en una máquina
puede ser utilizado a modo de covert 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 huésped), de forma que cuando el archivo se ejecuta,
el virus también lo hace, insertándose 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 será
el que hay que tener en cuenta a la hora de diseñar una política
de seguridad).
Aunque los virus existentes para entornos Unix son más una curiosidad
que una amenaza real, 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 arranque;
aunque se trata de daños menores comparados con los efectos de otras
amenazas, 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 ocasiones portando virus o aprovechando bugs
de los sistemas a los que conecta para dañarlos. Al ser difíciles
de programar su número no es muy elevado, pero el daño que pueden
causar es muy grande: el mayor incidente de seguridad en Internet fué
precisamente el Internet Worm, un gusano que en 1988 causó
perdidas millonarias al infectar y detener más de 6000 máquinas
conectadas a la red.
Hemos de pensar que un gusano puede automatizar y ejecutar en unos segundos
todos los pasos que seguiría un atacante humano para acceder a nuestro
sistema: mientras que una persona, por muchos conocimientos y medios que posea,
tardaría como mínimo horas en controlar nuestra red completa
(un tiempo más que razonable para detectarlo), un gusano 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 funciones ocultas (generalmente en
detrimento de la seguridad) sin el conocimiento del usuario; como el Caballo
de Troya de la mitología griega, al que deben su nombre, ocultan su
función 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 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 conseguir que cuando el administrador las
ejecute no vea la información relativa al atacante, como sus procesos
o su conexión al sistema; otro programa que se suele suplantar es
login, por ejemplo para que al recibir un cierto nombre de usuario y
contraseña proporcione acceso al sistema sin necesidad de consultar
/etc/passwd.
- Programas conejo o bacterias
Bajo este nombre se conoce a los programas que no hacen nada útil,
sino que simplemente se dedican a reproducirse hasta que el número
de copias acaba con los recursos del sistema (memoria, procesador, disco...),
produciendo una negación de servicio. Por sí mismos no hacen
ningún daño, sino que lo que realmente perjudica es el gran
número de copias suyas en el sistema, que en algunas situaciones pueden
llegar a provocar la parada total de la máquina.
Hemos de pensar hay ciertos programas que pueden actuar como conejos sin proponérselo;
ejemplos típicos se suelen encontrar en los sistemas Unix destinados
a prácticas en las que se enseña a programar al alumnado: es
muy común que un bucle que por error se convierte en 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 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.
- Técnicas salami
Por técnica salami se conoce al robo automatizado de pequeñas
cantidades de bienes (generalmente dinero) de una gran cantidad origen. El
hecho de que la cantidad inicial sea grande y la robada pequeña hace
extremadamente difícil su detección: si de una cuenta con varios
millones de pesetas se roban unos céntimos, nadie va a darse cuenta
de ello; si esto se automatiza para, por ejemplo, descontar una peseta de
cada nómina pagada en la universidad o de cada beca concedida, tras
un mes de actividad seguramente se habrá robado una enorme 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 más habitual es en sistemas bancarios; sin embargo,
como en una red con requerimientos de seguridad medios es posible que haya
ordenadores dedicados a contabilidad, facturación de un departamento
o gestión de nóminas del personal, comentamos esta potencial
amenaza contra el software encargado de estas tareas.
Las catástrofes (naturales o artificiales) son la amenaza menos probable
contra los entornos habituales: simplemente por su ubicación geográfica,
a nadie se le escapa que la probabilidad de sufrir un terremoto o una inundación
que afecte a los sistemas informáticos en una gran ciudad como Madrid,
Valencia o Barcelona, es relativamente baja, al menos en comparación con
el riesgo de sufrir un intento de acceso por parte de un pirata o una infección
por virus. Sin embargo, el hecho de que las catástrofres sean amenazas
poco probables no implica que contra ellas no se tomen unas medidas básicas,
ya que si se produjeran generarían los mayores daños.
Un subgrupo de las catástrofes es el denominado de riesgos poco probables.
Obviamente se 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 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 extraterrestre. Nada nos asegura
que este tipo de catástrofes no vaya a ocurrir, pero la probabilidad es
tan baja y los sistemas de prevención tan costosos que no vale la pena
tomar medidas contra ellas.
Como ejemplos de catástrofes hablaremos de terremotos, inundaciones, incendios,
humo o atentados de baja magnitud (más comunes de lo que podamos pensar);
obviamente los riesgos poco probables los trataremos como algo anecdótico.
De cualquier forma, vamos a hablar de estas amenazas 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 en caso de incendio.
Hasta ahora hemos hablado de los aspectos que engloba la seguridad informática,
de los elementos 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 protección de nuestros
sistemas. Cuando hayamos completado este punto, habremos presentado a 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 sufrir, las pérdidas que podrían generar,
y la probabilidad de su ocurrencia; a partir de este análisis hemos de
diseñar una polí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 garantizar la protección de los sistemas o de la propia red.
Figura 1.2: Visión global
de la seguridad informática
|
Los mecanismos de seguridad se dividen en tres grandes grupos: de prevención,
de detección y de recuperación. Los mecanismos de prevención
son aquellos que aumentan la seguridad de un sistema durante el funcionamiento
normal de éste, previniendo la ocurrencia de violaciones a la seguridad;
por ejemplo, el uso de cifrado en la transmisión de datos se puede considerar
un mecanismo 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 violaciones de la seguridad
o intentos de violación; ejemplos de estos mecanismos son los programas
de auditoría como Tripwire. Finalmente, los mecanismos de recuperación
son aquellos que se aplican cuando una violación del sistema se ha detectado,
para retornar a éste a su funcionamiento correcto; ejemplos de estos mecanismos
son la utilización de copias de seguridad o el hardware adicional.
Dentro de este último grupo de mecanismos de seguridad encontramos un subgrupo
denominado mecanismos de análisis forense, cuyo objetivo no es
simplemente retornar al sistema a su modo de trabajo normal, sino averiguar el
alcance de la violación, las actividades de un intruso en el sistema, y
la puerta utilizada para entrar2.6; 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 nuestro sistema, hemos de enfatizar en el uso de mecanismos de prevención
y de detección; la máxima popular 'más vale prevenir
que curar' se puede aplicar a la seguridad informática: para nosotros,
evitar un ataque, detectar un intento de violación, o detectar una violación
exitosa inmediatamente después de que ocurra es mucho más productivo
y menos comprometedor para el sistema que restaurar el estado tras una penetración
de la máquina. Es más, si consiguiéramos un sistema sin vulnerabilidades
y cuya política de seguridad se implementara mediante mecanismos de prevención
de una forma completa, no necesitaríamos mecanismos de detección
o recuperación. Aunque esto es imposible de conseguir en la práctica,
será en los mecanismos de detección, y sobre todo en los de prevención,
en los que centraremos nuestro trabajo.
Los mecanismos de prevención más habituales en Unix y en redes son
los siguientes ([Olo92]):
- Mecanismos de autenticación e identificación
Estos mecanismos hacen posible identificar entidades del sistema de una forma
única, y posteriormente, una vez identificadas, autenticarlas (comprobar
que la entidad es quién dice ser). Son los mecanismos más importantes
en cualquier sistema, ya que forman la base de otros 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 utilizados en la práctica.
- Mecanismos de control de acceso
Cualquier objeto del sistema ha de estar protegido mediante mecanismos de
control de acceso, 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, 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 de acceso obligatorio (MAC).
- Mecanismos de separación
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 objetos y entidades de diferentes niveles siempre
que no exista una autorización expresa del mecanismo de control de
acceso.
Los mecanismos de separación se dividen en cinco grandes grupos, en
función de como separan a los objetos: separación física,
temporal, lógica, criptográfica y fragmentación. Dentro
de Unix, el mecanismo de separación más habitual es el de separación
lógica o aislamiento, implementado en algunos sistemas mediante
una Base Segura de Cómputo (TCB).
- 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 en las comunicaciones, hemos de
utilizar ciertos mecanismos, la mayoría de los cuales se basan en la
Criptografía: cifrado de clave pública, de clave privada, firmas
digitales...Aunque cada vez se utilizan más los protocolos seguros
(como SSH o Kerberos, en el caso de sistemas Unix en red), aún es frecuente
encontrar conexiones en texto claro ya no sólo entre máquinas
de 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 robar contraseñas o suplantar
la identidad de máquinas de la red.
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, por ejemplo, la Base Segura de
Cómputo o las Listas de Control de Acceso, es la concienciación
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á unos conocimientos del
sistema operativo y de la red más o menos amplios (o mucha suerte) si 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.
En este trabajo, como ya hemos comentado, no se pretende ni mucho menos adentrarse
en temas de seguridad que se podría considerar 'de alto nivel', como la
necesaria en un entorno militar2.7,
de 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 - en el más amplio sentido
de la palabra -; un pequeño fallo en los sistemas encargados de lanzar
un satélite nos costaría a todos miles de millones de dólares...si
en lugar de ser un satélite es un 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.
Pero lo más probable es que todas estas cosas nos queden demasiado lejos
a la mayoría de mortales; para nosotros los problemas de seguridad diarios
son intrusiones, virus (sin comentarios), negaciones de servicio contra una máquina
que sirve páginas web...algo mucho más terrenal que todo
lo anterior. Es en este tipo de entornos donde los mecanismos que estudiaremos
se pueden aplicar más fácilmente, tanto por las caracterí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
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 aficionados a la piratería,
o que acaban de ver una película - de cuyo nombre no quiero acordarme -
y tratan de emular a los actores. Gente que ante la más mí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 tipo de
personas es contra quien debemos esforzarnos: ya hemos dicho que es inútil
intentar parar a un atacante profesional, pagado, o muy interesado en nuestras
máquinas; el que su ataque tenga éxito es sólo cuestión
de tiempo, y seguramente depende más de la suerte que tenga él frente
a la que tengamos nosotros. Pero estos atacantes son minoría, y lo que
debemos buscar es defendernos contra la mayoría.
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...), 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.
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 ninguna excepción, y aunque con demasiada
frecuencia su seguridad es mínima - o ni siquiera existe - merece la pena
invertir tiempo, y por qué no, dinero, para garantizar un mí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 su carácter extremadamente abierto:
mientras que una empresa puede limitar el acceso exterior a través de un
simple firewall, u ofrecer sólo determinados servicios al exterior
de la empresa, como unas páginas web, una red de I+D no puede permitirse
este carácter tan cerrado. Esto es debido a que el aspecto de la seguridad
más importante en las redes de investigación es la disponibilidad:
a todo el personal investigador le interesa que sus publicaciones sean lo más
accesibles a través de la web, al alumnado le interesa poder consultar
sus datos académicos desde casa, por Internet, etc. Y es muy difícil
hacerles cambiar de opinión, o al menos concienciarlos de los problemas
de seguridad 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, 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í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 investigación o centros universitarios.
En entornos de estas características no se suele trabajar con datos que
impliquen información valiosa para un espía industrial o militar,
ni tampoco se mueven grandes cantidades de dinero a través del comercio
electrónico; casi todo lo que un intruso va a encontrar en una máquina
de I+D son programas, documentos, resultados de simulaciones...que a muy poca
gente, aparte de sus autores, interesan.
Entonces, ¿contra quién nos enfrentamos? Muy pocos de los intrusos
que podamos encontrar en redes de I+D son piratas expertos; la mayoría
son gente poco experimentada, que incluso ataca nuestras máquinas desde
sus PCs en casa corriendo MS-DOS (desde 6.2 hasta 2000) sin saber
nada sobre Unix o redes. La mejor defensa contra estos individuos consiste simplemente
en cerrar los servicios que no sean estrictamente necesarios y mantener actualizado
el software de nuestras máquinas que se pueda considerar crítico
(núcleo, demonios, ficheros setuidados...). Casi todos ellos suelen actuar
movidos únicamente por el afán de conseguir un cierto status
en comunidades virtuales de piratas; ni siquiera actúan por curiosidad
o para ampliar sus conocimientos, con lo que tenemos una 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 fructíferos directamente dejarán el ataque para dedicarse
a objetivos más fáciles. En cuanto a los 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' para un intruso, como máquinas militares o de centros de
investigación muy importantes, como la 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 información de contacto se cita al final del proyecto junto
a la de otros organismos relacionados con la seguridad informática a distintos
niveles.
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 empresas disponen de una
LAN en el edificio donde están ubicadas, red que se puede aislar perfectamente
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 entre el router
y la red interna. Además, en muchos casos la LAN de la empresa ni siquiera
es realmente necesario que esté conectada a Internet, aunque esto cada
día es menos habitual más por requisitos humanos que técnicos:
aunque no haga falta para el trabajo la conexión a Internet, el 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ía; como siempre, casi perfecta: vamos a añadirle
problemas reales para comprobar 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 entre todas ellas
es corta y la empresa solvente, quizás se puedan permitir una red propia,
dedicada, y protegida por los técnicos de la propia compañía;
pero esto rara vez es así: conforme aumenta la separación, la idea
de la red dedicada se va difuminando (simplemente con una distancia de un par
de kilómetros - o menos, dependiendo de la zona - ya resulta imposible
esta aproximación). Ahora entra en juego una red de propósito general
como base de comunicaciones, seguramente la red telefónica, o incluso Internet;
la protección de la red ya no depende exclusivamente de nuestra organización,
sino que entran en juego terceras compañías - posiblemente Telefónica,
con todo 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 mantener comunicaciones seguras
entre las diferentes sucursales...pero no todas las compañías recurren
a estos mecanismos: realmente, es más fácil utilizar la red de propósito
general como si fuera segura, enviando por ella toda la información que
queramos intercambiar entre oficinas, sin proteger. Además, la seguridad
no suele ser tangible: seguramente nuestro jefe estará más contento
si en un día tiene montada la red aunque sea insegura, sin esperar a la
configuración de la red privada - evidentemente, más costosa -,
aunque a la larga resulte una solución mucho peor.
Compliquemos aún más la seguridad de nuestra compañía:
ahora entran en juego estaciones móviles, por ejemplo comerciales con portátiles
que deben comunicarse con los equipos fijos, o ejecutivos que al salir de viaje
de negocios quieren poder seguir leyendo su correo. Estas estaciones están
dando 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 viaje acabará conectado su portatil a la
línea telefónica de un hotel, y conectando con las máquinas
fijas vía módem. Por supuesto, esa persona ni ha oído
ni quiere oir hablar de conexiones cifradas: es más fácil un
telnet o un rlogin contra el servidor para poder leer el correo; a
fin de cuentas, los piratas son algo que sólo existe en las pelí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 no sólo quiere irse, sino que decide
llevarse varios documentos confidenciales, documentos a los que ha tenido un fácil
acceso simplemente acercándose a una de las impresoras comunes, recogiendo
los listados, y fotocopiándolos antes de entregarlos a su dueño.
O incluso más fácil: en nuestra 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 información entre empleados. Esa persona, sin ni siquiera
levantarse de su puesto de trabajo, tiene acceso a casi toda la información
de nuestra empresa...Por cierto, esto no pretende ser un ataque a la seguridad
de estos productos (aunque fácilmente podría serlo), sino una realidad
que se puede ver en muchísimas empresas, sobre todo pequeñas y medianas.
Como acabamos de ver, ha sido suficiente con plantear un par de situaciones -
de lo más normales - para romper toda la idea de seguridad fácil
que teníamos al principio; y eso sin plantear problemas más rebuscados:
¿qué sucede si a una empresa de la competencia le da por sabotear
nuestra imagen atacando nuestras páginas web? ¿y si le interesa
leer nuestros e-mails? No hace 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.
Las empresas dedicadas a ofrecer acceso a Internet a través de la línea
telefónica, así como otros servicios de red (principalmente, hospedaje
de páginas web) son los conocidos ISPs ( Internet Service
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 de máquinas Unix sabe
que cada puerto abierto en su sistema es una potencial fuente de problemas para
el mismo, por lo que conviene reducir al mínimo su número. Si los
ISPs viven justamente de permitir accesos - a Internet o a sus propios servidores
- parece obvio que no podrán aplicar estrictas políticas de seguridad
en las máquinas: mientras que por ejemplo en una empresa el administrador
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 de transferencia de
archivos que aplique criptografía, es muy probable que muchos de esos clientes
abandonen y se vayan a la competencia: es más fácil utilizar el
ftp clásico que instalar software adicional para poder
actualizar una página web.
Imaginemos un proveedor que ofrece conexión a Internet a sus clientes;
sin duda esos clientes querrán conectar a páginas web, hacer
IRC, transferir archivos o utilizar telnet. Nada problemático
a primera vista: las conexiones se realizan hacia el exterior de nuestra red,
no hacia el interior. Pero además esos clientes querrán utilizar
ICQ o NetMeeting, querrán instalar servidores de
todo tipo en sus máquinas para que sus amigos los utilicen - desde servicios
web hasta NFS -, 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 proveedor
(por supuesto, sin oir hablar de cifrado en la conexión) y también
les hace gracia un espacio para publicar sus páginas web de forma
permanente...y mucho mejor para ellos si se les permite programar e instalar sus
propios CGIs en dichas páginas; aquí ya no hay opción:
o simplemente se les niega esta última 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 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.
Sigamos añadiendo problemas: puestos a pedir, los usuarios también
pueden pedir acceso a bases de datos en sus páginas, por ejemplo vía
PHP3; ya nos afectan los problemas que pueda tener este tipo de
software. Incluso pueden querer instalar sistemas completos de comercio
electrónico, sistemas capaces de convertir nuestra red en un auténtico
agujero. Es más, si permitimos hospedaje de máquinas es muy probable
que el cliente que usa este servicio quiera acceder remotamente vía
telnet - o peor, rlogin-, incluso para tareas de administración;
ni oir hablar de cosas como SSH o SSL Telnet: a fin de
cuentas, hacen lo mismo y son más complicados que un sencillo telnet...
La seguridad de los ISPs sufre además el problema clásico de la
seguridad en cualquier entorno, pero quizás de una forma mucho más
grave: estamos trabajando con algo intangible, con algo muy difícil de
ver. Si se realiza una inversión de tiempo o dinero para adquirir equipos
nuevos, la mejora se nota inmediatamente; si esa inversión se realiza para
incrementar la seguridad, quizás las mejoras 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 más rápida frente a una conexión
o unos servicios más seguros.
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 ambientes underground no es raro encontrar
piratas con casi todas - o con todas - las claves de los clientes de un proveedor
(personalmente he conocido varios casos). Sólo tenemos un punto a nuestro
favor, si se puede considerar así: hace un par de años esas claves
eran algo más o menos valioso para un pirata, ya que con ellas conseguía
un acceso a Internet gratuito y - más importante - si dar ninguno de sus
datos. Hoy en día, y debido a empresas que ofrecen ese tipo de acceso -
por ejemplo como Alehop, con unas contraseñas genéricas
y gratuitas para todo el mundo -, las claves de los clientes de un ISP no son
algo tan codiciado.
En la década de los ochenta para mucha gente el concepto de seguridad
era algo inimaginable en el entorno Unix: la facilidad con que un experto podía
acceder a un sistema, burlar todos sus mecanismos de protección y conseguir
el máximo nivel de privilegio era algo de sobra conocido por todos, por
lo que nadie podía pensar en un sistema Unix seguro.
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 convirtió en
el primer sistema operativo en alcanzar niveles de seguridad quasi militares
([HJAW88], [Ser91]...). En la actualidad se puede considerar el
sistema operativo de propósito general más 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...), cualquier entorno Unix puede ofrecer los mecanismos de seguridad
suficientes para satisfacer las necesidades de la mayoría de instituciones.
Los Unices habituales, como Solaris o Linux, son bastante 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ínima
puesta a punto, en cuanto a seguridad se refiere, antes de ponerlos a trabajar
con unas mínimas garantías de fiabilidad. Una vez realizada esta
puesta a punto suelen tener una seguridad aceptable en redes de propósito
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 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 estos Unix seguros podemos encontrar AT&T System V/MLS y OSF/1 (B1),
Trusted Xenix2.8 (B2) y XTS-300 STOP 4.1 (B3), considerados los sistemas
operativos más seguros del mundo (siempre según la NSA). La gran
mayoría de Unices (Solaris, AIX...) están clasificados como C2,
y algunos 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 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 dentro de la gama de sistemas operativos
de propósito general; sin embargo, por alguna extraña razón,
mucha gente tiende a considerar todavía a los equipos Unix como amenazas
en la red, especialmente 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, inseguros: empresas tan importantes
como Yahoo! ( www.yahoo.com) o Citroën ( www.citroen.com),
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,
lo que motiva que algunas organizaciones intenten buscar sistemas alternativos,
casi siempre sustituyendo máquinas Unix por entornos Windows NT o Windows
9x. No creo que haga falta hacer comentarios sobre la seguridad de estos
sistemas, por lo que no entraremos en detalles sobre ella; si alguien está
interesado, o duda de la capacidad de Unix frente a estos entornos, puede consultar
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 el tipo de sistemas utilizados
en centros de investigación como AT&T y la NASA, o en organismos de
seguridad como el FBI y la NSA: Unix, por supuesto.
Notas al pie
- ... modificados2.1
- Por modificar entendemos escribir, cambiar, cambiar el estado, borrar
y crear.
- ... grave2.2
- Aunque por supuesto no es en absoluto recomendable.
- ... recuperar2.3
- Quizás no el más caro, pero sí el más difícil.
- ... desconocimiento2.4
- O inexistencia.
- ... parte2.5
- Si los pagara la organización propietaria de los equipos hablaríamos
de grupos Tigre.
- ... entrar2.6
- Si además los resultados se pretenden utilizar como pruebas ante
un tribunal, se habla de Informatoscopia ([Gal96a]).
- ... militar2.7
- Tampoco creo que fuera posible; a fin de cuentas, la seguridad de estos
sistemas sólo la conocen los militares...
- ... Xenix2.8
- Este sistema, de la compañía Trusted Information Systems,
Inc, obviamente no tiene nada que ver con el antiguo Microsoft Xenix,
de Microsoft Corporation
Next: Seguridad del entorno de
Up: Índice de Tablas Previous: Notas del autor Índice General
