Así que hoy vamos a ver cómo integrar nuestro SSO de cabecera con esta herramienta a través de un módulo de Apache y de paso vamos a proveerle de un proxy inverso que nos dé encriptación TLS de las comunicaciones.

Listado de episodios

• Parte 1.

Esquema del laboratorio

Como siempre, el primer paso es detallar nuestra arquitectura.

Como plataforma de virtualización se ha utilizado KVM sobre Debian 11 pero se puede hacer con cualquier otra como VirtualBox, VMWare o Hyper-V.

Todos los servidores están desplegados sobre CentOS 7.9 de 64 bits excepto el desktop que es una Debian 11 de 64 bits. En cuanto al resto de componentes:

• El Apache desplegado es el propio del repositorio estándar de CentOS.
• Rundeck Community se ha desplegado en la version 4.7.0.
• 389DS se ha desplegado en la versión 1.3.10.
• Apereo CAS se ha desplegado desde la plantilla de CAS overlay en su versión 6.6.0.

Para el direccionamiento de red se ha usado un segmento de red de clase C en el segmente 192.168.122.0/24 con direccionamiento estático asignado a las máquinas.

La distribución final de los equipos en el laboratorio será la siguiente:

• Servidor 389DS. 2 GB de RAM, 2 vCPU y 40 GB de disco. Dirección IP: 192.168.122.11.
• Servidor Apereo CAS. 2 GB de RAM, 2vCPU y 40 GB de disco. Dirección IP: 192.168.122.12.
• Servidor Rundeck y Apache. 2 GB de RAM, 2vCPU y 40 GB de disco. Dirección IP: 192.168.122.13.
• Estación de trabajo. 2 GB de RAM, 2vCPU y 40 GB de disco. Dirección IP: 192.168.122.2.

Como siempre voy a suponer que sabéis cómo instalar los sistemas operativos, 389DS, Apereo CAS y Rundeck por lo que no voy a explicar esta parte. Al fin y al cabo si estáis leyendo esto entiendo que si estás leyendo este artículo es porque ya sabes todo esto.

Hasta el siguiente episodio.

Activar el modulo NBD

Lo primero es cargar el módulo NBD que nos permitirá conectar el fichero qcow2 como un dispositivo de disco más del sistema.

{% highlight bash %}

igalvit@server:/vms/kvm$ sudo modprobe nbd max_part=8

{% endhighlight %}

Montar el fichero qcow2

Una vez que ya tenemos el módulo cargado tenemos que conectar el fichero qcow2, en mi caso se trata de un disco virtual de una máquina CentOS 7.

{% highlight bash %}

igalvit@server:/vms/kvm$ sudo qemu-nbd –connect=/dev/nbd0 /vms/kvm/centos7.qcow2

{% endhighlight %}

Ver las particiones disponibles

En este punto ya hemos montado el disco pero no sabemos qué contiene, así que vamos a visualizarlo para posteriormente elegir la partición que nos interesa.

{% highlight bash %}

igalvit@server:/vms/kvm$ sudo fdisk /dev/nbd0 -l Disco /dev/nbd0: 20 GiB, 21474836480 bytes, 41943040 sectores Unidades: sectores de 1 * 512 = 512 bytes Tamaño de sector (lógico/físico): 512 bytes / 512 bytes Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes Tipo de etiqueta de disco: dos Identificador del disco: 0x000a1f9c

Dispositivo Inicio Comienzo Final Sectores Tamaño Id Tipo /dev/nbd0p1 * 2048 2099199 2097152 1G 83 Linux /dev/nbd0p2 2099200 41943039 39843840 19G 8e Linux LVM

{% endhighlight %}

Montar la partición

En nuestro caso se trata de un volumen LVM por lo que lleva un poco más de trabajo del habitual.

{% highlight bash %}

igalvit@server:/vms/kvm$ sudo vgscan Found volume group “centos_centos7” using metadata type lvm2 Found volume group “ubuntu_vg” using metadata type lvm2

igalvit@server:/vms/kvm$ sudo vgchange -ay centos_centos7 2 logical volume(s) in volume group “centos_centos7” now active

igalvit@server:/vms/kvm$ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root centos_centos7 -wi-a—– <17,00g
swap centos_centos7 -wi-a—– 2,00g
root ubuntu_vg -wi-ao—- 921,00g
swap ubuntu_vg -wi-ao—- <9,28g

igalvit@server:/vms/kvm$ sudo mount /dev/centos_centos7/root /mnt -o ro,user

{% endhighlight %}

Visualizar el contenido de un fichero

Como esto es una prueba no vamos a hacer nada complicado, simplemente vamos a visualizar el fichero de la versión de la distribución de CentOS instalada.

{% highlight bash %}

igalvit@server:/vms/kvm$ cd /mnt

igalvit@server:/mnt$ ls bin dev home lib64 mnt proc run srv tmp var boot etc lib media opt root sbin sys usr

igalvit@server:/mnt$ cat etc/redhat-release CentOS Linux release 7.9.2009 (Core)

{% endhighlight %}

Desmontarlo todo

Una vez terminada la tareas ha llegado la hora de recoger velas.

{% highlight bash %}

igalvit@server:/$ sudo umount /mnt

igalvit@server:/$ sudo vgchange -an centos_centos7 0 logical volume(s) in volume group “centos_centos7” now active

igalvit@server:/$ sudo qemu-nbd –disconnect /dev/nbd0 /dev/nbd0 disconnected

{% endhighlight %}

Y con esto damos por finalizado este artículo.

Acceso al OWA

El acceso al OWA lo haremos como siempre, accediendo por la URL que hayamos definido para este servicio que en nuestro caso es https://exlab.olimpo.lab/owa.

Cuando accedamos en vez de mostrarnos el formulario clásico del OWA veremos una página llamada Home Realm Discovery donde deberemos seleccionar el proveedor que vamos a usar para autenticarnos, que en nuestro caso será apereolab.olimpo.lab.

Al hacer eso accederemos al formulario del CAS donde introducieremos las credenciales de acceso. Bastante sencillo, ¿no?

Pues vamos a introducir una mejora, en realidad a nosotros ya no nos interesa que el usuario se valide mediante Directorio Activo o que tenga que seleccionar un proveedor de identididades por que con estos dos comandos de PowerShell vamos a forzar que el proveedor sea el CAS.

{% highlight posh %} Set-AdfsRelyingPartyTrust -TargetName “Outlook on the web” -ClaimsProviderName “apereolab.olimpo.lab” Set-AdfsRelyingPartyTrust -TargetName “Exchange Control Panel” -ClaimsProviderName “apereolab.olimpo.lab” {% endhighlight %}

Una mejora de última hora

Ya había terminado de redactar este tutorial cuando realizando un par de pruebas encontré la forma de evitar que al cerrar sesión se muestre este mensaje tan feo.

Todo lo que hay que hacer es editar el fichero cas.properties de nuestro CAS y añadir la siguiente línea:

{% highlight conf %} cas.authn.saml-idp.logout.sign-logout-response=true {% endhighlight %}

Reiniciamos el CAS y listo, problema solucionado.

Y con esto damos por terminado este tutorial. Cualquier comentario, ya sabéis, a través de mis redes sociales.

• /etc/cas/config/cas.properties.
• /etc/cas/services/cas_saml-100.json.
• /etc/cas/services/adfs-101.json.
• /etc/cas/metadata/adfs-metadata.xml.

Antes de comenzar

En el fichero build.gradle del CAS Overlay se han añadido las implementaciones de IDP, JSON Service Registry y LDAP. Posteriormente hemos ejecutado el comando ./gradlew clean build para crear el fichero WAR que usaremos. Para ejecutar el CAS hemos usado el comando java -jar build/lib/cas.war

También tendremos que crear un usuario que nos permita autenticar contra Directorio Activo para poder obtener la información de los usuarios. En el caso de este laboratorio el usuario creado es “APEREO USER”.

Fichero /etc/cas/config/cas.properties

{% highlight conf %} as.server.name=https://apereolab.olimpo.lab:8443 cas.server.prefix=${cas.server.name}/cas logging.config=file:/etc/cas/config/log4j2.xml cas.authn.saml-idp.core.entity-id=https://apereolab.olimpo.lab/idp cas.service-registry.json.location: file:/etc/cas/services cas.authn.ldap[0].order=1 cas.authn.ldap[0].name=AD-OLIMPO cas.authn.ldap[0].ldap-url=ldap://exlab.olimpo.lab:389 cas.authn.ldap[0].base-dn=dc=olimpo,dc=lab cas.authn.ldap[0].bind-dn=CN=APEREO USER,OU=Administrators,DC=olimpo,DC=lab cas.authn.ldap[0].bind-credential=<TU_PASSWORD> cas.authn.ldap[0].type=AUTHENTICATED cas.authn.ldap[0].subtreeSearch=true cas.authn.ldap[0].searchFilter=(&(objectClass=person)(sAMAccountName={user})) cas.authn.ldap[0].principalAttributeList=sAMAccountName,mail,userPrincipalName {% endhighlight %}

Fichero /etc/cas/services/cas_saml-100.json

Aquí nuevamente hemos hecho un poco de trampas para que capture cualquier URL.

{% highlight conf %} { “@class”: “org.apereo.cas.services.RegexRegisteredService”, “serviceId”: “http://.+”, “name” : “cas_saml”, “id” : 100, “evaluationOrder” : 100 } {% endhighlight %}

Fichero /etc/cas/services/adfs-101.json

{% highlight conf %} { “@class”: “org.apereo.cas.support.saml.services.SamlRegisteredService”, “serviceId”: “http://fs.olimpo.lab/adfs/services/trust", “name”: “adfs”, “id”: 101, “evaluationOrder”: 101, “description”: “adfs lab service”, “logoutType”: “NONE”, “attributeReleasePolicy”: { “@class”: “org.apereo.cas.services.ReturnAllAttributeReleasePolicy”, }, “usernameAttributeProvider” : { “@class” : “org.apereo.cas.services.PrincipalAttributeRegisteredServiceUsernameProvider”, “usernameAttribute” : “mail”, }, “requiredNameIdFormat”: “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”, “metadataLocation”: “/etc/cas/metadata/adfs-metadata.xml”, “signAssertions”: true, “signResponses”: false } {% endhighlight %}

Fichero /etc/cas/metadata/adfs-metadata.xml

Este fichero se obtiene desde ADFS. Concretamente se debe acceder a la ruta https://fs.olimpo.lab/FederationMetadata/2007-06/FederationMetadata.xml y descargar el fichero XML para luego copiarlo en esta ruta.

Directorio /etc/cas/saml

Contiene la definición del IDP, certificado de firma, encriptación, etc.

{% highlight shell %} ls idp-encryption.crt idp-encryption.key idp-metadata.xml idp-signing.crt idp-signing.key metadata-backups {% endhighlight %}

Ya en la parte siguiente veremos algunas pruebas de funcionamiento y algunas mejoras que se pueden hacer para que todo vaya más fluido. Hasta el próximo episodio.

Claims Providers Trusts

Hemos llamado “apereolab.olimpo.lab” a la relación de confianza y para su generación hemos utilizado los metadatos públicados en la siguiente URL del CAS https://apereolab.olimpo.lab:8443/cas/idp/metadata. Esto nos facilita mucho el trabajo porque ya se encarga de realizar el resto de la configuración de esta relación de confianza.

A continuación mostramos dos capturas de pantalla de las dos pestañas más importantes. Recuerda que esta configuración puede variar en función de la configuración que tengas en el Apereo CAS.

La primera captura es de la pestaña Monitoring donde figura la URL de los metadatos junto con la configuración para que se actualice automáticamente la información.

La segunda captura muestra la configuración de la pestaña que contiene los puntos finales o Endpoints.

Acceptance Transform Rules

Solo vamos a tener un regla de transformación de notificación entrante para NameID que va a ser de tipo Email e indicaremos que pase a través todos los valores de las notificaciones. Recuerda que anteriormente ya hemos comentado que nos vamos a fiar que desde Apereo nos van a enviar una dirección de correo electrónico que existe en el Exchange Server y que además va a coincidir con el UPN de un usuario. Sí, es un poco de trampa, lo sé. 😋

Por si quereis echarle un vistazo a la consulta que se genera, es la siguiente:

{% highlight query %} c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”, Properties[“http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format”] == “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”] => issue(claim = c); {% endhighlight %}

Y ya con esto nos vemos en el próximo capítulo donde hablaremos de la parte del Apereo CAS.

Vamos a suponer que ya tienes un controlador de dominio operativo, en nuestro caso sobre el dominio OLIMPO y que además ya cuentas con al menos un Exchange Server 2019 en marcha, recuerda que en este laboratorio está integrado en el mismo servidor que el controlador de dominio, es decir, en exlab.olimpo.lab.

Configuración de la federación ADFS

La federación de mi laboratorio está desplegada sobre el servidor adfslab.olimpo.lab y tiene la configuración que se muestra en la siguiente captura. Realmente se trata de la configuración por defecto donde el único cambio reseñable es que la federación tiene como nombre http://fs.olimpo.lab simplemente para diferenciarla del nombre del servidor que la alberga.

Relaying Trust Parties

En nuestro caso se van a generar dos relaciones de relaciones de confianza, una para Outlook Web App (OWA) y la otra para Exchange Control Panel (ECP). A la primera le hemos puesto el nombre de “Outlook on the web” y a la segunda “Exchange Control Panel”.

Recuerda que estos son los únicos servicios de Exchange que se pueden federar ya que tanto EAS como Outlook deben autenticarse mediante Directorio Activo.

Outlook on the web

Como se puede observa la segunda relación de confianza es casi igual que la primera solo que para el ECP. En la siguiente captura se puede observar la configuración de los identificadores que solo es uno hacia la URL del OWA.

En esta captura se puede observar la configuración de los puntos finales. En realidad solo tenemos uno de tipo POST hacia la URL de OWA.

Exchange Control Panel

Como se puede observa la segunda relación de confianza es casi igual que la primera solo que para el ECP. En la siguiente captura se puede observar la configuración de los identificadores que en este caso también es solo uno hacia la URL del ECP.

En esta captura se puede observar la configuración de los puntos finales. Como en el primer caso solo tenemos uno de tipo POST hacia la URL del ECP.

Issuance Transform Rules

En las reglas de transformación de notificaciones tenemos dos reglas, una para el UPN y otra para obtener el PrimarySID mediante uan búsqueda en el repositorio de Directorio Activo. Ambas reglas son exactamente iguales en ambas relaciones de confianza por lo que solo las describiremos una vez.

Regla UPN

En esta primera regla simplemente obtenemos la notificación entrante NameIdentifier que es de tipo email (esto lo veremos cuando configuremos el CAS) y emito una nueva notificación de tipo UPN con el valor que me llega.

{% highlight query %} c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”] => issue(Type = “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Value = c.Value); {% endhighlight %}

Es verdad que esto es bastante deficiente y estoy confiando en que me llegue la notificación con una dirección de correo valida y que coincida con el UPN del usuario en Directorio Activo pero recuerda que esto se trata de un laboratorio para aprender.

Regla PrimarySID

En esta segunda regla aprovechamos la notificació de tipo UPN recien creada para localizar el objectSID del usuario buscandolo por el UPN y por la dirección de correo electrónico por si no somos capaces de localizarlo por el UPN.

{% highlight query %} c1:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”] && c2:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”] => issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"), query = “(&(objectCategory=person)(objectClass=user)(|(userPrincipalName={0})(&(mail={0})(!(userPrincipalName={0})))));objectSid;OLIMPO\random”, param = c2.Value); {% endhighlight %}

Aquí nuevamente hacemos un poco de truco porque estamos forzando el dominio del usuario al del laboratorio pero no he sido capaz de hacerlo funcionar de otra manera.

Bueno y con esto nos despedimos hasta el siguiente episodio donde veremos la parte de los proveedores de confianza de notificaciones o Claims Providers Trusts.

Listado de episodios

Comencemos con el listado de todos los artículos relacionados con este tutorial.

• Parte 1.
• Parte 2.
• Parte 3.
• Parte 4.
• Parte 5.

Esquema del laboratorio

Vamos a usar cuatro máquinas virtuales en este laboratorio aunque en un entorno real deberían ser al menos seis ya que he integrado el controlador de dominio con el servidor Exchange y, como no nos hacía falta para un laboratorio, no he publicado ADFS mediante un Web Application Proxy.

Como plataforma de virtualización se ha utilizado WMWare Workstation 16 pero se puede hacer con cualquier otra como VirtualBox, KVM o Hyper-V.

Los servidores Windows se han montado en Windows Server 2022 Standard, la estación de trabajo en Windows 10 Pro y el servidor de Apereo en CentOS 7.9 de 64 bits.

Se ha utilizado Exchange Server 2019 CU11 y para la implementación del CAS de Apereo se ha utilizado la 6.0.0 obtenida del overlay descargado desde su repositorio en GitHub en la URL https://github.com/apereo/cas-overlay-template.

Para el direccionamiento de red se ha usado un segmento de red de clase C en el segmente 172.16.53.0/24 con direccionamiento estático asignado a las máquinas.

La distribución final de los equipos en el laboratorio será la siguiente:

• Controlador de dominio y Exchange Server. 6 GB de RAM, 4 vCPU y dos discos de 100 GB. Dirección IP: 172.16.53.10.
• Servidor ADFS. 4 GB de RAM, 2 vCPU y 60 GB de disco. Dirección IP: 172.16.53.11.
• Servidor Apereo CAS. 2 GB de RAM, 2vCPU y 40 GB de disco. Dirección IP: 172.16.53.13.
• Estación de trabajo. 4 GB de RAM, 2vCPU y 60 GB de disco. Dirección IP: 172.16.53.20.

Voy a dar por supuesto que todos sabemos instalar el sistema operativo tanto de los servidores como de la estación de trabajo y también obtener las ISO de Windows y Exchange Server por lo que no voy a explicar esta parte. Tampoco voy a detallar cómo se instala el controlador de dominio o Exchange Server porque entiendo que si estás leyendo este artículo es porque ya sabes todo esto.

Hasta el siguiente episodio.

Instalación

Lo primero es descargar e instalar dos programas en nuestro equipo Windows. Os dejo los enlaces.

• SSHFS-Win: https://github.com/billziss-gh/sshfs-win
• WinFsp: https://github.com/billziss-gh/winfsp

Son dos paquetes MSI de los de “siguiente, siguiente, finalizar” así que tampoco vamos a perder el tiempo detallando su instalación.

Mapear el directorio personal de un usuario

El mapeo se realiza como cualquier unidad de red de Windows con la excepción de que a la hora de mapear la unidad debemos seguir el siguiente formato:

\\sshfs\<USUARIO>@<MAQUINA>

Nos pedirá nuestras credenciales y ya está hecho.

En esta captura podemos observar los ficheros que contiene mi carpeta personal en el servidor GNU/Linux.

Mapear un directorio dentro del servidor

¿Os acordais del montaje NFS que hemos usado en otras publicaciones? Pues es muy fácil mapear directamente ese directorio como una unidad de red. Tan solo hay que cambiar un poco el comando para que siga este formato.

\\sshfs.r\<USUARIO>@<MAQUINA>\<RUTA>

Aquí podemos ver el contenido de la carpeta datos dentro del explorador de Windows.

Mapear un directorio desde la consola CMD

Pues resulta que también es posible mapear un directorio desde la consola CMD y como esto es algo que me encanta, ahí os dejo un ejemplo.

C:\Users\IEUser>net use X: \\sshfs\ignacio@192.168.2.129
The password is invalid for \\sshfs\ignacio@192.168.2.129.

Enter the user name for 'sshfs': ignacio
Enter the password for sshfs:
The command completed successfully.

C:\Users\IEUser>net use
New connections will be remembered.


Status       Local     Remote                    Network

-------------------------------------------------------------------------------
             X:        \\sshfs\ignacio@192.168.2.129
                                                WinFsp.Np
             Z:        \\sshfs.r\ignacio@192.168.2.129\datos
                                                WinFsp.Np
The command completed successfully.

Y para eliminarlo, igual de sencillo

$ net use X: /delete
X: was deleted successfully.

Más opciones

Tiene algunas opciones más como el uso de claves SSH si no quereis usar contraseñas. Lo mejor es que reviseis la documentación en su página web. Pues eso es todo, amigos.

Instalación

Desde una consola de PowerShell elevada hay que ejecutar el siguiente comando.

{% highlight powershell %} Enable-WindowsOptionalFeature -Online -FeatureName ClientForNFS-Infrastructure {% endhighlight %}

Montaje de solo lectura

Hay que tener en cuenta que esto no funciona desde la consola de PowerShell.

mount -o anon \\<IP_SERVIDOR_NFS>\datos Z:
Z: is now successfully connected to \\<IP_SERVIDOR_NFS>\datos

Montaje de lectura/escritura

Esta parte es bastante engorrosa en Windows. A mí personalmente no me gusta nada y por eso prefiero usar otras alternativas que os mostraré en otra publicación. Pero bueno, para ciertos entornos tiene su utilidad.

Lo primero es usar el comando mount para obtener el UID y GID con el que está montado el recurso NFS.

mount

Local    Remote                                 Properties
-------------------------------------------------------------------------------
Z:       \\<IP_SERVIDOR_NFS>\datos              UID=-2, GID=-2
                                                rsize=262144, wsize=262144
                                                mount=soft, timeout=0.8
                                                retry=1, locking=yes
                                                fileaccess=755, lang=ANSI
                                                casesensitive=no
                                                sec=sys

Hay que crear dos entradas en el registro de Windows para modificar los UID y GID por defecto. Lo ideal es elegir el UID y GDI de un usuario que ya exista en el servidor NFS y de esa manera creamos los ficheros y carpeta con identificadores ya existentes y no veremos valores númericos al visualizar los directorios desde nuestro Linux.

La primera clave se crea con el siguiente comando.

{% highlight powershell %} New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousUID -Value 1000 -PropertyType “DWord”

AnonymousUID : 1000 PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\De fault PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion PSChildName : Default PSDrive : HKLM PSProvider : Microsoft.PowerShell.Core\Registry {% endhighlight %}

La segunda clave se crea con el siguiente comando.

{% highlight powershell %} New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousGID -Value 105 -PropertyType “DWord”

AnonymousGID : 1000 PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\De fault PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion PSChildName : Default PSDrive : HKLM PSProvider : Microsoft.PowerShell.Core\Registry

PS C:\Windows\system32> {% endhighlight %}

Es necesario reiniciar el equipo para que lea del registro los cambios.

Vamos a ver si esto ha funcionado. Vamos a intentar crear una carpeta llamada folder2.

C:\Users\IEUser>z:

Z:\>dir
 Volume in drive Z has no label.
 Volume Serial Number is 1835-1B2D

 Directory of Z:\

10/22/2021  01:40 PM    <DIR>          .
10/22/2021  01:40 PM    <DIR>          ..
10/22/2021  01:23 PM    <DIR>          folder
               0 File(s)             62 bytes
               3 Dir(s)  37,989,482,496 bytes free

Z:\>mkdir folder2

Z:\>dir
 Volume in drive Z has no label.
 Volume Serial Number is 1835-1B2D

 Directory of Z:\

10/22/2021  01:40 PM    <DIR>          .
10/22/2021  01:40 PM    <DIR>          ..
10/22/2021  01:23 PM    <DIR>          folder
10/22/2021  01:40 PM    <DIR>          folder2
               0 File(s)             98 bytes
               4 Dir(s)  37,989,482,496 bytes free

Y ahora vamos a nuestro servidor NFS a ver si realmente existe y con qué propietario y permisos se ha creado.

{% highlight shell %} [root@centos7 datos]# ll total 0 drwxr-xr-x. 2 root root 22 oct 22 21:23 folder drwxr-xr-x. 2 ignacio ignacio 6 oct 22 21:43 folder2 [root@centos7 datos]# {% endhighlight %}

Pues eso es todo, amigos.

Una nota aclaratoria, esto no pretende ser un tutorial sobre cómo exportar volúmenes NFS sino una breve introducción explicativa para apoyar lo que mostraré en la entrada que crearé en breve. 😁

Instalación servicio NFS

Lo primero que vamos a hacer es instalar los paquetes necesarios para disponer del servicio NFS.

[ignacio@centos7 ~]$ sudo dnf install nfs-utils

Si tenemos habilitado SELinux en el servidor hay que permitir su uso, por lo que hay que ejecutar este comando.

[ignacio@centos7 ~]$ sudo setsebool -P nfs_export_all_ro=1 nfs_export_all_rw=1

El siguiente paso es abrir los puertos necesarios en el cortafuegos. Esto lo hacemos en dos pasos, el primero sirve para añadir las excepciones del servicio y el segundo para forzar el cortafuegos a recargar la configuración que hemos modificado.

[ignacio@centos7 ~]$ sudo firewall-cmd --permanent --add-service nfs
success
[ignacio@centos7 ~]$ sudo firewall-cmd --reload
success

El siguiente paso es habilitar los servicios para que se inicien con el inicio del servidor.

[ignacio@centos7 ~]$ sudo systemctl enable rpcbind nfs-server
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service.

Y ahora vamos a iniciar los servicios para poder pasar a la parte de configuración.

[ignacio@centos7 ~]$ sudo systemctl start rpcbind nfs-server

Configuración servicio NFS

El primer paso es crear el directorio que vamos a exportar, en mi caso /datos.

mkdir /datos

Como segundo paso vamos a modificar el fichero exports para configurar una exportación del directorio datos en modo lectura para cualquier usuario. En mi caso lo voy a exportar a cualquier IP porque es un laboratorio. Si vais a montar esto en un entorno más serio, por favor, indicad solo la IP desde la que vais a acceder.

cat /etc/exports
/datos *(ro,sync)

En el siguiente paso vamos a forzar la exportación del nuevo volumen mediante el siguiente comando.

root@centos7 ignacio]# exportfs -arv<br />exporting *:/datos</span></p>

Por último, vamos a comprobar que el directorio se encuentra correctamente exportado y accesible.

[ignacio@centos7 ~]$ sudo exportfs -s
/datos *(sync,wdelay,hide,no_subtree_check,sec=sys,ro,secure,root_squash,no_all_squash)

Bueno y con esto hemos terminado por hoy. 🏁

Al utilizar la consola para ejecutar la herramienta ovftool mostraba un error con la librería libnsl.

[ignacio@server MSEdge-Win10-VMware]$ ovftool MSEdge-Win10-VMware.ovf <br />/usr/lib/vmware-ovftool/ovftool.bin: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory

Solucionarlo es tan sencillo como instalarla y listo.

Máquina servidor

Lo primero es instalar el paquete de EPEL para posteriormente instalar el paquete knock-server. También es necesario instalar libpcap.

[root@knockd ~]# yum install libpcap

[...]

[root@knockd ~]# yum install epel-release

[...]

[root@knockd ~]# yum install knock-server

[...]

El siguiente paso es eliminar de nftables la regla que permite las conexiones SSH remotas mediante el siguiente comando. Ten en cuenta que en mi instalación se usa la zona por defecto llamada public.

[root@knockd ~]# firewall-cmd --zone=public --remove-service=ssh --permanent
success
[root@knockd ~]# firewall-cmd --reload

El siguiente paso es modificar el fichero /etc/knockd.conf y dejarlo con el siguiente contenido. Por favor, cambiad los puertos a otra secuencia. 😜

[options]
        UseSyslog

[opencloseSSH]
        sequence      = 51234:udp,55678:tcp,59124:udp
        seq_timeout   = 15
        tcpflags      = syn,ack
        start_command = /bin/firewall-cmd --zone=public --add-rich-rule "rule family="ipv4" source address="%IP%" service name="ssh" accept"
        cmd_timeout   = 10
        stop_command  = /bin/firewall-cmd --zone=public --remove-rich-rule "rule family="ipv4" source address="%IP%" service name="ssh" accept"

El último paso es habilitar e iniciar el servicio knockd.

sudo systemctl enable knockd && sudo systemctl start knockd

Máquina cliente

En la máquina cliente desde la que vamos a acceder por SSH es necesario instalar el cliente de knock. Al igual que en el servidor es necesario disponer del repositorio EPEL.

yum install epel-release

[...]

yum install knock

[...]

Vamos a una un primer intento de conexión mediante SSH para que veamos que no es posible conectar.

[ignacio@knock-client ~]$ ssh root@192.168.122.186
ssh: connect to host 192.168.122.186 port 22: No route to host
[ignacio@knock-client ~]$  

Ahora vamos a usar el cliente de knock que hemos instalado para hacer la “llamada” y que se abra la puerta.

[root@knock-client ~]# knock -v -d 1 192.168.122.186 51234:udp 55678:tcp 59124:udp
hitting udp 192.168.122.186:51234
hitting tcp 192.168.122.186:55678
hitting udp 192.168.122.186:59124
[root@knock-client ~]# ssh root@192.168.122.186
root@192.168.122.186's password:  
Last failed login: Sun Aug  1 20:51:14 WEST 2021 from knock-client on ssh:notty
Last login: Sun Aug  1 20:25:03 2021 from knock-client
[root@knockd ~]# 

En el fichero messages del servidor podemos ver lo siguiente:

Aug  1 20:51:26 knock-client knockd: 192.168.122.136: opencloseSSH: Stage 1
Aug  1 20:51:26 knock-client knockd: 192.168.122.136: opencloseSSH: Stage 2
Aug  1 20:51:26 knock-client knockd: 192.168.122.136: opencloseSSH: Stage 3
Aug  1 20:51:26 knock-client knockd: 192.168.122.136: opencloseSSH: OPEN SESAME
Aug  1 20:51:26 knock-client knockd: opencloseSSH: running command: /bin/firewall-cmd --zone=public --add-rich-rule "rule family="ipv4" source address="192.168.122.136" service name="ssh" accept"
Aug  1 20:51:31 knock-client systemd-logind: New session 4 of user root.
Aug  1 20:51:31 knock-client systemd: Started Session 4 of user root.
Aug  1 20:51:37 knock-client knockd: 192.168.122.136: opencloseSSH: command timeout
Aug  1 20:51:37 knock-client knockd: opencloseSSH: running command: /bin/firewall-cmd --zone=public --remove-rich-rule "rule family="ipv4" source address="192.168.122.136" service name="ssh" accept"

Hay que ver cómo está el patio, ¡la máquina encendida llevaba cinco minutos encendida! Así que después de cambiar en el servicio SSH que solo se pueda autenticar mediante claves, lo siguiente ha sido instalar Fail2ban.

Instalación de Fail2ban en CentOS

El primer paso es instalar el repositorio EPEL, si no lo tiene hecho ya, claro.

dnf install epel-repo

Después tenemos que instalar el paquete fail2ban.

dnf install fail2ban

Configuración de Fail2ban

En mi caso, al menos por ahora, voy a dejar la configuración por defecto. En el fichero /etc/fail2ban/jail.conf, está toda la configuración por si queréis modificarla.

Creación de la jaula para SSHD

Hay que crear el fichero que contendrá la configuración de la jaula para el servicio SSHD. Creamos el fichero /etc/fail2ban/jail.d/sshd.local y dentro ponemos el siguiente contenido:

[sshd]
enabled = true

Activación del servicio Fail2ban

Una vez que hemos completado la configuración de Fail2ban, lo siguiente es activar el servicio para que empiece a vigilar por nosotros. 😉

systemctl enable --now fail2ban
Created symlink /etc/systemd/system/multi-user.target.wants/fail2ban.service → /usr/lib/systemd/system/fail2ban.service.

Verificación del estado del servicio Fail2ban

Verificamos que se ha iniciado correctamente con la jaula definida.

fail2ban-client status
Status
|- Number of jail:    1
`- Jail list:    sshd

Comprobamos cómo va la cosa

Dejamos pasar un par de minutos y vamos a ver cuántas IP bloqueadas tenemos.

fail2ban-client get sshd banned
['xxx.xxx.xxx.xxx', 'xx.xx.xx.xxx', 'xx.xx.xxx.xxx', 'xxx.xxx.xxx.xxx', 'xx.xx.xxx.xxx', 'xxx.xxx.xxx.xxx', 'xx.xxx.xxx.xxx', 'xx.xxx.xxx.xx', 'xxx.xxx.xx.xx', 'xx.xx.xxx.xxx']

El enunciado de esta cuarta parte nos dice lo siguiente:

Based on the information available to you, what is the maximum amount of time Vivian Alyse could have spent composing the final message in the thread that you examined? That is, time elapsed from the moment she pressed the “Reply” or “Forward” button, to the moment she hit “Send”. Assume that the following is true:

Vivian used Outlook to compose and send the message
All of the computers involved in the email conversation keep perfectly accurate time

Enter the duration in minutes rounding up. For example, enter 46 for 45 minutes and 31 seconds.

Este es bastante fácil. Si lo retomamos dónde lo dejamos en el artículo anterior, en la propiedad PR_CONVERSATION_INDEX tenemos unos valores llamados TimeDelta y de estos nos interesa el segundo que es la última respuesta a este correo.


El valor 0x00000AE9 lo tenemos que convertir a decimal y posteriormente a minutos quedando que son 1 minuto y 47 segundos, que redondeando hacia arriba como nos pide el enunciado nos queda el valor de 2 minutos. :checkered_flag:

Y con esto ya hemos terminado este reto. :tada:

El enunciado de esta tercera parte nos dice lo siguiente:

It is believed that the email you examined in Part 1 and Part 2 of this challenge was the last message in a conversation thread that comprises multiple messages. Based on the information available to you, when was the initial message in this conversation thread likely sent?

Enter the timestamp in UTC in the following format: yyyy-mm-dd hh:mm:ss (e.g., 2005-11-20 13:17:48)

Una vez que abrimos el mensaje en Outlook y hacemos clic sobre el botón “iMessage” veremos toda la información interna del fichero incluyendo sus propiedades MAPI. La propiedad que debemos buscar es PR_CONVERSATION_INDEX. Dentro de esta propiedad lo que nos interesa es el campo Value que contiene una cadena hexadecimal de 32 bytes que tenemos que descomponer.


De toda esta estructura lo que nos interesa son los primeros doce caracteres a los que debemos añadir cuatro ceros (0000) en la parte posterior quedando el valor 01D5D17A24E40000 y así completar la longitud de 32 bits.

Si os estáis preguntando qué representa este valor pues os cuento que es el número de nanosegundos que han pasado desde el 1 de enero de 1601 que es lo que se conoce como unidades FILETIME (https://docs.microsoft.com/es-es/office/client-developer/outlook/mapi/filetime).

Lo más rápido para convertir esto a una fecha “humana” es utilizar un conversor de FILETIME como el de la página https://www.epochconverter.com/ldap. Tras convertirlo nos queda la fecha 22 de enero de 2020 a las 23:17:41 que es la respuesta que buscamos. Tan solo queda formatearlo tal y como se nos indica, con lo que la respuesta final es 2020-01-22 23:17:41.

El enunciado de esta segunda parte nos dice lo siguiente:

Regardless of whether you believe it is legitimate or fake, what is the last modification timestamp you were able to find for the attachment in Part 1?

Enter the timestamp in UTC with 0.1 microsecond precision in the following format: yyyy-mm-dd hh:mm:ss.fffffff (e.g., 2005-11-20 13:17:48.1234567)

Recuperamos la salida del script de la primera parte con el siguiente contenido:

┌──(kali㉿kali)-[~/Desktop/msgopen]
└─$ php ex1.php
Message Creation time: 1607983178 => 2020-12-14 16:59:38.000000 EST
Message Last modification time: 1607983178 => 2020-12-14, 16:59:38.000000 EST

Attachment: FC_4fca-8f34_Specs.txt
Attachment creation time: 1591119805 => 2020-06-02 13:43:25.000000 EDT
Attachment last modification time: 1591385420 => 2020-06-05 15:30:20.000000 EDT
┌──(kali㉿kali)-[~/Desktop/msgopen]
└─$ 

Cuidado con el enunciado que nos pide que demos la respuesta en zona horaria UTC y nosotros tenemos la respuesta en EST/EDT. Podríamos modificar el script anterior para que nos muestre las fechas en UTC pero es mucho más rápido “googlear” un poco y averiguar que la diferencia horaria es de 4 horas hacia delante desde EST a UTC y sumarlas obteniendo 2020-06-05 19:30:20.0000000 que es la respuesta solicitada.

El enunciado de esta primera parte nos dice lo siguiente:

You are being asked to examine an email1 between two colleagues within the same corporation. The email contains an important business document known to have been created and maintained on a volume formatted with the NT File System (NTFS).

Based on your examination of the email, are the creation and last modification timestamps of the attachment more likely to be legitimate or fake? Enter L for legitimate, F for fake.

1SHA-256: FB42631EC43891EE2D877E02D911 A1FFB95E9B31825986F09DEFE8B9A55F2614

El primer paso es descargarse el fichero en formato msg. Como siempre usamos el comando sha256sum y comprobamos que el “hash” coincide.

──(kali㉿kali)-[~/Desktop/msgopen]
└─$ sha256sum FW__New_Finite_Curvature_Product_Line_Specs.msg                                                 127 ⨯
fb42631ec43891ee2d877e02d911a1ffb95e9b31825986f09defe8b9a55f2614  FW__New_Finite_Curvature_Product_Line_Specs.msg
                                                                                                                    
┌──(kali㉿kali)-[~/Desktop/msgopen]

El siguiente paso lógico sería pasar por VirusTotal el fichero para ver si tiene algo raro dentro pero vamos a omitir este paso porque ya sabemos que es algo que todos hacemos antes de abrir un fichero. :wink:

Aquí lo normal sería utilizar alguna herramienta para Windows y poder husmear dentro de las propiedades MAPI del fichero pero como a mí me gusta hacer las cosas al “estilo software libre” voy a usar una librería de PHP llamada hfig/mapi (https://github.com/hfig/MAPI) en un pequeño script. Aquí os dejo su contenido:

<?php
require 'vendor/autoload.php';

use Hfig\MAPI;
use Hfig\MAPI\OLE\Pear;

// message parsing and file IO are kept separate
$messageFactory = new MAPI\MapiMessageFactory();
$documentFactory = new Pear\DocumentFactory(); 

$ole = $documentFactory->createFromFile('FW__New_Finite_Curvature_Product_Line_Specs.msg');
$message = $messageFactory->parseMessage($ole);

$dateToPrint = date_create();
date_timestamp_set($dateToPrint, $message->properties['creation_time']);
echo 'Message Creation time: ', date_format($dateToPrint,'U => Y-m-d H:i:s.u T'), "\n";
date_timestamp_set($dateToPrint, $message->properties['last_modification_time']);
echo 'Message Last modification time: ', date_format($dateToPrint, 'U => Y-m-d, H:i:s.u T'), "\n\n";
foreach ($message->getAttachments() as $attachment) {
  echo 'Attachment: ', $attachment->properties['display_name'], "\n";
  date_timestamp_set($dateToPrint, $attachment->properties['creation_time']);
  echo 'Attachment creation time: ', date_format($dateToPrint,'U => Y-m-d H:i:s.u T'), "\n";
  date_timestamp_set($dateToPrint, $attachment->properties['last_modification_time']);
  echo 'Attachment last modification time: ', date_format($dateToPrint,'U => Y-m-d H:i:s.u T'), "\n";
}
?>

Tras ejecutarlo la salida que muestra es la siguiente:

┌──(kali㉿kali)-[~/Desktop/msgopen]
└─$ php ex1.php
Message Creation time: 1607983178 => 2020-12-14 16:59:38.000000 EST
Message Last modification time: 1607983178 => 2020-12-14, 16:59:38.000000 EST

Attachment: FC_4fca-8f34_Specs.txt
Attachment creation time: 1591119805 => 2020-06-02 13:43:25.000000 EDT
Attachment last modification time: 1591385420 => 2020-06-05 15:30:20.000000 EDT
┌──(kali㉿kali)-[~/Desktop/msgopen]
└─$ 

Aunque no lo pueda demostrar fehacientemente, es bastante probable que se hayan modificado las fechas de creación y modificación de este correo y de sus adjuntos porque es muy poco probable que todas estas acciones se realicen justo en el microsegundo cero.

El enunciado nos dice lo siguiente:

Congrats on making that determination! You are now asked to take this a step further, and determine the earliest date and time the email could have been sent based on the timing information you can locate within the file.

You will be examining the same email1. Included here again for convenience.

1SHA-256: 42B6FD78DAF38C03E1A744ECA1A0CB 44F6859AB892E0F32B01763EFD835B5648

Enter the timestamp in UTC in the following format: yyyy-mm-dd hh:mm (e.g., 2005-11-20 13:17)

Ya nos habíamos descargado el fichero pero si no lo tenemos lo podemos descargar otra vez desde este mismo reto. Como siempre usamos el comando sha256sum y comprobamos que el “hash” coincide.

(kali㉿kali)-[~/Desktop]
└─$ sha256sum Draft_Agreement.eml 
42b6fd78daf38c03e1a744eca1a0cb44f6859ab892e0f32b01763efd835b5648  Draft_Agreement.eml
                                                                           
┌──(kali㉿kali)-[~/Desktop]
└─$ 

El siguiente paso lógico sería pasar por VirusTotal el fichero para ver si tiene algo raro dentro pero vamos a omitir este paso porque ya sabemos que es algo que todos hacemos antes de abrir un fichero. :wink:

Nos están pidiendo la primera fecha en la que el correo pudo ser enviada. Como ya sabemos del artículo anterior no es posible que podamos obtener ese dato de las cabeceras del correo electrónico, pero si recordáis en el correo había un fichero adjunto llamado “Agreement_v2.pdf”.

──(kali㉿kali)-[~/Desktop]
└─$ grep 'Content-' Draft_Agreement.eml                              130 ⨯
Content-Type: multipart/mixed; 
Content-Length: 70085
Content-Type: multipart/alternative; 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Agreement_v2.pdf"
Content-ID: <bd1c0c4c-3c0e-20e0-f6b2-5bc858aab23a@yahoo.com>

Vamos a separarlo utilizando el comando munpack para poder manipularlo. Por cierto, en Kali no viene instalado por defecto y es necesario instalar el paquete mpack.

──(kali㉿kali)-[~/Desktop]
└─$ sudo munpack Draft_Agreement.eml
tempdesc.txt: File exists
)greement_v2.pdf.1 (application/pdf
                                                                           
┌──(kali㉿kali)-[~/Desktop]
└─$ 

Yo no tengo ganas de abrir el fichero porque ya sabemos las cosas malas que se pueden meter en un PDF y además dudo que sea tan sencillo de resolver como visualizar el fichero. Sin embargo, sí hay algo que sabemos de antes que nos puede ayudar. ¿Recordáis la fecha de la versión de Chrome que vimos en la cabecera “X-Mailer”? Pues vamos a rastrear el fichero PDF del adjunto para ver si podemos obtener cadenas de texto que hagan referencia al año 2020 mediante el comando pdf-parser.

(kali㉿kali)-[~/Desktop]
└─$ pdf-parser Agreement_v2.pdf|grep -B10 2020
 Type: /Annot
 Referencing: 46 0 R, 9 0 R

  <<
    /AP
      <<
        /N 46 0 R
      >>
    /C [1.0 1.0 1.0]
    /Contents (Dean Vinny)
    /CreationDate "(D:20201206151800-08'00')"
    /DA (0.898 0.1333 0.2157 rg /Helv 12 Tf)
    /DS (font: Helvetica,sans-serif 12.0pt; text-align:left; color:#E52237 )
    /F 4
    /M "(D:20201206151937-08'00')"

Aquí tenemos dos fechas muy interesantes. Si nos fijamos en el resultado se ve el contenido de una anotación cuyo contenido es el nombre de la persona y además dos fechas casi seguidas. La primera se corresponde con la fecha de creación de la anotación y la segunda con la fecha de la última modificación de esa anotación. Vamos a coger la segunda fecha porque parece difícil que se puede enviar un fichero antes de terminar de editarlo. En esta fecha que fijarse que es necesario calcular la diferencia horaria para sumarla a la hora y con eso ya tendríamos la respuesta, el 6 de diciembre de 2020 a las 23:19.

El enunciado nos dice lo siguiente:

You have received the email1 below in connection with a legal action. The timing of the email is critical. Examine the email and determine if it is more likely to be legitimate or fake.

Enter L for legitimate, F for fake. More to come based on your answer.

SHA-256: 42B6FD78DAF38C03E1A744ECA1A0CB 44F6859AB892E0F32B01763EFD835B5648

Si nos descargamos el fichero EML, el primer paso como siempre es comprobar la suma SHA256. Para ello usamos el comando sha256sum y comprobamos que el “hash” coincide.

(kali㉿kali)-[~/Desktop]
└─$ sha256sum Draft_Agreement.eml 
42b6fd78daf38c03e1a744eca1a0cb44f6859ab892e0f32b01763efd835b5648  Draft_Agreement.eml
                                                                           
┌──(kali㉿kali)-[~/Desktop]
└─$ 

El siguiente paso lógico sería pasar por VirusTotal el fichero para ver si tiene algo raro dentro pero vamos a omitir este paso porque ya sabemos que es algo que todos hacemos antes de abrir un fichero. :wink:

Yo prefiero usar un editor de textos para abrir los ficheros EML y así poder revisar tranquilamente su contenido. En este artículo voy a utilizar el comando grep para simplificar su redacción.

A primera vista las cabeceras que contienen fechas parecen legitimas y están sincronizadas por lo que el correo parece provenir del 7 de marzo de 2016, pero aquí tiene que haber algún truco, no me creo que sea tan sencillo.

──(kali㉿kali)-[~/Desktop]
└─$ grep Mar Draft_Agreement.eml
        Mon, 7 Mar 2016 14:38:34 -0800 (PST)
        Mon, 07 Mar 2016 14:38:34 -0800 (PST)
        Mon, 07 Mar 2016 14:38:34 -0800 (PST)
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Mon, 7 Mar 2016 22:38:33 +0000
Date: Mon, 7 Mar 2016 22:38:31 +0000 (UTC)

Comprobando el resto de cabeceras vemos que hay una interesante, la que se corresponde con “X-Mailer” que habla de la versión 87.0.4280.67 de Chrome y de Edge basado en Chromium tal y como se puede ver en la siguiente captura.

┌──(kali㉿kali)-[~/Desktop]
└─$ grep 'X-Mailer' Draft_Agreement.eml        
X-Mailer: WebService/1.1.17111 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.67 Safari/537.36 Edg/87.0.664.55

Aquí hay algo raro. Si buscamos en Google podemos confirmar que esa versión de Chrome es del 17 de noviembre de 2020, con lo que es imposible que el correo sea del año 2016.

¡Bingo! Ya tenemos la prueba para demostrar que la fecha del correo fue alterada.

Con este pequeño cambio en el fichero /etc/systemd/logind.conf se puede alterar el comportamiento por defecto y, en mi caso, no haga nada. La verdad es que se puede configurar cualquiera de las siguientes cinco opciones:

• HandleLidSwitch=suspend. Suspende el equipo y es el comportamiento por defecto.
• HandleLidSwitch=lock. Bloquea la pantalla.
• HandleLidSwitch=ignore. No hace nada, que sería el comportamiento que yo quiero utilizar.
• HandleLidSwitch=poweroff. Apaga el equipo.
• HandleLidSwitch=hibernate. Hiberna el equipo.

El proceso es sencillo, hay que editar el fichero /etc/systemd/logind.conf con permisos de root y buscar la línea que pone #HandleLidSwitch=suspend y cambiarla por cualquiera de las cinco de arriba según corresponda.


Después solo hay que reiniciar el servicio logind mediante el siguiente comando y ya hemos terminado.

systemctl restart systemd-logind.service

Escenario

En nuestro escenario partimos de la presencia de un servidor con dos interfaces de red, la primera en la red 10.0.2.0/24 que tiene la puerta de enlace por defecto en la IP 10.0.2.2, vamos a llamarla “red pública”, y la segunda en la red 192.168.56.20/24, vamos a llamarla “red de gestión”. Queremos que todo el tráfico de la red de gestión se enrute por la segunda interfaz por temas de seguridad.

[root@routes ~]# ip addr show | grep "inet\b" | awk '{print $2" "$NF}'
127.0.0.1/8 lo
10.0.2.15/24 enp0s3
192.168.56.22/24 enp0s8
[root@routes ~]# ip route|grep default
default via 10.0.2.2 dev enp0s3 proto static metric 100 

Instrucciones

Antes de comenzar a configurar PBR, en CentOS 7 es necesario instalar el siguiente paquete:

[root@routes ~]# yum install -y NetworkManager-dispatcher-routing-rules

El siguiente paso es crear la entrada de la política de enrutado:

[root@routes ~]# echo "2 mgt" >> /etc/iproute2/rt_tables

El siguiente paso es crear las reglas para la interfaz enp0s8:

[root@routes ~]# vi /etc/sysconfig/network-scripts/rule-enp0s8
from 192.168.56.22/32 table mgt
to 192.168.56.22/32 table mgt

El siguiente paso es crear la ruta por defecto para la interfaz enp0s8:

[root@routes ~]# vi /etc/sysconfig/network-scripts/route-enp0s8
default via 192.168.56.21 dev enp0s8 table mgt

Una vez configurado todo, tenemos que recargar la configuración para hacerla efectiva:

[root@routes ~]# nmcli connection reload

Comrpobamos que todo está configurado según esperabamos:

[root@routes ~]# ip rule show
0:	from all lookup local 
32764:	from all to 192.168.56.22 lookup mgt
32765:	from 192.168.56.22 lookup mgt 
32766:	from all lookup main 
32767:	from all lookup default
[root@routes ~]# ip route show table mgt
default via 192.168.56.21 dev enp0s8