La forma más sencilla sería no permitir el reenvío de IP entre las interfaces internas y externas. De esa manera solo se permitirá el tráfico HTTP / HTTPS que pasa a través del proxy. Pero esta solución simplista no se puede utilizar si se debe permitir el tráfico no HTTP (S), por ejemplo, SMTP, IMAP, POP o DNS. Por lo tanto, para que sea aceptable, debe configurar reglas de filtrado que permitan explícitamente algunos puertos (o algunas máquinas) al tiempo que prohíbe HTTP (S). En organizaciones medianas a grandes, configuraría sistemas de correo y DNS que podrían usar esos puertos a través del firewall externo, mientras que a todas las máquinas cliente solo se les permitiría usar el proxy HTTP (S).
El resto no es más que mi opinión. El servidor de Windows 2012 es un excelente sistema operativo para crear servidores internos, porque si ofrece servicios ricos a través de AD. Pero para construir firewalls seguros expuestos a Internet, preferiría sistemas más simples como Linux o BSD mejor, porque se pueden simplificar más fácilmente para contener solo las aplicaciones y servicios requeridos para ese uso: por lo general, no hay una interfaz gráfica de usuario X11, pero sí una interfaz confiable. Servicio de filtrado de IP (IPTABLE, IPF, IPFilter, etc.) y opcionalmente (*) algunos proxies. La razón detrás de esto es: cuanto menos servicios se abren en el host del bastión, menos vulnerabilidades potenciales. Por supuesto, depende en gran medida del tamaño de su red y de su conocimiento: si usted es un experto en proteger servidores de Windows y sabe poco o nada sobre la configuración básica de Unix, esto no será una opción ...
(*) ya que algunos proxies pueden ser complejos en una configuración o en el punto de vista del tamaño del código, puede tener sentido no instalarlos en el host del bastión en sí, sino en otro servidor