Vamos a ver que hay muchos tipos de scaneos de puertos, no es uno solo, hay algunos mas silenciosos que otros, otros mas efectivos. Todos se basan en un conocimiento profundo de TCP/IP.






Los protocolos basados en TCP, son protocolos orientados a conección. Esto quiere decir, que hay todo un proceso para armar la conección, recien ahi se empiezan a mandar los paquetes necesarios (la información que se tenian que mandar) y luego terminan la conección. Esto hace que los protocolos basados en TCP sean mas lentos, que los protocolos basados en UDP (no vamos a hablar de UDP/IP ahora, pero lo que tienen que saber, es que los protocolos basados en UDP, no arman una conección previamente a mandar los datos necesarios, si no que los mandan a lo 'bruto' sin fijarse si el receptor esta en condiciones de recivirlos o no).


Vamos a profundizar un poco mas en esto de como se maneja el protocolo TCP/IP.

Cuando ustedes necesitan hablar con alguien por msn, y pedirles algo, generalmente primero lo saludan, esperan el saludo de la otra persona, luego de eso (y al asegurarse que del otro lado del msn hay una persona escuchandolos) le dicen lo que necesitan, y su comunicación termina con una despedida. Aunque siempre se encuentran maleducados en la vida ¬¬ (en la informatica, es microsoft ....)

En TCP/IP es lo mismo. El proceso es asi:

1. Petición de conección --> Persona A
2. <-- Conección aceptada Persona B
3. <-- Ida y vuelta de datos -->
4. Cierre de conección


Por otro lado, les voy adelantando que en UDP/IP, el esquema seria este:

Persona A <-- Ida y vuelta de datos --> Persona B



Los paquetes TCP/IP son estructurados, y esta es la estructura de su cabecera de datos:


| Puerto Origen | Puerto Destino |

| Numero de Secuencia |

| Numero de Confirmación           |

|Comienso de | |U|A|P|S|F|       |
| Datos | |R|C|S|Y|I| Ventana   |
| | |G|K|H|N|N|                       |

| Suma de | Puntero de             |
| Comprobación | Urgencia         |

| Datos                                   |



Asi se organizan las cabeceras de los paquetes TCP/IP que circulan por nuestra PC Wink
A medida que vamos a ir necesitando, vamos a ir explicando para que sirve cada parte de la cabecera de un paquete TCP/IP (en este articulo expicaremos algunos, a medida que vamos abanzando, veremos mas)

Por ahora, veremos los Flags. Los flags ocupan 1 bit cada uno en la cabezera de un paquete, y como pueden ver (aunque quedaron chuequitas las | ) son URG, ACK, PSH, SYN, FIN. Como sabran, que ocupe 1 bit significa que es 1 caracter, y como se pueden imaginar puede ser 0 o 1.



Como ya habiamos adelantado, si el protocolo se basa sobre TCP/IP, es un protocolo orientado a conección, y ahora veremos como se hace esa conección.


1 -> Enviamos un paquete SYN Host A
2 <- Recibimos un paquete SYN ACK Host B
3 -> Enviamos un paquete ACK

Asi es como realmente se realizan las conecciones TCP/IP


Veamos, antes de comenzar a enviar los datos que realmente queremos enviar, vamos a armar una conección para asegurarnos que el Host B va a recibir los paquetes que estamos enviando y que no los estamos enviando al vacio =P (ya los tengo podrido con esto de que es orientado a conección, no?)

Enviamos un paquete con el Flag SYN activado (o sea, con el Flay Syn valiendo 1)
Cuando este paquete le llega al Host B, este interpreta que el Host A esta intentando comenzar una conección, (si las reglas de administración lo permite, digamos, si ningun router, firewall, o lo que sea lo impide) este le contesta con un paquete que tiene dos flags activados: SYN y ACK. Esto quiere decir que acepta la conección
El Host A al recibir este ultimo paquete, tiene la aceptación del Host B para iniciar una conección con el, solo falta que responda con un paquete ACK para que realmente la conección se establezca.

En todo este proceso, que obviamente se hace automaticamente, la conección toma distintos estados.

• Cuando enviamos el paquete SYN, nuestro estado es SYN_ENVIADO
• Cuando recivamos la respuesta del Host B (el paquete con los flags SYN y ACK activados) nuestro estado de coneccion es SYN_RECIBIDO
• Luego de enviar por ultimo el ACK, el estado sera de ESTABLECIDO

-. Flag URG: Este Flag, significa que tiene caracter de urgente el paquete. Que debe ser tratado primero que los Paquetes normales, es decir que se saltea la cola =P

-. Flag ACK: Este paquete se usa como confirmación de que el paquete anterior fue recivido.

-. Flag PSH: Se utiliza para vaciar un buffer de transimision (por ahora no importa)

-. Flag RST: Significa Reset, es para reiniciar una conección porque capaz un paquete llego corrumpido (los paquetes tienen verificaciones, por si se perdio un paquete por el camino o por si alguien esta mandando paquetes corruptos =P)

-. Flag SYN: Para comenzar una conección.

-. Flag FIN: Para finalizar una conección.


Fin de la 'teoria' vamos a la practica



Hay muchas técnicas, algunas mejores que otras, algunas mas silenciosas, otras mas directas, yo lo que voy a explicar ya lo puse en practica, pero luego nos reuniremos por el IRC a practicar Smile
Para esta practica, usaremos el nmap. Bajenlo de aca.

1- TCP_CONNECT

Este es el mas comun de todos, directamente, nos conectamos un host al puerto que queremos saber si esta abierto. Si nos podemos conectar, esta abierto.
Ahi pasaria lo que explicamos arriba, los 3 pasos para formar una conección
Si esta cerrado, en vez de recibir un paquete SYN-ACK, recibiremos un RST

2- SYN_SCAN

Este es un scan de medio pelo, y lo que hacemos es esto.
Mandamos un paquete SYN; si recibimos un paquete SYN-ACK no respondemos con un paquete ACK, si no que mandamos un paquete RST para cerrar la conección.
¿porque? Fácil, el Host B (mantengamos esa idea en la cabeza) ya nos informo perfectamente que tiene el puerto abierto o cerrado, y el solo echo de responder con un ACK para armar la conección a ese puerto, seria una estupidez, ya que no sacariamos provecho alguno, mas que dejar un lindo log de conección en el SO.
Este tipo de scaneo, es bien reconocido por los firewalls, les aparecera algo como SYN attack (el mcaffe lo muestra textualmente asi) pero es mejor que nada.
Digamos, a un firewall le basta y le sobra con que le llege un paquete SYN pidiendo que se arme una conección; pero al SO solo se da cuenta y hace un log cuando se completa el intento de conección

nmap escribió:
nmap -vv -PO -sS ip

3- Stealth Scan

Este scaneo es realmente bueno y silencioso, muchos firewalls lo pasaron por alto.
La idea de este scaneo, es mandar un paquete FIN al Host B a determinado puerto, si nos responde con un paquete RST, el puerto seguro esta cerrado.
Caso contrario (si no responde) esta abierto o silencioso (un puerto silencioso, no responde a estos pedidos)
Si bien, tiene como ventaja que la mayoria de los firewalls lo pasan por alto (por no armar una conección) Windows, que no siguen los estandares de nada, no respeta esta estructura TCP/IP (asi como su IE no sigue los standares de la programación web y luego la gama de Mozilla es "inconpatible"). Asi que no es buena idea lanzar este tipo de scaneos a un SO windows ya que nos dara una infinidad de puertos abiertos, que en realidad no esta. Aunque por otro lado, nos sirve para osfinger, de esta forma ya sabemos que estamos frente a un SO windows =P

nmap escribió:
nmap -vv -PO -sF ip


4- ACK Scan

Este tipo de scaneo, esta orientado para determinar cuando un puerto esta silenciado (que era la falla de los anteriores)
La idea es esta, si le mandamos un paquete ACK a un Host B, con todo aleatorio (como si hubiera existido en algun momento una conección) el Host B interpretara que ese paquete es totalmente erroneo, y que nunca hubo un intento de conección... por eso si el Puerto esta abierto, o cerrado, en cualquiera de los dos casos, nos respondera con un paquete RST.
Pero si no responde, ya sabemos con perfección que ese puerto esta filtrado por un firewall!!
Como veran, esta tecnica es extremadamente útil para convinarla con otra, para sacarnos las dudas.

nmap escribió:
nmap -vv -PT ip



Vamos a aplicar nuestras técnicas para hacer un DoS, aprovechando nuestros conocimientos de TCP/IP
Vamos a hacer uno que consume los recursos, veamos, cada vez que uno se quiere conectar con un HOST y envia un paquete SYN a el, este crea una tabla en memoria, llamda estructura de datos. Asi con cada intento de coneccion de una IP, a un puerto, vamos a intentar floodear al sistema con paquetes SYN, con muchos intentos de conección para consumir recursos en memoria y hacer un DoS al demonio.
Para hacer esto de manera correcta, tenemos que spofear el IP. ¿Y esto porque?

Host A --> Envia paquete SYN --> Host B
24.232.144.xxx con IP Spofeada
1.1.1.1

Bueno, si el HOST B recibe un paquete SYN de la IP 1.1.1.1, va a intentar responder al IP con un SYN/ACK, la gracia es que al no existir la IP 1.1.1.1 nunca recibira una respuesta al paquete que "envio" 1.1.1.1 y se quedara consumiendo recursos en memoria, en su estructura de datos. (cada conección tiene un time to live, es decir, luego de x cantidad de tiempo, se borran automaticamente, liberando los recursos en memoria)
Al ser flood, obviamente hay que hacer esto, con muchos paquetes, por ejemplo con 100; todos con IPs spoofeadas.
Hay un programa muy poderoso para linux que nos permite hacer esto automaticamente, es hPing (hping es un programa propio para linux, lo pueden hacer desde una shell si no disponen de un windows instalado en su propia pc, o si no, utilizar nemesis que es parecido y corre sobre windows)

hPIng escribió:
hPing xxx.xxx.xxx.xxx --rand-source --destport 21 --syn --count 150

Explico brevemente:
rand source, enviara desde IPs aleatorias.
destport 21, ataca a la IP xxx.xxx.xxx.xxx al puerto 21
syn, obiviamente pone un 1 en el flag syn
count 150, va a enviar 150 paquetes

Un problema para esto, es cuantos routers o sistemas de validación hay en el medio entre vos y tu destino xxx.xxx.xxx.xxx
Capaz antes de llegar al destino, tenes routers que verifican que las IPs no son validas, y no dejen llegar los paquetes a destino.

Buena RooT_Shell Buen Tema me sirbio de algo Gracias.

Buen tuto root, Muchas Gracias. ^^

Exelente men! EXLENTE!  me explico mucho y ahora se mas!

2- SYN_SCAN
Mandamos un paquete SYN; si recibimos un paquete SYN-ACK no respondemos con un paquete ACK, si no que mandamos un paquete RST para cerrar la conección.
¿No responderíamos con un FIN? Porque con el RST volvería a comenzar la conexión y lo que se busca es finalizar de una vez porque ya sabemos que el puerto está abierto

2- SYN_SCAN
Mandamos un paquete SYN; si recibimos un paquete SYN-ACK no respondemos con un paquete ACK, si no que mandamos un paquete RST para cerrar la conección.
¿No responderíamos con un FIN? Porque con el RST volvería a comenzar la conexión y lo que se busca es finalizar de una vez porque ya sabemos que el puerto está abierto

Tenemos dos maneras de cerrar la conexión. Con FIN y RST.

Con FIN: Le decimos al otro host.. terminamos la conexión pero estoy dispuesto a escuchar lo que quieras decir.

Con RST: Le decimos.. Acá termino todo. No quiero que me digas más nada.. ni quiero escuchar más nada. Adiós.

.. se entiende!?.

El método SYN luego que recibe el syn/ack y sabe que el port esta abierto le envía un RST.

Saludos.