Me he encontrado con muchos servidores NFS completamente abiertos, que podrían hacerse un poco más seguros con un par de cambios rápidos. Esta es una guía rápida para hacer las cosas un poco más seguras. Esta no es una guía completa para asegurar NFS, pero puede hacer que las cosas sean un poco más seguras sin mucho esfuerzo. Para pasar a otro nivel, debe considerar la implementación de NFSv4 y Kerberos.
Las opciones básicas para las exportaciones pueden incluir:
- no_all_squash :esta opción deshabilita todos los aplastamientos.
- rw :esta opción permite que el servidor NFS utilice solicitudes de lectura y escritura en un volumen NFS.
- ro :esta opción permite que el servidor NFS utilice solicitudes de solo lectura en un volumen NFS.
- sincronizar :esta opción permite que el servidor NFS responda a las solicitudes solo después de que los cambios se hayan confirmado en un almacenamiento estable.
- asincrónico :esta opción permite que el servidor NFS infrinja el protocolo NFS y responda a las solicitudes antes de que los cambios se hayan confirmado en el almacenamiento estable.
- seguro :esta opción requiere que las solicitudes se originen en un puerto de Internet.
- inseguro :esta opción acepta cualquiera o todos los puertos.
- wretraso :esta opción permite que el servidor NFS retrase la confirmación de una solicitud de escritura en un disco si sospecha que otra solicitud de escritura relacionada puede estar en curso o puede llegar pronto.
- sin_wdelay :esta opción permite que el servidor NFS permita que varias solicitudes de escritura se confirmen en el disco en una sola operación. Esta función puede mejorar el rendimiento, pero si un servidor NFS recibe muchas solicitudes pequeñas, este comportamiento puede degradar el rendimiento. Debe tener en cuenta que esta opción no tiene ningún efecto si también se establece asíncrono.
- subtree_check :Esta opción activa la comprobación de subárboles.
- no_subtree_check :esta opción deshabilita la verificación de subárboles, lo que tiene algunos problemas de seguridad implícitos, pero puede mejorar la confiabilidad.
- anonuid=UID :estas opciones configuran explícitamente el uid y el gid de la cuenta anónima; esto puede ser útil cuando desea que todas las solicitudes aparezcan como si fueran de un solo usuario.
- anongid=GID :esta opción desactivará anonuid=UID.
¿Qué es root_squash?
root_squash permitirá que el usuario raíz del cliente acceda y cree archivos en el servidor NFS como raíz. Técnicamente hablando, esta opción obligará a NFS a cambiar la raíz del cliente a una ID anónima y, de hecho, esto aumentará la seguridad al evitar que la propiedad de la cuenta raíz en un sistema migre a otro sistema. Esto es necesario si aloja sistemas de archivos raíz en el servidor NFS (especialmente para clientes sin disco); con esto en mente, se puede usar (con moderación) para hosts seleccionados, pero no debe usar no_root_squash a menos que sea consciente de las consecuencias.
SUID y NFS
suid es un método en el que un usuario asume los derechos del propietario de un archivo cuando el usuario lo ejecuta. ¿Por qué me importa esto? Imagínese si un usuario pudiera copiar un archivo en el volumen NFS, habilitar suid bit en el archivo, luego ejecutarlo en el servidor NFS o el cliente, elevándose efectivamente a la raíz en el proceso.
Este es un ejemplo que demuestra los riesgos.
El nombre de host del servidor NFS es el servidor, el nombre de host del cliente NFS es el cliente. La subred de la red de ejemplo es 192.168.1.0/24. Este ejemplo también asume que ambos sistemas ejecutan las mismas versiones del sistema operativo (es decir, ambos son RHEL 7 o ambos son SLES 12), siempre que las versiones principales del sistema operativo coincidan.
1. En un servidor NFS, cree un directorio temporal (/exportar/prueba) y exporte con las siguientes opciones (sustituya 192.168.1.0/255.255.255.0 con su propia red/máscara de red):
server# vi /etc/exports /export/test 192.168.1.0/255.255.255.0(no_root_squash,insecure,rw)
2. Reinicie el servidor nfs. Esto varía según el sabor de Linux..
RHEL:
server# systemctl restart nfs
SUSE:
server# systemctl restart nfsserver
3. En la máquina cliente, monte la exportación:
client# mkdir /mnt/nfstest client# mount -t nfs server:/export/test /mnt/nfstest
4. En el cliente, como usuario raíz, copie el binario vi en el montaje NFS.
client# which vi —— output ——— /usr/bin/vi
client# cp /usr/bin/vi /mnt/nfstest
5. Configure el bit suid en el binario copiado.
client# chmod u+s /mnt/nfstest/vi
6. SSH en el servidor nfs como usuario sin privilegios. Como usuario sin privilegios, ejecute el vi ubicado en el montaje exportado en el servidor:
server$ /export/test/vi /etc/passwd
7. Busque la cuenta sin privilegios en el archivo de contraseñas y cambie el UID a 0, guarde, cierre la sesión y vuelva a iniciar sesión como usuario sin privilegios. El usuario ahora es root.
Lo mismo funcionará en el cliente, si ejecuta el vi desde el montaje NFS como un usuario normal, puede apuntarlo a cualquier archivo en el host y podrá editarlo como root. Funcionará con cualquier binario que se te ocurra.
¿Cómo evitar esto?
1. En primer lugar, elimine el archivo vi del directorio de exportación :), luego habilite root_squash en la exportación de nfs. En el servidor, edite /etc/exports nuevamente, modifique no_root_squash a root_squash:
server# vi /etc/exports /export/test 192.168.1.0/255.255.255.0(root_squash,insecure,rw)
2. Reinicie el servidor nfs, vuelva a montar el sistema de archivos en el cliente:
server# systemctl restart nfs
client# umount /mnt/test client# mount -t nfs server:/export/test /mnt/nfstest
3. Desde el cliente, como raíz, cree algunos archivos en el montaje NFS, verifique los permisos:
client# touch /mnt/nfstest/{test1,test2,test3} Según los permisos establecidos en /exportar/prueba, se le denegará el permiso o, si el directorio tiene permiso de escritura mundial, los permisos de los archivos serán similares a:
-rw-r--r-- 1 65534 65534 0 Nov 6 2015 test1 -rw-r--r-- 1 65534 65534 0 Nov 6 2015 test2 -rw-r--r-- 1 65534 65534 0 Nov 6 2015 test3
root_squash está reasignando el UID raíz para que sea el uid de un usuario anónimo. Este uid se puede configurar en el archivo de exportaciones, man /etc/exports para obtener más información. Copie el comando vi nuevamente (si está permitido) como root en el cliente al volumen nfs y repita los pasos anteriores (ssh al servidor ejecute vi en /etc/passwd). Esta vez no tendrá permiso para guardar el archivo, los permisos se elevan a una cuenta sin privilegios.
Eso es un poco más seguro, sin embargo, aún no hemos terminado. Otro paso que puede tomar es montar el sistema de archivos exportado en el servidor NFS con la opción nosuid.
server# vi /etc/fstab
4. Busque el punto de montaje para /exportar/, cambie los valores predeterminados de la columna de opciones a.
/dev/mapper/sys_vg-export_lv /export ext3 defaults 0 0 /dev/mapper/sys_vg-export_lv /export ext3 nosuid 0 0
5. Vuelva a montar la montura:
server# mount -o remount /export
6. Vuelque el archivo vi en el soporte, configure el bit suid, cambie a una cuenta sin privilegios y vuelva a intentarlo:
server# cp /usr/bin/vi /export/test; chmod u+s /export/test/vi
server# su - someuser server$ /export/test/vi /etc/passwd
Después de realizar un cambio en el archivo pasado, no se le permitirá guardar el cambio.
7. Vaya al cliente como usuario sin privilegios e intente lo mismo:
client$ /export/test/vi /etc/passwd
Todavía funciona, el cliente también debe volver a montarse con la opción nosuid:
client# mount -t nfs -o nosuid server:/export/test /mnt/nfstest
Pruébelo de nuevo con la cuenta sin privilegios, debería fallar.
Hay un par de otras opciones que se pueden especificar en el punto de montaje para restringir aún más lo que se puede ejecutar desde ellos, consulte noexec (sin archivos ejecutables), nodev (sin archivos de dispositivo). Si se requiere más seguridad, consulte Kerberos y NFSv4.