Conectar a un FTP desde SUSE Linux 15 o superior

Escrito por Blai el 30.12.20

Cómo conectar a un servidor vía FTP desde SUSE Linux Enterprise Server 15 o superior.



Hoy he tenido que conectar hacia un servidor usando FTP, ya que en el otro lado no quieren usar SFTP. Cuál ha sido mi sorpresa que al tratar de realizar la conexión como he hecho toda la vida, es decir:

HOST# ftp 192.168.1.1

El comando ftp me ha devuelto:

If 'ftp' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf ftp

Al usar SUSE Linux Enterprise Server 15, he ido a software.opensuse.org para buscar el binario 'ftp', pero no he encontrado el paquete. Tras darle vueltas al asunto, me he decantado por instalar lftp para poder conectar a un servidor remoto usando el protocolo ftp, ya que el programa lftp permite usar múltiples protocolos para iniciar una conexión (FTP, FTPS, HTTP, HTTPS, FISH, SFTP...).

He instalado lftp con zypper:

HOST# zypper install lftp

Tras instalar lftp, he ejecutado el comando 'ftp' y he visto lo siguiente:

HOST# ftp Wrapper for lftp to simulate compatibility with lukemftp lftp :~>

Es decir, una vez instalado, lftp actúa como wrapper al usar el comando ftp.

Visto esto, me he conectado al servidor como he venido haciendo toda la vida:

HOST# ftp 192.168.1.1 Wrapper for lftp to simulate compatibility with lukemftp Name (root): user Password: lftp user@192.168.1.1:~>

Listo, ya podemos volver a usar el comando ftp desde la terminal o ejecutarlo de forma desatendida dentro de nuestros scripts al usar un SUSE Linux Enterprise Server 15 o superior.

Leer más »

NGINX: SSL y no SSL en el mismo puerto

Escrito por Blai el 23.12.20

Cómo ejecutar protocolos con SSL y sin SSL en el mismo puerto con NGINX.



NGINX tiene una característica llamada "$ssl_preread_protocol" que le permite distinguir entre SSL / TLS y otros protocolos al recibir tráfico en un puerto TCP determinado. Esto es útil para recibir dos aplicaciones distintas en un mismo puerto y evitar así las restricciones de un firewall en origen, ejecutando, por ejemplo, HTTPS y SSH en el mismo puerto pero enviándolo por detrás a distintos hosts.

NGINX inspecciona el mensaje ClientHello inicial en una conexión SSL o TLS y determina la versión de TLS. Por otro lado, si la conexión no usa SSL o TLS, la variable $ssl_preread_protocol permanecerá en blanco, lo que indica que la conexión está usando un protocolo que no es SSL / TLS, como SSH.

Veamos un ejemplo de esto:

stream { upstream ssh { server 192.0.2.1:22; } upstream web { server 192.0.2.2:443; } map $ssl_preread_protocol $upstream { default ssh; "TLSv1.2" web; } server { listen 443; proxy_pass $upstream; ssl_preread on; } }

En el ejemplo anterior, NGINX escucha por el puerto 443.

Si la conexión no es TLS, el tráfico va al puerto 22 del servidor 192.0.2.1.

Si, por el contrario, la conexión contiene TLS, el tráfico se envía al puerto 443 del host 192.0.2.2.


Fuentes:

https://www.nginx.com/blog/running-non-ssl-protocols-over-ssl-port-nginx-1-15-2/

Leer más »

Windows: averiguar origen de NTP

Escrito por Blai el 16.12.20

Averiguar donde realiza consultas NTP una máquina Windows.



Si queremos saber a qué servidor está realizando consultas NTP nuestra máquina Windows, podemos usar la utilidad de línea de comandos w32tm.

Para averiguar el orgien del NTP, abrir un cmd y ejecutar el siguiente comando:

w32tm /query /status

En un entorno real:

C:\Users\blai>w32tm /query /status Indicador de salto: 0(ninguna advertencia) Capa: 4 (referencia secundaria - sincronizada mediante (S)NTP) Precisión: -23 (119.209ns por tick) Demora de raíz: 0.0934627s Dispersión de raíz: 0.1888415s Id. de referencia: 0xC0A86E35 (IP de origen: 192.168.1.1) Última sincronización de hora correcta: 04/06/2021 15:32:08 Origen: DC01.dominio.local Intervalo de sondeo: 12 (4096s)

En el output, DC01.dominio.local y 192.168.1.1 son la dirección de origen de NTP.

Leer más »

Linux: conectarse a una carpeta en red con SMBv1

Escrito por Blai el 9.12.20

¿Cómo conectarse a una carpeta compartida desde Linux con Samba versión 1?



Samba usa por defecto la versión 2 para conectarse a un recurso compartido en red.

Por otro lado, el binario smbclient permite usar SMBv1 para conectarse a una carpeta especificándolo en el parámetro options de la línea de comandos. Esto es útil si queremos conectarnos a un dispositivo antiguo que solo acepte SMBv1.

Para conectarnos a un dispositivo vía línea de comandos usando SMBv1:

HOST# smbclient --option='client min protocol=NT1' 192.168.1.1

192.168.1.1 es la IP del dispositivo remoto.

Fuentes:

https://wiki.samba.org/index.php/Samba_4.11_Features_added/changed#SMB1_is_disabled_by_default

Leer más »

Instalar smbclient en SUSE Linux

Escrito por Blai el 2.12.20

Cómo instalar smbclient en SLES (SUSE Linux Enterprise Server).



Recientemente quise instalar smbclient en un SLES para conectarme a una carpeta compartida. La particularidad de este sistema es que ya tenía un servicio de samba corriendo a modo servidor, pero no tenía instalado el ejecutable smbclient, necesario par actuar como cliente:

HOST# smbclient -bash: smbclient: command not found

Tras probar varias cosas como "zypper install smbclient", "zypper install smb*", "zypper install smb-*" etc. logré dar en el clavo con "zypper install samba-client":

HOST# zypper install samba-client Refreshing service 'Basesystem_Module_15_SP2_x86_64'. Refreshing service 'Desktop_Applications_Module_15_SP2_x86_64'. Refreshing service 'Development_Tools_Module_15_SP2_x86_64'. Refreshing service 'Python_2_Module_15_SP2_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP2_x86_64'. Refreshing service 'SUSE_Package_Hub_15_SP2_x86_64'. Refreshing service 'Server_Applications_Module_15_SP2_x86_64'. Refreshing service 'Web_and_Scripting_Module_15_SP2_x86_64'. Loading repository data... Reading installed packages... Resolving package dependencies... The following 3 NEW packages are going to be installed: gvfs-backend-samba libsmbclient0 samba-client 3 new packages to install. Overall download size: 1.3 MiB. Already cached: 0 B. After the operation, additional 3.6 MiB will be used. Continue? [y/n/v/...? shows all options] (y): y

Una vez instalado, ya pude ejecutar smbclient:

HOST# smbclient Usage: smbclient [-?EgqBVNkPeC] [-?|--help] [--usage] [-R|--name-resolve=NAME-RESOLVE-ORDER] [-M|--message=HOST] [-I|--ip-address=IP] [-E|--stderr] [-L|--list=HOST] [-m|--max-protocol=LEVEL] [-T|--tar=IXFqgbNan] [-D|--directory=DIR] [-c|--command=STRING] [-b|--send-buffer=BYTES] [-t|--timeout=SECONDS] [-p|--port=PORT] [-g|--grepable] [-q|--quiet] [-B|--browse] [-d|--debuglevel=DEBUGLEVEL] [-s|--configfile=CONFIGFILE] [-l|--log-basename=LOGFILEBASE] [-V|--version] [--option=name=value] [-O|--socket-options=SOCKETOPTIONS] [-n|--netbiosname=NETBIOSNAME] [-W|--workgroup=WORKGROUP] [-i|--scope=SCOPE] [-U|--user=USERNAME] [-N|--no-pass] [-k|--kerberos] [-A|--authentication-file=FILE] [-S|--signing=on|off|required] [-P|--machine-pass] [-e|--encrypt] [-C|--use-ccache] [--pw-nt-hash] service <password>

Espero que este artículo ahorre tiempo a alguien :)

Leer más »

Versiones de Samba que acepta un servidor

Escrito por Blai el 25.11.20

¿Qué versión de Samba usa un servidor remoto para publicar carpetas compartidas?



Si queremos averiguar qué versiones del protocolo Samba (SMB) acepta un servidor remoto que está publicando una carpeta compartida, podemos usar nmap junto con el plugin "smb-protocols":

nmap -p445 --script smb-protocols 192.168.1.1

Donde 192.168.1.1 es la IP a escanear.

Este comando produce el siguiente output:

nmap -p445 --script smb-protocols 192.168.1.1 Starting Nmap 7.70 ( https://nmap.org ) at 2020-11-25 14:04 CEST Nmap scan report for 192.168.1.1 Host is up (0.00024s latency). PORT STATE SERVICE 445/tcp open microsoft-ds Host script results: | smb-protocols: | dialects: | NT LM 0.12 (SMBv1) [dangerous, but default] | 2.02 | 2.10 | 3.00 | 3.02 |_ 3.11 Nmap done: 1 IP address (1 host up) scanned in 241.03 seconds

Como se puede observar, un escaneo de estas características tarda casi 5 minutos.

En el output arrojado por namp, se observan las versiones de SMB que soporta el otro extremo. En este caso 1.0 y varias versiones de las ramas 2.x y 3.x de Samba.

Leer más »

Windows: ver contraseña de la red WiFi a la que estamos conectados (cmd)

Escrito por Blai el 18.11.20

Ver contraseña de la red WiFi a la que estamos conectados desde el cmd de Windows.



En la entrada anterior os mostré cómo ver el password de la red WiFi a la que estamos conectados desde un Windows. En esta ocasión, os mostraré cómo ver el password usando el cmd de Windows.

Para ello usaremos la utilidad netsh. Sustituir name=MiFibra-D6F0 por el nombre del SSID de la red WiFi.

C:\Users\blai>netsh wlan show profile name=MiFibra-D6F0 key=clear Perfil MiFibra-D6F0 en la interfaz Wi-Fi: ======================================================================= Aplicado: Perfil de todos los usuarios Información del perfil ---------------------- Versión : 1 Tipo : LAN inalámbrica Nombre : MiFibra-D6F0 Opciones de control : Modo de conexión : conectar automáticamente Difusión de red : conectarse solo si esta red está difundiendo Cambio automático: no cambiar a otras redes Selección aleatoria de dirección MAC: deshabilitada Configuración de conectividad ----------------------------- Número de SSID : 1 Nombre de SSID : "MiFibra-D6F0" Tipo de red : Infraestructura Tipo de radio : [ Cualquier tipo de radio ] Extensión de proveedor : no está presente Configuración de seguridad -------------------------- Autenticación : WPA2-Personal Cifrado : CCMP Autenticación : WPA2-Personal Cifrado : GCMP Clave de seguridad : Presente Contenido de la clave : a63456KVrth2dfZ Configuración de costos ------------- Costo : Sin restricciones Congestionado : No A punto de alcanzar el límite de datos: No Límite de datos superado : No Itinerancia : No Origen de costo : Predeterminado

La línea:

Contenido de la clave : a63456KVrth2dfZ

Nos muestra la contraseña de la red en texto plano.

Leer más »

Windows: ver contraseña de la red WiFi a la que estamos conectados (GUI)

Escrito por Blai el 11.11.20

Ver contraseña de la red WiFi a la que estamos conectados desde Windows.



Puede que hayamos ido a un bar que tenga WiFi y nos conectemos automáticamente a su red, pero que estemos allí con un amigo que nos pregunte por el password de la WiFi. Para ver el password de la WiFi a la que estamos conectados, podemos usar una de estras 3 opciones:

- Click derecho con el ratón sobre el icono de WiFi y seleccionar Abrir "Configuración de red e internet".
- Click derecho con el ratón sobre el icono de Windows.
- Click sobre el icono de Windows, escribir "Red" y clicar en "Ver estado de red".
- Ir a Panel de control y luego a "Centro de redes y recursos compartidos"

Una vez se haya abierto la nueva ventana, y dependiendo de la opción que hayamos elegido, deberemos ir a "Centro de redes y recursos compartidos":

En centro de redes y recursos compartidos, debemos hacer click sobre la conexión WiFi:

Hacemos click en Propiedades inalámbricas:

Y por último, nos vamos a la pestaña seguridad y marcamos la opción "Mostrar caracteres":

Leer más »

Backup de la configuración de FortiGate vía CLI

Escrito por Blai el 4.11.20

Hacer un backup de la configuración de un firewall FortiGate de Fortinet vía CLI.



Puede resultarnos interesante realizar backups de la configuración de nuestros firewalls FortiGate vía CLI. Por ejemplo, podemos crear una tarea que realice una conexión SSH cada día a primera hora de la mañana hacia un firewall FortiGate y que lance un backup vía CLI.

Para lanzar un backup de un FortiGate vía CLI, podemos usar la siguiente sintaxis:

execute backup config ftp nombre_de_archivo.cfg 192.168.1.1 usuario password

Donde:

- ftp: protoclo FTP.
- nombre_de_archivo.cfg: nombre del archivo que se escribirá en el servidor de destino.
- usuario: usuario para conectar vía FTP al servidor de destino.
- password: password del usuario.

Si todo va bien, veremos esto en pantalla:

FORTI # execute backup config ftp nombre_de_archivo.cfg 192.168.1.1 usuario password Please wait... Connect to ftp server 192.168.1.1 ... Send config file to ftp server OK.

NOTA: es posible que debamos ejecutar antes el comando "config global".

Si algún parámetro falla, veremos algo parecido a esto:

FORTI # execute backup config ftp nombre_de_archivo.cfg 192.168.1.1 usuario password Please wait... Connect to ftp server 192.168.1.1 ... Send config file to ftp server via vdom root failed. Command fail. Return code 5

Si nos aparece un error en pantalla, asegurarnos de que la VLAN del firewall tiene conectividad con el servidor de destino, que usuario y password son correctos, que la ruta donde dejamos el archivo exista, que el usuario tenga permisos de escritura, etc.


Fuentes:

https://help.fortinet.com/fadc/4-4-0/cli/Content/FortiADC/cli-ref/execute_backup_.htm

Leer más »

Configurar Content Security Policy en NGINX

Escrito por Blai el 28.10.20

Cómo configurar Content-Security-Policy en NGINX..



La "política de Seguridad del Contenido" (del inglés Content Security Policy) es una capa de seguridad que ayuda a prevenir y mitigar algunos ataques como Cross Site Scripting (XSS) usados para robar información de un servidor web o distribuir malware.

La configuración de la Política de Seguridad del Contenido (CSP), consiste en agregar a una página web la cabecera HTTP Content-Security-Policy y darle valores para controlar los recursos que el navegador puede cargar para esa página. Por ejemplo, una página que carga y muestra imágenes podría permitir imágenes desde cualquier lugar, pero puede restringir el envío de un formulario a una ruta específica.

CSP está diseñado para ser completamente retrocompatible; los navegadores que no soportan CSP simplemente lo ignoran. Si el sitio web no ofrece la cabecera CSP, los navegadores igualmente usan la política estándar "mismo-origen".

Para habilitar CSP, necesitas configurar tu servidor web para que devuelva la cabecera HTTP Content-Security-Policy (en ocasiones verás menciones de la cabecera X-Content-Security-Policy, pero se trata de una versión antigua y obsoleta).

Para especificar una política CSP, se puede utilizar la cabecera HTTP Content-Security-Policy de la siguiente manera:

Content-Security-Policy: política; politica2; politica3

La cabecera Content-Security-Policy puede llegar a ser muy larga según si la web tiene muchos orígenes y actualizar esa línea puede llegar a ser tedioso.

En NGINX podemos anidar las variables de esta forma, y tener una URL origen en cada línea, cosa que nos permite una mejor visibilidad del conjunto:

set $SCRIPT "script-src 'self'"; set $SCRIPT "${SCRIPT} https://www.a.com"; # comentario set $SCRIPT "${SCRIPT} https://b.com"; set $STYLE "style-src 'self'"; set $STYLE "${STYLE} https://a.com"; set $IMG "img-src 'self' data:"; set $IMG "${IMG} https://a.com"; set $IMG "${IMG} https://www.b.com"; set $FONT "font-src 'self' data:"; set $FONT "${FONT} https://a.com"; set $DEFAULT "default-src 'self'"; set $CONNECT "connect-src 'self'"; set $CONNECT "${CONNECT} https://www.a.com"; set $CONNECT "${CONNECT} https://www.b.com"; set $FRAME "frame-src 'self'"; set $FRAME "${FRAME} https://a.com"; set $FRAME "${FRAME} https://b.com"; add_header Content-Security-Policy "${SCRIPT}; ${STYLE}; ${IMG}; ${FONT}; ${DEFAULT}; ${CONNECT}; ${FRAME}";

Fuentes:

https://stackoverflow.com/questions/50018881/is-it-ok-to-put-line-breaks-in-add-header-in-nginx...
https://developer.mozilla.org/es/docs/Web/HTTP/CSP

Leer más »

Comprobar si un certificado PFX tiene password

Escrito por Blai el 21.10.20

Comprobar si un certificado en formato PFX tiene un password asociado.



Puede que hace tiempo creáramos un fichero PFX a partir de una clave pública y una clave privda y que ahora no recordemos si le pusimos un password o no al fichero resultante durante su creación. Hoy nos pide alguien que le enviemos el certificado en formato PFX y queremos comprobar antes si el archivo está protegido por un password o no.

Para comprobar si un certificado .pfx tiene password, podemos ejecutar el siguiente comando y pulsar enter cuando el programa nos pida un password (password en blanco):

HOST # openssl pkcs12 -in certificado.pfx -noout Enter Import Password:

Si no aparece nada más en pantalla quiere decir que el archivo .pfx no está protegida con una contraseña.

Por el contrario, si ejecutamos el mismo comando y el resultado es el siguiente:

HOST # openssl pkcs12 -in certificado.pfx -noout Enter Import Password: Mac verify error: invalid password?

Si vemos este error significa que el certificado en formato PFX está protegido con una contraseña. Ahora solo toca encontrarla ;)


Fuentes:

https://stackoverflow.com/questions/4678730/how-to-verify-the-password-of-a-pkcs12-certificate...

Leer más »

Mover ficheros según año de creación

Escrito por Blai el 14.10.20

Cómo mover cada fichero de una carpeta a otra carpeta según el año en que fue creado.



Puede que tengamos un programa que genere ficheros cada día en un directorio determinado de un sistema Linux. Y que haga eso mismo cada día del año. Si es así, al cabo de unos años podemos acabar con miles de ficheros (o incluso cientos de miles de ficheros) en ese directorio, cosa que dificulta acciones tan básicas como listar los ficheros para ver sus nombres.

Si no queremos eliminar los ficheros antiguos, una opción es moverlos hacia directorios que correspondan con su año de creación. De este modo, podemos mover los ficheros de 2015 al directorio 2015, los de 2016 al directorio 2016, etc. es decir, tener la siguiente estructura de directorios:

/directorio /directorio/2015 /directorio/2016 /directorio/2017 /directorio/2018 ...

Una vez visto como quedará la estructura del directorio, podemos proceder a crear un script que lea la fecha de creación de cada fichero del directorio principal y lo mueva a la carpeta correspondiente a su año de creación.

Para leer los ficheros del directorio principal, podemos usar find para poder trabajar con miles de ficheros y luego usar un loop while para mover cada fichero mientras existan ficheros.

Por último, he especificado un año en la variable "year", por si queremos dejar los ficheros de un año concreto en el directorio principal y no moverlos (los ficheros que hayan sido creados en ese año o superior no se moverán):

#!/bin/bash

orig="/origen";
dest="/destino"
year="2020";

find "$orig" -type f -print | while read -r file; do
    file_year=$(date -r "$file" "+%Y");
    if [ "$file_year" -lt "$year" ] ; then
        [ ! -d "$dest/$file_year" ] && mkdir -p "$dest/$file_year";
        mv "$file" "$dest/$file_year";
    fi
done

En cuanto a la línea:

[ ! -d "$dest/$file_year" ] && mkdir -p "$dest/$file_year";

Comprueba si existe el directorio correspondiente al año de creación del fichero que se está procesando y, si el directorio correspondiente al año no existe, lo crea.


Fuentes:

https://unix.stackexchange.com/questions/73268/how-to-move-the-files-based-on-year
https://stackoverflow.com/questions/547719/is-there-a-way-to-make-mv-create-the-directory...

Leer más »

Listar controladores de dominio

Escrito por Blai el 7.10.20

Ver una lista de todos los domains controllers / controladores de dominio de una empresa u organización usando cmd.



Una máquina cualquiera de una organización tiene visibilidad de todos los controladores de dominio de una organización, pues debe poder conectar a cualquiera de ellos para iniciar sesión, recibir GPO, etc.

Para listar los controladores de dominio de una organización podemos usar el comando "nltest":

nltest /dclist:dominio

Un ejemplo de resultado mostrado por este comando es:

C:\Users\usuario>nltest /dclist:dominio.local Obtener lista de los DC del dominio 'dominio.local' a partir de '\\USA-DC01.dominio.local'. DC01.dominio.local [DS] Sitio: Madrid DC02.dominio.local [DS] Sitio: Barcelona DC03.dominio.local [DS] Sitio: Sevilla DC04.dominio.local [DS] Sitio: Cordoba DC05.dominio.local [DS] Sitio: NY DC06.dominio.local [DS] Sitio: LA DC07.dominio.local [DS] Sitio: Washington DC08.dominio.local [DS] Sitio: Boston DC09.dominio.local [DS] Sitio: Miami DC10.dominio.local [DS] Sitio: Denver DC11.dominio.local [PDC] [DS] Sitio: Sacramento DC12.dominio.local [RODC] [DS] Sitio: Seattle El comando se completó correctamente

Como vemos, se muestran los controladores de dominio en una lista.

Leer más »

Conectar vía FTPS desde Linux

Escrito por Blai el 30.9.20

Cómo conectar usando FTPS (FTP implícito sobre TLS) desde Linux.



Para realizar un intercambio de archivos entre un servidor de la empresa A y un servidor de la empresa B, tuve que hacer que la empresa A conectara con un servidor de la empresa B usando FTPS (FTP implícito sobre TLS) desde un servidor Linux.

Existen varias opciones (programas) para realizar una conexión FTPS desde Linux. Yo elegí lftp.

Para conectarnos vía FTPS desde Linux con lftp, el manual de lftp dice que debemos usar esta sintaxis:

HOST # lftp -p puerto -u usuario,password ftps://host

Pero si usamos esta sintaxis sin más, veremos el siguiente error:

HOST # lftp -p puerto -u usuario,password ftps://host lftp usuario@host:~> ls ls: Fatal error: Certificate verification: Not trusted

Como vemos, hay un certificado (TLS) en la conexión, y lftp no nos muestra ninguna opción para aceptarlo o guardarlo. Para eludir este error, podemos usar diferenets métodos.

Por un lado, podemos indicarle a lftp que no compruebe el certificado TLS durante la conexión:

HOST # lftp -p puerto -u usuario,password ftps://host -e "set ssl:verify-certificate false"

De esta forma, podremos conectar con el host sin problemas, pero la conexión no será cifrada punto a punto, es decir, no será segura. Usar esta opción sería lo mismo que hacer una conexión FTP plana.

Para conectar de forma segura con el host de destino, debemos importar el certificado ofrecido por el host remoto en nuestro host. Para hacer esto, debemos ver primero el certificado del host remoto.

Para ver el certificado del host al que nos queremos conectar podemos usar la utilidad openssl:

HOST # openssl s_client -showcerts -connect host:puerto CONNECTED(00000003) depth=0 CN = host, C = ES, ST = Spain, L = Madrid, O = Company, OU = Company, emailAddress = usuario@host.com verify error:num=18:self signed certificate verify return:1 depth=0 CN = host, C = ES, ST = Spain, L = Madrid, O = Company, OU = Company, emailAddress = usuario@host.com verify return:1 --- Certificate chain 0 s:/CN=host/C=ES/ST=Spain/L=Madrid/O=Company/OU=Company/emailAddress=usuario@host.com i:/CN=host/C=ES/ST=Spain/L=Madrid/O=Company/OU=Company/emailAddress=usuario@host.com -----BEGIN CERTIFICATE----- MIIDzDCCArSgAwIBAgIEF59rnf gUURFEfe7GDtunFR67HFd3GHJ45regTYu7jh8 OTQuMTQyLjIwMS4yNTQxCzAJBgNVBAYTAkVTMQ4wDAYDVQQIDAVTcGFpbjEPMA0G A1UEBwwGTWFkcmlkMRYwFAYDVQQKDA1BbWFkZXVzIFNwYWluMRYwFAYDVQQLDA1B bWFkZXVzIFNwYWluMS4wLAYJKoZIhvcNAQkBFh9hbHZhcm8uZ2FyY2lhYW5ndWxv QGFtYWRldXMuY29tMB4XDTIwMTIwMTE2MzQ0OVoXDTIxMTIwMTE2MzQ0OVowgacx 59mnermTxTujODDTHBdffs9342rTBHfghfg66GVdfsdfg)g534GDFGsfsDTGSFsf U3BhaW4xDzANBgNVBAcMBk1hZHJpZDEWMBQGA1UECgwNQW1hZGV1cyBTcGFpbjEW MBQGA1UECwwNQW1hZGV1cyBTcGFpbjEuMCwGCSqGSIb3DQEJARYfYWx2YXJvLmdh cmNpYWFuZ3Vsb0BhbWFkZXVzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL++EGGUDSIWgJUkvgFXk1Zjo2RXrmToHF6zmBrkl052jFJQXj0sPSuX Lt+CJu8whg2xnnCNb6BwTCB7J+a9hDJJQR9m7uanzLn/1RlEcrcm0AyHA0tZ8UKw H589/QlWlfVwJLFqLMpYUowECh15jCh69TzHuSW6/mPc5Eo008LS20Cx28YKtfV5 g+qCv2BizkbEEiSCDe498H0+n/Kv1JeKFbJESJDaMNhuKxzQbfirNysgxTuf0rOR hhFTSLLsIa5NZMFXWESMpukU/0vYez0Mf3psOhNGEVKyQo1mbKT0eCDpLsZaPRzX IG/m1duwIyTMjN4c+hiXYlda1t7JLUsCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEA l4vJUVhgOPzqgr516r5QDynF8o9I8xgJZj5ZA/Jma8lUoYO3+g5lTv8NM2JqeRdP fKhdUK3t7MofPh3YKHg/NubUz6vtJi6vpzfqkAjUY3z7z2RzITbmAtTqgnqWPzK9 pfdGsT99acNeUoYzAnCRN46sftQ9dS4mCUZdIP+vUObXBGJhxB6LOxwYs1EeGEPa 8p6C/rErdHNVu7nO+CEOkXiN2QnBYacYdV2q90oS/eZ5XEVCet4mjMltcKwX1mCL or8fnfvsdgDH$/rwegdrh/$GDHFGJSG575757RHRTRGdfgdfg4d4h3f33hf33h4h DaszVAQqxS687mfneI5vgQw== -----END CERTIFICATE----- --- Server certificate subject=/CN=host/C=ES/ST=Spain/L=Madrid/O=Company/OU=Company/emailAddress=usuario@host.com issuer=/CN=host/C=ES/ST=Spain/L=Madrid/O=Company/OU=Company/emailAddress=usuario@host.com --- No client certificate CA names sent --- SSL handshake has read 1635 bytes and written 387 bytes ...

Cogemos el certificado, es decir, lo que hay entre BEGIN CERTIFICATE y END CERTIFICATE (ambas líneas incluidas) y lo metemos en un archivo .crt. A continuación, editamos el fichero /etc/lftp.conf, última línea, y lo enlazamos en el apartado set ssl:ca-file:

## SSL default settings #set ssl:ca-file "/etc/ssl/ca-bundle.pem" set ssl:ca-file "/ruta/hacia/el/archivo.crt"

Una vez hecho esto, ya podremos conectar con el host usando la encriptación punto a punto con:

HOST # lftp -p puerto -u usuario,password ftps://host

Leer más »

Qué es y cómo apuntarse a Windows Insider

Escrito por Blai el 23.9.20

¿Qué es Windows Insider? ¿Cómo enrolar un ordenador al programa?



Windows Insider es una iniciativa de Microsoft destinada a los usuarios de Windows que permite a quien esté apuntado en ella probar versiones preliminares (o nuevas características) del sistema operativo Windows antes de que estas sean lanzadas al gran público. A cambio, Microsoft pide a los Insiders sus opiniones respecto a las nuevas funcionalidades de cara a mejorar el producto.

Este programa fue anunciado el 30 de septiembre de 2014 junto con Windows 10. A finales de ese mismo año, alrededor de 1,5 millones de personas ya se habían instalado la primera preview de la siguiente build de Windows 10 y ya estaban flighting.

Flighting

Flighting es un término inventado por el departamento de marketing de Microsoft usado para denominar el proceso de ejecutar las compilaciones de Windows 10 Insider Preview. Este proceso incluye:

• Configurar nuestro dispositivo en uno de los canales de Windows Insider.
• Instalar las actualizaciones preview (de vista previa) de ese canal.
• Ejecutar y probar esas compilaciones previas.

Canales

Microsoft divide el programa Insider en 5 canales, donde 2 de ellos son sólo para uso interno, es decir, solo visibles por sus empleados.

El primer canal se llama Canary, y es donde los desarrolladores de Microsoft proponen y prueban por primera vez nuevas funciones para Windows.

Una vez creada una nuva función, esta llega al canal Dev y se libera al público para que de su feedback.

Una vez testeadas en el canal Dev, las actualizaciones vuelven a un canal interno, el canal Microsoft, donde además de los desarrolladores, el resto de empleados de Microsoft pueden también probarlas.

Una vez pulidas por los programadores tras el feedback recibido desde Dev, las actualizaciones pasan del canal Microsoft al canal Beta, volviendo a ser públicas.

En última instancia, las actualizaciones llegan al canal "Release Preview", donde los Insiders reciben las próximas actualizaciones acumulativas unos días antes de su lanzamiento oficial, para acabar de pulir incompatibilidades o problemas derivados de hardware poco común.

No hace falta decir que al canal Dev llegan muchas más actualizaciones que al canal Beta, pero cuando las actualizaciones llegan al canal Beta, estas ya han sido pulidas y funcionan mejor que cuando llegaron a Dev. Por último, las Release Preview apenas recibirán builds, aunque días antes de que se lance una gran actualización se envían allí para que puedan ser probadas anticipadamente por los Insiders.

Ventajas y desventajas

La ventaja principal de este programa es la posibilidad de ser una de las primeras personas en probar cada nueva función de Windows. Otra ventaja de Insider es que siendo miembro del programa tienes Windows gratis, pues una vez que inscritos en el programa podemos descargarnos la ISO de la última build disponible de Windows dntro del programa.

En el otro lado se encuentra la inestabilidad que puede padecer un PC al usar versiones no finales de un producto, con culegues ocasionales y problemas varios.

Cómo apuntarse a Windows Insider

Para apuntarse a Windows Insider, hace falta un ordenador con Windows 10.

Ir a Inicio, botón derecho y clic en configuración:

Una vez allí, ir a Actualización y seguridad y luego a Programa Windows Insider:

A continuación, clicar el botón "Comenzar" y acto seguido, vincular una cuenta:

Nos registramos en el programa Windows Insider y aceptamos las condiciones de uso:

Y por último, elegimos el canal que queramos probar.

A partir de este momento, ya recibiremos las actualizaciones lanzadas desde el canal seleccionado.


Fuentes:

https://insider.windows.com/es-es/

Leer más »

Rutas estáticas persistentes en SLES

Escrito por Blai el 16.9.20

Cómo crear (y eliminar) rutas estáticas persistentes en un SUSE Linux Enterprise Server.



Si añadimos una ruta estática a un SUSE Linux Enterprise Server con el comando ip route add y reiniciamos la máquina después, comprobaremos que las rutas añadidas de esta manera se pierden tras un reinicio, es decir, son temporales.

Para añadir rutas estáticas persistentes a un SLES, es decir, rutas que se mantengan en el sistema operativo tras reiniciar la máquina, deberemos editar dos archivos: /etc/sysconfig/network/routes y /etc/sysconfig/network/ifroute-* y añadirlas en uno de ellos.

Archivos

La tabla de rutas persistentes de un SUSE Linux Enterprise Server se encuentra en el archivo:

/etc/sysconfig/network/routes

Adicionalmente, se pueden añadir rutas a un adpatador específico editando un archivo del tipo:

/etc/sysconfig/network/ifroute-*

Es decir, si tenemos un adaptador llamado eth0 configurado en el archivo ifcfg-eth0, podemos crear rutas estáticas que afecten solamente a este adaptador editando el archivo:

/etc/sysconfig/network/ifroute-eth0

Añadir ruta estática

Las entradas en los archivos de configuración de enrutamiento pueden seguir uno de estos 3 patrones:

DESTINO GATEWAY MÁSCARA INTERFAZ
DESTINO GATEWAY PREFIJO INTERFAZ
DESTINO/PREFIJO GATEWAY INTERFAZ

Para omitir el GATEWAY, MÁSCARA o PREFIJO escribir - (guión).

El destino siempre se escribe en la primera columna. Este puede ser tanto un host como una red, así como un FQDN que la máquina sepa resolver (por ejemplo, host.dominio.com).

La segunda columna contiene el gateway (desde donde se enviará el tráfico al destino).
La palabra clave default, por su parte, indica que la ruta usa la puerta de enlace predeterminada.

La tercera columna está obsoleta; solía contener la máscara de red IPv4 del destino, del tipo máscara (por ejemplo 255.255.255.0) o prefijo (/24). Hoy en día se usa una combinación de host o red con su prefijo directamente en la primera columna. Por ejemplo, 192.168.0.0/16 para IPv4 o fc00::/ 7 para IPv6.

Por último, la cuarta columna nos indica la interfaz a usar.

Mostrar rutas

Hay dos formas de visualizar las rutas estáticas persistentes de un sistema: por comando o por archivo.

Podemos usar el comando ip route show para ver las rutas estáticas configuradas en un sistema:

HOST# ip route show default via 192.168.4.1 dev eth0 192.168.4.0/24 dev eth0 proto kernel scope link src 192.168.4.2 192.168.7.0/24 dev eth1 proto kernel scope link src 192.168.7.2

(Recordar que el comando ip route sustituye el antiguo comando netstat -nr).

De otro modo, podemos mirar el contenido de uno de los archivos mencionados anteriormente:

HOST# cat /etc/sysconfig/network/routes 192.168.4.0 192.168.4.1 255.255.255.0 eth0 192.168.7.0 192.168.7.1 255.255.255.0 eth1

Sea cual sea el método elegido, deberíamos ver las mismas rutas.

Eliminar ruta estática

Para eliminar alguna ruta, basta simplemente con borrarla del archivo en cuestión.


Fuentes:

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-network.html#sec-network-man...
https://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch14s05.html

Leer más »

Especificar IP de origen desde proxy NGINX

Escrito por Blai el 9.9.20

Cómo enviar peticiones desde una IP de origen concreta en un proxy inverso NGINX.



Puede que tengamos un servidor web que solo acepte conexiones de un determinado rango IP y que tengamos un NGINX por delante actuando de reverse proxy que no disponga de una IP de ese rango o que sí disponga de ella, pero no la use a la hora de enviar tráfico a dicho servidor, por lo que los paquetes no lleguen desde el NGINX al servidor final.

Para solucionar este problema, podemos asignar una IP secundaria a nuestro NGINX y especificar que para ese servidor, usaremos esa IP secundaria como origen a la hora de enviarle tráfico.

Para especificar desde qué IP se envía tráfico hacia un servidor web final, podemos usar la directiva proxy_bind antes de proxy_pass en el bloque location dentro del bloque server de un dominio:

server { server_name dominio1.com; ... location /app1/ { proxy_bind 127.0.0.1; proxy_pass http://example.com/app1/; } } server { server_name dominio2.com; ... location /app2/ { proxy_bind 127.0.0.2; proxy_pass http://example.com/app2/; } }

La dirección IP también se puede especificar con una variable, p.e $server_addr.

Primero declaramos la variable y su valor:

set $server_addr "127.0.0.1";

A partir de aquí, ya la podemos usar dentro de la directiva proxy_bind de cuantos dominios queramos:

server { server_name dominio3.com; ... location /app3/ { proxy_bind $server_addr; proxy_pass http://example.com/app3/; } } server { server_name dominio4.com; ... location /app4/ { proxy_bind $server_addr; proxy_pass http://example.com/app4/; } } ...

De esta forma, podemos usar dicha variable en varios dominios y si algún día cambiamos la IP desde la que se origina el tráfico, no hará falta ir línea por línea cambiando su valor sino que podremos cambiarla una sola vez en la declaración de la variable.


Fuentes:

https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

Leer más »

Acceder a Google Drive desde el escritorio

Escrito por Blai el 2.9.20

Cómo acceder a Google Drive desde nuestro explorador de Windows, Mac o Linux.



Google Drive es un servicio de alojamiento de archivos en la nube creado por Google en 2012. Este servicio nos permite disponer de hasta 15 GB por cuenta para guardar fotos, documentos, copias de seguridad, etc. alojados en servidores de Google sin gasto alguno.

Para disfrutar de Google Drive, deberemos usar una cuenta de gmail o vincular una cuenta de correo electrónico existente con Google. Una vez hecho esto, ya podremos usar Google Drive desde el navegador web y/o desde la aplicación de escritorio.

Para acceder a Google Drive desde el escritorio de nuestro ordenador como si de una carpeta más del sistema se tratara, deberemos descargar "Backp and Sync" (Copia de seguridad y sincronización) desde:

https://www.google.com/intl/es-419_ALL/drive/download/backup-and-sync/

Al inicio de la instalación, el programa nos pide iniciar sesión a nuestra cuenta Google:



Luego debemos elegir si queremos maneter sincronizadas las carpetas de fotos, vídeos y documentos de nuestro sistema operativo o si queremos mantener Google Drive como una carpeta independiente:



A continuación, y muy importante, debemos marcar "sincronizar mi unidad con este ordenador". Si no lo marcamos, no veremos los cambios que hagamos en nuestro PC en el Drive ni viceversa.



Una vez hecho esto, ya podremos acceder a nuestros archivos contenidos en el Drive como si de una carpeta más del ordenador se tratase:



Solo recordar que el límite de espacio del plan gratuito para este servicio es 15 GB.

Leer más »

Incrementar tamaño de / en EC2 Linux

Escrito por Blai el 26.8.20

Cómo incrementar el tamaño de la partición raíz ( / ) de un EC2 Linux en Amazon Web Services.



Si tenemos una instancia Linux en AWS, puede pasarnos que nos quedemos sin espacio en el disco principal de la máquina y no tengamos más remedio que ampliar el número de GB del disco.

Antes de ampliar la partición raíz, debemos averiguar en qué disco está situada la partición:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 99G 60G 35G 64% / tmpfs 799M 0 799M 0% /run/user/1000

Listamos los discos del sistema con el comando lsblk y encontramos el disco xvda:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 100G 0 disk └─xvda1 202:1 0 100G 0 part /

Ahora ampliamos el espacio del disco xvda desde la consola de AWS.

Volvemos a lanzar el comando lsblk y vemos como xvda ha subido de tamaño:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 250G 0 disk └─xvda1 202:1 0 100G 0 part /

Llegados a este punto, tenemos un disco ampliado, pero la partición raíz sigue igual:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 99G 60G 35G 64% / tmpfs 799M 0 799M 0% /run/user/1000

Ampliamos la partición /dev/xvda1:

ip-10-250-4-103:/home/ec2-user # sudo growpart /dev/xvda 1 CHANGED: partition=1 start=2048 old: size=209713119 end=209715167 new: size=524285919,end=524287967

Comprobamos que haya cogido el nuevo espacio asignado:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 250G 0 disk └─xvda1 202:1 0 250G 0 part /

EXT4

Si el disco está particionado con EXT4, usamos resize2fs para acabar de ampliar la partición raíz:

ip-10-250-4-103:/home/ec2-user # sudo resize2fs /dev/xvda1 resize2fs 1.42.11 (09-Jul-2014) Filesystem at /dev/xvda1 is mounted on /; on-line resizing required old_desc_blocks = 7, new_desc_blocks = 16 The filesystem on /dev/xvda1 is now 65535739 blocks long.

Vemos como la partición raíz ya ve el nuevo espacio en disco:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 246G 60G 177G 26% / tmpfs 799M 0 799M 0% /run/user/1000

XFS

Si ampliamos una partición no EXT4 usando el comando resize2fs veremos el siguiente error en pantalla:

ip-10-250-4-94:/home/ec2-user # sudo resize2fs /dev/xvda2 resize2fs 1.43.8 (1-Jan-2018) resize2fs: Bad magic number in super-block while trying to open /dev/xvda2 Couldn't find valid filesystem superblock.

Buscamos el tipo de partición del sistema operativo:

ip-10-250-4-94:/home/ec2-user # df -Th Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 3.9G 0 3.9G 0% /dev tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs tmpfs 3.9G 375M 3.6G 10% /run tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda2 xfs 100G 58G 42G 58% / /dev/xvda1 xfs 297M 90M 208M 31% /boot tmpfs tmpfs 797M 0 797M 0% /run/user/1000

Vemos que es XFS. Usamos xfs_growfs para ampliar nuestra partición raíz:

ip-10-250-4-94:/home/ec2-user # sudo xfs_growfs -d / meta-data=/dev/xvda2 isize=512 agcount=42, agsize=636096 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0 spinodes=0 rmapbt=0 = reflink=0 data = bsize=4096 blocks=26137339, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 26137339 to 65458939

Ahora ya vemos el nuevo espacio en la partición raíz:

ip-10-250-4-94:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 375M 3.6G 10% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda2 250G 58G 192G 24% / /dev/xvda1 297M 90M 208M 31% /boot tmpfs 797M 0 797M 0% /run/user/1000

Fuentes:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

Leer más »