Asegurando servicios de red, utilizando TCP Wrappers en...

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


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


definir política.............................................................................57


configuración de reglas................................................................57


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


prueba 1-A.................................................................................94


prueba 1-B. ................................................................................95


prueba 1-B. ................................................................................95


IV


prueba 1-B.................................................................................95


prueba 1-B. ................................................................................96

Figura 38.- Archivo /etc/security/banners/allow/in.telnetd..............97

Figura 39.- Archivo /etc/security/banners/deny/in.telnetd..............97


prueba 2-A.................................................................................98


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


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


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


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.


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


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.


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


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.


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


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.


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.


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


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.


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.


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.


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.


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






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.


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.


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.


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.


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.


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


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


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:


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.


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


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


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


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


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.


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.


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


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


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


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


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


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


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.


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


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


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.


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.


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.


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.


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


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


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.


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


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:


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:


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


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


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


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.


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.


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.


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


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.


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.


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.


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.


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.


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:


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.


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.


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.


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.


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.


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


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.


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


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:


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.


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.


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.


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:


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:


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.


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.


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:


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.


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.


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


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.


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.


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


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.


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.


87

Figura 28.- Página donde se añade una regla.


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:


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


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.


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:


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.


93


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.


94


En la figura 33 el computador N° 3 de nombre samcorp (IP 10.0.0.21)

no tiene acceso al servicio ftp.

Parte B.


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.


95


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


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.


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


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


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


98


Figura 40.- Resultado de ejecutar telnet desde la IP 10.0.0.225 en la prueba 2-A.


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.



99


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.


100

Parte B.


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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, <[email protected]> # <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


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


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.


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),


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


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.


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


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


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


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


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

Asegurando servicios de red, utilizando TCP Wrappers en...

Documents

Transcript of Asegurando servicios de red, utilizando TCP Wrappers en...