¿Sabían que Cloudflare se cayó el mes pasado? El 18 de noviembre ocurrió esa gran caída, y ahora la oficial finalmente ha dado un análisis del incidente.
Es un poco irónico: el problema surgió cuando se generó un archivo de configuración incorrecto al ajustar los permisos de la base de datos, lo que provocó la caída del sistema de proxy central. CDN caído, servicios de seguridad caídos, Workers KV, Turnstile y Access todos fuera de servicio. Lo más absurdo es que el equipo al principio pensó que estaba sufriendo un ataque DDoS y después de un buen rato se dio cuenta de que era un error propio.
¿Cómo se solucionó al final? De manera simple y brusca, se devolvieron los archivos antiguos. La oficina dijo que este es el peor tiempo de inactividad desde 2019; considerando cuántos proyectos de Web3 y DApp dependen de los servicios de CF, el impacto de esta situación es realmente considerable. La vulnerabilidad de la infraestructura centralizada ha sido nuevamente puesta sobre la mesa.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
5 me gusta
Recompensa
5
5
Republicar
Compartir
Comentar
0/400
TradFiRefugee
· hace3h
Jaja, reímos hasta morir, uno se entierra y culpa a DDoS, esta operación es increíble
---
¿Un error en el archivo de permisos puede hacer colapsar todo? ¿Así es la infraestructura centralizada?
---
Espera, los problemas expuestos por CF son incluso más aterradores que la caída misma
---
Web3 necesita desprenderse urgentemente de este tipo de fallos de punto único, realmente no se puede seguir apostando
---
La más grave desde 2019 y aún se atreven a decir que son estables, me hace reír
---
¿Un error de configuración puede eliminar tantos servicios, quién asume este riesgo?
---
La razón que da el oficial suena absurda, no tiene sentido
---
Los DApp debieron asustarse mucho ese día, si CF cae, se acaba todo
---
¿Así que esta es su preciada infraestructura centralizada?
---
Retroceso de archivos antiguos resuelto, así que no tienen nada de tecnología avanzada, ¿verdad?
Ver originalesResponder0
LiquidationSurvivor
· hace10h
Ah, esto, realmente es absurdo que uno mismo se haya colgado, pensaba que me habían golpeado, jaja
Así son los servicios centralizados, Web3 realmente tiene que aprender la lección
Un error tan básico en el archivo de configuración puede causar un impacto tan grande, realmente no se puede soportar.
Ver originalesResponder0
WenMoon42
· hace10h
Jaja, pensé que había sido hackeado, pero resultó que mi propio archivo de configuración se rompió, me muero de risa.
Ver originalesResponder0
GweiObserver
· hace10h
Jaja, pensaba que había sido atacado por el lío que él mismo creó, esta acción es increíble
---
Configurar los permisos incorrectamente lleva a la muerte social, ¡qué vergonzoso que el CDN se caiga todo!
---
Una vez más se demuestra que la infraestructura centralizada es un gran agujero, ya era hora de descentralizar
---
Workers KV en todas partes GG, los proyectos que dependen de esto definitivamente explotarán ese día
---
Retroceso y todo solucionado, ¿por qué no he visto un plan de compensación?
---
Siempre dije que las cosas centralizadas no son confiables, y ahora ha explotado de nuevo
---
Un error en el archivo de configuración causó la caída de toda la red, realmente se atreve a pasar esto
---
¿El más grave desde 2019? Parece que CF también tendrá que aprender la lección.
Ver originalesResponder0
OnChainDetective
· hace11h
no voy a mentir, ese error en el archivo de configuración es exactamente el tipo de patrón de riesgo operativo que hemos visto antes: mal diagnosticado como un ataque externo primero, luego boom, una interrupción autoinfligida. movimiento clásico, honestamente
¿Sabían que Cloudflare se cayó el mes pasado? El 18 de noviembre ocurrió esa gran caída, y ahora la oficial finalmente ha dado un análisis del incidente.
Es un poco irónico: el problema surgió cuando se generó un archivo de configuración incorrecto al ajustar los permisos de la base de datos, lo que provocó la caída del sistema de proxy central. CDN caído, servicios de seguridad caídos, Workers KV, Turnstile y Access todos fuera de servicio. Lo más absurdo es que el equipo al principio pensó que estaba sufriendo un ataque DDoS y después de un buen rato se dio cuenta de que era un error propio.
¿Cómo se solucionó al final? De manera simple y brusca, se devolvieron los archivos antiguos. La oficina dijo que este es el peor tiempo de inactividad desde 2019; considerando cuántos proyectos de Web3 y DApp dependen de los servicios de CF, el impacto de esta situación es realmente considerable. La vulnerabilidad de la infraestructura centralizada ha sido nuevamente puesta sobre la mesa.