domingo, 9 de octubre de 2011

La solidaridad en Facebook

Facebook es indiscutíblemente la red social más importante actualmente. Tiene sus cosas buenas y sus cosas malas, como todo. Lo bueno es que ayuda a unir a las personas, brindando un medio de comunicación que permite acercar virtualmente a gente que está geográficamente lejos. Entre las cosas malas, está el uso indiscriminado del servicio, tanto por parte de delincuentes como de instituciones, como herramienta para rastrear personas, obtener información sensible (ofrecida en forma inadvertida por los usuarios) y obtener lucro mediante el fraude.

El fraude más común en Facebook era el de ofrecer una aplicación que afirma poder brindar información sobre quién visitó tu perfil. Siendo que Facebook NO ofrece acceso a esa información mediante el API que permite crear aplicaciones para el mismo, es evidentemente imposible que alguien pueda escribir una aplicación así. ¿Como funciona este fraude? Simple: Alguien publica el acceso a la aplicación, y le avisa a otros que la misma existe. Por lo general la propagación de la noticia de la existencia de esta aplicación es viral, ya que a los incautos usuarios se les dan instrucciones para que reenvíen la invitación a la aplicación a todos sus contactos, facilitando el esparcimiento de la misma y su rápida expansión en cuestión de horas.

Las instrucciones siempre exigen presionar el botón "Me gusta", el cual supuestamente activa la funcionalidad o permite el acceso a la aplicación. También se exige que se le envíe el enlace a toda la lista de contactos, esparciendo el fraude. Aquí radica el propósito del mismo, ya que al presionar el botón, lo que se hace es inadvertidamente cargarle el "Me gusta" a algún sitio web o a alguna página que realmente no es interesante ni está relacionado con la función que supuestamente la "aplicación" provée, y además se le hace propaganda gratuíta entre todos los contactos a quienes se le envíe. De esta manera, a los incautos usuarios les queda "gustando" algo que realmente NO les gusta ni les interesa. La popularidad de ciertas páginas se debe jústamente a este tipo de fraudes.

Como los mismos usuarios se tornan en vehículos promocionales del sitio, el esquema del "Me gusta" se vuelve fructífero en pocas horas, dándole cierto prestigio popular y atrayendo a más víctimas. Esta es la forma más simple de fraude en Facebook.

Como Facebook plantea una filosofía conceptuamente benigna (somos "amigos", las cosas "nos gustan", etc.), es fácil que los usuarios se confundan y piensen que TODO lo que hay en Facebook lo es, lo cual alimenta la idea de que todo lo que allí aparece es creíble y confiable. Y jústamente por eso es que algunas personas inescrupulosas utilizan las herramientas que Facebook provée para obtener lucro engañando a los usuarios que visitan sus páginas.

Afortunadamente, Facebook provée un enlace en todas las páginas que permite "avisarles" que dicha página es fraude o spam, con lo cual podemos rápidamente "deshacer" la acción simplemente entrando en la página y presionando el enlace que dice "Ya no me gusta", y el que dice "Denunciar esta página". No siempre la gente de Facebook desactiva la página en cuestión inmediatamente, sino que hay un procedimiento de verificación que puede tomar algunos días, por lo cual hay que ser pacientes. Lo importante es avisarle al resto de los contactos a quienes se les haya "promocionado" el sitio que es un fraude, así ellos también podrán hacer su aporte y eliminar rápidamente la página fraudulenta.

La gran mayoría de estas páginas "solidarias" muestra alguna fotografía shockeante, generalmente de bebes o niños con enfermedades o deformaciones visibles, fotos que tienen como cometido generar compasión y pena. Esto produce en la mayoría de las personas, sobre todo en los que somos padres, el impulso de tratar de ayudar a los afectados, lo cual termina decantándose en seguir las instrucciones que la página indique como forma de ayuda. Por lo general, la ayuda que se pide consiste en hacer click en uno o varios botones "Me gusta", los cuales, tal y como indican las instrucciones, harán que "alguien" done una cierta cantidad de dinero (a veces especificada, a veces no) a los damnificados. Y esta es la primera señal de alerta que debería todo el mundo tomar en cuenta cuando se entra a alguna de estas páginas.

Es cierto, no cuesta "nada" hacer un click en un botón "Me gusta", y como no cuesta nada, casi todo el mundo sigue ciegamente las instrucciones sin preguntarse si quiera a qué le está haciendo click realmente. Además, la mayoría de los pedidos tiene frases como "Si no nos ayudas, no tienes corazón", o "Dios te ayudará por ayudarnos a salir adelante", o "Solo te pido que hagas un click para salvar una vida", etc., lo cual tiene como propósito generar culpa y remordimiento, lo que finalmente se traduce en clicks en los botones mencionados. Es necesario aclarar que la gente que hace este tipo de fraudes tiene claro cual es su público objetivo y que tienen entrenamiento en marketing e ingeniería social, así que no es dificil darse cuenta de porqué estos fraudes abundan y tienen éxito. Saben engañar y saben qué "botones" presionar en nuestro interior para generarnos la necesidad de ayudar.

Lamentablemente, el público en general no tiene idea de cómo distinguir entre un fraude y algo real, así que me dió por escribir este artículo, con la finalidad de ayudar a entender cómo funciona este tipo de fraude y cuales son los indicadores importantes que hay que tener en cuenta para poder saber si son fraudes o no.

¿Como darnos cuenta de si es un fraude?

1) Normalmente, estas páginas no tienen ninguna dirección de contacto real. ¿Qué podemos aceptar como dirección de contacto real? Nunca una dirección de correo electrónico. Tiene que ser una dirección física, calle y número, localidad, teléfono, etc. Si no tiene ninguna de estas cosas, ya se puede estar 99% seguro de que es un fraude. ¿Porqué? Porque si realmente necesitas ayuda, no tendrás reparos en darle a la gente una dirección donde poder hacer una donación o simplemente acercarse a "dar una mano", o un teléfono donde comunicarte y poder coordinar la ayuda. Una dirección de correo electrónico no es aceptable, y menos cuando se trata de una dirección de un servicio gratuíto, o de un servicio que no permite conocer el origen real del mensaje (como Gmail, por dar un ejemplo claro).

2) Mayormente, las páginas de fraude indican que por cada click que hagas en algún enlace, "alguien" les donará una cantidad de dinero. Estos esquemas solo funcionan en los casos en que el tráfico puede ser cuantificado en forma controlada y confiable, lo cual no es el caso en Facebook. Acuerdos de donación de este tipo están debidamente identificados y son extremadamente raros. Los fraudes generalmente citan empresas de gran envergadura (Microsoft, Hotmail, Yahoo, Facebook, Google, etc.) como benefactores, aunque esto se hace con el fin de dar a entender que se trata de una situación reconocida por instituciones de renombre, tratando de aprovecharse del prestigio de las mismas para proveer realismo al fraude. Es raro que estas instituciones accedan a ser parte de un esquema de "pago por click", así que si la única forma de ayudar consiste en eso, está claro que se trata de un fraude.

3) No suele haber más de una o dos fotos en un fraude, y tampoco hay información de estado de la situación, ni forma de hacerle un seguimiento a la misma. Los fraudes suelen tener "vida corta", aunque gracias a la velocidad de propagación en las redes sociales, ese poco tiempo les reditúa en forma inmediata y efectiva. Para el defraudador, es importante que ese único disparo surta efecto inmediatamente y luego sea olvidado sin más. Dado que la responsabilidad que le implica a las víctimas se reduce a hacer un click y la mayoría de las veces pide reenviarle el pedido original a todos sus contactos, estas creen haber ayudado con esas simples acciones y tienden a creer que "cumplieron" con las condiciones indicadas (y con su conciencia), olvidando rápidamente el asunto. Si no hay forma de hacer un seguimiento, es otro indicativo claro de que la situación planteada no es real.

4) El fraude suele tener incongruencias, faltas de ortografía, de redacción y de detalles. Nunca hay referencias importantes en otros sitios web confiables, y raramente hay fechas concisas en el texto, lo cual es importante para los defraudadores porque nos impide saber si estamos "a tiempo" de llegar con ayuda. Suele haber inconsistencias y hasta contradicciones en la historia, lo cual es otro factor a tomar en cuenta. Si la situación es real, habrá referencias reales e información precisa y confiable. Si no las hay, es un fraude.

5) Por último, si tenemos conocimiento técnico de la web, podemos hacer el análisis del código fuente de las páginas implicadas, lo cual nos dará a ciencia cierta indicadores inequívocos del verdadero propósito de las mismas. Esta suele ser la forma más segura de darnos cuenta, pero se sobreentiende que por lo complejo de su comprobación no será la forma más común de descubrir el fraude. Si Usted tiene dudas, puede consultar con un experto que le indique claramente la veracidad de lo que se plantea en una página. Ese puede ser el factor definitivo en la decisión de brindar "ayuda" o no.

Todo esto que planteo en este artículo es simplemente una herramienta para los interesados en estar informados a la hora de "dar ayuda". Como dicen ellos, hacer click no cuesta nada, y si les es más fácil hacer click que tomarse la molestia de leer estas indicaciones, no hay problema. A mi en lo personal no me gusta que haya gente que se aproveche de la bondad de otros, y menos utilizando fraudes que impliquen niños, así que aconsejo que tomen en cuenta lo que aquí expuse y se tomen el trabajo de analizar y verificar el destino y el tipo de "ayuda" que se plantean en este tipo de situaciones. ¡Ojalá ayudar fuera tán fácil como hacer click en el botón de una página web!

Como les digo eso, también les digo que si sienten la necesidad de ayudar sin mirar a quien ni cómo, están en todo su derecho, sin importar si los beneficiarios son reales o defraudadores. Si hacer click en una página les ayuda a dormir mejor, no me hagan caso. Como siempre les digo, puedo estar equivocado :-)



Addendum: Análisis de un fraude

Hace unos días apareció una página en Facebook invitando a los usuarios a un evento denominado "Ayuda a salvar a Carlitos". Esta es la URL original:

http://www.facebook.com/event.php?eid=273817502649634

Aquí les pongo una captura de pantalla para que vean cómo se veía la página, la cual ya denuncié y espero que quiten en breve.

Pido disculpas a mis lectores por hacerles ver la foto a continuación, pero creo que es necesario para que tomen conciencia de la dimensión que tiene el engaño y de la poca tolerancia que tenemos que tener ante gente que hace este tipo de cosas:



En la página de información del evento están los botones de "Me gusta" que supuestamente le redituarán a la familia del niño 5 centavos de dolar por cada vez que se haga click en ellos. Nótese que en la descripción del evento dice "5 centavos de dolar", mientras que en la página del usuario que creó el fraude dice "$$5". El texto describe la dolosa situación de una madre de 27 años cuyo hijo nació con un cancer en la lengua. El pedido termina con la frase "Si no ayudas honestamente no tienes corazón".

En la página se muestra el enlace "para ayudar", el cual lleva a la página
http://www.facebook.com/pages/Ayuda-A-Salvar-a-Carlitos/180327365381094, la cual en este momento se vé así:



Noten que en "Informacion" de la página no hay nada.

Como puede apreciarse, hay 9 botones "Me gusta", y supuestamente al hacer click en ellos, estamos ayudando. Examinando el código fuente de la página, podemos ver a donde apuntan estos enlaces realmente:



Esta es la lista de enlaces de los botones "Me gusta":

1) http://www.facebook.com/yo.tambien.miro.tuperfil.JAIROJDC
Si miran con atención, esta es una página que nada tiene que ver con una donación a Carlitos, ni nada que se le parezca. Es una página de negocios de una empresa denominada "Team Admin", que provée páginas de ocio y juegos, como hay miles en internet. Actualmente esta página tiene 535.097 seguidores, y 88.310 personas están "hablando" de ella. Resulta obvio de donde sale tanta "popularidad".

2) http://www.facebook.com/by.jairo.castillo
Esta página tiene nombre y apellido, y como podrán ver si entran, es otra página de la misma empresa anterior. A 433.398 personas les "gusta esto", y 44.852 están hablando de ella. Veo dificil que tanta gente disfrute al saber que sus clicks para Ayudar a Carlitos terminen alimentando los números de esta "empresa".

3) http://www.facebook.com/tipico.byJAIRO
Otra página más de la misma empresa. A 274.291 personas les "gusta esto" y 46.801 están "hablando de ella". Naturalmente, dudo que esas personas sepan realmente que esta página les gusta.

4) http://www.facebook.com/Verr.maass
Otra página más de esta "gente" (si se les puede llamar así). 223.302 incautos presionaron el botón me gusta en alguna página fraudulenta y 40.301 personas comentan la misma.

5) http://www.facebook.com/pages/ByJairo/240157339354570
Este enlace apunta al perfil de la persona que inició el fraude. Un tal "Jairo Castillo". Le escribí dos veces en su muro y el borró los comentarios. UPDATE: Acaba de aparecer otro perfil de este personaje: http://www.facebook.com/profile.php?id=100002294694471&sk=wall. Esta vez protegió su muro para evitar que le siga "mandando saludos". Naturalmente no me voy a hacer amigo de él para seguir publicándole lo que pienso.

6) http://www.facebook.com/pages/Yo-tambi%C3%A9n-quiero-ser-un-ni%C3%B1o-de-nuevo/281117895247003
Otra página más de este personaje. 164.921 usuarios engañados, y 37.964 comentando.

7) http://www.facebook.com/diariodiez
Es la página de un diario deportivo, seguramente un cliente de Jairo o un asociado. ¿Sabrán que parte de su popularidad se debe a un fraude? 90.805 víctimas y 12.475 usuarios comentandola.

8) http://www.facebook.com/pages/Prefieron-Un-minuto-Con-tigo-que-una-eternidad-sin-ti/223831821010906
Otra página tonta, que solo pone una frase en el muro de los usuarios a quienes les gusta. Otra vez se vé la referencia al creador del scam: Jairo Daniel Castillo. 14.706 víctimas engañadas y otros 7.765 comentando.

9) http://www.facebook.com/Amas.a.perry.By.AndreexD
Otra página más, aunque no está claro de quien es, ya que no hay referencias. Probablemente sea un "amigo" de Jairo, el cual le pidió una "mano" para popularizar su página. 167.191 usuarios engañados, y otros 88.413 comentando.

Bueno, como puede verse, los "Me gusta" terminan en páginas que está comprobado que no tienen nada que ver con Carlitos y su horrible enfermedad, sea cual sea.

Rastreamos al verdadero culpable, un defraudador llamado Jairo Daniel Castillo, hondureño, quien aparentemente basa parte de su negocio en el engaño, y podemos decir que ahora debe estar escondido en algún rincón de su casa tratando de evitarnos.

UPDATE: Este personaje, Jairo Daniel, me acaba de enviar una solicitud de amistad a través de Facebook, hoy 18 de noviembre de 2011. Me cuesta creer que sea tan arrogante como para creer que se la voy a aceptar. Acá está el perfil desde el cual quiere contactarme: http://www.facebook.com/Mr.Jairo.daniel. Si alguien quiere enviarle "saludos", ahí lo tienen. El "evento" que invita a ayudar a Carlitos fué dado de baja (no sé si hoy), pero NO la página principal, así que volví a denunciarla. Se vé que como en todos lados, la burocracia se toma su tiempo para arreglar las cosas que están mal. Por lo menos se bajó el evento... algo es algo.

Y por si queda duda de que este pedido de ayuda es falso, acá les posteo el lugar del cual sacaron la foto original, con datos reales y referencias:

http://patoral.umayor.cl/enfgen/enfgen.html

http://casodelmespatoral.blogspot.com/2008/02/caso-6-marzo-2008.html

Resulta que "Carlitos" es una niña africana después de todo.

Este tipo de personas son las que hacen lucro con nuestra solidaridad, así que ya saben, tengan cuidado y si quieren ayudar, busquen medios alternativos y ayuden a quien realmente lo merece.

Cambio y fuera.
:wq

sábado, 8 de octubre de 2011

¿Como no van a salir caros los lentes importados?

Hace unos días, perdí los lentes de práctica de tiro. Eran unos Guarder C3 Tactical Shooting Glasses, los cuales cumplieron su función perfectamente durante el tiempo que los tuve. Para peor, los usaba para andar en la calle ya que tenían un buen filtro solar y me quedaban cómodos como para conducir con ellos puestos. Después de todo, no necesitaba nada más complicado que un par de lentes de sol, y la protección extra que pudieran proveer me resultaba en un doble beneficio.

La cosa es que los perdí y no tengo idea de donde pudieron quedar, así que me puse en campaña para conseguir otro par de lentes con iguales o mejores características. Averiguando por lentes de buena calidad y alta protección balística (ya tuve un par de "accidentes" con armas y me quedó claro que la vista es el punto más vulnerable en estos casos), las mejores referencias siempre fueron para ESS (Eye Safety Systems), en cualquiera de las líneas que produce. Sus productos ofrecen una excelente protección balística, y cumplen (en exceso) con las especificaciones ANSI Z87.1+, OSHA y MIL-V-43511C, y son utilizados por las fuerzas de la ley, el ejercito y la marina en USA, así que decidí comprarme unos para probarlos.



He visto fotos de esos lentes, incluso después de un disparo directo de escopeta a 7 metros, y es increíble que las municiones no hayan podido atravesarlos. Hay varias historias de soldados que les envían cartas agradeciendo a ESS por sus productos, porque en incontables casos les ha salvado la vista. Mejores referencias no he visto en ningún otro lugar, ni con respecto a ningún otro producto.

De todos los que ESS fabrica, los que me parecieron más apropiados para mi caso fueron los ESS EyeShield ICE (Interchangeable Component Eyeshield) 2.4, ya que son modulares, cómodos y ofrecen un campo visual extendido, ideal para mantener una buena visibilidad (imperativo para situaciones de stress o ambientes en rápido movimiento, como la calle cuando uno maneja), así que preparé el pedido y los compré. No había muchas opciones para el shipping, así que el envío se hizo a través de FedEx.

Hace pocos días me llegó el aviso de que los lentes habían quedado retenido en Aduanas, así que tuve que hacer el trámite correspondiente. No es que no me lo esperara... son lentes muy específicos, aunque con los Guarder no me había pasado lo mismo. Esos habían venido directo por El Correo Nacional y no hubo misterios. Simplemente los trajo un cartero a la puerta de mi casa.

Como el paquete vino por FedEx, tuve que pasar por la oficina de ellos primero. A pesar de que el shipping ya estaba pago, tuve que desembolsar $ 950 por "gastos terminales y administrativos", lo cual me indignó hasta límites insospechados, sobre todo porque estos gastos únicamente me dieron acceso a una pequeña etiqueta autoadhesiva, sin la cual simplemente no podía siquiera iniciar los trámites de importación. ¿Como puede ser posible que FedEx me cobre en Uruguay algo que se supone que ya pagué en el país de origen?... Sinceramente, no lo entiendo. Considero que es un robo descarado, y debería ser delito, pero bueh... Vivimos en un país generoso. Hasta ahora, esta es la etiqueta más cara que he pagado...

Una vez con los papeles en regla, fuí a la oficina de Aduana, inicié el trámite y finalmente llegó el momento de verificar la carga. Esta tarea fué llevada a cabo por una agente verificadora de Aduanas, quien una vez que vió los lentes, dijo "Ah, son lentes de sol. Tienen que pasar por el Ministerio de Salud Pública."... Traté de explicarle que eran lentes de protección balística, y que como pensaba usarlos al aire libre, para evitar tener que usar lentes de sol encima o por debajo los pedí directamente de tinte oscuro. La verificadora me hizo ver lo fútil de mi explicación, ya que "obviamente son lentes de sol, y los tiene que ver el M.S.P.". Claro, debí suponer que explicarle a esta señora que esos lentes tenían características especiales más allá del simple filtro solar, era como tratar de enseñar a una ameba a hablar en griego...

Como sea, tuve que dejar los lentes en Aduana e irme al Ministerio de Salud Pública, donde hay una oficina que se dedica a la comprobación de la calidad de los productos, incluídos los lentes. Para mi sorpresa, allí me atendió una amable señora que me explicó la mecánica del trámite, los detalles, el costo y por si fuera poco, se solidarizó conmigo por la situación ridícula que estaba enfrentando. Todos conocen mis opiniones al respecto de los empleados públicos, así que fuí predispuesto a una larga sesión de espera infructuosa y a un desagradable período de tortura de manos de personas a quienes les pago el sueldo con mis impuestos... pero no, estaba equivocado. El trámite fué fácil y la atención un lujo, algo digno de una excelente empresa privada.

¿Porqué tuve que ir al Ministerio de Salud Pública?... Resulta ser que desde el año 2006 hay una ley que exige que todos los lentes que ingresen al país, cumplan con el requisito de tener filtro ultravioleta. El porcentaje de filtrado debe ser mayor al 95% para ser considerado aceptable. Para mis adentros pensé "¿Y qué pasaría si además se exigiera que dichos lentes soportaran un impacto de munición de .22 a 170 m/s?"... Estoy seguro de que muchos lentes no lo soportan.

Bueno, después de ir al M.S.P., fuí al aeropuerto de nuevo, a la fecha y hora que me dijeron que iba la persona que revisa los lentes y de nuevo pensé que iba a esperar horas, pero NO, apenas minutos después de entrar yo, aparecieron dos personas del M.S.P., portando una caja de 80x50x50 centímetros, conteniendo el equipo necesario para probar el filtro solar de los lentes. Entraron a la jaula (el depósito de la Terminal de Cargas del Uruguay) y me llamaron inmediatamente(!). Entré, abrimos el paquete (después de hacer el trámite de "apertura previa" en la Aduana), revisaron los lentes y me dijeron que fuera en unos días de nuevo al M.S.P. a buscar el certificado.

Fuí al M.S.P. cinco días después y me dieron el dichoso papel. Otra vez me atendió la misma persona, quien se acordaba de mi y me trató igual de bien que la vez anterior. Lo mejor de todo, es que no me cobraron el trámite (que suele costar una UR). Con ese papel volví a ir a la Aduana y finalmente pude hacerme de los lentes.

Como nota al margen, cabe destacar que el mismo día que fuí a buscar los lentes por primera vez, también me había llegado otro ítem que adquirí en el exterior (unos protectores auditivos Peltor de 26 db), y lo fuí a buscar a las oficinas del Correo Uruguayo, donde el trámite fué simple y fácil, y cuando le comenté a la persona que estaba a cargo del despacho la situación con los lentes, me dijo "Ah, no... acá si vienen lentes para particulares, los dejamos pasar. Si nosotros seguimos al pié de la letra todas las reglamentaciones del M.S.P., no podemos tampoco dejar entrar ni jabones, ni perfumes, ni shampoo, nada que toque la piel, así que imaginate..." (!!!).

Todo este tramiterío, idas y vueltas (tres veces a la Aduana, y dos veces al M.S.P.) sucedió en el correr de aproximadamente una semana. La verdad, me gustaron mucho los lentes, y no he visto acá en Uruguay ningunos que cumplan con todas las especificaciones de la misma manera, así que de alguna forma valió la pena... pero creo que no voy a volver a traer más, salvo que vengan por el correo uruguayo.

Y así ahora sabemos porqué los lentes importados salen tan caros...

:wq

jueves, 4 de agosto de 2011

There is no place like 127.0.1.50: Una historia de error

Hace tiempo que no escribo en el blog... pido disculpas a mis lectores, pero estuve inmerso en una maraña de sucesos que han hecho interesante mi vida más allá de todas mis expectativas... evitando que pudiera usar la computadora para otra cosa que no fuera trabajar (sin contar pequeñas pausas para no perder contacto vía FB...).

--

Muchas veces sucede que cuando estamos trabajando en algo y empiezan a aparecer problemas, tendemos a tratar de resolverlos lo más rápidamente posible para poder seguir adelante. Ya antes he hablado del "síndrome del sysadmin", y no me enorgullezco de decir que a veces aflora gracias a la eventual simultaneidad de ciertos problemas informáticos que parecen ser causados por diversos factores como el viento solar, la diferencia horaria generada por el tsunami asiático, la caída de las bolsas en Wall Street o quién sabe por qué otras esotéricas razones exactamente... Así es que uno a veces busca respuestas o soluciones de la forma más complicada, talvéz también debido a la estructura mental que caracteriza a los idiotas que hacemos de la administración de sistemas nuestro modo de vida (no se sientan agredidos, colegas... sé que no todos son idiotas como yo).

Hace un par de días me llamó un cliente para decirme que tenía problemas con su correo electrónico. Siendo que este cliente es una persona inteligente, versada y acostumbrada a las cuestiones tecnológicas e informáticas, cuando me dijo que tenía dificultades con el servicio de envío, asumí que NO se trataba de un usual y mero problema de capa 8 (situación también conocida como "PEBKAC", "PIBCAK", "PICNIC", o según la jerga militar yanquee "One Delta Ten Tango problem"). Referencias y alusiones ilustrativas pueden buscarse en Google.

Pedí detalles sobre el problema y el cliente me dijo que no podía enviar mensajes desde ningún equipo, y que el servidor tardaba mucho en responder, en el mejor de los casos. Las descargas de mensajes y el webmail funcionaban bien, así que el servicio que fallaba parecía no afectar a los otros servicios en el sistema.

Entré al servidor y comencé el diagnóstico standard. Pude ver que había varias conexiones abiertas desde una IP externa a la red, enviando mensajes a través de una conexión debídamente autenticada (esto es, usando SMTP-AUTH y con credenciales de acceso válidas). Como sabía que no había nadie de viaje en la empresa del cliente, y como esta dirección de origen correspondía a algún lugar en la China, parecía evidente que este "usuario" conectado no era trigo limpio. Examinando los mensajes encolados en el servidor y que este usuario estaba enviando, veo que se trata de SPAM, así que desactivé la cuenta y limpié la cola de mensajes para evitar más daños (más tarde tendría que hacer los trámites de salida de las blacklists correspondientes y también tendría que implementar políticas más restrictivas al respecto de las credenciales de acceso al servicio). Habiéndome asegurado de que el spammer no podía volver a conectarse desde esa red, ni siquiera con nuevas credenciales de acceso, me puse a verificar otros parámetros del servicio, dado que aún no funcionaba como debía.

Así fué que ví que había una serie de conexiones abiertas desde y hacia la dirección IP 127.0.1.50...

En este punto estoy seguro de que muchos lectores experimentados en las artes del manejo de redes y servicios estarán sospechando cual es el problema en realidad... pero dejaré igual que sigan leyendo, esperando que de esta historia salga una moraleja útil para alguien.

Como la concurrencia de conexiones al servicio SMTP está limitada (como forma de controlar los recursos del servidor), una vez que se llegaba a la cantidad máxima de conexiones permitidas, el servicio simplemente dejaba de responder, hasta que las conexiones se resolvieran (se cerraran).

Mi primer impresión fué que algo o alguien había logrado ejecutar un claro spoofing de la dirección IP 127.0.1.50, inyectando paquetes desde la red e iniciando conexiones en el servicio SMTP. Lo primero que hice fué ejecutar una captura de tráfico en el enlace externo para verificar el verdadero origen de los paquetes. Me contrarió no encontrar nada en el tráfico externo, así que capturé paquetes en las otras interfaces para ver si el "ataque" provenía de la red lan. Tampoco vi nada. Razonando la situación, me dí cuenta de que es simplemente imposible que existan conexiones establecidas desde una dirección perteneciente a la red 127.0.0.0/8 "spoofed" sobre una interfaz externa, porque un paquete SYN con ese origen debería ser contestado entregando el SYN/ACK a través de la ruta local del sistema hacia la dirección origen de la conexión, con lo cual el destino de dichos paquetes debería ser invariablemente la interfaz loopback... evitando que las conexiones pudieran establecerse en primer momento. Si bien se puede instruir al kernel para que entregue respuestas a través de la misma interfaz que las recibe, bypasseando las rutas de la tabla de encaminamiento de paquetes, yo estaba seguro de que este NO era el caso. Ojalá hubiera seguido razonando sobre esa misma línea, en vez de echarme a perseguir fantasmas durante el resto del "evento", hubiera ahorrado tiempo y recursos valiosos. En cambio, asumí que el ataque tenía que provenir desde el "interior" del servidor entonces, mediante alguna técnica posíblemente menos sutil.

Todos sabemos que esa dirección forma parte del bloque de direcciones 127.0.0.0/8, el cual está asociado a la interfaz loopback (ver RFC3300), lo cual me hizo sospechar que se trataba de algún tipo de ataque de ejecución remota, el cual había logrado utilizar la dirección de la loopback como origen. Supuse que de alguna manera habían podido subir un script y lo habían ejecutado para hacer spam (que es el propósito más común de este tipo de ataques hoy día). Antes de cortar las conexiones, exploré el sistema en busca del script, pero para mi sorpresa, no encontré nada.

Revisé logs de servicios, sobre todo el del servicio web (Apache) y si bien ví intentos de acceso a software que no tengo ni uso (como el phpBB, el phpMyAdmin, etc.), no encontré nada que demostrara que alguien había subido un programa o script y lo había ejecutado. Verifiqué los ejecutables básicos del sistema mediante checksums y comparación con los de otros sistemas "sanos", revisé los módulos cargados en el kernel (en busca de rootkits de tipo LKM), listé los archivos abiertos en el sistema, las conexiones activas, examiné los subdirectorios de procesos en el directorio /proc en busca de ejecutables eliminados, procesos con nombres cambiados o indicios de invocaciones extrañas, revisé el filesystem para ver si había archivos con nombres extraños o en directorios donde no debería haberlos, el /tmp, el /dev, directorios o archivos que comienzan con "." o que se llaman "...*", etc... y seguí sin encontrar nada...

Descargué y ejecuté rkhunter y chkrootkit, y aunque ya había hecho manualmente los chequeos que estos dos softwares hacen, decidí intentarlo a ver si se me había escapado algo inadvertidamente. Nuévamente, NADA.

En este momento empecé a preocuparme seriamente... ya que si alguien había tomado posesión de ese servidor y estaba ejecutando algo, su método de ocultación era, para todo propósito, simplemente perfecto.

Opté por cerrar las conexiones y hacerle un seguimiento intenso con el fin de descubrir algo que me llevara a encontrar al atacante. Talvéz algún cracker había subido, ejecutado y eliminado toda traza de algún software en un movimiento único... lo cual era improbable, pero "posible". Tal atacante se merecería más que respeto de mi parte, así que decidí no dejar nada al azar y vigilar la actividad del servidor muy de cerca, más de lo que el tiempo del que dispongo para dicha tarea me lo permite.

Una hora después, el problema volvió a aparecer. Otra vez intenté dar con el causante sin poder hacerlo, lo cual me inquietó más aún. Esta vez terminé las conexiones y restauré el servicio en forma inmediata, dado que lo que fuera que pasaba estaba sucediendo tán rápido que evitaba que yo pudiera tomar acciones preventivas a tiempo. Evalué incorporar un bloqueo mediante iptables con el propósito de evitar nuevos intentos de acceso desde/hacia esa dirección, pero asumí que estaba frente a un atacante lo suficientemente habil como para darse cuenta del mismo y naturalmente que su paso siguiente sería probar otra dirección IP. Evalué también poner reglas sobre todo el bloque 127.0.0.1/8, exceptuando el 127.0.0.1 y el 127.0.0.2, que son las únicas dos direcciones necesarias (bueno, la primera al menos) para el correcto funcionamiento del servidor, pero eso daría por tierra con mi intento de encontrar al causante del problema, así que dejé todo como estaba, en espera de poder seguir mi búsqueda. Otros asuntos me llamaron al deber y tuve que dejar de monitorear este servicio para atenderlos, así que a pesar de mi renuencia, me separé de la terminal y fuí a seguir mi rutina diaria.

Horas después, verifiqué el estado del sistema y estaba normal, así que decidí poner manos a la obra y escribir un script que chequeara el sistema de forma constante (con una ventana de un segundo) y que sacara una "radiografía" del servidor en ese preciso instante, en caso de detectar actividad de esa dirección IP, con el propósito de tratar de encontrar el vector de ataque en caso de que la situación volviera a suceder. Esa sería una herramienta invaluable para descubrir al habil atacante. Terminé el script, lo probé y lo dejé en ejecución, esperando que las respuestas fuesen reveladas.

Seguí con otras cosas y en la noche recibí una notificación del script indicando que otra vez estaba sucediendo el "ataque". Con los archivos generados por el script, esperaba obtener una solución definitiva... y finalmente la obtuve, aunque no era lo que yo esperaba.



En los servidores de correo que instalo, utilizo una versión modificada de QMail. Entre las modificaciones y herramientas accesorias que utilizo, tengo un script que escribí y que hace de "proxy" entre los clientes externos y el software que dá el servicio. Dicho script chequea ciertos parámetros de las conexiónes antes de permitir el establecimiento de las mismas directamente con el sistema interno que gestiona el servicio SMTP. Entre los chequeos que hace, se encuentra la verificación del reverso DNS de la IP del cliente, la comparación de la IP y del reverso contra una blacklist interna, la pasada de la conexión por un proceso de "greylisting" (con el propósito también de asegurar que la misma se hace desde un servidor de correo legítimo, el cual volverá a reintentar la conexión más tarde en caso de haber sido rechazado la primera vez), el registro de la conexión y de la sesión, con puertos de origen y destino, con fines de monitoreo y diagnóstico, etc. Este script "escucha" en el puerto 25 del enlace externo (en caso de que haya más de un enlace de acceso al servidor) y decide si la conexión se establece o no dependiendo de los parámetros de la misma. Se supone que no puede haber en Internet un servidor de correo electrónico legítimo ejecutándose sobre una dirección IP dinámica, o sobre una dirección IP que no tiene reverso de DNS, o cuyo reverso DNS indique claramente que se trata de una dirección IP que no está asignada a ningún recurso en particular.

Como muchas veces sucede, algunos servidores de correo legítimos están activos sobre direcciones IP que no tienen reversos de DNS, ya sea porque los ISP a los que pertenecen no permiten o no usan dichos reversos, o porque los administradores de sistemas de dichos servidores ni siquiera saben que semejante cosa existe o se usa, o simplemente porque esos administradores no tienen ganas de asignarle un reverso de DNS a sus IP (hasta hace pocos años, los servidores del dominio "hsbc.com.ar", la sucursal argentina del conocido banco inglés, NO tenían reversos de DNS, por ejemplo).

Como mi script no permite conexiones desde direcciones IP sin reverso DNS, a veces rechazábamos correo emitido desde servidores legítimos pero mal administrados, con las consecuencias obvias para los clientes. Para evitar rechazar mensajes de correo electrónico de servidores legítimos pero cuyas direcciones IP no tienen reversos de DNS, se me ocurrió implementar un chequeo denominado "callback", el cual tiene como propósito verificar que el servidor que se conecta con nuestro servidor y que no tiene reverso de DNS, sí tiene un servicio SMTP activo, lo cual disminuye el riesgo de que se trate de una fuente de spam (en el mundo real, este chequeo no es tán efectivo, dado que cualquier spammer que vaya a usar una dirección IP sin reverso puede crear un servicio SMTP ilegítimo con la capacidad de burlar el método de callback, pero es preferible aceptar diez mensajes de spam que rechazar un mensaje legítimo).

El metodo de callback implica que el servidor que aún espera permitir la conexión desde la dirección IP sin reverso, genere una nueva conexión hacia el puerto 25 de dicha IP y ejecute ciertos comandos SMTP destinados a verificar la fuente. Una vez que la fuente es verificada (o sea que los comandos recibidos por la misma se ejecutan y generan una respuesta acorde con el protocolo), la conexión se permite. El caso contrario, la conexión se cierra y el script bloquea la dirección origen dejando una entrada en el registro del servicio. En este caso, el programa que hace el callback es un simple script en perl que escribí hace unos años para probar conexiones, modificado para agregar el envío de comandos SMTP y procesar la salida. ¿Porqué es importante que mencione esto? Bueno, resulta ser que el "ataque" en realidad se podría decir que fué "autoinflingido"...

En alguna parte del planeta, un malévolo sysadmin creyó que era una buena idea asignar la dirección IP 127.0.1.50 como registro MX (Mail Exchanger) de un dominio real en Internet. O bien es "malévolo" o "estúpido", o talvéz las dos... No está claro. Talvéz sea política standard de la empresa para la que trabaja este "sysadmin" hacer ese tipo de cosas, pero sincéramente no se me ocurre una buena razón para hacer esto (bueno, pensándolo bien, puede ser un retorcido mecanismo antispam...).

¿Qué pasó entonces en realidad? Simplícimo: nuestro servidor (de nuestro cliente en realidad) recibió un spam (enviado por nuestro "amigo chino") con dirección de remitente en un dominio que tenía como registro MX la dirección 127.0.1.50 (hubiera dado lo mismo que tuviera cualquier dirección dentro del rango 127.0.0.0/8), y al intentar enviar el mensaje correspondiente, nuestro servidor inició la conexión SMTP al puerto 25 de esa dirección IP, lo cual hizo que se conectara a sí mismo (dado que todo el bloque 127.0.0.0/8 "contesta" como si las 16.777.214 direcciones que forman parte del bloque estuvieran activas), lo que a su vez disparó el script que chequea las conexiones, el cual al ver que la dirección IP 127.0.1.50 no tenía reverso de DNS, inició el script de callback (para chequear que el origen de la conexión era un servidor de correo legítimo), que inició a su vez otra conexión hacia la dirección origen de la conexión inicial, que al haber sido generada desde la dirección IP 127.0.1.50, volvió a iniciar otra conexión al puerto 25 de la dirección 127.0.1.50, la cual fué atendida nuevamente por el script de chequeo de conexiones, el cual a ver que la dirección no tenía reverso DNS, inició el script de callback, el cual inició otra conexión a la IP de origen, la cual inició el script de chequeo de IP, el cual inició el proceso de callback... y así sucesivamente, entrando en un bucle infinito, el cual se enlenteció cuando se establecieron todas las conexiones posibles como valor máximo permitido. A medida que las conexiones expiraban (por timeout), iban saliendo de la lista de establecidas, permitiendo nuevas conexiones, lamentablemente idénticas.

Esto sucede tán rápido en realidad, que uno no se dá cuenta hasta que todas las conexiones están ocupadas. Es una avalancha de conexiones que parecen simultáneas, y solo se pueden detener matando todas las instancias de los procesos implicados al mismo tiempo.

El descubrimiento de esta situación fué agridulce... De alguna forma sentí haber tenido una epifanía, y al mismo tiempo sentí una terrible vergüenza al darme cuenta de lo torpe que fuí al no ver lo que en otras circunstancias me hubiera resultado obvio. De hecho, sí lo vi al hacer el análisis inicial del que les hablé arriba al respecto de las conexiones desde y hacia direcciones asignadas a la loopback, pero de alguna forma no llegué a hacer la asociación hasta mucho después.

Me metí en una cacería de fantasmas, enceguecido por las ánsias de atrapar a un atacante súmamente hábil y cauteloso, sin darme cuenta de que básicamente estaba persiguiendo mi propio trasero, tal y como lo hacen los perros.

Finalmente, luego de terminar mi análisis, modifiqué el programa de chequeo de conexiones para que esto no vuelva a suceder. Se podría decir entonces que algo bueno surgió de todo esto. Fué lo que se dice "una experiencia educativa", aunque en el estado en el que estoy estos días, lo que menos necesito es otra de estas experiencias. Lo que necesito realmente son vacaciones... y seguramente mi desempeño durante este evento fué un claro indicativo de ello.

:wq

martes, 8 de febrero de 2011

Problemas con adjuntos en simscan con ripmime

En la última versión del servidor de correo electrónico que desarrollé, la cual ya está en producción en los últimos tres servidores que instalé, apareció un error inusual. Básicamente, el software de control de contenidos (simscan 1.4.0) estaba rebotando mensajes porque contenían un adjunto no permitido. El problema es llamativo ya que no sucede siempre, lo cual me desorientó bastante.

Hice un desesperado pedido de ayuda en la lista de correo de la herramienta, en el sitio de Inter7 (la empresa que creó la herramienta originalmente), pero no obtuve una respuesta, así que seguí investigando por mi cuenta. UPDATE: Matt Brookings, desarrollador de simscan para Inter7 contestó a mi mensaje hoy (10 de Febrero de 2011) confirmando el bug en simscan (y también en ripmime, el cual voy a comunicar a Paul S. Daniels en estos días) y avisando que iba a revisarlo (Ver archivo de la lista de correo de Simscan: http://news.gmane.org/gmane.mail.qmail.simscan).

Simscan permite especificar una lista de extensiones de archivos los cuales serán rechazados si se adjuntan a un mensaje. Estas extensiones se especifican en un archivo llamado simcontrol, del cual luego se genera (mediante la ejecución de una herramienta complementaria llamada simscanmk) un archivo de base de datos en formato CDB, conteniendo las reglas de control. El archivo se vé de esta manera:

:clam=yes,spam=yes,spam_passthru=yes,attach=.vbs:.lnk:.scr:.cmd:.exe:.com:.bat:.reg:.pif


Esto básicamente significa que los adjuntos con extensión .vbs, .lnk, .scr, .cmd, .exe, .com, .bat, .reg y .pif están administrativamente prohibidos. Bueno, el software estaba rechazando un archivo cuyo nombre resultó ser "d" (si, solo la letra "D" minúscula). Lo extraño es que el mensaje solo tenía un único archivo de Word adjunto (con extensión ".doc").

Así se veía el error:
554 Your email was rejected because it contains a bad attachment: d


Lo extraño también es que no todos los archivos .doc fallaban, sino que el problema parecía darse en ciertos archivos solamente. Esto resultó ser lo más desconcertante de todo. Decidí probar a revisar el ripmime, con quien ya antes había tenido un altercado gracias a un error de capa 8 (si, me equivoqué de versión cuando lo instalé), y esto resultó ser interesante. Sobre una copia del mensaje que rebotaba ejecuté ripmime manualmente y me llevé una sorpresa. Ripmime extrajo varios archivos (5 en total) de un mensaje que supuestamente solo tiene un único adjunto(!).

srv:/usr/local/src/ripmime-tests # mkdir res
srv:/usr/local/src/ripmime-tests # ls -la
total 140
drwxr-xr-x 4 root root 4096 Feb 8 19:29 .
drwxr-xr-x 7 root root 4096 Feb 8 16:04 ..
drwxr-xr-x 2 root root 4096 Feb 8 19:27 res
-rw------- 1 root root 125608 Feb 8 12:37 testmessage.eml
srv:/usr/local/src/ripmime-tests # ripmime --disable-qmail-bounce -i testmessage.eml -d res
srv:/usr/local/src/ripmime-tests # cd res
srv:/usr/local/src/ripmime-tests/res # ls -la
total 96
-rw------- 1 root root 90112 Feb 8 19:27 Documento de prueba.doc
-rw-r--r-- 1 root root 0 Feb 8 19:27 d
-rw-r--r-- 1 root root 0 Feb 8 19:27 textfile0
-rw-r--r-- 1 root root 1094 Feb 8 19:27 textfile1
-rw-r--r-- 1 root root 936 Feb 8 19:27 textfile2


Ahora que sabía de donde salía el famoso archivo "d", el problema estaba en entender porqué el simscan tomaba el archivo como "bloqueado" y rechazaba el mensaje...

Configuré un recordio sobre el puerto 25 de uno de los servidores afectados para poder capturar toda la transacción del servicio SMTP y activé la función de debug del simscan (provista por el patch que escribió John Simpson para poder diagnosticar otro problema en simscan) y ahí empezó a verse la luz...

Pude obtener el siguiente registro:

@400000004d514dd628a87474 simscan: lpart: local part is **
@400000004d514dd628a8d61c simscan: cdb looking up gcastro@example.com
@400000004d514dd62991f5cc simscan: checking attachment textfile0 against .vbs
@400000004d514dd629921cdc simscan: checking attachment textfile0 against .lnk
@400000004d514dd629922894 simscan: checking attachment textfile0 against .scr
@400000004d514dd629923064 simscan: checking attachment textfile0 against .cmd
@400000004d514dd629923834 simscan: checking attachment textfile0 against .com
@400000004d514dd6299243ec simscan: checking attachment textfile0 against .exe
[...]
@400000004d514dd629992d74 simscan: checking attachment d against .com
@400000004d514dd629993544 simscan: checking attachment d against .exe
@400000004d514dd629993d14 simscan: checking attachment d against .bat
@400000004d514dd629997b94 simscan: checking attachment d against .cmd
@400000004d514dd629998364 simscan:[21057]:ATTACH:5.3975s:d:209.85.214.53:gcastrop@example2.com:gcastro@example.com
@400000004d514dd629998f1c simscan: exit error code: 82
@400000004d514dd6299996ec 21057 > 554 Your email was rejected because it contains a bad attachment: d

@400000004d514dd722f67e2c 21057 < QUIT


Y así se hizo evidente que el archivo "d" caía en la regla correspondiente a los archivos con extensión ".cmd", lo cual me intrigó bastante, ya que el nombre de archivo "d" difiere mucho de tener una extensión, y dicha extensión, si la hubiera, dudo que fuera ".cmd", dado que el archivo está vacío...

Lo obvio de todo esto es que ".cmd" termina en una letra "d", lo cual dudé que fuera una mera coincidencia... así que me puse a investigar el código fuente de simscan. Encontré que el archivo simscan.c tiene una función llamada check_attach(), la cual contiene el código que compara los nombres con las extensiones:

while((mydirent=readdir(mydir))!=NULL) {
/* skip . and .. */
if ( mydirent->d_name[0] == '.' &&
(mydirent->d_name[1] == '.' || mydirent->d_name[1] == 0) ) {
continue;
}

for(i=0;i<MaxAttach;++i) {
if ( DebugFlag > 2 ) fprintf(stderr, "simscan: checking attachment %s against %s\n", mydirent->d_name, bk_attachments[i] );
lowerit(mydirent->d_name);
if ( str_rstr(mydirent->d_name,bk_attachments[i]) == 0 ) {
strncpy(AttachName, mydirent->d_name, sizeof(AttachName)-1);
closedir(mydir);
return(1);
}
}
}


mediante otra función llamada str_rstr(), que se encarga de comparar las entradas en un vector de cadenas de texto conteniendo las extensiones, con el nombre del archivo de turno en la iteración ejecutada secuencialmente sobre todos los adjuntos del mensaje. Dicha función toma dos parámetros, el nombre de archivo y la extensión a comparar. Así se ve la función:

int str_rstr(register char *h,register char *n)
{
register char *sh;
register char *sn;

for(sh=h;*h!=0;++h); --h;
for(sn=n;*n!=0;++n); --n;

for(;h>=sh && n>=sn;--h,--n) {
if ( *h!=*n ) {
return(-1);
}
}
return(0);
}


Como puede verse, la función lee de atrás para adelante y compara los textos en forma literal, con lo cual el problema emerge finalmente. Al revisar letra por letra y empezar desde atrás hacia adelante, cuando revisa el nombre de archivo "d" con la última letra de la extensión ".cmd", las dos coinciden. Como no hay más nada para probar, dado que el nombre de archivo consta de una única letra, la función devuelve 0, con lo cual el mensaje es rechazado finalmente por contener un archivo no permitido.

A estas alturas, tenía dos soluciones posibles: o reparaba el ripmime para que deje de extraer archivos que no existen, o modificaba el código fuente del simscan para que haga un chequeo extra sobre los nombres de archivos a comparar con la lista de extensiones. Quise consultar el foro de ripmime para ver si alguien había tenido algún problema similar y discutir una posible solución, pero resultó ser que estaba cerrado por haber recibido spam, así que decidí decantarme por la modificación al código de simscan, el cual me sería más simple y fácil de probar, sin contar con que podía consultar la lista de correo de Inter7 en caso de encontrarme con algo inesperado.

Bueno, de las muchas opciones que se me ocurrieron, la que me pareció más simple y menos invasiva para con el código fué simplemente chequear que el largo del nombre del archivo a chequear en la iteración fuera como mínimo igual al largo de la extensión a chequear. Esto haría más exacto el chequeo y proporcionaría más robustez al software. Sin pensarlo demasiado, hice la modificación al código del archivo simscan.c, agregando código de debugging de la misma forma que John Simpson hizo con el resto del código para poder debuggear los errores anteriores:

for(i=0;i<MaxAttach;++i) {
if ( DebugFlag > 2 ) fprintf(stderr, "simscan: checking attachment %s against %s\n", mydirent->d_name, bk_attachments[i] );
lowerit(mydirent->d_name);
if ( strlen(mydirent->d_name) >= strlen(bk_attachments[i]) ) {
if ( str_rstr(mydirent->d_name,bk_attachments[i]) == 0 ) {
strncpy(AttachName, mydirent->d_name, sizeof(AttachName)-1);
closedir(mydir);
return(1);
}
} else {
if ( DebugFlag > 2 ) fprintf(stderr, "simscan: attachment name '%s' (%d) is shorter than '%s' (%d). IGNORED\n", mydirent->d_name, strlen( mydirent->d_name ), bk_attachments[i], strlen( bk_attachments[i] ) );
}

}


Ahora si el largo del nombre de archivo a comprobar es menor al largo de la extensión, el simscan simplemente lo ignora:

[...]
@400000004d517ee02c8894d4 simscan: attachment name d (1) is smaller than .vbs (4)
@400000004d517ee02c895054 simscan: checking attachment d against .cmd
@400000004d517ee02c8a0fbc simscan: attachment name d (1) is smaller than .cmd (4)
@400000004d517ee02c8acb3c simscan: checking attachment d against .lnk
@400000004d517ee02c8b8aa4 simscan: attachment name d (1) is smaller than .lnk (4)
[...]


Y el simscan ya no falla con el error críptico que desencadenó esta entretenida sesión de debugging.

Queda publicado este patch, el cual dejo aquí para que quien quiera pueda utilizarlo:

diff -ruN simscan-1.4.0/simscan.c simscan-1.4.0-tested/simscan.c
--- simscan-1.4.0/simscan.c 2011-02-08 20:26:06.095067924 -0200
+++ simscan-1.4.0-tested/simscan.c 2011-02-08 18:16:11.003064430 -0200
@@ -1735,10 +1735,14 @@
for(i=0;i if ( DebugFlag > 2 ) fprintf(stderr, "simscan: checking attachment %s against %s\n", mydirent->d_name, bk_attachments[i] );
lowerit(mydirent->d_name);
- if ( str_rstr(mydirent->d_name,bk_attachments[i]) == 0 ) {
- strncpy(AttachName, mydirent->d_name, sizeof(AttachName)-1);
- closedir(mydir);
- return(1);
+ if ( strlen(mydirent->d_name) >= strlen(bk_attachments[i]) ) {
+ if ( str_rstr(mydirent->d_name,bk_attachments[i]) == 0 ) {
+ strncpy(AttachName, mydirent->d_name, sizeof(AttachName)-1);
+ closedir(mydir);
+ return(1);
+ }
+ } else {
+ if ( DebugFlag > 2 ) fprintf(stderr, "simscan: attachment name '%s' (%d) is shorter than '%s' (%d). IGNORED\n", mydirent->d_name, strlen( mydirent->d_name ), bk_attachments[i], strlen( bk_attachments[i] ) );
}
}
}


Debe tomarse en cuenta que este patch está pensado para aplicarse sobre simscan 1.4.0 con el patch http://qmail.jms1.net/simscan/simscan-1.4.0-combined.4.patch de John Simpson (Thanks, John!).

Bueno, un problema menos... a seguir con los otros.

Happy hacking!

lunes, 17 de enero de 2011

2010: El año que (NO) hicimos contacto...

Por allá por los 60', un astrónomo llamado Frank Drake dió el puntapié inicial para crear lo que hoy todavía conocemos como el proyecto SETI (Search for Extra Terrestrial Intelligence). Ya hacía algunos años que había sucedido aquel incidente luego del cual Kenneth Arnold popularizó el término "platillo volador" y que de alguna forma dió inicio a la ola de avistamientos que después resultaran en las primeras investigaciones serias del gobierno de los Estados Unidos sobre el tema de los OVNIs.

Antes de seguir, quisiera hacer un alto para hacer una aclaración importante acerca de la nomenclatura y el real significado de la sigla "OVNI", así como también sobre el concepto como es visto por el común de la gente. Cuando alguien habla de un OVNI, la primera imagen que a todos le viene a la mente es la de "una nave espacial tripulada por hombrecitos verdes o grises, provenientes de otro planeta", cuando en realidad, la sigla únicamente sirve para designar a "cualquier fenómeno u objeto en el cielo que no puede ser identificado sin lugar a dudas por el observador". Esta diferenciación es primordial, ya que mucha gente rápidamente desestima a los testigos de avistamientos y los tacha de locos gracias a esta interpretación errónea de la realidad, muchas veces descartando un hecho fidedigno en pro de la ferviente verdad de los más numerosos (o sea, de los que no ven "naves espaciales flotando en el cielo").

Aclarado esto, confieso haber sido testigo de tres avistamientos a lo largo de mi vida, y lo digo con la convicción de saber que realmente eran OVNIs, o sea, "algo que ví flotando en el cielo y que no pude identificar claramente como algo cotidiano, como un avión, un globo, un pájaro o el reflejo de la Luna o de Venus contra las nubes". Si bien he teorizado al respecto, evidentemente no puedo concluir que se trató de naves espaciales de otro planeta, lo cual de alguna forma simplificaría mucho la situación... Solo uno de esos avistamientos tuvo características inusuales, pero como dije, no puedo afirmar categóricamente nada.

Volviendo al tema central, SETI viene intentando (entre otras cosas) hacer contacto con alguna raza extraterrestre inteligente desde su creación. La idea es simple, aunque las limitaciones de distancia y tiempo son un problema de dificil solución hasta el momento. Para tener una idea del problema, solo hace falta saber que la luz del Sol tarda aproximadamente 8 minutos y 19 segundos en llegar a la tierra, así que la visión que tenemos de nuestra estrella está desfasada en el tiempo (digamos "atrasada") 8 minutos y 19 segundos con respecto a la realidad, y el Sol está "acá nomás", a solo 149.000.000 de kilómetros... La siguiente estrella más cercana está a 4.1 años luz, o sea que la visión que tenemos de ella tiene un desfasaje temporal de 4.1 años con respecto a la realidad... y así sucesivamente con el resto de las estrellas. Esto complica enormemente la tarea de comunicarnos con cualquier otra raza inteligente fuera del planeta, ya que la velocidad de transmisión de información más rápida que conocemos es la de la luz (si descartamos de plano el extraño vínculo que parece existir entre partículas y que fuera el centro de la paradoja Einstein-Podolsky-Rosen, la cual demuestra la existencia de una "acción a distancia" que perturba las mediciones de ciertos valores entre partículas de forma tal que parece que las mismas estuvieran "comunicadas" entre sí), y ciertamente no es práctica a través de distancias interestelares. Asumiendo que nuestras transmisiones están siendo emitidas a una potencia apenas detectable desde hace 76 años (las primeras transmisiones de radio se hicieron en el año 1938), a estas alturas habríamos alcanzado aproximadamente unas 3500 estrellas, de las cuales ninguna tiene una civilización inteligente con ganas de comunicarse (esto se desprende de la aplicación de la ecuación del mismo Drake del que hablábamos al principio de este artículo...), ya que según los cálculos menos conservadores, las civilizaciones inteligentes capaces y deseosas de comunicarse con otras estarían separadas entre sí por una distancia de 2.000.000.000 de años luz, lo cual daría por tierra con la idea de poder comunicarnos con extraterrestres...

Nos queda entonces esperar a que los hombrecitos verdes o grises estén de viaje, cerca del sistema solar y que se "den una vuelta" por nuestro planeta para visitarnos, asumiendo que no lo han hecho o lo están haciendo en este momento. Esto implicaría que son mucho más avanzados que nosotros, por lo menos en cuanto a métodos de viaje por el espacio. Velocidades "luz" o "subluz" no parecen prácticas, a menos que tengas una nave enorme, repleta de recursos y con varias generaciones de viajeros en camino a algún lugar recóndito de la galaxia y sin posibilidad de retorno. Si los viajeros fueran inmortales, tendría lógica, ya que esta gente tendría "todo el tiempo del mundo para viajar", pero para otros seres mortales, el viaje por sí mismo sería un asunto a demasiado largo plazo como para valer la pena.

Si el nivel tecnológico de una raza inteligente está lo suficientemente desarrollado como para permitir viajar a velocidades superiores a la de la luz (léase "warp", "hyperespacio", "ftl", etc.), el viaje sería por supuesto mucho más rápido, y por lo tanto, es factible de ser realizado en poco tiempo, dando la oportunidad a estos extraterrestres de llegar cerca y comunicarse con nosotros en un período relativamente corto, digamos dentro del alcance de una "vida terrestre".

Con respecto a las formas de viaje más rápidas que la luz, a muchos les sorprenderá saber que en 1994 un científico mexicano llamado Miguel Alcubierre, patentó un modelo teórico del motor "warp". El sistema se denomina "Alcubierre Drive" (disponible también en español) (original, ¿no?) y si bien su modelo no ha sido aplicado en forma práctica aún, se espera que el avance tecnológico permita una primer implementación en algunos años (el gran problema de este modelo es que requiere de la existencia y manipulación de "materia exótica", la cual casualmente no abunda salvo en teorias sobre materia oscura y estados raros de la materia).

Por ahí hay un proyecto que data de los años 60' y que describe un posible vehículo (llamado "Dédalo" ("Daedalus") en honor al padre de Ícaro), el cual tendría la capacidad de viajar a un 12 % de la velocidad de la luz (unos 35.000 kilómetros por segundo, aproximadamente), y que sería lanzado desde una órbita alta de la Tierra hasta apagar sus motores, luego de un período de casi 50 años. El motor de este ingenio es denominado "Motor inercial de fusión en confinamiento", la cual es una tecnología probada y lista para ser usada. La única razón por la cual Dédalo no ha abandonado la Tierra aún en un viaje interestelar, es su costo (como siempre...). Con esto se acaba nuestra capacidad de viaje por el espacio.

Definitivamente, nuestra mejor oportunidad sería si nuestros visitantes ya estuvieran en camino, viajando por el espacio hace mucho tiempo a velocidades increíbles y con un sistema de comunicaciones que les permitiera "escucharnos" de alguna manera y acceder a conocernos mediante una visita formal. Lamentablemente, podemos decir que eso no ha pasado todavía. Si bien existen personas que afirman haber sido contactadas por inteligencias de otros planetas, sus afirmaciones son bastante sensacionalistas y se prestan a la especulación. Hay casos significativos, sobre todo en el área de las abducciones, muy poco se puede afirmar como verídico y fidedigno.

Para peor, Hollywood ha hecho contribuciones bastante negativas a lo largo de los años, con películas como "Body Snatchers", "Alien", "Independence Day", "Progeny", "Signs", "Predator", "The fourth kind", "Skyline", "Battle: Los Angeles", etc... las cuales hacen palidecer obras "positivas" como "The Day the Earth Stood Still", "Contact", "Encounters of the third kind", "E.T.", etc., así que probablemente cuando alguien vea "algo" que parece ser una nave tripulada por seres de otros planetas, lo más probable es que le tiren con cuanto elemento contundente tengan a mano, haciendo del "Primer Contacto" el inicio de un conflicto bélico de proporciones extra-planetarias.

Y si, no estamos preparados todavía para semejante proeza como un primer contacto con una civilización inteligente. Sin lugar a dudas, yo, si fuera un extraterrestre, miraría de lejos este "asentamiento irregular" al que llamamos Planeta Tierra, sacudiría la cabeza y me daría la vuelta de nuevo al lugar de donde vine, seguramente un planeta donde todos los habitantes conviven pacíficamente, dando su parte para mejorar su existencia como raza y donde todos persiguen el bien común. No se los puede culpar por eso...

Seguramente, esta es la razón por la cual no hicimos contacto todavía. Talvéz estén realmente ahí afuera, se acerquen lo suficiente con sus vehículos como para vernos (y dejarse ver), y eventualmente, llegarán a la conclusión de que lo mejor que pueden hacer es quedarse al margen y observar, esperando que "esto" llegue a una conclusión. Talvéz sean algo así como los personajes del cuento de Asimov "The Gentle Vultures" ("Los Buitres Bondadosos"), que observaban desde lejos, esperando que una civilización llegara a un punto de quiebre (léase "aniquilación por una guerra") y luego hacían su llegada triunfal, brindando ayuda a los sobrevivientes a cambio de un pequeño impuesto que sirviera para financiar la operación... (cualquier similitud, aunque sea vaga, con la operación "War on terrorism" de los yankees es pura coincidencia...).

Lo "malo" de todo esto entonces es no haber hecho contacto con otra raza inteligente. De alguna manera, creo que ese evento nos haría crecer como seres humanos y talvéz nos obligaría a madurar ante la seguridad de no estar solos en el Universo. Sé que a estas alturas nuestra capacidad de asombro ha mermado significativamente. La constante exposición a los medios de comunicación y a obras de arte sobre dicha temática nos ha hecho desarrollar una especie de escudo que evita que nos maravillemos ante la inmensidad y las posibilidades del Universo, pero todavía tengo esperanza en que si algún día tenemos contacto con otra raza de seres inteligentes, nos daremos cuenta de ello y haremos lo correcto.

Si no es así, no estoy seguro de querer estar acá cuando suceda...

:wq

 
Gustavo Castro

Crea tu insignia