Administracion e Instalacion de Servidores Linux - Debian Sarge 3 1 - by Jose Antonio Escartín

Memoria del Proyecto
—–
Servidor Linux
para conexiones seguras de una LAN a Internet
—–
Jose Antonio Escartı́n Vigo
Junio de 2005
Introducción
En las siguientes lı́neas trato de describir los motivos que me llevaron a escoger un proyecto de este
estilo y de donde surgió la idea de realizar un documento informativo para facilitar la tarea de muchos
administradores de sistemas “noveles”, como yo cuando comencé este proyecto.
En esta pequeña introducción también se especifican los objetivos que se pretenden conseguir y para
entrar en materia se comenta, muy por encima, la historia de Linux.
Motivación
Me decidı́ a realizar este proyecto por la inquetud personal que tenı́a respecto al sistema operativo
Linux. Conozco a mucha gente que lo maneja y que me hablaba muy bien, por pereza y falta de tiempo,
nunca me habı́a puesto a experimentar a fondo con él. Si bien es cierto que lo tenı́a instalado (una versión
Mandrake 9.0) lo utilizaba solamente para realizar las prácticas de la universidad y poca cosa más.
Siempre me han atraı́do los sistemas operativos, bastante más que la rama de programación. Una
prueba de ello es que cuando llege a la FIB (vine del Ciclo formativo de grado superior: Desarrollo de
aplicaciones informaticas; es decir, básicamente programación) me cambié a la rama de sistemas.
Actualmente me encuentro cursando el PFC de la Ingenierı́a técnica en Informática de Sistemas y
tengo la intención de solicitar plaza de admisión en la Ingenierı́a superior de informática, carrera a la que
no pude acceder en primera instancia por restricciones legales, al acceder a la universidad por la vı́a de
los ciclos formativos de grado superior.
A lo largo de la carrera, he cursado las siguientes asignaturas relacionadas con los sistemas operati-
vos: ISO (Introducción a los sistemas operativos), SO (Sistemas Operativos), ASO (Administración de
sistemas operativos), CASO (Conceptos avanzados de sistemas operativos), SSI (Seguridad en sistemas
informáticos). Además hace unos años, antes de comenzar la carrera, realizaba trabajos de administrador
de sistemas en entornos Windows, para dos institutos (IES Pirámide y IES Sierra de Guara) de mi ciudad
natal, Huesca.
El PFC: “Servidor Linux para conexiones seguras de una LAN a Internet” me ha permitido desarrollar
amplios conocimientos en el campo de los sistemas operativos, algo que realmente me interesa y supongo
que me permitirá encarrilar mi carrera hacia el trabajo que pretendo desarrollar como Administrador de
sistemas.
Si en vez de elegir uno de los proyectos propuestos desde la universidad, hubiera pensado proponer
uno, sin duda habrı́a elegido hacer un proyecto igual al que propuso el profesor Lluı́s Pérez Vidal del
departamente LSI de la UPC. Me siento bastante afortunado de haber realizado un PFC que realmente
me interesaba y motivaba.
vi Servidor Linux para conexiones seguras de una LAN a Internet
Motivación del proyecto

Ante el problema de instalar un sistema operativo que controle los servicios de red y además sea estable
se nos plantean principalmente dos alternativas, Linux o Windows.
¿Qué ventajas tiene Linux sobre Windows?

Es más seguro.
Ya que la gran mayorı́a de los ataques de hackers son dirigidos a servidores Windows al igual que
los virus los cuales se enfocan principalmente a servidores con éste sistema operativo. La plataforma
Linux es más robusta lo cual hace más difı́cil que algún intruso pueda violar la seguridad del sistema.
Es más rápido.
Al tener una plataforma más estable, se favorece la utilización de aplicaciones de todo tipo de
aplicaciones. La eficiencia de su código fuente hace que la velocidad de las aplicaciones Linux sean
superiores a las que corren sobre Windows.
Es más económico.
Ya que requiere menor mantenimiento. Los servidores Windows son más costosos debido a que es
necesaria una frecuente atención y monitoreo contra ataques de virus, hackers y errores de código.
El software Linux ası́ como también un sin número de aplicaciones, son de código abierto y están
protegidas por la licencia GPL1 , motivo por el que son distribuidas gratuitamente. No requieren
supervisión constante ni pagos de mantenimiento para obtener Service Packs, que no son más que
parches de seguridad para aplicaciones mal diseadas.
¿Qué ventajas tiene Windows sobre Linux?
Es más fácil.
Al ser de mayor facilidad de uso Windows en este momento continúa siendo el sistema operativo más
comercial lo cual se refleja en la disponibilidad de aplicaciones, facilidad de mantenimiento ası́ como
soporte en el desarrollo de nuevas aplicaciones.
Las aplicaciones se desarrollan en menor tiempo.

Fruto de la inversión realizada por Microsoft y aunado a una comunidad de programadores cada vez
más grande se ha logrado facilitar el desarrollo de aplicaciones y sistemas que corran sobre servidores
Windows lo cual se ve reflejado en tiempos de desarrollo menores. De la misma forma, la curva de
aprendizaje en el sistema Windows es mucho menor.
La alternativa más sencilla y a la vez más ineficiente es elegir un sistema operativo Windows. Lo que
se busca es seguridad, integridad de datos y eficiencia del sistema, por tanto nos decantarémos por una
distribución GNU/Linux.
El proyecto surge ante la necesidad de escoger entre las distribuciones Linux actuales, la más adecuada
para instalar un servidor e implementar las aplicaciones necesarias para dar servicios a clientes de sistemas
operativos Linux y Windows.
Esto es algo no trivial y el proyecto trata de ser una ayuda, apoyo y consulta para facilitar la tarea de
una persona que trate de implementar un servidor.
1 GPL: Licencia pública GNU. Según se cita en [Sha01] expecifica explı́citamente que el software desarrollado es libre y
que nadie puede coartar estas libertados. Se puede revender, incluso obteniendo beneficio; sin embargo, en esa reventa el
vendedor debe de proveer el código fuente completo, incluyendo cualquier modificación realizada. El paquete continua bajo
GPL y puede ser distribuido de modo libre y revendido de nuevo obteniendo también beneficio. Es de una importancia
primordial la cláusula de responsabilidad: los programadores no son responsables de cualquier daño causado por su software.
Jose Antonio Escartı́n Vigo, Junio 2005.

vii
Objetivos
Este documento está elaborado para describir la implementación de un servidor GNU/Linux, ası́ como
especificar y resolver los principales problemas que un administrador se encuentra al poner en funcio-
namiento un servidor. Se aprenderá a configurar un servidor GNU/Linux describiendo los principales
servicios utilizados para compartir archivos, páginas web, correo y otros que veremos más adelante.
La herramienta de configuración Webmin, que se detalla en uno de los últimos capı́tulos es indepen-
diente de la distribución GNU/Linux que utilicemos y nos permitirá administrar de forma transparente
diferentes distribuciones, con la ventaja que eso supone si alguna vez cambiamos de distribución.
Cuadro 1: Objetivos del proyecto
Estudiar el entorno de composición de textos LATEX
Analizar e instalar las distribuciones Linux más importantes

Estudiar la compilación de kernels
Analizar y configurar los servicios para usuarios Linux y Windows
Establecer sistemas de protección
Realizar pruebas de seguridad del servidor

Documentar el proyecto
Marco histórico
Como se especifica en [BB00], Linux hizo su aparición en 1991 cuando el finlandés Linus Torvalds deci-
dió publicar en Internet su proyecto de carrera, animando a la comunidad internacional de programadores
a mejorarlo. Nació como una mejora de Minix, una versión de Unix para ordenadores PC basados en el
procesador 8086 de Intel, Linux por su parte utilizaba el procesador 386SX de Intel.
Posiblemente una de las explicaciones del éxito de Linux es GNU1 que junto con la FSF2 (Free Software
Fundation), tratan de promover el desarrollo de programas cuyo código sea público y compartido. Una de
las principales aportaciones GNU fue Linux, un sistema operativo de libre distribución.
A partir de 1994 emperzaron a aparecer las primeras distribuciones de CD-ROM, junto con el código
fuente del sistema operativo, se disponı́a de diversas utilidades y aplicaciones sin tener que descargarlas.
Ese año aparecieron los primeros grupos locales de usuarios de Linux y la primera revista on-line especia-
lizada. Al año siguiente se empezó a trabajar en las primeras versiones de Linux para plataforma no Intel
y los primeros desarrollos de instaladores parcialmente automáticos. A partir de 1996 Linux comienza a
difundirse de forma más general en España, año en el que se inicia el proyecto de documentación de Linux
en catellano (LUCAS) y se comienzan a organizar los primeros grupos de usuarios.
El futuro es muy prometedor, cada vez es mayor el número de fabricantes de software y hardware que
han mostrado un creciente interés.
1 GNU: GNU no es Unix. Definición recursiva que representa el humor informático en su máxima expresión
2 FSF: Fundación para el software libre. Es el principal contribuidor del Proyecto GNU, depende de donaciones privadas y
se dedica a preservar, proteger y promover los derechos de los usuarios y su libertad para usar, estudiar, copiar, modificar y
redistribuir software. Apoya la libertad de expresión, prensa y asociación en internet, el derecho a usar software criptográfico
en comunicaciones privadas y el derecho a escribir software sin los impedimentos del monopolio.

viii Servidor Linux para conexiones seguras de una LAN a Internet
Requisitos mı́nimos Linux

Probablemente la configuración mı́nima sobre la que Linux sea capaz de funcionar sea un 386SX con 2
Mb de memoria RAM y una disquetera de 1.44, aunque con estas caracterı́sticas simplemente podremos
arrancar el sistema y poco más. Una configuración más realista deberı́a incluir 4Mb de Ram si no vamos
a utilizar el entorno gráfico, 8Mb en caso contrario y un mı́nimo de 40MB de espacio en disco, aunque
en las distribuciones actuales el espacio deberı́a ser mayor de unos 300Mb. Cantidades ridı́culas si las
comparamos con los dispositivos disponibles actualmente, pero que permiten reutilizar materiales más
antiguos de los que se pueda disponer. Frente a estos requerimientos, se encuentran los sistemas Windows,
con unos requerimientos1 desorbitados.
Linux soporta cualquier CPU compatible con los procesadores x86 de Intel, pudiéndose encontrar
versiones que funcionan con procesadores 680x0 de Motorola utilizados en ordenadores Amiga y Atari.
También son compatibles con Linux muchos ordenadores basados en Alpha, ciertas máquinas Sparc, las
máquinas basadas en PowerPC como por ejemplo los ordenadores Macintosh de Apple, ası́ como ARM,
MIPS y algunos tipos de agendas electrónicas, teléfonos y consolas de juegos.
Notas Previas
Se van a tomar varias la siguiente notación para el documento:
Cuando aparezcan frases que el usuario pueda introducir por teclado se hará notar por el tipo de
letra mecanográfica, Verbatim
Al hacer referencia a un comando que deba de ser introducido por una cuenta con privilegios de
root, irá precedido por el carácter “#”
Al hacer referencia a un comando que puede a ser ejecutado por un usuario cualquiera del sistema,
si tiene privilegios para ello, irá precedido por el carácter “$”
Cuando se muestran códigos el carácter “#” al inicio de la frase especifica que esa frase concreta es
un comentario dentro del código.
1 WindowsXP: Procesador 233Mhz, 64Mb Ram y 1.5 Gb de disco; Windows2003 Server: Procesador 550Mhz, 256Mb Ram
y 1.5 Gb de disco

Índice general
Introducción IV
I Tareas previas 1
1. Planificación 3
1.1. Fases del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Esquema temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Selección de Herramientas 9
2.1. Selección de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2. Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Selección de la distribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Distribuciones Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3. Distribución elegida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Selección del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1. Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2. LATEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3. Kile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.4. Prosper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.5. Programas gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II Instalación base 19
3. Instalación de la distribución 21
3.1. Proyecto Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1. Unstable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.3. Stable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.4. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Debian Sarge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Debian Woody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. Actualización de Woody a Sarge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4. Primeros pasos 25
4.1. Particionar el disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2. Gestores de arranque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3. Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1. Añadir nuevos usuarios al sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2. Añadir grupos al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
x Servidor Linux para conexiones seguras de una LAN a Internet
4.3.3. Bases de datos de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4. Permisos de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4.1. Tipos de archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4.2. Modificar los permisos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4.3. Permisos especiales: SUID, SGID y bit de persistencia . . . . . . . . . . . . . . . . 32
4.4.4. Cambiar un archivo de propietario o grupo . . . . . . . . . . . . . . . . . . . . . . 33
4.5. Instalación de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.1. Compilación de paquetes desde archivos fuente . . . . . . . . . . . . . . . . . . . . 33
4.5.2. Dpkg: Instalador de paquetes precompilados . . . . . . . . . . . . . . . . . . . . . . 36
4.5.3. Apt: Gestor de paquetes Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5.4. Alien: Convertir paquetes .rpm a .deb (formato Debian) . . . . . . . . . . . . . . . 38
4.5.5. Encontrar paquetes y sus dependencias . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5.6. Problemas al instalar paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6. Shells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6.1. Tipos de shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.6.2. Caracterı́sticas de la shell Bash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.6.3. Ejecución de procesos en la shell Bash . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6.4. Variables de entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6.5. Configuración del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.6.6. Redireccionamientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.7. Consolas virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5. Kernel 45
5.1. ¿Por qué compilar? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2. Acerca de los módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3. Kernel-image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4. Kernel-source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4.1. Instalar un kernel-source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4.2. Crear un paquete .deb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5. Compilar Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5.1. Paquetes necesarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5.2. Comprobar el hardware disponible . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.3. Método de compilación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.4. Parchear el kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5.5. Consejos para la configuración del kernel . . . . . . . . . . . . . . . . . . . . . . . . 49
6. Interfaz gráfico 51
6.1. X-Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.1. Configuración X-Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.2. Arrancar X-Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2. Gestores de ventanas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3. Entornos de escritorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.1. Kde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.2. Gnome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.3. Otros entornos de escritorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7. Infraestructura de redes 59
7.1. Arquitectura de redes (Modelo OSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.2. Direcciones IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2.1. Datagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2.2. Encaminamiento IP (router y gateway) . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2.3. Máscaras de red y notación de barra inclinada . . . . . . . . . . . . . . . . . . . . 64
7.2.4. Subneting (CIDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2.5. Enmascaramiento IP (NAT, Network Adress Translation) . . . . . . . . . . . . . . 66
7.3. Resolución de direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Índice general xi
7.3.1. ARP (Adress Resolution Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.3.2. RARP (Reverse Address Resolution Protocol) . . . . . . . . . . . . . . . . . . . . . 68
7.4. Protocolos de red, IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.4.1. ICMP (Internet Control Message Protocol) . . . . . . . . . . . . . . . . . . . . . . 69
7.4.2. OSPF (Open Shortest Path First) . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.4.3. Protocolo BGP (Border Gateway Protocol) . . . . . . . . . . . . . . . . . . . . . . 70
7.4.4. IGMP (Internet Group Management Protocol) . . . . . . . . . . . . . . . . . . . . 70
7.5. Protocolos de transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.5.1. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.5.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.6. Protocolos de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.6.1. NFS (Network File System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.6.2. SNMP (Simple network management protocol) . . . . . . . . . . . . . . . . . . . . 74
7.6.3. DNS (Domain Name Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.6.4. SMTP (Simple Mail Transfer Protocol) . . . . . . . . . . . . . . . . . . . . . . . . 74
7.6.5. TELNET (Remote login) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.6.6. FTP (File Transfer Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.6.7. HTTP (Hyper Text Transport Protocol) . . . . . . . . . . . . . . . . . . . . . . . . 75
7.7. Protocolo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8. Configuración de dispositivos de red 79

8.1. Etherconf: Configurador gráfico de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.2. Ifconfig: Configurador de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.3. Route: Tablas de redireccionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.4. Netstat: Estado de las conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.5. Configuración de interfaces usando DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.6. Archivo /etc/network/interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.6.1. Direcciónes IP estáticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.6.2. Direcciones IP dinámicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.6.3. Interfaz Wifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.6.4. Interfaz PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.6.5. Puertas de enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.6.6. Interfaces virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.7. Reconfiguración de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.7.1. Configuración de red durante el arranque . . . . . . . . . . . . . . . . . . . . . . . 87
8.7.2. Hotplug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.7.3. Ifplugd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.8. Resolvconf: Resolución de nombres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.9. Archivos de configuración de Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.10. Iwconfig: Configuración wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.11. Resolución de problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
III Instalación de Servicios 91

9. Servicios de red 93
9.1. Servidor DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.1.1. Asignación de direcciones IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.1.2. Parámetros configurables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.3. Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.4. Anatomı́a del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.5. Configuración de un servidor DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.1.6. Configuración de un cliente DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
9.1.7. Configuración gráfica de DHCP, interfaz Webmin . . . . . . . . . . . . . . . . . . . 99
9.2. BIND: Servidor de nombres DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

xii Servidor Linux para conexiones seguras de una LAN a Internet
9.2.1. ¿Para qué necesitamos un DNS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

9.2.2. Servicios que activa un DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.2.3. Configuración del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.2.4. Traducción de nombres a direcciones IP . . . . . . . . . . . . . . . . . . . . . . . . 103
9.2.5. Configuración gráfica de DNS BIND, interfaz Webmin . . . . . . . . . . . . . . . . 103
9.2.6. Seguridad en DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.3. NIS: Servicio de información de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.3.1. Funcionamiento básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.3.2. Servidores NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.3.3. Configuración del servidor NIS maestro . . . . . . . . . . . . . . . . . . . . . . . . 110
9.3.4. Cliente NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.3.5. Herramientas básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
9.3.6. Problemas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
9.4. NFS: Sistema de archivos Linux en red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
9.4.1. Cliente NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
9.4.2. Montaje automático de particiones NFS . . . . . . . . . . . . . . . . . . . . . . . . 118
9.4.3. Propiedades de las particiones montadas . . . . . . . . . . . . . . . . . . . . . . . . 118
9.4.4. Servidor de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9.4.5. Configuración gráfica de NFS, interfaz Webmin . . . . . . . . . . . . . . . . . . . . 120
9.5. Samba: Servicio de conexiones para sistemas Microsoft . . . . . . . . . . . . . . . . . . . . 121
9.5.1. Compartición de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
9.5.2. ¿Qué es Samba? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
9.5.3. Configuración gráfica de Samba, interfaz SWAT . . . . . . . . . . . . . . . . . . . . 123
9.5.4. Funcionamiento de CIFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
9.5.5. Parámetros globales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
9.5.6. Impresoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.5.7. Compartición de directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.5.8. Limitar acceso de los usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.5.9. Integración de Samba en un dominio NT . . . . . . . . . . . . . . . . . . . . . . . 127
9.5.10. Configuración de Samba como controlador de dominio . . . . . . . . . . . . . . . . 128
9.5.11. Cliente Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
9.5.12. Configuración gráfica de Samba, interfaz Webmin . . . . . . . . . . . . . . . . . . . 129
9.6. ProFTPD: Servidor FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.6.1. Servidor ProFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.6.2. Configuración gráfica de ProFTP, interfaz Webmin . . . . . . . . . . . . . . . . . . 132
9.6.3. Clientes FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
10.Servicios de usuario 133

10.1. Cuotas de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
10.1.1. Arrancar el sistema de cuotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
10.1.2. Asignar cuotas a los usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
10.1.3. Configuración gráfica de Quote, interfaz Webmin . . . . . . . . . . . . . . . . . . . 134
10.2. Cups: Servidor de impresión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
10.2.1. Servidor Cups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
10.2.2. Servidor Cups para Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
10.2.3. Clientes Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
10.2.4. Clientes Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
10.2.5. Solucionar problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
10.3. Servidor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
10.3.1. Servidor Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
10.3.2. Apache-SSL: Conexiones seguras . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
10.3.3. Creación de un servidor web seguro . . . . . . . . . . . . . . . . . . . . . . . . . . 152
10.3.4. Apache 2.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
10.3.5. Ataques al servidor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Índice general xiii
10.4. Servidor de correo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

10.4.1. Exim: Correo corporativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.4.2. Fetchmail: Correo externo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
10.4.3. Horde: Webmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
10.4.4. Protocolo IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
10.4.5. Filtrado de correo, eliminar virus y Spam con Procmail . . . . . . . . . . . . . . . 163
10.4.6. ClamAV: Antivirus para correo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
10.4.7. SpamAssassin: Filtro basado en reglas . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.4.8. Bogofilter: Filtro bayesiano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
10.5. Jabber: Mensajerı́a instantánea para corporaciones . . . . . . . . . . . . . . . . . . . . . . 172
10.5.1. Servidor Jabber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
10.5.2. Configuración gráfica de Jabber, interfaz Webmin . . . . . . . . . . . . . . . . . . . 174
10.5.3. Clientes Jabber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
11.Comunicaciones seguras 177

11.1. Shell seguro: OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
11.1.1. Cliente OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
11.1.2. Servidor OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
11.2. Criptografı́a y cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
11.2.1. Tipos de cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
11.2.2. Estándares generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
11.2.3. Aplicaciones de la criptografı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
11.2.4. Protocolos de cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
11.2.5. OpenPGP: Aplicación de cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
12.Herramientas de seguridad 191

12.1. Herramientas básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
12.1.1. Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
12.1.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
12.1.3. Whois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
12.1.4. Dig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
12.1.5. Finger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
12.2. Firewall o cortafuegos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
12.2.1. Polı́ticas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
12.2.2. Modos de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
12.2.3. IPTables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
12.3. Squid: Proxy transparente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
12.4. Bastille Linux: Herramienta de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
12.4.1. Ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
12.4.2. Modos de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
12.5. Copias de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
12.5.1. Dispositivos de cinta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
12.5.2. Mt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
12.5.3. Dump y Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
12.5.4. Configuración gráfica de backups, interfaz Webmin . . . . . . . . . . . . . . . . . . 210
12.5.5. K3B: Grabación de CDs y DVDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
13.Sistemas de detección de intrusiones 213

13.1. Tipos de IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
13.1.1. NIDS (Network Intrusion Detection System) . . . . . . . . . . . . . . . . . . . . . 213
13.1.2. IDS (Detección de actividades anómalas) . . . . . . . . . . . . . . . . . . . . . . . 214
13.1.3. IPS (Intrusion Prevention System) . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
13.2. Ubicación del NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
13.3. El problema de los falsos positivos de NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . 215
13.4. Obtener lo máximo del IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

xiv Servidor Linux para conexiones seguras de una LAN a Internet
13.4.1. Configuración apropiada del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 217

13.4.2. Ajuste del IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
13.4.3. Herramientas de análisis IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
13.5. IDS Snort (NIDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
13.5.1. Caracterı́sticas básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
13.5.2. Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
13.5.3. Modos de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
13.5.4. Modos de alerta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
13.5.5. Optimizar la configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
13.5.6. Clases de reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
13.5.7. Ejecutar como servicio del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
13.5.8. Configuración gráfica de Snort, interfaz Webmin . . . . . . . . . . . . . . . . . . . 226
13.5.9. Personalizar reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
13.6. Detección de intrusiones en el host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
13.7. Integridad de archivos: IDS Tripwire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
13.8. ACIDlab: Analizar alertas IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
13.9. Logcheck: Analizar logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
13.10.PortSentry: Detectar escaneos de puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
13.11.Detectores de sniffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
13.11.1.Neped . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
13.11.2.Sentinel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
13.12.Chkrootkit: Detector de rootkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
13.13.HoneyPots: Entretener a los atacantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
13.13.1.¿Cómo funcionan? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
13.13.2.Ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
13.13.3.Utilidades de honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
13.13.4.Tipos de honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
13.13.5.Otras caracterı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
13.13.6.Honeynets: alta interacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
13.13.7.Honeyd: baja interacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
14.Redes inalámbricas 257

14.1. Estándar 802.11 (Wifi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
14.2. Peligros de las LAN inalámbricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
14.3. El fenómeno del “Wardriving” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
14.4. Seguridad en redes inalámbricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
14.4.1. Clave WEP (Wired Equivalente Privacy) . . . . . . . . . . . . . . . . . . . . . . . 262
14.4.2. Clave WPA (Wifi Protected Access) . . . . . . . . . . . . . . . . . . . . . . . . . . 262
14.4.3. Clave WPA2 (Estándar 802.11i) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
14.4.4. Medidas preventivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
14.5. Servidor Radius: FreeRadius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
14.5.1. Configurar FreeRadius con EAP-TLS . . . . . . . . . . . . . . . . . . . . . . . . . 267
14.5.2. Generar los certificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
14.5.3. Comprobar el funcionamiento de FreeRadius . . . . . . . . . . . . . . . . . . . . . 270
14.5.4. Configurar AP (Router 3Com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
14.5.5. Clientes Linux: WPA-Supplicant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
14.5.6. Clientes Windows: WindowsXP + SP2 . . . . . . . . . . . . . . . . . . . . . . . . . 272
14.6. Herramientas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
14.6.1. Descubrir redes ilegales e intrusos: Kismet Wireless . . . . . . . . . . . . . . . . . . 273
14.6.2. Desencriptar claves inalámbricas WEP: Airsnort . . . . . . . . . . . . . . . . . . . 275
15.Servicio de administración por Web: WebMin 279

15.1. Usuarios de Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
15.2. Secciones Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
15.3. Módulos de Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Índice general xv
16.Servicios de monitorización del sistema 287

16.1. Monitor del sistema: Top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
16.2. Rendimiento del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
16.2.1. CPU, dispositivos y particiones de E/S: iostat . . . . . . . . . . . . . . . . . . . . . 288
16.2.2. Memoria: free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
16.2.3. Memoria virtual: vmstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
16.2.4. Disco: df, du . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
16.2.5. Usuarios y sus procesos: w . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
16.3. Gestionar procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
16.3.1. Visualizar procesos: ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
16.3.2. Enviar signals a procesos: kill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
16.3.3. Modificar prioridades: nice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
16.4. Terminal de root con prioridad máxima . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
16.5. Programación de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
16.5.1. At . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
16.5.2. Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
16.5.3. Tareas periódicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
16.5.4. Anacron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
IV Valoración final 297

17.Pruebas del sistema 299
17.1. Nessus: Escáner de vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
17.1.1. Configurar el programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
17.1.2. Ejecución de Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
17.1.3. Otros interfaces de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
17.2. Nmap: Escáner de red y puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
17.2.1. Caracterı́sticas básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
17.2.2. Tipos de escaneado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
17.2.3. Opciones de descubrimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
17.2.4. Opciones de ajuste de frecuencia de Nmap . . . . . . . . . . . . . . . . . . . . . . . 305
17.2.5. Otras opciones de Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
17.2.6. Salida de Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
17.2.7. Configuración gráfica de Nmap, interfaz Nmapfe . . . . . . . . . . . . . . . . . . . 307
17.3. Pruebas de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
18.Estudio Económico 309

18.1. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
18.2. Costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
18.3. Resumen económico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
18.4. Modificaciones a los costes económicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
19.Conclusiones 311
V Apéndices 315
A. Comandos básicos 317
B. Debian en castellano 319
C. Archivos de configuración 321
D. ¿Por qué Debian no tiene rc.local ? 325

xvi Servidor Linux para conexiones seguras de una LAN a Internet
E. Puertos por defecto 327
F. Manual del editor Vim (Vi mejorado) 329
G. Guı́a rápida de IPTables 331
Debian Sarge, nueva versión estable 333
Licencia CC - Reconocimiento-CompartirIgual 335
Páginas Web 339
Bibliografı́a 343

Índice de figuras
1.1. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Planner, distribución de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2. Planner, diagrama temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3. Editor Kile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4. Prosper, tipos de transparencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. IP, rango de direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.2. IP, direcciones reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3. IP, cabecera del datagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.4. UDP, cabecera del datagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.5. TCP, cabecera del datagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.1. DHCP, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

9.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.4. DNS BIND, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
9.9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
9.10. NIS, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.11. NFS, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
9.12. Samba, interfaz gráfica SWAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
9.13. Samba, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.14. ProFTPD, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
10.1. Quota, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

10.2. Cups, interfaz gráfica de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
10.3. Cups, impresora HP815 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
10.4. Apache, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
10.5. Apache, parametros de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
10.6. Apache, módulo HtAccess Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
10.7. Webalizer, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10.8. Apache, servidores virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
10.9. Apache, compartición de carpetas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
10.10.Apache, módulos instalados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
10.11.Exim, monitor con la interfaz Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
10.12.Fetchmail, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
xviii Servidor Linux para conexiones seguras de una LAN a Internet
10.13.Procmail, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

10.14.Procmail, crear acciones de forma gráfica . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
10.15.SpamAssassin, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
10.16.SpamAssassin, opciones de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
10.17.Jabber, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
10.18.Kopete, cliente de mensajerı́a instantánea . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
10.19.Gaim, cliente de mensajerı́a instantánea . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
11.1. SSHD, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
12.1. Backups, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

12.2. K3B, grabación de CDs y DVDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
13.1. Snort, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

13.2. Acidlab, detalle de una alerta de Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
13.3. Logcheck, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
13.4. PortSentry, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
14.1. Sı́mbolos urbanos de redes wifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

14.2. WEP-WPA, comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
14.3. WPA/EAP, funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
14.4. WPA, autenticación servidor Radius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
14.5. Servidor Radius, sistema de autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
14.6. Servidor Radius, desvı́o en el router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
14.7. AirSnort, descifrado de claves WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
15.1. Webmin, pantalla de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

15.2. Webmin, pantallas de la interfaz Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
15.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
17.1. Nessus, configuración de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

17.2. Nessus, vulnerabilidades del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
D.1. Runlevels, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
G.1. Licencia Reconocimiento-CompartirIgual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Índice de cuadros
1. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
2.1. Distribuciones Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Lilo, archivo de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2. /etc/passwd, ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3. /etc/passwd, descripción de campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4. /etc/shadow, ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5. /etc/shadow, descripción de campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6. /etc/group, ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7. /etc/group, descripción de campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.8. Tipos de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.9. Chmod, Opciones básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.10. Chmod, opciones especiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.11. Makefile, ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.12. Dpkg, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.13. /etc/apt/sources.list, ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.14. Apt, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.15. Variables habituales del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1. Kernel, paquetes básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2. Kernel 2.6, paquetes necesarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3. Método de compilación del kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1. /etc/X11/XF86Config-4, ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.1. Modelo de referencia OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.2. Tipos de redes, n.o de hosts por red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3. Notación de barra inclinada en IPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.4. TCP/IP, ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.5. TCP/IP, esquema de transmisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.1. Netstat, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.1. /var/yp/Makefile, ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
10.1. Apache, archivos de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
11.1. SSH cliente, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
12.1. Ping, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

12.2. Dig, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
12.3. IPTables, especificaciones de reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
12.4. IPTables, comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
12.5. IPTables, ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
xx Servidor Linux para conexiones seguras de una LAN a Internet
12.6. /etc/squid/squid.conf, ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

12.7. Mt, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
12.8. Dump, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
12.9. Restore, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
13.1. Snort, opciones de alerta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

13.2. Snort, archivos de reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
13.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
13.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
13.5. Snort, opciones de personalización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
13.6. Tripwire, máscaras de propiedad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
13.7. Tripwire, máscaras predefinidas en plantillas . . . . . . . . . . . . . . . . . . . . . . . . . . 232
13.8. Acidlab, variables de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
13.9. PortSentry, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
14.1. Estándares 802.11 inalámbricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

14.2. Kismet, configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
14.3. Kismet, configuración de la interfaz gráfica . . . . . . . . . . . . . . . . . . . . . . . . . . 274
14.4. Kismet, teclas de la interfaz gráfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
15.1. Webmin, módulos disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
16.1. Ps, opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
17.1. Nmap, tipos de escaneo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

17.2. Nmap, opciones de descubrimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
17.3. Nmap, configuraciones de frecuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
17.4. Nmap, otras opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
17.5. Nmap, codificación de color de la salida . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
18.1. Recursos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

18.2. Costes del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

Parte I
Tareas previas
Capı́tulo 1
Planificación
El número de créditos asignados al proyecto es de 22,5 y decidı́ que cada crédito me supondrı́a una
carga de 20 horas, por lo tanto, la planificación ha sido realizada para un total de 450 horas.
1.1. Fases del proyecto

Planificación temporal: 20 horas. Mediante la herramienta de gestión de proyectos Planner, se realiza
una división temporal de las actividades a realizar.
Trabajo preliminar: 40 horas. Se eligen una serie de herramientas y sistemas sobre los cuales se
desarrolla el proyecto.
Instalación base y configuración: 80 horas. Implementación y configuración del entorno de trabajo.

Configuración de los servicios: 120 horas. Basándose en los servicios tı́picos que implementan los
servidores de red, se instalan una serie de servicios estándar para clientes de sistemas operativos
Linux y Windows.
Pruebas del sistema y conclusiones: 30 horas. Apoyándose en una serie de pruebas de carga se deter-
mina la eficiencia real, de los servicios del servidor. Ası́ mismo se utilizan varias herramientas para
determinar la seguridad del servidor y comprobar su resistencia a posibles intrusiones o agresiones
externas.
Aprendizaje del entorno LATEX: 20 horas. A través de varios libros, que detallo en la bibliografı́a, se
aprende a utilizar el entorno de composición de textos LATEX para elaborar la documentación del
proyecto.
Documentación del proyecto: 140 horas. A lo largo del desarrollo de las fases anteriores se realizan
una serie de informes parciales que son la base de la memoria del proyecto.
1.2. Esquema temporal

Pese a la planificación inicial, en los siguientes esquemas se detallan la cronologı́a real que se siguió en
la elaboración del proyecto.
1 PFC: Proyecto fin de carrera

4 Servidor Linux para conexiones seguras de una LAN a Internet
Figura 1.1: Planificación (I)

Capı́tulo 1. Planificación 5
Figura 1.2: Planificación (II)

Figura 1.3: Planificación (III)

Capı́tulo 1. Planificación 7
Figura 1.4: Planificación (IV)

Capı́tulo 2
Selección de Herramientas
En este capitulo explicaré cuales fueron las diferentes herramientas utilizadas para la elaboración del
proyecto.
En una primera fase se determina el hardware donde se implementa el servidor y los diferentes
clientes utilizados en las pruebas
En la segunda fase se elige la distribución utilizada y los motivos que me llevaron a su elección
En la tercera fase se detalla qué herramientas de apoyo se usó para desarrollar los trabajos.
2.1. Selección de Hardware

Pese a que el director del proyecto me ofreció la utilización de material del departamento LSI de la
UPC, por mi comodidad, el material escogido fue de mi propiedad. Comprando una parte de él para
desarrollar de forma más eficiente las tareas.
2.1.1. Servidor
Como servidor me decidı́ por la compra de un ordenador portátil, que permitiera desarrollar un servidor
portable con más utilidades habituales en los servidores fijos, además de la ventaja de poder portar el
proyecto y trabajar en sitios diferentes. Con este sistema se permite a un grupo corporativo itinerante el
desarrollo de sus actividades en posibles reuniones fuera de su propio edificio. La conexión y seguridad del
sistema queda garantizada gracias al sistema de validación de clientes.
El portátil elegido fue un Acer TravelMate 4002 WLMI con procesador Intel Centrino a 1,6 Ghz.
con dos tarjetas de red integradas, una ethernet 10/100Mb y otra wifi 802.11g de 54Mb que permite sin
problemas establecer dos segmentos diferenciados de red. Uno para los usuarios de oficina, es decir los
usuarios fijos, y otro para los clientes wifi, dotando al sistema de mayor seguridad.
Se presentaron una serie de problemas directamente derivados de esta elección. El hardware era dema-
siado nuevo y esto provocó una serie de incompatibilidades que se fueron solucionando con la instalación
de drivers y parches que no se encontraban en las instalaciones Linux estándar.
El servidor realiza también la gestión de la conexión a internet. Esta conexión es suministrada, cuando
se encuentra fijo, por un router 3com conectado al switch de la red y que solo responde a las peticiones
del servidor.
2.1.2. Clientes
Como clientes se utilizarán varios PC’s de sobremesa, conectados mediante cable RJ45 a un switch.
PC AMD-Duron a 1,3 Ghz., también de mi propiedad, donde estará situado el principal cliente
Linux y Windows del sistema. En este ordenador se realizarón la mayoria de pruebas de conexión a
servicios.
PC AMD-Athlon a 1,2 Ghz. y PC AMD-Athlon a 2,4 Ghz. con clientes Windows, prestados.
Portatil Pentium-IV Mobile, con sistema Linux y Windows, para la pruebas de conexión de clientes
inalámbricos.
Los clientes se utilizaron simultáneamente para realizar las pruebas de carga una vez terminada la
implementación del servidor, para comprobar la efectividad del mismo.
2.2. Selección de la distribución

Completada la infraestructura hardware, comencé a leer sobre distribuciones de GNU/Linux, buscando
cuales eran las más adecuadas para desplegar servidores.
A continuación detallo los tipos de distribuciones valoradas:
Mepis y Ubuntu (basadas en Debian) son consideradas las mejores para aquellos usuarios nuevos
en Linux que quieren empezar a ser productivos lo antes posible, sin tener que aprender todas sus
complejidades, son distribuciones orientadas a usuario de escritorio.
En el lado opuesto tenemos a Gentoo, Debian y Slackware que son distribuciones más avanzadas
que requieren un completo aprendizaje antes de poder ser usadas eficientemente.
A medio camino entre ellas se encuentran Mandrake, Fedora (basada en Red Hat) y SuSE, estas dos
últimas son distribuciones comerciales.
Knoppix y Mepis-LiveCD (basadas en Debian) son un caso a parte, permiten probar Linux sin tener
que hacer nada, ya que funciona directamente del CD, sin ninguna instalación.
2.2.1. Distribuciones Linux
Cuadro 2.1: Distribuciones analizadas

SimplyMepis 3.3 - Mepis-LiveCD
Ubuntu (Warty Warthog 4.10)
Gentoo 2004.3 (FreeBSD)
Debian Woody 3.r04 - Sarge 3.1)
Debian Sarge 3.1)
Slackware 10.1
Mandrake 10.1
Fedora Core 3 (Red Hat)
SuSE
Knoppix 3.7
Mepis y Mepis-LiveCD
Fue lanzada por Warren Woodford en julio de 2003. Mepis Linux es una fusión entre Debian Sid
y Knoppix, una nueva clase de distribución de Linux que se pueda utilizar como CD en vivo, y como
distribución completa con un instalador gráfico a disco duro. De esta manera, usuarios pueden probar el
producto simplemente “booteando” desde el CD de Mepis, e instalándolo luego a disco duro solamente
si les gusta. Muchas otras distribuciones copiaron esta idea más adelante, pero fue Mepis quien inició el
concepto de un CD vivo más un instalador gráfico completo partiendo de un CD.
¿A que se debe el éxito de Mepis? A diferencia de la mayorı́a de las distribuciones principales de Linux,
Mepis viene con muchos paquetes que no son de uso-libre, pero altamente útiles, preconfigurados todos y

Capı́tulo 2. Selección de Herramientas 11
listos para utilizar. Éstos incluyen el driver de video Nvidia, el plugin Flash de Macromedia, Java, varios
codecs de multimedia para manejar archivos populares de audio y video y otros usos. Con Mepis Linux, no
hay necesidad de buscar el software para Java y después tener que buscar la documentación para descubrir
cómo permitir el uso de Java en sus navegadores. Todo está disponible después de la instalación.
Esta idea simple resultó ser enormemente popular, no solamente entre los usuarios nuevos de Linux,
sino también entre los más experimentados quienes encontraron muy conveniente el no tener que pasar
horas post-instalación configurando y afinando el sistema. Aparte de las aplicaciones estándard de Debian
y del software no-libre antes citado Mepis Linux tiene excelente auto-detección del hardware.
Ubuntu (Warty Warthog)

Ubuntu está basada en Debian, pero el planteamiento está inspirado en los principios de la corriente
ubuntu, un movimiento humanista encabezado por el obispo Desmond Tutu, premio Nobel de la Paz en
1984. Económicamente el proyecto se sostiene con aportaciones de la empresa Canonical del millonario
sudafricano Mark Shuttleworth.
El proyecto nació por iniciativa de algunos programadores de los proyectos Debian, Gnome y Arch
que se encontraban decepcionados con la manera de operar del proyecto Debian. La versión estable era
utilizada sólo por una minorı́a debido a la poca o nula vigencia que poseı́a en términos de la tecnologı́a
Linux actual.
Tras varios meses de trabajo y un breve perı́odo de pruebas, la primera versión de Ubuntu (Warty
Warthog) fue lanzada en el mes de octubre de 2004.
Los desarrolladores se esfuerzan en ofrecer una propuesta que corrija la problemática que advirtieron
en Debian. Las versiones estables se liberan al menos dos veces al año y se mantienen actualizadas.
Contribuye al proyecto Debian de manera continua debido a que ambas distribuciones comparten
colaboradores de manera oficial. El administrador de escritorio oficial es Gnome y el navegador oficial es
Mozilla Firefox. El sistema incluye funciones avanzadas de seguridad y entre sus polı́ticas se encuentra el
no activar procesos latentes por omisión al momento de instalarse.
Gentoo (FreeBSD)
Gentoo Linux fue creada por Daniel Robbins, un conocido desarrollador de Stampede Linux y FreeBSD.
La primera versión estable de Gentoo fu anunciada en Marzo del 2002.
Gentoo Linux es una distribución basada en código fuente. Mientras que los sistemas de instalación
proveen de varios niveles de paquetes pre-compilados, para obtener un sistema Linux básico funcionando,
el objetivo de Gentoo es compilar todos los paquetes de código en la máquina del usuario. La principal
ventaja de esto es que todo el software se encuentra altamente optimizado para la arquitectura de la
computadora.
También, actualizar el software instalado a una nueva versión es tan fácil como teclear un comando,
y los paquetes, mantenidos en un repositorio central, son actualizados a menudo. En la otra cara de la
moneda, instalar Gentoo y convertirla en una distribución completa, con los últimos entornos gráficos,
multimedia y de desarrollo es un trabajo largo y tedioso, puede durar varios dı́as incluso en una máquina
rápida.
Debian (Woody - Sarge)

Debian GNU/Linux inició su andadura de la mano de Ian Murdock en 1993. Debian es un proyecto
totalmente no-comercial; posiblemente el más puro de los ideales que iniciaron el movimiento del software
libre. Cientos de desarrolladores voluntarios de todo el mundo contribuyen al proyecto, que es bien dirigido
y estricto, asegurando la calidad de la distribución. En cualquier momento del proceso de desarrollo existen
tres ramas en el directorio principal: “estable”, en “pruebas” e “inestable” (también conocida como “sid”,
nombre que no varı́a). Actualmente la rama “estable” es Woody y la rama en “pruebas” es Sarge.
Cuando aparece una nueva versión de un paquete, se sitúa en la rama inestable para las primeras
pruebas, si las pasa, el paquete se mueve a la rama de pruebas, donde se realiza un riguroso proceso que
dura muchos meses. Esta rama sólo es declarada estable tras una muy intensa fase de pruebas.

Como resultado de esto, la distribución es posiblemente la más estable y confiable, aunque no la

más actualizada. Mientras que la rama estable es perfecta para servidores con funciones crı́ticas, muchos
usuarios prefieren usar las ramas de pruebas o inestable, más actualizadas, en sus ordenadores personales.
Debian es también famosa por su reputación de ser difı́cil de instalar, a menos que el usuario tenga
un profundo conocimiento del hardware de la computadora. Compensando este fallo está “apt-get” el
instalador de paquetes Debian. Muchos usuarios de Debian hacen bromas sobre que su instalador es tan
malo por que solo lo han de usar una vez, tan pronto como Debian está en funcionamiento, todas las
actualizaciones, de cualquier tipo pueden realizarse mediante la herramienta apt-get.
Slackware
Creada por Patrick Volkerding en 1992, Slackware Linux es la distribución más antigua que sobrevive
hoy en dı́a. No ofrece extras vistosos, y se mantiene con un instalador basado en texto, y sin herramientas
de configuración gráfica.
Mientras otras distribuciones intentan desarrollar intarfaces fáciles de usar para muchas utilidades
comunes, Slackware no ofrece nada amistoso, y toda la configuración se realiza mediante los archivos de
configuración. Es por esto que Slackware solo se recomienda a aquellos usuarios nuevos que deseen perder
el tiempo aprendiendo acerca de Linux.A pesar de todo, Slackware tiene una especie de aura mágica para
muchos usuarios.
Es extremadamente estable y segura, muy recomendada para servidores. Los administradores con
experiencia en Linux encuentran que es una distribución con pocos fallos, ya que usa la mayorı́a de paquetes
en su forma original, sin demasiadas modificaciones propias de la distribución, que son un riesgo potencial
de añadir nuevos fallos. Es raro que se produzcan lanzamientos de nuevas versiones (aproximadamente una
al año), aunque siempre se pueden encontrar paquetes actualizados para descargar después del lanzamiento
oficial. Slackware es una buena distribución para aquellos interesados en profundizar en el conocimiento
de las entrañas de Linux.
Posiblemente, la mejor caracterı́stica de esta distribución es que si necesitas ayuda con tu sistema
linux, encuentra un usuario de Slackware. Es más probable que resuelva el problema que otro usuario
familiarizado con cualquier otra distribución.
Mandrake
Creada por Gal Duval, Mandrake Linux es una distribución que ha experimentado un enorme aumento
de popularidad desde su primera versión de julio de 1998. Los desarrolladores partieron de la distribución
de Red Hat, cambiaron el entorno de escritorio predeterminado por KDE, y añadieron un instalador fácil
de usar rompiendo el mito de que linux es difı́cil de instalar. Las herramientas de detección de hardware
de Mandrake y sus programas para el particionamiento de discos son consideradas por muchos como las
mejores de la industria, y muchos usuarios se encontraron usando Mandrake allı́ donde otras distribuciones
no habı́an conseguido entregar la usabilidad necesaria.Desde entonces Mandrake Linux ha madurado y
se ha convertido en una distribución popular entre los nuevos usuarios de linux y aquellos hogares que
buscan un sistema operativo alternativo.
El desarrollo de Mandrake es completamente abierto y transparente, con paquetes nuevos que se añaden
al directorio llamado ”cooker“ a diario. Cuando una nueva versión entra en fase beta, la primera beta se
crea a partir de los paquetes que se encuentran en ”cooker“ en ese momento. El proceso de pruebas de
la beta solı́a ser corto e intensivo, pero desde la versin 9.0 ha pasado ha ser más largo y exigente. Las
listas de correo sobre la versión beta suelen estar saturadas, pero sigue siendo posible recibir una respuesta
rápida sobre cualquier fallo o duda que envı́es. Como resultado de este tipo de desarrollo se obtiene una
distribución puntera y altamente actualizada. Como contrapartida, los usuarios pueden encontrarse con
más fallos que en otras distribuciones.
Mucha gente encuentra este ’pero’ razonable para sus equipos, ellos obtienen las últimas versiones de
software y los cuelgues ocasionales de las aplicaciones es algo con lo que pueden vivir. Tan pronto como
el desarrollo se completa el software se pone a la libre disposición de la gente desde réplicas en todo el
mundo.

Fedora (Red Hat)
Para muchos el nombre de Red Hat equivale a Linux, ya que probablemente se trata de la compañı́a
de linux más popular del mundo. Fundada en 1995 por Bob Young y Marc Ewing, Red Hat Inc. Sólo ha
mostrado beneficios recientemente gracias a otros servicios en lugar de a la distribución en si. Aun ası́,
Red Hat es la primera elección para muchos profesionales y parece que seguirá siendo un peso pesado
durante mucho tiempo.
Afortunadamente se resistieron a realizar ningún plan de rápida expansión durante el boom de las
punto-com durante los años 1998-1999, concentrándose en su negocio principal. Este tipo de gestión
prudente si sigue ası́, es propensa a garantizar estabilidad y dependencia..
¿Qué hace a Red Hat Linux tan especial? Su curiosa mezcla de conservadurismo y paquetes punteros
mezclados con muchas aplicaciones desarrolladas en casa. Los paquetes no son los más actuales, una vez se
anuncia una nueva versión beta, las versiones de los paquetes se mantienen, excepto para actualizaciones
de seguridad. Como resultado se obtiene una distribución bien probada y estable. El programa de betas
y las facilidades para enviar fallos están abiertas al público y hay un gran espı́ritu en las listas de correo
públicas.
Red Hat Linux se ha convertido en la distribución linux dominante en servidores en todo el mundo.
Otra de las razones del éxito de Red Hat es la gran variedad de servicios populares que ofrece la com-
pañı́a. Los paquetes de software son fácilmente actualizables usando la Red Hat Network, un repositorio
oficial de software e información. Una larga lista de servicios de soporte son accesibles en la compañı́a
y, aunque no siempre baratos, tienes virtualmente asegurado un excelente soporte de personal altamente
cualificado. La compañı́a ha desarrollado incluso un programa de certificación para popularizar su distribu-
ción, el RHCE (Certificado de Ingenierı́a de Red Hat), academias y centros examinadores están disponibles
en el casi todas las partes del mundo.
Todos estos factores han contribuido a que Red Hat sea una marca reconocida en el mundo de la
industria de las TI.
SuSE
SuSE es otra compañı́a orientada a los escritorios, aunque tiene variedad de otros productos para
empresas. La distribución ha recibido buenas crı́ticas por su instalador y la herramienta de configuración
YaST, desarrollada por los desarrolladores de la propia SuSE. La documentación que viene con las versiones
comerciales, ha sido repetidas veces evaluada como la más completa, útil y usable con diferencia a la de
sus competidores. SuSE Linux 7.3 recibió el premio ”Producto del año 2001”que entrega el Linux Journal.
La distribución tiene un gran porcentaje de mercado en Europa y América del norte, pero no se vende en
Asia y otras partes del mundo.
El desarrollo de SuSE se realiza completamente a puerta cerrada, y no se lanzan betas públicas para
probar. Siguen la polı́tica de no permitir descargar el software hasta tiempo después de que salgan a la
venta las versiones comerciales. A pesar de todo, SuSE no entrega imágenes ISO de fácil instalación de su
distribución, usando el software empaquetado para la gran mayorı́a de su base de usuarios.
Actualmente van por la version 9.3 y no la instale porque la única forma de conseguirla era pagando
y uno puntos claves era que todo el software fuera libre y gratuito. SuSE no cumplı́a esos requisitos.
Knoppix
Knoppix es una distribución CD vivo de Linux basada en Debian y que utiliza como gestor de escritorio
KDE. Está desarrollada por el consultor de GNU/Linux Klaus Knopper. Gnoppix es una variante pero
incluye como entorno gráfico Gnome en vez de KDE.
A diferencia de la mayorı́a de las distribuciones Linux, no requiere una instalación en el disco duro;
el sistema puede iniciarse desde un simple CD de 700 MB. Además, Knoppix reconoce automáticamente
la mayorı́a del hardware del ordenador cuando se inicia. También puede ser instalado en el disco duro
utilizando un script de instalación. Y otra posibilidad de hacerlo más persistente es guardar el directorio
home en una unidad removible, como un dispositivo de almacenamiento USB.
Se puede usar de distintas formas como:

Para enseñar y demostrar de manera sencilla el sistema GNU/Linux, especialmente como sistema
operativo.
Probar rápidamente la compatibilidad de hardware bajo Linux antes de comprarlo o utilizarlo,

especialmente para tarjetas de vı́deo.
Utilizar las herramientas incluidas para restaurar un sistema corrupto o sus datos perdidos.
Existen versiones ı́ntegramente en español y catalán.
2.2.2. Pruebas
Los CD’s vivos arrancaron bien, sobre todo MEPIS con el que me llevé una grata sorpresa, muy simple
y funciona casi todo.
La distribución Ubuntu estaba claramente orientada a usuario final y no servidor que era mi objetivo,
de todas formas es una buena distribución que permite estar siempre actualizado.
Gentoo no la llegé a probar debido a las dificultades de instalación que representa la continua compi-
lación de paquetes, paso esencial en esta distribución. Es muy complicado dejarla a punto.
Debian y Slackware eran las distribuciones que más se ajustaron a los propósitos del proyecto; sobre
todo Debian que cuenta con un gran grupo de soporte y recursos. Pese a ser las menos actualizadas,
eso no presenta ninguna dificultad para poder actuar como un servidor, más bien al contrario, son las
distribuciones más estables de todas las evaluadas.
Mandrake no presentaba el entorno adecuado y Fedora y SuSE, al ser versiones comerciales, no cubrı́an
los requisitos prefijados.
2.2.3. Distribución elegida

Pese a la dificultad de instalación y configuración me decanté por Sarge del proyecto Debian, debido
a su carácter al 100 % libre y la gran cantidad de aplicaciones que adjunta. Otro factor decisivo fue el
soporte que tiene dicha distribución, mantenida por multitud de desarrolladores.
Pese a ser una versión en “pruebas”, se encuentra en la última fase. La rama de desarrollo Sarge, lleva
abierta desde el 2002 y la liberación de la versión “estable” se plantea inminente.
2.3. Selección del Software

Las herramientas escogidas no lo han sido al azar, son consecuencia directa de la filosofı́a del proyecto,
donde el uso exclusivo de software libre y gratuito era un objetivo prioritario.
Paso a detallar el software que utilizo:
2.3.1. Planner
Programa de gestión de proyectos que permite crear planes para el proyecto y seguir su progreso,
pudiendo colocar sellos temporales
Lista de caracterı́sticas
Calendario
Costes de proyecto
Gestión de tareas

Gestión de recursos
Figura 2.1: Distribución de recursos
Diagramas de ghant
Figura 2.2: Diagrama temporal de Ghant
2.3.2. LATEX
Como se menciona en [CSLSMR+ 03] LATEX es un conjunto de sentencias escritas en un lenguaje
de programación llamado TEX. Este no es un lenguaje de programación usual, sino uno orientado a la
escritura de textos de excelente calidad. TEX no es un editor de la familia WYSIWYG, término empleado
para denominar a los editores que sólo trabajan sobre la pantalla del computador, dando un formato
visual al texto, y en los cuales “lo que ves es lo que tienes”. Muy al contrario, en TEX se escribe el texto
acompañado de órdenes que el compilador, posteriormente, interpreta y ejecuta para proporcionar un
texto perfectamente compuesto.
A estas ventajas hay que añadir otra, es gratuito; Donald E. Knuth el creador de TEX, lo liberó en
Octubre de 1.990.
El entorno LATEX desarrollado por Leslie Lamport, lo creó en 1982, con la intención de simplificar la
tarea a aquellos que desean utilizar TEX. Añade a TEX una colección de comandos que simplifican el
mecanografiado, permitiendo al usuario concentrarse en la estructura del texto, en vez de en los comandos
para dar formato. Tal es la calidad de LATEX que muchas editoriales permiten a sus autores escribir libros
en LATEX, dándoles un archivo base y unas directrices sobre la elaboración de los textos.
Una de las ventajas de LaTeX es que puede ser exportado muy fácilmente a Portable Document Format
(PDF) y PostScrip.
Utilizaré este entorno de composición de textos para desarrollar la documentación derivada del pro-
yecto.

2.3.3. Kile
Kile es un editor de textos para LATEX desarrollado por P. Brachet. Tiene una completa interfaz con
diversas facilidades que ofrece a un usuario novel un entorno amigable.
Figura 2.3: Imagen del editor Kile
Sus principales caracterı́sticas son las siguientes:
Los comandos de LATEX están disponibles a través de menús, botones y combinaciones de teclas.
La ayuda integrada en el programa nos permitirá saber qué macro usar ante una necesidad concreta.
Para una edición cómoda de los ficheros de texto, contamos con resaltado de sintaxis, funciones de
búsqueda (incremental o no), reemplazo, deshacer, . . .
Los más de 370 sı́mbolos matemáticos posibles son accesibles mediante botones y menús.
Corrector ortográfico a través de ispell
Asistentes para la creación de distintos tipos de documentos LATEX(cartas, artı́culos, etc).
Manejo de bibliografı́as a través de BibTEX.
Navegación mediante menús de la estructura de un documento o proyecto.
Facilidades para compilar y depurar ficheros LATEX.
Integración con herramientas externas para la visualización e impresión de los documentos editados
en distintos formatos: DVI, Postscript o PDF.
Interfaz con programas de dibujo como xfig o gnuplot.
2.3.4. Prosper
La herramienta Prosper, desarrollada por F. Goualard y P.M.Neergaard es una clase para LATEX que
permite crear presentaciones electrónicas con una excelente calidad.
Con ella se pueden producir documentos en formato PDF para realizar exposiciones con un monitor o
con un sistema de proyección de vı́deo. También se puede producir documentos PostScript para imprimir
la presentación sobre transparencias para exposiciones con retroproyector.
Dispone de multitud de estilos de presentación y la posibilidad de conseguir efectos de animación en
pantalla haciendo que el contenido de la misma aparezca o desaparezca en distintas etapas (de forma
incremental).

Figura 2.4: Varios estilos de transparencias
2.3.5. Programas gráficos

Las imágenes y videos que he utilizado en la documentación y en las transparencias se han generado
con los siguientes programas:
KSnapshot: Para capturar pantallas, es mucho mejor que la tı́pica tecla Impr-pant gracias a sus
múltiples opciones, entre las que se encuentran un temporizador y poder elegir que parte de la
pantalla se va a capturar; pudiendo seleccionar entre toda la pantalla, la ventana activa o una región
concreta. En resumen, una herramienta muy útil para la redacción de tutoriales.
The Gimp: Es el programa estrella de GNU para la creación y el retoque fotográfico de imágenes,
comparable al famoso programa comercial Adobe Photoshop.
Xvidcap y Mencoder: Permite capturar una secuencia de imágenes de una parte de la pantalla, ya sea
una ventana o una región. De esta manera, obtendremos una colección de imágenes del área capturada
separadas temporalmente un número de fps1 que se puede especificar. El programa Mencoder forma
parte de Mplayer, que es un conjunto de aplicaciones para la grabación y reproducción de vı́deos,
dvd’s y otros. Una vez obtenida la colección de imágenes que conformaran los frames del vı́deo se
utilizará el programa Mencoder para componerlo.
1 fps: frames por segundo

Parte II
Instalación base
Capı́tulo 3
Instalación de la distribución
Existen varias formas de realizar la instalación de la distribución:
Desde CD-ROM: con las imágenes oficiales

Desde disquetes: carga un núcleo y permite hacer una instalación base por internet si la tarjeta de
red es soportada.
Desde dispositivo USB: crea un mini sistema base
Desde el disco duro: a partir de unos ficheros locales.
Desde red: Se realiza a través de TFTP desde una máquina a la que se tiene acceso, si la tarjeta de
red es soporta.
La manera más sencilla, con mucho, de instalar Debian GNU/Linux, es usar un juego oficial de CDs o
DVDs de Debian, las imágenes pueden ser descargadas desde el servidor Debian (www.debian.org/distrib/ )
o desde una replica del mismo.
Si el sistema no permite arrancar desde el CD, se puede utilizar una estrategia alternativa (disquete o
disco duro) para hacer el arranque inicial del instalador del sistema, los ficheros para arrancar mediante
otros medios también se encuentran en el CD. Una vez arranque el instalador, se pueden obtener el resto
de ficheros desde el CD.
Se puede obtener más información respecto a la instalación de Debian en [PRG+ 02] y [eidD04].
3.1. Proyecto Debian

El proyecto Debian GNU/Linux posee tres ramas: “stable”, “testing” y “unstable”. En los siguientes
apartados se detallan las diferencias entre ellas.
3.1.1. Unstable
Se llama “Sid” y como su nombre indica es la distribución más inestable porque contiene paquetes
muy nuevos. La utilizan los desarrolladores de Debian para depuración. Debian Sid contiene software muy
reciente y puede traer problemas de estabilidad graves.
3.1.2. Testing
Actualmente se llama “Sarge”, posee el software que ya pasó un tiempo de prueba en inestable pero
que aún debe pasar una fase de pruebas para consideralo estable, es la utilizada por aquellos que desean
disfrutar de las nuevas caracterı́sticas de Debian y de las versiones de software más reciente sin esperar
a la liberación oficial de una nueva versión. Es el equivalente a la distribución más actual de las demás
distribuciones (Mandrake, Fedora, Slackware, etc).
3.1.3. Stable
Actualmente es la versión 3.0, tambień llamada “Woody” y como su nombre indica es la más estable de
las distribuciones Debian, ya que su software contenido ya superó varios meses de pruebas y correcciones.
En sistemas de producción, donde no se toleran problemas de estabilidad, se recomienda el uso de
Debian Woody.
3.1.4. Recomendaciones
En entornos de prueba y/o desarrollo se recomienda utilizar Debian Woody o Sarge.
Para PCs de escritorio se recomienda utilizar Debian Sarge, ya que contiene versiones de software
bastante recientes y ya probadas un tiempo en la rama inestable.
He elegido Sarge, ya que esta rama de desarrollo lleva abierta desde el 2002 y la liberación de la versión
estable se plantea inminente.
3.2. Debian Sarge

Este método de instalación se utilizó en el cliente de pruebas. En el servidor se instaló Debian Woody
y se realizó una actualización debido a incompatibilidades de Hw.
Método de instalación
Mediante el siguiente esquema detallo el sistema de instalación.
1. Configurar la BIOS para arrancar desde el DVD
2. Iniciar el instalador boteando desde el DVD
3. Arrancar el instalador con los métodos y parámetros más adecuados al Hw disponible. Presionando
Enter se arranca con los parámetros por defecto que incluyen el kernel 2.6 de GNU/Linux.
4. Elegir idioma
5. Seleccionar paı́s
6. Confirmar mapa de teclado
7. Detectar Hw y cargar componentes.
8. Configurar la red
9. Particionar discos. Se puede escoger un particionado automático o si se elige manual, al menos se

han de crear 2 particiones, una raı́z y otra de intercambio
10. Formar particiones y realizar la instalación base
11. Instalar el núcleo
12. Instalar el gestor de arranque, se instala Grub como predeterminado. Si se disponen de varios sistemas
operativos se puede especificar un arranque múltiple
13. Retirar el DVD y reiniciar para continuar la instalación
14. Arrancar y configurar el sistema base
15. Configurar zona horaria

Capı́tulo 3. Instalación de la distribución 23
16. Configurar usuarios (root y usuarios corrientes)

17. Configurar APT
18. Instalar y configurar paquetes adicionales
19. Configurar correo
Si durante la instalación se producen errores o cuelgues se pueden especificar opciones restrictivas al
iniciar el instalador. En mi caso, no conseguı́ que ninguna opción instalara el sistema en el servidor.
3.3. Debian Woody

En la instalación se incluyen varias imágenes de núcleos disponibles, la mayorı́a basados en el kernel 2.2.20:
Vanilla: La imagen estándar de Debian Woody, instala el kernel 2.2.20. Incluye casi todos los
controladores soportados por Linux, compilados como módulos.
Compact: Igual que Vanilla, pero eliminando controladores de dispositivo que se usan con menos
frecuencia.
Idepci: Un núcleo que sólo soporta dispositivos IDE y PCI (y unos pocos ISA). Se debe usar este
núcleo si los controladores SCSI producen cuelgues al arrancar, debido a conflictos de hardware o a
un compotamiento inadecuado de los controladores o placas de su sistema.
Bf2.4: Usa el kernel 2.4 y da soporte a hardware nuevo ausente en las otras imagenes. Soporta más
hardware USB, controladoras IDE modernas, y los sistemas de ficheros Ext3 y Reiser.
Esta fue una de las partes más desesperantes del proyecto, debido a incompatibilidades de Hw, tuve
que instalar un versión diferente de la planificada y al arrancar Debian Woody con cualquiera de los
kernels disponibles, no cargaba el driver adecuado para la pantalla TFT. Esto supuso tener que utilizar
otra pantalla diferente, conectada a la salida VGA del portatil, para realizar toda la instalación, hasta
poder actualizar el kernel a una versión 2.6.
El arranque que utilicé fue Bf2.4, para que fuera soportado un mayor número de dispositivos desde el
inicio, aunque el problema de la pantalla persistı́a.
Este es un pequeño resumen de los pasos a seguir en la instalación de Debian Woody:

1. Configurar la bios para arrancar desde CD
2. Arrancar el sistema de instalación, boteando desde el CD
3. Seleccionar la imagen de núcleo deseada
4. Configurar teclado
5. Crear y montar particiones para Debian en el disco duro, con un mı́nimo de dos, una para el sistema
base y otra de intercambio
6. Seleccionar qué controladores de periféricos cargar
7. Configurar la interfaz de red
8. Iniciar la instalación y configuración automática del sistema base.
9. Configurar el gestor de arranque, en este caso Lilo. Si se dispone de varios sistemas operativos se
puede espedificar arranques multiples
10. Arrancar el sistema recién instalado y hacer las configuraciones finales
11. Instalar taréas y paquetes adicionales, a la elección de cada usuario.
Una vez terminada la instalación estándar, es necesario instalar un kernel más avanzado (2.6 o superior)
que nos detecte todos los dispositivos de los que dispone nuestro sistema, y si todavı́a no los soporta,
parchearlo con los drivers del fabricante.

3.4. Actualización de Woody a Sarge

Esto se realiza mediante la herramienta APT y se puede enfocar de dos formas.
Si disponemos de los DVD’s o CD’s de Debian Sarge, añadiéndolos al archivo de fuentes de APT
(#apt-cdrom add).
Si disponemos de internet, añadiendo la dirección de una réplica de los archivos de Debian Sarge al
archivo de fuentes de APT. La forma de hacerlo se detalla en el siguiente capı́tulo.
Una vez tenemos agregadas las fuentes de la nueva distribución en el APT, solamente tenemos que
introducir los siguientes comandos:
#apt-get update
#apt-get upgrade
#apt-get dist-upgrade

Capı́tulo 4
Primeros pasos
En los apartados que se presentan a continuación establecen varias cosas que hay que tener en cuenta
para administrar un servidor Linux.
4.1. Particionar el disco

En Linux cada partición se monta en tiempo de arranque. El proceso de montaje hace disponible el
contenido de esa partición dentro del sistema. El directorio raı́z (/) será la primera partición.
Las particiones, cuando se montan, aparecen como un árbol de directorios unificado en vez de unidades
separadas, el software de instalación no diferencia una partición de otra. Sólo hay que preocuparse de en
que directorio esta cada archivo. Como consecuencia de ello, el proceso de instalación distribuye automáti-
camente sus archivos por todas las particiones montadas, ası́ que las particiones montadas representan
diferentes partes del árbol de directorios donde se sitúan normalmente los archivos.
Debido a que estamos configurando un servidor, debemos conocer que directorios es necesario tener en
particiones separadas:
/usr, donde se sitúan todos los archivos de programa.
/home, donde están los directorios de todos los usuarios. Esto es útil por si los usuarios consumen
el disco entero y dejan a otras aplicaciones crı́ticas sin espacio (tales como los archivos log).
/var, el destino final de los archivos log. Debido a que estos pueden verse afectados por usuarios
exteriores (por ejemplo personas que visiten una página web), es importante situarlos en otra par-
tición para que nadie pueda realizar un ataque de Denegación de servicio (DoS) generando tantas
entradas que se llene todo el disco.
/tmp, donde se sitúan los archivos temporales. Debido a que este directorio está diseñado para que
todos los usuarios puedan escribir en él, necesitaremos asegurarnos de que ningún usuario abuse y
llene el disco completo. Podemos conseguir esto situándolo en una partición separada.
swap. Este es un sistema de archivos no accesible para el usuario. Es donde se almacena el archivo
de memoria virtual, tenerlo en otra partición mejora el rendimiento del sistema.
Se puede observar por qué es una buena idea crear varias particiones en un disco en lugar de una sola
partición grande al estilo de Microsoft. Esto da una idea de por qué un sistema trabaja mejor que el otro.
4.2. Gestores de arranque

El gestor de arranque indica al ordenador qué sistema operativo o kernel se iniciará y donde se en-
cuentran los archivos necesarios para ejecutarlo.
Dependiendo del tipo de distribución escogida se instalará por defecto uno de estos dos gestores de
arranque Lilo o Grub. Durante ese proceso se añadirán automáticamente los diferentes sistemas operativos
que tengamos instalados en el sistema. Posteriormente los parámetros pueden ser configurados desde
consola o mediante la herramienta de administración gráfica Webmin.
En el servidor he mantenido Lilo, era un gestor que ya conocı́a y con el que me sentı́a cómodo. Paso
a detallar los dos gestores según se explican en [BB00].
Lilo
Si hemos optado por utilizar Lilo, al terminar el proceso de instalación de Linux dispondremos de
un archivo de configuración denominado /etc/lilo.conf el cual podremos editar en cualquier momento
para ajustar el menú o comportamiento de Lilo a nuestras necesidades.
El archivo está dividido en tres secciones, como se puede observar en el cuadro 4.1.
La primera sección contiene opciones globales, como son el sistema operativo por defecto o si queremos
que aparezca el menú de selección y el tiempo por defecto.
En la segunda sección se especifican los parámetros necesarios para arrancar Linux, indicándose en
image y initrd el kernel y las opciones de arranque.
La última sección especifica la partición desde donde deberá ejecutarse los otros sistemas operativos
que tengamos instalados en el ordenador.
Si necesitamos realizar alguna modificación simplemente editaremos el archivo /etc/lilo.conf y pos-
teriormente ejecutaremos el comando lilo para activar los cambios.
#/sbin/lilo
Cuadro 4.1: Archivo de configuracion /etc/lilo.conf

# Global
prompt
timeout=70
default=Kernel-2_6
boot=/dev/hda
map=/boot/map
install=/boot/map
install=/boot/boot.b
message=/boot/message
lba 32
#Linux
image=/boot/vmlinuz-2.6.11-9
label=Kernel-2_6
read-only
root=/dev/hda3
image=/boot/vmlinuz-2.4.18-3
label=Kernel-2_4
initrd=/boot/initrd-2.4.18-3.img
read-only
root=/dev/hda3
#Windows
other=/dev/hda1
optional
label=WindowsXP
Grub
Es el gestor de arranque por defecto en Debian Sarge. Es un poco más flexible que Lilo, ya que permite
interactuar en caso de arranque inválido.
Incluye otras funciones como el soporte de múltiples módulos, interfaz gráfico de arranque, lı́nea de
comandos, descompresión automática, soporte para LBA y soporte para terminales entre otras muchas
opciones.

Capı́tulo 4. Primeros pasos 27
4.3. Usuarios
Es muy recomendable crearse un usuario de trabajo dentro del sistema, ya que con el usuario root
es posible crear, modificar o eliminar cualquier archivo del sistema operativo. Al utilizar este usuario se
podrı́a dañar el sistema en caso de cometer algún error.
Más adelante se detalla como crear y administrar usuarios con la herramienta grafica Webmin, pero
ahora voy a explicar como se harı́a desde la lı́nea de comandos.
4.3.1. Añadir nuevos usuarios al sistemas

La instrucción necesaria para crear un nuevo usuario es useradd.
#useradd josan
Este mandato crea una nueva entrada en el archivo /etc/passwd. Este archivo contiene información
como el nombre de usuario, contraseña, directorio de trabajo y shell predeterminado.
Es necesario crear una carpeta /home/josan que será el directorio del usuario.
#mkdir /home/josan
Una vez creado el usuario le deberemos asignar una contraseña, para ello utilizaremos la instrucción
passwd. Con ella podemos modificar la contraseña de cualquier usuario si hemos iniciado una sesión de
root, o nuestra propia contraseña en cualquier otro caso.
#passwd josan, . . . y introducir la nueva contraseña.
Si el sistema esta bien administrado, se ha de almacenar información imprescindible de los usuarios,

como el n.o de tlf. y el lugar donde encontrar fı́sicamente a ese usuario. Esto es necesario por si se
compromete la seguridad del sistema y necesitamos ponernos en contacto con el usuario a través de vı́as
no informáticas.
Para cambiar la información de una cuenta se usa el comando chfn.
#chfn josan
Y para visualizar esa informacion finger.
#finger josan
4.3.2. Añadir grupos al sistema

Para añadir un nuevo grupo al sistema se utiliza el siguiente comando:
#groupadd -g [GID] [nombre_grupo], . . . donde GID es el n.o de grupo que se asignará.
Si tenemos usuarios ya creados y deseamos añadirlos o eliminarlos de un grupo utilizaremos:
#gpasswd -a [nombre_usuario] [nombre_grupo], . . . añadir usuario

#gpasswd -d [nombre_usuario] [nombre_grupo], . . . eliminar usuario

4.3.3. Bases de datos de usuarios

Ahora vamos a especificar con más detalle como es almacenada la información de los usuarios dentro
del sistema.
Esta información es almacenada en tres archivos:
/etc/passwd: Información de los usuarios
/etc/shadow: Claves encriptadas de los usuarios
/etc/group: Grupos del sistema
Archivo /etc/passwd
Es usado para establecer y configurar las cuentas. Es un archivo de texto plano que puede ser consultado
por todos los usuarios del sistema. Y su contenido podrı́a ser algo parecido al siguiente:
Cuadro 4.2: Ejemplo de un archivo /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
postgres:x:31:32:postgres:/var/lib/postgres:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
operator:x:37:37:Operator:/var:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
josan:x:1000:1000:Jose Antonio Escartin Vigo:/home/josan:/bin/bash
identd:x:100:65534::/var/run/identd:/bin/false
sshd:x:101:65534::/var/run/sshd:/bin/false
Cada lı́nea representa un usuario. La información de cada usuario está dividida en seis campos delimi-
tados por el carácter dos puntos (:). La descripción de cada uno de los campos aparece listada en la Tabla
4.3.
Cuadro 4.3: Descripción de los campos del archivo /etc/passwd

Campo Descripción
1 Nombre de usuario o identificador de inicio de sesión. Tiene que ser único.
2 Contraseña encriptada de usuario. Una “x” minúscula indica que se usan contraseñas ocultas
y que estas estarán en el archivo /etc/shadow
3 Identificador de usuario (UID). Este n.o ha de ser único
4 Identificador de grupo (GID). Aquı́ solo aparece el grupo principal del usuario, aunque puede
pertenecer a más de un grupo
5 Campo de comentarios
6 Directorio /home del usuario.
7 Shell de trabajo del usuario. Habitualmente es la shell bash
Un carácter “*” en la contraseña indica que la cuenta esta deshabilitada temporalmente. Es una buena
práctica no sólo añadir el carácter, sino indicar el motivo por el que ha sido deshabilitada.
Se pueden añadir nuevas cuentas de usuario editando directamente el archivo /etc/passwd, pero para
crear las contraseñas hay que usar la utilidad /usr/bin/passwd ya que esta es cifrada.

Archivo /etc/shadow
Es el archivo de contraseñas ocultas. Este archivo añade un nivel de seguridad adicional, ya que la
encriptación de la clave de usuario solo es visible por el root.
Cuando todavı́a no existı́an las contraseñas ocultas, la contraseña, aunque cifrada, se almacenaba en el
archivo /etc/passwd. Este archivo puede ser leı́do por cualquier usuario del sistema, pero sólo modificado
por el usuario root. Esto representa un problema porque significa que cualquiera puede ver una contraseña
cifrada e intentar conseguir una clave que genere ese cifrado. Para combatir esta amenaza potencial, se
definió el concepto de contraseñas ocultas.
Cuadro 4.4: Ejemplo de un archivo /etc/shadow

root:$1$wzPAR6Nw$RTLX6R4qjZT6KGJI8efJL0:12890:0:99999:7:::
daemon:*:12890:0:99999:7:::
bin:*:12890:0:99999:7:::
sys:*:12890:0:99999:7:::
sync:*:12890:0:99999:7:::
games:*:12890:0:99999:7:::
man:*:12890:0:99999:7:::
lp:*:12890:0:99999:7:::
mail:*:12890:0:99999:7:::
news:*:12890:0:99999:7:::
uucp:*:12890:0:99999:7:::
proxy:*:12890:0:99999:7:::
postgres:*:12890:0:99999:7:::
www-data:*:12890:0:99999:7:::
backup:*:12890:0:99999:7:::
operator:*:12890:0:99999:7:::
list:*:12890:0:99999:7:::
irc:*:12890:0:99999:7:::
gnats:*:12890:0:99999:7:::
nobody:*:12890:0:99999:7:::
josan:$1$tUlRDVd7$6kPCHl4XyLIYnjBt4BpxF0:12890:0:99999:7:::
identd:!:12890:0:99999:7:::
sshd:!:12890:0:99999:7:::
messagebus:!:12891:0:99999:7:::
hal:!:12891:0:99999:7:::
gdm:!:12893:0:99999:7:::
saned:!:12905:0:99999:7:::
Está formado por entradas de una lı́nea con campos delimitados por el carácter dos puntos (:). Algunos
de estos campos contendrán aparentemente números raros, demasiado altos para ser correctos. Estos
campos están referidos a la fecha de comienzo “de la era de la computación”, el 1 de enero de 1970.
Cuadro 4.5: Descripción de los campos del archivo /etc/shadow

Campo Descripción
1 Nombre de la cuenta de usuario
2 Campo de contraseña cifrada
3 Dı́as transcurridos desde el comienzo de la era hasta la fecha en que la contraseña fue
cambiada por última vez
4 Número de dı́as tras que deben transcurrir hasta que la contraseña se pueda volver a cambiar
5 Número de dı́as tras los cuales hay que cambiar la contraseña (-1 significa nunca)
6 Dı́as antes de la expiración de la contraseña en que se avisará al usuario al inicio de la sesión
7 Dı́as despues de la expiración de la contraseña en que la cuenta se inhabilita si la contraseña
no se ha cambiado correctamente.
8 Dı́as transcurridos desde la era en que la cuenta se inhabilitará (con independecia de cambios
de la contraseña)
9 Campo reservado
Se utilizará change, la utilidad de cambio de caducidad, para modificar estos valores predeterminados.
Para realizar el cifrado de las contraseñas es mejor usar MD5 que el antiguo método DES, ya que
el primero permite contraseñas más largas y si esta es buena implica un tiempo mucho mayor para
descifrarlas.

Archivo /etc/group
El objetivo de la existencia de un identificador de grupo (GID) es agrupar de forma lógica recursos
o archivos para asignarlos a miembros de un grupo determinado. Los archivos de un grupo pueden ser
compartidos entre los miembros de ese grupo, protegiéndose contra el acceso de otros usuarios que no
deban acceder a esos recursos.
Cuadro 4.6: Ejemplo de un archivo /etc/group

root:x:0:
daemon:x:1:
bin:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:lp
mail:x:8:
news:x:9:
uucp:x:10:
proxy:x:13:
kmem:x:15:
dialout:x:20:
fax:x:21:
voice:x:22:
cdrom:x:24:hal
floppy:x:25:hal
tape:x:26:
audio:x:29:josan
dip:x:30:
postgres:x:32:
www-data:x:33:
backup:x:34:
operator:x:37:
list:x:38:
irc:x:39:
src:x:40:josan
gnats:x:41:
shadow:x:42:
utmp:x:43:
video:x:44:
staff:x:50:
games:x:60:
users:x:100:
nogroup:x:65534:
josan:x:1000:
man:*:12:
plugdev:*:46:
ssh:x:101:
crontab:x:102:
messagebus:x:103:
hal:x:104:
lpadmin:x:105:
gdm:x:106:
camera:x:107:
scanner:x:108:
saned:x:109:
Cada lı́nea del archivo /etc/group indica un grupo. Se puede observar que muchos de los grupos
predeterminados corresponden directamente a un servicio especı́fico.
Cada cuenta de usuario tiene que pertenecer como mı́nimo a un grupo.
Cuadro 4.7: Descripción de los campos del archivo /etc/group

Campo Descripción
1 Nombre de grupo
2 Contraseña de grupo. No suele usarse
3 Número de identificación de grupo
4 Lista de usuarios asociadas a este grupo. Si en el archivo /etc/passwd se ha especificado
este grupo, no es necesario que aparezca en la lista. Sólo es para usuarios que su grupo inicial
no fuera este

4.4. Permisos de archivos

En Linux hay tres niveles de permisos de archivos y directorios. Estos tres niveles pertenecen a las
siguientes categorı́as:
Usuario (el propietario)
Grupo
Otros
Cada nivel o categorı́a tiene los privilegios asociados de:
Lectura
Escritura
Ejecución
Un archivo está identificado por el grupo al que pertenece y su propietario. Cuando realizamos un
listado de un archivo, encontramos los siguientes parametros:
#ls -l <archivo>
- rwx rwx rwx root root 512 Jan 7 10:50 nom_archivo
4.4.1. Tipos de archivo

El primer carácter identifica el tipo de archivo. Podemos encontrar los siguientes:
Cuadro 4.8: Tipos de archivos
Carácter Tipo de archivo

- Archivo normal (generalmente un archivo binario o de texto ASCII)
d Directorio
l Enlace simbólico
l Dispositivo de carácter
l Dispositivo de bloque
l Socket (un proceso de escucha de red)
p Canalización o pipe con nombre
4.4.2. Modificar los permisos

Para modificar los permisos de acceso a un archivo se utiliza el comando chmod. Es necesario especi-
ficar los tres elementos siguientes:
Nivel se va a modificar (propietario, grupo o otros)
Permiso se va a modificar (lectura, escritura o ejecución)
Archivo o archivos que se van a modificar
La tabla 4.9 especifica las opciones del comando chmod.
Los permisos pueden ser especificados con letras:
#chmod g+w /home/josan/archivo, . . . da permiso de lectura al grupo

#chmod g-w /home/josan/archivo, . . . quita permiso de lectura al grupo

Cuadro 4.9: Opciones de chmod
Opción Descripción
u Propietario
g Grupo
o Otros
a Todos
r Lectura
x Ejecución
w Escritura
0 Sin privilegios
1 Ejecución
2 Escritura
3 Escritura y ejecución
4 Lectura
5 Lectura y ejecución
6 Lectura y escritura
7 Lectura, escritura y ejecución
O con números:
#chmod 751 /home/josan/archivo
Da lectura, escritura y ejecución al propietario; Lectura y ejecución al grupo; Ejecución a otros.
4.4.3. Permisos especiales: SUID, SGID y bit de persistencia

Con un archivo ejecutable, activar el bit SUID de propietario obliga al archivo ejecutable binario a
ejecutarse como si lo hubiera lanzado el usuario propietario del archivo y no realmente quien lo lanzó.
Normalmente, el usuario root es propietario de los ejecutables binarios con el bit SUID activo, de forma
que cualquiera que pueda ejecutar el programa lo ejecuta como usuario root.
Cuando un programa es SUID o SGID, una “s” sustituye a la “x” que corresponde al bit de ejecución
del usuario o grupo.
Esto es peligroso pero necesario para algunos programas. Por ejemplo, un usuario normal no puede
leer o escribir en el archivo /etc/shadow, para que este usuario normal (sin privilegios) pueda cambiar
su contraseña, el ejecutable passwd debe ser SUID del usuario root. El bit SGID funciona del mismo modo
para los grupos.
Cuadro 4.10: Opciones especiales chmod
s SUID o SGID
t Bit de persistencia
0 Sin permisos especiales (predeterminado)
1 Activar el bit de persistencia (t)
2 Activar el bit SGID de grupo (s)
3 Activar el bit SGID de grupo y el de persistencia
4 Activar el bit SUID de propietario
5 Activar el bit SUID de propietario y el de persistencia
6 Activar el bit SUID de propietario y el bit SGID de grupo
7 Activar el bit SUID, el SGID y el de persistencia

Cuando los bits SUID o SGID se refieren a directorios, los archivos que se almacenan en estos directorios
adoptan el propietario o grupo del directorio, en vez de adoptar el del usuario que creó el archivo.
El bit de persistencia, mostrado como “t” en lugar del bit de ejecución normal para el nivel “otros” se
usa normalmente en directorios tales como /tmp. Este atributo en concreto hace que sólo el propietario
del archivo pueda eliminarlo, aunque otros pueden leerlo.
Se puede especificar los permisos especiales SUID, SGID y bit de persistencia con la tabla 4.10
La forma de utilizarlo es añadir un número más al chmod:
#chmod 2751 /home/josan/archivo
Lo comentado anteriormente y el SGID activado.
4.4.4. Cambiar un archivo de propietario o grupo

La utilidad chown modifica el indicador de propietario.
#chown josan /tmp/archivo
La utilidad chgrp modifica el indicador de grupo.
#chgrp proyecto /tmp/archivo
4.5. Instalación de aplicaciones

En Debian GNU/Linux tenemos tres aplicaciones para manejar paquetes precompilados dpkg, apt y
alien.
Cuando disponemos de los archivos fuente de una aplicación y los queremos instalar en nuestro sistema
hay que tener varias precauciones.
La mejor opción es que el software a utilizar esté incluido en el proyecto Debian, ası́ se eliminará la
posibilidad que un usuario malintencionado haya modificado deliberadamente el paquete. Para asegurarnos
es preciso leer atentamente la documentación de los paquetes (INSTALL y README) y comprobar “a
mano” los script’s de instalación.
Si nos vemos en la obligación de instalar un paquete de una fuente no segura, desconocida o sospechosa
es una buena conducta de actuación instalar el paquete con un usuario con privilegios restringidos, evitando
usar root a menos que sea imprescindible. Si los scripts estuvieran modificados, sin privilegios, no podrı́an
hackear el sistema.
4.5.1. Compilación de paquetes desde archivos fuente

Las aplicaciones suelen venir comprimidas en uno de estos dos formatos
.tar.gz
.tar.bz2
Lo primero es descomprimir los fichero fuente, para ello debemos disponer de tres aplicaciones: gunzip
(.gz), bzip (.bz2) y tar (.tar).
Si el archivo es .tar.gz, el comando es el siguiente:
$tar zxvf archivo.tar.gz, . . . para descomprimir archivo.tar.gz

$tar jxvf archivo.tar.bz2, . . . para descomprimir archivo.tar.bz2

Entramos en el directorio que se haya creado y allı́ normalmente encontraremos algunos ficheros de
documentación especificos de cada paquete y los siguientes ficheros estándar:
README
INSTALL
Es imprescindible leerlos, en ellos se especifica la documentación del paquete. Aquı́ encontraremos la

historia del paquete, la versión actual, los paquetes adicionales que debemos de tener instalados, el método
de instalación y la información necesaria para modificar los archivos de configuración.
Para realizar la instalación se utiliza el Makefile, un archivo que se pasa al comando make con una serie
de parámetros dependiendo de las opciones disponibles. En el próximo párrafo se explica en que consiste
exactamente un archivo de este tipo.
Makefiles
En proyectos extensos, con varios miles de lı́neas de programación, no resulta muy práctico recompilar
cada vez que se desea armar un nuevo ejecutable. Es frecuente por lo tanto dividir el proyecto en varios
archivos con código fuente, y recompilar sólo los archivos qué registren cambios.
Existe un programa, que dada esta serie de interdependencias es capaz de generar el ejecutable con la
mı́nima cantidad de pasos necesarios. La especificación de las dependencias se da en un archivo llamado
Makefile y el programa que interpreta que lo interpreta y genera el ejecutable es Make.
Un Makefile es un archivo de configuración donde se indicarán que archivos debe compilar, las depen-
dencias de compilación, y los flags qué se han de pasar al compilador.
Pueden llegar a ser archivos grandes y complejos. Trataré de explicar las nociones más básicas de los
mismos, para poder leer los que vienen en las instalaciones de las aplicaciones. La sintaxis básica de un
archivo Makefile es la siguiente:
objetivo: dependencias
acciones a ejecutar
El objetivo es el archivo que se desea generar.

Las dependencias son los archivos de los cuales el objetivo depende.
Las acciones son los comandos para generar el objetivo a partir de las dependencias.
Para ilustrar esto veamos el siguiente ejemplo:
tst: tst.o tstf.o

gcc -o tst tst.o tstf.o
tst.o: tst.c
gcc -c -o tst.o tst.c
tstf.o: tstf.c
gcc -c -o tstf.o tstf.c
El programa make leerá el archivo Makefile, al llegar a la primera lı́nea encuentra que tst depende de
tst.o y tstf.o. Si tst no existe o tiene fecha de modificación anterior a la de sus dependencias, deberá ejecutar
la acción indicada para generarlo nuevamente. Análogamente, si tst.o no existe o tiene fecha de modificación
anterior a la de tst.c, será necesario recompilar nuevamente su código fuente.

En este tipo de archivos se suelen definir variables para ser utilizadas en las lı́neas de acciones. Estas
definiciones están al comienzo de los Makefiles y son del tipo:
DEPTST=tst.o tstf.o
CFLAGS=-c -o
Con estas modificaciones el archivo original quedarı́a de la siguiente forma:
Cuadro 4.11: Ejemplo de un archivo Makefile
DEPTST=tst.o tstf.o
CFLAGS=-c -o
tst: $(DEPTST)
gcc -o tst $(DEPTST)
tst.o: tst.c
gcc $(CFLAGS) tst.o tst.c
tstf.o: tstf.c
gcc $(CFLAGS) tstf.o tstf.c
Para abreviar también se pueden utilizar las construcciones especiales “$<” para referirse a las depen-
dencias y “$@” para referirse al objetivo, en el interior de las acciones.
Para ejecutar el Makefile:
$make, . . . para ejecutar todos los objetivos.

$make <objetivo>, . . . para ejecutar un objetivo concreto.
Los objetivos habituales en los instaladores son: check, install, y clean.
Método habitual de instalación

La mayorı́a de los paquetes se instalan de la siguiente forma:
$./configure
$make
$make install
Según el archivo INSTALL podremos observar las necesidades concretas del paquete, también es ha-
bitual, entre las distintas fases de instalación, las directivas:
$make check
$make clean
Por último decir que dependiendo del tipo de paquete y los lugares del sistema donde deba escribir
puede ser necesario instalar el paquete mediante un usuario con más privilegios.

4.5.2. Dpkg: Instalador de paquetes precompilados

Si en vez de paquetes fuentes lo que tenemos es un paquete precompilado o binario utilizaremos el
gestor de paquetes dpkg (Debian Package).
En la tabla 4.12 se especifican las opciones más comunes.
Cuadro 4.12: Opciones del comando dpkg

Comando Descripción
#dpkg -i <paquete> Instala paquete
#dpkg -r <paquete> Elimina paquete
#dpkg --purge <paquete> Borra un paquete incluı́dos los ficheros de configuración
#dpkg -f <paquete> Muestra información de la versión del paquete
#dpkg -c <paquete> Lista los ficheros contenidos
#dpkg --contents <paquete> Lista los ficheros contenidos y sus directorios
#dpkg --info <paquete> Información del paquete
#dpkg --unpak <paquete> Desempaqueta
#dpkg --info <paquete> Información del paquete
#dpkg --force-help <paquete> Fuerza opciones
#dpkg -L <paquetes> Lista el paquetes si está instalado
#dpkg -l Lista paquetes instalados
#dpkg-reconfigure --all Reconfigura todos los paquetes
#dpkg-reconfigure locales Reconfigura paquetes con la configuración local, por ejemplo colo-
ca paquetes en el idioma del sistema
4.5.3. Apt: Gestor de paquetes Debian

El programa APT (Advancd Packaging Tool) se encarga de manejar automáticamente las dependencias
de la paqueterı́a del sistema.
El archivo /etc/apt/sources.list
Como parte de su funcionamiento, APT utiliza un archivo que contiene las “fuentes” en donde se
encuentran los paquetes. En el siguiente cuadro podemos observar un archivo estándar del sources.list.
Cuadro 4.13: Ejemplo de /etc/apt/sources.list

deb cdrom:[Debian GNU/Linux testing _Sarge_ - Official Snapshot i386 Binary-2 (20050225)]/ unstable contrib main main/debian-installer
deb cdrom:[Debian GNU/Linux testing _Sarge_ - Official Snapshot i386 Binary-1 (20050225)]/ unstable contrib main main/debian-installer
deb cdrom:[Debian GNU/Linux 3.0 r4 _Woody_ - Official i386 Binary-2 (20050102)]/ unstable contrib main non-US/contrib non-US/main non-US/non-free non-free
deb cdrom:[Debian GNU/Linux 3.0 r4 _Woody_ - Official i386 Binary-1 (20050102)]/ unstable contrib main non-US/contrib non-US/main non-US/non-free non-free
#Sarge (testing)
deb http://ftp.rediris.es/debian testing main contrib non-free
deb-src http://ftp.rediris.es/debian/ testing main non-free contrib
deb http://ftp.rediris.es/debian-non-US testing/non-US main contrib non-free
deb-src http://ftp.rediris.es/debian-non-US testing/non-US main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
#Woody (stable)
#deb http://ftp.rediris.es/debian testing main contrib non-free
#deb http://ftp.rediris.es/debian-non-US testing/non-US main contrib non-free
#deb http://security.debian.org/ stable/updates main contrib non-free
#Sid (unstable)
#deb http://ftp.rediris.es/debian unstable main contrib non-free
#deb http://ftp.rediris.es/debian-non-US unstable/non-US main contrib non-free
El archivo puede contener varios tipos de lı́neas. APT sabe como interpretar lı́neas del tipo http, ftp y
file (archivos locales).
Para poder descargar los paquetes a través de internet utilizamos ftp.rediris.es, replica en España de
los paquetes Debian.

La primera palabra de cada lı́nea indica el tipo de archivo:

deb, indica un paquete pre-compilado (binario)
deb-scr, indica código original (fuentes)
Opciones ATP
En el cuadro 4.14 vamos a poder encontrar las opciones mas usuales que se pueden utilizar con el
comando APT
Cuadro 4.14: Opciones del comando APT

#apt-get install <paquete> Instala paquete
# apt-get --reinstall install <paquete> Reinstala paquete o una nueva versión del mismo
#apt-get remove <paquete> Desinstala paquete
#apt-get --purge remove <paquete> Desinstala paquete y borra sus archivos de configu-
ración
#apt-cdrom ident Identifica un CD
#apt-cdrom add Añade un CD al /etc/apt/sources.list
#apt-get update Actualiza la lista local de paqutes con el archivo
/etc/apt/sources.list
#apt-get upgrade Actualiza a las ultimas versiones todos los paquetes
del sistema
#apt-get dist-upgrade Actualiza a la distribución mas reciente
#apt-show-versions -u Muestra los paquetes del sistema que pueden ser ac-
tualizados
#apt-cache search <nombre> Muestra los paquetes relacionados con nombre
#apt-cache show <paquete> Muestra información de un paquete especı́fico
#apt-cache showpkg <paquete> Muestra mucha más información del paquete
#apt-cache depends <paquete> Muestra de qué paquetes depende
#apt-file search <archivo> Muestra a qué paquete pertenece el archivo
#apt-file list <paquete> Muestra los archivos del paquete
#apt-file update Actualiza los paquetes de apt-file (como apt-get up-
date)
#apt-get source <paquete> Descarga las fuentes del paquete
#apt-get -b source <paquete> Descarga y compila las fuentes del paquete (genera
un .deb, que hay que instalarlo con dpkg)
#apt-get build-dep <paquete> Descarga y compila las fuentes del paquete y des-
carga también los paquetes que dependen necesarios
para compilarlo.
#apt-cache showscr <paquete> Muestra que paquetes son necesarios para compilar
el paquete
#apt-get -f install Reconfigura los paquetes mal instalados (puede ser
necesario combinarlo con #dpkg --configure -a)
La opción -u muestra la lista completa de los paquetes que se actualizarán.
Si utilizamos la opción apt-cdrom solo tendrá efecto si el CD-ROM esta bien configurado en /etc/fstab.

4.5.4. Alien: Convertir paquetes .rpm a .deb (formato Debian)

Existen muchas distribuciones basadas en Red Hat que utilizan el formato de paquetes .rpm (Red Hat
Package Manager), cuando tenemos este tipo de paquetes es posible convertirlos a .deb, formato de Debian
y instalable con dpkg. Para ello utilizaremos la herramienta alien que convierte un tipo de paquete en otro.
#apt-get install alien

$alien paquete.rpm
4.5.5. Encontrar paquetes y sus dependencias

En algún momento nos podemos encontrar que necesitamos saber de qué paquete proviene un archivo,
o lo más frecuente, qué paquete/s tengo que instalar para que me funcione un comando.
Disponemos de apt-cache y dpkg para realizar estas tareas.
Buscar paquetes padre de comandos instalados
Si tenemos un comando instalado y no sabemos de que paquete proviene, se usa dpkg -S.
$dpkg -S <nombre_comando>
Devuelve una lista de todos los paquetes que durante su instalación crearon un archivo igual a nom-
bre comando. Si sabemos el directorio donde se encuentra podemos refinar la búsqueda.
$dpkg -S /usr/bin/nombre_comando
Buscar paquetes padre de comandos no instalados
En este caso hay que buscar en la página de paquetes Debian, http://packages.debian.org/testing/.
También se puede utilizar el siguiente truco rápido:
$links -dump "http://packages.debian.org/cgi-bin/search_contents.pl?

case=insensitive&arch=i386&version=testing&word=nombre_comando"
Donde arch, version y word se ajustan a las necesidades de nuestra búsqueda concreta.
Buscar paquetes si sabemos su nombre parcial
En este caso lo mejor es usar una de las opciones de dpkg -l.
$dpkg -l "*cadena_caracteres*"
Busca todos los paquetes que contienen la cadena cadena caracteres.
Buscar paquetes si tenemos una descripción
Si no conocemos el comando, pero sabemos su descripción, lo mejor es usar apt-cache search.
$apt-cache search <paquete>

Buscar dependencias de un paquete

Para conocer las dependencias e información de un paquete, podemos usar el apt-cache depends.
$apt-cache depends <paquete>
La información que se nos mostrará es la siguiente:
Depende: Paquetes que son necesarios para que funcione
Sugiere: Paquetes recomendables

Entra en conflicto: Paquetes incompatibles
Reemplaza: Paquetes que quedarán obsoletos
4.5.6. Problemas al instalar paquetes

Cuando existe un problema de dependencias entre paquetes podemos utilizar los siguientes comandos
para reconfigurarlos.
#dpkg --configure -a, . . . Comprueba problemas de configuración.

#apt-get -f install, . . . Reintenta la instalación de paquetes que han dado problemas.
Realizando una lectura, completa y a conciencia de las salidas de los comandos anteriores se suele
identificar el problema. Se puede probar a repetir varias veces estos dos comandos.
Si existe un paquete que ha quedado mal instalado, lo primero que hay que hacer es leer la docu-
mentación que trae, para comprobar si tiene alguna incompatibilidad con nuestro sistema. En caso de no
encontrar el problema, es recomendable probar a reinstalar el paquete:
#apt-get remove <paquete>

#apt-get install <paquete>
Si esto tampoco funciona, corriendo el consiguiente riesgo, se puede forzar la reescritura de paquete
con el comando:
#dpkg -i --force-overwrite /var/cache/apt/archives/nombre_paquete
. . . y probar a reconfigurar los paquetes otra vez
Estos comandos (dpkg --force-help) son útiles en determinadas ocasiones, pero hay que saber que
es lo que se quiere hacer de antemano y asumir las posibles consecuencias.
Por último comentar el siguiente comando que también puede ser útil en determinadas ocasiones:
# apt-get -s -t <rama_debian> install --reinstall <paquete>
Donde -s simula la instalación y -t unstable, stable o testing especifica la distribución Debian utilizada.
4.6. Shells
Un shell es un programa, ejecutado por el usuario, que le proporciona a este una interfaz interactiva
con el sistema (una lı́nea de comandos) para introducir datos o especificar programas que quiera ejecutar.
El shell predeterminado en la mayorı́a de distribuciones Linux es bash (Bourne Again Shell).

4.6.1. Tipos de shell

Existe varios shells para Linux. Cada una de ellas tiene ciertas caracterı́sticas, pero todas están clasi-
ficadas en dos ramas: la shell Bourne o la familia de shells C.
Shell Bourne
La shell Bourne es la más antigua de las shells modernas. La shell bash, suele ser ejecutada por defecto
en todas las distribuciones Linux. Algunas shells disponibles para sistemas Linux, que se inscriben en
la familia de shells Bourne, incluyen otro sucesor de Bourne, ksh, la shell de Korn (implementada en
casi todas las distribuciones como pdksh); ash, una shell parecida a bash pero de menor tamaño, ideal
para disquetes de arranque; kiss, otro intérprete sencillo de shell (pero sólo tiene comandos rudimentarios
integrados), que es también ideal para discos de arranque o rescate; y zsh, una shell muy parecida a la
shell de Korn.
La shell C
La shell C fue creada en principio para superar las limitaciones de la shell Bourne (como el soporte
para cálculos numéricos). Estaba dirigida a usuarios avanzados y a usuarios más familiarizados con la
sintaxis de la programación en C. La shell C proporciona una interfaz agradable, pero se considera que es
más difı́cil hacer scripts para ella, especialmente para aquéllos que no estén familiarizados con la sintaxis
C. La sintaxis para las variables de entorno varı́a significativamente, y los scripts escritos para shells de la
familia Bourne, normalmente no se pueden ejecutar en una shell C y viceversa. Entre los sucesores de la
shell C (csh) tenemos tsch, recomendada por encima de csh para aquellos que quieran usar este tipo de
interfaz.
4.6.2. Caracterı́sticas de la shell Bash

La shell bash contiene una serie de herramientas que facilitan la tarea del usuario. Estas quedan
descritas en los siguientes puntos:
Escribiendo cd se va directamente al home del usuario.
Si se empieza a escribir una ruta o un nombre de archivo, y esa ruta o ese nombre son únicos entre
todas las opciones disponibles, si se pulsa la tecla TAB, el shell rellena el resto de la ruta o nombre.
En caso de que no sea único emite un pitido de opción ambigua y si se pulsa por segunda vez la
tecla TAB se muestra el rango de opciones disponibles. A menudo, con sólo un carácter más
tendremos una selección única otra vez.
Se pueden ejecutar varios comandos en la misma lı́nea separándolos por el caracter “;”
Permite incrustar comandos como parametros de otros comandos, encerrándolos entre comillas
invertidas (#kill ‘cat /var/run/named.pid‘)
Existe un historial de comandos, que queda almacenado en .bash history. Tiene un tamaño
prefijado (normalmente 500 lineas) a partir del cual empieza a borrar las lı́neas antigüas para
escribir las nuevas. El comando $history mostrará el contenido de .bash history.
Este histórico de comandos facilita la tarea de escribir scripts para la shell. Sencillamente, cortando
y pegando en un script los comandos que funcionaron bien.
Se puede recuperar un comando ya utilizado pulsando repetidas veces la flecha hacia arriba.
Facilita la tarea de cortar y pegar, en entorno X-Windows, funciona entre ventanas de diferentes
aplicaciones. También permite seleccionar textos usando el ratón.

4.6.3. Ejecución de procesos en la shell Bash

Para ejecutar un archivo que se encuentre en el directorio local, siendo que este directorio no se en-
cuentra en el $PATH del sistema se emplea el siguiente método:
$./<archivo_ejecutable>
Desde una consola también podemos hacer que un proceso se ejecute en segundo plano añadiéndole
un & al final, y ası́ seguir trabajando en esa consola:
$comando &
4.6.4. Variables de entorno

Una variable de entorno es una cadena de caracteres con información de las diferentes opciones del
sistema asociada a un nombre simbólico que pueda utilizar Linux.
Visualizar contenido de variables

Podemos visualizar las variables definidas, ası́ como sus valores utilizando los comandos:
$printenv
$env
El comando printenv se diferencia de env por el hecho de que nos permite visualizar el valor de una
variable en particular:
$printenv <VARIABLE>
Variables más comunes

La siguiente tabla, obtenida en [BB00] especifica las variables que encontraremos, más habitualmente,
en nuestro sistema.
Si se utiliza el shell bash, se puede encontrar más información sobre las variables de entorno que existen
mediante el comando $man bash.
Asignar valores a variables de entorno

Para definir una variable de entorno podemos hacerlo desde la lı́nea de comandos, con la desventaja
de que el valor sólo será válido en la sesión actual, o modificando los archivos de perfil.
La forma de realizar esta asignación desde la lı́nea de comandos dependerá del shell que estemos uti-
lizando.
Si utilizamos el shell bash el método es el siguiente:
#VARIABLE_DE_ENTORNO=valor
#export VARIABLE_DE_ENTORNO
En caso de realizarlo mediante los archivos de perfil, en el interior del /etc/profile o el ˜/.profile se
coloca la siguiente instrucción:
export VARIABLE_DE_ENTORNO=valor

Cuadro 4.15: Variables habituales del sistema

Variable Descripción
EDITOR Indica el editor por defecto utilizado por el sistema
HISTSIZE Es el número de comandos que recuerda el shell. Podemos acceder a los coman-
dos utilizando los cursores arriba y abajo
HOME Determina el directorio de trabajo del usuario actual
HOSTNAME Indica el nombre del ordenador o host en el cual estamos trabajando
HOSTTYPE Especifica el tipo o arquitectura del ordenador
LANG Esta variable se emplea para indicar el idioma utilizado
LOGNAME Nombre del usuario actual
MAIL Directorio en el cual se almacena el correo entrante
OSTYPE Sistema operativo en uso
PATH Trayecto o ruta de búsqueda de los archivos ejecutables
SHELL Nombre del shell actualmente en uso
PWD Path de inicio
TERM Tipo de terminal utilizado en la sesión de trabajo actual
USER Nombre de usuario
PATH Conjunto de directorios donde se buscan los comandos
PS1 Especifica el aspecto del sı́mbolo de prompt del sistema
LANG, LANGUAGE Especifica el estándar de lenguaje que se utiliza en la máquina
LC ALL, LC TYPE Especifica el estándar de lenguaje para las configuraciones locales
Eliminar variables de entorno

Para eliminar variables desde la lı́nea de comando se ejecutará una instrucción diferente dependiendo
del shell sobre el que trabajemos. En el shell bash se realiza de la siguiente forma:
#unset VARIABLE_DE_ENTORNO
También es posible utilizar el comando env con la -u:
#env -u VARIABLE_DE_ENTORNO
Hay que tener en cuenta que si la variable se encontraba contenida en uno de los archivos de configu-
ración de perfil, cuando volvamos a cargar el entorno del usuario la variable también se cargará.
4.6.5. Configuración del entorno

Cuando se inicia una sesión de trabajo el intérprete de comandos bash lee y ejecuta de forma automáti-
ca las órdenes del archivo /etc/profile. A continuación1 busca los archivos del usuario ˜/.bash profile,
˜/.bash login y ˜/.profile ejecutándolos según el orden indicado. Al finalizar la ejecución del shell se
lee y ejecuta el archivo ˜/.bash logout del directorio del usuario.
Si queremos que se ejecute algo al comienzo o final de cada sesión, o añadir nuevas variables de sistema,
elegiremos el archivo a modificar que más convenga a nuestros objetivos.
Resulta de gran utilidad realizar alguna modificación a los comandos tı́picos para evitar daños no
deseados en el sistema o añadir las opciones que mas utilizamos. Un ejemplo de esto serı́a colocar en el
archivo ˜/.profile:
alias mv="mv -i"

1 En el caso de ejecutar un shell interactivo que no sea de entrada se lee y ejecuta el archivo ˜/.bashrc ubicado en el
directorio del usuario.

alias cp="cp -i"

alias rm="rm -i"
alias dir="ls -alF"
Con los tres primeros comandos se redefinirá el comando base, pidiendo confirmación por defecto y
con el último se creará un comando nuevo que llamará a ls pero con más opciones.
4.6.6. Redireccionamientos
Para redireccionar a un archivo la salida normal de un script, de forma que más tarde se puedan ver
los resultados, se utiliza la redirección (>).
$ls -l >listado
Si se quiere añadir los resultados de la salida de un comando al final de un archivo, se utiliza la redi-
rección (>>).
$ls -l /bin >>listado
De forma similar, se pude redireccionar la entrada, para ello se utiliza la redirección(<).
$cat < listado
Canales estándar
En Linux existen una serie de canales estándar que nunca cambian, al menos que los modifiquemos a
mano:
Dispositivo 0: stdin, o dispositivo de entrada estándar
Dispositivo 1: stdout, o dispositivo de salida estándar
Dispositivo 2: stderr, o dispositivo de error estándar
Dispositivo /dev/null: Todo lo que se redirecciona a este dispositivo se pierde
Estos dispositivos estándar también pueden ser redireccionados con: “>” y “<”. Esto se puede observar
en los siguientes ejemplos:
$ls > listado 2>&1, . . . redirecciona la salida estándar y el error estándar al archivo listado.
$ls > listado 2>/dev/null, . . . redirecciona la salida estándar al archivo listado y descarta errores.
$cat < listado 2>&1 listado2, . . . toma como entrada listado, la salida y el error se redireccionan
a listado2.
Filtros o pipes
Los filtros o pipes son un mecanismo por el cual la salida de un programa se puede enviar como en-
trada a otro programa. Los programas individuales se pueden encadenar juntos para convertirse en unas
herramientas extremadamente potentes.
Podemos ver esto con un ejemplo:
$env | grep "SHELL", . . . el comando env lista las variables y filtramos la variable “SHELL”.
Los comandos more y less paginan (dividen en páginas) uno o varios ficheros y los muestran en la
terminal. De no indicárseles un fichero, paginan la entrada estándar. Se diferencian en las facilidades que

brindan. Por ejemplo more es más restrictivo en cuanto al movimiento dentro del texto, mientras que less
no limita este aspecto pues acepta el empleo de todas las teclas de movimiento tradicionales. Cuando se
alcanza el final del último fichero a paginar, more termina automáticamente, no ası́ less. También more
muestra sucesivamente el porcentaje del fichero visto hasta el momento.
Proveen una serie de comandos para moverse con facilidad dentro del texto paginado:
q: permite interrumpir el proceso y salir
/p: realiza búsquedas del patrón p dentro del texto. Para repetir la búsqueda del mismo patrón sólo
es necesario escribir /.
n b: en more permite regresar n páginas (por defecto n es 1).
n f: en more se adelantan n páginas y en less, n lı́neas.
4.7. Consolas virtuales

Al ser Linux un sistema multiusuario y multitarea, se pueden ejecutar diversos procesos simultánea-
mente, en varias consolas virtuales, y estos ser controlados por usuarios diferentes. En cada consola virtual
que se utiliza es necesario logearse como usuario del sistema.
Para cambiar de consola:
En modo texto: ALT-F1 . . . ALT-F6

En modo gráfico: CTRL-ALT-F1 . . . CTRL-ALT-F6 para consolas de texto y CTRL-ALT-F7 para
volver al modo gráfico.
Esto es muy útil para tener una consola virtual de root con máxima prioridad, si el sistema se ralen-
tiza, podremos observar por qué esta pasando y remediarlo. También podemos finalizar algún proceso o
aplicación que haya podido bloquear otra consola, evitando de esta forma tener que reiniciar el sistema.

Capı́tulo 5
Kernel
El kernel o núcleo es una de las partes esenciales de un sistema operativo. Proporciona todos los servicios
básicos requeridos por otras partes del sistema operativo y aplicaciones. Se encarga de la administración
de la memoria, los procesos y los discos. El kernel es independiente de la distribución Linux utilizada, el
mismo kernel deberı́a servir para otras distribuciones, usando el mismo ordenador.
Las distribuciones Linux vienen con kernels que necesitan ser instalados en una amplia variedad de
escenarios de configuraciones de sistemás y hardware, por lo tanto dan soporte a muchos dispositivos y
hardware que no necesitamos. Recompilar el kernel es una buena idea y dará como resultado un kernel
más pequeño y rápido. El kernel 2.6 es más rápido que los kernels anteriores y tiene soporte para nuevos
dispositivos.
La actualización del kernel se divide en dos partes: compilación e instalación del nuevo kernel.
5.1. ¿Por qué compilar?

Hay diversas razones para recompilar el kernel de Linux. Es útil por qué trabajando con kernels nuevos
generalmente se obtiene:
1. Un sistema más rápido, estable y robusto
2. Soporte a elementos de hardware no encontrado en kernels viejos.
3. Soporte a caracterı́sticas especiales disponibles pero no habilitadas en kernels viejos.
Recompilar el kernel de Linux no es más que personalizar el kernel. Como en cualquier aplicación,
la personalización se hace para sacar un mayor provecho de las diferentes caracterı́sticas que ofrece el
software.
5.2. Acerca de los módulos

Varias partes de código del kernel pueden compilarse por separado en forma de módulos, dando flexi-
bilidad al sistema. Los módulos no están enlazados directamente en el kernel, siendo necesario insertarlos
en él ya sea durante el proceso de arranque o posteriormente, de tal forma que sólo se usan cuando se
necesitan, sin utilizar innecesariamente la memoria Ram del sistema.
5.3. Kernel-image
La manera más sencilla de obtener un nuevo kernel es instalar un paquete kernel-image.deb. Una vez
instalado sólo es necesario actualizar el gestor de arranques y reiniciar.
Son kernels bastante estándar y adaptados a distribuciones Debian. Para hacerlos más utilizables,
incluyen soporte para todo tipo de hardware e idiomás imaginados.
Este método es rápido y sencillo pero es muy ineficiente, desaprovecha los recursos del sistema.
5.4. Kernel-source
Es un paquete de código fuente del kernel oficial, adaptado a la distribución Debian. Kernel-source es
mucho más versátil que kernel-image, los binarios no suelen contener configurados correctamente todos
los dispositivos del sistema.
5.4.1. Instalar un kernel-source

Para saber cual es la version más actual podemos utilizar la siguiente secuencia de comandos:
1. Cargar las fuentes de Apt (/etc/apt/sources.list) con nuestra distribución, como se puede ver en
el ejemplo 4.13 del capı́tulo anterior
2. Actualizar el Apt con las nuevas fuentes, #apt-get update
3. Cargar el paquete links, #apt-get install links
4. Averiguar el nombre del kernel-source más actual,
$links -dump "http://packages.debian.org/cgi-bin/search_contents.pl?
case=insensitive&arch=i386&version=testing&word=kernel-sourse-2.6"
5. Descargar la nueva versión del kernel-source (se descarga en el directorio /usr/src/),
#apt-get install kernel-source-2.6.8
6. Descomprimir el kernel-source, #tar jxvf /usr/src/kernel-source-2.6.8.tar.bz2
7. Crear un enlace simbólico, #ln -s kernel-source-2.6.8 linux

8. Ejecutar el menu de configuración para el menu texto, #usr/src/linux/make menuconfig,
. . . o para el menu gráfico, #usr/src/linux/make xconfig
9. Elegir las opciones que queramos implementar en el kernel

Una vez completadas estas instrucciones podemos elegir entre dos alternativas: o crear un paquete
.deb, descrito en el apartado siguiente; o compilar el kernel como si fueran las fuentes oficiales (Apartado
5.5).
Esto queda a elección del usuario, pero al haber optado por las herramientas Debian la opción más
coherente es crear un paquete.
5.4.2. Crear un paquete .deb

Usaremos la herramienta make-kpkg de Debian para crear el paquete .deb con nuestro kernel. La
documentación se puede encontrar en /usr/share/doc/kernel-package/. Para evitar dañar el sistema con
posibles errores se utilizará el paquete fakeroot que proporciona un entorno de root falso, donde poder
compilar el kernel. En la página del manual se describen las opciones del paquete fakeroot, en el ejemplo
se muestra el método más simple:
Para crear el kernel-image, hay que introducir los siguientes comandos:
$fakeroot make-kpkg clean

$fakeroot make-kpkg -version .fecha kernel_image
Donde version es el número de la versión del kernel, en la secuencia del usuario y .fecha es la fecha
en la que se está compilando el kernel. De esta forma tendremos claramente identificado la versión del
kernel y la fecha de la compilación.

Capı́tulo 5. Kernel 47
Para instalar el paquete:
#dpkg -i kernel-image-2.6.8_Version.1.050518_i386.deb
Una vez terminado solo es necesario actualizar el gestor de arranque con el nuevo kenel y reiniciar
(Como se puede observar en el apartado 4.2 del capı́tulo anterior).
5.5. Compilar Kernel

Las fuentes oficiales del kernel más actual las podemos encontrar en http://www.kernel.org. Las des-
cargamos al directorio /usr/src/ y las descomprimimos empleando el método adecuado, según el formato
del kernel descargado.
Para la seguridad y asegurarnos que no dañamos involuntariamente el sistema se puede creer un usua-
rio capaz de actuar con los archivos fuentes. Para eso se añadirá al grupo src.
#gpasswd -a josan src
5.5.1. Paquetes necesarios

Para poder compilar el kernel necesitamos tener los siguientes paquetes instalados.
Paquetes básicos
Cuadro 5.1: Paquetes básicos
gcc
kernel-package
libc6-dev
tk8.0
libncurses5-dev
fakeroot
Paquetes kernel 2.6
Antes de realizar el proceso de compilación de un kernel de la serie 2.6 es necesario que actualize-
mos nuestro sistema con las últimás versiones de los paquetes que se detallan en el cuador 5.2.
Si alguno no lo tenemos instalado, es necesario realizar su instalación mediante apt-get. El proceso

automatizado que comprueba las versiones se encuentra implementado en el scrip:
/usr/src/linux/scripts/ver_linux

Cuadro 5.2: Paquetes necesarios para compilar kernel 2.6
Paquete Version necesaria Comando comprobar versión

Gnu C 2.95.3 #gcc --version
Gnu make 3.78 #make --version
binutils 2.12 #ld -v
util-linux 2.10 #fdformat --version
module-init-tools 0.9.10 #depmod -V
e2fsprogs 1.29 #tune2fs
jfsutils 1.1.3 #fsck.jfs -V
reiserfsprogs 3.6.3 #reiserfsck -V
xfsprogs 2.1.0 #xs_db -V
pcmcia-cs 3.1.21 #cardmgr -V
quota 3.09 #quota -V
PPP 2.4.0 #pppd --version
isdn-utils 3.1pre1 #isdnctrl 2>&1|grep version
nfs-utils 1.0.5 #showmount --version
procps 3.1.13 #ps --version
oprofile 0.5.3 #oprofiled --version
5.5.2. Comprobar el hardware disponible

Para comprobar que todos los dispositivos que tenemos son reconocidos vamos a ejecutar una serie de
comandos:
#apt-get install hardinfo, instala una serie de utilidades para hw

$/bin/lspci, . . . informa sobre los dispositivos disponibles
$cat /proc/cpuinfo, . . . lista detalles sobre la CPU reconocida
En caso de que no reconociera alguno, es necesario estudiar más a fondo el problema concreto. Suele ser
necesario descargar los drivers y parchear el kernel para que les de soporte. Normalmente, los fabricantes
de software incluyen manuales de instalación que simplifican esta tarea.
5.5.3. Método de compilación

En el cuadro 5.3 se describe el método que utilicé para compilar el kenel del servidor. Es un trabajo
laborioso y que requiere bastante práctica, es necesario realizar varias recompilaciones para ajustar las
opciones del kernel. Al comenzar el usuario se encuentra abrumado ante tal cantidad de opciones, averiguar
las correctas es cuestión de disponer de las especificaciones del hardware y paciencia.
El método descrito es una guı́a estándar para compilar el kernel, la elección de los módulos a colocar
en el kernel se deja a elección del usuario, ya que cada hardware tiene sus propias caracterı́sticas.
Es muy recomendable, para mayor seguridad, compilar en kernel en un entorno simulado, que da acceso
a recursos pero no permite modificaciones del sistema. Esto se realiza mediante el paquete fakeroot, como
se ha explicado anteriormente (sección 5.4.2). Una vez tenemos descargadas las fuentes en /usr/src/, si
queremos comprobar que hace el Makefile lo podemos encontrar en, /usr/src/linux/arch/i386/Makefile.
El método descrito en este apartado es un resumen del documento Kernel-Build-HOWTO, en el que

me basé para realizar la compilación del kernel. Se puede encontrar en la dirección:
http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html

Capı́tulo 5. Kernel 49
Cuadro 5.3: Compilación del Kernel

Acción Comando
Nos situamos en el directorio $cd /usr/src
Si existe enlace /usr/src/linux rm linux
Descomprimimos el kernel $tar zxvf linux-2.6.11.tar.gz
Creamos un enlace simbolico a $ln -s linux-2.6.11 linux
las fuentes del nuevo kernel
Entramos en el directorio de las $cd linux
fuentes
Cambiar a usuario root $su root
Salvamos el archivo antiguo de #cp .config config.save
configuración del kernel
Borramos los mensajes de com- #make mrproper
pilaciones anteriores
Entramos en el menú de configu- #make menuconfig (menu texto) o #make xconfig (menu gráfico)
ración
Agregamos dependencias #make dep
Borramos datos innecesarios #make clean
Compilamos el kernel #make bzImage
Compilamos los módulos #make modules
Instalamos los módulos en el ker- #make modules_install
nel
Copiamos a /boot el kernel #cp arch/i386/boot/bzImage /boot/bzImage-VERSION_KERNEL
Borramos el antiguo enlace a #rm /boot/System.map
System.map
Copiamos el archivo System.map #cp System.map /boot/System.map-VERSION_KERNEL
Creamos el nuevo enlace a Sys- #ln -s /boot/System.map-VERION_KERNEL /boot/System.map
tem.map
Configuramos el gestor de arran- #vi /etc/lilo.conf
que
Cargamos el nuevo arranque #/sbin/lilo
Marcamos que reinicie con el #/sbin/lilo -R <Nombre_del_arranque_en_lilo>
nuevo kernel
5.5.4. Parchear el kernel

Los parches del kernel son la forma de añadir caracterı́sticas especiales al kernel. Antes de lanzar
#make menuconfig o #make xconfig, es necesario ejecutar los parches con el siguiente comando:
#/usr/src/linux/patch -p1 < [ruta_del_pache]/parche_a_aplicar
Con esto conseguiremos aplicar los parches sobre las fuentes del kernel, es preciso asegurarse que los
parches coinciden con la versión de nuestro kernel, en caso contrario no funcionarán.
5.5.5. Consejos para la configuración del kernel

Hay que tomarse todo el tiempo necesario con xconfig o menuconfig. Asegúrarse de incluir todo lo
imprescindible y quitar todo lo que no (módulos para dispositivos zip, soporte usb, video, tarjeta de
sonido, nic, raid, etc...). Se recomienda usar los módulos siempre que sea posible, esto hace al kernel más
pequeño y más rápido. Si no se está seguro de que elegir resulta de gran ayuda consultar la documentación.

Capı́tulo 6
Interfaz gráfico
En los sistemas Linux se tiene una visión diferente del entorno gráfico. La interfaz que se presenta al
usuario es independiente del núcleo del sistema operativo.
El núcleo de Linux (su kernel) está completamente desacoplado de la interfaz gráfica. Esto permite
seleccionar la interfaz con la que nos resulte más cómoda, en lugar de tener que seguir el dictado de alguien
o de la potencialmente aleatoria “investigación de mercado”.
Sin embargo, lo más importante de esta decisión es la estabilidad que implica tener este programa
independiente del núcleo. Si cae el GUI1 bajo Windows o MacOS, se tiene que volver a arrancar. Bajo
Linux, se pude matar el proceso y reiniciarlo sin afectar al resto de servicios del sistema (tales como
servicios de archivos, o de red).
6.1. X-Window
A mediados de 1980 se creó una fundación para entornos de usuario gráfico, indepenediente del sistema
operativo llamado X-Windows. Las “X” simplemente definen el método por el cual se pueden comunicar
las aplicaciones con el hardware gráfico. También establece un conjunto de funciones de programación
bien definidas que podrán ser llamadas para realizar la manipulación básica de las ventanas.
La definición básica de cómo se dibuja una ventana, un botón o un icono no incluye la definición de
cómo estos se deberı́an ver. En realidad X-Windows en su estado natural no tienen apariencia real. El
control de la apariencia se delega en otro programa externo llamado gestor de ventanas.
Con los entornos de programación y las interfaces de usuario tan poco amigables X-Windows tenı́a el
potencial de convertirse en la interfaz final, pero a cambio contaba con la desventaja de ofrecer un diseño
que parecı́a como hecho “a trozos”.
El protocolo es abierto, lo cual significa que cualquiera puede escribir un cliente X o un servidor X.
Una de las mejores caracterı́sticas de X-Windows es que permite que las aplicaciones se ejecuten en
una máquina, pero se visualicen en otra distinta, suministra protocolos de red para realizar esta función.
6.1.1. Configuración X-Windows

Linux ofrece la funcionalidad de poder ejecutar aplicaciones a través de una red heterogenea, mediante
la incorporación de la implementación XFree86 del estándar X11 del sistema X-Window, creado por el
MIT2 .
1 Interfaz gráfica de usuario

2 Instituto Tecnológico de Massachusetts
Históricamente, XFree86 ha sido una de las partes más complejas de Linux en lo referente a instalación
y configuración. Ya no es este el caso, en la mayorı́a de las configuraciones estándar de hardware. Ahora las
distribuciones más populares de Linux lo instalan y configuran automáticamente. Además, con XFree86 v4,
algunas de las partes más complejas de la configuración son gestionadas automáticamente.
Actualmente XFree86, el servidor X que usa Linux normalmente, se encuentra en el estándar X11R6.4,
que se ha adaptado a los sistemas basados en Intel.
Hay que asegurarse de que se dispone de hardware apropiado para ejecutar XFree86, se debe tener una
tarjeta de vı́deo que disponga de un chipset soportado y un monitor que permita la frecuencia escogida. Al
trabajar directamente con el hardware, si no fuera compatible, se podrı́a dañar fı́sicamente el ordenador.
xf86Config
Es el configurador de X-Windows para Debian. Después de leer los archivos /usr/X11/lib/doc, hay que
ejecutar uno de los siguientes comandos:
#xf86config, . . . para modo texto
#xf86cfg, . . . para modo gráfico
A continuación, se seleccionan las especificaciones de la tarjeta y el monitor. Esto generará el archivo

de configuración /etc/X11/XF86Config-4.
Para probar la configuración ejecutamos #startx.
Si no arranca ha llegado el momento de adentrarse en el archivo XF86Config-4.
Archivo /etc/X11/XF86Config-4
Si se dispone de hardware poco frecuente, puede que sea necesario configurar manualmente XFree86.
No se debe utilizar este archivo copiado y sin revisar, de otro sistema, otro ordenador o el ejemplo
que se expone mas adelante. Es necesario inspeccionar el archivo en busca de valores erróneos, arrancar
el monitor con frecuencias no soportadas podrı́a dañar el equipo.
El archivo de configuración está dispuesto en secciones con el siguiente formato:
Section "Nombre de la seccion"

Comando1 "Opcion"
Comando2 "Opcion"
Subsection "Nombre de la subseccion"
Comando3 "Opcion"
EndSubSection
EndSection
A continuación paso a detallar cada una de las secciones que contiene el archivo de configuración:
Sección Files
Está sección define los archivos y directorios importantes para XFree86. Las rutas de acceso a la base
de datos de color (RGB), las definiciones de las fuentes y bibliotecas de módulos.
Sección Modules
Se proporciona soporte para varios servicios mediante módulos de carga dinámica. Esto aumenta mucho
la flexibilidad en el modo de suministro de servicios, y en los servicios que los usuarios eligen usar en
realidad.

Capı́tulo 6. Interfaz gráfico 53
De este modo, también se proporciona un mecanismo más general para ofrecer servicios, como soporte
TrueType, que antes suministraban programas externos.
Los módulos pueden cargarse usando el comando Load o usando una SubSection. El uso de una
SubSection activa las opciones que se quieren pasar al módulo.
Sección InputDevice
Es una de las muchas secciones que puede repetirse en el archivo de configuración. Cada dispositi-
vo (ratón, teclado, pantalla táctil, . . . ) tiene su propia sección InputDevice.
Define simplemente un dispositivo de entrada disponible. No implica que este dispositivo de hecho se
use. La sección ServerLayout asociará este dispositivo con una presentación en pantalla.
Sección Device
Esta sección define una tarjeta de vı́deo. Como con muchas de las otras secciones, no implica que
el dispositivo se esté usando, sólo que está disponible. Al igual que que la mayorı́a de las secciones, la
sección Device usa un comando Identifier para nombrar a este dispositivo.
El comando Driver indica a XFree86 qué módulo cargable debe usar para este dispositivo.
Los controladores de dispositivos suelen aceptar multitud de opciones.
Sección Monitor
Esta sección define un monitor que esté disponible para su uso, pero no implica que esté usando en
realidad. Tampoco asocia al monitor con una tarjeta de vı́deo. Esto se hará en la sección Screen. Cada
sección Monitor tiene un comando Identifier para nombrarlo.
Todos estos rodeos pueden hacer parecer el sistema confuso, pero hacen que XFree86 sea enorme-
mente flexible. Al definir el monitor independiente de la tarjeta de vı́deo, es mucho más fácil definir las
configuraciones multipantalla.
Sección Screen
Esta sección combina un Monitor y un Device, definidos en las secciones anteriores, para crear una
pantalla lógica. También define una profundidad de color predeterminada, o el número de bits de color
por pixel.
Dentro de esta sección se encuentran una o más subsecciones Display. Estas subsecciones definen las
combinaciones de profundidad de color/resolución para esta pantalla. También suministran el tamaño de
los espacios de visualización o de la pantalla virtual. Después de seleccionar una pantalla usando una
presentación o la opción de la lı́nea de comandos --screen, la profundidad de color de ese momento
determinará qué visualización se usará. La profundidad de color puede configuarse usando la opción de la
lı́nea de comandos --depth, o se usará la profundidad de color predeterminada.
Sección ServerLayout
Esta sección define una presentación de pantallas y de dispositivos de entrada. Se puden definir una
o más pantallas. Si se definen varias pantallas, las opciones indicarán a XFree86 dónde se encuentra
fı́sicamente una con relación a la otra. Por ejemplo:
Section "ServerLayout"
Identifier "Main Layout"
Screen "Screen 1" 0
Screen "Screen 2" 1 RighOf "Screen 1"
Screen "Screen 3" Relative "Screen 1" 2048 0
EndSection

Aquı́ se muestra que Screen 1 está arriba, a la izquierda, Screen 2 se encuentra justo a la derecha de
Screen 1, y Screen 3 esta 2048 pixels a la derecha de Screen 1. Esto le permite distribuir sus ventanas en
varios monitores y moverse entre ellos con facilidad. Sin embargo, de manera predeterminada, no puede
tener ventanas que estén solapadas entre varios monitores.
Al usar un nuevo módulo llamado Xinerama, se pueden tratar varios monitores como si fuese un
único espacio de trabajo, moviendo las ventanas alrededor de ellos sin fragmentarlas. Xinerama ha de ser
soportado por el gestor de ventanas, en mi caso que uso Enlightenment si se puede.
Sección ServerFlags
Esta sección define varios indicadores de opción de Xfree86. Las configuraciones predeterminadas pa-
ra estos indicadores son válidas en casi todas las situaciones y necesitarán modificaciones en contadas
ocasiones. Si se necesita investigar estas opciones, los comentarios que se encuentran en el archivo de
configuración son bastante clarificadores.
Ejemplo de un archivo /etc/X11/XF86Config-4
Cuadro 6.1: Archivo /etc/X11/XF86Config-4
# XF86Config-4 (XFree86 X Window System server configuration file)

#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type "man XF86Config-4" at the shell prompt.)
#
# This file is automatically updated on xserver-xfree86 package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xfree86
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following commands as root:
#
# cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom
# md5sum /etc/X11/XF86Config-4 >/var/lib/xfree86/XF86Config-4.md5sum
# dpkg-reconfigure xserver-xfree86
Section "Files"
FontPath "unix/:7100" # local font server
# if the local font server has problems, we can fall back on these
FontPath "/usr/lib/X11/fonts/misc"
FontPath "/usr/lib/X11/fonts/cyrillic"
FontPath "/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/Type1"
FontPath "/usr/lib/X11/fonts/CID"
FontPath "/usr/lib/X11/fonts/Speedo"
FontPath "/usr/lib/X11/fonts/100dpi"
FontPath "/usr/lib/X11/fonts/75dpi"
EndSection
Section "Module"
Load "GLcore"
Load "bitmap"
Load "dbe"
Load "ddc"
Load "dri"
Load "extmod"
Load "freetype"
Load "glx"
Load "int10"
Load "record"
Load "speedo"
Load "type1"
Load "vbe"
EndSection
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "keyboard"
Option "CoreKeyboard"
Option "XkbRules" "xfree86"
Option "XkbModel" "pc105"
Option "XkbLayout" "es"
EndSection

Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/psaux"
Option "Protocol" "PS/2"
Option "Emulate3Buttons" "true"
Option "ZAxisMapping" "4 5"
EndSection
Identifier "Generic Mouse"
Driver "mouse"
Option "SendCoreEvents" "true"
Option "Device" "/dev/input/mice"
Option "Protocol" "ImPS/2"
Option "Emulate3Buttons" "true"
Option "ZAxisMapping" "4 5"
EndSection
Section "Device"
Identifier "Generic Video Card"
Driver "vesa"
Option "UseFBDev" "true"
EndSection
Section "Monitor"
Identifier "Generic Monitor"
HorizSync 28-50
VertRefresh 43-75
Option "DPMS"
EndSection
Section "Screen"
Identifier "Default Screen"
Device "Generic Video Card"
Monitor "Generic Monitor"
DefaultDepth 24
SubSection "Display"
Depth 1
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
Depth 4
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
Depth 8
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
Depth 15
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
Depth 16
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
Depth 24
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
EndSection
Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
InputDevice "Generic Mouse"
EndSection
Section "DRI"
Mode 0666
EndSection
6.1.2. Arrancar X-Windows

Para entrar en el entorno X-Windows simplemente es necesario ejecutar:
$startx
Para poder elegir entre que sistema de ventanas queremos arrancar tenemos que modificar el archivo
de configuración de usuario ˜/.xinitrc.
$vi ~/.xinitrc, . . . para editar el archivo.
Añadir las siguientes lı́neas para arrancar KDE:
#!/bin/sh
startkde

Añadir las siguientes lı́neas para arrancar GNOME:
#!/bin/sh
gnome-session
Si el archivo no está vacı́o, probablemente la última lı́nea sea un comando exec. Es necesario cambiarlo
por la opción que hayamos escogido.
6.2. Gestores de ventanas

El gestor de ventanas se preocupa de dibujar los bordes, usar el color y hacer que el entorno sea
agradable a la vista. Sólo se requiere usar las llamadas estándares al subsistema X-Windows para dibujar
sobre la pantalla. El gestor de ventanas no dicta cómo debe utilizar las ventanas la propia aplicación. Esto
significa que los programadores de aplicaciones tienen la flexibilidad adecuada para desarrollar la interfaz
de usuario más intuitiva para la aplicación en particular.
Son programas clientes de las “X”, forman parte del entorno de escritorio o, en otros casos, se ejecutan
independientes de un escritorio. Su propósito principal es controlar la forma en que las ventanas gráficas
son posicionadas, redimensionadas o movidas. Controlan las barras de tı́tulos, el comportamiento del foco,
los vı́nculos del botón del ratón y teclas especificadas por el usuario.
Los gestores de ventanas generalmente son más pequeños que los escritorios y están más orientados
hacia usuarios expertos, que se sienten más a gusto con un interfaz de lı́nea de comandos.
Como las “X” no especifican un gestor de ventanas en particular, a lo largo de los años han aparecido
muchos. Algunos de los más populares para Linux son fvwm2, Window Maker, blackbox y AfterStep. Mu-
chos gestores estan basados bien en el Tab Window Manger, un administrador de ventanas muy simple y
que consume pocos recursos, o bien en NeXTSTEP, muy completo y altamente configurable.
Paso a describir las caracterı́sticas de los más extendidos, aunque no todos están aquı́, existen muchos
otros:
twm: Tab Windows Manager, gestor de ventanas minimalista que proporciona el conjunto de utili-
dades más básico de cualquier otro.
fvwm2: F Virtual Windows Manager, un derivado de twm que incorpora un aspecto visual en 3D y
tiene menos requisitos de memoria. Es uno de los mas extendidos.
AfterSTEP: Emula la interfaz NeXT y está basado en fvwm2.
wmaker: WindowMaker, completı́simo gestor de ventanas GNU diseado para emular el aspecto del
entorno NeXT.
blackbox: También inspirado en NeXT. Es un muy ligero y rápido.
Enlightenment: Era el gestor predeterminado de GNOME. Es muy grande, pero muy atractivo a la
vista. Posiblemente es el más configurable de todos.
Sawfish: Enormemente configurable, pero mucho más ligero que Enlightenment es ahora el gestor
por defecto en el entorno de escritorio GNOME, pero puede ser usado sin él. Se está convirtiendo
rápidamente en uno de los gestores con más aceptación.
Kwin: El gestor de ventanas KWin es el gestor por defecto para el entorno KDE. Soporta temas
personalizados.

Estos gestores pueden ejecutarse sin los entornos de escritorio para poder observar sus diferencias,
mediante el siguiente comando:
$xinit -e <path-gestor-ventanas>
Donde <path-gestor-ventanas> es el path del archivo binario del gestor de ventanas. Si no sabemos
el path, lo podemos buscar con el comando which.
También existe un paquete llamado wmanager que permite seleccionar el gestor de ventanas al arrancar
las “X”.
6.3. Entornos de escritorio

A diferencia de los gestores de ventanas, los escritorios incluyen la posibilidad de colocar archivos
y directorios directamente sobre el fondo del mismo. Incluyen la capacidad de arrastrar y soltar, esto
permite que los iconos que representan archivos sean arrastrados con el ratón y soltados sobre un icono
que representa una aplicación. La aplicación se abrirá entonces, utilizando el archivo. Los escritorios
también pueden suministrar otras aplicaciones.
En general, los escritorios están orientados a los usuarios más novatos (aunque los usuarios avanzados
también los encuentran increı́blemente útiles). A menudo, un usuario de escritorio puede efectuar todo su
trabajo sin invocar nunca a una lı́nea de comandos.
Desde la aparición de KDE 3.3, parece haber eclipsado al resto de entornos de escritorio, GNOME
incluido. Ello es debido a que han desarrollado un interfaz más versátil y agradable a la vista.
Al final, la elección del gestor de ventanas es solo cuestion de gustos. En mi caso, para la elaboración
del proyecto he utilizado GNOME como entorno de escritorio y las bibliotecas KDE para ejecutar la
aplicación Kile, un editor de textos LATEX.
6.3.1. Kde
KDE1 es el entorno de escritorio que actualmente copa el mercado. Es ligeramente diferente de los
gestores de ventanas tı́picos. En lugar de describir cómo se debe ver la interfaz, KDE proporciona un
conjunto de bibliotecas que, si se usan, permiten a una aplicación mejorar algunas caracterı́sticas especiales
que no las ofrecen el resto. Esto incluye cosas como soporte a pinchar y arrastrar, soporte de impresión
estandarizado, etc.
El punto negativo de este tipo de técnicas de gestión de ventanas es que una vez que una aplicación
se diseña para ejecutarse con KDE, requiere KDE para trabajar. Esto es un gran cambio con respecto a
los primeros gestores de ventanas donde las aplicaciones eran independientes del gestor.
Esta basado en las bibliotecas Qt3. Desde el punto de vista del programador, KDE ofrece unas biblio-
tecas que son mucho más sencillas de usar que el trabajo directo con la interfaz “X”. Se ofrece un conjunto
de herramientas orientadas a objetos estándar que permite construir otras herramientas, algo que sólo
está disponible con X-Windows.
1K Desktop Environment, entorno de escritorio K.

6.3.2. Gnome
Hasta hace pocos años habı́a algunos problemas con las restricciones de licencias impuestas por los
desarrolladores de la biblioteca Qt3, en la que KDE está basado. Estaba prohibido el uso comercial de
KDE sin pagar derechos. El proyecto GNOME1 comenzó debido a esta resticción.
Hace un tiempo se revisó la licencia de KDE. La licencia revisada, conocida como QPL, es ahora más
abierta y permite su uso comercial. Sin embargo, es distinta la licencia GPL y el estilo de licencias de
Berkley usado por la mayorı́a de los paquetes que usan las distribuciones Linux.
Tanto GNOME, como KDE, ofrece un entorno de escritorio completo y un marco de aplicaciones para
desarrollo tan bueno como de fácil uso. Lo que hace a GNOME diferente es cómo alcanza sus objetivos.
A diferencia de KDE, GNOME no es un gestor de ventanas en si mismo. Necesita apoyarse en un
gestor de ventanas externo, que se encuentra en lo más alto de su estructura y muestra la apariencia ge-
neral del escritorio. El gestor de ventanas por defecto es Sawfish, pero contamos con multitud de opciones
disponibles (Vease seccion 6.2
Esta basado en las bibliotecas GTK+2 que permiten el desarrollo del entorno y las caracterı́sticas
de gestión de sesión, que nosotros como usuarios no vemos. Desde el punto de vista del desarrollador,
GNOME es muy interesante. Define sus interfaces con el resto del mundo mediante tecnologı́a CORBA2 .
De esta manera, cualquier sistema de desarrollo que pueda comunicarse usando CORBA puede utilizarse
para desarrollar aplicaciones compiladas en GNOME.
6.3.3. Otros entornos de escritorio

No solo existen KDE o GNOME, también podemos encontrar estos otros entornos de escritorio:
CDE3 : Desarrollado por algunos fabricantes de Unix, es uno de los más primitivos. A sido portado
a Linux, pero no es libre ni gratuito.
XFce: Esta basado en las bibliotecas GTK+2, al igual que GNOME, y ofrece una interfaz similar
a CDE. Su ventaja es que es sencillo y utiliza pocos recursos, es ideal para maquinas con poca
capacidad o aquellos que prefieran ahorrar recursos para sus aplicaciones. Trabaja especialmente
bien con programas GNOME, peor también maneja sin dificultad aplicaciones KDE.
1 Entornode modelo de objeto de red GNU.

2 Common Object Request Broker Architecture, es un estándar que establece una plataforma de desarrollo de sistemas
distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos.
3 Common Desktop Environment, entorno de escritorio común.

Capı́tulo 7
Infraestructura de redes
Para podernos situar en el marco de las configuraciones de redes, primero debemos conocer una serie
de conceptos y arquitecturas que se describen en las secciones siguientes del presente capı́tulo.
Esta sección se ha basado en la documentación que se puede obtener en:

http://eia.udg.es/ ˜atm/tcp-ip/index.html
7.1. Arquitectura de redes (Modelo OSI)

Antes de conocer realmente los servicios de red y la seguridad en redes, primero se tiene que conocer
la arquitectura de redes, cómo son y cómo están diseñadas.
Cada diseño de red se divide en siete partes lógicas, cada una de las cuales controla una parte diferente
de la tarea de comunicación. Este diseño de siete capas se denomina Modelo de referencia OSI. Dicho
modelo fue creado por la Organización internacional de estándares (ISO, International Standard Organi-
zation) para proporcionar un modelo lógico para la descripción de comunicaciones de red y ayuda a los
suministradores a estandarizar los equipos y el software. La tabla 7.1 muestra la composición del modelo.
Cuadro 7.1: Estructura del modelo de referencia OSI

N.o de capa OSI Nombre de la capa Protocolos de ejemplo
Capa 7 Aplicación DNS, FTP, HTTP, SMTP, Telnet
Capa 6 Presentación XDR
Capa 5 Sesión Pipes con nombre, RPC
Capa 4 Transporte NetBIOS, TCP, UDP
Capa 3 Red ARP, IP, IPX, OSPF
Capa 2 Enlace de datos Acrcnet, Ethernet, Token Ring
Capa 1 Fı́sica Coaxial, Fibra óptica, UTP
Capa Fı́sica
Esta capa es el medio fı́sico real que contiene los datos. Los distintos tipos de medios siguen diferentes
estándares. Por ejemplo, el cable coaxial, el par trenzado (UTP, Unshielded Twisted Pair) y el cable de fibra
óptica sirven para distintos propósitos: el cable coaxial se usa en instalaciones LAN antiguas ası́ como en
servicios de Internet a través de redes de TV por cable. UTP se usa normalmente en cableados domésticos,
mientras que la fibra óptica se suele usar para conexiones de distancias largas que requieren una capacidad
de carga alta.
Capa de enlade datos

Esta capa relaciona los distintos elementos del hardware de interfaz de red en la red. Ayuda a codificar
los datos y a colocarlos en el medio fı́sico. También permite que los dispositivos se identifiquen entre
sı́ cuando intentan comunicarse con otro nodo. Un ejemplo de una dirección de la capa de enlace de datos
es la dirección MAC de nuestra tarjeta de red. En una red Ethernet, las direcciones MAC son el medio por
el que se puede encontrar a nuestro ordenador en la red. Las empresas utilizaban muchos tipos diferentes
de estándares de enlace entre 1970 y 1980, la mayorı́a determinados por su suministrador de hardware.
IBM utilizaba Token Ring para sus redes de PC y SNA para la mayor parte de su hardware más grande;
DEC utilizaba un estándar diferente y Apple otro. La mayorı́a de las empresas actuales utilizan Ethernet
porque es el más extendido y económico.
Capa de red
Esta capa es la primera parte que podemos ver cuando interactuamos con sistemas de red TCP/IP. La
capa de red permite las comunicaciones entre diferentes redes fı́sicas utilizando una capa de identificación
secundaria. En los sistemas de red TCP/IP, se trata de una dirección IP. Esta dirección IP en nuestro
ordenador nos ayuda a enrutar los datos de un lugar a otro de la red y sobre Internet. Esta dirección
es un número único para identificar nuestro ordenador en una red basada en IP. En algunos casos, este
número es único para un ordenador; ninguna otra máquina en Internet puede tener dicha dirección. Es
el caso de las direcciones IP normales que se pueden enrutar públicamente. En las LAN internas, las
máquinas normalmente utilizan bloques de direcciones IP. Estas se han reservado sólo para su uso interno
y no se enrutarán por Internet. Estos números pueden no ser únicos de una red a otra, pero siguen siendo
únicos dentro de cada LAN. Aunque dos ordenadores pueden tener la misma dirección IP privada sobre
diferentes redes internas, nunca tendrán la misma dirección MAC, ya que es un número de serie asignado
por el fabricante. Existen excepciones a esta regla pero, en general, la dirección MAC identificará de forma
única dicho ordenador o al menos, la tarjeta de interfaz de red (NIC, Network Interface Card) dentro del
ordenador.
Capa de transporte
Este nivel lleva el paquete de datos desde el punto A hasta el punto B. Es la capa donde residen los
protocolos TCP y UDP.
El protocolo de control de transmisión (TCP, Transmission Control Protocol) básicamente asegura que
los paquetes se envı́an y se reciben con consistencia en el otro punto. Permite una corrección de errores a
nivel de bits, una retransmisión de segmentos perdidos y una reorganización de los paquetes y el tráfico
desfragmentado.
El protocolo de datagramas de usuario (UDP, User Datagram Protocol) es un esquema más ligero
empleado para tráfico multimedia y para transmisiones cortas, como las solicitudes DNS. También efectúa
detección de errores, pero no proporciona ninguna facilidad para reorganizar los datos o asegurar la llegada
de datos. Esta capa y la capa de red es donde operan la mayorı́a de los cortafuegos.
Capa de sesión
La capa de sesión se encuentra implicada principalmente en la configuración de una conexión y en
su cierre posterior. También realiza autenticaciones para determinar qué partes pueden participar en una
sesión. Se utiliza principalmente en aplicaciones especı́ficas.
Capa de presentación
Esta capa controla determinadas codificaciones y descodificaciones requeridas para presentar los datos
en un formato legible para la parte receptora. Algunas formas de cifrado pueden considerarse como pre-
sentación. La distinción entre la capa de aplicación y la de sesión es muy delicada y algunos afirman que
la capa de presentación y la de aplicación son básicamente iguales.

Capı́tulo 7. Infraestructura de redes 61
Capa de aplicación
Este nivel final es donde el programa de la aplicación obtiene los datos, que pueden ser FTP, HTTP,
SMTP, etc. Aquı́, algunos programas se encargan de controlar los datos reales dentro del paquete y se
ajustan las soluciones profesionales de seguridad, ya que la mayorı́a de los ataques se producen en esta
capa.
7.2. Direcciones IP
Cada computador (host) y cada dispositivo de encaminamiento (router) tendrá una dirección única
cuya longitud será de 32 bits, que será utilizada en los campos dirección origen y dirección destino de
la cabecera IP. Esta dirección consta de un identificador de red y de un identificador de host. La direc-
ción está codificada para permitir una asignación variable de los bits utilizados al especificar la red y el
computador. La dirección IP más pequeña es la 0.0.0.0 y la mayor es 255.255.255.255.
Existen tres clases de redes que se pueden clasificar teniendo en cuenta la longitud del campo de red y
del campo host. La clase a la que pertenece una dirección puede ser determinada por la posición del primer
0 en los cuatro primeros bits. Las direcciones están codificadas para permitir una asignación variable de
bits para especificar la red y el host.
Clase A: Pocas redes, cada una con muchos ordenadores. 1 bit de selección de clase A, 7 bits de red
y 24 bits de host (Por ejemplo ARPANET)
Clase B : Un número medio de redes, cada una con un número medio de ordenadores. 2 bits de
selección de clase B, 14 bits de red y 16 bits de host.
Clase C : Muchas redes, cada una con pocos ordenadores. 3 bits de selección de clase C, 21 bits de
red y 8 bits de host (LANs).
Clase D: Permite hacer multitransmisión (o multicasting) en la cual el datagrama se dirige a múltiples
ordenadores. Podemos enviar un paquete IP a un grupo de máquinas que por ejemplo pueden estar
cooperando de alguna manera mediante la utilización de una dirección de grupo
Clase E : No se utiliza, queda reservado para otros usos
Figura 7.1: Rango de direcciones IP
En el siguiente cuadro podemos observar el número de redes y de ordenadores por red en cada una de
las tres clases primarias de direcciones IP.

Cuadro 7.2: N.o de Hosts por red
Clase Bits en el prefijo Máximo n.o de redes Bits en el sufijo Máximo n.o de
hosts por red
A 7 128 24 16777216
B 14 16384 16 65536
C 21 2097152 8 256
Normalmente las direcciones se suelen escribir en notación decimal con puntos (calculando cada ocho
bits). Por ejemplo, la dirección 82CE7C0D (1000 0010 1100 1110 0111 1100 0000 1101 que es de clase B)
se escribe como 130.206.124.13.
82 = 8*16 + 2 = 128 + 2 = 130
CE = C*16 + E = 12 * 16 + 14 = 192 + 14 = 206
7C = 7 * 16 + C = 112 + 12 = 124
0D = D = 13
Algunas direcciones de red se utilizan como direcciones especiales (Vease figura 7.2):
Este host: La dirección 0.0.0.0 significa esta red o este host y únicamente es usada por los ordenadores
cuando son arrancados, sin que vuelva a utilizarse posteriormente. De esta forma las máquinas se
pueden referir a su propia red sin saber su número, pero la clase s ha de ser conocida para saber
cuantos ceros debe incluir.
Un host de esta red : Poniendo el campo red todo a ceros (es necesario saber la clase de la red para
decidir el número de ceros).
Difusión de red local o limitada: La dirección 255.255.255.255 (todos 1s) se usa como dirección para
indicar todos los ordenadores de la red indicada y es utilizada para hacer difusión.
Difusión de una red distante o dirigida (broadcast): También se puede hacer difusión a una red
distante poniendo la dirección de la red y rellenando el campo ordenador con 1s.
Retrociclo: Las direcciones 127.xx.yy.zz se reservan para pruebas de realimentación (localhost). Los
paquetes que tienen esta dirección no son enviados por la red sino que son procesados localmente y
se tratan como si fueran paquetes de entrada (pasan por la tarjeta de red, pero sin salir del host).
Esto permite que los paquetes se envı́en a la red local sin que el transmisor conozca su número. Esta
caracterı́stica también se usa para la detección de fallos en el software de red.
Figura 7.2: Direcciones IP reservadas

Para estar seguros de que las direcciones Internet son únicas, todas las direcciones de Internet son
asignadas por un autoridad central. La IANA (Internet Assigned Number Authority) tiene el control
sobre los números asignados. Sin embargo, cuando una organización quiere una dirección debe obtenerla
de INTERNIC (Internet Network Information Center). La autoridad central sólo es necesaria para asignar
la porción de la dirección correspondiente a la red, cuando una organización ya tiene su prefijo, puede
asignar un único sufijo a cada ordenador sin contactar con la autoridad central.
Una máquina puede estar conectada a varias redes y tener una dirección IP diferente en cada red. En
este caso recibe el nombre de “multihomed”. Esto se utiliza para aumentar la seguridad, si una red falla el
host aún está conectado a internet utilizando la otra red. Por otra parte, también es usado para aumentar
el rendimiento de la red, pues permite enviar directamente el tráfico a una red en concreto sin tener que
pasar por los dispositivos de encaminamiento.
Que la dirección de la red esté guardada en la dirección Internet tiene algunos inconvenientes:
Si la dirección IP identifica la red a la que se conecta el ordenador, no al ordenador que tenemos

conectado, no es posible asignarle a un ordenador una dirección IP permanente. Por lo tanto, si
movemos un ordenador de una red a otra su dirección IP debe cambiar. Este problema se da cuando,
por ejemplo, nos llevamos un ordenador portátil de un sitio a otro y queremos conectarlo a la red.
Como el número de ordenadores asignados a la clase C (255) puede resultar insuficiente en muchos
casos y que la transición a la clase B no es fácil debido a que muchos programas no permiten que
una red fı́sica tenga múltiples direcciones, no se pueden introducir nuevas direcciones poco a poco y
es necesario reconfigurar toda la red para la nueva clase.
Como existe la facilidad de que una máquina pueda estar conectada a dos redes y por lo tanto
tenga dos direcciones diferentes, el encaminamiento se hace teniendo en cuenta la dirección IP, el
comportamiento de los paquetes puede ser totalmente diferente dependiendo de la dirección que
estemos utilizando. Esto puede resultar sorprendente para los usuarios.
En algunos casos, el conocer una dirección IP puede resultar insuficiente para alcanzar la máquina
que utiliza esta dirección. Debido a la configuración de la red y dependiendo de por donde se enruten
los paquetes en nuestra red, algunos equipos pueden resultar inalcazables.
7.2.1. Datagramas
Los datos proporcionados por la capa de transporte son divididos en datagramas y transmitidos a
través de la capa de red (capa internet), por el protocolo IP. Durante el camino puede ser fragmentado en
unidades más pequeñas, si deben atravesar una red o subred cuyo tamaño de paquete sea más pequeño.
En la máquina destino, estas unidades son reensambladas para volver a tener el datagrama original que
es entregado a la capa de transporte.
En la cabecera hay una parte fija de 20 bytes y una parte opcional de longitud variable. En la figura
7.3 se puede observar el formato de la cabecera IP.
7.2.2. Encaminamiento IP (router y gateway)

Cuando un paquete llega a un dispositivo de encaminamiento, se debe determinar cuál es la dirección
del siguiente dispositivo de encaminamiento teniendo en cuenta la dirección IP destino que hay almace-
nada en el campo correspondiente del paquete y de la información que hay almacenada en las tablas de
encaminamiento. Hay que tener en cuenta que es necesario realizar una conversión entre la dirección IP
y la dirección MAC (cuando el enlace entre los dos dispositivos de encaminamiento sea una LAN) que se
efectúa de manera automática mediante el protocolo ARP.
Esta tabla puede ser estática o dinámica. En el primer caso puede contener rutas alternativas que
serán utilizadas cuando algún dispositivo de encaminamiento no esté disponible. Las tablas dinámicas son
más flexibles cuando aparecen errores o congestión en la red. Estas tablas también pueden proporcionar
servicios de seguridad y de prioridad, por ejemplo, para asegurarse que a ciertos datos no se les permita
pasar por determinadas redes.

Figura 7.3: Cabecera del datagrama IP
Otra técnica de encaminamiento es el encaminamiento en la fuente. En este caso, como ya comentamos

anteriormente, el ordenador origen incluye en la cabecera del paquete la dirección de los dispositivos de
encaminamiento que debe utilizar el paquete.
7.2.3. Máscaras de red y notación de barra inclinada

El propósito de configurar una máscara es, en primer lugar, decirle al sistema qué bits de la dirección
IP corresponden al componente de red y qué bits corresponden al componente host. Basados en estos dos
componentes de red, un host puede determinar cuál es su dirección de broadcast o de difusión de red (es
decir, la dirección IP que corresponde al envı́o de un paquete a todas las máquinas de la red local).
Normalmente nos referiremos a las redes IP como máscaras de red o con una barra inclinada y un
número. Ambas son formas de definir el tamaño de la red. Para entenderlas tenemos que conocer un poco
de la estructura de la dirección IP. Una dirección IPv4 estándar esta formada por 32 bits. Normalmente
se representa en cuatro secciones, con cuatro octetos de 8 bits cada una. Cada octeto, normalmente se
convierte de un conjunto de bits binarios, a un numero decimal para facilitar su lectura. Por tanto, cuando
vemos 192.168.1.1, el ordenador ve lo siguiente:
11000000 10101000 00000001 00000001
Una máscara de red normalmente es un conjunto de cuatro números que nos indica dónde finalizan los
bits de red y donde comienzan los de hosts. Normalmente tiene la siguiente apariencia:
255.255.255.0
Una forma rápida de calcular el tamaño de una red representada por una máscara de red es restar cada
octeto de 256 y multiplicar dichos números entre sı́. Por ejemplo, la máscara de red de 255.255.255.248
describe una red de 8 IPs porque:
(256-255) * (256-255) * (256-255) * (256-248) = 8
Una máscara de red de 255.255.255.0 describe una red de 256 IPs ya que:
(256-255) * (256-255) * (256-255) * (256-0) = 256

Y por último, una máscara de red de 255.255.0.0 describe una red de 65.536 direcciones IP porque:
(256-255) * (256-255) * (256-0) * (256-0) = 65.536
La notación de barra inclinada es algo más difı́cil de entender, aunque utiliza el mismo concepto. El
número que se encuentra detras de la barra inclinada indica la cantidad de bits que describen la dirección
de red (para una explicación con más detalle, véase la sección 7.2.4). Si restamos de 32 dicho número
obtenendremos el número de bits que desciben la dirección de host dentro de la red local. Por ejemplo la
notación 192.168.0.0/24 describe una red que empieza en 192.168.0.0 que contiene 256 direcciones IP de
tamaño (es decir, el mismo tamaño que el de arriba con una máscara de red de 255.255.255.0).
Los 32 bits en una dirección IP menos los 24 bits para el prefijo de red deja 8 bits activados (igual a 1)
para los hosts de la red local. Un número binario de bits de 11111111 convertido en decimal es 255. Si las
matemáticas binarias nos resultan complicadas, podemos utilizaremos la siguiente tabla para recordarlo.
Cuadro 7.3: Notación de barra inclinada en IPs

Notación de barra inclinada Tamaño de la red
/24 256 direcciones IP
/32 1 dirección IP
7.2.4. Subneting (CIDR)

Incluso si tenemos una clase de direcciones A o B, no es realista configurar la red como un gran grupo
de máquinas. Aparte de resultar una pesadilla para administrar, resulta muy difı́cil encontrar una red
capaz de tener tantas máquinas agrupadas juntas. Por ejemplo, Ethernet sólo permite configurar 1.024
hosts por segmento.
Para resolver este problema, estas redes enormes se dividen en subredes más pequeñas. Esto se hace
expandiendo el número de bits usados para representar la dirección de red, una técnica conocida como
subneting ó CIDR (Classless Inter Domain Routing, enrutamiento interdominio sin clases) debido a que
viola la descripción de las redes A, B y C.
Un lugar tı́pico para ver esto es en las redes IP privadas. La mayorı́a de las organizaciones no tienen 16
millones de computadoras, sino que cada división de la organización se convierte en una subred. La mayorı́a
de las veces, la elección razonable es escoger una máscara de 24 bits (255.255.255.0) para conseguir 254
máquinas por red (recordamos que .0 es la dirección de red y .255 la dirección de broadcast), un nivel
bastante razonable de agrupamiento de máquinas.
Cuando se utilizan subredes, en las tablas de encaminamiento se agregan entradas de la forma (ésta
red, subred, 0) y (ésta red, ésta subred, 0). De esa forma, un dispositivo de encaminamiento de la subred
k sabe cómo llegar a todas las subredes y a todos los hosts de la subred k. No necesita saber nada de los
hosts de otras subredes. Cada encaminador lo que debe hacer es un AND booleano con la máscara de la
subred para eliminar el número de host y buscar la información resultante en sus tablas.

7.2.5. Enmascaramiento IP (NAT, Network Adress Translation)

Un escenario común para los usuarios familiares y de oficinas pequeñas es tener una cuenta de conexión
punto a punto para varias computadoras que quieran usarla (con frecuencia, al mismo tiempo). Para hacer
esto aún más difı́cil, sólo tenemos una dirección IP.
El enmascaramiento de IP resuelve este problema permitiendo a nuestro sistema Linux hacer dos
trucos: actuar como un enrutador y realizar la traslación de direcciones de red, NAT.
Nuestra red LAN, usa un rango de direcciones IP privadas, para redes pequeñas, el rango 192.168
trabaja bien.
Lo que queremos es que nuestro servidor enrute los paquetes entre las máquinas de la LAN de forma
que cuando vayan a Internet, parezca que los origina él. Cuando vuelve un paquete como respuesta, el
servidor sabe que realmente el paquete va destinado a una máquina de la red y se lo envı́a.
No se puede asumir como única forma de funcionamiento el enmascaramiento de IP con un router.
Una interfaz de red ppp0 puede ser cualquier tipo de interfaz de red. Por ejemplo, en una configuración
de firewall la interfaz de salida puede ser, simplemente, una segunda tarjeta Ethernet que la une a la red
corporativa.
Configuración de IPTables para NAT

Lo primero que necesitamos es asegurarnos de que tenemos cargado el módulo iptables nat en el kernel.
Después instalaremos el siguiente paquete:

#apt-get install ipmasq
Si nuestra red contiene la red 192.168.1.0 y el servidor conectado a un interfaz ppp0 desde el que se
recibe el acceso a internet. Para realizar el enmascaramiento IP necesitamos utilizar el firewall IPTables,
ejecutamos las siguientes instrucciones
#iptables -t nat -F : Configura el comportamiento de iptables, le dice que va a usar nat y quita
las politicas actuales para nat (-F)
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0.0.0.0/0 -j MASQUERADE :

Añade la regla de enmascaramiento. Todos los paquetes que salgan por enrutados desde la red a
Internet se enmascarán
#echo 1 > /proc/sys/net/ipv4/ip_forward : Activamos el ip forward
El mecanismo de enmascaramiento se ocupa de reescribir el paquete y dejarlo en Internet. Cuando un

paquete entra en la interfaz ppp0 desde Internet, Linux comprueba con el mecanismo de enmascaramiento
si el paquete está realmente destinado para alguien de dentro de la red. Si es ası́, el paquete se desenmascara
y después se envı́a al emisor original de la LAN.
Proxies: Problemas con el enmascaramiento

Desafortunadamente, no todos los protocolos enmascaran bien. FTP es un ejemplo perfecto de esto.
Cuando un cliente FTP se conecta a un servidor FTP, empieza conectándose al puerto 21 del servidor. El
cliente pasa toda la información de usuario/contraseña a través de este puerto. Sin embargo, cuando el
cliente pide al servidor que le envı́e un archivo, el servidor inicia una conexión nueva de vuelta al cliente. Si
el cliente está enmascarado, entonces la máquina probablemente rechace la conexión porque no tendrá un
programa escuchando en ese puerto y la transferencia se interrumpirá.
FTP es uno de los muchos protocolos que hacen cosas extrañas. A fin de permitir el enmascaramiento de
estos protocolos, debemos colocar un proxy especial. IPTables esta equipado con los proxies más comunes:
FTP, IRC y otros. Para usar estos módulos simplemente hay que incluir la sentencia insmod en tiempo
de arranque. Por ejemplo, podemos añadir a los scripts de arranque:
insmod ip_masq_ftp
insmod ip_masq_irc

También lo podemos hacer con reglas, añadiendo el redireccionamiento de los puertos que utilice el
protocolo. Esto se observa en el siguiente ejemplo:
Enviamos el tráfico que entra, dirigido por eth0 al puerto 80 (web), a nuestro proxy squid (transparente)
por el puerto 3128 de nuestra máquina:
#iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
7.3. Resolución de direcciones

Dos ordenadores de una red fı́sica sólo pueden comunicarse si cada uno de ellos conoce la dirección
fı́sica del otro. Cuando enviamos un paquete IP entre estas dos máquinas sólo indicamos la dirección IP.
Por lo tanto es necesario tener un mecanismo que nos proporcione la correspondencia entre la dirección
IP y la dirección fı́sica.
Como la dirección IP es virtual, pues es mantenida por software, ningún elemento hardware entiende
la relación: entre el prefijo de la dirección IP y la red, y la relación entre el sufijo de la dirección IP y el
host.
La traslación entre direcciones IP y direcciones fı́sicas es local a la red. Un ordenador sólo puede ob-
tener la dirección fı́sica de otro si ambos se encuentran en la misma red fı́sica.
Existen tres mecanismos para hacer la traslación:
El primero utiliza un tabla en cada máquina para almacenar para cada dirección IP la correspon-
diente dirección fı́sica. Cada entrada de la tabla contiene una dirección IP y una dirección fı́sica.
Como existe una tabla para cada red fı́sica, todos las direcciones IP tienen el mismo prefijo. En el
siguiente ejemplo podemos observar la traducción entre dirección IP y dirección fı́sica.
Dirección IP Dirección Ethernet

130.206.124.13 0F:13:26:36:F3:B4
130.203.124.31 A4:34:27:AE:B1:10
El segundo realiza la traducción mediante una función matemática. Aunque muchas tecnologı́as
utilizan direcciones fı́sicas estáticas, algunas usan direccionamiento configurable, es decir, el admi-
nistrador de la red elige tanto la dirección fı́sica como la dirección IP. En este caso, los valores pueden
ser elegidos para que la traslación sea trivial.
El tercero es el más interesante pues usa una computación distribuida en la que los dos ordenadores
intercambian mensajes dinámicamente. En este caso, el ordenador que conoce la dirección IP de otro
ordenador pero desconoce su dirección fı́sica, envı́a un mensaje a la red con la dirección IP conocida
y recibe de la red una respuesta con la dirección fı́sica. Existen dos posibles diseños:
1. En el primero hay uno o más servidores que se encargan de enviar las respuestas. La principal
ventaja de este diseño es que es centralizado y por lo tanto fácil de configurar, gestionar y
controlar. Tiene el inconveniente de que estos servidores pueden ser un cuello de botella en una
red grande.
2. En el segundo diseño, se hace un broadcast de la petición (envı́o a la dirección de difusión de red)
y todos los ordenadores participan en la resolución de la dirección, en concreto responde el que
tiene la dirección pedida. La principal ventaja de este diseño es que el cálculo es distribuido.
Este diseño es el utilizado en el ARP, una de las ventajas de este método sobre tener unos
archivos de configuración es su sencillez. El propio protocolo se encarga de construir las tablas
en lugar de tener que hacerlo el administrador del sistema.

7.3.1. ARP (Adress Resolution Protocol)

En cada máquina se tiene una tabla que identifica la correspondencia que hay entre la dirección fı́sica
y la dirección IP del resto de máquinas. Cuando tenemos que enviar un paquete a una dirección IP de la
que se desconoce la dirección fı́sica entra el funcionamiento el protocolo ARP para actualizar los valores
de la tabla. Este protocolo es el encargado de obtener la dirección fı́sica de una máquina de la que conoce
la dirección IP. Para conseguirlo debe acceder a recursos de bajo nivel.
Únicamente hay dos tipos de mensaje que tienen el mismo formato: petición ARP y respuesta ARP.
Los mensajes ARP van a ser encapsulados directamente en una trama Ethernet. En el campo tipo de
la cabecera de la trama Ethernet es necesario especificar qué contiene un mensaje ARP. El emisor se
debe encargar de poner el valor correspodiente y el receptor de mirar el contenido de ese campo. Como
Ethernet asigna un único valor para los dos mensajes ARP, el receptor debe examinar el campo operación
del mensaje ARP para determinar si es el mensaje recibido es una petición o una respuesta. Es importante
destacar, que este protocolo sólo puede ser utilizado en aquellas redes en las cuales es posible hacer un
broadcast (difusión de red).
Cuando no conocemos la dirección fı́sica de la máquina a la que queremos enviar el mensaje es necesario
enviar tres mensajes; para que esto no se tenga que repetir para cada paquete que queremos enviar y
además se pueda reducir el tráfico, en cada máquina tendremos una pequeña memoria cache en la que
guardaremos una tabla con las parejas de direcciones (fı́sica, IP). Cuando esta tabla esté llena se irán
borrando las más antiguas y las que lleven más tiempo sin ser utilizadas.
7.3.2. RARP (Reverse Address Resolution Protocol)

Cada máquina, además de su dirección fı́sica que está en la tarjeta de red, debe tener guardada en
algún dispositivo la dirección IP que le corresponde.
Pero, ¿cómo una máquina que no disponga de disco duro puede determinar su dirección IP?. El
problema es crı́tico para aquellas estaciones de trabajo que almacenan todos sus ficheros en un servidor
remoto ya que ellas deben utilizar los protocolos de transferencia de ficheros de TCP/IP para obtener su
imagen de arranque inicial.
La idea para encontrar la dirección IP es simple: una máquina que necesita conocer su dirección envı́a
una petición a un servidor que hay en otra máquina y espera hasta que recibe la respuesta. Suponemos
que el servidor tiene acceso a un disco que contiene una base de datos de direcciones IP. En la petición, la
máquina que necesita conocer su dirección IP únicamente debe identificarse a si misma, y de esta manera
el servidor puede buscar su dirección IP y enviarle una respuesta. Tanto la máquina que hace la petición
como el servidor que responde usan direcciones fı́sicas durante su breve comunicación.
¿Cómo puede la máquina conocer la dirección del servidor?. Generalmente no la conoce, lo que hace
es hacer un broadcast (difusión de red) de su petición a todas las máquina de la red local y esperar que
algún servidor responda. De alguna manera lo que hace la máquina es enviar un mensaje diciendo:
“ mi dirección fı́sica Ethernet es XX.XX.XX.XX.XX.XX Sabe alguien cual es mi dirección IP?”
Como podemos ver en esta pregunta, para identificarse, la máquina utiliza su dirección fı́sica lo que
tiene la ventaja de que siempre está disponible y de que es uniforme para todas las máquinas de una red.
En realidad lo que queremos es encontrar la dirección IP de una máquina de la que conocemos su
dirección fı́sica. El protocolo para conseguir esto es el RARP que es una adaptación del ARP visto
anteriormente y que usa el mismo formato de mensaje. Como ocurre con los mensajes ARP, un mensaje
RARP es enviado de una máquina a otra encapsulado en la porción de datos de la trama fı́sica, por ejemplo
en una trama Ethernet.

7.4. Protocolos de red, IP

Entre los protocolos que utilizan IP ‘puro’, es decir encapsulan sus mensajes sobre el protocolo IP,
encontramos los siguientes: ICMP, OSPF, BGP y IGMP.
7.4.1. ICMP (Internet Control Message Protocol)

Permite el intercambio de mensajes de control y de supervisión entre dos ordenadores. Toda anomalı́a
detectada por el protocolo IP provoca el intercambio de mensajes ICMP entre los nodos de la red.
Es un protocolo de control que utilizan los dispositivos de encaminamiento para notificar las incidencias
que pueden haber en una red IP. Proporciona información de realimentación sobre los problemas.
Estos son los problemas que más frecuentemente se encarga de informar:
Un datagrama no puede alcanzar su destino
El dispositivo de encaminamiento no tiene la capacidad de almacenar temporalmente el datagrama-

para poderlo reenviar
El dispositivo de encaminamiento indica a un ordenador que envı́e el tráfico por una ruta más corta
(redireccionamiento de rutas). Cada mensaje se encapsula en un paquete IP y luego es enviado de
la forma habitual. Al utilizar IP no se garantiza que llegue a su destino.
En el siguiente esquema podemos observar los diferentes tipos de mensajes ICMP:
• ICMP(3): Detectar destinos inalcanzables

• ICMP(11): Tiempo excedido
• ICMP(12): Problema de parámetros
• ICMP(4): Petición de control de flujo
• ICMP(5): Redireccionando rutas
• ICMP(0) y ICMP(8): Eco y respuesta a eco (para los pings)
• ICMP(13) y ICMP(14): Marca de tiempo y la respuesta
• ICMP(17) y ICMP(18): Petición de máscara de dirección y la respuesta
• ICMP(15) y ICMP(16): Petición de información y la respuesta
• ICMP(9) y ICMP(10): Petición de rutas y su publicación
7.4.2. OSPF (Open Shortest Path First)

El protocolo OSPF (abrir primero la trayectoria más corta) se usa muy frecuentemente como protocolo
de encaminamiento interior en redes TCP/IP. Cuando se diseñó se quiso que cumpliera los siguientes
requisitos:
Ser abierto en el sentido de que no fuera propiedad de una compañı́a
Que permitiera reconocer varias métricas, entre ellas, la distancia fı́sica y el retardo
Ser dinámico, es decir, que se adaptará rápida y automáticamente a los cambio de la topologı́a
Ser capaz de realizar en encaminamiento dependiendo del tipo de servicio
Que pudiera equilibrar las cargas dividiendo la misma entre varias lı́neas
Que reconociera sistemas jerárquicos pues un único ordenador no puede conocer la estructura com-
pleta de Internet
Que implementara un mı́nimo de seguridad

El protocolo OSPF reconoce tres tipos de conexiones y redes:

Lı́neas punto a punto entre dos dispositivos de encaminamiento.
Redes multiacceso1 con difusión de red (por ejemplo, la mayorı́a de redes LAN).
Redes multiacceso sin difusión (por ejemplo, la mayorı́a de redes WAN de conmutación de paquetes).
La función del OSPF es encontrar la trayectoria más corta de un dispositivo de encaminamiento a
todos los demás. Cada dispositivo de encaminamiento tiene almacenada en una base de datos la topologı́a
de la red de la que forma parte.
7.4.3. Protocolo BGP (Border Gateway Protocol)

El protocolo de ‘pasarela frontera’ se encarga de mover paquetes de una red a otra pero en algunos casos
debe preocuparse de otras cuestiones que no tienen porqué estar relacionadas con el objetivo de mover
los paquetes de la forma más eficiente posible. Es posible que se deban considerar algunas restricciones
relacionadas con cuestiones comerciales o polı́ticas, como por ejemplo:
“Una empresa no hace de red de tránsito para los mensajes de la competencia.”
“Nuestros mensajes no deben pasar por paı́ses enemigos.”
Los diferentes dispositivos de encaminamiento BGP se comunican entre sı́ estableciendo conexiones
TCP. Es fundamentalmente un protocolo de vector distancia en el que cada dispositivo de encamina-
miento mantiene el coste a cada destino y la trayectoria seguida. Estos valores son dados periódicamente
a cada uno de los vecinos enviando mensajes. La esencia de BGP es el intercambio de información de
encaminamiento entre dispositivos de encaminamiento. La información de encaminamiento actualizada se
va propagando a través de un conjunto de redes.
Involucra tres procedimientos funcionales, que son:
Obtener información del vecino

Detectar los vecinos alcanzables
Detectar las redes alcanzables
7.4.4. IGMP (Internet Group Management Protocol)

Es usado, por ejemplo, para informar a los dispositivos de encaminamiento que un miembro del grupo
multicast 2 está en la red conectada al nodo. Está información de los miembros del grupo multicast también
es transmitida al emisor del multicast utilizando este protocolo.
7.5. Protocolos de transporte

Los protocolos de transporte tienen la función de actuar de interficie entre los niveles orientados a la
aplicación y los niveles orientados a la red dentro de la jerarquı́a de protocolos TCP/IP. Se encargan de
ocultar a los niveles altos del sistema el tipo de tecnologı́a a la que se estén conectando los ordenadores.
En la jerarquı́a de TCP/IP se definen dos protocolos de transporte: el UDP y el TCP. El UDP es un
protocolo no orientado a la conexión mientras que el TCP es orientado a la conexión.
1 Diremos que una red es multiacceso si tiene varios dispositivos de encaminamiento que se pueden comunicar con los
demás.
2 Multicast es el envı́o de la información a múltiples destinos simultáneamente usando la estrategia más eficiente para el
envı́o del mensajes sobre cada enlace de la red únicamente una vez y creando copias cuando los enlaces en los destinos se
dividen. En comparación con multicast, los envı́os de un punto a otro se le denomina unicast, y el envı́o a todos los nodos
se le denomina broadcast.

Se definen dos direcciones para relacionar el nivel de transporte con los niveles superior e inferior:
La dirección IP es la dirección que identifica un dispositivo dentro de una red.
El puerto es un número de 16 bits que se coloca en cada paquete y sirve para identificar la aplicación
que requiere la comunicación. La utilidad de los puertos es que permite multiplexar aplicaciones
sobre protocolos del nivel de transporte. Es decir, un mismo protocolo de transporte puede llevar
información de diferentes aplicaciones y estas son identificadas por el puerto.
Para establecer una comunicación entre dos máquinas se ha de utilizar uno de los protocolos de trans-
porte (TCP o UDP) y es necesario conocer tanto el puerto que identifica la aplicación destino como la
dirección IP que identifica el terminal o el servidor dentro del conjunto de redes.
Los datos que se envı́an durante la comunicación son empaquetados por los protocolos del nivel de
transporte. Los bytes que se transmiten en el TCP reciben el nombre de segmento TCP y los que se
transmiten en el UDP el de datagrama UDP.
Para establecer una comunicación de utiliza el modelo cliente/servidor. En este caso, el cliente inicia
la comunicación y para hacerlo necesita conocer la dirección IP asignada al ordenador servidor y el puerto
de la aplicación que identifica la aplicación que se quiere utilizar.
El cliente conoce su dirección IP (dirección origen), la dirección del servidor (dirección destino) y el
puerto que identifica su aplicación cliente. Para que pueda saber el puerto destino que identifica la apli-
cación deseada, se utilizan los llamados puertos conocidos que consiste en un número de puerto reservado
para identificar una aplicación determinada (Véase apéndice E).
El servidor responderá a las peticiones de cualquier cliente. Como el cliente envı́a en el datagrama
UDP y en el segmento TCP tanto el puerto origen como el destino, el servidor conoce el puerto origen
una vez ha recibido una petición.
7.5.1. UDP
Este protocolo es “no orientado a la conexión”, y por lo tanto no proporciona ningún tipo de control
de errores ni de flujo, aunque si que utiliza mecanismos de detección de errores. Cuando se detecta un
error en un datagrama en lugar de entregarlo a la aplicación se descarta.
Este protocolo se ha definido teniendo en cuenta que el protocolo del nivel inferior (el protocolo IP)
también es no orientado a la conexión y puede ser interesante tener un protocolo de transporte que explote
estas caracterı́sticas. Cada datagrama UDP existe independientemente del resto de datagramas UDP.
El protocolo UDP es muy sencillo y tiene utilidad para las aplicaciones que requieren pocos retardos o
para ser utilizado en sistemas sencillos que no pueden implementar el protocolo TCP. Las caracterı́sticas
del protocolo UDP son:
No garantiza la fiabilidad. No se puede asegurar que un datagrama UDP llegará al destino.
No preserva la secuencia de la información que proporciona la aplicación. La información se puede
recibir desordenada (como ocurre en IP) y la aplicación debe estar preparada por si se pierden
datagramas, llegan con retardo o llegan desordenados.
Un datagrama consta de una cabecera y de un cuerpo en el que se encapsulan los datos. La cabecera
consta de los siguientes campos:
Los campos puerto origen y puerto destino son de 16 bits e identifican las aplicaciones en la máquina
origen y en la máquina destino.
El campo longitud es de 16 bits e indica en bytes la longitud del datagrama UDP incluyendo la
cabecera UDP. En realidad es la longitud del datagrama IP menos el tamaño de la cabecera IP.
Como la longitud máxima del datagrama IP es de 65.535 bytes y la cabecera estándar de IP es de
20 bytes, la longitud máxima de un datagrama UDP es de 65.515 bytes.
El campo suma de comprobación (checksum) es un campo opcional de 16 bits que, a diferencia del
campo equivalente de la cabecera IP que solo protegı́a la cabecera, protege tanto la cabecera como
los datos.

Figura 7.4: Cabecera del datagrama UDP
Como el protocolo UDP no está orientado a la conexión y no envı́a ningún mensaje para confirmar
que se han recibido los datagramas, su utilización es adecuada cuando queremos transmitir información
en modo multicast (a muchos destinos) o en modo broadcast (a todos los destinos) pues no tiene sentido
esperar la confirmación de todos los destinos para continuar con la transmisión. También es importante
tener en cuenta que si en una transmisión de este tipo los destinos enviarán confirmación, fácilmente el
emisor se verı́a colapsado, pues por cada paquete que envı́a recibirı́a tantas confirmaciones como destinos
hayan recibido el paquete.
Lo que realmente proporciona UDP respecto a IP es la posibilidad de multiplexación de aplicaciones.
La dirección del puerto permite identificar aplicaciones gracias a la dirección del puerto.
7.5.2. TCP
La unidad de datos de este protocolo recibe el nombre de segmento TCP. Como la cabecera debe
implementar todos los mecanismos del protocolo su tamaño es bastante grande, como mı́nimo 20 bytes.
Figura 7.5: Cabecera del datagrama TCP
A continuación muestro una descripción de cada uno de los campos que forman la cabecera:
Puerto origen (16 bits): Es el punto de acceso de la aplicación en el origen.
Puerto destino (16 bits): Es el punto de acceso de la aplicación en el destino.
Número de secuencia (32 bits): Identifica el primer byte del campo de datos. En este protocolo no
se enumeran segmentos sino bytes, por lo que este número indica el primer byte de datos que hay
en el segmento. Al principio de la conexión se asigna un número de secuencia inicial (ISN, Initial
Sequence Number) y a continuación los bytes son numerados consecutivamente.

Número de confirmación (ACK) (32 bits): El protocolo TCP utiliza la técnica de piggybacking 1 para
reconocer los datos. Cuando el bit ACK está activo, este campo contiene el número de secuencia del
primer byte que espera recibir. Es decir, el número ACK=1 indica el último bit reconocido.
Longitud de la cabecera (4 bits): Indica el número de palabras de 32 bits que hay en la cabecera. De
esta manera el TCP puede saber donde se acaba la cabecera y por lo tanto donde empieza los datos.
Normalmente el tamaño de la cabecera es de 20 bytes por lo que en este campo se almacenará el
número 5. Si el TCP utiliza todos los campos de opciones la cabecera puede tener una longitud
máxima de 60 bytes almacenándose en este campo el valor 15.
Reservado (6 bits): Se ha reservado para su uso futuro y se inicializa con ceros.
Indicadores o campo de control (6 bits): Cada uno de los bits recibe el nombre de indicador y cuando
está a 1 indica una función especı́fica del protocolo.
• URG: Hay datos urgentes y en el campo “puntero urgente” se indica el número de datos urgentes
que hay en el segmento.
• ACK: Indica que tiene significado el número que hay almacenado en el campo “número de
confirmación”.
• PSH: Sirve para invocar la función de carga (push). Como se ha comentado anteriormente con
esta función se indica al receptor que debe pasar a la aplicación todos los datos que tenga
en la memoria intermedia sin esperar a que sean completados. De esta manera se consigue
que los datos no esperen en la memoria receptora hasta completar un segmento de dimensión
máxima. No se debe confundir con el indicador URG que sirve para señalar que la aplicación
ha determinado una parte del segmento como urgente.
• RST: Sirve para hacer un reset de la conexión.
• SYN: Sirve para sincronizar los números de secuencia.
• FIN: Sirve para indicar que el emisor no tiene más datos para enviar.
Ventana (16 bits): Indica cuantos bytes tiene la ventana de transmisión del protocolo de control de
flujo utilizando el mecanismo de ventanas deslizantes. A diferencia de lo que ocurre en los protocolos
del nivel de enlace, en los que la ventana es constante y se cuentan las tramas, en el TCP la ventana
es variable y cuenta bytes. Contiene el número de bytes de datos comenzando con el que se indica
en el campo de confirmación y que el que envı́a está dispuesto a aceptar.
Suma de comprobación (16 bits): Este campo se utiliza para detectar errores mediante el comple-
mento a uno de la suma en módulo 216-1 de todas las palabras de 16 bits que hay en el segmento más
una pseudo-cabecera. La pseudo-cabecera incluye los siguientes campos de la cabecera IP: dirección
internet origen, dirección internet destino, el protocolo y un campo longitud del segmento. Con la
inclusión de esta pseudo-cabecera, TCP se protege a sı́ mismo de una transmisión errónea de IP.
Puntero urgente (16 bits): Cuando el indicador URG está activo, este campo indica cual es el último
byte de datos que es urgente. De esta manera el receptor puede saber cuantos datos urgentes llegan.
Este campo es utilizado por algunas aplicaciones como telnet, rlogin y ftp.
Opciones (variable): Si está presente permite añadir una única opción de entre las siguientes:
• Tiemstamp: para marcar en que momento se transmitió el segmento y de esta manera monito-
rizar los retardos que experimentan los segmentos desde el origen hasta el destino.
• Aumentar el tamaño de la ventana.
• Indicar el tamaño máximo del segmento que el origen puede enviar.
1 Un paquete puede llevar dentro no sólo los datos que van en dirección A-B, sino también un ACK (acuse de recibo) de
otros datos que llegaron anteriormente en dirección B-A. Ası́ se reduce el número total de paquetes requeridos, porque de
otra manera el ACK tendrı́a que ocupar un paquete completo. Es una técnica de optimización que se usa cuando hay tráfico
de datos en ambos sentidos.

Como TCP ha sido diseñado para trabajar con IP, algunos parámetros de usuario se pasan a
través de TCP a IP para su inclusión en la cabecera IP. Por ejemplo: prioridad (campo de 3
bits), retardo-normal / retardo-bajo, rendimiento-normal / rendimiento-alto, seguridad-normal /
seguridad-alta y protección (campo de 11 bits).
7.6. Protocolos de aplicación

Los protocolos de aplicación se pueden dividir en dos grupos según su protocolo de transporte:
UDP : NFS, SNMP, DNS
TCP : SMTP, TELNET, FTP, HTTP
7.6.1. NFS (Network File System)

Utiliza el protocolo UDP y está basado en el RPC (Remote Procedure Call de SUN). El núcleo del
sistema operativo de la máquina cliente es modificado con un nuevo tipo de sistema de fichero NFS, de
manera que cuando un programa intenta abrir, cerrar, leer o escribir en un fichero remoto, el código NFS
es llamado en lugar del código “normal” para acceder a los manejadores de los discos fı́sicos. El código del
sistema de ficheros NFS usa el protocolo RPC de SUN para comunicar con el código servidor NFS que se
ejecuta en la máquina remota, leyendo o escribiendo bloques de ficheros en él.
7.6.2. SNMP (Simple network management protocol)

Es un protocolo cliente/servidor que normalmente es usado para configurar y monitorizar remotamente
los equipos de la red Internet. Este protocolo se basa en el protocolo UDP. En terminologı́a SNMP es
descrito como un protocolo manager/agent.
7.6.3. DNS (Domain Name Server)

El servicio de nombres de dominio (DNS) se utiliza para relacionar los nombres de dominio de los
nodos con sus direcciones IP. Tal como hemos comentado al explicar el protocolo IP, la asignación de
direcciones sigue una estructura jerárquica. Para hacer más sencillo el acceso a los sistemas, cada host
puede tener asignados uno o varios nombres de dominio DNS, que son identificadores descriptivos que
permiten hacer referencia al equipo y equivalen a su dirección IP. Los nombres DNS también se asignan de
forma jerárquica, añadiendo a la derecha del nombre del host una serie de identificadores que corresponden
con la organización o empresa a la que pertenece el sistema.
Cuando en un comando entramos un nombre de máquina, el sistema siempre convierte ese nombre en
una dirección IP antes de establecer la conexión. Desde la máquina que necesita saber la dirección IP,
se envı́a un paquete UDP a un servidor DNS, que busca el nombre y devuelve la dirección IP. Con la
dirección IP, el programa establece una conexión TCP con el destino, o le envia paquetes UDP.
7.6.4. SMTP (Simple Mail Transfer Protocol)

Este es el protocolo dedicado a la transmisión de mensajes electrónicos sobre una conexión TCP.
El protocolo especifica el formato de los mensajes definiendo la estructura de la información sobre el
remitente, el destinatario, datos adicionales y naturalmente el cuerpo de los mensajes. Este protocolo no
especifica como los mensajes deben ser editados. Es necesario tener un editor local o un aplicación nativa
de correo electrónico. Una vez el mensaje es creado, el SMTP lo acepta y usa el protocolo TCP para
enviarlo a un módulo SMTP de otra máquina. El TCP es el encargado de intercomunicar módulos SMTP
de las máquina implicadas.

7.6.5. TELNET (Remote login)

Este protocolo permite a los usuarios conectarse a ordenadores remotos y utilizarlos desde el sistema
local, mediante la emulación de terminal sobre una conexión TCP. Interconecta el cliente local de una
máquina con el servidor con el que se comunica. Los caracteres que se teclean en un cliente local son
enviados por la red y procesados en el ordenador remoto, utilizando la información que ese ordenador
contiene. El resultado de su ejecución se muestra en la pantalla del ordenador local. Este protocolo fue
uno de los primeros que se definió y ha sido diseñado para trabajar con terminales de modo texto. Se
implementa en dos módulos. El módulo cliente relaciona el módulo de entrada y salida del terminal para
que pueda comunicarse con el terminal local. Convierte las caracterı́sticas de los terminales reales con los
standards de las redes y viceversa. El módulo servidor interactúa con una aplicación, de manera que los
terminales remotos sean vistos por la aplicación como terminal local.
7.6.6. FTP (File Transfer Protocol)

Permite la transferencia de ficheros de texto o binarios desde un ordenador a otro sobre una conexión
TCP. FTP implementa un sistema estricto de restricciones basadas en propiedades y permisos sobre los
ficheros. Hay un control de acceso de los usuarios, y cuando un usuario quiere realizar la transferencia
de un fichero, el FTP establece una conexión TCP para el intercambio de mensajes de control. De esta
manera se puede enviar el nombre de usuario, el password, los nombre de los ficheros y las acciones que
se quieren realizar. Una vez se ha aceptado la transferencia del fichero, una segunda conexión TCP se
establece, del servidor al cliente, para la transferencia de datos. El fichero se transfiere sobre la conexión
de datos, sin la utilización de ninguna cabecera o información de control en la capa de aplicación. Cuando
se completa la transferencia, la conexión de control es usada para transmitir la señalización de que la
transferencia se ha completado y para aceptar nuevos comandos de transferencia.
7.6.7. HTTP (Hyper Text Transport Protocol)

Este es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los
clientesWeb y los servidores HTTP. Este protocolo fue propuesto atendiendo a las necesidades de un
sistema global de distribución de información multimedia como el World Wide Web. Se utiliza para
transferir páginas de hipertexto. Está soportado sobre los servicios de conexión TCP/IP. Un proceso
servidor espera las solicitudes de conexión de los clientes Web, y una vez se establece la conexión, el
protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de
errores.
7.7. Protocolo TCP/IP

En su época, el protocolo de red TCP/IP era un protocolo oculto utilizado principalmente por ins-
tituciones gubernamentales y educativas. De hecho, lo inventó la agencia de investigación militar de los
Estados Unidos (DARPA) para proporcionar un sistema de redes sin interrupciones. Su objetivo era crear
una red que pudiera soportar múltiples fallos de enlace, en el caso de que se produjese alguna catástrofe,
como una guerra nuclear. Las comunicaciones de datos tradicionales siempre se habı́an basado en una sola
conexión directa y si dicha conexión se degradaba o se saboteaba, la comunicación cesaba. TCP/IP ofrecı́a
una forma de empaquetar los datos y dejar que “encontraran” su propio camino por la red. Ası́ se creó la
primera red tolerante al fallo.
Sin embargo, la mayorı́a de las empresas seguı́an utilizando los protocolos de red proporcionados por
los fabricantes de su hardware. Las LAN IBM utilizaban normalmente NetBIOS o SNA; las LAN Novell
utilizaban un protocolo denominado IPX/SPX y las LAN Windows utilizaban otro estándar denominado
NetBEUI, derivado del NetBIOS de IBM. Aunque TCP/IP se convirtió en algo común a lo largo de 1980,
no fue hasta el surgimiento de Internet, a primeros de 1990, cuando empezó a convertirse en el estándar
para la comunicación de datos. Por todo lo anteriormente expuesto hizo que cayeran los precios del hard-
ware en sistema de red IP, hecho que facilitó la interconexión entre redes.

Una red TCP/IP permite que los nodos de comunicación establezcan una conexión y después verifiquen
cuándo se inician y se detienen las comunicaciones de datos. Los datos a transmitir se cortan en secciones,
denominadas paquetes y se encapsulan en una serie de “envolturas”, conteniendo cada una información
especı́fica para la siguiente capa de red. Cada paquete se graba con un número de secuencia de 32 bits
para que, aunque lleguen en el orden erróneo, la transmisión se pueda volver a montar. A medida que el
paquete cruza diferentes partes de la red, se abre y se interpreta cada capa y los datos restantes se pasan
según dichas instrucciones. Cuando el paquete de datos llega a su destino, se entregan a la aplicación los
datos reales, o carga útil.
Parece algo confuso, pero mostrando la siguiente analogı́a se entenderá mejor. Piensa en una carta
dentro de un sobre que se envı́a a una empresa de mensajerı́a para su distribución. La empresa de men-
sajerı́a utiliza su propio sobre para enrutar el paquete al edificio correcto. Cuando se reciba el paquete en
este edificio, se abrirá y se tirará el sobre exterior. Esta carta puede estar destinada a otro buzón de correo
interno, por lo que pueden colocarla en un sobre de correo ı́nter-oficinas y enviarla al sitio apropiado. Por
último, la carta llega al receptor, que quita todos los envoltorios y utiliza los datos que están dentro. La
tabla 7.4 resume cómo encapsulan datos algunos protocolos de red.
Cuadro 7.4: Paquete de datos TCP/IP de ejemplo
Protocolo Contenido Capa OSI

Ethernet Dirección MAC Enlace de datos
IP Dirección IP Red
TCP Encabezado TCP Transporte
HTTP Encabezado HTTP Aplicación
Datos de aplicación Página Web Aplicación
Como se puede comprobar, el exterior de nuestro “sobre” de datos tiene la dirección Ethernet, que
identifica el paquete en la red Ethernet. Dentro de esta capa se encuentra la información de la red,
denominada dirección IP, y dentro se encuentra la capa de transporte, que establece una conexión y la
cierra. A continuación está la capa de aplicación, que es un encabezado HTTP, que indica al explorador
Web cómo debe formatear una página. Por último, entra la carga de datos real del paquete (el contenido
de una página Web). Todo esto ilustra la naturaleza de múltiples capas de las comunicaciones de red.
Existen varias fases durante una comunicación entre dos nodos de red que utilizan TCP/IP. Suponiendo
que estamos utilizando direcciones IP y nombres que no son del anfitrión, lo primero que sucede es que
la máquina genera una solicitud de Protocolo de resolución de direcciones (ARP, Address Resolution
Protocol) para buscar la dirección Ethernet correspondiente a la dirección IP con la que está intentando
comunicarse. Ahora que puede comunicarse con la máquina utilizando IP, existe una comunicación de tres
vı́as entre las máquinas que utilizan el protocolo TCP para establecer una sesión.
Una máquina que desea enviar datos a otra máquina envı́a un paquete SYN para sincronizar, o iniciar,
la transmisión. El paquete SYN está básicamente diciendo “¿Está preparada para el envı́o de datos?”.
La otra máquina, envı́a un SYN/ACK, que significa “De acuerdo, he recibido el paquete SYN y estoy
preparada”. Por último, la máquina emisora envı́a un paquete ACK de respuesta diciendo, “Bien, inicio el
envı́o de datos”. Esta comunicación se denomina Acuerdo de conexión TCP de tres vı́as. Si una de las tres
partes no se produce, la conexión no tiene lugar. Mientras la máquina está enviando sus datos, etiqueta
los paquetes de datos con un número de secuencia y reconoce cualquier número de secuencia anterior
utilizado por el anfitrión en el otro punto. Cuando se han enviado todos los datos, una parte envı́a un
paquete FIN a la otra parte del enlace. Ésta responde con un FIN/ACK para cerrar esa sesión TCP/IP.

Cuadro 7.5: Esquema de transmisión TCP/IP
1 SYN: Inicio la conexión (1.a máquina)

2 SYN/ACK: De acuerdo, listo para recibir (2.a máquina)
3 ACK: Transmito (1.a máquina)
4 Transmision: Comunicación entre las dos máquinas
5 FIN: Finalizo conexión (1.a máquina)
6 FIN/ACK: Conexión finalizada (2.a máquina)
Debido a la forma en que TCP/IP controla la iniciación y finalización de una sesión, las comunica-
ciones TCP/IP se dice que tienen un estado. Esto significa que podemos saber qué parte del diálogo se
está produciendo sólo con mirar a los paquetes, algo muy importante para los cortafuegos porque la forma
más común de bloquear el tráfico saliente con un cortafuegos es no admitir los paquetes SYN del exterior
en máquinas internas de la red. Ası́, las máquinas internas pueden comunicarse fuera de la red e iniciar
conexiones con el exterior pero las máquinas externas no pueden iniciar nunca la conexión.
En Linux el cortafuegos IPTables integrado en el núcleo, esta disponible en las versiones de kernel 2.4x
o superior. Funciona mediante la interacción directa con el núcleo del sistema y nos sirve para hacer el
filtrado de paquetes TCP/IP.
Generalmente los cortafuegos tienen dos o más interfaces (tarjetas de red). Una interfaz se conecta
normalmente a la LAN interna; esta interfaz se denomina interfaz de confianza o privada. La otra interfaz
es para la parte pública (WAN) de nuestro cortafuegos. En las redes más pequeñas, la interfaz WAN se
conecta a Internet. También puede existir una tercera interfaz denominada DMZ (Desmilitarized Zone),
que normalmente es para los servidores que necesitan exponerse más a Internet de forma que los usuarios
externos pueden conectarse a ellos, disponen de una IP pública. Todos los paquetes que intentan pasar a
través de la máquina, pasan a través de una serie de filtros. Si coinciden con el filtro, se lleva a cabo alguna
acción. Ésta puede ser evitar su paso, pasarlo o enmascararlo con una dirección IP privada interna. La
mejor práctica para la configuración del cortafuegos es denegarlo todo siempre y permitir, a continuación,
el tráfico que necesitamos de una forma selectiva.
Los cortafuegos pueden filtrar paquetes en distintos niveles. Pueden mirar una dirección IP y bloquear
el tráfico proveniente de determinadas direcciones o redes IP, comprobar el encabezado TCP y determinar
su estado y, en niveles superiores, pueden mirar a la aplicación o al número de puerto TCP/UDP. Se
pueden configurar para evitar categorı́as completas de tráfico, como ICMP. Los paquetes externos de tipo
ICMP, como los ping, normalmente se rechazan en los cortafuegos porque dichos paquetes se utilizan a
menudo en el descubrimiento de redes y denegación de servicio (DoS). No existe ninguna razón para que
alguien externo a nuestra empresa pruebe nuestra red con un ping. Si no lo rechazamos expresamente, el
cortafuegos va a permitir las réplicas de eco (respuestas de ping).

Capı́tulo 8
Configuración de dispositivos de red
En Debian el archivo de configuración de los dispositivos de red es:

/etc/network/interfaces
En su interior encontraremos el modo de funcionamiento de todos los dispositivos de red del sistema.
En este capı́tulo trataremos su configuración mediante una serie de herramientas.
8.1. Etherconf: Configurador gráfico de red
Es el configurador gráfico para redes de Debian y se instala con el siguiente comando:

#apt-get install etherconf
Para configurar las tarjetas de red automáticamente hay que ejecutar el comando:
#dpkg-reconfigure etherconf, . . . que arrancará debconf.
Y nos realizará unas preguntas, para configurar nuestro sistema.
8.2. Ifconfig: Configurador de red
El programa ifconfig es responsable de configurar las tarjetas de interfaz de red (NIC, Network Interface
Card). Todas estas operaciones se realizan a través de la lı́nea de comandos, ya que no tiene interfaz gráfica.
Existen varias herramientas que se han escrito para cubrir la falta de interfaz gráfica o de menús del
comando ifconfig. Muchas de ellas vienen en las distribuciones de Linux, en Debian la interfaz que podemos
utilizar es etherconf.
El formato del comando ifconfig es el siguiente:

#ifconfig dispositivo direccion opciones
Donde dispositivo es el nombre del dispositivo ethernet (por ejemplo, eth0), dirección es la dirección
IP que se desea aplicar al dispositivo y opciones es una de las siguientes:
up Activa el dispositivo. Esta opción es implı́cita
down Desactiva el dispositivo
arp Activa este dispositivo para responder peticiones, por defecto
-arp Desactiva este dispositivo para responder a peticiones arp
mtu valor Configura la unidad de transmisión máxima (MTU) del dispositivo a valor.
Bajo ethernet, el valor por defecto es 1500
netmask dirección Configura la máscara de red de esta interfaz a dirección. Si no se propor-
ciona un valor, ifconfig calcula la máscara basada en la clase de la dirección
IP. Una dirección de clase A tiene una máscara 255.0.0.0, una de clase B
255.255.0.0 y la clase C 255.255.255.0
broadcast dirección Configura la dirección de broadcast de la interfaz de dirección. Si no se
proporciona un valor, ifconfig calcula la dirección de broadcasta basada
en la clase de la dirección IP de manera parecida a la máscara de red
pointtopoint dirección Configura la conexión punto a punto (PPP) donde la dirección remota es
dirección
Un ejemplo de uso simple podrı́a ser el siguiente: #ifconfig eth0 192.168.0.3, . . . Donde el dispo-
sitivo eth0 quedará configurado con la dirección IP 192.168.0.3. Como es una dirección de clase C, la
máscara será 255.255.255.0 y el broadcast será 192.168.0.255, asignándolos ifconfig por defecto.
Si la dirección IP que configuramos es una dirección de clase A o B dividida en subredes, necesitaremos

determinar explı́citamente las direcciones de broadcast y de máscara en la lı́nea de comandos:
#ifconfig dispositivo ip netmask num_mascara broadcast num_broadcast
Se pueden listar todos los dispositivos activos ejecutando: #ifconfig.

Con la opción -a: #ifconfig -a, . . . se mostrarán todos los dispositivos, estén activos o no.
En tiempo de ejecución, con el comando ifconfig podemos habilitar y deshabilitar los dispositos de red:
#ifconfig dispositivo up, . . . para activar el dispositivo
#ifconfig dispositivo down, . . . para desactivar el dispositivo
Para visualizar los dispositivos del sistema basta con ejecutar:

#ifconfig
Si estamos en un cliente habrá que especificar toda la ruta:
$/sbin/ifconfig
A continuación podemos observar la salida del servidor que se utiliza en el proyecto:

$/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:C0:9F:6E:1D:E0
inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2506 errors:0 dropped:0 overruns:0 frame:0
TX packets:5953 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2280653 (2.1 MiB) TX bytes:707464 (690.8 KiB)
Interrupt:6
eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00

RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:10
lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX bytes:29170217 (27.8 MiB) TX bytes:29170217 (27.8 MiB)

Capı́tulo 8. Configuración de dispositivos de red 81
Se puede observar que dispone de dos tarjetas de red, en este caso eth0 es una tarjeta de red LAN y
eth1 una tarjeta de red wifi, en estos momentos deshabilitada. Ası́ mismo, también podemos observar el
dispositivo lo, de loopback.
8.3. Route: Tablas de redireccionamiento

Si la máquina se conecta a una red con varias subredes, necesitamos un enrutador. Este aparato, que
se sitúa entre redes, redirige paquetes a su destino real (normalmente, muchas máquinas no conocen el
camino correcto al destino, sólo conocen el propio destino).
En el caso donde una máquina ni siquiera tiene una pista sobre dónde enviar el paquete, se usa una
ruta por defecto. Este camino apunta a un enrutador, que idealmente sabe a dónde deberı́a ir el paquete
o, al menos, sabe otra ruta que puede tomar.
Una máquina tı́pica Linux conoce al menos tres rutas:
La primera es la ruta de bucle local que simplemente apunta a su dispositivo de loopback.
La segunda es la ruta a la LAN, de forma que los paquetes destinados a las máquinas de esa misma
red se envı́an directamente a ellas.
La tercera es la ruta por defecto. Esta ruta se usa para paquetes que necesitan abandonar la LAN
para comunicarse con otras redes.
Si configuramos la red en tiempo de instalación, este valor lo configurará el instalador. Ası́ que no suele
ser necesario cambiarlo, lo cual no quiere decir que no se pueda. Suele ser necesario cuando tenemos varias
tarjetas instaladas en un mismo equipo, como a menudo pasa en los servidores, enrutadores o cortafuegos.
El comando route tı́pico se estructura de la siguiente forma:

#route cmd tipo direccion netmask masc gw gatw dev destino
Los parametros significan lo siguiente:
Parámetro Descripción
cmd Valor add o del dependiendo de si añadimos o borramos una ruta. Si eliminamos
una ruta, sólo necesitamos otro parámetro, dirección
tipo Valor -net o -host dependiendo si dirección representa una dirección de red o una
dirección de un enrutador
dirección La red destino que quiere ofrecer para enrutar
netmask masc Configura la máscara de red de la dirección dirección a masc
gw gatw Configura la la dirección de enrutador para direccion a gatew. Normalmente se usa
como ruta por defecto
dev destino Envı́a todos los paquetes destinados a dirección a través de la red del dispositivo
destino según se configura con ifconfig
Podemos ver el uso del comando con los siguientes ejemplos:
1. Configurar una ruta por defecto en mi máquina, la cual tiene un dispositivo Ethernet y un enrutador
en 192.168.0.1:
#route add -net default gw 192.168.0.1 dev eth0
2. Configurar un sistema para que todos los paquetes destinados a 192.168.0.3 se envı́en a través del
primer dispositivo PPP:
#route add -host 192.168.0.3 netmask 255.255.255.0 dev ppp0

3. Ası́ se borra una ruta destino a 192.168.0.3:

#route del 192.168.0.3
Hay otra cosa a tener en cuenta, si usamos una pasarela (gateway), necesitamos asegurarnos de que
existe una ruta a la pasarela antes de referenciarla como otra ruta. Por ejemplo, si la ruta por defecto usa
la pasarela de 192.168.1.1, necesitamos asegurarnos primero de que tenemos una ruta a la red 192.168.1.0
Para visualizar la tabla de enrutamiento utilizaremos:

#route
Route visualiza los nombres de máquinas a cualquier dirección IP que podrı́a buscar y resolver. Aunque
es bueno leerlo, presenta un problema cuando hay dificultades de red y no se consigue llegar a los servidores
DNS o NIS. El comando route esperará, tratando de resolver los nombres de máquinas y esperando para
ver si los servidores devuelven y los resuelven. Esta espera será de varios minutos hasta que la petición
devuelva un timeout.
Para evitar que route realice resolución de nombres ejecutaremos: #route -n
Este serı́a un ejemplo de la salida de una máquina con acceso a la LAN y a internet por una pasarela:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
default . 0.0.0.0 UG 0 0 0 eth0
Podemos observar varias columnas como destino, pasarela, máscara (referido como genmask) e iface
(interfaz, configurada por la opción dev de route). Las otras entradas de la tabla tienen el significado
siguiente:
Entrada Descripción
Flags Un sumario de estado de conexión, donde cada letra tiene un significado:
U: la conexión está arriba
H: el destino es una máquina
G: el destino es la pasarela
Metric El “coste” es una ruta, normalmente medida en saltos (hops). Esto es significativo para
los sistemas que tienen varias rutas para llegar al destino, pero se prefiere una ruta
sobre el resto. Un camino con métrica baja es el preferido. El kernel de Linux no usa
esta información, pero sı́ lo hacen algunos protocolos de enrutamiento avanzados.
Ref El número de referencias de la ruta. Esto no se usa en el kernel de Linux. Está aquı́ debido
a que la propia herramienta route es de plataformas cruzadas. Ası́ se imprime este valor,
pues otros sistemas operativos lo usan
Use El número de bucles de cache de rutas utilizados con éxito. Para ver este valor, hay que
usar la opción -F cuando invoquemos route

8.4. Netstat: Estado de las conexiones

El programa netstat se utiliza para mostrar el estado de todas las conexiones de red de una máquina.
La opciones de netstat son combinables, en la siguiente tabla se muestran las más comunes:
Cuadro 8.1: Opciones de Netstat
-a Visualiza la información de todas las conexiones activas
-i Visualiza las estadı́sticas de todos los dispositivos de red configurados
-c Actualiza la información visualizada cada segundo
-r Muestra la tabla de enrutado
-n Visualiza las direcciones locales y remotas en formato numérico
-t Muestra tan sólo la información de TCP
-u Muestra tan sólo la información de UDP
-v Visualiza la versión de netstat
8.5. Configuración de interfaces usando DHCP

DHCP (Dynamic Host Configuration Protocol), es un protocolo de red empleado para asignar de forma
automática una dirección IP a los hosts que se conectan a ella.
En redes pequeñas las direcciones IP pueden asignarse de forma manual, equipo por equipo, pero en
redes de un cierto tamaño esta tarea puede convertirse en agotadora, no sólo por tener que editar cada
uno de los hosts, sino por la dificultad de mantener un registro con las IPs asignadas para evitar duplicados.
Para que esto funcione debemos instalar uno de los siguientes paquetes:
dhcp3-client (versión 3, Internet Software Consortium)

dhcpcd (Yoichi Hariguchi y Sergei Viznyuk)
pump (Red Hat)

Pump es sencillo y ampliamente utilizado. Para instalarlo:
#apt-get install pump
Y para utilizarlo, simplemente:
#pump -i dispositivo, . . . como por ejemplo: #pump -i eth0
Dhcp3-client es complejo pero más configurable. Para instalarlo:

#apt-get install dhcp3-client
Y para utilizarlo ejecutamos:
#dhclient3 dispositivo, . . . como por ejempo: #dhclient3 eth0
Este comando tiene otras opciones que pueden ser consultadas con el manual del sistema: $man dhclient

8.6. Archivo /etc/network/interfaces

El archivo especifica la configuración de nuestros dispositivos de red y puede ser configurado a mano.
Los comandos: #ifdown dispositivo y #ifup dispositivo, utilizan el archivo para habilidar y des-
habilitar los dispositivos de red.
En las siguientes secciones se especifica la forma de configurar el archivo /etc/network/interfaces.
Esta sección esta basada en la configuración de la red de la guı́a de referencia Debian, para más
información consúltela.
8.6.1. Direcciónes IP estáticas

Supongamos que se desea configurar una interfaz ethernet que tiene una dirección IP fija 192.168.0.123.
Esta dirección comienza con 192.168.0 por lo tanto debe estar en una LAN. Supongamos además que
192.168.0.1 es la dirección de la puerta de enlace de la LAN Internet. Editamos /etc/network/interfaces
de modo que incluya un fragmento como el siguiente:
iface eth0 inet static
address 192.168.0.123
netmask 255.255.255.0
gateway 192.168.0.1
Si tenemos instalado el paquete resolvconf podemos añadir las siguientes lı́neas para especificar la
información relativa al DNS:
address 192.168.0.123
netmask 255.255.255.0
gateway 192.168.0.1
dns-search nicedomain.org
dns-nameservers 195.238.2.21 195.238.2.22
Después de que se activa la interfaz, los argumentos de las opciones dns-search y dns-nameservers
quedan disponibles para resolvconf para su inclusión en resolv.conf.
El argumento nicedomain.org de la opción dns-search corresponde al argumento de la opcin search en
resolv.conf.
Los argumentos 195.238.2.21 y 195.238.2.22 de la opción dns-nameservers corresponde a los argu-
mentos de las opciones nameserver en resolv.conf.
Otras opciones reconocidas en el archivo son dns-domain y dns-sortlist.
8.6.2. Direcciones IP dinámicas

Para configurar una interfaz usando DHCP editamos el /etc/network/interfaces de manera que incluya
un fragmento como el siguiente:
iface eth0 inet dhcp
Para que esto funcione debemos tener instalado un cliente DHCP (Véase sección 8.5).

8.6.3. Interfaz Wifi

El paquete wireless-tools incluye el script /etc/network/if-pre-up.d/wireless-tools que permite confi-
gurar hardware Wifi (802.11a/b/g) antes que se active la interfaz. La configuración se realiza usando el
programa iwconfig (véase sección 8.10).
Para cada parámetro del comando iwconfig podemos incluir una opción en /etc/network/interfaces
con un nombre como el del parámetro con el prefijo “wireless-”. Por ejemplo, para fijar el ESSID de eth1
a miessid y la clave de cifrado en 123456789e antes de activar eth1 y usando DHCP, editamos el archivo
/etc/network/interfaces de modo que incluya un fragmento como el siguiente :

wireless-essid miessid
wireless-key 123456789e
8.6.4. Interfaz PPPoE

Muchos Proveedores de Servicios de Internet (ISPs) de banda ancha utilizan PPP para negociar las
conexiones incluso cuando las máquinas de los clientes están conectadas mediante ethernet y/o redes ATM.
Esto se logra mediante PPP sobre ethernet (PPPoE) que es una técnica para el encapsulamiento del flujo
PPP dentro de las tramas ethernet.
Supongamos que el ISP se llama mi isp. Primero configuramos PPP y PPPoE para mi isp. La manera
más fácil de hacerlo consiste en instalar el paquete pppoeconf y ejecutar pppoeconf desde la consola. A
continuación, editamos /etc/network/interfaces de modo que incluya un fragmento como el siguiente:
iface eth0 inet ppp

provider mi_isp
A veces surgen problemas con PPPoE relativos a la Unidad de Transmisin Mxima (Maximum Transmit
Unit o MTU) en lı́neas DSL (Digital Subscriber Line). Hay que acudir al manual en estos casos.
Debemos observar que si el módem posee un router, si esto es ası́ el módem/router maneja por sı́ mismo
la conexin PPPoE y aparece del lado de la LAN como una simple puerta de enlace Ethernet a Internet.
Ası́ no hay que realizar la configuración. En mi caso, mi proveedor de servicios me ha instalado un
módem/router de este estilo y no me es necesario. Me han facilitado un usuario y contraseña que utilizo
para validarme en su servidor y recibir el servicio.
8.6.5. Puertas de enlace

Supongamos que eth0 está conectada a internet con un dirección IP configurada con DHCP y eth1
está conectada a la LAN con una dirección IP estática 192.168.1.1. Editamos /etc/network/interfaces de
modo que incluya un fragmento similar al siguiente:

address 192.168.1.1
netmask 255.255.255.0
Si activamos NAT en esta máquina, mediante una puerta de enlace, podemos compartir la conexión
de internet con todas las máquinas de la LAN.

8.6.6. Interfaces virtuales

Usando interfaces virtuales se puede configurar una única tarjeta ethernet para que sea la inter-
faz de distintas subredes IP. Por ejemplo, supongamos que la máquina se encuentra en una red LAN
192.168.0.x/24. Y deseamos conectar la máquina a Internet usando una direccin IP pública proporcionada
con DHCP usando su tarjeta ethernet existente. Editamos /etc/network/interfaces de modo que incluya
un fragmento similar al siguiente:
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
iface eth0:0 inet dhcp
La interfaz eth0:0 es una interfaz virtual. Al activarse también lo hará su padre eth0.
8.7. Reconfiguración de la red

Aquı́ es necesario diferenciar entre interfaz fı́sica y interfaz lógica.
Una interfaz fı́sica es lo que hemos estado llamando “interfaz o dispositivo” de red, lo que hemos
designado con eth0, ppp1, etc.
Una interfaz lógica es un conjunto de valores que pueden asignarse a los parámetros variables de una
interfaz fı́sica.
Las definiciones iface en /etc/network/interfaces son, en realidad, definiciones de interfaces lógicas no
de interfaces fı́sicas.
No obstante, supongamos que nuestra máquina es un equipo portátil que transportamos de casa al
trabajo. Cuando conectamos la máquina a una red corporativa o a nuestra LAN hogareña, necesitamos
configurar eth0 adecuadamente. Vamos a definir, en el archivo /etc/network/interfaces dos interfaces
lógicas: hogar y trabajo (en vez de eth0 como hicimos antes) que describen cómo deberı́a configurarse la
interfaz para la red hogareña y la del trabajo respectivamente.
iface hogar inet static
address 192.168.0.123
netmask 255.255.255.0
gateway 192.168.0.1
iface trabajo inet static

address 81.201.3.123
netmask 255.255.0.0
gateway 81.201.1.1
De esta forma, la interfaz fı́sica eth0 se puede activar en la red hogareña con la configuración apropiada,
especificando:
#ifup eth0=hogar
Para reconfigurar eth0 en la red del trabajo, ejecutamos los comandos:

#ifdown eth0
#ifup eth0=trabajo
Observamos que con el archivo interfaces escrito ası́ ya no resultará posible activar eth0 haciendo
solamente ifup eth0. La razón es que ifup utiliza el nombre de la interfaz fı́sica como el nombre de la
interfaz lógica eth0 predeterminada y, en realidad, en nuestro ejemplo no hay una interfaz lógica definida.

Una vez visto como se reconfiguran las interfaces, hay que precisar que la reconfiguración necesita
realizarse en el momento apropiado.
Actualmente existe una tendencia en GNU y Linux al soporte de hardware y entornos que cambian
dinámicamente. El primer soporte se añadió para la inserción en caliente de tarjetas PCMCIA; más
recientemente ha sido incorporado el mecanismo hotplug para que muchos más periféricos se puedan
enchufar y desenchufar mientras la máquina se encuentra funcionando. Esto incluye el hardware de red.
Se puede observar que los servicios que dependen del hardware que se conecta en caliente sólo deben
iniciarse después de que el hardware haya sido insertado y deben detenerse cuando se hayan eliminado.
Esto significa que dichos servicios deben liberarse del control del sistema init System V y ponerlos, en
cambio, bajo el control de ifupdown.
Por ejemplo, supongamos que el servicio ‘loquesea’ controlado por el script de init /etc/init.d/loquesea
depende dinámicamente de la interfaz de red reconfigurada eth0. Deberı́amos actuar siguiendo este esque-
ma:
Primero eliminamos ‘loquesea’ del control del sistema init. Si está ultilizando el sistema init sysv-rc
entonces hacemos lo siguiente:
# rm /etc/rc?.d/S??loquesea
Luego pongamos ‘loquesea’ bajo el control de ifupdown añadiendo las opciones up y down en la
sección eth0 de /etc/network/interfaces que contiene las llamadas al script init loquesea:

up /etc/init.d/loquesea start
down /etc/init.d/loquesea stop
8.7.1. Configuración de red durante el arranque

Al arrancar, el script de init, /etc/rcS.d/S40networking se ejecuta el comando ifup -a. Esto activa
todas las interfaces fı́sicas que aparecen en las secciones auto de /etc/network/interfaces.
Actualmente, a menudo resulta mejor manejar la configuración de la red usando métodos dinámicos.
Una vez configurados los mecanismos para el soporte de hardware que cambia en forma dinámica, resulta
más sencillo tratar el hardware estático como si fuera dinámico. El arranque se puede considerar como un
simple evento hotplug (Véase sección 8.7.2).
No obstante, en casi todos los casos uno desea por lo menos que la interfaz de retorno lo (loopback) se
active en el arranque. Por lo tanto, nos aseguramos de que /etc/network/interfaces incluya las siguientes
lı́neas:
auto lo
iface lo inet loopback
Se puede listar los nombres de interfaces fı́sicas adicionales en las secciones auto si desea que también
se activen durante el arranque. Nunca debemos de incluir las interfaces PCMCIA en las secciones auto.
Para el PCMCIA, cardmgr se inicia durante el arranque después de /etc/rcS.d/S40networking, si descubre
algún dispositivo lo instala.
8.7.2. Hotplug
Para el soporte del arranque en caliente instalamos el paquete hotplug:
#apt-get install hotplug
El hardware de red se puede enchufar en caliente ya sea durante el arranque, tras haber insertado la
tarjeta en la máquina (una tarjeta PCMCIA, por ejemplo), o después de que una utilidad como discover
se haya ejecutado y cargado los módulos necesarios.

Cuando el kernel detecta nuevo hardware inicializa el controlador para el hardware y luego ejecuta
el programa hotplug para configurarlo. Si más tarde se elimina el hardware, ejecuta nuevamente hotplug
con parámetros diferentes. En Debian, cuando se llama a hotplug éste ejecuta los scripts contenidos en
/etc/hotplug/ y /etc/hotplug.d/.
El hardware de red recién conectado es configurado por el /etc/hotplug/net.agent. Supongamos que
la tarjeta de red PCMCIA ha sido conectada lo que implica que la interfaz eth0 esta lista para usar.
/etc/hotplug/net.agent hace lo siguiente: #ifup eth0=hotplug
Para que una interfaz pueda ser configurada por hotplug debemos añadir la referencia a hotplug en en
/etc/network/interfaces. Para que este comando configure eth0, añadimos las siguientes lı́neas:
mapping hotplug
script echo
Si sólo deseamos que eth0 se active en caliente y no otras interfaces, utilizamos grep en vez de echo
como se muestra a continuación:
mapping hotplug
script grep
map eth0
8.7.3. Ifplugd
Ifplugd activa o desactiva una interfaz dependiendo si el hardware subyacente está o no conectado a la
red. El programa puede detectar un cable conectado a una interfaz ethernet o un punto de acceso asociado
a una interfaz wifi. Cuando ifplugd ve que el estado del enlace ha cambiado ejecuta un script que por
defecto ejecuta ifup o ifdown para la interfaz.
ifplugd funciona correctamente en combinación con hotplug. Al insertar una tarjeta, lo que significa que
la interfaz est lista para usar, /etc/hotplug.d/net/ifplugd.hotplug inicia una instancia de ifplugd para dicha
interfaz. Cuando ifplugd detecta que la tarjeta es conectada a una red, ejecuta ifup para esta interfaz.
8.8. Resolvconf: Resolución de nombres

El paquete resolvconf proporciona un marco para la administración dinámica de la información relativa
a los servidores de nombres disponibles. Soluciona el antiguo problema de mantener las listas dinámicas
de los nombres de los servidores para ser usadas por el sistema de resolución y los cachés DNS. Resolvconf
es el intermediario entre los programas que controlan las interfaces de red y suministran información de
los servidores de nombres, y las aplicaciones que necesitan dicha información. Este comando está diseñado
para funcionar sin que sea necesaria ninguna configuración manual.
Para la resolución de nombres se utiliza el archivo de configuración:

/etc/resolv.conf
Si no hemos instalado el paquete resolvconf, podemos editar a mano el fichero /etc/resolv.conf. En él
podemos especificar hasta tres servidores de nombres, siendo los dos últimos utilizados en caso de que no
se encuentre disponible el primero.
La lı́nea domain se emplea para definir el nombre de dominio por defecto que se añadirá a los
nombres de host que no contengan dominio.
La lı́nea search se emplea para especificar que busque un dominio.

Esto podrı́a ser un contenido tı́pico:

#cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

domain example.com
nameserver 192.168.0.1
8.9. Archivos de configuración de Hosts

Existen varios archivos que tienen que ver con los hosts de nuestro sistema:
Un sistema Debian a veces necesita identificarse por su nombre. Para este propósito /etc/hostname
contiene el nombre de la máquina. Este archivo únicamente deberá contener el nombre de la máquina
y no el nombre de dominio completo.
El archivo /etc/hosts contiene un conjunto de nombres de hosts con sus correspondientes direcciones
IP.
En redes pequeñas y sin conexión a Internet este archivo puede utilizarse en lugar de un servidor
DNS. En él especificaremos los nombre de todos los equipos conectados a la red y su correspondientes
direcciones IP. De esta forma podremos hacer referencia a los mismos sin especificar su dirección.
Linux se encargará de buscar esta dirección dentro del archivo /etc/hosts
Puede emplearse para proporcionar un conjunto mı́nimo de nombres de hosts en caso de que el
servidor de DNS se encuentre desactivado o durante el proceso de arranque de Linux.
El archivo /etc/host.conf dice al sistema cómo resolver los nombres de los hosts. Contiene el orden
en el que serán ejecutadas las resoluciones que requiera el host, este archivo normalmente contiene
la siguiente lı́nea:
order hosts,bind,nis
El significado de estos parámetros es que cualquier tipo de resolución de nombres primeramente debe
ser ejecutada en el archivo /etc/hosts, posteriormente se debe consultar a Bind y si aún no se ha
logrado la resolución, intentar con NIS (Network Information Server), si después de consultar este
servicio no es posible la resolución, el Resolver responderá que no fue posible localizar el host.
/etc/hosts.allow, . . . donde se especifican los hosts que tienen acceso al sistema.
/etc/hosts.deny, . . . donde se especifican los hosts a los que se prohı́be el acceso al sistema
8.10. Iwconfig: Configuración wireless

Para poder configura la red inalámbrica necesitamos instalar los siguientes paquetes:
#apt-get install wireless-tools wavemon
El comando iwconfig tiene las mismas funciones que ifconfig, es decir configurar la red, pero en este
caso la red wireless.
Ejecutando el comando: #iwconfig, sin parametros observaremos cuales son las interfaces wireless de
nuestro sistema.

Por ejemplo la salida del servidor es la siguiente:

# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
eth1 unassociated ESSID:off/any

Mode:Managed Channel=0 Access Point: 00:00:00:00:00:00
Bit Rate=0 kb/s Tx-Power=off
RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Las opciones básicas de iwconfig sirven para determinar el nombre del ESSID, y establecer la clave
WEP del sistema, tanto en hexadecimal como en ASCII. Veámoslo con unos ejemplos:
Asignar el nombre de “NodoEjemplo” a nuestra red:
#iwconfig eth1 essid NodoEjemplo
Asignar una clave WEP hexadecimal
#iwconfig eth1 key 1234123412341234abcd
Asignar una clave WEP ASCII, añadiendo al principio “s:”:

#iwconfig eth1 key s:clave-secreta
Este comando tiene multitud de opciones que pueden ser consultadas en el manual del sistema:
$man 8 iwconfig.
Para configuraciones más complejas es mejor que editemos el archivo /etc/network/interfaces como se
describe en la sección 8.6.3. Si utilizamos claves WPA, será necesario instalar un cliente WPA (para esta
configuración dirı́jase a la sección 14.5.5).
Podemos tener un monitor de la conexión wireless con:

$wavemon, . . . monitor del estilo de top para conexiones wireless.
Para más información dirı́jase al capı́tulo Redes inalámbricas (cap. 14).
8.11. Resolución de problemas

Si encontramos problemas en la instalación de red podemos ejecutar los siguientes comandos y consultar
las salidas:
#ifconfig
#cat /proc/pci
#cat /proc/interrupts
#dmesg | more

Parte III
Instalación de Servicios
Capı́tulo 9
Servicios de red
9.1. Servidor DHCP

El Protocolo de configuración dinámica de servidores (DHCP, Dynamic Host Configuration Protocol),
es un protocolo de red en el que un servidor provee los parámetros de configuración a las computadoras
que lo requieran, conectadas a la red (máscara, puerta de enlace y otros) y también incluye un mecanismo
de asignación de direcciones de IP.
Este protocolo apareció como protocolo estándar en octubre de 1993 y existe un proyecto abierto para
desarrollar DHCPv6, en redes IPv6.
La información de esta sección a sido obtenida de la enciclopedia libre: http://es.wikipedia.org
9.1.1. Asignación de direcciones IP

Sin DHCP, cada dirección IP debe configurarse manualmente en cada ordenador y, si el ordenador se
mueve a otro lugar en otra parte de la red, se debe de configurar otra dirección IP diferente. El DHCP
le permite al administrador supervisar y distribuir de forma centralizada las direcciones IP necesarias y,
automáticamente, asignar y enviar una nueva IP si el ordenador es conectado en un lugar diferente de la red.
El protocolo DHCP incluye tres métodos de asignación de direcciones IP:

Asignación manual : Donde la asignación se basa en una tabla con direcciones MAC (pares de
direcciones IP introducidas manualmente por el administrador). Sólo las computadoras con una
dirección MAC que figure en dicha tabla recibirán la IP asignada en dicha tabla.
Asignación automática: Donde una dirección de IP libre obtenida de un rango determinado por el
administrador se le asigna permanentemente a la computadora que la requiere.
Asignación dinámica: El único método que permite la reutilización dinámica de las direcciones IP.
El administrador de la red determina un rango de direcciones IP y cada computadora conectada a
la red está configurada para solicitar su dirección IP al servidor cuando la tarjeta de interfaz de red
se inicializa. El procedimiento usa un concepto muy simple en un intervalo de tiempo controlable.
Esto facilita la instalación de nuevas máquinas clientes, en la red.
El DHCP es una alternativa a otros protocolos de gestión de direcciones IP de red como el BOOTP
(Bootstrap Protocol), respento a este, DHCP es un protocolo más avanzado.
9.1.2. Parámetros configurables

Un servidor DHCP puede proveer de una configuración opcional a la computadora cliente.
La lista de opciones siguientes son configurables mediante DHCP:

Dirección del servidor DNS.
Nombre DNS.
Puerta de enlace de la dirección IP.
Dirección de difusión de red (Broadcast Address).
Máscara de subred.
Tiempo máximo de espera del ARP (Protocolo de Resolución de Direcciones).
MTU (Unidad de Transferencia Máxima) para la interfaz.
Servidores NIS (Servicio de Información de Red).
Dominios NIS.
Servidores NTP (Protocolo de Tiempo de Red).
Servidor SMTP.
Servidor TFTP.
Nombre del servidor WINS.
9.1.3. Implementaciones
Microsoft introdujo DHCP en sus Servidores NT con la versión 3.5 de Windows NT a finales de 1994,
a pesar de que la llamaron una nueva función no fue inventada por ellos.
El Consejo de Software de Internet (ISC: Internet Software Consortium) publicó distribuciones de
DHCP para Unix con la versión 1.0 del ISC DHCP Server el 6 de diciembre de 1997 y una versión (2.0) que
se adaptaba mejor el 22 de junio de 1999. Se puede encontrar el software en: http://www.isc.org/sw/dhcp/.
Otras implementaciones importantes incluyen:

Cisco: añadió un servidor DHCP habilitado en Cisco IOS 12.0 en febrero de 1999.
Sun: añadió el soporte para DHCP, a su sistema operativo Solaris, en julio de 2001.
Actualmente, la mayorı́a de los routers incluyen soporte DHCP.
9.1.4. Anatomı́a del protocolo

DHCP usa los mismos puertos asignados por el IANA (Autoridad de Números Asignados en Internet
según siglas en inglés) en BOOTP:
67/udp: Para las computadoras servidor.
68/udp: Para las computadoras cliente.
A continuación muestro las actuaciones que puede tener el protocolo:
DHCP Discover : La computadora cliente emite peticiones masivamente en la subred local para
encontrar un servidor disponible. El router puede ser configurado para redireccionar los paquetes
DHCP a un servidor DHCP en una subred diferente. La implementación cliente crea un paquete UDP
(Protocolo de Datagramas de Usuario) con destino 255.255.255.255 y requiere también su última
dirección IP conocida, aunque esto no es necesario y puede llegar a ser ignorado por el servidor.

Capı́tulo 9. Servicios de red 95
DHCP Offer : El servidor determina la configuración basándose en la dirección del soporte fı́sico de
la computadora cliente especificada en el registro CHADDR. El servidor especifica la dirección IP
en el registro YIADDR.
DHCP Request: El cliente selecciona la configuración de los paquetes recibidos de DHCP Offer. Una
vez más, el cliente solicita una dirección IP especı́fica que indicó el servidor.
DHCP Acknowledge: El servidor confirma el pedido y lo publica masivamente en la subred. Se espera

que el cliente configure su interface de red con las opciones que se le asignaron.
9.1.5. Configuración de un servidor DHCP

El fichero de configuración de un servidor DHCP es /etc/dhcpd.conf.
El primer paso es comprobar que nuestro kernel esta configurado para que el sistema se pueda utilizar
como servidor DHCP. Para ello ejecutaremos: #ifconfig -a
#ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:C0:9F:6E:1D:E0

inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
RX bytes:1272847 (1.2 MiB) TX bytes:381723 (372.7 KiB)
Interrupt:6
Si no encontramos la opción MULTICAST deberemos reconfigurar el kernel para agregarlo. En la

mayorı́a de sistemas no será necesario, funcionará por defecto.
Para instalar el servicio DHCP realizamos un apt:

#apt-get install dhcp
El primer paso al configurar un servidor DHCP es crear el fichero de configuración que almacena la
información de red de los clientes. Se pueden declarar opciones globales para todos los clientes, o bien
opciones para cada sistema cliente. El fichero de configuración posee dos tipos de información:
Parámetros: Establece cómo se realiza una tarea, si debe llevarse a cabo una tarea o las opciones de
configuración de red que se enviarán al cliente.
Declaraciones: Describen el tipo de red y los clientes, proporcionan direcciones para los clientes o
aplican un grupo de parámetros a un grupo de declaraciones.
Algunos parámetros deben empezar con la palabra clave option. Los parámetros definen valores no
opcionales o que controlan el comportamiento del servidor DHCP.
Si cambiamos el fichero de configuración, para aplicar los cambios, reiniciaremos el demonio DHCP:
# /etc/init.d/dhcp restart
Subredes
Debemos incluir una declaración subnet para cada subred de la red. Si no lo hacemos, el servidor
DHCP no podrá arrancarse. En el ejemplo siguiente, hay opciones globales para cada cliente DHCP de la
subred y un rango de IPs declarado, a los clientes se les asigna una dirección IP dentro de ese rango.
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.254;
option subnet-mask 255.255.255.0;
option domain-name "example.com";

option domain-name-servers 192.168.1.1;
option time-offset -5; # Eastern Standard Time
range 192.168.1.10 192.168.1.100;

}

Redes compartidas
Todas las subredes que comparten la misma red fı́sica deben declararse dentro de una declaración
shared-network. Los parámetros dentro de shared-network, pero fuera de las declaraciones subnet se consi-
deran parámetros globales. El nombre que le asignemos debe ser el tı́tulo descriptivo de la red, como, por
ejemplo, test-lab para describir todas las subredes en un entorno de laboratorio de tests.
shared-network name {
option domain-name "test.redhat.com";
option domain-name-servers ns1.redhat.com, ns2.redhat.com;
more parameters for EXAMPLE shared-network
subnet 192.168.1.0 netmask 255.255.255.0 {
parameters for subnet
range 192.168.1.1 192.168.1.31;
}
subnet 192.168.1.32 netmask 255.255.255.0 {
parameters for subnet
range 192.168.1.33 192.168.1.63;
}
}
Grupos
La declaración group puede utilizarse para aplicar parámetros globales a un grupo de declaraciones.
Podemos agrupar redes compartidas, subredes, hosts u otros grupos.
group {

option time-offset -5; # Eastern Standard Time
host apex {
option host-name "apex.example.com";
hardware ethernet 00:A0:78:8E:9E:AA;
fixed-address 192.168.1.4;
}
host raleigh {
option host-name "raleigh.example.com";
hardware ethernet 00:A1:DD:74:C3:F2;
}
}
Tiempo de lease (asignación de IP)

Para configurar un servidor DHCP que realiza un lease de la dirección IP dinámica dentro de una
subred, declararemos un tiempo de lease por defecto, un tiempo de lease máximo y los valores de confi-
guración de red para los clientes. Esto se puede ver en el ejemplo siguiente que asigna direcciones a los
clientes dentro de un rango:
default-lease-time 600;
max-lease-time 7200;
option broadcast-address 192.168.1.255;
option domain-name-servers 192.168.1.1, 192.168.1.2;
subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.10 192.168.1.100;
}
Asignaciones IP por MAC

Para asignar una dirección IP a un cliente según la dirección MAC de la tarjeta de interfaz de red,
usamos el parámetro hardware ethernet de una declaración host. En el ejemplo siguiente, la declaración
host apex especifica que la tarjeta de interfaz de red con la dirección MAC 00:A0:78:8E:9E:AA siempre
debe ejecutarse en lease con la dirección IP 192.168.1.4. También hay que tener en cuenta, que podemos
usar el parámetro opcional host-name para asignar un nombre host al cliente.
host apex {
option host-name "apex.example.com";
hardware ethernet 00:A0:78:8E:9E:AA;
}

Más opciones
Para obtener una lista completa de sentencias de opciones e información relacionada, podemos consultar
la página del manual de dhcp-options: $man dhcp-options
Base de datos lease

En el servidor DHCP, el fichero /var/lib/dhcp/dhcpd.leases almacena la base de datos lease del cliente
DHCP. Este fichero no debe modificarse manualmente. La información sobre lease de DHCP de cada
dirección IP asignada recientemente se almacena de modo automático en la base de datos lease. La infor-
mación incluye la longitud del lease, al que se ha asignado la dirección IP, las fechas iniciales y finales del
lease, y la dirección MAC de la tarjeta de interfaz de red utilizada para recuperar el lease. Todas las horas
de la base de datos lease se expresan según GMT, no con la hora local.
En el cliente DHCP, el fichero /var/lib/dhcp/dhclient.leases almacena la base de datos lease del servidor
DHCP, como en el caso anterior. El contenido de este archivo se puede ver en el ejemplo siguiente:
lease {
interface "eth0";
option dhcp-lease-time 604800;
option dhcp-message-type 5;
option dhcp-server-identifier 192.168.0.1;
option domain-name "proyecto";
renew 4 2005/5/26 09:33:21;
rebind 0 2005/5/29 13:16:07;
expire 1 2005/5/30 10:16:07;
}
Arranque y parada del servidor

Antes de arrancar por primera vez el servidor DHCP, nos aseguraremos de que existe un fichero
/var/lib/dhcp/dhcpd.leases para que no falle el arranque.
Para interactuar con el servicio DHCP, utilizaremos:

#/usr/sbin/dhcpd start,. . . arrancar el servidor.
#/usr/sbin/dhcpd stop,. . . parar el servidor.
Si tenemos más de una interfaz de red conectada al sistema, pero sólo deseamos que el servidor DHCP
arranque en una de las interfaces, podemos modificar el script init para arrancar desde ese dispositivo.
Para ello, añadimos el nombre de la interfaz o interfaces en el archivo /etc/default/dhcpd :

INTERFACES="eth0" o INTERFACES="eth0 wlan0"
Esto es útil si disponemos de una máquina firewall con dos tarjetas de red. Se puede configurar una tar-
jeta de red como cliente DHCP para recuperar una dirección IP en Internet y la otra puede utilizarse como
servidor DHCP para la red interna, detrás del firewall. Nuestro sistema será más seguro si especificamos la
tarjeta de red conectada a la red interna, ya que los usuarios no pueden conectarse al demonio por Internet.
Otras opciones que pueden ser especificadas incluyen:
-p <portnum>: Especifica el número de puerto UDP en el que DHCPD deberá escuchar, por defecto
es el 67 y el servidor DHCP transmite las respuestas al cliente por el puerto 68. Si especificamos
un puerto en este momento y usamos el Agente de Transmisión DHCP, este debe escuchar por el
mismo puerto.
-f: Ejecuta el demonio como un proceso de en primer plano.
-d: Registra el demonio del servidor DCHP en el descriptor de errores estándar. Se suele usar para
depurar errores, los mensajes son guardados en el archivo /var/log/messages.

-cf archivo: Especifica la localización del archivo de configuración, por defecto se encuentra en
/etc/dhcpd.conf.
-lf archivo: Especifica la localización del archivo de base de datos lease. Si ya existe , es muy
importante que el mismo fichero sea usado cada vez que el servidor DHCP se inicia. Por defecto se
encuentra en /var/lib/dhcp/dhcpd.leases.
-q: No imprime la versión del servidor DHCP cuando se inicia el demonio.
Agente de transmisión DHCP

Si lo vamos a utilizar, para instalarlo realizaremos el correspondiente apt:
#apt-get install dhcp3-relay
Nos creará un nuevo archivo de opciones: /etc/default/dhcp3-relay.
El agente de transmisión DHCP (dhcp-relay) permite transmitir las peticiones DHCP y BOOTP desde
una subred sin un servidor DHCP, dirigidos a uno o más servidores en otras subredes.
Cuando un cliente DHCP pide información, el agente de transmisión DHCP reenvı́a la petición a la
lista de servidores DHCP especificada al iniciarlo. Cuando el servidor DHCP devuelve una respuesta, la
respuesta puede ser broadcast o unicast, en la red que ha enviado la petición originaria.
El agente de transmisión escuchará las peticiones de todas las interfaces a menos que el argumento -i
se use para especificar solo una o varias interfaces donde escuchar. Para iniciar el agente de transmisión
DHCP, usamos el comando:
#dhcrelay <servidor>
Donde servidor es el nombre de al menos un servidor DHCP al que se le deben transmitir las peticiones.
Dhcp-relay se puede iniciar con las siguientes opciones:
-i Nombres de interfaces de red que deben configurarse. Si no se especifica ninguna interfaz,
se configurarán todas y se eliminarán las interfaces sin multidifusión, si se puede.
-p Puerto en el que deberá escuchar dhcp-crelay. Transmite peticiones a los servidores en este
puerto y respuestas a los clientes en el puerto inmediatamente superior.
-d Obliga a dhcp-relay a ejecutarse en primer plano.
-q Desactiva la impresión de configuración de red, cuando arranca dhcp-relay.
9.1.6. Configuración de un cliente DHCP

El primer paso al configurar un cliente DHCP es asegurarse de que el kernel reconoce la tarjeta de la
interfaz de red. La mayorı́a de las tarjetas se reconocen durante el proceso de instalación y el sistema es
configurado para utilizar el módulo correcto en el kernel. Si instalamos una tarjeta después de la instala-
ción, probablemente tendremos que recompilar el kernel.
Para configurar manualmente un cliente DHCP, debemos modificar el archivo /etc/network/interfaces

habilitando el uso de la red con los dispositivos adecuados.
Para configurar las opciones de red debemos modificar el archivo /etc/network/options.
Podemos instalar uno de los siguientes clientes dhcp:
#apt-get install pump, . . . para ejecutar: #pump <dispositivo_red>
#apt-get install dhcp-client-udeb, . . . para ejecutar: #dhclient <dispositivo_red>
#apt-get install dhcp3-client, . . . para ejecutar: #dhclient3 <dispositivo_red>

9.1.7. Configuración gráfica de DHCP, interfaz Webmin

El módulo DHCP para nuestra interfaz web: Webmin, nos facilitará mucho la tarea de administración
del servidor. Para ello realizaremos un apt:
#apt-get install webmin-dhcpd
En las siguientes pantallas podemos observar como realizar todos los pasos detallados en las secciones
anteriores, pero esta vez de forma gráfica.
Figura 9.1: Módulo Webmin para DHCPD

Figura 9.2: Módulo DHCPD WEBMIN: Subredes y redes compartidas
Figura 9.3: Módulo DHCPD WEBMIN: máquinas y grupos de máquinas

9.2. BIND: Servidor de nombres DNS

Los objetivos de un servidor de nombres de dominio son dos:
1. Por una parte, traducir una dirección canónica en una dirección IP.
2. Por otra parte, traducir una dirección IP en una o varias direcciones canónicas, es lo que se conoce
como traducción inversa.
DNS (Domain Name Service) es un sistema jerárquico con estructura de árbol. El inicio se escribe “.”
y se denomina raı́z, al igual que en las estructuras de datos en árbol. Bajo la raı́z se hallan los dominios de
más alto nivel (TLD, del inglés, Top Level Domain), cuyos ejemplos más representativos son ORG, COM,
EDU y NET, si bien hay muchos más (como los dominios de paises, .es, .uk, . . . ). Del mismo modo que
un árbol, tiene una raı́z y ramas que de ella crecen.
Cuando se busca una máquina, la consulta se ejecuta recursivamente en la jerarquı́a, empezando por
la raı́z. Ası́ pues, empezando en “.” encontramos los sucesivos servidores de nombres para cada nivel en el
nombre de dominio por referencia. Por supuesto, nuestro servidor de nombres guardará toda la información
obtenida a lo largo del proceso, a fin de no tener que preguntar de nuevo durante un buen rato. En el
árbol análogo, cada “.” en el nombre es un salto a otra rama. Y cada parte entre los “.” son los nombres
de los nodos particulares en el árbol.
9.2.1. ¿Para qué necesitamos un DNS?

El DNS define:
Un espacio de nombres jerárquico para los hosts y las direcciones IP.

Una tabla de hosts implementada como una base de datos distribuida.
Un traductor (resolver) o librerı́a de rutinas que permite realizar consultas a esa base de datos.
Enrutamiento mejorado para el correo electrónico.
Un mecanismo para encontrar los servicios en una red.
Un protocolo para intercambiar información de nombres.
Para ser auténticos ciudadanos de Internet, los sitios necesitan el DNS. Mantener un fichero local
/etc/hosts con un mapeado de todos los hosts que los usuarios puedan querer contactar no es factible.
Cada sitio mantiene una o varias piezas de la base de datos distribuida que posibilita el servicio global
del sistema DNS. Su pieza de la base de datos consiste en dos o más ficheros de texto que contienen registros
para cada uno de los hosts. Cada registro es una sencilla lı́nea consistente en un nombre (normalmente el
nombre de un host), un tipo de registro y diversos valores o datos.
Es un sistema cliente/servidor. Los servidores (de nombres) cargan los datos de sus ficheros de DNS en
memoria y los usan para responder las consultas tanto de los clientes de la red interna como de los clientes
y otros servidores en Internet. Todos nuestros hosts deberı́an ser clientes del DNS, pero relativamente
pocos necesitan ser servidores de DNS.
Si nuestra organización es pequeña (unos pocos hosts en una única red), podemos ejecutar un servidor
en uno de nuestros equipos o pedirle al ISP (Proveedor de servicios) que nos proporcione el servicio. Un
sitio de tamaño medio con diversas subredes deberı́a tener múltiples servidores de DNS para reducir la
latencia de las consultas y mejorar la productividad. Un sistema muy grande puede dividir los dominios
de DNS en subdominios y usar algunos servidores para cada subdominio.

9.2.2. Servicios que activa un DNS

Servicios de los que se puede disponer con un servidor DNS, son los siguientes:
Resolución de nombres a direcciones IP.
Resolución inversa (de direcciones IP a nombres).
Listas de control de acceso.
Servidores secundarios.
Transferencia segura de zonas entre servidores primarios y secundarios (y puertos).
Localización de servicios.
Respuestas parametrizadas en función del origen de la petición (vistas).
Uso de la herramienta rndc.
Logs a medida.
9.2.3. Configuración del servidor

Un FQDN (Nombre de Dominio Totalmente Cualificado) está formado por un host y un nombre de
dominio, incluyendo el de más alto nivel. Por ejemplo, www.upc.es es un FQDN. www es el host, upc es
el dominio de segundo nivel y .es es el dominio de de más alto nivel. Un FQDN siempre comienza con el
nombre del host y continúa subiendo directo al dominio de más alto nivel.
Si necesitamos proveer un servicio de nombres para un dominio, podemos utilizar un servidor de nom-
bres completo: como named, que viene con el paquete bind o bind9. Para nuevas instalaciones se recomienda
bind9, ya que soluciona problemas de seguridad que tenı́an las versiones anteriores. DNS es uno de los
puntos más frágiles y puede ser atacado en cualquier momento, borrando nuestras máquinas de la red.
Para instalar bind9, se necesitan los siguientes paquetes:

bind9
bind9-doc
dnsutils
Para instalarlos simplemente realizamos un apt:

#apt-get install bind9 bind9-doc dnsutils
Aunque puede que también queramos instalar estos paquetes de utilidades:

bind9-host
dns-browse
dnscvsutil
nslint
bind9-doc
libbind-dev
libnet-dns-perl
dhcp-dns

Los archivos de configuración que intervendrán serán los siguientes:

/etc/bind/named.conf : Para definir las zonas DNS básicas.
/etc/bind/named.conf.local : Para definir las zonas locales.
/etc/bind/named.conf.options: Para configurar opciones.
/etc/bind/db.lan: Para añadir los equipos de una LAN.
/etc/bind/db.192.168.0 : Para añadir el DNS inverso de una LAN.
El archivo /etc/bind/named.conf.options también es procesado por resolvconf para producir:

/var/run/bind/named.options
Este archivo es el mismo que el original, excepto que la especificación forwarders es una lista de los
servidores de nombres no locales, actualmente disponibles.
Para hacer uso de ello, cambiamos la lı́nea include del /etc/bind/named.conf de modo que incluya:
/var/run/bind/named.options
Los archivos de base de datos sin una ruta explicita, y que se han definido en cualquiera de los archivos
de configuración de named se almacenarán en /var/cache/bind/.
9.2.4. Traducción de nombres a direcciones IP

El primer paso es editar el fichero /etc/bind/named.conf.options, donde cambiaremos algunos de los
valores por defecto y añadiremos todo lo necesario para que nuestro dominio sea accesible desde el exterior.
A menos que seamos un proveedor de servicios de internet, se nos habrán proporcionado una o más
direcciones IP de servidores de nombres estables, que seguramente querremos usar como redireccionadores
(forwarders). Para ello deberemos descomentar el bloque al principio del fichero:
// forwarders {
// 0.0.0.0;
// };
Y dejarlo en algo como esto:
forwarders {
194.224.52.4;
194.224.52.6; };
Entre las opciones también se encuentra ocultar la versión de Bind, para una mayor seguridad del
sistema: "DNS server";
9.2.5. Configuración gráfica de DNS BIND, interfaz Webmin

Para facilitarnos la compleja tarea de configuración de DNS BIND es posible utilizar la herramienta
de administración web: Webmin.
Para la instalación del módulo correspondiente, utilizamos el siguiente apt:

#apt-get install webmin-bind
En los apartados siguientes iré comentando las opciones a las que se puede acceder desde el módulo
web.

Pantalla principal
Para acceder al servidor BIND, pulsamos sobre la pestaña “Servidores” y después sobre el icono “Ser-
vidor de DNS BIND”, aparecerá el menú de configuración, como se observa en la figura 9.4.
En este menú podemos realizar las siguientes opciones:
Configurar el resto de opciones globales del servidor.

Crear un servidor DNS primario.
Crear un servidor DNS secundario.
Crear un servidor DNS de cache.

Crear un servidor DNS de reenvı́o.
Figura 9.4: Interfaz gráfica Webmin para el servidor DNS BIND
Para que todos los cambios sean tenidos en cuenta, es necesario reiniciar el servidor DNS BIND, se
realiza pulsando el botón “Aplicar Cambios” en la página de configuración principal del servidor DNS.
Pasemos a ver cada una de las secciones a las que podemos acceder.

Opciones generales
Como se puede observar en la figura 9.5, desde estas secciones podemos modificar los valores contenidos
en el archivo /etc/bind/named.conf.
Figura 9.5: Webmin BIND: Opciones generales

Crear zona maestra
En esta sección podemos crear un servidor DNS primario o editar sus parámetros una vez configurado.
Figura 9.6: Webmin BIND: Servidor primario
Crear zona subordinada
En esta sección podemos crear y modificar todos los parámetros de un servidor DNS secundario.
Figura 9.7: Webmin BIND: Servidor secundario
Los servidores DNS son dos (o más) para evitar que el fallo de uno impida el acceso a los servicios
asociados al dominio, esto es, por motivos de redundancia. Si bien es posible utilizar un único servidor
DNS no es una práctica recomendable.
A pesar del nombre servidor “secundario”, la información que contienen estos servidores DNS, es el
mismo valor que cualquier otro servidor DNS primario, la razón principal por la que se configura un servidor
secundario es para ofrecer un nivel de respaldo y reducir la carga de los servidores DNS principales, pero
sobre todo para reducir la carga administrativa en el caso de necesitar varios servidores.
La única diferencia que existe entre un primario y un secundario en DNS, es que el secundario obtiene su
información copiando el Archivo de Zona del primario que se le ha indicado en el archivo de configuración.
La actualización de esta copia de Archivo de Zona es conocida como “Zone Transfer” y ocurre depen-
diendo de los parámetros que hayan sido definidos.

Crear zona de sólo cache

En esta sección podemos crear y modificar todos los parámetros de un servidor DNS de cache.
Figura 9.8: Webmin BIND: Crear zona de sólo cache
Este tipo de servidor DNS mantiene copias de las resoluciones (“cache”) que ya han sido buscadas
en otros servidores DNS primarios o secundarios, esto no implica que los servidores DNS primarios y
secundarios no mantengan copias de sus resoluciones “caches”, lo único que se evita en este tipo de
servidores DNS es mantener Archivos de Zona, toda resolución que realice un servidor “cache” debe ser
consultada con un servidor que primario o secundario.
Una de las principales razones por las cuales se configura un servidor “cache” , es cuando se utiliza una
conexión lenta, esto evita la necesidad de requerir resoluciones que ya fueron resueltas en una ocasión, y
por lo tanto evitan un cierto nivel de tráfico, aprovechando la información local para buscar resoluciones
de nombres.
Crear zona de reenvı́o

En esta sección podemos crear y modificar todos los parámetros de un servidor DNS que reenvie las
peticiones a otro servidor.
Figura 9.9: Webmin BIND: Crear zona de reenvı́o
Si los clientes de la red tienen que poder resolver nombres DNS externos, puede que necesitemos
configurar y utilizar servidores de reenvı́o en los servidores DNS de nuestra red.

Para utilizar reenviadores que administren el tráfico DNS entre nuestra red e Internet, configuramos el
firewall para permitir que sólo un servidor DNS se comunique con Internet. Cuando hayamos configurado
los demás servidores DNS de nuestra red para reenviar a ese servidor DNS consultas que no puedan
resolver localmente, ese servidor funcionará como nuestro único reenviador.
9.2.6. Seguridad en DNS

Los servidores que controlan y mantienen los nombres de dominio de nuestra red, ofrecen a los atacantes
un objetivo tentador. El servicio de denominación de nombres de Internet de Berkley (BIND, Berkley
Internet Naming domain), es decir, el servidor DNS primario, ha estado constantemente en la lista de los
diez servicios más atacados. DNS es un programa antiguo y su estructura deja brechas potenciales (un
binario monolı́tico en lugar de una arquitectura más modular). Además DNS, frecuentemente se ejecuta
como raı́z, lo que hace que sea más peligroso.
Ası́ mismo, como DNS es difı́cil de configurar y se conoce poco, se suele configurar y asegurar mal. Las
configuraciones de cortafuegos para DNS no se implementan correctamente, permitiendo a casi todos los
administradores acceder de dentro a fuera sin filtros.
Aunque el web, el correo electrónico y otros servicios tienen más visibilidad y captan más la atención
del administrador, las brechas DNS ofrecen la forma más rápida y fácil de dejar a nuestra empresa fuera
del mapa de Internet. Incluso aunque tengamos conectividad IP con el mundo, sin un servicio DNS válido
para nuestros dominios, nadie podrı́a llegar a nuestro servidor web y no se producirı́a ningún flujo de
correo. De hecho, se ha citado DNS como el punto más débil en toda la infraestructura de Internet y
un objetivo potencial para los ataques del terrorismo cibernético. En lugar de introducirse en nuestros
servidores o atravesar nuestro cortafuegos, un atacante puede simplemente enviar un DoS (denegación de
servicio) contra nuestro servicio DNS, quitando del aire a nuestra empresa de una forma efectiva, o peor
aún, utilizando un tipo de ataque denominado veneno de cache DNS, los exploradores web enlazados a
nuestro sitio serán redireccionados al sitio que le apetezca al atacante.
Se conocen al menos cuatro vulnerabilidades BIND. Todas permiten a un atacante ejecutar cualquier
código con los mismos privilegios que el servidor DNS. Como usualmente BIND se ejecuta en una cuen-
ta de root, la este código puede lanzarse con los mismos privilegios. Además, se puede interrumpir la
propia operación del servidor BIND, y obtener otro tipo de información, que llevarı́a a explotar otras
vulnerabilidades diferentes en el sistema.
¿Cuáles son los sistemas son afectados?

Están afectados todos los servidores de nombres de dominio (DNS), que ejecutan las versiones de
BIND 4.9.8 y 8.2.3 (y todas las anteriores). Las versiones 9.x, ya se encuentran corregidas. Como el
funcionamiento normal de la mayorı́a de los servicios de Internet depende del funcionamiento apropiado
de los servidores de DNS, podrı́an afectar otros servicios si estas vulnerabilidades son explotadas.
¿Como usuario domestico, nos debemos preocupar por este problema?

Los usuarios comunes, también estamos afectados por este problema, aunque en forma indirecta. Ge-
neralmente contamos con un proveedor de servicios de Internet (ISP), que es el que nos proporciona el
servicio DNS. Es el ISP, quien debe proteger sus sistemas.
Sin embargo, los usuarios de Linux o con otras variantes de Unix instaladas en sus máquinas, deberı́an
verificar si poseen una version vulnerable de BIND instalada, ya que en ese caso, ellos necesitan desac-
tivar o actualizar este software. Son varios los sistemas operativos Unix/Linux que instalan un servidor
DNS por defecto. Ası́, algunos usuarios podrı́an estar ejecutando este servicio, sin haberlo configurado
explı́citamente.

9.3. NIS: Servicio de información de red

El servicio de información de red (NIS, Network Informatión Service) hace posible la compartición
de archivos crı́ticos a través de una red de área local. Normalmente, archivos tales como /etc/passwd
y /etc/group, que idealmente deberı́an permanecer sin cambios entre todas las máquinas, se comparten
mediante NIS. De esta forma, cada máquina de red que tiene su cliente NIS correspondiente puede leer los
datos contenidos en esos archivos compartidos y usar las versiones de red de los archivos como extensiones
de sus versiones locales.
El beneficio principal que se alcanza mediante el uso de NIS es que puede mantener una copia central
de los datos, y aunque los datos se actualicen, automáticamente se propagan a todos los usuarios de la red.
A los usuarios, NIS da la apariencia de un sistema más uniforme (no importa con qué máquina trabaje,
que todas sus herramientas y archivos estarán allı́).
9.3.1. Funcionamiento básico

Es, simplemente, una base de datos que los clientes pueden consultar. Consta de una serie de tablas
independientes. Cada tabla se origina como un archivo de texto, como el /etc/passwd, el cual tiene una
naturaleza tabular y tiene al menos una columna que es única por cada archivo. NIS accede a esas tabla
por nombre y permite búsquedas de dos formas:
Listado de la tabla entera
Presentación de una entrada especı́fica basada en una búsqueda por una clave dada
Una vez establecidas las bases de datos en el servidor, los clientes pueden buscar en el servidor las
entradas de la base de datos. Normalmente esto ocurre cuando un cliente se configura para que busque en
un mapa NIS cuando no encuentra una entrada en su base de datos local. Una máquina puede tener sólo
las entradas que necesite para que el sistema trabaje en modo usuario único (cuando no hay conectividad
por red), por ejemplo, el archivo /etc/passwd. Cuando un programa hace una petición de búsqueda de la
información de contraseña de un usuario, el cliente comprueba su archivo passwd local y si el usuario no
existe allı́, entonces el cliente hace la petición a su servidor NIS para buscar la entrada correspondiente en
la tabla de contraseñas. Si NIS tiene entrada, la devolverá cliente y al programa que pidió la información.
El propio programa no se da cuenta de que se ha usado NIS. Lo mismo es cierto si el mapa NIS devuelve la
respuesta de que la entrada de contraseña del usuario no existe. El programa deberı́a recibir la información
sin que sepa qué ha ocurrido entre medias.
Esto se aplica a todos los archivos que se comparten por NIS.
Otros archivos comunes compartidos incluyen a /etc/group y /etc/hosts.
9.3.2. Servidores NIS

NIS puede tener un único servidor autorizado donde permanecen los archivos de datos originales (en
esto es similar a DNS). Este servidor autorizado se llama servidor NIS maestro. Si nuestra organización
es grande, podemos necesitar distribuir la carga entre más de una máquina. Esto lo podemos hacer
configurando uno o más servidores NIS secundarios. Además de ayudar a distribuir la carga, los servidores
secundarios también proporcionan un mecanismo de manejo de fallos de servidores, ya que puede continuar
contestando peticiones incluso mientras el maestro u otros secundarios están caı́dos.
Los servidores NIS secundarios reciben actualizaciones si el servidor NIS primario se actualiza, ası́ que
los maestros y esclavos permanecen sincronizados. El proceso de mantener la sincronización del los secun-
darios con el primario se llama server push.
El NIS maestro, como parte de sus scripts de actualización, también pone una copia de sus archivos
de mapas en los secundarios. Una vez recibidos los archivos, los servidores secundarios actualizan también
sus bases de datos. El NIS maestro no se considera completamente actualizado hasta que se actualizan
todos sus secundarios.
Hay que señalar que un servidor puede ser a la misma vez servidor y cliente.

Los servidores NIS primarios establecen dominios que son similares a los dominios de un PDC (Con-
trolador Primario de Dominio). Una diferencia significativa es que el dominio NIS no requiere que el
administrador del servidores NIS permita explı́citamente unirse a un cliente. Además, el servidor NIS sólo
envı́a datos, no realiza autenticación. El proceso de autenticación de usuarios se deja a cada máquina indi-
vidual. Unicamente proporciona una lista de usuarios centralizada, ya que todos los clientes son miembros
del mismo dominio administrativo y están gestionados por los mismos administradores de sistemas.
Deberemos dar nombre a los dominios NIS, y es una buena práctica (aunque no obligatoria) usar
nombres distintos de nuestros nombres de dominios DNS. Nos será mucho más fácil explicar los dominios
de nuestra red a otros administradores identificando el dominio NIS al que nos referimos.
Es posible facilitar la configuración mediante un módulo para la herramienta de administración web

Webmin.
Para la instalación se utiliza el siguiente apt:

#apt-get install webmin-nis
Figura 9.10: Interfaz gráfica Webmin para el servidor NIS
9.3.3. Configuración del servidor NIS maestro

La primera cosa que hemos de tener presente es que no podemos montar dos servidores NIS diferentes
para un mismo dominio de una red. Si ya existe un dominio en nuestra red deberemos configurar un
cliente.
Cuando NIS se desarrolló, en los años ochenta, se le llamó “páginas amarillas” (Yelow Pages, YP
para abreviar). Cuando Sun Microsystems, los desarrolladores del sistemas operativo SunOS (Solaris),
empezaron a vender sus sistemas en el Reino Unido, ocurrió un conflicto: el término “páginas amarillas”
era una marca registrada de British Telecom y para evitar un pleito, Sun renombró el paquete a Servicio
de información de red, después otros vendedores de Unix le siguieron.
Por eso hoy encontraremos que todas las herramientas NIS vienen con el prefijo yp en lugar de nis.
Por alguna razón los nombres de archivo no se cambiaron con el nombre oficial de paquete.

Para instalar el servidor NIS realizaremos un apt:

#apt-get install nis,. . . la instalación nos pedirá que especifiquemos el nombre de dominio
Para obtener más información se instala en el sistema el HowTo de NIS, documento muy clarificador:
/usr/share/doc/nis/nis.debian.howto.gz
Disponemos de varios archivos de configuración:
/etc/yp.conf
/etc/nsswitch.conf
/etc/ypserv.conf
/etc/ypserv.securenets
Una vez configurados el archivo:
#ypserv start, . . . arranca el servidor NIS
#ypserv stop, . . . para el servidor NIS
Después de la instalación podemos cambiar el nombre del dominio con el comando:

#domainname <dominio>, . . . como por ejemplo: #domainname proyecto.debian.com
Naturalmente, a fin de que se establezca cada vez que volvamos a arrancar el sistema, es necesario
situar el comando domainname en uno de los archivos de inicio rc#.d (Véase apéndice D). Para elegir
el runlevel del archivo donde realizar el cambio de nombre tenemos que tener en cuenta que hay que
cambiarlo antes de que se arranquen los servidores NIS.
Archivos compartidos en NIS

Para compartir los archivos en NIS, necesitamos situarnos en el directorio: /var/yp
Allı́ encontraremos un Makefile. Este archivo lista los archivos que se compartirán mediante NIS,
ası́ como algunos parámetros adiciónales sobre cómo compartirlos. Editamos el Makefile y retocamos las
opciones como se detalla en esta y posteriores secciones. Sin embargo, que se listen aquı́ no significa que
se compartan automáticamente. Este listado simplemente establece los nombres de archivos que se com-
partirán una vez compilemos el Makefile.
La mayorı́a de las entradas comienzan con: $(YPWDIR) y $(YPSRCDIR), son variables que se configuran
al inicio del Makefile, y señalan la ruta donde encontrar los archivos, el valor por defecto es /etc.
Una vez configurado el Makefile, para actualizar los mapas de archivos y configurar el servidor NIS
como primario simplemente ejecutamos:
#ypinit -m, . . . la opción -m le dice que un servidor primario
Ypinit ejecutará el make, para construir los mapas y ponerlos en los servidores secundarios que se le
indiquen en /var/yp/yp-servers.

En el cuadro 9.1 puede observar un listado tı́pico del archivo /var/yp/Makefile.
Cuadro 9.1: Listado del archivo NIS /var/yp/Makefile

# Makefile for the NIS databases
#
# This Makefile should only be run on the NIS master server of a domain.
# All updated maps will be pushed to all NIS slave servers listed in the
# /var/yp/ypservers file. Please make sure that the hostnames of all
# NIS servers in your domain are listed in /var/yp/ypservers.
#
# This Makefile can be modified to support more NIS maps if desired.
...
# If we have only one server, we don’t have to push the maps to the
# slave servers (NOPUSH=true). If you have slave servers, change this
# to "NOPUSH=false" and put all hostnames of your slave servers in the file
# /var/yp/ypservers.
NOPUSH=true
...
# We do not put password entries with lower UIDs (the root and system
# entries) in the NIS password database, for security. MINUID is the
# lowest uid that will be included in the password maps. If you
# create shadow maps, the UserID for a shadow entry is taken from
# the passwd file. If no entry is found, this shadow entry is
# ignored.
# MINGID is the lowest gid that will be included in the group maps.
MINUID=1000
MINGID=1000
...
# Should we merge the passwd file with the shadow file ?

# MERGE_PASSWD=true|false
MERGE_PASSWD=false
# Should we merge the group file with the gshadow file ?

# MERGE_GROUP=true|false
MERGE_GROUP=false
...
# These are the source directories for the NIS files; normally
# that is /etc but you may want to move the source for the password
# and group files to (for example) /var/yp/ypfiles. The directory
# for passwd, group and shadow is defined by YPPWDDIR, the rest is
# taken from YPSRCDIR.
#
YPSRCDIR = /etc
YPPWDDIR = /etc
YPBINDIR = /usr/lib/yp
YPSBINDIR = /usr/sbin
YPDIR = /var/yp
YPMAPDIR = $(YPDIR)/$(DOMAIN)
# These are the files from which the NIS databases are built. You may edit
# these to taste in the event that you wish to keep your NIS source files
# seperate from your NIS server’s actual configurati\’on files.
#
GROUP = $(YPPWDDIR)/group
PASSWD = $(YPPWDDIR)/passwd
SHADOW = $(YPPWDDIR)/shadow
GSHADOW = $(YPPWDDIR)/gshadow
ADJUNCT = $(YPPWDDIR)/passwd.adjunct
ALIASES = $(YPSRCDIR)/aliases
ETHERS = $(YPSRCDIR)/ethers # ethernet addresses (for rarpd)
BOOTPARAMS = $(YPSRCDIR)/bootparams # for booting Sun boxes (bootparamd)
HOSTS = $(YPSRCDIR)/hosts
NETWORKS = $(YPSRCDIR)/networks
PRINTCAP = $(YPSRCDIR)/printcap
PROTOCOLS = $(YPSRCDIR)/protocols
PUBLICKEYS = $(YPSRCDIR)/publickey
RPC = $(YPSRCDIR)/rpc
SERVICES = $(YPSRCDIR)/services
NETGROUP = $(YPSRCDIR)/netgroup
NETID = $(YPSRCDIR)/netid
AMD_HOME = $(YPSRCDIR)/amd.home
AUTO_MASTER = $(YPSRCDIR)/auto.master
AUTO_HOME = $(YPSRCDIR)/auto.home
AUTO_LOCAL = $(YPSRCDIR)/auto.local
TIMEZONE = $(YPSRCDIR)/timezone
LOCALE = $(YPSRCDIR)/locale
NETMASKS = $(YPSRCDIR)/netmasks
YPSERVERS = $(YPDIR)/ypservers # List of all NIS servers for a domain
....

Configuración de un NIS maestro para poner esclavos

Esto requiere dos tareas:
Editar el archivo /var/yp/yp-servers para colocar todos los servidores NIS secundarios a los que el
servidor maestro deberá mandar sus mapas. Esto se consigue introduciendo, en una lı́nea diferente,
los nombres de hosts de cada servidor secundario. Por cada nombre de host que listemos en este
archivo tenemos que colocar su entrada correspondiente en el archivo /etc/hosts.
Asegurarnos de que el /var/yp/Makefile tiene la lı́nea NOPUSH=false
Establecer UID y GID mı́nimos. Obviamente, no queremos compartir la entrada de root mediante
NIS, entonces el mı́nimo deberı́a ser mayor que cero. Estas variables del /var/yp/Makefile son:
MINUID=<numero>
MINGID=<numero>
Configuración de un servidor NIS secundario

Cuando crece nuestra red, indudablemente encontraremos que necesitamos distribuir la carga de nues-
tro servicio NIS entre varias máquinas. Esto es soportado a través del uso de servidores NIS secundarios.
Los servidores no requieren mantenimiento adicional una vez configurados, debido a que el servidor NIS
maestro les envı́a las actualizaciones si se recontruyen los mapas.
Hay que seguir tres pasos para configurar el servidor NIS secundario:
Configurar el nombre de dominio (domainname)
Configurar el maestro NIS al que se va a unir el esclavo
Ejecutar: #ypinit -s <nis_maestro>, . . . para iniciar el servidor esclavo
Autenticar usuarios mediante NIS

Como NIS se puede usar con otros sistemas para autenticar usuarios, necesitaremos permitir que las
entradas de contraseña encriptadas se compartan. Si usamos contraseñas shadow, NIS automáticamente lo
manejará, tomando el campo encriptado del archivo /etc/shadow y mezclándolo con la copia compartida
de /etc/passwd en NIS.
Ésta opción se encuentra en el archivo /var/yp/Makefile. A menos que tengamos una razón especı́fica
para no compartir las contraseñas, dejaremos la variable MERGE PASSWD=true.
El archivo /etc/group permite tener contraseñas de grupo aplicadas en el sistema. Puesto que necesita
ser de lectura para todo el mundo, algunos sistemas ofrecen soporte a archivos shadow de grupos. A menos
que dispongamos y usemos, el archivo /etc/gshadow, configuraremos la opción MERGE GROUP=false.
9.3.4. Cliente NIS

El primer paso que deberemos realizar es indicar al cliente NIS, ypbind, cuál es el dominio al que se va
a conectar, siendo el comportamiento por defecto de ypbind interrogar al servidor de la red local a la que
está conectado.
De esta forma, si se trata de un ordenador portátil, el cual deberá conectarse a diferentes redes pode-
mos optar por dejar el archivo /etc/yp.conf vacı́o sin especificar el dominio a emplear, de esta forma el
ypbind realizará la consulta por defecto en la red local en donde se esta conectando.
Para lanzar el cliente NIS, ejecutaremos el siguiente comando:

#ypbind

Configuración local de NIS: /etc/yp.conf

Si hubiera más de un dominio en la red especificaremos el servidor NIS de la siguiente forma:
# yp.conf Configurati\’on file for the ypbind process. You can define
# NIS servers manually here if they can’t be found by
# broadcasting on the local net (which is the default).
#
# See the manual page of ypbind for the syntax of this file.
#
# IMPORTANT: For the "ypserver", use IP addresses, or make sure that
# the host is in /etc/hosts. This file is only interpreted
# once, and if DNS isn’t reachable yet the ypserver cannot
# be resolved and ypbind won’t ever bind to the server.
ypserver ypserver.network.com
Donde ypserver.network.com es el nombre del servidor NIS al que nos conectaremos. Evidentemente
el ordenador debe saber como resolver el nombre del servidor, ya sea utilizando DNS o especificando el
nombre e IP en el archivo /etc/hosts.
También podemos especificar múltiples dominios en el archivo /etc/yp.conf de la siguiente forma:
#yp.conf
#
domain proyecto server debian
domain casa server debian-home
Al arrancar el ordenador podemos emplear el comando domainname para especificar el dominio al que
nos estamos conectando. De esta forma el cliente NIS selecciónará el servidor adecuado:
#domainname proyecto
Si no supiéramos el nombre o IP del servidor en un determinado dominio se podrı́a modificar el archivo

de configuración de la siguiente forma:
#yp.conf
#
domain proyecto server debian
domain casa server debian-home
domain trabajo broadcast
La opción broadcast indica al cliente NIS que, si nos conectamos al dominio trabajo, debe utilizar el
servidor que encuentre en la red local.
Seleccionar los archivos de configuración del servidor

Una vez establecida la conexión con el servidor NIS, es necesario especificar qué archivos de configu-
ración importaremos.
Normalmente los archivos de configuración serán los correspondientes a la configuración de usuarios,
grupos y en el caso de redes que no utilicen DNS, el archivo de hosts. Pudiendo importar cualquier archivo
de configuración común a todos los ordenadores de la red y que sufra modificaciones periódicas, evitando
de esta forma tener que realizar manualmente esta tarea en cada ordenador de la red.
Esto se realiza mediante el archivo:

/etc/nsswitch, . . . Name Service Switch
El orden correcto de los servicios dependerá del tipo de datos que cada uno de ellos ofrezca, ası́ nor-
malmente se consultará en primer lugar el archivo local y posteriormente el ofrecido por NIS.
Como antes he comentado, una de las principales utilidades de NIS es mantener sincronizados en la
red los archivos empleados para la administración de usuarios, de tal forma que podamos tener un control
total sobre los usuarios que pueden acceder a los diferentes ordenadores de la red sin necesidad de editar
manualmente cada uno de los hosts.

No obstante, con activar este servicio en /etc/nsswitch.conf, no es suficiente, debemos asegurarnos de

que el número o ID de los usuarios locales coinciden con el de los contenidos en el servidor.
Una vez realizada esta comprobación podremos activar este servicio NIS añadiendo el siguiente código
al archivo /etc/nsswitch.conf :
passwd: nis files

group: nis files
El formato del archivo /etc/nsswitch.conf es el siguiente:

nombre-archivo: nombre-servicio
Donde nombre-archivo es el nombre del archivo que necesita referenciarse y nombre-servicio es el nom-
bre del servicio que se utiliza para encontrar el archivo. Se pueden listar varios servicios, separados por
espacios.
Estos son los servicios válidos:
Servicio Descripción
files Usa el archivo de la propia máquina
yp Usa NIS para realizar la búsqueda
nis Usa NIS para realizar la búsqueda (nis es un alias de yp)
dns Usa DNS para realizar la búsqueda (se aplica sólo al archivo hosts)
[NOTFOUND=return] Detiene la búsqueda
nis+ Usa NIS+
Prueba de configuración del cliente NIS

Una vez hayamos configurado los archivos:
/etc/yp.conf
/etc/nsswitch.conf
Y tengamos en funcionamiento el demonio de cliente ypbind, podemos usar el comando ypcat para
volcar un archivo de nuestro servidor NIS en pantalla. Para ello, escribimos: #ypcat passwd
Vuelca el archivo passwd (mapa del archivo) en pantalla (si es que lo estamos compartiendo por NIS).
Si no vemos el archivo, necesitamos hacer una comprobación de las configuraciones del servidor y el cliente
cliente, y probar de nuevo.
9.3.5. Herramientas básicas

Para trabajar con NIS disponemos de algunas herramientas que extraen información de la base de
datos mediante la lı́nea de comandos:
ypcat: Comentada en la sección anterior, vuelca los contenidos de un mapa NIS (archivo NIS).
ypwhich: Devuelve el nombre del servidor NIS que responde a las peticiones. También es una buena
herramienta de diagnóstico, si NIS parece no funcionar correctamente.
ypmatch: Es muy parecido a ypcat. Sin embargo, en lugar de mostrar el mapa entero, le proporciona-
mos un valor clave y solo aparecerá la entrada correspondiente a esa clave. Esto es útil, por ejemplo,
para el passwd: #ypmatch josan passwd

9.3.6. Problemas de seguridad

NIS se considera seguro, desde el punto de vista del servidor, puesto que no modifica los mapas direc-
tamente y los archivos pueden ser leı́dos por todo el mundo.
Desde el punto de vista del cliente, la seguridad es bastante pobre. Incluso en una red local, hay que
saber que las contraseñas circulan sin encriptar sobre la red. Cualquier máquina puede “escuchar” los
intercambios entre un cliente NIS y el servidor.
Por defecto no se utiliza ningún algoritmo de cifrado en estas comunicaciones. Y como no utiliza au-
tenticación a nivel de RPC, cualquier máquina de la red puede enviar una respuesta falsa, y pasar por el
servidor de NIS. Para que el ataque tenga éxito, el paquete con la respuesta falsa debe llegar al cliente
antes de que responda el servidor. También debe ser capaz de observar la petición y generar la respuesta,
para ello es preciso que la máquina que lleva a cabo el ataque esté situada en el camino de comunica-
ción entre servidor y cliente. Se puede crear fácilmente un mapa NIS para sustituir al del servidor. Un
intruso podrá acceder al cliente NIS a través de los comandos de acceso remoto, cambiando en el mapa,
la dirección de la máquina que lleva a cabo la intrusión, por otra máquina que se encuentre en el archivo
/etc/hosts.allow.
La solución de estos problemas de seguridad pasa por utilizar autenticación en el protocolo RPC. NIS+
trata de solucionar ese problema, mediante soporte para el cifrado. Elimina la mayor parte de problemas
de seguridad que NIS planteaba, puesto que utiliza RPCs seguros, si se configuran de forma adecuada. En
estos momentos NIS+ es bastante experimental e inestable, por eso me he centrado en NIS.
En NIS también se han buscado algunas soluciones al problema de la seguridad. Solı́a tener un defecto
grave, dejaba su archivo de contrasenãs legible por prácticamente cualquier persona en todo Internet, esto
suponı́a un gran número de posibles intrusos. Si un intruso sabı́a nuestro dominio NIS y la dirección de
nuestro servidor, simplemente tenı́a que enviar una consulta al mapa passwd y recibir al instante todas
las contraseñas encriptadas del sistema. Con un programa rápido para crackear contraseñas, y un buen
diccionario, averiguar unas cuantas contraseñas de usuario no tenı́a ningún problema.
De todo esto trata la opción securenets. Simplemente restringe el acceso a su servidor NIS a ciertos
nodos, basándose en la dirección IP. La última versión de ypserv implementa esta caracterı́stica de dos
formas.
Utilizando un archivo de configuración especial: /etc/ypserv.securenets.

Utilizando convenientemente los archivos /etc/hosts.allow y /etc/hosts.deny.

9.4. NFS: Sistema de archivos Linux en red

NFS es un protocolo que data de los años 80. En esas fechas los problemas de seguridad eran menores.
Todavı́a podı́an construirse protocolos basados en la confianza, tanto el servidor como el cliente, confiando
en la información que intercambian. Internet convierte este principio en algo absurdo y este es sin duda
uno de los mayores problemas de NFS. La segunda versión del protocolo es la primera versión publicada
y sigue la siendo la más extendida en nuestros dı́as. Existen implementaciones sobre varias plataformas
diferentes y se han descrito pocos problemas de compatibilidad.
La tercera versión del protocolo data de 1992 y presenta varias mejoras:

Mejora del rendimiento debido a la reescritura del código de red y uso de paquetes de datos mayores.
Mejora en la seguridad:
• Listas de ACL (Listas de control de acceso) que permiten definir acceso a los recursos por UID
y archivo a archivo.
• Implementación de un sistema de autenticación basado en contraseña.
Por desgracia, la tercera versión de NFS para Linux, esta todavı́a en pañales. NFS para GNU/Linux
es intrı́nsecamente inseguro y peligroso si se administra mal.
NFS es una interfaz entre el sistema de archivos fı́sico y un sistema remoto. Cuando NFS recibe una
petición vı́a red, opera las modificaciones sobre el sistema local.
Dispone de todo lo que podemos esperar de un sistema de archivos tipo Unix: gestión de permisos,
propiedades avanzadas, enlaces, tuberı́as con nombre . . .
Pero como indica su nombre ha sido ideado para ser usado de forma transparente a través de la red.
Desde el punto de vista del cliente, se trata de un sistema de archivos clásico, se monta con mount,
y se integra en la jerarquı́a de archivos existente en la máquina. Todas las ordenes de entrada/salida son
enviadas al servidor que se encarga de procesarlas, controlar acceso concurrente a archivos, etc.
9.4.1. Cliente NFS

Montaje de las particiónes
Para poner en servicio un cliente de NFS, hay que asegurarse de que el kernel de Linux que estamos
usando tiene compilado el soporte para NFS.
Para montar una partición hay que conocer algunos parámetros:
El nombre del servidor.

El nombre de la partición a la que se desea acceder.
El nombre del directorio donde vamos a montar la partición NFS.
La sintaxis del comando mount es la siguiente:

#mount -t nfs maquina:particion_a_montar punto_de_montaje
Se puede facilitar el montaje de una partición si la incluimos en el /etc/fstab para que se monte al
iniciarse el sistema.
Podrı́amos usar algunas opciones de montaje para dotar de mayor seguridad al sistema.
La opción -o nosuid quita el bit SUID sobre los ejecutables montados por NFS. Esto puede resultar
molesto si estamos montando /usr pero tiene sentido si estamos montando particiones de datos.
La opción -o noexec es todavı́a más radical, ya que imposibilita la ejecución de programas desde
la partición montada por NFS. Si tenemos usuarios que escriben scripts esta opción puede ser muy
molesta.

Ejemplos de uso
Los ejemplos de uso de una partición NFS son numerosos. Podemos imaginar, entre otros, una partición
de lectura/escritura sobre /home. Ası́ cada usuario puede trabajar sobre cualquier máquina de la red
encontrando siempre sus archivos personales sin esfuerzo.
Es frecuente que se exporten los buzones de correo de los usuarios. Esta es una mala idea, ya que la
gestión de concurrencia de NFS no es muy fiable y exportar /var/spool/mail por ejemplo, puede producir
pérdidas de mensajes.
Podemos también compartir una partición que contenga ejecutables, como /usr/bin para ganar algo
de espacio en disco sobre las máquinas locales. Llegando al extremo podrı́amos tener ordenadores sin disco
duro trabajando directamente sobre particiones NFS.
Las herramientas del cliente: showmount
Estrictamente hablando solo es necesario el programa mount para hacer funcionar un cliente de NFS.
Pero las utilidades de cliente son a menudo muy útiles. Showmount en este caso, nos permite ver la lista
de particiones NFS montadas por otras máquinas dentro de la red.
9.4.2. Montaje automático de particiones NFS

Utilizaremos a este proposito el /etc/fstab como para cualquier otro sistema de archivos.
maquina:partition_distante punto_montaje nfs defaults 0 0

maquina:partition_distante punto_montaje nfs noauto,user 0 0
La primera opción permite montar la partición automáticamente en el arranque. La segunda opción

permite que cualquier usuario monte la partición con mount, pero no en el arranque.
9.4.3. Propiedades de las particiones montadas

Los derechos de propiedad (permisos de acceso)
Cuando navegamos por una partición montada, podemos constatar una serie de cosas. Lo primero es
que los propietarios de los archivos sobre el servidor y sobre la máquina local no concuerdan. Es que Linux
no usa los nombres de usuario y grupos sino que utiliza los códigos de usuario y de grupo (UID, GID). Las
equivalencias aparecen en /etc/passwd y /etc/groups respectivamente, estos archivos no son compartidos
por NFS.
Ahora imaginemos lo siguiente: el usuario Paco dispone de una cuenta en el servidor donde tiene
asignado el UID 542 y allı́ tiene algunos archivos de su posesión. Su partición de trabajo es importada
sobre otra máquina donde el UID 542 corresponde al usuario Pepe. Esto es un problema porque ahora
Pepe puede acceder a los documentos de Paco, pero Paco no puede acceder ni a sus propios documentos.
Se trata de uno de los inconvenientes ligado a NFS.
Varias soluciones son posibles, siendo la más evidente el uso de servidores NIS para tener un control
de usuarios uniforme.
Los accesos concurrentes
Las diferentes versiones del protocolo NFS dejan en manos del implementador la solución de los pro-
blemas derivados de la concurrencia. Uno de los problemas más habituales en una red lenta o subestimada
es que las particiones pueden ser desmontadas de forma “violenta” cuando los tiempos de respuestas son
excesivamente lentos. Esto implica problemas de perdida de datos.

9.4.4. Servidor de NFS

Existen dos servidores NFS en Linux, uno funciona como un servidor tradicional y el otro integrado en
el kernel. Este último es frecuentemente llamado knfsd, y ofrece mejores resultados en términos de rapidez
pero le falta estabilidad.
Para realizar la instalación haremos un apt:

#apt-get install nfs-kernel-server nfs-user-server
El archivo /etc/exports
Contiene la lista de las máquinas y de los repertorios que deben ser exportados. Su sintaxis es:
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
/directorio maquina1(option) maquina2(option) ...

/usr pepe(ro) 192.168.0.10(rw)
La mayorı́a de implementaciones de NFS no autorizan la exportación de un subdirectorio de un di-

rectorio previamente exportado. El servidor de NFS del kernel si que permite esta opción y esto puede
favorecer ciertas configuraciones.
Entre las opciones más corrientes, podemos citar las opciones de seguridad que veremos más adelante
y las opciones de montaje tales como rw o ro que permiten la exportación en modo lectura/escritura o
solo lectura respectivamente.
Por defecto los directorios son exportados en modo rw (lectura/escritura).
Los nombres de las máquinas pueden ser nombres DNS, direcciones IP, clases de direcciones IP o do-
minios enteros. Si estamos utilizando NIS podemos también precisar el nombre del grupo de NIS.
Modificar dinámicamente las particiones exportadas no es posible, el servidor NFS no actualiza los
cambios realizados en el archivo /etc/exports.
Estos cambios hay que activarlos usando el comando exportfs:

#exportfs -r, . . . vuelve a cargar la configuración de /etc/exports
Este comando permite sincronizar la lista de montajes posibles, conservada en /var/lib/nfs/xtab y

basada en el archivo /etc/exports.
Para anular la exportación de directorios (prohibición de montaje):

#exportfs -u <directorio>
Este comando nos permite interrumpir momentáneamente la exportación de uno o varios directorios.
Este comando no modifica el contenido de /etc/exports y la modificación no es definitiva. Permite prohibir
todo nivel de montaje, pero los montajes existentes no son desactivados.
Restricción de los permisos de los clientes

Cuando el administrador de una máquina monta una partición NFS, dispone de permisos de acceso de
escritura, como sobre cualquier otra partición del disco local. Si la red es administrada por varios usuarios
root, en máquinas distintas se sugiere el uso de la opción: root squash en el archivo de /etc/exports.
Esta opción elimina los privilegios de root sobre la partición montada, lo que asegura la integridad
de la misma. En el marco de una exportación de /home impedirı́a que el usuario root de una máquina
cualquiera accediera a los directorios personales de todos los miembros de la red NFS.
Se puede usar también la opción all squash que otorga a todos los usuarios los privilegios de “nobody”
(usuario anónimo).

El problema del UID

El problema de propiedad de los archivos es particularmente sensible cuando tratamos con particiones
de usuarios. Es posible esquivar el problema usando la opción all squash en el montaje.
En primer lugar no montamos directamente /home en el conjunto de máquinas cliente, sino que el
servidor debe exportarlas una a una sobre cada cliente. Hecho esto, usamos la opción all squash para que
todas las modificaciones remotas sean consideradas como realizadas por el usuario nobody.
Las opciones anonuid=UID y anongid=GID nos permiten reemplazar nobody por el UID y el GID del
usuario en cuestión, para que tenga acceso a su directorio personal. Allı́ podrá usar los archivos de los que
él es dueño sin ningún problema.
La autenticación por máquina funciona relativamente bien si los recursos personales son montados desde
clientes Windows donde solo hay un usuario. Esto, sin embargo, es problemático en entornos multiusuario
(como los entornos NT).
Las herramientas del servidor : mountd y nfsd

Si estamos usando el NFS incluido en el kernel, el trabajo lo lleva a cabo directamente el modulo nfsd.o
de Linux. El programa rpc.nfsd solo sirve para comunicar el portmapper con el kernel.
El programa rpc.mountd es el programa responsable de la seguridad de los montajes con NFS. Cuando
una máquina cliente solicita la exportación de una partición, mountd verifica si dicha máquina cliente
está autorizada.
9.4.5. Configuración gráfica de NFS, interfaz Webmin

Para facilitarnos la tarea de la configuración de archivos, en Debian, disponemos de la herramienta web:
Webmin. Esta herramienta nos permitirá una configuración y administración de forma simple y sencilla.
Para instalar el módulo NFS de Webmin realizaremos un apt:

#apt-get install webmin-exports
Figura 9.11: Módulo Webmin para NFS

9.5. Samba: Servicio de conexiones para sistemas Microsoft

En esta sección configuraremos el servidor Samba, mostrando sus funcionalidades más habituales.
Basado en los articulos sobre Samba publicados en http://bulma.net
9.5.1. Compartición de recursos

El servicio de FTP permite intercambiar archivos en red. Pero presenta serios problemas de integración.
Es decir no es transparente al usuario, su uso cambia según trabajemos con los entornos Linux o Windows.
NFS, solución limitada a máquinas Linux

Entre máquinas Linux, es posible usar el protocolo NFS para compartir archivos. Se trata de una buena
solución puesto que permite conservar todas las funcionalidades del sistema de archivos Linux. Pero tiene
una serie de inconvenientes:
NFS presenta problemas de seguridad
No existe una buena implementación libre de NFS para equipos Windows
Protocolo CIFS, una posible solución

En lugar de usar una solución costosa, en los equipos Windows, es más económico (y lleva menos
trabajo) utilizar el protocolo empleado nativamente por las máquinas Windows. El protocolo CIFS (Com-
mon Internet FileSystem), tiene implementaciones sobre un gran número de plataformas. Existiendo una
implementación libre, llamada SaMBa, que permite utilizarlo sobre servidores Unix/Linux.
9.5.2. ¿Qué es Samba?

Samba es una implementación bajo Unix/Linux de los protocolos CIFS y NetBIOS (antiguamente
llamado SMB, de allı́ el nombre de Samba)
Este protocolo permite compartir varios recursos diferentes:
El acceso a los directorios compartidos.
El acceso a las impresoras compartidas.
El paquete Samba incluye utilidades para controlar el acceso de los archivos con la misma soltura que
un WindowsNT. Además Samba puede colaborar con un servidor NT existente, o reemplazarlo del todo.
Veremos más adelante como configurarlo en detalle, pero es posible:
Proteger con una contraseña el acceso a un directorio compartido.
Proteger con una contraseña personificada para cada usuario, y dotar de permisos de acceso indivi-
dualizados.
Las herramientas necesarias

Los paquetes relacionados con Samba son los siguientes:
samba-common: Contiene los elementos que van a permitir el buen funcionamiento de los otros
paquetes:
• Herramientas de conversión de tablas de caracteres Windows.

• Archivos de configuración.
• Documentación básica de Samba.

samba: Contiene todos los programas del servidor, es decir:
• Aplicaciones que permiten hacer accesible los recursos a los usuarios.

• Herramientas de configuración.
• Documentación esencial de Samba.
smbclient: Contiene los programas clientes, que permiten acceder a los recursos compartidos.
smbfs: Configura el sistema de archivos Samba.
samba-doc: Contiene toda la documentación necesaria para configurar en detalle todos las funciones
del servidor Samba.
swat: Es una aplicación web que permite configurar el servidor Samba fácilmente. Pero para ello nos
hará falta: Apache y varios paquetes de dependencias.
Estos paquetes se pueden instalar fácilmente con apt:

#apt-get install samba samba-doc smbclient smbfs swat
Los demonios de Samba
Dos demonios se encargan de ofrecer los servicios del conjunto de aplicaciones Samba.
El demonio smbd es el demonio que se encarga de la compartición de recursos, pero también del
control del acceso a los mismos. Gestiona los permisos de los diferentes clientes una vez que estos
han sido identificados.
El demonio nmbd se ocupa de publicitar los servicios. Es decir, se encarga de informar a las máqui-
nas presentes en la red sobre cuales son los recursos disponibles. Este demonio maneja también la
resolución de nombres de NetBIOS. Para ello, puede comunicarse con un servidor WINS (Windows
Internet Naming Service) que se encuentre presente en la red.
Existen dos formas para realizar la configuración:
Editar directamente los archivos de configuración con un editor de texto.
Manejar una herramienta gráfica que generará el mismo resultado. Aquı́ veremos, el manejo de
Swat (Samba Web Administratión Tool), que se trata de una interfaz que se comporta como un
servidor Web, conectándose a la máquina por medio de un simple navegador. Es posible leer la
documentación, cambiar la configuración y realizar el resto de tareas administrativas después de
habernos validado con un usuario y una contraseña. El servidor Swat, por defecto, se ejecuta en el
puerto http://localhost:901.
Herramientas del cliente
Las herramientas para el cliente bajo Microsoft Windows son aquellas utilizadas habitualmente para
trabajar con servidores NT. No hay que cambiar nada en este sentido, el funcionamiento para las máquinas
Windows es totalmente transparente.
En Linux, contamos con el paquete smbclient para conectarse con los servicios CIFS, sean proporcio-
nados por un servidor Windows o por un servidor Linux que ejecute Samba.

9.5.3. Configuración gráfica de Samba, interfaz SWAT

La herramienta SWAT es el ejemplo de una buena interfaz de administración gráfica. Intenta de forma
relativamente transparente proporcionar todas las funcionalidades de la configuración en modo texto.
Como la configuración de Samba es sencilla, ha sido posible agrupar todas las posibilidades en un
número reducido de opciones, sin sobrecargar la interfaz.
Ofrece la posibilidad de generar un archivo /etc/samba/smb.conf de muestra, con el que podremos
estudiar la sintaxis del script por si tuviéramos que editarlo a mano en alguna ocasión.
Si no lo realiza la instalación en el sistema, para poder ejecutar SWAT hay que modificar el archivo
/etc/inetd.conf. Y añadir la siguiente lı́nea:
swat stream tcp nowait.400 root /usr/sbin/swat swat
Figura 9.12: Interfaz gráfica Swat para Samba
Presentación de los archivos en modo texto

/etc/smbpasswd : Contiene los passwords de los usuarios de Samba, de forma cifrada.
/etc/lmhosts: Es un interfaz entre los nombres de máquinas NetBIOS y las direcciones IP numéricas.
Su formato es parecido al de /etc/hosts.
/etc/smbusers: Contiene una lista de usuarios del sistema, seguida de una lista de los usuarios Samba
que les corresponden.
De esta forma es posible crear varios usuarios Samba sin tener que crear para cada uno de ellos un
usuario del sistema.

Los menús de SWAT

Paso a detallar cada una de las secciones del archivo /etc/samba/smb.conf. Este archivo es parecido a
los archivos .ini, habituales del entorno Windows.
HOME : Permite acceder a la versión html de la documentación Samba. Faltan tal vez algunas
opciones, en particular la ayuda sobre el propio SWAT deja bastante que desear. Se trata a menudo de
una ayuda relativa a las opciones de los archivos en modo texto, más configurables que la herramienta
gráfica. De un modo u otro toda esta documentación es en el fondo muy descriptiva.
GLOBALS : Contiene variables generales que se aplican al total de los recursos puestos a disposición
del servidor Samba. Esta sección contiene también información de identificación del servidor dentro
de la red NetBIOS : grupo de trabajo, nombre e identificador. Ası́ mismo, aquı́ podemos establecer
los modos de funcionamiento de Samba.
SHARES : Contiene la lista de comparticiones de disco efectuadas por la máquina. Es aconsejable

primero crear la partición compartida (o los directorios) y después precisar para cada partición sus
propiedades particulares.
PRINTERS : Es casi idéntico al anterior, pero permite compartir impresoras en lugar de particiones
de disco o directorios.
WIZARD: Permite configurar de una forma rápida los archivos de configuración, establecer el modo
de funcionamiento del servidor y el servidor WINS de la red. Desdeaquı́, también podemos cambiar
la configuración para compartir los directorios /home por Samba.
STATUS : Muestra el estado actual del servidor, el estado de los demonios Samba, las conexiones
activas, los archivos compartidos y los archivos abiertos actualmente.
VIEW : Nos permite ver el archivo smb.conf tal cual ha sido redactado por SWAT. Es posible ver
también la totalidad de las opciones posibles, incluso las que SWAT no ha cambiado, pero que tienen
un valor por defecto.
PASSWORD: Permite al usuario cambiar su contraseña. Se trata de un interfaz grafico para el

programa smbpasswd. Sirve también al administrador para añadir nuevos usuarios.
9.5.4. Funcionamiento de CIFS

Sobre una misma red, varias máquinas pueden poner recursos a disposición de otras. CIFS dispone de
un sistema para anunciar servicios (browsing), que permite saber que recursos compartidos hay disponibles.
Cada máquina que desea anunciar sus recursos compartidos a las otras máquinas contacta con una
máquina en particular, el Servidor de Anuncios (Master Browser) que se encarga de centralizar estas
notificaciones de presencia. Es posible configurar el servidor Samba para que sea el mismo Servidor de
Anuncios o dejar esta tarea a una máquina Windows.
El acceso a los recursos puede controlarse de dos formas:

Escondiendo el recurso, es decir, no anunciándolo a ciertas máquinas de la red.
Estableciendo un sistema de validación para restringir el acceso, basado en contraseña.

El anuncio de servicios esta limitado al “grupo de trabajo”. Cada máquina Windows puede ser miembro
de un solo grupo, y por tanto, solo puede pertener a un conjunto de máquinas que compartan los mismos
recursos. Es posible de este modo separar conjuntos de recursos compartidos, creando distintos grupos
de trabajo. Si lo que deseamos es tener máquinas accediendo a los recursos de varios grupos distintos, es
necesario pasar por un sistema de autenticación.

Existen varias formas de autenticación, cada una con sus ventajas e inconvenientes:
La autenticación por usuario y contraseña: Se trata del método por defecto. Representa la ventaja
de permitir una gestión fina de los permisos. Para cada usuario es posible definir el acceso o no a
unos recursos. Este método presenta un inconveniente: cada usuario debe disponer de una cuenta en
la máquina Unix, para permitir la autenticación.
El control de acceso por comparticiones: Se trata de un método más global: cada recurso compartido
es protegido por un password propio. Para ello es necesario que varios usuarios conozcan el mismo
password y que recuerden la contraseña adecuada para cada recurso compartido al que accedan.
Este método presenta la ventaja de que no son necesarias tantas cuentas de usuario como usuarios
haya, sino tantas como recursos se compartan.
Autenticación contra otro servidor : Existen también dos métodos indirectos de control de acceso.
• El método server : Consiste en consultar con otro servidor CIFS, que se encargara de la auten-
ticación.
• El método domain: Consiste en validarse contra el servidor de dominio NT.
9.5.5. Parámetros globales

Es necesario elegir algunos parámetros de funcionamiento del servidor y para identificarlo y conseguir
que se integre en la red.
El campo server string: Permite elegir la descripción que acompaña al nombre del servidor en la
lista de recursos anunciados.
El campo netbios name: Permite definir el nombre de la máquina, no como un nombre de DNS, sino
como un nombre de resolución de nombres propio del protocolo NetBIOS. Es importante entender
que son dos cosas totalmente diferentes.
El campo workgroup: Permite elegir el grupo de trabajo del servidor Samba.
El campo interfaces: Permite identificar la o las tarjetas de red que enlazan el servidor con el grupo
de trabajo.
También disponemos de una serie de parámetros referidos al control de acceso:
El campo security: Permite elegir el método de autenticación, podemos elegir uno de los vistos
anteriormente.
Los menús hosts allow y host deny permiten controlar el acceso a los recursos de ciertas máquinas.
Las configuraciones hechas en esta sección se aplican a la totalidad de los recursos compartidos,
independientemente de la configuración especifica.
Las configuraciones realizadas por Swat se reflejan en el archivo de configuración /etc/smb.conf. Si

editamos dicho archivo podremos ver algo de este estilo:
[global]
workgroup = nombre_del_grupo
server string = Servidor Samba
security = SHARE
log file = /var/log/samba/log.%m
max log size = 50

9.5.6. Impresoras
Samba permite compartir fácilmente una impresora conectada fı́sicamente a una máquina Linux, ha-
ciendo asi accesible a todas las máquinas conectadas a la red.
Una impresora de red que no soporte mecanismos de autenticación puede ser puesta a disposición de
los usuarios gracias a un servidor de impresión de Samba, lo que permite controlar el acceso.
Esta operación de elegir impresora, se realiza dentro del menu PRINTERS. Este presenta una lista
de impresoras existentes. Seleccionando una en la lista desplegable y usando el comando Choose Printer
(elegir impresora) accederemos a su configuración.
Por defecto Samba extrae la lista de impresoras disponibles de /etc/printcap. Si la máquina dispone de
otras impresoras, es posible añadirlas, introduciendo su nombre en el campo Create Printer y confirmando
la acción.
El camino de acceso (PATH), en una impresora se trata de del camino hacia el directorio utilizado por
Samba para conservar la cola de impresión. En general se adopta /var/spool/samba.
Autorizar el acceso guest, es permitir a cualquier usuario de una máquina miembro del grupo de
trabajo, usar la impresora.
Hay que tener mucho cuidado con esto, la integración en un grupo de trabajo no es un método fiable de
validación. Cualquier usuario de una máquina Windows puede cambiar su grupo de trabajo tantas veces
como desee sin que ningún mecanismo de autenticación se lo impida. De este modo podrı́a introducirse
en un grupo con permisos de impresión un usuario al que en principio habı́amos dejado fuera. Puede ser
necesario usar restricciones por nombre de máquina (archivos host allow y host deny) para una mayor
seguridad.
El menú browseable indica que este recurso debe ser anunciado por nmbd, y por tanto ser visible para
todos los usuarios.
9.5.7. Compartición de directorios

Algunas opciones son idénticas a la compartición de impresoras. Las opciones que permiten limitar el
acceso a ciertas máquinas, elegir el camino de acceso al recurso (en este caso, directorio a compartir), y la
autorización de un usuario invitado son identicas a las que hemos encontrado en la sección PRINTERS.
En el caso de la compartición de espacio en disco es posible tener un mejor control sobre el acceso.
Activando la opción read only, autorizar solamente el acceso en modo lectura o definir sobre un mismo
directorio varios tipos de permisos. Por ejemplo, se podrı́a ofrecer acceso de solo lectura a la totalidad del
grupo y luego afinar un acceso de escritura a ciertos usuarios en concreto.
Si la seguridad esta en modo compartido (share), todos los usuarios disponen, previa autenticación, de
los derechos correspondientes al directorio que es compartido. El sistema usa un método heuristico para
determinar el identificador de un usuario que se conecta, pero este método es facilmente manipulable.
Ası́ que más vale usar la autenticación en modo usuario. Este modo permite por ejemplo, compartir las
carpetas personales del usuario sin riesgo alguno.
Por defecto, Samba no utiliza contraseñas cifradas. Esta elección le permite interoperar con clientes
de Windows 3.x y Windows95. Por culpa de esta compatibilidad perdemos seguridad y es necesario tocar
el registro del sistema de Windows en máquinas Win98 y posteriores para que todo funcione. Si en la red
no hay máquinas windows95 o anteriores, es muy recomendable configurar el servidor de Samba para que
use contraseñas cifradas.
Esto se hace, añadiendo al archivo smb.conf la siguiente lı́nea:

encrypt passwords = Yes, . . . dentro de [global]
Estas contraseñas son almacenadas dentro del archivo /etc/smbpasswd. Las máquinas clientes contactan
con el servidor y reciben una clave codificada usando la contraseña cifrada. El resultado es reenviado al
servidor, que hace la misma operación. Si los dos resultados son idénticos la autenticación es correcta.
Esto impide a un usuario “malicioso” hacerse con los passwords que atraviesan la red camino al servidor
en busca de la autenticación.

9.5.8. Limitar acceso de los usuarios

Para cada recurso es posible restringir el acceso a ciertos usuarios. Esto se realiza en en /etc/smb.conf,
para cada una de las lı́neas de recursos compartidos que deseamos limitar, podemos añadir la lı́nea:
valid users = usuario1, usuario2
En ausencia de valid, el recurso es accesible por todos los usuarios del servidor Samba. Si esta lı́nea
esta presente el acceso esta reservado únicamente a los usuarios mencionados.
La opción read only, permite impedir a los usuarios que escriban en el directorio compartido. Pudiendo
también limitar el acceso a unos usuarios concretos.
Para ello tenemos dos posibilidades:

Autorizar el acceso de escritura y bloquear ciertos usuarios con derecho de solo lectura, colocando
su nombre en la sección read list= del recurso compartido.
Autorizar el acceso en solo lectura y dar el privilegio de escritura a ciertos usuarios gracias a la
sección write list= del recurso compartido.
9.5.9. Integración de Samba en un dominio NT

Los dominios NT son variantes de los grupos de trabajo. Igual que los grupos, permiten anunciar
los recursos a diferentes clientes. La principal diferencia se encuentra a nivel de autenticación. Todos los
miembros de un dominio utilizan la misma base de datos de usuarios y contraseñas.
Cuando un cliente miembro de un dominio intenta acceder a un recurso, envı́a una petición a todas las
máquinas de la red, y se autentica contra la primera que responde. En una red NT, la tarea de responder
se lleva a cabo la máquina “mas activa” que tenga acceso a la base de datos de usuarios. Se trata del
Primary Domain Controller (PCD), el controlador del dominio principal. En su ausencia, los servidores
secundarios o BCDs pueden tomar el relevo.
Una vez la máquina cliente se ha autenticado con un controlador del dominio, el cliente no tiene porque
volver a validarse dentro del dominio aunque decida acceder a otro recurso compartido diferente del inicial.
El controlador del dominio “memoriza” las autenticaciones satisfactorias.
Es posible configurar un servidor Samba para que se integre dentro de un dominio NT, para ello hay
que seguir el siguiente método:
Lo primero consiste en declarar Samba como un miembro del grupo de trabajo del servidor NT.
Seleccionando en el Swat Security=SERVER, le estamos pidiendo al servidor de Samba que contacte
con un servidor NT.
El servidor NT, se encuentra indicado en la sección password server = nombre del servidor ) para la
autenticación. Evidentemente el servidor NT debe estar configurado para responder a las peticiones
de autenticación del servidor de Samba.
Después hay que crear una cuenta para el servidor:

#smbpasswd -j nombre_del_dominio
Por último, hay que asegurarse de que cada usuario, que el servidor NT va a autenticar, tiene una
cuenta en la máquina NT consiguiendo con esto que los permisos funcionen.

9.5.10. Configuración de Samba como controlador de dominio

Samba es capaz de comportarse como un PDC (Controlador de Dominio Primario).
Para configurarlo, hay que realizar varias etapas:

1. Autorizar las peticiones de autenticación de otras máquinas.
2. Configurar la autenticación usuario por usuario.
3. Declararse Master Browser, es decir invertir el mecanismo de elección habitual en las máquinas NT
para llevarlas a nuestra máquina Samba.
En el archivo /etc/samba/smb.conf, la sección [GLOBAL] debe contener los siguientes elementos:
domain logons = yes

security = user
os level = 34
local master = yes
preferred master = yes
domain master = yes
Si queremos compartir permitiendo la autenticación de usuarios, creamos una compartición ficticia,

siguiendo este patron:
[netlogon]
path = /export/samba/logon
public = no
writeable = no
browsable = no
Esta compartición no ofrece el acceso a ningún recurso, sin embargo permite la autenticación de las
diferentes máquinas.
Autorizar la conexión de las máquinas NT

Las máquinas NT intentan conectarse directamente al servidor y no a un recurso en concreto. Es por
tanto preciso autorizarlas para ello. Necesitamos que las máquinas (y no los usuarios) dispongan de una
cuenta, como no van a conectarse al shell, no es necesario darles un usuario normal, con su directorio.
El identificador de una máquina es su nombre NetBIOS, seguido del carácter $.

Ası́ por ejemplo la máquina iceberg, tendrá como identificador iceberg$. Hecho lo cual hay que añadir
esta cuenta de usuario a la base de datos de los usuarios de Samba, con el comando:
#smbpasswd -a -m maquina
9.5.11. Cliente Samba

Acceder a los recursos compartidos: smbclient
Este comando permite acceder, desde un cliente Linux, a los recursos disponibles a través de servidores
CIFS, bien se trate de un servidor Samba o de un servidor basado en Windows. La interfaz es parecida a
la del ftp, es de este modo posible transferir archivos sin esfuerzo.
La sintaxis es: #smbclient //maquina/recurso

El recurso puede ser:

Un directorio.
Una impresora.
Un disco compartido.
El nombre de la máquina es su nombre de NetBIOS, que puede (y suele) ser diferente de su nombre
de DNS. La opción -R permite elegir el modo de resolución del nombre de la máquina:
-R lmhosts: Permite consultar el archivo /etc/lmhosts, que resuelve nombres de IP contra los nombres
de NetBIOS de la máquina.
-R wins: Permite lanzar la consulta a un servidor WINS para obtener dicha conversión.
Una vez conectado al servicio en cuestión, disponemos de una interfaz de transferencia de archivos
idéntica a la del FTP. También podemos acceder a algunas opciones extra, tales como print archivo, para
imprimir un archivo local en el servidor.
Integrar un recursos compartido en nuestros directorios: smbmount y smbumount

El comando smbmount nos permitirá movernos de una manera más cómoda por los recursos com-
partidos mediante CIFS, se comporta de una forma similar a los montajes mediante NFS. El recurso
compartido CIFS se monta en un punto de nuestra jerarquı́a de directorios y podemos movernos por el
usando los comandos Unix habituales.
Smbclient se encarga de gestionar las interacciones entre los archivos presentes en el servidor. Para
desmontar un recurso compartido usamos el comando smbumount.
Guardar datos de un recurso compartido: smbtar

El comando smbtar es muy similar al comando tar. Permite realizar copias de seguridad de los archivos
del servidor desde la máquina cliente Samba.
La sintaxis es la siguiente:
#smbtar -s servidor -x recurso -t lugar_de_almacenamiento
Es necesario disponer de permisos de lectura del directorio que deseamos almacenar. Es también posible
crear copias incrementales con la opción -N fecha, que no almacena nada más que los archivos que han
sido modificados a partir de la fecha especificada.
9.5.12. Configuración gráfica de Samba, interfaz Webmin

Para facilitarnos la tarea de la configuración de archivos en Debian, también disponemos de otra he-
rramienta web, esta vez para el entorno Webmin. Esta herramienta nos permitirá una configuración y
administración de forma simple y sencilla.
Para instalar el módulo Samba de Webmin realizaremos un apt:

#apt-get install webmin-samba
En la figura 9.13 se puede observar una serie de pantallas de la interfaz.

Figura 9.13: Módulo Webmin para Samba

9.6. ProFTPD: Servidor FTP

El protocolo de transferencia de archivos (FTP, File Transfer Protocol) es empleado en redes IP, como
es el caso de Internet, para la transmisión de archivos. Uno de los mejores servidores FTP que podemos
encontrar en Linux es ProFTPD. Este servidor soporta la creación de hosts virtuales permitiéndonos dis-
poner, de esta forma, de “más de un servidor FTP” en una sola máquina. Se diseño como un servidor
FTP especialmente orientado a sistemas de tipo Unix, tomando muchas de las ideas y conceptos propios
de Apache, como la modularidad.
Para instalarlo desde nuestro sistema Debian realizaremos un apt:

#apt-get install proftpd
La instalación da la opción de colocarlo en el inetd o utilizarlo como un servicio independiente.
Una vez instalado en el servidor necesitaremos editar el archivo /etc/inetd.conf o /etc/xinted.conf.
Si utilizamos inetd.conf editamos el archivo y añadimos # (comentario) al principio de la lı́nea:

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
y, a cambio, agregamos la siguiente:

ftp stream tcp nowait root /usr/sbin/proftpd proftpd
Ahora que ya hemos instalado el servidor tendremos que modificar los archivos de configuración.
9.6.1. Servidor ProFTP

La configuración se encuentra almacenada en el archivo: /etc/proftpd.conf.
Será necesario editar este archivo y al menos, realizar los siguente cambios:
1. En ServerName, colocamos el nombre de nuestro servidor.
2. En ServerType, colocamos el tipo de servidor (standalone o inetd ) en función de lo que hayamos

especificado al instalar.
3. Colocamos, después de ServerType, la lı́nea ServerIdent off. De esta forma el servidor no mostrará su
versión cuando se establece una conexión.
4. Especificamos el User y el Group, si colocamos nobody nadie podrá acceder al servidor. Si queremos
colocar un usuario anónimo, se suele utilizar: user:ftp y group:nogruop.
5. Cambiamos MaxClients por el número máximo de conexiones simultaneas que deseamos permitir.
Este valor lo tendremos que determinar en función del número de usuarios del servidor, el ancho de
banda disponible y los recursos de la máquina.
Podemos especificar múltiples opciones más, que se detallan en el archivo mediante comentarios, o
podemos instalar el paquete de documentación y consultarlo allı́:
#apt-get install proftpd-doc
El archivo de configuración /etc/ftpusers contendrá los nombres de los usuarios, a los que se les per-
mitirá el uso del servicio FTP.

9.6.2. Configuración gráfica de ProFTP, interfaz Webmin

Estas misma tareas administrativas se pueden realizar cómodamente con la herramienta web: Webmin.
Para instalar el módulo de ProFTPD para webmin:

#apt-get install webmin-proftpd
Figura 9.14: Módulo Webmin para ProFTPD
Desde la ventana de ProFTP accederemos a las opciones de configuración global del servidor y de los
diferentes servidores virtuales que tengamos definidos.
Algunos de los parámetros más importantes a ajustar son el control de acceso y la autenticación.
Cuando configuramos un servidor virtual podemos volver a ajustar algunos de los parámetros establecidos
en las opciones globales, como por ejemplo las opciones de autenticación de los usuarios y grupos en el
caso de que tengamos que establecer una configuración de seguridad diferente en cada servidor virtual.
Desde las opciones de configuración del servidor virtual también podremos establecer el directorio
utilizado para guardar los archivos a disposición de los usuarios que se conecten a nuestro servidor de
forma anónima.
9.6.3. Clientes FTP

En Internet es posible encontrar diversas aplicaciones que nos permiten trabajar con servidores FTP
de una forma fácil y rápida.
Desde nuestro entorno Debian se ponen a nuestra disposición: gFTP (GNU FTP ).
Para instalarlo:
#apt-get install gftp, . . . para ejecutarlo: #gftp
Es un cliente FTP, muy intuitivo y con entorno gráfico.

Capı́tulo 10
Servicios de usuario
10.1. Cuotas de usuario

Las cuotas permiten especificar lı́mites en dos aspectos del almacenamiento en disco:
El numero de inodos que puede poseer un usuario o un grupo
El numero de bloques de disco que puede ocupar un usuario o un grupo.
La idea que se esconde detrás de las cuotas es que se obliga a los usuarios a mantenerse debajo de su
limite de consumo de disco, quitándoles su habilidad de consumir espacio ilimitado en un sistema.
Las cuotas se manejan en base al usuario o grupo y al sistema de archivos. Si el usuario espera crear
archivos en más de un sistema de archivos, las cuotas deben activarse en cada sistema de archivos por
separado.
Primero deberemos de asegurarnos que la opción quota está activada dentro de nuestro kernel (opción
CONFIG QUOTA=yes). Para habilitar las cuotas, tanto para nuestros usuarios Linux, como los usuarios
Windows (Samba) necesitaremos instalar el programa: quote, para el manejo de cuotas.
Para ello realizaremos el siguiente apt:

#apt-get install quota
10.1.1. Arrancar el sistema de cuotas

Tenemos que que cambiar nuestro /etc/fstab para indicarle que vamos a utilizar quotas, tenemos que
insertar lı́neas como las siguientes, ajustandolas al perfil de nuesto sistema:
/dev/hda6 /usr ext2 defaults,grpquota 1 1

/dev/hda10 /home ext3 defaults,usrquota 1 1
/dev/hda7 /tmp ext2 defaults,usrquota,grpquota 0 2
El parámetro grpquota, habilita las cuotas de grupo en la partición que corresponde a /usr. El paráme-
tro usrquota, habilita las cuotas de usuario en la partición que corresponde a /home. En una misma
partición pueden haber cuotas de usuario y grupo, colocando los dos parámetros (en el ejemplo /tmp).
Ahora debemos de crear los siguientes archivos, para manejar las cuotas de la partición /home:
#touch /home/quota.group
#touch /home/quota.user
Ambos archivos de registro, deben pertenecer a root y sólo el tendrá permisos de lectura y escritura:
#chmod 600 /home/quota.user

#chmod 600 /home/quota.group
Los comandos que se muestran a continuación nos permiten interactuar con el servicio de cuotas:
#repquota -a Produce un resumen de la información de cuota de un sistema de archivos.
#quotacheck -avug Para realizar el mantenimiento de las cuotas. Se utiliza para explorar el
uso de disco en un sistema de archivos, y actualizar los archivos de registro
de cuotas quota.user y quota.gruop, al estado mas reciente. Se recomienda
ejecutar quotacheck periódicamente al arrancar el sistema o mediante el
anacron cada cierto tiempo (por ejemplo cada semana).
#edquota -g <cuota> Edita la cuota de el grupo.
#quotaon -vaug Activa las cuotas.
#quotaoff -vaug Desactiva las cuotas.
Para arrancar el sistema de cuotas deberemos de colocar el servicio en uno de los archivos rc#.d
(runlevels, para más información véase el apéndice D). Es preciso arrancar las cuotas siempre después de
que los sistemas de archivos incluidos en /etc/fstab hallan sido montados, en caso contrario las cuotas no
funcionarán.
Para obtener más información podemos consultar el manual:

$man quota
$man -k quota
10.1.2. Asignar cuotas a los usuarios

Esta operación se realiza con el comando edquota. Es recomendable ejecutar quotacheck -avug para
obtener el uso de los sistemas de archivos lo más actualizado posible antes de editar cuotas.
Si ejecutamos el siguiente comando:

#edquota -u <user>
Se editarán todos los dispositivos que permitan tener cuotas de usuario, especificado en /etc/fstab.
Permitiendo modificar las cuotas del user.
Los mismo ocurre en los grupos, si ejecutamos el comando:

#edquota -g <grupo>
Se editarán todos los dispositivos que permitan tener cuotas de grupo, especificado en /etc/fstab.
Permitiendo modificar las cuotas del grupo.
10.1.3. Configuración gráfica de Quote, interfaz Webmin

Para facilitarnos la tarea de administración de cuotas, podemos utilizar el módulo Webmin para cuotas.
Para instalarlo, realizaremos un sencillo apt:

#apt-get install webmin-quota
Desde allı́ podremos realizar, de forma gráfica, los mismos pasos que desde la lı́nea de comandos.

Capı́tulo 10. Servicios de usuario 135
Figura 10.1: Gestión de cuotas de disco, en este caso /tmp

10.2. Cups: Servidor de impresión

Como servidor de impresión utilizaré Cups frente a LPD, este último es un sistema bastante engorroso
en algunas configuraciones.
Como ventajas de Cups respecto a LPD, podemos citar las siguientes:

Es más sencillo hacer funcionar impresoras extrañas, es decir que están poco difundidas.
Cada usuario puede tener su propia configuración y no es necesario instalar varias impresoras cuando
cambiamos los parámetros de una impresora (econofast, presentaciones, color, 600x600, . . . ).
Usa SLP e IPP para descubrimiento/publicación del servicio e impresión, respectivamente. Esto
quiere decir que en una red debidamente configurada se puede encontrar las impresoras de todo el
mundo que las tiene compartidas, sin problemas.
Dispone de una interfaz de configuración por web.
Pero no todo son alegrı́as, también existen una serie de desventajas respecto a lpd:
LPD es bastante más sencillo de hacer funcionar, para una máquina aislada con la impresora en
local.
Si no necesitamos soporte a usuarios Microsoft igual nos estamos complicando la vida con Cups.
10.2.1. Servidor Cups

Para instalar el servidor de impresión y que se pueda compartir por Samba, necesitaremos instalar
varios paquete mediante el siguiente apt:
#apt-get install cupsys cupsomatic-ppd cupsys-driver-gimpprint samba samba-common
Debemos de asegurarnos de tener soporte en el kernel, para puerto paralelo o en mi caso para usb
(necesitaremos hotplug). Si lo tenemos activado pero en el kernel lo dejamos como módulo, lo podremos
cargar con la herramienta: #modconf, en caso contrario, no tendremos más remedio que recompilar el
kernel, con las opciones adecuadas a nuestro sistema de impresión.
Configuración del servidor

Una vez tengamos instalados los archivos en el sistema vamos a configurar el servicio Cups. Para ello
editaremos el archivo: /etc/cups/cupsd.conf
Aquı́ estableceremos el acceso a la interfaz web, que nos permitirá realizar la configuración de una
forma mucho más visual y agradable. Para conseguirlo modificaremos las siguientes opciones:
ServerName host.dominio.com
ServerAdmin admin@host.com
HostNameLookups On
<Location />
Order Deny,Allow
Deny From All
Allow From 192.168.0.*
</Location>

<Location /admin>
AuthType Basic
AuthClass System
Order Deny,Allow
Deny From All
Allow From 192.168.0.*
</Location>
En la opción de Allow From pondremos la IP, o rango de IP desde las cuales accederemos al servidor
Cups. En el ejemplo, se deniega el acceso a todo el mundo y despues se permite a las direcciónes del rango
192.168.0.*
Como se detalla en los comentarios del archivo, podemos especificar los host y los rangos de IPs, de
diversas formas:
# All
# None
# *.domain.com
# .domain.com
# host.domain.com
# nnn.*
# nnn.nnn.*
# nnn.nnn.nnn.*
# nnn.nnn.nnn.nnn
# nnn.nnn.nnn.nnn/mm
# nnn.nnn.nnn.nnn/mmm.mmm.mmm.mmm
# @LOCAL
# @IF(name)
Cuando hayamos terminado con la configuración, reiniciaremos el servidor Cups:

#/etc/init.d/cupsys restart
Configuración gráfica vı́a web

Una vez hemos configurado los accesos, probaremos a conectarnos al servicio de administración vı́a
web. Para ello, nos conectaremos al host donde se encuentre el servidor, accediendo por el puerto 631 :
http://host.dominio.com:631
http://IP:631
http://localhost:631, si nos encontramos en local.
Utilizaremos el navegador que más nos guste y el método de acceso que resulte más adecuado a nuestro
sistema. En la figura 10.2 podemos observar la pantalla de presentación.
Figura 10.2: Interfaz gráfica de configuración para Cups

Una vez situados en la web, para configurar la impresora debemos de seguir los siguientes pasos:
Seguidamente iremos al menú de Administración y nos autenticaremos como usuario root.
Ahora hacemos clic en Añadir impresora. En este menú estableceremos un nombre a la impresora y
estableceremos el tipo de conexión.
Después sólo queda elegir el fabricante y el modelo adecuados.

Una vez realizado esto tendremos la impresora configurada, desde el menú impresoras podemos impri-
mir una página de prueba y comprobar que la configuración es correcta.
Figura 10.3: Impresora HP815 configurada para usar Cups
10.2.2. Servidor Cups para Samba

Para configurar Cups rn Samba editaremos el archivo /etc/samba/smb.conf, para añadir lo siguiente:
[global]
#Nombre del servidor Samba
server string = Paquito
obey pam restrictions = Yes
#Tipo de autenticacion. En este caso la base de datos, tdbsam que viene por defecto
passdb backend = tdbsam, guest
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
printcap name = cups
dns proxy = No
panic action = /usr/share/samba/panic-action %d
printing = cups
security = share
# Habilitaremos localhost y nuestra subred

hosts allow = 192.168.0. 127.0.0.1
[HP815]
#El nombre tiene que ser el mismo en Cups y Samba
comment = HP Deskjet 815
browseable=yes
writable=no
printable=yes
create mode = 0700
Una vez realizada la configuración básica de Samba, deberı́amos añadir los usuarios Samba para que
se puedan autenticar contra el servidor. Lo realizaremos de la siguiente forma:
#smbpasswd usuario, . . . nos pedirá que le establezcamos una contraseña.
Una vez realizado esto, volveremos a la configuración Cups y realizaremos los siguientes cambios:
Editaremos el archivo /etc/cups/mime.convs y descomentaremos las lı́nea:
application/octet-stream
application/vnd.cups-raw
Editaremos el archivo /etc/cups/mime.types y descomentaremos la lı́nea:
application/octet-stream.
Ahora sólo queda reiniciar los servicios Samba y Cups. Después todo deberı́a funcionar.
/etc/init.d/samba restart
/etc/init.d/cupsys restart

10.2.3. Clientes Linux

La configuración del cliente, es muy similar a la instalación del servidor Cups.
Para ello seguiremos una serie de pasos:

Agregamos al sistema los paquetes necesarios, con un apt:
#apt-get install cupsys cupsomatic-ppd cupsys-driver-gimpprint
Si no tenemos Ghostscript en el sistema, también lo añadimos:

#apt-get install ghostscript ghostscript-fonts
Ahora iniciaremos el servicio Cups:

#/etc/init.d/cupsys restart
Y entraremos vı́a web a nuestro host cliente (http://localhost:631 ) para configurar una nueva im-
presora. La añadiremos de la misma forma que en el servidor.
La diferencia está en la conexión, en este caso asignaremos una impresora del tipo Windows Printer
vı́a Samba. Y en el Device URI, colocaremos:
smb://<usuario:password>@<host.dominio.com>/<impresora>
Una vez finalizada podemos imprimir una página de prueba, para ver si todo está configurado correc-
tamente.
10.2.4. Clientes Microsoft

Vamos a realizar la instalación, mediante los siguientes pasos:
Accedemos a Inicio -> Configuración -> Panel de Control.
Seleccionamos Impresoras y faxes -> Agregar nueva impresora.

En el asistente, especificamos la impresora como local y seleccionamos Crear un nuevo puerto ->
Local Port
Establecemos como nombre de puerto: \\host.dominio.com\<nombre_impresora>

Por último, seleccionamos el modelo de impresora que vamos a agregar (en mi caso, HP 815).
Una vez hecho esto la impresora deberı́a estar configurada y lista para imprimir.
10.2.5. Solucionar problemas

Si lo hemos configurado bien, pero no tenemos ni idea de porque no funciona podemos consultar los
logs de Cups (/var/log/cups/error log) y buscar allı́ el problema.
Si queremos aumentar el nivel de debug de los logs, tendremos que cambiar la opción “LogLevel” del
archivo /etc/cups/cupsd.conf, a nivel debug, de esta forma podremos encontrar el fallo.
Otra cosa primordial es consultar la documentación Cups, a lo mejor nos encontramos con que el
módelo concreto de impresora que tenemos no está soportado.

10.3. Servidor Web

Un servidor web1 es un programa que implementa el protocolo HTTP (hypertext transfer protocol).
Este protocolo está diseñado para transferir lo que llamamos hipertextos, páginas web o páginas HTML
(hypertext markup language): textos complejos con enlaces, figuras, formularios, botones y objetos incrus-
tados como animaciones o reproductores de sonidos.
Sin embargo, el hecho de que HTTP y HTML estén ı́ntimamente ligados no debe dar lugar a confundir
ambos términos. HTML es un formato de archivo y HTTP es un protocolo.
Un servidor web se encarga de mantenerse a la espera de peticiones HTTP llevada a cabo por un
cliente HTTP que solemos conocer como navegador. El navegador realiza una petición al servidor y éste le
responde con el contenido que el cliente solicita. El cliente es el encargado de interpretar el código HTML,
es decir, de mostrar las fuentes, los colores y la disposición de los textos y objetos de la página; el servidor
tan sólo se limita a transferir el código de la página sin llevar a cabo ninguna interpretación de la misma.
Sobre el servicio web clásico podemos disponer de aplicaciones web. Éstas son fragmentos de código
que se ejecutan cuando se realizan ciertas peticiones o respuestas HTTP. Hay que distinguir entre:
Aplicaciones en el lado del cliente: El cliente web es el encargado de ejecutarlas en la máquina
del usuario. Son las aplicaciones tipo Java o Javascript, el servidor proporciona el código de las
aplicaciones al cliente y éste, mediante el navegador, las ejecuta. Es necesario, por tanto, que el cliente
disponga de un navegador con capacidad para ejecutar aplicaciones (también llamadas scripts).
Normalmente, los navegadores permiten ejecutar aplicaciones escritas en lenguaje javascript y java,
aunque pueden añadirse mas lenguajes mediante el uso de plugins.
Aplicaciones en el lado del servidor: El servidor web ejecuta la aplicación. Una vez ejecutada, genera
cierto código HTML, el servidor toma este código recién creado y lo envı́a al cliente por medio del
protocolo HTTP.
Las aplicaciones de servidor suelen ser la opción por la que se opta en la mayorı́a de las ocasiones para
realizar aplicaciones web. La razón es que, al ejecutarse ésta en el servidor y no en la máquina del cliente,
éste no necesita ninguna capacidad adicional, como sı́ ocurre en el caso de querer ejecutar aplicaciones
javascript o java. Ası́ pues, cualquier cliente dotado de un navegador web básico puede utilizar.
10.3.1. Servidor Apache

El servidor HTTP Apache es un servidor HTTP de código abierto para plataformas Unix (BSD,
GNU/Linux, etc.), Windows y otras, que implementa el protocolo HTTP/1.1 (RFC 2616) y la noción de
sitio virtual. Cuando comenzó su desarrollo en 1995 se basó inicialmente en código del popular NCSA
HTTPd 1.3, pero más tarde fue reescrito por completo. Su nombre se debe a que originalmente Apache
consistı́a solamente en un conjunto de parches a aplicar al servidor de NCSA. Era, en inglés, a patchy
server (un servidor parcheado).
El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software
Foundation.
Apache presenta entre otras caracterı́sticas mensajes de error altamente configurables, bases de datos
de autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz gráfica que ayude
en su configuración (en nuestro caso esto queda resuelto con Webmin).
En la actualidad (2005), Apache es el servidor HTTP más usado, siendo el servidor HTTP del 68 %
de los sitios web en el mundo y creciendo aún su cuota de mercado.
1 Definición obtenida de Wikipedia, la enciclopedia libre: http://es.wikipedia.org

Configuración de Apache
Para instalar el servidor web y realizar su configuración de una forma cómoda y sencilla, utilizaremos
unos módulos para la herramienta web Webmin.
Para instalarlos, realizaremos el siguiente apt:

#apt-get install apache apache-doc webmin-apache webmin-htaccess
En la figura 10.4 podemos observar la pantalla de presentación del módulo Webmin y los parámetros
de configuración que podemos modificar del mismo.
Figura 10.4: Interfaz Webmin para Apache
Directorios y archivos de configuración

En nuestra distribución Debian, los directorios de configuración se encuentran colocados en los siguien-
tes puntos del sistema:
ServerRoot: /etc/apache, . . . directorio base de los archivos de configuración.
DocumentRoot: /var/www, . . . directorio base de las páginas web del servidor.
Ejecutables de Apache: /usr/bin
El directorio base de los archivos de configuración del servidor web se especifica en el archivo httpd.conf,
utilizando la directiva ServerRoot. Cuando el servidor web se inicia mediante los scripts de inicialización,
la ruta de acceso a httpd.conf se especifica en la lı́nea de comandos del servidor (httpd) y, desde allı́, se
especifica el resto de archivos de configuración (con la opción -f ).

Hay cuatro archivos de configuración básicos en el directorio de configuración. Estos archivos, y su

contenido habitual se describen en el cuadro 10.1. Los cambios de configuración de Apache más habituales
se realizan en httpd.conf.
Cuadro 10.1: Archivos de configuración de Apache

Archivo Contenido
httpd.conf Parámetros generales de configuración del servidor. Este archivo tiende ahora a contener
toda la configuración, suprimiendo la necesidad de srm.conf y access.conf.
srm.conf Directrices del procesamiento de las peticiones, entre otras: respuestas de error, opciones
de indexación del directorio y de procesamiento de scripts. Este archivo define el árbol
de documentos (espacio de nombres) visible por todos los usuarios, además de cómo el
servidor envı́a información de ese árbol a clientes remotos. La estructura del árbol de
documentos no tiene que coincidir necesariamente con la estructura del directorio de su
sistema de archivos local. Por lo general, este archivo no se sigue utilizando.
access.conf Opciones de cada directorio: entre otras, control de acceso y restricciones de seguridad,
este archivo ya no se suele utilizar.
mime.types Definiciones de tipos de archivo MIME para diferentes extensiones de archivos.
Históricamente, los archivos .conf contienen los diferentes tipos de información. Sin embargo, todas
las directrices del servidor web se pueden colocar en cualquiera de los tres archivos, y el servidor web las
interpretará correctamente. Con el fin de reducir la confusión, Apache se distribuye ahora con todas las
opciones en el archivo principal httpd.conf. Si existen los demás archivos .conf, se procesarán en el orden
siguiente: http.conf, srm.conf y access.conf. Los archivos de configuración adicionales (especialmente los
relacionados con la seguridad) deberán estar presentes en el árbol de documentos real que el servidor
procesa.
Estos archivos pueden ser modificados desde el módulo Webmin de Apache. Los parámetros a los que
se puede acceder los podemos observar en la figura 10.5.
Sintaxis de los archivos de configuración:

Los archivos de configuración de Apache contienen una directiva por lı́nea. Se puede usar “\” al final
de una lı́nea para indicar que una directiva continua en la próxima. No puede haber otros caracteres o
espacio en blanco entre el carácter “\” y el fin de la lı́nea.
En las directivas, dentro de los archivos de configuración, no se hace distinción entre mayúsculas y
minúsculas. Las lı́neas que comiencen con el carácter “#” serán consideradas comentarios, siendo ignora-
das. No se pueden incluir comentarios en una lı́nea, después de una directiva de configuración. Los espacios
y lı́neas en blanco antes de una directiva de configuración se ignoran, de manera que se puede dejar una
sangrı́a en las directivas para mayor claridad.
Podemos hacer un chequeo de la sintaxis de sus archivos de configuración sin tener que reiniciar el
servidor, usando apachectl configtest o la opción -t de la lı́nea de comandos.
Directivas relevantes en los archivos de configuración:

Las directivas más habituales son las siguientes:
<Directory>
<DirectoryMatch>
<Files>
<FilesMatch>
<Location>
<LocationMatch>
<VirtualHost>

Figura 10.5: Parámetros de configuración de APACHE
Las directivas que se pongan en los archivos principales de configuración se aplicarán a todo el servidor.
Si queremos cambiar únicamente la configuración de una parte del servidor, podemos cambiar el rango de
acción de las directivas poniéndolas dentro de las secciones <Directory>, <DirectoryMatch>, <Files>,
<FilesMatch>, <Location>, y <LocationMatch>. Estas secciones limitan el dominio de aplicación de las
directivas dentro de ellas, a locales particulares dentro del sistema de archivos o URLs particulares. Estas
secciones pueden ser anidadas, para permitir un grado de selección más fino.
Apache tiene la capacidad de servir varios sitios web diferentes al mismo tiempo, esto se llama Hospe-
daje Virtual. El dominio de aplicación de las directivas también puede ser delimitado poniéndolas dentro
de <VirtualHost>, de manera que solo tendrán efecto para pedidos de un sitio web en particular.

A pesar de que la mayor parte de las directivas pueden ir dentro de estas secciones, hay algunas
directivas que pierden su sentido en algunos contextos. Por ejemplo, las directivas que controlan la creación
de procesos solo pueden ir en el contexto del servidor principal. Para descubrir qué directivas pueden estar
dentro de qué secciones, revise el contexto de la directiva.
Protección implı́cita de archivos del servidor:

Una de las caracterı́sticas de Apache que puede causar problemas de seguridad por ser mal interpretada
es el acceso implı́cito.
Si no se configura correctamente Apache es posible recorrer todo el sistema de archivos del servidor
desde una página web. Para evitarlo hemos de añadir las instrucciones siguientes a la configuración del
servidor:
<Directory />
Order Deny, Allow
Deny from all
</Directory>
De esta forma evitaremos el acceso implı́cito al sistema de archivos. Para dar acceso a un conjunto
determinado de directorios añadiremos el siguiente código:
<Directory /home/*/public_html>
Order Deny, Allow
Allow from all
</Directory>
Archivos .htaccess
Apache permite una administración descentralizada de la configuración, a través de archivos colocados
dentro del árbol de páginas web. Los archivos especiales se llaman normalmente .htaccess, pero se puede
especificar cualquier otro nombre en la directiva AccessFileName. Las directivas que se pongan dentro de los
archivos .htaccess se aplicarán únicamente al directorio donde esté el archivo, y a todos sus subdirectorios.
Siguen las mismas reglas de sintaxis que los archivos principales de configuración. Como los archivos
.htaccess se leen cada vez que hay una petición de páginas, los cambios en estos archivos comienzan a
actuar inmediatamente.
Para ver qué directivas se pueden colocar, podemos consultar el contexto de cada directiva. El admi-
nistrador del servidor pueden controlar aún más qué directivas son permitidas configurando la directiva
AllowOverride en los archivos principales de configuración.
Con se puede observar en la figura 10.6, en el módulo Webmin-htaccess, podemos especificar los direc-
torios a los que se va a tener acceso a través de Apache.
Figura 10.6: Interfaz Webmin para HtAccess de Apache

Archivos de log
Cualquier persona que pueda escribir en el directorio donde Apache escribe los logs, seguramente
podrá también acceder al código de usuario (UID) con el que se ha arrancado el servidor, que normalmente
es el usuario root. No debemos permitir que los usuarios puedan escribir en el directorio donde se guardan
los logs sin tener presente las posibles consecuencias.
Fichero pid : Al arrancar Apache almacena el número del proceso padre del httpd en el archivo
logs/httpd.pid. Este nombre de archivo se puede cambiar con la directiva PidFile. El número del
proceso es para el uso del administrador, cuando quiera terminar o reiniciar el demonio.
Si el proceso muere (o es interrumpido anormalmente), entonces necesitaremos matar los procesos
hijos.
Log de errores: El servidor registrará los mensajes de error en un archivo de log, que será por defecto
logs/error log. El nombre del archivo se puede alterar usando la directiva ErrorLog; se pueden usar
diferentes logs de error para diferentes anfitriones virtuales.
Log de transferencia: El servidor normalmente registrará cada pedido en un archivo de transferencia

que, por defecto, será logs/access log. El nombre del archivo se puede alterar usando la directiva
CustomLog; se pueden usar diferentes archivos de transferencia para diferentes anfitriones virtuales.
Estadı́sticas Webalizer
Para poder ver las estadı́sticas de uso del apartado Web de nuestro sistema, podemos instalar el pa-
quete Webalizer, pudiéndose controlar por web mediante un módulo para Webmin.
Para realizaremos el siguiente apt:

#apt-get install webalizer webmin-webalizer
La instalación nos pedirá que indiquemos donde esta situado el archivo de logs de Apache. También
es capaz de realizar estadisticas para el proxy Squid y los servidores FTP.
El archivo de configuración de Webalizer es: /etc/webalizer.conf
Si ejecutamos desde el programa desde la lı́nea de comandos: #webalizer, se generará el reporte de

estadı́sticas, estos reportes quedarán almacenados, en formato html, en el directorio: /var/www/webalizer.
Si utilizamos el módulo para Webmin, lo primero que necesitaremos será añadir los archivos de log de
Apache, situados en el directorio: /var/log/apache/.
En la figura 10.7 se muestran diferentes pantallas del módulo Webmin.
Hosts virtuales
El término Host Virtual se utiliza para referirse a la práctica de mantener más de un servidor web en
una sola máquina, ası́ como para diferenciarlos por el nombre de servidor que presentan. En determinadas
circunstancias puede suceder que una empresa que dispone de un servidor quiera tener más de un dominio
activo en el servidor, por ejemplo: www.empresa1.com y www.empresa2.com.
El servidor web Apache fue uno de los primeros que incluyó soporte de hosts virtuales basados en
IP y basados en nombre. A partir de la versión 1.3.13 Apache tiene una nueva funcionalidad en la que
si cualquiera de los archivos de configuración es un directorio, Apache entrará en ese directorio y anali-
zará cualquier archivo (y subdirectorio) que se encuentre allı́, tratándolos como archivos de configuración.
Un posible uso de esta funcionalidad consistirı́a en añadir servidores virtuales (VirtualHosts), creando
pequeños archivos de configuración para cada servidor virtual, y colocándolos en un directorio de confi-
guración. Ası́, se puede insertar o eliminar servidores virtuales sin tener que editar ningún archivo, sino
simplemente quitando o copiando archivos. Esto facilita la automatización de estos procesos.

Figura 10.7: Módulo de Webmin para Webalizer
Con el boom de Internet y el consiguiente aumento del número de sitios web, cada vez es más frecuente
encontrar una sola máquina actuando como servidor para más de un sitio web.
Existen unas cuantas formas de proporcionar más de un sitio web desde una máquina. Una de ellas
consiste en ejecutar múltiples copias de un servidor web, una para cada sitio; sin embargo, puede resultar
imposible por lo que respecta a los recursos de la máquina.
Hay dos métodos para soportar hosts virtuales como un solo servidor. Uno se basa en utilizar múltiples
direcciones IP, una para cada sitio web, y otro se basa en soportar múltiples nombres de host en (normal-
mente) una sola dirección IP. Se denominan, respectivamente, hospedaje virtual basado en IP y basado
en nombres. Una variante menor del hospedaje virtual basado en IP es el hospedaje virtual basado en
puertos, donde sólo el puerto que forma parte de la dirección diferencia los hosts virtuales.
Los procedimientos y los parámetros necesarios para configurar el hospedaje virtual utilizando estos
métodos diferentes se tratan en las secciones siguientes. He aquı́ unas cuantas preguntas que podemos
utilizar para seleccionar una de los métodos de hospedaje virtual:
¿Disponemos de más de una dirección IP?
¿Cuantos sitios web pensamos hospedar?
¿Necesitan todos los sitios utilizar el puerto HTTP predeterminado (80)?
¿Se han asignado múltiples nombres a la máquina?
¿Deseamos separar estrictamente los sitios web?

Para añadir un host virtual en Apache utilizaremos la directiva <VirtualHost>.
En el siguiente ejemplo podemos ver cómo se definirı́a un servidor virtual para el dominio www.aucad.com.
<VirutalHost www.aucad.com aucad.com>

ServerName www.aucad.com
DocumentRoot /usr/local/etc/httpd/vhost/aucad
ServerAdmin webmaster@servidoc.com
TransferLog /usr/local/etc/httpd/vhosts/aucad/logs/access_log
ErrorLog /usr/local/etc/httpd/vhosts/aucad/logs/error_log
ScripAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/
</VirtualHost>
En la figura 10.8, podemos observar la configuración gráfica de Webmin para Servidores virtuales
Figura 10.8: Servidores Virtuales en Apache
Compartir carpetas en el servidor web
Una vez tenemos montado el servidor virtual, en cada servidor podemos colocar las carpetas web que
queramos, en la figura 10.9 podemos observar como se configurará.
Figura 10.9: Compartición de carpetas en Apache

Arrancar el servidor Apache

El proceso httpd, se ejecuta como un demonio en segundo plano para atender las peticiones que se
realicen. Es posible que Apache sea invocado por el demonio Internet, inetd o xinetd, cada vez que se
realice una conexión al servicio HTTP usando la directiva ServerType, aunque esto no se recomienda.
En el caso de que el puerto especificado en el archivo de configuración sea el puerto por defecto, 80
(o cualquiera por debajo de 1024), será necesario tener privilegios de root para poder iniciar Apache.
Una vez que el servidor ha arrancado y completado las actividades preeliminares como la apertura de
los archivos de registro, ejecutará los procesos hijo que realizan el trabajo de escuchar y responder las
peticiones de los clientes. El proceso principal httpd continuará ejecutándose como root, pero los procesos
hijo se lanzarán con un usuario con menos privilegios.
La primera tarea que realiza httpd cuando es invocado es localizar y leer el archivo de configuración
httpd.conf. Es posible especificar la ruta del archivo en el momento de la ejecución la opción -f en la lı́nea
de comandos de la forma:
#httpd -f /etc/apache/httpd.conf
En lugar de ejecutar http directamente, podemos utilizar el script llamando a apachectl que sirve para
controlar el proceso demonio con comandos simples como:
#apachectl start, . . . para arrancar el servidor
#apachectl stop, . . . para detener el servidor
Si el servidor Apache se ejecuta correctamente volverá a aparecer el sı́mbolo del sistema y si ejecutamos
en un navegador: http://localhost, podremos ver la página de prueba ubicada en el directorio especificado
en DocumentRoot.
Si nos da algún fallo al arrancar normalmente es debido a que ya habı́a otra instancia de Apache corrien-
do o a que estamos intentado arrancar el servidor por un puerto privilegiado, sin utilizar privilegios de root.
Si queremos que Apache arranque automáticamente, lo deberemos colocar en uno de los scripts runlevel
(véase apéndice D), de inicio del sistema. Si hemos realizado un apt, ya se habrá colocado allı́.
Módulos Apache
Apache es un servidor modular. Esto implica que en el servidor básico se incluyen únicamente las
funcionalidades más básicas. Otras funcionalidades se encuentran disponibles a través de módulos que
pueden ser cargados por Apache. Por defecto, durante la compilación se incluye en el servidor un juego
de módulos base. Los módulos van por separado y pueden ser incluidos en cualquier momento usando la
directiva LoadModule. Las directivas de configuración pueden ser incluidas en forma condicional depen-
diendo de la presencia de un módulo particular, poniéndolas dentro de un bloque <IfModule>. Para ver
qué módulos han sido cargados en el servidor, se puede usar la opción de lı́nea de comandos -l.
Para poder realizar las configuración, en conjunto con el resto del sistema, podrı́a ser interesante
utilizar alguno de los siguientes módulos Apache:
apache-utils
libapache-mod-security
apache-perl libapache-mod-perl
apache-php libapache-mod-php4
libapache-mod-jk
libapache-mod-auth-shadow

libapache-mod-auth-radius
libapache-mod-ldap
libapache-mod-auth-mysql libapache-mod-acct-mysql
libapache-mod-repository
...
Como se muestra en la figura 10.10, podemos observar que módulos se encuentran instalados en el
sistema y habilitar o deshabilitar su uso.
Figura 10.10: Módulos instalados en APACHE
10.3.2. Apache-SSL: Conexiones seguras

Para instalar Apache con SSL, realizaremos el siguiente apt:
#apt-get install apache-ssl libapache-mod-ssl libapache-mod-ssl-doc
La información de esta sección a sido obtenida de [BN00].
En esta sección nos ocuparemos de otro aspecto de la seguridad: hacer privadas las comunicaciones
mantenidas entre los clientes y su servidor web, lo cual se consigue codificando dichas comunicaciones a
través del protocolo SSL (Secure Sockets Layer ).
El hecho de que el protocolo SSL esté disponible para utilizarlo con los servidores web, supone un in-
teresante dilema para los gobiernos que desean controlar los sistemas de codificación con el fin de impedir
que caiga en las manos de entidades extranjeras a las que espiar.
SSL es un protocolo que fue definido, inicialmente, por Netscape Communications Corporation con el
fin de posibilitar que dos máquinas que se comunicasen a través de TCP/IP, codificasen la información
que se enviaran la una a la otra. Después de garantizar, de esta manera, la seguridad de una sesión de
comunicación, las dos máquinas pueden intercambiar información privada o confidencial sin preocuparse
de que alguien pueda escuchar y utilizar la información. La seguridad es una caracterı́stica fundamental
para los servidores web utilizados para el comercio en Internet, esta actividad requiere con frecuencia la
transferencia de información personal y confidencial, como números de tarjetas de crédito o códigos de
cuentas bancarias.

Sistemas de clave pública-privada
Para codificar los paquetes que viajan entre dos máquinas, las máquinas deben entender una codifica-
ción de algoritmos común, y deben intercambiar información que permita a una máquina descodificar lo
que la otra codifica. Las partes de la información de seguridad utilizadas para codificar y descodificar la
información se llaman claves.
La codificación se realiza introduciendo una modificación en la información localizada en una ubicación,
mediante una clave. Se transmite, entonces, la información a otra ubicación, donde se utiliza una clave para
restaurar la información a su forma original (descodificarla). En un sistema sencillo, la clave utilizada para
codificar la información es la misma que se utiliza para descodificarla. Es a esto a lo que se llama sistema
de clave privada, porque el contenido de la clave se debe mantener en secreto para que la información se
mantenga también en secreto. Sin embargo, los sistemas de clave privada presentan un problema porque
la clave se debe transmitir, de algún modo, de forma segura a la nueva ubicación. SSL utiliza una forma
especial de codificación denominada infraestructura de clave pública (PKI), como parte del sistema global
que utiliza para proporcionar sesiones de comunicación segura.
En un sistema de claves como éste, se utilizan dos claves para el proceso de codificación y descodifica-
ción, y una de ellas (la clave pública) se puede hacer disponible para cualquiera sin que se vea afectada
la seguridad de las comunicaciones entre dos máquinas. De esta forma se soluciona el problema de la
seguridad de la distribución de claves, inherente a los sistemas de claves.
Certificados: Verificación de quién está al otro lado de una sesión segura
Otro asunto relacionado con las comunicaciones seguras es si debemos confiar en el servidor web con
el que nos estamos comunicando. Aunque un servidor web puede enviar a un cliente una clave para
realizar una comunicación segura con el mismo, es posible que el servidor esté hablando con el servidor
web erróneo (por ejemplo, el cliente puede proporcionar un número de tarjeta de crédito a un servidor
falso ejecutado por estafadores). Cuando se utiliza un sistema de clave pública-privada, también es posible
transmitir información adicional, lo que se denomina un certificado, donde se describa al servidor web y
a la organización que hay detrás del mismo.
Este certificado puede estar “firmada” electrónicamente por una agencia de confianza. Existen varias
agencias que investigan a la organización que esté ejecutando el sitio web y la información recopilada en
el certificado y, después, firman el certificado, por un precio. Los navegadores clientes poseen una lista de
agencias de confianza que utilizan para verificar que se está comunicando con el servidor con el que el
usuario desea (es decir, que el servidor está siendo ejecutado por la organización que el usuario espera).
Cuando instalemos un servidor web, debemos crear una pareja de claves públicas-privadas y un certi-
ficado para utilizarlos con el servidor. Si deseamos ejecutar un sitio web seguro para uso público, debemos
hacer que una de estas agencias de confianza firme el certificado.
Utilización del HTTP seguro: HTTPS
En las comunicaciones a través de un servidor web seguro, el cliente utiliza un protocolo diferente,
denominado HTTPS (o HTTP seguro), en lugar de HTTP. Como se deduce del nombre, es similar al
HTTP, pero con seguridad añadida. Para acceder a un servidor web seguro, un usuario debe especificar
la URL con el identificador de protocolo HTTPS, como indico a continuación:
https://www.example.com/cgi-bin/proceso de tarjetas de credito
Uno de los errores más comunes que cometen los nuevos administradores de servidores de web seguros,
es no utilizar el tipo de protocolo correcto (https) en las URL que remiten al sitio web seguro. Mientras el
puerto predeterminado TCP para el protolo HTTP es el puerto 80, el puerto predeterminado para HTTPS
es 443. Cuando un navegador intenta acceder a un servidor seguro en un puerto equivocado, parece que
el navegador se boquea y, finalmente, se agota el tiempo de espera.
Esto puede desconcertar al usuario final, de modo debemos prestar especial atención a la comprobación
de todas las URL que creemos y que estén vinculadas al sitio seguro.

10.3.3. Creación de un servidor web seguro

Debido a las restricciones gubernamentales impuestas en los EEUU a la exportación, la mayorı́a de las
distribuciones no proporcionan directamente la funcionalidad de servidor de web seguro. Linux se distri-
buye en todo el mundo y el gobierno de EEUU no permite la venta fuera de sus fronteras de determinadas
formas de codificación. Lo que significa, desafortunadamente, que hay que ingeniárselas para conseguir,
generar e instalar la funcionalidad del servidor web seguro para Apache.
Existen dos opción para agregar el protocolo SSL a Apache; la que se describe a continuación, y que
se recomienda usar, se denomina mod ssl. Consiste en un conjunto de parches y un módulo especial para
utilizarlos con el código fuente de Apache y utiliza una biblioteca de criptografı́a, llamada OpenSSL, que
proporciona las funciones de SSL. OpenSSL se basa en una biblioteca más antigua llamada SSLeay, y
mod ssl se basa en el paquete que utilizamos, Apache-SSL. El hecho de que un paquete pueda constituir
la base para otro, aunque sea de la competencia, es uno de los mejores valores de la filosofı́a Open Sopurce
(de código fuente abierto).
Preparación de los archivos especiales necesarios para la seguridad

El servidor necesita varios archivos especiales para operar de modo seguro. Alguno de ellos requieren
un procesamiento especial llevado a cabo por una agencia de confianza (una autoridad de certificación)
para que el público en general utilice correctamente el sitio web.
Los archivos siguientes se utilizan para la seguridad del servidor:
Un archivo de claves del servidor : Este archivo contiene una clave pública y una privada, utilizadas
por el servidor para codificar y descodificar operaciones.
Un archivo de certificado. Este archivo indica que la clave y el sitio web son gestionados por una
determinada organización. Si es una agencia de confianza quien firma este certificado, el usuario
puede confiar en que es ciertamente esa organización la que ejecuta el sitio web.
Una petición de firma del certificado: Este archivo contiene información del certificado, ası́ como in-
formación sobre la clave. Se debe enviar a la agencia de confianza (llamada autoridad de certificación)
para que sea firmado.
Todos estos archivos son creado durante el proceso de instalación de Apache-SSL. Ası́ como los nuevos
archivos de configuración que quedarán alojados en: /etc/apache-ssl/.
A partir de ahora nuestro httpd.conf, se encontrará situado en: /etc/apache-ssl/httpd.conf
Pareja de claves pública-privada:

La pareja de claves pública-privada se guarda en el archivo server.key, de manera predeterminada.
Este archivo contiene las claves que utiliza el servidor para realizar la codificación.
La clave privada de la pareja de claves pública-privada debe ser protegida en todo momento. Por
este motivo, durante la creación de la clave, se nos pedirá que introduzcamos una frase de contraseña
para codificar el archivo que contiene la clave. Una vez que el archivo esté codificado, se nos pedirá que
introduzcamos la frase de contraseña cada vez que el servidor se inicie para que pueda acceder al archivo.
Aunque pueda resultar molesto, es muy peligroso dejar sin codificar la clave privada en el disco, sin
protegerla con una frase de contraseña.
Hay que utilizar la directiva SSLCertificateKeyFile del archivo de configuración httpd.conf del servidor
para especificar el archivo de claves que ha de usarse para que las operaciones sean seguras.
El certificado del servidor

El archivo de certificado del servidor contiene información sobre la organización que ejecuta el sitio
web. Éste es transmitido al cliente cuando se establece una sesión segura, y el cliente lo utiliza para verificar

que el sitio es legal. A veces se le llama archivo X.509 porque ése es el nombre del estándar que define el
formato utilizado para este archivo.
Para que el cliente acepte el certificado, debe ser firmado digitalmente por una CA (Certificate Autho-
rity, Autoridad de certificación). Cada uno de los principales navegadores que soportan el protocolo SSL
posee una lista de las autoridades de certificación de confianza cuyas firmas acepta. Cuando un navegador
se encuentra ante un certificado firmado por una CA que no conoce, suele proporcionar al usuario la infor-
mación sobre dicha autoridad y el certificado preguntándole si debe continuar. De modo que dependerá del
usuario si confı́a o no en que el sitio al que está conectado sea válido.
El archivo de certificados que se ha de utilizar aparece especificado en el archivo de configuración del
servidor, mediante la directiva SSLCertificateFile
La petición de firma del certificado
Si deseamos que los clientes confı́en en nuestro sitio, deberemos poseer un certificado firmado por una
agencia de confianza que funcione como autoridad de certificación. Para que una autoridad de certificación
nos firme el certificado, deberemos de crear un CSR (Certificate Signing Request, Petición de firma del
certificado) y envı́arla a la autoridad con la documentación y el dinero.
Existen varias agencias que actúan como autoridades de certificación, lo que implica verificar la in-
formación recopilada en el certificado y firmarlo digitalmente. El precio de este servicio se cobra por el
coste derivado de investigar la información que contiene el CSR y por asumir la responsabilidad de la
certificación de nuestro sitio web.
En la siguiente lista se pueden observar algunas autoridades de certificación:
CatCert: http://www.catcert.net
CertiSing: http://certisign.com.br/servidores
Entrust: http://www.entrust.net
IKS GmbH : http://www.iks-jena.de/produkte/ca
Thawte: http://www.thawte.com
VeriSign: http://www.verisign.com/site
Todas estas compañı́as aceptan las peticiones de firma de certificados generadas por el paquete mod ssl,
para su uso con Apache y mod ssl. Cuando creemos nuestro archivo de claves de servidor y el certificado,
se creará también la petición de firma del certificado. La información solicitada para esta petición debe
coincidir exactamente con el nombre de la compañı́a, nombre registrado del dominio y otro datos que
la autoridad de certificación solicita para que puedan procesar la petición. Además, el archivo se cifra
automáticamente en un formato especial. Podemos encontrar información detallada sobre los precios y
las instrucciones para la creación de la CSR, ası́ como la documentación solicitada por la autoridad de
certificación, en los sitios web de cada compañı́a.
POdemos actuar como nuestra propia autoridad de certificación y firmar nuestro certificado para
comprobar nuestro servidor o para ejecutarlo internamente en nuestra organización. A esto se le denomina
autocertificación. Los navegadores que se conecten a nuestro servidor no reconocerán nuestra firma, como
una de las que las autoridades de certificación contemplan como válidas, pero los usuarios lo pueden
aceptar manualmente en los navegadores cuando aparezca el mensaje de error.
Para nuestro uso interno, podemos eliminar el mensaje de error que aparece en el cliente, agregando
un archivo de autoridad de certificación al navegador del cliente.
Cuando hayamos recibido un certificado firmado por una autoridad de certificación real, sustituiremos
el certificado autofirmado copiando el nuevo sobre el archivo antiguo, o modificando el valor de la directiva
SSLCertificateFile.

Ejemplo de la creación de certificados para un servidor

Deberemos de tener instalado el SSL, ya se habrá instalado con apache-ssl, pero para asegurarnos
realizamos el siguiente apt:
#apt-get openssl install ssl-cert ca-certificates
Esta es la parte fácil, el siguiente paso es crear el conjunto de llaves, y después configurar el httpd.conf
para utilizarlo correctamente. Busca dónde está instalado el OpenSSL y nos aseguraremos de que está en el
$PATH, después vamos al directorio donde tengamos los archivos de configuración de apache-ssl (/etc/apache-
ssl/conf.d/ ).
Si se necesita crear un certificado de prueba, para uso interno, se puede hacer:
#openssl genrsa -des3 > httpsd.key

#openssl req -new -x509 -key httpsd.key > httpsd.crt
Los navegadores se quejarán sobre este certificado, puesto que está creado por la persona que lo firma,
y no son fiables. Si quieres generar un certificado, y una petición de certificado para enviar a alguien como
CatCert o Verisign, entonces hay que hacer:
#openssl genrsa -des3 > httpsd.key

#openssl req -new -key httpsd.key > httpsd.csr
Ahora, configuraremos Apache para que utilize estos certificados. Se necesitan añadir varias cosas al
archivo de configuración de Apache, para conseguir que ejecute las extensiones SSL con nuestros certifi-
cados. También será preciso añadir algunas configuraciones globales.
Pasemos a ver las modificaciones de la configuración de /etc/apache-ssl/httpd.conf :

# Hay que decirle al Apache que escuche en el puerto 443, por defecto solo escucha en el 80
Listen 443
# Si utilizamos mas de un sitio seguro en una IP necesitaremos:

NameVirtualHost 10.1.1.1:443
# Es una buena idea deshabilitar el SSL globalmente y habilitarlo basado en hosts

SSLDisable
# SSL cache server, sin esto el servidor se caera

SSLCacheServerPath /usr/bin/gcache
# Puerto en el que se ejecuta el servidor

SSLCacheServerPort 12345
# timeout del SSL cache, 300 es un buen valor, lo acortaremos para realizar pruebas
valueSSLSessionCacheTimeout 300
Ahora crearemos un host virtual con SSL habilitado:

<VirtualHost www.example.com:443>
DocumentRoot /www/secure/
ServerName www.example.com
ServerAdmin example@example.com
ErrorLog logs/https_error.log
TransferLog logs/https_access.log
# Habilitar SSL para este host virtual

SSLEnable
# Esto prohibe el acceso excepto cuando se utiliza el SSL. Muy comodo para defenderse contra errores de configuracion que
# ponen al descubierto elementos que deberian estar protegidos
SSLRequireSSL
SSLCertificateFile /usr/conf/httpsd.crt
# Si la llave no esta combinada con el certificado, utilizamos esta directiva para apuntar al archivo de la llave.
SSLCertificateKeyFile /usr/conf/httpsd.key
# Si se requiere que los usuarios tengan un certificado, se necesitaran un monton de certificados raiz, para que se puedan
# verificar sus certificados personales SSLCACertificateFile /etc/ssl/ca-cert-bundle.pem
SSLVerifyClient none
</VirtualHost>
Con estas modificaciones ya deberı́amos poder acceptar peticiones por el puerto seguro. Para probarlo
podemos ejecutar la siguiente lı́nea en un navegador: https://localhost:443

Directrices de seguridad especiales

Se añaden las directrices de seguridad para el control de mod ssl a la documentación de Apache que
se instala cuando genera el servidor web seguro (podemos estudiarlas en profundidad allı́). Sin embargo,
merece la pena destacar aquı́ unas cuantas directrices de seguridad para dar una visión general sobre su
utilización.
Debemos utilizar la directiva SSLCipherSuite para controlar qué algoritmos se permiten para las
sesiones de seguridad. A menos que seamos expertos en seguridad, deberı́amos dejar estas configu-
raciones tal y como se encuentran.
Debemos utilizar la directiva SSLSessionCache para indicar si deseamos soportar una cache para
comunicar la información entre los procesos que intervengan de la sesión SSL (y, si ası́ fuera, cuál va
a ser el nombre del archivo). Debido a que las sesiones seguras requieren un trabajo importante de
configuración, y debido a que las peticiones de los clientes pueden ser servidas por múltiples procesos
servidores hijos, el uso de una cache de sesión para compartir la información entre los procesos hijo
puede acelerar las cosas considerablemente. Debemos utilizar el valor none (ninguna) para desactivar
la cache de la sesión o dbm, seguido de la ruta del archivo que se va a utilizar para la cache de sesión.
Debemos utilizar las directivas SSLLog y SSLLogLevel para crear registros donde almacenar la
información especı́fica de SSL.
Finalmente, los certificados SSL y X.509 pueden ser utilizados también por el servidor para la au-
tenticación de los clientes utilizando los certificados: SSLCACertificatePath, SSLCACertificateFile,
SSLVerifyClient, SSLVerifyDepth y SSLRequire.
Comprobación de la legalidad
En su infinita sabidurı́a, las comisiones del gobierno de los EEUU han creado leyes que convierten
en un delito exportar desde este paı́s ciertos programas potentes de codificación. Aparentemente, se ha
tomado esta medida para impedir que una herramienta de codificación muy potente caiga en manos de
terroristas y gobiernos no simpatizantes. El resultado de esta situación, sin embargo, es que la mayorı́a de
los programas buenos de codificación se desarrollan en otros paı́ses y es EEUU el paı́s que los importa, en
lugar de ser al contrario. El software de codificación que EEUU importa, ya no puede ser exportado desde
EEUU, ni al propio autor original.
Hasta hace muy poco tiempo, la compañı́a RSA Data Security, Inc. poseı́a una patente norteamericana
sobre determinados algoritmos de codificación de claves públicas-privadas utilizados en el protocolo SSL.
La patente del algoritmo de RSA expiró en el 2000, de modo que ya no existen restricciones en la mayor
parte del código. Sin embargo, si tenemos código especı́ficamente de RSA, todavı́a nos encontraremos
ligados por el contrato de licencia.
Si simplemente pensamos utilizar Apache con mod ssl como un servidor web seguro dentro de nuestra
organización seguramente no tendremos problemas. Si, por el contrario, pensamos distribuir el servidor web
o una máquina que lo contenga al extranjero, es necesario consultar con un abogado para conocer cuales
son las leyes de exportación e importación de criptografı́a en el lugar, debemos asegurarnos de atenernos
a ellas. Por suerte, los cambios que se han producido recientemente tanto en el gobierno norteamericano,
como en sus leyes, hacen la circulación de la criptografı́a más fácil. Con el tiempo se verá hacia donde nos
lleva esta tendencia.

10.3.4. Apache 2.x

La versión 2.x de Apache incorporará una gran cantidad de mejoras y nuevas opciones entre las que
cabe citar las siguientes:
Soporte de multi-threads: De esta forma Apache puede ejecutarse utilizando múltiples procesos como
sucedı́a con la versión 1.3.x, con múltiples hebras de un único proceso o en una forma hı́brida,
proporcionando de esta forma una mejor escalabilidad.
Soporte para multiple protocolos: Apache incluye la infraestructura necesaria para servir múltiples
protocolos.
Nueva API : La versión 2.x incorporá múltiples cambios en la API (Aplication Programming Inter-
face) mejorándola y añadiendo nuevas funciones que permiten incorporar nuevas capacidades a los
módulos. Uno de los inconvenientes de estas modificaciones es la incompatibilidad con los módulos
existentes para Apache 1.3.
Soporte para IPv6 : Apache permite trabajar con el protocolo IPv6.
Filtrado: Los módulos de Apache ahora pueden actuar como filtros analizando el contenido que es
servido.
Errores multilenguaje: Los mensajes de error devueltos al navegador pueden proporcionarse de forma
automática en función del idioma del navegador.
Configuración simplificada: Algunas directivas confusas han sido simplificadas. También han sufrido
mejoras algunos de los módulos que se incluyen por defecto en la instalación básica de Apache.
Algunos de estos módulos son:

• mod_ssl: Este nuevo módulo proporciona una interfaz a los protocolos de encriptación SSL/TLS
proporcionados por OpenSSL.
• mod_dav: Es un módulo nuevo que implementa DAV (Distributed Authoring and Versioning)
para HTTP. DAV es una especificación para publicar y mantener el contenido de una web.
• mod_proxy: Este módulo ha sido completamente reescrito para aprovechar las nuevas carac-
terı́sticas de filtrado e implementar de una forma más eficiente HTTP/1.1
Para instalarlo deberemos ejecutar el siguiente apt:

#apt-get install apache2 apache2-doc
10.3.5. Ataques al servidor Web

Actualmente casi todas las empresas tienen que ejecutar un servidor web, sin embargo, los servidores
web se sabe que tienen defectos y brechas de seguridad. La idea intrı́nseca de un servidor web (un usuario
puede extraer archivos del servidor sin ninguna autenticación) establece las brechas de seguridad. Este
gran número se debe al aumento creciente de tipos de protocolos y comandos con los que los servidores
tienen que tratar. Cuando las páginas web sólo consistı́an en HTML, era mucho más fácil controlarlo todo.
Pero ahora que los servidores tienen que interpretar ASP, PHP y otro tipo de tráfico que contiene código
ejecutable. Ahora que las aplicaciones web son cada vez más complejas, con el tiempo estos problemas
sólo se incrementarán.
Algunos servidores web son más seguros que otros, pero todos tienen sus problemas. Y un servidor
web pirateado puede significar más que la vergüenza de una página web deformada si el servidor también
tiene acceso a bases de datos y otros sistemas internos, algo bastante común en nuestros dı́as.

10.4. Servidor de correo

Para montar el servidor de correo, el siguiente conjunto de programas:
Exim4: Servidor de correo corporativo (MTA), para uso local.
Fetchmail: Servidor de correo externo, para importar cuentas ajenas.
Courier-imap: Servidor de IMAP para dar acceso desde internet.
Horde: Webmail, para consultar el correo por IMAP desde Internet. Para hacer funcionar Horde,
deberemos ejecutar además los siguientes servicios.
• Apache.
• PHP.
• Para autenticar usuarios: LDAP o MySQL.
Procmail: Procesador de correo. Es utilizado para filtrar los correos a través de los siguientes pro-
gramas
• ClamAv: Antivirus de correo.

• SpamAssassin: Filtro de Spam, basado en reglas.
• Bogofilter: Filtro de Spam, basado en el teorema de Bayes.
El sistema es un poco complejo pero consigue tener correo interno y externo, centralizado en el servidor
corporativo. Además podrá ser consultado desde el exterior mediante el Portal Web Horde, consiguiendo
que este libre de virus y Spam.
En las siguientes secciones detallo la configuración del sistema.
Basado en artı́culos publicados en http://bulma.net
10.4.1. Exim: Correo corporativo

Para instalar un servidor de correo corporativo, lo primero que necesitaremos es disponer de programa
que haga las veces de servidor de correo local (MTA, Mail Transfer Agent), en nuestro caso elegiremos el
servidor Exim4.
Para instalarlo ejecutamos el siguiente apt:

#apt-get install exim4
Durante la configuración especificaremos el uso de un único archivo de configuración global:

/etc/exim4/exim4.conf.template
Además se nos pedirá que contestemos a una serie de preguntas para configurar el servidor:
1. Tipo de uso que vamos a dar a Exim. Como posteriormente queremos enviar nosotros mismos los
e-mails, seleccionaremos la primera opción.
2. Nombre visible de nuestro sistema, es decir, el “mail name” o nombre de dominio en la dirección de
correo. Si no sabemos que contestar, colocamos cualquier cosa, después lo podemos modificar desde
el archivo de configuración.
3. Si tenemos otro nombre para el correo entrante, presionamos intro para dejar la opción por defecto.
4. Servidores virtuales de correo, en este caso no lo vamos a utilizar.
5. Hacer de “relay” para otros dominios, tampoco se aplica en nuestra situación.

6. Quien recibirá los mensajes del “postmaster” o “root”, es decir, quién recibirá los logs de error.
Colocamos un usuario del sistema que habilitemos para esta tarea.
7. Por último preguntará si queremos guardar nuestro archivo de aliases o sobrescribir el ya existente.
Por si lo necesitamos más adelante, es mejor guardar la configuración anterior.
En el archivo, /etc/exim4/exim4.conf.template, encontramos reunidos todos los parámetros de confi-
guración. Editaremos este archivo, para que reparta el correo local en el formato Maildir, consiguiendo
que sea compatible con “courier-imap” (lo utilizaremos más adelante para el Webmail).
La parte que tenemos que cambiar es la que hace referencia al reparto local de los e-mails, por defecto
los enviará al archivo: /var/mail/<usuario>, concatenándose uno detras de otro, esto es precisamente lo
que queremos evitar.
Nos situamos en la sección: 30 exim4-config mail spool. Una vez allı́ comentaremos la siguiente lı́nea:
file = /var/spool/mail/${local_part}, . . . agregándole un # delante.
Y a cambio, debajo de esa lı́nea añadiremos lo siguiente:

driver = appendfile
maildir_format = true
directory = /home/${local_part}/Maildir
create_directory = true
group = mail
mode = 0600
check_string = ""
escape_string = ""
prefix = ""
suffix = ""
Con esas lı́neas conseguiremos que el reparto se realice en el directorio de correo de cada usuario:
/home/<usuario>/<Maildir>, siendo usuario cualquier usuario del sistema y Maildir una carpeta que
hemos creado para guardar el correo. Podemos colocar la que queramos, en esta carpeta se guardara el
correo del usuario en formato maildir.
Al reiniciar Exim: /etc/init.d/exim restart, . . . ya tedremos el correo en formato Maildir.
Monitor de Exim, interfaz Webmin

Podemos monitorizar el servidor de correo Exim si instalamos el siguiente módulo para Webmin:
#apt-get install webmin-exim
Como se aprecia en la figura 10.11, podremos visualizar las siguientes informaciones:
Los Logs del servidor

La cola de correo del servidor
Estadistas de mensajes

Figura 10.11: Monitor para Exim a través del módulo para Webmin
10.4.2. Fetchmail: Correo externo

Fetchmail es un cliente de IMAP y POP que permite a los usuarios descargar automáticamente el
correo de cuentas remotas en servidores IMAP y POP y almacenarlos en carpetas de correo locales. Una
vez en local, se puede acceder a los correos de una forma más sencilla y utilizando multitud de programas
cliente.
Como caracterı́sticas más habituales podemos citar:
Soporte de POP3, APOP, KPOP, IMAP, ETRN y ODMR.
Puede reenviar correo utilizando SMTP lo que permite que las reglas de filtrado, reenvı́o y “aliasing”
funcionen correctamente.
Se puede ejecutar en modo daemon para comprobar periódicamente el correo entrante.
Puede recuperar correo de múltiples carpetas y reenviarlos, en función de la configuración establecida,

a varios usuarios locales.
Para instalarlo simplemente ejecutaremos el siguiente apt:

#apt-get install fetchmail fetchmail-ssl
El archivo de configuración general del sistema se sitúa en /etc/fetchmail y desde aquı́ se puede
redireccionar el correo a cada usuario. Este podrı́a ser un listado tı́pico:

set logfile "/home/josan/.fetchmail.log"

# establecemos el tiempo en segundos entre el que se estar\’a
# intentando recuperar el correo de los distintos servidores.
set daemon 120
#
# Recuperamos el correo de buzon@dominio.com y lo
# depositamos en el buzon de correo local de josan.
#
#
poll servidorcorreo.dominio.com #Colocamos el servidor de correo externo
proto pop3 #En este caso POP3
user usuario #Usuario del correo externo
pass "mi_password" #Password del correo externo
to josan #Usuarios local, que recibira el correo
Creamos este archivo y lo modificamos con los parámetros de las cuentas POP3 de los usuarios, el
bloque cuenta-usuario lo podemos repetir tantas veces como sea necesario.
Después sólo tenemos que crear un archivo por usuario para que cuando ese usuario ejecute Fetchmail
lea las opciones del archivo de configuración y se descargue el correo. Ese archivo se llamara: ˜/.fetchmailrc
Podriamos simplificar la configuración de los archivos de usuario mediante el paquete fetchmailconf.

Para instalarlo realizamos el siguiente apt:
#apt-get install fetchmailconf
Este podrı́a ser el archivo tipico de usuario ˜/.fechmailrc:

set postmaster "pepe"
set bouncemail
set no spambounce
set properties ""
# set daemon 90
# Cuentas de correo de ono: pepe1@ono.com y pepe2@ono.com
poll pop3.ono.com with proto POP3
user ’pepe1’ there with password ’ElPasswordDePepe1’ is ’pepe’ here
#
# Cuentas de correo terra: pepe2@terra.es pepe3@terra.es y pepe4@terra.es
poll pop3.terra.es
#
# Cuentas de correo de Microsoft: wgates@microsoft.com ;-)
poll microsoft.com with proto POP3
user ’wgates’ there with password ’Hasecorp’ is ’pepe’ here
Automatizar la descarga de correo externo

Para ejecutar Fetchmail automáticamente tenemos las siguientes opciones:
Ponerlo en el cron
Ejecutarlo como demonio del sistema. Para ello descomentamos la lı́nea: set daemon, del archivo de
configuración.
Si lo ejecutamos en modo daemon, le indicaremos cada cuantos segundos se ejecutara Fetchmail. Para
lanzar el demonio de forma automática tenemos que ejecutarlo, en alguno de los archivos de perfil, como
.profile o .bashrc (incluiremos la instrucción, fetchmail). Si preferimos lanzarlo manualmente, ejecutamos
desde la lı́nea de comandos: #fetchmail
Si lo queremos ejecutar en el cron, añadiremos al archivo /var/spool/cron/crontabs/<usuario>, en

nuestro caso pepe: */3 * * * * /usr/bin/fetchmail -s
Esto indicará que se ejecute fetchmail cada tres minutos.

Configuración gráfica de Fetchmail, interfaz Webmin

Para simplificar el proceso de configuración podemos utilizar nuestra herramienta de configuración por
web: Webmin.
Para instalar el módulo realizaremos el siguiente apt:

#apt-get install webmin-fetchmail
Figura 10.12: Módulo Webmin para Fetchmail
10.4.3. Horde: Webmail

Un Webmail no es más que una interfaz para leer el correo electrónico del servidor de correo, por medio
de una pagina web.
Horde es un programa gestor de correo IMAP para ser usado con un navegador y que está disponible
para todas las cuentas de correo de los servidores locales.
El protocolo IMAP (Internet Message Access Protocol), es un protocolo de red de acceso a mensajes
electrónicos almacenados en el servidor. Mediante IMAP se puede tener acceso al correo electrónico desde
cualquier equipo que tenga una conexión a Internet. Una vez configurada la cuenta IMAP, podemos espe-
cificar las carpetas que deseamos mostrar y las que deseamos ocultar, esta caracterı́stica lo hace diferente
del protocolo POP3.
Horde cuenta con las siguientes caracterı́sticas:
Enviar y Recibir mensajes con múltiples archivos adjuntos.
Despliegue en lı́nea de archivos adjuntos de imagenes
Interfaz de usuario amigable y atractiva basada en iconos.
Soporte para múltiples mensajes, incluyendo Ingles, Español, Francés, Alemán, Húngaro, Italiano,
Polaco, Portugués, Noruego, Ruso, . . .
Múltiples carpetas, por defecto cuenta con la opción enviar, la papelera y soporta algunas creadas
por los usuarios.
Configuración en lı́mite del tamaño para archivos adjuntos en salida.
Preferencias de usuarios, incluyendo número de mensajes en pantalla, lenguaje, firma y estilo.
Cada usuario tiene su propias libreta de direcciones.

La ventaja de usar la web es que lo podemos hacer desde cualquier ordenador y siempre tendremos la
misma configuración, los mensajes quedan en el servidor organizados en carpetas. En cambio eso no pasa
con POP3, ya que nos bajamos los mensajes y los tenemos que organizar en nuestro disco local.
Para instalar el Webmail Horde, simplemente deberemos ejecutar el siguiente apt:

#apt-get install horde3
Para acceder de forma directa a este gestor de correo, deberemos usar las direcciones:
http://dominio.tld:2095/horde/
https://dominio.tld:2096/horde/, . . . puerto seguro
Para poder utilizar Horde tenemos dos opciones:

Validar los usuario mediante directorio LDAP
Utilizar una base de datos de usuarios MySQL
Es mejor decantarse por la opción MySQL, ya que Jabber también lo utiliza y nos será útil más
funciones. Es decir, para poder utilizar Horde necesitamos tener instalados los:
Apache
PHP
MySQL
Si vamos a instalar el Webmeil Horde, podemos obtener toda la información detallada en la siguiente
dirección de Internet:
http://patux.glo.org.mx/imp-mini-como.html, HowTo sobre como instalar el servidor IMAP a través
de Horde.
10.4.4. Protocolo IMAP

El protocolo IMAP nos servirá para consultar el correo vı́a web con cualquier navegador, pudiendo
realizar las conexiones desde un lugar ajeno a la empresa o mediante un cliente IMAP.
La necesidad surge ya que el protocolo POP3 es poco flexible y accediendo desde otros correos nos
puede descargarnos los e-mails al host local, si es que ası́ esta configurado en ese cliente, con la consiguiente
perdida de los e-mails del usuario que se encontraban almacenados en el servidor.
El servidor IMAP, lo que hace es recoger el correo que se encuentra en el $HOME de un usuario y
servirlo al cliente IMAP interactivamente. Es decir, los mensajes siempre están en el servidor y sólo bajan
al cliente si son seleccionados para lectura en local, y no por Internet.
Para utilizarlo, necesitaremos tener el servidor de correo Exim para enviar los correos y también Fetch-
mail para obtener los correos externos. En este punto supondremos que tenemos instalado y funcionando
en el sistema: Exim4 y Fetchmail.
En Debian para poder realizar la tarea de servidor IMAP tenemos dos paquetes: Corier-imap y Mail-
drop.
Configuración de Courier-imap
Para instalarlo es muy simple:
#apt-get install courier-imap courier-imap-ssl
Ahora, editaremos el archivo de configuración de courier-imap: /etc/courier/imapd.

Allı́ cambiaremos la siguiente lı́nea: ADDRESS = 0 por ADDRESS = 127.0.0.1, localhost
Es recomendable, por motivos de seguridad, configurar courier-imap sobre SSL. Si lo hacemos no

debemos olvidar configurar la cuenta cliente como SSL.
Configuración Maildrop
Para que el servidor solo sea accesible desde nuestra máquina. Deberemos instalar un filtro de e-mails,
para que nos coloque el correo en nuestra carpeta Maildir, o como la hayamos llamado.
Para instalarlo es muy simple:

#apt-get install maildrop courier-maildrop
Nos permite filtrar los e-mails para ası́ colocarlos en subcarpetas, según el asunto, el remitente, etc.
La configuración básica es que nos deje todos los emails en el directorio Maildir. Estas opciones son con-
figurables desde el archivo de configuración: ˜/.mailfilter.
El contenido del archivo debe de ser el siguiente:
DEFAULT="$HOME/Maildir"
logfile "$DEFAULT/.maildroplog"
Finalmente, creamos la carpeta Maildir, con el comando maildirmake:

#maildirmake Maildir
Ahora solo falta comprobar su funcionamiento. Cada cierto tiempo el usuario, mediante Fetchmail,
descargará el correo en la carpeta. Después sólo es necesario configurar un cliente de correo para que lea
del servidor de correo Imap. Por ejemplo, podemos configurar Mutt, que comprende a la perfección el
correo en formato Maildir.
A la hora de acceder al correo, deberemos colocar como nombre de servidor localhost y como usua-
rio/contraseña, el que tengamos asignado en el sistema.
10.4.5. Filtrado de correo, eliminar virus y Spam con Procmail

Ahora que ya tenemos todas nuestras cuentas de correo centralizadas en nuestra máquina, vamos a
procesar el correo. Esta tarea la lleva a cabo Procmail, justo antes de que se deje el correo en el Maildir
de cada usuario.
Para instalar Procmail, simplemente ejecutaremos el siguiente apt:

#apt-get install procmail
Procmail es una herramienta muy potente que permite repartir el correo, filtrarlo, organizarlo en car-
petas, reenviarlo automáticamente, etc. Nosotros lo utilizaremos para pasar el antivirus ClamAv y los
filtros de Spam: SpamAssassin y Bogofilter.
Las posibilidades son prácticamente ilimitadas y dependen de nuestra imaginación y de nuestras ha-
bilidades, pero básicamente el proceso consiste en dos pasos:
Identificar el correo
Procesar el correo
Para identificar el correo, usaremos las expresiones regulares, de forma que los todos correos que
cumplan unas determinadas condiciones, pasarán a realizar el proceso que queramos.

Redireccionamiento de correo
Si queremos redireccionar el correo desde Fetchmail, necesitamos editar o crear el archivo de configu-
ración Fetchmail del usuario: ˜/.fetchmailrc.
En el agregaremos las siguientes lı́neas:

$ cat $HOME/.forward
| procmail
Con esto, cada vez que nos llegue un correo (.forward), se ejecutará Procmail de forma automática.
Otra opción interesante es procesar directamente un archivo de correo (*.mbox) de forma manual, a
él se aplicarán los filtros indicados en el ˜/.procmailrc:
$formail -s procmail < INBOX.mbox
En este caso es recomendable utilizar un script para Procmail, como el siguiente:

#!/bin/sh
ORGMAIL=/var/mail/$LOGNAME
if cd $HOME &&
test -s $ORGMAIL &&
lockfile -r0 -l1024 .newmail.lock 2>/dev/null
then
trap "rm -f .newmail.lock" 1 2 3 13 15
umask 077
lockfile -l1024 -ml
cat $ORGMAIL >>.newmail &&
cat /dev/null >$ORGMAIL
lockfile -mu
formail -s procmail <.newmail &&
rm -f .newmail
rm -f .newmail.lock
fi
exit 0
Configuración de Procmail y reglas de filtrado

Los archivos de configuración de Procmail, son los siguientes:
/etc/procmailrc: Archivo de configuración del servidor Procmail.
˜/.procmailrc: Archivo de configuración Procmail, por cada usuario.
Este serı́a un archivo ˜/.procmailrc tı́pico:

PATH=/usr/bin:/bin:/usr/local/bin:.
MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/
:0fw: spamassassin.lock
* < 256000
| spamassassin
# Algunas versiones de Spamassassin eliminan la letra "F"

# de la cabecera "From"
:0
* ^^rom[ ]
{
LOG="*** Dropped F off From_ header! Fixing up. "
:0 fhw
| sed -e ’1s/^/F/’
}
Opcionalmente podrı́amos mandar los correos de Virus y Spam a /dev/null, pero los filtros no son
infalibles, por lo que por lo menos al principio, es mejor revisarlos antes de borrarlos.
Este serı́a el formato, que habrı́a que añadir al ˜/.procmailrc, para borrar los correos que cumplan una
determinada regla:
:0
* ^X-Regla: Yes
/dev/null

Configuración gráfica de Procmail, interfaz Webmin

web: Webmin.
Para instalar el módulo realizaremos el siguiente apt:

#apt-get install webmin-procmail
Figura 10.13: Módulo Webmin para Procmail
Desde este módulo, además de editar manualmente el archivo de configuración /etc/procmail, como
podemos observar en la figura 10.14, podemos especificar las acciones que ejecutará el filtro.
Figura 10.14: Crear acciones gráficamente en Procmail
10.4.6. ClamAV: Antivirus para correo

Mediante ClamAv podemos escanear, los mensajes recibidos, es el filtro antivirus que pasaremos a
través de Procmail.
ClamAv tiene licencia GPL, funciona bastante bien y se actualiza a menudo.
Para instalar el programa, simplemente ejecutaremos el siguiente apt:

#apt-get install clamav clamav-daemon

Durante el proceso de instalación clamav-freshclam (el actualizador de bases de datos de virus), pre-
guntará por qué interfaz estamos conectados a Internet y un servidor (se apuntan varios por defecto) desde
donde bajarse las actualizaciones. También podemos establecer el modo de ejecución de clamav-freshclam,
se recomienda ejecutar como demonio del sistema.
El archivo de configuración del demonio ClamAv es: /etc/clamav/clamd.conf
En ese archivo podemos encontrar las siguientes opciones:
ScanMail, para que escanee correo.
ScanArchive, para que escanee archivos.
ScanHTML, para que escanee código HTML.
Situados en este punto, suponemos que nuestro servidor de correo entrega los correos locales correc-
tamente a Procmail. Este ejecutará las reglas de filtrado de /etc/procmailrc (y después las de: ˜/.proc-
mailrc,. . . para cada usuario) y lo dejará, tı́picamente en: /var/mail/<usuario>.
Para que Procmail ejecute ClamAv añadiremos al archivo: /etc/procmailrc, las siguientes lı́neas:
SHELL=/bin/sh
AV_REPORT=‘clamdscan --stdout --disable-summary - | cut -d: -f 2‘

VIRUS=‘if [ "$AV_REPORT" != " OK" ]; then echo Yes; else echo No;fi‘
:0fw
| formail -i "X-Virus: $VIRUS"
:0fw
* ^X-Virus: Yes
| formail -i "Virus: $AV_REPORT" -i "Subject: MENSAJE CON VIRUS: $AV_REPORT"
Vamos a observar cada una de las lı́neas detenidamente:
La lı́nea de SHELL=/bin/sh es necesaria porqué se pueden tener usuarios en /etc/passwd sin shell,
en estos casos no se ejecutarı́a el código entre comillas simples.
En AV REPORT se almacena “OK”, si no tiene virus o el nombre de ese virus en caso contrario.
A la variable VIRUS se le asigna “Yes” si contiene virus y “No” en caso contrario.
En la primera regla de filtrado, añadimos la cabecera X-Virus con “Yes” o “No” (ası́ el usuario final
lo puede filtrar fácilmente, también nos sirve para saber que el correo ha sido escaneado).
En la segunda regla de filtrado, si el correo contiene virus, le agregamos una cabecera llamada
“Virus” que contiene el reporte de ClamAv. Además, modificamos el Subject y en su lugar ponemos
el nombre del virus.
Como función adicional, en lugar de modificar el Subject lo podrı́amos eliminar directamente.
Para que esta configuración funcione necesitamos tener lanzado el demonio: clamav-daemon.
Para probar que el sistema funciona, en la dirección: http://www.eicar.org/download/eicar.com.txt,

encontraremos la siguiente lı́nea:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Es un test, si nos la mandamos por e-mail, ClamAv deberá detectarlo como virus.
Una vez configurado este sistema, sólo tendremos que fijarnos que todos los correos nuevos que lleguen
a los usuarios contengan la nueva cabecera de X-Virus.

10.4.7. SpamAssassin: Filtro basado en reglas

El SpamAssassin es un filtro basado en scripts en Perl que procesan los mensajes y detectan, en base
a unas reglas bastantes complejas, si el mensajes es spam. A los correos, les son asignados una serie de
puntos, si supera determinado valor (5.0 por defecto) es considerado un spam.
La mejor manera de hacerlo funcionar es arrancar el demonio spamd y comunicarse con él a través del
spamc, que será ejecutado por Procmail. Para identificar el correo spam, usaremos expresiones regulares,
de forma que los todos correos que cumplan unas determinadas condiciones, pasaran a realizar el proceso
asignado en Procmail.
Para instalarlo nada más fácil que realizar el siguiente apt:

#apt-get install spamassassin spamc spampd
El paquete spampd, instala el demonio SMTP/LMTP demonio proxy de SpamAssassin.

El paquete spamc, instala el cliente para comunicarse con el demonio de SpamAssassin.
Para poder usar SpamAssasin como demonio es necesario retocar el archivo:

/etc/default/spamassassin y cambiar ENABLED a 1.
En el archivo de configuración de procmail, añadiremos la siguiente regla:
:0fw
| spamc -f -s 100000 -u $LOGNAME
Una vez instalados ambos y arrancado el spamd, sólo hay que hacer que el spamc filtre todos los men-
sajes para detectar spam.
El spamd agrega las siguientes cabeceras para indicar los resultados:

X-Spam-Prev-Content-Type: text/html; charset="us-ascii"
X-Spam-Prev-Content-Transfer-Encoding: 7bit
X-Spam-Status: Yes, hits=11.7 required=5.0
tests=NO_REAL_NAME,MSG_ID_ADDED_BY_MTA,INVALID_MSGID,SUBJ_REMOVE,
UPPERCASE_25_50,MAILTO_WITH_SUBJ,MAILTO_TO_REMOVE,
MAILTO_WITH_SUBJ_REMOVE,BIG_FONT,MAILTO_LINK,
FROM_AND_TO_SAME
version=2.30
X-Spam-Flag: YES
X-Spam-Level: ***********
X-Spam-Checker-Version: SpamAssassin 2.30 (devel $Id: SpamAssassin.pm,v 1.94 2002/06/14 23:17:15 hughescr Exp $)
Además, agrega la siguiente cabecera al Subject del mensaje:

Subject: *****SPAM***** Say Goodbye to YELLOW, STAINED Teeth!
Y las siguientes lı́neas en el texto para describir las reglas aplicadas:

SPAM: -------------------- Start SpamAssassin results ----------------------
SPAM: This mail is probably spam. The original message has been altered
SPAM: so you can recognise or block similar unwanted mail in future.
SPAM: See http://spamassassin.org/tag/ for more details.
SPAM:
SPAM: Content analysis details: (25.5 hits, 5 required)
SPAM: NO_REAL_NAME (-1.1 points) From: does not include a real name
SPAM: INVALID_DATE_TZ_ABSURD (4.4 points) Invalid Date: header (timezone does not exist)
SPAM: FAKED_UNDISC_RECIPS (3.5 points) Faked To "Undisclosed-Recipients"
SPAM: PLING (0.1 points) Subject has an exclamation mark
SPAM: DOUBLE_CAPSWORD (1.1 points) BODY: A word in all caps repeated on the line
SPAM: CLICK_BELOW (1.5 points) BODY: Asks you to click below
SPAM: CALL_FREE (0.7 points) BODY: Contains a tollfree number
SPAM: NORMAL_HTTP_TO_IP (3.3 points) URI: Uses a dotted-decimal IP address in URL
SPAM: REMOVE_PAGE (2.2 points) URI: URL of page called "remove"
SPAM: MAILTO_WITH_SUBJ (1.9 points) URI: Includes a link to send a mail with a subject
SPAM: CLICK_HERE_LINK (0.8 points) BODY: Tells you to click on a URL
SPAM: MAILTO_LINK (0.8 points) BODY: Includes a URL link to send an email
SPAM: FREQ_SPAM_PHRASE (2.4 points) Contains phrases frequently found in spam
SPAM: [score: 14, hits: click here, email address,]
SPAM: [enter your, list please, please click, this]
SPAM: [message, you wish, your email, your]
SPAM: [name]
SPAM: DATE_IN_FUTURE_06_12 (2.4 points) Date: is 6 to 12 hours after Received: date
SPAM: FORGED_YAHOO_RCVD (1.5 points) ’From’ yahoo.com does not match ’Received’ headers
SPAM:
SPAM: -------------------- End of SpamAssassin results ---------------------

Configuración del Procmail, con SpamAssassin

Se pueden aplicar filtros en el Procmail del usuario, en el genérico para todo el sistema (Hay que usar
con cuidado esta opción, borrar o modificar un mensaje de terceros sin su aprobación puede ser un delito)
o en el propio cliente (MUA) de correo electrónico, que es la opción más recomendable.
En este apartado lanzaremos el cliente (spamc) desde: /etc/procmailrc y ejecutarlo de forma global.
Editaremos el archivo y añadiremos las siguientes lı́neas:
DROPPRIVS=yes
:0fw
| /usr/bin/spamc -f
Después en el ˜/.procmailrc filtramos los spams a una carpeta especial para separarla del correo válido
y poder revisar, en busca de falsos positivos:
:0:
* ^X-Spam-Status: Yes
mail/spams
Los Spams son enviados al directorio: ˜/mail/spams, pero si nuestras reglas están lo suficientemente
probadas y no nos importa perder algún e-mail válido, podemos eliminarlos, enviándolos a /dev/null
Configuración gráfica de SpamAssassin, interfaz Webmin

web: Webmin. Para instalar el módulo realizaremos el siguiente apt:
#apt-get install webmin-spamassassin
Figura 10.15: Módulo Webmin para SpamAssassin
Como opción adicional se pueden especificar las opciones de configuración de Procmail para que pro-
cese el correo con SpamAssassin.

En las siguientes figuras (10.16) podremos observar la multitud de opciones que podemos configurables
gráficamente.
Figura 10.16: Opciones de configuración SpamAssassin
10.4.8. Bogofilter: Filtro bayesiano

El problema fundamental con el SpamAssassin es que está basado en el reconocimiento de patrones
de texto usando reglas, lo que obliga a estar continuamente actualizando y agregando nuevas reglas para
adaptarse a los cambios del spam. Además hay que elaborar reglas para cada lenguaje.
Esto produce que el proceso de análisis de cada mensaje sea aún más lento de lo que ya es actualmente,
entre otras cosas porque está implementado en Perl y el número de reglas es muy grande.
Y no acaba aquı́, en problema, lo que es el más grave, puede dar falsos positivos, que son mensajes que
no son spams pero son considerados como tal por el filtro. Esto es lo peor que le puede pasar, podemos
perder o dejar de leer mensajes importantes. También de vez en cuando, llegan spam que haya pasado el
filtro (falso negativo), pero en este caso no pasa nada realmente grave.
El SpamAssasin al poco tiempo muestra sus problemas, es muy fácil para los spammers encontrar
los trucos para saltarse las reglas de filtrados, ya que son de dominio público y común para todas las
instalaciones.
La solución pasa por usar métodos que “aprendan” de los mensajes que recibe el usuario y generan
una base de datos propia. Esta base de datos sirve para calcular las probabilidades combinadas de que un
mensaje sea o no spam, en función de las palabras que contiene. Este método se denomina “bayesiano” y

esta basado en el “Teorema de Bayes” sobre probabilidad, y se adapta automáticamente al idioma y a los
tipos de mensajes que recibe cada usuario.
El problema fundamental de ésta aproximación es que hay que entrenar inicialmente al programa con
un conjunto relativamente grande de mensajes spams y otros válidos para que arme su base de datos. A
partir de allı́, el programa puede aplicar los métodos bayesianos y usar esos mismos mensajes, ya clasifi-
cados como spam o no, para realimentar la base de datos. Para que el filtro aprenda, por cada mensaje
spam en la base de datos, tenemos que proporcionarle al menos tres mensajes buenos. Si no hacemos esto
dará muchos falsos positivos.
Una implementación mejorada de este método es Bogofilter, el filtro bayesiano que aquı́ propongo.
Configuración de Bogofilter
Para instalarlo realizaremos el siguiente apt:
#apt-get install bogofilter
Bogofilter mantiene un par de bases de datos en el directorio: ˜/.bogofilter :
goodlist.db
spamlist.db
Cada una de ellas mantiene una lista de “tokens” (palabras) junto con la cantidad de veces que esa
palabra ha aparecido en mensajes válidos y mensajes spams. Esos números son usados para calcular la
probabilidad de que el mensaje sea un spam.
Una vez que se han calculado las probabilidades, se usan aquellas más alejadas de la media para
combinarlas usando el Teorema de Bayes de probabilidades combinadas. Si la probabilidad combinada es
mayor que 0.9, bogofilter retorna 1, caso contrario retorna 0.
La fiabilidad del bogofilter depende exclusivamente de la cantidad de palabras que tenga en su base de
datos, mientras más contenga y mayor sea la cantidad de apariciones de cada palabra en un mensaje válido
o spam, mejores serán sus resultados. Si sólo le enseñamos cuales son mensajes válidos, no podrá detectar
los spams. Al contrario, si sólo le “enseñamos” spams, considerará a muchos mensajes válidos como spams
(falsos positivos . . . ). O sea, el aprendizaje inicial es importantı́simo, y nos ahorrará mucho trabajo de
mantenimiento de la base de datos.
Para configurarlo realizaremos los siguientes pasos:
Entrenarlo con un conjunto grande de mensajes válidos que tengamos almacenados.
Entrenarlo con un conjunto grande de spams.
Configurar ˜/.procmailrc
Seguimiento y mantenimiento los primeros dı́as, para evitar falsos positivos.
Si queremos probar otros, el sistema Debian pone a nuestra disposición, más filtros bayesianos como
por ejemplo, spamprobe.
Entrenarlo con mensajes válidos

Este paso es muy importante, caso contrario puede generar falsos positivos. Lo mejor en estos casos
es entrenarlo con los mensajes que tengamos almacenados en nuestro cliente de correo. Se aconsejan al
menos 1.000 mensajes.
Si tenemos los mensajes almacenados en formato mbox, basta con hacer lo siguiente:
#bogofilter -n < archivo_mbox

Si por el contrario lo tenemos en formato Maildir, y debido a que el estándar de éste formato quita
las lı́neas de “From” de inicio de mensaje, el Bogofilter no es capaz de separar y contar los mensajes, por
lo que hay que llamarlo por cada mensaje almacenado. Esto se puede realizar fácilmente con el siguiente
script:
for f in directorio_maildir/*
do
bogofilter -n < $f
done
Si hemos seguido los pasos descritos en este capitulo, no será necesario ya que en la sección 10.4.5
hemos realizado un filtro que recomponı́a esa lı́nea de “From”.
Después de este paso se habrá creado la base de datos: ~/.bogofilter/goodlist.db
Entrenarlo con spams

El siguiente paso será entrenarlo con spams, en la dirección:
http://bulma.net/ gallir/BULMA/spams.txt.gz
Se puede encontrar una lista de más de 700 mensajes de spams. Para entrenar el filtro con estos
mensajes usaremos la instrucción:
#zcat spams.txt.gz | bogofilter -s
Después de este paso se habrá creado la base de datos: ~/.bogofilter/spamlist.db
Configuración de Procmail
El siguiente paso es configurar Procmail. Para ello modificaremos el archivo de configuración: ˜/.proc-
mailrc de cada usuario, ya que este filtro dependerá de sus e-mails y no tendrı́a sentido aplicarlo a toda
la organización (en el /etc/procmailrc).
Una vez el mensaje ha sido clasificado como spam, modificaremos la configuración de Procmail para
que mueva los mensajes a otro archivo: ˜/mail/spams.
Además de ello, realimentaremos la base de datos con cada mensaje que llega, por lo que el sistema
irá aprendiendo con el tiempo, en pocas semanas ya no necesita casi mantenimiento.
El código que incluiremos en el ˜/.procmailrc es el siguiente:

:0HB
* ? bogofilter
{
# Es un spam, realimentamos la base de datos de spam
:0HBc
| bogofilter -S
# lo movemos al archivo $HOME/mail/spams

:0
mail/spams
}
:0EHBc
# Es un mensaje valido, realimentamos la base de datos validos
| bogofilter -n

Podemos realizar la actualización automática mediante la opción -u que indica al Bogofilter que ac-
tualice directamente la base de datos de acuerdo a la clasificación que se haga del mensaje.
Es decir la siguiente regla, insertada en ˜/.procmailrc, ya serı́a suficiente:
:0HB
* ? bogofilter -u
mail/spams
Seguimiento y mantenimiento
Aunque con el entrenamiento oficial y usando un conjunto de mensajes grande, es suficiente para que
el Bogofilter casi no de falsos positivos, los primeros dı́as deberemos de verificar los mensajes, resituando
los falsos positivos como mensajes válidos.
Para recolocar las modificaciones realizadas, tenemos las versiones incrementales -N y -S. En ambos
casos lo que tenemos que hacer es grabar el mensaje en un archivo de texto y ejecutar con la opción que
corresponda, -S si es un spam y -N si es un falso positivo.
Para marcar como spam un mensaje no detectado:

#bogofilter -S < mensaje.txt
Para marcar como válido un falso positivo:

#bogofilter -N < mensaje.txt, . . . esta situado en el archivo mbox: ˜/mail/spams.
10.5. Jabber: Mensajerı́a instantánea para corporaciones

El protocolo Jabber, será una de las piezas claves del desarrollo y evolución de la futura Internet, como
lo son y han sido los protocolos IP, FTP, Telnet, DNS, NNTP, ARP, ICMP, . . . , pero enfocado a la cada
vez más utilizada mensajerı́a instantánea.
Jabber a diferencia de otros sistemas de mensajerı́as instantáneos, es algo más que un sencillo programa
para enviar y recibir mensajes de texto entre usuarios a través de Internet, es un protocolo de Internet que
aspira a convertirse en parte fundamental de la misma, para lo cual cuenta con una serie de interesantes
caracterı́sticas:
Buena documentación.
Basado en estandares abiertos y libres.
Utiliza XML.
Es multiplataforma.
Su código esta liberado a la comunidad.
Existen multitud de clientes que lo utilizan

Utiliza pasarelas para interactuar con otros servicios (MSN, Yahoo, ICQ, IRC, . . . ).
Es modulable y escalable, lo que permite añadir mejoras fácilmente.
Existen disponibles, librerı́as Jabber en varios lenguajes.
Está basado en una arquitectura cliente/servidor.

Esta formado por un servidor y clientes, que son los programas que utilizan los usuarios para enviar y
recibir mensajes entre sı́. Existen clientes para prácticamente todas las plataformas (incluso varios escritos
en Java, con la consiguiente portabilidad).
Jabber es ideal para instalarlo en empresas, como complemento a la propia Intranet, puesto que
permite la comunicación de los trabajadores de una forma eficiente, rápida y muy económica. De forma
que permite, por ejemplo, intercambiar documentos, programas, datos, textos, . . . de una forma muy
sencilla sin tener que utilizar sistemas más complejos como ftp o correo interno, es decir, consiguiendo
comunicación instantánea y directa.
10.5.1. Servidor Jabber

Para poder instalar el servidor Jabber necesitamos realizar un apt:
#apt-get install jabber
Con esto, se guardaran en nuestro sistema todos los archivos básicos. Si observamos los archivos de
configuración de usuarios (/etc/passwd ) se ha creado un usuario jabber, para manejar el servidor Jabber
en el sistema. Además el servicio ha quedado agregado al arranque del sistema, en el inetd.
Para arrancar el servidor de jabber, a mano, ejecutaremos: #jabberd
Configuración Jabber
La configuración se encuentra centralizada en un único archivo: /etc/jabber/jabber.xml
Lo primero que tendremos que hacer es especificar en que máquina esta el servidor, el nombre de la
misma ha de estar en formato FQDN, para que desde cualquier máquina de nuestra red pueda acceder a
los servicios proporcionados por Jabber. Otra opción es poner directamente la dirección IP de la máquina,
e incluso para realizar pruebas en la propia máquina podemos poner localhost.
Cambiaremos la lı́nea:
<host><jabberd:cmdline flag="h">localhost</jabberd:cmdline></host>
Por una de las siguientes opciones:
<host>localhost</host>
<host>FQDN_servidor_jabber<host>
<host>IP_servidor_jabber<host>
Una vez arrancado el servidor, tendremos que verificar si realmente todo funciona bien, para lo cual
utilizaremos algunos de los múltiples clientes existentes para Jabber, (véase sección 10.18). Desde el cliente
necesitamos crear un usuario y registrarlo en el servidor local.
Podemos añadirle también otras funcionalidades extras:

Si queremos que nuestro servidor Jabber soporte conferencia, es decir más de dos usuarios simulta-
neos, necesitamos jabber-muc (Jabber Multi user chat), para ello realizaremos el siguiente apt:
#apt-get install jabber-muc

Si queremos que nuestro servidor Jabber soporte la busqueda de usuarios, es decir poder buscar
en el archivo de usuarios del sistema, necesitamos jabber-jud (Jabber User Directory), para ello
realizaremos el siguiente apt:
#apt-get install jabber-jud
Si queremos que nuestro servidor se comunique con otros protocolos propietarios como (IRC, MSN,
Yahoo, ICQ, AIM, . . . ), tenemos disponibles pasarelas a esos protocolos:
• #apt-get install jabber-irc : IRC
• #apt-get install jabber-msn : MSN Messenger
• #apt-get install jabber-jit : ICQ
• #apt-get install jabber-aim : AIM messenger
• #apt-get install jabber-yahoo: Yahoo messenger
Pero si aún necesitamos más potencia para nuestro servidor de mensajerı́a instantánea, en la dirección:
http://download.jabber.org/, encontraremos más utilidades.
Para conseguir más información sobre las opciones, podemos recurrir al manual: #man jabberd
O bien consultar la página oficial: http://www.jabber.org
10.5.2. Configuración gráfica de Jabber, interfaz Webmin

Podemos hacer más sencilla la configuración de nuestro servidor, si utilizamos nuestra herramienta
web: Webmin. Para instalar el módulo de Jabber realizaremos el siguiente apt:
#apt-get install webmin-jabber
Pomo se puede observar en la figura 10.17, podemos acceder a las opciones generales, como pue-
den ser quien puede tener acceso al servidor jabber o también nos da acceso al archivo de cofiguración
/etc/jabber/jabber.xml.
10.5.3. Clientes Jabber

Para poder interactuar con el servidor Jabber, necesitamos tener instalado un cliente. Existe muchos
clientes para jabber, personalmente utilizo kopete basado en el entorno de escritorio KDE.
Para instalarlo realizaremos un apt:

#apt-get install kopete
Desde el cliente nos conectaremos con una cuenta al servidor Jabber local y si no tenemos cuenta,
también podemos registrarla.
Como podemos observar en la figura 10.18, situando nuestra cuenta podemos interactuar con multitud
de servicios de mensajerı́a además de Jabber, es un cliente muy versatil.
Existen otros Clientes multiprotocolo, como Gaim (véase figura 10.19), que también funcionan muy
bien.
Para instalarlo: #apt-get install gaim
Al final todo es cuestión de probar y quedarnos con el cliente que más nos guste.

Figura 10.17: Módulo Webmin para Jabber

Figura 10.18: Cliente de mensajerı́a instantanea Kopete
Figura 10.19: Cliente de mensajerı́a instantanea Gaim

Capı́tulo 11
Comunicaciones seguras
En el interior y exterior de las redes de nuestro sistema pueden existir múltiples peligros acechandonos
detras de cada switch o router, es necesario proteger nuestras conexiones y las de nuestros usuarios para
que no sean escuchadas por usuarios no autorizados o si esto no lo podemos asegurar, al menos que les
sean incomprensibles.
11.1. Shell seguro: OpenSSH

SSH es una herramienta de acceso remoto que nos permite iniciar la sesión en un sistema remoto de
una forma segura. El talón de Aquiles de la mayorı́a de las redes es el hecho de que normalmente las
comunicaciones entre sistemas se pasan sobre una red en texto plano. Por lo tanto, podemos fortalecer las
máquinas individuales todo lo que deseemos, pero si iniciamos una sesión en ellas remotamente con un
programa de terminal inseguro, los ladrones pueden robar nuestras credenciales de registro con un sniffer
de red (escucha clandestina de paquetes de red). Después pueden iniciar una sesión sin ningún problema.
Una de las herramientas de acceso remoto más populares, Telnet, sufre esta deficiencia.
SSH soluciona el problema utilizando tanto la criptografı́a simétrica como la clave pública para cifrar
la sesión desde la primera pulsación de tecla. De este modo, todo el que esté escuchando su conexión
obtiene un sonido aleatorio. SSH no sólo proporciona confidencialidad para nuestros datos utilizando el
cifrado sino que además proporciona una sólida autenticación, que impide la suplantación de identidad,
esto lo hace utilizando certificados digitales para autenticar a los usuarios.
No hay que confundir SSH con SSL, es estándar de cifrado Web. Aunque ambos realizan la misma
función, SSH funciona con cualquier protocolo, mientras que SSL está diseñado principalmente para las
comunicaciones Web.
SSH también incluye SCP, un reemplazo seguro para RPC, la herramienta de copia remota, y SFTP un
reemplazo seguro para FTP. SSH también puede utilizarse para crear un túnel con otros protocolos entre
máquinas, como HTTP y SMTP. Al utilizar esta familia de programas en lugar de sus homólogos más
antiguos, nos aseguramos de que no se están leyendo nuestras comunicaciones remotas con los servidores.
Eliminar el uso de Telnet y FTP en nuestra red puede ser difı́cil, pero cuanto más lo hagamos, más
seguros estaremos.
11.1.1. Cliente OpenSSH

Para acceder al sistema remoto con SSH, necesitamos un cliente SSH en nuestro lado y tiene que existir
un servidor SSH ejecutándose en el lado remoto. Aunque SSH no está tan difundido como Telnet, poco a
poco se está haciendo más popular. Cisco está instalando SSH en sus enrutadores, aunque todavı́a deja
activado el servidor Telnet de forma predeterminada, mientras que SSH es opcional.
Debemos asegurarnos de estar utilizando una versión 3.6 o más actual; algunas versiones anteriores
tenı́an fallos en su implantación de protocolos criptográficos y son susceptibles de ataques. De hecho,
es recomendable asegurarse de tener la útima versión disponible, ya que el código se está mejorando
constantemente y los algoritmos se están ajustando.
SSH tiene un número de usos realmente interesantes distintos a asegurar un inicio de sesión en un
sistema remoto. Se puede utilizar para crear un túnel para cualquier servicio a través de un canal cifrado
entre servidores.
Para instalarlo en nuestro sistema hay que realizar un apt-get:

#apt-get install openssh-client-udeb
La sintaxis SSH básica para iniciar una sesión remotamente es:

$ssh -l login hotname
Donde login es su nombre de usuario en el sistema remoto y hotname es el anfitrión al que está inten-
tando conectar con SSH. También se puede utilizar:
$ssh login@hostname
Por lo tanto y a modo de ejemplo, para registrarse en el servidor Web denominado web.example.com
utilizando el nombre de inicio de sesión de josan, tendrı́amos que escribir:
$ssh josan@web.example.com
También podemos utilizar, $ssh -l josan web.example.com para iniciar la sesión. Si simplemente
escribirmos $ssh web.example.com, el servidor supondrá que el nombre del usuario es igual que el del
inicio de sesión del sistema.
En la tabla 11.1 podemos encontrar el resto de opciones de SSH:
Cuadro 11.1: Opciones del cliente SSH

-c protocol Utiliza un protocolo criptográfico especı́fico (tiene que ser soportado por la versión que
utilizamos de SSH)
-p port# Se conoceta a un número de puerto especı́fico en lugar de la puerto SSH predeterminado
(puerto 22)
-P port# Usa un puierto especı́fico que no forma parte de la lista estándar de puertos propietarios, lo
que normalmente significa un número por encima de 1024. Esto puede ser útil si tenemos
un cortafuegos que imposibilita las comunicaciones en números de puertos inferiores.
-v Muestra la salida larga. Útil para la depuración
-q: Informa en modo silencioso, cdontrario del modo largo
-C: Utiliza compresión del tráfico cifrado. PUde ser útil para conexiones demasiado lentas,
como las telefónicas, pero es mejor tener un procesaro más potente para realizar la com-
presión o ralentizará mucho el rendimiento.
Si queremos personalizar nuestras conexiones, en el directorio /etc/ssh encontraremos los archivos de

configuración del servicio SSH. El archivo de configuración del cliente es /etc/ssh/ssh config.
11.1.2. Servidor OpenSSH

Para utilizar SSH debemos tener un cliente SSH ejecutándose en la máquina que deseamos conectar y
un servidor SSH en la máquina a la que deseamos conectarnos. Los clientes FTP y Telnet normales no se
conectarán a un servidor SSH. El cliente se encuentra integrado en la mayorı́a de los sistemas operativos
Linux actuales, aunque puede que tengamos que seleccionar esta opción al instalar el sistema. El servidor
SSH es normalmente opcional. Para determinar si ya está instalado, escribimos $ps y comprobamos si se
está ejecutando el proceso sshd. Si no se está ejecutando, tendremos que instalar el servidor para permitir
las conexiones de su máquina a través de SSH.

Capı́tulo 11. Comunicaciones seguras 179
Pasemos a describir el proceso de instalación del servidor de SSH.
1. Lo primero es instalar el paquete si no lo tenemos en el sistema:

#apt-get install openssh-server-udeb
2. Después hay que revisar los archivos de configuración que se encuentran en el directorio /etc/ssh
para asegurarse de que coincide con los parámetros de nuestro sistema. El archivo de configuración
para el servidor es /etc/ssh/sshd config.
A continuación detallo los campos que hay que revisar dentro de este archivo:
Port: Es el puerto que escucha SSH para las conexiones entrantes. Su valor predeterminado es
22. Si lo cambiamos, las personas que intenten conectarse con su sistema tendrán que cambiar
manualmente el número de puerto en sus clientes SSH.
Protocols: Le indican al servidor los protocolos SSH que debe aceptar. El valor predeterminado
es aceptar conexiones de tipo SSH1 y SSH2.
Hostkey: Claves para aceptar conexiones de clientes, proporciona la ubicación de las claves
utilizadas para generar la autenticación de clientes. Éstas no son las mismas claves que las
claves del servidor generadas en la instalación.
3. Antes de poder utilizar un servidor SSH tiene que generar sus distintas claves. Esto proporciona un
identificador único para las claves de servidor. Para ello hay que escribir el siguiente comando:
#ssh make-host-key
4. Ahora se puede iniciar el servidor SSH en la lı́nea de comandos escribiendo:

#sshd &
Ası́ se ejecutara el demonio del servidor SSH en segundo plano y escuchará continuamente las co-
nexiones. Si se desea ejecutar sshd automáticamente al inicio (opción muy recomendable), hay que
colocar dicha lı́nea al final de un archivo al estilo de rc.local de otras distribuciones (véase apéndice
D para componer este tipo de archivos).
También es posible facilitar la configuración mediante un módulo para la herramienta de administración

web Webmin. Para la instalación se utiliza el siguiente apt:
#apt-get install webmin-sshd
Puerto de envı́o con OpenSSH

Aunque SSH se diseñó en principio para una interacción de lı́nea de comandos tipo Telnet, también
se puede utilizar para configurar un túnel entre dos máquinas para cualquier aplicación. Podemos crear
una conexión segura entre dos servidores con la opción de puerto de envı́o integrada en SSH. Para realizar
esta tarea, debemos tener SSH ejecutándose en ambos extremos de la conexión.
Con la siguiente declaración emitida en el extremo del cliente podemos realizar cualquier servicio sobre
cualquier puerto:
#ssh -L local_port:local_host:remote_port remote_hostname -N &
Donde debemos reemplazar:
local port: Por un número aleatorio, mayor de 1024, elegido para realizar la nueva conexión cifrada
local host: Por la máquina local
remote port: Por el puerto del servicio con el que deseamos abrir un túnel en el extremo remoto

Figura 11.1: Interfaz gráfica Webmin para el servidor SSHD
remote hostname: Por la dirección IP o nombre del servidor en el otro extremo de la conexión
La opción -L le indica a SSH que debe escuchar el local port en local host y enviar cualquier conexión
a remote port en remote host.
La opción -N le indica a SSH que no intente iniciar la sesión, sólo mantener la conexión abierta para
el tráfico enviado.
Si se desea que esta configuración del sistema se mantenga en siguientes reinicios de la máquina hay
que añadirla a un archivo de rc.local como se especifica en la sección D.
Esto podrı́an ser ejemplos de este tipo de usos:

Si se necesita cifrar una conexión de correo electrónico:
#ssh -L 5000:localhost:25 192.168.0.1 -N &, . . . donde la IP corresponde al servidor de correo
de la red
Si se necesita crear una conexión web segura con SSH en vez de SSL:
#ssh -L 5000:localhost:80 192.168.0.1 -N &, . . . utilizando en el navegador localhost:5000 se
realizaran envı́os a través de túnel seguro con el puerto web(80) en la máquina remota.
También podemos tener varios puertos al mismo servidor, como es nuestro caso:
#ssh -L 5000:localhost:25 -L 5001:localhost:80 192.168.0.1 -N &

Como se puede observar, SSH funciona extraordinariamente bien para crear una conexión segura entre
dos máquinas para casi cualquier protocolo.
11.2. Criptografı́a y cifrado

Hoy en dı́a la solidez del cifrado normalmente se mide por el tamaño de su clave. Independientemente
de la solidez del algoritmo, los datos cifrados pueden estar sujetos a ataques por la fuerza en los que se
prueban todas las combinaciones posibles de claves. Al final, el cifrado se puede romper. Para la mayorı́a
de los códigos modernos con longitudes decentes, el tiempo para romper la clave a la fuerza se mide en
milenios. Sin embargo, un fallo inadvertido en un algoritmo o el avance en la tecnologı́a informática o en
los métodos matemáticos pueden reducir este tiempo considerablemente.
Normalmente se cree que la longitud de la clave debe ajustarse para mantener seguros los datos durante
una cantidad razonable de tiempo. Si el elemento es muy local, como las comunicaciones del campo de
batalla o la información diaria sobre las acciones, un código que proteja estos datos durante semanas o
meses está bien. Sin embargo, algo como número de tarjeta de crédito o los secretos de seguridad nacional
tienen que mantenerse seguros durante un periodo de tiempo más prolongado y de forma eficaz para
siempre. Por lo tanto, utilizar algoritmos de cifrado más débiles o longitudes de clave más cortas para
algunas cosas está bien, siempre que la utilidad de la información para un intruso expire en un breve
periodo de tiempo.
11.2.1. Tipos de cifrado

Criptografı́a simétrica
El primer tipo de cifrado, denominado criptografı́a simétrica, o cifrado de secreto compartido, se ha
estado utilizando desde la época de los antiguos egipcios. Esta forma de cifrado utiliza una clave secreta,
denominada secreto compartido, para cifrar los datos en un galimatı́as inteligible. La persona que se
encuentra en el otro extremo necesita la clave compartida para desbloquear los datos (el algoritmo de
cifrado). Podemos cambiar la clave y los resultados del cifrado. Se denomina criptografı́a simétrica porque
se utiliza la misma clave para ambos extremos tanto para cifrar como para descifrar los datos.
El problema que surge con este método es que tenemos que comunicar la clave secreta de una for-
ma segura al destinatario pretendido. Si nuestro enemigo intercepta la clave, puede leer el mensaje. Se
han inventado todo tipo de sistemas para intentar solucionar esta fragilidad básica, pero el hecho sigue
existiendo: tendremos que comunicar la clave secreta de alguna forma al destinatario pretendido antes de
iniciar una comunicación segura.
Criptografı́a asimétrica
Una revolución en el cifrado fue la iniciada cuando Whitfield Diffie, Martin Hellman y Ralph Merkle
inventaron la criptografı́a de calve pública. (En realidad, todavı́a existe algún debate sobre si el británico
James Ellis en realidad inventó esta clave antes y la mantuvo en secreto, pero Diffie, Hellman y Merkle
fueron los primeros en publicarla en 1976).
Estaban tratando de resolver el antiguo problema del intercambio de clave. Diffie se preguntaba cómo
dos individuos que deseaban realizar una transacción financiera por una red electrónica podı́an hacerlo con
seguridad. Llevaba mucho tiempo pensando en ello porque Internet estaba naciendo en aquél momento
y el comercio electrónico todavı́a no existı́a. Si los gobiernos tenı́an muchos problemas tratando con el
problema del intercambio de clave, ¿cómo podrı́a controlarlo una persona media? Querı́a llegar a crear
un sistema por el que las dos partes pudiesen mantener conversaciones protegidas y realizar transacciones
seguras sin tener que intercambiarse una clave cada vez. Sabı́a que si resolvı́a el problema del intercambio
de claves, serı́a un gran avance en la criptografı́a.
Diffie se asoció con Martin Hellman y Ralph Merkle. Tardaron algunos años, pero finalmente consi-
guieron crear un sistema denominado Cifrado de clave pública (PKE, Public Key Encription), también
conocido como Criptografı́a asimetrica.
La criptografı́a asimétrica utiliza un cifrado que divide la clave en dos claves más pequeñas. Una de
las claves se hace pública y otra sigue siendo privada. El mensaje lo ciframos con la clave pública del

destinatario. Éste puede descifrarla a continuación con su propia clave privada. Y lo mismo pueden hacer
por nosotros, cifrando un mensaje con nuestra clave pública para poderlo descifrar con nuestra clave
privada. La diferencia es que nadie necesita la clave privada de nadie para enviar un mensaje seguro.
Utilizamos su clave pública, que no tiene que mantenerse segura (de hecho, se publican en repositorios
como si fueran una guı́a telefónica). Al utilizar la clave pública del destinatario, sabemos que sólo esa
persona puede descifrarlo utilizando su propia clave privada. Este sistema permite que dos entidades se
comuniquen con seguridad sin ningún intercambio anterior de claves.
Normalmente la criptografı́a asimétrica se implanta mediante el uso de funciones de un sentido. En
términos matemáticos, éstas son funciones fáciles de calcular en una dirección pero muy difı́ciles de calcular
a la inversa. De esta forma podemos publicar nuestra clave pública, derivada a partir de nuestra clave
privada, una tarea muy difı́cil de llevar a cabo al revés para determinar la clave privada. Una función
común de un sólo sentido utilizada actualmente, es la descomposición en factores de números primos
grandes. Es fácil multiplicar dos números primos y obtener un producto. Sin embargo, determinar cuál de
las muchas posibilidades son los dos factores de un producto es uno de los problemas matemáticos más
complejos (su tiempo de computación es NP-Completo1 ).
Si alguien inventase un método para deducir fácilmente factores de números primos grandes2 en tiem-
po de computación lineal o polinómico, darı́a al traste con el mecanismo de cifrado de claves públicas
actual, haciendo que cualquier tipo de comunicación basada en este tipo de algoritmos resultase insegura.
Afortunadamente, otras funciones de un solo sentido funcionan bien para este tipo de aplicación, como los
cálculos sobre curvas elı́pticas o el cálculo de logaritmos inversos sobre un campo finito.
Poco después del lanzamiento de Diffie, Hellman y Merkle, otro grupo de tres hombres desarrolló una
aplicación práctica de la teorı́a. Su sistema para el cifrado público se denominó RSA, por sus nombres:
Ronald Rivest, Adi Shamir y Leonard Adleman. Formaron una empresa que empezó a regular su sistema.
La velocidad de adopción era lenta y su empresa estuvo a punto de quebrar, hasta que llegó el momento
de aprovechar el emergente campo comercial de Internet con una empresa, entonces pequeña denominada
Netscape. El resto es historia y ahora RSA es el algoritmo de cifrado de clave pública más utilizado. Diffie
y Hellman finalmente lanzaron una aplicación práctica de su propiedad, pero sólo útil para intercambios
de clave, mientras que RSA puede realizar la autenticación y el no reconocimiento.
Panorama actual
Hoy en dı́a, el cifrado de clave pública se encuentra detrás de cada servidor web que nos ofrece una
compra segura. Nuestra transacción se cifra sin tener que dar ni obtener una clave secreta y todo se
produce en segundo plano. Como usuarios, lo único que conocemos es ese pequeño sı́mbolo de candado
SSL que se muestra en nuestro explorador para sentirnos seguros. No se puede imaginar el efecto que
tendrı́a sobre el comercio de Internet si cada vez que deseáramos comprar algo online tuviésemos que
pensar en una clave secreta, cifrar el mensaje y comunicar posteriormente de alguna forma dicha clave
a la otra parte. Evidentemente, el comercio electrónico no existirı́a tal y como existe actualmente si no
existiese la criptografı́a de clave pública.
Por lo general las aplicaciones, combinan los dos tipos de criptografı́a. Utilizan primeramente cripto-
grafı́a de clave pública para acordar una clave simétrica aleatoria. Esta clave simétrica es una clave de
sesión y sirve para realizar más rápidamente el cifrado y descifrado de la información que se mandan, ya
que tiene un coste computacional mucho mas bajo.
Existen muchos algoritmos de cifrado, protocolos y aplicaciones diferentes basadas en estos dos tipos
principales de cifrado. Las siguientes secciones explican algunos de estos tipos.
11.2.2. Estándares generales

El estándar de cifrado de datos (DES, Data Encryption Standar) es el estándar original que el gobierno
de los Estados Unidos empezó a promover para su uso gubernamental y comercial. Pensado originalmente
para se prácticamente inquebrantable en los años setenta, el aumento en potencia y el descenso en costo
1 Denominación que se le da en informática teórica a los problemas más dificeles de calcular, que necesitan un tiempo
exponencial para su resolución).

2 Esto no es algo descabellado, hace muy pocos años se ha conseguido desarrollar un algoritmo que resuelve el problema
de si un n.o tiene factores, en tiempo de computación polinomico.

de la informática hicieron que su funcionalidad de clave de 56 bits quedase obsoleta para información muy
confidencial. Sin embargo, todavı́a se sigue utilizando en muchos productos comerciales y se considera
aceptable para las aplicaciones de seguridad inferior. También se utiliza en productos que tienen proce-
sadores más lentos, como las tarjetas inteligentes y los dispositivos que no procesan un tamaño de clave
más largo.
TripleDES
También llamado 3DES es la versión DES más moderna y actualizada, su nombre implica lo que hace.
Ejecuta DES tres veces en los datos en tres fases: cifrado, descifrado y cifrado de nuevo. En realidad no
multiplica por tres la solidez de su código (la primera clave de código se utiliza dos veces para cifrar los
resultados del proceso), pero sigue teniendo una longitud de clave efectiva de 168 bits, bastante solidez
para la mayorı́a de usos.
RC4, RC5 y RC6

Este algoritmo de cifrado fue desarrollado por Ronald Rivest, uno de los desarrolladores de RSA, la
primera aplicación gráfica de criptografı́a pública. Se han realizado mejoras a lo largo del tiempo para
hacerla más sólida y solucionar problemas menores. La versión actual, RC6, permite una clave de 2.040
bits de tamaño y un tamaño de bloque variable de hasta 128 bits.
AES
Cuando el gobierno de los Estados Unidos se dio cuenta de que DES terminarı́a llegando al final de
su vida útil, empezó a buscar un sustituto. Hubo muchos competidores, incluyendo RC6, Blowfish del
reconocido criptógrafo Bruce Schneier y otros algoritmos meritorios. El concurso se resolvió a favor de
AES, basado en un algoritmo denominado Rijindael diseñado por dos criptógrafos belgas. Este hecho es
importante porque se utilizó una competición abierta para decidir el estándar. Asimismo, al seleccionar
un algoritmo de dos desarrolladores no norteamericanos sin intereses comerciales significativos ayudaba a
legitimar esta selección por todo el mundo. AES se está convirtiendo rápidamente en el nuevo estándar del
cifrado. Ofrece una clave de hasta 256 bits, algo más que suficiente para el futuro previsible. Normalmente,
AES se implanta en modo de 128 o 192 bits.
11.2.3. Aplicaciones de la criptografı́a

Hash
Los hash son funciones especiales de sentido único que proporcionan autenticación y verificación uti-
lizando el cifrado. Una función hash recoge un archivo y lo coloca en una función para que se produzca
un archivo de tamaño, en conjunto, mucho más pequeño. Al hacerlo, se produce una huella digital única,
lo que nos proporciona una forma segura de saber que el archivo no se ha alterado de ninguna manera.
Al utilizar una función hash para un archivo sospechoso y comparar su huella digital con la huella digital
correcta, podremos saber si se ha producido algún cambio en el archivo. Es muy poco probable que un
archivo con una estructura diferente produzca una huella idéntica. Incluso si cambia uno de los caracteres,
se cambia la huella digital significativamente. Las posibilidades de que dos archivos diferentes produzcan
el mismo hash son infinitesimales.
Normalmente los hash se proporcionan en versiones descargadas de software para asegurarse de que
está obteniendo el software real, algo importante, especialmente con el software de libre distribución que se
puede descargar desde réplicas de los servidores oficiales. El sitio web oficial normalmente incluye el hash
correcto de la última versión. Si ambos no coinciden, sabremos que se han producido cambios, posiblemente
sin el permiso o el conocimiento de los desarrolladores del software. El algoritmo hash más conocido se
denomina MD5.
Cuando se instala el sistema, se pregunta al usuario que algoritmo hash quiere usar para las contraseñas.
Es muy recomendable establecer MD5 como predeterminado, ya que actualmente se le considera uno de
los mejores algoritmos de hash.

Certificados digitales
Los certificados digitales son las “firmas” del mundo comercial en Internet. Utilizan una combinación de
tipos de cifrado para proporcionar autenticación y comprueban que quien se está conectando es realmente
quien dice ser. En resumen, un certificado es una “certificación” expedida por una autoridad de la que nos
fiemos y que permite fiarnos de la veracidad de lo que nos esta contando el titular del certificado.
Un certificado contiene la clave pública de la organización cifrada con la clave privada o la clave
pública de una autoridad de firmas. El uso de una autoridad de certificados o firmas se considera el
método más seguro de los dos. Si podemos descifrar el certificado con su clave publica, podremos suponer
razonablemente que el sitio web pertenece a dicha organización.
Normalmente, los certificados se unen a un dominio determinado. Pueden ser emitidos por una entidad
central, o creados y firmados localmente. Existen varias organizaciones de este tipo, entre ellas VeriSign,
la empresa que además se encarga del sistema de nombres de dominio en Internet. Estas organizaciones
han sancionado a otras muchas empresas por ofrecer certificados de su parte, sin regulación de ningun
tipo. Obtener un certificado de VeriSign o de una de las empresas autorizadas es como si respondieran por
nosotros. Generalmente, no emitirán un certificado hasta que verifiquen la información incluida en él, bien
por vı́a telefónica o bien por otro medio de documentación en papel, como un contrato corporativo en el
que se pide autenticación en persona. Cuando han “certificado” que nuestra información es correcta, cogen
esta información, incluyendo los URL que vamos a utilizar para el certificado y la “firman” digitalmente
cifrándola con su clave privada. Después, un servidor Web o cualquier programa podrán utilizar este
certificado.
Las entidades de certificación descentralizan su misión en entidades de certificación locales en las que
confian. En Cataluña esta entidad es la Agencia Catalana de certificaciones, CATCERT.
En su página web podemos encontrar más información: http://www.catcert.net
Cuando los usuarios externos reciben datos, como una página web del servidor, y adjunta un certificado,
pueden utilizar la criptografı́a de clave pública para descifrar el certificado y verificar nuestra identidad.
Se utilizan principalmente en los sitios de comercio electrónico, pero también se utilizan en cualquier otra
forma de comunicación. Programas como SSH y Nessus pueden utilizar certificados para la autenticación.
Las VPN o las redes inalámbricas también pueden utilizar certificados para la autenticación en lugar de
contraseñas.
11.2.4. Protocolos de cifrado

Un hecho bien conocido es que el protocolo IP tal y como se diseño originalmente no era muy seguro.
La versión 4 de IP (IPv4), utilizado por casi todo el mundo de la comunicación con IP, no proporciona
ningún tipo de autenticación ni confidencialidad. Las cargas útiles del paquete se envı́an al descubierto y
los encabezados del paquete se pueden modificar fácilmente ya que no se verifican en el destino. Muchos
ataques de Internet se basan en esta inseguridad básica de la infraestructura de Internet. Para proporcionar
autenticación y confidencialidad a través del cifrado, se ha desarrollado un nuevo estándar IP denominado
IPv6. Además, amplı́a el espacio de dirección IP utilizando una dirección de 128 bits en lugar de 32 bits
y mejora además otros elementos.
La implantación completa del estándar IPv6 requiere actualizaciones de hardware a amplia escala, por
lo que el despliegue de IPv6 esta siendo bastante lento. Mientras no se acabe de implantar existen una
serie de protocolos que nos permiten tener una cierta seguridad.
IPsec
Para solventar los problemas de IPv4 se desarrollo una implantación de seguridad para IP, denominada
IPsec, que no requerı́a cambios importantes en el esquema del direccionamiento. Los suministradores de
hardware se aferraron a ello, convirtiéndose IPsec poco a poco en un estándar de hecho para crear VPNs
en Internet.
No es un algoritmo de cifrado especı́fico, sino una estructura para cifrar y verificar paquetes dentro del
protocolo IP. Puede utilizar diversos algoritmos y puede implantarse total o parcialmente. Para codificar
el contenido del paquete se utiliza una combinación de clave pública y privada y además los hash añaden

también autenticación. Esta función se denomina encabezado de autenticación (AH, Autentication Hea-
der). Con AH, un hash se crea a partir del encabezado IP y éste pasa adelante. Cuando el paquete llega a
su destino, se crea un nuevo hash a partir de cada encabezado. Si no es comparable al enviado, sabrá que
el encabezado se ha alterado de alguna manera durante el tránsito, lo que nos proporciona un alto nivel de
garantı́a de que el paquete proviene de donde dice. Podemos elegir descifrar la carga útil pero no ejecutar
un AH ya que puede ralentizar el procesamiento. AH también puede estropearse en algunos entornos con
NAT o cortafuegos.
Existen otros dos modos de operación diferentes en los que podemos ejecutar IPsec: en modo túnel o
en modo transporte.
En modo túnel, todo el paquete (encabezados incluidos) se encapsula y se cifra, se coloca en otro
paquete y se remite al procesador VPN central. Los extremos finales descifran los paquetes y después los
envı́an al IP correcto. Una de las ventajas de utilizar este método es que los usuarios externos pueden
saber incluso cuál es el destino final del paquete cifrado. Otra ventaja es que VPN puede controlarse y
administrarse desde pocos puntos centrales. El inconveniente es que requiere un hardware dedicado en
ambos extremos para abrir el túnel.
En modo de transporte sólo se cifran las cargas útiles del paquete; los encabezados se envı́an intactos,
lo que produce un despliegue más facil y requiere menos infraestructura. Podemos seguir ejecutando AH
cuando utilicemos el modo de transporte y verificar la dirección de origen de los paquetes.
PPTP: Protocolo de túnel punto a punto

El protocolo PPTP (Point-to-Point Tunneling Protocol) es un estándar desarrollado por Microsoft,
3Com y otras grandes empresas que proporcionan cifrado. En PPTP se han descubierto algunos fallos
importantes que limitan su aceptación. Cuando Microsoft implemento IPsec en Windows 2000, parecı́a
una admisión tácita que IPsec habı́a ganado como nuevo estándar de cifrado. Sin embargo, PPTP sigue
siendo un protocolo útil y económico para configurar VPN entre los PC más antiguos de Windows.
L2TP: Protocolo de túnel de dos capas

El protocolo L2TP (Layer Two Tunneling Protocol) es otro protocolo desarrollado para la industria
y firmado por Microsoft y Cisco. Aunque se utiliza frecuentemente en dispositivos de cifrado basados en
hardware, su uso en software es relativamente limitado.
SSL: Capa segura de Sockets

El protocolo SSL (Secure Socket Layer) se diseñó especı́ficamente para su uso en la Web (ApacheSSL
que explico en el proyecto lo contempla), aunque puede utilizarse en cualquier tipo de comunicación TCP.
Originalmente lo diseño Netscape para que su explorador ayudase a la simulación de comercio electrónico.
SSL proporciona cifrado de datos, autenticación en ambos extremos e integridad de mensajes utilizando
certificados.
Normalmente, SSL se utiliza cuando se realiza una conexión a un servidor web para que sepa que la
información que enviamos se protege a lo largo del trayecto. La mayorı́a de las personas ni siquiera se dan
cuenta de que SSL se está ejecutando en segundo plano. Normalmente sólo autentica un extremo, la parte
del servidor, ya que la mayorı́a de usuarios finales no tienen certificados.
11.2.5. OpenPGP: Aplicación de cifrado

El estandar PGP (Pretty Good Privacy o privacidad bastante buena), en el que esta basado OpenPGP,
se creo para proteger la información de los usuarios ante miradas indiscretas.
Historia del PGP

Phil Zimmerman es un programador muy implicado en los derechos humanos. Le preocupaba que el uso
creciente de los ordenadores y de las redes de comunicación facilitase a las agencias de seguridad estatales
de regı́menes represivos la interceptación y recopilación de información sobre los disidentes. Phil querı́a
escribir algún software que ayudase a dichas personas a mantener su información privada y segura frente

a los brutales regimenes que los controlaban. Este software podı́a salvar literalmente la vida de algunas
personas. Tampoco creı́a que su propio gobierno no observara sus datos personales cuando se desplazaban
por redes interconectadas. Sabı́a lo fácil que podı́a ser para el gobierno crear sistemas para buscar cada
lı́nea de los mensajes de correo electrónico para determinadas palabras clave. Deseaba proporcionar a las
personas una forma de proteger y garantizar su derecho constitucional a la privacidad.
Este software lo denominó Pretty Good Privacy (PGP), algo ası́ como una Privacidad bastante buena,
ya que creı́a que hacı́a una buena labor a la hora de proteger los datos ante los servicios de inteligencia de
los paı́ses más pequeños. Sin embargo, la agencia de la información de los Estados Unidos, NSA, no lo veı́a
de esa forma. Zimmerman fue investigado por infringir las leyes federales de exportación de munición por
permitir que su software se descargase fuera del paı́s. Originalmente, Phil pretendı́a buscar una empresa
que vendiera su innovación. Sin embargo, cuando el gobierno inició su persecución, distribuyó libremente
el software por Internet para que se distribuyese por todas partes. Posteriormente formó una empresa para
vender las versiones comerciales del software pero existen implantaciones de libre distribución de PGP
por todo Internet. Algunas de éstas son mas populares que otras y algunas son aplicaciones que tienen
funciones especı́ficas como el cifrado de mensajes de correo electrónico. Se pueden encontrar una lista de
todas estas implementaciones de PGP en http://www.cypherspace.org/openpgp/.
GnuPG: GNU Privacy Guard

En el servidor he utilizado GnuPG, una de las implementaciones bajo licencia GPL basada en el
estandar OpenPGP.
La gran ventaja de la versión Gnu a la versión PGP comercial es que se encuentra bajo licencia GPL
y por lo tanto podemos utilizarla para cualquier aplicación, comercial o personal, asi como ampliarla o
insertarla como queramos. El inconveniente es que se trata de una herramienta de lı́nea de comandos,
por lo que no tiene los bonitos complementos que ofrece la versión comercial de PGP. No obstante hay
que tener cuidado, GnuPG probablemente no sea la mejor opción para usuarios no técnicos, a no ser que
añadamos su propia interfaz (Gnome dispone de una).
Para comprobar la versión:

$gpg --version
Si no lo tenemos instalado, hay que ejecutar algunas sentencias apt:

#apt-get instal gnupg, . . . Programa GnuPG
#apt-get instal gpgp, . . . interfaz Gnome para GnuPG
Crear pares de claves
Si ya las tiene creadas y quiere importarlas, #gpg --import path/filename. Si tiene separadas la
clave pública y privada, el formato de archivo suele ser pubring.pkr y secring.skr
Si se han de crear:
1. Escribimos: #gpg --gen-key y seguimos las instrucciones de pantalla

2. GnuPG pide el tamaño de bits de sus claves. El predeterminado es 1.024, que generalmente se
considera suficiente para una criptografı́a sólida de clave pública. Podemos aumentar el tamaño
hasta 2.048 para una seguridad mucho mas fuerte.
3. Generalmente no se desea que las claves expiren, pero si tiene un caso especial en el que sólo
utilizará esta clave durante un tiempo limitado, se puede establecer una fecha de finalización.
4. Por último se pide que se introduzca una contraseña que sirva de frase de paso.
Atención: Es muy importante conservar copias de seguridad del par de claves en un lugar
seguro, en caso de perderlas, los datos cifrados se no se podrı́an recuperar.

$gpg --list-keys, . . . nos dara la lista de claves instaladas en el sistema.
En el home del usuario se crea un directorio oculto .gnupg donde se almacenarán los archivos.
Crear un certificado de revocación:
Una vez creadas las claves, también podemos crear un certificado de revocación que se utiliza si perdemos
nuestras claves o si alguien obtiene acceso a nuestra clave privada. Después podemos utilizar este certifi-
cado para revocar nuestra clave de los servidores públicos. Podemos seguir descifrando mensajes recibidos
utilizando la clave pública antigua (suponiendo que no la hayamos perdido) pero nadie podrá descifrar
ningún mensaje con las claves públicas incorrectas. Para crear un certificado:
$gpg --output revoke.asc --gen-revoke user
Donde se debe reemplazar user con la frase secreta de dicho usuario, asignada cuando generamos el
par de claves. Este certificado hay que eliminarlo del disco y guardarlo en lugar seguro, ya que si alguien
se hace con él, también podrı́a hacerse con el certificado de revocación.
Publicar la clave pública
Se puede colocar la clave pública en un servidor de claves para que cualquiera pueda encontrarla fácil-
mente y enviar mensajes. Para ello es necesario ejecutar el siguiente comando:
$gpg --keyserver server --send-keys user
Donde se debe reemplazar server con el nombre de un servidor de claves públicas y user con la dirección
de correo electrónico de la clave que desea publicar. Puede utilizar cualquier servidor de claves públicas
PGP ya que todos se sincronizan con frecuencia. Existen muchos servidores de claves públicas, como por
ejemplo: pgp.mit.edu, certserver.pgp.com y usa.keyserver.net.

Cifrar archivos con GnuPG
Para cifrar un archivo se utiliza el comando:

$gpg --output file.gpg --encrypt --recipient friend@example.com file.doc
Reemplanzando file.gpg con el nombre de archivo resultante deseado, friend@example.com con la di-
rección de correo electrónico del usuario al que está realizando el envı́o y file.doc por el arcivo que se desea
cifrar. Tenga en cuenta que tiene que tener la clave pública del destinatario en su repositorio para poder
hacerlo.
También se puede utilizar GnuPG para cifrar archivos con una criptografı́a simétrica, que puede utilizar
para sus archivos locales que desea proteger o para alguien del que no tiene su clave pública. Para ello,
utilice el comando:
$gpg --output file.gpg --symmetric file.doc
Reemplazado file.gpg con el archivo de salida deseado y file.doc con el nombre del archivo que desea
cifrar.
Descifrar archivos
Para utilizar GnuPG para descifrar archivos recibidos, utilizamos el siguiente comando:
$gpg --output file.doc --decrypt file.gpg
Reemplazando file.doc con el nombre del archivo resultante deseado y siendo file.gpg el archivo cifrado.
Tenemos que tener la clave pública del usuario para el que se ha realizado el cifrado en nuestro repositorio.
Un mensaje solicitará la frase de contraseña y, una vez introducida correctamente, GnuPG producirá el
archivo descifrado.
Firmar archivos
Tal y como he mencionado anteriormente, otro uso de GnuPG y PGP es firmar documentos para
verificar su integridad, algo que podemos hacer con el siguiente comando:
$gpg --output signed.doc --sign unsigned.doc
Siendo signed.doc el nombre de archivo de salida resultante deseado y unsigned.doc el archivo a firmar.
Este comando firma y cifra el documento y después procesa el archivo de salida signed.doc. Cuando se
descifra, GnuPG también verificará el documento.
Para verificar el archivo se utiliza el comando:

$gpg --verify signed.doc
Siendo signed.doc el archivo cifrado que desea verificar. También podemos crear firmas separadas
del archivo para poder acceder a usuarios sin GnuPG e incluir la firma. Éstos son los comandos para
conseguirlo:
$gpg --clearsign file.doc
Crea un apéndice de texto al archivo con la firma. Si no desea alterar el archivo, puede crear un archivo
de firma separado, para dejar almacenada la firma o mandarla por separado, con el comando:
$gpg --output sig.doc --detached-sig file.doc

Web de modelo de confianza de PGP/GnuPG
Tal y como hemos mencionado anteriormente, en lugar de utilizar un sistema de confianza jerárqui-
co como los certificados digitales y su autoridad de certificados central, PGP y GnuPG utilizan una web
de modelo de confianza. Al firmar las claves de las personas que conoce, puede verificar que sus claves
son de confianza. Y si firman las claves de otras personas que no conoce directamente, se crea una cadena
de confianza. El modelo se basa en la idea de que “cualquier amigo suyo es un amigo mı́o”. En realidad
este modelo no funciona perfectamente; en algún lugar en la parte inferior de la cadena podrı́a haber una
manzana podrida, pero la idea que se esconde detrás del sistema es que se propaga orgánicamente y no
requiere ninguna estructura. Debido a ello puede desmantelarse o formarse fácilmente a gran escala. La
forma de establecer esta web de confianza es firmar las claves de las personas y dejar que ellos firmen la
suya propia.
Firmar claves y administrar claves de confianza
En GnuPG, firmamos y administramos claves de confianza entrando en el modo de edición de la clave

con el siguiente comando:
gpg --edit-key friend@example.org
Donde friend@example.org coincide con la dirección de correo electrónico de la clave que desea fir-
mar o administrar, tiene que ser una de la claves que tenemos en el repositorio. Este comando imprime
información básica sobre la clave. Dentro de este modo escriba fpr para imprimir la huella dactilar de
la clave. Igual que las personas, la huella dactilar de la clave es un identificador especı́fico para dicha
clave. Asegúrese de que se trata de la clave de la persona en concreto comparándola con dicha persona
por teléfono o por cualquier otro medio de comunicación. También puede comprobar si alguien más ha
firmado esta clave escribiendo check. Este comando imprime una lista de otros firmantes de esta clave y
puede ayudarla a decidir la validez de la misma.
Cuando se quiere asegurar de que se trata de la clave de una persona en concreto, escriba sign. Este
comando firma la clave de dicha persona para que cualquiera que la esté buscando sepa que confı́a en ella.
En este modo también puede editar los niveles de las diferentes claves en su repositorio. Se introduce este
modo dentro del modo de edición de la clave escribiendo trust.
Ası́ se muestra el siguiente menú:

1=Don’t know (No la conozco).
2=I do NOT trust (No confio en ella).
3=I trust marginally (Confio en ella un poco).
4=I trust fully (confio en ella plenamente).
d=Please show me more information (Mostrar mas detalles).
m=Back to the main menu (Volver al menu principal).
Al escoger uno de los elementos, dicha clave se marcará como realizada por nosotros. Ésta es otra
forma de poderse comunicar con otros a cerca de los usuarios que tienen su nivel más alto de confianza y
cuáles son usuarios en los que confı́a poco.
PGP y GnuPG son extraordinarios para cifrar archivos. Sin embargo, ¿y si desea cifrar todas las co-
municaciones entre dos puntos? PGP no es en realidad viable para esta función, esto es realizado por el
SSH, explicado en la sección anterior.
Existen muchı́simas más opciones que se pueden consultar con: $man gpg

Capı́tulo 12
Herramientas de seguridad
12.1. Herramientas básicas

Existen varios comandos de sistema operativo que utilizaremos con frecuencia en nuestra labor de
asegurar la seguridad. No son programas de seguridad completamente independientes, sino utilidades del
sistema operativo que se pueden utilizar para generar información de seguridad.
12.1.1. Ping
Ping (Packet Internet Groper, que se pude traducir como buscador de paquetes en Internet) es una
herramienta de diagnóstico TCP/IP. Muchos creen que el ping es como un radar submarino: un ping sale,
rebota en un destino y vuelve. Aunque se trate de una buena analogı́a general, no describe exactamente
lo que sucede cuando incluimos un ping en una máquina. Los ping utilizan un protocolo de red denomi-
nado ICMP (Internet Control Message Protocol, o Protocolo de mensajes de control de Internet). Estos
mensajes se utilizan para enviar información sobre redes. Ping utiliza los tipos de mensaje ICMP 8 y 0,
conocidos también como Solicitud de eco y Contestación de eco respectivamente. Cuando utilizamos el co-
mando ping, la máquina envı́a una solicitud de eco a otra máquina. Si se puede acceder a la máquina que se
encuentra en el otro extremo y se ejecuta una pila TCP conforme, responderá con una contestación de eco.
Básicamente, las comunicaciones en un ping tienen la siguiente apariencia:
El sistema A envı́a un ping al sistema B: solicitud de eco, “¿Estás ahı́?”
El sistema B recibe la solicitud de eco y envı́a una contestación de eco: “Si, estoy aquı́”
En una sesión ping tı́pica, este proceso se repite varias veces para comprobar si la máquina de destino
o la red están bajando paquetes. Tambieén se puede utilizar para determinar la latencia, el tiempo que
tardan los paquetes entre dos puntos.
También podemos obtener estos otros tipos de mensajes ICMP cuando mandamos un ping. Cada uno
tiene us propio significado.
Red inalcanzable
Anfitrión inalcanzable
Con un ping podemos saber algo más sobre un anfitrión que si simplemente está activo o no. La forma en
que una máquina responde a un ping, normalmente, identifica el sistema operativo que está ejecutando.
También podemos utilizar ping para generar una solicitud de búsqueda DNS, que nos proporciona el
nombre del anfitrión de destino (si lo tiene), que a veces puede decirnos si esta máquina es un servidor,
un enrutador o quizá una conexión telefónica o conexión de ancho de banda. Podemos mandar un ping a
una dirección IP o a un nombre de dominio.
Cuadro 12.1: Opciones del comando ping

-c count Establece un número de pings deteminado, por defecto es infinito
-f Flujo de los ping. Envı́a tantos paquetes como puede, tan rápido como puede. Útil para
comprobar si un anfitrión esta bajando paquetes porque mostrará gráficamente a cuántos
ping responde. Hay que tener cuidado con esta opción porque puede producir la caida
de la red por DoS (denegación de servicio)
-n No ejecuta DNS en la dirección IP. Puede aumentar la velocidad de una respuesta y
cancelar los problemas de DNS cuando existen problemas de diagnóstico de la red
-s size Envı́a paquetes de longitud size. Útil para probar cómo manipula los paquetes grandes
una máquina o un enrutador. Irregularmente, los paquetes grandes se utilizan en ataques
de denegación de servicios para hacer caer una máquina o desbordarla
-p pattern Envı́a un patrón especı́fico en el paquete ICMP de carga útil. También es útil para probar
cómo responde una máquina a un estı́mulo ICMP inusual
La tabla 12.1 incluye los modificadores y las opciones adicionales para el comando ping, que pueden
resultar útiles.
Un ejemplo de este comando podrı́a ser el siguiente:
# ping www.fib.upc.es
PING www.fib.upc.es (147.83.41.7): 56 data bytes
64 bytes from 147.83.41.7: icmp_seq=0 ttl=241 time=66.3 ms
--- www.fib.upc.es ping statistics ---

6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 61.5/83.4/130.4 ms
12.1.2. Traceroute
Si no lo tenemos instalado basta con hacer:
#apt-get install traceroute
Este comando es similar a ping pero proporciona más información sobre el anfitrión remoto. Bási-
camente, los pings que rastrean rutas (tracerotue) son anfitriones, pero cuando envı́an fuera el primer
paquete, establecen la configuración TTL (tiempo de vida) del paquete en uno. Esta configuración con-
trola la cantidad de puntos de conexión en el ordenador de la red que obtendrá antes de morir por lo que
el primer paquete sólo irá al primer enrutador o máquina más allá de la nuestra en Internet y después
devolverá un mensaje indicando que el paquete ha “expirado”. A continuación el siguiente paquete se
establece con un TTL de 2, y ası́ sucesivamente hasta llegar a nuestro objetivo, mostrándonos el trazado
virtual (la ruta) que siguen los paquetes. Se resuelve el nombre de cada anfitrión encontrado a lo largo
del camino para que podamos ver cómo cruza Internet el tráfico. Puede ser muy interesante comprobar
cómo un paquete pasa por diferentes paises antes de llegar a su destino una fracción de segundo después
y a veces, por caminos impensables y lejanos.
Esta herramienta es muy práctica cuando estamos intentando localizar el origen o la ubicación de un
intruso que hemos encontrado en nuestro logs o alertas. Podemos rastrear la ruta de la dirección IP y
saber varias cosas sobre dicha dirección. La salida puede indicarnos si se trata de un usuario doméstico

Capı́tulo 12. Herramientas de seguridad 193
o de un usuario que se encuentra dentro de una empresa, cuál es su ISP (para poder enviarle una queja
sobre el abuso), qué tipo de servicio tiene y lo rápido que es y dónde se encuentra geográficamente (a veces
depende de la capacidad de descripción de los puntos intermedios).
Para ver como funciona podemos ejecutar el siguiente ejemplo:

# traceroute www.fib.upc.es
traceroute to www.fib.upc.es (147.83.41.7), 30 hops max, 38 byte packets
1 (192.168.0.1) 0.480 ms 0.459 ms 0.408 ms
2 213.0.184.252 (213.0.184.252) 46.732 ms 47.016 ms 116.462 ms
3 213.0.190.22 (213.0.190.22) 48.833 ms 51.344 ms 47.850 ms
4 tbvia1-tbest1-1.nuria.telefonica-data.net (213.0.248.146) 47.108 ms 45.986 ms
5 213.0.254.242 (213.0.254.242) 47.335 ms 52.532 ms 51.392 ms
6 montseny-catnix.catnix.net (193.242.98.2) 61.530 ms 66.452 ms 61.101 ms
7 upc-anella.cesca.es (84.88.18.18) 63.990 ms 129.435 ms 64.099 ms
8 * * *
Como se puede observar, la lectura de traceroute es mas un arte que una ciencia, pero con el tiempo
se aprende a reconocer mejor el significado de las abreviaturas.
Traceroute nos ofrece mucha información para el seguimiento de una IP, si es el origen de una intrusión o
un ataque. Si identificamos el ISP, con el sitio web de la empresa podemos encontrar un número de telefono
o una dirección de correo y quejarnos. Los ISPs habitualmente finalizan su contrato de suministro con
el cliente malintencionado. También podemos utilizar el comando whois, para buscar contactos técnicos
especı́ficos para la empresa y organización.
12.1.3. Whois
El comando whois es útil para intentar localizar el contacto de alguien que está causando problemas
en nuestra red. Este comando consulta los servidores de nombre de dominio principales y devuelve toda
la información que tiene el registrador de nombres que le corresponda. Con esto podemos averiguar quién
es el propietario de un dominio.
Este comando es útil para ataques que provienen tanto de dentro de las redes de empresas como de los
ISP. De cualquier modo, podemos averiguar quién es la persona responsable de dicha red y comunicarle
nuestro problema. Esta solución no siempre es muy práctica, pero por lo menos podemos probar.
Su sintaxis es:
$whois domain-name.com, . . . donde domain-name.com es el nombre del dominio sobre el que estamos
buscando información.
Podemos observar esto en el siguiente ejemplo:

$whois www.google.com
Whois Server version 1.3
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
Server Name: WWW.GOOGLE.COM.TR

Registrar: TUCOWS INC.
Whois Server: whois.opensrs.net
Referral URL: http://domainhelp.tucows.com
Server Name: WWW.GOOGLE.COM.MX

Registrar: ENOM, INC.
Whois Server: whois.enom.com
Referral URL: http://www.enom.com
Server Name: WWW.GOOGLE.COM.BR

Registrar: ENOM, INC.
Whois Server: whois.enom.com
Referral URL: http://www.enom.com
Server Name: WWW.GOOGLE.COM.AU

Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE
Whois Server: whois.melbourneit.com
Referral URL: http://www.melbourneit.com
>>> Last update of whois database: Wed, 25 May 2005 08:39:49 EDT <<<

También nos puede pasar lo siguiente:

$whois www.fib.upc.es
Este TLD no dispone de servidor whois, pero puede acceder a la informacion de whois en
https://www.nic.es/ingles/
Con lo que, la única solución es buscar a mano en esa dirección. Solamente los dominios .com, .net y
.edu se encuentran incluidos en whois.
El comando whois normalmente muestra una lista de direcciones de correo electrónico, direcciones de
correo postal y, a veces, números telefónicos. Nos dice cuándo se creó el dominio y si se han hecho cambios
recientes en sus listados whois. Tambien muestra a los servidores de nombre de dominio responsables de
ese nombre de dominio. Se puede ampliar más esta información con el siguiente comando: dig.
Si administra dominios propios, debe asegurarse de que su listado whois está actualizado y es tan
genérico como pueda serlo. Al colocar direcciones de correo electrónico y nombre reales en los campos de
información, estamos proporcionando información que alguien del exterior puede aprovechar, ya sea para
una labor social como para atacar nuestros sistemas. Es mejor utilizar direcciones de correo electrónico
genéricas, dejando que los responsables reciban los mensajes enviados a esas direcciones de correo electróni-
co y evitar proporcionar una información valiosa sobre la estructura de nuestra organización técnica.
12.1.4. Dig
El comando dig consulta en el servidor de nombres determinada información sobre un dominio. Dig
es una versión actualizada del comando nslookup, que ha quedado desfasado. Podemos utilizarlo para
determinar los nombre de máquinas utilizados en una red, qué direcciones IP se unen a dichas máquinas,
cuál es su servidor de correo y otro tipo de información útil.
La sintaxis general es:

$dig @ server domain type
Donde server es el servidor DNS al que deseamos consultar, domain es el dominio sobre el que estamos
preguntando y type es el tipo de información deseada.
Como ejemplo podemos poner una dirección que viene en el manual:

$dig www.isc.org
; <<>> DiG 9.2.4 <<>> www.isc.org

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25173
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3
;; QUESTION SECTION:
;www.isc.org. IN A
;; ANSWER SECTION:
www.isc.org. 600 IN A 204.152.184.88
;; AUTHORITY SECTION:
isc.org. 3599 IN NS ns-ext.isc.org.
isc.org. 3599 IN NS ns-ext.lga1.isc.org.
isc.org. 3599 IN NS ns-ext.nrt1.isc.org.
isc.org. 3599 IN NS ns-ext.sth1.isc.org.
;; ADDITIONAL SECTION:
ns-ext.lga1.isc.org. 3599 IN A 192.228.91.19
ns-ext.nrt1.isc.org. 3599 IN A 192.228.90.19
ns-ext.sth1.isc.org. 3599 IN A 192.228.89.19
;; Query time: 696 msec

;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed May 25 21:30:18 2005
;; MSG SIZE rcvd: 192
En la tabla 12.2 podemos encontrar las opciones más usuales del comando dig.

Cuadro 12.2: Opciones del comando dig

AXFR Intenta obtener todo el archivo del archivo del dominio o de la “zona”. Actualmente algunos
servidores se han configurado para no admitir transferencias de archivos de zona, por lo que
puede que tengamos que preguntar por registros especı́ficos.
A Devuelve cualquier registro “A”. Los registros “A” son nombres de anfitrión individuales
sobre la red
MX Devuelve el nombre del anfitrión de correo registrado para dicho dominio. Es útil para
contactar con un administrador
CNAME Devuelve cualquier anfitrión CNAMED, conocidos como alias
ANY Devuelve cualquier información que puede generarse en el dominio. Algunas veces funciona
cuando falla AXFR
12.1.5. Finger
Finger es un antiguo comando Unix que ya no se utiliza pero que se sigue ejecutando en muchas
máquinas como servicio heredado. Originalmente se diseñó cuando Internet era un lugar cómodo y los
usuarios permitı́an que otras personas al otro lado del mundo conociesen sus datos.
La mayorı́a de los administradores lo eliminan de sus sistemas porque es una fuente de brechas de
seguridad, pero todavı́a existen muchos enrutadores que lo incluyen y algunos Unix lo mantienen por de-
fecto. Además a esto se une que muchos administradores se les olvida desinstalarlo o no saben cómo hacerlo.
El comando finger permite consultar, al sistema remoto, acerca de información de sus usuarios. La
sintaxis serı́a la siguiente:
$finger user@hotname.example.com
También podemos especificar una dirección IP como dominio. El resultado del finger, podrı́a ser usada
por una persona malintencionada para conseguir información más relevante mediante ingenierı́a social.
Otro uso de finger es enviar el comando sin un nombre de usuario. Ası́ se genera una lista de todos
los usuarios conectados actualmente. Con esto podemos saber quién está conectado y sus nombres reales
e incluso podemos saber si están inactivos y durante cuanto tiempo. Por último presenta una lista de las
estaciones y de donde provienen (si son locales o remotas), un usuario malicioso puede intentar secuestrar
una de esas sesiones inactivas. Los resultados del comando los podemos ver en el siguiente ejemplo:
$finger
Login Name Tty Idle Login Time Office Office Phone
josan Jose Antonio Escartin *:0 May 26 12:18
josan Jose Antonio Escartin pts/1 May 26 12:34 (:0.0)
Y después se puede utilizar para para averiguar más sobre un usuario:
$finger josan
Login: josan Name: Jose Antonio Escartin Vigo
Directory: /home/josan Shell: /bin/bash
On since Thu May 26 12:18 (CEST) on :0 (messages off)
On since Thu May 26 12:34 (CEST) on pts/1 from :0.0
No mail.
No Plan.
En este caso no hay demasiada información, pero otras veces podemos encontrar su correo electrónico,
su plan de trabajo e incluso proyectos en los que este trabajando actualmente.
También podemos hacer consultas sobre todos los que esten conectados con la siguiente opción:
$finger -l

12.2. Firewall o cortafuegos

Forman la primera lı́nea de defensa frente a los intrusos que quieren entrar en nuestra red corporativa.
Sin embargo, debido a la complejidad creciente y a la sofisticación de los atacantes, pueden ser unos meca-
nismos de defensa insuficientes si no se han configurado correctamente. Una lı́nea de configuración errónea
puede negar la protección que ofrece un cortafuegos. Un administrador muy ocupado que esté intentando
establecer el acceso para los empleados errará normalmente más en la parte de acceso en lugar de realizar
ahı́ un mejor esfuerzo para configurar la seguridad. Se necesita mucha revisión y paciencia a la hora de
establecer las reglas.
Los cortafuegos, se sitúan en la parte en la parte superior del sistema operativo y por lo tanto, pueden
ser vulnerables a todos los ataques normales a nivel de sistema operativo. Muchos cortafuegos utilizan un
servidor web como interfaz con otros usuarios y ası́ pueden aprovecharse también de las brechas en las
interfaces web. Asegurar estas defensas de primera lı́nea es crı́tico y debe ser una de nuestras primeras
prioridades.
Por otra parte un cortafuegos solo nos protege de los ataques exteriores, contra ataques interiores no
tiene nada que hacer. Debemos de asegurarnos de que nuestros sistemas están vigilados y no depender del
cortafuegos para toda la seguridad de nuestra red.
12.2.1. Polı́ticas de seguridad

En algún momento, preferiblemente antes de instalar el cortafuegos, debemos comentar por escrito
su proceso de actuación. Esto nos será muy útil para planificar la instalación y configuración. Este plan
documenta los procesos y procedimientos subyacentes para asegurarnos de que obtenemos un beneficio.
La instalación de un cortafuegos está muy bien, pero sin instalar los procesos apropiados, puede que no
esté ofreciendo a la organización la seguridad prometida.
Los siguientes pasos perfilan un proceso para la implantación y funcionamiento de un cortafuegos.
Desarrollar una polı́tica sobre el uso de la red
Trazar un mapa de los servicios internos y externos necesarios
Convertir la polı́tica sobre uso de la red y los servicios necesarios en reglas para el cortafuegos
Implantar y probar la funcionalidad y la seguridad. Después de esto podemos activar el cortafuegos

y sentarnos a esperar las quejas.
Revisar y probar las reglas del cortafuegos periódicamente.
Diseñar y utilizar un proceso como éste nos ayudará a garantizar que obtenemos mucho más de la
implantación de nuestro cortafuegos.
12.2.2. Modos de configuración

Existen dos formas de configurar un cortafuegos:
Permitir todo y bloquear lo que no deseemos
Denegar todo y añadir lo permitido
El método habitual, usado por la gran mayorı́a de administradores es empezar con “denegar todo” y
después añadir lo que deseamos permitir a los usuarios. Automáticamente bloqueamos todo el tráfico, a
no ser que se admita en la configuración especı́ficamente.
Para la mayorı́a de los sitios, la solución “denegar todo” es mucho mas seguro. Sin embargo, sólo
porque optemos por esta solución no significa que nuestra red sea totalmente segura. Los ataques pueden
provenir a través de cualquier brecha que hayamos creado, como la web y el correo electrónico.

12.2.3. IPTables
Esta sección describe cómo se configura un cortafuegos con IPTables, que es la utilidad integrada en la
mayorı́a de los sistema Linux 2.4 y posteriores. Esta utilidad nos permite crear un cortafuegos empleando
comandos de nuestro sistema operativo.
Es una herramienta muy eficaz, pero compleja, y normalmente se recomienda para usuarios que estén
familiarizados con los cortafuegos y con el arte de configurarlos. Si es nuestro primer cortafuegos, es mejor
utilizar una de las herramientas de configuración automática disponibles para crear la configuración, al
menos al principio. Estas herramientas utilizan IPTables para crear un cortafuegos utilizando nuestras
entradas. Sin embargo, es recomendable tener un conocimiento básico de lo que está sucediendo “bajo
cubierta” con IPTables antes de empezar a configurar con una de las herramientas gráficas.
Instalar IPTables
La mayorı́a de los sistemas Linux con kernel 2.4 o superior tendrán integrado IPTables, por lo que no
es necesario instalar ningún programa adicional, el servicio lo proporciona el propio kernel.
Para comprobar si lo tenemos instalado hay que ejecutar:

$iptables -L, . . . deberı́a mostrar una lista con el conjunto actual de reglas.
Si tenemos problemas lo más probable es que no tengamos habilitado IPTables en el kernel, tenemos
que recompilar el kernel.
Módulos del kernel para IPTables

Para poder usar IPTables es necesario tener instalado en el kernel el netfilter y cargados una serie de
módulos, depende para que usemos IPTables necesitaremos más o menos.
Las opciones de IPTables se encuentran en: Networking-suport -> Networking-options -> Network-
packet-filtering.
1. Módulos básicos
CONFIG NETFILTER
CONFIG PACKET
CONFIG IP NF CONNTRACK
CONFIG IP NF FTP
2. Tabla filter (actúa como filtro)
CONFIG IP NF IPTABLES
CONFIG IP NF FILTER
CONFIG IP NF MATCH LIMIT
CONFIG IP NF MATCH MAC
CONFIG IP NF MATCH MARK
CONFIG IP NF MATCH MULTIPORT
CONFIG IP NF MATCH TOS
CONFIG IP NF MATCH TCTPMSS
CONFIG IP NF MATCH STATE
CONFIG IP NF TARGET REJECT

3. Tabla Nat (actúa como router)

CONFIG IP NF NAT
CONFIG IP NF NAT NEEDED
CONFIG IP NF NAT FTP
CONFIG IP NF TARGET MASQUERADE
CONFIG IP NF TARGET REDIRECT
4. Tabla mangle (altera paquetes especiales)
CONFIG IP NF MANGLE
CONFIG IP NF TARGET TOS
CONFIG IP NF TARGET MARK
CONFIG IP NF TARGET LOG
CONFIG IP NF TARGET TCPMSS
5. Compatibilidad con versiones anteriores
CONFIG IP COMPAT IPCHAINS

CONFIG IP COMPAT IPFWADM
Utilizar IPTables
La idea que se esconde detrás de IPTables es crear canales de entradas y procesarlas de acuerdo con
un conjunto de reglas (la configuración del cortafuegos) y enviarlas a continuación a canales de salida. En
IPTables, estos canales se denominan tablas.
Las tablas básicas empleadas en IPTables son:

Input: Tráfico que entra en la máquina
Forward: Tráfico que pasa por la máquina
Prerouting: Enrutamiento previo
Postrouting: Enrutamiento posterior

Output: Trafico que sale de la máquina
El formato que genera una declaración IPTables es:
#iptables command rule-specification extensions
Donde command, rule-specification y extensions son una o más opciones válidas. La tabla 12.3 incluye
un resumen de las especificaciones de reglas y la tabla 12.4 de los comandos IPTables.
Existen otros comandos y opciones pero éstos son los más comunes. Para obtener una lista completa
de listados, consulte el manual de IPTables escribiendo:
$man iptables

Cuadro 12.3: Especificaciones de reglas de IPTables

Regla Descripción
-s address/mask!port Especifica una determindada dirección de red origen a comparar. Para desig-
nar un rago de direcciones IP se usa la notación estándar de barra oblicua.
También se pude especificar un número de puerto o un rango de números
de puerto colocándolos después de un signo de exclamación de apertura
-d address/mask!port Especifica una determindada dirección de red destino a comparar. Para
designar un rago de direcciones IP se usa la notación estándar de barra
oblicua. También se pude especificar un número de puerto o un rango de
números de puerto colocándolos después de un signo de exclamación de
apertura
--sport Puerto de origen
--dport Puerto de destino
--tcp-flags Flags permitidos y flags activos. Los flags son:SYN ACK FIN RST URG
PSH ALL NONE (hay que especificarlos separados por comas)
-f Especifica paquetes fragmentados
-m <modulo> Especifica un módulo de opciones especiales
-m multiport Especifica que se usará el módulo de multipuertos
-p protocol Especifica un determinado protocolo con el que se compara la regla. Los
tipos de protocolo válidos son icmp, tcp, udp o todos (all)
-i interface Especifica una interfaz de entrada
-o interface Especifica una interfaz de salida
-j target Indica lo que se tiene que hacer con el paqute si coincide
con las especificaciones. Las opciones válidas para target son:
DROP Coloca el paquete sin ninguna acción posterior
REJECT Coloca el paquete y devuelve un paquete de error
LOG Registra el paquete en un de error
MARK Marca el paquete para una acción posterior
TOS Cambia el bit TOS (Tipo de servicio)
MIRROR Invierte las direcciones de origen y de destino y las envı́a
de nuevo, básicamente “rebotándolas” de nuevo al origen
SNAT NAT estática. Esta opción se utiliza cuando se está reali-
zando una Traducción de dirección de red (NAT, Network
Address Translation). Convierte la dirección de origen en
otro valor estático
DNAT NAT dinámica. Similar a la anterior pero usando un rango
dinámico de direcciones IP
MASQ Enmascara la IP usando una IP pública
REDIRECT Redirecciona el paquete
Crear un cortafuegos IPTables

La mejor forma de ver como funciona es mediante un ejemplo, que situaremos dentro de un script
ejecutable.
Se toman las siguientes premisas: Se supone que la LAN local es 192.168.0.1 - 192.168.0.254, que la
interfaz eth1 es la conexión LAN local y que la interfaz eth0 es la conexión WAN o Internet.
1. Empieza eliminando cualquier regla existente con el comando Flush:

iptables -F FORWARD
Ası́ eliminamos cualquier regla para la cadena FORWARD, que es el “conducto” principal para
cualquier paquete que desea pasar por el cortafuegos.

Cuadro 12.4: Comandos IPTables

-A chain Añade una o más reglas al final de la declaración
-I chain rulenum Inserta una cadena en la ubicación rulenum. Es útil cuando deseamos que una
regla reemplace a las anteriores
-D chain Elimina la cadena indicada
-R chain rulenum Reemplaza la regla en la ubicación rulenum con la chain proporcionada
-L Lista todas las reglas en la cadena actual
-F Purga todas las reglas en la cadena actual, eliminando básicamente la configu-
ración de nuestro cortafuegos. Es recomendable su uso cuando iniciamos una
configuración para asegurarnos de que ninguna regla existente entrará en con-
flicto con una regla nueva
-Z chain Pone a cero todas las cuentas de paquetes y bytes en la cadena denominada
-N chain Crea una nueva cadena con el nombre de chain
-X chain Elimina la cadena especificada. Si no se especifica ninguna cadena, se eliminan
todas las cadenas
-P chain policy Establece la polı́tica para la cadena especificada en policy
2. Eliminamos las otras cadenas:

iptables -F INPUT
iptables -F OUTPUT
Ası́ eliminamos cualquier regla en su máquina local y en su cadena de salida, también podiamos
haber usado: iptables -F, afectando a todas las cadenas a la vez.
3. Inserta la declaración “denegar todo” estándar justo al principio:

iptables -P FORWARD DROP
iptables -A INPUT -i eth0 -j DROP
4. Para aceptar paquetes fragmentados en IPTables, es necesario que se escriba lo siguiente explı́cita-
mente:
iptables -A FORWARD -f -j ACCEPT
5. Existen dos tipos de ataques comunes que debemos bloquear en seguida. Uno es el conocido como
spooofing, que se produce cuando alguien falsifica los encabezados de los paquetes IP para que
parezcan paquetes externos que tienen direcciones internas. Ası́, alguien puede enrutar hacia nuestra
LAN incluso aunque tengamos idrecciones IP privadas. El otro tipo de ataque se lleva a cabo enviando
una gran cantidad de paquetes a las direcciones LAN para sobrecargar la red. Este tipo de ataque
se denomina ataque smurf, ataca sobre el protocolo de transmisión de archivos. Podemos bloquear
este tipo de ataques con dos sencillas declaraciones.
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -j DROP
iptables -A FORWARD -p icmp -i eth0 -d 192.168.0.0/24 -j DROP
La primera declaración rechaza cualquier paquete que provenga de la interfaz eth0 de Internet con la
dirección interna 192.168.0.0/24. Por definición, ningún paquete deberı́a provenir de una interfaz de
no confianza con una dirección de fuente privada e interna. La segunda declaración retira cualquier
paquete del protocolo ICMP que provenga de la dirección exterior a la interior.
También se podrı́an evitar las respuestas a pings externos mediante:

iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

6. Generalmente aceptaremos el tráfico entrante basado en conexiones iniciadas desde el interior, por
ejemplo, alguien que explora una página Web. Siempre que la conexión esté en curso y se haya
iniciado internamente, probablemente sea correcta. Sin embargo, podemos limitar el tipo de tráfico
permitido. Supongamos que sólo deseamos permitir a los empleados el acceso a la Web y al correo
electrónico. Podemos especificar los tipos de tráfico para permitir sólo el que esté en una conexión ya
iniciada. Podemos saber si es una conexión existente comprobando si se ha establecido la parte ACK,
es decir, si se ha producido la conexión TCP de tres vı́as. Las siguientes declaraciones permiten el
tráfico web basado en este criterio.
iptables -A FORWARD -m multiport -p tcp -i eth0 -d 192.168.0.0/24 --dports www,smtp

--tcp-flags SYN,ACK ACK -j ACCEPT
iptables -A FORWARD -m multiport -p tcp -i eth0 -d 192.168.0.0/24 --sports www,smtp
--tcp-flags SYN,ACK ACK -j ACCEPT
La declaración --dports indica que sólo se permite el correo electrónico y la Web y la declaración
de indicadores –tcp indica que sólo deseamos paquetes con el campo ACK establecido
7. Para poder aceptar conexiones de entrada desde el exterior sólo en determinados puertos, como un
mensaje correo electrónico entrante en nuestro servidor de correo, usamos este tipo de declaración:
iptables -A FORWARD -m multiport -p tcp -i eth0 -d 192.168.0.0/24 --dports smtp
--syn -j ACCEPT
El indicador de múltiples puertos -m indica a IPTables que vamos a emitir una declaración de
coincidencia para los puertos. La declaración -syn le indica que se permiten los paquetes SYN, lo
que significa que se deben iniciar las conexiones TCP. Y el indicador --dports permite sólo el tráfico
de correo SMTP.
8. Podemos permitir que los usuarios inicien conexiones de salida pero sólo en los protocolos que
deseamos que usen. Aquı́ podemos evitar que los usuarios usen FTP y otros programas no esenciales.
Las direcciones que contienen todo ceros son una abreviatura de “cualquier dirección”.
iptables -A FORWARD -m multiport -p tcp -i eth0 -d 0.0.0.0 --dports www,smtp
--syn -j ACCEPT
9. Necesitaremos permitir determinados paquetes UDP entrantes. UDP se usa para DNS y si lo blo-
queamos, los usuarios no podrán resolver direcciones. Como no disponen de un estado como los
paquetes TCP, no podemos fiarnos de la revisión de los indicadores SYN o ACK. Deseamos admitir
UDP sólo en el puerto 53, por lo que especificaremos: domain (una variable integrada para el puerto
53), como único puerto admisible. Las declaraciones que debemos usar son:
iptables -A FORWARD -m multiport -p udp -i eth0 -d 192.168.0.0/24 --dports
domain -j ACCEPT
iptables -A FORWARD -m multiport -p udp -i eth0 -s 192.168.0.0/24 --sports
domain -j ACCEPT
iptables -A FORWARD -m multiport -p udp -i eth1 -d 0.0.0.0 --dports
domain -j ACCEPT
iptables -A FORWARD -m multiport -p udp -i eth1 -s 0.0.0.0 --sports
domain -j ACCEPT
Las dos primeras declaraciones permiten los datagramas UDP entrantes y las otras dos declaraciones
permiten las conexiones salientes.

10. También podemos especificarlos para los paquetes ICMP. Lo que pretendemos es permitir todo tipo
de ICMP interno hacia el exterior, pero sólo determinados tipos como la contestación de eco hacia
el interior, algo que podemos conseguir con las siguientes instrucciones:
iptables -A FORWARD -m multiport -p icmp -i eth0 -d 192.168.0.0/24
--dports 0,3,11 -j ACCEPT
iptables -A FORWARD -m multiport -p icmp -i eth1 -d 0.0.0.0
--dports 8,3,11 -j ACCEPT
Es mas simple si lo controlamos a la entrada, haciendo un DROP de los ’echos de icmp’, ası́ estas
dos instrucciones no son necesarias.
11. Por último, vamos a establecer el inicio de sesión para poder ver en los registros lo que se ha
rechazado. Es mejor revisar estos registros de vez en cuando, incluso aunque no exista ningún
problema, para tener una idea de los tipos de tráfico que se han rechazado. Si observa paquetes
rechazados repetidamente de la misma red o dirección, puede que esté siendo atacado. Existe una
declaración para registrar cada tipo de tráfico:
iptables -A FORWARD -m tcp -p tcp -j LOG
iptables -A FORWARD -m udp -p udp -j LOG
iptables -A FORWARD -m icmp -p icmp -j LOG
Con esto conseguirı́amos una protección a nivel de cortafuegos ante los ataques más comunes de
internet. El siguiente código es el ejemplo en un script.
Cuadro 12.5: Ejemplo de IPTables

#! /bin/bash
# Punto 1
iptables -F FORWARD
# Punto 2
iptables -F INPUT
iptables -F OUTPUT
# Punto 3
iptables -P FORWARD DROP
iptables -A INPUT -i eth0 -j DROP
# Punto 4
iptables -A FORWARD -f -j ACCEPT
# Punto 5
iptables -A FORWARD -s 192.168.0.0/24 -i eth0 -j DROP
#iptables -A INPUT -p icmp --icmp-type echo-request -j DROP - OMITIDO , para evitar el punto 10
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
# Punto 6
iptables -A FORWARD -m multiport -p tcp -i eth0 -d 192.168.0.0/24 --dports www,smtp --tcp-flags SYN,ACK ACK -j ACCEPT
iptables -A FORWARD -m multiport -p tcp -i eth0 -d 192.168.0.0/24 --sports www,smtp --tcp-flags SYN,ACK ACK -j ACCEPT
# Punto 7
iptables -A FORWARD -m multiport -p tcp -i eth0 -d 192.168.0.0/24 --dports smtp --syn -j ACCEPT
# Punto 8
iptables -A FORWARD -m multiport -p tcp -i eth0 -d 0.0.0.0 --dports www,smtp --syn -j ACCEPT
# Punto 9
iptables -A FORWARD -m multiport -p udp -i eth0 -d 192.168.0.0/24 --dports domain -j ACCEPT
iptables -A FORWARD -m multiport -p udp -i eth0 -s 192.168.0.0/24 --sports domain -j ACCEPT
iptables -A FORWARD -m multiport -p udp -i eth1 -d 0.0.0.0 --dports domain -j ACCEPT
iptables -A FORWARD -m multiport -p udp -i eth1 -s 0.0.0.0 --sports domain -j ACCEPT
# Punto 10 - OMITIDO
#iptables -A FORWARD -m multiport -p icmp -i eth0 -d 192.168.0.0/24 --dports 0,3,11 -j ACCEPT
#iptables -A FORWARD -m multiport -p icmp -i eth1 -d 0.0.0.0 --dports 8,3,11 -j ACCEPT
# Punto 11
iptables -A FORWARD -m tcp -p tcp -j LOG
iptables -A FORWARD -m udp -p udp -j LOG
iptables -A FORWARD -m icmp -p icmp -j LOG
Es necesario darle permisos de ejecución: #chmod 700 nombre_script

El resultado de nuestro cortafuegos después de ejecutar el script serı́a el siguiente:

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere
DROP icmp -- anywhere anywhere icmp echo-request
Chain FORWARD (policy DROP)

ACCEPT all -f anywhere anywhere
DROP all -- 192.168.0.0/24 anywhere
ACCEPT tcp -- anywhere 192.168.0.0/24 multiport dports www,smtp tcp flags:SYN,ACK/ACK
ACCEPT tcp -- anywhere 192.168.0.0/24 multiport sports www,smtp tcp flags:SYN,ACK/ACK
ACCEPT tcp -- anywhere 192.168.0.0/24 multiport dports smtp tcp flags:SYN,RST,ACK/SYN
ACCEPT tcp -- anywhere 0.0.0.0 multiport dports www,smtp tcp flags:SYN,RST,ACK/SYN
ACCEPT udp -- anywhere 192.168.0.0/24 multiport dports domain
ACCEPT udp -- 192.168.0.0/24 anywhere multiport sports domain
ACCEPT udp -- anywhere 0.0.0.0 multiport dports domain
ACCEPT udp -- 0.0.0.0 anywhere multiport sports domain
LOG tcp -- anywhere anywhere tcp LOG level warning
LOG udp -- anywhere anywhere udp LOG level warning
LOG icmp -- anywhere anywhere icmp any LOG level warning
Chain OUTPUT (policy ACCEPT)

Enmascarar IP con IPTables

Cuando se diseño Internet originalmente, se reservaron varios bloques de direcciones para su uso
en redes privadas. Estas direcciones nos se van a enrutar a través de Internet y se pueden utilizar sin
preocuparse de que vayan a tener conflictos con otras redes. Los rangos de direcciones privadas son:
10.0.0.0 - 10.255.255.255
192.168.0.0 - 192.68.255.255
172.16.0.0 - 172.31.255.255
Al utilizar estas direcciones en nuestra LAN interna y tener una IP externa enrutable en nuestro cor-
tafuegos, estamos protegiendo con efectividad nuestras máquinas internas ante el acceso desde el exterior.
Podemos proporcionar esta capa adicional de protección fácilmente con IPTables utilizando el enmasca-
rado IP. El encabezado IP interno se desprende en el cortafuegos y se reemplaza con un encabezado que
muestra el cortafuegos como el IP de origen. A continuación se envı́a el paquete de datos a su destino con
una dirección IP de origen de la interfaz pública del cortafuegos.
Cuando vuelve de nuevo, el cortafuegos recuerda el IP interno al que se dirige y vuelve a dirigirlo para
una entrega interna. Este proceso también se conoce como Traducción de dirección de red (NAT, Network
Address Translation). Con las siguientes declaraciones podemos hacerlo en IPTables:
iptables -t nat -P POSTROUTING DROP

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
El indicador MASQUERADE se puede abreviar como MASQ.
Conclusiones
Bueno, ahora ya sabemos cómo crear un cortafuegos básico. Se trata de una configuración bastante
sencilla y las posibles variaciones son infinitas. Podemos enviar determinados puertos a servidores inter-
nos para que no tengan una dirección IP pública. Podemos colocar otra tarjeta de red en el servidor y
convertirla en una interfaz DMZ para servidores con dirección pública. Existen libros completos sobre la
configuración avanzada de cortafuegos y muchas listas de correo.
Existen otros métodos mas simples y rápidos de crear un cortafuegos, sin introducir comandos y
tener que recordar la sintaxis. Muchas herramientas crean las declaraciones del cortafuegos utilizando una
interfaz gráfica, es decir, de forma automática.
Para simplificar el método utilizare el módulo Firewall para Webmin, basado en IPTables.

12.3. Squid: Proxy transparente

Lo primero es tener el IPTables y el squid funcionando. Con las opciones NAT de netfilter en el kernel.
Veamos el proceso:
Activamos el reenvió de paquetes:
echo 1 > /proc/sys/net/ipv4/ip_forward
Hacemos que el NAT coja todas las peticiones que vayan a un puerto (por ejemplo el 80) y las
redirija al puerto del proxy (por ejemplo 3128):
iptables -t nat -A PREROUTING -s $NUESTRA_RED -p tcp --dport 80 -j REDIRECT
--to-port 3128
Instalación del proxy squid:
#apt-get install squid webmin-squid
El fichero de configuración del squid es: /etc/squid/squid.conf. Lo configuramos para permitir el
acceso del proxy a nuestra red interna:
• En #ACCESS CONTROLS :
acl redInterna src 192.168.1.0/255.255.255.0
• En #Only allow cachemgr access from localhost, hay que poner antes de las denegaciones:
http_access allow redInterna
• Y en #HTTPD-ACCELERATOR OPTIONS :
httpd_accel_host virtual
httpd_accel_uses_host_header on
httpd_accel_with_proxy on
También podemos configurar el proxy en modo gráfico mediante la herramienta de administración

Webmin. Para cargar el modulo realizaremos un apt: #apt-get install webmin-squid
Ahora veamos un ejemplo del archivo /etc/squid/squid.conf donde se limita el ancho de banda, para
la conexión:
Cuadro 12.6: Ejemplo del archivo /etc/squid/squid.conf
#Sacado de http://debaser.ath.cx/deal/manuales/Limitar-ancho-de-banda-COMO/html/install.html
#Todas las opciones de este archivo se encuentran muy bien documentadas en el
#propio squid.conf asi
#como en http://www.visolve.com/squidman/Configuration%20Guide.html
#Los puertos por los que escuchara nuestro Squid.

http_port 8080
icp_port 3130
#los cgi-bin no se cachearan.
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
#La memoria que usara Squid. Bueno, Squid usara mucha mas que esa.
cache_mem 16 MB
#250 significa que Squid usara 250 megabytes de espacio en disco.
cache_dir ufs /cache 250 16 256
#Lugares en los que iran los archivos de bitacora de Squid.

cache_log /var/log/squid/cache.log
cache_access_log /var/log/squid/access.log
cache_store_log /var/log/squid/store.log
cache_swap_log /var/log/squid/swap.log
#Cuantas veces rotar los archivos de bitacora antes de borrarlos.
#Acuda a la FAQ para m\’as informaci\’on.
logfile_rotate 10
redirect_rewrites_host_header off
cache_replacement_policy GDSF
acl localnet src 192.168.1.0/255.255.255.0
acl localhost src 127.0.0.1/255.255.255.255
acl Safe_ports port 80 443 210 119 70 20 21 1025-65535
acl CONNECT method CONNECT
acl all src 0.0.0.0/0.0.0.0

http_access allow localnet

http_access allow localhost
http_access deny !Safe_ports
http_access deny CONNECT
http_access deny all
maximum_object_size 3000 KB
store_avg_object_size 50 KB
#Configure esto si quiere que su proxy funcione de manera transparente.

#Eso significa que por lo general no tendra que configurar todos los
#navegadores de sus clientes, aunque tiene algunos inconvenientes.
#Si deja esto sin comentar no pasara nada peligroso.
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
#Todos los usuarios de nuestra LAN seran vistos por los servidores web
#externos como si usasen Mozilla en Linux.
anonymize_headers deny User-Agent
fake_user_agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011122
#Para acelerar aun mas nuestra conexion ponemos dos lineas similares a las
#de mas abajo. Apuntaran a un servidor proxy [parent] que usara nuestro propio
#Squid. No olvide cambiar el servidor por uno mas rapido para usted.
#Puede utilizar ping, traceroute y demas herramientas para comprobar la
#velocidad. Asegurese de que los puerto http e icp son los correctos.
#Descomente las lineas que comienzan por "cache_peer" de ser necesario.

#Este es el proxy que va a usar para todas las conexiones...
#cache_peer w3cache.icm.edu.pl parent 8080 3130 no-digest default
#...excepto para las direcciones e IPs que comiencen por "!".

#No es buena idea usar un mayor
#cache_peer_domain w3cache.icm.edu.pl !.pl !7thguard.net !192.168.1.1
#Esto resulta util cuando queremos usar el Cache Manager.

#Copie cachemgr.cgi al cgi-bin de su servidor web.
#Podra acceder a el una vez lo haya hecho introduciendo en un navegador
#la direccion http://su-servidor-web/cgi-bin/cachemgr.cgi
cache_mgr your@email
cachemgr_passwd secret_password all
#Este es el nombre de usuario con el que trabajara nuestro Squid.

cache_effective_user squid
cache_effective_group squid
log_icp_queries off
buffered_logs on
#####DELAY POOLS
#Esta es la parte mas importante para configurar el trafico entrante con
#Squid. Para una descripcion detallada acuda al archivo squid.conf o a la
#documentacion de http://www.squid-cache.org
#No queremos limitar las descargas en nuestra red local.

acl magic_words1 url_regex -i 192.168
#Queremos limitar la descarga de este tipo de archivos

#Ponga todo esto en una unica linea
acl magic_words2 url_regex -i ftp .exe .mp3 .vqf .tar.gz .gz .rpm .zip .rar .avi .mpeg .mpe .mpg .qt
.ram .rm .iso .raw .wav .mov
#No bloqueamos .html, .gif, .jpg y archivos similares porque por lo general
#no consumen demasiado ancho de banda.
#Queremos limitar el ancho de banda durante el dia permitiendo

#el ancho de banda completo durante la noche.
#Cuidado! con el acl de abajo sus descargas se interrumpiran
#a las 23:59. Lea la FAQ si quiere envitarlo.
acl day time 09:00-23:59
#Tenemos dos delay_pools diferentes

#Acuda a la documentaci\’on de Squid para familiarizarse
#con delay_pools y delay_class.
delay_pools 2
#Primer delay pool

#No queremos retrasar nuestro trafico local
#Hay tres cases de pools; aqui solo hablaremos de la segunda.
#Primera clase de retraso (1) de segundo tipo (2).
delay_class 1 2
#-1/-1 significa que no hay limites.

delay_parameters 1 -1/-1 -1/-1
#magic_words1: 192.168 que ya hemos puesto antes

delay_access 1 allow magic_words1
#Segundo delay pool.

#Queremos retrasar la descarga de los archivos mencionados en magic_words2.
#Segunda clase de retraso (2) de segundo tipo (2).
delay_class 2 2
#Los numeros siguientes son valores en bytes;

#Debemos recordar que Squid no tiene en cuenta los bits de inicio/parada
#5000/150000 son valores para la red al completo
#5000/120000 son valores para la IP independiente
#una vez los archivos descargados exceden los 150000 bytes,
#(o el doble o el triple)
#las descargas proseguiran a 5000 bytes/s
delay_parameters 2 5000/150000 5000/120000

#Ya hemos configurado antes el dia de 09:00 a 23:59.
delay_access 2 allow day
delay_access 2 deny !day
delay_access 2 allow magic_words2
#EOF

12.4. Bastille Linux: Herramienta de seguridad

Una vez instalado nuestro sistema operativo, necesitamos fortalecerlo para utilizarlo como sistema
de seguridad. Este proceso implica cerrar los servicios innecesarios, restringir los permisos y, en general,
minimizar las partes de la máquina que están expuestas. Los detalles de este proceso serán diferentes
dependiendo del uso pretendido de la máquina.
Antes el fortalecimiento solı́a ser un proceso manual intensivo a medida que se probaban y testeaban
las posibles modificaciones. Sin embargo, en Linux, existen herramientas que realizarán automáticamente
un fortalecimiento del sistema. Ası́ se puede ahorrar tiempo sin olvidarnos de nada.
En este caso utilizaré la herramienta Bastille Linux, disponible en la distribución Debian. A pesar de lo
que pueda parecer, no se trata de un sistema operativo independiente, sino de un conjunto de secuencias de
comandos que llevan a cabo determinadas configuraciones del sistema basándose en nuestras indicaciones.
Simplifica extraordinariamente el proceso de fortalecimiento y lo reduce a responder a algunas preguntas.
Si necesitamos más información la podemos obtener en la página web oficial: www.bastille-linux.org.
12.4.1. Ejecución
Es muy recomendable instalar esta herramienta, primeramente, en un entorno de pruebas. Este tipo
de programas pueden desconectar los servicios necesarios para el funcionamiento de algún servidores,
produciendo cortes de servicio o detención del mismo. Cuando haya probado su efecto y verificado su
estabilidad, podremos ejecutar la herramienta en nuestro entorno de trabajo.
Para instalar hay que ejecutar:
#apt-get install bastille
Para poder usar la aplicación deben de estar instalados los siguientes paquetes:
Perl 5.5 003 o superior

Perl TK Module 8.00.23 o superior
Perl Curses Module 1.06 o superior
Para ejecutar Bastille linux:
#/usr/sbin/bastille, . . . para el modo gráfico.
#/usr/sbin/bastille -c, . . . para el modo texto (curses).
También podemos ejecutar Bastille en lo que se denomina modo no interactivo. Este modo ejecuta Bas-
tille automáticamente, sin hacer preguntas, desde un archivo de configuración preasignado. cada vez que
ejecutamos Bastille, se crea un archivo de configuración. A continuación podemos utilizarlo para ejecutar
Bastille en otras máquinas en modo no interactivo. Esta técnica es útil para cerrar rápidamente múltiples
máquinas. Cuando disponga del archivo de configuración con los elementos deseados, simplemente cargue
Bastille en las máquinas adicionales y copie el archivo de configuración en dichas máquinas (o deje que
accedan al archivo por la red).
Para ejecutarlo escribimos:

#bastille non-interactive config-file
Donde config-file es el nombre y la ubicación del archivo de configuración que deseamos utilizar.

12.4.2. Modos de funcionamiento

Normalmente ejecutaremos Bastille en modo interactivo. En este modo responderemos a una serie de
preguntas sobre cómo vamos a utilizar la máquina. Basándose en las respuestas, Bastille desconecta los
servicios innecesarios o restringe los privilegios de los usuarios y servicios.
Nos pregunta cosas como “¿Desea utilizar esta máquina como acceso a máquinas Windows?”. Si res-
pondemos negativamente, desconecta el servidor Samba, que permite a nuestra máquina interactuar con
las máquinas Windows. Samba podrı́a introducir algunas brechas de seguridad potenciales en nuestro
sistema, por lo que es recomendable desconectarlo si no lo necesitamos.
Si tenemos que ejecutar algunos servidores (por ejemplo, SSH), intentará establecerlos con privilegios
limitados o utilizando un chrooted jail, es decir, si un servidor tiene que ejecutarse con acceso a la raı́z del
sistema, tiene una capacidad limitada de afectar a otras partes del sistema, lo que suaviza los efectos de
cualquier ataque con éxito sobre dicho servicio.
A cada pregunta le acompaña una pequeña explicación de porqué esa configuración es importante,
ası́ podemos decidir si es apropiada para nuestra instalación. También existe un botón de detalle con
información adicional.
Bastille adopta la solución de intentar educar al administrador mientras está cerrando el sistema.
Cuanta más información tenga, mejor armado estará para los deberes de seguridad de su red. Si no
está seguro, puede saltarse una pregunta y volver a ella más adelante. No hay que preocuparse, se ofrece una
oportunidad final para terminar todas las configuraciones. También puede ejecutar Bastille posteriormente
después de investigar sobre la respuesta y cambiar la configuración. Otra ventaja es que Bastille nos ofrece
una lista de “cosas para hacer” al final de la sesión de fortalecimiento para cualquier elemento del que
Bastille no se haya ocupado.
12.5. Copias de seguridad

Para realizar las copias de seguridad necesarias en nuestro servidor y dependiendo de las necesitades de
nuestra empresa, necesitamos disponer de una medio seguro donde poder almacenarlas. Para ello, podemos
aplicar una las siguientes soluciones:
Almacenar las copias en el propio disco fı́sico del servidor (no se recomienda).
Utilizar cintas de backup.
Utilizar DVDs de backups.

Si realizamos las copias en el propio disco o en cintas de backup, el proceso puede ser automatizado
mediante el cron del sistema.
12.5.1. Dispositivos de cinta

Las unidades de cinta SCSI, usan el siguiente esquema de nombres:
/dev/stX : Dispositivo de cinta SCSI de rebobinado automático; x es el número de la unidad de
cinta. Las unidades de cinta se numeran por su orden en la controladora SCSI.
/dev/nstX : Dispositivo de cinta SCSI sin rebobinado automático; x es el número de la unidad de
cinta. Las unidades de cinta se numeran por su orden en la controladora SCSI.
Probablemente tendremos en nuestro sistema un dispositivo de enlace simbólico a la cinta: /dev/tape.

12.5.2. Mt
El programa mt proporciona controles simples para la unidad de cinta, como el rebobinado, expulsión
o la búsqueda de un archivo. En el contexto de las copias de seguridad, mt es muy útil como mecanismo
de rebobinado y búsqueda.
Todas las acciones de mt se especifican en la lı́nea de comandos. El cuadro 12.7 muestra los parámetros
del comando.
Cuadro 12.7: Opciones del comando mt, para manipular cintas de backup
Parámetros Descripción
-f <dispositivo> Especifica el dispositivo de cinta.
fsf <cuenta> Avanza un número (cuenta) de archivos. La cinta se coloca en el primer bloque
del archivo siguiente; por ejemplo, fsf 1 deberı́a dejar la cabeza preparada para
leer el segundo archivo de la cinta.
asf <cuenta> Posiciona la cinta al comienzo del archivo indicado por cuenta. El posicionamiento
se hace primero con un rebobinado de la cinta y después se avanza cuenta archivos.
rewind Rebobina la cinta.
erase Borra la cinta.
status Da el estado de la cinta.
offline Deja la cinta inactiva y, si es aplicable, la descarga.
load Carga la cinta (aplicable a cambiadores de cinta).
lock Bloquea la puerta de la unidad (sólo aplicable a ciertas unidades de cinta).
unlock Desbloquea la puerta de la unidad (sólo aplicable a ciertas unidades de cinta).
Podemos ver los siguientes ejemplos:

#mt -f /ver/nst0 rewind,. . . Para rebobinar la cinta en /dev/nst0.
#mt -f /dev/nst0 asf 2,. . . Mueve la cabeza lectora, para leer el tercer archivo de la cinta.
12.5.3. Dump y Restore

Las herramientas que utilizaremos serán dos:
dump
restore
Para instalarlas ejecutaremos un apt:
#apt-get install dump
La herramienta dump trabaja haciendo una copia de un sistema de archivos entero. La herramienta
restore puede tomar esa copia y restaurarla.
Para soportar backups incrementales, dump usa el concepto de niveles de dump. Un nivel de dump
de 0 significa una copia de seguridad completa. Cualquier nivel de dump superior a 0 es un incremento
relativo a la última vez que se realizó un dump con un nivel de dump menor. Por poner un ejemplo, si
consideramos que tenemos tres dump: el primero de nivel 0, el segundo de nivel 1 y el tercero también
de nivel 1. El primer dump es una copia completa. El segundo dump contiene todos los cambios hechos
desde el primer dump. El tercer dump tiene todos los cambios desde el primer dump.
La utilidad dump almacena toda la información sobre sus operaciones en el archivo /etc/dumpdates.
Este archivo lista cada copia de seguridad de un sistema de archivos, cuándo se hizo y de qué nivel. Dada
esta información, podemos determinar que copia debemos restaurar.

En el cuadro 12.8 se muestran los parámetros más usuales del comando dump:
Cuadro 12.8: Parámetros del comando dump

-n El nivel de dump, donde n es un número entre 0 y 9.
-b <tam_bloque> Configura el tamaño del bloque de dump a tam bloque, el cual se mide en kilobytes.
Si hacemos copias de archivos muy grandes, al usar un tamaño de bloque mayor
aumentará el rendimiento.
-B <cuenta> Especifica el número (cuenta) de registros por cinta. Si hay más datos sobre los que
hacer dump, que espacio de cinta, dump muestra un sı́mbolo del sistema pidiendo
que se inserte una cinta nueva.
-f <archivo> Especifica una localización (archivo) para el archivo dump resultado. Podemos
hacer el archivo dump como un archivo normal que reside en otro sistema de
archivos, o podemos escribirlo en un dispositivo de cinta.
-u Actualiza el archivo /etc/dumpdates después de un dump con éxito.
-d <densidad> La densidad de una cinta en bits por pulgada.
-s <tam> El tamaño (tam) de la cinta en pies.
Para colocar el backup sobre una cinta, comprimiendolo, podemos hacer lo siguiente:
#dump -O -f - /dev/hda1 | gzip --fast -c > /dev/st0
Hay que tener cuidado con dump, se considera peligroso hacer dump de sistema de archivos que estén
en uso. Para asegurarse de que no estan en uso, hay que desmontar el sistema de archivos primero. Desa-
fortunadamente, muy poca gente se puede permitir el lujo de desmontar un sistema el tiempo necesario
para hacer una copia de seguridad. Lo mejor es realizar la poca atractiva tarea de verificar las copias de
seguridad sobre una base normal. La verificación se hace comprobando que el programa restore puede leer
completamente la copia y extraer los archivos de ella. Es tedioso y nada divertido, pero muchos adminis-
tradores de sistemas perdieron su trabajo después de copias de seguridad erróneas (y no queremos ser uno
de ellos).
Durante mis estudios en la FIB (Facultad de Informática de Barcelona) coincidı́ con varios profesores
que eran, al mismo tiempo, muy buenos administradores de sistemas. Y uno de ellos, Alex Ramirez, nos
dijo la siguiente frase, “La primera tarea de un administrador de sistemas es hacer copias de seguridad,
nadie quiere hacerlas y por eso nos pagan a nosotros para que las hagamos. Las copias de seguridad, sólo
se hechan de menos cuando nadie las ha hecho”.
Uso de dump para hacer backup de un sistema entero

La utilidad dump trabaja haciendo un archivo de un sistema de archivos. Si el sistema entero contiene
varios sistemas de archivos, necesitaremos ejecutar dump por cada sistema de archivos. Puesto que dump
crea su salida como un gran archivo independiente, podemos almacenar varios dumps en una sola cinta
mediante el uso de un dispositivo de cinta sin rebobinado automático, otra solución factible es el uso de
DVDs grabables. Primero tenemos que decidir sobre qué sistemas de archivos vamos a hacer la copia,
está información está en el archivo /etc/fstab.
Si por ejemplo queremos hacer un backup de: /dev/hda1, /dev/hda3, /dev/hda5 y /dev/hda6. Y
grabarlo en /dev/nst0, comprimiendo los archivos dump, debemos ejecutar los siguientes comandos:
#mt -f /dev/nst0 rewind
#dump -Ouf - /dev/hda1 | gzip --fast -c > /dev/st0
#mt -f /dev/nst0 rewind
#mt -f /dev/nst0 eject

Uso de restore
El programa restore lee los archivos dump y extrae archivos y directorios individuales de ellos. Aunque
restore es una herramienta de lı́nea de comandos, ofrece un modo interactivo muy intuitivo que le mueve
a través de la estructura de directorios de la cinta.
El cuadro 12.9 muestra las opciones de lı́nea de comandos de la utilidad restore.
Cuadro 12.9: Opciones del comando RESTORE

-i Activa el modo interactivo de restore. La utilidad leerá el contenido del directorio
de la cinta y nos dará una interfaz parecida a la shell en la cual nos podemos mover
entre los directorios y señalar los archivos que queramos, restore irá al dump y los
restaurará. Este modo es útil para recuperar archivos individuales, especialmente
si no estámos seguro en qué directorio están.
-r Reconstruye un sistema de archivos. en el caso de que pierda todo un sistema de
archivos (por ejemplo, por un fallo de disco), puede recrear un sistema de archivos
vacı́o y restaurar todos los archivos y directorios del archivo dump.
-b tam_bloque Configura el tamaño del bloque de dump a tam bloque kilobytes. Si no proporciona
esta información, restore se la pedirá.
-f nom_archivo Lee un dump del archivo nom archivo.
-T directorio Especifica el espacio de trabajo temporal (directorio) para el restore. Por defecto
es /tmp.
-v La opción verbal; muestra cada paso del restore.
-y En el caso de un error, reintenta automáticamente en lugar de preguntar al usuario
si quiere probar de nuevo.
Un restore tı́pico podrı́a ser el siguiente:

#restore -ivf /dev/st0
Donde tenemos el archivo dump en /dev/st0, visualizaremos cada paso que tome restore y entraremos
en una sesión interactiva donde decidiremos qué archivos se restauran.
Y para un restore completo desde la cinta /dev/st0, si perdemos el sistema de la unidad SCSI /dev/sda1
que contiene /home, sustituimos la unidad y lo recrear ayudandonos con mke2fs.
#mke2fs /dev/sda1
#mount /dev/sda1 /home
#cd /home
#restore -rf /dev/st0
12.5.4. Configuración gráfica de backups, interfaz Webmin

Para realizar de una forma mucho más simple las copias de seguridad, podemos utilizar la herramienta
de configuración por web: Webmin.
Para instalar el módulo de copias de seguridad ejecutaremos un apt:

#apt-get install webmin-fsdump
Este módulo permite hacer backups de:

Sistemas EXT2
Sistemas EXT3
Archivos TAR

Figura 12.1: Módulo Webmin para realizar Backups del sistema
12.5.5. K3B: Grabación de CDs y DVDs

Si queremos guardar las copias en CDs o DVDs, nos resultará muy útil una interfaz gráfica simple e
intuitiva, como la que nos ofrece el programa K3B basado en el entorno KDE.
Lo podemos instalar con un apt: #apt-get install k3b

Y para ejecutarlo introduciremos el comando: #k3b
Figura 12.2: Programa K3B para grabar CDs y DVDs

Capı́tulo 13
Sistemas de detección de intrusiones
Los Sistemas de detección de intrusiones (IDS, Intrusion Detection System) son básicamente sniffers
modificados que pueden ver todo el tráfico de la red e intentan detectar un tráfico potencialmente dañino,
alertándonos de ello cuando aparezca.
La forma principal de conseguirlo es examinando el tráfico de entrada e intentándolo comparar con
una base de datos de actividades dañinas conocidas denominadas firmas. Esta utilización de las firmas es
muy similar a la forma en que funcionan los programas antivirus.
La mayorı́a de los tipos de ataques tienen una apariencia muy distintiva a nivel TCP/IP. Un IDS puede
definir ataques basándose en las direcciones IP, los números de puertos, el contenido y cualquier número
de criterios.
Existe otra forma de realizar una detección de intrusión en el nivel del sistema comprobando la inte-
gridad de los archivos clave y asegurándose de que no se ha realizado ningún cambio en dichos archivos.
También existen otras tecnologı́as emergentes que combinan el concepto de detección de intrusión y
cortafuegos o realizan una acción posterior más allá de la pura detección.
Esta sección esta basada en el libro [How05].
13.1. Tipos de IDS

Existen tres tipos diferenciados de IDS:
NIDS: IDS de red, basado en firmas
IDS basado en actividad anómala
IPS: IDS que responde a las alertas con acciones automáticas
En las siguientes secciones se explican en detalle.
13.1.1. NIDS (Network Intrusion Detection System)

Un sistema detección de intrusión de red (NIDS, Network Intrusion Detection System) puede proteger-
nos contra los ataques que entran a través del cortafuegos hasta la LAN Interna. Los cortafuegos pueden
estar mal configurados, permitiendo la introducción de tráfico no deseado en nuestra red. Incluso cuando
funcionan correctamente, los cortafuegos normalmente dejan pasar algún tráfico de aplicación que puede
ser peligroso. Lo que llega a los puertos del cortafuegos, y está permitido por las reglas, se envı́a a los
servidores internos provocando un tráfico potencialmente dañino. Un NIDS puede comprobar dicho tráfico
y marcar los paquetes sospechosos. Configurado correctamente puede hacer una doble comprobación de las
reglas de nuestro cortafuegos y proporcionarnos una protección adicional para los servidores de aplicación.
Aunque es útil para protegernos contra ataques externos, una de las ventajas principales de un NIDS
es cazar los ataques y la actividad sospechosa de orı́genes internos. El cortafuegos nos protegerá de muchos
ataques externos, sin embargo, cuando el atacante se encuentra en la red local puede hacer muy poco.
Sólo puede ver el tráfico que lo atraviesa desde el exterior y son ciegos respecto a la actividad de la LAN.
Podemos pensar en los NIDS y en los cortafuegos como dispositivos de seguridad complementarios, el
cerrojo de la puerta principal y el sistema de seguridad de nuestra red. Uno protege nuestro perı́metro y
el otro nuestro interior.
Hay una buena razón para vigilar nuestro tráfico interno de red. Las estadı́sticas demuestran que un
setenta por ciento de los incidentes en crı́menes informáticos provienen de un origen interno. Por mucho
que nos guste pensar que nuestros compañeros no van a hacer nada para dañarnos, a veces no es el caso,
los intrusos internos no siempre son piratas informáticos que trabajan por la noche. Pueden ser desde
un administrador de sistemas contrariado, un empleado descuidado o hasta la señora de la limpieza. El
simple hecho de descargar un archivo o de abrir un archivo adjunto de un mensaje de correo electrónico
puede cargar un troyano que creará toda una brecha en nuestro cortafuegos para todo tipo de fechorı́as.
Con un NIDS, podemos captar este tipo de actividad ası́ como otros problemas en cuanto se producen.
Bien ajustado, puede ser el “sistema de alarma” de nuestra red.
13.1.2. IDS (Detección de actividades anómalas)

En lugar de utilizar firmas estáticas, que sólo pueden captar una actividad dañina cuando se define
explı́citamente, estos sistemas de nueva generación registran los niveles normales para distintos tipos de
actividad en nuestra red. Si observa una súbita oleada de tráfico FTP, nos avisará. El problema con este
tipo de sistemas es que son muy propensos a los falsos positivos, éstos se producen cuando se dispara una
alerta aunque la actividad que está marcando es normal y permitida en nuestra LAN, por ejemplo una
persona que está descargando un archivo particularmente grande activará la alarma.
Ası́ mismo se tarda mucho en que un IDS de detección de anomalı́as desarrolle un modelo preciso de
la red. Al principio, el sistema generará tantas alertas que es casi inútil.
Adicionalmente, estos tipos de sistemas de detección de intrusión pueden ser engañados por alguien que
conozca bien la red. Si los piratas informáticos son suficientemente furtivos y hábiles utilizarán protocolos
usados en nuestra LAN y no activarán este tipo de sistemas.
Sin embargo, una gran ventaja es que no tiene que actualizar firmas continuamente. A medida que
esta tecnologı́a madure y se haga más inteligente, probablemente se convierta en una forma muy popular
de detectar intrusiones.
Un ejemplo de IDS basado en actividades anómalas y de libre distribución es Spade, un módulo gratuito
para el NIDS Snort.
13.1.3. IPS (Intrusion Prevention System)

Un nuevo tipo de NIDS denominado Sistema de prevención de intrusión (IPS, Intrusion Prevention
System) se está publicitando como la solución para la seguridad de las empresas. Este tipo de sistemas
responderán a las alertas a medida que se generen. Esto puede realizarse trabajando con un cortafuegos o
con un enrutador, escribiendo reglas personalizadas en el momento que se detecta el problema, bloqueando
e interrogando la actividad de las direcciones IP sospechosas o incluso contraatacando al sistema ofensivo.
Aunque esta nueva tecnologı́a se encuentra en una constante evolución, todavı́a está muy lejos de poder
proporcionar el análisis y el juicio de una persona. El hecho es que cualquier sistema que dependa al cien
por cien de una máquina y de su software, tarde o temprano podrá ser burlado por algún intruso.
Un ejemplo de IPS de libre distribución es Inline Snort de Jed Haile, un módulo gratuito para el NIDS
Snort.
13.2. Ubicación del NIDS

Para elegir la ubicación del NIDS hay que valorar el grado de interoperabilidad con el resto de nuestras
protecciones de red. Existen varias posibilidades y cada una tiene distintas ventajas e inconvenientes.

Capı́tulo 13. Sistemas de detección de intrusiones 215
1. En la red LAN local, detrás del cortafuegos: Es el lugar más común, ofrece la mejor protección frente
a las amenazas externas e internas. Al escuchar el cable local, podemos detectar la actividad interna
de otros usuarios (como la actividad entre estaciones de trabajo o el uso ilı́cito de un programa).
También refuerza el cortafuegos, detectando una actividad sospechosa que de alguna manera ha
conseguido pasar los filtros del cortafuegos. De hecho, se pude utilizar un IDS para probar un
cortafuegos y comprobar lo que permite pasar.
Sin embargo, este sistema generará muchas alertas basadas en el tráfico de red de Windows, por lo que
debemos estar preparados para realizar muchos ajustes en este área. Ası́ mismo, si nos encontramos
en una LAN conmutada, necesitaremos la capacidad de reflejar todos los puertos sobre un puerto
monitor para poder permitir al IDS escuchar todo el tráfico LAN.
2. En el segmento DMZ : Podemos colocar un sensor Snort en la DMZ para registrar la actividad que
entra en los servidores públicos. Como esos servidores son los más expuestos y normalmente repre-
sentan recursos valiosos, es buena idea supervisarlos con un IDS. El problema de esta configuración
es ordenar todas las alertas. Aunque todas ellas puedan ser alertas válidas, con el nivel de ataque de
tráfico general actual en Internet, cualquier IP pública es atacada de forma aleatoria todos los dı́as.
Reaccionar ante ello intentando localizar dichas alertas serı́a excesivo y contraproducente.
Por lo tanto, ¿cómo podemos saber qué alertas son sólo gusanos que están atacando a nuestro
servidor y qué alertas están realmente avisándonos de un intruso real?. Una forma de hacerlo es
reduciendo el número de firmas a un pequeño número que sólo se activen si el host está realmente
comprometido, por ejemplo, reglas especı́ficas a las aplicaciones que se están ejecutando en el host,
como MySQL.rules, web-iis.rules o reglas relacionadas con la administración de conexiones.
3. Entre el ISP y el cortafuegos: Esta configuración filtrará todo el tráfico entrante y saliente de la
LAN y DMZ. Lo bueno es que capturará todos los ataques tanto a los servidores públicos como a
la LAN interna. Lo malo es que no podrémos ver ningún tráfico interno y el volumen general de las
alertas puede ser bastante alto, debido al tráfico de ataque general subyacente.
Igual que en el ejemplo anterior, se puede probar a reducir las alertas y dejar sólo las que realmente
van a mostrar algún problema para este segmento. Ası́ mismo, al situarlo entre el sensor ISP y el
cortafuegos, puede crear un cuello de botella y un punto de errores para nuestro tráfico de red.
Todas las formas puede ser válidas para utilizar un IDS y no hay razón para que no podamos seguir
las tres, siempre que tengamos el hardware y el tiempo necesario para hacerlo.
13.3. El problema de los falsos positivos de NIDS

Uno de los problemas principales con los sistemas de detección de intrusión es que suelen generar
muchos falsos positivos. Un falso positivo se produce cuando el sistema genera una alerta basándose
en lo que cree que es una actividad dañina o sospechosa pero en realidad es un tráfico normal en esa
LAN. Generalmente, cuando establecemos un NIDS con sus configuraciones predeterminadas, va a buscar
todo lo que sea ligeramente inusual. La mayorı́a de los sistemas de detección de intrusión de red tienen
grandes bases de datos predeterminadas con miles de firmas de posibles actividades sospechosas. Los
suministradores de IDS no tienen forma de saber la apariencia de nuestro tráfico de red, por lo que lo
incluyen todo.
Existen otras muchas fuentes de falsos positivos, dependiendo de la configuración de nuestra red y
de su nivel de actividad. Un NIDS con una instalación predeterminada puede generar cientos de falsos
positivos en un solo dı́a, algo que puede conducir a un sensación de desesperación en el administrador
del sistema. La reacción normal, es que las alertas de estos sistemas se ignoran a menudo debido a su
falta de eficacia. Sin embargo, con poco esfuerzo y utilizando las técnicas descritas en este capı́tulo un
IDS puede convertirse en una herramienta útil, en lugar de en la versión electrónica de la niña del exorcista.
Las causas más comunes de los falsos positivos se describen en los siguientes apartados.

Actividad del sistema de supervisión de red

Muchas empresas utilizan sistemas de supervisión de redes (NMS, Network Monitorig System) como
HP OpenView o WhatsUp Gold para tener registros de la actividad de sus sistemas. Estos programas
generan mucha actividad de sondeo y descubrimiento en nuestra red.
Normalmente utilizan SNMP o algún protocolo similar para obtener el estado, pero pueden también
utilizar pings y pruebas más intrusivas. De forma predeterminada, la mayorı́a de los sistemas de detección
considerarán hostil esta actividad, o al menos, sospechosa. Un NMS en una red grande puede generar
miles de alertas por hora, si se ha establecido en el IDS marcar este tipo de actividad. Se puede evitar
haciendo que nuestro NIDS ignore la actividad desde y hacia la IP del NMS. También podemos eliminar
este tipo de alertas de la base de datos de nuestro NIDS, si no consideramos estas alertas importantes.
Escaneado de vulnerabilidad y escáneres de puertos de red

Si estamos realizando una prueba de vulnerabilidad de red o un escaneado de puertos utilizando
programas como Nessus o Nmap, nuestro NIDS se volverá loco cada vez que se ejecuten dichos programas.
Estos programas están diseñados para hacer exactamente lo que hacen los piratas informáticos. De hecho,
probablemente exista una alerta para la mayorı́a de los complementos del programa Nessus. Una vez más,
podemos deshabilitar el informe de la dirección IP de nuestro servidor Nessus o Nmap dentro del NIDS.
Una mejor manera de controlar esta situación es apagar nuestro IDS durante los escaneados programados.
Ası́, la IP del escáner seguirá protegida contra un ataque cuando no esté escaneando y nuestra base de
datos de alertas no se cargará con datos de nuestra actividad de escaneado.
Actividad de usuario
La mayorı́a de los sistemas de detección de intrusión de redes se configuran para marcar diversas
actividades de usuario peligrosas, como compartir archivos punto a punto, mensajerı́a instantánea, etc.
Sin embargo, si permitimos este tipo de actividad, bien por polı́tica formal o simplemente sin imponer las
polı́ticas existentes, se mostrarán como alertas en nuestro registros.
Éste serı́a un buen momento para imponer o crear polı́ticas contra su utilización ya que podemos
demostrar cuánto ancho de banda y tiempo consumen, sin mencionar las implicaciones de seguridad.
Aunque si pretendemos seguir permitiendo esta actividad, deberı́amos comentar estas reglas para no
rellenar los registros con alertas innecesarias.
Comportamientos parecidos a los troyanos o gusanos

Normalmente, virus, gusanos y troyanos viven para la red. Intentan ejecutar diversas actividades por
la red, incluyendo la infección de nuevas máquinas y el envı́o en masa de mensajes de correo electrónico.
Estas actividades las puede detectar un NIDS, sin embargo, estas firmas también pueden ser activadas
por una actividad normal de nuestra red. Podrı́amos desactivar las alertas que reconocen esta actividad,
aunque exista un tráfico potencialmente dañino, para evitar vernos agobiados por los falsos positivos.
Cadenas largas de autenticación básica

Este tipo de alerta busca las cadenas de registro web largas, algunos ataques utilizan este método para
conseguir un desbordamiento de memoria y obtener acceso al sistema.
Sin embargo, hoy en dı́a, muchas webs llenan este campo de información. Aunque, si desactivamos la
regla para evitar falsos positivos, puede viajar código dañino por nuestra red y pasar inadvertido para el
NIDS.
Actividad de autenticación de base de datos

Algunos sistemas de detección de intrusión de red buscan actividades administrativas sobre bases de
datos. La teorı́a es que el uso de bases de datos no deberı́a de tener demasiada actividad administrativa
en curso y ello podrı́a ser señal de que alguien están intentando sabotearla. Sin embargo, muchas bases

de datos tienen trabajos en proceso y mucha actividad administrativa incluso si no se están consultando.
Esta actividad, aunque legı́tima, generará muchas de estas alertas.
Si nuestras bases de datos están en constante desarrollo, probablemente deberemos desactivar dichas
alertas, al menos hasta que se estabilicen y tengan un uso normal.
13.4. Obtener lo máximo del IDS

Para darnos cuenta del verdadero potencial de un sistema de detección de intrusión necesitaremos
seguir unas pautas antes y después de la instalación.
13.4.1. Configuración apropiada del sistema

Si simplemente instalamos un IDS y lo activamos con una configuración predeterminada, rápidamente
nos inundarán miles de alertas de falsos positivos. Podemos ajustarlo después de estar activo, pero nos
ahorraremos mucho tiempo y esfuerzo configurándolo cuidadosamente de antemano. No debemos confor-
marnos con las configuraciones por defecto, hay que ajustarlas al perfil de nuestra LAN.
La mayorı́a de los sistemas de detección agrupan las alertas en categorı́as. Es preciso examinar cada
grupo para comprobar si es relevante en nuestra red. Si hay un grupo de firmas basadas en Unix pero
no tenemos ningún sistema Unix, podemos desactivar con seguridad esas alertas. Algunos tienen alertas
que buscan la utilización de mensajerı́a instantánea o la utilización de software punto a punto. Si ya
tenemos sistemas que filtran estas actividades o las permitimos en nuestro sistema, es mejor desactivar
esas alarmas. Tenemos que repasar los grupos de alertas con detalle. Por ejemplo, desearemos utilizar la
mayorı́a de las alertas basadas en Windows, pero existirán algunas irrelevantes para nuestra red o que
causen falsos positivos, esas las podemos desactivar.
También podemos excluir algunos hosts del examen. Si efectuamos desde una máquina constantes
sondeos SNMP por nuestra red o frecuentemente estamos iniciando sesión como administrador remoto,
generaremos alertas que no merece la pena proteger.
Aunque reduzcamos el nivel de protección proporcionado y podamos dejar sin protección alguna máqui-
na crı́tica, podemos hacer el IDS más efectivo y merecerá la pena asumir ese riesgo. Tardar algunas horas
en configurar nuestro sistema antes de activarlo puede ahorrarnos mucho tiempo y frustración en el futuro.
Si vamos a ejecutar un IDS es mejor que nos tomemos el tiempo necesario para hacerlo funcionar
correctamente.
13.4.2. Ajuste del IDS

Cuando ya se está ejecutando, incluso el IDS más meticulosamente configurado empezará a generar
alertas. Al principio, si nos tomamos el tiempo necesario para analizarlas y empezamos a desactivar las
reglas que no nos importen en nuestra red, podremos reducir rápidamente el número de falsos positivos
que está produciendo el IDS.
También nos proporcionará un conocimiento de cómo está trabajando nuestra red y del tipo de tráfico
que se está revisando, algo útil para cualquier administrador de redes.
Es preciso reservar un tiempo semanal para modificar las configuraciones IDS. En algunos sistemas es
relativamente fácil marcar una alerta como falso positivo mientras que en otros podemos encontrarnos con
más dificultades. En general, se tardan algunos meses antes de que un IDS esté ajustado correctamente
para enviar alertas útiles sobre una actividad procesable.
13.4.3. Herramientas de análisis IDS

Los sistemas de detección normalmente ofrecen a los administradores varios métodos de notificación
de una alerta.
En su nivel más básico, las alertas pueden simplemente enviarse a un archivo de registro para una
revisión posterior, algo que no es muy recomendable ya que requiere que el administrador revise
los registros. Si no se supervisan diariamente, pueden pasar dı́as o semanas antes de descubrir los
intentos de intrusión.

La otra alternativa es enviar un mensaje de correo electrónico o una página, a la persona apropiada
siempre que se genere una alerta. Sin embargo, incluso en un sistema bien ajustado, puede ser
molesto recibir correos varias veces al dı́a. Ası́ mismo, las alertas de correo electrónico no estarán en
un formato en el que se puedan comparar con alertas pasadas o analizadas de otra forma.
La mejor solución para controlar las alertas IDS es insertarlas en una base de datos, para permitir un
análisis más profundo. Existe una herramienta de libre distribución para los sistemas de detección
de intrusiones denominada Analysis Console for Intrusion Database (ACIDlab, véase sección 13.8).
13.5. IDS Snort (NIDS)

Es una herramienta desarrollada por Martin Roesch, aunque ahora ya cuenta con 30 desarrolladores
más en su equipo principal, sin contar con los que escriben reglas y otras partes del software. Existen
muchos recursos disponibles para Snort y todos ellos son recursos gratuitos disponibles en Internet.
Snort es principalmente un IDS basado en firmas, aunque con la adición del módulo Spade, puede
realizar una detección de actividad de anomalı́as. Existen también otros módulos de complemento como
Inline Snort que permite a Snort realizar acciones predeterminadas ante determinadas alertas.
Para obtener más información sobre el programa, estos módulos o otros podemos consultar la web:
http://www.snort.org
O consultar la información que podemos obtener en nuestro sistema Debian:

#apt-get install snort-doc
13.5.1. Caracterı́sticas básicas

Libre distribución: Snort es de libre distribución y portable a casi cualquier sistema operativo
Unix/Linux. También existen versiones disponibles para Windows y otros sistemas operativos.
Ligero: Debido a que el código se ejecuta de una forma eficiente, no requiere mucho hardware, lo
que permite poder analizar tráfico en una red de 100 Mbps a una velocidad cercana al cable, algo
bastante increı́ble si pensamos lo que hace con cada paquete.
Snort personaliza reglas: Snort ofrece una forma fácil para ampliar y personalizar el programa es-
cribiendo nuestras propias reglas o firmas. Existe mucha documentación que puede ayudarnos a
aprender a hacer reglas (véase sección 13.5.9), sin mencionar la cantidad de foros sobre el tema.
13.5.2. Instalación
Para instalarlo simplemente realizaremos el apt del paquete:
#apt-get install snort
Los archivos importantes de snort son los siguientes:
/etc/snort/snort.conf : Archivo de configuración por defecto
/etc/snort/snort.<host>.conf: Archivo de configuración para el host
/etc/snort/snort.<dispositivo>.conf : Archivo de configuración para un dispositivo de red concreto
/etc/snort/rules/* : Archivos de reglas

13.5.3. Modos de ejecución

Snort se ejecuta desde la lı́nea de comandos, en tres modos diferentes:
Sniffer de red
Registro de paquetes
IDS
La mayorı́a de los usuarios lo ejecutaran en este último modo para obtener las ventajas de IDS, pero
también hay usos para los dos primeros modos.
Modo de sniffer de paquetes

En este modo, Snort actúa como un sniffer, mostrando el contenido sin filtrar en el cable. Evidente-
mente. Si lo único que necesitamos es un sniffer podrı́amos utilizar Tcpdump o Ethereal (más completos).
Sin embargo, el modo sniffer de paquetes es bueno para asegurarse de que todo funciona correctamente y
Snort esta viendo los paquetes.
En este modo tenemos las siguientes opciones:

-v Imprime en la pantalla los encabezados de los paquetes TCP/IP en Ethernet
-d Igual que la opción anterior pero además imprime los datos de la capa de aplicación
-e Igual que la opción anterior pero además imprime la capa de enlace de datos
Hay que incluir al menos el comando -v para utilizar el modo sniffer de paquetes.
Estos serian algunos ejemplos de su uso:

#snort -v
#snort -vde
Pulsamos CTRL+C para salir y veremos un resumen de la sesión de escucha de la red.
La siguiente salida, es una conexión a una página web desde el servidor:

#snort -v
Running in packet dump mode
Initializing Network Interface eth0
--== Initializing Snort ==--

Initializing Output Plugins!
Decoding Ethernet on interface eth0
--== Initialization Complete ==--
,,_ -*> Snort! <*-

o" )~ Version 2.3.2 (Build 12)
’’’’ By Martin Roesch & The Snort Team: http://www.snort.org/team.html
(C) Copyright 1998-2004 Sourcefire Inc., et al.
06/09-13:09:39.402225 195.149.189.15:80 -> 192.168.0.11:3516

TCP TTL:62 TOS:0x0 ID:47630 IpLen:20 DgmLen:52 DF
***A***F Seq: 0xB744B52F Ack: 0x34B0D324 Win: 0x1974 TcpLen: 32
TCP Options (3) => NOP NOP TS: 217975842 8827642
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/09-13:09:39.442220 192.168.0.11:3516 -> 195.149.189.15:80

***A**** Seq: 0x34B0D324 Ack: 0xB744B530 Win: 0x736 TcpLen: 32
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/09-13:09:43.433979 192.168.0.11:3516 -> 195.149.189.15:80

***A***F Seq: 0x34B0D324 Ack: 0xB744B530 Win: 0x736 TcpLen: 32
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/09-13:09:43.819445 195.149.189.15:80 -> 192.168.0.11:3516

***A**** Seq: 0xB744B530 Ack: 0x34B0D325 Win: 0x1974 TcpLen: 32
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
..........................................................................
..........................................................................

==========================================================================
Snort received 263 packets

Analyzed: 263(100.000%)
Dropped: 0(0.000%)
==========================================================================
Breakdown by protocol:
TCP: 247 (93.916%)
UDP: 12 (4.563%)
ICMP: 0 (0.000%)
ARP: 4 (1.521%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
==========================================================================
Action Stats:
ALERTS: 0
LOGGED: 0
PASSED: 0
==========================================================================
Snort exiting
Modo de registro de paquetes

Este modo es similar al anterior pero nos permite registrar paquetes “olfateados” al disco para su
utilización y análisis futuros. Para ejecutar Snort en el modo de registro de paquetes, simplemente lo
ejecutamos con los mismos comandos que en el modo sniffer de paquetes, pero añadiendo un modificador
adicional: -l logpath, reemplazando logpath con la ruta de acceso en la que deseamos que Snort registre los
paquetes (tiene que ser un directorio).
Por ejemplo: #snort -vde -l /var/log/snort
Creará archivos de registro en el directorio /var/log/snort. Snort registra paquetes por dirección IP y
crea un directorio independiente para cada IP registrada. Si estamos registrando tráfico en una red local
grande con muchas direcciones, esto puede escaparse rápidamente a nuestro control.
Podemos utilizar otra configuración para indicarle a Snort que registre los paquetes de la LAN en la
que se encuentra con el comando: -h homenet, donde homenet es el rango de direcciones IP en la notación
de barra inclinada. Esto hace que Snort coloque las direcciones basándose en la dirección IP del paquete
externo a la LAN, para poder ver con más facilidad el tráfico ajeno a la red. Si tanto los anfitriones de
destino como de origen son locales, Snort los coloca en el directorio con el número de puerto superior,
aparentemente para recoger el host de conexión sobre el host servidor.
Snort utiliza la dirección de origen como nombre del directorio en el que se colocarán los datos de los
paquetes, cuando registramos alertas de intrusión es importante saber con facilidad de dónde está provi-
niendo el tráfico de alertas marcado.
Por lo tanto, el comando para el modo de registro de paquetes será:

#snort -vde -l /var/log/snort -h 192.168.0.0/24
Esta declaración especifica una red interna en el rango comprendido entre 192.168.0.1 y 192.168.0.254.
También podemos utilizar la opción: -b para registrar todos los datos en un solo archivo binario,
apropiado para su lectura posterior con un sniffer de paquete (como Ethereal o Tcpdump). Si se realiza
ası́ el registro, no es necesario especificar la red local al utilizar el modificador -b ya que registrará los
archivos secuencialmente en un gran archivo. Este método es mucho más rápido para registrar redes de
muchos registros o si Snort funciona en un máquina lenta. También facilita el análisis con herramientas
más complejas, algo necesario si vamos a buscar sobre una gran cantidad de datos de red capturados.
Modo de detección de intrusión (IDS)

Este modo lo utiliza Snort para registrar paquetes sospechosos o que merecen una consideración es-
pecial. Sólo necesitamos un modificador adicional a la declaración anterior para que Snort entre en este
modo. El modificador: -c configfile, le indica a Snort que utilice un archivo de configuración para dirigir
los paquetes que registra. Este archivo determina la configuración de Snort, se incluye un archivo prede-

terminado, pero debemos realizar cambios antes de ejecutarlo, para que refleje nuestro perfil de red.
Por lo tanto, si escribimos:

#snort -de -l /var/log/snort -h 192.168.0.0/24 -c /etc/snort/snort.conf
Ejecutaremos Snort en modo IDS utilizando el archivo de configuración snort.conf predeterminado.

Hay que tener en cuenta que no hemos utilizado el modificador -v para ejecutar Snort en modo IDS.
Cuando intentamos comparar todos los paquetes con las firmas, obligar a Snort a escribir también las
alertas en la pantalla puede causar que algunos paquetes se omitan, especialmente en redes con mucho
tráfico. También podemos omitir el modificador -e si no necesitamos registrar las capas de enlace de datos.
Si omitimos el modificador -l, Snort de forma predeterminada utilizará /var/log/snort como su directorio
de registro. También podemos utilizar el modificador -b si deseamos registrar un archivo binario para un
análisis posterior con un programa independiente.
El comando para ejecutar Snort en el modo IDS es:

#snort -h 192.168.0.0/24 -c /etc/snort/snort.conf
13.5.4. Modos de alerta

Ahora que ya estamos registrando los paquetes de alerta, tendremos que decidir el detalle y el formato
de la alerta. El cuadro 13.1 incluye una lista con las opciones que podemos usar desde la lı́nea de comandos,
utilizando el modificador -A.
Cuadro 13.1: Opciones de alerta del comando Snort

-A full Información completa de la alerta, incluyendo datos de aplicación. Es el modo prede-
terminado de alerta y se utilizará cuando no especifiquemos nada.
-A fast Modo rápido. Registra sólo la información de encabezado del paquete y el tipo de
alerta. Es útil para redes muy rápidas pero si se necesita más información forense hay
que utilizar el modificador full.
-A unsock Reenvı́a la alerta a un socket
-A none Desactiva las alertas.
También podemos utilizar las opciones, Syslog, SMB y opciones de salida de bases de datos. Estas
opciones no utilizan el modificador -A desde la lı́nea de comandos sino módulos de salida independientes
que ofrecen una variedad más amplia de opciones de salida. Éstas deben configurarse en el tiempo de
compilación con modificadores añadidos a la declaración de configuración.
SMB : Envı́a las alertas al servicio de menú emergente de Windows. Para esta opción hay que
descargar las fuentes y compilarlas con la opción enable-smbalerts.
Para ejecutar Snort con esta configuración: #snort -c /etc/snort/snort.conf -M workstations
Donde workstations es el nombre del host Windows al que se envı́an las alertas.
Syslog: Envı́a alertas al servidor Syslog de Unix. Este es un servicio, que captura y guardar archivos
de registro, lo que nos ayudará a consolidar registros de red en un lugar único. Este servicio dificulta
a un intruso borrar los rastros de la intrusión. Podemos especificar los formatos Syslog dentro del
archivo de configuración y enviar ahı́ las alertas incluyendo el modificador -s.
Snort admite directamente cuatro tipos de salida a base de datos: MySQL, PostgreSQL, Oracle y
unixODBC. El módulo de salida de base de datos requiere: parámetros y configuraciones, dentro del
archivo de configuración y en tiempo de compilación.

13.5.5. Optimizar la configuración

Ahora que ya sabemos cómo funciona Snort y conocemos los comandos básicos, tendrémos que editar
el archivo de configuración para convertirlo en un IDS fiable y obtener los resultados deseados. Muchas
lı́neas del archivo contienen información útil para aclarar cada una de las partes de la configuración.
Para definir el archivo de configuración seguiremos los siguientes pasos:
1. Establecemos nuestra red local : Tendremos que indicarle a Snort las direcciones de nuestra red local
para que pueda interpretar correctamente los ataques provenientes del exterior. Para ello utilizaremos
la siguiente declaración:
var HOME_NET addresses
Donde debemos de reemplazar addresses con el espacio de direcciones de nuestra red local. Si existen
múltiples redes, podemos introducirlas todas separándolas por comas. Podemos incluso introducir
un nombre de interfaz y utilizar la dirección IP y la máscara de red asignada a dicha interfaz como
nuestro HOME NET. El formato para hacerlo es:
var HOME_NET $ interfacename
Donde debemos reemplazar interfacename con la interfaz de red donde está escuchando Snort.
También podemos definir nuestras redes externas con una declaración similar a HOME NET, reem-
plazándola por EXTERNAL NET. La entrada predeterminada para ambas variables es any. Es
recomendable definir la red interna pero dejar la red externa a any.
2. Configuramos los servidores internos: En el archivo de configuración podemos definir nuestros ser-
vidores de red, incluyendo web, mail, dns, telnet, . . . Ası́, limitaremos los falsos positivos para los
servicios en esas máquinas.
También podemos especificar los números de puertos para dichos servicios, entonces si nuestros
usuarios usan ese puerto, no se registrará ninguna alerta. Todas estas opciones de configuración
pueden ayudarnos a reducir el número de falsos positivos que obtenemos y alertarnos sólo con
información que tiene valor real.
3. Configuramos los decodificadores y procesadores previos de Snort: Diversos modificadores y configu-
raciones controlan los decodificadores y procesadores previos de Snort en el archivo de configuración.
Estas rutinas se ejecutan en el tráfico antes de pasar por ningún conjunto de reglas, normalmente
para formatearlas correctamente o para tratar con un tipo determinado de tráfico que sea más fácil de
procesar directamente en lugar de utilizar los conjuntos de reglas. Un ejemplo de este tipo de tráfico
serı́an los paquetes fragmentados-defragmentados. Muchos ataques intentan ocultar su verdadera
naturaleza fragmentando los paquetes, en esos casos, esta opción es muy valiosa.
Otro decodificador es para los paquetes de escaneado de puertos. Como éstos suelen entrar en grupos
y con un gran volumen, es mejor procesarlos directamente en masa en lugar de intentar comparar
cada paquete con una firma. Esto hace que el IDS sea más seguro ante una denegación de servicio.
Las configuraciones predeterminadas para estos subsistemas son muy generales, a medida que expe-
rimentemos con Snort, podremos ajustarlas para obtener un mejor rendimiento y resultados.
4. Configuramos los módulos de salida: Es un paso importante si deseamos utilizar una base de datos
para controlar las salidas de Snort. Como ya hemos visto anteriormente, existen varios módulos de
salida que podemos utilizar, dependiendo del formato en el que deseemos los datos: Syslog, Database
y el nuevo módulo denominado Unified, que es un formato binario genérico para exportar datos a
otros programas.

El formato general para configurar los módulos de salida es:

output module_name: configuration options
Siendo module name bien alert syslog, database o alert unified dependiendo del módulo que cargue-
mos.
Las opciones de configuración para cada módulo de salida son las siguientes:
Syslog:
output alert_syslog: LOG_AUTH LOG_ALERT
output alert_syslog: host= hostname:port, LOG_AUTH LOG_ALERT
Donde hostaname y port son la dirección IP y el puerto de nuestro servidor Syslog.
Database:
output database: log, database_type, user= user_name
password= password dbname host= database_address
Donde debemos reemplazar database type por una base de datos válida, user name por un
nombre de usuario válido en la base de datos y password por la contraseña asociada al usuario.
La variable dbname identifica el nombre de la base de datos en la que se va a realizar el registro.
Por último, database address es la dirección IP del servidor que contiene la base de datos.
No se recomienda intentar ejecutar Snort y la base de datos en el mismo servidor, suele provocar
una bajada considerable del rendimiento del sistema.
Unified : Es un formato binario básico para registrar los datos y usarlos en el futuro.
Los dos argumentos adminitidos son filename y limit:
output alert_unified: filename snort.alert, limit 128
5. Personalizamos los conjuntos de reglas: El archivo snort.conf permite añadir o eliminar clases enteras
de reglas. En la parte final del archivo podremos ver todos los conjuntos de reglas de alertas.
Podemos desactivar toda una categorı́a de reglas comentando la lı́nea. Por ejemplo, podrı́amos
desactivar todas las reglas icmp-info para reducir los falsos positivos del tráfico ping o todas las
reglas NetBIOS si no tenemos máquinas Windows en nuestra red. También podemos encontrar
disponibles conjuntos de reglas que se han ajustado para entornos especı́ficos.
13.5.6. Clases de reglas

La forma más fácil de limitar el tráfico de las alertas es desactivar reglas que no se aplican en nuestro
sistema, esto lo podemos hacer entrando en la configuración de Snort. El directorio /etc/snort/rules/
contiene muchos archivos con la extensión .rules, cada uno de ellos contiene las reglas agrupadas por
categorı́a.
Podemos deshabilitar toda una clase de reglas comentándola en el archivo de configuración o podemos
deshabilitar reglas individuales si queremos la protección del resto de reglas de la clase. Para comentar
una regla concreta, la buscamos en los archivos .rules apropiados e insertamos un comentario delante de
la lı́nea de dicha regla. Hay que tener en cuenta que normalmente es mejor deshabilitar un sola regla que
toda la clase, a no ser que ésta no se aplique en nuestra configuración.
En el cuadro 13.2 podemos observar una lista con las clases de reglas más habituales en Snort y una
pequeña descripción de las mismas.

Cuadro 13.2: Clases de reglas de Snort (I)

Clase de reglas Descripción
attack-response.rules Son las alertas para paquetes de respuesta comunes después de que un ata-
que haya tenido éxito. Raramente se informan como falsos positivos y de-
bemos dejarlas activadas en la mayorı́a de los casos.
backdoor.rules Estas reglas son signos comunes de una puerta trasera o de un programa
troyano en uso. Raramente son falsos positivos.
bad-traffic.rules Estas reglas representan el tráfico de red no estándar que normalmente no
deberı́a verse en la mayorı́a de las redes.
chat.rules Localizan transmisiones estándar para muchos programas conocidos de con-
versación. Si la conversación se permite implı́citamente o explı́citamente es-
tas alertas deben estar deshabilitadas. Ası́ mismo, hay que tener en cuenta
que estas alertas no son una solución milagrosa para las conversaciones y
no detectarán todos los tipos de tráfico de conversaciones.
ddos.rules Busca tipos de ataques de denegación de servicio distribuido estándares. En
DMZ y WAN, estas alertas no sirven de mucho porque si se ha producido
un ataque de este tipo probablemente lo sepamos en seguida. Sin embargo,
pueden ser muy útiles dentro de una LAN para comprobar si tenemos una
máquina zombi en otra red participando en un ataque de denegación de
servicio (DoS) sin saberlo.
dns.rules Buscan algunos abusos estándar contra servidores DNS. Si no estámos eje-
cutando un servidor DNS propio, podemos desactivarlas.
dos.rules Similar al conjunto de reglas anterior.
experimental.rules Están deshabilitadas de forma predeterminada. Generalmente se utilizan
sólo para probar nuevas reglas hasta que se desplazan a otra categorı́a.
exploit.rules Estas reglas son para el tráfico de abuso estándar, siempre habilitadas.
finger.rules Estas reglas marcan el tráfico que tiene que ver con los servidores finger. Si
no estámos ejecutando ninguno de estos servidores, las podemos deshabili-
tar. Sin embargo, este tipo de servidores normalmente se ejecutan ocultos
al administrador del sistema, por lo que podemos dejarlas habilitadas, ya
que no suelen generar falsos positivos.
ftp.rules Igual que las reglas anteriores pero buscan abusos de FTP. Una vez más,
podemos dejarlas habilitadas aunque no tengamos servidores FTP ya que
nos avisarán de cualquier servidor FTP ilegal en el sistema.
icmp-info.rules Estas reglas registran el uso de los mensajes ICMP que cruzan la red, por
ejemplo, los ping. A menudo producen falsos positivos, podemos desacti-
var toda la clase a no ser que deseemos estar pendientes del tráfico ICMP
en nuestra red. Otra clase de tráfico ICMP dañino conocido, icmp.rules,
captura los escaneados de puertos y similares.
icmp.rules Cubre el tráfico ICMP sospechoso o dañino y es poco propenso a generar
falsos positivos. Sin embargo, es posible que se activen en una red ocupada
ejecutando muchos servicios de diagnóstico.
imap.rules Reglas correspondientes al uso del protocolo de acceso a mensajes desde
internet (IMAP, Internet Message Access Protocol).
info.rules Capturan mensajes de errores diversos: Web, FTP y otros servidores.
local.rules En este archivo podemos añadir nuestras propias firmas o reglas personali-
zadas para la red, el archivo está vacı́o de forma predeterminada.
misc.rules Reglas que no encajan en ninguna de las restantes categorı́as.
multimedia.rules Registra el uso de software de vı́deo. Si permitimos las aplicaciones de vı́deo
o utilizamos video-conferencia, debemos deshabilitar estas reglas.

Cuadro 13.3: Clases de reglas de Snort (II)

mysql.rules Vigila el acceso del administrador y otros archivos importantes en una base
de datos MySQL. Si no ejecutamos este tipo de base de datos, podemos des-
habilitar estas alertas. Ası́ mismo, si nuestra base de datos MySQL está en
desarrollo, podrı́an producirse muchos falsos positivos.
Netbios.rules Esta clase de reglas nos alerta de diversa actividad NetBIOS en la LAN.
Algunas de ellas son exploits evidentes. Sin embargo, otras, como las alertas
de sesión NULL, pueden producirse normalmente en una LAN Windows.
Tendrémos que jugar con esta sección para deducir cuáles son las reglas
apropiadas en nuestra LAN.
nntp.rules Reglas relacionadas con el servidor de noticias. Si no ejecutamos noticias de
red en los servidores, es mejor deshabilitar estas reglas.
oracle.rules Reglas del servidor de base de datos Oracle. Si no tenemos un servidor de
este tipo, las deshabilitamos.
other-ids.rules Estas reglas se relacionan con exploits en los IDS de otros fabricantes. Es
muy probable que no tengamos ningún otro NIDS en la LAN, pero si es
ası́ hay que dejarlas habilitadas.
p2p.rules Reglas que rigen el uso del software para compartir archivos punto a punto.
Estas reglas crearán alertas durante el uso normal de este software, si lo
permitimos, deberemos deshabilitarlas.
policy.rules Este archivo contiene diversas alertas relacionadas con toda la actividad
permitida en la LAN, como Go-to-my-pc y otros programas. Debemos re-
visarlas y habilitar sólo las que se aplican en nuestras polı́ticas internas.
pop3.rules Para servidores de correo, si tenemos un servidor de este tipo, hay que
dejarlas habilitadas.
porn.rules Estas reglas son trampas rudimentarias para la exploración web relacionada
con la pornografı́a. No constituyen ni mucho menos un reemplazo para los
buenos sistemas de filtrado de contenido.
rpc.rules Esta clase controla las alertas de llamadas a procedimientos remotos (RPC).
Aunque creamos no ejecutar ninguno de estos servicios, normalmente se
activan como parte de otros programas, por lo que es importante tener
cuidado con lo sucede en la LAN. RPC puede habilitar la ejecución remota
de código y normalmente se utiliza en los troyanos y exploits.
rservices.rules Registra el uso de diversos programas de servicios remotos, como rlogin y
rsh. Estas reglas en general, son de servicios inseguros, pero si tenemos que
utilizarlos, pueden examinarse con este conjunto de reglas.
scan.rules Alertas para utilizar programas de escaneado de puertos. Los escaneados de
puertos son una indicación extraordinaria de una actividad ilı́cita. Si utiliza-
mos escáneres de puertos, podemos desactivar Snort durante su ejecución o
deshabilitar esta regla en concreto para la IP donde se encuentra el escáner.
shellcode.rules Esta clase busca paquetes que contienen código de montaje, comandos de
bajo nivel también conocidos como código shell. Estos comandos normal-
mente forman parte integral de muchos exploits como los desbordamientos
de memoria. Capturar al momento un código shell es una buena indicación
de que se está produciendo un ataque.
smtp.rules Contienen las alertas para el uso del servidor de correo en la LAN. Esta
sección necesitará algún ajuste ya que muchas actividades de servidor de
correo normales activarán reglas de esta sección.
sql.rules Reglas para diversos programas de base de datos SQL. Si no ejecutamos nin-
guna base de datos, podemos deshabilitarlas, pero no es mala idea dejarlas
por si existen bases de datos SQL ejecutándose sin que lo sepamos.

Cuadro 13.4: Clases de reglas de Snort (III)

telnet.rules Registra el uso de telnet sobre la red. Normalmente telnet se utiliza en
enrutadores o en otros dispositivos de lı́nea de comandos, por lo que es
recomendable realizar el registro incluso si telnet no está en nuestros servi-
dores.
tftp.rules TFTP (FTP trivial) es un servidor FTP alternativo que se ejecuta normal-
mente en enrutadores. Puede utilizarse para cargar nuevas configuraciones
y por consiguiente es mejor que este conjunto de reglas esté habilitado.
virus.rules Contiene las firmas de algunos gusanos y virus conocidos. Esta lista no
está completa y no se mantiene con regularidad. No es un reemplazo para
el software de escaneado de virus pero puede capturar algunos gusanos que
se transmitan por la red.
web-attacks.rules Todas estas clases se refieren a diversos tipos de actividad web sospechosa.
web-cgi.rules Algunas son genéricas, como las clases web-attacks. Otras clases, como
web-client.rules web-iis y web-frontpage, son especı́ficas de una determinada plataforma de
web-coldfusion.rules servidor web. Sin embargo, aunque creamos que no estamos ejecutando un
web-frontpage.rules servidor web Microsoft o PHP, es mejor dejarlas habilitadas para descubrir
web-iis.rules cualquier tipo de esta actividad en nuestra LAN de la que debamos preocu-
web-php.rules parnos. Tendremos que ajustar estos conjuntos de reglas, especialmente si
los servidores web se encuentra en un desarrollo activo.
X11.rules Registra el uso del entorno gráfico X11 en su red.
13.5.7. Ejecutar como servicio del sistema

Si vamos a ejecutar Snort en un servidor que se va a utilizar las 24 horas del dı́a, siete dı́as a la semana,
tendremos que ejecutar Snort inmediatamente al inicio para que, en el caso en el servidor caiga, se pueda
volver a cargar Snort y siga protegiendo nuestra LAN. Una forma de conseguirlo es tener una pequeña
secuencia de comandos que ejecute Snort con los parámetros de lı́nea de comandos en las rutinas de inicio.
Deberemos colocar el comando de arranque de Snort.
Como por ejemplo: snort -h 192.168.0.0/24 -c /etc/snort/snort.conf &
El signo de concatenación & indica que se debe ejecutar Snort como un proceso en segundo plano.
13.5.8. Configuración gráfica de Snort, interfaz Webmin

Realizar toda la configuración para Snort desde la lı́nea de comandos puede llegar a ser algo tedioso.
Aunque todavı́a no existe una interfaz gráfica para Snort, existe un módulo para la conocida herramien-
ta de administración web Webmin que nos permite realizar ajustes y configuraciones desde un servidor web.
Algunas de las ventajas de este sistema son:
Acceso a los archivos de configuración de Snort, basado en un formulario.
Niveles de acceso de usuario que permiten configurar diferentes usuarios con diferentes derechos.
Capacidad para para habilitar y deshabilitar conjuntos de reglas mediante un simple clic.
Indicador de estado para todas las reglas y conjuntos de reglas.
Enlaces incrustados a bases de datos externas como archNIDS, CVE y Bugtraq.
Registro de cambios.
Diferentes idiomas.

Soporte para ejecutar Snort como servicio utilizando archivos rc.d.

Administración remota segura a través de SSL (si esta habilitado).
El módulo de Snort requiere la versión 0.87 de Webmin o superior. Instalaremos el módulo con apt:
#apt-get install webmin-snort
Para acceder al sistema, con SSL y si no hemos cambiado el puerto por defecto:
https://localhost:10000
Una vez iniciada la sesión en la página de Snort (véase figura 13.1), podremos ver las secciones prin-
cipales del archivo de configuración, las configuraciones del procesado previo y las opciones de inicio de
sesión en la parte superior de la ventana. Haga clic en cualquiera de las opciones de configuración para
introducir su información personal para que Webmin realice los cambios apropiados en los archivos de
Snort.
Figura 13.1: Módulo Webmin de Snort
Todos los conjuntos de reglas aparecen en una lista, podemos ver cuáles están habilitados y cuales no.
Si queremos visualizar dicho conjunto de reglas o modificar una regla individual, hacemos clic en el
texto subrayado de color azul para dirigirnos a la página Edit RuleSet (editar conjunto de reglas). Aquı́ se
encuentran todas las reglas individuales dentro de dicho conjunto. Podemos ejecutar acciones en cada
regla como deshabilitarla, habilitarla o eliminarla del conjunto.
Si existen referencias a bases de datos externas dentro de la alerta, como los números de Vulnerabilidad
o exploit comúnes (VCE, Common Vulnerability or Exploit), podemos hacer clic en un hipervı́nculo para
abrir más detalles sobre lo que hace la alerta. En esta interfaz se puede ajustar el conjunto de alertas más
fácilmente.
Con el módulo Webmin Snort también podemos configurar usuarios para que puedan acceder a de-
terminadas configuraciones. Esto se realiza mediante el control de usuarios de Webmin, en la sección

correspondiente de acceso a Snort. Podemos controlar los archivos de configuración a los que pueden ac-
ceder o simplemente dejar que visualicen los archivos sin poder editar ninguno de ellos. Como se puede
comprobar, el módulo Webmin Snort nos proporciona un control de acceso granular para que podamos
delegar las tareas diarias en usuarios con privilegios de administración, a la vez que seguimos conservando
el control de la configuración y los cambios.
13.5.9. Personalizar reglas

Aunque los conjuntos de reglas estándar incluidos en Snort proporcionan una protección adecuada
contra firmas de ataques conocidas, podemos diseñar algunas reglas personalizadas especı́ficas para que
nuestra red obtenga el mejor rendimiento del IDS.
Se pueden escribir reglas para:

Registra el acceso hacia o desde determinados servidores.
Buscar determinados tipos de nombres de archivos especı́ficos en nuestra organización.
Vigilar determinados tipos de tráfico que no pertenecen a nuestra propia red.

La escritura de reglas de Snort es fácil de aprender y nos permite añadir funcionalidades al programa,
sin muchos conocimientos de programación. Como hemos podido comprobar, las reglas de Snort son
simplemente declaraciones de texto dentro de un archivo de reglas.
Si deseamos que Snort busque un comportamiento único que deberı́a ser sospechoso en nuestra red,
podemos codificar rápidamente una regla y probar el resultado. El formato de una regla de Snort es bási-
camente una sola lı́nea de texto que empieza con una acción (normalmente alert) seguida por diversos
argumentos. Se pueden añadir multiples lı́neas simplemente añadiendo una barra inclinada (/) al final
de cada lı́nea. También se puede llamar a otros programas utilizando una declaración de inclusión para
obtener una regla más compleja.
En su forma básica, una regla de Snort consta de dos partes:
Un encabezado de regla
Las opciones de la regla
Aquı́ tenemos un ejemplo:
alert tcp any any 192.168.0.0/24 /
(content:"|00 05 A4 6F 2E|";msg:"Test Alert";)
El encabezado de la alerta es la parte anterior al paréntesis de apertura. Esta declaración contiene la

acción (en este caso, alert), el protocolo y las direcciones de puertos de origen y destino. La acción es lo
que va a hacer la regla, si esta es verdadera.
Las opciones para las acciones son:
alert Alerta del cumplimiento de la regla.

log Sólo registra el paquete.
pass Ignora el paquete, es la acción predeterminada en paquetes que no coin-
ciden con la regla.
activate Alertar y a continuación activar una regla dinámica.
Dynamic Permanecer inactiva hasta que se active, a partir de entonces actúa como
una regla normal registro.

Los protocolos puede ser tcp, udp, icmp o ip, lo que significa cualquier protocolo IP (puede que en un
futuro se admitan protocolos no basados en IP, como IPX).
Los puertos de origen y destino se explican por sı́ mismos. La dirección de origen es la primera, lis-
tada en la notación de barra inclinada estándar para los rangos IP. También podemos listar múltiples
direcciones individuales y redes separándolas con una coma, sin espacios y escribiendo la declaración entre
corchetes, por ejemplo:
alert tcp any <> [192.168.0.2,192.168.0.5,192.168.0.10] 80 /

(content:"|00 05 A4 6F 2E|";msg:"Test Alert";)
Esta sentencia se centra en el tráfico que proviene de cualquier dirección enlazada para las máquinas
192.168.0.2, 192.168.0.5 y 192.168.0.10 en el puerto 80. Suponiendo que se tratan de nuestros servidores
Web, la sentencia buscarı́a el tráfico entrante con los datos hexadecimales de la sección de contenido.
La segunda parte de una alerta Snort son las opciones de la regla. Aquı́ es donde podemos especificar
más detalles sobre el tipo de tráfico que estamos buscando. Podemos buscar según los campos del encabe-
zado TCP/IP o buscar simplemente la cargar útil del paquete. Después de cada comando debemos incluir
comillas y el valor que se está buscando. Podemos añadir múltiples opciones separándolas con un punto y
coma.
El cuadro 13.5 contiene los comandos de opción válidos en la confección de reglas.
13.6. Detección de intrusiones en el host

Hemos tratado con detalle la detección de intrusiones basadas en redes (NIDS). Sin embargo, existen
otras formas de encontrar intentos de intrusión.
Un método alternativo es buscar signos de intrusión en el propio sistema. Si se ha aprovechado un
exploit en una máquina, normalmente se alterarán determinados archivos del sistema. Por ejemplo, puede
cambiar el archivo de contraseñas, pueden añadirse usuarios, pueden modificarse archivos de configuración
del sistema o se pueden alterar los permisos de algunos archivos. Normalmente, estos archivos de sistema
no deberı́an cambiar mucho. Al buscar modificaciones podemos detectar una intrusión u otra actividad
inusual.
Este método de detección de intrusión puede ser mucho más preciso, produciendo menos falsos posi-
tivos ya que no se activan a no ser que un sistema esté realmente afectado. Algo más complicado es el
mantenimiento ya que tenemos que cargar el software en cada sistema que deseamos proteger.
Podemos afirmar que merece la pena el tiempo y el esfuerzo empleados para detectar las intrusiones
basadas en hosts y en redes con el fin de proteger los sistemas que ejecutan tareas crı́ticas.
Los métodos de detección de intrusión basados en hosts tienen las siguientes ventajas:
Menos falsos positivos.

Se registran actividades en lugar de firmas, no necesitan actualizaciones constantes de firmas.
Necesitan menos ajustes.
Los métodos de detección de intrusión basados en hosts tienen los siguientes inconvenientes:
Hay que cargar y administrar el software en cada host a proteger.

La alerta tiene lugar después de que un ataque haya tenido éxito. Muy pocas veces los IDS de host
nos proporcionan un aviso previo.

Cuadro 13.5: Opciones de personalización en las reglas de Snort

msg Proporciona la descripción del texto de una alerta.
logto Registra el paquete para un nombre de archivo especı́fico de un usuario en lugar de para
el archivo de salida estándar.
ttl Prueba el valor del campo TTL del encabezado IP.
tos Prueba el valor del campo TOS del encabezado IP.
id Prueba el campo ID del fragmento del encabezado IP para un valor especı́fico.
ipoption Vigila los campos de opción IP buscando códigos especı́ficos.
fragbits Prueba los bits de fragmentación del encabezado IP.
dsize Prueba el tamaño de carga útil del paquete frente a un valor.
flags Prueba los indicadores TCP para determinados valores.
seq Prueba el campo de número de secuencia TCP para un valor especı́fico.
ack Prueba el campo de reconocimiento TCP para un valor especı́fico.
itype Prueba el campo de tipo ICMP frente a un valor especı́fico.
icode Prueba el campo de código ICMP frente a un valor especı́fico.
icmp id Prueba el campo ICMP ECHO ID frente a un valor especı́fico
icmp seq Prueba el número de secuencia ICMP ECHO frente a un valor especı́fico.
content Busca un patrón en la carga útil del paquete.
content-list Busca un conjunto de patrones en la carga útil del paquete.
offset Modificador para la opción de contenido. Establece la compensación en el intento de
coincidencia con el patrón.
depth Modificador para la opción de contenido. Establece la profundidad de búsqueda para un
intento de coincidencia con el patrón.
nocase Compara la cadena de contenido anterior sin tener en cuenta las mayúsculas y las
minúsculas.
session Descarga la información de la capa de aplicación para una determinada sesión
rpc Vigila los servicios RPC en búsqueda de determinadas llamadas de aplicaciones o proce-
dimientos.
resp Respuesta activa (por ejemplo, cerrar todas las conexiones).
react Respuesta activa. Responde con un conjunto de comportamientos cifrados (por ejemplo,
bloquear determinados sitios web).
referernce Los ID de referencia de ataques externos.
sid ID de regla Snort.
rev Número de revisión de regla.
classtype Identificador de clasificación de regla.
priority Identificador de severidad de regla.
uricontent Busca un patrón en la parte URI del paquete.
tag Acciones de registro avanzadas para las reglas.
ip proto Valor de protocolo del encabezado IP.
sameip Determina si la IP de origen es igual a la IP de destino.
stateless Válido independientemente del estado del flujo.
regex Coincidencia de patrón de caracteres comodı́n.
byte test Evaluación numérica.
distance Obliga a que la coincidencia de patrón relativa omita determinado número de bytes en
el paquete.
byte test Prueba numérica del patrón.
byte jump Prueba numérica del patrón y ajuste de compensación

13.7. Integridad de archivos: IDS Tripwire

Originalmente, Tripwire era de libre distribución. Al final, los creadores fundaron una empresa para
venderlo y soportarlo comercialmente. Sin embargo, cogieron el código base original y lo distribuyeron
con licencia GPL para que pudiera continuar su desarrollo en la comunidad de la libre distribución. Esta
versión libre se ha ido actualizando desde su lanzamiento (versión 2.2.1).
Ambas versiones funcionan creando una base de datos de atributos básicos, archivos importantes que
deseamos registrar para comprobar los atributos reales, en cualquier momento, frente a los atributos
básicos. Con ello determinaremos si ha cambiado algo.
Uno de los trucos favoritos de los piratas informáticos, una vez introducidos en un sistema, es reempla-
zar los archivos binarios clave con versiones de su propia cosecha. Ası́ cuando utilizamos comandos como
ls o ps, no vemos sus archivos ilı́citos ni la ejecución de determinados procesos. También podemos utilizar
Tripwire durante una investigación forense para descubrir dónde ha estado un intruso, es como seguir las
huellas digitales de una persona.
Para instalar el programa hacemos un apt:

#apt-get install tripwire
Configurar Tripwire
Antes de ejecutar Tripwire hay que establecer la polı́tica. El archivo de polı́ticas es muy importante
para el funcionamiento de Tripwire: le indica que archivos debe vigilar y a qué nivel de detalle debe
introducirse. El archivo principal de polı́ticas es: /etc/tripwire/twpol.txt. Éste no es el propio archivo de
polı́ticas, sino una copia de la versión cifrada que el programa utiliza. Para obtener una mejor seguridad,
deberı́amos hacer una copia y eliminarlo, una vez establecidas y probadas sus polı́ticas.
Este archivo contiene en su parte superior algunas variables, un listado de los diversos archivos y
directorios que se chequearan, las directivas y las polı́ticas que les aplicaremos.
Estas directivas se representan mediante letras de código o nombres de variable, denominadas máscaras
de propiedad, y representan las propiedades que está registrando Tripwire.
El cuadro 13.6 recoge la lista de los elementos que se pueden registrar para cada archivo y sus letras
de código.
Cuadro 13.6: Máscaras de propiedad de Tripwire
Letras de código Atributos registrados

a Último acceso
b Bloques asignados
c Crear/modificar hora
d Dispositivo ID en el que reside el i-nodo
g ID de grupo del propietario del archivo
i Número de i-nodo
l Si se permite crecer el archivo
m Modificación de la fecha y hora impresa
n Número de enlaces al i-nodo
p Leer/escribir/ejecutar permisos en el archivo
s Tamaño del archivo
t Tamaño del tipo
u ID de usuario del propietario del archivo
c Código CRC32
h Código Haval
m Código MD5
s Código SHA/SHS

Las polı́ticas de Tripwire operan sobre el concepto de ignorar los indicadores. Podemos configurar Trip-
wire para que registre o ignore diferentes propiedades de archivo. Para registrar propiedades utilizamos
un signo más (+) y para ignorarlas un signo menos (-).
El formato para la declaración de un archivo de polı́ticas es el siguiente:

file/directory name -> property mask;
Por ejemplo, esta lı́nea en el archivo de polı́ticas:

/etc/secreto.txt -> +amcpstu;
Producirı́a que Tripwire nos notificase en cualquier momento, cuándo se produjo el último acceso, la
fecha de creación o modificación, los permisos, la propiedad o el tamaño del tipo de archivo, cambiado en
el archivo /etc/secreto.txt.
Existen además diversas máscaras de propiedad predefinidas. En el cuadro 13.7 se incluyen dichas
máscaras plantilla y sus efectos.
Cuadro 13.7: Máscaras de propiedad de plantillas
Máscara de propiedad Efectos

$Readonly +pinugtsdbmCM-rlasSH
$Dynamic +pinugtd-srlbamcCMSH
$Growing +pinugtdl-srbamcCMSH
$Device +pugsdr-intlbamcCMSH
$IgnoreAll -pinugtsdrlbamcCMSH
$IgnoreNone +pinugtsdrlbamcCMSH
Estas variables predefinidas encajan en el comportamiento de diferentes conjuntos de archivos. Por

ejemplo, podemos utilizar $Readonly para nuestros archivos de configuración clave, ya que sus fechas
de acceso estarán continuamente cambiando cuando los programas los utilicen, pero no deseamos que el
contenido o el tamaño cambien. Podemos utilizar $Growing para nuestros archivos de registro ya que están
constantemente creciendo.
El archivo de configuración de polı́ticas también define algunas variables que son combinaciones de las
configuraciones predeterminadadas anteriores con algunas adiciones o sustracciones, proporcionándonos
un establecimiento rápido para las polı́ticas de diversas clases de archivos.
El siguiente código muestra las variables contenidas en el archivo /etc/tripwire/twpol.txt:

@@section GLOBAL
TWBIN = /usr/sbin;
TWETC = /etc/tripwire;
TWVAR = /var/lib/tripwire;
#
# File System Definitions
#
@@section FS
#
# First, some variables to make configuration easier
#
SEC_CRIT = $(IgnoreNone)-SHa ;# Critical files that cannot change
SEC_BIN = $(ReadOnly) ; # Binaries that should not change
SEC_CONFIG = $(Dynamic) ; # Config files that are changed
# infrequently but accessed
# often
SEC_LOG = $(Growing) ; # Files that grow, but that
# should never change ownership
SEC_INVARIANT = +tpug ; # Directories that should never
# change permission or ownership
SIG_LOW = 33 ; # Non-critical files that are of
# minimal security impact
SIG_MED = 66 ; # Non-critical files that are of
# significant security impact
SIG_HI = 100 ; # Critical files that are
# significant points of
# vulnerability
.......................................................................

Debajo de las máscaras de propiedad, se establecen las polı́ticas para los diversos archivos y directorios
del sistema. Podemos empezar con el archivo de polı́ticas predeterminado y comprobar su funcionamiento.
Hay que tomarse tiempo para examinar a fondo el archivo y comprobar qué archivos se están registrando.
Una vez hecho esto, ya estaremos preparados para ejecutar Tripwire.
Inicializar la base de datos básica

El primer paso en la ejecución de Tripwire es establecer la base de datos básica, creando ası́ la lista
inicial de firmas frente a las que se deben utilizar las polı́ticas. Recordemos que debemos ejecutar Tripwire,
idealmente, una vez instalado y configurado el sistema; y después cuando sospechemos que no funcionan
bien algunos archivos en nuestro sistema.
Para establece la base de datos de archivo inicial utilizamos el siguiente comando:

#tripwire -m i -v
El modificador -m especifica el modo a ejecutar, en este caso i para inicializar. El modificador -v le

proporciona una salida por pantalla para que podamos ver lo que está sucediendo. Tripwire audita todos los
archivos especificados en nuestro archivo de politicas, crea la datos en /var/lib/tripwire/ <hotsname>.twd
y lo cifra utilizando la frase de contraseña de site, especificada anteriormente.
Para que Tripwire sea realmente seguro, debemos hacer una copia de su base de datos básica en algún
medio seguro (disquete, CD o cinta). Si lo guardamos localmente siempre existe la posibilidad de que se
pueda alterar el archivo, aunque Tripwire tiene algunas protecciones contra este tipo de acciones.
Comprobar la integridad del archivo

Es el modo principal de ejecución en Tripwire una vez se haya configurado. Compara los atributos
actuales de los archivos especificados con los de la base de datos de Tripwire.
El formato es el siguiente:
#tripwire -m c file.txt
Donde debemos reemplazar file.txt con la ruta de acceso al archivo o a los directorios que deseamos
comprobar. Verificará los atributos de dicho archivo, según las especificaciones del archivo de polı́ticas y
devolverá un informe con los cambios producidos.
Por ejemplo podrı́amos hacer algo ası́:

# tripwire -m c /bin/*
Integrity checking objects specified on command line...

Wrote report file: /var/lib/tripwire/report/debian-20050610-210613.twr
Tripwire(R) 2.3.0 Integrity Check Report
Report generated by: root

Report created on: vie 10 jun 2005 21:06:13 CEST
Database last updated on: Never
===============================================================================
Report Summary:
===============================================================================
Host name: debian

Host IP address: Unknown IP
Host ID: None
Policy file used: /etc/tripwire/tw.pol
Configuration file used: /etc/tripwire/tw.cfg
Database file used: /var/lib/tripwire/debian.twd
Command line used: tripwire -m c /bin/arch /bin/bash /bin/cat
/bin/chgrp /bin/chmod /bin/chown /bin/cp /bin/cpio /bin/csh /bin/date /bin/dd
/bin/df /bin/dir /bin/dmesg /bin/dnsdomainname /bin/echo /bin/ed /bin/egrep
/bin/false /bin/fgconsole /bin/fgrep /bin/fuser /bin/grep /bin/gunzip
/bin/gzexe /bin/gzip /bin/hostname /bin/kill /bin/ln /bin/loadkeys /bin/login
/bin/ls /bin/lsmod /bin/lsmod.modutils /bin/lspci /bin/mkdir /bin/mknod
/bin/mktemp /bin/more /bin/mount /bin/mountpoint /bin/mt /bin/mt-gnu /bin/mv
/bin/nano /bin/netstat /bin/pidof /bin/ping /bin/ps /bin/pwd /bin/rbash
/bin/readlink /bin/rm /bin/rmdir /bin/run-parts /bin/sed /bin/setpci
/bin/setserial /bin/sh /bin/sleep /bin/stty /bin/su /bin/sync /bin/tar
/bin/tcsh /bin/tempfile /bin/touch /bin/true /bin/umount /bin/uname
/bin/uncompress /bin/vdir /bin/zcat /bin/zcmp /bin/zdiff /bin/zegrep
/bin/zfgrep /bin/zforce /bin/zgrep /bin/zless /bin/zmore /bin/znew

===============================================================================
Rule Summary:
===============================================================================
-------------------------------------------------------------------------------
Section: Unix File System
-------------------------------------------------------------------------------
Rule Name Severity Level Added Removed Modified

--------- -------------- ----- ------- --------
Root file-system executables 100 0 0 0
(/bin)
Total objects scanned: 82

Total violations found: 0
===============================================================================
Object Summary:
===============================================================================
-------------------------------------------------------------------------------
# Section: Unix File System
-------------------------------------------------------------------------------
No violations.
===============================================================================
Error Report:
===============================================================================
No Errors
-------------------------------------------------------------------------------
*** End of report ***
Tripwire 2.3 Portions copyright 2000 Tripwire, Inc. Tripwire is a registered

trademark of Tripwire, Inc. This software comes with ABSOLUTELY NO WARRANTY;
for details use --version. This is free software which may be redistributed
or modified only under certain conditions; see COPYING for details.
All rights reserved.
Integrity check complete.
Actualizar la base de datos

A medida que ajustamos las polı́ticas y realizamos cambios importantes en el sistema, podremos
actualizar la base de datos para que refleje con precisión el estado válido de los archivos. Es importante
no sólo que se añadan nuevos archivos y directorios a la base de datos sino también que se eliminen los
falsos positivos. No se debe actualizar la base de datos si existe alguna posibilidad de que nuestro sistema
haya sido comprometido.
Ası́ se invalidarán las firmas y nos aseguraremos de que la base de datos Tripwire es útil. Podemos
actualizar los directorios seleccionados después de todo, algunos elementos como pueden ser los binarios
del sistema, cambiarán en contadas ocasiones.
Para actualizar la base de datos de Tripwire, utilizaremos el siguiente comando:

#tripwire -m u -r path_reporte_anterior
Tendremos que reemplazar path reporte anterior con el nombre y ruta de acceso del archivo de informe
más reciente. La ejecución de este comando nos mostrará todos los cambios que se han producido y las
reglas que los detectan.
Tendremos una X en los cuadros de los archivos en los que Tripwire haya detectado cambios. Si deja
ahı́ la X, Tripwire actualizará la firma para dicho archivo cuando salgamos de éste. Si elimina la X, Tripwire
supondrá que la firma original es la correcta y no la actualizará. Al salir, Tripwire ejecutará dichos cambios.
También, podemos especificar -c en el comando para salir realizando la vista previa y dejar que Tripwire
realice los cambios para los archivos que haya detectado.
Actualizar el archivo de polı́ticas

Con el tiempo nos daremos cuenta que reglas no están generando alertas válidas y necesitaremos eli-
minar o cambiar las máscaras de propiedad. Para ello realizaremos los cambios necesarios en el archivo de
polı́ticas de Tripwire.

Una vez guardados ejecutaremos el comando siguiente, para que Tripwire actualice el archivo de polı́ti-
cas:
#tripwire -m p politica.text
Donde debemos reemplazar politica.text con el nuevo archivo de polı́ticas. Tripwire nos pedirá que
introduzcamos la contraseña local y de site antes de actualizar la polı́tica. Cuando hayamos ajustado
suficientemente las polı́ticas de Tripwire, podremos crear una tarea que se ejecute diariamente (o con la
frecuencia deseada) para revisar el sistema de archivos en busca de archivos modificados.
13.8. ACIDlab: Analizar alertas IDS

La consola de análisis para bases de datos de alarmas de intrusión (ACID, Analysis Console for In-
trusion Databases) es un programa diseñado para hacer un mejor uso de los dispositivos de detección de
intrusión. Esta es su página oficial:
http://acidlab.sourceforge.net/
La idea que se esconde detrás de ACID es portar todos los datos de detección de intrusión a una
base de datos donde se puedan ordenar y organizar por prioridades. Nos proporciona un panel de control
basado en web para visualizar y manipular estos resultados.
Utiliza cualquier base de datos SQL y cualquier servidor web, admitiendo múltiples sensores para los
datos de entrada. Acepta alertas Snort y archivos de registro ajustados a los registros del sistema.
Actualmente, ACID sólo funciona directamente con un IDS, Snort, pero podemos importar registros en
la base de datos de ACID desde cualquier dispositivo que produzca una salida en formato tipo archivo de
registro utilizando una utilidad denominada Logsnorter, que se encuentra disponible en la web de ACID.
Necesitamos cumplir unos requisitos previos para que funcione correctamente: Debemos tener instala-
dos una base de datos, un servidor web y el PHP.
Para instalarlo y hacerlo funcionar con Snort, necesitamos comunicar los dos programas a través de
una base de datos, por ejemplo MySQL. Instalaremos los siguientes paquetes:
#apt-get install acidlab acidlab-doc acidlab-mysql
Si queremos enlazar Snort a través de una base de datos MySQL con ACID debemos instalar el paquete:
#apt-get install snort-mysql
Sustituirá el antiguo Snort por otro que produzca las salidas en una base de datos MySQL.
Es muy recomendable instalar ACID en una máquina independiente de Snort. Colocarlos en la misma
máquina no sólo es poco recomendable desde el punto de vista de la seguridad sino que además inundará de
alertas el sensor Snort hasta hacerlo inservible. El host con ACID debe de ubicarse en un sitio donde no
pueda acceder el sensor de Snort.
Configuración de ACID
Este es el archivo de configuración del sistema ACIDlab:
/etc/acidlab/acid_conf.php
En la siguiente tabla se puede observar la descripción de las variables contenidas en el archivo:

Cuadro 13.8: Variables de configuración de ACID
Nombre de variable Descripción

$DBtype Tipo de base de datos ACID que se va a utilizar. El valor predeterminado
es mysql, pero también podemos establecer postgresql o mssql.
$alert_dbname El IDS desde donde se están obteniendo las alarmas para ACID. Ac-
tualmente solo adminte Snort (snort log), en el futuro admitirá otros
IDS.
$alert_host El host en el que se va a guardar la base de datos de alerta. Puede ser
una dirección IP o un nombre de host. Si se está ejecutando en la misma
máquina, serı́a localhost. Para una mejor seguridad y rendimiento, es
recomendable ejecutar la base de datos en una máquina distinta a la del
servidor web con PHP.
$alert_port Puerto sobre el que se accese a la base de datos. Si es local, sólo debemos
introducir “ ” para este valor.
$alert_user Nombre de usuario de base de datos que va a utilizar ACID para registrar
los datos. Hay que asegurarse de que coincide con el nombre de usuario
MySQL creado en la configuración de la base de datos
$alert_password La contraseña para el usuario de la base de datos. Una vez más, hay que
asegurarse de que coincide con la contraseña MySQL para dicho usuario.
$archive_dbname Nombre de la base de datos de Snort. El valor predeterminado es
snort archive, a no ser que estemos guardando múltiples bases de da-
tos en esta máquina y deseemos escribir nombres más descriptivos
$archive_host Host donde se va a ubicar la base de datos de archivo. Si está en la
misma máquina debe ser localhost.
$archive_port Puerto para iniciar la sesión en el servidor de base de datos. Introducimos
“ ” si estamos iniciando la sesión localmente.
$archive_user Usuario de base de datos para registrar los datos de archivo. Normalmen-
te es el mismo valor que el de la variable anterior, $alert_user, aunque
se pude crear un usuario independiente para registrar los archivos.
$archive_password Contraseña para que el usuario de la base de datos registre los datos de
archivo. Como en el caso anterior, el valor suele ser el mismo que el de
$alert_password.
$chartlib_path Ruta de acceso a los módulos de creación de gráficos.
$chart_file_format Formato de archivo de los gráficos. El formato predeterminado es png.
Otros formatos válidos son jpg y gif.
Ejecución de ACID
Una vez ajustado el archivo de configuración nos debemos conectar a la dirección:
http://localhost/acidlab/acid_main.php
Se muestra la página de configuración de ACID. A partir de este momento podremos utilizar la interfaz
web para terminar la configuración de ACID.
Hacemos clic sobre el boton Create ACID AG para crear una base de datos para los datos Snort. El
nombre predeterminado de la base de datos es “snort”.
Una vez hecho esto debemos dirigirnos a:

http://localhost/acid
La página principal de ACID y para ver la base de datos de Snort.

Una vez hecho esto hemos terminado la configuración de ACID y podemos empezar a utilizarlo para
administrar el sistema IDS.

Utilizar ACID para ajustar y administrar nuestro NIDS

Antes de que el NIDS sea útil debemos ajustarlo a nuestra red para eliminar alertas de falsos positivos.
ACID puede ser una herramienta muy valiosa en esa tarea. Cuando ajustamos por primera vez el NIDS,
todas las firmas de alerta se activarán y nuestra base de datos empezará a rellenarse con actividad de
las alertas. La mayorı́a de estas serán falsos positivos, para que los datos de alerta sean importantes en
nuestra red, tenemos que empezar a eliminar algunas de estas firmas para reducir la actividad errónea y
proporcionar sólo los datos procesables.
Cuando tengamos un número suficiente en la base de datos (al menos unas miles de alertas), podemos
empezar a analizar datos y asi eliminar los tipos de alertas que no nos proporcionen información.
Si pulsamos Unique Alerts (Alertas únicas) se mostrarán las alertas más recientes clasificadas por tipo
de alerta.
En está página podemos clasificar y ordenar por los siguientes campos:
Nombre de la firma (<Signature>).
Clasificación de la alerta (<Classification>).
Número total de este tipo de alertas en la base de datos (<Total#>).
Número de sensores desde donde proviene la alerta (Sensor#).
Número de las diferentes direcciones IP de origen asociadas con dicha alerta (<Src. Addr.>).
Número de las diferentes direcciones IP de destino asociadas con dicha alerta (<Dest. Addr.>).
Hora en la que se ha incluido la alerta (<Firt> y <Last>).
Hay que examinar las listas para averiguar si realmente es un problema de seguridad o un falso positivo:
¿Se puede apreciar algún tipo de patrón?
¿Provienen todas las alertas de la misma dirección IP?
¿Se dirigen todas las alertas a la misma dirección IP?
¿Se producen a intervalos regulares o lo hacen de forma aleatoria?
Si este análisis no nos conduce a ninguna conclusión, se puede buscar con más detalle haciendo clic en
las alertas individuales.
Basándose en la IP del emisor, podemos utilizar esta información para determinar si se trata de
una dirección que normalmente está accediendo a nuestra red. También podemos mirar más abajo para
comprobar la parte útil del paquete (Se ve en hexadecimal y ASCII).
Si determinamos que es un ataque al sistema podemos intentar tomar medidas. Normalmente serán
gusanos automatizados, ataque que se produce docenas de veces al dia. Aun ası́ es mejor estar pendiente de
estas alertas para comprobar si la IP persiste. Al menos, podemos asegurarnos de que la máquina atacada
esta protegida contra ese tipo de ataque y enviar una queja al ISP del atacante. También se pueden
ejecutar otras acciones contra la dirección IP que aparece como IP de origen, como una persecución legal
o una acción civil, si se ha producido con éxito la intrusión.
Al menos sabremos exactamente qué tipo de ataques se están produciendo en nuestra red y lo que
están intentando hacer, Ası́, nuestra red estará más protegida y podremos reaccionar si se produce un
ataque.

Figura 13.2: Detalle de una alerta ACID
Otras formas de analizar datos de alerta utlizando ACID

Ahora que disponemos de nuestra base de datos llena de alertas, podremos buscar las respuestas a
algunas preguntas que se nos plantean a continuación.
¿Quién es el objetivo del ataque? Al utilizar ACID, buscamos las direcciones IP más comunes ya que
muestran las direcciones IP que supuestamente son las más atacadas y, por consiguiente, habrá máquinas
sobre las que debemos centrar nuestros esfuerzos de protección, algo que nos ayudará a diferenciar entre
los falsos positivos y los positivos reales. Podremos localizar cualquier máquina que esté generando un
gran número de alertas desde una aplicación que se está ejecutando.
Un incremento súbito en las alertas hacia una dirección IP determinada puede apuntar que se esta
iniciando un ataque sobre dicha máquina. A continuación, podemos ejecutar escáneres de vulnerabilidad,
comprobar los niveles de seguridad, restringir direcciones de IP origen en el enrutador, etc.
¿Quién está atacando? Buscamos la dirección de origen IP que aparece con más frecuencia. Para ello
nos debemos dirigir a la lista IP de origen; ası́ podremos ver la IP y el nombre de dominio totalmente
calificado (FQDN, Fully Qualified Domain Name) que indica de dónde proviene el ataque. La ordenación
por el número de alertas permite ver a los peores atacantes, según la generación de alertas. Si las direcciones
IP con la mayorı́a de las alertas están en nuestra red, puede existir un culpable interno o una aplicación
que esté activando una alerta.
Utilizamos el proceso analizado anteriormente para llegar al detalle de la alerta. Si provienen de
direcciones IP externas, tendremos que determinar si se trata de un enlace de tráfico legı́timo de nuestra
red o son ataques reales. Buscamos en las alertas individuales para comprobar lo que esta pasando. Al
hacer clic en la dirección se abre una página con información adicional sobre la dirección y algunas opciones
para analizarla con más detalle.
Analizando esas salidas podremos encontrar qué organización es propietaria de dichas IP. Y podremos
registrar una queja en su centro de operaciones. Ası́ mismo, si comprobamos que determinadas direcciones
aparecen una y otra vez, podremos filtrar estas direcciones IP en nuestro cortafuegos.

¿Cuál es el servicio más atacado? Al buscar los puertos más comunes en los que las alertas se están
recibiendo podemos comprobar cuáles son los servicios más atacados. Si comprobamos que hay muchas
alertas basadas en web, deberemos de tener más cuidado en el bloqueo de servidores web.
Si las alertas muestran mucha actividad NetBIOS de Windows, tendremos que mirar las polı́ticas de
contraseñas y permisos de Windows. Ası́ podremos saber cuáles son los servicios en los que debemos
centrar primero nuestra atención.
Mantener la base de datos ACID

A medida que crece nuestra base de datos, tendremos que ejecutar algún tipo de tarea de manteni-
miento periódico, para evitar que se haga demasiado grande. Ası́ mismo, nuestras estadı́sticas y gráficos
serán más precisos si archivamos nuestras primeras alertas, que van a contener muchos falsos positivos.
Ası́ mismo, la limpieza de nuestra base de datos de vez en cuando agilizará el proceso de consultas. Para
archivar las alertas, utilizamos el control de consulta que se encuentra en la parte inferior de la pantalla
principal. Podemos crear una consulta para las alertas que se desea archivar, por ejemplo, todas las aler-
tas generadas el último año. Después seleccionamos Archive Alerts (Archivar alertas) como acción para
la consulta. Podemos archivar alertas seleccionando por dato, alerta u otros criterios. También podemos
elegir simplemente copiar las alerta en un archivo o eliminarlas. Las alertas archivadas se situarán en la
propia base de datos, con el nombre establecido en el archivo acid conf.php durante la configuración.
Debemos archivar todas las alertas desde los primeros meses de funcionamiento cuando estábamos
ajustando el sensor de Snort. A partir de ahora, los datos serán más importantes para los ataques reales
frente a los falsos positivos. Es recomendable archivar al menos una vez al año o quizá trimestralmente,
dependiendo del volumen de alertas que se estén registrando. Como regla general, no es recomendable
tener más de 100.000 alertas en la base de datos.
13.9. Logcheck: Analizar logs

Leer los logs, de nuestro sistemas es una tarea pesada y requiere bastante tiempo. Si tenemos bastante
trabajo como administradores de sistemas, es probable que pasemos dı́as o semanas sin mirarlos. Debido a
esto, no sabemos qué oscuras criaturas pueden estar penetrando nuestro sistema. Además, cuando leemos
logs la proporción de información útil respecto a la inútil es alarmantemente baja . . .
Se hace necesario disponer de una herramienta que analize automáticamente esa información y solo
extraiga las partes interesantes de esos logs. Haciéndolos mucho más fáciles de consultar y, sobre todo,
leer.
Logcheck revisa periódicamente los logs del sistema , analizando y clasificando cada lı́nea y según dife-
rentes niveles de alerta. Reportándolo al administrador del sistema en un formato fácil de leer, descartando
las lı́neas que no tengan relevancia. Normalmente estos datos son enviados por correo.
Logcheck chequeará cada lı́nea frente a cuatro niveles de seguridad: Ignorar, actividad inusual, viola-
ción de seguridad y ataque.
Para instalar el programa necesitaremos hacer un apt:

#apt-get install logcheck
Logcheck opera encontrando expresiones regulares. Itera sobre cada uno de los archivos de log tres
veces (para localizar mensajes inusuales, violaciones de seguridad y alertas de ataque) utilizando egrep
para buscar los patrones. Podemos consultar el manual de egrep para poder construir reglas más potentes.
Archivos que utiliza Logcheck

Al instalar Logcheck nos encontramos en el sistema los siguientes archivos:
logcheck.sh: Es el programa que se ejecutará cada vez que sea invocado logcheck. Es un script en
shell normal, e incluye la configuración en un formato fácil de comprender.

logcheck.hacking: Tiene la lista de cadenas con las que una lı́nea será identificada como intento de
entrar al sistema o de conseguir información acerca de él, y por tanto serán reportadas como ataques
activos, llamando la atención de manera especial al administrador.
logcheck.ignore: Tiene la lista de expresiones que son muy comunes y no vale la pena reportarlas al
administrador.
logcheck.violations: Tiene la lista de expresiones que pueden ser consideradas moderadamente peli-
grosas, y son etiquetadas como violaciones de seguridad.
logcheck.violations.ignore: Permite ser más especı́fico: Si una lı́nea concuerda con una de las expre-
siones de logcheck.violations pero también concuerda con una de éste archivo, la lı́nea es ignorada.
tmp: Es el directorio temporal utilizado por el programa para procesar los datos.
Además de estos archivos, logcheck instala el programa logtail en /usr/local/bin. Este programa man-
tiene la información de qué logs han sido analizados y hasta qué punto, para no perder ni repetir lı́neas.
Logcheck por defecto analizará los archivos /var/log/messages, /var/log/secure y /var/log/maillog.
Opciones de logcheck.sh
En el archivo logcheck.sh encontraremos las siguientes opciones de configuración:
PATH : Indica dónde buscará el sistema los binarios. Debemos recordar que se ejecutara con una
llamada desde cron, por lo que no hace daño definirlo, y tal vez limitarlo al mı́nimo necesario.
SYSADMIN : Es la persona que recibirá el reporte por correo. Si no lleva una dirección completa,
asume que es una dirección local.
LOGTAIL: Indica el path completo para el programa logtail.
TMPDIR: Especifica el directorio temporal que usará el programa. Este debe ser un directorio
seguro, que no tenga acceso de escritura más que para el usuario que ejecute Logcheck.
GREP : Indica el nombre del comando grep a ejecutar. En muchos sistemas Unix hay diferentes grep
con diferentes caracterı́sticas, sugerimos instalar el egrep de GNU.
MAIL: Es el comando empleado para mandar un correo. Tı́picamente será mail, aunque en algunos
sistemas puede ser mailx.
HACKING FILE : Es el pathname y nombre completo del archivo logcheck.hacking
VIOLATIONS FILE : Es el pathname y nombre del archivo logcheck.violations
VIOLATIONS IGNORE FILE : Es el pathname y nombre del archivo logcheck.violations.ignore
IGNORE FILE : Es el pathname y nombre completo del archivo logcheck.ignore
Ejecución de logcheck.sh
Logcheck no es un programa que funcione continuamente, sino que es llamado cada vez que el admi-
nistrador lo cree adecuado. Como cada reporte será enviado por correo, lo más común es hacerlo cada
hora. Para ello es necesario crear una entrada en el crontab de root o de algún usuario que tenga permiso
de leer los archivos localizados en /var/log.
La lı́nea a ser agregada en el crontab será similar a la siguiente:

0 * * * * /bin/sh /usr/local/etc/logcheck.sh

Con esto, cada hora el administrador recibirá un mensaje similar al siguiente:

From root@hostname.dominio.com Wed Sep 27 21:46:33 2000
Date: Wed, 27 Sep 2000 19:00:04 -0500
From: root <root@hostname.dominio.com>
To: root@hostname.dominio.com
Subject: hostname.dominio.com 09/27/00:19.00 system check
Security Violations
=-=-=-=-=-=-=-=-=-=
Sep 27 18:23:07 hostname PAM_pwdb[14075]: authentication failure; (uid=0) -> root for ssh service
Sep 27 18:23:11 hostname PAM_pwdb[14075]: (ssh) session opened for user root by (uid=0)
Sep 27 18:23:11 hostname sshd[14075]: log: Password authentication for root accepted.
Sep 27 18:23:11 hostname sshd[14075]: log: ROOT LOGIN as ’root’ from hostname2.dominio.com
Sep 27 18:23:43 hostname PAM_pwdb[14075]: (ssh) session closed for user root
Unusual System Events

=-=-=-=-=-=-=-=-=-=-=
Sep 27 18:02:26 hostname proftpd[13963]: hostname.dominio.com (lab1-15.dominio.com [192.168.1.16]) - FTP no transfer timeout, disconnected.
Sep 27 18:23:11 hostname sshd[14075]: log: ROOT LOGIN as ’root’ from dir-03.dominio.com
Sep 27 18:00:12 hostname sendmail[13610]: RAB13605: SAA13610: DSN: Host unknown (Name server: mail.internet.com: host not found)
En caso de haberse registrado algún evento que concuerde con alguna lı́nea de logcheck.hacking, para
que el reporte sea visto más rápidamente por el administrador cambiarán los encabezados, quedando ası́:
From root@hostname.dominio.com Wed Sep 27 21:52:58 2000
Date: Wed, 27 Sep 2000 21:00:05 -0500
From: root <root@hostname.dominio.com>
To: root@hostname.dominio.com
Subject: hostname.dominio.com 09/27/00:21.00 ACTIVE SYSTEM ATTACK!
Active System Attack Alerts

=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: SYN/Normal scan from host: ejemplo.dominio.com/192.168.0.111 to TCP port: 1019
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: Host 192.168.0.111 has been blocked via wrappers with string: "ALL: 192.168.0.111"
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: Host 192.168.0.111 has been blocked via dropped route command: "/sbin/iptables -I input -s 192.168.0.111 -j DENY -l"
(...)
Security Violations
=-=-=-=-=-=-=-=-=-=
Sep 27 20:09:22 hostname sshd[14589]: log: Password authentication for root accepted.
(...)
Unusual System Events

=-=-=-=-=-=-=-=-=-=-=
Sep 27 20:10:47 hostname sshd[14624]: fatal: Did not receive ident string.
Sep 27 20:19:43 hostname PAM_pwdb[14985]: authentication failure; (uid=0) -> llec for ssh service
Sep 27 20:09:34 hostname in.telnetd[14610]: connect from 192.168.0.111
(...)
Interfaz web para Logchek

Podemos manejar graficamente este util programa desde nuestro Webmin. Para instalar:
#apt-get install sentry
El la figura se puede observar que la configuración de la herramienta se vuelve un juego de niños.
13.10. PortSentry: Detectar escaneos de puertos

Cuando un atacante decide probar suerte en nuestro sistema, lo primero que necesita es recopilar cuan-
ta información le sea posible acerca de él. Todo puede serle útil: Sistema operativo, versión, servicios que
ofrecemos, versión de los programas que tenemos... Cualquiera de estos datos puede ser suficiente para que
su ataque sea exitoso. Basta con que el atacante vea, por ejemplo, que tenemos una versión vieja de un
programa, aunque no tenga éste ninguna vulnerabilidad importante, para que se dé cuenta que no somos
administradores muy cuidadosos y probablemente tengamos otros servicios descuidados.
La manera más común en que un atacante va a intentar obtener información acerca de nosotros es
el barrido de puertos: Intentar conectarse a cada uno de los puertos que tiene abiertos nuestro servidor,
anotando qué es lo que tiene activo y analizando dicha información. Una de las herramientas más comunes
para realizar barridos de puertos es el Nmap (véase sección 17.2).

Figura 13.3: Módulo Webmin para LogCheck
Tras haber hecho esta prueba, el atacante puede intentar entrar a cada uno de los puertos abiertos,
revisando si encuentra alguna versión vieja o vulnerable.
Detectar un barrido de puertos es muy fácil: Muchas conexiones casi simultáneas a una gran cantidad
de puertos originadas desde la misma dirección. Si bien los programas barredores se han vuelto muy
sofisticados y cada vez es más difı́cil detectarlos por diferentes estrategias que emplean (Nmap sabe hacer
desde una sencilla conexión TCP hasta un barrido silencioso con SYN, FIN, Xmas, Null, UDP, paquetes
fragmentados y barridos paralelos de diferentes tipos), el principio básico es el mismo.
Hay un excelente programa dedicado precisamente a encontrar éste patrón y tomar la acción que le
indique el administrador del sistema: Portsentry.
Para instalar el programa necesitaremos hacer un apt:

#apt-get install portsentry
Portsentry es un programa muy sencillo. Su misión es “sentarse y escuchar” en los puertos que le
indiquemos que deben permanecer siempre inactivos. En caso de llegar una conexión a uno de ellos puede
marcarlo en los logs del sistema, bloquear toda la comunicación con la dirección identificada como agre-
sora, o ejecutar un comando externo.
El archivo de configuración de PortSentry es:

/etc/portsentry/portsentry.conf
El programa tiene varios modos de operación:
Modo clásico
Modo stealth
Modo avanzado

Modo clásico
En este modo, le especificamos a Portsentry que escuche determinados puertos TCP y UDP, especifi-
cados con las opciones UDP PORTS y TCP PORTS y por los cuales no estamos dando ningún servicio.
Por ejemplo, puede que nuestro servidor no esté dando servicio de red SMB (Samba, red tipo Microsoft).
Sin embargo, es común que las computadoras windows manden mensajes broadcast buscando a un sistema
en especı́fico, con lo que podrı́amos recibir una gran cantidad de alertas falsas. Vienen varios puertos
predefinidos en el archivo de configuración, y es recomendable utilizarlos inicialmente.
Modo stealth
En este modo Portsentry abre sockets crudos, lo que le permite detectar una mayor cantidad de barridos
y ataques: Ataques de conexión normal, SYN/half-open, FIN, NULL y XMAS. Este modo es un tanto
experimental, por lo cual no funcionará en todos los sistemas.
Modo avanzado
Este modo es también considerado hasta cierto punto perteneciente a la categorı́a stealth. En éste modo,
Portsentry no abre ningún puerto, sino que le pide al kernel que le notifique si llega alguna petición a algún
puerto menor al especificado en las opciones ADVANCED PORTS TCP y ADVANCED PORTS UDP.
Tendremos que excluir algunos puertos que sean particularmente ruidosos (como el comentado en
la sección anterior, SMB) y para ello tenemos las opciones ADVANCED EXCLUDE TCP y ADVAN-
CED EXCLUDE UDP.
El modo avanzado es mucho más sensible que el modo clásico, dado que escucha muchos más puertos,
por lo que puede efectivamente causar una negación de servicio si no es configurado con cuidado.
Otras opciones de configuración

Tras haber especificado los puertos que deseamos escuchar, hay algunos parámetros adicionales que
debemos especificar:
IGNORE FILE : Es el nombre del archivo que incluye la lista de direcciones en las que confiamos y
por tanto no queremos bloquear si intentan acceder a un puerto bloqueado. Por ejemplo, serı́a muy
molesto que quisiéramos ejecutar Nmap contra uno de nuestros servidores para asegurarnos de que
no haya servicios abiertos que no requiramos y que nosotros mismos quedáramos bloqueádos.
HISTORY FILE : Contiene la lista de direcciones que Portsentry ha detectado intentando acceder a
puertos monitoreados.
BLOCKED FILE : Es equivalente a HISTORY FILE, pero relevante únicamente a la sesión actual
de Portsentry.
BLOCK TCP : Especifica qué hacer cuando un barrido de puertos TCP es detectado. Tiene tres po-
sibles valores: 0 (sólo registrar el intento), 1 (bloquear la dirección que intentó acceder a la máquina)
y 2 (ejecutar un comando externo especificado en KILL RUN CMD).
BLOCK UDP : Es equivalente a BLOCK TCP para barridos de puertos UDP.
KILL ROUTE : Guarda el comando utilizado para descartar toda la comunicación con una dirección.
En un sistema que incluya un filtro de paquetes (por ejemplo, iptables en Linux o ipf en los *BSD)
es muy preferible manejar una regla bloqueando la conexión.
KILL HOSTS DENY : Tiene la lı́nea que deberá ser agregada a /etc/hosts.deny para que la dirección
atacante sea bloqueada por TCPwrappers. Es conveniente activarlo, pues a diferencia de las reglas
manejadas por KILL ROUTE éste archivo sobrevivirá a la baja del sistema. Pero, no hay que
confiarse TCPwrappers sólo maneja determinados servicios, y si sólo nos protegemos con él, el sistema
podrá seguir proporcionando información importante a nuestro atacante.

KILL RUN CMD: Puede guardar un comando a ser ejecutado de ser detectada una intrusión. No
se recomienda utilizar esta opción, ya que puede fácilmente llevar a una negación de servicio. Hay
administradores que sugieren utilizar esta opción para lanzar un contraataque contra el atacante.
Nosotros categóricamente les indicamos que esto es una muy mala idea – La mejor defensa es tener
nuestro sistema seguro, no atacar al enemigo. Al atacar al enemigo, lo más probable es que centre
más su atención en nosotros y, con el paso del tiempo, logre penetrar nuestra seguridad. Es mucho
mejor aparentar que nada ocurrió o simplemente tirar la conexión que atacarla.
SCAN TRIGGER: Indica con cuantos intentos de conexión se deben realizar, para marcarla como
un ataque. Probablemente, si a la primera bloqueamos toda comunicación con el presunto atacante,
dejaremos fuera a muchos usuarios legı́timos que por casualidad hicieron la conexión equivocada. Sin
embargo, si ponemos un número muy alto nos exponemos a dar más información de la que hubiéramos
querido. Un valor de 1 o 2 es recomendado, aunque los muy paranóicos querrán mantenerlo en 0.
Inicialización automática
Hay que incluir la ejecución en uno de los archivos que se ejecutan al iniciar la máquina. Las opciones
que podemos establecer son las siguientes:
Cuadro 13.9: Opciones de PortSentry
-tcp Iniciar en modo clásico, escuchar TCP
-udp Iniciar en modo clásico, escuchar UDP
-stcp Iniciar en modo stealth, escuchar TCP
-sudp Iniciar en modo stealth, escuchar UDP
-atcp Iniciar en modo avanzado, escuchar TCP
-audp Iniciar en modo avanzado, escuchar UDP
Tı́picamente levantaremos dos copias del programa en el mismo modo general, una escuchando UDP
y la otra TCP.
Almacenamiento en los logs del sistema

El simple hecho de que Portsentry evite ciertos ataques al sistema es de por sı́ muy bueno y deseable.
Sin embargo, para que ésto nos sea realmente útil, tenemos que analizar nuestros logs y llevar registros de
quién y cuándo intentó se intentaron escanear nuestros puertos. Además, sólo leyendo los logs sabremos
si estamos limitando de más, bloqueando el acceso de máquinas legı́timas.
Afortunadamente, Portsentry utiliza syslog para reportar toda la información que el administrador
debe saber, por lo cual todo lo que necesitamos estará tı́picamente en el archivo /var/log/messages, o
donde se lo hayamos especificado en el syslogd.conf.
La detección de un barrido hecho por Nmap en un sistema Linux se ve ası́:
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: Host 192.168.1.3 has been blocked via wrappers with string: "ALL: 192.168.1.3"
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: Host 192.168.1.3 has been
blocked via dropped route using command: "/sbin/iptables -I input -s 192.168.1.3 -j DENY -l"
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: Host: ejemplo.dominio.com/192.168.1.3 is already blocked Ignoring
(...)

Readmitiendo hosts marcados como atacantes

Cuando configuremos Portsentry es muy común que marquemos direcciones como atacantes por error.
Eliminarlos de la lista de bloqueo es afortunadamente muy sencillo.
Si asumimos que queremos volver a permitir acceso a la dirección 192.168.1.3. Todo el proceso debe-
remos realizarlo como root.
Nuestro primer paso será editar el archivo /etc/hosts.deny y buscar la dirección que queremos
eliminar, en nuestro caso la tercera:
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the ’/usr/sbin/tcpd’ server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!
ALL: 216.98.66.42
ALL: 210.124.182.137
ALL: 192.168.1.3
ALL: 200.36.163.106
ALL: 202.111.97.171
Consultamos la tabla de direcciones filtradas por iptables. El comando iptables-save es de gran utili-
dad para esa tarea, pues muestra las lı́neas con los comandos que serı́an necesarios para insertarlas.
# /sbin/iptables-save
:input ACCEPT
:forward ACCEPT
:output ACCEPT
Saving ‘input’.
-A input -s 216.98.66.42/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j DENY -l
-A input -s 210.124.182.137/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j DENY -l
-A input -s 192.168.1.3/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j DENY -l
-A input -s 200.36.163.106/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j DENY -l
-A input -s 202.111.97.171/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j DENY -l
Una lı́nea es insertada en iptables con -A, y es eliminada con -D, por lo cual basta con que hagamos:
#iptables -D input -s 192.168.1.3/255.255.255.255 -d 0.0.0.0/0.0.0.0 -j DENY -l
Con esto, el host con la dirección 192.168.1.3 ya tendrá de nuevo acceso a nuestro sistema.
Interfaz web para Portsentry

Podemos manejar graficamente este util programa desde nuestro Webmin. Para instalar:
#apt-get install sentry
El la figura se puede observar que la configuración de la herramienta se vuelve un juego de niños.
13.11. Detectores de sniffers

Un grave problema de nuestra red son las escuchas clandestinas, ¿como podemos estar seguros que
no hay nadie escuchando nuestras conexiones? Disponemos de varias herramientas para la detección de
tarjetas de red en modo promiscuo (sniffers), aquı́ mostraremos las siguientes:
Neped
Sentinel
Estas herramientas, utilizan las siguientes técnicas para descubrir sniffers:

Figura 13.4: Módulo Webmin para Portsentry
El test DNS
En este método, la herramienta de detección en sı́ misma está en modo promiscuo. Creamos numerosas
conexiones TCP falsas en nuestro segmento de red, esperando un sniffer pobremente escrito para atrapar
estas conexiones y resolver la dirección IP de los inexistentes hosts. Algunos sniffers realizan búsquedas
inversas DNS en los paquetes que capturan. Cuando se realiza una búsqueda inversa DNS, una utilidad
de detección de sniffers “huele” la petición de las operaciones de búsqueda para ver si el objetivo es aquel
que realiza la petición del host inexistente.
El Test ICMP Etherping
Este método confı́a en un problema en el núcleo de la máquina receptora. Podemos construir una peti-
ción tipo “ICMP ECHO” con la dirección IP de la máquina sospechosa de hospedar un sniffer. Enviamos
un un paquete “ICMP ECHO” al objetivo con la dirección IP correcta, pero con una dirección de MAC
deliberadamente errónea. La mayorı́a de los sistemas desatenderán este paquete ya que su dirección MAC
es incorrecta. Pero en algunos sistemas Linux, NetBSD y NT, puesto que el NIC está en modo promis-
cuo, el sniffer identificara este paquete de la red como paquete legı́timo y responderá por consiguiente.
Si el blanco en cuestión responde a nuestra petición, sabremos que está en modo promiscuo. Los sniffers
avanzados filtran tales paquetes para que parezca que el NIC no hubiera estado en modo promiscuo.
El Test ICMP de latencia
Ping de Latencia. En éste método, hacemos ping al blanco y anotamos el Round Trip Time (RTT,
retardo de ida y vuelta o tiempo de latencia) Creamos centenares de falsas conexiones TCP en nuestro
segmento de red en un perı́odo de tiempo muy corto. Esperamos que el sniffer esté procesando estos
paquetes a razón de que el tiempo de latencia incremente. Entonces hacemos ping otra vez, y comparamos
el RTT esta vez con el de la primera vez. Después de una serie de tests y medias, podemos concluir o no
si un sniffer está realmente funcionando en el objetivo.

El test ARP
Podemos enviar una petición ARP a nuestro objetivo con toda la información rápida excepto con una
dirección hardware de destino errónea. Una máquina que no esté en modo promiscuo nunca verá este
paquete, puesto que no era destinado a ellos, por lo tanto no contestará. Si una máquina está en modo
promiscuo, la petición ARP serı́a considerada y el núcleo la procesarı́a y contestarı́a. La máquina que
contesta está en modo promiscuo.
13.11.1. Neped
NePED es una herramienta imprescindible para cualquier administrador de redes. Al ejecutarlo, el
programa nos informará de todos los equipos conectados a nuestra red local con la tarjeta ethernet en
modo promiscuo.
Lo podemos descargar desde su página web:

http://apostols.org/projectz/neped/
La forma de uso es muy sencilla:

#neped <dispositivo>
Esto serı́a un ejemplo de su funcionamiento:

#neped eth0
----------------------------------------------------------
> My HW Addr: 00:00:F4:C2:0E:2A
> My IP Addr: 192.168.0.2
> My NETMASK: 255.255.255.0
> My BROADCAST: 192.168.0.255
----------------------------------------------------------
> Scanning ....
*> Host 192.168.0.3, 00:60:08:64:06:FF **** Promiscuous mode detected !!!
> End.
La técnica empleada para la detección es sumamente sencilla. Se trata de realizar una simple petición
ARP para cada una de las IPs de nuestra red, con la salvedad de que los paquetes no van destinados
al broadcast (FF:FF:FF:FF:FF:FF), sino a una dirección arbitraria (cualquiera que no exista). Solo las
maquinas con la tarjeta ethernet en modo promiscuo son capaces de ver estos paquetes, y por lo tanto,
solo ellas contestarán a nuestras peticiones.
13.11.2. Sentinel
Lo podemos descargar desde su página web:
http://www.packetfactory.net/Projects/sentinel/
Utiliza los métodos de busqueda de snifers:

Test DNS, test ARP, test ICMP Etherping y test ICMP de latencia.
La forma de uso es muy sencilla:

#sentinel <metodo> [-t <ip>] <opciones>
Como método de uso podemos especificar uno o varios de los siguentes:

-a: test ARP
-d: test DND
-i: ICMP test ping de latencia
-e: ICMP test etherpingt
Las opciones más comunes se detallan a continuación:

-f <nombre>: Donde nombre representa, un fichero o una IP

-c <x.x.x>: Clase C a monitorizar
-n <n\’umero de paquetes a enviar>
-I <dispositivo>
Y estos serı́an algunos posibles ejemplos de uso de Sentinel:
Test ARP en el host 192.168.0.2

#sentinel -a -t 192.168.0.2
Test DNS en el host 192.168.0.2
#sentinel -d -f 1.1.1.1 -t 192.168.0.2
Escanear una red de Clase C (192.168.0) usando el test ARP, DNS y test etherping
#sentinel -aed -c 192.168.0
13.12. Chkrootkit: Detector de rootkits

Chkrootkit es un shell script que busca en nuestro sistema binarios modificados por RootKits, estos
son usados por los piratas informáticos para comprometer sistemas.
Para instalarlo solo hay que realizar un apt:

#apt-get install chkrootkit
Los piratas informaticos, suelen camuflar o sustituir algunos ficheros binarios del sistema por sus pro-
pios ficheros, algunos de los ejemplos tı́picos son: login, su, telnet, netstat, ifconfig, ls, find, du, df, libc,
sync, asi como los binarios listados en /etc/inetd.conf.
Este programa nos ayuda a verificar que tenemos la versión original de estos ficheros, en la última
versión disponible detecta troyanos en los siguientes ficheros:
aliens, asp, bindshell, lkm, rexedcs, sniffer, wted, z2, amd, basename, biff, chfn, chsh, cron, date, du,
dirname, echo, egrep, env, find, fingerd, gpm, grep, hdparm, su, ifconfig, inetd, inetdconf, identd, killall,
login, ls, mail, mingetty, netstat, named, passwd, pidof, pop2, pop3, ps, pstree, rpcinfo, rlogind, rshd, slo-
gin, sendmail, sshd, syslogd, tar, tcpd, top, telnetd, timed, traceroute, write.
También es capaz de detectar los siguientes RootKits:

Solaris rootkit, FreeBSD rootkit, lrk3, lrk4, lrk5, lrk6, t0rn (and t0rn v8), some lrk variants, Ambient’s
Rootkit for Linux (ARK), Ramen Worm, rh[67]-shaper, RSHA, Romanian rootkit, RK17, Lion Worm,
Adore Worm, LPD Worm, kenny-rk, LKM, ShitC Worm, Omega Worm, Wormkit Worm, dsc-rootkit.
Al ser un shell scrip una vez compilados los programas (chkwtmp, chklastlog, chkproc, chkwtmp, ifpro-
misc) utilizarán el chkrootkit para realizar parte de su trabajo.
En el sistema que he utilizado para el proyecto provoca la siguiente salida:

# 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

Checking ‘env’... not infected
Checking ‘find’... not infected
Checking ‘fingerd’... not found
Checking ‘gpm’... not found
Checking ‘grep’... not infected
Checking ‘hdparm’... not infected
Checking ‘su’... not infected
Checking ‘ifconfig’... not infected
Checking ‘inetd’... not infected
Checking ‘inetdconf’... not infected
Checking ‘identd’... not found
Checking ‘init’... not infected
Checking ‘killall’... not infected
Checking ‘ldsopreload’... not infected
Checking ‘login’... not infected
Checking ‘ls’... not infected
Checking ‘lsof’... not infected
Checking ‘mail’... not infected
Checking ‘mingetty’... not found
Checking ‘netstat’... not infected
Checking ‘named’... not found
Checking ‘passwd’... not infected
Checking ‘pidof’... not infected
Checking ‘pop2’... not found
Checking ‘pop3’... not found
Checking ‘ps’... not infected
Checking ‘pstree’... not infected
Checking ‘rpcinfo’... not infected
Checking ‘rlogind’... not found
Checking ‘rshd’... not found
Checking ‘slogin’... not infected
Checking ‘sendmail’... not infected
Checking ‘sshd’... not infected
Checking ‘syslogd’... not infected
Checking ‘tar’... not infected
Checking ‘tcpd’... not infected
Checking ‘tcpdump’... not infected
Checking ‘top’... not infected
Checking ‘telnetd’... not found
Checking ‘timed’... not found
Checking ‘traceroute’... not infected
Checking ‘vdir’... not infected
Checking ‘w’... not infected
Checking ‘write’... not infected
Checking ‘aliens’... no suspect files
Searching for sniffer’s logs, it may take a while... nothing found
Searching for HiDrootkit’s default dir... nothing found
Searching for t0rn’s default files and dirs... nothing found
Searching for t0rn’s v8 defaults... nothing found
Searching for Lion Worm default files and dirs... nothing found
Searching for RSHA’s default files and dir... nothing found
Searching for RH-Sharpe’s default files... nothing found
Searching for Ambient’s rootkit (ark) default files and dirs... nothing found
Searching for suspicious files and dirs, it may take a while... /usr/lib/mozilla-firefox/.autoreg /usr/lib/kaffe/.system
Searching for LPD Worm files and dirs... nothing found
Searching for Ramen Worm files and dirs... nothing found
Searching for Maniac files and dirs... nothing found
Searching for RK17 files and dirs... nothing found
Searching for Ducoci rootkit... nothing found
Searching for Adore Worm... nothing found
Searching for ShitC Worm... nothing found
Searching for Omega Worm... nothing found
Searching for Sadmind/IIS Worm... nothing found
Searching for MonKit... nothing found
Searching for Showtee... nothing found
Searching for OpticKit... nothing found
Searching for T.R.K... nothing found
Searching for Mithra... nothing found
Searching for OBSD rk v1... nothing found
Searching for LOC rootkit... nothing found
Searching for Romanian rootkit... nothing found
Searching for Suckit rootkit... nothing found
Searching for Volc rootkit... nothing found
Searching for Gold2 rootkit... nothing found
Searching for TC2 Worm default files and dirs... nothing found
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 Madalin rootkit default files... nothing found
Searching for anomalies in shell history files... nothing found
Checking ‘asp’... not infected
Checking ‘bindshell’... not infected
Checking ‘lkm’... You have 2 process hidden for readdir command
You have 2 process hidden for ps command
Warning: Possible LKM Trojan installed
Checking ‘rexedcs’... not found
Checking ‘sniffer’... lo: not promisc and no packet sniffer sockets
eth0: PACKET SNIFFER(/sbin/dhclient[3930], /usr/sbin/snort[4577])
Checking ‘w55808’... not infected
Checking ‘wted’... nothing deleted
Checking ‘scalper’... not infected
Checking ‘slapper’... not infected
Checking ‘z2’... nothing deleted
Vaya!, parece que ha detectado un archivo sospechoso, un posible troyano y que Snort está instalado.

13.13. HoneyPots: Entretener a los atacantes

Información obtenida de la web: http://www.xombra.com
El papel de la tecnologı́a del sistema de detección de intrusos basado en señuelos (o “honeypots”)

está evolucionando. Los honeypots, que alguna vez fueron utilizados, principalmente por los investiga-
dores, como una forma de atraer a los intrusos a un sistema de redes para estudiar sus movimientos y
comportamiento, están adquiriendo una importancia cada vez mayor en la seguridad empresarial. En efec-
to, al brindar detección temprana de actividad no autorizada en las redes, los honeypots son ahora más
útiles que nunca para los profesionales de la seguridad informática. Aquı́ se analiza el funcionamiento de
los honeypots y su tecnologı́a, que se está convirtiendo en el componente clave del sistema de capas de
protección contra intrusos.
Los honeypots son una emocionante tecnologı́a nueva, con un enorme potencial para la comunidad
informática. Los primeros conceptos fueron introducidos primeramente por varios iconos en la seguridad
informática, especialmente por Cliff Stoll en el libro “The Cuckoo’s Egg” y el trabajo de Bill Cheswick
“An Evening with Berferd”. Desde entonces, han estado en una continua evolución, convirtiendose en la
poderosa herramienta de seguridad que es hoy en dı́a. En esta sección se detalla exactamente: qué son los
honeypots, sus ventajas y desventajas, y su importancia en la seguridad.
Los Honeypots (o tarros de miel) “Consisten en activar un servidor y llenarlo de archivos tentadores,
hacer que sea difı́cil, pero no imposible penetrarlo y sentarse a esperar que aparezcan los intrusos. Los ho-
neynets (conjuntos de honeypots) dan a los crackers un gran espacio para recorrer. Presentan obstáculos
que poseen el nivel de complejidad suficiente para atraerlos, pero sin irse al extremo para no desalentar-
los. . . Juegan con los archivos y conversan animadamente entre ellos sobre todos los fascinantes programas
que encuentran, mientras el personal de seguridad observa con deleite cada movimiento que hacen. Fran-
camente, siento una combinación de sentimientos con respecto a espiar a la gente, aunque no sean buenas
personas”. Dan Adams.
Los honeynets son conjuntos de Honeypots, compuestos por servicios reales, ası́ se abarca más informa-
ción para el estudio. Hacen más fascinante el ataque al intruso, lo cual incrementa el número de ataques.
La función principal a parte de la de estudiar las herramientas de ataque, es la de desviar la atención del
atacante de la red real del sistema y la de capturar nuevos virus o gusanos para su posterior analisis. Una
de las múltiples aplicaciones que tiene es la de poder formar perfiles de atacantes y ataques.
Son sistemas que deliberadamente se decide exponerlos a ser atacados o comprometidos. Estos, no
solucionan ningún problema de seguridad, son una herramienta que nos sirve para conocer las estrategias
que se emplean a la hora de vulnerar un sistema. Son una herramienta muy útil a la hora de conocer
de forma precisa los ataques que se realizan contra la plataforma de trabajo que hemos elegido, o bien,
las plataformas configuradas de la misma forma, con el claro objetivo de acceder a información sensible.
Ası́ mismo nos permiten conocer nuevas vulnerabilidades y riesgos de los distintos sistemas operativos,
entornos y programas, los cuales aún no se encuentren debidamente documentados.
En general, existen dos tipos de honeypots:
Honeypots para la investigación: Gran parte de la atención actual se centra en este tipo. Los ho-
neypots para la investigación, que se utilizan para recolectar información sobre las acciones de los
intrusos. El proyecto Honeynet 1 , por ejemplo, es una organización para la investigación sobre segu-
ridad voluntaria, sin ánimo de lucro que utiliza los honeypots para recolectar información sobre las
amenazas del ciberespacio.
Honeypots para la producción: Son los que se utilizan para proteger a las organizaciones. Sin embargo,
se les concede cada vez más importancia debido a las herramientas de detección que pueden brindar
y por la forma cómo pueden complementar la protección en la red y en los hosts.
1 Proyecto Honeynet en castellano: http://his.sourceforge.net/trad/honeynet/

13.13.1. ¿Cómo funcionan?

Los honeypots también se pueden describir como de alta o baja interacción, distinción que se basa en
el nivel de actividad que permiten al atacante. Un sistema de baja interacción ofrece actividad limitada,
la mayorı́a de las veces emula los servicios y sistemas operativos. Las principales ventajas de los honeypots
de baja interacción es que son relativamente fáciles de instalar y mantener; también implican un riesgo
mı́nimo porque el atacante nunca tiene acceso a un sistema operativo real para perjudicar a otros sistemas.
Honeyd (véase sección 13.13.7) es un ejemplo de honeypot de baja interacción, cuya función principal
es monitorear el espacio de direcciones IP no utilizado. Cuando Honeyd detecta un intento de conectarse
a un sistema que no existe, intercepta la conexión, interactúa con el atacante fingiendo ser la vı́ctima para
captar y registrar al ataque.
Por el contrario, los honeypots de alta interacción utilizan sistemas operativos reales y aplicaciones rea-
les, no emulan nada. Al ofrecerles a los atacantes sistemas reales para que interactúen, se puede aprender
mucho sobre su comportamiento. Los honeypots de alta interacción no imaginan como se comportará un
atacante y proporcionan un ambiente que rastrea todas las actividades, lo que permite conocer un com-
portamiento al que de otra manera no tendrı́an acceso.
Los sistemas de alta interacción también son flexibles y los profesionales de la seguridad informática
pueden implementarlos en la medida que quieran. Además, este tipo de honeypot proporciona un objetivo
más realista, capaz de detectar atacantes de mayor calibre. Pueden ser complejos de instalar, sin embargo,
requieren que se implementen tecnologı́as adicionales para evitar que los atacantes los utilicen para lanzar
ataques a otros sistemas.
13.13.2. Ventajas y desventajas

Los honeypots son un concepto increı́blemente simple, las cuales ofrecen una fortaleza muy poderosa.
Podemos observar sus ventajas en los siguientes puntos:
Obtienen un conjunto de datos pequeños, pero de gran importancia: Los Honeypots recolectan
pequeñas cantidades de información. En lugar de logear 1 Gb por dı́a, logean sólo 1 Mb de datos por
dı́a. En vez de generar 10.000 alertas por dı́a, pueden generar sólo 10 alertas por dı́a. Recordemos
que los honeypots sólo capturan actividad sospechosa ya que cualquier interacción con un honeypot
es muy probablemente actividad no autorizada o una actividad maliciosa. Propiamente dicho, los
honeypots reducen el “ruido” recogiendo sólo los datos indispensables y de gran valor, los producidos
únicamente por “chicos malos”. Esto significa que es mucho más fácil (y barato) de analizar los datos
que un honeypot recoge.
Nuevas herramientas y tácticas: Los honeypots son diseñados para capturar cualquier cosa que
interactúa con ellos, incluyendo herramientas o tácticas nunca vistas.
Mı́nimos recursos: Los honeypots requieren mı́nimos recursos, sólo capturan actividad irregular. Esto
significa que un viejo Pentium con 128 mb de RAM puede manejar fácilmente una entera red de
clase B entera.
Encriptación en IPv6: A diferencia de la mayorı́a de las tecnologı́as para la seguridad, como los
sistemas IDS, honeypots trabajan bien en entornos encriptados como IPv6. No importa lo que los
“chicos malos” lancen hacia el honeypot, el honeypot lo detectará y lo capturará.
Información: Los honeypots pueden recoger información “en profundidad” como pocos, si es que
existen tecnologı́as que se le parezcan.
Simplicidad: Finalmente, los honeypots son conceptualmente simples. No hay por qué desarrollar
algoritmos raros, ni complejas tablas que mantener, o firmas que actualizar. Mientras más simple
sea la tecnologı́a, menos posibilidades de errores o desconfiguraciones habrá.

Como en cualquier otra tecnologı́a, los honeypots también tienen su debilidad. Esto es debido a que
no reemplaza a la actual tecnologı́a, sino que trabaja con las existentes.
Visión Limitada: Los honeypots pueden sólo rastrear y capturar actividad que interactúen directa-
mente con ellos. Los Honeypots no podrán capturar ataques a otros sistemas vecinos, al menos que
el atacante o la amenaza interactúe con el honeypot al mismo tiempo.
Riesgo: Todas las tecnologı́as de seguridad tienen un riesgo. Los firewalls tienen el riesgo de que sean
penetrados, la encriptación tiene el riesgo de que los algoritmos sean rotos, los sensores IDS tienen el
riesgo de que fallen al detectar ataques. Los Honeypots no son diferentes, tienen un riesgo también.
Especı́ficamente, los honeypots tienen el riesgo de que sean apoderados y controlados por los “chicos
malos” y que lo utilicen para dañar otros sistemas. El riesgo es variado para los diferentes honeypots.
Dependiendo del tipo de honeypots puede haber un riesgo, equivalente a un fallo del sensor IDS,
mientras que en otros honeypots puede que haya que enfrentarse a una situación crı́tica.
13.13.3. Utilidades de honeypots

Cuando son utilizados con propósitos productivos, los honeypots están protegiendo la organización.
En este mundo se incluye, prevención, detección y respuesta a un ataque.
Cuando son utilizados con propósitos de investigación, los honeypots son utilizados para recolectar
información. La importancia de esta información depende según las organizaciones. Algunas organizacio-
nes querrán estudiar la tendencia de las actividades intrusivas, mientras otras estarán interesadas en la
predicción y prevención anticipada, o las fuerzas legales.
En general, honeypots de baja interacción son utilizados con propósitos productivos, mientras ho-
neypots de alta interacción son utilizados con propósitos de investigación. Sin embargo, los dos tipos de
honeypots pueden funcionar para ambos propósitos.
Los honeypots pueden ayudar a prevenir ataques en varias formas. El primero es contra ataques au-
tomatizados, como los gusanos. Estos ataques son basados en herramientas que aleatoriamente escanean
redes enteras buscando sistemas vulnerables. Si un sistema vulnerable es encontrado, estas herramientas
automatizadas atacarán y tomarán el sistema (con gusanos que se replican en la vı́ctima). Uno de las
métodos para protejer de tales ataques es bajando la velocidad de su escaneo y potencialmente detenerlos.
Llamados “sticky honeypots” (Tarros de miel “pegajosos”), estas soluciones monitorean el espacio IP no
utilizado. Cuando los sistemas son escaneados, estos honeypots interactúan con él y disminuyen la velo-
cidad del ataque. Hacen esto utilizando una variedad de trucos TCP, como poniendo el “Window size” a
cero o poniendo al atacante en un estado de espera continua. Ésto es excelente para bajar la velocidad o
para prevenir la diseminación de gusanos que han penetrado en la red interna. Un ejemplo de un sticky
honeypot es: LaBrea Tarpit. Los “honeypots pegajosos” son más comunes encontrarlos entre soluciones de
baja interacción (hasta podrı́a llamársele soluciones “no interactivas”, ya que reducen tanto la velocidad
que hacen “gatear” al atacante. Los Honeypots pueden también protejer nuestra organización de intrusos
humanos. Este concepto se conoce como engaño o disuación. La idea es confundir al atacante, hacerle
perder el tiempo y recursos interactuando con honeypots. Mientras tanto, detectaremos la actividad del
atacante y tendrémos tiempo para reaccionar y detener el ataque. Hasta se puede dar un paso más allá: si
un atacante sabe que nuestra organización está utilizando honeypots pero no sabe cuales son los sistemas
honeypots y cuales son sistemas legı́timos, quizás tenga miedo de ser capturado por honeypots y decida
no atacarlo. Por lo tanto, honeypots disuaden al atacante. Un ejemplo de honeypot diseñado para hacer
esto, es el Deception Toolkit, un honeypot de baja interacción.
La segunda forma por la cual honeypots pueden ayudar a protejer una organización es por medio de
la detección. La detección es crı́tica, su propósito es la identificación de fallos para para la prevención. No
importa cuán segura sea nuestra organización, siempre habrán fallos si los hombres están involucrados en
el proceso... Detectando al atacante, podrán rápidamente reaccionar ante ellos, deteniéndolos, o mitigando
el daño que hicieron. Tradicionalmente, la detección ha sido extremadamente dificil de hacer. Tecnologı́as
como sensores IDS y sistemas de logueo han sido inefectivos por diversas razones: Generan muchos datos,

grandes porcentajes de falsos positivos, inhabilidad de detectar nuevos ataques, y la inhabilidad de tra-
bajar en forma encriptada o en entornos IPv6. Los Honeypots son excelentes en detección, solventando
muchos de los problemas de la detección clásica. Los honeypots reducen los falsos positivos, capturando
pequeñas cantidades de datos de gran importancia, capturan ataques desconocidos como nuevos exploits
o shellcodes polimórficos, y trabajan en forma encriptada o en entornos IPv6. En general, honeypots de
baja interacción son la mejor solución para la detección y tienen un riesgo limitado.
La forma tercera y final por la cual honeypots nos pueden ayudar a protejer una organización es en la
respuesta. Una vez que una organización detecta un fallo, ¿cómo debe responder? Esto es a menudo uno
de los grandes retos a los que nos debemos enfrentar. Hay por lo general poca información acerca de quién
es el atacante, cómo ingresó al sistema o cuánto daño hizo. En estas situaciones, la información detallada
acerca a las actividades del atacante son cruciales.
Hay dos problemas que afectan a la respuesta al incidente: el primero, a menudo los sistemas com-
prometidos no pueden ser desconectados de la red para ser analizados. Sistemas de producción, como el
servidor de correo de una organización, son tan crı́ticos que aunque estén compremetidos los administra-
dores no pueden desconectarlos y hacer un análisis forense como corresponde. Están limitados a analizar
el sistema encendido mientras sigue proveyendo sus servicios productivos. Esto merma la habilidad para
analizar qué sucedió, cuánto daño hizo el atacante, e incluso si el atacante accedió a otros sistemas de la
red. El otro problema es que incluso en el caso de que este desconectado, hay tanta polución de datos que
es muy difı́cil determinar qué es lo que hizo el “chico malo”. Con polución de datos me refiero que hay
tanta actividad (logeo de usuarios, lecturas de cuentas de mail, archivos escritos a bases de datos, etc. . . )
que puede ser difı́cil determinar cuál es la actividad normal del dı́a a dı́a y qué es lo que hizo el atacante.
Los Honeypots pueden ayudar a solventar ambos problemas. Honeypots son un excelente herramienta de
incidencias ya que pueden rápidamente y fácilmente ser sacados de la red para un análisis forense comple-
to, sin el impacto en las operaciones empresariales de todos los dı́as. Recuerden que la única actividad que
guardan los honeypots son las relacionadas con el atacante, ya que no las utilizan nadie (son señuelos),
excepto los atacantes. La importancia de los honeypots aquı́ es la rápida entrega de la información, ana-
lizada en profundidad, para responder rápida y eficientemente a un incidente. En general, los honeypots
de alta interacción son la mejor solución para la respuesta. Para reaccionar ante un intruso, se necesita
conocimientos en profundidad sobre qué hicieron, cómo ingresaron, y qué herramientas utilizaron.
13.13.4. Tipos de honeypots

Los honeypots vienen con diversidad de colores y gustos, haciendo difı́cil su comprensión. Para ayudar-
nos a entender mejor a los honeypots y a todos los diferentes tipos, dividiremos a dos categorı́as generales:
honeypots de “baja interacción” y de “alta interacción”. Estas categorı́as nos ayudan a entender con
qué tipo de honeypots estamos trabajando, sus fortalezas y debilidades. La interacción define el nivel
de actividad que un honeypot le permite tener un atacante. Los honeypots de baja interacción tienen
una interacción limitada, normalmente trabajan únicamente emulando servicios y sistemas operativos. La
actividad del atacante se encuentra limitada al nivel de emulación del honeypot. Por ejemplo, un servicio
FTP emulado escuchando en el puerto 21 probablemente estará emulando un login FTP o probablemente
suportará algúnos comandos FTP adicionales. Las ventajas de un honeypot de baja interacción es su
simplicidad, estos honeypots tienden a ser fáciles de utilizar y mantener con un riesgo mı́nimo.
Por lo general es instalar un software, elegir el sistema operativo y el servicio a emular y monitorear,
y dejar que el programa camine por sı́ solo desde ahı́ . . . Este proceso cercano al “plug and play” hace
que la utilización de éstos sea muy fácil. Incluso, los servicios emulados mitigan el riesgo conteniendo la
actividad del intruso, que nunca tiene acceso al sistema operativo real donde puede atacar o dañar otros
sistemas. Las principales desventajas de los honeypots de baja interacción es que registran únicamente
información limitada y son diseñados para capturar actividad prevista, los servicios emulados sólo pueden
llegar hasta ahı́. También es fácil para un atacante detectar un honeypot de baja interacción, sin importar
cuán buena sea la emulación. Un intruso hábil puede, con el debido tiempo, detectar su presencia. Ejemplos
de honeypots de baja interacción se incluyen: Specter, Honeyd, y KFSensor.
Los honeypots de alta interacción son diferentes, éstos generalmente son soluciones complejas ya que
implica la utilización de sistemas operativos y aplicaciones reales. Nada es emulado, le damos a los in-

trusos algo real. Si queremos un honeypot Linux corriendo un servidor FTP, tendrémos que construir un
verdadero sistema Linux y montar un verdadero servidor FTP. Las ventajas de dicha solución son dos:
Primero, usted capturarámos grandes cantidades de información dándoles a los intrusos algo sistemas
reales con la cual interactuar, podremos aprender la completa extensión de sus actividades, cualquier cosa
desde rootkits nuevos hasta sesiones internacionales de IRC. La segunda ventaja es que los honeypots de
alta interacción no asumen nada, acerca del posible comportamiento que tendrá el atacante, en lugar de
eso proveen un entorno abierto que captura todas las actividades realizadas. Esto permite a las solucio-
nes de alta interacción conocer comportamientos no esperados. Un excelente ejemplo de esto es cómo un
honeypot capturó comandos “back door” codificados en un protocolo IP no estandard (especı́ficamente
protocolo IP 11, Network Voice Protocol). No obstante, esto también incrementa el riesgo de los honey-
pots ya que los atacantes pueden utilizar estos sistemas operativos reales para lanzar ataques a sistemas
internos que no forman parte de los honeypots. En consecuencia, se requiere la implementación de una
tecnologı́a adicional que prevenga al atacante de dañar otros sistemas que no son honeypots. En general,
honeypots de alta interacción pueden hacer todo lo que uno de baja interacción puede hacer y mucho
más, pero pueden ser más complejos de utilizar y mantener. Ejemplos de honeypots de alta interacción
son Symantec Decoy Server y los Honeynets.
13.13.5. Otras caracterı́sticas

Algunos honeypots, como Honeyd, no sólo emulan servicios sino que también emulan el Sistema Ope-
rativo. En otras palabras, Honeyd puede aparentar ser un router Cisco, un webserver WinXP o un servidor
DNS Linux. Existen varias ventajas al emular diferentes sistemas operativos. Primero, el honeypot puede
encajar mejor con la red existente, si el honeypot tiene la misma apariencia y comportamiento que las
computadoras productivas. Segundo, se puede apuntar a atacantes especı́ficos proveyéndoles sistemas y
servicios sobre los que queremos aprender. Hay dos elementos en sistemas operativos emulados:
El primero es el servicio emulado, cuando un atacante se conecta a ese servicio, este se comportá como
si fuera legitimo y aparenta tener un sistema operativo determinado. Por ejemplo, si tiene un servicio emu-
lando un webserver y quiere que su honeypot aparente ser un Win2000 servidor, entonces deberá emular
el comportamiento de un IIS webserver, y para el caso de un Linux, deberı́a emular el comportamiento
de un webserver Apache. La mayorı́a de los honeypots emulan el SO de esta manera. Algunos honeypots
sofisticados llevan la emulación un paso adelante (como lo hace el Honeyd): No sólo emulan en el nivel de
servicio, sino que en el nivel del stack del IP. Si alguien realiza active fingerprinting para determinar el SO
de su honeypot, muchos honeypots responderán al nivel del IP Stack del SO real en donde esté instalado
el honeypot. Honeyd falsea la respuesta, emulando no sólo el servicio sino emulando también el stack del
IP, comportándose como si fuera realmente otro sistema operativo. El nivel de emulación y sofisticación
depende de la tecnologı́a del honeypot que elijamos.
Esto es un resumen de algunos de los HoneyPots que podemos utilizar:

1. De alta interacción: No hay emulación, suministra sistemas operativos y servicios reales.
Honeynets
Symantec Decoy Server
2. De baja interacción: Emula sistema operativos y servicios.
Honeyd
Specter
KFSensor
Deception Toolkit

13.13.6. Honeynets: alta interacción

Los Honeynets son un ejemplo ideal de honeypots de alta interacción. Honeynets no son un producto,
no son una solución software que se instala en una computadora. En lugar de eso, los Honeynets son una
arquitectura, una red entera de máquinas diseñados para ser atacadas. La idea es tener una arquitectura
que sea una red altamente controlada, un lugar donde toda actividad sea controlada y capturada. En
esta red nosotros ponemos a nuestras victimas en forma intencionada, computadoras reales corriendo
aplicaciones reales. Los “chicos malos” encuentran, atacan, rompen estos sistemas en su propia iniciativa.
Cuando hacen esto, ellos no saben que están en un Honeynet. Toda su actividad, desde sesiones encriptadas
SSH hasta correos y archivos subidos son capturados sin que lo noten. Esto es realizado introduciento
módulos en el kernel de los “sistemas vı́ctima” que capturan toda las acciones de los atacantes. Al mismo
tiempo, el Honeynet controla la actividad del atacante. Los Honeynets hacen esto mediante la utilización de
un gateway Honeywall. Este gateway permite el tráfico de entrada a los “sistemas vı́ctima”, pero controla
el tráfico de salida usando tecnologı́as de prevención contra instrusos. Esto le da al atacante la flexibilidad
de interactuar con las sistemas vı́ctimas, pero previene al atacante de dañar otros sistemas que no forman
parte del Honeynet.
13.13.7. Honeyd: baja interacción

Honeyd es un honeypot de baja interacción. Desarrollado por Niels Provos, Honeyd es OpenSource
y está diseñado para correr principalmente en sistemas Unix/Linux (aunque fue portado a Windows).
Honeyd trabaja con el concepto del monitoreo del espacio IP no utilizado. Cuando observa un intento de
conexión a un IP no utilizado, intercepta la conexión e interactúa con el atacante, pretendiendo ser la
vı́ctima. Por defecto, Honeyd detecta y logea cualquier conexión a puertos UDP o TCP. Como si fuera
poco, se pueden configurar los servicios emulados para que monitoreen puertos especı́ficos, como un ser-
vidor FTP emulado, monitoreando el puerto TCP 21. Cuando un atacante conecta el servicio emulado,
el honeypot no sólo detecta y logea la actividad, sino que captura también toda la actividad del atacante
con el servicio emulado. En caso del servidor FTP emulado podemos potencialmente capturar el logins y
passwords, los comandos que introduce y quizás también descubrir lo que está buscando o su identidad.
Todo depende del nivel de emulación del honeypot. La mayorı́a de los servicios emulados trabajan de la
misma manera. Ellos esperan un tipo especı́fico de comportamiento, y están programados para reaccionar
en una forma predeterminada. La limitación está en que si el atacante hace algo que la emulación no tiene
previsto, entonces no saben cómo responder. La mayorı́a de los honeypots de baja interacción, incluyendo
Honeyd, simplemente generará un mensaje de error. Podemos ver cuales son los comandos que soporta el
servidor FTP emulado de Honeyd viendo el código fuente.
En nuestra instalación Debian utilizaremos este paquete honeyd, ya que tiene licencia GPL y es gra-
tuito. Para instalarlo ejecutamos el siguiente apt: #apt-get install honeyd honeyd-common
También podemos encontrar un “kit de herramientas Honeyd para Linux” (Honeyd Linux Toolkit).
Mientras los posibles atacantes se entretienen intentando acceder a servicios que no existen, los IDS
de nuestro sistema los detectarán y podremos tomar acciones preventivas contra sus IP, como filtrarlas en
el firewall.
Una de sus grandes caracterı́sticas es que podemos asignar a cada una de nuestros dispositivos virtuales
el SO que queramos. Esta personalidad también se especifica con un fichero normal de firmas de SO de
Nmap, permitiéndonos convertirnos en el SO que queramos. Si ejecutamos la configuración que viene como
ejemplo, veremos de lo que es capaz.
Después de instalarlo, hay un fichero que se llama config.localhost con un montón de dispositivos con-
figurados. Lo podemos encontrar en: /usr/share/doc/honeyd/examples/config.localhost

Si observamos la definición del dispositivo 10.0.0.1 de ejemplo, veremos lo siguiente:
#cat /usr/share/doc/honeyd/examples/config.localhost|more
...
route entry 10.0.0.1
route 10.0.0.1 link 10.0.0.0/24
...
create routerone
set routerone personality "Cisco 7206 running IOS 11.1(24)"
set routerone default tcp action reset
add routerone tcp port 23 "router-telnet.pl"
...
bind 10.0.0.1 routerone
...
La explicación a grandes rasgos es que tenemos un dispositivo cuya dirección IP es 10.0.0.1, que se
comportará como un Cisco 7206 ejecutando una IOS 11.1(24), reseteará todas las conexiones TCP menos
las que vayan al puerto 23, ya que entonces el script router-telnet.pl (una emulación del demonio telnet)
será ejecutado.
Ahora ejecutemos Nmap para comprobar el SO que se ejecuta en el dispositivo virtual que acabamos
de crear:
# nmap (V. 3.10ALPHA4) scan initiated: nmap -v -sS -oN nmap4.

Warning: OS detection will be MUCH less reliable because we did not find at least
Interesting ports on 10.0.0.1:
(The 1604 ports scanned but not shown below are in state: filtered)
Port State Service
23/tcp open telnet
Remote OS guesses: Cisco 7206 running IOS 11.1(24), Cisco 7206 (IOS 11.1(17)
TCP Sequence Prediction: Class=random positive increments
Difficulty=26314 (Worthy challenge)
IPID Sequence Generation: Incremental
# Nmap run completed -- 1 IP address (1 host up) scanned in 178.847 s
Cuando recibimos los paquetes de Nmap, honeyd responde con la personalidad que hemos escogido.

Capı́tulo 14
Redes inalámbricas
En el proyecto he habilitado una red wifi, pero hoy los administradores de sistemas y conocen los
peligros que esto entraña, seran muy reacios a implantar este tipo de redes, pero es muy probable que las
circunstancias lo obliguen a implantar este tipo de tecnologı́a.
Aunque no tengamos red inalámbrica, debemos auditar la red frecuentemente y asegurarnos que nadie
está ejecutando un punto de acceso ilegal.
Hasta hace muy poco los administradores de red sólo tenı́an que preocuparse de asegurar los bienes
de la tecnologı́a de información fı́sicos y fijos, incluyendo los servidores, los enrutadores y los cortafuegos:
todo lo que configura sus redes de lı́nea de cable. Sin embargo, con el advenimiento del equipamiento de
redes inalámbricas existe todo un espectro nuevo de problemas seguridad que tratar.
Esta nueva tecnologı́a ha ayudado a rebajar el coste del despliegue de redes, ha traı́do acceso a sitios
a los que no se podı́a acceder antes y ha convertido el término “informática móvil” en una realidad.
Ha cambiado drásticamente el perı́metro de seguridad de redes de las empresas de todos los tamaños.
Tradicionalmente, las redes corporativas se conectaban al mundo exterior en sólo unos pocos lugares. Ası́,
los administradores de redes se podı́an concentrar en proteger estos puntos de acceso limitados. Podı́an
colocar cortafuegos o otras defensas en esos puntos de contención cruciales. El interior de la red se trataba
como de confianza porque no habı́a forma de introducirse que no fuese a través de los puntos protegidos.
Ahora con una LAN inalámbrica desplegada, nuestro perı́metro de seguridad se convierte literalmente
en el aire que nos rodea. Los atacantes sin cables pueden provenir de cualquier dirección. Si tenemos
desplegado un acceso sin cables, cualquiera con una tarjeta de unos 50e puede escuchar potencialmente
el cable de nuestra red sin poner un pie en nuestro local. Si estamos utilizando la tecnologı́a sin cables
para parte de nuestra red, nuestras amenazas de seguridad crecen considerablemente.
Antes de asegurar correctamente nuestra red inalámbrica, tenemos que saber cómo funcionan las redes
del área local inalámbrica y cuáles son sus puntos débiles.
Los fabricantes del equipamiento LAN inalámbrico han reducido tanto los precios que ahora es una
alternativa muy viable para las redes domésticas. En lugar de cablear nuestra casa para conectar nuestros
PCs a Ethernet, podemos comprar un punto de acceso (AP, Access Point) y un par de tarjetas inalámbricas
y utilizar Internet desde cualquier habitación de nuestra casa (o fuera de ella). El amplio despliegue de la
tecnologı́a LAN inalámbrica ha llegado definitivamente para quedarse y tarde o temprano tendremos que
tratar con ella.
14.1. Estándar 802.11 (Wifi)

El protocolo más popular para la tecnologı́a LAN inalámbrica es actualmente la serie 802.11, conocido
comúnmente como wifi. Los estándares inalámbricos de 802.11 son básicamente una extensión del protocolo
Ethernet, es la razón por la que funciona también con las redes Ethernet con cables. Utiliza las frecuencias
de 2.4 GHz para 802.11b y 802.11g y 5 GHz para 802.11a para señales de transmisión de datos. Estas
frecuencias son del espectro de uso general, por lo que no tendremos que pedir ninguna licencia para
utilizarlas. El inconveniente es que otros dispositivos pueden utilizar también estas longitudes de onda.
Algunos teléfonos inalámbricos y microondas se encuentran en la banda de los 2.4 GHz, por lo que si
tenemos este tipo de dispositivos u otras redes wifi en nuestro área podemos encontrarnos con algunas
interferencias.
Esta longitud de onda es perfecta para el corto rango deseado para wifi. Sus parámetros de diseño
permiten aproximadamente unos 45,72 metros interiores y unos 244 metros exteriores en condiciones nor-
males. Sin embargo, con una antena de alta potencia y alcance, podemos tener hasta un rango de 32,19
Km., algo atractivo para las comunicaciones de oficina a oficina dentro de una ciudad. El cuadro 14.1
incluye una descripción de los cuatro tipos de estándares inalámbricos 802.11 que han aparecido.
Cuadro 14.1: Estándares de 802.11 inalámbricos

Estándar Descripción
802.11a Esta versión del estándar utiliza una logitud de onda de 5 GHz, un espectro menos aba-
rrotado y menos propenso a tener problemas de interferencias. El potencial teórico para
esta tecnologı́a es de 54 Mps, una gran cantidad de ancho de banda, pero la mayorı́a de
las aplicaciones en el sector no se acercan a esa cantidad.
802.11b Utiliza una longitud de onda de 2.4 GHz, como Bluetooth y otros dispositivos. Ofrece hasta
11 Mps de ancho de banda, aunque las aplicaciones prácticas por debajo de las condiciones
óptimas trabajan a la mitad de dicha cantidad.
802.11g Actualmente es el estándar inalámbrico más conocido. Proporciona hasta 54 Mps de ancho
de banda, pero en el mismo espectro de 2.4 GHz que 11b. También es compatible hacia
atrás con el hardware de 11b.
802.11i Este nuevo protocolo es básicamente una extensión de 802.11b que se adhiere al protocolo
de cifrado para ser mucho más seguro. El IEEE acaba de aprobarlo y ya podemos encontrar
productos que lo implementan.
Una red wifi inalámbrica puede operar en uno de estos dos modos:
Modo adhoc: Nos permite conectar directamente dos nodos juntos. Este modo es útil para conectar
algunos PCs juntos que necesiten acceso a una LAN o a Internet.
Modo de infraestructura: Nos permite establecer una estación base, conocida como punto de acceso
(AP, Access Point), y conectarla a nuestra LAN. Todos los nodos sin cables se conectan a la LAN
través de este punto. Ésta es la configuración más común en redes corporativas ya que permite al
administrador controlar el acceso sin cables a un punto. Cada punto de acceso y tarjeta inalámbricos
tiene un número asignado, es el ID del nodo cliente (BSSID, Basic Station System ID). Ésta es
la dirección MAC para los clientes inalámbricos que se asocian al nodo servidor. Este nombre no
es necesariamente único a dicho punto de acceso. De hecho, la mayorı́a de los fabricantes asignan
un SSID predeterminado a los AP para que puedan utilizarse inmediatamente. El SSID del punto
de acceso es necesario para conectarse a la red. Algunas estaciones base tienen una funcionalidad
adicional, incluyendo enrutadores y servidores DHCP incorporados. Existen incluso algunas unidades
integradas que actúan como puntos de acceso sin cables, cortafuegos y enrutador para usuarios
domésticos y de pequeños negocios. Yo dispongo de un router 3Com ADSL 11g de este tipo.
Podemos configurar un nodo de red inalámbrica instalando una tarjeta de interfaz de red (NIC, Net-
work Interface Card) en un ordenador. Una NIC inalámbrica puede ser de varios tipos: puede ser una
tarjeta que se introduce en la ranura del PC, una tarjeta PCMCIA, un dispositivo USB, etc. Una red
inalámbrica 802.11 en un modo de infraestructura tiene un punto de acceso que actúa como puente entre
la LAN de Ethernet con cables y uno o más puntos extremo sin cables. El punto de acceso envı́a frecuen-
temente transmisiones de “señales luminosas” para que cualquier nodo sin cables sepa que está ahı́. Las
transmisiones de señales luminosas actúan como un faro invitando a cualquier nodo sin cables del área a
iniciar la sesión. Estas señales forman parte del problema con wifi. es imposible desactivar completamente
dichas señales, lo que dificulta ocultar el hecho de que hay una red inalámbrica. Cualquiera que tenga
una tarjeta inalámbrica puede, al menos, ver las señales luminosas si se encuentran dentro de un rango,
aunque algunos receptores permiten limitar la cantidad de información que sale de dichas transmisiones.
Estas señales contienen información básica sobre el punto de acceso inalámbrico, normalmente inclu-
yendo su SSID. Si la red no está utilizando ningún cifrado ni ninguna otra protección, esto es todo lo que se

Capı́tulo 14. Redes inalámbricas 259
requiere para que un intruso acceda a la red. Sin embargo, incluso en una red inalámbrica cifrada, el SSID
normalmente se transmite al descubierto y los paquetes cifrados pueden ser escuchados clandestinamente
en el aire y están sujetos a intentos de decodificación.
14.2. Peligros de las LAN inalámbricas

Aunque ofrecen la misma flexibilidad y funcionalidad que pueden ofrecer las LAN con cables, también
introducen algunos retos y peligros únicos para el administrador de redes preocupado por la seguridad.
Éstos son algunos de los que tenemos que tener en cuenta al añadir una LAN inalámbrica a nuestra
infraestructura:
Escuchas clandestinas: Lo más ácil para un intruso en una red inalámbrica es recopilar paquetes
utilizando un sniffer. Poco podemos hacer frente a ello, Los diseñadores de las redes inalámbricas
pensaron sobre ello e introdujeron en el diseño un cifrado estándar denominado Privacidad equivalen
al cable (WEP, Wired Equivalente Privacy) para que los datos se pudieran cifrar. Lamentablemente,
un fallo fundamental en cómo funcionan los algoritmos RC4 en los que esta basado hacen que los
datos se puedan descifrar. Por lo tanto, incluso aunque se ejecute WEP, cualquier dato que viaje
por una red inalámbrica está potencialmente sujeto a su inspección por personas ajenas a la red.
Alguien podrı́a escuchar sobre nuestro enlace sin cables para buscar los registros de inicio de sesión,
las contraseñas o cualquier otro dato.
Acceder a los PC sin cables: Un enlace inalámbrico proporciona a un atacante potencial un vector en
una máquina de nuestra red. Aparte de los puntos de acceso, las máquinas con tarjetas inalámbricas,
a veces, se pueden ver desde el exterior. Si utilizan este modo de acceso pueden lanzar ataques contra
una máquina que probablemente no está protegida por el cortafuegos y puede que no se bloqueen
como las defensas del perı́metro o los servidores públicos.
Acceder a la LAN : Probablemente éste sea el mayor peligro que presentan las redes inalámbricas.
Si los intrusos pueden obtener el acceso a nuestra LAN a través de un punto de acceso inalámbrico,
normalmente tienen las llaves de nuestro reino. La mayorı́a de las LAN ejecutan un servidor DHCP
sin restringir, por lo que los intrusos pueden obtener una dirección IP válida y empezar a explorar
nuestra red. A continuación pueden ejecutar un escáner de vulnerabilidades (como Nesus) o un
escáner de puertos como Nmap (Vease sección 17) para encontrar máquinas de su interés y buscar
brechas que puedan aprovechar.
Acceso anónimo a Internet: Aunque los intrusos no estén interesados en lo que contienen nuestra
LAN, pueden utilizar nuestro ancho de banda para otros usos. Al iniciar la sesión en nuestra red y
acceder después a Internet, pueden piratear nuestra red y hacer el daño que quieran sin que podamos
seguirles la pista. Cualquier ataque o daño perpetrado desde esta conexión se rastreará hacia nuestra
red. Las autoridades pueden llamar a nuestra puerta, no a la suya. Este método de piraterı́a se
hará cada vez más comun a medida que los intrusos se den cuenta de lo difı́cil que es rastrear
los ataques que se originan de esta manera. Existen pocas posibilidades de capturar a alguien que
proviene de una red inalámbrica a no ser que tenga un equipo de triangulación situado de antemano,
algo bastante caro y poco habitual. Las LAN inalámbricas no aseguradas ofrecen a los intrusos el
mejor acceso anónimo que existe.
Vulnerabilidades especı́ficas de 802.11 : Además de las inseguridades de las LAN inalámbricas, existen
algunos problemas especı́ficos del estándar 802.11. Algunos de ellos se deben a un mal diseño del
fabricante o a las configuraciones predeterminadas, otros problemas se deben al diseño general de
estándar.
SSID predeterminados: Cada estación base wifi tiene un identificador especı́fico que debemos conocer
para entrar en la red. Este identificador proporciona algún nivel de seguridad si se implanta correc-
tamente. Lamentablemente, muchas personas no cambian el SSID predeterminado del fabricante,
como linksys, default, etc. Cuando un intruso lo encuentra, puede suponer que el administrador no
ha perdido mucho tiempo en configurar y asegurar la red inalámbrica.

Transmisión de señales luminosas: La transmisión de señales luminosas son un problema inherente a

las redes inalámbricas. La estación base debe emitir regularmente su existencia para que los emisores
del usuario final puedan encontrar y negociar una sesión y como los dispositivos legı́timos del usuario
no se han autenticado todavı́a, esta señal debe transmitirse al descubierto. Cualquiera puede capturar
esa señal y, como mı́nimo saber que tenemos una LAN inalámbrica. Muchos modelos nos permiten
desactivar la parte SSID de la transmisión para que, al menos, sea más difı́cil de captar para las
escuchas clandestinas de redes inalámbricas, pero SSID se sigue enviando cuando una estación se
conecta, por lo que sigue existiendo una pequeña ventana de vulnerabilidad.
Comunicaciones sin cifrar de forma predeterminada: La mayorı́a de los dispositivos LAN inalámbri-
cos de hoy en dı́a ofrecen la opción de activar el cifrado WEP estándar . El problema es que normal-
mente se tiene que hacer manualmente. Muchos fabricantes comercializan su equipamiento con esta
opción desconectada de forma predeterminada. Muchos administradores tienen prisa por configurar
su red inalámbrica y no tienen mucho tiempo para activar esta importante función. Si una persona
no técnica configura la red, es muy probable que no se active el cifrado. También existe el problema
de la clave compartida por todos nuestros usuarios ya que WEP utiliza una sola clave entre todos
ellos, lo que puede llegar a convertirse en una pesadilla si tenemos muchos usuarios conectándose sin
cables.
Punto débil de WEP : Incluso cuando se utiliza el cifrado incorporado, la señal sigue teniendo el riesgo
de ser leı́da. Existen algunos puntos débiles fundamentales en la implantación del algoritmo RC4
utilizado para el cifrado en WEP que permiten que se descifren una vez interceptada una cantidad de
tráfico. Estos puntos débiles tienen que ver con la forma en que se programan las claves. WEP utiliza
vectores de inicialización débiles con un porcentaje suficientemente alto como para que finalmente
puedan descifrarse. Una vez roto el cifrado, no sólo los atacantes pueden leer todo el tráfico de la red
inalámbrica sino que probablemente puedan entrar en la red. Por lo tanto, aunque WEP ofrece una
protección básica frente a escuchas clandestinas casuales, cualquier intruso serio tendrá el software
como para descifrar potencialmente el cifrado.
14.3. El fenómeno del “Wardriving”

La búsqueda de LANs inalámbricas inseguras se ha convertido en un pasatiempo popular entre los
piratas informáticos. Esta práctica se conoce como “wardrive” o “wardriving”, funciona de la misma forma
que el marcado telefónico en masa o guerra del marcado telefónico, de los primeros piratas informáticos,
consiste en seleccionar de forma aleatoria bancos de números de teléfono para encontrar módems activos.
En general, los piratas informáticos conducen un automóvil con una tarjeta inalámbrica y algún soft-
ware buscando una señal de una red. El software puede registrar la ubicación exacta de la red inalámbrica
a través del GPS ası́ como otra gran cantidad de información como: si está cifrada o no y que tipos de
protecciones se encuentran activas. Los que realizan el “wardring” pueden explorar Internet o la LAN
local sobre el enlace sin cables. No se requiere un alto nivel de conocimientos para hacerlo, por lo que hay
intrusos de todos los niveles.
Las empresas que utilizan LAN en entornos densos alrededor de sus oficinas o cerca de carreteras
principales y autopistas son los entornos más propensos a este tipo de actividad, como oficinas en entornos
urbanos y áreas del centro donde hay muchos edificios altos. Las redes inalámbricas que utilizan 802.11b
tienen una distancia efectiva de un par de cientos de metros. Es fácil crear un puede entre el espacio
comprendido entre dos edificios o varias plantas en un edificio alto. En una zona del centro densa, es
común encontrar varias LAN inalámbricas sin protección dentro de un edificio. Desde el punto de vista de
la seguridad, los edificios altos suelen ser uno de los peores lugares para ejecutar una LAN inalámbrica.
el tı́pico edificio de cristal permite que las señales de su LAN viajen a mucha distancia. Si hay otros
edificios cerca, es casi seguro que podrán recoger algunas de sus señales. Incluso es peor los edificios altos
que se encuentran junto a una zona residencial. Imaginemonos a los adolescentes y otros recién llegados
escaneando en busca de las LAN inalámbricas disponibles, desde la comodidad de sus habitaciones en las
afueras de una ciudad.
Aproximadamente un 60 por ciento de las LAN inalámbricas son completamente inseguras. Los que
realizan los paseos de batalla han llegado incluso a anunciar puntos de acceso sin cables en bases de datos

online con mapas para que cualquiera pueda encontrar una LAN Inalámbrica bierta en cualquier parte.
Las catalogan por tipo de equipamiento, cifradas o no cifradas, etc. Si tenemos una LAN inalámbrica en
un área metropolitana importante, es probable que esté catalogada en uno de estos sistemas, esperando
sólo a que cualquier intruso oportunista de su zona al que le sobre algo de tiempo. Las siguientes son bases
de datos online que se pueden consultar para ver si nuestra LAN se encuentra ya catalogada:
http://www.wifimaps.com/
http://www.nodedb.com/europe/es
http://www.cybergeography.org/spanish/wireless.html
Existe hasta un catalogo de simbolos estandarizado para identificar redes wifis urbanas:
Figura 14.1: Sı́mbolos urbanos de redes wifi

Es tan grande este fenómeno que hace unos meses en las islas canarias, se organizo el primer campeona-
to de Wardriving de España (Canarias Wardrive’05), podemos encontrar mas información en esta dirección:
http://www.canariaswardrive.org/
Estas son las curiosas bases del concurso:
“Solo necesitamos explorar nuestra propia ciudad empleando un simple portátil, pda o similar,
dotado de una tarjeta wifi. La competición se divide en tres categorı́as territoriales:
Competición de Wardrive en Tenerife
Competición de Wardrive en Gran Canaria
Competición de Wardrive en toda Canarias
En estas competiciones se permite la participación individual o por equipos. Trabajando en
equipo se cubre más territorio y se encuentran los focos emisores más rapidamente. Una com-
petición sin carácter regional es la de los MiniGames, se celebrarán en Tenerife. En ellos se
plantearan a los competidores retos tales como intentar romper la seguridad de redes. Un sis-
tema homologado de puntuación asignará una cantidad de puntos dependiendo del tipo de red
local. La participación en este tipo de competición exige inexorablemente un comportamiento
deportivo intachable.”
Ha más de un administrador de sistemas se le pondrán los pelos de punta al leer esto.
14.4. Seguridad en redes inalámbricas

Si tenemos la red inalámbrica sin cifrado, cualquier intruso podrá leer los datos que mandemos o incluso
entrar en nuestra red. Es necesario implantar una serie de medidas: cifrado de datos, concienciación del
personal, auditorias, etc.
14.4.1. Clave WEP (Wired Equivalente Privacy)

La clave WEP es una clave asimétrica, compartida por todos los usuarios inalámbricos. Está basada
en el algoritmo RC4 y tiene un nivel de seguridad débil. Es debido a un fallo del algoritmo, crea una serie
de vectores de inicialización débiles que con un trafico de red suficiente, permiten deducir la clave. Fue
introducida con el estándar 802.11a y actualmente ha quedado superado por WPA.
Si en vez de tener una red abierta, al menos, ciframos los datos con clave WEP, los intrusos tendrán
que perder tiempo y esfuerzo en obtenerlos. Esto desanimará a intrusos casuales, y hará que los serios
tengan que quedarse por nuestra zona varios dı́as, aumentando las posibilidades de que el personal de
seguridad o los vigilantes noten su presencia.
La clave WEP, no es recomendable, ya que WPA representa una mejor forma de protección. En
determinadas situaciones, puede ser suficiente pero esto solo tiene lugar en entornos que no manejan datos
sensibles y donde se produzca muy poco trafico de red.
14.4.2. Clave WPA (Wifi Protected Access)

Esta destinada a garantizar la seguridad en las especificaciones IEEE 802.11a, 802.11b y 802.11g,
mejorando las claves WEP; En abril de 2003 aparecieron en el mercado los primeros productos que
incorporaban tecnologı́a de cifrado WPA.
En la figura 14.2 podemos ver una comparativa entre las claves WEP Y WPA.

Figura 14.2: Comparativa entre WEP y WPA
Privacidad e integridad con TKIP
TKIP (Temporal Key Integrity Protocol) amplı́a y mejora a WEP, solucionando sus vulnerabilidades.
Amplı́a la longitud de la clave de 40 a 128 bits y pasa de ser única y estática, a ser generada de forma
dinámica, para cada usuario, para cada sesión (teniendo una duración limitada) y para cada paquete
enviado. Conceptualmente el vector de inicialización pasa de 24 a 48 bits, minimizando la reutilización de
claves. También utiliza claves para tráfico de difusión y multidifusión.
Utiliza el algoritmo “Michael” para garantizar la integridad, generando un bloque de 4 bytes (denomi-
nado MIC) a partir de la dirección MAC de origen, de destino y de los datos, añadiendo el MIC calculado
a la unidad de datos a enviar. Posteriormente los datos (que incluyen el MIC) se fragmentan y se les asigna
un número de secuencia. La mezcla del número de secuencia con la clave temporal genera la clave que se
utilizará para el cifrado de cada fragmento.
Autenticación mediante 802.1X/EAP
El estándar IEEE 802.11x define un protocolo para encapsular, protocolos de autenticación sobre
protocolos de enlace de datos. IEEE 802.11x permite utilizar diversos métodos para autentificar al usuario
a través del protocolo de autenticación extensible (EAP). Se concibe como una ampliación de la capa de
enlace de datos:
Figura 14.3: Funcionamiento WPA/EAP

IEEE 802.11x define 3 entidades:

El solicitante (supplicant), reside en la estación inalámbrica
El autenticador (authenticator), reside en el AP
El servidor de autenticación, reside en un servidor AAA (Authentication, Authorization, & Accoun-
ting), como los servidores Radius
Utiliza un método de control de acceso basado en el concepto de puerto (PAE, Port Acess Entity). El
autenticador crea un puerto lógico por cliente, existiendo dos caminos uno autorizado y otro no. Mientras
el cliente no se ha autenticado con éxito únicamente se permite tráfico 802.11x/EAP hacia el servidor de
autenticación.
Figura 14.4: Autenticación mediante un servidor Radius
El solicitante cuando pasa a estar activo en el medio, selecciona y se asocia a un AP. El autenticador
(situado en el AP) detecta la asociación del cliente y habilita un puerto para ese solicitante, permitiendo
únicamente el tráfico 802.11x, el resto de tráfico se bloquea. El cliente envı́a un mensaje “EAP Start”. El
autenticador responde con un mensaje “EAP Request Identity” para obtener la identidad del cliente, la
respuesta del solicitante “EAP Response” contiene su identificador y es retransmitido por el autenticador
hacia el servidor de autenticación. A partir de ese momento el solicitante y el servidor de autenticación
se comunicarán directamente, utilizando un cierto algoritmo de autenticación que pueden negociar. Si el
servidor de autenticación acepta la autenticación, el autenticador pasa el puerto del cliente a un estado
autorizado y el tráfico será permitido.
Los métodos de autenticación definidos en WPA son: EAP-TLS, EAP-TTLS y PEAP. Estos métodos se
basan en la infraestructura de clave pública (PKI) para autenticar al usuario y al servidor de autenticación,
utilizando certificados digitales. La premisa es la existencia de una Autoridad de Certificación (CA) de
confianza para la corporación, que emita certificados para los usuarios y el servidor de autenticación. La
CA puede ser privada (empresarial) o pública (basada en CAs de Internet como Verisign).
EAP-TLS (TRANSPORT LAYER SECURITY)

Los usuarios y el servidor de autenticación deben tener un certificado digital. El solicitante, tras la
asociación y la creación del puerto de acceso por el autenticador, envı́a su identificación (nombre de
usuario) hacia el autenticador y éste hacia servidor de autenticación. Este último envı́a su certificado al
cliente, al validarlo el cliente responde con su certificado. El servidor de autenticación comprueba si el
certificado es válido y corresponde con el nombre de usuario antes enviado, si es ası́ autentica al cliente.
Cliente y servidor generan la clave de cifrado para esa sesión, y el servidor de autenticación la envı́a al
punto de acceso, de forma que ya puede comunicarse el cliente de forma segura.

PEAP y EAP-TTLS
EAP-TLS exige que todos los clientes dispongan de un certificado digital lo que puede ser, en muchos
casos, un inconveniente técnico y económico. Para evitar esta necesidad aparecen 2 métodos: Protected
EAP (PEAP) y EAP-Tunneled TLS (EAP-TTLS), que requieren únicamente del certificado en el servidor
de autenticación.
La idea subyacente es que si el servidor de autenticación dispone de un certificado digital, el cliente
podrá enviarle datos cifrados, creándose un “túnel de seguridad” por donde el cliente podrá enviar sus
datos de autenticación.
PEAP fue diseñado por Microsoft, Cisco y RSA. Cuando el cliente ha validado el certificado del
servidor de autenticación y creado el túnel, usando TLS se inicia una nueva autenticación donde negocian
un método, por ejemplo MS-CHAP v2, tras autentificar el servidor al cliente, ambos generan la clave de
sesión. EAP-TTLS fue diseñado por Funk Software. También se basa en crear en primer lugar un túnel TLS
pero los mensajes que intercambia son pares valor atributo (“attribute-value pairs”-AVPs) muy similares
a los que utiliza Radius. TTLS soporta todos los métodos EAP y se abre a nuevos métodos.
WPA y seguridad en pequeñas oficinas

Los métodos soportados por EAP necesitan de una cierta infraestructura, fundamentalmente de un
servidor Radius, lo que puede limitar su implementación en redes pequeñas. Wifi ofrece los beneficios de
WPA mediante el uso de una clave pre-compartida (PSK, pre-shared key) o contraseña. Esto posibilita el
uso de TKIP, pero configurando manualmente una clave en el cliente wireless y en el punto de acceso.
WPA y el uso de AES

Las directrices del estándar final IEEE 802.11i (denominado RSN: Robust Security Network) marcan
como algoritmo de cifrado a AES (Advanced Encryption Standard), basado en el algoritmo Rijndael para
proporcionar privacidad y en claves de 128 bits o más. Parece que la implementación más probable es el
modo Cipher Block Chaining Counter Mode (CBC-CTR) con Cipher Block Chaining Message Authenticity
Check (CBC-MAC), conocido el conjunto como CBC-CCM. AES ya ha sido adoptado como estándar para
cifrado en sistemas de computación y comunicaciones. WPA indica el soporte de AES como opcional,
existiendo dispositivos que lo implementan.
Implementación de WPA
Para soportar WPA, en caso de que los productos no estén certificados por su uso, debemos actualizar
el firmware de los puntos de acceso y de los adaptadores de red inalámbricos de las estaciones. En las
estaciones se deberá actualizar el sistema operativo para soportar 802.11x y el método EAP elegido. Por
ejemplo, Windows XP soporta WPA mediante una actualización.
Según el método EAP elegido habrá que definir la configuración del servidor Radius. También es posible
que tengamos que utilizar o implementar los servicios de una Autoridad de certificación.
Conclusiones sobre el uso de WPA

La seguridad es una cuestión conjunta por lo que las directivas aplicables a los segmentos de redes
inalámbricas deben integrarse con el resto de directivas. Por ejemplo, el uso de cortafuegos para conectar la
red inalámbrica con la red corporativa, añadiendo capacidades de detección de intrusos e incluso de analizar
el tráfico inalámbrico y detectar puntos de acceso no autorizados son mecanismos de seguridad necesarios
para garantizar los requerimientos de seguridad. Asimismo, tanto los clientes como servidores deberán de
seguir las directivas de seguridad definidas que deben incluir, como mı́nimo, el uso de antivirus, cortafuegos
personales, detección de intrusos, actualización de software, eliminación de servicios innecesarios
A la espera de poder implementar el estándar final sobre seguridad en redes inalámbricas (802.11i)
la especificación Wifi Protected Access (WPA) ofrece una solución fiable y robusta para garantizar la
privacidad, integridad y autenticación. Garantizando, además, la interoperabilidad entre fabricantes y
ofreciendo un modo “natural” de migrar hacia WPA2.

14.4.3. Clave WPA2 (Estándar 802.11i)

Aunque hace ya varios años que se desvelaron las vulnerabilidades del protocolo WEP (razón por
la que fue sustituido por WPA basado en TKIP), esta tecnologı́a dejó de ser un borrador a finales de
junio de 2004, por lo que ya podemos referirnos a ella como un estándar aprobado por el IEEE. Esta
nueva especificación utiliza el algoritmo de cifrado AES (Advanced Encryption Standard), un mecanismo
extremadamente seguro que mereció en su dı́a la aprobación del NIST (National Institute of Standards
and Technology).
WPA2 se basa en 802.11i y es compatible con WPA. La llegada de 802.11i debe ser acogida con
entusiasmo debido al elevado nivel de seguridad que ofrece. Aun ası́, es necesario tener en cuenta que el
algoritmo de cifrado AES requiere unas condiciones y una exigencia al hardware bastante alta, lo que
significa que algunas interfaces inalámbricas antiguas no serán capaces de satisfacer los requisitos de este
estándar.
Dentro de algún tiempo WPA2 se convertirá en el estándar de seguridad para las redes inalámbricas.
14.4.4. Medidas preventivas

La implantación de cualquier acceso inalámbrico tiene un riesgo, pero se puede reducir tomando una
serie de medidas preventivas.
Tratar la red inalámbrica como de no confianza

Como no se puede controlar el tráfico entrante por el aire, no se deberı́a tratar de forma distinta a la
parte pública del cortafuegos. Si nos lo podemos permitir, es recomendable situar un cortafuegos entre su
red inalámbrica y la LAN privada o situarla en una DMZ (Zona desmilitarizada). Después se puede filtrar
determinados tipos de paquetes de ataque, limitar los tipos de tráfico y registrar cualquier actividad que
provenga de dicha interfaz.
Auditar el perı́metro inalámbrico regularmente

Hay que probar la distancia de la señal, si la red está superpuesta sobre otras redes cercanas.
Es necesario realizar una tarea periódica para localizar cualquier punto de acceso “no controlado”.
La tecnologı́a inalámbrica es ahora tan barata que cualquier usuario de nuestro sistema puede comprar,
instalar y configurar una tarjeta wifi para algún propósito licito o no, como puede ser una demostración sin
cables en una sala de conferencias, abriendo ası́ nuestra red para los ataques inalámbricos. Actualmente
podemos encontrar hasta tarjetas de red wifi para USB.
Asimismo, no hay que olvidar que muchos PCs nuevos, especialmente portátiles, tienen incorporadas
tarjetas wifi y habilitarlas es cosa de niños. Podemos estar funcionando de forma inalámbrica en nuestra
red sin darnos cuenta. Una auditorı́a inalámbrica es la única forma de descubrirlo.
Configurar correctamente la red inalámbrica

Existen muchas opciones y configuraciones que podemos utilizar para aumentar considerablemente
nuestra seguridad y aunque no todos los equipamientos admiten estas opciones, podemos intentarlas.
Desactivar la transmisión de SSID: Esta tarea requiere que el usuario conozca el SSID para establecer
una sesión con la estación base. Actúa como una contraseña débil. Sin embargo, si una escucha
clandestina descifra el cifrado, podrá obtener el SSID fácilmente.
Restringir el acceso por la dirección MAC: Ası́ es más difı́cil para alguien obtener acceso a nuestra
red a través de una estación base inalámbrica. En la mayorı́a de los puntos de acceso, podemos
restringir el mismo a determinadas direcciones MAC hardware, un método bastante sólido para la
autenticación, ya que sólo las personas con la tarjeta con un número de serie correcto pueden obtener
acceso. Sin embargo, puede ser incómodo para un administrador mantener el registro de las tarjetas
NIC autorizadas, eso si contar que no permite el acceso instantáneo a un nuevo usuario en nuestra
oficina. Ası́ mismo, si el atacante conoce una de las direcciones MAC autorizadas, es posible falsificar
esta dirección en su propia tarjeta y hacerse pasar por el propietario.

Formar al personal
Igual que sucede con todo lo referente a la seguridad informática, el elemento humano puede ser el
punto más débil o el más fuerte. Hay que asegúrese de que los guardas de seguridad, los recepcionistas y
otro tipo de personal sepan buscar un comportamiento sospechoso. Por ejemplo, si ven a alguien sentado
en su aparcamiento durante mucho tiempo dentro del coche, posiblemente con una antena extraña en el
techo del mismo, es muy probable que se trate de alguien que busca entrar en nuestra red inalámbrica.
Asimismo, hay que desarrollar una polı́tica a nivel de toda la empresa. Algunas veces una demostración
es la mejor forma de mostrar este tipo de peligro. Un personal informado puede ser nuestra mejor defensa.
14.5. Servidor Radius: FreeRadius

Lo que vamos a montar es un sistema EAP-TLS (Vease sección 14.4.2) donde el servidor y los usuarios
necesitan tener un certificado digital para comunicarse. Es necesario que el servidor Radius se coloque en
la misma máquina donde se encuentra el cortafuegos.
Para configurar el sistema hay que seguir el siguiente esquema (Vease figura 14.5):
Instalamos FreeRadius: #apt-get install freeradius
Configuramos FreeRadius para trabajar con EAP-TLS
Generamos los certificados
Comprobamos que FreeRadius funciona correctamente
Configuramos el AP (Router 3Com)
Configuramos los clientes Linux
Configuramos los clientes Windows XP (Actualizado a Service Pak 2)
La información utilizada se puede encontrar en los siguientes HowTos:

HowTo 802.1x: http://tldp.org/HOWTO/html single/8021X-HOWTO/
HowTo EAP-TLS: http://www.missl.cs.umd.edu/wireless/eaptls/
HowTo Radius en WindowsXP: http://www.dslreports.com/forum/remark,9286052˜mode=flat
14.5.1. Configurar FreeRadius con EAP-TLS

Los archivos de configuración se encuentra en: /etc/freeradius/, los comentarios que llevan integra-
dos en el código ayudan bastante a la configuración y es muy recomendable leerlos.
Hay que realizar las siguientes modificaciones:

/etc/freeradius/radiusd.conf : Fichero de configuración general de Radius. Aquı́ definimos los siste-
mas de autenticación. Hay muchas partes del fichero que no he utilizado.
/etc/freeradius/eap.conf : Fichero de configuración del servicio EAP del servidor radius.
/etc/freeradius/clients.conf : Aquı́ se configuran las IPs y las redes de sistemas que pueden ser clientes
de radius, en nuestro caso el AP (router 3Com, con IP 172.16.1.253)
client 172.16.1.253/32 {
secret = clave_secreta
shortname = localhost
}

Figura 14.5: Sistema con cortafuegos + servidor Radius
/etc/freeradius/users.conf : Añadimos los usuarios a los que les vamos a permitir el acceso a la red
josan Auth-Type := Local, User-Password == "atitelovoyadecir"

Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 192.168.0.2,
Framed-IP-Netmask = 255.255.255.0,
Framed-Routing = Broadcast-Listen,
Framed-Filter-Id = "std.ppp",
Framed-MTU = 1500,
Framed-Compression = Van-Jacobsen-TCP-IP
Si no nos queremos complicar en exceso, para agregar más usuarios, solo hay que cambiar User-Password
y la IP.

14.5.2. Generar los certificados

Respecto a la generación de certificados, obviamente la idea es que los emita una entidad certificadora
contrastada, pero también nos los podemos hacer nosotros.
Para ello utilizaremos OpenSSL, si todavia no lo hemos instalado realizamos el apt:

#apt-get install openssl libssl-dev ca-certificates
Ahora tenemos dos opciones:

Aprendemos a utilizar la infraestructura PKI (bastante complicada por cierto)
Utilizamos los scripts de generación de certificados que vienen con FreeRadius y OpenSSL
Escogeremos la segunda opción, usando los scripts predefinidos, ya que, con muy pocas modificaciones
podemos crear los certificados que nos hacen falta para trabajar de forma segura con nuestro wifi.
Aquı́ nos encontramos con un problema, para generar los certificados necesitamos unos scripts que
vienen con el código fuente de freeradius, para obtenerlo:
#apt-get source freeradius, nos descargará los fuentes en el directorio actual.
En el directorio scripts encontraremos una serie de archivos entre los que se encuentran los siguientes:
CA.certs, certs.sh y xpextensions. A estos tendremos que añadir otro archivo de OpenSSL: CA.pl, un script
Perl para crear Autoridades de Certificación y cuyo path no suele estar en el $PATH del sistema.
Para buscarlo podemos ejecutar: #find / | grep ’CA.pl’, y lo copiamos donde los otros archivos.
Es preciso verificar las rutas de las ordenes de los scripts ya que puede ser que sino no funcionen bien.
En mi caso he tenido que modificar el cert.sh. En el archivo CA.certs, siguiendo el ejemplo que allı́ aparece,
colocaremos nuestros datos en las variables del inicio del fichero.
Para generar los certificados lo único que deberemos de hacer es:

#apt-get install ./certs.sh
Lo que se muestra por pantalla será algo parecido a esto:
# ./certs.sh
Generating DH parameters, 512 bit long safe prime, generator 2
This is going to take a long time
........................................................................................
.................................................+.+.........................+..........
+.........................+......................................+......................
........+.................+......+.............+........................................
...............+......+...................................+....+........................
......+......................+..++*++*++*++*++*++*
See the ’certs’ directory for the certificates.
The ’certs’ directory should be copied to .../etc/raddb/
All passwords have been set to ’whatever’
Ahora tendremos un nuevo directorio llamado ./certs y donde se encuentran todos los certificados que
nos harán falta para el cliente y el servidor.
Es recomendable colocar estos certificados en /etc/freeradius/certs, ya que los archivos de configuración
de freeradius apuntan a ese directorio y tendremos menos cosas que modificar.

14.5.3. Comprobar el funcionamiento de FreeRadius

Hay que repasar los archivos: radiusd.conf, eap.conf, clients.conf y users.conf, los ajustaremos para
que cojan los certificados que hemos generado.
radiusd.conf : Hay que revisar las rutas de los certificados, para que apunten a los directorios donde
los hemos colocado.
eap.conf : Hay que asegurarse de colocar la contraseña elegida en private key password, si no lo
hiciéramos nos pedirı́a la clave al arrancar al demonio y no podrı́a arrancarlo iniciar el sistema.
Ahora para ejecutar el servidor:
#freeradius -X, y para lanzar el demonio: /etc/init.d/freeradius start
Antes de pasar a configurar los usuarios es necesario configurar el AP, que será el cliente de nuestro
servicio de Radius. La configuración es realmente muy sencilla, yo lo tengo configurado como un router
entre dos redes la de usuarios (192.168.1.0/24) e Internet (en el gráfico la 172.16.1.253).
Revisamos el client.conf y asignamos a esa IP permisos para hacer peticiones al servidor Radius.
Aquı́ aparece otra contraseña que utilizan el AP y el FreeRadius para cifrar sus comunicaciones. En el AP
deberemos colocar la misma clave (lo podemos observar en la figura 14.6).
14.5.4. Configurar AP (Router 3Com)

El router 3Com que utilizo me permite introducir seguridad basada en WPA con soporte para un
servidor Radius, como se puede observar en la figura 14.6.
Hay que introducir la dirección IP de la máquina y el puerto de escucha del servicio Radius.
Radius Key es la clave secreta que hemos elegido en /etc/freeradius/client.conf
Figura 14.6: Router 3Com con WPA y servidor radius

14.5.5. Clientes Linux: WPA-Supplicant

Debemos asegurarnos que nuestra tarjeta wireless se puede utilizar en WPA con EAP-TLS, si en la
documentación no lo encontramos probablemente no será compatible.
Si lo soporta, necesitamos saber es como se llama la tarjeta en el sistema (en mi caso eth1):
#iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
eth1 IEEE 802.11g ESSID:"example"

Mode:Managed Frequency:2.442 GHz Access Point: 00:12:17:B8:2E:12
Bit Rate:54 Mb/s Tx-Power:25 dBm
RTS thr:2347 B Fragment thr:2346 B
Encryption key:41ED-EE53-EE7C-84BF-005D-A8F7-C10F-0CE0-9E7D-A17F-A5FD-2ECD-7FF3-6A4C-4E73-BDC5
Power Management:off
Link Quality:95/100 Signal level:-54 dBm Noise level:-256 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:1609 Invalid misc:6740 Missed beacon:0
Para tener acceso mediante los clientes Linux hay que instalar el siguiente programa:
#apt-get install wpasupplicant
Y crear el archivo de configuración (/etc/wpa supplicant.conf) para pasar el certificado al servidor

Radius:
network={ ssid="example"
proto=WPA
key_mgmt=WPA-EAP
pairwise=TKIP
group=TKIP
eap=TLS
identity="user@example.com"
ca_cert="/etc/cert/cert-srv.pem"
client_cert="/etc/cert/root.pem"
private_key="/etc/cert/root.der"
private_key_passwd="password"}
Si utilizamos clave WPA sin servidor Radius se nos ofrece la posibilidad de encriptar la clave que se
pasara por la red, esto se consigue mediante el comando:
#/usr/sbin/wpa_passphrase <ssid> <passphrase>
Después solo queda lanzar el cliente:

#wpa_supplicant -B -i <ifname> -c <config_file> -D <driver>
En mi caso, ifname es eth1, el config file lo creé en /etc/wpa supplicant.conf y el driver ipw, esto
variará dependiendo de nuestra configuración de hardware.
Si ejecutamos: #wpa_supplicant -h, veremos que soporte y para que driver ha sido compilado.
Y para comprobar si funciona correctamente la negociación de los certificados ejecutamos:

#wpa_supplicant -dd -i eth1 -c /etc/wpa_supplicant.conf -D ipw

14.5.6. Clientes Windows: WindowsXP + SP2

Como con los clientes Linux, debemos asegurarnos que nuestra tarjeta wireless se puede utilizar en
WPA con EAP-TLS.
Para instalar los certificados generados por OpenSSL (root.der y root.p12) es suficiente con hacer doble
click sobre ellos.
Instalamos el certificado de la entidad emisora: root.der
Instalamos el certificado de cliente: root.p12, nos pedira la contraseña del certificado
Para comprobar que realmente ha sido instalado, ejecutamos el siguiente comando en la consola: mmc
A través del Microsoft Manegement Console (mmc) podemos comprobar el certificado, :
Elegimos la opción “agregar”, “certificados”. Pulsando sobre él deberı́a de aparecer:
En certificados personales, el certificado de cliente
En entidades emisoras, el certificado del servidor
Ahora falta asociarlos a una conexión, vamos a ver las “conexiones de red inalámbricas disponibles”.
Pulsamos sobre “cambiar el orden de las redes preferidas”
Seleccionamos nuestra red en el listado, podremos observar que tiene el WPA activado
Apretamos al boton “propiedades”
En esta ventana, establecemos como autenticación de red “WPA” y como cifrado de datos “TKIP”
Después cambiamos a la pestaña de autenticación y establecemos como EAP “tarjeta inteligente u

otro certificado” y activamos la opción “Autenticar como equipo cuando la información del equipo
este disponible”
Solo queda pulsar sobre “propiedades” de EAP
Solo queda seleccionar las siguientes opciones y aceptar: “usar un certificado en este equipo”, “utilizar
selección simple de certificado”, “validar un certificado de servidor” y elegir el certificado cliente que
hemos instalado.
Ahora, si volvemos a la pantalla principal de selección de redes detectadas y si pulsamos sobre nuestra
red podremos observar que aparece al lado del reloj del sistema un icono que nos informa sobre el uso
del certificado. Si presionamos sobre este icono aparecerá una ventana emergente que nos avisa de que se
está validando el servidor y que presionemos “aceptar” si el certificado es correcto, una vez presionemos
ya no será necesario volver a repetir el proceso y si todo va bien podremos conectarnos de forma segura a
nuestra red.

14.6. Herramientas de seguridad

Las redes wifi son inseguras por definición, el hecho de comunicarse por un medio de libre acceso como
es el aire implica que la transmisión será vulnerable.
Si en nuestra red no permitimos estas conexiones o si queremos estar alerta sobre que hacen nuestros
clientes wifi (sean clientes autorizados o no), podremos utilizar Kismet Wireless herramienta que detallo
a continuación. También comento la herramienta de auditorı́a AirSnort que trata de descubrir la clave
WEP, si la utilizamos para el cifrado de datos.
14.6.1. Descubrir redes ilegales e intrusos: Kismet Wireless

Kismet Wireless es uno de los sniffers inalámbricos principales para Linux, pero existen otros programas
como AeroSniff o Prism2Dump. He elegido Kismet debido a su creciente oferta de módulos de soporte.
Es una herramienta cliente-servidor como Nessus (Véase apartado 17.1), que proporciona incluso más
flexibilidad.
Funciona con otros programas y puede diseñarse para recopilar claves de cifrado para los intentos
de descifrado por otros programas externos. Podemos incluso ejecutar Kismet en modo IDS para buscar
intentos de intrusión que provengan de nuestra red inalámbrica.
Instalar Kismet
Se puede obtener la versión más actualizada del programa en la dirección:
http://www.kismetwireless.net
Los pasos a seguir son los siguientes:
Instalar el programa: #apt-get install kismet
Editar y configurar el archivo: /etc/kismet/kismet.conf, aquı́ se ha de configurar el inicio de sesión

y las preferencias de la interfaz wifi (el cuadro 14.2 recoge los parámetros que se pueden configurar)
Editar y configurar el archivo: /etc/kismet/kismet ui.conf, aquı́ se han de establecer las preferencias
de la interfaz gráfica de kismet (el cuadro 14.3 recoge los parámetros que se pueden configurar)
Ya esta listo para auditar la red inalámbrica
Kismet trabajando como sniffer de red

Iniciamos Kismet desde la lı́nea de comandos. Se abre la interfaz principal y inmediatamente informa
sobre cualquier red inalámbrica en el área.
La interfaz se divide en tres secciones principales:
La sección Network List (lista de redes) que se encuentra a la izquierda muestra todas las redes
inalámbricas activas que puede ver Kismet y alguna información básica sobre ellas: el SSID de la red
(si está disponible), el tipo (punto de acceso frente a nodo), si está cifrada o no utilizando WEP, el
canal en el que se está transmitiendo, el número de paquetes interceptados hasta el momento, cual-
quier indicador sobre los datos y la cantidad de datos que están por la red. La pantalla está codificada
con colores, apareciendo en color rojo las redes activas y en negro las que no están activas.
El cuadro Info (información) que se encuentra a la derecha de la pantalla muestra las estadı́sticas
globales para esta sesión de captura (incluyendo el número total de redes detectadas, el número total
de paquetes, el número de paquetes cifrados, las redes débiles percibidas, los paquetes con un alto
nivel de ruido, los paquetes descartados y la media de paquetes por segundo.

Cuadro 14.2: Archivo de configuración de Kismet

Capture source Define las interfaces que va a escuchar Kismet. Normalmente la inter-
(Origen de captura) faz inalámbrica principal (wlan0, eth1, etc.) ya deberı́a estar configurada
aquı́. Si desea añadir interfaces adicionales puede hacerlo en el formato:
source=type, interface, name
Fuzzy encryption Muestra cualquier paquete que hayamos identificado como “sin descifrar”
(Cifrado confuso) para las estaciones que están utilizando métodos de cifrado sin definir o
propietarios. Generalmente se deja desconectado a no ser que su tarjeta
esté informando sobre redes cifradas como “sin descifrar”.
Filtering packet logs Limita el paquete que se registra. Utilice la opción noiselog para quitar
(Filtrar registros de pa- cualquier paquete que parezca que se va a desglosar o fragmentar por el
quete) ruido. En una zona muy ocupada con mucha interferencia o cuando se uti-
liza una tarjeta que tiene una antena externa, puede mantener el tamaño
de su registro reducido. La opción beaconlog quita todos los paquetes de
señales luminosas, excepto el primero, de un punto de acceso determina-
do. La configuración phylog quita cualquier paquete de la capa fı́sica que
a veces se recogen. También puede utilizar cualquier combinación de estas
configuraciones.
Decrypt WEP keys Descifra los paquetes de datos interceptados al momento. Sin embargo, pri-
(Descifrar claves WEP) mero tiene que tener la clave que a veces, se obtiene utilizando AirSnort.
Cada punto de acceso necesita una declaración independiente en el formato
bssid:key, siendo bssid la dirección MAC del punto de acceso y key la
clave para dicho punto de acceso
Using an external IDS Envı́a paquetes a un IDS externo para un análisis posterior
(Utilizar un IDS externo)
Cuadro 14.3: Configuración de la la interfaz UI de Kismet

Configuración Descripción
Columns (Columnas) Cambia lo que aparece en las columnas de la interfaz Kismet y su orden. Cam-
biamos el valor de columns o clientcolumns incluyendo lo que desea ver. Un
listado completo de columnas se encuentra disponible en las páginas del manual
de Kismet
Colors (Colores) Cambia los colores de cualquiera de los elementos que se muestran. Cambiamos
la configuración con color xxx al código de color que deseemos. Tendrémos
que jugar con esta configuración un poco hasta obtener los colores correctos.
El cuadro Status (Estado) en la parte inferior de la pantalla contiene una vista de desplazamiento
con los eventos producidos. Los mensajes se abren cuando aparecen nuevas redes o se producen otros
eventos.
Como Kismet es una herramienta de lı́nea de comandos, aunque con una GUI, utiliza comandos de
teclas para controlar sus funciones. El cuadro 14.4 incluye una lista de las teclas disponibles desde la
pantalla principal.
Soporte GPS de Kismet

Kismet tiene la capacidad de grabar datos GPS si tiene un receptor GPS conectado a la máquina.
Necesitamos el software demonio de GPS gpsd para que Kismet pueda leerlo.
Lo podemos instalar con el comando: #apt-get install gpsd
Para utilizarlo es parecido habilitar el uso de GPS en el archivo de configuración de Kismet. Después
Kismet escoge automáticamente las coordenadas de las redes detectadas y las registra.
Podemos ir un paso más allá y crear un mapa con estas coordenadas. Kismet incluye un programa

Cuadro 14.4: Comandos de tecla Kismet

Tecla Descripción
a Muestra estadı́sticas sobre cuentas de paquetes y asignaciones de canal
c Abre una ventana emergente para mostrar los clientes en la red seleccionada
d Le indica al servidor que inicie la extracción de cadenas imprimibles desde el flujo de paquetes
y que las muestre
e Abre una ventana emergenete en servidores Kismet, lo que permite supervisar simultáneamente
dos o más servidores Kismet en distintos anfitriones (hay que recordar que se trata de una
arquitectura cliente-servidor)
f Sigue el centro estimado de una red y muestra un compás
g Agrupa las redes codificadas actualmente
h Obtiene una lista de todos los comandos posibles
i Muestra información detallada sobre la red o el grupo actual
l Muestra los niveles de señal/capacidad/ruido si la tarjeta informa sobre ellos
m Silencia el sonido y la voz, si están activados (o los activa si están silenciados)
n Renombra la red o el grupo seleccionado
p Muestra los tipos de paquetes tal y como se han recibido
r Muestra un gráfico de barra del porcentaje de los paquetes
s Ordena la lista de redes de forma diferente
t Codifica (o descodifica) la red actual
u Desagrupa la red actual
w Muestra todas las alertas y avisos previos
z Amplı́a el nivel de zoom del panel de presentación de la red a pantalla completa (o vuelve a su
tamaño normal si ya estaba en pantalla completa)
denominado GPSMPA que traza automáticamente los datos recopilados en mapas en formato .gps El
inconveniente es que tiene que proporcionar su propio mapa GPS calibrado.
Existe un programa de trazado de mapas de libre distribución para Linux denominado GPSDrive, lo
podemos instalar con: #apt-get install gpsdrive.
IDS de Kismet
También podemos configurar Kismet como un IDS inalámbrico. Kismet interceptará todas las señales
entrates y detectará el tráfico inalámbrico que se sabe está asociado con los ataques a redes wifi o activi-
dades inalámbricas sospechosas.
Detecta unos 10 tipos diferentes de tráfico, incluyendo sondeos del programa NetStumbler (herramienta
para Windows), la actividad de Airjack y otras herramientas de piraterı́a inalámbrica. Y, como es de
libre distribución, siempre podemos ampliarlo mediante la escritura de nuestras propias alertas. También
podemos canalizar los datos de Kismet a través de un IDS tradicional como Snort (Véase sección 13.5)
para obtener un análisis más detallado.
La opción IDS se configura en /etc/kismet/kismet.conf y de forma predeterminada está deshabilitada.
También puede configurar Kismet para recopilar claves débiles conocidas criptográficamente para un
programa como AirSnort, que analiza paquetes inalámbricos e intenta descifrar el cifrado WEP. Pasemos
a describir el funcionamiento de este programa.
14.6.2. Desencriptar claves inalámbricas WEP: Airsnort

Si utilizamos criptografı́a por clave WEP, cosa que no recomiendo, podemos probar si nuestra clave se
puede deducir facilmente con esta herramienta. Actualmente la encriptación WPA es más segura y es una
mejor solución para servidores.
AirSnort se desarrolló como una aplicación práctica para demostrar la debilidad de WEP, el protocolo
básico de cifrado inalámbrico. Una nota sobre las debilidades en el algoritmo de programación de claves de

RC4, escrita por los expertos criptográficos Fluhrer, Martin y Shamir, incluı́a detalles sobre una teórica
debilidad en el algoritmo WEP, describiendo la debilidad de algunos vectores de inicialización. Los paquetes
cifrados con estos vectores débiles se podı́an coleccionar y al final habrı́a suficientes datos para extrapolar la
clave secreta compartida, lo que permitirı́a descifrar fácilmente los paquetes. Poco después, se lanzaron dos
herramientas, AirSnort y WEPCrack, que empleaban las debilidades descritas para recuperar claves WEP,
descifrándolas con efectividad. Ambas son buenas herramientas, pero AirSnort tiene una funcionalidad
adicional como sniffer inalámbrico.
AirSnort es ahora un proyecto de libre distribución que se encuentra en SourceForge.net y que se ha
extendido y mejorado considerablemente desde su lanzamiento.
Usos de AirSnort
¿Por qué utilizar AirSnort en una red inalámbrica? Alguien podrı́a decir que no existe un uso legı́timo
para el programa y su único propósito es el de ser una herramienta para el asalto de redes. Creo que la
única forma de saber lo expuesta que está nuestra red inalámbrica es hacer lo que harı́a un intruso para
comprobar si nuestro cifrado se puede descifrar y la cantidad de tiempo que tardarı́a en hacerlo. AirSnort
lleva a cabo precisamente esta tarea.
Al intentar descifrar el cifrado inalámbrico, podemos ver si se puede hacer. Si se está utilizando un
WEP estándar, entonces es simplemente cuestión de tiempo. Es una realidad matemática que se puede
descifrar en algún punto utilizando esta herramienta. La cuestión es cuanto tardaremos en hacerlo. Si
tardamos mucho tiempo, podemos suponer razonablemente que estamos bastante seguros. Si el nivel de
tráfico de nuestra LAN es pequeño, puede ser cuestión de dı́as o incluso de semanas, lo que sitúa a nuestra
red fuera del reino de lo práctico para la mayorı́a de los piratas informáticos casuales. Sin embargo, si es
una red ocupada, alguien podrı́a recoger los paquetes suficientes para descifra nuestro cifrado en cuestión
de horas o en un dı́a. Saber todo esto nos ayuda a proteger mejor nuestra red. Puede justificar incluir
más protecciones, como mejores controles fı́sicos o limitar el tráfico en la red. También puede justificar la
actualización de nuestro equipamiento inalámbrico, como por ejemplo a un sistema WPA con un servidor
Radius, como el que se propone en este proyecto. Una red inalámbrica que utiliza este protocolo puede
ser, actualmente (solo actualmente) indescifrable. Podemos descubrir que el nivel de tráfico no hace que
sea práctico descifrar el cifrado. De cualquier forma, dormiremos mucho mejor por la noche, si lo sabemos.
Ejecutar AirSnort
Para instalarlo solo hay que ejecutar la siguiente instrucción:
#apt-get install airsnort
Tiene tres archivos ejecutables principales:
airsnort: Recopila los paquetes desde algún origen, normalmente la tarjeta de red inalámbrica
gencases: Ordena los datos capturados en busca de claves débiles
decrypt: Realiza los intentos en desconexión de descifrado para los archivos cargados desde otro
origen
AirSnort acepta archivos de otros sniffers inalámbricos siempre que se guarden en formato PCAP. Con
el tiempo, Kismet separará especı́ficamente los paquetes interesantes para AirSnort, ahorrándonos este
paso.
No es necesario tener toda la colección de datos a la vez. AirSnort puede guardar una sesión y retomarla
posteriormente para realizar adiciones, lo que convierte a AirSnort en una herramienta particularmente
peligrosa para redes inalámbricas ya que nadie tiene que perder una sesión interrumpida cerca de nuestras
instalaciones para recopilar los paquetes suficientes como para entrar en nuestra red. Puede dividir sus
actividades de recopilación en incrementos de tiempo más pequeños y menos perceptibles, suponiendo que
la red controlada no cambie sus claves con frecuencia.
Una vez instalado AirSnort, podemos empezar escribiendo airsnort en la lı́nea de comandos. Como
puede verse en la figura 14.7, la interfaz es muy simple: es una sola pantalla que muestra los paquetes

interesantes y el número total de paquetes cifrados y sin cifrar. La sección superior muestra nuestras
configuraciones, como el tipo de tarjeta NIC, etc. A la derecha podemos cambiar algunas configuraciones
como breadth (número e intentos que tiene que realizar AirSnort por cada byte de clave) para intentos de
descifrado de 40 bits o 128 bits. El valor predeterminado es 3 para cifrados de 40 bits y 2 para cifrados de
128 bits. Si no tenemos muchos datos o tenemos mucha capacidad de procesamiento adicional, podemos
intentar aumentar este valor ligeramente, pero no más de 4 ó 5.
Figura 14.7: Imagen de AirSnort
A continuación, es el momento de sentarnos a recopilar paquetes. No hay que esperar descifrar claves
WEP en un momento. Para que AirSnot funcione correctamente, necesita aproximadamente entre 1.500 y
4.500 paquetes con claves débiles, es decir, aproximadamente entre 100MB y 500MB de datos. En una red
moderadamente ocupada, podemos tardar uno o más dı́as en recopilar esta cantidad de datos. En redes
más lentas, podemos tardar más y en redes ocupadas mucho menos. Hay que esperar, al menos, tardar un
par de horas, aunque seguramente sea más. Evidentemente, todo se basa en tener un poco de suerte, por
lo que los resultados pueden variar entre una hora y nunca.
Cuando un desciframiento de la clave WEP tiene éxito, aparece tanto en texto normal como en hexa-
decimal en la parte izquierda de la pantalla y los extremos de la sesión de captura.
¿Qué pasarı́a si encontrásemos las claves WEP? Bueno, hay que tranquilizarse, que no nos entre el
pánico ya que la mayorı́a de los intrusos casuales no se molestarán lo más mı́nimo. Sin embargo deberı́amos
pensar en tomar medidas para aumentar la seguridad de nuestra red inalámbrica para que sea más difı́cil
recopilar estos datos. Hay que seguir muchos pasos que varı́an desde reemplazar el equipamiento hasta
volver a configurar y cambiar el AP (punto de acceso). Tendremos que tomar decisiones basándonos en la
confidencialidad de los datos que tratamos en nuestra red.

Capı́tulo 15
Servicio de administración por Web:

WebMin
Para acceder a la configuración de Webmin, si no hemos cambiado los puertos por defecto:
http://127.0.0.1:10000, o http://localhost:10000 , https si usamos SSL
Webmin está dividido en diversos módulos. Cada uno de estos se encarga de la administración de una
parte concreta del sistema operativo y de los diferentes servicios que tengamos instalados.
Crea una configuración para cada uno de los módulos basándose en la estructura de ficheros y confi-
guración predeterminada para la versión y distribución de Linux seleccionadas.
Los módulos incluidos por defecto en Debian nos permiten administrar entre otros servicios Apache,
Squid, Bind, Exim, Fetchmail, Samba, MySql, etc.
Nota: Un problema que puede producirse en determinadas circunstancias es que una vez finalizada la
instalación algunos de los módulos que componen Webmin no funcionen correctamente. Esto suele ser
debido a que alguna parte del software se ha instalado en directorios que no son estándar en Linux.
15.1. Usuarios de Webmin

El usuario por defecto es el root, una vez que entramos en Webmin podemos crearnos uno o varios
usuarios de administración Webmin.
En el caso de que se nos olvide la contraseña de acceso y tengamos acceso como root al ordenador, se
puede crear una nueva utilizando el comando:
/usr/share/webmin/.changepass.pl /etc/webmin usuario nuevo_password
En el módulo usuarios de Webmin se encuentran las diferentes opciones disponibles para definir y
configurar los usuarios que tendrán acceso a Webmin. Permite al administrador del sistema crear diferentes
usuarios para determinadas tareas. Por ejemplo, si el ordenador se utiliza como servidor de correo, podemos
crear un usuario que tan sólo tenga acceso al módulo de administración de Exim, o si se emplea como
servidor de impresión crearı́amos un usuario que pudiera administrar las colas de impresión.
De esta forma es posible crear diferentes usuarios en función de los módulos a los que tendrán acceso,
delegando fácilmente la administración de determinados servicios del ordenador a diferentes usuarios y
siendo posible incluso determinar que aspectos de un determinado servicio podrá administrar.
15.2. Secciones Webmin

La sección Webmin nos da acceso a las diferentes opciones de configuración de Webmin, ası́ como a
los logs de actuaciones, el ı́ndice de servidores Webmin y los usuarios Webmin.
Desde el módulo de configuración de Webmin podemos cambiar los aspectos más importantes del
propio Webmin como instalar nuevos módulos, actualizar Webmin, cambiar el idioma, añadir, eliminar o
modificar usuarios de Webmin, cambiar el puerto utilizado, etc.
Figura 15.1: Webmin pantalla de configuración
Control de acceso a IP
Ya que Webmin tienen su propio servidor web (miniserv.pl) desde esta opción podemos seleccionar
qué direcciones de red (como 192.168.100.0), direcciones de host (como 192.168.100.7) o nombres de hosts
(linux.upc.es) es posible acceder a Webmin.
Es aconsejable limitar el acceso a Webmin al mı́nimo de ordenadores que sea posible para evitar de
esta forma intentos de acceso no autorizados.
Puerto y direcciones
En esta opción estableceremos el puerto utilizado para acceder a Webmin, por defecto 10000. En el caso
de que nuestro ordenador tenga asignada más de una dirección IP también podremos establecer qué di-
rección IP deberá atender el servidor web de Webmin, ya que por defecto el servidor aceptará peticiones
realizadas a cualquiera de las direcciones IP asignadas al sistema.
Diario
Desde aquı́ configuraremos la forma en que Webmin guardará un registro de las acciones realizadas.
De esta forma podremos monitorizar fácilmente las actuaciones realizadas por los diferentes usuarios a los
que proporcionemos acceso a Webmin.
Webmin nos permite guardar en el historial las acciones realizadas en función del módulo utilizado o
del usuario. Se permite programar cuando se limpiará el historial para evitar que el tamaño del mismo
crezca en exceso.
Servidores Proxy
Webmin dispone de diferentes herramientas que necesitan disponer de acceso a Internet para funcionar
correctamente, como es el caso de la herramienta de actualización de Webmin. Desde esta opción confi-
guraremos el acceso a Internet de Webmin en el caso de que estemos utilizando un servidor proxy o un
cortafuegos para acceder a Internet
Interfaz de usuario
El interfaz de usuario de Webmin puede ser modificado de diferentes formas para ajustarse a las
preferencias de cada uno de los usuarios.

Capı́tulo 15. Servicio de administración por Web: WebMin 281
Desde esta opción se modifican los colores y tipos de letras utilizados para visualizar las páginas de
Webmin.
Módulos de Webmin
Webmin está formado por diversos módulos. cada uno de estos módulos se encargan de realizar una
tarea determinada interrelacionada con el servidor web de Webmin (miniserv.pl).
Desde esta opción, añadiresmo, actualizaremos o eliminaremos los módulos utilizados por Webmin.
Está se encuentra dividida en tres secciones:
Instalar módulo
Clonar módulo
Borrar módulos
Instalar módulo La sección Instalar módulo permite instalar un nuevo módulo de Webmin, ya sea
desde un archivo que se encuentre en el ordenador o desde un archivo que tenga que descargarse de
Internet.
Estos módulos Webmin son archivos de extensión .wbm
Clonar un módulo Esta opción permite al administrador del sistema duplicar un módulo para permi-
tir a determinados usuarios administrar ciertos servicios. Ası́, por ejemplo, si tenemos dos configuraciones
diferentes de Apache ejecutándose en el ordenador, con esta opción duplicaremos el módulo de administra-
ción de Apache para permitir a diferentes usuarios acceder de forma independiente a la versión de Apache
que sea necesario.
Eliminar módulos Desde esta última sección, seleccionaremos y borraremos aquellos módulos que no
nos sean de interés o no se vayan a utilizar. Ası́, por ejemplo, si no tenemos instalado en nuestro ordenador
PostgreSQL podemos eliminar el módulo utilizando para su administración.
Sistema operativo
Desde esta opción podremos especificar cual es nuestro sistema operativo. Este proceso deberá realizarse
si, por ejemplo, hemos actualizado el sistema operativo instalando una versión nueva, la cual modifica la
estructura de directorios en los que se guardaba la configuración de los diferentes servicios del sistema.
Lenguaje
Se emplea para seleccionar el idioma utilizado para visualizar los textos en los módulos.
Opciones de página ı́ndice

En esta opción seleccionaremos el formato de la página inicial de Webmin y de las diferentes páginas
ı́ndice de cada una de las categorı́as existentes, indicando el número de iconos a visualizar en cada fila.
También podemos indicar si queremos agrupar los módulos en función de la categorı́a a la cual perte-
necen.
Mejorar Webmin
Desde esta página es posible actualizar Webmin a la última versión disponible de forma automática o
desde un archivo que hayamos descargado de Internet.
Utiliza un gestor de paquetes para realizar la tarea, en nuestro caso apt.

Autenticación
Webmin proporciona algunas caracterı́sticas orientadas a prevenir ataques como puede ser el intentar
averiguar la contraseña de administración a base de probar diferentes contraseñas de forma automática
hasta encontrar la correcta.
En el caso de que nuestro ordenador y Webmin sean accesibles desde Internet es recomendable utilizar
las caracterı́sticas de autenticación proporcionadas por Webmin para proteger nuestro sistema de posibles
ataques.
La primera opción que encontramos en la ficha es Tiempo máximo de clave de acceso. Si activamos
esta opción, se bloqueará el acceso al ordenador si se producen una serie de fallos en unos segundos
determinados, esto indicará que alguien está ejecutando una aplicación automática para descubrir
nuestra contraseña.
La Autenticación de sesión nos proporciona un método para desconectar un usuario de Webmin si

transcurre un determinado tiempo sin que éste realice alguna operación.
También podemos especificar si permitimos el acceso a Webmin empleando las cuentas de usuario
del sistema en lugar de emplear las cuentas de usuario definidas desde Webmin. Hay que tener
mucho cuidado con esta opción, cualquier usuario que tenga acceso al sistema, sea administrador o
no, podrá trabajar con Webmin.
Reasignando módulos
Como ya se ha comentado Webmin agrupa los módulos instalados en diferentes categorı́as. Estas
categorı́as están definidas en función de la tarea que realiza el módulo. Desde estas opción Webmin nos
permite asignar un módulo a una nueva categorı́a en el caso de que no estemos de acuerdo con la categorı́a
asignada por defecto.
Algunos módulos desarrollados antes de que se crearan las categorı́as en Webmin se asignan por defecto
a la categorı́a Otros.
Editar categorı́as
Utilizaremos esta opción para crear nuevas categorı́as o editar las existentes.
Temas de Webmin
En estas sección se puede modificar el aspecto y los colores de Webmin, utilizando temas.
Los temas de Webmin son muy flexibles, permitiendo al desarrollador modificar prácticamente cualquier
aspecto de la apariencia y distribución de los elementos de Webmin.
Referenciadores de confianza
Al estar basado en archivos web y accederse a él desde un navegador web, uno de los peligros con los
que podemos encontrarnos es el hecho de que la información de autenticación se guarda en el navegador
y puede ser reenviada de forma automática desde él. Esto puede causar que otro usuario que emplee el
mismo navegador tenga acceso a nuestro sistema sin conocer tan si quiera la contraseña o nombre de
usuario de Webmin.
En esta sección podremos indicar que hosts tienen acceso a Webmin, limitando de esta forma desde
qué ordenadores se podrá utilizar.
Acceso anónimo a módulo

Esta sección permite garantizar acceso a módulos selectos de Webmin y a trayectorias sin necesidad
de que los clientes hagan login.

Bloqueo de archivo
Permite bloquear un archivo para que no sea modificado por varios usuarios al mismo tiempo y esto
pueda producir incoherencias en el sistema.
Encriptación SSL
Si tenemos instaladas en nuestro ordenador las librerı́as OpenSSL y el módulo de Perl Net::SSLeay
podremos emplear conexiones encriptadas con SSL para acceder a Webmin. Para acceder a Webmin
utilizaremos una conexión segura, de la forma:
https://127.0.0.1:10000, ó https://localhost:10000
Ası́ incrementaremos la seguridad de Webmin, ya que la información, como por ejemplo el nombre de
usuario y contraseña, se enviará de forma encriptada.
Aunque se instala OpenSSL por defecto en la mayorı́a de distribuciones de Linux actuales, es posible
que no tenga instalado Net::SSLeay.
Para instalar OpenSSL y Net::SSLeay deberemos instalar los siguientes paquetes:

#apt-get install openssl
#apt-get install libnet-ssleay-perl
Autoridad de certificado
Esta opción se emplea para configurar un certificado SSL para el sistema. De esta forma es posible
configurar Webmin para que no sea necesario proporcionar un usuario y contraseña para utilizarlo. Los
usuarios pueden solicitar un certificado personal en el módulo de usuarios de Webmin y agregarlo al
navegador, de esta forma el navegador podrá autenticarse de forma automática y segura.
El problema que puede surgir al utilizar este método de autenticación es que cualquier usuario con
acceso a un navegador que contenga un certificado válido para acceder a Webmin podrá utilizar las
herramientas de administración. Este método también inválida polı́ticas de seguridad como la desconexión
del usuario después de un determinado periodo de inactividad, ya que simplemente volviendo a abrir el
navegador podrı́amos acceder.
15.3. Módulos de Webmin

Existen diversos módulos, que podemos instalar con apt y que permiten configurar de forma rápida
y gráfica muchas partes del sistema. En la tabla 15.1 podemos observar algunos, solo he colocado los
módulos más útiles. La mayorı́a de ellos han sido utilizados durante la elaboración del proyecto.
Podemos buscar más módulos Webmin dentro del sistema Debian con apt-cache:
#apt-cache search webmin
Otra fuente de módulos para Webmin la encontraremos en la página:

http://webadminmodules.sourceforge.net/
Aquı́ hallaremos una gran cantidad de módulos agrupados por categorı́as.
Para instalar los módulos, simplemente realizaremos un apt:

#apt-get install <m\’odulo>

En la siguiente tabla se muestran la mayoria de los módulos disponibles en nuestro sistema Debian:
Cuadro 15.1: Módulos Debian para Webmin
Tipo de operación Módulo Función

Gestión del servidor webmin-virtual-server Administración remota
webmin-lilo Gestor de arranque Lilo
webmin-grub Gestor de arranque Grub
webmin-status Estado del servidor
webmin-fsdump Copias de seguridad
webmin-inetd Superservidor
webmin-filemanager Archivos
Gestión de paquetes webmin-software Paquetes instalados
webmin-pserver Versiones concurrentes
webmin-core Módulos core
Gestión de la red webmin-adsl Cliente PPPoE
webmin-bandwidth Monitor de red
webmin-dhcp DHCP
webmin-bind BIND DNS
webmin-nis NIS
webmin-exports NFS
webmin-samba Samba
Servicios de red webmin-proftpd ProFTPD
webmin-updown FTP
webmin-telnet Telnet
webmin-ldap-user-simple LDAP usuario
webmin-ldap-netgroups LDAP redes
webmin-mysql MySql
Gestión de usuarios webmin-usermin Usuarios
webmin-quota Cuotas de disco
webmin-lpadmin Cuotas de impresión
Servicios de usuario webmin-apache Apache
webmin-webalizer Estadı́sticas web
webmin-exim Correo corporativo Exim
webmin-fechmail Correo externo Fechmail
webmin-procmail Procesador de correo Procmail
webmin-spamassassin Filtro SpamAssassin
webmin-jabber Mensajerı́a Jabber
Gestión de seguridad webmin-sshd SSH
webmin-firewall IPTables
webmin-squid Squid
webmin-snort IDS Snort
webmin-portsentry IDS puertos
webmin-logrotate IDS logs

Una vez instalados todos los módulos necesarios para el proyecto pasemos a ver graficamente las sec-
ciones de nuestro servidor.
Figura 15.2: Pantallas de la interfaz Webmin (I)

Figura 15.3: Pantallas de la interfaz Webmin (II)

Capı́tulo 16
Servicios de monitorización del

sistema
Para tener bajo control el sistema, es muy importante tener información esencial de su rendimiento:
procesos en ejecución, cantidad de memoria disponible, n.o de particiones, etc.
16.1. Monitor del sistema: Top

Proporciona una visión continuada de la actividad del procesador en tiempo real, muestra las tareas
que más uso hacen de la CPU, y tiene una interfaz interactiva para manipular procesos.
Las cinco primeras lı́neas muestran información general del sistema:
Las estadı́sticas del comando uptime
Estadı́sticas sobre los procesos del sistema (número de procesos, procesos durmiendo, procesos eje-
cutándose, procesos zombies y procesos parados).
El estado actual de la CPU (porcentaje en uso por usuarios, por el sistema, por procesos con valor nice
positivo, por procesos esperando E/S, tratando interrupciones hardware y software o desocupada).
La memoria (memoria total disponible, usada, libre, compartida, usada como buffer de E/S y en
caché, cantidad total de buffer o memoria caché de página, en kilobytes, que está en uso activo,
cantidad total de buffer páginas de la caché que podrı́an quedar libres, cantidad total de buffer o
páginas de la caché que están libres y disponibles.)
El espacio de swap (swap total disponible, usada y libre).
El resto es similar al del ps, con los procesos ordenados decrecientemente por el uso de la CPU.
La lista es actualizada de forma interactiva, y además se permite realizar una serie de tareas sobre los
procesos, como por ejemplo:
Cambiar la prioridad de alguno utilizando el comando “r”.
Matar o enviar una señal con el comando “k”.
Ordenarlos según diferentes criterios (por PID con “N”, uso de CPU con “P”, tiempo con “A”, etc.).
Con “n” se cambia el número de procesos que se muestran.
Para salir se utiliza la letra “q”.

Resulta muy recomendable siempre tener top funcionando en uno de los terminales, para poder ver de
forma rápida si hay cargas excesivas en el sistema.
En el siguiente ejemplo podemos observar lo que se verı́a habitualmente:

$top
top - 15:52:23 up 3:39, 4 users, load average: 0.46, 0.22, 0.29
Tasks: 96 total, 1 running, 95 sleeping, 0 stopped, 0 zombie
Cpu(s): 13.9% us, 2.6% sy, 0.0% ni, 83.5% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 511948k total, 491884k used, 20064k free, 63432k buffers
Swap: 979924k total, 0k used, 979924k free, 250764k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

4359 root 6 -10 107m 39m 5672 S 9.9 7.9 11:00.41 XFree86
4479 josan 15 0 22700 13m 9656 S 1.3 2.7 0:06.16 gnome-panel
4501 josan 15 0 18992 9.9m 7920 S 1.3 2.0 0:08.43 wnck-applet
4918 josan 15 0 30828 12m 8624 S 1.3 2.6 0:20.18 gnome-terminal
10072 josan 16 0 2132 1064 832 R 1.0 0.2 0:00.16 top
4642 josan 15 0 56140 33m 19m S 0.7 6.6 8:53.77 kile
4475 josan 16 0 12556 7396 6176 S 0.3 1.4 0:08.92 metacity
4503 josan 15 0 17160 8376 6884 S 0.3 1.6 0:10.62 multiload-apple
4512 josan 15 0 18568 8576 7012 S 0.3 1.7 0:33.27 clock-applet
1 root 16 0 1584 512 452 S 0.0 0.1 0:01.07 init
2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
3 root 10 -5 0 0 0 S 0.0 0.0 0:00.85 events/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
9 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
18 root 10 -5 0 0 0 S 0.0 0.0 0:01.90 kacpid
111 root 10 -5 0 0 0 S 0.0 0.0 0:00.04 kblockd/0
125 root 16 0 0 0 0 S 0.0 0.0 0:00.24 khubd
246 root 15 0 0 0 0 S 0.0 0.0 0:00.55 pdflush
247 root 15 0 0 0 0 S 0.0 0.0 0:02.41 pdflush
249 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
248 root 25 0 0 0 0 S 0.0 0.0 0:00.00 kswapd0
256 root 15 0 0 0 0 S 0.0 0.0 0:00.00 cifsoplockd
257 root 25 0 0 0 0 S 0.0 0.0 0:00.00 jfsIO
258 root 25 0 0 0 0 S 0.0 0.0 0:00.00 jfsCommit
259 root 25 0 0 0 0 S 0.0 0.0 0:00.00 jfsSync
260 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 xfslogd/0
261 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 xfsdatad/0
262 root 15 0 0 0 0 S 0.0 0.0 0:00.00 xfsbufd
881 root 17 0 0 0 0 S 0.0 0.0 0:00.00 kseriod
1104 root 15 0 0 0 0 S 0.0 0.0 0:00.00 khpsbpkt
1114 root 15 0 0 0 0 S 0.0 0.0 0:00.00 knodemgrd_0
1117 root 15 0 0 0 0 S 0.0 0.0 0:00.00 pccardd
...
16.2. Rendimiento del sistema

Al determinar el rendimiento del sistema se debe:
1. Definir el problema con todo el detalle que sea posible.
2. Determinar la causa o causas del problema.

3. Formular explı́citamente los objetivos para mejorar el rendimiento del sistema.
4. Diseñar e implementar las modificaciones al sistema y/o programas de aplicación diseñados para
llevar a cabo esos.
5. Monitorizar el sistema para determinar si los cambios realizados han sido efectivos.
6. Ir de nuevo al primer paso y volver a empezar, habrá un nuevo problema a resolver.
16.2.1. CPU, dispositivos y particiones de E/S: iostat

Para instalarlo hay que ejecutar el siguiente comando:
# apt-get install sysstat
Presenta estadı́sticas sobre la CPU y los dispositivos y particiones de E/S. Para ejecutarlo:
$iostat

Capı́tulo 16. Servicios de monitorización del sistema 289
Y un ejemplo del comando serı́a:
# iostat
Linux 2.6.11 (debian) 26/05/05
cpu-med: %user %nice %sys %iowait %idle

12,55 0,10 1,85 1,82 83,68
Device: tps Blq_leid/s Blq_escr/s Blq_leid Blq_escr

hda 2,12 35,58 14,16 581224 231256
hdc 0,01 0,08 0,00 1384 0
Donde el significado de las columnas es el siguiente:
tps: n.o de transferencias por segundo
Blq leid/s: n.o de bloques leı́dos por segundo
Blq escr/s: n.o de bloques escritos por segundo
Blq leid: n.o total de bloques leı́dos
Blq escr: n.o total de bloques escritos
16.2.2. Memoria: free

Se utiliza para obtener información sobre el estado de la memoria, (el significado de los campos es
mismo que en top).
Este podrı́a ser un ejemplo de su uso:
# free
total used free shared buffers cached
Mem: 511948 472644 39304 0 63548 230704
-/+ buffers/cache: 178392 333556
Swap: 979924 0 979924
16.2.3. Memoria virtual: vmstat

Si queremos obtener información sobre la memoria virtual utilizaremos este comando.
Esto podrı́a ser una salida tı́pica:
# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 38528 63620 230752 0 0 17 7 1063 255 12 2 84 2
En la siguiente tabla muestro el significado de las columnas:
r: número de procesos esperando su tiempo de ejecución.
b: número de procesos en espera
w: número de procesos en espacio de intercambio
us: tiempo de usuario como porcentaje del tiempo total

sy: tiempo de sistema como porcentaje del tiempo total

id: tiempo de inactividad como porcentaje de tiempo total
Si ejecutamos con la opción: $vmstat 2, refresca cada segundo.
16.2.4. Disco: df, du

Para poder observar estadı́sticas del disco utilizaremos estos comandos:
df: por cada sistema de ficheros informa de su capacidad, del espacio libre, del espacio usado y del
punto de montaje
du: cantidad de espacio utilizado por un directorio, y todos los subdirectorios que hayan en él.
Esto es la salida de mi sistema para el comando df:
# df
S.ficheros Bloques de 1K Usado Dispon Uso% Montado en
/dev/hda4 1921188 127236 1696360 7% /
tmpfs 255972 8 255964 1% /dev/shm
/dev/hda5 1921156 22344 1801220 2% /boot
/dev/hda7 1921156 324 1823240 1% /tmp
/dev/hda8 964500 505948 409556 56% /var
/dev/hda9 3842376 3656336 0 100% /usr
/dev/hda10 2284880 150528 2018284 7% /home
/dev/hda11 31246392 29145696 2100696 94% /mnt/ntfs
none 5120 3216 1904 63% /dev
Se puede ver que el disco tiene un grave problema en /usr, ya que está en uso al 100 %. Hay que liberar
espacio para que el sistema funcione correctamente.
Con el comando #du -sh, se muestra el espacio usado por los archivos y directorios del directorio
actual.
16.2.5. Usuarios y sus procesos: w

Sirve para determinar que usuarios están conectados y qué están haciendo.
El siguiente ejemplo ilustra el comando:

# w
17:07:08 up 4:54, 2 users, load average: 0,31, 0,22, 0,26
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
josan :0 - 12:18 ?xdm? 36:34 1.54s x-session-manag
josan pts/4 :0.0 15:53 1.00s 0.11s 25.63s gnome-terminal
Las columnas que aparecen significan lo siguiente:

JCPU: tiempo usado por todos los procesos asociados a ese terminal (incluye los procesos en segundo
plano actuales, pero no los pasados)
PCPU: tiempo de CPU usado por el proceso actual
16.3. Gestionar procesos

Para poder observar y modificar el funcionamiento de nuestros procesos disponemos de las siguientes
herramientas:

16.3.1. Visualizar procesos: ps

El comando ps, abreviatura de proceso, nos enseña todos los procesos que se están ejecutando en un
sistema, algo que puede ser muy útil para determinar si existe algún proceso ejecutándose en segundo
plano que no deberı́a estar ejecutándose.
En la tabla 16.1 podemos observar una lista de las opciones del comando:
Cuadro 16.1: Opciones del comando ps
A Muestra los procesos de todos los usuarios
a Muestra los procesos de los usuarios para todos los procesos con tty (terminal)
u Muestra el nombre del usuario del proceso
x Muestra los procesos con control de tty
-u<user> Muestra los procesos del usuario
A continuación muestro las opciones mas comunes:

$ps
$ps aux
$ps al
$ps -u<user>
La información se encuentra subdividida en las siguientes columnas:

USER: usuario que lanzó el programa
PID: Identificador del proceso

PPID: Identificador del proceso padre
%CPU: Porcentaje entre el tiempo usado realmente y el tiempo que lleva en ejecución.
%MEM: Fracción de memoria consumida (es un porcentaje estimado)
SIZE: Tamaño virtual del proceso: código + datos + pila
RSS: Memoria real usada

STAT: Estado del proceso
R: en ejecución
S: durmiendo
I: esperando
T: parado
D: esperando una E/S
W: no tiene páginas residentes
N: prioridad >
<: prioridad < 0
Si se observa algún servicio misterioso ejecutándose, hay que investigar un poco más.

Un ejemplo de esto serı́a:

$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 1584 472 ? S 11:50 0:01 init [2]
root 2 0.0 0.0 0 0 ? SN 11:50 0:00 [ksoftirqd/0]
root 3 0.0 0.0 0 0 ? S< 11:50 0:01 [events/0]
root 4 0.0 0.0 0 0 ? S< 11:50 0:00 [khelper]
root 9 0.0 0.0 0 0 ? S< 11:50 0:00 [kthread]
root 18 0.0 0.0 0 0 ? S< 11:50 0:06 [kacpid]
root 111 0.0 0.0 0 0 ? S< 11:50 0:00 [kblockd/0]
root 125 0.0 0.0 0 0 ? S 11:50 0:00 [khubd]
root 277 0.0 0.0 0 0 ? S< 11:50 0:00 [aio/0]
root 276 0.0 0.0 0 0 ? S 11:50 0:02 [kswapd0]
root 284 0.0 0.0 0 0 ? S 11:50 0:00 [cifsoplockd]
root 285 0.0 0.0 0 0 ? S 11:50 0:00 [jfsIO]
root 286 0.0 0.0 0 0 ? S 11:50 0:00 [jfsCommit]
root 287 0.0 0.0 0 0 ? S 11:50 0:00 [jfsSync]
root 288 0.0 0.0 0 0 ? S< 11:50 0:00 [xfslogd/0]
root 289 0.0 0.0 0 0 ? S< 11:50 0:00 [xfsdatad/0]
root 290 0.0 0.0 0 0 ? S 11:50 0:00 [xfsbufd]
root 352 0.0 0.0 0 0 ? S 11:50 0:00 [shpchpd_event]
root 951 0.0 0.0 0 0 ? S 11:50 0:00 [kseriod]
root 1175 0.0 0.0 0 0 ? S 11:50 0:00 [khpsbpkt]
root 1185 0.0 0.0 0 0 ? S 11:50 0:00 [knodemgrd_0]
root 1188 0.0 0.0 0 0 ? S 11:50 0:00 [pccardd]
root 1241 0.0 0.0 0 0 ? S< 11:50 0:00 [exec-osm/0]
root 1259 0.0 0.0 0 0 ? S 11:50 0:00 [pktgen/0]
root 1343 0.0 0.0 1572 392 ? S<s 11:50 0:00 udevd
root 2990 0.0 0.0 0 0 ? S 11:51 0:03 [kjournald]
root 2991 0.0 0.0 0 0 ? S 11:51 0:00 [kjournald]
root 2992 0.0 0.0 0 0 ? S 11:51 0:02 [kjournald]
root 3924 0.0 0.1 2876 520 ? Ss 11:51 0:00 dhclient3 -pf /var/run/dhclient.eth0.pid -lf /var/run/dhdaemon
root 4189 0.0 0.1 2328 656 ? Ss 11:51 0:00 /sbin/syslogd
root 4192 0.0 0.0 3128 488 ? Ss 11:51 0:00 /sbin/klogd
root 4221 0.0 0.1 1580 612 ? Ss 11:51 0:00 /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.soroot
message 4250 0.0 0.1 2160 880 ? Ss 11:51 0:00 /usr/bin/dbus-daemon-1 --system
hal 4255 0.1 0.6 8136 3236 ? Ss 11:51 0:34 /usr/sbin/hald --drop-privileges
root 4265 0.0 0.0 2316 508 ? Ss 11:51 0:00 /usr/sbin/inetd
root 4386 0.0 0.0 1600 484 ? Ss 11:51 0:00 /sbin/cardmgr
root 4390 0.0 0.0 1572 456 ? SNs 11:51 0:02 /usr/sbin/powernowd -q
root 4399 0.0 0.1 3544 660 ? Ss 11:51 0:00 /usr/sbin/sshd
root 4423 0.0 0.2 4820 1148 ? Ss 11:51 0:00 /usr/bin/X11/xfs -daemon
root 4532 0.0 0.2 2816 1028 ? S 11:51 0:00 /bin/bash /etc/rc2.d/S20xprint start
root 4533 0.0 0.2 2816 1028 ? S 11:51 0:00 /bin/bash /etc/rc2.d/S20xprint start
root 4534 0.0 0.1 11788 536 ? S 11:51 0:00 /usr/bin/Xprt -ac -pn -nolisten tcp -audit 4 -fp /usr/X1root
josan 4553 0.0 0.3 3440 1908 ? Ss 11:51 0:30 /usr/sbin/famd -T 0
root 4567 0.0 0.1 2448 608 ? Ss 11:51 0:00 /sbin/rpc.statd
root 4677 0.0 0.3 9184 1684 ? Ss 11:51 0:00 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/daemon
root 4694 0.0 0.1 1820 744 ? Ss 11:51 0:00 /usr/sbin/cron
root 4699 0.0 0.3 9476 1772 ? Ss 11:51 0:00 /usr/bin/gdm
root 4701 0.0 0.4 10032 2164 ? S 11:51 0:00 /usr/bin/gdm
root 4749 0.0 0.0 1580 416 tty1 Ss+ 11:51 0:00 /sbin/getty 38400 tty1
root 4819 7.5 43.4 238624 222152 ? S< 11:51 41:44 /usr/X11R6/bin/X :0 -audit 0 -auth /var/lib/gdm/:0.Xauthjosan
josan 5133 0.0 0.0 3072 428 ? Ss 12:01 0:00 /usr/bin/ssh-agent x-session-manager
josan 5135 0.0 1.1 10068 5812 ? S 12:01 0:01 /usr/lib/gconf2/gconfd-2 5
josan 5140 0.0 0.1 2328 772 ? S 12:01 0:00 /usr/bin/gnome-keyring-daemon
josan 5142 0.0 0.4 5620 2240 ? Ss 12:01 0:00 /usr/lib/bonobo-activation/bonobo-activation-server --acjosan
josan 5169 0.0 0.4 9060 2196 ? Ss 12:01 0:04 gnome-smproxy --sm-config-prefix /.gnome-smproxy-ghqj5S/josan
josan 5182 0.0 1.1 16628 6052 ? Ss 12:01 0:01 gnome-volume-manager --sm-config-prefix /gnome-volume-majosan
josan 5206 0.0 1.9 18972 9720 ? S 12:01 0:16 /usr/lib/gnome-panel/wnck-applet --oaf-activate-iid=OAFIjosan
root 8911 0.0 0.0 0 0 ? S 14:20 0:03 [pdflush]
josan 10637 0.0 1.8 22600 9304 ? Ss 15:07 0:00 kdeinit Running...
josan 10640 0.0 1.7 22296 8796 ? S 15:07 0:00 dcopserver [kdeinit] dcopserver --nosid --suicide
josan 10642 0.0 1.9 24068 9896 ? S 15:07 0:00 klauncher [kdeinit] klauncher
josan 10644 0.0 2.5 26808 13056 ? S 15:07 0:01 kded [kdeinit] kded
josan 10738 0.0 2.9 31816 14972 ? S 15:07 0:08 knotify [kdeinit] knotify
josan 13198 0.0 2.6 26084 13540 ? S 16:43 0:02 kio_uiserver [kdeinit] kio_uiserver
josan 14623 1.9 13.4 83728 68852 ? S 17:33 4:05 /usr/bin/kile
josan 14624 0.0 0.3 3280 1640 pts/0 Ss+ 17:33 0:00 /bin/bash
josan 17531 0.0 1.9 24276 10036 ? S 19:23 0:00 kio_file [kdeinit] kio_file file /tmp/ksocket-josanGrQ9Wjosan
josan 20028 0.0 0.1 2276 664 ? S 21:03 0:00 gnome-pty-helper
josan 20029 0.0 0.3 3284 1644 pts/1 Ss 21:03 0:00 bash
josan 20042 0.0 0.1 2564 844 pts/1 R+ 21:04 0:00 ps aux
16.3.2. Enviar signals a procesos: kill

En ocasiones es necesario enviar señales a los procesos: pararlos (SIGSTOP -19), eliminarlos, que con-
tinúen (SIGCONT -18), etc.
kill [-signal] pids:

#kill [-signal] pid, . . . envı́a una señal al proceso identificado por pid.
#kill pid, . . . se el dice al proceso que termine, de forma controlada, el estado en que termino puede
ser capturado. Esta instrucción le envı́a un SIGTERM (signal 15).
La señal SIGKILL (signal 9), no puede ser capturada y fuerza al proceso a finalizar.
#kill [-signal] orden, . . . envı́a la señal a todos los procesos “orden” (ejemplo: #killall -9 bash).

Hay procesos que no mueren a pesar de recibir la señal KILL:
Procesos zombies
Procesos que esperan un recurso vı́a NFS que no está disponible
Procesos que esperan una petición de E/S realizada a un dispositivo
16.3.3. Modificar prioridades: nice

El número nice marca la prioridad del proceso.
Linux realiza una planificación por prioridades dinámicas
Al lanzar un proceso se le asigna un valor de prioridad (número nice), por defecto la hereda del
proceso padre.
La prioridad dinámica del proceso se calcula en función del número nice, junto con el consumo de
CPU realizado
Valores bajos (negativos), implica más prioridad
Valores altos (positivos), menos prioridad
Rango de prioridad: -20(máxima) a 20 (mı́nima)
Valor especial: -19, sólo se le da la CPU cuando nadie más la quiere
Asignar un valor negativo o que disminuya (mejore) la prioridad del proceso sólo puede hacerlo el
root, aumentar (disminuir prioridad) también lo puede hacer el usuario que lo ejecuto
nice -incremento orden a ejecutar
renice nueva prioridad pid
16.4. Terminal de root con prioridad máxima

Para establecer un programa de máxima prioridad solamente es necesario subir la prioridad a uno de
nuestros terminales. Para no confundirnos es recomendable utilizar siempre el mismo terminal. El ejemplo
se muestra con el terminal 5.
Hacemos un ps: #ps -uroot
Identificamos el número de proceso (PID) que tiene el tty5
Aumentamos la prioridad de ese terminal: #renice -20 [pid_tty5]
Si el sistema se ralentiza pasamos al terminal 5, CTRL+ALT+F5 y desde ahı́ podemos comprobar

que esta pasando y solucionar el problema.
16.5. Programación de tareas

Una posibilidad deseable en cualquier sistema operativo es la de poder ejecutar algunos procesos de
forma periódica o en un momento determinado del dı́a, la semana o el mes. En Linux hay múltiples y
variadas formas tanto para los usuarios como para el sistema de crear tareas a ejecutarse en el futuro o de
forma periódica. Las tareas o trabajos no son más que uno o varios comandos que se ejecutan utilizando
un shell como intérprete.

16.5.1. At
Para un usuario definir una tarea o trabajo a ejecutarse en un momento determinado puede utilizar el
comando at. Este ofrece numerosas posibilidades.
Los comandos que componen el trabajo por defecto se toman de la entrada estándar una vez invocado
el comando, o de un fichero utilizando la opción -f, el camino a este fichero debe estar especificado a partir
del directorio home del usuario. Se pueden utilizar varias colas para colocar las tareas. Estas se nombran
con todas las letras del alfabeto y tienen prioridad mayor los trabajos en las colas con “letras mayores”.
Para ver todas las tareas de tipo at se utiliza el comando atq y para cancelar alguna, atrm.
La salida estándar y de errores de estas tareas se envı́a a través del correo local al usuario correspon-
diente a menos que este las redireccione utilizando los operadores correspondientes. El administrador del
sistema puede especificar cuales usuarios pueden o no utilizar at en los ficheros /etc/at.allow y /etc/at.deny.
A continuación vemos unos ejemplos del uso de at:

$ at 4:45pm # crea una tarea para ejecutarse a las 4:45 PM que imprime
at> echo "hora de irse" # mensaje en la salida estndar, se enviar por correo
Ctrl-d #sale del modo insertar tareas
$at -f save_all.sh 5:00PM tomorrow # ejecutara save_all.sh, 5:00PM
$at -q Z -f script.sh 3:00am + 5 days # trabajo en la cola Z y ejecutado 3AM en 5 dias
$at -f bin/my_job -m midnight Sep 24 # lanza medianoche, 24 de sep, manda correo
#atq
1 2000-11-24 10:35 b pepe
2 2000-11-23 00:00 c pepe
5 2000-11-26 01:00 Z root
#at -c 2 # muestra el contenido de tarea 2
También existe el comando batch que es similar a at solo que los trabajos batch se ejecutan cuando
la carga del procesador lo permita, o sea tenga un valor inferior a 0.8 por defecto. Este valor puede
modificarse cuando se levanta el servicio atd que es el que se encarga de manipular estas tareas.
16.5.2. Cron
Existe otro tipo de tareas que se pueden ejecutar periódicamente conocidas como crons. Para definirlas
se emplea un fichero por usuario cuyo formato se explica a continuación.
Básicamente para cada tarea periódica se escribe una lı́nea donde se especifican los momentos en que
se ejecutará y el comando correspondiente. También se pueden realizar asignaciones a variables de entorno
que serán vlidas sólo para los procesos indicados en lo sucesivo mientras no aparezcan nuevas asignaciones.
Las fechas se especifican utilizando cinco indicadores separados por espacios:
1. Minutos: Oscila entre 0 y 59

2. Horas: Oscila entre 0 y 23
3. Dı́as del mes: Oscila entre 1 y 31
4. Meses: Oscila entre 1 y 12 (se pueden poner también las tres primeras letras del nombre del mes en
inglés)
5. Dı́as de la semana: Oscila entre 0 y 7 (0 y 7 corresponden al domingo, también se pueden usar las
tres primeras letras del nombre del dı́a en inglés)

Si no se coloca alguno de los cinco indicadores se pone el carácter “*” en su lugar. Para separar indi-
cadores de un mismo tipo se utiliza la coma; para indicar rangos, el signo “-”; y para variar el incremento
del rango a n se puede colocar /n después del rango.
A continuación muestro ejemplos de este sistema:

PATH = /bin:/usr/bin:/sbin/:/usr/sbin:~/programas/bin
10 4 * * 0 backup every_thing
0 5 1,5,10,15,20,25,30 * * backup part_one
FILE = ~/docs/partners.txt
INFORM = ~/docs/inform.ps
0 7 * 1-6,9-12 mon sendmails
TARGET = ~/especial/target.img
0 8 31 12 * sendmother
MAILTO = josan
0 8-16/2 4,19 * * echo "cobraste josan?"
Los ficheros de tareas periódicas o crons de los usuarios se guardan en el directorio del sistema
/var/spool/cron/ cada uno con el login del usuario correspondiente como nombre.
Para evitar algunos errores en la sintaxis de estos ficheros no se editan directamente por los usuarios,
sino que se utiliza el comando crontab. Este permite editar, listar y borrar los crons.
Opciones del crontab:

-e: permite editar el fichero de crons. La variable de entorno EDITOR indicará el editor con que se
modificará el fichero de crons
-l: lista todos los crons del usuario
-r: borra todos los crons
A continuación, podemos observar algunos ejemplos del uso de crontab:
$ export EDITOR=vim; crontab -e # editor por defecto vim
$ export VISUAL=kwrite; crontab -e # editor visual kwrite
$ crontab -l
$ crontab -r
El siguiente código presenta el contenido del archivo /etc/crontab de mi servidor:
# cat /etc/crontab
# /etc/crontab: system-wide crontab

# Unlike any other crontab you don’t have to run the ‘crontab’
# command to install the new version when you edit this file.
# This file also has a username field, that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command

17 * * * * root run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
47 6 * * 7 root test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly
52 6 1 * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly
El demonio que se encarga de que se ejecuten las instrucciones es crond.

16.5.3. Tareas periódicas

Un sistema Linux trae algunas tareas periódicas definidas por defecto y es posible a su vez crear otras.
En este caso se emplea un fichero con formato similar al de los usuarios, que se almacena en /etc/crontab,
con la diferencia de que este sı́ se edita directamente además de que se puede especificar el usuario con
cuyos privilegios se ejecuta el proceso.
Las tareas del sistema se organizan en cuatro grupos: tareas que se ejecutan cada una hora, tareas
diarias, tareas semanales y tareas mensuales.
A cada uno de estos grupos le corresponde un directorio:

/etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ y /etc/cron.monthly/ respectivamente.
En cada directorio se colocan los programas o comandos a ejecutarse periódicamente de acuerdo al

perı́odo correspondiente.
Algunas de las tareas que se hacen de forma periódica por el sistema, son la actualización de las bases
de datos sobre las que trabajan los comandos locate y whatis, ası́ como la rotación de las trazas del sistema.
Esto puede utilizarse, por ejemplo, para descargar las bases de datos de los antivirus para Windows y que
nuestros clientes las obtengan de un directorio local.
Al igual que para las tareas que se crean con at, tanto la salida de errores como la estándar de todas
las tareas periódicas, se trasmiten al usuario correspondiente utilizando la mensajerı́a local del sistema.
Para el caso de las tareas del sistema, se envı́an al usuario root a menos que se defina lo contrario.
16.5.4. Anacron
Una tarea tipo cron es muy útil pero su ejecución depende de que la máquina se encuentre encendida
en el momento exacto para el que se programó. Es por ello que existe otro tipo de tareas periódicas:
las anacrons. Estas se ejecutan cada cierto tiempo especificado en dı́as. En caso de que la máquina se
apague durante un tiempo mayor que el especificado, entonces una vez encendida y activado el servicio
que manipula los trabajos anacron todos aquellos que se encuentren atrasados se ejecutarán tan pronto
transcurra la espera especificada. O sea, para cada trabajo anacron se indica un tiempo en dı́as y una
espera (delay).
Los trabajos anacron se almacenan en el fichero del sistema /etc/anacrontab. Además de indicar el
intervalo de dı́as, el delay y el comando se especifica un nombre para el trabajo. Este se emplea para las
trazas y para nombrar un fichero que emplea el servicio de anacron para saber cuando fue la última vez
que ejecutó este trabajo (timestamp file). Este fichero se almacena en /var/spool/anacron/ y slo contiene
una fecha.
Si no se encuentra instalado, es necesario hacer un apt:

#apt-get install anacron
El fichero /etc/anacrontab tiene la forma:
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
1 5 cron.daily run-parts /etc/cron.daily
7 10 cron.weekly run-parts /etc/cron.weekly
30 15 cron.monthly run-parts /etc/cron.monthly
Podrı́a pensarse que puede ocurrir que un mismo programa se ejecute por la vı́a cron y por la anacron,
pero esto no sucede pues existe una tarea cron para cada perı́odo que actualiza los ficheros en los cuales se
basa el servicio anacron para saber que es lo que debe ejecutar; o sea, cuando el servicio cron logra ejecutar
las tareas correspondientes a un perı́odo, actualiza el fichero de ese perı́odo, y cuando llega anacron (que
se demora más) ya no tiene que ejecutar las tareas.

Parte IV
Valoración final
Capı́tulo 17
Pruebas del sistema
17.1. Nessus: Escáner de vulnerabilidades

Nessus es un potente escáner de redes de Software Libre. Consta de dos partes (cliente/servidor) que
pueden estar instaladas en las misma máquina por simplicidad.
Si el ataque se hace hacia localhost lo que se consigue es auditar nuestra propia máquina.
Cuando finaliza el escaneo se generan unos informes que si se sabe aprovechar e interpretar explican
que tipo de vulnerabilidades han sido encontradas, cómo “explotarlas” y cómo “evitarlas”.
La distribución de Nessus consta de cuatro ficheros básicos: las librerı́as del programa, las librerı́as
NASL (Nessus Attack Scripting Language), el núcleo de la aplicación y sus plugins.
Para instalar el programa hay que realizar el apt siguiente:

#apt-get install nessus nessusd
Y después descargamos de la página de Nessus (http://www.nessus.org/ ) los plugins que creamos ne-
cesarios, instalandolos en la carpeta /nessus/plugins.
Durante el proceso de instalación se nos realizan una serie de preguntas para generar un certificado
SSL para Nessus:
-------------------------------------------------------------------------------
Creation of the Nessus SSL Certificate
-------------------------------------------------------------------------------
Congratulations. Your server certificate was properly created.
/etc/nessus/nessusd.conf updated
The following files were created :
. Certification authority :
Certificate = /var/lib/nessus/CA/cacert.pem
Private key = /var/lib/nessus/private/CA/cakey.pem
. Nessus Server :
Certificate = /var/lib/nessus/CA/servercert.pem
Private key = /var/lib/nessus/private/CA/serverkey.pem
Donde podemos observar que se ha creado un certificado autofirmado para el servidor Nessus.
17.1.1. Configurar el programa

Vamos a seguir una serie de pasos para configurar el servidor Nessus:
El archivo de configuración es: /etc/nessus/nessusd.conf
La configuración por defecto es completa y válida, entre otras cosas escanea desde el puerto 0 al
15000. Ahı́ podemos modificar todas las opciones que nos parezcan oportunas.
Creamos un usuario para lanzar el programa, para ello seguiremos las instrucciones de pantalla, una
vez ejecutado el siguiente comando:
#nessus-adduser
Entre las opciones que se presentan, para validar el usuario se puede elegir entre el sistema de
login/password o certificados digitales, es mucho más seguro el sistema de certificados. También
podemos especificar unas reglas (rules) concretas para ese usuario.
Se puede elegir que el usuario acceda desde una red concreta, o permitir que acceda desde todas las
redes. Para esta última configuración es neceario editar el archivo de reglas /etc/nessus/nessusd.rules
e introducir la siguiente lı́nea en la parte address/netmask : default accept
Podemos observar como queda el archivo ası́:

#
# Nessus rules
#
# Syntax : accept|reject address/netmask
# Accept to test anything :

default accept
Registrar la versión de Nessus, para ello hay que entrar en: http://www.nessus.org/register/ poner
un correo electrónico donde se nos reportará la clave. Una vez recibido el correo basta con insertarlo
en la lı́nea de comandos:
#nessus-fetch --register <CLAVE>
Una vez tengamos el servidor registrado, lo arrancamos en background:
#nessusd -D o #nessusd --background
Si ejecutamos: # ps aux | grep ’nessus’,. . . podremos observar si se ha cargado bien:
root 10938 0.0 0.9 7332 4712 ? Ss 13:22 0:00 nessusd: waiting
root 10960 1.0 0.1 2316 772 pts/3 S+ 13:23 0:00 grep nessus
17.1.2. Ejecución de Nessus

Para lanzar el cliente en modo gráfico, ejecutaremos el siguiente comando: #nessus
También se puede iniciar en modo comando, para el modo comando consultaremos el manual de ayuda:
$man nessus
Es necesario recordar que si tenemos activo el IDS Snort o cualquier otro NIDS, se va a volver loco al
ejecutar Nessus. Es necesario desactivarlo o hacer que el NIDS ignore la IP de Nessus.
Para ejecutarlo podemos seleccionar las siguientes opciones:

En Nessusd Host, indicaremos los datos añadidos en la creación del usuario (login/password, etc).
En la pestaña de plugins (los tipos de ataques), seleccionaremos todos si queremos un escaneo
completo. Hay que tener cuidado con Denial of service (DoS) por razones obvias.
En credentials, colocaremos la cuenta, contraseña y dominio Samba, si es que lo queremos escanear.
En Scan Options, especificaremos los puertos a escanear y la herramienta a utilizar.
En target, indicaremos la o las direcciónes IP de las máquinas a escanear.

Capı́tulo 17. Pruebas del sistema 301
En las siguientes pantallas podemos observar cada una de estas secciones:
Figura 17.1: Configuración de la aplicación Nessus

Una vez realizada la comprobación del servidor podemos observar las siguientes vulnerabilidades en-
contradas:
Figura 17.2: Vulnerabilidades encontradas en el sistema
Básicamente podemos decir que la seguridad del servidor esta controlada. A esto únicamente habrı́a
que añadir alguna actualización de versiones para parchear posibles exploits descubiertos recientemente.
17.1.3. Otros interfaces de configuración

También podemos ejecutar otras interfaces gráficas para Nessus:
NPI: Interfaz PHP. Se puede descargar en: http://enterprise.bidmc.harvard.edu/pub/nessus-php/
NCC: Nessus Command Center. Se puede descargar en: http://www.netsecuritysvcs.com/ncc/

17.2. Nmap: Escáner de red y puertos

La herramienta de exploración de red y escáner de seguridad, Nmap es posiblemente el mejor escaner
de puertos existente, permitiendo determinar, de una forma rápida y sencilla, que servidores están activos
y qué servicios ofrecen, es decir sus puertos abiertos.
Es una de esas herramientas de seguridad imprescindible para cualquier administrador de sistemas,
siendo utilizada diariamente en todo el mundo, tanto por piratas informáticos como por administradores
de sistemas. Su software se ha utilizado en otros muchos programas y ha sido portado a casi todos los
sistemas operativos importantes.
Es un requisito previo, realizar un escanéo de vulnerabilidades con Nessus. Existen también disponibles
varios complementos, incluyendo analizadores de salidas del programa, como por ejemplo Nlog.
17.2.1. Caracterı́sticas básicas

Entre las caracterı́sticas del Nmap podemos encontrar:
Flexible: Soporta técnicas avanzadas para el mapeado de sistemas y redes que estén detrás de filtros
IP, firewalls, routers y otros obstáculos. Estas incluyen mecanismos de escaneado de puertos (tanto
TCP, como UDP), detección del sistema operativo, escaneos invisibles, conexiones semiabiertas, . . .
Potente: Se puede utilizar para escanear redes de ordenadores con cientos de máquinas.
Portable: Existen versiones para la gran mayorı́a de los sistemas operativos modernos, entre ellos:
Linux, Open/Free/Net BSD, Solaris, IRIX, Mac OS X, HP-UX, Sun OS, Windows (fase beta), . . .
Fácil : Aunque existen una gran cantidad de opciones disponibles, se puede realizar un sencillo
escaneado de puertos con: #nmap -O -sS <maquina>
Libre: El objetivo del proyecto Nmap es proveer a los administradores, auditores e intrusos de una
potente herramienta de seguridad con la que explorar las redes. Nmap se distribuye con licencia
GPL por lo que su código fuente está disponible para su descarga.
Buena Documentación: Se ha realizado un gran esfuerzo en mantener actualizados y traducidos
tanto las páginas man, como los tutoriales y el resto de documentación relacionada con Nmap.
Soportado: Aunque Nmap viene sin garantı́a explicita de ningún tipo, se puede escribir al autor o
utilizar las diferentes listas de distribución sobre Nmap. Existen varias empresas que incluyen soporte
para Nmap entre sus servicios.
Premiado: Nmap ha recibido multitud de premios y reconocimientos concedidos por revistas del
sector.
Popular : Diariamente cientos de personas descargan Nmap, además está incluido de serie en muchos
sistemas operativos, como Debian. Esta gran popularidad es la mejor garantı́a de su calidad, soporte
y desarrollo.
Tal y como hemos comentado, el uso del Nmap es muy sencillo, por ejemplo, para averiguar los servicios
o puertos, accesibles de una determinada máquina, bastará con ejecutar: #nmap <host> -O
La salida que obtenermos del servidor que se ha configurado durante el proyecto se puede observar en
la siguiente página.

#nmap 192.168.0.10 -O
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-06-11 19:27 CEST

Interesting ports on 192.168.0.10:
(The 1652 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
9/tcp open discard
13/tcp open daytime
22/tcp open ssh
37/tcp open time
80/tcp open http
111/tcp open rpcbind
113/tcp open auth
515/tcp open printer
631/tcp open ipp
721/tcp open unknown
10000/tcp open snet-sensor-mgmt
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X
OS details: Linux 2.5.25 - 2.6.3 or Gentoo 1.2 Linux 2.4.19 rc1-rc7), Linux 2.6.3 - 2.6.8
Uptime 0.274 days (since Sat Jun 11 12:52:40 2005)
Nmap finished: 1 IP address (1 host up) scanned in 2.372 seconds
Depués de descubrir los servicios que ofrece la máquina, con un simple telnet hemos obtenido el sistema
operativo instalado en la máquina y la versión de ssh, si se conoce alguna vulnerabilidad de esa versión
podrı́a ser atacada: telnet <host> <puerto>
# telnet 192.168.0.10 22
Trying 192.168.0.10...
Connected to 192.168.0.10.
Escape character is ’^]’.
SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4
Protocol mismatch.
Connection closed by foreign host.
Existen muchas más opciones y alternativas, por lo que es más que recomendable acceder a la docu-
mentación incluida con Nmap, ası́ como a la página man del mismo.
#nmap --help
#man nmap
#lynx nmap\manpage-es.html
Estos escaneos de máquinas y redes, suelen dejar huellas de su ejecución en los registros logs de las
máquinas escaneadas (por ejemplo, en /var/log/messages), por lo que es interesante el utilizar alguno de
los modos de escaneos invisibles que se pueden ejecutar con Nmap, tales como -sF,-sX,-sN Stealth FIN,
Xmas, or Null scan, . . . de forma que se evitar finalizar la negociación TCP, evitando al mismo tiempo
el comentado registro en los ficheros logs.
Fyodor, el desarrollador de esta herramienta, tiene un gran sentido de humor, tal y como lo demuestra
al implementar la opción -oS, que muestra la salida del Nmap en un formato que les encantará a los
Script-kiddies, la podemos observar en el siguiente ejemplo:
#nmap -oS - 192.168.0.10+
$taRt|ng nmap V. 2.54B3T431 ( www.1n$ecur3.ORg/nmap/ )

|nt3r3sting pOrtz 0n debian.example.org (192.168.0.10):
(The 1545 Portz scannEd but nOT sh0wn bel0w ar3 In $tatE: cLOS3D)
POrt Stat3 S3rv1Ce
22/tcp OpeN $$H
25/Tcp 0pEn smtp
80/tcp 0p3n htTp
139/tcP op3n N3Tb1Oz-Ssn
143/tCP 0pen imap2
515/tcp f!lt3red prinT3r
3128/tcp Op3n squ|d-HtTP
3306/tCp Op3n my$ql
6000/tcp 0p3n x11
Nmap rUn c0mpl3ted -- 1 !P aDdr3Sz (1 hOst uP) scANnEd !n 3 $econdS

17.2.2. Tipos de escaneado

Existen muchos tipos de escaneado que se pueden ejecutar con Nmap. El cuadro 17.1 incluye una lista
de los que probablemente usaremos con más frecuencia.
Cuadro 17.1: Tipos de escaneo en Nmap

Tipo de escanéo Descripción
SYN: -sS Escaneado predeterminado, no completa la comunicación TCP.
TCP Connect: -sT Parecido a SYN, completando la comunicación TCP. Es un método ruidoso
y carga en exceso las máquinas examinadas.
Ping Sweep: -sP Un simple ping a todas las direcciones, comprueba las direcciones IP activas.
Escaneado UDP: -sU Comprueba los puertos UDP para localizar los que escuchan.
Escaneado FIN: -sF Escaneado sigiloso, como SYN pero enviando en su lugar un paquete TCP
FIN. La mayorı́a de los hosts devolveran un RST.
Escaneado NULL: -sN Escaneado sigiloso, establece los indicadores de encabezados a nulos. No es
un paquete válido y algunos hosts no sabran que hacer con él.
Escaneado XMAS: -sX Similar a NULL pero todos los indicadores del encabezado TCP se activan.
Los Windows, por su estructura, no responderán.
Escaneado Bounce: Usa un agujero en el protocolo FTP, para rebotar paquetes fuera de un
-n FTP_HOST servidor FTP y hacia una red interna que normalmente no serı́a accesible.
Escaneado RPC: -sR Busca máquinas que respondan a los servicios RPC.
Escaneado Windows: Se basa en una anomalı́a en las respuestas a los paquetes ACK en algún
-sW sistema operativo para mostrar los puertos que se suponen van a filtrarse.
Escaneado Idle: Escaneado sigiloso por el que los paquetes rebotan hacia un host externo.
-SI zombie_host_probe_port
17.2.3. Opciones de descubrimiento

También podemos ajustar la forma en que Nmap descubre la red y determina que hosts están activos.
El cuadro 17.2 incluye diversas opciones:
Cuadro 17.2: Opciones de descubrimiento en Nmap

TCP + ICMP: -PB Utiliza paquetes ICMP y TCP para determinar el estado de un anfitrión. Es la
forma más fiable y precisa, ya que usa los dos métodos.
TCP Ping: -PT Usa solo el método TCP. Si estamos intentando ser sigilosos esta es la mejor
opción.
ICMP Ping: -PE No es una buena opción si el objetivo se encuentra detrás de un cortafuegos, la
mayorı́a de los paquetes serán eliminados.
Dont’s Ping: -P0 Nmap no intentará conocer primero qué hosts se encuentran activos en la red,
en su lugar enviará sus paquetes a todas las IP en el rango especificado, incluso
aunque no haya una máquina detrás. Puede ser la única forma de examinar una
red bien protegida y que no responde a ICMP.
17.2.4. Opciones de ajuste de frecuencia de Nmap

Nmap nos ofrece la opción de agilizar o ralentizar la frecuencia con la que envı́a sus paquetes de escáner.
Si estámos preocupado por la cantidad de tráfico de red (o estámos intentando ser sigilosos), podemos
ralentizar el nivel. Sólo hay que tener en cuenta que cuanto más lejos los enviamos, más tiempo tardará el
escaneado, algo que puede aumentar exponencialmente el tiempo de escaneado en redes grandes. Por otro
lado, si tenemos prisa y no nos preocupa el tráfico de red adicional, podemos aumentar el nivel. Podemos
ver los distintos niveles de frecuencia en el cuadro 17.3.

Cuadro 17.3: Configuraciones de frecuencia en Nmap

Frecuencia Parámetro Frecuencia de paquete Comentarios
Paranoid -F 0 Una vez cada 5 minutos No utilizar esta opción en escaneados
de varios hosts, ya que el escaneado
nunca terminará.
Sneaky -F 1 Una vez cada 15 segundos
Polite -F 2 Una vez cada 4 segundos
Normal -F 3 Tan rápida como permita el SO Configuración predeterminada.
Agressive -F 4 Igual que Normal pero la fre-
cuencia del paquete se recorta a
5 minutos por host y 1,25 segun-
dos por paquete de sondeo
Insane -F 5 0,75 segundos por host y 0,3 se- Este método no funciona bien a no ser
gunos por paquete de sondeo que estemos en una red muy rápida
y usemos un computador realmente
rápido, e incluso ası́ podrı́amos perder
datos.
17.2.5. Otras opciones de Nmap

El cuadro 17.4 recoge una lista de otras opciones para Nmap que controlan cosas como la resolución
DNS, la identificación de SO y otras opciones. Existen más opciones para ajustar nuestros escaneados
disponibles utilizando la interfaz de lı́nea de comandos. Si queremos más detalles podemos recurrir al
manual de Nmap.
Cuadro 17.4: Opciones deversas de Nmap

Opción descripción
Don’t Resolve: -n Agiliza el escaneado, pero podemos perder hosts, sobre todo en redes
con DHCP.
Fast Scan: -F Escanea los puertos especificados, generalmente los puertos conocidos
por debajo de 1024.
Port Range: -p port_range De forma predeterminada Nmap examina los 65.536 puertos disponi-
bles, con esta opción solo examina ese rango.
Use Decoy: -D Se introducen IPs señuelo en el trafico mandado a la máquina que se
decoy_address1, esta examinando, ası́ le resulta más dificil saber que máquina le esta
decoy_address2, ... escaneando.
Fragmentation: -f Opción sigilosa, que fragmenta los paquetes de escaneado a mediada
que sale. Los paquetes son montados en la máquina atacada y algunas
veces pueden burlar los cortafuegos e IDS.
Get Indentd Info: -I El servicio Identd que se ejecuta en algunas máquinas puede propor-
cionar información adicional sobre el host consultado.
Resolve All: -R Esta opción intenta resolver las direcciones en el rango, incluso aunque
no estén respondiendo.
SO Identification -o Analiza la “huella digital” de las respuestas para determinar el SO
Send on Device: Obliga a los paquetes de escaneado a salir de una interfaz especı́fica.
-e interface_name

17.2.6. Salida de Nmap

Nmap produce un informe que muestra cada dirección IP encontrada, los puertos descubiertos escu-
chando dicha IP y el nombre conocido del servicio (si lo tiene). También muestra si el puerto se ha abierto,
filtrado o cerrado. Sin embargo, sólo porque Nmap obtenga una respuesta sobre el puerto 80 e imprima
“http”, no significa que un servidor Web se está ejecutando en el host, aunque es algo bastante probable.
Siempre se puede verificar cualquier puerto sospechoso abierto consultando con dicha dirección IP sobre el
número de puerto especificado y observando la respuesta obtenida. Si existe un servidor Web ejecutándose
ahı́, normalmente podremos obtener una respuesta mediante la introduccion del comando GET/HTTP.
Ası́ se devolverá la página inicial de ı́ndice como HTML (no como una bonita página Web), pero podremos
verificar si un servidor se está ejecutando. Con otros servicios como FTP o SMTP podemos llevar a cabo
tareas similares. Nmap también codifica con colores los puertos encontrados, según la siguiente tabla:
Cuadro 17.5: Codificación de color de la salida de Nmap

Color Descripción
Rojo Este número de puerto está asignado a un servicio que ofrece alguna forma directa de inicio
de sesión en la máquina, como Telnet o FTP. Estos son los más atractivos para los intrusos.
Azul Este número de puerto representa un servicio de correo como SMTP o POP.
Negrita Estos son servicios que pueden proporcionar alguna información sobre la máquina o el sistema
operativo.
Negro Cualquier otro servicio o puerto identificado.
Como podemos comprobar en el cuadro 17.5, la salida nos permite examinar un informe y determinar
rápidamente si hay más servicios o puertos con los que tenemos que tener cuidado, lo que no significa
que deberı́amos ignorar cualquier número inusual que no esté resaltado o en negrita. Los troyanos y el
software de conversación se muestran normalmente como servicios desconocidos, pero podemos buscar un
puerto misterioso en una lista de puertos malignos conocidos para determinar rápidamente si el puerto
abierto es algo de lo que tenemos que preocuparnos. Si no lo podemos encontrar en dicha lista, tendremos
que cuestionarnos cuál será ese servicio extraño que se está ejecutando en la máquina y que no utiliza un
número de puerto conocido.
Podemos guardar los registros Nmap como números de formato, incluyendo el texto simple o legible
por la máquina, e importarlos en otro programa. Sin embargo, si dichas opciones no fuesen suficientes,
Nlog (sin licencia GPL) o alguna herramienta parecida puede ayudarnos a interpretar la salida Nmap. Su
ejecución sobre redes muy grandes puede servirnos de salvavidas ya que el examen cuidadoso de cientos
de páginas de salidas Nmap nos puede volver locos rápidamente.
17.2.7. Configuración gráfica de Nmap, interfaz Nmapfe

Incluido con Nmap se encuentra nmapfe que es un interfaz gráfica, que permite ejecutar Nmap usando
el ratón. También indicar que existen otras interfaces gráficas para facilitar aún más el uso de esta potente
aplicación (KNmap, KNmapFE, QNMap, Kmap, Web-NMap, vnmap, . . . )
Para instalarla realizaremos un apt:

#apt-get install nmapfe
Y para ejecutarla: #nmapfe o xnmap
Nmap es una herramienta ideal para Verificar/auditar el Firewall, tal como dice uno de los banner de
su página oficial, “Audite la seguridad de sus Redes antes que los chicos malos lo hagan” (Audit your
network security before the bad guys do).
La página oficial de Nmap es: http://www.insecure.org/nmap/

17.3. Pruebas de carga

Aunqué en un principio pense en realizar una serie de pruebas de carga con diferentes clientes, para
determinar el grado de sostenibilidad del sistema, no va a hacer falta. Carece de sentido probar algo que
no va a aportar ningún dato nuevo, sino la confirmación de algo que temia desde un principio. Tales eran
mis dudas que lo llege a comentar con el director del proyecto.
Durante la elaboración del proyecto, en todas y cada una de las secciones, en la información que he
consultado, se advertı́a de que el uso de servicios de gran consumo de recursos en la misma máquina
provocarı́an la ralentización del sistema hasta niveles inaceptables. Un ejemplo de esto serı́a el IDS Snort,
trabajando junto a la base de datos MySQL o el el servidor Syslog.
Puesto que el servidor que utilizo es un ordenador portatil con procesador Intel Centrino a 1,6 Ghz.
con 512 Mb de RAM, en vez de un supercomputador con con varios procesadores, no es necesario rea-
lizar estas pruebas para confirmar lo evidente. Considero que mi capacidad de optimización del sistema,
probablemente, sea menor que la de muchas de esas personas que describen como “suicidio”, respecto a
rendimiento y seguridad, centralizar los servicios de una corporación en una única máquina.
Las razones que me llevan a esta decisión son varias:
He asumido desde un principio, que el sistema no es capaz de ejecutar y soportar el uso simultaneo de
los demonios de los servicios implementados. Esto se puede observar, por ejemplo, cuando arranco
el servidor y Tripwire deja el sistema colapsado, al actualizar las sus bases de datos de archivos
(Incluso con una prioridad nice baja (+10).
Por el tamaño de la empresa que vaya a implementar el proyecto:

• Para empresas pequeñas carece de sentido tener todos los tipos de servidores disponibles, ya
que la mayorı́a no se utilizarán.
• Para empresas grandes que necesiten todos los tipos de servidores, se disponen de presupuestos
adecuados para distribuir los servicios entre varias máquinas. La limitación no esta en el coste
de las máquinas sino en el personal que necesitan para configurarlas y administrarlas, además
del coste que supone, el espacio fı́sico que ocupan (en cuartos climatizados), medidas de fı́sicas
de seguridad, etc.
Por motivos de eficiencia no se debe centralizar los servicios:
• La máquina funcionarı́a al 100 % de su capacidad, obteniendose de ella un 10 % del rendimiento
teórico.
• Si se produjerá una caida fortuita de la máquina, como un fallo eléctrico o mecánico, todos los
servicios de la red caerı́an con ella.
Por motivos de seguridad no se debe centralizar los servicios:

• Si un servicio tiene un exploit y un intruso obtiene el control de la máquina, obtiene a la misma
vez el control de todos los servicios de esa máquina.
• Los ataques dirigidos sobre una sola máquina son más eficientes que sobre varias.
Por todo ello, no creo necesario realizar pruebas de carga para determinar que no es una buena elección
situar todos los servicios en una única máquina. Y que se deberı́a de buscar una solución para descentralizar
el sistema.

Capı́tulo 18
Estudio Económico
Mediante los siguientes esquemas se determinará el coste del proyecto de haber sido encargado por
una empresa.
18.1. Recursos
En el siguiente cuadro se detallan los recursos que fueron necesarios para la elaboración del proyecto
con una baremación aproximada de sus costes.
Cuadro 18.1: Recursos asignados al proyecto
Nombre Nombre corto Grupo Tipo Coste

Jose Antonio Escartı́n Vigo Jefe de proyecto Personal Obra 40 e/h
Jose Antonio Escartı́n Vigo Analista Personal Obra 30 e/h
Jose Antonio Escartı́n Vigo Administrador de sistemas Personal Obra 25 e/h
Jose Antonio Escartı́n Vigo Documentalista Personal Obra 15 e/h
Servidor Portatil Infraestructura Material 1150 e
Cliente Duron Linux/Windows Infraestructura Material 600 e
Cliente de alquiler 1 Windows1 Infraestructura Material 100 e
Cliente de alquiler 2 Windows2 Infraestructura Material 100 e
Portatil de alquiler ClienteWifi Infraestructura Material 150 e
Impresora HP Deskjet 815 HP815 Infraestructura Material 240 e
Router, Swich y cables Redes Infraestructura Material 300 e
Material de oficina Oficina Infraestructura Material 300 e
Local, luz e internet Mantenimiento Gastos Material 1500 e
Desplazamientos Desplanzamientos Gastos Material 100 e
Manual de administración Linux Linux1 Libros Material 48 e
Linux a fondo Linux2 Libros Material 30 e
Todo Linux Linux3 Libros Material 68 e
Sw libre: Herramientas de seguridad Seguridad Libros Material 42 e
El libro de LATEX LATEX Libros Material 38 e
Resto de libros e información prove- Información Libros Material —e
niente de bibliotecas e Internet
18.2. Costes
En la siguiente tabla, se puede encontrar una valoración aproximada de los costes totales del proyecto,
basada en los sueldos/hora asignados a cada cargo del personal.
Cuadro 18.2: Costes del proyecto
Nombre Nombre corto Tareas asignadas N.o de horas Coste

Jose Antonio Jefe de proyecto Establecer la planificación y fijar 20 h. 800e
Escartı́n Vigo objetivos
Jose Antonio Analista Seleccionar herramientas y anali- 50 h. 1.500e
Escartı́n Vigo zar el grado de cumplimiento de
los objetivos
Jose Antonio Administrador Instalar sistema, configurar ser- 220 h. 5.500e
Escartı́n Vigo de sistemas vicios y realizar las pruebas
Jose Antonio Documentalista Generar informes y documentar 160 h. 2.400e
Escartı́n Vigo el proyecto
Material Varios — — 4.766e
TOTAL: 14.966e
18.3. Resumen económico

El coste del proyecto esta muy por encima de lo esperado, con un valor aproximado de 15.000e. Parece
claro, que el factor que influye de una forma determinante es la mano de obra necesaria, estableciendo el
valor del material en solamente un tercio del total, por dos tercios la mano de obra.
Manejando estas cantidades, un proyecto de este estilo solo está al alcance de empresas donde se vaya
a utilizar este documento de manera intensiva, haciendo inviable un estudio de este tipo en pymes.
18.4. Modificaciones a los costes económicos

Debido a la falta de experiencia en sistemas Linux y en la creación de manuales, esta planificación
económica se deberı́a ver incrementada de la siguiente forma:
Hasta las 350 horas en Administración de sistemas: Para la asimilación de los entornos, la configu-
ración de los servicios y las pruebas necesarias.
Hasta las 400 horas en Documentación: Debido al cambio de orientación del proyecto, hacia la
elaboración de un “Manual de instalación de servidores en Linux”.
Esto supodrı́a un aumento, de valor respecto al proyecto original, de unos 7.000e, subiendo el precio
total aproximado a los 22.000e.
Este aumento en el número de horas en ningún caso a derivado en un retraso en los plazos de entrega,
ya que estos han sido respetados con riguridad. Y atienden a un mejor aprovechamiento y usabilidad de
los contenidos del proyecto. Se podrı́a decir que respecto a los objetivos iniciales, de “instalar un servidor”,
elaborando un “Manual de instalación para servidores Linux” se ha conseguido que el uso del proyecto
pueda llegar a más ámbitos y convertirlo en útil para muchas personas.

Capı́tulo 19
Conclusiones
La conclusión principal es que los objetivos marcados inicialmente fueron erróneos:

No es viable un servidor centralizado:
• El poco coste del material, para una empresa, no compensa las desventajas.
• La descentralización se apoya en: Modularidad, seguridad y redimiento.
No es viable un servidor portatil corporativo e itinerante:
• Sólo puede ser utilizado para servicios concretos.
• Las redes inalámbricas producen graves problemas de seguridad intrinsecos e inevitables.
• Las conexiones itinerantes a Internet, ofrecidas por los ISP, todavı́a estan en pañales.
• La conexión es un problema, desde los siguientes puntos de vista:
1. Se necesita un punto de acceso (AP) que acompañe al servidor, como podrı́a ser un router.
2. La conexión EAP-TLS a través de certificados digitales no es muy flexible a la incorpora-
ción de nuevos usuarios, que por ejemplo podrı́an ser los empleados de otra oficina, en otra
ciudad. Este problema lo podrı́amos solventar agregando a nuestro sistema un programa
de validación de conexión en nuestro sistema por web, como NoCat, donde los usuarios wifi
acceden al servidor mediante usuario y contraseña.
El aumento de las horas dedicadas, que no los plazos de entrega, fue debida a que el proyecto evoluciono
hacia la elaboración de un: “Manual de instalación para servidores Linux”, que abarca desde la elección
de la distribución, pasando por la instalación del sistema y finalmente la configuración de la gran mayorı́a
de servicios disponibles para entornos corporativos.
Este cambio de orientación, fue decidio a la mitad del proyecto, de nada servı́a documentar la ins-
talación de un servidor Linux, si el proceso no podı́a ser reproduccido, a menos que se dispusiera de la
misma máquina y la misma infraestructura. El proyecto se ha adaptado a un entorno más general, basado
en la distribución Debian Sarge, para que los conociemientos adquiridos, puedan ser aprovechados por un
número mayor de usuarios de escritorio y administradores de sistemas.
A modo de resumen me quedaré con la siguiente frase que lei mientras me documentaba y que esta
en concordancia con el espı́ritu de este proyecto: “En Internet sólo el paranoico sobrevive. Puede ser un
lugar muy sucio, lleno de virus, gusanos, troyanos, spammers y abogados de litigios de patentes; lo último
que alguien querrı́a es ponerse en lı́nea sin protección alguna.”
Es decir, el uso de:

Conexiones seguras como: SSH (telnet), SSL (web), PGP (cifrado de datos), EAP-TSL (wifi), . . .
Firewalls, es decir sistemas de barrera contra ataques exteriores y fugas de información.
IDS, sistemas de detección de intrusos: NIDS como Snort, IDS como Tripwire para garantizar la in-
tegridad en archivos, Honeypots como Honeyd para entretener los ataques de los intrusos, detectores
de escaners de puertos, de sniffers y de rootkits, . . .
Monitorización del sistema: Top, Kismet Wireless, AirSonrt, . . .
Chequeos del sistema: Escaneo de vulnerabilidades con Nessus, escaneo de puertos y servicios en red
con Nmap, escaneo de logs con Logcheck, . . .
...
No garantiza la seguridad. Si un intruso quiere entrar, y tiene los conocimientos y/o herramientas
suficientes, entrará. Las herramientas aquı́ propuestas son de carácter preventivo, disuasorio y forense. De
esta forma es mucho más facil que el intruso se desespere y se vaya a hacer lo que quiere hacer, a otro sitio.
Los sistemas de este estilo, no son la panacea, exigen la dedicación de mucho tiempo y una adminis-
tración rigurosa. Es decir, exigen de mucho tiempo y mucho dinero para que resulten efectivos.
No todas las empresas se podrán permitir este tipo de gastos. Hay que analizar hasta donde conviene
proteger y aplicar una solución, que no será estandar, sino adaptada al perfil de nuestra organización o
empresa.
A nivel personal a sido un proyecto muy gratificante y muy desesperante al mismo tiempo, esto a sido
debido a varios motivos:
El primero y principal, el proyecto lo plantee demasiado ambicioso. Partı́a con mucha voluntad,
ganas e interes; pero con una gran falta de conocimientos de base, esto muy pronto se hizo patente.
La planificación fue bastante imprecisa: Debido a mi falta de experiencia y conocimientos, los plazos
se han aumentado muchisimo, llegando suplir esta falta de previsión con unas 300 horas extras
respecto a la planificación inicial.
A pocos dı́as de la entrega final, se lanzo la versión estable del proyecto Debian Sarge. Esto derivo
en dos consecuencias importantes:
1. La primera positiva: La elección de Debian Sarge fue muy acertada, si hubiera elegido Debian
Woody, habrı́a terminado un proyecto que desde el principio serı́a obsoleto. Por contra, ahora
está totalmente actualizado y será válido por un largo periodo de tiempo.
2. En contra: La mayor parte del documento está escrito pensado que la versión estable se lanzarı́a
en un futuro inmediato. Este futuro se ha adelantado un mes, la solución a pasado por agregar
un anexo (véase anexo G) donde se explica que ha pasado y que implicaciones tiene esto en el
documento.
El proyecto lo podrı́a clasificar de interés personal, ya que mi pasión de siempre, han sido los
sistemas operativos. Por razones diversas no me habı́a adentrado en el mundo de Linux, más que a
un nivel muy superficial. Este proyecto me ha permitido profundizar e investigar sobre el mundo de
la seguridad informática, sobre todo en entornos Linux y es muy probable que en el futuro, mi perfil
profesional se ubique en este sector.
Con el proyecto finalizo la Ingenierı́a técnica en Informática de Sistemas, y me servido para afian-
zarme en la idea de terminar mis estudios en la Ingeniera superior. Gracias a los conocimientos
adquiridos, el proyecto de la superior me resultará mucho más facil de afrontar y probablemente
también este enfocado hacia alguna parte concreta de la seguridad informática, sector que actual-
metne está teniendo un gran auge.

Capı́tulo 19. Conclusiones 313
Los conocimientos adquiridos en el entorno de composición de textos LATEX me permitirán, a partir

de ahora, realizar documentación mucho más profesional.
El descubrimiento del mundo del software libre, me ha abierto el horizonte, las licencias GPL per-
miten observar que hay futuro más haya de las empresas y los entornos propietarios. Cada uno tiene
su sector de mercado y deben cooperar en vez de enfrentarse, asumiendo el papel que han elegido.
Después de la elaboración de este proyecto, yo me he situado claramente en el sector GPL.
Por todo ello, lo considero una experiencia muy positiva y seguramente orientará mi futuro profesional
al sector de la seguridad informática.
Una objetivo que me gustarı́a conseguir, si es posible (es decir, si la universidad y mi director de
proyecto están de acuerdo), es poner a disposición de la comunidad de usuarios Linux este documento.
De está forma mi trabajo podrá ser aprovechado por un mayor número de personas, ya que este no es el
tı́pico proyecto con una utilidad muy limitada, sino que tiene un uso mucho más amplio y puede llegar a
ser útil a mucha gente.

Parte V
Apéndices
Apéndice A
Comandos básicos
Para más información sobre los comandos podemos ejecutar: $man <comando>
Comandos de sistema
man Páginas del manual
ls Listar (múltiples opciones)
rm Borrar
cp Copiar
mv Mover o renombrar
ln -s <fichero> <enlace> Enlace debil a fichero
pwd Directorio actual
cd <directorio> Entra en directorio
cd .. Sale del directorio actual
chown, chgrp y chmod Sobre atributos de ficheros
touch <fichero> Crear ficheros vacı́os
find y locate Buscar ficheros
grep Buscar texto en ficheros (muy potente)
find / | grep ’cadena’ Busca un fichero que contenga esa cadena por el sistema
df Ver espacio libre en disco
du -sh Ver espacio usado en el directorio actual
cat, more y less Lista ficheros
<comando>|more y <comando>|less Salida de comando filtrada por páginas
vim y emacs Editores de texto, modo texto
nedit, kedit y kwrite Editores de texto, modo gráfico
split Partir ficheros
which Devuelve el Path de un ejecutable, que se encuentre en la
variable $PATH
Entorno gráfico X-Windows

startx Iniciar sesion X
startx -- :2, :3, etc. Abrir nuevas sesiones
xf86config Configurar X, modo texto
xf86cfg Configurar X, modo gráfico
CTRL+ALT+BACKSPACE Salir de las X
Comandos para comunicaciones y redes

who Lista los usuarios conectados
finger Información sobre los usuarios
mail Sencillo programa de correo
write Manda un mensaje a la pantalla de un usuario
wall Manda un mensaje a todos los usuarios
mesg Activa/Desactiva la recepción de mensajes write y wall
talk Establece una conversación con otro usuario
baner Saca un letrero en pantalla con el texto que se le pase al comando
cal Saca un calendario en pantalla
clear Limpia la pantalla
date Saca fecha y hora actuales
passwd Cambia contraseña de un usuario
Comprimir y descomprimir
tar zxvf Descomprimir un .tar.gz
tar jxvf Descomprimir un .tar.bz2
tar cxvf <archivo>.tar.gz <archivo> Comprimir un archivo o directorio
gzip -d Descomprimir un .gz
tar Empaquetar sin comprimir (múltiples opciones)
gzip Comprimir ficheros (despues de empaquetar)
Montaje de unidades
mount -t msdos /dev/floppy /mnt Montar diskette
mount -t iso9660 /dev/cdrom /mnt Montar cdrom
mount -t <tipo> /dev/<dispositivo> <punto_de_montaje> Montar un dispositivo
umount <punto_de_montaje> Desmontar unidad
Uso del sistema

ps Procesos en ejecución del teminal
ps -u<usuario> Procesos en ejecución del usuario
lspci Dispositivos PCI del sistema
lsmod Módulos cargados en el kernel
modconf Cargar módulos en el kernel
uname -a Información del sistema
ldconfig -p Librerı́as instaladas
ldd <ruta>/<programa> Librerı́as que usa el programa
shutdown -r 0 Reinizializa el sistema (#reboot)
shutdown -h 0 Apaga el sistema (#halt)
shutdown <opcion> <n_segundos> Realiza ópcion despues de n segundos segundos
logout Cierra la sesión del usuario
su <usuario> Cambia sesión a otro usuario (switch user)
fdisk /mbr Borra el gestor de arranque del disco (arranques del siste-
ma)

Apéndice B
Debian en castellano
Para tener las aplicaciones en nuestro idioma lo primero que necesitamos es instalar los siguientes
paquetes:
#apt-get install user-euro-es language-env euro-support
Una vez hayamos realizado el apt-get, para ver “los locales” (idiomas locales) que tiene el usuario que
se encuentra actualmente conectado, hay que ejecutar el siguiente comando:
$locale
Si además queremos saber que traducciones locales tenemos disponibles en el sistema, ejecutaremos la
siguiente instrucción:
$locale -a
Si el idioma castellano, no se encuentra disponible entre las locales del sistema las podemos incluir
en el archivo de configuración de locales, /etc/locale.gen. Para ello añadiremos al final de ese archivo las
siguientes lı́neas:
es_ES@euro ISO-8859-15
es_ES ISO-8859-1
Una vez añadidas al archivo necesitamos que las ejecute y reconfigure nuestro sistema, mediante el
comando:
#/usr/sbin/locale-gen
Además en unos de los ficheros que carga las variables de usuario añadiremos las siguientes variables
de entorno. Por ejemplo en el archivo ˜/.bash profile:
export LANG=es_ES.ISO-8859-15
export LC_ALL=es_ES@euro
La próxima vez que hagamos login con el usuario cargará el nuevo perfil. Podemos comprobamos que
“los locales” son los correctos, con el mismo comando que antes: $locale
Una vez tengamos disponible el idioma castellano, podemos habilitar también el soporte para el euro
en la consola. Pasa eso tenemos que añadir las siguientes lı́neas al fichero /etc/console-tools/config, fichero
de configuración de la consola:
SCREEN_FONT=lat0-sun16
APP_CHARSET_MAP=iso15
APP_CHARSET_MAP_vc2=iso15
APP_CHARSET_MAP_vc3=iso15
Si además también queremos colocar las páginas de manuales en castellano hay que instalar los si-
guientes paquetes:
#apt-get install user-es manpages-es manpages-es-extra
Solo queda castellanizar las aplicaciones del sistema, si es que tienen los archivos del idioma. Hay que
ejecutar el siguiente comando, seleccionando las opciones que nos interesen:
#dpkg-reconfigure locales,
Este documento esta basado en la documentación disponible en Debian, se puede consultar mediante:
$man castellanizar

Apéndice C
Archivos de configuración
Archivo Descripción
/etc/lilo Configuración del gestor de arranque Lilo
/etc/inetd.conf Superservidor de Internet y envoltorio de demonios TCP/IP
/etc/xinetd.conf Configuración del superservidor, mediante entorno gráfico
/etc/init.d/* Scrips de inicio del sistema que ejecutara initd
/etc/rc#.d Scripts runlevels que ejecuta init al arrancar el equipo
/etc/passwd Usuarios del sistema
/etc/group Contraseñas encriptadas de los usuarios del sistema
/etc/skel/* El contenido de este directorio se copiará al home de cada
usuario nuevo del sistema
/etc/fstab Montaje de particiones en el sistema
/etc/X11/XF86Config-4 Configuracion de las X-Windows
˜/.xinitrc Archivo de arranque de usuario para las X-Windows
˜/.vimrc Archivo de configuración del Vim
/etc/profile Preferencias de todos los usuarios del sistema
˜/.profile Preferencias del usuario
˜/.bash profile Preferencias del shell bash
˜/.bash login Configuración de inicio del shell bash
˜/.bash logout Configuración de finalización del shell bash
˜/.bashrc Si se ejecuta un shell interactivo bash sin entrada por consola
/etc/ssh/ssh config Configuración del cliente para las conexiones seguras SSH
/etc/ssh/sshd config Configuración del servidor de conexiones seguras SSH
˜/.gnupg/ Directorio que contiene los archivos de usuario de GnuPG
/etc/at.allow Usuarios a los que les esta permitido programar tareas at
/etc/at.deny Usuarios a los que les esta denegado programar tareas at
/etc/crontab Taréas programadas del sistema
/var/spool/cron/crontabs/<usuario> Tareas programadas por cada usuario
/etc/anacrontab Tareas programadas que se pueden ejecutar con retraso
/etc/locale.gen Archivo de locales
/etc/console-tools/config Archivo de configuración de la consola
/etc/webmin/miniserv.conf Archivo de configuración de Webmin
/etc/squid/squid.conf Configuración del proxy Squid
/etc/squid/* Archivos de configuración del Proxy Squid
/etc/kismet/kismet ui.conf Configuración de la interfaz del sniffer wifi Kismet
/etc/kismet/kismet.conf Configuración del sniffer wifi Kismet
/etc/freeradius/radiusd.conf Opciones de FreeRadius
/etc/freeradius/eap.conf Opciones para EAP en FreeRadius
/etc/freeradius/clients.conf IPs clientes de FreeRadius
/etc/freeradius/users.conf Usuarios clientes de FreeRadius
/etc/modules.conf Módulos que se cargarán al inicio
/etc/modules Configuración de los módulos
/etc/network/interfaces Configuración de interfaces de red
/etc/network/options Configuración de las opciones de red
/etc/host.conf Dice al sistema cómo resolver los nombres de los hosts
/etc/hostname Nombre.dominio del host local
/etc/hosts Nombre y dirección IP de hosts del sistema
/etc/hosts.allow Hosts a los que se le permite el acceso al sistema
/etc/hosts.deny Hosts a los que se le deniega el acceso al sistema
/etc/hotplug/* Scrips de configuración de dispositivos hotplug (inst. dinámica)
/etc/hotplug.d/* Archivos de agentes de dispositivos
/etc/cvs-cron.conf Sistema de versiones concurrentes (cvs)
/etc/cvs-pserver.conf Opciones del servidor de versiones (cvs)
/etc/dhcpd.conf Archivo de configuración estandar DHCPD
/etc/default/dhcpd Opciones del DHCPD
/var/lib/dhcp/dhcpd.leases Base de datos lease para el servidor DHCPD
/var/lib/dhcp/dhclient.leases Base de datos lease para el cliente DHCP
/etc/default/dhcp3-relay Archivo de configuración DHCP-relay
/etc/dhpc3/dhclient.conf DHCP del cliente dhcp3
/etc/dhcp3/dhcpd.conf DHCP del servidor dhcp3
/etc/snort/snort.conf Archivo de configuración de Snort
/etc/snort/rules/*.rules Archivos de reglas para Snort
/etc/tripwire/twpol.txt Archivo de polı́ticas
/etc/acidlab/acid conf.php Archivo de configuración de ACID
/etc/portsentry/portsentry.conf Archivo de configuración de PortSentry
/var/log/* Registro de logs del sistema
/etc/nessus/nessusd.conf Archivo de configuración de Nessus
/etc/proftpd.conf Configuración del servidor ProFTPD
/etc/ftpusers Usuarios del sistema que tienen permitido el acceso FTP
/etc/ypserv.conf Configuración del servidor NIS
/etc/ypserv.securenets Configura las IP que tienen permiso para usar el servidor NIS
/var/yp/Makefile Configuración opciones servidor NIS y archivos a exportar
/var/yp/yp-servers Listado de los servidores NIS secundarios de nuestro sistema
/etc/yp.conf Configuración del cliente NIS
/etc/nsswitch Archivos a importar del servidor NIS
/etc/resolv.conf Contiene el nombre y la dirección IP de los servidores DNS
/etc/bind/db.lan Añadir para los equipos de una LAN
/etc/bind/db.192.168.0 Añadir para el DNS inverso de una LAN
/etc/bind/named.conf Configuración del servidor DNS BIND
/etc/bind/named.conf.local Define zonas locales en el servidor DNS BIND
/etc/bind/named.conf.options Define las opciones del servidor DNS BIND
/etc/samba/smb.conf Configuración del servidor Samba
/etc/smbpasswd Contiene los passwords de los usuarios Samba
/etc/smbusers Contiene una lista de los usuarios del sistema y su corresponden-
cia con su usuario Samba
/etc/lmhosts Interfaz entre los nombres de maquinas NetBIOS y las direcciones
IP numericas

Apéndice C. Archivos de configuración 323
/etc/printcap Impresoras del sistema
/var/spool/samba Cola de impresión, por defecto, en Samba
/var/spool/mail Correo de los usuarios
/etc/dumpdates Información de las copias de seguridad realizadas
/<particion>/quota.group Archivos de configuración de quotas de grupo
/<particion>/quota.user Archivos de configuración de quotas de usuario
/etc/exports Archivo de configuración de NFS
/etc/jabber/jabber.xml Archivo de configuración del servidor Jabber
/etc/printcap Archivo de configuración de impresoras LPD
/etc/cups/cupsd.conf Configuración del servidor Cups
/var/run/cups/printcap Archivo de configuración de impresoras Cups
/var/spool/cups Directorio donde se almacenan los archivos que se van a imprimir
/etc/apache/httpd.conf Archivos de configuración de Apache
/etc/apache/modules.conf
/etc/apache/access.conf
/etc/apache/srm.conf
/etc/apache/mime.types
/etc/apache/conf.d/ Directorio de configuración de los módulos Apache
/etc/apache-ssl/* Los mismos archivos de configuración, para Apache-SSL
/var/log/apache/* Directorio donde se almacenan los logs, generados por Apache
/etc/webalizer.conf Archivo de configuración de Webalizer
/var/www/webalizer Reportes de estadisticas web
/etc/exim4/exim4.conf.template Archivo de configuración de Exim4
/var/mail/<usuario> Archivo de correo de los usuarios del sistema
/etc/mailname Direcciones de correo locales
/etc/aliases Alias de nombres de usuario
/etc/email-addresses Direccion de correo del servidor
/etc/fetchmailrc Archivo de configuración del servidor Fetchmail
˜/.fetchmailrc Archivo de configuración de usuario Fetchmail
/etc/courier/imapd Archivo de configuración de courier-imap
/etc/courier/imapd.cnf Opciones de courier-imap
/etc/courier/imapd-ssl Opciones de courier-imap-ssl
˜/.mailfilter Configuración de usuario Maildrop
/etc/procmailrc Archivo de configuración del servidor Procmail
˜/.procmailrc Archivo de configuración de usuario Procmail
/etc/clamav/clamd.conf Archivo de configuración de ClamAV
/etc/default/spamassassin Configuración del SpamAssassin
/etc/default/spampd Configuración del demonio de SpamAssassin

Apéndice D
¿Por qué Debian no tiene rc.local ?
A diferencia de otras distribuciones Linux, parece que Debian no usa rc.local (el archivo de configuración
local) para el proceso de inicialización. Entonces, ¿qué facilidades suministra Debian para esta tarea?
Runlevels
Tradicionalmente en los sistemas UNIX/LINUX, cuando se inicia la máquina, el proceso “init” (que
es ejecutado por el kernel cuando termina su arranque) ejecuta una serie de scripts de inicio, los cuales
suelen encargarse de “setear” valores de configuración y ejecutar diversos programas.
Dicho proceso de arranque se separa en runlevels, que son simplemente números que identifican cada
etapa, y en general van del 0 al 6, los números del 7 al 9 también están definidos pero no se suelen usar.
Hay una excepción, el runlevel s, que es el “single user mode”, y se suele usar para tareas especiales
de rescate y/o mantenimiento inesperado.
Hoy en dı́a, las distribuciones manejan cada una sus scripts de arranque de forma particular, y muchas
veces se manejan de forma alternativa sin tener runlevels claramente definidos como hasta hace unos años.
En algunas, se pueden encontrar los directorios /etc/rc#.d/, donde # representa al número de runlevel ;
en otras están todos los scripts contenidos en /etc/rc.d o en /etc/init.d. Lo mas aconsejable en cada caso
es consultar la documentación de cada distribución.
Podemos cofigurar gráficamente los scrips de RunLevel con la herramienta: #ksysv
Insertar un script en el arranque

Supongamos que un sistema necesita ejecutar el script exemple al inicializar, o al entrar en un runlevel
en particular. Entonces el administrador del sistema deberı́a:
Colocar el script exemple en el directorio /etc/init.d/
Ejecutar la orden update-rc.d con los argumentos apropiados para preparar enlaces entre los directo-
rios rc?.d (especificados desde la lı́nea de comandos) y /etc/init.d/exemple. Aquı́, ‘?’ es un número
que corresponde a un runlevel estilo System V
La orden update-rc.d 1 creará enlaces entre ficheros en los directorios rc?.d y el script en /etc/init.d/.
Cada enlace comenzará con una ‘S’ o una ‘K’, seguida de un número, seguido por el nombre del script. Los
scripts que comiencen con ‘S’ en /etc/rcN.d/ serán ejecutados al entrar al runlevel N. Los que lo hagan
con con una ‘K’ serán ejecutados al dejar el runlevel N.
1 Para tener disponible el comando update-rc.d hay que realizar un apt: #apt-get install rcconf
Uno podrı́a, por ejemplo, obligar al script exemple a ejecutarse en el arranque, poniéndolo en /etc/init.d/
e instalando los enlaces con #update-rc.d exemple defaults 19. El argumento ‘defaults’ se refiere a los
runlevels predeterminados, que son los que van del 2 al 5. El argumento ‘19’ se asegura de que exemple
sea llamado antes que cualquier otro script que contenga el número 20 o un número mayor.
Si necesitamos administra este tipo de archivos de runlevel podemos instalar con apt, el siguiente pa-
quete: #apt-get install rcconf
Para ejecutarlo intruduciremos el comando: #rcconf
Mostrará un menú gráfico desde donde podremos habilitar o deshabilitar servicios en la carga inicial
del sistema.
Insertar un script, mediante el asistente gráfico

Se pueden agregar scrips de forma gráfica, mediante nuestra herramienta de configuración web: Web-
mail. En la figura D.1 podemos observar el método para agregar un scrip nuevo.
Figura D.1: Interfaz gráfica Webmin para agregar Runlevels

Apéndice E
Puertos por defecto
El n.o de puertos a los que podemos acceder en cada hosts es de 65.536 (216 ). Estos puertos están
divididos en tres secciones:
Los puertos IANA: Son los 1024 primeros puertos del PC. La organización IANA (Internet As-
signed Numbers Authority) adjudicó a cada uno de estos puertos una utilidad, protocolo,. . . para
estandarizar la comunicación.
Los puertos Registrados: Son aquellos comprendidos entre el 1.024 y el 49.151 asignados a protocolos,
programas, . . . Pero no se encuentran estandarizados.
Los puertos privados: Son los que van del 49.152 y el 65.535. Sobre ellos no recae ningún uso par-
ticular y son utilizados para uso privado de los hosts y programas locales.
Si necesitamos más información, sobre la asignación de puertos la podemos consultar en la RFC1700

que data de Octubre de 1994, disponible en la dirección: http://www.ietf.org/rfc/rfc1700.txt.
También existe otro “malicioso” grupo de puertos, son los puertos por defecto de los troyanos. Se
utilizan para establecer la comunicación servidor-cliente entre los ordenadores implicados en la misma. Al
existir troyanos que permiten utilizar utilizar otros puertos , la identificación de los mismos puede no ser
infalible, si bien la mayorı́a de los usuarios de troyanos no se molestan en cambiar los puertos y utilizan
los puertos por defecto. Si necesitamos más información, en la siguiente página web podemos encontrar la
mayorı́a de puertos de troyanos: http://webs.ono.com/usr026/Agika2/2troyanos/puertos troya.htm
Y para terminar con esta sección, podemos observar los puertos que hemos utilizado en este proyecto:
Servicio Puerto Servicio Puerto

FTP 21 SAMBA 901
SSH 22 NESSUS 1241
TELNET 23 RADIUS SERVER 1812
DNS 53 (UDP) HORDE 2095
DHCP SERVIDOR 67 (UDP) HORDE (SSL) 2096
DHCP CLIENTE 68 (UDP) SQUID 3128
TFTP 69 JABBER CLIENTE 5222
WEB (HTTPS) 80 JABBER SERVIDOR 5269
HTTPS 443 WEBMIN 10000
CUPS 631
Apéndice F
Manual del editor Vim (Vi mejorado)
Personalmente utilizo el editor Vim frente al editor Emacs, este último es más completo y tiene más
opciones, pero no me son útiles. Prefiero un editor potente y a la vez simple (Vim es muy simple, una vez
conocidos los comandos básicos).
Tiene dos modos de trabajo, el modo comando y el modo inserción. Me voy a centrar, principalmente
en el modo comando debido al gran número de opciones disponibles.
Edición de ficheros
Para editar un fichero simplemente hay que hacer:
$vi <archivo>, . . . en caso de que no exista se creará.
Modo inserción
Al editar un fichero entramos en el modo comando por defecto, si lo que queremos es entrar en el modo
inserción, tenemos varias opciones:
a: Añadir a partir del siguiente carácter
i: Insertar a partir del carácter actual
o: Insertar una lı́nea debajo de la actual y comenzar allı́ la inserción
El modo inserción no tiene muchos secretos, se puede escribir lo que se quiera y luego volver al modo
comando, pulsando la tecla Esc.
Modo comando
El modo comando del vim tiene multitud de opciones, pasemos a detallar las más utilizadas:
u: Deshacer la última acción. Cabe destacar que en Vim, a diferencia de otros editores se pueden
deshacer infinitos cambios, ya que esta opción no tiene lı́mite
CTRL+r: Rehace la última acción deshecha con “u”
w: Guardar
w!: Fuerza a guardar (es recomendable usar esta opción)

q: Salir, si no se ha guardado bloquea la salida

q!: Fuerza a salir sin guardar
x: Guardar y salir
x!: Guardar y salir, forzando la escritura.
e fichero: Abre el fichero
dd: Elimina la lı́nea sobre la que está el cursor
x: Suprime el carácter siguiente a donde esta el cursor

<numero>yy: Copia una cantidad de lı́neas igual a número
p: Pegar lı́neas
/cadena: Busca ‘cadena’ en el texto sobre el que trabajamos

n: nueva búsqueda sobre la última cadena especificada
:<numero> : Va a la lı́nea identificada por el número
%s/cadena/nueva cadena: Se usa para sustituir ‘cadena’ por ‘nueva cadena’ en el texto, esta opción
es especialmente útil
r fichero: Vuelca el contenido de fichero sobre la posición actual del cursor
!comando: Inserta la salida de un comando ejecutado. Por ejemplo si hacemos !ls inserta la salida
de ls en nuestro fichero.
. (punto): Repite el último comando
Personalización del Vim

Se puede personalizar Vim mediante un archivo de configuración, el ˜/.vimrc. En dicho fichero tenemos
una serie de opciones que podemos activar o desactivar según lo que prefiramos, las principales son:
syntax on: Activa el coloreado de sintaxis, muy útil para programadores

set nobackup: Evita que se creén copias de seguridad cada vez que editemos un fichero
set showmode: Muestra siempre en que modo estamos trabajando (comando o inserción)
set ruler: Muestra una regla con información en la parte inferior de la consola
set vb: Desactiva el molesto “pitido” y lo sustituye por un parpadeo de pantalla
set ignorecase: No diferencia entre mayúsculas y minúsculas
set showmatch: Es útil para realizar búsquedas, resaltará los resultados coincidentes con el patrón.
au BufReadPost * if line ("""")lexecute(normal’"")|endif: Posiciona el cursor en donde se
encontraba la última vez que editamos el fichero
Basado en un manual publicado en Todo-Linux, puede ser consultado en la siguiente dirección:
http://www.todo-linux.com/modules.php?name=News&file=article&sid=2162

Apéndice G
Guı́a rápida de IPTables
IPTables es una herramienta para filtrar paquetes del kernel (2.4x o posterior).
Comandos básicos
IPTables es la evolución de ipchains y ipfwadm y básicamente permite o rechaza los paquetes que
llegan al host desde una red.
Cadenas (chains) predefinidas:
• INPUT: Los paquetes que llegan a nuestra máquina

• OUTPUT: Los paquetes que salen de nuestra máquina
• FORWARD: Los paquetes que atraviesan nuestra máquina
Las opciones básicas:
• -s: Especifica una dirección de origen

• -d: Especifica una dirección de destino
• --sport: Puerto de origen
• --dport: Puerto de destino
• --tcp-flags mascara activos: Flags permitidos (máscara) y flags activos
• -m: Módulo de opciones (Vease $man iptables)
• -f: Paquetes fragmentados
• -t: Especifica la tabla (filter, nat o mangle)
• -p: Especifica un protocolo
• -i: Especifica un interface de entrada
• -o: Especifica un interface de salida
• -j: Especifica la acción a ejecutar sobre el paquete
Acciones:
• DROP: Elimina el paquete

• LOG: Registra el paquete
• REJECT: Rechaza el paquete
• ACCEPT: Acepta el paquete
Comandos fundamentales:
• iptables -L, . . . ver las reglas introducidas
• iptables -F, . . . borrar todas las reglas
Con #man iptables tenemos todas las opciones.
Ejemplos
Eliminamos todas los paquetes de entrada y salida:
iptables -A INPUT -j DROP
iptables -A OUPUT -j DROP
Aceptamos que se conecten a nuestro servidor Web(80) y FTP(21):
iptables -A INPUT -p TCP --dport 80 -j ACCEPT
Permitimos la comunicación con el servidor DNS:
iptables -A INPUT -p udp --dport 53 -j ACCEPT
Script muy básico de IPTables para dar acceso al 80 y al 22:
#!/bin/bash
# Permitimos que se conecten a nuestro servidor web y al ssh
# Permitimos la comunicacion con el servidor dns
iptables -A INPUT -p udp --dport 53 -j ACCEPT
# Reglas basicas. Denegamos todas las entradas permitimos todas las salidas
iptables -A INPUT -j DROP
iptables -A OUTPUT -j ACCEPT
Si queremos poner la máquina como firewall con dos interfaces de red, eth0 y eth1:
• Activamos el ip forward:
echo 1 > /proc/sys/net/ipv4/ip_forward
• Hacemos el NAT de las direcciones de fuera y permitimos la salida:
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -o eth1 -i eth0 -j ACCEPT
• Sólo permitimos que la red interna acceda a los puertos 25 y 80 de la red externa:
iptables -A FORWARD -s 192.168.0.0/24 -p TCP -j DROP
iptables -A FORWARD -s 192.168.0.0/24 -p TCP --dport 25 -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -p TCP --dport 80 -j ACCEPT
Si queremos hacer un proxy transparente para la salida de la red interna, es decir abrir un puerto
de salida en el router:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport [puerto_externo]
-j DNAT --to [IP_maquina]:[puerto_maquina]
Si queremos denegar un rango concreto de IPs:
iptables -A INPUT -s 195.76.238.0/24 -j DROP
iptables -A INPUT -s 217.116.0.144 -j DROP

Debian Sarge, nueva versión estable
En el proyecto Debian, Sarge ha sido congelada y en breve será la nueva versión ‘stable’ de Debian. La
versión testing pasara a llamarse Etch y será una versión real “en pruebas” ya que Sarge llevaba mucho
tiempo entre los usuarios y ya esta muy probada.
Para tener nuestro servidor es necesario tener una versión estable y no en pruebas, hemos de modificar
nuestro /etc/apt/sources.list para que no nos cambie de versión automáticamente.
En estos momentos mi archivo /etc/apt/sources.list contiene las siguientes entradas:

deb http://ftp.rediris.es/debian testing main contrib non-free
deb-src http://ftp.rediris.es/debian/ testing main non-free contrib
deb http://ftp.rediris.es/debian-non-US testing/non-US main contrib non-free
deb-src http://ftp.rediris.es/debian-non-US testing/non-US main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
Para que mi sistema siga siendo Sarge, aunque dentro de unos dı́as lo hará en la nueva etapa como
estable, deberemos cambiarlo por este otro:
deb http://ftp.rediris.es/debian sarge main contrib non-free

deb-src http://ftp.rediris.es/debian/ sarge main non-free contrib
deb http://ftp.rediris.es/debian-non-US sarge/non-US main contrib non-free
deb-src http://ftp.rediris.es/debian-non-US sarge/non-US main contrib non-free
deb http://security.debian.org/ sarge/updates main contrib non-free
Y realizar un: #apt-get update
Si dejamos el archivo /etc/apt/sources.list como “testing”, nuestro sistema dejará de ser Sarge, y pa-
sará a ser Etch.
También querı́a recordar que existe una tercera versión de Debian: Debian Sid o “unstable”, que es la
versin inestable. Esta versión siempre se llamará ası́: “Sid” y no es adecuada para el uso de servidores, ya
que esta destinada a desarrollar el software que luego pasará al resto de versiones.
Desde la página oficial de Debian podemos obtener los siguientes datos:

Desde el 3 de mayo de 2005, las actualizaciones de seguridad de la distribución “en pruebas” las
gestiona el equipo de seguridad. Por tanto, esta distribución dispone de oportunas actualizaciones
de seguridad. Esta situación es temporal, ya que la distribución en pruebas está congelada.
La fecha de publicación, inicialmente prevista para el 30 Mayo, se ha pospuesto una semana, y pasa
a ser el 6 de junio de 2005.
Como es usual, las metas de la versin y la fecha en la que se hará pública no se determinan con
antelación. En otras palabras, “Debian publica la nueva versión cuando es el momento de hacerlo”.
Los mayores cambios para Sarge incluyen reemplazar el antiguo sistema de instalación con discos
flexibles, por el nuevo instalador de Debian, y usar GCC 3.3 como el nuevo compilador predeter-
minado en arquitecturas que hasta ahora usaban la versión 2.95. También se ha llevando a cabo la
introducción de nuevas versiones de programas como son Perl 5.8 y XFree86 4.3.
Como despedida solo cabe decir, que acerte de pleno en la planificación y la elección de Debian
Sarge fue primordial para que este documento sirva como ayuda durante un largo tiempo a los nuevos
“administradores junior”, sitio en el cual humildemente me ubico.

Licencia Creative Commons:
Reconocimiento-CompartirIgual
Gracias a la Universidad de Barcelona y en particular a Ignasi Labastida i Juan y a la colaboración de

un grupo de abogados de reconocido prestigio disponemos hoy por hoy de las licencias creative commons,
no meramente traducidas al castellano y al catalán, sino también y sobre todo, adaptadas a la legislación
española.
Con demasiada frecuencia, la visión sobre la protección de de obras creativas tiende a los extremos.
Por una lado tenemos la concepción en la cual cualquier posible uso de una obra debe estar regulado al
milı́metro; cuyo máximo exponente en nuestro paı́s quizá sea la cada vez menos querida SGAE
Por otro lado tenemos la anarquı́a total. Una visión en la que los creadores tienen total libertad para
hacer lo que les dé la gana, pero en la que no tienen absolutamente ninguna protección.
Creative commons surge como una solución de compromiso entre ambas posturas. De esta forma, los
creadores pueden elegir qué derechos quieren reservarse y qué usos de su obra quieren permitir. Ası́ se cons-
truye una capa de protección que ofrece una alternativa razonable y flexible a la cada vez más restrictiva
normativa en cuestión de propiedad intelectual.
En diciembre de 2002, Creative Commons lanza el primer conjunto de licencias, que cualquier a puede
utilizar de forma completamente gratuita para proteger sus creaciones.
Las licencias de Creative Commons se inspiran en la licencia a GPL de la Fundación para el Software
Libre; pero, al contrario ésta, las licencias Creative Commons no están pensadas para software, sino para
otros tipos de trabajos creativos: páginas web, tesis doctorales, música, pelı́culas, fotografı́as, literatura,
cursos . . .
Como escoger una licencia

Para que la selección de licencias resulte fácil para todo el que quiera proteger sus obras sin necesidad
de saber nada de Derecho, han creado una herramienta online, diponible en Castellano y Catalán que te
permite ir eligiendo el tipo de protección que quieres para tu trabajo y en función de las opciones que
escojas, te ofrece la licencia más adecuada.
http://creativecommons.org/license/?lang=es, . . . herramienta en castellano.

http://creativecommons.org/license/?lang=ca, . . . herramienta en catalán.
0 Estos datos han sido obtenidos de la web http://www.elcuaderno.info, acogida a la licencia http://creativecommons.org/
/licenses/by-sa/2.0/, “Reconocimiento-CompartirIgual” la misma bajo la que se encuentra este proyecto, el autor no se cita
al no figurar en el articulo.
Creative commons no supone renunciar a proteger tu trabajo, sino que implica que puedes escoger
qué derechos prefieres reservarte y qué derechos quieres ceder a los demás.
Tú decides en qué condiciones estás dispuesto a permitir la utilización de tu trabajo, combinando las
distintas condiciones que puedes imponer, hay hasta once tipos de licencias distintas de las que escoger
(adaptadas a nuestra legislación, en este momento hay 6).
Estas son las condiciones que se pueden escoger:

Attribution/Reconocimiento: Permites que otras personas puedan copiar, distribuir y comunicar
púlicamente la obra ası́ como hacer obras derivadas, incluyendo el hacer un uso comercial de tu obra.
Siempre que:
• Te citen y te reconozcan como el autor original de la obra.
• Al reutilizar o distribuir la obra, tienen que dejar bien claro los términos de la licencia la obra
Noncommercial/No comercial : Permites que otras personas puedan copiar, distribuir y comu-
nicar púlicamente la obra ası́ como hacer obras derivadas. Siempre que:
• No utilicen tu obra con fines comerciales
No Derivative Works/Sin obra derivada: Permites que otras personas puedan copiar, distribuir
y comunicar púlicamente la obra, incluidos los posibles usos comerciales de la obra. Siempre qué:
• No se alterare, transforme o genere una obra derivada a partir de tu obra.
Share Alike/Compartir igual : Permites copiar, distribuir y comunicar púlicamente la obra, hacer
obras derivadas y hacer un uso comercial de esta obra. La distribución de las obras derivadas se
permite única y exclusivamente cuando la obra derivada utilice una licencia idéntica que la que tiene
el trabajo original.
No se pueden combinar las condiciones “compartir igual” y “sin obra derivada”, puesto que la con-
dición “compartir igual” sólo es aplicable a las obras derivadas.
Una vez que has escogido las condiciones que quieres, accedes a la licencia apropiada de tres maneras:
Resumen simple: Un resumen en un lenguaje simple que todo el mundo puede entender, junto con
los iconos representativos de la licencia.
Código legal: el texto completo de la licencia dirigido fundamentalmente a abogados.
Código digital: Una versión de la licencia legible por máquinas que ayudará a las herramientas de
búsqueda y otras aplicaciones a identificar tu trabajo en función de sus condiciones de uso.

Apéndice G. Guı́a rápida de IPTables 337
Cómo se utiliza la licencia

Una vez elegida la licencia, obtendremos un código HTML, que una vez pegado en la página web
generará un botón.
El botón “some rights reserved”, indica que los contenidos del sitio web están protegidos por una
licencia Creative commons. El botón enlaza con el resumen de la licencia que utilizas para proteger tus
contenidos. De esta forma, comunicando públicamente los términos de tu licencia si alguien infringe los
mismos, estás protegido jurı́dicamente y puedes interponer una demanda en defensa de tus derechos de
propiedad intelectual.
Creative commons no es un bufete de abogados ni proporciona asesoramiento jurı́dico en caso de in-
fringimiento de los términos de una licencia. Si se da el caso, tendrás que acudir a un abogado, los que
yo conozco? Supongo que los mismos que todo el mundo: Javier Mestre y Carlos Sánchez Almeida del
bufete Almeida (http://www.bufetalmeida.com). En la lista de correo sobre licencias creative commons en
español, participan varios abogados, quizá allı́ puedes preguntar qué bufete hay cerca de dónde vives que
esté especializado en estos temas.
Las seis posibles combinaciones adaptadas a la legislación española son:

1. Reconocimiento
2. Reconocimiento-SinObraDerivada
3. Reconocimiento-NoComercial-SinObraDerivada
4. Reconocimiento-NoComercial
5. Reconocimiento-NoComercial-CompartirIgual
6. Reconocimiento-CompartirIgual
Licencia escogida
Por el carácter abierto y libre de este proyecto, para elegir la licencia se voy a seguir el espı́ritu de
GNU y sus licencias: GPL para software y GFDL (GNU Free Document) para documentación.
Por eso cedo el derecho de realizar una explotación económica de la obra, a condición de que, esa obra
modificada o derivada este bajo la misma licencia que la primera y en ella se me cite como autor original.
Es decir, para el PFC: “Servidor Linux para conexiones seguras de una LAN a Internet”, he escogido
la licencia CC - “Reconocimiento-CompartirIgual”.
La asignación de este tipo de licencia “Creative Common” respecto a GFDL, está justificada debido a
que, en mi opinión, GFDL tiene un gran fallo, no permite realizar modificaciones de la obra y publicarlas
bajo el mismo nombre y en mi caso, esta obra se deberá actualizar con el tiempo, ya sea por mı́ o por
alguna otra persona que continúe el proyecto. No quiero que el PFC nazca y muera igual, prefiero donarlo
a la comunidad y permitir que se pueda modificar y actualizar con el tiempo.
Creative Commons, me ha facilitado el siguiente párrafo para cualquier persona que necesite más
información sobre la licencia:
“Esta obra está bajo la licencia de Atribución de Creative Commons: Reconocimiento-CompartirIgual
2.1 España. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-sa/2.1/es/
o envie una carta a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.”

Resumen simple de la licencia del PFC
Figura G.1: Licencia Reconocimiento-CompartirIgual
Esto es un resumen legible del texto legal, la licencia completa se encuentra disponible en la dirección:
http://creativecommons.org/licenses/by-sa/2.1/es/legalcode.es

Páginas Web consultadas
http://acidlab.sourceforge.net/ - Consola de análisis de Bases de datos de intrusiones (ACID)

http://airsnort.shmoo.com/ - Web oficial de AirSnort
http://apostols.org/projectz/neped/ - Web oficial de NePED, detector de sniffers
http://barrapunto.com - Web de noticias sobre informática
http://bogofilter.sourceforge.net/ - Página web de Bogofilter
http://bulma.es - Comunidad de usuarios Linux, multitud de artı́culos
http://bulma.net/body.phtml?nIdNoticia=1334 - Manual de configuración DNS BIND 9.2.1
http://cauchy.bdat.net/dns/bind-9/DNS-HOWTO-9-es/ - DNS Como
http://certisign.com.br/servidores - Entidad de certificación
http://deim.etse.urv.es/ajuda/manuals/vi/ - Manual del vi
http://docs.kde.org/es/HEAD/kdegraphics/ksnapshot/ - Manual de KSnapshot
http://download.jabber.org/ - Pluggins para jabber
http://eia.udg.es/˜atm/tcp-ip/index.html - Documentación sobre TCP/IP
http://enterprise.bidmc.harvard.edu/pub/nessus-php/ - Interfaz PHP para Nessus
http://es.tldp.org - Proyecto Lucas, documentación Linux en español
http://es.tldp.org/Tutoriales/NOVATO/novato-a-novato/novato-a-novato.html - Manual del novato
http://es.wikipedia.org - Wikipedia, la enciclopedia libre
http://gimp.hispalinux.es - Grupo de usuarios Españoles de GIMP
http://gsyc.escet.urjc.es/robotica/apuntes/captura video COMO.pdf - COMO capturar video
http://his.sourceforge.net/trad/honeynet/ - Proyecto HoneyNet en castellano
http://hostap.epitest.fi/wpa supplicant/ - HowTo wpa supplicant
http://httpd.apache.org/ - Apache HTTPD Server Project
http://kile.sourceforge.net/ - Web oficial Kile
http://latex2rtf.sourceforge.net/ - Convertidor de Latex a Rtf
http://laura.celdran.name/ - HowTos Laura Celdran
http://losinvisibles.net/como/como.html - Mini Como’s de Simon
http://oriol.joor.net/article fitxers/1574/WXP-WAP-EAPTLS.pdf - Conectar WinXP a Radius
http://packages.debian.org/testing/ - Guı́a completa de paquetes Debian Sarge
http://patux.glo.org.mx/imp-mini-como.html - HowTo sobre IMAP
http://prosper.sourceforge.net/ - Web oficial de Prosper
http://sourceforge.net/projects/airsnort - Proyecto SourceForge AirSnort
http://spamassassin.apache.org/ - Página web de SpamAssassin
http://tira.escomposlinux.org/ - Tira cómica Linux
http://tldp.org/HOWTO/html single/8021X-HOWTO/ - HowTo 802.1x
http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/ - HowTo oficial de Samba
http://webadminmodules.sourceforge.net/ - Módulos para Webmin
http://webs.ono.com/usr026/Agika2/2troyanos/puertos troya.htm - Puertos de Troyanos
http://www.apache.org/ - Página Web del Proyecto Apache
http://www.apache-ssl.org/ - Página Web del Proyecto Apache-SSL
http://www.bastille-linux.org - Web de Bastille Linux
http://www.bufetalmeida.com - Bufete Almeida, especializado en ciberderechos
http://www.canariaswardrive.org/ - 1.er campeonato de Wardriving en España
http://www.catb.org/ esr/fetchmail/ - Página web de Fetchmail
http://www.catcert.net/ - Agencia catalana de certificación

http://www.cert.org/ - Agencia seguridad en Internet CERT (Computer Emergency Response Team)
http://www.cervantex.org - Comunidad de usuarios españoles de TEX
http://www.chkrootkit.org/ - Web de chkrootkit
http://www.clamv.net - Web oficial del antivirus de correo ClamV
http://www.compuamersa.com/linux.htm - Sobre las distribuciones
http://www.courier-mta.org/ - Página web de Courier
http://www.cypherspace.org/openpgp/ - Implementaciones de OpenPGP
http://www.debian.org - Web oficial de Debian
http://www.debian.org/distrib/ - Métodos de la distribución Debian
http://www.debian.org/doc/ - Documentación rápida para Debian
http://www.debian.org/doc/manuals/apt-howto/index.es.html - APT HowTo, en español
http://www.debian.org/doc/manuals/securing-debian-howto/index.es.html - Manual de seguridad
http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html - Recompilación Kernel HowTo
http://www.distrowatch.com/index.php?language=ES - Todo sobre distribuciones
http://www.dslreports.com/forum/remark,9286052 mode=flat - Conectar WinXP a Radius (Ingles)
http://www.elcuaderno.info/ - Web de noticias
http://www.entrust.net - Entidad de certificación
http://www.escomposlinux.org/ - Grupos de noticias de Linux
http://www.exim.org/ - Página web de Exim
http://www.faqs.org/docs/iptables/index.html - Tutorial IPTables (Inglés)
http://www.freeradius.org/ - FreeRadius
http://www.gimp.org - Web oficial de The Gimp
http://www.gnome.org/ - Web de GNOME
http://www.gnupg.org - Web oficial de GnuPG
http://www.gwolf.org/seguridad/portsentry/ - Manual de uso PortSentry
http://www.gwolf.org/seguridad/logcheck/ - Manual de uso Logcheck
http://www.honeyd.org - Web oficial de Honeyd
http://www.horde.org/ - Página web de Horde
http://www.icewalkers.com/Linux/Howto/ - HowTos en español
http://www.ietf.org/rfc/rfc1700.txt - Puertos estandarizados por la IANA
http://www.iks-jena.de/produkte/ca - Entidad de certificación
http://www.imendio.com/projects/planner/ - Web oficial Planner
http://www.insecure.org/nmap/ - Escaner de puertos
http://www.isc.org/index.pl?/sw/bind/ - Página oficial de Bind
http://www.jabber.org/ - Página web oficial de Jabber
http://www.jabberes.org/ - Página de usuarios de Jabber españoles
http://www.kde.org/ - Web de KDE
http://www.kernel.org - Fuentes oficiales
http://www.kismetwireless.net - Web oficial Kismet Wireless
http://www.latex-project.org/ - Web oficial de LATEX
http://www.lids.org/ - Linux Intrusion Detection System
http://www.linux.cu/manual/basico-html/node120.html - Definición de tareas periódicas
http://www.linuxdocs.org - HowTos
http://www.linuxdocs.org/HOWTOs/Kernel-HOWTO.html - Kernel HowTo
http://www.linuxguruz.com/iptables/ - Manuales sobre IPTables
http://www.linuxlots.com/˜barreiro/spain/cuota.html#toc1 - Cuotas de usuario
http://www.linuxzamora.org - Web de usuarios de Linux
http://www.llibreriaha.com/cas/index.asp - Librerı́a técnica online de Barcelona
http://www.missl.cs.umd.edu/wireless/eaptls/ - HowTo EAP-TLS en WPA
http://www.nessus.org/ - Herramienta de búsqueda de vulnerabilidades
http://www.netfilter.org - Web oficial de IPTables
http://www.netsecuritysvcs.com/ncc/ - Herramienta gráfica para Nessus
http://www.nodedb.com/europe/es - Web de nodos wireless

Apéndice G. Guı́a rápida de IPTables 341
http://www.openssh.org - Web de OpenSSH

http://www.packetfactory.net/Projects/sentinel/ - Web oficial de Sentinet, detector de sniffers
http://www.planetplanner.org/ - Comunidad de usuarios de Planner
http://www.procmail.org/ - Página web de Procmail
http://www.proftpd.org/ - Web oficial del proyecto ProFTPD
http://www.samba.org/samba/docs/ - Documentación sobre samba
http://www.snort.org - Web oficial de Snort
http://www.thawte.com - Entidad de certificación
http://www.tldp.org/HOWTO/BootPrompt-HOWTO.html - HowTo bootprompt en Debian Sarge
http://www.todo-linux.com/ - Manuales sobre linux
http://www.tripwire.org - Web oficial de Tripwire
http://www.verisign.com/site - Entidad de certificación VeriSign
http://www.webmin.com/ - Web de Webmin
http://www.wifimaps.com/ - Mapas de nodos wireless
http://www.xfree86.org/ - Web de XFree86
http://www.xombra.com - Articulos sobre Linux
http://www.zonagratuita.com/servicios/seguridad/snort.html - Snort + Acid en Windows
http://xvidcap.sourceforge.net - Proyecto Xvidcap

Bibliografı́a
[Ano00] Anonimo. Linux máxima seguridad. Pearson Prentice Hall, 2000.

[Aok05] Osamu Aoki. Guı́a de referencia Debian. http://qref.sourceforge.net, Febrero 2005.
[BB00] Albert Bernaus and Jaime Blanco. Linux a fondo. InforBook’s, 2000.
[BN00] Daniel Bandel and Robert Napier. Linux. Pearson Prentice Hall, sexta edition, 2000.
[CO03] Francisco Charte Ojeda. Programación GNU/Linux. Anaya Multimedia, 2003.
[CSLSMR+ 00] Bernardo Cascales Salinas, Pascual Lucas Saorı́n, José Manuel Mira Ros, Antonio José Pa-
llarés Ruiz, and Salvador Sánchez-Pedreo Guillén. LATEX: una imprenta en sus manos. Aula
Documental de Investigación, 2000.
[CSLSMR+ 03] Bernardo Cascales Salinas, Pascual Lucas Saorı́n, José Manuel Mira Ros, Antonio José Pa-
llarés Ruiz, and Salvador Sánchez-Pedreo Guillén. El libro de LATEX. Pearson Prentice
Hall, 2003.
[eidD04] El equipo instalador de Debian. Guı́a de instalación Debian GNU/Linux 3.1 para Intel x86.
http://www.debian.org, 2004. http://d-i.alioth.debian.org/manual/es.i386/index.html.
[How05] Tony Howlett. Software libre: Herramientas de seguridad. Anaya Multimedia, 2005.
[PRG+ 02] Bruce Perens, Sven Rudolph, Igor Grobman, James Treacy, and Adam Di Carlo. Insta-
lación Debian GNU/Linux 3.0 para Intel x86. http://www.debian.org, Diciembre 2002.
http://www.debian.org/releases/woody/installmanual.
[Sha01] Steve Shash. Manual de administración de Linux. Osborne McGraw-Hill, 2001.

[VF97] Gabriel Valiente Feruglio. Composición de textos cientı́ficos con LATEX. Ediciones UPC,
1997.
[vH02] William von Hagen. Sistemas de ficheros Linux. Pearson Prentice Hall, 2002.

Administracion e Instalacion de Servidores Linux - Debian Sarge 3 1 - by Jose Antonio Escartín

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Administracion e Instalacion de Servidores Linux - Debian Sarge 3 1 - by Jose Antonio Escartín

Uploaded by

Copyright:

Available Formats

Memoria del Proyecto

Jose Antonio Escartı́n Vigo

Motivación del proyecto

¿Qué ventajas tiene Linux sobre Windows?

¿Qué ventajas tiene Windows sobre Linux?

Las aplicaciones se desarrollan en menor tiempo.

Jose Antonio Escartı́n Vigo, Junio 2005.

Cuadro 1: Objetivos del proyecto

Estudiar el entorno de composición de textos LATEX

Analizar e instalar las distribuciones Linux más importantes

Realizar pruebas de seguridad del servidor

Jose Antonio Escartı́n Vigo, Junio 2005.

Requisitos mı́nimos Linux

Jose Antonio Escartı́n Vigo, Junio 2005.

4.3.3. Bases de datos de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Jose Antonio Escartı́n Vigo, Junio 2005.

7.3.1. ARP (Adress Resolution Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8. Configuración de dispositivos de red 79

III Instalación de Servicios 91

Jose Antonio Escartı́n Vigo, Junio 2005.

9.2.1. ¿Para qué necesitamos un DNS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

10.Servicios de usuario 133

Jose Antonio Escartı́n Vigo, Junio 2005.

10.4. Servidor de correo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

11.Comunicaciones seguras 177

12.Herramientas de seguridad 191

13.Sistemas de detección de intrusiones 213

Jose Antonio Escartı́n Vigo, Junio 2005.

13.4.1. Configuración apropiada del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 217

14.Redes inalámbricas 257

15.Servicio de administración por Web: WebMin 279

Jose Antonio Escartı́n Vigo, Junio 2005.

16.Servicios de monitorización del sistema 287

IV Valoración final 297

18.Estudio Económico 309

B. Debian en castellano 319

C. Archivos de configuración 321

D. ¿Por qué Debian no tiene rc.local ? 325

Jose Antonio Escartı́n Vigo, Junio 2005.

E. Puertos por defecto 327

F. Manual del editor Vim (Vi mejorado) 329

G. Guı́a rápida de IPTables 331

Debian Sarge, nueva versión estable 333

Licencia CC - Reconocimiento-CompartirIgual 335

Páginas Web 339

Jose Antonio Escartı́n Vigo, Junio 2005.

2.1. Planner, distribución de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7.1. IP, rango de direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

9.1. DHCP, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

10.1. Quota, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

10.13.Procmail, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

11.1. SSHD, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

12.1. Backups, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

13.1. Snort, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

14.1. Sı́mbolos urbanos de redes wifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

15.1. Webmin, pantalla de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

17.1. Nessus, configuración de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

D.1. Runlevels, módulo Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

G.1. Licencia Reconocimiento-CompartirIgual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Jose Antonio Escartı́n Vigo, Junio 2005.

1. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

2.1. Distribuciones Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1. Lilo, archivo de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26