miércoles, 22 de enero de 2020

Windows: la configuracion de seguridad no permite que esta aplicacion se instale en su PC



Cómo instalar una aplicación en Windows cuando este muestra la advertencia de seguridad:
"La configuracion de seguridad no permite que esta aplicacion se instale en su PC".




Es posible que tras descargar una aplicación desde internet y tratar de instalarla en nuestro PC, Windows nos muestre la siguiente advertencia de seguridad:



La causa es el "Comportamiento de solicitud de confianza de Click Once" deshabilitado en Windows.


Solución



Para resolver este problema, la siguiente clave de registro debe configurarse como habilitada:

HKLM\SOFTWARE\MICROSOFT\.NETFramework \Security\TrustManager\PromptingLevel\Internet

Para habilitar la clave de registro, debemos:

1) Abrir el editor de registro (regedit.exe)

2) Buscar la siguiente clave del Registro:

HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\.NETFramework\Security\TrustManager\PromptingLevel\Internet

(Si la clave no existe, crearla).

3) Establecer el valor en Habilitado.

Una vez hecho esto, ya podremos instalar la aplicación sin problema.


Fuentes:

https://knowledge.autodesk.com/es/support/bim-360-glue/troubleshooting/caas/sfdcarticles...
https://docs.microsoft.com/es-es/visualstudio/deployment/how-to-configure-the-clickonce-trust...
0

miércoles, 15 de enero de 2020

Deshabilitar SuSEfirewall2



Cómo deshabilitar SuSEfirewall2 en un SUSE Linux Enterprise Server 12 o inferior.



SUSE Linux Enterprise 15 trae firewalld como firewall preinstalado. Al igual que Red Hat Enterprise Linux. No siempre fue así. Anteriormente (SLES 12 hacia abajo), SUSE incluía un firewall propio en su distribución llamado, como no podía ser de otra forma, "SuSEfirewall2". Ambos son interfaces para gestionar Netfilter, el framework que usa el kernel de Linux para manipular paquetes de red.

Si el gateway del sistema operativo es un firewall en el que ya controlamos los accesos desde y hacia el servidor en cuestión, lo más cómodo es desactivar el firewall del SUSE para evitarnos trabajo.

SuSEfirewall2 viene activado por defecto en SLES 12 e inferiores y puede llegar a darnos muchos dolores de cabeza si no recordamos que está allí, denegando el tráfico hacia la máquina.

Podemos comprobar si SuSEfirewall2 está activo con el siguiente comando:

HOST# systemctl status SuSEfirewall2 SuSEfirewall2.service - SuSEfirewall2 phase 2 Loaded: loaded (/usr/lib/systemd/system/SuSEfirewall2.service; enabled; vendor preset: disabled) Active: active (exited) since Tue 2020-01-07 09:46:41 CET; 50min ago Main PID: 1784 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 512) CGroup: /system.slice/SuSEfirewall2.service Jan 07 09:46:39 HOST systemd[1]: Starting SuSEfirewall2 phase 2... Jan 07 09:46:39 HOST SuSEfirewall2[1784]: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jan 07 09:46:39 HOST SuSEfirewall2[1784]: using default zone 'ext' for interface eth0 Jan 07 09:46:41 HOST SuSEfirewall2[1784]: Firewall rules successfully set Jan 07 09:46:41 HOST systemd[1]: Started SuSEfirewall2 phase 2.

Para desactivar el firewall, primero lo paramos:

HOST# systemctl stop SuSEfirewall2

Lo configuramos para que no se inicie automáticamente al reiniciar la máquina:

HOST# systemctl disable SuSEfirewall2 Removed symlink /etc/systemd/system/SuSEfirewall2_setup.service. Removed symlink /etc/systemd/system/multi-user.target.wants/ SuSEfirewall2.service. Removed symlink /etc/systemd/system/multi-user.target.wants/ SuSEfirewall2_init.service.

Comprobamos el estado del firewall:

HOST# systemctl status SuSEfirewall2 ● SuSEfirewall2.service - SuSEfirewall2 phase 2 Loaded: loaded (/usr/lib/systemd/system/SuSEfirewall2.service; disabled; vendor preset: disabled) Active: inactive (dead) Jan 07 09:46:39 HOST systemd[1]: Starting SuSEfirewall2 phase 2... Jan 07 09:46:39 HOST SuSEfirewall2[1784]: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jan 07 09:46:39 HOST SuSEfirewall2[1784]: using default zone 'ext' for interface eth0 Jan 07 09:46:41 HOST SuSEfirewall2[1784]: Firewall rules successfully set Jan 07 09:46:41 HOST systemd[1]: Started SuSEfirewall2 phase 2. Jan 07 10:37:13 HOST systemd[1]: Stopping SuSEfirewall2 phase 2... Jan 07 10:37:13 HOST SuSEfirewall2[8878]: Firewall rules unloaded. Jan 07 10:37:13 HOST systemd[1]: Stopped SuSEfirewall2 phase 2.

El firewall está completamente desactivado.

A partir de este momento, si abrimos algún puerto en la máquina (por ejemplo, el puerto 443), este será accesible sin configuraciones adicionales a nivel de sistema operativo.
0

miércoles, 8 de enero de 2020

Conectarse a un switch Aruba con clave SSH



Cómo conectarse a un switch Aruba / Hewlett Packard Enterprise con una clave pública/privada.
Cómo conectarse a un switch Aruba por SSH de forma desatendida sin usar password.




Los switches Aruba que ofrecen la posibilidad de acceso vía SSH permiten el acceso por SSH tanto con usuario/password como con un par de claves pública/privada. Este par de claves debe ser generado en el switch, desde el cual podemos exportar la parte pública de la clave.

Posteriormente, podemos depositar esa clave pública en un sistema Linux para poder conectarnos al switch sin necesidad de usar password. Esto es útil para, por ejemplo, conectarnos de forma automática al switch y realizar backups de su configuración.

Para generar un par de claves, primero debemos acceder al modo config del switch y luego ejecutar:

switch(config)# crypto key generate ssh rsa Installing new key pair. If the key/entropy cache is depleted, this could take up to a minute.

Podemos especificar el tamaño de la clave RSA. Por defecto, es de 2048 bits.

Una vez generado el par, podemos ver su parte pública para copiarla y pegarla en otro sistema:

switch(config)# show crypto host-public-key ssh-rsa 38912988qAAAFGHqwn564das7TRZbd3as...

Como el par de claves se escribe en la flash, no hace falta ejecutar "write memory" para guardarlo.

Aunque el par de claves se almacen en la memoria flash y no en el archivo running-config, el switch mantiene el par al reiniciar el dispositivo. Es decir, el par de claves es permanente, por lo que no es necesario regenerarlo si reiniciamos el switch. Si se regenera, se deberá reintroducir la parte pública de la clave en todos los sietamas en los que fuese introducida previamente.

Cabe decir que solo la parte pública del par es legible por el usuario. Esta parte pública, como decía, se puede añadir a un sistema Linux para acceder al switch sin necesidad de usar password. Para ello, debemos añadir el hash al archivo "know_hosts" de un usuario.

Una posible ruta del archivo known_hosts es:

/home/usuario/.ssh/known_hosts

Destacar también que si se remueve el par de claves de un switch, el switch deja de ser accesible por SSH automáticamente hasta que se vuelva a activar el acceso por ssh con el comando "ip ssh".


Fuentes:

https://techhub.hpe.com/eginfolib/networking/docs/switches/RA/15-18/5998-8151_ra_2620_asg...
0

miércoles, 1 de enero de 2020

Mostrar discos de un cluster GPFS



Cómo mostrar qué discos forman parte de un cluster GPFS bajo un sistema operativo Linux en IBM Spectrum Scale para así poder quitarlos del cluster, por ejemplo.



Para ver qué discos forman parte de un cluster GPFS™, podemos usar el comando mmlsnsd.

Recordemos que para poder ejecutar el comando mmlsnsd en una máquina que tenga GPFS, debemos disponer de permisos de root - ya sea estando logeados como root o mediante el uso de sudo.

Veamos el output producido por mmlsnsd:

HOST# mmlsnsd File system Disk name NSD servers --------------------------------------------------------------------------- sapmntdata data01node01 gpfsnode01 sapmntdata data02node01 gpfsnode01 sapmntdata data03node01 gpfsnode01 sapmntdata data04node01 gpfsnode01 sapmntdata2 data05node01 gpfsnode01

Por defecto, este comando muestra informacón de todos los discos del cluster (-a).

También podemos elegir mostrar información para un file system determinado (-f):

HOST# mmlsnsd -f sapmntdata File system Disk name NSD servers --------------------------------------------------------------------------- sapmntdata data01node01 gpfsnode01 sapmntdata data02node01 gpfsnode01 sapmntdata data03node01 gpfsnode01 sapmntdata data04node01 gpfsnode01

Podemos mostrar todos los discos que no pertenecen a ningún file system (-F):

HOST# mmlsnsd -F mmlsnsd: [I] No disks were found.

También podemos mostrar información de un disco concreto:

HOST# mmlsnsd -d data02node01 File system Disk name NSD servers --------------------------------------------------------------------------- sapmntdata data02node01 gpfsnode01

O podemos ver qué disco de Linux corresponde con qué disco de GPFS con la opción -m. Esta opción nos dirá, por ejemplo, si data03node01 es /dev/sda o es /dev/sdd:

HOST# mmlsnsd -m Disk name NSD volume ID Device Node name Remarks ---------------------------------------------------------------------------- data01node01 C0A86E9D573D888F /dev/sdb gpfsnode01 server node data02node01 C0A86E9B5B7FB1A2 /dev/sdc gpfsnode01 server node data03node01 C0A86E9B5B7FB1EE /dev/sdd gpfsnode01 server node data04node01 C0A86E9B5B90FDB2 /dev/sde gpfsnode01 server node

Con esta información ya podemos eliminar el disco, ampliarlo, etc.


Fuentes:

https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc...
https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.2/com.ibm.spectrum.scale.v5r02.doc...
0

miércoles, 25 de diciembre de 2019

nginx: [emerg] SSL error: key values mismatch



Solucionar error "key values mismatch" al recargar la configuración en NGINX.



Cuando instalemos un nuevo certificado SSL en NGINX, puede que nos encontremos con el siguiente error al ejecutar nginx -s reload (comando que carga los cambios efectuados en los archivos .conf):

nginx: [emerg] SSL_CTX_use_PrivateKey("/etc/ssl/name.key") failed (SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch)

Este error se pude deber a 2 causas:


Causa 1:
Las claves pública/privada no coinciden



Esta causa se da cuando estamos enlazando una clave pública (crt) y una clave privada (key) que no coinciden. Es un problema común cuando hay varias partes involucradas en la instalación de un certificado SSL (la persona que genera el CSR, la que efectúa el pago del certificado, la que lo instala en NGINX...). En el tramo final del proceso, puede darse que la persona encargada de instalar los archivos acabe recibiendo un key y un crt que no hagan match.

Para solucionar este problema, deberemos buscar la key que sí combine con el crt, o en última instancia, volver a generar un nuevo crt en la entidad certificadora donde compramos el certificado SSL originalmente, en caso de que no encontremos el key y el crt que hagan match.

Para quien le interese, ya mostré cómo comprobar el match entre clave pública y clave privada de un certificado SSL mediante el comando openssl en una entrada anterior.


Causa 2:
Orden incorrecto en la concatenación de certificados



Otro de los causantes de este error es el orden de concatenacion de los certificados.

Al especificar un archivo crt en NGINX, no basta con especificar el dominio.com.crt como archivo en el apartado ssl_certificate, sino que debemos unificar el crt del dominio con los certificados intermedios y el certificado de nuestra entidad certificadora.

Este orden de unificación o concatenación debe ser el siguiente:

tu_dominio.crt) -> intermediario_1.crt -> intermediario_2.crt -> root_ca.crt

Para juntar todos los certificados en un solo archivo, podemos usar el siguiente comando:

HOST# cat tu_dominio.crt gd_bundle.crt >> dominio.chained.crt

Una vez concatenados los certificados, ya podemos usar el archivo resultante en el apartado ssl_certificate de NGINX para el dominio que queramos configurar.
0