%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Nota Legal                              %
%                                                               %
% Este documento es copyright (C) Olaf Kirch, okir@monad.swb.de %
%                                                               %
% Para las condiciones de copia, vease el fichero COPYING.      %
%                                                               %
% El autor no se responsabiliza de ningun dan~o, directo o      %
% indirecto, resultado del uso de la informacion proporcinada   %
% en este documento.                                            %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Cuando lea este documento con vi en una pantalla de 80        %
% columnas, haga primero un ':se nonumber'.                     %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
% Revisado en 5-Marzo-1999 por:                                 %
%   Juan Jose Amor <jjamor@ls.fi.upm.es>                        %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%          C O M I E N Z O   D E L   C A P I T U L O            %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Algunas Aplicaciones de Red}
\label{appl}

Despu\'es de instalar correctamente el IP y el sistema de resoluci\'on, tiene que 
dedicarse a los servicios que quiera proporcionar a trav\'es de la red. 
Este cap\'{\i}tulo trata la configuraci\'on de algunas sencillas aplicaciones
de red, incluyendo el servidor \prog{inetd}, y los programas de la 
familia \prog{rlogin}. El interface de {\it Llamada a Procedimiento
Remoto} o RPC\footnote{
N. del T.: Del ingl\'es Remote Procedure Call
}, en el que est\'an basados servicios como el {\it Sistema de Ficheros en
Red} o NFS\footnote{
N. del T.: Del ingl\'es Network File System} y el {\it Sistema de Informaci\'on de Red} o NIS\footnote{
N. del T.: Del ingl\'es Network Information System.
}, tambi\'en ser\'a tratado brevemente aqu\'{\i}. Las configuraciones de NFS 
y de NIS, sin embargo, ocupan m\'as espacio y ser\'an descritas en cap\'{\i}tulos
aparte. Lo mismo sucede con el correo electr\'onico y el sistema de noticias.


Por supuesto, no podemos cubrir todas las aplicaciones de red en este
libro. Si desea instalar alguna no tratada aqu\'{\i}, como \prog{talk}, 
\prog{gopher}, o \prog{Xmosaic}, por favor, refi\'erase a su documentaci\'on.


\section{El Super-Servidor \prog{inetd} }
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{appl.inetd}
\index{inetd@\prog{inetd}}
\index{servicios!configuraci\'on}
\index{servidor!inetd@\prog{inetd}|(}
\index{configurar!servicios de red}

Frecuentemente, los servicios son llevados a cabo por los llamados
\emph{demonios}. Un demonio es un programa que abre un determinado
puerto, y espera a recibir peticiones de conexi\'on. Si se recibe una
petici\'on de conexi\'on, lanza un proceso hijo que aceptar\'a la conexi\'on,
mientras el padre continua escuchando a la espera de m\'as peticiones.
Este concepto tiene el inconveniente de que por cada servicio ofrecido,
se necesita ejecutar un demonio que escuche las conexiones a un puerto,
lo que generalmente significa un desperdicio de recursos
de sistema como, por ejemplo, de espacio de intercambio.


Por ello, casi todas las instalaciones \unix{} corren un
``super-servidor'' que crea sockets para varios servicios, y escucha en
todos ellos simult\'aneamente usando la llamada al sistema
\func{select(2)}. Cuando un nodo remoto requiere uno de los servicios,
el super-servidor lo recibe y llama al servidor especificado para ese
puerto.


\index{inetd.conf@\file{inetd.conf}|(}
\index{chargen@\prog{chargen}}
\index{daytime@\prog{daytime}}
El super-servidor m\'as usado es \prog{inetd}, el demonio Internet.
Es iniciado en tiempo de arranque del sistema, y toma la lista de
servicios que debe tratar de un fichero de configuraci\'on denominado
\file{/etc/inetd.conf}. Aparte de esos servidores invocados por
\prog{inetd}, hay varios servicios triviales que el propio \prog{inetd} se
encarga de llevar a cabo, denominados \emph{servicios internos}. Entre
ellos, el \prog{chargen} que simplemente genera una cadena de
caracteres, y el \prog{daytime} que devuelve la fecha y hora del sistema.


Una entrada de este fichero consiste en una \'unica l\'{\i}nea compuesta por 
los siguientes campos:


\begin{tscreen}
\var{servicio tipo protocolo espera usuario servidor linea\_de\_comando}
\end{tscreen}


\noindent
El significado de cada campo es como sigue:

\begin{dispitems}
\ditem[\var{servicio}]
        \index{servicios@\file{services}}
        Proporciona el nombre del servicio. El nombre del servicio debe
        ser traducido a un n\'umero de puerto consultando el fichero
        \file{/etc/services}. Este fichero ser\'a descrito m\'as adelante
        en la secci\'on \ref{appl.services}.

\ditem[\var{tipo}]
        Especifica un tipo de socket, ya sea \keyword{stream} (para
        protocolos orientados a la conexi\'on) o \keyword{dgram} (para
        protocolos no orientados a la conexi\'on). Los Servicios basados en
        TCP deber\'an, por lo tanto, usar siempre \keyword{stream}, mientras
        que los servicios basados en UDP deber\'an usar siempre \keyword{dgram}.

\ditem[\var{protocolo}]
        \index{protocolos@\file{protocols}}
        Indica el protocolo de transporte usado por el servicio. \'Este
        debe ser un nombre de protocolo v\'alido que se pueda encontrar en
        el fichero \file{protocols}, tambi\'en descrito m\'as adelante.

\ditem[\var{espera}]
        Esta opci\'on se aplica s\'olo a sockets de tipo \keyword{dgram}.
        Puede tomar los valores \keyword{wait} o \keyword{nowait}. Si se
        especifica \keyword{wait}, \prog{inetd} ejecutar\'a s\'olo un servidor
        cada vez para el puerto especificado. De otro modo, continuar\'a
        escuchando por el puerto inmediatamente despu\'es de ejecutar el
        servidor.

        Esto es \'util para servidores ``single-threaded'' que leen todos
        los datagramas que entran hasta que no llegan m\'as, y despu\'es
        acaban. La mayor parte de los servidores RPC son de este tipo y se
        deber\'a por ello especificar \keyword{wait}. El otro tipo de
        servidores, los ``multi-threaded'', permiten un n\'umero ilimitado
        de instancias corriendo concurrentemente. Con estos servidores se
        deber\'a especificar \keyword{nowait}.

        Para sockets de tipo \keyword{stream} se deber\'a especificar siempre
        \keyword{nowait}.

\ditem[\var{usuario}]
        \'Este es el identificador del usuario bajo el que se
        ejecutar\'a el proceso. Por lo general, \'este suele ser el usuario
        \user{root}, aunque algunos servicios pueden usar diferentes
        cuentas. Es una buena idea el aplicar aqu\'{\i} el principio del
        menor privilegio, que indica que uno no deber\'{\i}a ejecutar un
        comando bajo una cuenta privilegiada si el programa no lo
        requiere para funcionar correctamente.
        Por ejemplo, el servidor de noticias NNTP se ejecutar\'a como
        \user{news}, mientras que otros servicios que podr\'{\i}an significar
        un riesgo para la seguridad (como \prog{tftp} o \prog{finger})
        son normalmente ejecutados como \user{nobody}.

\ditem[\var{servidor}]
        Proporciona el camino completo del programa servidor a ejecutar.
        Los servicios internos se indican con la palabra \keyword{internal}.

\ditem[\var{linea\_de\_comando}]
        \'Esta es la l\'{\i}nea de comando a pasar al servidor. Esto incluye el
        argumento~0, es decir, el nombre del comando. Normalmente, \'este
        ser\'a el nombre de programa del servidor, salvo que el programa se
        comporte de forma distinta cuando se le invoque con un nombre
        diferente.

        Este campo se deja vac\'{\i}o para los servicios internos.

\end{dispitems}


\begin{figure}[hbtp]
\begin{tscreen}
\begin{verbatim}
# 
# servicios inetd
ftp       stream tcp nowait root   /usr/sbin/ftpd    in.ftpd -l
telnet    stream tcp nowait root   /usr/sbin/telnetd in.telnetd -b/etc/issue
#finger    stream tcp nowait bin    /usr/sbin/fingerd in.fingerd
#tftp      dgram  udp wait   nobody /usr/sbin/tftpd   in.tftpd
#tftp      dgram  udp wait   nobody /usr/sbin/tftpd   in.tftpd /boot/diskless
login     stream tcp nowait root   /usr/sbin/rlogind in.rlogind
shell     stream tcp nowait root   /usr/sbin/rshd    in.rshd
exec      stream tcp nowait root   /usr/sbin/rexecd  in.rexecd
#
#       servicios internos inetd
#
daytime   stream tcp nowait root internal
daytime   dgram  udp nowait root internal
time      stream tcp nowait root internal
time      dgram  udp nowait root internal
echo      stream tcp nowait root internal
echo      dgram  udp nowait root internal
discard   stream tcp nowait root internal
discard   dgram  udp nowait root internal
chargen   stream tcp nowait root internal
chargen   dgram  udp nowait root internal
\end{verbatim}
\end{tscreen}
 \caption{
  \label{appl.fig.inetd.conf}
  Un ejemplo de fichero \file{/etc/inetd.conf}.
 }
\end{figure}


\index{seguridad!servidores TCP}
\index{finger@\prog{finger}}
En la figura~\ref{appl.fig.inetd.conf} se muestra un ejemplo de fichero
\file{/etc/inetd.conf}. La l\'{\i}nea del servicio \prog{finger} est\'a comentada,
de forma que no est\'e disponible. Esto se suele hacer normalmente por
razones de seguridad porque podr\'{\i}a ser usado por atacantes para obtener
nombres de usuarios del sistema.


\index{TFTP|see {Trivial File Transfer Protocol}}
\index{Trivial File Transfer Protocol}
\index{tftp@\prog{tftp}}
El \prog{tftp} tambi\'en se muestra deshabilitado. \prog{tftp} implementa
el \emph{Trivial File Transfer Protocol} que permite transferir
cualquier fichero del sistema que tenga permiso de lectura global sin
chequeo de passwords, etc. Esto es especialmente peligroso con el
fichero \file{/etc/passwd}, sobre todo si no se usa {\it shadow password}.


TFTP es usado com\'unmente por clientes y terminales~X sin unidad de
discos para obtener su {\it software} de un servidor de arranque. Si necesita
ejecutar \prog{tftp} por \'esta raz\'on, aseg\'urese de limitar su acci\'on a
los directorios de los que los clientes obtendr\'an los ficheros a\~nadiendo
esos nombres de directorio a la l\'{\i}nea de comando del \prog{tftpd}. Esto
se muestra en la segunda l\'{\i}nea \prog{tftp} del ejemplo.

\index{inetd.conf@\file{inetd.conf}|)}


\section{La herramienta de control de acceso \prog{tcpd}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{appl.tcpd}
\index{seguridad!servidores TCP}
\index{servicios!restringir acceso}
\index{acceso!restringir}
\index{restringir acceso}
\index{envoltorio, TCP}
\index{TCP!programa envoltorio}
\index{tcpd@\prog{tcpd}|(}
\index{servidor!inetd@\prog{tcpd}|(}

Ya que abrir un ordenador al acceso en red implica  muchos riesgos de
seguridad, las aplicaciones est\'an dise\~nadas para protegerse ante varios
tipos de ataques. Algunas de \'estas aplicaciones, sin embargo, pueden ser
reventadas (lo que qued\'o bastante demostrado con el {\it RTM Internet worm}),
o pueden no distinguir entre un nodo seguro cuyas peticiones de un
servicio particular deber\'{\i}an ser aceptadas, y otro nodo que no lo es y
cuyas peticiones deber\'{\i}an ser rechazadas. Ya hemos discutido brevemente
los servicios \prog{finger} y \prog{tftp} m\'as arriba. As\'{\i}, uno podr\'{\i}a
querer limitar el acceso a esos servicios solamente a los ``nodos
de confianza'', lo cual es imposible con la configuraci\'on usual, donde
\prog{inetd} o proporciona un servicio a todos los clientes, o a
ninguno.


Una herramienta \'util para esto es \prog{tcpd},\footnote{
  Escrita por Wietse Venema, \email{wietse@wzv.win.tue.nl}.
} el denominado {\it demonio envoltorio}\footnote{N. del T.: Del ingl\'es
Wrapper Daemon}. Para los servicios TCP que quiera
monitorizar o proteger, \'este es invocado en lugar del programa servidor.
\prog{tcpd} informa de la petici\'on al demonio \prog{syslog}, chequea si
el nodo remoto est\'a autorizado para usar ese servicio, y s\'olo si la
respuesta es satisfactoria, ejecutar\'a el programa servidor real. Observe
que esto no funciona con servicios basados en UDP.


Por ejemplo, para proteger el demonio \prog{finger}, debe cambiar la
l\'{\i}nea correspondiente en \file{inetd.conf} as\'{\i}:


\begin{tscreen}
\begin{verbatim}
# Proteger el demonio de finger
finger  stream  tcp     nowait  root    /usr/sbin/tcpd   in.fingerd
\end{verbatim}
\end{tscreen}


\index{syslog@\prog{syslog}}
As\'{\i}, sin a\~nadir ning\'un control de acceso, esto le har\'a parecer al
cliente que es la t\'{\i}pica configuraci\'on de \prog{finger}, salvo que
toda petici\'on ser\'a registrada en la facilidad \keyword{auth} del
\prog{syslog}.


El control de acceso est\'a implementado mediante dos ficheros llamados
\file{/etc/hosts.allow} y \file{/etc/hosts.deny}. Estos ficheros
contienen entradas permitiendo y denegando acceso, respectivamente, para
ciertos servicios y nodos. Cuando \prog{tcpd} trata una petici\'on de un
servicio como \prog{finger} de un nodo cliente denominado
\host{biff.foobar.com}, busca en \file{hosts.allow} y \file{hosts.deny}
(en \'este orden) una entrada en la que el servicio y el nodo cliente
coincidan. Si la entrada coincidente aparece en \file{hosts.allow}, se
garantiza el acceso, sin importar lo que haya en \file{hosts.deny}. Si
la coincidencia se encuentra en \file{hosts.deny}, la petici\'on se
rechaza cerrando la conexi\'on. Si no hay coincidencia en ninguno, la
petici\'on es aceptada.


Las entradas en los ficheros de acceso tienen la siguiente estructura:

\begin{tscreen}
 \var{lista\_servicios}: \var{lista\_nodos} [:\var{cmd\_shell}\/]
\end{tscreen}

%\indent
%These field have the following meaning:
%
%\begin{dispitems}

\var{lista\_servicios} es una lista de nombres de servicios de
\file{/etc/services}, o la palabra clave \keyword{ALL}. Para especificar
todos los servicios excepto \prog{finger} y \prog{tftp}, usa
``\keyword{ALL} \keyword{EXCEPT} \prog{finger, tftp}''.


\var{lista\_nodos} es una lista de nombres de nodos o direcciones~IP, o las
palabras clave \keyword{ALL}, \keyword{LOCAL}, o \keyword{UNKNOWN}.
\keyword{ALL} hace coincidir todos los nodos mientras que \keyword{LOCAL}
hace coincidir todos los nombres de nodos que no contengan un punto\footnote{
 Normalmente s\'olo los nombres de nodos locales obtenidos de b\'usquedas en
 \file{/etc/hosts} no contienen puntos.
}. \keyword{UNKNOWN} hace coincidir todos los nodos cuya b\'usqueda de nombre o
direcci\'on fall\'o. Un nombre comenzado por un punto incluye a todos los
nodos cuyo dominio es el mismo a ese nombre. Por ejemplo,
\host{.foobar.com} encajar\'a con \host{biff.foobar.com}. Tambi\'en hay
formas de especificar direcciones de red~IP y n\'umeros de subred. Por
favor, refi\'erase a la p\'agina del manual de \file{hosts\_access(5)} para m\'as
detalles.


Para denegar acceso a los servicios \prog{finger} y \prog{tftp} a todos
los nodos menos a los locales, ponga lo siguiente en
\file{/etc/hosts.deny}, y deje \file{/etc/hosts.allow} vac\'{\i}o:


\begin{tscreen}
in.tftpd, in.fingerd: ALL EXCEPT LOCAL, \var{.su.dominio}
\end{tscreen}

El campo opcional \var{cmd\_shell} puede contener un comando de shell para
que sea invocado cuando una b\'usqueda coincida con la entrada. Esto es
\'util para establecer trampas que puedan delatar a atacantes potenciales:

\begin{tscreen}
\begin{verbatim}
in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \
      echo "peticion de %d@%h" >> /var/log/finger.log; \
      if [ %h != "vlager.vbrew.com" ]; then \
	  finger -l @%h >> /var/log/finger.log \
      fi
\end{verbatim}
\end{tscreen}

Los argumentos \keyword{\%h} y \keyword{\%d} son expandidos por
\prog{tcpd} al nombre del nodo cliente y al nombre del servicio,
respectivamente. Refi\'erase a la p\'agina del manual de
\file{hosts\_access(5)} para m\'as detalles.


\index{tcpd@\prog{tcpd}|)}
\index{servidor!inetd@\prog{tcpd}|)}
\index{servidor!inetd@\prog{inetd}|)}

%\end{dispitems}

\section{Los ficheros \file{services} y \file{protocols}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{appl.services}
\label{appl.protocols}
\index{servicios@\file{services}|(}
\index{protocolos@\file{protocols}|(}
\index{servicios!conocidos}

Los n\'umeros de puerto en los que se ofrecen ciertos servicios
``est\'andar'' est\'an definidos en el RFC de ``N\'umeros Asignados''\footnote{
N. del T.: A veces se conocen como {\it Well Known Ports}, es decir, {\it
Puertos Bien Conocidos}}. Para
permitir a los programas cliente y servidor convertir nombres de
servicios en estos n\'umeros, se almacenan en un fichero llamado
\file{/etc/services}. Una entrada se construye as\'{\i}:


\begin{tscreen}
\var{servicio} \var{puerto}/\var{protocolo}   [\var{aliases}]
\end{tscreen}


Aqu\'{\i}, \var{servicio} especifica el nombre del servicio, \var{puerto} define
el puerto por el que se ofrece el servicio, y \var{protocolo} define qu\'e
protocolo de transporte se usa. Com\'unmente, \'este es \keyword{udp} o
\keyword{tcp}. Es posible que un servicio sea ofrecido a m\'as de un
protocolo, lo mismo que es posible ofrecer distintos servicios por el
mismo n\'umero de puerto, siempre que el protocolo sea distinto. El campo
\var{aliases} permite especificar nombres alternativos para el mismo
servicio.


Usualmente, no se necesita cambiar el fichero de servicios que viene con el
software de red en su sistema \linux{}. De todas formas, presentaremos
un peque\~no extracto de ese fichero.


\begin{tscreen}
\begin{verbatim}
# El fichero services:
#
# servicios conocidos (well-known)
echo           7/tcp                 # Eco
echo           7/udp                 #
discard        9/tcp  sink null      # Descartar
discard        9/udp  sink null      #
daytime       13/tcp                 # Fecha del sistema
daytime       13/udp                 #
chargen       19/tcp  ttytst source  # Generador de caracteres
chargen       19/udp  ttytst source  #
ftp-data      20/tcp                 # Protocolo FTP de ficheros (Datos)
ftp           21/tcp                 # Protocolo FTP de ficheros (Control)
telnet        23/tcp                 # Protocolo de Terminal
smtp          25/tcp                 # Protocolo de Correo
nntp         119/tcp  readnews       # Protocolo de Noticias
#
# servicios UNIX
exec         512/tcp                 # rexecd de BSD
biff         512/udp  comsat         # Notificacion de correo
login        513/tcp                 # login remoto
who          513/udp  whod           # who y uptime remotos
shell        514/tcp  cmd            # comando remoto, si contrase~na
syslog       514/udp                 # registro remoto del sistema
printer      515/tcp  spooler        # cola de impresion remota
route        520/udp  router routed  # informacion de encaminamiento
\end{verbatim}
\end{tscreen}


Observe que, por ejemplo, el servicio \prog{echo} es ofrecido en el
puerto 7 tanto para TCP como para UDP, y que el puerto 512 es usado para
dos servicios diferentes; el demonio COMSAT (que notifica a los usuarios
de correo reci\'en llegado, vea \prog{xbiff(1x)}), mediante UDP, y la
ejecuci\'on remota (\prog{rexec(1)}), usando TCP.


\index{n\'umeros de protocolo}
Ocurre algo similar con el fichero de protocolos: la librer\'{\i}a de red necesita una forma
de convertir nombres de protocolo~--- por ejemplo, los usados en el
fichero services~--- a n\'umeros de protocolo entendibles por el nivel IP 
en otros nodos. Esto se hace buscando el nombre en el fichero
\file{/etc/protocols}. Contiene una entrada por l\'{\i}nea, cada una
con un nombre de protocolo y el n\'umero asociado. Necesitar
modificar \'este fichero es todav\'{\i}a m\'as improbable que tener que hurgar en
\file{/etc/services}. Le mostramos un fichero ejemplo:


\begin{tscreen}
\begin{verbatim}
#
# Internet (IP) protocols
#
ip      0       IP              # protocolo internet, pseudo-protocolo
icmp    1       ICMP            # protocolo de mensajes de control
igmp    2       IGMP            # protocolo para mensajes multidestino
tcp     6       TCP             # protocolo de control de transmision
udp     17      UDP             # protocolo de datagramas de usuario
raw     255     RAW             # interfaz IP directa (modo "crudo")
\end{verbatim}"
\end{tscreen}

\index{servicios@\file{services}|)}
\index{protocolos@\file{protocols}|)}


\section{Llamada a Procedimientos Remotos}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\namedlabel{appl.rpc}{Remote Procedure Call}
\index{Remote Procedure Call|(}
\index{RPC|see {Remote Procedure Call}}

Un mecanismo muy general para aplicaciones cliente-servidor lo
proporciona RPC, el paquete \emph{Remote Procedure Call}. RPC fue
desarrollado por Sun Microsystems, y es una colecci\'on de herramientas y
funciones de librer\'{\i}a. Ejemplos de aplicaciones construidas sobre RPC
son NFS, el sistema de ficheros en red, y NIS, el sistema de
informaci\'on de red, que ser\'an presentados en pr\'oximos cap\'{\i}tulos.


\index{Representaci\'on Externa de Datos}
\index{XDR|see {External Data Representation}}
Un servidor RPC consiste en una colecci\'on de procedimientos a los que el
cliente puede llamar enviando una petici\'on RPC al servidor, junto con
los par\'ametros del procedimiento. El servidor invocar\'a al procedimiento
indicado en nombre del cliente, devolviendo el valor del resultado, si
lo hay. Para que sea independiente de la plataforma, todos los datos
intercambiados entre el cliente y el servidor son convertidos al formato
denominado de \emph{Representaci\'on Externa de Datos} o XDR\footnote{N. del T.: del ingl\'es eXternal Data Representation} por el segundo, y convertidos
otra vez a la representaci\'on de la m\'aquina local por el receptor.


A veces, las mejoras en una aplicaci\'on RPC introducen cambios incompatibles
en el interface de llamada a procedimiento. Por supuesto, s\'olo cambiando
el servidor dejar\'{\i}a de funcionar cualquier aplicaci\'on que todav\'{\i}a
espere el comportamiento original. Por ello, los programas RPC tienen
numeros de versi\'on asignados, normalmente empezando con~1, y con cada
nueva versi\'on del interface RPC \'este contador se incrementar\'a. A menudo,
un servidor puede ofrecer varias versiones a la vez; entonces los
clientes indicar\'an en sus peticiones mediante el n\'umero de versi\'on qu\'e
implementaci\'on del servicio desean usar.


\index{rpc@\file{rpc}}
\index{Remote Procedure Call!n\'umeros de programa}
La comunicaci\'on por red entre servidores y clientes RPC es un poco
peculiar. Un servidor RPC ofrece una o m\'as colecciones de
procedimientos; cada conjunto de \'estos es llamado \emph{programa}, y es
identificado un\'{\i}vocamente por un \emph{n\'umero de programa}. En
\file{/etc/rpc} se suele mantener una lista que mapea nombres de
servicios con n\'umeros de programa, reproducimos un extracto de \'este en
la figura~\ref{rpc.fig}.


\begin{figure}[htbp]
\begin{tscreen}
\begin{verbatim}
#
# /etc/rpc - servicios variados basados en RPC
#
portmapper      100000  portmap sunrpc
rstatd          100001  rstat rstat_svc rup perfmeter
rusersd         100002  rusers
nfs             100003  nfsprog
ypserv          100004  ypprog
mountd          100005  mount showmount
ypbind          100007
walld           100008  rwall shutdown
yppasswdd       100009  yppasswd
bootparam       100026
ypupdated       100028  ypupdate
\end{verbatim}
\end{tscreen}
 \caption{
  \label{rpc.fig}
  Un ejemplo de fichero \file{/etc/rpc}.
 }
\end{figure}


En redes TCP/IP, los autores de RPC se encontraron con el problema de
mapear n\'umeros de programa a servicios de red gen\'ericos. Decidieron
que cada servidor proporcionara ambos, un puerto TCP y otro UDP, para
cada programa y para cada versi\'on. Generalmente, las aplicaciones RPC
usar\'an UDP cuando env\'{\i}en datos, y s\'olo recaer\'an en TCP cuando los datos
a transferir no quepan en un datagrama UDP sencillo.


\index{demonio mapeador de puertos}
\index{Remote Procedure Call!mapeando puertos a programas}
\index{portmap@\prog{portmap}}
Por supuesto, los programas clientes tienen que tener una forma de
encontrar a qu\'e puerto mapea un n\'umero de programa. Usando un fichero de
configuraci\'on para esto ser\'{\i}a muy inflexible: ya que las aplicaciones
RPC no usan puertos reservados, no hay garant\'{\i}as de que un puerto
originalmente pensado para ser usado por nuestra aplicaci\'on de base
de datos no haya sido cogido por alg\'un otro proceso. Por lo tanto, las
aplicaciones RPC escogen cualquier puerto que puedan utilizar, y lo
registran con el denominado \emph{demonio mapeador de puertos}\footnote{
N. del T.: Del ingl\'es Portmapper daemon}. \'Este
\'ultimo act\'ua como un distribuidor de servicios para todos los servidores
que corren en su m\'aquina: un cliente que desee contactar con un servicio
que tiene un n\'umero de programa dado, preguntar\'a primero al mapeador de
puertos del nodo del servidor qui\'en devolver\'a los n\'umeros de puerto TCP
y UDP por los que el servicio puede ser accedido.


\index{inetd@\prog{inetd}}
Este m\'etodo tiene como mayor inconveniente que introduce un punto de ruptura
\'unico, muy parecido al que crea el demonio \prog{inetd} en los servicios
Berkeley est\'andar. De todas formas, \'este caso es un poco m\'as grave,
porque cuando el mapeador de puertos cae, toda la informaci\'on de
puertos RPC se pierde; esto normalmente implica que hay que rearrancar
todos los servidores RPC manualmente, o rearrancar toda la m\'aquina.


En \linux{}, el mapeador de puertos se llama \prog{rpc.portmap} y reside
en \file{/usr/sbin}. Aparte de asegurarse de que es arrancado desde
\prog{rc.inet2}, el mapeador de puertos no necesita m\'as trabajo de
configuraci\'on.

\index{Remote Procedure Call|)}


\section{Configurar los Comandos \prog{r}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{appl.remote}
\index{configurar!los comandos r@los comandos \prog{r}|(}
\index{autorizacion!y comandos r@y comandos \prog{r}}
\index{LAN!comandos r@comandos \prog{r}}
\index{LAN!passwords}
\index{passwords!y login remoto}
\index{remoto!ejecucuci\'on de comandos}
\index{seguridad!comandos r@comandos \prog{r}}
\index{seguridad!login remoto}
\index{remoto!login}
\index{remoto!acceso de ficheros}
\index{rlogin@\prog{rlogin}}
\index{rcp@\prog{rcp}}
\index{rsh@\prog{rsh}}

Hay varios comandos para ejecutar programas en nodos remotos. Son
\prog{rlogin}, \prog{rsh}, \prog{rcp} y \prog{rcmd}. Todos ellos lanzan
un shell en el nodo remoto y permiten al usuario ejecutar comandos. Por
supuesto, el cliente necesita tener una cuenta en el nodo en el que se
van a ejecutar los comandos. Por ello todos estos comandos llevan a cabo
un procedimiento de autorizaci\'on. Normalmente, el cliente indicar\'a el
nombre de login del usuario al servidor, el cual requerir\'a un password
que ser\'a validado de la forma habitual.


A veces, sin embargo, es deseable el relajar estos chequeos de
autorizaci\'on para ciertos usuarios. Por ejemplo, si usted tiene que
entrar frecuentemente en otras m\'aquinas de su LAN, tal vez desee ser
admitido sin tener que escribir su password cada vez.
% On one hand, this is a question of convenience, on the other it may be
% a matter of security not having to send your password across an insecure
% network every time you log in.


Deshabilitar autorizaciones s\'olo es aconsejable en un n\'umero reducido de
nodos cuyas bases de datos de passwords est\'en sincronizadas, o para un
n\'umero reducido de usuarios privilegiados que necesiten acceder a muchas
m\'aquinas por razones administrativas. Siempre que desee permitir a gente
entrar en su nodo sin tener que especificar un login o password, debe
asegurarse de que no permite acceso accidentalmente a nadie m\'as.


\index{hosts.equiv@\file{hosts.equiv}}
\index{rhosts@\file{.rhosts}}
Hay dos formas de deshabilitar chequeos de autorizaci\'on para los
comandos \file{r}. Una es que el super usuario permita a ciertos o a
todos los usuarios el entrar, sin ser preguntados por un password,
en ciertos o en todos los nodos (lo cual es ciertamente una mala idea).
Este acceso es controlado por un fichero denominado
\file{/etc/hosts.equiv}. Este contiene una lista de nodos y nombres de
usuarios que son considerados equivalentes a usuarios en el nodo local.
Una opci\'on alternativa es que un usuario permita acceso a otros usuarios
de ciertos nodos a su cuenta. \'Estos ser\'{\i}an listados en el fichero
\file{.rhosts} en el directorio {\it home} del usuario. Por razones de
seguridad, este fichero debe pertenecer al usuario o al super usuario, y no
debe ser un enlace simb\'olico, de otro modo ser\'a ignorado.\footnote{
 En un entorno NFS, podr\'{\i}a necesitar darle una protecci\'on de 444, porque
 el superusuario por lo general est\'a muy restringido en el acceso a
 ficheros en discos montados via NFS.
}


Cuando un cliente pide un servicio \prog{r}, su nodo y nombre de usuario
son buscados en el fichero \file{/etc/hosts.equiv}, y despu\'es en el
fichero \file{.rhosts} del usuario con cuyo nombre se pretende entrar.
Como ejemplo, asumamos que \user{janet} est\'a trabajando en \host{gauss}
e intenta entrar en la cuenta de \user{joe} en \host{euler}. A partir de
ahora, nos referiremos a Janet como el usuario cliente, y a Joe como el
usuario \emph{local}. Ahora, cuando Janet escriba

\begin{tscreen}
\$ rlogin -l joe euler
\end{tscreen}

\noindent
en \host{gauss}, el servidor primero
chequear\'a en \file{hosts.equiv}\footnote{
 Observe que el fichero \file{hosts.equiv} \emph{no} es examinado cuando
 alguien intenta entrar como \user{root}.
} si a Janet se le puede proporcionar acceso libre y, si esto falla,
intentar\'a localizarla en el fichero \file{.rhosts} del directorio {\it home}
de \user{joe}.


El fichero \file{hosts.equiv} en \host{euler} es algo as\'{\i}:

\begin{tscreen}
\begin{verbatim}
gauss
euler
-public
quark.physics.groucho.edu     andres
\end{verbatim}
\end{tscreen}

Una entrada consiste en un nombre de nodo, seguido opcionalmente por
un nombre de usuario. Si aparece un nombre de nodo y nada m\'as, todos los
usuarios de ese nodo ser\'an admitidos en sus cuentas locales sin ninguna
comprobaci\'on. En el ejemplo anterior, Janet hubiera sido autorizada a
entrar en su cuenta \user{janet} si llamaba desde \host{gauss}, y lo
mismo se aplicar\'{\i}a a cualquier otro usuario exceptuando a \user{root}.
De todas formas, si Janet desea entrar como \user{joe}, se le pedir\'{\i}a un
password como siempre.


Si un nombre de nodo va seguido de un nombre de usuario, como en la
\'ultima l\'{\i}nea del fichero ejemplo, a ese usuario se le permite acceso
libre de password a \emph{todas} las cuentas excepto a la cuenta
\user{root}.


El nombre de nodo tambi\'en puede ir precedido de un signo menos, como en
la entrada ``\host{-public}''. Esto requiere autorizaci\'on para todas las
cuentas en \host{public}, sin importar lo que permitan los usuarios
individuales en sus ficheros \file{.rhosts}.


El formato del fichero \file{.rhosts} es id\'entico al del
\file{hosts.equiv}, pero su significado es un poco diferente.
Consideremos el siguiente fichero \file{.rhosts} de Joe en \host{euler}:


\begin{tscreen}\small
\begin{verbatim}
chomp.cs.groucho.edu
gauss      janet
\end{verbatim}
\end{tscreen}


La primera entrada permite a \user{joe} acceso libre cuando entra desde
\host{chomp.cs.groucho.edu}, pero no afecta a los permisos de ninguna
otra cuenta en \host{euler} o \host{chomp}. La segunda entrada es una
peque\~na variaci\'on de esto en que permite a \user{janet} acceso libre a
la cuenta de Joe cuando entra desde \host{gauss}.


Observe que el nombre de nodo del cliente se obtiene mediante la resoluci\'on
inversa de la direcci\'on del que llama a un nombre, de forma que esta
caracter\'{\i}stica fallar\'a con nodos deconocidos para el sistema de
resoluci\'on. El
nombre de nodo del cliente se considera que coincide con el nombre en
los ficheros de nodos en uno de los siguientes casos:


\begin{itemize}
\item   El nombre can\'onico del cliente (no un alias) coincide
        literalmente con el nombre de nodo en el fichero.

\item   Si el nombre de nodo del cliente es un nombre de dominio
        completamente cualificado (como el devuelto por el sistema de resoluci\'on
        cuando se tiene DNS en marcha), y no coincide literalmente con
        el nombre de nodo en el fichero de nodos, se compara con el
        nombre de nodo que se forma al expandirlo con el nombre de
        dominio local.

% \item   The host name specified in the hosts file is \host{+},
%         in which case any host name matches.
\end{itemize}


% If NIS is in place, the hosts files provide yet another feature.
% Instead of a host or user name, a netgroup (as defined in the
% \file{/etc/netgroups} file) may be specified, preceded by an at sign
% (@).
% 
% If the netgroup appears instead of a host name, the entry applies to
% all hosts in the netgroup; if it appears instead of a user name, the
% entry applies to all users in the netgroup.
% 
% 
% If the netgroup name is preceded by a plus, the entry grants free
% access to all clients matching the entry; otherwise it denies access.
% 

\index{configurar!los comandos r@los comandos \prog{r}|)}



 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%
%% We don't really want this. The BSD ftpd doesn't really cut it
%% as an FTP server, and wu-ftpd is way too complicated to cram it
%% into two and a half pages.
%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \section{Setting up an FTP Server}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \label{appl.ftp}
% \index{configuring!anonymous FTP|(}
% \index{FTP, anonymous|(}
% \index{server!ftpd@\prog{ftpd}}
% \index{ftpd@\prog{ftpd}}
% \index{passwd@\file{passwd}}
% \index{shadow@\file{shadow}}
% 
% 
% The most widely known use of FTP (File Transfer Protocol) is to
% provide users from any host with access to publicly available data.
% This is generally called anonymous FTP. However, it may be used
% for file transfers from and to local user accounts as well. The FTP
% server, \prog{ftpd}, performs the usual authorization procedure using
% the \file{/etc/passwd} and \file{/etc/shadow} databases.
% 
% 
% \index{ftpusers@\file{ftpusers}}
% \index{access!restricting}
% After passing this procedure, a client is allowed access to any files
% and directories accessible to the user she logged in as.  Certain users
% may be denied access to FTP by listing them in the file
% \file{/etc/ftpusers}. This file contains one user name per line, without
% any white space allowed.
% 
% 
% There are other FTP daemons, e.g. \prog{ftpd-diku}, which have enhanced
% functionality.  Since they are not part of the ``official'' networking
% release, I do not describe them here. Please refer to the documentation
% that comes with them.
% 
% 
% \subsection{Anonymous FTP}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \label{appl.ftp.anonymous}
% 
% Anonymous FTP requires tough security measures to prevent clients from
% accessing any important information on your system.
% 
% 
% To set up an anonymous FTP account, you have to create a user named
% \user{ftp}. It should be member of a group with very limited access only,
% for example \user{guest}, have a login shell of \prog{/bin/false}, and a
% password of ``\keyword{*}'' to prevent anyone from actually logging in as
% \user{ftp}. The home directory should be something like \file{/home/ftp},
% have proper ownership (namely \user{ftp} and \user{guest}) and have a
% protection mode of 555. The entry in the \file{passwd} file would look like
% this:
% 
% \begin{tscreen}
% \begin{verbatim}
% ftp:*:500:60:Anonymous FTP:/home/ftp:/bin/false
% \end{verbatim}
% \end{tscreen}
% 
% 
% If a client specifies a user name of \user{ftp} or \user{anonymous} when
% asked by \prog{ftpd}, the server performs a \func{chroot(2)} to the
% home directory of the \user{ftp} account. The effect of this is that this
% home directory appears to the client as the root of the directory hierarchy,
% thus denying it access to any files outside the home directory.\footnote{
%  When you merely change the working directory, you may access files
%  outside of it by either using absolute pathnames or \file{..} to move
%  up the directory hierarchy.  When doing a \prog{chroot}, all absolute
%  pathnames are interpreted as starting at the new directory, and its
%  parent directory is inaccessible.
% } Any files (such as the \prog{ls} command) accessed after this \prog{chroot}
% must thus be available beneath this directory.
% 
% 
% In addition, you may allow sub-logins of users whom you have granted
% special access to your FTP area, for example the person who maintains
% the \file{Network} directory. These users first log in as an anonymous
% FTP user, and after that log into the sub-account by specifying a user
% name and password using the \keyword{USER} command of \prog{ftp}. For
% these, you have to set up a home directory, which is owned by the user
% and has mode 700. Remember that the home directory name is rooted
% at \user{ftp}'s home directory.
% 
% 
% \noindent
% The following files directories need to be present:
% 
% \begin{dispitems}
% \ditem[\file{\tld{}ftp/bin}]
%         This directory should be owned by \user{root} and have mode
%         555.  It should contain a copy of the \prog{ls} command, which
%         is needed by \prog{ftpd} to list directories. It should be
%         mode 111.  If \file{\tld{}ftp} is on the same file system as
%         \file{/bin}, this may also be a hard link to \file{/bin/ls};
%         however, you can not make it a symbolic link.
% 
% \ditem[\file{\tld{}ftp/lib}]
%         This directory should be owned by \user{root} and have mode 555.
%         If the programs in \file{\tld ftp/bin} are dynamically linked, it
%         must contain a copy of the current version of the shared C~library,
%         \file{/lib/libc.so.\var X}, and the dynamic loader \file{ld.so}.
%         Most \linux{} distributions, however, contain a statically linked
%         \prog{ls} binary for this FTP purpose, so you don't need the shared
%         library in \file{\tld ftp/lib}.
% 
% \ditem[\file{\tld{}ftp/etc}]
%       \index{passwd@\file{passwd}}
%       \index{shadow@\file{shadow}}
%         This directory should be owned by \user{root} and have mode 555.
%         It should contain a \file{passwd} and \file{group} file to
%         map user id's to login names when listing files. They should not
%         be complete copies of the files from \file{/etc}, nor should
%         they be hard links, since this would provide intruders with a
%         list of all accounts on your system.
% 
%         The \file{passwd} and \file{shadow} files should contain data
%         for \user{root}, \user{bin}, \user{ftp}, plus the available
%         sub-logins.
% 
%         Accounts other than sub-logins should be denied access by
%         specifying a password of ``\keyword{*}'' in the password
%         field.
% 
% \ditem[\file{\tld{}ftp/incoming}]
%         This directory should be owned by \user{ftp}. It should have
%         mode 1733 to allow users to deposit files, but prevent others
%         from retrieving them before you have moved them to the proper
%         location (or thrown them away, for that matter).  Alternatively,
%         it can have mode 1777 if you want to allow them to be retrieved.
% 
% \ditem[\file{\tld{}ftp/pub}]
%         Below this directory, you keep all files you want to make
%         available to users of your anonymous FTP service. The directory
%         should be owned by \user{ftp} and have mode 555. Files below this
%         should have mode 444 to prevent FTP users from removing or
%         modifying them.
% 
% \end{dispitems}
% 
% If your \file{\tld{}ftp/} directory is not on the same partition as your
% shared libraries, you will almost certainly be better off to make
% staticly linked copies of your executables, as the shared library is
% quite large, and would take up more disk space than simply making a few
% staticly-linked executables.  Another possibility is installing the
% ``lite'' shared library, which is available in the GCC/library
% distribution, and is quite a bit smaller.
% 
% 
% 
% \subsection{\prog{ftpd} Options}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \label{appl.ftp.options}
% \index{inetd.conf@\file{inetd.conf}}
% \index{inetd@\prog{inetd}}
% \index{ftpd@\prog{ftpd}}
% 
% Usually, \prog{ftpd} is invoked by the \prog{inetd} super-server. On the
% command line passed to \prog{ftpd}, you may specify the following
% options:
% 
% 
% \begin{dispitems}
% \ditem[\option{-l}]
%         Log FTP sessions.
% 
% \ditem[\option{-d \var{dbglvl}}]
%         Log debug messages. 
% 
% \ditem[\option{-t \var{timeout}}]
%         Causes \prog{ftpd} to close down sessions after the client has
%         been inactive for the specified amount of time. By default, this
%         value is set to 15 minutes.
% 
% \ditem[\option{-u \var{umask}}]
%         Sets the file creation mask used by \prog{ftpd} to \var{umask}.
%         It defaults to 027, which means that files deposited in the
%         \file{incoming} directory will have a permission of 640.
% 
% \end{dispitems}
% 
% You can add these options to the \prog{ftpd} invocation in \file{inetd.conf}.
% 
% 
% \index{syslog@\prog{syslog}}
% When logging is enabled, \prog{ftpd} logs messages to the
% \keyword{daemon} facility of \prog{syslogd}. FTP sessions are logged at
% the \keyword{info} level; debug messages are logged at the
% \keyword{debug} level. To send these messages to a file, enter the
% following line to \file{/etc/syslogd.conf}:
% 
% 
% \begin{tscreen}
% \begin{verbatim}
% daemon.info:    /usr/adm/daemon.log
% \end{verbatim}
% \end{tscreen}
% 
% \index{configuring!anonymous FTP|)}
% \index{FTP, anonymous|)}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%              F I N   D E L   C A P I T U L O                  %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
