agente nagios para linux

29 de abril de 2011

Si tenemos Nagios, podemos monitorizar maquinas remotas utilizando el agente de Nagios para Linux o para Windows.
Si la maquina remota es un Windows, podemos instalar el NSClient++. Si la maquina es un Linux, podemos instalar el NRPE. Explicaré cómo se instala el NRPE y cómo se configura Nagios para hacer consultas a esta maquina remota.

Tenemos que tener presente dos tipos de maquinas: la maquina con Nagios Server (por ejemplo 192.168.1.2) y la maquina remota (por ejemplo 192.168.1.3). El funcionamiento es el siguiente: en los dos extremos hay que instalar un NRPE de forma que el daemon de la maquina remota ejecutará los comandos que nosotros definamos, por ejemplo check_disck, check_swap, check_users, check_oracle, etc.

En la maquina remota hacemos:

# wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz
# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz

# useradd nagios
# passwd nagios
Nota: recomiendo editar el /etc/passwd y ponerle un Shell /bin/false a este usuario para que no pueda hacer Login en el sistema.
# tar -xzvf nagios-plugins-1.4.15.tar.gz
# cd nagios-plugins-1.4.15
# export LDFLAGS=-ldl
# ./configure --with-nagios-user=nagios --with-nagios-group=nagios
# make
# make install 
# chown nagios.nagios /usr/local/nagios
# chown -R nagios.nagios /usr/local/nagios/libexec/

# apt-get install xinetd libssl-dev
# tar xvfz nrpe-2.12.tar.gz
# cd nrpe-2.12

# ./configure
# make all
# make install-plugin
# make install-daemon
# make install-daemon-config
# make install-xinetd
Editar /etc/xinetd.d/nrpe para aceptar peticiones solo de nuestro Nagios Server:
only_from       = 127.0.0.1 192.168.1.2
La IP 192.168.1.2 es la de nuestra maquina Nagios Server.
# /etc/init.d/xinetd restart
Pruebas de funcionamiento:
# netstat -ant | grep 5666
tcp        0      0 0.0.0.0:5666            0.0.0.0:*               LISTEN  
# /usr/local/nagios/libexec/check_nrpe -H localhost
NRPE V2.12
Modificar los comandos disponibles para nuestra maquina remota. Editar el /usr/local/nagios/etc/nrpe.cfg y modificar los comandos a nuestro gusto. Yo he creado una consulta llamada check_disk que me dirá el estado de disco /dev/sda1:
command[check_disk]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/sda1
En la maquina Nagios Server hacemos:
# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz
# apt-get install libssl-dev
# cd nrpe-2.1.2
# ./configure
# make all
# make install-plugin
Prueba de funcionamiento:
# /usr/local/nagios/libexec/check_nrpe -H 192.168.1.3
NRPE V2.12
# /usr/local/nagios/libexec/check_nrpe -H 192.168.1.3 -c check_disk
DISK OK - free space: / 33010 MB (96% inode=97%);| /=1126MB;28771;32367;0;35964
Ahora solo queda configurar nuestro Nagios Server para que utilice el comando check_nrpe:
define service{
   use generic-service
   host_name remotehost
   service_description Current Users
   check_command check_nrpe!check_disk
}
Más informacion:
+ http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf

caida ldap

13 de abril de 2011

Hoy se ha ido la luz y nos ha echado abajo el servidor de Samba. Como consecuencia al reiniciar el servidor se ha quedado corrupto el LDAP con el siguiente error:

[root@fileserver]# /etc/init.d/ldap start
Checking configuration files for slapd: bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.
bdb_db_open: Database cannot be opened, err 13. Restore from backup!
bdb(dc=XXXXXX,dc=com): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
backend_startup_one: bi_db_open failed! (13)
slap_startup failed (test would succeed using the -u switch)
[FAILED]
stale lock files may be present in /var/lib/ldap [WARNING]
Antes de restaurar el backup hemos probado un: http://www.blogger.com/img/blank.gif
[root@fileserver]# /usr/sbin/slapd_db_recover -v -h /var/lib/ldap
Finding last valid log LSN: file: 1 offset 5315883
Recovery starting from [1][5315755]
Recovery complete at Sun Jul 30 11:31:56 2006
Maximum transaction ID 8000040d Recovery checkpoint [1][5315883]

Para restauraciones más críticas podemos hacer un backup en texto de tú arbol LDAP, corregir los errores y volver a recrear el arbol de LDAP. En este post hay un buen ejemplo: http://blog.mydream.com.hk/howto/linux/openldap-recovery-howto

envolviendo el vsftp

4 de abril de 2011

Al intentar poner un servicio público en Internet, te das cuenta de la cantidad de intentos de acceso que hay al cabo de un día. Al final, te queda la duda de si pueden o no llevar buen puerto.
Si eres de esos de que leen los Logs cada día o de lo que reciben su Logwatch oportuno, te darás cuenta de estos intentos:

--------------------- pam_unix Begin ------------------------ 
 vsftpd:
    Unknown Entries:
       check pass; user unknown: 168 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=administrator rhost=thirdeyemedia.net : 82 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=administrador rhost=thirdeyemedia.net : 59 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=anonymous rhost=host217-40-235-141.in-addr.btopenworld.com : 17 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=113.107.101.249 : 168 Time(s)
       check pass; user unknown: 168 Time(s)
Para bannear estas IPs, lo puedes realizar de dos formas diferentes: o las cierras directamente en tú firewall perimetral, o lo cierras en el firewall del propio servidor o lo cierras con tcpwrappers.

El concepto de tcpwrappers consiste en envolver tú daemon TCP/UDP en un envoltorio el cual analiza el paquete de red antes de enviárselo a tú daemon. Tcpwrapper permite controlar los accesos a los servicios ofrecidos por el sistema ya sea por máquina, por servicio o por combinaciones de ambos. Para ello el daemon de tcpwrapper llamado “tcpd” lee los archivos de configuración /etc/hosts.allow y /etc/hosts.deny. El primer archivo contie las reglas que especifican las máquinas y servicios que están autorizados y el segundo las maquinas y servicios que no están autorizados.
Personalmente me gusta este sistema porque es posible denegar estas conexiones por un administrador que no tiene acceso a su Firewall porque este está administrador por otro conjunto de personas y además no es necesario rebotar nigún servicio.


En este ejemplo real vamos a denegar los accesos de 113.107.101.249, 217.40.235.141 y 64.40.107.210, que corresponden a diferentes ataque al servicio FTP. Primero de todo verificaremos que el servicio de FTP está compilidado para poder utilizar TCPWrappers:
# whereis vsftpd
vsftpd: /usr/sbin/vsftpd /etc/vsftpd /usr/share/man/man8/vsftpd.8.gz
# ldd /usr/sbin/vsftpd | grep libwrap
        libwrap.so.0 => /lib/libwrap.so.0 (0x0046c000)
Una vez vemos que la librería está cargada, podemos editar el /etc/hosts.deny y meter todas las IP necesarias:
vsftpd: 113.107.101.249, 217.40.235.141, 64.40.107.210
Podemos bloquear también por rangos o por subredes:
vsftpd: 113.107.101.0/255.255.255.0
Podemos denegar todos los accessos a cualquier servicio:
ALL: 113.107.101.0/255.255.255.0
O incluso podemos dejar un mensajito:
vsftpd : .elhacker.net \
: twist /bin/echo "421 %h has been banned from this server!"
Si queremos ver todos los servicios TCP que están compilados para utilizar TCPWrappers, podemos hacer:
# strings -f /usr/sbin/* | grep hosts_access
/usr/sbin/rpc.mountd: hosts_access
/usr/sbin/sshd: hosts_access
/usr/sbin/stunnel: hosts_access
/usr/sbin/stunnel: See hosts_access(5) manual for details
/usr/sbin/tcpd: hosts_access_verbose
/usr/sbin/vsftpd: hosts_access
Más información:
+ http://linux.web.cern.ch/linux/scientific4/docs/rhel-rg-en-4/s1-tcpwrappers-access.html