TEMA 7. Introducción a las redes TCP/IP.
Volver Imprimir Capítulo

7.3 Servicios y control de acceso.

Ya sabes que existen una serie de servicios que pueden estar ejecutándose en tu máquina y que ofrecen algún tipo de utilidad; algunos de ellos están pensados para dar servicio a otras máquinas de la red además de la propia. Ya sabes cómo activar y desactivar estos servicios desde el entorno gráfico, pero ahora lo veremos desde la consola.

Típicamente los servicios (tanto de red como los demás) se controlan mediante el uso de un script de texto localizado en /etc/init.d; ejecutando este script se puede iniciar el servicio, detenerlo o reiniciarlo (por ejemplo después de realizar alguna modificación en su configuración), tan sólo es necesario conocer el nombre de ese script.

Ya conoces el demonio atd, encargado de la ejecución programada de comandos; para iniciarlo es necesario invocar desde la línea de comandos: /etc/init.d/atd start, para detenerlo: /etc/init.d/atd stop, y para reiniciarlo /etc/init.d/restart.

Este funcionamiento de los servicios recibe el nombre de “standalone” ya que el demonio estará a la espera de que se necesiten sus servicios. Pero existe otra forma de tener estos servicios en funcionamiento conocida como activación “bajo demanda”; este modo de funcionamiento está reservado a los servicios de red y se basan a su vez en un servicio llamado “inetd”.

El programa inetd es un demonio (conocido a veces como “superdaemon” o superdemonio) que escucha peticiones en muchos puertos a la vez; cuando detecta actividad en alguno de los puertos arranca el servidor correspondiente al servicio solicitado. Este funcionamiento es conveniente por dos razones: evita tener en continuo funcionamiento un gran número de servidores que sólo se emplean ocasionalmente, y permite conceder o denegar el acceso en función del origen de la conexión antes de iniciar el servidor correspondiente.

Este servicio se configura en el archivo /etc/inetd.conf. Cada línea se utiliza para iniciar un servicio; si consultas este archivo encontrarás estas dos líneas:

smtp stream tcp nowait mail /usr/sbin/exim exim -bs
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd

La primera línea configura el servidor de correo electrónico de correo saliente o MTA (siglas en inglés de Agente de Transporte de Correo). El primer valor es el nombre del servicio tal y como aparece en /etc/services. Los dos siguientes indican el tipo de conexión y el protocolo a utilizar, y generalmente valen “stream tcp” o “dgram udp”, según que el servicio utilice un flujo (stream) TCP o datagramas UDP. El campo wait/nowait sólo tiene validez para datagramas e indica si hay que esperar a que se cierre la conexión abierta para atender otras peticiones.

A continuación se encuentra el usuario (y eventualmente el grupo) a través del cual se ejecutará el servidor; recuerda que vimos que existían usuarios “ficticios” que no se correspondían con una persona física sino que eran utilizados por programas y demonios para funcionar. En este caso el servicio smtp tomará la personalidad del usuario y grupo “mail”.

Para finalizar se encuentra la ruta completa del programa ejecutable para ese servicio seguido en su caso de los argumentos necesarios. En general no es necesario modificar este archivo a mano, puesto que al instalar el servidor correspondiente añadirá la línea adecuada en el archivo inetd.conf.

En ocasiones no aparece el programa ejecutable del servidor directamente sino que aparece “/usr/sbin/tcpd” antes de él, como ocurre en la segunda de las líneas; de esta forma se puede realizar el control de acceso que veremos a continuación. Dicho control de acceso permite o deniega el acceso a los servicios en función del origen de la conexión; este mecanismo se configura en los archivos /etc/hosts.allow y /etc/hosts.deny, donde se especifican unas sencillas reglas que permiten aceptar o rechazar conexiones entrantes. Además de los servicios activados mediante inetd hay algunos servidores que siempre utilizan este método de control de acceso (como sshd), conocido como TCP wrappers (cubiertas o envolturas para TCP).

Estos dos ficheros tienen una lista de la forma:

demonio : cliente

“Demonio” es el nombre del ejecutable, no el nombre del servicio (cuidado con esto, es fuente de numerosos quebraderos de cabeza) y el cliente es el origen al que se le permite o deniega el acceso a ese servicio.

Como demonio se pueden poner uno o más nombres separados por espacios o comas, y pueden usarse comodines como “?” (coincidencia con un carácter) o “*” (coincidencia con cualquier grupo de caracteres); también puede usarse la palabra “ALL” para indicar “cualquier servidor”. El cliente por su parte puede ser una o más direcciones IP, redes o nombres de máquinas separadas por espacios o comas; se pueden usar las palabras LOCAL (para especificar conexiones desde la misma máquina) o EXCEPT, para escribir excepciones.

El funcionamiento de ambos ficheros es muy sencillo; cuando el servicio arranca, se comprueba el contenido de /hosts.allow en busca de alguna regla que coincida; si se encuentra se permite el acceso. Si no se encuentra ninguna, se comprueba hosts.deny; si se encuentra una regla coincidente, se deniega el acceso. Observa que el acceso puede concederse de dos maneras distintas: por coincidir en el primero o por no coincidir en el segundo; ten esto en cuenta para no encontrarte con accesos no permitidos.

Veamos en un ejemplo; imaginemos que tenemos configurado el servidor FTP para ejecutarse a través de inetd (ya veremos cómo hacerlo en un capítulo posterior), con una línea como vimos anteriormente; si queremos que sólo accedan a él las máquinas de nuestra red excepto 192.168.0.13 tendremos que poner:

# contenido de /etc/host.allow
in.ftpd: LOCAL, 192.168.0 EXCEPT 192.168.0.13

# contenido de /etc/host.deny
ALL: ALL

No hay que olvidar esto último, ya que si no estaríamos permitiendo el acceso desde fuera de nuestra red.

Existen dos tipos de políticas de seguridad frecuentemente utilizadas: una de casi todo abierto y otra de casi todo cerrado. La primera consiste en permitir todo lo que no esté expresamente denegado; se implementa dejando vacío hosts.allow y denegando el servicio concreto en hosts.deny. La segunda por el contrario consiste en denegar todo lo que no esté permitido y se establece como en el ejemplo anterior, poniendo los accesos permitidos en el hosts.allow y denegando todo en el hosts.deny; esta última es en general la más adecuada.

Es posible que te tropieces alguna vez con un servicio especial llamado “portmap”; este servicio se encarga de encontrar un puerto disponible para servicios que no utilizan un número de puerto fijo sino que se acceden mediante un nombre; estos servicios se denominan de forma genérica RPC (Remote Procedure Call, o llamada a procedimiento remoto); en este caso es necesario indicar el origen mediante una IP, no es posible poner un nombre. Para protegerse ante posibles conexiones desde máquinas haciéndose parar por otras se puede usar un nombre de cliente denominado PARANOID, que coincide con todas las máquinas cuyo nombre no coincida con su IP.

 
 
   
 
Copyright - © ANFORA, 2004. Todos los derechos reservados. Condiciones Legales.    
Subir al inicio de la página Página Web de ÁNFORA