Cómo se rompen y se reparan los sistemas reales.

Un nodo validador combina tres planos que normalmente se diseñan por separado: red P2P, almacenamiento de cadena y firma criptográfica. Un atacante puede aspirar a degradar cualquiera de ellos. Saturar el plano P2P con pares maliciosos provoca eclipse attacks; saturar el almacenamiento con bloques mal formados fuerza re-validación costosa; comprometer el plano de firma equivale a comprometer la identidad del validador.

En auditorías recurrentes encuentro RPC JSON sin allowlist, métricas Prometheus expuestas en 0.0.0.0:9100 sin TLS mutuo, SSH con autenticación por contraseña y puertos de gossip aceptando peers no firmados. Cualquiera de estos puntos es suficiente para construir una cadena de explotación.

El primer ejercicio que pido al cliente es un escaneo externo desde fuera de su VPC. Casi siempre aparece más superficie de la documentada — agentes de observabilidad heredados, paneles internos olvidados, balanceadores con políticas permisivas.

Segmentar el nodo productor detrás de relays dedicados, aplicar rate limiting por IP y por par criptográfico, exigir mTLS para todo plano de control, y firmar las release binarias del nodo con sigstore. Para DoS a nivel de protocolo, lo que mejor funciona es presupuesto de CPU/IO por par y desconexión agresiva de peers que excedan un umbral de mensajes malformados.

Y monitorización con alertas que tengan sentido operativo: tiempo desde el último bloque adoptado, profundidad de mempool, ratio de forks observados. Métricas que un humano puede accionar a las 03:00, no dashboards con cien series irrelevantes.

Un cluster EKS recién creado con la configuración por defecto no es seguro para producción. El Service Account default monta su token automáticamente en cada pod, el PodSecurityPolicy ya no existe, y la mayoría de equipos pasan directamente a desplegar workloads sin definir un PodSecurityStandard, NetworkPolicies ni un OPA/Kyverno mínimo.

Ese pod compromisible — un sidecar de logs vulnerable, una imagen base con CVE conocido — se convierte en pivote dentro del cluster en cuestión de minutos. Y desde ahí, si el IRSA está mal acotado, el atacante salta al plano AWS con permisos que nadie revisó.

Cuatro controles mínimos: runAsNonRoot con un UID estable, readOnlyRootFilesystem siempre que el workload lo permita, seccompProfile RuntimeDefault, y allowPrivilegeEscalation: false. Sobre esa base, NetworkPolicies default-deny por namespace y egress controlado a una lista cerrada de destinos. Sin esto, hablar de Zero Trust dentro del cluster es marketing.

El patrón correcto es: un Service Account por workload, un IAM Role por Service Account, y una política con acciones explícitas — nunca Action: "*". El trust policy del rol debe restringir el sub a system:serviceaccount:<ns>:<sa>, y la política debe acotar Resource con ARNs concretos, no con comodines de cuenta.

Un escaneo trimestral con AWS IAM Access Analyzer y prowler --compliance cis_2.0_aws debería ser parte del pipeline, no una tarea anual.

CloudTrail con eventos de gestión y de datos habilitados, GuardDuty con findings enviados a un EventBridge bus dedicado, y reglas de detección sobre acciones IAM sensibles: CreateAccessKey, AttachUserPolicy, AssumeRole desde IPs fuera de la lista corporativa. En el cluster, Falco con un ruleset adaptado al negocio — no el default — y exfiltración bloqueada por defecto a nivel de NetworkPolicy.

A pesar de quince años de literatura, sigo encontrando reentrancy explotables en auditorías nuevas. La razón es que el patrón clásico (call externo antes de actualizar estado) ha mutado: hoy aparece en hooks ERC-777, en callbacks de flash-loans, y especialmente en cross-function reentrancy donde la víctima no es la misma función que hace el call.

La defensa estructural es Checks-Effects-Interactions estricto y, cuando el flujo lo permite, un ReentrancyGuard. Pero más importante: modelar explícitamente qué funciones comparten estado y cuáles pueden ser reentrantes entre sí.

La mayoría de explotaciones de ocho cifras de los últimos dos años no han sido bugs de lógica del contrato auditado, sino manipulación de la fuente de precio que ese contrato consultaba. Un Uniswap V2 spot price es trivialmente manipulable dentro del mismo bloque mediante flash-loan; usarlo como referencia para liquidaciones es entregar el protocolo.

La regla: TWAP de ventana suficientemente amplia, o feeds Chainlink con validación de staleness (block.timestamp - updatedAt < heartbeat) y de desviación contra una segunda fuente. Nunca un único oráculo, nunca precio instantáneo de un AMM para decisiones financieras.

El built-in overflow check de 0.8 cubre el caso obvio, pero no protege contra pérdida de precisión por divisiones prematuras, ni contra rounding direction equivocado en favor del usuario en lugar del protocolo. En vaults y curvas de bonding, el orden de operaciones decide quién gana micro-arbitrajes acumulados a lo largo de millones de transacciones.

Regla operativa: multiplicar antes de dividir, redondear siempre en contra del usuario en operaciones de mint/redeem, y testear con fuzzing — Foundry y Echidna deberían formar parte del ciclo, no de la auditoría final.

Antes de leer una línea de lógica reviso: control de acceso (¿hay onlyOwner sobre funciones que mueven valor?), inicialización (¿hay riesgo de re-init en proxies?), pausabilidad y planes de upgrade, y el grafo de llamadas externas. Si esos cuatro puntos están bien, la auditoría se vuelve productiva. Si están mal, no hace falta leer más para emitir un informe accionable.

Una instancia de n8n productiva acumula credenciales hacia decenas de SaaS: Slack, GitHub, AWS, Stripe, bases de datos, CRM. Comprometer el host equivale a comprometer todo ese set de integraciones a la vez. Y, sin embargo, la mayoría de despliegues que reviso están detrás de un Cloudflare Tunnel sin autenticación adicional, con N8N_ENCRYPTION_KEY en un .env versionado y webhooks públicos sin validación de firma.

Autenticación SSO obligatoria delante de la UI (Cloudflare Access, Authentik o similar), N8N_ENCRYPTION_KEY rotada y custodiada en un secret manager (no en variables de entorno persistidas), base de datos externa con TLS, y ejecución de workflows en modo queue con workers aislados por red del scheduler.

Para webhooks expuestos: firma HMAC obligatoria validada en el primer nodo del workflow, allowlist de IPs cuando el proveedor lo permite, y rate limiting en la capa de ingreso. Un webhook sin firma es una RPC anónima sobre tu infraestructura.

El nodo Execute Command y el nodo Code en modo unrestricted son RCE por diseño cuando los usa un operador con acceso a la UI. En entornos multi-equipo desactivo ambos a nivel de instancia y obligo a que cualquier integración custom pase por un nodo HTTP contra un microservicio interno auditado, donde la lógica vive en un repo con revisión de código y firma de imagen.

Una instalación limpia de Debian o CentOS deja activos servicios, módulos del kernel y permisos que no son aceptables para un servidor expuesto. rpcbind escuchando en todas las interfaces, /tmp sin noexec, módulos como cramfs, freevxfs, jffs2 o usb-storage cargables a demanda y SSH aceptando root con contraseña son la norma, no la excepción.

El primer paso disciplinado es ejecutar un baseline contra CIS Benchmark — entonces con Bastille y lynis, hoy con OpenSCAP — y tratar cada desviación como un ticket. La mayoría se resuelve con un puñado de cambios en /etc/ssh/sshd_config, /etc/sysctl.conf, /etc/security/limits.conf y un par de unit files de systemd.

Reglas no negociables: PermitRootLogin no, PasswordAuthentication no, AllowUsers acotado a la cuenta operativa, MaxAuthTries 3, LoginGraceTime 20, y Protocol 2 explícito. Las claves del cliente, ed25519 — RSA de 2048 ya no se considera prudente para nuevos despliegues.

Sobre esa base, fail2ban con jail específico para sshd y un puerto no estándar reducen el ruido de los logs en uno o dos órdenes de magnitud. No es seguridad por oscuridad — es economía operativa: menos eventos para auditar.

auditd con un ruleset que cubra ejecuciones bajo /tmp, modificaciones a /etc/passwd, /etc/shadow, /etc/sudoers y carga de módulos del kernel. /tmp, /var/tmp y /home montados con nodev, nosuid y noexec donde el workload lo permita. En sysctl: kernel.randomize_va_space=2, net.ipv4.conf.all.rp_filter=1, net.ipv4.tcp_syncookies=1 y desactivación de redirects ICMP. Son cambios baratos que cierran clases completas de ataques.

Tres VLANs como punto de partida: LAN corporativa, servidores internos (DMZ interna) y wifi de invitados, cada una con su propio rango y reglas. El error común es tratar el firewall como puerta de entrada y dejar el tráfico este-oeste sin control. En una pyme real, el 80% del riesgo está en el tráfico interno: portátiles infectados, impresoras con firmware sin parchear, dispositivos IoT olvidados.

Egress allowlist por VLAN es el cambio que más reduce impacto de incidentes. La mayoría de malware necesita salir a un C2 por HTTPS arbitrario; si la VLAN de servidores sólo puede hablar contra repositorios de paquetes y endpoints internos, ese vector se cierra. Para usuarios, proxy explícito con categorización y registro.

Snort en modo inline en la interfaz WAN con el ruleset Emerging Threats y un ajuste periódico para reducir falsos positivos. Sin ese ajuste, el operador deja de mirar las alertas en una semana — y entonces no sirve para nada.

Cualquier RDP, SSH o panel administrativo expuesto a Internet acaba en una botnet. La regla en una pyme es: cero servicios administrativos públicos, acceso remoto sólo por OpenVPN con certificados por usuario, MFA opcional con Google Authenticator, y revocación inmediata cuando un empleado deja la compañía. Es mucho más barato que limpiar un ransomware.

Una pila LAMP en alta disponibilidad razonable se compone de cuatro capas independientes: balanceo (HAProxy o keepalived + nginx), aplicación (Apache/PHP-FPM en N nodos sin estado), base de datos (MySQL con replicación maestro-réplica y promoción automática mediante MHA o orchestrator) y almacenamiento compartido para uploads (GlusterFS o NFS con DRBD). Cada capa debe poder perder un nodo sin que el servicio se degrade más allá de lo aceptable.

Configurar el balanceador con sticky sessions parece una solución sencilla, pero ata la disponibilidad al nodo concreto. Las sesiones PHP deben ir a un almacén externo — Redis o Memcached con replicación — y el balanceo puede entonces ser puramente round-robin con health-check. Lo mismo para caché de aplicación: APCu por nodo está bien para opcode, pero la caché de datos debe ser compartida.

Nagios o Zabbix con checks que reflejen la salud del servicio, no sólo de los procesos: latencia HTTP percentil 95, número de conexiones activas en MySQL, lag de replicación, espacio libre en /var/log, y un health-check sintético que simule un login real. Una guardia útil se mide por cuántas alertas requieren acción humana real — debería tender a cero si el sistema está bien dimensionado.

Una flota de tres servidores se puede gestionar con bash y SSH. A partir del cuarto, los scripts empiezan a divergir: una máquina tiene la versión vieja de un parche, otra olvida un usuario, otra mantiene un cron que ya nadie recuerda haber añadido. La salida disciplinada es declarar el estado deseado, no las acciones, y ejecutarlo de forma idempotente.

Un layout que envejece bien: inventories/{prod,staging}/hosts.ini con group_vars por entorno, roles/ con un rol por responsabilidad (common, ssh, mysql, nginx, app) y playbooks de alto nivel que sólo componen roles. Las credenciales viven en ansible-vault con la clave fuera del repositorio; cualquier secreto en texto plano en un playbook es un incidente esperando a ocurrir.

Un módulo que reporta changed=true en cada ejecución porque compara timestamps o re-renderiza un template idéntico es un bug. Antes de considerar un rol terminado, ejecutarlo dos veces seguidas debe dejar el segundo run con changed=0 en todas las tareas relevantes. Esa disciplina hace que las ejecuciones contra producción dejen de dar miedo.

Las primeras imágenes que un equipo construye suelen pesar 1-2 GB porque parten de ubuntu:latest, instalan build-essential y dejan dentro caches de apt, archivos de compilación y herramientas de desarrollo. Una imagen de producción debería ser multi-stage: una etapa para compilar, otra mínima (alpine o distroless) que sólo contenga el binario, sus librerías y los certificados.

Tres errores recurrentes: pasar contraseñas por ENV (quedan en el manifiesto, en docker inspect y en los logs del orquestador), no fijar memory/cpu limits (un contenedor mata al host en producción) y escribir datos en el filesystem del contenedor (se pierden en cada redeploy). Las soluciones son conocidas: secrets gestionados, requests/limits explícitos y volúmenes para todo dato persistente.

Un contenedor reiniciado pierde sus logs locales. Stdout/stderr a un colector central (Fluentd, Loki, journald-remote), métricas expuestas en /metrics y trazas con un identificador de correlación que sobreviva al ciclo de vida del contenedor. Sin esto, debugar un incidente en producción se convierte en arqueología.

La concatenación de strings para construir SQL no es un problema de hace veinte años — sigue apareciendo en auditorías nuevas, especialmente en capas internas de servicios que el equipo asume seguras porque no están expuestas. Cualquier punto donde una entrada cruza una frontera de confianza necesita parametrización: prepared statements, ORM bien usado o, en última instancia, escapado explícito documentado.

Cookies de sesión sin HttpOnly ni Secure, identificadores de sesión predecibles, no rotar el ID tras login, recuperación de contraseña por preguntas secretas, contadores de intentos sólo en el cliente. Cada uno por separado parece menor; combinados son una toma de cuenta a un paso.

La regla simple: usar el módulo de sesión del framework, configurarlo con valores explícitos (no defaults), rotar el ID en cada cambio de privilegio y registrar todo intento fallido con suficiente contexto para detectar password spraying.

TLS 1.2+ con ciphersuites modernas y HSTS preload son el mínimo en tránsito. En reposo: bcrypt/argon2 para contraseñas (nunca SHA-x sin sal), cifrado a nivel de columna para PII, y un proceso documentado de gestión de claves. Cifrar la base de datos entera con el mismo KMS que la aplicación usa para todo no aporta gran cosa si el atacante ya tiene la aplicación.

Las CAs internas gestionadas con OpenSSL y un README envejecen mal: claves privadas en pendrives, certificados emitidos por dos años porque rotarlos cuesta, expiraciones que tiran el servicio un viernes por la tarde. Una CA intermedia en Vault, firmada por una CA raíz offline, permite emitir certificados con TTL corto (24-72h) a través de una API autenticada — y el operador deja de ser el cuello de botella.

Cada servicio recibe un AppRole con permisos para emitir certificados de un solo dominio interno y un TTL acotado. Vault registra cada emisión con metadata del solicitante; revocar es un endpoint, no una página de wiki. La CA raíz vive offline en un host air-gapped y sólo se activa para firmar la renovación anual de la intermedia.

Un sidecar (consul-template, vault-agent) renueva el certificado al 60% de su vida útil y manda un SIGHUP al servicio para recargar TLS sin downtime. El servicio nunca persiste la clave privada en disco fuera de tmpfs. Resultado operativo: rotación silenciosa, ningún incidente por expiración y revocación inmediata si una clave se sospecha comprometida.

Durante años, la respuesta a incidentes asumía una sala con personas frente a pantallas. En 2020 eso desapareció en una semana. Lo que sustituyó al war-room funcionó si y sólo si tres cosas estaban previamente preparadas: un canal de comunicación fuera de banda (porque el corporativo puede estar comprometido), un repositorio central de evidencias con control de acceso y un runbook que asume que la persona que toma una decisión no está en la misma zona horaria que quien la ejecuta.

Imágenes forenses tomadas en remoto sobre EDR o agentes de IR, hashes SHA-256 firmados y registrados con timestamp confiable, transferencia por canal cifrado con doble custodia. Cada acción ejecutada en la máquina comprometida queda registrada en un live response document que es la fuente única de verdad si el incidente acaba en un juzgado.

El método sigue siendo el mismo: contener, erradicar, recuperar, lecciones aprendidas. Lo único que cambia es la latencia de cada paso y la presión sobre la documentación. Un equipo distribuido que documenta bien responde mejor que un equipo presencial que improvisa.

El término ha sido vaciado por el marketing. La definición operativa útil — la del NIST SP 800-207 — es: ninguna confianza implícita basada en ubicación de red; cada solicitud se evalúa contra identidad, postura del dispositivo, sensibilidad del recurso y contexto, y la decisión se reevalúa de forma continua. No es un producto, es un patrón arquitectónico.

Un IdP central (Okta, Entra ID, Google Workspace) federado contra AWS IAM Identity Center y GCP Workforce Identity, MFA resistente a phishing (WebAuthn, no SMS), y SCIM para desaprovisionamiento automático. El día que un empleado deja la empresa, su acceso a todo el estate desaparece en minutos, no en semanas.

Cloudflare Access, Google BeyondCorp o equivalentes publican aplicaciones internas sin VPN, evaluando en cada request: identidad, MDM/EDR del dispositivo, geolocalización, hora. El usuario nunca entra a una red corporativa — entra a aplicaciones concretas, con un token de corta vida. La VPN tradicional se reserva para casos de acceso a infraestructura, y aun ahí con MFA y segmentación estricta.

El 80% del esfuerzo va a aplicar los mismos principios a comunicación servicio-a-servicio: SPIFFE/SPIRE para identidad criptográfica de cargas, mTLS por defecto en la malla de servicios, y políticas de autorización (OPA, Cedar) versionadas como código. Sin esto, el Zero Trust del usuario es un escaparate y la red interna sigue siendo plana para los atacantes que llegan al primer pod.