P. 1
Linux Original Courseware - LX5: Seguridad y Contraseguridad

Linux Original Courseware - LX5: Seguridad y Contraseguridad

4.71

|Views: 806|Likes:
Published by Jesus Morbo
Correspondiente al curso:

LX5: Seguridad y Contraseguridad

Correspondiente al curso:

LX5: Seguridad y Contraseguridad

More info:

Published by: Jesus Morbo on Oct 21, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

09/07/2012

pdf

text

original

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(*) Originaly Developed for CentralTECH

- 53 Páginas

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(*) Originaly Developed for CentralTECH

- 53 Páginas

Convenciones
Para el correcto entendimiento de la documentación y de sus contenidos, explicamos las convenciones utilizadas en este documento. Formato Los nombres de Software, Productos Comerciales y/o Compañías. Las palabras en inglés que no necesiten traducción y/o palabras en español que denotan características Las siglas que corresponden a protocolos, características, etc. Las teclas y/o combinación de teclas, donde la combinación se expresa uniendo los nombres de cada tecla con un signo + (más). Los nombres de archivos y dispositivos, contenidos de archivos y salidas por consola. Los Comandos y utilitarios del sistema operativo, con sus respectivos parámetros, denotando que deben ser escritos tal cual se leen. Se debe asumir que seguido a cada comando el usuario debe pulsar la tecla Enter. Para expresar los parámetros de los comandos se respetará la convención de las man pages (páginas de ayuda) utilizando llaves, corchetes rectos, corchetes en ángulo y pipes. Negrita + Cursiva (Itálica) Ejemplo Debian GNU/Linux

Cursiva (Itálica)

Kernel

Mayúsculas + Negrita

TCP/IP
Control

Monoespacio
Alt+F2

Monoespacio

/etc/resolv.conf

Monoespacio + Negrita

mount /mnt/cdrom

cat [-v] arch.txt

Monoespacio + Negrita
cp ar1 ar2 [...] <dir>

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(*) Originaly Developed for CentralTECH

- 53 Páginas

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(*) Originaly Developed for CentralTECH

- 53 Páginas

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): Pueden ser discos rígidos individuales o cualquier dispositivo que desde el punto de vista del SO se vea como un disco.
hda1 hdc1

VG (Volume Group-Grupo de Volúmenes): Contienen la información que engloba los Volúmenes Físicos
diskvg

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

En sistemas que no soportan LVM, el LV es una partición más en el directorio /dev.

FS (File System-Sistema de Archivos):
jfs xfs ext3

Es el formato que se establecerá a cada LV para 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(*) Originaly Developed for CentralTECH

- 53 Páginas

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 pvchange pvdisplay pvmove pvscan vgcreate vgchange vgdisplay vgextend vgreduce vgremove vgrename vgscan lvcreate lvchange lvdisplay lvextend lvreduce lvremove lvrename lvscan lvmchange lvmdiskscan lvmsadc lvmsar

crea un PV cambia los atributos de un PV muestra información de la configuración de un PV mueve datos a un PV diferente busca todos los PVs crea un VG a partir de un PV activa y desactiva VGs muestra información de la configuración de un VG agrega un PV a un VG remueve un PV de un VG remueve un VG renombra un VG inactivo busca todos los VGs crea un LV cambia los atributos de un LV muestra información de la configuración de un LV extiende el tamaño de un LV reduce el tamaño de un LV remueve un LV renombra un LV busca todos los LVs cambia atributos de un LVM escanea todos los discos / particiones y los lista recolector de información estadística 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(*) Originaly Developed for CentralTECH

- 53 Páginas

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(*) Originaly Developed for CentralTECH

- 53 Páginas

• • •

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 cd /usr cp –avx * /mnt/temp ls –l /mnt/temp rm –rf /usr/* umount /mnt/temp mount –a ls –l /usr

Montar el LV que reemplazará al /usr en /mnt/temp Ubicarse en /usr Copiar el contenido del /usr original al /mnt/temp Verificar el contenido del /mnt/temp BORRAR el contenido del /usr original Desmontar el /dev/vg00/usr Comprobar la sintáxis del /etc/fstab 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 /dev/hda2 /dev/vg00/usr /dev/vg00/var /dev/vg00/home /dev/vg00/swap /dev/vg00/tmp /dev/vg00/srv /dev/vg00/squid / ext3 /boot ext3 /usr ext3 /var ext3 /home ext3 none swap /tmp ext3 /srv ext3 /var/spool/squid defaults,errors=remount,ro defaults,noauto defaults,ro defaults defaults,usrquota,grpquota sw defaults,usrquota,grpquota,nosuid defaults,usrquota,grpquota,nosuid reiserfs defaults,noatime,nolog

Vamos a explicar por cada renglón las decisiones tomadas para llegar al esquema planteado:
/

/boot

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. 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(*) Originaly Developed for CentralTECH

- 53 Páginas

/usr

/var /home swap /tmp

/srv

/var/spool/squid

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. 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. 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. 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. 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. 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. 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 pvmove pvmove pvmove pvmove /dev/hdc1 /dev/hdd1 -- moving physical extents in active volume group "dev" -- WARNING: moving of active logical volumes may cause data loss! -- do you want to continue? [y/n] y -- 249 extents of physical volume "/dev/hdb" successfully moved

Nota El comando pvmove es extremadamente lento. Podemos agregarle verbose con -v.

- 10 (*) Originaly Developed for CentralTECH

- 53 Páginas

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

reiserfs

xfs jfs

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. 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. Para este sistema de archivos no hay posibilidad de achicar una partición. 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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. 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.

http://evms.sourceforge.net

- 12 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 Mar Mar Mar 4 5 5 6 00:00:00 17:25:57 17:26:36 14:09:15 srvlx srvlx srvlx srvlx /USR/SBIN/CRON[1286]: (root) CMD ( ... ) pam_rhosts_auth[2285]: allowed to user1@srvlx as user1 su: (to root) user1 on /dev/pts/0 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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
authpriv cron daemon kern lpr mail news local (desde 0 a 7)

Subsistema Asociado Autenticación de usuarios. Trabajos del cron. Servidores del sistema. Kernel. Spool de impresoras. Subsistema e-mail. Subsistema news. 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 cron.=warn cron.!warn cron.!=warn

mensajes de cron, con prioridad warn o superior mensajes de cron, sólo con prioridad warn mensajes de cron, de prioridad menor a un nivel 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 Archivo Características Todos los mensajes son escritos en un archivo de texto plano definido con el path absoluto al mismo. Ejemplo
cron.warn /var/log/cron.warn

- 14 (*) Originaly Developed for CentralTECH

- 53 Páginas

Dispositivo

Lista de usuarios

Equipo remoto

Usualmente se utiliza una terminal para este tipo de destino, como por ejemplo alguna que esté sin uso. Separados por comas, se pueden definir 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. Precedido por un @ todos los mensajes del syslog que correspondan son enviados vía red al equipo elegido para ser logueados.

kernel.err

/dev/tty8

daemon.err

proxyadmin,ftpadmin

authpriv.*

@server_de_log

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

weekly rotate 4 create #compress include /etc/logrotate.d

# rotar los logs semanalmente # guardar 4 rotaciones de logs # crear un log nuevo vacío luego de rotar los viejos # descomentar si queremos que los logs sean comprimidos # 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

#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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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' make[1]: 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' [...] make[2]: Leaving directory `/tmp/aide/aide-0.10' make[1]: Leaving directory `/tmp/aide/aide-0.10' 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 `amd'... 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 `echo'... not infected Checking `egrep'... 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 `asp'... 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 http://www.insecurity.org http://sourceforge.net/projects/aide http://www.chkrootkit.org

Algunos sitios dedicados en materia de seguridad. La página del AIDE en SourceForge. El sitio oficial del ChkRootKit.

- 26 (*) Originaly Developed for CentralTECH

- 53 Páginas

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:~# here: 25 25/tcp: azrael:~# root postfix postfix root azrael:~# fuser 25/tcp 1546 ps -fea |grep 1546 1546 1 0 14:34 1549 1546 0 14:34 1550 1546 0 14:34 2439 2432 0 15:53

? ? ? pts/12

00:00:00 00:00:00 00:00:00 00:00:00

/usr/lib/postfix/master pickup -l -t fifo -u -c qmgr -l -t fifo -u -c grep 1546

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 tcp 0 tcp 0 1571/xinetd tcp 0 1280/portmap -anp |grep LISTEN | more 0 0.0.0.0:62209 0 0.0.0.0:110 0 0.0.0.0:111 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* LISTEN LISTEN LISTEN 1940/wish

- 27 (*) Originaly Developed for CentralTECH

- 53 Páginas

tcp 0 0 0.0.0.0:21 1575/ftpd: acceptin tcp 0 0 0.0.0.0:22 tcp 0 0 0.0.0.0:25 1546/master

0.0.0.0:* 0.0.0.0:* 0.0.0.0:*

LISTEN LISTEN LISTEN 1555/sshd

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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.20 appears to be up. Host 192.168.0.29 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 Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-11 17:05 ART Host 192.168.0.1 appears to be up. Host 192.168.0.20 appears to be up. Host 192.168.0.29 appears to be up. 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 Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-11 17:12 ART 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 Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-11 17:25 ART

- 29 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 0.787 seconds 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 Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-11 18:26 ART 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 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) Nmap run completed -- 1 IP address (1 host up) scanned in 5.028 seconds 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-11 23:50 ART 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 Adding open port 22/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 Interesting ports on 192.168.0.1: PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 3128/tcp closed squid-http Device type: general purpose Running: Linux 2.4.X OS details: Linux 2.4.20 - 2.4.22 w/grsecurity.org patch Uptime 35.421 days (since Sun Mar 7 13:43:26 2004) TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) IPID Sequence Generation: Randomized Nmap run completed -- 1 IP address (1 host up) scanned in 4.809 seconds azrael:~# nmap -v -sS -O -p 22,53,3128 192.168.0.1 Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-11 23:50 ART 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 Adding open port 22/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 Interesting ports on 192.168.0.1: PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 3128/tcp closed squid-http Device type: general purpose Running: Linux 2.4.X OS details: Linux 2.4.20 - 2.4.22 w/grsecurity.org patch Uptime 35.421 days (since Sun Mar 7 13:43:26 2004) TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) IPID Sequence Generation: Randomized Nmap run completed -- 1 IP address (1 host up) scanned in 4.809 seconds

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 Password DN Rules : usuario_de_prueba : prueba : :

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 nessusrmuser.

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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

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 alumno servidorvpn alumno

IP addresses *

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

## 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 chapsecrets. 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

-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 [**] [121:4:1] Portscan detected from 200.32.96.124 Talker(fixed: 7 sliding: 30) Scanner(fixed: 0 sliding: 0) [**] 05/08-23:24:43.460715 [**] [121:4:1] Portscan detected from 200.31.96.122 Talker(fixed: 30 sliding: 53) Scanner(fixed: 0 sliding: 0) [**] 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 tcp tcp tcp tcp tcp tcp tcp tcp 0 0 0 0 0 0 0 0 0 0 0.0.0.0:1 0 0.0.0.0:20034 0 0.0.0.0:32771 0 0.0.0.0:32772 0 0.0.0.0:40421 0 0.0.0.0:32773 0 0.0.0.0:32774 0 0.0.0.0:31337 0 0.0.0.0:6667 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* LISTEN 14463/portsentry LISTEN 14463/portsentry LISTEN 14463/portsentry LISTEN 14463/portsentry LISTEN 14463/portsentry LISTEN 14463/portsentry LISTEN 14463/portsentry LISTEN 14463/portsentry 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

¿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. eth0 Link encap:Ethernet HWaddr 52:54:05:F3:95:01 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. eth0 Link encap:Ethernet HWaddr 52:54:05:F3:95:01 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

*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 tcp6 0 0 127.0.0.1:1152 tcp6 0 0 :::22

192.168.0.1:22 ESTABLISHED2889/ssh :::* LISTEN 2889/ssh :::* 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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

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 (*) Originaly Developed for CentralTECH

- 53 Páginas

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->