¿Es seguro ejecutar bitcoind en otro servidor?

Primero, estoy haciendo conceptos aproximados de algunas ideas para servicios habilitados para bitcoin que tengo en mente.

Una cosa que me pregunto es si existe un enfoque de mejores prácticas para ejecutar bitcoind en otro servidor que actúe como backend para otro servidor en particular.

Pensé en algo así:

Tengo un servidor virtual A y un PHP-Webspace simple y simple en otro host B.

A ejecuta mi bitcoind-deamon y solo permite llamadas RPC desde Bs IP.

B realiza sus llamadas RPC a A en un proceso de servidor que no fue activado por un cliente/visitante del sitio web.

¿Qué tan seguro garantizaría tal escenario? ¿Es posible que los nodos, conectados a mi servidor virtual A, identifiquen el propósito del servidor a partir de las transacciones e intenten atacarlo?

Incluso si lo hicieran, tendrían que usar un ataque MiM, porque A solo acepta la IP de B.

¿Qué más puedo hacer para que la comunicación sea más segura? ¿Autorización HTTP, SSL?

Respuestas (3)

¿Es posible que los nodos, conectados a mi servidor virtual A, identifiquen el propósito del servidor a partir de las transacciones e intenten atacarlo?

Sí, si pueden ver lo suficiente de la red, pueden determinar si está originando una transacción o simplemente transfiriéndola. Sin embargo, es más fácil darse cuenta de que está ejecutando RPC a través de un escaneo de puertos.

Hay formas de evitar que un escaneo de puertos encuentre esto, como usar iptables (Ctrl-F 'excepto'). Tenga cuidado, porque el simple hecho de usar DROPseguirá diciendo a los atacantes que hay algo especial en ese puerto.

Gracias por tu consejo (: Esperaré un poco más por otras respuestas antes de marcar la tuya como solución

Si tiene acceso SSH en ambas máquinas, simplemente puede crear un túnel SSH desde la máquina B a la A y reenviar el puerto 8332 a través de él. De esa manera, el comportamiento es como si bitcoind estuviera instalado en ambas máquinas, el tráfico entre las dos máquinas se cifra con SSH y bitcoind solo tiene que escuchar la interfaz de bucle invertido y no sería accesible desde la red.

¿Bitcoind no habla SSL de forma nativa?
Sí, pero todavía tendría que abrir el puerto a la red.
Entonces, no veo cómo un túnel SSH realmente mejora la seguridad en ese caso. Además, descubrí que herramientas como stunnel son bastante inestables y, en el caso general, evitaría agregar partes móviles a la configuración de un servidor a menos que sean absolutamente necesarias.

Entiendo la lógica inicial de poner el bitcoind y las billeteras en un servidor separado, pero piénsalo... si tu servidor web se ve comprometido, entonces no importa dónde esté tu bitcoind... también está comprometido.

Ejemplo; Bitcoind está en el servidor A, el servidor web está en el servidor B. El servidor web B envía solicitudes -> al servidor bitcoind A. . respuestas -> volver al servidor web A.

Por lo tanto, si comprometo su servidor web B, puedo decirle que envíe un mensaje al servidor bitcoind diciendo enviar a la dirección [mi dirección del hacker] y eso es todo. Los fondos se han ido.

Eso es en parte cierto. Pero se puede proteger aún más. Si solo creo un conjunto específico de comandos en mi propia interfaz, que es la única forma en que ambos servidores se comunican entre sí, el atacante también puede usar solo estos. Aunque tiene razón: la mayoría de los sitios web necesitarían admitir algo como makeTransaction (cantidad, desde, hasta)
@Gundon trae un buen punto: podría configurar el servidor bitcoind para que solo acepte un rango predefinido de llamadas rpc permitidas, como: getbalance..etc.
Y si el tiempo no es crítico y está bien realizar todas las transacciones solo una vez al día, también puede proteger con contraseña llamadas rpc específicas. Si escribe un contenedor en el servidor bitcoind, eso también podría hacerse por usuario y la contraseña no necesitaría almacenarse en su servidor público
¿Es seguro ejecutar bitcoind en otro servidor?
RespuestasAquíPolítica de privacidad1y, 0v