¿Los empleados de Facebook no pudieron ingresar a su propio edificio para solucionar los problemas del enrutador durante una interrupción reciente (seis horas)?

Se ha informado de manera un tanto misteriosa que los empleados de FB no pudieron corregir una configuración incorrecta del enrutador (BGP) de manera oportuna

porque "las personas que trataban de averiguar cuál era este problema ni siquiera podían entrar físicamente al edificio" para averiguar qué había salido mal.

También se menciona que "el cierre significó que los anuncios no se publicaron durante más de seis horas en sus plataformas".

Puede que FB no quiera decir más por vergüenza o algo así, pero suena como una historia bastante extraña. ¿Existe alguna evidencia que corrobore que la falta de acceso físico fue el culpable de la interrupción prolongada?

¿Qué tiene que ver el estado de los anuncios con la pregunta central?
@DanielRHicks: la BBC solo dio el tiempo de inactividad en esos términos más concretos... para los anuncios. Solo dijeron "varias horas" para otros servicios.
@GordonDavisson ah sí, no vi eso
En un hilo de reddit durante la interrupción, un usuario llamado ramenporn que afirmaba estar en el equipo de recuperación/investigación publicó (entre otras cosas): "Hay personas que ahora intentan obtener acceso a los enrutadores de emparejamiento para implementar arreglos, pero las personas con el acceso físico está separado de las personas que saben cómo autenticarse realmente en los sistemas y las personas que saben qué hacer realmente, por lo que ahora existe un desafío logístico para unificar todo ese conocimiento". Luego eliminaron los comentarios y su cuenta, por lo que es difícil verificar esto. Ver: archive.is/Idsdl
La pregunta es un poco ambigua: hay una diferencia entre "su propio edificio" en el sentido de un edificio perteneciente a FaceBook, y lo mismo en el sentido de un edificio donde normalmente trabajan esos empleados. Ciertamente parece que el edificio en cuestión satisface la descripción anterior, pero no estoy tan seguro de que satisfaga la última. El reclamo está coloreado por cuál de esas interpretaciones se aplica.
@JohnBollinger: sí, es probable que varias personas hayan tenido que ir a un centro de datos que casi nunca visitan de otro modo... incluso si es propiedad de FB. La forma en que se expresa la historia es como si FB fuera una pequeña empresa con uno o pocos edificios.
No puedo comentar cómo Facebook hace su seguridad... pero puedo decirles que, como empleado de Google, si me presentara en un centro de datos aleatorio y exigiera acceso, el personal de seguridad probablemente me escoltaría fuera de las instalaciones (y Dudo que mi placa funcione tampoco). Los centros de datos son edificios extremadamente sensibles con una seguridad muy diferente a las oficinas corporativas "normales".

Respuestas (2)

Tomó "tiempo extra" para llegar al sitio.

Del informe de Facebook sobre el apagón :

...estas instalaciones están diseñadas con altos niveles de seguridad física y del sistema en mente. Es difícil acceder a ellos y, una vez que está adentro, el hardware y los enrutadores están diseñados para que sea difícil modificarlos, incluso cuando tiene acceso físico a ellos. Por lo tanto, tomó más tiempo activar los protocolos de acceso seguro necesarios para que las personas estuvieran en el sitio y pudieran trabajar en los servidores.

Esto no desglosa el tiempo que les tomó ingresar al edificio en comparación con el tiempo que les llevó modificar el hardware y los enrutadores. No es demasiado difícil imaginar cómo esta distinción podría perderse y atribuirse únicamente a no poder ingresar al edificio.

Sabemos que entrar al edificio prolongó la interrupción hasta cierto punto, aunque, por lo que sabemos, podría haber sido solo unos minutos.

Algo que leí (no recuerdo dónde...) decía que debían participar tres grupos diferentes de personas: un grupo que tuviera acceso físico a los servidores, otro que tuviera las credenciales para iniciar sesión y modificar la configuración, y un tercero que tenía la experiencia técnica para hacer las correcciones necesarias. El acceso remoto no era una opción (¡por un problema de red...!), por lo que tenían que conseguir que alguien de cada uno de los tres grupos estuviera físicamente presente en la sala de servidores.
@avid Supongo que la mayoría, si no todos, los empleados de Facebook poseen teléfonos celulares. No estoy seguro de por qué sería necesario que 3 personas estuvieran presentes siempre que tengan algún medio de comunicarse entre sí...
@DarrelHoffman No estoy seguro de que un teléfono celular realmente ayude. No es que supieran lo que estaba mal, tenían que diagnosticar el problema. A menos que la cámara del teléfono celular apuntara a la pantalla, lo cual funciona, pero es una forma dolorosa de trabajar.
@DarrelHoffman ¿Quién sabe? En cualquier caso, eso fue lo que leí.
@DarrelHoffman Supongo que los centros de datos de alta seguridad están construidos como una jaula de Faraday, lo que hace que cualquier comunicación por radio (incluidos los teléfonos celulares) sea inútil. También imagino que hay algunas puertas que requieren autenticación biométrica. Y eso no es todo... así que, en resumen, no importa cuáles de esas medidas se implementen realmente allí: la información de que un sistema de seguridad que está desconectado de Internet requiere que varias personas estén físicamente allí es completamente creíble para mí.
@orithena: Realmente no hay necesidad de construirlos como jaulas de Faraday. Por lo general, tienen pisos falsos (es decir, placas de piso sobre una rejilla de metal regular), techos falsos (es decir, placas de techo que cuelgan de una rejilla de metal regular), largas filas de estantes de metal llenos de cajas de metal con tuberías de metal y armazones de cables de metal que se extienden entre a ellos. Incluso sin diseñarlos de esa manera a propósito, son esencialmente cajas de metal gigantes llenas de muchas cajas de metal pequeñas instaladas en cajas de metal de tamaño mediano, todas emitiendo radiación EM. i.redd.it/pu3odmbdpqm71.jpg
@DarrelHoffman Estoy bastante seguro de que la capacidad de obtener acceso físico/ingresar credenciales/solucionar el problema se distribuye entre tres grupos de personas por razones de seguridad, de modo que ninguna persona pueda alterar las cosas en los servidores por sí misma. Entonces, si una persona del grupo "solucionar el problema" puede simplemente hacer dos llamadas de teléfono celular para obtener acceso físico e iniciar sesión, anula todo el propósito, ¿no lo cree? Por lo tanto, todos necesitaban estar físicamente presentes.
@avid Esa información provino de un usuario de Reddit que afirmó trabajar para Facebook, comentando esta publicación de r/sysadmin . El usuario eliminó sus comentarios y toda su cuenta poco después. El comentario fue archivado aquí .
@JörgWMittag Ampliaré mi oración: "... construido como una jaula de Faraday (ya sea intencional o no)" :)
Como dice el viejo chiste, la seguridad es fácil. ¡ Es difícil dejar entrar a la gente !
Como alguien que ha trabajado para una gran tecnología durante años... Es bastante normal que los empleados no tengan acceso local a sus credenciales a centros de datos aleatorios a los que normalmente no ingresan. Ahora bien, si esto sucede fuera de horario (media noche o fin de semana), bueno, santo cielo, pueden pasar horas hasta que llame a la persona adecuada para aprobar las cosas. Ahora, si necesitaban tres grupos diferentes en el centro de datos, es probable que solo uno de ellos tuviera acceso, por lo que habrían tenido que encontrar 2 VP para firmar la seguridad de DC para permitirles ingresar... Esto podría llevar de 4 a 8 horas sin problemas.

Como dice la respuesta de Robb Watts, Facebook ha reconocido que esto era parte del problema , por lo que sabemos que la afirmación es cierta. ("... tomó más tiempo activar los protocolos de acceso seguro necesarios para que las personas estuvieran en el sitio y pudieran trabajar en los servidores".) La comunicación personal de fuentes no identificadas a un reportero técnico acreditado específicamente afirmó que el acceso a la tarjeta estaba caído, aunque Facebook no nos está dando ese nivel de detalle.

Esa respuesta es la única necesaria para abordar el reclamo inmediato.

Esta respuesta analiza algunos mecanismos propuestos de por qué esto podría haber sido el caso, dado el contexto más amplio de la interrupción. (Considérelo como un complemento: si la pregunta original era "¿Por qué murió JFK?" y la respuesta estrictamente correcta es "Le dispararon", esta respuesta explica cómo eso resulta en la muerte).

Al momento de escribir este artículo, Facebook no ha brindado más detalles; sin embargo, muchas publicaciones en redes sociales diferentes han explorado mecanismos sobre cómo un problema de red podría impedir el acceso al edificio, a saber, que los sistemas electrónicos que autorizan el acceso también se vieron afectados por la interrupción.

Partes externas como CloudFlare , una importante empresa de facilitación de redes no relacionada con Facebook, originalmente se dieron cuenta del problema debido a la falta de registros de DNS . DNS es el sistema de búsqueda que convierte entre nombres de recursos memorables, como sitios web, y las direcciones numéricas reales que actualmente proporcionan el recurso. Las primeras especulaciones sugirieron que con el DNS inactivo, Facebook tampoco podría acceder a sus propios sistemas, incluido el sistema de directorio del servidor LDAP que rastrearía qué empleados pueden acceder a qué instalaciones.

Sin embargo, el informe de Facebook sobre la interrupción indica que el orden de los eventos fue un poco diferente. Una operación de mantenimiento de rutina (que salió mal) apagó accidentalmente las principales conexiones de red internas ("columna vertebral") entre los centros de datos de Facebook. Como resultado, ninguno de los sistemas internos de Facebook podía comunicarse. Los servidores DNS internos de Facebook, las máquinas que le dicen al tráfico cómo llegar a Facebook, también perdieron la conectividad con los centros de datos. Ahora, esos sistemas están diseñados para funcionar solo si creen que pueden proporcionar datos confiables: si pierden la conexión con los servidores reales de Facebook, no pueden hacer su trabajo de decirles a otros dónde encontrar los recursos de Facebook. Entonces le dicen a todo Internet que deje de preguntarles, usando algo llamado Protocolo de puerta de enlace fronteriza.o BGP (un sistema que ayuda a las máquinas de red a mapear las mejores formas de enviar tráfico de un lado a otro).

Esencialmente, en ese momento, todos los servidores DNS de Facebook se enfermaron a la vez, y nadie pudo encontrar Facebook nunca más. Pero esto no era estrictamente un problema de DNS, ni siquiera estrictamente de BGP, como se dieron cuenta los observadores cuidadosos poco después (aunque el problema de BGP a DNS causó daños por salpicadura a todo Internet en forma de tráfico de DNS elevado). Las conexiones entre los balanceadores de carga de los servicios de Facebook (que dirigen el tráfico desde el exterior a ubicaciones específicas dentro de las redes de Facebook) y la Internet más amplia aún funcionaban en algunos casos. La causa raíz fue que Facebook había destruido su propia red interna.

Independientemente del mecanismo exacto, el impacto en el acceso físico sería una interrupción de la comunicación entre los lectores de cerraduras de las puertas, que obtienen un código de identificación de la credencial de un empleado, y el sistema de directorio que confirma a qué identificaciones de empleados se supone que tienen acceso. qué instalación. Originalmente dije que esto se debía al problema de DNS (lo que significa que los lectores de puertas ya no podían encontrar la ubicación del servidor LDAP), pero la mejor práctica es hacer que los servidores de directorio sean accesibles solo en redes privadas (o privadas virtuales), no en Internet. (ver también aquí y probablemente más referencias de las que tengo tiempo de rastrear). Es más probable que el servidor de directorio que otorga acceso se haya conectado a través de la misma conexión de red troncal interna que se cayó al principio.

En cualquier caso, hay una anulación física para esto, con una llave anticuada. Pero no entregas una copia de esa llave a todos los que tienen acceso al edificio; pueden hacer copias, tendrías que recuperarlas cuando cambiaran sus funciones, etc., etc. En cambio, hay un pequeño equipo de seguridad con anula el acceso físico. Sin embargo, en la medida en que el equipo de ingeniería utilice productos internos de Facebook (por ejemplo, Messenger) para la comunicación, estos también se habrían visto afectados por la interrupción; y habría habido demoras en encontrar otra información de contacto debido a que el directorio no estaba disponible.

Nuevamente, esta es una reconstrucción del mecanismo a través del cual se habría producido el acceso físico. No lo sabremos con certeza hasta que Facebook publique una autopsia más específica, pero mi objetivo es demostrar la plausibilidad de las afirmaciones informadas en función de las circunstancias circundantes.

Este análisis es mayormente correcto, pero hay un problema. Si tiene un contacto en WhatsApp, tiene su número de teléfono real. No necesita usar LDAP en ese momento. Resolver el resto del problema sigue siendo una pesadilla.
Tenía la impresión (confirmada por la publicación del blog de Cloudflare, etc.) de que el problema estaba relacionado con BGP, no solo con DNS. Entonces, ¿por qué los servidores internos de Facebook no podrían comunicarse entre sí? Supongo que todos están en el mismo ASN, porque Facebook no parece tener varios.
Entiendo por qué cree que esta es la respuesta más probable, pero no ha demostrado que realmente sucedió.
@CJR Si los servidores DNS informan ciertos tipos de error, ese error se propagará y se almacenará en caché.
@CJR Esa es la "cadena de eventos" en el tercer párrafo. Estaba tratando de no meterme demasiado en problemas, pero como interpreto 1 y 2, el error original hizo que los servidores DNS de Facebook perdieran la conectividad con los centros de datos; los servidores DNS respondieron al error enviando actualizaciones de BGP que los desconectaron de Internet.
De acuerdo con esta publicación de blog en engineering.fb.com , el desencadenante inicial fue un problema de enrutamiento en la red troncal interna de FB; eso llevó a sus instalaciones a dejar de anunciarse en el mundo exterior (a través de BGP) como formas de llegar a FB; esto hizo que los servidores DNS de FB fueran inalcanzables, por lo que las entradas de DNS comenzaron a caducar. Entonces, la cadena de fallas fue enrutamiento interno -> enrutamiento externo (BGP) -> DNS.
Esto significa que los problemas que se ven dentro de la red de Facebook son bastante diferentes de los que se ven desde fuera. Perdimos el acceso a su DNS debido a problemas con BGP, pero desde adentro BGP es irrelevante. Dependiendo de cómo estén configurados sus servidores DNS, es posible que incluso hayan tenido servidores secundarios en cada instalación, lo que significa que el DNS seguiría funcionando bien (internamente) durante la interrupción. Es más probable que el verdadero problema sea que los lectores de tarjetas de la instalación A no pudieron comunicarse con el servidor LDAP de la instalación B porque la red troncal interna no funcionaba.
Esa fue también mi interpretación: todas las tablas de enrutamiento se cayeron, los centros de datos se desconectaron de la red y nada podía comunicarse con nada que no fuera el siguiente rack. El DNS fue la falla externa, pero nada podía enrutar incluso si el DNS estaba activo, por lo que no importaba. Sin embargo, es difícil saberlo a partir de los comunicados de prensa, estoy interesado en leer un libro blanco o algo así si Facebook alguna vez publica detalles.
@GordonDavisson No creo que tengamos ninguna evidencia real de que haya problemas de acceso a la tarjeta (LDAP o de otro tipo), solo tweets. Si los ingenieros que normalmente no están en el sitio tuvieron que ser enviados al sitio, dudo que tuvieran acceso a la tarjeta en primer lugar. Por la forma en que está escrito su informe , lo interpreto como un proceso lento para permitir que una persona ingrese al edificio (potencialmente exacerbado si los registros de recursos humanos, etc., que muestran que este tipo es un empleado real también estaban fuera de línea)
@GordonDavisson Hmm... mi lectura fue que los lectores de tarjetas en A no podían llegar a LDAP en B porque el DNS de Facebook había explotado, por lo que una vez que el (presumiblemente corto) caché de DNS TTL había expirado, ya no podía encontrar rutas. Pero probablemente tenga más sentido que no hayan expuesto el LDAP a Internet en general.
@mrig Verdadero; Solo estaba usando lectores de tarjetas (hipotéticos) y servidores LDAP como ejemplo. Mi punto era que los problemas dentro de la red de Facebook eran diferentes de lo que veíamos desde el exterior. Desde el exterior, vimos problemas con BGP y DNS; desde adentro, BGP es irrelevante y, por lo que sabemos, DNS puede haber estado funcionando bien. (O es posible que el DNS también haya fallado internamente. Simplemente no podemos saberlo desde el exterior).
En instalaciones que conozco, los lectores de tarjetas no dependen directamente de la red. Tienen cableado dedicado a una caja de control respaldada por batería en cada edificio. La caja de control mantiene una copia local de la lista de control de acceso en el almacenamiento interno que se puede actualizar casi en tiempo real desde los servidores de la red, pero puede funcionar de forma independiente utilizando los últimos datos conocidos en el caso no tan improbable de una red o alimentación. apagón para evitar exactamente este tipo de situación.