PDF de programación - Políticas de Seguridad en entornos GNU

Políticas de Seguridad en
entornos libres.

Sancho Lerena
[email protected]

"Software Libre" es cuestión de libertad, no de precio. "Free" en
"free software" es una palabra que debe ser traducida como "libre"
tal como en "libertad de expresión" ("Free speech"); no como
"Gratis" como en "cerveza gratuita“ (“Free beer”).

www.gnu.org



Índice

 Parte 1. Introducción
 Parte 2. Políticas de Seguridad

 a) Analisis
 b) Diseño

 Parte 3. Implementación

 a) Arquitectura de redes seguras
 B) Seguridad Perimetral

 1) Firewall. Netfilter

Inspeccion de estados

•
• NAT
• Filtrado
• Cadenas
• Scripting
• Modulos
• HA con VRRP



Indice (continuación)

 B) Seguridad Perimetral (continuación)

 2) IDS. Snort
• Arquitectura
• Respuestas
•

Integracion de resultados

 3) Securización

 C) QoS. IPRoute2, tc y otros
 D) Auditoria. Nessus
 E) Gestion y monitorizacion

 MRTG
 NTOP
 Iptraf



 Parte III. Respuesta ante incidentes.
 Parte IV. Recursos de seguridad.



Avance

 Teoría organizativa

 Funcionamiento Algoritmos



Avance

 Arquitectura real de redes

 Descripciones técnicas



Avance

 Gestion y control



Avance
 Teoría

 ... y práctica

#!/bin/bash
# Checking conectivity with ICMP Ping, VRRPD Companion Script
VER="11/03/2002 - v1.0"
SLEEP_TIME=$2 # Tiempo de parada entre checks, en segundos
if [ -z $2 ]
then
SLEEP_TIME=5 # Si no se especifica, el check es cada 5 segundos
fi;
# Obtener el PID de los procesos de VRRPD en memoria
LISTA_PROCESOS=`ps -A | grep "vrrpd" | tr -s " " | cut -d " " -f 2`
if [ -z "$LISTA_PROCESOS" ]
then
echo " No VRRP Daemon running, aborting. "
exit
fi;
IP_DESTINO=$1 # IP de comprobacion, pasada como 1# parametro
COMANDO="`ping -c 1 "$IP_DESTINO" | grep '100% packet loss'`"
RES=0
while [ "$RES" -eq 0 ];do
if [ ! -z "$COMANDO" ] ;then
echo " Ping fail "
echo " Shutting down VRRP daemons "
kill -s 9 $LISTA_PROCESOS
RES=1;else
echo " Debug: Ping ok"
sleep $SLEEP_TIME
fi;done;



Parte I.
Introduccion a la seguridad



GNU y Seguridad

 ¿ Que es la Seguridad ?.

 Logica
 Fisica
 Redes

 Firewalls
 IDS
 Hosts

 Software Abierto vs Software Cerrado

 Soporte y otros “problemas”



GNU y Seguridad I

 Software Abierto vs Software Cerrado



GNU y Seguridad II

 GNU y Empresa

 Teoría vs Practica

 Falta de conocimientos
 Prisas y falta de profesionalidad
 GUI’s

 ¿ Es GNU Seguro ?

 Codigo Abierto
 Documentacion



Un poco de miedo I

 Un buen día....



Un poco de miedo II

 Algunos sucesos curiosos (13/3/02)



Un poco de miedo III
 www.securitybase.com



Un poco de miedo IV
 www.canon.es



Un poco de miedo V
 www.securecreditcard.net



Un poco de miedo VI

 www.exodus.it



Un poco de miedo VII

www.comntel.com



Un poco de miedo VIII

www.fox.dk



Un poco de miedo IX
www.kenwood.cd



Un poco de miedo X

 Algunas noticias sobre seguridad

(neworder.box.sk)

IT security pros learn to beat hackers at their own
game
@ SMS     Mar 14 2002 - 01:26 EST 

The_MadMan writes: Corporate security and IT professionals got a
chance last week to think like hackers so they could learn how to better
prevent unauthorized users from gaining access to their networks.

More than a dozen computer specialists from across the country took
part in an intensive five-day "boot camp" offered by New York-based
Ernst & Young LLP on the defense of enterprise networks. They paid

$5,000 apiece for the training here.



Read More 
read comments (0) | write comment



La seguridad no es...

!



 Ni un firewall “tonto” (Filtrado Simple)
 Ni tampoco un Firewall “listo” (Filtrado de

estados).



Parte II
Políticas de seguridad



Ingeniería de Seguridad I

 Ingeniería de seguridad. Modelos
 Análisis
 Diseño
 Implementacion
 Mantenimiento e incidencias.
 Referencias.



Ingeniería de Seguridad II
 Modelo Clásico Ing. del Software



Ingeniería de Seguridad III
 Modelo ISS



Ingeniería de Seguridad IV

 Modelo CERT



Análisis. Que es (I)

 Que es una Politica de Seguridad
“La seguridad obtenida sólo con medios técnicos es limitada”, 
“Sin técnica que la respalde, la seguridad es papel mojado”. 

 Sistemas informaticos.

 Organizaciones.



Análisis. ¿ Que es ? (II)

 Una Politica de Seguridad no es un

firewall.

 Fallos Tecnicos: Man in the middle, spoofing,

autenticación débil...

 Fallos no tecnicos: Señora de la limpieza,

fallos humanos, mal diseño, poco control en
la organización....

 Kevin Midnick



Análisis. ¿¡ QUE ES !? (III)
 ¿ Que es una política de seguridad ?

 Confusiones varias al respecto.

 Un conjunto de documentos, con un orden y una

sistematización.

 Describe paso a paso los distintos elementos de una

politica de seguridad.

 Detalla riesgos y peligros
 Como protegerse frente a esos riesgos, medidas a

tomar y detalles de esas medidas.

 Que medidas tomar frente a posibles incidencias
 Que hacer en el peor de los casos



Análisis. Que es (IV)

 Una Politica de Seguridad no se

vende ni se compra.

 No existen productos que hagan todo.
 La seguridad se vende con el miedo.
 El riesgo es real, las consecuencias diversas.
 Figura del Consultor / Tecnico de Seguridad.



Análisis. Necesidad

 Necesidad de una Política de

Seguridad en una organización.

 Confidencialidad.

 Integridad.

 Disponibilidad.



Análisis. Justificación

 Justificación

 Establece lo que se puede hacer y lo que no, de

forma escrita y formal. Se puede leer y es algo
escrito y aceptado.

 Demuestra que la empresa se lo quiere tomar en

serio. Implica un compromiso con los directivos.

 Util frente a una auditoria, sobre todo si se siguen

las normalizaciones.

 Util para demostrar casos de intrusiones o delitos

contra los sistemas informáticos.



Analisis. Normalización I

 Normalización y método.
ISO 17799, BS7799, RFC 2196

 Standard y certificación

 Rigurosidad y Método

 Hacking ”etico”



Análisis. Normalización II

 Normalización y método II

 Hacker vs Administrador

 Teoría de la “presa”



Análisis. Ámbitos

 Personas implicadas y

responsabilidades en el proyecto.

 Equipo de seguridad

 Dirección de la organización

 Personal técnico

 Personal no técnico



Análisis. Ambitos (II)



Análisis. Riesgos (I)

 Administrador vs Hacker. Teoria de

la presa.

 Identificar peligros. Checklist.

 Confidencialidad
 Integridad
 Disponibilidad

 Clasificación en niveles de
seguridad. Normalizaciones.



Análisis. Riesgos (II)

 ¿Que proteger?

 Acceso a Informacion comprometida o

confidencial

 Planes de negocio, nominas, contratos, listados passwords,

informacion de clientes.

 Acceso a Informacion valiosa

 Documentacion, desarrollos de I+D, historicos y archivos.

 Acceso a Inversiones e infraestructura

 Configuraciones, logs, backups, bbdd, webs, intranets,

Acceso a servidores, electrónica y hardware costoso.



Análisis. Riesgos (III)



Análisis. Riesgos (IV)

 Peligros contra la confidencialidad.

 Accesos no autorizados a información confidencial
 Accesos públicos a informacion confidencial, por

error, mala configuracion o descuido.

 Suplantación de usuarios.
 Acceso a servicios confidenciales (correo, bbdd,

servidores de acceso, etc).

 Instalación de caballos de troya.
 Acceso fisico a material restringido.



Análisis. Riesgos (V)

 Peligros contra la integridad

 Modificación indebida de datos (fallo de permisos)
 Falta de integridad (borrado o modificación) de

datos.

 Imposibilidad de idenficar fuente de datos.
 Fallo en la integridad de bases de dato

(corrupcion).

 Modificación en archivos de sistema

(configuraciones, logs, etc)

 Destrucción o corrupción de backups.
 Virus.
 Acceso fisico a material restringido.



Análisis. Riesgos (VI)

 Peligros contra la disponibilidad.

 Caida de servicios externos. (DoS)
 Agotamiento de recursos (ancho de banda, disco,

socket, etc). (DoS o mala config.)

 Fallo de infraestructuras generales de red (routing,

switches, etc). (DoS, fallo, mala configuración o
sabotaje)

 Destrucción de configuraciones o servicios. (DoS

o Sabotaje)

 Acceso fisico a infraestructura básica. Sabotaje.



Análisis. Riesgos (VII)

 DoS

etc. Perdidas.

 Tecnicas varias.

 Casos historicos: Yahoo, Amazon, eBay,

 Fallos especificacion protocolo.
 Programacion deficiente (buffer overflow).
 Flood.
 Acceso a los servicios: Fuerza bruta,

trojan, otros.

 Spoofing vario (IP, DNS, etc).
 Session hijacking.
 Ingenieria social y acceso fisico.
 DDoS y gusanos



Análisis. Riesgos (VII)

 Resumen de riesgos:

 Acceso a informacion sensible.
 DoS y fallos de programación.
 Mal uso de recursos.

 ¿ Era un firewall suficiente ?
 ¿ Existe algo suficiente por si

mismo para garantizar la seguridad
?



Diseño. Introducción

 Diseño.

 Como llevar esto a la práctica

 Uso de herramientas

 ISO 17799 y BS 7799
 RFC 2196
 Orange Book (DoD EEUU)
 CERT Security Guidelines
 Otras guías



Diseño. Vamos allá (I)

 Organizando subpoliticas
 Las mas importantes y comunes

 Uso de los recursos del sistema (*)
 Política de cuentas de usuario (*)
 Política de protección de la información (*)
 Política legal (*)
 Política de seguridad general de los sistemas

informáticos en producción (*)

 Política de backup (*)
 Política de control de accesos (*)
 Política de accesos y permisos (*)
 Política de seguridad física (*)



Diseño. Vamos allá (II)

 Otras subpolíticas.

 Política de Accesos remotos.
 Política de educación en el ámbito de la

seguridad.

 Política de prevencion y detección de virus.
 Plan de continuidad de nego