Nombre de dominio ovg

Los ataques de denegación de servicio son una vulnerabilidad del sistema a nivel mundial. Los piratas informáticos están obsesionados con su investigación e innumerables usuarios de la red serán víctimas de este ataque. Tribal Flood Network, TFN2K, Pitufos, Talga... y muchos otros proyectos están en constante desarrollo. Estos programas se extienden como una plaga por la web, debilitando a nuestras aldeas y obligándonos a buscar una solución de seguridad fácil de usar contra ataques en la oscuridad.

Los ataques de denegación de servicio continúan evolucionando a medida que mejoran nuestras defensas. Tribal Flood Network (tfn) y tfn2k introducen un nuevo concepto: distribuido. Estos programas permiten que máquinas dispersas por Internet ataquen un host simultáneamente, haciendo que parezca que el host está siendo atacado por múltiples hosts en diferentes ubicaciones. Estas máquinas dispersas son operadas por varias computadoras maestras e implementan varios tipos de ataques, como inundación UDP, inundación SYN, etc.

Los piratas informáticos descubren y explotan constantemente fallas en los sistemas operativos y equipos de red para llevar a cabo ataques maliciosos. Si esto lo tenemos claro, deberíamos seguir los dos pasos siguientes para intentar prevenir ciberataques y proteger nuestras redes: Corregir los problemas identificados y las vulnerabilidades del sistema siempre que sea posible.

Identificar, rastrear o desactivar el acceso a nosotros de estas molestas máquinas o redes.

Centrémonos primero en el segundo punto. El principal problema al que nos enfrentamos es cómo identificar esos hosts maliciosos, especialmente aquellos que utilizan ataques de denegación de servicio. Porque estas máquinas ocultan sus propias direcciones y utilizan la dirección de la persona atacada. El atacante utilizó miles de paquetes falsificados con fines maliciosos para atacar nuestros hosts. El principio de "tfn2k" es tan simple como se mencionó anteriormente, solo proporciona una interfaz gráfica. Si es atacado por una denegación de servicio distribuida, es realmente difícil de manejar.

Existen algunas técnicas sencillas para prevenir ataques de denegación de servicio. Eso sí, lo más común es siempre prestar atención a la información de seguridad y esperar que aparezca el mejor método. Los administradores deben suscribirse a informes de información de seguridad y monitorear el desarrollo de todos los problemas de seguridad en tiempo real. :) El segundo paso es aplicar tecnología de filtrado de paquetes, principalmente filtrado de puertos abiertos al mundo exterior. Estas medidas tienen como objetivo principal prevenir ataques de direcciones falsas para que las máquinas externas no puedan falsificar las direcciones de las máquinas internas para lanzar ataques a las máquinas internas.

Ha habido controversia sobre si se debe utilizar el filtrado de paquetes entrantes o el filtrado de paquetes salientes. RFC 2267 recomienda utilizar un mecanismo de filtrado interno en Internet global, pero puede causar muchos problemas. El uso de listas de control de acceso en enrutadores de nivel medio no causará muchos problemas, pero los enrutadores troncales que ya están completamente cargados corren un claro riesgo. Por otro lado, si el ISP utiliza filtrado de paquetes salientes, desviará el tráfico sobrecargado a algunos dispositivos menos ocupados. A los ISP tampoco les importa si los consumidores utilizan esta tecnología en sus enrutadores fronterizos. Por supuesto, esta técnica de filtrado no es infalible, dependiendo del mecanismo de filtrado utilizado por el administrador.

1.Medidas de protección ICMP

ICMP se desarrolló originalmente para "ayudar" a las redes y los administradores de WAN suelen utilizarlo como herramienta de diagnóstico. Hoy en día, sin embargo, se abusa de varias versiones inadecuadas de ICMP y no cumplen con los estándares establecidos originalmente en RFC 792. Es necesario implementar ciertas estrategias para hacerlo más seguro.

Se responderá a los paquetes entrantes de solicitud de información y marca de tiempo ICMP, y los paquetes falsificados con parámetros ilegales o incorrectos también generarán paquetes con problemas de parámetros ICMP, lo que permitirá otra forma de descubrimiento de host. Esto todavía deja el sitio desprotegido.

Una forma común de emitir comandos en secreto desde un host a un cliente es utilizar un paquete de respuesta de eco ICMP como portador. La respuesta de eco en sí no puede ser respondida y generalmente no está bloqueada por firewalls.

Primero, tenemos que abordar todo el tema de la "limitación ICMP" en términos de salida y entrada. El eco ICMP puede autenticar fácilmente máquinas remotas, pero el eco ICMP saliente debe limitarse a personas individuales o a un único servidor/proxy ICMP (preferido).

Si restringimos los ecos ICMP a direcciones IP externas (a través de un proxy), nuestras respuestas de eco ICMP solo pueden ir a hosts predefinidos en nuestra red.

Las redirecciones generalmente ocurren entre enrutadores, no entre hosts. Las reglas del firewall deben ajustarse para que estos tipos de ICMP solo se permitan entre enrutadores involucrados en la conexión a Internet que requiere la información.

Se recomienda que todas las transferencias externas pasen por el proxy y las transferencias ICMP internas pasen por el firewall al devolver la dirección del proxy. Esto al menos limitará los paquetes de tiempo de espera ICMP a direcciones internas, pero puede evitar que se agoten los paquetes.

Cuando el Protocolo de mensajes de control de Internet se envía con parámetros incorrectos, el paquete se descarta y se envía un paquete de error de parámetro ICMP. El host o enrutador descarta el paquete enviado y envía un paquete de error ICMP de parámetro al remitente indicando el parámetro incorrecto.

En términos generales, sólo los servidores con direcciones públicas (como servidores web, de correo electrónico y FTP), firewalls y enrutadores conectados a Internet tienen una razón real para usar ICMP para comunicarse con el mundo exterior. . Si se ajusta correctamente, se suspenderán casi todos los canales de comunicación encubiertos que utilizan ICMP entrante y saliente.

2. Prevención de inundaciones sincrónicas

SYN Flood es uno de los métodos más populares de DoS (ataque de denegación de servicio) y DdoS (ataque de denegación de servicio distribuido). que utiliza el protocolo TCP La falla es un método de ataque que envía una gran cantidad de solicitudes de conexión TCP falsificadas, lo que hace que la parte atacada agote los recursos (la CPU está llena o la memoria es insuficiente). Actualmente no existen buenos métodos de monitoreo y defensa para los ataques SYN Flood, pero si el administrador del sistema está familiarizado con los métodos de ataque y la arquitectura del sistema, a través de una serie de configuraciones, la carga del sistema atacado se puede reducir hasta cierto punto y la el impacto negativo puede mitigarse.

En términos generales, si la carga de un sistema (o host) aumenta repentinamente o incluso deja de responder, puede ver una gran cantidad de medias conexiones SYN_RCVD (número > 500 o más de 65438 00 del total). número de conexiones), se puede concluir que este sistema (o host) está sujeto a un ataque SYN Flood. Después de ser atacado por SYN Flood, lo primero que debe hacer es recopilar evidencia. Pass Netstat -n -p tcp > Resault.txt es necesario para registrar el estado actual de todas las conexiones tcp. Si tiene un rastreador o una herramienta como TcpDump, registrar todos los detalles del mensaje TCP SYN también ayudará con el seguimiento y la defensa en el futuro. Los campos que deben registrarse incluyen: dirección de origen, identificador en el encabezado IP, número de secuencia en el encabezado TCP, valor TTL, etc. Aunque es probable que el atacante falsifique esta información, también es útil para analizar el estado psicológico del atacante y los procedimientos de ataque. Especialmente el valor TTL Si una gran cantidad de paquetes de ataque parecen provenir de diferentes IP pero tienen el mismo valor TTL, a menudo podemos inferir la distancia del enrutador entre el atacante y nosotros, o al menos mitigar el ataque al sistema filtrando mensajes. con valores TTL específicos (en este caso, los usuarios con valores TTL diferentes del paquete de ataque pueden reanudar el acceso normal). Desde una perspectiva de defensa, existen varias soluciones simples:

2.1 Acortar el tiempo de espera de SYN: debido a que el efecto de un ataque de inundación SYN depende del número de medias conexiones SYN mantenidas en el servidor, este valor = SYN El Frecuencia de ataques Duplicar la carga en el servidor.

2.2 Establecer Cookie SYN: asigna una cookie a cada dirección IP que solicita una conexión. Si se reciben mensajes SYN repetidos desde una IP en un corto período de tiempo, se considera un ataque y los paquetes de datos de esta dirección IP se descartarán en el futuro. Sin embargo, los dos métodos anteriores solo pueden lidiar con ataques SYN Flood primitivos. Acortar el tiempo de espera SYN solo tendrá efecto cuando la frecuencia de los ataques del oponente no sea alta.

La cookie SYN depende más de la dirección IP real utilizada por la otra parte. Si un atacante envía mensajes SYN a una velocidad de decenas de miles por segundo y reescribe aleatoriamente la dirección de origen en el mensaje IP a través de SOCK_RAW, todos los métodos anteriores serán ineficaces.

2.3 Estrategia de retroalimentación negativa: consulte algunos sistemas operativos populares, como el mecanismo de protección contra ataques SYN de Windows 2000. En circunstancias normales, el sistema operativo tiene una configuración regular para algunos parámetros importantes de la conexión TCP: tiempo de espera de SYN, número de reintentos de SYN-ACK, retraso de los mensajes SYN desde el enrutador al sistema y a Winsock, etc. Esta configuración general tiene como objetivo la optimización del sistema y puede proporcionar a los usuarios servicios convenientes y rápidos una vez que el servidor es atacado y la cantidad de semienlaces SYN excede el límite superior de la cantidad de semienlaces TCP activos en el sistema, el sistema lo considerará; si está bajo un ataque SYN Flood, responderá según el juicio del ataque, como acortar el tiempo de espera SYN, reducir la cantidad de reintentos SYN-ACK, retrasar automáticamente los mensajes en el búfer, etc. , para minimizar el daño del ataque. Si el ataque continúa y excede el valor máximo de media conexión permitido por el sistema, el sistema ya no podrá proporcionar servicios normales. Para garantizar que el sistema no falle, cualquier mensaje SYN que exceda el valor máximo de media conexión se puede descartar aleatoriamente para garantizar la estabilidad del sistema.

Por lo tanto, podemos probar o predecir el límite superior de la cantidad de actividades del host durante el período pico de antemano, y usarlo como referencia para establecer el valor de la cantidad máxima de TCP activo a la mitad. -conexiones, y luego tome un múltiplo de este valor (que no exceda 2) como el valor máximo de semiconexión TCP, de modo que los ataques SYN se puedan prevenir hasta cierto punto mediante retroalimentación negativa.

2.4 Estrategia de concesión: La estrategia de concesión se basa en la vulnerabilidad del código de ataque SYN Flood. Analicemos el proceso del atacante SYN Flood: el programa SYN Flood tiene dos métodos de ataque, basado en IP y basado en dominio. En el primero, el atacante resuelve él mismo el nombre de dominio y le pasa la dirección IP. En el segundo, el atacante resuelve automáticamente el nombre de dominio, pero son los mismos. Es decir, una vez que comienza el ataque, la resolución del nombre de dominio no continuará. Este es también nuestro punto de ruptura: suponiendo que un servidor cambia rápidamente su dirección IP después de ser atacado por SYN Flood, entonces el atacante todavía está atacando una dirección IP vacía. sin ningún host. Al cambiar la resolución DNS a una nueva dirección IP, el acceso normal del usuario a través del nombre de dominio se puede restaurar en poco tiempo (dependiendo del tiempo de actualización del DNS). Para confundir al atacante, podemos incluso poner un servidor "sacrificial" para que el atacante esté satisfecho con el "efecto" del ataque (debido al almacenamiento en búfer DNS, mientras el navegador del atacante no se reinicie, seguirá accediendo al dirección IP original).

2.5 Equilibrio de carga de DNS distribuido: entre muchas arquitecturas de equilibrio de carga, el equilibrio de carga basado en la resolución de DNS en sí tiene inmunidad a SYN Flood. El equilibrio de carga basado en la resolución DNS puede distribuir las solicitudes de los usuarios a hosts de servidores con diferentes IP. El atacante siempre atacará solo a uno de los servidores, lo que aumentará los costos del atacante. En segundo lugar, las solicitudes de DNS excesivas pueden ayudarnos a rastrear los rastros reales del atacante (las solicitudes de DNS son diferentes de los ataques SYN y es difícil falsificar la IP).

2.6 Qos del firewall: para los firewalls, el método de defensa contra ataques SYN Flood depende de los principios básicos del firewall. En términos generales, los firewalls pueden funcionar por encima de la capa TCP o por debajo de la capa IP. Los firewalls que funcionan por encima de la capa TCP se denominan firewalls de puerta de enlace. En el diseño de un firewall de puerta de enlace, no existe una conexión TCP real entre el cliente y el servidor. Todo el intercambio de datos entre el cliente y el servidor se produce a través del proxy del firewall, y la resolución DNS externa también apunta al firewall. Entonces, el sitio web fue atacado y el firewall fue realmente atacado. Las ventajas de este tipo de firewall son una buena estabilidad y una fuerte resistencia a los ataques. Sin embargo, debido a que todos los mensajes TCP deben reenviarse a través del firewall, la eficiencia es relativamente baja.

Dado que el cliente no establece una conexión directa con el servidor, cuando la conexión TCP no se completa, el firewall no establecerá una nueva conexión TCP con el servidor backend, por lo que el atacante no puede atacar directamente al servidor backend a través del firewall. Siempre que el firewall sea lo suficientemente fuerte, esta arquitectura puede resistir ataques SYN Flood bastante fuertes. Sin embargo, dado que la cantidad de conexiones TCP realmente establecidas por el firewall es el doble de la cantidad de conexiones de usuario (ambos extremos del firewall deben establecer conexiones TCP), también representa todas las solicitudes TCP y transmisiones de datos del cliente. Cuando el sistema tiene mucho acceso, la carga en el firewall será mayor, por lo que esta arquitectura no es adecuada para sitios web grandes. (Creo que para una arquitectura de firewall de este tipo, usar ataques TCP_STATE será bastante efectivo :)

Trabajar en la capa IP o debajo de ella se llama firewall de enrutamiento. El principio de funcionamiento es diferente: el cliente se comunica directamente con ella. la capa IP a través de TCP El servidor se conecta y el firewall actúa como enrutador. Intercepta todos los paquetes de datos que pasan y los filtra. Los paquetes de datos filtrados se reenvían al servidor y la resolución DNS externa también se dirige al servidor. La ventaja de este tipo de firewall es su alta eficiencia. Puede adaptarse a tráfico de 100Mbps-1Gbps. Sin embargo, si el firewall no está configurado correctamente, no sólo permitirá a los atacantes atacar directamente los servidores internos a través del firewall, sino que incluso puede amplificar la intensidad del ataque, provocando que todo el sistema colapse.

Además de estos dos modelos básicos, existe un nuevo modelo de firewall que integra las ventajas de ambos firewalls. El principio de funcionamiento del firewall es el siguiente:

En la primera fase, el cliente solicita establecer una conexión con el firewall:

En la segunda fase, el firewall se disfraza de un cliente y establece una conexión con el servidor en segundo plano.

En la tercera fase, después de esto, todos los paquetes TCP del cliente se reenvían directamente al servidor en segundo plano.

Esta estructura absorbe las ventajas de los dos firewalls anteriores y puede controlar completamente todos los mensajes SYN sin proxy de todos los mensajes de datos TCP. Esta es una forma de matar dos pájaros de un tiro. Recientemente, algunos fabricantes de firewalls nacionales y extranjeros han comenzado a estudiar la tecnología de control de ancho de banda. Si el ancho de banda se puede controlar y asignar estrictamente, la mayoría de los ataques SYN se pueden defender en gran medida.

3. Varias formas de prevenir 3. (jerga de Internet) trompeta; abre una trompeta

Bloquear la fuente de los ataques de los Pitufos: los ataques de los Pitufos dependen del poder del atacante para enviar solicitudes de eco con direcciones de origen engañosas. Los usuarios pueden evitar este ataque utilizando el acceso enrutado para garantizar que todas las transmisiones enviadas dentro de la red interna tengan direcciones de origen legítimas. Esto evita que los grupos estafadores encuentren sitios de rebote.

Bloquear sitios web de rebote de ataques de los Pitufos: los usuarios tienen dos opciones para bloquear sitios web de rebote de ataques de los Pitufos. El primer método consiste simplemente en bloquear todas las solicitudes de eco entrantes, lo que evita que estos paquetes lleguen a su propia red. Si no puede bloquear todas las solicitudes de eco entrantes, deberá hacer que su enrutador asigne la dirección de transmisión de la red a la dirección de transmisión de la LAN. Detenga este proceso de mapeo y su sistema ya no recibirá estas solicitudes de eco.

Bloquear la plataforma pitufa: para evitar que el sistema se convierta en una plataforma para ataques pitufos, se debe desactivar la función de transmisión IP en todos los enrutadores. En términos generales, no se requiere la funcionalidad de transmisión IP. Si un atacante quiere explotarlo con éxito como plataforma de ataque, su enrutador debe permitir que los paquetes abandonen la red con una dirección de origen no generada desde su intranet. El enrutador se puede configurar para filtrar paquetes que no se generan dentro de su intranet. Esto se denomina filtrado de salida de la red.

Evite que Smurf ataque sitios de destino: a menos que el ISP del usuario esté dispuesto a ayudar, es difícil para los usuarios evitar que Smurf afecte sus conexiones WAN. Aunque los usuarios pueden bloquear esta transmisión en su propio equipo de red, ya es demasiado tarde para evitar que Smurf se coma todo el ancho de banda de la WAN. Pero al menos los usuarios pueden limitar el impacto de Smurf en los periféricos. Al utilizar tecnología de filtrado dinámico de paquetes o un firewall, los usuarios pueden evitar que estos paquetes ingresen a su red.

En la tabla de estado del firewall queda claro que estas sesiones de ataque no se originaron en la red local (no hay ningún registro de la solicitud de eco inicial en el registro de la tabla de estado), por lo que descarta esta información como cualquier otro ataque falsificado.

Prevención de inundaciones 4.UDP

Tome el trinoo mencionado anteriormente como ejemplo, el análisis es el siguiente:

En todas las comunicaciones entre el programa principal y el programa agente, trinoo Utilice el protocolo UDP. El software de detección de intrusiones puede utilizar el protocolo UDP (tipo 17) para encontrar flujos de datos.

El puerto de escucha del programa principal de Trinoo es 27655. Los atacantes suelen conectarse al ordenador donde se encuentra el programa principal a través de telnet y TCP. El software de detección de intrusos puede buscar el flujo de datos utilizando TCP (tipo 6) y conectarse al puerto 27655.

Todas las comunicaciones del programa principal al agente contienen la cadena "l44" y se dirigen al puerto UDP 27444 del agente. El software de detección de intrusos comprueba las conexiones al puerto UDP 27444. Si envía un paquete que contiene la cadena l44, la computadora que recibe el paquete probablemente sea un agente DDoS.

La comunicación entre agentes maestros está protegida con contraseña, pero la contraseña no se envía en formato cifrado y, por lo tanto, puede rastrearse y detectarse. Usando esta contraseña y el script trinot proporcionado por Dave Dittrich, primero debe enviar una solicitud DNS para resolver el nombre de dominio. Por lo general, esas herramientas de ataque realizarán este paso por sí mismas, llamando a la función gethostbyname() o a la interfaz de programación de aplicaciones correspondiente. Es decir, una solicitud de DNS previa al ataque nos proporcionará una lista relevante que podremos utilizar para localizar al atacante.

Es posible leer la lista de solicitudes sospechosas de DNS utilizando herramientas disponibles en el mercado o leyendo manualmente los registros de solicitudes de DNS. Sin embargo, tiene tres desventajas principales:

Los atacantes suelen utilizar el DNS local como punto de partida para analizar y consultar direcciones, por lo que el iniciador de la solicitud de DNS que encontramos puede no ser el propio atacante, sino el DNS local. Solicitó servidor. Sin embargo, si el atacante se esconde en una organización que tiene un DNS local, podemos utilizar esa organización como punto de partida para las consultas.

Es posible que el atacante ya conozca la dirección IP del objetivo, o que la conozca a través de otros métodos (host, ping), o que el atacante tarde mucho tiempo en iniciar el ataque después de consultar la IP. dirección, por lo que no podemos distinguir al atacante (o a su servidor local) del período de tiempo de las solicitudes de DNS.

El DNS mantiene una vida útil para diferentes nombres de dominio, por lo que un atacante puede utilizar la información almacenada en la caché de DNS para resolver nombres de dominio. Para realizar un registro de análisis detallado, se puede acortar el tiempo TTL ahorrado por DNS, pero esto provocará más consultas de DNS y, por tanto, aumentará el uso del ancho de banda de la red.

6. Prevención de hosts

Todos los hosts que proporcionen servicios públicos a Internet deben estar restringidos. Las siguientes estrategias recomendadas pueden proteger los hosts expuestos a Internet.

Aislar todos los servidores públicos de la cuarentena.

Cada servicio prestado debe disponer de su propio servidor.

Si usa Linux (recomendado), puede evitar la mayoría (si no todos) los desbordamientos de búfer locales o remotos utilizando uno o más parches o mejoras de "desbordamiento de búfer/ejecución de pila" para evitar que estos derrames pongan en peligro las raíces. Se recomienda encarecidamente incluir los parches de Solar Designer como funciones de seguridad adicionales.

Utilice SRP (Contraseña remota segura) en lugar de SSH.

Restringir el acceso a demonios telnet y FTP compatibles con SRP a direcciones internas y enfatizar que sólo los clientes compatibles con SRP pueden comunicarse con estos programas. Si debe ejecutar FTP normal para acceso público (como FTP anónimo), puede ejecutar SRP FTP en otro puerto.

Utilice una ruta confiable. El directorio donde debe ubicarse el programa ejecutable binario propiedad del usuario root debe ser propiedad del root y ningún usuario o grupo debe tener permisos de escritura.

Si es necesario, puedes cambiar el kernel para forzar esto.

Utilice la funcionalidad de firewall incorporada. Generalmente puedes aprovechar la tabla de estado del kernel activando las reglas del firewall.

Utilice algunas medidas de escaneo anti-puertos. Esto se puede lograr utilizando la funcionalidad demonio de Linux o modificando el kernel.

Utilice Tripwire y software equivalente para ayudar a detectar cambios en archivos importantes.

7. Protección contra bombas de correo electrónico

Para proteger la seguridad de los componentes electrónicos, es necesario comprender el proceso de envío de correo electrónico. El proceso es el siguiente: cuando un usuario escribe un correo electrónico, primero se conecta al servidor de correo electrónico. Cuando el servidor de correo responda, iniciará la herramienta de correo y llamará al programa de enrutamiento Sendmail para enrutar el correo. Según el host receptor especificado en la dirección de recepción adjunta al correo electrónico, como 163.net en a@163.net, se establece una conexión TCP del puerto 25 con el demonio de correo ubicado en el host 163.net. las dos partes interactúan según el protocolo SMTP. Esto completa la entrega del correo electrónico. Después de recibir el correo electrónico, el correo electrónico del destinatario se colocará en el directorio de correo del sistema de acuerdo con el nombre del usuario receptor, como el archivo semxa en el directorio /usr/e-mail. Los usuarios receptores también utilizan herramientas de correo para recuperar y leer estos correos electrónicos enviados. Si la entrega falla, estos mensajes se devuelven nuevamente al remitente. De hecho, el proceso de envío de correos electrónicos es mucho más complicado de lo que se dice aquí, y en el proceso intervienen muchos archivos de configuración. Actualmente, el protocolo SMTP es un protocolo basado en texto que es relativamente sencillo de entender e implementar. Puede utilizar telnet para iniciar sesión directamente en el puerto 25 del servidor de correo (LANA está asignada al protocolo SMTP) para interactuar.

La forma más eficaz de proteger la seguridad de la información del correo electrónico es utilizar tecnología de firma criptográfica, como PGP, para verificar los correos electrónicos, que puede proteger la información para que no se envíe desde el lugar correcto y no se modifique durante el proceso. transmisión. Pero esto no es algo que los usuarios individuales puedan hacer porque PGP es más complicado.

En lo que respecta a las bombas postales, todavía se puede proteger bien. Porque no es muy complejo, es sólo spam. Puedes protegerte usando el helicóptero de correo /hacking/echom201.zip. Pero actualmente, en lo que respecta a los usuarios domésticos, la mayoría de los usuarios utilizan buzones de correo gratuitos, como yeh.net, 163.net, 063.net, etc. Incluso si alguien los destruye, permanecen en el servidor de correo y son básicamente inofensivos. Si se conecta a través de pop3, puede utilizar herramientas de recepción de pop como Outlook o Foxmail para recibir correos electrónicos. La mayoría de los usuarios utilizan Outlook Express para Windows y puede configurar el filtrado en Herramientas-Asistente de la Bandeja de entrada. Puede utilizar un software antivirus de correo electrónico para protegerse contra varios gusanos de correo electrónico transmitidos por correo electrónico y gusanos de correo electrónico desconocidos.

Además, los administradores del sistema de correo pueden utilizar la "lista negra" para filtrar parte del spam. Para diferentes sistemas de correo electrónico, la mayoría de los últimos programas o listas de listas negras se pueden encontrar en línea.

8. Utilice la herramienta ngrep para hacer frente a los ataques tfn2k.

Basado en el principio de utilizar DNS para rastrear el programa residente tfn2k, apareció un programa de utilidad llamado ngrep. El ngrep modificado puede monitorear alrededor de cinco tipos de ataques de denegación de servicio tfn2k (Targa 3, Synflood, UDP Flood, ICMP Flood y smurf), y también tiene un caché reciclable para registrar solicitudes DNS e ICMP. Si ngrep detecta un ataque, imprimirá el contenido de su caché y continuará registrando las solicitudes de respuesta ICMP. Si un atacante hace ping al objetivo haciendo ping al host de destino, registrar las solicitudes de respuesta ICMP durante o después del ataque es una forma de atrapar a un atacante desprevenido. Dado que es probable que los atacantes utilicen otros servicios para verificar los efectos de sus ataques (como la web), también deben mantener registros detallados de otros servicios estándar.

También cabe señalar que ngrep utiliza un medio para monitorear la red, por lo que ngrep no se puede usar en un entorno conmutado.

Sin embargo, el ngrep modificado no tiene que estar en el mismo segmento de red que su DNS, pero debe estar en una ubicación donde se puedan monitorear todas las solicitudes de DNS. Al ngrep modificado tampoco le importa la dirección de destino. Puede colocarlo en un segmento DMZ para que pueda verificar toda la red en busca de ataques tfn2k. En teoría, también puede detectar muy bien ataques externos tfn2k.

En un evento de inundación ICMP, los paquetes ICMP que forman parte de la inundación tfn2k no se incluirán en el informe de la solicitud de respuesta ICMP. Ngrep también puede informar los tipos de ataques detectados (TARGA, UDP, SYN, ICMP, etc.) además de Smurf. De forma predeterminada, un ataque híbrido se comporta como un ataque ICMP, a menos que bloquee las solicitudes de respuesta ICMP entrantes, en cuyo caso se comporta como un ataque UDP o SYN. Los resultados de estos ataques son esencialmente similares.

9. Recomendaciones para los sistemas de detección de intrusiones

Dado que muchos de los métodos utilizados para derrotar a los sistemas de detección de intrusiones basados ​​en red siguen siendo válidos para la mayoría de los productos de sistemas de detección de intrusiones comerciales, se recomienda que Sistemas de detección de intrusiones El sistema debe tener al menos paquetes con dirección propia capaces de reensamblarse o encontrar fragmentos. Aquí hay algunas cosas a tener en cuenta:

Asegúrese de incluir todas las reglas existentes, incluidas algunas reglas nuevas para ataques distribuidos de denegación de servicio.

Si sigue las recomendaciones de ICMP, muchos ICMP se bloquearán y existen muchas oportunidades para que se active el sistema de detección de intrusos. Se activará cualquier protocolo ICMP de mensajes de control de Internet entrante o saliente que normalmente esté bloqueado.

"Cualquier" tráfico de red que esté bloqueado por un firewall puede ser un posible desencadenante de IDS.

Si su sistema de detección de intrusiones admite la detección de ataques persistentes, asegúrese de no excluir hosts confiables para que no puedan atravesar el firewall. Esto también incluye las redes privadas virtuales.

Si se pudiera entrenar a cada usuario de ping para que use paquetes pequeños al hacer ping a un host, sería posible construir un sistema de detección de intrusiones que detectaría paquetes de eco y respuesta de eco de más de 29 bytes.

Contenido de esta página

Objetivos

Áreas de aplicación

Cómo utilizar este módulo

Resumen

Conocimientos básicos

Resistir ataques SYN

Resistir ataques ICMP

Resistir ataques SNMP

AFD. Protección del sistema

Otra protección

Desventajas

Otros recursos

Objetivos

Con este módulo, puede lograr :

Reforzar la seguridad de la pila de protocolos TCP/IP del servidor

Proteger el servidor de denegación de servicio y otros ataques basados ​​en la red.

Habilite la protección contra ataques de inundación SYN cuando se detecte un ataque.

Establezca umbrales para identificar los componentes del ataque.

Volver al principio

Áreas de aplicación

Este módulo es aplicable a los siguientes productos y tecnologías:

Microsoft Windows 2000 Server y Windows 2000 Advanced Server

Volver al principio

Cómo utilizar este módulo

Es posible que algunas claves y valores de registro en este módulo no existan de forma predeterminada. En estos casos, se crean estas claves de registro, valores y datos numéricos.

Para obtener más información sobre el registro de configuración de red TCP/IP controlada por Windows 2000, consulte el documento técnico "Detalles de implementación de TCP/IP de Microsoft Windows 2000" en /technet/treeview/default.asp? URL =/TechNet/it Solutions/network/deploy/depovg/tcpip 2k .ASP(inglés)

Nota: Esta configuración modificará la forma en que funciona TCP/IP en el servidor.

Las características del servidor web determinarán el umbral óptimo para activar contramedidas de denegación de servicio. Algunos valores pueden ser demasiado estrictos para las conexiones de clientes. Pruebe las recomendaciones de este módulo antes de implementarlas en un servidor de producción.

Volver al principio

Resumen

La pila TCP/IP es responsable de procesar los paquetes IP entrantes y salientes y de enrutar los datos de los paquetes a la aplicación. que los manejará. De forma predeterminada, TCP/IP es un protocolo inherentemente inseguro. ¿Pero qué pasa con Microsoft? ¿Windows? La versión 2000 le permite configurar su funcionamiento para defenderse de la mayoría de los ataques de denegación de servicio a nivel de red.

Este módulo explica cómo mejorar la seguridad de la pila de protocolos TCP/IP y cómo configurar varios parámetros TCP/IP en el registro de Windows para proteger el servidor de ataques de denegación de servicio a nivel de red, incluido SYS. ataques de inundación, ataques ICMP y ataques SNMP.

Volver al principio

Conceptos básicos

Se pueden configurar varios parámetros TCP/IP en el registro de Windows para proteger el servidor contra la denegación de acceso a nivel de red. ataques a servicios, incluidos ataques de inundación SYS, ataques ICMP y ataques SNMP. Puede configurar la clave de registro para:

Habilitar el mecanismo de protección contra ataques de inundación SYN cuando se detecta un ataque.

Establece el umbral de confirmación de que constituye un ataque.

Esta es una introducción a cómo ser administrador