Continuando con la cruzada personal para ajustar cualquier cosa para que funcione como yo quiero, voy a enseñaros un caso práctico que utilizo en mi casa para mostrar lo útil que puede llegar a ser suplantar algunos dominios de internet.
La idea principal es hacer que un dominio (como por ejemplo www.microsoft.com) no apunte a la IP original, sino a una dentro de nuestra red local o bien hacia otra distinta en Internet.
Todo lo que se explica aquí afectará únicamente a la red local, desde el resto del mundo se seguirá viendo todo con normalidad, así que esto NO sirve para hacer phishing (salvo quizás dentro de la propia red local… claro…).
Para empezar, nos hace falta montar un entorno como sigue:
- Enrutador (realmente es opcional, pero si lo tenemos nos evitará tener que modificar las configuraciones en cada equipo. Uso el script apf que simplifica la administración con iptables)
- Servidor caché DNS (dnsmasq en este ejemplo)
- Servidor web (en mi caso uso apache)
- Proxy caché HTTP (opcional, transparente o no, recomendable usar squid)
Asumo que la mayoría de la gente no tiene en casa un cluster o un rack de servidores, así que todos estos servicios probablemente estarán en el mismo equipo. Para los posibles ejemplos que se mostrarán, la interfaz de red que va conectada hacia internet sería eth0 y la que va conectada a la red local sería eth1. En eth1 el servidor tendrá la IP 192.168.1.1.
Todos los clientes de la red deben utilizar el servidor DNS local como servidor principal de DNS; o bien, si el equipo está actuando de enrutador entre la red local e internet, redireccionar todas las peticiones salientes hacia el puerto UDP 53 (DNS) hacia nuestro servidor DNS local. De esta forma aunque se intenten conectar a un DNS externo a la red, se están conectando en realidad al DNS local.
Esta redirección de puertos se hace muy facilmente con iptables:
1 |
iptables -A PREROUTING -t nat -i eth1 -p udp --dport 53 -j DNAT --to 192.168.1.1:53 |
Incluso se podría conseguir lo mismo realizando unos ajustes en la configuración del router ADSL.
El proxy caché HTTP no es necesario a priori, pero sí recomendable si queremos poder analizar el tráfico que se utiliza en nuestra red y poder tomar acciones sobre ello. Más adelante profundizaré en este tema.
Redireccionar un servidor a otro:
En ocasiones tengo jugado a algún juego online en servidores privados, lo que normalmente se consigue modificando el archivo C:\Windows\System32\drivers\etc\hosts de Windows (burda copia de los sistemas UNIX de /etc/hosts) haciendo que cierto dominio apunte a cierta IP en lugar de hacia la IP real. El problema es que muchos juegos verifican si se ha modificado este fichero y no te dejan continuar.
Lo que vamos a hacer es esta misma modificación pero directamente desde la configuración del dnsmasq.
En mi caso particular, tengo probado el juego Lineage 2 (cuyo cliente puedes descargar gratuitamente) y jugado en el servidor privado de Guerreros del caos cuya IP es 88.198.49.101.
Modificamos el archivo /etc/dnsmasq.conf añadiendo lo siguiente:
1 2 3 |
address=/l2testauthd.lineage2.com/88.198.49.101 address=/l2authd.lineage2.com/88.198.49.101 address=/nprotect.lineage2.com/216.107.250.194 |
Reiniciamos el servicio:
1 |
/etc/init.d/dnsmasq restart |
Y probamos si funciona:
1 2 3 4 |
debian:/# host l2authd.lineage2.com l2authd.lineage2.com A 88.198.49.101 !!! l2authd.lineage2.com A record has zero ttl debian:/# |
Excelente, se nos indica también que se obtiene una respuesta inmediata (TTL=0, lo que muy probablemente implica que está siendo suplantada :D).
Si probamos a instalar ahora el juego en cualquier ordenador de la red y lo ejecutamos tal cual (sin modificar el archivo hosts) veremos que se conecta correctamente al servidor de Guerreros del caos en lugar de al servidor original de NCSoft.
Filtrar publicidad de páginas web:
Aunque existen plugins para Mozilla Firefox para evitar ver la publicidad de las páginas web, esto no evita que se consuma ancho de banda descargando dichos anuncios.
Toda mi red está pasando por un proxy caché transparente squid. Actualmente uso tres analizadores de logs de squid para sacar conclusiones:
- SquidGraph: Genera gráficas del uso de ancho de banda, peticiones cacheadas y sin cachear etc… Se ejecuta cada minuto y lo utilizo para sacar datos instantáneos de consumo de ancho de banda en la red.
- Calamaris: Genera informes agrupados de efectividad del proxy, dominios más visitados, ancho de banda consumido y numero de peticiones por tipo de archivo, dominio, cliente, etc…
- Sarg: Genera informes detallados de todas las páginas visitadas por cada cliente, esto permite ver muy detalladamente donde ha navegado cada uno. Aunque puede suponer una violación de la intimidad en mi caso no lo utilizo con esos fines, sino para observar el volumen de peticiones segun cada dominio.
Mi padre es asíduo visitante de páginas como As, Marca o El País y suele dejar el pc encendido con las páginas cargadas todo el día. Curiosamente todas estas páginas pertenecen a la misma empresa, Prisacom. Pues bien, revisando el top 10 de dominios más visitados me encontré con lo siguiente (extraído del log de ayer):
destination | request | % | hit-% | sec/req | Byte | % | hit-% | kB/sec |
---|---|---|---|---|---|---|---|---|
*.as.com | 19256 | 31.45 | 73.76 | 0.34 | 14285790 | 1.75 | 32.24 | 2.11 |
*.prisacom.com | 6695 | 10.93 | 0.00 | 0.01 | 1392560 | 0.17 | 0.00 | 35.07 |
*.marca.com | 2956 | 4.83 | 51.39 | 1.23 | 11402986 | 1.39 | 55.37 | 3.07 |
*.google.es | 2234 | 3.65 | 2.64 | 0.73 | 2149657 | 0.26 | 8.74 | 1.30 |
*.google.com | 1637 | 2.67 | 3.97 | 14.78 | 11503326 | 1.41 | 5.08 | 0.46 |
*.google-analytics.com | 1275 | 2.08 | 0.00 | 3.52 | 735943 | 0.09 | 0.00 | 0.16 |
*.premiumtv.co.uk | 1083 | 1.77 | 0.00 | 1.92 | 280490 | 0.03 | 0.00 | 0.13 |
apezz.com | 954 | 1.56 | 79.04 | 0.57 | 2828761 | 0.35 | 6.47 | 5.10 |
*.2o7.net | 632 | 1.03 | 0.00 | 0.01 | 131546 | 0.02 | 0.00 | 33.99 |
*.wunderloop.net | 621 | 1.01 | 0.00 | 0.00 | 129198 | 0.02 | 0.00 | 46.68 |
He marcado en rojo aquellos dominios que me llamaron mucho la atención. Investigando cada uno de ellos ví que unos eran gestores de estadísticas (207.net y wunderloop.net), que premiumtv.co.uk era la televisión online que utilizaba As para sus videos y que prisacom era la empresa que poseía dichas webs.
Pero detrás de todo esto hay mucho más, resulta que el numero de peticiones es una burrada, estan marcados en verde el número de peticiones web. Utilizando el log de Sarg pude ver miles de líneas como las siguientes:
http://petra.prisacom.com/RealMedia/ads/adstream.track/1471560644?
http://ads.prisacom.com/RealMedia/ads/adstream_nx.ads/www.as.com/portada/1987259978@Middle,Position1,Top,x02,x03,x05,x06,x08,x09!x03?
http://tu.connect.wunderloop.net/TU/922/2396/8095/?
http://ds.serving-sys.com/BurstingScript/ebBannerServing_1025909.js
Todas relacionadas con publicidad, en concreto de las dos primeras hay una auténtica salvajada de peticiones, más que de as.com.
Bueno, la primera acción a tomar está clara, hacer que todos esos dominios de publicidad apunten al servidor local. Editamos el archivo /etc/dnsmasq.conf como antes y añadimos lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
address=/doubleclick.net/192.168.1.1 address=/ads.prisacom.com/192.168.1.1 address=/safebrowsing-cache.google.com/192.168.1.1 address=/safebrowsing.cache.l.google.com/192.168.1.1 address=/safebrowsing.clients.google.com/192.168.1.1 address=/petra.prisacom.com/192.168.1.1 address=/247realmedia.com/192.168.1.1 address=/2o7.net/192.168.1.1 address=/ads.prisacom.com/192.168.1.1 address=/flashtalking.com/192.168.1.1 address=/serving-sys.com/192.168.1.1 address=/connextra.com/192.168.1.1 address=/wunderloop.net/192.168.1.1 address=/imrworldwide.com/192.168.1.1 |
De esta forma, todas las solicitudes se realizarán contra nuestro servidor apache. Hay que tener en cuenta que todos los subdominios de los dominios que redireccionemos también estarán redireccionados (si añadimos 2o7.net, también estará añadido ads.2o7.net, por ejemplo…). El problema está (y no tardaréis mucho en daros cuenta si sólo haceis esto) en que no existe ninguna de estas páginas en nuestro servidor. En algunos banners que son de texto se visualiza el error 404 Página no encontrada, cosa que no queda nada bien… además de que se nos inundan los logs con basura y peticiones inexistentes.
Lo que vamos a hacer es crear un dominio virtual en el apache para que atienda todas estas peticiones. Todas las peticiones realizadas contra la IP 192.168.1.1 que no vengan de un dominio que esté en otro host virtual configurado en el apache, serán tratados por esta configuración por defecto (no vamos a incluir el ServerName en las directivas).
En la tabla anterior teneis en color naranja el tiempo que tarda una vez redireccionada la petición (ahora es instantánea) y los bytes que genera (muchísimos menos que antes, sale un promedio de 208 bytes por petición 😎 ).
Seguimos, empezamos creando un nuevo archivo en /etc/apache2/sites-availiable/ (por ejemplo ‘default‘) con la siguiente configuración:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
ServerAdmin webmaster@localhost DocumentRoot /var/www DirectoryIndex index.html Options FollowSymLinks AllowOverride None DirectoryIndex index.html Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all ErrorLog /var/log/apache2/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/access.log combined |
Creamos un enlace blando a esta configuración en /etc/apache2/sites-enabled para activar el sitio, y otro enlace blando del módulo rewrite y ya podemos reiniciar el servicio:
1 2 3 |
debian:/# ln -s /etc/apache2/sites-availiable/default /etc/apache2/sites-enabled/default debian:/# ln -s /etc/apache2/mods-availiable/rewrite.load /etc/apache2/mods-enabled/rewrite.load debian:/# /etc/init.d/apache2 restart |
Ahora que funciona el servidor (podemos probarlo entrando en http://192.168.1.1), tenemos que crear una página vacía y añadir unas reglas para el mod-rewrite para que cualquier archivo solicitado sea devuelto como un archivo de longitud 0:
1 2 |
debian:/# touch /var/www/index.html debian:/# vi /var/www/.htaccess |
Ahora en el archivo .htaccess escribimos lo siguiente, esto redireccionará cualquier petición al archivo index.html que acabamos de crear:
1 2 3 |
Options +FollowSymLinks RewriteEngine on rewriterule ^.*$ index.html [L] |
Ya está, si probamos a abrir ahora alguna de las páginas analizadas por Sarg veremos que devuelve una página en blanco.
Probando con el navegador, por ejemplo, la web de As se ve así (fijaos en la cantidad de Click! Click!):
Listo, ya está funcionando. Con esto también se puede gastar alguna broma o hacer alguna travesura 😮 «¡Han hackeado Google!» :-o, 😮 «¡Microsoft vende Linux!» :-o, etc… 😉
Espero que os haya gustado. 🙂
Pingback: meneame.net
Pingback: Cómo bloquear la publicidad en Internet sin plugins y con facilidad
Pingback: auladigital.com
Pingback: TOR – La cebolla enrutadora al rescate | Reprogramador.es