Product SiteDocumentation Site

Capítulo 14. Seguridad

14.1. Definición de una política de seguridad
14.2. Firewall o el filtrado de paquetes
14.2.1. Comportamiento de netfilter
14.2.2. Sintaxis de iptables e ip6tables
14.2.3. Creación de reglas
14.2.4. Instalación de las reglas en cada arranque
14.3. Supervisión: prevención, detección, disuasión
14.3.1. Monitorización de los registros con logcheck
14.3.2. Monitorización de actividad
14.3.3. Detección de cambios
14.3.4. Detección de intrusiones (IDS/NIDS)
14.4. Introducción a AppArmor
14.4.1. Principios
14.4.2. Activar AppArmour y gestionar los perfiles
14.4.3. Creación de un nuevo perfil
14.5. Introducción a SELinux
14.5.1. Principios
14.5.2. Configuración de SELinux
14.5.3. Gestión de un sistema SELinux
14.5.4. Adaptación de las reglas
14.6. Otras consideraciones relacionadas con la seguridad
14.6.1. Riesgos inherentes de las aplicaciones web
14.6.2. Saber qué esperar
14.6.3. Selección prudente de software
14.6.4. Gestión de una máquina como un todo
14.6.5. Los usuarios también son parte
14.6.6. Seguridad física
14.6.7. Responsabilidad legal
14.7. Tratamiento de una máquina comprometida
14.7.1. Detección y visualización de la intrusión
14.7.2. Desconexión del servidor
14.7.3. Preservación de todo lo que pueda utilizar como evidencia
14.7.4. Reinstalación
14.7.5. Análisis forense
14.7.6. Reconstrucción del escenario de ataque
Un sistema de información puede tener un nivel variable de importancia dependiendo del entorno. En algunos casos es vital para la supervivencia de una empresa. Por lo tanto, debe ser protegido de los diversos tipos de riesgos. El proceso de evaluación de estos riesgos y la definición e implementación de la protección se conocen en su conjunto como «proceso de seguridad».

14.1. Definición de una política de seguridad

La palabra «seguridad» en sí misma cubre un amplio rango de conceptos, herramientas y procedimientos, ninguno de los cuales es universal. Seleccionar entre ellos requiere una idea precisa de sus metas. Asegurar un sistema comienza con responder unas pocas preguntas. Al precipitarse a implementar un conjunto arbitrario de herramientas corre el riesgo de enfocarse en los aspectos de seguridad equivocados.
Lo primero a determinar, por lo tanto, es el objetivo. Un buen método para ayudar con esta determinación comienza con las siguientes preguntas:
  • ¿Qué estamos tratando de proteger? La política de seguridad será diferente dependiendo de si queremos proteger los equipos o los datos. En este último caso, también es necesario saber qué datos.
  • ¿Contra qué estamos tratando de protegernos? ¿Fuga de datos confidenciales? ¿Pérdida accidental de datos? ¿Perdida de ingresos por interrupción del servicio?
  • También ¿contra quién estamos tratando de protegernos? Las medidas de seguridad serán diferentes para protegerse contra el error de un usuario regular del sistema de lo que serían contra un grupo de atacantes determinado.
Habitualmente, se utiliza el término «riesgo» para referirse al conjunto de estos tres factores: qué proteger, qué necesitamos prevenir antes que suceda y quién intentará hacer que suceda. Modelar el riesgo requiere respuestas a estas tres preguntas. A partir de este modelo de riesgo, podemos construir una normativa de seguridad e implementarla con acciones concretas.
Vale la pena el tomar en cuenta restricciones adicionales, dado que pueden limitar el alcance de las políticas disponibles. ¿Hasta dónde estamos dispuestos a llegar para asegurar un sistema? Esta pregunta tiene un gran impacto en la política a implementar. La respuesta es a menudo definida en términos de costos monetarios, pero debe considerar otros elementos, tal como la cantidad de inconvenientes impuestos a los usuarios del sistema o una degradación en el rendimiento.
Una vez que modelamos el riesgo, podemos comenzar a pensar en diseñar una política de seguridad real.
En la mayoría de los casos, el sistema de información puede ser segmentado en subconjuntos coherentes y en su mayoría independientes. Cada subsistema tendrá sus propios requisitos y limitaciones, por lo que se deberá llevar a cabo la evaluación de riesgos y el diseño de la política de seguridad por separado para cada uno. Un buen principio a tener en cuenta es que un perímetro corto y bien definido es más fácil de defender que una frontera larga y sinuosa. Se debe diseñar en consecuencia también la organización de la red: se deben concentrar los servicios sensibles en un pequeño número de máquinas y estas máquinas sólo deben ser accesibles a través de un número mínimo de puntos de control, asegurar estos puntos de control será más fácil que asegurar todas la máquinas sensibles contra la totalidad del mundo exterior. Es en este punto que se hace evidente la utilidad del filtrado de red (incluyendo los firewalls). Puede implementar este filtrado con hardware dedicado, pero posiblemente una solución más simple y flexible sea utilizar un firewall en software como el que se integra en el núcleo Linux.