Informatica Dantesca

martes, 14 de enero de 2025

Nginx (V) Autenticación LDAP(IV). Usando JWT, manejo de sesiones y TSL (https)

1. Usando JWT en Python. Normas generales

2. Manejo de sesiones en Python

3. Pasar el openrety a TSL (ssh)

Nginx (IV) Autenticación LDAP(III). Programa python para autenticación LDAP

1. Introducción

Tenemos que creare un programa para que verifique las credenciales de usuario y contraseña sobre el servidor LDAP

También debemos ponerlo en un servidor http para recibir dichos parámetros y devolver la autorización

2. Programa de autenticación LDAP (xmldap.py)

Veamos el código fuente:

La primera línea es de (Shebang #!) que indica el ejecutor del programa. Si en una ventana de comandos ejecutamos xmldap.py, ya sabe que python lo deber ejecutar, que es el de la ruda indicada en el shebang, que es la del entorno virtual que tiene todos los módulos necesarios instalados. (Pero en este caso no lo vamos a ehjecutar con el shebang, sino el fichero python del siguiente apartado)

El módulo que nos da toda la gracia de acceso a LDAP es ldap3 que hay que instalarlo con "pip install ldap3" desde el entorno virtual

La función getProps se encarga de leer el fichero de propiedades para aceder al fichero de parámetros del servidor LDAP

La función autheticateByLogin se encarga de acceder al servidor LDAP y autenticar el usuario con su contraseña.

Las demás funciones son para obtener información del sistem LDAP

#!/home/eduard/MyPython/05.fasthtml/venv_fasthtml/bin/python3

import pprint
from ldap3 import Server, Connection, ALL, ALL_ATTRIBUTES ,SAFE_SYNC, NTLM, ALL_ATTRIBUTES
import sys
import os
#------Imprescindible para poder importar de otras carpetas (de basicutils)
import sys
from pathlib import Path
#from ox import xmoxfrmdict2fasthtml as xmoxfrmdict2fasthtml
path_root1 = Path(__file__).parents[1] # Damos un salto de directorio hacia arriba-> ximoutilsmod
sys.path.append(str(path_root1))
path_root0 = Path(__file__).parents[0] # El mismo directorio
sys.path.append(str(path_root0))
from basicutils import xmcrypto, xmfile
# ------Fin imprescindible


def getProps():
	logs=[]
	logs.append('env='+str(os.environ))
	logs.append('os.getenv("CONF_PYTHON")='+str(os.getenv("CONF_PYTHON")))
	xmfile.addLinesToFile('/home/eduard/kk.log', logs)
	confFile=os.getenv("CONF_PYTHON")+'ldap.encrypted.yml'
	config= xmcrypto.getPropertiesFromFile(confFile)
	return config['ldapWindows']

'''Autheticate by login name and password'''
def autheticateByLogin(usename: str, password: str)->bool:
	config=getProps()
	try:
		server = Server(config['serverName'], get_info=ALL)
		myUser=config['userPrefix']+usename
		conn = Connection(server, user=myUser, password=password)
		if conn.bind():
			return True
		else:
			return False
	except Exception as e:
		print(f"LDAP error: {e}", file=sys.stderr)
		if 'conn' in locals():
			conn.unbind()
		return False
	
def getConn()->Connection:
	conn=None; config=None; baseDN=None
	try: 
		config=getProps()
		baseDN=config['dn'][config['dn'].find("DC="):]
		server = Server(config['serverName'], get_info=ALL)
		conn = Connection(server, user=config['dn'], password=config['password'], auto_bind=True)
		return conn, config, baseDN
	except Exception as e:
		print(f"LDAP error: {e}", file=sys.stderr)
		if 'conn' in locals():
			conn.unbind()
		return conn, config, baseDN
	
'''Get all login names from LDAP'''
def getAllLogins()->list:
	try:
		conn, config, baseDN=getConn()
		#conn.search(baseDN, '(&(objectclass=user) (sAMAccountName=*))',attributes=ALL_ATTRIBUTES)
		conn.search(baseDN, '(&(objectclass=person) (sAMAccountName=*))',attributes=['sAMAccountName'])
		entries=conn.entries
		return [str(e['sAMAccountName']) for e in entries]
		
	except Exception as e:
		print(f"LDAP error: {e}", file=sys.stderr)
		if 'conn' in locals():
			conn.unbind()
		return []

'''Get all DNs from LDAP'''
def getAllDNs()->list:
	try:
		conn, config, baseDN=getConn()
		conn.search(baseDN, '(&(objectclass=user) (sAMAccountName=*))',attributes=[])
		#conn.search(baseDN, '(&(objectclass=person) (sAMAccountName=*))',attributes=['DN'])
		entries=conn.entries
		#pprint.pprint(entries)
		print(str(entries[0]))
		return [str(e)[:str(e).find(" - STATUS:")].replace('DN: ','')for e in entries]
		
		
	except Exception as e:
		print(f"LDAP error: {e}", file=sys.stderr)
		if 'conn' in locals():
			conn.unbind()
		return []


			
if __name__ == "__main__":
	if len(sys.argv) != 3:
		print("Usage: authenticate.py <username> <password>")
		sys.exit(1)

	username = sys.argv[1]
	password = sys.argv[2]
	#print(f"username: {username}, password: {password}")

	'''
	print(getAllDNs())
	print (getAllLogins())
	print(autheticateByLogin(username, password))
	print(autheticateByLogin(username, password+'a'))
	print(autheticateByLogin(username+'a', password))
	'''

	if autheticateByLogin(username, password):
		print("OK")
	else:
		print("FAIL")

3. Programa python en fastapi para que ejecute un servidor uvicorn que reciba los parámetros y autentique (xmopenresty.py)

Cabe destacar :

La línea que llama a FastAPI (app = FastAPI())
Las clases AuthRequest y AuthResponse que encapsulan la entrada y salida de datos
La ruta POST /auth que es la que se encarga de contestar las peticiones de autenticación
El arranque del servidor uvicorn en l IP 127.0.0.1 y el puerto 5000

Veamos el código:

#!/home/eduard/MyPython/05.fasthtml/venv_fasthtml/bin/python3

# auth_service.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import uvicorn

import os
import sys
import base64

#------Imprescindible para poder importar de otras carpetas (de basicutils)
import sys
from pathlib import Path
#from ox import xmoxfrmdict2fasthtml as xmoxfrmdict2fasthtml
path_root1 = Path(__file__).parents[1] # Damos un salto de directorio hacia arriba-> ximoutilsmod
sys.path.append(str(path_root1))
path_root0 = Path(__file__).parents[0] # El mismo directorio
sys.path.append(str(path_root0))
from basicutils import xmldap
# ------Fin imprescindible

app = FastAPI()

class AuthRequest(BaseModel):
    username: str
    password: str

class AuthResponse(BaseModel):
    authenticated: bool

def authenticate(username: str, password: str) -> bool:
    """
    Your existing authentication function.
    Replace this implementation with your actual authentication logic.
    """
    # Example implementation
    #if username == "admin" and password == "secret":
    #    return True
    #return False
    return xmldap.autheticateByLogin(username, password)

@app.post("/auth", response_model=AuthResponse)
async def auth(request: AuthRequest):
    is_valid = authenticate(request.username, request.password)
    return AuthResponse(authenticated=is_valid)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=5000)

Para ejecutarlo, hay que ir a un ventana de comandos y introducir

cd ruta-mdulos-python
./xmopenresty.py

Pues como está el shebang, ya sabe que python utilizará para su ejecución

viernes, 10 de enero de 2025

Ubuntu enviroment variables. Formas de crearlas

Existen tres formas principales de configurar variables de entorno en Ubuntu:

Usar el comando export en la terminal para variables temporales.
Editar el archivo /etc/environment para variables permanentes de todo el sistema
Crear un shell script en la carpeta /etc/profile.d/ específicico del usuario.
El archivo ~/.profile.
El archivo ~/.bashrc.

viernes, 3 de enero de 2025

Nginx (II) Autenticación LDAP(I). Sustituir NGINX por openresty. Luaroks y Lua script

1. Introducción

Openresty es un nginx que lleva incorporado Lua, que es un lenguaje de script para Nginx creado por la Universidad Católica Pontificia de Rio de Janeiro en Brasil que es rápido y utiliza pocos recursos.

2. Instalación de openresty

Veamos los pasos a realizar:

#1. Bloquear nginx

sudo systemctl disable nginxsudo systemctl stop nginx

#2. Instalar prerequisitos
sudo apt-get -y install --no-install-recommends wget gnupg ca-certificates lsb-release

#3. Importar la clave GPG de descarga (para Ubuntu 22 +)
wget -O - https://openresty.org/package/pubkey.gpg | sudo gpg --dearmor -o /usr/share/keyrings/openresty.gpg

#4. Añadir el repositorio en sistemas x86_64 or amd64 para Ubuntu 22 +
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/openresty.gpg] http://openresty.org/package/ubuntu $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/openresty.list > /dev/null

#5. Actualizar el índice APT
sudo apt-get update

#6. Instalar el paquete
sudo apt-get -y install openresty

#7. Verificar la instalación que debe devolver: nginx version: openresty/X.Y.Z
openresty -v

#8. Arrancar/rearrancar/ pararel servicio
sudo systemctl start openresty
sudo systemctl restart openresty
sudo systemctl stop openresty

#9. Permitir el servicio al arrancar (boot)
sudo systemctl enable openresty

#10. Ver el estado del servicio
sudo systemctl status openresty

Ojo, ahora el fichero de configuración esta en una de estas 2 carpetas:
/etc/openresty
/usr/local/openresty
Y los logs están en:
/usr/local/openresty/nginx/logs/error.log

4. Instalación de luarocks

Luarocks es un paquete de instación de módulos Lua para openresty

Para instalarlo hacemos:

# 1.Prerequisitos
sudo apt install build-essential libreadline-dev unzip

# 2. Descargar
curl -R -O http://www.lua.org/ftp/lua-5.3.5.tar.gz

# 3. Descomprimir
tar -zxf lua-5.3.5.tar.gz

# 4. Compilar
cd lua-5.3.5
make linux test
sudo make install

Veamos algunos usos de luarock

# 1.Instalar paquetes.
# En este caso instala el paquete lua-python para poder ejecutar modulos python
sudo luarocks install lua-python --check-lua-versions

sudo luarocks install lua-resty-http

sudo luarocks install lua-resty-openssl

# 2. Ver los módulos instalados
luarocks list

# Devuelve
#Rocks installed for Lua 5.1
#---------------------------
#
#lua-resty-http
#   0.17.2-0 (installed) - /usr/local/lib/#luarocks/rocks-5.1
#
#lua-resty-lrucache
#   0.09-2 (installed) - /usr/local/lib/#luarocks/rocks-5.1
#
#lua-resty-openssl
#   1.5.1-1 (installed) - /usr/local/lib/#luarocks/rocks-5.1
#

5. Lua script

Con Lua se pueden generar scripts de :

Autenticación con JWT, LDAP o OAuth2
Enrutamiento (Routing) dinámico basado en headers, cookies o contenido del body del request
Caching Personalizado
Rate limiting. Contruir lógica rate-limiting basada en IP, user agent (navegador), etc
Transformación del contenido para generar respuestas dinámicas (compresión, conversión, etc)
API Gateways como validación de request, filtrado de respuestas i logging (bitácora)

OJO: Los comentarios en lua se encabezan con "--" y no con "#" (como nginx)

En Lua hay varios módulos que podemos instalar (y algunos ya vienen instalados)

ngx_lua: Core module for embedding Lua in OpenResty.
lua-resty-core: Standard Lua library optimized for OpenResty.
lua-resty-http: Make HTTP requests from within OpenResty.
lua-resty-jwt: Validate and decode JSON Web Tokens (JWT).
lua-resty-redis: Connect to Redis for caching or session management.

Veamos algunos ejemplos de Lua como contenido dinámico y enrutado dinámico

server {
    listen 8080;

    #1. Creación de contenido.
    #   Cuando se accede a http://localhost:8080/hello:
    #   devuelve "Hello Word"

    location /hello {

        content_by_lua_block {
            ngx.say("Hello, World!")
        }
    }

    #2. Redirección dinámica en base al navegador (si es "curl" u otro)

    #   Cuando se accede a http://localhost:8080/route:
    #   te envía a http://localhost:8080/for-curl si operas en "curl"
    #   y sinó te envia a http://localhost:8080/for-browser

    
    location /route {
        content_by_lua_block {
            local user_agent = ngx.var.http_user_agent
            if user_agent and user_agent:find("curl") then
                ngx.redirect("/for-curl", 302)
            else
                ngx.redirect("/for-browser", 302)
            end
        }
    }
}

Veamos un caso concreto que opera con autenticación JWT. Aquí cabe destacar la clave secreta "your_jwt_secret", el control de las cabeceras o header

server {
    listen 8080;

    location /protected {
        access_by_lua_block {

            -- Importamos el módulo lua-resty-jwt que debe estar previamente instalado
            local jwt = require "resty.jwt"
            local auth_header = ngx.var.http_Authorization

            if not auth_header or not auth_header:find("Bearer ") then
                ngx.status = ngx.HTTP_UNAUTHORIZED
                ngx.say("Missing or invalid Authorization header")
                return ngx.exit(ngx.HTTP_UNAUTHORIZED)
            end

            local token = auth_header:sub(8)  -- Remove "Bearer "

            --- "your_jwt_secret" es la clave secreta para verificar la firma del token
            local jwt_obj = jwt:verify("your_jwt_secret", token)

            if not jwt_obj.verified then
                ngx.status = ngx.HTTP_UNAUTHORIZED
                ngx.say("Unauthorized: " .. (jwt_obj.reason or "unknown reason"))
                return ngx.exit(ngx.HTTP_UNAUTHORIZED)
            end
        }

     content_by_lua_block {
            ngx.say("Access Granted!")
        }
    }
}

Para llamar con curl usando JWT se puede hacer con curl y dando un Bearercon el token JWT:

curl http://localhost:8080/protected -H "Authorization: Bearer <your-jwt-token>"

Vewamos

1. Introducción

Se puede utilizar el módulo adicional ngx_http_auth_request_module, pero se necesita una versión de nginx precompilada con este módulo adicional. Para Ubuntu se podría instalar nginx-extras. Pero da muchos problemas. Para ello se ha optado por configurar nginx para que uilizando fastCGI consulte un script python para autenticar usuarios sobre LDAP.

Supongamos que ya tenemos instalado python y un entorno virtual. Instalaremos pues nginx y fcgiwrap

# 1. Instalar paquetes requeridos
sudo apt update
sudo apt install nginx fcgiwrap

# 2. Verificar la versión de nginx instalada (en este caso 1.24.0 (Ubuntu)

nginx -v

# 3. Como curisidad si queremos mostra los módulos instalados en nginx
nginx -V 2>&1|xargs -n1|grep module

2. Configurar fcgiwrap

Ejecutar

# 1. Arrancar el sercicio
sudo systemctl enable fcgiwrap
sudo systemctl start fcgiwrap

# 2. Verificar el servicio
systemctl status fcgiwrap

3. Crear el script python de un fake autenticathor

Veamos este código propuesto por ChatGPT.

Observar que la primera línea es el "shebang" que indica el intérprete que va utilizar para ejecutarlo. En este caso, utilizamos el python3 que se encuenttra en el entorno virtual creado

Si le pasamos admin + secret nos deja pasar

#!/home/edu/MyPython/05.fasthtml/env05/bin/python3

import os
import cgi

print("Content-Type: text/plain\n")

# Simulated authentication logic
form = cgi.FieldStorage()
username = form.getvalue("username")
password = form.getvalue("password")

if username == "admin" and password == "secret":
    print("Authentication successful")
else:
    print("Authentication failed")

Hay que dar permiso de ejecución a todo el mundo

sudo chmod +x /home/edu/MyPython/05.fasthtml/basicutils/xmlogin.py

2. Configurar nginx

Según CHATGPT esto sirve: para el fichero /etc/nginx/nginx.conf

http {

    server {
        listen 8001;
        server_name localhost;

        location /auth {
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME /home/edu/MyPython/05.fasthtml/basicutils/xmlogin.py;
            fastcgi_pass unix:/var/run/fcgiwrap.socket;
        }
    }
}

Y aclara:

Explicación de la configuración:

ldap_server my_ldap_server:
- Define un servidor LDAP con el nombre my_ldap_server.
- url: Especifica la URL del servidor LDAP. En este caso, ldap://municipio-dc-03.edificio.municipio:389.
  - dc=edificio,dc=municipio: Indica la base de búsqueda en el árbol LDAP.
  - ?uid: Especifica el atributo de búsqueda del usuario (generalmente uid o cn).
  - ?sub: Define el alcance de la búsqueda (sub para buscar recursivamente en subárboles).
  - (objectClass=person): Filtro para encontrar objetos LDAP que representan usuarios.
binddn y binddn_passwd:
- Credenciales usadas por Nginx para consultar el servidor LDAP.
auth_ldap y auth_ldap_servers:
- Habilita la autenticación LDAP en el bloque de ubicación.

3. Proteger rutas específicas

En este ejemplo, solo las solicitudes al directorio /protected requieren autenticación LDAP. Si la autenticación es exitosa, el usuario puede acceder; de lo contrario, se muestra un desafío de autenticación.

Pruebas y solución de problemas

Revisar los logs:
- Logs de acceso: /var/log/nginx/access.log
- Logs de error: /var/log/nginx/error.log
Asegurar conectividad con el servidor LDAP:
- Probar la conexión desde el servidor donde está Nginx (escribiendo en una sola línea):

ldapsearch -H

   ldap://municipio-dc-03.edificio.municipio

   -D "cn=Ximo Dante,ou=SISTEMAS,ou=USUARIOS IMPORTANTES,dc=edificio,dc=municipio"

   -w "mi_contraseña"

   -b "dc=edificio,dc=municipio"

Supongamos que

Depurar errores comunes:
- Credenciales incorrectas:
- URL LDAP incorrecta: Verificar que el servidor LDAP y la base DN sean correctos.

Conclusión

Usar LDAP con Nginx es posible con el módulo adecuado, como ngx_http_auth_ldap_module o la solución comercial de Nginx Plus. Este enfoque permite autenticar usuarios centralmente mediante un servidor LDAP, lo cual es útil en entornos empresariales.

----------------------------------------------------------------------------------------

1. Introducción

Se puede utilizar el módulo adicional ngx_http_auth_request_module, pero se necesita una versión de nginx precompilada con este módulo adicional. Para Ubuntu se podría instalar nginx-extras pero da problemas. Para ello utilizamos una ruta alternativa, compilando el módulo

sudo apt install nginx-extras #DA PROBLEMAS PUES NO RECONOCE EL SERVICIO LDAP

sudo apt update
sudo apt upgrade

# Install requiered packages

sudo apt install build-essential libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev git

# Download nginx versison 1.27.3

wget http://nginx.org/download/nginx-1.27.3.tar.gz
tar -xzvf nginx-1.27.3.tar.gz
cd nginx-1.27.3

# Clone LDAP Module

git clone https://github.com/kvspb/nginx-auth-ldap.git

# Configure Nginx with the LDAP Module

./configure --add-module=./nginx-auth-ldap --with-http_ssl_module --with-http_v2_module

# Compile and Install Nginx:

make
sudo make install

# Verify Installation: Check the installed Nginx binary for the LDAP module:
/usr/local/nginx/sbin/nginx -V

Nginx (I) Introducción

1. Introducción

Esto es un resumen de Saquib Khan

Nginx es:

Non threaded (en contra de los servidores web tradicionales que son multi-threaded)
Dirigido por eventos
Permite manejar más conexiones simultáneas más de 10.000 peticiones concurrentes
Es apropiado para sitios web de alto tráfico.
Puede actuar como balaceador de cargas
Cacheador de request HTTP, reduciendo el tiempo de carga y mejorando la respuesta
Reverse proxy, pwermitiendo el balanceo de carga delos servidores.
API gateway, manejando y enrutadno las request por API.
Servidor de ficheros estáticos (imágenes, vídeos etc)
Manejo SSL (certificados, conexiones segurasa los usuarios)

2. Forward Proxy y Reverse Proxy

Hemos dicho que Nginx es reverse proxy. Veamos la diferencia respecto a un Forward proxy

Forward Proxy se caracteriza por:

El proxy está entre el cliente y el servidor. El cliente envia la petición al proxy y este al servidor.
El servidor se desvincula del cliente, intereactuando solo con el proxy. Esto permite la privacidad y superar las restricciones geográficas. (VPN es un ejemplo)

Reverse Proxy se caracteriza por:

Se situa entre el cliente y múltiples servidores, decidiendo que server va a recibir el request.
El cliene desconoce que servidor le contesta.
Los criterios de selección de servidores pueden ser por la ruta (por ejemplo /admin se entruta al servidor 1 y /settings al servidor 2). Es decir se predefinen reglas para la redirección de servidores.

3. Instalación de nginx

Si lo instalamos en docker

# 1. Instalar Ubuntu en un contenedor docker usando el puerto 8080 de la máquina local y el puerto 80 del contenedor
docker run -it -p 8080:80 ubuntu

# 2. Instalar nginx
apt-get update
apt-get install nginx

# 3. Verificar la instalación
nginx -v

Si lo instalamos en la máquina local

# 1. Instalar nginx en Ubuntu
sudo apt update
sudo apt install nginx

# 2. Arrancar nginx
sudo systemctl start nginx

# 3. Verificar 
sudo systemctl status nginx

4. Entender el fichero de configuración nginx.conf

Este fichero se encuenta en /etc/nginx/nginx.conf

Veamos el contenido de un fichero ejemplo:

worker_processes auto;

events {
    worker_connections 1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    server {
        listen       80;
        server_name  localhost;

        location / {
            root   /usr/share/nginx/html;
            index  index.html index.htm;
        }
    }
}

Veamos las claves:

worker_processes auto;

Un worker process se encarga del manejo de las peticiones. Con la opción auto dejamos enmanos de nginx que cree el número de workers en base a los cores de la CPU

events { worker_connections 1024; }

events indica la configuración del manejo de conexiones. worker_connections 1024; indica que cada worker puede manejar hasta 1024 conexiones simultáneas.

http {...}

Define la configuracion del manejo de las request HTTP

include mime.types;

Le indica a nginx la inclusión del fichero mime.types que mapea la extensión de un fichero a los tipos MIME. Por ejemplo .html como text/html, .jpg como image/jpeg )

default_type application/octet-stream;

Si no se puede obtener el tipo mime de un fichero, se utilizará por omisión application/octet-stream que significa "descargar este fichero"

sendfile on;

Para utilizar la llamada del sistema"sendfile" que permite el copiado de ficheros entre servidores o redes sin utilizar passar por los buffers de la memoria del usuario. Ver CocCoc Techblog

keepalive_timeout 65;

Determina el tiempo que una conexión estará abierta en segundos antes que nginx la cierre. Por defecto son 65 segundos

5. La parte más importante de nginx.conf: server

server

Para configurar un servidor virtual, por ejemplo un servidor que maneja la "request"para un dominio específico i una dirección IP

Repitamos esta parte:

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
}

listen 80;

Le indica a nginx que escuche las peticiones del puerto 80. Sabemos que el puerto 80 es el puerto por omisión para HTTP

server_name localhost;

indica el nombre de dominio que este bloque de configuración del servidor va a responder. localhost se usa para test local, pero en producción se debe reemplazar por el dominio (por ejemplo example.com)

location / { ... }

Indica como responder a diferentes URIs de la "request". "/" indica que este bloque manejará las las "request" de la URL root . En este caso http:/localhost/ pues el server_name del punto anterior es localhost

root /usr/share/nginx/html;

La directiva root indica la carpeta donde nginx buscará los ficheros a servir. En este caso /usr/share/nginx/html que es la carpeta donde nginx guarda los ficheros HTML por omisión.

index index.html index.htm;

Cuando la request apunta a un directorio sin indicar un fichero de dicho directorio, entonces nginx buscará un fichero llamado index.html o index.htm dentro de dicho directorio para servirlo

6. Configuración básica de prueba de nginx

Supongamos que creamos este fichero para probar nginx ( /etc/nginx/nginx.conf). Ojo hacer una copia de seguridad del fichero anterior.

events {
}

http {
    server {
        listen 80;
        server_name _;  # This means it will respond to any server name
        location / {
            return 200 "Hello from Nginx Conf File";
        }
    }
}

Con esto, cualquier petición a cualquier servidor va a responder "Hello from Nginx Conf File"

pero hay que hacer un

nginx -s reload

Si creamos un directorio llamado /www/data y dentro de el creamos el fichero index.html

mkdir -p /www/data
echo "<h1>Welcome to Nginx</h1>" > /www/data/index.html

Podemos modificar la parte server del fichero nginx.conf con el posterior nginx -s reload para que muestre el contenido del fichero /www/data/index.html que es "<h1>Welcome to Nginx</h1>" . La "request" que debemos realizar es http://localhost:8080 que es la que apunta a "/"

server {
    listen 80;
    server_name localhost;
    root /www/data;

    location / {
        try_files $uri $uri/ =404;
    }
}

Observar que $uri es la ruta del recurso por ejemplo http://example.com/path/to/resource, $uri sería /path/to/resource.

7. Los bloques Server, Location y Upstream

Como se vió, el bloque server define lac onfiguracion para un dominio particular o dirección IP.

El bloque location define como responder a las URIs de "requests" específicas, por ejemplo:

location /images/ {
    root /var/www/images;
}

que indica que para un servidor específico cuando accedemos a /images nos servirá los fichero de la carpeta /var/www/images

El bloque upstream define un grupo de servidores backend (segundo plano) para el balanceo de cargas, por ejemplo:

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
}

8. Reverse Proxy

Veamos unaconfiguración como reverse proxy

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_server;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

proxy_pass http://backend_server;

Para pasar la "request" a http://backend_server o sea backend_server va a ser el servidor encargado de responder a la "request"

proxy_set_header Host $host;

Asegura que el "header" del host original es pasado al servidor backend_server. La variable $host representa el valor del encabezado Host original de la "request" del cliente. Si elencabezado Hos noesta presente en la "request" toma el nombre sel servidor definido en server_name (en este caso example,.com) o dirección IP del servidor

proxy_set_header X-Real-IP $remote_addr;

Envía la dirección IP real del cliente al servidor de destino.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Agrega la dirección IP del cliente a la lista de encabezados X-Forwarded-For ,que es usado por el backend para identificar la IP original del cliente

9. Balanceo de carga

Veamos este ejemplo:

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
    }
}

upstream backend { ... }

Define la lista se servidores backend

server backend1.example.com;

Añade dicho servidor a la lista de backend servers

proxy_pass http://backend;

Redirige la "request" a uno de los servidores de la lista de servidores backends

10. Securizando con SSL/TLS

Este protocolo encripta la transmisión entre cliente y servidor. Veamos como se configura:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    location / {
        root /var/www/html;
        index index.html;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Vemos que aparecen dos bloques server, uno para ssl (https) y otro http

listen 443 ssl;

Indica que utilice escuche el puerto 443 (por defecto el de https) con SSL habilitado

ssl_certificate /etc/nginx/ssl/example.com.crt;;

indica la ruta del certificado del servidor a utilizar por nginx

ssl_certificate_key /etc/nginx/ssl/example.com.key;

Indica la ruta donde está la clave del certificado de servidor

return 301 https://$host$request_uri;

return sirve para redirigir.

301 és el código de estado HTTP que indica Redirección permanente, indicando al navegador del cliente que el recurso solicitado se ha movido ae manera permanente a una nueva dirección.

https://$host$request_uri redirige al cliente a la misma dirección pero utilizando el protocolo https.

$host representa elbombre del host (en este caso example.com)

$request_uri incluye la ruta completa y los parámetros de la solicitud original, asegurando que la redirección sea precisa

11. Cacheando

Nginx puede cachear las respuestas del servidor backend para acelerar los tiempos de respuesta para posteriores "requests"

Por ejemplo:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;

proxy_cache_path

Establece la carpeta y configuración para el caché, en este caso /var/cache/nginx

levels=1:2

Define la estructura del directorio para la caché. La estructura tendrá:

1 nivel con un subdirectorio de 1 carácter
2 niveles adicionales con subdirectorios de 2 caracteres cada uno

Con ello se distribuyen los archivos en múltiples directorios, evitando tener muchos archivos en una sola carpeta

keys_zone=my_cache:10m

Crea una zona de memoria compartida llamada my_cache con 10 MB de memoria. Esta zona compartida se utiliza para almacenar metadatos de los objetos de caché como claves y tiempos de expiración

max_size=1g

Limita el tamaño máximo a 1 GB. Cuando se alcanze este límite , se eliminan los objetos menos utilizados (uando el algoritmo LRU, "Least Reacently Used"

inactive=60m

Elimina los elementos del caché si no se ha accedido a ellos durante 60 minutos

12. Monitoreando y logging

Nginx hace una bitácora (log) de todas las peticiones y errores, permitiendo el control de errores (troubleshooting) y monitoreo

En este ejemplo:

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

log_format main ...

Define un formato a medida de bitácora llamado main

Siendo:

$remote_addr la dirección IP del cliente que realizó el "request"

$remote_user el nombre del usuario autenticado si se utilizó la autenticación HTTP. Sinó se ha autenticado queda vacío

[$time_local] La hora local en que se realizó la petición en formato [día/mes/año:hora:minuto:segundo zona_horaria]

"$request" La solicitud HTTP completa, incluyendo el método (GET, POST...), el URI, y la versionb del protocolo, por ejemplo: GET /index.html HTTP/1.1

$status el código del estado devuelto, por ejemplo 200, 404, 500

$body_bytes_sent el número de bytes enviados al cliente, excluyendo los encabezados de respuesta.

"$http_referer" el encabezado Referer enviado por el cliente, que indica la página que ha visitado el cliente previamente para acceder al sitio actual.Si no hay un referer, queda vacío.

"$http_user_agent" el encabezado User-Agent, que identifica al cliente (por ejemplo, un navegador o una herramienta de línea de comandos).

"$http_x_forwarded_for" el encabezado X-Forwarded-For, que contiene las direcciones IP de los clientes originales en caso de que Nginx actúe como un proxy inverso. Si no existe este encabezado, queda vacío.

access_log /var/log/nginx/access.log main;

Almacena la bitácora de accesos en el fichero especificado (/var/log/nginx/access.log main) usando el formato de log definido como main

Veamos este ejemplo, donde un cliente con la dirección 192.168.1.1 accedeal recurso /index.html. Entonces se tendría una entrada como esta en el fichero de registro

192.168.1.1 - - [03/Jan/2025:12:34:56 +0000] "GET /index.html HTTP/1.1" 200 1024 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" "-"

Siendo:

192.168.1.1: Dirección IP del cliente.

-: Sin usuario autenticado.

[03/Jan/2025:12:34:56 +0000]: Fecha y hora de la solicitud.

"GET /index.html HTTP/1.1": Solicitud HTTP realizada.

200: Código de estado HTTP.

1024: Bytes enviados al cliente (excluyendo encabezados).

"-": Sin Referer.

"Mozilla/5.0 (Windows NT 10.0; Win64; x64)": User-Agent del cliente.

"-": Sin encabezado X-Forwarded-For

Los errores típicos que se reciben son:

400 Bad Request, 401 Unauthorized, 403 Forbidden, y 404 Not Found: Errores del cliente.

500 Internal Server Error, 502 Bad Gateway, y 503 Service Unavailable: Errores del servidor.

13. Códigos de estado típicos

En general los códigos de error típicos que se pueden obtener son:

1xx - Respuestas informativas

Indican que la solicitud fue recibida y el servidor está procesándola.

100 Continue: El cliente puede continuar con su solicitud.

101 Switching Protocols: El servidor acepta cambiar a un protocolo diferente solicitado por el cliente.

103 Early Hints: El servidor envía encabezados preliminares antes de la respuesta final.

2xx - Éxito. La solicitud se procesó correctamente.

200 OK: La solicitud fue exitosa y el servidor devolvió el contenido solicitado.

201 Created: La solicitud fue exitosa y se creó un nuevo recurso.

202 Accepted: La solicitud fue recibida, pero su procesamiento no ha concluido aún.

204 No Content: La solicitud fue exitosa, pero no hay contenido que devolver.

206 Partial Content: Se devuelve parte del contenido solicitado, usado en solicitudes con rangos.

3xx - Redirecciones. Indican que el cliente debe tomar medidas adicionales para completar la solicitud.

301 Moved Permanently: El recurso solicitado se ha movido de manera permanente a una nueva URL.

302 Found: El recurso se encuentra temporalmente en una ubicación diferente.

303 See Other: La respuesta está disponible en una URL diferente (usado después de una solicitud POST para redirigir a una página de confirmación).

304 Not Modified: Indica que el recurso no ha cambiado desde la última vez que fue solicitado (usado con caché).

307 Temporary Redirect: La redirección es temporal y debe usar el mismo método HTTP.

308 Permanent Redirect: Similar a 301, pero obliga a usar el mismo método HTTP.

4xx - Errores del cliente. Indican que la solicitud del cliente contiene un error.

400 Bad Request: La solicitud no es válida debido a un error de sintaxis.

401 Unauthorized: El cliente no está autenticado (requiere credenciales).

403 Forbidden: El cliente no tiene permisos para acceder al recurso.

404 Not Found: El recurso solicitado no existe en el servidor.

405 Method Not Allowed: El método HTTP usado no está permitido para el recurso.

408 Request Timeout: El servidor agotó el tiempo de espera para la solicitud.

409 Conflict: Hay un conflicto con el estado actual del recurso (por ejemplo, datos duplicados).

410 Gone: El recurso ya no está disponible y no se sabe su ubicación.

413 Payload Too Large: El cuerpo de la solicitud supera el límite permitido por el servidor.

414 URI Too Long: El URI de la solicitud es demasiado largo para ser procesado.

429 Too Many Requests: El cliente ha enviado demasiadas solicitudes en un tiempo determinado (límite superado).

5xx - Errores del servidor. Indican que el servidor falló al procesar la solicitud.

500 Internal Server Error: Error genérico cuando el servidor encuentra una condición inesperada.

501 Not Implemented: El servidor no soporta la funcionalidad requerida.

502 Bad Gateway: El servidor recibió una respuesta inválida de un servidor upstream.

503 Service Unavailable: El servidor no está disponible temporalmente, generalmente por mantenimiento o sobrecarga.

504 Gateway Timeout: El servidor upstream no respondió a tiempo.

505 HTTP Version Not Supported: El servidor no soporta la versión del protocolo HTTP usada en la solicitud.

Suscribirse a: Entradas ( Atom )

Informatica Dantesca

Páginas

martes, 14 de enero de 2025

Nginx (V) Autenticación LDAP(IV). Usando JWT, manejo de sesiones y TSL (https)

Nginx (IV) Autenticación LDAP(III). Programa python para autenticación LDAP

1. Introducción

2. Programa de autenticación LDAP (xmldap.py)

3. Programa python en fastapi para que ejecute un servidor uvicorn que reciba los parámetros y autentique (xmopenresty.py)

viernes, 10 de enero de 2025

Ubuntu enviroment variables. Formas de crearlas

viernes, 3 de enero de 2025

Nginx (II) Autenticación LDAP(I). Sustituir NGINX por openresty. Luaroks y Lua script

1. Introducción

2. Instalación de openresty

Ojo, ahora el fichero de configuración esta en una de estas 2 carpetas:
/etc/openresty
/usr/local/openresty
Y los logs están en:
/usr/local/openresty/nginx/logs/error.log

4. Instalación de luarocks

5. Lua script

Vewamos

1. Introducción

2. Configurar fcgiwrap

3. Crear el script python de un fake autenticathor

Hay que dar permiso de ejecución a todo el mundo

sudo chmod +x /home/edu/MyPython/05.fasthtml/basicutils/xmlogin.py

2. Configurar nginx

Explicación de la configuración:

3. Proteger rutas específicas

Pruebas y solución de problemas

Conclusión

1. Introducción

Nginx (I) Introducción

2. Forward Proxy y Reverse Proxy

3. Instalación de nginx

4. Entender el fichero de configuración nginx.conf

5. La parte más importante de nginx.conf: server

6. Configuración básica de prueba de nginx

7. Los bloques Server, Location y Upstream

8. Reverse Proxy

9. Balanceo de carga

10. Securizando con SSL/TLS

11. Cacheando

12. Monitoreando y logging

13. Códigos de estado típicos

Páginas

martes, 14 de enero de 2025

Nginx (V) Autenticación LDAP(IV). Usando JWT, manejo de sesiones y TSL (https)

Nginx (IV) Autenticación LDAP(III). Programa python para autenticación LDAP

1. Introducción

2. Programa de autenticación LDAP (xmldap.py)

3. Programa python en fastapi para que ejecute un servidor uvicorn que reciba los parámetros y autentique (xmopenresty.py)

viernes, 10 de enero de 2025

Ubuntu enviroment variables. Formas de crearlas

viernes, 3 de enero de 2025

Nginx (II) Autenticación LDAP(I). Sustituir NGINX por openresty. Luaroks y Lua script

1. Introducción

2. Instalación de openresty

Ojo, ahora el fichero de configuración esta en una de estas 2 carpetas:/etc/openresty/usr/local/openrestyY los logs están en:/usr/local/openresty/nginx/logs/error.log

4. Instalación de luarocks

5. Lua script

Vewamos

1. Introducción

2. Configurar fcgiwrap

3. Crear el script python de un fake autenticathor

Hay que dar permiso de ejecución a todo el mundosudo chmod +x /home/edu/MyPython/05.fasthtml/basicutils/xmlogin.py2. Configurar nginx

Explicación de la configuración:

3. Proteger rutas específicas

Pruebas y solución de problemas

Conclusión

1. Introducción

Nginx (I) Introducción

2. Forward Proxy y Reverse Proxy

3. Instalación de nginx

4. Entender el fichero de configuración nginx.conf

5. La parte más importante de nginx.conf: server

6. Configuración básica de prueba de nginx

7. Los bloques Server, Location y Upstream

8. Reverse Proxy

9. Balanceo de carga

10. Securizando con SSL/TLS

11. Cacheando

12. Monitoreando y logging

13. Códigos de estado típicos

Ojo, ahora el fichero de configuración esta en una de estas 2 carpetas:
/etc/openresty
/usr/local/openresty
Y los logs están en:
/usr/local/openresty/nginx/logs/error.log

Hay que dar permiso de ejecución a todo el mundo

sudo chmod +x /home/edu/MyPython/05.fasthtml/basicutils/xmlogin.py

2. Configurar nginx