From 53c7bd7f95fd6e2189c954ba5c90bf4eb02602d0 Mon Sep 17 00:00:00 2001 From: Milton Gonzalez Date: Wed, 9 Sep 2026 23:35:43 -0500 Subject: [PATCH] docs: registra el cierre del incidente SMTP (certificado + Spamhaus XBL) Co-Authored-By: Claude Sonnet 5 --- PRODUCCION.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/PRODUCCION.md b/PRODUCCION.md index 43eb648..f682356 100644 --- a/PRODUCCION.md +++ b/PRODUCCION.md @@ -150,6 +150,42 @@ confirmado distinto en ambos), verificado contra `https://project.linkedcorp.net` (bundle nuevo servido, `GET /api/projects` sin token responde 401 como se espera). +## Cierre del incidente SMTP (2026-09-09) — certificado vencido + IP en Spamhaus XBL + +Con el host ya sin espacios (fix de v1.4.0), el boton de prueba seguia fallando con +`certificate has expired`. Investigacion completa en el servidor de correo (`192.168.222.10`, +iRedMail): + +- **Causa del certificado**: en `/etc/nginx/sites-available/00-default.conf` (puerto 80) el + `return 301 https://...` estaba directo en el bloque `server{}`, que en nginx se ejecuta en la + fase de *server rewrite* **antes** de evaluar `location` — por eso el reto ACME + `/.well-known/acme-challenge/` de certbot siempre terminaba redirigido a HTTPS, y ahi fallaba + contra NPM (sin certificado asignado para `mail.linkedcorp.net` en el 443, SNI rechazado). Fix: + mover el redirect dentro de `location / { return 301 ...; }` para que la ubicacion mas + especifica del challenge tenga prioridad. Certificado renovado con `certbot renew` + (valido hasta 2026-12-08); Postfix y Dovecot recargados (`systemctl reload`, sin cortar + conexiones). Backup del nginx original guardado junto al archivo en el servidor. +- **Causa de que Hotmail/Outlook rechazara igual**: la IP publica compartida de toda la red + (`186.3.190.7`, NAT de `192.168.222.0/24` — no exclusiva del correo) estaba listada en el + **XBL de Spamhaus** por una deteccion real de malware (`urlzone`/Bebloh, conexion a un C2, + ultima deteccion 2026-09-03). No era fuerza bruta ni relay de spam del correo. Delisting + pedido y confirmado por Spamhaus el mismo dia (autoservicio, `check.spamhaus.org`); no se logro + rastrear el dispositivo infectado especifico (el `filter.log` de pfSense solo retenia horas de + historial — se amplio a ~25 dias por si se repite). +- **Verificado end-to-end**: envio real via `testSmtpConfig` desde el propio backend de + produccion a Gmail y Hotmail, ambos confirmados recibidos (`{"sent":true}` + confirmacion + visual del usuario en Hotmail). +- **Endurecimiento aplicado de paso** (servidor de correo): `fail2ban` con `maxretry` 5->3, + `bantime` 1h->24h con escalado a 7 dias para reincidentes, jail `recidive` nuevo. Cuentas + `admin@`/`postmaster@linkedcorp.net` identificadas bajo ataque de fuerza bruta activo con clave + sin rotar desde su creacion (dic. 2024) — **pendiente que el superadmin rote esas claves**, no + se toco por no ser parte del alcance de este proyecto. +- Inventario completo de cuentas de correo del grupo (que app usa cada una, ultima actividad, + candidatas a borrar) documentado en `project-md-templates/CUENTAS_CORREO.md`. De paso se + encontraron y corrigieron dos apps de otros proyectos (`album-mundial-2026`, `linkedsign`) que + tenian `MAIL_TLS_REJECT_UNAUTHORIZED=false` como workaround del mismo certificado vencido — + revertido a `true` y servicios reiniciados una vez el certificado quedo renovado. + ## Actualizacion v1.6.0 (2026-09-09) — administradores por proyecto, Configuracion solo superadmin - Un proyecto puede tener uno o mas administradores (`role_in_project='admin'` en