marzo 14, 2013

Firewall

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 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 altamente 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 No-Transparente (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).
Si elegimos un Proxy Cache (3128) sin la cláusula transparent o intercept (depende de la versión), 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 los navegadores web de todos los equipos de su red local para que apunten a la ip del proxy y al puerto, bien sea usando el protocolo WPAD (lo cual no es muy recomendado por su vulnerabilidad) o manualmente.
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 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... En fín; otra pérdida de tiempo.
Sin embargo hay algo que podemos hacer y es ofrecer lo mejor de ambos mundos y obtener un buen resultado bastante satisfactorio. En otras palabras, podemos establecer un Proxy 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
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.
Tenga en cuenta que el filtrado IP a través del firewall, que a continuación se describirá, demanda grandes cantidades de recursos de servidor. Uselo a discresión.
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'.
~$ 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
#!/bin/bash
### BEGIN INIT INFO
# Provides:          iptables
# Required-Start:    $remote_fs $syslog $network
# Required-Stop:     $remote_fs $syslog $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       iptables for gateproxy.com
# Written:           Maravento.com and Novatoz.com
# Ejecute root:      chmod +x /etc/init.d/iptables.sh
# Verifique con:     iptables -L -n o iptables -nvL
# verifique puertos: /etc/services
### END INIT INFO
#-------------------------------------------------------
echo IPTABLES FIREWALL START...

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

echo Load Firewall Rules...

internet=eth0
lan=eth1
local=192.168.1.0
iptables=/sbin/iptables
ip6tables=/sbin/ip6tables
route=/etc/acl
proxyport1=3128
proxyport2=8080
netmask=24
# reemplace los DNS por los de su ISP
DNS1=8.8.8.8
DNS2=8.8.4.4
# reemplace la mac de administrador
sysadmin="00:00:00:00:00:00"

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

# Preload required kernel modules
# modules (consulte con lsmod)
modprobe=/sbin/modprobe
arp=/usr/sbin/arp
# Adicional modules
sysctl=/sbin/sysctl
rmmod=/sbin/rmmod
lsmod=/sbin/lsmod
depmod=/sbin/depmod
grep=/bin/grep
awk=/usr/bin/awk

# modprobe
# ls /lib/modules/*/kernel/net/*/netfilter/
$modprobe ip_tables
$modprobe iptable_nat
$modprobe iptable_mangle
$modprobe iptable_filter
$modprobe ipt_REJECT
$modprobe nf_nat
$modprobe nf_conntrack
$modprobe ip_conntrack_irc
$modprobe nf_conntrack_ipv4
$modprobe nf_conntrack_ftp
$modprobe xt_connlimit
$modprobe ipt_recent
$modprobe xt_NFLOG

# Activar ip forward rules. Ponga el resto de las reglas en /etc/sysctl.conf
# Para mayor informacion, visite https://klaver.it/linux/sysctl.conf
echo 1 > /proc/sys/net/ipv4/ip_forward

echo ok
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  
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
o
sudo apt-get install squid
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 intercept
Diferencia entre distros de Linux
IPtables difiere en cada versión de Linux. Lea el post de Nico Schottelius para solucionarlo. Tenga en cuenta a la hora de configurar su iptables, el error de squid3 No forward-proxy ports configured
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.
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 httpspermitidos y httpsbloqueados 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 httpspermitidos. El resto de las peticiones https se rechazan.
Caso 2: DENEGAR CONEXIÓN
Solo se niegan las IPs incluidas en la ACL httpsbloqueados. 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 '/#.*/d' $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 HTTPSPERMITIDOS)
for ip in `sed '/#.*/d' $route/httpspermitidos`; 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 HTTPSBLOQUEADOS)
#for ip in `sed '/#.*/d' $route/httpsbloqueados`; 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 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 -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 '/#.*/d' $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 '/#.*/d' $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 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 httpspermitidos, 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 basadas en "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. Ejemplo:
nslookup google.com
dig +short google.com
host -t a google.com
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 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.
Sin embargo, si conseguir todas las IPs que necesita para validar su entrada se convierte en algo tedioso, ya que pueden ser cientos, o tal vez miles de dominios, consulte el post Automatizando parámetros en Linux II.
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 intercept
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)
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
BLOQUEO DE ANONIMIZADORES
Para bloquear anonimizadores como Ultrasurf, etc, con Iptables, visite el proyecto blackstring.
Para bloquear otros anonimizadores, como PrivateTunnelFreegateyour-freedom, además de las reglas del proyecto Blackstring, 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 squid
acl blacklistweb dstdomain -i "/etc/acl/blacklistweb"
http_access deny blacklistweb
Para mayor información visite blacklistweb.com
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 la acl httpspermitidos puede usarla también en squid). Lo anterior es debido a que ultrasurf, SecurityKiss Tunel, Easy Hide IP (y familia hide-ip), etc, hacen peticiones al puerto 80, y los Free o Anonymous Web proxy.
# squid.conf Denegar todas las peticiones a ips (solo url)
acl httpspermitidos src "/etc/acl/httpspermitidos"
acl no_ip dstdom_regex ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$
http_access deny no_ip !httpspermitidos
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 '/#.*/d' $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 -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), 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
RECOMENDACIONES FINALES
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. Pruebe su firewall
6. Visite el proyecto Gateproxy

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