Qué tan profundo es el agua en la industria del ajedrez, los que han participado en ella entender que los ataques DDoS son comunes, pero lo que hace que el cuero cabelludo de la gente entumecida es a menudo el tipo de trucos “silenciosos” - como el secuestro de DNS. Los jugadores, obviamente, introduzca la dirección de su sitio web oficial, pero los resultados fueron dirigidos a un sitio de phishing idénticos, contraseñas de cuentas, cantidad de recarga al instante ser rastrillado. Esto es más repugnante que paralizar directamente el servicio, perteneciente al asesinato del corazón.
Me comí este tipo de pérdida en los primeros años. En ese momento, pensé que la seguridad del servidor para hacer cubo de hierro en general, todo tipo de alta defensa, WAF pila llena, el resultado del atacante no tocó mi servidor, desvío directo, en mi DNS parsing manipulación. Los usuarios simplemente no pueden llegar a la puerta de mi servidor, a medio camino de ser secuestrado. Durante ese período de tiempo, las quejas fueron abrumadoras, todos dijeron que la recarga no llegó, inicio de sesión anormal, y sólo después de medio día de investigación reaccionaron: el DNS fue envenenado.
El DNS es la “guía telefónica” de Internet, responsable de traducir los nombres de dominio en direcciones IP. Sin embargo, el proceso de consulta DNS tradicional es básicamente en texto plano y carece de mecanismos de autenticación - es como preguntar a una persona al azar en la calle por direcciones, y luego la otra persona te señala la dirección equivocada y tú ni siquiera lo sabes. Un secuestrador puede manipular los resultados de una consulta DNS en cualquier punto del proceso (caché local, resolver recursivo, servidor autoritativo).
Especialmente en el negocio del ajedrez, la motivación para atacar es demasiado fuerte. El secuestro por parte de bandas de chantaje es directamente rentable, y el secuestro por parte de los competidores puede arrebatarle sus usuarios. De hecho, he probado, incluso si sólo un corto tiempo para resolver a la IP incorrecta, dentro de media hora puede perder una gran cantidad de usuarios activos y el flujo de recarga. No creas en la tonteria de “solo usa DNS publicos”, 8.8.8.8 y 114.114.114.114 siguen estando en riesgo de ser contaminados.
Para prevenir realmente el secuestro de DNS, hay que empezar en dos niveles básicos: unResolución redundante de varias líneas DNSEl otro esVerificación de firma DNSSECLa combinación de estas dos tácticas equivale tanto a múltiples pólizas de seguro para su dominio como a la verificación de la huella digital del proceso de resolución. La combinación de estas dos tácticas equivale tanto a múltiples pólizas de seguro para su dominio como a una verificación de la huella digital del proceso de resolución.
Empecemos por las líneas multi-DNS. Hoy en día, es una apuesta arriesgada alojar servicios de resolución con un solo proveedor. Mi estrategia actual es utilizar al menos dos o más proveedores de servicios DNS al mismo tiempo, y requerir una CDN de alta defensa para soportar el cambio de resolución multilínea. Por ejemplo, utilizo CDN5 para la resolución primaria, CDN07 para la resolución de respaldo y otro 08Host para el respaldo. Tenga en cuenta que no se trata simplemente de configurar unos cuantos registros NS y ya está, sino de configurar laPrioridades y controles de salud。
Tomando la configuración de CDN5, yo configuraría la automatización de la conmutación por error en su consola:
Esta configuración significa que la línea DNS principal hará una comprobación de salud cada 30 segundos, y si la prueba falla 2 veces consecutivas, cambiará automáticamente a la línea de respaldo. En la prueba real, incluso si la línea principal es secuestrada o contaminada, la línea de reserva puede mantener la resolución normal. Pero el núcleo de la multilínea esservicio heterogéneo-No te decantes por varias marcas de la misma empresa, que es probable que compartan infraestructura y lo cuelguen todo junto.
Sin embargo, las líneas múltiples son sólo “redundancia”, no protección contra la “manipulación”. Lo que realmente puede evitar la falsificación de resoluciones desde la raíz es DNSSEC (Domain Name System Security Extensions). Utiliza el cifrado asimétrico para firmar digitalmente los registros DNS, y el servidor recursivo verifica que la firma coincide antes de devolver el resultado de la resolución. Si la firma no coincide, significa que el registro ha sido manipulado y la respuesta será rechazada directamente.
Instalar DNSSEC es un poco más complicado, pero merece la pena. Primero hay que activar el soporte DNSSEC en el registrador de dominios (algunos proveedores nacionales lo ocultan un poco más, hay que buscar el servicio de atención al cliente para abrirlo), y luego generar pares de claves:
Tras la generación, se obtienen las claves pública y privada, la clave privada se guarda para uno mismo y la clave pública debe cargarse en la consola DNS y añadirse al registro DS (Delegation Signer) del nombre de dominio. El registrador debe enviar el registro DS al registro del dominio de nivel superior (por ejemplo, .com). La autenticación encadenada completa está configurada.
Pero DNSSEC tiene un escollo: no todas las CDN lo soportan perfectamente. Con el fin de ahorrar recursos, algunos servidores recursivos CDN de alta defensa de pequeño tamaño no verifican en absoluto las firmas DNSSEC. He pisado la mina, y sin duda utilizaré el comando dig para comprobarlo cuando elija un modelo más adelante:
Si hay una bandera `ad` (datos auténticos) en el resultado devuelto, significa que el nodo CDN soporta completamente la autenticación DNSSEC. Actualmente, CDN5 y 08Host tienen el soporte DNSSEC más estable, y CDN07 es ocasionalmente perezoso en algunos nodos de borde sin verificación.
Además de las herramientas técnicas, hay que quedarse atrás a nivel empresarial. He hecho que las páginas críticas para el negocio (por ejemplo, las de recarga)Comprobación de la resolución secundariaEl cliente, después de adquirir una IP por primera vez, verifica que la IP es legítima a la inversa a través de un canal cifrado hacia el servidor comercial. Si es secuestrada, al menos alertará y bloqueará la transacción a tiempo. El nivel de código tiene el siguiente aspecto:
Por último, para ser honesto, la esencia de la seguridad de DNS es la cadena de confianza, y CDN de alta defensa en este anillo no debe arrastrar el pie. Debo mirar tres puntos al seleccionar: si para apoyar el acceso de múltiples proveedores de DNS, si todo el nodo para abrir la autenticación DNSSEC, si la resolución de anomalías en las alarmas en tiempo real. Los que ni siquiera le permiten configurar el registro DS proveedores CDN, directamente pasar.
El propio sector del ajedrez es delicado, y los atacantes siempre buscan deficiencias. La defensa del servidor es de nuevo difícil, y la fuga de DNS también en vano. Análisis sintáctico multilínea + DNSSEC + verificación de la capa de negocio, estos tres ejes hacia abajo, no quiere decir a prueba de tontos, pero al menos puede hacer que 99% bandas de secuestradores de DNS tomar la iniciativa para eludir. El resto de la 1%, que puede tener que ser superado físicamente.
Ah, sí, y mide regularmente la salud de la resolución de tu dominio con herramientas como `dnsviz.net` o `cloudflare-dns.com/check`. No esperes a que los usuarios se quejen: hoy en día, incluso las CDN tienen que ser “a prueba de mate”.
