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=mimail@dominio.cl, sender=fail2ban@fail2ban@latitud33.cl 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
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.pichinual@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=mimail@dominio.cl, sender=fail2ban@fail2ban@latitud33.cl 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
mmmmm si pero http con fail2ban....??? sabes??
El 2 de octubre de 2013 13:43, David González Romero dgrvedado@gmail.comescribió:
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.pichinual@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=mimail@dominio.cl, sender=fail2ban@fail2ban@latitud33.cl 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
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.pichinual@gmail.com> escribió:
mmmmm si pero http con fail2ban....??? sabes??
El 2 de octubre de 2013 13:43, David González Romero dgrvedado@gmail.comescribió:
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.pichinual@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=mimail@dominio.cl, sender=fail2ban@fail2ban@latitud33.cl 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
Un ataque propiamente tal no...si no que una sobre carga de la web....usuarios 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 darkdiabliyo@gmail.comescribió:
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.pichinual@gmail.com> escribió:
mmmmm si pero http con fail2ban....??? sabes??
El 2 de octubre de 2013 13:43, David González Romero dgrvedado@gmail.comescribió:
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.pichinual@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=mimail@dominio.cl, sender=fail2ban@fail2ban@latitud33.cl 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.cantu@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
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.pichinual@gmail.com> escribió:
Un ataque propiamente tal no...si no que una sobre carga de la web....usuarios 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 <darkdiabliyo@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.pichinual@gmail.com> escribió:
mmmmm si pero http con fail2ban....??? sabes??
El 2 de octubre de 2013 13:43, David González Romero dgrvedado@gmail.comescribió:
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.pichinual@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=mimail@dominio.cl, sender=fail2ban@fail2ban@latitud33.cl 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.cantu@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
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.tirado@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.pichinual@gmail.com> escribió:
Un ataque propiamente tal no...si no que una sobre carga de la web....usuarios 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 <darkdiabliyo@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.pichinual@gmail.com> escribió:
mmmmm si pero http con fail2ban....??? sabes??
El 2 de octubre de 2013 13:43, David González Romero dgrvedado@gmail.comescribió:
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.pichinual@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=mimail@dominio.cl, sender=fail2ban@fail2ban@latitud33.cl 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.cantu@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
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 dgrvedado@gmail.comescribió:
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.tirado@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.pichinual@gmail.com> escribió:
Un ataque propiamente tal no...si no que una sobre carga de la web....usuarios 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 <darkdiabliyo@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.pichinual@gmail.com> escribió:
mmmmm si pero http con fail2ban....??? sabes??
El 2 de octubre de 2013 13:43, David González Romero dgrvedado@gmail.comescribió:
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.pichinual@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=mimail@dominio.cl, > sender=fail2ban@fail2ban@latitud33.cl > 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.cantu@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
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
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.bastias@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 dgrvedado@gmail.comescribió:
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.tirado@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.pichinual@gmail.com> escribió:
Un ataque propiamente tal no...si no que una sobre carga de la web....usuarios 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 <
darkdiabliyo@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.pichinual@gmail.com> escribió:
mmmmm si pero http con fail2ban....??? sabes??
El 2 de octubre de 2013 13:43, David González Romero dgrvedado@gmail.comescribió:
> 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.pichinual@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=mimail@dominio.cl, > > sender=fail2ban@fail2ban@latitud33.cl > > 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.cantu@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
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
-- Elio Bastias Project Manager _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
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 dgrvedado@gmail.comescribió:
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.bastias@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 dgrvedado@gmail.comescribió:
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.tirado@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.pichinual@gmail.com> escribió:
Un ataque propiamente tal no...si no que una sobre carga de la web....usuarios 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 <
darkdiabliyo@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.pichinual@gmail.com> escribió:
> mmmmm si pero http con fail2ban....??? sabes?? > > > > > > El 2 de octubre de 2013 13:43, David González Romero > dgrvedado@gmail.comescribió: > > > 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.pichinual@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=mimail@dominio.cl, > > > sender=fail2ban@fail2ban@latitud33.cl > > > 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.cantu@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
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
-- Elio Bastias Project Manager _______________________________________________ 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
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 dgrvedado@gmail.comescribió:
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.tirado@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.pichinual@gmail.com> escribió:
Un ataque propiamente tal no...si no que una sobre carga de la web....usuarios 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 <darkdiabliyo@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.pichinual@gmail.com> escribió:
mmmmm si pero http con fail2ban....??? sabes??
El 2 de octubre de 2013 13:43, David González Romero dgrvedado@gmail.comescribió:
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.pichinual@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=mimail@dominio.cl, > sender=fail2ban@fail2ban@latitud33.cl > 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.cantu@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
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
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.tirado@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 dgrvedado@gmail.comescribió:
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.tirado@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.pichinual@gmail.com> escribió:
Un ataque propiamente tal no...si no que una sobre carga de la web....usuarios 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 <
darkdiabliyo@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.pichinual@gmail.com> escribió:
mmmmm si pero http con fail2ban....??? sabes??
El 2 de octubre de 2013 13:43, David González Romero dgrvedado@gmail.comescribió:
> 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.pichinual@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=mimail@dominio.cl, > > sender=fail2ban@fail2ban@latitud33.cl > > 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.cantu@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
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
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", protocol=tcp] sendmail-whois[name=Named, dest=tu email] logpath = /var/log/messages ignoreip = tu ip
# Jail for more extended banning of persistent abusers # !!! WARNING !!! # Make sure that your loglevel specified in fail2ban.conf/.local # is not at DEBUG level -- which might then cause fail2ban to fall into # an infinite loop constantly feeding itself with non-informative lines [recidive]
enabled = true filter = recidive logpath = /var/log/fail2ban.log action = iptables-allports[name=recidive] sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log] bantime = 604800 ; 1 week findtime = 86400 ; 1 day maxretry = 5
Estas son algunas opciones que puedes configurar en tu fail2ban, si buscas en google con tus logs que ya tienes puedes probar cada una de ellas, te recomiendo que crees tu propio archivo jail.local en vez de jail.conf, asi cada vez que actualices tendrás tus reglas guardadas sin problemas, todo es cuestión de paciencia y sobre todo de analizar tus logs para detectar los ataques que recibes, claro habrán otros que no veras como escaneos, pero tampoco hay que ponerse tan paranoico.
El 2 de octubre de 2013 12:44, Rodrigo Pichiñual Norin < rodrigo.pichinual@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=mimail@dominio.cl, sender=fail2ban@fail2ban@latitud33.cl 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
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 tecnologiaterabyte@gmail.com
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", protocol=tcp] sendmail-whois[name=Named, dest=tu email] logpath = /var/log/messages ignoreip = tu ip
# Jail for more extended banning of persistent abusers # !!! WARNING !!! # Make sure that your loglevel specified in fail2ban.conf/.local # is not at DEBUG level -- which might then cause fail2ban to fall into # an infinite loop constantly feeding itself with non-informative lines [recidive]
enabled = true filter = recidive logpath = /var/log/fail2ban.log action = iptables-allports[name=recidive] sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log] bantime = 604800 ; 1 week findtime = 86400 ; 1 day maxretry = 5
Estas son algunas opciones que puedes configurar en tu fail2ban, si buscas en google con tus logs que ya tienes puedes probar cada una de ellas, te recomiendo que crees tu propio archivo jail.local en vez de jail.conf, asi cada vez que actualices tendrás tus reglas guardadas sin problemas, todo es cuestión de paciencia y sobre todo de analizar tus logs para detectar los ataques que recibes, claro habrán otros que no veras como escaneos, pero tampoco hay que ponerse tan paranoico.
El 2 de octubre de 2013 12:44, Rodrigo Pichiñual Norin < rodrigo.pichinual@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=mimail@dominio.cl, sender=fail2ban@fail2ban@latitud33.cl 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
-- *Wilmer Arambula. * *Asoc. Cooperativa Tecnologia Terabyte 124, RL.* ** ** _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
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.h...
2013/10/3 Rodrigo Pichiñual Norin rodrigo.pichinual@gmail.com
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 tecnologiaterabyte@gmail.com
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",
protocol=tcp]
sendmail-whois[name=Named, dest=tu email]logpath = /var/log/messages ignoreip = tu ip
# Jail for more extended banning of persistent abusers # !!! WARNING !!! # Make sure that your loglevel specified in fail2ban.conf/.local # is not at DEBUG level -- which might then cause fail2ban to fall into # an infinite loop constantly feeding itself with non-informative lines [recidive]
enabled = true filter = recidive logpath = /var/log/fail2ban.log action = iptables-allports[name=recidive] sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log] bantime = 604800 ; 1 week findtime = 86400 ; 1 day maxretry = 5
Estas son algunas opciones que puedes configurar en tu fail2ban, si
buscas
en google con tus logs que ya tienes puedes probar cada una de ellas, te recomiendo que crees tu propio archivo jail.local en vez de jail.conf,
asi
cada vez que actualices tendrás tus reglas guardadas sin problemas, todo
es
cuestión de paciencia y sobre todo de analizar tus logs para detectar los ataques que recibes, claro habrán otros que no veras como escaneos, pero tampoco hay que ponerse tan paranoico.
El 2 de octubre de 2013 12:44, Rodrigo Pichiñual Norin < rodrigo.pichinual@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=mimail@dominio.cl, sender=fail2ban@fail2ban@latitud33.cl 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
-- *Wilmer Arambula. * *Asoc. Cooperativa Tecnologia Terabyte 124, RL.* ** ** _______________________________________________ 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
-
angel jauregui -
Carlos Tirado Elgueta -
David González Romero -
Elio Bastias, Project Managers -
Rodrigo Pichiñual Norin -
Wilmer Arambula