Header Ads

Automatizando parámetros en linux II

En el post Automatizando parámetros en Linux, vimos cómo es posible cambiar los parámetros de una red a golpe de script. En esta ocasión le tocó el turno a la obtención de ips.
En la serie Firewall, abordamos el tema sobre darle "algo de seguridad" a un proxy transparente, basado en Squid-Cache, filtrando el puerto 443 con iptables. Es importante resaltar que como Squid no filtra peticiones https cuando se encuentra en modo transparente, cualquier cosa dirigida al puerto 443, no será procesada por este proxy (y tampoco aparecerá en ningún reporte, como Sarg, Sqstat, etc).
En dicho post propusimos crear una regla de iptables que solo valide (permita) entrar a nuestra red local aquellas ips que nos interesan (asociadas a sitios webs https) y denegar el resto, sin embargo, como la moda ahora es "todo por https" (Google prioriza la indexación https), nuestras listas de ips https pueden pasar de los cientos a los cientos de miles, y eventualmente puede convertirse en una pesadilla logística obtener todas estas ips.
En su momento propusimos varias maneras de obtenerlas, las cuales enumeraremos a continuación:
1. METODO MANUAL
a. Comandos:
nslookup google.com
dig +short google.com
host -t a google.com
b. Herramientas y/o sitios webs
Socketsniff es una herramienta 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.
Pros: Ambas alternativas son muy fiables en los resultados
Contras: Los comandos se deben ejecutar varias veces (con y sin www) para cada dominio, ya que los resultados podrían variar.
Socketsniff no funciona en sistemas x64 y tiene dificultades para capturar ips de aplicaciones y sitios cifrados y en algunos navegadores no ofrece resultados.
2. CIDR/ORIGINAS
originAS es la información asociada a un dominio o ip. Se puede obtener de varias maneras:
a. Manualmente
En centralops.net/co/ buscamos el dominio (Ej: facebook.com) y en los resultados aparecerá el originAS. Luego ejecutamos en consola:
/usr/bin/whois -h whois.radb.net '!gAS32934' | tr ' ' '\n' | sort -n -k1,1 -k2,2 -k3,3 -k4,4 |grep /
Donde AS32934 es el originAS de facebook y arrojará todos los rangos de ips de este dominio.
También existen sitios y herramientas donde consultar los ASN.
b. Script
Haciendo uso de whois.radb.net, (y whois.arin.net) utilizamos un script como el propuesto por el portal Karpoke
for IP in $(dig +short -f domains.txt); do
        AAS=$(whois $IP | awk -F: '/OriginAS/{print $2}')
        for AS in $AAS; do
                AS=${AS%%[^0-9]}
                test -n "$AS" && whois -h whois.radb.net '!g'$AS | tr -d "\n" | tr " " "\n"
        done
done > final.txt
Donde domains.txt es una acl que contiene todos los dominios que queramos saber el OriginAS y final.txt es donde pondremos el resultado y finalmente hacemos una depuración del resultado. También podemos capturar el CIDR, como el propuesto en stackoverflow
for X in `cat domains.txt`; 
do 
    host -t a  $X; 
done | awk 'BEGIN { FS = " " } ; { print $4 }' > ip.txt; 

for Y in `cat ip.txt`; 
do 
    whois $Y | grep CIDR; 
done
También están las calculadoras web como ipaddressguide, ultratools, etc.
Pros: Ahorra mucho tiempo en la obtención de ips y amplia el rango de posibilidades de validación (o bloqueo) de las ips asociadas a un domino.
Contra: No siempre se obtiene el originAS o CIDR. Whois puede bloquear peticiones masivas. Durante la ejecución del script podemos obtener mensajes como:
ANALISIS
En este punto es prudente hacernos una pregunta: ¿Que tanto necesitamos todos rangos de ips asociados a un domino?
Muchos responderán que ahorra mucho trabajo y tiempo, sin embargo veamos el siguiente escenario.
Supongamos que tenemos un firewall y vamos a realizar un bloqueo masivo de ips. Sin embargo necesitamos validar todos los rangos de ips asociadas al dominio google.com y ponerlos en nuestra "lista blanca", para excluirlos de este bloqueo y así los usuarios puedan ingresar a google.com.
Debemos saber que, aparte de los servicios que ofrece google expresados en subdominios ( doc.google.com, drive.google.com, etc), también existen cientos de dominios tipo "com.algo" en dependencia del país (www.google.com.ve, com.br, com.co, etc)
Ahora imaginemos que vivimos en México (puede ser cualquier país) y la "lista blanca" la vamos a usar en ese país. Entonces, ¿para qué necesitamos validar en nuestra lista los dominios google.com.br (brasil) o google.com.co (colombia), y similares?
Si tenemos una lista de control de acceso ACL, bien sea para nuestro firewall, route, servidor, proxy, etc, introducirle el rango asociado a google.com.br estando la infraestructura en México no tendría mucho sentido, ya que las peticiones hacia cualquier dominio, por lo general, siempre buscan el camino más corto o se redireccionan al servidor más cercano al punto de la petición, en este caso, las peticiones a google.com se redireccionan a google.com.mx. Y este mismo esquema lo utilizan infinidades de dominios.
Pero, a pesar de esto, muchos administradores IT tienen la costumbre de validar todos y cada uno de los rangos que existen de google, yahoo, microsoft, etc, trayendo como consecuencia la ralentización de su red, ya que por cada rango de ips que le introduzcamos a nuestro hardware o software de administración de red, será un procesamiento adicional y/o consulta que tendrá que hacer por cada petición que un usuario realice dentro de la red local, generando también un consumo excesivo de recursos y de ancho de banda (que implican estas consultas masivas), y si lo hacemos con regularidad, pueden tachar a nuestro servidor como scam, bot o cualquier otra cosa y meterlo en alguna blacklist.
Para una mayor comprensión de este problema, observemos solamente el ASN del dominio google.com (AS15169), el cual contiene nada mas y nada menos que 1,247,488 direcciones ips. Y cada una de ellas deberá ser procesada por nuestro firewall o proxy, para cada una de las peticiones que haga un cliente. Ya podrán imaginar el volumen y la capacidad de procesamiento. Y hablamos de un solo dominio...
Por último, muchos dominios, como Google, tienen rangos dinámicos (cambian rangos de ips sin previo aviso), y hoy es muy usual que las empresas y proveedores de internet, cambien constantemente sus rangos de ips (y servidores), con el objeto de protegerse de un ataque prolongado DDoS y así balancear cargas y no interrumpir sus servicios, y los antiguos rangos son revendidos, segmentados y/o reasignados a otras empresas, ya que en la mayoría de los casos son servidores compartidos.
Además, todo el rango de ips asociadas a un dominio no necesariamente puede ser utilizado por el mismo y desafortunadamente muchos administradores IT van dejando estos rangos obsoletos en sus listas de control de acceso, lo cual ralentiza aún más la red local y eventualmente pueden convertirse en un problema de seguridad (ya que los rangos pueden ser revendidos a una organización con fines maliciosos)
En resumen, los dominios (o si prefieren llamarlos sitios web / urls) por lo general no sufren muchos cambios significativos y más bien se amplían (net, org, crean nuevos subdominios, se redireccionan etc), pero sus rangos de ips sí cambian constantemente. Por tal razón, hoy por hoy, los métodos anteriormente descritos, así como cualquier otro método que involucre rangos masivos de ips (basados en CIDR/OriginAS), consideramos que no son del todo viables y creemos que es más factible utilizar métodos que capturen únicamente las IPs asociadas a un dominio, ya que son mucho más seguros y fáciles de renovar.
AUTOMATIZANDO LA OBTENCIÓN DE IPS
En el siguiente ejemplo crearemos una acl llamada whitewebs (puede elegir cualquier otro nombre) y dentro incluiremos todos los dominios http/s que queramos dejar pasar. En el siguiente ejemplo la hemos guardado en la ruta /etc/acl. Los dominios deben estar en el siguiente formato:
# Google
google.com
google.com.co
google.co
# Yahoo
yahoo.com
# etc, etc
Sin embargo si tienen puntos al inicio (como en nuestra ACL. Ej: .google.com), comentarios (#), espacios en blanco, el script los elimina.
Guardamos el script en /etc/init.d/web2ip.sh (puede darle el nombre o la ruta que quieran) y le da permisos root chmod +x.
#!/bin/bash
### BEGIN INIT INFO
# Provides:          web2ip
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       capture ips from acl
# Authors:           Maravento.com and Novatoz.com
### END INIT INFO
route=/etc/acl
tmp=/tmp
cat $route/domains.txt | sed '/^$/d; / *#/d' | sed 's:^\.::' | sort -u  > $tmp/cleardomains.txt
for ip in `cat $tmp/cleardomains.txt`; do
 for sub in "" "www." "ftp."; do
  host -t a "${sub}${ip}";
 done
done | awk 'BEGIN { FS = " " } ; { print $4 }' | egrep -o "(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)" | sort -u > $route/ips.txt
sort -o $route/ips.txt -u $route/ips.txt -t . -k 1,1n -k 2,2n -k 3,3n -k 4,4n $route/ips.txt
El script anterior lo que hace es revisa la ACL domains.txt, elimina cualquier comentario, punto delante o espacio, para que sean dominios válidos de consulta y así evitar el error '.google.com' is not a legal name (empty label) y crea un archivo temporal con los resultados. El script utiliza este archivo temporal para realizar consultas de cada dominio, con y sin el www (incluye también ftp, y puede agregarle manualmente otros tipos de consultas de subdominios), para obtener todas las ips asociadas a los dominios incluidos en la lista.
Finalmente hace una validación y depuración de las ips y el resultado es una ACL final a la cual hemos llamado ips.txt. Puede programar el script en el cron para que se ejecute periódicamente y actualice las ips.
Con la tecnología de Blogger.