Configurando la red del Hackmeeting 2011 – MeigHacks

Este año me he ofrecido para configurar la red del hackmeeting. Para ello han usado 5 RB750 ofrecidas por Jose, ZUNbado y un par de mías.

Uno de los retos es conseguir una red a la que se puedan conectar un gran número de usuarios y que además, si alguien enchufa un servidor de DHCP (cosa que ha ocurrido en años anteriores) que no se quede toda la red del hackmeeting colgada.

El planteamiendo inicial fué crear varias subredes que operasen de forma independiente las unas de las otras y poder así fraccionar la red para cada una de las zonas.

Finalmente lo que se ha hecho ha sido poner 1 RB750GL como master y las otras RB750, RB750G y RB750GL como esclavas, enrutando con BGP un total de 16 subredes de 254 IPs cada una, 4 subredes por cada RB750.
En cada una de estas bocas se van a colgar switches o Access Points en modo bridge.

La comunicación entre la RB Master (a partir de ahora A-MASTER) y las RB Esclavas (B-SLAVE, C-SLAVE, D-SLAVE y E-SLAVE) se hace mediante 4 subredes del tipo 172.0.0.0/29. Inicialmente la idea era hacerlo con /30, pero curiosamente si usaba /30 no podía hacer el nat para asignarles una IP de gestión desde A-MASTER.
La gestión de las RB sólo se podrá realizar mediante túneles ssh desde la red de servidores.

Todas las peticiones a 0.0.0.0/0 finalmente se mandan a un servidor que hará de default gateway y se encargará de gestionar las conexiones, para optimizarlo, todas las peticiones al puerto 80 se hacen pasar por un proxy-http para optimizar las peticiones.

A continuación pongo algunas capturas y más detalles de dicha configuración, toda aportación a mejora será bienvenida, en dicha configuración no hay configurada la parte de logging pero no se descarta activarla una vez empiece el hackmeeting si se detectan distintos intentos de ataque para tal de identificar las máquinas atacantes y proceder a identificar a sus propietarios para que transformen sus ansias de destruir en ansias de mejorar la red y optimizarla.
No soy ninguna experta en este campo, estoy poniendo en práctica algunos de los conocimientos que he adquirido en los ultimos meses y toda ayuda será como siempre bienvenida :)

ESQUEMA SIMPLIFICADO DE LA RED MEIGHACKS
  +----------------+
  |  RB GUIFI.NET  |
  +----------------+
     |
  +----------------+
  | red servidores |
  +----------------+
     |
     + A-MASTER
     |
     +--- B-SLAVE
            + B-SLAVE-NET1
            + B-SLAVE-NET2
            + B-SLAVE-NET3
            + B-SLAVE-NET4
     +----- C-SLAVE
            + C-SLAVE-NET1
            + C-SLAVE-NET2
            + C-SLAVE-NET3
            + C-SLAVE-NET4
     +----- D-SLAVE
            + D-SLAVE-NET1
            + D-SLAVE-NET2
            + D-SLAVE-NET3
            + D-SLAVE-NET4
     +----- E-SLAVE
            + E-SLAVE-NET1
            + E-SLAVE-NET2
            + E-SLAVE-NET3
            + E-SLAVE-NET4

En esta captura vemos la configuración más significativa de A-MASTER, de izquierda a derecha y de arriba a abajo: Las interfaces, la configuración SNMP, las direcciones IP de cada interfaz (sólo las 172 que comunican con las RB SLAVE), los peer BGP hacia las RB SLAVE y el NAT para gestionar las RB SLAVE.

Captura de la E-SLAVE, ahora mismo con 1 Access Point (desde el que estoy escribiendo este post) en el puerto ether3. Al igual que en la captura anterior, Las interfaces, el rango de IPs que voy a servir por DHCP desde este router, algunos filtros de firewall, los leases de DHCP y el peer hacia A-MASTER (en ether1).

B-SLAVE, C-SLAVE, D-SLAVE y E-SLAVE, tienen la misma configuración y simplemente cambian las ips con las que nos conectamos a A-MASTER y las ips que servimos a los usuarios que se van a conectar a los access points o red cableada.

Entrando más en la configuración e E-SLAVE, empezamos por la configuración de los leases DHCP en cada una de las bocas.

Dicha captura no necesita demasiada explicación, routerOS aunque sea software privativo permite adentrarte al mundo de las redes con relativa facilidad :)
Destaco la parte del servidor de DNS, he puesto la IP del que va a ser el servidor que gestionará todas las conexiones, de esta forma nos olvidamos de problemas de caché de DNS que a veces da algun problema.

Aquí una pequeña chapuzilla, ya que en algún momento los paquetes no han hecho lo que realmente les decía ;)
Estas reglas son para que desde las IPs 10 no se pueda acceder a las IPs 172, que són única y exclusivamente para que hablen las RB y pasen los NAT para la gestión.

En el mangle, justo entran los paquetes en el firewall, los que correspondan a peticiones desde la red de IPs 10 a IPs 172, los marcamos con la etiqueta “tatequieto”, y luego en filter rules le indicamos que en el momento de hacer el forward, descarte todos los paquetes con la etiqueta “tatequieto”.
Además de esto (que esta era la primera regla y que en algunos casos no me hizo caso), que todas las peticiones de IPs 10, a IPs 172 que procedan de las interfaces eth2, eth3, eth4 y eth5 también los descarte.

Así que queda clarísima esta restricción ;) si alguien trata de hacer pings a estas IPs va a hacer subir el contador y de la misma forma que podemos marcar los paquetes, los podemos logguear!

En esta vemos todas las subredes con las que vamos a trabajar. La primera columna es la subred, la segunda a donde tenemos que ir para llegar a esta subred, la distancia, la ip local en el caso que la subred se encuentre en el mismo router y los AS Path BGP. Esto último en una red mucho más grande, podrías ver qué routers y con qué AS Path (numero identificativo único de BGP) tienes que pasar para llegar a la ruta. En este caso como mucho hay 2 saltos, pero es mucho más divertido cuando hay más y encima trabajas con redundancias :D

Destaco una ruta que es la 0.0.0.0/0, donde le digo que todas las peticiones que no sean de las redes indicadas las mande a 10.0.1.1, en otras palabras, el default gateway.

Los usuarios y por las redes permitidas que se permite acceder a la administración de la RB.

Hasta aquí más o menos la configuración de lo que es esta torre de cajitas blancas:

Ahora ya sólo queda la parte de configuración del server. No excesivamente complicada. El secreto es saber qué es lo que quieres hacer, como siempre ;)

La palabra clave es proxy transparente, tal como he comentado al principio y para ello instalaremos squid3 en la debian que ya tenemos instalada:

# apt-get install squid3

y modificamos el fichero de configuración y lo dejamos con estos parámetros:

http_port 3128 transparent
hosts_file /etc/hosts

acl manager proto cache_object
acl our_networks src 10.0.0.0/16
acl localnet src 127.0.0.1/32

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT


http_access allow our_networks
http_access allow localnet
http_access deny manager

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# And finally deny all other access to this proxy
http_access deny all

cache_dir ufs /var/spool/squid3 7000 16 256

En el hackmeeting vamos a usar conexión externa del lugar a la que nos encontramos, pero como tenemos el control de la red vamos a hacer llegar la conexión íntegra en la ubicación, pero si no fuese el caso y tenemos que estirar la conexión de otro proxy os recomiendo leer este otro post:

https://blackhold.nusepas.com/2009/12/squid-por-proxy/

El siguiente paso es configurar iptables para que automáticamente pase las conexiones, así los usuarios no tendrán que configurar el proxy y además no tendrán limitaciones con los otros puertos y servicios que no hayamos tenido en cuenta.

Para comodidad vamos a crear un script de configuración de iptables, así si queremos añadir alguna restricción, por ejemplo el P2P podríamos permitirlo desde el propio servidor. Aunque teniendo las RB750, también podemos hacerlo desde ahí ;)

# vi /root/scripts/iptables.sh

[iptables.sh]
#!/bin/sh
# squid server IP
SQUID_SERVER="10.0.1.1"
# Internet
INTERNET="eth1"
# Local LAN
LAN_IN="eth0"
# Squid port
SQUID_PORT="3128"

# Clean old firewall
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
# Load IPTABLES modules for NAT and IP conntrack support
modprobe ip_conntrack
modprobe ip_conntrack_ftp
# For win xp ftp client
#modprobe ip_nat_ftp
echo 1 > /proc/sys/net/ipv4/ip_forward
# Setting default filter policy
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
# Unlimited access to loop back
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow UDP, DNS and Passive FTP
iptables -A INPUT -i $INTERNET -m state --state ESTABLISHED,RELATED -j ACCEPT
# set this system as a router for Rest of LAN
iptables --table nat --append POSTROUTING --out-interface $INTERNET -j MASQUERADE
iptables --append FORWARD --in-interface $LAN_IN -j ACCEPT
# unlimited access to LAN
iptables -A INPUT -i $LAN_IN -j ACCEPT
iptables -A OUTPUT -o $LAN_IN -j ACCEPT
# DNAT port 80 request comming from LAN systems to squid 3128 ($SQUID_PORT) aka transparent proxy
iptables -t nat -A PREROUTING -i $LAN_IN -p tcp --dport 80 -j DNAT --to $SQUID_SERVER:$SQUID_PORT
# if it is same system
iptables -t nat -A PREROUTING -i $INTERNET -p tcp --dport 80 -j REDIRECT --to-port $SQUID_PORT
# DROP everything and Log it
iptables -A INPUT -j LOG
iptables -A INPUT -j DROP

Fuente: cyberciti.biz

Una vez hecho esto reiniciamos squid y ya podríamos navegar desde el Access Point conectado a una de las RB.

Ahora lo último que nos falta configurar es el dnsmasq, para que los usuarios de la red puedan resolver las DNS, para ello instalamos el paquete dnsmasq y copiamos el /etc/resolv.conf a /etc/resolv.dnsmasq.conf

# apt-get install dnsmasq
# cp /etc/resolv.conf /etc/resolv.dnsmasq.conf
# /etc/init.d/dnsmasq restart

Y hasta aquí tal como está montado este sistema, ahora sólo quedará instalarlo, ponerlo de nuevo en funcionamiento, añadir un par de juguetitos para monitorearlo (dude y snpservices de guifi modificado) y cruzar los dedos a que el sistema aguante toda la avalancha de hacktivistas que van a llenar por 11º año consecutivo este evento, el Hackmeeting.

Ficheros backup RBs

Foto finish: