Security Art Work

Hoy un cliente me preguntaba sobre posibles medidas a implantar para evitar la fuga de información corporativa, y me apuntaba a la utilización de DRM (Digital Rights Management) y DLP (Data Loss Prevention) para controlar el flujo de información, sobre lo que además tal y como me indicaba no hemos escrito nada en el blog. Me comprometo ya mismo a escribir sobre ello en las próximas semanas (si no pueden esperar hasta entonces, sobre DLP la gente de Websense tiene un PDF bastante detallado en este enlace), pero en cualquier caso, es pertinente comentar unos puntos básicos al respecto de estas tecnologías:

• Este tipo de soluciones suelen tener un coste de adquisición e implantación no despreciable, si se pretende obtener una buena efectividad.
• Además del coste económico implícito, el mantenimiento y gestión de estos sistemas y la información que generan requiere su tiempo, que puede ser significativo y que al final se traslada en un mayor coste.
• Estos sistemas no son infalibles 100%; aunque limitan mucho la gestión no autorizada de información, no son la panacea ni hay que olvidar el resto de medidas (que incluyo en la segunda parte de esta entrada).
• Finalmente, estos sistemas introducen restricciones al flujo de información que pueden generar un torrente de quejas entre el personal, que el Departamento de Informática debe estar listo para asumir y gestionar; dicho de otra forma, es bueno que la organización sea consciente de qué está implantando y que Dirección ofrezca todo su respaldo… para poder utilizarla de escudo en caso de apedreamiento público.

Teniendo estos puntos en cuenta, es lógico que algunas organizaciones decidan llevar a cabo la implantación de DRM/DLP, por las indudables ventajas que aportan al control de la información que fluye por la organización. No obstante, sin que sirva de comparación o contrapartida, dejando de lado sistemas específicos, mis recomendaciones (bastante más baratas, por otro lado) son las siguientes:

• Disponer de normativas internas que especifiquen las funciones y obligaciones del personal, y de contratos de confidencialidad firmados con los empleados, que garanticen un respaldo legal en caso de robo “evidente” de información (el problema es que a veces no tiene nada de evidente).
• Implantación de controles técnicos que eviten que una persona pueda acceder a recursos y documentación a la que no debería tener acceso.
• Seguir la regla del need-to-know, y que a cada usuario se le otorgue acceso exclusivamente a lo que necesita para su trabajo, y no más que eso.
• Definir niveles de confidencialidad que establezcan de manera incremental los controles necesarios para el acceso a los recursos.
• Por último, pero casi lo más importante, concienciar a los usuarios sobre el buen uso de la información corporativa; quizá compartir el identificador de usuario con “el nuevo” que acaba de llegar y todavía no tiene acceso no sea tan buena idea, después de todo.

Todas estas medidas forman parte de un SGSI implantado y bien gestionado, que añade muchas más. Una opción alternativa es establecer restricciones a aquellos medios que pueden ser utilizados para la extracción de información, como son el acceso a Internet, los puertos USB y las grabadoras de CD/DVD, pero es algo para lo que también hay que estar (muy) preparado.

En definitiva, mi opinión es que una solución DLP/DRM es útil cuando se ha alcanzado un buen nivel de madurez en la gestión de la seguridad de la organización; hacerlo antes implica muy probablemente una implantación ineficaz que no (a)traiga más que problemas. ¿Cuál es su opinión al respecto?

(Para hoy martes, una entrada de uno de nuestros colaboradores habituales, Francisco Benet, sobre la necesidad de dotar de un cuerpo documental a la operación de nuestros sistemas y hacerlo con el menor sufrimiento posible)

La creación de procedimientos es una de esas tareas que muchas veces, por no decir siempre, se pasa por alto dentro de las tareas propias de la gestión de sistemas. Naturalmente no es algo que a los técnicos les agrade mucho, precisamente porque lo que a un técnico le gusta es ‘jugar’ con los cacharros que tiene a su disposición; eso de escribir no es que sea sólo para novelistas, sino que cuando llega la fatídica hora de pasar al papel lo aprendido, o se ha olvidado, o ha pasado a ser la tarea menos prioritaria de las pendientes (a veces porque hay justificadamente otras tareas más urgentes, y a veces porque “se buscan” esas otras tareas). En definitiva, es una de esas cosas que presentan más batalla para el personal que esta operando y explotando los sistemas; según mi experiencia personal, si tuviera que decir cuál es la tarea más problemática que me ha tocado lidiar en el trato con las super-estrellas-técnicos-de-la-muerte, sin lugar a dudas diria que es la procedimentación de una plataforma, no tanto por el contenido sino por la calidad y la dedicación a la redacción, porque un procedimiento mal hecho es casi lo mismo que nada, por la rapidez en que cae en desuso y lo poco que se utiliza.

Algunos de ustedes (no todos) estarán pensando: ¿que tiene que ver esto con la seguridad? ¿esto no es una cosa que se hace una vez al año con los auditores? ¿tú tienes tiempo para esas cosas?

[Read more…]

Hace unos días leía una interesante entrada de Alonso Hurtado sobre la disparidad de jurisdicciones en relación con las redes sociales, basada a su vez en una entrevista a Natalia Martos, directora del Área Jurídica y Privacidad de Tuenti.

En dicha entrada, Alonso hace una reflexión sobre la diferencia de obligaciones y requerimientos en materia de protección de datos que existe entre Facebook y Tuenti, al someterse a jurisdicciones diferentes, la estadounidense y la europea, siendo la primera mucho más laxa que la primera (y más si tenemos en cuenta que la LOPD es una de las leyes más restrictivas de la UE), y parece abogar por una relajación de las restricciones en materia de protección de datos para evitar la ventaja competitiva de empresas como Facebook frente a Tuenti. Al respecto, es cierto que Facebook y otras empresas extranjeras tienen una ventaja significativa frente al “producto nacional”, pero no creo que se limite a las organizaciones estadounidenses, sino a la práctica mayoría de empresas que operan en Internet con datos de carácter personal; la directiva 95/46/CE da el suficiente margen de libertad para que su aplicación entre unos estados y otros sea significativa, por lo que en la práctica, estamos en desventaja no sólo con los EEUU sino con prácticamente todo el globo terráqueo, dado que la aplicación española de la directiva tiene fama de ser la más (o una de las más) restrictiva de Europa.

El principal problema no es tanto que Estados Unidos tenga una regulación en materia de privacidad mucho más laxa que la de la UE, sino de que cuando esta última trata de lidiar con grandes multinacionales parece ignorar las exigencias que les hace a sus propios estados miembros, como se ha visto anteriormente con las “exigencias” a Google. Es cierto que una persona que decide crear una nueva aplicación o red social puede llegar a valorar el hecho de llevarse fuera de nuestras fronteras la empresa (no perdamos nunca de vista el hecho de que son siempre empresas) para evitar la estricta regulación nacional, pero al mismo tiempo, el usuario de ese sistema, red social o aplicación debería valorar ese hecho. Me resulta complicado explicar esto sin caer en radicalismos y sin duda estoy entrando en opiniones personales que no son el objeto de este blog, pero pienso que en todo esto rezuma una clara cuestión ética. No podemos anteponer los intereses económicos a la privacidad de las personas, si estamos de acuerdo en que la regulación europea incorpora mejoras y no se trata de simple e inútil burocracia; salvando las distancias, ese tipo de prácticas juegan en la misma liga que la deslocalización a empresas del tercer mundo donde los derechos de los trabajadores “están menos contemplados”, o la domiciliación de empresas en paraísos fiscales donde los requerimientos de transparencia son “menores”. La palabra es responsabilidad.

Entonces, la pregunta principal que deberíamos hacernos es si creemos que la regulación europea es necesaria y útil para la protección de datos de las personas. Mi opinión es que sí. Con indudables mejoras, que al parecer y como leo en el blog de Félix Haro ya se están estudiando (hace ya quince años de la directiva), pero sí. Rotundamente.

Acabo. Creo que el enfoque que debemos adoptar con respecto a esta “desventaja competitiva” es radicalmente opuesto al que expone Alonso (aunque no de manera tajante): no se trata de desregularizar, sino de aprovechar los controles que introduce la LOPD y su reglamento como una ventaja competitiva y no sólo en su aplicación en redes sociales sino también como experiencia aprendida en muchas otras áreas (la consultoría, sin ir más lejos). Somos uno de los países del mundo con mayores garantías en materia de protección de datos personales, por mucho que desde el sector nos quejemos de la poca implantación de la LOPD (algo que no deja por ello de ser cierto al menos para nuestros estándares). Deberíamos dejar de ver ese hecho como un obstáculo, y comenzar a potenciarlo como un sello propio de cara al usuario final; más allá del “Made in Spain“, el “Hosted in Spain“. Por supuesto, para que esto suponga realmente una ventaja, es necesario informar, concienciar y en cierto modo “educar” a éste (por paternalista que suene) en la importancia, relevancia y visibilidad de sus datos personales, algo para lo que quizá no esté (todavía) listo, pero después de todo, nadie dijo que fuese fácil.

Con relativa frecuencia aparecen en prensa noticias sobre demandas judiciales entre empleados y empresas por violaciones deliberadas de la privacidad en el correo electrónico, pero poco se habla de los posibles problemas de privacidad que surgen fortuitamente durante el análisis que realizan los sistemas de detección de intrusos (IDS).

Para los no familiarizados con el término —aunque imagino que habrá pocos—, un IDS es un equipo que analiza el tráfico de red, generalmente entre Internet y la red corporativa, aunque puede ser ubicado en cualquier otro punto de la estructura de red. Cualquier comunicación sospechosa de ser un ataque, virus, o comunicación ilícita es registrada para ser analizada por técnicos, quienes se encargan de diferenciar los falsos positivos —comunicaciones válidas que parecen ataques— de ataques reales. Puesto que estamos hablando de un sniffer, al monitorizar el tráfico es posible interceptar comunicaciones en texto plano que contengan información sensible, como pueden ser comunicaciones personales, detalles de navegación o contraseñas.

Sin una correcta configuración podemos encontrarnos con los siguientes escenarios:

• Al enviar un correo electrónico con un adjunto o contenido sospechoso, tanto el adjunto como parte del contenido del correo quedan registrados.
• Existen páginas de dudosa reputación, por ejemplo de contenidos para adultos, que contienen virus o malware. Al navegar un usuario por ella, además de arriesgarse a ser infectado, se arriesga a que el IDS clasifique la navegación como vírica y que por ello los técnicos encargados de la revisión vean por donde ha navegado.
• Al utilizar servicios de mensajería instantánea con clientes comprometidos las conversaciones quedan registradas.
• Al utilizar servicios de IRC sobre servidores configurados en puertos distintos de los estándares, estos son considerados como posibles comunicaciones entre bots y por tanto registradas.
• Al conectar con servicios de red que utilizan protocolos de autenticación no cifrados, en caso de realizar muchos intentos de conexión simultáneos como es el caso de usuarios lícitos navegando desde un mismo proxy, puede interpretarse como un ataque de fuerza bruta quedando registradas las credenciales.

Con Snort, un IDS muy extendido, estos casos se pueden mitigar en gran medida configurando las variables $HOME_NET, $EXTERNAL_NET, $DNS_SERVERS , $SMTP_SERVERS, $HTTP_SERVERS, $SQL_SERVERS, $TELNET_SERVERS, $FTP_SERVERS y $SNMP_SERVERS, evitando así que conexiones internas a servidores de la DMZ o Internet sean registradas por confundirse con ataques.
Esto se debe a que generalmente se crean las firmas de detección buscando ataques desde la red externa ($EXTERNAL_NET) hacia los servidores definidos en las variables que acaban en “SERVERS”, por lo que las comunicaciones que provienen de la red interna ($HOME_NET), quedan fuera de esté análisis. Puede parecer que esta configuración deja desprotegidos a los usuarios, pero no es así ya que las reglas destinadas a los usuarios apuntan hacia la ($HOME_NET). Además ha de realizarse un análisis de cada red y sus necesidades de monitorización con el fin de eliminar todas las reglas que no sean necesarias, ya que además de aumentar el rendimiento del IDS, podremos eliminar o afinar las reglas que puedan violar la privacidad de los usuarios (y de paso, eliminaremos falsos positivos).

Merecen una mención especial ciertos paquetes de reglas diseñados para monitorizar las actividades de los usuarios en lugar de detectar exclusivamente ataques. Algunos ejemplos son los paquetes policy, porn, p2p, chat o multimedia, todos ellos deshabilitados por defecto. Frente a la posibilidad de que las comunicaciones privadas de los usuarios puedan quedar expuestas a los técnicos que revisan los eventos, en ocasiones se opta por ocultarlo para así evitar el descontento de los empleados, o incluso para no preocupar a clientes ante la posibilidad de que se revele información sensible al contratar un servicio de detección de intrusos. Esta actitud errónea lleva a quedar expuesto innecesariamente a denuncias de los empleados o rupturas de contrato por el simple hecho de no informar debidamente a las partes implicadas.

Por todo esto, en caso de disponer de un servicio de detección de intrusos ya sea propio o para terceros, existen una serie de medidas básicas a adoptar:

• Si no disponemos de un fichero o tratamiento LOPD que cubra ya esta finalidad, debe darse de alta.
• Los empleados deben ser informados de que sus comunicaciones pueden ser analizadas, dejando totalmente claro el alcance y objetivo de dicho análisis. Esta información debe constar en la normativa de seguridad, y se ha de tener la certeza de que todos los empleados la leen y aceptan, preferiblemente por escrito.
• Los clientes deben ser informados de que el IDS puede capturar tráfico legítimo de la organización que será analizado por causas siempre justificadas, y debe firmarse el correspondiente contrato de confidencialidad y contrato de acceso a datos.
• El personal que gestiona el IDS debe firmar (al igual que cualquier otro empleado) el correspondiente contrato de confidencialidad.
• La información del IDS, más allá del nivel de los datos de carácter personal que gestiona, debe ser accesible únicamente al personal autorizado, dada la sensibilidad de la información que puede contener desde perspectivas personales o corporativas.

Dicho esto, para el fin de semana quiero dejarles una pregunta: Imaginen que en una revisión del IDS se detectan accesos hacia páginas web de contenido “no apropiado”, o el envío de información sensible hacia direcciones de e-mail “sospechosas” ¿hasta qué punto deberíamos informar al cliente sobre las actividades de sus empleados en una red que monitorizamos, si no nos han contratado para dicha tarea?

Esperamos sus respuestas. Pasen un buen fin de semana.

El pasado viernes, estuvimos participando en una sesión sobre “ITIL y Seguridad en la práctica”, organizada por nuestros amigos de Tecnofor en Madrid. Asistieron más de cincuenta directivos de entidades públicas y privadas de prestigio. Nos acompañó Manuel Mata, director de TI de Ciudad de las Artes y las Ciencias de Valencia, a quien desde aquí queremos agradecer el favor de su participación y su interés y esfuerzo.

Tras una introducción de Marlon Molina (Tecnofor), José Antonio Espinal (Tecnofor) presentó los referenciales de base de ITIL y los SGSI, preparando el terreno para los casos prácticos presentados a continuación por José Rosell (S2 Grupo) y Manuel Mata (CAC).

El punto de vista de José Rosell fue el de evidenciar la necesidad de conocer los riesgos a los que una organización se ve expuesta, valorar cuáles de ellos es necesario eliminar, mitigar o, a veces, incluso asumir. Según explicó José, el SGSI es la manera de asegurar el terreno ganado en la aplicación de medidas de seguridad en la organización, a la manera en que se apuntala una mina según se va perforando. Destacó también la necesidad de la monitorización como la única forma factible de gestionar la seguridad como un proceso.

Manuel Mata explicó su experiencia en primera persona, a la hora de implantar y gestionar un SGSI. Destacó la importancia del compromiso de la dirección, pero también de cómo el SGSI ayuda a poner en valor la seguridad cara a la propia dirección. Según Manuel, un SGSI requiere un esfuerzo importante por parte del área de TI, pero rinde beneficios tanto en el servicio a otras áreas como en la delimitación de responsabilidades.

Tal como comentó uno de los asistentes, los que conocemos la Ciudad de las Artes y las Ciencias, empezaremos a verla con otros ojos, sabiendo que, detrás de las impresionantes estructuras arquitectónicas y las instalaciones, hay un sistema de monitorización y un sistema de gestión de seguridad de la información que garantiza la protección de activos lógicos y datos.

Las presentaciones se pueden ver y descargar en el blog de Tecnofor, por si puede resultar de interés.

(Para hoy miércoles, una entrada de uno de nuestros colaboradores habituales, Francisco Benet, elaborada conjuntamente con Manuel Benet)

La suplantación de identidad podría definirse según la RAE como una combinación de suplantar e identidad. Veamos qué dice la RAE al respecto:

[Read more…]

Cuando comencé mi carrera profesional como técnico de Sistemas hace algo más de nueve años (hay que ver cómo pasa el tiempo), una de las primeras responsabilidades que me “cayó” encima en mi anterior empresa fue la gestión del sistema de monitorización de la infraestructura TIC propia y de clientes. La situación entonces era muy diferente de la actual. Nagios acababa de nacer a partir de NetSaint, y la madurez de este tipo de software distaba mucho de ser la actual; el sistema que utilizábamos (Big Brother) no era el colmo de la usabilidad, aunque su interfaz era extremadamente intuitivo. Los monitores eran bastante más rudimentarios que hoy en día, pero aun así, conseguíamos saber si las cosas funcionaban, por la cuenta que nos traía; teniendo en cuenta que por aquel entonces alojábamos la web de varios clientes importantes, una caída solía ser la antesala de problemas, así que si además no la detectábamos, imagínense. En definitiva, puede decirse que durante un buen puñado de años, tanto en aquella empresa como en la actual, mis andanzas como informático han estado ligadas entre otras cosas a gestionar sistemas de monitorización.

Aunque hoy en día aún es posible encontrar alguna empresa sin ningún sistema de monitorización TIC básico o uno que “ahí está” pero nadie mantiene ni “escucha”, las cosas han cambiado mucho. Ha habido una mejora significativa al menos en el primer paso: la detección de las incidencias. Ahora ya nadie se extraña de que sea necesario un sistema de monitorización TIC que al menos nos avise de cuándo el servidor de correo ha dejado de funcionar y así evitar los gritos de la alta dirección. Podría decirse que casi nos felicitamos por ello, como si eso fuese un gran logro. Vamos a dejar de lado aspectos de monitorización más complejos y todo el capítulo de gestión, tratamiento de las incidencias y análisis histórico; aunque debería ser inseparable de lo anterior, seguramente eso es demasiado.

No sé qué les parece a ustedes, pero a mí todo esto que les cuento me parece extremadamente básico y evidente. Quizá es que estoy demasiado acostumbrado a trabajar con estos sistemas, pero poder saber que el puerto 80 de un equipo tarda más de 5 segundos en contestar y eso es un problema no me parece nada extraordinario; al contrario, me parece de lo más ordinario. Es como hablar de las copias de seguridad. No cabe en mi cabeza que una empresa no tenga copias de seguridad; sería una temeridad, una imprudencia, una estupidez, una insensatez, un ejercicio de ignorancia y todas ellas juntas. Como decía aquel eslógan de la DGT hace unos años: las imprudencias se pagan, y cada vez más. Así que, resumiendo, desde que comencé a trabajar en esto de la informática, han pasado poco más de nueve años y ahora cualquier empresa con un mínimo de sentido común dispone de un sistema de monitorización TIC, mejor o peor gestionado, mejor o peor montado. Bravo por ellos. Applause.

Pasemos a temas más interesantes. Hace casi ocho años que Gartner acuñó el término BAM: Business Activity Monitoring (ya hemos hablado de esto en Security Art Work). Dicho en una frase y sin pretender total exactitud, se trata de monitorizar, analizar y gestionar indicadores propios del negocio basados en información en tiempo real. Cualquiera diría que parece lógico; de hecho, mucha parte del funcionamiento de las empresas de inversión financiera es precisamente ese. Saber que un sistema ha caído puede tener su gracia, pero saber cuándo el margen de una venta es inferior a un 5% sobre el precio de coste tiene mucho más sentido para el negocio y, francamente, es más interesante. Al fin y al cabo, la disponibilidad o capacidad remanente de un servidor o un router no deja de ser un indicador para el personal de Sistemas y Comunicaciones, pero que no tiene o no debería tener mucho más sentido fuera de ese ámbito. Sin duda, cualquier departamento puede identificar un puñado de indicadores que no sólo les resultarían extremadamente útiles en sus tareas diarias, sino que les ayudarían a detectar situaciones anómalas o que requieren su intervención; piénsenlo dos minutos. La idea detrás de BAM es saber qué pasa: sistematizar y automatizar el tratamiento de información en tiempo real asociada a los procesos corporativos que permitan a la organización tomar decisiones de manera más rápida y eficiente. ¿Saben aquello de que la información es poder? Pues eso, ni más ni menos.

No sé qué les parece todo esto. No sé si están de acuerdo conmigo o todo esto les parece un rollo macabeo. Como pueden imaginarse, a mí me parece de lo más coherente, y por eso me cuesta entender que a estas alturas, los sistemas de monitorización BAM no estén tan extendidos ni madurados como los TIC que les comentaba. Sin querer ser duro y pensar que se trata de simple falta de visión o miopía generalizada (les apuesto a que la mayoría de sistemas de monitorización TIC de la mayor parte de las empresas tienen menos tiempo del que nos creemos), la razón quizá sea la excesiva dependencia geek de muchas empresas, donde los sistemas/aplicaciones se conciben como mucho más que meros “sustentadores” de los procesos de negocio, quizá la escasez de recursos o simplemente la resistencia natural y poca “disponibilidad” del personal para aceptar este tipo de novedades. Claro que después de todo, nadie dijo que fuese fácil y como decía Jane Fonda, No pain, no gain.

La cuestión aquí, si me permiten ponerme algo trascendente, es que BAM es el principal camino —que conozco— a la mejora de la eficiencia de los procesos corporativos y de la productividad, algo que, a decir por los datos oficiales y si acudimos al discurso económico diario, no es algo de lo que vayamos sobrados en este país. Por eso, que sistemas BAM implantados sean hoy por hoy casi una rareza, es algo que me causa estupor. Y les prometo que no exagero un ápice.

(Comenzamos la semana con la colaboración de un amigo al que muchas veces hemos invitado a escribir, pero hasta ahora no se había decidido. Nos ha pedido, no obstante, que desea firmar anónimamente y que su colaboración aparezca firmada con el pseudónimo Walt Kowalsky. Esperamos que les parezca interesante)

Llevo tiempo siguiendo este interesante blog, que se ha convertido en uno de mis favoritos y después de un tiempo queriendo aportar mi granito de arena, me he lanzado a la piscina y he preparado la siguiente colaboración que espero que les sea de agrado.

A pesar del título del post, no esperen un enfrentamiento a lo Quevedo-Gongora, puesto que por ahí no van los tiros. Voy a ponerles en situación comenzando con el recurso fácil de la pregunta retórica: ¿se han copiado de ustedes en algún examen? Seguramente contestarán que sí y si no me equivoco muchas veces habrá sido de mutuo acuerdo. Pero, ¿se han copiado de ustedes sin su permiso? Si ha sido así traten de recordar la sensación de aquel momento. Llevaban semanas preparando ese examen concienzudamente, noches sin dormir, cafeína recorriendo su torrente sanguíneo para al final tener la certeza de que el día del examen la cosa va a ir bien y que pasaremos la prueba con nota. Entran al examen y comprueban que a su lado se sienta aquel compañero que únicamente vieron el primer día de clase, aquel que se dedicó a salir todos los jueves y a llegar a laboratorio para que el compañero le haga las prácticas. Comienza el examen y todo marcha de acuerdo con su plan maestro, pero entonces se dan cuenta de que el compañero de al lado está copiando descaradamente nuestro examen… Se acaba el examen y unas semanas más tarde cuando salen las notas comprueban que aquel jeta ha sacado casi la misma nota que nosotros, pero sin asistir a clase, SIN DEDICARLE RECURSOS. En ese momento piensan en todo el tiempo y esfuerzo que han dedicado a prepararse para aprobar ese examen, y lo poco que ha invertido nuestro compañero en aprobar, y piensan que la vida no es justa.

Alguien les susurra C´est la vie….

[Read more…]

(Para acabar la semana en que hemos superado los 1000 suscriptores al feed, hoy tenemos una colaboración de Rafael García, amigo, antiguo colaborador de S2 Grupo y con extensos conocimientos y experiencia en la gestión de centros de proceso de datos, como muestra en su blog. Esperamos que les guste la entrada tanto como a nosotros; por lo demás, pasen un buen fin de semana, nosotros nos vamos hasta el lunes, aunque esporádicamente puede que aparezcamos por “el” Twitter)

Hace casi un año, el pasado 28 de Febrero de 2009 YouTube dejó de funcionar durante 2 horas. La incidencia —una incidencia de su conectividad— no se debió ni a la falta de redundancia de sus infraestructuras, ni a un fallo coordinado de todos sus proveedores, ni a un apagón simultáneo de todos sus centros de datos; ni siquiera al súbito interés simultáneo y mundial por el último vídeo de la Obama girl. YouTube dejó de funcionar debido al secuestro de parte de su direccionamiento IP por parte del operador Pakistan Telecom. ¿Secuestro? Sí, secuestro o suplantación del direccionamiento IP, algo tan antiguo como el propio protocolo BGP.

BGP4 (RFC 1771 y RFC 1772) es el protocolo que se utiliza para intercambiar tráfico entre los proveedores de servicios de Internet. Sus funciones son bastante simples: básicamente permite que los sistemas autónomos (AS) —las subdivisones organizativas que gestionan los prefijos de enrutamiento en Internet, habitualmente un ISP— comuniquen a otros sistemas autónomos cómo alcanzar redes en Internet. Específicamente BGPv4 intercambia prefijos de direcciones de Internet seguidas de los identificadores de los sistemas autónomos a través de los cuales se alcanza dicho direccionamiento. Todos los ASs intercambian esta información entre ellos asumiendo que es correcta. BGP, aunque permite implementar políticas sobre los prefijos que anuncia o deja de anunciar, no tiene ningún mecanismo para saber si la información de sus tablas de enrutamiento es válida y si realmente se la está suministrando quien debe suministrársela. Este funcionamiento se denomina confianza transitiva, vamos, que si me creo lo que me dices me estoy creyendo lo que a tí te dicen todos tus vecinos y los míos te creerán. Transitive faith podrían haberle puesto.

[Read more…]

Hace poco tuvimos la necesidad de incluir unos certificados SSL firmados por VeriSign para la navegación HTTPS en un proxy inverso Squid. El problema fue el hecho de que el cliente que lo requería había gestionado personalmente la creación y firma del certificado con una entidad certificadora internacional, la cual realizó todo el proceso con una herramienta propietaria basada en JAVA. Esto hizo que nosotros recibiéramos un fichero binario ilegible por OpenSSL, y sobre todo, por Squid.

Tras indagar un poco y averiguar que la aplicación del cliente había hecho uso de la herramienta keytool de JAVA respiré aliviado, pues suponía que seria trivial obtener los datos. Primeramente, pensando que en 20 minutos podría estar almorzando inspeccione el contenedor mediante el comando:

# keytool -list -v -keystore server_keystore

[Read more…]