Firewallking

• Presentación
• TCP: Que es?
• SYN-ACK
• Utilidades necesarias
  
• Configurando un Firewall
• Clases de FW
• FireWalking
• Despedida

En este texto vamos a analizar brevemente el protocolo TCP, vamos a analizar la configuración y el comportamiento de un FireWall, y por ultimo vamos a realizar la tecnica FireWallking descubierta por Mike D. Schiffman y David E. Goldsmit. Esta tecnica consiste en testear mediante paquetes TCP al firewall para comprobar su efectividad, tracear los hosts de la network y por ultimo localizar los filtros para poder realizar un esquema de la network completa.

Es un protocolo orientado a la conexión, básicamente es el encargado de permitirnos el acceso a un host remoto. Este protocolo, a diferencia de UDP, solo permite la comunicación cuando la conexión es establecida. Para realizar dicha conexión es necesario un inercambio de paquetes TCP, al que comunmente se le denomina three-way.

Pongo un ejemplo y no me extiendo más sobre el tema, confío en que quede claro:

Cita:

PC1 -> paquete SYN -> PC2 PC2 -> paquete SYN/ACK -> PC1 PC1 -> paquete ACK -> PC2 Conexión establecía!

Entonces, para establecer la conexión entre 2 hosts es necesario el envío y recepción de un paquete TCP SYN, un paquete TCP SYN/ACK y un paquete ACK,de otro modo la conexión quedará incompleta.

Las cabeceras de todos los paquetes TCP (excluyendo null-.-) contienen "flags" que se encargan de definir como debe ser tratado cada paquete.

Un SYN flag es una peticón de conexión, o bien su sincronización.

Un ACK flag es la respuesta a esta peticón de información.

Un paquete SYN/ACK es la respuesta a la petición SYN.

También existen paquetes nulos denominados NULL que carecen de ningún tipo de flag.

Los paquetes SYN reciben una respuesta ACK o en caso de denegación RST(reset) Los paquetes ACK reciben una respuesta RST (a no ser que esten precedidos por un SYN).

Los paquetes NULL reciben respuesta RST en caso de que el puerto esté cerrado de no ser así pasan y no son reciben respuesta. (En windows siempre reciben respuesta RST)

El administrador es el encargado de configurar el filtrado, para esto debe
establecer unas "reglas" de actuación determinadas.

Puede optar por comenzar con todos los puertos filtrados y abrir los que le
interesan o por el contrario filtrar solo los puertos abiertos que desea
proteger (en el segundo caso el administrador es idiota...).

En este caso el admin no es un inutil y filtra todos los puertos, luego
establece las siguientes reglas de actuación:

Para conexiones: externas (inet)
Con destino a: interno (lan..)
De protocolo: TCP
Puerto: 110
Procedimiento: Aceptar

Como vemos, todos los paquetes provinientes de cualquier dirección y destinados al pop3 serán aceptados.

Para conexiones: internas
Con destino a: externas
De protocolo: TCP
Puerto: 110
Procedimiento: Aceptar

En este caso todas las conexiones provinientes de la red local y datinadas a110 serán aceptadas.

Supongamos que no desee permitir el acceso al puerto 110 desde internet:

Para conexiones: externas
Con destino a: internas
De protocolo: TCP
Puerto: 110
Procedimiento: Rechazar

Todas las conexiones externas quedan rechazadas por lo que es muy pocoprobable que un huanker malvado le lea el e-mail xD

En conclusión, si se filtran todos los puertos y luego se establecen reglas de actuación seguras el sistema será de dificil acceso. Si por ejemplo el puerto 25 (smtp) queda configurado así:

Para conexiones: externas
Con destino a: internas
De protocolo: TCP
Puerto: 25
Procedimiento: Aceptar

por mucho que todos los demás puertos estén bloqueados a conexiones externas, al estar permitidas las conexiones internas toda la red sería vulnerable... por lo cual y solo en el caso de que consiguieramos "navegar" por la red desde dentro, nos habriamos saltado el firewall

Stateless: Este tipo de firewalls siplemente chequea el destino y la procedencia de las conexiones. Para esto solo lee el flag del paquete y decide que hacer con él.

Stateful: Este, a diferencia de su pariente, además de chequear el destino y la procedencia es capaz de seleccionar que paquetes pueden pasar analizando su objetivo.. es decir, si el paquete genera alguna amenza es filtrado. Si les interesa:

Google

DMZ: "DeMilitarized Zone, requiere un router/firewall con, por lo menos, tres interfaces de las cuales una es internet, otra para la red privada y la ultima para la red DMZ. Esto es utilo para servidores por ejemplo, si montamos un web-server en DMZ, evitamos la "inseguridad" que genera la red local... en otras palabras: será tan dificil cargarnos el webserver desde internet como desde la red :O

Se acabó la teoría, vamos a ver que nos dice el firewall! El objetivo es
analizar profundamente el wall y descubrir sus puntos debiles para así poder comprometer la network que se esconde detrás.

Empezamos con un simple ping a www.x.com:
__________________________________________________ ____
[root@localhost murder]# ping www.x.com
PING www.x.com (64.4.241.16) 56(84) bytes of data.

--- www.x.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2018ms
__________________________________________________ ____

Como vemos el host no responde pings... por lo tanto ya sabemos que hay algún sistema que ignora nuestros ICMP ECHO REQUEST (pings..)

Ahora vamos a ver si está filtrando algún puerto:

__________________________________________________ _____
[root@localhost murder]# hping2 www.x.com -S -p 85
HPING www.x.com (atm0 64.4.241.16): S set, 40 headers + 0 data bytes

--- www.x.com hping statistic ---
3 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
__________________________________________________ ____

Está claro: filtra puertos! ¿Pq? ... simplemente porque en caso de que el
puerto estubiera cerrado, este debería responder a nuestro SYN con un RST/ACK (RST= reset) de negativa.

El -S indica al hping que debe enviar SYN flags y -p es el puerto

Ahora veremos si el firewall es básico o no:
__________________________________________________ _____
[root@localhost murder]# hping2 www.x.com -A -p 85
HPING www.x.com (atm0 64.4.241.16): A set, 40 headers + 0 data bytes

--- www.x.com hping statistic ---
2 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
__________________________________________________ _____

Ha bloqueado nuestro ACK ping.. no tenemos suerte, un firewall basico solo
bloquea los intentos de conexión por lo que entendemos que este no es un
firewall básico.

*Un paquete ACK siempre debe recibir una respuesta RST, da = el puerto, si está abierto o cerrado.

Ya sabemos que el firewall está filtrando un puerto que no está en uso (no se para que sirve el 85 pero nunca jamás lo he visto en uso..). Lo que significa que todos los puertos cerrados están filtrados.. ¿pq iria el admin a filtrar un puerto cerrado y no los demás? (el admin no es inutil... la firewall no es básica... no pinta nada bien

Ahora comprobemos si el firewall está filtrando correctamente utilizando
paquetes fragmentados, un paquete fragmentado no es más que el original
separado en paquetes más pequeños que se re-agrupan al llegar al destino,
algunos firewalls al no poder leer el flag completo dejan pasar estos
paquetes.

__________________________________________________ _______
[root@localhost murder]# nmap -vv -sS -p85 -f www.x.com -P0

Starting nmap 3.55 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2004-08-10 02:09 CEST
Host www.paypal.com (64.4.241.16) appears to be up ... good.
Initiating SYN Stealth Scan against www.paypal.com (64.4.241.16) at 02:09
The SYN Stealth Scan took 37 seconds to scan 1 ports.
Interesting ports on www.paypal.com (64.4.241.16):
PORT STATE SERVICE
85/tcp filtered mit-ml-dev

Nmap run completed -- 1 IP address (1 host up) scanned in 36.700 seconds
__________________________________________________ _______

Utilizamos -sS para SYN scan, -p85 para el puerto, -f (fydors) para fragmentar y -P0 para no realizar pings al server. Podemos realizar el mismo scan-type pero con paquetes ACK (-sA)

Bien, no hemos conseguidor colar ni un paquete pero no desesperen, vamos a intentarlo ahora con paquetes nulos (los paquetes nulos son los que no contienen ningún tipo de flag). Un paquete nulo siempre que el puerto esté cerrado devolverá un RST, si está abierto lo dejará pasar... el problema es winbugs, winbugs siempre devuelve RST a los paquetes nulos, por lo que no debemos fiarnos. Para unix systems el null scan es muy util, sobre todo para los firewalls básicos. Con ACK sabemos si el firewall es básico y podremos saber exactamente que puertos filtrados están en verdad abiertos; ejemplo:

EDIT: He cambiado el host y su IP para evitar todo tipo de problemas

1º paso
__________________________________________________ _______
[root@localhost murder]# nmap -vv -sS -p23 www.firewallbasica.com -P0

Starting nmap 3.55 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2004-08-10 02:25 CEST
Host www.firewallbasica.com (192.168.3.3) appears to be up ... good.
Initiating SYN Stealth Scan against www.firewallbasica.com (192.168.0.3) at
02:25
The SYN Stealth Scan took 36 seconds to scan 1 ports.
Interesting ports on www.firewallbasica.com (192.168.0.3):
PORT STATE SERVICE
23/tcp filtered telnet

Nmap run completed -- 1 IP address (1 host up) scanned in 36.368 seconds
__________________________________________________ _______

2º paso

__________________________________________________ _______
[root@localhost murder]# nmap -vv -sA -p23 www.firewallbasica.com -P0

Starting nmap 3.55 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2004-08-10 02:27 CEST
Host www.firewallbasica.com (192.168.3.3) appears to be up ... good.
Initiating ACK Scan against hola.com diario de actualidad, moda y belleza (192.168.0.3) at 02:27
The 1 scanned port in www.firewallbasica.com (192.168.3.3) is:
UNfiltered

Nmap run completed -- 1 IP address (1 host up) scanned in 36.287 seconds
__________________________________________________ _______

3º paso

__________________________________________________ _______
[root@localhost murder]# nmap -vv -sN -p23 www.firewallbasica.com -P0

Starting nmap 3.55 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2004-08-10 02:25 CEST
Host www.firewallbasica.com (192.168.3.3) appears to be up ... good.
Initiating NULL Scan against www.firewallbasica.com (192.168.3.3) at 02:25
The NULL Stealth Scan took 36 seconds to scan 1 ports.
Interesting ports on www.firewallbasica.com (192.168.3.3):
PORT STATE SERVICE
23/tcp open telnet

Nmap run completed -- 1 IP address (1 host up) scanned in 36.368 seconds
__________________________________________________ _______

Ya sabemos que estamos tratando con un firewall de filtro básico, sabemos
exactamente que puertos tiene abiertos y que servicios está ofreciendo. De no ser así deberiamos probar con -f para intentar saber por lo menos que servicios está ofreciendo a la local network. Lo que nos falta saber es si el filtro está en algún lugar del webserver, cuantos filtros hay y donde estan localizados. Se puede decir que sabemos que obstaculos tenemos pero no sabemos donde están localizados ni cuantos son exactamente; procedamos:

Para localizar los filtros debemos realizar tacnicas de traceado, esto es
recorrer toda la red en busqueda del/los filtro/s. Para realizar esta labor
con más facilidad les propongo un par de pequeños scripts muy simples en bash:

__________________________________________________ ___
#!/bin/sh
# localiza el filtro ICMP

num=1
while [ $1 ] ; do
echo hop \#$num:
hping -1 -c 1 -t $cnt $1 #utilizamos la opción trace de hping
#la opcion -1 es ICMP protocol..
let num=num+1 #aumenta el nº de hop
sleep 1
done
__________________________________________________ ____


__________________________________________________ ____
#!/bin/sh
#localiza el filtro TCP
num=1
while [ $1 ] ; do
echo hop \#$num:
hping -S -p $2 -c 1 -t $num $1 #-S es SYN flag TCP paket
let num=num+1 #aumentamos el nº de hop
sleep 1
done
__________________________________________________ ____

Vamos a utilizar el primero, al que denominaremos ICMPtrace.sh:

__________________________________________________ ____
[root@localhost murder]# ./ICMPtrace.sh 192.168.0.3 23
hop #1:
HPING 192.168.0.3 (eth0 192.168.3.3): icmp mode set, 28 headers +
0 data bytes
TTL 0 during transit from ip=100.100.100.1 name=gateway.xxxxxxxxx.org
--- 192.168.0.3 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
hop #2:
HPING 192.168.3.3 (eth0 192.168.3.3): icmp mode set, 28 headers +
0 data bytes
TTL 0 during transit from ip=100.100.1.1 name=gateway.xxxxxxxxx.org
---192.168.0.3 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
....
hop #18:
HPING 1192.168.3.3 (eth0 192.168.3.3): icmp mode set, 28 headers +
0 data bytes
--- 1192.168.0.3 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
hop #19:
HPING 192.168.0.3 (eth0 192.168.0.3): icmp mode set, 28 headers +
0 data bytes
ICMP Packet filtered from ip=192.168.0.9 name=UNKNOWN
__________________________________________________ ____

Ya vemos... el filtro de ICMP no se encuentra en el webserver, se encuentra en el gateway hop 19 con ip 192.168.0.9. Ahora vamos con TCP... a ver con que nos encontramos:

__________________________________________________ ____
[root@localhost murder]# ./trace_tcp.sh 192.168.3.3 23
hop #1:
HPING 192.168.0.3 (eth0 192.168.3.3): S set, 40 headers + 0 data
bytes
TTL 0 during transit from ip=100.100.100.1
--- 192.168.0.9 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
....
....
....
....
hop #21:
HPING 192.168.3.3 (eth0 192.168.3.3): S set, 40 headers + 0 data
bytes
len=46 ip=192.168.0.12 flags=SA DF seq=0 ttl=63 id=0 win=5840 rtt=575.6
ms

Bien, ya sabemos que el webserver está en el hop 21.. y sabemos que el hop 19 está filtrando paquetes ICPM.

Ahora vamos a ver si hay otro hop filtrando paquetes:

__________________________________________________ _____
[root@localhost murder]# hping2 -A -p 85 -c 1 -t 19 www.firewallbasica.org
HPING www.firewallbasica.org (eth0 192.168.3.3): A set, 40 headers + 0
data bytes
TTL 0 during transit from ip=192.168.0.1 name=UNKNOWN
--- www.firewallbasica.org hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
__________________________________________________ _____

No, puerto unreachable, por lo menos el puerto 85 no está filtrado en la mismo direccion que el de ICMP... Como vemos ahora el filtro puede estar en el webserver o detras de él... comprobémoslo:

__________________________________________________ _____
[root@localhost murder]# hping2 -A -p 85 -c 1 -t 20 www.firewallbasica.org
HPING www.firewallbasica.org (eth0 192.168.3.3): A set, 40 headers + 0
data bytes
--- www.firewallbasica.org hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
__________________________________________________ _____

Ok, esta detrás del webserver... veamos que dirección tiene:

__________________________________________________ _____
[root@localhost murder]# hping2 -S -p 80 -c 1 -t 20 www.www.firewallbasica.org
HPING www.firewallbasica.org (eth0 192.168.3.3): S set, 40 headers + 0
data bytes
TTL 0 during transit from ip=192.168.0.1 name=UNKNOWN
--- www.firewallbasica.org hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
__________________________________________________ ______

Mmmmm ok está en el 192.168.0.1 )
Ahora sabemos que nuestro server está detrás de un gateway que hace de firewall para la subred... graficamente así queda más claro:

192.168.3.3
|
192.169.0.1
|
INTERNET

Vamos a usar un poco la astusia.. intentemos localizar el smtp server... quizas esté detrás del wall y tengamos suerte ^^

__________________________________________________ ____
[root@localhost murder]# host -t mx www.firewallbasica.org
www.firewallbasica.org mail is handled by 50 smtp.isp.com
www.firewallbasica.org mail is handled by 10 smtp-in.sc5.xx.com
__________________________________________________ ____

Bien, ahora sabemos que tiene dos smtps, vamos donde se encuentran..
(La opción mx es para localizar smtp servers)

__________________________________________________ ____
[root@localhost murder]# host smtp-in.sc5.xx.com
www.firewallbasica.com has address 192.168.3.5
__________________________________________________ ____

Perfecto, se encuentra en la red privada! Veamos el siguiente:

__________________________________________________ ____
[root@localhost murder]# host smtp.isp.com
www.firewallbasica.com has address 192.168.0.2
__________________________________________________ ____

Este parece ser externo... no se encuentra en el mismo rango, se encuentra
en el rango del firewall.

Actualicemos el esquema:

192.168.3.3 192.169.3.5
|________ _______|
|
___________________
192.169.0.1 192.169.0.2
|
INTERNET

Además de este magnifico esquema de la red tenemos dos huecos, el puerto 80 y el 25, seguimos escaneando puertos, localizando filtros, otros servidores.. etc )

Bueno, eso es todo... espero que les haya gustado, resultado util, interesado, repugnado, lo que sea.. en fín si quereis saber más del tema podeis leer el magnifico manual hacking_unix_2 (ingles). En google no hay mucha info sobre el tema, tambien podeis descargar el soft Firewalk creado para facilitar la labor... personalmente lo veo una lamerada así que ni me molesto en buscaros el link )))

Salu2!


Tutorial de Murder