MARAVENTO STUDIO | TECNOLOGY AND SECURITY OPEN SOURCE 
MARAVENTO STUDIO 
FIREWALL
How/TO Firewall (IPTables & Squid) 
1 
Firewall 
Last Update: Oct 03/2014 
ACEPTAR O DENEGAR HTTPS 
En el artículo “Bloque...
How/TO Firewall (IPTables & Squid) 
2 
Si elegimos un Proxy Cache (3128) (sin la cláusula transparent), Squid filtrará las...
How/TO Firewall (IPTables & Squid) 
3 
~$ which iptables /sbin/iptables 
Luego haga el script de IPtables con los datos ap...
How/TO Firewall (IPTables & Squid) 
4 
netmask=255.255.255.0 # alias alias sed="sed '/#.*/d'" # Opcional horario (24h) hor...
How/TO Firewall (IPTables & Squid) 
5 
iptables: contiene la ubicación del IPtables 
proxyport: el puerto que define el pr...
How/TO Firewall (IPTables & Squid) 
6 
PASOS 
1. Cree dos ACLs cada una con las direcciones ip o rangos completos que vaya...
How/TO Firewall (IPTables & Squid) 
7 
estar comentada (con #) o eliminada (así se cierra el acceso a este puerto). Si eli...
How/TO Firewall (IPTables & Squid) 
8 
con acceso a nuestra red puede saltarse literalmente estas IPs bloqueadas con progr...
How/TO Firewall (IPTables & Squid) 
9 
Es importante resaltar que los comandos host, dig y nslookup debe ejecutarlos como ...
How/TO Firewall (IPTables & Squid) 
10 
que Sockersniff detecte la IP y el resto es el mismo procedimiento que con los pro...
How/TO Firewall (IPTables & Squid) 
11 
# TWITTER 199.59.148.0-199.59.151.255 # MYSPACE 216.178.32.0-216.178.47.255 # HI5 ...
How/TO Firewall (IPTables & Squid) 
12 
64.4.0.0-64.4.63.255 65.52.0.0-65.55.255.255 72.246.0.0-72.247.255.255 78.141.128....
How/TO Firewall (IPTables & Squid) 
13 
NOTA: Por seguridad se recomienda cambiar los puertos del proxy por defecto, o sea...
How/TO Firewall (IPTables & Squid) 
14 
# ANTI-ULTRASURF for string in `sed $route/blacklist-string`; do $iptables -I FORW...
How/TO Firewall (IPTables & Squid) 
15 
.ninjacloak.com .24topproxy.com .sneakzorz.com .proxybutton.com .wtunnel.net .ztun...
How/TO Firewall (IPTables & Squid) 
16 
.webproxy.mobi .turkey.uswebproxy.com .webproxy-server.com .free-web-proxy.de .pro...
How/TO Firewall (IPTables & Squid) 
17 
Para descargar packs "blacklist" visite el post Firewall IV. 
Para completar el fi...
How/TO Firewall (IPTables & Squid) 
18 
entonces si hay demasiados hexadecimales en la acl blacklist-string, su firewall s...
How/TO Firewall (IPTables & Squid) 
19 
Firewall II 
En el post anterior Firewall explicamos la manera de bloquear las con...
How/TO Firewall (IPTables & Squid) 
20 
2. Denegar el resto de las conexiones (corta literalmente las comunicaciones al re...
How/TO Firewall (IPTables & Squid) 
21 
Primero debe establecer en la cabecera del IPtables el horario (Ajústelo en depend...
How/TO Firewall (IPTables & Squid) 
22 
Firewall III 
Actualizado Mar 29/2014 
En las entregas anteriores Firewall y Firew...
How/TO Firewall (IPTables & Squid) 
23 
Este es uno de los problemas más graves que enfrentan las redes locales actuales, ...
How/TO Firewall (IPTables & Squid) 
24 
Hay que aclarar que no es un método 100% garantizado, ya que si hay problemas inte...
How/TO Firewall (IPTables & Squid) 
25 
Además, hay que tener en cuenta el tipo de enrutamiento de la red local, desde y h...
How/TO Firewall (IPTables & Squid) 
26 
Nuestro post tampoco les ofrecerá una solución "mágica", ya que no existe. Las int...
How/TO Firewall (IPTables & Squid) 
27 
Además, existen muchos ataques que involucran al servidor DHCP. Explicarlos todos ...
How/TO Firewall (IPTables & Squid) 
28 
recomendamos en primera instancia la lectura de los artículos Configuración segura...
How/TO Firewall (IPTables & Squid) 
29 
} host CLIENTE2 { hardware ethernet 00:14:d1:d5:xx:xx; fixed-address 192.168.1.101...
How/TO Firewall (IPTables & Squid) 
30 
b. El amarre real se produce entre mac+ip, ya que a pesar de que se asigna un nomb...
How/TO Firewall (IPTables & Squid) 
31 
dhcpd_conf=/etc/dhcp/dhcpd.conf pid_file=/var/run/isc-dhcp-server/dhcpd.pid interf...
How/TO Firewall (IPTables & Squid) 
32 
En este orden de ideas, el próximo paso (tal y como lo explicamos en el post Firew...
How/TO Firewall (IPTables & Squid) 
33 
mac2ip=$(sed -n '/^s+hardware|^s+fixed/ s:hardware ethernet |fixed- address ::p' $...
How/TO Firewall (IPTables & Squid) 
34 
# Activar ip forward rules echo 1 > /proc/sys/net/ipv4/ip_forward echo OK ########...
How/TO Firewall (IPTables & Squid) 
35 
bloquear, puede generar una sobrecarga en el firewall, por tanto recomendamos más ...
How/TO Firewall (IPTables & Squid) 
36 
Esta regla en la cabecera se usa principalmente para mantenimiento. Cuando existe ...
How/TO Firewall (IPTables & Squid) 
37 
http_access deny blacklist-ips http_reply_access deny archivos-bloqueados http_acc...
How/TO Firewall (IPTables & Squid) 
38 
Si están en Windows pueden echar mano de la suite Net Tools, la cual contiene un s...
How/TO Firewall (IPTables & Squid) 
39 
Firewall IV 
En los posts anteriores Firewall, Firewall II y Firewall III, abordam...
How/TO Firewall (IPTables & Squid) 
40 
Administrador TI haya recopilado y que no se encuentren en las ACLs ofrecidas en e...
How/TO Firewall (IPTables & Squid) 
41 
http_access allow manager webserver http_access deny manager http_access allow pur...
How/TO Firewall (IPTables & Squid) 
42 
Existen varios tipos de ataques contra la infraestructura informática. En dependen...
How/TO Firewall (IPTables & Squid) 
43 
permanente. Hay alternativas Open Source, como Open UTM, pero aún está en fase de ...
How/TO Firewall (IPTables & Squid) 
44 
APF_BAN= "Si es igual a uno (1) se usará APF, sino lo tienes instalado, cámbialo p...
How/TO Firewall (IPTables & Squid) 
45 
autorizada logre llegar al servidor de destino. Esto elimina cualquier posibilidad...
How/TO Firewall (IPTables & Squid) 
46 
complejo y más fácil de aprender a utilizar para un usuario medio que SELinux. Aña...
Firewall
Firewall
Upcoming SlideShare
Loading in...5
×

Firewall

1,534

Published on

Iptables, DHCP, Squid, Pentesting, Security IT

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,534
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
47
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Firewall"

  1. 1. MARAVENTO STUDIO | TECNOLOGY AND SECURITY OPEN SOURCE MARAVENTO STUDIO FIREWALL
  2. 2. How/TO Firewall (IPTables & Squid) 1 Firewall Last Update: Oct 03/2014 ACEPTAR O DENEGAR HTTPS En el artículo “Bloqueo de p2p, redes sociales y messengers” dimos algunas herramientas para que el Administrador IT pudiera bloquear las conexiones p2p y https en su red local, las cuales se centraban en afectar el archivo host, sin embargo el inconveniente es que algunos antivirus (Microsoft Essential Security, etc), eliminan estas modificaciones y restaura el host. También ofrecimos dentro del PACK algunos archivos .reg para afectar registro de Windows de los clientes e impedir la ejecución de ciertos programas en sus terminales, como ares, ultrasurf, tor, utorrent, eMule, bittorrent y un largo etc, pero hay programas como Malwarebytes que eliminan estas modificaciones. Si bien puede surtir los efectos deseados en redes pequeñas y controlables, esta alternativa aplica si los clientes de la red local son Windows. Con MacOS o Linux es virtualmente imposible. Esto sin mencionar los que acceden con sus smartphones, tabletas y demás dispositivos portables, con una variedad de sistemas operativos fuera del alcance del Administrador IT. Ante esta situación solo nos queda un camino: suicidarnos… Mejor usar a los superhéroes Batman y Robin: IPTABLES y SQUID entre nuestra red local e internet, para filtrar el contenido. Nota: Para los amantes de Windows Server, lamentamos informarles que Microsoft decidió usar servidores Linux para Skype. 8080 o 3128: ESA ES LA CUESTION Saltándonos la explicación de cómo funciona IPTABLES y SQUID, se presenta un gran dilema al aplicar las políticas restrictivas en un servidor proxy: Usamos un Proxy Cache (Todas las peticiones van al puerto 3128 por default) o un Proxy Cache Transparente (Redirección de todas las peticiones del 80 al puerto 8080 Transparent por default).
  3. 3. How/TO Firewall (IPTables & Squid) 2 Si elegimos un Proxy Cache (3128) (sin la cláusula transparent), Squid filtrará las peticiones HTTPS, que a fin de cuentas es el objetivo de este artículo y el látigo que azota a los Administrador IT, que intentan frenar a sus usuarios para que no se la pasen metidos en las redes sociales en horas laborales y dilapiden el preciado ancho de banda, pero esta configuración implica una carga laboral muy grande, ya que el Administrador IT tendría que configurar manualmente los navegadores web de todos los equipos de su red local para que apunten a la ip del proxy y al puerto. Esta selección se vuelve inmanejable si tenemos en cuenta que hay que configurar smartphones, tabletas y demás dispositivos portables, y a los visitantes ocasionales procedentes de otras redes con diferentes configuraciones. Si bien existen scripts que hacen este trabajo, no están diseñados o no funcionan bien fuera del entorno Windows. Caso contrario, si el Administrador IT se decanta por un Proxy Cache Transparente, no tendría que hacer esta tediosa tarea, pero no puede filtrar las peticiones HTTPS (443) ya que SQUID no filtra HTTPS en modo transparente (aunque otros afirman lo contrario). Lo anterior se traduce en que cualquier novato puede saltarse la protección del proxy y ganar acceso al centro mundial del chisme (facebook) con solo ponerle una "S" al final de HTTP, o usar un túnel VPN, o los escurridizos Tor o Ultrasurf . Antes que lo considere, no pierda el tiempo redireccionando las peticiones del 443 al 8080, porque el navegador web no podría verificar los certificados de seguridad SSL procedentes de estas conexiones seguras y se presenta el típico error de certificado SSL. Y si piensan que la solución es crear certificados propios SSL o un man-in-the-middle, aparte del trabajo adicional que implica y de la ralentización del tráfico, es algo considerado por la comunidad como una invasión a la privacidad... Otra pérdida de tiempo. Después de debatir la problemática en foros y probar algunas alternativas, llegamos a la conclusión de que es posible usar lo mejor de ambos mundos y obtener un buen resultado. En otras palabras, podemos establecer un Proxy Cache Transparente y a la vez filtrar las peticiones HTTPS con una solución muy simple: agregando un par de líneas en el Firewall de Linux IPtables. ANTES DE COMENZAR Importante: Las siguientes técnicas están basadas en los principios de los NGFW (Next Generation Firewalls), con un esquema de seguridad en el cual solo lo legitimo y autorizado es permitido, bloqueando todo lo demás, sin embargo se ofrece la posibilidad de hacerlo a la inversa, o sea, permitir todo y bloquear urls o ips específicas, pero esta última no la recomendamos, por carecer de estándares básicos de seguridad, sin embargo queda a juicio del administrador TI usar una técnica u otra. El Firewall IPtables viene por defecto en muchas distribuciones de Linux, pero su ubicación puede variar. Para saberlo use los comandos 'which' o 'whereis'.
  4. 4. How/TO Firewall (IPTables & Squid) 3 ~$ which iptables /sbin/iptables Luego haga el script de IPtables con los datos aportados por los comandos y colóquelo en init.d, especificando la ruta del IPTables, tal y como aparece abajo. Sin importar la política por default que se aplique en iptables, se recomienda SIEMPRE, cerrar todo al final del script. Esto es con el objeto de cerrar algún puerto abierto declarado en alguna regla específica, pero no cerrado explícitamente para el resto.También se aclara que el iptables no agrega las reglas en el orden del script sino en su propio orden. Para mayor información, lea el Capítulo 3 de Iptables Turorial 1.1.19 Script de iptables: Iptables Script by Maravento Studio se encuentra bajo una Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional. Basada en una obra en www.maravento.com. Permisos que vayan más allá de lo cubierto por esta licencia pueden encontrarse en www.maravento.com. #--------------------------------------------------------- # FRAGMENTO DE IPTABLES SCRIPT BY MARAVENTO STUDIO # v1.0 B2 Nov 21/2013 # Written by: # Jhonathan Sneider sneider2002@gmail.com # Alej Calero administrador@maravento.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/ # Arief Yudhawarman http://awarmanf.wordpress.com/ # # 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 FIREWALL START... sysadmin="cc:af:78:a3:XX:XX" internet=eth0 lan=eth1 local=192.168.1.0 iptables=/sbin/iptables route=/home/usurio/acl proxyport=8080
  5. 5. How/TO Firewall (IPTables & Squid) 4 netmask=255.255.255.0 # alias alias sed="sed '/#.*/d'" # Opcional horario (24h) hora_actual=$(date +%H) hora_permitida=12 hora_ilimitada=18 # Optional modules iptables=/sbin/iptables sysctl=/sbin/sysctl modprobe=/sbin/modprobe rmmod=/sbin/rmmod arp=/usr/sbin/arp ############### # FLUSH RULES # ############### echo Apply Flush Rules... # Zero all packets and counters $iptables -F $iptables -X $iptables -t nat -F $iptables -t nat -X $iptables -t mangle -F $iptables -t mangle -X $iptables -t raw -F $iptables -t raw -X $iptables -t security -F $iptables -t security -X $iptables -Z $iptables -t nat -Z $iptables -t mangle -Z ################ # KERNEL RULES # ################ # Load required kernel modules $modprobe ip_conntrack_ftp $modprobe ip_conntrack_irc # Activar ip forward rules echo 1 > /proc/sys/net/ipv4/ip_forward En la cabecera del script de colocan las siguientes variables: route: es la variable que sustituye la ruta en el IPtables donde el Administrador IT ubicará las ACLs internet: es eth0, la interfaz que recibe el internet del exterior lan es eth1, la interfaz que maneja la red local adminMAC: la variable que contiene la/s MAC/s de administración del IPtables, o de acceso a los puertos SSH/VNC/WEBMIN
  6. 6. How/TO Firewall (IPTables & Squid) 5 iptables: contiene la ubicación del IPtables proxyport: el puerto que define el proxy default. Ej: 8080 netmask: define la máscara de red. alias: una serie de símbolos que usaremos en la regla, para validarlos Es importante resaltar que las variables solo son para el script de IPTables. En el Squid no se usan, debido a que es un archivo de configuración, por tanto, para el caso de route hay que poner la ruta completa y no la variable. A continuación le podemos otorgar privilegios a sysadmin para los puertos SSH, Webmin, y VNC. Si hay más de un sysadmin debe colocar las macs en sysadmin, una después de las otras, separadas por un espacio. # PRIVILEGIOS SSH, WEBMIN, VNC PARA SYSADMIN $iptables -A INPUT -i $lan -m mac --mac-source $sysadmin -p tcp -m multiport --dports 22,10000,5900 -j ACCEPT Instalar Squid Para este procedimiento, instale Squid v2.x o v3.x, en dependencia de la versión de su distribución. sudo apt-get install squid3 Puerto del Proxy No se recomienda el uso puertos reservados para la configuración del Proxy (Ej: 80 (Internet), 53 (DNS), etc.) Puede consultar los puertos de servicios en /etc/services El puerto del Proxy debe ser predefinido por el Administrador IT al momento de la configuración. Squid usa por defecto el 3128, pero puede cambiarlo. Para activar el modo transparente (que no tengamos que configurar el navegador web) solo necesita agregarle al puerto la palabra "transparent" (para Squid 2.6 o superior) o "intercept" (Para Squid 3.1 o superior) después del puerto elegido (Vea Directiva http_port). Para los efectos de este artículo, usaremos el puerto 8080 en modo transparente y versión 3x de Squid. # Default Squid Listens to Port 3128 http_port 8080 transparent Diferencia entre distros de Linux IPtables difiere en cada versión de Linux. Lea el post de Nico Schottelius para solucionarlo. CONFIGURANDO IPTABLES Solo mencionaremos la parte del filtrado HTTPS y otras recomendaciones. Asumimos que ya tienen el script iptables.sh (Por seguridad cámbiele el nombre) ubicado en init.d y arrancado (puede usar webmin para arrancarlo automáticamente en cada inicio del sistema) y que SQUID e IPTABLES están configurados en modo TRANSPARENTE. Las siguientes políticas solo afectan las conexiones al puerto 443 (HTTPS) y no al resto de las conexiones (80, 53, 21, 8080, etc). Por tanto debe ubicarlas después de las reglas que hayan establecido por defecto. Ambos scripts son idénticos (ACCEPT Y DROP). Lo único que cambia es el nombre de la ACL a usar y su ruta, y la regla.
  7. 7. How/TO Firewall (IPTables & Squid) 6 PASOS 1. Cree dos ACLs cada una con las direcciones ip o rangos completos que vaya a bloquear o aceptar, según el caso y ubíquelas donde considere (establezca los permisos necesarios). Para los efectos de este instructivo las llamaremos https- permitidos y https-bloqueados y estarán en la ruta explicada en la variable $route de la cabecera del IPtables. 2. Edite el script iptables.sh en init.d (o como sea que lo haya nombrado) con privilegios root y después de las políticas de la red que haya determinado como prioridad, coloque lo siguiente (copie y pegue): Caso 1: ACEPTAR CONEXIÓN (Recomendado) Solo se aceptan las IPs incluidas en la ACL https-permitidos. El resto de las peticiones https se rechazan. Caso 2: DENEGAR CONEXIÓN Solo se deniegan las IPs incluidas en la ACL https-bloqueados. El resto de las peticiones https se aceptan. El siguiente ejemplo es el clásico Caso 1: se aceptan solamente algunos sitios https (correos, etc) y el resto se bloquea. ########################## # LOCAL NETWORK POLICIES # ########################## echo Apply Local Network Policies... # SOLO PETICIONES LAN for mac in `sed $route/macs-* | tr '[A-Z]' '[a-z]' | sort -u`; do $iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -j ACCEPT done $iptables -t mangle -A PREROUTING -i $lan -j DROP # ACCESO LAN AL PUERTO 443 (SOLO SE PERMITEN SITIOS ACL HTTPS-PERMITIDOS) for ip in `sed '/#.*/d' $route/https-permitidos`; do if echo $ip | grep "-" >/dev/null; then $iptables -A FORWARD -m iprange --dst-range "$ip" -j ACCEPT else $iptables -A FORWARD -d $ip -j ACCEPT fi done # ACCESO LAN AL PUERTO 443 (DENEGAR SITIOS ACL HTTPS-BLOQUEADOS) #for ip in `sed '/#.*/d' $route/https-bloqueados`; do # if echo $ip | grep "-" >/dev/null; then # $iptables -A FORWARD -m iprange --dst-range "$ip" -j DROP # else # $iptables -A FORWARD -d $ip -j DROP # fi #done echo ok Donde "route" es la ruta donde están las acls con las macs de la red local; y "macs-*" es el nombre con el que comienzan las acls con dichas macs (Ej: macs-permitidas). Si cambia el nombre de sus acls deberá hacerlo en el script. Para finalizar el script, debe asegurarse de que se encuentre el puerto 443. Si eligió el CASO 1: ACEPTAR CONEXIÓN, la línea correspondiente a 443 debe
  8. 8. How/TO Firewall (IPTables & Squid) 7 estar comentada (con #) o eliminada (así se cierra el acceso a este puerto). Si eligió el CASO 2: DENEGAR CONEXIÓN, la línea debe estar descomentada (para abrir el puerto) ########################## ### PRESET CONNECTIONS ### ########################## echo Apply Preset Connections... # LAN ---> INTERNET # ACEPTAR CONEXIONES DE LA LAN A PUERTOS HTTP, FTP, DNS, POP3, SSH, SMTP !HTTPS $iptables -A FORWARD -s $local/$netmask -i $lan -p udp -m multiport -- dports 25,53,110 -o $internet -j ACCEPT $iptables -A FORWARD -s $local/$netmask -i $lan -p tcp -m multiport -- dports 80,8080,22,21,53 -o $internet -j ACCEPT # $iptables -A FORWARD -s $local/$netmask -i $lan -p tcp --dport 443 -o $internet -j ACCEPT # DENEGAR EL RESTO $iptables -A FORWARD -s $local/$netmask -i $lan -o $internet -j DROP echo ok Si quiere permitir algunos terminales dentro de su red local que tengan acceso al puerto 443 escriba la siguiente regla y póngala antes de la regla de aceptar o denegar conexión https, pero primero cree la ACL (la llamaremos macs-443) y coloque dentro todas las MACs que quiera que tengan acceso al 443. El siguiente ejemplo hemos permitido el acceso al 443 a una acl llamada macs- 443, en el horario laboral (El horario se estableció previamente en la cabecera del iptables definido como hora actual - hora limitada). Después que finalice la hora laboral, se abre el puerto 443 para toda la red local. # ACCESO AL PUERTO 443 (SOLO ALC MACS-443) if [ $hora_actual -lt $hora_ilimitada ]; then for mac in `sed $route/macs-443`; do $iptables -A FORWARD -m mac --mac-source $mac -p tcp --dport 443 -o $internet -j ACCEPT done else $iptables -A FORWARD -p tcp --dport 443 -o $internet -j ACCEPT fi Pero si quiere bloquear el 443 de forma permanente (sin horarios) y dejarlo solamente para las macs-443, cambie la última línea por DROP # ACCESO PRIVILEGIADO AL PUERTO 443 (SOLO ALC MACS-443) for mac in `sed $route/macs-443`; do $iptables -A FORWARD -m mac --mac-source $mac -p tcp --dport 443 -o $internet -j ACCEPT done $iptables -A FORWARD -p tcp --dport 443 -o $internet -j DROP Ahora, cada vez que un usuario visite https://www.facebook.com, el navegador quedará en suspenso hasta que se agote el tiempo y se cae la página como si no hubiese internet. En una política basada en el Caso 2, solamente se bloquearán las IPs que escriba en la ACL, pero como este caso abre el puerto 443, implica que cualquier usuario
  9. 9. How/TO Firewall (IPTables & Squid) 8 con acceso a nuestra red puede saltarse literalmente estas IPs bloqueadas con programas como Ultrasurf o Tor. En una política basada en el Caso 1, el puerto 443 está cerrado por defecto y solo se autorizan las IPs https contenidas en la ACL https-permitidos, por lo que los programas como Tor o Ultrasurf y sus derivados, quedarán inservibles. Basados en ese análisis, consideramos que la mejor política es el Caso 1; o sea, aceptar solamente las conexiones https (443) procedentes de los correos electrónicos y messengers (Hotmail, Skype, gmail, yahoo, etc), bancos y uno que otro portal corporativo o institucional y denegar el resto del tráfico por ese puerto, e ir agregando sitios a medida que los de su red local lo soliciten y las políticas de seguridad de su empresa las valide. El resto del tráfico (Puerto 80) puede ser filtrado por el Squid. Otros métodos de bloqueo Iptables, de acuerdo a la documentación, solamente trabaja con IPs y puertos. Sin embargo una regla basada en aceptar o denegar urls es aceptada por Iptables. $iptables -A FORWARD -i $lan -o $internet -p tcp -d google.com --dport 443 -j ACCEPT $iptables -A FORWARD -i $lan -o $internet -p tcp -d facebook.com --dport 443 -j DROP Lo anterior se puede hacer debido a que Iptables "traduce" las urls a ips y las acepta o niega en dependencia de la regla, pero esto ralentiza el firewall, ya que cada vez que se corre debe realizar estas consultas, y el tiempo que demore lo determinará la cantidad de urls/ips a consultar. Es por esta razón que basamos nuestro método en IPs directamente. También existen otras reglas para bloquear sitios: $iptables -A FORWARD -p tcp --dport 443 -m string --string 'facebook.com' --algo bm -j DROP O para bloquear descargas de archivos con extensiones específicas: $iptables -A INPUT -p tcp -m string --string ".exe" --algo bm -j DROP O para vigilar un puerto y bloquear tráfico sospechoso por ejemplo en el puerto 80 $iptables -A INPUT -p tcp --dport 80 -m string --string "/etc/passwd" -- algo kmp -j LOG --log-ip-options --log-tcp-options --log-prefix "passwd access " $iptables -A INPUT -p tcp --dport 80 -m string --string "/etc/passwd" -- algo kmp -j DROP Sin embargo aclaramos que las reglas string no corren con fluidez y ralentizan demasiado el firewall y la navegación en comparación con la validación por ip, sin embargo queda a criterio del administrador IT, utilizarlas o no. DONDE BUSCO LAS IPs PARA LAS ACLs? El Administrador IT debe saber cuáles sitios HTTPS debe aceptar o denegar. Para averiguarlo, con tan solo escribir en el terminal de linux la palabra host y seguido la URL del sitio a bloquear (Ej: host www.google.com), rápidamente obtiene la/s IP/s del sitio. También puede usar dig o nslookup (Ej: nslookup facebook.com).
  10. 10. How/TO Firewall (IPTables & Squid) 9 Es importante resaltar que los comandos host, dig y nslookup debe ejecutarlos como mínimo 3 veces (con www y sin www para cada dominio), ya que los resultados en cada ejecución puede ser diferentes. Otro método que arroja resultados más amplios es originAS. Para obtenerlo visite centralops.net/co/, busque el sitio de su preferencia (Ej: facebook.com) y en los resultados aparecerá el originAS. Luego ejecute en consola el siguiente comando: /usr/bin/whois -h whois.radb.net '!gAS32934' | tr ' ' 'n' | sort -n - k1,1 -k2,2 -k3,3 -k4,4 |grep / Donde, por ejemplo, AS32934 es el originAS de facebook y seguido arrojará todos los rangos de ips de este dominio. Desafortunadamente no siempre se obtiene el originAS de un dominio, pero es bastante útil y ahorra tiempo en la recopilación de las IPs. El originAS también sirve para bloquear o aceptar rangos en el Iptables. Ejemplo de bloqueo de Ultrasurf por OriginAS (AS6939) # BLOCK ULTRASURF (solo bloquea los rangos de ips relacionados con el sitio web) for i in $(/usr/bin/whois -h whois.radb.net '!gAS6939' | tr ' ' 'n' | sort -n -k1,1 -k2,2 -k3,3 -k4,4 |grep /) do iptables -A FORWARD -d $i -j DROP done Aunque no es muy recomendable usarlo para este propósito (bloqueo o aceptar conexiones a un sitio), ya que si lo incluye en el Iptables, cada vez que corre, debe consultar la base de datos en internet para actualizar las tablas, lo cual ralentiza la ejecución del firewall. Si no se abusa de este comando puede usarse para casos de emergencia (ataques DDoS, etc) Otra herramienta excelente para determinar las ip que usan los programas, navegadores y demás para conectarse es Socketsniff. Es muy efectiva y simple. Iniciamos el programa que queremos saber la ip a la cual se conecta (ej: Skype). Después de iniciado, arrancamos Sockersniff y elegimos Skype. Seguido ponemos el usuario y la contraseña en Skype y comienza la autenticación normal, y Sockersniff va registrando todos las ip a las que Skype intenta conectarse y otros datos como el puerto que usa, etc. Tomamos nota de las IPs y vamos a nuestra ACL correspondiente (bloquear o aceptar) y las validamos. Lo mismo con los sitios en Internet. Abrimos el navegador. Elegimos en Sockersniff el navegador a monitorear, y luego vamos a la página deseada, para
  11. 11. How/TO Firewall (IPTables & Squid) 10 que Sockersniff detecte la IP y el resto es el mismo procedimiento que con los programas. En ocasiones las IPs son similares, lo cual nos indica que hay un rango más amplio de IPs que usa nuestro programa o sitio web que queremos bloquear o aceptar. Para saberlo vamos a IP Adrdress Lockup, y buscamos las IPs, subiendo y bajando los octetos de valor decimal, para ir verificando el propietario o usuario de la IP, hasta completar el rango. También pueden usar Whois Lockup, o cualquier otra herramienta que gusten para determinar las IPs objetivo, siempre que brinden resultados confiables. DEFINIENDO LAS IPs EN LAS ACLs Si conseguir todas las IPs, que pueden ser cientos o miles, se convierte en algo tedioso, a continuación les ahorramos tiempo y ponemos a su disposición las IPs y rangos de IPs de los servicios y sitios más usados. Solo copie y pegue los que necesita y ubíquelos en la ACL correspondiente. NOTA: Las IPs que se relacionan a continuación pueden cambiar sin previo aviso, así como pueden aparecer nuevos rangos. Además es posible que las empresas propietarias de las IPs o los proveedores migren sus servidores a nuevas IPs o migren sus servicios a nuevos rangos de IPs, con el objeto de protegerse de un ataque prolongado DDoS y así balancear cargas y no interrumpir sus servicios, por tanto se recomienda hacer verificaciones cada 15 días, máximo 30 días (cada cierto tiempo actualizaremos los listados de IPs que se relacionan abajo). También hay que tener en cuenta el país desde donde se realiza el escaneo de IPs. Las que se relacionan a continuación fueron escaneadas desde Colombia. Si el país o el ISP cambian al momento de hacer host, puede que haya que agregar nuevos rangos. ACL https-bloqueados # HTTPS BLOQUEADOS # PUEDE AGREGAR LAS IP QUE CONSIDERE NECESARIOS # PARA DETERMINAR LA IP DE UN SITIO ENTRE AL TERMINAL Y ESCRIBA # HOST Y SEGUIDO LA URL DEL SITIO # EJEMPLO host www.facebook.com # NO INCLUYA MUCHAS IP O PUEDE RALENTIZAR EL FIREWALL # # REDES SOCIALES # # FACEBOOK 66.220.144.0-66.220.159.255 69.63.176.0-69.63.191.255 69.171.224.0-69.171.255.255 204.15.20.0-204.15.23.255 # FACEBOOK INFO 50.116.72.56 66.147.244.51 # BADOO 64.209.21.0-64.209.21.255 66.175.123.0-66.175.123.255
  12. 12. How/TO Firewall (IPTables & Squid) 11 # TWITTER 199.59.148.0-199.59.151.255 # MYSPACE 216.178.32.0-216.178.47.255 # HI5 67.221.174.31 # SONICO 208.74.29.108 # MENEAME.NET 46.137.126.119 ACL https-permitidos # HTTPS permitidos # PUEDE AGREGAR LAS IP QUE CONSIDERE NECESARIOS # PARA DETERMINAR LA IP DE UN SITIO ENTRE AL TERMINAL Y ESCRIBA # HOST Y SEGUIDO LA URL DEL SITIO # EJEMPLO host www.facebook.com # NO INCLUYA MUCHAS IP O PUEDE RALENTIZAR EL FIREWALL # Last Update Sep 13 2014 # # Google 64.233.160.0-64.233.191.255 66.102.0.0-66.102.15.255 66.249.64.0-66.249.95.255 72.14.192.0-72.14.255.255 74.125.0.0-74.125.229.159 74.125.229.175-74.125.255.255 173.194.0.0-173.194.37.127 173.194.37.143-173.194.255.255 208.109.4.0-208.109.6.255 208.117.224.0-208.117.255.255 209.85.128.0-209.85.255.255 216.69.149.0-216.69.149.255 216.239.32.0-216.239.63.255 # Youtube 74.125.229.160-74.125.229.174 173.194.37.128-173.194.37.142 # # Yahoo and Messenger 66.163.160.0-66.163.191.255 68.142.254.15 68.180.128.0-68.180.255.255 72.30.0.0-72.30.255.255 74.6.32.0-74.6.63.255 76.13.0.0-76.13.255.255 98.136.0.0-98.139.255.255 209.191.64.0-209.191.127.255 216.115.96.0-216.115.111.255 216.136.172.0-216.136.255.255 # # Microsoft (Hotmail, Messenger, Skype) 23.0.0.0-23.45.0.0 23.46.0.0-23.67.255.255 54.241.30.137-54.241.32.167 63.245.215.82-63.245.215.110 63.245.217.55-63.245.217.138
  13. 13. How/TO Firewall (IPTables & Squid) 12 64.4.0.0-64.4.63.255 65.52.0.0-65.55.255.255 72.246.0.0-72.247.255.255 78.141.128.0-78.141.191.255 91.190.216.0-91.190.223.255 96.6.0.0-96.7.255.255 96.16.98.0-96.16.98.24 157.54.0.0-157.60.255.255 173.222.0.0-173.223.255.255 177.103.201.0-177.141.232.255 179.1.8.69 181.64.47.0-181.64.47.255 184.24.0.0-184.51.255.255 184.84.0.0-184.87.255.255 186.49.78.0-186.204.255.255 189.7.159.0-189.70.121.255 190.0.3.0-190.0.63.255 190.250.21.255 192.204.0.0-192.204.5.255 193.95.154.0-193.95.154.127 199.7.71.72 204.9.163.128-204.9.163.255 204.79.197.0-204.79.197.255 207.46.0.0-207.46.255.255 212.8.166.0-212.8.166.63 212.161.8.0-212.161.8.255 213.166.33.0-213.166.63.255 213.199.128.0-213.199.191.255 Nota Importante: Tenga en cuenta las direcciones ips de los servicios Bots (Google, Yahoo, Microsoft) en dependencia de si quiere autorizarlas PUEDO USAR MI SERVIDOR PROXY CONFIGURADO COMO TRANSPARENTE Y NO TRANSPARENTE A LA MISMA VEZ? Por supuesto; así puede recibir peticiones de su red local, con configuración manual o automática del proxy en el navegador web de los usuarios. Ejemplo de Squid: # Default Squid Listens to Port 3128 http_port 3128 http_port 8080 transparent Para usar ambos en el Squid debe asegurarse tener abiertos los puertos que vaya a usar como transparente y no transparente en el IPtables y redireccionarlos al Squid. Ejemplo de Iptables # ACCESO LAN AL PROXY (LAN ---> PROXY ---> INTERNET) (DEFAULT 3128 Y NAT 8080) $iptables -t nat -A PREROUTING -i $lan -p tcp --dport 80 -j REDIRECT -- to-port $proxyport $iptables -A INPUT -i $lan -p tcp --dport 8080 -j ACCEPT $iptables -A INPUT -i $lan -p tcp --dport 3128 -j ACCEPT Donde internet=eth0 (que viene de internet) y lan=eth1 (que va a la red local)
  14. 14. How/TO Firewall (IPTables & Squid) 13 NOTA: Por seguridad se recomienda cambiar los puertos del proxy por defecto, o sea 8080 y 3128. Si los cambia, asegúrese que su reemplazo no sea el mismo para ambos tipos de configuraciones y colocar los nuevos en el iptables y squid RECOMENDACIONES 1. Si va a usar algún símbolo diferente en el script de IPTables, debe agregarlo en el 'alias'. 2. Puede tener ambas reglas dentro del mismo IPtables. Solo comente la que no va a usar 3. No abuse de este tipo de filtrado colocándole demasiadas ips o rangos de ips dentro de las ACLs, ya que ralentiza el Firewall. 4. No olvide configurar el SQUID para estas reglas 5. Pack de ACLs 6. Pruebe su firewall Actualización Jun 12/2014 A partir de las versiones 13x y 14x de Ultrasurf, esta app usa un método diferente, el cual consiste en conectarse a ip válidas de servidores de Google y Amazon (y etc), muchas de estas ips publicadas en la acl https-permitidos, por tanto si bloquea estas ips, también bloqueará los servicios de Google y Amazon. Para mayor información visite el post Ultrasurf secuestra IPs de Google y Amazon Actualización Jun 28/2012 (MUY IMPORTANTE) Hemos creado una regla, para bloquear Ultrasurf 13x y 14x y otros proxys, basada en el método de Arief Yudhawarman y adaptada por Maravento Studio. También se han modificado otras reglas explicadas en este post, para mejorar el filtrado. La siguiente regla en el Iptables deberá anteponerse a la regla que abre el puerto 443 para la acl https- permitidos (tal y como se muestra a continuación). La acl que hemos usado se llama blacklist-string y está disponible para la descarga AQUI (o en el panel de descargas). A medida que salgan nuevas versiones de Ultrasurf, iremos actualizando la acl blacklist-string. A esta regla también debe antecederle una protección adicional al puerto 443. La regla ANTI-ULTRASURF deberá aplicarse dentro del script de iptables propuesto en este post, en el orden descrito. Antes de aplicar la siguiente regla deberá haber validado la entrada al firewall de las direcciones macs de su red local. Para mayor información sobre este punto, visite el post Firewall III Ejemplo de Iptables con Anti-Ultrasurf # alias (d: delete - borra lineas que tenga # seguido . por cualquier cosa *) # quitar comentarios alias sed="sed '/#.*/d'" #
  15. 15. How/TO Firewall (IPTables & Squid) 14 # ANTI-ULTRASURF for string in `sed $route/blacklist-string`; do $iptables -I FORWARD -p tcp --dport 443 --tcp-flags SYN,ACK,FIN,RST,PSH ACK,PSH -m string --to 77 --hex-string "|$string|" --algo bm -j DROP $iptables -I FORWARD -m tcp -p tcp --dport 443 -m string --to 256 --hex- string "|$string|" --algo bm -j DROP done # # ACCESO DE LA LAN AL PUERTO 443 (SOLO SE PERMITEN LAS IPS HTTPS- PERMITIDOS) for ip in `sed $route/https-permitidos`; do if echo $ip | grep "-" >/dev/null; then $iptables -A FORWARD -s $local/$netmask -o $internet -p tcp --dport 443 -m iprange --dst-range "$ip" -j ACCEPT else $iptables -A FORWARD -s $local/$netmask -o $internet -p tcp --dport 443 -d $ip -j ACCEPT fi done # CERRANDO EL PUERTO 443 $iptables -A FORWARD -p tcp --dport 443 -j DROP $iptables -A FORWARD -p udp --dport 443 -j DROP echo ok... Donde $iptables es sbin/iptables y $route es la ruta donde se encuentran la acl blacklist-string Nota: Las reglas incluidas en ANTI-ULTRASURF usan diferentes parámetros y banderas (Ej: string --to 77, --to 256, etc). Esto es con el objeto de que si no hay "match" con la primera, la búsqueda se amplíe con las reglas sucesivas. El usuario puede ampliar el rango a --to 512 o superior, si así lo considera, sin embargo por lo general es suficiente con la primera regla. Bloqueo de otros proxys, vpn, etc Las reglas anteriores + la validación por IP, son suficientes para bloquear P2P, Ultrasurf, Hotspot Shield, Tor PrivateTunnel y Freegate y no necesita realizar acciones adicionales. Para la aplicación your-freedom, además de las reglas anteriores, debe cerrar el puerto 21 y filtrar el puerto 80 en el squid. Para las aplicaciones autohide (y familia hide-ip), y similares, solamente deberá filtrar el puerto 80 como medida adicional. Para filtrar el puerto 80, agregue la siguiente regla a su squid3 acl blacklist-web dstdomain –i "/home/usuario/blacklist-web" http_access deny blacklist-web Donde blacklist-web es una acl ubicada en la ruta home/usuario (a modo de ejemplo) que contiene los sitios url a bloquear por el puerto 80, ejemplo: .proxpn.com .vpnbook.com .youtubeproxy.org .polysolve.com .unblock-websense.com .vpntunnel.net .safeforwork.net .pimpmyip.com
  16. 16. How/TO Firewall (IPTables & Squid) 15 .ninjacloak.com .24topproxy.com .sneakzorz.com .proxybutton.com .wtunnel.net .ztunnel.org .anonymouse.org .proxyweb.com.es .hotspotshield.com .securitykiss.com .your-freedom.de .your-freedom.net .your-freedom.com .autohideip.com .easy-hideip.com .hideipprivacy.com .platinumhideip.com .quick-hide-ip.com .real-hide-ip.com .superhideip.com .utrasurf.us .torproject.org .hidemyass.com .freesafeip.com .proxy.org .proxify.com .xroxy.com .anonymizer.com .blewpass.com .dontfilter.us .proxygaz.com .spys.ru .webproxy.net .webproxy.ca .webproxy.stealthy.co .webproxy.to .webproxy.hu .filterbypass.me .webproxy.uach.cl .vunblock.com .incloak.es .incloak.com .idcloak.com .prx.im .zalmos.com .freebrowsing.tecnoent.com .webproxy.tw .1proxy.de .protectproxy.com .pressfr.com .fastest-webproxy.com .proxyanonimo.es .sumrando.com .zendproxy.com .schnellster-webproxy.net .onewebproxy.com .hideme.be
  17. 17. How/TO Firewall (IPTables & Squid) 16 .webproxy.mobi .turkey.uswebproxy.com .webproxy-server.com .free-web-proxy.de .proxysite.com .webproxy.yt .hidebux.com .webproxy.ru .webproxy-service.de .japanwebproxy.com .xperienc.com .vpndeluxe.com .navegasinley.com .guardster.com .pxaa.com .mobiforge.com .free-webproxy.com .proxypy.org .my-proxy.com .webproxyusa.com .proxay.co.uk .megaproxy.com.ar .appspot.com .netherlandsproxy.co.nl .paperproxy.net .studysurf.com .hideproxy.nu .proxysites.tn .poxy.info .web.leue.biz .unblockyoutube.xyz .extraproxy.com .proxyus.nu .crownproxy.com .unblocksite.xyz .surf-proxy.smoz.us .iproxy.xyz .crazyproxy.xyz .rapidserver.nu .safeunblock.com .yamoontech.com .shcool.vf1.us .fast.ynna.biz Sin embargo, como la lista es muy extensa y todos los días salen nuevos webproxies, anonimizadores y listados de Free Proxy, se recomienda crear una regla en el Squid3 tipo url_regex para bloquear expresiones relacionadas con este tipo de filtrado; ejemplo: acl blacklist-webproxies url_regex -i "/home/usuario/blacklist-words" http_access deny blacklist-words Dentro de la acl blacklist-words puede poner palabras como sex, proxy, porno, anonymous, socks proxy y todas aquellas que considere deben ser bloqueadas. Si en alguna parte de la url se encuentra alguna de estas palabras, squid bloqueará la petición.
  18. 18. How/TO Firewall (IPTables & Squid) 17 Para descargar packs "blacklist" visite el post Firewall IV. Para completar el filtrado, bloquee las peticiones a ips por el puerto 80 en el Squid (y solo permita peticiones urls de su red local y una acl Whitelist con ips que quiera no filtrar). Lo anterior es debido a que ultrasurf, SecurityKiss Tunel, Easy Hide IP (y familia hide-ip), etc p), etc, hacen peticiones al puerto 80, y los Free o Anonymous Web proxy. # squid.conf Denegar todas las peticiones a ips (solo url) acl whitelist-ips src "/home/usuario/whitelist-ips" acl no_ip dstdom_regex ^[0-9]+.[0-9]+.[0-9]+.[0-9]+$ http_access deny no_ip !whitelist_ips Luego puede crear una acl para las macs de su red local que quiera permitirles el acceso a ciertos puertos (Ej: 443, 21, 22) # ACCESO PRIVILEGIADO A CIERTOS PUERTOS(ALC MACS-ESSENTIAL) for mac in `sed $route/macs-essential`; do $iptables -A FORWARD -m mac --mac-source $mac -p tcp -m multiport -- dports 443,21,22 -o $internet -j ACCEPT done Autorice los puertos de trabajo de su red local (sin incluir los puertos autorizados arriba) y cierre. # LAN ---> INTERNET # ACEPTAR CONEXIONES A PUERTOS HTTP, FTP, DNS, POP3, SMTP !HTTPS, SSH, FTP $iptables -A FORWARD -s $local/$netmask -i $lan -p udp -m multiport -- dports 25,53,110 -o $internet -j ACCEPT $iptables -A FORWARD -s $local/$netmask -i $lan -p tcp -m multiport -- dports 80,8080,53 -o $internet -j ACCEPT # DENEGAR EL RESTO $iptables -A FORWARD -s $local/$netmask -i $lan -o $internet -j DROP Y después de poner todas las reglas de su preferencia, no olvide cerrar parcialmente el script echo Drop All... $iptables -A INPUT -s 0.0.0.0/0 -j DROP También puede bloquear los servicios de Google Translate Para mayor información sobre cómo usar Google como proxy visite el post visite el post Usar Google como un proxy para entrar a páginas censuradas. Recomendaciones para el script de Iptables 1. Establecer en lo posible una política de cero tolerancia. por defecto DROP 2. Que tenga como política permitir solo las ips https autorizadas y bloquear el resto 3. No abusar de la regla "string" propuesta (incluyéndole otros hexadecimales en la acl blacklist-string para realizar bloqueos a sitios o descargas), ya que este tipo de reglas lo que hacen es capturar todo el tráfico (443) y revisar una por una las peticiones y respuestas, y si alguna coincide con los hexadecimales incluidos en la acl blacklist-string se aplica el DROP (caso contrario lo deja pasar). Dicha revisión es mucho más exhaustiva (en comparación con una regla que solamente valida si la ip https solicitada/recibida se encuentra en la acl https-permitidas),
  19. 19. How/TO Firewall (IPTables & Squid) 18 entonces si hay demasiados hexadecimales en la acl blacklist-string, su firewall se ralentizara al extremo que se puede detener. Medidas adicionales Recomendamos proteger las peticiones a los puertos 80 y 443 con la siguiente regla que deberá ubicarse en el Iptables antes que la de https-permitidos y anti- ultrasurf y similares (active el módulo connlimit en la cabecera de su Iptables: modprobe xt_connlimit) # PROTECTION RULES # Permitir conexiones 443 (3 por host) $iptables -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit- above 3 -j DROP # Proteger el puerto 80 $iptables -I INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 30 -j DROP ...Continúa en Firewall II
  20. 20. How/TO Firewall (IPTables & Squid) 19 Firewall II En el post anterior Firewall explicamos la manera de bloquear las conexiones de tipo HTTPS no autorizadas usando una regla, sin embargo, ésta por sí sola no impide el acceso al HTTPs a usuarios no deseados, ya que su única función es validar o denegar las IPs contenidas dentro de ACL usada según el caso, pero no discrimina cuáles usuarios pueden hacer peticiones HTTPs y cuáles no. Puede ocurrir que un fulano de tal, no autorizado, haga peticiones (desde dentro o fuera de nuestra red local) a sitios HTTPs contenidos en la ACL citada en el artículo anterior, por lo tanto podrá navegar sin problemas. Peor aún; un hacker irrumpe en nuestra LAN, (ya sea por un ataque por fuerza bruta descifrando la clave del WIFI, usando software de penetración como Backtrack, Beini, Wireless Key View, etc, o logra acceso físico a uno de los equipos de nuestra red o cibercafé y copie la clave WIFI en la configuración de red de los terminales Windows. En este caso el chico malo tendrá acceso a gmail, hotmail, yahoo o a cualquier IP registrada en la ACL https-permitidos, con tan solo agregarle una "s" a su petición http://. Para evitarlo hay que aplicar niveles de seguridad en el servidor; o sea blindar el firewall IPTABLES. TABLA MANGLES MANGLES es una de las tantas alternativas que existen para hacer más seguro el acceso a nuestra red. De acuerdo a la estructura misma del IPTABLES, lo primero que aparece es la tabla MANGLES. Esta se encarga de modificar los paquetes de Internet y es precisamente en este punto cuando podemos establecer los usuarios que vamos a autorizar a recibir o enviar paquetes dentro de nuestra red, sin importar que sus peticiones sean http o https, ftp, etc. Un filtrado con MANGLES se logra creando una simple regla que hace dos cosas: 1. Solo permite el acceso a Internet y a los recursos de nuestra LAN a las MACs previamente seleccionadas por el administrador TI, que registre en una ACL.
  21. 21. How/TO Firewall (IPTables & Squid) 20 2. Denegar el resto de las conexiones (corta literalmente las comunicaciones al resto) De esta manera es más fácil controlar los equipos que hacen uso de nuestros recursos en la red y por ende el filtrado de HTTPs descrito en el post Firewall, sería más fácil de aplicar. NOTA: Consulte las variables de la cabecera del IPTables en Firewall Ejemplo del uso de MANGLES en el IPTABLES, visto en Firewall: # SOLO PETICIONES DE LA LAN for mac in `sed $route/macs-* | tr '[A-Z]' '[a-z]' | sort -u`; do $iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -j ACCEPT done $iptables -t mangle -A PREROUTING -i $lan -j DROP Con esta regla limitamos el acceso a nuestra red a un puñado de MACs establecidas previamente en las ACLs creadas por el administrador TI. El resto de las MACs que logren entrar a nuestra red local, simplemente no tendrán conectividad ni acceso a ningún recurso. Pero a pesar de que esta regla es muy efectiva, solo considera las macs autorizadas, mas no realiza ningún "amarre" entre Host+IP+Mac. Para poder elevar el nivel de seguridad, lea nuestra próxima entrega Firewall III. ESTABLECIENDO HORARIOS Supongamos ahora que el administradores TI quiere hacer una discriminación. Un grupo de computadores de nuestra red tendrá acceso a Internet 24/7 y a los sitios establecidos en la ACL https-permitidos (o como quieran llamarle), sin embargo el otro grupo no tendrá Internet salvo en un horario predefinido y solo tendrá acceso a ciertos recursos de la red en ese horario (Ejemplo: carpetas compartidas desde el servidor, impresión, sistema de mensajería interna, etc). Para este grupo limitado, hay que poner de primero la regla MANGLES, antes que cualquier otra regla del IPTABLES e irle validando los puertos que queremos que tengan acceso y cerrarles el resto. El administrador TI es quien debe valorar qué recursos les otorga a sus usuarios (abriendo o cerrando puertos y bloqueando sitios y recursos) dentro de su red LAN. El siguiente ejemplo se abren solamente los puertos 53 (consulta DNS), 80 (internet), 8080 (proxy) 137, 138, 139 y 445 (samba - archivos compartidos con redes windows). Para efectos de este ejemplo llamaremos a la ACL macs-limitadas. Aquí se le aplicará un horario especial a esta ACL y las restricciones estarán sujetas a este horario. Las restricciones consisten en un bloqueo general y la validación de algunos puertos. Una vez terminado el horario, se levantarán las restricciones impuestas. Se recomienda que se programe esta tarea en el Crontab (/usb/bin/crontab) para que se ejecute de manera desatendida y automáticamente. También se incluyen especificaciones adicionales y las reglas descritas en la primera parte Firewall para una mayor comprensión de los pasos.
  22. 22. How/TO Firewall (IPTables & Squid) 21 Primero debe establecer en la cabecera del IPtables el horario (Ajústelo en dependencia de sus necesidades # horario (formato 24h) route=/home/usuario/acl hora_actual=$(date +%H) hora_permitida=12 hora_ilimitada=16 Uso de MANGLES para aplicarle restricciones a un grupo de equipos de la red LAN en un horario determinado. # TABLA/CADENA: -t mangle -A PREROUTING (INTERNET-2-LOCALHOST) # BLOQUEAR HTTPS A MACS-LIMITADAS SI NO ES LA HORA PERMITIDA Y ABRIR PUERTO HTTP PARA ERROR (BLOQUEO SQUID) if [ $hora_actual -lt $hora_permitida ]; then echo bloqueando https para macs-limitadas for mac in `sed $route/macs-limitadas`; do $iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -p tcp -m multiport --dports 80,3128,139,445 -j ACCEPT $iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -p udp -m multiport --dports 53,137,138 -j ACCEPT $iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -j DROP done fi Otro ejemplo es cuando permite solo la entrada a las direcciones mac de nuestra red local, previamente seleccionadas # SOLO PETICIONES DE LA LAN for mac in `sed $route/macs-* | tr '[A-Z]' '[a-z]' | sort -u`; do $iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -j ACCEPT done $iptables -t mangle -A PREROUTING -i $lan -j DROP O cuando las trabajamos con el DHCP (Se profundizará en este punto en entregas posteriores de Firewall) # SOLO PETICIONES DE LA LAN create_acl $mac2ip $iptables -t mangle -A PREROUTING -i $lan -j DROP MANGLES es de gran ayuda, pero no servirá de mucho si la política es demasiado flexible. Habría que implementar un nivel mucho más alto de seguridad y aplicar protecciones adicionales, que se describirán en el próximo capítulo. ... Continúa en Firewall III.
  23. 23. How/TO Firewall (IPTables & Squid) 22 Firewall III Actualizado Mar 29/2014 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.
  24. 24. How/TO Firewall (IPTables & Squid) 23 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.
  25. 25. How/TO Firewall (IPTables & Squid) 24 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.
  26. 26. How/TO Firewall (IPTables & Squid) 25 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.
  27. 27. How/TO Firewall (IPTables & Squid) 26 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. SNIFEANDO 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 HOST+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.
  28. 28. How/TO Firewall (IPTables & Squid) 27 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 y 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 Host+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,
  29. 29. How/TO Firewall (IPTables & Squid) 28 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 Host+Mac+IP en el archivo de configuración de DHCP. Nota: a. Nos parámetros propuestos, rangos de red, leases, dns, host + 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" Configuración 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 host CLIENTE1 { hardware ethernet e0:ca:94:a7:xx:xx; fixed-address 192.168.1.100;
  30. 30. How/TO Firewall (IPTables & Squid) 29 } host CLIENTE2 { hardware ethernet 00:14:d1:d5:xx:xx; fixed-address 192.168.1.101; } # Bloqueando 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 parametros del servidor 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 Host+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 Host+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.
  31. 31. How/TO Firewall (IPTables & Squid) 30 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
  32. 32. How/TO Firewall (IPTables & Squid) 31 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.
  33. 33. How/TO Firewall (IPTables & Squid) 32 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/ # Yago Jesus http://www.securitybydefault.com/ # 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=/home/usuario/acl proxyport=8080 netmask=255.255.255.0 # RUTA dhcpd.conf #dhcp_conf=/etc/dhcp3/dhcpd.conf # para dhcp v3.x dhcp_conf=/etc/dhcp/dhcpd.conf # para dhcp v4.x #
  34. 34. How/TO Firewall (IPTables & Squid) 33 mac2ip=$(sed -n '/^s+hardware|^s+fixed/ s:hardware ethernet |fixed- address ::p' $dhcp_conf | sed 's/;//') # RUTA ips_dhcp/macs_dhcp path_ips=/home/usuario/acl/ips_dhcp path_macs=/home/usuario/acl/macs_dhcp # alias alias sed="sed '/#.*/d'" ############### # 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 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="$ipsn$ip" macs="$macsn$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...
  35. 35. How/TO Firewall (IPTables & Squid) 34 # 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
  36. 36. How/TO Firewall (IPTables & Squid) 35 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 $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 /home/usuario/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.
  37. 37. How/TO Firewall (IPTables & Squid) 36 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 $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 macs-limitadas arp "/home/usuario/acl/macs-limitadas" acl horario_tarde time MTWHF 14:00-23:59 acl fin_de_semana time SA 00:00-23:59 acl lunes-a-viernes time MTWHF 18:00-23:59 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
  38. 38. How/TO Firewall (IPTables & Squid) 37 http_access deny blacklist-ips http_reply_access deny archivos-bloqueados http_access deny extensiones http_access allow fin_de_semana macs-permitidas http_access allow lunes-a-viernes macs-permitidas http_access allow fin_de_semana macs-limitadas http_access allow horario_tarde macs-limitadas 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 AQUI 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), Solarwinds, Nagios, entre otras.
  39. 39. How/TO Firewall (IPTables & Squid) 38 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, pero si quiere el nivel más alto de seguridad, lo más recomendado es Secure Virtual Cloud (Entornos Virtuales Seguros) o SVC o un túnel virtual (VPN) Este y otros temas serán tratado con mayor profundidad en próximas entregas de la serie Firewall. ... Continúa en Firewall IV
  40. 40. How/TO Firewall (IPTables & Squid) 39 Firewall IV En los posts anteriores Firewall, Firewall II y Firewall III, abordamos temas relacionados con el control HTTPS usando el IPtables, para frenar el acceso a programas y sitios que usan el puerto de seguridad 443, conocido como puerto HTTPS. También explicamos el uso de la tabla MANGLES y restringir el acceso de equipos no autorizados a nuestra red local de datos, entre otras reglas, pero solucionar del filtrado HTTPS via IPTables, o amarrar IP+Host+Mac no significa que todo está resuelto. Hay mucho Black Traffic que circula por el puerto 80 (HTTP), el cual puede ser filtrado por el Squid. Squid es uno de los software tipo proxy más usados en la actualidad y es capaz de filtrar múltiples protocolos, pero, para el caso del proxy cache transparente, Squid no procesa peticiones al puerto de seguridad 443 en modo transparente (Vea Firewall); pero sí procesa el resto del tráfico por el puerto 80. Ver tutorial de instalación de Squid para Linux y Windows FILTRANDO BLACKTRAFFIC El Administrador TI debe determinar que sitios debe bloquear y cuales no y crear una ACL que contenga estos portales restringidos para su red local, sin embargo, (tal y como sucedía con las IPs de HTTPS en el artículo Firewall) son incontables los sitios de descargas, de contenido adulto xxx, etc, etc. Cómo bloquear millones de IPs y URLs con contenido no deseado... Si bien este trabajo es arduo para el Administrador TI, existen sitios que ofrecen ACLs Blacklists. Lo único que hay que hacer es descargarlas, colocarlas en una carpeta y agregarle al Squid las reglas de filtrado correspondiente, indicándole la ruta de las ACLs. Estas ACLs pueden representar el 80% de los portales e IPs que el Administrador TI necesita bloquear. El restante 20% serán aquellas específicas que el
  41. 41. How/TO Firewall (IPTables & Squid) 40 Administrador TI haya recopilado y que no se encuentren en las ACLs ofrecidas en estos "big packs blacklists". El tema de los monitores será profundizado en la próxima entrega Firewall V SUPERPACKS BLACKLISTS Estos sitios especializados ofrecen Packs de ACLs Blacklists con Black Traffic. La ventaja es que los creadores las actualizan permanentemente, lo cual es un ahorro de tiempo considerable para el Administrador TI. He aquí algunos de ellos: En Squidguard puede encontrar una relación de sitios que ofrecen las ACLs Blacklists Capitole.fr (Free): Puede elegir las ACLs Blacklists de manera individual y descargar la que necesite (o descargarlas todas). SquidBlacklists (Pago): Ofrece ACLs Blacklists para diversos usos. URLBlacklists (Free y Pago): Descarga limitada. Viene configurado para dansguardian. Tiene un Script para hacer las actualizaciones automáticas. Puede descargarlo AQUI. Debe instalar Dansguardian primero. Shallalist (Free): Colección de listas de URLs, similar a las anteriores, con la ventaja que tiene un script para su instalación en el Squid. Ver Howto AQUI y DD AQUI MESD (Free): Un paquete de Blacklists más pequeño pero igual de efectivo. Maravento's Extended Blacklists MEB (Free): Incluye una recopilación de muchas ACLs citadas en el How/TO de Firewall. La descarga se encuentra disponible dentro de un pack llamado SuperPack-Blacklists (SPB), el cual también recopila todas las ACLs de los sitios aquí descritos, en un solo enlace. Descarga SuperPack-Blacklists (SPB) Configurando Squid Supongamos que hemos descargado una ACL con URLs de sitios con contenido para adultos (porno) y otra de sitios prohibidos de descargas. Ahora vamos a ponerlas en el Squid y a activarlas. A modo de ejemplo las ubicaremos en una carpeta en la siguiente ruta: /home/usuario/acl/porno Sustituya usuario por tu-usuario. Editando squid.conf sudo /etc/squid/squid.conf o sudo /etc/squid3/squid.conf Inserte las siguientes reglas # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS acl webserver src 192.168.1.0/255.255.255.0 acl porno dstdomain -i "/home/usuario/acl/porno" acl descargas dstdomain -i "/home/usuario/acl/descargas" Y actívelas # Don't upgrade ShoutCast responses to HTTP acl apache rep_header Server ^Apache http_access allow manager localhost
  42. 42. How/TO Firewall (IPTables & Squid) 41 http_access allow manager webserver http_access deny manager http_access allow purge localhost http_access deny purge http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access deny porno http_access deny descargas http_access allow localhost http_access deny all upgrade_http0.9 deny shoutcast Pueden seguir agregando reglas de filtrado con ACLs, por ejemplo, que prohíban las descargas de archivos vía HTTP (exe, mp3, mp4...) y solo dejar pasar pdf, xls, doc, etc. También se puede exceptuar las reglas para determinado grupo privilegiados de terminales dentro de la red local, los cuales deben estar también dentro de una ACL (macs-privilegiadas). # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS acl archivos-bloqueados rep_mime_type -i "/home/usuario/acl/archivos- bloqueados" acl extensiones url_regex "/home/usuario/acl/extensiones" Y luego... # Don't upgrade ShoutCast responses to HTTP http_reply_access allow macs-privilegiadas archivos-bloqueados http_access allow macs-privilegiadas extensiones http_reply_access deny archivos-bloqueados http_access deny extensiones EFECTO DOMINÓ Primero que todo hay que establecer que en un proxy server, que tenga Squid e Iptables "filtrando" el tráfico de nuestra red local, el tráfico primero llega al servidor y ahí se produce el filtrado, no antes ni después, por tanto no importará que tengamos el IPtables en DROP, ya que ante un ataque DDOS, al no haber nada protegiendo a nuestro Servidor Proxy, el ataque llegará y con toda seguridad el servidor caerá. Ante esto, muchos se preguntarán: ¿Si usamos un servidor para proteger nuestro servidor, quién protege al primer servidor y así sucesivamente?.. Un servidor tras otro, protegiendo siempre al anterior; y si "el último" es atacado, cae el resto como fichas de dominó. El hecho de tener muchos servidores, firewalls dedicados y otros equipos perimetrales protegiendo nuestro servidor proxy y bases de datos, no garantiza que un ataque no llegue al núcleo de nuestra red local. Todo radica en la estrategia de defensa y no en la cantidad de equipos.
  43. 43. How/TO Firewall (IPTables & Squid) 42 Existen varios tipos de ataques contra la infraestructura informática. En dependencia de su origen, tenemos los Externos (Outside), cuando vienen desde fuera de nuestra red local y los Internos (Inside), los se producen desde nuestra propia infraestructura, incluyendo nuestros servidores. También están los Directos e Indirectos (client-side attacks), basados en la forma del ataque. Puede leer sobre ellos en el portal thehackerway.com. El más popular de los "Externos" es el de 'Denegación de Servicios' o (DoS o su variante DDos). Hay mucha documentación en Internet sobre estos ataques. Entrar en detalles sería muy extenso, pero puede consultar su funcionamiento AQUI y verlo en acción en un video publicado por la revista Enter. Garantías... Ninguna. Hay que partir de la base que no existen soluciones 100% garantizadas. Todos son paños de agua tibia para un mal que crece cada día. Hay muchos "intentos", que van desde balancear las cargas con clusters (pool de servidores), rogarle a los ISP que ponga filtros para bloquear el Black Traffic, disminuir el tamaño de la pila TCP o un delay en el establecimiento de conexiones, hasta firewall dedicados por hardware o software, etc, etc... Sin embargo, si el ataque DDoS es superior a 1TB/s no lo para ni la NASA... (a no ser que apaguen los Backbones, Datacenters, Nodos, Botnet, Puntos Neutros, Tiers (Tier1 y Tier2) y demás puntos por donde circula el tráfico del ataque DDoS). Ejemplo de ataque DoS mediano: Una “botnet” tiene 3000 máquinas zombies. Cada máquina utiliza una conexión hogareña (generalmente xDSL) con un promedio de 128 Kib/s de ancho de banda de subida (upstream). 3000 hosts * 128 KiB/s (upstream) = 384000 KiB/s = 375,00 MiB/s, el cual es suficiente para hacer caer cualquier sistema de rango medio. Pero no debemos quedarnos con los brazos cruzados y ver cómo caen como moscas nuestro servidores. La mejor manera de protegernos hasta la fecha es aplicando un sistema de seguridad por capas (o niveles), que van desde la protección física primaria de la infraestructura informática, hasta el uso del sentido común. He aquí algunas soluciones: Gestión Unificada de Amenazas (UTM Unified Theat Management) Es un Firewall avanzado que engloba múltiples funcionalidades, tales como Firewall, UDP, VPN, Antiphishing, Antispyware, Filtro de contenidos, Antivirus, Detección/Prevención de Intrusos (IDS/IPS), control de aplicaciones, acceso móvil, prevención de fuga de datos, información de la identidad, filtrado URL, Web, antibots, antispam & correo electrónico, read & clustering avanzados, software de emulación de amenazas, etc, etc, etc. Hay una variedad de empresas que suministran este tipo de soluciones integradas tales como IBM Firewall, Checkpoint Firewall o Stonesoft, (certificadas por ICSLABS), pero son productos muy costosos y requieren de soporte
  44. 44. How/TO Firewall (IPTables & Squid) 43 permanente. Hay alternativas Open Source, como Open UTM, pero aún está en fase de desarrollo. Lectura recomendada: Seguridad Perimetral, UTM Escudo de Red (NetShield o Network Shield) Es la primera línea de defensa de tipo perimetral. Se define como un conjunto de técnicas y herramientas (integradas o independientes), de hardware y software, que vinculadas (o por separado) brindan la primera protección a una infraestructura informática. Puede estar conformada por sistemas IDS/IPS, uno o varios servidores (clusters) y diferentes tipos de hardware de red y equipos de comunicaciones, Firewalls, UnitSystemBox, proxy inverso, etc, en dependencia del esquema de protección que se pretenda brindar. Su único objetivo es rechazar el Black traffic (Tráfico no deseado) hacia nuestras redes y solo dejar pasar el White Traffic (Tráfico solicitado), por lo que se convierte en un esquema ideal para blindar nuestros servidores locales de ataques, en especial los DDoS. He aquí algunos ejemplos de herramientas usadas en un Escudo de Red: DDOS Deflate: Un script de bash bastante efectivo para mitigar ataques DoS y DDoS pequeños y medianos, y muy útil en escenarios donde el servidor proxy solo se usa para filtrado de la red local y otros usos internos, y para pequeñas y medianas empresas y centros educativos. Requerimientos Conexión a internet para descargar el script y APF (si queremos usar que las IP´s sean baneadas a traves de APF). Este script se mantiene ejecutando en el servidor y puede detectar los ataques o conexiones originados desde múltiples direcciones IPs, mediante; netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n Instalación wget http://www.inetbase.com/scripts/ddos/install.sh chmod 0700 install.sh ./install.sh Desinstalación wget http://www.inetbase.com/scripts/ddos/uninstall.ddos chmod 0700 uninstall.ddos ./uninstall.ddos Configuración Edite el archivo de configuración: /usr/local/ddos/ddos.conf Con los siguientes parámetros: FREQ= "aquí ponemos la frecuencia en la que el O.S ejecuta dicho script en minutos" //Default =1 NO_OF_CONNECTIONS= "conexiones límites para una IP entrante al servidor" //Default =150
  45. 45. How/TO Firewall (IPTables & Squid) 44 APF_BAN= "Si es igual a uno (1) se usará APF, sino lo tienes instalado, cámbialo por cero (0) para usar iptables" //Default =1 KILL= "Deniega la conexión a IPS de lista Negra" //Default =1 EMAIL_TO= "aquí ponemos el email a donde se nos enviaran las ips atacantes" //Default =root BAN_PERIOD= "segundos de banneo tras realizar un ataque al servidor" //Default =600 Podría ser necesario cambiar la línea shebang de /bin/sh a /bin/bash en ddos.sh para que la primera línea quede como #!/bin/bash. Así mismo recomendamos instalar APF ya que es mucho más preciso que mod_dosevasive/mod_evasive. Para excluir IPs, incluyalas en el archivo ignore.ip.list /usr/local/ddos/ignore.ip.list Luego agregue el servicio al cron sh /usr/local/ddos/ddos.sh -c La entrada del cron job se añade en /etc/cron.d con el nombre ddos.cron SHELL=/bin/sh 0-59/1 * * * * root /usr/local/ddos/ddos.sh >/dev/null 2>&1 Si el script detecta una ip atacante nos enviará un e-mail root: administrador@maravento.com Asunto “IP addresses banned”, con los datos de la ip baneada (fecha, ip, número de conexiones) IP addresses banned on Mon Jan 25 10:30:09 CET 2014 Banned the following ip addresses on Mon Jan 25 10:30:09 CET 2014 xxx.xxx.xxx.xxx with 212 connections Para mayor información visite RinconLejano APF y BFD: También están los scripts APF (Políticas Avanzadas de Firewall) y BFD (Detección de Fuerza Bruta), que refuerzan a DDoS Deflate. Puede descargar el pack antiDDoS desde nuestra nube, el cual contiene DDos Deflate, APF y BFD. Para DDoS Deflate modifique el instalador para que busque los scripts dentro de una carpeta del pack antiDDoS. Puede ver su configuración AQUI Otros scripts para protegerse de ataques DDOS basado en IPTables es el de Ruslan Abuzant y el de Citadel (similar a DDoS Deflate) Reverse Proxy: Otra buena medida es un Proxy Inverso (Reverse Proxy). Un servidor proxy-caché pero "al revés". O sea, en lugar de permitir el acceso a Internet a usuarios internos, permite a usuarios de Internet acceder indirectamente a determinados servidores internos. El Reverse Proxy, en vez de de bloquear las peticiones entrantes, trata consigo mismo. Esta estrategia ofrece una seguridad mucho más fuerte que un firewall tradicional, ya que un firewall comprueba la estructura del paquete de fuentes sospechosas de conexiones y lo deja pasar o lo rechaza, en dependencia de las reglas que tenga predeterminadas, pero el tráfico llega hasta el servidor y ahí se produce el filtrado; en cambio, el Proxy Inverso impide que la conexión no
  46. 46. How/TO Firewall (IPTables & Squid) 45 autorizada logre llegar al servidor de destino. Esto elimina cualquier posibilidad de un virus o spyware en el servidor. En este orden de ideas, un proxy-inverso protege a un proxy-caché (o a cualquier otro proxy que tengamos en la red local). Tutoriales Cómo configurar un Proxy Inverso con Apache, y Qué es Reverse Proxy y cuándo usarlo? Fail2ban y DenyHOST: De las mejores herramientas que han mostrado resultados efectivos en la prevención y supervisión de ataques por fuerza bruta (Tutorial Eng y Esp). Puede verlos juntos trabajando y con asterisk. ARPon: De las mejores herramientas para impedir ataques por envenenamiento de la caché ARP (ARP Spoofing/Flooding/Poisoning or (ARP Poison Routing)) y MITM. No necesita de conocimientos avanzados para su configuración. Vea el Tutorial de instalación en Ubuntu rkhunter: Un verificador de rootkits (mucho más completo y potente que chkrootkit). Se encarga de verificar el sistema de nuestro servidor por comparación de hashes MD5, búsqueda por archivos comunes usados por rootkits, permisos equivocados para binarios, búsqueda por cadenas de texto sospechosos en módulos LKM (Loadable Kernel Modules) y KLD (Kernel Loadable Device); búsqueda de archivos ocultos; opciones de escaneo dentro de archivos binarios y planos, etc. (Tutorial de instalación AQUI) Hay ataques más peligrosos que el DDoS, que se desencadenan en nuestra red local y servidores, ya sea originado por un malware, una aplicación, u otro tipo de amenazas, en ocasiones casi imposibles de controlar por la proximidad teórica con el núcleo de la red. Para blindar los puntos neurálgicos de la red local (servidores, bases de datos, etc) se debe contar con una protección adicional, más allá del Squid y el Iptables. En otras palabras, hay que evitar que el Black Traffic llegue a nuestro servidor principal, sin importar de donde venga. Para esto se pueden implementar medidas adicionales de seguridad perimetral. Dos de las más usadas son SELinux y AppArmor SELinux: (del inglés Security-Enhanced Linux, Linux con Seguridad Mejorada) (Wiki) es un proyecto de la Agencia de Seguridad Nacional (NSA) de los Estados Unidos y de la comunidad SELinux. Es una característica de seguridad de Linux que provee una variedad de políticas de seguridad, incluyendo controles de acceso a través del uso de módulos de Seguridad en el núcleo Linux. No es una distribución de Linux, sino un conjunto de modificaciones que puede ser aplicado a un sistema tipo Unix (como Linux y BSD). Por tanto activar este módulo es vital para proteger internamente nuestros servidores. AppArmor: Fue creado en parte como alternativa a SELinux, que era criticado por los administradores por ser demasiado difícil de instalar y mantener. Al contrario que SELinux, que se basa en añadir etiquetas a los archivos, AppArmor trabaja con las rutas de los ficheros. Según sus autores, AppArmor es menos
  47. 47. How/TO Firewall (IPTables & Squid) 46 complejo y más fácil de aprender a utilizar para un usuario medio que SELinux. Añaden además que AppArmor necesita realizar pocas modificaciones en el sistema de ficheros mientras que SELinux necesita un sistema de ficheros que soporte sus atributos extendidos, lo que implica que no pueda controlar el acceso a archivos montados vía NFS. Con AppArmor no importa en qué clase de sistema de ficheros estén montados los archivos. Lea los posts: Habilitando y Deshabilitando SELinux en Fedora, SELinux Teoría, Introducción a SELinux, Secure Ubuntu With AppArmor, Armado y protegido Hay otras alternativas que ayudan a proteger el núcleo de nuestra red; entre ellas: Systrace: Un sistema diseñado para "enjaular" las app que intenten correr en el servidor. Sandboxes o Entornos de prueba: Similar a Systrace, con la diferencia que prueba las aplicaciones en un entorno virtual antes de dejarla ejecutar en el entorno real. Secure Virtual Cloud (SVC es una plataforma completamente virtual (Open Source). Su función principal es correr todo tipo de tráfico cliente-servidor por la plataforma virtual en la nube, incluyendo sistemas operativos, aplicaciones, comunicaciones, transporte de datos, ejecutar archivos y programas, sistemas virtualizados, etc, con el objeto de que si se produce un daño por malware, ataques informáticos, aplicaciones corruptas, o factor humano (mal uso), simplemente se reemplaza el sistema completo (o el segmento virtual afectado), por otra plataforma en limpio, de manera transparente y transparente, sin que afecte ningún servicio, programas, ni comprometa los datos de la red local y usuarios. Esto se logra gracias a que tiene la capacidad de autoclonarse de manera incremental, según la programación del Administrador TI. Tampoco se afecta la seguridad, ya que posee un sistema de encriptación militar, siendo la encriptación de la capa de transporte la mejor alternativa en la actualidad. Si bien los sistemas actuales de encriptación y los números aleatorios has sido fuertemente cuestionados por tener supuestos backdoors (incluso Linux ha caído en desgracia ante la posibilidad de estar penetrado por la NSA) la batalla por la privacidad no está perdida. En el caso de los sistemas basados en SVC, se crean tramas de datos conocidas como "jarra de miel" (honeypot); o sea de introduce dentro del tráfico habitual codificado un volumen considerable de "datos no relacionados con los reales", para que el atacante, en el supuesto caso que logre burlar la seguridad perimetral y entre al túnel, tarde años en "armar el rompecabezas", ya que la criptografía usada para proteger el tráfico real está basada en números aleatorios que se generan por una combinación de software y hardware (externo e interno), sin el patrón definido del chip y RDRand de Intel o la "piscina de entropía" de Linux. EL FIN JUSTIFICA LOS MEDIOS La única manera de saber realmente si nuestro trabajo de protección sirve de algo es haciéndole una auditoria. En otras palabras, bombardear nuestra defensa

×