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, debemos situarnos en la home de root:

HOST# cd /root/.ssh

Y buscar 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 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
0

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 casi todos los 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 se comunican con un clúster GPFS puede que dejen de funcionar o funcionen erróneamente después de un cambio de versión de GPFS.

Del mismo modo, si queremos actualizar un programa que depende de GPFS, deberemos saber si la nueva versión de dicho programa es compatible o no con la versión de GPFS desplegada en el sistema antes de proceder con su instalació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.17 ". 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...
0

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

miércoles, 7 de agosto de 2019

Cómo activar / desactivar módulos en un SLES



Cómo registrar un módulo vía línea de comandos en SUSE Linux Enterpirse Server 15.



Al tratar de instalar un Service Pack en un SUSE Linux Enterprise Server me encontré con este error:

HOST# zypper migration ... Can't get available migrations from server: SUSE::Connect::ApiError: The requested products 'Desktop Applications Module 15 x86_64, Development Tools Module 15 x86_64, Legacy Module 15 x86_64, Public Cloud Module 15 x86_64, Web and Scripting Module 15 x86_64' are not activated on the system. '/usr/lib/zypper/commands/zypper-migration' exited with status 1

Para poder continuar con la instalación, tenía que activar manualmente cada uno de los módulos.

Para ver cómo activarlos, lo mejor es listar primero los módulos instalados en el sistema:

HOST# SUSEConnect --list-extensions AVAILABLE EXTENSIONS AND MODULES Basesystem Module 15 x86_64 (Activated) Deactivate with: SUSEConnect -d -p sle-module-basesystem/15/x86_64 Containers Module 15 x86_64 (Activated) Deactivate with: SUSEConnect -d -p sle-module-containers/15/x86_64 Desktop Applications Module 15 x86_64 Activate with: SUSEConnect -p sle-module-desktop-applications/15/x86_64 Development Tools Module 15 x86_64 Activate with: SUSEConnect -p sle-module-development-tools/15/x86_64 SUSE Cloud Application Platform Tools Module 15 x86_64 (Activated) Deactivate with: SUSEConnect -d -p sle-module-cap-tools/15/x86_64 SUSE Package Hub 15 x86_64 Activate with: SUSEConnect -p PackageHub/15/x86_64 Server Applications Module 15 x86_64 (Activated) Deactivate with: SUSEConnect -d -p sle-module-server-applications/15/x86_64 Legacy Module 15 x86_64 Activate with: SUSEConnect -p sle-module-legacy/15/x86_64 Public Cloud Module 15 x86_64 Activate with: SUSEConnect -p sle-module-public-cloud/15/x86_64 SUSE Linux Enterprise High Availability Extension 15 x86_64 Activate with: SUSEConnect -p sle-ha/15/x86_64 Web and Scripting Module 15 x86_64 Activate with: SUSEConnect -p sle-module-web-scripting/15/x86_64 REMARKS (Not available) The module/extension is not enabled on your RMT/SMT (Activated)     The module/extension is activated on your system MORE INFORMATION You can find more information about available modules here: https://www.suse.com/products/server/features/modules.html

Llegados a este punto, sólo quedaba ir activando los diferentes módulos no activados con el comando proporcionado en la lista anterior, valiéndome de la utilidad propietaria de SUSE SUSEConnect:

HOST# SUSEConnect -p sle-module-web-scripting/15/x86_64 Registering system to registration proxy https://smt-ec2.susecloud.net Updating system details on https://smt-ec2.susecloud.net ... Activating sle-module-web-scripting 15 x86_64 ... -> Adding service to system ... -> Installing release package ... Successfully registered system

Una vez activados todos los módulos, ya pude efectuar la instalación del Service Pack sin problemas.

Si lo que queremos es desactivar un módulo, debemos seguir las instruciones proporcionadas en la lista de extensiones, y usar la opción -d junto al nombre de módulo, tal y como se indica.


Fuentes:

https://www.suse.com/support/kb/doc/?id=7018790
https://www.suse.com/products/server/features/modules.html
0

miércoles, 31 de julio de 2019

WARNING: UNPROTECTED PRIVATE KEY FILE!



Cómo solucionar el error "WARNING: UNPROTECTED PRIVATE KEY FILE!" al conectar por SSH con una clave privada a una instancia Linux alojada en Amazon Web Services (AWS) u otro entorno.



Puede pasarnos que al tratar de conectar con una instancia Linux en AWS vía SSH nos aparezca el siguiente mensaje de advertencia en el sistema operativo cliente y no podamos conectarnos:

HOST# ssh -i "key.pem" ec2-user@192.168.1.1 The authenticity of host '192.168.1.1' can't be established. ECDSA key fingerprint is SHA256:fIXn6S2e9d1w3S4LcVXkqyFOWw03M+PrRRq9OqM25BZ. Are you sure you want to continue connecting (yes/no)? y Please type 'yes' or 'no': yes Warning: Permanently added '192.168.1.1' (ECDSA) to the list of known hosts. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions for 'key.pem' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Load key "key.pem": bad permissions ec2-user@192.168.1.1: Permission denied (publickey).

El problema reside en los permisos del archivo .pem que contiene la clave privada. El sistema no nos deja usarlo si los permisos de lectura / escritura del archivo son demasiado laxos. Con esto, se pretende evitar que otros usuarios puedan copiar una clave privada y usarla sin consentimiento de su propietario.

Para poder usar la clave privada en una conexión SSH, deberemos primero fijar permisos de solo lectura al archivo, y fijarlos solo para el usuario o usuarios que tengan que usar el archivo.


En Linux



En Linux, deberemos darle permisos 400 o 600 al archivo .pem para poder usarlo:

HOST# chmod 400 key.pem

Alternativamente, si necesitamos que un grupo de usuarios pueda usar la clave privada para iniciar conexiones hacia la instancia, podemos darle permisos "0440" al archivo .pem para que cualquier usuario perteneciente al grupo propietario pueda usar la clave privada.


En Windows



Si estamos usando OpenSSH en Windows, nos podemos encontrar con el problema inicial, pero al ser Windows, no podremos realizar chmod al archivo. Para modificar los permisos del archivo .pem clicamos el botón derecho del mouse sobre el archivo > Propiedades y otorgamos solamente permisos de Lectura al usuario que va a usar el archivo .pem:



A partir de este momento, independientemente del sistema operativo desde el que trabajemos, ya podremos realizar la conexión hacia la instancia EC2 de turno sin problemas.


Fuentes:

https://stackoverflow.com/questions/9270734/ssh-permissions-are-too-open-error
0

miércoles, 24 de julio de 2019

Ruin My Search History



Análisis de esta utilidad creada para "trollear" a Google y hacerle más difícil nuestro perfilado.



Google usa nuestro historial de búsquedas para completar el perfil de cada uno de nosotros. Este perfil incluye nuestro nombre, número de teléfono, dirección de e-mail, personas con las que nos intercambiamos correos, personas a las que llamamos, sitios que visitamos, cosas que buscamos y un largo etcétera. Recordemos que Google es el buscador más usado en internet, gmail es el servicio de correo más usado y Android es un sistema operativo de Google.


Ruin My Search History



"Ruin My Search History" es una utilidad online de proprivacy.com cuya finalidad es trollear a Google generando búsquedas aleatorias bajo nuestro usuario para alimentar así a Google con información no generada por nosotros. Al generar búsquedas aleatorias, evitaremos que Google construya un perfil real sobre nuestra persona (aunque quizás sea demasiado tarde....).

Para usarlo, simplemente debemos acceder a https://proprivacy.com/ruinmysearchhistory y clicar el botón que dice "Ruin My Search History". Se abrirá una nueva pestaña en nuestro navegador y cada pocos segundos se irá refrescando con una nueva búsqueda aleatoria (en inglés).

Ejemplo de búsqueda "troll" generada automáticamente por Ruin My Search History:



Tras realizar 50 búsquedas, veremos un resumen de las consultas:




¿Perfilado?



Empresas como Google, Facebook y Amazon almacenan datos de sus usuarios para mostrarles publicidad dirigida. Aunque en un primer momento parezca atractivo para el usuario, estas compañías almacenan absolutamente todo la información posible sobre cada uno de sus usuarios con la esperanza de poder usar esos datos para en un futuro obtener beneficios extra.

Incluso si vemos la publicidad dirigida como una ventaja para encontrar productos que nos son interesantes, deberíamos sentirnos un poco nerviosos, como mínimo, con el hecho de que varias empresas tengan acceso a todos nuestros datos, gustos y fotografías, entre otros.


Conclusión



Para evitar un perfilado exhaustivo sobre nosotros por parte de estas empresas, lo ideal es, obviamente, dejar de usar sus productos. Si esto no es posible, siempre podemos usar herramientas como "Ruin My Search History" para trampear la información que almacenan / analizan sobre nosotros.
0

miércoles, 17 de julio de 2019

Cómo servir PHP con NGINX



Cómo servir archivos .php usando NGINX como web server.



Para usar PHP en NGINX, primero hay que instalar NGINX en el servidor. Lo podemos instalar de la siguiente manera (sustituir zypper por el gestor de paquetes que use el sistema operativo del servidor):

HOST# zypper install nginx

Con NGINX instalado, el siguiente paso es instalar PHP:

HOST# zypper install php7

Nos aseguramos que tengamos instalado el módulo php-fpm. Podemos instalarlo con:

HOST# zypper install php7-fpm

En la ruta /etc/php7/fpm encontraremos un archivo llamado php-fpm.conf.default. Debemos copiarlo hacia un archivo .conf para que php-fpm lo lea y se inicie correctamente. Si no existe el archivo .conf, al iniciar php-fpm veremos errores del tipo "No existe el archivo php-fpm.conf...".

Copiamos el archivo default hacia un archivo con extensión .conf:

HOST# cp php-fpm.conf.default php-fpm.conf

De la misma manera, nos dirigimos hacia la subcarpeta php-fpm.d (/etc/php7/fpm/php-fpm.d) y copiamos el archivo www.conf.default a www.conf:

HOST# cp www.conf.default www.conf

Ahora ya podemos iniciar el servicio php-fpm:

HOST# service php-fpm restart

Es importante prevenir que NGINX pase peticiones al «backend» de PHP-FPM. Esto se puede conseguir estableciendo la directiva cgi.fix_pathinfo a 0 dentro del fichero php.ini.

Primero buscamos la ruta del fichero php.ini en nuestra distribución Linux y versión de php instalada:

HOST# find / -name php.ini /etc/php7/cli/php.ini

Editamos php.ini:

HOST# vi /usr/local/php/php.ini

Localizamos la opción cgi.fix_pathinfo= y la modificamos como sigue:

cgi.fix_pathinfo=0

Una vez hecho esto, toca configurar NGINX para que pueda procesar aplicaciones PHP:

HOST# vi /etc/nginx/nginx.conf

Primero modificamos el bloque de ubicaciones iniciales predeterminado en el archivo nginx.conf para que NGINX intente servir un index.php en caso de que este exista:

location / {         root html;         index index.php index.html index.htm; }

El siguiente paso es asegurarse de que los ficheros .php se pasan al «backend» de PHP-FPM. Descomentar el bloque de ubicaciones predeterminado de PHP y cambiar la siguiente línea:

fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;

por

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

El bloque php debe quedar de este modo:

location ~* \.php$ {         fastcgi_index index.php;         fastcgi_pass 127.0.0.1:9000;         include fastcgi_params;         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;         fastcgi_param SCRIPT_NAME $fastcgi_script_name; }

Después de hacer estos cambios, reiniciamos NGINX:

HOST# service nginx restart

Creamos un fichero .php de prueba que contenga <?php phpinfo(); ?> en /srv/www/htdocs/ y navegamos a http://localhost/fichero.php. En este momento, phpinfo() debería mostrarse.

Si hemos seguido los pasos anteriores tendremos un servidor web NGINX funcionando, con soporte para PHP como módulo SAPI.


Fuentes:

https://www.php.net/manual/es/install.unix.nginx.php
https://stackoverflow.com/questions/17808787/file-not-found-when-running-php-with-nginx
https://security.stackexchange.com/questions/177354/turned-on-cgi-fix-pathinfo-still-dangerous...
0

miércoles, 10 de julio de 2019

Cómo actualizar un Debian



Cómo actualizar un sistema operativo GNU/Linux Debian para aplicar parches a sus paquetes y mantener el sistema al día en cuestión de seguridad. Actualización desatendida en Debian.



Actualizar un sistema operativo hace que se apliquen correcciones a problemas de seguridad, se mejora la compatibilidad con el nuevo hardware, se mejora la estabilidad y, en ocasiones, se añaden algunas funciones y características nuevas a los programas instalados.


apt



APT (siglas de Advanced Package Tool) es el programa de gestión de paquetes del sistema operativo Debian. Proporciona herramientas de línea de comandos para buscar y administrar paquetes y para consultar información sobre ellos.

Antiguamente, se usaba el comando apt-get (apt-get update, apt-get upgrade, etc.) para actualizar un sistema operativo Debian. A partir de Debian Jessie, se unificaron apt-get y apt-cache en apt, de modo que lo que antes se ejecutaba como apt-get update, apt-get install o apt-get remove ahora también se puede llamar a través de apt como apt update, apt install, apt remove,etc.

Algunos comandos comunes de apt relacionados con la actualización del sistema operativo son:

• Actualizar la lista de paquetes conocidos por un sistema:

HOST# apt update

Este comando le presenta a nuestro sistema operativo las últimas versiones disponibles de los paquetes instalados en él. Para ello, se conecta a los repositorios configurados en el sistema y compara versiones.

• Enumerar todos los paquetes para los cuales hay disponibles versiones más nuevas.

HOST# apt list --upgradable

Después de realizar apt update, con apt list --upgradable veremos qué paquetes deben ser actualizados.

• Actualizar todos los paquetes de un sistema (sin instalar paquetes adicionales o eliminar paquetes):

HOST# apt upgrade

• Actualizar todos los paquetes de un sistema y, si es necesario, instalar/desinstalar dependencias:

HOST# apt full-upgrade

apt full-upgrade es un alias que apunta a apt-get dist-upgrade.

Recordar que se debe iniciar sesión como root o usar sudo para ejecutar cualquier comando que modifique los paquetes de un sistema.


aptitude



A parte de apt, disponemos de la herramienta aptitude para la administración de parches en Debian. aptitude es un administrador de paquetes para los sistemas Debian GNU / Linux que proporciona una interfaz basada en texto que utiliza la biblioteca curses. Las acciones se pueden realizar desde una interfaz visual o desde la línea de comandos.


synaptic



Debemos nombrar también synaptic. synaptic es un gestor de paquetes gráfico. Permite instalar, actualizar y eliminar paquetes de software de una manera fácil para el usuario. Junto con la mayoría de las funciones ofrecidas por aptitude, también tiene una función para editar la lista de repositorios usados ​​y permite explorar toda la documentación disponible de un paquete.


Conclusión



Si queremos mantener nuestros servidores Debian actualizados, debemos ejecutar periódicamente el siguiente "script" en la línea de comandos:

HOST# apt update && apt upgrade -y

Estos comandos lo que hacen es descargarse una lista con la última versión disponible de cada paquete instalado en el sistema, y si la descarga acaba correctamente, llevar a cabo una actualización de todos los paquetes del sistema operativo de forma desatendida (opción -y).


Fuentes:

https://www.debian.org/doc/manuals/debian-faq/ch-pkgtools.en.html#s-apt-get
https://www.debian.org/doc/manuals/debian-faq/ch-uptodate.en.html
https://askubuntu.com/questions/605719/the-difference-between-the-different-apt-upgrade...
https://askubuntu.com/questions/770135/apt-full-upgrade-versus-apt-get-dist-upgrade
0

miércoles, 3 de julio de 2019

Cómo descargar un vídeo de arte.tv



Descubrí la web arte.tv a raíz del vídeo sobre "los hackers rusos" que comenté en otra entrada:



Lo que me llamó más la atención del vídeo no fue su contenido, que también, sino que el vídeo tuviera fecha de caducidad; solo estaba disponible del 07/05/2019 al 06/07/2019.


¿Qué ocurre si quiero mirar el vídeo más adelante?



Para poder disponer de él en cualquier momento, me puse a investigar cómo guardarlo.

Si miramos el código fuente de la página, veremos que hay un iframe apuntando a una URL:

..
<div class="video-embed">
<iframe allowfullscreen="true" style="transition-duration:0;transition-property:no;margin:0 auto;position:relative;display:block;background-color:#000000;" scrolling="no" src="https://www.arte.tv/player/v3/index.php?json_url=https%3A%2F%2Fapi.arte.tv%2Fapi%2Fplayer%2Fv1%2Fconfig%2Fes%2F080159-000-A%3Fautostart%3D1%26lifeCycle%3D1&amp;lang=es_ES" width="100%" height="100%" frameborder="0"></iframe>
</div>
...


Fijándonos en el código, vemos que la URL del vídeo es:

https%3A%2F%2Fapi.arte.tv%2Fapi%2Fplayer%2Fv1%2Fconfig%2Fes%2F080159-000-A%3Fautostart%3D1%26lifeCycle%3D1&lang=es_ES

Si traducimos los carácteres hexadeciamles a una URL legible obtenemos:

https://api.arte.tv/api/player/v1/config/es/080159-000-A?autostart=1&lifeCycle=1&lang=es_ES

Si accedemos con el navegador a la URL, veremos las URLs finales de varios vídeos en un archivo JSON:



Seleccionamos la URL del vídeo en español, la abrimos desde cualquier navegador y descargamos el archivo .mp4 a nuestro PC desde el menú contextual:



Hecho esto, ya tenemos el archivo de vídeo en nuestro poder para re-mirarlo cuando queramos :)
0

miércoles, 26 de junio de 2019

Documental: Los nuevos mercenarios rusos



Navegando por internet, me crucé con un documental de arte.tv titulado Los nuevos mercenarios rusos, el cual habla sobre "los hackers rusos", es decir, gente que vive en Rusia y accede a sistemas informáticos ajenos para obtener información confidencial.

El documental empieza con uno de los periodistas yendo a una escuela francesa donde se enseña a niños de 4º de primaria (9 años) a conectarse a máquinas por SSH y a programar en Arduino. Pretende hacernos ver que las generaciones que vienen son nativas digitales y que ya mismo, los niños de cualquier país empiezan su adiestramiento en irrupción a sistemas ajenos desde bien pequeños.


Momento estelar del documental. Niño explicándole al periodista lo que es una shell. Este niño llegará lejos.

De niños pasan a jóvenes. Uno de los periodistas va a casa de un hacker francés el cual asegura que el FBI, así como agencias varias de otros países, trató de reclutarlo.


El chaval asegura que el FBI (agencia gubernamental norteamericana) le ha llegado a ofrecer trabajo (a él, un joven francés) en asuntos de ciberseguridad. No se por qué, no lo acabo de ver claro.

Este individuo, además, dice haber hackeado a un hacker ruso. Y esto nos sirve como punto de entrada a la comunidad hacker rusa. En los siguientes minutos, se muestra el corazón del movimiento hacker en Rusia: los foros, donde se compra y vende información y malware por miles de dólares.


$50.000 por los nombres y cuentas de varios millonarios africanos, información vendida en un foro ruso.

A través de un abogado especializado en hacking, los reporteros se ponen en contacto con un hacker condenado por robo de tarjetas de crédito al que aún a día de hoy busca EEUU: Sergey Pavlovich.


El tipo no se puede quejar: cuenta cómo ganaba más de $100,000 al mes con el robo de tarjetas y cómo se los gastaba en prostitutas, entre otras cosas. Eso da para muchas prostitutas. Espero que esté bien de salud.

Más adelante, se habla de presuntos ciberataques de Rusia a Ucrania, más concretamente a su infraestructura estatal: centrales térmicas, metro, bancos... Lo más interesante del asunto es que aparece en pantalla un oficial del departamento de ciberseguridad ucraniano diciendo que Ucrania dispone de una unidad de hackers llamada "Ciberalianza", formada por civiles, que se dedica - según sus miembros - a hackear a estamentos gubernamentales de Rusia.

En Rusia, a su vez, se promueve el hackeo de infraestructuras extranjeras con eventos como Positive Hack Days. En este evento, se anima a los asistentes a piratear contadores de la luz, a modificar rutinas en software para fábricas, a acceder a PCs, etc.


Uno de los hobbies de la juventud en Rusia parece ser hackear cajeros automáticos.

Un hacker ruso llamdo Konstantin Kozlovsky aparece en el documental asegurando, desde una sala de un tribunal ruso, haber sido reclutado de joven por el FSB ruso y haber sido contactado para manipular las elecciones de EEUU. Tras hacerlo y haberlo revelado públicamente, fue detenido y encarcelado.

Putin no niega que Rusia use hackers para espiar a otros países. Es más, compara el ciber terrorismo con la boma atómica. Dice que hay que fijar reglas para su uso del mismo modo que se fijaron para el uso de bombas atómicas. Y en una entrevsta a su asesor en cibrseguridad, este dice que al no haber reglas aún en este tema, cada nación es libre de espiar a quien quiera.


Michael Hayden dice que si cuando era director de la NSA se le hubiera preguntado qué hacer en caso de haber obtenido acceso al correo del partido de Putin habría dicho: ¡cójalo! Al menos, es un tipo sincero.

Por último, el ex-presidente de la NSA y de la CIA Michael Hayden dice que Rusia no debería negar que hackeó a Hillary Clinton. Que debería ser USA quien se avergonzara de haber sido hackeada.
0