En esta segunda parte veremos las configuraciones referentes al host «tservice» y cómo se configurará OpenVPN como cliente en Linux (para el tservice) y en Windows para la estaciones de trabajo de los administradores (en caso de usar Windows). También se analizará la instalación y configuración de Guacamole como Remote Desktop Gateway (RDG) en Linux.
1. Configuraciones en host “tservice”
En este apartado se configurará el host para que sirva de intermediario entre la red aislada y la red pública. Para el uso de estas herramientas por parte de los usuarios que acceden desde sus terminales móviles y, por tanto, desde el TUN10, será necesario configurar al host “tservice” para que forme parte de esta red. Esto posibilitará que con la debida configuración del servidor, realizada anteriormente, usuarios del TUN10 y el host “tservice”, puedan verse entre ellos y poder así, brindar el servicio a los mismos.
1.1. Entorno gráfico ligero XFCE
Necesitamos que “tservice” tenga un entorno visual de escritorio, para que una vez se acceda a éste por RDP o por VNC, se pueda ejecutar el navegador y acceder a su vez a la red aislada de gestión. En este caso usaremos el escritorio XFCE, el cual como indica la documentación oficial, su objetivo es “ser visualmente atractivo y fácil de usar”.
1 | apt install -y xfce4 |
Instalamos, opcionalmente, el terminal de gnome:
1 | apt install -y gnome-terminal |
Si desde la consola local (no desde SSH) ejecutamos el siguiente comando, podremos iniciar el entorno escritorio XFCE:
1 | startx |
Al seleccionar la opción predeterminada XFCE se encuentra listo para que trabajemos sobre él.
Una vez reiniciado el sistema se perderán los cambios y XFCE no iniciará. Para habilitarlo con el inicio del sistema, ejecutamos la siguiente línea:
1 | systemctl set-default graphical.target |
Debe devolver lo siguiente:
1 | Created symlink /etc/systemd/system/graphical.target → /lib/systemd/system/graphical.target. |
Con esto nuestro sistema iniciara con entorno de escritorio XFCE.
Podemos instalar Firefox para usarlo como navegador por defecto:
1 | apt install firefox-esr -y |
1.2. Implementación y configuración de TigerVNC
Existen varios servidores VNC disponibles en Linux. En este caso usaremos «TigerVNC», porque funciona mejor con Guacamole. TigerVNC es una bifurcación de TightVNC, totalmente de código abierto, con desarrollo y debate que se realiza a través de listas de correo de acceso público y repositorios. Esta aplicación se preocupa especialmente del desempeño y la función de mostrar pantalla (escritorio) remotamente:
Instalamos el TigerVNC:
1 | apt install -y tigervnc-standalone-server |
Corremos el siguiente comando para iniciar el servidor VNC:
1 | vncserver |
Cuando «TigerVNC» inicia por primera vez, solicita una contraseña VNC y almacena el dichero de la contraseña en el directorio «~/.vnc». Esta debe tener una longitud no más de 8 caracteres:
1 2 3 4 5 6 7 8 9 10 11 12 13 | You will require a password to access your desktops. Password:***** <-- vncadmin Verify:***** <-- vncadmin Would you like to enter a view-only password (y/n)? n New 'tservice.midominio.local:1 (root)' desktop at :1 on machine tservice.midominio.local Starting applications specified in /etc/X11/Xvnc-session Log file is /root/.vnc/tservice.midominio.local:1.log Use xtigervncviewer -SecurityTypes VncAuth -passwd /root/.vnc/passwd :1 to connect to the VNC server. |
Note el «:1» que nos devuelve en la salida después del hostname. Esto significa que el servidor estará corriendo en el puerto TCP 5901 (5900+1). Se pueden tener varias instancias, siempre y cuando se cumpla que :X especifique el puerto para 590X (5900+X).
El servidor «TigerVNC» no se instala con ninguna unidad de servicio de systemd. Para hacer que inicie con el sistema, creamos el servicio:
1 | nano /etc/systemd/system/vncserver@.service |
Agregamos lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | [Unit] Description=Remote Desktop Service (VNC) After=syslog.target network.target [Service] Type=forking User=root Group=root WorkingDirectory=/home/root ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1 ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 -localhost :%i ExecStop=/usr/bin/vncserver -kill :%i [Install] WantedBy=multi-user.target |
Creamos el directorio «/home/root:
1 | mkdir /home/root |
Detenemos la actual instancia del servidor VNC:
1 | vncserver -kill :1 |
Iniciamos el servicio con «systemd»:
1 | systemctl start vncserver@1.service |
Habilitamos el servicio con el inicio del sistema:
1 | systemctl enable vncserver@1.service |
Verificamos su estado:
1 | systemctl status vncserver@1.service |
El servidor TigerVNC estará escuchando en el puerto 5901:
1 | ss -lnpt | grep vnc |
Debe devolver lo siguiente:
1 2 | LISTEN 0 5 127.0.0.1:5901 0.0.0.0:* users:(("Xtigervnc",pid=29685,fd=7)) LISTEN 0 5 [::1]:5901 [::]:* users:(("Xtigervnc",pid=29685,fd=8)) |
1.2.1. Múltiples instancias de VNC y múltiples perfiles de Firefox
Pensando en la gestión de múltiples sesiones, será necesario que TigerVNC inicie varias instancias por un puerto diferente, cada una. Esto lo haremos con el objetivo de que, cuando se haga una conexión a cada una de estas instancias, se muestre un escritorio para cada una, sin interrumpir el trabajo de las demás.
Habilitamos que inicien con el sistema varias instancias VNC para el localhost:
1 2 3 4 5 6 | systemctl enable vncserver@2.service systemctl enable vncserver@3.service systemctl enable vncserver@4.service systemctl enable vncserver@5.service systemctl enable vncserver@6.service systemctl enable vncserver@7.service |
Verificamos las instancias iniciadas:
1 | ss -lnpt | grep vnc |
Debe devolver lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | LISTEN 0 5 0.0.0.0:5901 0.0.0.0:* users:(("Xtigervnc",pid=821,fd=7)) LISTEN 0 5 0.0.0.0:5902 0.0.0.0:* users:(("Xtigervnc",pid=1947,fd=7)) LISTEN 0 5 0.0.0.0:5903 0.0.0.0:* users:(("Xtigervnc",pid=2251,fd=7)) LISTEN 0 5 0.0.0.0:5904 0.0.0.0:* users:(("Xtigervnc",pid=2429,fd=7)) LISTEN 0 5 0.0.0.0:5905 0.0.0.0:* users:(("Xtigervnc",pid=2607,fd=7)) LISTEN 0 5 0.0.0.0:5906 0.0.0.0:* users:(("Xtigervnc",pid=2783,fd=7)) LISTEN 0 5 0.0.0.0:5907 0.0.0.0:* users:(("Xtigervnc",pid=2959,fd=7)) LISTEN 0 5 [::]:5901 [::]:* users:(("Xtigervnc",pid=821,fd=8)) LISTEN 0 5 [::]:5902 [::]:* users:(("Xtigervnc",pid=1947,fd=8)) LISTEN 0 5 [::]:5903 [::]:* users:(("Xtigervnc",pid=2251,fd=8)) LISTEN 0 5 [::]:5904 [::]:* users:(("Xtigervnc",pid=2429,fd=8)) LISTEN 0 5 [::]:5905 [::]:* users:(("Xtigervnc",pid=2607,fd=8)) LISTEN 0 5 [::]:5906 [::]:* users:(("Xtigervnc",pid=2783,fd=8)) LISTEN 0 5 [::]:5907 [::]:* users:(("Xtigervnc",pid=2959,fd=8)) |
Abrimos el navegador y accedemos al gestor de perfiles de Firefox, con el comando, mostrado en la imagen:
Siguiendo este mismo procedimiento, se crea los demás perfiles de Firefox, hasta llegar a los 7 requeridos (total de administradores de red):
- franco.diaz
- naylet.carballo
- maybel
- danilo.noa
- mairela.usatorres
- pavel
- mayra.perez
De esta manera, cada vez que un usuario se conecte a una instancia VNC del localhost, podrá ejecutar su propio navegador sin interrumpir el trabajo de otro administrador que esté administrando simultáneamente desde el Firefox. Para ello, es necesario que se ejecute desde la consola (genoma-terminal, en este caso), dentro de cada sesión VNC, el comando que permitirá lanzar el gestor de perfiles de Firefox:
1 | firefox --profilemanager |
O simplemente ejecutar la aplicación desde el entorno gráfico. Cualquiera de las dos vías nos llevara a donde queremos:
Nos abrirá una instancia de Firefox para el perfil “franco.diaz”, en este caso:
Lo anterior significa que, cada usuario podrá trabajar individualmente con su perfil de Firefox, siendo el usuario del sistema “root” quien ejecute siempre el programa.
Es importante resaltar, el desempeño que pueda tener el servidor con tantos perfiles de Firefox ejecutándose simultáneamente y varias instancias VNC. Siempre probar y analizar su consumo, por si es necesario dotar al servidor de mayores recursos hardware.
1.3. Implementación y configuración de Guacamole
Guacamole es un RDG (Remote Desktop Gateway) sin cliente dedicado. Soporta protocolos estándar como SSH, VNC, RDP. Gracias a HTML5, una vez Guacamole es instalado en un servidor, todo lo que se necesita para acceder a los escritorios es un navegador. Se trata de una solución de software libre que nos permitirá gestionar remotamente nuestros servidores vía web.
1.3.1. Servidor Guacamole
Instalar paquetes de dependencia:
1 | apt install -y build-essential libcairo2-dev libjpeg62-turbo-dev libpng-dev libtool-bin libossp-uuid-dev libvncserver-dev freerdp2-dev libssh2-1-dev libtelnet-dev libwebsockets-dev libpulse-dev libvorbis-dev libwebp-dev libssl-dev libpango1.0-dev libswscale-dev libavcodec-dev libavutil-dev libavformat-dev |
Descargamos el servidor de Guacamole y lo descompactamos:
1 2 3 | cd /tmp wget https://downloads.apache.org/guacamole/1.3.0/source/guacamole-server-1.3.0.tar.gz tar xfz guacamole-server-*.tar.gz |
Accedemos al directorio y lo preparamos para la compilación:
1 2 | cd guacamole-server-1.3.0 ./configure --with-init-dir=/etc/init.d --enable-allow-freerdp-snapshots |
Compilamos el servidor:
1 | make |
Instalamos el servidor:
1 | make install |
Actualizamos la cache del sistema de las bibliotecas instaladas:
1 | ldconfig |
Recargamos «systemd», para que pueda encontrar el servicio «guacd» (demonio proxy Guacamole), instalado en el directorio «/etc/init.d»:
1 | systemctl daemon-reload |
Iniciamos el servicio:
1 | systemctl start guacd |
Habilitamos auto-inicio con el sistema:
1 | systemctl enable guacd |
Verificamos su estado:
1 | systemctl status guacd |
El servicio debe estar funcionando y escuchando por la IP 127.0.0.1 y puerto 4822:
1 | ss -lnpt | grep guacd |
Debe devolver lo siguiente y confirmar lo dicho anteriormente:
1 | LISTEN 0 5 127.0.0.1:4822 0.0.0.0:* users:(("guacd",pid=5883,fd=4)) |
Creamos el directorio y fichero de configuración de Guacamole:
1 2 | mkdir /etc/guacamole/ nano /etc/guacamole/guacamole.properties |
Agregamos las siguientes líneas al fichero, que ya vienen por defecto habilitadas en el servicio, pero que, de esta manera, podremos editar cuando la necesidad lo requiera:
1 2 3 | # Hostname and port of guacamole proxy guacd-hostname: localhost guacd-port: 4822 |
1.3.2. Cliente web para Guacamole
La aplicación web de Guacamole está escrita en Java, así que necesitaremos instalar lo siguiente:
1 | apt install -y tomcat9 tomcat9-admin tomcat9-common tomcat9-user |
Habilitamos su inicio con el sistema:
1 | systemctl enable tomcat9 |
Apache Tomcat escuchara en el puerto 8080:
1 | ss -lnpt | grep java |
Debe devolver lo siguiente y confirmar lo dicho anteriormente:
1 | LISTEN 0 100 *:8080 *:* users:(("java",pid=10867,fd=37)) |
Descargamos la aplicación web de Guacamole:
1 2 | cd /tmp wget https://downloads.apache.org/guacamole/1.3.0/binary/guacamole-1.3.0.war |
Movemos el fichero al directorio de la aplicación web:
1 | mv guacamole-1.3.0.war /var/lib/tomcat9/webapps/guacamole.war |
Reiniciamos tomcat9 y guacd:
1 | systemctl restart tomcat9 guacd |
1.3.3. MariaDB para Guacamole
Instalamos MariaDB:
1 | apt install -y mariadb-server mariadb-client |
Aseguramos la instalación de MariaDB:
1 | mysql_secure_installation |
Respondemos según convenga:
- Enter current password for root (enter for none): ENTER
- Set root password? [Y/n] y
- New password: *****
- Re-enter new password: *****
- Remove anonymous users? [Y/n] y
- Disallow root login remotely? [Y/n] y
- Remove test database and access to it? [Y/n] y
- Reload privilege tables now? [Y/n] y
Creamos la DB y el usuario:
1 | mysql -p |
En color blanco se especifican los comandos necesarios para la creación de la DB, el usuario y sus permisos:
1 2 3 4 5 | MariaDB [(none)]> CREATE DATABASE guacamole_db; MariaDB [(none)]> CREATE USER 'guacamole_user'@'localhost' IDENTIFIED BY 'passw0rd'; MariaDB [(none)]> GRANT SELECT,INSERT,UPDATE,DELETE ON guacamole_db.* TO 'guacamole_user'@'localhost'; MariaDB [(none)]> FLUSH PRIVILEGES; MariaDB [(none)]> quit; |
Descargamos la extensión «jdbc-extension», para el uso de la autenticación por DB, en este caso MariaDB. Esto será necesario para poder autenticarnos con el usuario de administración de Guacamole “guacadmin”:
1 2 3 | cd /tmp wget http://apache.mirror.digionline.de/guacamole/1.3.0/binary/guacamole-auth-jdbc-1.3.0.tar.gz tar xfz guacamole-auth-jdbc-1.3.0.tar.gz |
Importamos la DB:
1 | cat guacamole-auth-jdbc-1.3.0/mysql/schema/*.sql | mysql -u root -p guacamole_db |
Tras especificar la contraseña root de MariaDB, se importará la DB.
1 2 | Creamos el directorio de extensiones de Guacamole: mkdir /etc/guacamole/extensions/ |
Instalamos la extensión, moviendo al directorio de extensiones:
1 | mv guacamole-auth-jdbc-1.3.0/mysql/guacamole-auth-jdbc-mysql-1.3.0.jar /etc/guacamole/extensions/ |
Instalación del driver JDBC, para que Guacamole se conecte correctamente a la DB:
1 2 3 | cd /tmp wget https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-8.0.23.tar.gz tar xfz mysql-connector-java-8.0.23.tar.gz |
Creamos el directorio para el driver en guacamole y lo agregamos a dicho directorio:
1 2 | mkdir /etc/guacamole/lib mv mysql-connector-java-8.0.23/mysql-connector-java-8.0.23.jar /etc/guacamole/lib/ |
1.3.4. Ajustes para autenticación por LDAP
Para que Guacamole pueda autenticar usuarios LDAP, primero hay que configurar la autenticación por MySQL/MariaDB, para acceder con el usuario de administración
1 | nano /etc/guacamole/guacamole.properties |
Agregamos lo siguiente:
1 2 3 4 5 6 7 | # [...] # Datos para Auth MySQL/MariaDB mysql-hostname: localhost mysql-port: 3306 mysql-database: guacamole_db mysql-username: guacamole_user mysql-password: passw0rd |
Descargamos el plugin de Guacamole para autenticación por LDAP y la descompactamos:
1 2 3 | cd /tmp wget https://apache.mirror.iphh.net/guacamole/1.3.0/binary/guacamole-auth-ldap-1.3.0.tar.gz tar xfz guacamole-auth-ldap-1.3.0.tar.gz |
Movemos el plugin al directorio de extensiones de Guacamole:
1 | mv guacamole-auth-ldap-1.3.0/guacamole-auth-ldap-1.3.0.jar /etc/guacamole/extensions |
Agregamos la configuración de autenticación LDAP al fichero de Guacamole:
1 | nano /etc/guacamole/guacamole.properties |
Agregamos lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | # [...] # Auth provider class auth-provider: net.sourceforge.guacamole.net.auth.ldap.LDAPAuthenticationProvider # Datos para Auth LDAP/AD ldap-hostname: dc1.empresa.midominio.cu ldap-port: 389 ldap-user-base-dn: ou=Usuarios,dc=empresa,dc=midominio,dc=cu ldap-username-attribute: samAccountName ldap-config-base-dn: cn=Users,dc=empresa,dc=midominio,dc=cu ldap-encryption-method: none ldap-search-bind-dn:cn=administrator,cn=Users,dc=empresa,dc=midominio,dc=cu ldap-search-bind-password:Admin*123 ldap-user-search-filter:(&(objectClass=person)(|(memberOf=cn=Guacamole,ou=Grupos,dc=empresa,dc=midominio,dc=cu))) |
El servidor LDAP estará integrado en un AD (Samba4) y no se usará método de encriptación alguno para la comunicación entre el LDAP y el Guacamole.
NOTA: En el servidor AD necesitamos crear el grupo «Tservice» para los usuarios que vayan a hacer uso del Guacamole:
1 2 3 | samba-tool group add "Guacamole" \ --groupou="OU=Grupos" \ --description="Grupo para acceso al Terminal Service de gestion" |
Creamos el usuario “guacadmin” en el AD:
1 2 3 | samba-tool user create guacadmin guacamoleadmin \ --userou="OU=Servicios,OU=Usuarios" \ --given-name="guacadmin" |
Agregamos al grupo creado, los usuarios del AD que vayan a hacer uso del Guacamole:
1 2 | samba-tool group addmembers "Guacamole" guacadmin samba-tool group addmembers "Guacamole" usuario1.apellido |
Reiniciamos Tomcat y y el servidor de Guacamole:
1 | systemctl restart tomcat9 guacd |
Accedemos al cliente web de Guacamole:
http://192.168.120.50:8080/guacamole
Nos autenticamos con el usuario de administración:
- Usuario: guacadmin
- Contraseña: guacadmin
Nos recibe la página inicial del servicio:
Nos desplazamos a la esquina superior derecha, damos clic en la ventana desplegable y click sobre “Configuración”:
Accedemos a la pestaña “Usuarios” para gestionar los permisos de los usuarios LDAP:
Vemos cómo Guacamole identifica los usuarios miembros del grupo “Guacamole” del AD para Guacamole. Ahora accedemos en el usuario del AD “usuario1.apellido”:
En este caso estaremos ajustando permisos para un usuario del AD con permisos de administración en Guacamole:
Damos click en “Guardar” para aplicar los cambios.
Ahora ya podremos acceder Guacamole con el usuario del AD “usuario1.apellido” y tener permisos de administración sobre el servicio:
Con esto realizado ya nos encontramos en condiciones de configurar conexiones. A continuación, se muestra un ejemplo de la configuración para una conexión por VNC (para acceder por escritorio remoto) al propio servidor “tservice”:
Vamos a la sección “Inicio” para acceder a las conexiones disponibles para el usuario:
En este caso aparecerán todas las conexiones habilitadas para este usuario:
Al intentar acceder a la conexión con nombre “tservice”, que está configurada para VNC, nos deberá pedir automáticamente la contraseña configurada en TigerVNC para hacer uso de la instancia 1 del servidor VNC (habíamos especificado vncadmin):
Se puede configurar la conexión VNC para que guarde la contraseña de acceso a la instancia del TigerVNC especificada.
Tras una autenticación exitosa, nos debe mostrar el escritorio de XFCE, entorno gráfico configurado para el host “tservice”:
Gucamole nos permite interactuar con algunas herramientas mediante la combinación de teclas “Crtl+Shift+Alt” (para acceder a ellas y para ocultarlas también). Podremos incluso, pegar texto usando la combinación “Crtl+Shift+v”. La barra de herramientas desplegable nos permite también subir y descargar ficheros, si el usuario tiene permitido el servicio SFT para la conexión.
1.3.5. Asegurando el acceso al cliente web con HTTPS
Apache Tomcat se encuentra escuchando por el puerto 8080. Para tener una forma más sencilla de acceder al Guacamole, instalaremos Nginx y lo configuraremos como un proxy inverso, para que se acceda por el nombre de dominio “guacamole.empresa.midominio.cu” (se necesita una entrada en el DNS) para la IP del host “tservice” de cara a la red pública. Se redireccionará el tráfico de HTTP a HTTPS, cuando se intente acceder con nombre de servidor “guacamole.empresa.midominio.cu”.
Instalamos Nginx:
1 | apt install nginx -y |
Configuramos un bloque de configuración para Guacamole:
1 | openssl req -x509 -nodes -days 730 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt |
Respondemos según convenga, lo resaltado en color blanco:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Generating a RSA private key ........................................................................................................................................................................+++++ ..................+++++ writing new private key to '/etc/ssl/private/nginx-selfsigned.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:CU State or Province Name (full name) [Some-State]:HABANA Locality Name (eg, city) []:LaHabana Organization Name (eg, company) [Internet Widgits Pty Ltd]:EMPRESA Organizational Unit Name (eg, section) []:REDES Common Name (e.g. server FQDN or YOUR name) []:guacamole.empresa.midominio.cu Email Address []:postmaster@empresa.midominio.cu |
Generamos el parámetro DH. Con 2048 bits debería ser suficientes, pero por requerimientos de la empresa, lo llevaremos a su máximo valor, al tratarse de un acceso que pudiera ser desde internet (aun cuando sea un acceso desde una VPN):
1 | openssl dhparam -out /etc/nginx/dhparam.pem 4096 |
Creamos un nuevo fragmento de configuración de Nginx en el directorio “/etc/nginx/snippets”:
1 | nano /etc/nginx/snippets/self-signed.conf |
Agregamos lo siguiente:
1 2 | ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt; ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key; |
Crearemos otra pequeña configuración que defina algunas opciones SSL:
1 | nano /etc/nginx/snippets/ssl-params.conf |
Agregamos lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | # Autorizar solamente el uso de los protocolos TLSv1.2 y TLSv1.3 ssl_protocols TLSv1.2 TLSv1.3; # Imponer la seleccion del cifrado por el servidor y no por el cliente ssl_prefer_server_ciphers on; # Autorizar cifrados de tipo AEAD y Perfect Forward Secrecy (FS-ECDHE) para TLSv1.2: # (para TLSv1.3 no es necesario especificar los cifrados, pues todos son seguros) ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256; # Especificar una curva para cifrados ECDHE: ssl_ecdh_curve secp384r1; # Parametro Diffie-Hellman para la suite de cifrados de tipo DHE: ssl_dhparam /etc/nginx/dhparam.pem; # Habilitar reanudacion de la sesion para mejorar rendimiento de HTTPS: ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_session_tickets off; # Habilitar OCSP stapling: ssl_stapling on; ssl_stapling_verify on; resolver ns1.empresa.midominio.cu valid=300s; resolver_timeout 5s; # HSTS (HTTP Strict Transport Security): add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"; # Proteccion contra ataque Clickjacking: add_header X-Frame-Options SAMEORIGIN; # Proteccion de rastreo del navegador: add_header X-Content-Type-Options nosniff; # Filtro Cross-site scripting (XSS): add_header X-XSS-Protection "1; mode=block"; |
Creamos el bloque de configuración de Nginx para Prometheus:
1 | nano /etc/nginx/sites-available/guacamole.vhost |
Agregamos lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | server { listen 80; server_name guacamole.empresa.midominio.cu; # Redireccion permanente a HTTPS return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name guacamole.empresa.midominio.cu; include snippets/self-signed.conf; include snippets/ssl-params.conf; access_log /var/log/nginx/guac_access.log; error_log /var/log/nginx/guac_error.log; location / { proxy_pass http://127.0.0.1:8080/guacamole/; proxy_buffering off; proxy_http_version 1.1; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_cookie_path /guacamole/ /; } } |
Habilitamos la configuración:
1 | ln -s /etc/nginx/sites-available/guacamole.vhost /etc/nginx/sites-enabled/ |
Verificamos que la configuración no tenga errores de sintaxis:
1 | nginx -t |
Si todo está bien, debe devolvernos lo siguiente, ignorando la advertencia que nos indica:
1 2 3 | nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt" nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful |
Esta configuración en particular arroja una advertencia ya que nuestro certificado auto-firmado no puede usar el engrapado SSL. Esto se espera y nuestro servidor aún puede cifrar las conexiones correctamente, por lo que obviamos la advertencia.
Modificaremos el fichero de configuración principal de Nginx, para implementar algunas medidas de seguridad extra:
1 | nano /etc/nginx/nginx.conf |
Deshabilitamos que Nginx envíe su versión en las paginas de error o en las cabeceras del servidor, y también deshabilitamos la compresión por gzip, modificando las siguientes líneas:
1 2 3 4 5 | # [...] server_tokens off; # [...] gzip off; # [...] |
Reiniciamos el servicio:
1 | systemctl restart nginx |
El servidor web Nginx está funcionando ahora como proxy inverso para Guacamole:
https://guacamole.empresa.midominio.cu
NOTA: Se recomienda cerrar el puerto 8080 de cara a la red empresarial.
Para el caso de los usuarios que acceden por el VPN, el proxy inverso no funcionará, ya que desde el TUN10 no se tiene acceso por enrutamiento al DNS, con toda intensión, pues no se desea que lo tengan. La única opción que hay para proteger las credenciales de estos usuarios al acceder al cliente web de Guacamole, es configurar Tomcat para que funcione por el 8443 para HTTPS. Así como Tomcat usa 8080 para alejarse del puerto 80, también da la posibilidad a las conexiones cifradas mediante el 8443, alejándose el 443.
Lo primero será crear el certificado en formato “jks” para Java.
NOTA: Tomcat usa tres diferentes implementaciones de SSL:
- JSSE: Implementación provista como parte de “Java runtime”.
- JSSE: Implementación que usa el OpenSSL.
- APR: implementación, que usa el motor por defecto de OpenSSL.
Generamos el certificado para ser usado por JSSE:
1 | keytool -genkey -alias tomcat -keyalg RSA -keystore /var/lib/tomcat9/conf/localhost-rsa.jks |
Respondemos las preguntas, acorde a una información que sea lógica para el usuario que revise el certificado:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Introduzca la contraseña del almacén de claves: Volver a escribir la contraseña nueva: ¿Cuáles son su nombre y su apellido? [Unknown]: guacamole.empresa.midominio.cu ¿Cuál es el nombre de su unidad de organización? [Unknown]: REDES ¿Cuál es el nombre de su organización? [Unknown]: EMPRESA ¿Cuál es el nombre de su ciudad o localidad? [Unknown]: LaHabana ¿Cuál es el nombre de su estado o provincia? [Unknown]: HABANA ¿Cuál es el código de país de dos letras de la unidad? [Unknown]: CU ¿Es correcto CN=guacamole.empresa.midominio.cu, OU=REDES, O=EMPRESA, L=LaHabana, ST=HABANA, C=CU? [no]: si |
Editamos el siguiente fichero:
1 | nano /var/lib/tomcat9/conf/server.xml |
Localizamos en el fichero “JSSE style configuration is used below” y después del primer “–>” que le sigue, agregamos lo siguiente debajo de esa flecha:
1 2 3 4 5 6 7 8 9 | <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true"> <SSLHostConfig protocols="TLSv1.3"> <Certificate certificateKeystoreFile="conf/localhost-rsa.jks" certificateKeystorePassword="changeit" certificateKeyAlias="tomcat" type="RSA" /> </SSLHostConfig> </Connector> |
Reiniciamos tomcat9:
1 | systemctl restart tomcat9 |
Tomcat deberá estar escuchando ahora por el 8080 (para HTTP) y el 8443 (para HTTPS):
1 | ss -lnpt | grep java |
Debe devolver algo, como lo siguiente:
1 2 | LISTEN 0 100 *:8080 *:* users:(("java",pid=29823,fd=37)) LISTEN 0 100 *:8443 *:* users:(("java",pid=29823,fd=43)) |
Con esto configurado, se resuelve el problema de los usuarios dentro del TUN10, los cuales podrán acceder al Guacamole mediante el siguiente enlace:
https://192.168.254.50:8443/guacamole
Siendo “192.168.254.50” la dirección IP fija del “tservice”, por dentro del TUN10. Lo mismo sucederá por el TUN11, pero con la IP “192.168.253.50”.
NOTA: Se recomienda cerrar el puerto 8080 para el TUN10 y el TUN11.
1.4. Instancias OpenVPN en modo cliente
Se repetirá el mismo procedimiento realizado en el host “vpn” para la instalación de OpenVPN.
Instalamos OpenSSL y libssl1.1 (1.1.1d), easy-rsa (3.0.6-1) y openvpn (2.4.7-1) por los repos oficiales de Buster:
1 | apt install openssl libssl-dev easy-rsa openvpn -y |
Agregamos los repos de Bullseye:
1 2 | echo "deb [trusted=yes] https://ftp.debian.org/debian bullseye main contrib non-free" > /etc/apt/sources.list.d/bullseye.list apt update |
Instalación de OpenSSL (1.1.1i) y sus librerías actualizadas
1 | apt install openssl libssl-dev -y |
Instalación de OpenVPN (2.5.0-1):
1 | apt install openvpn -y |
Comentamos los repos de Bullseye y volvemos actualizar el listado:
1 2 | echo "#deb https://ftp.debian.org/debian bullseye main contrib non-free" > /etc/apt/sources.list.d/bullseye.list apt update |
Creamos el siguiente enlace simbólico:
1 | ln -s /usr/sbin/openvpn /usr/local/sbin/ |
Directorio que albergará la ca, certificado y llaves para cliente:
1 2 | mkdir -p /etc/openvpn/client/ovpn10/auth mkdir -p /etc/openvpn/client/ovpn11/auth |
Creamos el fichero de configuración de OpenVPN para TUN10:
1 | nano /etc/openvpn/client/ovpn10.conf |
Agregamos lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 | # ____ _ ______ _ __ _________ __ # / __ \____ ___ ____| | / / __ \/ | / / / ____/ (_)__ ____ / /_ # / / / / __ \/ _ \/ __ \ | / / /_/ / |/ / / / / / / _ \/ __ \/ __/ # / /_/ / /_/ / __/ / / / |/ / ____/ /| / / /___/ / / __/ / / / /_ # \____/ .___/\___/_/ /_/|___/_/ /_/ |_/ \____/_/_/\___/_/ /_/\__/ # /_/ # Especificar modo de funcionamiento client # Tipo de interfaz dev tun10 # Protocolo de transporte a usar proto udp # Servidor remoto remote 192.168.130.103 11940 # No almacenar en RAM las credenciales de autenticacion auth-nocache # Autenticarse con el servidor por usuario y password auth-user-pass # Mantener estado de llave e interfaz, aun despues del reinicio persist-key persist-tun # Rutas para CA, y certificado y llave del cliente, con las capas de TLS activadas tls-client ca /etc/openvpn/client/ovpn10/auth/ca.crt cert /etc/openvpn/client/ovpn10/auth/tservice.crt key /etc/openvpn/client/ovpn10/auth/tservice.key # HMAC firewall con encriptacion de mensajes con llave pre-compartida tls-crypt /etc/openvpn/client/ovpn10/auth/ta.key 1 # Usar AES-GCM para encriptacion de datos cipher AES-256-GCM # Migrar de cifrados obsoletos data-ciphers AES-256-GCM # Medida para prevenir que un cliente use su certificado para hacerse pasar por un servidor remote-cert-tls server # Para certificados con el estandar X509v3 de la UIT remote-cert-eku "TLS Web Server Authentication" # Usar SHA512 para autenticar datos encriptados auth SHA512 # Nivel de verbosidad de los logs verb 3 # Intentar de resolver indefinidamente el hostname del servidor resolv-retry infinite # Permitir compresion y usar la ultima version de compresion disponible allow-compression yes compress lz4-v2 # No enlazarse a un puerto local especifico nobind # Degradar privilegios despues de la inicializacion (solo para clientes no-Windows) user nobody group nogroup # Si el cliente no es sobre Windows y presenta problemas con la opcion "block-outside-dns", descomentar la siguiente opcion ignore-unknown-option block-outside-dns |
Creamos el fichero de configuración de OpenVPN para TUN11:
1 | nano /etc/openvpn/client/ovpn11.conf |
Agregamos lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 | # ____ _ ______ _ __ _________ __ # / __ \____ ___ ____| | / / __ \/ | / / / ____/ (_)__ ____ / /_ # / / / / __ \/ _ \/ __ \ | / / /_/ / |/ / / / / / / _ \/ __ \/ __/ # / /_/ / /_/ / __/ / / / |/ / ____/ /| / / /___/ / / __/ / / / /_ # \____/ .___/\___/_/ /_/|___/_/ /_/ |_/ \____/_/_/\___/_/ /_/\__/ # /_/ # Especificar todo de funcionamiento client # Tipo de interfaz dev tun11 # Protocolo de transporte a usar proto udp # Servidor remoto remote 192.168.130.103 11941 # No almacenar en RAM las credenciales de autenticacion auth-nocache # Autenticarse con el servidor por usuario y password auth-user-pass # Mantener estado de llave e interfaz, aun despues del reinicio persist-key persist-tun # Rutas para CA, y certificado y llave del cliente, con las capas de TLS activadas tls-client ca /etc/openvpn/client/ovpn11/auth/ca.crt cert /etc/openvpn/client/ovpn11/auth/tservice.crt key /etc/openvpn/client/ovpn11/auth/tservice.key # HMAC firewall con encriptacion de mensajes con llave pre-compartida tls-crypt /etc/openvpn/client/ovpn11/auth/ta.key 1 # Usar AES-GCM para encriptacion de datos cipher AES-256-GCM # Migrar de cifrados obsoletos data-ciphers AES-256-GCM # Medida para prevenir que un cliente use su certificado para hacerse pasar por un servidor remote-cert-tls server # Para certificados con el estandar X509v3 de la UIT remote-cert-eku "TLS Web Server Authentication" # Usar SHA512 para autenticar datos encriptados auth SHA512 # Nivel de verbosidad de los logs verb 3 # Intentar de resolver indefinidamente el hostname del servidor resolv-retry infinite # Permitir compresion y usar la ultima version de compresion disponible allow-compression yes compress lz4-v2 # No enlazarse a un puerto local especifico nobind # Degradar privilegios despues de la inicializacion (solo para clientes no-Windows) user nobody group nogroup # Si el cliente no es sobre Windows y presenta problemas con la opcion "block-outside-dns", descomentar la siguiente opcion ignore-unknown-option block-outside-dns |
En este caso, lo habilitaremos las instancias de openvpn como un servicio, pues para el host “tservice” se trata de clientes y se debe autenticar en cada caso, con su contraseña del AD para el TUN10 y con la del usuario PAM creado en el “vpn” para el TUN11.
Reiniciamos openvpn:
1 | service openvpn restart |
Iniciando conexión VPN contra “ovpn10”:
1 | openvpn /etc/openvpn/client/ovpn10.conf |
Ponemos las credenciales y estaremos conectados con el TUN10.
Para iniciar la conexión el con el segundo túnel, necesitamos abrir una nueva consola ssh y hacer lo propio, pero para el “ovpn11”:
1 | openvpn /etc/openvpn/client/ovpn11.conf |
Al cerrar la consola se cerrará la conexión en cada túnel, por lo que las conexiones no debemos hacerla desde un cliente SSH, sino de forma local, usando la interfaz grafica de XFCE y abriendo dos consolas para ejecutar las instancias ovpn. Esto habrá que hacerlo cada vez que se reinicie el servidor. A continuación muestro una imagen con lo anteriormente dicho:
