Habilitar escritorio remoto XRDP en CentOS 8

Para tener acceso remoto XRDP en Linux CentOS 8 si no tenemos habilitado los repositorios extras para Linux Empresarial (EPEL) los instalamos e iniciamos la instalación:

sudo dnf install epel-release
sudo dnf install xrdp

Habilitamos en el inicio del sistema y comprobamos el estado:

sudo systemctl enable xrdp --now
sudo systemctl status xrdp

La configuración básica se almacena en /etc/xrdp/xrdp.ini pero por defecto no hará falta modificarla.

Permitimos en el firewall el acceso desde nuestra red local, por ejemplo:

 

sudo firewall-cmd --new-zone=xrdp --permanent
sudo firewall-cmd --zone=xrdp --add-port=3389/tcp --permanent
sudo firewall-cmd --zone=xrdp --add-source=10.0.0.0/24 --permanent
sudo firewall-cmd --reload

Ya podemos utilizar el cliente predeterminado de Windows para escritorio remoto y iniciar sesión:

Y el escritorio por defecto del usuario:

 


Almacenamiento en discos SSD desde 2010: SATA vs NVMe

Intel empezó a trabajar alrededor de las memorias flash desde 2007, no fue hasta 2011 cuando se publicó la versión 1.0 del protocolo y poco después su soporte en Linux. Como suele ser habitual, el destino inicial de los avances se dirigió al entorno empresarial y para 2013 Samsung ponía en venta el modelo XS1415.

Hasta 2015 Microsoft no lanzó una actualización para dar soporte nativo a este nuevo protocolo NVMe dentro de Windows 7 / 8, por su parte Apple lo incluyó este mismo año en OS X Yosemite y su iPhone 6S.

Han pasado 5 años y ahora si podemos afirmar que es una tecnología asequible (calidad/rendimiento/precio), la eliminación del cuello de botella que supone el acceso a disco se ha disminuido considerablemente.

Comparativa entre Samsung SSD 850/860 EVO SATA y 970 PRO NVMe

Estar a la última en tecnología supone un coste enorme, para seguramente quedar "obsoleto" en 6 meses; es necesario buscar el equilibrio entre presupuesto y prestaciones a la hora de realizar inversiones tanto personales como empresariales.

Auditoria de registros de servidores en entorno híbridos Microsoft

Si disponemos de equipos on-premise y en Azure, podemos unificar la gestión de registros en una única herramientas. Aunque ha variado de nombres, actualmente se engloba dentro de "Área de trabajo de Log Analytics" que podremos crear desde el panel de control de Azure.

Desde el nuevo recurso en "Configuración avanzada" podemos descargar el agente para Windows o Linux:

Junto con el ID del área de trabajo y la clave principal que necesitaremos para la instalación en nuestro servidor:

Finalizada la instalación en el panel de control encontraremos la nueva aplicación "Microsoft Monitoring Agent"


Desde la que podremos realizar cambios posteriores de ser necesario:

Una vez se empiezan a recolectar los registros, podemos realizar consultas a petición, alertas informes...

 

Algunas de las habituales:

  • Inicios de sesión erróneos consecutivos
  • Espacio en disco duro escaso
  • Utilización promedio de CPU alta
  • Servidor no accesible (heartbeat)

 

[Escribir consultas personalizadas en Azure Monitor]

 

Convertir certificado PFX a CRT

Si disponemos de un certificado en entornos Windows y queremos utilizar un certificado en otro tipo de dispositivos, por ejemplo un wilcard (*.midominio.com) podemos desglosar en dos partes utilizando OpenSSL:

openssl pkcs12 -in certificadoCompleto.pfx -nocerts -out llaveSegura.key

De este modo tenemos en un archivo la parte correspondiente a la clave privada de forma encriptada (BEGIN ENCRYPTED PRIVATE KEY). Por otro lado tenemos el certificado firmado:

openssl pkcs12 -in certificadoCompleto.pfx -clcerts -nokeys -out certificado.crt

Si necesitamos las claves sin encriptar (BEGIN RSA PRIVATE KEY), cuidado donde guardar este tipo de ficheros, podemos hacerlo mediante:

openssl rsa -in llaveSegura.key -out llaveNoSegura.key

Con estas 2+1 partes podremos instalar el certificado, por ejemplo en PLESK:

 

 

 

 

Teletrabajo con entornos Windows y coronavirus

Si bien algunas empresas están ya habituadas a permitir a sus empleados realizar trabajo en remoto, con la pandemia del coronavirus muchas otras se han visto forzadas a utilizar recursos limitados para un gran número de trabajadores.

Lo primero de todo, debemos tener en cuenta los servicios nativos cloud, los cuales permiten realizar tareas desde cualquier sitio de forma habitual. Por otro lado, el acceso a recursos locales dentro de la empresa debe asegurarse de diferentes formas:

  • Sistemas de alimentación ininterrumpida deben proveer corriente a los servidores o equipos con disponibilidad, algo básico pero necesario.
  • Seguridad de red activa, abrir un puerto o varios para permitir un servicio (por ejemplo de conexión remota) debe conllevar su monitorización activa en busca de patrones o usos inadeacuados. Firewall dedicados o Azure Bastion por ejemplo.
  • Autenticación de doble factor, donde sea posible y factible, como punto de verificación de identidad de humanos frente a máquinas.
  • Sistemas operativos y antivirus actualizados, no debería llegar una pandemia para tener este punto mínimo cubierto.

Dentro de los entornos corporativos con recursos limitados, se han habilitado ordenadores para su acceso por escritorio remoto, si bien las soluciones RDS/VDI/WVD son muy capaces, para PYMES puede no ser una opción asequible en todos los casos. Por ello debemos tener en cuenta cuando habilitamos el acceso remoto:

  • Separar y securizar redes según los perfiles y requisitos de acceso
  • Establecer directivas de red suficientes
  • Monitorizar y controlar los usuarios permitidos

Si llegados a este punto permitimos el acceso remoto al puesto de trabajo habitual de un trabajador, deberemos tener en cuenta adicionalmente:

Debemos estar seguros lo que supone introducir un ordenador dentro de la red corporativa, así como tener en mente primero a las personas y luego a las máquinas.