¿Cómo detectar ciertos eventos y situaciones en nuestras máquinas?". Entre otras posibilidades, registros de auditoría y monitorización a todos los niveles.
Ante problemas de funcionamiento, prestación de servicios, "performance", etc. en nuestros sistemas existen dos posibilidades de actuación.:
- No hacer nada y que sean los propios usuarios de nuestros sistemas los que, cuando un sistema presente un mal funcionamiento o una degradación en sus prestaciones, nos avise.
- Disponer de distintos sistemas de monitorización y alarmas en los sistemas administrados o, al menos, en servidores relevantes. Señalar que en este punto no estamos hablando de sistemas como puedan ser los I[D,P]Ss, que entrarían en otro apartado relacionados con la monitorización y detección-prevención de intrusiones, o los sistemas de análisis de vulnerabilidades.
La primera opción supone tener que curar a un paciente cuando está en una situación crítica, sin contar todas las implicaciones de prestar un mal servicio a nuestros usuarios-clientes. Bajo ningún concepto debemos proceder de esta manera. En todo momento deberemos pensar en un mínimo de herramientas que nos faciliten la monitorización de los sistemas.
En este punto, iniciamos la aventura con las opciones básicas de "accounting" de procesos y usuarios.
El clásico paquete
acct nos proporcionará unas herramientas básicas de monitorización de procesos y usuarios. Comandos como el
ac,
lastcomm,
sa,
last,
lastb, entre otros, nos proporcionan algunas posibilidades básicas. Se estudian los parámetros de salida de los mismos.
En un segundo nivel se analiza el paquete
sysstat como herramienta básica de monitorización de los distintos subsistemas gestionados por los sistemas operativos de nuestras máquinas, tanto en "tiempo real" como sobre bases de datos históricas, que nos permiten analizar el "performance" de las máquinas en cualquier momento pasado.
En toda monitorización un parámetro que debemos definir es el período de muestreo. Obviamente este deberá ajustarse a los objetivos de los posibles estudios sobre las muestras. Señalar que toda monitorización también supone una sobrecarga en el sistema que, de ser necesario, debería cuantificarse. En el marco del paquete sysstat se analiza la salida obtenida por los comandos
iostat, mpstat, sar, top, vmstat y
free, así como las opciones para garantizar el muestreo histórico de parámetros del sistema y el tratamiento de los mismos por los "scripts"
sa1,
sadc y
sa2. También se incluye el comando
sadf para exportar los datos a CSV o XML. Nuevamente se analizan los principales parámetros de salida de todos ellos.
Se incluye una herramienta no menos importante, la ISAG (Interactiva System Activity Grapher) que, sobre un entorno gráfico permite seleccionar un fichero del subsistema
sysstat en binario (
saXX) y mostrar los datos de muestreo históricos de forma gráfica. Sin duda alguna estos gráficos nos proporcionan de una forma visual mucha información sobre la evolución del "performance" en los distintos subsistemas gestionados por el sistema operativo.
Para concluir, señalar que de nada nos sirve disponer de muchos datos sin una cierta capacidad de análisis y, o, sistemas de alarma. Es necesario "conocer" las salidas producidas y las posibles interacciones e implicaciones de las mismas para, con ellas, sacar conclusiones que nos permitan tomar decisiones. Nuevamente llegamos a la “palabreja” que aparece cada poco en la asignatura, "tomar decisiones". Sin duda alguna, el profesional que nunca toma decisiones, o hace que sean otros los que las tomen, nunca se equivocará. Pero este es otro de los muchos puntos que diferencia un buen profesional de uno mediocre. Todo responsable del sector TIC debe potenciar a aquellos profesionales que toman decisiones y, muy especialmente, a los que asumen las posibles responsabilidades de las mismas, incluso en los casos no acertados.
Seguimos con comandos básicos de ayuda a la monitorización. Entre ellos,
uname, uptime, time, ps, vnstat, df, du, who, gprof, ping, traceroute, etc., etc. Otro conjunto de comandos evolucionados lo constituyen
dstat, iftop, tcptrack, vnstat y
atop. Se presenta la utilidad y salida de dichos comandos, sin entrar en posibles opciones. Para más información, juega un poco con ellos.
Otro ámbito de herramientas es del chequeo de integradad. Entre ellas
sxid, tripwire o
ViperDB.
Entre los muchos apartados de la práctica 2 (parte II), de las posibles opciones de uso, el
tripwire y el
vnstat os permitirán resolver un par de ellos.
Hasta este punto hemos visto herramientas de monitorización de equipos, sin pensar en las posibilidades de entornos centralizados de monitorización de un gran número de activos. Aunque se podrían desarrollar soluciones propias con lo visto, en la actualidad existe una gran cantidad de herramientas para dicha tarea. Entre ellas,
Pikt,
zabbix,
munin,
Nagios (
mini-howto nagios),
NTOP.
MRTG (Multi Router Traffic Grapher) y
OSSIM (Open Source Infraestructure for Security Monitoring). De forma generealizada estas herramientas o hacen uso de agentes propios en el lado cliente o del protocolo de gestión
SNMP (Simple Network Management Protocol), con o sin soporte de las
MIB (Management Information Base).
"De nada sirve disponer de todo tipo de sistemas de monitorización, "logs", sensores, analizadores de vulnerabilidades, sistemas de alarma más o menos inteligentes, etc. en entornos en los que nadie analiza la información y, como mínimo, atiende las alarmas (a mano o a máquina). Tener este tipo de sistemas está muy bien pero, sin duda alguna, requiere un cierto control de toda la información y alarmas generadas".
Al final de la clase de hoy me habéis preguntado por un sistema de videovigilancia casero. Existen varias entradas para las típicas webcams con sistemas caseros y software free. Entre las múltiples.:
