miércoles, 31 de agosto de 2022

Ver parches instalados en un SUSE Linux



Cómo ver el historial de todos los parches instalados en SLES (SUSE Linux Enterprise Server).



En una auditoría de seguridad me pidieron que presentara un listado que mostrara todos los parches instalados en un sistema SUSE Linux Enterprise Server durante el año en curso. Tras investigar un poco, di con las siguientes maneras de encontrar dicha información.


Histórico


SLES guarda un histórico de actualizaciones en /var/log/zypp/history:

HOST # cat /var/log/zypp/history 2022-08-31 12:08:56 | install | hwinfo | 21.82-150300.3.3.1 | x86_64 ||Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Updates|4cb0aad9e2148b3290877e3903a9792bfb31bfc7b9cb883a5088b6e04387d682| 2022-08-31 12:08:57 | install | glibc-locale-base | 2.31-150300.37.1 | x86_64 ||Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Updates|e13d47fd5e6a0cc73f5c469d16360b40c7c77ae560425c34c96e5fd67e8edae6| 2022-08-31 12:08:57 | install | glibc-lang | 2.31-150300.37.1 | noarch ||Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Updates|17185b24afb65caf58422923d28942ea7dc08efba88fde4608fca106f1b84879| 2022-08-31 12:08:57 | install | Mesa-libglapi0 | 20.2.4-150300.59.3.1 | x86_64 ||Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Updates|6170c01d46ec4b79feab1a1d5381e4328ca325f9134f73b4d80b01729c32446b| 2022-08-31 12:08:57 | install | libz1-32bit | 1.2.11-150000.3.33.1 | x86_64 ||Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Updates|fd6f29c14574b6daa8c8af6a17949ac9d9d68c71b7ac143a714eaa4815fee937| 2022-08-31 12:08:57 | install | libudev1-32bit |246.16-150300.7.51.1 | x86_64 ||Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Updates|39993ba30db3639e359662c4a70333b5f54718622309984e0c6e9a43bd08be00| 2022-08-31 12:08:57 | install | libsystemd0-32bit |246.16-150300.7.51.1 | x86_64 ||Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Updates|19aef524977d87bf6c4ba27e810c6e0ad849d68389cdbda5469a778895d01095| 2022-08-31 12:08:57 | install | libpcre1-32bit |8.45-150000.20.13.1 | x86_64 ||Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Updates|75a6cf6909f11a956935c6612cbac7509f33e7dca1dee6165c2698122a0be1ca| ...

Usando grep, podemos filtrar los resultados por año:

HOST # cat /var/log/zypp/history | grep 2022 | grep -E 'patch|install'


Listado


Por otro lado, podemos ver una lista con todos los parches instalados usando el siguiente comando:

HOST # zypper search --type patch --installed-only Loading repository data... Reading installed packages... S | Name | Summary | Type --+---------------------------------------------+-----------------------------+------ i | SUSE-SLE-Module-Basesystem-15-SP3-2021-1474 | Security update for ceph | patch i | SUSE-SLE-Module-Basesystem-15-SP3-2021-1481 | Recommended update for lvm2 | patch i | SUSE-SLE-Module-Basesystem-15-SP3-2021-1491 | Security update for p7zip | patch i | SUSE-SLE-Module-Basesystem-15-SP3-2021-1493 | Security update for avahi | patch i | SUSE-SLE-Module-Basesystem-15-SP3-2021-1523 | Security update for libxml2 | patch ...

Si queremos listar los parches por el CVE al que hacen referencia:

HOST # zypper list-patches --cve The following matches in issue numbers have been found: Issue | No. | Patch | Category | Severity | Status ------+---------------+-------------------+-------------+-----------+---------- cve | CVE-2015-0287 | SUSE-SLE-Module.. | recommended | moderate | needed cve | CVE-2014-3566 | SUSE-SLE-SERVER.. | recommended | moderate | not needed ...


Fuentes:

https://documentation.suse.com/sles/15-SP3/pdf/book-sle-admin_color_en.pdf
0

miércoles, 24 de agosto de 2022

Esconder la cabecera Server en nginx



Cómo esconder la versión de nginx o la cabecera server por completo.



Tras una auditoría de seguridad se me ha pedido esconder la versión de nginx corriendo en un servidor.

nginx, tanto en su versión plus como en su versión open source, permite esconder la versión que corre un servidor mediante la directiva server_tokens. Eso es útil para esconder la versión de nginx que se muestra en las páginas de error y en la cabecera Server de cada respuesta.

Las distintas posibilidades de sintaxis son las siguientes:

- server_tokens on: muestra la versión de nginx.
- server_tokens off: no muestra la versión de nginx.
- server_tokens build: muestra el nombre del build junto a la versión.
- server_tokens "string": muestra un string personalizado (plus).
- server_tokens "": no muestra la cabecera server (plus).

Por defecto nginx usa "server_tokens on", es decir, muestra la versión instalada de nginx.

Si quisieramos esconder la versión, como se me pedía a mi, podríamos usar:

server_tokens off;

Esta directiva se puede usar en distintos contextos:

- http: todos los dominios.
- server: un dominio concreto.
- location: una ruta dentro de un dominio concreto.

Asimismo, las dos últimas posibilidades (string personalizado y esconder el nombre del software) sólo están disponibles en nginx plus (la subscripción comercial) desde la versión 1.9.13.

Si queremos obtener los mismos resultados con la versión open source, siempre podemos compilar el código fuente de nginx eliminando todas las referencias a la versión o a nginx en sí mismo.


Fuentes:

http://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
0

miércoles, 3 de agosto de 2022

Compartir directorios entre servidores vía NFS



Cómo compartir directorios vía NFS entre servidores Linux.



A continuación un pequeño manual de cómo compartir directorios entre sistemas Linux vía NFS.


Servidor


En el lado servidor, instalamos el paquete nfs-server:

HOST # zypper in nfs-server*

Añadimos la entrada del host que se conectará a este servidor en la lista de entradas permitidas:

HOST # cat /etc/exports # See the exports(5) manpage for a description of the syntax of this file. # This file contains a list of all directories that are to be exported to # other computers via NFS (Network File System). # This file used by rpc.nfsd and rpc.mountd. See their manpages for details # on how make changes in this file effective. /carpetaexportada/ 10.100.200.2(rw,sync,no_root_squash)

Arrancamos el servicio nfs-server:

HOST # service nfs-server start

Lo hacemos permanente:

HOST # systemctl enable nfs-server Created symlink /etc/systemd/system/multi-user.target.wants/nfs-server.service → /usr/lib/systemd/system/nfs-server.service.

Exportamos el share:

HOST # exportsfs -a


Cliente


En el cliente, montamos el share en /etc/fstab:

10.120.200.1:/carpetaexportada /montajelocal nfs defaults 0 0

Remontamos todo:

HOST # mount -a

Mostramos las carpetas remotas compartidas:

HOST # showmount -e 10.100.200.1 Export list for 10.100.200.2: /carpetaexportada 10.100.200.1
0

miércoles, 6 de julio de 2022

Nginx socket() failed (24: Too many open files)



Cómo solucionar el error "too many open files" en NGINX.



Al acceder a una web que pasaba a través de NGINX en modo reverse proxy, he visto que esta no era accesible y me he encontrado el siguiente log en su archivo de log:

2021/07/06 12:21:23 [alert] 28720#0: *59757 socket() failed (24: Too many open files) while connecting to upstream,

Esto ha ocurrido porque NGINX tenía demasiados archivos abiertos. Recordemos que, por defecto, NGINX puede abrir un máximo de 4096 archivos simultáneos por worker.

Para saltarnos esta limitaxción, deberemos usar el parámetro "worker_rlimit_nofile", el cual deberemos añadir al archivo /etc/nginx/nginx.conf antes del bloque http:

# Increase open files worker_rlimit_nofile 30000;

En el ejemplo anterior le estamos diciendo a NGINX que puede abrir un máximo de 30.000 archivos, lo cual debería ser suficiente para proxys con una cantidad elevada de peticiones por segundo.

Para aplicar los cambios, reiniciamos NGINX:

service nginx restart

Luego comprobamos que la config. se ha aplicado correctamente:

HOST # ps -ef | grep nginx root 5092 1 0 09:33 ? 00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 5093 5092 13 09:33 ? 00:37:06 nginx: worker process

Nos fijamos en el worker process, servicio con PID 5093 y miramos sus límites:

HOST # cat /proc/5093/limits | grep "open files" Max open files 30000 30000 files


Fuentes:

https://www.claudiokuenzler.com/blog/850/nginx-socket-failed-24-too-many-open-files
0

miércoles, 1 de junio de 2022

NGINX: página de error 403 personalizada



Cómo personalizar la página de error 403 Forbidden en NGINX.



Por defecto, NGINX muestra una página de error 403 Forbidden muy básica. Lo bueno es que podemos personalizarla a nuestro gusto creando un documento HTML y enlazándolo desde la config. de NGINX.

Primero creamos un documento HTML:

<html> <head><title>Error 403 – Acceso denegado</title></head> <body> No tienes permisos suficientes para acceder a esta página. </body> </html>

Cuando hayamos creado el documento, lo guardamos en la ruta "root" de la web:

A continuación, editamos el fichero /etc/nginx/nginx.conf y añadimos:

... server { ... error_page 403 /error403.html; location /error403.html { allow all; } ... } ...

Destacar que la config. que nos permite personalizar el error 403 debe estar dentro del bloque "server" para un dominio o subdominio concreto.

En el código anterior se le dice a NGINX que muestre el archivo error403.html cada vez que ocurra un error 403 en el acceso a la web. Adicionalmente, se debe especificar explícitamente que todo el mundo pueda leer este archivo, de lo contrario, se mostrará la página de error 403 predeterminada de NGINX y nuestro trabajo no habrá servido para nada.
0

miércoles, 4 de mayo de 2022

Exportar lista de usuarios de un grupo de AD



Cómo exportar todos los usuarios de un grupo de Active Directory.



Imaginemos que queremos enviar un correo a todos los usuarios de un grupo concreto de Active Directory. Primero, deberemos saber qué usuarios hay en el grupo.

Para ver los usuarios y sus direcciones de correo, deberemos exportar los campos nombre y mail de los usuarios. Para ello, podemos usar la función Get-AdGroupMember:

$GroupName = 'Nombre del grupo'
Get-AdGroupMember -Identity $GroupName | Get-AdUser -Properties * | Select Name,Mail

El output del script será:

Name Mail -------------- ----------------- Marc Garcia marc.garcia@una.org Alberto Perez alberto.perez@una.org ...

De esta forma veremos el output en la terminal.

Si queremos exportar el resultado a un archivo csv podemos usar la función Export-csv:

$GroupName = 'Nombre del grupo'
$ExportPath = 'C:\Temp\export.csv'
Get-AdGroupMember -Identity $GroupName | Get-AdUser -Properties * | Select Name,Mail | Export-csv -NoTypeInformation $ExportPath

En este caso, el resultado será un archivo csv con los campos separados por comas:

"Marc García","marc.garcia@una.org" "Alberto Perez","alberto.perez@una.org" ...

Una vez obtenido el archivo csv, ya lo podremos manipular con Excel para extraer solo las direcciones de correo o eliminar ciertos usuarios, entre otros.


Fuentes:

https://shellgeek.com/powershell-export-active-directory-group-members/