miércoles, 15 de enero de 2025

Permitir acceso solo a ciertas IPs en NGINX



Permitir acceso solo a ciertas IPs.



Nginx incluye un módulo llamado ngx_http_access_module, que permite controlar el acceso a hosts según la dirección IP de origen del cliente. Este módulo permite aceptar o denegar solicitudes a hosts. La sintaxis típica es:

location / { deny 192.168.1.1; allow 192.168.1.0/24; allow 10.1.1.0/16; allow 2001:0db8::/32; deny all; }

Las reglas se evalúan en orden, de arriba hacia abajo, hasta encontrar la primera coincidencia. En este ejemplo, se permiten las subredes `10.1.1.0/16` y `192.168.1.0/24`, excepto la IP concreta `192.168.1.1`. También se acepta tráfico desde la subred IPv6 `2001:0db8::/32`. El resto del mundo queda denegado.


¿Cómo implementarlo de forma segura?


1. Nunca edites directamente `nginx.conf` para modificar IPs. En su lugar, crea un archivo aparte con la lista de IPs que deseas permitir o bloquear. Nómbralo, por ejemplo, nginx-blockips.conf.

2. Agrega una línea para incluir este archivo dentro del bloque `http {}` de tu `nginx.conf`:

include /ruta/a/tu/nginx-blockips.conf;

3. En ese archivo (nginx-blockips.conf), puedes definir las reglas:

deny 192.168.1.1; deny 192.168.1.2; deny 192.168.2.0/24; allow 192.168.1.0/24; deny all;

4. Guarda los cambios, luego verifica la configuración:

nginx -t

Si todo está correcto, recarga Nginx:

nginx -s reload

Y ya puedes probar a acceder desde distintas IPs para comprobar el comportamiento de NGINX desde peticiones enviadas desde diferentes orígenes.


Personalizar la página de error 403


Por defecto, Nginx muestra una página de error 403 muy básica a los clientes cuya IP de origen está incluida en una lista de acceso como no permitida. Para personalizarla:

1. Crea un archivo HTML en el directorio de tu sitio (por ejemplo, `error403.html`):

<html> <head><title>Error 403 – Acceso denegado</title> </head> <body> No tienes permiso para acceder a esta página. No intentes de nuevo. </body> </html>

2. Añade en tu bloque `server {}`:

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

Con esto, Nginx mostrará esa página personalizada en lugar de la predeterminada.
0

miércoles, 8 de enero de 2025

Ver los tipos de cifrado Kerberos de un equipo



Cómo comprobar qué tipo de cifrado Kerberos acepta un equipo de dominio con PowerShell.



En entornos de Active Directory (AD), la autenticación Kerberos es fundamental para la seguridad y el acceso a los recursos de la red. En este tipo de entornos, cada equipo tiene un atributo llamado `msDS-SupportedEncryptionTypes`, el cual indica los tipos de cifrado Kerberos que admite.

Para consultar esta propiedad en un equipo específico, podemos utilizar este comando de PowerShell:

Get-ADComputer -Identity "WBCNDC01" -Properties msDS-SupportedEncryptionTypes | Select-Object -ExpandProperty msDS-SupportedEncryptionTypes

Este comando obtiene la propiedad `msDS-SupportedEncryptionTypes` del equipo WBCNDC01, devolviendo un valor numérico que representa los tipos de cifrado compatibles.


Entendiendo msDS-SupportedEncryptionTypes


El atributo `msDS-SupportedEncryptionTypes` es un campo de bits (bitmask) que indica qué métodos de cifrado son compatibles. Los valores posibles son los siguientes:

0: No se admite el cifrado.
1: DES-CBC-CRC.
2: DES-CBC-MD5.
4: RC4-HMAC.
8: AES128-CTS-HMAC-SHA1-96.
16: AES256-CTS-HMAC-SHA1-96.
24: AES128 + AES256.
31: Todos los cifrados mencionados anteriormente.

Si el comando devuelve, por ejemplo, 24, significa que el equipo admite AES128 y AES256, pero no DES ni RC4. Si el valor devuelto es un número diferente a los mencionados, significa que se trata de una combinación de cifrados activados. Para determinar los cifrados habilitados, se puede analizar el valor como una suma de los valores de la tabla anterior.

Por ejemplo, si el resultado es 20, significa:

4: RC4-HMAC
16: AES256-CTS-HMAC-SHA1-96

Esto indica que el equipo admite RC4-HMAC y AES256, pero no AES128 ni DES.


Desglose automático


Para facilitar esta interpretación, podemos usar el siguiente script de PowerShell para desglosar el valor:

$encryptionTypes = @{
    1 = "DES-CBC-CRC"
    2 = "DES-CBC-MD5"
    4 = "RC4-HMAC"
    8 = "AES128-CTS-HMAC-SHA1-96"
    16 = "AES256-CTS-HMAC-SHA1-96"
}

$computer = Get-ADComputer -Identity "WBCNDC01" -Properties msDS-SupportedEncryptionTypes
$encryptionValue = $computer."msDS-SupportedEncryptionTypes"

Write-Host "El equipo admite los siguientes cifrados:"
foreach ($key in $encryptionTypes.Keys) {
    if ($encryptionValue -band $key) {
        Write-Host "- " $encryptionTypes[$key]
    }
}

Este script mostrará una lista detallada de los cifrados habilitados en el equipo consultado (WBCNDC01).


Modificar los tipos de cifrado admitidos


Si es necesario cambiar los tipos de cifrado admitidos en un equipo, se puede modificar el atributo `msDS-SupportedEncryptionTypes` con el siguiente comando de PowerShell:

Set-ADComputer -Identity "WBCNDC01" -Add @{msDS-SupportedEncryptionTypes=24}

En este caso, estamos estableciendo el valor 24, lo que habilita AES128 y AES256.


Conclusión


El comando `Get-ADComputer` permite obtener los tipos de cifrado Kerberos compatibles en un equipo de Active Directory, lo que es útil para garantizar la seguridad y compatibilidad de los sistemas.
0

miércoles, 1 de enero de 2025

Liberar espacio ocupado "fantasma" en Linux



Cómo encontrar y liberar espacio ocupado no presente en directorios en Linux.



Me he dado cuenta de que un servidor con un disco de 150 GB tenía 118 GB usados:

HOST # ip-10-250-7-164:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 7.9G 4.0K 7.9G 1% /dev/shm tmpfs 3.2G 8.8M 3.2G 1% /run tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup /dev/xvda3 150G 119 32G 80% / /dev/xvda2 20M 146K 20M 1% /boot/efi tmpfs 1.6G 0 1.6G 0% /run/user/1000

Mirando qué estaba ocupando este espacio veo:

HOST # du -h --max-depth=1 | sort -hr du: cannot access './proc/22284/task/22284/fd/4': No such file or directory du: cannot access './proc/22284/task/22284/fdinfo/4': No such file or directory du: cannot access './proc/22284/fd/3': No such file or directory du: cannot access './proc/22284/fdinfo/3': No such file or directory 32G . 19G ./var 5.8G ./srv 3.6G ./usr 2.1G ./home 591M ./opt 524M ./lib 321M ./run 106M ./boot 24M ./etc 15M ./tmp 9.0M ./sbin 8.5M ./lib64 7.3M ./root 744K ./bin 16K ./dev 8.0K ./CPAN 0 ./sys 0 ./selinux 0 ./proc 0 ./mnt

¿Dónde está el resto del espacio usado?

Si un proceso activo mantiene abierto un archivo que ha sido eliminado, el espacio sigue ocupado hasta que el proceso en cuestión se detenga.

Para encontrar estos archivos:

HOST # lsof | grep deleted nscd 628 nscd 10u REG 0,25 217032 860 /run/nscd/dbEp42mF (deleted) nscd 628 nscd 11r REG 0,25 217032 860 /run/nscd/dbEp42mF (deleted) nscd 628 651 nscd nscd 10u REG 0,25 217032 860 /run/nscd/dbEp42mF (deleted) nscd 628 651 nscd nscd 11r REG 0,25 217032 860 /run/nscd/dbEp42mF (deleted) ...

En este caso, se observa que el proceso nscd tiene archivos abiertos.
Para liberar el espacio usado por todos estos archivos, reinicio el servicio:

HOST # systemctl restart nscd

Hecho esto, el espacio usado de forma "fantasma" se ha liberado:

HOST # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 7.9G 4.0K 7.9G 1% /dev/shm tmpfs 3.2G 8.8M 3.2G 1% /run tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup /dev/xvda3 150G 32G 119G 22% / /dev/xvda2 20M 146K 20M 1% /boot/efi tmpfs 1.6G 0 1.6G 0% /run/user/1000

Si esto no hubiera funcionado, se podría reiniciar el servidor para liberar todo el espacio ocupado.
0