# OpenBSD y la cultura de la seguridad: el sistema obsesionado con el código correcto
- **Publicado el:** 2026-09-30
- **Categoría:** Noticias
- **Página original:** https://linuxgratis.com/articulos/openbsd-cultura-seguridad
Cómo OpenBSD convirtió la seguridad en filosofía: auditorías de código, secure by default, OpenSSH, LibreSSL y mitigaciones como pledge o unveil que hoy usamos todos.
---
Entre los sistemas operativos libres hay proyectos enormes y proyectos influyentes, y rara vez coinciden. [OpenBSD](/openbsd) lo demuestra de manera ejemplar: una comunidad pequeña, sin grandes patrocinadores ni campañas de marketing, que aun así ha cambiado la forma en que todo internet entiende la seguridad. Si esta noche te conectas por SSH a un servidor, estás usando código que nació en OpenBSD. Te cuento cómo un proyecto tan austero acabó marcando el rumbo de la industria.
## Un nacimiento marcado por el conflicto
Theo de Raadt, fundador de OpenBSD, que en 1995 hizo un fork de NetBSD para imponer su propio estandar de rigor. · Imagen: FAndrey / CC BY 2.0 · Wikimedia Commons
OpenBSD nació en octubre de 1995, cuando Theo de Raadt decidió crear un fork de [NetBSD](/netbsd). De Raadt había sido miembro fundador de NetBSD, pero a finales de 1994 le pidieron que dejara el equipo principal tras una serie de desencuentros sobre el tono y el estilo de trabajo. En lugar de retirarse, tomó el código de NetBSD y arrancó un proyecto nuevo con una idea fija: si controlaba su propio árbol de fuentes, podría imponer un estándar de calidad y rigor que nadie le discutiría.
Ese origen explica buena parte del carácter de OpenBSD. Es un proyecto exigente, a veces áspero, pero coherente hasta el extremo. Lo que le obsesiona no es la popularidad ni el número de paquetes, sino que cada línea de código esté bien escrita.
## Auditorías de código y "secure by default"
El sello distintivo de OpenBSD es la auditoría sistemática del código. Durante años el equipo ha peinado el árbol de fuentes buscando errores clásicos (desbordamientos de búfer, condiciones de carrera, manejo descuidado de memoria) y corrigiéndolos sin esperar a que alguien los explotara. La idea de partida es sencilla: un fallo de seguridad es, antes que nada, un fallo de programación.
A esa práctica se suma el principio de "secure by default". Una instalación recién hecha de OpenBSD arranca con casi todos los servicios no esenciales desactivados. No hay puertos abiertos esperando una conexión que nadie pidió. El sistema es seguro porque, sencillamente, no hace nada que no le hayas ordenado.
De ahí viene uno de los lemas más célebres del proyecto: "Solo dos agujeros remotos en la instalación por defecto, en mucho tiempo". El eslogan ha ido cambiando con los años. En 2002 hablaba de un solo agujero en casi seis años, y se actualizó en 2007 tras una vulnerabilidad de red. Pero la idea de fondo se mantiene: en su configuración básica, OpenBSD ha sido extraordinariamente difícil de comprometer de forma remota.
## OpenSSH, LibreSSL y otras herramientas que usas sin saberlo
OpenBSD iniciando su servidor SSH: OpenSSH nacio aqui en 1999 y hoy es el estandar para administrar servidores en remoto. · Imagen: Hpott / CC BY-SA 4.0 · Wikimedia Commons
La influencia de OpenBSD se mide mejor por lo que ha regalado al resto del mundo. En 1999 el equipo tomó la última versión libre del código de SSH y creó OpenSSH, pasándolo por la misma auditoría que el resto del sistema. Hoy OpenSSH es el estándar absoluto para administrar servidores de forma remota: está en casi cualquier máquina [Linux](/linux-kernel), en [Ubuntu](/ubuntu), en [Debian](/debian), en macOS y hasta en Windows.
En abril de 2014, tras conocerse el desastre de Heartbleed, los desarrolladores de OpenBSD forkearon OpenSSL para crear LibreSSL. Quitaron APIs obsoletas, recortaron más de cien mil líneas de código y pusieron por delante la legibilidad y la auditabilidad. De Raadt no tuvo reparos en describir el diseño de OpenSSL como sencillamente "roto". El proyecto está también detrás de OpenBGPD, una implementación limpia del protocolo de enrutamiento BGP, entre muchas otras herramientas de red.
## Mitigaciones que protegen incluso al código con errores
OpenBSD no se conforma con escribir código correcto: da por hecho que algún fallo siempre se escapará y diseña el sistema para limitar el daño. En 2003 la versión 3.4 introdujo W^X, un esquema según el cual una página de memoria puede ser escribible o ejecutable, pero nunca las dos cosas a la vez. Eso dificulta enormemente los ataques por desbordamiento de búfer.
Más tarde llegaron dos mitigaciones especialmente elegantes. Pledge, disponible desde la versión 5.9 (2016), permite que un programa declare voluntariamente qué llamadas al sistema necesita; si intenta cualquier otra cosa, el kernel lo mata. Unveil, presentada en la 6.4 (2018), restringe qué partes del sistema de ficheros puede ver un proceso. Juntas hacen que un programa comprometido sea casi inútil para un atacante: aunque consiga ejecutar código, no puede tocar nada para lo que no estuviera autorizado. Y casi todos los binarios que vienen con OpenBSD ya llegan blindados con pledge.
## Por qué importa una distribución tan pequeña
OpenBSD nunca competirá en número de usuarios con [Fedora](/fedora), [Arch](/arch) o las grandes distribuciones de escritorio. Tampoco es ese su objetivo. Su impacto es indirecto y profundo: las ideas que nacen aquí terminan adoptadas en otros sistemas, las herramientas que se escriben aquí acaban en todas partes, y el listón de calidad que impone obliga al resto a tomarse la seguridad más en serio.
En un sector que muchas veces premia lo rápido por encima de lo correcto, OpenBSD defiende justo lo contrario con una terquedad casi artesanal. Por eso, aunque pocos lo instalen en su portátil, su cultura de la seguridad sigue protegiendo a millones de personas que ni siquiera saben que existe. Si te interesa el mundo BSD, échale un vistazo también a [FreeBSD](/freebsd) y [NetBSD](/netbsd): tres hermanos con filosofías distintas y un origen común.
