miércoles, 27 de mayo de 2020

Cómo actualizar un CentOS



Cómo actualizar CentOS, diferencias entre yum upgrade y yum update.



CentOS se genera a partir del código fuente de Red Hat Enterprise Linux, por lo que la forma de actualizar un CentOS es la misma que en un Red Hat, es decir, mediante el gestor de paquetes yum.


Actualizar el sistema



Para actualizar un CentOS, podemos usar:

HOST# yum update

Alternativamente, podemos ejecutar

HOST# yum upgrade

Si se especifican uno o más paquetes, yum solo actualizará los paquetes especificados, de lo contrario, se actualizarán todos los paquetes presentes en el sistema.

Al actualizar los paquetes, yum se asegurará de que todas las dependencias estén satisfechas. Si se usa la opción --obsolete, yum eliminará dependencias obsoletas.


yum update vs yum upgrade



La diferencia entre ambos es que "yum upgrade" actualiza los paquetes a sus últimas versiones y además fuerza la eliminación de paquetes obsoletos mientras que "yum update" puede que remueva esos paquetes dependientes o no. Usar "yum upgrade" es equivalente a usar "yum update --obsolete".

No hace falta decir que remover paquetes puede suponer un riesgo para el correcto funcionamiento de las aplicaciones que corran en el servidor, pues puede que el programa que se esté actualizando funcione, pero que otros que necesiten esas dependencias dejen de funcionar.

Por ejemplo, si instalamos un software manualmente, este no quedará registrado en el log de yum y si ejecutamos "yum upgrade" y se desinstala un paquete necesario para el correcto funcionamiento de este software, la aplicación dejará de funcionar.


Conclusión



Por todo lo mencionado anteriormente, es aconsejable usar "yum update" a la hora de actualizar servidores críticos que usen CentOS para evitar problemas con aplicaciones instaladas manualmente o aplicaciones de terceros.
0

miércoles, 20 de mayo de 2020

Denegar tráfico con ACL en switch Aruba



Cómo denegar tráfico entre un origen y un destino desde un switch.



Una lista de control de acceso o ACL (del inglés, access control list) es un concepto de configuración que podemos aplicar a los switches (u otros dispositivos) para denegar cierto tipo de tráfico.

En los switches Aruba, existen dos tipos de ACL:

• Standard ACL: permiten filtrar tráfico analizando la IP de origen.
• Extended ACL: permiten aplicar filtros dependiendo del origen y el destino de los paquetes.

Los switches Aruba permiten un total de hasta 2048 ACLs combinando IPv4 e IPv6. Hay que tener en cuenta que configurar 2 ACLs resulta en tener ACL usadas aunque ninguna de ellas esté asignada a una interfaz. Del mismo modo, si se asigna una ACL que no exista a una interfaz, el total de ACL usadas son 3 porque el switch tiene ahora 3 ACL únicas en su configuración.


Crear una ACL



Ejemplo de extended ACL en la que bloqueamos (deny) el puerto 445 provinente de los rangos 192.168.192.0/24 y 192.168.150.0/24 y permitimos todo el tráfico restante:

ip access-list extended "Puerto-445" 10 deny tcp 192.168.192.0 0.0.0.255 0.0.0.0 255.255.255.255 eq 445 log 20 deny tcp 192.168.150.0 0.0.0.255 0.0.0.0 255.255.255.255 eq 445 log 40 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 exit

La sintaxis es:

orden acción protocolo dirección_origen máscara_origen dirección_destino máscara_destino

Para denegar el tráfico hacia un puerto concreto, usaremos "eq puerto" al final de la línea.

Hay que tener en cuenta también que el orden de las reglas en una ACL es importante. Una vez un paquete hace match en una de las reglas de una ACL, las subsigüientes reglas de la misma ACL no se aplicarán al paquete.


Aplicar una ACL



Recordemos que una ACL no actúa hasta que no la aplicamos a una interfaz o VLAN. Para aplicar esta ACL a una VLAN - por ejemplo, la 100 - para bloquear el tráfico que entra a las máquinas de esta VLAN por su puerto 445 usamos la directiva "ip access-group" junto con la ACL creada anteriormente:

vlan 100 name "SERVERS" untagged C6,C8,C18 ip address 192.168.100.10 255.255.255.0 tagged C4,C24,Trk1-Trk7 ip access-group "Puerto-445" out exit


A partir de este momento, todo el tráfico con origen en los rangos 192.168.192.0/24 y 192.168.150.0/24 con destino cualquier IP de la VLAN 100 tendrá el tráfico de entrada por el puerto 445 denegado.


Fuentes:

http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/RA/15-18/5998-8151_ra_2620_asg...
http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/RA/15-18/5998-8151_ra_2620_asg...
http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/RA/15-18/5998-8151_ra_2620_asg...
http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/RA/15-18/5998-8151_ra_2620_asg...
0

miércoles, 13 de mayo de 2020

command-not-found



Cómo buscar en qué paquete está contenido un comando no instalado en SUSE Linux.



Si queremos compilar un programa escrito en C++ necesitaremos el compilador g++. Si ejecutamos g++ en un SLES recién instalado, nos encontraremos con el siguiente error:

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

Como nos dice el texto, podemos usar la utilidad "command-not-found" o "cnf" exclusiva de las distintas distribuciones de SUSE Linux para averiguar en qué paquete se encuentra un determinado binario.

Buscamos en qué paquete se encuentra "g++":

HOST# cnf g++ The program 'g++' can be found in the following package: * gcc-c++ [ path: /usr/bin/g++, repository: zypp (Basesystem_Module_15_SP1_x86_64:SLE-Module-Basesystem15-SP1-Pool) ] Try installing with: zypper install gcc-c++

Llegados a este punto, solo nos queda instalar el paquete sugerido siguiendo las instrucciones proporcionadas por el output del paso anterior.

En este caso, instalamos el paquete "gcc-c++" el cual incluye el binario "g++":

HOST# zypper install gcc-c++ RRefreshing service 'Basesystem_Module_15_SP1_x86_64'. Refreshing service 'Desktop_Applications_Module_15_SP1_x86_64'. Refreshing service 'Development_Tools_Module_15_SP1_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP1_x86_64'. Refreshing service 'SUSE_Package_Hub_15_SP1_x86_64'. Refreshing service 'Server_Applications_Module_15_SP1_x86_64'. Refreshing service 'Web_and_Scripting_Module_15_SP1_x86_64'. Loading repository data... Reading installed packages... Resolving package dependencies... The following 2 NEW packages are going to be installed: gcc-c++ gcc7-c++ 2 new packages to install. Overall download size: 8.9 MiB. Already cached: 0 B. After the operation, additional 23.9 MiB will be used. Continue? [y/n/v/...? shows all options] (y):

Cuando finalice la instalación, ya podremos compilar proyectos de C++ con g++.
0

miércoles, 6 de mayo de 2020

Moodle tras un reverse proxy NGINX



Configurar Moodle para que el tráfico hacia él pase por un reverse proxy NGINX.



Si tenemos un servidor web que aloje un Moodle y queremos pasar el tráfico hacia él a través de un reverse proxy como NGINX, deberemos aplicar configuraciones específicas tanto en el Moodle como en NGINX. De lo contrario, al acceder al moodle a través del proxy, nos encontraremos con el mensaje:

Reverse proxy enabled, server can not be accessed directly, sorry.

Para que el Moodle sea accesible tras el proxy, primero deberemos decirle que se está accediendo a él a través de un reverse proxy. Para ello, deberemos añadir los parámetros reverseproxy y sslproxy en el archivo de configuración de Moodle (config.php) y definirlos como true. Del mismo modo, deberemos fijar el parámetro wwwroot hacia el FQDN que nos llevará al Moodle (con https delante).


Moodle



El config.php de Moodle deberá tener las siguientes líneas:

$CFG->wwwroot = 'https://dominio.com'; ... $CFG->reverseproxy = true; $CFG->sslproxy = true;


NGINX



En el archivo nginx.conf del NGINX que actúe como proxy inverso deberemos especificar una serie de cabeceras que se traspasarán al servidor final:

server { listen 443 ssl; server_name dominio.com; access_log /var/log/nginx/dominio.com_access.log; error_log /var/log/nginx/dominio.com_error.log; location / { proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_cache_bypass $http_upgrade; proxy_pass_request_headers on; proxy_pass http://192.168.1.1; } }

Sobretodo, debemos evitar esta cabecera:

proxy_set_header Host $host;

Sustituimos la IP 192.168.1.1 por la IP o FQDN del servidor donde está corriendo Moodle y a partir de este momento, ya nos funcionará Moodle tras un reverse proxy NGINX.


Fuentes:

https://serverfault.com/questions/919318/moodle-behind-ssl-reverse-proxy-reverse-proxy-enabled...
0