Cualquier persona que ha entrenado conmigo puedo decir que estoy realmente grande en ser capaz de leer su propia detecta. Aunque tenemos un montón de dispositivos de seguridad que tratan de describir con precisión lo que piensan que ven en el cable, que son programados por seres humanos y los seres humanos cometen errores. Trata de automatizar el proceso y los errores se complica. Incluso Cisco ha retrocedido un poco en su afirmación grandiosa de lo que una red de defensa de sí mismo es realmente capaz de hacer. Nada sustituye a tener un analista experto de revisar los hallazgos.

Una buena ayuda es difícil de encontrar

Por supuesto, la palabra clave en ese último comentario es muy hábil. He tratado con un montón de gente de seguridad del grupo, que nunca han visto una decodificación de un paquete IP, y mucho menos puedo decir lo que una sesión IP de fiar debe ser similar. Uno de los problemas es cuando necesitamos el entrenamiento por lo general recurren a los vendedores. Los vendedores tienden a centrarse en su interfaz gráfica de usuario bastante, no lo que está pasando detrás del escenario.

En una vida anterior yo tenía un ISP y había algunos informes de abusos muy entretenido presentado. Uno de mis favoritos fue un informe de administración que uno de mis sistemas era "el envío de paquetes ICMP hostil" a uno de sus sistemas. Al revisar los registros de mi, me di cuenta que uno de mis routers, de hecho enviándole mensajes ICMP de host inalcanzable. Esto ocurre cada vez que su anfitrión sondeó el puerto RPC de una dirección IP que no estaba en uso. Le escribí y le explicó que si su sistema simplemente dejarían de que se comprueben los inexistentes sistemas, el router podría dejar de decirle a él, el anfitrión está fuera de línea.

Otro administrador (en un lugar grande, empresa bien conocida, podría añadir) me informó que uno de mis sistemas lo estaba atacando con Code Red a través de e-mail. Si te acuerdas de Code Red, que sólo atacó a los servidores web IIS a través de HTTP. Los "ataques" en cuestión eran usuarios suscritos a una lista de correo. La gente hablaba de cómo escribir una buena intrusión de firmas para coger correctamente el Código Rojo. Si eso no fuera lo suficientemente irónico, la carga de la decodificación de que él me envió como prueba explicó que los ataques sólo basados ​​en HTTP. Si ese giro no es suficiente para hacerte reír, más tarde admitió que fue una de las personas suscritas a la lista.

El más cambian las cosas más se quedan igual

Mi Monstruo de alojamiento de host del proveedor (una subsidiaria de Blue Host) ha puesto un filtro en su lugar el bloqueo de todos los accesos al Instituto SANS servidor de correo (SysAdmin, Audit, Network, Security Institute, ofrece capacitación en seguridad informática), el Internet Storm Center (registro diario de las amenazas de seguridad en Internet) y DShield (un sistema de alerta temprana para las amenazas de Internet). Me puse en contacto de apoyo y confirmaron que están filtrando estos sitios. No he podido averiguar por qué más allá ", debido a la actividad sospechosa".

Sé que la gente de que mantener la SANS y servidores DShield. Son difíciles de la gente de seguridad central con una pista seria. La primera vez que firmó con mi proveedor de alojamiento me quedé impresionado con el nivel de conocimientos de su personal de apoyo. Sin embargo, últimamente me he encontrado a faltar, incluso en lo básico. Aunque yo me quedo de adivinar lo que realmente provocó la prohibición, me inclino a pensar que alguien en Host Monster (o el alojamiento, posiblemente azul) vio una alerta, pero no tienen las habilidades para resolver sus falsos positivos.

La comunicación es una calle de dos vías

Blue Host reclamaciones 1.500.000 sitios alojados a través de todas sus posesiones. Así que ahora tenemos 1,5 millones de clientes que no pueden:

• Recibe alertas en tiempo real el bloqueo de la IP maliciosa
• Recibe las evaluaciones sobre las amenazas actuales de Internet
• Recibir información sobre lo que está pasando en la industria de la seguridad

Así que al tratar de protegerse a sí mismos es algo positivo, la puesta en práctica ha tenido un efecto negativo en la seguridad de sus clientes.

Cómo comprobar una detección

Así que vamos a sacar algo positivo de todo esto y determinar el procedimiento adecuado para verificar una alerta de seguridad. Primero tenemos que empezar con buen equipo. Ni siquiera considerar un sistema de detección de intrusos o de prevención que no incluye:

• Acceso a la lengua de firma
• Decodificación completa de los paquetes sospechosos

Sin estas características que se filma en la oscuridad.

Paso 1: Entender el ataque

Cuando se desencadena una alerta, asegúrese de que entiende el mecanismo de ataque. ¿Qué puertos o servicios tiene que ir después? ¿Hay algún firmas conocidas? Si buscas en Google el nombre del ataque es seguido por las palabras clave "falsos positivos" y "falso", hace algo salido?

Paso 2: Comprender el sistema de intrusión

Ningún otro producto de seguridad es perfecto. Todos ellos tienen debilidades o limitaciones. ¿Su sistema de intrusión mantener el estado? Si es así, es todo el tiempo o sólo algunas de las veces? ¿Se validan correctamente los campos de la Convención? ¿Cómo lidiar con el tráfico fragmentado? ¿Se sabe para generar falsos positivos? Si es así, son los falsos positivos limita sólo a ciertas firmas o protocolos, o es todo el tiempo?

Paso 3: comprobación de validez de la alerta

A veces, los falsos positivos pueden ser eliminados a partir de la limitada cantidad de información presentada en una alerta. Por ejemplo, hace la afirmación de alerta se ha detectado un ataque HTTP procedente de TCP/80 en vez de ir a ella? Si es así, hay un problema evidente con la firma de la generación de la alerta.

Paso 4: Revise la firma

Algunas firmas se escriben muy específicamente lo que hay pocas posibilidades de un falso positivo. Algunos son más general, sin embargo lo tanto es posible que la caída de falsos positivos a cabo. Revisión de la firma que generó la alerta y hacer un llamado a juicio. ¿La comprobación de firma 3-4 diferentes condiciones o diez o más? Es evidente que los parámetros más estamos comprobando, el menos probable es que para obtener un falso positivo.

Paso 5: Compruebe la decodificación

Si usted entiende el patrón de ataque, ya debe tener una expectativa de lo que será en la decodificación de ataque. ¿Tiene el paquete coincide con sus expectativas? He visto un montón de falsos positivos generados por la gente que lee información en un sitio web que describe un ataque basado en HTTP. Estos son fáciles de distinguir debido a la adicional agente HTML, adecuado y los campos de remitente, etc En resumen, si el paquete no coincide con un conocido de descifrar el verdadero ataque, averiguar por qué.

Paso 6: Investigación de la fuente

Siempre me tomo el tiempo para asegurarme de que entiendo que está sentado detrás de la dirección IP de origen. A veces esto puede ir una manera larga hacia la identificación de si puedo confiar en la alerta. Me acuerdo de un amigo que prohibía una serie de direcciones IP a su sistema de intrusión había identificado como hostil. Poco después comenzó a darse cuenta de que las partes de Internet ya no eran accesibles. Resulta que una persona falsa una serie de ataques de las direcciones IP de los servidores de nombres raíz . Si hubiera tomado el tiempo para buscar las direcciones IP en primer lugar, que ciertamente no hubiera bloqueado.

Resumen ejecutivo

El bloqueo se sabe que las direcciones IP hostil sin duda puede ser beneficioso para la seguridad, pero debe aplicarse con cautela. En el núcleo de cualquier sistema de seguridad de la red debe ser un experto en seguridad con conocimientos de sentido común. Si este componente no está presente, toda la estructura puede derrumbarse como un castillo de naipes.

Actualización: Desde esta publicación he encontrado que el Monstruo de host (Host Blue) está bloqueando el acceso a uno o más de Cisco y servidores. Supongo que la lista sigue ...