Re: [CentOS-es] Proteger http con fail2ban

2013-10-03 Por tema Wilmer Arambula
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

2013-10-03 Por tema Carlos Tirado Elgueta
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] Proteger http con fail2ban

2013-10-03 Por tema Wilmer Arambula
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] Proteger http con fail2ban

2013-10-03 Por tema 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]
>
> 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] Proteger http con fail2ban

2013-10-03 Por tema 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, 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

2013-10-03 Por tema Elio Bastias, Project Managers
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] Proteger http con fail2ban

2013-10-03 Por tema David González Romero
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é

Re: [CentOS-es] Proteger http con fail2ban

2013-10-02 Por tema Elio Bastias, Project Managers
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  > > >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] Proteger http con fail2ban

2013-10-02 Por tema David González Romero
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
> > > > > > http://lists.centos.org/mailman/listinfo/centos-es
> > > > > >
> > > > > ___
> > > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > M.S.I. Angel Haniel Cantu Jauregui.
> > >
> > > Celular: (011-52-1)-899-871-17-22
> > > E-Mail: angel.ca...@sie-group.net
> > > Web: http://www.sie-group.net/
> > > Cd. Reynosa Tamaulipas.
> > > ___

Re: [CentOS-es] Proteger http con fail2ban

2013-10-02 Por tema Carlos Tirado Elgueta
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
> > > > > http://lists.centos.org/mailman/listinfo/centos-es
> > > > >
> > > > ___
> > > > 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
> > >
> >
> >
> >
> > --
> > M.S.I. Angel Haniel Cantu Jauregui.
> >
> > Celular: (011-52-1)-899-871-17-22
> > E-Mail: angel.ca...@sie-group.net
> > Web: http://www.sie-group.net/
> > Cd. Reynosa Tamaulipas.
> > ___
> > 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
>



-- 
Carlos Francisco Tirado Elgueta
Google Apps for Business Partner Chile
http://www.chilemedios.cl
___
CentOS-es mailing list
CentOS-es@centos.org
http://lists.centos.org/mailman/listinfo/centos-es


Re: [CentOS-es] Proteger http con fail2ban

2013-10-02 Por tema Rodrigo Pichiñual Norin
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
> > > > http://lists.centos.org/mailman/listinfo/centos-es
> > > >
> > > ___
> > > 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
> >
>
>
>
> --
> M.S.I. Angel Haniel Cantu Jauregui.
>
> Celular: (011-52-1)-899-871-17-22
> E-Mail: angel.ca...@sie-group.net
> Web: http://www.sie-group.net/
> Cd. Reynosa Tamaulipas.
> ___
> 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

2013-10-02 Por tema angel jauregui
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
> > > http://lists.centos.org/mailman/listinfo/centos-es
> > >
> > ___
> > 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
>



-- 
M.S.I. Angel Haniel Cantu Jauregui.

Celular: (011-52-1)-899-871-17-22
E-Mail: angel.ca...@sie-group.net
Web: http://www.sie-group.net/
Cd. Reynosa Tamaulipas.
___
CentOS-es mailing list
CentOS-es@centos.org
http://lists.centos.org/mailman/listinfo/centos-es


Re: [CentOS-es] Proteger http con fail2ban

2013-10-02 Por tema Rodrigo Pichiñual Norin
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
> > http://lists.centos.org/mailman/listinfo/centos-es
> >
> ___
> 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

2013-10-02 Por tema David González Romero
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
> http://lists.centos.org/mailman/listinfo/centos-es
>
___
CentOS-es mailing list
CentOS-es@centos.org
http://lists.centos.org/mailman/listinfo/centos-es


[CentOS-es] Proteger http con fail2ban

2013-10-02 Por tema Rodrigo Pichiñual Norin
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
http://lists.centos.org/mailman/listinfo/centos-es