Categoría: Internet

Temas relacionados a TCP/IP, WEB y tecnologías afines.

Google Chrome el nuevo navegador

El día de hoy (1 de setiembre), he tratado de descansar un poco luego de un fin de semana bien trabajado . Una consolidación y reubicación de servidores me ha tenido trabajando hasta hoy por la tarde, sin embargo de lo que he visto en las noticias, mañana será un gran día porque estará disponible para descarga Google Chrome (el nuevo navegador de Google) en más de 100 países, aunque por el momento sólo disponible para Windows, con versiones para Mac y Linux en camino pronto, al menos es lo que ha anunciado Google.

Hasta donde he podido leer el nuevo navegador de Google, no estará basado en Gecko como Firefox, sino que han elegido Webkit, el motor de renderizado de Konqueror (el navegador de KDE) y Safari (el navegador de los Mac), pero añadiéndole un interprete JavaScript llamado V8 desarrollado por la gente de Google, supongo yo que con la idea de optimizar la performance de aplicaciones Ajax como son Google Apps y Google Gears.

Dado que Google está apostando que la próxima plataforma será la red, el browser vendría a jugar el papel del nuevo sistema operativo, por lo tanto ser el dueño de la plataforma definitivamente da ventajas, como ya lo ha demostrado Microsoft con Windows en los noventas, y al parecer Google quiere aplicar la misma estrategia.

Aunque por lo pronto el segmentado mercado de navegadores donde están IE, Firefox, Safari y Opera, recibirá a Chrome con expectativa, no será fácil para este recién llegado hacerse de un lugar. Pero no dudo que con suficiente tiempo, veremos cómo se reacomodan las fuerzas. Al final todo dependerá de que tanta aceptación tenga el nuevo navegador en el mercado, por lo pronto los usuarios de Google Apps, serán los primeros beneficiados de este nuevo producto Google.

Lo gracioso de la presentación de Chrome al público en general el día de hoy ha sido que se ha hecho a través de un comic (se puede leer el PDF desde aquí), y no a través de uno de los clásicos Google Camps.

Estoy impaciente por ver que tan bueno es Chrome, y sobre todo ver como reacciona Microsoft, que justo el viernes pasado desilusionó a muchos de los usuarios de IE, cuando comenzaron a circular las primeras quejas de que IE8 no respetaría los estándares en su configuración por defecto. Y para el caso de Firefox, cómo harán para compatibilizar el hecho de que uno de sus principales financistas ha decidido entrar de lleno en su nicho de mercado. Todas esas dudas las iremos resolviendo en el transcurso de los próximos meses, por lo pronto a esperar pacientemente y preparar una máquina virtual con XP para poder probar Chrome mañana temprano.

Publicado el por volkan68 0

Una increíble forma de esclavitud digital

El día de hoy leí un muy interesante artículo en el blog Zero Day en ZDNet, sobre el negocio de romper la seguridad de los CAPTCHA en India, lo cuál me mostro como la revolución digital que ha traído el Internet a la vida de millones, puede llevarnos a cosas tan extremas como la explotación del hombre por el hombre, que todos creíamos superada hace varias décadas.

Primero hay que explicar que es CAPTCHA para los no entendidos. Bueno CAPTCHA es la abreviatura de "Completely Automated Public Turing test to tell Computers and Humans Apart", el "Test de Turing" o "Prueba de Turing" es el procedimiento desarrollado por Alan Turing para corroborar la existencia de inteligencia en una máquina. Fue expuesto en 1950 en un artículo (Computing machinery and intelligence) para la revista Mind. Se fundamenta en la hipótesis positivista de que, si una máquina se comporta en todos los aspectos como inteligente, entonces debe ser inteligente. Hasta la fecha no se puede desarrollar un algoritmo que pueda comprender la escritura manual de todo ser humano y por extensión si se ditorsionan letras rotandolas, alargandolas, invietiendolas o ensuciándolas una computadora no podría reconocerlas incluso si son generadas aleatoriamente por otra computadora, porque es incapaz de separar el ruido del mensaje, pero un humano sí puede hacerlo. Ese es el principio usado tanto por Google, Yahoo o MySpace para no permitir que un robot cree millones de cuentas para luego usarlas como plataforma de spam.

En la práctica el CAPTCHA es imposible de romper por una computadora, pero sencillo de resolver incluso para niños de 9 años. Debido a ello miles de compañías indias entre ellas decaptcher.com, ofrecen su servicio de descifrado de CAPTCHA por la módica tarifa de $2 por cada 1000 CAPTCHAS vulnerados, ¿cómo es posible ésto?, ¿acaso han descubierto cómo simular inteligencia humana en una computadora?, lamentablemente no. Lo que hacen es ser un intermediario entre los clientes (spamers) y los proveedores del servicio (desesperados tele-trabajadores). Para tal fin la empresa provee un API que permite desarrollar aplicaciones que toman el CAPTCHA generado por Google, MySpace, etc., y lo envía a ser procesado por los proveedores que son un grupo numeroso de digitadores mal pagados que reciben la imagen y escriben la solución que es enviada de vuelta al cliente, el sistema cuenta cuántas CAPTCHA exitosas se realizarón y se le factura el cliente, que usualmente es un spamer profesional.

Piensa Ud. que es una forma fácil de hacer dinero, pues le comento que no lo es. Considere ésto, aún si los $2 se los lleva el digitador (falsa suposición porque la mayor parte se la lleva el intermediario) el esperar por un CAPTCHA y tipear las letras correctas ( usualmente 6 u 8 ) no se puede hacer en menos de 30 segundos, de esa forma un digitador trabajando 8 horas al día sólo podría resolver 960 CAPTCHAS (8 horas x 60 minutos/hora x 2 CAPTCHA/minuto) asumiendo una eficiencia del 100%, así que en el mejor de los casos un obrero digital tendría que pasar más de 8 horas al día para hacer solamente $2 diarios, asumiendo que no se equivoca en ningun CAPTCHA y recibe todo el dinero pagado por el cliente.

Como vemos en este caso Internet esta permitiendo que se explote a millones de digitadores con salarios realmente bajos. Parte de ésto es posible debido a que la industria de los rompedores de CAPTCHA de la India, esta camuflada detras de la legal actividad del procesamiento de datos, y muchos de ellos incluso disfrazan su ilegal actividad aduciendo que ayudan a los impedidos (ciegos) a crear sus cuentas de correo. Parte del problema es que este negocio reposa sobre la base de miles de pequeños "emprensarios", con 10 a 30 PC, que compran el servicio de proxy de compañías como decaptcher.com, haciendo de ésta forma muy difícil parar esta ilegal actividad.

En el blog Zero Day, aparecen varios de los pantallazos de los terminales de los digitadores, así como muestras de cómo estos pequeños negocios se publicitan por Internet, incluso hay uno afirma poder romper 700 mil CAPTCHAS diariamente. Espero nomas que éste lamentable ejemplo de como usar la tecnología no sea usado en el Perú, debido a las similitudes entre Perú e India, como son fácil acceso a Internet, un gran númerod e personas entrenadas en el uso de una computadora y sin trabajo.

Publicado el por volkan68 2

Haciendo tuneles con OpenSSH

En los últimos días he estado ocupado reubicando servers, y uno de los problemas que tuve es que ciertas aplicaciones usan el IP en lugar de nombre para hacer referencia al servidor, ésto hace imposible el asignar un nuevo IP, sin cambiar la aplicación. La única solución que encontre fue crear tuneles a un server que tuviera todas las IP’s que necesitaba, para luego hacer un forward de todos los paquetes IP a través de los tuenel que había creado. Como siempre digo, para que me sirva en un futuro a mi, y a cualquier otro que necesite resolver un problema similar, aquí les detallo como crear un tunel usando el OpenSSH que es una aplicación Open Source y que ofrece esta opción desde su versión 4.3, para desarrollar este tutorial me he basado en otro que encontré en inglés aquí.

Manos a la obra, primero comencemos instalando los siguientes paquetes:

# apt-get install vtun bridge-utils openssh-server openssh-client openssh-blacklist

Asegurarse de que en ambos equipos aparezcan estas líneas en el archivo /etc/ssh/sshd_config:

PermitRootLogin yes
PermitTunnel yes
Asegurarse de que en ambos equipos el forwarding entre interfaces este habilitado:

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

Luego de lo anterior debemos de crear el tunel desde el equipo que este en la nueva red con éste comando (asumiremos que 123.123.123.123 es el IP antiguo):

# ssh -N -w 0:0 root@123.123.123.123&

Ahora hay que asignar a cada equipo un IP privada para cada extremo del tunel, para nuestro caso:

En el server con IP antigua:
# ifconfig tun0 10.0.0.1 netmask 255.255.255.0

En el server con IO nueva:
# ifconfig tun0 10.0.0.2 netmask 255.255.255.0

Finalmente en el equipo que tiene la IP antigua debemos de hacer el port-forwarding y el enmascarado de la interface del tunel (la idea es hacer un NAT, para que los paquetes generados por el server con la nueva IP sean enviados de vuelta por el tunel), para ello ejecutamos éstos comandos:

# iptables -F
# iptables -t nat -F
# iptables -t nat -A PREROUTING -p tcp -d 123.123.123.123
–dport 80 -j DNAT –to 10.0.0.2:80
# iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Ya esta listo, ahora si abrimos en un browser el URL: http://123.123.123.123 (asumiendo que ese sea el valor de la antigua IP) veremos el webserver que tiene la nueva IP.

Lo anterior también funcionaría si desearamos asignarle IP público a un equipo que esta detras de un NAT.

El port forwarding es hecho por puerto, así que no se olviden de crear una regla para cada servicio que quieran ofrecer.

Aquellos que deseen automatizar el proceso con un script y necesiten crear la conexión ssh sin introducir el password manualmente, pueden seguir éste tutorial que explica como establecer una conexión ssh sin necesidad de tipear el password manualmente.

Finalmente, algo que olvidé mencionar al inicio es que este tutorial esta basado sobre Debian, se puede usar lo mismo sobre Ubunto añadiendo "sudo" al incio de cada domando, y en otras distribuciones haciendo la instalación de OpenSSH 4.3 o superior y de TUN/TAP.

Espero que toda ésta información les haya sido de provecho, y les pueda haber ahorrado algún tiempo googleando. Cuálquier comentario o sugerencia para mejorar el contenido de este howto sera bienvenido.

Publicado el por volkan68 0

Los e-mails privados de Hugo Chávez en subasta

ChavezÉsta noticia si que me hizo reir, los amigos de Wikileaks, una web que se ha hecho famosa por presentar información confidencial como el manual de operaciones de la base de Guantánamo, o documentos secretos de la Iglesia de la Cienciología, ahora se han hecho del correo privado de Hugo Chávez entre el 2005 y el 2008 y como una forma de financiar su operación están subastando la exclusiva, aunque eventualmente en un futuro próximo ésta información será publicada en el website, al menos eso es lo que opinan en Wired.

Según comenta Wired, una de las figuras más prominentes de Wikileaks, Julian Assange, ha aceptado que el modelo de negocios en dicho portal ha fracasado y comenzarían ha experimentar nuevas formas de encontrar financiamiento, al parecer la subasta de los correos privados de Chávez sería una de las formas de Wikileaks de tratar de sufragar sus gastos de defensa legal, ya que el filtrar información tan sensible le ha ganado poderosos enemigos.

Lo que me llama la atención en todo caso no es Wikileaks este subastando la información en lugar de publicarla de una vez, eso es una decisión de ellos. Lo realmente increíble para mi es lo inocentes/cándidos que son los asesores cubano-venezolanos de seguridad informática del presidente Hugo Chávez, que no recomendaron usar PGP para el envío de su correspondencia personal. Por todos es sabido que el protocolo SMTP no es seguro, absolutamente toda transferencia es en texto claro, y usar Internet sin cifrado en general tampoco es seguro porque cualquiera puede oir lo que uno esta escribiendo, como lo demostro Alex Pilosoft y Anton Kapela, mostrando lo vulnerable del protocolo BGP en el último Defcon, así que me parece un poco contradictorio que justamente sean gobiernos que se califican como enemigos de Washington y presidentes que dicen ser objetivos de la CIA, no tomen la precausión de cifrar su correo personal. Pero a decir verdad, nada de eso me sorprende de la "inteligencia" cubano-venezolana, que sólo puede tener relativo éxito reprimiendo a sus ciudadanos, pero no contra una estructura de inteligencia extranjera, incluso de ciudadanos medianamente entrenados en temas informáticos, como lo ha demostrado la comunidad de Wikileaks.

En fin, esperare hasta que los e-mails se hagan públicos y me deleiraté leyendo lo que Chávez no quiere que sepamos, siempre es interesante ver lo que una figura pública hace cuando tiene la idea de que nadie lo observa. ¿Sera cierto que lo que hay entre Chávez y Fidel es "amor pulo y veldadero"?, ojala los e-mails nos ayuden a resolver ese misterio.

Publicado el por volkan68 0

Grave falla en el diseño del protocolo BGP podría colapsar Internet

Aunque no se ha hecho mucha propaganda sobre el asunto, la falla de diseño del protocolo BGP explotada por Alex Pilosov y Anton Kapela, que permite escuchar todo el tráfico de una red bajo la modalidad de man in the middle y que fuera motivo de su disertación en el último Defcon de Las Vegas, poco a poco comienza ha conocerse a través de los medios, al menos de los medios espacializados, porque justo el día de hoy (27 de agosto) he visto que Kim Zetter ha blogueado sobre el tema en los blogs de la revista Wired.

El asunto había pasado más o menos desapercibido hasta hace poco, eclipsado por el más publicitado problema con el protocolo DNS que fuera expuesto en el mismo evento por Dan Kaminsky y al cual le dedicáramos el post "Toda la verdad sobre la vulnerabilidad de los DNS". Pero como dice Peiter Zatko, éste problema con el protocolo BGP es mucho más grave que el de los DNS y tiene la capacidad de colapsar toda Internet en menos de 30 minutos si es convenientemente explotado. Pero antes de que la desesperación cunda, y los profetas del desastre comiencen a comentar sin saber de que se trata dedicare unas líneas de éste post a explicar cuál es el problema, por qué es un problema y bajo que condiciones puede aprovecharce esta devilidad del protocolo BGP.

En primer lugar hay que entender que el protocolo BGP está diseñado para permitir el ruteo de una "red" sobre multiples enlaces, así si uno de los enlaces cae el tráfico puede ser re-enrutado por otro, para ello la "red" que se re-enruta debe poseer un ANS (Autonomous System Number), que es asignado por IANA, el protocolo BGP confía en que todo router que forma parte de este anillo de super-routers de proveedores de Internet, es confiable y enviará la información correcta sobre los enlaces y las redes asociadas a los mismos. Por diseño del protocolo se supone que todos los routers que usan el protocolo BGP diran la verdad. En el experimento conducido por Alex y Anton, lo que se hizo fue introducir una ruta falsa (haciendo un spoofing del IP real del router dueño de la red que se pretende secuestrar, creado una paquete BGP manipulado) y forzar a que todo el tráfico fuera re-enrutado a través del data center de Alex en New York, en el cuál la empresa donde trabajo tiene hosteado sus racks (dicho sea de paso conozco a Alex Pilosov personalmente). Ésto fue posible por dos cosas, primero el hecho de que Alex tiene acceso a un router BGP reconocido por todos los proveedores Internet, y segundo a que cuenta con bastante ancho de banda para que la nueva ruta no sea más costosa en términos de tiempo y sólo añada un salto más a la ruta original. Osea que cualquier aprendiz de brujo que crea que puede colapsar Internet desde su línea ADSL es tan fantacioso como aquel adolescente que creía que era cierto que desde un Altair 8800 se podía iniciar la tercera guerra mundial así como en la película "Juegos de Guerra". El protocolo tiene una falla sí, pero es explotable sólo desde un router que pertenezca a un proveedor de Internet importante.

En teoría un terrorista que tuviera acceso a uno de estos routers principales, podría enviar información de rutas ciclicas, que colapsarian el tráfico porque enviarian los paquetes a un loop sin fin entre una pareja o trio de routers, claro sólo hasta que se reinicie el router que esta confundiendo a los demás. Es sólo un ataque que teóricamente es posible, pero dado a que los routers BGP en Internet son sólo unos miles, es relativamente fácil detectar al culpable.

Es por ello que si quiere estar seguro de que la información que esta transmitiendo por Internet esta segura, y Alex no la está escuchando , use protocolos de encriptación como SSL, así si alguién esta escuchando el tráfico sus claves e información personal no viajara en texto claro. Así que concluyendo aunque la falla de diseño del protocolo lo expone a un ataque que podría afectar a millones de usuarios, éste ataque sólo puede realizarce desde un lugar específico, el cuál puede ser custodiado.

Publicado el por volkan68 0