Durante nuestra revisión de seguridad anual, recordé un incidente a principios de este año en el que recibimos una amenaza al servidor web de nuestra organización. Se trataba de una política de la organización y amenazaba con atacar nuestro sitio mediante DDoS. Afortunadamente, no pasó nada malo y resultó ser una amenaza vacía. Sin embargo, notificamos inmediatamente al CIO, CSO y CEO y a nuestro proveedor de alojamiento, quienes aplaudieron nuestra respuesta. Debido a la naturaleza de nuestra organización (en educación), la respuesta preventiva involucró a muchas personas, incluida la coordinación con las autoridades locales.
Aunque nuestra respuesta fue suficiente para una amenaza vacía, me estoy haciendo dar cuenta de la poca planificación de ataques que ha sufrido la aplicación web. Ahora mismo la configuración es:
- Un VPS Linode que no esté detrás del firewall empresarial (hay una larga historia detrás de esto que no vale la pena explicar)
- una base de datos PostgreSQL en el mismo servidor que solo permite conexiones locales
- un servidor Nginx que actualmente estamos siguiendo las mejores prácticas para proteger [1]
- Acceso SSH que estamos migrando a autenticación de certificado
- Un VPS de respaldo que tiene todas las configuraciones de servidor más recientes y solo necesita la última versión del código insertado y la configuración de la base de datos migrada (actualmente se usa como servidor de prueba, pero también se concibe como una opción de georedundancia)
Supongo que mi pregunta probablemente pueda reducirse a ¿qué otros pasos debo seguir para bloquear mi servidor y protegerlo contra DDoS? Nos encantaría utilizarNegocios en la nubecon su protección DDoS, pero no siempre la necesitamos y $200 al mes es un poco caro para la organización. ¿Necesito esto siquiera? ¿Existe alguna solución que permita la protección temporal contra DDoS? Si no, ¿cuál es la mejor manera de mantener la estabilidad durante o después de un ataque? Finalmente, ¿qué registro debería implementarse para que podamos ayudar a las autoridades en caso de que ocurra un ataque?
Respuesta1
¿Qué otros pasos debo seguir para bloquear mi servidor y protegerlo contra DDoS?
- Cortafuegos de cualquier puerto y protocolo que no se utilice. Limite el acceso solo a IP confiables cuando corresponda y sea posible.
- Aplique todos los parches y actualizaciones de seguridad de manera oportuna
- Implementar un monitor de red que pueda alertar sobre ráfagas de actividad sospechosas
200 dólares al mes es un poco caro para la organización. ¿Necesito esto siquiera?
No. No hasta que agregue valor y se convierta en algo imprescindible.
¿Existe alguna solución que permita la protección temporal contra DDoS?
Sí. Pueden implicar una buena inversión de tiempo inicial para solucionar las complicaciones de implementar su servicio DDoS. http://www.blacklotus.net/protect/emergency-ddos-protectiones uno de esos servicios a pedido.
Si no, ¿cuál es la mejor manera de mantener la estabilidad durante o después de un ataque?
Siéntate ahí y tómalo. Esa es la naturaleza de DDoS. Puedes intentar desactivar las IP, pero si el ataque está realmente distribuido... bueno, eso es como combatir un incendio forestal con una pistola de agua.
Finalmente, ¿qué registro debería implementarse para que podamos ayudar a las autoridades en caso de que ocurra un ataque?
Mantenga registros de las IP de origen entrantes y marcas de tiempo y cualquier otro dato forense relevante. Por ejemplo, si se trata de un servidor web, intente registrar el agente de usuario y los recursos solicitados. Las tasas de tráfico, como paquetes por segundo, y el número de solicitudes por segundo son útiles.
DDoS se reduce a un análisis matemático. Si alguien intenta extorsionarlo, está apostando a que puede perturbar su negocio lo suficiente como para obligarlo a pagar dinero de protección para evitarlo. La escala es un factor, es más fácil acabar con los operadores más pequeños, pero pueden pagar menos. Si recibe una amenaza por correo electrónico, lo mejor que puede hacer es ignorarla. Se necesitan importantes recursos de botnets para iniciar y mantener ataques DDoS; no pueden simplemente atacar a todos como spammers. Lo más probable es que simplemente estén realizando una explosión masiva de phishing en busca de objetivos fáciles de intimidar. Debido a la naturaleza de la bestia DDoS, las víctimas están bastante indefensas a menos que puedan implementar un sofisticado esquema de prevención de filtrado de paquetes o tengan el presupuesto para contratar servicios externos.
Respuesta2
La respuesta de inetplomber es genial.
Yo agregaría que otra opción es configurar su aplicación a escala, de modo que pueda manejar un ataque mayor sin afectar a su usuario. Puede configurar una nube privada virtual (VPC) en Amazon AWS, por ejemplo, con su servidor PostgreSQL accesible solo desde dentro de su VPC. Puede configurar una interfaz de equilibrador de carga para distribuir la carga entre varios servidores.
La ventaja de hacerlo de esa manera es que puede escalar rápidamente hasta cientos (o más) de servidores sin inversión inicial y muy rápidamente (si ya estaba configurado), lo que lo convierte en un objetivo mucho más difícil. Sólo tendrías que pagar por esos servidores durante las horas en las que estuvieras bajo ataque. Cuando no estuviera bajo ataque, solo necesitaría pagar por su servidor web y su servidor de base de datos.
La parte difícil sería la configuración, y ciertamente es algo más compleja que su configuración actual. Prepararse para una rápida ampliación requeriría aún más trabajo. Pero si estás buscando algo que puedas hacer para planificar (especialmente si, debido a otros problemas, crees que podrías ser un objetivo en el futuro), eso sería todo.
Respuesta3
¿Qué otros pasos debo seguir para bloquear mi servidor y protegerlo contra DDoS?
Si su aplicación web no es interactiva y solo muestra contenido: use nginx + proxy-cache con un tiempo de caché corto (normalmente de 1 a 5 minutos está bien). esto aumenta mucho el rendimiento y obliga al atacante a asignar más recursos
configurar un firewall restringido que filtre todo lo innecesarioENTRADA Y FUERAconfigurando la Política de ENTRADA/SALIDA/ADELANTE en DROP; asegúrese de registrar cada intento de conexión saliente (excepto el puerto UPD 53 :)
Si no puede restringir SSH a una IP de administración estática, use un puerto alto alternativo como 22222, esto evitará muchos mensajes de "hola mcfyl, alguien ahí adentro".
Además, utilice fail2ban/denyhosts para proteger ssh de ataques de fuerza bruta.
si tiene recursos de administrador: use OSSEC y un WAF liviano (hay naxsi para nginx, liviano y no un PITA como mod_security), pero necesitará que alguien configure y mantenga dichas instalaciones
implementar copias de seguridad y utilizar su servidor de reserva como destino de la copia de seguridad
mantenga actualizado el código de su aplicación web; Si utiliza un proyecto de código abierto, regístrese en su lista de correo de seguridad.
Intente evitar el software que se sabe que tiene muchas vulnerabilidades.
si utiliza admin-login y/o managament-webapps: establezca una autenticación básica para esos inicios de sesión + ssl (el certificado autofirmado está bien).
utilice ssh-tunneling siempre que pueda en lugar de abrir puertos, por ejemplo, para desarrollo
Si no, ¿cuál es la mejor manera de mantener la estabilidad durante o después de un ataque?
- mantenga la calma
- tener a mano a alguien con experiencia para tal caso
- tener algunos planes de emergencia listos
Lo más importante que ya hiciste: pensar en ello (y en las posibles contramedidas) antes de que suceda.