Tema 2 Acceso Remoto y Lectura de Logs

2Administracin Linux II - Modalidad VirtualTema 2

Acceso remoto y lectura de logs

Centro

de Educ

acin Co

ntinua

Edificio Aulas y relacin con el medio externoToledo y Lerida, Planta bajaPBX: 25-25-766

[email protected]

Capacitacin en Modalidad Virtual Administracin Linux II, Acceso remoto y lectura de logs Ricardo Ortega Levantamiento de texto: Ernesto Prez Redaccin de texto 2010: Ricardo Ortega Registro de derecho autoral: en trmite ISBN de este volumen: en trmite Depsito Legal: en trmite Publicado en http://cursos.cec-epn.edu.ec/aulavirtual/ desde julio 2008 CENTRO DE EDUCACIN CONTINUA ESCUELA POLITCNICA NACIONAL UNIDAD DE EDUCACIN VIRTUAL Quito Ecuador

CEC-EPN Linux II Tema 2

1

Tema 2

Acceso remoto y lectura de logs

Objetivos

1. Entender lo que es el SYSLOG y aprender a usarlo.

2. Interpretar, leer y analizar los logs del sistema.

3. Aprender el uso de SSH para acceso remoto

4. Saber copiar archivos entre mquinas de forma segura.

5. Realizar respaldos remotos con SSH.

Contenidos

OBJETIVOS........................................................................................................................................................ 1

CONTENIDOS .................................................................................................................................................... 1

2.1. SYSLOG ................................................................................................................................................. 2

2.1.1. ACTIVANDO EL SYSLOG: ..............................................................................................................................4

2.2. LEYENDO E INTERPRETANDO LOS LOGS DEL SISTEMA ........................................................................... 6

2.3. SYSLOG REMOTO ................................................................................................................................ 25

2.3.1 ENVIANDO LOGS A UN SERVIDOR REMOTO ....................................................................................................29

2.4. LOGROTATE ........................................................................................................................................ 30

2.5. HERRAMIENTAS PARA ANLISIS DE LOGS ........................................................................................... 36

2.5.1. LOGWATCH ..................................................................................................................................................36 2.5.2. PARMETROS DEL LOGWATCH ..........................................................................................................................41

2.6. INTRODUCCIN AL TRABAJO REMOTO MEDIANTE EL USO DE SSH ..................................................... 41

2.6.1 PROTOCOLO SSH ....................................................................................................................................42 2.6.2. CARACTERSTICAS DE SSH ...............................................................................................................................42 2.6.3. POR QU USAR SSH? ...................................................................................................................................43 2.6.4. VERSIONES DEL PROTOCOLO SSH .....................................................................................................................44

2.7. EL CLIENTE DE SSH............................................................................................................................... 45

2.7.1. LINUX (UNIX) ................................................................................................................................................45 2.7.2. USUARIOS ....................................................................................................................................................46 2.7.3. COMPRESIN ................................................................................................................................................47 2.7.4. WINDOWS ...................................................................................................................................................47


2

2.7.5. PALMOS .....................................................................................................................................................50

2.8. COPIANDO ARCHIVOS ENTRE MQUINAS DE FORMA SEGURA ........................................................... 51

2.8.1. WINSCP .....................................................................................................................................................52 2.8.2. SFTP ............................................................................................................................................................53

2.9. SSHD: EL SERVIDOR DE SSH ................................................................................................................. 54

2.9.1. QU LOGRAMOS CON NO ESCUCHAR EN LA INTERFAZ EXTERNA? ............................................................................56 2.9.2. OTRAS OPCIONES DE CONFIGURACIN DEL SSHD ............................................................................................56

2.10. OTRAS OPCIONES DEL SSH .............................................................................................................. 57

2.10.1. MS QUE UN SHELL SEGURO..........................................................................................................................57 2.10.2. REENVO POR X11 .......................................................................................................................................57 2.10.3. REENVO DEL PUERTO ...................................................................................................................................58

2.11. REALIZANDO RESPALDOS REMOTOS CON SSH ................................................................................ 59

2.11.1. TAR - SSH ..................................................................................................................................................59 2.11.2. AUTENTICACIN AUTOMTICA .......................................................................................................................61

2.1. Syslog

Syslog es el servicio que se utiliza en Linux para guardar los mensajes que los otros

servicios y demonios del sistema necesitan guardar. Recuerda que un servicio es un

programa que realiza alguna tarea en beneficio del sistema, por ejemplo el httpd, el

mysqld, el crond, el iptables son servicios importantes que requieren almacenar

informacin para auditora, monitoreo y depuracin.

No es recomendable que cada servicio o demonio guarde por su lado los mensajes,

puesto que el trabajo de guardar los mensajes es, muchas veces, pesado y debe tratar de

coordinarse para ahorrar recursos. No es lo mismo 5 50 servicios o demonios tratando

de escribir un mismo archivo, que 5 50 demonios envindole mensajes al syslog, que es

el que se encargar, en su debido momento, de escribir estos mensajes en el disco,

coordinando las escrituras y, sobre todo, ahorrando accesos de escritura innecesarios al

disco.

El directorio donde se almacenan los logs se llama /var/log

Sugiero que le des un vistazo. La mayora de archivos son planos (archivos de texto) que

pueden ser leidos con el less o con cualquier editor de texto, aunque no es recomendable

modificarlos. Imagnate un administrador del sistema que mete mano y modifica los logs

seguramente lo despedirn de su trabajo.


3

Algunos archivos son usados por varios servicios. Por ejemplo todos los siguientes

servicios necesitan escribir dentro de /var/log/maillog, que es un archivo

x servidor de smtp (para recibir correos) x servidor de POP3 (una variante que posteriormente estudiaremos para leer los

correos)

x servidor de IMAP (otra variante que posteriormente estudiaremos para leer los correos)

x Sistema antivirus y antispam

Todos ellos son sistemas independientes, separados, a los efectos de nuestro sistema

operativo Linux, que, sin embargo, escriben hacia /var/log/maillog.

-Oye, Gabriel, te imaginas cmo haran todos para escribir al mismo archivo?, crees que

entraran a empujones hasta lograr escribir?

El estudiante sonre imaginndose los acalorados empujones: A m se me ocurre poner

archivos de lock para saber que uno est escribiendo y que los dems deben esperar.

-Esta variante que t propones es una forma que podra considerarse medio adecuada-

admite Ricardo -slo que no es suficientemente rpida para servidores de mucha

actividad, porque eso de esperar introduce muchas demoras.

Hay una tercera alternativa: que todos ellos manden los mensajes que van a escribir en el

disco (a /var/log/maillog en este caso) hacia un servicio, que es el que se ocupar de

saber cundo y cmo escribir; este es el syslog. Estos mensajes se envan al kernel, que

se los entrega al syslog.

El syslog es un paquete que viene instalado por defecto en un servidor Linux, y,

normalmente, viene bien configurado y trabajando.

Nunca se recomienda detener el syslog, ya que sin l no se podran guardar muchos

mensajes de los demonios del sistema.

Debo hacerte notar, Gabriel, que los logs (histricos) del sistema siempre tienen mucha

informacin intil (ruido), que muchas veces no nos interesa, pero tambin tienen mucha

informacin til, que ya veremos cmo leer e interpretar.


4

2.1.1. Activando el syslog:

Ricardo explica que aunque normalmente el syslog viene activado, nunca est de ms

verificar si efectivamente lo est:

Escribe el comando chkconfig list syslog

chkconfig --list syslog

syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off

O con el comando service syslog status

Si por casualidad necesitramos activar el syslog, podramos hacerlo con el comando que

ya conocemos (chkconfig o service). Gabriel, recuerda por favor que este paso no es

necesario, solamente deben hacerlo las personas que no lo tengan activado:

chkconfig --level 2345 syslog on

service syslog start

Listo!, con esto tenemos el syslog activo.

Un mensaje de syslog se divide en tres partes:

1. Facilidad (facility) a la que se emite el mensaje. Se pueden utilizar 12+8 facilidades. (No te preocupes, Gabriel, en un rato expondremos todas ellas).

2. Prioridad (priority) conque se emite el mensaje. Existen 8 prioridades con las que se emiten el mensaje.

3. El mensaje en s. Que es una cadena de texto de libre uso.

El responsable de definir la facilidad, prioridad y texto del mensaje, es el servicio que emite

este mensaje. No somos nosotros.

Gabriel quiere sabe para qu se utilizan las facilidades y prioridades. Ricardo se

arremanga la camisa y empieza a explicar:

- Mira, no es necesario conocer todos los detalles para manejar el syslog, pero siempre

ayuda, as que te explicar: se usan para poder determinar hacia qu archivo vamos a

realizar la escritura de este mensaje.


5

Sin embargo, te sugiero no cambiar la configuracin que trae el sistema syslog hasta que

no hayas tenido varios aos de experiencia.

En nuestro caso, necesitamos entender las facilidades y prioridades, con el fin de

comprender el formato del archivo de configuracin /etc/syslog.conf; este formato es el que

usa nuestro demonio de syslog para saber hacia dnde escribir.

El formato de /etc/syslog.conf es el siguiente:

facilidad.prioridad /camino/a/archivo.log

Veamos un ejemplo: yo podra definir en /etc/syslog.conf estas dos lneas:

x mail.info /var/log/messages x mail.* /var/log/maillog

La primera lnea significara una orden para syslog, algo as como: "cualquier mensaje

enviado a la facilidad mail, con una prioridad info(rmativa), gurdalo en /var/log/messages".

La segunda lnea dira: "Cualquier mensaje emitido a la facilidad mail, con cualquier otra

prioridad, gurdalo en /var/log/maillog".

Este par (facilidad-prioridad) est separado por el signo de punto (.).

Aqu hay otra lnea interesante:

local7.* /var/log/boot.log

Todos los mensajes de la facilidad local7 irn a /var/log/boot.log. El sistema Linux al

arrancar enva hacia local7 todos los mensajes del sistema de arranque, lo que nos

permite ver cmo fue levantando cada subsistema al arrancar.

Debemos comentar que no todos los demonios del sistema hacen uso del syslog, sobre

todo porque el syslog, cuando fue creado, slo incluy una serie de facilidades que

parecan inamovibles para la poca (uucp, news), y no hizo provisiones muy tiles, para lo

que pudiera surgir en el futuro (web, ftp, proxy, p2p, etc). Por lo que muchos sistemas

escriben directamente a sus propios archivos de logs. Ejemplos de estos sistemas son:

x servidor web (httpd) x servidor de ftp x servidor proxy (squid)


6

x servidor de netbios (samba)

2.2. Leyendo e interpretando los logs del sistema

Mira Gabriel: Mucha informacin que se incluye en los logs puede y debe ser ignorada, ya

sea porque no comprendes el tema o porque no viene al caso con tu problemtica. Debes

leer y leer y releer! hasta saber qu es normal y qu no es normal. Cuando seas un experto,

ya no tendrs que leer tanto, porque te dars cuenta en seguida de lo que es normal y

puedes ignorar. Esto te lo da el tiempo. En principio, por novato, te tocar leer todo y buscar

informacin sobre todo, hasta saber qu va y qu no va.

Gabriel asiente con la cabeza. Sabe que le va a tocar leer mucho, antes de discernir lo que

es importante de lo que no lo es.

-Bien, dice Ricardo, vamos al grano: los logs del sistema. Si nos fijamos en syslog.conf

veremos que todos se guardan en /var/log. Vayamos a este directorio y listmoslo:

[root@eperez ~]# cd /var/log/ [root@eperez log]# ll total 5992 -rw-r----- 1 root root 19619 Sep 7 07:19 acpid -rw------- 1 root root 12391 Jul 21 16:48 anaconda.log -rw------- 1 root root 15593 Jul 21 16:48 anaconda.syslog -rw------- 1 root root 49165 Sep 7 07:19 boot.log -rw------- 1 root root 124258 Sep 4 09:13 boot.log.1 -rw------- 1 root root 98810 Aug 28 19:12 boot.log.2 -rw------- 1 root root 125832 Aug 21 19:23 boot.log.3 -rw------- 1 root root 47508 Aug 14 12:49 boot.log.4 -rw------- 1 root root 7088 Sep 7 12:01 cron -rw------- 1 root root 13611 Sep 4 09:13 cron.1 -rw------- 1 root root 14219 Aug 28 19:12 cron.2 -rw------- 1 root root 13586 Aug 21 19:23 cron.3 -rw------- 1 root root 5088 Aug 14 12:49 cron.4 drwxr-xr-x 2 lp sys 4096 Sep 4 09:13 cups -rw-r--r-- 1 root root 10473 Sep 7 07:19 dmesg drwxr-xr-x 2 root root 4096 Sep 7 07:19 gdm drwx------ 2 root root 4096 Aug 21 19:23 httpd drwxr-xr-x 2 root root 4096 Aug 26 23:24 ices -r-------- 1 root root 19136220 Sep 7 07:19 lastlog drwxr-xr-x 2 root root 4096 Jul 21 16:33 mail -rw------- 1 root root 6120 Sep 7 08:24 maillog -rw------- 1 root root 22977 Sep 4 09:13 maillog.1 -rw------- 1 root root 12346 Aug 28 19:12 maillog.2 -rw------- 1 root root 14484 Aug 21 19:23 maillog.3 -rw------- 1 root root 5308 Aug 14 11:44 maillog.4 -rw------- 1 root root 312996 Sep 7 12:01 messages -rw------- 1 root root 761886 Sep 4 09:13 messages.1 -rw------- 1 root root 682827 Aug 28 19:12 messages.2 -rw------- 1 root root 725521 Aug 21 19:23 messages.3 -rw------- 1 root root 279267 Aug 14 12:49 messages.4


7

drwx------ 2 root root 4096 Feb 21 2005 ppp -rw-r--r-- 1 root root 30114 Sep 7 08:25 prelink.log -rw-r--r-- 1 root root 22501 Sep 7 08:25 rpmpkgs -rw-r--r-- 1 root root 21125 Sep 3 08:53 rpmpkgs.1 -rw-r--r-- 1 root root 20891 Aug 26 09:39 rpmpkgs.2 -rw-r--r-- 1 root root 20781 Aug 19 09:08 rpmpkgs.3 -rw-r--r-- 1 root root 20675 Aug 10 08:45 rpmpkgs.4 drwx------ 2 root root 4096 Feb 21 2005 samba -rw-r--r-- 1 root root 126324 Aug 14 19:31 scrollkeeper.log -rw------- 1 root root 2865 Sep 7 09:07 secure -rw------- 1 root root 6175 Sep 4 08:45 secure.1 -rw------- 1 root root 5858 Aug 28 18:07 secure.2 -rw------- 1 root root 9804 Aug 21 18:18 secure.3 -rw------- 1 root root 4287 Aug 14 11:51 secure.4 -rw------- 1 root root 0 Sep 4 09:13 spooler -rw------- 1 root root 0 Aug 28 19:12 spooler.1 -rw------- 1 root root 0 Aug 21 19:23 spooler.2 -rw------- 1 root root 0 Aug 14 12:49 spooler.3 -rw------- 1 root root 0 Aug 8 07:29 spooler.4 drwxr-x--- 2 squid squid 4096 Sep 4 09:13 squid -rw------- 1 root root 542 Jul 29 11:19 sudolog drwxr-xr-x 2 root root 4096 Feb 21 2005 vbox -rw-rw-r-- 1 root utmp 422400 Sep 7 12:10 wtmp -rw-rw-r-- 1 root utmp 1669248 Sep 1 08:25 wtmp.1 -rw------- 1 root root 0 Sep 4 09:13 xferlog -rw------- 1 root root 0 Aug 28 19:12 xferlog.1 -rw------- 1 root root 0 Aug 21 19:23 xferlog.2 -rw------- 1 root root 0 Aug 14 12:49 xferlog.3 -rw------- 1 root root 0 Aug 8 07:29 xferlog.4 -rw-r--r-- 1 root root 32678 Sep 7 07:20 Xorg.0.log -rw-r--r-- 1 root root 32678 Sep 6 19:00 Xorg.0.log.old -rw-r--r-- 1 root root 891 Aug 1 06:52 Xorg.setup.log -rw-r--r-- 1 root root 14449 Sep 6 19:42 yum.log

Observamos que tenemos una serie de archivos y directorios. Vamos a examinar los ms

importantes para nosotros: la gran mayora son generados por el syslog, aunque vemos

otros que no revisamos en el syslog.conf, como por ejemplo yum.log o xferlog.

Estos, al igual que muchos ms, son generados por aplicaciones que no dependen del

syslog.

Gabriel se pregunta cules sern esas aplicaciones, y Ricardo, como leyndole la mente, le

dice:

Apache, squid y yum, por ejemplo tienen sus razones para no usar el syslog. No te voy a

explicar aqu las razones... t podrs investigarlo por tu cuenta ms adelante, pero tienen

por poltica grabar siempre los accesos y los errores est o no activado el syslog.

Adems, hay otros casos en los que el trabajo de usar el syslog es demasiado y no vale la

pena.

En serio?- pregunta Gabriel.


8

-Claro... mira, yum, por ejemplo, es el paquete de actualizacin del sistema. No se ejecuta

junto con otros yum y, por lo tanto, no necesita ms que escribirle muy espordicamente al

sistema. Lo mismo ocurre con los Xorg*, que son logs del ambiente grfico que se generan

slo al levantarlo, y no hay ms de un ambiente grfico normalmente activo.

-Pens que todo se escriba usando syslog, dice Gabriel.

-Pues ya ves que no. Pero una parte positiva es que al menos tenemos la certeza de que

todos los logs del sistema se escriben hacia /var/log, sean escritos por syslog o no.

Adems, debes haber notado que existen una serie de archivos con la terminacin 1 (2, 3, 4,

etc.). Estos son archivos viejos de logs. Ms adelante hablaremos del sistema de rotacin de

logs y el programa logrotate.

Veamos entonces los archivos de logs ms interesantes:

dmesg

El primer log que escribe el sistema al levantar se llama dmesg. Lo escribe al acabar de

arrancar el sistema y contiene informacin sobre cmo fue que el kernel fue subiendo. La

utilera dmesg es la encargada de almacenar la informacin del sistema a nivel de kernel y

hardware y, con slo ejecutarla al final del arranque de Linux, se obtiene este log.

-No veo muy bien su utilidad..., apunta Gabriel.

La utilidad es muy simple: gracias al dmesg tenemos la informacin exacta de cmo levant

el sistema la ltima vez; ya que cada vez que el sistema levanta, este archivo es

sobreescrito por el arranque.

Linux version 2.6.9-11.EL ([email protected]) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 Wed Jun 8 16:59:52 CDT 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001bff0000 (usable) BIOS-e820: 000000001bff0000 - 000000001bff8000 (ACPI data) BIOS-e820: 000000001bff8000 - 000000001c000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)


9

ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 *12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 apm: BIOS not found. audit: initializing netlink socket (disabled) audit(1126077532.756:0): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API ksign: Installing public key data Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA KM400/KM400A chipset ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize divert: not allocating divert_blk for non-ethernet device lo Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:11.1 ACPI: PCI interrupt 0000:00:11.1[A]: no GSI usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 NET: Registered protocol family 2 IP: routing cache hash table of 1024 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 9362) Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 ACPI: (supports S0 S1 S4 S5) ACPI wakeup devices: PCI0 UAR1 USB1 USB2 USB3 EHCI PS2K AC9 MC9 ILAN SLPB Freeing unused kernel memory: 144k freed kjournald starting. Commit interval 5 seconds


10

EXT3-fs: mounted filesystem with ordered data mode. SELinux: Disabled at runtime. SELinux: Unregistering netfilter hooks inserting floppy driver for 2.6.9-11.EL Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11 divert: allocating divert_blk for eth0 ehci_hcd 0000:00:10.3: irq 10, pci mem dc824f00 md: ... autorun DONE. usb 2-1: new low speed USB device using address 2 input: USB HID v1.10 Mouse [062a:0000] on usb-0000:00:10.0-1 ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] EXT3 FS on hda3, internal journal device-mapper: 4.4.0-ioctl (2005-01-12) initialised: [email protected] kjournald starting. Commit interval 5 seconds EXT3 FS on hda1, internal journal EXT3-fs: mounted filesystem with ordered data mode. EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended Adding 522104k swap on /dev/hda2. Priority:-1 extents:1 Sigue .

Este es el dmesg actual. Tiene informacin particular a mi sistema que puede ser analizada

concienzudamente y que tiene ciertos detalles que pueden ser de inters para m.

-S, ya veo, pero me resulta difcil entender todo lo est ah- dice Gabriel, poniendo cara de

resignacin.

-Tranquilo muchacho, te har un resumen:

El kernel que est corriendo es el 2.6.9-11.EL y fue compilado por la versin 3.4.3 del GCC.

Tengo 447MB de memoria (LOW RAM le llaman).

La cadena de arranque del kernel fue: ro root=LABEL=/ rhgb quiet elevator=as.

Tengo una cpu (CPU#0) que es un procesador de 1.6GHz, aproximadamente.


11

La memoria que ocupa el kernel es de 2MB, reserv otros 7MB por si lo necesitara el kernel,

y le quedan unos 450kb disponibles (Memory: 450300k/458688k available (2062k kernel

code, 7736k reserved, 656k data, 144k init, 0k highmem).

El sistema tiene una velocidad de 3268.60 BogoMIPS,

Activ el SELinux en modo permisivo (lo que es lo mismo que tener apagado el SELinux).

Tengo una cach L2 de 256K.

La CPU es un sempron (CPU: AMD Sempron(tm) 2400+ stepping 01).

Tiene un puerto serial (ttyS0).

Tiene dos discos ide (hda y hdc).

Tiene un cdrom (hdd).

Tiene una interfaz de ethernet del tipo via rhine (eth0: VIA Rhine II at 0xdffffe00,

00:0b:6a:cc:ed:26, IRQ 11.).

Eso bsicamente es lo que me interes averiguar de lo que el kernel detect al iniciar el

sistema. Gracias a este log lo hemos podido averiguar.

boot.log

Una vez que el kernel levanta, comienza el proceso de arranque de los servicios que

hayamos definido con el chkconfig. Este proceso puede ser observado en /var/log/boot.log

Cada servicio que arranca o se detiene en nuestro sistema queda grabado en boot.log:

Sep 7 07:19:27 eperez network: Bringing up loopback interface: succeeded

Sep 7 07:19:37 eperez xinetd: xinetd startup succeeded

Sep 7 07:19:29 eperez network: Bringing up interface eth0: succeeded

Sep 7 07:19:38 eperez sendmail: sendmail startup succeeded

Sep 7 07:19:38 eperez sendmail: sm-client startup succeeded

Sep 7 07:19:38 eperez gpm: gpm startup succeeded


12

Sep 7 07:19:38 eperez crond: crond startup succeeded

Sep 7 07:19:39 eperez squid: Starting squid:

Sep 7 07:19:40 eperez squid: .

Sep 7 07:19:40 eperez squid:

Sep 7 07:19:40 eperez rc: Starting squid: succeeded

Sep 7 07:19:42 eperez xfs: xfs startup succeeded

Sep 7 07:19:42 eperez anacron: anacron startup succeeded

Sep 7 07:19:42 eperez atd: atd startup succeeded

Sep 7 07:19:42 eperez readahead: Starting background readahead:

Sep 7 07:19:43 eperez rc: Starting readahead: succeeded

Sep 7 07:19:43 eperez messagebus: messagebus startup succeeded

Sep 7 07:19:43 eperez cups-config-daemon: cups-config-daemon startup succeeded

Sep 7 07:19:44 eperez haldaemon: haldaemon startup succeeded

Sep 7 14:44:10 eperez syslog: klogd shutdown succeeded

Sep 7 14:44:10 eperez syslog: syslogd startup succeeded

Sep 7 14:44:10 eperez syslog: klogd startup succeeded

Sep 7 14:44:10 eperez syslog: syslogd shutdown succeeded

Como la mayora de los logs que veremos, que son generados por el syslog, tienen un

formato muy fcil de entender. Primero van el mes, da, hora, minutos y segundos; despus

viene el nombre de la mquina que genera los logs (eperez en mi caso) y posteriormente

una descripcin de quin mand a generar el log y cul es el mensaje. Por ejemplo:

Sep 7 07:19:39 eperez squid: Starting squid:

Este mensaje indica que el da 7 de septiembre, a las 07:19:39, mi mquina (eperez) mand

a escribir un log a nombre de squid ( squid: ) con el mensaje de que haba iniciado el squid.

-Hasta aqu es sencillo, pero imagino que no siempre es as- dice Gabriel.

-Mira, Gabriel, el problema es que los logs no estn compuestos por una lnea, sino que

llevan cientos, muchas veces cientos de miles de lneas, y a veces es difcil buscar la

informacin que deseamos.

cron

Es el archivo encargado de guardar los eventos que han ocurrido en el cron del sistema

(/var/log/cron). Como puedes ver, tiene el mismo formato que usa syslog para todos sus


13

logs. Y ahora que ya has hemos visto algo de syslog, me puedes decir, ms o menos,

cmo es este formato, Gabriel?

Sep 7 14:50:00 srv4 CROND[13256]: (apache) CMD (/usr/local/Zend/sbin/cache_clean

/usr/local/Zend/etc/php.ini)

Sep 7 15:00:00 srv4 CROND[17385]: (root) CMD (/usr/local/bin/weblogs)



Sep 7 15:01:00 srv4 CROND[17846]: (root) CMD (run-parts /etc/cron.hourly)

Sep 7 15:10:00 srv4 CROND[27255]: (root) CMD (/usr/local/bin/weblogs)



- A ver si puedo. Primero: a qu hora ocurri un evento; despus, en qu mquina (srv4 en

este ejemplo no?) y, por ltimo, el comando ejecutado.

-Bien, como ves, hasta aqu, no tiene mayores misterios.

lastlog

Es un log compactado, binario, que no puede ser visto directamente, sino a travs de una

utilera llamada last.

[root@srv4 log]# last|less

root ttyS0 Tue Sep 6 06:06 - 06:13 (00:06)

reboot system boot 2.4.21-32.0.1.EL Tue Sep 6 05:59 (1+09:19)

root tty1 Tue Sep 6 05:52 - down (00:00)

root ttyS0 Tue Sep 6 05:51 - 05:52 (00:00)


14

root pts/2 144.226.uio.satn Tue Sep 6 05:48 - 05:49 (00:00)

root pts/2 144.226.uio.satn Mon Sep 5 21:41 - 21:41 (00:00)











El formato es muy fcil de entender. Qu usuario entr (root), desde qu terminal (pts/0),

desde qu IP (144.226.uio.satnet.net) da y mes y, las horas de entrada (por ejemplo de 8:25

a 8:27 por un espacio de (00:01); es decir, un minuto).

Adems de darnos toda esta informacin compactada, el lastlog nos indica cundo fue

reiniciado un sistema (por ejemplo este fue reiniciado a las 5:59AM) y el tiempo que estuvo

activo (en este caso 1da+9 horas y 19 minutos).

maillog


15

El maillog es el log que se ocupa de guardar todos los eventos de los servicios y sistemas

relacionados con la mensajera. Estos son smtp, pop, imap, antivirus, antispam, etc.

El formato es el estndar del syslog:

Sep 7 15:23:36 srv4 ipop3d[791]: Logout [email protected]

host=7.209.cue.satnet.net [200.63.211.7] nmsgs=0 ndele=0


host=nova [200.107.35.34] nmsgs=0 ndele=0


host=66.134.uio.satnet.net [200.25.134.66] nmsgs=11 ndele=0

Sep 7 15:23:37 srv4 sm-acceptingconnections[762]: j87KNXh2000762: from=,

size=54894, class=0, nrcpts=1,

msgid=,

proto=ESMTP, daemon=MTA, relay=gye14.ecua.net.ec [157.100.1.52]

Sep 7 15:23:37 srv4 sm-acceptingconnections[762]: j87KNXh2000762:

to=, delay=00:00:03, mailer=virthostmail, pri=84894, stat=queued

Sep 7 15:23:37 srv4 sm-acceptingconnections[790]: j87KNZ0F000790:

from=, size=4448, class=0, nrcpts=1, msgid=, proto=ESMTP, daemon=MTA,

relay=bay12-f15.bay12.hotmail.com [64.4.35.15]

Sep 7 15:23:37 srv4 sm-acceptingconnections[790]: j87KNZ0F000790:

to=, delay=00:00:01, mailer=virthostmail, pri=34448, stat=queued

Sep 7 15:23:37 srv4 ipop3d[792]: Login [email protected]

host=[201.245.100.209] nmsgs=0/0

Sep 7 15:23:37 srv4 ipop3d[815]: pop3 service init from 200.124.230.250

Sep 7 15:23:37 srv4 ipop3d[816]: pop3 service init from 201.219.10.2


16

Este es un pequeo extracto de un servidor. En el que indica que el servidor srv4 ha

generado todos esos logs. De ipop3d (pop) y de sendmail (sm-*), indicando de quin provino

un mail, el nmero de identificador (j87KNZ0F000790 por ejemplo) y hacia quin fue el mail,

as como el tiempo que se demor en enviarlo (delay=00:00:01) y el tamao (size) del mail.

Tambin nos indica si el mail fue enviado (stat=Sent) o encolado (stat=Queued), si un mail

est encolado es que est esperando para su procesamiento; si est Sent, no hay mayor

historia, el mail ha sido enviado a su destino.

Este log es uno de los ms importantes, pues nos permite averiguar qu pas con un mail y

por qu no lleg a su destino.

-Con esto, no podemos tener secreto ni mentir diciendo que hemos enviado un mail que

nunca escribimos- dice Gabriel un tanto asombrado.

-S, es verdad. Frecuentemente los usuarios llaman diciendo que enviaron un mail a

[email protected] y que fulanito no lo ha recibido. Mediante este log podemos saber si en

verdad hemos recibido un mail dirigido (to) a [email protected] y sabremos a la hora

que el otro servidor remoto recibi el correo. Si el mensaje tiene el stat=Sent, entonces no es problema nuestro; nosotros lo enviamos a su servidor de destino y tienen que averiguar

ellos por su otra parte por qu no lleg un mail.

messages

/var/log/messages es otro de los logs ms importantes. Mantiene toda una serie de eventos

informativos del sistema que nos permiten ver qu ha estado ocurriendo. Cmo te imaginas

que es el formato?- pregunta Ricardo a su alumno.

-Supongo que el formato es el generado por syslog.

-Supones bien. Sigamos aprendiendo la utilidad de messages, porque, de hecho, puede ser

muy til en muchas ocasiones. Yo, bsicamente, primero miro en messages antes que en

cualquier otro log, para determinar fallas en el sistema (aunque, claro, si el error o problema

es exclusivo de mail, miramos mejor en maillog).

secure


17

Aqui no slo se guarda informacin de quin entr, sino detalles que podemos obtener en el

lastlog, como la hora en que entr, la IP, a qu hora se desconect, mediante qu servicio

entr, etc. Tambin indica los comandos de sudo que se hayan ejecutado:

Sep 7 15:35:20 srv4 xinetd[7282]: EXIT: imap pid=6633 duration=0(sec)

Sep 7 15:35:20 srv4 xinetd[7282]: START: pop3 pid=6637 from=201.219.10.2


Sep 7 15:35:20 srv4 xinetd[7282]: START: imap pid=6645 from=67.15.12.90















18







xferlog

Es un log generado por el demonio de ftp, que indica qu archivos estn siendo transferidos

hacia o desde nuestro servidor via ftp, y en general qu acciones estn tomando los clientes

va ftp:

Wed Sep 7 13:45:51 2005 5 200.63.242.254 80611 /var/www/html/guayaquil/fotos/fotos.htm

a _ i r farras ftp 0 * c

Wed Sep 7 13:54:36 2005 1 200.63.242.254 14918

/var/www/html/guayaquil/farrasculturales_4/teatro.htm a _ i r farras ftp 0 * c

Wed Sep 7 13:54:40 2005 2 200.63.242.254 50090

/var/www/html/guayaquil/farrasculturales_4/farrasculturales_4.htm a _ i r farras ftp 0 * c

Wed Sep 7 13:55:36 2005 2 200.63.242.254 24215 /home/farras/baradero.htm a _ i

r farras ftp 0 * c

Wed Sep 7 13:59:20 2005 0 200.63.242.254 24215 /home/farras/baradero.htm a _ d

r farras ftp 0 * c


19

Wed Sep 7 13:59:30 2005 1 200.63.242.254 24215 /var/www/html/baradero.htm a _ i r farras

ftp 0 * c

Wed Sep 7 14:00:55 2005 0 200.63.242.254 4392

/var/www/html/guayaquil/farrasculturales_4/imagenes/normalixta_ind.jpg b _ i r farras ftp 0 *

c

Wed Sep 7 14:01:00 2005 0 200.63.242.254 4296

/var/www/html/guayaquil/farrasculturales_4/imagenes/bienal_26_index.jpg b _ o r farras ftp 0

* c

Wed Sep 7 14:03:12 2005 1 200.63.242.254 45039 /var/www/html/indexmain.htm a _

i r farras ftp 0 * c

Wed Sep 7 14:07:15 2005 3 200.63.242.254 29445

/var/www/html/imagenes/portada_foto.jpg b _ i r farras ftp 0 * c

Wed Sep 7 14:07:19 2005 0 200.63.242.254 3113

/var/www/html/imagenes/alcohol_index.jpg b _ o r farras ftp 0 * c

/var/log/httpd/access.log

Me indica los accesos que hay o ha habido a nuestro(s) sitio(s) web. De esta forma

podemos determinar cul es el objeto o script que consume ms recursos o espacio. Ms

tarde en el curso, usaremos estos logs para revisar y crear estadsticas sobre nuestros sitios

web y dems. El formato es muy parecido al del syslog, pero no es generado por el syslog

sino directamente por el apache:

200.69.167.87 - - [07/Sep/2005:17:40:33 -0500] "GET

/guayaquil/dondefarrear1/flyer/sto_remedio_120_100.jpg HTTP/1.1" 200 6213

"http://www.farras.com/guayaquil/dondefarrear1/agenda_flyer.htm" "Mozilla/4.0 (compatible;

MSIE 6.0; Windows NT 5.1)"


20

200.55.225.156 - - [07/Sep/2005:17:40:33 -0500] "GET /guayaquil/fotos/2005-09-

03/miro/05.jpg HTTP/1.1" 304 - "http://www.farras.com/guayaquil/fotos/2005-09-03/miro.php"

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

201.218.6.46 - - [07/Sep/2005:17:40:33 -0500] "GET

/Templates/menu2002/botonInscribete.gif HTTP/1.0" 200 1898

"http://www.farras.com/indexmain.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

200.69.166.211 - - [07/Sep/2005:17:40:31 -0500] "GET

/guayaquil/television/imagenes/vamoscontodo.jpg HTTP/1.1" 200 26493

"http://www.farras.com/guayaquil/television/telesistema.htm" "Mozilla/4.0 (compatible; MSIE

6.0; Windows NT 5.1)"

201.218.6.46 - - [07/Sep/2005:17:40:33 -0500] "GET

/Templates/menu2002/granhermanobanner.jpg HTTP/1.0" 200 5108

"http://www.farras.com/indexmain.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

201.218.6.46 - - [07/Sep/2005:17:40:33 -0500] "GET

/guayaquil/dondefarrear1/flyer/fizz_09_120_100.jpg HTTP/1.0" 200 8131

"http://www.farras.com/guayaquil/dondefarrear1/agenda_flyer.htm" "Mozilla/4.0 (compatible;

MSIE 6.0; Windows NT 5.1)"

/var/log/httpd/error_log

Es el log que nos indica cualquier evento o circunstancia que el httpd haya encontrado y

necesite reportar.

-Cmo qu por ejemplo?, pregunta Gabriel.

- Como que no encuentre un objeto o pgina o que determine que su sistema tiene alguna

falla y necesite reportarlo.

[Tue Aug 30 15:09:05 2005] [notice] Digest: done

[Tue Aug 30 15:09:06 2005] [notice] Apache configured -- resuming normal operations


21

[Tue Aug 30 19:13:30 2005] [notice] caught SIGTERM, shutting down

[Tue Aug 30 19:15:13 2005] [notice] suEXEC mechanism enabled (wrapper:

/usr/sbin/suexec)

[Tue Aug 30 19:15:13 2005] [notice] Digest: generating secret for digest authentication ...



[Tue Aug 30 19:47:58 2005] [notice] caught SIGTERM, shutting down

[Tue Aug 30 19:50:29 2005] [notice] suEXEC mechanism enabled (wrapper:

/usr/sbin/suexec)

[Tue Aug 30 19:50:30 2005] [notice] Digest: generating secret for digest authentication ...



/var/log/squid/access.log

Es el log que nos indica quin est accediendo a travs de nuestro proxy hacia Internet. Nos

permite tambin sacar estadsticas de uso de la conexin en lo referente a la navegacin

web.

1126286893.476 9511 127.0.0.1 TCP_MISS/200 613 POST

http://cursos.Ricardoperez.com/moodle/course/mod.php - DIRECT/67.15.12.90 text/html

1126286896.333 2857 127.0.0.1 TCP_MISS/200 16984 GET

http://cursos.Ricardoperez.com/moodle/mod/resource/view.php? - DIRECT/67.15.12.90

text/html

1126286896.634 300 127.0.0.1 TCP_MISS/200 252 GET

http://toolbarqueries.google.com/search? - DIRECT/64.233.185.104 text/html


22

1126286905.599 2766 127.0.0.1 TCP_MISS/200 19092 GET

http://cursos.Ricardoperez.com/moodle/course/mod.php? - DIRECT/67.15.12.90 text/html

1126286905.665 1801 127.0.0.1 TCP_MISS/304 222 GET

http://cursos.Ricardoperez.com/moodle/lib/editor/lang/en.php - DIRECT/67.15.12.90 -

1126286908.230 1162 127.0.0.1 TCP_MISS/200 252 GET


1126287042.973 262 127.0.0.1 TCP_MISS/302 513 GET

http://toolbar.google.com/version3f? - DIRECT/64.233.167.124 text/plain

1126287043.466 466 127.0.0.1 TCP_MISS/200 516 GET

http://toolbar.google.com/version3f_withCookie? - DIRECT/64.233.183.124 text/plain

1126287045.190 880 127.0.0.1 TCP_MISS/200 2205 GET

http://cursos.Ricardoperez.com/moodle/lib/editor/popups/insert_table.php -

DIRECT/67.15.12.90 text/html

1126287045.584 393 127.0.0.1 TCP_MISS/200 252 GET


/var/log/squid/cache.log

Nos indica cmo ha arrancado el squid, qu parmetros est usando, adems de qu

errores o advertencias ha encontrado en el sistema que le impide arrancar, o qu le impide

seguir trabajando. Es importante siempre leerlo en caso de que el squid d problemas.

2005/09/04 16:47:41| Starting Squid Cache version 2.5.STABLE6 for i686-RedHat-linux-

gnu...

2005/09/04 16:47:41| Process ID 2325

2005/09/04 16:47:41| With 1024 file descriptors available


23

2005/09/04 16:47:41| DNS Socket created at 0.0.0.0, port 32770, FD 4

2005/09/04 16:47:41| Adding nameserver 127.0.0.1 from /etc/resolv.conf

2005/09/04 16:47:41| User-Agent logging is disabled.

2005/09/04 16:47:41| Referer logging is disabled.

2005/09/04 16:47:41| Unlinkd pipe opened on FD 9

2005/09/04 16:47:41| Swap maxSize 102400 KB, estimated 7876 objects

2005/09/04 16:47:41| Target number of buckets: 393

2005/09/04 16:47:41| Using 8192 Store buckets

2005/09/04 16:47:41| Max Mem size: 8192 KB

2005/09/04 16:47:41| Max Swap size: 102400 KB

2005/09/04 16:47:41| Rebuilding storage in /var/spool/squid (CLEAN)

2005/09/04 16:47:41| Using Least Load store dir selection

2005/09/04 16:47:41| Set Current Directory to /var/spool/squid

2005/09/04 16:47:41| Loaded Icons.

2005/09/04 16:47:42| Accepting HTTP connections at 0.0.0.0, port 3128, FD 11.

2005/09/04 16:47:42| Accepting ICP messages at 0.0.0.0, port 3130, FD 12.

2005/09/04 16:47:42| WCCP Disabled.

2005/09/04 16:47:42| Ready to serve requests.

2005/09/04 16:47:42| Store rebuilding is 34.8% complete


24

2005/09/04 16:47:42| Done reading /var/spool/squid swaplog (11775 entries)

2005/09/04 16:47:42| Finished rebuilding storage from disk.

2005/09/04 16:47:42| 11775 Entries scanned

2005/09/04 16:47:42| 0 Invalid entries.

2005/09/04 16:47:42| 0 With invalid flags.

2005/09/04 16:47:42| 11775 Objects loaded.

2005/09/04 16:47:42| 0 Objects expired.

2005/09/04 16:47:42| 0 Objects cancelled.

2005/09/04 16:47:42| 0 Duplicate URLs purged.

2005/09/04 16:47:42| 0 Swapfile clashes avoided.

2005/09/04 16:47:42| Took 0.9 seconds (13120.1 objects/sec).

2005/09/04 16:47:42| Beginning Validation Procedure

2005/09/04 16:47:42| Completed Validation Procedure

2005/09/04 16:47:42| Validated 11775 Entries

2005/09/04 16:47:42| store_swap_size = 92140k

2005/09/04 16:47:43| storeLateRelease: released 0 objects

Aqu vemos un log de arranque del squid, bsicamente todo fue bien hasta que arranc y

dej guardados unos parmetros de arranque por si acaso los tuviramos que analizar. Es el

log ms importante cuando hay problemas en el squid.


25

En general, siempre que tengamos un problema, debemos referirnos a los logs. En un inicio

es muy difcil leerlos, pues normalmente no se sabe cul es el log que puede tener la

verdad; por lo tanto, si no se conoce, sugiero se busque en messages, y posteriormente en

maillog, si es referido a los mails, o en el directorio de squid o de httpd, si es referido a uno

de ellos dos.

Sinceramente, y aqu te lo advierto muy bien, Gabriel: si tienes un problema, ni se te ocurra

preguntar en un foro o sitio de Internet cul es la solucin sin haber indicado lo que dicen los

logs. Si no lo haces, perders tu tiempo, porque la nica respuesta que obtendrs ser:

mustrame los logs.

-S, entiendo: en los logs est la clave de todo lo que ha sucedido. Es como tener un cmara

que guarda todos nuestros movimientos.

-Bueno, ms o menos... En fin, para solucionar un problema, normalmente tenemos que

revisar los logs, analizar el error y buscar una solucin de acuerdo a lo que se dice.

Es una falla comn por parte de los novatos preguntar sin ofrecer detalles del problema, sin

decir exactamente qu sucede, qu dicen los logs, qu dice la consola. Y al no hacerlo estn

pecando exactamente de lo que no le gusta a la comunidad de Linux: de preguntar

intilmente. Antes, hay que leer los logs, analizarlos y mostrarlos, para poder obtener ayuda.

-Prometo no ser un pecador... al menos en eso, dice Gabriel sonriendo.

-Adems, sabes qu? En el mismo momento en que realizamos la tarea de bsqueda de

los logs, y anlisis para ponerlos en un foro... generalmente nos damos cuenta del error!!

-Sin ayuda?-pregunta Gabriel.

-Bueno, si es que el error est puesto en los logs, no tenemos casi ni que escribir en los

foros, porque automticamente nos damos cuenta de lo que es.

2.3. Syslog remoto

En la tercera reunin, Ricardo y Gabriel tratan del tema del syslog remoto. Ricardo se sienta

delante de la computadora y empieza a explicar:


26

Una de las mejores caractersticas del syslog es que es capaz de aceptar o enviar las

solicitudes de logs de forma remota.

Ejemplo: podemos tener un equipo (o varios) que no tenga disco, pero que s soporte enviar

logs a servidores remotos. Por ejemplo, cisco lo hace con sus ruteadores, linksys, 3com,

allied telesyn, dlink, y muchos ms tienen una directiva que permite enviar los logs hacia un

servidor remoto.

Mira este ejemplo de un telfono de VoIP que tengo:

Si te fijas arriba, dice: Syslog server y tambin dice syslog level (es para saber cules

priorities enviar).

Tambin puede hacerse entre mquinas Linux. Por ejemplo, si tenemos sospechas de que

una mquina tiene el disco daado, y que casi con seguridad no podr reportar problemas

con el disco porque no podr escribir los logs (los logs lgicamente se escriben a disco), la

solucin es enviar los logs hacia una mquina remota y cuando algo pase, entrar en el

sistema remoto y verificar los logs.

Hay muchas variantes. Tenemos sistemas embebidos, es decir sistemas que no tienen

disco, que, por ejemplo, pueden ser usados como firewall o en cualquier otra actividad. Al no

tener disco estos sistemas tienen que escribir remotamente a otro lugar, esto se puede


27

hacer con el syslog.

Gabriel pregunta:

Cmo hacemos para aceptar logs de equipos remotos?

Muy fcil, el demonio de syslog de Linux permite mediante un switch adicional (-r) aceptar

conexiones va Internet de otros sistemas de log.

Sencillamente tenemos que llamar a nuestro syslog con el switch -r, para esto editamos

/etc/sysconfig/syslog:

vi /etc/sysconfig/syslog # Options to syslogd # -m 0 disables 'MARK' messages. # -r enables

logging from remote machines # -x disables DNS lookups on messages recieved with -r #

See syslogd(8) for more details SYSLOGD_OPTIONS="-m 0" # Options to klogd # -2 prints

all kernel oops messages twice; once for klogd to decode, and # once for processing with

'ksymoops' # -x disables all klogd processing of oops messages entirely # See klogd(8) for

more details KLOGD_OPTIONS="-x"

El directorio /etc/sysconfig tiene muchos archivos de configuracin de varios demonios, entre

ellos el syslog. Te pido que, si real mente te interesa aprender, te molestes en ver los

diferentes archivos adicionales que hay dentro de /etc/sysconfig, para que te enteres de los

diferentes parmetros que potencialmente se pueden usar en los diferentes demonios.

En este caso estamos editando el archivo de configuracin del syslog. Como vemos,

bsicamente hay dos lneas a editar, la segunda (KLOGD_OPTIONS) no la toquemos, mejor

remitmonos a la primera.

Encima de esta primera lnea (SYSLOGD_OPTIONS) veremos las diferentes opciones que

tenemos para llamar al syslog.

En principio, viene con una opcin activada, que es la de apagar las marcas (-m). La

facilidad marcas (MARK) es un mensaje que el sistema manda a escribir cada cierto tiempo.

Lo nico que hace es guardar una lnea en todos los archivos de logs con la hora en que se

escribi.

Tiene como ventaja que permite conocer a qu hora dej de funcionar el sistema (si es que

algn da dejara de funcionar), pues tenemos la certeza de que se escribe una marca cada


28

30 segundos.

-Cada medio minuto?- pregunta Gabriel sorprendido.

-Tal como lo oyes. Pero se suele apagar, porque como defecto provoca que cada cierto

tiempo se escriba a disco y, en muchos sistemas, como las laptops, no deja que se apague

la mquina cuando no se, usa sino que la mantiene constantemente encendida y el disco se

mantiene funcionando continuamente. Tambin en las noches (porque hay muchos que

duermen con la laptop al lado) se oye un continuo: "click", que es el disco escribiendo la

marca.

Adems, en los servidores, el tener que escribir cada 30 segundos una marca implica

consumir un poco ms de recursos, por lo que siempre debemos dejar desactivada las

marcas (-m 0).

Volviendo al tema que nos interesa, si quisiramos aceptar logs de mquinas remotas,

sencillamente tendramos que agregar el switch -r a esta lnea:

SYSLOGD_OPTIONS="-m 0 -r -x"

-Hum... pero tambin agregamos -x, qu es la -x? - pregunta Gabriel, mirando el monitor.

-Simple, le indica al syslog que no resuelva la direccin IP del servidor remoto, para as

acelerar el proceso de escritura de logs.

Al recibirse una peticin remota, sta se enviar con una facility y una priority. Nuestro

servidor determinar en qu lugar escribir estas facility y priority (como hara para las

peticiones locales) y, adems, tratar de averiguar el hostname que le enva ese log

mediante los dns del sistema y escribir entonces en el log adecuado esta informacin.

Esto de resolver los dns es un tema lento, pues cada resolucin puede tardar entre algunas

dcimas de segundo y algunos segundos, lo que puede hacer que, potencialmente, el

sistema consuma recursos. Por eso es importante desactivarlo, para no gastar recursos

resolviendo direcciones IP. Entonces el syslog sencillamente guardar el log con la direccin

IP.

Al terminar de editar el archivo /etc/sysconfig/syslog, debemos reiniciar nuestro syslog para

que tome los nuevos valores:


29

service syslog restart

Una vez que los sistemas remotos comiencen a enviarnos informacin, los logs se vern

ms o menos as:

Sep 7 14:01:01 192.168.1.1 crond(pam_unix)[7658]: session closed for user root

Si te fijas, Gabriel, en el nombre de la mquina sencillamente se pone la IP desde donde

provino el evento del log, lo que nos permite diferenciar entre logs locales a nuestra mquina

y logs particulares de cada sistema remoto, pues cada uno ir con su propia IP.

2.3.1 Enviando logs a un servidor remoto

Bueno, Gabriel, acabamos de ver cmo configurar nuestro servidor para recibir logs de

sistemas remotos.

Pero qu tal que yo no quiera eso, sino todo lo contrario? Cmo hacer para que nuestra

mquina no guarde los logs localmente, sino que los enve hacia un sistema remoto?

Ante todo, debemos indicar que el procedimiento anteriormente descrito y este

procedimiento no deben hacerse en una misma mquina.

-Claro, dice Gabriel. -No tiene sentido configurar una mquina para que reciba logs remotos,

y adems configurarla para que enve los logs de ella a otros sistemas.

- Exactamente, o se hace uno, o el otro. No es que sean incompatibles, pero no tendra

mucho sentido.

El procedimiento para enviar los logs a un servidor remoto es muy fcil. En syslog.conf, en

vez de indicarle un archivo para escribir, podemos decirle que enve remotamente ese tipo

de log a otro lugar.

vi /etc/syslog.conf

*.info;mail.none;authpriv.none;cron.none @192.168.1.1

authpriv.* @192.168.1.1 mail.* @192.168.1.1


30

En el ejemplo anterior, como ves, estamos indicndole a nuestro sistema que enve los logs

de mail y los mensajes, as como los mensajes de authpriv, al (@) servidor 192.168.1.1

Una vez cambiado el syslog.conf procedemos a reiniciar el syslog para que tome los nuevos

cambios:

service syslog restart

En cuanto hayamos hecho esto, podemos generar algn evento (por ejemplo entrar como

root en otra consola) y veremos que nuestros logs ya no se estn escribiendo al disco, sino

que se van a ese sistema remoto.

Debemos recordar que ese sistema remoto debe tener activada la opcin de recibir eventos

de log remotos.

Cualquier tipo de evento de log puede ser enviado remotamente. Es decir, si en todas las

lneas del syslog.conf ponemos @192.168.1.1 en vez del nombre de archivo, entonces todos

los logs sern enviados remotamente y nada se escribir a disco.

2.4. logrotate

-Ricardo, es muy interesante todo lo que hemos visto sobre los logs del sistema- le dice

Gabriel a su tutor.

- S, en realidad si te gusta Linux, es un tema apasionante. Ahora, es necesario que sepas

que si los logs no se rotaran, es decir si no se comprimen y si no se eliminaran de vez en

cuando, el espacio en disco de nuestro sistema crecera desmesuradamente hasta llenarse.

-No haba pensado en eso- dice Gabriel.

- Pero no hay que preocuparse. En Linux existe una utilera que se ejecuta todos los das

(desde /etc/cron.daily) que se llama logrotate.

logrotate lo que hace es leer la configuracin general desde /etc/logrotate.conf y la

configuracin particular para cada log rotado desde /etc/logrotate.d


31

En cuanto lea estos parmetros, va a ir de directorio en directorio, dentro de los indicados en

/etc/logrotate.d, y truncar los logs para disminuir su tamao.

-Truncar?- pregunta Gabriel extraado.

-Por truncar realmente quiero decir "cambiar su nombre". Me explico mejor: Supongamos

que lleg la hora de rotar /var/log/maillog, lo que el sistema realiza son tres acciones:

1. Renombrar (con el comando mv) el archivo /var/log/maillog a /var/log/maillog.1.

2. Crear un archivo vaco (touch /var/log/maillog), de forma tal que pueda comenzar a

escribirse en l.

3. Avisarle a todos los servicios relacionados que dejen de escribir en el inodo de maillog.1

y comiencen a escribir al inodo de maillog.

Ahora ya sabemos de dnde vienen estos archivos de /var/log que contienen.1 .2 .3 .4, etc...

son los logs viejos.

maillog.2 significara "el antiguo maillog.1". Antiguo, porque seguramente ya toc rotar

nuevamente los logs y se hizo una operacin parecida a esta:

* maillog.1 lo movi a maillog.2

* maillog lo movi a maillog.1

Por supuesto, cuando pase un tiempo tocar hacer algo similar:



* maillog lo movi a maillog.1

-Entiendo cmo se van rotando, pero por qu todo este movimiento?-pregunta Gabriel.

- Porque los logs pueden alcanzar muchos megas, incluso gigas de tamao y escribir a un

archivo de 600MB de tamao o de digamos 1.8GB de tamao es bien un proceso lento. Por

eso hace falta, de vez en cuando, cortar y poner un archivo nuevo de log.

- Entonces, se va a rotando y cortando, pero hasta cundo todo este movimiento?

- Mira Gabriel, en el archivo de configuracin del logrotate se indica cuntos logs viejos

mantener. Mantener muchos logs es bueno porque te permite remitirte a muchos das o

semanas atrs para averiguar algo. Pero, a la vez, se consume mucho espacio en disco el


32

mantener muchos logs.

-Y no se pueden comprimir estos logs?

-S, se pueden comprimir. Como son archivos de texto, pueden comprimirse muchas veces,

en promedio 1/10 de su tamao, lo que hace que se ahorre bastante espacio.

-Pero recuerda primero usar logwatch (que se explica ms adelante) ya que si primero usas

logrotate antes que logwatch, no obtendrs ningn reporte. El logwatch se explica en el

siguiente punto.

Veamos un momento /etc/logrotate.conf, que es el archivo principal de configuracin de

logrotare

vi /etc/logrotate.conf

# see "man logrotate" for details

# rotate log files weekly

weekly

# keep 4 weeks worth of backlogs

rotate 4

# create new (empty) log files after rotating old ones

create

# uncomment this if you want your log files compressed

#compress

# RPM packages drop log rotation information into this directory

include /etc/logrotate.d


33

# no packages own wtmp -- we'll rotate them here

/var/log/wtmp {

monthly

create 0664 root utmp

rotate 1}

Aqu lo que vemos son parmetros de configuracin general. Estn bien explicados. Por

ejemplo, RedHat/Centos por defecto indica que los logs deben rotarse semanalmente

(weekly), esto es, slo una vez a la semana realmente actuar el logrotate, los dems das

operar calladito, sin hacer nada.

El parmetro weekly es el que se encarga de indicar que se rotar semanalmente. En mi opinin, en sistemas medianamente cargados (empresas, isp, etc) se debe cambiar las

rotaciones y hacerlas diarias. Cambiando weekly por daily el sistema rotar los logs todos

los das por la maana, reduciendo el consumo de disco.

Ahora, muchos administradores desean ver logs anteriores a la fecha de la rotacin. El

logrotate se encarga de mantener una cantidad determinadas de copias de acuerdo al

parmetro: rotate #; por defecto rotate 4 es el valor que RedHat sugiere, lo que indicara que

mantenga 4 copias de los logs (como por defecto las rotar semanalmente, entonces

tendremos 4 semanas de copias guardadas).

Si cambiamos la rotacin a: diaria, podramos indicarle que haga 7 rotaciones.

-As mantendramos 7 das de copias no?

- S, en realidad podemos poner el parmetro que queramos: 15 30, segn sea nuestro

inters o el razonamiento de la empresa. Sugiero siempre ms de 3 rotaciones.

En empresas muy cargadas, que generan una gran cantidad de logs, no es saludable

mantener todas estas rotaciones, por lo que, a veces, es bueno bajarlo a 3 o menos

rotaciones.

Igualmente, si necesitamos mantener por ms tiempo las copias anteriores, siempre existen

los respaldos para realizarlas y no mantenerlas en disco.


34

Ms adelante vemos un parmetro que est comentado, y que para m es de mucha utilidad.

Es el compress, que permite que una vez rotado un log, este se comprima para ahorrar

espacio. Los logs son pura informacin en modo texto, por lo que el nivel de compresin

suele ser alto. Tenemos casos de clientes con ms de 300 megas de logs, a veces ms de

500, y no es muy saludable mantener todos esos logs rotados abiertos, pues consumiran

mucho disco. Al comprimirlos (por defecto se comprimen con gzip), estos logs bajan a 40 o

menos megas, lo que s hace que sea sostenible el mantener varios logs antiguos en

nuestro sistema.

Para activar la compresin de logs rotados, sencillamente podemos descomentar (quitar la

#) esta lnea y, a partir de maana, se rotarn y comprimirn.

Cmo se rotar cada archivo de log?

Hasta el momento hemos visto la configuracin general del logrotate.

Bueno, dentro de /etc/logrotate.d tenemos una cantidad de ficheros que nos dan una

indicacin sobre cmo se rotar cada log. Al logrotate se le define tambin por cmo se

rotan cada uno de los archivos dentro de /var/log; estas definiciones estn dentro de

/etc/logrotate.d. Sugiero que entres y mires cada uno de los archivos que estn ah dentro.

-Lo har!- promete Gabriel con mucha conviccin.

Por ejemplo: todos los logs que son atendidos por el syslog, se rotan desde un mismo

archivo de configuracin:

vi /etc/logrotate.d/syslog

/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log

/var/log/cron {

sharedscripts

postrotate

/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true


35

endscript}

Cmo se entiende todo esto?

Gabriel mira el monitor y se siente un poco abrumado..., hay muchas lneas que no

comprende.

-Ya veo que ests un poco perdido- le dice Ricardo. Mira, es menos complicado de lo que te

imaginas. La primera lnea, hasta el signo de {, indica exactamente todos y cada uno de los

archivos (con sus caminos completos) sobre los que estamos tratando. En este ejemplo son

messages, secure, maillog, spooler, boot.log y cron.

sharedscripts indica que se deben ejecutar las siguientes acciones al rotar este log. Las

acciones pueden ser:

* prerotate: accin a realizar antes de rotar los archivos.

* postrotate .... endscript, indicar la accin a tomar (o acciones) posterior a haber rotado

(cambiado de extensin) los scripts. En este caso sencillamente se le enviar un -HUP al

syslog para que vuelva a leer los archivos de scripts y tome los nuevos inodos de los

archivos de logs (los que se acaban de crear con tamao 0).

Normalmente la accin de postrotate es la que se utiliza e incluye el reinicio del servicio (o el

HUP) para que vuelva a leer su configuracin, pero, sobre todo, para que se d cuenta de

que el archivo donde escriba ya no est (est con otro nombre) y que debe comenzar a

escribir en el nuevo, recin creado.

Veamos el caso del archivo de rotacin para httpd:

vi /etc/logrotate.d/httpd

/var/log/httpd/*log {

missingok

notifempty

sharedscripts


36

postrotate

/bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true endscript}

Como ves es muy similar: trabajamos con todos los archivos .log que estn presentes dentro

de /var/log/httpd, esto se indica justo antes del {

Con missingok: indicamos que no hay problema; es decir, que proceda si falta uno de ellos,

de esta forma el script no fallar si falta uno de los archivos o todos.

notifempty: si el log est vaco, no rotarlo (no hace falta perder el tiempo cambiando de

nombre a un log vaco, no consume nada).

Por lo dems, vemos que es muy parecido, recarga de igual forma el apache en el

postrotate.

Normalmente no debemos preocuparnos por lo que est programado dentro de un script de

rotacin, pero existen ocasiones muy especiales en las que los demonios (sobre todo el

apache) fallan al rotar (el signo ms evidente es que el servidor deja de responder a las 4am

o una hora parecida, que es cuando el logrotate se ejecuta), en este caso podemos realizar

una reprogramacin del script de rotacin en comandos del shell que consideremos

necesario.

2.5. Herramientas para anlisis de logs

2.5.1. logwatch

Esto de andar leyendo todos los logs del sistema se vuelve muy complejo a veces.

Imagnate, Gabriel, todos los das tener que leer 10 20 megas (o ms) de logs del sistema

slo para determinar que no hubo eventualidades de consideracin. Es muy pesado.

-S, sin duda. Pero, entonces, qu hay que hacer?

- Pues tenemos logwatch que es la herramienta que, por defecto, viene en nuestro sistema

CentOS. Esta herramienta se ocupa de analizar diariamente todos los logs importantes de

nuestro sistema y categorizar los eventos guardados en ellos. En cuanto ha hecho eso,

manda un mail a root con el resumen de lo que encontr.


37

Es muy sencillo, a continuacin vemos un ejemplo de un mail que nos lleg:

From [email protected] Thu Sep 8 07:54:07 2005

Date: Thu, 8 Sep 2005 07:54:06 -0500

From: Ernesto Perez

To: [email protected]

Subject: LogWatch for eperez.ecualinux.com

################### LogWatch 5.2.2 (06/23/04) ####################

Processing Initiated: Thu Sep 8 07:54:04 2005

Date Range Processed: yesterday

Detail Level of Output: 0

Logfiles for Host: eperez.ecualinux.com

################################################################

--------------------- Cron Begin ------------------------

**Unmatched Entries**

STARTUP (V5.0)

---------------------- Cron End -------------------------

--------------------- Named Begin ------------------------



38

succeeded: 1 Time(s)

---------------------- Named End -------------------------

--------------------- pam_unix Begin ------------------------

crond:

Unknown Entries:

session closed for user root: 12 Time(s)

session opened for user root by (uid=0): 12 Time(s)

---------------------- pam_unix End -------------------------

--------------------- Connections (secure-log) Begin ------------------------


userhelper[5017]: pam_timestamp: updated timestamp file `/var/run/sudo/root/unknown'

userhelper[5018]: running '/usr/share/system-config-soundcard/system-config-soundcard'

with root privileges on behalf of 'root'

userhelper[8529]: pam_timestamp: updated timestamp file `/var/run/sudo/root/unknown'

userhelper[8530]: running '/usr/sbin/system-install-packages //root/Desktop/skype-1.2.0.11-

fc3.i586.rpm' with root privileges on behalf of 'root'

userhelper[10824]: running '/sbin/poweroff' with root privileges on behalf of 'root'

---------------------- Connections (secure-log) End -------------------------

--------------------- sendmail Begin ------------------------

Bytes Transferred: 23306


39

Messages Sent: 4

Total recipients: 4

---------------------- sendmail End -------------------------

--------------------- SSHD Begin ------------------------

SSHD Killed: 1 Time(s)

SSHD Started: 1 Time(s)

---------------------- SSHD End -------------------------

------------------ Disk Space --------------------

/dev/hda3 8.6G 6.3G 1.9G 77% /

/dev/hda1 99M 8.3M 86M 9% /boot

/dev/hdd2 7.5G 6.8G 368M 95% /home

/dev/hdc 69M 69M 0 100% /media/cdrecorder

###################### LogWatch End #########################

Como vemos, nos cataloga en diferentes secciones los eventos detectados por l. Los

mensajes que muestra no son una receta. Quiero decir que estos varan segn el evento

que haya ocurrido y segn el tipo de sistema. Por eso, debemos ser capaces de analizar y

determinar qu es un verdadero problema y qu no lo es.

-Cmo hay que analizar para detectar los problemas?- pregunta Gabriel.

-En mi caso, primero veo los eventos del cron. Como ves, dice algo de unmatched entries...

Lo veo y considero que realmente no es un grave problema para m, as que contino con

las otras lneas.


40

Despus un mensaje del named. Entiendo que es cuando se reinici (por eso dice success,

que es una buena seal para m).

pam es el sistema de autenticacin; indica que el usuario root abri 12 veces sesiones con

el sistema y tambin cerr 12 veces. Nada inusual: era yo mismo y lo recuerdo; no las 12

veces, por supuesto, pero s que estuve trabajando todo el da de ayer y abr y cerr

sesiones a discrecin.

En secure log dice que configuraron algo del sonido (/usr/share/system-config-

soundcard/system-config-soundcard) como root y en efecto as lo hice. Adems, dice que

instalaron un paquete (skype.rpm) y as fue, pues quera hablar por telfono va Internet.

Ms abajo hay un pequeo reporte de sendmail, que indica que se enviaron unos 23k en

mails en total 4 mensajes. Puede ser, realmente es un sistema personal mo y esos

mensajes deben haber sido eventos que el mismo sistema me envi como reportes (este

mismo reporte posiblemente). Este reporte en sistemas de produccin es ms grande y

alcanza los millones de mensajes y decenas de gigas de transferencia.

Posteriormente, me indica que mataron una vez al ssh y lo arrancaron una vez (cuando

encend y cuando apagu la mquina, claro est). No hay mayor inconveniente.

Y al final vemos un reporte del uso del disco en ese momento que se corri el reporte.

Tampoco hay mayor problema con mis discos pero agradezco que me enve este reporte.

Estos reportes son cansones, de hecho te confieso que no los analizo todos los das ni en

todos los servidores. Se estima que un administrador de Linux debe ser capaz de manejar

tranquilamente 10 servidores Linux, y al decir manejar, me refiero a ejecutar todas las tareas

que veremos durante el curso (contigo y con tus compaeros), incluidas estas de revisin de

logs, por lo que leer los logs de 10 servidores es verdaderamente un problema.

Eso s: siempre recomiendo echar una mirada a los logs y detectar eventos inusuales. El

logwatch nos ayuda mucho a revisar estos eventos y los consolida en una gran medida; sin

embargo, nada como el ojo humano para poder detectar problemas en un sistema. Por eso

siempre es bueno entrenarse para detectar cules son los eventos que normalmente

ocurren en nuestro sistema y cules han comenzado a salir para, posteriormente, poder

determinar cmo mejorar nuestro sistema o reaccionar ante fallas o problemas.


41

2.5.2. Parmetros del logwatch

El logwatch tambin tiene un archivo de configuracin con una infinidad de parmetros, de

los cuales veremos algunos muy sencillos. Este archivo de configuracin principal est en

/etc/logwatch/conf/logwatch.conf

Como vemos, este archivo est vaco (slo una indicacin de que los parmetros por

defecto pueden ser encontrados en /usr/share/logwatch/default.conf/logwatch.conf)

Dentro de /etc/logwatch/conf/logwatch.conf podemos incluir cualquier parmetro que

deseemos cambiar, yo sugerira solamente analizar e incluir dos (no son obligatorios, son

opcionales)

vi /etc/logwatch/conf/logwatch.conf

MailTo = root

Detail = low

MailTo es el parmetro que indica a qu usuario vamos a enviar los logs con las advertencias. Por defecto va a root, pero podemos, y yo sugiero que as lo hagamos, enviar

los mails con el reporte a un usuario normal, de ser posible fuera del sistema. Se puede

indicar la direccin completa ([email protected]).

Detail es el parmetro que indica con qu nivel de detalle o verbosidad hablar el reporte, por defecto es Low, pero si consideramos que necesitamos reportes ms detallados

podemos ponerlo en Med o en High para incrementar el nivel. Yo prefiero no tocarlo, pues

con low me genera bastante cantidad de mensajes.

Existen otros parmetros que podemos configurar, pero no es nuestro inters analizarlos; en

todo caso, si usamos man logwatch, o analizamos este archivo de configuracin, podemos

obtener una cantidad impresionante de opciones adicionales.

2.6. Introduccin al trabajo remoto mediante el uso de


42

SSH

Ricardo y Gabriel se renen nuevamente.

-Preparado Gabriel? Para un correcto estudio de este tema, necesitars seguramente de

dos mquinas con Linux para que una acte como servidor y otra como cliente.

Empecemos:

2.6.1 Protocolo SSH

SSH (o Secure SHell) es un protocolo que facilita las comunicaciones seguras entre dos

sistemas, usando una arquitectura cliente/servidor, que les permite a los usuarios

conectarse remotamente a un host .

A diferencia de otros protocolos de comunicacin remota, tales como FTP o Telnet, el SSH

encripta la sesin de conexin, haciendo imposible que alguien pueda obtener las

contraseas no encriptadas y tampoco permite ver qu se est escribiendo dentro de esta

sesin.

SSH est diseado para reemplazar los mtodos ms viejos y menos seguros para

registrarse remotamente en otro sistema a travs de la shell de comando, tales como telnet

o rsh. Un programa relacionado, el scp, reemplaza a otros programas diseados para copiar

archivos entre hosts como rcp. Ya que estas aplicaciones antiguas no encriptan contraseas

entre el cliente y el servidor, evita usarlas mientras sea posible.

-Entonces, es preferible usar siempre SSH en lugar de FTP y Telnet?- pregunta Gabriel.

-S, as es. Recuerda que el uso de mtodos seguros para registrarse remotamente a otros

sistemas reduce los riesgos de seguridad, tanto para el sistema cliente como para el sistema

remoto.

2.6.2. Caractersticas de SSH

El protocolo SSH proporciona las siguientes protecciones:

* Despus de la conexin inicial, el cliente puede verificar que se est conectando al

mismo servidor al que se conect anteriormente.

* El cliente transmite su informacin de autenticacin al servidor usando una encriptacin


43

robusta de 128 bits.

* Todos los datos enviados y recibidos durante la sesin se transfieren por medio de

encriptacin de 128 bits, lo cual los hace extremamente difciles de descifrar y leer.

* El cliente tiene la posibilidad de reenviar aplicaciones X11 desde el servidor. Esta

tcnica, llamada reenvo por X11, proporciona un medio seguro para usar aplicaciones

grficas sobre una red.

Ya que el protocolo SSH encripta todo lo que enva y recibe, se puede usar para asegurar

protocolos inseguros. El servidor SSH puede convertirse en un conducto para convertir en

seguros los protocolos inseguros mediante el uso de una tcnica llamada reenvo por puerto,

como por ejemplo POP, incrementando la seguridad del sistema en general y de los datos.

Red Hat Enterprise Linux contiene el paquete general de OpenSSH (openssh), as como

tambin los paquetes del servidor OpenSSH (openssh-server) y del cliente (openssh-

clients).

2.6.3. Por qu usar SSH?

-Bien Gabriel, es importante que comprendas las razones por las que es tan necesario el

uso de SSH.

Gabriel asiente y anota lo que el tutor le explica.

Los potenciales atacantes tienen a su disposicin una variedad de herramientas que les

permiten interceptar y redirigir el trfico de la red para ganar acceso al sistema. En trminos

generales, estas amenazas se pueden catalogar del siguiente modo:

* Intercepcin de la comunicacin entre dos sistemas: en este escenario existe un tercero

en algn lugar de la red entre entidades en comunicacin, que hace una copia de la

informacin que pasa entre ellas. La parte interceptora puede interceptar y conservar la

informacin, o puede modificar la informacin y luego enviarla al recipiente al cual estaba

destinada.

Este ataque se puede montar a travs del uso de un paquete sniffer, que es una utilidad

de red muy comn.

* Personificacin de un determinado host: con esta estrategia, un sistema interceptor finge


44

ser el recipiente a quien est destinado un mensaje. Si funciona la estrategia, el sistema del

usuario no se da cuenta del engao y contina la comunicacin con el host incorrecto. Esto

tambin est relacionado con la tcnica de ataque de hombre en el medio.

Esto se produce con tcnicas como el envenenamiento del DNS o spoofing de IP

(engao de direcciones IP).

Ambas tcnicas interceptan informacin potencialmente confidencial y, si esta intercepcin

se realiza con propsitos hostiles, el resultado puede ser catastrfico.

Si se utiliza SSH para inicios de sesin de shell remota y para copiar archivos, se pueden

disminuir notablemente estas amenazas a la seguridad. Esto es porque el cliente SSH y el

servidor usan firmas digitales para verificar su identidad. Adicionalmente, toda la

comunicacin entre los sistemas cliente y servidor es encriptada. No servirn de nada los

intentos de falsificar la identidad de cualquiera de los dos lados de la comunicacin, ya que

cada paquete est cifrado por medio de una llave conocida slo por el sistema local y el

remoto.

2.6.4. Versiones del protocolo SSH

El protocolo SSH le permite a cualquier programa cliente y servidor, construido segn las

especificaciones del protocolo, comunicarse de forma segura y ser usado de intercambiable.

Existen dos variedades de SSH actualmente (versin 1 y versin 2). La versin 1 de SSH

hace uso de muchos algoritmos de encriptacin patentados (sin embargo, algunas de estas

patentes han expirado) y es vulnerable a un hueco de seguridad que potencialmente le

permite a un intruso insertar datos en la corriente de comunicacin.

-No puede tan efectiva si es vulnerable, opina Gabriel.

- Tiene su pequeo defecto... por suerte hay una nueva versin. La suite OpenSSH bajo Red

Hat Enterprise Linux utiliza por defecto la versin 2 de SSH, que tiene un algoritmo de

intercambio de llaves mejorado que no es vulnerable al hueco de seguridad en la versin 1.

Sin embargo, la suite OpenSSH tambin soporta las conexiones de la versin 1.


45

2.7. El cliente de SSH

Ese mismo martes, despus de bajar a comer algo rpido en la cafetera, Ricardo y Gabriel

continan.

- Dnde nos quedamos?- pregunta Ricardo mirando los monitores.

- Estbamos mirando las caractersticas de SSH.

- Ah ya me acuerdo! Bien, sigamos. Estudiemos ahora el cliente de SSH. Mira, el cliente de

SSH es aquel que nos permite conectarnos desde nuestra estacin de trabajo hacia nuestro

servidor.

Existen una infinidad de clientes de SSH, pero bsicamente veremos 3, para 3 diferentes

sistemas operativos.

2.7.1. Linux (unix)

Existe un cliente de SSH que viene conjuntamente con nuestro servidor Linux. Este paquete

se llama openssh-clients y viene por defecto en todos los Linux instalados.

Uno de los componentes del openssh-clients es la utilera SSH. Veamos cmo usarla:

SSH 192.168.1.1

nos permitir conectarnos al servidor 192.168.1.1 y acceder a l.

El SSH utiliza un sistema de clave pblica y privada. La primera vez que nos conectemos a

un sistema nos indicar que no conoce de la clave del sistema destino, que no la puede

validar, que por favor indiquemos si tenemos confianza en este sistema o no.

-Necesito un ejemplo para poder captar bien lo que me dices, -dice Gabriel mirando el

monitor.

- Claro, a eso iba. Por ejemplo, aqu nos estamos conectando al diario El Mercurio de

Cuenca por primera vez y obtenemos este anuncio:

[root@eperez ~]# SSH mail.elmercurio.com.ec

The authenticity of host 'mail.elmercurio.com.ec (200.93.223.170)' can't be established.

RSA key fingerprint is 0b:95:df:77:60:e3:8c:4b:24:3e:59:e0:4d:1a:c7:9e.


46

Are you sure you want to continue connecting (yes/no)?

Si quisiramos entrar, debemos escribir perfectamente la palabra: yes y ah procedera a

pedirnos la clave.

Si somos detallistas, nos debemos haber fijado que no slo podemos hacer SSH a una

direccin IP sino que podemos usar el nombre de la mquina (mail.elmercurio.com.ec en mi

caso).

2.7.2. Usuarios

Por defecto el SSH enva como username el usuario conque estamos conectados en

nuestra mquina de origen, por lo que si estamos en nuestra mquina conectados como root

el comando anterior tratar de conectarse a 192.168.1.1 como el usuario root.

Slo nos pedir la clave de root de la mquina remota para entrar.

Ahora, si quisiramos conectarnos como otro usuario, podramos usar:

SSH -l eperez 192.168.1.1

esto permitir conectarnos al servidor 192.168.1.1 ya no como el usuario con el que estamos

conectados, sino que nos permitir entrar como cualquier otro usuario que queramos de

forma remota. T puedes poner tu nombre, Gabriel.

Mira, otra variante para entrar con otro usuario es:

SSH [email protected]

Este comando tiene exactamente el mismo efecto, nos permite entrar remotamente con el

usuario eperez, aun cuando seamos otro usuario en nuestra mquina.


47

2.7.3. Compresin

Por defecto el SSH no comprime los datos que circulan en su canal.

- Sin comprimir? Imagino, entonces, que la mquina se volver lenta, apunta Gabriel.

- S, y por eso, muchas veces nos interesa comprimir estos datos para lograr una velocidad

de trabajo mejor. Por ejemplo, cuando estamos conectndonos a un sitio remoto a travs de

una mala conexin. Para esto podemos usar el switch -C, el cual le indicar al SSH que use

compresin para el intercambio de datos y, a menudo, s mejora la percepcin de velocidad.

SSH -C mail.elmercurio.com.ec

-Qu hara -C en esta lnea que acabo de poner, Gabriel?

-Nos permitira conectarnos con compresin al diario El Mercurio de Cuenca.

-Exactamente. En una red local la compresin no tiene mayor efecto, no se nota mucha

diferencia en la velocidad pero s hace que el SSH consuma cpu en comprimir los datos. Por

lo tanto, si estamos trabajando desde una red local o estamos conectndonos a un sitio

cercano o con buena conexin hacia nosotros, sugiero que no uses la compresin para

evitar el consumo de recursos en vano.

Los switches se pueden combinar a conveniencia, por ejemplo:

SSH -l eperez -C mail.elmercurio.com.ec

El cliente de SSH de Linux tambin nos permite ejecutar comandos en otros sistemas de

forma automtica. Por ejemplo:

SSH 192.168.1.1 ls

Lo que hara sera conectarse a 192.168.1.1 y ejecutar el comando ls.

Por supuesto, en vez de ls podemos usar cualquier otro comando presente en el sistema

remoto.

2.7.4. Windows

-Ahora, no todos tenemos la dicha de usar Linux en nuestras mquinas clientes... dice


48

Ricardo, hacindole un guio de complicidad a Gabriel.- Muchas veces tenemos la

desgracia de tener Windows en nuestras estaciones de trabajo por situaciones

imponderables y necesarias.

Gabriel sonre y piensa que l ha tenido esa "desgracia" casi toda su vida. Por eso, quiere

aprender bien Linux.

-Pero cmo nos conectamos a nuestros servidores Linux entonces? Bueno, como

imaginas, existe una solucin que nos permite usar el mouse (para eso es Windows no?) y

se llama PuTTY.

Realmente hay muchas otras soluciones, pero la ms extendida es el PuTTY, primero

porque es gratuita y segundo porque realmente tiene todas las caractersticas necesarias

para trabajar con nuestros servidores Linux.

-Qu bien que sea gratis... y es fcil encontrarla en Internet?- pregunta Gabriel.

- Cuando me ha hecho falta, entro en Google y pongo: putty download. De primerito saldr!

Es un .exe, no hay ni que ejecutarlo... sencillamente lo ponemos en el escritorio y ya!

Puedes bajarlo de aqu:

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

si te fijas es una URL muy larga, por lo que es preferible que uses google.com para buscar

por las palabras "putty download". Recuerda descargar del sitio primario. Nunca bajes de

e

Tema 2 Acceso Remoto y Lectura de Logs

Documents

Transcript of Tema 2 Acceso Remoto y Lectura de Logs