[Indice][Tema
1] [Tema 2] [Tema 3] [Tema
4] [Tema 5]
Tema 3: Seguridad en redes.
1.Criptografía en las redes.
1.-Cifrado de enlace
El cifrado de enlace consiste en que el
cifrado se establece en el software de red y se manda por la red cifrado.
Al llegar al destino el mismo software de red se encarga de descifrar el
texto y lo muestra a la aplicación que desea en claro, y lo almacena
en claro en el Sistema Operativo por lo que el texto queda expuesto a la
seguridad del SO. Si algún individuo viola la seguridad del SO entonces
tendrá acceso a nuestro mensaje confidencial.
La ventaja de este cifrado es que todas las aplicaciones de la máquina
se benefician de el texto que ya esta cifrado no teniendo que descifrarlo
ellas mismas.
El inconveniente más grande es que la seguridad queda al amparo
de la seguridad del SO que disponga la máquina. Otro inconveniente
es la difícil implementación en una red extensa como es Internet,
aunque existe uno bastante extendido como es el IPSEC (el cifrado se realiza
en la capa IP del protocolo TCP/IP). Hay otro cifrado de enlace que se
aplica en las tarjetas Ethernet.
Cifrado a través de IPSEC (marca roja implica
texto claro)
Cifrado a través de Ethernet
En los dibujos se puede apreciar donde se realiza el
cifrado. Hay que observar que se hace dentro de las capas de la red.
2.- Cifrado de extremo a extremo
En este sistema de cifrado el cifrado al contrario que
en el cifrado anterior lo realiza la misma aplicación que lo necesita,
enviándolo por la red cifrado. Una vez llega a su destino
es la misma aplicación la que se encarga de descifrar el mensaje.
Ejemplos de cifrado de extremo a extremo:
-
SSL /TLS : utilizado para comunicación por sesión (páginas
web, TELNET, FTP, ...)
-
SMIME : utilizado para el correo electrónico (que es una comunicación
sin sesión)
-
PED
SSL / TLS
El SSL es una implementación de Netscape
y TLS es un descendiente casi idéntico a SSL.
El SSL tiene como objetivos principales la confidencialidad
y la autenticación del servidor. Opcionalmente también se
puede establecer la autenticación del cliente, pero el servidor
puede utilizar sus propios métodos para autentificar al cliente.
El servidor tiene que tener un par de llaves RSA
y un certificado X.509 debidamente firmado por una autoridad certificadora.
El cliente al establecerse la conexión el
servidor debe ponerse de acuerdo con el cliente en algún algoritmo
de cifrado simétrico que los dos conozcan con la misma longitud
de clave, que será con el que se comunicarán en verdad.
Una vez establecido el algoritmo simétrico
el servidor manda el certificado X.509 que es público. Entonces
el cliente lo verifica mediante la firma de la autoridad certificadora
(cifrada con la clave privada de la CA).
Una vez verificado se realiza la verificación
que quien nos esta mandando este certificado es su dueño, ya que
como este certificado es público es posible que no sea él.
Para ello se manda algo cifrado con la clave pública del servidor
(retro), podría mandarse cualquier texto pero se opta por elegir
un número lo más aleatorio posible ya que si siempre mandamos
el mismo texto podría darse el caso que el servidor (o persona que
se hace pasar por él) lo adivinase. Para adelantar trabajo en la
conexión el número aleatorio se establece como clave de sesión.
Entonces el servidor la descifra con su clave privada
(que solo él debe tener) y se establece la conexión.
A partir de este momento cualquier intercambio que
se haga entre servidor y cliente o viceversa se cifrará con
el algoritmo elegido en común y la clave de sesión establecida.
Si por algún casual el servidor no pudiese
descifrar la clave de sesión daría muestras que no es quien
dice ser y la conexión se pierde, porque aunque el cliente
le mande peticiones cifradas con la clave de sesión aunque quiera
no podrá descifrarlo porque no tiene la clave de sesión.
Opcionalmente se puede autentificar el cliente.
Para ello se puede utilizar el sistema user / password que no hay ningún
problema en enviarlo por red porque la información esta toda cifrada.
También puede procederse de la siguiente
forma. El servidor le pide al cliente que se autentifique para ello el
cliente le manda su propio certificado, del cual el servidor extrae la
clave pública (después de comprobar la firma de la CA) y
le manda un retro al cliente con un número aleatorio y con ello
comprueba realmente si es él o no.
Seguridad en web.
Se puede restringir el acceso por servidor
o por directorio.
Existen unas directivas que permiten hacer esto:
deny IP1, IP2, IP3 , nombre
allow IP1, IP2, IP3 , nombre
En la primera directiva se prohibe el acceso a los clientes
con IP comenzadas por IP1, IP2, IP3, y aquellos acabados con nombre.
En la segunda es lo mismo pero en vez de prohibir
permitir
3.- Seguridad en el correo electrónico (SMIME).
Para empezar a hablar del SMIME primero hay que estudiar
el MIME ya que el SMIME es un subconjunto del MIME.
La estructura de un email MIME es: cabecera y cuerpo,
ambas separadas por una linea en blanco.
La estructura de la cabecera es del formato campo
: valor (;otracosa = adicional). Veamos un ejemplo:
MIMEversion : 1.0
Content-type : grupo/subgrupo
Content transfer encoding : {7 bits, 8 bits, base 64}.
Content-type.
Es un campo obligatorio ya que sino el agente de
correo no sabe lo que le mandas.
En este campo se escribe el tipo de aquello que
enviamos, por ejemplo image/jpg . Cuando el tipo o subtipo aceptado
del todo se añade delante x-. Para enviar más de un
tipo por email se utiliza el tipo multipart cuyos subtipos son:
-
Signed: firmado (SMIME).
-
mixed: mixto.
-
related
-
alternative
El subgrupo mixed es una forma de indicar que el email
se compone de una colección de entidades MIME. Veamos un ejemplo
donde se utiliza el multipart / mixed.
MIMEversión : 1.0
Content-type: multipart / mixed; boundary = esto debe ser irrepetible
pq separara todo lo que hagamos
{linea en blanco}
Si te aparece esto es que tu mailer no sabe lo que es el MIME
--esto debe ser irrepetible pq separara todo lo que hagamos
Content-type: text / plain
{linea en blanco}
Esto es ya el mensaje en si
{linea en blanco}
--esto debe ser irrepetible pq separara todo lo que hagamos
Content-type: image / jpg
Content tranfer encoding : base 64
{linea en blanco}
adfhOIAFSDFHOIHJhlkjhlkjyu983579385hfjkh jrehtnlreukhtlkumjh cjhnjhljkhrnjk
jhrqlkehmc hjhlkj4ynkcn nbf4uy4iu3o2yiu43ypoyukjn jm bvbkvlwj4potumkjnñlkjlkj
KLJILJLKJÑ
SMLKGJLKVJK RKLJLKWJLÑKTJWIUIO45JKLNM LKJLKÑJLJKLMÑLKjlkkjblkjghjkf
{linea en blanco}
--esto debe ser irrepetible pq separara todo lo que hagamos-
Este es un ejemplo donde se manda un texto normal y
una imagen jpg.
Content tranfer encoding
Es un campo indispensable ya que nos dice en que
formato esta codificada la información del mensaje. Hay tres tipos:
-
7 bits : este es el código ASCII no extendido y este formato es
el que interpreta él por defecto.
-
8 bits : este es el código ASCII extendido.
-
base 64: este formato se emplea para representar información binaria
tales como fotos en caracteres imprimibles. Consiste en coger 8 bits del
documento binario y pasarlos a un subconjunto del ASCII imprimible.
SMIME.
En el SMIME aparecen tipos nuevos tales como:
Mensaje cifrado
Aquí esta todo oculto dentro del mensaje
cifrado por lo que solo tiene un tipo. Veamos un ejemplo:
MIMEversión : 1.0
Content-type : application / x-pkc7-mime
Content tranfer encoding : base 64
ajeijvmdsakfmkljfñlkjnvauieuicdmlkklfjñveoirumcjkl
fjadmlkfsljvmñlkjeiojmcjklf bhg4uiypoiu985y983ynvhk
iviufmdciajioh njkvitu4m8 io45ujmiomjjñkjalkjdlñk
El mailer descifra el mensaje elimina la cabecera y
lo pega. El resultado es un mail.
Análogamente la persona que lo envía
debe cifrar todo el mail (cabecera incluida) y añadirle la cabecera
arriba puesta.
Mail firmado.
El objetivo es poder leer el mail aunque
no se pueda comprobar la firma, por lo que tendrá dos partes el
mensaje en si y la firma.
MIMEversion : 1.0
Content-type : multipart / signed ; protocol ="application/x-pkcs7-signature
mical :sh1;
boundary =esto debe ser irrepetible pq separara todo lo que hagamos
si ves esto es que no lo tienes bien configurado
--esto debe ser irrepetible pq separara todo lo que hagamos
Esto es el mail en si. Es posible la recursividad ,esto es que dentro
de este mail podríamos definir un multipart/mixed que a su vez contuviera
otro ... etc
--esto debe ser irrepetible pq separara todo lo que hagamos
Content -type : application / x-pkcs7-signature
Content tranfer encoding : base 64
adfkjakfjsdklfjsdlkfjldksfjkldjf---la firma electrónica--afdkjfkdjfakldjfñ
sfjasdfjkdsajfañljfkldjfewr934uriohfjnbm clirthhnfndkjsfñaoi4uhfjkghrñkth
çtkituqklfnertñuihihnfantñklerjhtqñkjnerklenrlkñjrtñliqnfkmlnfkljrñklrjken
--esto debe ser irrepetible pq separara todo lo que hagamos-
Debe tenerse en cuenta en no alterar ni siquiera en
un carácter el mail una vez firmado porque sino la firma seria errónea
Mail firmado y cifrado.
En este punto solo hay que comentar que el mail
resultante se debería firmar y luego cifrar tal y como recomendamos
en el tema 2. El mail resultante solo tendría un tipo, porque la
firma quedaría oculta dentro del texto cifrado.
2.- Amenazas de la red
a)Escuchar - sniffing :
este tipo de amenaza se produce cuando el interceptor escucha la comunicación
a través de la red. Este tipo de intrusión nos preocupa cuando
la información no esta cifrada, porque si esta cifrada aunque escuche
no se enterara de nada.
Un ejemplo de sniffing es este dibujo:
Aqui si A y B se conectan C puede escuchar y ademas
si A y B se comunican C y D no pueden utilizar la red.
Una solución es mantener el cable dentro
de otro cable (coaxial) de forma que se produzca el vacío o haya
una presión constante de tal forma que cuando alguien pinche el
cable varíe la presión y repararlo. Este sistema es muy caro
Otra solución es implementar la red de forma
que se establezcan circuitos virtuales. Es decir que cuando A se conecte
con B se establezca ese circuito de información y que C no pueda
entrar.
b) Spoofing - suplantación
de identidad (ataque a la autenticidad).
Esto consiste tal y como su nombre indica en hacerse
pasar por otra persona
Una buena solución es la firma electrónica,
guardar la password en un lugar seguro, elegir bien la password, ...
c) Hijacking - suplantación
de conexión
A se conecta con B, una vez A se ha autenticado
frente a B C lo suplanta y se comunica con B como si fuese A.
Hay que resaltar que C no necesita autenticarse
frente a B porque ya lo ha hecho A.
Soluciones:
-
Comunicación segura cifrada mediante clave de sesión, de
ese modo C podrá entrar pero no se enterara de nada porque no se
enterara de nada porque no conoce la clave de sesión.
-
Pedir la autenticación de A cada X segundos.
d) DOS - denial of service
Esta amenaza consiste en atacar a un punto dejando
fuera de funcionamiento sus servicios. Sobre todo se utiliza para atacar
servidores.
Tambien puede darse por un mal diseño de
la arquitectura (por ejemplo un determinado sistema es diseñado
para 100 peticiones, si en un determinado momento se efectuan más
peticiones se produce una denegación de servicios.
e) Intrusión.
Esto es entrar en el servidor sin autenticación.
Es la más frecuente y va relacionado con los fallos del software
(bugs).
f) Ataque DNS
Consiste en hacer que el DNS de IP falsas
3.- Cortafuegos (Firewall)
Para protegerse de amenazas una empresa que tiene
instalada una red local puede establecer una maquina de forma que filtre
los paquetes que lleguen a través de Internet.
Para ello se utiliza la técnica de filtrado
de paquetes que consiste en permitir o evitar el paso de ciertos paquetes.
Los paquetes a nivel de TCP se distinguen por el
puerto destino y por el puerto origen.
Los paquetes a nivel del protocolo IP se diferencian
por la IP origen y por la IP destino.
Si fusionamos los dos protocolos (TCP/IP que es
el que se usa para acceder a Internet normalmente) podemos restringir el
acceso o permitir a paquetes segun su puerto/IP de entrada/salida.
El proceso mediante el cual el cortafuegos filtra los
paquetes se le denomina forwarding.
También el cortafuegos puede ser una máquina
con "vida propia" (que tenga un sistema operativo instalado y que algunos
paquetes vengan dirigidos directamente) por eso se definen también
los siguientes procesos:
-
Input: esto es cuando llega un paquete al cortafuegos procedente de la
red externa. Logicamente el forwarding no tiene sentido si para ese paquete
no esta activado el input, porque para entrar en la red corporativa tiene
que pasar primero por el cortafuegos.
-
Output: análogamente se define este proceso que es lógicamente
el contrario al anterior.
Cuando un paquete es rechazado por el cortafuegos tiene
dos alternativas:
-
Reject: en esta opción lo que hace es enviarle al usuario que ha
pedido o ha enviado ese paquete una notificación diciendo que no
se ha podido mandar.
-
Discart: esta opción no avisa al usuario el cual se queda esperando
respuesta a su petición.
El administrador del sistema al configurar el cortafuegos
tiene dos alternativas:
-
Politica abierta: en esta politica lo que se hace es permitir que pasen
todos los paquetes excepto aquellos señalados explicitamente.
-
Politica cerrada: se prohíbe todos los paquetes y se permiten
algunos paquetes. Esta implementación es más difícil
en la médida en que no solo hay que permitir que salga un
cierto paquete sino que hay que permitir que entren los paquetes respuesta.
Para ello se permite la entrada a aquellos paquetes que tienen el bit ACP
activo ( este bit esta activo siempre y cuando los paquetes sean respuesta
de algún otro paquete).
La linea roja simboliza los peligros de Internet y la
linea azul la seguridad del que se siente protegido.