Guía de Seguridad del Administrador de Linux - NFSD

NFS significa Sistema de Ficheros de Red, Netork File System, y es sencillamente eso, una buena forma de distribuir sistemas de ficheros, de sólo lectura y lectura/escritura, mientas se conserva un grado de seguridad y de control suponiendo que la red está cerrada y es segura. El NFS se pensó para ser utilizado en entornos con un gran ancho de banda (p. ej., en una LAN), en la cual los riesgos de seguridad no son altos, o la información que se comparte no es sensible (p. ej., una LAN pequeña y fiable detrás de un cortafuegos intercambiando diagramas de CAD/CAM, o un gran laboratorio de una universidad, que utilice el nfs para montar el /usr/. Si se necesita un alto nivel de seguridad, tal como el cifrado de datos entre hosts, el NFS no es la mejor elección. Personalmente lo utilizo dentro de mi LAN interna (la máquina tiene 2 interfaces, adivina cuál es la que tiene los filtros del cortafuegos más severos), para compartir sistemas de ficheros que contienen rpm’s, este sitio web, etc. Alternativas más seguras incluyen el SAMBA (gratuito) y ahora IBM está portando el AFS a Linux (costoso, pero el AFS es un buen trozo de código).

El NFS tiene algunos controles de seguridad rudimentarios. El primero sería el filtrado mediante cortafuegos; en cualquier caso, utilizar NFS a través de una red grande, lenta y pública como Internet no una buena idea, de modo que hay que filtrar el puerto 2049, UDP. Puesto que el NFS se ejecuta como un conjunto de demonios, los TCP_WRAPPERS no son útiles, a menos que se haya compilado el NFS para soportarlos. El fichero de configuración del NFS tiene unas cuantas directivas, un montón de las cuales tratan de las configuraciones de id del usuario y grupo (mapear todo el mundo a nobody, quizás mapear todos los motores clientes a "motor", etc, etc.) pero no existen mecanismos de autentificación reales (que tu cliente diga tener UID 0, que es por lo que el id del root se limita por defecto a nobody). Las exportaciones del NFS de sólo lectura son bastante seguras, sólo hay que preocuparse de que la gente equivocada sea la que le eche un vistazo a tu información (si ésta es sensible) y/o creen ataques de negación de servicio (pongamos que tienes un directorio legible por el mundo/etc para compartir los fuentes del kernel, y algún tipejo empieza a succionar datos como un loco…).

Las exportaciones de escritura son harina de otro costal, y se deberían utilizar con extrema precaución, puesto que la única "autentificación" está basada en IP/nombre de host (ambas fácilmente sujetas a spoofing), y UID (tú mismo puedes ejecutar Linux y ser UID 0). Viene un cliente con un ataque DOS, toma su IP, monta el compartido con permiso de escritura y se va para casa. Te dices "pero tendría que haber conocido la IP y el UID", amigos, el sniffing de paquetes no es una ciencia aeroespacial, ni lo es el "showmount".

De modo que, ¿cómo se asegura el NFS? Lo primero que hay que hacer es filtrarlo con el cortafuegos, especialmente si la máquina es del tipo multi-homed, con un interfaz conectado a una red públicamente accesible (Internet, el laboratorio de estudiantes, etc.). Si se está pensando en ejecutar NFS sobre una red pública, es mejor que sea de sólo lectura, y definitivamente se estará mejor con un producto diferente a NFS.

Lo segundo y la parte más interesante es el fichero /etc/exports. Controla qué es lo que se les permite hacer a los clientes, y cómo lo hacen.

Un fichero exports de ejemplo:

# Permitir a una estación de trabajo editar el contenido web

/www 10.0.0.11(rw,no_root_squash)

#

# Otro compartido que permita a un usuario editar un sitio web

/www/www.bobo.org 10.0.0.202(rw,no_root_squash)

#

# directorio ftp público

/home/ftp *.ejemplo.org(ro,all_squash)

La estructura del fichero exports es bastante simple, el directorio que se quiere exportar, el cliente (utiliza siempre IP’s, los nombres de hosts se pueden falsear), y cualquier opción. El cliente puede tener una única IP (10.0.0.1), nombre de host (tipejo.poncho.net), una subred (10.0.0.0/255.255.255.0), o un wildcard (*.abuelito.mil). Algunas de las directivas más interesantes (y útiles) del fichero de configuración son: secure – la sesión nfs se debe originar desde un puerto privilegiado, es decir, el root TIENE que ser el que esté intentando montar el directorio. Esto es útil si el servidor que se está exportando también está asegurado.

ro – uno bueno, Sólo Lectura, ya se ha hablado lo suficiente.

noaccess – utilizado para cortar el acceso, p. ej. exportar /home/ pero poner como noaccess el /home/root

root_squash - limita el UID del root a la UID/GID del usuario anónimo (normalmente "nobody"), muy útil si se están exportando los directorios a servidores de administradores en los que no se confía al 100% (el root casi siempre puede leer cualquier fichero…PISTA)

no_root_squash – útil si se quiere perder el tiempo en directorios exportados como root para arreglar cosas (como los permisos del site www)

squash_uids y squash_gids – limitar ciertos UID(s) o GID(s) a los del usuario anónimo, en Red Hat un buen ejemplo sería 500-10000 (por defecto, Red Hat comienza a añadir usuarios y grupos en el 500), permitiendo a cualquier usuario con UID’s más bajas (p. ej. cuentas especiales) acceder a cosas en especial.

all_squash – uno bueno, todos los privilegios se eliminan y todo el mundo es guest.

anonuid y anongid – configuran específicamente el UID / GID del usuario anónimo (quizás se quiera algo especial como "anonnfs").

En realidad, la página man exports es bastante buena.

Más allá de esto no hay mucho que asegurar en NFS, aparte de eliminarlo y sustituirlo por algún otro producto (como AFS, Coda, etc). El NFS es relativamente robusto, casi cualquier sabor de Unix lo soporta, y suele ser fácil de configurar, trabajar y mantener. También es "un viejo conocido", que ha estado entre nosotros durante mucho tiempo. Échale un vistazo a "Practical Unix and Internet Security", también ponen en negrita que no se utilice NFS si la seguridad es de especial interés.

El NFS se debería restringir al mundo exterior, se ejecuta en el puerto 2049, udp, al igual que utiliza RPC en el puerto 111, udp/tcp, y hace uso del mountd, que se ejecuta en el puerto 635, udp. Cambia el 2049 por el 111, y pon el 635 y tcp para asegurar esos servicios (de nuevo, la mejor idea es una regla en blanco para denegar los puertos 1 al 1024, o mejor aún, una política por defecto de denegación).

ipfwadm –I –a accept –P udp –S 10.0.0.0/8 –D 0.0.0.0/0 2049

ipfwadm –I –a accept –P udp –S un.host.fiable –D 0.0.0.0/0 2049

ipfwadm –I –a deny –P udp –S 0.0.0.0/0 –D 0.0.0.0/0 2049

o

ipchains –A input –p udp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 2049

ipchains –A input –p udp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 2049

ipchains –A input –p udp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 2049



tftp

El tftp (Protocolo Trivial de Transferencia de Ficheros, Trivial File Transfer Protocol) se utiliza en dispositivos que solicitan información desde un servidor de red, generalmente a la hora de arrancar. Es una forma extremadamente simple de ftp, con la mayoría de la seguridad y comandos avanzados eliminados, básicamente se utiliza casi en exclusiva por estaciones sin disco, datos de configuraciones de routers, y cualquier dispositivo que se arranque, y necesite información que no pueda almacenar permanentemente. Como tal, presenta un agujero de seguridad bastante grande, imagínate que alguien se conecta al servidor tftp y coge el fichero de arranque del router Cisco principal.