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

miércoles, 18 de diciembre de 2019

Añadir discos a un Linux que corra sobre VMWare



Cómo añadir un disco a un sistema Linux que corre sobre VMWare sin reiniciar la máquina.



Con la llegada de los entornos virtuales llegaron nuevos desafíos, como por ejemplo, cómo añadir un disco a una máquina virtual encendida y hacer que esta lo detecte sin tener que reiniciar la máquina.

Para añadr un disco a una máquina virtual Linux que corra sobre VMware, lo primero que debemos hacer es añadir un disco a dicha máquina desde el hipervisor.

Al añadir un disco en caliente, Linux no se dará cuenta de que se le ha conectado nuevo hardware hasta que se lo indiquemos. Para ello, debemos usar sysfs para decirle al kernel que rescanee los buses (o channels, en terminología SCSI) con el fin de que el sistema operativo pueda ver el nuevo disco.


Método manual



Con el comando lsscsi, listamos todos los dispositivos SCSi detectados por el sistema:

HOST# lsscsi [1:0:0:0] cd/dvd NECVMWar VMware IDE CDR10 1.00 /dev/sr0 [2:0:0:0] disk VMware, VMware Virtual S 1.0 /dev/sda

Entre corchetes, encontraremos 4 números representados como [ <H> <C> <T> <L> ]

- <H> es el host adapter
- <C> es el channel (bus) en el host adapter.
- <T> es el target ID.
- <L> es el Logical Unit Number.

A continuación, buscaremos a qué host adapter está conectado el disco que acabamos de añadir:

HOST# grep mpt /sys/class/scsi_host/host?/proc_name /sys/class/scsi_host/host2/proc_name:mptspi

Con el comando anterior, hemos visto que el disco está conectado al host2. Ahora le diremos al kernel que reescanee todos los controladores de ese host adapter:

HOST# echo "- - -" > /sys/class/scsi_host/host2/scan

Los tres valores "- – -" representan:

- Channel (bus)
- SCSI target ID
- LUN

Los guiones son comodines que significan "reescanea todo".

Después del escaneo, comprobamos que el sistema operativo ya ve el disco:

HOST# lsscsi [1:0:0:0] cd/dvd NECVMWar VMware IDE CDR10 1.00 /dev/sr0 [2:0:0:0] disk VMware, VMware Virtual S 1.0 /dev/sda [2:0:1:0] disk VMware, VMware Virtual S 1.0 /dev/sdb


Alternativa: rescan-scsi-bus.sh



Alternativamente, podemos reescanear los adaptadores SCSI con el comando rescan-scsi-bus.sh del paquete sg3_utils. Este script hace todo el proceso anterior automáticamente:

HOST# rescan-scsi-bus.sh -a

Alguna gente es crítica con este script, quejándose de que a veces falla. Personalmente, debo decir que siempre que lo he usado me ha funcionado la mar de bien.


Fuentes:

http://systemadmin.es/2017/06/hacer-un-rescan-de-discos-iscsi
https://ssh.guru/adding-and-removing-disks-from-linux-guest/
https://blog.fpmurphy.com/2017/05/adding-and-removing-disks-from-vmware-rhel7-guests...
0

miércoles, 11 de diciembre de 2019

Incrementar tamaño de un volumen EBS en Linux



Cómo aumentar el tamaño de un volumen EBS en una instancia EC2 Linux en AWS.



A continuación, mostraré cómo subir el tamaño de un disco o volumen de una instancia Linux alojada en Amazon Web Services y cómo ver el nuevo tamaño en el sistema operativo.

Para este ejemplo, el disco a ampliar será un disco de 60 GB llamado "xvdf" montado en la partición /mnt. La ampliación se hará en caliente, sin parar la máquina ni desmontar el punto de montaje.

admin@ip-10-250-4-93:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 80G 0 disk └─xvda1 202:1 0 80G 0 part / xvdf 202:80 0 60G 0 disk /mnt

Para ampliar el disco, debemos ir a la consola web de AWS y buscar la opción "Volumes". Una vez dentro, seleccionamos el disco a subir de tamaño e incrementamos su Size:



Una vez modificado el tamaño del disco, nos conectamos por SSH a la instancia y lanzamos el comando lsblk. Tras unos instantes - y sin hacer nada más en la terminal - deberíamos ver el nuevo tamaño del disco en pantalla (vemos que el disco xvdf tiene ahora un tamaño de 70 GB):

admin@ip-10-250-4-93:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 80G 0 disk └─xvda1 202:1 0 80G 0 part / xvdf 202:80 0 70G 0 disk /mnt

Aun viendo que el tamaño del disco es 70 GB, el punto de montaje /mnt aún no ve el nuevo espacio:

admin@ip-10-250-4-93:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 7.9G 0 7.9G 0% /dev tmpfs 1.6G 12M 1.6G 1% /run /dev/xvda1 79G 1.1G 75G 2% / tmpfs 7.9G 0 7.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup tmpfs 1.6G 0 1.6G 0% /run/user/1000 /dev/xvdf 59G 53M 56G 1% /mnt

Para que /mnt vea los 70 GB, usaremos el comando resize2fs para extender el filesystem en caliente:

admin@ip-10-250-4-93:~$ sudo resize2fs /dev/xvdf resize2fs 1.43.4 (31-Jan-2017) Filesystem at /dev/xvdf is mounted on /mnt; on-line resizing required old_desc_blocks = 8, new_desc_blocks = 9 The filesystem on /dev/xvdf is now 18350080 (4k) blocks long.

Volvemos a ejecutar un df y ya vemos el tamaño correcto:

admin@ip-10-250-4-93:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 7.9G 0 7.9G 0% /dev tmpfs 1.6G 12M 1.6G 1% /run /dev/xvda1 79G 1.1G 75G 2% / tmpfs 7.9G 0 7.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup tmpfs 1.6G 0 1.6G 0% /run/user/1000 /dev/xvdf 69G 52M 66G 1% /mnt

A partir de este momento, ya podemos usar el nuevo espacio asignado.
0

miércoles, 4 de diciembre de 2019

Cron: ejecutar script el primer lunes de cada mes



Cómo hacer que un script se ejecute el primer lunes de cada mes en Linux.



Los que conozcáis cron sabréis que es una utilidad que sirve para ejecutar scripts (o comandos) de forma recurrente en entornos Linux. Cron permite elegir el minuto, hora, dia, mes y día de la semana en que ejecutar un script automáticamente.


Ejecutar script el día 1 de cada mes



Siguiendo lo mencionado anteriormente, para hacer que un script se ejecute automáticamente el dia 1 de cada mes a las 2:00 de la madrugada, debemos usar la siguiente sintaxis en crontab:

0 2 1 * * /ruta/script.sh


Ejecutar script el primer lunes de cada mes



Puede que nos interese ejecutar un script, ya no el día 1 de cada mes, sino el primer lunes de cada mes, de modo que al entrar a la oficina a las 8:00h podamos actuar dependiendo del resultado generado por el script. Y que sea crítico que se ejecute el lunes porque sí o sí estaremos a la mañana siguiente en el trabajo, cosa que no pasaría si el día 1 de ese mes fuese sábado (por ejemplo).

NOTA: sí, puede que haya lunes que sean festivos...

La forma en la que está diseñado cron no contempla este tipo de planificación, pero eso no significa que no se pueda llevar a cabo. Para conseguir que un script se ejecute el primer lunes de cada mes a las 2:00h (por ejemplo), podemos usar la siguiente parametrización en crontab:

0 2 1-7 * * [ "$(date '+\%u')" = "1" ] && /ruta/script.sh

Lo que estamos haciendo es ejecutar un script y luego otro. Recordemos que, en bash, el operando && indica "si se cumple la condición anterior, ejecuta el comando siguiente". Es decir, si el día de la semana equivale a 1 (lunes), ejecuta el script.

En el primer script, vemos cómo se escapa el caracter % con el uso de comillas simples y \. Esto es necesario, puesto que si no se escapa el caracter, el comando no se ejecuta en cron. Sin más.


Número vs Nombre



Se podría usar [ "$(date '+\%a')" = "Mon" ] para comprobar si el día es lunes, pero entonces el script solo funcionaría en sistemas con el locale inglés. Si nuestro sistema estuviera en español, necesitaríamos compararlo con "lun", si estuviera en francés, con "lundi", etc.

Para evitar problemas con el idioma del sistema operativo, considero que es mejor usar el número del día (%u) en vez de usar el nombre del día (%a), ya que los números son universales, cosa que nos permitirá pasar esta entrada cron de un sistema a otro sin importar los locales.


Alternativa



De forma alternativa, se podría ejecutar el script cada lunes y dentro del script en sí comprobar si ese lunes es el primero del mes actual. Si es el primer lunes, seguir con la ejecución, y sino, ejecutar un simple "exit" para salir del script. Pero considero que esta opción gasta más tiempo de procesador.


Conclusión



Aunque cron no esté diseñado explícitamente para permitirnos ejecutar un script el primer dia X de cada mes, hemos visto cómo podemos llevar a cabo esta tarea usando simples comandos de bash.
0

miércoles, 27 de noviembre de 2019

Terminator: Dark Fate, Sarah Connor y su móvil



¿Es efectivo poner un teléfono móvil dentro de una bolsa de patatas fritas para anular así su geolocalización tal y como hace Sarah Connor en la película Terminator: Dark Fate? Spoilers inside



El fin de semana pasado fui a ver la película Terminator: Dark Fate, la supuesta secuela directa de Terminator 2: Judgment Day, la cual se supone que sigue la cronología de Terminator allá donde se quedó esta Terminator 2, dejando en otro universo a Terminator 3 y sus continuaciones.

El caso es que unos días después de ver la película, me crucé con un artículo en el blog de Kaspersky en el que hablan de un hecho importante en el film: la geolocalización de teléfonos móviles. Más concretamente, hablan de si es posible anular la geolocalización de un teléfono con solo ponerlo dentro de una bolsa de patatas fritas, tal y como hace Sarah Connor (Linda Hamilton) en la película.


Localizando un teléfono móvil



Recordemos que los teléfonos móviles actuales ofrecen su ubicación mediante varios medios: señales GPS, antenas de telefonía móvil y puntos de acceso WiFi. Cuantos más medios de esta lista estén disponibles, más precisas serán las coordenadas de localización del teléfono. Aun así, y siempre según Kaspersky, para evitar la localización de un móvil, no habría que anular la señal GPS, sino más bien la red móvil y el WiFi, ya que al GPS permite que un teléfono reciba señales para determinar dónde está ubicado, pero no transmite nada.

En la película, Sarah Connor usa el aluminio de una bolsa de patatas para anular la localización de su móvil siguiendo el principio de la jaula de Faraday, esto es, el campo electromagnético en el interior de un conductor en equilibrio es nulo, anulando el efecto de los campos externos. De este modo, se supone que el aluminio de la bolsa anula las señales de GPS, WiFi y la localización de las antenas.


El experimento



Hay gente en Kaspersky que tiene mucho tiempo libre, por lo que pueden dedicarse a hacer este tipo de experimentos para ver si la tecnología y métodos usados en las películas son eficientes o son puro teatro hollywoodiense. Y gente como yo estamos encantados de que haya gente en Kaspersky con tiempo libre para comprobar estas cosas :)

Para ver si una bolsa de patatas impide a un teléfono móvil ser localizado, los ingenieros de Kaspersky metieron un móvil en una bolsa de patatas fritas y confirmaron que no tenía ningún efecto. Se podían determinar las coordenadas del teléfono con una precisión de un par de metros.

Tras este primer experimento fallido decidieron probar usando dos bolsas de patatas. Y, ahora sí, con dos bolsas, el teléfono no recibía ni enviaba señal alguna.

Los chavales de Kaspersky probaron bolsas de diferentes fabricantes y el resultado fue siempre el mismo: con dos bolsas funcionaba; con una sola bolsa no.


Conclusión



La recomendación con la que concluye el artículo de Kaspersky es que si quieres anular la localización de tu teléfono, lo mejor es poner el móvil dentro de dos o más bolsas de patatas.


Bonus



Para los que hayan visto Terminator: Dark Fate, dejo este enlace que explica cómo se modelaron las caras de Linda Hamilton y Edward Furlong para hacerlos rejuvenecer 30 años en las escenas iniciales de la película (no, no eran tomas descartadas de Terminator 2).


Fuentes:

https://www.kaspersky.es/blog/terminator-dark-fate-chips/19581/
0

miércoles, 20 de noviembre de 2019

Deshabilitar SMB versión 1 en Windows Server



Cómo volver a conectar con carpetas compartidas en red. Solucionar error "El nombre de red especificado ya no está disponible", "Este recurso compartido requiere el protocolo SMB1 obsoleto".



Vemos este error en le Windows de un usuario:

No se puede conectar con los recursos compartidos de archivos porque no es seguro. Este recurso compartido requiere el protocolo SMB1 obsoleto, el cual no es seguro y podría exponer su sistema a ataques. Su sistema requiere SMB2 o superior. Para obtener más información sobre cómo solucionar este problema, visite: https://go.microsoft.com/fwlink/?linkid=852747.

Esto ocurre porque, probablemente, el file server al que trata de conectarse el usuario sea un Windows Server 2012 con Samba v1 activo. Y como Microsoft ha aplicado un parche a Windows 10 que impide a esta versión de Windows conectar con servidores que tengan SMBv1 activo, Windows nos muestra un error al tratar de acceder a rutas UNC en estos servidores.

Recordemos que Microsoft desaprobó el uso del protocolo SMBv1 en 2014 y desde 2017, Windows utiliza solo SMBv2 y protocolos posteriores. A partir de Windows 10 Fall Creators Update y Windows Server versión 1709 (RS3), el protocolo de red SMBv1 no viene instalado por defecto


Qué ocurre con SMBv1



Cuando se usa SMB1, se pierden las protecciones que ofrecen SMBv2 y posteriores:

• Integridad previa a la autenticación (SMB 3.1.1+). Protege contra ataques de degradación de seguridad.
• Negociación de dialecto seguro (SMB 3.0, 3.02). Protege contra ataques de degradación de seguridad.
• Cifrado (SMB 3.0+). Evita la inspección de datos, ataques MiTM.
• Bloqueo de autenticación de invitados inseguro (SMB 3.0+). Protege contra los ataques MiTM.
• Firma de mensajes (SMB 2+). MD5 es reemplazado por HMAC SHA-256 (SMBv2) y AES-CMAC SMBv3).

Si un cliente usa SMB1, un atacante puede realizar man-in-the-middle y puede decirle al cliente que ignore todo lo anterior. Todo lo que necesita hacer el atacante es bloquear SMBv2+ en la máquina intermedia y responder al nombre o IP del servidor. El cliente negociará entonces con SMBv1 y compartirá todo, a menos que se requiera cifrado en ese recurso compartido para evitar SMBv1...

Además, fallos de SMBv1 son explotados por varios ransomware para propagarse por la red.

Pero estas razones, es por las que se debe dejar de usar SMBv1 en una red interna.


Cómo desactivar SMBv1



En Windows Server 2012 R2 y 2016 se puede desactivar SMBv1 vía PowerShell (o ver si está activo):

Detectar si SMBv1 está activo:

Get-WindowsFeature FS-SMB1

Deshabilitar:

Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Habilitar:

Enable-WindowsOptionalFeature -Online -FeatureName smb1protocol

En Windows Server anteriores a 2012 no hace falta mostrar el método porque están fuera de soporte por parte de Microsoft y no debería existir ninguno en nuestra infraestructura.

Una vez deshabilitado SMBv1 en el file server de turno, los clientes que usen Windows 10 ya se podrán volver a conectar a carpetas compartidas sin problema.


Fuentes:

https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/Stop-using-SMB1/ba-p/425858
https://support.microsoft.com/es-es/help/4034314/smbv1-is-not-installed-by-default-in-windows
https://support.microsoft.com/es-es/help/2696547/detect-enable-disable-smbv1-smbv2-smbv3...
0

miércoles, 13 de noviembre de 2019

Deshabilitar TLS 1.0 y TLS 1.1 en SAP



Cómo deshabilitar TLS 1.0 y TLS 1.1 en productos de SAP como SAP Web Dispatcher.



Si estás leyendo estas líneas, probablemente estés a cargo de configurar el Web Dispatcher de SAP en tu compañía y busques cómo limitar la versión de TLS que acepta el servidor a TLS 1.2 para superar una auditoría de seguridad sin que salten alertas :)

Como ya comenté, a partir de marzo de 2020, TLS 1.0 y TLS 1.1 dejarán de ser soportados por los navegadores web, por lo que deja de tener sentido soportar esos protocolos de encriptación en el Web Dispatcher de SAP, a menos que tengamos la certeza de que servimos contenido a usuarios con PCs, sistemas operativos y/o navegadores antiguos.


Opciones de configuración



En SAP, se pueden configurar los parámetros ssl/ciphersuites y ssl/client_ciphersuites usando combinaciones (sumas) de los siguientes valores:

Valor     Descripción

1            "BC" (aceptar SSL Version 2.0 CLIENT-HELLO / SSLv2Hello para TLSv1.x Handshake)
2            "BEST" (activar TLS más alto disponible)
4            "NO_GAP" (sin saltos entre protocolos TLS)
16           Permitir el envío ciego de un certificado de cliente (5.5.5pl36+ and all CCL 8.x.x)
32           "Strict protocol version configuration" (no habilitare TLSv1.0)
64            SSLv3
128          TLSv1.0
256          TLSv1.1 (solo con CommonCryptoLib (CCL) 8.4.31 o superior)
512          TLSv1.2 (solo con CommonCryptoLib (CCL) 8.4.31 o superior)

Con los valores predeterminados, el lado servidor del sistema SAP tiene todas las versiones de los protocolos SSL y TLS (más BC) habilitadas:

TLSv1.0 + SSLv3 + BC = 128 + 64 + 1 = 193
TLSv1.2 + TLSv1.1 + TLSv1.0 + SSLv3 + BC = 512 + 256 + 128 + 64 + 1 = 961

Los valores predeterminados para el lado del cliente solo permiten SSLv3 + TLSv1.0:

TLSv1.0 + SSLv3 = 128 + 64 = 192


Configurando solo TLS 1.2



Para limitar las versiones de TLS en el lado servidor a TLS 1.2 solamente, debemos configurar los cipher suites en el archivo DEFAULT.PFL (se pueden configurar en DEFAULT.PFL o en el archivo de instancia, pero SAP recomienda configurarlos en DEFAULT.PFL).

Para solo atender peticiones que lleguen con TLS 1.2 debemos usar estas líneas:

ssl/ciphersuites = 545:PFS:HIGH::EC_P256:EC_HIGH
ssl/client_ciphersuites = 560:PFS:HIGH::EC_P256:EC_HIGH
icm/HTTPS/client_sni_enabled = TRUE
ssl/client_sni_enabled = TRUE

Los valores 545 y 560 salen de:

TLSv1.2 + STRICT_PROTOCOL_VERSIONS + BC = 512 + 32 + 1 = 545
TLSv1.2 + STRICT_PROTOCOL_VERSIONS + BLIND_CLIENT_CERTS = 512 + 32 + 16 = 560

Una vez aplicados los cambios, reiniciar instancia para aplicar la configuración.


Fuentes:

https://launchpad.support.sap.com/#/notes/510007
https://launchpad.support.sap.com/#/notes/2384290
0

miércoles, 6 de noviembre de 2019

Deshabilitar TLS 1.0 y TLS 1.1 en IIS



Cómo deshabilitar TLS 1.0 y TLS 1.1 en IIS en un Windows Server.



Expliqué anteriormente cómo deshabilitar TLS 1.0 y TLS 1.1 en NGINX y cómo deshabilitar TLS 1.0 y TLS 1.1 en Apache. A continuación, explicaré cómo hacer lo propio en IIS sobre Windows Server. Recordemos que estos protocolos dejarán de estar soportados por los navegadores en marzo de 2020, por lo que a partir de esa fecha dejará de tener sentido soportarlos en nuestros servidores web.

El registro de Windows contiene diferentes claves por cada protocolo de encriptación que este sistema acepta en modo servidor. Estas claves se almacenan en:

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols

Habitualmente, esta clave contiene las siguientes subclaves:

• SSL 2.0
• SSL 3.0
• TLS 1.0
• TLS 1.1
etc.

Cada una de estas claves contiene una entrada que indica a la máquina si acepta dicho protocolo o no.

Cualquiera de estos protocolos se puede deshabilitar creando un nuevo valor con una subclave "Server" y ubicando dentro una clave de tipo DWORD llamada Enabled con valor 0:



Veamos cómo deshabilitar TLS 1.0 paso a paso:

1. Hacer clic en Inicio, Ejecutar, escribir "regedit" y pulsar enter.
2. En el Editor del Registro, buscar la siguiente clave:

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols\

3. Botón derecho del mouse encima, clic en Agregar Clave y escribir TLS 1.0 (si esta no existe)
4. Crear nueva sub-clave llamada Server.
5. Crear tipo de datos DWORD y titularlo Enabled.
6. Escribir 0 como valor de la entrada Enabled.

Repetir los pasos para TLS 1.1 y al finalizar, reiniciar la máquina.

Una vez reiniciada la máquina, esta ya no negociará con TLS 1.0 ni TLS 1.1 en el lado servidor.


Fuentes:

https://support.microsoft.com/es-es/help/187498/how-to-disable-pct-1-0-ssl-2-0-ssl-3-0-or-tls-1-0...
https://docs.microsoft.com/es-es/windows-server/security/tls/tls-registry-settings
0

miércoles, 30 de octubre de 2019

Deshabilitar TLS 1.0 y TLS 1.1 en NGINX



Cómo deshabilitar TLS 1.0 y TLS 1.1 en un servidor que esté ejecutando NGINX para servir contenido.



Transport Layer Security (TLS) es un protocolo de encriptación usado encima de la capa HTTP para generar conexiones HTTPS, es decir, conexiones seguras vía navegador web entre un cliente y un servidor (entre otros usos). TLS es el sucesor del protocolo SSL. A su vez, TLS ha ido evolucionando en diferentes versiones desde el año 1999 hasta la actualidad: TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3...

Compañías de la talla de Microsoft, Google o Mozilla han declarado que dejarán de ofrecer soporte para TLS 1.0 y TLS 1.1 en marzo de 2020, por lo que si tenemos un servidor web corriendo NGINX (tanto en modo servidor como en modo Reverse Proxy), sería recomendable deshabilitarlos, puesto que dejarán de ser un estándar. Las conexiones HTTPS se podrán seguir realizando con TLS 1.2 o superior.


Backup



Antes de deshabilitar TLS 1.0 y TLS 1.1 en una instalación de NGINX, deberíamos empezar por realizar un backup de la configuración actual de NGINX que se esté ejecutando en el servidor:

HOST# cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup


Configuración general



Para que NGINX solo negocie con TLS 1.2 o superior en todos los dominios que apuntan a él, debemos editar la directiva "server" general del servidor en el archivo /etc/nginx/nginx.conf y añadir (o modificar) la opción ssl_protocols para que quede tal que así:

server { listen 443 ssl http2; ... ssl_protocols TLSv1.2 TLSv1.3; }

Si ya disponemos de la directiva ssl_protocols, simplemente debemos eliminar los valores TLSv1 y TLSv1.1.


Configuración independiente de un dominio



Puede que se de el caso de que usemos NGINX como Reverse Proxy y queramos que un dominio determinado sea accesible con TLS 1.0, por ejemplo, porque se conectan a él máquinas que tienen un sistema operativo antiguo embedido y solo pueden negociar conexiones HTTPS con TLSv1.

Para este tipo de casos, podemos configurar la entrada de tipo "server" que agrupa la configuración del dominio en cuestión (por ejemplo, dominio.net) para que este dominio funcione con TLS 1.0 de forma independiente a la configuración general. Para ello, especificamos en el bloque server del dominio los ssl_protocols que queremos que acepte (TLSv1, TLSv1.1, TLSv1.2, etc.):

server { listen 443 ssl http2; server_name www.dominio.net dominio.net; ... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; }


Aplicar cambios



Una vez configurados los protocolos, solo queda recargar la configuración de NGINX:

HOST# nginx -s reload

A partir de este momento, si realizamos un test de conexión HTTPS (con Qualys, nmap, etc.), observaremos que el servidor ya no negocia con TLS 1.0 ni TLS 1.1.
0

miércoles, 23 de octubre de 2019

Deshabilitar TLS 1.0 y TLS 1.1 en Apache



Cómo deshabilitar TLS 1.0 y TLS 1.1 en un servidor web Apache.

Microsoft, Google y Mozilla han declarado que dejarán de ofrecer soporte para TLS 1.0 y TLS 1.1 en marzo de 2020 en sus navegadores web (Edge, Chrome y Firefox, respectivamente).

Cuando accedemos a una web por HTTPS, cliente y servidor negocian la encriptación con un protocolo que ambos soporten (TLS 1.0, TLS 1.2, TLS 1.3, etc.). A partir de marzo de 2020, TLS 1.1 ya no será aceptado como protocolo válido por los navegadores web de las compañías mencionadas.

Aprovechando que los navegadores web actuales ya no podrán usar TLS 1.1 o inferior, podemos aprovechar para deshabilitar estos protocolos de encriptación HTTPS obsoletos e inseguros en nuestros servidores web. Por un lado ganaremos en seguridad; por otro lado perderemos en compatibilidad con ordenadores que usen navegadores antiguos (NOTA: nadie debería usar navegadores antiguos).

Apache, en su rama actual 2.4.x, soporta TLS 1.0 y TLS 1.1 por defecto.

Para deshabilitar estos protocolos, debemos editar el archivo ssl-global.conf:

HOST# vi /etc/apache2/ssl-global.conf

En este archivo, encontraremos la siguiente sección:

# SSL protocols # Supporting TLS only is adequate nowadays SSLProtocol all -SSLv2 -SSLv3

Por defecto, Apache ya no acepta encriptación SSL, solo TLS.


Opciones



Para dejar de aceptar TLS 1.0 y TLS 1.1 en Apache, deberemos cambiar la directiva SSLProtocol all. Al modificarla, podemos usar uno de estos dos métodos, segun si queremos aceptar o rechazar cipher suites en nuestro servidor web.

Método 1

Con el método 1, indicamos al servidor web qué protocolos no acepta. Es decir, el servidor aceptará todos aquellos cipher suites que no estén en la lista.

Para quitar protocolos de encriptación, debemos usar el signo "-" precediendo el nombre del protocolo:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1.0 -TLSv1.1


Método 2

Con el método 2 indicamos solo aquellos cipher suites que sí acepta el servidor.

Para permitir solo ciertos protocolos, los indicamos explícitamente:

SSLProtocol all TLSv1.2 TLSv1.3


Conclusión



Personalmente, prefiero el método 1, ya que de este modo, podemos ir especificando los protocolos que van quedando obsoletos a medida que vayan quedando obsoletos. Bajo mi punto de vista, es más fácil estar al día sobre qué protocolos se "deprecan" que sobre qué protocolos se lanzan.
0

miércoles, 16 de octubre de 2019

Averiguar versión de VMWare ESXi de un host



Cómo averiguar la versión y el build number de VMWare ESX/ESXi que está corriendo un host.



Puede que no recordemos qué versión de VMWare ESXi se está ejecutando sobre un host y necesitemos averiguarlo para ver si cierta versión de un sistema operativo está soportada en esa versión. O puede que simplemente queramos saber la versión para mantenerla en nuestra documentación interna.

Para averiguar la versión de VMWare que se ejecuta en un host determinado, existen dos formas:

- Vía SSH
- Vía vSphere


SSH



Para ver la versión de VMWare que se está ejecutando en un host por SSH, deberemos conectarnos al host vía SSH y ejecutar el siguiente comando:

[root@esxigs:~] vmware -v VMware ESXi 6.0.0 build-6921384

El resultado es la versión y build number de ESXi que está corriendo en el host.


vSphere



Para ver la versión de VMWare mediante vSphere Web Client, deberemos conectarnos al apartado web del vSphere y seguir los siguientes pasos:

1. Ir a Home.
2. Clicar Hosts and Clusters.
3. Abrir el datacenter.
4. Expandir el cluster.
5. Clicar sobre el host.
6. Clicar sobre Summary.
7. En el apartado "Configuration" se encuentra el campo "ESX/ESXi Version":




Fuentes:

https://kb.vmware.com/s/article/1022196
0

miércoles, 9 de octubre de 2019

Conectarse como root a instancia Linux en AWS



Cómo conectarse directamente como root a una instancia EC2 Linux en AWS.



Al crear una instancia Linux en AWS, Amazon nos obliga a iniciar una conexión por SSH a una instancia EC2 Linux en AWS usando un usuario no privilegiado predefinido por ellos, como ec2-user o ubuntu. Si tratamos de iniciar una sesión SSH como root, nos encontraremos con el siguiente mensaje:

Using username "root". Authenticating with public key "imported-openssh-key" Please login as the user "ec2-user" rather than the user "root".

Para permitir el login del usuario root vía SSH, cambiamos al usuario root:

HOST# sudo su

Nos situamos en la home de root:

HOST# cd /root/.ssh

Y buscamos el fichero authorized_keys, el cual contendrá algo parecido a:

HOST# cat authorized_keys no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"ec2-user\" rather than the user \"root\".';echo;sleep 10" ssh-rsa AAAAB3NzaC1yc2EAAAADA+K4WkbVwemgociUzbzVtBb5SJZHbV1uqKNBH8mS82o6ffjhUGljbUjTj5EStJVMqnxFZpi7+RukgH55lwtKeIASZxjyiHEKq+0xg3iyRno2masFCgiwZD18znPnUFtX0Js8vM0+QOOsb7EE+w8nLuk+m4Jxze+eTjjErRSrTkpQejeJ3OkfGce3GLJLCwA2KsUMMLEsAvyTL6qn9ppk+VaO1fNeQtrr0OYSBKo3 KEY_NAME

Para permitir el login de root por SSH, tenemos que borrar el "command" con algún editor tipo vi:

command="echo 'Please login as the user \"ec2-user\" rather than the user \"root\".';echo;sleep 10"

A continuación, debemos editar el fichero de configuración de SSH (/etc/ssh/sshd_config) y modificar la política PermitRootLogin, la cual viene desactivada por defecto en AWS (PermitRootLogin No).

Si queremos acceder solamente con clave pública/privada:

PermitRootLogin wihtout-password

Si queremos acceder con password:

PermitRootLogin Yes

Una vez modificada la política, recargamos la configuración del servicio SSH para que lea los cambios:

HOST# systemctl reload sshd

Hecho esto, ya podremos conectarnos a la instancia EC2 Linux por SSH con el usuario root.
0

miércoles, 2 de octubre de 2019

Linux: espacio ocupado no concuerda con archivos



Cómo liberar espacio bloqueado en disco en un sistema Linux.



El sistema de monitorización que uso para ver si las máquinas virtuales tienen el disco lleno, la CPU al 100%, etc. me envió un correo diciendo que el directorio raíz de un sistema Linux estaba prácticamente lleno. Me conecté a la máquina afectada y lo comprobé:

root@host:/# df -h S.ficheros      Size   Used   Avail   Use%   Montado en /dev/sda1        38G    30G    5,9G    84%   / tmpfs           7,9G      0    7,9G     0%   /lib/init/rw udev            7,9G   100K    7,9G     1%   /dev tmpfs           7,9G      0    7,9G     0%   /dev/shm

Al ejecutar el comando df vi que había 30 GB usados de un total de 38 GB aprovisionados en /dev/sda1. En cambio, al mirar qué carpeta estaba ocupando más espacio en disco mediante du, no vi ningún directorio donde se concentrara esa ocupación. Tampoco el total de GB ocupados cuadraban con los mostrados por df. Como vemos, no había más de 3 GB usados en total:

root@host:/# du -hs * | sort -h 0      dead.letter 0      initrd.img 0      proc 0      sys 0      vmlinuz 4,0K   lib64 4,0K   mnt 4,0K   opt 4,0K   selinux 8,0K   backup 8,0K   srv 12K    media 16K    lost+found 52K    tmp 100K   dev 3,6M   lib32 4,5M   sbin 5,8M   bin 6,6M   etc 16M    boot 22M    root 49M    home 115M   lib 1,0G   usr 1,8G   var

Lo que podía estar ocurriendo es que algún proceso estuviese usando un archivo que hubiese sido eliminado y como el buffer no se podía vaciar porque no existía el archivo hacia el que el proceso quería escribir, se mantuviera esa información en el limbo hasta que ese proceso mueriera, aumentando así el tamaño del buffer hasta ocupar esos 30 GB mencionados anteriormente.

Podemos ver qué procesos usan archivos que han sido borrados mediante:

root@host:/# lsof | grep deleted

En el resultado, vi que el programa apache2 estaba tratando de escribir en los archivos /var/log/apache2/error.log y /var/log/apache2/other_vhosts_access.log, los cuales habían sido eliminados:

apache2 ... /var/log/apache2/error.log (deleted) apache2 ... /var/log/apache2/other_vhosts_access.log (deleted)

Como el causante era Apache, tras reiniciar Apache se liberó el espacio ocupado en /dev/sda1:

root@host:/# df -h S.ficheros      Size   Used   Avail   Use%   Montado en /dev/sda1        38G   4,7G    32G     14%   / tmpfs           7,9G      0    7,9G     0%   /lib/init/rw udev            7,9G   100K    7,9G     1%   /dev tmpfs           7,9G      0    7,9G     0%   /dev/shm

¡Misterio resuelto!


Fuentes:

https://serverfault.com/questions/315181/df-says-disk-is-full-but-it-is-not
0

miércoles, 25 de septiembre de 2019

Migrar colas de impresión entre Windows Servers



Cómo migrar colas de impresión o impresoras de un Windows Server a otro Windows Server.



Si tenemos colas de impresión funcionando en un Windows Server antiguo - por ejemplo en un Windows Server 2008 - en algún momento tendremos que migrarlas a un Windows Server más reciente.

En este artículo, muestro como migrar todas las colas de impresión de un Windows Server 2008 (ya fuera de soporte por parte de Microsoft) a un Windows Server 2019 recién instalado.


Servidor origen



Lo primero que tendremos que hacer para migrar las colas de impresión es asegurarnos de que el Windows Server origen tenga instalado el rol de "Print and Document Services". Este rol añade al componente "Print Management" al servidor, necesario para exportar la lista de impresoras, sus drivers, IPs, etc. a un archivo. Este archivo será el que luego importemos en el servidor destino.



Clicamos con el botón derecho sobre "Print Management" y elegimos la opción "Migrate Printers...":



Elegimos la opción "Export" y exportamos todos los datos de las impresoras presentes en el sistema.



Este proceso nos generará un "Printer Migration File", el cual contiene los nombres de todas las impresoras presentes en el sistema, así como sus IPs, marca y modelo y el driver asociado.


Servidor Destino



Nos aseguramos de que el rol "Print Services" esté instalado en el servidor destino:



Dentro del Server Manager, nos dirigimos a Tools > Print Management:



En Print Management, botón derecho y elegimos la opción "Migrate Printers...":



Seleccionamos la opción "Import...", abrimos el archivo generado en el apartado anterior y clicamos siguiente hasta que el import finalice:



En este caso, el proceso de import ha terminado con advertencias; algunas impresoras de la lista ya no existen, y por lo tanto, su IP ya no responde. Es un buen momento para eliminarlas.

Llegados a este punto, solo nos queda configurar el FQDN al que apuntan los servicios de impresión para que apunte al nuevo servidor. Con esto, ya habremos migrado satisfactoriamente el servicio de impresión a una versión actual de Windows Server.
0

miércoles, 18 de septiembre de 2019

Re-registrar SUSE Linux Enterprise Server 'cloud'



Registrar SLES en AWS, Error Unexpected exception. Receive: script died unexpectedly Please file a bug report about this en un sistema SUSE Linux Enterprise Server en Amazon Web Services.



Actualizando un sistema SUSE Linux Enterprise Server (SLES) alojado en Amazon Web Services (AWS), me encontré con un mensaje de error un tanto curioso que no había visto nunca antes:

ec2-user@ip-10-250-3-73:~> sudo zypper up Refreshing service 'Basesystem_Module_x86_64'. Refreshing service 'Containers_Module_x86_64'. Refreshing service 'Desktop_Applications_Module_x86_64'. Refreshing service 'Development_Tools_Module_x86_64'. Refreshing service 'Legacy_Module_x86_64'. Refreshing service 'Public_Cloud_Module_x86_64'. Refreshing service 'SUSE_Cloud_Application_Platform_Tools_Module_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_x86_64'. Unexpected exception. Receive: script died unexpectedly Please file a bug report about this. See http://en.opensuse.org/Zypper/Troubleshooting for instructions.

No recuerdo haber visto ningún otro error en SLES que dijera al usuario explícitamente que informara de un bug. Sea como sea, la situación era que el sistema no me permitía instalar paquetes, ni realizar actualizaciones ni migraciones hacia Service Packs, por lo que suponía un riesgo de seguridad.

Después de eliminar y añadir repositorios al S.O. y de jugar con SUSEConnect sin éxito, encontré un comando que debe ser exclusivo de las instancias cloud de SLES y que me fue la mar de bien:

ec2-user@ip-10-250-3-73:~> sudo /usr/sbin/registercloudguest --force-new

Después de forzar el re-registro de la instancia con este comando llamado "registercloudguest", ya pude actualizar el sistema operativo sin mayor problema:

ec2-user@ip-10-250-3-73:~> sudo zypper up Refreshing service 'Basesystem_Module_x86_64'. Refreshing service 'Containers_Module_x86_64'. Refreshing service 'Desktop_Applications_Module_x86_64'. Refreshing service 'Development_Tools_Module_x86_64'. Refreshing service 'Legacy_Module_x86_64'. Refreshing service 'Public_Cloud_Module_x86_64'. Refreshing service 'SUSE_Cloud_Application_Platform_Tools_Module_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_x86_64'. Refreshing service 'Server_Applications_Module_x86_64'. Refreshing service 'Web_and_Scripting_Module_x86_64'. ...

Comentar que los registros generados por este comando pueden consultarse en:

/var/log/cloudregister

No hay ninguna entrada en las páginas man del sistema operativo para el comando registercloudguest, ni hay más documentación por parte de SUSE al respecto, así que solo debe poderse ejecutar con las opciones mencionadas y solamente en instancias cloud.


Fuentes:

https://forums.suse.com/showthread.php?14030-SLES12SP4-fails-cloud-registration
https://www.suse.com/support/kb/doc/?id=7022311
1

miércoles, 11 de septiembre de 2019

Redirigir HTTP a HTTPS en NGINX



Cómo redireccionar las peticiones HTTP a HTTPS en NGINX.



Cuando un usuario quiere acceder a una página web, normalmente accede a dominio.com en vez de acceder a https://dominio.com. De esta forma, su sesión en la página web se desempeña por HTTP, con todos los riesgos de seguridad que ello conlleva.

Desde NGINX podemos configurar que se redirija automáticamente a un usuario desde [http://] dominio.com hacia https://dominio.com de forma automática, para así asegurar su sesión. En determinados casos, como en el e-commerce, este requisito es indispensable para poder operar con TPVs, por ejemplo, donde la pasarela de pago debe estar asegurada mediante HTTPS obligatoriamente.


Redirección 301



Para automatizar la redirección de HTTP a HTTPS en todos los dominios que apunten al NGINX, lo más habitual es usar una redirección 301 en las solicitudes HTTP. Una redirección 301 devuelve el mensaje "Moved Permanently" (Movido permanentemente), el cual indica al navegador que efectue una redirección desde una determinada URL hacia un nuevo destino URL. Para los usuarios, una redirección 301 implica que cambie la URL de la barra de direcciones del navegador.


Configurando NGINX



Para que NGINX realice una redirección 301 de HTTP a HTTPS en la URL que el usuario está visitando, podemos usar este código dentro de la directiva http en nuestro archivo de configuración .conf:

http {     server {         listen 80;         return 301 https://$host$request_uri;     } ... }

Si quisiéramos realizar la redirección en un solo dominio en vez de aplicar esta redirección a todos los dominios configurados en NGINX, deberíamos incorporar el server_name a la directiva server tal que así:

http {     server {         server_name dominio.com;         listen 80;         return 301 https://$host$request_uri;     } ... }

Si queremos hacer la redirección en varios dominios, los pondremos uno detrás de otro en la opción server_name, separados por espacios.


Certificado SSL



Por último, recordar que para evitar que el navegador muestre a los visitantes un aviso del tipo "Detectado riesgo de seguridad" al acceder al dominio por HTTPS, deberemos configurar un certificado SSL en el NGINX para el dominio en cuestión.


Fuentes:

https://miposicionamientoweb.es/redireccion-301/
https://www.sistrix.es/preguntale-a-sistrix/optimizacion-onpage/codigo-de-estado-http/3xx-redirect...
0

miércoles, 4 de septiembre de 2019

Averiguar versión de GPFS instalada en Linux



Cómo averiguar qué versión de GPFS está instalada en un sistema operativo Linux, averiguar versión instalada de General Parallel File System, ver versión de IBM Spectrum Scale.



Hay aplicaciones, como SAP, que se suelen instalar sobre un sistema de archivos GPFS (General Parallel File System) por su velocidad de acceso a disco y su escalabilidad.

GPFS, como la mayoría de productos, evoluciona con cada versión, es decir, recibe cambios que pueden provocar un comportamiento inesperado en las aplicaciones que interactúan con él. Esto significa que scripts o programas que interactúan con un clúster GPFS puede que dejen de funcionar o funcionen erróneamente después de actualizar el programa o la versión de GPFS.

Para prevenir problemas, un buen comienzo es averiguar qué versión de GPFS está instalada en una máquina. Para ello, IBM no ha creado un comando específico, pero sí existen un par de métodos que nos ayudarán a encontrar la susodicha versión.


rpm



Para averiguar la versión de GPFS instalada en un sistema Linux podemos usar el comando siguiente:

HOST# rpm -qa | grep gpfs gpfs.gpl-4.2.3-13.noarch gpfs.gskit-8.0.50-86.x86_64 gpfs.license.std-4.2.3-13.x86_64 gpfs.docs-4.2.3-13.noarch gpfs.ext-4.2.3-13.x86_64 gpfs.msg.en_US-4.2.3-13.noarch gpfs.base-4.2.3-13.x86_64

Las opciones "qa" del comando rpm equivalen a "query all", es decir, busca todos los paquetes instalados en el sistema operativo. Con grep, filtramos los paquetes que contienen "gpfs" en su nombre, para ver solo aquellos que tienen relación con GPFS.

Con todo esto, llegamos al paquete "gpfs.base", el cual nos dice que tenemos instalada la versión 4.2.3 del General Parallel File System en este sistema.


mmfsadm



IBM Spectrum Scale incluye una utilidad llamada mmfsadm, la cual nos muestra en pantalla la versión del daemon de GPFS instalado en la máquina, así como otros datos de la instalación:

HOST# mmfsadm dump version Dump level: verbose Build branch "4.2.3.13 ". Built on Aug 7 2019 at 13:50:36 by . Current daemon version 1717, minimum compatible version 1301 ...


mmlsconfig



A nivel de cluster, mmlsconfig nos muestra la versión mínima de GPFS del cluster:

HOST# /usr/lpp/mmfs/bin/mmlsconfig Configuration data for cluster HANAcluster.gpfsnode01: ------------------------------------------------------ clusterName HANAcluster.gpfsnode01 clusterId 774744069380081798 dmapiFileHandleSize 32 dataStructureDump /tmp/GPFSdump pagepool 4G maxMBpS 2048 maxFilesToCache 4000 skipDioWriteLogWrites yes nsdInlineWriteMax 1M prefetchAggressivenessWrite 2 readReplicaPolicy local nsdThreadsPerDisk 24 enableLinuxReplicatedAio no restripeOnDiskFailure yes ignorePrefetchLUNCount yes minReleaseLevel 4.2.3.9 ccrEnabled yes autoload yes adminMode central File systems in cluster HANAcluster.gpfsnode01: ----------------------------------------------- /dev/sapmntdata

La línea que empieza por minReleaseLevel nos indica la versión más baja de GPFS instalada en el cluster.


Conclusión



Sabiendo la versión de GPFS instalada en un sistema, ya podemos indagar si el software que queremos instalar o actualizar soporta dicha versión, para proceder o no con su instalación.


Fuentes:

https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000...
https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.0/com.ibm.itsm.hsmul.doc...
1

miércoles, 28 de agosto de 2019

Ampliar espacio en disco en Windows Server 2003



Cómo ampliar (o extender) un volumen (o disco duro) en Windows Server 2003.



A estas alturas del siglo XXI, usar Windows Server 2003 debería estar prohibido, pero mientras haya aplicaciones legacy que solo funcionen en ese sistema y nuestro empleador no quiera ejecutarlas en contenedores o no nos atrevamos a hacerlo, no nos queda más remedio que conservar estas máquinas virtuales y realizarles el mantenimiento que requieran.

Windows Server 2003 no dispone de la utilidad de Disk Management de la que disponen versiones más actuales de Windows Server para administrar discos, así que si queremos extender el tamaño de un disco en este sistema, deberemos usar la utilidad diskpart incluida en Windows 2000 / 2003 / XP.

Para extender un disco , abrimos el símbolo del sistema e iniciamos diskpart.exe:

C:\Documents and Settings\Administrador>diskpart.exe Microsoft DiskPart version 5.2.3790.3959 Copyright (C) 1999-2001 Microsoft Corporation. En el equipo: SERVER5 DISKPART>

Escribir list volume para mostrar los volúmenes existentes:

DISKPART> list volume Volumen ### Ltr    Etiqueta     Fs     Tipo       Tamaño    Estado    Info ----------- ---   -----------  ----- ----------   ------- --------- --------   Vol. 0     D                        DVD-ROM        0 B   Correcto   Vol. 1     F    Nuevo vol2   NTFS   Partición    60 GB   Correcto   Vol. 2     C                 NTFS   Partición   150 GB   Correcto  Sistema   Vol. 3     J    Nuevo vol6   NTFS   Partición   120 GB   Correcto   Vol. 4     H    Nuevo vol4   NTFS   Partición    60 GB   Correcto   Vol. 5     K    Nuevo vol7   NTFS   Partición    80 GB   Correcto   Vol. 6     L    Nuevo vol8   NTFS   Partición    60 GB   Correcto  Archivo   Vol. 7     G    Nuevo vol3   NTFS   Partición    50 GB   Correcto   Vol. 8     I    Nuevo vol5   NTFS   Partición   120 GB   Correcto

Escribir select volume seguido del número de volumen a extender. Elegimos, por ejemplo, el vol. 8:

DISKPART> select volume 8 El volumen 8 es el volumen seleccionado.

Escribir extend seguido de los valores opcionales [size=n] [disk=n] [noerr].

A continuación, una descripción de los parámetros opcionales:

size=n
Espacio, en megabytes (MB), que se agrega a la partición actual. Si no especifica un tamaño, el disco se extiende para usar todo el espacio contiguo sin asignar.

disk=n
El disco dinámico en el que extender el volumen. Se asigna en el disco un espacio igual a size=n. Si no se especifica ningún disco, el volumen se extiende en el actual.

noerr
Sólo para secuencias de comandos. Cuando se produce un error, este parámetro especifica que Diskpart continúa procesando los comandos como si el error no hubiera ocurrido. Sin el parámetro noerr, un error hace que Diskpart se cierre con un código de error.

Si queremos extender el disco I (volumen 8) al completo, simplemente usaremos extend:

DISKPART> extend DiskPart ha extendido el volumen satisfactoriamente.

Una vez haya aparecido este mensaje en pantalla, el nuevo espacio ya está disponible en la unidad.


Fuentes:

https://support.microsoft.com/es-es/help/325590/how-to-extend-a-data-volume-in-windows-server...
0

miércoles, 21 de agosto de 2019

NFS: Stale file handle



Cómo solucionar el error "NFS: Stale file handle" en un sistema Linux con carpetas remotas.



Al conectarme a una máquina Linux y dirigirme a una carpeta montada por NFS, vi que dicha carpeta no era accesible. Lancé entonces un df y me encontré con el siguiente mensaje:

HOST # df -h df: ‘/usr/mount’: Stale file handle Filesystem                   Size   Used   Avail   Use%   Mounted on /dev/sda2                     95G    29G     62G    32%   / devtmpfs                     119G   8.0K    119G     1%   /dev tmpfs                        119G    80K    119G     1%   /dev/shm tmpfs                        119G   114M    119G     1%   /run tmpfs                        119G      0    119G     0%   /sys/fs/cgroup /dev/sda1                    148M      0    148M     0%   /boot/efi

Este problema se da cuando un sistema es apagado de forma brusca y no se desmontan correctamente los puntos de montaje del mismo, dando lugar a que la parte servidor crea que siguen montados.

Cuando la máquina cliente vuelve a estar operativa y trata de montar la carpeta compartida con ella, no puede montarla y muestra este error titulado "Stale file handle".

Para solucionar este problema, debemos conectarnos al sistema desde el que se exportan las carpetas (lado servidor) y re-exportar las carpetas compartidas.


Lado servidor



Primero, desmontamos los exports desde el lado servidor:

HOST # exportfs -ua

Luego, verificamos que no se está compartiendo ninguna carpeta:

HOST # cat /proc/fs/nfs/exports # Version 1.1 # Path Client(Flags) # IPs

Por último, re-exportamos todas las carpetas compartidas:

HOST # exportfs -a

Una vez hecho esto, el montaje de la carpeta ya debería ser posible en el sistema operativo cliente.


Lado cliente



Para montar las carpetas compartidas desde el lado cliente podemos hacerlo de forma individual o podemos desmontar y volver a montar todas las carpetas compartidas al mismo tiempo. Para desmontar/montar todas las carpetas al mismo tiempo, podemos usar la opción -a (all):

HOST # umount -fa

HOST # mount -a

Una vez hecho esto, ya deberíamos ver correctamente el punto de montaje al lanzar el comando df:

HOST # df -h Filesystem                   Size   Used   Avail   Use%   Mounted on /dev/sda2                     95G    29G     62G    32%   / devtmpfs                     119G   8.0K    119G     1%   /dev tmpfs                        119G    80K    119G     1%   /dev/shm tmpfs                        119G   114M    119G     1%   /run tmpfs                        119G      0    119G     0%   /sys/fs/cgroup /dev/sda1                    148M      0    148M     0%   /boot/efi srv1.dominio.com:/usr/mount   10G     5G      5G    50%   /usr/mount


Fuentes:

https://unix.stackexchange.com/a/447581
0

miércoles, 14 de agosto de 2019

ping / traceroute en un switch eligiendo IP origen



Cómo hacer un ping o un traceroute desde un switch Aruba eligiendo la IP de origen desde donde se inicia la conexión, para hacer pruebas de conectividad entre VLANs.



Si tenemos una red segmentada, es decir, una red donde diferentes dispositivos están ubicados en distintos rangos IP o VLANs, nos puede interesar probar si un dispositivo ubicado en un rango determinado tiene conectividad con otro dispositivo situado en otro rango, o si por el contrario, el dispositivo que estamos instalando no puede conectar con el otro extremo.

Imaginemos un switch con 3 VLANS, configurado de la siguiente manera:

Startup configuration: 3 ; J9729A Configuration Editor; Created on release #WB.15.12.0015 ; Ver #05:18.41.ff.35.0d:9b hostname "SWITCH-3" module 1 type j9729a ip default-gateway 192.168.101.10 snmp-server community "public" unrestricted vlan 1 name "DEFAULT_VLAN" untagged 1-48 ip address 192.168.101.11 255.255.255.0 exit vlan 2 name "VLAN2" untagged 1-48 ip address 192.168.102.11 255.255.255.0 exit vlan 3 name "VLAN3" tagged 1-48 ip address 192.168.103.11 255.255.255.0 qos priority 6 voice exit spanning-tree no tftp server no autorun no dhcp config-file-update no dhcp image-file-update

Como la VLAN 1 o DEFAULT_VLAN tiene la IP 192.168.101.11 asignada, si hacemos un ping desde el switch a una IP, por ejemplo ping 192.168.1.1, el ping siempre se realizará desde la IP origen 192.168.101.11, es decir, la IP de la VLAN por defecto.

Para comprobar si un dispositivo ubicado en la VLAN 2 o la VLAN 3 tiene conectividad con el dispositivo con IP 192.168.1.1, podemos modificar el origen de las peticiones de ping o traceroute.

La sintaxis en estos casos es:

comando <ip_destino> source <ip_origen>

Por ejemplo, para realizar un ping a 192.168.1.1 desde la VLAN 2:

# ping 192.168.1.1 source 192.168.102.1

O también:

# ping 192.168.1.1 source 2

Para realizar un traceroute, sería la misma sintaxis:

# traceroute 192.168.1.1 source 192.168.102.1

O el número de VLAN:

# traceroute 192.168.1.1 source 2

A partir de aquí, si desde la VLAN 1 hay conectividad, pero desde las otras VLAN no, ya podemos ir haciendo los cambios de routing pertinentes en los dispositivos intermedios de la red (firewalls, routers, switches, etc.) para establecer conectividad entre ambos lados.

Fuentes:

https://community.hpe.com/t5/LAN-Routing/source-ping-from-HP-devices/td-p/5348859#.XVFCtHtS-Uk
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c02920971
0