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