O cifrado de conexión de Firebird 3 e a VPN son dúas fronteiras

A VPN conecta, o cliente abre unha sesión e todos asumen que a conexión á base de datos está protexida. Acaban de mesturarse tres cousas distintas. Se o listener é accesible, se o servidor aceptou o usuario e se Firebird negociou o cifrado de conexión son mecanismos separados con probas separadas. O túnel responde só á primeira, e só para as fontes que vostede permitiu.

Dúas fronteiras que non se solapan

A fronteira da VPN protexe os paquetes entre un cliente e unha pasarela. O cifrado de conexión de Firebird protexe o protocolo de base de datos entre a biblioteca de cliente e o proceso do servidor. Ambos poden estar presentes e ningún substitúe o outro.

Se o túnel remata antes do host da base de datos, o tráfico máis alá só queda protexido polo que negociase a sesión de base de datos. É nese oco onde unha revisión adoita atopar a sorpresa. O diagrama do túnel remata nunha pasarela, e a conexión que leva a súa consulta continúa máis alá. Calquera que lea ese diagrama despois herda a suposición.

Fronteira un: quen pode abrir o listener

Identifique o enderezo real do servidor e o porto configurado, que é 3050 salvo que se cambiase, e despois permita só as fontes VPN aprobadas nos devasas do host e da rede. Teña en conta calquera tradución de enderezos na pasarela VPN e dea ao host da base de datos unha ruta de retorno ao conxunto de clientes se a pasarela está separada.

Despois demostre o negativo. Unha ruta externa que debería denegarse debe seguir denegada, porque abrir o túnel non restrinxe por si só o listener de Firebird.

Fronteira dous: que negocia Firebird

Firebird 3 introduciu un marco de cifrado de conexión cunha política de servidor que pode desactivarse, activarse ou esixirse. A política fixa o mínimo. A sesión real segue dependendo da biblioteca de cliente que carga a aplicación e dos complementos que admiten ambas as partes.

En as notas da versión de Firebird 3 Arc4 figura como complemento de cifrado de conexión predeterminado desa versión. Arc4 é un valor predeterminado histórico, non unha recomendación de cifrado moderno, e non é o mesmo que a protección VPN externa.

A autenticación é unha terceira variable na mesma negociación. O servidor acepta un conxunto de complementos de autenticación, a biblioteca de cliente ofrece un subconxunto e ambos teñen que solaparse.

A trampa de Legacy_Auth

Admitir Legacy_Auth esixe relaxar a política predeterminada de cifrado obrigatorio do servidor. Ese é o custo de compatibilidade documentado, e por iso baixar a política para silenciar un erro de conexión é un cambio de seguridade e non unha corrección.

Se un cliente falla de súpeto tras actualizar o servidor, compare as listas de complementos antes de debilitar nada. O fallo adoita ser un desaxuste de negociación, e a resposta é un complemento admitido en ambos os lados.

Comprobe a conexión que importa

Nunha compilación que proporcione a variable de contexto, esta consulta informa do estado de cifrado da conexión actual:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

Execútea a través da conexión propia da aplicación, non dunha sesión de administrador no mesmo servidor. Unha conexión de administración cifrada non di nada sobre a sesión doutra biblioteca de cliente, e unha compilación máis antiga que non admite a variable non é proba de que o cifrado estea desactivado.

Anote xuntos a versión da biblioteca de cliente, a compilación do servidor e o resultado, porque ningún deles por separado é lexible.

Permisos e a ruta de actualización

Restrinxir as fontes e cifrar o transporte non substitúen a autenticación nin os permisos de mínimo privilexio. Comprobe os permisos do usuario normal da base de datos sobre os obxectos que realmente toca.

Por último, trate un despregamento de longa vida como unha cuestión de mantemento. Un túnel non fai segura indefinidamente unha biblioteca de cliente obsoleta, e unha ruta de actualización admitida é máis barata que descubrir que o complemento que necesita foi eliminado.