RPC de Bitcoin Core: lo que no demuestra un cortafuegos activo

Financiación: Este artículo no contiene enlaces de afiliación para comprar directamente. CypherpunkGuide puede recibir comisiones a través de las guías de compra enlazadas.

El nodo funciona, la sincronización avanza y el cortafuegos aparece como activo. Cada observación aporta información útil. Ninguna resuelve por sí sola quién puede conectarse a la interfaz que permite administrar el nodo.

RPC, siglas en inglés de llamada a procedimiento remoto, es la interfaz que otros programas utilizan para pedir información a Bitcoin Core o darle instrucciones. Es distinta de la comunicación entre nodos de Bitcoin, conocida como P2P. Aceptar una conexión entre nodos no justifica permitir el acceso a la administración. Según las billeteras habilitadas y los permisos, el acceso RPC puede poner fondos en riesgo y revelar información privada. La documentación de seguridad de Bitcoin Core advierte que no se debe exponer RPC a la internet pública.

La cuestión es delimitar qué demuestra cada comprobación. Es el mismo criterio que aplicamos en la guía de verificación de autocustodia: un indicador tranquilizador solo resulta útil si conoces sus límites.

Qué permite concluir el análisis de las fuentes

#

Este análisis sigue el código de Bitcoin Core v31.1 y la documentación de Docker. No mide un nodo en funcionamiento, un puerto abierto ni el comportamiento del cortafuegos de una máquina.

El código de Core corresponde al commit —una revisión concreta— 9be056a8a72b624dae9623b2f7bded92c2a21c91, obtenido el 10 de octubre de 2026. El paquete de evidencias descargable reúne siete archivos públicos del código fuente, el registro de su obtención, sus huellas SHA-256 y el análisis de ocho casos. Estas huellas permiten comprobar los archivos guardados; no equivalen a verificar la firma de un programa compilado. La documentación de Docker se consultó el 10 de octubre y se volvió a comprobar el 11 de octubre de 2026. Puede cambiar y no constituye una prueba realizada con una versión concreta de Docker Engine.

No se inició ningún servicio ni se utilizaron billeteras, secretos de autenticación o fondos reales. Los ocho casos conservan not_tested —no probado— como resultado observado. El aporte consiste en relacionar lo que indica una configuración con las evidencias que aún hacen falta para saber si se puede acceder al servicio. Los tres archivos descargables conservan los materiales originales compartidos, incluidos el código fuente, los campos para procesar los datos y las notas de análisis. No se han traducido íntegramente al español.

Escucha, permisos y autenticación son controles distintos

#

La dirección en la que escucha Bitcoin Core, las direcciones de los clientes admitidos, la autenticación y las operaciones autorizadas se controlan por separado. Superar o no superar un control no determina el estado de los demás.

Un punto de escucha es la combinación de dirección y puerto en la que un programa acepta conexiones. Las direcciones de bucle local, o loopback, como 127.0.0.1 y ::1, apuntan al propio entorno de red. Docker ejecuta aplicaciones en contenedores, entornos separados dentro de una máquina anfitriona. En un contenedor con el aislamiento habitual, el bucle local es distinto del de la máquina anfitriona.

En el código del servidor HTTP de la revisión analizada, si rpcbind o rpcallowip carece de valores, Core recurre a direcciones de bucle local como candidatas para la escucha. Esto no significa que descarte la lista independiente de direcciones de origen permitidas. Aunque ambas opciones tengan valores, abrir los puntos de escucha y comprobar los permisos de los clientes siguen siendo procesos distintos.

No añadas estas opciones a una configuración solo para conseguir que una prueba funcione. Averigua primero cuáles utiliza realmente el proceso en ejecución. Según la documentación de la interfaz RPC de esa revisión, bitcoind, el programa que funciona sin interfaz gráfica, habilita por defecto el modo servidor; la aplicación gráfica no lo hace. Que funcione la consola de depuración de la aplicación gráfica no demuestra que exista un punto de escucha HTTP.

Tampoco basta con comprobar el puerto 8332. Es el puerto RPC predeterminado de la red principal de Bitcoin en la versión analizada; otra red de Bitcoin o una opción personalizada pueden utilizar uno distinto. rpcport sustituye al puerto predeterminado de la red. Si rpcbind incluye un puerto explícito, este tiene prioridad para ese punto de escucha. Con contenedores, distingue además el puerto de la máquina anfitriona del puerto del contenedor.

Docker añade rutas que el estado de UFW no permite descartar

#

En Linux, cuando Docker usa redes de tipo puente, un cortafuegos UFW activo no demuestra que un puerto publicado de un contenedor esté bloqueado. UFW es una herramienta para administrar el cortafuegos de Linux; una red de tipo puente conecta los contenedores mediante una red virtual en la máquina anfitriona. La documentación oficial de Docker sobre cortafuegos explica que el tráfico de los puertos publicados se redirige antes de las cadenas INPUT y OUTPUT, los recorridos de reglas que UFW utiliza normalmente.

La documentación sobre publicación de puertos añade condiciones. Si se omite la dirección de la máquina anfitriona, normalmente se usan todas sus direcciones, salvo que se haya cambiado ese valor predeterminado. Aun así, una correspondencia entre puertos no demuestra que Core escuche dentro del contenedor.

Publicar en el bucle local tampoco garantiza que estén cerradas todas las rutas. Docker documenta una excepción en versiones anteriores a 28.0.0: otras máquinas del mismo segmento de red local, o capa 2, podían acceder a esos puertos. El acceso directo a las direcciones del contenedor depende también de las rutas, del modo de la puerta de enlace y de opciones como trusted_host_interfaces. Revisa por separado las conexiones dirigidas a la máquina anfitriona y al contenedor.

Estas observaciones no permiten dar un comando de reparación universal para Docker Desktop, Swarm, todos los controladores de red o todas las implementaciones del cortafuegos. La hoja adjunta pide identificar el entorno real. El trabajo que exige mantenerlo forma parte de la decisión de alojar tus propios servicios.

Ocho casos para localizar las evidencias que faltan

#

Los ocho casos son comprobaciones que debes documentar, no ocho pruebas de seguridad superadas. Descarga la hoja de revisión en blanco y el registro de casos basado en las fuentes. Si compartes una copia, excluye las credenciales, las direcciones reales y los detalles que permitan identificar la infraestructura.

Cuando recurre al bucle local, la función que abre los puntos de escucha en la revisión analizada intenta usar ambas familias de direcciones. Sin embargo, comunica éxito si logra abrir al menos uno. Un inicio aparentemente correcto no demuestra, por tanto, que se hayan abierto ambos. Docker también permite que IPv4 e IPv6 tengan modos de puerta de enlace distintos.

Completa la hoja en este orden:

1. Identifica el cliente que debe administrar el nodo y el destino al que debe llegar. En las notas compartidas, usa etiquetas que describan la función de cada equipo en lugar de datos identificativos.
2. Registra las opciones efectivas que no contengan secretos y los puntos de escucha observados. Un archivo de configuración de ejemplo no demuestra qué cargó el proceso en ejecución. No exportes configuraciones completas ni salidas de procesos que puedan incluir credenciales.
3. Documenta las rutas del anfitrión y del contenedor para cada familia de direcciones. Cuando corresponda, incluye la función del router; la auditoría del router doméstico, en inglés trata ese límite por separado.
4. Si pruebas el acceso, hazlo solo sobre sistemas propios o para los que tengas autorización. Anota desde dónde se conecta el cliente, la función del destino, la familia de direcciones, la hora y el tipo exacto de resultado. Nunca expongas RPC a la internet pública para facilitar la prueba.
5. Marca como unknown —desconocido— lo que carezca de evidencia. Resuélvelo antes de confiar en que solo los clientes previstos pueden acceder a la administración.

Un rechazo HTTP demuestra una respuesta, no un puerto cerrado

#

Un error HTTP indica que algún servicio HTTP respondió por la ruta probada. No demuestra que el puerto fuera inaccesible. Si hay un proxy —un intermediario que recibe o reenvía solicitudes—, tampoco identifica a Bitcoin Core como quien respondió.

El código que procesa RPC en la revisión analizada devuelve 401 cuando falta la autenticación o falla en el recorrido de solicitud correspondiente. Un 403 puede deberse al rechazo de la dirección de origen o, en una etapa posterior, a las restricciones sobre los métodos que puede usar un usuario autenticado. El código de estado, por sí solo, no identifica el control que rechazó la solicitud.

La autenticación tampoco cifra el tráfico RPC. Usar una VPN —una red privada virtual—, un túnel SSH —una conexión cifrada entre equipos— o un servicio onion de Tor no garantiza por su nombre que el anfitrión sea de confianza, que los extremos tengan el acceso adecuado o que no queden otros puntos de escucha expuestos. La documentación de Core advierte expresamente contra exponer RPC al público, incluso mediante un servicio onion público. Evalúa el medio de transporte junto con quién controla sus extremos y quién puede acceder a ellos.

Fuentes y límites de la verificación

#

Las afirmaciones sobre Core se apoyan en el código de v31.1 fijado en la revisión indicada. Las de Docker proceden de la consulta de documentación en las fechas señaladas. Se comprobaron las copias archivadas de los dos documentos de Docker. Las cinco copias de Core conservan los archivos de código fuente sin la interfaz de GitHub; su contenido coincide exactamente con el código fijado que se usó en este análisis.