LOGs en LINUX
LOGs en LINUX
-------------
Quienes me conocen saben que considero fundamental
revisar los logs del
sistema, ya que considero una de las mejores maneras
de prevenir un posible
ataque o tambien un error en el sistema. Si bien
hablare de logs de linux, este
concepto se aplica a cualquier sistema operativo.
Como sabran *nix intenta q todo sea un archivo,
desde un dispositivo como el
HD hasta un archivo de configuracion y los logs
no son la excepsion.
Basicamente el logging en linux esta basado en
syslogd:
SYSLOGD
=======
"syslogd": es quien proporciona
el servicio al sistema para poder logear
segun este especificado en su archivo de configuracion.
Podemos acceder a su archivo de configuracion
en /etc/syslog.conf en donde
podremos observar que a grandes rasgos se encarga
de indicar que y donde se
envian los logs. Esto no quita que existan programas
que se encargan de
administrar sus propios logs (por ejemplo Apache).
Observamos con atencion unas lineas del archivo
syslog.conf
kern.* /var/log/kern.log
mail.* /var/log/mail.log
(A) (B)
NOTA: A Y B fueron agregados por mi para organizar
el siguiente tema.
Esta compuesto principalmente de dos partes: -Que
logear (A)
-Donde enviarlo (B)
Que logear
----------
Se indica el servicio que envia el mensaje y la
prioridad del mensaje,
separados por un punto "."
Los servicios: auth, auth-priv, cron, daemon,
kern, lpr, mail, mark, news,
syslog, user, uucp, local0 a 7
Las Prioridades: debug, info, notice, warn, err,
crit, alert, emerg.
Parametros especiales:
* (asterisco)
Cumple la misma funcion que es utilizada en bash,
indica "todos". Pero en el
archivo de configuracion indicara TODOS, segun
la posicion en la que se
encuentre.
Veamos un ejemplo:
kern.* /var/log/kern.log
En este caso el servicio es el kern (kernel) y
el nivel de alerta que
deseamos es * (todos), de esta manera estariamos
enviando TODOS los mensajes
del servicio kern a /var/log/kern.log
, (coma)
Se utiliza para indicarle a varios servicios una
misma prioridad.
Por ejemplo:
kern,mail.warning /var/log/kern_mail.log
Se enviaran a /var/log/kern_mail.log todos los
mensajes que produzcan los
servicios kern y mail, de prioridad warning (4)
e inferiores, err (3), crit
(2), alert (1), emerg (0).
= (igual)
Es utilizado para dar una prioridad especifica
a uno o mas servicios.
Por ejemplo:
kern,mail.=warning /var/log/kern_mail_warn.log
*.alert /var/log/alerts.log
En el primer caso se logeara todos los mensajes
de prioridad warning (4), que
produzcan los servicios kern y mail. En el segundo
todos los mensajes de
prioridad alert (1) que produzca cualquier servicio
seran logeadas en el
archivo /var/log/alerts.log
! (exclamacion)
Se utiliza para exceptuar la prioridad mas las
inferiores, tambien se puede
utilizar con el signo = para exceptuar solo esa
prioridad.
Por ejemplo:
kern.notice;kern.!crit /var/log/kern_notice.log
mail.*;mail.!=notice /var/log/mail.log
Aqui el servicio kern logeara los mensajes de
prioridades notice (5), warning
(4) y err (3). Esto se debe a que con el campo
!crit estamos exceptuando todas
las prioridades crit (2) e inferiores: alert (1),
emerg (0).
En la segunda linea podemos observar que se utiliza
!= para exceptuar los
mensajes de prioridad notice (5). Es decir que
se logearan todos los mensajes
que produzca el servicio mail, menos aquellos
que sean de prioridad notice (5).
Donde enviarlo
--------------
En este campo se especifica donde se enviaran
los logs: si seran guardados,
impresos o si directamente se guardaran en otro
servidor, etc. Generalmente son
enviados a archivos de texto plano, los cuales
deben estar correctamente
especificados y con su path completo. Tenemos
una opcion bastante util, que nos
permite evitar una sincronizacion constante del
archivo en el que se esta
logeando, de esa manera se puede conseguir un
mayor rendimiento en velocidad.
Para utilizarla simplemente debemos ateponer el
signo - antes del path. Si bien
se pueden perder datos si hay un error en el sistema
al momento de escribir el
log, considero que se puede utilizar sin miedo,
dependiendo del sistema y de lo
que estemos logeando.
Hasta ahora vimos como enviar los logs a archivos
de texto ubicados en
nuestro sistema, veamos otras opciones:
DEVICES ( /dev/ )
Podemos enviar los logs a dispositivos (Devices)
de nuestro sistema
directamente a una terminal determinada.
Por ejemplo:
kern.emerg /dev/console
mail.emerg /dev/console
Seran enviados a la consola (por pantalla) todos
los mensajes de prioridad
emerg (0) de los servicios kern y mail.
PIPES ( | )
Podemos enviar los logs a un archivo "pipe", en
este tipo de archivo por
decirlo de una manera entendible, no se almacena,
sino que agurdan ser leidos.
Por ejemplo:
Primero creamos el archivo "pipe":
root@utopia:~#
mkfifo tubo
root@utopia:~#
chmod 0 tubo
root@utopia:~#
ls -l tubo
p--------- 1 root root 0 Oct 20 19:30 tubo
Recordemos que syslogd debe estar configurado
para enviarlo ahi:
mail.emerg |/var/log/tubo
Como notaran antes del path esta el caracter "pipe"
| de esa manera le
indicamos que se trata de un archivo pipe a syslogd.
Una vez realizado esto
solo basta leerlos:
root@utopia:~#
cat tubo
Se puede jugar mucho con esta funcion, despues
veremos un ejemplo MUY UTIL de
esa funcion.
OTRO HOST
Siempre que sea "necesario" y se pueda, recomiendo
utilizar otro host para
logear, ya que de esa manera prevenimos que sean
borrados o modificados,
logrando asi mayor confianza en nuestros logs.
Suponiendo que tenemos un
servidor (web, mail, ftp) debemos reconocer que
existe la posibilidad de que
alguien logre vulnerar nuestro sistema, lo grave
seria no darnos cuenta.
Al tener un host aislado (solo accesible desde
el servidor) y tomando las
medidas de seguridad necesarias (fw, attributos
de archivos, usuarios,
contrase~as), podemos tener una confianza bastante
alta sobre lo que dicen
nuestros logs. Si los logs se realizaran en el
mismo servidor y alguien lograra
vulnerar el sistema, quizas ni siquiera lo notemos
ya que podria ocultar
procesos, usuarios, modificar logs y nosotros
ni siquiera nos enterariamos.
Para enviar a otro host simplemente basta con
una @, veamos...
Por ejemplo:
*.info @host.seguro
Aqui se enviarian todos los mensajes de prioridad
info (6) e inferiores, de
cualquier servicio, a host.seguro
Si bien syslogd nos permite de manera MUY simple
logear en otro host, tenemos
que asegurarnos que este configurado correctamente
para poder realizarlo. En el
host.seguro debemos utilizar la opcion -r de syslogd
para que acepte conexiones
remotas (por default deshabilitado).
Al utilizar un nombre de host es conveniente tenerlo
definido en el sistema
(/etc/hosts), aunque syslogd intentara 10 veces
acceder a ese host antes de
ANUNCIAR que no puede logear en el sistema remoto.
( Las conexiones se realizan
a traves del puerto 514/udp y deben asegurarse
de reiniciar el servicio syslogd
en el host.seguro con la opcion -r; tambien recuerden
que los logs se envian en
texto plano)
Lo que parece un GRAN aumento de confianza y seguridad
a nuestros logs puede
representar un GRAVE fallo de seguridad si no
se realiza correctamente. Veamos
porque:
- LAN
HUB
Nuestra LAN esta conectada a traves de un HUB,
por lo que cualquier host de
la red podria capturar los paquetes que sean enviados
de un host al otro
(sniff) y obtener informacion muy valiosa, nuestros
LOGS.
SWITCH
Quizas consideremos que al utilizar un switch
evitamos que cualquier host
de la red pueda capturar paquetes, pero no es
asi. Hoy en dia existen
herramientas que permiten de manera muy simple
"enga~ar" las tablas ARP, para
poder continuar capturando paquetes. Si quieren
mas informacion respecto a este
tema, esto se denomina "ARP POISONING" o "ARP
SPOOFING" y ettercap es una
herramienta que permite hacerlo de manera MUY
sencilla. En proximos boletines
se tratara el tema.
- DIRECTO
Podriamos establecer una UNICA conexion FISICA
entre el servidor y el
host.seguro encargado de los logs, de esa manera
se aumenta la seguridad. Por
ejemplo se podria utilizar una tarjeta para conectar
los dos hosts y asi evitar
el trafico por el resto de la red. De esta manera
estamos aislando al
host.seguro del resto de la red y haciendolo accesible
solo por el servidor.
- SEGURIDAD
CONEXION SEGURA
Lo que yo recomiendo es utilizar una conexion
segura (SSH) al transmitir
los logs a otro host. La comunicacion entre los
hosts es cifrada por lo que si
un atacante pudiese obtener los paquetes que se
transmiten no lo servirian de
mucho ya que la conexion es cifrada. Veamos como
hacerlo:
Para poder hacer esto necesitamos trabajar con
archivos "pipe" ( | ), para
crear este arhivo simplemente:
root@utopia:~#
mkfifo tuberia
root@utopia:~#
chmod 0 tuberia
root@utopia:~#
ls -l tuberia
p--------- 1 root root 0 Oct 20 19:30 tuberia
Ahi ya tenemos creada nuestra tuberia ahora como
habiamos visto antes, para
indicarle a syslogd que queremos enviarlo a un
arhivo "pipe" simplemente antes
del path destino agregamos |
La linea se veria asi:
kern.* |/var/logs/tuberia
Una vez realizado esto los logs del servicio kern
de cualquier prioridad
seran enviados al archivo pipe "tuberia", ahora
debemos enviarlo por ssh al
otro host. Lo ideal seria tener esta conexion
y todas las referentes al log en
scripts de manera tal que se realizen constantemente
desde el inicio del
sistema. Es cierto que necesitara mas atenciones
pero creo que si la seguridad
importa, es algo que vale la pena.
Para mas info en "man syslogd" hay una seccion
que hace referencia a este
tema, explicando otros casos.
FIREWALL
Es fundamental tener configurado nuestro firewall
de manera que no
entorpezca las conexiones, pero que ASEGURE el
aislamiento del host en una
conexion DIRECTA asi tambien COMO TODA LA RED.
Ya se hablo en boletines
anteriores sobre Firewall veanlos (Boletines 2
y 3) igualmente NUNCA dejaran de
ser tema de conversacion ;)
- IMPRESORA ( /dev/lp1 )
Si ni siquiera el metodo anterior les parece aun
seguro nos queda Imprimir
nuestros logs a medida que se producen, a muchos
les parecera un poco mucho y
otros perfectamente normal. Podemos configurar
syslogd de manera ciertos
mensajes sean enviados directamente al disposistivo
de impresion.
Esto es verdaderamente muy simple:
*.warn /dev/lp1
Todos los mensajes de cualquier servicio de prioridad
warn seran enviados a
la impresora ( /dev/lp1 ).
- USUARIOS CONECTADOS
Podemos enviar mensajes a usuarios logeados en
el sistema.
Por ejemplo:
*.crit root, admin
*.=emerg *
Todos los mensajes de prioridad crit (2) e inferiores
de cualquier servicio
seran enviados a los usuarios root y admin. Podemos
indicar tantos usuarios
como deseemos. En el segundo caso vemos como root
y admin fueron reemplazados
por un asteriso (*), de esta manera se enviaran
todos los mensajes de prioridad
emerg (0) de cualquier servicio a todos los usuarios
conectados en el sistema.
OTROS CONCEPTOS
===============
Ademas de lo que hablamos hasta ahora hay otros
conceptos que debemos conocer:
- logger
Este comando nos permite interactuar con syslog
desde la shell, quizas en
principio no les parezca muy util, pero a medida
que vayan utilizandolo y
agregandolo en sus scripts, veran lo util que
resulta.
Veamos algunos ejemplos:
karmax@utopia:~$
ls && logger -p user.info -t comando "ls
se ejecuto
correctamente"
root@utopia:~#
tail -1 /var/log/messages
Oct 18 06:58:49 utopia comando: ls se ejecuto
Veamos cada opcion que utilizamos:
-p user.info
Como ya vimos en syslog.conf aqui debemos especificar
servicio.prioridad
-t comando
Es el "tag" que le damos al mensaje.
"ls se ejecuto"
Es el mensaje en si, lo que se logea.
karmax@utopia:~$
logger -p user.info -f /home/karmax/pepe -t pepe
root@utopia:~#
tail -1 /var/log/messages
Oct 18 07:12:18 utopia pepe: rocknroll
-f /home/karmax/pepe
Aqui simplemente enviamos el contenido de este
archivo como un mensaje de
user.info
Recuerden que con logger estan produciendo un
mensaje de un servicio y
prioridad determinada, el cual syslog detectara
y lo enviara segun hayamos
indicado en su archivo de configuracion.
Como veran ambos ejemplos no son muy utiles a
lo que comodidad y seguridad
refiere, pero se los dejo para que hagan los suyos.
Con logger se puede hacer
mucho mas, para mas info: "man logger"
Si lo suyo es programar en C, les recomiendo "man
syslog"
- klogd
Se encarga de logear los mensajes del kernel,
al estar separado de syslogd,
ofrece una clara separacion de servicios. Hay
dos fuentes principales de
informacion referentes al log del kernel. Primero
intenta acceder a /proc/kmsg
si no puede (no esta montado el fs /proc) utiliza
la llamada a sistema
"sys_syslog" para obtener
los mensajes del kernel.
Si los mensajes del kernel son enviados a syslogd,
klogd cuenta con la
capacidad de darle una determinada prioridad al
mensaje. Por default todo lo
que sea inferior a 7 se vera en pantalla. Supongamos
q nosotros solo queremos
ver los mensajes (3, 2, 1), entonces deberiamos
utilizar la opcion -c del
klogd:
klogd -c 4
Una lista de a que corresponde cada cada nivel
de mensaje:
#define KERN_EMERG "<0>" /* system is unusable
*/
#define KERN_ALERT "<1>" /* action must
be taken immediately */
#define KERN_CRIT "<2>" /* critical conditions
*/
#define KERN_ERR "<3>" /* error conditions
*/
#define KERN_WARNING "<4>" /* warning conditions
*/
#define KERN_NOTICE "<5>" /* normal but
significant condition */
#define KERN_INFO "<6>" /* informational
*/
#define KERN_DEBUG "<7>" /* debug-level
messages */
Esta lista se encuentra en kernel.h para poder
verla simplemente hay que hacer
lo siguiente:
karmax@utopia:~$
cat /usr/include/linux/kernel.h |egrep "\"<"
El klogd es mucho mas que esto y si les interesa
les recomiendo "man klogd"
- Seguridad general
Si bien no podemos tener una confianza ABSOLUTA
en lo que dicen nuestros logs
(ya que pudieron haber sido modificados/evitados)
tenemos que intentar llevar
esta confianza al maximo, y para esto es necesario
asegurarlos.
Como administradores de sistema no queremos que
nadie vea nuestros logs y
mucho menos que lo pueda modificar o borrar. Imaginen
q alguien tenga acceso a
sus logs, bastaria analizar y analizar sin despertar
ninguna alerta buscando el
momento oportuno para realizar el ataque.. no
le resten importancia a los LOGS!
Como primera medida aseguremonos que los archivos
de log solo sean accesibles
para root y su grupo.
Para cambiar de owner y grupo:
chown owner grupo archivo
(donde archivo puede ser un directorio)
Por ejemplo:
root@utopia:~#
chown root root /var/log/user.log
root@utopia:~#
chmod 600 /var/log/user.log
Ahora comprobamos...
root@utopia:~#
ls -l /var/log/user.log
-rw------ 1 root root 2188 Oct 15 23:41 /var/log/user.log
Realizenlo con los archivos q crean necesarios
Tambien podemos utilizar el comando chattr para
cambiar los atributos de
archivo, nos convendria utilizar la opcion +a
(de esa manera solo se puede
agregar contenido al archivo). Si tenemos algun
programa como logrotate
deberiamos incluir en el script del programa un
-a para poder dejarlo en 0 y
luego un +a para volver a indicarle el attributo.
- Archivos principales
En syslog vienen definidos por default algunos
logs, entre ellos se
encuentran:
NOTA: Recuerden que el archivo syslog.conf puede
ser configurado para logear lo
que quieran, aqui comento lo "general", asi tambien
como cuando indique la
linea de syslog.conf correpondiente a ese log,
sera a modo de ejemplo.
/var/log/auth.log
Es en donde se guardan logs referidos principalmente
con la "seguridad" del
sistema.
/var/log/messages
*.=info;*.=notice;*.=warning /var/log/messages
En este archivo estan la mayoria de los mensajes,
a nivel informativo asi
tambien como nuestro el log que realiza el firewall
(NetFilter)
/var/log/syslog
En general se logea todo lo relacionado con accesos
(o intentos) a los
servicios del sistema (telnet, rpc). Asi tambien
como algunos avisos referentes
a los modulos.
/var/log/debug
*.=debug /var/log/debug
Es donde se registran los mensajes de prioridad
debug (6), si lo observan
veran que la mayoria son producidos por el kernel.
/var/log/daemon.log
daemon.* /var/log/daemon.log
Contiene un log de los Daemons (Servicios) que
se cargan en el sistema asi
tambien como informacion referente a avisos en
los modulos.
/var/log/kern.log
kern.* /var/log/kern.log
Los mensajes producidos por klogd en su mayoria
son almacenados aqui.
/var/log/user.log
user.* /var/log/user.log
En su mayoria son mensajes enviados a usuarios
en el sistema, como por
ejemplo un aviso de "shutdown".
/var/log/mail.log
mail.info /var/log/mail.info
mail.warning /var/log/mail.warning
mail.err /var/log/mail.err
Informacion de cada mensaje que entra y sale de
nuestro servidor, asi tambien
como detalles sobre el mail en cuestion.
/var/log/wtmp
Este archivo contiene la informacion relacionada
a los logins y logouts
relacionados al sistema (de de donde, horario,
fecha, usuario..) para poder
verlo tenemos que utilizar el comando "last".
Si quieren mas informacion al
respecto "man wmtp" y "man last".
Por ejemplo:
root@utopia:~#
last -2
karmax tty7 Sat Oct 18 07:57 still logged in
karmax tty8 Sat Oct 18 07:56 still logged in
Vemos cuales son los 3 ultimos logins o logouts
Relacionado con este, tambien tenemos el archivo
"utmp", el cual nos brinda
informacion acerca de los usuarios logeados en
el sistema al momento de
solicitar la informacion. Para acceder a esta
informacion podemos utilizar el
comando "who" (tambien se puede utilizar el last).
Mas informacion "man who".
/var/log/lastlog
Este archivo contiene informacion relativa a la
fecha y hora del ultimo login
de cada usuario, para acceder a esta informacion
podemos hacerlo con el comando
"lastlog".
Mas info "man lastlog". Por ejemplo:
root@utopia:~#
lastlog -u karmax
Username Port From Latest
karmax tty8 Sat Oct 18 07:56 -0300 2003
Para indicar de que usuario queremos saber anteponemos
-u al nombre de
usuario.
/var/log/faillog
Tambien tenemos el archivo "faillog" el cual indica
los intentos fallidos de
cada usuario al querer logearse en el sistema,
para acceder tenemos el comando
"faillog".
Mas info "man faillog". Por ejemplo:
root@utopia:~#
faillog -u karmax
Username Failures Maximum Latest
karmax 0 2
En la columna "Maximum" se indica la cantidad
de intentos erroneos que se
permiten antes de deshabilitar la cuenta, para
modificar este valor "faillog -u
karmax -m valor" donde valor es el numero maximo.
Recuerden que para realizar
esto necesitan tener permisos de escritura sobre
/var/log/faillog dejenle
acceso de escritura a este archivo solo a root
(por default).
sulog
Este archivo contiene la informacion referente
al comando "su" (man su),
utilizado para cambiar el user ID. Esta informacion
es bastante importante ya
que logeariamos usuarios que utilizaron el comando
su para, por ejemplo,
obtener permisos de root. Para poder logearlo
primero debemos comprobar el
archivo /etc/login.defs
root@utopia:~#
cat /etc/login.defs |fgrep "SYSLOG_SU_ENAB" -A
6
SYSLOG_SU_ENAB yes
SYSLOG_SG_ENAB yes
#
# If defined, all su activity is logged to this
file.
#
SULOG_FILE /var/log/sulog
Veamos los campos importantes:
SYSLOG_SU_ENAB yes
Ahi le indicamos que queremos que syslog logee
su
SULOG_FILE /var/log/sulog
En donde queremos que se logee
Tengan en cuenta que el archivo login.defs es
MUY importante para la
seguridad y configuracion de nuestro sistema,
en otra ocasion hablare de este y
otros archivos de configuracion del sistema.
- Bash
Si bien hay muchisimas shells en linux, hablare
de Bash ya que es la mas
conocida. En bash tenemos lo que se denomina Historial,
el cual segun como lo
configuremos, podra guardar los comandos que hayamos
ingresado. Para configurar
esto, lo podemos hacer desde el archivo de "profile"
tanto el global (para
todos) "/etc/profile" o para cada usuario "~user/.bash_profile".
En mi opinion podriamos configurarlo de manera
tal que los datos no sean
modificables (con el chattr visto anteriormente)
y ademas asegurarnos de que
cada usuario SOLO tenga acceso a su directorio,
para evitar que se anden
leyendo los historiales entre ellos.
Recordemos que puede ser un error MUY GRAVE de
seguridad permitir que otros
usuarios tengan acceso a esto. Ya que puede contener
informacion muy importante
que hayamos tipeado, nombres de archivo, acciones
que realizamos, etc. Tengamos
cuidado con esto.
Bueno, espero que les sea de alguna utilidad este
texto, prometo ampliar este
tema en otra ocasion, pero por hoy lo dejamos
asi.
Gonzalo Martinez
KarMax_mdp@ yahoo.com.ar
|
|
|
|