Seguridad en Unix y Redes
Libro en Formato HTML y PDF de seguridad informática realizado por Antonio Villalon Huerta

Los contenidos pueden estar desactualizados con respecto al original

Este documento se encuentra disponible también en formato PDF

El sistema de red


next up previous contents
Siguiente: Algunos servicios y protocolos Subir: Seguridad de la subred Anterior: Seguridad de la subred   Índice General

Subsecciones

El sistema de red

Introducción

Por sistema de red de un equipo Unix se entiende el conjunto de software que posibilita la interconexión entre diferentes máquinas. Este software está dividido en dos espacios: por un lado, tenemos el soporte de red dentro del kernel del sistema operativo, encargado de implementar las tareas de más bajo nivel necesarias para la comunicación entre sistemas, como la pila de protocolos TCP/IP o los controladores de tarjetas de red; por otro, ya en el espacio de usuario, tenemos el conjunto de programas y ficheros utilizados para configurar parámetros del sistema relacionados con la red, como la dirección IP, las tablas de rutado, o el comportamiento de una máquina ante solicitudes de servicio desde otros equipos conectados lógicamente a ella.

En este trabajo vamos a hablar exclusivamente de este software de usuario (tanto utilidades como ficheros) que de una u otra forma puede afectar a la seguridad global del equipo. Se trata de una pequeña - muy pequeña - introducción a esta parte del sistema de red en Unix, sin entrar en ningún detalle; para temas más concretos, como la configuración del soporte de red en núcleo, la configuración de interfaces de red, servicios de nombres o la configuración de las tablas de rutado, se puede consultar [Fri95], [Hun92], [NSS89] o, en el caso de máquinas Linux, [Kir95].

Algunos ficheros importantes

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.

Algunas órdenes importantes

La orden ifconfig

La orden ifconfig se utiliza para configurar correctamente los interfaces de red de nuestro sistema Unix; habitualmente con ifconfig se indican parámetros como la dirección IP de la máquina, la máscara de la red local o la dirección de broadcast. Si como parámetros se recibe únicamente un nombre de dispositivo, ifconfig nos muestra su configuración en este momento:
anita:/# ifconfig nei0
nei0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
        inet 192.168.0.3 netmask ffffff00 broadcast 192.168.0.255
        ether 0:20:18:72:45:ad 
anita:/#
Ya hemos dicho que aquí no vamos a hablar de la configuración de estos dispositivos, sino de sus consideraciones de seguridad. Podemos utilizar ifconfig para detectar un funcionamiento anómalo de la tarjeta de red; este `funcionamiento anómalo' suele ser la causa (siempre en cuanto a seguridad se trata) de uno de los tres siguientes problemas:
  • Dirección IP incorrecta.
    Es posible que alguien esté realizando un ataque de tipo IP Spoofing utilizando nuestro sistema: si utilizamos la dirección IP de otro equipo, las peticiones que irían a él van a llegar a nosotros14.2. Estamos suplantando su identidad, hecho que un atacante puede aprovechar para capturar todo tipo de información (desde claves hasta correo electrónico).
  • Dirección MAC incorrecta.
    Esto puede denotar un ataque similar al anterior, pero más elaborado: estamos suplantando la identidad de otro equipo no sólo a nivel de IP, sino a nivel de dirección MAC. Cuando esto sucede, casi con toda seguridad se acompaña de un IP Spoof para conseguir una suplantación que no sea tan fácil de detectar como el IP Spoof a secas.
  • Tarjeta en modo promiscuo.
    Alguien ha instalado un sniffer en nuestro sistema y ha puesto la tarjeta de red en modo promiscuo, para capturar todas las tramas que ésta `ve'. Es un método muy utilizado por atacantes que han conseguido privilegio de superusuario en la máquina (es necesario ser root para situar a la tarjeta en este modo de operación) y se está dedicando a analizar el tráfico de la red en busca de logins y claves de usuarios de otros equipos.

La orden route

Este comando se utiliza para configurar las tablas de rutado del núcleo de nuestro sistema. Generalmente en todo equipo de una red local tenemos al menos tres rutas: la de loopback, utilizando el dispositivo de bucle interno (lo, lo0...), la de red local (localnet), que utiliza la tarjeta de red para comunicarse con equipos dentro del mismo segmento de red, y una default que también utiliza la tarjeta para enviar a un router o gateway paquetes que no son para equipos de nuestro segmento. Si no se especifica ningún parámetro, route muestra la configuración actual de las tablas de rutado14.3:
andercheran:~# route
Kernel routing table
Destination   Gateway          Genmask        Flags  MSS    Window  Use Iface
localnet      *                255.255.0.0    U      1500   0       16  eth0
loopback      *                255.0.0.0      U      3584   0       89  lo
default       atlas.cc.upv.es  *              UG     1500   0       66  eth0
andercheran:~#
Si route nos muestra una configuración sospechosa (esto es, las tablas no son las que en el sistema hemos establecido como administradores, aunque todo funcione correctamente) esto puede denotar un ataque de simulación: alguien ha desviado el tráfico por un equipo que se comporta de la misma forma que se comportaría el original, pero que seguramente analiza toda la información que pasa por él. Hemos de recalcar que esto suele ser transparente al buen funcionamiento del equipo (no notamos ni pérdida de paquetes, ni retardos excesivos, ni nada sospechoso), y que además el atacante puede modificar los ficheros de arranque del sistema para, en caso de reinicio de la máquina, volver a tener configuradas las rutas a su gusto; estos ficheros suelen del tipo /etc/rc.d/rc.inet1 o /etc/rc?.d/Sinet.

También es posible que alguien esté utilizando algún elemento utilizado en la conexión entre nuestro sistema y otro (un router, una pasarela...) para amenazar la integridad de nuestro equipo; si queremos comprobar el camino que siguen los paquetes desde que salen de la máquina hasta que llegan al destino, podemos utilizar la orden traceroute. Sin embargo, este tipo de ataques es mucho más difícil de detectar, y casi la única herramienta asequible para evitarlos es la criptografía.

La orden netstat

Esta orden se utiliza para visualizar el estado de diversas estructuras de datos del sistema de red, desde las tablas de rutado hasta el estado de todas las conexiones a y desde nuestra máquina, pasando por las tablas ARP, en función de los parámetros que reciba.

En temas referentes a la seguridad, netstat se suele utilizar, aparte de para mostrar las tablas de rutado de ciertos sistemas (con la opción -r, como hemos visto antes), para mostrar los puertos abiertos que escuchan peticiones de red y para visualizar conexiones a nuestro equipo (o desde él) que puedan salirse de lo habitual. Veamos un ejemplo de información mostrada por netstat: 
anita:/# netstat -P tcp -f inet -a
TCP
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q  State
-------------------- -------------------- ----- ------ ----- ------ -------
      *.*                  *.*                0      0     0      0 IDLE
      *.sunrpc             *.*                0      0     0      0 LISTEN
      *.*                  *.*                0      0     0      0 IDLE
      *.32771              *.*                0      0     0      0 LISTEN
      *.ftp                *.*                0      0     0      0 LISTEN
      *.telnet             *.*                0      0     0      0 LISTEN
      *.finger             *.*                0      0     0      0 LISTEN
      *.dtspc              *.*                0      0     0      0 LISTEN
      *.lockd              *.*                0      0     0      0 LISTEN
      *.smtp               *.*                0      0     0      0 LISTEN
      *.8888               *.*                0      0     0      0 LISTEN
      *.32772              *.*                0      0     0      0 LISTEN
      *.32773              *.*                0      0     0      0 LISTEN
      *.printer            *.*                0      0     0      0 LISTEN
      *.listen             *.*                0      0     0      0 LISTEN
      *.32774              *.*                0      0     0      0 LISTEN
      *.*                  *.*                0      0     0      0 IDLE
      *.6000               *.*                0      0     0      0 LISTEN
      *.32775              *.*                0      0     0      0 LISTEN
localhost.32777      localhost.32775      32768      0 32768      0 ESTABLISHED
localhost.32775      localhost.32777      32768      0 32768      0 ESTABLISHED
localhost.32780      localhost.32779      32768      0 32768      0 ESTABLISHED
localhost.32779      localhost.32780      32768      0 32768      0 ESTABLISHED
localhost.32783      localhost.32775      32768      0 32768      0 ESTABLISHED
localhost.32775      localhost.32783      32768      0 32768      0 ESTABLISHED
localhost.32786      localhost.32785      32768      0 32768      0 ESTABLISHED
localhost.32785      localhost.32786      32768      0 32768      0 ESTABLISHED
localhost.32789      localhost.32775      32768      0 32768      0 ESTABLISHED
localhost.32775      localhost.32789      32768      0 32768      0 ESTABLISHED
localhost.32792      localhost.32791      32768      0 32768      0 ESTABLISHED
localhost.32791      localhost.32792      32768      0 32768      0 ESTABLISHED
localhost.32810      localhost.6000       32768      0 32768      0 ESTABLISHED
localhost.6000       localhost.32810      32768      0 32768      0 ESTABLISHED
anita.telnet         luisa.2039           16060      0 10136      0 ESTABLISHED
anita.telnet         bgates.microsoft.com.1068 15928 0 10136      0 ESTABLISHED
localhost.32879      localhost.32775      32768      0 32768      0 TIME_WAIT
      *.*                  *.*                0      0     0      0 IDLE
anita:/#
Por un lado, en este caso vemos que hay bastantes puertos abiertos, esto es, escuchando peticiones: todos los que presentan un estado LISTEN, como telnet, finger o smtp (si es un servicio con nombre en /etc/services se imprimirá este nombre, y si no simplemente el número de puerto). Cualquiera puede conectar a este servicio (como veremos en el siguiente punto) y, si no lo evitamos mediante TCP Wrappers, utilizarlo para enviarle peticiones.

Aparte de estos puertos a la espera de conexiones, vemos otro gran número de conexiones establecida entre nuestro sistema y otros (como antes hemos dicho, desde nuestro equipo o hacia él); casi todas las establecidas (estado ESTABLISHED) son de nuestra máquina contra ella misma, lo que a priori no implica consecuencias de seguridad. Otra de ellas es desde un equipo de la red local contra nuestro sistema, lo que también es bastante normal y no debe hacernos sospechar nada14.4; sin embargo, hay una conexión que sí puede indicar que alguien ha accedido a nuestro sistema de forma no autorizada: si nos fijamos, alguien conecta por telnet desde la máquina bgates.microsoft.com. Es raro que tengamos a un usuario allí, por lo que deberíamos monitorizar esta conexión y las actividades que esta persona realice; es muy probable que se trate de alguien que ha aprovechado la inseguridad de ciertos sistemas para utilizarlos como plataforma de ataque contra nuestros Unix.

La orden ping

El comando ping se utiliza generalmente para testear aspectos de la red, como comprobar que un sistema está encendido y conectado; esto se consigue enviando a dicha máquina paquetes ICMP (de tipo ECHO/SMALL>_REQUEST), tramas que causarán que el núcleo del sistema remoto responda con paquetes ICMP, pero esta vez de tipo ECHO/SMALL>_RESPONSE. Al recibirlos, se asume que la máquina está encendida:
 
anita:~# ping luisa
luisa is alive
anita:~#
En otras variantes de Unix (el ejemplo anterior es sobre Solaris) la orden ping produce un resultado con más información:
luisa:~# ping -c 1 anita
PING anita (192.168.0.3): 56 data bytes
64 bytes from 192.168.0.3: icmp_seq=0 ttl=255 time=0.2 ms

--- luisa ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
luisa:~#
Aunque un simple ping resulta inofensivo en la mayoría de situaciones, existen casos en los que se puede utilizar como un arma - efectiva - para atacar sistemas; por ejemplo, uno de los ataques más conocidos es el Ping Flood, consistente en saturar una línea lenta con un número de paquetes ICMP suficientemente grande. Esta saturación causará una degradación del servicio importante, incluso la desconexión del sistema si se ataca una línea telefónica (un objetivo muy habitual para los piratas). En este último caso, el de conexiones telefónicas, otro ataque común - no directamente relacionado con ping, pero en el que se usa esta herramienta como base - consiste en enviar una trama `especial' a un módem, obligándole a finalizar la llamada: los módems conmutan a modo comando cuando reciben la orden `+++', y muchos de ellos lo hacen también al recibir remotamente esta secuencia de control. Así, podemos conectar a un puerto donde se ofrezca determinado servicio (como FTP o SMTP) en un host con un módem de estas características y colgar el módem remoto sin levantarnos de la silla, simplemente enviando la cadena `+++' seguida de una orden de colgado como `ATH0':
luisa:~# telnet XXX.XXX.X.XX 21
Trying XXX.XXX.X.XX...
Connected to XXX.XXX.X.XX.
Escape character is '^]'.
220 gema FTP server (Version wu-2.4.2-academ[BETA-15](1) Fri Oct 22 
00:38:20 CDT 1999) ready.
USER +++ATH0
^]
telnet> close
Connection closed.
luisa:~# telnet XXX.XXX.X.XX
Trying XXX.XXX.X.XX...
telnet: Unable to connect to remote host: Network is unreachable
luisa:~#
Bien pero, >dónde entra ping en este ataque? Muy sencillo: al conectar a un servicio para enviar la cadena de caracteres, lo habitual es que el sistema remoto registre la conexión, aunque luego su módem cuelgue. En cambio, muy pocos sistemas registran en los logs un simple ping, por lo que esta orden se convierte en un mecanismo que algunos piratas utilizan para no dejar rastro de sus acciones; esto se consigue de una forma muy sencilla: en la utilidad ping de la mayoría de Unices existe un parámetro que permite especificar el contenido del paquete enviado (por ejemplo, `-p' en Linux), por lo que simplemente hemos de insertar (en hexadecimal) la cadena `+++ATH0' en la trama que enviamos al sistema remoto:
luisa:~# ping -c 1 XXX.XXX.X.XX
PING XXX.XXX.X.XX (XXX.XXX.X.XX): 56 data bytes
64 bytes from XXX.XXX.X.XX: icmp_seq=0 ttl=255 time=0.2 ms

--- XXX.XXX.X.XX ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 6.5/6.5/6.5 ms
luisa:~# ping -p 2b2b2b415448300d XXX.XXX.X.XX
PING XXX.XXX.X.XX (XXX.XXX.X.XX): 56 data bytes

^C
--- XXX.XXX.X.XX ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
luisa:~# telnet XXX.XXX.X.XX
Trying XXX.XXX.X.XX...
telnet: Unable to connect to remote host: Network is unreachable
luisa:~#
Para evitar los problemas relacionados con los paquetes ICMP que sistemas remotos puedan enviar a nuestra máquina puede ser conveniente filtrar dicho protocolo mediante un cortafuegos (incluso situado en el propio equipo); si no tenemos esta posibilidad, al menos es interesante registrar las tramas de este tipo que llegan hasta nuestra máquina, con programas como icmpinfo (si hacemos esto, hemos de tener cuidado con las negaciones de servicio ocasionadas por una cantidad de logs excesiva en el disco duro).

Ah, si es nuestro módem el que presenta el problema que acabamos de comentar, podemos solucionarlo mediante la cadena de inicialización `s2=255'.

La orden traceroute

Esta orden se utiliza para imprimir la ruta que los paquetes siguen desde nuestro sistema hasta otra máquina; para ello utiliza el campo TTL (Time To Live) del protocolo IP, inicializándolo con valores bajos y aumentándolo conforme va recibiendo tramas ICMP de tipo TIME/SMALL>_EXCEEDED. La idea es sencilla: cada vez que un paquete pasa por un router o una pasarela, esta se encarga de decrementar el campo TTL en una unidad; en el caso de que se alcance un valor 0, se devuelve un paquete TIME/SMALL>_EXCEEDED y se descarta la trama. Así, traceroute inicializa a 1 este campo, lo que ocasiona que el primer router encontrado ya devuelva el mensaje de error; al recibirlo, lo inicializa a 2, y ahora es el segundo router el que descarta el paquete y envía otro mensaje de error, y así sucesivamente. De esta forma se va construyendo la ruta hasta un determinado host remoto:
luisa:~# traceroute www.altavista.com
traceroute to altavista.com (204.152.190.70), 30 hops max, 40 byte packets
 1  annex4.net.upv.es (158.42.240.191)  156.251 ms  144.468 ms  139.855 ms
 2  zaurac-r.net.upv.es (158.42.240.250)  159.784 ms  149.734 ms  149.809 ms
 3  atlas.cc.upv.es (158.42.1.10)  149.881 ms  149.717 ms  139.853 ms
 4  A1-0-3.EB-Valencia1.red.rediris.es (130.206.211.185)  149.863 ms  
    150.088 ms  149.523 ms
 5  A0-1-2.EB-Madrid00.red.rediris.es (130.206.224.5)  189.749 ms  
    159.698 ms  180.138 ms
 6  A6-0-0-1.EB-Madrid0.red.rediris.es (130.206.224.74)  179.518 ms  
    159.678 ms  189.897 ms
 7  194.69.226.13 (194.69.226.13)  259.752 ms  249.664 ms  259.83 ms
 8  * * 195.219.101.1 (195.219.101.1)  290.772 ms
 9  195.219.96.34 (195.219.96.34)  1680.33 ms  1660.36 ms  1669.83 ms
10  * 195.66.225.76 (195.66.225.76)  1660.68 ms  1650.33 ms
11  core1-linx-oc3-1.lhr.above.net (216.200.254.81)  2009.88 ms  1970.32 ms *
12  iad-lhr-stm4.iad.above.net (216.200.254.77)  2050.68 ms * *
13  sjc-iad-oc12-2.sjc.above.net (216.200.0.22)  2440.89 ms  2170.29 ms  
    2579.81 ms
14  pao-sjc-oc12-2.pao.above.net (207.126.96.65)  2441.19 ms  2140.32 ms *
15  mibh-above-oc3.pao.mibh.net (216.200.0.10)  2200.57 ms * *
16  * * www.altavista.com (204.152.190.70)  1810.56 ms
luisa:~#
traceroute se utiliza para realizar pruebas, medidas y administración de una red; introduce mucha sobrecarga, lo que evidentemente puede acarrear problemas de rendimiento, llegando incluso a negaciones de servicio por el elevado tiempo de respuesta que el resto de aplicaciones de red pueden presentar. Además, se trata de un programa contenido en un fichero setuidado, por lo que es interesante resetear el bit de setuid de forma que sólo el root pueda ejecutar la orden: hemos de pensar que un usuario normal rara vez tiene que realizar pruebas sobre la red, por lo que el bit setuid de traceroute no es más que un posible problema para nuestra seguridad; aunque con ping sucede lo mismo (es un fichero setuidado), que un usuario necesite ejecutar traceroute es menos habitual que que necesite ejecutar ping (de cualquier forma, también podríamos resetear el bit setuid de ping).


Servicios

Los servicios ofrecidos por una máquina al resto suelen ser uno de los principales puntos de ataque contra esa máquina; estos ataques pueden implicar desde negaciones de servicio (DoS, Denial of Service) más o menos graves hasta un acceso root remoto sin necesidad de ninguna clave.

Hay dos formas básicas de ofrecer un servicio: o mediante inetd, o bien lanzando un demonio que se asocia y escucha en cierto puerto, generalmente en el arranque del sistema. Por norma general se recomienda ofrecer el mínimo número de servicios; incluso si hay algún servicio que no sabemos para qué se utiliza, lo mejor para nuestra seguridad sería dejar de ofrecerlo.

Dejar de ofrecer cierto servicio en máquinas Unix es muy sencillo; no necesitamos reiniciar el sistema para que los cambios tengan efecto ni nada por el estilo: con un simple editor de textos podemos limitar los servicios ofrecidos. En el caso de servicios ofertados a través de inetd, no tenemos más que editar /etc/inetd.conf y comentar las líneas correspondientes a los servicios a cerrar (los comentarios en ficheros de configuración de Unix suelen ser lineales, utilizando el símbolo #). Después de comentar las líneas correspondientes hemos de reiniciar el demonio inetd enviándole la señal SIGHUP (con órdenes como kill, pkill o killall). En el caso de demonios independientes lanzados durante el arranque del sistema no tenemos más que enviarles la señal SIGTERM (por norma general, aunque en algunos casos quizás es necesaria SIGKILL), y también editar los ficheros que lanzen estos demonios y comentar las líneas encargadas de la inicialización, para que no se vuelvan a lanzar la próxima vez que la máquina arranque; generalmente se tratará de archivos situados en /etc/rc.d/ o en /etc/rc?.d/.

Veamos un ejemplo: imaginemos que en nuestro /etc/inetd.conf tenemos la línea del servicio de telnet que hemos mostrado anteriormente. En este caso, si alguien ejecuta un telnet a nuestro sistema, verá algo parecido a esto:
rosita:~$ telnet anita
Trying 192.168.0.3...
Connected to anita.
Escape character is '^]'.

SunOS 5.7

login:
Si esta línea de /etc/inetd.conf la sustituimos por 
#telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd
y a continuación ejecutamos pkill -HUP inetd, cuando alguien haga un telnet a nuestra máquina verá esto:
rosita:~$ telnet anita 
Trying 192.168.0.3...
telnet: Unable to connect to remote host: Connection refused
rosita:~$
Demonios típicos que se lanzan desde inetd son in.telnetd (para recibir peticiones telnet), in.ftpd (para peticiones ftp), in.talkd (para peticiones talk), in.fingerd (para finger remoto) o in.r, para los servicios r- de Unix BSD. Demonios que se suelen lanzar en el arranque del sistema son sendmail (gestión de correo electrónico), httpd (servicio http), lpd (demonio de impresión), inetd (recordemos que es un demonio que también se ha de iniciar en el arranque) o nfsd (para compartir sistemas de ficheros mediante NFS); algunos de estos conviene servirlos desde inetd en lugar de como demonios independientes, por motivos de seguridad que ya veremos al hablar de TCP Wrappers.

Hasta ahora hemos hablado de dos formas de ofrecer un servicio: o bien a través de inetd, o bien como demonio independiente lanzado al arrancar el sistema; realmente, existe una tercera forma de ofrecer servicios, y es el mecanismo RPC (Remote Procedure Call), original de Sun Microsystems pero que en la actualidad está implementado también por OSF (Open Software Foundation) en su DCE (Distributed Computing Environment) y por OMG (Open Management Group) en CORBA (Common Object Request Broker Architecture). La idea básica del funcionamiento de RPC es sencilla: existe un programa denominado portmap, rpcbind, rpc.portmap... (su nombre depende del clon de Unix utilizado) que los servidores RPC utilizan para registrarse. Así, cuando un cliente desea utilizar esos servicios, en lugar de conectar a un puerto determinado donde se encuentre el servidor lo hace al puerto del portmapper, que le indicará la ubicación exacta del servidor solicitado. Como estos mecanismos pueden llegar a ser muy complejos no vamos a entrar en detalles de su seguridad; sólo decir que existe una versión de portmap desarrollada por Wietse Venema que utiliza un control de accesos similar a TCP Wrappers, lo que evidentemente va a ser muy útil para nuestra seguridad: sólo permitiremos conexiones RPC a los sistemas deseados, denegando el acceso al resto. Más detalles de la seguridad de RPC pueden encontrarse en el capítulo 19 de [GS96].

Cada puerto abierto en nuestro sistema representa una puerta de entrada al mismo, por lo que como hemos dicho, hemos de minimizar su número ofreciendo sólo los servicios estrictamente necesarios. Por ejemplo, si ofrecemos el servicio telnet, cualquier persona, desde cualquier parte del mundo, podrá acceder a nuestra máquina simplemente conociendo (o adivinando) un nombre de usuario y su clave; si ofrecemos el servicio netstat, cualquiera podrá consultar las conexiones activas de nuestra red simplemente tecleando telnet maquina.dominio.com netstat, desde cualquier ordenador conectado a la red. Pero no sólo nos tenemos que limitar a cerrar servicios: hay algunos que, como administradores de un sistema, no vamos a tener más remedio que ofrecer; en este caso es casi obligatorio restringir su disponibilidad a un número de máquinas determinado, como veremos al hablar de TCP Wrappers, y por supuesto utilizar la última versión de los demonios encargados de procesar las peticiones: un demonio no es más que un programa, y por supuesto es muy difícil que esté completamente libre de errores. Un error en el demonio que utilicemos para procesar una petición puede comprometer la seguridad de todo nuestro sistema, por lo que se recomienda estar atento a listas de seguridad (como BUGTRAQ o CERT) en las que se difundan problemas de seguridad y sus soluciones.
next up previous contents
Siguiente: Algunos servicios y protocolos Subir: Seguridad de la subred Anterior: Seguridad de la subred   Índice General
2002-07-15