¿Detecta / reacciona a la tunelización de DNS?

La respuesta más sistemática es implementar DNS de horizonte dividido en su infraestructura, de modo que solo se resuelvan las direcciones internas; los clientes deben usar un servidor proxy para conectarse a Internet, y el servidor proxy resuelve el DNS externo para ellos. Esto es particularmente efectivo si su red central no tiene una ruta predeterminada, por lo que se eliminan los paquetes destinados fuera de su red.

La desventaja, obviamente, es que la adaptación de esos controles a un entorno de ejecución probablemente sea una propuesta costosa y compleja ...

No puedo recordar el nombre, pero sé que ha habido al menos un producto comercial que usó el puerto 53 para llamar a casa (aunque no es un túnel TCP / IP completo).

Me gustaría cuestionar seriamente la utilidad (f) de tratar de prevenir este tipo de cosas al intentar bloquear el tráfico de salida específico. Los firewalls nunca tuvieron la intención de filtrar el tráfico saliente, túneles, canales ocultos, etc. de esta manera. Mientras se permita la comunicación, la gente encontrará una forma: HTTP (s) es el medio obvio, pero la gente incluso ha construido pilas TCP / IP completas de prueba de concepto utilizando el correo electrónico como medio de transporte.

Tal vez pueda detectar este tipo de cosas al monitorear el tráfico anómalo, pero eso me parece una preocupación secundaria. Probablemente sea un mejor uso de los recursos para abordar directamente el problema principal que desencadena la preocupación, por ejemplo, malware o fuga de datos.

Me doy cuenta de que esta es una pregunta antigua, pero simplemente la encontré y pensé en publicar mi perspectiva por el próximo tipo.

La respuesta de mejor es la respuesta de caelyx : diseñe la red de manera que solo el proxy puede resolver nombres de host DNS externos. Como señala, es difícil adaptar esto a un entorno de producción.

Un compromiso es bloquear todo udp / 53 de salida a menos que se origine desde su servidor DNS interno y / o permita solo a su servidor DNS externo. Esto mitiga las aplicaciones que simplemente envían datos sobre udp / 53 a un servidor externo arbitrario. no reduce el riesgo de tunelización de DNS, ya que sus servidores DNS internos y externos con gusto reenviarán cualquier tráfico compatible con RFC.

Investigo esto en 2009 y publiqué mis hallazgos en armatum.com . La primera publicación consistía en caracterizar el tráfico DNS "de rutina" y compararlo con las implementaciones típicas de túneles DNS. La segunda fase consistió en crear un algoritmo para detectar el comportamiento inusual; comenzó como un algoritmo de agrupamiento y terminó como una simple visualización de características clave:

(hagaclicparaveryverelvideo,vealaaplicaciónquefuncionaentiemporeal)Esascaracterísticasclaveterminaronenfocándoseenlalongituddelnombredehostconsultado,eltipodesolicitudyelnúmerodecaracteresúnicosenelnombredehostsolicitado.LamayoríadelasimplementacionesdetúnelesDNScompatiblesconRFCmaximizanestosvaloresparamaximizarelanchodebandaascendente,loqueresultaenunaumentosignificativodelosvaloressobreeltráficoDNStípico.

Comoseñaléenlaactualizacióndelasegundapublicación,sivolvieraahaceresetrabajohoy,incluiríalainvestigaciónquesehapublicadodesdeentoncesytambiénutilizarélacuentadesubdominiospordominiocomounacaracterísticaclave.Esaesunatécnicainteligente.

Construíestocomounaherramientaquequeríaenelperímetrodemiredempresarialmi,enfuncióndelosañosenquedesempeñéeserol.Porloquesé,nohayaplicaciones/hardwaredelaindustriadeclaseempresarialqueproporcionenestaprofundidaddeconocimiento.Losmáscomunessonlos"firewalls de nivel de aplicación" que garantizan el cumplimiento de RFC, algo que puede (generalmente) hacer cumplir con la arquitectura de red de DNS dividida más simple descrita anteriormente.

Es de destacar que he visto que los registros de respuesta de TXT están totalmente prohibidos en un gran perímetro empresarial (450k hosts) sin una reducción significativa en la utilidad. Sus puertas de enlace de correo necesitan registros TXT para SPF, pero los otros usos comunes rara vez tienen un lugar en la empresa. No abogo por este enfoque, porque "rompe internet", pero en circunstancias extremas no puedo discutir su sentido práctico.

Y, finalmente, sí, he visto esta técnica utilizada en vivo, aunque es inusual. (refiriéndose a empresas, no puntos de acceso público de pago por uso)

He visto que esto suceda.

Es utilizado principalmente por geeks baratos para evitar tener que pagar por redes inalámbricas públicas. Lo que hacen es configurar un servidor en casa con un falso DNS o simplemente una VPN aleatoria en casa. Y cuando están fuera, es posible que tengan que conectarse a Internet para buscar cualquier conexión inalámbrica abierta y conectarse. Si quiere que pague, intente conectarse a su falso servidor DNS y tada, Internet gratis :). He visto esto hecho en el "mundo real".

Esto también es factible con ICMP o más conocido como PING que crea un túnel de ping entre el cliente y el servidor doméstico y envía los datos de esa manera.

Pero si ves esto en una red "abierta" como una LAN de oficina, probablemente haya algún tipo de malware o similar que no quiera que te metas con él. Si este es el caso, te sugiero que lo mires.

El firewall de próxima generación de Palo Alto Networks se usa regularmente para limitar el uso de un puerto a una aplicación específica. DNS es una aplicación compatible. Se necesitan dos reglas en este orden específico: (1) Aplicación = DNS, Puerto = 53, Permitir (2) Aplicación = cualquiera, Puerto = 53, Denegar

La única forma en la que podría estar seguro de que su enfoque de tunelización específico sería denegado sería probándolo.

Los nuevos métodos de tunelización se desarrollan todo el tiempo y seguramente no hay garantía de que un nuevo método no requiera algún trabajo por parte de Palo Alto. Esto se evidencia en el reciente método de evasión de protocolo de enlace TCP dividido que Palo Alto abordó esta semana.

No tengo conocimiento de ningún otro firewall que le permita implementar un modelo de cumplimiento positivo en el nivel de la aplicación en este momento como lo describí anteriormente.

Revelación completa: proporciono servicios de seguridad de red, incluida la reventa de firmas de Palo Alto Networks, Check Point y Juniper.