junio 12, 2013

Firewall III

Last Update Feb 04/2015
En las entregas anteriores Firewall y Firewall II, explicamos cómo implementar un proxy transparente usando el firewall iptables de Linux y Squid, y aplicar una serie de políticas restrictivas para impedir que programas como Tor, Ultrasurf, Torrent y los túneles VPN salten las protecciones de nuestro Proxy y naveguen sin ningún control.
También se ofrecieron ACLs que contenían rangos de Ips de diferentes sitios (Google, Yahoo, Microsoft, etc), que se pueden usar ya sea para denegar o autorizar sitios, los cuales facilitan la labor del Administrador TI.
Sin embargo ninguna política descrita anteriormente impide que un intruso, con ciertos conocimientos, se haga con nuestra clave de red wifi o tenga acceso físico a un terminal de nuestra Lan y ejecute un scanner de red (Angry Ip Scanner, arp ping, etc) y logre obtener todas las Macs de los equipos autorizados de la Lan y clone alguna para hacer uso de los recursos de la red de datos o lanzar un túnel vpn para establecer contacto remoto con su propio servidor y comprometer la seguridad del entorno.
Este es uno de los problemas más graves que enfrentan las redes locales actuales, como cibercafes internet, universidades, empresas, bancos, etc, sobre todo aquellas que tienen puntos de acceso WiFi, abiertas o no; el robo de direcciones mac.
Como bien lo define Wikipedia, estas direcciones son únicas en cada dispositivo de red y no en cada computador (como muchos creen), ya que a un PC se le pueden conectar X cantidad de tarjetas de red, ya sea en su interior o via usb, aplicable también a tablets, smarthphones y otros dispositivos de comunicaciones. Sin embargo el hecho de que sean únicas no significa que no se puedan alterar y es por eso que se presenta este mal que tanto daño causa.
Existe una infinidad de aplicaciones, que en dos o tres pasos nos permiten alterar la mac de un adaptador de red. Incluso los sistemas operativos actuales permiten hacer esto. Las distribuciones de seguridad Wifiway, Wifislax, Kali, y otras, traen aplicaciones capaces de detectar y falsear el identificador de una tarjeta de red y luego navegar con nuestros recursos, ya sea normalmente o conectado a una VPN.
Y en el mejor de los casos, el usuario no autorizado nos monta un Fake AP (Rogue AP) y revende nuestra señal o la usa para fines más lucrativos, como robar información financiera y venderla en el mercado negro, o simplemente reventar nuestra red por mera diversión o prestigio.
La mayoría de arquitecturas y firewalls que se implementan en estas redes, son susceptibles a este tipo de ataques, sobre todo en las redes WIFI, que ya no es necesario estar físicamente conectado a la red mediante un cable ethernet para escanearla y determinar todas las ips con sus respectivas macs.
QUÉ SUCEDE CUANDO UNA MAC ES CLONADA?
Cuando dos PCs (o tablets, smarthphones, AP, etc) tienen la misma dirección mac, eventualmente uno de los dos podrá acceder a internet y a los recursos de la red local (no pueden acceder ambos al mismo tiempo) y las peticiones que hagan a internet puede llegar a cualquiera de los terminales clonados indistintamente; o sea si un PC se conecta a Gmail y el otro a Hotmail, eventualmente ambos pueden recibir la misma información, o no recibir nada.
Obviamente esto genera cuellos de botella en la red y mal funcionamiento, ya que el proxy o router puede descartar paquetes o generar un exceso de reenvío, afectando directamente el ancho de banda de la red local. 
CÓMO SABER SI UNA MAC HA SIDO CLONADA?
Lanzando un ARP ping a la IP sospechosa y si arroja más de una respuesta o hay diferencias entre una respuesta y otra, entonces se repite el proceso, pero esta vez con el equipo que tiene la mac clonada desconectado de la red local. Si se obtiene respuesta, definitivamente ha sido clonada. 
Hay que aclarar que no es un método 100% garantizado, ya que si hay problemas internos con la red local o los paquetes ICMP u otros están bloqueados a nivel de proxy o router, puede que no haya respuesta.
EXISTE ALGUNA MANERA DE EVITARLO?
Cómo dicen en un foro: ¿Existe alguna manera de evitar que algunos conductores manejen borrachos por las carreteras?.. No, pero no hacer nada y esperar que se estrellen, para que aprendan la lección, es un error, ya que lo más seguro es que se lleven por delante a muchos inocentes en el proceso. Lo mismo sucede con la seguridad de una red local. Nada puede evitar que un atacante pueda hacerse con las credenciales de nuestra Lan, corra un escáner sigiloso, obtenga todas las direcciones macs y clone algunas de ellas, ya que no tenemos control sobre el equipo del atacante, pero sí tenemos control sobre nuestra red local, y se pueden tomar algunas contramedidas para mitigar el problema. Pero es necesario aclarar que, al igual que sucede con el conductor borracho, no siempre las medidas que se toman están exentas de daños colaterales.
Pero primero analicemos algunas propuestas hechas en los diferentes foros, desde las más simples hasta las avanzadas, con sus ventajas y desventajas.
1. Crear una tabla con las direcciones mac autorizadas en el router o servidor proxy y ponerles una ip a cada mac
Esta medida es buena y es un primer paso al filtrado interno de la red local, pero no aplica en redes abiertas y tampoco evita que un atacante escanee la red y se haga con el juego Mac+IP, clone una Mac y le ponga una IP manual, diferente a la que tiene asignada la original, para evitar la colisión y las alertas de "ip duplicada en la red".
Además, es necesario insistir que las direcciones IP trabajan en la Capa 3 del Modelo OSI y las direcciones MAC son identificadores de acceso al medio físico (adaptador de red) que trabajan en la capa 2 OSI, y normalmente se usan para direccionar paquetes dentro de la red Lan (broadcast), por tanto, operan en niveles diferentes y no se relacionan entre sí de forma directa y esto conlleva a que se pueda tener en una red local, dos equipos con la misma dirección mac, pero con una misma ip diferente.
2. Desactivar el servidor DHCP y poner las IPs manualmente; ocultar el SSID; establecer el/los rango/s de IP/s que se van a usar, reduciendo el pool de direcciones y bloquear el resto
Funcional bien si tu red local es cerrada y tiene pocos equipos, pero de igual manera el atacante puede escanear la red y determinar el rango de IPs autorizadas y colocar la IP manual. Además, muchos escáneres de red detectan el tráfico de los AP, incluso si el punto de acceso está "escondido" (SSID oculto).
Se imaginan a un Administrador IT poniendo direcciones manuales en una red pública y mixta (con clientes dinámicos y estáticos), con más de 1000 terminales, muchos de ellos smarthphones, tablets, etc. Una auténtica locura.
Además, hay que tener en cuenta el tipo de enrutamiento de la red local, desde y hacia el servidor o router. Lea el post Enrutamiento en Linux
3. Usar un servidor DNS propio
Evita en parte el problema, pero el atacante puede colocar DNS manuales de su conveniencia y conectarse a una VPN propia para navegar.
Se recomienda leer el post Tres tipos de ataques DNS y cómo lidiar con ellos. También puede usar la herramienta DNSSec-Check para diagnosticar su servidor DNS.
4. Usar un Servidor controlador de Dominio de Active Directory
Obsoleto. Una tecnología exclusiva de Microsoft que tiene más de 20 años. Se puede implementar en linux pero es muy engorroso. No obstante para los nostálgicos, pueden leer el manual de instalación, aunque en la actualidad existen mejores y más versátiles soluciones.
5. Usar un Portal Cautivo (hotspot) con redirección a una web interna y credenciales de validación (Servidor Radius)
Está de moda, pero no es tan seguro como creemos. Recomendamos la lectura del post Sobre Wifi, Robar y los portales cautivos
6. Cambiar los puertos por defecto del servidor, AP o router, ponerlos en modo "stealth"; y crear un honeypot 
Es una solución más avanzada, pero tampoco garantiza nada. Con respecto a la implementación de un honeypot, siempre que sea una solución local y no un escudo de red, puede disuadir bastante al atacante, ya que crea una serie de servicios inexistentes ideales para distraer al más concentrado atacante. Y si le agregamos una jaula Chroot, puede sumarle más distracción. Recomendamos las herramientas honeypot de distro LiveCD HoneyDrive
7. Usar una VPN y encriptar el tráfico de la red local
Muy buena elección, pero más costosa, ya se aplica a nivel de servidor y no se justifica en redes locales pequeñas. Implementar una VPN con cifrado de datos eleva mucho el nivel de seguridad, y esta sería aún mayor si en lugar de una VPN implementáramos una Nube Virtual Segura SVC, sin embargo estos esquemas son mayormente corporativos y no aplican para redes Lan pequeñas.
La lista de propuestas de los diferentes foros y portales especializados en seguridad informática es realmente extensa, muchas de estas "soluciones" concentradas en grandes redes de datos, y otras, más sencillas, orientadas al mundo de los cibercafes internet, escuelas, redes públicas.
Como el esquema en cada caso no es el mismo, y es difícil encontrar una regla de oro para todos los casos, estos portales solo se limitan a dar pautas para contrarrestar intrusiones no deseadas, pero para casos específicos.
Nuestro post tampoco les ofrecerá una solución "mágica", ya que no existe. Las intrusiones evolucionan todos los días y con ellas la seguridad informática. Es por esta razón que la panacea de hoy es el hazme reír del mañana, por tanto nos enfocaremos en una parte esencial de la seguridad de cualquier red: la protección del tráfico in/out.
ESNIFANDO NUESTRA RED
Lo primero que hay que hacer es escanear nuestra red local. Esto debe ser una tarea constante para cualquier administrador TI, usando las mismas herramientas exploratorias que utilizaría cualquier usurpador.
Existen herramientas muy versátiles que hacen este trabajo, como Wireshark o Ettercap (Véalos en acción en Ataque MITM), pero en esta ocasión lo haremos a la antigua (por consola) y usaremos Nmap y nast, que son perfectas para el trabajo.
Y como dice Oscar Wide "La mejor manera de librarse de una tentación es caer en ella", ejecuten en el terminal lo siguiente y verán los resultados:
# Instalamos nmap y nast
sudo apt-get install nmap nast
# Escaneamos la red local con el protocolo arp
sudo nast -m
# Determinar el gateway (con Yep! ya lo tenemos)
sudo nast -g
# si tienen varias interfaces en su PC, elijan una. Ej: wlan1
sudo nast -m -i wlan1
# Escaneo preliminar del target ej 192.168.1.1
sudo nast -S
Nast V. 0.2.0
Port Scanner extremes
Insert IP to scan   : 192.168.1.1
Insert Port range   : 1-65535
# Pero si quieres algo rápido y potente
sudo nmap -sS -PN -T5 -p 1-65535 192.168.1.10
# y al estilo triniti
sudo nmap -sS -O -v 192.168.1.10
Nota: Para más opciones de nmap, lea su cheatsheet. Consulte Nmap Warning, para establecer la restransmisión (T5, T4, T3, etc) y evitar mensaje como "nmap warning: giving up on port because retransmission cap hit (2)". 
Con esto ya establecemos las mac+ip asignadas en nuestra Lan, si hay alguna mac clonada con diferente ip (algo que hacen los atacantes para ocultar el llamativo mensaje de Windows "conflicto de ip") y de paso establecemos los puertos desprotegidos, gateway, etc, etc. Esta información es la misma que obtendría un atacante; y si bien es difícil ocultarla, es la primera que tenemos que proteger.
AMARRAR MAC+IP CON DHCP+IPTABLES+SQUID
Muchos dirán que este tipo de solución tiene vulnerabilidades, ya expuestas en el Punto No 1 de este post; y es cierto. El servidor ISC DHCP utiliza un Socket Internet de protocolo Raw en lugar de TCP o UDP, lo cual es una limitación para poder bloquear sus peticiones en el IPtables.
Además, existen muchos ataques que involucran al servidor DHCP. Explicarlos todos (DHCP ACK Injection Attack, IP Spoofing Attacks, Discover DoS attacks, etc) y sus defensas (DHCP Snooping) podría tomarnos varios post. Es por eso que si quiere profundizar en la protección de su servidor DHCP y evitar ataques Man-in-the-Middle puede consultar el post Defensas frente a ataques DHCP  Bloqueo de servidores DHCP Falsos
En resumen, DHCP literalmente hace lo que se le da la gana, y no respeta las reglas de IPtables, como las propuestas por este tutorial de Iptables
$IPTABLES -t filter -A INPUT -p udp --sport 68 --dport 67 -j DROP
o
$IPTABLES -A INPUT -i LAN_IFACE -p udp --sport 67:68 --dport 67:68 -j ACCEPT
o
$IPTABLES  -I INPUT -i $LAN_IFACE -p udp --dport 67:68 --sport \
     67:68 -j ACCEPT  
Sin embargo podemos aprovechar algunas de sus virtudes para establecer un nivel de protección, que por sí solo no es efectivo, pero si los parámetros establecidos previamente en el servidor DHCP son validados por el IPtables y el Squid, entonces estamos hablando de una protección decente en la entrada/salida de nuestra red local. 
Combinar un triple filtrado mac+IP en la entrada/salida de nuestra red local es un gran paso en la seguridad, sin importar su clasificación, categoría, esquema, protocolos, cifrado, etc.
Desafortunadamente estas técnicas (no todas) solo se admiten en los routers más costosos. Es por eso que recomendamos usar un servidor proxy basado en Linux,  que es mucho más económico y configurable que un router físico.
Para lograrlo podemos utilizar varias herramientas muy conocidas, como son DHCP Server, Squid3 e IPtables y reforzamos el perímetro con Fail2ban, ARPon y script Anti-DDos (DDoS Deflate) y de ser posible con un proxy inverso.
Nota: Las defensas perimetrales como IDS/IPS (Snort), sistemas UTMs (Unified Threat Management) y MFA (Multi Functional Appliances), o WAF las explicaremos en otras entregas de la serie Firewall
Adicionalmente instalaremos los programas de monitoreo Sarg, Sqstat e IPtraf; y para un análisis global de nuestra red local y detectar las vulnerabilidades, podemos implementar Nessus (opcional) (Vea el post Network Monitor)
No se asusten si se mencionan demasiadas herramientas. Muchas de ellas trabajan automáticamente y las configuraciones son tan solo un par de líneas; y para el caso de IPtables, si consideran difícil manipularlo, puede echar mano de algún frontend disponible.
PASOS
Primero que todo debe configurar su Firewall IPtables de manera segura. Cada Firewall se construye de acuerdo a las necesidades de cada red, por tanto si es demasiado permisivo, estos controles no serán suficientes. En este orden de ideas, para que diseñe un Firewall seguro, acorde a sus necesidades, recomendamos en primera instancia la lectura de los artículos Configuración segura de Iptables, Detección, control y contención de tráfico innecesario con Iptables  , Iptables like a pro, y nuestra serie Firewall (I, II, III, IV), así como conocer en detalles los comandos del Iptables
Una vez configurado el script de Iptables, y el servidor DHCP instalado y corriendo en su servidor, ahora pasaremos a colocar la primera capa de reglas de filtrado Mac+IP en el archivo de configuración de DHCP.
Nota:
a. Nos parámetros propuestos, rangos de red, leases, dns, mac + ip, etc, son a modo de ejemplo. Puede modificarlos de acuerdo a sus necesidades.
b. Jamás elijan la primera dirección IP (.01) para asignarla al servidor proxy, ya que los AP, Routers, etc, casi siempre traen por defecto esta dirección y si se la cambiemos, pero por alguna causa externa (voltaje, hackeo, etc) se desconfiguran, estos, una vez reinicien, automáticamente se reconfigurarán con los valores de fábrica, el cual incluye la IP terminada en 01, creando una colisión con nuestro servidor proxy.
1. DHCP
Aquí se establece en el archivo de configuración del servidor DHCP una IP por cada Host y Mac de nuestra Lan. El procedimiento es sencillo. Asumiendo que tiene instalado DHCP (Tutorial), acceda a su archivo de configuración
Configuración de red
# solo para dhcp v4.x. Las versiones anteriores a 4.x no tienen este archivo
sudo nano /etc/default/isc-dhcp-server

# Defaults for dhcp initscript
# sourced by /etc/init.d/dhcp
# installed at /etc/default/isc-dhcp-server by the maintainer scripts
#
# This is a POSIX shell fragment
#
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".

# Poner el nombre de la tarjeta de red que usará para el dhcp.
# Para determinarlo, ejecute en el terminal ifconfig o ipconfig (en dependencia de su SO). 
# Como ejemplo usaremos una tarjeta wifi.
INTERFACES="wlan3"
Configuracion del archivo dhcp.conf
# en dependencia de su versión de dhcp
sudo nano /etc/dhcp3/dhcpd.conf # para dhcpd v3.x
# o
sudo nano /etc/dhcp/dhcpd.conf # para dhcpd v4.x
Parametrizando dhcpd.conf
# Establezca la autoridad de su servidor dhcp, descomentando authoritative
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Determine sus usuarios
host CLIENTE1 {
  hardware ethernet e0:ca:94:a7:xx:xx;
  fixed-address 192.168.1.100;
}
host CLIENTE2 {
  hardware ethernet 00:14:d1:d5:xx:xx;
  fixed-address 192.168.1.101;
}

# Bloquer macs no autorizadas, que roban ips asignadas por DHCP
class "macs-block" {
         match pick-first-value (option dhcp-client-identifier, hardware);
  }
  subclass "macs-block" 1:cc:af:78:a3:xx:xx;
  subclass "macs-block" 1:54:26:96:96:xx:xx;
  subclass "macs-block" 1:cc:55:ad:02:xx:xx;

# Configurando los parámetros generales de su red local en el DHCP
subnet 192.168.1.0 netmask 255.255.255.0 {
 option domain-name-servers 8.8.8.8 , 8.8.4.4;
# Nunca elijan la IP 1 para evitar autoataque por desconfiguracion de un AP
        option routers 192.168.1.10;
 option broadcast-address 192.168.1.255;
        #option domain-name "tu.server.public";
 default-lease-time 600;
        max-lease-time 7200;
  pool {
                deny members of "macs-block" ;
                range 192.168.1.160 192.168.1.199;
                }
}
Y guardamos el archivo de configuración y reiniciamos el servidor DHCP
sudo service dhcp3-server restart
o
sudo service isc-dhcp-server restart
Con esta configuración propuesta para el servidor DHCP evitamos tener que asignar IPs fijas (manuales) a cada terminal de nuestra red, y de paso nos quitamos de encima una tediosa y casi imposible tarea. El DHCP hace este trabajo por nosotros y de paso quedan amarrados Mac+IP en un nivel.
También bloqueamos las macs que no pertenecen a nuestra red local, para que no ocupen direcciones ips que ofrece el servidor DHCP. En el Webmin, en la sección "arrendamientos DHCP, marcamos las casillas de las macs indeseadas y pulsamos "Haz click en una dirección IP de arrendamiento de la lista superior para borrarla" y el servidor DHCP liberará la IP. También puede eliminarlas del archivo dhcpd.leases (donde también se puede obtener la información mac+IP del DHCP para luego ponerla en dhcpd.conf)
/var/lib/dhcp/dhcpd.leases
Nota:
a. No declaren el rango (range) DHCP dos veces en el archivo de configuración ya que genera error.
b. El amarre real se produce entre mac+ip, ya que a pesar de que se asigna un nombre de host en el DHCP, este no garantiza que pueda ser cambiado arbitrariamente.
Diferencias de configuración DHCP en Webmin
En las recientes versiones de DHCPd, en especial para Ubuntu 12.04 o superior, dhcp3-server (v3x) ya no se usa, y en su reemplazo llegó isc-dhcp-server (v4x). Las configuraciones en ambos son diferentes, y por supuesto también en el Webmin. Por lo anterior se recomienda encarecidamente que purgue cualquier configuración anterior de dhcp (dhcp3-server o isc-dhcp-server), y que instale el dhcpd directamente del administrador Webmin, PERO ANTES DE INSTARLO (ojo) primero modifique el módulo de dhcp en webmin, reemplazando dhcp3 por isc-dhcp-server, para que quede con los parámetros necesarios, ya que pueden presentarse conflictos en los archivos de configuración.
Vea los siguientes ejemplos de las configuraciones de Webmin dhcp3-server vs isc-dhcp-server, para Ubuntu 10.04.03, Ubuntu 12.04.02 y Debian 7x
Ruta al archivo de configuracion DHCP de Webmin
sudo nano /etc/webmin/dhcpd/conf
Configuración del servidor DHCPd versión 3.1.3 de ISC (dhcp3-server) para Ubuntu 10.04.03 (descontinuada)
lease_file=/var/lib/dhcp3/dhcpd.leases
display_max=100
lease_tz=0
interfaces_type=debian
show_mac=0
stop_cmd=/etc/init.d/dhcp3-server stop
dhcpd_conf=/etc/dhcp3/dhcpd.conf
pid_file=/var/run/dhcp3-server/dhcpd.pid
restart_cmd=/etc/init.d/dhcp3-server restart
desc_name=0
dhcpd_nocols=5
dhcpd_path=/usr/sbin/dhcpd3
start_cmd=/etc/init.d/dhcp3-server start
dhcpd_version=3.1.3
dhcpd_size=642480
group_name=0
lease_sort=0
show_ip=0
dhcpd_mtime=1369359529
Configuración del servidor dhcp3 DHCPd versión 4.1 de ISC para Ubuntu 12.04.02 LTS (isc-dhcp-server). Presenta problemas con Stop/Restart en Webmin.
lease_file=/var/lib/dhcp/dhcpd.leases
display_max=100
lease_tz=0
interfaces_type=debian
show_mac=0
stop_cmd=service isc-dhcp-server stop
dhcpd_conf=/etc/dhcp/dhcpd.conf
pid_file=/var/run/isc-dhcp-server/dhcpd.pid
interfaces=wlan3
restart_cmd=service isc-dhcp-server restart
desc_name=0
dhcpd_nocols=5
dhcpd_version=4.1
dhcpd_path=/usr/sbin/dhcpd
start_cmd=service isc-dhcp-server start
dhcpd_size=787816
group_name=0
lease_sort=0
show_ip=0
dhcpd_mtime=1378284459
add_file=
lease_refresh=
hostnet_list=
version=
Para solucionar el problema del Webmin, antes de instalar isc-dhcp-server desde webmin o desde el terminal, ingrese a "Configuración de Módulo", y reemplace dhcp3 por isc-dhcp-server, o entre directamente al archivo de configuración de Webmin y coloque los parámetros de la siguiente manera.
lease_file=/var/lib/dhcp/dhcpd.leases
display_max=100
lease_tz=0
interfaces_type=debian
show_mac=0
stop_cmd=/etc/init.d/isc-dhcp-server stop
dhcpd_conf=/etc/dhcp/dhcpd.conf
pid_file=/var/run/dhcp-server/dhcpd.pid
interfaces=wlan3
restart_cmd=/etc/init.d/isc-dhcp-server restart
desc_name=0
dhcpd_nocols=5
dhcpd_version=4.1
dhcpd_path=/usr/sbin/dhcpd
start_cmd=/etc/init.d/isc-dhcp-server start
dhcpd_size=787816
group_name=0
lease_sort=0
show_ip=0
dhcpd_mtime=1378284459
add_file=
lease_refresh=
hostnet_list=
version=
Para configurarlos en Debian 7x consulte Configurar Webmin para isc-dhcp-server (4.x). Por lo anterior se recomienda tener la última versión de DHCP instalada.
2. SCRIPT IPTABLES
Nada de lo anterior es suficiente para completar el "amarre" ip+mac, y las subclass del DHCP lo único que hacen es impedir que el DHCP le asigne más direcciones IP a estas macs bloqueadas. El bloqueo real se produce en Iptables.
En este orden de ideas, el próximo paso (tal y como lo explicamos en el post Firewall), es definir cuales direcciones mac accederán a nuestra red local, para evitar que si el atacante logra burlar la seguridad del punto WiFi, no llegará más lejos.
A continuación, el IPTables, va a leer las macs asociadas a las ips, previamente escritas en el dhcpd.conf, y creará dos ACLs, una con el nombre de macs_dhcp (donde pondrá todas las macs en orden) y otra llamada ips_dhcp (donde hará lo mismo con las ips).
Lo siguiente que hará la regla es autorizar solamente a estas macs con sus respectivas ips a pasar por el firewall y accesar a la red local y sus recursos. Aquellas que no coincidan serán rechazadas.
Filtrado MAC+IP por IPtables
#---------------------------------------------------------
#     FRAGMENTO DE IPTABLES SCRIPT BY MARAVENTO STUDIO
#                   v1.0 Mar 17/2014                                                
# Written by: 
#     Alej Calero  administrador@maravento.com
#     Jhonathan Sneider sneider2002@gmail.com
#                        
# Special Thanks to:
#     Ruslan Abuzant ruslan@abuzant.com
#     Pello Xabier Altadill Izura pello@pello.info
#     Suzdal http://www.hacktimes.com/author/suzdal
#     Oskar Andreasson blueflux@koffein.net
#     Koratsuki http://blog.desdelinux.net/
#     Vincent Renardias http://www.linuxfocus.org/
#                            
# Licencia Creative Commons Atribución-Compartir 
# http://www.netfilter.org/documentation/
# Ejecute: chmod +x /etc/init.d/iptables.sh
# Verifique con: iptables -L -n
# ------------------------------------------------------

##################
# FIREWALL RULES #
##################

echo IPTABLES FIREWALL START...
adminMAC="48:5a:b6:55:xx:xx"
internet=eth0
lan=eth1
local=192.168.1.0
iptables=/sbin/iptables
route=/etc/acl
proxyport=8080
netmask=255.255.255.0

###############
# FLUSH RULES #
###############

echo Apply Flush Rules...

# Delete all
$iptables -F
$iptables -t nat -F
$iptables -t mangle -F
$iptables -X
$iptables -t nat -X
$iptables -t mangle -X
# Zero all packets and counters.
$iptables -Z
$iptables -t nat -Z
$iptables -t mangle -Z

# CREANDO ACL MACS/IPS
# RUTA dhcpd.conf 
#dhcp_conf=/etc/dhcp3/dhcpd.conf # para dhcp v3.x
dhcp_conf=/etc/dhcp/dhcpd.conf # para dhcp v4.x
# 
mac2ip=$(sed -n '/^\s\+hardware\|^\s\+fixed/ s:hardware ethernet \|fixed-address ::p' $dhcp_conf | sed 's/;//')

# RUTA ips_dhcp/macs_dhcp
path_ips=/etc/acl/ips_dhcp 
path_macs=/etc/acl/macs_dhcp

create_acl() {
    ips="# ips"
    macs="# macs"
    while [ "$1" ]; do
        mac="$1"
        shift
        ip="$1"
        shift
        $iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -s $ip -j ACCEPT
        ips="$ips\n$ip"
        macs="$macs\n$mac"
    done
# Para versiones anteriores a Debian 7 y Ubuntu 12x
#     echo $ips > $path_ips
#     echo $macs > $path_macs
# Para Debian 7x y Ubuntu 12x o superior
      echo -e $ips > $path_ips
      echo -e $macs > $path_macs
}

echo ok

#####################
### KERNEL RULES ###
#####################

echo Load Kernel Rules...

# Activar ip forward rules
echo 1 > /proc/sys/net/ipv4/ip_forward

echo OK

####################
# DEFAULT POLICIES #
####################

echo Apply Default Policies...

# LOOPBACK
$iptables -A INPUT -i lo -j ACCEPT
$iptables -A OUTPUT -o lo -j ACCEPT

echo ok

##########################
# LOCAL NETWORK POLICIES #
##########################

echo Apply Local Network Policies...

# SOLO PETICIONES DE LA LAN
create_acl $mac2ip
$iptables -t mangle -A PREROUTING -i $lan -j DROP
Muy Importante
Este script es válido para Debian 7, Ubuntu 12x o superior. Para versiones anteriores (Ubuntu 10x, Debian 6) hay que suprimir la "-e" del script. Esto se debe a la incompatibilidad de versiones del comando "echo". Para mayor información visite Etherlabs
El siguiente paso es definir qué hacer con estas "macs" generadas por el DHCP y convertidas en ACLs por el IPtables. O sea, determinar qué privilegios le otorgará dentro de nuestra red local.  Para esto, puede consultar el post anterior Firewall.
Nota:
El duo DHCP+IPtables solo puede darle conectividad a una Mac (la real o la clonada), pero no a las dos al mismo tiempo, por tanto uno de los dos terminales se quedaría sin acceso a Internet al momento de navegar y eventualmente el usuario real puede alertar al Administrador TI sobre este comportamiento anormal, y sería otro indicador para tomar medidas.
Medidas Opcionales
Si ya aplicó las reglas explicadas anteriormente (que solo pueden acceder a su red local las macs que estableció previamente en las acls, o las establecidas manualmente en el dhcpd.conf), la siguiente regla no es necesaria. Solo la mostramos a modo de ejemplo, para que nuestros lectores puedan ver las posibilidades de iptables. Tenga en cuenta que si la aplica y son demasiadas ips a bloquear, puede generar una sobrecarga en el firewall, por tanto recomendamos más efectivo filtrarlas en el squid.
En el siguiente ejemplo, creamos dos ACLs: blacklist-macs (para bloquear las macs no autorizadas o clonadas) y blacklist-ips (Para las ips o rangos de ips falsificados, de la LAN o de internet) y las ubicamos en la ruta de las ACLs (route) y las bloqueamos.
# blacklist-macs
for mac in `sed '/#.*/d' $route/blacklist-macs`; do
 $iptables -t mangle -A PREROUTING -m mac --mac-source $mac -j DROP
 $iptables -A FORWARD -i $lan -m mac --mac-source $mac -p tcp -j DROP
done

# blacklist-ips
for ips in `sed '/#.*/d' $route/blacklist-ips`; do
   if echo $ips | grep "-" >/dev/null; then
     $iptables -A FORWARD -m iprange --dst-range "$ips" -j DROP
   else
     $iptables -t mangle -A PREROUTING -i $ips -j DROP
     $iptables -A FORWARD -d $ips -j DROP
     $iptables -A INPUT -s $ips -j DROP
     $iptables -A OUTPUT -s $ips -j DROP
   fi
done
3. TODO POR EL SQUID
El hecho de que el servidor sea transparente no significa que el tráfico de internet no pase por Squid. Todo el tráfico de su red Lan debe pasar obligatoriamente por el Squid, si quiere evitarse dolores de cabeza. El Administrador TI deberá evitar a toda costa reglas en la cabecera del Iptables como la siguiente:
####################
# ACCESO ILIMITADO #
####################
for mac in `sed '/#.*/d'/etc/acl/macs-privilegiadas`; do
 $iptables -t nat -A PREROUTING -i $lan -m mac --mac-source $mac -j ACCEPT
 $iptables -A FORWARD -i $lan -m mac --mac-source $mac -p tcp -j ACCEPT
done
Donde la ACL "macs-privilegiadas" contiene un grupo de Macs (terminales) que no pasan por el Squid, ni por el iptables, por tanto no están sujetas a ningún tipo de supervisión ni su actividad en la red e internet sale en algún reporte. Esta regla es un ejemplo de lo que NO SE DEBE HACER en el Iptables.
Hay administradores TI que usan esta regla (y otras similares) para que los jefes y los "amigos", hagan y deshagan, sin que nadie lo sepa. Grave error, ya que si un atacante o usuario no autorizado se hace con una de estas macs, con tan elevado nivel de privilegios, simplemente el Administrador TI jamás sabrá lo que sucede y los recursos de su red pueden dilapidarse en cuestión de segundos... y su contrato de soporte terminado por los mismos jefes y amigos a quienes les ofreció el cielo y la tierra con esta regla.
Esta regla en la cabecera se usa principalmente para mantenimiento. Cuando existe algún problema en la red local, en el squid o en el iptables, o no hay conectividad interna o algún otro problema derivado de las configuraciones, una buena manera de "descartar" si el problema es en la entrada de nuestra red (antes de aplicar filtrados) o en otro tramo de la misma, es colocando nuestra dirección mac en esta acl y saltándonos nuestras propias restricciones para acceder a internet y otros recursos.
Es más viable abrir el puerto 443 bajo demanda, que otorgar privilegios ilimitados a un grupo reducido de Macs. Para abrirlo basta con colocar la misma acl y crear la siguiente regla en el IPtables
########################
### Macs acceso 443 ####
########################
for mac in `sed '/#.*/d' $route/macs-privilegiadas`; do
 $iptables -A FORWARD -m mac --mac-source $mac -p tcp --dport 443 -o $internet -j ACCEPT
done
En el Squid filtraremos los accesos que no sean https (ya que está en modo transparente y Squid no filtra peticiones https en modo "transparent") y declaramos las acls (mencionadas en otros post de la serie Firewall), tales como, blacklist-web (contiene todos los sitios en internet a bloquear), blacklist-ips (contiene todas las ips que queremos banear), extensiones (para impedir que determinados archivos con un tipo específico de extensión sean descargados y dilapiden el ancho de banda. También se puede hacer por mime_type) y las diferentes acls que contienen los listados de las macs de nuestra red, clasificadas según el nivel de privilegios que les querramos otorgar y los horarios (explicados en el capítulo anterior Firewall II) y al final aceptarlas o bloquearlas
Squid Config
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
acl blacklist-web dstdomain -i "/home/usuario/acl/blacklist-web"
acl blacklist-ips src "/home/usuario/acl/blacklist-ips"
acl extensiones url_regex "/home/usuario/acl/extensiones"
acl archivos-bloqueados rep_mime_type -i "/home//usuario/acl/archivos-bloqueados"
acl macs-443 arp "/home/usuario/acl/macs-443"
acl macs-permitidas arp "/home/usuario/acl/macs-permitidas"
acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9]

# reglas propias (bloqueando o aceptando)
http_access allow localhost
http_access allow facebook macs-443
http_access allow youtube macs-443
http_access allow vimeo macs-443
#http_reply_access allow macs-443 archivos-bloqueados
http_access deny blacklist-web
http_access deny blacklist-ips
http_reply_access deny archivos-bloqueados
http_access deny extensiones
http_access allow macs-permitidas
El filtrado por Squid con las conocidas SuperBlacklist, será abordado en la próxima entrega Firewall IV
4. MEDIDAS OPCIONALES
Vigilancia ARP, puertos
Podemos implementar una vigilancia estricta sobre las tablas ARP, para evitar su envenenamiento. Para esto podemos utilizar ARPWatch, ARPon o MACWatch (una variante mejorada de ARP Watch), siendo las dos últimas las más recomendadas, en conjunto, y complementar con Port Knocking
Lectura recomendada: ArpON Proteccion contra Spoofing/Poisoning y mas
Cache DNS
A medida que se van colocando filtros, esto puede ralentizar las peticiones. Colocar un servidor DNS, no es lo adecuado en muchos casos, ya que debe llevar una protección adicional para evitar ataques DNS, sin embargo podemos "cachear" las consultas DNS de los terminales de nuestra red local, para reducir la latencia creada por los diferentes filtros y la conexión de internet. Para esto podemos usar DNSmasq o djbdns, aunque el uso del primero es mucho más sencillo de implementar, siempre que no active el DHCP que trae por defecto, para que no entre en conflicto con nuestro DHCP3. Además, al no ser persistente, a su reinicio vacía la caché de consultas, lo cual es una ventaja para evitar un ataque DNS.
Puede verlo en acción en Jam Blog y trabajando en combinación con la herramienta de cifrado DNSCrypt, ambos cortesía de Jesús Marin.
Broadcast, Diagramación y Mapeo
Las ips sin asignar generan problemas de broadcast. Una correcta diagramación de la red local puede significar la diferencia entre un flujo de tráfico transparente y un cuello de botella. Para mayor información, lea Subnetting y Redes con Subnetting
Existen muchas herramientas que pueden ayudarnos a mapear nuestra red local y verificar (en intervalos) si los equipos están activos, o presentan cualquier anormalidad, (clonación, problemas de conectividad interna, etc), tales como JNetMap, (Official), Network Topology Mapper de Solarwinds, Nagios, entre otras.
Si están en Windows pueden echar mano de la suite Net Tools, la cual contiene un sinnúmero de herramientas, para diagnosticas nuestra red, y poner a prueba nuestro sistema de seguridad.
Protección Adicional
Existe niveles más altos de seguridad. La encriptación de las comunicaciones cliente-servidor es una alternativa. Hay muchas técnicas y programas que logran muy buena seguridad como las soluciones tipo VPN, tales como OpenVPN (Howto GNU/Linux, Howto Android, Howto Ubuntu), PPTP, Openswan, etc.

Contramedidas frente a ataques ARP y DHCP (Update Feb 4/2015)
Nada de lo anterior nos protegerá de un ataque DHCP (rogue dhcp) o envenenamiento ARP, y filtrar los puertos dhcp 67 y 68 en el iptables es virtualmente imposible y las contramedidas para proteger la tabla ARP, como ArpOn, por sí solas son insuficientes.
Por lo anterior recomendamos como alternativa realizar una protección adicional, implementando VACL (Vlan Access List), que controlan el trafico UDP dirigido a los puertos 68 y 67, y DHCP Snooping, una contramedida implementada en dispositivos Cisco. Para mayor información consulte el post Defensas frente ataques DHCP
Y para proteger la tabla ARP, podemos utilizar Dynamic ARP Inspection (DAI), una medida de seguridad también disponible en switches Cisco que nos permite validar los paquetes ARP de la red, la cual utiliza la tabla de asociaciones IP-MAC generada por DHCP Snooping. Para mayor información consulte el post Defensas frente ataques ARP. Y para evitarlo en los clientes, utilice el script AntiArpSpoof (Descarga)

... Continúa en Firewall IV
Maravento, Actualizado en: 21:04
Escrito por: Maravento Studio
 
© 2017 Maravento. All Rights Reserved | Powered by Maravento
Design by Novatoz and Maravento | Bloggerized By LawnyDesignz
# https://github.com/google/code-prettify