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