asegurando servicios de red, utilizando tcp wrappers en...
Post on 28-Mar-2020
1 Views
Preview:
TRANSCRIPT
Universidad Metropolitana Facultad de Ingeniería Escuela de Ingeniería de Sistemas
ASEGURANDO SERVICIOS DE RED, UTILIZANDO TCP WRAPPERS EN LINUX
Gianfranco Samuele Luigi Vellucci
Tutor: Ing. Ricardo Strusberg
Caracas, Marzo 2001
DERECHO DE AUTOR
Cedo a la Universidad Metropolitana el derecho de reproducir y
difundir el presente trabajo, con las únicas limitaciones que establece la
legislación vigente en materia de autor.
En la ciudad de Caracas, a los 28 días del mes de febrero de 2001
____________________
Gianfranco Samuele
____________________
Luigi Vellucci
APROBACIÓN
Considero que el Trabajo de Grado titulado
Asegurando servicios de red con los TCP Wrappers en Linux
Elaborado por los ciudadanos
Gianfranco Samuele
Luigi Vellucci
Para optar por el título de
INGENIERO DE SISTEMAS
Reúne los requisitos exigidos por la Escuela de Ingeniería de Sistemas
de la Universidad Metropolitana, y tiene meritos suficientes como para
ser sometido a la presentación y evaluación exhaustiva por parte del
jurado examinador que se designe.
En la ciudad de Caracas, a los 28 días del mes de marzo de 2001
___________________
Ing. Ricardo Strusberg
ACTA DE VEREDICTO
Nosotros, los abajo firmantes, constituidos como jurado examinador y
reunidos en Caracas, el día ___ de Marzo de 2001, con el propósito de
evaluar el Trabajo de Grado titulado.
Asegurando servicios de red, utilizando TCP Wrappers en Linux
Presentado por los ciudadanos
Gianfranco Samuele Luigi Vellucci
Para optar al título de
INGENIERO DE SISTEMAS
Emitimos el siguiente veredicto:
Reprobado ___ Aprobado ___ Notable ___ Sobresaliente ___
Sobresaliente con mención honorífica ___
Observaciones:
__________________ __________________ __________________ Ing. Ricardo Strusberg Ing. Vincenzo Mendillo Ing. Teodoro Lobo
Asegurando servicios de red utilizando TCP Wrappers en Linux.
I
ÍNDICE DE CONTENIDO
ÍNDICE DE CONTENIDO ................................................................ I
LISTA DE FIGURAS......................................................................II
LISTA DE TABLAS........................................................................ V
RESUMEN...................................................................................VI
INTRODUCCIÓN .......................................................................... 1
I. MARCO TEORICO...................................................................... 3
I.1 Antecedentes de los TCP Wrappers...................................... 4 I.2 El Demonio Central de Servicios de red (inetd).....................18 I.3 El Demonio Manejador del Registro de logs (syslogd) ...........21 I.4 Definición de los TCP Wrappers (tcpd) ................................22 I.5 Funcionamiento de los TCP Wrappers .................................23 I.6 Entornos Gráficos KDE y GNOME........................................30 I.7 Webmin (Sistema de Administración a Distancia) .................33
II. MARCO METODOLÓGICO........................................................40
II.1 Fase de planeación y elaboración......................................46 II.2 Fase de análisis...............................................................54 II.3 Fase de diseño................................................................61 II.4 Fase de construcción .......................................................65
III. DESARROLLO........................................................................66
III.1 Desarrollo de Kwrapper...................................................66 III.2 Desarrollo del Módulo de TCP Wrappers para Webmin........73
IV. RESULTADOS........................................................................81
CONCLUSIONES........................................................................103
RECOMENDACIONES.................................................................107
GLOSARIO ...............................................................................109
REFERENCIAS BIBLIOGRAFICAS.................................................112
APÉNDICE A.: Archivo de Configuración inetd.conf........................ 114
APÉNDICE B: Características de Linux..........................................116
APÉNDICE C. ¿Qué es Código Abierto? ........................................120
Asegurando servicios de red utilizando TCP Wrappers en Linux.
II
LISTA DE FIGURAS
Figura 1.- El demonio inetd atiende los puertos de red para los
servicios ftp, telnet y finger. .......................................................... 6
Figura 2.- El demonio inetd ha dado inicio un proceso servidor telnet
que conecta al usuario a un proceso denominado login. ................... 7
Figura 3.- El programa servidor de telnet ha sido transferido a otro
lugar, y el TCP Wrapper ha tomado su lugar. .................................. 8
Figura 4.- El programa TCP Wrapper ha iniciado el servidor telnet y
no vuelve a participar en la conexión.............................................. 8
Figura 5.- Primeras conexiones del cracker observadas con el
programa TCP Wrapper. ............................................................... 8
Figura 6.- Archivos útiles en el control de acceso. .........................11
Figura 7.- Un bosquejo de actividades en una red informática. .......12
Figura 8.- Resultado al aplicarse un proceso de reverso del servicio
finger. .......................................................................................13
Figura 9.- Ejemplo de una trampa de arena sobre el servicio tftp. ...15
Figura 10.- Muestra del contenido generado en el archivo de registro
de logs, de conexiones rechazadas................................................15
Figura 11.- Reverso del servicio finger, de un usuario conectado. ...16
Figura 12.- Intercepción y filtrado de los TCP Wrappers en solicitudes
de servicio..................................................................................24
Figura 13.- Modelo conceptual ....................................................55
Figura 14.- Diagrama de secuencia del sistema para el caso de uso
proteger servicio. ........................................................................56
Figura 15.- Diagrama de secuencia del sistema para el caso de uso
definir política.............................................................................57
Figura 16.- Diagrama de secuencia del sistema para el caso de uso
configuración de reglas................................................................57
Asegurando servicios de red utilizando TCP Wrappers en Linux.
III
Figura 17.- Diagrama de interacción: administrador – sistema........62
Figura 18.- Diagrama de interacción: protección de los servicios con
TCP Wrappers.............................................................................62
Figura 19.- Diagrama de interacción: definición de las políticas de
control. ......................................................................................63
Figura 20.- Diagrama de interacción: definición de las reglas de
control. ......................................................................................63
Figura 21.- Diagrama de diseño de clases....................................64
Figura 22.- Menú principal del Kwrapper......................................82
Figura 23.- Listado de servicios manejados por el inetd. ................82
Figura 24.- Pantalla de control de acceso. ....................................83
Figura 25.- Pantalla de servicios ofrecidos por webmin. .................84
Figura 26.- Página principal de los TCP Wrappers en webmin.......85
Figura 27.- Detalles del servicio de red. .......................................86
Figura 28.- Página donde se añade una regla. ..............................87
Figura 29.- Página donde se modifica una regla............................88
Figura 30.- Resultado de ejecutar telnet desde la IP 10.0.0.225 5...92
en prueba 1-A. ...........................................................................92
Figura 31.- Resultado de ejecutar ftp desde la IP 10.0.0.225 en la
prueba 1-A.................................................................................93
Figura 32.- Resultado de ejecutar telnet desde la IP 10.0.0.21 en la
prueba 1-A.................................................................................93
Figura 33.- Resultado de ejecutar ftp desde la IP 10.0.0.21 en la
prueba 1-A.................................................................................94
Figura 34.- Resultado de ejecutar telnet desde la IP 10.0.0.225 en la
prueba 1-B. ................................................................................95
Figura 35.- Resultado de ejecutar ftp desde la IP 10.0.0.225 en la
prueba 1-B. ................................................................................95
Asegurando servicios de red utilizando TCP Wrappers en Linux.
IV
Figura 36.- Resultado de ejecutar telnet desde la IP 10.0.0.21 en la
prueba 1-B.................................................................................95
Figura 37.- Resultado de ejecutar ftp desde la IP 10.0.0.21 en la
prueba 1-B. ................................................................................96
Figura 38.- Archivo /etc/security/banners/allow/in.telnetd..............97
Figura 39.- Archivo /etc/security/banners/deny/in.telnetd..............97
Figura 40.- Resultado de ejecutar telnet desde la IP 10.0.0.225 en la
prueba 2-A.................................................................................98
Figura 41.- Resultado de ejecutar ftp desde la IP 10.0.0.225 en la
prueba 2-A.................................................................................98
Figura 42.- Resultado de ejecutar telnet en la prueba 2-A, desde la IP
10.0.0.21...................................................................................99
Figura 43.- Resultado de ejecutar ftp en la prueba 2-A, desde la IP
10.0.0.21...................................................................................99
Figura 44.- Resultado de la ejecución del comando spawn enviando
un email...................................................................................100
Asegurando servicios de red utilizando TCP Wrappers en Linux.
V
LISTA DE TABLAS
Tabla 1.- Ejemplo de pares cliente-servidor bajo protocolo TCP/IP y
sus aplicaciones. .......................................................................... 6
Tabla 2.- Wildcards en los archivos de control de acceso. ...............26
Tabla 3.- Sintaxis para definir clientes en los archivos de control de
acceso. ......................................................................................27
Tabla 4.- Comandos que extienden las capacidades de los archivos de
control de acceso........................................................................28
Tabla 5.- Variables que recolectan información del cliente y del
servidor. ....................................................................................29
Tabla 6.- Caso de uso proteger servicio........................................52
Tabla 7.- Caso de uso definir política de control de acceso a servicios.
.................................................................................................53
Tabla 8.- Caso de uso configurar el control de acceso a servicios. ...53
Tabla 9.- Contrato seleccionar servicio. ........................................58
Tabla 10.- Contrato wrapp servicio..............................................58
Tabla 11.- Contrato seleccionar política control. ............................59
Tabla 12.- Contrato activar política de control...............................59
Tabla 13.- Contrato especificar cliente. ........................................59
Tabla 14.- Contrato especificar comandos. ...................................60
Tabla 15.- Contrato activar regla. ................................................60
Asegurando servicios de red utilizando TCP Wrappers en Linux.
VI
RESUMEN
Asegurando servicios de red utilizando TCP Wrappers en Linux
Autores: Gianfranco Samuele
Luigi Vellucci
Caracas, Febrero 2001
El presente informe describe la investigación realizada para el diseño y desarrollo de dos aplicaciones que tienen como función específica, facilitar por medio de una interfaz visual el manejo y configuración de una herramienta de seguridad denominada TCP Wrappers. Esta herramienta tiene la capacidad de definir las restricciones de acceso a los diferentes servicios de red que provee un host específico. Los objetivos específicos de este trabajo fueron: proveer una interfaz visual, con capacidad de conexión interplataforma para la gestión de los TCP Wrappers, proveer los mecanismos para la administración y consulta de las listas de restricciones de control de acceso y bitácora de las conexiones UDP y TCP manejadas por el demonio inetd y desarrollar una herramienta independiente de la distribuciones Linux existentes.
Con el propósito de cumplir dichos objetivos se realizó un estudio del
funcionamiento de los TCP Wrappers utilizando la metodología UML y el uso como plataforma base para el desarrollo de este trabajo el sistema operativo Linux en conjunto con lenguajes de programación tales como: PERL, HTML, Python y GTK.
El contenido del presente informe tiene como base fundamental el
conocimiento para definir reglas de restricciones en los archivos de control de acceso de los TCP Wrappers; igualmente fue necesario comprender la estructura del sistema de administración a distancia (webmin), y el conocimiento básico acerca de los entornos gráficos más utilizados en Linux tales como: KDE y GNOME.
INTRODUCCIÓN
Con el constante avance de la tecnología, la necesidad casi obligada
de obtener y hacer uso de la información en forma instantánea, ha generado
en la sociedad actual una necesidad de estar conectado en red bien sea para
realizar actividades laborales, de entretenimiento, búsqueda de información o
simplemente para estar actualizado con el mundo que nos rodea.
Sin embargo, debido a la gran cantidad de personas que hoy en día
pueden tener acceso a los diferentes sistemas de computación, en ocasiones
se hace uso de este medio informático para ejercer acciones que violentan
los diferentes sistemas computacionales existentes. Es por ello que surge la
necesidad de incrementar y mejorar los sistemas de seguridad en el cual se
ven involucradas peticiones de servicio de red emitidas por un cliente y la
respuesta a los servicios solicitados por parte del sistema, de modo que no
exista o sea casi nulo el riesgo de ataques informáticos.
Debido a esta problemática, aparece la necesidad de establecer un
esquema de seguridad para el control y acceso a los servicios dentro de un
sistema. Entre los mecanismos existentes, uno de estos se denomina TCP
Wrappers, el cual funciona en diferentes sistemas operativos basados en
UNIX. El mismo representa la base fundamental para la elaboración del
presente trabajo.
Los TCP Wrappers tienen como función principal controlar el acceso a
los diferentes servicios de red que ofrece un sistema específico, el cual utiliza
ciertos mecanismos esenciales al momento de ocurrir una solicitud de un
servicio de red para posteriormente prestar dicha petición. A partir de este
Asegurando servicios de red utilizando TCP Wrappers en Linux.
2
hecho surge otra necesidad, como es la de disponer de una interfaz gráfica la
que funcione en forma local y a distancia, que tenga como finalidad permitir
la configuración y manejo de los TCP Wrappers.
Debido a esto, los objetivos planteados para el siguiente trabajo
fueron:
ü Desarrollar una interfaz sobre el sistema operativo Linux que
funcione bajo los dos entornos gráficos de gran estabilidad y
mayor crecimiento tales como: KDE y GNOME.
ü Crear un módulo dentro de la aplicación de administración a
distancia Webmin que permita el manejo y control de los TCP
Wrappers a distancia.
ü Facilitar las consultas a los archivos que registran la bitácora de
acceso a los diferentes servicios que son protegidos por los TCP
Wrappers.
Es conveniente, para establecer un nivel de seguridad confiable en el
área de redes, hacer uso de varios mecanismos de seguridad que se
complementen entre sí para reducir los riesgos de ataque.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
3
I. MARCO TEORICO
En este capítulo se exponen los diferentes tópicos que sirvieron de
base para la realización de este trabajo. Previo a describir el proceso de
desarrollo de las herramientas que permiten el manejo de los TCP Wrappers,
se expone la información necesaria a evaluar y de esta manera justificar las
diferentes decisiones que se tomaron en el diseño e implementación de las
aplicaciones que se presentan en este trabajo.
Los tópicos que integran este capítulo son los siguientes:
Antecedentes de los TCP Wrappers: En esta sección se describe
la historia que fundamenta la elaboración del programa principal de los TCP
Wrappers.
Definiciones y funciones del demonio central de Servicios de
red (inetd) y el demonio1 manejador del registro de logs (syslogd):
En esta sección se explican las definiciones de los demonios inetd y syslogd
y sus respectivas funciones dentro de la ejecución de los TCP Wrappers.
Definición de los TCP Wrappers (tcpd): Se explica el
funcionamiento del demonio tcpd y los archivos que se utilizan para la
configuración de los TCP Wrappers.
Entornos gráficos KDE y GNOME: En esta sección se muestra una
breve explicación acerca de los entornos gráficos que son los más utilizados
1 Programa que se ejecuta en background en sistemas UNIX
Asegurando servicios de red utilizando TCP Wrappers en Linux.
4
por su robustez y estabilidad.
Sistema de Administración a Distancia (Webmin): En esta
sección se especifican los pasos a seguir para la construcción de módulos
para Webmin, así como las diversas funciones que pueden ser ejecutadas
en esta aplicación.
I.1 Antecedentes de los TCP Wrappers
A mediados de 1991, Wietse Venema [V93] presenció en repetidas
oportunidades una acción lesiva o ataque. Él relata que en la Universidad de
Tecnología de Eindhoven en Holanda fue víctima de un fuerte ataque de un
cracker informático quien había logrado adquirir permisos de root dentro del
sistema en reiteradas ocasiones. Esta situación es considerada un problema
grave en la seguridad de la universidad, ya que el cracker tenía ciertos
conocimientos de comandos que utilizados por error o con malas intenciones
pueden causar severos daños y/o pérdidas considerables al sistema
operativo.
Uno de los comandos preferidos ejecutados por el cracker fue el rm -rf
/, el cual representa una ejecución tan destructiva como el comando format
en MS-DOS. Usualmente el daño es reparable mediante la recuperación de
los datos a través de los denominados backups o cintas y/o dispositivos de
respaldo, pero aún así los afectados pierden gran parte del trabajo realizado
hasta ese momento.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
5
Estos incidentes provocaron un arduo proceso de investigación con el
objetivo de conocer la procedencia del individuo autor de los daños
ocasionados al sistema. La investigación se tornó compleja debido a que el
cracker eliminaba todo tipo de trazas o huellas de forma efectiva.
Fue uno de los hallazgos de la investigación fue que el cracker
vigilaba el comportamiento de los usuarios en la red haciendo uso del servicio
denominado finger. Este ofrece información acerca de los usuarios del
sistema. Para la ejecución del servicio finger no es requerida una clave de
acceso y no es común mantener una bitácora de las diferentes acciones del
mismo, lo que explica el hecho de que sus operaciones con el servicio finger
permanecieran sin ser detectadas por el administrador del sistema.
La reacción natural ante este problema, normalmente, es la de
eliminar o no proveer el servicio de finger dentro del sistema operativo y red
de computadores en cuestión. Sin embargo, se decidió que sería mucho más
productivo mantener el servicio e investigar la procedencia de las peticiones
al servicio finger.
Para ilustrar la situación del problema y su solución, se procederá a
definir con ciertos detalles una típica implementación de los servicios de red
bajo protocolo TCP/IP en sistemas operativos UNIX.
La mayoría de las aplicaciones que hacen uso del protocolo TCP/IP se
basan en el modelo denominado cliente-servidor. Por ejemplo, cuando
alguien hace uso del comando telnet para conectarse a un host, se ejecuta
un proceso interno que realiza las funciones de un servidor telnet, y a su vez
este proceso servidor posteriormente conecta al usuario a un proceso de
Asegurando servicios de red utilizando TCP Wrappers en Linux.
6
login.
Algunos ejemplos de parejas cliente-servidor se muestran en la tabla
1.
Cliente Servicio Aplicación Telnet telnetd Login remoto.
Ftp ftpd Transferencia de archivos.
Finger fingerd Información de los usuarios
Systat systatd Información de los usuarios.
Tabla 1.- Ejemplo de pares cliente-servidor bajo protocolo TCP/IP y sus aplicaciones.
El camino usual para la ejecución es el de ejecutar un proceso
denominado demonio el cual espera por todo tipo de conexiones entrantes a
la red de computadores. Al momento en el cual se establece una conexión,
este demonio (usualmente llamado inetd) ejecuta la aplicación que responde
a la petición emitida por el cliente y posteriormente regresa a su estado
inicial, a la espera de otras peticiones de servicios por parte de otras
conexiones (véase figura 1 y figura 2) .
user telnet client
ftp
telnet
finger
inetd
Figura 1.- El demonio inetd atiende los puertos de red para los servicios ftp, telnet y finger.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
7
user telnet
client login telnet server
Figura 2.- El demonio inetd ha dado inicio un proceso servidor telnet que conecta al usuario a un proceso denominado login.
Volviendo al relato anterior, ¿cómo se podía obtener el nombre del
host desde el cual el cracker realiza todas sus operaciones de espionaje?, a
primera vista esto requeriría de cambios en los software de red existentes,
sin embargo, existían algunos problemas para realizar estos cambios:
ü No se tenía la licencia sobre el código fuente para los sistemas
Ultrix, SunOS, y otras implementaciones de UNIX. Aunado a
esto, tampoco se tenía el código fuente.
ü El código fuente de la red de computadores de Berkeley (sobre
el cual la mayoría de las implementaciones de redes comerciales
UNIX TCP/IP son derivadas) estaba disponible, pero adaptarlo a
este ambiente de trabajo requería de un esfuerzo considerable
horas hombre de trabajo.
Se requería una solución que resultara eficaz y que no implicara
cambios en el software existente y que, eventualmente podría aplicarse en
todos los sistemas UNIX. Se realizó un intercambio entre programas, se
instalarían en otro computador ubicado en otro sitio los programas servidores
de red ofrecidos por el fabricante y se instala un programa trivial en el lugar
original en los cuales éstos residían. Al momento de ocurrir una conexión,
este programa trivial sólo registraría el nombre del remote host (véase figura
3) y luego ejecutaría el programa servidor de red original que ha sido
Asegurando servicios de red utilizando TCP Wrappers en Linux.
8
solicitado (véase figura 4).
user telnet client
tcpwrapper
logfile
Figura 3.- El programa servidor de telnet ha sido transferido a otro lugar, y el TCP Wrapper ha tomado su lugar.
user telnet client
telnetserver
login
Figura 4.- El programa TCP Wrapper ha iniciado el servidor telnet y no vuelve a participar en la conexión.
Esta herramienta resultaría ser la primera versión de los TCP
Wrappers.
May 21 14:06:53 tuegate: systatd: connect from monk.rutgers.edu May 21 16:08:45 tuegate: systatd: connect from monk.rutgers.edu May 21 16:13:58 trf.urc: systatd: connect from monk.rutgers.edu May 21 18:38:17 tuegate: systatd: connect from ap1.eeb.ele.tue.nl May 21 23:41:12 tuegate: systatd: connect from mcl2.utcs.utoronto.ca May 21 23:48:14 tuegate: systatd: connect from monk.rutgers.edu May 22 01:08:28 tuegate: systatd: connect from HAWAII-EMH1.PACOM.MIL May 22 01:14:46 tuewsd: fingerd: connect from HAWAII-EMH1.PACOM.MIL May 22 01:15:32 tuewso: fingerd: connect from HAWAII-EMH1.PACOM.MIL May 22 01:55:46 tuegate: systatd: connect from monk.rutgers.edu May 22 01:58:33 tuegate: systatd: connect from monk.rutgers.edu May 22 02:00:14 tuewsd: fingerd: connect from monk.rutgers.edu May 22 02:14:51 tuegate: systatd: connect from RICHARKF.TCASSIS.ARMY.MIL May 22 02:19:45 tuewsd: fingerd: connect from RICHARKF.TCASSIS.ARMY.MIL May 22 02:20:24 tuewso: fingerd: connect from RICHARKF.TCASSIS.ARMY.MIL May 22 14:43:29 tuegate: systatd: connect from monk.rutgers.edu May 22 15:08:30 tuegate: systatd: connect from monk.rutgers.edu May 22 15:09:19 tuewse: fingerd: connect from monk.rutgers.edu May 22 15:14:27 tuegate: telnetd: connect from cumbic.bmb.columbia.edu May 22 15:23:06 tuegate: systatd: connect from cumbic.bmb.columbia.edu May 22 15:23:56 tuewse: fingerd: connect from cumbic.bmb.columbia.edu
Figura 5.- Primeras conexiones del cracker observadas con el programa TCP Wrapper.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
9
La primera versión de los TCP Wrappers incluía una cantidad mínima
de código. Dado que este programa no intercambiaba ningún tipo de
información con el cliente o con los procesos del servicio, esa misma versión
pudo ser usada para muchos otros tipos de servicios de red.
Como se muestra en la figura 5, cada conexión es registrada con los
siguientes campos: fecha y hora de conexión, el nombre del localhost, el
nombre del servicio solicitado y el nombre del remote host. Los ejemplos
muestran que el cracker no sólo hace uso de terminales servidores por
discado (dial-up terminal servers) tales como monk.rutgers.edu, sino que
también ha penetrado en sistemas informáticos militares (.MIL) y
universitarios (.EDU).
El cracker realizó una serie de peticiones a los servicios de finger y
systat, con el fin de conocer que usuarios se encontraban activos en los
sistemas. Continuamente el cracker realizaba conexiones a través del servicio
telnet, presumiblemente para realizar un único intento de conexión mediante
un login para luego desconectarse inmediatamente y así evitar que el sistema
generase un reporte por repetidos intentos fallidos de acceso.
De esta forma, únicamente se podía detectar el lugar donde el cracker
realizaba sus acciones delictivas, lo que representó un gran avance sobre el
pasado, cuando solamente se sabía que algo había ocurrido.
Uno de los problemas de esa solución es que al registrar toda la
información de las conexiones y peticiones de servicios de red, se genera una
gran cantidad de información dentro del archivo de registro y esto dificultaría
la identificación del cracker.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
10
Afortunadamente, el cracker fue fácil de rastrear por los siguientes
motivos:
ü Con frecuencia trabajaba de noche, momento en el cual
existe poco movimiento en cuanto a otro tipo de actividades.
ü Continuas conexiones a un número determinado de
sistemas. El esparcir sus pruebas, lo ayudaría a esconder sus
actividades. Sin embargo, reuniendo los archivos de registro
de varios de los sistemas atacados, fue sumamente fácil
observar cuándo se encontraba activo el cracker.
ü Ningún otro individuo hacía uso del servicio systat.
Por lo tanto se adoptó la siguiente medida: negar todas las conexiones
provenientes de terminales de servicios ya abiertos, de tal manera que el
cracker podía únicamente atacar o alcanzar un sistema específico a través del
ataque a la cuenta de un usuario registrado. El objetivo perseguido era el de
lograr que el atacante dejara la mayor cantidad de trazas útiles con el fin de
poder conocerlo con mayor detalle.
Para llevar a cabo la medida elegida, se generó un mecanismo simple
de control de acceso dentro de los TCP Wrappers, de manera que, al
momento de ocurrir una conexión proveniente de un terminal la misma era
mostrada en los archivos de registro y todo el tráfico proveniente de ese
sistema sería bloqueado por el host que estaba siendo objeto de ataque,
además se aplicaría la misma medida en los diferentes servidores. Para que
esta nueva versión de los TCP Wrappers utilizara las restricciones de acceso
Asegurando servicios de red utilizando TCP Wrappers en Linux.
11
se hizo uso de dos archivos donde se definen ciertas reglas de bloqueo de
servicios de red los cuales son: /etc/hosts.allow y el /etc/hosts.deny
/etc/hosts.allow: in.ftpd:ALL /etc/hosts.deny: ALL: terminus.lcs.mit.edu hilltop.rutgers.edu monk.rutgers.edu ALL: comserv.princeton.edu lewis-sri-gw.army.mil ALL: ruut.cc.ruu.nl 131.211.112.44 ALL: tip-gsbi.stanford.edu
ALL: tip-quada.stanford.edu ALL: s101-x25.stanford.edu ALL: tip-cdr.stanford.edu ALL: tip-cromemaa.stanford.edu ALL: tip-cromembb.stanford.edu
Figura 6.- Archivos útiles en el control de acceso.
El primer archivo (/etc/hosts.allow) mostrado en la figura 6, describe
cuál combinación (servicio, host) están permitidas. En este ejemplo, el
servicio de transferencia de archivos ftp está garantizado para todos los
sistemas. El segundo archivo (/etc/hosts.deny) describe las combinaciones
(servicio, host) que están prohibidas. En el caso de los pares (servicio, host)
que no concuerden con alguna de las reglas de control de acceso todos los
accesos son permitidos.
Una vez puesto en funcionamiento la nueva versión de los TCP
Wrappers, el cracker no podía atacar haciendo uso de un terminal de
servidores de acceso público, lo cual indujo al atacante a utilizar la cuenta de
un usuario registrado en el sistema y proceder desde ese punto.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
12
El siguiente paso fue investigar cuáles cuentas de usuarios se
encontraban envueltas en el caso y esto generó la creación de un proceso
que consultaría una tabla de sitios "malos" para así enviar el resultado de la
ejecución del servicio finger y systat en el momento que alguien realice algún
tipo de conexión, lo que daría como consecuencia la posibilidad de observar
el cracker de la misma forma que él lo había estado haciendo.
Los ejemplos en la figura 7 muestran actividades de un único usuario
quien se encontraba conectado al sistema guzzle.Stanford.EDU. El resultado
de ejecutar el servicio finger arrojaría como respuesta que el nombre de la
cuenta utilizada es adrian (véase figura 8), y el acceso provino desde el
terminal de servidor tip-forsythe.Stanford.EDU, por lo que el cracker estaba
utilizando una cuenta con clave de acceso débil perteneciente al usuario
adrian.
Jan 30 04:55:09 tuegate: telnetd: connect from guzzle.stanford.EDU Jan 30 05:10:02 svin01: fingerd: connect from guzzle.stanford.EDU Jan 30 05:17:57 svin01: fingerd: connect from guzzle.stanford.EDU Jan 30 05:18:24 svin01: fingerd: connect from guzzle.stanford.EDU Jan 30 05:18:34 svin01: fingerd: connect from guzzle.stanford.EDU Jan 30 05:18:38 svin01: fingerd: connect from guzzle.stanford.EDU Jan 30 05:18:44 svin01: fingerd: connect from guzzle.stanford.EDU Jan 30 05:21:03 svin01: fingerd: connect from guzzle.stanford.EDU Jan 30 05:24:46 tuegate: systad: connect from guzzle.stanford.EDU Jan 30 05:27:20 svin01: fingerd: connect from gloworm.stanford.EDU Jan 30 05:33:33 svin01: telnetd: connect from guzzle.stanford.EDU Jan 30 05:33:38 svin01: telnetd: connect from guzzle.stanford.EDU Jan 30 05:33:41 svin01: telnetd: connect from guzzle.stanford.EDU Jan 30 05:33:50 svin01: ftpd: connect from guzzle.stanford.EDU Jan 30 05:33:58 svin01: fingerd: connect from math.uchicago.edu Jan 30 05:34:08 svin01: fingerd: connect from math.uchicago.edu Jan 30 05:34:54 svin01: fingerd: connect from math.uchicago.edu Jan 30 05:35:36 svin01: fingerd: connect from guzzle.stanford.EDU
Figura 7.- Un bosquejo de actividades en una red informática.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
13
Wed Jan 30 05:10:08 MET 1991 [guzzle.stanford.edu] Login name: adrian In real life: Adrian Cooper Directory: /u0/adrian Shell: /phys/bin/tcsh On since Jan 29 19:30:18 on ttyp0 from tip-forsythe.stanford.edu No plan.
Figura 8.- Resultado al aplicarse un proceso de reverso del servicio finger.
Durante algunos meses se identificaron serios ataques realizados a
cuentas de usuarios registrados, por lo que continuamente se enviaban
avisos a los administradores del sistema y una copia a CERT para
mantenerlos informados en cuanto a progresos se refería.
CERT sugirió que se contactara a Stephen Hansen de la Universidad de
Stanford. Esta persona ya estaba al tanto de la situación, por lo que seguía
los pasos del cracker desde hacía algún tiempo, y sus archivos de registro
proporcionaron un excelente punto de vista acerca de cómo operaba el
cracker.
El cracker tenía la ventaja de estar al tanto de muchos de los defectos
del software de los sistemas y fue muy persistente en sus intentos de obtener
privilegios de root, donde el conseguir el acceso al sistema fue sólo cuestión
de encontrar una cuenta con una clave de acceso débil.
Por varios meses el cracker hacía uso de la Universidad de Stanford
como base para el ataque de un gran número de sitios. Uno de sus objetivos
fue research.att.com, los laboratorios de investigación de la compañía AT&T
Bell. Al conocer estos ataques, el grupo de sistemas de AT&T le tendieron
una trampa de arena, donde le permitieron el acceso a un ambiente
altamente protegido por el cual pudieran vigilar todos sus movimientos.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
14
Los reversos automáticos resultantes del servicio finger ( véase figura
8) han pasado a ser de gran utilidad y en consecuencia se decidió agregar la
herramienta finger con los TCP Wrappers. Con este fin, el lenguaje para el
control de acceso fue extendido de modo que se le añadieron varios
comandos arbitrarios propios de una consola. Una vez concretada la nueva
versión del programa, para ejecutar un comando era necesario especificarlo
en cada regla luego de definir el servicio y el cliente, esto hizo posible
detectar en forma automática algunos tipos de tráfico sospechosos.
A lo largo de los meses transcurridos se detectaron constantes
peticiones tftp (trivial file transfer protocol) desde sitios muy lejanos. Este
tipo de protocolos no requiere de ningún tipo de clave, y es comúnmente
usado para descargar software del sistema en estaciones de trabajos que no
disponen de unidades de disco o por hardware dedicado a la red de
computadores. El uso de este protocolo es muy común en la comunidad
cracker ya que el mismo tiene la capacidad de lectura de cualquier archivo
del sistema.
Basándose en la ejecución constante de peticiones tftp y la nueva
versión de los TCP Wrappers, se lograron generar nuevas reglas de acceso
con un poco más de complejidad (véase figura 9) y éstas fueron configuradas
de tal forma que las peticiones locales al servicio tftp serían administradas de
la forma usual, sin embargo las peticiones restantes serían negadas y en ese
momento se ejecutaría una instrucción que mandaría por correo electrónico
el resultado de haber ejecutado un finger a la persona que intentó la
conexión.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
15
/etc/hosts.allow:
in.tftpd:LOCAL, .win.tue.nl
/etc/hosts.deny:
in.tftp: ALL: /usr/ucb/finger -l @%h 2>&1 | /usr/ucb/mail wswietse
Figura 9.- Ejemplo de una trampa de arena sobre el servicio tftp.
En la figura 9 se muestra, un ejemplo claro de una trampa de arena2,
ya que en el momento en que cualquier usuario intente efectuar el servicio
tftp, en el servidor se ejecutara un comando que le aplica el finger al usuario
conectado y envía los resultados por correo electrónico a W. Venema
Jan 4 18:58:28 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
Jan 4 18:59:45 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
Jan 4 19:01:02 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
Jan 4 19:02:19 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
Jan 4 19:03:36 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
Jan 4 19:04:53 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
Figura 10.- Muestra del contenido generado en el archivo de registro de logs , de conexiones rechazadas.
En la figura 10, se muestra un ejemplo de las actividades recientes del
servicio tftp. Las peticiones negadas se repetían cada 77 segundos. El
intervalo para el reintento depende de la implementación y puede aportar
algunos conocimientos o sugerencias acerca del tipo de sistema remoto
involucrado. De acuerdo a los resultados obtenidos por el reverso del servicio
finger (véase figura 11), sólo una persona se encontraba activa en ese
instante: aparentemente, el acceso login provenía de un sistema ubicado en
Francia.
2 Procesos o programas que simulan el funcionamiento del servicio que esta siendo comprometido y que permite hacer el seguimiento de las actividades del presunto atacante.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
16
Login name: mvscott In real life: Mark V Scott Office: 14S-134, x3-6724 Directory: /mit/mvscott Shell: /bin/csh On since Jan 4 12:46:44 on ttyp0 from cnam.cnam.fr 12 seconds Idle Time No Plan.
Figura 11.- Reverso del servicio finger, de un usuario conectado.
Desde Francia se informó que el cracker provenía de un terminal
proveniente de la NASA (sdcds8.gsfc.nasa.gov). Evidentemente el cracker
recorrió y comprometió varios sistemas, ya que el mismo comenzó desde un
terminal de la NASA hasta Francia, desde Francia hasta el MIT y del MIT
hasta Holanda.
El ejemplo en esta sección aporta sólo una ilustración limitada de el
uso de las trampas de arena. Las trampas de arena pueden ser de gran
utilidad al ser instaladas en un sistema firewall, cuya principal finalidad es la
de separar una red de computadoras organizacional del resto del mundo.
Los TCP Wrappers provee una herramienta simple y efectiva que sirve
para controlar y manejar los servicios de red ofrecidos dentro de una red de
computadoras. Para recapitular brevemente cuáles son las características
esenciales de la herramienta, se tiene:
ü Es perfectamente adaptable a servicios TCP y UDP que sean
manejados por un demonio central de red, tal como lo es el inetd.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
17
ü La configuración por defecto es tal que el software puede ser
instalado "out of the box" 3 en la mayoría de las implementaciones
de sistemas UNIX.
ü Ningún impacto es causado a usuarios legales.
ü Se minimiza el riesgo de errores o defectos en el software debido a
que el programa de los TCP Wrappers no intercambia datos con el
sistema de red del cliente.
ü Verifica las direcciones IP, y nombres de hosts realizando
comparaciones en el servidor DNS, reduciendo el riesgo de
forjamiento de IP y DNS. Esto es de suma importancia para aquellos
servicios de red como el rsh y rlogin, los cuales basan su esquema
de autenticación en el nombre de sus anfitriones.
ü La facilidad del mecanismo de control de acceso puede ser usada
para proteger sistemas abiertos. Los enrutadores de red pueden
realizar una función similar, pero éstos mantienen los registros de
tráfico no solicitado o no permitido de una forma distinta. Por otra
parte, los enrutadores de red son de gran utilidad al momento de
bloquear el acceso a puertos que normalmente no pueden ser
cubiertos o protegidos por programas semejantes a los TCP Wrappers
tales como los puertos de red del portmapper 4, NIS, NFS y X server.
3 Aplicación que instalada no requiere de cambios en la estructura del sistema operativo. 4 Demonio que provee puertos de forma dinámica a los servicios que hacen uso de los RPC.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
18
ü La facilidad de uso de las trampas de arena puede ser útil al
implementar sistemas de prevención temprana (early-warning
systems). Esto puede ser de gran utilidad para complementar los
firewall quienes sólo proveen un limitado conjunto de servicios de red
al resto del mundo; los puertos de red restantes pueden ser
perfectamente adaptados para la ejecución de trampas de arena.
I.2 El demonio central de Servicios de red (inetd)
El inetd es el demonio encargado de escuchar las conexiones que se
realizan por ciertos puertos de Internet. En el momento que este detecta una
conexión en uno de los puertos, él activa el servicio correspondiente a ese
puerto e invoca el programa que establece la comunicación entre el cliente y
el servidor para acatar dicha petición.
Este demonio central maneja únicamente servicios de red que se
encuentren definidos bajo los protocolos TCP y UDP, los cuales están
explícitamente configurados en su archivo de configuración /etc/inetd.conf,
para posteriormente proceder a enviar dicha petición al demonio tcpd o en
su defecto al programa que atiende el servicio que se esté solicitando. De
manera que, el demonio inetd basa su funcionalidad en el uso de un único
archivo en el cual se encuentran definidos parte de los servicios de red que
ofrece el sistema y que se quiere sean invocados a través de este demonio,
junto a los comandos que se ejecutan para la respuesta a la petición
solicitada.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
19
Entre los servicios por defecto que son manejados por el demonio
inetd dentro del sistema operativo Linux, están: telnet, ftp, rlogin, exec,
pop2, pop3, imap , smtp, entre otros.
I.2.1 Configuración del inetd.conf
Con la finalidad de definir un servicio dentro del inetd.conf, es
necesario que el mismo se encuentre registrado dentro del archivo
/etc/services del sistema operativo Linux. Este archivo contiene todos los
servicios que ofrece el sistema, y a su vez especifica el protocolo de red que
utiliza y el puerto mediante el cual se establece la comunicación.
La presencia de un servicio dentro del archivo /etc/services no implica
necesariamente que el mismo se encuentre activado, ni que tenga que estar
registrado en el archivo /etc/inetd.conf.
Para incluir un registro que defina un servicio es necesario cumplir con
ciertas limitaciones y con ciertos campos de orden obligatorio. En el apéndice
A se muestra el contenido del archivo inetd.conf y a continuación se
procederá a explicar de manera detallada el significado de cada uno de los
campos requeridos para definir un servicio a ser manejado por el inetd.
ü Service Name: nombre válido del servicio de red que se
encuentra registrado en el archivo /etc/services.
ü Socket_Type: contiene los valores "stream", "dgram", "raw",
"rdm" o "seqpacket", correspondiente al tipo de socket
mediante el cual se ha de establecer la comunicación.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
20
ü Protocol: especifica el protocolo mediante el cual se establece
la comunicación entre el servicio y el cliente solicitante. Este
campo debe contener un valor válido que se encuentre definido
dentro del archivo /etc/protocols.
ü Flags: las únicas dos opciones válidas como entradas para este
campo la constituyen, "wait" y "nowait". La opción “wait” se
refiere a que el puerto debe aguardar a que una solicitud sea
completada para poder liberar el puerto y de esta manera
poder atender otra conexión entrante. La opción “nowait” se
refiere a que el demonio no aguarda por la finalización de un
servicio, sino que por el contrario atiende peticiones ocurridas
en cualquier momento.
ü User: debe contener el nombre del usuario propietario del
servicio. Es requerido que dicho usuario posea la permisología
necesaria para el control del servicio.
ü Server-program: este parámetro debe contener la ruta
completa del programa que será ejecutado por el inetd cuando
una petición de servicio es localizada a través de un socket. En
caso de que el inetd ofrezca este servicio de manera interna, el
valor del parámetro en cuestión será “internal”.
ü Server-program-arguments: si el programa que se ejecuta
al momento de la petición de un servicio recibe parámetros
especiales para su ejecución, estos deben ser especificados en
este campo. En caso de que el servicio se provea de manera
Asegurando servicios de red utilizando TCP Wrappers en Linux.
21
interna estos argumentos deben estar definidos dentro de la
ejecución del programa interno.
Los campos mencionados anteriormente son obligatorios al momento
de registrar un servicio de red dentro del inetd; así mismo la secuencia de
los campos no debe variar, para que la interpretación y manejo del servicio
por parte del demonio inetd se realice de forma correcta.
I.3 El demonio manejador del registro de logs (syslogd)
El syslog es un sistema de registro de eventos disponible en la
mayoría de sistemas UNIX, el cual ofrece una gran cantidad de variantes en
cuanto a flexibilidad y funcionalidad del mismo, ya que ofrece una amplia
gama de posibilidades para registrar los diferentes acontecimientos que
ocurren en un sistema operativo.
La utilidad del syslog consiste principalmente en la ejecución del
demonio syslogd el cual se encarga de recibir los mensajes de eventos
entrantes los cuales son generados por programas, demonios y el kernel del
sistema operativo. El manejo de estos mensajes se realiza de acuerdo con las
especificaciones que se encuentran registradas en el archivo de configuración
del demonio syslogd: /etc/syslog.conf .
En el caso de los TCP Wrappers, el demonio syslogd registra todas las
conexiones tanto rechazadas como aceptadas en el archivo /var/log/secure.
El mismo registra la fecha, hora, servicio solicitado, especificaciones en
cuanto a si el servicio fue rechazado o accedido por el cliente, el hostname y
Asegurando servicios de red utilizando TCP Wrappers en Linux.
22
la dirección IP del cliente.
Este demonio es empleado por la gran mayoría de los servicios y
programas que deseen implementar un mecanismo que registre las
operaciones efectuadas por un cliente dentro del sistema, con la finalidad de
facilitar los procesos de auditoria del mismo.
I.4 Definición de los TCP Wrappers (tcpd)
Los TCP Wrappers representan un mecanismo de seguridad que
funciona bajos los diferentes sistemas operativos basados en UNIX, con la
finalidad de proteger, controlar y registrar el acceso a los servicios de red
ofrecidos por el sistema. Esta herramienta de seguridad ofrece un mecanismo
de control de acceso basado en una lista de restricciones y a su vez en el
registro de todas las peticiones de servicio que son manejadas por el
programa principal de los TCP Wrappers: el demonio tcpd.
El tcpd es el programa encargado de realizar los chequeos de control
a los servicios de red solicitados basado en las reglas definidas por el
administrador del sistema, las cuales especifican quiénes son los clientes que
van a acceder a ciertos servicios. Estas reglas se encuentran definidas en dos
archivos: /etc/hosts.allow y /etc/hosts.deny, estos poseen las mismas
características pero a su vez cumplen diferentes funciones. Uno de ellos
(/etc/hosts.allow) especifica cuáles son los clientes que tienen derechos a
cuáles servicios; mientras que en el otro (/etc/hosts.deny) se definirá que
servicios les serán negados a cuáles clientes. De este hecho surgen dos
políticas o filosofías de seguridad para controlar la permisología de los
servicios:
Asegurando servicios de red utilizando TCP Wrappers en Linux.
23
1. Todo está permitido siempre y cuando no esté expresamente
prohibido.
2. Todo lo que no está expresamente permitido, está prohibido.
La filosofía a seguir dependerá del administrador y del uso al cual va
destinado el sistema.
Los TCP Wrappers ofrecen un mecanismo de defensa y seguridad con
la finalidad de controlar el acceso a los servicios bajo protocolo UDP o TCP,
que sean activados a través del demonio central inetd.
I.5 Funcionamiento de los TCP Wrappers
A continuación, una vez que se posee conocimiento acerca de las
funciones que cumple cada uno de los demonios involucrados en los TCP
Wrappers, se procede a explicar el esquema en el cual se vislumbra la
solicitud de un servicio de red y cómo el tcpd intercepta dicha petición. En
base a las reglas definidas en los archivos de control a los cuales el tcpd
hace uso, éste acepta o niega la solicitud de un servicio solicitado por el
cliente. En la figura 12 se explica la intercepción y filtrado de peticiones de
servicios de red.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
24
ftp inetd tcpd
syslogd
in.telnetd
in.rlogind
in.talkd
In.ftpd
in.fingerd
inetd.conf
hosts.allow hosts.deny
finger
talk
telnet
rlogin
Clients Server
ftp inetd tcpd
syslogd
in.telnetd
in.rlogind
in.talkd
In.ftpd
in.fingerd
inetd.conf
hosts.allow hosts.deny
finger
talk
telnet
rlogin
Clients Server
Figura 12.- Intercepción y filtrado de los TCP Wrappers en solicitudes de servicio.
De acuerdo a la figura 12, el esquema de funcionamiento de los TCP
Wrappers [MM00] se especifica a continuación:
1. Ocurre la petición de un servicio.
2. La petición es atendida por el demonio inetd.
2.1. El demonio inetd hace uso de su archivo de configuración
(inetd.conf) y comprueba si el servicio solicitado se encuentra
definido. De ser así, el demonio tcpd intercepta dicha petición
(paso 3) o la solicitud es transferida directamente al demonio
definido para prestar ese servicio (paso 4).
3. Al momento en el cual el demonio tcpd atiende la petición, este
Asegurando servicios de red utilizando TCP Wrappers en Linux.
25
realiza una serie de verificaciones haciendo uso de los archivos
de control hosts.allow y hosts.deny: Primeramente comprueba
las reglas en el archivo hosts.allow de modo que si existe el
acceso, este servicio es garantizado al cliente sin importar la
existencia de una regla que contradiga dicho acceso en el
archivo hosts.deny. En caso que no exista la regla en el archivo
de control de acceso hosts.allow, se procede a verificar las
reglas definidas en el hosts.deny y de existir una regla que
contenga las restricciones para esa petición, la misma es
negada y la conexión es finalizada. En ambos casos el demonio
tcpd realiza una llamada al demonio syslogd , que se encarga
de registrar el acceso o la negación del servicio registrando el
evento en el archivo /var/log/secure.
4. Al momento en el cual la petición es atendida por el demonio
del servicio correspondiente, (lo cual garantiza el acceso) se
procede a realizar las llamadas al demonio syslogd para
registrar el acceso y los eventos a ocurrir.
Los dos archivos que definen las reglas de acceso y negación deben
constituir una completa gama de restricciones impuestas para todos los
servicios que están protegidos por el tcpd. La sintaxis de las reglas definidas
en cada uno de los archivos debe estar especificada de la siguiente manera:
demonio [,demonio, ....] : cliente [, cliente, ....] [: opción : opción ....]
Para definir el servicio de red al cual le va a ser aplicada a regla, se
Asegurando servicios de red utilizando TCP Wrappers en Linux.
26
especifica nombre del demonio que maneja dicho servicio y el mismo debe
coincidir exactamente con el nombre que aparece en el archivo
/etc/inetd.conf el cual es invocado por el tcpd. Se pueden definir varios
demonios en una misma regla, como también se pueden hacer
generalizaciones en los servicios haciendo uso únicamente de dos “wildcards”
definidos en la tabla 2, que son el “ALL” y el “EXCEPT”.
Los "wildcards" ofrecen flexibilidad a la sintaxis de control de acceso
necesaria dentro de los archivos que contienen las reglas de control y acceso.
A continuación en la tabla 2 se muestran los "wildcards” definidos para ser
utilizados por los TCP Wrappers:
Wildcard Descripción
ALL Compara todos. LOCAL Compara únicamente los hostname que
no contengan el carácter "." KNOWN Compara cualquier nombre de usuario
conocido. También compara todo host cuyo hostname y dirección IP es conocida.
UNKNOWN Compara cualquier nombre de usuario desconocido. También compara todo host cuyo hostname y dirección IP es desconocida.
PARANOID Compara todo host, donde el conjunto de dirección IP y hostname no coinciden basado en la resolución de DNS.
EXCEPT Esta palabra clave es un operador que representa la excepción de alguna dirección IP o hostname.
Tabla 2.- Wildcards en los archivos de control de acceso.
Luego de especificar el servicio al cual se le aplicará la regla, se separa
Asegurando servicios de red utilizando TCP Wrappers en Linux.
27
por dos puntos y en la misma línea se especifica el cliente que se quiere
incluir en la restricción. Uno o varios clientes pueden ser especificados
mediante el uso de las diferentes sintaxis definidas dentro de los TCP
Wrappers (véase tabla 3).
Sintaxis Cliente Descripción Hostname Especifica el nombre del host o la
dirección IP del sistema cliente. Si utiliza un hostname se debe resolver el nombre por dirección IP por medio de un DNS, NIS, /etc/hosts.
.domain El uso de esta sintaxis, asume que esta definido el DNS en la red. Cualquier hostname que se resuelve por hostname.domain, tiene el acceso garantizado.
Net_number. Esta sintaxis combina la porción de direcciones IP mostradas, por ejemplo si el net_number. es 87.3. , todo sistema en los cuales la dirección IP comienza con 87.3. combinará sin importar la sub-máscara de red utilizada.
@netgroup El símbolo @ indica que un grupo dentro de la red es especificado, causando que todos los hosts dentro de ese grupo de red, sean validados para su debido acceso o negación.
Net_number/net_mask Esta sintaxis se utiliza para especificar sub-redes. Por ejemplo, 144.20.16.0 / 255.255.240.0 , es una especificación para el acceso o negación de conjunto de direcciones que van desde la 144.20.16.0 hasta la 144.20.31.255.
Tabla 3.- Sintaxis para definir clientes en los archivos de control de acceso.
Luego de definir los clientes dentro de los archivos que contienen las
Asegurando servicios de red utilizando TCP Wrappers en Linux.
28
reglas de acceso y negación (hosts.allow, hosts.deny) , se pueden definir, en
la misma regla, los comandos, los cuales constituyen ciertas opciones y
utilidades adicionales que se listan en la tabla 4.
Tabla 4.- Comandos que extienden las capacidades de los archivos de control de acceso.
Como limitante en el uso de comandos, la utilización del comando
Claves Opcionales Descripción Keepalive Ocasiona que el servidor envíe
periódicamente mensajes al cliente, si éste no contesta la conexión esta se considera interrumpida y luego es finalizada.
Linger seconds Especifica el número de segundos después del termino de una conexión durante el cual el servidor intentará despachar datos no enviados.
Allow Deny
Estas opciones permiten el mantenimiento de las reglas de negación y acceso sobre el mismo archivo.
Spawn Shell_command
Ejecuta un comando del shell especificado como un proceso sin haber especificado una regla.
Twist Shell command
Ejecuta el comando shell especificado como un proceso de reemplazo para el proceso especificado en el ultimo campo del archivo /etc/inetd.conf.
Rfc931 seconds Ocasiona que el servidor ejecute una llamada al cliente para obtener el nombre de usuario que está solicitando un servicio. El cliente debe tener activo el demonio identd, o un demonio compatibleRFC931, RFC1413. Esta opción no se aplica para servicios que utilicen el protocolo UDP.
Banners dir Especifica el directorio dir , en el cual el demonio tcpd, realiza la búsqueda de un archivo con el nombre del servicio solicitado y manejado por el tcpd, donde su contenido será desplegado inicialmente al cliente que solicite el servicio.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
29
“banners” no aplica para servicios que se conecten a través del protocolo
UDP.
La mayoría de estas opciones utilizan la información del cliente que
realiza la petición recolectada por el tcpd, la cual es almacenada en variables
definidas por los TCP Wrappers. Las mismas son especificadas en letras y
precedidas por el signo "%" (véase tabla 5).
Tabla 5.- Variables que recolectan información del cliente y del servidor.
El uso de “wildcards” ofrece grandes ventajas, pero en función de
Variable Significado %a Dirección IP del cliente %A Dirección IP del servidor
%c
Comienza como usuario@hostname, usuario@IP-address, hostname o IP-address. Dependiendo de cual está disponible.
%d El nombre del demonio. %h El hostname del cliente o la dirección
IP si el hostname no está disponible %H El hostname del servidor o la dirección
IP si el hostname no está disponible %n El hostname del cliente. Si el host es
desconocido, intenta resolver por su reverso por medio de un DNS lookup.
%N El hostname del servidor. %p El proceso identificador del demonio
(PID). %s Comienza como demonio@host o
demonio@IP-address, dependiendo de la información disponible.
%u El nombre de usuario del cliente. Resuelve el nombre si el host es desconocido. El uso de esta variable ocasionará que el demonio tcpd intente hacer una llamada RFC931.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
30
aprovecharlas al máximo, es necesario saber que el “wildcard” “EXCEPT” no
puede ser utilizado para hacer excepciones de un nombre de cliente ni una
única dirección IP. Para poder utilizar el “wildcard” “PARANOID” es necesario
contar con la instalación los TCP Wrappers compilados con la opción –D
paranoid, para que la comparación de la dirección IP y el hostname se
ejecute de manera correcta.
Es necesario tener conocimiento de que los “wildcards” “KNOWN” y
“UNKNOWN” en la comparación para los nombres de usuarios en la máquina
cliente, basan su funcionalidad en la respuesta del host por medio del
demonio identd, el cual es el programa que se encarga de emitir el nombre
correspondiente al usuario que se encuentre conectado al momento de
realizar una petición. Si el demonio identd está activado del lado del cliente el
“wildcard” “KNOWN” realiza la comparación y obtiene la identificación del
usuario de forma correcta, pero en caso de no encontrarse activo el demonio
identd, el nombre de usuario será desconocido y el “wildcard” “UNKNOWN”
tomará lugar.
El uso de los “wildcards”, comandos y variables que recolectan
información del cliente y del servidor, extienden las capacidades al momento
de definir cada regla, de tal manera que esto impide la redundancia en la
declaración de clientes y sobre todo para la generalización para los demonios
en cada regla. De esta manera, dichas capacidades extienden y facilitan al
usuario la declaración de reglas de acceso y negación.
I.6 Entornos Gráficos KDE y GNOME
Asegurando servicios de red utilizando TCP Wrappers en Linux.
31
Linux es un sistema operativo el cual ofrece una gran variedad de
herramientas, aplicaciones (véase apéndice B) y entornos gráficos como el
KDE y GNOME. Dichos entornos gráficos cumplen las mismas funciones, sólo
que las llevan a cabo de manera distinta. La mayoría de estos escritorios son
softwares de libre distribución (véase apéndice C) y existe una comunidad
que puede realizar aportes al sistema sin ningún tipo de implicación o
problema. Esto ha generado que existan una gran cantidad de interfaces
gráficas que ayudan a los usuarios del sistema a manipular, utilizar y
entender el funcionamiento del sistema operativo y a dar soporte a una serie
de aplicaciones que sólo pueden ser ejecutadas dentro de este tipo de
ambiente.
Entre las interfaces gráficas más comunes y completamente adoptadas
por la gran mayoría de las distribuciones Linux existentes en el mercado, se
destacan por su estabilidad, versatilidad y diseño, los entornos KDE y
GNOME. Ambos entornos gráficos han surgido para satisfacer la necesidad de
contar con un escritorio fácil de utilizar para estaciones de trabajo UNIX,
guardando similitud con el escritorio que puede encontrarse en MacOS o
Windows 95/NT.
I.6.1 KDE (Kool Desktop Environment)
KDE es un proyecto iniciado en 1996 por Matthias Ettrich [KD00] con
el propósito fundamental de aprovechar el poder que ofrece el sistema
operativo UNIX con el confort de un escritorio moderno y fácil de utilizar. Este
ambiente gráfico, si bien ha sido diseñado específicamente para el sistema
operativo Linux, también funciona, actualmente, con otros sistemas tales
Asegurando servicios de red utilizando TCP Wrappers en Linux.
32
como: Solaris, FreeBSD, OpenBSD, IRIX, HP-UX, MKLinux, LinuxPPC.
KDE provee un escritorio de ambiente gráfico completo, incluyendo un
manejador de archivos, un sistema de ayuda, un sistema de configuración y
una amplia gama de herramientas y utilidades, unido a un número creciente
de aplicaciones tales como cliente de correo (Kmail), programas de diseño de
imágenes, entre otros.
Cualquier persona u organización puede desarrollar aplicaciones y
herramientas funcionales bajo el entorno gráfico KDE, debido, precisamente,
a que el software propio de esta interfaz se rige bajo la licencia GPL (General
Public License), es decir, el código fuente es libre y perfectamente
modificable para satisfacer distintos tipos de necesidades. La aplicación a
desarrollar puede regirse bajo la misma licencia del entorno o puede ser
considerada también de tipo comercial, si así se requiere.
I.6.2 GNOME (GNU Network Object Model Enviroment)
El proyecto GNOME [GN00] nace como un esfuerzo por crear un
ambiente de escritorio completo para sistemas de libre distribución. Desde
sus inicios, el principal objetivo de este proyecto ha sido proveer al usuario
de una gama de aplicaciones amigables dentro de un escritorio de fácil uso.
Al igual que el entorno gráfico KDE, GNOME se rige bajo la licencia
GPL y ha sido diseñado para ser ejecutado en sistemas operativos con
kernels basados en UNIX tales como: Solaris, SCO UNIX, Linux, entre otros.
Este entorno gráfico de escritorio se ve representado por un ambiente
Asegurando servicios de red utilizando TCP Wrappers en Linux.
33
basado en ventanas con facilidades destinadas a simplificar la interacción
entre el usuario y el sistema operativo. Provee una plataforma de desarrollo
compuesta por una gran colección de herramientas, librerías y componentes
útiles para la realización de poderosas aplicaciones sobre UNIX.
GNOME incluye una gran colección de software agrupadas en una
gama de géneros que incluye desde medianas a grandes herramientas
utilitarias hasta librerías de bajo nivel útiles para el desarrollo de aplicaciones
destinadas a usuarios finales. Entre estas librerías se encuentran aquellas
destinadas a la creación de interfaces gráficas útiles para alcanzar los
objetivos que se persiguen en este proyecto.
I.7 Webmin (Sistema de Administración a Distancia)
Webmin es una interfaz para la administración de sistemas basada en
web, implementable en sistemas operativos derivados de UNIX. Con él se
pueden añadir cuentas de usuarios, configurar servidores de nombre (DNS),
servidor de web (Apache), compartir archivos, entre otros, obteniendo la
ventaja de realizar estas operaciones desde cualquier navegador que soporte
tablas y formularios a través de cualquier computadora conectada en red
(bien sea en intranet o internet) .
La mayoría de los servicios de red en los sistemas operativos derivados
de UNIX hacen uso de diferentes directorios para localizar sus archivos de
configuración, los cuales son manipulados y configurados por esta
herramienta de administración. Debido a esta característica, webmin sólo
puede ser ejecutado en sistemas para los cuales ha sido específicamente
Asegurando servicios de red utilizando TCP Wrappers en Linux.
34
concebido y configurado.
Este sistema consiste en un servidor web y un número de programas
CGI (Common Gateway Interface), los cuales actualizan directamente los
archivos de configuración del sistema tales como el /etc/inetd.conf y
/etc/passwd. El servidor web y todos los programas CGI están escritos en el
lenguaje de programación PERL versión 5, y no existe la necesidad de utilizar
módulos externos, sólo se requiere del lenguaje de programación para
ejecutarlo. Los módulos para las nuevas versiones del webmin puede
localizarse en su [CWW] página web principal.
La aplicación webmin ha sido adquirida por la compañía de Linux
Caldera Systems, lo cual trae como consecuencia que todas las versiones
pasadas y futuras del programa se encuentren disponibles bajo licencia GPL,
y por consiguiente, en ambientes Linux y otras plataformas, el mismo puede
ser distribuido y modificado completamente gratis, aún cuando se destine
para usos comerciales. Este hecho resulta fundamental como sustento para la
realización de este proyecto, ya que se persigue generar un módulo de TCP
Wrappers para esta herramienta de administración.
I.7.1 Construyendo módulos para Webmin
Webmin esta diseñado para permitir la fácil incorporación de módulos
adicionales sin realizar modificaciones considerables al código ya existente.
Estos módulos pueden ser desarrollados por personas no involucradas
directamente con el desarrollo original del webmin y distribuidos bajo la
actual licencia por la cual se rige la distribución de esta herramienta.
Un módulo debe ser escrito para administrar un servicio o servidor, tal
Asegurando servicios de red utilizando TCP Wrappers en Linux.
35
como el archivo de password de UNIX o el Servidor Web Apache.
Teóricamente los módulos que se agregan al webmin pueden ser escritos en
cualquier lenguaje, sin embargo se recomienda el uso del lenguaje de
programación de PERL por dos razones fundamentales: el webmin, por estar
enteramente programado en lenguaje PERL, provee una librería de funciones
comunes que pueden ser utilizadas por cualquier módulo desarrollado en
PERL versión 5.002 o superior, y la otra razón es la portabilidad de los
módulos en cualquier sistema UNIX y tipos de CPU (Central Process Unity).
Cada módulo tiene su propio directorio dentro del directorio base del
webmin. Generalmente éste se ubica en los directorios /etc/webmin y
/usr/libexec/webmin/ (distribución OpenLinux de Caldera), en la cual se
almacenan todos los programas CGI de cada módulo y archivos de
configuración. Como primer paso para generar un módulo para webmin, es
necesario crear un directorio con el nombre del módulo que se está
generando en la ruta de acceso /usr/libexec/webmin/, directorio que
contendrá todos los archivos referentes a la programación y configuración del
módulo a generar para el webmin.
La aplicación webmin consta de un menú principal en el cual se
despliegan los módulos soportados actualmente. Para que un módulo
aparezca en el menú principal, debe contener por lo menos dos archivos
dentro de la siguiente ruta: /usr/libexec/webmin/<nombre del módulo>. Un
directorio a crear es el "<nombre del módulo>/images". En el mismo se
almacena el archivo "icon.gif", que representa la imagen del icono o logo del
módulo a ser mostrado en el menú principal. Existen ciertas especificaciones
en cuanto a la imagen: la primera es el tamaño del icono, el cual debe ser de
48X48 píxeles; y la segunda es utilizar el mismo esquema de colores
Asegurando servicios de red utilizando TCP Wrappers en Linux.
36
empleados por los íconos de los otros módulos. También es necesario crear el
archivo "module.info" dentro del directorio "/usr/libexec/webmin/<nombre
del módulo>/", el cual contiene la información acerca del módulo y el sistema
operativo en el cual se ejecuta. Cada una de las líneas de este archivo es de
la forma "nombre=valor". Los nombres requeridos y sus valores son:
NAME: una abreviación para el nombre del módulo a generar.
DESC: una descripción del módulo. Este texto es el que se mostrará
debajo del icono en el menú principal.
OP.SUPPORT: lista de sistemas operativos soportados por el módulo.
El módulo sólo será mostrado si el sistema operativo en el cual se ha
instalado webmin se encuentra definido en esta lista.
DEFENDS: listado de las dependencias hacia otros módulos. Si el
módulo A depende del módulo B entonces la aplicación webmin no permitirá
que el módulo B sea eliminado mientras el módulo A continúe instalado.
Igualmente webmin no permitirá que el módulo A sea instalado mientras B
no se encuentre instalado aún.
CATEGORY: este valor determina en que categoría del menú principal
de webmin residirá el módulo. Los valores soportados son webmin, system,
server y hardware. Si no se especifica la categoría del módulo dentro del
archivo "module.info", el módulo residirá en la categoría others.
I.7.2 Vista y Apariencia de módulo a generar.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
37
Todos los módulos de webmin deberían tener el mismo esquema
general de colores, vista y apariencia definidas por las siguientes reglas:
ü Todas las páginas deben ser visibles mediante el uso de
cualquier navegador que soporte imágenes, tablas y
formularios. Las características adicionales de los navegadores
tales como cuadros (frames), HTML, Javascript o Java no
deberían ser usadas a menos de que no exista otra opción.
ü Todos los programas CGI que generen código HTML deben
invocar a la función header()5. Los módulos usan fuente de
texto de tipo helvética de 50 puntos color negro con un fondo
transparente, creado por la aplicación gráfica GIMP. El módulo a
realizar debería emplear el mismo tipo de fuente, tamaño y
estilo para mantener la consistencia con los otros módulos y el
webmin en sí.
ü Es recomendable tratar de evitar la generación de formularios
de HTML que contengan gran número de campos de entrada.
Algunos navegadores (particularmente Netscape en sistemas
operativos derivados de UNIX) se tornan lentos al momento de
ejecutar dichas páginas.
ü Cada icono en el menú principal representa un enlace al
5 Función descrita por Tim Niemueller en Webmin Modules [NW00].
Asegurando servicios de red utilizando TCP Wrappers en Linux.
38
directorio donde residen los archivos de programación y
configuración del módulo, por lo tanto se debe contar dentro
del directorio con un archivo "index.cgi" o "index.html", el
cual será ejecutado al momento de que un usuario haga click
sobre el icono.
I.7.3 Programas CGI del modulo a generar
El servidor web de webmin maneja archivos con la extensión CGI
como programas de interfaz, al igual que otros servidores web. Todos los
formularios, menús y otras páginas en el módulo serán generados por estos
programas, por lo que se requiere conocimientos básicos de los conceptos de
programación en CGI y HTML para la realización de un módulo para
webmin.
Asumiendo que el módulo sea programado el PERL, se debe comenzar
por programar un script que contenga funciones generales que han de ser
usadas por los programas CGI del módulo. Usualmente este módulo script
adopta el mismo nombre del módulo a crear.
I.7.4 Funciones comunes
Webmin incluye dentro de los archivos útiles para su ejecución un
script programado en PERL denominado "web-lib.pl", el cual contiene un
número de funciones útiles para generar código HTML, división de archivos y
una serie de procesos que los módulos de webmin necesitan realizar.
Estas etapas definen los primeros pasos a seguir para programar un
Asegurando servicios de red utilizando TCP Wrappers en Linux.
39
módulo manejable por la aplicación webmin. De aquí en adelante todo
depende de las especificaciones, requerimientos y procesos que el módulo
debe llevar a cabo para así alcanzar los objetivos establecidos.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
40
II. MARCO METODOLÓGICO
En todo desarrollo de sistemas es esencial cubrir una serie de etapas
que permitan organizar las actividades relacionadas con la creación,
presentación y mantenimiento de los sistemas y que a su vez conduzcan a la
solución del problema planteado. Estas etapas conforman lo que se denomina
“ciclo de vida del software”, y son las etapas las cuales todo sistema debe
cumplir desde su inicio hasta su final ización. A lo largo de este proceso
evolutivo hay que tomar en cuenta los siguientes aspectos críticos para que
todo sistema sea exitoso:
ü La estrategia primordial consiste en examinar rigurosamente los
requerimientos y elaborar un diseño formal que contribuyan a
aumentar las probabilidades de crear un sistema eficiente. Con
esto se logra aminorar el riesgo de fracaso en el proceso de
desarrollo de todo sistema.
ü Crear un proceso que puedan reproducir los individuos, y sobre
todo los equipos de trabajo. No se sustenta el desarrollo que se
funda en logros y esfuerzos individuales.
ü Detectar y realizar, de ser necesario, los posibles cambios a que
hubiera a lugar en las etapas iniciales del proceso de desarrollo.
ü Establecer un riguroso examen y diseño que permita crear
sistemas robustos, susceptibles de mantenimiento y capaces de
soportar una mayor reutilización del software.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
41
Ahora bien, para definir el ciclo de vida que rige el desarrollo de este
proyecto de grado, la metodología a implementar es la denominada UML
[L99] (Unified Modeling Language o Lenguaje Unificado de Construcción de
Modelos). La finalidad de este método de desarrollo es describir modelos de
sistemas (del mundo real y del mundo del software) basados en los
conceptos de objetos (cosas, conceptos). Un sistema (tanto en el mundo real
como en el mundo del software) suele ser extremadamente complejo; por
ello es necesario dividir el sistema en partes o fragmentos si se quiere
entender y administrar su complejidad. Estas partes pueden ser
representadas como modelos que describan y abstraigan sus aspectos
esenciales.
Por lo tanto, un paso útil en la construcción de un sistema de
software, es el de crear modelos que organicen y comuniquen los detalles
importantes del problema de la vida real con que se relacionan y del sistema
a construir.
En el caso de este proyecto, el problema consiste en crear un
mecanismo de interfaz gráfica que permita la configuración (tanto por vía
local como a distancia) de los TCP Wrappers dentro del sistema operativo
Linux, permitiendo así que el administrador del sistema establezca sus
políticas para el control de acceso de los servicios haciendo uso de una
aplicación gráfica encargada para tal fin. De esta manera se garantiza
minimizar los errores que pueden existir cuando se editan y configuran
directamente los archivos que contienen las reglas necesarias para el control
de acceso a los servicios.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
42
Por otra parte se requiere de un conocimiento no exhaustivo por parte
del administrador en cuanto a los TCP Wrappers se refiere para su utilización
y configuración de las bondades que este sistema aporta.
Continuando con la metodología UML, el ciclo de vida de un sistema se
rige por las siguientes etapas:
Fase de planeación y elaboración: consiste en determinar los
requerimientos, los cuales representan una descripción de las necesidades o
deseos de un producto, y definir los casos de uso, documentos narrativos que
describen la secuencia de eventos de un actor (agente externo) que hace uso
del sistema para completar un proceso; con ellos se describen los procesos
principales involucrados dentro del sistema.
Fase de análisis: consiste en descomponer el problema en conceptos
u objetos individuales mediante la realización de los modelos que representan
las divisiones o partes que en conjunto conforman el sistema, a fin de
conocerlo y entenderlo. Se basa en la construcción de un modelo conceptual
que explica los conceptos significativos en un dominio del problema y en el
cual se muestran los conceptos, asociaciones entre ellos y los atributos que
los conforman. Un concepto representa una idea, cosa u objeto. Otro de los
modelos fundamentales dentro de esta fase, son los diagramas de secuencia
del sistema, en los cuales se muestra gráficamente los eventos que fluyen de
los actores al sistema. Por último se tienen los contratos, documento que
describe lo que una operación se propone lograr y que contribuyen a definir
el comportamiento de un sistema; ellos describen el efecto que sobre él
tienen las operaciones. En esta fase se da prioridad al conocimiento de los
requerimientos, los conceptos y las operaciones relacionadas con el sistema.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
43
A menudo se caracteriza por centrarse en cuestiones concernientes a: cuáles
son los procesos, los conceptos, entre otros.
Fase de diseño: consiste en elaborar una solución lógica basada en
la información recolectada, especificaciones y requerimientos obtenidos en las
dos fases previas (fase de planeación y elaboración y fase de análisis). Su
esencia es la elaboración de los diagramas de interacción, los cuales
muestran gráficamente cómo los objetos se comunicarán entre ellos a fin de
cumplir con los requerimientos. Con la realización de los diagramas de
interacción se da paso a la definición de los diagramas de clases. Los cuales
resumen la definición de las clases (e interfaces) a ser implementadas en
software.
Fase de construcción: consiste en codificar toda la información
proveniente de la fase previa de diseño para luego ser escrita en un lenguaje
de programación orientado a objetos de preferencia.
Una de las fases o etapas del ciclo de vida de un sistema que no se
encuentra definido dentro de la metodología UML y que sin embargo es de
gran importancia, es la fase de prueba del sistema resultante. Esta fase
consiste en realizar una serie de pruebas elaboradas de manera estructurada
y someter al sistema en situaciones y/o condiciones normales de uso con el
fin de obtener los resultados previstos o en su defecto conseguir los errores
que posteriormente deben ser corregidos.
Otra de las fases importantes en todo trabajo académico y no
contemplada explícitamente en la metodología UML, es la fase de
investigación y/o levantamiento de información, etapa previa a todas las
Asegurando servicios de red utilizando TCP Wrappers en Linux.
44
expuestas anteriormente y de la cual se requiere un tiempo de dedicación y
realización considerable. Parte de esta fase es realizada en la primera parte
de este proyecto y se complementa con la consecución de las demás etapas.
La estrategia a adoptar para obtener la información útil y necesaria en
la realización de este proyecto se basa en la consulta de libros, manuales,
documentos técnicos, papers publicados, entre otros. Sin embargo, el gran
aporte e información valiosa se obtiene a través de la consulta de diferentes
sitios y páginas web (Linux, documentación de Linux, seguridad bajo
ambiente Linux, documentación de los TCP Wrappers, entre otros) aunado a
la colaboración invaluable del tutor de este proyecto y personas relacionadas
con temas de seguridad, quienes, a través de discusiones (en persona o por
medio electrónico) y planteamiento de casos, han sabido dar respuesta a las
interrogantes surgidas y presentadas con respecto a este trabajo durante su
realización. Hay que recordar que los TCP Wrappers conforman un sistema ya
existente, funcional y que ha sido adoptado por la gran mayoría de las
diferentes distribuciones Linux en el mercado como uno de los mecanismos
de seguridad y defensa propio del sistema operativo. Por lo tanto una ayuda
adicional en cuanto al entendimiento y funcionamiento de este mecanismo de
seguridad se alcanza con el uso directo del sistema, al realizar las
configuraciones y pruebas dentro de un ambiente de redes de computadoras,
observando y comprendiendo los resultados que se obtienen.
A lo largo de esta fase de investigación se ha de tomar en cuenta
ciertos aspectos que pueden resultar factores decisivos en la interpretación
de la información que se obtiene por los diferentes medios consultados. Se
ha visto como cierta información escrita en libros, al realizar las pruebas
directas con el sistema, generan resultados erróneos; también se ha de ser
Asegurando servicios de red utilizando TCP Wrappers en Linux.
45
muy selectivo y precavido con la información que se obtiene vía web, ya que
no todo lo que en ella aparece resulta ser cierto o está dirigida de forma
malintencionada con el fin de ocasionar resultados contraproducentes. Estos
problemas son resueltos con la consulta de información proveniente de
diversas fuentes que sean confiables y reconocidas, lo que permite asegurar
la veracidad del documento y establecer las comparaciones entre ellos para
así detectar y entender los aspectos semejantes y los puntos en los cuales
difieren.
Hay que recordar y tomar en consideración lo siguiente: la información
que se obtiene a través de medios impresos como son libros, revistas,
publicaciones, entre otros y aquella que se obtiene por medios electrónicos,
tales como páginas web, forum y correo electrónico, si bien es cierto que
proporcionan el conocimiento necesario para el entendimiento de lo que se
ha recopilado, también resulta ser inútil si no se es capaz de transmitir o
transformar ese conocimiento en la práctica y/o en situaciones de la vida
real. En estos casos es cuando se torna importante una figura con la
experiencia en el ramo, que sirva de apoyo en el paso de traducir la teoría a
la práctica y que sirva de referencia ante los diferentes obstáculos que se
presentan al momento de realizar cualquier tipo de proyecto. Para este
trabajo de grado dicha figura se encuentra totalmente representada en el
tutor, persona que resulta ser guía, aquella con la experiencia en sistemas de
seguridad bajo ambientes de redes de computadoras y con el conocimiento y
práctica con el mecanismo de control de servicios TCP Wrappers dentro del
sistema operativo Linux.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
46
Todo el proceso de investigación y levantamiento de información
involucra un proceso continuo y no estructurado, en cuanto a tiempo se
refiere, debido, precisamente, a las características de este proyecto. Los TCP
Wrappers son un mecanismo de seguridad que involucra el control de acceso
a los servicios que se prestan en una sistema. Por tratarse de un proyecto
referente a seguridad, ámbito muy cambiante y volátil, en el cual surgen, a
diario o en espacios de tiempo muy cortos, nuevas amenazas, nuevas
herramientas o mecanismos de control y por ser los TCP Wrappers un
sistema ya implantado y funcional como mecanismo de seguridad dentro de
las diferentes distribuciones de Linux existentes en el mercado, se ha de
estar constantemente actualizado e informado de posibles fallas o huecos de
seguridad en el sistema, soluciones a estas fallas y las debidas
actualizaciones que se generan por tal motivo.
Una vez obtenida la información, haberla estudiado y comprendido a
fondo, se procede a clasificarla con el fin de poder aislar cada uno de los
problemas que se presentan para de esta manera poder sustentar las bases
útiles en el proceso evolutivo por el cual ha de transcurrir el desarrollo de
este proyecto de grado.
II.1 Fase de planeación y elaboración
Esta constituye la primera etapa en la metodología UML y una de las
metas primordiales es la determinación de los requerimientos: identificar y
documentar lo que en realidad se necesita, en una forma que claramente sea
atendida por el equipo de desarrollo. Debido a las características de este
proyecto, en el que no existe una entidad o individuo en específico al cual
Asegurando servicios de red utilizando TCP Wrappers en Linux.
47
interrogar por posibles necesidades, sino que todo surge por motivos de
iniciativa propia, con calidad de aporte a la comunidad Linux a nivel mundial,
la definición de requerimientos se define a partir de la investigación e
información recolectada por los diferentes medios consultados. El reto
consiste en definir las necesidades de manera inequívoca, de modo que sean
detectados los riesgos y no se presenten sorpresas al momento de entregar
el producto (en este caso la aplicación).
Para proceder a definir los requerimientos se recomienda especificar
de antemano los siguientes puntos:
Panorama general: este proyecto tiene por objeto crear una
aplicación con interfaz gráfica para la administración del mecanismo de
seguridad y defensa TCP Wrappers, tanto local como a distancia, para así
establecer las políticas de filtrado en cuanto a acceso de servicios se refiere.
Clientes: todo administrador que haga uso de alguna de las
distribuciones Linux e implemente los TCP Wrappers como mecanismo de
seguridad para controlar el acceso a los servicios que se prestan y que son
invocados por el demonio inetd.
Metas: en términos generales, la meta es proveer a la comunidad
Linux y todo administrador de sistema que haga uso de los TCP Wrappers, de
un mecanismo de seguridad, de una herramienta gráfica amigable y que
requiera de un conocimiento básico y no exhaustivo del mismo, para qué
sirven y cómo se configuran. Más concretamente la meta incluye:
Asegurando servicios de red utilizando TCP Wrappers en Linux.
48
1. Configurar de una forma amigable el control de acceso a los
servicios que son invocados por el demonio inetd y que hagan
uso de los TCP Wrappers como mecanismo para tal fin.
2. Minimizar el conocimiento exhaustivo, por parte del
administrador del sistema operativo Linux, necesario para
entender el funcionamiento y la manera cómo se configuran las
políticas o reglas de acceso a los servicios que han de consultar
los TCP Wrappers para tomar decisiones pertinentes.
3. Permitir la configuración de los TCP Wrappers no sólo
localmente sino también a distancia bajo un ambiente y estilo
web.
Parte de esta fase consiste también en especificar las funciones del
sistema, operaciones que éste ha de realizar, las cuales han de ser listadas
en grupos cohesivos y lógicos. Las funciones se clasifican o se categorizar en:
ü Evidentes: funciones que deben realizarse y el usuario del
sistema debe saber que se han realizado.
ü Ocultas: funciones que deben realizarse aunque no es visible
para los usuarios del sistema.
Para la aplicación a desarrollar en este proyecto, se tienen dentro de la
categoría evidente las siguientes funciones:
Asegurando servicios de red utilizando TCP Wrappers en Linux.
49
ü Proteger los servicios invocados por el demonio inetd para que
hagan uso de los TCP Wrappers como mecanismo de seguridad
para el control de acceso.
ü Definir las reglas y políticas de control para el acceso a los
servicios invocados por el demonio inetd y que hagan uso de
los TCP Wrappers como mecanismo de control: qué clientes van
a tener acceso y a cuáles servicios.
ü Definir las reglas y políticas de control para la negación a los
servicios invocados por el demonio inetd y que hagan uso de
los TCP Wrappers como mecanismo de control: qué servicios no
pueden ser accedidos por cuáles clientes.
ü Consultar los registros almacenados de acceso y negaciones a
servicios de toda conexión realizada y en la cual se ha visto
involucrado el demonio de los TCP Wrappers, el tpcd.
Dentro de la categoría oculta tenemos:
ü Registrar los servicios protegidos en el archivo de configuración
del demonio inetd (/etc/inetd.conf).
ü Registrar las políticas y reglas de acceso a los servicios
protegidos por el demonio tcpd en el archivo de control de
acceso (/etc/hosts.allow).
ü Registrar las políticas y reglas para la negación a los servicios
protegidos por el demonio tcpd en el archivo de control de
Asegurando servicios de red utilizando TCP Wrappers en Linux.
50
negaciones (/etc/hosts.deny).
ü Tomar y dar formato entendible a la información almacenada en
los archivos de registro de bitácoras (/var/log/secure).
Una vez definidas las funciones del sistema, se deben especificar los
atributos del mismo, quienes representan las características o dimensiones
del sistema y aplicación en sí. Entre los atributos definidos se destacan los
siguientes:
Facilidad de uso: la aplicación resultante debe requerir un mínimo
conocimiento de la funcionalidad y configuración de los TCP Wrappers. Dado
que el usuario final para esta herramienta es el administrador del sistema
operativo, quien en teoría debiera conocer todas las bondades de sistema
que administra y no basa su labor en herramientas gráficas sino que conoce y
entiende cómo realizar las tareas en un ambiente tipo consola o manejando y
editando directamente los archivos de configuración de los diferentes
servicios que se prestan, se cumple el requisito único y necesario para la
utilización de la aplicación. La herramienta gráfica final realiza sus procesos
internos de forma transparente para el usuario e implementa mecanismos de
ayuda que realmente cumplen con su función y que sirvan de complemento
al conocimiento que posee el usuario del mecanismo de seguridad TCP
Wrappers.
Interfaz: como toda aplicación actual, la herramienta gráfica de
configuración de los TCP Wrappers implementa ventanas que hacen uso de
formas para la recolección de información necesaria por parte del usuario
(servicios, clientes, comandos, entre otros), acompañadas de botones
Asegurando servicios de red utilizando TCP Wrappers en Linux.
51
quienes realizan las funciones pertinentes y cuadros de diálogo que muestran
y guían al usuario con información que el sistema maneja. Además, establece
un mecanismo de navegación sencilla y fácil intuir haciendo uso de
dispositivos tales como el teclado y ratón, orientada a un ambiente y estilo
web, bajo la utilización de un navegador de internet. Esto contribuye a
complementar la facilidad de uso del sistema.
Plataforma: todas las distribuciones Linux existentes el mercado (por
excelencia Caldera OpenLinux) y que hagan uso de las interfaces gráficas
KDE y GNOME (comunes para todas las distribuciones).
Cabe destacar que la herramienta gráfica útil para la administración de
los TCP Wrappers debe ser configurable tanto localmente (en la misma
computadora en la que se encuentra instalada) como a distancia (otra
computadora distinta que se conecte a la máquina que tenga instalada la
aplicación). Para el segundo caso se hace uso de una aplicación a distancia
ya existente y denominada webmin, la cual se encarga de administrar varios
tipos de servicios a distancia a través del uso de un navegador web y el
establecimiento de una conexión por un puerto específico (actualmente el
número de puerto es 10000) y que es atendida por su respectivo demonio.
Este programa permite la adición de módulos que configuren servicios que
aún no han sido incluidos en su distribución. Un módulo para la configuración
de los TCP Wrappers se incluye dentro de esta aplicación.
Como punto conclusivo y no menos esencial de esta fase se tiene la
definición de los casos de uso en los que se describen la secuencia de
eventos de un agente externo que hace uso del sistema para completar un
proceso. Una persona que interactúe con el sistema desde el exterior y que
Asegurando servicios de red utilizando TCP Wrappers en Linux.
52
desea intercambiar información con el sistema es considerada un agente
externo.
Dentro de este proyecto se ha considerado un solo actor: el
administrador del sistema TCP Wrappers, quien no necesariamente debe ser
el administrador del sistema operativo. Este ente es el que se encarga de
establecer las políticas de control en cuanto a prestaciones de servicios se
refiere, definir las reglas que ha de manejar el mecanismo TCP Wrappers
para cumplir con las políticas establecidas y tomar las decisiones respectivas,
sustentadas por la consulta y revisión de los registros almacenados de acceso
y negaciones a servicios, al momento de ocurrir algún tipo de eventualidad.
Para este proyecto se han determinado los siguientes casos de uso:
Caso de uso: Proteger servicio
Actor: Administrador
Propósito: Indicar al demonio inetd que el servicio seleccionado es
protegido por el demonio de los tcpd.
Descripción: El administrador indica al sistema el servicio, invocado por el
demonio inetd, que desea proteger a través del uso del
demonio de los tcpd.
Tabla 6.- Caso de uso proteger servicio.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
53
Tabla 7.- Caso de uso definir política de control de acceso a servicios.
Caso de uso: Configurar el control de acceso a los servicios
Actor: Administrador
Propósito: Registrar la regla que ha de ser colocada en los archivos
involucrados en el control del acceso a los servicios.
Descripción: El administrador especifica las reglas de control a ser usadas por
el mecanismo TCP Wrappers para el acceso y negación de los
servicios, definiendo qué clientes tienen acceso a cuáles servicios
y qué servicios serán negados a cuáles clientes.
Tabla 8.- Caso de uso configurar el control de acceso a servicios.
Esta fase, en conclusión, tiene por objeto mostrar una descripción
preliminar del sistema, logrando aclarar ciertas dudas que se presentan al
respecto en cuanto a la especificación de requerimientos se refiere. La
planeación y elaboración proporcionan una ventana con vista a las fases que
realmente dan inicio al ciclo de desarrollo de un sistema. Con ella se da paso
a la fase de análisis en la cual se investigan a fondo los problemas en los
cuales se ve involucrado el sistema.
Caso de uso: Definir la política de control de acceso a servicios
Administrador
Propósito: Establecer la modalidad del comportamiento del
mecanismo de seguridad TCP Wrappers (totalmente
permisivo o negativo)
Descripción: El administrador especifica la política por defecto que ha de
satisfacer el mecanismo de control de servicios TCP
Wrappers.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
54
II.2 Fase de análisis
La fase de análisis resulta ser una de las etapas primordiales dentro
del patrón de metodología UML, ya que en ella se define el dominio del
problema en el cual se asienta el sistema a desarrollar. Uno de los modelos
que ayuda en la consecución de los objetivos que persigue esta fase es el
modelo conceptual, el cual explica los conceptos significativos en un dominio
del problema.
Según la metodología UML el modelo conceptual representa un grupo
de diagramas de estructura estática donde no se define ninguna operación.
Este modelo puede mostrar:
ü Conceptos: idea, cosa u objeto.
ü Asociaciones: relación entre dos conceptos que indica alguna
conexión significativa e interesante entre ellos.
ü Atributos: valor lógico de un dato de un objeto. Son
considerados atributos dentro de un modelo conceptual aquellos
en que los requerimientos indican o conllevan la necesidad de
recordar información.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
55
INTERFAZ
tipomodo
ADMINISTRADOR
idnombre
SERVICIO
nombreprotocolodemonio
POLÍTICA
tipo
REGLA
demonioclientecomando
ARCHIVO DECONTROL
nombreruta
Es usada por1
1
Protege1
*
Es establecida por1
*
Define *
*
*Es establecida por 1
Se registra en
*
*Es manejado por
*
1
Figura 13.- Modelo conceptual
Al definir el modelo conceptual se tiene una aproximación al dominio
que se intenta entender. Un buen modelo conceptual capta las abstracciones
esenciales y la información indispensable para comprender el dominio dentro
del contexto de los requerimientos actuales; además facilita el conocimiento
del dominio: sus conceptos, su terminología y sus relaciones.
Otro modelo que se emplea en la fase de análisis de la metodología
UML es el diagrama de la secuencia del sistema el cual muestra gráficamente
los eventos que fluyen de los actores al sistema. Este modelo forma parte de
la investigación para conocer el sistema y su creación depende de la
formulación previa de los casos de uso (especificados en la fase de
planeación y elaboración).
Asegurando servicios de red utilizando TCP Wrappers en Linux.
56
Para este sistema, y como se ha definido en la fase de planeación y
elaboración a la hora de especificar los casos de uso, se ha determinado la
participación de un solo actor, denominado administrador del sistema o
administrador de los TCP Wrappers. Esta persona es la encargada de hacer
uso y manipular todas las operaciones que ofrece el sistema con respecto a la
configuración de los TCP Wrappers; de allí que los diagramas de la secuencia
del sistema centren su atención en los eventos por él realizados con la
aplicación.
En este proyecto se han definido los siguientes diagramas de
secuencia:
Caso de uso: Proteger Servicio
Administrador
:SISTEMA
seleccionar_servicio(nombre_servicio)
wrap_servicio( )
Figura 14.- Diagrama de secuencia del sistema para el caso de uso proteger servicio.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
57
Caso de uso: Definir polí tica de control de acceso a servicios
Administrador
:SISTEMA
seleccionar_política_control ( )
activar_política ( )
Figura 15.- Diagrama de secuencia del sistema para el caso de uso definir política
Caso de uso: Configurar el control de acceso a los servicios
Administrador
:SISTEMA
seleccionar_servicio (nombre_servicio)
especificar_clientes ( )
especificar_comandos ( )
activar_regla ( )
Figura 16.- Diagrama de secuencia del sistema para el caso de uso configuración de reglas.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
58
Como paso sucesivo dentro de la fase de análisis se tiene la definición
de los denominados contratos, quienes ayudan a definir el comportamiento
del sistema; describen el efecto que sobre el sistema tienen las operaciones.
Un contrato es un documento que describe lo que una operación se propone
lograr haciendo énfasis en lo que sucederá y no en el cómo se conseguirá.
Estos documentos basan su punto de fuerza en dos estipulaciones: las
precondiciones, que son las suposiciones acerca del estado del sistema antes
de ejecutar la operación, y las poscondiciones, que estipulan el estado del
sistema después de la operación.
Para este sistema se han definido los siguientes contratos:
Tabla 9.- Contrato seleccionar servicio.
Nombre: wrapp_servicio.
Responsabilidades: Proteger el servicio haciendo uso de los TCP Wrappers.
Tipo: Sistema.
Precondiciones: Conocer los servicios invocados por el demonio inetd.
Poscondiciones: Servicio protegido por los TCP Wrappers.
Tabla 10.- Contrato wrapp servicio.
Nombre: seleccionar_servicio.
Responsabilidades: Capturar el nombre del servicio seleccionado y
desplegar sus características.
Tipo: Sistema.
Precondiciones:
Poscondiciones: Conocer el servicio a manipular.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
59
Nombre: seleccionar_política_control
Responsabilidades: Establecer la política de seguridad con la cual se regirá el
comportamiento del mecanismo de control de los TCP
Wrappers.
Tipo: Sistema.
Precondiciones:
Poscondiciones: Adoptar un comportamiento a seguir por el mecanismo de
control de los TCP Wrappers.
Tabla 11.- Contrato seleccionar política control.
Nombre: activar_política_control
Responsabilidades: Fijar el mecanismo de control del sistema TCP Wrappers
en base a la política seleccionada.
Tipo: Sistema.
Precondiciones: Haber seleccionado la política a regir por el sistema.
Poscondiciones: Controlar los servicios en base a la política establecida.
Tabla 12.- Contrato activar política de control.
Nombre: especificar_cliente
Responsabilidades: Definir los clientes que han de ser involucrados en la
regla a estipular.
Tipo: Interfaz.
Precondiciones:
Poscondiciones: Determina los clientes que van a ser controlados por los
TCP Wrappers.
Tabla 13.- Contrato especificar cliente.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
60
Tabla 14.- Contrato especificar comandos.
Nombre: activar_regla
Responsabilidades: Registrar la regla estipulada en el archivo de control
correspondiente.
Tipo: Sistema.
Precondiciones: Haber cumplido con la sintaxis requerida para la definición
de una regla (lista demonios : cliente obligatorio, :
comandos opcionales), demonio : cliente : opc. comando.
Poscondiciones: Tomar en consideración la nueva regla establecida para la
determinación de los siguientes controles.
Tabla 15.- Contrato activar regla.
En la fase de análisis del desarrollo de sistemas se da prioridad al
conocimiento de los requerimientos, los conceptos y las operaciones
relacionadas con el sistema. Una vez culminada esta fase, es posible pasar a
la fase de diseño, en la cual se debe lograr establecer una solución lógica
fundada en el paradigma orientado a objetos.
Nombre: especificar_comandos
Responsabilidades: Definir los comandos que han de ser ejecutados si una
solicitud de servicio cumple con una de las reglas
definidas y registradas en los archivos de control.
Tipo: Interfaz.
Precondiciones:
Poscondiciones: Determina los comandos que han de ser registrados en la
regla correspondiente.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
61
II.3 Fase de diseño
Esta fase tiene como objetivo establecer una solución lógica al
problema estudiado y presentado en la fase de análisis. Su esencia es la
elaboración de los denominados diagramas de interacción que muestran
gráficamente cómo los objetos se comunicarán entre ellos a fin de cumplir
con los requerimientos. Los diagramas de interacción se encuentran
compuestos por:
ü Diagramas de colaboración: describen las interacciones entre
los objetos en un formato de grafo o red.
ü Diagramas de secuencia: describen las interacciones entre
los objetos en una especie de formato de cerca o muro.
Ambos tipos de diagramas visualizan la misma información,
únicamente que la representan, gráficamente hablando, de forma distinta.
Para efectos de este proyecto, se ha convenido la implementación de los
diagramas de colaboración debido a su excepcional expresividad y a su
capacidad de comunicar más información contextual.
Como diagramas de colaboración se han definidos los siguientes:
Asegurando servicios de red utilizando TCP Wrappers en Linux.
62
:Política
:Servicio
definir ( )
proteger ( )
:Regladefinir ( )
:Interfaz
configurar ( ):Administrador
iniciar ( )
Figura 17.- Diagrama de interacción: administrador – sistema
:Interfaz
configurar ( ) :Administrador
iniciar ( )
:Archivo de control
wrapp_servicio ( )
seleccionar_servicio ( ):Servicio
Figura 18.- Diagrama de interacción: protección de los servicios con TCP Wrappers.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
63
:Interfaz
configurar ( ) :Administrador
iniciar ( )
:Archivo de control
activar_política_control ( )
seleccionar_política_control ( ):Política
Figura 19.- Diagrama de interacción: definición de las políticas de control.
:Interfaz
configurar ( ):Administrador
iniciar ( )
:Archivo de control
activar_regla ( )especificar_cliente ( )
:Reglaseleccionar_servicio ( )
especificar_comandos ( )
Figura 20.- Diagrama de interacción: definición de las reglas de control.
Una vez definidos los diagramas de interacción se puede identificar la
especificación necesaria para proveer la solución lógica a ser desarrollada en
software. Toda información obtenida de los diagramas de interacción, unida a
la que se encuentra reflejada en la definición del modelo conceptual, forman,
en conjunto, el denominado diagrama de clases de diseño que describe
gráficamente las especificaciones de las clases de software y de las interfaces
en una aplicación.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
64
INTERFAZ
tipomodo
ADMINISTRADOR
idnombre
SERVICIO
nombreprotocolodemonio
POLÍTICA
tipo
REGLA
demonioclientecomando
ARCHIVO DE CONTROL
nombreruta
Es usada por1
1
Protege
1
*
Es establecida por
1
*
Define **
*
Es establecida por 1
Se registra en
*
*Es manejado por
*
1
seleccionar_servicio( )especificar_cliente( )especificar_comandos ( )
activar_regla( )activar_política_control ( )
seleccionar_política_control( )
iniciar( ) configurar ( )
seleccionar_servicio ( )
wrapp_servicio ( )
Figura 21.- Diagrama de diseño de clases
Concluida la fase de diseño, especificando sus respectivos diagramas,
se obtienen suficientes detalles como para proceder a generar el código
fuente con el que se ha de regir la programación del software o aplicación
resultante, encargada de realizar las operaciones necesarias para establecer
el mecanismo de interfaz gráfica para la configuración de los TCP Wrappers.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
65
II.4 Fase de construcción
Esta fase consiste en traducir toda la información definida y
especificada en las etapas previas a un producto final encargado de cumplir
con los requerimientos, estipulaciones y operaciones establecidas que ha de
realizar el sistema. Su esencia es la selección de una herramienta o lenguaje
de programación que ayude y sea útil en programar las clases, interfaces y
funciones que en conjunto conforman la aplicación que ha de configurar de
forma gráfica el mecanismo de seguridad de los TCP Wrappers.
En el caso de este proyecto, existe gran variedad de aplicaciones de
desarrollo para seleccionar la herramienta de programación, pero debido,
precisamente, a que la aplicación debe ser adaptable para los entornos
gráfico de Linux (KDE y GNOME) y el sistema de administración a distancia
(webmin), esta lista se ve reducida a las recomendaciones que ofrecen
estos ambientes para así establecer y mantener consistencia con ellos y no
incurrir en procesos de posible adaptación de los resultados si no se siguen
los patrones establecidos.
Gran parte de la información correspondiente a esta fase se ve
reflejada en el capítulo referente al desarrollo del proyecto en si, donde se
establecen y se explican en detalle los pasos que se siguieron para la
realización de la aplicación y el cumplimiento de los objetivos planteados en
este trabajo.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
66
III. DESARROLLO
En esta sección se explica el proceso de construcción de ambas
aplicaciones: el Kwrapper (manejo de TCP Wrappers de forma local) y el
módulo de TCP Wrappers para webmin (administración a distancia), a pesar
de que son dos aplicaciones con un mismo fin común, sus entornos son muy
diferentes lo que nos llevó a utilizar por conveniencia, herramientas y
métodos de programación diferentes. A continuación se explica el desarrollo
de cada una de las aplicaciones.
III.1 Desarrollo de Kwrapper
Kwrapper es el nombre de la aplicación que va a configurar y
manejar los TCP Wrappers bajo los entornos gráficos KDE y GNOME. Para la
realización de la aplicación fue necesario, en principio, conocer cómo se
configuran y se editan los archivos de control de acceso para que el proceso
de interpretación por parte del demonio de los TCP Wrappers, el tcpd, se
realice de forma correcta, y luego encontrar una herramienta de
programación que le proporcione a la aplicación la capacidad de poder ser
utilizada en los entornos gráficos KDE y GNOME.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
67
III.1.1 Herramientas de programación utilizadas
Se eligió como herramienta de programación Python 1.5.2, lenguaje
con licencia GPL, que viene instalado y configurado en la mayoría de las
distribuciones Linux. La plataforma Linux empleada es la distribución
OpenLinux eDesktop 2.4.
El lenguaje de programación Python ofrece las siguientes
características:
ü Capacidad para el manejo de comandos y archivos del sistema.
ü Orientado a objetos.
ü Facilidad en el manejo de librerías de objetos gráficos como lo
es GTK+.
ü Documentación en línea y un alto soporte en listas de correo.
ü Es un lenguaje que extiende sus capacidades en el área de
redes y la web, por medio de librerías que posee el sistema
operativo Linux.
Luego de instalar la herramienta de programación Python y las
librerías de objetos de GTK+, fue necesario, para que la herramienta de
programación empleará las librerías de objetos de imágenes GTK+, instalar la
aplicación pygtk 0.6 que contiene los módulos con las definiciones de los
objetos gráficos GTK+, con sus respectivos atributos, para ser utilizados por
Asegurando servicios de red utilizando TCP Wrappers en Linux.
68
el lenguaje de programación Python 1.5.2.
El motivo para utilizar estas herramientas de programación tiene una
relación muy estrecha con el hecho de las compatibilidades entre los dos
entornos gráficos para los que está diseñado el Kwrapper.
Cabe destacar en estas herramientas de programación la
documentación y la ayuda constante a través de listas de soporte al
momento de programar.
El siguiente paso para el desarrollo de la aplicación Kwrapper, fue el
diseño de las pantallas que van a funcionar de interfaz, facilitando al usuario
el agregar, borrar y editar reglas de control de acceso, manejadas por los
TCP Wrappers.
III.1.2 Capacidades del Kwrapper
La aplicación Kwrapper tiene las siguientes capacidades:
ü Listar los servicios activos y manejados por el inetd, además
tiene la capacidad de proteger y desproteger un servicio de red
con los TCP Wrappers con sólo hacer un click.
ü Mostrar los servicios de red protegidos por los TCP Wrappers, y
poder revisar cuáles son los clientes que tienen reglas asociadas
a este servicio.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
69
ü Manejo de las políticas de acceso: se puede dar acceso de todos
los servicios a todo el mundo y negar el acceso; así como
también se tiene la capacidad de realizar una configuración
manual.
ü Se puede crear, borrar y editar las reglas de control de acceso,
así como consultar los registros de logs y archivos que
intervienen en la definición de reglas.
ü Manejo de los “wildcards”, comandos y sintaxis de los mismos al
momento de generar reglas de control de acceso.
ü Verificación de la identidad del usuario que controle la
aplicación Kwrapper, ya que la misma, por ser un mecanismo
de seguridad y modificar archivos del sistema, únicamente
puede ser manejada por root.
III.1.3 Rutinas globales
Se identificaron tres rutinas principales que han sido definidas en
forma global y que van a componer la aplicación Kwrapper. Luego de
conocer las metas de esta aplicación gráfica descritas en la fase de
planeación y elaboración, se definieron las siguientes rutinas:
1. Se definió la rutina de nombre iniciar_inetd(): la misma recorre
el archivo /etc/inetd.conf y chequea los servicios activos a
través de la revisión y manipulación de dicho archivo por medio
de expresiones regulares. Esta rutina también ejecuta la
Asegurando servicios de red utilizando TCP Wrappers en Linux.
70
inicialización del demonio inetd para tomar los nuevos cambios
en el caso de alguna modificación del archivo (únicamente se
modifica este archivo al momento de proteger o desproteger un
servicio con el demonio tcpd).
2. La siguiente rutina se ha denominado iniciar_tcpd: ésta tiene
como función principal listar los servicios de red que están
protegidos por los TCP Wrappers.
3. El último procedimiento global, denominado principal() es el
que da inicio al despliegue de la pantalla principal y tiene como
función base la navegación de las pantallas que se muestran al
momento de seleccionar cualquier opción dentro del menú
principal. El programa se inicia haciendo una llamada a esta
función.
La utilización de estas rutinas son de gran ayuda, ya que tiene una
participación importante al momento de mantener actualizada la información
de servicios de red activos por el inetd y protegidos por los TCP Wrappers a
la vista del usuario que este ejecutando la aplicación.
III.1.4 Módulos específicos.
Basados en los casos de estudio, los módulos de programación que le
ofrecen al usuario la capacidad de configurar los TCP Wrappers, se tienen:
Asegurando servicios de red utilizando TCP Wrappers en Linux.
71
1. El módulo que maneja el despliegue de la pantalla donde la
función base es la de agregar, borrar y editar una regla, sea de
acceso o de negación está recibe como parámetro el archivo el
cual se va a modificar(/etc/hosts.allow, /etc/hosts.deny). Aquí
se muestran y se controlan los objetos gráficos de GTK+ que
hacen que la interfaz sea de fácil uso al momento de crear,
modificar y borrar una regla.
2. El segundo módulo que tiene gran importancia es el que se
encarga de revisar en el archivo /var/log/secure depurando el
mismo para mostrar las conexiones que se han realizado en
forma sencilla y entendible a la vista del usuario, ofreciendo
opciones para indexar la búsqueda por servicio, por fecha o por
clientes.
3. Otro módulo de la aplicación es el de listar las reglas en los
archivos de control de acceso, donde se hacen traducciones al
español de los “wildcards” que se encuentran definidos dentro
de la cada regla definida.
4. El módulo que depura, y lista los servicios de red activados por
el inetd y protegidos por el tcpd. El mismo utiliza las rutinas
globales definidas anteriormente para el despliegue en forma
clara de los servicios de red que el sistema tiene configurado.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
72
III.1.5 Dificultades encontradas
ü El manejo de los archivos resulta complicado al momento de
agregar una regla, ya que la posición de la misma dentro del
archivo es de gran importancia al momento de establecer las
prioridades en las restricciones. También el manejo de otros
archivos como los son: /etc/inetd.conf , ya que son archivos del
sistema es imprescindible mantener ciertas pautas para evitar el
borrado o daño de los mismos.
ü La utilización de ciertos objetos gráficos GTK+ [G00], donde los
atributos del objeto no ofrecen la información requerida para la
ejecución de un procedimiento, tal como es el caso del objeto
que despliega la lista de opciones en los “wildcards” en la
ventana donde se agrega una regla. La información mostrada
en la lista no es guardada a menos que se establezca una
etiqueta de la opción y se guarde internamente en una lista de
pares con la posición y el nombre de la opción. Esta lista se
encuentra definida dentro del procedimiento.
Es importante resaltar que estas rutinas y módulos se encuentran
definidas dentro de un solo archivo denominado kwrapp.py, el cual necesita
importar librerías del sistema para el manejo de comandos shell y librerías
GTK+ para mostrar las ventanas, botones y los diferentes objetos gráficos
que se encargan de facilitar el manejo y configuración del control de acceso
por medio de los TCP Wrappers.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
73
Para poder ejecutar este programa se generó un guión de ejecución
del mismo, donde además de ejecutar la aplicación Kwrapper, instale los
componentes necesarios para que el Kwrapper funcione de manera correcta
y sin inconvenientes en cualquiera de los entornos gráficos (KDE y GNOME).
III.2 Desarrollo del módulo de TCP Wrappers para Webmin
El sistema de administración a distancia denominado webmin permite
agregar nuevos módulos a su estructura que se encarguen de realizar
funciones específicas referentes al sistema operativo con el que se esté
trabajando y que son soportados por esta aplicación. Parte de los objetivos
propuestos pretenden el desarrollo de un módulo que permita la
administración y configuración a distancia de los TCP Wrappers, por lo que el
uso del webmin representa la solución necesaria para cumplir con lo
planteado en esta propuesta.
Para desarrollar un módulo en este tipo de sistema, hay que seguir
cierto tipo de especificaciones y recomendaciones por parte de los
desarrolladores originales de webmin [NW00]. La creación del módulo, para
que webmin lo adoptara en su estructura, no constituyó problema alguno,
ya que la documentación que se obtuvo resultó ser entendible y de gran
ayuda en la consecución de este aspecto.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
74
III.2.1 Herramientas de programación utilizadas
Otro de los puntos importantes para desarrollar el módulo, es definir
el tipo de lenguaje a ser utilizado para programar la interfaz y funciones que
han de cumplir con los requerimientos estipulados y que ha de conseguir la
herramienta de configuración de los TCP Wrappers. Dado que webmin se
encuentra programado enteramente en lenguaje PERL, resulta ser el más
apto y recomendado para la programación de los módulos, aunque esto no
representa una limitación para la selección de la herramienta de desarrollo.
También hay que tomar en consideración que la aplicación webmin se
ejecuta a través de una ventana de navegador de páginas web (Netscape y
Microsoft Explorer), por lo tanto se hace imprescindible, para el desarrollo y
programación, un conocimiento exhaustivo del lenguaje HTML.
A efectos de la programación del módulo de TCP Wrappers para
webmin, se ha seleccionado, como herramienta de desarrollo, el lenguaje de
programación PERL para así mantener la estructura y consistencia con el
sistema de administración, obteniendo grandes ventajas, ya que en este caso
se puede tomar provecho de las librerías ya desarrolladas para webmin y
que pueden ser reutilizadas por los diferentes módulos existentes.
III.2.2 Integración del módulo a la estructura de Webmin
Una vez definido el lenguaje de programación, hay que seguir una
serie de pasos para poder incluir el módulo de TCP Wrappers en la estructura
ya establecida y existente de webmin. Entre estos pasos se tienen los
siguientes:
Asegurando servicios de red utilizando TCP Wrappers en Linux.
75
Determinar el nombre del módulo: se establece un nombre al
módulo a crear con el cual la aplicación webmin hará referencia y
establecerá los enlaces a éste. Dado que el módulo en cuestión implica la
configuración de los TCP Wrappers, el nombre acordado y definido es el de
tcpw.
Creación de directorios: se crean los directorios donde serán
almacenados los programas que definen las funciones y establecen la interfaz
con el usuario administrado y los archivos de configuración respectivos de los
cuales hará uso el módulo. Estos directorios deben estar ubicado dentro de la
ruta base en la cual se encuentra instalado webmin (/etc/webmin/ y
/usr/libexec/webmin/). La carpeta debe llevar el mismo nombre del módulo
estipulado en el paso anterior. Los directorios quedan de la siguiente forma:
ü /etc/webmin/tcpw/ -> en él se almacenan los archivos de
configuración de los cuales hará uso el módulo de TCP
Wrappers.
ü /usr/libexec/webmin/tcpw/ -> en él se almacenan los
programas encargados de realizar las funciones y establecer la
interfaz de usuario que ha de mostrar el módulo de TCP
Wrappers.
Creación del archivo de información: se crea un archivo con
nombre “module.info” dentro del directorio /usr/libexec/webmin/ el cual
contiene la siguiente información:
Asegurando servicios de red utilizando TCP Wrappers en Linux.
76
NAME = tcpw -> nombre con que el webmin establecerá los enlaces
para la ejecución del módulo.
DESC = TCP Wrappers -> nombre que aparece bajo el logo de los
TCP Wrappers en el menú de webmin.
OP.SUPPORT = OpenLinux Mandrake Suse ... -> listado de los
sistemas operativos soportados por el módulo TCP Wrappers.
DEPENDS = -> el módulo TCP Wrappers no depende de ningún otro
módulo incluido en webmin.
CATEGORY = servers -> el módulo de TCP Wrappers se ubica en el
menú de servicios de webmin.
Creación de la imagen con el logotipo del módulo: esta imagen
es la que aparece en el menú de webmin donde se encuentra ubicado el
módulo y debe ser almacenada en el directorio /usr/libexec/tcpw/images/.
También serán almacenados en esta carpeta cualquier otro tipo de imagen de
la cual hará uso el módulo.
Creación del archivo “index.cgi”: este archivo contiene la
información principal que se le muestra al usuario administrador al momento
de acceder el módulo de los TCP Wrappers.
Notificar a webmin de la existencia del módulo: editar el archivo
/etc/webmin/webmin.acl y colocar el nombre de tcpw para que la aplicación
webmin soporte el nuevo módulo creado.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
77
Una vez conseguidos estos pasos se tiene prácticamente listo el
funcionamiento del módulo de TCP Wrappers en la aplicación webmin;
faltaría por programar las funciones que ha de realizar el módulo para
proceder con la configuración de los TCP Wrappers.
III.2.3 Características del módulo de TCP Wrappers
El módulo de los TCP Wrappers basa su concepción en la información
bibliográfica a la que se ha recurrido para entender el funcionamiento y
configuración de los TCP Wrappers como sistema de seguridad y control ya
existente, y en la implementación de un método orientado a objetos como
mecanismo a seguir durante todo el ciclo de vida del proyecto. De este
estudio, se obtuvieron resultados muy importantes y útiles para poder
acoplar el sistema de TCP Wrappers a una aplicación como webmin, y así
establecer los requerimientos, las operaciones y pantallas que ha de regir la
programación del módulo.
El módulo se encuentra constituido por las siguientes características:
Operaciones y funciones: el módulo permite la protección a
aquellos servicios que son invocados por el demonio inetd, mediante el uso
del mecanismo de los TCP Wrappers, realizando los ajustes necesarios al
archivo de configuración inetd.conf. También permite el control y manejo de
los archivos donde se definen las reglas de acceso (hosts.allow y hosts.deny),
permitiendo al administrador definir nuevas reglas, modificar y eliminar las ya
existentes.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
78
Pantalla: se encuentran constituidas por el uso de tablas que
muestran la información con la cual los TCP Wrappers basan su mecanismo
de decisión de acciones, y formularios, útiles para recolectar los datos e
información que el usuario desea introducir o modificar a efectos de
determinar el comportamiento de los TCP Wrappers.
Idioma: gracias al alcance que tiene webmin, el módulo a
desarrollar puede soportar una gran cantidad de idiomas. El módulo de los
TCP Wrappers soporta como lenguas base el español, inglés e italiano.
Hay que recalcar que debido a que webmin es una aplicación
destinada para el uso a distancia, la programación de los módulos debe
realizarse de manera bien estructurada y no deben incluir cálculos y
operaciones consideradas fuertes y/o muy pesadas que afecten el
rendimiento de la aplicación, ya que este efecto pudiera traer cambios
contraproducentes en las actividades a realizar. En este caso, se ha
convenido en definir archivos cuya programación implica la realización de
actividades muy puntuales en el proceso de configuración de los TCP
Wrappers.
III.2.4 Páginas especificas
El módulo de TCP Wrappers se encuentra compuesto por tres páginas
principales. Entre éstas tenemos:
Asegurando servicios de red utilizando TCP Wrappers en Linux.
79
ü Página principal: en ella se muestra información relevante,
representada en tablas, de la cual hace uso el mecanismo de los
TCP Wrappers. Se destacan: los servicios invocados a través del
demonio inetd; las reglas definidas para el acceso a los
servicios y las reglas definidas para la negación de los mismos.
ü Agregar y editar reglas: formulario útil para la captura de datos
por parte del administrador, necesarios para la definición y
modificación de las reglas en los archivos de control. También
en él se da la posibilidad de poder eliminar las reglas ya
registradas.
ü Agregar y editar comandos: formulario que da la posibilidad de
agregar y editar la opción de los comandos provenientes regla
que se ha de definir o que se ha de editar.
III.2.5 Dificultades encontradas.
El proceso de integración del módulo a webmin no resultó ser tan
complicado como se creía en un principio. La información referente a este
proceso resultó ser bastante útil y a su vez entendible para un usuario con
conocimientos básicos en Linux.
En cuanto a los lenguajes de programación, hubo que dedicar gran
tiempo en el aprendizaje de la herramienta PERL, ya que no se tenía un
conocimiento previo que sirviera de base para comenzar a trabajar de buenas
a primera en la realización del módulo.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
80
Otro de los problemas encontrados, referente a PERL y programación
en HTML, es que todo programa generado debe ser mostrado en estilo de
página web, la cual, una vez enviada para ser desplegada en pantalla, la
información que en ella aparece no puede ser modificada de forma dinámica,
a menos que se haga uso de la programación en Java o JavaScript, caso no
recomendado por los desarrolladores de webmin. También la transferencia
de datos y parámetros de una página a otra resulta ser un aspecto delicado
en este tipo de programación.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
81
IV. RESULTADOS
Concluidas las fases del proceso de desarrollo, se obtienen como
producto final dos aplicaciones que cumplen la misma función, pero que se
ejecutan y manejan en ambientes distintos:
ü Kwrapper: aplicación única para la configuración de los TCP
Wrappers bajo las interfaces de Linux KDE y GNOME.
ü TCPW: módulo para la administración a distancia de los TCP
Wrappers integrado a la aplicación webmin.
Dado que ambas aplicaciones difieren una de otra, su proceso de
ejecución resulta ser diferente. La aplicación Kwrapper sólo puede ser
iniciada si se está ejecutando algún entorno gráfico que haga uso del servidor
X del sistema operativo Linux. La herramienta TCPW se ejecuta dentro de la
aplicación webmin como un módulo perteneciente a su estructura, por lo
tanto requiere de un navegador web que soporte tablas y formas.
Ahora bien, una vez iniciados los programas, se explicará a
continuación el funcionamiento de cada uno de ellos.
Funcionamiento del Kwrapper
Iniciado el Kwrapper, se muestra una pantalla principal con un menú
de opciones (véase figura 22).
Asegurando servicios de red utilizando TCP Wrappers en Linux.
82
Figura 22.- Menú principal del Kwrapper
Como opciones se tienen las siguientes:
ü Principal: permite mostrar los servicios activos y protegidos que
son invocados a través del demonio inetd. En él también se
puede establecer la política de acceso que ha de regir en el
mecanismo de los TCP Wrappers (véase figura 23).
Figura 23.- Listado de servicios manejados por el inetd.
ü Haciendo click en un servicio, sobre el valor expuesto en la
columna de nombre protegido, la aplicación automáticamente
protege o desprotege el servicio seleccionado.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
83
ü Reglas: permite mostrar las reglas definidas en el archivo de
acceso hosts.allow y negación hosts.deny.
Figura 24.- Pantalla de control de acceso.
ü En ambos, se muestran las reglas definidas en los archivos de
control respectivo, indicando las partes de servicio, cliente y
comandos. También se observan botones que cumplen
funciones respectivas: agregar, (permite la adición de nuevas
reglas) editar, (permite la edición de una de las reglas
seleccionadas) borrar, (elimina la regla seleccionada) y cancelar
(cierra la ventana sin efectuar algún tipo de cambio) (véase
figura 24).
ü Consultar: permite la revisión del archivo de bitácoras de
eventos del cual hace uso los TCP Wrappers mediante la
llamada al demonio syslogd.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
84
Funcionamiento del TCPW
Iniciado webmin, el módulo de TCP Wrappers se encuentra ubicado
bajo la etiqueta de servidores.
Figura 25.- Pantalla de servicios ofrecidos por webmin.
Haciendo click sobre el icono o el enlace del módulo, se accede a la
página principal de los TCP Wrappers (véase figura 25).
Asegurando servicios de red utilizando TCP Wrappers en Linux.
85
Figura 26.- Página principal de los TCP Wrappers en webmin.
En la figura 26 se muestra información útil de la cual hace uso el
mecanismo de los TCP Wrappers. Como primera instancia, se muestran los
servicios que son invocados a través del demonio inetd. Aquellos cuyo
nombre se encuentra en letra negrita, indica que el servicio está siendo
protegido por los TCP Wrappers, en caso contrario no. También se muestra el
tipo de protocolo que el servicio emplea para establecer la comunicación.
Cada nombre de servicio, representa un enlace a la página en la figura 27
que muestra las características de ese servicio, mostrando la opción de
protección bajo el mecanismo de los TCP Wrappers.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
86
Figura 27.- Detalles del servicio de red.
En segunda instancia de la página principal se muestran las reglas
definidas en el archivo hosts.allow. En ella se especifican, dentro de una
tabla, la parte del demonio, el cliente y por último los comandos, elementos
que en conjunto definen una regla.
En tercer lugar se evidencian las reglas definidas en el archivo
hosts.deny, cumpliendo con el mismo formato de la información definida
anteriormente.
Se puede observar en ambos casos que en las reglas definidas,
específicamente en la parte del servicio, éste se muestra en forma de enlace.
Esto indica que al hacer click en ellos, se da la posibilidad de editar dicha
regla. También podemos notar un enlace que indica la adición de nuevas
reglas. Ambos enlaces se dirigen a la misma página, en donde se muestra el
formulario de ingreso de una nueva regla; en caso de tratarse de una edición,
la página indica en el título que una regla se está editando y ésta aparecerá
en los campos de datos del formulario.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
87
Figura 28.- Página donde se añade una regla.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
88
Figura 29.- Página donde se modifica una regla.
En las figuras 28 y 29 se observa que, aparte el formulario para el
ingreso de datos, se vuelven a mostrar las reglas definidas, pero en este caso
se trata del archivo de control específico en el cuál se desea ingresar o editar
una regla. Existen también una serie de botones los cuales se indican a
continuación:
Asegurando servicios de red utilizando TCP Wrappers en Linux.
89
ü Save/Guardar: almacena la regla en el archivo de control.
ü Command/Comando: permite la adición de nuevos comandos
dentro de la definición de una regla.
ü Delete/Borrar: permite eliminar las reglas seleccionadas, ya
existentes en el archivo de control.
Como se puede observar y notar, las aplicaciones son independientes,
se ejecutan en ambientes diferentes pero ambas, prácticamente, realizan las
mismas funciones, que es la configuración de los TCP Wrappers, mediante el
uso de una interfaz gráfica.
Pruebas
Dado que el mecanismo de seguridad de los TCP Wrappers pretende
proteger y controlar los servicios de un host conectado en red (intranet e
Internet), las pruebas se realizaron empleando los siguientes recursos:
ü 3 computadores conectados en red: un computador que haga
de servidor de nombres (DNS), otro al cual se le van a proteger
los servicios mediante el uso de TCP Wrappers, y un tercero
que no pertenezca al dominio de esa red. Todos bajo el sistema
operativo OpenLinux eDesktop 2.4.
ü TCP Wrappers versión 7.6-4
Asegurando servicios de red utilizando TCP Wrappers en Linux.
90
Ahora bien, en la tabla a continuación se muestran en detalle las
características de cada uno de los computadores que intervienen en el
proceso de prueba:
N° Dirección
IP Nombre de Host Descripción
1 10.0.0.169 develpc.prisma.ofic .
• Computador a ser protegido por los
TCP Wrappers
• Registrado en el DNS
• No tiene instalado el demonio
identd
2 10.0.0.225 berzeker.prisma.ofic
• Servidor de DNS
• Registrado en el DN
• No tiene instalado el demonio
identd
3 10.0.0.21 samcorp.com
• Computador ajeno al dominio
• No registrado en el DNS
• Tiene instalado el demonio identd
Una vez especificados los elementos a usar, se define la estructura de
las pruebas a seguir. Los TCP Wrappers rigen sus decisiones en base a reglas
definidas en los archivos de control. Estas reglas pueden variar en cuanto a
complejidad se refiere, por lo tanto, se ha decidido establecer un patrón de
pruebas que a medida que avancen, incrementen el nivel de complejidad en
las reglas a definir, con el fin de entender y captar las opciones y ventajas
que ofrecen los TCP Wrappers en su estructura de configuración.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
91
Las pruebas varían según el siguiente patrón de complejidad:
ü Protección de servicios a un host: se protegen los servicios en
base a la especificación de una dirección IP o gama de
direcciones.
ü Protección de servicios por dominio: los servicios son protegidos
en base a la especificación de un dominio (este tipo de reglas
funcionan si se encuentra un servidor de DNS activo en la red).
ü Protección de servicios haciendo uso de “wildcards”: estas
opciones sirven para especificar, en la sintaxis de una regla, la
parte del cliente y requieren, para su perfecta ejecución, el uso
de un servidor de DNS y la ejecución del demonio identd en la
parte del cliente solicitante.
Definido el patrón de pruebas, a continuación se deben definir los
servicios que se han de involucrar en éstas, debido, precisamente, a la
naturaleza de los TCP Wrappers, que constituye la protección y control de los
servicios de red.
En este caso se ha convenido en utilizar servicios de uso frecuente y
muy común dentro de ambientes de redes de computadores como lo son
telnet y ftp.
A continuación se especifican las pruebas realizadas con sus
respectivas descripciones y resultados:
Asegurando servicios de red utilizando TCP Wrappers en Linux.
92
Prueba N° 1. Negación a hosts específicos
Parte A.
Se definieron las siguientes reglas en los archivos de control:
Archivos Reglas
hosts.allow
hosts.deny ALL: 10.0.0.21
En este caso se está especificando la negación de todos los servicios
desde el host que tenga definido la dirección IP 10.0.0.21, que, a los efectos
de esta prueba, se trata del computador N° 3, de nombre samcorp.com.
Los resultados obtenidos son los siguientes:
El computador N° 2 de nombre berzeker (IP 10.0.0.225) tiene acceso
a telnet (véase figura 30) .
Figura 30.- Resultado de ejecutar telnet desde la IP 10.0.0.225 5 en prueba 1-A.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
93
El computador N° 2 de nombre berzeker (IP 10.0.0.225) tiene acceso
al servicio ftp (véase figura 31).
Figura 31.- Resultado de ejecutar ftp desde la IP 10.0.0.225 en la prueba 1-A.
En la figura 32 el computador N° 3 de nombre samcorp (10.0.0.21) no
tiene acceso para el servicio telnet.
Figura 32.- Resultado de ejecutar telnet desde la IP 10.0.0.21 en la prueba 1-A.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
94
Figura 33.- Resultado de ejecutar ftp desde la IP 10.0.0.21 en la prueba 1-A.
En la figura 33 el computador N° 3 de nombre samcorp (IP 10.0.0.21)
no tiene acceso al servicio ftp.
Parte B.
Se definieron las siguientes reglas en los archivos de control:
Archivos Reglas
hosts.allow
hosts.deny ALL: 10.0.0.0/255.255.255.0
En este caso se está especificando la negación de todos los servicios a
todo host cuya dirección IP se ubique en la red 10.0.0.0 con máscara
255.255.255.0, que, a los efectos de esta prueba, se trata de los
computadores N° 2 y 3, de nombre berzeker.prisma.ofic. y samcorp.com
respectivamente.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
95
Los resultados obtenidos son los siguientes:
Figura 34.- Resultado de ejecutar telnet desde la IP 10.0.0.225 en la prueba 1-B.
Figura 35.- Resultado de ejecutar ftp desde la IP 10.0.0.225 en la prueba 1-B.
Figura 36.- Resultado de ejecutar telnet desde la IP 10.0.0.21 en la prueba 1-B
Asegurando servicios de red utilizando TCP Wrappers en Linux.
96
Figura 37.- Resultado de ejecutar ftp desde la IP 10.0.0.21 en la prueba 1-B.
Como se restringe el acceso al grupo de direcciones IP que se
encuentran en el rango 10.0.0.0 / 255.255.255.0, ninguna de las máquinas
que están siendo utilizadas para la prueba tienen acceso (véase figura 34,
35,36,37) .
Prueba N° 2 . Uso de comandos
Parte A.
Se definieron las siguientes reglas en los archivos de control:
Archivos Reglas
hosts.allow in.telnetd: .prisma.ofic: banners /etc/security/banners/allow
in.ftpd: .prisma.ofic: banners /etc/security/banners/allow
hosts.deny ALL: ALL: banners /etc/security/banners/deny
En este caso se está especificando la negación de todos los servicios a
aquellos host que no pertenezcan al dominio prisma.ofic. A los efectos de
esta prueba, el computador N° 3, de nombre samcorp.com, no tendrá acceso
a ningún servicio. Sin embargo, se le otorga acceso a los servicios de telnet y
ftp a los hosts que sí pertenecen al dominio, entre los cuales se encuentra el
Asegurando servicios de red utilizando TCP Wrappers en Linux.
97
computador N° 2 de nombre berzeker.prisma.ofic.
Como se puede observar, en este caso se hace uso del comando
“banners” que muestra un mensaje al momento de establecerse la conexión.
Se tiene un mensaje para el acceso al servicio y otro para la negación del
mismo. Ambos mensajes se muestran a continuación:
Figura 38.- Archivo /etc/secur ity/banners/allow/in.telnetd.
Figura 39.- Archivo /etc/security/banners /deny/in.telnetd.
En la figura 38 se muestra el archivo que contiene el mensaje que se
despliega al acceder al servicio telnet. Éste es almacenado en el directorio
/etc/security/banners/allow al cual hace referencia la regla de acceso definida
y para el servicio telnet al cual se le niega el acceso se le despliega el
mensaje que esta registrado en el archivo /etc/security/banners/deny (véase
figura 39).
Asegurando servicios de red utilizando TCP Wrappers en Linux.
98
Los resultados obtenidos son los siguientes:
Figura 40.- Resultado de ejecutar telnet desde la IP 10.0.0.225 en la prueba 2-A.
El computador N° 2 de nombre berzeker (IP 10.0.0.225) tiene acceso
a telnet. Se puede observar en la figura 40 el despliegue del mensaje donde
se muestra la dirección IP y el nombre de host del cliente solicitante. Este
mensaje es producto del uso del comando “banners”, proveniente de la regla
definida en el archivo hosts.allow.
Figura 41.- Resultado de ejecutar ftp desde la IP 10.0.0.225 en la prueba 2-A.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
99
El computador N° 2 de nombre berzeker (IP 10.0.0.225) tiene acceso
al servicio ftp. Se puede observar en la figura 41 un mensaje donde se
muestra la dirección IP y el nombre de host del cliente solicitante. Este
mensaje es producto del uso del comando “banners”, proveniente de la regla
definida en el archivo hosts.allow.
Figura 42.- Resultado de ejecutar telnet en la prueba 2-A, desde la IP 10.0.0.21.
Figura 43.- Resultado de ejecutar ftp en la prueba 2-A, desde la IP 10.0.0.21.
El computador N° 3 de nombre samcorp (IP 10.0.0.21) no tiene
acceso a los servicios telnet y ftp. Se puede observar en las figuras 42 y 43 el
despliegue de un mensaje donde se muestra la dirección IP y el nombre de
host del cliente solicitante. Este mensaje es producto del uso del comando
“banners”, proveniente de la regla definida en el archivo hosts.deny.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
100
Parte B.
Se definieron las siguientes reglas en los archivos de control:
Archivos Reglas
hosts.allow in.telnetd: .prisma.ofic: banners /etc/security/banners/allow
in.ftpd: .prisma.ofic: banners /etc/security/banners/allow
hosts.deny ALL: ALL: banners /etc/security/banners/deny \
spawn (/bin/echo “La maquina de nombre %u@%n con direccion
IP %a intento accesar el servicio %d.” /bin/mail –s “Intento de
conexión fallido” root)
Este caso resulta ser el mismo al presentado en la parte A, únicamente
que se agregó el comando “spawn” que se encarga de enviar un correo
electrónico al administrador del sistema notificando la negación de un servicio
a un cliente que no pertenece al dominio de red. Los resultados serán los
mismos a los mostrados anteriormente sólo que el administrador recibirá el
siguiente correo electrónico:
Figura 44.- Resultado de la ejecución del comando spawn enviando un email.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
101
En la figura 44 se muestra el correo enviado al administrador del
sistema que tiene los TCP Wrappers instalado y protegiendo los servicios. Se
puede observar las especificaciones de la máquina cliente solicitante (nombre
de usuario, nombre de host y dirección IP). El nombre de usuario proviene de
una llamada al demonio identd instalado en el cliente, el nombre de host es
desconocido precisamente porque éste no se encuentra definido en el
servidor DNS. También se muestra el nombre del demonio que atiende el
servicio, en cuyo caso parecerá in.telnetd si el servicio solicitado es telnet, e
in.ftpd si se trata del servicio ftp.
Prueba N° 3. Uso de los wildcards
Se realizó una única prueba en la cual se definieron las siguientes
reglas en los archivos de control:
Archivos Reglas
hosts.allow in.telnetd: UNKNOWN@KNOWN
in.ftpd: UNKNOWN@KNOWN
hosts.deny ALL: ALL: UNNOWN@UNKNOWN, KNOWN@UNKNOWN
En este caso se está especificando la negación de todos los servicios a
aquellos usuarios, conocidos y no conocidos de hosts que no pertenezcan a
dominios conocidos por el servidor DNS. Todos los hosts conocidos por el
servidor DNS tendrán acceso a los servicios telnet y ftp. A los efectos de esta
prueba, el computador N° 3, de nombre samcorp.com , no tendrá acceso a
ningún servicio. Sin embargo, se le otorga acceso a los servicios de telnet y
ftp a los hosts que sí pertenecen al dominio, entre los cuales se encuentra el
computador N° 2 de nombre berzeker.prisma.ofic.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
102
Los resultados que se muestran al aplicar esta prueba son los mismos
mostrados en la parte A de la primera prueba realizada.
Con la realización de estas pruebas lo que se persigue es mostrar la
forma de actuar de los TCP Wrappers y cómo se definen las reglas de filtrado
para el control de servicios, explicando cada uno de los elementos que la
componen. Para complementar esta fase, se muestran los resultados
obtenidos, con los cuales se visualizan los alcances que este mecanismo de
seguridad proporciona y de cuán simple es su aplicación e implementación
para la defensa y protección de los servicios que presta un sistema operativo
dentro de una ambiente de redes.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
103
CONCLUSIONES
Los servicios de red constituyen la esencia de todo ambiente basado
en la arquitectura cliente – servidor, por lo tanto resultan ser los activos que
todo hacker y/o cracker tiene en la mira a la hora de efectuar un ataque, y
que todo administrador de sistema debe proteger y salvaguardar con algún
mecanismo de seguridad.
Existen un gran número de herramientas de seguridad encargadas de
establecer algún tipo de mecanismo que contrarreste los ataques de personas
malintencionadas o que buscan violentar los sistemas simplemente por
hobby. Entre éstas podemos mencionar los Firewall , Ipchains, TCP Wrappers,
entre otros. Los TCP Wrappers se destacan de entre todos ellos,
precisamente por la función que cumple: proteger los servicios que presta un
host y que son invocados a través del demonio inetd, mediante la definición
de reglas que rigen el comportamiento y mecanismo de acción de este
sistema de seguridad.
Los TCP Wrappers representan una herramienta de seguridad simple,
estable y efectiva a la hora de proteger un host ubicado dentro de un
ambiente de redes de computadores (internet e intranet). Su costo es ínfimo
y no representa valor económico alguno comparado a las ventajas que este
sistema ofrece.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
104
Entre las ventajas y desventajas que este sistema ofrece se tienen:
Ventajas:
ü Mecanismo de seguridad no complejo, de fácil instalación y,
ahora, de simple configuración .
ü Realiza sus chequeos de forma transparente para el cliente
solicitante y la parte solicitada.
ü No representa impacto alguno en la conexión inicial al
momento de ser solicitado un servicio que sea protegido por
este mecanismo.
ü Dispone de un propio mecanismo de bitácora de eventos.
Desventajas:
ü Debido a su esquema estructural, el radio de protección es
limitado: sólo protege aquellos servicios invocados a través
del inetd.
Existen ciertas vulnerabilidades dentro de este sistema de seguridad,
pero que no involucran directamente al demonio tcpd. Éstas son producto de
errores o ataques a los servicios varios de los cuales hace uso los TCP
Wrappers, tales como el servidor DNS (si una dirección IP y/o nombre de
host es forjado, o si este servicio es comprometido). Los TCP Wrappers no
actuarían de forma correcta en este tipo de escenario, ya que no dispone de
mecanismos de prevención ante este tipo de situaciones.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
105
Wietse Venema, creador de los TCP Wrappers, demostró que no hace
falta crear soluciones complejas para resolver los problemas de ataques y
violación de privacidad que se presentan, sino que hace falta conocer el
ambiente y sistema con el que se está lidiando para así poder establecer
simples patrones que realmente cumplan con los requerimientos establecidos
y aporten soluciones efectivas ante la problemática que se presenta.
Sistema operativo y aplicaciones utilizadas
Linux, como plataforma base y sistema operativo, resultó ser valioso
por ser un sistema concebido para ambientes de redes y de escritorio. Se
caracteriza por su robustez, fiabilidad y estabilidad; características que han
contribuido en consolidar lo como una alternativa a ser tomada altamente en
cuenta para ser adoptado a efectos de consolidar un ambiente de red
organizacional. Es de libre distribución y se rige bajo la licencia GPL y código
abierto, por lo que resulta ser un ambiente apto para el desarrollo de nuevas
aplicaciones y tecnología.
Dado que Linux y la comunidad de desarrollo aportan un sinnúmero de
aplicaciones, éstas resultan ser útiles en el desarrollo de un nuevo trabajo,
porque pueden ser adoptadas y reutilizadas sin ningún tipo de restricciones o
leyes que intervengan en este proceso. Caso éste del propio webmin e
interfaces gráficas que componen Linux (KDE y GNOME), en donde cualquier
individuo o equipo de trabajo puede desarrollar la herramienta y/o módulo
que simplifique o ayude en la realización de una actividad específica del
sistema operativo.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
106
En fin, dentro de todo proyecto de desarrollo referente a seguridad,
hay que tener en cuenta una serie de factores: ambiente de trabajo,
situación, ventajas, desventajas, fortalezas y debilidades, que ayuden a
definir la balanza que ha de regir para establecer un mecanismo de defensa
ante las situaciones y/o problemas a venir.
También hay que tomar en consideración que la seguridad no es una
solución que luego de ser estipulada y definida, resulta funcional en todos los
sistemas en los cuales se aplique. La seguridad es una percepción que basa
su fundamento y establecimiento en el análisis de los factores que
intervienen en el ambiento o sistema estudiado. Por lo tanto, cada persona
puede adoptar o definir una percepción de seguridad distinta ante una misma
situación.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
107
RECOMENDACIONES
A lo largo de este proyecto y como en todo trabajo de desarrollo,
surgen ciertos aspectos y propuestas que han de ser señaladas con el fin de
informar y establecer puntos de partida a todo aquél interesado en hacer uso
y/o referencia al desarrollo aquí expuesto.
Las recomendaciones que a continuación se describen, se aplican,
algunas de ellas, para todo proyecto de seguridad, mientras que otras
resultan ser propias de este proyecto de desarrollo. Como recomendaciones y
sugerencias se tiene lo siguiente:
ü Si bien es cierto que los TCP Wrappers resulta ser un mecanismo
de seguridad efectivo y simple de usar, también es cierto que no
debe ser considerado como el único mecanismo de defensa que
represente una barrera ante posibles ataques y violaciones de
servicios a venir. Existen alternativas que, aplicadas en conjunto,
ofrecen un ambiente mucho más seguro y efectivo para el
administrador del sistema.
ü Dependiendo del sistema a proteger, hay que comenzar con
adoptar una de la políticas de seguridad:
Ø Todo lo que no está expresamente prohibido, está
permitido.
Ø Todo lo que no está expresamente permitido, está
prohibido.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
108
Una vez adoptado el tipo de política a seguir, se comienzan a definir
las reglas de filtrado en base a lo estipulado.
ü Consultar y revisar las bitácoras cada cierto tiempo, incluso si
todo funciona y se encuentra bajo control, con el fin de detectar
eventos considerados anormales para así poder establecer un
posterior estudio de lo acontecido.
ü Suscribirse a listas de correo electrónico referentes a temas de
seguridad que notifiquen de todo posible error, fallas y
correcciones existentes en los diferentes mecanismos de
seguridad y sistemas operativos para así estar al tanto sobre la
creación de nuevas implementaciones y herramientas de
seguridad.
ü Estar al tanto de la nueva implementación del demonio xinetd
(extended internet services daemon), quien pueda ser sustituto
del actual demonio inetd en algunos sistemas operativos, por
tratarse de un mecanismo más seguro que incorpora opciones ya
presentes en los TCP Wrappers y portmapper y añade otras
capacidades no presentes en ellos.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
109
GLOSARIO
Cracker: persona que hace uso de sus conocimientos sobre ambientes de
computadoras, para intentar un ataque o penetración a un sistema en
funcionamiento con el fines delictivos.
Demonio: programa que corre en background en un sistema UNIX.
DNS: servidor de nombres de dominio.
Finger: comando que despliega información sobre los usuarios del sistema.
Firewall: cortafuegos. Nodo de red establecido como un límite para controlar
el paso de tráfico de un segmento a otro.
Internet: malla mundial de computadoras y redes interconectadas. Integra
redes de área local (LAN), en una gran red de comunicaciones extendida por
todo el mundo.
Kernel: núcleo del sistema operativo.
NFS: Network File System. Protocolo que ofrece la habilidad de compartir
datos desde una computadora a otra en forma transparente.
NIS: Network Information Service. Sistema que permite manejar en forma
centralizada los servicios que son compartidos por múltiples máquinas.
Rlogin: inicia una sesión de terminal en un host remoto.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
110
Root: usuario con todos los privilegios administrativos en UNIX y Linux.
Rsh: shell remoto. Ejecuta comandos en el host determinado.
Servidor X: se encarga de proporcionar una plataforma para las aplicaciones
que utilizan interfaces gráficas.
Script: programa o secuencia de comandos.
Shell: conjunto de comandos empleados en UNIX y Linux.
Sockets: modelo comunicación-interproceso.
Sock_stream: provee una conexión de stream de bytes secuenciada,
confiable y de dos vías.
Sock_dgram: soporta datagramas (mensajes de un tamaño máximo
predeterminado, no confiables y de transmisión fuera de línea).
Sock_seqpacket: provee un camino de transmisión para datagramas en
una conexión secuenciada, confiable y de dos vías.
Sock_rdm: provee una capa de datagrama confiable que no garantiza el
ordenamiento.
TCP: es un protocolo de transmisión de flujo de bytes (streams) orientado a
conexión, confiable y con control de flujo.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
111
Trampas de arena: procesos o programas que simulan el funcionamiento
del servicio que esta siendo comprometido y que permite hacer el
seguimiento de las actividades del presunto atacante.
UDP: es un protocolo que proporciona un mecanismo básico de
intercomunicación de datagramas entre aplicaciones. No es confiable y no es
orientado a conexión.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
112
REFERENCIAS BIBLIOGRAFICAS
A98 Anonymous, Maximum Security. A hacker´s guide to
protecting your Internet site and network. Sams.net,
1999.
MM00 S. Mann, E. Mitchell. Linux System Security. The
Administrator´s guide to open source security tools.
Prentice Hall, 2000.
T97 A.Tanenbaum. Redes de Computadoras (Tercera
Edición). Prentice Hall,1997.
L99 C. Larman. UML y Patrones. Prentice Hall, 1999.
G00 A. Griffith. Gnome/Gtk+ Programing Bible. IDG Book,
2000.
LA99 M. Lutz, D. Ascher. Learning Python. O´Reilly &
Associates, 1999.
RD00 G. Rossum, F. Drake. Python Tutorial 2.0. BeOpen
PythonLabs,2000.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
113
RDR00 G. Rossum, F. Drake. Python Library Reference. BeOpen
PythonLabs, 2000.
V93 W. Venema. TCP WRAPPER, Network monitoring, access
control, and booby traps. 1993,
ftp://ftp.porcupine.org/pub/security/index.html
H99 J. Henstridge. PyGTK - Python Bindings for the GTK
Widget Set. 1999,
http://www.daa.com.au/~james/pygtk/
WCO00 L. Wall, T. Christiansen, J. Orwant. Programming PERL
3rd Edition. O´Reilly & Associates, 2000.
H98 K. Husain. PERL 5 Al Descubierto. Sams.net, 1998.
CWW J. Cameron, R. Wapple. Webmin.
http://www.webmin.com/webmin
NW00 T Niemueller. Webmin Modules. 2000
http://www.niemueller.de/webmin/writers-help/
KD00 KDE Proyect. Enero 2000, http://www.kde.org
GN00 GNOME Proyect. Enero 2000, http://www.gnome.org
Asegurando servicios de red utilizando TCP Wrappers en Linux.
114
APÉNDICE A.: Archivo de Configuración inetd.conf
# inetd.conf This file describes the services that will be available # through the INETD TCP/IP super server. To re-configure # the running INETD process, edit this file, then send the # INETD process a SIGHUP signal. # # Version: @(#)/etc/inetd.conf3.10 05/27/93 # # Authors: Original taken from BSD UNIX 4.3/TAHOE. # Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org> # <service_name> <sock_type> <proto> <flags> <user> <server_path> <args> # Note: builtin UDP services now silently drop packets from ports < 512. #echo stream tcp nowait root internal #echo dgram udp wait root internal discard stream tcp nowait root internal discard dgram udp wait root internal daytime stream tcp nowait root internal daytime dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal time stream tcp nowait root internal time dgram udp wait root internal # # These are standard services. # ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # # Mail and news # # Do not uncomment either unless you *really* know what you are doing. # Both are started as standalone demonios from the /etc/rc.d scripts. #smtp stream tcp nowait root /usr/bin/smtpd smtpd #nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd # # Shell, login, exec and talk are BSD protocols. # shell stream tcp nowait root /usr/sbin/tcpd in.rshd login stream tcp nowait root /usr/sbin/tcpd in.rlogind exec stream tcp nowait root /usr/sbin/tcpd in.rexecd talk dgram udp wait nobody.tty /usr/sbin/tcpd in.talkd ntalk dgram udp wait nobody.tty /usr/sbin/tcpd in.ntalkd #dtalk stream tcp wait nobody.tty /usr/sbin/tcpd in.dtalkd # # Pop and imap mail services et al # pop2 stream tcp nowait root /usr/sbin/tcpd ipop2d pop3 stream tcp nowait root /usr/sbin/tcpd ipop3d imap stream tcp nowait root /usr/sbin/tcpd imapd # # The Internet UUCP service. # uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/sbin/uucico -l # # Tftp service is provided primarily for booting. Most sites # run this only on machines acting as "boot servers." Do not uncomment
Asegurando servicios de red utilizando TCP Wrappers en Linux.
115
# this unless you *need* it. # #tftp dgram udp wait root /usr/sbin/tcpd in.tftpd #bootps dgram udp wait root /usr/sbin/tcpd bootpd # # This is for the finger service # finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd -u /var/run/.ppp_socket stream UNIX nowait root /usr/sbin/ppp-envoy ppp-envoy -da # # Finger, systat and netstat give out user information which may be # valuable to potential "system crackers." Many sites choose to disable # some or all of these services to improve security. # #systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx #netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat --inet # # Authentication # auth stream tcp nowait root /usr/sbin/in.identd in.identd swat stream tcp nowait.400 root /usr/sbin/tcpd swat # # End of inetd.conf
Asegurando servicios de red utilizando TCP Wrappers en Linux.
116
APÉNDICE B: Características de Linux
Definición de Linux
Linux es un sistema operativo multiusuario, multitarea y
multiprocesador, inspirado en UNIX. El Kernel de Linux fue originalmente
desarrollado por un estudiante llamado Linus Torvalds en la Universidad de
Helsinki en Finlandia. Torvalds luego de trabajar con el sistema operativo
Minix, encontró ciertos aspectos que el podía mejorar , entonces fue cuando
en Octubre de 1991, luego de rigurosos test de prueba, Torvalds publicó un
mensaje en internet anunciando que su nuevo sistema ya era estable y
ofreció su código fuente invitando a otros desarrolladores a contribuir por
esta causa.
Desde ese entonces desde la versión del kernel 0.9 hasta la 2.14, se
han incorporado una gran cantidad de cambios que lo han hecho altamente
popular y mejorado. Linux es un sistema operativo robusto que con modestos
recursos de hardware puede ser un excelente servidor de red y coexistir
prácticamente con cualquier otro sistema operativo como UNIX, Windows
3.11, Windows 95, Windows 98, Windows 2000, Windows NT, BeOs, DOS,
Netware y Macintosh.
Características de Linux
Multitarea: Es la capacidad de manejar múltiples procesos en forma
simultanea. Esto se conoce como multitarea preferente, porque cada
programa tiene garantizada la posibilidad de correr.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
117
Multiusuario: Linux permite que más de una persona pueda trabajar
en la misma versión y aplicación de manera simultánea, desde los mismos
terminales, o en terminales separados.
Programación: Ofrece una cantidad de lenguajes de programación y
compiladores y herramientas de desarrollo en forma gratuita, tales
como: Ada, Basic, C, C++, PERL, Python, Fortran, Pascal, GTK, Expect
, TCL/Tk, lenguajes shell (csh,bash,etc).
Portabilidad: Linux es compatible con diversos estándares UNIX,
tales como System V, BSD y los estándares internacionales IEEE POSIX.1 e
IEE POSIX.2, facilitando el desarrollo de aplicaciones para múltiples
plataformas.
Interconectividad: Linux puede conectarse a una red local y
convertirse en un servidor para MS-DOS, Windows, Windows para Trabajo en
Grupo (WfW), Windows 95 y Macintosh, por un costo muy por debajo de
otros sistemas comerciales.
Redes y Telecomunicaciones: Linux soporta las siguientes
interfaces de red: Ethernet, FDDI, Token Ring, Arcnet, X.25, ISDN, líneas
seriales síncronas y asíncronas.
Intranet / Internet: Linux ofrece un poder de internetworking
óptimo, provee clientes y servidores para protocolos esenciales tales como:
FTP (File Transfer Protocol), Gopher, HTTP (Hypertext Transfer Protocol), IP
(Internet Protocol), NNTP (Network News Transfer Protocol), POP (Post
Office Protocol), PPP (Point-to-Point), SMTP (Simple Mail Transfer Protocol),
Asegurando servicios de red utilizando TCP Wrappers en Linux.
118
Telnet, TCP (Transmission Control Protocol). Linux es probablemente el
sistema operativo óptimo en redes de estos momentos, debido al soporte de
diversos protocolos de redes, de poder convivir en redes heterogéneas y la
cantidad de programas y servicios de redes que ofrece.
Hardware: Linux también corre en computadoras con las diferentes
arquitecturas tales como: procesadores Alpha, Intel 80386, 80486, 80586 y
pentium, Sparc , Macintosh Power PC y Cyrix entre otros.
Propiedades Técnicas
El sistema operativo maneja consolas virtuales, lo que permite tener
más de una sesión abierta en la consola de texto y conmutar entre ellas
fácilmente. Maneja diversos sistemas de archivos para guardar los datos y
además permite acceder a los diskettes y particiones formateados con MS-
DOS o estándares como ISO-9660, usado en los CD-ROMS.
Con respecto a la conectividad, implementa todo lo necesario para
trabajar en red con TCP/IP. Desde drivers para las tarjetas de red más
populares hasta SLIP/PPP, que permiten acceder a una red TCP/IP por
puertos seriales. También implementa PLIP para comunicarse por el puerto
de la impresora y NFS (para acceso remoto de archivos). Además trabaja con
los clientes TCP/IP como FTP, Telnet, NNTP, SMTP.
El kernel soporta ejecutables con paginación por demanda. Esto
significa que sólo los segmentos del programa que se necesitan son los que
se cargan en memoria desde el disco. Las páginas de los ejecutables son
Asegurando servicios de red utilizando TCP Wrappers en Linux.
119
compartidas mediante la técnica copy-on-write, contribuyendo todo ello a
reducir la cantidad de memoria requerida para las aplicaciones.
Con la finalidad de incrementar la memoria disponible, Linux
implementa la paginación con el disco: puede tener hasta 256 megabytes de
intercambio, donde no se intercambian procesos completos, sino páginas
individuales en el disco duro. Cuando el sistema necesita más memoria,
expulsará páginas inactivas al disco, permitiendo la ejecución de programas
más grandes o aumentando el número de usuarios que puede atender a la
vez.
La memoria dedicada a los programas y al caché de disco está
unificada. Por ello, sí en cierto momento hay mucha memoria libre, el tamaño
del caché de disco aumentará acelerando así los accesos a éste.
Los ejecutables hacen uso de las librerías de enlace dinámico, esto
significa que comparten el código común de las librerías en un único archivo.
Así, los ejecutables serán más cortos a la hora de guardarlos en el disco.
También pueden enlazarse estáticamente cuando se deseen ejecutables que
requieran la presencia de las librerías del sistema. El enlace dinámico se hace
en tiempo de ejecución, con lo que el programador puede cambiar las
librerías sin necesidad de recompilación de los ejecutables.
Asegurando servicios de red utilizando TCP Wrappers en Linux.
120
APÉNDICE C. ¿Qué es Código Abierto?
En los viejos interludios en la historia de la computación, por allá por
los años 50, UNIX fue un sistema de código abierto. Quizá, porque a AT&T,
los creadores de UNIX, no se les permitía competir en el mercado de
software, el resultado fue que autorizaron el uso del software a las
universidades a un costo mínimo. En la medida en que fueron
desarrollándose distintos programas y aplicaciones, el mundo académico las
difundía sin restricciones.
Algunos de los mejores ejemplos de software disponible en cualquier
plataforma fueron creados en esa época, y todos se compartieron en la
comunidad de computación. La historia de la Internet es la historia del
software compartido sobre sistemas UNIX.
Hasta que Bill Gates y Paul Allen crearon un sistema operativo para el
MITS Altair 8800, nadie había pensado que un programa de software, de
cualquier tipo, pudiese ser “propietario”. Cuando alguien difundió ese sistema
operativo a otros estudiantes de computación de Harvard y MIT, en línea con
la costumbre habitual de compartir software, Bill Gates reaccionó de la
siguiente manera: “La mayoría de ustedes han robado el software... Una de
las cosas que hacen es la de impedir que se siga desarrollando buen
software. ¿Quién puede hacer un trabajo profesional por nada?”. Claramente
Bill Gates no quería que sus esfuerzos en programación se convirtieran en un
bien público.
Ciertamente él no fue el único que pensaba así, sin embargo, su
opinión reflejó un cambio en la manera en que se vio a la industria del
software. Desde entonces se comenzó a ver al software como “propiedad
Asegurando servicios de red utilizando TCP Wrappers en Linux.
121
comercial” en vez de verla como “propiedad comunitaria”. o “bien público”. El
software se transformó en algo protegido, una propiedad, algo secreto. Se
registraba como cualquier propiedad intelectual, incluso se hicieron intentos
de patentarla.
Para todos aquellos que vivieron los anteriores tiempos, estos fueron
días de oscurantismo. Richard Stallman, un estudiante del MIT (Instituto
Tecnológico de Massachusetts) viendo lo que estaba ocurriendo a la
propiedad comunal del software y recordando los días despreocupados de la
computación, dijo: “En 1971, cuando empecé a trabajar en el Laboratorio de
Inteligencia Artificial del MIT, me incorporé a una comunidad que llevaba
muchos años compartiendo el software. Ese intercambio no era limitativo de
esa comunidad en particular; es tan antiguo como las mismas computadoras.
Lo mismo que compartir recetas lo es al arte de cocinar. Simplemente lo
hacíamos más que la mayoría.”
“No calificábamos a nuestro software como software libre™, porque
ese término no existía todavía, sin embargo, eso es lo que era. Cuando
alguien de otra universidad o compañía quería adaptar o usar un programa,
gustosamente se lo cedíamos. Si veías a alguien usando un programa
interesante o fuera de lo común, se podía solicitar el código fuente, leerlo,
cambiarlo, o canibalizar algunas partes para hacer un nuevo programa.”
(Open Sources: Voices from the Open Source Revolution, O™Reilly, 1999.)
Observando el ocaso del software comunitario, Stallman escribió: “Esto
significa que el primer paso para usar una computadora era prometer que no
se ayudaría a nadie. Una comunidad cooperativa estaba prohibida. La regla
de los dueños del software era‚ si compartes con tu compañero, eres un
Asegurando servicios de red utilizando TCP Wrappers en Linux.
122
pirata. Si quieres algún cambio, ruéganos para hacerlo.”
La idea de que el sistema social del software propietario (el que dice
que compartir o cambiar software no está permitido) es antisocial, falto de
ética, erróneo, puede ser sorprendente para algunos lectores. Pero, ¿qué otra
cosa podemos decir de un sistema que divide al publico y mantiene al usuario
indefenso?. Los lectores que encuentren esta idea un tanto sorprendente
pueden haber tomado el sistema social tal como es, o lo han juzgado en los
términos dados por los fabricantes de software propietario. Los editores de
software han realizado una labor larga y dura para convencernos de que hay
sólo una forma de ver este asunto.
En un destello de genio, y Stallman es reconocido tanto por su genio
como por su pasión, decidió voltear el mundo de registros,
“propietarianismo”, proteccionismo y legalidades. Formó el proyecto GNU
para crear una nueva versión de UNIX libre y abierta. Para proteger su
esfuerzo, creó la Free Software Foundation (Fundación del Software Libre) e
hizo el bosquejo de la General Public License (GPL), a la cual llamó
“copiable”. Pareciera irónico que Stallman haya tenido que usar las leyes de
derechos de autor hechas para proteger software para mantenerlo “libre”. En
inglés el termino “libre” (free) tiene el significado de libre, suelto o gratis,
Stallman define el término “libre” como el usado en el contexto de “libertad”
de expresión no en el de cerveza “gratis”. Esto ocurrió en 1983.
En una ráfaga de creatividad, Stallman y su grupo crearon utilidades y
herramientas para UNIX. Todo para un sistema operativo menos el “kernel”
(núcleo).
Asegurando servicios de red utilizando TCP Wrappers en Linux.
123
El destino quiso que, alrededor de 1989, Linus Torvalds estuviese
trabajando en una versión de Minix basada en Intel, una pequeña versión de
UNIX desarrollada por Andrew Tannenbaum. Las limitaciones de
procesamiento inherentes de Minix, hizo que lo desechara y comenzara a
desarrollar un “kernel” completamente nuevo. A través de Internet, aglutinó
la ayuda de otros programadores y crearon un sistema operativo de alto
rendimiento, multiusuario y multitarea. En 1992, Linus liberó Linux. Sin el
trabajo de Stallman, entre otros, que crearon los programas GNU y las
utilidades, Linus no hubiese podido hacerlo tan rápido.
En la medida en que Linux empezó a circular, principalmente entre
“hackers”. Bruce Perens escribió en 1997, las “Pautas del Software Libre” en
la cual definió los derechos del usuario. Estas Pautas han seguido vigentes
con muy pocos ajustes. En 1997, Eric Raymond notó la ambigüedad de la
palabra “free” en el idioma inglés, especialmente cuando ya Linux empezaba
a atraer la atención de las grandes empresas. Durante el año siguiente, él y
Bruce Perens establecieron la Open Source Initiative (Iniciativa del Código
Abierto) y solicitaron la patente por el término “Open Source” (“Código
Abierto”).
En el último par de años, no solamente se ha venido incrementando el
número de utilidades y programas en Código Abierto, sino también el de las
compañías tradicionales de hardware y software que han anunciado su apoyo
a la comunidad Linux/Código Abierto.
Lo que comenzó como pequeñas gotas en visionarios como Stallman,
Torvalds, Perens y Raymond, se convirtieron en una fuerte tormenta en la
medida en que compañías como Caldera Systems y otros visionarios
Asegurando servicios de red utilizando TCP Wrappers en Linux.
124
empezaron a distribuir software en Código Abierto y a financiar la producción
de aun más. En la medida en que el mundo corporativo continúe adoptando
el modelo de desarrollo del Código Abierto, comenzará un diluvio que nadie
podrá parar.
(Extractos de la monografía de Caldera Systems titulada: “OpenLinux
and Open Sourcel” por Dean R.Zimmerman.)
top related