Recomendaciones de seguridad en Sistemas Distribuidos 2

7. No usar la configuración "estándar"

Esto se puede considerar una generalización de la recomendación anterior. Por lo general los sistemas operativos y
las aplicaciones se instalan con una configuración determinada y de carácter genérico. En muchos casos el
administrador no tiene necesidad de modificarla pues el sistema aparentemente funciona bien. Sin embargo, los
atacantes al no tener conocimiento de la configuración de nuestro sistema, asumen que ésta es justamente la
"estándar", y programan sus ataques basados en dicha asunción.

Leí en algún lugar acerca de un administrador cuyo servidor web IIS fue atacado con éxito por "CodeRed", pero las
páginas web publicadas no fueron alteradas debido a que antes había decidido modificar en la configuración el
directorio donde se guardan los documentos html.

Ciertamente este tipo de cambios tienden a complicar el sistema puesto que sólo el administrador es consciente de
tales. Sin embargo esta complejidad también la padecerá el atacante. Lamentablemente muchas herramientas
"automáticas" de configuración, en su afán de hacer la vida del administrador más sencilla, no permiten hacer
modificaciones radicales. Esta tendencia a la homogeneidad en la configuración va en aumento.

Muchos administradores (y sus jefes) pretenden elevar la seguridad tan sólo a costa de comprar un producto costoso.
Imaginémonos una ciudad en la que todas las casas comprar un mismo modelo de cerradura. Entonces lógicamente
los ladrones se dedicarán sin parar a conseguir la llave correspondiente que les abrirá las puertas de todas las casas.
Ahora imaginemos otra ciudad en la que todos los habitantes son cerrajeros. Seguramente los ladrones dejarán de
pensar en las llaves y a no ser que encuentren otro mecanismo distinto, tendrán que mudarse.

8. La seguridad hacia el interior

Algunos reportes [12] han puesto de relieve que en una gran cantidad de casos la mayor amenaza de ataques al
sistema no proviene de fuera, sino que parte desde el interior de la organización. Muchos ataques exitosos desde el
exterior han necesitado de cierta ayuda inicial activada en el interior de la organización, donde por lo general nadie
sospecha de este tipo de prácticas.

Por tanto, el análisis de riesgos debe incluir posibles ataques originados en el interior, incluyéndose el robo de
contraseñas, la modificación de archivos de configuración, la desactivación de las barreras de protección, etc.
Un caso muy común de este tipo de ataque lo constituye el trabajador despedido o castigado que decide tomar
venganza. Antes de retirarse definitivamente puede efectuar este tipo de tareas maliciosas e incluso ponerse en
combinación con un atacante externo. En ciertos casos la simple introducción intencional de un virus puede acarrear
efectos devastadores.

La única manera de reducir el riesgo en estos casos, consiste en planificar el acceso al sistema de modo tal que
ningún elemento crítico dependa de una sola persona. Dicho de otro modo, para dañar un sistema, no debe bastar con
un único individuo disconforme.

Esto muchas veces no es posible con los sistemas operativos comerciales actuales (por ejemplo, con las estaciones
Windows 9x) y se hace aún más difícil si el despedido es el administrador! Algunos sistemas intentan por tanto
dividir las responsabilidades en diversos administradores, pero en el sector comercial todavía falta mucho camino por
recorrer. Los usuarios de Linux podrían interesarse en el sistema LIDS a fin de implementar esta recomendación.

9. Educar a los usuarios

Una de las mayores ayudas que puede recibir un hacker que intenta infiltrarse en el sistema de una organización
consiste en obtener información acerca de éste. En este sentido, las prácticas empleadas por el atacante comprenden
muchas veces la interacción encubierta con los usuarios de la organización a los cuales se les extrae (sin que tomen
conciencia de esto) una serie de datos útiles para el hacker. El caso más evidente consiste en obtener "como jugando"
una contraseña de parte de este incauto. Y ciertamente las contraseñas de los usuarios comunes suelen ser muy
malas, por lo que pueden liberarlas inadvertidamente al interlocutor en medio de una conversación aparentemente
inocente. Esto se suele denominar "Ingeniería Social".

La única forma de combatir esto es con educación para los usuarios. Por ejemplo, es necesario hacer que ellos sean
conscientes de este tipo de ataque (o entrevista), y que una de las mejores medidas a tomarse es el uso de contraseñas
suficientemente complicadas como para que no surjan de improviso en cualquier diálogo.

Otra recomendación (o norma obligatoria si se desea) consiste en que los usuarios no divulguen detalles acerca de la
configuración del sistema. Esta es una práctica increíblemente extendida: Auxiliares, programadores, ingenieros, e
incluso administradores, que en su deseo de hacer alarde del "super sistema" que utiliza su empresa, empiezan de
pronto a nombrar todos y cada uno de sus componentes, tanto de hardware como de software, con número de versión
incluido.

Esto puede ser inmediatamente aprovechado por el atacante, pues empezará a "disparar" los ataques ya conocidos
para ese hardware/software específico.

10. No confiar (totalmente) en nosotros mismos

Esto puede sonar extraño, sin embargo lo único que quiero indicar es la necesidad de que otra persona verifique la
seguridad de nuestro sistema. Como se sabe, existen empresas consultoras especializadas en auditar nuestra
organización con este fin. Si esta última opción no es posible (por ejemplo, por el costo involucrado) entonces es de
rigor solicitar a otro administrador o ingeniero que verifique las medidas que hemos considerado. En sistemas y redes
complejas es muy posible que una sola persona (nosotros) hayamos dejado pasar alguna puerta insegura. Mientras
más personas verifiquen nuestro trabajo, habrá más probabilidades de que éste esté adecuadamente realizado. Esta es
la idea que está detrás de mucho software Open Source, siendo el Kernel de Linux el caso más conspicuo.

Naturalmente evitaremos mostrar estos detalles a personas ajenas a la organización, a fin de disminuir el
conocimiento que se tiene en el exterior acerca de nuestro sistema [13].

11. Ejecutar sólo los servicios imprescindibles

Algunas personas tienen la manía de instalar los sistemas con la mayor cantidad posible de opciones que puedan
entrar en el disco duro. Los administradores de sistemas seguros deben ir exactamente en sentido inverso: en un
sistema de alto riesgo es de rigor que se ejecute únicamente lo imprescindible. El ejemplo más conocido corresponde
a los servicios de red, los cuales muchas veces vienen configurados para estar activos tan pronto como se instala un
sistema operativo, creándose automáticamente nuevas oportunidades para los atacantes.

El administrador debería asegurarse de que sólo esté instalado lo imprescindible para que el sistema siga en
operación. Debe descartar incluso el software aparentemente más inofensivo. Recuerdo haber leído de un caso en el
cual el sistema de manuales de Solaris tenía una vulnerabilidad explotable que permitía a cualquier usuario ejecutar
programas con mayores privilegios.

Sistemas que en apariencia no tienen nada de riesgosos han presentado serias amenazas para la seguridad, como por
ejemplo, las conexiones X Window, las librerías compartidas, los módulos del kernel, etc.

12. Mantenerse al día con las actualizaciones

Esta recomendación cada vez es más crítica [14]. El software, pese a los esfuerzos y la propaganda, continuará
teniendo errores y puertas ocultas. Y al parecer la tendencia sigue en aumento con la complejidad del mismo. Esto
implica que los vendedores deberán proporcionar parches o versiones mejoradas a sus clientes cada vez que se
descubra alguna vulnerabilidad.

Lamentablemente esto no se suele tomar muy en cuenta, tanto por las empresas de software como por los
administradores. Desde que se descubre una vulnerabilidad hasta que ésta puede ser aprovechada por un atacante
puede pasar mucho tiempo (incluso puede ser que nunca se logre aprovechar) lo que motiva a que las casas de
software tiendan a esperar más de la cuenta para admitir la vulnerabilidad a la vez que presentan el parche
correspondiente.

En sistemas operativos que involucran muchos componentes (como casi todos en la actualidad) es de esperarse que
las vulnerabilidades surjan con una frecuencia extremadamente alta. Desde el punto de vista de la casa de software,
esto significaría incomodar con demasiada frecuencia a los administradores (que se convertirían en eternos
"parchadores") por lo que usualmente se distribuyen parches a intervalos relativamente extensos y que corrigen de un
solo golpe todas vulnerabilidades halladas hasta la fecha, generalmente acompañadas de aditamentos al sistema de
modo tal que no luzca como un simple parche (piénsese en los "service pack".) Obviamente, los administradores que
se limitan a esperar el lanzamiento del próximo super-parche corren un gran riesgo en este lapso.

En un ambiente de alta seguridad esto no es aceptable: los parches de cada componente deben aplicarse tan pronto
como sea posible. Por tanto, si no deseamos que la administración se convierta en un parchar y parchar, deberíamos
asegurarnos que nuestro sistema realmente tenga pocos componentes (y por tanto, menos necesidad de parches.)
Como se indicó en la recomendación anterior, en todo sistema seguro, lo más indicado es evitar que se ejecuten
servicios innecesarios. He aquí un motivo más para seguir esta regla.

Otro corolario de esto es el establecimiento de una rigurosa política de actualización, para lo cual normalmente
existen diversos canales en Internet proporcionados por el vendedor. De igual modo, es menester mantenerse
informado acerca de las nuevas vulnerabilidades descubiertas, para lo cual existen diversas publicaciones
electrónicas especializadas [15],[16].

13. Escaneos regulares

Un "scanner" es un programa que intenta indagar acerca de qué servicios proporciona un computador de la red. Una
vez que se conocen estos servicios, un atacante puede centrar sus ataques hacia los mismos.

Esta herramienta es empleada regularmente por los hackers. Sin embargo, la podemos emplear en nuestro propio
beneficio, puesto que así nosotros podremos descubrir si hemos dejado ciertas puertas abiertas. El scanner sólo se
limita a proporcionar esta información y por tanto su uso es seguro e inofensivo.

El "escaneo" se debería hacer desde fuera de nuestra red (por ejemplo, desde un computador de Internet), así como
desde su interior contra nuestras estaciones de trabajo.

Fuente:

Recomendaciones de seguridad en sistemas distribuidos de cómputo
(V0.11)
Diego Bravo Estrada

Si quieres conocer otros artículos parecidos a Recomendaciones de seguridad en Sistemas Distribuidos 2 puedes visitar la categoría SEGURIDAD INFORMATICA.