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).
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.
Hoy no he podido contener la emoción al descubrir fonYou… fijaos 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…
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:
Aunque sea un poco tarde no quiero dejar de desearos una Feliz Navidad desde SendaOscura.
Y como el post se me queda muy corto, voy a contaros algo que paso hace muchos años en un lugar muy lejano…
Tal día como hoy los expertos en seguridad de una importante compañía que contaba con los más sofisticados sistemas de protección, salían a toda prisa para acabar las últimas compras navideñas. Les esperaba una larga noche, muchos regalos que colocar bajo el luminoso árbol para que al día siguiente sus pequeños retoños disfrutaran de la ilusión de todos los años. Estando la empresa desierta y todos los expertos con otros asuntos de los que ocuparse, nadie notó como todas las alarmas saltaban. Como los IDS no dejaban de detectar firmas de ataques y como tras muchos intentos, uno de los servidores cayó bajo el control de aquella fuerza misteriosa.
Sí, fue una noche larga, por un lado los regalos se amontonaban junto al árbol, por el otro varios sistemas caían al son del Jingle Bells, Los logs amontonaban información del ataque, pero no había nadie allí para hacer nada. Hubo varios intentos infractuosos de un IPS por evitar al intruso, pero con tanto tiempo por delante nada podía impedir aquella fuerza destructora.
A la mañana siguiente, mientras los expertos en seguridad de la compañía se volvía locos intentando descifrar los manuales de esos raros juguetes en algún idioma exótico, los logs seguían incrementándose. El ataque no acabó hasta la madrugada del día 26. Ahí quedaban muchos logs y unos cuantos servidores maltrechos para demostrar lo que había pasado, pero ya era demasiado tarde para alcanzar al hábil intruso.
No lo olvidéis, hay algunos que no toman vacaciones, que no descansan nunca, que viven por y para superar retos imposibles. Es difícil encontrar a gente así entre los ‘buenos’, sin embargo hay muchos que viven con la única ilusión de que su gesta perdure para siempre en las crónicas del underground. Gente que no descansa hasta alcanzar su objetivo y que cuando lo consiguen se imponen uno mayor.
Es bueno no olvidar esto y procurar que las guardias del día de Navidad le toquen a algún compañero
Hace unos meses recibí una oferta de trabajo como mínimo curiosa, el entrevistador me estuvo hablando de lo maravillosa que era su empresa y de las grandes inversiones que estaban haciendo en nuevas tecnologías, me dijo que estaban montando una nueva red de “fibra oscura”, aclarándome que este tipo de fibra le estaba ganando la batalla a la antigua. ¿Oigo alguna carcajada?
Para todos los que no estén familiarizados con la fibra óptica aclararé que este es una de los medios más rápidos (y caros) para transmitir grandes cantidades de información. Según la wikipedia
La fibra óptica es un hilo de ondas en forma de filamento degradado, generalmente de vidrio, aunque también puede ser de materiales plásticos. La fibra ocular es capaz de dirigir la luz a lo largo de su longitud usando la reflexión total interna. Normalmente la luz es emitida por un láser o un LED.
Y es que precisamente para que la fibra transmita datos tiene que existir luz en su interior… al fin y al cabo se trata sólo de un material con unas capacidades de reflexión muy especiales. Es la modulación de la luz la que permite transportar la información. Las fibras que no se están usando no tienen luz, por eso se las llama “fibras oscuras”. Efectivamente, fibra oscura es aquella que no se usa… así de claro.
No es la primera vez que escucho a alguien hablar de fibra oscura como si de otra tecnología se tratase, parece que el término suena muy bien a todo tipo de personal no técnico, por eso se usa tanto y tan erróneamente.
La próxima vez que escuchéis hablar de fibra oscura prestad atención a la persona que lo dice, seguramente no tiene ni puñetera idea de lo que está diciendo.
Ésta suele ser una de las quejas más comunes en estos días en los que las tecnologías inalámbricas se extienden como la pólvora. Si eres uno de los que tiene ese problema, estás leyendo justo lo que necesitas.
Las redes inalámbricas que tenemos en casa utilizan variantes del estándar IEEE 802.11, posiblemente 802.11b o g. Estas redes trabajan en la banda de los 2,4GHz, conjunto de frecuencias de libre utilización. El estándar b permite alcanzar velocidades teóricas de 11Mbit/s, mientras que con el g el máximo se eleva a 54Mbit/s. Obviamente estamos hablando de máximas teóricas, en la práctica las velocidades suelen estabilizarse alrededor de los 5 Mbit/s para b y los 20 Mbit/s para g. Ten en cuenta que las medidas están dadas en Mbit/s, si las quieres en MByte/s (que es lo que suelen ofrecer los programas de descargas) tienes que dividirlas entre 8 (Ej. 20*1024/8 = 2560, es decir unos 2,5MBytes/s) . Aclaro esto porque lleva a muchas situaciones engañosas y falsas expectativas.
Si a pesar de lo anterior consideras que tu red wifi funciona a una velocidad muy inferior a la esperada, entonces debes prestar atención a los dos factores fundamentales que definen el ratio de transmisión: la fuerza de la señal y el ruido.
La fuerza de la señal es más intensa cuánto más cerca estemos del punto de acceso, lo que es totalmente obvio y conocido por todos. Lo que quizás no sepa todo el mundo es que las velocidades de transmisión están intimamente ligadas a la fuerza de la señal (el ratio de transmisión es mucho mayor con una cobertura del 90% que con una del 20%). Este factor es simple de entender y controlar, colocando el punto de acceso más cerca de nuestros equipos o usando una antena con más ganancia podemos fácilmente aumentar la velocidad de la red.
El ruido sin embargo es harina de otro costal y me consta que es aquí en donde tienen problema la mayoría de los usuarios de estas redes. El estándar 802.11b/g define un total de 11 canales (13 en Europa) en la banda de los 2,4GHz. Sin embargo sólo 3 de ellos son enteramente independientes: el 1, el 6 y el 11 (algunos estudios demuestran que se pueden usar los canales 1, 5, 9 y 13 sin interferencias relevantes). Usar otros canales puede producir solapamiento de frecuencias. Así pues, cuando montamos una red es conveniente decidir con cuidado en que canales ponemos nuestros puntos de acceso, sobre todo si tenemos más de uno, ya que entonces es de vital importancia que los pongamos en canales distintos no solapados.
Hasta ahora bien, pero ¿Qué pasa con nuestros vecinos? Las interferencias producidas por las redes colindantes hacen que la velocidad de la nuestra se degrade notablemente. Ocasionalmente realizo estudios de cobertura para clientes y me he llegado a encontrar con casos en los que a pesar de que la fuerza de la señal era excelente, había un nivel de interferencias tan severo que el ratio de transmisión se reducía a cero en algunas zonas. Así pues, el primer paso antes de colocar un punto de acceso es determinar que frecuencias se están utilizando en el área en la que queremos dar cobertura y luego elegir aquella que produzca el menor nivel de interferencias. Para detectar las frecuencias en las que emiten los puntos de acceso que tenemos cerca recomiendo usar kismet para Linux o kiswin que es el port para Windows. A nivel profesional y para realizar estudios de cobertura más complejos utilizo Ekahau, que es un producto comercial pero tiene disponible una versión de evaluación para los que quieran experimentar un poco.
En el siguiente gráfico se puede ver la distribución de canales y cómo se solapan, cuando no encuentres ninguna frecuencia libre de interferencias, intenta elegir una que las minimice.
Canales 802.11 (USA)
También os dejo un gráfico que he encontrado en la web de Cisco y que resalta mejor el solapamiento de frecuencias.
Solapamiento de canales
Por último también es importante saber que muchos aparatos electrónicos usan la banda de frecuencia de los 2,4GHz y que por lo tanto podrían producir interferencias en nuestra red. Los teléfonos inalámbricos, el microondas y los dispositivos bluetooth son algunos de los productos que se mueven en estas frecuencias. Así que si os estáis preparando una pizza y deja de funcionar la red, ya sabéis por qué es.
¿Os gusta el nuevo estilo? Ya que tenía que actualizar a la nueva versión del Wordpress, aproveché la ocasión y he cambiado un poco la apariencia del blog.
Por otra parte y gracias a la colaboración de mi buen amigo Yeray, SendaOscura ya tiene su propio logo. Os adelanto que estoy trabajando con Yeray en otro proyecto que espero vea la luz lo antes posible, aunque la verdad es que los dos estamos liados y no sé cuánto tardaremos en poner las cosas en marcha.
En los próximos días veréis algún que otro pequeño cambio en el blog, nada importante, pero son cosas que quiero dejar hechas antes de continuar posteando nuevo contenido. Pero tranquilos que no voy a tardar mucho y además tengo un montón de artículos en el tintero.
¡¡Lo hemos conseguido!! SendaOscura.com lleva un año en la red
Hoy hace exactamente un año que escribí mi primer post y la verdad es que mucho ha llovido desde entonces. El blog ha pasado por buenos y malos momentos, incluso hubo ocasiones en que estuve a punto de abandonarlo. Agradezco mucho las palabras de ánimo que algunos me dieron entonces. También estoy muy agradecido a aquellos que constantemente me piden más posts, siento que vale la pena escribir. Y es que lo más triste de llevar un blog es no saber si alguien te lee, si sirve de algo el esfuerzo y el tiempo empleado en él. Afortunadamente entre todos me habéis demostrado que esto merece la pena, así que mientras alguien me lea yo pienso seguir escribiendo
Al principio el blog tenía un marcado enfoque técnico, demasiado técnico me atervería a decir. Poco a poco he visto que no es eso lo que queréis, al fin y al cabo tutoriales y consejos los podéis encontrar en todos lados. Me llamó mucho la atención que uno de los posts más apreciados por la mayoría fuera Persiguiendo a un script kiddie. Aunque no sea el post con más comentarios, sí que es cierto que muchos me dijistéis personalmente que os gustó bastante. En los últimos posts he decidido darle un enfoque más humano al asunto y creo que esa es la tendencia que seguiré en este segundo año de vida del blog. Eso no quiere decir que no vayáis a ver posts técnicos, como en la fábula de la rana y el escorpión, yo tampoco puedo evitarlo, es mi naturaleza.
No me enrrollo más, celebremos este primer año de vida del blog.
Hace unos días visité el CPD de un cliente y por fin vi los famosos Blade de los que tanto había oído hablar. Para entender el por qué de los Blade basta imaginar la siguiente secuencia lógica de acontecimientos. Primero habilitamos un espacio de nuestro edificio para un CPD, luego empezamos a meter servidores y llega un momento en el que el espacio se nos acaba. Entonces decidimos llenar el CPD con racks ya que así aprovechamos mejor el espacio. Pero se nos vuelve a acabar… entonces llega el momento de los Blade. Aunque a decir verdad los servidores Blade son mucho más que tener un montón de servidores en un espacio realmente rídiculo. Hay que cambiar el concepto de servidor que tenemos en mente…
Cualquiera familiarizado con la instalación de sistemas sabe que cuando se habla de instalar un servidor, no sólo se habla de colocar una máquina formada por procesador, memoria y disco duro (que es lo que se define como máquina de Turing desde un punto de vista abstracto), también estamos hablando de conectar unas fuentes de alimentación (normalmente redundadas), tarjetas de red, tarjetas de video, periféricos, etc.
Pues bien, un chasis Blade incluye todo esto que no es estrictamente necesario creando un entorno en donde los servidores son ‘pinchados’, y aquí por servidor me refiero a una máquina que sólo tiene procesador, memoria y disco duro (así que imaginad su pequeño tamaño). Todos los accesorios (fuentes de alimentación, tecnología de red, periféricos, etc.) están incluidos en el chasis y se proporciona de forma común para todos los servidores que se pinchen en él.
Una vuelta de tuerca más al concepto rack. Podéis encontrar más información en la wikipedia.
