Mostrando entradas con la etiqueta Administracion. Mostrar todas las entradas
Mostrando entradas con la etiqueta Administracion. Mostrar todas las entradas

22.5.13

NAGIOS - Monitoreo de servidores


la mayoria de la gente piensa q los admines no hacemos nada... y en parte es verdad, pero justamente el secreto del exito esta en q no haya nada q hacer, ya q esto quiere decir q todo funciona ok... pero para q todo funcione tenemos q estar siempre informados de lo q pasa con nuestros servers para poder ser los 1eros en enterarnos cuando hay un problema y solucionarlo antes de q escale a mayores proporciones... o alguien se de cuenta... xD

nagios es un sistema de monitoreo de servidores, apto para estructuras complejas, q cubre la mayoria de las necesidades de cualquier admin, avisandonos cuando hay una situacion fuera de lo normal en base a parametros q podemos configurar facilmente. podemos monitorear tanto servicios publicos (HTTP, SSH, FTP, MYSQL, etc) como internos (carga del micro, espacio en disco, procesos, etc).


INSTALACION


como siempre voy a describir la instalacion para debian/ubuntu, pero en el caso de los servers monitoreados voy a agregar la de centos ya que los archivos necesarios no estan en los repositorios standard y hay q hacer un par de modificaciones. lo primero que vamos a configurar es el server q va a cumplir la funcion de monitoreo de los demas (y x supuesto de si mismo). es requisito tener apache instalado ya que es usado para ingresar a la web de administracion del sistema, si todavia no lo hicieron... apt-get install apache2.

en este ejemplo vamos a llamar a este server "monitor" con la ip 192.168.1.1. una vez que esta todo listo en una consola con derechos de root (sudo para ubuntu) ingresar:

# apt-get install nagios3 nagios-plugins nagios-nrpe-plugin

durante la instalacion nos pide configurar workgroup para samba:



y despues ingresar password para administracion:



una vez terminado el proceso ya podemos loguear desde:

http://localhost/nagios3

con el usuario "nagiosadmin" y la password que configuramos antes. a la izquierda haciendo click en "hosts" podemos ver que el localhost ya esta siendo monitoreado y desde ahi entrar a la pagina de la informacion del estado gral y al detalle de los distintos servicios configurados.

...pero vamos a agregar servers para monitorear q es lo mas importante. vamos a llamar al 1ero "server1" corriendo en la ip 192.168.1.100. en este abrimos una consola con derechos de root e ingresamos:

# apt-get install nagios-nrpe-server nagios-plugins

durante la instalacion tambien pide configurar workgroup, cambiarlo si es necesario y sino dejarlo x default.

en la maquina monitor tenemos que crear un archivo de configuracion por cada server que agregamos. creamos entonces un archivo con el nombre correspondiente agregandole al final "nagios2.cfg" o sea "server1.nagios2.cfg" y lo ponemos en:

/etc/nagios3/conf.d

dentro definimos el host y los servicios a monitorear. en el siguiente ejemplo puse la carga del procesador solamente, el contenido del archivo quedaria asi:

define host{
        use             generic-host
        host_name       server1
        alias           server1
        address         192.168.1.100
}
define service{
        use                     generic-service
        host_name               server1
        service_description     Current Load
        check_command           check_nrpe_1arg!check_load
}

y reiniciamos el servicio con:

# service nagios3 restart

antes de poder ver la informacion tenemos que configurar server1 para que permita a la maquina monitor tomar los datos. esto lo hacemos desde nrpe.cfg q se encuentra en:

/etc/nagios/

buscamos la entrada "allowed_hosts" y cambiamos la ip por la del server "monitor", quedaria asi:

allowed_hosts=192.168.1.1

y reiniciamos el servicio:

# service nagios-nrpe-server restart

en el monitor ya deberia aparecer el nuevo server, del cual se puede ver la carga actual solamente (x ahora)... despues de checkear su funcionamiento podemos sumar otros servicios. todo esto se agrega al archivo de configuracion que encuentra en "monitor" (server1.nagios2.conf). algunos ejemplos son:

USUARIOS LOGUEADOS:

define service{
        use                     generic-service
        host_name               server1
        service_description     Current Users
        check_command           check_nrpe_1arg!check_users
}

ESPACIO EN DISCO:

define service{
        use                     generic-service
        host_name               server1
        service_description     Disk Space
        check_command           check_nrpe_1arg!check_hda1
}

CANTIDAD DE PROCESOS ACTIVOS:

define service{
        use                     generic-service
        host_name               server1
        service_description     Total Processes
        check_command           check_nrpe_1arg!check_total_procs
}

HTTP:

define service{
        use                     generic-service
        host_name               server1
        service_description     HTTP-Server
        check_command           check_http
}

FTP:

define service{

use generic-service
host_name remotehost
service_description FTP
check_command check_ftp
}

SSH:

define service{

use generic-service
host_name remotehost
service_description SSH
check_command check_ssh
}

SMTP:

define service{

use generic-service
host_name remotehost
service_description SMTP
check_command check_smtp
}

hay muchos otros servicios monitoreables pero son demasiados para incluirlos todos, googleando un poco se puede encontrar facilmente info al respecto. simplemente se agrega el que se necesita al archivo de configuracion, reiniciar el servicio y ya esta funcionando.


NRPE-SERVER EN CENTOS


nrpe se encarga del monitoreo de los servicios internos (carga de cpu, usuarios, disco, etc), ya que los publicos se checkean normalmente sin necesidad de acceso al servidor. como habiamos dicho antes, centos no tiene a nagios en sus repositorios por defecto asi que tenemos q descargar e instalar un par de paquetes para poder usarlo.

ya q los paquetes dependen del sistema en q se instala no puedo poner links q sirvan para todos. el 1ero es epel que se puede descargar de aca:

http://dl.fedoraproject.org/pub/epel/

y el otro es remi:

http://rpms.famillecollet.com/enterprise/

dependiendo de la version bajamos el rpm correspondiente. pongo como ejemplo los archivos de instalacion en centos6 x64:

http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

los bajamos e instalamos con rpm o sino directamente hacemos:

# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

una vez instalados ya podemos usar yum:

# yum install nagios nagios-plugins-all nrpe

y configuramos el servicio para q arranque automaticamente:

# chkconfig nrpe on

otro paso necesario en centos es configurar iptables para q permita el acceso al monitor q necesita abierto el puerto 5666:

# iptables -N NRPE
# iptables -I INPUT -s 0/0 -p tcp --dport 5666 -j NRPE
# iptables -I NRPE -s ipdelservermonitor -j ACCEPT
# iptables -A NRPE -s 0/0 -j DROP
# /etc/init.d/iptables save

solo falta arrancar el servicio:

# service nrpe start

el resto de los pasos de configuracion en nrpe.cfg son los mismos q en debian.


MODIFICAR ALERTAS DE LOS SERVICIOS


podemos establecer los porcentajes q necesitemos en cada caso para las alertas del sistema. los defaults estan bastante bien pero siempre es necesario "tocar" algo en alguno.

el 1er problema q nos encontramos normalmente es q el sistema no puede conectar al disco de sistema para checkear el espacio. esto se debe a q viene definido como "hda1", lo cual no coincide en la mayor parte de los sistemas modernos. esto se modifica tambien desde el archivo nrpe.cfg en "server1". buscamos la linea:

command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1

y la cambiamos por el q corresponda q lo podemos ver haciendo un df en la consola. desde ahi tambien modificamos los porcentajes de las alertas, en la de arriba podemos ver el del espacio en disco que envia un alerta "warning" cuando queda 20% libre y un "critical" al 10%.

para modificar la alerta de procesos modificamos:

command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200 

siendo como en el caso anterior 150 el warning y 200 el critical.


CONFIGURANDO LAS ALERTAS DE CORREO


hasta ahora todo muy lindo pero no podemos estar todo el dia mirando si hay algun problema, lo q necesitamos es q nagios nos avise cuando se da un estado de alerta. para esto lo mas usado es el envio de correo.

para usar esta caracteristica tenemos q tener postfix (o el smtp prefieran) configurado y funcionando. basicamente para instalarlo hacemos:

# apt-get install postfix

durante el proceso pide datos sobre el tipo de correo q configuramos, seleccionar "internet site". acto seguido pregunta por el dominio que es el q sale en los correos enviados. una vez finalizado editar:

/etc/postfix/main.cf

y en "myhostname" agregar el nombre del host. x ej:

myhostname= nagios.locvtvs.com

si usan un relay configurarlo en "relayhost". y reiniciar el servicio:

service postfix restart

con postfix corriendo vamos a configurar en nagios el destinatario de los correos de alerta. modificamos el archivo:

/etc/nagios3/conf.d/contacts_nagios2.cfg

q contiene algo asi:

define contact{
        contact_name                    root
        alias                           Root
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-service-by-email
        host_notification_commands      notify-host-by-email
        email                           admin@domain.com
        }

define contactgroup{
        contactgroup_name       admins
        alias                   Nagios Administrators
        members                 root
        }

simplemente cambiamos la direccion en "email" por la q necesitamos. para agregar otro contacto hay q repetir todo el bloque "define contact" con la direccion nueva y agregar el contact_name en el bloque de abajo (define contactgroup) separado por comas:

members root,otrousuario,otromas

con todo corriendo solo falta esperar (o provocar) alguna alerta para checkear el funcionamiento. personalmente lo tengo configurado para que me mande correo (q me suena en el celu) y desde ahi mismo puedo tambien levantar la web de administracion y tener mas detalles de lo q pasa. al normalizarse el servicio el sistema envia otro correo informando el nuevo estado.


16.11.12

VNC antes del login en linux (tambien con gdm3...) - error "XOpenDisplay failed (:0)"


vnc es una de las mas populares herramientas de administracion remota, ciertamente hay otras mejores pero ninguna tan standard. corre perfectamente tanto en linux como windows con una configuracion bastante sencilla y no requiere de servidores intermediarios en la conexion.

el protocolo fue desarrollado originalmente por olivetti y oracle y tanto el original como muchas versiones modernas son open source y estan bajo licenci GNU, a pesar de que hay versiones que suman caracteristicas no propias del protocolo como la transferencia de archivos y otras. vnc basicamente usa el framebuffer remoto transmitiendo eventos de mouse y teclado y recibiendo los refrescos de la pantalla del servidor.

para windows se debe instalar alguna de las versiones para usarlo, una de las mas usadas es el realVNC. en la mayoria de los linux viene como opcion del sistema en preferences->remote desktop, solo hay que activarlo y ya esta corriendo.


VNC antes del login

en linux podemos hacer casi todo desde la consola, incluido el uso de aplicaciones graficas abriendo una sesion de ssh con X, pero en contadas ocasiones necesitamos tener acceso full al escritorio remoto por alguna razon y entonces nos encontramos con el problema.

en windows vnc se lanza como servicio antes de loguear y por lo tanto podemos conectar y acceder facilmente a la pantalla de logueo como si estuvieramos delante de la maquina. en linux el server se lanza recien despues de loguear el equipo, con lo cual necesitamos alguien fisicamente para que se active, lo cual no es lo ideal la mayoria de las veces...

entre las versiones disponibles este ejemplo usa x11vnc por ser la que viene instalada por default en la mayoria de los sistemas. dando por sentado que ya esta instalada logueamos por ssh y tratamos de lanzarla sin opciones, lo cual enseguida nos tira entre otras cosas:

XOpenDisplay failed (:0)

lo cual nos dice que vnc no pudo conectar con el display y por lo tanto no se pudo lanzar... simplemente no tiene autorizacion para hacerlo.

esta autorizacion esta en el clasico archivo .Xauthority que por lo gral se encuentra en el home del usuario. ahi se almacena la famosa MIT-MAGIC-COOKIE que es requerida para la autenticacion y sin la cual nos quedamos siempre en el error anterior. lo que debemos hacer entonces es pasarle como parametro la ruta al archivo con el modificador auth de alguna de estas maneras segun donde este ubicado:

gdm:     -auth /var/gdm/:0.Xauth
            -auth /var/lib/gdm/:0.Xauth
kdm:     -auth /var/lib/kdm/A:0-crWk72
            -auth /var/run/xauth/A:0-crWk72
xdm:     -auth /var/lib/xdm/authdir/authfiles/A:0-XQvaJk
dtlogin:  -auth /var/dt/A:0-UgaaXa

quedando por ejemplo:

#x11vnc -auth /var/gdm/:0.Xauth (para gdm)


el "problema" con gdm3

hasta ahi todo esta bastante claro pero el problema lo encontramos cuando migramos a un sistema con gdm3 donde no podemos encontrar el famos archivo en ninguna de las rutas usuales. la razon es que se genera con un nombre aleatorio en cada logueo y se ubica en:

/var/run/gdm3/auth-for-locvtvs-gdm-XXXXXX/database

donde XXXXXX cambia en cada reinicio, por lo cual no podemos simplemente meter siempre la misma linea de comando sino que debemos saber puntualmente el nombre cada vez. para conocerlo podesmos hacer un ps para buscarla entre los modificadores de Xorg:

ps aux | grep auth

y una vez conocida lanzarlo de esta forma:

x11vnc -auth /var/run/gdm3/auth-for-Debian-gdm-XXXXXX/database

o aun mejor:

x11vnc -usepw -auth /var/run/gdm3/auth-for-Debian-gdm-8ixCen/database

para usar la password definida anteriormente ;)


automatizacion

el problema del cambio de nombre nos complica el tema de poder automatizarlo por medio de un script, para hacerlo debemos extraer la ruta cada vez que se inicia el sistema. en este caso podriamos usar algo asi:

ps ax | grep auth | awk '/gdm3/ { print $13 }'

esto meterlo en una variable:

variable=$(ps ax | grep auth | awk '/gdm3/ { print $13 }')
x11vnc -usepw -auth "$variable"

y agregarlo al inicio del sistema para que lo lance automaticamente.

27.5.12

fail2ban - como proteger nuestros servers de intrusos varios...

los dos ultimos fines de semana tuve q sacar intrusos de servidores q administro, nada peligroso ya q los servers estan actualizados y bastante protegidos dentro de lo posible, pero siempre esta el problema de los usuarios y el cuidado q le dan a sus contraseñas... en ambos casos se vieron comprometidas cuentas de los mismos. en la 1era lograron entrar x ssh y correr un script q enviaba spam, en la 2da simplemente un login de correo con el mismo proposito pero enviando una scam tipica, este era el texto:

Please be informed that you have £100,000 British Pounds Lodged in our Western Union to transfer to you as winner of ECOWAS Lottery Jackpot.

Please Contact: milton_daniel17@yahoo.com

al entrar hizo un par de pruebas enviandose a direcciones propias q son las siguientes:

kenblast2003@yahoo.com
kenblastall@hotmail.com
motide7@aol.com

no fue lo suficientemente inteligente para borrar ni siquiera los correos q enviaba, simplemente consiguio la pass del usuario y me puso en cola 10 millones de correos q se estuvieron enviando durante unas horas hasta q me di cuenta. creo q penso q siendo domingo no lo veria hasta el lunes pero x suerte suelo checkear logs bastante seguido.

los spammers/scammers estan en la escala mas baja de la porqueria existente en internet, tanto desde el punto de vista del usuario q recibe montones de correos q no le importan como del administrador q trata de hacer todo lo posible para minimizar el impacto en el buzon del usuario final.

pero el peligro no esta solo en parar la basura sino tambien en proteger nuestros servers ya q son una codiciada presa para ellos, la oportunidad de hacer unos cuantos billetes a costa de nuestro buen nombre... je

asi tambien tenemos los miles de script kiddies q pasan el dia con sus programas de fuerza bruta y sus diccionarios probando combinaciones de user/pass y algun ocasional hacker o aprendiz q puede ocasionar algo mas de trabajo. mas de uno se sorprenderia al ver los logs de un server publico, al final de la entrada voy a pastear algunos para q vean el nivel de los ataques...

para detener este tipo de ataques automatizados existe fail2ban, q es un software q en base a los logs del sistema puede bannear IPs en base a intentos fallidos de logueo. a pesar de tenerlo instalado en la mayoria de los servers tuve q ponerlo en TODOS y ajustar la configuracion para q sea todavia mas agresiva. de paso aprovecho para hacer esta entrada para q vean q no es nada dificil de instalar y configurar y ciertamente hace darse x vencido a la mayoria de los intrusos.


instalacion

a pesar de q son muy parecidas voy a explicar la instalacion tanto para centos/redhat como para debian/ubuntu. para el 1ero tenemos q descargarlo desde:

http://sourceforge.net/projects/fail2ban/

lo extraemos con:

tar xvf fail2ban-x.x.x.tar.bz2

despues...

cd fail2ban-x.x.x
python setup.py install

a continuacion lo agregamos al arranque del sistema copiando el siguiente archivo:

cp /files/redhat-initd /etc/init.d/fail2ban

y despues...

chkconfig --add fail2ban
chkconfig fail2ban on
service fail2ban start

en debian/ubuntu lo podemos bajar de los repositorios con:

apt-get install fail2ban (sudo en ubuntu)

y nos ahorramos todo el proceso anterior.


configuracion


lo siguiente es configurar las "jails" para los servicios q queremos proteger. para eso vamos a /etc/fail2ban y editamos el archivo jail.conf haciendo una copia de seguridad antes por las dudas...

la configuracion puede variar un poco de una version a otra pero las opciones son mas o menos las mismas siempre. en debian x ejemplo, las acciones, tiempos de banneo, etc vienen definidas al principio de manera gral o se pueden personalizar despues en cada jail.

lo primero es setear las redes e IPs seguras, o sea las q queremos q el sistema no blockee nunca, como el rango de nuestra propia lan o direcciones de usuarios del sistema. esto se hace modificando el campo "ignoreip", por ejemplo:

ignoreip = 127.0.0.1 192.168.0.0/24 200.53.23.1 10.0.0.0/25

mas abajo tenemos los tiempos y situaciones del blockeo, q podemos dejar como estan o editarlas como queramos. son las siguientes:

bantime: es la cantidad de segundos q una IP es banneada (default 600).
findtime: un host es banneado si se loguea erroneamente tantas veces como la cantidad en "maxretry" dentro del "findtime" (default 600seg).
maxretry: es el numero de intentos fallidos antes de ser blockeado.

pasamos ahora a configurar las jails (carceles). una de las mas usadas es la de ssh asi q empecemos x esa, vamos hasta "[ssh]" y x default (en debian x lo menos) ya la tenemos activada. sale mas o menos asi:

[ssh]
enabled = true
port    = ssh
filter    = sshd
logpath = /var/log/auth.log
maxretry = 6

y asi para centos:

[ssh-iptables]
enabled    = true
filter    = sshd
action    = iptables[name=SSH, port=ssh, protocol=tcp]
                 sendmail-whois[name=SSH, dest=root, sender=fail2ban@fail2ban]
logpath    = /var/log/secure
maxretry = 6

lo q mas nos interesa es q el enabled este en "true" (activada) y el logpath q es la ruta del log de seguridad del sistema, esta cambia de un sistema a otro como se puede ver. en debian vemos q falta el campo "action", eso es xq viene definido antes en la seccion "actions" con el campo "banaction".

en el action de centos vemos dos acciones, iptables y sendmail whois. la 1era crea una regla de iptables blockeando la IP y la 2da envia un correo con un whois de la misma al destinatario configurado (root en este caso).

vamos a crear alguna jail mas x si no quedo muy claro, postfix en centos:

[postfix-tcpwrapper]
enabled    = true
filter    = postfix
action    = hostsdeny[file=/etc/hosts.deny]    (ruta al archivo hosts.deny)
      sendmail[name=Postfix, dest=root]
logpath    = /var/log/maillog
bantime    = 6000

en debian:

[postfix]
enabled    = true
port    = smtp,ssmtp
filter    = postfix
logpath    = /var/log/mail.log

y asi tenemos todo tipo de jails para ftp, http y todos los servicios y la mayoria de los ataques posibles. seria interminable y no tendria mucho sentido explicarlas una a una, simplemente experimentando un poco se pueden activar bastante facil.


roundcube


roundcube es un cliente de webmail relativamente nuevo (todavia esta en beta) con muchisimas opciones y una interfaz q no tiene nada q envidiarle a ninguna otra. en mi humilde opinion es muy superior al eterno squirrelmail q parece casi prehistorico al darle una mirada a uno y el otro.

los logueos de correo pueden ser blockeados con la jail "postfix" o el MTA q usemos como vimos antes, pero tambien se puede dar el caso (como me paso a mi) de que el webmail corra en un server mientras q el MTA esta en otro. en este caso nos vemos obligados a agregar la IP del 1ero en la lista de ignoradas del fail2ban del 2do para no bannear a todos los usuarios ya q la direccion de origen del logueo es siempre la misma para todos.

para solucionar esto podemos usar un plugin escrito x matt rude, q se puede descargar desde aca:

http://mattrude.com/projects/roundcube-fail2ban-plugin/

hay q copiar el contenido dentro del directorio de plugins de roundcube (roundcube/plugins) y despues editar el contenido del archivo main.inc.php q esta dentro del directorio "config", agregando en la seccion de plugins la siguiente linea:

$rcmail_config['plugins'] = array('fail2ban');

con esto se crea un nuevo archivo llamado userlogins en la carpeta logs conteniendo solo los intentos fallidos q usamos para el fail2ban creando una nueva jail:

[roundcube]
enabled    = true
port    = http,https
filter    = roundcube
logpath    = /pathderouncube/logs/userlogins


el eterno punto debil


obviamente esto no nos deja 100% a salvo pero ayuda bastante, de todas formas nunca es bueno confiarnos demasiado y mantener siempre los sistemas actualizados, los permisos bien configurados y los usuarios con las passwords mas complejas posibles... aunque siempre seran usuarios y siempre cabe la posibilidad de q hagan click donde no deben entregando sus datos ante cualquier loteria de turquia o una herencia del principe de liechtenstein...

... ese es el verdadero punto debil.


apendix


como habia prometido copio unas horas del log de fail2ban en un servidor de correo publico (no muy grande) para q vean la cantidad de conexiones blockeadas. la mayoria son de postfix pero hay alguna de ssh.

2012-05-24 04:02:41,098 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.49.25.205
2012-05-24 04:14:01,114 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.224.163.183
2012-05-24 04:52:59,128 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 186.105.151.68
2012-05-24 05:01:16,142 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 90.170.212.117
2012-05-24 05:01:32,156 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.172.162.35
2012-05-24 05:31:24,170 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 188.138.115.237
2012-05-24 05:54:26,188 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 181.1.142.88
2012-05-24 05:56:43,202 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.139.154.117
2012-05-24 06:04:14,217 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 181.14.149.157
2012-05-24 06:42:19,230 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.16.233.253
2012-05-24 06:47:21,242 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 189.45.204.138
2012-05-24 06:54:42,259 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 41.79.176.10
2012-05-24 07:13:24,273 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 181.14.133.18
2012-05-24 07:14:32,287 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 168.226.249.18
2012-05-24 07:18:01,301 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 168.226.165.193
2012-05-24 07:19:59,315 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 181.14.130.174
2012-05-24 07:28:02,330 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 182.71.75.106
2012-05-24 07:58:49,604 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.31.98.41
2012-05-24 08:02:34,618 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 181.14.150.101
2012-05-24 08:03:04,633 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.139.223.41
2012-05-24 08:16:23,647 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 122.163.39.30
2012-05-24 08:28:23,675 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.139.221.178
2012-05-24 08:37:23,690 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 200.45.10.100
2012-05-24 08:50:45,706 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.220.206.251
2012-05-24 09:13:29,721 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.166.153.58
2012-05-24 09:14:36,738 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 113.161.75.97
2012-05-24 09:29:53,760 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 168.226.165.155
2012-05-24 10:03:37,798 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 181.14.140.243
2012-05-24 10:06:49,816 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 58.186.2.73
2012-05-24 10:11:35,835 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 123.26.160.109
2012-05-24 10:12:47,849 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 186.134.140.73
2012-05-24 10:14:29,866 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 123.180.71.142
2012-05-24 10:14:51,880 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 181.14.127.147
2012-05-24 10:37:40,897 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 200.45.10.239
2012-05-24 10:44:08,913 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 190.172.97.222
2012-05-24 10:54:20,928 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 181.14.180.85
2012-05-24 11:02:05,942 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 168.226.165.130
2012-05-24 11:11:21,956 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 200.74.100.150
2012-05-24 11:27:45,974 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 84.15.191.254
2012-05-24 11:30:49,993 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 122.163.197.52
2012-05-24 11:37:58,014 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 181.14.186.253
2012-05-24 11:51:08,040 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 115.84.93.94
2012-05-24 12:18:00,057 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 123.180.84.251
2012-05-24 12:31:09,010 fail2ban.actions: WARNING [ssh-iptables] Ban 66.85.142.166
2012-05-24 12:33:16,075 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 82.114.94.6
2012-05-24 12:36:31,090 fail2ban.actions: WARNING [postfix-tcpwrapper] Ban 101.99.12.1

28.9.11

/bin/rm: Argument list too long - Como solucionarlo.

hoy me volvi a encontrar con este problema y me decidi a escibir una entrada para los q se lo encuentran x 1era vez... la 1era vez suele ser traumatica... xD

uno de los servers en los q trabajo esta todo el tiempo bajando datos q almacena en un directorio del sistema generando una gran cantidad de archivos q se van acumulando bastante rapido. dado q no uso personalmente los datos y no tengo muy claro hasta cuando sirven, suelo dejar q se acumulen hasta q el espacio en disco empieza a escasear y ahi es cuando viene el problema. la cantidad de archivos es tan grande q al intentar algo tan simple como un rm *.* la consola me devuelve:

/bin/rm: Argument list too long


el problema

como decia antes suele ser bastante traumatico encontrarse con q no se puede hacer algo tan basico como borrar archivos. buscando tanto la solucion como la causa me encontre con la interesante explicacion de que no es un problema del comando en si sino del kernel de linux.

traduccion de la debian wiki:

el limite afecta la funcion execve() del kernel, q es usada x todas las otras funciones exec() (execl, execlp, execle,etc). La funcion trabaja creando un buffer de 128k al final del espacio de memoria y copiando el comando y el entorno para el nuevo proceso en este espacio. entonces el kernel carga el nuevo programa en memoria, setea sus punteros argv y endv, y salta al punto de entrada del programa. El mensaje de error "argument list too long" es causado por el codigo de error !E2BIG, siendo devuelto por la funcion execve(), cuando es incapaz de introducir el argumento y entorno suministrados dentro del buffer de 128k.

x suerte el usuario normal no tiene q luchar normalmente con directorios q contienen tantos archivos... entonces me dio curiosidad de ver de cuantos archivos hablamos en realidad (mientras escribo esto voy haciendo el proceso), entonces meto en la consola:

# ls | wc -l

... y despues de un buen rato me devuelve... 1146724!!


la solucion

para poder borrar los archivos lo q tenemos q hacer es pasarselos a rm como argumento de a poco usando xargs. la linea q recomienda la misma debian wiki es esta:

find ./ -name '*' -print0 | xargs -0 -n 10 rm

hacemos un find de todos los archivos (*) y x medio de xargs se los vamos pasando a rm de a 10 (-n 10). el "-print0" en find y el -0 en xargs son para no tener problemas con los espacios en blanco de los archivos si es q los tienen, sino se pueden eliminar.

hay otras soluciones posibles como ls | xargs rm o ir borrando x partes pero la anterior es la mas simple y efectiva.