OpenBSD 7.7 como base sólida de cortafuegos: una pf.conf y una sysctl.conf que te respaldan

OpenBSD 7.7 como base sólida de cortafuegos: una pf.conf y una sysctl.conf que te respaldan

OpenBSD es desde hace años sinónimo de un enfoque de seguridad sin concesiones: valores predeterminados sensatos, código limpio y “secure by default” como mandato, no como eslogan. Si buscas un cortafuegos fiable y explicable en el día a día, OpenBSD te ofrece una base sólida. Al mismo tiempo, los buenos valores por defecto están muy bien, pero con unos pocos ajustes puntuales puedes elevar de forma notable el nivel de seguridad y la previsibilidad—sin convertir tu entorno en un experimento frágil.
Con este artículo queremos proporcionarte una línea base práctica que proteja con solvencia redes pequeñas, laboratorios domésticos y muchos entornos de pymes, manteniéndose a la vez legible y fácil de mantener.

En lugar de listas interminables y consejos de tuning arbitrarios, aquí encontrarás decisiones fundamentadas con una justificación clara. Te mostraremos por qué se activa cada opción, qué riesgos aborda y qué efectos secundarios debes tener presentes. El objetivo no es cubrir todos los escenarios teóricos de ataque, sino darte un punto de partida fiable: reglas concisas, pocas excepciones y un comportamiento predecible.

Este guía sigue una línea nítida: lo que no se permite explícitamente, se bloquea. Del exterior al interior, solo se permite lo que el router realmente necesita; del interior al exterior, solo lo que tú quieres que salga. El DNS se mantiene visible y controlable. DoH, DoT, DoQ y QUIC no tienen atajos silenciosos, para que no aparezcan “canales invisibles”. Los estados se anclan intencionadamente a las interfaces para que las conexiones permanezcan donde se originaron. Eso hace el sistema predecible y la resolución de problemas más llevadera. Y porque la transparencia vale más que diez trucos ingeniosos, todos los caminos críticos llevan etiquetas: en la operación diaria verás al instante qué se usa, qué se deniega y dónde debes ajustar.

Para que todo sea tangible, te ofrecemos dos perfiles de pf entre los que puedes elegir: una variante solo router para escenarios clásicos LAN‑a‑internet y una variante router+DMZ si quieres aislar servicios. Forzamos el DNS de los clientes exclusivamente hacia 1.1.1.1 (con 1.0.0.1 opcional como respaldo). No es una manía: es una decisión arquitectónica deliberada con la que recuperas visibilidad y control. Si una aplicación quiere otra cosa, destaca, y tú decides de forma consciente si y dónde conceder una excepción.

El archivo sysctl.conf refuerza esta postura a nivel de kernel. OpenBSD ya trae mucho de serie, pero unos cuantos interruptores aportan una robustez medible: una configuración de malloc endurecida que hace que los errores de memoria fallen antes y más ruidosamente; desactivar SMT/Hyper‑Threading cuando los riesgos de canal lateral no aportan beneficio alguno; W^X, que prefiere terminar procesos antes que dejarlos correr en zonas grises peligrosas; desactivar redirecciones y protocolos de túnel prescindibles; opciones TCP modernas y límites de tasa moderados que amortiguan el “ruido” de red sin romper funciones legítimas. No son “tweaks” vistosos, sino higiene constante: menos superficie de ataque, menos sorpresas, comportamiento más estable bajo carga.

Quedan fuera de alcance los ataques dirigidos de alta especialización o despliegues completos de IDS/IPS. Si quieres monitorización en varias capas, inspección profunda de protocolos o feeds de intel de amenazas, esta configuración no te estorba; es el fundamento sobre el que puedes añadir esos bloques con método más adelante. También omitimos a propósito políticas multi‑WAN complejas, paisajes extensos de port‑forwarding o redes superpuestas exóticas. Todo eso es posible, pero no sin diluir la claridad de la línea base.

Nuestra apuesta por la legibilidad implica mecánica antes que magia. El NAT es estático donde beneficia a los protocolos en tiempo real y dinámico donde da igual. QUIC se queda fuera para que el DNS no se esconda dentro de flujos TLS. IPv6 se bloquea inicialmente para evitar el “IPv6 a medias”, donde los clientes prefieren v6 mientras el cortafuegos no lo controla; más adelante encontrarás una receta limpia para activar IPv6 correctamente si lo necesitas. Y donde ayude, marcamos los casos límite con etiquetas—no para colorear los logs, sino para obtener respuestas: ¿Quién intentó hablar DoT? ¿Qué hosts chocan con la regla anti‑rebind? ¿Qué dispara los bloqueos de egress?

¿Para quién es esto? Para ti si ves la administración como un oficio y prefieres invertir una hora en una base limpia antes que tres semanas persiguiendo efectos secundarios raros. Para ti si quieres entender tu red en lugar de sorprenderte por permisos por defecto. Y para ti si te sientes “entre dos sillas”: sin tamaño para un SOC/equipo azul, pero demasiado exigente para un router doméstico de escaparate. Esta línea base no es un truco de magia; es un estándar sensato: lo bastante pequeño para dominarlo y lo bastante robusto para conservarlo.

Modelo de amenazas: a qué nos enfrentamos y a qué no

Esta línea base está pensada para entornos sin equipo azul dedicado que, aun así, quieren estándares fiables. Te protege del ruido habitual que golpea tu perímetro a diario: escaneos masivos, exploits oportunistas, abuso de protocolos (el “DNS sobre cualquier cosa”), configuraciones erróneas o políticas de egress generosas que hacen posible la exfiltración de datos. Encapsula servidores opcionales en una DMZ, impidiendo movimientos laterales hacia la LAN. No está en el foco cubrir ataques muy dirigidos o pilas completas de IDS/IPS: podrás añadirlos sobre este fundamento más adelante.

Principios de diseño: poca superficie de ataque, responsabilidades claras

La configuración sigue varias pautas que también ayudan en futuras modificaciones:

Fail‑closed. Si algo no se permite explícitamente, permanece cerrado—tanto entrante como saliente. Así, en pruebas verás pronto lo que una aplicación realmente necesita y conservarás el control.

Estados deterministas. if-bound asegura que una conexión se mantenga ligada a la interfaz donde se originó. En routers de un solo WAN, esto te ahorra perseguir “estados flotantes” mágicos y facilita el troubleshooting.

Minimalismo de egress. Del interior al exterior solo pasa lo necesario: web clásico, envío de correo (submission), rangos UDP definidos para VoIP/WebRTC—y DNS únicamente hacia donde tú decidas.

Transparencia frente a conjeturas. Se bloquean QUIC y también DoH/DoT/DoQ. Sí, es molesto para algunas apps. A cambio, obtienes claridad: DNS es DNS, TLS es TLS. Si alguien necesita “DNS en la sombra”, se notará.

Valores robustos por defecto. Scrubbing, tope de MSS, IDs aleatorias, filtros de bogons, anti‑spoofing, higiene de flags TCP y límites de tasa razonables para ICMP y RST. Nada espectacular; en conjunto, higiene sólida.

IPv6 por decisión. IPv6 está apagado por defecto. Si lo quieres, en el artículo tienes una ruta limpia para activarlo. Evitamos de forma consistente el “IPv6 a medias”.

sysctl.conf — Palancas de seguridad a nivel de kernel que sí importan

OpenBSD ya trae buenos predeterminados, pero unos pocos ajustes elevan notablemente la seguridad y la previsibilidad. He aquí lo esencial—sin listas interminables, con razones claras.

Endurecimiento de memoria (vm.malloc_conf=CFGJRS). Guard pages, patrones de “junk”, red zones y canaries dificultan la explotación de errores de memoria clásicos y hacen que los procesos fallen “en voz alta” en lugar de corromper en silencio. El pequeño overhead compensa en prácticamente todos los escenarios de router.

CPU/Hardware: SMT desactivado, aperture cerrada. hw.smt=0 reduce riesgos de canal lateral (Hyper‑Threading); en routers el impacto suele ser mínimo. machdep.allowaperture=0 cierra accesos tipo /dev/mem—ideal para equipos sin gráfica. Si necesitas X11/KMS lo sabrás; si no, déjalo cerrado.

Enrutamiento y protocolos: IPv4 activo, IPv6 intencionadamente inactivo. net.inet.ip.forwarding=1 convierte tu equipo en router IPv4. net.inet6.ip6.forwarding=0 evita el enrutamiento “accidental” de IPv6. Además desactivamos túneles innecesarios (IP‑in‑IP, GRE, ESP/AH, EtherIP). Menos maquinaria de cifrado/encapsulación = menos superficie de ataque y menos sorpresas.

Desactivar trampas heredadas. Broadcasts dirigidos desactivados, redirecciones ignoradas (IPv4 e IPv6). Las redirecciones ICMP son un clásico “arma de doble filo”; si quieres alterar rutas, hazlo explícitamente en el enrutamiento o en PF, no por atajos.

ICMP con mesura. Nada de eco a broadcast, ni timestamps/netmask; los paquetes de error tienen límite de tasa razonable. Esto amortigua ruido de DDoS sin romper funciones legítimas. ICMP no es el enemigo, pero necesita guardarraíles.

Endurecimiento UDP/TCP sin brujería. Checksums UDP obligatorios; buffers de socket sensatos evitan pérdidas feas. En TCP, mantenemos activas las funciones modernas (window scaling, timestamps, SACK) para ganar estabilidad. ECN va activado; rara vez causa problemas y ayuda bajo carga. Los límites de SYN cache/bucket y el rate‑limit de RST absorben oleadas típicas de escaneo.

Colas, BPF y W^X. Una if‑queue más larga reduce drops en ráfagas. Buffers BPF mayores son un regalo futuro al depurar. kern.wxabort=1 hace cumplir W^X: el código es o escribible o ejecutable, nunca ambas. Las violaciones matan el proceso—fail‑closed, como queremos. El swap cifrado permanece activo para que restos sensibles no terminen en disco en claro.

Esta selección de sysctl es deliberadamente sobria. Mueve la curva de “suele funcionar” a “se comporta con consistencia bajo estrés”. Cárgala con sysctl -f, comprueba algunos contadores (sysctl -n net.inet6.icmp6.errppslimit, netstat -m, pfctl -s memory) y recuerda: si tocas presupuestos de mbuf/cluster, puede que debas ajustar límites de PF como set limit frags.

pf.conf: reglas que puedes explicar

pf te da posibilidades infinitas. Nuestra línea base toma exactamente lo que necesitas para estándares robustos—ni más ni menos.

Macros, tablas y etiquetas: la mitad de la batalla es la estructura. Empieza con interfaces y redes definidas con claridad: WAN, LAN y—en la variante con DMZ—DMZ. Añade tablas para bogons, abusers, scanners y una lista de vigilancia para endpoints DoH sospechosos. No es decoración: con persist sobreviven a recargas y, mediante overload, las fuentes ruidosas se añaden automáticamente. Las etiquetas coherentes en las reglas te dan visibilidad operativa sin recurrir a pcap pesado: pfctl -vvsr o systat pf muestran dónde está la acción.

Opciones globales: comportamiento predecible. set block-policy drop y la optimización “aggressive” son valores conservadores sensatos. set state-policy if-bound ancla las conexiones a su interfaz de entrada. Definimos límites de estados, fragmentos y src‑nodes, timeouts adaptativos y activamos syncookies de forma adaptativa—útiles cuando sube la marea. loginterface te da estadísticas del WAN; set skip on lo0 evita “autodisparos”.
En pf, IPv6 está bloqueado por defecto, acorde con sysctl, y evita el “IPv6 a medias”. Si lo quieres, actívalo de forma deliberada y visible.

ICMP entrante: lo suficientemente abierto para mantener la salud. En la interfaz WAN permitimos eco y “unreachable”, con estado y límite de tasa. Mejora la capacidad de diagnóstico (¿cómo si no detectas problemas de MTU/ruta?) y te protege de floods de ping. Todo lo demás—especialmente redirecciones—permanece desactivado.

Scrubbing: menos fragmentación, menos frustración. Depuramos en ambos sentidos: IDs de IP aleatorias, TTL mínimo conservador, MSS limitado a 1440 (valor sano en la práctica) y reensamblado TCP. Evita que paquetes fragmentados dudosos atasquen estados y reduce dolores de PMTU. Con esto, raramente necesitas tocar MSS vía sysctl.

NAT: estático donde importa el tiempo real; dinámico donde no. UDP obtiene puertos estáticos—oro para VoIP/WebRTC, juegos y protocolos en tiempo real. Todo lo demás usa un rango ephemeral alto para facilitar atribución de egress en capturas y evitar colisiones. El NAT se aplica a todo salvo destinos de gestión definidos explícitamente—sin caminos sorpresa.

Anti‑spoofing, bogons, puertos nulos. antispoof vigila todas las interfaces relevantes. Lo que llega al WAN con ruta de origen rota se descarta pronto. Bloqueamos bogons entrantes y salientes; tráfico desde 10/8 o 127/8 hacia internet suele significar otros problemas. También limpiamos puertos 0 y flags TCP inverosímiles—no es ciencia de cohetes, pero te ahorra dolores con escáneres y herramientas “creativas”.

Denegación por defecto: la gran escoba. Tras la higiene llega el corte duro: block all. A partir de aquí, todo es excepción consciente.

Entrante en WAN: solo lo que necesita el router. Permitimos DHCP entrante si tu upstream lo requiere. Nada más. Una DMZ pública alcanzable desde internet no es el objetivo de esta línea base; para eso definirías port forwards—con moderación.

QUIC: HTTP/3 se queda fuera. Bloqueamos UDP 80/443 en WAN. Eso asfixia QUIC. ¿Por qué tan estrictos? Porque QUIC es un túnel conveniente—también para variantes de DoH y otros trucos “todo en un flujo”. Si más adelante realmente necesitas HTTP/3 hacia objetivos concretos (y sabes por qué), añade excepciones quirúrgicas. La línea base antepone transparencia a velocidad.

Visibilidad para DoH/DoT/DoQ—con límites claros. DoT (853/TCP) y DoQ (784/UDP) se bloquean en egress y se registran en inbound. En LAN/DMZ etiquetamos conexiones TLS a hosts DoH conocidos—sin cambiar la política salvo que elijas la variante estricta. El punto es: verás cuando los clientes intenten DNS encubierto.

Acceso admin al cortafuegos: ajustado y con control de ritmo. SSH desde la LAN al cortafuegos está permitido con estado, higiene de flags y limitación suave de tasa. Las rutas de gestión ascendentes (por ejemplo, la GUI de un módem/router) obtienen pasos dirigidos; límites de conexiones por fuente evitan “sprays” por error. Las etiquetas te mantienen estas rutas a la vista.

Política DNS sin resolutor local: imponer, no esperar. Punto central: los clientes en la LAN (y en la DMZ, si existe) solo pueden usar 1.1.1.1 y, opcionalmente, 1.0.0.1 en el puerto 53/TCP+UDP. Todo lo demás hacia el 53 se bloquea y registra. No es un “nice to have”, es crucial para la visibilidad. Verás al instante intentos de otros resolutores—o de DoH/DoT/DoQ, que bloqueas aparte. Puedes cambiar estos resolutores externos cuando quieras; la mecánica es la misma.

DMZ: sin atajos ni puertas traseras. En la variante con DMZ no hay comunicación intra‑DMZ, no hay retorno a la LAN y solo hay pasos dirigidos de egress para los servicios que allí viven (web clásico, envío de correo, rangos UDP de VoIP/WebRTC). El acceso desde DMZ a cualquier GUI de upstream no se permite; así evitas que un servidor comprometido toque tu red de gestión. Todo lo demás se bloquea—y se registra—para que encuentres enseguida el tornillo que falta.

Mitigar riesgos de salida: cerrar los clásicos. Hacia fuera bloqueamos a los sospechosos de siempre: SMB/NetBIOS, RPC/NFS, TFTP, SNMP, RDP/VNC/WinRM y SMTP oportunista. Cada uno tiene su lugar dentro de tu red o en caminos deliberados; en internet, por defecto, no. Si necesitas una excepción, defínela a conciencia—con etiqueta.

El propio cortafuegos: puede salir, pero visible. El cortafuegos puede acceder a internet—con estados, límites y etiquetas. Lo necesitas para updates, paquetes y diagnóstico. No te excedas: esta caja es router y perro guardián, no un terminal de navegación.

Anti‑rebind, LAN→DMZ y el gran repaso. Entre LAN y DMZ solo se permiten rutas explícitas (p. ej., clientes a un servicio en DMZ); el retorno permanece cerrado. Las reglas anti‑rebind evitan que clientes alcancen objetivos protegidos internos mediante trucos DNS a través del cortafuegos. En lo demás, PF dice un no claro—con return donde un error rápido ayuda al diagnóstico.

Solo router vs. router+DMZ: ¿qué perfil encaja contigo?

Si solo quieres conectar una LAN a internet, solo router es ideal: compacto, claro y aun así endurecido. Obtienes anti‑spoofing, filtros de bogons, postura estricta de egress, DNS forzado a 1.1.1.1/1.0.0.1, controles de DoH/DoT/DoQ/QUIC, SSH admin desde la LAN al cortafuegos y valores ordenados para scrubbing, estados y límites.

En cuanto hospedes servicios—aunque sean solo internos—router+DMZ cobra sentido. Una DMZ contiene fallos y reduce la probabilidad de que un servicio comprometido sea trampolín hacia tu LAN. La comunicación intra‑DMZ permanece cerrada; el egress es por lista blanca y más estrecho que en la LAN. El DNS es igual de estricto; NTP queda cerrado hasta que realmente lo necesites.

Activar IPv6 correctamente

La línea base bloquea IPv6 para que nada quede a medio abrir. Si lo necesitas, actívalo de forma deliberada y consistente: enrutamiento vía sysctl, reglas inet6 correspondientes en pf, un plan de egress limpio (sí, también enforcement de DNS para v6) y decisiones claras sobre RA/DHCPv6. Refleja las buenas ideas de v4: anti‑spoofing, denegación por defecto, gestión de QUIC/DoH/DoQ y excepciones visibles—ni más ni menos. Consejo clave: no “cueles” v6 en silencio. Si está, que sea bien; si no, aún no.

Operación, diagnóstico y forense: medir, no adivinar

Una política estricta solo es buena si puedes leerla a diario. pf te ayuda por tres vías:

Etiquetas. Cada regla relevante lleva una etiqueta descriptiva. En pfctl -vvsr verás qué rutas se usan, cuáles se bloquean y dónde está el movimiento. A menudo basta para acotar problemas.

Tablas. Con pfctl -t <table> -T show lees entradas de abusers/scanners. overload llena estas tablas automáticamente cuando un cliente abre conexiones en exceso. No es un castigo; es un cinturón de seguridad.

pcap mínimo. tcpdump es tu amigo—úsalo con intención. Para controlar DNS/DoH suelen bastar miradas rápidas como:
tcpdump -n -e -ttt -i $wan 'port 53 or port 853 or (udp and port 784)'
Eso es forense con plan, no “Wireshark hasta que te lloren los ojos”.

Canon de pruebas sano. Cuando cambies reglas, compílalas primero sin cargarlas: pfctl -nf /etc/pf.conf. Luego pfctl -f y, si algo falla, etiquetas y tablas guiarán la corrección. Para enforcement de DNS: drill @1.1.1.1 openbsd.org debe funcionar; drill @9.9.9.9 openbsd.org debe bloquearse. Para QUIC, comprueba que curl -I --http3 https://example.com no vaya por UDP y que caiga en HTTP/2. Valida DoT/DoQ intentando 1.1.1.1:853 y UDP 784—deben fallar y verás los contadores de bloqueo en las reglas etiquetadas.

Un consejo para cambios de egress. Cuando abras algo, márcalo temporalmente con una etiqueta muy explícita y, a la semana, revisa si se usa. Si no, bórralo. Así tu línea base permanece ligera.

Consideraciones de rendimiento sin folclore

Este montaje no está afinado “al límite”, sino para la estabilidad. Algunas consecuencias importan:

Bloquear QUIC puede ralentizar ligeramente algunos sitios. Es un intercambio deliberado: visibilidad sobre velocidad. Si tienes razones válidas para permitir HTTP/3, hazlo de forma quirúrgica (objetivos en una tabla, etiqueta y listo).

ECN activado suele ir bien en redes modernas. Si alguna caja exótica lo detesta, lo verás rápido y podrás desactivarlo en ese caso—la línea base no se interpondrá.

Puertos NAT estáticos para UDP son un regalo para protocolos en tiempo real. Quien haya perseguido problemas de WebRTC lo sabe: valen oro. No cuestan nada, salvo reconocer que la “aleatoriedad” de puertos en UDP no es una función de seguridad.

If‑queues y buffers BPF están dimensionados con pragmatismo: margen para picos y sesiones de depuración que no mueren con buffers de 4 KB. Si de verdad apuras al máximo, mide y ajusta—no al revés.

Errores comunes y cómo manejarlos con elegancia

“¡Mi app solo funciona con DoH!” Entonces necesita una excepción o, mejor, una revisión honesta. DoH no es malo en sí, pero es contraproducente para el control de red (hogar/empresa). Puedes permitir hosts concretos en una tabla; mantenlo como excepción consciente, no como apertura global.

“Las videollamadas se entrecortan.” Verifica primero que tienes cubiertos los rangos UDP de tu proveedor (Zoom/Teams/WebRTC). Los puertos UDP estáticos ayudan, pero sin corredor de egress adecuado, nada mejora. Ajusta a medida, no en bloque.

“Mi cliente de correo no puede enviar directo.” Correcto: el puerto 25 saliente está cerrado. El correo debe ir por submission (465/587) a tu proveedor o servidor; no directamente a internet. Define esos puertos como egress permitido—etiquetados.

“De repente se rompió IPv6.” En esta línea base, v6 está bloqueado. Si los clientes prefieren v6 mientras el cortafuegos no lo enruta, verás timeouts. O activas v6 correctamente (con reglas) o señalas a los clientes (RA/ND) que aún no hay v6.

“Efectos raros tras cambiar una regla.” Piensa en los estados. Los antiguos sobreviven por defecto. Cuando cambies política de fondo (p. ej., un nuevo puerto de egress), mata los estados afectados (pfctl -k ...) o, si hace falta, flushea todos (pfctl -F state). Después, el mundo vuelve a ser consistente.

Por qué esta línea base es “segura” y qué significa seguridad aquí

La seguridad nunca es absoluta. Pero sí es medible cuando fijas objetivos claros y verificas el camino con honestidad. Esta línea base reduce la superficie de ataque porque:

minimiza toda exposición entrante,

convierte el egress en excepción y no en regla,

impone y hace visible el DNS,

bloquea rutas ofuscadas (QUIC/DoH/DoT/DoQ),

desactiva pseudo‑funciones (redirecciones, broadcasts),

aplica valores robustos TCP/ICMP,

maneja estados de forma determinista,

y te da herramientas para observar el uso en el día a día.

A la vez, la configuración sigue siendo mantenible. No es “segura” por tener 3.000 líneas, sino porque puedes explicar cada línea.

Migración: cómo proceder

Si vienes de una configuración pf existente, avanza paso a paso:

Primero sysctl. Carga el endurecimiento que no rompe servicios. Mira logs por ruido inusual de ICMP/RST.

Prueba la política pf en paralelo. Usa pfctl -nf y un laboratorio o ventana de mantenimiento. Al activar por primera vez, cuida el SSH desde LAN al cortafuegos—no hay nada peor que auto‑bloquearte.

Endurece el egress. Activa el enforcement de DNS y observa. Luego ve cerrando gradualmente los servicios clásicos de riesgo. Una o dos semanas de monitorización ayudan a encontrar puntos ciegos.

Introduce una DMZ (si procede). Migra servicios, mantén cerrados intra‑DMZ y DMZ→LAN. Abre solo los egress estrictamente necesarios. Observa y refina.

Decide IPv6 con intención. O lo activas bien o lo dejas fuera informando a los clientes.

Cada etapa eleva la seguridad sin un “big bang” arriesgado.

Lo que podrás ampliar fácilmente más adelante

Esta línea base es un fundamento, no una jaula. Extensiones típicas:

Excepciones quirúrgicas para QUIC/DoH si hay razones validadas—siempre con tablas y etiquetas.

VPN sitio‑a‑sitio con mínima superficie de ataque; los sysctl por defecto no te limitan si permites explícitamente los protocolos.

Monitorización/alerting. Contadores de pf y systat pf sirven para métricas básicas. Para más, envía logs de pf a un sistema centralizado.

IPv6, reflejando totalmente la lógica de v4—no como injerto.

Sobre actualizaciones y mantenimiento

OpenBSD cumple sus promesas—pero lee las release notes en cada actualización, especialmente sobre sintaxis de pf y valores de kernel. Etiquetas, tablas y macros claras hacen rápida la validación entre versiones. Mantén la disciplina de comentar cada excepción: por qué existe, quién la necesita, cuándo la revisaste por última vez. Las excepciones no son pecado; no comentarlas sí es deuda técnica.

Conclusión: la claridad es el mejor endurecimiento

Esta línea base persigue un objetivo simple: claridad sobre complejidad. Obtienes un cortafuegos OpenBSD predecible en el día a día, con superficie de ataque reducida y que te muestra—mediante etiquetas, tablas y valores sensatos—lo que realmente sucede. Priorizamos elecciones explícitas frente a efectos colaterales implícitos: política de egress estricta, DNS forzado a resolutores definidos, sin canales silenciosos vía QUIC o DoH/DoT/DoQ, estados deterministas y palancas de kernel robustas. El resultado no es una pieza académica, sino un punto de partida duradero sobre el que puedes construir con confianza.

Importa señalar que esta línea base intencionalmente asume sin resolutor local y sin servicio NTP local. Apunta a entornos que deben estabilizarse rápido sin infraestructura adicional. Si más adelante quieres más control on‑prem, puedes añadirlo sin fricción—la arquitectura está lista sin renunciar a la postura central.

Para ahorrarte búsquedas: abajo encontrarás las propuestas de configuración completas—ambos perfiles de pf.conf (solo router sin DMZ y router+DMZ con aislamiento estricto) y la sysctl.conf endurecida. Este artículo explica las decisiones; los archivos de abajo las implementan tal cual. Si sigues la secuencia “validar → cargar → medir”, llegarás pronto a un resultado reproducible.

Igualmente importante es ser honesto con el alcance: no están en foco aquí ataques dirigidos de alta especialización ni escenarios IDS/IPS completos. Eso no significa renunciar a ellos—al contrario. Este fundamento está dispuesto para que puedas añadirlos con método. Tres caminos de ampliación han demostrado su utilidad en la práctica.

Si tienes ideas para afinar reglas concretas, requisitos especiales o quieres compartir observaciones de tu operación: ponte en contacto. La retroalimentación real es el mejor catalizador de mejoras con sentido—y alimentará futuras ampliaciones. La seguridad es un proceso, no un sprint; con una línea base clara y una comunidad que comparte experiencia, lo “bueno” pasa a “excelente” muy rápido.

Descargar sysctl.conf: https://www.protectstar.com/download/blog/sysctl.txt
Descargar pf.conf (con DMZ): https://www.protectstar.com/download/blog/pf.conf_withDMZ.txt
Descargar pf.conf (sin DMZ): https://www.protectstar.com/download/blog/pf.conf_noDMZ.txt