Filtrado de egreso del cortafuegos por dominio

  

¿Hay cortafuegos que podamos usar que tengan reglas basadas en el dominio, en lugar de   basado en IP para que nuestras solicitudes de API continúen llegando sin interrupciones aún   ¿Seguimos bloqueando todas las demás conexiones salientes?

Sí, aunque generalmente a través de una funcionalidad de proxy en lugar de un sentido de la regla de firewall tradicional.

Por ejemplo, la Check Blade de software de filtrado de URL de punto le permite restringir el HTTP saliente y las conexiones HTTPS basadas en el nombre DNS al que solicitan acceso, por ejemplo, ya sea GET http://example.com/ HTTP/1.0 o CONNECT example.com HTTP/1.1 solo tendrían éxito si existe una regla que permita el acceso a example.com.

El aspecto del proxy es un resultado del espacio del problema. El DNS inverso no se puede confiar en ninguna forma, forma o forma, por lo que el firewall no puede simplemente invertir la IP a la que el cliente desea conectarse y decidir en función de eso. Tiene que ser dado un nombre por el cliente, y tomar su decisión basada en eso. Los proxies de estilo HTTP funcionan bien para esto porque, incluso cuando es para una conexión encriptada, el cliente entrega el nombre al proxy antes de que se pueda hacer la conexión.

El problema con este enfoque es que basa efectivamente la seguridad en el resultado de las consultas de DNS contra los dominios remotos. El DNS inverso no se puede confiar en nunca porque cualquiera puede poner cualquier nombre para una IP que posea. Pero incluso el DNS hacia adelante carece de la seguridad requerida: puede asumir con seguridad que un atacante moderadamente motivado puede manejar la falsificación o el envenenamiento del DNS si les permite filtrar los datos PCI de su centro de datos.

(Eso no significa que no pueda ser bendecido por un QSA; es un control de compensación razonable. ¡No quiero que piense que es completamente seguro!)

Me abordé el mismo problema , por el mismo razones como usted: hace más de un año, y concluyó que el método "seguro" requeriría algo más que DNS para los sitios remotos, y que el certificado SSL era una cosa razonable para fijar la seguridad. Terminé implementando tal proxy y usándolo para mis propósitos; la respuesta mr.spuratic proporcionada promete hacer lo mismo (la única razón por la que no la he aceptado todavía es porque siento la necesidad de probarlo primero).

La idea de proxy-lista blanca por certificado es realmente interesante / clara que personalmente nunca había pensado antes para este escenario; Definitivamente echaría un vistazo a eso & Vea si sería viable para su situación.

Sin embargo, permítame decirle un poco acerca de la solución más antigua y algo más simple que mencionó usted mismo: configurar una secuencia de comandos para realizar una comprobación de DNS periódicamente para ver qué dirección IP funcionará actualmente. Específicamente: cuando una pregunta relacionada preguntó sobre el Unix & Linux SE hace unos años produjo un par de scripts de muestra para iptables que funcionarán con una regla crontab para verificar la IP de un dominio dado cada cinco minutos (desde DynamicDNS, en ese caso particular) y luego crear una regla que permita < em> tráfico entrante de esa IP a través. No veo ninguna razón por la que no pueda tomar un script preexistente, establecer el tipo de regla en saliente , hacer cualquier otra adición o sustracción útil que desee, y listo. No idealmente elegante, claro, pero tampoco llamaría a este enfoque hacky o gimmicky.

No estoy seguro de si sería correcto copiar & pegue el código de muestra directamente desde que Linux SE pregunta a la que me referí, así que no lo haré. Sin embargo, solo hay dos respuestas, con una muestra de script cada una, en la página de preguntas. No es difícil de leer & ordenar a través de todos

Finalmente, deberíamos abordar lo que puede hacer para proteger mejor sus búsquedas de DNS. En teoría, si su software de pago se está comunicando a las instituciones financieras únicamente a través de https, el servidor de recepción se autentica ante el cliente como legítimo al tener un certificado válido. En ese caso, incluso los resultados de DNS alterados maliciosamente ( ya sea mediante la falsificación de DNS de MitM local, el envenenamiento de la caché de DNS al servidor de resolución al que se está conectando , etc.) que que está enviando la información financiera a través. (Debido a que el certificado para un servidor falso configurado por un atacante no coincidiría con el nombre de dominio). Pero como se supone que debemos estar pensando en la defensa en profundidad y suponiendo que algo podría ir mal con cualquier capa de seguridad (como tal vez un la clave de firma privada de la Autoridad de certificación está comprometida, para que un atacante pueda firmar cualquier servidor que desee con cualquier nombre de dominio), supongamos que queremos algún tipo de protección sólida para las consultas de DNS. Desafortunadamente, eso significa que (a) realmente se ejecuta un servidor DNS - con DNSSec habilitado y configurado correctamente para evitar ataques de envenenamiento - directamente en la máquina local que va a hacer la conexión o (b) utilizando DNSCrypt para establecer una conexión cifrada con OpenDNS o un servidor DNS de confianza (con DNSSec activado) que haya configurado dentro de su red local.

Así que tienes al menos una o dos opciones.