elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.
 
Inicio Ayuda Buscar Ingresar Registrarse
27 Mayo 2012, 15:51  


Tema destacado: Recuperar cuenta de Google, GMail, Youtube

+  Foro de elhacker.net
|-+  Seguridad Informática
| |-+  Hacking Avanzado
| | |-+  Hacking Básico (Moderadores: zhyzura, kamsky, TRICKY)
| | | |-+  Controlar puertas habiertas en los firewall
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: Controlar puertas habiertas en los firewall  (Leído 335 veces)
TigreDARK


Desconectado Desconectado

Mensajes: 369



Ver Perfil
Controlar puertas habiertas en los firewall
« en: 9 Agosto 2005, 16:04 »

Ya se que con NMAP tambien se puede hacer (si no recuerdo mal!).
Pero aca tambien hay una utility para poder controlar las puerta habiertas de un firewall! Lo siento mucho que este en Ingles... Al fondo puse una traduccion con una traductor de palabras! asi que no se fien MUCHO de eso! bye

============================================================

Firewalking:

Firewalk is just another utility written by Mike Schiffman, and can also be found at www.packetfactory.net. The aim of this little handy tool is to find open ports on a filtering device, Firewall. It works by checking a live system behind a firewall, without touching this system to discover which services are permitted, which ports are open on that firewall.

A second potential advantage of firewalk is mapping the unknown network behind the filtering device. By sending packets to every host behind the firewall, an attacker can generate accurate topology of the network behind the firewall.

The firewalk scan works by sending out TCP or UDP packets with an IP TTL evaluated to expire just one hop past the firewall. If the filtering device allows the traffic in, then it will send the packets to target where the TTL will get zero and the target will elicit a TTL exceeded on transit back to attacker. If the filtering device does not allow the traffic in, then we will not see any packet back which means the port is closed.

 

[willyhacker]#firewalk -n –P135-140 –pTCP 10.10.0.5 10.10.0.20

Firewalking through 10.10.0.5 (towards 10.10.0.20) with a maximum of 25 hops.

Ramping up hopcounts to binding host...

probe: 1 TTL: 1 port 33434: <response from> [10.10.0.4]

probe: 2 TTL: 2 port 33434: <response from> [10.10.0.6]

probe: 3 TTL: 3 port 33434: <response from> [10.10.0.8]

probe: 4 TTL: 4 port 33434: <response from> [10.10.0.10]

probe: 5 TTL: 5 port 33434: Bound scan: 5 hops <Gateway at 5 hops> [10.10.0.10]

port 135: open

port 136: *

port 137: open

port 138: *

port 139: open

port 140: *

However, what we see on our tests is that, some firewalls recognize that the packet will expire when they get to the target host before applying ACL rules. And they elicit an ICMP TTL Expired packet back to attacker and this leads to false-positives.

To learn more about firewalk, you can check the following URL www.es2.net/research/firewalk
==================================================

TRADUCIDO AL ESPAÑOL

Caminar sobre el fuego:

Firewalk es apenas otra utilidad escrita por Mike Schiffman, y se puede encontrar también en www.packetfactory.net. El objetivo de esto instrumento cercano pequeño deberá encontrar los puertos abiertos en un dispositivo que filtra, el Cortafuegos. Trabaja verificando un sistema vivo detrás de un cortafuegos, sin tocar este sistema para descubrir cuál servicios se permiten, cuál puertos están abierto en ese cortafuegos.

Una segunda ventaja potencial de firewalk traza la red desconocida detrás del dispositivo que filtra. Mandando paquetes a cada anfitrión detrás del cortafuegos, un atacador puede engendrar topología exacta de la red detrás del cortafuegos.

El firewalk escudriña los trabajo arrojando TCP o paquetes de UDP con un IP TTL evaluaron para expirar sólo un pasado del salto el cortafuegos. Si el dispositivo que filtra permite el tráfico en, entonces mandará los paquetes a concentrar en donde el TTL obtendrá cero y el objetivo sacará un TTL excedió en la espalda de tránsito al atacador. Si el dispositivo que filtra no permite el tráfico en, entonces nosotros no veremos cualquier espalda de paquete que significa que el puerto se cierra.

 

[willyhacker]#firewalk -N –P135-140 –pTCP 10.10.0.5 10.10.0.20

Caminar sobre el fuego por 10.10.0.5 (hacia 10.10.0.20) con un máximo de 25 saltos.

Inclinar arriba hopcounts al anfitrión obligatorio..

la tienta: 1 TTL: 1 puerto 33434: <response from> [10.10.0.4]

la tienta: 2 TTL: 2 puerto 33434: <response from> [10.10.0.6]

la tienta: 3 TTL: 3 puerto 33434: <response from> [10.10.0.8]

la tienta: 4 TTL: 4 puerto 33434: <response from> [10.10.0.10]

la tienta: 5 TTL: 5 puerto 33434: Salta escudriña: 5 saltos <Gateway at 5 hops> [10.10.0.10]

el puerto 135: abre

el puerto 136: *

el puerto 137: abre

el puerto 138: *

el puerto 139: abre

el puerto 140: *

Sin embargo, lo que vemos en nuestras pruebas es eso, algunos cortafuegos reconocen que el paquete expirará cuando ellos llegan a al anfitrión del objetivo antes de aplicar ACL las reglas. Y ellos sacan un ICMP TTL Expiró espalda de paquete al atacador y esto lleva a falso-positivo.

Para aprender más acerca de firewalk, usted puede verificar el URL www.es2.net/research/firewalk ============================================

En línea

Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  
Powered by SMF 1.1.16 | SMF © 2006-2008, Simple Machines