Re: [CentOS-es] Proteger http con fail2ban
Yo estaba igual los chino y rusos queriendo usar mi servidor de correo, aplicaron de todo, con fail2ban, hice una lista de ip las banee todas con el shorewall y mas nunca tuve problemas, lo importante es revisar los logs, y ver todos los ataques, eso es fundamental, cuando los baneas o les mandas msgs de baneos o de intentos por ssh o ftp soeces ya no lo intentan mas, todo esta en ponerse paranoico, Saludos, El 3 de octubre de 2013 11:06, Carlos Tirado Elgueta < carlos.tir...@gmail.com> escribió: > A mi por lo menos me ha estado funcionando muy bien el CSF para los > SYN_FLOOD, conexiones múltiples y exceso de peticiones. > > Llevan 4 dias atacando uno de nuestros webserver y el primer dia lo > tumbaron 3 veces, hasta que aplicamos parametros respectivos en CSF (que > finalmente lo traduce a IPTABLES). > > Saludos! > > > El 2 de octubre de 2013 20:17, David González Romero > escribió: > > > DDOS es muy complejo de poder parar CSF es una variante, otra > mod_security; > > la tarcera no seas SysAdmin así te evitas dolores de cabeza Pero ya > que > > estás "enfermo" como nosotros, escucha consejo para que llegues a viejo. > > > > Mod_security, Fail2Ban usalo más bien en otra area. IPtables bien duro > para > > que pueda asegurarte un poquito y así poco a poco podrás ir teniendo tu > > propio librito sobre Seguridad de la que no tenemos que saberlo todo 100% > > > > Saludos, > > David > > > > > > El 2 de octubre de 2013 14:14, Carlos Tirado Elgueta < > > carlos.tir...@gmail.com> escribió: > > > > > yo uso para eso, incluyendo DDoS y demases, CSF ( > > > http://configserver.com/cp/csf.html) > > > > > > > > > Slds > > > > > > > > > El 2 de octubre de 2013 15:06, Rodrigo Pichiñual Norin < > > > rodrigo.pichin...@gmail.com> escribió: > > > > > > > Un ataque propiamente tal no...si no que una sobre carga de la > > > > webusuarios virtuales que acceden simultaneamente dentro de un > > lapsus > > > > corto de tiempo, de manera que hagan colapsar o relentarizar la web. > > > > > > > > a eso me refiero...=) > > > > > > > > gracias > > > > > > > > > > > > El 2 de octubre de 2013 13:58, angel jauregui < > darkdiabl...@gmail.com > > > > >escribió: > > > > > > > > > Con SSH la manera que reconoces un intento de ataque es cuando > > existen > > > > > FALLOS en el login, y esto repetidas veces. > > > > > > > > > > Dime cual te imaginas seria el ataque en Apache ? si lo > analizas, > > > en > > > > > realidad cualquier consulta puede ser un ataque o bien no serlo. > > Muchos > > > > > podrian decir "la comilla simple", pero que tal si en la web tienen > > un > > > > > producto en ingles que lleva comilla simple ?, entonces caerias en > > que > > > > esa > > > > > comilla en ese caso no representa un ataque. > > > > > > > > > > Innvestiga mod_security, es lo mejor.. > > > > > > > > > > Fail2ban es recomendable para servicios que requieren una > > > autentificacion > > > > > al servicio: ssh, ftp, tftp, smtp, pop, etc... > > > > > > > > > > Saludos ! > > > > > > > > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 12:48, Rodrigo Pichiñual Norin < > > > > > rodrigo.pichin...@gmail.com> escribió: > > > > > > > > > > > m si pero http con fail2ban??? sabes?? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 13:43, David González Romero > > > > > > escribió: > > > > > > > > > > > > > Rodrigo!! > > > > > > > > > > > > > > Esta muy bien, pero la mejor protección que puedes hacer para > tu > > > SSH > > > > es > > > > > > > cambiar el puerto de escucha. en el /etc/ssh/sshd_config > > > > > > > > > > > > > > Port 6541 > > > > > > > > > > > > > > Asi evitas que los boots se pongan a scanear al respecto. > Puedes > > > > > entonces > > > > > > > con fail2ban proteger ese puerto. Y luego IPtables, si no > puedes > > > > > cambiar > > > > > > tu > > > > > > > puerto SSH sería entonces prudente aceptar conecciones SSH > desde > > IP > > > > > > > conocidas en tu server. > > > > > > > > > > > > > > De cualquier forma una de las maneras más fuertes de proteger > > > Apache > > > > es > > > > > > > mod_security. > > > > > > > > > > > > > > Saludos, > > > > > > > David > > > > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 13:14, Rodrigo Pichiñual Norin < > > > > > > > rodrigo.pichin...@gmail.com> escribió: > > > > > > > > > > > > > > > Hola a todos. > > > > > > > > > > > > > > > > > > > > > > > > Tengo instalado fail2ban en centos 6.3 > > > > > > > > > > > > > > > > Logre entender como proteger SSH en caso de ataques de fuerza > > > > bruta. > > > > > > > > > > > > > > > > > > > > > > > > banntime=600 > > > > > > > > > > > > > > > > [ssh-iptables] > > > > > > > > enabled = true > > > > > > > > filter = sshd > > > > > > > > action = iptables[name=SSH, port=ssh, protocol=tcp] > > > > > > > > mail-whois[name=SSH, dest=mim...@dominio.cl, > > > > > > > > sender=fail2ban@ > > > > > > > > dominio.cl] > > > > > > > > logpath = /var/log/secure > > > > > > >
Re: [CentOS-es] Proteger http con fail2ban
A mi por lo menos me ha estado funcionando muy bien el CSF para los SYN_FLOOD, conexiones múltiples y exceso de peticiones. Llevan 4 dias atacando uno de nuestros webserver y el primer dia lo tumbaron 3 veces, hasta que aplicamos parametros respectivos en CSF (que finalmente lo traduce a IPTABLES). Saludos! El 2 de octubre de 2013 20:17, David González Romero escribió: > DDOS es muy complejo de poder parar CSF es una variante, otra mod_security; > la tarcera no seas SysAdmin así te evitas dolores de cabeza Pero ya que > estás "enfermo" como nosotros, escucha consejo para que llegues a viejo. > > Mod_security, Fail2Ban usalo más bien en otra area. IPtables bien duro para > que pueda asegurarte un poquito y así poco a poco podrás ir teniendo tu > propio librito sobre Seguridad de la que no tenemos que saberlo todo 100% > > Saludos, > David > > > El 2 de octubre de 2013 14:14, Carlos Tirado Elgueta < > carlos.tir...@gmail.com> escribió: > > > yo uso para eso, incluyendo DDoS y demases, CSF ( > > http://configserver.com/cp/csf.html) > > > > > > Slds > > > > > > El 2 de octubre de 2013 15:06, Rodrigo Pichiñual Norin < > > rodrigo.pichin...@gmail.com> escribió: > > > > > Un ataque propiamente tal no...si no que una sobre carga de la > > > webusuarios virtuales que acceden simultaneamente dentro de un > lapsus > > > corto de tiempo, de manera que hagan colapsar o relentarizar la web. > > > > > > a eso me refiero...=) > > > > > > gracias > > > > > > > > > El 2 de octubre de 2013 13:58, angel jauregui > > >escribió: > > > > > > > Con SSH la manera que reconoces un intento de ataque es cuando > existen > > > > FALLOS en el login, y esto repetidas veces. > > > > > > > > Dime cual te imaginas seria el ataque en Apache ? si lo analizas, > > en > > > > realidad cualquier consulta puede ser un ataque o bien no serlo. > Muchos > > > > podrian decir "la comilla simple", pero que tal si en la web tienen > un > > > > producto en ingles que lleva comilla simple ?, entonces caerias en > que > > > esa > > > > comilla en ese caso no representa un ataque. > > > > > > > > Innvestiga mod_security, es lo mejor.. > > > > > > > > Fail2ban es recomendable para servicios que requieren una > > autentificacion > > > > al servicio: ssh, ftp, tftp, smtp, pop, etc... > > > > > > > > Saludos ! > > > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 12:48, Rodrigo Pichiñual Norin < > > > > rodrigo.pichin...@gmail.com> escribió: > > > > > > > > > m si pero http con fail2ban??? sabes?? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 13:43, David González Romero > > > > > escribió: > > > > > > > > > > > Rodrigo!! > > > > > > > > > > > > Esta muy bien, pero la mejor protección que puedes hacer para tu > > SSH > > > es > > > > > > cambiar el puerto de escucha. en el /etc/ssh/sshd_config > > > > > > > > > > > > Port 6541 > > > > > > > > > > > > Asi evitas que los boots se pongan a scanear al respecto. Puedes > > > > entonces > > > > > > con fail2ban proteger ese puerto. Y luego IPtables, si no puedes > > > > cambiar > > > > > tu > > > > > > puerto SSH sería entonces prudente aceptar conecciones SSH desde > IP > > > > > > conocidas en tu server. > > > > > > > > > > > > De cualquier forma una de las maneras más fuertes de proteger > > Apache > > > es > > > > > > mod_security. > > > > > > > > > > > > Saludos, > > > > > > David > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 13:14, Rodrigo Pichiñual Norin < > > > > > > rodrigo.pichin...@gmail.com> escribió: > > > > > > > > > > > > > Hola a todos. > > > > > > > > > > > > > > > > > > > > > Tengo instalado fail2ban en centos 6.3 > > > > > > > > > > > > > > Logre entender como proteger SSH en caso de ataques de fuerza > > > bruta. > > > > > > > > > > > > > > > > > > > > > banntime=600 > > > > > > > > > > > > > > [ssh-iptables] > > > > > > > enabled = true > > > > > > > filter = sshd > > > > > > > action = iptables[name=SSH, port=ssh, protocol=tcp] > > > > > > > mail-whois[name=SSH, dest=mim...@dominio.cl, > > > > > > > sender=fail2ban@ > > > > > > > dominio.cl] > > > > > > > logpath = /var/log/secure > > > > > > > maxretry = 5 > > > > > > > > > > > > > > Esto bloquea a una ip el accesso mediante SSH después de 5 > > intentos > > > > > > > fallidos (bloque la ip durante 600 seg). > > > > > > > > > > > > > > lo probé y funciona. > > > > > > > > > > > > > > pero ahora quiero proteger mi servidor web (apache httpd). > > > > > > > > > > > > > > pero no se como hacerlo. > > > > > > > > > > > > > > en ssh el maxretry es 5(intentos antes de bloquear) en un > > servidor > > > > web > > > > > > esto > > > > > > > debería ser mucho mas mayor (nro de transacciones de un web > > server > > > > > > siempre > > > > > > > es mas alto) > > > > > > > > > > > > > > > > > > > > > Orientación..gracias > > > > > > > ___ > > > > > > > CentOS-es mailing list > > > > > > > CentOS-es@centos.org > > > >
Re: [CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
hola pero desde el punto de vista del servidor DNS en lo que respecta de la configuracion como puedo evitar esos ataques DDoS y por medio de iptables sin necesidad de utilizar el software fail2ban, tienen alguna configuracion al detalle de este tipo de configuracion saludos El 3 de octubre de 2013 08:46, David González Romero escribió: > DNS tiene dos cosas: > 1- Tener una configuracion CERO recursividad y tratar de hacer FORWARD a > todo lo que no puedas solucionar. > 2- NUNCA permitir conexion tcp al puerto 53 y si tienes que definir SLAVES > de tus zonas, intenta configurar bien las zonas. > > Por demás: > iptables -A INPUT -s 0/0 -dport 53 -p tcp -j DROP o REJECT > iptables -A INPUT -s 0/0 -dport 53 -p udp -j ACCEPT > > Y claro muy importante "yum update" o "aptitude update" con frecuencia > > Saludos, > David > > > El 3 de octubre de 2013 10:39, Elio Bastias, Project Managers < > elio.bast...@gmail.com> escribió: > > > Rodrigo, > > Buenos Días, > > Como estas, > > te paso un link, en donde te explica un poco mas detallado cada una de > las > > líneas, y otros temas: > > > > http://www.fail2ban.org/wiki/index.php/Talk:Apache > > *básicamente apache-badbots* Bloquea por iptables los hosts que se > conectan > > haciendo uso de un “User Agent” sospechoso, y nos envia un mail para > > avisarnos. > > > > te paso algunos ejemplos: > > > > *apache-tcpwrapper:* Bloquea con el fichero /etc/hosts.deny los hosts que > > se intentan conectar a dominios protegidos con contraseña (estos fallos > de > > autenticación aparecen en el error_log)*[* > > > > *apache-tcpwrapper]* > > > > enabled = true > > > > filter = apache-auth > > action = hostsdeny > > logpath = /var/www/vhosts/*/statistics/logs/error_log > > maxretry = 6 > > > > *apache-badbots* Bloquea por iptables los hosts que se conectan haciendo > > uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos.*** > > *[apache-badbots] > > enabled = true > > filter = apache-badbots > > action = iptables-multiport[name=BadBots, port="http,https"] > >sendmail-buffered[name=BadBots, lines=5, dest=y...@mail.com] > > logpath = /var/www/vhosts/*/statistics/logs/access_log > > bantime = 172800 > > maxretry = 1 > > > > # Para prevenir ataques de inyeccion de codigo > > > > *php-url-fopen*. Bloqueamos los hosts, que intentan una inyeccion de > código > > del tipo: GET /index.php?n=http://www.dominio.com/fichero.htm > > [php-url-fopen] > > enabled = true > > port = http,https > > filter = php-url-fopen > > logpath = /var/www/vhosts/*/statistics/logs/access_log > > maxretry = 1 > > > > # Evitamos ataques de ips que accedan a urls que contengan passthru o > > system o similares > > > > *apache-hacks*: Bloquea los hosts que acceden a urls sospechosas, > haciendo > > un SCAN o directamente acceden a urls intentando inyectar llamadas al > > sistema desde php (system, passthru…) esta regla se va rellenando con las > > expresiones que vamos encontrando en los logs, al final del post, > > adjuntamos el contenido del filtro en nuestro caso. > > [apache-hacks] > > enabled = true > > port = http,https > > filter = apache-hacks > > action = iptables-multiport[name=AtaqueApache, > > port="http,https"] > >sendmail-buffered[name=AtaqueApache, lines=5, dest= > y...@mail.com > > ] > > logpath = /var/www/vhosts/*/statistics/logs/access_log > > maxretry = 3 > > > > En el ultimo caso, hemos creado un fichero apache-hacks.conf en el > > directorio filters.d, para empezar podemos agregar entradas como estas: > > > > failregex = ^ -.*”(GET|POST).*\?.*passthru.* HTTP\/.*$ > > ^ -.*”(GET|POST).*\?.*system.* HTTP\/.*$ > > > > Y mas adelante agregar nuevas reglas. > > > > Con estos 4 casos, podemos evitar algunos de los intentos de ataque mas > > comunes, pero no podemos ni por un momento pensar que con solo aplicar > esto > > estamos a salvo. > > > > > > Saludos, > > > > > > > > > > > > > > 2013/10/3 Rodrigo Pichiñual Norin > > > > > Elio, > > > > > > me puedes explicar este trozo de codigo y para que sirve? > > > > > > [apache-badbots] > > > > > > enabled = true > > > filter = apache-badbots > > > action = iptables-multiport[name=BadBots, port="http,https"] > > >sendmail-buffered[name=BadBots, lines=5, dest=tu email] > > > logpath = /home/*/logs/access.log > > > bantime = 172800 > > > maxretry = 1 > > > > > > > > > > > > esta habilidato apache-badbots (enabled = true) > > > utiliza el filtro apache-badbots ubicado en el directorio filter.d > > > action = ? > > > logpath= donde busca los log para actuar > > > bantime = ? ( se que es timepo de banneo) > > > maxretry = ? ( un solo intent ) > > > > > > > > > gracias > > > > > > > > > 2013/10/3 Elio Bastias, Project Managers > > > > > > > Buenos Días, > > > > Ignacio, > > > > Hay muchas formas para poder evitarlos: > > > > 1) Una es colocar un router con algún IDS, tipo Snort, ú otro para > que > > > la > > > > carga se haga en el router y no en el servido
Re: [CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
DNS tiene dos cosas: 1- Tener una configuracion CERO recursividad y tratar de hacer FORWARD a todo lo que no puedas solucionar. 2- NUNCA permitir conexion tcp al puerto 53 y si tienes que definir SLAVES de tus zonas, intenta configurar bien las zonas. Por demás: iptables -A INPUT -s 0/0 -dport 53 -p tcp -j DROP o REJECT iptables -A INPUT -s 0/0 -dport 53 -p udp -j ACCEPT Y claro muy importante "yum update" o "aptitude update" con frecuencia Saludos, David El 3 de octubre de 2013 10:39, Elio Bastias, Project Managers < elio.bast...@gmail.com> escribió: > Rodrigo, > Buenos Días, > Como estas, > te paso un link, en donde te explica un poco mas detallado cada una de las > líneas, y otros temas: > > http://www.fail2ban.org/wiki/index.php/Talk:Apache > *básicamente apache-badbots* Bloquea por iptables los hosts que se conectan > haciendo uso de un “User Agent” sospechoso, y nos envia un mail para > avisarnos. > > te paso algunos ejemplos: > > *apache-tcpwrapper:* Bloquea con el fichero /etc/hosts.deny los hosts que > se intentan conectar a dominios protegidos con contraseña (estos fallos de > autenticación aparecen en el error_log)*[* > > *apache-tcpwrapper]* > > enabled = true > > filter = apache-auth > action = hostsdeny > logpath = /var/www/vhosts/*/statistics/logs/error_log > maxretry = 6 > > *apache-badbots* Bloquea por iptables los hosts que se conectan haciendo > uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos.*** > *[apache-badbots] > enabled = true > filter = apache-badbots > action = iptables-multiport[name=BadBots, port="http,https"] >sendmail-buffered[name=BadBots, lines=5, dest=y...@mail.com] > logpath = /var/www/vhosts/*/statistics/logs/access_log > bantime = 172800 > maxretry = 1 > > # Para prevenir ataques de inyeccion de codigo > > *php-url-fopen*. Bloqueamos los hosts, que intentan una inyeccion de código > del tipo: GET /index.php?n=http://www.dominio.com/fichero.htm > [php-url-fopen] > enabled = true > port = http,https > filter = php-url-fopen > logpath = /var/www/vhosts/*/statistics/logs/access_log > maxretry = 1 > > # Evitamos ataques de ips que accedan a urls que contengan passthru o > system o similares > > *apache-hacks*: Bloquea los hosts que acceden a urls sospechosas, haciendo > un SCAN o directamente acceden a urls intentando inyectar llamadas al > sistema desde php (system, passthru…) esta regla se va rellenando con las > expresiones que vamos encontrando en los logs, al final del post, > adjuntamos el contenido del filtro en nuestro caso. > [apache-hacks] > enabled = true > port = http,https > filter = apache-hacks > action = iptables-multiport[name=AtaqueApache, > port="http,https"] >sendmail-buffered[name=AtaqueApache, lines=5, dest=y...@mail.com > ] > logpath = /var/www/vhosts/*/statistics/logs/access_log > maxretry = 3 > > En el ultimo caso, hemos creado un fichero apache-hacks.conf en el > directorio filters.d, para empezar podemos agregar entradas como estas: > > failregex = ^ -.*”(GET|POST).*\?.*passthru.* HTTP\/.*$ > ^ -.*”(GET|POST).*\?.*system.* HTTP\/.*$ > > Y mas adelante agregar nuevas reglas. > > Con estos 4 casos, podemos evitar algunos de los intentos de ataque mas > comunes, pero no podemos ni por un momento pensar que con solo aplicar esto > estamos a salvo. > > > Saludos, > > > > > > > 2013/10/3 Rodrigo Pichiñual Norin > > > Elio, > > > > me puedes explicar este trozo de codigo y para que sirve? > > > > [apache-badbots] > > > > enabled = true > > filter = apache-badbots > > action = iptables-multiport[name=BadBots, port="http,https"] > >sendmail-buffered[name=BadBots, lines=5, dest=tu email] > > logpath = /home/*/logs/access.log > > bantime = 172800 > > maxretry = 1 > > > > > > > > esta habilidato apache-badbots (enabled = true) > > utiliza el filtro apache-badbots ubicado en el directorio filter.d > > action = ? > > logpath= donde busca los log para actuar > > bantime = ? ( se que es timepo de banneo) > > maxretry = ? ( un solo intent ) > > > > > > gracias > > > > > > 2013/10/3 Elio Bastias, Project Managers > > > > > Buenos Días, > > > Ignacio, > > > Hay muchas formas para poder evitarlos: > > > 1) Una es colocar un router con algún IDS, tipo Snort, ú otro para que > > la > > > carga se haga en el router y no en el servidor DNS.- > > > 2) Podes utilizar fail2ban, en otro hilo estamos discutiendo algo > > similar, > > > te pego una de las posibles config que se puede hacer, esto es de uno > de > > > los foristas, para que te orientes: > > > > > > había un problema similar con unos de mi vps, al revisar los logs full > > > ataques, > > > pero con pocas cosas los detuve, te explico a ver que te sirve: > > > > > > 1.- SSH: Cambie el puerto por Defecto. > > > > > > 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista > > Negra > > > de Ips de Ataques). > > > > > > 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): > > >
Re: [CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
Rodrigo, Buenos Días, Como estas, te paso un link, en donde te explica un poco mas detallado cada una de las líneas, y otros temas: http://www.fail2ban.org/wiki/index.php/Talk:Apache *básicamente apache-badbots* Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos. te paso algunos ejemplos: *apache-tcpwrapper:* Bloquea con el fichero /etc/hosts.deny los hosts que se intentan conectar a dominios protegidos con contraseña (estos fallos de autenticación aparecen en el error_log)*[* *apache-tcpwrapper]* enabled = true filter = apache-auth action = hostsdeny logpath = /var/www/vhosts/*/statistics/logs/error_log maxretry = 6 *apache-badbots* Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos.*** *[apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port="http,https"] sendmail-buffered[name=BadBots, lines=5, dest=y...@mail.com] logpath = /var/www/vhosts/*/statistics/logs/access_log bantime = 172800 maxretry = 1 # Para prevenir ataques de inyeccion de codigo *php-url-fopen*. Bloqueamos los hosts, que intentan una inyeccion de código del tipo: GET /index.php?n=http://www.dominio.com/fichero.htm [php-url-fopen] enabled = true port = http,https filter = php-url-fopen logpath = /var/www/vhosts/*/statistics/logs/access_log maxretry = 1 # Evitamos ataques de ips que accedan a urls que contengan passthru o system o similares *apache-hacks*: Bloquea los hosts que acceden a urls sospechosas, haciendo un SCAN o directamente acceden a urls intentando inyectar llamadas al sistema desde php (system, passthru…) esta regla se va rellenando con las expresiones que vamos encontrando en los logs, al final del post, adjuntamos el contenido del filtro en nuestro caso. [apache-hacks] enabled = true port = http,https filter = apache-hacks action = iptables-multiport[name=AtaqueApache, port="http,https"] sendmail-buffered[name=AtaqueApache, lines=5, dest=y...@mail.com] logpath = /var/www/vhosts/*/statistics/logs/access_log maxretry = 3 En el ultimo caso, hemos creado un fichero apache-hacks.conf en el directorio filters.d, para empezar podemos agregar entradas como estas: failregex = ^ -.*”(GET|POST).*\?.*passthru.* HTTP\/.*$ ^ -.*”(GET|POST).*\?.*system.* HTTP\/.*$ Y mas adelante agregar nuevas reglas. Con estos 4 casos, podemos evitar algunos de los intentos de ataque mas comunes, pero no podemos ni por un momento pensar que con solo aplicar esto estamos a salvo. Saludos, 2013/10/3 Rodrigo Pichiñual Norin > Elio, > > me puedes explicar este trozo de codigo y para que sirve? > > [apache-badbots] > > enabled = true > filter = apache-badbots > action = iptables-multiport[name=BadBots, port="http,https"] >sendmail-buffered[name=BadBots, lines=5, dest=tu email] > logpath = /home/*/logs/access.log > bantime = 172800 > maxretry = 1 > > > > esta habilidato apache-badbots (enabled = true) > utiliza el filtro apache-badbots ubicado en el directorio filter.d > action = ? > logpath= donde busca los log para actuar > bantime = ? ( se que es timepo de banneo) > maxretry = ? ( un solo intent ) > > > gracias > > > 2013/10/3 Elio Bastias, Project Managers > > > Buenos Días, > > Ignacio, > > Hay muchas formas para poder evitarlos: > > 1) Una es colocar un router con algún IDS, tipo Snort, ú otro para que > la > > carga se haga en el router y no en el servidor DNS.- > > 2) Podes utilizar fail2ban, en otro hilo estamos discutiendo algo > similar, > > te pego una de las posibles config que se puede hacer, esto es de uno de > > los foristas, para que te orientes: > > > > había un problema similar con unos de mi vps, al revisar los logs full > > ataques, > > pero con pocas cosas los detuve, te explico a ver que te sirve: > > > > 1.- SSH: Cambie el puerto por Defecto. > > > > 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista > Negra > > de Ips de Ataques). > > > > 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): > > > > [DEFAULT] > > > > # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban > will > > not > > # ban a host which matches an address in this list. Several addresses can > > be > > # defined using space separator. > > ignoreip = tu ip. > > > > # "bantime" is the number of seconds that a host is banned. > > bantime = 36000 > > > > # A host is banned if it has generated "maxretry" during the last > > "findtime" > > # seconds. > > findtime = 600 > > > > # "maxretry" is the number of failures before a host get banned. > > maxretry = 3 > > > > # "backend" specifies the backend used to get files modification. > > # Available options are "pyinotify", "gamin", "polling" and "auto". > > # This option can be overridden in each jail as well. > > # > > # pyinotify: requires pyinotify (a file alteration monit
Re: [CentOS-es] Proteger http con fail2ban
Te dire busca en google hay muchas formas de proteger apache, te agrego dos links la mejor forma de hacerlo es probando con tus logs y configurarlo a tus necesidades, es lo que mas recomiendo: *apache-tcpwrapper:* Bloquea con el fichero /etc/hosts.deny los hosts que se intentan conectar a dominios protegidos con contraseña (estos fallos de autenticación aparecen en el error_log) *apache-badbots* Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos. Pondre dos links: http://apliweb.com/blog/fail2ban-evitando-ataques-en-nuestro-servidor-web http://garciavictor.blogspot.com/2012/11/fail2ban-en-debian-squeezy-wheezy.html 2013/10/3 Rodrigo Pichiñual Norin > Gracias Willmer > > me podrias explicar parte de este trozo de codigo. > > [apache-badbots] > > enabled = true > filter = apache-badbots > action = iptables-multiport[name=BadBots, port="http,https"] >sendmail-buffered[name=BadBots, lines=5, dest=tu email] > logpath = /home/*/logs/access.log > bantime = 172800 > maxretry = 1 > > > entiendo que esta habilitado (enabled) > el filtro que utiliza dentro de la carpete filter.d es apache-badbots > > peor el resto no lo tengo muy claro.. > > > gracias > > > 2013/10/3 Wilmer Arambula > > > Yo tenia un problema similar con mi vps, al revisar los logs full > ataques, > > pero con pocas cosas los detuve, te explico a ver que te sirve: > > > > 1.- SSH: Cambie el puerto por Defecto. > > > > 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista > Negra > > de Ips de Ataques). > > > > 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): > > > > [DEFAULT] > > > > # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban > > will not > > # ban a host which matches an address in this list. Several addresses can > > be > > # defined using space separator. > > ignoreip = tu ip. > > > > # "bantime" is the number of seconds that a host is banned. > > bantime = 36000 > > > > # A host is banned if it has generated "maxretry" during the last > > "findtime" > > # seconds. > > findtime = 600 > > > > # "maxretry" is the number of failures before a host get banned. > > maxretry = 3 > > > > # "backend" specifies the backend used to get files modification. > > # Available options are "pyinotify", "gamin", "polling" and "auto". > > # This option can be overridden in each jail as well. > > # > > # pyinotify: requires pyinotify (a file alteration monitor) to be > > installed. > > # If pyinotify is not installed, Fail2ban will use auto. > > # gamin: requires Gamin (a file alteration monitor) to be installed. > > # If Gamin is not installed, Fail2ban will use auto. > > # polling: uses a polling algorithm which does not require external > > libraries. > > # auto: will try to use the following backends, in order: > > # pyinotify, gamin, polling. > > backend = auto > > > > # "usedns" specifies if jails should trust hostnames in logs, > > # warn when reverse DNS lookups are performed, or ignore all hostnames > > in logs > > # > > # yes: if a hostname is encountered, a reverse DNS lookup will be > > performed. > > # warn: if a hostname is encountered, a reverse DNS lookup will be > > performed, > > #but it will be logged as a warning. > > # no:if a hostname is encountered, will not be used for banning, > > #but it will be logged as info. > > usedns = warn > > > > > > # This jail corresponds to the standard configuration in Fail2ban 0.6. > > # The mail-whois action send a notification e-mail with a whois request > > # in the body. > > > > [ssh-iptables] > > > > enabled = true > > filter = sshd > > action = iptables[name=SSH, port=ssh, protocol=tcp] > >sendmail-whois[name=SSH, dest=root, sender=tu email] > > logpath = /var/log/secure > > > > [proftpd-iptables] > > > > enabled = true > > filter = proftpd > > action = iptables[name=ProFTPD, port=ftp, protocol=tcp] > >sendmail-whois[name=ProFTPD, dest=tu email] > > logpath = /var/log/proftpd/access.log > > maxretry = 5 > > > > # This jail forces the backend to "polling". > > > > [sasl-iptables] > > > > enabled = true > > filter = sasl > > backend = polling > > action = iptables[name=sasl, port=smtp, protocol=tcp] > >sendmail-whois[name=sasl, dest=tu email] > > logpath = /var/log/maillog > > maxretry = 3 > > > > # Here we use TCP-Wrappers instead of Netfilter/Iptables. "ignoreregex" > is > > # used to avoid banning the user "myuser". > > > > > > [ssh-tcpwrapper] > > > > enabled = true > > filter = sshd > > action = hostsdeny > > sendmail-whois[name=SSH, dest=tu email] > > ignoreregex = for myuser from > > logpath = /var/log/secure > > > > # This jail demonstrates the use of wildcards in "logpath". > > # Moreover, it is possible to give other files on a new line. > > > > [apache-tcpwrapper] > > >
Re: [CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
Elio, me puedes explicar este trozo de codigo y para que sirve? [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port="http,https"] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 esta habilidato apache-badbots (enabled = true) utiliza el filtro apache-badbots ubicado en el directorio filter.d action = ? logpath= donde busca los log para actuar bantime = ? ( se que es timepo de banneo) maxretry = ? ( un solo intent ) gracias 2013/10/3 Elio Bastias, Project Managers > Buenos Días, > Ignacio, > Hay muchas formas para poder evitarlos: > 1) Una es colocar un router con algún IDS, tipo Snort, ú otro para que la > carga se haga en el router y no en el servidor DNS.- > 2) Podes utilizar fail2ban, en otro hilo estamos discutiendo algo similar, > te pego una de las posibles config que se puede hacer, esto es de uno de > los foristas, para que te orientes: > > había un problema similar con unos de mi vps, al revisar los logs full > ataques, > pero con pocas cosas los detuve, te explico a ver que te sirve: > > 1.- SSH: Cambie el puerto por Defecto. > > 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista Negra > de Ips de Ataques). > > 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): > > [DEFAULT] > > # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will > not > # ban a host which matches an address in this list. Several addresses can > be > # defined using space separator. > ignoreip = tu ip. > > # "bantime" is the number of seconds that a host is banned. > bantime = 36000 > > # A host is banned if it has generated "maxretry" during the last > "findtime" > # seconds. > findtime = 600 > > # "maxretry" is the number of failures before a host get banned. > maxretry = 3 > > # "backend" specifies the backend used to get files modification. > # Available options are "pyinotify", "gamin", "polling" and "auto". > # This option can be overridden in each jail as well. > # > # pyinotify: requires pyinotify (a file alteration monitor) to be > installed. > # If pyinotify is not installed, Fail2ban will use auto. > # gamin: requires Gamin (a file alteration monitor) to be installed. > # If Gamin is not installed, Fail2ban will use auto. > # polling: uses a polling algorithm which does not require external > libraries. > # auto: will try to use the following backends, in order: > # pyinotify, gamin, polling. > backend = auto > > # "usedns" specifies if jails should trust hostnames in logs, > # warn when reverse DNS lookups are performed, or ignore all hostnames in > logs > # > # yes: if a hostname is encountered, a reverse DNS lookup will be > performed. > # warn: if a hostname is encountered, a reverse DNS lookup will be > performed, > #but it will be logged as a warning. > # no:if a hostname is encountered, will not be used for banning, > #but it will be logged as info. > usedns = warn > > > # This jail corresponds to the standard configuration in Fail2ban 0.6. > # The mail-whois action send a notification e-mail with a whois request > # in the body. > > [ssh-iptables] > > enabled = true > filter = sshd > action = iptables[name=SSH, port=ssh, protocol=tcp] >sendmail-whois[name=SSH, dest=root, sender=tu email] > logpath = /var/log/secure > > [proftpd-iptables] > > enabled = true > filter = proftpd > action = iptables[name=ProFTPD, port=ftp, protocol=tcp] >sendmail-whois[name=ProFTPD, dest=tu email] > logpath = /var/log/proftpd/access.log > maxretry = 5 > > # This jail forces the backend to "polling". > > [sasl-iptables] > > enabled = true > filter = sasl > backend = polling > action = iptables[name=sasl, port=smtp, protocol=tcp] >sendmail-whois[name=sasl, dest=tu email] > logpath = /var/log/maillog > maxretry = 3 > > # Here we use TCP-Wrappers instead of Netfilter/Iptables. "ignoreregex" is > # used to avoid banning the user "myuser". > > > [ssh-tcpwrapper] > > enabled = true > filter = sshd > action = hostsdeny > sendmail-whois[name=SSH, dest=tu email] > ignoreregex = for myuser from > logpath = /var/log/secure > > # This jail demonstrates the use of wildcards in "logpath". > # Moreover, it is possible to give other files on a new line. > > [apache-tcpwrapper] > > enabled = true > filter = apache-auth > action = hostsdeny > logpath = /home/*/logs/*error.log >/home/*/logs/error.log > maxretry = 6 > > # The hosts.deny path can be defined with the "file" argument if it is > # not in /etc. > > [postfix-tcpwrapper] > > enabled = true > filter = postfix > action = iptables-multiport[name=postfix, port="110,995,143,993,25", > protocol=tcp] >sendmail-buffered[name=BadBots, lines=5, dest=tu email] > logpath = /var/log/maillog >
Re: [CentOS-es] Proteger http con fail2ban
Gracias Willmer me podrias explicar parte de este trozo de codigo. [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port="http,https"] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 entiendo que esta habilitado (enabled) el filtro que utiliza dentro de la carpete filter.d es apache-badbots peor el resto no lo tengo muy claro.. gracias 2013/10/3 Wilmer Arambula > Yo tenia un problema similar con mi vps, al revisar los logs full ataques, > pero con pocas cosas los detuve, te explico a ver que te sirve: > > 1.- SSH: Cambie el puerto por Defecto. > > 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista Negra > de Ips de Ataques). > > 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): > > [DEFAULT] > > # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban > will not > # ban a host which matches an address in this list. Several addresses can > be > # defined using space separator. > ignoreip = tu ip. > > # "bantime" is the number of seconds that a host is banned. > bantime = 36000 > > # A host is banned if it has generated "maxretry" during the last > "findtime" > # seconds. > findtime = 600 > > # "maxretry" is the number of failures before a host get banned. > maxretry = 3 > > # "backend" specifies the backend used to get files modification. > # Available options are "pyinotify", "gamin", "polling" and "auto". > # This option can be overridden in each jail as well. > # > # pyinotify: requires pyinotify (a file alteration monitor) to be > installed. > # If pyinotify is not installed, Fail2ban will use auto. > # gamin: requires Gamin (a file alteration monitor) to be installed. > # If Gamin is not installed, Fail2ban will use auto. > # polling: uses a polling algorithm which does not require external > libraries. > # auto: will try to use the following backends, in order: > # pyinotify, gamin, polling. > backend = auto > > # "usedns" specifies if jails should trust hostnames in logs, > # warn when reverse DNS lookups are performed, or ignore all hostnames > in logs > # > # yes: if a hostname is encountered, a reverse DNS lookup will be > performed. > # warn: if a hostname is encountered, a reverse DNS lookup will be > performed, > #but it will be logged as a warning. > # no:if a hostname is encountered, will not be used for banning, > #but it will be logged as info. > usedns = warn > > > # This jail corresponds to the standard configuration in Fail2ban 0.6. > # The mail-whois action send a notification e-mail with a whois request > # in the body. > > [ssh-iptables] > > enabled = true > filter = sshd > action = iptables[name=SSH, port=ssh, protocol=tcp] >sendmail-whois[name=SSH, dest=root, sender=tu email] > logpath = /var/log/secure > > [proftpd-iptables] > > enabled = true > filter = proftpd > action = iptables[name=ProFTPD, port=ftp, protocol=tcp] >sendmail-whois[name=ProFTPD, dest=tu email] > logpath = /var/log/proftpd/access.log > maxretry = 5 > > # This jail forces the backend to "polling". > > [sasl-iptables] > > enabled = true > filter = sasl > backend = polling > action = iptables[name=sasl, port=smtp, protocol=tcp] >sendmail-whois[name=sasl, dest=tu email] > logpath = /var/log/maillog > maxretry = 3 > > # Here we use TCP-Wrappers instead of Netfilter/Iptables. "ignoreregex" is > # used to avoid banning the user "myuser". > > > [ssh-tcpwrapper] > > enabled = true > filter = sshd > action = hostsdeny > sendmail-whois[name=SSH, dest=tu email] > ignoreregex = for myuser from > logpath = /var/log/secure > > # This jail demonstrates the use of wildcards in "logpath". > # Moreover, it is possible to give other files on a new line. > > [apache-tcpwrapper] > > enabled = true > filter = apache-auth > action = hostsdeny > logpath = /home/*/logs/*error.log >/home/*/logs/error.log > maxretry = 6 > > # The hosts.deny path can be defined with the "file" argument if it is > # not in /etc. > > [postfix-tcpwrapper] > > enabled = true > filter = postfix > action = iptables-multiport[name=postfix, port="110,995,143,993,25", > protocol=tcp] >sendmail-buffered[name=BadBots, lines=5, dest=tu email] > logpath = /var/log/maillog > maxretry = 3 > > # Ban hosts which agent identifies spammer robots crawling the web > # for email addresses. The mail outputs are buffered. > > [dovecot] > > enabled = true > filter = dovecot > action = iptables-multiport[name=Dovecot, port="110,995,143,993,25", > protocol=tcp] > sendmail-whois[name=Fail2Dovecot, lines=5, dest=tu email] > logpath = /var/log/dovecot.log > maxretry = 3 > > [apache-badbots] > > enabled = true > filter = apache-badbots > action = iptables-multiport[name=BadBots, p
Re: [CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
Buenos Días, Ignacio, Hay muchas formas para poder evitarlos: 1) Una es colocar un router con algún IDS, tipo Snort, ú otro para que la carga se haga en el router y no en el servidor DNS.- 2) Podes utilizar fail2ban, en otro hilo estamos discutiendo algo similar, te pego una de las posibles config que se puede hacer, esto es de uno de los foristas, para que te orientes: había un problema similar con unos de mi vps, al revisar los logs full ataques, pero con pocas cosas los detuve, te explico a ver que te sirve: 1.- SSH: Cambie el puerto por Defecto. 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista Negra de Ips de Ataques). 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): [DEFAULT] # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = tu ip. # "bantime" is the number of seconds that a host is banned. bantime = 36000 # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 600 # "maxretry" is the number of failures before a host get banned. maxretry = 3 # "backend" specifies the backend used to get files modification. # Available options are "pyinotify", "gamin", "polling" and "auto". # This option can be overridden in each jail as well. # # pyinotify: requires pyinotify (a file alteration monitor) to be installed. # If pyinotify is not installed, Fail2ban will use auto. # gamin: requires Gamin (a file alteration monitor) to be installed. # If Gamin is not installed, Fail2ban will use auto. # polling: uses a polling algorithm which does not require external libraries. # auto: will try to use the following backends, in order: # pyinotify, gamin, polling. backend = auto # "usedns" specifies if jails should trust hostnames in logs, # warn when reverse DNS lookups are performed, or ignore all hostnames in logs # # yes: if a hostname is encountered, a reverse DNS lookup will be performed. # warn: if a hostname is encountered, a reverse DNS lookup will be performed, #but it will be logged as a warning. # no:if a hostname is encountered, will not be used for banning, #but it will be logged as info. usedns = warn # This jail corresponds to the standard configuration in Fail2ban 0.6. # The mail-whois action send a notification e-mail with a whois request # in the body. [ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois[name=SSH, dest=root, sender=tu email] logpath = /var/log/secure [proftpd-iptables] enabled = true filter = proftpd action = iptables[name=ProFTPD, port=ftp, protocol=tcp] sendmail-whois[name=ProFTPD, dest=tu email] logpath = /var/log/proftpd/access.log maxretry = 5 # This jail forces the backend to "polling". [sasl-iptables] enabled = true filter = sasl backend = polling action = iptables[name=sasl, port=smtp, protocol=tcp] sendmail-whois[name=sasl, dest=tu email] logpath = /var/log/maillog maxretry = 3 # Here we use TCP-Wrappers instead of Netfilter/Iptables. "ignoreregex" is # used to avoid banning the user "myuser". [ssh-tcpwrapper] enabled = true filter = sshd action = hostsdeny sendmail-whois[name=SSH, dest=tu email] ignoreregex = for myuser from logpath = /var/log/secure # This jail demonstrates the use of wildcards in "logpath". # Moreover, it is possible to give other files on a new line. [apache-tcpwrapper] enabled = true filter = apache-auth action = hostsdeny logpath = /home/*/logs/*error.log /home/*/logs/error.log maxretry = 6 # The hosts.deny path can be defined with the "file" argument if it is # not in /etc. [postfix-tcpwrapper] enabled = true filter = postfix action = iptables-multiport[name=postfix, port="110,995,143,993,25", protocol=tcp] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /var/log/maillog maxretry = 3 # Ban hosts which agent identifies spammer robots crawling the web # for email addresses. The mail outputs are buffered. [dovecot] enabled = true filter = dovecot action = iptables-multiport[name=Dovecot, port="110,995,143,993,25", protocol=tcp] sendmail-whois[name=Fail2Dovecot, lines=5, dest=tu email] logpath = /var/log/dovecot.log maxretry = 3 [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port="http,https"] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 # Use shorewall instead of iptables. [apache-shorewall] enabled = true filter = apache-noscript action = shorewall sendmail[name=Postfix, dest=tu email] logpath = /home/*/logs/error.log # This jail uses ipfw, the standard fir
[CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
hola me gustaria saber como evitar ataque DDoS a mi servidor dns por medio de iptables e inclusive como volver mas seguros el servidor dns para evitar estos tipo de ataques saludos ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] Proteger http con fail2ban
Yo tenia un problema similar con mi vps, al revisar los logs full ataques, pero con pocas cosas los detuve, te explico a ver que te sirve: 1.- SSH: Cambie el puerto por Defecto. 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista Negra de Ips de Ataques). 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): [DEFAULT] # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = tu ip. # "bantime" is the number of seconds that a host is banned. bantime = 36000 # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 600 # "maxretry" is the number of failures before a host get banned. maxretry = 3 # "backend" specifies the backend used to get files modification. # Available options are "pyinotify", "gamin", "polling" and "auto". # This option can be overridden in each jail as well. # # pyinotify: requires pyinotify (a file alteration monitor) to be installed. # If pyinotify is not installed, Fail2ban will use auto. # gamin: requires Gamin (a file alteration monitor) to be installed. # If Gamin is not installed, Fail2ban will use auto. # polling: uses a polling algorithm which does not require external libraries. # auto: will try to use the following backends, in order: # pyinotify, gamin, polling. backend = auto # "usedns" specifies if jails should trust hostnames in logs, # warn when reverse DNS lookups are performed, or ignore all hostnames in logs # # yes: if a hostname is encountered, a reverse DNS lookup will be performed. # warn: if a hostname is encountered, a reverse DNS lookup will be performed, #but it will be logged as a warning. # no:if a hostname is encountered, will not be used for banning, #but it will be logged as info. usedns = warn # This jail corresponds to the standard configuration in Fail2ban 0.6. # The mail-whois action send a notification e-mail with a whois request # in the body. [ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois[name=SSH, dest=root, sender=tu email] logpath = /var/log/secure [proftpd-iptables] enabled = true filter = proftpd action = iptables[name=ProFTPD, port=ftp, protocol=tcp] sendmail-whois[name=ProFTPD, dest=tu email] logpath = /var/log/proftpd/access.log maxretry = 5 # This jail forces the backend to "polling". [sasl-iptables] enabled = true filter = sasl backend = polling action = iptables[name=sasl, port=smtp, protocol=tcp] sendmail-whois[name=sasl, dest=tu email] logpath = /var/log/maillog maxretry = 3 # Here we use TCP-Wrappers instead of Netfilter/Iptables. "ignoreregex" is # used to avoid banning the user "myuser". [ssh-tcpwrapper] enabled = true filter = sshd action = hostsdeny sendmail-whois[name=SSH, dest=tu email] ignoreregex = for myuser from logpath = /var/log/secure # This jail demonstrates the use of wildcards in "logpath". # Moreover, it is possible to give other files on a new line. [apache-tcpwrapper] enabled = true filter = apache-auth action = hostsdeny logpath = /home/*/logs/*error.log /home/*/logs/error.log maxretry = 6 # The hosts.deny path can be defined with the "file" argument if it is # not in /etc. [postfix-tcpwrapper] enabled = true filter = postfix action = iptables-multiport[name=postfix, port="110,995,143,993,25", protocol=tcp] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /var/log/maillog maxretry = 3 # Ban hosts which agent identifies spammer robots crawling the web # for email addresses. The mail outputs are buffered. [dovecot] enabled = true filter = dovecot action = iptables-multiport[name=Dovecot, port="110,995,143,993,25", protocol=tcp] sendmail-whois[name=Fail2Dovecot, lines=5, dest=tu email] logpath = /var/log/dovecot.log maxretry = 3 [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port="http,https"] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 # Use shorewall instead of iptables. [apache-shorewall] enabled = true filter = apache-noscript action = shorewall sendmail[name=Postfix, dest=tu email] logpath = /home/*/logs/error.log # This jail uses ipfw, the standard firewall on FreeBSD. The "ignoreip" # option is overridden in this jail. Moreover, the action "mail-whois" defines # the variable "name" which contains a comma using "". The characters '' are # valid too. # This jail blocks TCP traffic for DNS requests. [named-refused-tcp] enabled = true filter = named-refused action = iptables-multiport[name=Named, port="domain,953", prot
Re: [CentOS-es] Proteger http con fail2ban
David, Quizás tengas razón David, pero depende de quien sea al admin, a veces uno puede actuar con la reglas del Kunfu, para luego obtener de donde viene el ataque y actuar en consecuencia.- Pero creo que nuestro amigo Rodrigo, tiene ese problema y lo están scaneando a pleno. Ahora creo también que esto tipo de ataque se deben para en el borde ó sea en el router antes de que entre al servidor para realizar las peticiones.- Como bien decís David #OpenBSD es una de las distro mas limpias que hay.- Lo que armaría es un servidor con 2 eth y usarlo como router hacia la LAN y desde la WAN, para que pueda analizar el tráfico con algún tipo de IDS, como dije anteriormente. Para luego si poder hacer un trabajo fino y ver desde donde viene el ataque y quien puede ser y por que lo esta haciendo. Para luego tomar las acciones que sean apropiadas.- Saludos EB El 3 de octubre de 2013 08:50, David González Romero escribió: > Yo soy partidario de no devolver el ataque. Eso implica empezar una guerra. > De cualquier forma mi objetivo es prestar mis servicios y no formar una > guerra santa, con algún X por ahí. > > De cualquier forma si hay temor a ataques de algún tipo, empieza a mirar > para este lado: > www.openbsd.org > > Suerte, > David > > > El 2 de octubre de 2013 22:39, Elio Bastias, Project Managers < > elio.bast...@gmail.com> escribió: > > > Gente, > > Buenas Noches, > > Estuve leyendo los post, > > Y veo que están viendo el tema de DDos.- > > fail2ban úsalo en otras áreas, ahora yo lo que haría es empezar en el > > router con IDS, tipo Snort, analizando el tráfico y parándolo según las > > reglas que tienen el IDS bannear a los atacante ó devolver el ataque.- > > Saludos, > > > > > > > > El 2 de octubre de 2013 20:17, David González Romero > > escribió: > > > > > DDOS es muy complejo de poder parar CSF es una variante, otra > > mod_security; > > > la tarcera no seas SysAdmin así te evitas dolores de cabeza Pero ya > > que > > > estás "enfermo" como nosotros, escucha consejo para que llegues a > viejo. > > > > > > Mod_security, Fail2Ban usalo más bien en otra area. IPtables bien duro > > para > > > que pueda asegurarte un poquito y así poco a poco podrás ir teniendo tu > > > propio librito sobre Seguridad de la que no tenemos que saberlo todo > 100% > > > > > > Saludos, > > > David > > > > > > > > > El 2 de octubre de 2013 14:14, Carlos Tirado Elgueta < > > > carlos.tir...@gmail.com> escribió: > > > > > > > yo uso para eso, incluyendo DDoS y demases, CSF ( > > > > http://configserver.com/cp/csf.html) > > > > > > > > > > > > Slds > > > > > > > > > > > > El 2 de octubre de 2013 15:06, Rodrigo Pichiñual Norin < > > > > rodrigo.pichin...@gmail.com> escribió: > > > > > > > > > Un ataque propiamente tal no...si no que una sobre carga de la > > > > > webusuarios virtuales que acceden simultaneamente dentro de un > > > lapsus > > > > > corto de tiempo, de manera que hagan colapsar o relentarizar la > web. > > > > > > > > > > a eso me refiero...=) > > > > > > > > > > gracias > > > > > > > > > > > > > > > El 2 de octubre de 2013 13:58, angel jauregui < > > darkdiabl...@gmail.com > > > > > >escribió: > > > > > > > > > > > Con SSH la manera que reconoces un intento de ataque es cuando > > > existen > > > > > > FALLOS en el login, y esto repetidas veces. > > > > > > > > > > > > Dime cual te imaginas seria el ataque en Apache ? si lo > > analizas, > > > > en > > > > > > realidad cualquier consulta puede ser un ataque o bien no serlo. > > > Muchos > > > > > > podrian decir "la comilla simple", pero que tal si en la web > tienen > > > un > > > > > > producto en ingles que lleva comilla simple ?, entonces caerias > en > > > que > > > > > esa > > > > > > comilla en ese caso no representa un ataque. > > > > > > > > > > > > Innvestiga mod_security, es lo mejor.. > > > > > > > > > > > > Fail2ban es recomendable para servicios que requieren una > > > > autentificacion > > > > > > al servicio: ssh, ftp, tftp, smtp, pop, etc... > > > > > > > > > > > > Saludos ! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 12:48, Rodrigo Pichiñual Norin < > > > > > > rodrigo.pichin...@gmail.com> escribió: > > > > > > > > > > > > > m si pero http con fail2ban??? sabes?? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 13:43, David González Romero > > > > > > > escribió: > > > > > > > > > > > > > > > Rodrigo!! > > > > > > > > > > > > > > > > Esta muy bien, pero la mejor protección que puedes hacer para > > tu > > > > SSH > > > > > es > > > > > > > > cambiar el puerto de escucha. en el /etc/ssh/sshd_config > > > > > > > > > > > > > > > > Port 6541 > > > > > > > > > > > > > > > > Asi evitas que los boots se pongan a scanear al respecto. > > Puedes > > > > > > entonces > > > > > > > > con fail2ban proteger ese puerto. Y luego IPtables, si no > > puedes > > > > > > cambiar > > > > > > > tu > > > > > > > > puerto SSH sería entonces prudente a
Re: [CentOS-es] Multicast por UDP
Los terminales tienen alguna identificación IP? Podrias establecer pequeños tuneles para asegurar la entrega del paquete... Saludos, David El 2 de octubre de 2013 22:56, Normando Hall escribió: > Hola Francesc > > El tema es asi. El host desde el cual salen los paquetes UDP es una VPS > alojado en la empresa IPLAN. Es un VPS de los mas grandes que disponen. > > No sé que hay en el medio, pero lo cierto es que tengo acceso a la IP > pública directamente y es sobre la cual envío los paquetes. > Cuando digo multicast no me refiero exactamente al protocolo multicast, > sino que simplemente hago como un broadcast. Es asi de simple, quizás me > he equivocado bastante con el asunto del email, en realidad es un > broadcast. Bueno, ese broadcasta, a algunos terminales les llega el > paquete y a otros no. > > Saludos > > El 30/09/2013 09:06 p.m., Francesc Guitart escribió: > > Hola, > > > > Entre el host que envía los paquetes UDP y los ordenadores que los > > reciben, ¿que hay en medio? > > > > Lo que quiero decir es que los dispositivos de red (routers y switchs) > > por los que pasa el trafico UDP deben soportar y tener bien configurado > > multicast. Verifica que tienes activado al menos un dispositivo con el > > rol IGMP Querier en la red y IGMP Snooping en todos. > > > > Saludos. > > > > > > -- > Normando Hall > Rosario - Argentina > normandoh...@gmail.com > > ___ > CentOS-es mailing list > CentOS-es@centos.org > http://lists.centos.org/mailman/listinfo/centos-es > ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] Proteger http con fail2ban
Yo soy partidario de no devolver el ataque. Eso implica empezar una guerra. De cualquier forma mi objetivo es prestar mis servicios y no formar una guerra santa, con algún X por ahí. De cualquier forma si hay temor a ataques de algún tipo, empieza a mirar para este lado: www.openbsd.org Suerte, David El 2 de octubre de 2013 22:39, Elio Bastias, Project Managers < elio.bast...@gmail.com> escribió: > Gente, > Buenas Noches, > Estuve leyendo los post, > Y veo que están viendo el tema de DDos.- > fail2ban úsalo en otras áreas, ahora yo lo que haría es empezar en el > router con IDS, tipo Snort, analizando el tráfico y parándolo según las > reglas que tienen el IDS bannear a los atacante ó devolver el ataque.- > Saludos, > > > > El 2 de octubre de 2013 20:17, David González Romero > escribió: > > > DDOS es muy complejo de poder parar CSF es una variante, otra > mod_security; > > la tarcera no seas SysAdmin así te evitas dolores de cabeza Pero ya > que > > estás "enfermo" como nosotros, escucha consejo para que llegues a viejo. > > > > Mod_security, Fail2Ban usalo más bien en otra area. IPtables bien duro > para > > que pueda asegurarte un poquito y así poco a poco podrás ir teniendo tu > > propio librito sobre Seguridad de la que no tenemos que saberlo todo 100% > > > > Saludos, > > David > > > > > > El 2 de octubre de 2013 14:14, Carlos Tirado Elgueta < > > carlos.tir...@gmail.com> escribió: > > > > > yo uso para eso, incluyendo DDoS y demases, CSF ( > > > http://configserver.com/cp/csf.html) > > > > > > > > > Slds > > > > > > > > > El 2 de octubre de 2013 15:06, Rodrigo Pichiñual Norin < > > > rodrigo.pichin...@gmail.com> escribió: > > > > > > > Un ataque propiamente tal no...si no que una sobre carga de la > > > > webusuarios virtuales que acceden simultaneamente dentro de un > > lapsus > > > > corto de tiempo, de manera que hagan colapsar o relentarizar la web. > > > > > > > > a eso me refiero...=) > > > > > > > > gracias > > > > > > > > > > > > El 2 de octubre de 2013 13:58, angel jauregui < > darkdiabl...@gmail.com > > > > >escribió: > > > > > > > > > Con SSH la manera que reconoces un intento de ataque es cuando > > existen > > > > > FALLOS en el login, y esto repetidas veces. > > > > > > > > > > Dime cual te imaginas seria el ataque en Apache ? si lo > analizas, > > > en > > > > > realidad cualquier consulta puede ser un ataque o bien no serlo. > > Muchos > > > > > podrian decir "la comilla simple", pero que tal si en la web tienen > > un > > > > > producto en ingles que lleva comilla simple ?, entonces caerias en > > que > > > > esa > > > > > comilla en ese caso no representa un ataque. > > > > > > > > > > Innvestiga mod_security, es lo mejor.. > > > > > > > > > > Fail2ban es recomendable para servicios que requieren una > > > autentificacion > > > > > al servicio: ssh, ftp, tftp, smtp, pop, etc... > > > > > > > > > > Saludos ! > > > > > > > > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 12:48, Rodrigo Pichiñual Norin < > > > > > rodrigo.pichin...@gmail.com> escribió: > > > > > > > > > > > m si pero http con fail2ban??? sabes?? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 13:43, David González Romero > > > > > > escribió: > > > > > > > > > > > > > Rodrigo!! > > > > > > > > > > > > > > Esta muy bien, pero la mejor protección que puedes hacer para > tu > > > SSH > > > > es > > > > > > > cambiar el puerto de escucha. en el /etc/ssh/sshd_config > > > > > > > > > > > > > > Port 6541 > > > > > > > > > > > > > > Asi evitas que los boots se pongan a scanear al respecto. > Puedes > > > > > entonces > > > > > > > con fail2ban proteger ese puerto. Y luego IPtables, si no > puedes > > > > > cambiar > > > > > > tu > > > > > > > puerto SSH sería entonces prudente aceptar conecciones SSH > desde > > IP > > > > > > > conocidas en tu server. > > > > > > > > > > > > > > De cualquier forma una de las maneras más fuertes de proteger > > > Apache > > > > es > > > > > > > mod_security. > > > > > > > > > > > > > > Saludos, > > > > > > > David > > > > > > > > > > > > > > > > > > > > > El 2 de octubre de 2013 13:14, Rodrigo Pichiñual Norin < > > > > > > > rodrigo.pichin...@gmail.com> escribió: > > > > > > > > > > > > > > > Hola a todos. > > > > > > > > > > > > > > > > > > > > > > > > Tengo instalado fail2ban en centos 6.3 > > > > > > > > > > > > > > > > Logre entender como proteger SSH en caso de ataques de fuerza > > > > bruta. > > > > > > > > > > > > > > > > > > > > > > > > banntime=600 > > > > > > > > > > > > > > > > [ssh-iptables] > > > > > > > > enabled = true > > > > > > > > filter = sshd > > > > > > > > action = iptables[name=SSH, port=ssh, protocol=tcp] > > > > > > > > mail-whois[name=SSH, dest=mim...@dominio.cl, > > > > > > > > sender=fail2ban@ > > > > > > > > dominio.cl] > > > > > > > > logpath = /var/log/secure > > > > > > > > maxretry = 5 > > > > > > > > > > > > > > > > Esto bloquea a una ip el accesso mediante SSH despué
