El Mon, 07 Jun 2010 22:32:52 +0200, Carlos E. R. escribió:
El 2010-06-05 a las 09:06 -0000, Camaleón escribió:
"Mira la respuesta de jose maria, es exactamente lo que vengo diciendo."
Por lo que estabas dando validez, desde tu punto de vista, a sus palabras :-)
Claro, es la respuesta adecuada.
Que no es para un ataque ddos o dos.
¿Ahora dices que "mod_evasive" no es para un ataque ddos/dos? Pues entonces relee el primer correo que envió porque eso es precisamente lo que sugería >:-)
Para eso eres el administrador y tienes que revisar los registros, de la misma forma que tienes que revisar los registros cuando te atacan el servicio pop3. No sabes si es un usuario que conecta a cada minuto (por ejemplo, debido a una mala configuración de su cliente de correo) o si se trata de una IP que viene de China. Hay que mirar los registros, siempre. Si dejas que la aplicación rechace las conexiones automáticamente podrías bloquear a usuarios válidos, como a un jefe despistado que deja su PDA comprobando correos cada minuto >:-)
Eso sería lo que se vería en el log, que la aplicación automática no está trabajando bien, y se ajustaría, se bsucaría otra, o se reconfiguraría la pda.
Y por eso es "necesario" revisar los registros antes de tomar alguna contra-medida. No puedes cerrar el tráfico legítimo porque entonces es peor el remedio que la enfermedad.
Además, la denegación puede ser válida, eso no lo sabe Cyrus. Y Cyrus no puede tomar esa decisión, no le corresponde. Por eso, ante este tipo de ataques (dos/ddos)
Insisto en que yo no estoy hablando de los dos/ddos.
¿Ah, no? ¿Y de qué estamos hablando, entonces?
Es lo que hay en realidad, los ataques bien realizados ddos (distribuidos, que golpean desde distintas fuentes) no son los que ven habitualmente (salvo que trabajes para alguna agencia gubernamental o para sitios como facebook, twitter o google).
Insisto en que yo no estoy hablando de los dos/ddos.
Estoy hablando de los ataques que buscan, lentamente, una vulnerabilidad en tu sistema, el apache en este caso.
¡Ahí va la osa! ¿Ahora ya volvemos al "ataque lento" que decías (no mucho ha) que eso "no era lo que le estaba pasando al OP"? >>>:-)
Te estoy diciendo que SÉ las direcciones IP que tengo que bloquear en el cortafuegos, la veo en los registros. Y como es un ataque "lento", pues me da tiempo hasta para tomarme un café >>:-)
Las sabes por otro sistema. No tienes un sistema automático que detecte el ataque y cambie automáticamente las IPs a bloquear mediante iptables
- y de eso es de lo que se trata.
Ni falta que hace. Si es un "ataque lento" y previsible, con que configures iptables para rechazar las conexiones de un bloque completo de la red de origen, te dejan en paz en un día completo. Es más, seguramente vuelvan a la carga al día siguiente desde la misma red, que ya tienes bloqueada.
No me digas que estás bloqueando las IPs en el cortafuegos, porque esa no es toda la verdad. Estás bloqueando una serie de IPs que ya conoces en el cortafuegos, que es distinto.
Pues ya me dirás qué diferencia ves tú entre esas dos afirmaciones :-)
Pues que no lo estás haciendo automáticamente... estás haciendo una defensa en dos fases:
- detectar el ataque manualmente desde IPs definidas (pocas). 2) bloquear esas IPs manualmente en el cortafuegos.
Tú das como solución la 2, sin mencionar que estás antes haciendo la 1.
Porque para quien está administrando un servidor web o un servidor de correo el paso 1) es "obvio". Se da por hecho. Lo primero que hay que hacer para determinar, no sólo que te están atacando sino el tipo de ataque, es revisar los logs.
Eso puede funcionar, pero no es perfecto, dista mucho. Hace falta sistemas automatizados que consigan eso sin intervención del administrador.
Y se supone que el modulo ese del apache se puede usar en esa configuración automática.
Y las reglas de iptables, también. Y si tienes sistemas avanzados de IPS, también. Que yo no lo haga no significa que no sea posible hacerlo (esos ataques "lentos" al servidor web no suponen ninguna molestia, ya te digo que el amavisd-new se lleva más carga de trabajo que los script-kiddies o las redes de bots). Lo más habitual (por económico y efectivo) sería disponer de un cortafuegos tipo "appliance" (solución de hardware dedicada) entre el router y la zona dmz (o el servidor expuesto) o un equipo con alguna distribución de linux o bsd haciendo las veces de cortafuegos y filtrando, rechazando y gestionado las peticiones de acceso hacia el servidor web. Lo tengo en la lista de "To-Do" O:-)
Sabes perfectamente que hay cortafuegos que sí son capaces de añadir automáticamente las direcciones IP a su lista negra cuando se reciben ataques sencillos dos (de denegación de servicio) o que sencillamente tienen reglas activadas para evitar escaneos externos.
Ataques DoS, sí. Ataques de buscar vulnerabilidades en el apache, automáticamente? O de probar un user/pass por minuto en el pop3? No. O no se ha contado.
Sí, hombre, pues claro que sí :-) Sin ir más lejos, susefirewall2 (oh, sí, el "cortafuegos") implementa ese tipo de medidas de tipo anti-SYN Flood para el servicio ssh, adaptables al pop3. Mira, si lo dijiste tú mismo, además: *** [opensuse-es] Ataques de diccionario a cuentas pop3 http://lists.opensuse.org/opensuse-es/2008-08/msg00931.html *** Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org