Linux Original Courseware - LX5: Seguridad y Contraseguridad

LOC: Linux Original Courseware*
Correspondiente al Curso
LX5: Seguridad y Contraseguridad
-1-
(*) Originaly Developed for CentralTECH - 53 Páginas
Tabla de Contenidos
Convenciones ...................................................................................................................................................................................... 4
Capítulo 1 - Particionamiento Avanzado ........................................................................................................................................... 5
Introducción .................................................................................................................................................................................... 5
LVM – Logical Volume Management ........................................................................................................................................... 5
¿Cómo LVM nos soluciona los problemas?................................................................................................................................... 5
Configurando, Compilando e Instalando........................................................................................................................................ 6
Conceptos y Comandos de Referencia ........................................................................................................................................... 7
¿Cómo se crea un Physical Volume? ............................................................................................................................................. 7
¿Cómo se crea un Volume Group?................................................................................................................................................. 8
¿Cómo se crea un Logical Volume dentro de un Volume Group? ................................................................................................ 8
Un ejemplo de “/etc/fstab” luego de implementar LVM ............................................................................................................... 9
Ejemplos prácticos de la administración de un LVM .................................................................................................................. 10
Agregando Physical Volumes a un Volume Group. ................................................................................................................ 10
Removiendo Physical Volumes (discos) de un Volume Group .............................................................................................. 10
Remover un Logical Volume.................................................................................................................................................... 11
Reduciendo y aumentando el tamaño de un Logical Volume ................................................................................................. 11
Realizando backups al vuelo con snapshots................................................................................................................................. 11
Crear el Snapshot ...................................................................................................................................................................... 11
Montar el Snapshot ................................................................................................................................................................... 12
Realizar el Backup .................................................................................................................................................................... 12
Remover el Snapshot ................................................................................................................................................................ 12
Conclusión..................................................................................................................................................................................... 12
Más Información ....................................................................................................................................................................... 12
Capítulo 2 – Monitoreo del Sistema ................................................................................................................................................. 13
Introducción .................................................................................................................................................................................. 13
Los demonios syslog y klogd........................................................................................................................................................ 13
Breve ejemplo explicativo ........................................................................................................................................................ 13
Facilidades y niveles de seguridad: .............................................................................................................................................. 13
¿Dónde registrar los logs?............................................................................................................................................................. 14
¿Cómo configurar un servidor de logs?........................................................................................................................................ 15
Configuración en el equipo “cliente” ....................................................................................................................................... 15
Configuración en el equipo “servidor”..................................................................................................................................... 16
Iniciando el syslogd ...................................................................................................................................................................... 16
¿Que pasó con el klogd? ............................................................................................................................................................... 16
Logger ........................................................................................................................................................................................... 17
Logrotate ....................................................................................................................................................................................... 17
Conclusión..................................................................................................................................................................................... 19
Más Información ....................................................................................................................................................................... 19
Capítulo 3 – Comprobando la Integridad de los Archivos............................................................................................................... 20
Introducción .................................................................................................................................................................................. 20
¿Cómo mantenernos al día con las actualizaciones de seguridad? .............................................................................................. 20
¿Qué es un “rootkit”?.................................................................................................................................................................... 21
AIDE (Advanced Intrusion Detection Environment) .................................................................................................................. 21
Pasos a seguir para tener funcionando el AIDE ........................................................................................................................... 22
Comprobando la integridad del disco....................................................................................................................................... 22
Sugerencias para un chequeo de integridad más seguro ......................................................................................................... 23
Comprobando la seguridad con “chkrootkit”............................................................................................................................... 25
¿Cómo saber si el equipo ha sufrido una intrusión y tiene un “rootkit” instalado? ................................................................ 25
¿Cómo utilizar el “chkrootkit”?................................................................................................................................................ 25
¿Cómo verifico un disco secundario con el “chkrootkit”? ...................................................................................................... 26
¿Puedo ejecutar el “chkrootkit” vía “cron”? ............................................................................................................................ 26
-2-
Conclusión..................................................................................................................................................................................... 26
Más Información ....................................................................................................................................................................... 26
Capítulo 4 – Herramientas de Auditoría........................................................................................................................................... 27
Introducción .................................................................................................................................................................................. 27
Fuser .............................................................................................................................................................................................. 27
Netstat............................................................................................................................................................................................ 27
Netcat............................................................................................................................................................................................. 28
Nmap ............................................................................................................................................................................................. 28
Nessus............................................................................................................................................................................................ 32
John The Ripper: ........................................................................................................................................................................... 34
Conclusión..................................................................................................................................................................................... 35
Capítulo 5 – Virtual Private Networks ............................................................................................................................................. 36
Introducción .................................................................................................................................................................................. 36
Requisitos mínimos....................................................................................................................................................................... 36
Configuración del cliente.............................................................................................................................................................. 39
Configurando las reglas de ruteo e iptables.................................................................................................................................. 41
Conclusión..................................................................................................................................................................................... 41
Capítulo 6 – Network Intrusión Detection Systems......................................................................................................................... 42
Snort .............................................................................................................................................................................................. 42
1. Que es el Snort? .................................................................................................................................................................... 42
2. ¿Que es un NIDS?................................................................................................................................................................. 42
3. Porque usar un NIDS? .......................................................................................................................................................... 42
4. Tipos de IDS: ........................................................................................................................................................................ 42
5. Instalando el Snort: ............................................................................................................................................................... 42
6. Configurando el Snort:.......................................................................................................................................................... 42
7. ¿Como estar al día con las reglas?........................................................................................................................................ 43
8. Probando el Snort.................................................................................................................................................................. 43
Portsentry ...................................................................................................................................................................................... 44
1. ¿Qué es el Portsentry?........................................................................................................................................................... 44
2. ¿Cómo hace esto el Portsentry?............................................................................................................................................ 44
3. ¿Cómo instalamos el Porsentry?........................................................................................................................................... 45
4. ¿Cómo configuramos el Portsentry? .................................................................................................................................... 45
5. Iniciando y probando el servicio. ......................................................................................................................................... 46
Conclusión..................................................................................................................................................................................... 46
Capítulo 7 – Capítulo Final............................................................................................................................................................... 47
Introducción .................................................................................................................................................................................. 47
¿Qué es un sniffer?........................................................................................................................................................................ 47
¿Para qué puedo usar un sniffer? .................................................................................................................................................. 47
¿Hay algún lugar donde pueda conectarme para ver el tráfico de todo internet?........................................................................ 47
¿Cómo trabaja un sniffer?............................................................................................................................................................. 47
¿Qué es una MAC address? .......................................................................................................................................................... 47
¿Cómo detectar un sniffer? ........................................................................................................................................................... 48
¿Cómo prevenir el sniffing? ......................................................................................................................................................... 48
¿Qué aplicaciones hay disponibles en Linux para usar de sniffer? ............................................................................................. 48
¿Cómo prevenir el sniffing en la práctica?................................................................................................................................... 49
Utilizando GNUPG ....................................................................................................................................................................... 50
¿Cómo generar una llave?......................................................................................................................................................... 50
¿Cómo distribuir nuestra llave? ................................................................................................................................................ 51
¿Cómo importar llaves de nuestros contactos? ........................................................................................................................ 52
¿Cómo encriptar archivos? ....................................................................................................................................................... 52
Conclusión..................................................................................................................................................................................... 52
-3-
Convenciones
Para el correcto entendimiento de la documentación y de sus contenidos, explicamos las convenciones utilizadas en este
documento.
Formato Ejemplo
Los nombres de Software, Productos Comerciales
y/o Compañías. Negrita + Cursiva (Itálica) Debian GNU/Linux
Las palabras en inglés que no necesiten

traducción y/o palabras en español que denotan
Cursiva (Itálica) Kernel
características
Las siglas que corresponden a protocolos,

características, etc. Mayúsculas + Negrita TCP/IP
Las teclas y/o combinación de teclas, donde la

Control
combinación se expresa uniendo los nombres de
Monoespacio
cada tecla con un signo + (más). Alt+F2
Los nombres de archivos y dispositivos,

contenidos de archivos y salidas por consola. Monoespacio /etc/resolv.conf
Los Comandos y utilitarios del sistema operativo,

con sus respectivos parámetros, denotando que
deben ser escritos tal cual se leen. Se debe asumir
Monoespacio + Negrita mount /mnt/cdrom
que seguido a cada comando el usuario debe
pulsar la tecla Enter.
Para expresar los parámetros de los comandos se

cat [-v] arch.txt
respetará la convención de las man pages
Monoespacio + Negrita
(páginas de ayuda) utilizando llaves, corchetes cp ar1 ar2 [...] <dir>
rectos, corchetes en ángulo y pipes.
En caso que sea necesario hacer aclaraciones adicionales, o brindar información extensiva o de precauciones, se utilizará alguna
de las siguientes notas:
Nota
Esta clase de notas informan al lector/alumno sobre ayudas o vías rápidas al
procedimiento que se está describiendo.
Nota
Esta clase de notas brindan información relacionada o adicional al procedimiento
que se está describiendo.
Nota
Esta clase de notas brindan información sobre precauciones que debe tomar el
lector/alumno respecto al procedimiento que se está describiendo.
-4-
Capítulo 1 - Particionamiento Avanzado
Introducción
A esta altura, ya deberíamos conocer como particionar un disco de manera adecuada para una estación de trabajo. También
deberíamos estar familiarizados con el FHS (Filesystem Hierarchy Standard-Estructura Estándar de Sistema de Archivos) que
nos cuenta un poco que hay en cada uno de los directorios en un sistema Unix y que incluye un apartado para los sistemas
Linux.
Lo que vamos a ver en este capítulo es cómo particionar un equipo para un servidor y como poner en marcha LVM (Logical
Volume Management-Administración de Volúmenes Lógicos) en nuestros equipos con algunos ejemplos concretos de su
administración.
LVM – Logical Volume Management

Antes de empezar a configurar un sistema con LVM vamos a ver cómo funciona, luego vamos a poder poner en marcha lo
aprendido.
Usualmente, uno se introduce en el mundo de la informática usando computadoras en plataformas PC en lugar de servidores y
estaciones de trabajo comerciales basadas en sistemas Unix comerciales como HP-UX. En una PC, siempre tenemos que lidiar
con el particionamiento de los discos.
Uno suele estar acostumbrado a herramientas como el fdisk para crear y borrar particiones primarias, extendidas y lógicas en
discos rígidos. Este proceso suele ser tedioso dado que para hacerlo bien, hay que anticipar cuánto espacio disponible vamos a
necesitar para cada partición.
Si cometemos un error, probablemente hasta tengamos que realizar un backup completo de nuestro sistema, redimensionar las
particiones y luego restaurar el backup sobre el nuevo esquema de particiones. Un buen administrador, tiene que saber como
particionar el disco en función del uso que se le va a dar al sistema.
Por suerte hay varias aplicaciones como el conocido Partition Magic para redimensionar particiones. Este tipo de herramientas
crean un disco de arranque y dinámicamente cambian el tamaño de las particiones y de los sistemas de archivos. Una
característica notoria es que luego de hacer los cambios en las particiones, es necesario reiniciar la PC/Servidor. Estas
herramientas suelen ayudarnos con problemas menores para la administración de espacio en disco. Pero, ¿Son perfectas? No
exactamente.
Herramientas como el Partition Magic son excelentes para workstations, pero no son ideales para servidores. Por varios
motivos, primero que nada necesitamos reiniciar el equipo y esto es justamente algo que la mayoría de los administradores de
un sistema se niegan a hacer. ¿Qué pasa si tenemos que reiniciar el equipo cada vez que nos quedamos sin espacio en alguna
partición? ¿Qué pasa si semanalmente tenemos que redimensionar particiones? ¿Qué pasa si necesitamos expandir un sistema
de archivos a más de una unidad de disco o si necesitamos expandir o achicar el volumen de disco que usa el Apache para
servir páginas web pero continuar dando servicio?
Para situaciones de alta disponibilidad y ambientes dinámicos una herramienta como el Partition Magic no nos sería útil. Para
ésta y otras situaciones LVM es la solución perfecta.
¿Cómo LVM nos soluciona los problemas?

Logical Volume Management viene incorporado nativamente al kernel y miles de personas lo usan, tiene más de 10 años de
desarrollo siendo un sistema totalmente probado y estable. En la actualidad hay dos versiones, la 1.08 que es la estable y una
versión 2 que todavía no está lista para equipos productivos. Aparte de permitirnos hacer backups rápidos utilizando los
snapshots (literalmente: fotos instantánas) de LVM, podemos aumentar la disponibilidad y la performance permitiendo agregar
y sacar dispositivos en caliente y cambiar el tamaño de uso de cada Logical Volume. Con estas herramientas permite a cualquier
-5-
administrador dar de baja un disco defectuoso para evitar problemas o reorganizar la carga de datos en discos adaptándose a
cualquier redimensionamiento necesario.
El siguiente diagrama nos muestra un panorama general de cómo funciona LVM como para entenderlo un poco más.
PV (Physical Volume-Volúmen Físico):

hda1 hdc1
Pueden ser discos rígidos individuales o cualquier
dispositivo que desde el punto de vista del SO se
vea como un disco.
VG (Volume Group-Grupo de Volúmenes):

diskvg
Contienen la información que engloba los
Volúmenes Físicos
LV (Logical Volume-Volúmen Lógico):

usrlv varlv
En sistemas que no soportan LVM, el LV es una homelv
partición más en el directorio /dev.
FS (File System-Sistema de Archivos):

jfs xfs
Es el formato que se establecerá a cada LV para ext3
que se puedan almacenar archivos en él.
Configurando, Compilando e Instalando

Para tener funcionando LVM completo, necesitamos soporte en el kernel y las herramientas. No necesitamos emparchar el
kernel, porque por defecto viene con lo que necesitamos. Simplemente hace falta levantar el entorno de compilación del kernel
preferido.
cd /usr/src/linux
make menuconfig
Las opciones de LVM se encuentran debajo de "Multi-device support (RAID and LVM)".
Una vez que hayan activado esa opción se puede elegir:
[*] Multiple devices driver support (RAID and LVM)

<*> Logical volume manager (LVM) support
Luego sólo nos queda compilar el kernel como vimos en capítulos anteriores.
Para instalar las herramientas, con el apt-get es muy simple:
apt-get install lvm10
Una vez instaladas las aplicaciones, tendremos las herramientas listas y un servicio nuevo en /etc/init.d/.
-6-
Conceptos y Comandos de Referencia
Aquí hacemos una referencia de los comandos básicos de LVM. Están ordenados de manera similar a los de HP-UX. Donde
los comandos que tienen que ver con physical volume comienzan con pv, los que tienen que ver con volume group comienzan
con vg y los que tienen que ver con logical volume comienzan con lv.
pvcreate crea un PV
pvchange cambia los atributos de un PV
pvdisplay muestra información de la configuración de un PV
pvmove mueve datos a un PV diferente
pvscan busca todos los PVs
vgcreate crea un VG a partir de un PV

vgchange activa y desactiva VGs
vgdisplay muestra información de la configuración de un VG
vgextend agrega un PV a un VG
vgreduce remueve un PV de un VG
vgremove remueve un VG
vgrename renombra un VG inactivo
vgscan busca todos los VGs
lvcreate crea un LV
lvchange cambia los atributos de un LV
lvdisplay muestra información de la configuración de un LV
lvextend extiende el tamaño de un LV
lvreduce reduce el tamaño de un LV
lvremove remueve un LV
lvrename renombra un LV
lvscan busca todos los LVs
lvmchange cambia atributos de un LVM

lvmdiskscan escanea todos los discos / particiones y los lista
lvmsadc recolector de información estadística
lvmsar generador de reportes de datos estadísticos
¿Cómo se crea un Physical Volume?

Para crear una unidad lógica (LV) hay que seguir tres pasos. Primero que nada es necesaria una partición física (PV) que puede
ser una de las que ya conocemos o una partición de un RAID. En la terminología LVM estas unidades son llamadas volúmenes
físicos (physical volumes). Entonces el primer paso es inicializar estos physical volumes para que sean reconocidos por el
sistema LVM, esto involucra cambiar el tipo de partición a 8E con el fdisk clásico o con el más sencillo cfdisk. Luego,
utilizamos el primero de los comandos de LVM:
pvcreate /dev/hdc1
Esto crea un volúmen físico en la primera partición del disco master del IDE secundario.
-7-
Nota
Si nuestro equipo está utilizando para ordenar el /dev el sistema devfsd hace
falta utilizar el path completo al dispositivo y no el link simbólico /dev/hdc1.
De lo contrario no va a funcionar correctamente. Para comprobar si se está
utilizando o no devfsd simplemente buscar el proceso en el sistema o verificar si
el kernel lo soporta haciendo:
cat /proc/filesystems
¿Cómo se crea un Volume Group?

Luego de haber definido un dispositivo físico como usable por el LVM, el siguiente paso es crear un Volume Group sobre el o
los dispositivos físicos. Para esto existe el comando vgcreate.
Si tenemos un sólo dispositivo físico:
vgcreate vg00 /dev/hdc1
Si tenemos dos o más dispositivos físicos:

vgcreate vg00 /dev/hdc1 /dev/hdd1
Nota
Si se está usando devfsd para organizar el /dev es necesario usar los path reales
a los dispositivos y no el link simbólico como en el ejemplo anterior. En el primer
ejemplo, lo correcto sería:
vgcreate vg00 /dev/ide/host1/bus0/target0/lun0/part1
¿Cómo se crea un Logical Volume dentro de un Volume Group?

Ya existe un Physical Volume creado y un Volume Group definido. Ahora se cumplen las condiciones para crear un Logical
Volume dentro del Volume Group creado anteriormente.
lvcreate –L tamaño –n nombre vg00
Donde tamaño hay que reemplazarlo por el tamaño que deseamos crear el LV. Puede estar expresado en Megabytes o
Gigabytes agregando una M o G según corresponda. A su vez nombre hace referencia al nombre que llevará el Logical Volume
a crear. Es el nombre que va a tener el archivo en /dev/vg00/ y con el cual podremos asociarlo a la hora de montar la
partición que contenga. Finalmente, vg00 es el Volume Group en el cual se creará el Logical Volume.
Para ver cuánto espacio disponible queda a medida que vamos creando los Logical Volumes hay que usar el comando
vgdisplay y buscar la sentencia “Total PE”.
vgdisplay vg00 | grep “Total PE”

Total PE 23023
Este procedimiento hay que repetirlo por cada uno de los Logical Volumes que sea necesario crear. Luego de haberlos creado
todos, podemos ir al /dev/vg00 y ver todos los dispositivos que tenemos creados.
El último paso para que los Logical Volumes sean utilizables es formatearlos, para luego poder montarlos donde corresponda.
Para esto hay que tener ciertas precauciones:
• Para formatear un Logical Volume podemos usar herramientas como mkfs.ext3 ó mkfs.reiserfs según el
sistema de archivos a implementar.
-8-
• Una vez formateados todos los Logical Volumes lo ideal es poner al sistema en runlevel 1 (single user) para parar
la mayor cantidad posible de servicios y poder empezar a mudar los datos de nuestro sistema actual al nuevo
LVM.
• Sabiendo que, por ejemplo, vamos a mudar el /usr a un Logical Volume y que ya tenemos claro cuál es
(/dev/vg00/usr) podemos hacer las modificaciones necesarias en el archivo /etc/fstab para que monte el
dispositivo correspondiente en el /usr en el próximo inicio.
• Estando en single user mode (runlevel 1) podemos montar de a uno los LV en algun directorio temporal, por
ejemplo /mnt/temp, y copiar el contenido correspondiente.
Nota
Un error en este paso puede suponer la pérdida total o parcial del sistema
irreversiblemente.
Veamos un ejemplo paso a paso:
mount /dev/vg00/usr /mnt/temp Montar el LV que reemplazará al /usr en /mnt/temp

cd /usr Ubicarse en /usr
cp –avx * /mnt/temp Copiar el contenido del /usr original al /mnt/temp
ls –l /mnt/temp Verificar el contenido del /mnt/temp
rm –rf /usr/* BORRAR el contenido del /usr original
umount /mnt/temp Desmontar el /dev/vg00/usr
mount –a Comprobar la sintáxis del /etc/fstab
ls –l /usr Listar el contenido del nuevo /usr
Un ejemplo de “/etc/fstab” luego de implementar LVM

Al estar familiarizados con la nomenclatura y características de LVM, tenemos la libertad necesaria para poder “corregir”
posibles errores en el particionamiento de los discos rígidos de nuestro servidor.
Para verlo en la práctica, veremos un ejemplo medianamente complejo, pero entendible:
Un servidor con un disco de 80Gb IDE. El servidor hará de proxy usando el Squid y hará de servidor de e-mails para 200
usuarios. También tendrá instalado un servidor FTP y un servidor WWW, ambos configurados pero deshabilitados, por si en
un futuro se realiza hosting de websites. En el /home de los usuarios cada uno recibe sus e-mails, pero no tiene acceso al
equipo por consola. El archivo /etc/fstab se ve como el siguiente:
/dev/hda1 / ext3 defaults,errors=remount,ro

/dev/hda2 /boot ext3 defaults,noauto
/dev/vg00/usr /usr ext3 defaults,ro
/dev/vg00/var /var ext3 defaults
/dev/vg00/home /home ext3 defaults,usrquota,grpquota
/dev/vg00/swap none swap sw
/dev/vg00/tmp /tmp ext3 defaults,usrquota,grpquota,nosuid
/dev/vg00/srv /srv ext3 defaults,usrquota,grpquota,nosuid
/dev/vg00/squid /var/spool/squid reiserfs defaults,noatime,nolog
Vamos a explicar por cada renglón las decisiones tomadas para llegar al esquema planteado:
/ No se agrego la raíz del disco el LVM por las dudas. Si el sistema tiene algún problema,
cualquier kernel va a tener soporte para ext3 pero no todos para LVM. El tamaño definido
es de 2Gb.
/boot Idem para el /, pero con la opción noauto no se automonta la partición al inicio del equipo.
No hace falta, dado que no vamos a cambiar el kernel seguido. Sólo se utilizaron 35Mb.
-9-
/usr Es la primera partición en el LVM, de acá en adelante, todas van a estar en LVM. Se la
monta como ro (read-only), dado que luego de configurado el sistema, a menos que sea
necesaria una actualización, no va a hacer falta escribir en esta partición. Utilizando solo el
30% de la partición, se reservaron 5Gb para su destino.
/var Se incluyó la partición en el Volume Group vg00 sin ninguna modificación a la hora de ser
montada. Con otros 5Gb tiene que ser suficiente.
/home Con soporte de quotas para usuarios y grupos. Aquí se alojarán los mails de los usuarios, si
hay 200 usuarios, a 150Mb por usuario, configurando 8Gb para estar holgados.
swap 1Gb para swap. Suficiente con un 1Gb de RAM. De hacer falta, se puede crear otra swap
más, preferentemente en otro disco rígido ó agregar más RAM por el Squid.
/tmp Nadie debería necesitar ésta partición dado que los usuarios no se loguean al sistema. Pero
cómo medida de seguridad es necesario limitar el espacio para que no crezca
indefinidamente y llene el directorio raíz. 500Mb tiene que ser más que suficiente.
/srv De ser necesario en un futuro montar un servidor WWW o FTP, ya se deja este directorio
listo para comenzar a trabajar. Reservar 4Gb por si en algún momento se decide poner en
marcha el sitio.
/var/spool/squid Acá sólo existirá cache en disco. Por eso se utilizó reiserfs como sistema de archivos. El
reiserfs es ideal para un proxy. Se optó por nolog, para no usar el Journaling del
sistema de archivos y por el noatime, para no actualizar la fecha de modificación de los
archivos. Es de suponen cierto aumento de performance usar esas opciones a la hora de
montar un sistema reiserfs. Se dejaron 20Gb para la partición.
Aunque haya quedado espacio libre en el disco para repartir entre las particiones. No es necesario utilizarlo inmediatamente en
la distribución de particiones, es preferible dejarlo libre para utilizarlo según necesidad futura de las particiones.
Ejemplos prácticos de la administración de un LVM

Agregando Physical Volumes a un Volume Group.
Para agregar una unidad física nueva ya inicializada hay que usar el comando vgextend:
vgextend vg00 /dev/hdc1
Removiendo Physical Volumes (discos) de un Volume Group

Antes de sacar una unidad física, necesitamos comprobar que no esté siendo usada. Para eso utilizaremos el comando
pvdisplay.
pvdisplay /dev/hdc1
Si el dispositivo esta en uso, es necesario mudar los datos a otra unidad antes de poder removerlo. Para eso existe el comando
pvmove.
pvmove /dev/hdc1 /dev/hdd1

pvmove -- moving physical extents in active volume group "dev"
pvmove -- WARNING: moving of active logical volumes may cause data loss!
pvmove -- do you want to continue? [y/n] y
pvmove -- 249 extents of physical volume "/dev/hdb" successfully moved
Nota
El comando pvmove es extremadamente lento.
Podemos agregarle verbose con -v.
- 10 -
Nota
Sino tenemos espacio donde pasar los datos del disco físico que vamos a quitar
del sistema, es necesario agregar un disco previamente. Para esto, debe
inicializarse con el comando pvcreate. Luego expandir el Volume Group con
vgextend y finalmente, con el comando pvmove mover los datos de un disco a
otro.
Una vez que los datos ya no están en el disco físico, los desasociamos del Volume Group con vgreduce.
vgreduce vg00 /dev/hdd1
Remover un Logical Volume

Para esto, previamente es necesario desmontar el Logical Volume.
lvremove /dev/vg00/usr
Nota
Una vez ejecutado y completado el comando lvremove, se perderán TODOS los
datos contenidos en él.
Reduciendo y aumentando el tamaño de un Logical Volume

A un Logical Volume se le puede aumentar el tamaño como disminuir el tamaño.
Nota
Lo importante antes de hacer esta tarea es tener presente que se debe aplicar el
cambio en el sistema de archivos ANTES de hacerlo en el Logical Volume.
Según el sistema de archivos, que este contenido en el Logical Volume, existen varias opciones:
ext2/ext3 Previamente hay que desmontar la partición. Usar la herramienta e2fsadm de la siguiente
manera: e2fsadm –L-1G /dev/vg00/home. Habiendo terminado el e2fsadm podemos
hacer un lvreduce –L-1G /dev/vg00/home y luego montar la partición.
reiserfs Nuevamente, lo ideal es desmontar la partición y luego reducir el sistema de archivos con el
siguiente comando: resize_reiserfs –s-1G /dev/vg00/home. Luego reducir el
Logical Volume con: lvreduce –L-1G /dev/vg00/home y finalmente volver a montar
la partición.
xfs Para este sistema de archivos no hay posibilidad de achicar una partición.
jfs Idem xfs.
Realizando backups al vuelo con snapshots

Una característica que viene con LVM es la posibilidad de sacar snapshots (literalmente: fotos instantánas) del sistema para
tener un backup en caliente de nuestro equipo. Este tipo de volúmenes son una copia read-only de otro volúmen que contiene
todos los datos previa a la creación del snapshot. De esta forma, es posible realizar un backup del servidor sin necesidad de
suspender los servicios que está brindando, por ej: un RDBMS).
Crear el Snapshot
Utilizando el comando vgdisplay determinamos cuánto espacio disponible existe en el Volume Group. El snapshot puede ser
tan grande como sea necesario, el espacio que le asignemos sólo se va a usar para guardar los cambios que pueda haber en el
volumen original durante el backup.
- 11 -
lvcreate -L592M -s -n dbbackup /dev/vg00/databases
Nota
Si el snapshot se llena, se convierte en inusable así que es fundamental terminar
antes de que se use todo el espacio disponible.
Montar el Snapshot
Ahora es necesario crear un punto de montaje y montar el snapshot:
mkdir /mnt/ops/dbbackup
mount /dev/vg00/dbbackup /mnt/ops/dbbackup
Realizar el Backup
No es la mejor estrategia para realizar backups, pero como ejemplo…
tar -cf /dev/rmt0 /mnt/ops/dbbackup
Remover el Snapshot
Cuando el backup termina, se puede desmontar el volumen y removerlo del equipo.
umount /mnt/ops/dbbackup
lvremove /dev/vg00/dbbackup
Conclusión
Utilizar LVM provee una flexibilidad total a la hora de administrar el espacio en disco. Simplifica el trabajo de cálculo para
particionamiento (se puede considerar que nos da margen de error a la hora de particionar el disco). Se convierte en una
herramienta indispensable para la administración de los datos almacenados en un servidor corporativo donde hay que cambiar
al vuelo el porcentaje de uso de los volúmenes de datos.
Más Información
http://www.sistina.com La página oficial del proyecto LVM tiene mucha información
relacionada al desarrollo y documentación para el usuario.
http://evms.sourceforge.net El sitio de EVMS, un proyecto paralelo a LVM totalmente

compatible que trae varias funcionalidades extras. Tiene GUIs
para la administración de un LVM y entornos de managment
amigables similares a un Partition Magic.
- 12 -
Capítulo 2 – Monitoreo del Sistema
Introducción
Una de las posibilidades que existen para detectar problemas en un sistema operativo es a través de las trazas o logs que
generan las distintas aplicaciones que en él se ejecutan, incluyendo el propio kernel. Una traza no es más que un mensaje breve
que normalmente va acompañado de la fecha y la hora en que se produce, el nombre de la máquina donde se produce y el
programa que la origina. Las trazas se pueden clasificar de acuerdo a su importancia. Algunas son puramente informativas
como pueden ser aquellas que avisan que un servicio inició; mientras que otras, pueden indicar una emergencia grave, como
puede ser un fallo físico en algún dispositivo.
Los demonios syslog y klogd

En Linux el programa que implementa el servicio de logs se llama syslog. Este es un producto portado para varias
plataformas Unix. En el caso de Linux funciona a través de un par de daemons nombrados syslogd, que se encarga de las
trazas generales y klogd, que manipula las trazas del kernel. El servicio permite almacenar las trazas en ficheros (agrupados
en el directorio /var/log), mostrarlas a través de una terminal o enviarlas a otra máquina donde se ejecute syslogd en modo
servidor, entre otras posibilidades.
Breve ejemplo explicativo

Se puede controlar el estado del servicio syslog con ejecutar /etc/init.d/sysklogd. El único archivo de configuración se
ubica en /etc/syslog.conf y la rotación de logs se realiza desde un trabajo programado en el cron en
/etc/cron.daily/sysklogd.
Nota
Para más información, existe la manpage del sysklogd y del syslog.conf.
Nota
Para los que están familiarizados con los productos Microsoft, en el /var/log
encontrarán algo parecido al visor de sucesos de Windows. En este directorio
residen los logs analizables con cualquier editor de texto.
El siguiente es un ejemplo válido de uno de estos archivos:
Mar 4 00:00:00 srvlx /USR/SBIN/CRON[1286]: (root) CMD ( ... )

Mar 5 17:25:57 srvlx pam_rhosts_auth[2285]: allowed to user1@srvlx as user1
Mar 5 17:26:36 srvlx su: (to root) user1 on /dev/pts/0
Mar 6 14:09:15 srvlx kernel: eth0: Transmit error, Tx status register 82.
En el log que estamos viendo, podemos notar que el día 4 de Marzo a las 00:00Hs se ejecutó el cron del usuario root. Luego
el día siguiente a las 17:25 el usuario user1 se logueó al equipo vía rlogin desde el equipo srvlx y minutos después hizo un
su a root. Finalmente, el día 6 se registra un error menor de transmisión.
Todos estos mensajes, comienzan con una fecha y hora, seguidos por el equipo y la facilidad del sistema que está generando ese
mensaje (opcionalmente puede tener un número de PID entre corchetes), y finalmente el mensaje de texto de la traza.
Facilidades y niveles de seguridad:

Para mantener un orden, los logs pueden ser divididos en facilidades, las facilidades permiten, desde la configuración, definir
un archivo de log individual para cada tipo de mensaje. De esta forma, tenemos los logs de un spool de impresora en un archivo
- 13 -
diferente de todos los mensajes que tengan que ver con el sistema de mails. Cuando exista la necesidad de analizar los logs,
tenerlos en diferentes archivos en función del contenido va a simplificar la tarea.
Facilidad Subsistema Asociado

authpriv Autenticación de usuarios.
cron Trabajos del cron.
daemon Servidores del sistema.
kern Kernel.
lpr Spool de impresoras.
mail Subsistema e-mail.
news Subsistema news.
local (desde 0 a 7) Facilidades personalizadas.
El syslog maneja varios niveles de seguridad de forma tal de poder clasificar los logs según la prioridad del mensaje. Los
niveles de seguridad son (desde el menos al más crítico): debug, info, notice, warning, err, crit, alert y emerg. Hay
que tener presente que no todos los subsistemas usan todos los niveles de seguridad; es decir, no todas las aplicaciones tienen
mensajes disponibles o diferentes para todos los niveles de seguridad. Si no estamos interesados en tener un log basado en el
nivel de seguridad, podemos usar el nivel none, que justamente esta definido para eso.
Las entradas en el archivo de configuración del syslog determinan cómo son registrados los mensajes de cada facilidad en sus
distintos niveles de seguridad. El formato usual es:
facility.level destination
Donde el primer campo especifica la facilidad y/o los niveles de seguridad que se aplican y el segundo campo determina el
destino donde los mensajes deben ser enviados o almacenados. Como destino pueden ser utilizados: archivos, dispositivos,
equipos remotos y usuarios. Para las facilidades como para los niveles de seguridad pueden ser utilizados los asteriscos como
wildcards.
Un ejemplo concreto es usar una facilidad y un nivel de seguridad separado por un punto, por ejemplo: cron.err. Usando este
formato se indica que se desean registrar todos los mensajes que sean de una prioridad igual o mayor a err que se apliquen a
la facilidad cron.
Por otro lado, el syslog de Linux trae como novedad la posibilidad de ajustar la sintaxis usando “.=” y de esta forma
especificar un nivel exacto de seguridad, en lugar de un rango desde el elegido hasta el más alto. En adición, el ¨.!” puede
preceder a un nivel de seguridad y de esta forma usarlo como inverso para seleccionar a todos los niveles de seguridad, menos
el elegido y superiores. La diferencia con el “.!=” es que en este caso se eligen a todos los niveles de seguridad menos al
elegido. A continuación algunos ejemplos para dejar claro el concepto:
cron.warn mensajes de cron, con prioridad warn o superior

cron.=warn mensajes de cron, sólo con prioridad warn
cron.!warn mensajes de cron, de prioridad menor a un nivel warn
cron.!=warn mensajes de cron, en cualquier nivel de prioridad que no sea warn
¿Dónde registrar los logs?

El destino de los logs puede ser definido en varios formatos entre alguno de los siguientes ejemplos para definir dónde van a ser
registrados/almacenados:
Destino Características Ejemplo

Archivo Todos los mensajes son escritos en un archivo cron.warn /var/log/cron.warn
de texto plano definido con el path absoluto al
mismo.
- 14 -
Dispositivo Usualmente se utiliza una terminal para este kernel.err /dev/tty8
tipo de destino, como por ejemplo alguna que
esté sin uso.
Lista de usuarios Separados por comas, se pueden definir daemon.err proxyadmin,ftpadmin
usuarios que si estan logueados en el sistema
van a recibir el mensaje con el comando
write. Si utilizamos un asterisco el mensaje
se enviará a todos los usuarios como si
ejecutaramos un write all.
Equipo remoto Precedido por un @ todos los mensajes del authpriv.* @server_de_log
syslog que correspondan son enviados vía
red al equipo elegido para ser logueados.
Para ver un poco a nivel práctico lo mencionado anteriormente, veremos algunos ejemplos puntuales.
kern.=warn;*.err;authpriv.none /dev/console
Todos los mensajes del kernel de nivel warn y los mensajes de error de todos los subsistemas menos todos los
mensajes del subsistema authpriv van a ser logueados en la consola.
lpr.debug -/var/log/lpd.err
Todos los mensajes del subsistema de spool van a ser registrados asincrónicamente en el archivo
/var/log/lpd.err. Registrar de manera asincrónica supone una mejora en la performance pero no garantiza la
pérdida de datos que no hayan sido escritos en el momento de una caída del sistema.
*.emerg root
Todos los mensajes de emergencia van a ser enviados a través del comando write al usuario root del equipo.
*.err;daemon,authpriv.notice;mail.none /var/log/messages
Todos los mensajes de error de todas las facilidades; las facilidades daemon y authpriv seran registradas con nivel
notice ó superior y la facilidad mail no será registrada.
¿Cómo configurar un servidor de logs?

El último de los posibles destinos, requiere de una explicación adicional. Es el que comienza con un @ y es utilizado cuando es
necesario enviar los logs a un equipo remoto, un servidor de logs, en lugar de tener que revisar localmente todos y cada uno de
los equipos que se administran. A nivel de equipo cliente sólo hay que definir a que equipo server enviará todo, localmente lo
ideal seria sólo guardar la información crítica del equipo. En contraste a esto, la configuración en el servidor de logs va a ser
mucho más elaborada. A continuación mostramos como sería la configuración de un cliente y luego la de un servidor.
Configuración en el equipo “cliente”

Para el caso del cliente, con hacer modificaciones como mostramos en el siguiente ejemplo:
# Registra los logs mas importantes localmente en la consola y en un archivo.

kern.warn /dev/console
*.err;kern.warn /var/log/messages
# Avisa a los que estan logueados de las emergencias.

*.emerg *
# Envia todo, menos los logs de mails, al servidor de logs

*.info;mail.none @syslog_srv
Luego de hacer esta modificación sólo hay que reiniciar el syslogd.
- 15 -
Configuración en el equipo “servidor”
En un servidor de logs hay que configurar al syslogd para que escuche peticiones remotas. Para esto, hace falta editar el
script de arranque en /etc/init.d/sysklogd y modificar una variable. En el siguiente ejemplo mostramos la modificación:
# Options for start/restart the daemons

# For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD="-r"
Como explica el mismo archivo, con sólo modificar la variable syslogd y agregarle el –r para luego reiniciar el servicio de
syslogd comenzamos a tener listo el servidor de logs. El syslog ahora actúa como servidor. Es necesaria una configuración
acorde, el siguiente ejemplo del archivo /etc/syslog.conf muestra cómo sería un prototipo de configuración:
# Mostrar mensajes criticos

*.emerg;kern.warn;user.none *
# Separar los mensajes por subsistema

kern.* /var/log/kernel.log
mail.* /var/log/maillog
local7.* /var/log/boot.log
# Los errores de lpd son bastante raros, pero igualmente los logueamos
lpr.* /var/log/lpd.errs
# Tenemos un archivo particular para los su

auth,authpriv.=notice /var/log/sulog
# El log principal del equipo

*.info;mail,news,lpr,authpriv,auth.none /var/log/messages
Como se puede ver en los ejemplos, configurar un syslog efectivo requiere un conocimiento de las facilidades y los diferentes
niveles de seguridad que produce nuestro equipo. Hay que obtener conocimiento y experiencia para familiarizarse con los
contenidos típicos de un sistema de logs y así poder realizar una configuración adecuada para cumplir con los requerimientos
necesarios.
Iniciando el syslogd
Así como el archivo de configuración puede que no tenga lo es necesario, puede suceder que el script de arranque del syslogd
también sea necesario hacerle modificaciones. El syslogd inicia desde el /etc/init.d/sysklog y existen varios
parámetros que se pueden incluir a la hora de iniciar el demonio. Por ejemplo, si bien por defecto el archivo de configuración
del syslog es el /etc/syslog.conf se puede definirle uno distinto con el switch “-f” y de esta forma poder probar la nueva
configuración sin modificar la actual. Una opción que se suele incluir y que no viene por defecto es el modificador “-m”, con
esta opción se evita que el syslog avise cuando no tienen nada para decir.
Nota
La característica de marcas sirve para dejar registro que syslogd está
funcionando. Cuando no hay ningún evento para loguear, syslogd escribe un
“MARK” en los archivos de log.
¿Que pasó con el klogd?
El klogd inicia automáticamente cuando inicia el syslogd. Puede que este en un script aparte en el archivo
/etc/init.d/klogd o en el mismo script llamado /etc/init.d/sysklogd. No lo hemos mencionado antes, dado que la
información que recolecta es exclusiva del kernel y más que nada se utiliza para que los desarrolladores puedan encontrar
- 16 -
información de debug al respecto. Por defecto, toda la información que el klogd registre se la envía al syslogd. Con lo cual
no hay archivo de configuración aparte del que ya conocemos del syslogd.
Nota
Sólo hace falta tener presente que todos los logs generados por el klogd son
registrados también por el syslogd como si el klogd fuese una aplicación más.
Logger
Existe una aplicación para hacer tests de la configuración de /etc/syslog.conf. Se llama logger y se utiliza justamente
para esto, también es posible utilizarlo en un script para agregarle funcionalidades de “logueo simulado”. Su sintaxis de uso es
muy simple:
logger -p facility.level “Mensage to be sent to syslogd”
Veamos un ejemplo:
logger -p daemon.warn “Esto es una prueba”
De esta forma se genera un log de nivel warn en la facilidad daemon con el mensaje “Esto es una prueba”.
Logrotate
Una vez que el sistema esta configurado para registrar los eventos en los archivos de log, es necesario saber que el sistema lo
hará continuamente de la misma manera y sobre los mismor archivos. Es correcto suponer que, si no se hace ninguna clase de
mantenimiento sobre los archivos de log, éstos incrementarán su tamaño hasta ocupar todo el espacio disponible de la partición
en la que estén ubicados. Dependiendo del uso que tenga el servidor, algunos archivos de log crecerán más rápido que otros.
También es correcto suponer que dado un período de tiempo considerablemente largo (meses o inclusive años) se volverá
dificultoso encontrar, dentro de los archivos de log, algún evento ocurrido en el pasado.
Para poder controlar el tamaño de los archivos de log y facilitar la búsqueda dentro de ellos, es necesario implementar alguna
metodología de administración automática de dichos archivos. Este proceso es normalmente llamado “rotación”. Lo ideal, es
poder rotar estos logs en horarios y fechas determinados y en función del tamaño o fecha ver de crear uno vacío, guardando los
viejos con otro nombre para comprimirlos y tenerlos históricamente por si es necesario revisar o buscar algún evento.
Para explicar este proceso en la práctica usaremos como ejemplo el archivo /var/log/messages. Luego de unas semanas, la
rotación típica establece que se le cambiará el nombre a /var/log/messages.1 y se creará un nuevo archivo
/var/log/messages vacío. Pasadas unas semanas más, vuelve a aplicarse la rotación, pero esta vez /var/log/messages.1
será /var/log/messages.2 y /var/log/messages será /var/log/messages.1 y se volverá a crear
/var/log/messages. Con esta parte del proceso de rotación se logra dividir el log de mensajes en diferentes archivos para
facilitar la búsqueda dentro de cada uno de ellos.
Nota
Un inconveniente básico salta a la vista, si este proceso se repite suficientes
veces, la suma de todos los archivos individuales ocupa el mismo tamaño que si
existiera un único archivo /var/log/messages. En este punto es donde entra
en juego la necesidad de comprimir o remover los archivos de log “viejos”.
En Linux existe una utilidad llamada logrotate, que se ejecuta diariamente desde el cron, y que permite la rotación de los
logs almacenados en archivos. Automáticamente rota, comprime, remueve o envía por mail los logs dependiendo de su
configuración. Esto se puede realizar diariamente, semanalmente, mensualmente o cuando un archivo de log llegue a un tamaño
determinado. El archivo de configuración del logrotate es el /etc/logrotate.conf. Veamos un ejemplo.
- 17 -
weekly # rotar los logs semanalmente
rotate 4 # guardar 4 rotaciones de logs
create # crear un log nuevo vacío luego de rotar los viejos
#compress # descomentar si queremos que los logs sean comprimidos
include /etc/logrotate.d # similar a /etc/xinetd.d para casos particulares
Algunas opciones permiten enviar los logs por e-mail en lugar de rotarlos. Esto se puede hacer con una línea como:
mail usted@su-empresa.com.ar
Aparte, se podrían rotar los logs cuando lleguen a un tamaño definido:
size=100k
En la línea del include se hace referencia al directorio /etc/logrotate.d/. Ahí encontrará configuraciones individuales
para ciertos servicios, como por ejemplo el squid. Veamos un ejemplo:
/var/log/squid/*.log {
daily
compress
delaycompress
rotate 2
missingok
nocreate
sharedscripts
prerotate
test ! -x /usr/sbin/sarg-maint || /usr/sbin/sarg-maint
endscript
postrotate
test ! -e /var/run/squid.pid || /usr/sbin/squid -k rotate
endscript
}
Según el archivo para el squid, los logs van a ser rotados diariamente y comprimidos. Pero se va a retrasar la compresión de
los archivos de log con el parámetro delaycompress. Se van a rotar dos veces y sino hay ninguno no se genera un alerta al
root del quipo. A su vez el sharedscripts, prerotate y postrotate configuran lo que va a ocurrir antes y después de
rotar los logs. Se sugiere revisar la configuración de los servicios que están presentes en este directorio y hagar los cambios
necesarios para ajustar todo a las necesidades específicas de la implementación que se esté haciendo.
Nota
Luego de hacer los cambios, pueden realizarse pruebas ejecutando el logrotate
manualmente de la siguiente forma:
logrotate -f /etc/logrotate.conf
En donde le decimos que ejecute la rotación de logs de inmediato y que utilice

como referencia su archivo de configuración.
- 18 -
Conclusión
Con lo visto en este capítulo es posible crear, testear y usar configuraciones especiales para los syslogs. Los logs ahora podrán
ser detallados, ordenados, completos y rotados como mejor convenga tanto para clientes como para servidores syslog.
Más Información
Existen otros proyectos para registrar logs en sistemas GNU/Linux y/o Unix. El syslog-ng es uno de ellos y entre otras
cosas, aporta como novedad la encriptación de los logs que vayan a un servidor remoto de logs. Para obtener información
detallada, visite: http://www.balabit.com/products/syslog_ng/.
- 19 -
Capítulo 3 – Comprobando la Integridad de los Archivos
Introducción
El paso natural luego de haber particionado de manera inteligente un servidor, de haber configurado un sistema completo de
logs y de haber instalado las aplicaciones que son necesarias, es el de asegurar que en un futuro, todo siga tan perfecto y seguro
como cuando se completó la instalación. Para esto, el siguiente paso sería mantener el servidor al día con las actualizaciones de
seguridad que suelen aparecer con bastante frecuencia. En segunda instancia, necesitamos tener un control exacto de qué había
cuando concluyó la instalación y que hay ahora en el equipo para tener un control de cambios. Finalmente, es necesario saber
cómo reaccionar ante una intrusión en el “perfecto y seguro” sistema.
Hay dos pasos que estamos dejando de lado, uno es instalar un firewall y el otro es diagramar un sistema de backups coherente.
En el primer caso, vamos a omitir una explicación porque ya se ha visto en capítulos anteriores cómo realizar un firewall. En el
segundo caso, daremos nociones básicas de esquemas de backup y veremos algunas sugerencias para poder obtener uno a la
medida de las necesidades.
Para cumplir con el primer enunciado, es necesario estar al día con las actualizaciones de seguridad de la distribución que
tengamos instalada. Cada distribución maneja un sistema para controlar las actualizaciones. Todas las distribuciones tienen
listas de correo relacionadas a la seguridad donde suelen publicarse las novedades diariamente para poder estar informados de
inmediato ante algún problema de seguridad conocido. No tiene mucho sentido que habamos una explicación de cómo anotarse
a una lista de correo, simplemente hay que visitar la página oficial de nuestra distribución y subscribirnos a las listas de
seguridad que sean de interés.
¿Cómo mantenernos al día con las actualizaciones de seguridad?

Para realizar esta tarea, deberíamos tener un sistema para controlar qué versiones de nuestras aplicaciones tenemos y cuáles
están disponibles. Muchas distribuciones tienen mirrors que por FTP permiten hacer un download de las actualizaciones de
seguridad de las aplicaciones que esten instaladas. Hasta existen páginas dedicadas a las actualizaciones de seguridad y es
probable que exista la posibilidad de recibir vía e-mail las novedades. Pero todo esto hace necesario el invertir tiempo para
controlar diariamente las novedades, Debian aporta un sistema de control de actualizaciones para simplificar la tarea engorrosa
de controlar las novedades.
Cuando se instala el equipo, en Debian, existe la opción de usar o no las actualizaciones de seguridad del sitio dedicado a esto.
Si el servidor ya está funcional, sin haber configurado esta característica, veremos en detalle cómo configurar el apt para que
utilice el sistema de actualizaciones.
El apt tiene su archivo de mirrors en /etc/apt/sources.list y para empezar a usar el mirror de seguridad de Debian
alcanza con agregar la siguiente línea en el archivo:
deb http://security.debian.org/ stable/updates main contrib non-free
Luego de haber editado el archivo y de haber agregado la línea correspondiente sólo queda pendiente actualizar la lista de
paquetes:
apt-get update
Finalmente, para ver que actualizaciones hay disponibles:
apt-get upgrade
Cuando éste úlimo comando finalice su ejecución, el servidor ya está “seguro”, pero ¿Qué pasa mañana? ¿Es necesario
acordarse de actualizar el sistema nuevamente? No, para esto podemos instalar el paquete cron-apt que va a ser el encargado
de actualizar nuestro sistema con los parches de seguridad con la periodicidad que le definamos. Para tenerlo funcionando
alcanza con un:
- 20 -
apt-get install cron-apt
No es necesario profundizar en la configuración del cron-apt porque es dinámica y simple de entender. Solo hay que definir
qué y cuándo se debe actualizar y el cron-apt deja un log en /var/log/cron-apt con los resultados.
¿Qué es un “rootkit”?
Para cumplir con la segunda meta, necesitamos controlar qué había al finalizar la configuración del equipo antes de estar en
producción y que hay ahora luego de haber sido expuesto. De esta forma, se puede mantener un control de cambios en el equipo
y poder verificar si hubo alguna modificación o intrusión en el sistema.
Por más seguros que estén configurados los servicios, siempre existe la posibilidad que algo quede fuera del esquema de
seguridad. Todos los días hay nuevos métodos para lograr la intrusión a un sistema. Si se da el caso que un intruso logró entrar
en el sistema, el visitante seguramente trajo consigo herramientas para instalar en el equipo. Estas herramientas suelen
reemplazar aplicaciones vitales del equipo, como el ps, ifconfig, kill, netstat, df, du, ls y de esta forma, poder ocultar
aplicaciones, ocultar procesos, registrar usuarios y passwords. En definitiva, poner en compromiso al sistema. Estás
aplicaciones llevan el nombre de rootkits y le dan al intruso herramientas para dejar al equipo vulnerable para futuros ingresos.
Suelen dejar backdoors para que ellos tengan acceso remoto con versiones modificadas del telnet o del ssh que usualmente
van a correr en puertos diferentes al que corresponde para cada uno de ellos.
Como los rootkits van a reemplazar aplicaciones básicas del equipo, no es posible seguir confiando en él. Es necesario tener un
inventario de estas aplicaciones y poder identificar los cambios que se hayan producido, como por ejemplo, calculando el
checksum de los archivos y guardar esta información en un lugar seguro. Obviamente, no el mismo equipo. Para realizar esta
tarea podríamos usar el md5sum pero existen herramientas mas completas como el AIDE.
AIDE (Advanced Intrusion Detection Environment)

AIDE (Advanced Intrusión Detection Environment-Entorno Avanzado de Detección de Intrusiones) es el reemplazo free del
Tripwire. Hace lo mismo que el semi-free Tripwire y un poco más. Para los que no conocen al Tripwire, con el AIDE se puede
tener un control, un snapshot, de los archivos controlando el estado actual de los mismos para poder compararlos a futuro y
determinar su existieron modificaciones que no correspondan. Para entrar en detalle, al mirar un archivo de configuración, se
dará una idea un poco más completa sobre sus características:
# Available Optiones
#p: permissions
#i: inode
#n: number of links
#u: user
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#S: check for growing size
#md5: md5 checksum
#sha1: sha1 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksum
#R: p+i+n+u+g+s+m+c+md5
#L: p+i+n+u+g
#E: Empty group
#>: Growing logfile p+u+g+i+n+S
#haval: haval checksum
#gost: gost checksum
- 21 -
#crc32: crc32 checksum
# Reglas personalizadas, para cada keyboard hago los siguientes chequeos.

Binlib = p+i+n+u+g+s+b+m+c+md5+sha1
ConfFiles = p+i+n+u+g+s+b+m+c+md5+sha1
Logs = p+i+n+u+g+S
Devices = p+i+n+u+g+s+b+c+md5+sha1
Databases = p+n+u+g
StaticDir = p+i+n+u+g
ManPages = p+i+n+u+g+s+b+m+c+md5+sha1
# Binarios
/bin Binlib
/sbin Binlib
/usr/bin Binlib
/usr/sbin Binlib
/usr/local/bin Binlib
/usr/local/sbin Binlib
/usr/games Binlib
# Librerías
/lib Binlib
/usr/lib Binlib
/usr/local/lib Binlib
# Archivos de Logs.
/var/log$ StaticDir
!/var/log/ksymoops
/var/log/aide/aide.log(.[0-9])?(.gz)? Databases
/var/log/aide/error.log(.[0-9])?(.gz)? Databases
/var/log/setuid.changes(.[0-9])?(.gz)? Databases
/var/log Logs
Este es un ejemplo de un archivo de configuración medianamente personalizado que revisa, según las especificaciones, en los
directorios definidos. Ahora veremos que se puede controlar los archivos en base a varios sistemas de checksum, permisos,
fechas de acceso, fechas de modificación y muchas cosas más.
Pasos a seguir para tener funcionando el AIDE

Para tener andando el AIDE es muy simple. Obtener e instalar la aplicación con el apt-get, y luego de contestar algunas
preguntas ya esta la base para editar el archivo de configuración y seleccionar qué chequear y con qué preferencias.
Luego, queda a criterio del administrador si la base de datos tiene que quedar en el mismo equipo o corresponde tenerlo en una
unidad removible como puede ser un floppy o unidad remota (P.Ej: vía NFS).
Comprobando la integridad del disco

Una vez instalado el AIDE, quedará definido un trabajo en el cron para ejecutarse diariamente. Este trabajo va a usar la base
de datos para comparar con la situación actual del sistema. Ante un alerta, AIDE avisará por e-mail a la dirección definida en el
archivo de configuración. Si durante la instalación se evitó hacer la inicialización de la base de datos de AIDE es posible
reiniciarla haciendo:
aide –init
Esto va a releer el archivo de configuración y va a aplicar los cambios en la base de datos. Esta base de datos se encuentra en
/var/lib/aide/aide.db.new y para poder comenzar a utilizarla es necesario renombrarla a aide.db.
- 22 -
Nota
Las nuevas bases de datos llevan ese nombre y las validadas no llevan el “.new”.
Si no se renombran las bases de datos, AIDE no comparará correctamente.
Si la base ya está inicializada y renombrada, ya está en condiciones de ser usada para compararla con el equipo actual
utilizando el siguiente comando:
aide -C
AIDE se encargará de chequear el sistema actual y mostrará las diferencias en cuanto al sistema que teníamos la última vez que
se realizó el chequeo.
Nota
Hay que tener mucho cuidado con los directorios que se están comprobando.
Por ejemplo: Verificar el directorio de spool de impresoras o el de los mails
siempre generará falsas alarmas en su mayoría.
Una vez que obtenemos las diferencias, es posible validarlas o no. Para validarlas, se debe actualizar la base y para esto existe
una forma:
aide –U
Sugerencias para un chequeo de integridad más seguro

Todo lo que hemos visto hasta ahora contempla que tengamos el AIDE instalado en el disco. Cualquier intruso que entre en el
equipo, se da cuenta que tenemos al AIDE monitoreando. Lo ideal, es tenerlo instalado en una unidad removible y tenerlo
disponible sólo cuando sea necesario. Repasaremos los pasos a seguir para tener AIDE instalado en un floppy y poder scanear
el sistema desde ahí:
Primero que nada, formatear un floppy.
root@srvlx:~# mkfs /dev/fd0

mke2fs 1.35 (28-Feb-2004)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
184 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
1 block group
8192 blocks per group, 8192 fragments per group
184 inodes per group
Writing inode tables: done

Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 37 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.
root@srvlx:~#
Ahora montamos el floppy y dentro de él creamos un directorio llamado “aide”. De la página del AIDE obtenemos las fuentes,
el desarrollo de la herramienta ahora esta en SourceForge. http://sourceforge.net/projects/aide.
Con las fuentes, ya podemos usar el procedimiento usual de “configure”, “make”, “make install”.
root@srvlx:/tmp/aide# tar xvfz aide-0.10.tar.gz ¡
- 23 -
aide-0.10/
aide-0.10/Makefile.in
[...]
aide-0.10/include/compare_db.h
aide-0.10/include/gnu_regex.h
root@srvlx:/tmp/aide# cd aide-0.10
Nota
Para el caso de AIDE, el procedimiento del configure tiene algunas diferencias
con el configure estandarizado para otras aplicaciones.
root@srvlx:/tmp/aide/aide-0.10# ./configure --prefix=/mnt/floppy/aide

creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/ginstall -c
[...]
creating aide.spec
creating config.h
root@srvlx:/tmp/aide/aide-0.10# make
make all-recursive
make[1]: Entering directory `/tmp/aide/aide-0.10'
[...]
make[2]: Leaving directory `/tmp/aide/aide-0.10'
root@srvlx:/tmp/aide/aide-0.10# strip src/aide
root@srvlx:/tmp/aide/aide-0.10# make install

\Making install in src
make[1]: Entering directory `/tmp/aide/aide-0.10/src'
[...]
root@srvlx:/tmp/aide/aide-0.10# cd ..
root@srvlx:/tmp/aide# cd ..
root@srvlx:/tmp# rm -r aide
Finalmente creamos una configuración simple.
root@srvlx:/tmp# cd /mnt/floppy/aide/bin/
root@srvlx:/mnt/floppy/aide/bin# cat aide.conf

database=file:/mnt/floppy/aide/bin/aide.db
database_out=file:/mnt/floppy/aide/bin/aide.db.new
/vmlinuz R
/boot R
/etc R
/bin R
/usr/bin R
/usr/local/bin R
/sbin R
/usr/sbin R
/usr/local/sbin R
=/var/log R
/tmp R
/var/tmp R
root@srvlx:/mnt/floppy/aide/bin# ./aide --config=./aide.conf --init
- 24 -
root@srvlx:/mnt/floppy/aide/bin# mv aide.db.new aide.db
Ahora, guardando este floppy en un lugar físicamente seguro, podemos controlar manualmente nuestro equipo y quedarnos un
poco tranquilos de que todo está como pensamos que debería estar.
Comprobando la seguridad con “chkrootkit”

¿No nos quedamos tranquilos? ¿El AIDE dio una alarma positiva? ¿Necesitamos más datos sobre un archivo que fue
modificado? ¿Tenemos dudas de la integridad de nuestro equipo? Bueno... es probable que estemos frente a un rootkit en
nuestro sistema. Hay muchos rootkits en la actualidad y si bien nos podemos quedar tranquilos respecto de que los virus no
afectan a los sistemas operativos *nix. Tenemos que tener alguna forma de verificar nuestro sistema en contra de los rootkits.
¿Cómo saber si el equipo ha sufrido una intrusión y tiene un “rootkit” instalado?

A continuación una serie de aclaraciónes, teniendo en cuenta que la primera aclaración es la más importante de todas:
• Es prácticamente imposible darse cuenta a menos que hagamos un chequeo.
• Frecuentemente, luego de una intrusión, no es posible conectarnos por ssh al equipo.
• Un sniffer va a correr oculto del comando ps y va a estar logueando usuarios y passwords.
• El programa y los logs del sniffer van a estar ocultos de los comandos ls y find entre otros.
• Vamos a tener ocultos varios archivos con permisos SUID.
• Muchos de nuestros comandos básicos van a estar reemplazados para ayudar al rootkit a ocultarse.
• Los logs que nos sirvan para ver cual fue el método de entrada a nuestro equipo no van a estar.
• Como resultado, el equipo va a estar en manos del intruso.
Para detectar esto entra en juego el chkrootkit.
¿Cómo utilizar el “chkrootkit”?

Instalarlo no es ningún misterio si ya manejamos el apt-get. El chkrootkit nos permite hacer varios chequeos de integridad
en nuestro sistema y detectar posibles rootkits. Cuando ejecutamos el chkrootkit sin parámetros realizar un chequeo
completo:
srvlx:~# chkrootkit
ROOTDIR is `/'
Checking àmd'... not found
Checking `basename'... not infected
Checking `biff'... not infected
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `date'... not infected
Checking `du'... not infected
Checking `dirname'... not infected
Checking ècho'... not infected
Checking ègrep'... not infected
[...]
Searching for Anonoying rootkit default files and dirs... nothing found
Searching for ZK rootkit default files and dirs... nothing found
Searching for ShKit rootkit default files and dirs... nothing found
Searching for AjaKit rootkit default files and dirs... nothing found
Searching for zaRwT rootkit default files and dirs... nothing found
Searching for anomalies in shell history files... nothing found
Checking àsp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... no infected
Checking `rexedcs'... not found
Checking `sniffer'... lo: not promisc and no packet sniffer sockets
- 25 -
eth0: PACKET SNIFFER(/sbin/dhclient3[1565])
Checking `w55808'... not infected
Checking `wted'... nothing deleted
Checking `scalper'... not infected
Checking `slapper'... not infected
Checking `z2'... nothing deleted
En el test que realizamos, genera una falsa alarma en cuanto al proceso dhclient3 que supuestamente parece ser un packet
sniffer. El dhclient es el cliente DHCP y siempre está en ese modo sniffeando al servidor. Con lo cual podemos quedarnos
tranquilos de que no es ningún rootkit.
¿Cómo verifico un disco secundario con el “chkrootkit”?

Sino estamos tranquilos de nuestro sistema, vamos a tener que sacar el disco y ponerlo en uno que este limpio y comprobar su
integridad nuevamente. Para esto el chkrootkit tiene un switch, el “-r” que verifica un directorio root que este montado en
otro lado. Es decir, si instalamos el disco supuestamente infectado como secundario del IDE primario:
mount /dev/hdb1 /mnt
Luego, pasamos el switch “-r” al chkrootkit.
chkrootkit –r /mnt
Va a realizar el mismo procedimiento, pero con nuestro sistema estable verificando otro disco.
¿Puedo ejecutar el “chkrootkit” vía “cron”?

Se puede perfectamente, en el siguiente ejemplo ejecutamos el chkrootkit a las 3AM todos los días y el resultado se lo
mandamos al usuario root del equipo.
0 3 * * * ( chkrootkit 2>&1 | mail -s "chkrootkit output" root)
Conclusión
Los rootkits son cada vez más comunes en los entornos GNU/LInux y Unix. Si bien podemos asumir una “falsa tranquilidad”
de que los virus no afectan a las plataformas *nix, tenemos que tener protegido nuestro equipo de los rootkits con herramientas
para verificar la integridad de nuestros archivos. Y tener herramientas para determinar si nuestro sistema haya sido
comprometido.
De llegar a encontrar algo raro, sera necesario instalar el sistema de cero o intentar detectar que cosas fueron cambiadas. Para
esto, podríamos usar el AIDE y según qué fue modificado reinstalar las aplicaciones según corresponda. Acto seguido verificar
la seguridad de nuestro equipo para encontrar cuál fue el método que utilizó el intruso.
Más Información
http://www.securityfocus.org Algunos sitios dedicados en materia de seguridad.
http://www.insecurity.org
http://sourceforge.net/projects/aide La página del AIDE en SourceForge.
http://www.chkrootkit.org El sitio oficial del ChkRootKit.
- 26 -
Capítulo 4 – Herramientas de Auditoría
Introducción
En Linux hay varias herramientas de auditoria, estas herramientas son utilizadas tanto por los intrusos como por los
administradores para comprobar la seguridad de sistemas que en el segundo caso, controlan. Cuando un intruso quiere ingresan
en un sistema, el primer paso es conseguir información del destino y una de las formas de conseguir esta información es
averiguar en que puertos esta escuchando el sistema que puedan ser comprometidos. Usualmente, esto se hace a través del port
scanning. Mediante el port scanning de una red o un host en particular uno puede detectar vulnerabilidades que un intruso va a
intentar utilizar para ingresar en nuestro sistema. Uno de los scanners más populares es el nmap.
El nmap es la herramienta por excelencia a la hora de hacer un port scanning. Consiguió ser considerada una herramienta
básica de diagnostico similar a la de un ping, un traceroute. El nmap es utilizada desde para ver que hosts de una red están
activos, ver que sistema operativo corre en cada equipo de una lan o auditar la seguridad de un sistema remoto comprobando
que ports tiene abierto el sistema.
Antes de comenzar a usar el nmap, vamos a ver herramientas aún más básicas para poder hacer tareas similares a las que
cumple el nmap que ya vienen instaladas en nuestro sistema.
Fuser
Sin entrar en muchos detalles y hablando muy por arriba, el fuser es una herramienta que se utiliza para ver que archivo esta
siendo utilizado por que aplicación. Vamos a dar un ejemplo concreto, tienen que desmontar un sistema de archivos y les dice
que esta siendo utilizado. Para esto, el fuser es la herramienta ideal, con él podemos revisar el directorio, el punto de montaje o
los archivos que hay en este recurso compartido para ver quién o qué los esta utilizando y simplemente cerrar esa aplicación.
Este mismo concepto se aplica a un puerto, podemos usar el fuser para ver que puertos están siendo abiertos por que aplicación
en nuestro equipo.
azrael:~# fuser 25/tcp

here: 25
25/tcp: 1546
azrael:~# ps -fea |grep 1546
root 1546 1 0 14:34 ? 00:00:00 /usr/lib/postfix/master
postfix 1549 1546 0 14:34 ? 00:00:00 pickup -l -t fifo -u -c
postfix 1550 1546 0 14:34 ? 00:00:00 qmgr -l -t fifo -u -c
root 2439 2432 0 15:53 pts/12 00:00:00 grep 1546
azrael:~#
De esta forma, vemos que en nuestro equipo el puerto 25 TCP esta abierto y si buscamos el número de pid que nos acusa el
fuser, podemos ver que el que esta abriendo este puerto es el postfix, nuestro servidor SMTP.
Netstat
Otra aplicación básica de todo sistema unix. Fundamental a la hora de comprobar el funcionamiento de un servicio. El netstat
nos da una respuesta rápida y más completa que el fuser cuando interroguemos un servicio.
azrael:~# netstat -anp |grep LISTEN | more

tcp 0 0 0.0.0.0:62209 0.0.0.0:* LISTEN 1940/wish
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
1571/xinetd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
1280/portmap
- 27 -
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
1575/ftpd: acceptin
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1555/sshd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
1546/master
Usando el netstat de esta forma podemos ver que, en la primera columna nos muestra el protocolo, en la cuarta las redes en las
que esta escuchando el servicio y el puerto que determina el servicio. En la última columna tenemos el pid asociado al puerto y
el nombre de la aplicación que veríamos con un PS.
Al igual que el fuser, el netstat es local pero nos da más datos, como las redes en las que esta escuchando el servicio.
Netcat
El netcat probablemente no lo tengamos instalado, pero luego de instalarlo vamos a tener una herramienta sencilla para hacer
algo más parecido a lo que hace el nmap. El netcat lo podemos usar para averiguar si un puerto esta abierto o no en un host
remoto o localmente. Localmente no tiene mucho valor porque podemos seguir usando un netstat o un fuser. Pero remotamente
si porque el netstat y fuser carecen de esta función.
bubu5:~# netcat -z 192.168.0.29 21

bubu5:~# echo $?
bubu5:~# 0
El resultado de esta consulta, dio que el ftp (21/tcp) estaba abierto en el host remoto 192.168.0.29. Cualquier valor distinto de 0
al interrogar al $? Hubiera dado que el port estaba cerrado.
bubu5:~# netcat -z 192.168.0.29 23

(UNKNOWN) [192.168.0.29] 23 (telnet): Connection refused
bubu5:~#
Cuando consultamos un puerto que este cerrado, o nos tira un error como el ejemplo o simplemente un “echo $?” nos va a dar
un número distinto de cero.
Nmap
Comprobando nuestra seguridad con herramientas que usaría un intruso, nos da un panorama de qué información pueden
conseguir y de esta forma intentar a segurizar nuestro sistema. El nmap lo podemos conseguir en www.insecure.org/nmap en
varios formatos e inclusive para varias plataformas. En nuestro caso, alcanza con hacer un “apt-get install nmap”. Si bien
existen front ends para realizar las tareas que cumple el nmap desde modo gráfico, como por ejemplo el nmapfe, nos vamos a
centrar en la consola.
La sintaxis del nmap es bastante simple, las opciones que acepta el nmap son diferentes tipos de escaneos que son definidos
por el parámetro –s. Un ping scan es “-sP”. Estas opciones luego son seguidas por hosts o networks que hacen de nuestro
objetivo. Utilizando el nmap como root tenemos mas opciones a la hora de ejecutarlo, porque como root podemos crear
paquetes determinados que el nmap necesita para usar las funciones avanzadas. Como usuario vamos a estar muy limitados
para usar el nmap.
En cuanto a los “targets”, el nmap es flexible, podemos definirle un host o una red entera agregándole la mascara de subred.
Por ejemplo, nmap 192.168.0.0/24 va a escanear toda una red clase C en la subnet 192.168.0.0. A su vez, podemos usar
wildcards como 192.168.0.* o 192.168.0-1,4,5-10 para scanner los hosts que nosotros queramos de esa subred.
Ping Scan: Para escanear toda una subred y ver que equipos están disponibles, podemos usar el ping scan con el switch “-sP”.
Por defecto el nmap va a enviar un icmp hecho y un tcp ack a todos los hosts a escanear. Los hosts que contesten alguno de los
dos van a ser considerados como activos por el nmap. En este ejemplo escaneamos todos los hosts de una red 192.168.0.0.
- 28 -
azrael:~# nmap -sP 192.168.0.0/24
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-11 17:04 ART

Host 192.168.0.0 seems to be a subnet broadcast address (returned 1 extra pings).
Host 192.168.0.1 appears to be up.
Host 192.168.0.255 seems to be a subnet broadcast address (returned 1 extra pings).
Nmap run completed -- 256 IP addresses (3 hosts up) scanned in 8.484 seconds
azrael:~#
Si nos encontramos con una serie de hosts que bloqueen el icmp podemos usar un “tcp ping”. Un “tcp ping” envía un ack a
todas las maquinas de una red, las que estén disponibles van a contestar con un “tcp rst”. Para usar este método hay que incluir
el “-PT”.
azrael:~# nmap -sP -PT80 192.168.0.0/24

Nmap run completed -- 256 IP addresses (3 hosts up) scanned in 6.810 seconds
azrael:~#
Cuando un potencial intruso descubre un equipo activo, el siguiente paso es hacer un port scanning. Varios port scans hay
disponibles en el nmap: TCP connect, TCP syn, stealth fin, xmas tree y null. También hayUDP scans.
TCP connect scan: Éste tipo de escaneo es detectado fácilmente, dado que el nmap abre el puerto remoto y establece una
comunicación completa. Los logs en el equipo remoto van a registrarnos fácilmente. Para realizar un tcp connect scan se usa el
“-sT”.
azrael:~# nmap -sT 192.168.0.1

Interesting ports on 192.168.0.1:
(The 1655 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
4000/tcp open remoteanything
9999/tcp open abyss
Nmap run completed -- 1 IP address (1 host up) scanned in 1.062 seconds

azrael:~#
TCP syn scan: Cuando no queremos hacer sonar todas las alarmas en el equipo remoto, el stealth scanning tiende a ser
menos ruidoso que el connect scan. Esto es porque nunca se realizar una comunicación completa con el equipo destino. Un syn
scan comienza por enviar un paquete syn que es el primero en una negociación TCP y cuando el equipo remoto reciba el
paquete va a contestar con un syn/ack como corresponde, pero en este caso el intruso no va a contestar con un ack para empezar
a hablar, sino un rst que termina la comunicación. La ventaja de este escaneo es que no se establece una comunicación completa
y muchos equipos no van a detectar este escaneo.
Para lanzar este escaneo, se usa el flag “-sS”.
azrael:~# nmap -sS 192.168.0.1
- 29 -
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
9999/tcp open abyss

azrael:~#
Aunque los TCP syn scans son mas indetectables muchos sistemas de detección de intrusos van a notarlos. Los escaneos
stealth fin, xmas tree y null son utilizados para evadir filtros de paquetes y firewalls que pueden estar escuchando paquetes syn.
Estos escaneos deberían devolver un RST por cada puerto cerrado.
Stealth fin, Xmas tree y Null: Cuando el TCP syn scan no es lo suficientemente clandestino, estos escaneos pueden
llegar a pasar inadvertidos. El concepto detrás de estos es que a los paquetes que generan enviados a todo puerto cerrado, éste
contesta que esta cerrado con un rst mientras que un puerto abierto debería ignorar el paquete que estamos enviando. Citando la
pagina del manpage del nmap “Desafortunadamente Microsoft (como es usual) decide completamente ignorar los estándares y
hacer las cosas a su forma” así que este tipo de escaneos contra una plataforma Microsoft no responde con un “drop” al paquete
enviado.
UDP scan: Si un intruso quiere aprovechar exploits en el protocolo UDP va a tener que escanear puertos UDP. Usando el “-
sU” un atacante podría determinar que puertos UDP hay abiertos. Un UDP scan es extremadamente lento, así que tengamos
paciencia a la hora de probarlo.
Stack Fingerprint: Muchos exploits están basados para ciertos sistemas operativos. Una opción común a la hora de
escanear un equipo remoto es usar el “-O” para determinar el sistema operativo remoto. Esto tiene que estar combinado con un
port scan y no un ping scan. De esta forma, sin entrar en detalles, el nmap hace un stack fingerprint para intentar determinar el
sistema operativo. Para más datos, podemos ver un artículo completo sobre el tema por el creador del nmap en
http://www.insecure.org/nmap/nmap-fingerprinting-article.html.
azrael:~# nmap -sS -O 192.168.0.1

PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
9999/tcp open abyss
Device type: general purpose
Running: Linux 2.4.X
OS details: Linux 2.4.20 - 2.4.22 w/grsecurity.org patch
Uptime 35.196 days (since Sun Mar 7 13:43:23 2004)

Luego del escaneo, el nmap descubrió que el equipo remoto es un Linux con un kernel
2.4.20-2.4.22 con el parche de seguridad grsecurity.
Opciones: Aparte de los tipos de escaneos, el nmap tiene varias opciones disponibles. Una de ellas es “-P0”. Esta opción es
muy útil cuando intentamos escasear un equipo que esta bloqueando el ping, usándola podemos igualmente escanear el equipo
remoto.
- 30 -
Otra opción muy útil es la “-v” que nos permite tener mas información acerca del equipo auditado.
Finalmente, para tener información sobre un puerto en particular, podemos usar el “-p” seguido por el número de puerto del
cual queremos averiguar mas datos.
azrael:~# nmap -v -sS -O -p 22,53,3128 192.168.0.1

Host 192.168.0.1 appears to be up ... good.
Initiating SYN Stealth Scan against 192.168.0.1 at 23:50
Adding open port 53/tcp
The SYN Stealth Scan took 0 seconds to scan 3 ports.
For OSScan assuming that port 22 is open and port 3128 is closed and neither are
firewalled
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
3128/tcp closed squid-http
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
IPID Sequence Generation: Randomized
azrael:~# nmap -v -sS -O -p 22,53,3128 192.168.0.1

Host 192.168.0.1 appears to be up ... good.
Initiating SYN Stealth Scan against 192.168.0.1 at 23:50
The SYN Stealth Scan took 0 seconds to scan 3 ports.
For OSScan assuming that port 22 is open and port 3128 is closed and neither are
firewalled
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
3128/tcp closed squid-http
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
IPID Sequence Generation: Randomized
Una aclaración final: el nmap es extremadamente agresivo en sus escaneos y algunos sistemas operativos no soportan un
escaneo con el nmap en una lan. Tengan presente también que puede ser considerado agresivo usar un nmap sin autorización.
- 31 -
Nessus
El Nessus es una herramienta diseñada para auditar un equipo y sus aplicaciones desde la red y detectar problemas de
seguridad. A su vez, nos da una explicación de cada uno de estos problemas y posibles soluciones según el sistema operativo
que hayamos analizado. En el caso puntual de Microsoft, nos daría como solución un link al parche para el bug de seguridad
que haya encontrado. En otras palabras, hace algo parecido a lo que hace la herramienta de electronic eye llamada Retina
(www.eeye.com) pero con licencia GPL.
Esta diseñado con el concepto de cliente servidor, a diferencia del Retina, con lo cual podemos instalar varios servidores de
Nessus en nuestra red y conectarnos con nuestro client Nessus y analizar nuestros equipos desde diferentes puntos de vista
según el servidor que utilicemos. Es decir, el servidor es el que hace el análisis mientras que el cliente simplemente recibe los
reportes.
Instalación
La página del Nessus es www.nessus.org y en la sección de downloads podemos encontrar lo necesario para instalarlo si
nuestra distribución no es Debian, inclusive si nuestro sistema operativo no es GNU/Linux. Instalarlo a lo Debian es posible
con el apt-get recordando que es un cliente servidor, así que tenemos que instalar el paquete del servidor (nessusd) y el paquete
del cliente (nessus) por separado.
Al finalizar la instalación, de cualquiera de las formas que la hagamos, hay una serie de pasos a seguir para poder empezar a
usar el servidor / cliente Nessus.
El cliente y el servidor se comunican por ssl, cuando finalicemos la instalación el mini wizard nos va a pedir que generemos un
certificado.
Creation of the Nessus SSL Certificate

-------------------------------------------------------------------------------
This script will now ask you the relevant information to create the SSL
certificate of Nessus. Note that this information will *NOT* be sent to anybody
(everything stays local), but anyone with the ability to connect to yourNessus daemon
will be able to retrieve this information.
CA certificate life time in days [1460]:
Acá deberíamos ingresar la vida útil del certificado. Todas las opciones que veamos entre corchetes son las opciones por default
que si le damos un enter van a ser seleccionadas sin que ingresemos nada mas. Luego de esta opción vamos a tener que
contestar varías mas relacionadas con el certificado. Datos que necesita para generar ese certificado, podemos personalizarlas o
simplemente darle un enter a todas las opciones y continuar con los valores por defecto. Al terminar el mini wizard nos va a
mostrar que fue lo que hizo y donde dejo los resultados.
Ahora nos queda pendiente generar usuarios para el cliente, el Nessusd (el servidor) no usa los usuarios del sistema, con lo cual
vamos a tener que generar usuarios exclusivos para que los clientes Nessus se puedan conectar. Para dar de alta un usuario el
comando es nessus-adduser y luego se nos van a presentar una serie de preguntas similares al adduser que ya conocemos.
Using /var/tmp as a temporary file holder
- 32 -
Add a new nessusd user
----------------------
Login : usuario_de_prueba
Authentication (pass/cert) [pass] :
Login password : prueba
User rules
----------
nessusd has a rules system which allows you to restrict the hosts that usuario_de_prueba
has the right to test. For instance, you may want him to be able to scan his own host
only.
Please see the nessus-adduser(8) man page for the rules syntax
Enter the rules for this user, and hit ctrl-D once you are done : (the user can have an
empty rules set)
Login : usuario_de_prueba
Password : prueba
DN :
Rules :
Is that ok ? (y/n) [y] y

user added.
Lo importante es que presten atención cuando les pregunte el sistema de autenticación. Tienen que ingresar si quieren validarse
por password o por certificado. Con un enter eligen la opción por defecto, password. Para dar de baja un usuario es nessus-
rmuser.
Iniciando el servicio:
Ahora estamos listos para iniciar el servicio del servidor Nessusd como root y conectarnos con el cliente desde cualquier
equipo, inclusive el mismo que tiene corriendo el servidor.
/etc/init.d/nessusd start
Cuando iniciemos el cliente vamos a tener que completar los datos necesarios, como la ip del servidor, el puerto, el usuario y el
password que vamos a usar para validarnos. Una vez terminado esto, tenemos que aceptar el certificado que nos emite el
servidor Nessusd y ya estamos listos para comenzar.
Usando el Nessus:
El nessus como cliente tiene una interfaz en la que podemos elegir los plug-ins que vamos a utilizar, las preferencias, los tipos
de escaneos y la selección de hosts o redes a escanear.
En cuanto a los “plug-ins”, la lista es larga y actualizable. Sino usamos Debian tenemos el comando nessus-update-plugins
pero como somos afortunados cada vez que haya alguna novedad en cuanto a plug-ins nos vamos a enterar con un apt-get
update. Los plug-ins son como las definiciones de viruses en un antivirus, hay que actualizarlas periódicamente para estar al día
con las novedades y poder siempre auditar todo con lo último que haya. A la hora de elegir los plug-ins que vamos a usar para
nuestro escaneo, tengamos presente que por defecto solo va a elegir aquellos que no sean agresivos para los hosts destinos, así
que si queremos usarlos todos explícitamente vamos a tener que pedirlo con las implicaciones que eso lleva.
Con respecto a las “preferencias”, el Nessus se vale de otros programas como el que ya vimos nmap para realizar algunos de
los testeos. En esta sección vamos a poder configurar los tipos de escaneo que hará el nmap y sus amigos desde el Nessus.
Ahora si queremos refinar el escaneo ya vamos a tener que entrar en la sección de “scan options” y seleccionar opciones para
definir la performance del test, prestar atención a la opción de “designate hosts by their mac address” si estamos en una lan
- 33 -
con DHCP y desactivar la opción de “optimize the test” y “safe checks” cuando estamos muy seguros de que queremos
realmente estresar los equipos que revisemos.
Finalmente, cuando tengamos que elegir los hosts a escanear podemos usar el sistema que ya conocemos del nmap. Así que ya
saben, hosts, series de hosts, redes, nombres de equipos, etc.
Una vez que tengamos todo a nuestro gusto, comencemos a usarlo. Pero con paciencia dado que los tests suelen llevar su
tiempo, sobre todo si estamos revisando un equipo en internet. Tengan nuevamente presente que estos escaneos van a ser
considerados agresivos para el equipo remoto y no van a ser bien vistos por el administrador de una red. Pidan autorización.
John The Ripper:
Hasta ahora venimos viendo aplicaciones para hacer auditorias remotas de equipos, ahora vamos a ver una que localmente va a
revisar los passwords definidos en nuestro sistema para controlar que no sean extremadamente simples. Para esto, el John The
Ripper es la ayuda ideal. Es un password cracker por fuerza bruta con la posibilidad de usar un diccionario de palabras. El John
The Ripper va a probar con un diccionario definido de palabras comunes utilizadas para un password o puede usar fuerza bruta
probando según el mapa de caracteres y la cantidad de caracteres que le definamos. Puede trabajar con varios procesadores,
guardar el trabajo en la mitad y continuar luego, definirle el uso del procesador entre otras muchas opciones que hacen al John
The Ripper la aplicación justa para verificar el nivel de complejidad que se utilizo para generar un password y de esta forma,
alertar a nuestros usuarios de la simplicidad de sus passwords para que los mismos corrijan el error antes de que pase a
mayores.
Para esto, necesitamos primero que nada instalar el John The Ripper. En Debian el paquete se llama simplemente “john” y su
página en internet es http://www.openwall.com/john/ donde vamos a poder conseguir las fuentes y más diccionarios de palabras
comunes.
Luego de instalado, lo primero que necesitamos es tener un archivo donde estén los passwords a controlar. Para esto, existe una
aplicación llamada unshadow que combina el /etc/passwd y /etc/shadow para que el john pueda interpretar los archivos y
analizarlos.
unshadow /etc/passwd /etc/shadow > passwd.1
Ahora tendríamos que editar el archivo y remover los usuarios del sistema operativo y dejar solamente los usuarios reales para
acotar la búsqueda y tener más orden.
Para iniciar el testeo, usando el diccionario y luego por fuerza bruta en modo incremental alcanza con hacer un:
john passwd.1
Si lo que queremos es ir viendo cuales passwords recolecto podemos analizar el archivo john.pot con el comando
john -show passwd.1
Por otro lado, podemos usar mas de un password para revisar, simplemente haciendo algo como
De esta forma, vamos a revisar más de un passwd que tengamos en el directorio en cuestión.
John passwd*
Ahora es un buen momento para refrescar el uso del nice y usarlo de la siguiente forma:
Nice -20 john passwd.1
El modo mas poderoso del John The Ripper es el incremental, para utilizar solo este tipo crackeo tenemos que usar el switch “-
i” que va a ser configurable desde el archivo john.ini.
- 34 -
John –i passwd.1
El archivo de configuración en /etc/john.ini tiene definidos parámetos para un crackeo incremental.
# Incremental modes
[Incremental:All]
File = /usr/share/john/all.chr
MinLen = 6
MaxLen = 8
CharCount = 95
[Incremental:Alpha]
File = /usr/share/john/alpha.chr
MinLen = 8
MaxLen = 8
CharCount = 26
[Incremental:Digits]
File = /usr/share/john/digits.chr
MinLen = 1
MaxLen = 8
CharCount = 10
Podríamos redefinirlo para optimizar nuestra búsqueda según corresponda. Viendo el archivo de configuración notamos que
podemos usar solo números o sólo letras y para esto existe el switch “-i:alpha” o “-i:digits”
También existe la posibilidad de que tengamos una idea de que letras o números fueron usados para los passwords y queramos
acotar la búsqueda para estos. Para eso, debemos crear un archivo similar a los del ejemplo previo e ingresar solo los caracteres
que queramos usar, acto seguido definirlo en el john.ini y luego usarlo como método.
john -makechars:personalizados.chr passwd.1
Para finalizar, luego de instalar el John, automáticamente se nos crea una entrada en el cron que va a revisar nuestros passwords
periódicamente para controlar la debilidad de los mismos y va a enviarles un mail a los usuarios con passwords crackeables.
Controlemos si realmente queremos que se hagan estos chequeos o no y actuemos según corresponda.
Conclusión
Hasta ahora vimos herramientas para auditar nuestros equipos y controlar nuestra seguridad. El nmap ya es una herramienta
fundamental en el análisis de una red y podemos decir que junto con el ping y el traceroute es esencial para determinar
problemas a nivel red.
El Nessus nos ofrece una aplicación de alta calidad que nos sirve para controlar nuestros equipos y revisar que no tengamos
agujeros de seguridad conocidos y de tenerlos nos ofrece soluciones y posibles parches.
A nivel local, el John The Ripper nos da una mano con la auditoria de los passwords de nuestro sistema verificando que nadie
use passwords en blanco o simples que puedan fomentar alguna intrusión en nuestro sistema.
En el próximo capitulo vamos a ver herramientas mas activas en cuanto al análisis de una red y un poco de cómo protegernos
de ellas.
- 35 -
Capítulo 5 – Virtual Private Networks
Introducción
Soluciones para armar VPNs en Linux hay muchas, el capitulo esta orientado para armar una VPN compatible nativamente con
clientes o servidores Microsoft. No obstante no vamos a profundizar en protocolos como IPSEC.
La VPN que vamos a armar es la que se usa entre un servidor de VPNs y un cliente que se conecta desde su casa para poder
acceder a su oficina como si estuviera físicamente en el lugar de trabajo. Es decir, vamos a poder acceder a todos los servidores
que no deberían estar expuestos a Internet, a todos los recursos locales de la Lan de su oficina, impresoras, recursos
compartidos, el entorno de red de la Lan de la oficina. Concretamente, a través de Internet vamos a tener una interfaz más que
va a tener una dirección de red de la Lan la cual a través de un túnel que vamos a crear va a poder acceder a la Lan remota y
obtener una dirección de red de esa Lan. La ventaja de esto, es que la persona que se conecte va a poder seguir trabajando desde
su casa, como si estuviese en su puesto de trabajo.
El modelo de VPN que vamos a presentar, es totalmente compatible con Microsoft y no hace falta instalar absolutamente nada
en los Windows para que funcionen contra nuestros clientes / servidores Linux. De hecho, el Windows no va a notar la
diferencia en conectarse a una VPN contra un servidor Linux que contra un servidor Windows.
Vamos a ver desde cero como parchar nuestro kernel para tener soporte para el protocolo de VPNs de Microsoft (mppe). Como
configurar un servidor VPN (poptop) para clientes heterogéneos. Vamos a ver cuales serían los pasos para configurar esta VPN
en un cliente Microsoft y vamos a llevarlo a la práctica con clientes Linux (pptp-linux). Para finalizar el capitulo, vamos a ver
como configurar un adsl sobre PPTP que es muy parecido a la configuración de un cliente de VPN.
Requisitos mínimos
Lamentablemente, tenemos que caer en parchar el kernel. Las redes virtuales privadas en Microsoft usa el protocolo MPPE y el
kernel vanilla no viene con soporte. Por suerte, existen parches para agregar el soporte. En Debian el paquete que trae el parche
se llama “kernel-patch-mppe” Pero, en otras distribuciones no estamos perdidos, existen sitios donde podemos bajar el parche.
Con respecto a aplicaciones, para el lado del cliente necesitamos el paquete”pptp-linux” que es el cliente pptp. Para el servidor
el paquete es el “pptpd” mas conocido como “poptop”. Para ambos casos, vamos a necesitar un ppp parchado para tener soporte
para pptp+mppe. Debian viene con el parche aplicado en el ppp, con lo cual si vamos a manejarnos con el paquete de Debian
no vamos a tener que hacer nada en este punto. Pero sino estamos en Debian vamos a tener que parchar el ppp. Mas datos al
final del capitulo en cuanto a esto.
¿Cómo parchar el kernel para tener soporte de mppe?

Bueno a esta altura tienen que tener instalado el paquete “kernel-patch-mppe” y obviamente cae de maduro que vamos a
necesitar también las fuentes del kernel. Lean la documentación del parche para ver que versiones del kernel soporta, pero no es
un parche conflictivo con lo cual no deberían tener restricciones en cuanto a versiones. En la actualidad funciona muy bien con
la versión 2.4.25 como con la ultima versión de la serie 2.6.x.
Cuando parchamos el kernel para agregarle funcionalidades usualmente hacemos uso de la aplicación “patch”. Pero el paquete
que vamos es semi auto instalable. Para parchar nuestro kernel hace falta:
1) Tener las fuentes del kernel descomprimidas.
azrael:/usr/src# tar xjvfp kernel-source-2.6.4.tar.bz2
2) Ubicarnos en el cd que generó el comando previo.
azrael:/usr/src# cd kernel-source-2.6.4
azrael:/usr/src/kernel-source-2.6.4#
- 36 -
3) Aplicar el parche.
azrael:/usr/src/kernel-source-2.6.4# ../kernel-patches/all/apply/mppe
¿Qué hicimos en el último paso? Bueno cuando instalamos nuestro parche para mppe lo que hace es generar este
directorio “/usr/src/kernel-patches/all/apply” e instalar el archivo “mppe” quien es finalmente el parche. Para aplicarlo, alcanza
con estar en el directorio de las fuentes del kernel y ejecutarlo. En este directorio vamos a encontrar todos los parches que
tengamos disponibles. Si queremos buscar mas parches, podemos usar como palabra clave “kernel-patch”. Con el “apt-cache
search kernel-patch” vamos a tener una lista importante de parches para el kernel. La ventaja/desventaja de usar Debian es que
el kernel que viene por defecto esta pelado, así que vamos a poder parcharlo a nuestro gusto con estos paquetes de manera
similar a como hicimos con el parche de MPPEpara personalizarlo.
Lo siguiente es levantar el menú de configuración del kernel. Si vamos a la sección de “Networking Support” vamos a tener
una vez activado el soporte para PPP la función “PPP MPPE compression (encryption)”. Esta función es la que necesitamos
activar, más todas las de PPP para tener una VPN sobre MPPE.
Acto seguido, compilamos el kernel y lo instalamos como ya vimos en el capitulo dedicado a la compilación del kernel.
Instalación del servidor de pptp (poptop):

El paquete que debemos instalar para tener nuestro servidor funcionando es el pptpd. Al finalizar la instalación vamos a tener
un nuevo servicio llamado “pptpd” y un archivo de configuración en /etc llamado pptp.conf.
################################################################################
#
# Sample PoPToP configuration file
#
# for PoPToP version 0.9.12
#
################################################################################
# TAG: speed
#
# Specifies the speed for the PPP daemon to talk at.
#
speed 115200
# TAG: option
#
# Specifies the location of the PPP options file.
# By default PPP looks in '/etc/ppp/options'
#
option /etc/ppp/pptpd-options
# TAG: debug
#
# Turns on (more) debugging to syslog
#
#debug
# TAG: localip
# TAG: remoteip
#
# Specifies the local and remote IP address ranges.
#
- 37 -
# You can specify single IP addresses seperated by commas or you can
# specify ranges, or both. For example:
#
# 192.168.0.234,192.168.0.245-249,192.168.0.254
#
# IMPORTANT RESTRICTIONS:
#
# 1. No spaces are permitted between commas or within addresses.
#
# 2. If you give more IP addresses than MAX_CONNECTIONS, it will
# start at the beginning of the list and go until it gets
# MAX_CONNECTIONS IPs. Others will be ignored.
#
# 3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
# you must type 234-238 if you mean this.
#
# 4. If you give a single localIP, that's ok - all local IPs will
# be set to the given one. You MUST still give at least one remote
# IP for each simultaneous client.
#
localip 192.168.0.100-120
remoteip 192.168.0.130-140
#localip 10.0.1.1
#remoteip 10.0.1.2-100
Acá podemos ver un archivo de ejemplo del poptop. La única opción fundamental para tocar es la que habla de localip y
remoteip.
Localip hace referencia a las ips que va a generar el servidor por cada cliente que se conecte. Es decir, nuestro servidor por cada
cliente que se conecte va a tener una interfaz virtual nueva con una ip asociada del rango que definamos en “localip”. Por
ejemplo, un cliente establece una conexión con nuestro servidor satisfactoriamente y como resultado tenemos la interfaz ppp0
con dirección de ip 192.168.0.100. Luego, otro cliente se conecta a nuestro equipo y nuevamente se levanta otra interfaz virtual
para atender el pedido con dirección de ip 192.168.0.101. Esto va a pasar por cada cliente que se conecte a nuestro servidor.
Del lado del cliente, el parámetro “remoteip” define las ips que vamos a tener para asignar a los equipos que se conecten. En
nuestro ejemplo previo, el primer cliente consiguió la ip 192.168.0.130 y el segundo 192.168.0.131.
Con solo realizar estos cambios, tenemos el poptop listo. Nos queda pendiente ver como validar a los usuarios.
Microsoft usa como método de validación el protocolo chap. El PPP ya tiene soporte para chap y su archivo de configuración
es /etc/ppp/chap-secrets. En este archivo es donde tenemos usuario y password de cada uno de los clientes que se pueden
conectar a nuestro equipo.
# Secrets for authentication using CHAP

# client server secret IP addresses
alumno servidorvpn alumno *
Arriba podemos ver un archivo chap-secrets de ejemplo en donde se dio de alta al usuario “alumno” con password “alumno”.
Este usuario se puede conectar a nuestro servidor “servidorvpn” en cualquier IP. Si quisiéramos asignarle una IPen concreto
del pool que definimos en el /etc/pptp.conf tendríamos que definirlo en el último campo.
Ahora, como ultimo paso, nos queda verificar el archivo de configuración para el PPP.
Este archivo se llama pptpd.options y esta en /etc/ppp.
## SAMPLE ONLY
## CHANGE TO SUIT YOUR SYSTEM
- 38 -
## turn pppd syslog debugging on
#debug
## change 'servername' to whatever you specify as your server name in chap-secrets

name servidorvpn
## change the domainname to your local domain
domain cortech.local
## these are reasonable defaults for WinXXXX clients

## for the security related settings
# The Debian pppd package now supports both MSCHAP and MPPE, so enable them
# here. Please note that the kernel support for MPPE must also be present !
auth
require-mschap
require-mschap-v2
require-mppe-128
## Fill in your addresses

ms-dns 192.168.0.1
ms-wins 192.168.0.1
## Fill in your netmask

netmask 255.255.255.0
## some defaults
nodefaultroute
proxyarp
lock
Acá definimos como primer parámetro, activar o desactivar el debug. Mientras realicemos pruebas y necesitemos comprobar el
servidor, podemos dejarlo activado. Una vez este en marcha, habría que desactivarlo para que nuestros logs no crezcan
demasiado con información que no vamos a necesitar.
El tag “name” hace referencia a las conexiones que hayamos creado en el chap-secrets. Es importante que por cada usuario que
hayamos dado de alta tenga el mismo nombre del servidor asociado.
El resto de las opciones tiene que ver con la configuración de la red Lan a la que se van a conectar los clientes, que parámetros
queremos pasarle a su configuración dado que de alguna forma estamos configurando un servidor de dhcp y necesitamos
pasarle un dominio, dns, wins y mascara para que se acomoden a nuestra red.
También vamos a encontrar que hay varios parámetros asociados a activar el MPPE en el PPP, son necesarios para que
funcione la encriptación.
Configuración del cliente

La configuración del cliente en Windows es relativamente sencilla. Para el caso de Windows XP en el panel de control,
conexiones de red tenemos la opción de crear una nueva conexión de red. Si siguen el menú van a encontrar la opción de crear
una red privada virtual y les va a pedir los datos de la conexión. Una vez completados todos los datos ya pueden conectarse y
no deberían tener problemas. Controlen los logs del Linux y agreguen debug de hacer falta.
Del lado de Linux tampoco es muy complicado, pero implica usar la consola y un editor de texto. Por un lado, necesitamos
instalar el pptp-linux que es el cliente del pptpd. Una vez instalado tenemos que crear un archivo donde podamos poner la
configuración de nuestra conexión. Un ejemplo del archivo /etc/ppp/options.pptp sería:
lock noauth nobsdcomp nodeflate
- 39 -
Con sólo ese contenido estamos listos. Ahora nos queda pendiente el usuario y password adonde nos vamos a conectar.
Nuevamente, caemos en el chap-secrets que tiene un formato similar al que ya vimos. Con una aclaración importante que antes
no tenía relevancia, en la columna donde definimos el servidor es fundamental que el servidor sea una dirección válida. Es
decir, si ponemos un hostname tenemos que poder resolver la dirección de ip de ese equipo. Sino, directamente la dirección de
ip va a estar bien. En el ejemplo sigo usando “servidorvpn” donde en un caso real, seria “servidorvpn.dyndns.org” si somos
usuarios de dyndns.org o alguna dirección de red válida en Internet.
Finalmente hacemos una mini introducción a como configurar una conexión de adsl pptp como ofrecen algunos proveedores en
nuestro país y terminamos de configurar el cliente de nuestra vpn al mismo tiempo. El archivo en cuestión no existe, hay que
crearlo en /etc/ppp/peers que es donde se ubica la configuración de los proveedores de Internet y en nuestro caso, de la VPN.
Un ejemplo para nuestra VPN sería un archivo llamado “servidorvpn” con el siguiente contenido:
pty "pptp servidorvpn --nolaunchpppd"
name alumno
remotename servidorvpn
require-mppe-128
file /etc/ppp/options.pptp
ipparam bubu
Esto mismo se aplica a una conexión pptp de adsl. Pero para una conexión pppoe sería de la siguiente forma:
pty "/usr/sbin/pppoe -I eth0 -T 80 -m 1452"

noipdefault
defaultroute
hide-password
lcp-echo-interval 60
lcp-echo-failure 3
connect /bin/true
noauth
persist
mtu 1492
user "usuariodeadsl@isp-bsas-apb"
Los cambios que hay que hacer en este archive es el de “user” para que coincida con el de nuestro proveedor y con el chap-
secrets.
Ahora, una vez que vieron lo difícil. Hay una forma amena de hacer esto y es usando el modo gráfico. Les dejo un source para
agregar al apt-get para poder bajarse un GUI para configurar una conexión pptp sobre Linux en modo gráfico como en
Windows.
deb http://quozl.netrek.org/pptp/php-gtk ./P
Agregando esto al /etc/apt/sources.list y corriendo un “apt-get update” ya van a tener disponible el paquete “pptp-php-gtk” que
les hace la configuración mucho mas simple con un par de “seguir”.
Ahora que tenemos todo configurado, del lado del cliente y del lado del servidor podemos iniciar la conexión con el comando
“pon” y como parámetro el servidor vpn al que queremos conectarnos. En nuestro ejemplo “pon servidorvpn” y luego de unos
segundos deberíamos tener una interfaz mas llamada ppp0 (sino teníamos ya una), tanto en nuestro servidor como en nuestro
cliente.
- 40 -
Configurando las reglas de ruteo e iptables
Esto no terminó acá. Nos queda pendiente el ruteo. Nuestro equipo hace ping y ve a nuestro servidor de VPN a travez de una ip
privada, bárbaro. Pero no vemos a ninguno de los equipos que hay detrás de este servidor. Necesitamos levantar una ruta para
que nuestro equipo sepa por donde llegar al resto de los equipos.
Vamos a un ejemplo concreto. Si luego de haber establecido una conexión entre nuestro servidor y el cliente pptp tenemos una
dirección de red ppp1 similar a la siguiente:
ppp1 Link encap:Point-to-Point Protocol

inet addr:10.250.1.250 P-t-P:10.250.1.77 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1496 Metric:1
RX packets:2406 errors:0 dropped:0 overruns:0 frame:0
TX packets:3169 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:109583 (107.0 KiB) TX bytes:118907 (116.1 KiB)
Podemos ver claramente que el servidor que nos asigno la dirección es la ip 10.250.1.77 y nuestra ip privada en la VPN es
10.250.1.250.
Nosotros queremos lograr que para hablar con esa red usemos la interfaz que se levantó con la conexión. Para esto, el comando
route nos va a ayudar:
“route add –net 10.250.1.0 netmask 255.255.255.0 dev ppp1”
De esta forma, todos los paquetes dirigidos a la red 10.250.1.0 van a salir a travez de nuestra nueva interfaz ppp1.
Podemos comprobar esto con un traceroute.
# traceroute 10.250.1.12
traceroute to 10.250.1.12 (10.250.1.12), 30 hops max, 38 byte packets
1 10.250.1.77 (10.250.1.77) 42.126 ms 48.315 ms 53.416 ms
2 10.250.1.12 (10.250.1.12) 56.524 ms 42.148 ms 48.453 ms
Ahora podemos ver a la Lan completa usando como ruta por defecto para esa red el servidor VPN.
Conclusión
Al finalizar el capitulo tenemos una noción de cómo armar rápido y sin mayores complicaciones una VPN desde un servidor
Linux a cualquier cliente, ya sea Windows o Linux y desde Internet acceder como cliente a la Lan que esté detrás del servidor
de VPN. Aparte, tienen las nociones básicas de cómo establecer una conexión de adsl tanto con modems pppoe como pptp.
Para seguir leyendo:

El parche de mppe:
http://public.planetmirror.com/pub/mppe/
El poptop:
http://www.poptop.org
El cliente pptp para linux:
http://pptpclient.sourceforge.net/
- 41 -
Capítulo 6 – Network Intrusión Detection Systems
Snort
1. Que es el Snort?
El Snort es uno de los mejores Network Intrusion Detection System opensource. Vamos a ver como instalarlo, configurarlo y
probarlo en Linux, pero también está disponible para otras plataformas, inclusive Microsoft. Trabaja como un monitor de red
manejando un registro de los intentos de intrusión y de señales de posibles malos comportamientos o intentos de hackeo.
2. ¿Que es un NIDS?
Un Network Intrusion Detection System es un sistema responsable de detectar anomalías o cualquier otro tipo de información
que se considere no autorizada en una red. A diferencia de un firewall, que se lo puede configurar para denegar o aceptar un
servicio particular con ciertas restricciones. Si el tráfico es aceptado por las reglas se permite el tráfico independientemente del
contenido del paquete. Un NIDS captura el tráfico y lo inspecciona este o no aceptado en el firewall. Basándose en su
contenido tanto a nivel IP como a nivel aplicación.
3. Porque usar un NIDS?

Los sistemas de detección de intrusos son una parte integral de cualquier red. En internet las cosas cambian seguido y nuevas
vulnerabilidades y exploits se descubren diariamente. Un NIDS aporta una capa más de seguridad para detectar la presencia de
un intruso.
4. Tipos de IDS:
El snort puede trabajar principalmente de dos formas. Con una interfaz de red o con dos. Es decir, con una interfaz vamos a
monitorear una red interna y desde la misma interfaz vamos a hacer managment remoto del equipo vía ssh. De esta forma,
podemos controlar el tráfico LAN de nuestra red local. Este modo se llama NIDS, Network Intrusión Detection System.
La otra posibilidad es correr el snort como IDS, Intrusión Detection System en el cual esta escuchando exclusivamente en la
interfaz que tenga salida a Internet y de esta forma controlar el tráfico entrante a nuestro equipo o red interna.
5. Instalando el Snort:
Para instalar el Snort en Debian podemos usar el apt-get y utilizar como paquete a instalar simplemente el “snort”. Cuando le
pidamos de instalar el snort va a automáticamente bajarse sus dependencias y entre ellas va a estar el paquete “snort-rules” que
son las reglas que usa el Snort para detectar intrusos. Estas reglas son actualizables de manera regular como se haría con un
antivirus. Mas adelante vamos a volver sobre éste tema.
Luego de haber bajado los paquetes y de comenzar a configurarlos nos va a presentar un menú con el mini wizard que nos tiene
acostumbrados el apt que nos va a hacer una serie de preguntas. La primera de ellas es en que interfaz queremos que el snort
escuche. Acá deberíamos definir si queremos ser NIDS o IDS en base a que interfaz elijamos. Acto seguido, nos va a consultar
cual es nuestra red interna. Es decir, en quienes confiamos. Sino confiamos en nadie la respuesta sería “any”. Como última
pregunta del wizard nos pide que definamos una dirección de email para que el equipo envíe las estadísticas y reportes diarios
de intentos de intrusiones.
6. Configurando el Snort:
El archivo principal de configuración del snort esta ubicado en /etc/snort/snort.conf. Pero todas las opciones que definimos en
el mini wizard del apt no están en ese archivo. Están ubicadas en /etc/snort/snort.debian.conf.
# This file is used for options that are changed by Debian to leave
# the original lib files untouched.
# You have to use "dpkg-reconfigure snort" to change them.
DEBIAN_SNORT_STARTUP="boot"
DEBIAN_SNORT_HOME_NET="192.168.0.0/24"
DEBIAN_SNORT_OPTIONS=""
- 42 -
DEBIAN_SNORT_INTERFACE="ppp0"
DEBIAN_SNORT_STATS_RCPT="root"
DEBIAN_SNORT_STATS_TRESHOLD="1"
Cuando queramos hacer cambios en la configuración que involucren estos parámetros, recordemos el archivo en cuestión. En el
resto de las distribuciones, todo esta en el archivo principal. Si nos manejamos con este archivo, no hace falta que miremos
mucho el contenido del /etc/snort/snort.conf. Unas cosas que probablemente queramos definir en él son las siguientes variables
que sirven para definir si estamos corriendo o no alguno de estos servicios o para darlos de alta para no recibir falsas alertas.
# Configure your server lists. This allows snort to only look for attacks to
# systems that have a service up. Why look for HTTP attacks if you are not
# running a web server? This allows quick filtering based on IP addresses
# These configurations MUST follow the same configuration scheme as defined
# above for $HOME_NET.
# List of DNS servers on your network

var DNS_SERVERS $HOME_NET
# List of SMTP servers on your network

var SMTP_SERVERS $HOME_NET
# List of web servers on your network

var HTTP_SERVERS $HOME_NET
# List of sql servers on your network

var SQL_SERVERS $HOME_NET
# List of telnet servers on your network

var TELNET_SERVERS $HOME_NET
# List of snmp servers on your network

var SNMP_SERVERS $HOME_NET
7. ¿Como estar al día con las reglas?

Como anticipamos, las reglas se actualizan de la misma manera que las definiciones de un antivirus, con lo cual necesitamos
hacer un update a las reglas del snort con cierta frecuencia.
Hay un script hecho para esto si instalan la documentación del snort. El paquete se llama “snort-doc” y nos deja un directorio
en /usr/share/doc/snort-doc/. Ahí vamos a poder encontrar un script llamado snort_rules_update en el directorio examples. Sería
ideal cronearlo de vez en cuando para que se actualice automáticamente.
8. Probando el Snort.
Terminaron de configurar el snort, lo actualizaron. Ahora queda pendiente comenzar a probarlo a ver si nos informa de lo que
pasa.
Previamente, vamos a ver como arrancar el snort por línea de comandos así vemos como se comporta en detalle.
Para definirle su archivo de configuración, fundamental para que funcione en modo NIDS.
-c path_al_archivo_de_configuración
Le decimos donde va a generar los logs.

-l directorio_de_logs
Para que nos muestre como funciona y que resultados obtiene en pantalla.
-d
Idealmente, el snort debería correr con un usuario que no sea el root.
- 43 -
-u usuario –g grupo
Hace falta saber en que interfaz debe escuchar.

-i interfaz
También, en quien confiar.

-S HOME_NET=[red/mascara]
Finalmente, un ejemplo concreto que va a usar el archivo de configuración por defecto, va a dejar los logs en /var/log/snort/, va
a correr en pantalla mostrándonos el progreso, el proceso va a estar lanzado por el usuario snort, grupo snort en la interfaz ppp0
y confiando en la red 192.168.0.0/24.
snort -c /etc/snort/snort.conf -l /var/log/snort/ -d -u snort -g snort -S HOME_NET=[192.168.0.0/24] -i ppp0
El output del comando, si funcionó bien, debería ser algo como:
--== Initialization Complete ==--
-*> Snort! <*-

Version 2.1.2 (Build 25)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
Ahora es cuando probamos nuestro snort contra un portscanner como el nmap y revisamos como crecen los logs en
/var/log/snort/. Un tail del alert.log acusa lo siguiente:
[**] [121:4:1] Portscan detected from 200.42.142.231 Talker(fixed: 30 sliding: 30) Scanner(fixed: 0 sliding: 0) [**]
05/08-23:17:15.333851
05/08-23:24:43.460715
05/08-23:25:05.918803
Para leer el contenido de los logs que llevan el nombre de “snort.log.*” tenemos que usar el snort con el parámetro “-r” y como
segundo parámetro el nombre del archivo a analizar en detalle.
8. Addons para el snort.

En la página oficial del snort, http://www.snort.org podemos encontrar aplicaciones para complementar al snort en la sección
de downloads. Hay herramientas para generar htmls basándose en los logs, generar reportes en bases de datos, actualizar las
reglas, etc.
Portsentry
1. ¿Qué es el Portsentry?
El Porsentry cumple funciones similares a las del Snort, pero a diferencia de él puede reaccionar en base a lo que registre. Es
decir, el Portsentry va a poder generar logs y bloquear a los intrusos usando reglas de iptables automáticamente.
2. ¿Cómo hace esto el Portsentry?

Cuando instalemos, configuremos y pongamos en marcha el Portsentry va a sólo registrar el tráfico y generar reportes. Pero
una vez configurado puede reaccionar y en base a ciertas alertas ejecutar comandos. Desde avisos via mail, pager o logs hasta
- 44 -
comandos de iptables para bloquear a los intrusos. A diferencia del Snort, el Portsentry va a simular que nuestro equipo tiene
abiertos un montón de puertos y de esta forma invita a los intrusos a intentar hacer algo. Apenas detecta actividad en estos
puertos el Portsentry interactúa. Algo similar a lo que hace el conocido firewall de Symantec.
3. ¿Cómo instalamos el Porsentry?

La instalación del portsentry la podemos hacer con el apt-get. Una vez terminado de desempaquetar nos va a advertir que va a
trabajar sin interactuar con lo que registre, es decir que solo va a monitorear el tráfico. Si necesitamos cambiar esto, tenemos
que caer en el archivo de configuración.
4. ¿Cómo configuramos el Portsentry?

El archivo de configuración esta ubicado en /etc/portsentry/portsentry.conf y tiene varias opciones interesantes.
Una de las opciones importantes es en que puertos el Prelude va a escuchar. Mientras mas puertos escuchemos mas alarmas
vamos a generar. Comenten y descomenten para dejar sólo una opción de las tres que hay disponibles.
# Un-comment these if you are really anal:

#TCP_PORTS="1,7,9,11,15,70,79,80,109,110,111,119,138,139,143,512,513,514,515,540,635,1080,1524,2000,2001,4
000,4001,5742,6000,6001,6667,12345,12346,20034,27665,30303,32771,32772,32773,32774,31337,40421,40425,497
24,54320"
#UDP_PORTS="1,7,9,66,67,68,69,111,137,138,161,162,474,513,517,518,635,640,641,666,700,2049,31335,27444,34
555,32770,32771,32772,32773,32774,31337,54321"
#
# Use these if you just want to be aware:
TCP_PORTS="1,11,15,79,111,119,143,540,635,1080,1524,2000,5742,6667,12345,12346,20034,27665,31337,32771,
32772,32773,32774,40421,49724,54320"
UDP_PORTS="1,7,9,69,161,162,513,635,640,641,700,37444,34555,31335,32770,32771,32772,32773,32774,31337,5
4321"
#
# Use these for just bare-bones
#TCP_PORTS="1,11,15,110,111,143,540,635,1080,1524,2000,12345,12346,20034,32771,32772,32773,32774,49724,
54320"
#UDP_PORTS="1,7,9,69,161,162,513,640,700,32770,32771,32772,32773,32774,31337,54321"
Cuando definamos que el Prelude tenga que reaccionar ante un evento, van a quedar registros en los logs y en los archivos que
definimos en las siguientes variables. Aparte, podemos definir hosts de los que confiamos ciegamente y por lo tanto queremos
ignorarlos para que no sean bloqueados.
# Hosts to ignore
IGNORE_FILE="/etc/portsentry/portsentry.ignore"
# Hosts that have been denied (running history)
HISTORY_FILE="/var/lib/portsentry/portsentry.history"
# Hosts that have been denied this session only (temporary until next restart)
BLOCKED_FILE="/var/lib/portsentry/portsentry.blocked"
Para activar que el Prelude reaccione ante un evento, tenemos que cambiar los siguientes valores. En “0” los paquetes son sólo
registrados, en “1” se los bloquea y en “2” se ejecuta un comando seleccionado por el administrador.
BLOCK_UDP="0"
BLOCK_TCP="0"
Si activamos el bloqueo de paquetes, tenemos que definir que método vamos a utilizar para esto. La variable siguiente es la
ideal si estamos en Linux y tenemos iptables instalado.
# iptables support for Linux
- 45 -
KILL_ROUTE="/sbin/iptables -I INPUT -s $TARGET$ -j DROP"
5. Iniciando y probando el servicio.

Una vez iniciado el servicio, vamos a tener el demonio corriendo y el log de la aplicación va a crecer en el daemon.log
Si revisamos los puertos que tenemos abiertos a raíz del Portsentry vamos a ver que esta ocupando los siguientes ports, de
ejemplo esto sería parte del output que deberían tener al ejecutar un “netstat -anp | grep portsentry”:
tcp 0 0 0.0.0.0:1 0.0.0.0:* LISTEN 14463/portsentry

Una vez que tengamos esto, podemos probarlo escaneándonos desde otro equipo de la red y viendo como se genera una regla
de iptables para bloquear el posible intruso.
Conclusión
El Snort es una excelente herramienta opensource multiplataforma para registrar intentos de romper nuestra seguridad. Tiene
continuas actualizaciones y soporte en su página oficial y listas de correo. El Portsentry no llega a tener el mismo nivel de
registro que el Snort dado que depende de que nosotros no hayamos bloqueado en nuestro firewall los puertos que el controla.
Si tenemos un firewall demasiado cerrado el Portsentry no va a servirnos de mucho. Por otro lado, es una buena solución para
un equipo hogareño o un servidor para compartir Internet, pero no para una empresa ni para un servidor de gran escala donde el
Porsentry va a decidir de bloquear ciertos hosts en base a posibles portscans.
- 46 -
Capítulo 7 – Capítulo Final
Introducción
¿Qué es un sniffer?
Un sniffer es un programa/dispositivo que controla el tráfico de la red y captura la información que se transmita por ella.
Sniffer son básicamente programas para interceptar datos. Trabajan basándose en que el tráfico ethernet fue diseñado para
compartir.
La mayoría de las redes usan tecnología de broadcast, es decir que cada mensaje transmitido por un equipo en una red va a ser
leído por todos los equipos de una red. En la práctica, todos los equipos de la red, excepto el que debía recibir el mensaje van a
ignorar el mensaje porque no le corresponde. Igualmente, uno puede lograr que nuestro equipo acepte esos mensajes aunque no
sean para él usando un sniffer.
¿Para qué puedo usar un sniffer?

En internet se consiguen, tanto free como no free, herramientas para hacer sniffing. Estas aplicaciones sirven para:
• Automáticamente conseguir usuarios y passwords de una red en protocolos que transmiten en texto plano, como el
telnet y el pop3.
• Convertir el tráfico a “human readable” así se puede intepretar el contenido.
• Analizar problemas de tráfico de red, como problemas de latencia o equipos que “no se ven” en la red.
• NIDS, como el snort.
• Logueo de red, simplemente para tener una estadistica del tráfico de la red para futuro analisís.
¿Hay algún lugar donde pueda conectarme para ver el tráfico de todo internet?
Si bien parece una pregunta ridícula, mucha gente suele hacer este tipo de preguntas. NO es la respuesta. La conectividad que
hay en Internet es como una red, el tráfico camina por esa red y no hay un punto en el cual se puedan ver todos los origenes y
destinos. De la misma forma, Internet soporta que haya “puntos de falla” y que todos sigamos conectados. De la misma forma,
previene el sniffing.
¿Cómo trabaja un sniffer?

Supongamos que una pcA quiere hablar con una pcB. pcA tiene una dirección de red 192.168.0.200 y pcB tiene una direccion
de red 192.168.0.201. Cuando pcA le envía un paquete a la red incluye como contenido la direccion mac del destino y del
origen. Todos los equipos de la red comparan la mac del destino con su mac. Cuando no coincidan van a descartar el paquete.
El equipo que use un sniffer no cumple con esta regla y no descarta el paquete. Este tipo de equipos se dice que esta en modo
promiscuo y efectivamente puede escuchar todo el tráfico de una red.
¿Qué es una MAC address?

Muchos equipos pueden llegar a compartir una red. Cada equipo debe tener una identificación única para poder distinguirse
entre ellos. Esto no pasa con conexiones dial-up donde uno habla únicamente con el otro lado de la línea telefónica. Pero
cuando enviamos tráfico al cable de red tenemos que dejar en claro para quien es el mensaje que estamos enviando. Para
cumplir con esto, cada equipo ethernet tiene un identificador unico llamado mac address. Con el comando ifconfig van a poder
ver la dirección mac de la placa de red de uds.
eth0 Link encap:Ethernet HWaddr 52:54:05:F3:95:01
Donde la mac address es el número hexadecimal 52:54:05:F3:95:01
- 47 -
¿Cómo detectar un sniffer?
Un sniffer es pasivo, sólo recolecta información. Por lo tanto, es dificultoso detectar un sniffer en una red. A nivel local, en
Linux podemos ver si una placa esta o no en modo promiscuo con solo mirar el output del comando ifconfig.

inet addr:192.168.0.200 Bcast:203.199. ...
UP BROADCAST RUNNING MULTICAST MTU:1500 ...
Pero en un equipo en modo promiscuo el resultado del ifconfig no es el mismo.

inet addr:192.168.0.200 Bcast:203.199. ...
UP BROADCAST RUNNING PROMISC MULTICAST ...
¿Cómo prevenir el sniffing?

El mejor método es segurizando nuestra red usando métodos de encriptación. Mientras que esto no va a prohibir que nadie nos
registre el tráfico, va a evitar que entiendan lo que capturen.
*SSH: El estandar para administración remota de equipos *nix o *bsd es a travez del Secure Shell. El SSH espera primero la
validación de ambos equipos para pedir usuario y password, TODA la transferencia es encriptada. Hay dos protocolos para este
tipo de comunicaciones, tengamos presente en estar usando la versión 2 y no la versión 1 que trae problemas similares a los que
trae el telnet. Si bien es encriptado, es popularmente desencriptable.
*VPN: Encriptar los datos en una Red Privada Virtual para transmitir datos seguros entre dos redes. Pero con una aclaración
importante, obviamente si alguno de los nodos es comprometido con algún troyano, el tráfico vuelve a estar comprometido.
Hay varios niveles de encriptación y tipos de VPN.
*SSL: Secure Sockets Layer, SSL esta incluido en muchos servicios actuales, como web, smtp, pop3. Es lo que se usa cuando
se hace una transmisión web en modo seguro. Como cuando hacemos una compra con tarjeta por Internet o como cuando
miramos los mails en Hotmail. Una aclaración, NO cuando ingresamos el usuario y password en Hotmail, sólo cuando los
leemos.
*GNUPG: Los emails pueden ser sniffeados de muchas formas diferentes. Puede que ni siquiera hayan sido sniffeados, sino
que fueron logueados por un servidor corporativo que registra el tráfico. La mejor forma de asegurar nuestro tráfico es
encriptándolo con PGP (Pretty Good Privacy). Para PGP existe la alternativa open source GNUPG. Podemos utilizar gnupg
en la mayoría de los clientes de correo open source.
¿Qué aplicaciones hay disponibles en Linux para usar de sniffer?
*Ethereal: Siendo una aplicación gráfica es una aplicación que tiene muchos adeptos. Analiza el tráfico de una red y nos da la
posibilidad de usar filtros para buscar lo que queramos. Ideal para encontrar problemas de red o protocolos.
*Dsniff: Una herramienta utilizada para sniffer una red y encontrar tráfico en texto plano. Incluye varias aplicaciones para
escuchar y crear tráfico de red.
*Snort: Ya conocemos el Snort, pero no podemos dejar de incluirlo. Es la herramienta a la hora de usar un NIDS y tener un
control de lo que esta pasando en nuestra LAN.
- 48 -
*Ettercap: Si pensaban que tenían una red segura por usar un switch, estan equivocados. El ettercap es una herramienta
demasiado poderosa que nos permite tomar el control total de una LAN.
*Kismet: Si tienen una placa wifi no pueden dejar de probar esta herramienta. Es la herramienta por excelencia a la hora de
hacer sniffing en redes inalámbricas. Puede emitir sonidos al descubir una red e inclusive registrar la ubicación usando un gps.
¿Cómo prevenir el sniffing en la práctica?

A esta altura, ya conocen el ssh y deberían usarlo diariamente. Los conceptos básicos de VPN ya se vieron y se puso en
práctica. Lo que queda pendiente es segurizar servicios con SSL y encriptación con PGP.
Utilizando SSH
Vamos a suponer la siguiente situación. Tenemos una empresa con una sucursal en la vereda de enfrente. Las dos sucursales se
enlazan mediante una red inalámbrica desde un extremo a otro de la calle. A nivel administrativo, desde ambos extremos de la
red corre una aplicación corporativa que maneja la contaduría de la empresa. Datos sensitivos corren por nuestra red
inalámbrica. Un buen día, descubrimos que tenemos una camioneta negra parada las 24hs del día y con nuestro snort
detectamos continuos intentos de escanear el tráfico entre los extremos de nuestra red.
¿Que solución tenemos ante esta situación?

Bueno, acá es donde el SSH nos vuelve a dar una importante mano. No vamos a poder reprogramar la aplicación para que
trabaje con SSL. Pero podemos crear un túnel sobre SSH para darle soporte de SSL a la aplicación en cuestión.
Vamos a dar más datos sobre nuestro ejemplo:

*La red A del edificio principal esta en una red 192.168.0.0/24.
*La red B del edificio sucursal esta en una red 192.168.1.0/24.
*Los routers que se utilizan para comunicar ambas redes, los que tenemos que segurizar, tienen Linux instalado y se
administran remotamente vía SSH.
*El routerA tiene una dirección de red 10.0.0.1 y el routerB tiene una dirección de red 10.0.0.2.
*La aplicación a segurizar corre en el routerB en el puerto 152.
Bien, ahora queremos lograr que la conexión entre todos los equipos de la red A y el equipo 192.168.1.200 en el puerto 152
sean encriptados. Este es nuestro objetivo final.
Para eso, necesitamos levantar una conexión encriptada por ssh desde el routerA al routerB:
Ssh –L 1152:routerb:152 root@routerb
De esta forma, le estamos pidiendo al ssh que haga un túnel en nuestra placa de loopback levantando un puerto 1152. Cada vez
que nos conectemos con nuestra placa de loopback en el puerto 1152 vamos a estar hablando por ssh al puerto 152 del routerB.
Para ver esto de una forma un poco más gráfica.
routarA:~# netstat -anp | grep ssh

tcp 0 0 192.168.0.19:33029 192.168.0.1:22 ESTABLISHED2889/ssh
tcp6 0 0 127.0.0.1:1152 :::* LISTEN 2889/ssh
tcp6 0 0 :::22 :::* LISTEN 2017/sshd
Pero esto no nos resuelve los problemas. Porque lo único que logramos fue que el routerA pueda conectarse con el routerB a
travez del túnel. Pero no a la lan que esta detrás del routerA. Entonces el comando que utilizamos para entablar el túnel esta
incompleto.
ssh –L 1152:routerb:152 root@routerb –g
- 49 -
Ahora si le estamos diciendo al routerA que aparte de levantar el túnel en la placa de loopback lo haga en todas las interfaces.
Es decir que estamos compartiendo con la LAN del routerA nuestra conexión. Para comprobarlo:
linux:~# netstat -anp | grep ssh

tcp 0 0 192.168.0.19:33029 192.168.0.1:22 ESTABLISHED2889/ssh
tcp6 0 0 :::1152 :::* LISTEN 2889/ssh
tcp6 0 0 :::22 :::* LISTEN 2017/sshd
Finalmente, lo logramos. Cada vez que alguien se conecte a nuestro equipo en cualquier dirección de red que tengamos en el
puerto 1152 va a conectarse a travez de una conexión segura por ssh al puerto 152 del routerB.
Algunas consideraciones finales: Tengan precaución de sólo aceptar conexiones entre ambos extremos del nodo y de nadie
mas en las interfaces que dan a la conexión wifi. De hecho, sería ideal que restrinjan los puertos con excepción del ssh
obviamente y el de la aplicación tuneleada. Extrema precaución en no dejar el 1152 disponible para la interfaz wifi dado que
estamos aceptando conexiones de todos lados con el “-g” en el túnel.
Utilizando GNUPG
El segundo método que vamos a ver lo vamos a poner en práctica para encriptar emails.
Alguna vez se preguntaron si cuando envían un mail la única persona que lee el contenido del mail es la persona a la que uds
destinaron el mail? Bueno, existe la posibilidad de que alguien intercepte el mail en el camino y lea su contenido.
Con GNUPG y un cliente de correo que soporte GPG vamos a poder enviar y recibir mails encriptados o firmados
digitalmente. Para eso, necesitamos instalar el gnupg.
apt-get install gnupg
¿Cómo generar una llave?

Una vez finalizada la instalación todos los usuarios de nuestro sistema van a tener la posibilidad de generar llaves. GNUPG se
maneja con intercambio de llaves, similar al ssh. Es decir que vamos a tener que generar una llave pública y una privada. La
privada nuevamente es sólo para nosotros. La pública es la que vamos a ofrecerle a nuestros contactos para que puedan
enviarnos mails encriptados que sólo nosotros podemos desencriptar y para que puedan asegurarse de que nuestros mails
firmados digitalmente sean realmente nuestros.
gpg --gen-key
De esta forma comenzamos el proceso para generar un juego de llaves.
gpg (GnuPG) 1.2.4; Copyright (C) 2003 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Please select what kind of key you want:

(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) RSA (sign only)
Your selection?
Acá nos pide que elijamos el tipo de llave que queremos utilizar. Por defecto es lo correcto. Continuemos eligiendo la opción
“1”.
Acto seguido, nos va a pedir que generemos una palabra clave para usar la llave. Igual que para generar las llaves de ssh. Luego
de que hayamos definido la palabra clave el gpg nos va a mostrar un mensaje como el siguiente:
- 50 -
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++.+++++.++++++++....++++++++++..+++++.+++++.+++++++.+++++++
+++.++++++++++++++++++++++++++++++++++++++..........................++++
No dejemos de hacer lo que nos pide así el tiene mayores chances de generar una llave.
Cuando termine de trabajar vamos a tener un directorio .gnupg en donde vamos a tener guardadas nuestras llaves. Para ver que
llaves tenemos podemos hacer algo como:
gpg --list-keys
/home/jperez/.gnupg/pubring.gpg
---------------------------------
pub 1024D/A31EEC31 2004-05-16 Juan Peréz (CORtech) <jperez@cortech.com.ar>
sub 1024g/3123C36E 2004-05-16
¿Cómo distribuir nuestra llave?

Bien, ahora que tenemos una llave pública y una privada lo ideal sería que nuestros contactos también la tengan. Sino todo lo
que hicimos no tiene sentido alguno.
Para esto tenemos dos posibilidades. Pasar la llave a texto y enviarla por mail o publicarla en internet.
Para el primer caso:
gpg --armor --export jperez@cortech.com.ar > llave
Luego, nos queda a nosotros como tarea enviar la llave por mail a nuestros contactos o publicarla en una página en internet. El
contenido del archivo llave, a modo de ejemplo es el siguiente:
-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: GnuPG v1.2.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
mQGiBDkHP3URBACkWGsYh43pkXU9wj/X1G67K8/DSrl85r7dNtHNfLL/ewil10k2
q8saWJn26QZPsDVqdUJMOdHfJ6kQTAt9NzQbgcVrxLYNfgeBsvkHF/POtnYcZRgL
tZ6syBBWs8JB4xt5V09iJSGAMPUQE8Jpdn2aRXPApdoDw179LM8Rq6r+gwCg5ZZa
pGNlkgFu24WM5wC1zg4QTbMD/3MJCSxfL99Ek5HXcB3yhj+o0LmIrGAVBgoWdrRd
BIGjQQFhV1NSwC8YhN/4nGHWpaTxgEtnb4CI1wI/G3DK9olYMyRJinkGJ6XYfP3b
cCQmqATDF5ugIAmdditnw7deXqn/eavaMxRXJM/RQSgJJyVpbAO2OqKe6L6Inb5H
kjcZA/9obTm499dDMRQ/CNR92fA5pr0zriy/ziLUow+cqI59nt+bEb9nY1mfmUN6
SW0jCH+pIQH5lerV+EookyOyq3ocUdjeRYF/d2jl9xmeSyL2H3tDvnuE6vgqFU/N
sdvby4B2Iku7S/h06W6GPQAe+pzdyX9vS+Pnf8osu7W3j60WprQkUGF1bCBHYWxs
YWdoZXIgPHBhdWxnYWxsQHJlZGhhdC5jb20+iFYEExECABYFAjkHP3UECwoEAwMV
AwIDFgIBAheAAAoJEJECmvGCPSWpMjQAoNF2zvRgdR/8or9pBhu95zeSnkb7AKCm
/uXVS0a5KoN7J61/1vEwx11poLkBDQQ5Bz+MEAQA8ztcWRJjW8cHCgLaE402jyqQ
37gDT/n4VS66nU+YItzDFScVmgMuFRzhibLblfO9TpZzxEbSF3T6p9hLLnHCQ1bD
HRsKfh0eJYMMqB3+HyUpNeqCMEEd9AnWD9P4rQtO7Pes38sV0lX0OSvsTyMG9wEB
vSNZk+Rl+phA55r1s8cAAwUEAJjqazvk0bgFrw1OPG9m7fEeDlvPSV6HSA0fvz4w
c7ckfpuxg/URQNf3TJA00Acprk8Gg8J2CtebAyR/sP5IsrK5l1luGdk+l0M85FpT
/cen2OdJtToAF/6fGnIkeCeP1O5aWTbDgdAUHBRykpdWU3GJ7NS6923fVg5khQWg
uwrAiEYEGBECAAYFAjkHP4wACgkQkQKa8YI9JamliwCfXox/HjlorMKnQRJkeBcZ
iLyPH1QAoI33Ft/0HBqLtqdtP4vWYQRbibjW
=BMEc
-----END PGP PUBLIC KEY BLOCK-----
- 51 -
Existe también la posiblidad de exportarlo a un servidor de llaves. Concretamente el mas usado es www.keyserver.net donde la
mayoría de la gente aloja sus llaves. Ahí simplemente podemos hacer un upload de nuestra llave y dejarla como referencia para
que la gente pueda consultarla.
¿Cómo importar llaves de nuestros contactos?

Lo único que nos queda pendiente es que hacer cuando todos nuestros contactos empiecen a usar GPG y tengamos que
empezar a poder importar las llaves de los demas.
Bueno, para eso tenemos que volver a usar el comando GPG.
gpg --import llavedemicontacto.txt
Listo, ahora tenemos una llave nueva con la que vamos a poder encriptar los mensajes para que sólo el contacto pueda
desencriptarla.
¿Cómo encriptar archivos?

Vimos como encriptar emails. Pero el mismo concepto se aplica a la hora de encriptar archivos.
gpg --recipient jperez@cortech.com.ar --encrypt archivo
El resultado de éste comando produce un archivo llamado “archivo.gpg” que no vamos a poder ver el contenido sin
desencriptarlo.
gpg –decrypt archivo.gpg
Esto nos va a desencriptar el archivo. Deberíamos redirigir la salida del comando a un archivo para no tener el output en
pantalla.
Conclusión
Existen demasiadas herramientas que pueden perjudicar la seguridad en una red LAN. Confiemos o no en nuestros empleados,
es imposible tener un control total de la situación. Lo ideal es tomar la mayor cantidad de medidas de seguridad posible, desde
encriptar los mails hasta establecer conexiones seguras via SSL. Pero para cualquiera sea el caso, es fundamental conocer las
herramientas que hay disponibles para conocer los posibles ataques que nos podemos encontrar. Herramientas como el ettercap
simplemente son inaceptables en una red lan y equipos en modo promiscuo comprometen seriamente la privacidad de una
LAN.
- 52 -
Esta publicación no puede ser reproducida, ni en todo ni en parte, ni registrada en o transmitida por un sistema de recuperación
de información, en ninguna forma ni por ningún medio, sea mecánico, fotoquímico, electrónico, magnético, electroóptico o
cualquier otro, sin el permiso previo y por escrito de CentralTECH.
Registro de Obras Publicadas (Derecho de Autor): Expediente Número: 278087
- 53 -

Linux Original Courseware - LX5: Seguridad y Contraseguridad

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Linux Original Courseware - LX5: Seguridad y Contraseguridad

Diunggah oleh

Hak Cipta:

Format Tersedia

LOC: Linux Original Courseware*

LX5: Seguridad y Contraseguridad

Las palabras en inglés que no necesiten

Las siglas que corresponden a protocolos,

Las teclas y/o combinación de teclas, donde la

Los nombres de archivos y dispositivos,

Los Comandos y utilitarios del sistema operativo,

Para expresar los parámetros de los comandos se

LVM – Logical Volume Management

¿Cómo LVM nos soluciona los problemas?

PV (Physical Volume-Volúmen Físico):

VG (Volume Group-Grupo de Volúmenes):

LV (Logical Volume-Volúmen Lógico):

FS (File System-Sistema de Archivos):

Configurando, Compilando e Instalando

[*] Multiple devices driver support (RAID and LVM)

Para instalar las herramientas, con el apt-get es muy simple:

apt-get install lvm10

vgcreate crea un VG a partir de un PV

lvmchange cambia atributos de un LVM

¿Cómo se crea un Physical Volume?

¿Cómo se crea un Volume Group?

Si tenemos dos o más dispositivos físicos:

vgcreate vg00 /dev/ide/host1/bus0/target0/lun0/part1

¿Cómo se crea un Logical Volume dentro de un Volume Group?

lvcreate –L tamaño –n nombre vg00

vgdisplay vg00 | grep “Total PE”

Veamos un ejemplo paso a paso:

mount /dev/vg00/usr /mnt/temp Montar el LV que reemplazará al /usr en /mnt/temp

Un ejemplo de “/etc/fstab” luego de implementar LVM

Para verlo en la práctica, veremos un ejemplo medianamente complejo, pero entendible:

/dev/hda1 / ext3 defaults,errors=remount,ro

Ejemplos prácticos de la administración de un LVM

vgextend vg00 /dev/hdc1

Removiendo Physical Volumes (discos) de un Volume Group

pvmove /dev/hdc1 /dev/hdd1

vgreduce vg00 /dev/hdd1

Remover un Logical Volume

Reduciendo y aumentando el tamaño de un Logical Volume

Realizando backups al vuelo con snapshots

tar -cf /dev/rmt0 /mnt/ops/dbbackup

http://evms.sourceforge.net El sitio de EVMS, un proyecto paralelo a LVM totalmente

Los demonios syslog y klogd

Breve ejemplo explicativo

El siguiente es un ejemplo válido de uno de estos archivos:

Mar 4 00:00:00 srvlx /USR/SBIN/CRON[1286]: (root) CMD ( ... )

Facilidades y niveles de seguridad:

Facilidad Subsistema Asociado

cron.warn mensajes de cron, con prioridad warn o superior

¿Dónde registrar los logs?

Destino Características Ejemplo

¿Cómo configurar un servidor de logs?

Configuración en el equipo “cliente”

# Registra los logs mas importantes localmente en la consola y en un archivo.

# Avisa a los que estan logueados de las emergencias.

# Envia todo, menos los logs de mails, al servidor de logs

Luego de hacer esta modificación sólo hay que reiniciar el syslogd.

# Options for start/restart the daemons

# Mostrar mensajes criticos

# Separar los mensajes por subsistema

# Tenemos un archivo particular para los su

# El log principal del equipo

¿Que pasó con el klogd?

logger -p facility.level “Mensage to be sent to syslogd”