2. Modelo OSI

Modelo de capas

El hecho de que los protocolos de aplicación estén pensados para ocultar los detalles de los protocolos de comunicación y estos los de los protocolos de transmisión nos permite construír un modelo de capas.

Capa n+1
^
ˇ
Protocolo en la capa n+1
^
ˇ
Capa n+1
^
ˇ
 Capa n
^
ˇ
 Protocolo en la capa n
^
ˇ
 Capa n
^
ˇ
 Capa n-1 Protocolo en la capa n-1  Capa n-1

Aquí, el protocolo de transmisión toma la posición más baja y el protocolo de de aplicación la más alta. Cada capa del lado de envío recibe la información desde arriba y la pasa para abajo.
Conceptualmente, seguimos diciendo que dos nodos se comunicacn vía HTTP, cuando de hecho los datos HTTP fluyen a través de TCP/IP y un gran número de protocolos de transmisión entre un nodo y el siguiente, y deben sufrir los mismos pasos hacia arriba antes de volver a convertirse en datos HTTP.

Header
Técnicamente, en cada capa del lado del remitente, el correspondiente protocolo recibe «una unidad de datos del protocolo» en la interfaz del servicio de la capa superior y añade una cabecera conteniendo toda la información importante para su operación antes de pasarlo a través del servicio a la capa inferior.
La capa inferior considera todo lo que recibe en el servicio de interfaz como datos, las cabeceras de los protocolos anteriores no incumben a la capa inferior.
Del lado del receptor, el paso de paquetes a través de las mismas capas en orden inverso, y cada capa elimina su cabecera antes de pasar los datos útiles hacia arriba.

El modelo de capas más conocido es el modelo ISO/OSI (Organización internacional de normalización / Interconexión de sistemas abiertos) (“Internation Organisation for Standardisation/Open
Systems Interconnection”)

Estación 1                    Capas OSI            Estación 1
Protocolos de                Aplicación            Protocolos de
aplicación                    Presentación        aplicación
(HTTP, FTP…)                Sesión                (HTTP, FTP…)

Protocolos de                 Transporte            Protocolos de
comunicación (IP, TCP…)    Red                    comunicación (IP, TCP…)

Medios de acceso            Enlace de datos        Medios de acceso
(Ethernet…)                Capa física            (Ethernet…)

Los estándares ISO/OSI nunca han llegado a utilizarse, demasiado poco prácticos para ser útiles, y los estándares demasiado difíciles de conseguir, pero el modelo de referencia con sus siete capas ha permanecido y su popularidad utilizada para explicar el proceso de transferencia de datos.

Algunas pilas de protocolos no pueden ser directamente mapeados al modelo ISO/OSI. Para empezar, está el hecho de que no todos los fabricantes se adhieren a la definición realizada por el modelo, por otro lado, varias pilas de protocolos depredan el modelo OSI.
No se debe confundir el modelo OSI con un estándar cerrado para la estructura del funcionamiento del software de red, o incluso un set de instrucciones para la implementación de software de red. El modelo OSI es simplemente una clarificación de los conceptos involucrados y los hace más fáciles de discutir.

Una breve explicación del modelo:
Capas 1 y 2, física y enlace de datos, describen cómo los datos son enviados a través del «cable». Esto incluye el esquema del medio de acceso así como el codificado de los datos.
La capa 3, capa de red, define las funciones requeridas para enrutar, incluyendo los requisitos de direccionamiento
Capa 4, capa de transporte, describe el transporte de los datos de aplicación. Distingue entre servicios orientados a conexiones y servicios sin conexión
Capas 5, 6 y 7, sesión presentación y aplicación, a menudo no están explícitamente discriminadas en la práctica, por ejemplo con el protocolo TCP/IP. Describen cómo se muestra la representación de los datos independientemente del sistema, red o interfaces de los protocolos de aplicación

Adiccionalemnte, Andy Tanenbaum ha postulado las capas 8 y 9, capas financiera y política. Mientras que estas capas son bien conocidas en la práctica, no se han incorporado al modelo OSI de referencia.

1. Protocolos en internet

Protocolos en internet

· Protocolos de transmisión
A menudo llamados métodos de acceso.
Se encargan de la transmisión de datos a nivel de tarjetas de red y de las conexiones físicas. Su construcción depende de las propiedades físicas y las restricciones de la implementación en hardware.
Por ejemplo, es muy diferente una comunicación entre dos equipos a través de un cable conectado a un módem de la comunicación a través de señales de radio en una WLAN, por lo que los protocolos que se utilizan, así como los requisitos de los mismos, no tienen nada que ver.
El protocolo de transmissión en redes LAN es Ethernet. Es también muy corriente en redes WLAN el uso de IEEE 802.11.

· Protocolos de comunicación
Sirven para organizar la comunicación entre equipos en diferentes redes, sin presuponer un conocimiento detallado de los medios de acceso utilizados.
Para ver una web de canguros alojada en Australia en mi equipo en Galicia no quiero saber que el equipo está conectado vía Ethernet al router de casa, que habla ATM con el DSLAM de la empresa que me provee internet, que pasa datos a través de fibra a través de varios nodos hasta Australia, etc. Solamente necesito escribir «cangurosbonitos.com» en mi navegador.
Los protocolos de comunicación están pensados para prevenir tener que usar los protocolos de transmisión, pero no pueden existir sin estos. El objeto es ocultar los protocolos de transmisión al usuario final.
Los protocolos de comunicación más importantes son IP, TCP y UDP. También se puede incluír ICMP como protocolo de infraestructura para obtener diagnósticos, control y notificación de errores.

· Protocolos de aplicación
Implementan servicios como servidor de correo electrónico, transferencia de archivos o telefonía a través de internet basados en los protocolos de comunicación. Si los protocolos de comunicación son útiles para enviar bytes a Australia y conseguir otros de vuelta, los protocolos de aplicación le dan sentido a dichos bytes.
Protocolos de aplicación típicos son SMTP, SSH, FTP, DNS o HTTP, con sus correspondientes métodos seguros, esto es, autenticados y encriptados.
Todos estos protocolos son usados por programas aplicación como clientes de correo o navegadores y están basados en protocolos de comunicación como TCP o UDP.
Los datos intercambiados mediante un protocolo son llamados de forma abstracta «unidades de datos de protocolo». Dependiendo del protocolo pueden tener nombres más específicos como paquetes, datagramas, segmentos o frames.

6. Journald

Logs del sistema con Systemd y «el journal»

Fichero de configuración: /etc/systemd/journald.conf

journalctl: comando para examinar el log del journal, básicamente muestra lo mismo que /var/log/messages con ciertas mejoras:
# El log se muestra con el visualizador favorito, típicamente less
# La salida incluye todos los logs accesibles, incluso aquellos que han sido rotados
# Los logs con prioridad notice o warning son mostrados en negrita
# Los logs con prioridad error o superior aparecen en rojo

Systemd es una renovación del software de linux que asegura las operaciones básicas de un equipo.
En un modo estricto, systemd se encarga de iniciar y seguir servicios y gestionar recursos.
Además, systemd contiene un acercamiento al sistema de logs que es marcadamente diferente del tradicional syslogd, «el journal», y los componentes de software necesario para implementarlo.

Mientras que en el acercamiento tradicional el demonio syslog acepta los mensajes en el puerto 514/UDP o el socket /dev/log, en systemd los servicios en segundo plano pueden simplemente escribir mensajes de log a su canal stderr y systemd se las arreglará para pasarlo al servicio de logs.
Con systemd los ficheros de log no son ficheros de texto, donde cada mensaje es enviado posiblemente a varios archivos, si no que los mensajes son escritos a una base de datos binaria que puede ser consultada de acuerdo a diferentes criterios.

-O- Por ejemplo, es fácil mostrar todos los mensajes guardados por un servicio específico durante un período de tiempo concreto. Esto era complicado de realizar con el sistema tradicional.

-O- Para ser justos, deberíamos apuntar que las implementaciones modernas de syslog como rsyslog o syslog-NG son, en principio, capaces de escribir mensajes de log a una base de datos. Sin embargo, será responsabilidad del administrador hacer una estructura adecuada de la base de datos, para configurar los servicios adecuadamente y para desarrollar software que permita acceder convenientemente a los mensajes de log. Systemd incluye todo esto de forma implícita.

-O- El journal no está limitado a mensajes de log textuales. Es, por ejemplo, perfectamente posible almacenar volcados de fallos de programas en el journal (mientras no sean de tamaños desproporcionadamente grandes).

Los logs de systemd pueden ser leídos con los métodos tradicionales. Si se desea, los mensajes de log que llegan a /dev/log o el puerto 514/UDP pueden ser registrados, y puede pasar los mensajes al demonio tradicional syslog.
Si se quiere mostrar los logs recientes de un serivicio se puede utilizar, por ejemplo, systemctl status servicio, que devolverá el estado y las últimas líneas de log.
Si se quiere mostrar más líneas, systemctl status -l servicio

#systemctl status ssh
. ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: active (running) since Mo 2015-07-27 13:37:22 CEST; 8h ago
Main PID: 428 (sshd)
CGroup: /system.slice/ssh.service
..428 /usr/sbin/sshd -D

Jul 27 13:37:23 blue sshd[428]: Server listening on 0.0.0.0 port 22.
Jul 27 13:37:23 blue sshd[428]: Server listening on :: port 22.
Jul 27 13:56:50 blue sshd[912]: Accepted password for hugo from ...sh2
Jul 27 13:56:50 blue sshd[912]: pam_unix(sshd:session): session ...=0)
Hint: Some lines were ellipsized, use -l to show in full.

 

Systemd y Journald
El Journal es una parte integrada de systemd. En el caso más simple, systemd utiliza una cantidad limitada de memoria en un anillo de buffer en /run/log/journal para almacenar un cierto número de mensajes de log en RAM. Para obtener ventajas de todas las funciones del Journal, debes asegurarte que los mensajes de log son guardados en disco permanentemente. Se realiza simplemente creando el directorio para el almacenamiento:

# mkdir -p /var/log/journal
# systemctl --signal=USR1 kill systemd-journald

-O- El componente de systemd que se encarga del Journal es systemd-journald, o journald para sus amigos.

Al igual que logrotate, systemd rota el Journal para hacer sitio a nuevos mensajes. Para hacerlo, el espacio disponible es subdividido en un número de ficheros, para que el más antiguo pueda ser descartado si es necesario. Esta rotación es transparente para el usuario, ya que journald la gestiona cuando es necesario y journalctl siempre evalua el Journal completo, sin importar en cuántos archivos consista.

 

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg

· Storage: puede tomar los valores:
volatile: los mensajes se guardan solamente en RAM (/run/log/journal)
incluso si existe /var/log/journal
persistent: los logs son almancenado en el disco preferiblemente.
Durante las primeras instancias de arranque, si no se puede escribir en
disco, se utiliza /run/log/journal
auto: parecido a persistente, pero la existencia de /var/log/journal
determina si se escribirá un log persistente
none: no se almacenan mensajes de log en el journal, de todas formas, se
pueden pasar los mensajes a syslog

· Compress: especifica si los ficheros de log, al menos los que exceden
cierto tamaño, serán comprimidas transparentemente. El valor por defecto
es sí.

· Seal: permite asegurar que los ficheros persistentes de Journal son
protegidos contra manipulaciones externas mediante una firma
criptográfica. Solamente se necesitará una clave, el manual explica cómo.

· RateLimitInterval / RateLimitBurst: se supone que hacen más difícil
inundar el log con mensajes. Si un servicio produce más del
RateLimitBurst durante un período de tiempo dado por RateLimitInterval,
los mensajes que restan durante dicho período son ignorados, el log
contendrá un número que dice los mensajes ignorados. Por defecto el
límite es más de 1000 mensajes en 30 segundos. Poner a cero cualquiera
de los parámetros elimina la restricción

· SystemMaxFilesize y RuntimeMaxFileSize: gobiernan la subdivisión de ficheros. Especifican qué tamaño puede alcanzar cada ficero, por defecto 1/8 del tamaño disponible para el Journal, por lo que siempre habrá, por defecto, un histórico de 7 archivos mas el actual.

· MaxFileSec: asegura una rotación del log en función de un tiempo determinado. Valor por defecho 1 mes, 0 significa ilimitado.

· MaxRetentionSec: define cuánto tiempo son guardados los ficheros de log antiguos. El valor por defecto es 0, es decir, está deshabilitado.

· ForwardToSyslog: configura el envío de mensajes al sistema tradicional

· SyncIntervalSec: especifica qué tan a menudo se escribe el Journal al disco. Será guardado inmediatamente después que un mensaje de prioridad crit o superior sea logueado. Mientras no llegue este tipo de mensaje, journald esperará el tiempo especificado, por defecto, 5 minutos.

· SystemMaxUse y RuntimeMaxUse: describen ćuanto espacio puede ocupar el Journal en /var/log/journal y /run/log/journal, respectivamente. Valor por defecto, 10%.

· SystemKeepFree y RuntimeKeepFree: determinan cuanto espacio debe ser reservado en los fihceros definidos. Valor por defecto, 15%.
Systemd-journald toma los valores …MaxUse y …KeepFree y los confina a lo mínimo dictado por los dos.
Los valores Runtime… son usados cuando el sistema está arrancando o no se usa un Journal persistente. Los valores System… se aplican al Journal persistente si el sistema ha arrancado. Cuando se determinal el espacio usado por Journal, solamente se tienen en cuenta los ficheros con terminación .journal.
Se pueden especificar tamapos en unidades binarias, K, M, G, T, P y E (tibibytes, petabibytes y exbibytes no serán muy usados hoy en día, pero quién sabe).

Recuperar volúmenes lógicos creados con lvm

Cómo recuperar particiones lvm:

Buscar backup de la configuración, normalmente en:
/etc/lvm/backup/ficherodebackup

Buscar el UUID del volumen físico (pv) en el fichero de backup:

# cat /etc/lvm/backup/dynamic_vol
...   
 physical_volumes {

        pv0 {
            id = "LStNTn-BXkM-ZahU-B8SF-E6QV-A6EQ-sdS19M"
            device = "/dev/sda4"    # Hint only
...

Crear volumen de grupo con el UUID que hemos obtenido, para poder restaurar el backup, ignorar el mensaje de error por ahora:

# pvcreate --uuid="LStNTn-BXkM-ZahU-B8SF-E9QQ-A6EQ-sdS19M" --restorefile=/etc/lvm/backup/dynamic_vol /dev/sda4
  Couldn't find device with uuid LStNTn-BXkM-ZahU-B8SF-E9QQ-A6EQ-sdS19M.
  Physical volume "/dev/sda4" successfully created.

Ya tenemos creado el volumen físico, aunque si buscamos el volumen de grupo no encontraremos nada todavía:

# pvs
  PV         VG Fmt  Attr PSize   PFree  
  /dev/sda4     lvm2 ---  105,74g 105,74g

# vgs

Restaurar el volumen de grupo:

# vgcfgrestore -f /etc/lvm/backup/dynamic_vol dynamic_vol
  Restored volume group dynamic_vol

# vgs
  VG          #PV #LV #SN Attr   VSize   VFree 
  dynamic_vol   1   3   0 wz--n- 105,74g 78,74g

Ya aparecen nuestros volúmenes lógicos:

# lvs
  LV   VG          Attr       LSize  Pool Origin Data%  Meta%  Move  Log Cpy%Sync Convert                                              
  root dynamic_vol -wi------- 15,00g                                                    
  tmp  dynamic_vol -wi-------  2,00g

Aunque al intentar montarlos, recibimos un error, y si buscamos la ruta en que deberían encontrarse, no hay nada:

# mount -a
mount: special device /dev/dynamic_vol/root does not exist
mount: special device /dev/dynamic_vol/tmp does not exist

# ls /dev/mapper/
control

Informamos al kernel de la existencia de los volúmenes y los montamos:

# vgchange -a y dynamic_vol
   3 logical volume(s) in volume group "dynamic_vol" now active
 
# ls /dev/mapper/
 control  dynamic_vol-root  dynamic_vol-tmp

# mount -a

Listo, tenemos acceso de nuevo:

 # mount
 /dev/mapper/dynamic_vol-root on /root type ext4 (rw,relatime,data=ordered)
 /dev/mapper/dynamic_vol-tmp on /tmp type ext4 (rw,relatime,data=ordered)

5. Logrotate

logrotate

Fichero de configuración: /etc/logrotate.conf


 

Dependiendo del número de usuarios y el tipo de servicios corriendo, los ficheros de log pueden crecer mucho y rápidamente. Para mantener el sistema libre de basura, se deben crear particiones separadas para /var o /var/log.
Además, existe software que revisa periódicamente los ficheros de logs de acuerdo a varios criterios, como puede ser el tamaño, y recorta o elimina viejos ficheros de log. El proceso es conocido como rotación (rotation), y el programa que lo realiza es logrotate.

Logrotate no es un demonio, si no que normalmente se ejecuta una vez al día utilizando un servicio como cron o similar.

Logrotate rechaza modificar ficheros de log más de una vez al día, excepto si la decisión depende del tamaño del fichero, se está utilizando un criterio horario o la opción –force.

El fichero /etc/logrotate.conf es solamente una convención puesta en marcha por una invoncación de /etc/cron.daily/logrotate (o similar). Posteriormente se procesan todos los ficheros en el directorio /etc/logrotate.d/, al cual se hace una llamada mediante include en el fichero inicial.

Logrotate revisa todos los ficheros que se le solicitan, no solamente aquellos creados por syslogd.

EJEMPLO:

/var/log/syslog
 {
 rotate 7
 mail nanana@batman.es
 daily
 missingok
 notifempty
 delaycompress
 compress
 postrotate
    invoke-rc.d rsyslog rotate >/dev/null
 endscript
 }

· /var/log/syslog: define qué fichero se debe revisar
Pueden enumerarse diversos ficheros o establecer criterios de búsqueda en shell (shell patterns).
Tras esto, entre los corchetes, se puede ver el bloque de directivas que aplicará logrotate.
Normalmente, los ficheros de configuración contienen directivas que están fuera de los corchetes. Éstas se aplican por defecto a todos los ficheros de log, a menos que haya directivas más específicas para dichos ficheros posteriormente entre corchetes.

· rotate 7: deben mantenerse 7 versiones del fichero de log. Si hay más, se eliminan.  Los ficheros rotados son numerados secuencialmente, es decir, si el fichero actual es /var/log/mail, el siguiente es /var/log/mail.1 y así hasta el último permitido.
Se pueden utilizar fechas en vez de números, con la directiva dateext. Los ficheros serían renombrados tal que var/log/syslog-20150719 (19/7/2015)
Usando este método, se puede controlar exactamente cómo se verá el nombre del archivo mediante %Y, %m, %d y %s.
Utilizando dateformat, logrotate ordena los ficheros léxicamente para encontrar el más antiguo. Esto funciona con -%Y%m%d y -%d%m%Y

· mail nanana@batman.es: si se especifica una dirección de correo con ‘mail’, los ficheros no se eliminarán si no que se enviarán a la dirección de email.

· daily: significa que los ficheros deben rotar diariamente.
Existen además hourly, weekly, monthly y yearly.
Weekly realiza la rotación el primer día de la semana en el sistema inglés, el domingo, o si el equipo ha estado apagado, cuando puede siempre que haya transcurrido dicha semana.
Monthly, se rotan los ficheros en la primera ejecución mensual de logrotate.
Yearly realiza la rotación a principios de año.
Hourly presenta el problema de que por defecto, logrotate se ejecuta una vez al día, por lo que se debe buscar la forma de cambiar el período de ejecución.
Un criterio alternativo es size. Rotará el fichero de log cuando exceda un tamaño X definido. Estos tamaños se definen en bytes por defecto, o con K para Kibibytes, M para Mibibytes y G para Gibibytes.
Se pueden utilizar a la vez time y size. Se hace utilizando maxsize, en este caso el fichero se rota al llegar al tamaño máximo incluso si la fecha especificada no ha llegado o minsize, en cuyo caso el fichero solamente será rotado en la fecha especificada si ha excedido el tamaño dado, los ficheros con menor tamaño serán saltados

· missingok: suprime los mensajes de error si un log no es encontrado
La configuración por defecto es nomissingok

· notifempty: no rota los logs si el fichero está vacío. Por defecto se utiliza ifempty, que sí los rota.

· delaycompress: asegura que una rotación realizada recientemente no es comprimida, solamente las que se realizan en rotaciones posteriores, por lo que la secuencia de ficheros se vería tal que así:

history.log  history.log.1  history.log.2.gz  term.log  term.log.1.gz  term.log.2.gz

mientras que por defecto se realiza lo siguiente:

history.log  history.log.1.gz  history.log.2.gz  term.log  term.log.1.gz  term.log.2.gz

Esto se utiliza si hay alguna posibilidad de que, por ejemplo, rsyslog necesite añadir información al fichero despues de haber sido renombrado. Esto puede suceder porque rsyslog mantiene el fichero abierto, y renombrarlo es irrelevante mientras se está escribiend en él.

· compress: permite que los ficheros rotados sean comprimidos. Se realiza por defecto con gzip, a menos que se utilice un método alternativo con compresscmd. Las opciones que deberá utilizar para comprimir (las que se pueden utilizar en línea de comandos) se definen con compressoptions. Por defecto se utiliza -6.

· postrotate: avisa a rsyslog de que hay un nuevo fichero de logs.

· invoke-rc.d rsyslog rotate >/dev/null: Los comandos del shell son ejecutados por logrotate una vez el fichero de log ha sido rotado.
El comando en sí es irrelevante (este es el que utiliza Debian), la idea es que se envíe una señal SIGHUP al programa que está manejando los logs, de forma que se reinicie y relea el fichero de configuración, otras distribuciones tienen métodos diferentes.

Entre postrotate y endscript puede haber varias líneas con scripts que logrotate concatena y las pasa al intérprete por defecto, /bin/sh como un conjunto. El comando pasa el nombre del fichero de log como parámetro, por lo que se puede utilizar la forma $1.

Los comandos a continuación de postrotate son ejecutados una vez por cada fichero de log enumerado al inicio del bloque de configuración. Se puede utilizar la directiva sharedscripts para garantizar que los comandos son ejecutados, como mucho, una vez para los ficheros que coinciden con el patrón, o ninguna, si no necesitan ser rotados.

Se puede utilizar create para asegurarse que el fichero de log es creado automáticamente después que los comandos son ejecutados. Utiliza el nombre del fichero antiguo, se pueden definir de 3 formas diferentes:

create 600 root adm         Con permisos, propietario y grupo
create root adm             Con propietario y grupo
create                      Sin nada

Si no se espefican ningún parámetro, todas las propiedades son tomadas del fichero anterior. Toda la documentación en logrotate(8).

4. Syslog-NG

Syslog-NG

Fichero de configuración: /etc/syslog-ng/syslog.ng.conf


 

Syslog-NG, de next generation, es una reimplementación de syslog retrocompatible. Las principales ventajas respecto a syslogd son:
· filtrado de mensajes basado en su contenido, no sólo en categorías y prioridades
· se pueden encadenar varios filtros
· sistema más sofisticado de entrada/salida, incluyendo el envío mediante TCP y a subprocesos

 

Configuración:
· Opciones globales (Global options): aplica a todas las fuentes de mensajes de syslog-ng
· Fuentes de mensajes (Message sources): syslog-ng puede leer mensajes de un socket o retransmitidos por UDP como syslogd, pero también, por ejemplo, de ficheros FIFO o sockets TCP. A cada fuente se le asigna un nombre.
· Filtros (Filters): expresoines booleanas basadas en funciones interas que puede referirse al origen, categoría, prioridad o contenido textual del mensaje
· Pozos (Message sinks): syslog-ng incluye todos los de métodos d syslogd y algunos más
· Rutas (Log paths): conecta una o más fuentes, filtros y pozos, si un mensaje llega de la fuente y pasa el filto (o filtros) es enviado al pozo específico

 

Opciones:
Se pueden especificar varias opciones globales que controlan el comportamiento o determinan los valores por defecto de una fuente de mensaje o pozo (las opciones específicas tendrán prioridad sobre éstas).
Si syslog-ng en el host A recibe un mensaje del host B, comprueba la opción keep_hostnames(). Si el valor es sí, B guarda el hostname para el log. Si es no, la salida depende de la opción chain_hostnames(), si esta también es no, A se logeará como hostname, si es sí, se guardará el hosname B/A. Particularmente importante si el log se reenvía a otro host.

 

Fuentes de mensaje:
las fuentes se determinan con la palabra clave source. Para hacer lo mismo que en syslog, se puede incluír la siguiente línea en el fichero de configuración:

 source src { unix-stream("/dev/log"); internal(); };

dice a syslog-ng que escuche en el socket /dev/log. internal(). Se refiere a los mensajes que syslog-ng crea por sí mismo.

Una fuente de syslog-ng correspondiente con la opción remota de syslogd (-r) se parecerá a:

 source s_remote { udp(ip(0.0.0.0) port(514)); };
 dado que es la opción por defecto, también puede ser:
 source s_remote { udp(); };

Con la opción ip() se puede forzar escuchar solamente a una ip. No es posible en syslogd.

La siguiente especificación permite a syslog-ng reemplazar al programa klogd:

 source kmsg { file("/proc/kmsg" log_prefix("kernel: ")); };

Todas las fuentes soportan el parámetro log_msg_size(), que especifica el tamaño máximo en bytes.

 

Filtros:
Usados para cribar o distribuir los logs a varios pozos. Utilizan las funciones internas, que consideran diferentes aspectos de los mensajes. Dichas funciones pueden ser unidas con operadores lógicos tales como and, or y not.
EJEMPLO:
Filtro que acepta todos los mensajes del host «nananana» con el mensaje «Batmaaaaaaaaan»

 filter f_nananana { host("nananana") and match ("Batmaaaaaaaaan"); };

Con las funciones level() o priority() se pueden especificar una o más prioridades separadas por comas, o rangos, como warn, crit, emerg, etc.

 

Pozos:
Al igual que las fuentes, los pozos consisten en varios «drivers» que definen los métodos:

destination d_file { file("/var/log/messages"); };

Se pueden especificar plantillas que describen el formato en que el mensaje deberá ser escrito en el pozo en cuestión. Haciendo esto, se pueden definir «macros» que hacen las diferentes partes del mensaje accesible.
EJEMPLO:

 destination d_file {
 file("/var/log/$YEAR.$MONTH.$DAY/messages"
 template("$HOUR:$MIN:$SEC $TZ $HOST [$LEVEL] $MSG\n")
 template_escape(no)
 create_dirs(yes)
 );
 };

Las macros $YEAR, $MONTH, etc. serán reemplazadas por los valores obvios.
$TZ: time zone
$LEVEL: nivel de prioridad del mensaje
$MSG: el mensaje en sí

La función template_escape() controla si ‘ y » deben ser escapados en la salida (\). Importante si se quiere enviar los logs, por ejemplo, a un servidor SQL.

Como ya hemos dicho, syslog-ng permite el envío de mensajes a otros hosts utilizando TCP, asegurando así que los mensajes son recibidos por el destinatario. Se puede definir un envío mediante TCP de la siguiente forma:

destination d_tcp { tcp("10.11.12.13" port(514); localport(514)); };

La función program() permite el envío de mensajes a programas. Syslog-ng arranca el programa y lo mantiene activo hasta que se detiene al propio syslog-ng o el el programa recibe una seña SIGHUP. No se realiza de esta forma solamente para aumentar la eficiencia, si no que además se evitan ataques DOS (Denial of service), al no abrir múltiples instancias del mismo programa.

 

Rutas de logs:
Sirven para juntar fuentes, filtros y pozos y además evaluar mensajes. Siempre empiezar con la palabra clave log.
EJEMPLO:

# Prerequisites
 source s_all { internal(); unix-stream("/dev/log"); };
 filter f_auth { facility(auth, authpriv); };
 destination df_auth { file("/var/log/auth.log"); };

# auth,authpriv.*
 /var/log/auth.log
 log {
 source(s_all);
 filter(f_auth);
 destination(df_auth);
 };

Esta regla hace que todos los mensajes que tienen que ver con autenticación (facility(auth, authpriv)) sean enviados al fichero /var/log/auth.log

Otro más:

# kern.warn;*.err;authpriv.none
/dev/tty10
filter f_nearly_all {
(facility(kern) and priority(warn .. emerg))
or (not facility(authpriv,kern));
};
destination df_tty { file("/dev/tty10"); };
log {
source(s_all);
filter(f_nearly_all);
destination(df_tty);
};

Todos los mensajes pasan por todos los filtros, y son registrados en todos los coincidentes. Si se quiere que un determinado mensaje no continúe una vez que ha pasado un filtro, puede añadirse la opción flags(final) a esa ruta.

flags(final) no implica que el mensaje sea registrado solamente una vez, ya que puede haber filtros coincidentes anteriores.

Con flags(fallback) se puede declarar una ruta como «ruta por defecto». Esta ruta solamente será considerada para mensajes que no coinciden con ninguna de las rutas que no fueron marcadas con la opción flags(fallback).

 

facility( ⟨category⟩[ , ⟨category⟩ … ] ) Matches messages with one of the listed categories
level( ⟨priority⟩[ , ⟨priority⟩ … ] ) Matches messages with one of the listed priorities
priority( ⟨priority⟩[ , ⟨priority⟩ … ] ) Same as level()
program( ⟨regex⟩ ) Matches messages where the name of the sending program matches ⟨regex⟩
host( ⟨regex⟩ ) Matches messages whose sending host matches ⟨regex⟩
match( ⟨regex⟩ ) Matches messages which match the ⟨regex⟩ themselves
filter( ⟨name⟩ ) Invokes another filtering rule and returns its value
netmask( ⟨IP address⟩ / ⟨netmask⟩ ) Checks whether the IP address is in the given network

Documentación en:
https://www.balabit.com/network-security/syslog-ng

3. Rsyslog

Rsyslog – rocket-fast syslog

Fichero de configuración:  /etc/rsyslog.conf


 

Además de una mayor eficiencia, el objetivo de rsyslog es soportar varias fuentes  y pozos para los mensajes de log. No solamente escribe los mensajes a ficheros de texto y terminales, si no también a una amplia selección de bases de datos.

 

Funciona de la siguiente forma:
Las fuentes pasan los mensajes a los «conjuntos de reglas». Hay un conjunto por defecto, RSYSLOG_DefaultRuleset, pero se pueden definir más.

Cada conjunto de reglas puede contener tantas como se quiera (o ninguna)
Una regla consiste en un filtro y una lista de acciones. Los filtros realizan acciones sí/no acerca de la ejecución de las acciones pertinentes.

Para cada mensaje, todas las reglas se ejecutarán en orden descendente, de primera a la última. Todas las reglas se ejecutarán, aunque haya una orden de detención por el medio.

Una lista puede contener diversas acciones (por lo menos una). Sin lista de acciones, no se admiten más filtros. Las acciones determinan qué sucede con los logs que coinciden.

La apariencia de los logs puede ser controlada mediante plantillas.

 

El fichero de configuración:
En el fichero /etc/rsyslog.conf se pueden encontrar 3 estilos de configuración diferentes:
· La sintaxis tradicional de /etc/syslog.conf (sysklogd)
· Una sintaxis obsoleta de rsyslog. Se reconoce por comandos que comienzan con $
· La sintaxis actual de rsyslog (RainerScript). Bien adaptada a situaciones complejas

Las dos primeras opciones están basadas en líneas, la última no atiende a los saltos de línea. Se recomienda solamente el uso de la última opción para realizar configuraciones en el fichero de rsyslog.

 

Filtros extendidos

:msg, contains, "FOO" /var/log/foo.log

Consisten en:
· «:» en el margen izquierdo
· una propiedad que syslog toma del mensaje, «msg»
· un filtro, aquí, «contains»
· y un término de búsqueda, «FOO»

Además de «msg», el mensaje de log en sí, las propiedades que se pueden incluír son:
· hostname: nombre del equipo que envía el mensaje
· fromhost: nombre del equipo que envía el mensaje a rsyslog
· pri: categoría y prioridad del mensaje como número sin codificar
· pri-text: categoría y prioridad del mensaje como cadena de texto, con el  número añadido (local0.err<133>)
· syslogfacility y syslogseverity así como syslogfacility-text y syslogseverity-text: para acceder directamente a la categoría y prioridad
· timegenerated: cuándo ha sido recibido el mensaje
· inputname: el módulo de rsyslog que ha recibido el mensaje
Y más, revisar la documentación de rsyslog de ser necesairo.

Los operadores de comparación permitidos son:
· contains: contiene la cadena de texto
· isequal: la cadena de texto es igual a la dada
· startswith: la cadena de texto empieza con (más eficiente que utilizar regex, aunque puede que lo que tú consideres el inicio del mensaje y lo que rsyslog considere no sean lo mismo:
EJEMPLO:

<131>Jul 22 14:25:50 root: error found

El mensaje comienza a partir de «:», por lo que la sintaxis sería para filtrar estos errores sería (véase el espacio antes de error)

:msg, startswith, " error" /var/log/error.log

· regex: expresión regular simple de acuerdo a POSIX
· eregex: expresión regular extendida de acuerdo a POSIX

 

Si se desean enviar los mensajes a otra máquina a través de la red, lo que con syslog sería «local0.* @red.example.com», lo cual transmite los mensajes a través de UDP al host de destino, con rsyslog además se permite «local0.* red.example.com», utilizando así TCP. Por supuesto, al otro lado debe haber un rsyslog correctamente configurado, se puede comprobar con la siguiente sintaxis:

module(load="imtcp" MaxSessions="500")
input(type="imtcp" port="514")

Los mensajes se transmisten por defecto al puerto 514/UDP, dicho puerto en TCP está reservado para rsh (remote shell, nadie lo utiliza hoy en día), se puede utilizar otro de la siguiente forma:

local0.* @@red.example.com:10514

Los cambios a implementar del lado del servidor pasan por configurar el puerto de escucha.

 

Siguiente nivel de complejidad, filtros basados en expresiones que pueden contener expresiones arbitrarias tales como booleanas, aritméticas o cadenas de operación, comienzan simepre con if y deben ser definidos en una línea (similar a los condicionales if de bash):

if $syslogfacility-text == "local0" and $msg startswith " FOO" and ($msg contains "BAR" or $msg contains "BAZ") then /var/log/foo.log

Rsyslog soporta un gran número de módulos que determinan lo que sucederá con los logs. Se puede, por ejemplo, enviar los mensajes por correo:

module(load="ommail")
template(name="mailBody" type="string" string="ALERT\\r\\n%msg%")
if $msg contains "disk error" then {
action(type="ommail" server="mail.example.com" port="25"
mailfrom="rsyslog@example.com" mailto="admins@example.com"
subject.text="disk error detected"
body.enable="on" template="mailBody"
action.execonlyonceeveryinterval="3600")
}

Se trata de una implementación primitiva de SMTP que no soporta encriptación ni autenticación, el servidor que lo recibe debe estar configurado acorde a esto.

 

Además, rsyslog acepta por sí mismo los mensajes del kernel con el módulo imklog, por lo que no se necesita klog:

module(load="imklog")

Toda la información en
www.rsyslog.com/doc/master/index.html

2. Registros del Kernel

Logs del kernel

Programas utilizados:

klogd – leer los mensajes del kernel, solamente con syslog
dmesg – leer los logs de arranque del sistema

Ficheros: /proc/ksmg – almacena los mensajes del kernel


 

El kernel no envía los mensajes de registro a syslogd si no que la pone en un «buffer en anillo» interno.

Puede ser leída de dversas formas, mediante una llamada específica del sistema o el «fichero» /porc/ksmg. Tradicionalmente, este fichero es leído por el porgrama klogd.

Si el sistema, por el contrario, utiliza rsyslog, klogd no se instala ya que rsyslog se hace cargo de los mensajes directamente.

Durante el arranque del sistema, syslogd y klogd no se encuentran inmediatamente disponibles, ya que deben ser arrancados como programas, por lo que no pueden registrar los logs de arranque. Para esto puede utilizarse el dmesg.

root@soporte:/# dmesg | head -5
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
[    0.000000] Command line: root=/dev/md1 ro console=tty0 console=ttyS0,57600

Utilizar dmesg permite además borrar el búfer en anillo del kernel (opción -c) y establecer prioridades para notificaciones directas: mensajes que exceden o igualan esta prioridad se envían automáticamente a consola (opción -n). Las prioridades pueden ser de 0 a 7, correspondientes a las de syslogd desde emerg a debug.

1. Syslog

Registros del sistema

Demonio: syslogd

Fichero de configuración: /etc/syslog.conf

Socket: /dev/log


 

Los programas aplicación necesitan mostrar información a los usuarios, una tarea completada, un error o un aviso necesitan ser reportados.
El kernel, el sistema operativo y los servicios de red, entre otros, corrien segundo plano, a diferencia de los programas con interfaz gráfica. Escribir mensajes a la consola del administrador del sistema no garantiza que este los lea, mucho menos en modo multiusuario, por lo que pueden ser fácilmente perdidos.

El demonio Syslog (syslogd) es la solución a este problema.
En vez de emitir el mensaje a la salida directamente, los mensajes del sistema con siginificado especial se emiten mediante la función syslog(). Estos mensajes son aceptados por syslogd en el socket /dev/syslog.

En realidad los mensajes del kernel son gestionados por klogd. Este programa preprocesa los mensajes y se los traslada a syslogd.

Syslogd es, como su nombre indica, un dominio. Normalmente es iniciado mediante un script en el arranque del sistema. Cuando recibe un mensaje, puede escribirlo en un fichero o bien enviarlo a través de la red a otra máquina que centralice los logs de varios equipos.

Las distribuciones más comunes (Debian, Ubuntu, Red Hat…) han estado utilizando durante bastante tiempo una implementación más avanzada llamada ‘rsyslog’, que permite más opciones de configuración.
Algunas distribuciones, como Novell/SUSE utilizan ‘syslog-NG’.

El fichero de configuración de syslog define dónde se guarda la información que recibe de cada uno de los servicios del sistema.
El fichero de configuración de rsyslog es compatible con la configuración de syslog, simplemente ignora las líneas que comienzan por $.

 

Estructura de ejemplo del fichero de configuración syslog.conf

*.=warn;*.=err -/var/log/warn
*.crit /var/log/warn
*.*;mail.none;news.none/td> -/var/log/messages

La primera columna define qué mensajes son seleccionados, la segunda a dónde deben ser enviados.

La primera columna se estructura de la siguiente forma:

aplicación.prioridad;aplicación.prioridad;etc.

· Si se define, por ejemplo, capturar los mensajes del servicio de correo con mail.warn, todos los warnings y mensajes con una prioridad inferior serán capturados y enviados a la salida.
· Si solamente se quiere capturar los warnings, la sintaxis es mail.=warn
· Para capturar todos los mensajes de un servicio, se puede definir con * o debug, mail.* o mail.debug
· Si se desea no capturar los mensajes, la negación se realiza con !, esto actúa para todos los mensajes con nivel inferior a error, mail.!err. Por este motivo, se suele utilizar con la sintaxis mail.*;!mail.err
· Se pueden combinar ! y =, mail.!=err deselecciona solamente los mensajes de error de mail

La segunda columna indica el fichero (en principio) donde se escribe el log, siempre utilizando rutas absolutas:

/var/log/mail

· Un guión (-) al principio hace que, a diferencia del funcionamiento normal de syslogd, los mensajes no sean escritos al momento al disco, lo cual se puede traducir en pérdida de datos en caso de fallo del sistema. (Utilizar para mensajes no relevantes), -/var/log/mail
· Se puede hacer referencia a un fichero de dispositivo /dev/tty10
· Se puede escribir a un fichero FIFO, se debe dar la ruta absoluta con | precediéndola, |/dev/xconsole
· Se puede enviar la información por la red a otro syslogd. Se realiza con @IP.de.destino.
Es la única forma de asegurarse que los logs no son modificados por un posible atacante.
El host de destino debe iniciarse con la opción -r (remote)
· Se pueden enviar los mensajes directamente a los usuarios, se deben separar con una coma. El mensaje se mostrará en terminal si están logueados, fran,root
· Se pueden enviar a todos los usuarios logueados especificando un * en vez del nombre de usuario

Para testear el funcionamiento de syslog, se puede utilizar el programa logger:

root@soporte:/home/fran# logger -p mail.err -t TEST "Hello World"
root@soporte:/home/fran# tail -1 /var/log/mail.err
 Jan 16 20:09:24 1and1soporte TEST: Hello World

 

Prioridad Siginificado
none No prioritario, excluír mensajes de cierta aplicación
0 – debug Estado interno de un programa, para depurar errores
1 – info Registro de operaciones normales del sistema
2 – notice Documentación notable durante operaciones normales del sistema
3 – warning o warn Errores no serios pero que tampoco pertenecen a las tareas normales
4 – err Mensajes de error de todo tipo
5 – crit Errores críticos (no está clara la división entre crit y err)
6 – alert Mensajes que requieren atención inmedata
7 – emerg Último mensaje antes de un fallo del sistema
Aplicación Significado
authpriv Mensajes de seguridad confidenciales del subsistema
cron Mensajes de cron y at
daemon Mensajes de programas demonio sin más especificación
ftp Mensajes de demonios ftp
kernel Mensajes del kernel
lpr Mensajes del susbsistema
mail Mensajes del subsistema de correo
news Mensajes del subsistema usenet
syslog Mensajes de syslogd
user Mensajes sobre usuarios
uucp Mensajes sobre el subsistema UUCP
localr ( 0 ≤ r ≤ 7) De libre uso para mensajes locales