Tengo un conjunto de nombres de dominio que se utilizan internamente y no deseo que se filtren al mundo exterior (ya que eso le daría al atacante un conocimiento avanzado del diseño de la red interna). DadoTransparencia del certificadoParece que está ganando impulso, ¿cuál es el consenso general sobre la mejor manera de tener nombres de dominio privados? ¿Certificados autofirmados? ¿Certificados comodín? ¿Algo más?
Respuesta1
Tengo un conjunto de nombres de dominio que se utilizan internamente.
Para usos internos únicamente, puede configurar una CA privada, instalar su certificado en sistemas internos y emitir certificados internos usted mismo.
Si tuuso internoLos servidores se usan de alguna manera externamente, no funcionarán a menos que los clientes externos agreguen una excepción para su certificado. Eso no impedirá que los atacantes externos descubran los dominios internos y los ataquen. En este caso, utilice un certificado comodín. El uso de un certificado de CA interno o autofirmado molestará a los usuarios externos y no hará nada para protegerlo contra los atacantes (como la mayoría de los esquemas DRM).
Respuesta2
Si la filtración de nombres de host es parte de su modelo de amenaza, entonces CT probablemente no sea la única fuente de dicha filtración. Piense en encabezados de correo electrónico, registros, monitoreo, compiladores,... muchas herramientas podrían eventualmente derramar nombres de sistemas (ya sean nombres de host o simplemente parte de los certificados) en espacios de acceso público. Más bien, trabaje en las razones subyacentes por las que desea que se mantengan confidenciales.
No tendrás que ocultarlos si no tienen nada de secreto. Si revelan alguna información, generalmente es porque estás usando los nombres para
- ayudar a los administradores a navegar por su propia red o
- Ayude a sus compañeros de trabajo a recordar qué URL escribir.
- probar un sistema internamente antes de la operación comercial
Para los 3 problemas, existen mejores soluciones. El principal problema de 1. es que los nombres de los sistemas generalmente terminan no coincidiendo con las funciones del sistema después de una serie de cambios. El principal problema con 2. es que sus compañeros de trabajo nunca deberían escribir las URL a mano; piense en estafas de tipo dominio mal escrito. Los nombres en clave resuelven 3.
Recomendación: nombre sus servidores internos con un esquema consistente, pero por lo demás aleatorio.Transmitir relaciones sistema <> roles a través de medios completamente diferentes. Por lo general, se dirige a sus compañeros de trabajo por sus nombres, no por sus funciones; haga lo mismo con sus servidores internos.
Nuestra wiki interna está alojada en lake.example.org. Lake no significa nada, simplemente es suficientemente diferente de cube.example.org(la colección de registros). Pero el malvado atacante sólo sabe que hay 8 dominios internos, lo que no sorprende teniendo en cuenta el tamaño de la organización. Si quiere saber más, tendrá que visitarnos y leer las etiquetas con los nombres.
Respuesta3
Esta parece una decisión bastante simple a menos que me esté perdiendo algo.
Si decide que la privacidad de los datos que quedarían expuestos a través de la Transparencia de Certificados es más valiosa que la conveniencia de tener certificados firmados por una CA de confianza pública, usted puede:
- No utilice certificados (imprudente e inviable con software moderno)
o
- Ejecute su propia CA y solucione los inconvenientes de configurar clientes para que confíen en ella.