miércoles, 26 de diciembre de 2018

Instalar Service Pack en SUSE Linux Enterprise



Cómo instalar un Service Pack en un SUSE Linux Enterprise Server 12.



Hace unos días, SUSE lanzó el Service Pack 4 para SUSE Linux Enterprise 12. Este Service Pack dota a SLES 12 de soporte para nuevo hardware, instala una nueva versión del kernel, ofrece mejoras de virtualización, etc. además de ser un compendio de todos los parches aparecidos en el lapso de tiempo comprendido entre el SP3 y el SP4.

Para actualizar a este Service Pack, debemos tener, primero de todo, una suscripción activa a SUSE.

Para actualizar a SP4, podemos actualizar desde cualquier versión de SLES 12, desde la versión base hasta la versión SP3. En este artículo, mostraré como actualizar desde SLES 12 versión base a SLES 12 SP4 vía línea de comandos. Hay que decir que es posible actualizar también desde otras vías, como son la ISO del DVD y el entorno gráfico (mediante YasT2).

Primero de todo, sería recomendable ver qué versión de SUSE Linux Enterprise Server tenemos instalada. Lo podemos averiguar de varias formas. Yo he elegido la siguiente:

HOST# cat /etc/os-release NAME="SLES" VERSION="12" VERSION_ID="12" PRETTY_NAME="SUSE Linux Enterprise Server 12" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12"

Vemos que el sistema es un SLES 12 base (base = sin ningún Service Pack instalado).

En este punto, lo ideal es realizar una actualización estándar de paquetes del sistema. Así, si las herramientas de conexión a los repositorios de SUSE hubieran sido actualizadas, podríamos descargar sus últimas versiones y usarlas en la actualización de Service Pack:

HOST# zypper up Building repository 'SLES12-Pool' cache ...............................[done] Retrieving repository 'SLES12-Updates' metadata .......................[done] Building repository 'SLES12-Updates' cache ............................[done] Loading repository data... Reading installed packages... ...

Una vez actualizados los paquetes correspondientes del sistema, ya podemos lanzar la migración hacia el último Service Pack. Como partimos de un SLES 12 base, deberemos instalar primero el Service Pack 3 antes de poder instalar el Service Pack 4:

HOST# zypper migration Executing 'zypper refresh' Repository 'SLES12-Pool' is up to date. Repository 'SLES12-Updates' is up to date. All repositories have been refreshed. Executing 'zypper --no-refresh patch-check --updatestack-only' Loading repository data... Reading installed packages... 0 patches needed (0 security patches) Available migrations: 1 | SUSE Linux Enterprise Server 12 SP3 x86_64 2 | SUSE Linux Enterprise Server 12 SP2 x86_64 3 | SUSE Linux Enterprise Server 12 SP1 x86_64 [num/q]:

Elegimos la opción 1 (actualizar a Service Pack 3), aceptamos el acuerdo de licencia y esperamos pacientemente a que se instalen las más de 1.000 actualizaciones.

Cuando el proceso haya terminado, verificamos que se haya instalado el servce Pack 3:

HOST# cat /etc/os-release NAME="SLES" VERSION="12-SP3" VERSION_ID="12.3" PRETTY_NAME="SUSE Linux Enterprise Server 12 SP3" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12:sp3"

Reiniciamos la máquina. Cuando levante, ya podemos actualizar a Service Pack 4:

HOST# zypper migration Executing 'zypper refresh' Repository 'SLES12-SP3-Pool' is up to date. Repository 'SLES12-SP3-Updates' is up to date. All repositories have been refreshed. Executing 'zypper --no-refresh patch-check --updatestack-only' Loading repository data... Reading installed packages... Considering 0 out of 0 applicable patches: 0 patches needed (0 security patches) Available migrations: 1 | SUSE Linux Enterprise Server 12 SP4 x86_64 [num/q]:

Para acabar, verificamos que el Service Pack 4 haya quedado instalado:

HOST# cat /etc/os-release NAME="SLES" VERSION="12-SP4" VERSION_ID="12.4" PRETTY_NAME="SUSE Linux Enterprise Server 12 SP4" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12:sp4"

Y ya tenemos el SUSE Linux Enterprise Server actualizado a Service Pack 4.
1

miércoles, 19 de diciembre de 2018

SSL: cómo generar un archivo .p12



Cómo generar un archivo .p12 para realizar firmas electrónicas en ficheros PDF.



Hace un tiempo hablé de cómo generar un certificado SSL. Hoy hablaré de como usar la clave pública y la clave privada de un certificado para unirlas en un solo archivo de extensión .p12, el cual podremos usar como certificado para firmar documentos PDF.

Para empezar, necesitamos la parte pública del certificado SSL (archivo .cer o .crt) y la parte privada del certificado (archivo .key) así como los certificados intermedios de la entidad (archivos .cer).

Unimos todas las partes del certificado mediante la utilidad openssl:

C:\temp>openssl pkcs12 -export -inkey clave_privada.key -in CERT364.cer -out fichero.p12 -certfile multi.pem Enter Export Password: Verifying - Enter Export Password:

IMPORTANTE: el password que se nos pide es el que asignamos en su momento al CSR.

Echemos un vistazo a los diferentes archivos usados para generar el .p12:

- clave_privada.key: la clave privada del certificado.
- CERT364.cer: la clave pública del certificado. Podría ser un archivo .crt.
- fichero.p12: el fichero resultante de unir ambas claves.
- multi.pem: este archivo está compuesto por el contenido de los archivos .cer "extra" que nos envían desde la entidad certificadora; se trata de certificados propios de la entidad que validan que el certificado que vamos a usar ha sido emitido por ellos.

Para obtener el archivo .pem, creamos un archivo vacío y copiamos dentro los bloques de texto que hay dentro de los archivos .cer de la entidad certificadora:

-----BEGIN CERTIFICATE-----
<contenido>
-----END CERTIFICATE-----

Los copiamos uno debajo del otro, sin líneas en blanco entre ellos, y manteniendo el begin y el end.

Con el .p12 ya generado, ya lo podemos usar para realizar firmas electrónicas.
0

miércoles, 12 de diciembre de 2018

Tipos de red en VirtualBox



¿Alguna vez te has preguntado cuál es la diferencia entre los distintos tipos de red que puedes elegir en el adaptador de red de una máquina virtual en VirtualBox? veamos sus diferencias.



En esta entrada, veremos los tipos de conexiones de red de los que dispone el programa VirtualBox.



Con VirtualBox instalado, creamos o importamos una máquina Virtual y clicamos el botón Configuración. En Configuración, nos vamos al apartado Red. Allí, veremos distintas opciones a seleccionar para el adaptador de red de la máquina. Veamos en qué consiste cada una.

No conectado
Adaptador sólo-anfitrión (Host-Only)
Modo puente (bridge)
NAT
Red interna



No conectado



Con esta opción, la máquina virtual tiene una tarjeta de red instalada, pero no tiene conectividad con el host anfitrión ni con ninguna otra máquina virtual. Al entrar en la máquina virtual y mirar su IP, veremos que tiene una IP estática, no visible fuera de la máquina en sí.



Adaptador sólo-anfitrión (Host-Only)



Una máquina con el adaptador de red fijado en host-only solo tiene conectividad con el equipo anfitrión. Está totalmente aislada de las demás máquinas de la red de área local donde está conctado el anfitrión.




Modo puente (bridge)



En modo bridge, la máquina virtual pasa a ser un equipo más dentro de la red local. De este modo, la máquina virtual podrá conectarse a cualquier otra máquina/dispositivo presente en la red y cualquier otra máquina de la red podrá usar los recursos compartidos de la máquina virtual. De esta forma, si el equipo anfitrión está configurado para recibir una dirección IP por DHCP, la máquina virtual recibirá una IP del mismo rango, del mismo servidor DHCP.




NAT



Con el adaptador fijado en NAT, la máquina virtual recibe una dirección IP de un pool DHCP privado de VirtualBox. La máquina virtual, entonces, se conecta hacia el exterior mediante el firewall de VirtualBox, el cual le permite salir a internet medante el adaptador de red de la máquina anfitrión.




Red interna



Red interna es una forma de conectar varias máquinas virtuales entre ellas creando una red privada. De esta forma, las máquinas virtuales no podrán ver al PC anfitrión, ni viceversa, pero tendrán conectividad entre ellas. Con esta opción, podemos crear más de una red interna, separadas unas de otras.



Fuentes:

http://www.ticarte.com/contenido/tipos-de-conexiones-de-red-en-virtualbox-y-vmware
5

miércoles, 5 de diciembre de 2018

Quitar contraseña de un certificado SSL



Cómo quitar la contraseña de un certificado SSL, para que el servidor no la pida al reiniciarse.



Si tenemos un servidor web que sirva contenido HTTPS, necesitamos un certificado SSL que asegure las conexiones HTTPS hacia él. Los certificados SSL se suelen crear con un contraseña incrustada cuya utilidad principal es evitar que si el servidor web se ve comprometido, el intruso pueda robar el certificado y usarlo en otra máquina para realizar ataques de phishing, o similares.

Por otro lado, nos encontramos con que al proteger un certificado SSL con contraseña, cada vez que reiniciemos Apache o reiniciemos la máquina, el sistema nos pedirá que introduzcamos la contraseña:

Server dominio.com:443 (RSA) Enter pass phrase:

Esto puede llegar a ser un engorro y puede llegar a provocar downtime del sitio web. Si, por ejemplo, varias personas tienen acceso al servidor (desarrolladores, administradores, operadores, etc.) y una de ellas lo reinicia por una u otra causa, es posible que se olvide de que hay que intoducir el password del certificado durante el arranque de la máquina y el servicio web quede caído hasta que alguien se de cuenta. Si el certificado no tiene contraseña, se puede reiniciar la máquina sin mayor preocupación.

Para evitar que Apache nos pida la contraseña del certificado SSL cada vez que lo reiniciemos (o que reiniciemos la máquina), podemos usar este comando para quitar la contraseña a la clave privada:

HOST# openssl rsa -in /ssl/dominio.key -out /ssl/dominio_sin_password.key

La máquina nos preguntará entonces por la contraseña del certificado.

Después de introducirla por última vez, se generará un archivo .key sin contraseña.

Lo último que queda por hacer es configurar Apache para que use el archivo .key que contiene la clave privada sin contraseña. A partir de este momento, al reiniciar Apache (o la máquina), este ya no pedirá la contraseña del certificado, pero seamos conscientes de que cualquiera que consiga hackear el servidor podrá extraer y usar el certificado SSL del dominio a su antojo.
0