Translate

lunes, noviembre 21, 2016

NSCLIENT++. Instalación y configuración básica.




La página de nsclient++… la verdad es que está un poco desordenada y cuesta encontrar la documentación correcta. En el directorio de instalación del cliente incluye un par de pdf con una documentación similar con lo que necesitamos para configurar el agente y los chequeos con Nagios.
Bajamos nsclient++ de su página y lo instalamos en nuestro Windows. En nuestro caso probamos la versión NSCP-0.4.1.90-Win32.
Al instalar elegimos “Custom Setup” y nos selecciona todos los componentes para instalar (luego puedes desactivarlos en el fichero de configuración).
Configuramos el servidor de Nagios que se podrá conectar y si queremos, una password. También los módulos a instalar (una vez sepamos lo que necesitamos instalaríamos solo lo necesario o lo desactivaríamos posteriormente).

El instalador nos crea un servicio “NSClient++”, como automático y nos lo inicia (proceso nsc). Nsclient funciona por defecto en los puertos 5666 (check_nt), 12489 (nrpe) y escucha en todas las IPs.
netstat -an | find "5666"
 TCP 0.0.0.0:5666 0.0.0.0:0 LISTENING
 TCP [::]:5666 [::]:0 LISTENING
netstat -an | find "12489"
 TCP 0.0.0.0:12489 0.0.0.0:0 LISTENING
 TCP [::]:12489 [::]:0 LISTENING
De hecho también nos crea la regla en nuestro Firewall de Windows para permitir que el programa responda. Verificad en cualquier caso. Tened en cuenta que la password proporcionada solo es para el módulo de chequeo check_nt, no para el resto. Lo mejor es siempre configurar el Firewall del equipo para que solo acepte conexiones para los puertos de nsclient++ desde el servidor de Nagios. Además esa pass creo recordar no va encriptada (aunque tiene un método para “ofuscarla”).
En la instalación por defecto “C:\Program Files\NSClient++” podemos ver:
nscp.exe El binario que ejecuta como servicio pero que también podemos usarlo modo comandos para realizar pruebas y configuraciones.
nsclient.ini El archivo de configuración reducido. El que usa por defecto.
nsclient-full.ini El archivo de configuración extendido. Incluye todas las secciones
*.pdf Manuales un tanto desactualizados
DIR Scripts Pues eso…
DIR modules Todos los módulos que incluye y puede usar el programa (como dlls).

Intalación de check_nt y check_nrpe en Nagios.

De momento nos vamos a nuestro servidor de Nagios para probar e instalar si fueran necesarios los plugins para chequear servicios en un equipo Windows con el agente nsclient++. Luego volvemos a la configuración del cliente.
Si seguimos las instrucciones de instalación del artículo de instalación en Centos / Redhat 6.4 ya tendremos instalados ambos plugin (/usr/lib64/nagios/plugins/). Si no, podemos instalarlos: yum install nagios-plugins-nt nagios-plugins-nrpe.Si nos gusta más Debian / Ubuntu y seguimos el artículo correspondiente también deberíamos tener ambos instalados. Podría faltarnos nrpe:apt-get install nagios-nrpe-plugin
Si nos gusta OMD… pues también los tendremos ya de serie en su directorio de plugins.
Probaremos desde el servidor de Nagios, siempre en línea de comandos y omitiendo rutas.

Probando check_nt

check_nt -H 192.168.1.33 -v UPTIME -p 12489 -s pass
System Uptime - 0 day(s) 8 hour(s) 30 minute(s)
Con check_nt hay que darle el Puerto y la pass que le pusimos durante la instalación (que vale solo para check_nt, no para nrpe y está en el ini de configuración).Podemos ver la ayuda con “check_nt –h”. Algo más interesante con check_nt:
check_nt -H 192.168.1.33 -v CPULOAD -l 60,90,95 -p 12489 -s pass
CPU Load 2% (60 min average) | '60 min avg Load'=2%;90;95;0;100

check_nt -H 192.168.1.33 -v USEDDISKSPACE -l c -w 80 -c 90 -p 12489 -s pass
c:\ - total: 488,28 Gb - used: 226,80 Gb (46%) - free 261,48 Gb (54%) | 'c:\ Used Space'=226,80Gb;390,63;439,45;0.00;488,28

check_nt -H 192.168.1.33 -v SERVICESTATE -l AVP,wuauserv -p 12489 -s pass
OK: All services are in their appropriate state.
Estos son sencillos y se entienden, podemos chequear memoria, procesos concretos en ejecución, uptime, discos, cpu, servicios y contadores de Windows (muy útil estos porque hay muchas aplicaciones que crean contadores y puedes monitorizar ciertas cosas interesantes sobre estas por medio de los contadores). Estos chequeos de check_nt funcionan tal cual, no es necesario configurar nada en el ini del cliente. De todas formas… es mejor usar nrpe del que a continuación se habla. Se puede hacer lo mismo y más que con check_nt (de hecho llama a los comandos de este realmente cuando los usas mediante nrpe), es más seguro (ssl) y tiene muchas más funcionalidades. De hecho… desactiva ya mejor check_nt en el nsclient.ini 🙂
NSClientServer = 0

 Probando check_nrpe

check_nrpe -H 192.168.1.33
 I (0,4,1,90 2013-02-04) seem to be doing fine...
Algunos chequeos con check_nrpe (usando el comando “alias” predefinido en el fichero ini donde estarán también los intervalos de alerta por defecto):
check_nrpe -H 192.168.1.33 -c alias_disk
 WARNING: D:\: Total: 117G - Used: 105G (90%) - Free: 11.7G (10%) < warning|'C:\ %'=54%;10;5 'C:\'=226.8G;48.82;24.41;0;488.28 'D:\ %'=10%;10;5 'D:\'=105.49G;11.71;5.84999;0;117.18 'E:\ %'=80%;10;5 'E:\'=67.2G;32.9;16.45;0;329.03 'G:\ %'=46%;10;5 'G:\'=322.97G;59.61;29.8;0;596.1 'M:\ %'=31%;10;5 'M:\'=681.56G;98.41;49.2;0;984.1

check_nrpe -H 192.168.1.33 -c alias_cpu
OK CPU Load ok.|'5m'=10%;80;90 '1m'=11%;80;90 '30s'=14%;80;90

./check_nrpe -H 192.168.1.33 -c alias_mem
OK: physical memory: Total: 3.25G - Used: 2.23G (68%) - Free: 1.02G (32%), virtual memory: Total: 2G - Used: 336M (16%) - Free: 1.67G (84%), paged bytes: Total: 6.5G - Used: 3.01G (46%) - Free: 3.49G (54%), page file: Total: 6.5G - Used: 3.01G (46%) - Free: 3.49G (54%)|'physical memory %'=68%;80;90 'physical memory'=2.23G;2.58999;2.91999;0;3.24 'virtual memory %'=16%;80;90 'virtual memory'=336.47M;1638;1843.08;0;2047.87 'paged bytes %'=46%;80;90 'paged bytes'=3G;5.19;5.83999;0;6.49 'page file %'=46%;80;90 'page file'=3G;5.19;5.83999;0;6.49
Estos chequeos funcionan porque existen en el fichero de configuración (nsclient.ini) del cliente la definición de los alias (alias_xxxx). La sintaxis es muy clara –c COMANDO –a OPCION1 OPCION2 …
Ahora pasándoles parámetros con “-a” (vemos que hay alias que requieren parámetros):
check_nrpe -H 192.168.1.33 -c alias_cpu_ex -a 50 60
 Exception processing request: Request contained arguments (not currently allowed, check the allow arguments option).
Ops… un horror!!!! Modificamos en el fichero ini del cliente y añadimos al final (buscamos la sección correspondiente [], si no está la ponemos también entonces):
[/settings/NRPE/server]
 allow arguments = true
 [/settings/external scripts]
 allow arguments = true
Vemos que el mismo valor se usa para varias secciones NRPE, check_nt, scrips externos,… Si queremos habilitar argumentos usando esos tendremos que habilitarlo en su respectiva sección. Para aclararnos podemos mirar el ini extendido nsclient-full.ini (que no se usa pero tiene todos los valores posibles parece) y cortar y pegar en el ini que si aplica, nsclient.ini.
Me llama la atención la nueva sintaxis para nombrar las cabeceras de las secciones (para mí son nuevas, hacía tiempo que no lo usaba 🙂 ). En cualquier caso con la sintaxis antigua parece que también funciona. Probamos de nuevo con argumentos:
check_nrpe -H 192.168.1.33 -c alias_cpu_ex -a 50 60
 OK CPU Load ok.|'5m'=0%;50;60 '1m'=2%;50;60 '30s'=4%;50;60
 check_nrpe -H 192.168.1.33 -c alias_process -a proceso_fulano
 CRITICAL: proceso_fulano: stopped < critical|'proceso_fulano'=0;0;1
Hay que tener en cuenta que el uso de argumentos supone un posible problema de seguridad según nos indican en la documentación. Si los usamos debemos proteger el cliente Windows con su firewall para que solo use el puerto nrpe el host de Nagios. En cuanto a que es mejor, definir los intervalos de alerta en el cliente o en el chequeo desde Nagios… pues como siempre, depende. Si los defines en el cliente puedes tener en Nagios un grupo de Host específico al que le apliques el mismo chequeo de servicio, sin distinguir intervalos/opciones. Es una ventaja ya que los intervalos de Warning /Crítical pueden variar dependiendo del tipo de Host. Por otro lado si los tenemos en la definición de los objetos en Nagios está todo más a mano, no es necesario acceder a los hosts para cambiarlo/revisarlo y siempre está el dato en Nagios, pero probablemente tendremos que llamar a muchos servicios de host de forma individual porque tengan unos intervalos distintos, en lugar de asignárselo a un grupo de Host y pista.
Mediante NRPE se amplía el abanico de chequeos además de los habituales, chequeo de espacio de ficheros/ directorios, sobre propiedades de ficheros, valores de WMI, event logs, fichero logs, … Otros ejemplos:
Algunos comandos más interesantes:
Avísame si mi fichero de logs “C:\SOFWARE\LogMyApp.exe se pasa de tamaño:
check_nrpe -H 192.168.1.33 -c CheckFileSize -a ShowAll MaxWarn=1024K MaxCrit=4096K File=c:\\SOFTWARE\\LogMyApp.exe
 CRITICAL: c:\SOFTWARE\LogMyApp.exe: 15.4M > critical|'c:\SOFTWARE\LogMyApp.exe'=15.3M;1;4
OJO: para que funcione bien el tema de las rutas de ficheros vemos que hay que duplicar (escapar) la barra de directorio. Pero para que es o funcione debemos activa en nuestro ini del cliente:
[/settings/NRPE/server]
 allow nasty characters = true
Avísame si se me sale de madre mi directorio… p.e. c:\Temp
check_nrpe -H 192.168.1.33 -c CheckFileSize -a ShowAll MaxWarn=1024M MaxCrit=4096M File:_WIN=c:\\Temp\\*.*
 OK: _WIN: 5.46M|'_WIN'=5.45M;1024;4096
Así como verificar el tamaño de ficheros puede ser interesante (logs, dbs,…), el tema de los directorios es más delicado. Si pruebas con directorios grande te dará un timeout el plugin ya que lógicamente el Windows tiene que ponerse a ello. Quizá se pueda aumentar el timeout pero no me tiene mucho sentido estresar a los sistemas así.
Hay que ser muy fino probando los checks con la sintaxis, si te devuelve 0 bytes es que has puesto algo mal.
Chequear contadores de Windows.
Podemos también preguntar por el valor de cualquier contador Windows. Para ubicar bien sus nombres podemos usar el Monitori de rendimiento de Windows. Los buscamos, los añadimos y luego vemos claramente cual es su ruta completa.
check_nrpe -H 192.168.1.33 -c CheckCounter -a "Counter:proc=\\Procesador(_Total)\\% de tiempo de procesador" ShowAll
 OK: proc: 10.3046|'proc'=10.30455
Otro ejemplo de uso de consulta de valores WMI. Chequear la carga en todas las CPUs.
check_nrpe -H 192.168.1.33 -c CheckWMIValue -a "Query=Select * from win32_Processor" MaxWarn=50 MaxCrit=80 Check:CPU=LoadPercentage ShowAll=long
 OK: Everything seems fine.|'CPU'=31;50;80

Modo test.

Si algo va mal o incluso para probar ciertos comandos previamente siempre podemos usar el cliente en Windows directamente. Tiene un montón de opciones de debug y de inyección de comandos directos. Siempre tenemos que parar el servicio primero si usamos el modo test/debug. Por ejemplo:
net stop nscp
nscp.exe test
En ese momento podemos o bien “injectar” el comando a ejecutar (escribir directamente su alias, p.e.: alias_cpu) o ejecutar el comando nrpe correspondiente desde Nagios y ver en el modo debug como le llega al cliente y que hace con él.
Continúa en el artículo sobre los comandos externos. Podemos ejecutar vbs, bat, powershelll,… lo cual puede ser sumamente interesante para el chequeo de tareas concretas.

viernes, noviembre 18, 2016

Seguridad Raspberry pi - Ataques SSH_brute_force conexiones ssh

Haciendo un chekeo en el fichero /var/log/auth.log vi algo sorprendente:

Nov 18 08:21:21 raspberrypi sshd[13564]: Failed password for root from 51.4.225.228 port 13577 ssh2

Tras googlear un poco, vi el problema, parecen ser intentos de acceso root en nuestras máquinas, ni idea para qué, seguro que algo bastante oscuro, así que buscanso soluciones tenemos una muy buena:

bloquear toda conexión SSH (direcciones IP cuyo login falla 4 veces cada 10 minutos (es un ejemplo, lo ajustamos según nuestras necesidades (poner antes sudo para que ejecute el comando root):

iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 4 -j DROP

Con esto empezamos a estar protegidos frente a un ataque que pretenda acceder como root a nuestro sistema Linux por fuerza bruta (listas de passwords, etc..)

Para que esta configuración no se borre en el siguiente reboot (lo anterior queda para una sesión en memoria):

Actualizamos como siempre nuestra raspi:

$sudo rpi-update 
$sudo apt-get dist-upgrade 
$sudo  apt-get update

1- Instalar el paquete iptables-persistent :
#sudo apt-get install iptables-persistent
En el menu selecciuonamos YES en rule.v4.


2.Para que nuestra configuración anterior quede salvada, es encesario ejecutar los comandos anteriores en memoria y despues salvar esta canfiguración (iptabes-persient los lee de memoria):
$sudo bash -c "iptables-save > /etc/iptables/rules.v4"



Sensores de humedad y temperatura DHT11 y DTH22 en la Raspberry Pi



Existen varios sensores de humedad relativa, entre los cuales el DHT11 y el DHT22 son de los más comunes. El DHT11 es muy barato (alrededor de 2-3€ si lo compras desde China, 8-10€ en España), pero con algo menos de precisión tanto en la humedad como en la temperatura que la que da su hermano mayor, el DHT22, que es algo más caro. Puede verse una tabla comparativa de ambos modelos aquí.
Vamos a empezar conectando el sensor de humedad y temperatura DHT11 a la Raspberry Pi y tomar lecturas. Y después haremos lo mismo con el DHT22.
Sensor de humedad DTH11
Sensor de humedad DHT11
Sensor de humedad DHT22
Sensores de humedad y temperatura DHT11 y DHT22
Hace falta además una resistencia entre el pin de alimentación y el de datos, aunque se puede comprar el sensor en una mini placa con la resistencia incorporada, como el caso del sensor que tengo yo y que se ve en la imagen de arriba.
En muchas páginas se explica cómo conectar el sensor a la Raspberry Pi (ver más abajo), y todas lo hacen al pin GPIO4 (pin 7). Como en el proyecto que estoy haciendo ahora mismo ya tengo conectado ahí un termómetro DS18B20 (ver este post), voy a conectarlo el GPIO5 (pin 29). Bastará con cambiar el código según a dónde lo conectemos.
Entonces lo conecto así:
  • GND del sensor a un pin GND de la RPi, en mi caso al 20
  • S (datos) al GPIO 5 (pin 29 de la Raspberry Pi)
  • 3V3 a uno de los 3V3 de la Raspberry Pi, en mi caso al 17.
Y ahora, el código para tomar las lecturas. Googleando se pueden encontrar varias formas de hacerlo. El problema en todas ellas es que linux no es un sistema operativo de tiempo real, y como el sensor requiere medidas muy rápidas consecutivas, esto puede suponer un problema. He visto varios ejemplos en Python y en C; en C funciona mejor porque es de más bajo nivel. De todas maneras, en todos los casos advierten de que en ocasiones da error en la lectura y hay que intentarlo varias veces.
Vamos a emplear el código de Adafruit. Es necesario hacer lo siguiente:
git clone https://github.com/adafruit/Adafruit_Python_DHT.git
cd Adafruit_Python_DHT
Hay que tener instaladas las siguientes librerías (que tal vez ya tengas instaladas):
sudo apt-get update
sudo apt-get install build-essential python-dev python-openssl
Y ahora compilamos la librería de Adafruit:
sudo python setup.py install
Tras instalarse, probamos a ver si funciona:
cd examples
sudo ./AdafruitDHT.py 11 5
Con esto estoy diciendo que lea los datos del sensor DHT11 (podría ser el DHT22 o el AM2302), conectado al pin GPIO 5.
Y con esto obtenemos la lectura de temperatura y humedad:
Temp=28.0*C  Humidity=29.0%
¡Funciona!
Vamos a probar ahora el sensor DHT22. Lo primero que tengo que hacer es soldarle la resistencia. En algunos sitios he visto que la resistencia debe ser de 4.7KΩ, y en otros, que debe ser de 10KΩ.
thumb_IMG_7031_1024
Soldando la resistencia al sensor DHT22
thumb_IMG_7032_1024
Y lo conecto a la Raspberry Pi de la siguiente forma:

thumb_IMG_7033_1024
Sensor DHT22 conectado a la Raspberry Pi
Sigo los pasos de instalación de más arriba, y cuando ejecuto:
sudo ./AdafruitDHT.py 22 4
Tras un par de segundos obtengo:
Temp=29.0*C  Humidity=26.4%
¡Funciona!

Los dos sensores funcionando al mismo tiempo, el DHT22 conectado al GPIO4, y el DHT11 al GPIO5:
Sensores DHT11 y DHT22 conectados a la Raspberry Pi
Sensores DHT11 y DHT22 conectados a la Raspberry Pi

Referencias
  • http://fpaez.com/sensor-dht11-de-temperatura-y-humedad/
  • http://www.uugear.com/portfolio/dht11-humidity-temperature-sensor-module/
  • https://learn.adafruit.com/dht-humidity-sensing-on-raspberry-pi-with-gdocs-logging/wiring

Instalando OpenVPN server en una Raspberry Pi



Algo super util en una Raspberry para poder conectarnos desde donde sea será el montar un servidor VPN, en un documento anterior ya vimos cómo montarlo, pero era con PPTP, algo no muy seguro digamos, en este documento veremos cómo instalar OpenVPN en una Raspberry, os dejo unos apuntes para que podáis montar una VPN segura y os podáis conectar desde cualquier lugar!
raspberry-openvpn-00-bujarra
OpenVPN nos ofrece una combinación de seguridad a nivel empresarial, seguridad, facilidad de uso y riqueza de características. La seguridad es lograda mediante cifrado del tráfico usando mecanismos SSL/TLS, por lo que en este documento nos desplegaremos además de OpenVPN en sí, nuestra propia CA, generaremos los certificados para los usuarios y daremos sus claves para que se conecten! Si no tenemos una IP pública fija, sería ideal combinarlo con el cliente NO-IP en nuestra Raspberry!!!

Comenzamos con la instalación de OpenSSL:
sudo apt-get install openvpn openssl
cd /etc/openvpn
sudo su
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa
Editaremos con ‘vim easy-rsa/vars’ y corregiremos la siguiente ruta con el path correcto: ‘export EASY_RSA=“/etc/openvpn/easy-rsa”’
Creamos los certificado del servidor y de un cliente además de la clave, al rellenar la información del certificado con que indiquemos el ‘Common name’ sería suficiente, empezamos:
./easy-rsa/clean-all
cd easy-rsa
ln -s openssl-1.0.0.cnf openssl.cnf
cd ..
./easy-rsa/build-ca OpenVPN
./easy-rsa/build-key-server server (y a todo)
./easy-rsa/build-key client1
./easy-rsa/build-dh
Creamos nuestro archivo de configuración con ‘vim /etc/openvpn.conf’ y con esta configuración sería suficiente:
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
user nobody
group nogroup
server 10.8.0.0 255.255.255.0
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
client-to-client
push "redirect-gateway def1"
#set the dns servers
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
log-append /var/log/openvpn
comp-lzo
Ejecutamos lo siguiente para permitir el enrutado a nuestra red, en este ejemplo uso el interfaz Wifi wlan0, si usas ethernet deberías poner eth0; ojo al rango IP por si tu red no es la 192.168.1.0/24 para cambiarlo y por último la 192.168.1.197 es la dirección de mi Raspberry Pi:
echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o wlan0 -j SNAT --to 192.168.1.197
Editamos ‘vim /etc/sysctl.conf’ y descomentamos’ net.ipv4.ip_forward=1′
Ya podremos arrancar OpenVPN con: ‘/etc/init.d/openvpn start’.
Crearemos nuestro fichero de configuración OpenVPN para los clientes, ejecutamos ‘vim conexion_vpn.ovpn y poner:
dev tun
client
proto udp
remote NOMBRE_O_DIRECCIÓN_IP_(PUBLICA)_DE_LA_RASPBERRY 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
verb 3
Editamos ‘vim /etc/rc.local’ y ponemos al final antes del último exit (ojo al rango IP del ejemplo, interfaz  y dirección de la Raspberry Pi:
iptables -t nat -A INPUT -i wlan0 -p udp -m udp --dport 1194 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o wlan0 -j SNAT --to-source 192.168.1.197
Nos copiamos los certificados y los clientes para tenerlos cerca, nos haremos propietarios de los ficheros que entregaremos a los clientes:
cp -rf /etc/openvpn/easy-rsa/keys /home/pi
chown pi:pi /home/pi/keys para poder copiarlas con SCP a nuestros PCs
sudo chmod 777 /home/pi/keys/client1.key
Copiaremos a los PCs que se quieran conectar los siguientes ficheros: ca.crt, client1.crt y client1.key
Y por último, tendremos que tener en cuenta en abrir los siguientes puertos en nuestros firewalls/routers para permitir el acceso desde Internet a nuestras redes: TCP 443, TCP 943 & UDP 1194.