[CentOS-virt] Xen Project Developer Summit Line-up announced
Hi, sorry for the spam. Just a quick note to let you know that the schedule for the Xen Project Developer Summit is finally available at: http://xendevelopersummit2013.sched.org/ - You can find more information about the summit on http://events.linuxfoundation.org//events/xen-project-developer-summit/ and http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg02434.html Best Regards Lars ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-es] Proteger http con fail2ban
Yo soy partidario de no devolver el ataque. Eso implica empezar una guerra. De cualquier forma mi objetivo es prestar mis servicios y no formar una guerra santa, con algún X por ahí. De cualquier forma si hay temor a ataques de algún tipo, empieza a mirar para este lado: www.openbsd.org Suerte, David El 2 de octubre de 2013 22:39, Elio Bastias, Project Managers elio.bast...@gmail.com escribió: Gente, Buenas Noches, Estuve leyendo los post, Y veo que están viendo el tema de DDos.- fail2ban úsalo en otras áreas, ahora yo lo que haría es empezar en el router con IDS, tipo Snort, analizando el tráfico y parándolo según las reglas que tienen el IDS bannear a los atacante ó devolver el ataque.- Saludos, El 2 de octubre de 2013 20:17, David González Romero dgrved...@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.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 dgrved...@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.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@fail2...@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
Re: [CentOS-es] Multicast por UDP
Los terminales tienen alguna identificación IP? Podrias establecer pequeños tuneles para asegurar la entrega del paquete... Saludos, David El 2 de octubre de 2013 22:56, Normando Hall nh...@unixlan.com.arescribió: Hola Francesc El tema es asi. El host desde el cual salen los paquetes UDP es una VPS alojado en la empresa IPLAN. Es un VPS de los mas grandes que disponen. No sé que hay en el medio, pero lo cierto es que tengo acceso a la IP pública directamente y es sobre la cual envío los paquetes. Cuando digo multicast no me refiero exactamente al protocolo multicast, sino que simplemente hago como un broadcast. Es asi de simple, quizás me he equivocado bastante con el asunto del email, en realidad es un broadcast. Bueno, ese broadcasta, a algunos terminales les llega el paquete y a otros no. Saludos El 30/09/2013 09:06 p.m., Francesc Guitart escribió: Hola, Entre el host que envía los paquetes UDP y los ordenadores que los reciben, ¿que hay en medio? Lo que quiero decir es que los dispositivos de red (routers y switchs) por los que pasa el trafico UDP deben soportar y tener bien configurado multicast. Verifica que tienes activado al menos un dispositivo con el rol IGMP Querier en la red y IGMP Snooping en todos. Saludos. -- Normando Hall Rosario - Argentina normandoh...@gmail.com ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] Proteger http con fail2ban
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 dgrved...@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.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 dgrved...@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.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 dgrved...@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.pichin...@gmail.com escribió: Hola a todos. Tengo instalado fail2ban en centos 6.3 Logre entender como proteger
Re: [CentOS-es] Proteger http con fail2ban
Yo tenia un problema similar con mi vps, al revisar los logs full ataques, pero con pocas cosas los detuve, te explico a ver que te sirve: 1.- SSH: Cambie el puerto por Defecto. 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista Negra de Ips de Ataques). 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): [DEFAULT] # ignoreip can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = tu ip. # bantime is the number of seconds that a host is banned. bantime = 36000 # A host is banned if it has generated maxretry during the last findtime # seconds. findtime = 600 # maxretry is the number of failures before a host get banned. maxretry = 3 # backend specifies the backend used to get files modification. # Available options are pyinotify, gamin, polling and auto. # This option can be overridden in each jail as well. # # pyinotify: requires pyinotify (a file alteration monitor) to be installed. # If pyinotify is not installed, Fail2ban will use auto. # gamin: requires Gamin (a file alteration monitor) to be installed. # If Gamin is not installed, Fail2ban will use auto. # polling: uses a polling algorithm which does not require external libraries. # auto: will try to use the following backends, in order: # pyinotify, gamin, polling. backend = auto # usedns specifies if jails should trust hostnames in logs, # warn when reverse DNS lookups are performed, or ignore all hostnames in logs # # yes: if a hostname is encountered, a reverse DNS lookup will be performed. # warn: if a hostname is encountered, a reverse DNS lookup will be performed, #but it will be logged as a warning. # no:if a hostname is encountered, will not be used for banning, #but it will be logged as info. usedns = warn # This jail corresponds to the standard configuration in Fail2ban 0.6. # The mail-whois action send a notification e-mail with a whois request # in the body. [ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois[name=SSH, dest=root, sender=tu email] logpath = /var/log/secure [proftpd-iptables] enabled = true filter = proftpd action = iptables[name=ProFTPD, port=ftp, protocol=tcp] sendmail-whois[name=ProFTPD, dest=tu email] logpath = /var/log/proftpd/access.log maxretry = 5 # This jail forces the backend to polling. [sasl-iptables] enabled = true filter = sasl backend = polling action = iptables[name=sasl, port=smtp, protocol=tcp] sendmail-whois[name=sasl, dest=tu email] logpath = /var/log/maillog maxretry = 3 # Here we use TCP-Wrappers instead of Netfilter/Iptables. ignoreregex is # used to avoid banning the user myuser. [ssh-tcpwrapper] enabled = true filter = sshd action = hostsdeny sendmail-whois[name=SSH, dest=tu email] ignoreregex = for myuser from logpath = /var/log/secure # This jail demonstrates the use of wildcards in logpath. # Moreover, it is possible to give other files on a new line. [apache-tcpwrapper] enabled = true filter = apache-auth action = hostsdeny logpath = /home/*/logs/*error.log /home/*/logs/error.log maxretry = 6 # The hosts.deny path can be defined with the file argument if it is # not in /etc. [postfix-tcpwrapper] enabled = true filter = postfix action = iptables-multiport[name=postfix, port=110,995,143,993,25, protocol=tcp] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /var/log/maillog maxretry = 3 # Ban hosts which agent identifies spammer robots crawling the web # for email addresses. The mail outputs are buffered. [dovecot] enabled = true filter = dovecot action = iptables-multiport[name=Dovecot, port=110,995,143,993,25, protocol=tcp] sendmail-whois[name=Fail2Dovecot, lines=5, dest=tu email] logpath = /var/log/dovecot.log maxretry = 3 [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port=http,https] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 # Use shorewall instead of iptables. [apache-shorewall] enabled = true filter = apache-noscript action = shorewall sendmail[name=Postfix, dest=tu email] logpath = /home/*/logs/error.log # This jail uses ipfw, the standard firewall on FreeBSD. The ignoreip # option is overridden in this jail. Moreover, the action mail-whois defines # the variable name which contains a comma using . The characters '' are # valid too. # This jail blocks TCP traffic for DNS requests. [named-refused-tcp] enabled = true filter = named-refused action = iptables-multiport[name=Named, port=domain,953, protocol=tcp] sendmail-whois[name=Named,
[CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
hola me gustaria saber como evitar ataque DDoS a mi servidor dns por medio de iptables e inclusive como volver mas seguros el servidor dns para evitar estos tipo de ataques saludos ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
Buenos Días, Ignacio, Hay muchas formas para poder evitarlos: 1) Una es colocar un router con algún IDS, tipo Snort, ú otro para que la carga se haga en el router y no en el servidor DNS.- 2) Podes utilizar fail2ban, en otro hilo estamos discutiendo algo similar, te pego una de las posibles config que se puede hacer, esto es de uno de los foristas, para que te orientes: había un problema similar con unos de mi vps, al revisar los logs full ataques, pero con pocas cosas los detuve, te explico a ver que te sirve: 1.- SSH: Cambie el puerto por Defecto. 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista Negra de Ips de Ataques). 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): [DEFAULT] # ignoreip can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = tu ip. # bantime is the number of seconds that a host is banned. bantime = 36000 # A host is banned if it has generated maxretry during the last findtime # seconds. findtime = 600 # maxretry is the number of failures before a host get banned. maxretry = 3 # backend specifies the backend used to get files modification. # Available options are pyinotify, gamin, polling and auto. # This option can be overridden in each jail as well. # # pyinotify: requires pyinotify (a file alteration monitor) to be installed. # If pyinotify is not installed, Fail2ban will use auto. # gamin: requires Gamin (a file alteration monitor) to be installed. # If Gamin is not installed, Fail2ban will use auto. # polling: uses a polling algorithm which does not require external libraries. # auto: will try to use the following backends, in order: # pyinotify, gamin, polling. backend = auto # usedns specifies if jails should trust hostnames in logs, # warn when reverse DNS lookups are performed, or ignore all hostnames in logs # # yes: if a hostname is encountered, a reverse DNS lookup will be performed. # warn: if a hostname is encountered, a reverse DNS lookup will be performed, #but it will be logged as a warning. # no:if a hostname is encountered, will not be used for banning, #but it will be logged as info. usedns = warn # This jail corresponds to the standard configuration in Fail2ban 0.6. # The mail-whois action send a notification e-mail with a whois request # in the body. [ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois[name=SSH, dest=root, sender=tu email] logpath = /var/log/secure [proftpd-iptables] enabled = true filter = proftpd action = iptables[name=ProFTPD, port=ftp, protocol=tcp] sendmail-whois[name=ProFTPD, dest=tu email] logpath = /var/log/proftpd/access.log maxretry = 5 # This jail forces the backend to polling. [sasl-iptables] enabled = true filter = sasl backend = polling action = iptables[name=sasl, port=smtp, protocol=tcp] sendmail-whois[name=sasl, dest=tu email] logpath = /var/log/maillog maxretry = 3 # Here we use TCP-Wrappers instead of Netfilter/Iptables. ignoreregex is # used to avoid banning the user myuser. [ssh-tcpwrapper] enabled = true filter = sshd action = hostsdeny sendmail-whois[name=SSH, dest=tu email] ignoreregex = for myuser from logpath = /var/log/secure # This jail demonstrates the use of wildcards in logpath. # Moreover, it is possible to give other files on a new line. [apache-tcpwrapper] enabled = true filter = apache-auth action = hostsdeny logpath = /home/*/logs/*error.log /home/*/logs/error.log maxretry = 6 # The hosts.deny path can be defined with the file argument if it is # not in /etc. [postfix-tcpwrapper] enabled = true filter = postfix action = iptables-multiport[name=postfix, port=110,995,143,993,25, protocol=tcp] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /var/log/maillog maxretry = 3 # Ban hosts which agent identifies spammer robots crawling the web # for email addresses. The mail outputs are buffered. [dovecot] enabled = true filter = dovecot action = iptables-multiport[name=Dovecot, port=110,995,143,993,25, protocol=tcp] sendmail-whois[name=Fail2Dovecot, lines=5, dest=tu email] logpath = /var/log/dovecot.log maxretry = 3 [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port=http,https] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 # Use shorewall instead of iptables. [apache-shorewall] enabled = true filter = apache-noscript action = shorewall sendmail[name=Postfix, dest=tu email] logpath = /home/*/logs/error.log # This jail uses ipfw, the standard firewall on FreeBSD. The ignoreip #
Re: [CentOS-es] Proteger http con fail2ban
Gracias Willmer me podrias explicar parte de este trozo de codigo. [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port=http,https] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 entiendo que esta habilitado (enabled) el filtro que utiliza dentro de la carpete filter.d es apache-badbots peor el resto no lo tengo muy claro.. gracias 2013/10/3 Wilmer Arambula tecnologiaterab...@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 #
Re: [CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
Elio, me puedes explicar este trozo de codigo y para que sirve? [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port=http,https] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 esta habilidato apache-badbots (enabled = true) utiliza el filtro apache-badbots ubicado en el directorio filter.d action = ? logpath= donde busca los log para actuar bantime = ? ( se que es timepo de banneo) maxretry = ? ( un solo intent ) gracias 2013/10/3 Elio Bastias, Project Managers elio.bast...@gmail.com Buenos Días, Ignacio, Hay muchas formas para poder evitarlos: 1) Una es colocar un router con algún IDS, tipo Snort, ú otro para que la carga se haga en el router y no en el servidor DNS.- 2) Podes utilizar fail2ban, en otro hilo estamos discutiendo algo similar, te pego una de las posibles config que se puede hacer, esto es de uno de los foristas, para que te orientes: había un problema similar con unos de mi vps, al revisar los logs full ataques, pero con pocas cosas los detuve, te explico a ver que te sirve: 1.- SSH: Cambie el puerto por Defecto. 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista Negra de Ips de Ataques). 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): [DEFAULT] # ignoreip can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = tu ip. # bantime is the number of seconds that a host is banned. bantime = 36000 # A host is banned if it has generated maxretry during the last findtime # seconds. findtime = 600 # maxretry is the number of failures before a host get banned. maxretry = 3 # backend specifies the backend used to get files modification. # Available options are pyinotify, gamin, polling and auto. # This option can be overridden in each jail as well. # # pyinotify: requires pyinotify (a file alteration monitor) to be installed. # If pyinotify is not installed, Fail2ban will use auto. # gamin: requires Gamin (a file alteration monitor) to be installed. # If Gamin is not installed, Fail2ban will use auto. # polling: uses a polling algorithm which does not require external libraries. # auto: will try to use the following backends, in order: # pyinotify, gamin, polling. backend = auto # usedns specifies if jails should trust hostnames in logs, # warn when reverse DNS lookups are performed, or ignore all hostnames in logs # # yes: if a hostname is encountered, a reverse DNS lookup will be performed. # warn: if a hostname is encountered, a reverse DNS lookup will be performed, #but it will be logged as a warning. # no:if a hostname is encountered, will not be used for banning, #but it will be logged as info. usedns = warn # This jail corresponds to the standard configuration in Fail2ban 0.6. # The mail-whois action send a notification e-mail with a whois request # in the body. [ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois[name=SSH, dest=root, sender=tu email] logpath = /var/log/secure [proftpd-iptables] enabled = true filter = proftpd action = iptables[name=ProFTPD, port=ftp, protocol=tcp] sendmail-whois[name=ProFTPD, dest=tu email] logpath = /var/log/proftpd/access.log maxretry = 5 # This jail forces the backend to polling. [sasl-iptables] enabled = true filter = sasl backend = polling action = iptables[name=sasl, port=smtp, protocol=tcp] sendmail-whois[name=sasl, dest=tu email] logpath = /var/log/maillog maxretry = 3 # Here we use TCP-Wrappers instead of Netfilter/Iptables. ignoreregex is # used to avoid banning the user myuser. [ssh-tcpwrapper] enabled = true filter = sshd action = hostsdeny sendmail-whois[name=SSH, dest=tu email] ignoreregex = for myuser from logpath = /var/log/secure # This jail demonstrates the use of wildcards in logpath. # Moreover, it is possible to give other files on a new line. [apache-tcpwrapper] enabled = true filter = apache-auth action = hostsdeny logpath = /home/*/logs/*error.log /home/*/logs/error.log maxretry = 6 # The hosts.deny path can be defined with the file argument if it is # not in /etc. [postfix-tcpwrapper] enabled = true filter = postfix action = iptables-multiport[name=postfix, port=110,995,143,993,25, protocol=tcp] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /var/log/maillog maxretry = 3 # Ban hosts which agent identifies spammer robots crawling the web # for email addresses. The mail outputs are buffered. [dovecot]
Re: [CentOS-es] Proteger http con fail2ban
Te dire busca en google hay muchas formas de proteger apache, te agrego dos links la mejor forma de hacerlo es probando con tus logs y configurarlo a tus necesidades, es lo que mas recomiendo: *apache-tcpwrapper:* Bloquea con el fichero /etc/hosts.deny los hosts que se intentan conectar a dominios protegidos con contraseña (estos fallos de autenticación aparecen en el error_log) *apache-badbots* Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos. Pondre dos links: http://apliweb.com/blog/fail2ban-evitando-ataques-en-nuestro-servidor-web http://garciavictor.blogspot.com/2012/11/fail2ban-en-debian-squeezy-wheezy.html 2013/10/3 Rodrigo Pichiñual Norin rodrigo.pichin...@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 tecnologiaterab...@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
Re: [CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
Rodrigo, Buenos Días, Como estas, te paso un link, en donde te explica un poco mas detallado cada una de las líneas, y otros temas: http://www.fail2ban.org/wiki/index.php/Talk:Apache *básicamente apache-badbots* Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos. te paso algunos ejemplos: *apache-tcpwrapper:* Bloquea con el fichero /etc/hosts.deny los hosts que se intentan conectar a dominios protegidos con contraseña (estos fallos de autenticación aparecen en el error_log)*[* *apache-tcpwrapper]* enablednbsp; = true filternbsp;nbsp; = apache-auth actionnbsp;nbsp; = hostsdeny logpathnbsp; = /var/www/vhosts/*/statistics/logs/error_log maxretry = 6 *apache-badbots* Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos.*** *[apache-badbots] enablednbsp; = true filternbsp;nbsp; = apache-badbots actionnbsp;nbsp; = iptables-multiport[name=BadBots, port=http,https] sendmail-buffered[name=BadBots, lines=5, dest=y...@mail.com] logpathnbsp; = /var/www/vhosts/*/statistics/logs/access_log bantimenbsp; = 172800 maxretry = 1 # Para prevenir ataques de inyeccion de codigo *php-url-fopen*. Bloqueamos los hosts, que intentan una inyeccion de código del tipo: GET /index.php?n=http://www.dominio.com/fichero.htm [php-url-fopen] enabled = true portnbsp;nbsp;nbsp; = http,https filternbsp; = php-url-fopen logpath = /var/www/vhosts/*/statistics/logs/access_log maxretry = 1 # Evitamos ataques de ips que accedan a urls que contengan passthru o system o similares *apache-hacks*: Bloquea los hosts que acceden a urls sospechosas, haciendo un SCAN o directamente acceden a urls intentando inyectar llamadas al sistema desde php (system, passthru…) esta regla se va rellenando con las expresiones que vamos encontrando en los logs, al final del post, adjuntamos el contenido del filtro en nuestro caso. [apache-hacks] enablednbsp; = true portnbsp;nbsp;nbsp;nbsp; = http,https filternbsp;nbsp; = apache-hacks actionnbsp;nbsp; = iptables-multiport[name=AtaqueApache, port=http,https] sendmail-buffered[name=AtaqueApache, lines=5, dest=y...@mail.com] logpathnbsp; = /var/www/vhosts/*/statistics/logs/access_log maxretry = 3 En el ultimo caso, hemos creado un fichero apache-hacks.conf en el directorio filters.d, para empezar podemos agregar entradas como estas: failregex = ^HOST -.*”(GET|POST).*\?.*passthru.* HTTP\/.*$ ^HOST -.*”(GET|POST).*\?.*system.* HTTP\/.*$ Y mas adelante agregar nuevas reglas. Con estos 4 casos, podemos evitar algunos de los intentos de ataque mas comunes, pero no podemos ni por un momento pensar que con solo aplicar esto estamos a salvo. Saludos, 2013/10/3 Rodrigo Pichiñual Norin rodrigo.pichin...@gmail.com Elio, me puedes explicar este trozo de codigo y para que sirve? [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port=http,https] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 esta habilidato apache-badbots (enabled = true) utiliza el filtro apache-badbots ubicado en el directorio filter.d action = ? logpath= donde busca los log para actuar bantime = ? ( se que es timepo de banneo) maxretry = ? ( un solo intent ) gracias 2013/10/3 Elio Bastias, Project Managers elio.bast...@gmail.com Buenos Días, Ignacio, Hay muchas formas para poder evitarlos: 1) Una es colocar un router con algún IDS, tipo Snort, ú otro para que la carga se haga en el router y no en el servidor DNS.- 2) Podes utilizar fail2ban, en otro hilo estamos discutiendo algo similar, te pego una de las posibles config que se puede hacer, esto es de uno de los foristas, para que te orientes: había un problema similar con unos de mi vps, al revisar los logs full ataques, pero con pocas cosas los detuve, te explico a ver que te sirve: 1.- SSH: Cambie el puerto por Defecto. 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista Negra de Ips de Ataques). 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): [DEFAULT] # ignoreip can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = tu ip. # bantime is the number of seconds that a host is banned. bantime = 36000 # A host is banned if it has generated maxretry during the last findtime # seconds. findtime = 600 # maxretry is the number of failures before a host get banned. maxretry = 3 # backend specifies the backend used to get files modification. # Available options are pyinotify, gamin, polling and auto. # This option can be overridden in each jail as well. # # pyinotify: requires pyinotify (a file
Re: [CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
DNS tiene dos cosas: 1- Tener una configuracion CERO recursividad y tratar de hacer FORWARD a todo lo que no puedas solucionar. 2- NUNCA permitir conexion tcp al puerto 53 y si tienes que definir SLAVES de tus zonas, intenta configurar bien las zonas. Por demás: iptables -A INPUT -s 0/0 -dport 53 -p tcp -j DROP o REJECT iptables -A INPUT -s 0/0 -dport 53 -p udp -j ACCEPT Y claro muy importante yum update o aptitude update con frecuencia Saludos, David El 3 de octubre de 2013 10:39, Elio Bastias, Project Managers elio.bast...@gmail.com escribió: Rodrigo, Buenos Días, Como estas, te paso un link, en donde te explica un poco mas detallado cada una de las líneas, y otros temas: http://www.fail2ban.org/wiki/index.php/Talk:Apache *básicamente apache-badbots* Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos. te paso algunos ejemplos: *apache-tcpwrapper:* Bloquea con el fichero /etc/hosts.deny los hosts que se intentan conectar a dominios protegidos con contraseña (estos fallos de autenticación aparecen en el error_log)*[* *apache-tcpwrapper]* enablednbsp; = true filternbsp;nbsp; = apache-auth actionnbsp;nbsp; = hostsdeny logpathnbsp; = /var/www/vhosts/*/statistics/logs/error_log maxretry = 6 *apache-badbots* Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos.*** *[apache-badbots] enablednbsp; = true filternbsp;nbsp; = apache-badbots actionnbsp;nbsp; = iptables-multiport[name=BadBots, port=http,https] sendmail-buffered[name=BadBots, lines=5, dest=y...@mail.com] logpathnbsp; = /var/www/vhosts/*/statistics/logs/access_log bantimenbsp; = 172800 maxretry = 1 # Para prevenir ataques de inyeccion de codigo *php-url-fopen*. Bloqueamos los hosts, que intentan una inyeccion de código del tipo: GET /index.php?n=http://www.dominio.com/fichero.htm [php-url-fopen] enabled = true portnbsp;nbsp;nbsp; = http,https filternbsp; = php-url-fopen logpath = /var/www/vhosts/*/statistics/logs/access_log maxretry = 1 # Evitamos ataques de ips que accedan a urls que contengan passthru o system o similares *apache-hacks*: Bloquea los hosts que acceden a urls sospechosas, haciendo un SCAN o directamente acceden a urls intentando inyectar llamadas al sistema desde php (system, passthru…) esta regla se va rellenando con las expresiones que vamos encontrando en los logs, al final del post, adjuntamos el contenido del filtro en nuestro caso. [apache-hacks] enablednbsp; = true portnbsp;nbsp;nbsp;nbsp; = http,https filternbsp;nbsp; = apache-hacks actionnbsp;nbsp; = iptables-multiport[name=AtaqueApache, port=http,https] sendmail-buffered[name=AtaqueApache, lines=5, dest=y...@mail.com ] logpathnbsp; = /var/www/vhosts/*/statistics/logs/access_log maxretry = 3 En el ultimo caso, hemos creado un fichero apache-hacks.conf en el directorio filters.d, para empezar podemos agregar entradas como estas: failregex = ^HOST -.*”(GET|POST).*\?.*passthru.* HTTP\/.*$ ^HOST -.*”(GET|POST).*\?.*system.* HTTP\/.*$ Y mas adelante agregar nuevas reglas. Con estos 4 casos, podemos evitar algunos de los intentos de ataque mas comunes, pero no podemos ni por un momento pensar que con solo aplicar esto estamos a salvo. Saludos, 2013/10/3 Rodrigo Pichiñual Norin rodrigo.pichin...@gmail.com Elio, me puedes explicar este trozo de codigo y para que sirve? [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port=http,https] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 esta habilidato apache-badbots (enabled = true) utiliza el filtro apache-badbots ubicado en el directorio filter.d action = ? logpath= donde busca los log para actuar bantime = ? ( se que es timepo de banneo) maxretry = ? ( un solo intent ) gracias 2013/10/3 Elio Bastias, Project Managers elio.bast...@gmail.com Buenos Días, Ignacio, Hay muchas formas para poder evitarlos: 1) Una es colocar un router con algún IDS, tipo Snort, ú otro para que la carga se haga en el router y no en el servidor DNS.- 2) Podes utilizar fail2ban, en otro hilo estamos discutiendo algo similar, te pego una de las posibles config que se puede hacer, esto es de uno de los foristas, para que te orientes: había un problema similar con unos de mi vps, al revisar los logs full ataques, pero con pocas cosas los detuve, te explico a ver que te sirve: 1.- SSH: Cambie el puerto por Defecto. 2.- Definir Buenas Reglas Iptables y Shorewall (Administrar una Lista Negra de Ips de Ataques). 3.- Fail2ban: (Luego de Investigar mucho logre esta configuración): [DEFAULT] # ignoreip can be an IP address, a CIDR
Re: [CentOS-es] Como evito ataque DDoS a servidor DNS por iptables
hola pero desde el punto de vista del servidor DNS en lo que respecta de la configuracion como puedo evitar esos ataques DDoS y por medio de iptables sin necesidad de utilizar el software fail2ban, tienen alguna configuracion al detalle de este tipo de configuracion saludos El 3 de octubre de 2013 08:46, David González Romero dgrved...@gmail.comescribió: DNS tiene dos cosas: 1- Tener una configuracion CERO recursividad y tratar de hacer FORWARD a todo lo que no puedas solucionar. 2- NUNCA permitir conexion tcp al puerto 53 y si tienes que definir SLAVES de tus zonas, intenta configurar bien las zonas. Por demás: iptables -A INPUT -s 0/0 -dport 53 -p tcp -j DROP o REJECT iptables -A INPUT -s 0/0 -dport 53 -p udp -j ACCEPT Y claro muy importante yum update o aptitude update con frecuencia Saludos, David El 3 de octubre de 2013 10:39, Elio Bastias, Project Managers elio.bast...@gmail.com escribió: Rodrigo, Buenos Días, Como estas, te paso un link, en donde te explica un poco mas detallado cada una de las líneas, y otros temas: http://www.fail2ban.org/wiki/index.php/Talk:Apache *básicamente apache-badbots* Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos. te paso algunos ejemplos: *apache-tcpwrapper:* Bloquea con el fichero /etc/hosts.deny los hosts que se intentan conectar a dominios protegidos con contraseña (estos fallos de autenticación aparecen en el error_log)*[* *apache-tcpwrapper]* enablednbsp; = true filternbsp;nbsp; = apache-auth actionnbsp;nbsp; = hostsdeny logpathnbsp; = /var/www/vhosts/*/statistics/logs/error_log maxretry = 6 *apache-badbots* Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos.*** *[apache-badbots] enablednbsp; = true filternbsp;nbsp; = apache-badbots actionnbsp;nbsp; = iptables-multiport[name=BadBots, port=http,https] sendmail-buffered[name=BadBots, lines=5, dest=y...@mail.com] logpathnbsp; = /var/www/vhosts/*/statistics/logs/access_log bantimenbsp; = 172800 maxretry = 1 # Para prevenir ataques de inyeccion de codigo *php-url-fopen*. Bloqueamos los hosts, que intentan una inyeccion de código del tipo: GET /index.php?n=http://www.dominio.com/fichero.htm [php-url-fopen] enabled = true portnbsp;nbsp;nbsp; = http,https filternbsp; = php-url-fopen logpath = /var/www/vhosts/*/statistics/logs/access_log maxretry = 1 # Evitamos ataques de ips que accedan a urls que contengan passthru o system o similares *apache-hacks*: Bloquea los hosts que acceden a urls sospechosas, haciendo un SCAN o directamente acceden a urls intentando inyectar llamadas al sistema desde php (system, passthru…) esta regla se va rellenando con las expresiones que vamos encontrando en los logs, al final del post, adjuntamos el contenido del filtro en nuestro caso. [apache-hacks] enablednbsp; = true portnbsp;nbsp;nbsp;nbsp; = http,https filternbsp;nbsp; = apache-hacks actionnbsp;nbsp; = iptables-multiport[name=AtaqueApache, port=http,https] sendmail-buffered[name=AtaqueApache, lines=5, dest= y...@mail.com ] logpathnbsp; = /var/www/vhosts/*/statistics/logs/access_log maxretry = 3 En el ultimo caso, hemos creado un fichero apache-hacks.conf en el directorio filters.d, para empezar podemos agregar entradas como estas: failregex = ^HOST -.*”(GET|POST).*\?.*passthru.* HTTP\/.*$ ^HOST -.*”(GET|POST).*\?.*system.* HTTP\/.*$ Y mas adelante agregar nuevas reglas. Con estos 4 casos, podemos evitar algunos de los intentos de ataque mas comunes, pero no podemos ni por un momento pensar que con solo aplicar esto estamos a salvo. Saludos, 2013/10/3 Rodrigo Pichiñual Norin rodrigo.pichin...@gmail.com Elio, me puedes explicar este trozo de codigo y para que sirve? [apache-badbots] enabled = true filter = apache-badbots action = iptables-multiport[name=BadBots, port=http,https] sendmail-buffered[name=BadBots, lines=5, dest=tu email] logpath = /home/*/logs/access.log bantime = 172800 maxretry = 1 esta habilidato apache-badbots (enabled = true) utiliza el filtro apache-badbots ubicado en el directorio filter.d action = ? logpath= donde busca los log para actuar bantime = ? ( se que es timepo de banneo) maxretry = ? ( un solo intent ) gracias 2013/10/3 Elio Bastias, Project Managers elio.bast...@gmail.com Buenos Días, Ignacio, Hay muchas formas para poder evitarlos: 1) Una es colocar un router con algún IDS, tipo Snort, ú otro para que la carga se haga en el router y no en el servidor DNS.- 2) Podes utilizar fail2ban, en otro hilo estamos discutiendo algo similar, te pego una de las posibles config que se puede
Re: [CentOS-es] Proteger http con fail2ban
A mi por lo menos me ha estado funcionando muy bien el CSF para los SYN_FLOOD, conexiones múltiples y exceso de peticiones. Llevan 4 dias atacando uno de nuestros webserver y el primer dia lo tumbaron 3 veces, hasta que aplicamos parametros respectivos en CSF (que finalmente lo traduce a IPTABLES). Saludos! El 2 de octubre de 2013 20:17, David González Romero dgrved...@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.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 dgrved...@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.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@fail2...@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.ca...@sie-group.net Web: http://www.sie-group.net/ Cd. Reynosa
Re: [CentOS-es] Proteger http con fail2ban
Yo estaba igual los chino y rusos queriendo usar mi servidor de correo, aplicaron de todo, con fail2ban, hice una lista de ip las banee todas con el shorewall y mas nunca tuve problemas, lo importante es revisar los logs, y ver todos los ataques, eso es fundamental, cuando los baneas o les mandas msgs de baneos o de intentos por ssh o ftp soeces ya no lo intentan mas, todo esta en ponerse paranoico, Saludos, El 3 de octubre de 2013 11:06, Carlos Tirado Elgueta carlos.tir...@gmail.com escribió: A mi por lo menos me ha estado funcionando muy bien el CSF para los SYN_FLOOD, conexiones múltiples y exceso de peticiones. Llevan 4 dias atacando uno de nuestros webserver y el primer dia lo tumbaron 3 veces, hasta que aplicamos parametros respectivos en CSF (que finalmente lo traduce a IPTABLES). Saludos! El 2 de octubre de 2013 20:17, David González Romero dgrved...@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.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 dgrved...@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.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@fail2...@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
Re: [CentOS] Historical Data related to CPU,IO and Memory
W dniu 2013-10-02 03:18, Kaushal Shriyan pisze: Hi, Are there any utilities or tools to look at historical data of Memory, CPU Utilization or IO activity on CentOS 6.4 or 5.9 Version? For example the how much the memory was consumed for the period of last six months. Regards, Kaushal Munin ? I.Piasecki ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Enterprise Class Hard Drive - Scam Warning
On 02/10/2013 17:28, Stephen Harris wrote: And name the retailer... +1000 Come on, this isn't the BBC, name the retailer and the manufacturer... -- Regards, Giles Coochey, CCNP, CCNA, CCNAS NetSecSpec Ltd +44 (0) 8444 780677 +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CIFS Share with encrypted credentials
On 02/10/13 06:40, Eero Volotinen wrote: This is really stupid idea, don't even try to do it. Why not give a reason why it is a **stupid** idea??? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] About Memory mirroring
Greetings, Was wondering if any software exists for mirroring memory across hosts like what drbd does for disks. I am somewhat aware of copying of a VM's memory when a live migration is done. Another query, as I have not seen too many VM migrations, is that what happens to the memory contents such as data yet to be written onto disk, states etc happens when one of the RHCS cluster hosts which is running VM fail: does the cluster restart the machine? An example perhaps would be suppose the VM is running a movie what would the user's experience would be. I tried it on cluster with ctdb. The movie simply restarted. Any experiences? -- Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 104, Issue 2
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of CentOS-announce digest...
Today's Topics:
1. CEBA-2013:1400 CentOS 6 setup Update (Karanbir Singh)
2. CEBA-2013:1401 CentOS 6 qemu-kvm Update (Karanbir Singh)
--
Message: 1
Date: Wed, 2 Oct 2013 16:45:47 +
From: Karanbir Singh kbsi...@centos.org
Subject: [CentOS-announce] CEBA-2013:1400 CentOS 6 setup Update
To: centos-annou...@centos.org
Message-ID: 20131002164547.ga65...@n04.lon1.karan.org
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2013:1400
Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-1400.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
f3baabe199eabf0c11866c1c076f0c6bc01abe0c1cab20aa3348cd8e1c967031
setup-2.8.14-20.el6_4.1.noarch.rpm
x86_64:
f3baabe199eabf0c11866c1c076f0c6bc01abe0c1cab20aa3348cd8e1c967031
setup-2.8.14-20.el6_4.1.noarch.rpm
Source:
6cd2835e633e6af4c072f1e444dc150aa91cb96bf92c1ca84321e2bed2b54377
setup-2.8.14-20.el6_4.1.src.rpm
--
Karanbir Singh
CentOS Project { http://www.centos.org/ }
irc: z00dax, #cen...@irc.freenode.net
--
Message: 2
Date: Wed, 2 Oct 2013 16:52:02 +
From: Karanbir Singh kbsi...@centos.org
Subject: [CentOS-announce] CEBA-2013:1401 CentOS 6 qemu-kvm Update
To: centos-annou...@centos.org
Message-ID: 20131002165202.ga...@n04.lon1.karan.org
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2013:1401
Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-1401.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
9a5d53661265a21e2c01437bfa501c89a97931b5d9d204f85e9ac9a237f90123
qemu-guest-agent-0.12.1.2-2.355.0.1.el6_4.9.i686.rpm
x86_64:
d7bba07262272b8d1ba80430c0aed94c66689ad2f0bc204c0d4db73d9212a28c
qemu-guest-agent-0.12.1.2-2.355.0.1.el6_4.9.x86_64.rpm
927ca6ac3edc771921ac09980347a42e5fbcd1da932014a0997e0dfee0ee2104
qemu-guest-agent-win32-0.12.1.2-2.355.0.1.el6_4.9.x86_64.rpm
a40f87712412f4b6b4483f11fe8c7dbb301f1888b4d62ad172cae0b6d4ee6b28
qemu-img-0.12.1.2-2.355.0.1.el6_4.9.x86_64.rpm
031c4b40e2003851a7b062efb555382835d59a54659b396b68a4736ccd6d19b8
qemu-kvm-0.12.1.2-2.355.0.1.el6_4.9.x86_64.rpm
e8d64b86e9ae7564ae68149c8f4e9d927f1987fb816f46d9cd8caea2be2a8549
qemu-kvm-tools-0.12.1.2-2.355.0.1.el6_4.9.x86_64.rpm
Source:
5f7e087dee9073fb16ee6d3b49f6902c487d01665471ab0bfe70948d650f5449
qemu-kvm-0.12.1.2-2.355.0.1.el6_4.9.src.rpm
--
Karanbir Singh
CentOS Project { http://www.centos.org/ }
irc: z00dax, #cen...@irc.freenode.net
--
___
CentOS-announce mailing list
centos-annou...@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
End of CentOS-announce Digest, Vol 104, Issue 2
***
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] Target TRACE in CentOS
HI, I'm trying to use TRACE target of raw table but It doesn't work It's a CentOS 6.2 with kernel 2.6.32-220.7.1.el6.x86_64. lsmod | egrep -i raw|trace|log iptable_raw 2264 1 ip_tables 17831 4 iptable_raw,iptable_filter,iptable_mangle,iptable_nat xt_TRACE1060 1 ipt_LOG 5845 5 ipt_ULOG 10765 11 dm_log 10122 2 dm_mirror,dm_region_hash dm_mod 81596 14 dm_mirror,dm_log The problem is TRACE target maches but it isn't logging anything Chain PREROUTING (policy ACCEPT 380796 packets, 194521672 bytes) pkts bytes target prot opt in out source destination 6 360 TRACE tcp -- * * 0.0.0.0/0 A.B.C.D tcp dpt:443 if I use the LOG target it WORKS, but TRACE it's better for debugging, am I doing something wrong or this CentOS release has no full support for this target? Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Historical Data related to CPU,IO and Memory
Am 02.10.2013 um 03:18 schrieb Kaushal Shriyan kaushalshri...@gmail.com: Are there any utilities or tools to look at historical data of Memory, CPU Utilization or IO activity on CentOS 6.4 or 5.9 Version? For example the how much the memory was consumed for the period of last six months. http://collectd.org -- LF ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Xorg fills up /var/log/Xorg.0.log with AUDIT messages (up to system crash)
Hi, on a CentOS 6.4-workstation we have the problem, that Xorg fills up /var/log/Xorg.0.log with AUDIT messages faster than one can read. Within four hours the logfile grew to 160 MB and usually within 1-2 days applications and sometimes the OS crash because /var becomes full. Here a small extract of /var/log/Xorg.0.log: [...] [ 24272.458] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 disconnected [ 24272.487] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 connected from local host ( uid=9435 gid=577 pid=24951 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.490] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 disconnected [ 24272.500] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 30 disconnected [ 24272.516] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 connected from local host ( uid=9435 gid=577 pid=24948 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.516] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 30 connected from local host ( uid=9435 gid=577 pid=24952 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.521] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 disconnected [ 24272.549] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 connected from local host ( uid=9435 gid=577 pid=24957 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.552] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 disconnected [ 24272.564] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 30 disconnected [ 24272.575] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 connected from local host ( uid=9435 gid=577 pid=24954 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.577] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 30 connected from local host ( uid=9435 gid=577 pid=24958 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.585] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 disconnected [ 24272.612] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 connected from local host ( uid=9435 gid=577 pid=24963 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.616] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 disconnected [ 24272.628] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 30 disconnected [ 24272.630] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 connected from local host ( uid=9435 gid=577 pid=24960 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.633] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 30 connected from local host ( uid=9435 gid=577 pid=24964 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.644] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 disconnected [ 24272.673] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 connected from local host ( uid=9435 gid=577 pid=24969 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.679] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 disconnected [ 24272.691] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 30 disconnected [ 24272.692] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 connected from local host ( uid=9435 gid=577 pid=24966 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.697] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 30 connected from local host ( uid=9435 gid=577 pid=24970 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 572 [ 24272.711] AUDIT: Wed Oct 2 15:41:44 2013: 2625: client 28 disconnected [...] The client numbers are just a small repeating set, but trying to find the associated processes through the pids fails, because when the logfile entry is written, the processes are already gone. For sure these messages are associated with something the user(s) do, because as soon as nobody is logged in, these messages stop. We have lots of CentOS 6 machines, but this is the only one with such an issue, even though there are more or less the same applications running on all machines. Xorg is running with the following options (CentOS 6 default settings): /usr/bin/Xorg :0 -nr -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-jQ4DVP/database -nolisten tcp vt1 Questions: * How can one find out which processes are responsible for these audit messages? * How can I stop auditing completely? With CentOS 5 Xorg ran with audit 0 and I was unable to find the place where the audit level is set. * (more generally) What's auditing good/used for anyway? Any hint is appreciated. Cheers frank [cross-posted on lopsa-tech maillist] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Enterprise Class Hard Drive - Scam Warning
From: Steve Brooks ste...@mcs.st-and.ac.uk I ordered three new Enterprise hard drives this month from a well known UK online retailer. The drives arrived as new in their anti-static packaging. Before using one of the drives in a mission critical hardware raid I checked the SMART attributes and was amazed at what I saw; see a few of the attributes listed below There's also the grey area of the like new, refurbished (by the manufacturer, or even the vendor), etc... especially on ebay. When I did some server support for a big name, I learned that all the (very expensive) repair parts they sold to clients whose equipment was out of warranty were all refurbished parts (from other clients). JD ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Enterprise Class Hard Drive - Scam Warning
On 10/3/2013 8:36 AM, John Doe wrote: There's also the grey area of the like new, refurbished (by the manufacturer, or even the vendor), etc... especially on ebay. a LOT of 'refurbish' stuff is refurbed by 3rd parties, neither the OEM or the reseller, and then reinserted into the grey market retail stream. in these cases traceability and accountability can be hard to come by. now, its a fact that something like 80% of product returns are 100% AOK, they were returned for stupid reasons, pilot error, etc. The refurbishers often do little more than a quick functional test, relabel (if you're lucky) and repack.Big discount resellers like Fry's are notorious for stocking this sort of junk (never mind the stuff they repack in-house). -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
