¿Cuál es la diferencia entre un solucionador de nombres de dominio y un servidor DNS?
Un nombre de dominio es una URL que apunta a un sitio web (o blog, espacio, etc.), por ejemplo: wmnet/. Los nombres de dominio incluyen nombres de dominio de nivel superior, nombres de dominio de segundo nivel y nombres de dominio de tercer nivel. nombres de dominio de nivel, etc. Después de todo, un nombre de dominio es sólo una cadena; DNS es mucho más complicado. DNS es un sistema de nombres de dominio (DomainNameSystem), que consta de un solucionador de nombres de dominio y un servidor de nombres de dominio. El servidor de nombres de dominio almacena todos los nombres de dominio del host y las direcciones IP correspondientes en la red a la que pertenece y tiene la función de convertir nombres de dominio en direcciones IP. La función del solucionador de nombres de dominio es apuntar el nombre de dominio a la dirección IP del espacio donde se encuentra el sitio web (según esta premisa, si el nombre de dominio está vinculado al servidor del sitio web, la conexión entre el nombre de dominio y el El sitio web está establecido y el sitio web se puede abrir mediante la URL).
上篇: ¿Cómo ver CCTV en la computadora? 下篇: Cómo piratear software Cómo piratear software James A. Whittaker Resumen Este artículo analiza una serie de métodos para descubrir fallas en el diseño y desarrollo de software (los llamados "ataques"). Estos ataques son pruebas exploratorias manuales que se diseñan y ejecutan dinámicamente con poca sobrecarga adicional. Estos ataques se crean estudiando cientos de defectos de software reales y abstrayendo sus causas y fenómenos. Después de dos semestres de análisis detallado, los estudiantes de pruebas de software de Florida Tech identificaron docenas de estrategias de ataque destinadas a encontrar fallas. Estas tácticas resultaron tan útiles que se descubrieron cientos de defectos más en un período de tiempo muy corto, con poco o ningún conocimiento del producto, como resultado directo de estas tácticas. Este artículo presenta un subconjunto de estas estrategias de ataque y explica cómo pueden descubrir fallas reales en los productos lanzados. ¿Qué caracteriza a un buen evaluador? ¿Qué don los hace tan sensibles a las vulnerabilidades? ¿Se puede enseñar esta habilidad? Estas preguntas son el tema de este artículo. Creo que los buenos testers nacen, no se hacen. De hecho, a lo largo de los años, muchos evaluadores parecen haber acumulado un arsenal estándar de estrategias de ataque. De hecho, a lo largo de los años, muchos evaluadores parecen haber acumulado una biblioteca de estrategias de ataque estándar, que reorganizan cada vez que encuentran un problema de prueba difícil para poder encontrar siempre fallas. Aunque estas estrategias de ataque rara vez se documentan, desempeñan un papel importante en las pruebas manuales y la herencia de pruebas. Al estudiar probadores reales y errores reales, comenzamos a documentar esta riqueza. En este artículo exploramos algunos de los resultados de este proyecto. El próximo desafío es automatizar estos ataques y encontrar estrategias específicas para usarlos de manera efectiva. Los ataques se pueden dividir en tres categorías amplias: ? Ataques de entrada/salida ? Cada categoría tiene tipos de ataques específicos que pueden provocar fallos de software muy interesantes. En los siguientes capítulos, utilizaré errores específicos como ejemplos para presentar los tipos de ataques en cada categoría. Todos los errores involucrados provienen de productos de Microsoft. No creo que esto deba verse como un comportamiento anti-Microsoft. El hecho de que Microsoft sea un actor dominante en la industria del software lo convierte en un objetivo natural. Sin embargo, no debemos dar por sentado que los productos de Microsoft tengan más defectos que los de otros proveedores de software. Las tácticas de ataque descritas en este artículo han tenido éxito contra una variedad de productos de software de empresas que se ejecutan en prácticamente cualquier plataforma que se pueda imaginar. Mi experiencia muestra que los desarrolladores crean vulnerabilidades con frecuencia sin importar para qué dominio estén desarrollando aplicaciones, qué sistema operativo estén usando y si publican el código fuente o no. Si son desarrolladores web, el problema es menor, porque los propios programas de red. son propensos a sufrir accidentes. Ataques de entrada/salida Los ataques de entrada/salida son lo que los evaluadores llaman pruebas de "caja negra" porque no se requieren datos internos ni información computacional para respaldar la ejecución de la prueba. De hecho, este es el tipo de prueba más común porque leer el código fuente es tedioso y consume mucho tiempo, y a menudo no sirve de nada a menos que sepas exactamente qué tipo de vulnerabilidad estás buscando (hablaremos de eso en la siguiente sección). dos partes) Qué lagunas jurídicas deberíamos intentar encontrar). Ataque de entrada/salida Ataque de entrada única Forzar la aparición de todos los mensajes de error Forzar la especificación de valores predeterminados Pruebe todos los conjuntos de caracteres disponibles Forzar el cambio del tamaño del área de salida Provocar que el área de visualización se desborde Provocar problemas de actualización de la pantalla Ataque de combinación de entradas Forzar la aparición de resultados no válidos La búsqueda no se puede estropear Combinación de entradas Ataques de secuencia de entradas Forzar la aparición de resultados no válidos Repetir la misma secuencia de entradas muchas veces Ataques de entrada única Estos ataques se dirigen a usuarios que utilizan una única entrada (o una combinación de entradas). Este tipo de ataque estudia el comportamiento del uso de una única entrada (entrada variable). Intentamos encontrar situaciones en las que una sola entrada provocaría que la aplicación fallara mientras la mayoría de los datos funcionaban normalmente. Además de considerar los valores límite, existen muchas otras formas de seleccionar casos de uso de entrada, especialmente si desea encontrar vulnerabilidades que los desarrolladores realmente reconozcan y no simplemente ignoren los requisitos indefinidos. Primero, un consejo que parece simple pero que no es fácil de implementar: asegúrese de que todos los mensajes de error aparezcan una vez. Los errores generalmente no hacen que el programa aborte o finalice correctamente; muchos mensajes de error simplemente obligan al programa a dejar de mostrar el mensaje de error y luego continuar con la siguiente entrada o hasta que expire un temporizador. Sin embargo, también hay mensajes de error que provienen de excepciones lanzadas por el programa y excepciones causadas por la ejecución del controlador de excepciones.