Metología de Contingencía en Servidores DNS, DHCP, WEB, Correo y FTP en Sistemas Operativos UNIX y LINUX

Inhaltsverzeichnis

Agradecimientos

Introducción

1.1 Datos estadísticos
1.1.1 Incidentes anuales
1.2 Objetivo
1.3. Alcances
1.4 Descripción por capítulos
1 El alcance del peritaje informático en servidores DNS, DHCP, WEB, Correo y FTP
1.1 Introducción
1.2 Resguardo de la información volátil y no volátil
1.3 Principales obstáculos para el peritaje informático

2 Metodologías de seguridad actual y propuesta
2.1 Introducción
2.2 ISO/IEC
2.2.1 ISMS
2.2.2 Valoración de riesgos
2.2.3 Controles
2.3 OCTAVE
2.4 NIST SP 800-
2.5 MAGERIT
2.6 Metodología propuesta
2.6.1 Fase monitoreo de los servicios DNS, DHCP, FTP, WEB y Correo
2.6.2 Fase resguardo del servicio DNS, DHCP, FTP, WEB y Correo
2.6.3 Fase restauración del servicio.Índice General

3 Condiciones necesarias para realizar la metodología de contingencia en servidores DNS, DHCP, WEB, Correo y FTP
3.1 Introducción
3.2 Identificación de acciones realizadas en el sistema operativo
3.3 Identificación del servidor comprometido

4 Metodología de contingencia en el servidor DNS
4.1 Introducción
4.2 Monitoreo del servicio DNS
4.2.1 Monitoreo del usuario con el que se ejecuta el servicio DNS
4.2.2 Monitoreo sobre los permisos de transferencias de zonas en el servidor DNS
4.2.3 Monitoreo sobre la versión del demonio named
4.3 Resguardo del servicio DNS
4.4 Restauración del servicio DNS
4.4.1 Asegurar el demonio named
4.4.2 Delimitar la transferencia de zonas
4.4.3 No informar acerca de la versión del demonio named
4.4.4 Creación de un entorno chroot en el servidor DNS

5 Metodología de contingencia en el servidor DHCP
5.1 Introducción
5.2 Monitoreo del servidor DHCP
5.2.1 Monitoreo del usuario con el que se ejecuta el servicio DHCP
5.2.2 Monitoreo de Interfaces por las que sirve el servicio DHCP
5.3 Resguardo del servidor DHCP
5.4 Restauración del servicio DHCP
5.4.1 Usuario con el que se ejecuta el servicio DHCP sin acceso al shell
5.4.2 Restaurar las Interfaces que tienen permiso de servir como DHCP
5.4.3 Creando un entorno chroot en el servicio DHCP

6 Metodología de contingencia en el servidor FTP
6.1 Introducción
6.2 Monitoreo del servicio FTP.Índice General
6.2.1 Monitoreo de ambientación chroot en el servidor FTP
6.2.2 Monitoreo de los permisos de escritura en el servidor FTP
6.2.3 Monitoreo del usuario con el que se ejecuta el servicio FTP
6.2.4 Monitoreo sobre la versión del demonio FTP
6.2.5 Monitoreo de la existencia activa del usuario anónimo
6.2.6 Monitoreo de la existencia activa de usuarios virtuales en el servidor FTP
6.2.7 Monitoreo de la existencia de configuración SSL en el servidor FTP
6.3 Resguardo del servidor FTP
6.4 Restauración del servidor FTP
6.4.1 Creación de un ambiente chroot
6.4.2. Restauración de los permisos de escritura en el servidor FTP
6.4.3. Restauración del usuario con el que se ejecuta el servicio FTP
6.4.4. Restauración visibilidad versión del servicio FTP al exterior
6.4.5. Usuarios anónimos sin acceso al servicio FTP
6.4.6. Creación de usuarios virtuales para el servicio FTP
6.4.7. Integrando al servicio FTP al protocolo de capa de conexión segura

7 Metodología de contingencia en el servidor WEB
7.1 Introducción
7.2 Monitoreo del servidor web
7.2.1 Monitoreo del usuario con el que se ejecuta el servicio WEB
7.2.2 Monitoreo sobre la versión del servicio WEB
7.2.3 Monitoreo del usuario y grupo con el que se administra el servicio WEB
7.2.4 Monitoreo de los permisos en el archivo de configuración del servidor WEB
7.2.5 Monitoreo del valor de timeout en el servidor WEB
7.2.6 Monitoreo del valor del LimitRequestBody en el servidor WEB
7.3 Resguardo del servicio WEB
7.4 Restauración del servicio WEB.Índice General
7.4.1 Restauración del usuario con el que se ejecuta el servicio WEB
7.4.2 No informar acerca de la versión del servicio WEB
7.4.3 Restauración del usuario y grupo con el que se administra elservicio WEB
7.4.4 Restauración de los permisos en el archivo de configuración del servidor WEB
7.4.5 Restauración del valor de timeout en el servidor WEB
7.4.6 Restauración del valor de LimitRequestBody en el servidor WEB
7.4.7 Crear un entorno chroot en servidor Web

8. Metodología de contingencia en el servidor correo
8.1 Introducción
8.1.1 Clasificación de los programas de correo
8.2 Monitoreo del servidor de correo
8.2.1 Monitoreo del usuario con el que se ejecuta el servicio de correo
8.2.2 Monitoreo del archivo /etc/mail/access en el servidor de correo
8.3 Resguardo del servidor de Correos archivos volátiles y no volátiles
8.3.1 Resguardo de estadísticas del servidor de correo
8.3.2 Resguardo de correos enviados a usuarios importantes del servicio de correo
8.4 Restauración del servicio de correo
8.4.1 Restauración del usuario que corre el demonio sendmail
8.4.2 Restauración del archivo /etc/mail/access en el servidor de correo

Conclusión

Anexos

Glosario

Bibliografía

Índice Scripts

3.2.1 Script necesario antes de realizar cualquier metodología

3.3.1 Script recolecta la información global del servidor

3.3.2 Script necesario antes de realizar cualquier metodología completo

4.2.1 Script monitoreo del usuario con el que se ejecuta el servicio DNS

4.2.2 Script monitoreo sobre los permisos de transferencias de zonas en el servidor DNS

4.2.3 Script monitorear que se mantenga como no visible la versión del servidor DNS

4.3 Script resguardo de archivos volátiles y no volátiles del servidor DNS

4.4.1 Script asegurar el demonio named

4.4.2 Script delimitar la transferencia de zonas

4.4.3 Script no informar acerca de la versión del demonio named

4.4.4 Script creación de un entorno chroot en nuestro servidor DNS

4.4.5 Script restauración del servicio completo

5.2.1 Script monitoreo del usuario con el que se ejecuta el servicio DHCP

5.2.2 Script monitoreo de Interfaces por las que sirve el servicio DHCP

5.3 Script resguardo de archivos volátiles y no volátiles del servicio DHCP

5.4.1 Script usuario con el que se ejecuta el servicio DHCP sin acceso al shell

5.4.2 Script agregar interfaces a usar para el demonio dhcpd

5.4.3 Script creación de entorno chroot en el servicio DHCP

5.5.1 Script restauración del servicio completo

6.2.1 Script monitoreo de ambientación chroot en el servidor FTP

6.2.2 Script monitoreo de permisos de escritura en servidor FTP

6.2.3 Script monitoreo del usuario con el que se ejecuta el servicio FTP

6.2.4 Script monitoreo sobre la versión del demonio FTP

6.2.5 Script monitoreo de la existencia activa del usuario anónimo

6.2.6 Script monitoreo de la existencia activa de usuarios virtuales en el servidor FTP

6.2.7 Script monitoreo de la existencia de configuración SSL en el servidor FTP

6.3. Script resguardo de archivos volátiles y no volátiles del servidor FTP

6.4.1 Script creación de un entorno chroot en el servidor FTP

6.4.2 Script restauración de los permisos de escritura en el servidor FTP

6.4.3 Script restauración del usuario con el que se ejecuta el servicio FTP

6.4.4 Script dejar invisible la versión del servicio FTP al exterior

6.4.5 Script usuarios anónimos sin acceso al servicio FTP

6.4.6 Script creación de usuarios virtuales para el servicio FTP

6.4.7 Script integrando al servicio FTP al protocolo de capa de conexión segura

7.2.1 Script monitoreo del usuario con el que se ejecuta el servicio WEB

7.2.2 Script monitoreo sobre la versión del servicio WEB

7.2.3 Script monitoreo del usuario y grupo con el que se administra el servicio WEB

7.2.4 Script monitoreo de los permisos en el archivo de configuración del servidor WEB

7.2.5 Script monitoreo del valor de timeout en el servidor WEB

7.2.6 Script monitoreo del valor del LimitRequestBody en el servidor WEB

7.3 Script resguardo del servicio WEB

7.4.1 Script restauración del usuario con el que se ejecuta el servicio WEB

7.4.2 Script No informar acerca de la versión del servicio WEB

7.4.3 Script restauración del usuario y grupo con el que se administra el servicio WEB

7.4.4 Script restauración de los permisos en el archivo de configuración del servidor WEB

7.4.5 Script restauración del valor de timeout en el servidor WEB

7.4.6 Script restauración del valor de LimitRequestBody en el servidor WEB

8.2.1 Script monitoreo del usuario con el que se ejecuta el servicio de correo

8.2.2 Script monitoreo del archivo /etc/mail/access en el servidor de correo

8.3 Script resguardo del servidor de correos

8.3.1 Script resguardo de estadísticas del servidor de correo

8.3.2 Script resguardo de correos enviados a usuarios importantes de nuestro servicio

8.4.1 Script restauración del usuario que corre el demonio sendmail

8.4.2 Script restauración del archivo /etc/mail/access en el servidor de correo

Índice Figuras

1.1 Principales obstáculos para la seguridad (ISM 1999)

2.1 Metodología de contingencia en servidores Unix/Linux propuesta

3.1 El sistema de archivos en Unix/Linux

3.2 Salida del script condmetodologia.sh

3.3 Resultados del script condmetodologia.sh

3.4 Ejecución del script condmetodologia2.sh

3.5 Resultado del script condmetodologia2.sh

4.1 Búsqueda interactiva y recursiva del DNS

4.2 Jerarquía del DNS

4.3 Menú del menú de monitoreo del usuario named

4.4 Resultado de verificar si el usuario named tenía acceso a la shell

4.5 Menú de monitoreo de permisos de transferencia de zonas

4.6 Salida del menú monitoreo de permisos de transferencia de zonas

4.7 Menú del monitoreo de versión del DNS

4.8 Ejemplo del resultado del monitoreo de tener invisible la versión del DNS

4.9 Contenido del archivo /etc/resolv.conf

4.10 Contenido del archivo /etc/named.conf

4.11 Contenido del archivo /var/named/db.murillotrejo.com

4.12 Contenido del archivo /etc/hosts

4.13 Contenido del archivo /etc/host.conf

4.14 Ejecución del script metodología.sh

4.15 Resultado del script metodología.sh

4.16 Contenido del archivo /etc/passwd

4.17 Cambio de contraseña al named

4.18 Contenido del archivo /etc/passwd

4.19 Ejecución del script metodologia2.sh

4.20 Salida del Script metodologia2.sh

4.21 Salida del script metodologia2.sh cuando es seguro el demonio

4.22 Salida del script metodologia2.sh cuando no es seguro el demonio

4.23 Salida del script metodologia2.sh cuando se opta por la opción 1

4.24 Salida del script metodología2.sh cuando salimos

4.25 Ejecución del script trans.sh

4.26 Resultado del script trans.sh mostrando los archivos que recolecto

4.27 Resultado del script trans.sh muestra la salida de trazona.txt archivo que recolecto

4.28 Ejecución y salida del script version.sh

4.29 Resultado del script version.sh muestra los archivos que recolectó

4.30 Salida del script version.sh que informa sobre la vulnerabilidad

5.1 Interfaces encontradas

5.2 Contenido del archivo /etc/dhcpd.leases

5.3 Contenido del archivo dhcpd.leases

5.4 Contenido del archivo dhcpd.conf

5.5 Ejecución del script MRdhcp.sh

5.6 Se comprueba que los archivos se resguardaron

5.7 Salida del script Mdhcp1

5.8 El archivo /etc/password

5.9 Seleccionando la opción 1 del menú

5.10 Archivo /etc/password

5.11 Enjaular servidor dhcpd

6.1 Salida del script 6.2.1 cuando existe ambientación chroot

6.2 Salida del script 6.2.2 cuando existe permisos de escritura en el servidor FTP

6.3 Salida del script 6.2.3 cuando el usuario ftp no tiene asignada ninguna Shell

6.4 Menú del script 6.2

6.5 Menú del script 6.2.5 ejemplo de vulnerabilidad

6.6 Contenido del archivo /etc/vsftpd.user_list

6.7 Contenido del archivo vsftpd.ftpusers

6.8 Contenido del archivo /etc/pam.d/vsftpd

6.9 Ejecución del script 6.3

6.10 Ejemplo ejecución del script con la opción uno

6.11 Ejemplo ejecución del script con la opción dos

6.12 Salida del script Mvsftpd1

6.13 El archivo /etc/password

6.14 Seleccionando la opción uno del Menú

6.15 Archivo /etc/password

6.16 Ejecución del script prue2ftp

6.17 Ejecución del Script prue1ftp

6.18 Comportamiento del protocolo SSL en FTP

7.1 Ejecución del script 7.2.1

7.2 Ejecución del script 7.2.2

7.3 Ejemplo de la ejecución del script 7.2.3

7.4 Ejemplo de la ejecución del script 7.2.4

7.5 Ejemplo de la ejecución del script 7.2.5

7.6 Ejemplo de lo existente en el archivo/var/log/httpd/error_log

7.7 Ejemplo de lo existente en /etc/httpd/conf/httpd.conf

7.8 Ejemplo de lo existente en /var/www

7.9 Salida del script 7.4.1

7.10 El archivo /etc/password

7.11 Seleccionando la opción 1 del Menú

7.12 Archivo /etc/password

7.13 Ejecución del Script WebVersion.sh

7.14 Ejemplo de ejecución del script 7.4.5

7.15 Resultado después de escoger la opción 0

7.16 Ejemplo de la ejecución del script 7.4.6

7.17 Ejemplo de la ejecución del script 7.4.6 opción cero

8.1 Envió de correos electrónicos

8.2 Ejemplo de ejecución del script 8.2

8.3 Ejemplo de ejecución del script 8.2.2 seleccionando en el menú opción uno

8.4 Ejemplo de lo existente en /var/spool/mqueue

8.5 Cabecera de un correo en cola

8.6 Ejemplo de lo existente en /var/log/maillog

8.7 Ejemplo de lo existente en /etc/mail/sendmail.cf

8.8 Parte de la salida del archivo /etc/mail/access

8.9 Parte de la salida del archivo /etc/mail/relay-domains

8.10 Parte de la salida del archivo /etc/mail/local-host-names

8.11 Ejecución del script Rgdoemail.sh

8.12 Resultados del script Rgdoemail.sh

8.13 Verificación del archivo /etc/mail/access

8.14 Archivo resguardado por el script restaura4.sh

8.15 Ejecución del script buscacorreo.sh

8.16 Muestra la bitácora del usuario jose.murillo@softtek.com

8.17 Ejecución del script resgemail1.sh

8.18 Salida del Script resgemail1.sh

8.19 Salida del script resgemail1.sh cuando es seguro el demonio

8.20 Salida del script metodología mailcont.sh mostrando su menú después de que avisa que el demonio no es seguro

8.21 Salida del script metodología de contingencia de correo.sh cuando se opta por la opción 1

8.22 Salida del script metodología2.sh cuando salimos

Índice Tablas

1.1 Incidentes Anuales atendidos por la UNAM-CERT.

1.2 Incidentes trimestrales atendidos por la UNAM-CERT.

1.3 Reporte anual de los incidentes atendidos por la UNAM-CERT.

3.1. Comandos que identifican los procesos y acciones realizados por los usuarios del sistema

4.1 Archivos volátiles y no volátiles en la configuración de un DNS (Bind).

4.2 Estructura de la jaula chroot en demonio Bind.

5.1. Archivos volátiles y no volátiles en la configuración de un DHCP (dhcpd).

5.2 Estructura del DHCPD enjaulado.

6.1 Archivos volátiles y no volátiles en la configuración de un FTP (vsftp).

6.2 Contenido del archivo /etc/vsftpd/vsftpd.conf

7. .1 Archivos volátiles y no volátiles en la configuración de un servicio de WEB con demonio Apache

8.1 Archivos volátiles y no volátiles en la configuración de un servidor de correo condemonio Sendmail

8.2. Opciones de mailstats.

Agradecimientos

A mis padres y hermanos Natalia y Carlos que me han apoyado y alentado en todo lo que emprendido.

A mi novia Grisdely por todo su amor y apoyo para alcanzar esta meta.

A mi coordinador MC. Felipe por todo su apoyo y consejos para mejorar este trabajo.

A mis Profesores del Instituto Tecnológico de Morelia que me motivaron con sus enseñanzas para realizar este trabajo.

A Softtek por permitirme ejecutar esta metodología para mejorar los procesos y seguridad.

Al Ing. Gilberto Zavala Pérez por todo su apoyo y comentarios que complementaron este trabajo.

Muchas Gracias

José Emmanuel Murillo Trejo

Introducción

El uso de servidores Unix y Linux es muy popular ya que estas plataformas se consideran las más estables. Cuando se trata de servidores de gama media y alta, los principales usuarios corporativos han confiado tradicionalmente en Unix y Linux; sin embargo en estas plataformas predecir los ataques hacia servidores es casi imposible (es muy complicado garantizar la seguridad ó la inviolabilidad absoluta de un servidor), por lo que todo administrador de sistemas debe estar preparado. Estos ataques se realizan en días no hábiles, en horas de poco acceso o utilización por parte de técnicos o administradores de sistemas.⁵.

La utilización de métodos cada vez más sofisticados para el ataque hace necesario tener un plan de contingencia ante cualquier ataque, una mala utilización ó configuración por parte de los encargados de los servidores. Una metodología como ésta permite recuperar a la brevedad el servicio y en su momento de crisis poder mantener los datos fiables y las pruebas intactas, esta metodología puede eliminar errores debido a la crisis por querer recobrar lo más rápido posible el servidor.

Esta metodología deja intacto los datos (volátiles y no volátiles) que puedan servir para reconstruir los eventos transcurridos antes, después y a posteriori del compromiso a los servidores para realizarle un análisis forense informático después del accidente.

La seguridad en servidores es un proceso que se puede ver comprometido en cualquier momento de la forma menos esperada, si la prevención no funcionó, una buena metodología de contingencia deberá disminuir los costos de este accidente.

1.1 Datos estadísticos

Las eventualidades en sistemas informáticos cada día están en aumento, se muestran las estadísticas y los tipos de incidentes atendidos por la UNAM-CERT al 2010.⁹

1.1.1 Incidentes anuales

La tabla 1.1 muestra la cantidad de incidentes por año atendidos por la UNAM-CERT en la que se atendieron los siguientes:

Abbildung in dieser Leseprobe nicht enthalten

Tabla 1.1 Incidentes Anuales atendidos por la UNAM-CERT.

La tabla 1.2 muestra los incidentes trimestrales en el 2010 atendidos por la UNAM- CERT.

Tabla 1.2 Incidentes trimestrales atendidos por la UNAM-CERT.

Abbildung in dieser Leseprobe nicht enthalten

La tabla 1.3 muestra un reporte anual de los incidentes atendidos por la UNAM- CERT.

Tabla 1.3 Reporte anual de los incidentes atendidos por la UNAM-CERT.

Como se puede observar en el año 2010 los ataques que se presentan con mayor residencia ha sido el Bot, así como la negación de servicio. La utilización de métodos cada vez más técnicos y complejos que buscan comprometer los servicios hace necesario tener un plan de contingencia.

1.2 Objetivo

Este trabajo cubre el vacío en metodologías prácticas usando scripts para recuperar servidores DNS, DHCP, WEB, FTP y de correo en sistemas operativos Unix, Linux después de una eventualidad interna o externa (ataque externo, mala administración o configuración).

Una metodología que responderá el cómo se produjo el compromiso en el servidor, bajo qué circunstancias, la identidad de posibles atacadores, su procedencia y origen, fechas de compromiso, objetivo de los atacadores, así como la reconstrucción cronológicamente los eventos.

Los beneficios son muchos ya que esta metodología está enfocada a proteger los datos volátiles y no volátiles que servirían para buscar a los responsables, mantener la seguridad en todo momento, y dejar funcionando los servidores a la brevedad con un nivel de seguridad fiable después de la eventualidad.

1.3 Alcances

El producto final es una metodología clara de contingencia que recuperará el funcionamiento correcto de los servidores DNS, DHCP, WEB, FTP y de correo en un mínimo tiempo conservando en todo momento seguro los datos que servirían para fincar responsabilidades.

Se presentará la configuración contingencial para cada uno de los servicios DNS, DHCP, WEB, FTP y de correo.

Es parte de la metodología mostrar la manera correcta de presentar los informes de contingencia para cada servicio (DNS, DHCP, WEB, FTP y de correo).

1.4 Descripción por capítulos

Capítulo 1. Se da una introducción sobre la importancia de contar con una metodología de contingencia para los servidores DNS, DHCP, WEB, FTP y de correo. Además se plantea el objetivo del trabajo y sus alcances.

Capítulo 2. Muestra una amplia visión sobre el estado del arte de una auditoría forense informática dando a conocer el alcance del peritaje informático en servidores DNS, DHCP, WEB, Correo y FTP.

Capítulo 3. Consiste en dar a conocer las condiciones necesarias para realizar la metodología de contingencia en servidores DNS, DHCP, WEB, Correo y FTP, se presentaran las herramientas necesarias tanto de software, hardware y otras utilidades que serán una constante de uso en cada una de las metodologías de contingencia.

Capítulo 4. Se muestra la metodología de contingencia en el servidor DNS en los sistemas operativos Unix, Linux (usando el servicio Bind) se presentarán los scripts correspondientes.

Capítulo 5. Se hablará de la metodología de contingencia en el servidor DHCP usando el demonio dhcpd en Unix y Linux se presentarán los scripts de resguardo y restauración.

Capítulo 6. Se muestra la metodología de contingencia en el servidor WEB en los sistemas operativos Unix y Linux usando el servicio Apache y como demonio a httpd.

Capítulo 7. Se muestra la metodología de contingencia en el servidor FTP usando el demonio vftpd que es uno de los mas seguros y mas usados en sistemas operativos Unix y Linux. .

Capítulo 8. Se hablará de la metodología de contingencia en el servidor de Correo usando como servicio a sendmail considerado como un servicio muy robusto y seguro.

1.1 Introducción.

Cada una de las eventualidades en servidores comprometidos es única y es el resultado de infinidad de variables. Por lo que es absurdo querer tratar todos los problemas relacionados a los servidores DNS, DHCP, WEB, correo, FTP y buscarle una solución a cada uno de los problemas conocidos.

La distribución de archivos de sistema en Linux y Unix es muy clara y concisa lo que ha llevado al éxito de estas plataformas, por lo que también juegan un papel crucial en el peritaje informático y por ende en esta metodología de contingencia en servidores.

El objetivo principal de un investigador forense es identificar todos los sistemas controlados por el intruso, comprender los métodos utilizados para acceder a estos sistemas, los objetivos del intruso y la actividad que ha desempeñado durante su estancia dentro del sistema comprometido⁵.

El tiempo que lleva en recolectar información un perito informático en los archivos del sistema es la clave del éxito, pero muchas veces al perito informático sólo le entregan la información y con esas evidencias tendrá que realizar la auditoría por lo que sus alcances ya dependerán del trabajo de quien le entregó las pruebas.

Es crítica la recolección de información, la escena del crimen es el servidor comprometido y cualquier equivocación ó descuido pueden causar la pérdida de información vital que podría dar pistas de algún hecho importante sobre "la víctima", el "criminal", el "objetivo" o el "móvil".

Los intrusos permanentemente mejoran sus técnicas, sean de acceso, ocultación de pruebas o de eliminación de huellas, siendo difícil, ó en algunos casos imposibles de reconstruir al 100% los eventos ocurridos.

Los forenses informáticos desde hace varios años tienen dificultades adaptándose a las nuevas técnicas ya que no sólo son necesarios los conocimientos de la materia sino experiencia en campos que tienen bastante poco que ver con la ciencia forense como los son la ingeniería inversa, criptografía, programación en lenguajes de bajo nivel, por lo que la metodología tratará de dotarlos con pruebas suficientes y lo más puras posibles para que realicen su trabajo de forma exitosa.

1.2 Resguardo de la información volátil y no volátil.

Uno de los objetivos más importantes de esta metodología es el resguardo de la información volátil y no volátil, ambas son muy importantes y su recolección debe hacerse lo antes posible, retardar la captura de la información volátil y no volátil podría propiciar la pérdida de evidencia valiosa en el análisis de la intrusión y por ende, en la restauración de los servicios, si se realiza de manera adecuada el perito informático tendrá que saber cómo se produjo el compromiso en el servidor, bajo que circunstancias, la identidad de posibles atacadores, su procedencia y origen, fechas de compromiso, objetivo de los atacadores, así como reconstruir cronológicamente los eventos.

La información volátil es aquella información activa que refleja temporalmente el estado actual del sistema⁸, la información no volátil es la que no es activa y no cambia con el estado del sistema.

El perito informático en todo momento deberá tener integra la información que el recogió ó le entregaron como parte de la metodología, es responsabilidad del forense informático mantener integra la información que arrojó la metodología de contingencia en cada uno de los servidores.

No serviría de nada el que se haya realizado un buen procedimiento al ejecutar la metodología cuando los resultados a manos de los peritos informáticos no están seguros. Si la metodología no se realiza a tiempo traería consigo fatales consecuencias para los peritos informáticos como los siguientes:

1. Se elimina el poder para fincar responsabilidades ya que se modificaron los archivos volátiles dando por resultado la eliminación de la escena del crimen.
2. El daño se eleva conforme va pasando el tiempo y no es ejecutada la metodología de contingencia para los servidores.
3. El tiempo de restauración seria más lento.

1.3 Principales obstáculos para el peritaje informático.

La metodología que se presentará en este trabajo no es de uso exclusivo de un perito informático su uso es tan general que está realizada para que la ejecute el Encargado de redes, el Administrador de sistemas, el Administrador de redes ó cualquier persona que su objetivo sea el correcto funcionamiento de los servidores sin necesidad de mucho presupuesto económico ya que para poner en marcha las metodologías de contingencia no es requerida ninguna inversión.

De acuerdo a un sondeo realizado por la Information Security Magazine (ISM 1999), que se muestra en la figura 1.1, se encuentra que el principal obstáculo para implementar la seguridad en las organizaciones es el económico.

Figura 1.1 Principales obstáculos para la seguridad (ISM 1999).

Abbildung in dieser Leseprobe nicht enthalten

Siendo las restricciones presupuestales el principal obstáculo para la implementación de la seguridad, se han realizado sondeos para estimar cual es la inversión que se dedica a este rubro. En Estados Unidos alrededor del 6% del presupuesto en TI se asigna a seguridad informática.

En México (Macías, Saucedo) realizó un sondeo denominado Encuesta Nacional sobre la Seguridad Informática en México 2007²⁴. Se encontró que únicamente el 65% de las empresas considera a la información como un activo. Las empresas entre 1 y 50 empleados invierten menos de $50,000 USD al año, en cambio, las empresas con más de 1000 empleados invierten alrededor de $130,000USD al año.

Si el problema para dotar seguridad es el presupuestal, las metodologías de contingencia en software libre disminuirán los costos significativamente.

Capítulo 2

Metodologías de seguridad actual y propuesta.

2.1 Introducción

El presente capítulo muestra las metodologías de seguridades actuales y más usadas en el mundo de la informática. Se mostrará los pasos y procesos para implementarlas, dejando en evidencia lo complicado y costoso de llevarlas a cabo, enfocándose más en lo administrativo que en lo técnico, muchas de ellas necesitan capacitación para llevarlas a cabo por lo que muchas empresas optan por contratar servicios externos para implementar su metodología.

Por todo lo anterior se propone una metodología fiable de llevar a cabo con aspectos técnicos bien fundamentados así como realistas sin tener que invertir grandes recursos económicos o de personal ya que el enfoque es más que practico.

2.2 ISO/IEC27001

La norma ISO/IEC27001 forma parte de un conjunto de estándares desarrollados por la ISO (International Organization for Standardization - La Organización Internacional para la Estandarización) e IEC (International Electrotechnical Commission - La Comisión Electrotécnica Internacional), que proporcionan un marco de gestión de la seguridad de la información utilizable por cualquier tipo de organización, pública o privada, grande o pequeña²⁵.

Esta norma está orientada principalmente a los aspectos organizativos de la seguridad, más que a los despliegues tecnológicos o de infraestructura, esto es a organizar la seguridad de la información. Se conforma de 3

Fases: ISMS, Valoración de riesgos y Controles.

2.2.1 ISMS

Es la Gestión de la Seguridad de los Sistemas de Información (Information Security Management System). Adopta el modelo PDCA (Plan-Do-Check-Act - Plan-- Comprobar-Actúe) en toda la estructura de procesos del ISMS:

Plan (Establecer): Establecer la política ISMS, sus objetivos, procesos, procedimientos relevantes para la administración de riesgos y mejoras para la seguridad de la información.

Do (Implementar y operar): Representa la forma en que se debe operar e implementarla política, controles, procesos y procedimientos.

Check (Monitorizar y revisar): Analizar y medir donde sea posible, los procesos ejecutados con relación a la política ISMS, evaluar objetivos.

Act (Mantener y mejorar): Realizar las acciones preventivas y correctivas, basadas en las auditorías internas y revisiones del ISMS o alguna otra información relevante que permita la mejora continúa del ISMS.

2.2.2 Valoración de riesgos

La valoración y análisis de riesgo está abierta a la aplicación de cualquier metodología, siempre y cuando sea metódica y completa, es decir, que satisfaga todos los aspectos que se mencionan en ella. Como ejemplo de metodologías de análisis de riesgos se tiene a OCTAVE del CERT (EEUU), MAGERIT (España), NIST SP 800-30 (EEUU) y MEHARI (Francia).

2.2.3 Controles

La norma contempla un mínimo de 133 controles que se deberán aplicar, en caso de encontrarse nuevos controles durante la fase de análisis de riesgos también será necesario aplicarlos para completar el ciclo.

Estos controles están agrupados en los siguientes rubros:

-Política de seguridad.
-Organización de la información de seguridad. Administración de los recursos.
-Seguridad de los recursos humanos. Seguridad física y del entorno.
-Administración de las comunicaciones y operaciones. Control de accesos.
-Adquisición de los sistemas de información, desarrollo y mantenimiento. Administración de los incidentes de seguridad.
-Administración de la continuidad del negocio.
-Marco legal y buenas prácticas (legales, de estándares, técnicas y auditorías)

La implementación de las normas ISO 27000 suele traer, sin lugar a dudas, diversos beneficios a la organización, sin embargo, lograr una implementación exitosa puede tener ciertos riesgos o contratiempos, entre otros un consumo excesivo de tiempo para la implementación, costos agregados en la adquisición de los estándares y capacitación del personal, generar temor ante el cambio, falta de visión gerencial que resulta en la delegación de todas la responsabilidades al departamento técnico y otros.

2.3 OCTAVE

La metodología OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation- Operacionalmente amenaza crítica, Bienes y evaluación de la vulnerabilidad) (Alberts 2002) es una suite de herramientas, técnicas y métodos para la seguridad de la información basada en riesgo, evaluación estratégica y planificación, desarrollado por el Instituto de Ingeniería de Software de la Universidad Carnegie Mellon. Se compone de una fase de Preparación con 4 actividades: Obtener el respaldo de la alta gerencia, selección del equipo de análisis, establecer el alcance apropiado de la metodología OCTAVE y selección de los participantes. Las 3 fases de desarrollo son:

1. Construir perfiles de amenazas basado en activos

a) Activos críticos.
b) Requerimientos de seguridad para activos críticos.
c) Amenazas a activos críticos.
d) Prácticas de seguridad actuales
e) Vulnerabilidades de la organización actuales

2. Identificar vulnerabilidades de la infraestructura

a) Identifique componentes clave.
b) Vulnerabilidades de la tecnología actuales.

3. Desarrollar planes y estrategias de seguridad

a) Riesgos a activos críticos.
b) Medición del riesgo.
c) Estrategia de protección.
d) Planes de mitigación del riesgo.

La implementación de OCTAVE es muy similar a la implementación de proyectos de Tecnologías de Información (TI), ya que se requiere la participación de toda la organización y el trabajo directo de varios grupos: Dirigentes de alto rango, áreas operativas y gerentes de áreas operativas, técnicos de tecnologías de información y personal en general.

2.4 NIST SP 800-30

La metodología NIST SP 800-30 (Risk Management Guide for Information Technology Systems- Guía de Gestión de Riesgos de los Sistemas de Tecnología de Información) fue desarrollada por el Instituto Nacional de Estándares y Tecnología (NIST). Está enfocada al manejo de riesgos. Se compone de tres fases: 1) Valoración del riesgo, 2) Mitigación del riesgo y 3) Evaluación y valoración.

La valoración del riesgo es el primer paso en la metodología de gestión del riesgo. Se usa para determinar el alcance de una amenaza potencial y el riesgo asociado con un sistema de tecnología de información a través del ciclo de vida de desarrollo del sistema. Esta fase abarca nueve pasos principales:

1. Caracterización del sistema.
2. Identificación de amenaza.
3. Identificación de vulnerabilidades.
4. Análisis de control.
5. Determinación de la probabilidad.
6. Análisis de impacto.
7. Determinación del riesgo.
8. Recomendaciones de control.
9. Documentación de resultados.

La mitigación del riesgo implica priorizar, evaluar e implementar los controles de reducción de riesgo apropiados recomendados para el proceso de valoración de riesgos. Esta fase abarca seis pasos:

1. Opciones de mitigación del riesgo.
2. Estrategia de mitigación del riesgo.
3. Aproximación para la implementación de control.
4. Categorías de control.
5. Análisis costo beneficio.
6. Riesgo residual.

La etapa de evaluación y valoración se refiere al empleo de buenas prácticas como parte integrante del desarrollo del ciclo de vida de desarrollo del sistema y no como una regulación legal, lo cual contribuye a los objetivos o misión de la organización. Finalmente la clave del éxito de esta metodología recae en el compromiso de la alta gerencia, el total apoyo y participación del equipo de TI, la competencia del equipo de valoración de riesgos, la conciencia y cooperación de los miembros la comunidad de usuarios y la evaluación y valoración de los riesgos relacionados a las TI.

2.5 MAGERIT

MAGERIT es una Metodología de Análisis y Gestión de Riesgos en los Sistemas de Información desarrollada por el Ministerio de Administraciones Públicas del gobierno español, actualmente disponible la versión 2. Se compone de dos fases:

1. Análisis de riesgos.
2. Gestión de riesgos

El análisis de riesgos tiene cinco pasos que son:

1. Activos: Determinar los activos relevantes para la organización, su interrelación y su valor en el sentido de qué perjuicio (costo) supondrá su degradación.
2. Amenazas: Determinar a qué amenazas están expuestos aquellos activos.
3. Salvaguardas: Determinar qué salvaguardas hay dispuestas y cuán eficaces son frente al riesgo.
4. Determinación del impacto: Estimar el impacto, definido como el daño sobre el activo derivado de la materialización de la amenaza.
5. Determinación del riesgo: Estimar el riesgo definido como el impacto ponderado con la tasa de ocurrencia (o expectativa de materialización) de la amenaza.

La gestión del riesgo se da una vez que se ha realizado el análisis de riesgo y se determina que existe un riesgo probable a la organización. Se identifican tres actividades:

1. Toma de decisiones.
2. Elaboración del plan de seguridad de la información.
3. Ejecución del plan.

Esta metodología ha sido implementada por organismos españoles principalmente.

2.6 Metodología propuesta.

Después de haber hecho una revisión de las diversas metodologías sobre seguridad informática, se observa que uno de los principales obstáculos en la implementación de las mismas es la gran cantidad de pasos y procesos que hay que seguir, enfocadas al manejo administrativo de la seguridad más que al técnico, además de que algunas tienen costo, es necesario contar con una capacitación especializada para el manejo de las mismas e inclusive es muy recomendable contratar los servicios de empresas externas para llevar a cabo la implementación.

Con la finalidad de contar con un procedimiento que pueda ser utilizado para cumplir con los objetivos del presente trabajo, se propone una estrategia conformada por una metodología y su implementación, la cual permite una planeación bien fundamentada y un desarrollo noventa por ciento práctico llevado por los mismo Administradores de Sistemas, siendo factible de llevar a cabo.

Resulta difícil la comparación entre la metodología propuesta y las que proponen organismos internacionales debido a que los objetivos y alcances son distintos. Mientras que las normas y estándares tienen como finalidad uniformizar, normar criterios y certificar, la propuesta aquí planteada es solo un modelo que puede ser utilizado por organizaciones que deseen mejorar la seguridad en su ámbito de operación, sin tener que invertir grandes recursos económicos y de personal ya que el enfoque es muy práctico.

La siguiente figura 2.1 muestra las fases de la metodología propuesta.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.1 Metodología de contingencia en servidores Unix/Linux propuesta.

La figura 2.1 muestra la metodología de contingencia propuesta así como sus fases donde cada una de estas fases proporciona los elementos previos para que se continúe con la siguiente. Al final del ciclo se indica una predicción de ataques (control adaptivo) con lo que se convierte en un proceso iterativo. Estas tres fases son:

Monitoreo, Resguardo de información según el servicio, Restauración del servicio comprometido.

Se inicia la metodología con un monitoreo para asegurarnos de cual servicio es el comprometido, muchas veces se puede mal interpretar que un servicio está comprometido y estos falsos positivos pueden generar gastos en lo más importante de una contingencia que es el tiempo.

2.6.1 Fase monitoreo de los servicios DNS, DHCP, FTP, WEB y Correo.

La mayor parte del ciclo de vida se encuentra en esta fase, es la encargada de detectar compromisos a los servicios así como de predecirlos y retroalimentar a la fase de restauración del servicio.

En esta fase se estarán monitoreando los archivos de configuración de los servicios DNS, DHCP, FTP, WEB y correo en busca de vulnerabilidades ó modificaciones a los archivos de configuración, estas vulnerabilidades serán reportadas a los Administradores de Sistemas para que puedan proceder con la fase de resguardo y restauración de la metodología de contingencia.

La fase de monitoreo está retroalimentada por los Administradores del Sistema por un proceso llamado control adaptivo que su objetivo es actualizar con los últimos riesgos a la metodología, con esta iteración la metodología siempre estará vigente.

En la introducción mencionamos que cada una de las eventualidades en servidores comprometidos es única y es el resultado de infinidad de variables, por lo que es absurdo querer tratar todos los problemas relacionados a los servidores DNS, DHCP, WEB, correo, así como FTP y buscarle una solución a cada uno de los problemas conocidos, es por eso la importancia del proceso de control adaptivo que como toda metodología tecnológica necesita su retroalimentación para blindarse de una manera estructural de los muchos ataques presentes y futuros.

2.6.2 Fase resguardo del servicio DNS, DHCP, FTP, WEB y Correo.

En esta fase es donde se van a resguardar los datos volátiles y no volátiles que conforman al servicio degradado, entendiendo como datos no volátiles: Un archivo es no volátil cuando su información no es dinámica o no cambia según el estado actual del sistema⁷, es lo inverso de un archivo volátil.

Es de suma importancia seguir estrictamente el orden de resguardo ya que de esto depende tener la información que responderá el cómo se produjo el compromiso en el servidor, bajo qué circunstancias, la identidad de posibles atacadores, su procedencia y origen, fechas de compromiso, objetivo de los atacadores, así como la reconstrucción cronológicamente los eventos.

2.6.3 Fase restauración del servicio.

En esta fase es la más crítica ya que es la encargada de presentar los errores del servicio a nivel configuración así como de resolverlos hasta dejar nuevamente fiable, integro y en producción al servicio. En el ciclo de vida de la metodología la fase de Monitoreo y control adaptivo estarán retroalimentando esta fase de manera iterativa.

Capítulo 3 Condiciones necesarias para realizar la metodología de contingencia en servidores DNS, DHCP, WEB, Correo y FTP.

3.1 Introducción.

En este capítulo se citarán las condiciones necesarias que serán universales en toda la metodología de contingencia en servidores DNS, DHCP, WEB, correo y FTP así como las herramientas necesarias tanto de software, hardware, scripts y otras utilidades que serán una constante de uso para llevar a cabo exitosamente la metodología. En la recopilación de información se usarán las herramientas contenidas en los sistemas operativos ya que son muy poderosas y sumamente confiables, eliminando con éstos el uso de (utilerías) comprometidas, se valdrá de la propia terminal de estos sistemas operativos.

Una vez que se tiene una terminal confiable se deben copiar los scripts de cada metodología al sistema operativo en cuestión los scripts deben ser borrados en el sistema para evitar que sean comprometidos.

Es importante recordar que el objetivo de esta metodología va dirigido al personal que se encarga de Administrar el Sistema Operativo por lo que los scripts de la metodología se estarán ejecutando con su usuario administrador root en su respectivo home (/root/Desktop)

3.2 Identificación de acciones realizadas en el sistema operativo.

La estructura de los sistemas de archivos de Unix y Linux es un sistema jerárquico como se muestra en la figura 3.1, al punto de mayor jerarquía se le llama raíz y se le representa con una diagonal (/). Cuando arranca Unix y Linux monta la partición raíz, a partir de la cual se van montando otras particiones o sistemas.

Figura 3.1 El sistema de archivos en Unix/Linux.

Abbildung in dieser Leseprobe nicht enthalten

La siguiente tabla 3.1 muestra los comandos que se usan tanto en Unix y Linux y serán ejecutados antes de seguir cualquiera de las metodologías por el script 3.1. que se muestra a continuación.

Abbildung in dieser Leseprobe nicht enthalten

Tabla 3.1 Comandos que identifican los procesos y acciones realizados por los usuarios del sistema.

Para el proceso de las metodologías de contingencia en cada uno de los servidores a tratar con sistemas operativos Unix y Linux existen archivos de configuración que comparten. Estos archivos universales serán los primeros a guardar.

Script 3.2.1 Necesario antes de realizar cualquier metodología.

El primer objetivo del script será el resguardo de la información volátil y no volátil que identifica al servidor y sus características como los parámetros de red su sistema de archivos así como también los procesos y acciones realizados por los usuarios antes de la eventualidad.

El siguiente script tiene el nombre de condmetodologia.sh con permisos de ejecución 700 y fue guardado en la siguiente ruta absoluta /root/Desktop/ y ahí es donde fue ejecutado y probado con éxito.

Abbildung in dieser Leseprobe nicht enthalten

Script 3.2.1 Necesario antes de realizar cualquier metodología.

La figura 3.2 muestra un ejemplo de la ejecución del script.

Figura 3.2 Salida del script condmetodologia.sh.

Abbildung in dieser Leseprobe nicht enthalten

Revisamos el directorio para asegurarnos de que han sido debidamente copiados los archivos que se resguardaron en el script 3.2.1 como se muestra en la figura 3.3, con los cuales se identificarán los procesos y acciones realizadas por los usuarios del sistema los cuales son los siguientes:

Respaldar la salida de last, who, ps aux, top -n 1, nmap localhost, find / -perm -6000 ls, reguardar el archivo /var/log/wtmp así como /var/log/utmp.

Abbildung in dieser Leseprobe nicht enthalten

Figura 3.3 Resultados del script condmetodologia.sh.

3.3 Identificación del servidor comprometido.

Será necesario también recolectar información que identifica al servidor comprometido ya que podría ser que su identidad hubiese sido cambiada así como la organización de sistema de ficheros.

Los siguientes archivos y directorios serán los siguientes a resguardar /etc/fstab este archivo indica que dispositivos tiene que montar, a donde y cuáles son las opciones. El archivo /etc/hosts mantiene una relación de las direcciones IP y los nombres de las maquinas, es una pequeña base de datos que ayuda a recordar a las computadoras con las que se podría tener mayor comunicación.

El siguiente archivo será /var/log/dmesg que contiene todo los dispositivos físicos que reconoció al iniciar, los logs de sistema que se encuentra en /var/log/messages, /etc/hosts.allow es donde se configuran las direcciones IP ó dominios que tendrán acceso a los servicios ofrecidos por el servidor, el archivo /etc/hosts.deny es el complemento de archivo /etc/hosts.allow y sirve para negar el acceso a los servicios ofrecidos por el servidor, /etc/sysconfig/network. Contienen el nombre de la computadora, la dirección IP (estática ó dinámica), el dominio, el ruteador por default.

Script 3.3.1 Recolecta la información global del servidor.

Abbildung in dieser Leseprobe nicht enthalten

Script 3.3.1 Recolecta la información global del servidor.

El script 3.3.1 tiene el nombre de condmetodologia2.sh con permisos de ejecución 700 y fue guardado en la siguiente ruta absoluta /root/Desktop/ y ahí es donde fue ejecutado y probado con éxito.

La figura 3.4 muestra la ejecución del script 3.3.1.

Figura 3.4 Ejecución del script condmetodologia2.sh.

Abbildung in dieser Leseprobe nicht enthalten

A continuación revisamos el directorio para confirmar el resguardo de la información que identifica al servidor como se muestra en la figura 3.5.

Figura 3.5 Resultado del script condmetodologia2.sh.

Abbildung in dieser Leseprobe nicht enthalten

Con el script 3.2.1 obtenemos la identificación de los procesos y acciones realizadas por los usuarios en el servidor y con el script 3.3.1 se identifica al servidor.

Al finalizar estos dos scripts podemos seguir con cualquiera de las metodologías de contingencia DNS, DHCP, WEB, correo, y FTP.

Script 3.3.2 Necesario antes de realizar cualquier metodología completo.

Este Script 3.3.2 reúne la metodología completa y firma el directorio con los archivos recolectados con md5sum para darle seguridad e integridad a la información recolectada.

Abbildung in dieser Leseprobe nicht enthalten

Script 3.3.2. Necesario antes de realizar cualquier metodología completo.

El script 3.3.2 permitirá resguardar y mantener seguro los datos que se hayan recolectado y que se estarán recolectando a lo largo de la metodología y deberemos estar preparado con todas las utilidades necesarias para nunca caer en la incapacidad de no poder guardar estos datos.

Capítulo 4 Metodología de contingencia en el servidor DNS

4.1 Introducción.

El servidor de nombres de Internet DNS (Domain Name Server-Sistema de nombres de dominio) sirve para convertir nombres de dominios en direcciones IP de Internet y viceversa.

El DNS funciona de la siguiente manera, cuando un cliente desea conectarse a un servidor de Internet, este realiza la petición a su DNS principal, si este conoce la dirección se la proporciona al cliente, en caso de que éste no la conozca, el servidor DNS pregunta al inmediatamente superior, si éste conoce la dirección se la proporciona al DNS y de ahí pasa al cliente, en caso contrario se hace una nueva solicitud al servidor inmediatamente superior, así hasta que se encuentre al servidor autorizado para proporcionar la dirección IP.

Las búsquedas recursivas generalmente las realizan los clientes, que espera como respuesta la dirección IP solicitada ó de que no se conoce la dirección. El servidor interrogado se encarga de realizar la búsqueda por los medios que estén a su alcance, preguntando a otros servidores hasta obtener la información o hasta que la búsqueda falla.

En la búsqueda interactiva en cambio se pregunta al servidor DNS por información que conoce (posiblemente almacenada en cache). En caso de que no sea así, como respuesta obtiene una referencia del nombre del servidor que debe tener la respuesta (un servidor autorizado en un nivel inferior del árbol). En la figura 4.1 se muestra el diagrama de la búsqueda interactiva y recursiva del sistema.

Abbildung in dieser Leseprobe nicht enthalten

Figura 4.1 Búsqueda interactiva y recursiva del DNS. Fuente: Security Issues with DNS (Carli 2003).

El dominio de nombres de Internet está organizado en forma jerárquica, el nivel más alto de la jerarquía es llamado dominio raíz (root domain), y es representado con un punto (.). El siguiente nivel de la jerarquía es llamado dominio del alto nivel (TLD top-level domain). Existe solamente un dominio raíz y muchos dominios de alto nivel, cada nivel TLD es un domino hijo del dominio raíz. Cada dominio TLD tiene dominios hijos también llamados dominios de nivel secundario o dominios de las organizaciones.

En la representación de los dominios, generalmente se omite el dominio raíz, así por ejemplo para el dominio VENTAS.MYDOMINIO.COM, el TLD se debería representar como COM., con un punto al final, el dominio de segundo nivel o de organización es MYDOMINIO y el dominio de tercer nivel es VENTAS, y así sucesivamente. A la concatenación de estos dominios se le conoce como FQDN (fully qualified domain name- Nombre de Dominio totalmente calificado).

Existen varios millones de dominios de organización de segundo nivel, en septiembre de 2004 había más de 60 millones de dominios registrados. La figura 4.2 muestra parcialmente la jerarquía del DNS.

Abbildung in dieser Leseprobe nicht enthalten

Figura 4.2 Jerarquía del DNS

Fuente: Adaptado de Security Issues with DNS (Carli 2003).

4.2 Monitoreo del servicio DNS.

En está fase se estarán monitoreando el servicio de DNS, en busca de vulnerabilidades, en los archivos de configuración del servicio. Está es la fase encargada de presentar los errores de configuración al Administrador de Sistemas, dándose a conocer una vulnerabilidad en el sistema se procederá con la fase de resguardo del servicio DNS para terminar con la restauración del servicio DNS.

Como se menciono anteriormente está fase estará retroalimentada por el proceso de control adaptivo con esto se pretende mantener actualizada la fase de monitoreo con los problemas actuales y predecir los futuros.

4.2.1 Monitoreo del usuario con el que se ejecuta el servicio DNS.

El usuario que ejecuta el servidor DNS es llamado named y es importante su monitoreo ya que puede tener vulnerabilidades tales cómo que tenga acceso a una shell ya que para sus tareas no es necesario.

Muchos atacantes que irrumpen el servidor DNS cambian las propiedades del usuario named permitiéndole acceso a alguna shell del sistema operativo, con la finalidad de ganar acceso en el futuro, es por ello la importancia de estar monitoreando la configuración del usuario con el que se ejecuta el servicio DNS.