El rincón de Zerial » redes

Nueva infraestructura de red, torre triangular y antenas Yagi para el hacklab

Zerial — Wed, 21 Apr 2010 01:18:44 +0000

En el hacklab estamos remodelando la infraestructura de red, en simples palabras lo que buscamos es mejorar la disponibilidad de internet y de los recursos que queremos ofrecer. Para esto hemos pensado junto a xwall en armar una estructura donde poder poner un pc y un par de antenas.

El esquema de lo que tenemos en mente es el siguiente:

Podemos ver tres antenas sobr ela torre triangular, las identifiqué como “verde”, “roja” y “negra”. El color verde simboliza nuestra LAN y nuestra WLAN y la roja nuestra DMZ donde se encuentran nuestros servidores con nombres de personajes de los simpsons.
La idea principal de todo esto es tener dos redes separadas, nuestra WLAN y LAN que simplemente tenga acceso a internet y que nuestra DMZ tenga entrada y salida a internet, mediante una VPN, un tunel o como sea, la idea es dejar abierto los servidores al público y en algun momento (cuando armemos el proyecto) entregar accesos a shell para servicios de anonimato para quienes lo necesiten.

Violando sistemas: Sniffeando la red

Zerial — Thu, 01 Apr 2010 01:42:12 +0000

Cuando se logra vulnerar la seguridad de un sistema informático y obtenemos acceso al servidor tenemos varias formas de continuar el ataque, ya sea revisando los archivos del servidor buscando información interesante, controlar distintos servicios como el de base de datos o de correo, revisar la información de cada usuario de sistema, dejar una puerta trasera para volver a ingresar al servidor, etc. Una de las cosas que más me gustan es saltar a otros servidores, hacer un análisis de la red y poder tener control sobre la mayor cantidad de máquinas que forman la red, ya sean servidores físicos o virtuales.
El primer paso para armar un diagrama lógico de red es empezare a ver la configuración de la o las tarjetas de red, ver los últimos accesos que se han hecho en forma local o desde la lan, revisar logs, archivo de hosts y obviamente empezar a escanear usando nmap (obviamente de forma local) o alguna otra utilidad que tenga instalada o que podamos instalar. Si no tenemos nmap lo podemos hacer con un simple script en bash que haga ping a todo un rango y nos diga qué dirección está arriba:

#!/bin/bash
NETWORK=192.168.1
FROM=100
TO=110
for x in $(seq $FROM $TO)
do
	ping -c 1 $NETWORK.$x >/dev/null 2>&1
	if [ $? -eq 0 ]; then
		echo $NETWORK.$x is up.
	else
		echo $NETWORK.$x is down.
	fi
done

Una vez que tengamos el mapa mental-lógico de la red podemos empezar a analizar el tráfico que pasa por ellas y acá es donde entran en juego los famosos sniffers, que nos ayudarán a reforzar nuestro diagrama:

En informática, un packet sniffer es un programa de captura de las tramas de red.

Existen distintos métodos y herramientas para sniffear y para envenenar la red.

ettercap Ettercap es un interceptor/sniffer/registrador para LANs con switch. Soporta direcciones activas y pasivas de varios protocolos (incluso aquellos cifrados, como SSH y HTTPS). También hace posible la inyección de datos en una conexión establecida y filtrado al vuelo aun manteniendo la conexión sincronizada gracias a su poder para establecer un Ataque Man-in-the-middle(Spoofing). Muchos modos de sniffing fueron implementados para darnos un conjunto de herramientas poderoso y completo de sniffing.

tcpdump es un herramienta en línea de comandos cuya utilidad principal es analizar el tráfico que circula por la red. Permite al usuario capturar y mostrar a tiempo real los paquetes transmitidos y recibidos en la red a la cual el ordenador está conectado. Está escrito por Van Jacobson, Craig Leres, y Steven McCanne que trabajaban en … (más)

wireshark o ethereal La funcionalidad que provee es similar a la de tcpdump, pero añade una interfaz gráfica y muchas opciones de organización y filtrado de información. Así, permite ver todo el tráfico que pasa a través de una red (usualmente una red Ethernet, aunque es compatible con algunas otras) estableciendo la configuración en modo promiscuo. También incluye una versión basada en texto llamada tshark.

(nota: Las definiciones fueron obtenidas desde Wikipedia)

Luego de identificar qué máquinas nos interesan, podemos aplicar la técnica del hombre en el medio (Man In The Middle) o MiTM para capturar información para poder acceder a otros sistemas.

Link: Top 11 Packet Sniffers

Script para escanear la red en busca de servidores y servicios

Zerial — Wed, 10 Feb 2010 13:40:07 +0000

Hace un par de días tuve la necesidad de escanear 3 redes completas, mas de 50 direcciones ip, en busca de servicios que corrieran en ellas. Obviamente, no iba a ingresar a cada servidor y hacer un netstat o revisar uno por uno que servicios tenia instalado, si para eso existe nmap!
Lo que hicste fue separar los rangos de ip en archivos distintos, para tener un orden y escanear la red en orden según los segmentos y luego hice un script que leia cada archivo y escaneaba la ip en busca de servicios, la salida del nmap la parseaba y lo guarda en un archivo separado por comas. En un principio el script mostraba todo en el stdout pero para que quedara más ordenado, preferí hacerlo en un CSV para poder abrirlo con oocalc.
El script me genera un archivo con la siguiente información:

host, IP, Servicio, Puerto, Version

El script es el siguiente:

#!/bin/bash

nmap=/usr/bin/nmap
params="-sV"
tmp_file=/tmp/nmap_scanner_output
output=Servidores.csv
export SCANNER_ERROR=0

echo "host,IP,Servicio,Puerto,Version" >> $output
for ips in ips.*
do
	echo "Analizando $ips ..."
	for ip in $(cat $ips)
	do
		echo -e "\t-> $ip ..."
		ping -c 1 $ip 1>/dev/null 2>&1|| export SCANNER_ERROR=1
		if [ $SCANNER_ERROR = "1" ]; then
			echo -e "\t\t- Host no activo"
		fi
		if [ $SCANNER_ERROR = "0" ]; then
			$nmap $params $ip |grep -v "Starting Nmap" |grep -v "Nmap scan report" |grep -v "Host is up" |grep -v "Not shown" |grep -v "Service detection performed" |grep -v "Nmap done" > $tmp_file
			export _host=$(grep "Service Info" $tmp_file |sed 's/,//g'|grep "Host" |awk -F ' ' {'print $4'} |sed 's/;//g')
			grep tcp $tmp_file |scanner_ip=$ip awk -F " " '{print ENVIRON["_host"]","ENVIRON["scanner_ip"]","$3","$1","$4,$5,$6,$7,$8;}' >>$output
			echo -e "\n" >>$output
		fi
		export SCANNER_ERROR=0
	done
done

El script necesita para funcionar archivos con el listado de direcciones ip. Los (o el) archivo(s) se deben llamar “ips.“. En mi caso, tengo los siguientes archivos:
ips.192 ips.10 ips.172
Dentro de cada archivo hay direcciones del tipo 192.168.0.X, 10.0.0.X, 172.20.20.X…

$ sh scan.sh Analizando ips.10 ... -> 10.0.0.2 ... -> 10.0.0.3 ... -> 10.0.0.11 ... - Host no activo -> 10.0.0.20 ... - Host no activo -> 10.0.0.21 ... - Host no activo -> 10.0.0.70 ... -> 10.0.0.72 ... -> 10.0.0.73 ... Analizando ips.172 ... -> 172.20.20.2 ... -> 172.20.20.3 ... Analizando ips.192 ... -> 192.168.0.55 ... -> 192.168.0.101 ...

[...]

El script generará un output a un archivo llamado “Servidores.csv”, el cual lo podemos encontrar en la misma ruta donde tenemos el script.

SSH, Port Forwarding y Tunneling: Saltarse las restricciones del firewall

Zerial — Sat, 06 Feb 2010 19:59:04 +0000

En mi nuevo lugar de trabajo, misteriosamente está bloqueado por el firewall, entre otras cosas, la salida al puerto 25 de cualquier servidor. Desde mi portatil uso el cliente de correo Thunderbird conectandose a distintas cuentas de correo que tengo alojadas en Google Apps asi que no podía quedarme sin revisar mis cuentas de correo, por lo que tuve que buscar la forma de hacerlo.
Lo primero que se me vino a la cabeza es hacer un port forwarding con ssh usando un servidor externo, sabiendo que tengo el puerto 22 desbloqueado para salir. Entonces, accedería a cualquier servicio corriendo en el puerto 25 mediante un redireccionamiento a traves del puerto 22. Con esta técnica podemos saltarons el firewall y todas las restricciones.

El port forwarding, según el mismo manual de ssh, corresponde a:

Specifies that the given port on the local (client) host is to be
forwarded to the given host and port on the remote side. This
works by allocating a socket to listen to port on the local side,
optionally bound to the specified bind_address. Whenever a con-
nection is made to this port, the connection is forwarded over
the secure channel, and a connection is made to host port
hostport from the remote machine. Port forwardings can also be
specified in the configuration file. IPv6 addresses can be spec-
ified with an alternative syntax:
[bind_address/]port/host/hostport or by enclosing the address in
square brackets. Only the superuser can forward privileged
ports. By default, the local port is bound in accordance with
the GatewayPorts setting. However, an explicit bind_address may
be used to bind the connection to a specific address. The
bind_address of “localhost” indicates that the listening port
be bound for local use only, while an empty address or ‘*’ indi-
cates that the port should be available from all interfaces.

En simples palabras, lo que se hace, es habilitar un puerto local, por el cual se hara un redireccionamiento, a traves de ssh y el servidor remoto, hacia nuestro destino.

Paso a paso

Mapear la dirección de destino a nuestor localhost, en mi caso (y como ejemplo) usaré smtp.gmail.com. Debemos editar el /etc/hosts y agregar a la línea de 127.0.0.1 nuestro destino:
127.0.0.1 localhost.localdomain localhost smtp.gmail.com
Verificamos:
$ ping -c1 smtp.gmail.com PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.038 ms
Ahora, para nuestro sistema, el host smtp.gmail.com está apuntando a nuestra misma máquina.

Ahora, hacemos el port forwading usando el parámetro -L de la siguiente forma:
# ssh -L25:smtp.gmail.com:25 zerial@mydomain.org

Una véz logeados, ya va a estar hecho el redireccionamiento de puerto. Lo que hacemos con esa linea es decirle que todo el trafico desde localhost:25 lo lleve a traves de mydomain.org:22 a nuestro destino smtp.gmail.com:25.

Ahora realizamos la prueba, para ver si realmente tenemos salida a smtp.gmail.com:25:
$ telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mx.google.com ESMTP 42sm25383892vws.12

Listo. Obviamente, el Firewall no podrá bloquear el tráfico de localhost y tampoco el de ssh, ya que va cifrado.

Balancear la carga manualmente (definir mas de un gateway)

Zerial — Mon, 18 May 2009 00:47:55 +0000

La idea de balancear la carga manualmente es poder definir más de un gateway para distintos destinos, especificados por nosotros mismos. De esta manera, podremos tener dos o más salidas a internet y definir salidas hacia distintos rangos de direcciones ip.

Esto sirve de gran utilidad cuando nos conectamos a una red wifi que -por casualidad- llega hasta nuestro lugar de trabajo o nuestras casas e inocentemente queremos usarla. Por ejemplo, si tenemos un lugar de descargas, podemos dejar una máquina con una ruta estática que haga que cuando conecte a una IP x.x.x.x su salida a internet sea por el gateway predefinido por nosotros.
Para esto vamos a usar el comando route.

En este ejemplo, usaremos los destinos mi blog (este sitio), Google y Yahoo, para definir distintas salidas.
El primer paso consiste en identificar la dirección IP a la que queremos definir un gateway por defecto estático, batsa con que hagamos un ping al dominio de destino.

[zerial@daila ~]$ ping -c1 google.cl PING google.cl (216.239.59.104) 56(84) bytes of data. 64 bytes from gv-in-f104.google.com (216.239.59.104): icmp_seq=1 ttl=243 time=258 ms [zerial@daila ~]$ ping -c1 yahoo.es PING yahoo.es (217.146.186.221) 56(84) bytes of data. 64 bytes from rc1.vip.ird.yahoo.com (217.146.186.221): icmp_seq=1 ttl=53 time=251 ms [zerial@daila ~]$ ping -c1 blog.zerial.org PING blog.zerial.org (72.14.186.179) 56(84) bytes of data. 64 bytes from blog.zerial.org (72.14.186.179): icmp_seq=1 ttl=55 time=189 ms
Ya tenemos identificadas las tres direcciones IP de destino:

blog.zerial.org -> 72.14.186.179
google.cl -> 216.239.59.104
yahoo.es -> 217.146.186.221

En nuestra red local tenemos 3 gateways disponibles, por ejemplo los con la direccion ip 192.168.0.1, 192.168.0.2 y 192.168.0.3.
Haremos que para llegar a blog.zerial.org usemos el gateway 1, a google.cl el gateway 2 y a yahoo.es el gateway 3.
Ejecutamos las siguientes reglas:
[root@daila ~]# route add -host 72.14.186.179 gw 192.168.0.1 [root@daila ~]# route add -host 216.239.59.104 gw 192.168.0.2 [root@daila ~]# route add -host 217.146.186.221 gw 192.168.0.3

Podemos comprobarlo haciendo una traza (traceroute) a los distintos destinos, veremos que el primer salto es nuestro nuevo gateway.
[root@daila ~]# traceroute blog.zerial.org traceroute to blog.zerial.org (72.14.186.179), 30 hops max, 40 byte packets 1 192.168.0.1 (192.168.0.1) 1.582 ms 2.249 ms 3.687 m [root@daila ~]# traceroute blog.zerial.org traceroute to google.cl (216.239.59.104), 30 hops max, 40 byte packets 1 192.168.0.2 (192.168.0.2) 2.582 ms 2.256 ms 3.187 m [root@daila ~]# traceroute yahoo.es traceroute to yahoo.es (217.146.186.221), 30 hops max, 40 byte packets 1 192.168.0.3 (192.168.0.3) 1.555 ms 1.249 ms 3.688 m

Tambien podemos definir distintos gateways para distintos rangos de direcciones IP, para esto debemos cambiar el parametro -host < host> por -net < NET>.
Por ejemplo, ejecutamos el comando whois sobre la ip de zerial.org
[zerial@daila ~]$ whois 72.14.186.179 [...] NetRange: 72.14.176.0 - 72.14.191.255 CIDR: 72.14.176.0/20 [...]
Nos interesa lo que dice NetRange y CIDR, entonces ejecutamos:
[root@daila ~]# route add -net 72.14.176.0 gw 192.168.0.2
De esta forma, todas las salidas a las direcciones ip que incluye la red 72.14.176.0 serán despachadas por el gateway 192.168.0.2.

editado Haldrik escribió en su blog algo similar, que nos puede servir para balancear la carga entre dos lineas adsl. Recomiendo leerlo.