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

miércoles, 19 de junio de 2019

Borrar archivos más antiguos de X días en Linux



Cómo borrar todos los archivos de una carpeta creados hace más de X días en un sistema Linux.



Supongamos que tenemos un script corriendo en un sistema operativo Linux cuya función es conectarse a un dispositivo y exportar un backup de su configuración para guardarlo en local.

Si ejecutamos dicho script a diario, el sistema de archivos donde se guarden dichos backups se llenará de archivos, lo cual provocará que, a la larga, el disco duro llegue al 100% de ocupación y el sistema operativo deje de funcionar. Para evitar este problema, podemos usar un comando que vaya eliminando archivos cuya fecha de creación sea más antigua de X días. Dicho de otra forma, vamos a ver cómo realizar rotación de backups estableciendo un período de retención de X días.


Comando



Podemos eliminar archivos más antiguos de X días mediante el comando find:

HOST# find /ruta/ -type f -mtime +10 -delete

Analicemos sus parámetros:

• find: invocamos el comando find para buscar archivos.
• /ruta/: ruta absoluta hacia el directorio donde se encuentran los archivo a eliminar.
• -type f: solo eliminar archivos (sino, se eliminarían también directorios).
• -mtime +10: eliminar archivos cuyo contenido no haya sido modificado en más de 10 días.
• -delete: eliminar los archivos que cumplan las condiciones anteriormente descritas. Este parámetro siempre debe ir al final de la cadena de parámetros.


Opciones adicionales



Opcionalmente, podemos añadir estos parámetros (y más):

• -mindepth 1: procesar todos los directorios por debajo de la ruta absoluta, excepto los de la ruta en sí.
• -maxdepth X: solo eliminar archivos hasta X niveles (carpetas) por debajo de la ruta absoluta.
• -name "*.bak": eliminar solamente archivos con extensión .bak.


Alternativa



Alternativamente, podríamos usar el comando find con el parámetro -exec si la opción -delete no estuviera disponible en el sistema operativo o la shell que estemos usando.

Para usar la opción -exec, debemos invocarla de la siguiente manera:

HOST# find /ruta/ -type f -mtime +10 -exec rm {} \;

Decir que con este parámetro tendremos problemas si los nombres de archivo tienen espacios, comillas, etc. por lo que es aconsejable usar la opción -delete en vez de -exec rm {} \; a la hora de invocar el comando find para eliminar archivos, siempre que sea posible.


Reflexión final



Antes de usar la opción -delete no estaria de más ejecutar el comando sin esa opción, lo cual nos mostrará por pantalla la lista de archivos que encuentra. Una vez hayamos configurado opciones como mindepth, name y type a nuestro gusto y hayamos verificado qué archivos se van a eliminar, ya podemos usar -delete para eliminar esos archivos de forma segura.


Fuentes:

https://unix.stackexchange.com/questions/194863/delete-files-older-than-x-days
https://www.geeksforgeeks.org/mindepth-maxdepth-linux-find-command-limiting-search-specific...
0

miércoles, 12 de junio de 2019

Fortinet Threat Map



FortiGuard Labs es un departamento Fortinet compuesto por más de 200 investigadores y analistas que trabajan con herramientas y tecnología desarrolladas internamente para descubrir y estudiar amenazas de ciberseguridad. Siempre están buscando nuevas tácticas y técnicas de ataque que luego usan para crear estrategias de mitigación de amenazas en los firewalls FortiGuard, el producto insíngia de Fortinet.

El equipo de investigación de amenazas cuenta con expertos dedicados que estudian todas las áreas críticas de la ciberseguridad: malware, botnets, dispositivos móviles y vulnerabilidades zero days. Estos descubrimientos se comparten en el portal de FortiGuard Labs.

Los analistas de servicios estudian el código malicioso y desarrollan firmas de mitigación, mientras que los desarrolladores de tecnología actualizan continuamente los motores de protección de seguridad a nivel mundial para combatir las amenazas mediante los servicios de FortiGuard.

A través de los sistemas de detección de intrusiones (IPS), Fortinet alimenta un mapamundi on-line que muestra los ciber ataques que se están produciendo alrededor del mundo en tiempo real:



URL: http://threatmap.fortiguard.com

Si echamos un vistazo más de cerca al detalle de los ciber ataques que se están produciendo, veremos qué sistemas se están tratando de explotar y en qué país:



Si clicamos sobre un país, veremos el detalle de su actividad:



El tipo de ataque se diferencia por color:



Por último, decir que es bastante hipnótico mirar este mapa, aunque bajo mi punto de vista, no estaría de más algo más de información en la vista general o al clicar un país.


Fuentes:

https://www.fortiguard.com
https://www.fortinet.com/fortiguard/threat-intelligence/threat-research.html
0

miércoles, 5 de junio de 2019

Importar nuevo firmware a un Sonicwall vía CLI



Cómo averiguar el modelo de un Sonicwall vía cli, como averiguar la versión de firmware instalada en un Sonicwall y cómo subir una nueva versión de firmware a un Sonicwall via cli (SSH).



En otra entrada ya expliqué cómo actualizar el firmware de un Sonicwall vía interfaz gráfica. En esta ocasión, explicaré cómo actualizar el firmware de un Sonicwall vía cli (SSH).

Para empezar, nos conectamos al Sonicwall por SSH. Una vez en la terminal, debemos averiguar qué modelo de Sonicwall estamos administrando y qué versión de firmware está instalada en ese dispositivo. Podemos ver esta información usando el comando show version:

admin@18B16956> show version firmware-version "SonicOS Enhanced 5.9.1.10-1o" rom-version 5.0.6.0 model SOHO serial-number XXXX-XXXX-XXXX system-time "06/05/2019 13:23:09.640" system-uptime "76 Days, 0 Hours, 32 Minutes, 43 Seconds" last-modified-by "admin 192.168.1.2:X0 UI 05/21/2019 17:00:39"

A continuación, creamos las "backup settings" vía cli. Estas backup settings son una copia de la configuración del Sonicwall que el dispositivo cargará al iniciarse con el nuevo firmware.
Las backup settings solo se pueden crear en modo config.

admin@18B16956> configure config(18B16956)# firmware backup Backup Settings created successfully

En este punto, debemos habernos descargado un archivo .sig con la última versión de firmware liberada para el modelo en cuestión. Este archivo está disponible en www.mysonicwall.com. Una vez tengamos el archivo .sig, lo subimos a un servidor con FTP habilitado y lo importamos en el Sonicwall:

admin@18B16956# import firmware ftp ftp://user:password@192.168.10.11/firm.sig % Downloading firm.sig from FTP server at 192.168.10.11... % Download complete. 14954252 bytes read. % Firmware uploaded successfully. % Activate Uploaded Firmware by executing the 'boot' command.

Una vez se haya subido el archivo, reiniciamos el dispositivo con el nuevo firmware:

admin@18B16956# boot uploaded Are you sure you wish to restart? [cancel]: yes

Cuando se haya reiniciado el dispositivo, podremos ver que está en la última versión:

admin@18B16956> show version firmware-version "SonicOS Enhanced 5.9.1.12-4o" rom-version 5.0.6.0 model SOHO serial-number XXXX-XXXX-XXXX system-time "06/05/2019 13:33:19.640" system-uptime "0 Days, 0 Hours, 12 Minutes, 33 Seconds" last-modified-by "admin 192.168.1.2:X0 UI 06/05/2019 13:30:39"

En este momento ya tenemos el Sonicwall actualizado.


Fuentes:

https://www.sonicwall.com/support/knowledge-base/?sol_id=170505533052286
https://www.sonicwall.com/support/knowledge-base/?sol_id=170503555701786
0

miércoles, 29 de mayo de 2019

Cómo conectar por SSH a un EC2 Linux en AWS



Pasos a seguir para conectarse por SSH a una instancia EC2 Linux en Amazon Web Services (AWS).



Al igual que ocurre al desplegar una instancia Windows en Amazon Web Services, al desplegar una instancia Linux en AWS se debe generar un par de claves pública/privada, que luego nos servirán para acceder a la instancia. A continuación, se debe descargar la clave privada (fichero.pem), la cual actuará como "contraseña" para acceder al sistema operativo.

Con el usuario, la IP de la instancia y la clave privada, podremos conectarnos por SSH a la máquina que hayamos desplegado. El usuario para conectarse a una instancia varia según la distribución Linux.

La lista de usuarios y distribuciones soportadas es la siguiente:

Para Amazon Linux, el nombre de usuario es ec2-user.
Para CentOS, el nombre de usuario es centos.
Para Debian, el nombre de usuario es admin o root.
Para Fedora, el nombre de usuario es ec2-user o fedora.
Para RHEL, el nombre de usuario es ec2-user o root.
Para SUSE, el nombre de usuario es ec2-user o root.
Para Ubuntu, el nombre de usuario es ubuntu.


Conectarse desde Linux



Para conectarse a una instancia Linux mediante SSH desde un sistema operativo Linux, hay que especificar el archivo de clave privada (.pem), el usuario y la IP de la instancia. Por ejemplo:

HOST# ssh -i key.pem ec2-user@10.11.25.1


Conectarse desde Windows (PuTTy)



Para conectarse con PuTTY a una instancia Linux en AWS, primero hay que convertir la clave privada de la instancia mediante PuTTYgen, ya que PuTTY no admite de forma nativa claves en formato .pem. PuTTY tiene la herramienta PuTTYgen que permite convertir claves al formato que usa PuTTY (.ppk).

Para convertir la clave privada, abrir PuTTYgen y en "Type of key to generate", elegir RSA.



Clicar "Load" para cargar el fichero .pem. Recordar que hay que seleccionar la opción de mostrar todos los tipos de archivo para ver los archivos .pem.



Una vez cargado el fichero .pem, elegir "Save private key" (Guardar clave privada) para guardar la clave en un formato que PuTTY pueda usar. PuTTYgen mostrará una advertencia acerca de guardar la clave sin contraseña. Si se elije "Yes" se guardará la clave privada sin contraseña.

Opcionalmente, podemos usar una contraseña en la clave privada. Esto actúa como una capa adicional de seguridad. De esta forma, si alguien consigue robarnos la clave privada, no la podrá usar sin la contraseña. El inconveniente de usar una contraseña en una clave privada es que dificulta la automatización de tareas, puesto que la intervención humana es necesaria para, por ejemplo, iniciar sesión en una instancia.

La clave privada está ahora en el formato correcto para su uso con PuTTY.

Para conectarse a la instancia Linux mediante PuTTY, hay que insertar el nombre de usuario y la IP de la instancia en el campo "Host Name" del apartado Session, por ejemplo, ec2-user@10.1.12.34.



Comentar que se puede configurar PuTTY para que envíe datos "keepalive" a intervalos regulares para mantener la sesión activa. Esto es útil para evitar desconectarse de una instancia por inactividad. En el panel Category, elegir Connection y escribir el intervalo deseado en "Seconds between keepalives".

Para especificar la clave privada, abrir Connection, abrir SSH y elegir Auth (Autenticación).

Elegir Browse y seleccionar el archivo .ppk que se ha generado anteriormente.



Si se va a iniciar sesión frecuentemente en esta instancia, se puede guardar la sesión en la sección "Terminal" para usarla en el futuro. Para ello, elegir un nombre de sesión y clicar el botón Save.

Ahora ya se puede clicar Open para abrir una conexión SSH hacia la instancia.

NOTA: si se ha especificado una contraseña al convertir la clave privada al formato de PuTTY, se deberá introducir la contraseña en este momento.


Fuentes:

https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html
https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/putty.html
0

miércoles, 22 de mayo de 2019

libmcrypt-devel en SUSE Linux Enterprise 15



Cómo instalar libmcrypt o libmcrypt-devel en un SUSE Linux Enterprise Server 15



Instalando un daemon NRPE (Nagios Remote Plugin Executor) en un SUSE Linux Enterprise Server 15 para monitorizar el sistema, me encontré con que esta versión de SUSE Linux Enterprise Server (SLES) no incluye libmcrypt-devel en sus repositorios oficiales, a diferencia de SLES 12, que sí la incluye.

HOST# zypper install libmcrypt-devel Refreshing service 'Basesystem_Module_15_x86_64'. Refreshing service 'Desktop_Applications_Module_15_x86_64'. Refreshing service 'Development_Tools_Module_15_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. Refreshing service 'SUSE_Package_Hub_15_x86_64'. Refreshing service 'Server_Applications_Module_15_x86_64'. Refreshing service 'Web_and_Scripting_Module_15_x86_64'. Loading repository data... Reading installed packages... 'libmcrypt-devel' not found in package names. Trying capabilities. No provider of 'libmcrypt-devel' found. Resolving package dependencies... Nothing to do.

libmcrypt-devel es una dependencia de NRPE, y sin ella, no podía continuar con la instalación de NRPE.

Me puse en contacto con SUSE y les pregunté acerca de la disponibilidad de libmcrypt-devel para SUSE Linux Enterprise Server 15. Tras hablar con ingeniería, el soporte de SUSE me contestó que este paquete fue retirado en SLE 15 porque su código no recibía actualizaciones desde 2007, y ellos no dan soporte a software obsoleto, cosa respetable.

Llegados a este punto, tenía varias opciones: podía compilar libmcrypt desde código fuente, buscar un .rpm o buscar un repositorio que incluyera el paquete pre-compilado para SLE 15. Opté por la última opción. Busqué repositorios no oficiales en software.opensuse.org que ofrecieran este paquete, pero no encontré ninguno que ofreciera libmcrypt.

Buscando de otras formas, acabé encontrando un repositorio llamado 'SNAG-View Build Services' que incluía libmcrypt-devel para SLE 15, así que añadí este repositorio al sistema:

HOST# zypper addrepo https://download.opensuse.org/repositories/home:/snagview/SLE_15/home:snagview.repo Adding repository 'SNAG-View Build Services (SLE_15)' ..................[done] Repository 'SNAG-View Build Services (SLE_15)' successfully added URI : http://download.opensuse.org/repositories/home:/snagview/SLE_15/ Enabled : Yes GPG Check : Yes Autorefresh : No Priority : 99 (default priority) Repository priorities are without effect. All enabled repositories share the same priority.

Refresqué la lista de repositorios y acepté 'SNAG-View Build Services' como fuente de confianza:

HOST# zypper refresh Repository 'SLE-Module-Basesystem15-Pool' is up to date. Repository 'SLE-Module-Basesystem15-Updates' is up to date. Repository 'SLE-Module-Desktop-Applications15-Pool' is up to date. Repository 'SLE-Module-Desktop-Applications15-Updates' is up to date. Repository 'SLE-Module-DevTools15-Pool' is up to date. Repository 'SLE-Module-DevTools15-Updates' is up to date. Repository 'SLE-Product-SLES15-Pool' is up to date. Repository 'SLE-Product-SLES15-Updates' is up to date. Repository 'SLE-Module-Packagehub-Subpackages15-Pool' is up to date. Repository 'SLE-Module-Packagehub-Subpackages15-Pool' is up to date. Repository 'SLE-Module-Packagehub-Subpackages15-Updates' is up to date. Repository 'SUSE-PackageHub-15-Pool' is up to date. Repository 'SUSE-PackageHub-15-Pool' is up to date. Repository 'SUSE-PackageHub-15-Standard-Pool' is up to date. Repository 'SUSE-PackageHub-15-Standard-Pool' is up to date. Repository 'SLE-Module-Server-Applications15-Pool' is up to date. Repository 'SLE-Module-Server-Applications15-Updates' is up to date. Repository 'SLE-Module-Web-Scripting15-Pool' is up to date. Repository 'SLE-Module-Web-Scripting15-Updates' is up to date. Retrieving repository 'SNAG-View Build Services (SLE_15)' metadata --------[\] New repository or package signing key received: Repository: SNAG-View Build Services (SLE_15) Key Name: home:snagview OBS Project Key Fingerprint: 7689214A B23FD92F 60739D1C D3358BDA 12A73586 Key Created: Tue Dec 18 16:18:43 2018 Key Expires: Thu Feb 25 16:18:43 2021 Rpm Name: gpg-pubkey-12a73586-5c190fd3 Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): a Retrieving repository 'SNAG-View Build Services (SLE_15)' metadata .....[done] Building repository 'SNAG-View Build Services (SLE_15)' cache ..........[done] Repository 'Security tools (SLE_15)' is up to date. All repositories have been refreshed.

Ahora sí, ya pude instalar libmcrypt-devel y continuar con la instalación de NRPE.

HOST# zypper install libmcrypt-devel Refreshing service 'Basesystem_Module_15_x86_64'. Refreshing service 'Desktop_Applications_Module_15_x86_64'. Refreshing service 'Development_Tools_Module_15_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. Refreshing service 'SUSE_Package_Hub_15_x86_64'. Refreshing service 'Server_Applications_Module_15_x86_64'. Refreshing service 'Web_and_Scripting_Module_15_x86_64'. Loading repository data... Reading installed packages... Resolving package dependencies... The following 2 NEW packages are going to be installed: libmcrypt libmcrypt-devel The following 2 packages have no support information from their vendor: libmcrypt libmcrypt-devel 2 new packages to install. Overall download size: 194.2 KiB. Already cached: 0 B. After the operation, additional 676.4 KiB will be used. Continue? [y/n/...? shows all options] (y):

Ahora, a ver cuándo Nagios actualiza NRPE y usa otra librería criptográfica...
0

miércoles, 15 de mayo de 2019

Habilitar ejecución de archivos .ps1 en Windows



Cómo habilitar la ejecución de scripts de PowerShell en Windows, cómo ejecutar archivos .ps1, cómo solucionar el error "la ejecución de scripts está deshabilitada en este sistema".



Windows permite automatizar tareas mediante scripts de PowerShell, tanto en su versión de escritorio como en un Windows Server. Sin embargo, la ejecución de scripts está deshabilitada por defecto. Veamos cómo permitir la ejecución de scripts de PowerShell en un entorno Windows.

La primera vez que ejecutemos un script de PowerShell contenido en un archivo .ps1 en un sistema operativo Windows, lo más probable es que el sistema nos devuelva el siguiente mensaje:

PS C:\Users\usuario> .\archivo.ps1 .\script.ps1 : No se puede cargar el archivo C:\Users\usuario\archivo.ps1 porque la ejecución de scripts está deshabilitada en este sistema. Para obtener más información, consulta el tema about_Execution_Policies en https:/go.microsoft.com/fwlink/?LinkID=135170. En línea: 1 Carácter: 1 + .\script.ps1 + ~~~~~~~~~~~~ + CategoryInfo : SecurityError: (:) [], PSSecurityException + FullyQualifiedErrorId : UnauthorizedAccess

Podemos ver cómo está configurada la ejecución de scripts de PowerShell en el sistema mediante:

PS C:\Users\usuario> Get-ExecutionPolicy -list        Scope ExecutionPolicy        ----- --------------- MachinePolicy      Undefined UserPolicy         Undefined Process            Undefined CurrentUser        Undefined LocalMachine       Undefined

Como se observa en el cuadro, las políticas de ejecución de scripts de PowerShell no están definidas (Undefined). Por defecto, Windows no tiene definida la ejecución de scripts, lo cual significa que deniega implícitamente su ejecución hasta que se configure un apartado como "no restringido".

Los modos de ejecución que se pueden especificar son los siguientes:

• Restricted (Restringida): es la regla por defecto. Permite la ejecución de comandos individuales pero no de archivos de scripts, incluyendo los archivos de configuración y formato (.ps1xml), los archivos de scripts de módulos (.psm1) y los perfiles de Windows PowerShell (.ps1).

• Allsigned (Solo firmas): permite ejecutar scripts firmados por un editor de confianza, incluyendo los scripts que se escriban en el equipo local. Solicita confirmación antes de ejecutar scripts de publicadores que no hayan sido clasificados como de confianza.

• Remotesigned (Firma remota): permite la ejecución de scripts descargados de internet firmados digitalmente por un editor de confianza. No requiere firma digital en los scripts que hayan sido escritos en el equipo local.

• Unrestricted (Sin restricción): permite ejecutar scripts sin firmar. Advierte al usuario antes de ejecutar archivos de configuración y scripts descargados de Internet con el fin de añadir seguridad.

• Bypass: esta directiva no bloquea nada y no muestra advertencias de seguridad. Pensado para programas que integran un script de Windows PowerShell en una aplicación compleja.

• Undefined (Indefinido): esta opción indica que no existe ninguna directiva de ejecución establecida. Si la directiva de ejecución en todos los ámbitos es Undefined, la directiva de ejecución será Restricted, que es la directiva de ejecución por defecto en Windows.

Si queremos ejecutar scripts de PowerShell en una máquina, debemos permitir antes su ejecución mediante el comando Set-ExecutionPolicy del siguiente modo:

PS C:\Users\usuario> Set-ExecutionPolicy -Scope LocalMachine unrestricted Cambio de directiva de ejecución La directiva de ejecución te ayuda a protegerte de scripts en los que no confías. Si cambias dicha directiva, podrías exponerte a los riesgos de seguridad descritos en el tema de la Ayuda about_Execution_Policies en https:/go.microsoft.com/fwlink/?LinkID=135170. ¿Quieres cambiar la directiva de ejecución? [S] Sí [O] Sí a todo [N] No [T] No a todo [U] Suspender [?] Ayuda (el valor predeterminado es "N"): S Set-Executionpolicy : Se denegó el acceso a la clave de Registro 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell'. Para cambiar la directiva de ejecución para el ámbito (LocalMachine) predeterminado, inicie Windows PowerShell con la opción "Ejecutar como administrador". Para cambiar la directiva de ejecución para el usuario actual, ejecute "Set-ExecutionPolicy -Scope CurrentUser". En línea: 1 Carácter: 1 + Set-Executionpolicy -Scope LocalMachine unrestricted + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : PermissionDenied: (:) [Set-ExecutionPolicy], UnauthorizedAccessException + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands. SetExecutionPolicyCommand

Como vemos, para modificar los permisos a nivel de máquina, debemos ejecutar el comando como administrador. Si queremos ejecutar scripts con nuestro usuario sin tener que abrir una nueva instancia de PowerShell como administrador, basta con cambiar "LocalMachine" por "CurrentUser". De esta forma, Windows no nos pide que abramos nueva instancia de PowerShell como administrador:

PS C:\Users\usuario> Set-ExecutionPolicy -Scope CurrentUser unrestricted Cambio de directiva de ejecución La directiva de ejecución te ayuda a protegerte de scripts en los que no confías. Si cambias dicha directiva, podrías exponerte a los riesgos de seguridad descritos en el tema de la Ayuda about_Execution_Policies en https:/go.microsoft.com/fwlink/?LinkID=135170. ¿Quieres cambiar la directiva de ejecución? [S] Sí [O] Sí a todo [N] No [T] No a todo [U] Suspender [?] Ayuda (el valor predeterminado es "N"): S

Si listamos las políticas de ejecución de nuevo, veremos que CurrentUser ha cambiado a "Unrestricted":

PS C:\Users\usuario> Get-ExecutionPolicy -list        Scope ExecutionPolicy        ----- --------------- MachinePolicy      Undefined UserPolicy         Undefined Process            Undefined CurrentUser        Unrestricted LocalMachine       Undefined

A partir de este momento, ya podemos ejecutar archivos .ps1 con scripts de PowerShell sin problemas.
0

miércoles, 8 de mayo de 2019

¿Máquinas virtuales o contenedores?



Analicemos qué ventajas nos ofrecen los contenedores respecto a las máquinas virtuales y en qué situaciones sería recomendable sustituir máquinas virtuales por contenedores.
¿Puedo instalar Docker en el servidor?

Así empezó todo. Con una llamada de un desarrollador preguntándome si podía instalar Docker en un servidor de test que le había aprovisionado unos días antes. Esa llamada fue el preludio de una reunión infraestructura-desarrollo en la que surgió el tema que nos ocupa: ¿máquinas virtuales o contenedores?


Conceptos



Antes de evaluar qué opción es mejor y por qué, hablemos brevemente sobre qué es una máquina virtual y qué es un contenedor, para entender así sus diferencias.





Una máquina virtual es una imagen de un sistema operativo que se ejecuta sobre otro sistema operativo, creando un sistema invitado (guest) totalmente aislado del sistema operativo huésped (host).

Tanto el sistema operativo host como los sistemas operativos guest (máquinas virtuales) usan los recursos físicos (RAM, CPU, disco...) del servidor físico donde se encuentran. La porción de esos recursos que puede usar cada máquina virtual se configura en el hipervisor.

Un contenedor, por su parte, es un paquete cerrado de software que incluye una aplicación y todas aquellas dependencias que la aplicación necesita para poder desempeñar su función.

Los contenedores, a diferencia de las máquinas virtuales, están diseñados para interactuar con el sistema operativo sobre el que se despliegan - por ejemplo, interactúan con el kernel de Linux - por lo que anteriormente, un contenedor de Linux solo se podía ejecutar sobre sistemas operativos Linux y un contenedor de Windows solo se podía ejecutar sobre sistemas operativos Windows. Sin embargo, desde el año pasado, Microsoft permite ejecutar contenedores de Linux sobre Windows, previo despliegue de un entorno Linux mínimo sobre la máquina Windows (más información y detalles del proceso aquí).

En resumen, una máquina virtual es un sistema operativo completo, aislado del sistema operativo huésped, y un contenedor es un paquete de código que interactúa con el sistema operativo huésped y que incluye todas las dependencias que necesita para ejecutarse correctamente.


Antigüedad



La principal reticencia a la hora de usar contenedores es la antigüedad de la tecnología. Su consolidación en la industria. Si tomamos como ejemplo las máquinas virtuales, nos encontramos con que los famosos ESX de VMware se lanzaron al mercado en 2001 mientras que Docker - uno de los nombres que más suena cuando se habla de contenedores - existe desde 2013. No obstante, no debemos olvidar que los contenedores como aislamiento de aplicaciones ya existían desde antes de la aparición de Docker. Concretamente, LXC (Linux Containers) se lanzó en 2008.

Si bien es cierto que la virtualización de VMware existe desde hace casi 20 años, la tecnología de contenedores tiene ya más de 10 años a sus espaldas. No estamos ante una moda surgida el año pasado. Los contenedores son una tecnología que llegó para quedarse, y compañías de la talla de VISA, Desigual o PayPal, las cuales usan Docker en producción en estos momentos, lo demuestran.


¿Máquinas virtuales o contenedores?



Ahora sí, con los conceptos ya claros, podemos hablar de qué es mejor. Y la respuesta es: depende. Depende de nuestras necesidades.

Si necesitamos servir una página web, la respuesta para mi es muy clara: contenedores.
Si necesitamos ejecutar un programa .exe en un Windows Server, necesitamos que otra aplicación se conecte a este servidor a recoger unos logs y necesitamos una tercera aplicación, que corre sobre otro sistema operativo, para que monitorice el espacio en disco de los sistemas operativos anteriores, yo me decantaría por usar tres máquinas virtuales distintas.

Bajo mi punto de vista, los contenedores nos pueden ser útiles para albergar aplicaciones que corren bajo una misma plataforma, como pueden ser aplicaciones web, ya que nos permiten reaprovechar código, nos facilitan una alta disponibilidad que nos sería más difícil de conseguir con máquinas virtuales, nos permiten autoescalado (si la demanda por el servicio sube y se requieren más recursos en un momento dado se pueden autodesplegar contenedores rápidamente) y nos aseguran que una aplicación funcionará en cualquier máquina, como ventajas principales.


Aplicaciones monolíticas vs microservicios



Si hablamos de aplicaciones web, debemos hablar de microservicios, aplicaciones monolíticas y la relación de ambos con las máquinas virtuales y los contenedores.

La primera vez que escuché la expresión "aplicaciones monolíticas" fue en SUSE Expert Days 2018 (llego tarde, lo se), donde SUSE explicó su apuesta por los contenedores como método preferente de despliegue de aplicaciones web, por encima de opciones de hipervisor en Linux como KVM o Xen.

En una máquina virtual típica, podemos tener corriendo una página web sobre, por ejemplo, Apache y MariaDB. Esto es un ejemplo de aplicación monolítica. Si usáramos microservicios, podríamos dividir el código de la web en mini aplicaciones independientes entre sí que fueran llamadas según fueran siendo requeridas por la aplicación web. Y es en estas mini aplicaciones o mejor dicho, micro servicios, donde entran en juego los contenedores, pues cada microservicio se ejecuta en un contenedor independiente que se levanta solo cuando es necesario, y por tanto, solo consume recursos cuando es necesario, además de poder ser usado por varias aplicaciones web sin tener que tener el mismo código repetido en todas las aplicaciones.


Retorno de la inversión



Tomemos como ejemplo los entornos de antaño, con una máquina física por servidor. Hoy en día sería inviable que una compañía tuviera 500 máquinas físicas funcionando en su datacenter. Sin embargo, fácilmente puede una compañía tener 500 máquinas virtuales corriendo.

¿Por qué?

Porque el coste de electricidad, componentes, mantenimiento, etc. se dispararía en el caso de tener tantas máquinas físicas, mientras que esas máquinas virtualizadas tienen un coste asumible.

¿Qué ocurriría si sustituyéramos algunas máquinas virtuales por contenedores?

Lo que ocurriría es que el coste económico se reduciría aún más, puesto que se evitaría tener que mantener levantada una máquina virtual por cada aplicación, es decir, se podrían juntar varias aplicaciones en un mismo servidor, sin prescindir del aislamiento entre ellas ni de su alta disponibilidad.

Pongamos un ejemplo. Un sistema Linux Enterprise cualquiera requiere unos 15 GB de disco y 8 GB de RAM de media para funcionar de forma óptima. Si tenemos, digamos, 100 máquinas virtuales, estamos destinando 800 GB de RAM y 1,5 TB de disco solo para mantener levantados los sistemas operativos. Si las aplicaciones que corren sobre esos sistemas se contenerizasen, podríamos evitar gastar gran parte de esos recursos, ya que se podrían ejecutar muchos contenedores sobre unos pocos sistemas operativos y se podrían ir levantando y terminando contenedores en ellos según se requiriese.

Este ahorro de recursos, es decir, de dinero, se puede notar en un entorno on-premise, pero es especialmente destacable en un entorno cloud público, donde se paga directamente por recurso asignado a una máquina. En un AWS Summit, Amazon habló de cómo el uso de contenedores en vez de instancias podía llegar a reducir las facturas de AWS a la mitad.


Conclusión



Si estamos sirviendo muchas páginas web que usan la misma tecnología (mismo CMS, mismo servidor web, mismo tipo de base de datos, etc.), lo más recomendable sería ejecutar esas páginas en contendores. Así, se aprovecharían mejor los recursos de hardware y se facilitaría el ciclo de puesta en producción de las aplicaciones, ya que el código que corre en un contenedor en el PC del desarrollador funcionará igual en su PC que en el servidor de producción, entre otras ventajas.

Si, por el contrario, tenemos un entorno heterogéneo, con muchos sistemas operativos distintos y necesidades muy variadas, lo mejor, bajo mi punto de vista, es mantenerlo en máquinas virtuales separadas. Y, en todo caso, contenerizar aquellas aplicaciones que sea posible ejecutar desde contenedores, para aprovechar sus ventajas.
0

miércoles, 1 de mayo de 2019

-bash: /usr/bin/rm: Argument list too long



Qué provoca el error "-bash: /usr/bin/rm: Argument list too long", cómo borrar muchos, decenas, cientos, miles de archivos con un nombre determinado, de un directorio en Linux.



Antes de ver qué provoca el error "-bash: /usr/bin/rm: Argument list too long", veamos primero cómo se puede llegar a desencadenar la situación que lo origina.

Todo empezó cuando una compañera me comunicó que el acceso por FTP a cierto directorio de un servidor daba problemas. Me conecté por FTP al servidor y vi que, efectivamente, el servidor daba tiemout al tratar de devolver la lista de archivos de un directorio específico:

ftp> cd directorio 250 Directory successfully changed. ftp> dir 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. Error: Connection timed out Error: Failed to retrieve directory listing

Probé a listar el contenido de ese directorio desde la terminal de Linux para ver qué ocurria. Pasado un minuto aprox., el sistema me devolvió el listado de archivos.


Causas



Me encontré con miles de archivos de unos pocos bytes en el directorio afectado. Deduje entonces que algún programa estaba creando esos archivos cada día a una hora determinada, puesto que su hora de creación era la misma, día tras día.

La presencia de este gran volumen de archivos causaba timeout en el FTP porque al sistema no le daba tiempo a generar y mostrar la lista de archivos del directorio antes de hacer timeout. Del mismo modo, bash demoraba mucho tiempo hasta tener generada la lista de archivos del directorio, por su volumen.


Consecuencias



Mientras otra persona buscaba qué aplicación estaba creando esos archivos, tuve que lidiar con la posibilidad de que el disco donde se escribían estos archivos se quedara sin inodos libres, lo cual dejaría KO las aplicaciones que corren sobre él.


Solución



Debía borrar estos archivos. Empecé por buscar patrones compartidos por todos ellos y vi que todos los archivos tenían algo en común: sus nombres eran de 32 caracteres. Esto me daba una posibilidad de borrarlos en masa. Recordemos que, en Linux, para borrar archivos cuyo nombre de archivo es de una longitud determinada, se puede usar rm seguido de tantos ? como caracteres tenga el nombre.

En mi caso:

HOST# rm ???????????????????????????????? -bash: /usr/bin/rm: Argument list too long

El sistema se quejaba de que había demasiados archivos que coincidieran con el patrón facilitado, así que bash no podía ejecutar el comando rm sobre ellos.


Método 1: rm



Probé a ir bajando el número de comodines hasta que el sistema me dejó ejecutar:

HOST# rm 12E0ECTF783B1EE88ADA????????????

Llegados a este punto, podía ir borrando los archivos restantes poco a poco: buscar un nuevo patrón, borrar los archivos que siguen ese patrón, listar los archivos restantes, borrar el siguiente patrón, etc. pero eso era una tarea demasiado manual.

Tras buscar un poco, vi que se podía atacar el problema de otra forma más efectiva.


Método 2: find



Usando el comando find, bash no se queja del número de archivos a procesar.

HOST# find . -type f -name "12E?????????????????????????????" -delete


Resolución



Acabé usando el método 2, find, para borrar de golpe todos los archivos que quería eliminar. Después de esto, el sistema volvió a listar los archivos de esa carpeta de forma habitual (en milisegundos), tanto desde el FTP como desde la terminal. Ahora, el problema era enteramente del desarrollador...


¿Por qué se da el límite de argumentos en bash?



El límite de argumentos del cual se queja bash se da en la función del kernel execve (), que es utilizada por todas las demás funciones exec () (execl, execlp, execle, etc.). Lo que hace esta función es crear un búfer de 128 K en el extremo superior del espacio de memoria y copiar la línea de comandos y el entorno para el nuevo proceso en este espacio. El kernel luego carga el nuevo programa en la memoria, establece sus punteros argv y envp, y salta al punto de entrada del programa. El mensaje de error "Argument list too long" está causado por el código de error !E2BIG, devuelto por la función execve (), cuando no puede encajar la lista de argumentos y el entorno suministrados dentro del búfer de 128K.


Fuentes:

https://wiki.debian.org/CommonErrorMessages/ArgumentListTooLong
https://stackoverflow.com/questions/13409403/delete-files-with-a-length-of-x-or-more-characters
https://superuser.com/questions/701985/linux-how-can-i-delete-all-files-whose-file-name-is-more...
0