El 11 de noviembre de 2019, a las 21:57 UTC, Fastly desplegó una nueva compilación de su software de terminación HTTP/2 en dos servidores de caché de Fastly del centro de datos de Mineápolis-St. Paul (STP). Esta compilación contenía un fallo de procesamiento que implicaba la reutilización de la conexión entre sistemas internos de Fastly (no relacionada con la multiplexación de HTTP/2) y provocaba que algunas peticiones entrantes de HTTP/2 destinadas a servicios de los clientes de Fastly pudieran enrutarse por error a un grupo de hasta 20 servicios y orígenes de clientes de Fastly. Esto daba lugar a que algunos datos de peticiones de cliente se entregaran a un origen de cliente incorrecto, con el consiguiente envío de respuesta por parte de este. Es posible que los clientes cuyos orígenes recibían estas peticiones por error registraran los datos de las solicitudes incorrectamente enrutadas. Fastly recibió por primera vez notificación de este incidente por parte de un cliente el 12 de noviembre de 2019 a las 23:07 UTC. El 13 de noviembre de 2019, a las 00:50 UTC, todo el tráfico de clientes se desvió del centro de datos afectado. Fastly comenzó inmediatamente una investigación, y el 14 de noviembre de 2019, a las 00:31 UTC, confirmamos la presencia de datos de peticiones incorrectamente enrutadas en los registros de un cliente. Calculamos que el fallo afectó al 0,00016 % de nuestro tráfico global de peticiones durante un periodo de 27 horas. Es poco probable que las peticiones de cliente afectadas procedieran de fuera de Norteamérica. Como Fastly no almacena datos de registro de los clientes, no podemos asegurar con certeza si una petición afectada en concreto se enrutó incorrectamente.

Hemos empezado nuestras cotizaciones en la Bolsa de Nueva York el día de hoy, lo cual supone nuestra primera jornada de negociación como empresa cotizada. La Oferta Pública Inicial (IPO) de Fastly es todo un hito para la empresa, además de ser un motivo de celebración del éxito colectivo de nuestra comunidad global y nuestros clientes. Estoy tremendamente orgulloso de todo lo que hemos construido juntos; y esto es solo el principio.

Lucet, sistema de Fastly de código abierto de compilación y tiempo de ejecución de WebAssembly, está concebido para impulsar a WebAssembly más allá de los límites del navegador y para diseñar una plataforma que permita una ejecución más rápida y segura en la nube de borde de Fastly. En esta entrada de blog, vamos a presentar todas las fases del ciclo de vida de Lucet y vamos a probar su rendimiento para hacer hincapié en formas de mantener un nivel bajo de carga.

Nos llena de emoción presentar hoy el proyecto de código abierto de Lucet, nuestro compilador y motor en tiempo de ejecución nativos para WebAssembly. WebAssembly es una tecnología que está diseñada para permitir que los navegadores ejecuten programas en condiciones de seguridad a velocidades aproximadamente iguales a las nativas; desde principios de 2017, viene incluido en los cuatro principales navegadores.

Nos entusiasma haber dedicado tantos esfuerzos a QUIC, un nuevo protocolo de transporte que es más sensible, seguro y flexible que el que utiliza Internet en la actualidad. El mismísimo Jana Iyengar, que trabaja para Fastly y es coautor del documento esencial, te explica por qué.

En Fastly, somos conscientes de que nuestra plataforma de edge cloud forma parte de tus flujos de datos e infraestructura esenciales. Por tanto, es natural que quieras saber cómo protegemos los datos que compartes con nosotros y cómo garantizamos tus compromisos y obligaciones de seguridad y de cumplimiento normativo. La transparencia y la confianza están entre nuestros valores fundamentales, y creemos que debemos ofrecerte toda la información. En este sentido, nos complace anunciar que Fastly acaba de completar una auditoría de controles de organización de servicios 2 (SOC 2) Tipo 2 para la gestión y supervisión de nuestra plataforma de edge cloud.

El jueves 9 de agosto se publicó en Black Hat USA 2018 un artículo de investigación sobre ataques de envenenamiento de caché contra sitios web desplegados detrás de la infraestructura de almacenamiento en caché. Estos ataques tenían como objetivo potencial inyectar contenido arbitrario en la caché de la víctima. Ciertas configuraciones de los servicios de Fastly pueden resultar vulnerables si no tienen en cuenta la interacción entre los encabezados utilizados por los backends para seleccionar contenido. Este riesgo se puede mitigar por completo a través de un parche de VCL o mediante la modificación de las configuraciones de los backends.

El 6 de agosto de 2018, se hizo pública una vulnerabilidad en la implementación de TCP del kernel de Linux. La vulnerabilidad se denominó «SegmentSmack». Esta vulnerabilidad permitía a un atacante remoto provocar un ataque de denegación de servicio en el servidor de destino simplemente estableciendo una conexión TCP al servidor y enviando segmentos específicos a través de la conexión. Fastly viene trabajando con el mundo de la seguridad desde antes de la publicación de esta vulnerabilidad, para abordar cómo atajarla en nuestras redes del borde. No representa ninguna amenaza para los clientes de Fastly.

Los encabezados o headers HTTP son una forma importante de controlar de qué modo procesan tu contenido web las memorias caché y los navegadores. Sin embargo, muchos se emplean de forma incorrecta o sin sentido, lo cual incrementa la carga de tu página en momentos críticos, y quizás no funcionen del modo que tenías previsto.

Aprende a limpiar la memoria caché con JavaScript para solucionar errores y mejorar el rendimiento del frontend.

Para ayudar a nuestros clientes a proteger la seguridad de sus sitios y aplicaciones —sin dejar de ofrecer a sus usuarios experiencias fiables online— hemos construido un cortafuegos de aplicaciones web (WAF) integral y muy fácil de configurar. Para ofrecer una solución integral que proteja realmente tu infraestructura es esencial someter continuamente a prueba esa solución. En esta entrada, explicaremos cómo garantizamos la calidad en la implementación de WAF a nuestros clientes, sometiéndola continuamente a prueba utilizando nuestro testing framework o marco para pruebas WAF (FTW, por sus siglas en inglés), y profundizaremos en los hallazgos y contribuciones realizados en la comunidad OWASP CRS con FTW.

En la primera parte de esta serie echamos un vistazo al panorama cambiante de los DDoS (ataques de denegación de servicio). Queremos ofrecer una idea de la situación en términos de dimensiones y tipología de los ataques, y ayudarte a tomar decisiones mejor informadas para proteger tu infraestructura. En esta entrada compartiremos nuestra visión interna sobre la forma en que protegemos a nuestros clientes, las lecciones que hemos aprendido con los DDoS reales y presentaremos nuestra lista de verificación recomendada sobre cómo mitigar un ataque DDoS.

El miércoles 3 de enero se publicó una investigación sobre una clase de vulnerabilidades de seguridad que afecta a procesadores específicos. Estas vulnerabilidades podrían permitir que un usuario capaz de ejecutar código en un sistema obtenga acceso no autorizado a información vulnerando los límites de seguridad. Fastly ha completado el análisis inicial de estas vulnerabilidades y no cree que supongan una amenaza inmediata para los clientes de Fastly.

Los equipos de Infraestructura y Operaciones Edge Cloud de Fastly llevaron a cabo en 2017 varios hitos importantes de implementación de puntos de presencia (POP) en todo el mundo, alcanzando asimismo 20 Tbps de capacidad de borde conectada. Desde nuestra última actualización, hemos implementado puntos POP adicionales en Atlanta, Houston, Columbus y Palo Alto, nuevas ubicaciones en Ciudad del Cabo (Sudáfrica) y Columbus (Ohio), además de un nuevo punto POP habilitado para 100GE en Tokio (Japón). Estas actualizaciones nos permiten responder a las variables demandas de los clientes, reducir la latencia y mejorar la resiliencia de nuestra red. Sigue leyendo para ver lo que hemos estado haciendo.

Los equipos de ingenieros de Fastly son capaces de todo: concienzudos en el diseño de las arquitecturas, escriben códigos elegantes y resuelven con meticulosidad trabajos complejos y de envergadura. ¿Por qué son necesarias entonces las garantías de calidad o QA (quality assurance, por sus siglas en inglés)? En este post, Alice Nodelman, Senior QA Automation Engineer, explica cómo funciona el método de garantía de calidad, deteniéndose en la metodología QA que empleamos en Fastly y comparte cómo esta misma metodología podría aplicarse a tu empresa.

A fin de dejar atrás una arquitectura antigua que se nos estaba quedando pequeña con rapidez, recientemente migramos nuestra base de datos de estadísticas históricas desde una instancia de MySQL autogestionada a Google Cloud Bigtable. Sigue leyendo para averiguar cómo lo logramos (sin sufrir tiempos de inactividad).

OSS-Fuzz es un proyecto innovador que supone un avance en la ya puntera ingeniería de seguridad OSS y que mejora la calidad general del software que presta servicio a Internet. En esta publicación explicaré cómo utilizar los componentes de código abierto de google/oss-fuzz para lanzar pruebas de fuzzing autoservicio continuas para software público y privado utilizando h2o, el proxy HTTP/2 de Fastly, como ejemplo de ejecución.

La proporción de resultados de la caché o cache hit ratio (CHR, por sus siglas en inglés) figura entre las métricas más habituales con la que evaluar el rendimiento de cualquier CDN. Los clientes de CDN llevan empleándola varios años como indicador principal del grado de calidad, tanto de los servicios que estas redes prestan a sus usuarios como de la gestión del tráfico, pero esta métrica tiene más entresijos de lo que parece. Nuestro VP de Tecnología investiga qué mide realmente la CHR y la posibilidad de que necesitemos nuevas formas de calcularla y evaluarla.