Usar Kerberos para controlar el acceso a recursos compartidos de red NFS

Este es un objetivo muy fundamental e importante en el examen. Ya que este tema incluye varios aspectos que usted debe dominar a la parfeccion como futuro ingeniero.

Para comenzar partiremos de la siguiente configuracion:

Servidor IPA: labrhelserver.home.cert.com 192.168.4.50
Cliente 1: labsystem1.home.cert.com 192.168.4.60
Cliente 2: labsystem2.home.cert.com 192.168.4.70

Vamos a partir que estos dos servidores clientes estan enrolados en el servidor IPA, de no ser asi, usted debe hacerlo con el fin de obtener el “krb5.keytab”. Pero como esto lo relaizamos en la construccion de nuestro lab, ya sabemos como hacerlo. Pero tambien es importante tener la siguiente infirmacion para realizar este ejercicio:

Keytab information:

Cliente 1: ftp://labrhelserver.home.cert.com/pub/labsystem1.keytab
Cliente 2: ftp://labrhelserver.home.cert.com/pub/labsystem2.keytab

Ahora vamos a comenzar con la configuracion pertinente en nuestro cliente 1. Primero descagaremos el keytab del servidor y lo guargaremos en el lugar correcto:

[root@labsystem1 ~]# wget -O /etc/krb5.keytab ftp://labrhelserver.home.cert.com/pub/labsystem1.keytab
--2017-06-24 12:12:33-- ftp://labrhelserver.home.cert.com/pub/labsystem1.keytab
=> ‘/etc/krb5.keytab’
Resolving labrhelserver.home.cert.com (labrhelserver.home.cert.com)... 192.168.4.50
Connecting to labrhelserver.home.cert.com (labrhelserver.home.cert.com)|192.168.4.50|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /pub ... done.
==> SIZE labsystem1.keytab ... 376
==> PASV ... done. ==> RETR labsystem1.keytab ... done.
Length: 376 (unauthoritative)

100%[========================================>] 376 --.-K/s in 0.01s

2017-06-24 12:12:33 (35.4 KB/s) - ‘/etc/krb5.keytab’ saved [376]

[root@labsystem1 ~]#
[root@labsystem1 ~]# ls -lsZ /etc/krb5.keytab
-rw-------. root root unconfined_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab
[root@labsystem1 ~]#

Y nos aseguramos que tenga el contexto de SELinux correcto aplicado. Ahora para exportar un sistema de archivos vis NFS y utilizar kerberos para controlar el acceso, vamos a realizar un cambio en las politicas para que se exporten correctamente, para esto modificaremos el archivo “/etc/sysconfig/nfs”

[root@labsystem1 ~]# vim /etc/sysconfig/nfs
[root@labsystem1 ~]# head /etc/sysconfig/nfs

#
#
# To set lockd kernel module parameters please see
# /etc/modprobe.d/lockd.conf
#

# Optional arguments passed to rpc.nfsd. See rpc.nfsd(8)
RPCNFSDARGS="-V 4.2"
# Number of nfs server processes to be started.
[root@labsystem1 ~]#

El cambio en “RPCNFSDARGS”, en donde debemos agregar “-V 4.2”. Una vez este cambio realizado, procedemos con la instalacion de los paquetes necesarios:

[root@labsystem1 ~]# yum install nfs-utils
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Package 1:nfs-utils-1.3.0-0.33.el7.x86_64 already installed and latest version
Nothing to do
[root@labsystem1 ~]#

Como ven, ya tenemos el paquete instalado. Ahora vamos a proseguir con la creacion del directorio que vamos compartir. Tambien aplicaremos el “fcontext” correcto para NFS.

[root@labsystem1 ~]# mkdir /securedexport
[root@labsystem1 ~]# semanage fcontext -a -t public_content_rw_t "/securedexport(/.*)?"
[root@labsystem1 ~]# restorecon -Rvvvv /securedexport
restorecon reset /securedexport context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:public_content_rw_t:s0
[root@labsystem1 ~]#

Ahora agregaremos este direcotrio al archivo exports:

[root@labsystem1 ~]# echo '/securedexport *.home.cert.com(sec=krb5p,rw)' >>/etc/exports
[root@labsystem1 ~]# exportfs -rv
exporting *.home.cert.com:/securedexport
[root@labsystem1 ~]#

Fijense bien en las opciones que se ponen en este paso. Como ven el recurso esta siendo compartido utilizando kerberos. Pues ahora vamos a abrir los servicios correspondientes en el firewall e iniciarlos y no se olviden de habilitarlos para no tener problemas despues de un reinicio.

[root@labsystem1 ~]# firewall-cmd --permanent --add-service={nfs,mountd,rpc-bind}
success
[root@labsystem1 ~]# firewall-cmd --reload
success
[root@labsystem1 ~]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: dhcpv6-client mountd nfs rpc-bind ssh
ports:
protocols:
masquerade: no
forward-ports:
sourceports:
icmp-blocks:
rich rules:

[root@labsystem1 ~]# systemctl start nfs-server
[root@labsystem1 ~]# systemctl enable nfs-server
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service.
[root@labsystem1 ~]# systemctl start nfs-secure-server
[root@labsystem1 ~]# systemctl enable nfs-secure-server
[root@labsystem1 ~]#

Despues de esto, pues ahora vamos a montar el recurso conpartido en el Cliente 2. Entonces para comenzar vamos a descargar el keytab del cliente 2:

[root@labsystem2 ~]# wget -O /etc/krb5.keytab ftp://labrhelserver.home.cert.com/pub/labsystem2.keytab
--2017-06-24 16:07:16-- ftp://labrhelserver.home.cert.com/pub/labsystem2.keytab
=> ‘/etc/krb5.keytab’
Resolving labrhelserver.home.cert.com (labrhelserver.home.cert.com)... 192.168.4.50
Connecting to labrhelserver.home.cert.com (labrhelserver.home.cert.com)|192.168.4.50|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /pub ... done.
==> SIZE labsystem2.keytab ... 378
==> PASV ... done. ==> RETR labsystem2.keytab ... done.
Length: 378 (unauthoritative)

100%[==============================================================================================>] 378 --.-K/s in 0.001s

2017-06-24 16:07:16 (704 KB/s) - ‘/etc/krb5.keytab’ saved [378]

[root@labsystem2 ~]# ls -lsZ /etc/krb5.keytab
-rw-------. root root unconfined_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab
[root@labsystem2 ~]#

Ahora vamos a instalar los paquetes necesarios para montar el recurso que estamos compartiendo en el servidor cliente 1:

[root@labsystem2 ~]# yum -y install nfs-utils
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Package 1:nfs-utils-1.3.0-0.33.el7.x86_64 already installed and latest version
Nothing to do
[root@labsystem2 ~]#

Como ven ya esta instalado. Ahora bein, despues de esots pasos, es muy importante que el servicio “nfs-secure” se inicie y se habilite. Si omite esta paso, puede tener problemas en su examen.

[root@labsystem2 ~]# systemctl enable nfs-secure
[root@labsystem2 ~]# systemctl start nfs-secure

Ahora vamos a crear el punto de montaje, para esto vamos a crear un nuevo directorio:

[root@labsystem2 ~]# mkdir /mnt/securedexport

Entonces, antes de montar el recurso compartido, yo siempre recomiendo que sea montado temporalmente para comprobar que todo este bien, y despues proceder a agregar la linea correcta en el archivo fstab. Entonces vamos a proceder con lo siguiente:

[root@labsystem2 ~]# mount -o sec=krb5p,v4.2 labsystem1.home.cert.com:/securedexport /media/
[root@labsystem2 ~]# df -h | grep media
labsystem1.home.cert.com:/securedexport 5.3G 3.2G 2.2G 59% /media

Como ven todo luce perfecto, ahora vamos a agregar la de configuracion en fstab

[root@labsystem2 ~]# echo "labsystem1.home.cert.com:/securedexport /mnt/securedexport nfs _netdev,defaults,v4.2,sec=krb5p 0 0" >> /etc/fstab
[root@labsystem2 ~]# umount /media/
[root@labsystem2 ~]# mount -a
[root@labsystem2 ~]# df -h | grep /mnt/
/dev/sr0 3.6G 3.6G 0 100% /mnt/iso
labsystem1.home.cert.com:/securedexport 5.3G 3.2G 2.2G 59% /mnt/securedexport

Perfecto, ya tenemos montado nuestro recurso NFS con Kerberos. Pero aun nos queda algo muy fundamental, y es comprobar que este funcionando como esperamos.

Para esto vamos a crear un archivo en el cliente 1, y vamos a cambiarlo los permisos de usuario y grupo para que solo este usuario pueda escribir sobre el archivo.

[root@labsystem1 ~]# echo "Hello World" > /securedexport/testfile.txt
[root@labsystem1 ~]# chown ldapuser1:ldapuser1 /securedexport/testfile.txt
[root@labsystem1 ~]# ls -lZ /securedexport/testfile.txt
-rw-r--r--. ldapuser1 ldapuser1 unconfined_u:object_r:public_content_rw_t:s0 /securedexport/testfile.txt
[root@labsystem1 ~]#

Como ven solo el usuario “ldapuser1” puede realizar cambios en este archivo. Ahora vamos a comprobar esto en el cliente 2.

[root@labsystem2 ~]# cd /mnt/securedexport/
[root@labsystem2 securedexport]# ll
total 4
-rw-r--r--. 1 ldapuser1 ldapuser1 12 Jun 25 19:11 testfile.txt
[root@labsystem2 securedexport]# echo "root paso por aqui" >> testfile.txt
-bash: testfile.txt: Permission denied
[root@labsystem2 securedexport]#

Como pueden ver hasta ahora, el usuario root no puede realizar cambios al archivo, lo cual quiere decir que todo esta funcionando como esperamos, ahora vamos a logearnos como “ldapuser1” y comprobar:

[root@labsystem2 ~]# su - ldapuser1
Last login: Sat Jun 24 15:44:46 PDT 2017 on pts/0
-sh-4.2$ cd /mnt/
-sh-4.2$ ll
ls: cannot access securedexport: Permission denied
total 4
dr-xr-xr-x. 10 root root 4096 Oct 19 2016 iso
d?????????? ? ? ? ? ? securedexport
-sh-4.2$

Como ven, este usuario no puede ver el recurso montado, le aparece con uno “??????”. Como arreglamos esto, simplemente abrimos un “Kerberos ticket”

-sh-4.2$ kinit
Password for ldapuser1@HOME.CERT.COM: password
Password expired. You must change it now.
Enter new password: password
Enter it again: password
-sh-4.2$ ls -las
total 4
0 drwxr-xr-x. 4 root root 38 Jun 24 16:10 .
0 dr-xr-xr-x. 17 root root 233 Jun 24 12:37 ..
4 dr-xr-xr-x. 10 root root 4096 Oct 19 2016 iso
0 drwxr-xr-x. 2 root root 26 Jun 25 19:11 securedexport
-sh-4.2$ cd securedexport/
-sh-4.2$ ll
total 4
-rw-r--r--. 1 ldapuser1 ldapuser1 12 Jun 25 19:11 testfile.txt
-sh-4.2$ echo "ldapuser1 paso por aqui desde el cliente 2" >> testfile.txt
-sh-4.2$ cat testfile.txt
Hello World
ldapuser1 paso por aqui desde el cliente 2
-sh-4.2$

Como ven, este usuario fue requerido para que cambiara su clave despues de introducer la clave correcta. Esto no es un problema, pero debe tenerlo en cuenta en sus practicas.

Despues de haber verificado todo, solo nos queda reiniciar ambos clientes para comprobar que no tengamos errores al iniciar.

Esta es una comprobacion de que los clientes fueron reiniciados:

[root@labsystem1 ~]# uptime
19:19:19 up 13 min, 2 users, load average: 0.00, 0.09, 0.17
[root@labsystem1 ~]# systemctl reboot
Connection to labsystem1 closed by remote host.
fidel.valero ~ $ ssh labsystem1 -l root
Password:
Last login: Sun Jun 25 19:06:10 2017 from gateway
[root@labsystem1 ~]# uptime
19:20:47 up 0 min, 2 users, load average: 3.44, 1.04, 0.36
[root@labsystem1 ~]#

[root@labsystem2 ~]# uptime
19:19:30 up 13 min, 2 users, load average: 0.00, 0.10, 0.18
[root@labsystem2 ~]# systemctl reboot
Connection to labsystem2 closed by remote host.
fidel.valero ~ $ ssh labsystem2 -l root
Password:
Last login: Sun Jun 25 19:06:31 2017 from gateway
[root@labsystem2 ~]# uptime
19:21:32 up 0 min, 2 users, load average: 2.39, 0.66, 0.22
[root@labsystem2 ~]#

Y aqui la comprobacion de que todo este bien:

[root@labsystem2 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rhel_labsystem2-root 5.3G 3.2G 2.2G 60% /
devtmpfs 905M 0 905M 0% /dev
tmpfs 920M 84K 920M 1% /dev/shm
tmpfs 920M 8.9M 911M 1% /run
tmpfs 920M 0 920M 0% /sys/fs/cgroup
/dev/sr0 3.6G 3.6G 0 100% /mnt/iso
/dev/vda1 1014M 155M 860M 16% /boot
labsystem1.home.cert.com:/securedexport 5.3G 3.2G 2.2G 59% /mnt/securedexport
tmpfs 184M 16K 184M 1% /run/user/42
tmpfs 184M 0 184M 0% /run/user/0
[root@labsystem2 ~]# su - ldapuser1
Last login: Sun Jun 25 19:14:19 PDT 2017 on pts/0
-sh-4.2$ kinit
Password for ldapuser1@HOME.CERT.COM: password
-sh-4.2$ echo "despues de reiniciar" >> /mnt/securedexport/testfile.txt

Ahora si usted en vez de compartir un archivo, lo que desa es compartir un directorio, entonces debemos hacer algunos ajustes en el cliente 1. Para esto vamos a partir de crear un directorio en donde solo “ldapuser2” pueda escribir.

[root@labsystem1 ~]# cd /securedexport/
[root@labsystem1 securedexport]# ll
total 4
-rw-r--r--. 1 ldapuser1 ldapuser1 76 Jun 25 19:22 testfile.txt
[root@labsystem1 securedexport]# mkdir ldap-user2
[root@labsystem1 securedexport]# ll
total 4
drwxr-xr-x. 2 root root 6 Jun 25 19:24 ldap-user2
-rw-r--r--. 1 ldapuser1 ldapuser1 76 Jun 25 19:22 testfile.txt
[root@labsystem1 securedexport]# chmod 770 ldap-user2/
[root@labsystem1 securedexport]# chown ldapuser2:ldapuser2 ldap-user2/
[root@labsystem1 securedexport]# ls -lasdZ *
drwxrwx---. ldapuser2 ldapuser2 unconfined_u:object_r:public_content_rw_t:s0 ldap-user2
-rw-r--r--. ldapuser1 ldapuser1 unconfined_u:object_r:public_content_rw_t:s0 testfile.txt
[root@labsystem1 securedexport]#

Con estos cambios ya aplicados, pues no nos queda mas que comprobar en el cliente 2

[root@labsystem2 ~]# su - ldapuser2
Last login: Sun Jun 25 19:26:45 PDT 2017 on pts/0
-sh-4.2$ cd /mnt/
-sh-4.2$ ll
ls: cannot access securedexport: Permission denied
total 4
dr-xr-xr-x. 10 root root 4096 Oct 19 2016 iso
d?????????? ? ? ? ? ? securedexport
-sh-4.2$ kinit
Password for ldapuser2@HOME.CERT.COM: password
Password expired. You must change it now.
Enter new password: password
Enter it again: password
-sh-4.2$ cd securedexport/
-sh-4.2$ ll
total 4
drwxrwx---. 2 ldapuser2 ldapuser2 6 Jun 25 19:24 ldap-user2
-rw-r--r--. 1 ldapuser1 ldapuser1 76 Jun 25 19:22 testfile.txt
-sh-4.2$ cd ldap-user2/
-sh-4.2$ ll
total 0
-sh-4.2$ touch 1 ; mkdir 2
-sh-4.2$ ll
total 0
-rw-rw-r--. 1 ldapuser2 ldapuser2 0 Jun 25 19:27 1
drwxrwxr-x. 2 ldapuser2 ldapuser2 6 Jun 25 19:27 2
-sh-4.2$

Todo muy bien, con esto hemos terminado nuestro ejercicio. Espero que les ayude en su preparacion para el examen.

Leave a Reply

Your email address will not be published. Required fields are marked *