firewall.pdf
TRANSCRIPT
![Page 1: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/1.jpg)
www.maravento.com
MARAVENTO STUDIO FIREWALL
![Page 2: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/2.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
FIREWALL
ACEPTAR O DENEGAR HTTPS
En el artículo “Bloqueo de p2p, redes sociales y messengers” dimos algunas herramientas para
que el Administrador TI 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 TI.
Ante esta situación solo nos queda un camino: suicidarnos… Mejor usar a los superhéroes Batman
y Robin, o sea, un servidor proxy en linux con IPTABLES y SQUID entre nuestra red local e
internet, para filtrar el contenido (Para los amantes de Windows Server, lamentamos informarles
que Microsoft decidió usar servidores Linux para Skype).
![Page 3: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/3.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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).
Si elegimos un Proxy Cache (3128), 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 Administradores TI, 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 TI 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 TI 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, lo cual se traduce 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.
![Page 4: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/4.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
ANTES DE COMENZAR
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.
Ejemplo de cabecera del script de IPTables:
echo Aplicando reglas
adminMAC="08:00:27:6E:AF:XX"
internet=eth0
lan=eth1
local=192.168.1.0
iptables=/sbin/iptables
route=/home/tu-servidor/acl
proxyport=8080
netmask=255.255.255.0
Variables
route es la variable que sustituye la ruta en el IPtables donde el Administrador TI 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 MAC de administración del IPtables
iptables contiene la ubicación del IPtables
![Page 5: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/5.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
proxyport el puerto que define el proxy. Para este caso es 8080 (transparent)
netmask, define la máscara de red.
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
cambiarlo por la ruta completa.
Alias
Como vamos a usar "alias", es necesario que abajo de la cabecera del IPTables ponga el alias,
para que la regla que explicaremos sea válida.
alias cat="sed '/#.*/d'"
Administración del IPtables
Para aumentar la seguridad, ponga la MAC del Administrador TI en adminMAC, y así limitar el
acceso al Firewall y por ende a modificar su configuración (Vea cabecera del IPTables arriba) y
configure los accesos que le otorgará.
################################
### ADMIN WEBMIN, SSH, ETC #####
################################
$iptables -A INPUT -i $lan -m mac --mac-source $adminMAC -p tcp --dport
22 -j ACCEPT
$iptables -A INPUT -i $lan -m mac --mac-source $adminMAC -p tcp --dport
10000 -j ACCEPT
Instalar Squid
Para este procedimiento, asegúrese de tener instalado Squid (v2.x). Si va a usar Squid3 (v3.x) siga
las instrucciones de instalación y configuración AQUI
sudo apt-get install squid
Puerto del Proxy
![Page 6: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/6.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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 TI 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 2.6x de Squid.
# Default Squid Listens to Port 3128
http_port 8080 transparent
CONFIGURANDO IPTABLES
Las siguientes instrucciones se han diseñado en colaboración con nuestro portal
asociado Novatoz. 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 https-permitidos y https-bloqueados y estarán en la
ruta explicada en la variable $route de la cabecera del IPtables.
![Page 7: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/7.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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.
#######################################
## Realizado por Maravento y Novatoz ##
#######################################
# REGLAS PARA ACEPTAR O DENEGAR CONEXIONES HTTPS
# ACEPTAR CONEXION
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
![Page 8: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/8.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
# DENEGAR CONEXION
#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
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 (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)
# SALIDA A INTERNET. ABRIENDO PUERTOS (Y CERRANDO 443)
# Aceptar conexiones a puertos (https, http, ssh, ftp, dns, pop3, smtp)
# $iptables -A FORWARD -s $local/$netmask -i $lan -p tcp --dport 443 -o
$internet -j ACCEPT
$iptables -A FORWARD -s $local/$netmask -i $lan -p tcp --dport 80 -o
$internet -j ACCEPT
$iptables -A FORWARD -s $local/$netmask -i $lan -p tcp --dport 8080 -o
$internet -j ACCEPT
$iptables -A FORWARD -s $local/$netmask -i $lan -p tcp --dport 22 -o
$internet -j ACCEPT
$iptables -A FORWARD -s $local/$netmask -i $lan -p tcp --dport 21 -o
$internet -j ACCEPT
![Page 9: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/9.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
$iptables -A FORWARD -s $local/$netmask -i $lan -p tcp --dport 53 -o
$internet -j ACCEPT
$iptables -A FORWARD -s $local/$netmask -i $lan -p udp --dport 53 -o
$internet -j ACCEPT
$iptables -A FORWARD -s $local/$netmask -i $lan -p udp --dport 110 -o
$internet -j ACCEPT
$iptables -A FORWARD -s $local/$netmask -i $lan -p udp --dport 25 -o
$internet -j ACCEPT
# denegar el resto
$iptables -A FORWARD -s $local/$netmask -i $lan -o $internet -j DROP
Si quiere permitir algunos terminales dentro de su red local que tengan acceso al puerto 443, o sea
aplicar el Caso 1, salvo para un grupo de privilegiados, escriba la siguiente regla y póngala antes
de la regla de aceptar o denegar conexión, pero primero cree la ACL (La llamaremos https-
macsprivilegiadas) y coloque dentro todas más MACs que quiera que tengan acceso al 443
# ACCESO HTTPS 443
for mac in `cat $route/https-macsprivilegiadas`; do
$iptables -A FORWARD -m mac --mac-source $mac -p tcp --dport 443 -o
$internet -j ACCEPT
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 para dejar pasar el resto, 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 https-permitidos, por lo que los programas como Tor o Ultrasurf y
sus derivados, quedarán inservibles.
![Page 10: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/10.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
Basados en ese análisis, consideramos que una buena política es el Caso 1; o sea, aceptar los
correos electrónicos y messengers (Hotmail, Skype, gmail, yahoo, etc), bancos y uno que otro
portal corporativo o institucional y denegar el resto, 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.
DONDE BUSCO LAS IPs PARA LAS ACLs?
El Administrador TI 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 el
comando nslookup. (Ej: nslookup facebook.com).
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 usarWhois Lockup, o
cualquier otra herramienta que gusten para determinar las IPs objetivo, siempre que brinden
resultados confiables.
DEFINIENDO LAS IPs EN LAS ACLs
![Page 11: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/11.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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
#######################################
## Realizado por Maravento y Novatoz ##
#######################################
# 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
![Page 12: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/12.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
#
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
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
#
![Page 13: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/13.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
#
# SITIOS VARIOS
#
# MENEAME.NET
46.137.126.119
ACL https-permitidos
# HTTPS permitidos
#######################################
## Realizado por Maravento y Novatoz ##
#######################################
# 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
#
# MAILS
#
# MAILS
#
# Google (All services)
![Page 14: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/14.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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.255.255
173.194.0.0-173.194.255.255
209.85.128.0-209.85.255.255
208.109.4.0-208.109.6.255
208.117.224.0-208.117.255.255
216.69.149.0-216.69.149.255
216.239.32.0-216.239.63.255
# Yahoo (Mail, Messenger)
66.163.160.0-66.163.191.255
68.180.128.0-68.180.255.255
72.30.0.0-72.30.255.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
#
![Page 15: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/15.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
# Microsoft (Hotmail, Messenger, Skype, Outlook, Live)
23.0.0.0-23.67.255.255
54.241.30.137-54.241.32.167
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
157.54.0.0-157.60.255.255
173.194.0.0-173.194.255.255
173.222.0.0-173.223.255.255
177.103.201.0-177.141.232.255
181.64.47.0-81.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.250.21.255
192.204.0.0-192.204.5.255
193.95.154.0-193.95.154.127
![Page 16: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/16.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
204.9.163.128-204.9.163.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
#
# Skype-Hotmail-Outlook Live Microsoft de terceros
#
# Amazon Microsoft
184.72.0.0-184.73.255.255
184.169.128.0-184.169.255.255
# ETB Skype
200.119.0.0-200.119.127.255
# Telebucaramanga Skype
201.221.128.0-201.221.159.255
# Mercanet Skype
200.14.40.0-200.14.47.255
# SoftLayer Technologies Sype
208.43.117.200
# Northern Telecom Hotmail-Outlook
![Page 17: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/17.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
131.253.12.0-131.253.18.255
131.253.61.0-131.253.255.255
# Road Runner
107.14.43.145
# UPC Ceska Republica
78.45.182.29
# Cogent Communications
149.13.32.15
# Level 3 Communications
212.187.172.108
# Offermatica
70.42.13.0-70.42.13.255
#
# BANCOS
#
# BBVA
186.113.14.0-186.113.14.255
148.244.45.0-148.244.45.255
# BANCO AGRARIO
201.245.171.67
# BANCO DE BOGOTA
![Page 18: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/18.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
10.161.166.190
200.14.232.18
# BANCOLOMBIA
200.1.175.105
69.42.111.93
# PAGOSSIMPLE
200.74.147.85
# VIRTUALLYTHERE
151.193.254.14
# PAYPAL
64.4.240.0-64.4.255.255
#
# CONTROL
#
# LOGMEIN
63.208.0.0-63.215.255.255
64.74.103.0-64.74.103.255
64.94.46.0-64.94.47.255
69.25.20.0-69.25.21.255
74.201.74.0-74.201.75.255
77.242.192.0-77.242.193.255
![Page 19: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/19.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
212.118.234.0-212.118.234.255
#
# TEAMVIEWER
46.165.193.40
46.163.100.194-46.163.100.220
87.230.74.41-87.230.74.48
92.43.21.135-92.43.21.138
95.211.37.209-95.211.37.211
95.211.75.200
178.77.120.0-178.77.120.127
217.115.140.84
#
# DROPBOX
199.47.217.0-199.47.217.255
199.47.216.0-199.47.216.255
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
![Page 20: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/20.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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
$iptables -t nat -A PREROUTING -i lan -p tcp --dport 80 -j REDIRECT --to-
port 8080
$iptables -A INPUT -i lan -p tcp --dport 8080 -m state --state NEW -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: Si cambia los puertos por defecto 3128 y 8080, asegúrese que su reemplazo no sea el
mismo para ambos tipos de configuraciones.
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. Hay otro método usando Dansguardian y Squid. Puede consultarlo AQUI
![Page 21: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/21.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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, WirelessKeyView, etc, o logra acceso físico a uno de los equipos de
nuestra red o cibercafé y copie la clave WIFI en laconfiguració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 de la historia cuando podemos establecer los usuarios que vamos a autorizar a recibir
![Page 22: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/22.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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.
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:
#######################################
## Realizado por Maravento y Novatoz ##
#######################################
## FLUSH de reglas
$iptables -F
$iptables -X
$iptables -Z
$iptables -t nat -F
$iptables -t mangle -F
## Establecemos politica por defecto
$iptables -P INPUT ACCEPT
$iptables -P OUTPUT ACCEPT
$iptables -P FORWARD ACCEPT
![Page 23: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/23.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
$iptables -t nat -P PREROUTING ACCEPT
$iptables -t nat -P POSTROUTING ACCEPT
$iptables -A INPUT -i lo -j ACCEPT
########################################################
# SOLO SE ACEPTAN PETICIONES DE EQUIPOS DE NUESTRA RED #
########################################################
for mac in `cat $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
# Denegar el resto de las conexiones
$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.
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.
![Page 24: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/24.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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.
Ejemplo de uso de MANGLES para aplicarle restricciones a un grupo de equipos de la red LAN.
#######################################
## Realizado por Maravento y Novatoz ##
#######################################
echo Aplicando reglas
adminMAC=""
internet=eth0
lan=eth1
local=192.168.1.0
iptables=/sbin/iptables
proxyport=8080
netmask=255.255.255.0
hora_actual=$(date +%H)
# formato 24h
hora_permitida=13
![Page 25: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/25.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
alias cat="sed '/#.*/d'"
## FLUSH de reglas
$iptables -F
$iptables -X
$iptables -Z
$iptables -t nat -F
$iptables -t mangle -F
## Establecemos politica por defecto
$iptables -P INPUT ACCEPT
$iptables -P OUTPUT ACCEPT
$iptables -P FORWARD ACCEPT
$iptables -t nat -P PREROUTING ACCEPT
$iptables -t nat -P POSTROUTING ACCEPT
$iptables -A INPUT -i lo -j ACCEPT
#######################################
# BLOQUEAR SI NO ES LA HORA PERMITIDA #
#######################################
if [ $hora_actual -lt $hora_permitida ]; then
echo bloqueando https para macs-limitadas
for mac in `cat $route/macs-limitadas`; do
![Page 26: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/26.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
$iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -p
tcp --dport 80 -j ACCEPT
$iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -p
udp --dport 53 -j ACCEPT
$iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -p
udp --dport 137 -j ACCEPT
$iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -p
udp --dport 138 -j ACCEPT
$iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -p
tcp --dport 139 -j ACCEPT
$iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -p
tcp --dport 445 -j ACCEPT
$iptables -t mangle -A PREROUTING -i $lan -m mac --mac-source $mac -j
DROP
done
fi
Y a continuación las reglas explicadas en la primera entrega Firewall
CONCLUSIONES
Con estas reglas, los administradores TI ya pueden dormir tranquilos y decirle adiós al Ultrasurf,
Tor, los túneles vpn y toda la gran familia de programas proxies anónimos, mal acostumbrados a
saltarse cualquier restricción dentro de un red LAN. Sin embargo, si un usuario aventajado accede
a nuestra red, la escanea, logrando hacerse con las MACs autorizadas en las ALCs y las clona,
MANGLES no servirá de mucho y habría que implementar un nivel mucho más alto de seguridad y
aplicar protecciones adicionales, que se describirán el el próximo capítulo.
![Page 27: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/27.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
FIREWALL III
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, 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.
En este caso se le debe ir añadiendo diferentes capas o niveles de seguridad a nuestro servidor
proxy, para blindarlo de estas intrusiones no autorizadas.
Existen muchas técnicas, pero lo más importante es que el Administrador TI entienda que
implementar una sola técnica no es suficiente, sino la combinación de varias que traigan el
![Page 28: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/28.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
resultado esperado. Todo radica en las necesidades de la empresa, el nivel de protección de datos
y demás parámetros de seguridad a implementar.
Las técnicas que se vamos a describir a continuación tienen como objetivo reducir las posibilidades
de éxito del intruso. Cada técnica añade una capa o nivel de seguridad a nuestro proxy y por ende
lo vuelve más inexpugnable, sin embargo no existen técnicas infalibles, pero por cada capa de
seguridad que implementemos es una puerta más que se le cierra al intruso, hasta que desista de
sus intenciones.
AMARRAR LA IP CON MAC Y HOST
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
NOTA:
dhcp3-server o isc-dhcp-server obtienen el mismo resultado. Es más común usar dhcp3-server
sudo apt-get install dhcp3-server
sudo apt-get install -f
sudo gedit /etc/dhcp3/dhcpd.conf
y escriba lo siguiente (Fragmento del archivo de configuración de DHCP):
#######################################
# Fixed IP addresses can also be specified for hosts. These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP. Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
![Page 29: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/29.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
# set.
host USUARIO {
hardware ethernet 00:d0:b8:19:a7:xx;
fixed-address 192.168.1.100;
}
host USUARIO2 {
hardware ethernet 00:d0:b8:19:a7:xy;
fixed-address 192.168.1.101;
}
Donde USUARIO y USUARIO2 son los nombres de Host delos terminales de nuestra Lan. Puede
seguir asociando cada Mac de su red Lan a una IP específica, identificada con el Host. Luego
establezca el rango de DHCP al final del archivo de configuración. Ejemplo para 50 equipos:
#}
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.150;
option domain-name-servers 8.8.8.8 , 8.8.4.4;
option routers 192.168.1.1;
option broadcast-address 192.168.1.255;
default-lease-time 432000;
max-lease-time 432000;
}
![Page 30: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/30.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
El "range" o rango lo define el Administrador TI en dependencia de la cantidad de equipos que
tenga en su red. Luego se debe crear una ACL con los rangos de IP dentro de su red Lan a
bloquear (las IP que no se van a usar) y agregarla al Squid. Para los efectos de este ejemplo, la
ACL se llamará "ip-bloqueadas" y la ubicaremos en la carpeta home
sudo gedit /etc/squid/squid.conf
Y agregamos en el Squid
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
acl webserver src 192.168.1.1/255.255.255.0
acl ips-bloqueadas src "home/tu-servidor/alc/ips-bloqueadas"
acl macs-permitidas arp "home/tu-servidor/alc/macs-permitidas"
y luego activar la regla en el Squid
# Don't upgrade ShoutCast responses to HTTP
http_access deny ips-bloqueadas
http_access allow macs-permitidas
Nota: Para que funcione esta regla en el Squid, debe ir ANTES que la regla que controla las ACLs
con las "macs-permitidas" de la Lan, tal cual como se muestra arriba.
De esta manera, si el intruso coloca una ip manual, fuera del rango autorizado por el DHCP, no
podrá navegar, ya que está bloqueada en la Acl "ip-bloqueadas", así haya clonado una Mac
autorizada.
Es importante recordar que el Proxy Server 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.
TODO POR EL SQUID
![Page 31: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/31.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
El hecho de que el servidor sea transparente no significa que el tráfico 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 `cat /home/tu-servidor/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
Proxy Server y 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.
Casi siempre esta regla se usa para los jefes y los "amigos" del Administrador TI, que quieren
hacer y deshacer 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 será terminado por los mismos jefes y amigos a quienes les ofreció el
cielo y la tierra con esta regla.
Es más viable abrir el puerto 443 bajo demanda, que otorgar privilegios ilimitados a este grupo
reducido de Macs. Para abrirlo basta con colocar las Macs privilegiadas en una ACL y crear la
siguiente regla en el IPtables
########################
![Page 32: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/32.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
### Macs acceso 443 ####
########################
for mac in `cat $route/macs-privilegiadas`; do
$iptables -A FORWARD -m mac --mac-source $mac -p tcp --dport 443 -o
$internet -j ACCEPT
done
SUPERVISION
Otra técnica para proteger nuestra red es usar un software de monitoreo en tiempo real. Hay
muchos software de gestión TI que tienen estas funciones, como Whatsup
Gold, Nessus, OpManager, PRTG, etc, sin embargo recomendamos Sqstat, que ofrece resultados
realmente sorprendentes, logra el objetivo que buscamos y es gratuito. Si quiere conocer otras
alternativas gratis para Linux, pulse AQUI.
Descargamos el programa Sqstat AQUI. Luego instalamos
sudo apt-get install apache2 php5 libapache2-mod-php5 php5-cli
Lo copiamos en /var/www y lo descomprimimos:
sudo cp sqstat-1.20.tgz | sudo tar -xzvf sqstat-1.20.tgz
Nos cambiamos de directorio y copiamos el archivo config.inc.php.defaults como config.inc.php
sudo cd /var/www/sqstat | sudo cp config.inc.php.defaults config.inc.php
Editamos el archivo config.inc.php especificando los parámetros de IP o hostname del servidor
proxy y el puerto de escucha:
sudo vim /var/www/sqstat/config.inc.php
Y modificamos las líneas
$squidhost[0]="IP_PROXY_SERVER";
![Page 33: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/33.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
$squidport[0]=PORT_PROXY_SERVER;
Con aquellos parámetros de nuestra red Lan. Ejemplo:
$squidhost[0]="192.168.1.1";
$squidport[0]=8080;
Luego editamos el archivo /etc/squid/squid.conf, añadiendo estas líneas:
cl manager proto cache_object
acl PROXY_SERVER src IP_PROXY_SERVER/255.255.255.255
http_access allow manager PROXY_SERVER
http_access deny manager
Debemos hacer coincidir la sentencia IP_PROXY_SERVER/255.255.255.255 con la IP del servidor
Squid. Luego reiniciamos el Proxy o recargamos Squid y Apache con:
sudo squid -k reconfigure | sudo invoke-rc.d apache2 reload
Por último, abrimos el navegador web desde cualquier PC de la red Lan y en la barra de
direcciones tecleamos http://127.0.0.1/sqstat/sqstat.php, donde 127.0.0.1 es Localhost o puede ser
reemplazado por la IP_PROXY_SERVER
Ya podemos ver lo que sucede en nuestra red Lan en tiempo real.
SECURE VIRTUAL CLOUD
![Page 34: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/34.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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.
Referencia Recomendada: HowTO install Servidor Virtual Private Network (VPN)
SVC guarda algunas similitudes con el modo de conexión y operación de los túneles VPN, y los
programas proxy anónimos como Tor, Ultrasurf, etc, pero a un nivel más avanzado y seguro.
Encriptan las comunicaciones cliente-servidor a un nivel militar, dificultándole al usuarpador
comunicarse con nuestro servidor, así haya clonado una Mac de nuestra red y navegue con la
misma Ip asignada por el DHCP.
La diferencia de los SVC con los VPN, PPTP, etc, es que, a pesar de que las conexiones son
Point-to-Point, los SVC poseen un plataforma completamente virtualizada; en otras palabras, el
cliente se conecta a una especie de Nube Virtual Segura, controlada por una plataforma virtual y a
través de este entorno puede realizar las peticiones a Internet (no puede hacerlo directamente
desde su terminal). SVC es un sistema que opera independiente del proxy y del cliente y se puede
acceder a este desde la Lan o remotamente. De éste u otros temas, hablaremos en nuestra
próxima entrega.
![Page 35: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/35.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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 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...
![Page 36: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/36.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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 Administrador TI haya recopilado y
que no se encuentren en las ACLs ofrecidas en estos "big packs blacklists".
Una herramienta muy eficaz es Sqstat, o Monit (explicadas en Firewall III) para ver el tráfico de la
red local e ir bloqueando sitios que no estén acordes con las políticas de seguridad de la empresa.
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): Un pack, diseñado por nuestro portal, que 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) AQUI o AQUI
Configurando Squid
![Page 37: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/37.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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/adminred/acl/porno
Sustituya adminred 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 "/home/adminred/acl/porno"
acl descargas dstdomain "/home/adminred/acl/descargas"
Y actívelas
# Don't upgrade ShoutCast responses to HTTP
acl apache rep_header Server ^Apache
http_access allow manager localhost
http_access allow manager webserver
http_access deny manager
http_access allow purge localhost
http_access deny purge
![Page 38: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/38.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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/adminred/acl/archivos-
bloqueados"
acl extensiones url_regex "/home/adminred/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
![Page 39: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/39.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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.
Existen dos tipos de ataques contra la infraestructura informática (en dependencia de su origen):
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.
OUTSIDE
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,
![Page 40: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/40.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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.
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 capas de solución:
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 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
![Page 41: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/41.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
infraestructura informática. Puede estar conformada por uno o varios servidores (clusters), Firewall,
Unit System Box, proxy inversos, 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:
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 servidos 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:
![Page 42: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/42.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
Con los siguientes parámetros:
FREQ= "aquí ponemos la frecuencia en la que el O.S ejecuta dicho scrip en minutos" //Default =1
NO_OF_CONNECTIONS= "conexiones límites para una IP entrante al servidor" //Default =150
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 conexion a IPS de lista Negra" //Default =1
EMAIL_TO= "aqui 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 linea shebang de /bin/sh a /bin/bash en ddos.sh para que la
primera linea quede como #!/bin/bash. Asi mismo les recomiendo 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
APF y BFD: También estan 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
Reverse Proxy: Otro ejemplo es un Proxy Inverso (Reverse Proxy). Es 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
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).
![Page 43: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/43.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
Tutoriales Cómo configurar un Proxy Inverso con Apache, y Qué es Reverse Proxy y cuándo
usarlo?
INSIDE
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 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 recientes 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.
![Page 44: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/44.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
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.
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)
Secure Virtual Cloud (SVC es una plataforma completamente virtual (Open Source), en la Nube. 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.
VERIFICANDO SEGURIDAD PERIMETRAL
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 perimetral con todo lo que
tengamos, sin importar qué sea, hasta que se reviente o aguante la embestida... Es mejor hacerlo
uno mismo que esperar a que otro lo haga.
Existen muchas herramientas capaces de determinar qué tan sólida es nuestra defensa. Una muy
buena es la Mega Suite Net Tools, que contiene casi todo lo necesario para probar una red.
En GNU/Linux las más usadas para capturar y analizar el tráfico
son Wireshark (Install, Manual),TCPDump, Nmap, IPTraf (Manual), Ettercap y NLAS, entre otras
Una descripción de estos programas puede encontrarla en Bloqueando IP atacante y Snifeando su
proxy
FOCA es otra herramienta muy recomendada, que realiza procesos de fingerprinting e information
![Page 45: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/45.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
gathering en trabajos de auditoría web. La versión Free realiza búsqueda de servidores, dominios,
URLs y documentos publicados, así como el descubrimiento de versiones de software en
servidores y clientes. FOCA se hizo famosa por la extracción de metadatos en documentos
públicos, pero hoy en día es mucho más que eso.
EL FIN JUSTIFICA LOS MEDIOS
Podemos llevar las pruebas al "siguiente nivel", usando herramientas hack para realizar un ataque
de DDoSa nuestra propia infraestructura, de manera controlada. El objetivo es que el
Administrador TI compruebe la capacidad de tráfico que sus servidores pueden soportar sin
volverse inestables y afectar a los servicios que prestan, o sea, conocer la capacidad real de cada
máquina.
Puede utilizar Low Orbit Ion Cannon (LOIC), que es una aplicación del proyecto Chanology, la cual
realiza un ataque de denegación de servicio del objetivo enviando una gran cantidad de paquetes
TCP, paquetes UDP o peticiones HTTP con objeto de determinar cuál es la cantidad de peticiones
por segundo que puede resolver la red objetivo antes de dejar de funcionar. También puede usar
Turbinas, o Hping3, Ping Flooding o cualquier otra herramienta hacking para explotar las
vulnerabilidades de su propia red.
Ejemplo de ataque DDoS con Hping3
sudo apt-get install hping3
sudo hping3 --rand-source -p 80 -S --flood 192.168.1.1
o
sudo hping3 -S 192.168.1.1 --flood --rand-source -d 5000 -p 80
Donde 192.168.1.1 es la ip de nuestro servidor proxy que pretendemos hacer caer, -p 80 es el
puerto que elegimos atacar, -S activa el flag Syn, --flood le indica a hping que envíe los paquetes a
la máxima velocidad posible, --rand-source hace que se generan direcciones de origen ip al azar
(para no saturar nuestra propia máquina con las respuestas (Spoofing) o también se puede usar -
a ip_falsa (en reemplazo de --rand-source) para usar una ip diferente a la nuestra y finalmente -
d, que indica el tamaño del cuerpo del paquete (expresado en bytes). Este valor puede variar.
![Page 46: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/46.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
Al cabo de unos pocos segundos, el servidor se volverá inaccesible dada la cantidad de requests
que el servidor tiene que procesar. Al intentar acceder al servidor o sitio atacado por el puerto 80,
se obtiene un timeout dado que no puede responder a peticiones genuinas por estar saturado de
paquetes malformados.
Vea SYN Flood con Hping3 y Ataques coordinados DDos
Distribuciones especializadas GNU/Linux (Fuente: distrowatch.com)
Muchas de las tools descritas anteriormente se recogen en distros especializadas en seguridad
perimetral, análisis forense, recuperación, penetración y filtrado.
Una distro especializada y preconfigurada, no solo ahorra tiempo al Administrador TI, sino que
garantiza que no pase por alto alguna protección esencial a la hora de la configuración.
Una buena alternativa es Zeroshell. Es una distribución GNU/Linux casi desconocida, pero muy
profesional. Especial para servidores y dispositivos integrados destinados a proporcionar los
servicios de red principal de una LAN requiere. Está disponible en forma de Live CD o de imagen
de Compact Flash y se puede configurar y administrar utilizando el navegador web.
La ventaja es que no es un folk sino una distro genuina independiente, ideal para equilibrio de
cargas, tráfico 3g, servidor radius, proxy inverso, portal cautivo, etc, etc.
Backtrack, basada en Ubuntu, es considerada como una de las distros más populares entre los
hackers y entusiastas de la seguridad de redes. Fue creada combinando dos distros principales:
Auditor Security Linux (basada en Knoppix) y WHAX (anteriormente Whoppix; basada en Slax).
BackTrack está dotada con una gran gama de herramientas de seguridad y de hacking que
incluyen desde password crackers hasta port scanners. Además incluye una gran colección de
exploits así como también programas comunes como el navegador Firefox.
Network Security Toolkit (NST): Basada en Fedora es un Live CD equipado con herramientas de
análisis de seguridad de redes, programas de validación y monitoreo que puede ser utilizado en
servidores virtuales que albergan máquinas virtuales. Su principal objetivo es proveer a los
administradores de red de un set completo de herramientas de seguridad de código abierto.
NST está equipado con una avanzada interfaz de usuario web (WUI) la cual nos permite configurar
las aplicaciones de seguridad y redes, automatización, y otras tareas. Entre otras características se
![Page 47: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/47.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com
encuentran un capturador de paquetes y un sistema de análisis de protocolos que puede
monitorear más de cuatro interfaces de red usando Wireshark.
Pentoo: Es una distro disponible en Live CD y Live USB creada principalmente para pruebas de
penetración y asesoría de seguridad. Basada en Gentoo, está disponible para 32 y 64-bits. Sus
características incluyen controladores inalánbricos mejorados con inyección de paquetes, GPGPU
cracking software, y llena de buenas herramientas para pruebas de penetración. Actualmente
Pentoo tiene como escritorio por defecto a Enlightenment y utiliza el Kernel 2.6.31.6 con los
parches lzma y aufs.
Helix: Basada en Ubuntu, es un Live CD especialemten diseñado para análisis de sistemas,
recuperación de datos, auditoría de seguridad, y respuesta a incidentes. Puede ejecutarse en dos
modos: Linux mode (bootea un entorno nativo de Linux) y Windows mode (corre dentro de
Windows como una aplicación normal). Helix está principamente diseñada para usuarios
experimentados y administradores de red que trabajan en redes de computadoras y están
constantemente bombardeadas con altos niveles de brechas de seguridad y pérdida de datos.
WiFiSlax : Es una distribución GNU/Linux con funcionalidades de LiveCD y LiveUSB pensada y
diseñada para la auditoría de seguridad y relacionada con la seguridad informática en general.
WiFiSlax incluye una larga lista de herramientas de seguridad y auditoría listas para ser utilizadas,
entre las que destacan numerosos escáner de puertos y vulnerabilidades, herramientas para
creación y diseño de exploits, sniffers, herramientas de análisis forense y herramientas para la
auditoría wireless, además de añadir una serie de útiles lanzadores.
BackBox Linux: Distro basada en Ubuntu diseñada específicamente para tareas vinculadas a
seguridad de redes, análisis forense, ingeniería inversa, reportes, etc.
Desarrollada para realizar pruebas de penetración y evaluaciones de seguridad. Está diseñada
para ser rápida y fácil de usar. Proporciona un entorno de escritorio mínimo pero completo, gracias
a sus propios repositorios de software, que siempre se actualizan con las últimas versiones
estables de las más utilizadas y conocidas herramientas de hacking ético.
Hay otras no muy conocidas, algunas descontinuadas, pero no por eso dejan de ser útiles para
propósitos específicos, tales como Operator, Inside Security Rescue Toolkit, Deft Linux, Fire, Local
Area Security LAS, Phlak, nUbuntu (Network Ubuntu), entre otras.
…Continuará en Firewall V
![Page 48: Firewall.pdf](https://reader035.vdocumento.com/reader035/viewer/2022081420/55cf9c3c550346d033a91fcb/html5/thumbnails/48.jpg)
How/TO Firewall (IPTables & Squid)
www.maravento.com