load average por encima de 200

Hola, he experimentado una carga de más de 200. Como es lógico ha tumbado la máquina. Es posible que esté siendo atacado o más bien puede ser problema hardware. Que opináis? Adjunto captura de pantalla.

 

Tendrás que ver más información. Por ejemplo, con un server-status de Apache quizá puedas ver qué sitio web estaba siendo atacado (si viene por ahí el tema).
Otra pregunta es por qué el fail2ban usa tantos recursos, que no sé si es pero el ataque o el fail2ban consumiendo CPU

 

Era la fuente de alimentación que estaba fallando y se sobrecalentaba la cpu. El tema que comentas sobre Fail2ban es cierto que el consumo es muy elevado. Voy a revisar configuración de jails que seguro están mal y reverbera.

 

Hola,

Una pregunta que no viene al caso. ¿Tienes NFS activado en tu SO o lo usas para algo? Por que veo muchos subprocesos rpciod, y si lo tienes NFS y no lo usas, eso es una puerta abierta de par en par para posibles atacantes. Te recomiendo que lo desactives.
Aquí tienes más info: http://www.cyberciti.biz/faq/centos-redhat-rhel-fedora-remove-nfs-services/

 

Buen aporte @f.villalba

 

Sobre el consumo excesivo de fail2ban configúrale una memoria máxima permitida.
https://www.howtoforge.com/community/threads/optimize-your-fail2ban-memory-use-by-90.49666/

 

Otro buen aporte @f.villalba
Gracias

 

He probado la solución de reducción de memoria utilizada por fail2ban en Centos 6.6 y al reiniciar el servicio lanza error:

CODE, HTML o PHP Insertado:

ConfigParser.ParsingError: File contains parsing errors: /etc/fail2ban/fail2ban.
conf

En el enlace que comenta @f.villalba (https://www.howtoforge.com/community/threads/optimize-your-fail2ban-memory-use-by-90.49666/) la configuración es para Debian y parece que hay divergencia en la sintaxis.

 

Mira que ruta tiene fail2ban para CentOS. Ahora mismo no me la sé de memoria. Me tendría que instalar una centos en una vm pero ando pasando de binario a decimal unos ejercicios de FP info...

 

Vale en centos /etc/fail2ban debería ser...

 

/etc/fail2ban/fail2ban.conf

 

La opción (corresponde a open files) creo que sería:

CODE, HTML o PHP Insertado:

ulimit -n 256

 

Opciones del man:

CODE, HTML o PHP Insertado:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 2061997
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 2061997
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

 

vi /etc/fail2ban/fail2ban.conf

ulimit -s 256 (256 es el tamaño de la memoria que va a poder usar fail2ban del servidor)

Lo pones en:
FAIL2BAN_OPTS=""

Seguramente tengas algún script kiddie intentando joder tu server. De ahí que veas tanto consumo de cpu. Voi a terminar los malditos ejercicios de binario a decimal.

Acuérdate de reiniciar fail2ban para que guarde cambios.

Salu2,

 

El problema de la alta carga era debido a un fallo en la fuente de alimentación de la máquina. Me lo confirmaron desde el Data Center. Las comprobaciones que realicé eran normales en cuanto a procesos PHP y demonio httpd. MySQL está bien optimizado. No había intento de intrusión por fuerza bruta y descartado ataque DoS y DDoS.

No me preocupa mucho la utilización de memoria que necesita Fail2ban, no utiliza ni el 0,03 de la RAM. Sin embargo todo lo que sea aprendizaje de optimización está muy bien.

Me parece que estamos tod@s aprendiendo a marchas forzadas.

Agradezco mucho tu apoyo @f.villalba

 

Ahora que lo dices fail2ban veo que te coje un 0,7 por ciento de la cpu. Algo correcto. ¿Ósea que la carga alta entonces era por problemas de la fuente? Interesante...

 

Efectivamente. Al descartar cualquier anomalía software, avisé al Data Center y me confirmaron el problema hardware que me rondaba la cabeza.

 

Joder hoy ya he aprendido dos cosas. Una fuente en un servidor jodida puede generar carga alta y en clase se ha quemado un pc y no se ha jodido la fuente de alimentación. Ya te digo cada día se aprende algo...

 

Revisando el comentario que hiciste sobre NFS (rpciod) había un bug en el kernel que también parcheé. https://bugzilla.redhat.com/show_bug.cgi?id=485339

 

Esta es la diferencia entre la carga por encima de 200 del sábado y la de ahora mismo: