El fichero /etc/hosts
Este fichero se utiliza para obtener una relación entre un nombre de máquina y una dirección IP: en cada línea de
/etc/hosts se especifica una dirección IP y los nombres de máquina que le corresponden, de forma que un usuario no tenga que recordar direcciones sino nombres de
hosts. Habitualmente se suelen incluir las direcciones, nombres y aliases de todos los equipos conectados a la red local, de forma que para comunicación dentro de la red no se tenga que recurrir a DNS a la hora de resolver un nombre de máquina. El formato de una línea de este fichero puede ser el siguiente:
158.42.2.1 pleione pleione.cc.upv.es pleione.upv.es
Esta línea indica que será equivalente utilizar la dirección
158.42.2.1, el nombre de máquina
pleione, o los
aliases pleione.cc.upv.es y
pleione.upv.es cuando queramos comunicarnos con este servidor:
luisa:~# telnet pleione
Trying 158.42.2.1...
Connected to pleione.cc.upv.es
Escape character is '^]'.
Connection closed by foreign host.
luisa:~# telnet 158.42.2.1
Trying 158.42.2.1...
Connected to pleione.cc.upv.es
Escape character is '^]'.
Connection closed by foreign host.
luisa:~#
El archivo /etc/ethers
De la misma forma que en
/etc/hosts se establecía una correspondencia entre nombres de máquina y sus direcciones IP, en este fichero se establece una correspondencia entre nombres de máquina y direcciones
ethernet, en un formato muy similar al archivo anterior:
00:20:18:72:c7:95 pleione.cc.upv.es
En la actualidad el archivo
/etc/ethers no se suele encontrar (aunque para el sistema sigue conservando su funcionalidad, es decir, si existe se tiene en cuenta) en casi ninguna máquina Unix, ya que las direcciones hardware se obtienen por ARP. No obstante, aún resulta útil en determinados casos, por ejemplo en cortafuegos con tarjetas
quad donde todas las interfaces de la tarjeta tienen la misma dirección MAC.
El fichero /etc/networks
Este fichero, cada vez más en desuso, permite asignar un nombre simbólico a las redes, de una forma similar a lo que
/etc/hosts hace con las máquinas. En cada línea del fichero se especifica un nombre de red, su dirección, y sus
aliases:
luisa:~# cat /etc/networks
loopback 127.0.0.0
localnet 192.168.0.0
luisa:~#
El uso de este fichero es casi exclusivo del arranque del sistema, cuando aún no se dispone de servidores de nombres; en la operación habitual del sistema no se suele utilizar, ya que ha sido desplazado por DNS.
El fichero /etc/services
En cada línea de este fichero se especifican el nombre, número de puerto, protocolo utilizado y aliases de todos los servicios de red existentes (o, si no de todos los existentes, de un subconjunto lo suficientemente amplio para que ciertos programas de red funcionen correctamente). Por ejemplo, para especificar que el servicio de
smtp utilizará el puerto 25, el protocolo TCP y que un
alias para él es
mail, existirá una línea similar a la siguiente:
smtp 25/tcp mail
El fichero
/etc/services es utilizado por los servidores y por los clientes para obtener el número de puerto en el que deben escuchar o al que deben enviar peticiones, de forma que se pueda cambiar (aunque no es lo habitual) un número de puerto sin afectar a las aplicaciones; de esta forma, podemos utilizar el nombre del servicio en un programa y la función
getservicebyname() en lugar de utilizar el número del puerto:
luisa:~# telnet anita 25
Trying 192.168.0.3...
Connected to anita.
Escape character is '^]'.
220 anita ESMTP Sendmail 8.9.1b+Sun/8.9.1; Sun, 31 Oct 1999 06:43:06 GMT
quit
221 anita closing connection
Connection closed by foreign host.
luisa:~# telnet anita smtp
Trying 192.168.0.3...
Connected to anita.
Escape character is '^]'.
220 anita ESMTP Sendmail 8.9.1b+Sun/8.9.1; Sun, 31 Oct 1999 06:43:20 GMT
quit
221 anita closing connection
Connection closed by foreign host.
luisa:~#
Este fichero
NO se utiliza para habilitar o deshabilitar servicios, sino como hemos dicho, simplemente para obtener números de puerto a partir de nombres de servicio y viceversa.
El fichero /etc/protocols
El sistema de red en Unix utiliza un número especial, denominado número de protocolo, para identificar el protocolo de transporte específico que la máquina recibe; esto permite al
software de red decodificar correctamente la información recibida. En el archivo
/etc/protocols se identifican todos los protocolos de transporte reconocidos junto a su número de protocolo y sus
aliases:
luisa:~# cat /etc/protocols
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # internet group multicast protocol
ggp 3 GGP # gateway-gateway protocol
tcp 6 TCP # transmission control protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
idp 22 IDP # WhatsThis?
raw 255 RAW # RAW IP interface
luisa:~#
No es usual - ni recomendable - que el administrador modifique este fichero; es el
software de red el que lo va actualizando al ser instalado en la máquina.
El fichero /etc/hosts.equiv
En este fichero se indican, una en cada línea, las máquinas confiables. >Qué significa
confiables? Básicamente que confiamos en su seguridad tanto como en la nuestra, por lo que para facilitar la compartición de recursos, no se van a pedir contraseñas a los usuarios que quieran conectar desde estas máquinas con el mismo
login, utilizando las órdenes BSD
r (
rlogin, rsh, rcp...). Por ejemplo, si en el fichero
/etc/hosts.equiv del servidor
maquina1 hay una entrada para el nombre de
host maquina2, cualquier usuario14.1 de este sistema puede ejecutar una orden como la siguiente para conectar a
maquina1 <sin necesidad de ninguna clave!:
maquina2:~$ rlogin maquina1
Last login: Sun Oct 31 08:27:54 from localhost
Sun Microsystems Inc. SunOS 5.7 Generic October 1998
maquina1:~$
Obviamente, esto supone un gran problema de seguridad, por lo que lo más recomendable es que el fichero
/etc/hosts.equiv esté vacío o no exista. De la misma forma, los usuarios pueden crear ficheros
$HOME/.rhosts para establecer un mecanismo de confiabilidad bastante similar al de
/etc/hosts.equiv; es importante para la seguridad de nuestro sistema el controlar la existencia y el contenido de estos archivos
.rhosts. Por ejemplo, podemos aprovechar las facilidades de planificación de tareas de Unix para, cada cierto tiempo, chequear los directorios
$HOME de los usuarios en busca de estos ficheros, eliminándolos si los encontramos. Un
shellscript que hace esto puede ser el siguiente:
#!/bin/sh
for i in `cat /etc/passwd |awk -F: '{print $6}'`; do
cd $i
if [ -f .rhosts ]; then
echo "$i/.rhosts detectado"|mail -s "rhosts" root
rm -f $i/.rhosts
fi
done
Este programa envía un correo al
root en caso de encontrar un fichero
.rhosts, y lo elimina; podemos planificarlo mediante
cron para que se ejecute, por ejemplo, cada cinco minutos (la forma de planificarlo depende del clon de Unix en el que trabajemos, por lo que se recomienda consultar la página del manual de
cron o
crond).
El fichero .netrc
El mecanismo de autenticación que acabamos de ver sólo funciona con las órdenes
r* de Unix BSD; la conexión vía
ftp seguirá solicitando un nombre de usuario y una clave para acceder a sistemas remotos. No obstante, existe una forma de automatizar
ftp para que no solicite estos datos, y es mediante el uso de un archivo situado en el directorio
$HOME de cada usuario (en la máquina desde donde se invoca a
ftp, no en la servidora) y llamado
.netrc. En este fichero se pueden especificar, en texto claro, nombres de máquina, nombres de usuario y contraseñas de sistemas remotos, de forma que al conectar a ellos la transferencia de estos datos se realiza automáticamente, sin ninguna interacción con el usuario. Por ejemplo, imaginemos que el usuario
`root' del sistema
luisa conecta habitualmente a
rosita por
ftp, con nombre de usuario
`toni'; en su
$HOME de
luisa puede crear un fichero
.netrc como el siguiente:
luisa:~# cat $HOME/.netrc
machine rosita
login toni
password h/l0&54
luisa:~#
Si este archivo existe, cuando conecte al sistema remoto no se le solicitarán ningún nombre de usuario ni contraseña:
luisa:~# ftp rosita
Connected to rosita.
220 rosita FTP server (Version wu-2.6.0(1) Thu Oct 21 12:27:00 EDT 1999) ready.
331 Password required for toni.
230 User toni logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
La existencia de ficheros
.netrc en los
$HOME de los usuarios se puede convertir en un grave problema de seguridad: si un atacante consigue leer nuestro fichero
.netrc, automáticamente obtiene nuestro nombre de usuario y nuestra clave en un sistema remoto. Por tanto, no es de extrañar que para que el mecanismo funcione correctamente, este fichero sólo puede ser leído por su propietario; si no es así, no se permitirá el acceso al sistema remoto (aunque los datos de
.netrc sean correctos):
luisa:~# ftp rosita
Connected to rosita.
220 rosita FTP server (Version wu-2.6.0(1) Thu Oct 21 12:27:00 EDT 1999) ready.
Error - .netrc file not correct permissions.
Remove password or correct mode (should be 600).
ftp>
Existe una diferencia abismal entre el uso de
.rhosts y el de
.netrc; en el primer caso al menos conseguimos que nuestra clave no se envíe a través de la red, pero mediante
.netrc lo único que conseguimos es no tener que teclear la clave y el
login explícitamente: se envían de forma automática. Además de esto, si alguien consigue privilegios de administrador en la máquina cliente, podrá leer los posibles archivos
.netrc que sus usuarios posean; por tanto, este mecanismo sólo se ha de utilizar para conexiones a sistemas remotos como usuario anónimo (
anonymous o
ftp). Quizás nos convenga rastrear periódicamente los directorios de conexión de nuestros usuarios en busca de archivos
.netrc, por ejemplo mediante un
shellscript muy similar al que hemos visto para buscar ficheros
.rhosts.
El fichero /etc/inetd.conf
Este fichero es el utilizado por el demonio
inetd, conocido como el superservidor de red. El demonio
inetd es el encargado de ofrecer la mayoría de servicios de nuestro equipo hacia el resto de máquinas, y por tanto debemos cuidar mucho su correcta configuración. Posteriormente hablaremos de cómo restringir servicios, tanto ofrecidos por este demonio como servidos independientemente.
Cada línea (excepto las que comienzar por
`#', que son tratadas como comentarios) del archivo
/etc/inetd.conf le indica a
inetd cómo se ha de comportar cuando recibe una petición en cierto puerto; en cada una de ellas existen al menos seis campos (en algunos clones de Unix pueden ser más, como se explica en [SH95]), cuyo significado es el siguiente:
- Servicio
Este campo indica el nombre del servicio asociado a la línea correspondiente de
/etc/inetd.conf; el nombre ha de existir en /etc/services para ser considerado correcto, o en /etc/rpc si se trata de servicios basados en el RPC (Remote Procedure Call) de Sun Microsystems. En este último caso se ha de acompañar el nombre del servicio con el número de versión RPC, separando ambos con el carácter `/'.
- Socket
Aquí se indica el tipo de socket asociado a la conexión. Aunque dependiendo del clon de Unix utilizado existen una serie de identificadores válidos, lo normal es que asociado al protocolo TCP se utilicen sockets de tipo stream, mientras que si el protocolo es UDP el tipo del socket sea dgram (datagrama).
- Protocolo
El protocolo debe ser un protocolo definido en /etc/protocols, generalmente TCP o UDP. Si se trata de servicios RPC, de nuevo hay que indicarlo utilizando rpc antes del nombre del protocolo, separado de él por el carácter `/' al igual que sucedía con el nombre; por ejemplo, en este caso podríamos tener protocolos como rpc/tcp o rpc/udp.
- Concurrencia
El campo de concurrencia sólamente es aplicable a sockets de tipo datagrama (dgram); el resto de tipos han de contener una entrada nowait en este campo. Si el servidor que ha de atender la petición es multihilo (es decir, puede anteder varias peticiones simultáneamente), hemos de indicarle al sistema de red que libere el socket asociado a una conexión de forma que inetd pueda seguir aceptando peticiones en dicho socket; en este caso utilizaremos la opción nowait. Si por el contrario se trata de un servidor unihilo (acepta peticiones de forma secuencial, hasta que no finaliza con una no puede escuchar la siguiente) especificaremos wait.
Especificar correctamente el modelo de concurrencia a seguir en un determinado servicio es importante para nuestra seguridad, especialmente para prevenir ataques de negación de servicio (DoS). Si especificamos wait, inetd no podrá atender una petición hasta que no finalice el servicio de la actual, por lo que si este servicio es muy costoso la segunda petición no será servida en un tiempo razonable (o incluso nunca, si inetd se queda bloqueado por cualquier motivo). Si por el contrario especificamos nowait, el número de conexiones simultáneas quizás llegue a ser lo suficientemente grande como para degradar las prestaciones del sistema, lo que por supuesto no es conveniente para nosotros. Para evitar ataques de este estilo, la mayoría de sistemas Unix actuales permiten especificar (junto a wait o nowait, separado de él por un punto) el número máximo de peticiones a un servicio durante un intervalo de tiempo (generalmente un minuto), de forma que si este número se sobrepasa inetd asume que alguien está intentando una negación de servicio contra él, por lo que deja de ofrecer ese servicio durante cierto tiempo (algunos clones de Unix incluso paran inetd, es conveniente consultar la documentación en cada caso). Como evidentemente esto también es una negación de servicio, algo muy común entre administradores es aprovechar las facilidades de planificación de Unix para enviar cada poco tiempo la señal SIGHUP al demonio inetd, de forma que este relea su fichero de configuración y vuelva a funcionar normalmente. Por ejemplo, para conseguir esto podemos añadir a nuestro fichero crontab una línea como la siguiente:00,10,20,30,40,50 * * * * pkill -HUP inetd
Con esto conseguimos que inetd se reconfigure cada diez minutos (el equivalente a pkill en ciertos Unices es killall, pero es recomendable consultar el manual para asegurarse de lo que esta orden provoca).
- Usuario
En este campo se ha de indicar el nombre de usuario bajo cuya identidad se ha de ejecutar el programa que atiende cada servicio; esto es así para poder lanzar servidores sin que posean los privilegios del root, con lo que un posible error en su funcionamiento no tenga consecuencias excesivamente graves. Para el grupo, se asume el grupo primario del usuario especificado, aunque se puede indicar un grupo diferente indicándolo junto al nombre, separado de éste por un punto.
- Programa
Por último, en cada línea de /etc/inetd.conf hemos de indicar la ruta del programa encargado de servir cada petición que inetd recibe en un puerto determinado, junto a los argumentos de dicho programa. El servidor inetd es capaz de ofrecer pequeños servicios basado en TCP por sí mismo, sin necesidad de invocar a otros programas; ejemplos de este tipo de servicios son time, echo o chargen. En este caso, el valor de este campo ha de ser internal.
De esta forma, si en
/etc/inetd.conf tenemos una línea como
telnet stream tcp nowait root /usr/sbin/in.telnetd
entonces
inetd sabe que cuando reciba una petición al puerto
telnet ha de abrir un
socket tipo
stream (el habitual para el protocolo TCP) y ejecutar
fork() y
exec() del programa
/usr/sbin/in.telnetd, bajo la identidad de
root.
