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
- ¿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
- Snort para Windows, detección de Intrusos y seguridad.
- 22 herramientas de seguridad de servidores Linux de código abierto en 2023
- 8 hábitos que deben tomar los teletrabajadores altamente seguros
- 7 cosas que incluso los nuevos usuarios de Linux pueden hacer para proteger mejor el sistema operativo
- Recuperar contraseñas de archivos comprimidos en 3 pasos
- Administración: Glances - herramienta de monitoreo y supervisión para Linux
- Cómo monitorear sistemas Linux remotos con Glances
- Los 5 mejores VPN del momento
- Cómo bloquear ataques de fuerza bruta SSH usando SSHGUARD en Linux
- Cómo purgar y limpiar tus discos y borrar archivos en forma segura
- Generar password aletorios en Linux
- LinuxParty 6 meses, estadísticas y crecimiento.