Administracion e Instalacion de Servidores Linux - Debian Sarge 3 1 - by Jose Antonio Escartín
Administracion e Instalacion de Servidores Linux - Debian Sarge 3 1 - by Jose Antonio Escartín
Administracion e Instalacion de Servidores Linux - Debian Sarge 3 1 - by Jose Antonio Escartín
—–
Servidor Linux
para conexiones seguras de una LAN a Internet
—–
Junio de 2005
Introducción
En las siguientes lı́neas trato de describir los motivos que me llevaron a escoger un proyecto de este
estilo y de donde surgió la idea de realizar un documento informativo para facilitar la tarea de muchos
administradores de sistemas “noveles”, como yo cuando comencé este proyecto.
En esta pequeña introducción también se especifican los objetivos que se pretenden conseguir y para
entrar en materia se comenta, muy por encima, la historia de Linux.
Motivació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 él. Si bien es cierto que lo tenı́a instalado (una versión
Mandrake 9.0) lo utilizaba solamente para realizar las prácticas de la universidad y poca cosa más.
Siempre me han atraı́do los sistemas operativos, bastante más que la rama de programació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, básicamente programación) me cambié a la rama de sistemas.
Actualmente me encuentro cursando el PFC de la Ingenierı́a técnica en Informática de Sistemas y
tengo la intención de solicitar plaza de admisión en la Ingenierı́a superior de informá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 (Introducción a los sistemas operativos), SO (Sistemas Operativos), ASO (Administración de
sistemas operativos), CASO (Conceptos avanzados de sistemas operativos), SSI (Seguridad en sistemas
informáticos). Además hace unos años, antes de comenzar la carrera, realizaba trabajos de administrador
de sistemas en entornos Windows, para dos institutos (IES Pirá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 permitirá 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 Pé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
Es más rápido.
Al tener una plataforma más estable, se favorece la utilización de aplicaciones de todo tipo de
aplicaciones. La eficiencia de su código fuente hace que la velocidad de las aplicaciones Linux sean
superiores a las que corren sobre Windows.
Es más económico.
Ya que requiere menor mantenimiento. Los servidores Windows son más costosos debido a que es
necesaria una frecuente atención y monitoreo contra ataques de virus, hackers y errores de código.
El software Linux ası́ como también un sin número de aplicaciones, son de código abierto y están
protegidas por la licencia GPL1 , motivo por el que son distribuidas gratuitamente. No requieren
supervisión constante ni pagos de mantenimiento para obtener Service Packs, que no son más que
parches de seguridad para aplicaciones mal diseadas.
Es más fácil.
Al ser de mayor facilidad de uso Windows en este momento continúa siendo el sistema operativo más
comercial lo cual se refleja en la disponibilidad de aplicaciones, facilidad de mantenimiento ası́ como
soporte en el desarrollo de nuevas aplicaciones.
La alternativa más sencilla y a la vez más ineficiente es elegir un sistema operativo Windows. Lo que
se busca es seguridad, integridad de datos y eficiencia del sistema, por tanto nos decantarémos por una
distribución GNU/Linux.
El proyecto surge ante la necesidad de escoger entre las distribuciones Linux actuales, la má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 pública GNU. Segú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 código fuente completo, incluyendo cualquier modificación realizada. El paquete continua bajo
GPL y puede ser distribuido de modo libre y revendido de nuevo obteniendo también beneficio. Es de una importancia
primordial la cláusula de responsabilidad: los programadores no son responsables de cualquier daño causado por su software.
Objetivos
Este documento está elaborado para describir la implementació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 aprenderá a configurar un servidor GNU/Linux describiendo los principales
servicios utilizados para compartir archivos, páginas web, correo y otros que veremos más adelante.
La herramienta de configuración Webmin, que se detalla en uno de los últimos capı́tulos es indepen-
diente de la distribución GNU/Linux que utilicemos y nos permitirá administrar de forma transparente
diferentes distribuciones, con la ventaja que eso supone si alguna vez cambiamos de distribución.
Marco histórico
Como se especifica en [BB00], Linux hizo su aparición en 1991 cuando el finlandés Linus Torvalds deci-
dió publicar en Internet su proyecto de carrera, animando a la comunidad internacional de programadores
a mejorarlo. Nació como una mejora de Minix, una versió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 éxito de Linux es GNU1 que junto con la FSF2 (Free Software
Fundation), tratan de promover el desarrollo de programas cuyo código sea público y compartido. Una de
las principales aportaciones GNU fue Linux, un sistema operativo de libre distribución.
A partir de 1994 emperzaron a aparecer las primeras distribuciones de CD-ROM, junto con el código
fuente del sistema operativo, se disponı́a de diversas utilidades y aplicaciones sin tener que descargarlas.
Ese año aparecieron los primeros grupos locales de usuarios de Linux y la primera revista on-line especia-
lizada. Al año siguiente se empezó a trabajar en las primeras versiones de Linux para plataforma no Intel
y los primeros desarrollos de instaladores parcialmente automáticos. A partir de 1996 Linux comienza a
difundirse de forma más general en España, año en el que se inicia el proyecto de documentació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 número de fabricantes de software y hardware que
han mostrado un creciente interés.
1 GNU: GNU no es Unix. Definición recursiva que representa el humor informático en su máxima expresión
2 FSF: Fundació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 expresión, prensa y asociación en internet, el derecho a usar software criptográfico
en comunicaciones privadas y el derecho a escribir software sin los impedimentos del monopolio.
Linux soporta cualquier CPU compatible con los procesadores x86 de Intel, pudiéndose encontrar
versiones que funcionan con procesadores 680x0 de Motorola utilizados en ordenadores Amiga y Atari.
También son compatibles con Linux muchos ordenadores basados en Alpha, ciertas máquinas Sparc, las
máquinas basadas en PowerPC como por ejemplo los ordenadores Macintosh de Apple, ası́ como ARM,
MIPS y algunos tipos de agendas electrónicas, teléfonos y consolas de juegos.
Notas Previas
Se van a tomar varias la siguiente notación para el documento:
Cuando aparezcan frases que el usuario pueda introducir por teclado se hará notar por el tipo de
letra mecanográfica, Verbatim
Al hacer referencia a un comando que deba de ser introducido por una cuenta con privilegios de
root, irá precedido por el carácter “#”
Al hacer referencia a un comando que puede a ser ejecutado por un usuario cualquiera del sistema,
si tiene privilegios para ello, irá precedido por el carácter “$”
Cuando se muestran códigos el carácter “#” al inicio de la frase especifica que esa frase concreta es
un comentario dentro del có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
Introducción IV
I Tareas previas 1
1. Planificación 3
1.1. Fases del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Esquema temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Selección de Herramientas 9
2.1. Selección de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2. Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Selección de la distribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Distribuciones Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3. Distribución elegida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Selecció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 gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II Instalación base 19
3. Instalación de la distribució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. Actualizació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. Añadir nuevos usuarios al sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2. Añadir grupos al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
x Servidor Linux para conexiones seguras de una LAN a Internet
5. Kernel 45
5.1. ¿Por qué compilar? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2. Acerca de los mó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. Método de compilación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.4. Parchear el kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5.5. Consejos para la configuración del kernel . . . . . . . . . . . . . . . . . . . . . . . . 49
6. Interfaz gráfico 51
6.1. X-Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.1. Configuració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. Máscaras de red y notación de barra inclinada . . . . . . . . . . . . . . . . . . . . 64
7.2.4. Subneting (CIDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2.5. Enmascaramiento IP (NAT, Network Adress Translation) . . . . . . . . . . . . . . 66
7.3. Resolución de direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
19.Conclusiones 311
V Apéndices 315
A. Comandos básicos 317
Bibliografı́a 343
1.1. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Tareas previas
Capı́tulo 1
Planificación
El número de créditos asignados al proyecto es de 22,5 y decidı́ que cada crédito me supondrı́a una
carga de 20 horas, por lo tanto, la planificación ha sido realizada para un total de 450 horas.
Selección de Herramientas
En este capitulo explicaré cuales fueron las diferentes herramientas utilizadas para la elaboració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 distribución utilizada y los motivos que me llevaron a su elección
En la tercera fase se detalla qué herramientas de apoyo se usó para desarrollar los trabajos.
2.1.1. Servidor
Como servidor me decidı́ por la compra de un ordenador portátil, que permitiera desarrollar un servidor
portable con más utilidades habituales en los servidores fijos, ademá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 conexión y seguridad del
sistema queda garantizada gracias al sistema de validación de clientes.
El portá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 elección. El hardware era dema-
siado nuevo y esto provocó una serie de incompatibilidades que se fueron solucionando con la instalación
de drivers y parches que no se encontraban en las instalaciones Linux estándar.
El servidor realiza también la gestión de la conexión a internet. Esta conexió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 utilizarán varios PC’s de sobremesa, conectados mediante cable RJ45 a un switch.
PC AMD-Duron a 1,3 Ghz., también de mi propiedad, donde estará situado el principal cliente
Linux y Windows del sistema. En este ordenador se realizarón la mayoria de pruebas de conexión a
servicios.
10 Servidor Linux para conexiones seguras de una LAN a Internet
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 conexión de clientes
inalámbricos.
Los clientes se utilizaron simultáneamente para realizar las pruebas de carga una vez terminada la
implementación del servidor, para comprobar la efectividad del mismo.
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 má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
ú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 instalación.
Mepis y Mepis-LiveCD
Fue lanzada por Warren Woodford en julio de 2003. Mepis Linux es una fusión entre Debian Sid
y Knoppix, una nueva clase de distribución de Linux que se pueda utilizar como CD en vivo, y como
distribución completa con un instalador gráfico a disco duro. De esta manera, usuarios pueden probar el
producto simplemente “booteando” desde el CD de Mepis, e instalándolo luego a disco duro solamente
si les gusta. Muchas otras distribuciones copiaron esta idea más adelante, pero fue Mepis quien inició el
concepto de un CD vivo más un instalador gráfico completo partiendo de un CD.
¿A que se debe el é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 útiles, preconfigurados todos y
listos para utilizar. É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 después tener que buscar la documentación para descubrir
cómo permitir el uso de Java en sus navegadores. Todo está disponible después de la instalación.
Esta idea simple resultó ser enormemente popular, no solamente entre los usuarios nuevos de Linux,
sino también entre los más experimentados quienes encontraron muy conveniente el no tener que pasar
horas post-instalación configurando y afinando el sistema. Aparte de las aplicaciones estándard de Debian
y del software no-libre antes citado Mepis Linux tiene excelente auto-detección del hardware.
Gentoo (FreeBSD)
Gentoo Linux fue creada por Daniel Robbins, un conocido desarrollador de Stampede Linux y FreeBSD.
La primera versión estable de Gentoo fu anunciada en Marzo del 2002.
Gentoo Linux es una distribución basada en código fuente. Mientras que los sistemas de instalación
proveen de varios niveles de paquetes pre-compilados, para obtener un sistema Linux básico funcionando,
el objetivo de Gentoo es compilar todos los paquetes de código en la máquina del usuario. La principal
ventaja de esto es que todo el software se encuentra altamente optimizado para la arquitectura de la
computadora.
También, actualizar el software instalado a una nueva versión es tan fá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 distribución completa, con los últimos entornos gráficos,
multimedia y de desarrollo es un trabajo largo y tedioso, puede durar varios dı́as incluso en una máquina
rápida.
Slackware
Creada por Patrick Volkerding en 1992, Slackware Linux es la distribución má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 configuración gráfica.
Mientras otras distribuciones intentan desarrollar intarfaces fáciles de usar para muchas utilidades
comunes, Slackware no ofrece nada amistoso, y toda la configuración se realiza mediante los archivos de
configuració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 mágica para
muchos usuarios.
Es extremadamente estable y segura, muy recomendada para servidores. Los administradores con
experiencia en Linux encuentran que es una distribución con pocos fallos, ya que usa la mayorı́a de paquetes
en su forma original, sin demasiadas modificaciones propias de la distribución, que son un riesgo potencial
de añadir nuevos fallos. Es raro que se produzcan lanzamientos de nuevas versiones (aproximadamente una
al año), aunque siempre se pueden encontrar paquetes actualizados para descargar después del lanzamiento
oficial. Slackware es una buena distribución para aquellos interesados en profundizar en el conocimiento
de las entrañas de Linux.
Posiblemente, la mejor caracterı́stica de esta distribución es que si necesitas ayuda con tu sistema
linux, encuentra un usuario de Slackware. Es más probable que resuelva el problema que otro usuario
familiarizado con cualquier otra distribución.
Mandrake
Creada por Gal Duval, Mandrake Linux es una distribución que ha experimentado un enorme aumento
de popularidad desde su primera versión de julio de 1998. Los desarrolladores partieron de la distribución
de Red Hat, cambiaron el entorno de escritorio predeterminado por KDE, y añadieron un instalador fácil
de usar rompiendo el mito de que linux es difı́cil de instalar. Las herramientas de detecció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 distribució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 añaden
al directorio llamado ”cooker“ a diario. Cuando una nueva versió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 más largo y exigente. Las
listas de correo sobre la versión beta suelen estar saturadas, pero sigue siendo posible recibir una respuesta
rápida sobre cualquier fallo o duda que envı́es. Como resultado de este tipo de desarrollo se obtiene una
distribución puntera y altamente actualizada. Como contrapartida, los usuarios pueden encontrarse con
más fallos que en otras distribuciones.
Mucha gente encuentra este ’pero’ razonable para sus equipos, ellos obtienen las ú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 disposición de la gente desde réplicas en todo el
mundo.
Para muchos el nombre de Red Hat equivale a Linux, ya que probablemente se trata de la compañı́a
de linux más popular del mundo. Fundada en 1995 por Bob Young y Marc Ewing, Red Hat Inc. Sólo ha
mostrado beneficios recientemente gracias a otros servicios en lugar de a la distribución en si. Aun ası́,
Red Hat es la primera elección para muchos profesionales y parece que seguirá siendo un peso pesado
durante mucho tiempo.
Afortunadamente se resistieron a realizar ningún plan de rápida expansión durante el boom de las
punto-com durante los años 1998-1999, concentrándose en su negocio principal. Este tipo de gestión
prudente si sigue ası́, es propensa a garantizar estabilidad y dependencia..
¿Qué 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 más actuales, una vez se
anuncia una nueva versión beta, las versiones de los paquetes se mantienen, excepto para actualizaciones
de seguridad. Como resultado se obtiene una distribución bien probada y estable. El programa de betas
y las facilidades para enviar fallos están abiertas al público y hay un gran espı́ritu en las listas de correo
públicas.
Red Hat Linux se ha convertido en la distribución linux dominante en servidores en todo el mundo.
Otra de las razones del éxito de Red Hat es la gran variedad de servicios populares que ofrece la com-
pañı́a. Los paquetes de software son fácilmente actualizables usando la Red Hat Network, un repositorio
oficial de software e información. Una larga lista de servicios de soporte son accesibles en la compañı́a
y, aunque no siempre baratos, tienes virtualmente asegurado un excelente soporte de personal altamente
cualificado. La compañı́a ha desarrollado incluso un programa de certificación para popularizar su distribu-
ción, el RHCE (Certificado de Ingenierı́a de Red Hat), academias y centros examinadores está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 compañı́a orientada a los escritorios, aunque tiene variedad de otros productos para
empresas. La distribución ha recibido buenas crı́ticas por su instalador y la herramienta de configuración
YaST, desarrollada por los desarrolladores de la propia SuSE. La documentación que viene con las versiones
comerciales, ha sido repetidas veces evaluada como la más completa, útil y usable con diferencia a la de
sus competidores. SuSE Linux 7.3 recibió el premio ”Producto del año 2001”que entrega el Linux Journal.
La distribución tiene un gran porcentaje de mercado en Europa y Amé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 públicas para
probar. Siguen la polı́tica de no permitir descargar el software hasta tiempo después de que salgan a la
venta las versiones comerciales. A pesar de todo, SuSE no entrega imágenes ISO de fácil instalación de su
distribució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 ú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 distribución CD vivo de Linux basada en Debian y que utiliza como gestor de escritorio
KDE. Está desarrollada por el consultor de GNU/Linux Klaus Knopper. Gnoppix es una variante pero
incluye como entorno gráfico Gnome en vez de KDE.
A diferencia de la mayorı́a de las distribuciones Linux, no requiere una instalación en el disco duro;
el sistema puede iniciarse desde un simple CD de 700 MB. Además, Knoppix reconoce automáticamente
la mayorı́a del hardware del ordenador cuando se inicia. También puede ser instalado en el disco duro
utilizando un script de instalación. Y otra posibilidad de hacerlo má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 enseñar y demostrar de manera sencilla el sistema GNU/Linux, especialmente como sistema
operativo.
2.2.2. Pruebas
Los CD’s vivos arrancaron bien, sobre todo MEPIS con el que me llevé una grata sorpresa, muy simple
y funciona casi todo.
La distribución Ubuntu estaba claramente orientada a usuario final y no servidor que era mi objetivo,
de todas formas es una buena distribución que permite estar siempre actualizado.
Gentoo no la llegé a probar debido a las dificultades de instalación que representa la continua compi-
lación de paquetes, paso esencial en esta distribución. Es muy complicado dejarla a punto.
Debian y Slackware eran las distribuciones que más se ajustaron a los propó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, más bien al contrario, son las
distribuciones má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.3.1. Planner
Programa de gestió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
Gestión de tareas
Gestión de recursos
Diagramas de ghant
2.3.2. LATEX
Como se menciona en [CSLSMR+ 03] LATEX es un conjunto de sentencias escritas en un lenguaje
de programación llamado TEX. Este no es un lenguaje de programación usual, sino uno orientado a la
escritura de textos de excelente calidad. TEX no es un editor de la familia WYSIWYG, término empleado
para denominar a los editores que só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
acompañado de órdenes que el compilador, posteriormente, interpreta y ejecuta para proporcionar un
texto perfectamente compuesto.
A estas ventajas hay que añadir otra, es gratuito; Donald E. Knuth el creador de TEX, lo liberó en
Octubre de 1.990.
El entorno LATEX desarrollado por Leslie Lamport, lo creó en 1982, con la intención de simplificar la
tarea a aquellos que desean utilizar TEX. Añade a TEX una colecció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, dándoles un archivo base y unas directrices sobre la elaboración de los textos.
Una de las ventajas de LaTeX es que puede ser exportado muy fácilmente a Portable Document Format
(PDF) y PostScrip.
Utilizaré este entorno de composición de textos para desarrollar la documentació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.
Los comandos de LATEX están disponibles a través de menús, botones y combinaciones de teclas.
La ayuda integrada en el programa nos permitirá saber qué macro usar ante una necesidad concreta.
Para una edición cómoda de los ficheros de texto, contamos con resaltado de sintaxis, funciones de
búsqueda (incremental o no), reemplazo, deshacer, . . .
Los más de 370 sı́mbolos matemáticos posibles son accesibles mediante botones y menús.
Integración con herramientas externas para la visualización e impresión de los documentos editados
en distintos formatos: DVI, Postscript o PDF.
2.3.4. Prosper
La herramienta Prosper, desarrollada por F. Goualard y P.M.Neergaard es una clase para LATEX que
permite crear presentaciones electró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 proyección de vı́deo. También se puede producir documentos PostScript para imprimir
la presentación sobre transparencias para exposiciones con retroproyector.
Dispone de multitud de estilos de presentación y la posibilidad de conseguir efectos de animación en
pantalla haciendo que el contenido de la misma aparezca o desaparezca en distintas etapas (de forma
incremental).
Xvidcap y Mencoder: Permite capturar una secuencia de imágenes de una parte de la pantalla, ya sea
una ventana o una región. De esta manera, obtendremos una colección de imágenes del área capturada
separadas temporalmente un número de fps1 que se puede especificar. El programa Mencoder forma
parte de Mplayer, que es un conjunto de aplicaciones para la grabación y reproducción de vı́deos,
dvd’s y otros. Una vez obtenida la colección de imágenes que conformaran los frames del vı́deo se
utilizará el programa Mencoder para componerlo.
Instalación base
Capı́tulo 3
Instalación de la distribución
La manera más sencilla, con mucho, de instalar Debian GNU/Linux, es usar un juego oficial de CDs o
DVDs de Debian, las imá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 también se encuentran en el CD. Una vez arranque el instalador, se pueden obtener el resto
de ficheros desde el CD.
Se puede obtener más información respecto a la instalación de Debian en [PRG+ 02] y [eidD04].
3.1.1. Unstable
Se llama “Sid” y como su nombre indica es la distribución más inestable porque contiene paquetes
muy nuevos. La utilizan los desarrolladores de Debian para depuració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 pasó un tiempo de prueba en inestable pero
que aú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 más reciente sin esperar
a la liberación oficial de una nueva versión. Es el equivalente a la distribución más actual de las demás
distribuciones (Mandrake, Fedora, Slackware, etc).
22 Servidor Linux para conexiones seguras de una LAN a Internet
3.1.3. Stable
Actualmente es la versión 3.0, tambień llamada “Woody” y como su nombre indica es la más estable de
las distribuciones Debian, ya que su software contenido ya superó varios meses de pruebas y correcciones.
En sistemas de producció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 liberación de la versión
estable se plantea inminente.
Método de instalación
3. Arrancar el instalador con los métodos y parámetros más adecuados al Hw disponible. Presionando
Enter se arranca con los parámetros por defecto que incluyen el kernel 2.6 de GNU/Linux.
4. Elegir idioma
5. Seleccionar paı́s
8. Configurar la red
12. Instalar el gestor de arranque, se instala Grub como predeterminado. Si se disponen de varios sistemas
operativos se puede especificar un arranque múltiple
Si disponemos de los DVD’s o CD’s de Debian Sarge, añadiéndolos al archivo de fuentes de APT
(#apt-cdrom add).
Si disponemos de internet, añadiendo la dirección de una ré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 distribución en el APT, solamente tenemos que
introducir los siguientes comandos:
#apt-get update
#apt-get upgrade
#apt-get dist-upgrade
Primeros pasos
En los apartados que se presentan a continuación establecen varias cosas que hay que tener en cuenta
para administrar un servidor Linux.
Debido a que estamos configurando un servidor, debemos conocer que directorios es necesario tener en
particiones separadas:
/home, donde están los directorios de todos los usuarios. Esto es ú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 página web), es importante situarlos en otra par-
tición para que nadie pueda realizar un ataque de Denegación de servicio (DoS) generando tantas
entradas que se llene todo el disco.
/tmp, donde se sitúan los archivos temporales. Debido a que este directorio está diseñado para que
todos los usuarios puedan escribir en él, necesitaremos asegurarnos de que ningún usuario abuse y
llene el disco completo. Podemos conseguir esto situándolo en una partició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 partición mejora el rendimiento del sistema.
Se puede observar por qué es una buena idea crear varias particiones en un disco en lugar de una sola
partición grande al estilo de Microsoft. Esto da una idea de por qué un sistema trabaja mejor que el otro.
26 Servidor Linux para conexiones seguras de una LAN a Internet
Lilo
Si hemos optado por utilizar Lilo, al terminar el proceso de instalación de Linux dispondremos de
un archivo de configuración denominado /etc/lilo.conf el cual podremos editar en cualquier momento
para ajustar el menú o comportamiento de Lilo a nuestras necesidades.
El archivo está dividido en tres secciones, como se puede observar en el cuadro 4.1.
La primera sección contiene opciones globales, como son el sistema operativo por defecto o si queremos
que aparezca el menú de selección y el tiempo por defecto.
En la segunda sección se especifican los parámetros necesarios para arrancar Linux, indicándose en
image y initrd el kernel y las opciones de arranque.
La última sección especifica la partición desde donde deberá ejecutarse los otros sistemas operativos
que tengamos instalados en el ordenador.
Si necesitamos realizar alguna modificación simplemente editaremos el archivo /etc/lilo.conf y pos-
teriormente ejecutaremos el comando lilo para activar los cambios.
#/sbin/lilo
#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 más flexible que Lilo, ya que permite
interactuar en caso de arranque inválido.
Incluye otras funciones como el soporte de múltiples módulos, interfaz gráfico de arranque, lı́nea de
comandos, descompresión automática, soporte para LBA y soporte para terminales entre otras muchas
opciones.
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 dañar el sistema en caso de cometer algún error.
Má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.
#useradd josan
Este mandato crea una nueva entrada en el archivo /etc/passwd. Este archivo contiene información
como el nombre de usuario, contraseña, directorio de trabajo y shell predeterminado.
Es necesario crear una carpeta /home/josan que será el directorio del usuario.
#mkdir /home/josan
Una vez creado el usuario le deberemos asignar una contraseña, para ello utilizaremos la instrucción
passwd. Con ella podemos modificar la contraseña de cualquier usuario si hemos iniciado una sesión de
root, o nuestra propia contraseña en cualquier otro caso.
#chfn josan
#finger josan
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:
Cada lı́nea representa un usuario. La información de cada usuario está dividida en seis campos delimi-
tados por el carácter dos puntos (:). La descripción de cada uno de los campos aparece listada en la Tabla
4.3.
Un carácter “*” en la contraseña indica que la cuenta esta deshabilitada temporalmente. Es una buena
práctica no sólo añadir el carácter, sino indicar el motivo por el que ha sido deshabilitada.
Se pueden añadir nuevas cuentas de usuario editando directamente el archivo /etc/passwd, pero para
crear las contraseñas hay que usar la utilidad /usr/bin/passwd ya que esta es cifrada.
Archivo /etc/shadow
Es el archivo de contraseñas ocultas. Este archivo añade un nivel de seguridad adicional, ya que la
encriptación de la clave de usuario solo es visible por el root.
Cuando todavı́a no existı́an las contraseñas ocultas, la contraseña, aunque cifrada, se almacenaba en el
archivo /etc/passwd. Este archivo puede ser leı́do por cualquier usuario del sistema, pero sólo modificado
por el usuario root. Esto representa un problema porque significa que cualquiera puede ver una contraseña
cifrada e intentar conseguir una clave que genere ese cifrado. Para combatir esta amenaza potencial, se
definió el concepto de contraseñas ocultas.
Está formado por entradas de una lı́nea con campos delimitados por el carácter dos puntos (:). Algunos
de estos campos contendrán aparentemente números raros, demasiado altos para ser correctos. Estos
campos están referidos a la fecha de comienzo “de la era de la computación”, el 1 de enero de 1970.
Se utilizará change, la utilidad de cambio de caducidad, para modificar estos valores predeterminados.
Para realizar el cifrado de las contraseñas es mejor usar MD5 que el antiguo método DES, ya que
el primero permite contraseñas má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 ló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, protegiéndose contra el acceso de otros usuarios que no
deban acceder a esos recursos.
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.
#ls -l <archivo>
- rwx rwx rwx root root 512 Jan 7 10:50 nom_archivo
Opción Descripción
u Propietario
g Grupo
o Otros
a Todos
r Lectura
x Ejecución
w Escritura
0 Sin privilegios
1 Ejecución
2 Escritura
3 Escritura y ejecución
4 Lectura
5 Lectura y ejecución
6 Lectura y escritura
7 Lectura, escritura y ejecución
O con números:
Opción Descripción
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 creó el archivo.
El bit de persistencia, mostrado como “t” en lugar del bit de ejecución normal para el nivel “otros” se
usa normalmente en directorios tales como /tmp. Este atributo en concreto hace que só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 añadir un número más al chmod:
.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).
Entramos en el directorio que se haya creado y allı́ normalmente encontraremos algunos ficheros de
documentación especificos de cada paquete y los siguientes ficheros estándar:
README
INSTALL
Para realizar la instalación se utiliza el Makefile, un archivo que se pasa al comando make con una serie
de parámetros dependiendo de las opciones disponibles. En el próximo párrafo se explica en que consiste
exactamente un archivo de este tipo.
Makefiles
En proyectos extensos, con varios miles de lı́neas de programación, no resulta muy práctico recompilar
cada vez que se desea armar un nuevo ejecutable. Es frecuente por lo tanto dividir el proyecto en varios
archivos con código fuente, y recompilar sólo los archivos qué 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 especificació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 configuración donde se indicarán que archivos debe compilar, las depen-
dencias de compilación, y los flags qué se han de pasar al compilador.
Pueden llegar a ser archivos grandes y complejos. Trataré de explicar las nociones más básicas de los
mismos, para poder leer los que vienen en las instalaciones de las aplicaciones. La sintaxis básica de un
archivo Makefile es la siguiente:
objetivo: dependencias
acciones a ejecutar
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 leerá 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 modificación anterior a la de sus dependencias, deberá ejecutar
la acción indicada para generarlo nuevamente. Análogamente, si tst.o no existe o tiene fecha de modificación
anterior a la de tst.c, será necesario recompilar nuevamente su código fuente.
En este tipo de archivos se suelen definir variables para ser utilizadas en las lı́neas de acciones. Estas
definiciones están al comienzo de los Makefiles y son del tipo:
DEPTST=tst.o tstf.o
CFLAGS=-c -o
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 también se pueden utilizar las construcciones especiales “$<” para referirse a las depen-
dencias y “$@” para referirse al objetivo, en el interior de las acciones.
$./configure
$make
$make install
Según el archivo INSTALL podremos observar las necesidades concretas del paquete, también es ha-
bitual, entre las distintas fases de instalación, las directivas:
$make check
$make clean
Por ú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 más privilegios.
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 estándar del sources.list.
#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 través de internet utilizamos ftp.rediris.es, replica en España de
los paquetes Debian.
Opciones ATP
En el cuadro 4.14 vamos a poder encontrar las opciones mas usuales que se pueden utilizar con el
comando APT
Si utilizamos la opción apt-cdrom solo tendrá efecto si el CD-ROM esta bien configurado en /etc/fstab.
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 instalación crearon un archivo igual a nom-
bre comando. Si sabemos el directorio donde se encuentra podemos refinar la búsqueda.
$dpkg -S /usr/bin/nombre_comando
Donde arch, version y word se ajustan a las necesidades de nuestra búsqueda concreta.
$dpkg -l "*cadena_caracteres*"
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-
mentació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:
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
Estos comandos (dpkg --force-help) son útiles en determinadas ocasiones, pero hay que saber que
es lo que se quiere hacer de antemano y asumir las posibles consecuencias.
Por último comentar el siguiente comando que también puede ser útil en determinadas ocasiones:
Donde -s simula la instalación y -t unstable, stable o testing especifica la distribució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).
Shell Bourne
La shell Bourne es la má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 tamaño, ideal
para disquetes de arranque; kiss, otro intérprete sencillo de shell (pero sólo tiene comandos rudimentarios
integrados), que es tambié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 cálculos numéricos). Estaba dirigida a usuarios avanzados y a usuarios más familiarizados con la
sintaxis de la programación en C. La shell C proporciona una interfaz agradable, pero se considera que es
más difı́cil hacer scripts para ella, especialmente para aquéllos que no esté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.
Si se empieza a escribir una ruta o un nombre de archivo, y esa ruta o ese nombre son ú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 único emite un pitido de opción ambigua y si se pulsa por segunda vez la
tecla TAB se muestra el rango de opciones disponibles. A menudo, con sólo un carácter más
tendremos una selección única otra vez.
Se pueden ejecutar varios comandos en la misma lı́nea separándolos por el caracter “;”
Permite incrustar comandos como parametros de otros comandos, encerrándolos entre comillas
invertidas (#kill ‘cat /var/run/named.pid‘)
Existe un historial de comandos, que queda almacenado en .bash history. Tiene un tamaño
prefijado (normalmente 500 lineas) a partir del cual empieza a borrar las lı́neas antigüas para
escribir las nuevas. El comando $history mostrará el contenido de .bash history.
Este histó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. También permite seleccionar textos usando el ratón.
$./<archivo_ejecutable>
Desde una consola también podemos hacer que un proceso se ejecute en segundo plano añadiéndole
un & al final, y ası́ seguir trabajando en esa consola:
$comando &
$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>
Si se utiliza el shell bash, se puede encontrar más información sobre las variables de entorno que existen
mediante el comando $man bash.
La forma de realizar esta asignación desde la lı́nea de comandos dependerá del shell que estemos uti-
lizando.
#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 instrucción:
export VARIABLE_DE_ENTORNO=valor
#unset VARIABLE_DE_ENTORNO
#env -u VARIABLE_DE_ENTORNO
Hay que tener en cuenta que si la variable se encontraba contenida en uno de los archivos de configu-
ración de perfil, cuando volvamos a cargar el entorno del usuario la variable también se cargará.
Si queremos que se ejecute algo al comienzo o final de cada sesión, o añadir nuevas variables de sistema,
elegiremos el archivo a modificar que más convenga a nuestros objetivos.
Resulta de gran utilidad realizar alguna modificación a los comandos tı́picos para evitar daños no
deseados en el sistema o añadir las opciones que mas utilizamos. Un ejemplo de esto serı́a colocar en el
archivo ˜/.profile:
Con los tres primeros comandos se redefinirá el comando base, pidiendo confirmación por defecto y
con el último se creará un comando nuevo que llamará a ls pero con más opciones.
4.6.6. Redireccionamientos
Para redireccionar a un archivo la salida normal de un script, de forma que más tarde se puedan ver
los resultados, se utiliza la redirección (>).
$ls -l >listado
Si se quiere añadir los resultados de la salida de un comando al final de un archivo, se utiliza la redi-
rección (>>).
Canales estándar
En Linux existen una serie de canales estándar que nunca cambian, al menos que los modifiquemos a
mano:
Estos dispositivos estándar también pueden ser redireccionados con: “>” y “<”. Esto se puede observar
en los siguientes ejemplos:
$ls > listado 2>&1, . . . redirecciona la salida estándar y el error estándar al archivo listado.
$ls > listado 2>/dev/null, . . . redirecciona la salida está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.
$env | grep "SHELL", . . . el comando env lista las variables y filtramos la variable “SHELL”.
Los comandos more y less paginan (dividen en páginas) uno o varios ficheros y los muestran en la
terminal. De no indicárseles un fichero, paginan la entrada estándar. Se diferencian en las facilidades que
brindan. Por ejemplo more es má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 último fichero a paginar, more termina automáticamente, no ası́ less. Tambié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 búsquedas del patrón p dentro del texto. Para repetir la búsqueda del mismo patrón sólo
es necesario escribir /.
n b: en more permite regresar n páginas (por defecto n es 1).
Kernel
El kernel o núcleo es una de las partes esenciales de un sistema operativo. Proporciona todos los servicios
básicos requeridos por otras partes del sistema operativo y aplicaciones. Se encarga de la administración
de la memoria, los procesos y los discos. El kernel es independiente de la distribució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 sistemás y hardware, por lo tanto dan soporte a muchos dispositivos y
hardware que no necesitamos. Recompilar el kernel es una buena idea y dará como resultado un kernel
más pequeño y rápido. El kernel 2.6 es más rápido que los kernels anteriores y tiene soporte para nuevos
dispositivos.
La actualización del kernel se divide en dos partes: compilación e instalación del nuevo kernel.
5.3. Kernel-image
La manera más sencilla de obtener un nuevo kernel es instalar un paquete kernel-image.deb. Una vez
instalado sólo es necesario actualizar el gestor de arranques y reiniciar.
Son kernels bastante estándar y adaptados a distribuciones Debian. Para hacerlos más utilizables,
incluyen soporte para todo tipo de hardware e idiomás imaginados.
Este método es rápido y sencillo pero es muy ineficiente, desaprovecha los recursos del sistema.
46 Servidor Linux para conexiones seguras de una LAN a Internet
5.4. Kernel-source
Es un paquete de código fuente del kernel oficial, adaptado a la distribución Debian. Kernel-source es
mucho más versátil que kernel-image, los binarios no suelen contener configurados correctamente todos
los dispositivos del sistema.
Donde version es el número de la versión del kernel, en la secuencia del usuario y .fecha es la fecha
en la que se está compilando el kernel. De esta forma tendremos claramente identificado la versión del
kernel y la fecha de la compilación.
#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).
Para la seguridad y asegurarnos que no dañamos involuntariamente el sistema se puede creer un usua-
rio capaz de actuar con los archivos fuentes. Para eso se añadirá al grupo src.
Paquetes básicos
gcc
kernel-package
libc6-dev
tk8.0
libncurses5-dev
fakeroot
Antes de realizar el proceso de compilación de un kernel de la serie 2.6 es necesario que actualize-
mos nuestro sistema con las últimás versiones de los paquetes que se detallan en el cuador 5.2.
/usr/src/linux/scripts/ver_linux
En caso de que no reconociera alguno, es necesario estudiar má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 instalación que simplifican esta tarea.
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 (secció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.
http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html
Con esto conseguiremos aplicar los parches sobre las fuentes del kernel, es preciso asegurarse que los
parches coinciden con la versión de nuestro kernel, en caso contrario no funcionarán.
Interfaz gráfico
En los sistemas Linux se tiene una visión diferente del entorno gráfico. La interfaz que se presenta al
usuario es independiente del núcleo del sistema operativo.
El núcleo de Linux (su kernel) está completamente desacoplado de la interfaz gráfica. Esto permite
seleccionar la interfaz con la que nos resulte más cómoda, en lugar de tener que seguir el dictado de alguien
o de la potencialmente aleatoria “investigación de mercado”.
Sin embargo, lo más importante de esta decisión es la estabilidad que implica tener este programa
independiente del nú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 creó una fundación para entornos de usuario gráfico, indepenediente del sistema
operativo llamado X-Windows. Las “X” simplemente definen el método por el cual se pueden comunicar
las aplicaciones con el hardware gráfico. También establece un conjunto de funciones de programación
bien definidas que podrán ser llamadas para realizar la manipulación básica de las ventanas.
La definición básica de cómo se dibuja una ventana, un botón o un icono no incluye la definición de
có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 programació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 diseñ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 máquina, pero se visualicen en otra distinta, suministra protocolos de red para realizar esta función.
Históricamente, XFree86 ha sido una de las partes más complejas de Linux en lo referente a instalación
y configuración. Ya no es este el caso, en la mayorı́a de las configuraciones estándar de hardware. Ahora las
distribuciones más populares de Linux lo instalan y configuran automáticamente. Además, con XFree86 v4,
algunas de las partes más complejas de la configuración son gestionadas automáticamente.
Actualmente XFree86, el servidor X que usa Linux normalmente, se encuentra en el está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 dañar fı́sicamente el ordenador.
xf86Config
Es el configurador de X-Windows para Debian. Después de leer los archivos /usr/X11/lib/doc, hay que
ejecutar uno de los siguientes comandos:
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 erróneos, arrancar
el monitor con frecuencias no soportadas podrı́a dañar el equipo.
A continuación paso a detallar cada una de las secciones que contiene el archivo de configuración:
Sección Files
Está secció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 módulos.
Sección Modules
Se proporciona soporte para varios servicios mediante módulos de carga dinámica. Esto aumenta mucho
la flexibilidad en el modo de suministro de servicios, y en los servicios que los usuarios eligen usar en
realidad.
De este modo, también se proporciona un mecanismo más general para ofrecer servicios, como soporte
TrueType, que antes suministraban programas externos.
Los módulos pueden cargarse usando el comando Load o usando una SubSection. El uso de una
SubSection activa las opciones que se quieren pasar al módulo.
Sección InputDevice
Es una de las muchas secciones que puede repetirse en el archivo de configuración. Cada dispositi-
vo (ratón, teclado, pantalla táctil, . . . ) tiene su propia sección InputDevice.
Define simplemente un dispositivo de entrada disponible. No implica que este dispositivo de hecho se
use. La sección ServerLayout asociará este dispositivo con una presentación en pantalla.
Sección Device
Esta sección define una tarjeta de vı́deo. Como con muchas de las otras secciones, no implica que
el dispositivo se esté usando, sólo que está disponible. Al igual que que la mayorı́a de las secciones, la
sección Device usa un comando Identifier para nombrar a este dispositivo.
El comando Driver indica a XFree86 qué módulo cargable debe usar para este dispositivo.
Los controladores de dispositivos suelen aceptar multitud de opciones.
Sección Monitor
Esta sección define un monitor que esté disponible para su uso, pero no implica que esté usando en
realidad. Tampoco asocia al monitor con una tarjeta de vı́deo. Esto se hará en la sección Screen. Cada
secció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 más fácil definir las
configuraciones multipantalla.
Sección Screen
Esta sección combina un Monitor y un Device, definidos en las secciones anteriores, para crear una
pantalla lógica. También define una profundidad de color predeterminada, o el número de bits de color
por pixel.
Dentro de esta sección se encuentran una o más subsecciones Display. Estas subsecciones definen las
combinaciones de profundidad de color/resolución para esta pantalla. También suministran el tamaño de
los espacios de visualización o de la pantalla virtual. Después de seleccionar una pantalla usando una
presentación o la opción de la lı́nea de comandos --screen, la profundidad de color de ese momento
determinará qué visualización se usará. La profundidad de color puede configuarse usando la opción de la
lı́nea de comandos --depth, o se usará la profundidad de color predeterminada.
Sección ServerLayout
Esta sección define una presentación de pantallas y de dispositivos de entrada. Se puden definir una
o más pantallas. Si se definen varias pantallas, las opciones indicarán a XFree86 dónde se encuentra
fı́sicamente una con relació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 está 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 estén solapadas entre varios monitores.
Al usar un nuevo módulo llamado Xinerama, se pueden tratar varios monitores como si fuese un
ú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.
Sección ServerFlags
Esta sección define varios indicadores de opción de Xfree86. Las configuraciones predeterminadas pa-
ra estos indicadores son válidas en casi todas las situaciones y necesitarán modificaciones en contadas
ocasiones. Si se necesita investigar estas opciones, los comentarios que se encuentran en el archivo de
configuración son bastante clarificadores.
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
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/psaux"
Option "Protocol" "PS/2"
Option "Emulate3Buttons" "true"
Option "ZAxisMapping" "4 5"
EndSection
Section "InputDevice"
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
SubSection "Display"
Depth 4
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 8
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 15
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 16
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
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
$startx
Para poder elegir entre que sistema de ventanas queremos arrancar tenemos que modificar el archivo
de configuración de usuario ˜/.xinitrc.
#!/bin/sh
startkde
#!/bin/sh
gnome-session
Si el archivo no está vacı́o, probablemente la última lı́nea sea un comando exec. Es necesario cambiarlo
por la opción que hayamos escogido.
Como las “X” no especifican un gestor de ventanas en particular, a lo largo de los años han aparecido
muchos. Algunos de los má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 más extendidos, aunque no todos están aquı́, existen muchos
otros:
twm: Tab Windows Manager, gestor de ventanas minimalista que proporciona el conjunto de utili-
dades más bá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 está basado en fvwm2.
wmaker: WindowMaker, completı́simo gestor de ventanas GNU diseado para emular el aspecto del
entorno NeXT.
blackbox: También inspirado en NeXT. Es un muy ligero y rápido.
Enlightenment: Era el gestor predeterminado de GNOME. Es muy grande, pero muy atractivo a la
vista. Posiblemente es el más configurable de todos.
Sawfish: Enormemente configurable, pero mucho más ligero que Enlightenment es ahora el gestor
por defecto en el entorno de escritorio GNOME, pero puede ser usado sin él. Se está convirtiendo
rápidamente en uno de los gestores con más aceptació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.
También existe un paquete llamado wmanager que permite seleccionar el gestor de ventanas al arrancar
las “X”.
Desde la aparició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 más versátil y agradable a la vista.
Al final, la elección del gestor de ventanas es solo cuestion de gustos. En mi caso, para la elaboración
del proyecto he utilizado GNOME como entorno de escritorio y las bibliotecas KDE para ejecutar la
aplicació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 cómo se debe ver la interfaz, KDE proporciona un
conjunto de bibliotecas que, si se usan, permiten a una aplicación mejorar algunas caracterı́sticas especiales
que no las ofrecen el resto. Esto incluye cosas como soporte a pinchar y arrastrar, soporte de impresión
estandarizado, etc.
El punto negativo de este tipo de técnicas de gestión de ventanas es que una vez que una aplicación
se diseñ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 más sencillas de usar que el trabajo directo con la interfaz “X”. Se ofrece un conjunto
de herramientas orientadas a objetos estándar que permite construir otras herramientas, algo que sólo
está disponible con X-Windows.
6.3.2. Gnome
Hasta hace pocos años habı́a algunos problemas con las restricciones de licencias impuestas por los
desarrolladores de la biblioteca Qt3, en la que KDE está basado. Estaba prohibido el uso comercial de
KDE sin pagar derechos. El proyecto GNOME1 comenzó debido a esta resticción.
Hace un tiempo se revisó la licencia de KDE. La licencia revisada, conocida como QPL, es ahora má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 fácil uso. Lo que hace a GNOME diferente es có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 má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 gestión de sesió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.
CDE3 : Desarrollado por algunos fabricantes de Unix, es uno de los má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 también maneja sin dificultad aplicaciones KDE.
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.
Capa Fı́sica
Esta capa es el medio fı́sico real que contiene los datos. Los distintos tipos de medios siguen diferentes
estándares. Por ejemplo, el cable coaxial, el par trenzado (UTP, Unshielded Twisted Pair) y el cable de fibra
óptica sirven para distintos propósitos: el cable coaxial se usa en instalaciones LAN antiguas ası́ como en
servicios de Internet a través de redes de TV por cable. UTP se usa normalmente en cableados domésticos,
mientras que la fibra óptica se suele usar para conexiones de distancias largas que requieren una capacidad
de carga alta.
60 Servidor Linux para conexiones seguras de una LAN a Internet
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 identificación
secundaria. En los sistemas de red TCP/IP, se trata de una dirección IP. Esta dirección IP en nuestro
ordenador nos ayuda a enrutar los datos de un lugar a otro de la red y sobre Internet. Esta dirección
es un número único para identificar nuestro ordenador en una red basada en IP. En algunos casos, este
número es único para un ordenador; ninguna otra máquina en Internet puede tener dicha dirección. Es
el caso de las direcciones IP normales que se pueden enrutar públicamente. En las LAN internas, las
máquinas normalmente utilizan bloques de direcciones IP. Estas se han reservado sólo para su uso interno
y no se enrutarán por Internet. Estos números pueden no ser únicos de una red a otra, pero siguen siendo
únicos dentro de cada LAN. Aunque dos ordenadores pueden tener la misma dirección IP privada sobre
diferentes redes internas, nunca tendrán la misma dirección MAC, ya que es un número de serie asignado
por el fabricante. Existen excepciones a esta regla pero, en general, la dirección MAC identificará de forma
ú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 transmisión (TCP, Transmission Control Protocol) básicamente asegura que
los paquetes se envı́an y se reciben con consistencia en el otro punto. Permite una corrección de errores a
nivel de bits, una retransmisión de segmentos perdidos y una reorganización de los paquetes y el tráfico
desfragmentado.
El protocolo de datagramas de usuario (UDP, User Datagram Protocol) es un esquema más ligero
empleado para tráfico multimedia y para transmisiones cortas, como las solicitudes DNS. También efectúa
detecció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 sesión
La capa de sesión se encuentra implicada principalmente en la configuración de una conexión y en
su cierre posterior. También realiza autenticaciones para determinar qué partes pueden participar en una
sesión. Se utiliza principalmente en aplicaciones especı́ficas.
Capa de presentació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-
sentación. La distinción entre la capa de aplicación y la de sesión es muy delicada y algunos afirman que
la capa de presentación y la de aplicación son básicamente iguales.
Capa de aplicación
Este nivel final es donde el programa de la aplicació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) tendrá una dirección única
cuya longitud será de 32 bits, que será utilizada en los campos dirección origen y dirección destino de
la cabecera IP. Esta dirección consta de un identificador de red y de un identificador de host. La direc-
ción está codificada para permitir una asignación variable de los bits utilizados al especificar la red y el
computador. La dirección IP más pequeñ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 dirección puede ser determinada por la posición del primer
0 en los cuatro primeros bits. Las direcciones están codificadas para permitir una asignación variable de
bits para especificar la red y el host.
Clase A: Pocas redes, cada una con muchos ordenadores. 1 bit de selección de clase A, 7 bits de red
y 24 bits de host (Por ejemplo ARPANET)
Clase B : Un número medio de redes, cada una con un número medio de ordenadores. 2 bits de
selecció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 selección de clase C, 21 bits de
red y 8 bits de host (LANs).
Clase D: Permite hacer multitransmisión (o multicasting) en la cual el datagrama se dirige a múltiples
ordenadores. Podemos enviar un paquete IP a un grupo de máquinas que por ejemplo pueden estar
cooperando de alguna manera mediante la utilización de una dirección de grupo
En el siguiente cuadro podemos observar el número de redes y de ordenadores por red en cada una de
las tres clases primarias de direcciones IP.
Clase Bits en el prefijo Máximo n.o de redes Bits en el sufijo Má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 notación decimal con puntos (calculando cada ocho
bits). Por ejemplo, la direcció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 dirección 0.0.0.0 significa esta red o este host y únicamente es usada por los ordenadores
cuando son arrancados, sin que vuelva a utilizarse posteriormente. De esta forma las máquinas se
pueden referir a su propia red sin saber su nú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 número de ceros).
Difusión de red local o limitada: La dirección 255.255.255.255 (todos 1s) se usa como dirección para
indicar todos los ordenadores de la red indicada y es utilizada para hacer difusión.
Difusión de una red distante o dirigida (broadcast): También se puede hacer difusión a una red
distante poniendo la dirección de la red y rellenando el campo ordenador con 1s.
Retrociclo: Las direcciones 127.xx.yy.zz se reservan para pruebas de realimentación (localhost). Los
paquetes que tienen esta direcció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 número. Esta
caracterı́stica también se usa para la detección de fallos en el software de red.
Para estar seguros de que las direcciones Internet son únicas, todas las direcciones de Internet son
asignadas por un autoridad central. La IANA (Internet Assigned Number Authority) tiene el control
sobre los números asignados. Sin embargo, cuando una organización quiere una dirección debe obtenerla
de INTERNIC (Internet Network Information Center). La autoridad central sólo es necesaria para asignar
la porción de la dirección correspondiente a la red, cuando una organización ya tiene su prefijo, puede
asignar un único sufijo a cada ordenador sin contactar con la autoridad central.
Una máquina puede estar conectada a varias redes y tener una direcció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 aún está conectado a internet utilizando la otra red. Por otra parte, también es usado para aumentar
el rendimiento de la red, pues permite enviar directamente el tráfico a una red en concreto sin tener que
pasar por los dispositivos de encaminamiento.
Que la dirección de la red esté guardada en la dirección Internet tiene algunos inconvenientes:
Como el número de ordenadores asignados a la clase C (255) puede resultar insuficiente en muchos
casos y que la transición a la clase B no es fácil debido a que muchos programas no permiten que
una red fı́sica tenga mú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 máquina pueda estar conectada a dos redes y por lo tanto
tenga dos direcciones diferentes, el encaminamiento se hace teniendo en cuenta la dirección IP, el
comportamiento de los paquetes puede ser totalmente diferente dependiendo de la dirección que
estemos utilizando. Esto puede resultar sorprendente para los usuarios.
En algunos casos, el conocer una dirección IP puede resultar insuficiente para alcanzar la máquina
que utiliza esta dirección. Debido a la configuració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
través de la capa de red (capa internet), por el protocolo IP. Durante el camino puede ser fragmentado en
unidades más pequeñas, si deben atravesar una red o subred cuyo tamaño de paquete sea más pequeño.
En la má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.
Normalmente nos referiremos a las redes IP como máscaras de red o con una barra inclinada y un
número. Ambas son formas de definir el tamaño de la red. Para entenderlas tenemos que conocer un poco
de la estructura de la dirección IP. Una dirección IPv4 está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:
Una máscara de red normalmente es un conjunto de cuatro números que nos indica dónde finalizan los
bits de red y donde comienzan los de hosts. Normalmente tiene la siguiente apariencia:
255.255.255.0
Una forma rápida de calcular el tamaño de una red representada por una máscara de red es restar cada
octeto de 256 y multiplicar dichos números entre sı́. Por ejemplo, la máscara de red de 255.255.255.248
describe una red de 8 IPs porque:
Una máscara de red de 255.255.255.0 describe una red de 256 IPs ya que:
Y por último, una máscara de red de 255.255.0.0 describe una red de 65.536 direcciones IP porque:
La notación de barra inclinada es algo más difı́cil de entender, aunque utiliza el mismo concepto. El
número que se encuentra detras de la barra inclinada indica la cantidad de bits que describen la dirección
de red (para una explicación con más detalle, véase la sección 7.2.4). Si restamos de 32 dicho número
obtenendremos el número de bits que desciben la dirección de host dentro de la red local. Por ejemplo la
notación 192.168.0.0/24 describe una red que empieza en 192.168.0.0 que contiene 256 direcciones IP de
tamaño (es decir, el mismo tamaño que el de arriba con una máscara de red de 255.255.255.0).
Los 32 bits en una direcció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 número binario de bits de 11111111 convertido en decimal es 255. Si las
matemáticas binarias nos resultan complicadas, podemos utilizaremos la siguiente tabla para recordarlo.
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)
insmod ip_masq_ftp
insmod ip_masq_irc
También lo podemos hacer con reglas, añadiendo el redireccionamiento de los puertos que utilice el
protocolo. Esto se observa en el siguiente ejemplo:
Enviamos el tráfico que entra, dirigido por eth0 al puerto 80 (web), a nuestro proxy squid (transparente)
por el puerto 3128 de nuestra máquina:
#iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
El primero utiliza un tabla en cada máquina para almacenar para cada dirección IP la correspon-
diente dirección fı́sica. Cada entrada de la tabla contiene una dirección IP y una direcció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 traducción entre dirección IP y dirección fı́sica.
El segundo realiza la traducción mediante una función matemática. Aunque muchas tecnologı́as
utilizan direcciones fı́sicas estáticas, algunas usan direccionamiento configurable, es decir, el admi-
nistrador de la red elige tanto la dirección fı́sica como la dirección IP. En este caso, los valores pueden
ser elegidos para que la traslación sea trivial.
El tercero es el más interesante pues usa una computación distribuida en la que los dos ordenadores
intercambian mensajes dinámicamente. En este caso, el ordenador que conoce la dirección IP de otro
ordenador pero desconoce su dirección fı́sica, envı́a un mensaje a la red con la dirección IP conocida
y recibe de la red una respuesta con la dirección fı́sica. Existen dos posibles diseños:
1. En el primero hay uno o más servidores que se encargan de enviar las respuestas. La principal
ventaja de este diseño es que es centralizado y por lo tanto fá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 diseño, se hace un broadcast de la petición (envı́o a la dirección de difusión de red)
y todos los ordenadores participan en la resolución de la dirección, en concreto responde el que
tiene la dirección pedida. La principal ventaja de este diseño es que el cálculo es distribuido.
Este diseño es el utilizado en el ARP, una de las ventajas de este método sobre tener unos
archivos de configuración es su sencillez. El propio protocolo se encarga de construir las tablas
en lugar de tener que hacerlo el administrador del sistema.
Pero, ¿cómo una máquina que no disponga de disco duro puede determinar su direcció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 dirección IP es simple: una máquina que necesita conocer su dirección envı́a
una petición a un servidor que hay en otra má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 petición, la
máquina que necesita conocer su dirección IP únicamente debe identificarse a si misma, y de esta manera
el servidor puede buscar su dirección IP y enviarle una respuesta. Tanto la máquina que hace la petición
como el servidor que responde usan direcciones fı́sicas durante su breve comunicación.
¿Cómo puede la máquina conocer la dirección del servidor?. Generalmente no la conoce, lo que hace
es hacer un broadcast (difusión de red) de su petición a todas las máquina de la red local y esperar que
algún servidor responda. De alguna manera lo que hace la máquina es enviar un mensaje diciendo:
“ mi dirección fı́sica Ethernet es XX.XX.XX.XX.XX.XX Sabe alguien cual es mi dirección IP?”
Como podemos ver en esta pregunta, para identificarse, la máquina utiliza su dirección fı́sica lo que
tiene la ventaja de que siempre está disponible y de que es uniforme para todas las máquinas de una red.
En realidad lo que queremos es encontrar la dirección IP de una máquina de la que conocemos su
dirección fı́sica. El protocolo para conseguir esto es el RARP que es una adaptació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 máquina a otra encapsulado en la porción de datos de la trama fı́sica, por ejemplo
en una trama Ethernet.
El dispositivo de encaminamiento indica a un ordenador que envı́e el tráfico por una ruta má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:
Que permitiera reconocer varias métricas, entre ellas, la distancia fı́sica y el retardo
Ser dinámico, es decir, que se adaptará rápida y automáticamente a los cambio de la topologı́a
Que pudiera equilibrar las cargas dividiendo la misma entre varias lı́neas
Que reconociera sistemas jerárquicos pues un único ordenador no puede conocer la estructura com-
pleta de Internet
1 Diremos que una red es multiacceso si tiene varios dispositivos de encaminamiento que se pueden comunicar con los
demás.
2 Multicast es el envı́o de la información a múltiples destinos simultáneamente usando la estrategia más eficiente para el
envı́o del mensajes sobre cada enlace de la red únicamente una vez y creando copias cuando los enlaces en los destinos se
dividen. En comparació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 dirección IP es la dirección que identifica un dispositivo dentro de una red.
El puerto es un número de 16 bits que se coloca en cada paquete y sirve para identificar la aplicación
que requiere la comunicació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
información de diferentes aplicaciones y estas son identificadas por el puerto.
Para establecer una comunicación entre dos má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 aplicación destino como la
dirección IP que identifica el terminal o el servidor dentro del conjunto de redes.
Los datos que se envı́an durante la comunicació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 comunicación de utiliza el modelo cliente/servidor. En este caso, el cliente inicia
la comunicación y para hacerlo necesita conocer la dirección IP asignada al ordenador servidor y el puerto
de la aplicación que identifica la aplicación que se quiere utilizar.
El cliente conoce su dirección IP (dirección origen), la dirección del servidor (dirección destino) y el
puerto que identifica su aplicación cliente. Para que pueda saber el puerto destino que identifica la apli-
cación deseada, se utilizan los llamados puertos conocidos que consiste en un número de puerto reservado
para identificar una aplicación determinada (Véase apéndice E).
El servidor responderá 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 petición.
7.5.1. UDP
Este protocolo es “no orientado a la conexión”, y por lo tanto no proporciona ningún tipo de control
de errores ni de flujo, aunque si que utiliza mecanismos de detección de errores. Cuando se detecta un
error en un datagrama en lugar de entregarlo a la aplicación se descarta.
Este protocolo se ha definido teniendo en cuenta que el protocolo del nivel inferior (el protocolo IP)
también es no orientado a la conexió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 llegará al destino.
No preserva la secuencia de la información que proporciona la aplicación. La información se puede
recibir desordenada (como ocurre en IP) y la aplicació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 máquina
origen y en la má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 tamaño de la cabecera IP.
Como la longitud máxima del datagrama IP es de 65.535 bytes y la cabecera estándar de IP es de
20 bytes, la longitud máxima de un datagrama UDP es de 65.515 bytes.
El campo suma de comprobació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.
Como el protocolo UDP no está orientado a la conexión y no envı́a ningún mensaje para confirmar
que se han recibido los datagramas, su utilización es adecuada cuando queremos transmitir información
en modo multicast (a muchos destinos) o en modo broadcast (a todos los destinos) pues no tiene sentido
esperar la confirmación de todos los destinos para continuar con la transmisión. También es importante
tener en cuenta que si en una transmisión de este tipo los destinos enviarán confirmación, fá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 multiplexación de aplicaciones.
La dirección del puerto permite identificar aplicaciones gracias a la direcció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 tamaño es bastante grande, como mı́nimo 20 bytes.
A continuación muestro una descripción de cada uno de los campos que forman la cabecera:
Puerto origen (16 bits): Es el punto de acceso de la aplicación en el origen.
Puerto destino (16 bits): Es el punto de acceso de la aplicación en el destino.
Nú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 número indica el primer byte de datos que hay
en el segmento. Al principio de la conexión se asigna un número de secuencia inicial (ISN, Initial
Sequence Number) y a continuación los bytes son numerados consecutivamente.
Número de confirmación (ACK) (32 bits): El protocolo TCP utiliza la técnica de piggybacking 1 para
reconocer los datos. Cuando el bit ACK está activo, este campo contiene el número de secuencia del
primer byte que espera recibir. Es decir, el número ACK=1 indica el último bit reconocido.
Longitud de la cabecera (4 bits): Indica el nú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 tamaño de la cabecera es de 20 bytes por lo que en este campo se almacenará el
número 5. Si el TCP utiliza todos los campos de opciones la cabecera puede tener una longitud
máxima de 60 bytes almacenándose en este campo el valor 15.
Indicadores o campo de control (6 bits): Cada uno de los bits recibe el nombre de indicador y cuando
está a 1 indica una función especı́fica del protocolo.
• URG: Hay datos urgentes y en el campo “puntero urgente” se indica el número de datos urgentes
que hay en el segmento.
• ACK: Indica que tiene significado el número que hay almacenado en el campo “número de
confirmación”.
• PSH: Sirve para invocar la función de carga (push). Como se ha comentado anteriormente con
esta función se indica al receptor que debe pasar a la aplicació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 dimensión
máxima. No se debe confundir con el indicador URG que sirve para señalar que la aplicación
ha determinado una parte del segmento como urgente.
• RST: Sirve para hacer un reset de la conexión.
• SYN: Sirve para sincronizar los números de secuencia.
• FIN: Sirve para indicar que el emisor no tiene más datos para enviar.
Ventana (16 bits): Indica cuantos bytes tiene la ventana de transmisió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 número de bytes de datos comenzando con el que se indica
en el campo de confirmación y que el que envı́a está dispuesto a aceptar.
Suma de comprobación (16 bits): Este campo se utiliza para detectar errores mediante el comple-
mento a uno de la suma en módulo 216-1 de todas las palabras de 16 bits que hay en el segmento más
una pseudo-cabecera. La pseudo-cabecera incluye los siguientes campos de la cabecera IP: dirección
internet origen, dirección internet destino, el protocolo y un campo longitud del segmento. Con la
inclusión de esta pseudo-cabecera, TCP se protege a sı́ mismo de una transmisión errónea de IP.
Puntero urgente (16 bits): Cuando el indicador URG está activo, este campo indica cual es el ú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 está presente permite añadir una única opción de entre las siguientes:
• Tiemstamp: para marcar en que momento se transmitió el segmento y de esta manera monito-
rizar los retardos que experimentan los segmentos desde el origen hasta el destino.
• Aumentar el tamaño de la ventana.
• Indicar el tamaño máximo del segmento que el origen puede enviar.
1 Un paquete puede llevar dentro no sólo los datos que van en dirección A-B, sino también un ACK (acuse de recibo) de
otros datos que llegaron anteriormente en dirección B-A. Ası́ se reduce el número total de paquetes requeridos, porque de
otra manera el ACK tendrı́a que ocupar un paquete completo. Es una técnica de optimización que se usa cuando hay tráfico
de datos en ambos sentidos.
Como TCP ha sido diseñado para trabajar con IP, algunos parámetros de usuario se pasan a
través de TCP a IP para su inclusió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 protección (campo de 11 bits).
Una red TCP/IP permite que los nodos de comunicación establezcan una conexión y después verifiquen
cuá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 información
especı́fica para la siguiente capa de red. Cada paquete se graba con un número de secuencia de 32 bits
para que, aunque lleguen en el orden erróneo, la transmisió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
según dichas instrucciones. Cuando el paquete de datos llega a su destino, se entregan a la aplicación los
datos reales, o carga útil.
Parece algo confuso, pero mostrando la siguiente analogı́a se entenderá mejor. Piensa en una carta
dentro de un sobre que se envı́a a una empresa de mensajerı́a para su distribució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 abrirá y se tirará el sobre exterior. Esta carta puede estar destinada a otro buzón de correo
interno, por lo que pueden colocarla en un sobre de correo ı́nter-oficinas y enviarla al sitio apropiado. Por
último, la carta llega al receptor, que quita todos los envoltorios y utiliza los datos que están dentro. La
tabla 7.4 resume cómo encapsulan datos algunos protocolos de red.
Como se puede comprobar, el exterior de nuestro “sobre” de datos tiene la dirección Ethernet, que
identifica el paquete en la red Ethernet. Dentro de esta capa se encuentra la información de la red,
denominada dirección IP, y dentro se encuentra la capa de transporte, que establece una conexión y la
cierra. A continuación está la capa de aplicación, que es un encabezado HTTP, que indica al explorador
Web cómo debe formatear una página. Por último, entra la carga de datos real del paquete (el contenido
de una página Web). Todo esto ilustra la naturaleza de múltiples capas de las comunicaciones de red.
Existen varias fases durante una comunicación entre dos nodos de red que utilizan TCP/IP. Suponiendo
que estamos utilizando direcciones IP y nombres que no son del anfitrión, lo primero que sucede es que
la máquina genera una solicitud de Protocolo de resolución de direcciones (ARP, Address Resolution
Protocol) para buscar la dirección Ethernet correspondiente a la dirección IP con la que está intentando
comunicarse. Ahora que puede comunicarse con la máquina utilizando IP, existe una comunicación de tres
vı́as entre las máquinas que utilizan el protocolo TCP para establecer una sesión.
Una máquina que desea enviar datos a otra máquina envı́a un paquete SYN para sincronizar, o iniciar,
la transmisión. El paquete SYN está básicamente diciendo “¿Está preparada para el envı́o de datos?”.
La otra máquina, envı́a un SYN/ACK, que significa “De acuerdo, he recibido el paquete SYN y estoy
preparada”. Por último, la máquina emisora envı́a un paquete ACK de respuesta diciendo, “Bien, inicio el
envı́o de datos”. Esta comunicación se denomina Acuerdo de conexión TCP de tres vı́as. Si una de las tres
partes no se produce, la conexión no tiene lugar. Mientras la máquina está enviando sus datos, etiqueta
los paquetes de datos con un número de secuencia y reconoce cualquier número de secuencia anterior
utilizado por el anfitrió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. Ésta responde con un FIN/ACK para cerrar esa sesión TCP/IP.
Debido a la forma en que TCP/IP controla la iniciación y finalización de una sesión, las comunica-
ciones TCP/IP se dice que tienen un estado. Esto significa que podemos saber qué parte del diálogo se
está produciendo sólo con mirar a los paquetes, algo muy importante para los cortafuegos porque la forma
más común de bloquear el tráfico saliente con un cortafuegos es no admitir los paquetes SYN del exterior
en máquinas internas de la red. Ası́, las máquinas internas pueden comunicarse fuera de la red e iniciar
conexiones con el exterior pero las máquinas externas no pueden iniciar nunca la conexión.
En Linux el cortafuegos IPTables integrado en el núcleo, esta disponible en las versiones de kernel 2.4x
o superior. Funciona mediante la interacción directa con el núcleo del sistema y nos sirve para hacer el
filtrado de paquetes TCP/IP.
Generalmente los cortafuegos tienen dos o má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 pública (WAN) de nuestro cortafuegos. En las redes más pequeñas, la interfaz WAN se
conecta a Internet. También puede existir una tercera interfaz denominada DMZ (Desmilitarized Zone),
que normalmente es para los servidores que necesitan exponerse más a Internet de forma que los usuarios
externos pueden conectarse a ellos, disponen de una IP pública. Todos los paquetes que intentan pasar a
través de la máquina, pasan a través de una serie de filtros. Si coinciden con el filtro, se lleva a cabo alguna
acción. Ésta puede ser evitar su paso, pasarlo o enmascararlo con una dirección IP privada interna. La
mejor práctica para la configuración del cortafuegos es denegarlo todo siempre y permitir, a continuación,
el tráfico que necesitamos de una forma selectiva.
Los cortafuegos pueden filtrar paquetes en distintos niveles. Pueden mirar una dirección IP y bloquear
el tráfico proveniente de determinadas direcciones o redes IP, comprobar el encabezado TCP y determinar
su estado y, en niveles superiores, pueden mirar a la aplicación o al número de puerto TCP/UDP. Se
pueden configurar para evitar categorı́as completas de trá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 denegación de servicio (DoS). No existe ninguna razó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 réplicas de eco (respuestas de ping).
En su interior encontraremos el modo de funcionamiento de todos los dispositivos de red del sistema.
En este capı́tulo trataremos su configuración mediante una serie de herramientas.
Para configurar las tarjetas de red automáticamente hay que ejecutar el comando:
#dpkg-reconfigure etherconf, . . . que arrancará debconf.
El programa ifconfig es responsable de configurar las tarjetas de interfaz de red (NIC, Network Interface
Card). Todas estas operaciones se realizan a través de la lı́nea de comandos, ya que no tiene interfaz gráfica.
Existen varias herramientas que se han escrito para cubrir la falta de interfaz gráfica o de menús del
comando ifconfig. Muchas de ellas vienen en las distribuciones de Linux, en Debian la interfaz que podemos
utilizar es etherconf.
Donde dispositivo es el nombre del dispositivo ethernet (por ejemplo, eth0), dirección es la dirección
IP que se desea aplicar al dispositivo y opciones es una de las siguientes:
80 Servidor Linux para conexiones seguras de una LAN a Internet
Opción Descripción
up Activa el dispositivo. Esta opció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 transmisión máxima (MTU) del dispositivo a valor.
Bajo ethernet, el valor por defecto es 1500
netmask dirección Configura la máscara de red de esta interfaz a dirección. Si no se propor-
ciona un valor, ifconfig calcula la máscara basada en la clase de la dirección
IP. Una dirección de clase A tiene una máscara 255.0.0.0, una de clase B
255.255.0.0 y la clase C 255.255.255.0
broadcast dirección Configura la dirección de broadcast de la interfaz de dirección. Si no se
proporciona un valor, ifconfig calcula la dirección de broadcasta basada
en la clase de la dirección IP de manera parecida a la máscara de red
pointtopoint dirección Configura la conexión punto a punto (PPP) donde la dirección remota es
dirección
Un ejemplo de uso simple podrı́a ser el siguiente: #ifconfig eth0 192.168.0.3, . . . Donde el dispo-
sitivo eth0 quedará configurado con la dirección IP 192.168.0.3. Como es una dirección de clase C, la
máscara será 255.255.255.0 y el broadcast será 192.168.0.255, asignándolos ifconfig por defecto.
En tiempo de ejecución, con el comando ifconfig podemos habilitar y deshabilitar los dispositos de red:
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, también podemos observar el
dispositivo lo, de loopback.
La segunda es la ruta a la LAN, de forma que los paquetes destinados a las má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 instalación, este valor lo configurará 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.
Parámetro Descripción
cmd Valor add o del dependiendo de si añadimos o borramos una ruta. Si eliminamos
una ruta, sólo necesitamos otro parámetro, dirección
tipo Valor -net o -host dependiendo si dirección representa una dirección de red o una
dirección de un enrutador
dirección La red destino que quiere ofrecer para enrutar
netmask masc Configura la máscara de red de la dirección dirección a masc
gw gatw Configura la la dirección de enrutador para direccion a gatew. Normalmente se usa
como ruta por defecto
dev destino Envı́a todos los paquetes destinados a dirección a través de la red del dispositivo
destino según se configura con ifconfig
1. Configurar una ruta por defecto en mi má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 través del
primer dispositivo PPP:
#route add -host 192.168.0.3 netmask 255.255.255.0 dev ppp0
Route visualiza los nombres de máquinas a cualquier direcció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 esperará, tratando de resolver los nombres de máquinas y esperando para
ver si los servidores devuelven y los resuelven. Esta espera será de varios minutos hasta que la petición
devuelva un timeout.
Este serı́a un ejemplo de la salida de una má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, máscara (referido como genmask) e iface
(interfaz, configurada por la opción dev de route). Las otras entradas de la tabla tienen el significado
siguiente:
Entrada Descripción
Flags Un sumario de estado de conexión, donde cada letra tiene un significado:
U: la conexión está arriba
H: el destino es una má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 métrica baja es el preferido. El kernel de Linux no usa
esta información, pero sı́ lo hacen algunos protocolos de enrutamiento avanzados.
Ref El número de referencias de la ruta. Esto no se usa en el kernel de Linux. Está 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 número de bucles de cache de rutas utilizados con éxito. Para ver este valor, hay que
usar la opción -F cuando invoquemos route
La opciones de netstat son combinables, en la siguiente tabla se muestran las más comunes:
Opción Descripción
-a Visualiza la información de todas las conexiones activas
-i Visualiza las estadı́sticas de todos los dispositivos de red configurados
-c Actualiza la información visualizada cada segundo
-r Muestra la tabla de enrutado
-n Visualiza las direcciones locales y remotas en formato numérico
-t Muestra tan sólo la información de TCP
-u Muestra tan sólo la información de UDP
-v Visualiza la versión de netstat
Para que esto funcione debemos instalar uno de los siguientes paquetes:
Este comando tiene otras opciones que pueden ser consultadas con el manual del sistema: $man dhclient
Los comandos: #ifdown dispositivo y #ifup dispositivo, utilizan el archivo para habilidar y des-
habilitar los dispositivos de red.
Esta sección esta basada en la configuración de la red de la guı́a de referencia Debian, para más
información consúltela.
Si tenemos instalado el paquete resolvconf podemos añadir las siguientes lı́neas para especificar la
información relativa al DNS:
iface eth0 inet static
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
Después de que se activa la interfaz, los argumentos de las opciones dns-search y dns-nameservers
quedan disponibles para resolvconf para su inclusión en resolv.conf.
El argumento nicedomain.org de la opció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 opción dns-nameservers corresponde a los argu-
mentos de las opciones nameserver en resolv.conf.
Para que esto funcione debemos tener instalado un cliente DHCP (Véase sección 8.5).
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 módem posee un router, si esto es ası́ el mó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 configuración. En mi caso, mi proveedor de servicios me ha instalado un
módem/router de este estilo y no me es necesario. Me han facilitado un usuario y contraseña que utilizo
para validarme en su servidor y recibir el servicio.
Si activamos NAT en esta máquina, mediante una puerta de enlace, podemos compartir la conexión
de internet con todas las máquinas de la LAN.
La interfaz eth0:0 es una interfaz virtual. Al activarse también lo hará su padre eth0.
De esta forma, la interfaz fı́sica eth0 se puede activar en la red hogareña con la configuración apropiada,
especificando:
#ifup eth0=hogar
Observamos que con el archivo interfaces escrito ası́ ya no resultará posible activar eth0 haciendo
solamente ifup eth0. La razón es que ifup utiliza el nombre de la interfaz fı́sica como el nombre de la
interfaz lógica eth0 predeterminada y, en realidad, en nuestro ejemplo no hay una interfaz lógica definida.
Una vez visto como se reconfiguran las interfaces, hay que precisar que la reconfiguración necesita
realizarse en el momento apropiado.
Actualmente existe una tendencia en GNU y Linux al soporte de hardware y entornos que cambian
dinámicamente. El primer soporte se añadió para la inserción en caliente de tarjetas PCMCIA; más
recientemente ha sido incorporado el mecanismo hotplug para que muchos más periféricos se puedan
enchufar y desenchufar mientras la má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 sólo deben
iniciarse despué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 dinámicamente de la interfaz de red reconfigurada eth0. Deberı́amos actuar siguiendo este esque-
ma:
Primero eliminamos ‘loquesea’ del control del sistema init. Si está ultilizando el sistema init sysv-rc
entonces hacemos lo siguiente:
# rm /etc/rc?.d/S??loquesea
Luego pongamos ‘loquesea’ bajo el control de ifupdown añadiendo las opciones up y down en la
sección eth0 de /etc/network/interfaces que contiene las llamadas al script init loquesea:
auto lo
iface lo inet loopback
Se puede listar los nombres de interfaces fı́sicas adicionales en las secciones auto si desea que tambié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 después de /etc/rcS.d/S40networking, si descubre
algú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 máquina (una tarjeta PCMCIA, por ejemplo), o después de que una utilidad como discover
se haya ejecutado y cargado los módulos necesarios.
Cuando el kernel detecta nuevo hardware inicializa el controlador para el hardware y luego ejecuta
el programa hotplug para configurarlo. Si más tarde se elimina el hardware, ejecuta nuevamente hotplug
con parámetros diferentes. En Debian, cuando se llama a hotplug éste ejecuta los scripts contenidos en
/etc/hotplug/ y /etc/hotplug.d/.
El hardware de red recié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 añadir la referencia a hotplug en en
/etc/network/interfaces. Para que este comando configure eth0, añadimos las siguientes lı́neas:
mapping hotplug
script echo
Si sólo deseamos que eth0 se active en caliente y no otras interfaces, utilizamos grep en vez de echo
como se muestra a continuación:
mapping hotplug
script grep
map eth0
8.7.3. Ifplugd
Ifplugd activa o desactiva una interfaz dependiendo si el hardware subyacente está 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 combinació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.
Si no hemos instalado el paquete resolvconf, podemos editar a mano el fichero /etc/resolv.conf. En él
podemos especificar hasta tres servidores de nombres, siendo los dos ú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 añadirá a los
nombres de host que no contengan dominio.
La lı́nea search se emplea para especificar que busque un dominio.
El archivo /etc/host.conf dice al sistema cómo resolver los nombres de los hosts. Contiene el orden
en el que serán ejecutadas las resoluciones que requiera el host, este archivo normalmente contiene
la siguiente lı́nea:
order hosts,bind,nis
El significado de estos parámetros es que cualquier tipo de resolución de nombres primeramente debe
ser ejecutada en el archivo /etc/hosts, posteriormente se debe consultar a Bind y si aún no se ha
logrado la resolución, intentar con NIS (Network Information Server), si después de consultar este
servicio no es posible la resolución, el Resolver responderá 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
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.
lo no wireless extensions.
Las opciones básicas de iwconfig sirven para determinar el nombre del ESSID, y establecer la clave
WEP del sistema, tanto en hexadecimal como en ASCII. Veá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
Este comando tiene multitud de opciones que pueden ser consultadas en el manual del sistema:
$man 8 iwconfig.
Para configuraciones más complejas es mejor que editemos el archivo /etc/network/interfaces como se
describe en la sección 8.6.3. Si utilizamos claves WPA, será necesario instalar un cliente WPA (para esta
configuración dirı́jase a la sección 14.5.5).
Instalación de Servicios
Capı́tulo 9
Servicios de red
9.1.3. Implementaciones
Microsoft introdujo DHCP en sus Servidores NT con la versión 3.5 de Windows NT a finales de 1994,
a pesar de que la llamaron una nueva función no fue inventada por ellos.
El Consejo de Software de Internet (ISC: Internet Software Consortium) publicó distribuciones de
DHCP para Unix con la versión 1.0 del ISC DHCP Server el 6 de diciembre de 1997 y una versió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/.
DHCP Offer : El servidor determina la configuración basándose en la dirección del soporte fı́sico de
la computadora cliente especificada en el registro CHADDR. El servidor especifica la dirección IP
en el registro YIADDR.
DHCP Request: El cliente selecciona la configuración de los paquetes recibidos de DHCP Offer. Una
vez más, el cliente solicita una dirección IP especı́fica que indicó el servidor.
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
El primer paso al configurar un servidor DHCP es crear el fichero de configuración que almacena la
informació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 configuración posee dos tipos de información:
Parámetros: Establece cómo se realiza una tarea, si debe llevarse a cabo una tarea o las opciones de
configuración de red que se enviarán al cliente.
Declaraciones: Describen el tipo de red y los clientes, proporcionan direcciones para los clientes o
aplican un grupo de parámetros a un grupo de declaraciones.
Algunos parámetros deben empezar con la palabra clave option. Los parámetros definen valores no
opcionales o que controlan el comportamiento del servidor DHCP.
Si cambiamos el fichero de configuración, para aplicar los cambios, reiniciaremos el demonio DHCP:
# /etc/init.d/dhcp restart
Subredes
Debemos incluir una declaración subnet para cada subred de la red. Si no lo hacemos, el servidor
DHCP no podrá 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 direcció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;
Redes compartidas
Todas las subredes que comparten la misma red fı́sica deben declararse dentro de una declaración
shared-network. Los parámetros dentro de shared-network, pero fuera de las declaraciones subnet se consi-
deran pará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;
option routers 192.168.1.254;
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 declaración group puede utilizarse para aplicar parámetros globales a un grupo de declaraciones.
Podemos agrupar redes compartidas, subredes, hosts u otros grupos.
group {
option routers 192.168.1.254;
option subnet-mask 255.255.255.0;
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;
fixed-address 192.168.1.6;
}
}
Más opciones
Para obtener una lista completa de sentencias de opciones e información relacionada, podemos consultar
la página del manual de dhcp-options: $man dhcp-options
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";
fixed-address 192.168.0.11;
option subnet-mask 255.255.255.0;
option routers 192.168.0.1;
option dhcp-lease-time 604800;
option dhcp-message-type 5;
option domain-name-servers 192.168.0.1;
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;
}
Si tenemos más de una interfaz de red conectada al sistema, pero sólo deseamos que el servidor DHCP
arranque en una de las interfaces, podemos modificar el script init para arrancar desde ese dispositivo.
Esto es útil si disponemos de una máquina firewall con dos tarjetas de red. Se puede configurar una tar-
jeta de red como cliente DHCP para recuperar una dirección IP en Internet y la otra puede utilizarse como
servidor DHCP para la red interna, detrás del firewall. Nuestro sistema será más seguro si especificamos la
tarjeta de red conectada a la red interna, ya que los usuarios no pueden conectarse al demonio por Internet.
-p <portnum>: Especifica el número de puerto UDP en el que DHCPD deberá 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 Transmisión DHCP, este debe escuchar por el
mismo puerto.
-d: Registra el demonio del servidor DCHP en el descriptor de errores estándar. Se suele usar para
depurar errores, los mensajes son guardados en el archivo /var/log/messages.
-cf archivo: Especifica la localización del archivo de configuración, por defecto se encuentra en
/etc/dhcpd.conf.
-lf archivo: Especifica la localizació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.
El agente de transmisión DHCP (dhcp-relay) permite transmitir las peticiones DHCP y BOOTP desde
una subred sin un servidor DHCP, dirigidos a uno o más servidores en otras subredes.
Cuando un cliente DHCP pide información, el agente de transmisión DHCP reenvı́a la petició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 petición originaria.
El agente de transmisión escuchará 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 transmisió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.
Opción Descripción
-i Nombres de interfaces de red que deben configurarse. Si no se especifica ninguna interfaz,
se configurarán todas y se eliminarán las interfaces sin multidifusión, si se puede.
-p Puerto en el que deberá 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 impresión de configuración de red, cuando arranca dhcp-relay.
En las siguientes pantallas podemos observar como realizar todos los pasos detallados en las secciones
anteriores, pero esta vez de forma gráfica.
Para ser auté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 má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 organización es pequeña (unos pocos hosts en una ú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 tamaño medio con diversas subredes deberı́a tener mú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.
Este archivo es el mismo que el original, excepto que la especificació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 configuración de named se almacenarán en /var/cache/bind/.
forwarders {
194.224.52.4;
194.224.52.6; };
Entre las opciones también se encuentra ocultar la versión de Bind, para una mayor seguridad del
sistema: "DNS server";
En los apartados siguientes iré comentando las opciones a las que se puede acceder desde el módulo
web.
Pantalla principal
Para acceder al servidor BIND, pulsamos sobre la pestaña “Servidores” y después sobre el icono “Ser-
vidor de DNS BIND”, aparecerá el menú de configuración, como se observa en la figura 9.4.
Para que todos los cambios sean tenidos en cuenta, es necesario reiniciar el servidor DNS BIND, se
realiza pulsando el botón “Aplicar Cambios” en la página de configuració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.
En esta sección podemos crear un servidor DNS primario o editar sus parámetros una vez configurado.
En esta sección podemos crear y modificar todos los parámetros de un servidor DNS secundario.
Los servidores DNS son dos (o má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 único servidor
DNS no es una práctica recomendable.
A pesar del nombre servidor “secundario”, la información que contienen estos servidores DNS, es el
mismo valor que cualquier otro servidor DNS primario, la razó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 única diferencia que existe entre un primario y un secundario en DNS, es que el secundario obtiene su
información copiando el Archivo de Zona del primario que se le ha indicado en el archivo de configuración.
La actualización de esta copia de Archivo de Zona es conocida como “Zone Transfer” y ocurre depen-
diendo de los parámetros que hayan sido definidos.
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 único que se evita en este tipo de
servidores DNS es mantener Archivos de Zona, toda resolució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
conexión lenta, esto evita la necesidad de requerir resoluciones que ya fueron resueltas en una ocasión, y
por lo tanto evitan un cierto nivel de tráfico, aprovechando la información local para buscar resoluciones
de nombres.
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 tráfico DNS entre nuestra red e Internet, configuramos el
firewall para permitir que sólo un servidor DNS se comunique con Internet. Cuando hayamos configurado
los demás servidores DNS de nuestra red para reenviar a ese servidor DNS consultas que no puedan
resolver localmente, ese servidor funcionará como nuestro único reenviador.
Aunque el web, el correo electrónico y otros servicios tienen más visibilidad y captan más la atención
del administrador, las brechas DNS ofrecen la forma más rápida y fácil de dejar a nuestra empresa fuera
del mapa de Internet. Incluso aunque tengamos conectividad IP con el mundo, sin un servicio DNS válido
para nuestros dominios, nadie podrı́a llegar a nuestro servidor web y no se producirı́a ningún flujo de
correo. De hecho, se ha citado DNS como el punto más débil en toda la infraestructura de Internet y
un objetivo potencial para los ataques del terrorismo cibernético. En lugar de introducirse en nuestros
servidores o atravesar nuestro cortafuegos, un atacante puede simplemente enviar un DoS (denegación de
servicio) contra nuestro servicio DNS, quitando del aire a nuestra empresa de una forma efectiva, o peor
aún, utilizando un tipo de ataque denominado veneno de cache DNS, los exploradores web enlazados a
nuestro sitio serán redireccionados al sitio que le apetezca al atacante.
Se conocen al menos cuatro vulnerabilidades BIND. Todas permiten a un atacante ejecutar cualquier
código con los mismos privilegios que el servidor DNS. Como usualmente BIND se ejecuta en una cuen-
ta de root, la este código puede lanzarse con los mismos privilegios. Además, se puede interrumpir la
propia operación del servidor BIND, y obtener otro tipo de información, que llevarı́a a explotar otras
vulnerabilidades diferentes en el sistema.
Presentación de una entrada especı́fica basada en una bú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 máquina puede tener sólo
las entradas que necesite para que el sistema trabaje en modo usuario único (cuando no hay conectividad
por red), por ejemplo, el archivo /etc/passwd. Cuando un programa hace una petición de búsqueda de la
información de contraseña de un usuario, el cliente comprueba su archivo passwd local y si el usuario no
existe allı́, entonces el cliente hace la petición a su servidor NIS para buscar la entrada correspondiente en
la tabla de contraseñas. Si NIS tiene entrada, la devolverá cliente y al programa que pidió la informació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 contraseña del usuario no existe. El programa deberı́a recibir la información
sin que sepa qué 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.
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. Además, el servidor NIS sólo
envı́a datos, no realiza autenticación. El proceso de autenticación de usuarios se deja a cada máquina indi-
vidual. Unicamente proporciona una lista de usuarios centralizada, ya que todos los clientes son miembros
del mismo dominio administrativo y están gestionados por los mismos administradores de sistemas.
Deberemos dar nombre a los dominios NIS, y es una buena práctica (aunque no obligatoria) usar
nombres distintos de nuestros nombres de dominios DNS. Nos será mucho más fácil explicar los dominios
de nuestra red a otros administradores identificando el dominio NIS al que nos referimos.
Para obtener más información se instala en el sistema el HowTo de NIS, documento muy clarificador:
/usr/share/doc/nis/nis.debian.howto.gz
/etc/yp.conf
/etc/nsswitch.conf
/etc/ypserv.conf
/etc/ypserv.securenets
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 (Véase apé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.
Allı́ encontraremos un Makefile. Este archivo lista los archivos que se compartirán mediante NIS,
ası́ como algunos parámetros adiciónales sobre có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 automáticamente. Este listado simplemente establece los nombres de archivos que se com-
partirá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 señ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 opción -m le dice que un servidor primario
Ypinit ejecutará el make, para construir los mapas y ponerlos en los servidores secundarios que se le
indiquen en /var/yp/yp-servers.
...
# 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
...
...
# 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
....
Editar el archivo /var/yp/yp-servers para colocar todos los servidores NIS secundarios a los que el
servidor maestro deberá 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.
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>
Hay que seguir tres pasos para configurar el servidor NIS secundario:
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.
#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 selecciónará el servidor adecuado:
#domainname proyecto
#yp.conf
#
domain proyecto server debian
domain casa server debian-home
domain trabajo broadcast
La opción broadcast indica al cliente NIS que, si nos conectamos al dominio trabajo, debe utilizar el
servidor que encuentre en la red local.
El orden correcto de los servicios dependerá del tipo de datos que cada uno de ellos ofrezca, ası́ nor-
malmente se consultará 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 administració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.
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.
Servicio Descripción
files Usa el archivo de la propia máquina
yp Usa NIS para realizar la búsqueda
nis Usa NIS para realizar la búsqueda (nis es un alias de yp)
dns Usa DNS para realizar la búsqueda (se aplica sólo al archivo hosts)
[NOTFOUND=return] Detiene la búsqueda
nis+ Usa NIS+
/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 comprobación de las configuraciones del servidor y el cliente
cliente, y probar de nuevo.
ypcat: Comentada en la sección anterior, vuelca los contenidos de un mapa NIS (archivo NIS).
ypwhich: Devuelve el nombre del servidor NIS que responde a las peticiones. También es una buena
herramienta de diagnó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 aparecerá la entrada correspondiente a esa clave. Esto es útil, por ejemplo,
para el passwd: #ypmatch josan passwd
Desde el punto de vista del cliente, la seguridad es bastante pobre. Incluso en una red local, hay que
saber que las contraseñas circulan sin encriptar sobre la red. Cualquier máquina puede “escuchar” los
intercambios entre un cliente NIS y el servidor.
Por defecto no se utiliza ningún algoritmo de cifrado en estas comunicaciones. Y como no utiliza au-
tenticación a nivel de RPC, cualquier máquina de la red puede enviar una respuesta falsa, y pasar por el
servidor de NIS. Para que el ataque tenga éxito, el paquete con la respuesta falsa debe llegar al cliente
antes de que responda el servidor. También debe ser capaz de observar la petición y generar la respuesta,
para ello es preciso que la máquina que lleva a cabo el ataque esté situada en el camino de comunica-
ción entre servidor y cliente. Se puede crear fácilmente un mapa NIS para sustituir al del servidor. Un
intruso podrá acceder al cliente NIS a través de los comandos de acceso remoto, cambiando en el mapa,
la dirección de la máquina que lleva a cabo la intrusión, por otra máquina que se encuentre en el archivo
/etc/hosts.allow.
La solución de estos problemas de seguridad pasa por utilizar autenticació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 también se han buscado algunas soluciones al problema de la seguridad. Solı́a tener un defecto
grave, dejaba su archivo de contrasenãs legible por prácticamente cualquier persona en todo Internet, esto
suponı́a un gran número de posibles intrusos. Si un intruso sabı́a nuestro dominio NIS y la dirección de
nuestro servidor, simplemente tenı́a que enviar una consulta al mapa passwd y recibir al instante todas
las contraseñas encriptadas del sistema. Con un programa rápido para crackear contraseñas, y un buen
diccionario, averiguar unas cuantas contraseñas de usuario no tenı́a ningún problema.
De todo esto trata la opción securenets. Simplemente restringe el acceso a su servidor NIS a ciertos
nodos, basándose en la dirección IP. La última versión de ypserv implementa esta caracterı́stica de dos
formas.
Se puede facilitar el montaje de una partició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 opció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 opción -o noexec es todavı́a más radical, ya que imposibilita la ejecución de programas desde
la partición montada por NFS. Si tenemos usuarios que escriben scripts esta opción puede ser muy
molesta.
Ejemplos de uso
Los ejemplos de uso de una partición NFS son numerosos. Podemos imaginar, entre otros, una partición
de lectura/escritura sobre /home. Ası́ cada usuario puede trabajar sobre cualquier má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
gestión de concurrencia de NFS no es muy fiable y exportar /var/spool/mail por ejemplo, puede producir
pérdidas de mensajes.
Podemos también compartir una partición que contenga ejecutables, como /usr/bin para ganar algo
de espacio en disco sobre las máquinas locales. Llegando al extremo podrı́amos tener ordenadores sin disco
duro trabajando directamente sobre particiones NFS.
Estrictamente hablando solo es necesario el programa mount para hacer funcionar un cliente de NFS.
Pero las utilidades de cliente son a menudo muy útiles. Showmount en este caso, nos permite ver la lista
de particiones NFS montadas por otras máquinas dentro de la red.
Cuando navegamos por una partición montada, podemos constatar una serie de cosas. Lo primero es
que los propietarios de los archivos sobre el servidor y sobre la máquina local no concuerdan. Es que Linux
no usa los nombres de usuario y grupos sino que utiliza los có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 posesión. Su partición de trabajo es importada
sobre otra má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 más evidente el uso de servidores NIS para tener un control
de usuarios uniforme.
Las diferentes versiones del protocolo NFS dejan en manos del implementador la solución de los pro-
blemas derivados de la concurrencia. Uno de los problemas má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.
El archivo /etc/exports
Contiene la lista de las má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).
Modificar dinámicamente las particiones exportadas no es posible, el servidor NFS no actualiza los
cambios realizados en el archivo /etc/exports.
Este comando nos permite interrumpir momentáneamente la exportación de uno o varios directorios.
Este comando no modifica el contenido de /etc/exports y la modificación no es definitiva. Permite prohibir
todo nivel de montaje, pero los montajes existentes no son desactivados.
Se puede usar también la opción all squash que otorga a todos los usuarios los privilegios de “nobody”
(usuario anónimo).
El paquete Samba incluye utilidades para controlar el acceso de los archivos con la misma soltura que
un WindowsNT. Además Samba puede colaborar con un servidor NT existente, o reemplazarlo del todo.
Veremos más adelante como configurarlo en detalle, pero es posible:
Proteger con una contraseña personificada para cada usuario, y dotar de permisos de acceso indivi-
dualizados.
samba-common: Contiene los elementos que van a permitir el buen funcionamiento de los otros
paquetes:
smbclient: Contiene los programas clientes, que permiten acceder a los recursos compartidos.
samba-doc: Contiene toda la documentación necesaria para configurar en detalle todos las funciones
del servidor Samba.
swat: Es una aplicación web que permite configurar el servidor Samba fácilmente. Pero para ello nos
hará falta: Apache y varios paquetes de dependencias.
Dos demonios se encargan de ofrecer los servicios del conjunto de aplicaciones Samba.
El demonio smbd es el demonio que se encarga de la compartición de recursos, pero tambié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 máqui-
nas presentes en la red sobre cuales son los recursos disponibles. Este demonio maneja también la
resolución de nombres de NetBIOS. Para ello, puede comunicarse con un servidor WINS (Windows
Internet Naming Service) que se encuentre presente en la red.
Manejar una herramienta gráfica que generará el mismo resultado. Aquı́ veremos, el manejo de
Swat (Samba Web Administratión Tool), que se trata de una interfaz que se comporta como un
servidor Web, conectándose a la máquina por medio de un simple navegador. Es posible leer la
documentación, cambiar la configuración y realizar el resto de tareas administrativas después de
habernos validado con un usuario y una contraseña. El servidor Swat, por defecto, se ejecuta en el
puerto http://localhost:901.
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 má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.
Si no lo realiza la instalación en el sistema, para poder ejecutar SWAT hay que modificar el archivo
/etc/inetd.conf. Y añadir la siguiente lı́nea:
swat stream tcp nowait.400 root /usr/sbin/swat swat
HOME : Permite acceder a la versión html de la documentació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, más configurables que la herramienta
gráfica. De un modo u otro toda esta documentación es en el fondo muy descriptiva.
GLOBALS : Contiene variables generales que se aplican al total de los recursos puestos a disposición
del servidor Samba. Esta sección contiene también información de identificació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.
WIZARD: Permite configurar de una forma rápida los archivos de configuración, establecer el modo
de funcionamiento del servidor y el servidor WINS de la red. Desdeaquı́, también podemos cambiar
la configuració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
también la totalidad de las opciones posibles, incluso las que SWAT no ha cambiado, pero que tienen
un valor por defecto.
Existen varias formas de autenticación, cada una con sus ventajas e inconvenientes:
La autenticación por usuario y contraseña: Se trata del método por defecto. Representa la ventaja
de permitir una gestión fina de los permisos. Para cada usuario es posible definir el acceso o no a
unos recursos. Este método presenta un inconveniente: cada usuario debe disponer de una cuenta en
la máquina Unix, para permitir la autenticación.
El control de acceso por comparticiones: Se trata de un método má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 contraseña adecuada para cada recurso compartido al que accedan.
Este método presenta la ventaja de que no son necesarias tantas cuentas de usuario como usuarios
haya, sino tantas como recursos se compartan.
Autenticación contra otro servidor : Existen también dos métodos indirectos de control de acceso.
• El método server : Consiste en consultar con otro servidor CIFS, que se encargara de la auten-
ticación.
• El método domain: Consiste en validarse contra el servidor de dominio NT.
El campo server string: Permite elegir la descripción que acompaña al nombre del servidor en la
lista de recursos anunciados.
El campo netbios name: Permite definir el nombre de la máquina, no como un nombre de DNS, sino
como un nombre de resolución de nombres propio del protocolo NetBIOS. Es importante entender
que son dos cosas totalmente diferentes.
El campo interfaces: Permite identificar la o las tarjetas de red que enlazan el servidor con el grupo
de trabajo.
El campo security: Permite elegir el método de autenticación, podemos elegir uno de los vistos
anteriormente.
Los menús hosts allow y host deny permiten controlar el acceso a los recursos de ciertas máquinas.
Las configuraciones hechas en esta sección se aplican a la totalidad de los recursos compartidos,
independientemente de la configuración especifica.
[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 fácilmente una impresora conectada fı́sicamente a una máquina Linux, ha-
ciendo asi accesible a todas las máquinas conectadas a la red.
Una impresora de red que no soporte mecanismos de autenticación puede ser puesta a disposición de
los usuarios gracias a un servidor de impresión de Samba, lo que permite controlar el acceso.
Esta operació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 configuración.
Por defecto Samba extrae la lista de impresoras disponibles de /etc/printcap. Si la máquina dispone de
otras impresoras, es posible añadirlas, introduciendo su nombre en el campo Create Printer y confirmando
la acció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 impresión. En general se adopta /var/spool/samba.
Autorizar el acceso guest, es permitir a cualquier usuario de una máquina miembro del grupo de
trabajo, usar la impresora.
Hay que tener mucho cuidado con esto, la integración en un grupo de trabajo no es un método fiable de
validación. Cualquier usuario de una máquina Windows puede cambiar su grupo de trabajo tantas veces
como desee sin que ningún mecanismo de autenticación se lo impida. De este modo podrı́a introducirse
en un grupo con permisos de impresión un usuario al que en principio habı́amos dejado fuera. Puede ser
necesario usar restricciones por nombre de máquina (archivos host allow y host deny) para una mayor
seguridad.
El menú browseable indica que este recurso debe ser anunciado por nmbd, y por tanto ser visible para
todos los usuarios.
Estas contraseñas son almacenadas dentro del archivo /etc/smbpasswd. Las máquinas clientes contactan
con el servidor y reciben una clave codificada usando la contraseña cifrada. El resultado es reenviado al
servidor, que hace la misma operación. Si los dos resultados son idénticos la autenticación es correcta.
Esto impide a un usuario “malicioso” hacerse con los passwords que atraviesan la red camino al servidor
en busca de la autenticación.
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 únicamente a los usuarios mencionados.
La opción read only, permite impedir a los usuarios que escriban en el directorio compartido. Pudiendo
también limitar el acceso a unos usuarios concretos.
Cuando un cliente miembro de un dominio intenta acceder a un recurso, envı́a una petición a todas las
má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 má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 má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 mé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 sección password server = nombre del servidor ) para la
autenticación. Evidentemente el servidor NT debe estar configurado para responder a las peticiones
de autenticación del servidor de Samba.
Por último, hay que asegurarse de que cada usuario, que el servidor NT va a autenticar, tiene una
cuenta en la máquina NT consiguiendo con esto que los permisos funcionen.
[netlogon]
path = /export/samba/logon
public = no
writeable = no
browsable = no
Esta compartición no ofrece el acceso a ningún recurso, sin embargo permite la autenticación de las
diferentes máquinas.
-R lmhosts: Permite consultar el archivo /etc/lmhosts, que resuelve nombres de IP contra los nombres
de NetBIOS de la máquina.
-R wins: Permite lanzar la consulta a un servidor WINS para obtener dicha conversión.
Una vez conectado al servicio en cuestión, disponemos de una interfaz de transferencia de archivos
idéntica a la del FTP. También podemos acceder a algunas opciones extra, tales como print archivo, para
imprimir un archivo local en el servidor.
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 también posible
crear copias incrementales con la opción -N fecha, que no almacena nada más que los archivos que han
sido modificados a partir de la fecha especificada.
Ahora que ya hemos instalado el servidor tendremos que modificar los archivos de configuración.
Será necesario editar este archivo y al menos, realizar los siguente cambios:
1. En ServerName, colocamos el nombre de nuestro servidor.
3. Colocamos, después de ServerType, la lı́nea ServerIdent off. De esta forma el servidor no mostrará su
versión cuando se establece una conexión.
4. Especificamos el User y el Group, si colocamos nobody nadie podrá acceder al servidor. Si queremos
colocar un usuario anónimo, se suele utilizar: user:ftp y group:nogruop.
5. Cambiamos MaxClients por el número máximo de conexiones simultaneas que deseamos permitir.
Este valor lo tendremos que determinar en función del número de usuarios del servidor, el ancho de
banda disponible y los recursos de la máquina.
Podemos especificar múltiples opciones más, que se detallan en el archivo mediante comentarios, o
podemos instalar el paquete de documentación y consultarlo allı́:
#apt-get install proftpd-doc
El archivo de configuración /etc/ftpusers contendrá los nombres de los usuarios, a los que se les per-
mitirá el uso del servicio FTP.
Desde la ventana de ProFTP accederemos a las opciones de configuración global del servidor y de los
diferentes servidores virtuales que tengamos definidos.
Algunos de los parámetros más importantes a ajustar son el control de acceso y la autenticación.
Cuando configuramos un servidor virtual podemos volver a ajustar algunos de los parámetros establecidos
en las opciones globales, como por ejemplo las opciones de autenticación de los usuarios y grupos en el
caso de que tengamos que establecer una configuración de seguridad diferente en cada servidor virtual.
Desde las opciones de configuración del servidor virtual también podremos establecer el directorio
utilizado para guardar los archivos a disposición de los usuarios que se conecten a nuestro servidor de
forma anónima.
Desde nuestro entorno Debian se ponen a nuestra disposición: gFTP (GNU FTP ).
Para instalarlo:
#apt-get install gftp, . . . para ejecutarlo: #gftp
Servicios de usuario
La idea que se esconde detrás de las cuotas es que se obliga a los usuarios a mantenerse debajo de su
limite de consumo de disco, quitá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 más de un sistema de archivos, las cuotas deben activarse en cada sistema de archivos por
separado.
Primero deberemos de asegurarnos que la opción quota está activada dentro de nuestro kernel (opció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.
El parámetro grpquota, habilita las cuotas de grupo en la partición que corresponde a /usr. El paráme-
tro usrquota, habilita las cuotas de usuario en la partición que corresponde a /home. En una misma
partición pueden haber cuotas de usuario y grupo, colocando los dos parámetros (en el ejemplo /tmp).
Ahora debemos de crear los siguientes archivos, para manejar las cuotas de la partición /home:
#touch /home/quota.group
#touch /home/quota.user
Ambos archivos de registro, deben pertenecer a root y sólo el tendrá permisos de lectura y escritura:
134 Servidor Linux para conexiones seguras de una LAN a Internet
Los comandos que se muestran a continuación nos permiten interactuar con el servicio de cuotas:
Comando Descripción
#repquota -a Produce un resumen de la informació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 perió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 más información véase el apéndice D). Es preciso arrancar las cuotas siempre después de
que los sistemas de archivos incluidos en /etc/fstab hallan sido montados, en caso contrario las cuotas no
funcionarán.
Se editarán todos los dispositivos que permitan tener cuotas de usuario, especificado en /etc/fstab.
Permitiendo modificar las cuotas del user.
Se editarán todos los dispositivos que permitan tener cuotas de grupo, especificado en /etc/fstab.
Permitiendo modificar las cuotas del grupo.
Desde allı́ podremos realizar, de forma gráfica, los mismos pasos que desde la lı́nea de comandos.
Pero no todo son alegrı́as, también existen una serie de desventajas respecto a lpd:
LPD es bastante más sencillo de hacer funcionar, para una máquina aislada con la impresora en
local.
Si no necesitamos soporte a usuarios Microsoft igual nos estamos complicando la vida con Cups.
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 módulo, lo podremos
cargar con la herramienta: #modconf, en caso contrario, no tendremos más remedio que recompilar el
kernel, con las opciones adecuadas a nuestro sistema de impresión.
Aquı́ estableceremos el acceso a la interfaz web, que nos permitirá realizar la configuración de una
forma mucho más visual y agradable. Para conseguirlo modificaremos las siguientes opciones:
ServerName host.dominio.com
ServerAdmin [email protected]
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 opció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 direcció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)
Utilizaremos el navegador que más nos guste y el método de acceso que resulte más adecuado a nuestro
sistema. En la figura 10.2 podemos observar la pantalla de presentación.
Una vez situados en la web, para configurar la impresora debemos de seguir los siguientes pasos:
Seguidamente iremos al menú de Administración y nos autenticaremos como usuario root.
Ahora hacemos clic en Añadir impresora. En este menú estableceremos un nombre a la impresora y
estableceremos el tipo de conexión.
Una vez realizado esto tendremos la impresora configurada, desde el menú impresoras podemos impri-
mir una página de prueba y comprobar que la configuración es correcta.
[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 configuración básica de Samba, deberı́amos añadir los usuarios Samba para que
se puedan autenticar contra el servidor. Lo realizaremos de la siguiente forma:
#smbpasswd usuario, . . . nos pedirá que le establezcamos una contraseña.
Una vez realizado esto, volveremos a la configuració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 sólo queda reiniciar los servicios Samba y Cups. Después todo deberı́a funcionar.
/etc/init.d/samba restart
/etc/init.d/cupsys restart
Y entraremos vı́a web a nuestro host cliente (http://localhost:631 ) para configurar una nueva im-
presora. La añadiremos de la misma forma que en el servidor.
La diferencia está en la conexió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 página de prueba, para ver si todo está configurado correc-
tamente.
Una vez hecho esto la impresora deberı́a estar configurada y lista para imprimir.
Si queremos aumentar el nivel de debug de los logs, tendremos que cambiar la opción “LogLevel” del
archivo /etc/cups/cupsd.conf, a nivel debug, de esta forma podremos encontrar el fallo.
Otra cosa primordial es consultar la documentación Cups, a lo mejor nos encontramos con que el
módelo concreto de impresora que tenemos no está soportado.
Sobre el servicio web clásico podemos disponer de aplicaciones web. Éstas son fragmentos de có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 máquina
del usuario. Son las aplicaciones tipo Java o Javascript, el servidor proporciona el código de las
aplicaciones al cliente y éste, mediante el navegador, las ejecuta. Es necesario, por tanto, que el cliente
disponga de un navegador con capacidad para ejecutar aplicaciones (también llamadas scripts).
Normalmente, los navegadores permiten ejecutar aplicaciones escritas en lenguaje javascript y java,
aunque pueden añadirse mas lenguajes mediante el uso de plugins.
Aplicaciones en el lado del servidor: El servidor web ejecuta la aplicación. Una vez ejecutada, genera
cierto código HTML, el servidor toma este código recién creado y lo envı́a al cliente por medio del
protocolo HTTP.
Las aplicaciones de servidor suelen ser la opción por la que se opta en la mayorı́a de las ocasiones para
realizar aplicaciones web. La razón es que, al ejecutarse ésta en el servidor y no en la máquina del cliente,
é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 básico puede utilizar.
Configuración de Apache
Para instalar el servidor web y realizar su configuración de una forma cómoda y sencilla, utilizaremos
unos módulos para la herramienta web Webmin.
En la figura 10.4 podemos observar la pantalla de presentación del módulo Webmin y los parámetros
de configuración que podemos modificar del mismo.
Históricamente, los archivos .conf contienen los diferentes tipos de información. Sin embargo, todas
las directrices del servidor web se pueden colocar en cualquiera de los tres archivos, y el servidor web las
interpretará correctamente. Con el fin de reducir la confusión, Apache se distribuye ahora con todas las
opciones en el archivo principal httpd.conf. Si existen los demás archivos .conf, se procesarán en el orden
siguiente: http.conf, srm.conf y access.conf. Los archivos de configuración adicionales (especialmente los
relacionados con la seguridad) deberán estar presentes en el árbol de documentos real que el servidor
procesa.
Estos archivos pueden ser modificados desde el módulo Webmin de Apache. Los parámetros a los que
se puede acceder los podemos observar en la figura 10.5.
Las directivas que se pongan en los archivos principales de configuración se aplicarán a todo el servidor.
Si queremos cambiar únicamente la configuración de una parte del servidor, podemos cambiar el rango de
acción de las directivas poniéndolas dentro de las secciones <Directory>, <DirectoryMatch>, <Files>,
<FilesMatch>, <Location>, y <LocationMatch>. Estas secciones limitan el dominio de aplicació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 selección más fino.
Apache tiene la capacidad de servir varios sitios web diferentes al mismo tiempo, esto se llama Hospe-
daje Virtual. El dominio de aplicación de las directivas también puede ser delimitado poniéndolas dentro
de <VirtualHost>, de manera que solo tendrá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 creación
de procesos solo pueden ir en el contexto del servidor principal. Para descubrir qué directivas pueden estar
dentro de qué secciones, revise el contexto de la directiva.
Archivos .htaccess
Apache permite una administración descentralizada de la configuración, a través de archivos colocados
dentro del árbol de pá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 aplicarán únicamente al directorio donde esté el archivo, y a todos sus subdirectorios.
Siguen las mismas reglas de sintaxis que los archivos principales de configuración. Como los archivos
.htaccess se leen cada vez que hay una petición de páginas, los cambios en estos archivos comienzan a
actuar inmediatamente.
Para ver qué directivas se pueden colocar, podemos consultar el contexto de cada directiva. El admi-
nistrador del servidor pueden controlar aún más qué directivas son permitidas configurando la directiva
AllowOverride en los archivos principales de configuración.
Con se puede observar en la figura 10.6, en el módulo Webmin-htaccess, podemos especificar los direc-
torios a los que se va a tener acceso a través de Apache.
Archivos de log
Cualquier persona que pueda escribir en el directorio donde Apache escribe los logs, seguramente
podrá también acceder al có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 número del proceso padre del httpd en el archivo
logs/httpd.pid. Este nombre de archivo se puede cambiar con la directiva PidFile. El nú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 registrará los mensajes de error en un archivo de log, que será 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.
Estadı́sticas Webalizer
Para poder ver las estadı́sticas de uso del apartado Web de nuestro sistema, podemos instalar el pa-
quete Webalizer, pudiéndose controlar por web mediante un módulo para Webmin.
La instalación nos pedirá que indiquemos donde esta situado el archivo de logs de Apache. También
es capaz de realizar estadisticas para el proxy Squid y los servidores FTP.
Hosts virtuales
El término Host Virtual se utiliza para referirse a la práctica de mantener más de un servidor web en
una sola má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 má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 incluyó soporte de hosts virtuales basados en
IP y basados en nombre. A partir de la versión 1.3.13 Apache tiene una nueva funcionalidad en la que
si cualquiera de los archivos de configuración es un directorio, Apache entrará en ese directorio y anali-
zará cualquier archivo (y subdirectorio) que se encuentre allı́, tratándolos como archivos de configuración.
Un posible uso de esta funcionalidad consistirı́a en añadir servidores virtuales (VirtualHosts), creando
pequeños archivos de configuración para cada servidor virtual, y colocándolos en un directorio de confi-
guración. Ası́, se puede insertar o eliminar servidores virtuales sin tener que editar ningún archivo, sino
simplemente quitando o copiando archivos. Esto facilita la automatización de estos procesos.
Con el boom de Internet y el consiguiente aumento del número de sitios web, cada vez es más frecuente
encontrar una sola máquina actuando como servidor para más de un sitio web.
Existen unas cuantas formas de proporcionar más de un sitio web desde una máquina. Una de ellas
consiste en ejecutar múltiples copias de un servidor web, una para cada sitio; sin embargo, puede resultar
imposible por lo que respecta a los recursos de la máquina.
Hay dos métodos para soportar hosts virtuales como un solo servidor. Uno se basa en utilizar múltiples
direcciones IP, una para cada sitio web, y otro se basa en soportar múltiples nombres de host en (normal-
mente) una sola direcció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 sólo el puerto que forma parte de la dirección diferencia los hosts virtuales.
Los procedimientos y los parámetros necesarios para configurar el hospedaje virtual utilizando estos
métodos diferentes se tratan en las secciones siguientes. He aquı́ unas cuantas preguntas que podemos
utilizar para seleccionar una de los métodos de hospedaje virtual:
¿Disponemos de más de una dirección IP?
¿Cuantos sitios web pensamos hospedar?
¿Necesitan todos los sitios utilizar el puerto HTTP predeterminado (80)?
¿Se han asignado múltiples nombres a la máquina?
¿Deseamos separar estrictamente los sitios web?
En el siguiente ejemplo podemos ver cómo se definirı́a un servidor virtual para el dominio www.aucad.com.
En la figura 10.8, podemos observar la configuración gráfica de Webmin para Servidores virtuales
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 configurará.
#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:
Si el servidor Apache se ejecuta correctamente volverá a aparecer el sı́mbolo del sistema y si ejecutamos
en un navegador: http://localhost, podremos ver la página de prueba ubicada en el directorio especificado
en DocumentRoot.
Si nos da algú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 automáticamente, lo deberemos colocar en uno de los scripts runlevel
(véase apéndice D), de inicio del sistema. Si hemos realizado un apt, ya se habrá colocado allı́.
Módulos Apache
Apache es un servidor modular. Esto implica que en el servidor básico se incluyen únicamente las
funcionalidades más básicas. Otras funcionalidades se encuentran disponibles a través de módulos que
pueden ser cargados por Apache. Por defecto, durante la compilación se incluye en el servidor un juego
de módulos base. Los módulos van por separado y pueden ser incluidos en cualquier momento usando la
directiva LoadModule. Las directivas de configuración pueden ser incluidas en forma condicional depen-
diendo de la presencia de un módulo particular, poniéndolas dentro de un bloque <IfModule>. Para ver
qué módulos han sido cargados en el servidor, se puede usar la opción de lı́nea de comandos -l.
Para poder realizar las configuración, en conjunto con el resto del sistema, podrı́a ser interesante
utilizar alguno de los siguientes mó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 módulos se encuentran instalados en el
sistema y habilitar o deshabilitar su uso.
En esta secció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
través del protocolo SSL (Secure Sockets Layer ).
El hecho de que el protocolo SSL esté disponible para utilizarlo con los servidores web, supone un in-
teresante dilema para los gobiernos que desean controlar los sistemas de codificació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 máquinas que se comunicasen a través de TCP/IP, codificasen la información
que se enviaran la una a la otra. Después de garantizar, de esta manera, la seguridad de una sesión de
comunicación, las dos máquinas pueden intercambiar información privada o confidencial sin preocuparse
de que alguien pueda escuchar y utilizar la informació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 información personal y confidencial, como números de tarjetas de crédito o códigos de
cuentas bancarias.
Para codificar los paquetes que viajan entre dos máquinas, las máquinas deben entender una codifica-
ción de algoritmos común, y deben intercambiar información que permita a una máquina descodificar lo
que la otra codifica. Las partes de la información de seguridad utilizadas para codificar y descodificar la
información se llaman claves.
La codificación se realiza introduciendo una modificación en la información localizada en una ubicación,
mediante una clave. Se transmite, entonces, la información a otra ubicación, donde se utiliza una clave para
restaurar la información a su forma original (descodificarla). En un sistema sencillo, la clave utilizada para
codificar la informació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 información se
mantenga también en secreto. Sin embargo, los sistemas de clave privada presentan un problema porque
la clave se debe transmitir, de algún modo, de forma segura a la nueva ubicación. SSL utiliza una forma
especial de codificación denominada infraestructura de clave pública (PKI), como parte del sistema global
que utiliza para proporcionar sesiones de comunicación segura.
En un sistema de claves como éste, se utilizan dos claves para el proceso de codificación y descodifica-
ción, y una de ellas (la clave pública) se puede hacer disponible para cualquiera sin que se vea afectada
la seguridad de las comunicaciones entre dos máquinas. De esta forma se soluciona el problema de la
seguridad de la distribución de claves, inherente a los sistemas de claves.
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 comunicación segura con el mismo, es posible que el servidor esté hablando con el servidor
web erróneo (por ejemplo, el cliente puede proporcionar un número de tarjeta de crédito a un servidor
falso ejecutado por estafadores). Cuando se utiliza un sistema de clave pública-privada, también es posible
transmitir información adicional, lo que se denomina un certificado, donde se describa al servidor web y
a la organización que hay detrás del mismo.
Este certificado puede estar “firmada” electrónicamente por una agencia de confianza. Existen varias
agencias que investigan a la organización que esté ejecutando el sitio web y la información recopilada en
el certificado y, después, firman el certificado, por un precio. Los navegadores clientes poseen una lista de
agencias de confianza que utilizan para verificar que se está comunicando con el servidor con el que el
usuario desea (es decir, que el servidor está siendo ejecutado por la organización que el usuario espera).
Cuando instalemos un servidor web, debemos crear una pareja de claves públicas-privadas y un certi-
ficado para utilizarlos con el servidor. Si deseamos ejecutar un sitio web seguro para uso público, debemos
hacer que una de estas agencias de confianza firme el certificado.
En las comunicaciones a travé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 añadida. Para acceder a un servidor web seguro, un usuario debe especificar
la URL con el identificador de protocolo HTTPS, como indico a continuación:
Uno de los errores má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 atención a la comprobación
de todas las URL que creemos y que estén vinculadas al sitio seguro.
Existen dos opción para agregar el protocolo SSL a Apache; la que se describe a continuación, y que
se recomienda usar, se denomina mod ssl. Consiste en un conjunto de parches y un módulo especial para
utilizarlos con el có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 má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 código fuente abierto).
Un archivo de claves del servidor : Este archivo contiene una clave pú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 organización. Si es una agencia de confianza quien firma este certificado, el usuario
puede confiar en que es ciertamente esa organización la que ejecuta el sitio web.
Una petición de firma del certificado: Este archivo contiene información del certificado, ası́ como in-
formación sobre la clave. Se debe enviar a la agencia de confianza (llamada autoridad de certificación)
para que sea firmado.
Todos estos archivos son creado durante el proceso de instalación de Apache-SSL. Ası́ como los nuevos
archivos de configuración que quedarán alojados en: /etc/apache-ssl/.
que el sitio es legal. A veces se le llama archivo X.509 porque ése es el nombre del está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 certificación). Cada uno de los principales navegadores que soportan el protocolo SSL
posee una lista de las autoridades de certificació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-
mación sobre dicha autoridad y el certificado preguntándole si debe continuar. De modo que dependerá del
usuario si confı́a o no en que el sitio al que está conectado sea válido.
El archivo de certificados que se ha de utilizar aparece especificado en el archivo de configuración del
servidor, mediante la directiva SSLCertificateFile
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 certificación. Para que una autoridad de certificación
nos firme el certificado, deberemos de crear un CSR (Certificate Signing Request, Petición de firma del
certificado) y envı́arla a la autoridad con la documentación y el dinero.
Existen varias agencias que actúan como autoridades de certificación, lo que implica verificar la in-
formación recopilada en el certificado y firmarlo digitalmente. El precio de este servicio se cobra por el
coste derivado de investigar la información que contiene el CSR y por asumir la responsabilidad de la
certificación de nuestro sitio web.
CatCert: http://www.catcert.net
CertiSing: http://certisign.com.br/servidores
Entrust: http://www.entrust.net
Thawte: http://www.thawte.com
VeriSign: http://www.verisign.com/site
Todas estas compañı́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 creará también la petición de firma del certificado. La información solicitada para esta petición debe
coincidir exactamente con el nombre de la compañı́a, nombre registrado del dominio y otro datos que
la autoridad de certificación solicita para que puedan procesar la petición. Además, el archivo se cifra
automáticamente en un formato especial. Podemos encontrar información detallada sobre los precios y
las instrucciones para la creación de la CSR, ası́ como la documentación solicitada por la autoridad de
certificación, en los sitios web de cada compañı́a.
POdemos actuar como nuestra propia autoridad de certificación y firmar nuestro certificado para
comprobar nuestro servidor o para ejecutarlo internamente en nuestra organización. A esto se le denomina
autocertificación. Los navegadores que se conecten a nuestro servidor no reconocerán nuestra firma, como
una de las que las autoridades de certificación contemplan como vá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 certificación al navegador del cliente.
Cuando hayamos recibido un certificado firmado por una autoridad de certificación real, sustituiremos
el certificado autofirmado copiando el nuevo sobre el archivo antiguo, o modificando el valor de la directiva
SSLCertificateFile.
Esta es la parte fácil, el siguiente paso es crear el conjunto de llaves, y después configurar el httpd.conf
para utilizarlo correctamente. Busca dónde está instalado el OpenSSL y nos aseguraremos de que está en el
$PATH, después vamos al directorio donde tengamos los archivos de configuración de apache-ssl (/etc/apache-
ssl/conf.d/ ).
Los navegadores se quejarán sobre este certificado, puesto que está creado por la persona que lo firma,
y no son fiables. Si quieres generar un certificado, y una petición de certificado para enviar a alguien como
CatCert o Verisign, entonces hay que hacer:
Ahora, configuraremos Apache para que utilize estos certificados. Se necesitan añadir varias cosas al
archivo de configuración de Apache, para conseguir que ejecute las extensiones SSL con nuestros certifi-
cados. También será preciso añadir algunas configuraciones globales.
# timeout del SSL cache, 300 es un buen valor, lo acortaremos para realizar pruebas
valueSSLSessionCacheTimeout 300
# 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
Debemos utilizar la directiva SSLCipherSuite para controlar qué 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 información entre los procesos que intervengan de la sesión SSL (y, si ası́ fuera, cuál va
a ser el nombre del archivo). Debido a que las sesiones seguras requieren un trabajo importante de
configuración, y debido a que las peticiones de los clientes pueden ser servidas por múltiples procesos
servidores hijos, el uso de una cache de sesión para compartir la información entre los procesos hijo
puede acelerar las cosas considerablemente. Debemos utilizar el valor none (ninguna) para desactivar
la cache de la sesión o dbm, seguido de la ruta del archivo que se va a utilizar para la cache de sesión.
Debemos utilizar las directivas SSLLog y SSLLogLevel para crear registros donde almacenar la
información especı́fica de SSL.
Finalmente, los certificados SSL y X.509 pueden ser utilizados también por el servidor para la au-
tenticación de los clientes utilizando los certificados: SSLCACertificatePath, SSLCACertificateFile,
SSLVerifyClient, SSLVerifyDepth y SSLRequire.
Comprobació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 codificación. Aparentemente, se ha
tomado esta medida para impedir que una herramienta de codificación muy potente caiga en manos de
terroristas y gobiernos no simpatizantes. El resultado de esta situación, sin embargo, es que la mayorı́a de
los programas buenos de codificació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 codificación que EEUU importa, ya no puede ser exportado desde
EEUU, ni al propio autor original.
Hasta hace muy poco tiempo, la compañı́a RSA Data Security, Inc. poseı́a una patente norteamericana
sobre determinados algoritmos de codificación de claves públicas-privadas utilizados en el protocolo SSL.
La patente del algoritmo de RSA expiró en el 2000, de modo que ya no existen restricciones en la mayor
parte del código. Sin embargo, si tenemos có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
organización seguramente no tendremos problemas. Si, por el contrario, pensamos distribuir el servidor web
o una máquina que lo contenga al extranjero, es necesario consultar con un abogado para conocer cuales
son las leyes de exportación e importació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 circulación de la criptografı́a más fácil. Con el tiempo se verá hacia donde nos
lleva esta tendencia.
Horde: Webmail, para consultar el correo por IMAP desde Internet. Para hacer funcionar Horde,
deberemos ejecutar además los siguientes servicios.
• Apache.
• PHP.
• Para autenticar usuarios: LDAP o MySQL.
Procmail: Procesador de correo. Es utilizado para filtrar los correos a través de los siguientes pro-
gramas
El sistema es un poco complejo pero consigue tener correo interno y externo, centralizado en el servidor
corporativo. Además podrá ser consultado desde el exterior mediante el Portal Web Horde, consiguiendo
que este libre de virus y Spam.
En las siguientes secciones detallo la configuración del sistema.
Además se nos pedirá 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 opción.
2. Nombre visible de nuestro sistema, es decir, el “mail name” o nombre de dominio en la dirección de
correo. Si no sabemos que contestar, colocamos cualquier cosa, después lo podemos modificar desde
el archivo de configuración.
3. Si tenemos otro nombre para el correo entrante, presionamos intro para dejar la opción por defecto.
6. Quien recibirá los mensajes del “postmaster” o “root”, es decir, quién recibirá los logs de error.
Colocamos un usuario del sistema que habilitemos para esta tarea.
7. Por último preguntará si queremos guardar nuestro archivo de aliases o sobrescribir el ya existente.
Por si lo necesitamos más adelante, es mejor guardar la configuración anterior.
En el archivo, /etc/exim4/exim4.conf.template, encontramos reunidos todos los parámetros de confi-
guración. Editaremos este archivo, para que reparta el correo local en el formato Maildir, consiguiendo
que sea compatible con “courier-imap” (lo utilizaremos má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 enviará al archivo: /var/mail/<usuario>, concatenándose uno detras de otro, esto es precisamente lo
que queremos evitar.
Nos situamos en la sección: 30 exim4-config mail spool. Una vez allı́ comentaremos la siguiente lı́nea:
file = /var/spool/mail/${local_part}, . . . agregándole un # delante.
Figura 10.11: Monitor para Exim a través del módulo para Webmin
Puede reenviar correo utilizando SMTP lo que permite que las reglas de filtrado, reenvı́o y “aliasing”
funcionen correctamente.
El archivo de configuración general del sistema se sitúa en /etc/fetchmail y desde aquı́ se puede
redireccionar el correo a cada usuario. Este podrı́a ser un listado tı́pico:
Creamos este archivo y lo modificamos con los parámetros de las cuentas POP3 de los usuarios, el
bloque cuenta-usuario lo podemos repetir tantas veces como sea necesario.
Después sólo tenemos que crear un archivo por usuario para que cuando ese usuario ejecute Fetchmail
lea las opciones del archivo de configuración y se descargue el correo. Ese archivo se llamara: ˜/.fetchmailrc
Ponerlo en el cron
Ejecutarlo como demonio del sistema. Para ello descomentamos la lı́nea: set daemon, del archivo de
configuración.
Si lo ejecutamos en modo daemon, le indicaremos cada cuantos segundos se ejecutara Fetchmail. Para
lanzar el demonio de forma automática tenemos que ejecutarlo, en alguno de los archivos de perfil, como
.profile o .bashrc (incluiremos la instrucción, fetchmail). Si preferimos lanzarlo manualmente, ejecutamos
desde la lı́nea de comandos: #fetchmail
Soporte para múltiples mensajes, incluyendo Ingles, Español, Francés, Alemán, Húngaro, Italiano,
Polaco, Portugués, Noruego, Ruso, . . .
Múltiples carpetas, por defecto cuenta con la opción enviar, la papelera y soporta algunas creadas
por los usuarios.
La ventaja de usar la web es que lo podemos hacer desde cualquier ordenador y siempre tendremos la
misma configuració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 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
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 están en el servidor y só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 tambié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.
Configuración de Courier-imap
Para instalarlo es muy simple:
#apt-get install courier-imap courier-imap-ssl
Configuración Maildrop
Para que el servidor solo sea accesible desde nuestra máquina. Deberemos instalar un filtro de e-mails,
para que nos coloque el correo en nuestra carpeta Maildir, o como la hayamos llamado.
Nos permite filtrar los e-mails para ası́ colocarlos en subcarpetas, según el asunto, el remitente, etc.
La configuración básica es que nos deje todos los emails en el directorio Maildir. Estas opciones son con-
figurables desde el archivo de configuración: ˜/.mailfilter.
DEFAULT="$HOME/Maildir"
logfile "$DEFAULT/.maildroplog"
Ahora solo falta comprobar su funcionamiento. Cada cierto tiempo el usuario, mediante Fetchmail,
descargará el correo en la carpeta. Después só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 perfección el
correo en formato Maildir.
A la hora de acceder al correo, deberemos colocar como nombre de servidor localhost y como usua-
rio/contraseña, el que tengamos asignado en el sistema.
Procmail es una herramienta muy potente que permite repartir el correo, filtrarlo, organizarlo en car-
petas, reenviarlo automáticamente, etc. Nosotros lo utilizaremos para pasar el antivirus ClamAv y los
filtros de Spam: SpamAssassin y Bogofilter.
Las posibilidades son prácticamente ilimitadas y dependen de nuestra imaginación y de nuestras ha-
bilidades, pero bá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, pasará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-
ración Fetchmail del usuario: ˜/.fetchmailrc.
Otra opción interesante es procesar directamente un archivo de correo (*.mbox) de forma manual, a
él se aplicarán los filtros indicados en el ˜/.procmailrc:
$formail -s procmail < INBOX.mbox
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
:0fw: spamassassin.lock
* < 256000
| spamassassin
: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 añadir al ˜/.procmailrc, para borrar los correos que cumplan una
determinada regla:
:0
* ^X-Regla: Yes
/dev/null
Desde este módulo, además de editar manualmente el archivo de configuración /etc/procmail, como
podemos observar en la figura 10.14, podemos especificar las acciones que ejecutará el filtro.
Durante el proceso de instalación clamav-freshclam (el actualizador de bases de datos de virus), pre-
guntará por qué interfaz estamos conectados a Internet y un servidor (se apuntan varios por defecto) desde
donde bajarse las actualizaciones. También podemos establecer el modo de ejecución de clamav-freshclam,
se recomienda ejecutar como demonio del sistema.
Situados en este punto, suponemos que nuestro servidor de correo entrega los correos locales correc-
tamente a Procmail. Este ejecutará las reglas de filtrado de /etc/procmailrc (y después las de: ˜/.proc-
mailrc,. . . para cada usuario) y lo dejará, tı́picamente en: /var/mail/<usuario>.
Para que Procmail ejecute ClamAv añadiremos al archivo: /etc/procmailrc, las siguientes lı́neas:
SHELL=/bin/sh
:0fw
| formail -i "X-Virus: $VIRUS"
:0fw
* ^X-Virus: Yes
| formail -i "Virus: $AV_REPORT" -i "Subject: MENSAJE CON VIRUS: $AV_REPORT"
La lı́nea de SHELL=/bin/sh es necesaria porqué se pueden tener usuarios en /etc/passwd sin shell,
en estos casos no se ejecutarı́a el código entre comillas simples.
En AV REPORT se almacena “OK”, si no tiene virus o el nombre de ese virus en caso contrario.
En la primera regla de filtrado, añadimos la cabecera X-Virus con “Yes” o “No” (ası́ el usuario final
lo puede filtrar fácilmente, tambié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. Además, modificamos el Subject y en su lugar ponemos
el nombre del virus.
Para que esta configuración funcione necesitamos tener lanzado el demonio: clamav-daemon.
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 deberá detectarlo como virus.
Una vez configurado este sistema, sólo tendremos que fijarnos que todos los correos nuevos que lleguen
a los usuarios contengan la nueva cabecera de X-Virus.
:0fw
| spamc -f -s 100000 -u $LOGNAME
Una vez instalados ambos y arrancado el spamd, sólo hay que hacer que el spamc filtre todos los men-
sajes para detectar spam.
En este apartado lanzaremos el cliente (spamc) desde: /etc/procmailrc y ejecutarlo de forma global.
Editaremos el archivo y añadiremos las siguientes lı́neas:
DROPPRIVS=yes
:0fw
| /usr/bin/spamc -f
Después en el ˜/.procmailrc filtramos los spams a una carpeta especial para separarla del correo vá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 están lo suficientemente
probadas y no nos importa perder algún e-mail válido, podemos eliminarlos, enviándolos a /dev/null
Como opción adicional se pueden especificar las opciones de configuració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
gráficamente.
La solución pasa por usar mé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 función de las palabras que contiene. Este método se denomina “bayesiano” y
esta basado en el “Teorema de Bayes” sobre probabilidad, y se adapta automáticamente al idioma y a los
tipos de mensajes que recibe cada usuario.
El problema fundamental de ésta aproximación es que hay que entrenar inicialmente al programa con
un conjunto relativamente grande de mensajes spams y otros válidos para que arme su base de datos. A
partir de allı́, el programa puede aplicar los mé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
dará muchos falsos positivos.
Una implementación mejorada de este método es Bogofilter, el filtro bayesiano que aquı́ propongo.
Configuración de Bogofilter
Para instalarlo realizaremos el siguiente apt:
#apt-get install 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 válidos y mensajes spams. Esos nú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 má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 más contenga y mayor sea la cantidad de apariciones de cada palabra en un mensaje válido
o spam, mejores serán sus resultados. Si sólo le enseñamos cuales son mensajes válidos, no podrá detectar
los spams. Al contrario, si sólo le “enseñamos” spams, considerará a muchos mensajes válidos como spams
(falsos positivos . . . ). O sea, el aprendizaje inicial es importantı́simo, y nos ahorrará mucho trabajo de
mantenimiento de la base de datos.
Configurar ˜/.procmailrc
Si queremos probar otros, el sistema Debian pone a nuestra disposición, más filtros bayesianos como
por ejemplo, spamprobe.
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 estándar de é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 fá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 será necesario ya que en la sección 10.4.5
hemos realizado un filtro que recomponı́a esa lı́nea de “From”.
Se puede encontrar una lista de más de 700 mensajes de spams. Para entrenar el filtro con estos
mensajes usaremos la instrucción:
#zcat spams.txt.gz | bogofilter -s
Configuración de Procmail
El siguiente paso es configurar Procmail. Para ello modificaremos el archivo de configuración: ˜/.proc-
mailrc de cada usuario, ya que este filtro dependerá de sus e-mails y no tendrı́a sentido aplicarlo a toda
la organización (en el /etc/procmailrc).
Una vez el mensaje ha sido clasificado como spam, modificaremos la configuración de Procmail para
que mueva los mensajes a otro archivo: ˜/mail/spams.
Además de ello, realimentaremos la base de datos con cada mensaje que llega, por lo que el sistema
irá aprendiendo con el tiempo, en pocas semanas ya no necesita casi mantenimiento.
:0EHBc
# Es un mensaje valido, realimentamos la base de datos validos
| bogofilter -n
Podemos realizar la actualización automática mediante la opción -u que indica al Bogofilter que ac-
tualice directamente la base de datos de acuerdo a la clasificació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 vá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 opción que
corresponda, -S si es un spam y -N si es un falso positivo.
Buena documentación.
Basado en estandares abiertos y libres.
Utiliza XML.
Es multiplataforma.
Su código esta liberado a la comunidad.
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 prá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 comunicación de los trabajadores de una forma eficiente, rápida y muy económica. De forma
que permite, por ejemplo, intercambiar documentos, programas, datos, textos, . . . de una forma muy
sencilla sin tener que utilizar sistemas más complejos como ftp o correo interno, es decir, consiguiendo
comunicación instantánea y directa.
Con esto, se guardaran en nuestro sistema todos los archivos básicos. Si observamos los archivos de
configuración de usuarios (/etc/passwd ) se ha creado un usuario jabber, para manejar el servidor Jabber
en el sistema. Además el servicio ha quedado agregado al arranque del sistema, en el inetd.
Configuración Jabber
La configuración se encuentra centralizada en un único archivo: /etc/jabber/jabber.xml
Lo primero que tendremos que hacer es especificar en que máquina esta el servidor, el nombre de la
misma ha de estar en formato FQDN, para que desde cualquier máquina de nuestra red pueda acceder a
los servicios proporcionados por Jabber. Otra opción es poner directamente la dirección IP de la máquina,
e incluso para realizar pruebas en la propia máquina podemos poner localhost.
Cambiaremos la lı́nea:
<host><jabberd:cmdline flag="h">localhost</jabberd:cmdline></host>
<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 múltiples clientes existentes para Jabber, (véase sección 10.18). Desde el cliente
necesitamos crear un usuario y registrarlo en el servidor local.
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 aún necesitamos más potencia para nuestro servidor de mensajerı́a instantánea, en la dirección:
http://download.jabber.org/, encontraremos más utilidades.
Para conseguir más información sobre las opciones, podemos recurrir al manual: #man jabberd
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 también nos da acceso al archivo de cofiguración
/etc/jabber/jabber.xml.
Desde el cliente nos conectaremos con una cuenta al servidor Jabber local y si no tenemos cuenta,
también podemos registrarla.
Como podemos observar en la figura 10.18, situando nuestra cuenta podemos interactuar con multitud
de servicios de mensajerı́a además de Jabber, es un cliente muy versatil.
Existen otros Clientes multiprotocolo, como Gaim (véase figura 10.19), que también funcionan muy
bien.
Al final todo es cuestión de probar y quedarnos con el cliente que más nos guste.
Comunicaciones seguras
En el interior y exterior de las redes de nuestro sistema pueden existir mú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.
SSH soluciona el problema utilizando tanto la criptografı́a simétrica como la clave pública para cifrar
la sesión desde la primera pulsación de tecla. De este modo, todo el que esté escuchando su conexión
obtiene un sonido aleatorio. SSH no sólo proporciona confidencialidad para nuestros datos utilizando el
cifrado sino que además proporciona una sólida autenticación, que impide la suplantación de identidad,
esto lo hace utilizando certificados digitales para autenticar a los usuarios.
No hay que confundir SSH con SSL, es estándar de cifrado Web. Aunque ambos realizan la misma
función, SSH funciona con cualquier protocolo, mientras que SSL está diseñado principalmente para las
comunicaciones Web.
SSH también incluye SCP, un reemplazo seguro para RPC, la herramienta de copia remota, y SFTP un
reemplazo seguro para FTP. SSH también puede utilizarse para crear un túnel con otros protocolos entre
máquinas, como HTTP y SMTP. Al utilizar esta familia de programas en lugar de sus homólogos más
antiguos, nos aseguramos de que no se están leyendo nuestras comunicaciones remotas con los servidores.
Eliminar el uso de Telnet y FTP en nuestra red puede ser difı́cil, pero cuanto más lo hagamos, más
seguros estaremos.
es recomendable asegurarse de tener la útima versión disponible, ya que el código se está mejorando
constantemente y los algoritmos se están ajustando.
SSH tiene un número de usos realmente interesantes distintos a asegurar un inicio de sesión en un
sistema remoto. Se puede utilizar para crear un túnel para cualquier servicio a través de un canal cifrado
entre servidores.
Donde login es su nombre de usuario en el sistema remoto y hotname es el anfitrión al que está inten-
tando conectar con SSH. Tambié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 sesión de josan, tendrı́amos que escribir:
$ssh [email protected]
También podemos utilizar, $ssh -l josan web.example.com para iniciar la sesión. Si simplemente
escribirmos $ssh web.example.com, el servidor supondrá que el nombre del usuario es igual que el del
inicio de sesión del sistema.
2. Después hay que revisar los archivos de configuración que se encuentran en el directorio /etc/ssh
para asegurarse de que coincide con los parámetros de nuestro sistema. El archivo de configuración
para el servidor es /etc/ssh/sshd config.
A continuació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 tendrán que cambiar
manualmente el nú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 ubicación de las claves
utilizadas para generar la autenticación de clientes. Éstas no son las mismas claves que las
claves del servidor generadas en la instalación.
3. Antes de poder utilizar un servidor SSH tiene que generar sus distintas claves. Esto proporciona un
identificador único para las claves de servidor. Para ello hay que escribir el siguiente comando:
#ssh make-host-key
Con la siguiente declaració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 &
local port: Por un número aleatorio, mayor de 1024, elegido para realizar la nueva conexión cifrada
remote port: Por el puerto del servicio con el que deseamos abrir un túnel en el extremo remoto
remote hostname: Por la dirección IP o nombre del servidor en el otro extremo de la conexión
La opción -L le indica a SSH que debe escuchar el local port en local host y enviar cualquier conexión
a remote port en remote host.
La opción -N le indica a SSH que no intente iniciar la sesión, sólo mantener la conexión abierta para
el tráfico enviado.
Si se desea que esta configuración del sistema se mantenga en siguientes reinicios de la máquina hay
que añadirla a un archivo de rc.local como se especifica en la sección D.
Como se puede observar, SSH funciona extraordinariamente bien para crear una conexión segura entre
dos máquinas para casi cualquier protocolo.
Criptografı́a asimétrica
Una revolución en el cifrado fue la iniciada cuando Whitfield Diffie, Martin Hellman y Ralph Merkle
inventaron la criptografı́a de calve pública. (En realidad, todavı́a existe algún debate sobre si el británico
James Ellis en realidad inventó 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 cómo
dos individuos que deseaban realizar una transacción financiera por una red electrónica podı́an hacerlo con
seguridad. Llevaba mucho tiempo pensando en ello porque Internet estaba naciendo en aquél momento
y el comercio electrónico todavı́a no existı́a. Si los gobiernos tenı́an muchos problemas tratando con el
problema del intercambio de clave, ¿có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 asoció con Martin Hellman y Ralph Merkle. Tardaron algunos años, pero finalmente consi-
guieron crear un sistema denominado Cifrado de clave pública (PKE, Public Key Encription), también
conocido como Criptografı́a asimetrica.
La criptografı́a asimétrica utiliza un cifrado que divide la clave en dos claves más pequeñas. Una de
las claves se hace pública y otra sigue siendo privada. El mensaje lo ciframos con la clave pública del
destinatario. Éste puede descifrarla a continuación con su propia clave privada. Y lo mismo pueden hacer
por nosotros, cifrando un mensaje con nuestra clave pú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 pública, que no tiene que mantenerse segura (de hecho, se publican en repositorios
como si fueran una guı́a telefónica). Al utilizar la clave pública del destinatario, sabemos que sólo esa
persona puede descifrarlo utilizando su propia clave privada. Este sistema permite que dos entidades se
comuniquen con seguridad sin ningún intercambio anterior de claves.
Normalmente la criptografı́a asimétrica se implanta mediante el uso de funciones de un sentido. En
términos matemáticos, éstas son funciones fáciles de calcular en una dirección pero muy difı́ciles de calcular
a la inversa. De esta forma podemos publicar nuestra clave pública, derivada a partir de nuestra clave
privada, una tarea muy difı́cil de llevar a cabo al revés para determinar la clave privada. Una función
común de un sólo sentido utilizada actualmente, es la descomposición en factores de números primos
grandes. Es fácil multiplicar dos números primos y obtener un producto. Sin embargo, determinar cuál de
las muchas posibilidades son los dos factores de un producto es uno de los problemas matemáticos más
complejos (su tiempo de computación es NP-Completo1 ).
Si alguien inventase un método para deducir fácilmente factores de números primos grandes2 en tiem-
po de computación lineal o polinómico, darı́a al traste con el mecanismo de cifrado de claves públicas
actual, haciendo que cualquier tipo de comunicación basada en este tipo de algoritmos resultase insegura.
Afortunadamente, otras funciones de un solo sentido funcionan bien para este tipo de aplicación, como los
cálculos sobre curvas elı́pticas o el cálculo de logaritmos inversos sobre un campo finito.
Poco después del lanzamiento de Diffie, Hellman y Merkle, otro grupo de tres hombres desarrolló una
aplicación práctica de la teorı́a. Su sistema para el cifrado público se denominó RSA, por sus nombres:
Ronald Rivest, Adi Shamir y Leonard Adleman. Formaron una empresa que empezó a regular su sistema.
La velocidad de adopción era lenta y su empresa estuvo a punto de quebrar, hasta que llegó el momento
de aprovechar el emergente campo comercial de Internet con una empresa, entonces pequeña denominada
Netscape. El resto es historia y ahora RSA es el algoritmo de cifrado de clave pública más utilizado. Diffie
y Hellman finalmente lanzaron una aplicación práctica de su propiedad, pero sólo útil para intercambios
de clave, mientras que RSA puede realizar la autenticación y el no reconocimiento.
Panorama actual
Hoy en dı́a, el cifrado de clave pública se encuentra detrás de cada servidor web que nos ofrece una
compra segura. Nuestra transacción se cifra sin tener que dar ni obtener una clave secreta y todo se
produce en segundo plano. Como usuarios, lo único que conocemos es ese pequeñ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 deseáramos comprar algo online tuvié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 electrónico no existirı́a tal y como existe actualmente si no
existiese la criptografı́a de clave pública.
Por lo general las aplicaciones, combinan los dos tipos de criptografı́a. Utilizan primeramente cripto-
grafı́a de clave pública para acordar una clave simétrica aleatoria. Esta clave simétrica es una clave de
sesión y sirve para realizar más rápidamente el cifrado y descifrado de la informació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.
de la informática hicieron que su funcionalidad de clave de 56 bits quedase obsoleta para información muy
confidencial. Sin embargo, todavı́a se sigue utilizando en muchos productos comerciales y se considera
aceptable para las aplicaciones de seguridad inferior. También se utiliza en productos que tienen proce-
sadores más lentos, como las tarjetas inteligentes y los dispositivos que no procesan un tamaño de clave
más largo.
TripleDES
También llamado 3DES es la versión DES má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 código (la primera clave de có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.
AES
Cuando el gobierno de los Estados Unidos se dio cuenta de que DES terminarı́a llegando al final de
su vida útil, empezó a buscar un sustituto. Hubo muchos competidores, incluyendo RC6, Blowfish del
reconocido criptógrafo Bruce Schneier y otros algoritmos meritorios. El concurso se resolvió a favor de
AES, basado en un algoritmo denominado Rijindael diseñado por dos criptógrafos belgas. Este hecho es
importante porque se utilizó una competición abierta para decidir el estándar. Asimismo, al seleccionar
un algoritmo de dos desarrolladores no norteamericanos sin intereses comerciales significativos ayudaba a
legitimar esta selección por todo el mundo. AES se está convirtiendo rápidamente en el nuevo estándar del
cifrado. Ofrece una clave de hasta 256 bits, algo más que suficiente para el futuro previsible. Normalmente,
AES se implanta en modo de 128 o 192 bits.
Certificados digitales
Los certificados digitales son las “firmas” del mundo comercial en Internet. Utilizan una combinación de
tipos de cifrado para proporcionar autenticación y comprueban que quien se está conectando es realmente
quien dice ser. En resumen, un certificado es una “certificació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 pública de la organización cifrada con la clave privada o la clave
pública de una autoridad de firmas. El uso de una autoridad de certificados o firmas se considera el
método más seguro de los dos. Si podemos descifrar el certificado con su clave publica, podremos suponer
razonablemente que el sitio web pertenece a dicha organizació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 ademá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 regulación de ningun
tipo. Obtener un certificado de VeriSign o de una de las empresas autorizadas es como si respondieran por
nosotros. Generalmente, no emitirán un certificado hasta que verifiquen la información incluida en él, bien
por vı́a telefónica o bien por otro medio de documentación en papel, como un contrato corporativo en el
que se pide autenticación en persona. Cuando han “certificado” que nuestra información es correcta, cogen
esta información, incluyendo los URL que vamos a utilizar para el certificado y la “firman” digitalmente
cifrándola con su clave privada. Después, un servidor Web o cualquier programa podrán utilizar este
certificado.
Las entidades de certificación descentralizan su misión en entidades de certificación locales en las que
confian. En Cataluña esta entidad es la Agencia Catalana de certificaciones, CATCERT.
En su página web podemos encontrar más información: http://www.catcert.net
Cuando los usuarios externos reciben datos, como una página web del servidor, y adjunta un certificado,
pueden utilizar la criptografı́a de clave pública para descifrar el certificado y verificar nuestra identidad.
Se utilizan principalmente en los sitios de comercio electrónico, pero también se utilizan en cualquier otra
forma de comunicación. Programas como SSH y Nessus pueden utilizar certificados para la autenticación.
Las VPN o las redes inalámbricas también pueden utilizar certificados para la autenticación en lugar de
contraseñas.
IPsec
Para solventar los problemas de IPv4 se desarrollo una implantació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, convirtiéndose IPsec poco a poco en un está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 combinación de clave pública y privada y además los hash añaden
también autenticación. Esta función se denomina encabezado de autenticación (AH, Autentication Hea-
der). Con AH, un hash se crea a partir del encabezado IP y é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, sabrá que
el encabezado se ha alterado de alguna manera durante el tránsito, lo que nos proporciona un alto nivel de
garantı́a de que el paquete proviene de donde dice. Podemos elegir descifrar la carga útil pero no ejecutar
un AH ya que puede ralentizar el procesamiento. AH también puede estropearse en algunos entornos con
NAT o cortafuegos.
Existen otros dos modos de operación diferentes en los que podemos ejecutar IPsec: en modo túnel o
en modo transporte.
En modo tú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 después los
envı́an al IP correcto. Una de las ventajas de utilizar este método es que los usuarios externos pueden
saber incluso cuá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 túnel.
En modo de transporte sólo se cifran las cargas útiles del paquete; los encabezados se envı́an intactos,
lo que produce un despliegue más facil y requiere menos infraestructura. Podemos seguir ejecutando AH
cuando utilicemos el modo de transporte y verificar la dirección de origen de los paquetes.
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 fácil que podı́a ser para el gobierno crear sistemas para buscar cada
lı́nea de los mensajes de correo electró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 denominó 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 más pequeños. Sin embargo, la agencia de la información de los Estados Unidos, NSA, no lo veı́a
de esa forma. Zimmerman fue investigado por infringir las leyes federales de exportación de munición por
permitir que su software se descargase fuera del paı́s. Originalmente, Phil pretendı́a buscar una empresa
que vendiera su innovación. Sin embargo, cuando el gobierno inició su persecución, distribuyó libremente
el software por Internet para que se distribuyese por todas partes. Posteriormente formó una empresa para
vender las versiones comerciales del software pero existen implantaciones de libre distribución de PGP
por todo Internet. Algunas de éstas son mas populares que otras y algunas son aplicaciones que tienen
funciones especı́ficas como el cifrado de mensajes de correo electrónico. Se pueden encontrar una lista de
todas estas implementaciones de PGP en http://www.cypherspace.org/openpgp/.
Si ya las tiene creadas y quiere importarlas, #gpg --import path/filename. Si tiene separadas la
clave pública y privada, el formato de archivo suele ser pubring.pkr y secring.skr
Si se han de crear:
Atenció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.
En el home del usuario se crea un directorio oculto .gnupg donde se almacenarán los archivos.
Una vez creadas las claves, también podemos crear un certificado de revocación que se utiliza si perdemos
nuestras claves o si alguien obtiene acceso a nuestra clave privada. Después podemos utilizar este certifi-
cado para revocar nuestra clave de los servidores públicos. Podemos seguir descifrando mensajes recibidos
utilizando la clave pública antigua (suponiendo que no la hayamos perdido) pero nadie podrá descifrar
ningún mensaje con las claves pú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 él, también podrı́a hacerse con el certificado de revocación.
Se puede colocar la clave pública en un servidor de claves para que cualquiera pueda encontrarla fá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 públicas y user con la dirección
de correo electrónico de la clave que desea publicar. Puede utilizar cualquier servidor de claves públicas
PGP ya que todos se sincronizan con frecuencia. Existen muchos servidores de claves públicas, como por
ejemplo: pgp.mit.edu, certserver.pgp.com y usa.keyserver.net.
Reemplanzando file.gpg con el nombre de archivo resultante deseado, [email protected] con la di-
rección de correo electrónico del usuario al que está realizando el envı́o y file.doc por el arcivo que se desea
cifrar. Tenga en cuenta que tiene que tener la clave pública del destinatario en su repositorio para poder
hacerlo.
También se puede utilizar GnuPG para cifrar archivos con una criptografı́a simétrica, que puede utilizar
para sus archivos locales que desea proteger o para alguien del que no tiene su clave pú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 pública del usuario para el que se ha realizado el cifrado en nuestro repositorio.
Un mensaje solicitará la frase de contraseña y, una vez introducida correctamente, GnuPG producirá 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 después procesa el archivo de salida signed.doc. Cuando se
descifra, GnuPG también verificará el documento.
Siendo signed.doc el archivo cifrado que desea verificar. También podemos crear firmas separadas
del archivo para poder acceder a usuarios sin GnuPG e incluir la firma. Éstos son los comandos para
conseguirlo:
$gpg --clearsign file.doc
Crea un apé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
Tal y como hemos mencionado anteriormente, en lugar de utilizar un sistema de confianza jerá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 algún lugar en la parte inferior de la cadena podrı́a haber una
manzana podrida, pero la idea que se esconde detrás del sistema es que se propaga orgánicamente y no
requiere ninguna estructura. Debido a ello puede desmantelarse o formarse fá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.
Donde [email protected] coincide con la dirección de correo electró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
información bá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. Asegúrese de que se trata de la clave de la persona en concreto comparándola con dicha persona
por teléfono o por cualquier otro medio de comunicación. También puede comprobar si alguien má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 esté buscando sepa que confı́a en ella.
En este modo también puede editar los niveles de las diferentes claves en su repositorio. Se introduce este
modo dentro del modo de edición de la clave escribiendo trust.
Existen muchı́simas más opciones que se pueden consultar con: $man gpg
Herramientas de seguridad
12.1.1. Ping
Ping (Packet Internet Groper, que se pude traducir como buscador de paquetes en Internet) es una
herramienta de diagnó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 má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 información sobre redes. Ping utiliza los tipos de mensaje ICMP 8 y 0,
conocidos también como Solicitud de eco y Contestación de eco respectivamente. Cuando utilizamos el co-
mando ping, la máquina envı́a una solicitud de eco a otra máquina. Si se puede acceder a la máquina que se
encuentra en el otro extremo y se ejecuta una pila TCP conforme, responderá con una contestación de eco.
El sistema B recibe la solicitud de eco y envı́a una contestación de eco: “Si, estoy aquı́”
En una sesión ping tı́pica, este proceso se repite varias veces para comprobar si la máquina de destino
o la red están bajando paquetes. Tambieén se puede utilizar para determinar la latencia, el tiempo que
tardan los paquetes entre dos puntos.
También podemos obtener estos otros tipos de mensajes ICMP cuando mandamos un ping. Cada uno
tiene us propio significado.
Red inalcanzable
Anfitrión inalcanzable
Con un ping podemos saber algo más sobre un anfitrión que si simplemente está activo o no. La forma en
que una máquina responde a un ping, normalmente, identifica el sistema operativo que está ejecutando.
También podemos utilizar ping para generar una solicitud de búsqueda DNS, que nos proporciona el
nombre del anfitrión de destino (si lo tiene), que a veces puede decirnos si esta máquina es un servidor,
un enrutador o quizá una conexión telefónica o conexión de ancho de banda. Podemos mandar un ping a
una dirección IP o a un nombre de dominio.
192 Servidor Linux para conexiones seguras de una LAN a Internet
La tabla 12.1 incluye los modificadores y las opciones adicionales para el comando ping, que pueden
resultar útiles.
# 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
64 bytes from 147.83.41.7: icmp_seq=1 ttl=241 time=130.4 ms
64 bytes from 147.83.41.7: icmp_seq=2 ttl=241 time=103.8 ms
64 bytes from 147.83.41.7: icmp_seq=3 ttl=241 time=62.0 ms
64 bytes from 147.83.41.7: icmp_seq=4 ttl=241 time=76.8 ms
64 bytes from 147.83.41.7: icmp_seq=5 ttl=241 time=61.5 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 más información sobre el anfitrión remoto. Bási-
camente, los pings que rastrean rutas (tracerotue) son anfitriones, pero cuando envı́an fuera el primer
paquete, establecen la configuración TTL (tiempo de vida) del paquete en uno. Esta configuración con-
trola la cantidad de puntos de conexión en el ordenador de la red que obtendrá antes de morir por lo que
el primer paquete sólo irá al primer enrutador o máquina más allá de la nuestra en Internet y después
devolverá un mensaje indicando que el paquete ha “expirado”. A continuación el siguiente paquete se
establece con un TTL de 2, y ası́ sucesivamente hasta llegar a nuestro objetivo, mostrándonos el trazado
virtual (la ruta) que siguen los paquetes. Se resuelve el nombre de cada anfitrión encontrado a lo largo
del camino para que podamos ver cómo cruza Internet el tráfico. Puede ser muy interesante comprobar
cómo un paquete pasa por diferentes paises antes de llegar a su destino una fracción de segundo después
y a veces, por caminos impensables y lejanos.
Esta herramienta es muy práctica cuando estamos intentando localizar el origen o la ubicación de un
intruso que hemos encontrado en nuestro logs o alertas. Podemos rastrear la ruta de la dirección IP y
saber varias cosas sobre dicha dirección. La salida puede indicarnos si se trata de un usuario doméstico
o de un usuario que se encuentra dentro de una empresa, cuál es su ISP (para poder enviarle una queja
sobre el abuso), qué tipo de servicio tiene y lo rápido que es y dónde se encuentra geográficamente (a veces
depende de la capacidad de descripción de los puntos intermedios).
12.1.3. Whois
El comando whois es útil para intentar localizar el contacto de alguien que está causando problemas
en nuestra red. Este comando consulta los servidores de nombre de dominio principales y devuelve toda
la información que tiene el registrador de nombres que le corresponda. Con esto podemos averiguar quién
es el propietario de un dominio.
Este comando es útil para ataques que provienen tanto de dentro de las redes de empresas como de los
ISP. De cualquier modo, podemos averiguar quién es la persona responsable de dicha red y comunicarle
nuestro problema. Esta solución no siempre es muy prá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 información.
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.
>>> Last update of whois database: Wed, 25 May 2005 08:39:49 EDT <<<
El comando whois normalmente muestra una lista de direcciones de correo electrónico, direcciones de
correo postal y, a veces, números telefónicos. Nos dice cuándo se creó 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 más esta información con el siguiente comando: dig.
Si administra dominios propios, debe asegurarse de que su listado whois está actualizado y es tan
genérico como pueda serlo. Al colocar direcciones de correo electrónico y nombre reales en los campos de
información, estamos proporcionando información que alguien del exterior puede aprovechar, ya sea para
una labor social como para atacar nuestros sistemas. Es mejor utilizar direcciones de correo electrónico
genéricas, dejando que los responsables reciban los mensajes enviados a esas direcciones de correo electróni-
co y evitar proporcionar una información valiosa sobre la estructura de nuestra organización técnica.
12.1.4. Dig
El comando dig consulta en el servidor de nombres determinada información sobre un dominio. Dig
es una versión actualizada del comando nslookup, que ha quedado desfasado. Podemos utilizarlo para
determinar los nombre de máquinas utilizados en una red, qué direcciones IP se unen a dichas máquinas,
cuál es su servidor de correo y otro tipo de información útil.
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 información deseada.
;; 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
En la tabla 12.2 podemos encontrar las opciones más usuales del comando dig.
12.1.5. Finger
Finger es un antiguo comando Unix que ya no se utiliza pero que se sigue ejecutando en muchas
máquinas como servicio heredado. Originalmente se diseñó cuando Internet era un lugar có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. Además a esto se une que muchos administradores se les olvida desinstalarlo o no saben cómo hacerlo.
El comando finger permite consultar, al sistema remoto, acerca de información de sus usuarios. La
sintaxis serı́a la siguiente:
$finger [email protected]
También podemos especificar una dirección IP como dominio. El resultado del finger, podrı́a ser usada
por una persona malintencionada para conseguir información má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 quién está conectado y sus nombres reales
e incluso podemos saber si están inactivos y durante cuanto tiempo. Por ú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)
$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 información, pero otras veces podemos encontrar su correo electrónico,
su plan de trabajo e incluso proyectos en los que este trabajando actualmente.
También podemos hacer consultas sobre todos los que esten conectados con la siguiente opción:
$finger -l
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 están vigilados y no depender del
cortafuegos para toda la seguridad de nuestra red.
Convertir la polı́tica sobre uso de la red y los servicios necesarios en reglas para el cortafuegos
Diseñar y utilizar un proceso como éste nos ayudará a garantizar que obtenemos mucho más de la
implantación de nuestro cortafuegos.
El método habitual, usado por la gran mayorı́a de administradores es empezar con “denegar todo” y
después añadir lo que deseamos permitir a los usuarios. Automáticamente bloqueamos todo el tráfico, a
no ser que se admita en la configuración especı́ficamente.
Para la mayorı́a de los sitios, la solución “denegar todo” es mucho mas seguro. Sin embargo, sólo
porque optemos por esta solución no significa que nuestra red sea totalmente segura. Los ataques pueden
provenir a través de cualquier brecha que hayamos creado, como la web y el correo electrónico.
12.2.3. IPTables
Esta sección describe có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 estén
familiarizados con los cortafuegos y con el arte de configurarlos. Si es nuestro primer cortafuegos, es mejor
utilizar una de las herramientas de configuración automática disponibles para crear la configuración, al
menos al principio. Estas herramientas utilizan IPTables para crear un cortafuegos utilizando nuestras
entradas. Sin embargo, es recomendable tener un conocimiento básico de lo que está sucediendo “bajo
cubierta” con IPTables antes de empezar a configurar con una de las herramientas gráficas.
Instalar IPTables
La mayorı́a de los sistemas Linux con kernel 2.4 o superior tendrán integrado IPTables, por lo que no
es necesario instalar ningún programa adicional, el servicio lo proporciona el propio kernel.
Si tenemos problemas lo más probable es que no tengamos habilitado IPTables en el kernel, tenemos
que recompilar el kernel.
1. Módulos básicos
CONFIG NETFILTER
CONFIG PACKET
CONFIG IP NF CONNTRACK
CONFIG IP NF FTP
2. Tabla filter (actú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
Utilizar IPTables
La idea que se esconde detrás de IPTables es crear canales de entradas y procesarlas de acuerdo con
un conjunto de reglas (la configuración del cortafuegos) y enviarlas a continuación a canales de salida. En
IPTables, estos canales se denominan tablas.
Donde command, rule-specification y extensions son una o más opciones vá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 éstos son los más comunes. Para obtener una lista completa
de listados, consulte el manual de IPTables escribiendo:
$man iptables
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 conexión LAN local y que la interfaz eth0 es la conexión WAN o Internet.
Ası́ eliminamos cualquier regla para la cadena FORWARD, que es el “conducto” principal para
cualquier paquete que desea pasar por el cortafuegos.
Ası́ eliminamos cualquier regla en su máquina local y en su cadena de salida, también podiamos
haber usado: iptables -F, afectando a todas las cadenas a la vez.
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 transmisió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 declaración rechaza cualquier paquete que provenga de la interfaz eth0 de Internet con la
dirección interna 192.168.0.0/24. Por definición, ningún paquete deberı́a provenir de una interfaz de
no confianza con una dirección de fuente privada e interna. La segunda declaración retira cualquier
paquete del protocolo ICMP que provenga de la dirección exterior a la interior.
6. Generalmente aceptaremos el tráfico entrante basado en conexiones iniciadas desde el interior, por
ejemplo, alguien que explora una página Web. Siempre que la conexión esté en curso y se haya
iniciado internamente, probablemente sea correcta. Sin embargo, podemos limitar el tipo de tráfico
permitido. Supongamos que sólo deseamos permitir a los empleados el acceso a la Web y al correo
electrónico. Podemos especificar los tipos de tráfico para permitir sólo el que esté en una conexión ya
iniciada. Podemos saber si es una conexión existente comprobando si se ha establecido la parte ACK,
es decir, si se ha producido la conexión TCP de tres vı́as. Las siguientes declaraciones permiten el
tráfico web basado en este criterio.
La declaración --dports indica que sólo se permite el correo electrónico y la Web y la declaración
de indicadores –tcp indica que sólo deseamos paquetes con el campo ACK establecido
7. Para poder aceptar conexiones de entrada desde el exterior sólo en determinados puertos, como un
mensaje correo electrónico entrante en nuestro servidor de correo, usamos este tipo de declaración:
iptables -A FORWARD -m multiport -p tcp -i eth0 -d 192.168.0.0/24 --dports smtp
--syn -j ACCEPT
El indicador de múltiples puertos -m indica a IPTables que vamos a emitir una declaración de
coincidencia para los puertos. La declaració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 sólo el tráfico
de correo SMTP.
8. Podemos permitir que los usuarios inicien conexiones de salida pero só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 direcció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 podrán resolver direcciones. Como no disponen de un estado como los
paquetes TCP, no podemos fiarnos de la revisión de los indicadores SYN o ACK. Deseamos admitir
UDP sólo en el puerto 53, por lo que especificaremos: domain (una variable integrada para el puerto
53), como ú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. También podemos especificarlos para los paquetes ICMP. Lo que pretendemos es permitir todo tipo
de ICMP interno hacia el exterior, pero sólo determinados tipos como la contestació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 último, vamos a establecer el inicio de sesió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 ningún
problema, para tener una idea de los tipos de tráfico que se han rechazado. Si observa paquetes
rechazados repetidamente de la misma red o dirección, puede que esté siendo atacado. Existe una
declaración para registrar cada tipo de trá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 protección a nivel de cortafuegos ante los ataques más comunes de
internet. El siguiente código es el ejemplo en un script.
# 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
Al utilizar estas direcciones en nuestra LAN interna y tener una IP externa enrutable en nuestro cor-
tafuegos, estamos protegiendo con efectividad nuestras máquinas internas ante el acceso desde el exterior.
Podemos proporcionar esta capa adicional de protección fá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 continuación se envı́a el paquete de datos a su destino con
una dirección IP de origen de la interfaz pú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 también se conoce como Traducción de dirección de red (NAT, Network
Address Translation). Con las siguientes declaraciones podemos hacerlo en IPTables:
Conclusiones
Bueno, ahora ya sabemos cómo crear un cortafuegos básico. Se trata de una configuración bastante
sencilla y las posibles variaciones son infinitas. Podemos enviar determinados puertos a servidores inter-
nos para que no tengan una dirección IP pública. Podemos colocar otra tarjeta de red en el servidor y
convertirla en una interfaz DMZ para servidores con dirección pública. Existen libros completos sobre la
configuración avanzada de cortafuegos y muchas listas de correo.
Existen otros métodos mas simples y rápidos de crear un cortafuegos, sin introducir comandos y
tener que recordar la sintaxis. Muchas herramientas crean las declaraciones del cortafuegos utilizando una
interfaz gráfica, es decir, de forma automática.
Para simplificar el método utilizare el módulo Firewall para Webmin, basado en IPTables.
Ahora veamos un ejemplo del archivo /etc/squid/squid.conf donde se limita el ancho de banda, para
la conexión:
#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
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
#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.
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
En este caso utilizaré la herramienta Bastille Linux, disponible en la distribució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 basándose en nuestras indicaciones.
Simplifica extraordinariamente el proceso de fortalecimiento y lo reduce a responder a algunas preguntas.
12.4.1. Ejecució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 algún servidores,
produciendo cortes de servicio o detenció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 aplicación deben de estar instalados los siguientes paquetes:
También podemos ejecutar Bastille en lo que se denomina modo no interactivo. Este modo ejecuta Bas-
tille automáticamente, sin hacer preguntas, desde un archivo de configuración preasignado. cada vez que
ejecutamos Bastille, se crea un archivo de configuración. A continuación podemos utilizarlo para ejecutar
Bastille en otras máquinas en modo no interactivo. Esta técnica es útil para cerrar rápidamente múltiples
máquinas. Cuando disponga del archivo de configuración con los elementos deseados, simplemente cargue
Bastille en las máquinas adicionales y copie el archivo de configuración en dichas máquinas (o deje que
accedan al archivo por la red).
Donde config-file es el nombre y la ubicación del archivo de configuración que deseamos utilizar.
Almacenar las copias en el propio disco fı́sico del servidor (no se recomienda).
Utilizar cintas de backup.
12.5.2. Mt
El programa mt proporciona controles simples para la unidad de cinta, como el rebobinado, expulsión
o la búsqueda de un archivo. En el contexto de las copias de seguridad, mt es muy útil como mecanismo
de rebobinado y búsqueda.
Todas las acciones de mt se especifican en la lı́nea de comandos. El cuadro 12.7 muestra los parámetros
del comando.
Cuadro 12.7: Opciones del comando mt, para manipular cintas de backup
Parámetros Descripción
-f <dispositivo> Especifica el dispositivo de cinta.
fsf <cuenta> Avanza un nú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 despué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 (sólo aplicable a ciertas unidades de cinta).
unlock Desbloquea la puerta de la unidad (sólo aplicable a ciertas unidades de cinta).
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 última vez que se realizó 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 tambié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 información sobre sus operaciones en el archivo /etc/dumpdates.
Este archivo lista cada copia de seguridad de un sistema de archivos, cuándo se hizo y de qué nivel. Dada
esta información, podemos determinar que copia debemos restaurar.
En el cuadro 12.8 se muestran los parámetros más usuales del comando dump:
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 esté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 verificació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 después de copias de seguridad erróneas (y no queremos ser uno
de ellos).
Durante mis estudios en la FIB (Facultad de Informá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, sólo
se hechan de menos cuando nadie las ha hecho”.
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 travé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.
Donde tenemos el archivo dump en /dev/st0, visualizaremos cada paso que tome restore y entraremos
en una sesión interactiva donde decidiremos qué 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
Los Sistemas de detección de intrusiones (IDS, Intrusion Detection System) son básicamente sniffers
modificados que pueden ver todo el tráfico de la red e intentan detectar un tráfico potencialmente dañino,
alertándonos de ello cuando aparezca.
La forma principal de conseguirlo es examinando el tráfico de entrada e intentándolo comparar con
una base de datos de actividades dañinas conocidas denominadas firmas. Esta utilizació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 basándose en las direcciones IP, los números de puertos, el contenido y cualquier número
de criterios.
Existe otra forma de realizar una detección de intrusión en el nivel del sistema comprobando la inte-
gridad de los archivos clave y asegurándose de que no se ha realizado ningún cambio en dichos archivos.
También existen otras tecnologı́as emergentes que combinan el concepto de detección de intrusión y
cortafuegos o realizan una acción posterior más allá de la pura detección.
Sólo puede ver el trá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 razón para vigilar nuestro tráfico interno de red. Las estadı́sticas demuestran que un
setenta por ciento de los incidentes en crı́menes informáticos provienen de un origen interno. Por mucho
que nos guste pensar que nuestros compañeros no van a hacer nada para dañarnos, a veces no es el caso,
los intrusos internos no siempre son piratas informáticos que trabajan por la noche. Pueden ser desde
un administrador de sistemas contrariado, un empleado descuidado o hasta la señora de la limpieza. El
simple hecho de descargar un archivo o de abrir un archivo adjunto de un mensaje de correo electrónico
puede cargar un troyano que creará 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.
1. En la red LAN local, detrás del cortafuegos: Es el lugar más común, ofrece la mejor protecció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).
Tambié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 generará muchas alertas basadas en el tráfico de red de Windows, por lo que
debemos estar preparados para realizar muchos ajustes en este á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 tráfico LAN.
2. En el segmento DMZ : Podemos colocar un sensor Snort en la DMZ para registrar la actividad que
entra en los servidores públicos. Como esos servidores son los más expuestos y normalmente repre-
sentan recursos valiosos, es buena idea supervisarlos con un IDS. El problema de esta configuración
es ordenar todas las alertas. Aunque todas ellas puedan ser alertas válidas, con el nivel de ataque de
tráfico general actual en Internet, cualquier IP pú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, ¿cómo podemos saber qué alertas son sólo gusanos que están atacando a nuestro
servidor y qué alertas están realmente avisándonos de un intruso real?. Una forma de hacerlo es
reduciendo el número de firmas a un pequeño número que sólo se activen si el host está realmente
comprometido, por ejemplo, reglas especı́ficas a las aplicaciones que se están ejecutando en el host,
como MySQL.rules, web-iis.rules o reglas relacionadas con la administración de conexiones.
3. Entre el ISP y el cortafuegos: Esta configuración filtrará todo el tráfico entrante y saliente de la
LAN y DMZ. Lo bueno es que capturará todos los ataques tanto a los servidores públicos como a
la LAN interna. Lo malo es que no podrémos ver ningún tráfico interno y el volumen general de las
alertas puede ser bastante alto, debido al tráfico de ataque general subyacente.
Igual que en el ejemplo anterior, se puede probar a reducir las alertas y dejar sólo las que realmente
van a mostrar algú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 tráfico de red.
Todas las formas puede ser válidas para utilizar un IDS y no hay razón para que no podamos seguir
las tres, siempre que tengamos el hardware y el tiempo necesario para hacerlo.
Las causas más comunes de los falsos positivos se describen en los siguientes apartados.
Actividad de usuario
La mayorı́a de los sistemas de detección de intrusión de redes se configuran para marcar diversas
actividades de usuario peligrosas, como compartir archivos punto a punto, mensajerı́a instantánea, etc.
Sin embargo, si permitimos este tipo de actividad, bien por polı́tica formal o simplemente sin imponer las
polı́ticas existentes, se mostrarán como alertas en nuestro registros.
Éste serı́a un buen momento para imponer o crear polı́ticas contra su utilización ya que podemos
demostrar cuá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.
de datos tienen trabajos en proceso y mucha actividad administrativa incluso si no se están consultando.
Esta actividad, aunque legı́tima, generará muchas de estas alertas.
Si nuestras bases de datos están en constante desarrollo, probablemente deberemos desactivar dichas
alertas, al menos hasta que se estabilicen y tengan un uso normal.
La otra alternativa es enviar un mensaje de correo electrónico o una pá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 electrónico no estarán en
un formato en el que se puedan comparar con alertas pasadas o analizadas de otra forma.
La mejor solución para controlar las alertas IDS es insertarlas en una base de datos, para permitir un
análisis más profundo. Existe una herramienta de libre distribución para los sistemas de detección
de intrusiones denominada Analysis Console for Intrusion Database (ACIDlab, véase sección 13.8).
Para obtener más información sobre el programa, estos módulos o otros podemos consultar la web:
http://www.snort.org
Ligero: Debido a que el código se ejecuta de una forma eficiente, no requiere mucho hardware, lo
que permite poder analizar trá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 fácil para ampliar y personalizar el programa es-
cribiendo nuestras propias reglas o firmas. Existe mucha documentación que puede ayudarnos a
aprender a hacer reglas (véase sección 13.5.9), sin mencionar la cantidad de foros sobre el tema.
13.5.2. Instalación
Para instalarlo simplemente realizaremos el apt del paquete:
#apt-get install snort
==========================================================================
Creará archivos de registro en el directorio /var/log/snort. Snort registra paquetes por dirección IP y
crea un directorio independiente para cada IP registrada. Si estamos registrando tráfico en una red local
grande con muchas direcciones, esto puede escaparse rápidamente a nuestro control.
Podemos utilizar otra configuració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 notación
de barra inclinada. Esto hace que Snort coloque las direcciones basándose en la dirección IP del paquete
externo a la LAN, para poder ver con más facilidad el tráfico ajeno a la red. Si tanto los anfitriones de
destino como de origen son locales, Snort los coloca en el directorio con el número de puerto superior,
aparentemente para recoger el host de conexión sobre el host servidor.
Snort utiliza la dirección de origen como nombre del directorio en el que se colocarán los datos de los
paquetes, cuando registramos alertas de intrusión es importante saber con facilidad de dónde está provi-
niendo el tráfico de alertas marcado.
Esta declaración especifica una red interna en el rango comprendido entre 192.168.0.1 y 192.168.0.254.
También podemos utilizar la opció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 registrará los
archivos secuencialmente en un gran archivo. Este método es mucho más rápido para registrar redes de
muchos registros o si Snort funciona en un máquina lenta. También facilita el análisis con herramientas
más complejas, algo necesario si vamos a buscar sobre una gran cantidad de datos de red capturados.
terminado, pero debemos realizar cambios antes de ejecutarlo, para que refleje nuestro perfil de red.
Tambié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 módulos de salida independientes
que ofrecen una variedad más amplia de opciones de salida. Éstas deben configurarse en el tiempo de
compilación con modificadores añadidos a la declaración de configuración.
SMB : Envı́a las alertas al servicio de menú emergente de Windows. Para esta opción hay que
descargar las fuentes y compilarlas con la opción enable-smbalerts.
Para ejecutar Snort con esta configuració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 ayudará a consolidar registros de red en un lugar único. Este servicio dificulta
a un intruso borrar los rastros de la intrusión. Podemos especificar los formatos Syslog dentro del
archivo de configuració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 módulo de salida de base de datos requiere: parámetros y configuraciones, dentro del
archivo de configuración y en tiempo de compilación.
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 declaración:
var HOME_NET addresses
Donde debemos de reemplazar addresses con el espacio de direcciones de nuestra red local. Si existen
múltiples redes, podemos introducirlas todas separándolas por comas. Podemos incluso introducir
un nombre de interfaz y utilizar la dirección IP y la má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 está escuchando Snort.
También podemos definir nuestras redes externas con una declaración similar a HOME NET, reem-
plazá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 configuración podemos definir nuestros ser-
vidores de red, incluyendo web, mail, dns, telnet, . . . Ası́, limitaremos los falsos positivos para los
servicios en esas máquinas.
También podemos especificar los números de puertos para dichos servicios, entonces si nuestros
usuarios usan ese puerto, no se registrará ninguna alerta. Todas estas opciones de configuración
pueden ayudarnos a reducir el número de falsos positivos que obtenemos y alertarnos sólo con
informació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 configuración.
Estas rutinas se ejecutan en el tráfico antes de pasar por ningún conjunto de reglas, normalmente
para formatearlas correctamente o para tratar con un tipo determinado de tráfico que sea más fácil de
procesar directamente en lugar de utilizar los conjuntos de reglas. Un ejemplo de este tipo de tráfico
serı́an los paquetes fragmentados-defragmentados. Muchos ataques intentan ocultar su verdadera
naturaleza fragmentando los paquetes, en esos casos, esta opción es muy valiosa.
Otro decodificador es para los paquetes de escaneado de puertos. Como é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 más seguro ante una denegació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 mó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 módulos de
salida que podemos utilizar, dependiendo del formato en el que deseemos los datos: Syslog, Database
y el nuevo módulo denominado Unified, que es un formato binario genérico para exportar datos a
otros programas.
Las opciones de configuración para cada mó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 direcció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 válida, user name por un
nombre de usuario válido en la base de datos y password por la contraseñ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 último, database address es la direcció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 bá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 añ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 tráfico ping o todas las
reglas NetBIOS si no tenemos máquinas Windows en nuestra red. También podemos encontrar
disponibles conjuntos de reglas que se han ajustado para entornos especı́ficos.
El signo de concatenación & indica que se debe ejecutar Snort como un proceso en segundo plano.
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.
Registro de cambios.
Diferentes idiomas.
Para acceder al sistema, con SSL y si no hemos cambiado el puerto por defecto:
https://localhost:10000
Una vez iniciada la sesión en la página de Snort (véase figura 13.1), podremos ver las secciones prin-
cipales del archivo de configuración, las configuraciones del procesado previo y las opciones de inicio de
sesión en la parte superior de la ventana. Haga clic en cualquiera de las opciones de configuración para
introducir su información personal para que Webmin realice los cambios apropiados en los archivos de
Snort.
Todos los conjuntos de reglas aparecen en una lista, podemos ver cuáles está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 pá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 números de Vulnerabilidad
o exploit comúnes (VCE, Common Vulnerability or Exploit), podemos hacer clic en un hipervı́nculo para
abrir más detalles sobre lo que hace la alerta. En esta interfaz se puede ajustar el conjunto de alertas más
fácilmente.
Con el módulo Webmin Snort también podemos configurar usuarios para que puedan acceder a de-
terminadas configuraciones. Esto se realiza mediante el control de usuarios de Webmin, en la sección
correspondiente de acceso a Snort. Podemos controlar los archivos de configuració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 módulo Webmin Snort nos proporciona un control de acceso granular para que podamos
delegar las tareas diarias en usuarios con privilegios de administración, a la vez que seguimos conservando
el control de la configuración y los cambios.
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";)
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 dirección de origen es la primera, lis-
tada en la notación de barra inclinada estándar para los rangos IP. También podemos listar múltiples
direcciones individuales y redes separándolas con una coma, sin espacios y escribiendo la declaración entre
corchetes, por ejemplo:
Esta sentencia se centra en el tráfico que proviene de cualquier dirección enlazada para las má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 tráfico entrante con los datos hexadecimales de la sección de contenido.
La segunda parte de una alerta Snort son las opciones de la regla. Aquı́ es donde podemos especificar
más detalles sobre el tipo de tráfico que estamos buscando. Podemos buscar según los campos del encabe-
zado TCP/IP o buscar simplemente la cargar útil del paquete. Después de cada comando debemos incluir
comillas y el valor que se está buscando. Podemos añadir múltiples opciones separándolas con un punto y
coma.
Los métodos de detección de intrusión basados en hosts tienen las siguientes ventajas:
Los métodos de detección de intrusión basados en hosts tienen los siguientes inconvenientes:
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 qué nivel de detalle debe
introducirse. El archivo principal de polı́ticas es: /etc/tripwire/twpol.txt. Éste no es el propio archivo de
polı́ticas, sino una copia de la versió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 código o nombres de variable, denominadas máscaras
de propiedad, y representan las propiedades que está registrando Tripwire.
El cuadro 13.6 recoge la lista de los elementos que se pueden registrar para cada archivo y sus letras
de código.
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 más (+) y para ignorarlas un signo menos (-).
Producirı́a que Tripwire nos notificase en cualquier momento, cuándo se produjo el último acceso, la
fecha de creación o modificación, los permisos, la propiedad o el tamaño del tipo de archivo, cambiado en
el archivo /etc/secreto.txt.
Existen además diversas máscaras de propiedad predefinidas. En el cuadro 13.7 se incluyen dichas
máscaras plantilla y sus efectos.
#
# 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 má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 qué archivos se están registrando.
Una vez hecho esto, ya estaremos preparados para ejecutar 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. Verificará los atributos de dicho archivo, según las especificaciones del archivo de polı́ticas y
devolverá un informe con los cambios producidos.
===============================================================================
Report Summary:
===============================================================================
===============================================================================
Rule Summary:
===============================================================================
-------------------------------------------------------------------------------
Section: Unix File System
-------------------------------------------------------------------------------
===============================================================================
Object Summary:
===============================================================================
-------------------------------------------------------------------------------
# Section: Unix File System
-------------------------------------------------------------------------------
No violations.
===============================================================================
Error Report:
===============================================================================
No Errors
-------------------------------------------------------------------------------
*** End of report ***
Tendremos que reemplazar path reporte anterior con el nombre y ruta de acceso del archivo de informe
más reciente. La ejecución de este comando nos mostrará 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 actualizará la firma para dicho archivo cuando salgamos de éste. Si elimina la X, Tripwire
supondrá que la firma original es la correcta y no la actualizará. Al salir, Tripwire ejecutará dichos cambios.
Tambié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.
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 pedirá que
introduzcamos la contraseñ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.
http://acidlab.sourceforge.net/
La idea que se esconde detrás de ACID es portar todos los datos de detección de intrusió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 múltiples sensores para los
datos de entrada. Acepta alertas Snort y archivos de registro ajustados a los registros del sistema.
Actualmente, ACID só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 travé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 través de una base de datos MySQL con ACID debemos instalar el paquete:
#apt-get install snort-mysql
Sustituirá el antiguo Snort por otro que produzca las salidas en una base de datos MySQL.
Es muy recomendable instalar ACID en una máquina independiente de Snort. Colocarlos en la misma
máquina no sólo es poco recomendable desde el punto de vista de la seguridad sino que además inundará 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.
Configuración de ACID
Este es el archivo de configuración del sistema ACIDlab:
/etc/acidlab/acid_conf.php
Ejecución de ACID
Una vez ajustado el archivo de configuración nos debemos conectar a la dirección:
http://localhost/acidlab/acid_main.php
Se muestra la página de configuración de ACID. A partir de este momento podremos utilizar la interfaz
web para terminar la configuració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”.
Número de las diferentes direcciones IP de origen asociadas con dicha alerta (<Src. Addr.>).
Nú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 algún tipo de patrón?
¿Provienen todas las alertas de la misma dirección IP?
¿Se dirigen todas las alertas a la misma dirección IP?
¿Se producen a intervalos regulares o lo hacen de forma aleatoria?
Si este análisis no nos conduce a ninguna conclusión, se puede buscar con más detalle haciendo clic en
las alertas individuales.
Basándose en la IP del emisor, podemos utilizar esta información para determinar si se trata de
una dirección que normalmente está accediendo a nuestra red. También podemos mirar más abajo para
comprobar la parte útil del paquete (Se ve en hexadecimal y ASCII).
Si determinamos que es un ataque al sistema podemos intentar tomar medidas. Normalmente será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 máquina atacada
esta protegida contra ese tipo de ataque y enviar una queja al ISP del atacante. También se pueden
ejecutar otras acciones contra la dirección IP que aparece como IP de origen, como una persecución legal
o una acción civil, si se ha producido con éxito la intrusión.
Al menos sabremos exactamente qué tipo de ataques se están produciendo en nuestra red y lo que
están intentando hacer, Ası́, nuestra red estará más protegida y podremos reaccionar si se produce un
ataque.
¿Quién es el objetivo del ataque? Al utilizar ACID, buscamos las direcciones IP más comunes ya que
muestran las direcciones IP que supuestamente son las más atacadas y, por consiguiente, habrá máquinas
sobre las que debemos centrar nuestros esfuerzos de protección, algo que nos ayudará a diferenciar entre
los falsos positivos y los positivos reales. Podremos localizar cualquier máquina que esté generando un
gran número de alertas desde una aplicación que se está ejecutando.
Un incremento súbito en las alertas hacia una dirección IP determinada puede apuntar que se esta
iniciando un ataque sobre dicha máquina. A continuación, podemos ejecutar escáneres de vulnerabilidad,
comprobar los niveles de seguridad, restringir direcciones de IP origen en el enrutador, etc.
¿Quién está atacando? Buscamos la dirección de origen IP que aparece con má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 dónde proviene el ataque. La ordenación
por el número de alertas permite ver a los peores atacantes, según la generación de alertas. Si las direcciones
IP con la mayorı́a de las alertas están en nuestra red, puede existir un culpable interno o una aplicación
que esté 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 trá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 dirección se abre una página con información adicional sobre la dirección y algunas opciones
para analizarla con más detalle.
Analizando esas salidas podremos encontrar qué organizació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.
¿Cuál es el servicio más atacado? Al buscar los puertos más comunes en los que las alertas se están
recibiendo podemos comprobar cuáles son los servicios más atacados. Si comprobamos que hay muchas
alertas basadas en web, deberemos de tener más cuidado en el bloqueo de servidores web.
Si las alertas muestran mucha actividad NetBIOS de Windows, tendremos que mirar las polı́ticas de
contraseñas y permisos de Windows. Ası́ podremos saber cuáles son los servicios en los que debemos
centrar primero nuestra atención.
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 más potentes.
logcheck.sh: Es el programa que se ejecutará cada vez que sea invocado logcheck. Es un script en
shell normal, e incluye la configuración en un formato fácil de comprender.
logcheck.hacking: Tiene la lista de cadenas con las que una lı́nea será identificada como intento de
entrar al sistema o de conseguir información acerca de él, y por tanto serán reportadas como ataques
activos, llamando la atenció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 más especı́fico: Si una lı́nea concuerda con una de las expre-
siones de logcheck.violations pero también concuerda con una de éste archivo, la lı́nea es ignorada.
tmp: Es el directorio temporal utilizado por el programa para procesar los datos.
Además de estos archivos, logcheck instala el programa logtail en /usr/local/bin. Este programa man-
tiene la información de qué logs han sido analizados y hasta qué punto, para no perder ni repetir lı́neas.
Logcheck por defecto analizará 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 configuración:
PATH : Indica dónde buscará el sistema los binarios. Debemos recordar que se ejecutara con una
llamada desde cron, por lo que no hace daño definirlo, y tal vez limitarlo al mı́nimo necesario.
SYSADMIN : Es la persona que recibirá el reporte por correo. Si no lleva una dirección completa,
asume que es una dirección local.
LOGTAIL: Indica el path completo para el programa logtail.
TMPDIR: Especifica el directorio temporal que usará el programa. Este debe ser un directorio
seguro, que no tenga acceso de escritura má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 será 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
Ejecució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 será enviado por correo, lo más común es hacerlo cada
hora. Para ello es necesario crear una entrada en el crontab de root o de algún usuario que tenga permiso
de leer los archivos localizados en /var/log.
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
En caso de haberse registrado algún evento que concuerde con alguna lı́nea de logcheck.hacking, para
que el reporte sea visto más rápidamente por el administrador cambiarán los encabezados, quedando ası́:
From [email protected] Wed Sep 27 21:52:58 2000
Date: Wed, 27 Sep 2000 21:00:05 -0500
From: root <[email protected]>
To: [email protected]
Subject: hostname.dominio.com 09/27/00:21.00 ACTIVE SYSTEM ATTACK!
Security Violations
=-=-=-=-=-=-=-=-=-=
Sep 27 20:09:19 hostname PAM_pwdb[14589]: authentication failure; (uid=0) -> root for ssh service
Sep 27 20:09:22 hostname PAM_pwdb[14589]: (ssh) session opened for user root by (uid=0)
Sep 27 20:09:22 hostname sshd[14589]: log: Password authentication for root accepted.
(...)
La manera más común en que un atacante va a intentar obtener información acerca de nosotros es
el barrido de puertos: Intentar conectarse a cada uno de los puertos que tiene abiertos nuestro servidor,
anotando qué es lo que tiene activo y analizando dicha información. Una de las herramientas más comunes
para realizar barridos de puertos es el Nmap (véase sección 17.2).
Tras haber hecho esta prueba, el atacante puede intentar entrar a cada uno de los puertos abiertos,
revisando si encuentra alguna versión vieja o vulnerable.
Detectar un barrido de puertos es muy fácil: Muchas conexiones casi simultáneas a una gran cantidad
de puertos originadas desde la misma dirección. Si bien los programas barredores se han vuelto muy
sofisticados y cada vez es más difı́cil detectarlos por diferentes estrategias que emplean (Nmap sabe hacer
desde una sencilla conexión TCP hasta un barrido silencioso con SYN, FIN, Xmas, Null, UDP, paquetes
fragmentados y barridos paralelos de diferentes tipos), el principio básico es el mismo.
Hay un excelente programa dedicado precisamente a encontrar éste patrón y tomar la acción que le
indique el administrador del sistema: Portsentry.
Portsentry es un programa muy sencillo. Su misión es “sentarse y escuchar” en los puertos que le
indiquemos que deben permanecer siempre inactivos. En caso de llegar una conexión a uno de ellos puede
marcarlo en los logs del sistema, bloquear toda la comunicación con la dirección identificada como agre-
sora, o ejecutar un comando externo.
Modo clásico
Modo stealth
Modo avanzado
Modo clá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 ningún servicio.
Por ejemplo, puede que nuestro servidor no esté dando servicio de red SMB (Samba, red tipo Microsoft).
Sin embargo, es comú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 configuració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 conexión normal, SYN/half-open, FIN, NULL y XMAS. Este modo es un tanto
experimental, por lo cual no funcionará en todos los sistemas.
Modo avanzado
Este modo es también considerado hasta cierto punto perteneciente a la categorı́a stealth. En éste modo,
Portsentry no abre ningún puerto, sino que le pide al kernel que le notifique si llega alguna petición a algú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 sección anterior, SMB) y para ello tenemos las opciones ADVANCED EXCLUDE TCP y ADVAN-
CED EXCLUDE UDP.
El modo avanzado es mucho más sensible que el modo clásico, dado que escucha muchos más puertos,
por lo que puede efectivamente causar una negación de servicio si no es configurado con cuidado.
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 quisiéramos ejecutar Nmap contra uno de nuestros servidores para asegurarnos de que
no haya servicios abiertos que no requiramos y que nosotros mismos quedáramos bloqueá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 únicamente a la sesión actual
de Portsentry.
BLOCK TCP : Especifica qué hacer cuando un barrido de puertos TCP es detectado. Tiene tres po-
sibles valores: 0 (sólo registrar el intento), 1 (bloquear la dirección que intentó acceder a la máquina)
y 2 (ejecutar un comando externo especificado en KILL RUN CMD).
KILL ROUTE : Guarda el comando utilizado para descartar toda la comunicación con una direcció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 conexión.
KILL HOSTS DENY : Tiene la lı́nea que deberá ser agregada a /etc/hosts.deny para que la dirección
atacante sea bloqueada por TCPwrappers. Es conveniente activarlo, pues a diferencia de las reglas
manejadas por KILL ROUTE éste archivo sobrevivirá a la baja del sistema. Pero, no hay que
confiarse TCPwrappers sólo maneja determinados servicios, y si sólo nos protegemos con él, el sistema
podrá seguir proporcionando información importante a nuestro atacante.
KILL RUN CMD: Puede guardar un comando a ser ejecutado de ser detectada una intrusión. No
se recomienda utilizar esta opción, ya que puede fácilmente llevar a una negación de servicio. Hay
administradores que sugieren utilizar esta opción para lanzar un contraataque contra el atacante.
Nosotros categó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 más probable es que centre
más su atención en nosotros y, con el paso del tiempo, logre penetrar nuestra seguridad. Es mucho
mejor aparentar que nada ocurrió o simplemente tirar la conexión que atacarla.
SCAN TRIGGER: Indica con cuantos intentos de conexión se deben realizar, para marcarla como
un ataque. Probablemente, si a la primera bloqueamos toda comunicación con el presunto atacante,
dejaremos fuera a muchos usuarios legı́timos que por casualidad hicieron la conexión equivocada. Sin
embargo, si ponemos un número muy alto nos exponemos a dar más información de la que hubiéramos
querido. Un valor de 1 o 2 es recomendado, aunque los muy paranóicos querrán mantenerlo en 0.
Inicialización automática
Hay que incluir la ejecución en uno de los archivos que se ejecutan al iniciar la máquina. Las opciones
que podemos establecer son las siguientes:
Opción Descripción
-tcp Iniciar en modo clásico, escuchar TCP
-udp Iniciar en modo clá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.
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: SYN/Normal scan from host: ejemplo.dominio.com/192.168.1.3 to TCP port: 1019
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: SYN/Normal scan from host: ejemplo.dominio.com/192.168.1.3 to TCP port: 70
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: Host: ejemplo.dominio.com/192.168.1.3 is already blocked Ignoring
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: SYN/Normal scan from host: ejemplo.dominio.com/192.168.1.3 to TCP port: 934
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: Host: ejemplo.dominio.com/192.168.1.3 is already blocked Ignoring
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: SYN/Normal scan from host: ejemplo.dominio.com/192.168.1.3 to TCP port: 267
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: Host: ejemplo.dominio.com/192.168.1.3 is already blocked Ignoring
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: SYN/Normal scan from host: ejemplo.dominio.com/192.168.1.3 to TCP port: 202
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: Host: ejemplo.dominio.com/192.168.1.3 is already blocked Ignoring
Sep 27 20:10:48 hostname portsentry[14722]: attackalert: SYN/Normal scan from host: ejemplo.dominio.com/192.168.1.3 to TCP port: 613
(...)
Nuestro primer paso será editar el archivo /etc/hosts.deny y buscar la direcció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 dirección 192.168.1.3 ya tendrá de nuevo acceso a nuestro sistema.
Neped
Sentinel
El test DNS
En este método, la herramienta de detección en sı́ misma está 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 dirección IP de los inexistentes hosts. Algunos sniffers realizan búsquedas
inversas DNS en los paquetes que capturan. Cuando se realiza una búsqueda inversa DNS, una utilidad
de detección de sniffers “huele” la petición de las operaciones de búsqueda para ver si el objetivo es aquel
que realiza la petición del host inexistente.
Este método confı́a en un problema en el núcleo de la máquina receptora. Podemos construir una peti-
ción tipo “ICMP ECHO” con la dirección IP de la máquina sospechosa de hospedar un sniffer. Enviamos
un un paquete “ICMP ECHO” al objetivo con la dirección IP correcta, pero con una dirección de MAC
deliberadamente errónea. La mayorı́a de los sistemas desatenderán este paquete ya que su dirección MAC
es incorrecta. Pero en algunos sistemas Linux, NetBSD y NT, puesto que el NIC está en modo promis-
cuo, el sniffer identificara este paquete de la red como paquete legı́timo y responderá por consiguiente.
Si el blanco en cuestión responde a nuestra petición, sabremos que está en modo promiscuo. Los sniffers
avanzados filtran tales paquetes para que parezca que el NIC no hubiera estado en modo promiscuo.
Ping de Latencia. En éste mé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 esté procesando estos
paquetes a razó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. Después de una serie de tests y medias, podemos concluir o no
si un sniffer está realmente funcionando en el objetivo.
El test ARP
Podemos enviar una petición ARP a nuestro objetivo con toda la información rápida excepto con una
dirección hardware de destino errónea. Una máquina que no esté en modo promiscuo nunca verá este
paquete, puesto que no era destinado a ellos, por lo tanto no contestará. Si una máquina está en modo
promiscuo, la petición ARP serı́a considerada y el núcleo la procesarı́a y contestarı́a. La máquina que
contesta está en modo promiscuo.
13.11.1. Neped
NePED es una herramienta imprescindible para cualquier administrador de redes. Al ejecutarlo, el
programa nos informará de todos los equipos conectados a nuestra red local con la tarjeta ethernet en
modo promiscuo.
----------------------------------------------------------
> 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 técnica empleada para la detección es sumamente sencilla. Se trata de realizar una simple petició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 direcció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 contestarán a nuestras peticiones.
13.11.2. Sentinel
Lo podemos descargar desde su página web:
http://www.packetfactory.net/Projects/sentinel/
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 versión original de estos ficheros, en la última
versió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.
Al ser un shell scrip una vez compilados los programas (chkwtmp, chklastlog, chkproc, chkwtmp, ifpro-
misc) utilizarán el chkrootkit para realizar parte de su trabajo.
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
Vaya!, parece que ha detectado un archivo sospechoso, un posible troyano y que Snort está instalado.
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 obstá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 combinació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 más informa-
ción para el estudio. Hacen más fascinante el ataque al intruso, lo cual incrementa el número de ataques.
La función principal a parte de la de estudiar las herramientas de ataque, es la de desviar la atención del
atacante de la red real del sistema y la de capturar nuevos virus o gusanos para su posterior analisis. Una
de las mú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 ningú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 ú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 información sensible.
Ası́ mismo nos permiten conocer nuevas vulnerabilidades y riesgos de los distintos sistemas operativos,
entornos y programas, los cuales aún no se encuentren debidamente documentados.
Honeypots para la investigación: Gran parte de la atención actual se centra en este tipo. Los ho-
neypots para la investigación, que se utilizan para recolectar información sobre las acciones de los
intrusos. El proyecto Honeynet 1 , por ejemplo, es una organización para la investigación sobre segu-
ridad voluntaria, sin ánimo de lucro que utiliza los honeypots para recolectar información sobre las
amenazas del ciberespacio.
Honeypots para la producción: Son los que se utilizan para proteger a las organizaciones. Sin embargo,
se les concede cada vez más importancia debido a las herramientas de detección que pueden brindar
y por la forma cómo pueden complementar la protección en la red y en los hosts.
Obtienen un conjunto de datos pequeños, pero de gran importancia: Los Honeypots recolectan
pequeñas cantidades de información. En lugar de logear 1 Gb por dı́a, logean sólo 1 Mb de datos por
dı́a. En vez de generar 10.000 alertas por dı́a, pueden generar sólo 10 alertas por dı́a. Recordemos
que los honeypots sólo capturan actividad sospechosa ya que cualquier interacción con un honeypot
es muy probablemente actividad no autorizada o una actividad maliciosa. Propiamente dicho, los
honeypots reducen el “ruido” recogiendo sólo los datos indispensables y de gran valor, los producidos
únicamente por “chicos malos”. Esto significa que es mucho más fácil (y barato) de analizar los datos
que un honeypot recoge.
Nuevas herramientas y tácticas: Los honeypots son diseñados para capturar cualquier cosa que
interactúa con ellos, incluyendo herramientas o tácticas nunca vistas.
Mı́nimos recursos: Los honeypots requieren mı́nimos recursos, sólo capturan actividad irregular. Esto
significa que un viejo Pentium con 128 mb de RAM puede manejar fácilmente una entera red de
clase B entera.
Encriptació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 detectará y lo capturará.
Información: Los honeypots pueden recoger informació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 qué desarrollar
algoritmos raros, ni complejas tablas que mantener, o firmas que actualizar. Mientras más simple
sea la tecnologı́a, menos posibilidades de errores o desconfiguraciones habrá.
Como en cualquier otra tecnologı́a, los honeypots también tienen su debilidad. Esto es debido a que
no reemplaza a la actual tecnologı́a, sino que trabaja con las existentes.
Visión Limitada: Los honeypots pueden sólo rastrear y capturar actividad que interactúen directa-
mente con ellos. Los Honeypots no podrán capturar ataques a otros sistemas vecinos, al menos que
el atacante o la amenaza interactú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 encriptació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 también.
Especı́ficamente, los honeypots tienen el riesgo de que sean apoderados y controlados por los “chicos
malos” y que lo utilicen para dañ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 situación crı́tica.
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 atacarán y tomarán el sistema (con gusanos que se replican en la vı́ctima). Uno de las
mé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 interactúan con é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. Ésto es excelente para bajar la velocidad o
para prevenir la diseminación de gusanos que han penetrado en la red interna. Un ejemplo de un sticky
honeypot es: LaBrea Tarpit. Los “honeypots pegajosos” son más comunes encontrarlos entre soluciones de
baja interacción (hasta podrı́a llamársele soluciones “no interactivas”, ya que reducen tanto la velocidad
que hacen “gatear” al atacante. Los Honeypots pueden también protejer nuestra organización de intrusos
humanos. Este concepto se conoce como engaño o disuación. La idea es confundir al atacante, hacerle
perder el tiempo y recursos interactuando con honeypots. Mientras tanto, detectaremos la actividad del
atacante y tendrémos tiempo para reaccionar y detener el ataque. Hasta se puede dar un paso más allá: si
un atacante sabe que nuestra organización está utilizando honeypots pero no sabe cuales son los sistemas
honeypots y cuales son sistemas legı́timos, quizás tenga miedo de ser capturado por honeypots y decida
no atacarlo. Por lo tanto, honeypots disuaden al atacante. Un ejemplo de honeypot diseñado para hacer
esto, es el Deception Toolkit, un honeypot de baja interacción.
La segunda forma por la cual honeypots pueden ayudar a protejer una organización es por medio de
la detección. La detección es crı́tica, su propósito es la identificación de fallos para para la prevención. No
importa cuán segura sea nuestra organización, siempre habrán fallos si los hombres están involucrados en
el proceso... Detectando al atacante, podrán rápidamente reaccionar ante ellos, deteniéndolos, o mitigando
el daño que hicieron. Tradicionalmente, la detecció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 detección, solventando
muchos de los problemas de la detección clásica. Los honeypots reducen los falsos positivos, capturando
pequeñas cantidades de datos de gran importancia, capturan ataques desconocidos como nuevos exploits
o shellcodes polimórficos, y trabajan en forma encriptada o en entornos IPv6. En general, honeypots de
baja interacción son la mejor solución para la detección y tienen un riesgo limitado.
La forma tercera y final por la cual honeypots nos pueden ayudar a protejer una organización es en la
respuesta. Una vez que una organización detecta un fallo, ¿cómo debe responder? Esto es a menudo uno
de los grandes retos a los que nos debemos enfrentar. Hay por lo general poca información acerca de quién
es el atacante, cómo ingresó al sistema o cuánto daño hizo. En estas situaciones, la informació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 producción, como el
servidor de correo de una organización, son tan crı́ticos que aunque estén compremetidos los administra-
dores no pueden desconectarlos y hacer un análisis forense como corresponde. Están limitados a analizar
el sistema encendido mientras sigue proveyendo sus servicios productivos. Esto merma la habilidad para
analizar qué sucedió, cuánto daño hizo el atacante, e incluso si el atacante accedió a otros sistemas de la
red. El otro problema es que incluso en el caso de que este desconectado, hay tanta polución de datos que
es muy difı́cil determinar qué es lo que hizo el “chico malo”. Con polució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 cuál es la actividad normal del dı́a a dı́a y qué es lo que hizo el atacante.
Los Honeypots pueden ayudar a solventar ambos problemas. Honeypots son un excelente herramienta de
incidencias ya que pueden rápidamente y fácilmente ser sacados de la red para un análisis forense comple-
to, sin el impacto en las operaciones empresariales de todos los dı́as. Recuerden que la única actividad que
guardan los honeypots son las relacionadas con el atacante, ya que no las utilizan nadie (son señuelos),
excepto los atacantes. La importancia de los honeypots aquı́ es la rápida entrega de la información, ana-
lizada en profundidad, para responder rápida y eficientemente a un incidente. En general, los honeypots
de alta interacción son la mejor solución para la respuesta. Para reaccionar ante un intruso, se necesita
conocimientos en profundidad sobre qué hicieron, cómo ingresaron, y qué herramientas utilizaron.
trusos algo real. Si queremos un honeypot Linux corriendo un servidor FTP, tendrémos que construir un
verdadero sistema Linux y montar un verdadero servidor FTP. Las ventajas de dicha solución son dos:
Primero, usted capturarámos grandes cantidades de información dándoles a los intrusos algo sistemas
reales con la cual interactuar, podremos aprender la completa extensión de sus actividades, cualquier cosa
desde rootkits nuevos hasta sesiones internacionales de IRC. La segunda ventaja es que los honeypots de
alta interacción no asumen nada, acerca del posible comportamiento que tendrá el atacante, en lugar de
eso proveen un entorno abierto que captura todas las actividades realizadas. Esto permite a las solucio-
nes de alta interacción conocer comportamientos no esperados. Un excelente ejemplo de esto es cómo un
honeypot capturó comandos “back door” codificados en un protocolo IP no estandard (especı́ficamente
protocolo IP 11, Network Voice Protocol). No obstante, esto tambié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 implementación de una
tecnologı́a adicional que prevenga al atacante de dañar otros sistemas que no son honeypots. En general,
honeypots de alta interacción pueden hacer todo lo que uno de baja interacción puede hacer y mucho
más, pero pueden ser más complejos de utilizar y mantener. Ejemplos de honeypots de alta interacción
son Symantec Decoy Server y los Honeynets.
Honeynets
Symantec Decoy Server
2. De baja interacción: Emula sistema operativos y servicios.
Honeyd
Specter
KFSensor
Deception Toolkit
En nuestra instalació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
Tambié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 detectará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 también se especifica con un fichero normal de firmas de SO de
Nmap, permitiéndonos convertirnos en el SO que queramos. Si ejecutamos la configuración que viene como
ejemplo, veremos de lo que es capaz.
Después de instalarlo, hay un fichero que se llama config.localhost con un montón de dispositivos con-
figurados. Lo podemos encontrar en: /usr/share/doc/honeyd/examples/config.localhost
#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 explicación a grandes rasgos es que tenemos un dispositivo cuya dirección IP es 10.0.0.1, que se
comportará como un Cisco 7206 ejecutando una IOS 11.1(24), reseteará todas las conexiones TCP menos
las que vayan al puerto 23, ya que entonces el script router-telnet.pl (una emulación del demonio telnet)
será ejecutado.
Ahora ejecutemos Nmap para comprobar el SO que se ejecuta en el dispositivo virtual que acabamos
de crear:
Cuando recibimos los paquetes de Nmap, honeyd responde con la personalidad que hemos escogido.
Redes inalámbricas
En el proyecto he habilitado una red wifi, pero hoy los administradores de sistemas y conocen los
peligros que esto entrañ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 inalámbrica, debemos auditar la red frecuentemente y asegurarnos que nadie
está ejecutando un punto de acceso ilegal.
Hasta hace muy poco los administradores de red sólo tenı́an que preocuparse de asegurar los bienes
de la tecnologı́a de informació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 inalá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 término “informática móvil” en una realidad.
Ha cambiado drásticamente el perı́metro de seguridad de redes de las empresas de todos los tamaños.
Tradicionalmente, las redes corporativas se conectaban al mundo exterior en só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 contención cruciales. El interior de la red se trataba
como de confianza porque no habı́a forma de introducirse que no fuese a través de los puntos protegidos.
Ahora con una LAN inalámbrica desplegada, nuestro perı́metro de seguridad se convierte literalmente
en el aire que nos rodea. Los atacantes sin cables pueden provenir de cualquier direcció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 inalámbrica, tenemos que saber cómo funcionan las redes
del área local inalámbrica y cuáles son sus puntos débiles.
Los fabricantes del equipamiento LAN inalámbrico han reducido tanto los precios que ahora es una
alternativa muy viable para las redes domé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 inalámbricas
y utilizar Internet desde cualquier habitación de nuestra casa (o fuera de ella). El amplio despliegue de la
tecnologı́a LAN inalámbrica ha llegado definitivamente para quedarse y tarde o temprano tendremos que
tratar con ella.
tenemos este tipo de dispositivos u otras redes wifi en nuestro área podemos encontrarnos con algunas
interferencias.
Esta longitud de onda es perfecta para el corto rango deseado para wifi. Sus parámetros de diseñ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 descripción de los cuatro tipos de estándares inalámbricos 802.11 que han aparecido.
Una red wifi inalámbrica puede operar en uno de estos dos modos:
Modo adhoc: Nos permite conectar directamente dos nodos juntos. Este modo es útil para conectar
algunos PCs juntos que necesiten acceso a una LAN o a Internet.
Modo de infraestructura: Nos permite establecer una estació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
través de este punto. Ésta es la configuración más común en redes corporativas ya que permite al
administrador controlar el acceso sin cables a un punto. Cada punto de acceso y tarjeta inalámbricos
tiene un número asignado, es el ID del nodo cliente (BSSID, Basic Station System ID). Ésta es
la dirección MAC para los clientes inalámbricos que se asocian al nodo servidor. Este nombre no
es necesariamente ú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 actúan como puntos de acceso sin cables, cortafuegos y enrutador para usuarios
domésticos y de pequeños negocios. Yo dispongo de un router 3Com ADSL 11g de este tipo.
Podemos configurar un nodo de red inalámbrica instalando una tarjeta de interfaz de red (NIC, Net-
work Interface Card) en un ordenador. Una NIC inalá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
inalámbrica 802.11 en un modo de infraestructura tiene un punto de acceso que actúa como puente entre
la LAN de Ethernet con cables y uno o más puntos extremo sin cables. El punto de acceso envı́a frecuen-
temente transmisiones de “señales luminosas” para que cualquier nodo sin cables sepa que está ahı́. Las
transmisiones de señales luminosas actúan como un faro invitando a cualquier nodo sin cables del área a
iniciar la sesión. Estas señales forman parte del problema con wifi. es imposible desactivar completamente
dichas señales, lo que dificulta ocultar el hecho de que hay una red inalámbrica. Cualquiera que tenga
una tarjeta inalámbrica puede, al menos, ver las señales luminosas si se encuentran dentro de un rango,
aunque algunos receptores permiten limitar la cantidad de información que sale de dichas transmisiones.
Estas señales contienen información básica sobre el punto de acceso inalámbrico, normalmente inclu-
yendo su SSID. Si la red no está utilizando ningún cifrado ni ninguna otra protección, esto es todo lo que se
requiere para que un intruso acceda a la red. Sin embargo, incluso en una red inalámbrica cifrada, el SSID
normalmente se transmite al descubierto y los paquetes cifrados pueden ser escuchados clandestinamente
en el aire y están sujetos a intentos de decodificación.
Escuchas clandestinas: Lo más ácil para un intruso en una red inalámbrica es recopilar paquetes
utilizando un sniffer. Poco podemos hacer frente a ello, Los diseñadores de las redes inalámbricas
pensaron sobre ello e introdujeron en el diseño un cifrado estándar denominado Privacidad equivalen
al cable (WEP, Wired Equivalente Privacy) para que los datos se pudieran cifrar. Lamentablemente,
un fallo fundamental en có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 inalámbrica está potencialmente sujeto a su inspección por personas ajenas a la red.
Alguien podrı́a escuchar sobre nuestro enlace sin cables para buscar los registros de inicio de sesión,
las contraseñas o cualquier otro dato.
Acceder a los PC sin cables: Un enlace inalámbrico proporciona a un atacante potencial un vector en
una máquina de nuestra red. Aparte de los puntos de acceso, las máquinas con tarjetas inalámbricas,
a veces, se pueden ver desde el exterior. Si utilizan este modo de acceso pueden lanzar ataques contra
una máquina que probablemente no está protegida por el cortafuegos y puede que no se bloqueen
como las defensas del perı́metro o los servidores públicos.
Acceder a la LAN : Probablemente éste sea el mayor peligro que presentan las redes inalámbricas.
Si los intrusos pueden obtener el acceso a nuestra LAN a través de un punto de acceso inalá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 dirección IP válida y empezar a explorar
nuestra red. A continuación pueden ejecutar un escáner de vulnerabilidades (como Nesus) o un
escáner de puertos como Nmap (Vease sección 17) para encontrar máquinas de su interés y buscar
brechas que puedan aprovechar.
Acceso anónimo a Internet: Aunque los intrusos no estén interesados en lo que contienen nuestra
LAN, pueden utilizar nuestro ancho de banda para otros usos. Al iniciar la sesión en nuestra red y
acceder después a Internet, pueden piratear nuestra red y hacer el daño que quieran sin que podamos
seguirles la pista. Cualquier ataque o daño perpetrado desde esta conexión se rastreará hacia nuestra
red. Las autoridades pueden llamar a nuestra puerta, no a la suya. Este método de piraterı́a se
hará cada vez má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 inalámbrica a no ser que tenga un equipo de triangulación situado de antemano,
algo bastante caro y poco habitual. Las LAN inalámbricas no aseguradas ofrecen a los intrusos el
mejor acceso anónimo que existe.
Vulnerabilidades especı́ficas de 802.11 : Además de las inseguridades de las LAN inalámbricas, existen
algunos problemas especı́ficos del estándar 802.11. Algunos de ellos se deben a un mal diseño del
fabricante o a las configuraciones predeterminadas, otros problemas se deben al diseño general de
estándar.
SSID predeterminados: Cada estación base wifi tiene un identificador especı́fico que debemos conocer
para entrar en la red. Este identificador proporciona algú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 inalámbrica.
online con mapas para que cualquiera pueda encontrar una LAN Inalámbrica bierta en cualquier parte.
Las catalogan por tipo de equipamiento, cifradas o no cifradas, etc. Si tenemos una LAN inalámbrica en
un área metropolitana importante, es probable que esté catalogada en uno de estos sistemas, esperando
só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:
Es tan grande este fenómeno que hace unos meses en las islas canarias, se organizo el primer campeona-
to de Wardriving de España (Canarias Wardrive’05), podemos encontrar mas información en esta dirección:
http://www.canariaswardrive.org/
“Solo necesitamos explorar nuestra propia ciudad empleando un simple portátil, pda o similar,
dotado de una tarjeta wifi. La competición se divide en tres categorı́as territoriales:
Competición de Wardrive en Tenerife
Competición de Wardrive en Gran Canaria
Competición de Wardrive en toda Canarias
En estas competiciones se permite la participación individual o por equipos. Trabajando en
equipo se cubre más territorio y se encuentran los focos emisores más rapidamente. Una com-
petición sin carácter regional es la de los MiniGames, se celebrarán en Tenerife. En ellos se
plantearan a los competidores retos tales como intentar romper la seguridad de redes. Un sis-
tema homologado de puntuación asignará una cantidad de puntos dependiendo del tipo de red
local. La participación en este tipo de competición exige inexorablemente un comportamiento
deportivo intachable.”
Ha más de un administrador de sistemas se le pondrán los pelos de punta al leer esto.
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 única y estática, a ser generada de forma
dinámica, para cada usuario, para cada sesión (teniendo una duración limitada) y para cada paquete
enviado. Conceptualmente el vector de inicialización pasa de 24 a 48 bits, minimizando la reutilización de
claves. También utiliza claves para tráfico de difusión y multidifusión.
Utiliza el algoritmo “Michael” para garantizar la integridad, generando un bloque de 4 bytes (denomi-
nado MIC) a partir de la dirección MAC de origen, de destino y de los datos, añ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 número de secuencia. La mezcla del número de secuencia con la clave temporal genera la clave que se
utilizará para el cifrado de cada fragmento.
El estándar IEEE 802.11x define un protocolo para encapsular, protocolos de autenticación sobre
protocolos de enlace de datos. IEEE 802.11x permite utilizar diversos métodos para autentificar al usuario
a través del protocolo de autenticación extensible (EAP). Se concibe como una ampliación de la capa de
enlace de datos:
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 asociación del cliente y habilita un puerto para ese solicitante, permitiendo
únicamente el tráfico 802.11x, el resto de trá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 autenticación. A partir de ese momento el solicitante y el servidor de autenticación
se comunicarán directamente, utilizando un cierto algoritmo de autenticación que pueden negociar. Si el
servidor de autenticación acepta la autenticación, el autenticador pasa el puerto del cliente a un estado
autorizado y el tráfico será permitido.
Los métodos de autenticación definidos en WPA son: EAP-TLS, EAP-TTLS y PEAP. Estos métodos se
basan en la infraestructura de clave pública (PKI) para autenticar al usuario y al servidor de autenticación,
utilizando certificados digitales. La premisa es la existencia de una Autoridad de Certificación (CA) de
confianza para la corporación, que emita certificados para los usuarios y el servidor de autenticación. La
CA puede ser privada (empresarial) o pública (basada en CAs de Internet como Verisign).
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 técnico y económico. Para evitar esta necesidad aparecen 2 métodos: Protected
EAP (PEAP) y EAP-Tunneled TLS (EAP-TTLS), que requieren únicamente del certificado en el servidor
de autenticación.
La idea subyacente es que si el servidor de autenticación dispone de un certificado digital, el cliente
podrá enviarle datos cifrados, creándose un “túnel de seguridad” por donde el cliente podrá enviar sus
datos de autenticación.
PEAP fue diseñado por Microsoft, Cisco y RSA. Cuando el cliente ha validado el certificado del
servidor de autenticación y creado el túnel, usando TLS se inicia una nueva autenticación donde negocian
un método, por ejemplo MS-CHAP v2, tras autentificar el servidor al cliente, ambos generan la clave de
sesión. EAP-TTLS fue diseñado por Funk Software. También se basa en crear en primer lugar un tú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 métodos EAP y se abre a nuevos métodos.
Implementación de WPA
Para soportar WPA, en caso de que los productos no estén certificados por su uso, debemos actualizar
el firmware de los puntos de acceso y de los adaptadores de red inalámbricos de las estaciones. En las
estaciones se deberá actualizar el sistema operativo para soportar 802.11x y el método EAP elegido. Por
ejemplo, Windows XP soporta WPA mediante una actualización.
Según el método EAP elegido habrá que definir la configuración del servidor Radius. También es posible
que tengamos que utilizar o implementar los servicios de una Autoridad de certificación.
Formar al personal
Igual que sucede con todo lo referente a la seguridad informática, el elemento humano puede ser el
punto más débil o el más fuerte. Hay que asegú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 extraña en el
techo del mismo, es muy probable que se trate de alguien que busca entrar en nuestra red inalámbrica.
Asimismo, hay que desarrollar una polı́tica a nivel de toda la empresa. Algunas veces una demostración
es la mejor forma de mostrar este tipo de peligro. Un personal informado puede ser nuestra mejor defensa.
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)
client 172.16.1.253/32 {
secret = clave_secreta
shortname = localhost
}
/etc/freeradius/users.conf : Añadimos los usuarios a los que les vamos a permitir el acceso a la red
Si no nos queremos complicar en exceso, para agregar más usuarios, solo hay que cambiar User-Password
y la IP.
Utilizamos los scripts de generación de certificados que vienen con FreeRadius y OpenSSL
Escogeremos la segunda opció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 código fuente de freeradius, para obtenerlo:
#apt-get source freeradius, nos descargará 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 añadir otro archivo de OpenSSL: CA.pl, un script
Perl para crear Autoridades de Certificació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.
# ./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 harán falta para el cliente y el servidor.
Es recomendable colocar estos certificados en /etc/freeradius/certs, ya que los archivos de configuración
de freeradius apuntan a ese directorio y tendremos menos cosas que modificar.
Antes de pasar a configurar los usuarios es necesario configurar el AP, que será el cliente de nuestro
servicio de Radius. La configuració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 grá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 contraseñ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).
Si lo soporta, necesitamos saber es como se llama la tarjeta en el sistema (en mi caso eth1):
#iwconfig
lo no wireless extensions.
Para tener acceso mediante los clientes Linux hay que instalar el siguiente programa:
#apt-get install wpasupplicant
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>
En mi caso, ifname es eth1, el config file lo creé en /etc/wpa supplicant.conf y el driver ipw, esto
variará dependiendo de nuestra configuración de hardware.
Si ejecutamos: #wpa_supplicant -h, veremos que soporte y para que driver ha sido compilado.
Para instalar los certificados generados por OpenSSL (root.der y root.p12) es suficiente con hacer doble
click sobre ellos.
Para comprobar que realmente ha sido instalado, ejecutamos el siguiente comando en la consola: mmc
A través del Microsoft Manegement Console (mmc) podemos comprobar el certificado, :
Elegimos la opción “agregar”, “certificados”. Pulsando sobre él deberı́a de aparecer:
En certificados personales, el certificado de cliente
En entidades emisoras, el certificado del servidor
Ahora falta asociarlos a una conexión, vamos a ver las “conexiones de red inalá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 autenticación de red “WPA” y como cifrado de datos “TKIP”
Solo queda seleccionar las siguientes opciones y aceptar: “usar un certificado en este equipo”, “utilizar
selecció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 selecció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 aparecerá una ventana emergente que nos avisa de que se
está validando el servidor y que presionemos “aceptar” si el certificado es correcto, una vez presionemos
ya no será necesario volver a repetir el proceso y si todo va bien podremos conectarnos de forma segura a
nuestra red.
Instalar Kismet
Se puede obtener la versión más actualizada del programa en la dirección:
http://www.kismetwireless.net
Editar y configurar el archivo: /etc/kismet/kismet ui.conf, aquı́ se han de establecer las preferencias
de la interfaz gráfica de kismet (el cuadro 14.3 recoge los parámetros que se pueden configurar)
La sección Network List (lista de redes) que se encuentra a la izquierda muestra todas las redes
inalámbricas activas que puede ver Kismet y alguna información básica sobre ellas: el SSID de la red
(si está disponible), el tipo (punto de acceso frente a nodo), si está cifrada o no utilizando WEP, el
canal en el que se está transmitiendo, el número de paquetes interceptados hasta el momento, cual-
quier indicador sobre los datos y la cantidad de datos que están por la red. La pantalla está codificada
con colores, apareciendo en color rojo las redes activas y en negro las que no están activas.
El cuadro Info (información) que se encuentra a la derecha de la pantalla muestra las estadı́sticas
globales para esta sesión de captura (incluyendo el número total de redes detectadas, el número total
de paquetes, el número de paquetes cifrados, las redes débiles percibidas, los paquetes con un alto
nivel de ruido, los paquetes descartados y la media de paquetes por segundo.
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.
denominado GPSMPA que traza automá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 distribución para Linux denominado GPSDrive, lo
podemos instalar con: #apt-get install gpsdrive.
IDS de Kismet
También podemos configurar Kismet como un IDS inalámbrico. Kismet interceptará todas las señales
entrates y detectará el tráfico inalámbrico que se sabe está asociado con los ataques a redes wifi o activi-
dades inalámbricas sospechosas.
Detecta unos 10 tipos diferentes de tráfico, incluyendo sondeos del programa NetStumbler (herramienta
para Windows), la actividad de Airjack y otras herramientas de piraterı́a inalámbrica. Y, como es de
libre distribución, siempre podemos ampliarlo mediante la escritura de nuestras propias alertas. También
podemos canalizar los datos de Kismet a través de un IDS tradicional como Snort (Véase sección 13.5)
para obtener un análisis más detallado.
La opción IDS se configura en /etc/kismet/kismet.conf y de forma predeterminada está deshabilitada.
También puede configurar Kismet para recopilar claves débiles conocidas criptográficamente para un
programa como AirSnort, que analiza paquetes inalámbricos e intenta descifrar el cifrado WEP. Pasemos
a describir el funcionamiento de este programa.
RC4, escrita por los expertos criptográficos Fluhrer, Martin y Shamir, incluı́a detalles sobre una teórica
debilidad en el algoritmo WEP, describiendo la debilidad de algunos vectores de inicialización. Los paquetes
cifrados con estos vectores débiles se podı́an coleccionar y al final habrı́a suficientes datos para extrapolar la
clave secreta compartida, lo que permitirı́a descifrar fácilmente los paquetes. Poco después, se lanzaron dos
herramientas, AirSnort y WEPCrack, que empleaban las debilidades descritas para recuperar claves WEP,
descifrándolas con efectividad. Ambas son buenas herramientas, pero AirSnort tiene una funcionalidad
adicional como sniffer inalámbrico.
AirSnort es ahora un proyecto de libre distribución que se encuentra en SourceForge.net y que se ha
extendido y mejorado considerablemente desde su lanzamiento.
Usos de AirSnort
¿Por qué utilizar AirSnort en una red inalámbrica? Alguien podrı́a decir que no existe un uso legı́timo
para el programa y su único propósito es el de ser una herramienta para el asalto de redes. Creo que la
única forma de saber lo expuesta que está nuestra red inalá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 inalámbrico, podemos ver si se puede hacer. Si se está utilizando un
WEP estándar, entonces es simplemente cuestión de tiempo. Es una realidad matemática que se puede
descifrar en algún punto utilizando esta herramienta. La cuestión es cuanto tardaremos en hacerlo. Si
tardamos mucho tiempo, podemos suponer razonablemente que estamos bastante seguros. Si el nivel de
tráfico de nuestra LAN es pequeño, puede ser cuestión de dı́as o incluso de semanas, lo que sitúa a nuestra
red fuera del reino de lo práctico para la mayorı́a de los piratas informáticos casuales. Sin embargo, si es
una red ocupada, alguien podrı́a recoger los paquetes suficientes para descifra nuestro cifrado en cuestión
de horas o en un dı́a. Saber todo esto nos ayuda a proteger mejor nuestra red. Puede justificar incluir
más protecciones, como mejores controles fı́sicos o limitar el tráfico en la red. También puede justificar la
actualización de nuestro equipamiento inalámbrico, como por ejemplo a un sistema WPA con un servidor
Radius, como el que se propone en este proyecto. Una red inalámbrica que utiliza este protocolo puede
ser, actualmente (solo actualmente) indescifrable. Podemos descubrir que el nivel de tráfico no hace que
sea prá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 instrucción:
#apt-get install airsnort
airsnort: Recopila los paquetes desde algún origen, normalmente la tarjeta de red inalámbrica
decrypt: Realiza los intentos en desconexión de descifrado para los archivos cargados desde otro
origen
AirSnort acepta archivos de otros sniffers inalámbricos siempre que se guarden en formato PCAP. Con
el tiempo, Kismet separará especı́ficamente los paquetes interesantes para AirSnort, ahorrándonos este
paso.
No es necesario tener toda la colección de datos a la vez. AirSnort puede guardar una sesión y retomarla
posteriormente para realizar adiciones, lo que convierte a AirSnort en una herramienta particularmente
peligrosa para redes inalámbricas ya que nadie tiene que perder una sesión interrumpida cerca de nuestras
instalaciones para recopilar los paquetes suficientes como para entrar en nuestra red. Puede dividir sus
actividades de recopilación en incrementos de tiempo más pequeñ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 número total de paquetes cifrados y sin cifrar. La sección superior muestra nuestras
configuraciones, como el tipo de tarjeta NIC, etc. A la derecha podemos cambiar algunas configuraciones
como breadth (nú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 más de 4 ó 5.
A continuació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 débiles, es decir, aproximadamente entre 100MB y 500MB de datos. En una red
moderadamente ocupada, podemos tardar uno o más dı́as en recopilar esta cantidad de datos. En redes
más lentas, podemos tardar más y en redes ocupadas mucho menos. Hay que esperar, al menos, tardar un
par de horas, aunque seguramente sea má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 éxito, aparece tanto en texto normal como en hexa-
decimal en la parte izquierda de la pantalla y los extremos de la sesión de captura.
¿Qué pasarı́a si encontrásemos las claves WEP? Bueno, hay que tranquilizarse, que no nos entre el
pánico ya que la mayorı́a de los intrusos casuales no se molestarán lo más mı́nimo. Sin embargo deberı́amos
pensar en tomar medidas para aumentar la seguridad de nuestra red inalámbrica para que sea má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 basándonos en la
confidencialidad de los datos que tratamos en nuestra red.
Para acceder a la configuració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 está dividido en diversos módulos. Cada uno de estos se encarga de la administración de una
parte concreta del sistema operativo y de los diferentes servicios que tengamos instalados.
Crea una configuración para cada uno de los módulos basándose en la estructura de ficheros y confi-
guración predeterminada para la versión y distribución de Linux seleccionadas.
Los mó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
instalación algunos de los mó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 estándar en Linux.
En el módulo usuarios de Webmin se encuentran las diferentes opciones disponibles para definir y
configurar los usuarios que tendrá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 sólo tenga acceso al módulo de administración de Exim, o si se emplea como
servidor de impresión crearı́amos un usuario que pudiera administrar las colas de impresión.
De esta forma es posible crear diferentes usuarios en función de los módulos a los que tendrán acceso,
delegando fácilmente la administración de determinados servicios del ordenador a diferentes usuarios y
siendo posible incluso determinar que aspectos de un determinado servicio podrá administrar.
Desde el módulo de configuración de Webmin podemos cambiar los aspectos más importantes del
propio Webmin como instalar nuevos módulos, actualizar Webmin, cambiar el idioma, añadir, eliminar o
modificar usuarios de Webmin, cambiar el puerto utilizado, etc.
Control de acceso a IP
Ya que Webmin tienen su propio servidor web (miniserv.pl) desde esta opción podemos seleccionar
qué 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 opción estableceremos el puerto utilizado para acceder a Webmin, por defecto 10000. En el caso
de que nuestro ordenador tenga asignada más de una dirección IP también podremos establecer qué di-
rección IP deberá atender el servidor web de Webmin, ya que por defecto el servidor aceptará peticiones
realizadas a cualquiera de las direcciones IP asignadas al sistema.
Diario
Desde aquı́ configuraremos la forma en que Webmin guardará un registro de las acciones realizadas.
De esta forma podremos monitorizar fá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 función del módulo utilizado o
del usuario. Se permite programar cuando se limpiará el historial para evitar que el tamañ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 actualización de Webmin. Desde esta opció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.
Desde esta opción se modifican los colores y tipos de letras utilizados para visualizar las páginas de
Webmin.
Módulos de Webmin
Webmin está formado por diversos módulos. cada uno de estos módulos se encargan de realizar una
tarea determinada interrelacionada con el servidor web de Webmin (miniserv.pl).
Desde esta opción, añadiresmo, actualizaremos o eliminaremos los módulos utilizados por Webmin.
Está se encuentra dividida en tres secciones:
Instalar módulo
Clonar módulo
Borrar módulos
Instalar módulo La sección Instalar módulo permite instalar un nuevo mó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 módulos Webmin son archivos de extensión .wbm
Clonar un módulo Esta opción permite al administrador del sistema duplicar un módulo para permi-
tir a determinados usuarios administrar ciertos servicios. Ası́, por ejemplo, si tenemos dos configuraciones
diferentes de Apache ejecutándose en el ordenador, con esta opción duplicaremos el módulo de administra-
ción de Apache para permitir a diferentes usuarios acceder de forma independiente a la versión de Apache
que sea necesario.
Eliminar módulos Desde esta última sección, seleccionaremos y borraremos aquellos módulos que no
nos sean de interés o no se vayan a utilizar. Ası́, por ejemplo, si no tenemos instalado en nuestro ordenador
PostgreSQL podemos eliminar el módulo utilizando para su administración.
Sistema operativo
Desde esta opción podremos especificar cual es nuestro sistema operativo. Este proceso deberá realizarse
si, por ejemplo, hemos actualizado el sistema operativo instalando una versión nueva, la cual modifica la
estructura de directorios en los que se guardaba la configuración de los diferentes servicios del sistema.
Lenguaje
Se emplea para seleccionar el idioma utilizado para visualizar los textos en los módulos.
Mejorar Webmin
Desde esta página es posible actualizar Webmin a la última versión disponible de forma automática o
desde un archivo que hayamos descargado de Internet.
Utiliza un gestor de paquetes para realizar la tarea, en nuestro caso apt.
Autenticación
Webmin proporciona algunas caracterı́sticas orientadas a prevenir ataques como puede ser el intentar
averiguar la contraseña de administración a base de probar diferentes contraseñas de forma automá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 autenticación proporcionadas por Webmin para proteger nuestro sistema de posibles
ataques.
La primera opción que encontramos en la ficha es Tiempo máximo de clave de acceso. Si activamos
esta opción, se bloqueará el acceso al ordenador si se producen una serie de fallos en unos segundos
determinados, esto indicará que alguien está ejecutando una aplicación automática para descubrir
nuestra contraseña.
Tambié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 opción, cualquier usuario que tenga acceso al sistema, sea administrador o
no, podrá trabajar con Webmin.
Reasignando módulos
Como ya se ha comentado Webmin agrupa los módulos instalados en diferentes categorı́as. Estas
categorı́as están definidas en función de la tarea que realiza el módulo. Desde estas opción Webmin nos
permite asignar un módulo a una nueva categorı́a en el caso de que no estemos de acuerdo con la categorı́a
asignada por defecto.
Algunos mó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 opción para crear nuevas categorı́as o editar las existentes.
Temas de Webmin
En estas sección se puede modificar el aspecto y los colores de Webmin, utilizando temas.
Los temas de Webmin son muy flexibles, permitiendo al desarrollador modificar prácticamente cualquier
aspecto de la apariencia y distribución de los elementos de Webmin.
Referenciadores de confianza
Al estar basado en archivos web y accederse a él desde un navegador web, uno de los peligros con los
que podemos encontrarnos es el hecho de que la información de autenticación se guarda en el navegador
y puede ser reenviada de forma automática desde él. Esto puede causar que otro usuario que emplee el
mismo navegador tenga acceso a nuestro sistema sin conocer tan si quiera la contraseña o nombre de
usuario de Webmin.
En esta sección podremos indicar que hosts tienen acceso a Webmin, limitando de esta forma desde
qué ordenadores se podrá utilizar.
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.
Encriptación SSL
Si tenemos instaladas en nuestro ordenador las librerı́as OpenSSL y el módulo de Perl Net::SSLeay
podremos emplear conexiones encriptadas con SSL para acceder a Webmin. Para acceder a Webmin
utilizaremos una conexión segura, de la forma:
https://127.0.0.1:10000, ó https://localhost:10000
Ası́ incrementaremos la seguridad de Webmin, ya que la información, como por ejemplo el nombre de
usuario y contraseña, se enviará 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.
Autoridad de certificado
Esta opció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 contraseña para utilizarlo. Los
usuarios pueden solicitar un certificado personal en el módulo de usuarios de Webmin y agregarlo al
navegador, de esta forma el navegador podrá autenticarse de forma automática y segura.
El problema que puede surgir al utilizar este método de autenticación es que cualquier usuario con
acceso a un navegador que contenga un certificado válido para acceder a Webmin podrá utilizar las
herramientas de administración. Este método también inválida polı́ticas de seguridad como la desconexión
del usuario después de un determinado periodo de inactividad, ya que simplemente volviendo a abrir el
navegador podrı́amos acceder.
Podemos buscar más módulos Webmin dentro del sistema Debian con apt-cache:
#apt-cache search webmin
En la siguiente tabla se muestran la mayoria de los módulos disponibles en nuestro sistema Debian:
Una vez instalados todos los módulos necesarios para el proyecto pasemos a ver graficamente las sec-
ciones de nuestro servidor.
Para tener bajo control el sistema, es muy importante tener información esencial de su rendimiento:
procesos en ejecución, cantidad de memoria disponible, n.o de particiones, etc.
Estadı́sticas sobre los procesos del sistema (número de procesos, procesos durmiendo, procesos eje-
cutá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
caché, cantidad total de buffer o memoria caché de página, en kilobytes, que está en uso activo,
cantidad total de buffer páginas de la caché que podrı́an quedar libres, cantidad total de buffer o
páginas de la caché que están libres y disponibles.)
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 además se permite realizar una serie de tareas sobre los
procesos, como por ejemplo:
Ordenarlos según diferentes criterios (por PID con “N”, uso de CPU con “P”, tiempo con “A”, etc.).
Resulta muy recomendable siempre tener top funcionando en uno de los terminales, para poder ver de
forma rápida si hay cargas excesivas en el sistema.
4. Diseñar e implementar las modificaciones al sistema y/o programas de aplicación diseñ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, habrá un nuevo problema a resolver.
Presenta estadı́sticas sobre la CPU y los dispositivos y particiones de E/S. Para ejecutarlo:
$iostat
# iostat
Linux 2.6.11 (debian) 26/05/05
# free
total used free shared buffers cached
Mem: 511948 472644 39304 0 63548 230704
-/+ buffers/cache: 178392 333556
Swap: 979924 0 979924
# 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
Con el comando #du -sh, se muestra el espacio usado por los archivos y directorios del directorio
actual.
En la tabla 16.1 podemos observar una lista de las opciones del comando:
Opción Descripción
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
#kill pid, . . . se el dice al proceso que termine, de forma controlada, el estado en que termino puede
ser capturado. Esta instrucción le envı́a un SIGTERM (signal 15).
La señal SIGKILL (signal 9), no puede ser capturada y fuerza al proceso a finalizar.
#kill [-signal] orden, . . . envı́a la señal a todos los procesos “orden” (ejemplo: #killall -9 bash).
Procesos zombies
Al lanzar un proceso se le asigna un valor de prioridad (número nice), por defecto la hereda del
proceso padre.
La prioridad dinámica del proceso se calcula en función del número nice, junto con el consumo de
CPU realizado
Asignar un valor negativo o que disminuya (mejore) la prioridad del proceso sólo puede hacerlo el
root, aumentar (disminuir prioridad) también lo puede hacer el usuario que lo ejecuto
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 estándar una vez invocado
el comando, o de un fichero utilizando la opció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 estándar y de errores de estas tareas se envı́a a travé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.
#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
Tambié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 periódicamente conocidas como crons. Para definirlas
se emplea un fichero por usuario cuyo formato se explica a continuación.
Básicamente para cada tarea periódica se escribe una lı́nea donde se especifican los momentos en que
se ejecutará y el comando correspondiente. También se pueden realizar asignaciones a variables de entorno
que serán vlidas sólo para los procesos indicados en lo sucesivo mientras no aparezcan nuevas asignaciones.
Las fechas se especifican utilizando cinco indicadores separados por espacios:
Si no se coloca alguno de los cinco indicadores se pone el cará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 después del rango.
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 perió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.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Las tareas del sistema se organizan en cuatro grupos: tareas que se ejecutan cada una hora, tareas
diarias, tareas semanales y tareas mensuales.
Algunas de las tareas que se hacen de forma periódica por el sistema, son la actualización de las bases
de datos sobre las que trabajan los comandos locate y whatis, ası́ como la rotació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 estándar de todas
las tareas perió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 útil pero su ejecución depende de que la máquina se encuentre encendida
en el momento exacto para el que se programó. Es por ello que existe otro tipo de tareas periódicas:
las anacrons. Estas se ejecutan cada cierto tiempo especificado en dı́as. En caso de que la má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 ejecutará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. Ademá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 última vez
que ejecutó este trabajo (timestamp file). Este fichero se almacena en /var/spool/anacron/ y slo contiene
una fecha.
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 más) ya no tiene que ejecutar las tareas.
Valoración final
Capı́tulo 17
La distribución de Nessus consta de cuatro ficheros básicos: las librerı́as del programa, las librerı́as
NASL (Nessus Attack Scripting Language), el núcleo de la aplicación y sus plugins.
Y después descargamos de la página de Nessus (http://www.nessus.org/ ) los plugins que creamos ne-
cesarios, instalandolos en la carpeta /nessus/plugins.
Durante el proceso de instalación se nos realizan una serie de preguntas para generar un certificado
SSL para Nessus:
-------------------------------------------------------------------------------
Creation of the Nessus SSL Certificate
-------------------------------------------------------------------------------
/etc/nessus/nessusd.conf updated
. 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.
La configuración por defecto es completa y válida, entre otras cosas escanea desde el puerto 0 al
15000. Ahı́ podemos modificar todas las opciones que nos parezcan oportunas.
300 Servidor Linux para conexiones seguras de una LAN a Internet
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 más seguro el sistema de certificados. Tambié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 última configuració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
Registrar la versión de Nessus, para ello hay que entrar en: http://www.nessus.org/register/ poner
un correo electrónico donde se nos reportará 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
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
Tambié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.
Una vez realizada la comprobación del servidor podemos observar las siguientes vulnerabilidades en-
contradas:
Básicamente podemos decir que la seguridad del servidor esta controlada. A esto únicamente habrı́a
que añadir alguna actualización de versiones para parchear posibles exploits descubiertos recientemente.
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), . . .
Fá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 código fuente está disponible para su descarga.
Buena Documentación: Se ha realizado un gran esfuerzo en mantener actualizados y traducidos
tanto las páginas man, como los tutoriales y el resto de documentación relacionada con Nmap.
Soportado: Aunque Nmap viene sin garantı́a explicita de ningún tipo, se puede escribir al autor o
utilizar las diferentes listas de distribució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, además está 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 máquina, bastará con ejecutar: #nmap <host> -O
La salida que obtenermos del servidor que se ha configurado durante el proyecto se puede observar en
la siguiente página.
#nmap 192.168.0.10 -O
Depués de descubrir los servicios que ofrece la máquina, con un simple telnet hemos obtenido el sistema
operativo instalado en la máquina y la versión de ssh, si se conoce alguna vulnerabilidad de esa versió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 más opciones y alternativas, por lo que es más que recomendable acceder a la docu-
mentación incluida con Nmap, ası́ como a la página man del mismo.
#nmap --help
#man nmap
#lynx nmap\manpage-es.html
Estos escaneos de máquinas y redes, suelen dejar huellas de su ejecución en los registros logs de las
má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 negociació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 opción -oS, que muestra la salida del Nmap en un formato que les encantará a los
Script-kiddies, la podemos observar en el siguiente ejemplo:
#nmap -oS - 192.168.0.10+
Como podemos comprobar en el cuadro 17.5, la salida nos permite examinar un informe y determinar
rápidamente si hay más servicios o puertos con los que tenemos que tener cuidado, lo que no significa
que deberı́amos ignorar cualquier número inusual que no esté resaltado o en negrita. Los troyanos y el
software de conversación se muestran normalmente como servicios desconocidos, pero podemos buscar un
puerto misterioso en una lista de puertos malignos conocidos para determinar rápidamente si el puerto
abierto es algo de lo que tenemos que preocuparnos. Si no lo podemos encontrar en dicha lista, tendremos
que cuestionarnos cuál será ese servicio extraño que se está ejecutando en la máquina y que no utiliza un
número de puerto conocido.
Podemos guardar los registros Nmap como números de formato, incluyendo el texto simple o legible
por la má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
ejecución sobre redes muy grandes puede servirnos de salvavidas ya que el examen cuidadoso de cientos
de páginas de salidas Nmap nos puede volver locos rápidamente.
Nmap es una herramienta ideal para Verificar/auditar el Firewall, tal como dice uno de los banner de
su página oficial, “Audite la seguridad de sus Redes antes que los chicos malos lo hagan” (Audit your
network security before the bad guys do).
Durante la elaboración del proyecto, en todas y cada una de las secciones, en la información que he
consultado, se advertı́a de que el uso de servicios de gran consumo de recursos en la misma máquina
provocarı́an la ralentizació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 optimizació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 corporación en una única máquina.
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).
Estudio Económico
Mediante los siguientes esquemas se determinará 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 elaboración del proyecto
con una baremación aproximada de sus costes.
18.2. Costes
En la siguiente tabla, se puede encontrar una valoración aproximada de los costes totales del proyecto,
basada en los sueldos/hora asignados a cada cargo del personal.
Hasta las 350 horas en Administración de sistemas: Para la asimilación de los entornos, la configu-
ración de los servicios y las pruebas necesarias.
Hasta las 400 horas en Documentación: Debido al cambio de orientación del proyecto, hacia la
elaboración de un “Manual de instalació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 número de horas en ningú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 instalación para servidores Linux” se ha conseguido que el uso del proyecto
pueda llegar a más ámbitos y convertirlo en útil para muchas personas.
Conclusiones
El aumento de las horas dedicadas, que no los plazos de entrega, fue debida a que el proyecto evoluciono
hacia la elaboración de un: “Manual de instalación para servidores Linux”, que abarca desde la elección
de la distribución, pasando por la instalación del sistema y finalmente la configuración de la gran mayorı́a
de servicios disponibles para entornos corporativos.
Este cambio de orientación, fue decidio a la mitad del proyecto, de nada servı́a documentar la ins-
talación de un servidor Linux, si el proceso no podı́a ser reproduccido, a menos que se dispusiera de la
misma máquina y la misma infraestructura. El proyecto se ha adaptado a un entorno más general, basado
en la distribución Debian Sarge, para que los conociemientos adquiridos, puedan ser aprovechados por un
número mayor de usuarios de escritorio y administradores de sistemas.
A modo de resumen me quedaré con la siguiente frase que lei mientras me documentaba y que esta
en concordancia con el espı́ritu de este proyecto: “En Internet sólo el paranoico sobrevive. Puede ser un
lugar muy sucio, lleno de virus, gusanos, troyanos, spammers y abogados de litigios de patentes; lo último
que alguien querrı́a es ponerse en lı́nea sin protección alguna.”
312 Servidor Linux para conexiones seguras de una LAN a Internet
Los sistemas de este estilo, no son la panacea, exigen la dedicación de mucho tiempo y una adminis-
tración rigurosa. Es decir, exigen de mucho tiempo y mucho dinero para que resulten efectivos.
No todas las empresas se podrán permitir este tipo de gastos. Hay que analizar hasta donde conviene
proteger y aplicar una solución, que no será estandar, sino adaptada al perfil de nuestra organizació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 planificación fue bastante imprecisa: Debido a mi falta de experiencia y conocimientos, los plazos
se han aumentado muchisimo, llegando suplir esta falta de previsión con unas 300 horas extras
respecto a la planificación inicial.
A pocos dı́as de la entrega final, se lanzo la versión estable del proyecto Debian Sarge. Esto derivo
en dos consecuencias importantes:
1. La primera positiva: La elecció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
está totalmente actualizado y será válido por un largo periodo de tiempo.
2. En contra: La mayor parte del documento está escrito pensado que la versión estable se lanzarı́a
en un futuro inmediato. Este futuro se ha adelantado un mes, la solución a pasado por agregar
un anexo (véase anexo G) donde se explica que ha pasado y que implicaciones tiene esto en el
documento.
El proyecto lo podrı́a clasificar de interés personal, ya que mi pasión de siempre, han sido los
sistemas operativos. Por razones diversas no me habı́a adentrado en el mundo de Linux, más que a
un nivel muy superficial. Este proyecto me ha permitido profundizar e investigar sobre el mundo de
la seguridad informá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 técnica en Informá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 resultará mucho más facil de afrontar y probablemente
también este enfocado hacia alguna parte concreta de la seguridad informática, sector que actual-
metne está teniendo un gran auge.
El descubrimiento del mundo del software libre, me ha abierto el horizonte, las licencias GPL per-
miten observar que hay futuro má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.
Después de la elaboración de este proyecto, yo me he situado claramente en el sector GPL.
Por todo ello, lo considero una experiencia muy positiva y seguramente orientará mi futuro profesional
al sector de la seguridad informática.
Una objetivo que me gustarı́a conseguir, si es posible (es decir, si la universidad y mi director de
proyecto están de acuerdo), es poner a disposición de la comunidad de usuarios Linux este documento.
De está forma mi trabajo podrá ser aprovechado por un mayor número de personas, ya que este no es el
tı́pico proyecto con una utilidad muy limitada, sino que tiene un uso mucho más amplio y puede llegar a
ser útil a mucha gente.
Apéndices
Apéndice A
Comandos básicos
Para más información sobre los comandos podemos ejecutar: $man <comando>
Comandos de sistema
Comando Descripción
man Páginas del manual
ls Listar (mú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 páginas
vim y emacs Editores de texto, modo texto
nedit, kedit y kwrite Editores de texto, modo gráfico
split Partir ficheros
which Devuelve el Path de un ejecutable, que se encuentre en la
variable $PATH
Comprimir y descomprimir
Comando Descripción
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 (múltiples opciones)
gzip Comprimir ficheros (despues de empaquetar)
Montaje de unidades
Comando Descripción
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
Debian en castellano
Para tener las aplicaciones en nuestro idioma lo primero que necesitamos es instalar los siguientes
paquetes:
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 además queremos saber que traducciones locales tenemos disponibles en el sistema, ejecutaremos la
siguiente instrucción:
$locale -a
Si el idioma castellano, no se encuentra disponible entre las locales del sistema las podemos incluir
en el archivo de configuración de locales, /etc/locale.gen. Para ello añadiremos al final de ese archivo las
siguientes lı́neas:
es_ES@euro ISO-8859-15
es_ES ISO-8859-1
Una vez añadidas al archivo necesitamos que las ejecute y reconfigure nuestro sistema, mediante el
comando:
#/usr/sbin/locale-gen
Además en unos de los ficheros que carga las variables de usuario añ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 próxima vez que hagamos login con el usuario cargará el nuevo perfil. Podemos comprobamos que
“los locales” son los correctos, con el mismo comando que antes: $locale
320 Servidor Linux para conexiones seguras de una LAN a Internet
Una vez tengamos disponible el idioma castellano, podemos habilitar también el soporte para el euro
en la consola. Pasa eso tenemos que añadir las siguientes lı́neas al fichero /etc/console-tools/config, fichero
de configuración de la consola:
SCREEN_FONT=lat0-sun16
APP_CHARSET_MAP=iso15
APP_CHARSET_MAP_vc2=iso15
APP_CHARSET_MAP_vc3=iso15
Si además también queremos colocar las páginas de manuales en castellano hay que instalar los si-
guientes paquetes:
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 documentación disponible en Debian, se puede consultar mediante:
$man castellanizar
Archivos de configuración
Archivo Descripción
/etc/lilo Configuración del gestor de arranque Lilo
/etc/inetd.conf Superservidor de Internet y envoltorio de demonios TCP/IP
/etc/xinetd.conf Configuración del superservidor, mediante entorno grá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 Contraseñas encriptadas de los usuarios del sistema
/etc/skel/* El contenido de este directorio se copiará 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 configuración del Vim
/etc/profile Preferencias de todos los usuarios del sistema
˜/.profile Preferencias del usuario
˜/.bash profile Preferencias del shell bash
˜/.bash login Configuración de inicio del shell bash
˜/.bash logout Configuración de finalización del shell bash
˜/.bashrc Si se ejecuta un shell interactivo bash sin entrada por consola
/etc/ssh/ssh config Configuración del cliente para las conexiones seguras SSH
/etc/ssh/sshd config Configuració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 Taré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 configuración de la consola
/etc/webmin/miniserv.conf Archivo de configuración de Webmin
/etc/squid/squid.conf Configuración del proxy Squid
/etc/squid/* Archivos de configuración del Proxy Squid
322 Servidor Linux para conexiones seguras de una LAN a Internet
Archivo Descripción
/etc/kismet/kismet ui.conf Configuración de la interfaz del sniffer wifi Kismet
/etc/kismet/kismet.conf Configuració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 Módulos que se cargarán al inicio
/etc/modules Configuración de los módulos
/etc/network/interfaces Configuración de interfaces de red
/etc/network/options Configuración de las opciones de red
/etc/host.conf Dice al sistema cómo resolver los nombres de los hosts
/etc/hostname Nombre.dominio del host local
/etc/hosts Nombre y direcció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 configuración de dispositivos hotplug (inst. diná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 configuració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 configuració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 configuració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 configuración de ACID
/etc/portsentry/portsentry.conf Archivo de configuración de PortSentry
/var/log/* Registro de logs del sistema
/etc/nessus/nessusd.conf Archivo de configuración de Nessus
/etc/proftpd.conf Configuración del servidor ProFTPD
/etc/ftpusers Usuarios del sistema que tienen permitido el acceso FTP
/etc/ypserv.conf Configuración del servidor NIS
/etc/ypserv.securenets Configura las IP que tienen permiso para usar el servidor NIS
/var/yp/Makefile Configuración opciones servidor NIS y archivos a exportar
/var/yp/yp-servers Listado de los servidores NIS secundarios de nuestro sistema
/etc/yp.conf Configuración del cliente NIS
/etc/nsswitch Archivos a importar del servidor NIS
/etc/resolv.conf Contiene el nombre y la dirección IP de los servidores DNS
/etc/bind/db.lan Añadir para los equipos de una LAN
/etc/bind/db.192.168.0 Añadir para el DNS inverso de una LAN
/etc/bind/named.conf Configuració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 Configuració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
Archivo Descripción
/etc/printcap Impresoras del sistema
/var/spool/samba Cola de impresión, por defecto, en Samba
/var/spool/mail Correo de los usuarios
/etc/dumpdates Información de las copias de seguridad realizadas
/<particion>/quota.group Archivos de configuración de quotas de grupo
/<particion>/quota.user Archivos de configuración de quotas de usuario
/etc/exports Archivo de configuración de NFS
/etc/jabber/jabber.xml Archivo de configuración del servidor Jabber
/etc/printcap Archivo de configuración de impresoras LPD
/etc/cups/cupsd.conf Configuración del servidor Cups
/var/run/cups/printcap Archivo de configuración de impresoras Cups
/var/spool/cups Directorio donde se almacenan los archivos que se van a imprimir
/etc/apache/httpd.conf Archivos de configuració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 configuración de los módulos Apache
/etc/apache-ssl/* Los mismos archivos de configuración, para Apache-SSL
/var/log/apache/* Directorio donde se almacenan los logs, generados por Apache
/etc/webalizer.conf Archivo de configuración de Webalizer
/var/www/webalizer Reportes de estadisticas web
/etc/exim4/exim4.conf.template Archivo de configuració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 configuración del servidor Fetchmail
˜/.fetchmailrc Archivo de configuración de usuario Fetchmail
/etc/courier/imapd Archivo de configuración de courier-imap
/etc/courier/imapd.cnf Opciones de courier-imap
/etc/courier/imapd-ssl Opciones de courier-imap-ssl
˜/.mailfilter Configuración de usuario Maildrop
/etc/procmailrc Archivo de configuración del servidor Procmail
˜/.procmailrc Archivo de configuración de usuario Procmail
/etc/clamav/clamd.conf Archivo de configuración de ClamAV
/etc/default/spamassassin Configuración del SpamAssassin
/etc/default/spampd Configuración del demonio de SpamAssassin
A diferencia de otras distribuciones Linux, parece que Debian no usa rc.local (el archivo de configuración
local) para el proceso de inicialización. Entonces, ¿qué facilidades suministra Debian para esta tarea?
Runlevels
Tradicionalmente en los sistemas UNIX/LINUX, cuando se inicia la má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 configuración y ejecutar diversos programas.
Dicho proceso de arranque se separa en runlevels, que son simplemente números que identifican cada
etapa, y en general van del 0 al 6, los números del 7 al 9 también están definidos pero no se suelen usar.
Hay una excepció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 años.
En algunas, se pueden encontrar los directorios /etc/rc#.d/, donde # representa al número de runlevel ;
en otras están todos los scripts contenidos en /etc/rc.d o en /etc/init.d. Lo mas aconsejable en cada caso
es consultar la documentación de cada distribución.
Podemos cofigurar gráficamente los scrips de RunLevel con la herramienta: #ksysv
1 Para tener disponible el comando update-rc.d hay que realizar un apt: #apt-get install rcconf
326 Servidor Linux para conexiones seguras de una LAN a Internet
Uno podrı́a, por ejemplo, obligar al script exemple a ejecutarse en el arranque, ponié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 número 20 o un número mayor.
Si necesitamos administra este tipo de archivos de runlevel podemos instalar con apt, el siguiente pa-
quete: #apt-get install rcconf
Mostrará un menú gráfico desde donde podremos habilitar o deshabilitar servicios en la carga inicial
del sistema.
El n.o de puertos a los que podemos acceder en cada hosts es de 65.536 (216 ). Estos puertos están
divididos en tres secciones:
Los puertos IANA: Son los 1024 primeros puertos del PC. La organización IANA (Internet As-
signed Numbers Authority) adjudicó a cada uno de estos puertos una utilidad, protocolo,. . . para
estandarizar la comunicació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 ningún uso par-
ticular y son utilizados para uso privado de los hosts y programas locales.
También existe otro “malicioso” grupo de puertos, son los puertos por defecto de los troyanos. Se
utilizan para establecer la comunicación servidor-cliente entre los ordenadores implicados en la misma. Al
existir troyanos que permiten utilizar utilizar otros puertos , la identificació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 más información, en la siguiente pá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 sección, podemos observar los puertos que hemos utilizado en este proyecto:
Personalmente utilizo el editor Vim frente al editor Emacs, este último es más completo y tiene más
opciones, pero no me son útiles. Prefiero un editor potente y a la vez simple (Vim es muy simple, una vez
conocidos los comandos básicos).
Tiene dos modos de trabajo, el modo comando y el modo inserción. Me voy a centrar, principalmente
en el modo comando debido al gran número de opciones disponibles.
Edición de ficheros
Para editar un fichero simplemente hay que hacer:
Modo inserción
Al editar un fichero entramos en el modo comando por defecto, si lo que queremos es entrar en el modo
inserción, tenemos varias opciones:
El modo inserció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 más utilizadas:
u: Deshacer la última acción. Cabe destacar que en Vim, a diferencia de otros editores se pueden
deshacer infinitos cambios, ya que esta opción no tiene lı́mite
w: Guardar
http://www.todo-linux.com/modules.php?name=News&file=article&sid=2162
IPTables es una herramienta para filtrar paquetes del kernel (2.4x o posterior).
Comandos básicos
IPTables es la evolución de ipchains y ipfwadm y básicamente permite o rechaza los paquetes que
llegan al host desde una red.
Acciones:
Comandos fundamentales:
• iptables -L, . . . ver las reglas introducidas
• iptables -F, . . . borrar todas las reglas
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
iptables -A INPUT -p TCP --dport 21 -j ACCEPT
Permitimos la comunicación con el servidor DNS:
iptables -A INPUT -p udp --dport 53 -j ACCEPT
Script muy básico de IPTables para dar acceso al 80 y al 22:
#!/bin/bash
# Permitimos que se conecten a nuestro servidor web y al ssh
iptables -A INPUT -p TCP --dport 80 -j ACCEPT
iptables -A INPUT -p TCP --dport 22 -j ACCEPT
# 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 má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
• Só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.8.112/29 -j DROP
iptables -A INPUT -s 217.116.0.144 -j DROP
iptables -A INPUT -s 195.76.172.0/24 -j DROP
iptables -A INPUT -s 155.201.0.0/16 -j DROP
En el proyecto Debian, Sarge ha sido congelada y en breve será la nueva versión ‘stable’ de Debian. La
versión testing pasara a llamarse Etch y será una versió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 versión estable y no en pruebas, hemos de modificar
nuestro /etc/apt/sources.list para que no nos cambie de versión automáticamente.
Para que mi sistema siga siendo Sarge, aunque dentro de unos dı́as lo hará en la nueva etapa como
estable, deberemos cambiarlo por este otro:
Si dejamos el archivo /etc/apt/sources.list como “testing”, nuestro sistema dejará de ser Sarge, y pa-
sará a ser Etch.
También querı́a recordar que existe una tercera versión de Debian: Debian Sid o “unstable”, que es la
versin inestable. Esta versión siempre se llamará ası́: “Sid” y no es adecuada para el uso de servidores, ya
que esta destinada a desarrollar el software que luego pasará al resto de versiones.
334 Servidor Linux para conexiones seguras de una LAN a Internet
Los mayores cambios para Sarge incluyen reemplazar el antiguo sistema de instalació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 versión 2.95. También se ha llevando a cabo la
introducció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 planificación y la elecció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.
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.
336 Servidor Linux para conexiones seguras de una LAN a Internet
Creative commons no supone renunciar a proteger tu trabajo, sino que implica que puedes escoger
qué derechos prefieres reservarte y qué derechos quieres ceder a los demás.
Tú decides en qué condiciones estás dispuesto a permitir la utilizació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 legislación, en este momento hay 6).
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.
Código legal: el texto completo de la licencia dirigido fundamentalmente a abogados.
Código digital: Una versión de la licencia legible por máquinas que ayudará a las herramientas de
búsqueda y otras aplicaciones a identificar tu trabajo en función de sus condiciones de uso.
2. Reconocimiento-SinObraDerivada
3. Reconocimiento-NoComercial-SinObraDerivada
4. Reconocimiento-NoComercial
5. Reconocimiento-NoComercial-CompartirIgual
6. Reconocimiento-CompartirIgual
Licencia escogida
Por el cará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 documentación.
Por eso cedo el derecho de realizar una explotación económica de la obra, a condició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 asignación de este tipo de licencia “Creative Common” respecto a GFDL, está justificada debido a
que, en mi opinió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 deberá actualizar con el tiempo, ya sea por mı́ o por
alguna otra persona que continú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 párrafo para cualquier persona que necesite más
información sobre la licencia:
“Esta obra está bajo la licencia de Atribución de Creative Commons: Reconocimiento-CompartirIgual
2.1 Españ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.”
Esto es un resumen legible del texto legal, la licencia completa se encuentra disponible en la dirección:
http://creativecommons.org/licenses/by-sa/2.1/es/legalcode.es
[eidD04] El equipo instalador de Debian. Guı́a de instalació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-
lación Debian GNU/Linux 3.0 para Intel x86. http://www.debian.org, Diciembre 2002.
http://www.debian.org/releases/woody/installmanual.