¿Filtrado de egreso en una red de oficina?

PRO: control estricto sobre todo lo que se mueve fuera de su red (y por extensión, gran parte de lo que se mueve en ella).
CON: Sus usuarios sienten el control. Teniendo en cuenta que eres un negocio de desarrollo, tus usuarios son bastante técnicos y probablemente lo reenvíen.
CON: Teniendo en cuenta que usted es un negocio de desarrollo y que sus usuarios son bastante técnicos, es probable que instalen nuevos programas legítimamente, en el transcurso de su trabajo (¿cuánto tiempo pasó hasta que Skype se permitiera?), Y será Es difícil hacer un seguimiento y actualizar los filtros.
PRO: sus usuarios están en efecto restringidos en lo que pueden instalar :)
CONTRA: Ni siquiera considere esto para cada máquina, aunque no es completamente inútil, es mucho más fácil de omitir.
PRO: Como mencionaste, puede bloquear ciertos usos de botnets y otro malware involuntario.
PRO: Puede ayudar hipotéticamente (como primer paso) en la prevención de fugas de datos.

UBER-CON: es trivial omitir en la mayoría de los escenarios maliciosos simplemente haciendo un túnel sobre cualquier puerto / protocolo que tenga abierto (esto incluye muchos tipos de gusanos adaptativos), mientras que en el no casos maliciosos es un verdadero ** tch para tratar.

Conclusión: El filtrado de egreso es una muy buena herramienta para darle control , pero no es muy bueno para seguridad .

Una de las principales ventajas del filtrado de egreso es que lo obliga a comprender qué tipo de tráfico saliente legítimo requiere su personal y sus sistemas. Sin embargo, el inconveniente es que administrar eso llevará tiempo y dinero. Si vale la pena, dependerá de si cree que las amenazas que está mitigando valen la pena.

En términos de cómo se realiza el filtrado de egreso, donde lo he visto hacer es principalmente en las compañías más grandes donde no hay acceso directo a Internet para los usuarios finales, y todo el tráfico saliente tiene que pasar por servidores proxy.

Esto tiene la ventaja de imponer un punto de estrangulamiento en su red donde todo el tráfico de Internet del usuario fluirá y donde se puede inspeccionar, por lo que en teoría puede implementar IDS / IPS / DLP en este punto para obtener una vista de qué contenido está entrando y saliendo de su red.

Por supuesto, para ser realmente efectivo, debe terminar y restablecer todas las sesiones de SSL allí, para poder realizar la inspección de contenido.

Como dije, la pregunta principal es si ese nivel de costo y trabajo adicional vale la pena para una organización determinada.

Especialmente la comunicación entre servidores tiene patrones de comunicación muy predefinidos. Al solo permitir este tráfico, está seguro de que nadie comprometerá accidentalmente el servidor al agregar nuevo software y, por lo tanto, aumentará la seguridad.

Los contras al hacer esto es el trabajo que se necesita para mantener estos filtros. No solo necesita abrir una vez que se implementa el nuevo software, sino que también debe asegurarse de cerrar una vez que ya no se necesita el agua blanda o una vez que se modifica.

El uso de los filtros de egreso lo obliga a conocer y conocer los canales de comunicación utilizados por su servidor y software.

Pros:

• Mayor seguridad
• Mayor visibilidad del tráfico de red
• Mayor control

Contras:

• Aumento de gastos generales ++
• Mayor complejidad

Creo que la respuesta es sí, pero todo depende de su entorno. Como mínimo, las organizaciones deben considerar una red segmentada que controle el ingreso y el tráfico de salida a sus servidores. No estoy de acuerdo con que el filtrado de egreso sea trivial para eludir. Si se implementa correctamente, el filtrado de egreso puede ser una capa defensiva fuerte. Implementado correctamente significa que todo pasa a través de un proxy. Solo se deben permitir excepciones a puntos finales conocidos y de confianza.

Creo que los pros y los contras han sido bien discutidos y todos apuntan que el verdadero problema aquí es, de hecho, el de la protección contra la pérdida de datos.

Estoy de acuerdo en que los Firewalls deben usarse tanto para protegerlo de los demás como al mismo tiempo que otros de usted (es decir, de un brote de gusano) con filtros de salida sensibles. Si te gusta es básicamente una buena política de vecinos.

Sin embargo, como se comentó, son una herramienta contundente que se puede omitir de manera trivial si alguien está buscando filtrar información de la organización.

Por lo tanto, el enfoque debe ser proteger contra la pérdida de datos y utilizar el firewall como un componente de este enfoque. Las organizaciones deben monitorear el tráfico saliente como parte de un enfoque organizativo general de DLP (protección de pérdida de datos), que requiere el monitoreo del tráfico de la red en sí mismo y buscar tendencias / excepciones / volumen.

El problema con el que se encuentra la mayoría de las personas es configurar formas para evitar el flujo de tráfico saliente de DNS y HTTP / TLS. Estoy bastante seguro de que es mejor instalar Whitetrash que incluso usar un firewall (incluidos los de lujo como Palo Alto Networks) o una puerta de enlace web segura .

Si está utilizando una puerta de enlace web de lista blanca como Whitetrash, y ha evitado el tráfico saliente, debe preocuparse por los canales ocultos del DNS. La forma más sencilla es simplemente tener un servidor DNS interno sin conectividad de salida, y luego tener el proxy Squid que ejecuta Whitetrash o bien alojar DNS de Internet o hacer que se conecte a una red separada que aloja servidores de DNS de Internet. Los navegadores obtendrán su DNS a través del proxy. Sí, esto realmente funciona, pero los usuarios no podrán utilizar ningún tráfico de protocolo a Internet que no sea HTTP o SSL (e incluso eso debe pasar por el proxy). Supongo que FTP y Gopher también funcionarían si Squid estuviera configurado para permitirlos.

Esta sería una red frustrante a la que estar conectado, y solo sería posible en los entornos más estrictos con políticas de seguridad opresiva.

No soy un fanático de inspeccionar el tráfico SSL, pero si lo hace, asegúrese de no inspeccionar los bancos / etc. con el uso de una lista blanca. Si está utilizando Whitetrash, probablemente ya tenga una lista extensa para administrar de todos modos.

Me sorprende que la gente diga que "podría" ser una buena idea o "tal vez" es algo bueno. Es absolutamente lo que hay que hacer. No detendrá algo como una conexión tcp inversa, como lo que metasploit y otros pueden configurar en el puerto 80 o 443 en un entorno no proxy, pero evitará que estaciones de trabajo aleatorias envíen correo no deseado u otro malware a la red en algunas situaciones. Agrega complejidad, pero es por eso que nos pagan mucho dinero, ¿verdad? :)