Al que como yo se encuentre en un punto en donde se le vuelve tedioso ir servidor por servidor, dispositivo por dispositivo revisando los archivos de bitácora (logs) de cada uno, esto le resultará de utilidad.

syslog es un estándar de facto para el envío de mensajes de registro en una red informática IP. Por syslog se conoce tanto al protocolo de red como a la aplicación o biblioteca que envía los mensajes de registro.

Un mensaje de registro suele tener información sobre la seguridad del sistema, aunque puede contener cualquier información. Junto con cada mensaje se incluye la fecha y hora del envío.

Recibir los logs de otros servidores en un servidor Linux:

En mi caso, mi servidor central corre Syslog-NG, pretendo recibir en este servidor todos los logs que generan otros servidores corriendo Linux y Windows, cámaras de seguridad, routers y puntos de acceso inalámbricos que controlo.

Syslog puede enviar información sobre TCP o UDP indistintamente. Por convención se usa el puerto 514 UDP. La mayoría de los dispositivos del tipo access points wireless o cámaras de seguridad no permiten especificar puerto o protocolo así que lo mejor es crear una regla en el firewall que reenvíe todo el tráfico del puerto 514 UDP que es la configuración por defecto a nuestro Syslog server:

iptables -A PREROUTING -t nat -i eth0 -p udp –dport 514 -j DNAT –to 192.168.1.150

Una vez hecho esto, habilitar Syslog-NG para que reciba tráfico por UDP editando el archivo /etc/syslog-ng/syslog-ng.conf:

source src {
unix-stream(«/dev/log» max-connections(256));
internal();
file(«/proc/kmsg»);
udp();
};

Con eso ya tenemos suficiente como para recibir todos los logs de otros servidores y dispositivos en la red o desde internet en nuestro servidor central syslog.

Consultando los Logs:

Todos estos logs se pueden consultar en diferido usando:

less /var/log/messages

O verlos en tiempo real desde una consola:

tail -f /var/log/messages

O traerlos desde tty12 a la tty1 para una cómoda visualización nuevamente editando /etc/syslog-ng/syslog-ng.conf:

# By default messages are logged to tty12…
destination console_all { file(«/dev/tty1«); };

Trayendo logs remotos hasta nuestro servidor syslog:

El paso siguiente es traer todos los logs remotos a nuestro servidor central para poder administrarlos con mas comodidad. A continuación algunos ejemplos para diferentes escenarios.

Windows:

En el caso de servidores que corren windows, bastará con instalar NTsyslog (requiere .NET 2.0 y windows installer 3.0) y configurarlo para que envíe los logs hasta nuestro syslogserver usando el número de IP o el nombre de dominio del mismo.

Captura del programa NTsyslog

Linux:

Cuando el servidor remoto corre syslog-ng, agregar en el archivo de configuración:

destination remote { udp(«mi.servidor.com» port(514)); };

Cuando el servidor remoto corre rsyslog o similares, agregar en /etc/rsyslog.conf:

*.*     @mi.servidor.com

Otros dispositivos:

Dependerá del caso pero la gran mayoría de equipamiento de red de calidad permite el reenvío de logs a otros dispositivos, solo es cuestión de acceder a la página web de administración de los mismos y configurarlos según corresponda.

Por último, la frutillita del postre, acceder a estos logs usando un cliente web usando phpsyslogng, (requiere Apache/PHP/MySQL), eso lo dejo para la próxima entrada, que por hoy se me acabó el tiempo:

Ejemplo de phpsyslogng
Sigue en la parte 2: [HowTo] Controlar los logs generados por syslog desde una página web

Cada tanto de entre las miles de entradas en los blogs que hablan siempre de lo mismo de ubuntu se encuentra uno con una gema escondida. Esto es lo que me pasó ayer leyendo Bichotoblog. Me encontré con Nast.

A pesar de llevar muchos años en esto, nunca lo había visto, y eso que suelo darme una vueltita cada tanto por /usr/portage/net-analyzer a ver que hay de nuevo.

Nast viene a ser una especie de nmap/ettercap para principiantes, un analyzador de redes con capacidad de Sniffer.

De leerme un poco el manual me ha dejado encantado.

¿Por que?

Por su rapidez de uso; En lugar de tener que realizar 4 o 5 operaciones distintas con ettercap para inundar toda la subred con peticiones ARP para saber quien estan en línea, usando Nast, basta con ejecutar:

nast -m

El resultado:

¡Realmente no podría ser mas sencillo!

Otra posibilidad que me ha dejado encantado es la de romper conexiones al vuelo. Puede interceptar paquetes ACK y falsificar un RST como respuesta rompiendo cualquier conexión establecida:

Entre otras tantas funcionalidades interesantes, puede seguir conexiones TCP entre hosts, loguearlas en formato propio o compatible con tcpdump. Puede descubrir interfaces en modo promiscuo, detectar envenenamiento en la tabla ARP, detectar la topología de la red, autodetectar hosts en modo gateway (puerta de enlace), escanear puertos usando la tecnica half-open y un largo etcétera.

En definitiva, una herramienta mas para el arsenal. Imprescindible.

Desconozco en otras distribuciones pero en Gentoo basta con un:

emerge nast

¡Y andando !

O de como reemplazar 4 aplicaciones por una sola:

Prefacio:

Le tengo que dedicar al menos una mención de honor a Dnsmasq, este pequeño DNS Forwarder que con tan solo 269Kb (de código fuente en un .tar.gz) me ha cambiado la vida.

Como bien dicen en su página web oficial, «Dnsmasq is a lightweight, caching DNS proxy with integrated DHCP server«. Osea, un pequeñísimo proxy para cachear peticiones DNS que no resuelve por su cuenta -como lo haría BIND, por ejemplo- si no que se interpone entre la red y el verdadero DNS server almacenando los requests en memoria para servirlos rápidamente y ahorrar minúsculas cantidades de ancho de banda por petición.

Ya con eso solo me bastaría y sobraría si no fuera por que además hace de DHCP server!

Con un archivo de configuración tan bien comentado que ni hace falta leer el manual, además de proxy DNS, puede servir de DHCP server compitíendole a los mejores de su rubro sin ningún esfuerzo en lo que a configurabilidad se refiere, y la cosa no acaba ahi…

Además puede servir de PXE server! De nuevo, sin ningún esfuerzo mas que descomentar dos o tres líneas, puede servir peticiones PXE a la red para hacer arrancar thin clients de cualquier tipo…

No contento con todo esto, su desarrolador además le ha incorporado TFTP Server! No solo puede servir a clientes PXE con su configuración inicial, además puede servir por TFTP la imagen de arranque necesaria!

Todo esto lo he ido descubriendo de a poco, leyendo el archivo de ocnfiguración y haciendo algunas pruebas.

Para mis necesidades, ha reemplazado 4 aplicaciones diferentes que usaba antes con una sola que es tan (o mas) configurable que las anteriores y mucho mas estable en algunos casos… (Por ejemplo, no he vuelto a tener problemas desde que sirvo imagenes por TFTP usando Dnsmasq, cosa que si me pasaba al servirlas con tftp-hpa, un port del TFTP server de OpenBSD para linux)

Resumiendo, Dnsmasq te cambia la vida. En una sola aplicación:

  • DNS Proxy con caché (y control de TXT records si fuera necesario)
  • DHCP Server altamente configurable
  • PXE Server para diskless clients
  • TFTP Server de alta estabilidad y muy buena velocidad de operación.

Una joyita realmente. ¿Que mas se puede pedir de la vida?

Próxima entrega: Como encadené Dnsmasq para que sirva grldr, el bootloader de grub4dos por la red el cual a su vez encadena pxelinux y que me permiten arrancar de todo un poco, livecd de linux, windows, imagenes de diskette y archivos ISO…