tema 5. seguridad en redes y protocolos asociados · mensaje de longitud fija. • si el mensaje se...
TRANSCRIPT
1
Tema 5. Seguridad en Redes
y protocolos asociados
Ingeniería de protocolos
Curso 2012/13
Jaime Benjumea Mondéjar
Dpto. Tecnología Electrónica
(Univ. de Sevilla)
2
CRIPTOGRAFÍA
cifrado simétrico
La misma clave se utiliza para cifrar y para descifrar.
Son computacionalmente rápidos.
NO son capaces de soportar el no-repudio.
NO es posible intercambiar claves en entornos no seguros.
Es necesario una clave (distinta) por cada par en la comunicación.
Imagen: Web Security, Privacy &
Commerce, 2nd Edition
3
CRIPTOGRAFÍA
cifrado asimétrico La clave que sirve para cifrar un
texto, no es capaz de descifrarlo.
La clave pública la conocen todos,
la privada sólo yo.
La clave de cifrado (pública) no
tiene por qué transmitirse sobre un
canal seguro.
Da soporte a la firma digital (no
repudio).
Sólo se necesitan dos claves por
persona.
Pero: son computacionalmente muy caros en comparación con el sistema
simétrico a No son adecuados para transmisión en tiempo real.
Imagen: Web
Security, Privacy &
Commerce, 2nd
Edition
4
CRIPTOGRAFÍA
funciones hash • Hash: Función que “resume” un
texto de longitud indeterminada en un
mensaje de longitud fija.
• Si el mensaje se modifica, el hash
no coincide.
• Usado con sistemas de cifrado,
ofrece integridad (ambos) y no
repudio (asimétricos) de forma
automática.
• Las funciones hash deben garantizar:
1. Es caro obtener un texto con un hash previamente definido.
2. Debe ser suficientemente largo como para no tener un diccionario de
mensajes para cada hash.
3. Pequeños cambios en el texto agrandes cambios en el hash (la mitad
de los bits).
Imagen: Web Security, Privacy & Commerce, 2nd Edition
5
CRIPTOGRAFÍA
aspectos finales • Un buen sistema de cifrado debe:
– Ser resistente al criptoanálisis, sólo vale el ataque de fuerza
bruta.
– ¿Su algoritmo tiene que ser conocido?.
• La fortaleza global es la del punto más débil
• ¿Cómo se garantiza la “propiedad” de una clave pública?
– Sistema jerárquico y más bien centralizado (PKI).
– Sistema plano y no jerarquizado (PGP).
• ¿Cómo se generan los números “aleatorios”?
6
Protocolo SSH Conceptos y autenticación del servidor
• Ofrece un mecanismo de autentificación de servidor y cliente además de
cifrado.
MECANISMO DE OPERACIÓN (I)
(0) El cliente solicita una conexión.
1. Identificación del servidor con su clave pública
(no me fío de la IP). Atención a la primera
vez.
2. El cliente le pide una prueba.
3. El servidor responde correctamente.
(EL SERVIDOR YA ESTÁ AUTENTICADO)
• Se utiliza cifrado asimétrico al
comienzo, y simétrico una vez
negociados y autentificados el cliente y
el servidor.
• Además da soporte a la integridad de
los datos.
Cliente SSH
Servidor SSH
1
2
3
7
Protocolo SSH
Autentificación del cliente
Cliente SSH
Servidor SSH
4
5
6
Una vez autenticado el servidor, y sólo
entonces, el cliente se autentifica:
(4) El servidor, ya con una conexión segura
(negociada antes) pide al cliente
autenticarse.
(5) El cliente le responde, puede
autenticarse mediante: Kerberos, publickey
y contraseña (entre otros).
(6) Si el cliente responde de forma correcta,
la conexión se permite y ésta será cifrada y
con verificación de integridad.
Por lo tanto: SSH nos ofrece un servicio
de acceso seguro y con garantía de
integridad.
8
Man-in-the-middle attack
(Tipo de ataque general)
Flujo REAL de la información.
Flujo TEÓRICO de la información
Mediante este ataque es posible …
1. Leer el tráfico de red (sniffing).
2. Inserción y repetición
(replay/insertion attacks).
3. Interceptarlo y modificarlo (ataques
de modificación).
… y se consigue:
1. Leer contraseñas.
2. Ejecutar dos veces una
operación (p.ej. una transferencia
bancaria).
3. Hacernos pasar por uno de los
extremos sin que el otro se de
cuenta.
¿Puede SSH
solucionar
estos
problemas?
9
Protocolo SSH
Man-in-the-middle attack (II)
• Según veíamos antes, una vez autenticados ambos extremos, SSH ofrece:
– Cifrado: Me protege contra el punto (1).
– Integridad: Me protege contra el punto (3) (casi).
• ¿Y el punto (2)?a En cada mensaje se incluye un código que impide que éste mensaje si se repite, sea válido.
10
Protocolo SSH
Man-in-the-middle attack
(1)Petición de conexión (que es
interceptada).
(2)Atacante responde con la clave
pública del servidor SSH (que
conoce).
(3)Se envía la prueba (cifrado con la
clave pública)
(4)No sabe que responder.
2
3
1
?
Siempre que el cliente tenga previamente la clave pública del
servidor, no será posible que otros se hagan pasar por éste.
11
Protocolo SSH
¿de qué no me protege? La primera conexión: Es necesario conocer
previamente la clave pública del servidor
(problema de distribución).
1er Acceso
¡VERIFICAR!
• Certificados.
• Por teléfono.
• En persona.
Determinados ataques DoS: Los referidos a niveles inferiores:
• Físicamente: Corte de la comunicación.
• Nivel de transporte: Se puede resetear una conexión
falsificando segmentos TCP de forma adecuada.
12
Protocolo SSH
port forwarding (I)
Servidor POP Cliente de
correo
No
cifrado
• Existen muchos protocolos
que no tienen implementados
mecanismos de cifrado.
• Se puede o bien utilizar un
protocolo nuevo, que soporte
cifrado, o bien protocolos de
nivel inferior (como SSL o
IPsec).
• El problema es que estas soluciones requieren o bien un protocolo
nuevo, o bien una configuración más o menos complicada en el extremo
servidor y en el extremo cliente.
• Mediante SSH, sabemos que podemos crear una conexión segura entre
el cliente SSH y el servidor SSH; de lo que se trata es de usar esa
conexión para crear un túnel por el que pueda transportar una conexión
no segura.
13
Prococolo SSH
port forwarding (II) • El primer paso, consiste en
realizar la conexión con los
parámetros que permitan crear el
túnel.
• En un extremo (cliente o
servidor) se crea la cabecera del
túnel, en el otro la salida.
Cliente de
correo Servidor POP
Cliente SSH Servidor SSH
Conexión segura a través
del puerto SSH (22/tcp).
Para el servidor
POP, el acceso lo
hace “servidor
SSH”.
Salida del
túnel
Entrada del
túnel (“puerto
escuchando”)
Para el cliente
de correo, el
servidor POP es
el cliente ssh PORT FORWARDING COMPLETO (para POP)
Servidor SSH Cliente SSH
ssh <servidor_ssh> -L puerto_cliente_ssh:servidor_pop:puerto_pop
Hacia el servidor
POP real.
Hacia el cliente de
correo real.
14
Protocolo SSH
port forwarding (III)
Servidor SSH y de
POP
Cliente de SSH y
correo
Paquetes
POP Paquetes
POP
El cliente de correo
accede a un servicio
local POP (cabecera
del túnel). A la salida del túnel, se
accede localmente al
servidor POP
Versión simplificada
A veces, se unen el cliente SSH y el de correo en un solo ordenador
(más habitual).
Y también, se unen el servidor SSH y el servidor POP.
15
Protocolo SSH
port forwarding (IV) • El túnel se puede iniciar en el cliente SSH (como hemos visto) o
también en el servidor (hacia el cliente SSH).
Cliente SSH Servidor SSH
Cliente del servicio Servicio
En este caso, la
conexión se origina en
el lado del servidor
SSH.
Paradójicamente, el redireccionamiento de puertos puede plantear
problemas de seguridad.
16
Protocolo SSL
Generalidades
• Originalmente desarrollado por Netscape.
• Provee confidencialidad, integridad y autentificación
(cliente y servidor).
• Está siendo sustituido por TLS1.1 (RFC4346).
Nivel de Aplicación (web, p.ej.)
SSL
Nivel de transporte (fiable)
Se puede usar sobre
cualquier aplicación.
• SSL Handshake P., Change Cypher Specificacion P., Alert P.
• SSL Record Protocol
El protocolo de transporte debe ser
fiable (p.ej. TCP). NO VALE UDP
17
Protocolo SSL
Vista de niveles
SSL Record Protocol
SS
L H
andshake
Pro
tocol
Change C
ipher
Spec.
Pro
toocol
SS
L A
lert
Pro
tocol
• Record Protocol: Recibe los datos y los
fragmenta, comprime, cifra/descifra y
aplica MAC.
• Change Chipher: Sirve para negociar
cifrado y para cambiarlo (lo usa Record
Protocol).
• Alert Protocol: Indica ciertos grados de
alerta (severidad). Por ejemplo
problemas con un certificado.
• Handshake Protocol: Permite la
negociación previa a la comunicación.
Responsable de coordinar a cliente y
servidor.
18
Protocolo SSL
Handshake Protocol (1) El cliente solicita la conexión (indica qué soporta).
(2) Indica los parámetros negociados (el común de ambos) y
si se aceptó el modo “resume”.
(3) El servidor envía su certificado.
(4) Si no tiene certificado, se envían claves temporales.
(5) Petición de certificado al cliente.
(6) Fin del servidor.
(7) Si el cliente tiene certificado y se lo piden, lo envía.
(8) El cliente genera unas claves que envía cifradas al
servidor.
(9) Se verifica el certificado
(10) y ss: Se especifica el cifrado y se termina la negociación.
Las partes en gris, son
opcionales.
Existe un procedimiento
de conexión abreviado
(resume).
Cliente Servidor
Imagen: Cryptography and
Network Security, Third Edition
19
Protocolo SSL
Conclusiones Es transparente para los
protocolos de nivel superior
(usando TCP). Las aplicaciones sí
que se modifican.
Da servicio de autenticidad,
integridad, confidencialidad y no
repudio. Tabla de puertos usados con SSL
Tabla: MariCarmen Romero
Ternero. Apuntes de IP.
Como SSH, sufre ataques a los niveles inferiores.
No se puede usar sobre UDP (requiere un nivel de transporte
fiable).
El proceso de negociación inicial es costoso.
Con todo, es ampliamente usado en páginas
web en todo el mundo.
20
IPSec
Generalidades • IPSec actúa en el nivel 3, protege más
que en los casos anteriores.
Internet Sevilla Madrid
Confidencialidad, integridad,
autentificación Uso 1: Extender la red
corporativa sin
necesidad de líneas
dedicadas y de forma
segura (con routers
especiales).
Madrid Ordenador con
soporte IPSec
Uso 2: Acceso remoto mediante un s.o.
que soporte IPSec (Windows 2000/XP,
Linux, etc).
Imagen: Cryptography and
Network Security, Third Edition
21
IPSec
Arquitectura RFC2401
RFC2402 RFC2406
RFC2408
• Arquitectura: Especifica la arquitectura
general del protocolo.
• ESP: Encapsulated Security Protocol.
Protocolo de IPSec que provee
autenticidad/integridad y
confidencialidad.
• AH: Authentication Header. Protocolo
de IPSec que sólo provee
autenticidad/integridad.
• Algoritmos: Separados en dos tareas,
son usados por los dos protocolos.
• DOI: Unifica criterios y conceptos de
todos los documentos.
• Gestión de claves: Indica cómo se
distribuyen éstas.
Imagen: Cryptography and
Network Security, Third
Edition
22
IPSec
Authentication Header
• Puede viajar sobre un
datagrama IPv4 normal
(protocol=51).
• Provee sólo autentificación
del campo de datos y parte
de la cabecera IPv4. • Next Header: Indica el protocolo que viene después.
• P. Length: Longitud de la AH en palabras de 32-bit menos 2.
• SPI: Permite identificar una SA (Security Association).
• Seq. Number: Permite detectar ataques de repetición, nunca se repite en
una misma SA. Los duplicados se deben descartar.
• Authentication Data: Hash de autenticación. Protege: El campo de datos
(transporte), la propia AH (incluso este campo), parte de la cabecera IPv4
(entre otros: dir. fuente, dir. dest, version, long cab…). Los campos mutables
se ponen a cero.
Imagen: Cryptography and
Network Security, Third Edition
23
IPSec
Encapsulation Security Payload
• Puede viajar sobre un
datagrama IPv4 normal
(protocol=50).
•Además de autenticidad,
soporta la confidencialidad.
• La autentificación NO incluye
la cabecera IP, sólo la
cabecera ESP.
Imagen: Cryptography and
Network Security, Third Edition
• Payload Data: Es el campo de datos al que hace referencia “Next
header”, está cifrado.
• Se puede usar en conjunción con AH.
24
IPSec
Security Association
• Una SA es el elemento que suministra la seguridad.
• Se debe definir una por: a) dirección, b) soporte ESP y AH (una para cada).
• Una SA está definida por: – Una dirección destino.
– SPI
– Un protocolo ya sea ESP o AH.
• Modos de operación: – Túnel (gateway-gateway o gateway-host).
– Transporte (host-host).
25
IPSec
Modo transporte Aplicando AH
Aplicando ESP
• Se aplica entre dos hosts exclusivamente.
• No protege todo el datagrama IP:
• En AH, sólo provee autenticación (parte
de la cabecera IPv4, la cabecera AH y los
datos de nivel superior).
• En ESP, provee de cifrado a todo el
campo de datos de nivel superior y
autenticación sólo a la cabecera ESP.
Los datos dirección fuente y
destino son los reales.
La cabecera IPv4
no va cifrada.
Ejemplo: ESP en modo
transporte (con TCP).
Datos TCP
cifrados.
26
IPSec
Modo túnel (I)
Aplicando AH
Aplicando ESP
• Se aplica entre host-gateway o bien gateway-gateway.
• Encapsula un datagrama IP sobre otro datagrama IP donde el
campo de datos es el primero.
• En AH, se autentifica el datagrama IP original completamente.
• En ESP, se cifra el datagrama IP original completamente.
27
IPSec
Modo túnel (y II)
Sevilla Madrid
Encapsulación /
desencapsulación
Direcciones IP de los
gateways (sin cifrar).
Direcciones
“reales” (cifradas). Toda la trama original
aparece cifrada
• El tráfico en las “nubes” es el tráfico IPv4 normal. Los nodos de Madrid y
Sevilla no tienen que soportar IPSec.
• Para un atacante, sólo “ve” tráfico IP entre los dos gateways.
• Puede plantear problemas ya que reduce la MTU efectiva.
28
IPSec
Conclusiones
En modo túnel los nodos finales “ni se enteran” a Sólo es
necesario configurar los nodos gateway
En modo host se requiere software especial.
En cualquier caso, las aplicaciones no se tocan.
Puede ser complejo de instalar.
Puede ser una vía de entrada de ataques. Se podría entrar a
mi red coporativa a través de IPsec (Y DETRÁS DEL FIREWALL).
29
X.509 Conceptos generales
• X.509 forma parte de la X.500 (ITU). El RFC3280 define un modo de operación
para Internet. Pretende resolver el problema de la “propiedad” de una clave pública.
Si el certificado (que tiene la clave pública) lo crea
el impostor, el usuario podría suministrale datos
confidenciales sin saberlo.
1. El notario verifica que el
certificado es, realmente, del
banco y firma (valida) el
certificado.
2. El impostor, no puede tener
un certificado con esa firma y,
por lo tanto, es detectado.
• Necesito “notarios” electrónicos que verifiquen los certificados (y, por tanto, la
clave pública).
Mi Banco S.A.
Clave pública:
0x0A00A0B1...
Certificado
(sin firmar)
Mi Banco S.A.
Clave pública:
0x0A00A0B1...
Mi Banco S.A.
Clave pública:
0x0A00A0B1...
Certificado
(sin firmar) Certificado
(firmado)
Verificado
y firma
30
X.509 Formato Certificado V3
Imagen: Cryptography and
Network Security, Fourth Edition
• Version: Versión del certificado. La última es la V3.
• Serial: Identificador único (dentro de la misma CA) del
certificado.
• Signature ID: Indica el tipo de algoritmo de firma.
• Issuer Name: Identifica (X.500) al que firma ese certificado.
• Validity: Intervalo (GMT) en el que es válido el certificado.
• Subject Name: Identifica (X.500) al propietario del certificado.
• Public Key Info: Indica el tipo y la clave pública del propietario.
• Issuer Unique Id (v2/v3): Un identificador único del que firma.
• Subj. Unique Id (v2/v3): Igual que antes, para el propietario
(útil para reutilizar el Subject Name).
• Extensions (v3): Extensiones adicionales (ver luego).
• Signature: Algoritmo de firma (otra vez) y la firma propiamente
dicha del certficado (lo hace el issuer).
31
X.509 Extensiones habituales
• Authority/Subject Key Identifier: Facilita tareas de validación. El primero se refiere
a un identificador (hash) del certificado de la CA, el segundo a este mismo certificado.
• Key Usage / Extended key Usage: Sirven para determinar los usos del certificado
(los que no se diga expresamente, no se permite). Ej: TLS Web Server Authentication.
• Authority Information Access: Indica información sobre la CA (políticas p.e.).
• Basic Constrains: Tiene un campo: cA que si es “TRUE”, se trata de un certificado
de Autoridad de Certificación.
• CRL Distribution Point: Indica (casi siempre con una URL)
una lista de certificados revocados.
Identifica al emisor del certificado CRL.
Indica la fecha en la que se emite el certificado.
Indica la fecha (máxima) en la que se emitirá el próximo.
Listado de certificados (serial) con la fecha de
revocación.
Firma del certficado CRL.
CRL Certificate v1
Ima
ge
n: C
ryp
tog
rap
hy a
nd
Netw
ork
Se
cu
rity
, F
ou
rth
Ed
itio
n
32
X.509 Estructura jerárquica (ejemplo Web)
Autoridades de Certificación Raíz: Sus propios certificados
(como CA) son autofirmados. Pueden firmar a “usuarios
finales” o bien otras CA (Intermedias). Es imprescindible
conocerlas previamente.
Autoridades de Certificación Intermedias: Las CA-Raíz
firman sus certificados. Pueden firmar a “usuarios finales” o
bien otras CA.
Servidor Web
Usuarios finales: Sus certificados los firma una CA (intermedia o no).
No pueden firmar nada a nadie. Nota: En este ejemplo es el servidor web.
Ru
ta d
e a
ute
ntifica
ció
n
Ruta de autentificación (Path Validation): El servidor web (en este
ejemplo), debe presentar,al menos, su certificado más el de todas las
autoridades intermedias. El cliente web comprobará (usando los campos
“Subject” e “Issuer”) que puede llegar a una autoridad raíz.
33
Usuario final (servicio web)
CA Raíz (instalada en
el navegador)
Autoridad Intermedia
(no hay conocimiento
previo)
34
1
2 3
Debe
corresponderse
con la URL
Relaciona el certificado
web con la CA intermedia
Relaciona la CA
intermedia con la
CA raíz
1: El certificado de usuario
(web).
2: El certificado de la CA
intermedia (que el propio
servicio web suministra).
3: CA Raíz, instalada
previamente en el navegador
Nota: Es necesario
validar todas las firmas.
35
Uso de X.509
Aspectos adicionales. • En ocasiones existe una tercera entidad la
RA (Autoridad de registro) [FNMT].
• Distinción entre autentificación y cifrado.
• Existen herramientas disponibles para
generar CA y certificados (openssl).
• En la práctica, todas las CA reconocidas
son iguales.
36
Firewalls
generalidades
• Un firewall no es sólo un filtro de
paquetes, es toda una arquitectura.
• Hace homogéneo lo que no lo es.
• Permite forzar una política de seguridad
(dos alternativas).
37
Firewalls
Componentes
• Bastion Host: Ordenador expuesto a
Internet, medidas de seg. extremas.
• Dual-Homed Host: Ordenador con dos
tarjetas de red.
• DMZ (red perimetral): Es la red entre la
red interna e Internet.
• Proxy y filtros: Se ven luego.
38
Firewalls
Filtros de paquetes (screened host)
• Es uno de los elementos fundamentales
de un firewall.
• Su propósito principal es definir un
sistema de control de acceso en base a
una serie de reglas.
• Se aplica en un router que soporte eso,
o bien en un ordenador configurado como
filtro, Pero siempre en el camino de
entrada/salida.
• Dependiendo de lo complejo que sea,
puede llegar a inspeccionar todos los
niveles OSI.
Internet Red Interna
Filtro
Dirección MAC, EtherType.
Dirección IP origen, destino.
Puerto origen/destino, TCP/UDP.
Datos de nivel de aplicación:
FTP, DNS, otros.
Toma de
decisión en
función de:
¿OK? SÍ NO
39
Firewalls
Problemas con filtros (I)
• En TCP se señala perfectamente el inicio
de conexión, bastaría con inspeccionar las
banderas de la cabecera TCP.
• Sin la trama primera “SYN” no es posible
iniciar una conexión TCP.
El concepto de dirección (entrada o salida), SÓLO existe
conceptualmente, casi siempre hay tramas en los dos sentidos.
Debo distinguir lo que es un ataque de lo que es una respuesta
normal.
• En el caso de UDP, es más
complicado pues no existe el
concepto de conexión, pero puedo
observar la petición de salida y
esperar la respuesta.
SYN
SYN+
ACK
ACK
Inicio de conexión
TCP.
¡Solo se usa al
principio!
Registro respuesta, compruebo que es de una
pregunta anterior, permito pasar y cierro el
“hueco”. 4
Puerto origen: 5645,
Dirección Origen=10.7.5.3
Puerto destino: 53,
Dirección Destino=10.2.4.5
(PETICIÓN DNS)
1
Registro parámetros
de la petición, abro un
“hueco” en el filtro.
2
Puerto origen: 53,
Dirección Origen=10.2.4.5
Puerto destino: 5645,
Dirección Destino=10.7.5.3
(RESPUESTA DNS)
3
Ejemplo:
Consulta DNS.
40
Firewalls
Problemas con los filtros (II) • El estándar FTP, cuando no usa el modo
pasivo, al transferirse un fichero, el servidor
inicia una conexión al puerto indicado por el
cliente. Esa conexión entrante “no tiene nada
que ver” con la conexión de control FTP.
Iniciar transferencia. Indico
puerto local abierto (ej. 4531).
21/tcp
20/tcp 4531/tcp
La transferencia se
inicia con una conexión
ENTRANTE.
FTP: conexión de datos
sin modo PASV.
SOLUCIÓN 1: Permitir conexiones con origen puerto 20 y cualquier destino porque
éstas son de una conexión FTP en curso.
1239/tcp
Cualquier conexión entrante se
rechaza excepto las que
provienen del puerto 20/tcp.
20/tcp 22/tcp
Nuestro firewall impedirá esas conexiones
PROBLEMA:
• Si nuestro atacante genera una
conexión con puerto origen 20 (no es
normal, pero es posible), nuestro
servidor está abierto a ataques.
• Se podría paliar con control de acceso
en el propio servidor, pero eso no hace
desaparecer el problema, sólo lo oculta.
41
Firewalls
Problemas con los filtros (III)
SOLUCIÓN 2: Usar el modo pasivo del FTP, en este modo la conexión de
datos se origina en el cliente, y va hasta el servidor.
PROBLEMA:
• Si el servidor al que se accede
no soporta modo pasivo, no es
solución.
• Si tenemos un servidor FTP en
nuestra red local, el modo pasivo
es, precisamente, un problema.
Se permite acceso al FTP
(puerto de control 21/tcp), se
deniega el resto.
Cliente FTP.
21/tcp
5431/tcp
Solicitud de transferencia
modo pasivo al puerto
5431/tcp. 1 El servidor, acepta ese
modo y permanece a la
escucha en ese puerto.
2
¡La conexión no se
produce por culpa
del filtro!
SOLUCIÓN 3: Permitir el uso de los dos modos, y usar un filtro que
inspeccione el nivel de aplicación (las solicitudes de transferencia).
PROBLEMA:
• Para filtros simples, esto no es posible. Si lo es, suministra más carga al filtro.
• No hay una solución universal para todos los protocolos de Niv. de Aplicación.
42
Firewalls
Servidor Proxy
• Los clientes no acceden
directamente al servidor, sino que
es el proxy el que lo hace en su
nombre. Me permite inspeccionar
las peticiones.
• A veces es necesario un cliente especial que soporte estar detrás de un
proxy, pero otras (p.ej: smtp, http ) se usa el cliente normal. El proxy, en
cualquier caso, es específico para cada aplicación.
• Lo ideal es que el cliente (usuario) ni siquiera se de cuenta: proxies
transparentes.
El proxy recibe esas
peticiones y es el proxy el
que accede al servidor web.
Servidor WEB Servidor proxy Navegador WEB
Se redirecciona
la petición al
servidor web.
Proxy transparente Servidor WEB
“Cree” que las
peticiones las hace
“proxy
transparente”. (dir.
IP origen == proxy) Navegador WEB
Cree que accede
directamente al servidor WEB
(dir. IP dest == Servidor WEB)
Monitorizar acceso, control de acceso por
horas, impedir acceso a contenidos que violen
las políticas de uso, control de virus, mejorar
rendimiento (proxy-cache).
¿Qué puedo
hacer?
43
Firewalls
Arquitecturas. Screening router Red Interna Internet
En esta arquitectura, el único
elemento es un filtro de paquetes (ya
sea un router o un ordenador).
Es muy simple de implementar.
Es la primera y “última” línea de defensa. Es conveniente instalar contramedidas en los hosts de la
red interna.
Permite filtrar por puertos (aplicaciones) y por direcciones IP (ordenadores), pero no por usuarios.
Tiene acceso limitado al nivel de aplicación:
• Respecto al filtrado de protocolos complejos.
• No puede hacer un análisis tipo antivirus, filtros por contenidos …
• No puede distinguir un acceso al puerto 80 que transporte HTTP de un acceso al puerto 80
que transporte SSH (se entiende conexiones dentro->fuera).
Se puede implementar con ACL en un router CISCO o con “iptables” en
Linux.
44
Firewalls
Arquitecturas. Dual-homed host
Imagen: Building Internet
Firewalls, 2nd Edition.
• El host central, tiene las capacidades
de routing desactivadas.
• El acceso directo entre Internet y la red
Interna está prohibido. Sólo se accede a
través de los servicios de proxy
(transparente o no) del host central.
• Es más robusto que la arquitectura anterior, pero sigue habiendo un punto
único de fallo.
• Para redes de tamaño medio es correcto, redes grandes podrían
sobrecargarlo.
• Hay servicios que son difíciles de implementar con proxy, y tener cuentas en
el mismo no es buena idea.
• No permite tener servicios al exterior.
45
Firewalls Arquitecturas. Bastion Host sin DMZ
• El filtro se establece de forma que sólo se
permita el tráfico desde y hacia el Bastion
Host.
• Los usuarios de la red interna hacen uso de
los servicios de proxy, igual que antes.
• Se permite que el Host Bastion albergue servicios al exterior. En este caso,
el filtro impone medidas adicionales de seguridad ante problemas.
•Opcionalmente se pueden permitir ciertos accesos directos desde la red
interna (aquellos en los que no se puede usar proxy).
• Si alguien accede al Host Bastion, puede aplicar otras tácticas para
acceder a la red interna (incluso en redes con switch).
Imagen: Building
Internet Firewalls,
2nd Edition.
46
Firewalls Arquitecturas. Bastion Host con DMZ
Imagen:
Building
Internet
Firewalls,
2nd Edition.
• Traslado nuestro Host Bastion a una red
perimetral (DMZ) que es físicamente distinta
de la red interna.
• Los ordenadores de la red interna o bien
acceden a través del Bastion Host, o bien
directamente. El acceso a la red interna está
prohibido, incluso para la DMZ.
• La DMZ y la red interna son ahora dos dominios de broadcast distintos, un
ataque al Bastion Host no afecta a la red interna.
• El router exterior no hace casi nada, además no suelo tener acceso a él.
• En el caso de determinados servicios (DNS, SMTP), se puede plantear algunos
dilemas interesantes.
• Es una arquitectura bastante válida.
47
Firewalls
Otras arquitecturas
Esta arquitectura tiene dos Bastion
Host, cada un para una tarea
determinada. Permite distribuir carga.
En esta arquitectura, se fusionan el router
interior y el exterior. Siempre que se puedan
definir reglas de filtrado con versatilidad,
sigo teniendo una DMZ.
En este caso, se fusionan el Bastion
Host y el router interno. Esta
arquirectura es mala porque supone
eliminar “de-facto” la red DMZ.
Imágenes: Building
Internet Firewalls, 2nd
Edition.
48
Firewalls
Otras arquitecturas
Sin embargo, es posible unir el Bastion Host y el
router exterior, por ejemplo si se accede con
modem y es el Bastion Host el que lo hace.
Esta arquitectura no es recomendable
porque suele ser difícil mantener la
coherencia entre los dos router, y basta que
sólo uno esté mal configurado para que
tengamos problemas de seguridad.
Si quiero tener varios routers, esto es
mucho mejor. Además esto me permite
crear distintos niveles de seguridad dentro
de la red interna. Imágenes: Building
Internet Firewalls, 2nd
Edition.
49
Firewalls
Conclusiones
• ¿Qué puede hacer un firewall?
– Proteger de forma homogénea lo que no lo
es.
– Forzar determinadas políticas.
• ¿Qué no puede hacer?
– Protegerme del “enemigo en casa”.
– Protegerme de lo que no se que existe.
– Protegerme de nuevas amenazas.
50
Seguridad
Discusión final
• La visión de la seguridad como
vulneración de libertades fundamentales.
• Lo que es cómodo para mi es incomodo
para “ellos”.
• Es fundamental que se establezca una
política de seguridad por parte de la
dirección de la empresa.
51
Bibliografía
• “Building Internet Firewalls 2nd Ed.”, Chapman y otros, O´Reilly.
• “Web Security, privacy and comerce 2nd Ed.”, Garfinkel, O’Reilly.
• “Cryptography and Network Security: Principles and Practice”, W. Stallings,
PrenticeHall 2003.
• http://www.snailbook.com/protocols.html, Documentación SSH.
• http://wp.netscape.com/eng/ssl3/draft302.txt , Documentación SSL.
• RFCs de IPsec.
Agradecimientos: