hola me están dando caña al apache desde ciertas ips. he visto, y estoy haciendo pruebas, que se puede bloquear temporalmente ips usando el firewall (iptables)? no logro hacerlo. me podéis echar una mano? gracias -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-05-30 a las 21:21 +0200, koxkorrita escribió:
me están dando caña al apache desde ciertas ips.
he visto, y estoy haciendo pruebas, que se puede bloquear temporalmente ips usando el firewall (iptables)?
no logro hacerlo.
me podéis echar una mano?
Está la regla "FW_SERVICES_ACCEPT_EXT", que bloquea automáticamente si hay varios intentos seguidos al puerto que se le diga. Pero con un servicio como el apache no te sirve, porque tiene conexiones frecuentes válidas. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwC5qsACgkQtTMYHG2NR9UE0ACcCOm9Il7PA48mQWklb1pj69uC 0TMAn3EEE8ZrzGlG510v9anF53No0Id5 =9jOp -----END PGP SIGNATURE-----
A mi me pasa algo parecido, estoy mirando información sobre ban2fail o denyhost.... esto lo qeu hace es que si se intenta varias veces, bloqueal la ip el tiempo qeu tu le digas!!! Tienen bastante buena pinta. Un saludo. ----- Mensaje original ---- De: koxkorrita <koxkorrita@laudio.info> Para: OS-es <opensuse-es@opensuse.org> Enviado: dom,30 mayo, 2010 21:21 Asunto: [opensuse-es] firewall hola me están dando caña al apache desde ciertas ips. he visto, y estoy haciendo pruebas, que se puede bloquear temporalmente ips usando el firewall (iptables)? no logro hacerlo. me podéis echar una mano? gracias -- 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 -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-05-31 a las 07:39 -0000, Monica BM escribió:
A mi me pasa algo parecido, estoy mirando información sobre ban2fail o denyhost....
esto lo qeu hace es que si se intenta varias veces, bloqueal la ip el tiempo qeu tu le digas!!!
Y... ¿como defines "intentar" en un servidor web? Porque un servidor web está para que te conectes miles de veces desde la misma IP si te hace falta, cada vez que refrescas la pagina, o si cien ordenadores de la misma empresa abren la pagina desde la misma IP de salida corporativa. Es distinto en un servidor ssh en el que entras con contraseña. Es una sóla conexión rechazada. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwDiqAACgkQtTMYHG2NR9WxLACfdc6uSyplRNleNwiXjoaGqaf8 mN8An0zq2+86vFZOcEb0Hfb7V29fJ7Wy =qwyp -----END PGP SIGNATURE-----
El Mon, 31 May 2010 12:08:22 +0200, Carlos E. R. escribió:
El 2010-05-31 a las 07:39 -0000, Monica BM escribió:
A mi me pasa algo parecido, estoy mirando información sobre ban2fail o denyhost....
esto lo qeu hace es que si se intenta varias veces, bloqueal la ip el tiempo qeu tu le digas!!!
Y... ¿como defines "intentar" en un servidor web?
(...) Fácil, que te estén haciendo peticiones de páginas inexistentes, generalmente scripts de php, para intentar romper algo. Son bots automatizados. Si el ataque está mal hecho y las peticiones te vienen de una misma IP, lo puedes parar con una regla en iptables (descartando los paquetes desde esa IP al puerto 80). 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-05-31 a las 10:40 -0000, Camaleón escribió:
El Mon, 31 May 2010 12:08:22 +0200, Carlos E. R. escribió:
Y... ¿como defines "intentar" en un servidor web?
(...)
Fácil, que te estén haciendo peticiones de páginas inexistentes, generalmente scripts de php, para intentar romper algo. Son bots automatizados.
Si el ataque está mal hecho y las peticiones te vienen de una misma IP, lo puedes parar con una regla en iptables (descartando los paquetes desde esa IP al puerto 80).
No exactamente. Tiene que ser un modulo del apache, o un daemon que analice el log del apache, y entonces añada las reglas iptables necesarias, o las deniegue en el apache. Con iptables a solas no puedes. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwDpNEACgkQtTMYHG2NR9UZagCdGaQpQrFp7n2B/2bDBB9hO+TM mDoAoJS3vIvBu6yBkDiTt1crA3VYXyVW =/IJs -----END PGP SIGNATURE-----
El Mon, 31 May 2010 14:00:11 +0200, Carlos E. R. escribió:
El 2010-05-31 a las 10:40 -0000, Camaleón escribió:
El Mon, 31 May 2010 12:08:22 +0200, Carlos E. R. escribió:
Y... ¿como defines "intentar" en un servidor web?
(...)
Fácil, que te estén haciendo peticiones de páginas inexistentes, generalmente scripts de php, para intentar romper algo. Son bots automatizados.
Si el ataque está mal hecho y las peticiones te vienen de una misma IP, lo puedes parar con una regla en iptables (descartando los paquetes desde esa IP al puerto 80).
No exactamente. Tiene que ser un modulo del apache, o un daemon que analice el log del apache, y entonces añada las reglas iptables necesarias, o las deniegue en el apache.
Con iptables a solas no puedes.
¿Por qué no se va a poder? *** How Do I Block an IP Address on My Linux server? http://www.cyberciti.biz/faq/how-do-i-block-an-ip-on-my-linux-server/ *** Cambias el puerto al 80 y la IP por la que quieras bloquear. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-05-31 a las 12:13 -0000, Camaleón escribió:
El Mon, 31 May 2010 14:00:11 +0200, Carlos E. R. escribió:
Con iptables a solas no puedes.
¿Por qué no se va a poder?
*** How Do I Block an IP Address on My Linux server? http://www.cyberciti.biz/faq/how-do-i-block-an-ip-on-my-linux-server/ ***
Cambias el puerto al 80 y la IP por la que quieras bloquear.
Eso no vale, para eso que dices tienes que saber a priori que IP bloquear. No, tiene que ser automático, el apache tiene que decirle a "X" que le bloquee tal IP. Ese es el intrígulis del asunto. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwD0PkACgkQtTMYHG2NR9XzpQCcDykcEIdBP95Xhd7HinqIN+RR q94An2o8JouobZH2jis/W1cX+Y5+RkGa =PRe6 -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2010-05-31 a las 12:13 -0000, Camaleón escribió:
El Mon, 31 May 2010 14:00:11 +0200, Carlos E. R. escribió:
Con iptables a solas no puedes.
¿Por qué no se va a poder?
*** How Do I Block an IP Address on My Linux server? http://www.cyberciti.biz/faq/how-do-i-block-an-ip-on-my-linux-server/ ***
Cambias el puerto al 80 y la IP por la que quieras bloquear.
Eso no vale, para eso que dices tienes que saber a priori que IP bloquear
No es cierto. Lo he enviado en una respuesta anterior: http://lists.opensuse.org/opensuse-es/2010-05/msg00639.html . No, tiene que ser automático, el apache tiene que decirle a
"X" que le bloquee tal IP. Ese es el intrígulis del asunto.
Apache aquí no pinta nada, si no quieres. Y es mejor que no pinte, que se dedique a servir páginas web que es lo suyo: http://lists.opensuse.org/opensuse-es/2010-05/msg00635.html Saludos
-- CL Martinez carlopmart {at} gmail {d0t} com -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.00.1005312108100.9079@nimrodel.valinor> El 2010-05-31 a las 17:28 +0200, carlopmart escribió:
Carlos E. R. wrote:
*** How Do I Block an IP Address on My Linux server? http://www.cyberciti.biz/faq/how-do-i-block-an-ip-on-my-linux-server/ ***
Cambias el puerto al 80 y la IP por la que quieras bloquear.
Eso no vale, para eso que dices tienes que saber a priori que IP bloquear
No es cierto. Lo he enviado en una respuesta anterior: http://lists.opensuse.org/opensuse-es/2010-05/msg00639.html
Claro que es cierto, y ya vi tu correo antes. Yo lo que he dicho es que no puedes hacer una solución basada unicamente en iptables para defender el apache, de la forma propuesta por Camaleón: iptables -A INPUT -s IP-ADDRESS -j DROP porque para eso tienes que saber la IP y en esa solución no se indica como se obtiene.
. No, tiene que ser automático, el apache tiene que decirle a "X" que le bloquee tal IP. Ese es el intrígulis del asunto.
Apache aquí no pinta nada, si no quieres.
Claro que pinta. Es el atacado, y es el único que sabe si la petición de pagina web es correcta, o piden una pagina falsa o una típica de un ataque. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwECnMACgkQtTMYHG2NR9XYtQCeL/SdQmtLxUYzX9HHrPXc+08c BiwAoJYQ11ojzXemRnp06dWxmVECFaxW =HcdD -----END PGP SIGNATURE-----
Carlos E. R. wrote:
No es cierto. Lo he enviado en una respuesta anterior: http://lists.opensuse.org/opensuse-es/2010-05/msg00639.html
Claro que es cierto, y ya vi tu correo antes.
Yo lo que he dicho es que no puedes hacer una solución basada unicamente en iptables para defender el apache, de la forma propuesta por Camaleón:
iptables -A INPUT -s IP-ADDRESS -j DROP
porque para eso tienes que saber la IP y en esa solución no se indica como se obtiene.
Si puedes y además sin necesidad de saber la IP que ataca. El método es sencillo: instalar una regla iptables que te loguee todo el tráfico al puerto 80 sin bloquear absolutamente nada y con un proceso de HIDS te irá bloqueando "al vuelo" todas las IP's "enemigas", por llamarlo de alguna manera.
. No, tiene que ser automático, el apache tiene que decirle a "X" que le bloquee tal IP. Ese es el intrígulis del asunto.
Apache aquí no pinta nada, si no quieres.
Claro que pinta. Es el atacado, y es el único que sabe si la petición de pagina web es correcta, o piden una pagina falsa o una típica de un ataque.
Apache no pinta nada por el hecho de que iptables es el que va a interceptar la comunicación antes de que llegue al apache y en base a parámetros que tú puedes darle a iptables (como conexciones por segundo, etc), éste tomará un decisión de dejar pasar el paquete o no. Apache no se entera de nada y no tiene que hacer nada. Es muy sencillo. Mira esta regla: "iptables -I FORWARD -j QUEUE" Esta regla es la que se utiliza en snort en modo inline, o sea IPS. Aquí snort captura TODO, absolutamente todo, y toma decisiones antes de que la comunicación llegue al daemon que corresponda ... Esas "decisiones" las toma en base a firmas aunque otros IPS lo hacen también por heurísitica. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-05-31 a las 21:25 +0200, carlopmart escribió:
Yo lo que he dicho es que no puedes hacer una solución basada unicamente en iptables para defender el apache, de la forma propuesta por Camaleón:
iptables -A INPUT -s IP-ADDRESS -j DROP
porque para eso tienes que saber la IP y en esa solución no se indica como se obtiene.
Si puedes y además sin necesidad de saber la IP que ataca. El método es sencillo: instalar una regla iptables que te loguee todo el tráfico al puerto 80 sin bloquear absolutamente nada y con un proceso de HIDS
Camaelón no ha dicho nada de HIDS, y yo estoy respondiendo a la propuesta de Camaleón.
Apache no pinta nada por el hecho de que iptables es el que va a interceptar la comunicación antes de que llegue al apache y en base a parámetros que tú
Apache pinta mucho porque es el que mejor puede saber si el intento es válido o no. Y de hecho, hay módulos de apache para contraatacar este tipo de tráfico. ¿Que se puede hacer de otras formas? Claro. Y la tuya será buena, pero no es a la que estaba contestando. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwEG6UACgkQtTMYHG2NR9VmXACghkjslPABZvoutXSq8wm1eFkH 99cAnRscu8othQwvjOPqgikHxxRuwIJi =BdeN -----END PGP SIGNATURE-----
Carlos E. R. wrote:
Si puedes y además sin necesidad de saber la IP que ataca. El método es sencillo: instalar una regla iptables que te loguee todo el tráfico al puerto 80 sin bloquear absolutamente nada y con un proceso de HIDS
Camaelón no ha dicho nada de HIDS, y yo estoy respondiendo a la propuesta de Camaleón.
Correcto, pero Camaleón sí te ha dicho como se inserta la regla para una IP específica. Yo te he explicado el método automático si quieres hilar más fino ...
Apache no pinta nada por el hecho de que iptables es el que va a interceptar la comunicación antes de que llegue al apache y en base a parámetros que tú
Apache pinta mucho porque es el que mejor puede saber si el intento es válido o no. Y de hecho, hay módulos de apache para contraatacar este tipo de tráfico.
Apache no se entera de aboslutamente de nada en su instalación/configuración original. Solo puedes controlar a través de él el número de threads que puede abrir y cuantas conexiones. Nada más. Apache es incapaz de detectar un ataque DoS, y mucho menos un DDoS sin ayuda externa. Pero repito: siempre es mejor bloquear antes de que llegue la petición al daemon de turno.
¿Que se puede hacer de otras formas? Claro. Y la tuya será buena, pero no es a la que estaba contestando.
Pero es que Camaleón sí te ha contestado a la pregunta original. Si quieres bloquear IP a IP, eso se hace a mano. saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
El Mon, 31 May 2010 21:13:49 +0200, Carlos E. R. escribió:
El 2010-05-31 a las 17:28 +0200, carlopmart escribió:
Carlos E. R. wrote:
*** How Do I Block an IP Address on My Linux server? http://www.cyberciti.biz/faq/how-do-i-block-an-ip-on-my-linux- server/ ***
Cambias el puerto al 80 y la IP por la que quieras bloquear.
Eso no vale, para eso que dices tienes que saber a priori que IP bloquear
No es cierto. Lo he enviado en una respuesta anterior: http://lists.opensuse.org/opensuse-es/2010-05/msg00639.html
Claro que es cierto, y ya vi tu correo antes.
Yo lo que he dicho es que no puedes hacer una solución basada unicamente en iptables para defender el apache, de la forma propuesta por Camaleón:
iptables -A INPUT -s IP-ADDRESS -j DROP
porque para eso tienes que saber la IP y en esa solución no se indica como se obtiene.
No estás muy "fino" hoy ¿eh? X-) ¿Sabes cómo se obtiene la IP? Leyengo el log del apache, que para eso está ;-) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-05-31 a las 19:40 -0000, Camaleón escribió:
porque para eso tienes que saber la IP y en esa solución no se indica como se obtiene.
No estás muy "fino" hoy ¿eh? X-)
¿Sabes cómo se obtiene la IP? Leyengo el log del apache, que para eso está ;-)
Claro, pero eso no lo has dicho antes. Y te falta poner un analizador de logs del apache que cree la lista de IPs a bloquear, porque suelen cambiar. Es raro que te ataquen desde una sola ip o una ip fija. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwEHBQACgkQtTMYHG2NR9W8mACfaeUoUoi7we9ozCs2CiVB6yD8 yNIAnjdFgJRAw5xdZ1uVQ20ifauBIAFH =IF8Y -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2010-05-31 a las 19:40 -0000, Camaleón escribió:
porque para eso tienes que saber la IP y en esa solución no se indica como se obtiene.
No estás muy "fino" hoy ¿eh? X-)
¿Sabes cómo se obtiene la IP? Leyengo el log del apache, que para eso está ;-)
Claro, pero eso no lo has dicho antes. Y te falta poner un analizador de logs del apache que cree la lista de IPs a bloquear, porque suelen cambiar. Es raro que te ataquen desde una sola ip o una ip fija.
Es contraproducente mirar en los logs de apache. El método más "limpio" es que lo haga iptables directamente, en el caso de los Linux. Y si prefieres que sean consultados los logs del apache eso solo lo hacen algunos HIDS... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
El Mon, 31 May 2010 22:29:06 +0200, Carlos E. R. escribió:
El 2010-05-31 a las 19:40 -0000, Camaleón escribió:
porque para eso tienes que saber la IP y en esa solución no se indica como se obtiene.
No estás muy "fino" hoy ¿eh? X-)
¿Sabes cómo se obtiene la IP? Leyengo el log del apache, que para eso está ;-)
Claro, pero eso no lo has dicho antes. Y te falta poner un analizador de logs del apache que cree la lista de IPs a bloquear, porque suelen cambiar. Es raro que te ataquen desde una sola ip o una ip fija.
No, no hace falta analizar nada. Y no, no es raro que ataquen desde una determinada IP, hay mucho "garrulín" suelto. Me parece que cada uno hemos entendido una cosa distinta. Yo he entendido que al OP le están "friendo" el apache con peticiones a ciertas páginas o recursos, que seguramente no existan, y que esas peticiones vienen de determinadas direcciones IP (fijas) que el OP quiere bloquear desde el cortafuegos. Obviamente, para que lo que he dicho más arriba sea cierto, se sobreentiende que: a/ El OP sabe que le están atacando b/ Ha revisado los logs c/ Tiene las direcciones IP "localizadas" d/ Quiere bloquearlas momentáneamente desde susefirewall2 (que para eso está) o mediante una regla de iptables Para lo cual, una sencilla regla de iptables (ya que parece ser que hacerlo con susefirewall2 es "misión imposible") es suficiente. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-05-31 a las 20:40 -0000, Camaleón escribió:
El Mon, 31 May 2010 22:29:06 +0200, Carlos E. R. escribió:
Me parece que cada uno hemos entendido una cosa distinta.
Claro.
Yo he entendido que al OP le están "friendo" el apache con peticiones a ciertas páginas o recursos, que seguramente no existan, y que esas peticiones vienen de determinadas direcciones IP (fijas) que el OP quiere bloquear desde el cortafuegos.
Obviamente, para que lo que he dicho más arriba sea cierto, se sobreentiende que:
a/ El OP sabe que le están atacando b/ Ha revisado los logs c/ Tiene las direcciones IP "localizadas" d/ Quiere bloquearlas momentáneamente desde susefirewall2 (que para eso está) o mediante una regla de iptables
Ahá.
Para lo cual, una sencilla regla de iptables (ya que parece ser que hacerlo con susefirewall2 es "misión imposible") es suficiente.
No está pensado para eso. A lo mejor puede... o se puede añadir. Me suena... una lista de IPs baneada. Por algún lado lo he visto. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwEIm4ACgkQtTMYHG2NR9UZ5gCfdTXLCGB0JQNiJgt8ga3aJGYK 6n8An1vgkoV9LkSDulegxU9kK9eIzYpE =j+Wf -----END PGP SIGNATURE-----
El Mon, 31 May 2010 17:08:39 +0200, Carlos E. R. escribió:
El 2010-05-31 a las 12:13 -0000, Camaleón escribió:
El Mon, 31 May 2010 14:00:11 +0200, Carlos E. R. escribió:
Con iptables a solas no puedes.
¿Por qué no se va a poder?
*** How Do I Block an IP Address on My Linux server? http://www.cyberciti.biz/faq/how-do-i-block-an-ip-on-my-linux-server/ ***
Cambias el puerto al 80 y la IP por la que quieras bloquear.
Eso no vale, para eso que dices tienes que saber a priori que IP bloquear. No, tiene que ser automático, el apache tiene que decirle a "X" que le bloquee tal IP. Ese es el intrígulis del asunto.
A ver, Carlos... lee el mensaje original y los mensajes posteriores míos. Cuando la IP (o las direcciones IP) es conocida y *no cambian*, las puedes bloquear con iptables. Punto. Cosa aparte es que quieras jugar detener (o ralentizar) ataques "aleatorios" que se originan desde varias direcciones IP, que no tiene nada que ver (entiendo yo) con la pregunta del OP. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.00.1005312115490.9079@nimrodel.valinor> El 2010-05-31 a las 16:44 -0000, Camaleón escribió:
El Mon, 31 May 2010 17:08:39 +0200, Carlos E. R. escribió:
Cambias el puerto al 80 y la IP por la que quieras bloquear.
Eso no vale, para eso que dices tienes que saber a priori que IP bloquear. No, tiene que ser automático, el apache tiene que decirle a "X" que le bloquee tal IP. Ese es el intrígulis del asunto.
A ver, Carlos... lee el mensaje original y los mensajes posteriores míos.
Cuando la IP (o las direcciones IP) es conocida y *no cambian*, las puedes bloquear con iptables. Punto.
Yo eso no lo veo en el mensaje original.
Cosa aparte es que quieras jugar detener (o ralentizar) ataques "aleatorios" que se originan desde varias direcciones IP, que no tiene nada que ver (entiendo yo) con la pregunta del OP.
Pero es que yo entiendo que esa es la pregunta original, precisamente. Bien podría el OP estar pendiente de las respuestas y aclarar exactamente que es lo que busca y no liarla. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwEE34ACgkQtTMYHG2NR9X7HgCbBUmzsCixdKVlVb+j9T5iUxpq ufkAn1ovckazAkNFxznh2q7xiTgw0lFQ =wtvc -----END PGP SIGNATURE-----
El Mon, 31 May 2010 21:52:23 +0200, Carlos E. R. escribió:
El 2010-05-31 a las 16:44 -0000, Camaleón escribió:
El Mon, 31 May 2010 17:08:39 +0200, Carlos E. R. escribió:
Cambias el puerto al 80 y la IP por la que quieras bloquear.
Eso no vale, para eso que dices tienes que saber a priori que IP bloquear. No, tiene que ser automático, el apache tiene que decirle a "X" que le bloquee tal IP. Ese es el intrígulis del asunto.
A ver, Carlos... lee el mensaje original y los mensajes posteriores míos.
Cuando la IP (o las direcciones IP) es conocida y *no cambian*, las puedes bloquear con iptables. Punto.
Yo eso no lo veo en el mensaje original.
Hum... No, no estás "fino". (la negrita es mía) "me están dando caña al apache *desde ciertas ips*. he visto, y estoy haciendo pruebas, que *se puede bloquear temporalmente ips* usando el firewall (iptables)?" ¿Mejor? :-)
Cosa aparte es que quieras jugar detener (o ralentizar) ataques "aleatorios" que se originan desde varias direcciones IP, que no tiene nada que ver (entiendo yo) con la pregunta del OP.
Pero es que yo entiendo que esa es la pregunta original, precisamente.
Para nada, lo dice bien claro. No dice que está siendo atacado desde varias IP aleatorias ni nada por el estilo. De hecho, lo normal es que al apache le vengan las peticiones desde IP distintas, luego para "saberse" atacado hay que hacer un análisis más detallado de los registros y de los recursos.
Bien podría el OP estar pendiente de las respuestas y aclarar exactamente que es lo que busca y no liarla.
No creo que importe mucho ya que ambos derroteros son interesantes y tratan un tema similar. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.00.1005312238170.9079@nimrodel.valinor> El 2010-05-31 a las 20:00 -0000, Camaleón escribió:
El Mon, 31 May 2010 21:52:23 +0200, Carlos E. R. escribió:
Cuando la IP (o las direcciones IP) es conocida y *no cambian*, las puedes bloquear con iptables. Punto.
Yo eso no lo veo en el mensaje original.
Hum... No, no estás "fino".
(la negrita es mía)
¡Grrr!
"me están dando caña al apache *desde ciertas ips*.
he visto, y estoy haciendo pruebas, que *se puede bloquear temporalmente ips* usando el firewall (iptables)?"
¿Mejor? :-)
Lo volví a mirar antes de contestarte antes. No me deja convencido que las IPs sean constantes, además de que dudo, o creo que si las bloqueas el ataque saltará a otras. Es posible que mirando el log veas unas IPs "frecuentes", pero dudo que eso sea suficiente para estar seguro que son realmente constantes.
Cosa aparte es que quieras jugar detener (o ralentizar) ataques "aleatorios" que se originan desde varias direcciones IP, que no tiene nada que ver (entiendo yo) con la pregunta del OP.
Pero es que yo entiendo que esa es la pregunta original, precisamente.
Para nada, lo dice bien claro. No dice que está siendo atacado desde varias IP aleatorias ni nada por el estilo.
No me convence, y menos si él no participa en el hilo para aclarar las cosas. Ha iniciado tres o cuatro hilos pero sólo uno contesta para confirmar después. Sólo nueve mensajes desde enero. Así que sin detalles, me voy a la respuesta genérica para proteger un servidor.
De hecho, lo normal es que al apache le vengan las peticiones desde IP distintas, luego para "saberse" atacado hay que hacer un análisis más detallado de los registros y de los recursos.
Claro. Se puede ver, por ejemplo, si ves que al apache le llegan peticiones de paginas raras que sólo contienen los servidores de microsoft, típicas de ataques a sus servidores. Eso es un tipo de ataque se sólo se puede descubrir analizando las peticiones, y es el apache quien está en mejor situación para verlos, porque no son peticiones legítimas (no para un M$, pero menos para un apache). O el ataque puede ser porque llegan cientos de peticiones simultáneas de un robot explorando tu servidor web entero, clonándolo, o simplemente para cargar la información en un buscador como gugle, saturando el servidor porque no tiene tanta capacidad de servicio simultáneo. O puede ser un robot que no hace caso de lo que ponga el fichero "robots" de cada directorio, explorando a lo mejor páginas dinámicas, lo que no tiene sentido y satura el apache y más la base de datos que genera esas páginas detrás. O puede ser un ataque desde sólo una IP que no cambia en días. Dependiendo de la respuesta a esas preguntas, la respuesta cambia mucho.
Bien podría el OP estar pendiente de las respuestas y aclarar exactamente que es lo que busca y no liarla.
No creo que importe mucho ya que ambos derroteros son interesantes y tratan un tema similar.
Pero no sabemos cual es el correcto. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwEIV0ACgkQtTMYHG2NR9VpcgCfVdMrSMjMmcWeEp3a6m/1wNrx WAQAoIAlChfF2l+VwFuIVnOTXrZxzJwF =EokI -----END PGP SIGNATURE-----
Carlos E. R. wrote:
Claro.
Se puede ver, por ejemplo, si ves que al apache le llegan peticiones de paginas raras que sólo contienen los servidores de microsoft, típicas de ataques a sus servidores. Eso es un tipo de ataque se sólo se puede descubrir analizando las peticiones, y es el apache quien está en mejor situación para verlos, porque no son peticiones legítimas (no para un M$, pero menos para un apache).
O el ataque puede ser porque llegan cientos de peticiones simultáneas de un robot explorando tu servidor web entero, clonándolo, o simplemente para cargar la información en un buscador como gugle, saturando el servidor porque no tiene tanta capacidad de servicio simultáneo.
O puede ser un robot que no hace caso de lo que ponga el fichero "robots" de cada directorio, explorando a lo mejor páginas dinámicas, lo que no tiene sentido y satura el apache y más la base de datos que genera esas páginas detrás.
O puede ser un ataque desde sólo una IP que no cambia en días.
Dependiendo de la respuesta a esas preguntas, la respuesta cambia mucho.
Sin ánimo de liarla más hasta que la persona que ha abierto el thread "respire". Yo creo que sí hay una respuesta común a todo lo que planteas Carlos: iptables con un IDS o HIDS. Cubres todas estas opciones y algunas más ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.00.1006032158040.6667@nimrodel.valinor> El 2010-05-31 a las 22:56 +0200, carlopmart escribió:
Carlos E. R. wrote:
Dependiendo de la respuesta a esas preguntas, la respuesta cambia mucho.
Sin ánimo de liarla más hasta que la persona que ha abierto el thread "respire". Yo creo que sí hay una respuesta común a todo lo que planteas Carlos: iptables con un IDS o HIDS. Cubres todas estas opciones y algunas más
Mira la respuesta de jose maria, es exactamente lo que vengo diciendo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwICWYACgkQtTMYHG2NR9XD2gCbBfgKRoCeXnHbIH/ayVMgpBF8 V5UAmwZ3QxqJwBmOd2mjZcNZAmG4tlxk =A+8K -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LSU.2.00.1006032158040.6667@nimrodel.valinor>
El 2010-05-31 a las 22:56 +0200, carlopmart escribió:
Carlos E. R. wrote:
Dependiendo de la respuesta a esas preguntas, la respuesta cambia mucho.
Sin ánimo de liarla más hasta que la persona que ha abierto el thread "respire". Yo creo que sí hay una respuesta común a todo lo que planteas Carlos: iptables con un IDS o HIDS. Cubres todas estas opciones y algunas más
Mira la respuesta de jose maria, es exactamente lo que vengo diciendo.
La he visto y no és una solucion eficiente para un entorno de producción de servidores web. Sirve como solución para servidores de poca carga o "caseros", por ejemplo. Cuando un servidor web es atacado por DoS o DDoS la solución de josé maria tiene como resultado un cuelgue total del servidor. No digo que no sea una solución, pero solo debe ser tomada como preventiva. Las herramientas eficientes para estos casos son IDS/IPS. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.00.1006032235470.6667@nimrodel.valinor> El 2010-06-03 a las 22:16 +0200, carlopmart escribió:
Carlos E. R. wrote:
Mira la respuesta de jose maria, es exactamente lo que vengo diciendo.
La he visto y no és una solucion eficiente para un entorno de producción de servidores web.
Me da la impresión de que jose maría tiene experiencia en ese campo :-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwIEuUACgkQtTMYHG2NR9U9JgCfbPuhfQIc1DyNQ/OA08oDNEIN ws0An2DSZ5bTRw26Z1nscOtW2NH+Yxz7 =jvR6 -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LSU.2.00.1006032235470.6667@nimrodel.valinor>
El 2010-06-03 a las 22:16 +0200, carlopmart escribió:
Carlos E. R. wrote:
Mira la respuesta de jose maria, es exactamente lo que vengo diciendo.
La he visto y no és una solucion eficiente para un entorno de producción de servidores web.
Me da la impresión de que jose maría tiene experiencia en ese campo :-)
No lo pongo en duda en ningún momento ... Pero uno ha sufrido ataques DoS y DDoS en tres ocasiones y los sudores frios le hacen espabilar a uno :)) En serio. Lo que comenta Jose Maria yo ya lo probé en su dia con un ataque DDoS real y el apache murió ... literalmente y eso que estaba en un señor servidor configurado por alguien que sabe muchísimo de tuning apache y murió igual. La solución que implantamos: QoS, firewall, IPS en cluster y TAPs de capturas de tráfico. Resultado: ni un cuelgue más y hemos sufrido más ataques ... Hombre no digo que en este caso se deba montar un cluster IPS ni TAPs, pero que un HIDS con iptables lo sigo viendo muchísimo más eficiente que hacer gestinar esto al apache. Como dije antes soy de la opinión que el apache se ponga a servir páginas y aplicativos y de la seguridad que se encarguen otros que están mejor capacitados ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
El Jueves 03 Junio 2010, carlopmart escribió:
En serio. Lo que comenta Jose Maria yo ya lo probé en su dia con un ataque DDoS real y el apache murió ... literalmente y eso que estaba en un señor servidor configurado por alguien que sabe muchísimo de tuning apache y murió igual. La solución que implantamos: QoS, firewall, IPS en cluster y TAPs de capturas de tráfico. Resultado: ni un cuelgue más y hemos sufrido más ataques ... Hombre no digo que en este caso se deba montar un cluster IPS ni TAPs, pero que un HIDS con iptables lo sigo viendo muchísimo más eficiente que hacer gestinar esto al apache. Como dije antes soy de la opinión que el apache se ponga a servir páginas y aplicativos y de la seguridad que se encarguen otros que están mejor capacitados ...
Saludos.
* Lo que es evidente es que no te leiste la respuesta, a estas alturas ya vas soportando el DDos con media docena de tecnicas a las que el 99% de los usuarios y empresas ni le interesan ni las implementaran por no estar en relacion con su infraestructura, medios ni necesidades de uptime y en lo que comentas insistes en local, lo cual ni tu ni Google ni Yahoo han conseguido, en un DDos de lo que se trata es de que no te saturen las lineas principales, en resumen deshacerte de las conexiones chungas lo antes posible y de rebote de muchas buenas por supuesto, apache muere si tu le dejas morir, lo unico que se puede hacer es lo mismo que el atacante distribuir el palo a servidores de sacrificio en terceras ip y con anchos de banda contratados preventivamente a tal efecto, cuando google sufre un ddos tiene a media docena de empresas al lado soportando el asunto, akamai, etc ...etc, con centenares de Gb/s disponibles. * Lo que tiene que hacer el que pregunta es lo que le he dicho si el ataque es desde pocas ips, con especial atencion a lo que le he comentado de cerrar la conexion si es un ddos desde muchas ips e irse a comer, por que me apuesto un cafe con leche a que el ancho de banda de este caballero no supera una T1 y ese es el problema no apache. * Y en tu caso cuando sufras un DDos en serio no de cuatro cantamañanas entrenandose para asaltar una pieza de mayor envergadura mediatica, ten preparado el asunto de la excavadora para cuando llamen tus clientes.
jose maria wrote:
El Jueves 03 Junio 2010, carlopmart escribió:
En serio. Lo que comenta Jose Maria yo ya lo probé en su dia con un ataque DDoS real y el apache murió ... literalmente y eso que estaba en un señor servidor configurado por alguien que sabe muchísimo de tuning apache y murió igual. La solución que implantamos: QoS, firewall, IPS en cluster y TAPs de capturas de tráfico. Resultado: ni un cuelgue más y hemos sufrido más ataques ... Hombre no digo que en este caso se deba montar un cluster IPS ni TAPs, pero que un HIDS con iptables lo sigo viendo muchísimo más eficiente que hacer gestinar esto al apache. Como dije antes soy de la opinión que el apache se ponga a servir páginas y aplicativos y de la seguridad que se encarguen otros que están mejor capacitados ...
Saludos.
* Lo que es evidente es que no te leiste la respuesta, a estas alturas ya vas soportando el DDos con media docena de tecnicas a las que el 99% de los usuarios y empresas ni le interesan ni las implementaran
¿¿perdón?? .. ¿¿"ni le interesan ni las implementaran"?? ¿Estás seguro? La persona que abrió el thread no creo que implemente una solución así pero el resto ... por no estar en
relacion con su infraestructura, medios ni necesidades de uptime y en lo que comentas insistes en local, lo cual ni tu ni Google ni Yahoo han conseguido, en un DDos de lo que se trata es de que no te saturen las lineas principales, en resumen deshacerte de las conexiones chungas lo antes posible y de rebote de muchas buenas por supuesto, apache muere si tu le dejas morir
Hombre, yo no le quiero dejar morir, pero te aseguro que murió. Apache no está "pensado" para resolver incidencias de este tipo. Llega a donde llega ... , lo unico que
se puede hacer es lo mismo que el atacante distribuir el palo a servidores de sacrificio en terceras ip y con anchos de banda contratados preventivamente a tal efecto, cuando google sufre un ddos tiene a media docena de empresas al lado soportando el asunto, akamai, etc ...etc, con centenares de Gb/s disponibles.
... y puedes hacer más cosas. Pero yo la opción que daba era la de utilizar iptables+HIDS/IDS que creo que puede ser considerado por la persona que abrió el thread...
* Lo que tiene que hacer el que pregunta es lo que le he dicho si el ataque es desde pocas ips, con especial atencion a lo que le he comentado de cerrar la conexion si es un ddos desde muchas ips e irse a comer, por que me apuesto un cafe con leche a que el ancho de banda de este caballero no supera una T1 y ese es el problema no apache.
Seguro que no tiene una T1. Pero es que puedes aplicar lo mismo para una T1 que para una conexión a 256Kb desde el punto de vista teórico ...
* Y en tu caso cuando sufras un DDos en serio no de cuatro cantamañanas
Te aseguro que no fueron cuatro cantamañanas. Fue un DDoS en toda regla desde una bootnet de China. Y sí mira, al final fue controlado por la infraestuctura que comenté antes ...
entrenandose para asaltar una pieza de mayor envergadura mediatica, ten preparado el asunto de la excavadora para cuando llamen tus clientes.
Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
El Lunes 07 Junio 2010, carlopmart escribió:
jose maria wrote:
* Esta respuesta no es para ti, es para general conocimiento, tenemos notese el tenemos la mania de contestar a "nuestros" problemas y no a los del que pregunta, lo que tu o yo implementemos NO tiene nada que ver con lo de ese señor y lo probable es que no vaya a tener nada que ver nunca, asi que procuremos dar soluciones ajustadas a las necesidades y probabilidades del que pregunta. Este señor no tiene posiblidad alguna ante un DDos de tipo medio, no recuerdo el enunciado de la pregunta pero era evidente, simplemente y sin entrar en nada mas por ancho de banda y lo que hay que decirle es que ante un ataque del tipo "tocando los cojones" emplee tacticas razonables y ante lo otro cierre el grifo y se vaya a dormir. * Todo lo demas es autobombo sin sentido y liarle.
jose maria wrote:
El Lunes 07 Junio 2010, carlopmart escribió:
jose maria wrote:
* Esta respuesta no es para ti, es para general conocimiento, tenemos notese el tenemos la mania de contestar a "nuestros" problemas y no a los del que pregunta, lo que tu o yo implementemos NO tiene nada que ver con lo de ese señor y lo probable es que no vaya a tener nada que ver nunca, asi que procuremos dar soluciones ajustadas a las necesidades y probabilidades del que pregunta. Este señor no tiene posiblidad alguna ante un DDos de tipo medio, no recuerdo el enunciado de la pregunta pero era evidente, simplemente y sin entrar en nada mas por ancho de banda y lo que hay que decirle es que ante un ataque del tipo "tocando los cojones" emplee tacticas razonables y ante lo otro cierre el grifo y se vaya a dormir.
* Todo lo demas es autobombo sin sentido y liarle.
Hombre, la persona en cuestión ha recibido dos respuestas ajustadas a su problema: -a) Camaleón le ha comentado que ya que conoce las IPs las asigne de forma manual a reglas de iptables. -b) La mía: si no quiere hacerlo de forma manual puede utilizar iptables+HIDS (recomendé OSSEC) que se lo hará de forma automática ... Después todo degeneró a DoS, DDoS, que si mod_evassive en apache, etc .. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-06-07 a las 21:47 +0200, carlopmart escribió:
jose maria wrote:
* Todo lo demas es autobombo sin sentido y liarle.
Hombre, la persona en cuestión ha recibido dos respuestas ajustadas a su problema:
Cuatro. No dos. Te olvidas de las que no te gustan a tí. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwNVDUACgkQtTMYHG2NR9VFkACgmTPyYiGdLG4yj3saR9tZ4A83 2qUAn0UThKCeuc+XNg0NnR3CNJhI6SMZ =7ODC -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2010-06-07 a las 21:47 +0200, carlopmart escribió:
jose maria wrote:
* Todo lo demas es autobombo sin sentido y liarle.
Hombre, la persona en cuestión ha recibido dos respuestas ajustadas a su problema:
Cuatro. No dos. Te olvidas de las que no te gustan a tí.
- -- Saludos
Ok. Cuatro entonces: -a) Camaleón le ha comentado que ya que conoce las IPs las asigne de forma manual a reglas de iptables. -b) La mía: si no quiere hacerlo de forma manual puede utilizar iptables+HIDS (recomendé OSSEC) que se lo hará de forma automática ... -c) Carlos E.R. y Jose Maria: utlizar módulos integrados en apache como mod_evassive más configuración propia de apache. -d) José Maria: utilización de módulos específicos en iptables. ¿Es correcto? Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
El Thu, 03 Jun 2010 22:39:00 +0200, Carlos E. R. escribió:
El 2010-06-03 a las 22:16 +0200, carlopmart escribió:
Carlos E. R. wrote:
Mira la respuesta de jose maria, es exactamente lo que vengo diciendo.
La he visto y no és una solucion eficiente para un entorno de producción de servidores web.
Me da la impresión de que jose maría tiene experiencia en ese campo :-)
El cortafuegos sirve precisamente para eso. Cualquier manual de seguridad te dirá que ante un ataque indiscriminado, la primera medida a tomar es cortar la comunicación con la IP desde donde se está originando las peticiones no gestionarla desde el servicio que está siendo atacado. Las soluciones "de evasión" (preventivas) no siempre son eficientes y deben complementarse con las reglas del cortafuegos. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.00.1006040148060.6667@nimrodel.valinor> El 2010-06-03 a las 20:53 -0000, Camaleón escribió:
El Thu, 03 Jun 2010 22:39:00 +0200, Carlos E. R. escribió:
Me da la impresión de que jose maría tiene experiencia en ese campo :-)
El cortafuegos sirve precisamente para eso.
Cualquier manual de seguridad te dirá que ante un ataque indiscriminado, la primera medida a tomar es cortar la comunicación con la IP desde donde se está originando las peticiones no gestionarla desde el servicio que está siendo atacado. Las soluciones "de evasión" (preventivas) no siempre son eficientes y deben complementarse con las reglas del cortafuegos.
Y dale. Es la aplicación atacada la que sabe, en tiempo real, que está siendo atacada y con qué tipo de ataque, y es ella la que debe ordenar la defensa. La defensa puede ser un bloqueo de IP en el cortafuegos. La IP que diga la aplicación. Ej, según gugle: mod_evasive and mod_security modules are used to secure Apache Web Server from DDoS and brute force attacks by implementing web application firewall. For mod_security installation procedure, please use mod_security howto article. The mod_evasive authoring site (zdziarski.com) states that mod_evasive is an evasive maneuvers module for Apache to provide evasive action in the event of an HTTP DoS or DDoS attack or brute force attack. It is also designed to be a detection and network management tool, and can be easily configured to talk to ipchains, firewalls, routers, and etcetera.. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwIP+gACgkQtTMYHG2NR9WizgCgh2SWerm5cnQHyao1bMb9tk2K NeoAnjkTUcbXb0jv9NN5E8SqT71NXyV2 =rjOO -----END PGP SIGNATURE-----
El Fri, 04 Jun 2010 01:51:03 +0200, Carlos E. R. escribió:
El 2010-06-03 a las 20:53 -0000, Camaleón escribió:
El cortafuegos sirve precisamente para eso.
Cualquier manual de seguridad te dirá que ante un ataque indiscriminado, la primera medida a tomar es cortar la comunicación con la IP desde donde se está originando las peticiones no gestionarla desde el servicio que está siendo atacado. Las soluciones "de evasión" (preventivas) no siempre son eficientes y deben complementarse con las reglas del cortafuegos.
Y dale.
Y toma.
Es la aplicación atacada la que sabe, en tiempo real, que está siendo atacada y con qué tipo de ataque, y es ella la que debe ordenar la defensa.
La defensa puede ser un bloqueo de IP en el cortafuegos. La IP que diga la aplicación.
Las medidas disuasorias no siempre "f-u-n-c-i-o-n-a-n". En cualquier caso hay que usar el cortafuegos: apache mod_evasive sucks as anti-ddos protection http://www.dslreports.com/forum/r20353461-apache-modevasive-sucks-as-antiddo... Hasta los de Apache te lo dicen: *** http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos Denial of Service (DoS) attacks All network servers can be subject to denial of service attacks that attempt to prevent responses to clients by tying up the resources of the server. It is not possible to prevent such attacks entirely, but you can do certain things to mitigate the problems that they create. Often the most effective anti-DoS tool will be a firewall ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ or other operating-system configurations. For example, most firewalls can be configured to restrict the number of simultaneous connections from any individual IP address or network, thus preventing a range of simple attacks. Of course this is no help against Distributed Denial of Service attacks (DDoS). *** 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
Camaleón wrote:
El Fri, 04 Jun 2010 01:51:03 +0200, Carlos E. R. escribió:
El 2010-06-03 a las 20:53 -0000, Camaleón escribió:
El cortafuegos sirve precisamente para eso.
Cualquier manual de seguridad te dirá que ante un ataque indiscriminado, la primera medida a tomar es cortar la comunicación con la IP desde donde se está originando las peticiones no gestionarla desde el servicio que está siendo atacado. Las soluciones "de evasión" (preventivas) no siempre son eficientes y deben complementarse con las reglas del cortafuegos. Y dale.
Y toma.
Es la aplicación atacada la que sabe, en tiempo real, que está siendo atacada y con qué tipo de ataque, y es ella la que debe ordenar la defensa.
La defensa puede ser un bloqueo de IP en el cortafuegos. La IP que diga la aplicación.
Las medidas disuasorias no siempre "f-u-n-c-i-o-n-a-n". En cualquier caso hay que usar el cortafuegos:
apache mod_evasive sucks as anti-ddos protection http://www.dslreports.com/forum/r20353461-apache-modevasive-sucks-as-antiddo...
Hasta los de Apache te lo dicen:
*** http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos
Denial of Service (DoS) attacks All network servers can be subject to denial of service attacks that attempt to prevent responses to clients by tying up the resources of the server. It is not possible to prevent such attacks entirely, but you can do certain things to mitigate the problems that they create.
Often the most effective anti-DoS tool will be a firewall ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ or other operating-system configurations. For example, most firewalls can be configured to restrict the number of simultaneous connections from any individual IP address or network, thus preventing a range of simple attacks. Of course this is no help against Distributed Denial of Service attacks (DDoS). ***
Saludos,
Es como dice Camaleón. Carlos ¿de verdad tú te crees que por ejemplo un Tomcat sabe que "en tiempo real, que está siendo atacada y con qué tipo de ataque, y es ella la que debe ordenar la defensa"?? El tomcat no tiene ni idea de lo que pasa porque no es su función ni ha sido programado para ello ... Igual que apache. Mira la última línea que pone camaleón: "Of course this is no help against Distributed Denial of Service attacks (DDoS)." Mod_evasive y demás módulos apache ante un DDoS bien organizado se lo comen con patatas ... Es más el SO es mucho más efectivo que el propio apache para esto ... saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-06-04 08:15, Camaleón wrote:
El Fri, 04 Jun 2010 01:51:03 +0200, Carlos E. R. escribió:
El 2010-06-03 a las 20:53 -0000, Camaleón escribió:
Y dale.
Y toma.
Es la aplicación atacada la que sabe, en tiempo real, que está siendo atacada y con qué tipo de ataque, y es ella la que debe ordenar la defensa.
La defensa puede ser un bloqueo de IP en el cortafuegos. La IP que diga la aplicación.
Las medidas disuasorias no siempre "f-u-n-c-i-o-n-a-n". En cualquier caso hay que usar el cortafuegos:
¿Quien habla de disuasorias? No te fijes en el nombre de un módulo. Es sólo un ejemplo.
Hasta los de Apache te lo dicen:
*** http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos
Denial of Service (DoS) attacks All network servers can be subject to denial of service attacks that attempt to prevent responses to clients by tying up the resources of the server. It is not possible to prevent such attacks entirely, but you can do certain things to mitigate the problems that they create.
Often the most effective anti-DoS tool will be a firewall
El mod_evasive ese (que no será el unico modulo que existe) se usa, según el texto que puse, para cambiar las reglas iptables al vuelo. O sea, el cortafuegos. Os habeis emperrado en lo que no es. Un ataque DOS, masivo, es un tipo de ataque que necesita un tipo de medidas. Un ataque lento, que busca vulnerabilides en el servidor web, no puedes hacer nada en el cortafuegos porque el cortafuegos no sabe que hay un ataque en curso, no puede saberlo a no ser que analice el _contenido_ del tráfico. El servidor web sí puede saberlo, y puede entonces decirle al cortafuegos que corte esas IPs. De eso es de lo que estoy hablando. Y por cierto, ante un ataque grande, es el proveedor quien lo corta, al habla con el cliente. Con un proveedor como tiene que ser - porque hay ataques que lo que se comen es el ancho de banda que tengas contratado, y por mucho que hagas en tu cortafuegos, no te sirve de nada. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAkwJQrYACgkQja8UbcUWM1ybgQEAi7LyYPCQZN1d3FSnf3mvbhR5 Y9Ac/RLebILFkfkM2GEA+wXUELmE4bxCxfOM44Nf3ZzkHJxBTWDuHLgXcl/4pHo2 =vOme -----END PGP SIGNATURE----- -- 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
El Fri, 04 Jun 2010 20:15:18 +0200, Carlos E. R. escribió:
On 2010-06-04 08:15, Camaleón wrote:
Las medidas disuasorias no siempre "f-u-n-c-i-o-n-a-n". En cualquier caso hay que usar el cortafuegos:
¿Quien habla de disuasorias? No te fijes en el nombre de un módulo. Es sólo un ejemplo.
Son "disuasorias" porque permiten el acceso a los recursos hasta cierto punto, es decir, permites al atacante "juguetear" con tu servidor. No son medidas de bloqueo directo.
Often the most effective anti-DoS tool will be a firewall
El mod_evasive ese (que no será el unico modulo que existe) se usa, según el texto que puse, para cambiar las reglas iptables al vuelo. O sea, el cortafuegos.
Sí, pero lo que te quiero decir es que ante ciertos ataques eso resulta ineficiente.
Os habeis emperrado en lo que no es.
Juvar, que no O:-) A ver ¿quiénes de los "emperrados" tenemos un servidor expuesto? Yo, en mi caso me fríen el servidor POP3 (cyrus) con intentos de acceso (ataques de diccionario) para adivinar el nombre de usuario/contraseña y después usarlo para poder enviar spam a través de mi Postfix, "baipaseando" el "smtp auth". Bien, pues he tenido que activar el cortafuegos del router (que no será más que un iptables "descafeinado") para pararlos. ¿Cómo defiendo al pobre Cyrus sino? Con eso o con el susefirewall2... que ya no tengo, por lo que si no tuviera el cortafuegos en el router tendría que instalar algún administardor de iptables como "firehol" o algún otro, porque meterme con el iptables directamente me da "yu-yu" :-) A ver, ¿qué servicios externos tienes que proteger tú? ¿al cacharrín de la TV? >>>:-)
Un ataque DOS, masivo, es un tipo de ataque que necesita un tipo de medidas. Un ataque lento, que busca vulnerabilides en el servidor web, no puedes hacer nada en el cortafuegos porque el cortafuegos no sabe que hay un ataque en curso, no puede saberlo a no ser que analice el _contenido_ del tráfico. El servidor web sí puede saberlo, y puede entonces decirle al cortafuegos que corte esas IPs.
Te puedo dar las direcciones IP de mis atacantes cuando quieras. Todo queda registrado. Esas direcciones IP se pueden bloquear directamente metiéndolas manualmente en iptables para que las rechace el cortafuegos o mejor aún, un bloque de red completo. O puedes crear un script para que añada todas esas direcciones a la regla de iptables automáticamente.
De eso es de lo que estoy hablando.
Y por cierto, ante un ataque grande, es el proveedor quien lo corta, al habla con el cliente. Con un proveedor como tiene que ser - porque hay ataques que lo que se comen es el ancho de banda que tengas contratado, y por mucho que hagas en tu cortafuegos, no te sirve de nada.
Los ataques a gran escala y distribuidos no son comunes en los servidores que podamos manejar (bueno, al menos no en mi caso que administro un servidor corporativo y un ataque "grande" tendría un fin muy concreto). Los ataques más habituales que recibo suelen seguir un mismo patrón: direcciones IP de China (o de países de Europa del Este y alguna de Brasil), y no suele variar en el mismo día, lanzan el ataque desde la misma dirección IP con robots autómatas. No es un "ataque", yo diría que más bien son las "molestias" habituales de tener servicios abiertos accesibles desde Internet. 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
Camaleón wrote:
Un ataque DOS, masivo, es un tipo de ataque que necesita un tipo de medidas. Un ataque lento, que busca vulnerabilides en el servidor web, no puedes hacer nada en el cortafuegos porque el cortafuegos no sabe que hay un ataque en curso, no puede saberlo a no ser que analice el _contenido_ del tráfico. El servidor web sí puede saberlo, y puede entonces decirle al cortafuegos que corte esas IPs.
Te puedo dar las direcciones IP de mis atacantes cuando quieras. Todo queda registrado. Esas direcciones IP se pueden bloquear directamente metiéndolas manualmente en iptables para que las rechace el cortafuegos o mejor aún, un bloque de red completo. O puedes crear un script para que añada todas esas direcciones a la regla de iptables automáticamente.
De eso es de lo que estoy hablando.
Es tal como comenta Camaleon.
Y por cierto, ante un ataque grande, es el proveedor quien lo corta
Eso depende de la "pasta" que pagues ... , al
habla con el cliente. Con un proveedor como tiene que ser - porque hay ataques que lo que se comen es el ancho de banda que tengas contratado, y por mucho que hagas en tu cortafuegos, no te sirve de nada.
Y los hay que no se centran en el ancho de banda sino en dejarte solo un servicio fuera de juego ...
Los ataques a gran escala y distribuidos no son comunes en los servidores que podamos manejar (bueno, al menos no en mi caso que administro un servidor corporativo y un ataque "grande" tendría un fin muy concreto).
Los ataques más habituales que recibo suelen seguir un mismo patrón: direcciones IP de China (o de países de Europa del Este y alguna de Brasil), y no suele variar en el mismo día, lanzan el ataque desde la misma dirección IP con robots autómatas. No es un "ataque", yo diría que más bien son las "molestias" habituales de tener servicios abiertos accesibles desde Internet.
Saludos,
En resumen: esto es muy sencillo. Buscad por google algo tal que así: "simulate DDoS" y al momento os saltarán un montón de scripts para hacer tests. Es tan fácil como que primero probeis con un apache (más todos los módulos que querais meter) y después con iptables+IDS(IPS/HIDS) ... Solo así vais a ver que és más eficiente ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-06-04 21:04, Camaleón wrote:
El Fri, 04 Jun 2010 20:15:18 +0200, Carlos E. R. escribió:
On 2010-06-04 08:15, Camaleón wrote:
Las medidas disuasorias no siempre "f-u-n-c-i-o-n-a-n". En cualquier caso hay que usar el cortafuegos:
¿Quien habla de disuasorias? No te fijes en el nombre de un módulo. Es sólo un ejemplo.
Son "disuasorias" porque permiten el acceso a los recursos hasta cierto punto, es decir, permites al atacante "juguetear" con tu servidor. No son medidas de bloqueo directo.
Pero yo en ningún momento he hablado de medidas disuasorias.
Often the most effective anti-DoS tool will be a firewall
El mod_evasive ese (que no será el unico modulo que existe) se usa, según el texto que puse, para cambiar las reglas iptables al vuelo. O sea, el cortafuegos.
Sí, pero lo que te quiero decir es que ante ciertos ataques eso resulta ineficiente.
Y ante el tipo de ataques de los que yo hablo, muy eficaz.
Os habeis emperrado en lo que no es.
Juvar, que no O:-)
A ver ¿quiénes de los "emperrados" tenemos un servidor expuesto? Yo, en mi caso me fríen el servidor POP3 (cyrus) con intentos de acceso (ataques de diccionario) para adivinar el nombre de usuario/contraseña y después usarlo para poder enviar spam a través de mi Postfix, "baipaseando" el "smtp auth".
Pero eso es otro tipo de ataque, hablábamos de apache. Pues mira, "algo" podría sacar información del cyrus, detectar posibles ataques de diccionario, y bloquear esa IP en el cortafuegos. Es el mismo concepto del que hablo. Por cierto, otro sitio para bloquear IPs es en el /etc/deny... creo que el nombre es denyhost. Hay un script popular que hace eso. Creo que hay un servicio por ahí que genera listados de IPs atacantes, no se si cada dia o cada hora, para meterlos en tu script (automáticamente) y bloquearlas. Igual lo tengo apuntado por ahí. O busca en correos de Patrick, me parece que fué él quien me lo dijo. En el susefirewall hay una configuración (modificación reciente, por cierto, yo fuí uno de los que la pedí) que bloquea una IP si hace varios intentos en un minuto. Es habitual usarlo para el sshd. Meter la regla en iptables no es dificil, tengo entendido. Es regla no la puedes emplear con el servidor web. Y siguiendo con lo mismo, ese que dices es un ataque "lento". Si la regla en iptables se activa a los tres intentos por minuto, los atacantes no tienen más que modificar su script para no pasar el umbral de detección. Por ejemplo, la herramienta "nmap" para escanear puertos se puede configurar para que vaya muy lenta y con un orden aleatorio en los puertos para esquivar la detección. El cortafuegos no se entera de que le están escaneando... Si te hacen un ataque lento tienes que detectarlo en los logs, o con herramientas espécificas o módulos del daemon atacado hechos para ese objeto. Es un tipo de ataque distinto de un DoS y la defensa es distinta. Cada defensa sirve para cosas distintas. Yo no estoy hablando de metodos contra DoS.
Bien, pues he tenido que activar el cortafuegos del router (que no será más que un iptables "descafeinado") para pararlos. ¿Cómo defiendo al pobre Cyrus sino? Con eso o con el susefirewall2... que ya no tengo, por lo que si no tuviera el cortafuegos en el router tendría que instalar algún administardor de iptables como "firehol" o algún otro, porque meterme con el iptables directamente me da "yu-yu" :-)
Na, pues compra un router de los buenos de Cisco, hazte el curso o contrata a alguien que lo tenga (yo lo tengo ;-) ), y te hacen maravillas.
A ver, ¿qué servicios externos tienes que proteger tú? ¿al cacharrín de la TV? >>>:-)
Yo personalmente no, pero me parece que Jose María, que es quien mencionó el mod_evasive (que yo no lo conozco) sí tiene experiencia en esas cosas. Yo trato de mantenerme un poco al dia y enterarme de lo que se habla; y si alguien pregunta le puedo dar una orientación de por donde mirar. Simplemente eso.
Un ataque DOS, masivo, es un tipo de ataque que necesita un tipo de medidas. Un ataque lento, que busca vulnerabilides en el servidor web, no puedes hacer nada en el cortafuegos porque el cortafuegos no sabe que hay un ataque en curso, no puede saberlo a no ser que analice el _contenido_ del tráfico. El servidor web sí puede saberlo, y puede entonces decirle al cortafuegos que corte esas IPs.
Te puedo dar las direcciones IP de mis atacantes cuando quieras. Todo queda registrado. Esas direcciones IP se pueden bloquear directamente metiéndolas manualmente en iptables para que las rechace el cortafuegos o mejor aún, un bloque de red completo. O puedes crear un script para que añada todas esas direcciones a la regla de iptables automáticamente.
Y esos scripts existen. Pero el tipo de ataque que has descrito contra tu POP3 no es un DoS, es un ataque lento buscando vulnerabilidades. Necesitas algo que automáticamente los detecte y bloquee, sin tener que mirar tú en el log, y espécifico contra ataques a ese servicio.
De eso es de lo que estoy hablando.
Y por cierto, ante un ataque grande, es el proveedor quien lo corta, al habla con el cliente. Con un proveedor como tiene que ser - porque hay ataques que lo que se comen es el ancho de banda que tengas contratado, y por mucho que hagas en tu cortafuegos, no te sirve de nada.
Los ataques a gran escala y distribuidos no son comunes en los servidores que podamos manejar (bueno, al menos no en mi caso que administro un servidor corporativo y un ataque "grande" tendría un fin muy concreto).
Pues no creas... Eso que comento de contactar con el ISP es algo que he leído de alguien con un servidor de empresa mediana. No se el tamaño de la tuya, pero suponte que tengas una conexión de 10 megas simétrica. Suponte que te hacen un ataque masivo y distribuido contra tu servidor web (si lo tienes) o tu servidor de correo. Tu rechazas las conexiones tan rápido como le llegan (o las tiras en el cortafuegos), pero es que en seguida te van a llenar tu ancho de banda y no vas a poder hacer absolutamente nada, te bloquean toda la empresa, entrante y saliente. El único que puede hacerlo es el ISP, antes de que entren en tu tubería. Ese alguien que lo contaba era usaniano y su proveedor empezó a bloquear conexiones con un patrón determinado, permitiendo a esa empresa capear el temporal. El sitio donde lo narraban era uno de esos sitios de análisis de seguridad serios que hay por ahí, cuando empezaron a describir cierto tipo de ataques distribuidos no detectables, que era desconocido, hace unos años. Ahora sí se detecta. A ese tipo le estaban atacando simplemente con el propósito de probar la nueva técnica para luego emplearla contra otros sitios realmente interesantes. Aquí no podríamos nosotros hablar con el ISP con esa velocidad y eficacia.
Los ataques más habituales que recibo suelen seguir un mismo patrón: direcciones IP de China (o de países de Europa del Este y alguna de Brasil), y no suele variar en el mismo día, lanzan el ataque desde la misma dirección IP con robots autómatas. No es un "ataque", yo diría que más bien son las "molestias" habituales de tener servicios abiertos accesibles desde Internet.
Sí es un ataque... son redes de bots que se dedican a eso. Cuando encuentran paso lo reportan al "dueño", que probablemente no es ni siquiera el del ordenador atacante. A partir de entonces tu ordenador se suma a la red de bots, en este caso para enviar spam. Es serio, no los minusvalores. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkwJXdQACgkQU92UU+smfQUMJgCfYWIoMDGswcwISw1u/TzFXPiV nbIAoJIRfDfcC2v5gCc/zCyQ0Jth2VMY =f5wA -----END PGP SIGNATURE----- -- 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
El Fri, 04 Jun 2010 22:11:00 +0200, Carlos E. R. escribió:
On 2010-06-04 21:04, Camaleón wrote:
Son "disuasorias" porque permiten el acceso a los recursos hasta cierto punto, es decir, permites al atacante "juguetear" con tu servidor. No son medidas de bloqueo directo.
Pero yo en ningún momento he hablado de medidas disuasorias.
Sí, cuando dices de usar el "mod_evasive" del Apache, por ejemplo. Eso es una medida de disuasión, no de bloqueo directo.
Sí, pero lo que te quiero decir es que ante ciertos ataques eso resulta ineficiente.
Para nada, la forma más eficaz de impedir el "goteo" el cerrar la llave de paso :-). Lo otro (lo que tú dices) sería cerrar el grifo pero como haya mucha presión, te revienta las cañerías de la casa >:-)
Y ante el tipo de ataques de los que yo hablo, muy eficaz.
Inservible, ya lo has leído en el enlace que he enviado antes.
A ver ¿quiénes de los "emperrados" tenemos un servidor expuesto? Yo, en mi caso me fríen el servidor POP3 (cyrus) con intentos de acceso (ataques de diccionario) para adivinar el nombre de usuario/contraseña y después usarlo para poder enviar spam a través de mi Postfix, "baipaseando" el "smtp auth".
Pero eso es otro tipo de ataque, hablábamos de apache.
Son situaciones reales, muy similares y que requieren las mismas medidas.
Pues mira, "algo" podría sacar información del cyrus, detectar posibles ataques de diccionario, y bloquear esa IP en el cortafuegos. Es el mismo concepto del que hablo.
Ya lo hace el cortafuegos. Yo quiero que el Cyrus se encargue de gestionar el correo que para lo otro ya tengo "la caballería". Te recuerdo la filosofía de linux: muchos programitas pero especializados :-) (...)
Y siguiendo con lo mismo, ese que dices es un ataque "lento".
Los ataques que recibo son lentos. Lo que se ve en las películas es otra cosa :-). (...)
Si te hacen un ataque lento tienes que detectarlo en los logs, o con herramientas espécificas o módulos del daemon atacado hechos para ese objeto. Es un tipo de ataque distinto de un DoS y la defensa es distinta.
Con iptables y una regla de "drop".
Cada defensa sirve para cosas distintas. Yo no estoy hablando de metodos contra DoS.
Contra un ddos en toda regla no hay "mod_evasive" que valga, tendrías que usar otras tácticas, como desviar el tráfico a un honeypot o a otro equipo para que balancear las "tortas". No lo sé, la verdad es que no me he visto dentro de un ataque sincronizado de este tipo :-/
Bien, pues he tenido que activar el cortafuegos del router (que no será más que un iptables "descafeinado") para pararlos. ¿Cómo defiendo al pobre Cyrus sino? Con eso o con el susefirewall2... que ya no tengo, por lo que si no tuviera el cortafuegos en el router tendría que instalar algún administardor de iptables como "firehol" o algún otro, porque meterme con el iptables directamente me da "yu-yu" :-)
Na, pues compra un router de los buenos de Cisco, hazte el curso o contrata a alguien que lo tenga (yo lo tengo ;-) ), y te hacen maravillas.
¿Cisco "bueno"...? Será por los "agujeros" que tiene el IOS. No gracias, tendría que parchear al Cisco casi a diario :-).
Te puedo dar las direcciones IP de mis atacantes cuando quieras. Todo queda registrado. Esas direcciones IP se pueden bloquear directamente metiéndolas manualmente en iptables para que las rechace el cortafuegos o mejor aún, un bloque de red completo. O puedes crear un script para que añada todas esas direcciones a la regla de iptables automáticamente.
Y esos scripts existen. Pero el tipo de ataque que has descrito contra tu POP3 no es un DoS, es un ataque lento buscando vulnerabilidades. Necesitas algo que automáticamente los detecte y bloquee, sin tener que mirar tú en el log, y espécifico contra ataques a ese servicio.
Es el tipo de ataque común que verás en el 90% de los servidores web. A diario.
Los ataques a gran escala y distribuidos no son comunes en los servidores que podamos manejar (bueno, al menos no en mi caso que administro un servidor corporativo y un ataque "grande" tendría un fin muy concreto).
Pues no creas... Eso que comento de contactar con el ISP es algo que he leído de alguien con un servidor de empresa mediana.
No es lo habitual.
Aquí no podríamos nosotros hablar con el ISP con esa velocidad y eficacia.
Sí, siempre y cuando tengas un contrato específico con la operadora de turno. Obviamente, te mandan a freír monas si llamas al 900-101-010 y les dices que estás "under attack".
Los ataques más habituales que recibo suelen seguir un mismo patrón: direcciones IP de China (o de países de Europa del Este y alguna de Brasil), y no suele variar en el mismo día, lanzan el ataque desde la misma dirección IP con robots autómatas. No es un "ataque", yo diría que más bien son las "molestias" habituales de tener servicios abiertos accesibles desde Internet.
Sí es un ataque... son redes de bots que se dedican a eso. Cuando encuentran paso lo reportan al "dueño", que probablemente no es ni siquiera el del ordenador atacante. A partir de entonces tu ordenador se suma a la red de bots, en este caso para enviar spam. Es serio, no los minusvalores.
No, claro, por eso tengo configurado el cortafuegos ;-) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-06-04 22:32, Camaleón wrote:
El Fri, 04 Jun 2010 22:11:00 +0200, Carlos E. R. escribió:
On 2010-06-04 21:04, Camaleón wrote:
Son "disuasorias" porque permiten el acceso a los recursos hasta cierto punto, es decir, permites al atacante "juguetear" con tu servidor. No son medidas de bloqueo directo.
Pero yo en ningún momento he hablado de medidas disuasorias.
Sí, cuando dices de usar el "mod_evasive" del Apache, por ejemplo. Eso es una medida de disuasión, no de bloqueo directo.
Es un ejemplo y no lo puse yo.
Sí, pero lo que te quiero decir es que ante ciertos ataques eso resulta ineficiente.
Para nada, la forma más eficaz de impedir el "goteo" el cerrar la llave de paso :-). Lo otro (lo que tú dices) sería cerrar el grifo pero como haya mucha presión, te revienta las cañerías de la casa >:-)
Y ante el tipo de ataques de los que yo hablo, muy eficaz.
Inservible, ya lo has leído en el enlace que he enviado antes.
Para nada, eso es un DoS. Yo no hablo de ataques DoS, no estoy recomendando la misma estrategia. Lo dice en el enlace que has puesto: “apache mod_evasive sucks as anti-ddos protection” Pero es que yo no estoy hablando de ataques de denegación de servicio.
A ver ¿quiénes de los "emperrados" tenemos un servidor expuesto? Yo, en mi caso me fríen el servidor POP3 (cyrus) con intentos de acceso (ataques de diccionario) para adivinar el nombre de usuario/contraseña y después usarlo para poder enviar spam a través de mi Postfix, "baipaseando" el "smtp auth".
Pero eso es otro tipo de ataque, hablábamos de apache.
Son situaciones reales, muy similares y que requieren las mismas medidas.
No mucho. Detectar un ataque al apache para pillar un agujero conocido en el IIS es distinto de ver en el log "wrong user". En el caso del apache tienes que analizar las cadenas que llegan y los errores producidos para saber que te están atacando.
Pues mira, "algo" podría sacar información del cyrus, detectar posibles ataques de diccionario, y bloquear esa IP en el cortafuegos. Es el mismo concepto del que hablo.
Ya lo hace el cortafuegos. Yo quiero que el Cyrus se encargue de gestionar el correo que para lo otro ya tengo "la caballería". Te recuerdo la filosofía de linux: muchos programitas pero especializados :-)
El cortafuegos no va a saber que el cyrus ha denegado la conexión por contraseña errónea. Eso se lo dices tu.
(...)
Y siguiendo con lo mismo, ese que dices es un ataque "lento".
Los ataques que recibo son lentos. Lo que se ve en las películas es otra cosa :-).
¿Que películas? :-?
(...)
Si te hacen un ataque lento tienes que detectarlo en los logs, o con herramientas espécificas o módulos del daemon atacado hechos para ese objeto. Es un tipo de ataque distinto de un DoS y la defensa es distinta.
Con iptables y una regla de "drop".
Para nada. ¡Pero que manía! El IPtables no tiene idea de qué IPs bloquear a no ser que tu se lo digas después de obtener esa información por otro método. IPtables a secas y automáticamente no hace nada de eso. A ver, dime tú que regla IPtables añades para evitar los ataques de diccionario al Cyrus. Sin saber las IPs.
Te puedo dar las direcciones IP de mis atacantes cuando quieras. Todo queda registrado. Esas direcciones IP se pueden bloquear directamente metiéndolas manualmente en iptables para que las rechace el cortafuegos o mejor aún, un bloque de red completo. O puedes crear un script para que añada todas esas direcciones a la regla de iptables automáticamente.
Y esos scripts existen. Pero el tipo de ataque que has descrito contra tu POP3 no es un DoS, es un ataque lento buscando vulnerabilidades. Necesitas algo que automáticamente los detecte y bloquee, sin tener que mirar tú en el log, y espécifico contra ataques a ese servicio.
Es el tipo de ataque común que verás en el 90% de los servidores web. A diario.
Ya lo se.
Los ataques más habituales que recibo suelen seguir un mismo patrón: direcciones IP de China (o de países de Europa del Este y alguna de Brasil), y no suele variar en el mismo día, lanzan el ataque desde la misma dirección IP con robots autómatas. No es un "ataque", yo diría que más bien son las "molestias" habituales de tener servicios abiertos accesibles desde Internet.
Sí es un ataque... son redes de bots que se dedican a eso. Cuando encuentran paso lo reportan al "dueño", que probablemente no es ni siquiera el del ordenador atacante. A partir de entonces tu ordenador se suma a la red de bots, en este caso para enviar spam. Es serio, no los minusvalores.
No, claro, por eso tengo configurado el cortafuegos ;-)
¿Y como te cierra el cortafuegos las nuevas IPs que aparecen cada instante, sin que se las pongas tu? 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. Háblame de métodos automáticos sin intervención que bloqueen los ataques de diccionario al pop3, u ataques de buscar agujeros en un apache, o otro tipo de ataques lentos contra otro daemon. Que no tienen que ver contra los ataques masivos, son otra cosa. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkwJh4AACgkQU92UU+smfQUyiACgkL3gvemIL6U51i5K28uuqbU4 /EoAoITB2GKKzs3CZmwrmIMxp/KEpM5W =6MD1 -----END PGP SIGNATURE----- -- 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
El Sat, 05 Jun 2010 01:08:48 +0200, Carlos E. R. escribió:
On 2010-06-04 22:32, Camaleón wrote:
Pero yo en ningún momento he hablado de medidas disuasorias.
Sí, cuando dices de usar el "mod_evasive" del Apache, por ejemplo. Eso es una medida de disuasión, no de bloqueo directo.
Es un ejemplo y no lo puse yo.
No, pero te aferraste a ese ejemplo como si fuera un salvavidas. ¿Quién dijo esto? "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 :-)
Para nada, la forma más eficaz de impedir el "goteo" el cerrar la llave de paso :-). Lo otro (lo que tú dices) sería cerrar el grifo pero como haya mucha presión, te revienta las cañerías de la casa >:-)
Y ante el tipo de ataques de los que yo hablo, muy eficaz.
Inservible, ya lo has leído en el enlace que he enviado antes.
Para nada, eso es un DoS. Yo no hablo de ataques DoS, no estoy recomendando la misma estrategia. Lo dice en el enlace que has puesto:
“apache mod_evasive sucks as anti-ddos protection”
Pero es que yo no estoy hablando de ataques de denegación de servicio.
Querrás decir que no estás hablando de "ataques distribuidos de denegación de servicio" o sea, ddos :-P
Son situaciones reales, muy similares y que requieren las mismas medidas.
No mucho.
Detectar un ataque al apache para pillar un agujero conocido en el IIS es distinto de ver en el log "wrong user". En el caso del apache tienes que analizar las cadenas que llegan y los errores producidos para saber que te están atacando.
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 >:-)
Pues mira, "algo" podría sacar información del cyrus, detectar posibles ataques de diccionario, y bloquear esa IP en el cortafuegos. Es el mismo concepto del que hablo.
Ya lo hace el cortafuegos. Yo quiero que el Cyrus se encargue de gestionar el correo que para lo otro ya tengo "la caballería". Te recuerdo la filosofía de linux: muchos programitas pero especializados :-)
El cortafuegos no va a saber que el cyrus ha denegado la conexión por contraseña errónea. Eso se lo dices tu.
Los cortafuegos de tipo SPI son capaces de reconocer el tipo de tráfico y actuar en consecuencia. 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) previamente identificados por parte de del administrador (tal como decía el OP), la medida más eficaz y realista es rechazar las conexiones desde la IP que lo genera de plano. Para eso tenemos iptables y para eso está susefirewall2 (y por cierto, aún no sabemos cómo hacerlo desde susefirewall2).
Y siguiendo con lo mismo, ese que dices es un ataque "lento".
Los ataques que recibo son lentos. Lo que se ve en las películas es otra cosa :-).
¿Que películas? :-?
Las que supongo que ves cuando dices que eso es un "ataque lento". 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).
Si te hacen un ataque lento tienes que detectarlo en los logs, o con herramientas espécificas o módulos del daemon atacado hechos para ese objeto. Es un tipo de ataque distinto de un DoS y la defensa es distinta.
Con iptables y una regla de "drop".
Para nada.
¡Pero que manía! El IPtables no tiene idea de qué IPs bloquear a no ser que tu se lo digas después de obtener esa información por otro método. IPtables a secas y automáticamente no hace nada de eso.
A ver, dime tú que regla IPtables añades para evitar los ataques de diccionario al Cyrus. Sin saber las IPs.
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é >>:-) A ver... ¿Cómo sabes qué te están atacando si no LEES los registros? Sí, el servicio puede ir un "poco lento" (te aseguro que NO es mi caso porque ese tipo de ataque no hace realmente daño, es sólo molesto. Causa mucho más impacto en los recursos del servidor gestionar el spam, por ejemplo :-/) pero no lo suficiente como pensar que te están friendo con algún script.
Sí es un ataque... son redes de bots que se dedican a eso. Cuando encuentran paso lo reportan al "dueño", que probablemente no es ni siquiera el del ordenador atacante. A partir de entonces tu ordenador se suma a la red de bots, en este caso para enviar spam. Es serio, no los minusvalores.
No, claro, por eso tengo configurado el cortafuegos ;-)
¿Y como te cierra el cortafuegos las nuevas IPs que aparecen cada instante, sin que se las pongas tu?
El cortafuegos que tengo es muy sencillo (el que viene con el router adsl), no me permite más que activar las medidas de ataque o bloquear direcciones IP (o bloques completos). Nada más. Si quiero añadir direcciones IP lo tengo que hacer manualmente, sí.
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 :-) 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.
Háblame de métodos automáticos sin intervención que bloqueen los ataques de diccionario al pop3, u ataques de buscar agujeros en un apache, o otro tipo de ataques lentos contra otro daemon.
Que no tienen que ver contra los ataques masivos, son otra cosa.
Tendrías que saber las posibilidades que ofrece un cortafuegos, un router o un IPS ya que hiciste, precisamente, un curso de redes de Cisco ¿o enseñaban cómo proteger apaches con "mod_evasive"? >:-) 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
Camaleón wrote:
El Sat, 05 Jun 2010 01:08:48 +0200, Carlos E. R. escribió:
On 2010-06-04 22:32, Camaleón wrote:
Pero yo en ningún momento he hablado de medidas disuasorias. Sí, cuando dices de usar el "mod_evasive" del Apache, por ejemplo. Eso es una medida de disuasión, no de bloqueo directo. Es un ejemplo y no lo puse yo.
No, pero te aferraste a ese ejemplo como si fuera un salvavidas. ¿Quién dijo esto?
"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 :-)
Para nada, la forma más eficaz de impedir el "goteo" el cerrar la llave de paso :-). Lo otro (lo que tú dices) sería cerrar el grifo pero como haya mucha presión, te revienta las cañerías de la casa >:-)
Y ante el tipo de ataques de los que yo hablo, muy eficaz. Inservible, ya lo has leído en el enlace que he enviado antes. Para nada, eso es un DoS. Yo no hablo de ataques DoS, no estoy recomendando la misma estrategia. Lo dice en el enlace que has puesto:
“apache mod_evasive sucks as anti-ddos protection”
Pero es que yo no estoy hablando de ataques de denegación de servicio.
Querrás decir que no estás hablando de "ataques distribuidos de denegación de servicio" o sea, ddos :-P
Son situaciones reales, muy similares y que requieren las mismas medidas. No mucho.
Detectar un ataque al apache para pillar un agujero conocido en el IIS es distinto de ver en el log "wrong user". En el caso del apache tienes que analizar las cadenas que llegan y los errores producidos para saber que te están atacando.
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 >:-)
Pues mira, "algo" podría sacar información del cyrus, detectar posibles ataques de diccionario, y bloquear esa IP en el cortafuegos. Es el mismo concepto del que hablo. Ya lo hace el cortafuegos. Yo quiero que el Cyrus se encargue de gestionar el correo que para lo otro ya tengo "la caballería". Te recuerdo la filosofía de linux: muchos programitas pero especializados :-) El cortafuegos no va a saber que el cyrus ha denegado la conexión por contraseña errónea. Eso se lo dices tu.
Los cortafuegos de tipo SPI son capaces de reconocer el tipo de tráfico y actuar en consecuencia.
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) previamente identificados por parte de del administrador (tal como decía el OP), la medida más eficaz y realista es rechazar las conexiones desde la IP que lo genera de plano. Para eso tenemos iptables y para eso está susefirewall2 (y por cierto, aún no sabemos cómo hacerlo desde susefirewall2).
Y siguiendo con lo mismo, ese que dices es un ataque "lento". Los ataques que recibo son lentos. Lo que se ve en las películas es otra cosa :-). ¿Que películas? :-?
Las que supongo que ves cuando dices que eso es un "ataque lento".
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).
Si te hacen un ataque lento tienes que detectarlo en los logs, o con herramientas espécificas o módulos del daemon atacado hechos para ese objeto. Es un tipo de ataque distinto de un DoS y la defensa es distinta. Con iptables y una regla de "drop". Para nada.
¡Pero que manía! El IPtables no tiene idea de qué IPs bloquear a no ser que tu se lo digas después de obtener esa información por otro método. IPtables a secas y automáticamente no hace nada de eso.
A ver, dime tú que regla IPtables añades para evitar los ataques de diccionario al Cyrus. Sin saber las IPs.
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é >>:-)
A ver... ¿Cómo sabes qué te están atacando si no LEES los registros? Sí, el servicio puede ir un "poco lento" (te aseguro que NO es mi caso porque ese tipo de ataque no hace realmente daño, es sólo molesto. Causa mucho más impacto en los recursos del servidor gestionar el spam, por ejemplo :-/) pero no lo suficiente como pensar que te están friendo con algún script.
Sí es un ataque... son redes de bots que se dedican a eso. Cuando encuentran paso lo reportan al "dueño", que probablemente no es ni siquiera el del ordenador atacante. A partir de entonces tu ordenador se suma a la red de bots, en este caso para enviar spam. Es serio, no los minusvalores. No, claro, por eso tengo configurado el cortafuegos ;-) ¿Y como te cierra el cortafuegos las nuevas IPs que aparecen cada instante, sin que se las pongas tu?
El cortafuegos que tengo es muy sencillo (el que viene con el router adsl), no me permite más que activar las medidas de ataque o bloquear direcciones IP (o bloques completos). Nada más. Si quiero añadir direcciones IP lo tengo que hacer manualmente, sí.
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 :-)
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.
Háblame de métodos automáticos sin intervención que bloqueen los ataques de diccionario al pop3, u ataques de buscar agujeros en un apache, o otro tipo de ataques lentos contra otro daemon.
Que no tienen que ver contra los ataques masivos, son otra cosa.
Tendrías que saber las posibilidades que ofrece un cortafuegos, un router o un IPS ya que hiciste, precisamente, un curso de redes de Cisco ¿o enseñaban cómo proteger apaches con "mod_evasive"? >:-)
Saludos,
Solo un apunte más porque ratifico todo lo dicho por Camelón (y no voy a repetir lo mismo con otras palabras): hay IPS en el mercado que se encargan de parar ataques basados en diccionario. El daemon que presta el servicio no se entera de absolutamente nada ... Mirad es muy sencillo: en seguridad el principal factor de riesgo son las personas. Si las empresas implantasen técnicamente soluciones adecuadas (aunque el decidir que solución es adecuada nos llevaría a un debate interminable) el 98% ataques no tendrían afectación ninguna. Ahora bien el 2% restante, con esos hay que tener pero que mucho mucho cuidado porque son gente que saben lo que buscan y lo que hacen. Ejemplo: suponed que teneis una empresa de logística que presta servicios de mercancias a terceros. Si tus clientes son supermercados, ¿que interés tiene esa información para terceros competidores? Probablemente ninguna. Ahora bien, si tu empresa de logísitica trabaja para un farmacéutica importante o bien el ejército, eso cambia y mucho las cosas. Un ataque contra tu infraestructura seria un ataque muy serio, coordinado y probablemente tenga éxito si no te has gastado un dineral. Esa es la diferencia. Las contramedidas se implementan dependiendo del activo a proteger. ¿Un ataque lento? No me preocupa lo más mínimo porque lo puedo controlar en cualquier momento y si me apuras hasta me puedo divertir un ratito con el atacante a jugar al gato y al ratón. ¿Sabeis lo divertiod que és hacer parecer a un firewall OpenBSD, por ejemplo, que es un Cisco ASA/PIX?? Os lo aseguro, os partirías de risa. ¿Un ataque basado en diccinario? Tampoco me preocupa. Esos ataques son controlables desde distintas capas de los dispositivos. Ahora bien, preocupaos de ataques que aparecen como peticiones legítimas, esos sí dan miedo. Lo demás en los tiempos que corren, son todos superables. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-06-05 a las 09:06 -0000, Camaleón escribió:
El Sat, 05 Jun 2010 01:08:48 +0200, Carlos E. R. escribió:
Pero yo en ningún momento he hablado de medidas disuasorias.
Sí, cuando dices de usar el "mod_evasive" del Apache, por ejemplo. Eso es una medida de disuasión, no de bloqueo directo.
Es un ejemplo y no lo puse yo.
No, pero te aferraste a ese ejemplo como si fuera un salvavidas. ¿Quién dijo esto?
"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.
medidas.
No mucho.
Detectar un ataque al apache para pillar un agujero conocido en el IIS es distinto de ver en el log "wrong user". En el caso del apache tienes que analizar las cadenas que llegan y los errores producidos para saber que te están atacando.
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. ...
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.
¿Que películas? :-?
Las que supongo que ves cuando dices que eso es un "ataque lento".
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.
Si te hacen un ataque lento tienes que detectarlo en los logs, o con herramientas espécificas o módulos del daemon atacado hechos para ese objeto. Es un tipo de ataque distinto de un DoS y la defensa es distinta.
Con iptables y una regla de "drop".
Para nada.
¡Pero que manía! El IPtables no tiene idea de qué IPs bloquear a no ser que tu se lo digas después de obtener esa información por otro método. IPtables a secas y automáticamente no hace nada de eso.
A ver, dime tú que regla IPtables añades para evitar los ataques de diccionario al Cyrus. Sin saber las IPs.
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.
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: 1) 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. 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.
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.
Háblame de métodos automáticos sin intervención que bloqueen los ataques de diccionario al pop3, u ataques de buscar agujeros en un apache, o otro tipo de ataques lentos contra otro daemon.
Que no tienen que ver contra los ataques masivos, son otra cosa.
Tendrías que saber las posibilidades que ofrece un cortafuegos, un router o un IPS ya que hiciste, precisamente, un curso de redes de Cisco ¿o enseñaban cómo proteger apaches con "mod_evasive"? >:-)
No. Si acaso en alguno de los avanzados, previo pago. Esos cursos sirven para muy poco. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwNV3cACgkQtTMYHG2NR9XqtACdFcEDmGCaM7sImpt1knvm2F+m CiMAnRCr0tj8yE944yP1f6G675KSfDpB =qEI7 -----END PGP SIGNATURE-----
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:
1) 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
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2010-05-31 a las 07:39 -0000, Monica BM escribió:
A mi me pasa algo parecido, estoy mirando información sobre ban2fail o denyhost....
esto lo qeu hace es que si se intenta varias veces, bloqueal la ip el tiempo qeu tu le digas!!!
Y... ¿como defines "intentar" en un servidor web? Porque un servidor web está para que te conectes miles de veces desde la misma IP si te hace falta, cada vez que refrescas la pagina, o si cien ordenadores de la misma empresa abren la pagina desde la misma IP de salida corporativa.
Es distinto en un servidor ssh en el que entras con contraseña. Es una sóla conexión rechazada.
Si bien es cierto lo que comenta Carlos, sí existen herramientas más o menos decentes en linux para la detección y/o evitar ataques tipo DoS o DDoS. La más fiable hasta la fecha es esta: http://cipherdyne.org/psad/download/. Creo que también existe un módulo para apache que acomete y evita este tipo de ataques, pero yo personalmente ni lo he probado. Creo que se llama mod_evassive. Aún así con las limitaciones que ofrece iptables respecto a otros firewalls, sobre todo OpenBSD PF, sí existe la opción de bloquear IP's según el numero de reintentos por segundo que se hagan contra cualquier tipo de servicio. El problema de esta solución es que se debe hilar muy pero que muy fino, ya que las IP's se almacenan en unas tablas del kernel y quedán bloqueadas hasta que el administrador no las "vacie". La mejor solución que hay para Linux ante problemas de este tipo es la instalación de un sensor IDS que envie las alertas al firewall y este ejecute el bloqueo. O bien instalar un IPS directamente ... cosa nada nada trivial para neófitos en la materia. Otra biuena opción si no nos queremos liar con IDS, que no son nada sencillos de confirgurar, es utilizar una herramienta tipo HIDS. Por ejemplo: OSSEC (http://www.ossec.net/). Esta herramienta se ocupará de "lanzar las órdenes" a iptables para que ejecute los bloqueos ...y esta herramienta es bastante fácil de instalar y configurar en la mayoria de entornos ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
Lo de intentar me refiero a qeu va a hacerlo pero no llega a conectarse, en mi caso por lo menos.... De hecho, la solución qeu tu le has dado es la misma que la mía o muy parecida.... Por poder, podrá hacerlo, pero claro, si alguien necesita entrar y salir varias veces de la web le va a banear la IP, así qeu de vez en cuando mira la ip que te ataca, comrpueba de donde es, sobre todo si es de china o sitios de alto ataque y banea por rangos de ip, es mas laborioso, pero es lo mas efectivo. Si se te dan bien los scripts, siempre te lo podrás automatizar!! Un saludo. ----- Mensaje original ---- De: Carlos E. R. <robin.listas@telefonica.net> Para: OS-es <opensuse-es@opensuse.org> Enviado: lun,31 mayo, 2010 12:08 Asunto: Re: [opensuse-es] firewall -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-05-31 a las 07:39 -0000, Monica BM escribió:
A mi me pasa algo parecido, estoy mirando información sobre ban2fail o denyhost....
esto lo qeu hace es que si se intenta varias veces, bloqueal la ip el tiempo qeu tu le digas!!!
Y... ¿como defines "intentar" en un servidor web? Porque un servidor web está para que te conectes miles de veces desde la misma IP si te hace falta, cada vez que refrescas la pagina, o si cien ordenadores de la misma empresa abren la pagina desde la misma IP de salida corporativa. Es distinto en un servidor ssh en el que entras con contraseña. Es una sóla conexión rechazada. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwDiqAACgkQtTMYHG2NR9WxLACfdc6uSyplRNleNwiXjoaGqaf8 mN8An0zq2+86vFZOcEb0Hfb7V29fJ7Wy =qwyp -----END PGP SIGNATURE----- -- 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
Monica BM wrote:
Lo de intentar me refiero a qeu va a hacerlo pero no llega a conectarse, en mi caso por lo menos....
De hecho, la solución qeu tu le has dado es la misma que la mía o muy parecida....
Por poder, podrá hacerlo, pero claro, si alguien necesita entrar y salir varias veces de la web le va a banear la IP, así qeu de vez en cuando mira la ip que te ataca, comrpueba de donde es, sobre todo si es de china o sitios de alto ataque y banea por rangos de ip, es mas laborioso, pero es lo mas efectivo.
Si se te dan bien los scripts, siempre te lo podrás automatizar!!
Un saludo.
No necesitas hacer un script para iptables. Iptables ya incorpora la función de hacer eso. Ejmplos: http://www.cyberciti.biz/faq/iptables-connection-limits-howto/ http://www.cyberciti.biz/tips/howto-limit-linux-syn-attacks.html http://www.debian-administration.org/articles/187 http://www.hikaro.com/linux/linux-iptables-to-block-syn-flood-attacks.html Ahora bien, hay que saber lo que se está haciendo en todo momento ... Si es un servidor "casero" no hay problema, basta con el prueba y error si no se tienen muchos conocimientos ... Pero si es un servidor de empresa, mucho cuidadito con lo que se hace... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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
El Domingo 30 Mayo 2010, koxkorrita escribió:
hola
me están dando caña al apache desde ciertas ips.
he visto, y estoy haciendo pruebas, que se puede bloquear temporalmente ips usando el firewall (iptables)?
no logro hacerlo.
me podéis echar una mano?
gracias
* Utiliza htaccess y mod_evasive de apache o proxys o todos, iptables no es apropiado ni efectivo, no trabaja a nivel de aplicacion aunque existan algunos modulos que lo pretendan y aqui el problema es paginas inexistentes, robots buscando acceso directo a los cms, o buscando problemas en la base de datos y otras cuestiones que es apache quien sabe del asunto, del error y la utilizacion de expresiones mas comunes, lo que es y lo que no es razonable, ya que el servicio si ha de poder contestar a lo legitimo y cancelar el servicio ante un DDOS en toda regla, ya que supongo que no dispondras de servidores de sacrificio a los que poder redireccionar lo catalogado como malo. * en cuanto a denyhosts esta orientado a ssh, quiero decir que deduce el problema de los intentos ssh y despues bloquear ssh o todo a traves de tcp wrappers, pero la deteccion no es por apache, fail2ban mas o menos los mismo solo que en este caso utiliza una regla de denegacion de iptables. * La denegacion por ip en htaccess por ejemplo es una cuestion puntual y un numero relativamente pequeño de ip o rango y puntualmente en el tiempo no es cuestion de estar metiendo ip's sistematicamente .
participants (6)
-
Camaleón -
carlopmart -
Carlos E. R. -
jose maria -
koxkorrita -
Monica BM