LinuxParty
NUESTRO SITIO necesita la publicidad para costear hosting y el dominio. Por favor considera deshabilitar tu AdBlock en nuestro sitio. También puedes hacernos una donación entrando en linuxparty.es, en la columna de la derecha.
Según parece, a pesar de los intentos de Dan Kaminsky porque el último problema de seguridad del DNS quedase en secreto hasta la conferencia de Black Hat en agosto, se han publicado detalles más que suficientes sobre el problema. El título de Kaminsky en su blog DoxPara Research, "13>0",
hace referencia al parecer a los 13 días que todavía tendrían los
administradores para parchear sus sistemas si la vulnerabilidad no
hubiese sido descubierta (disclosed).
Matasano se adelantó,
a pesar del acuerdo que habían alcanzado con Kaminsky, y eliminando
posteriormente la entrada, aunque ésta se encuentra en Google, en Slashdot y en muchos otros sitios. Digamos que hay una salsa rosa nada despreciable detrás del ataque. Vía [Barrapunto.] Más detalles en la página ampliada.
«La idea básica del ataque, que puede considerarse a estas alturas de dominio público, es la combinación de DNS Forgery y DNS RRset poisoning. Se trata de conseguir, mediante la repetición de peticiones, que un servidor DNS acepte como respuesta legítima una respuesta ilegítima de nivel 3, y que ésta incluya información sobre la IP de otros dominios de nivel 3 del mismo dominio de nivel 2. En otras palabras, si se consigue que el servidor acepte como válido un paquete que le dice que xhstrn.google.com tiene como IP 1.2.3.4, aceptará como válida cualquier información adicional sobre google.com: www.google.com, mail.google.com, etc. Fascinante.»
«La idea básica del ataque, que puede considerarse a estas alturas de dominio público, es la combinación de DNS Forgery y DNS RRset poisoning. Se trata de conseguir, mediante la repetición de peticiones, que un servidor DNS acepte como respuesta legítima una respuesta ilegítima de nivel 3, y que ésta incluya información sobre la IP de otros dominios de nivel 3 del mismo dominio de nivel 2. En otras palabras, si se consigue que el servidor acepte como válido un paquete que le dice que xhstrn.google.com tiene como IP 1.2.3.4, aceptará como válida cualquier información adicional sobre google.com: www.google.com, mail.google.com, etc. Fascinante.»
-
Seguridad
- Conexión Segura NFS en Linux, Tunelizar NFS sobre SSH y Configuración de NFS sobre SSH para Mayor Seguridad
- Utilizar ssh sin contraseña con ssh-keygen y ssh-copy-id
- Millones de teléfonos móviles podrían ser vulnerables a la vigilancia del gobierno chino
- Cómo limitar las conexiones SSH a la red local en Linux
- Los televisores inteligentes son como un «caballo de Troya digital» en los hogares
- Snort para Windows, detección de Intrusos y seguridad.
- Detección de Intrusiones con las herramientas: BASE y Snort.
- El Sistema de Detección de Intrusos: Snort. ( Windows y Linux )
- Configuración con Ejemplos de Snort para Windows, detección de intrusiones
- ¿El gobierno de EE. UU. ignoró la oportunidad de hacer que TikTok fuera más seguro?
- ¿Qué es SSH y cómo se utiliza? Los conceptos básicos de Secure Shell que necesitas saber
- Asegurar memcached del servidor, para evitar amplificar ataques DDoS
- Consejos de Seguridad para Pagos Móviles en España: Protege tus Transacciones con Estos Consejos Prácticos
- 22 herramientas de seguridad de servidores Linux de código abierto en 2023
- 8 hábitos que deben tomar los teletrabajadores altamente seguros