Copy Link
Add to Bookmark
Report
SET 029 0x04
-[ 0x04 ]--------------------------------------------------------------------
-[ Logs en Linux ]-----------------------------------------------------------
-[ by karmax ]-------------------------------------------------------SET-29--
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 que todo sea un archivo, desde un dispositivo como
el HD hasta un archivo de configuracion y los logs no son la excepcion.
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 anteponer 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, se almacenan para ser leidos mas tarde.
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 dispositivo 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 que alguien tenga acceso
a sus logs, bastaria 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 que 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 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.
Sigan disfrutando del boletin.
KarMax
*EOF*
