filosofía del firewall

Es común y es malo.

He arreglado esto en el pasado. En una gran organización financiera, tomó cerca de 4 horas por semana durante dos años.

• Paso 1: aprobar y comunicar una nueva política para bloquear aplicaciones P2P no aprobadas. Bloquealas.
• Paso 2: supervise el puerto de salida 25, identifique el tráfico legítimo, hable con los equipos que lo originaron, repárelo o cree excepciones. Imponer la nueva regla.
• Paso 3: instala un proxy. Repita el paso 2 para los puertos 80 y 443 (excepto el proxy)
• Paso 4: monitorea el segmento de usuario para otro tráfico saliente. Comunicarse con equipos, documentar excepciones.
• Paso 5: Bloquea todo lo demás en el segmento de usuarios.
• Paso 6: supervise el segmento DMZ para ver si hay otro tráfico saliente. Comunicarse con equipos, documentar excepciones.
• Paso 7: Bloquea todo lo demás en el segmento DMZ.

Cada paso mejora su seguridad y hace que la empresa se sienta más cómoda con los cambios. Necesitas responder a los problemas a medida que surgen. Que quema más tiempo.

Cambiarlo todo de una vez podría funcionar ... pero será un infierno y al final, no tendrás los procesos y la documentación para mostrarlo, solo un queso suizo de las últimas noches de los equipos que gritan que el XYZ está roto o el informe Dobson ya no se está generando.

Si estás hablando de una organización muy pequeña, hazlo de una vez y deja que la gente grite. Puede responder rápidamente sin la separación de tareas para que sea más rentable.

En una organización grande, todo es un registro de cambio o incidente. Romper las cosas será mucho más costoso que su tiempo a través de todo.

Su diferencia de opinión es exactamente la diferencia entre dos filosofías distintas con respecto al control de acceso a la red. Estas filosofías también demuestran el clásico compromiso entre seguridad y usabilidad.

Blacklisting , similar a la postura de administrador de tu firewall, es una práctica de permitir que todos menos una lista definida de patrones de tráfico a través de. Esto es lo más fácil de hacer en términos de facilidad de uso y administración, pero es bastante inseguro y casi ingenuo. Afirmar que las listas negras es seguro, es suponer que conoce todas las posibles amenazas a su red y las ha agregado a su lista de denegación. Saber todas las amenazas posibles es obviamente imposible e, incluso en ese caso, incluirlas de forma selectiva en una lista de denegación haría que la lista fuera enorme e inmanejable.

Lista blanca , la filosofía con la que te "criaron" (por así decirlo), es exactamente lo contrario. Supone que todo el tráfico debe ser denegado, excepto el que se especifica en su lista de permitidos. Esta es la opción más segura, pero también puede tener un gran impacto en la usabilidad y la sobrecarga de administración. Se basa en la regla de seguridad "Principio de lo menos ...": usted solo permite a sus usuarios / computadoras / programas / etc. para hacer lo que realmente necesitan hacer. El lado positivo de esto es que usted sabe exactamente qué es lo que su red puede hacer. Si bien esto solo no lo hará inmune a todas las amenazas, lo ayudará a protegerse contra una buena parte de las incógnitas. Todavía habrá formas de evitar esto (por ejemplo, con la tunelización a través de puertos / protocolos permitidos) pero será mucho más difícil que contra un enfoque orientado a la lista negra. Por supuesto, la desventaja de este enfoque es que a menudo puede ser más difícil solucionar problemas con aplicaciones en red mientras se mantiene la regla "Principio de menos ...".

Cada enfoque tiene sus méritos y sus debilidades. Al final, depende de usted (o de los ejecutivos de su empresa) decidir cuál es el enfoque más razonable para su organización. Un buen enfoque de defensa en profundidad que incluya medidas de protección que no sean solo el firewall perimetral también es esencial para mitigar los riesgos dejados abiertos por cualquier configuración de firewall o hardware que elija.

Tener un rechazo implícito en la parte inferior de la ACL del firewall es estándar. Está siendo perezoso al permitir todo el tráfico saliente. Este es el sueño de un bot net.

Básicamente, si infectas una máquina, esa máquina ahora puede iniciar una conversación en cualquier puerto para regresar al servidor de comando y control.

• O, si tiene un proxy por el que deben pasar las personas para filtrar, pueden simplemente desactivar el proxy y omitir el filtrado.
• O ahora pueden omitir el firewall de su correo electrónico y enviar correo no deseado directamente.
• O pueden omitir la prevención de pérdida de datos que ha configurado en su servidor de seguridad de correo electrónico.

Diablos, sus zonas de seguridad no importan en ese momento porque tiene un permiso implícito. Entonces, si un atacante obtiene una casilla en su red, esa casilla puede llegar a cualquier parte dentro . Oh las posibilidades Puro genio.

Desde una perspectiva de estado, es común que todas las conexiones salientes nuevas sean las predeterminadas. La idea es que los usuarios estén haciendo nuevas conexiones a servidores fuera de la red. Si utiliza un método de inclusión en la lista blanca y solo permite que los puertos 80 y 443 salgan, entonces bloquea cosas como las redes de bots para que no usen su punto de apoyo en su red para que no lleguen a casa en puertos no estándar (6667), a menos que usen el puerto 80, que es casi siempre abierto.

Puede haber una discusión válida acerca de los riesgos cuantificados de permitir todas las conexiones salientes nuevas, pero el enfoque "más seguro" es agregar a la lista blanca las conexiones salientes, aunque no esté protegiendo su red mucho más que permitiéndolas todas.

En mi caso, estoy muy interesado en saber qué tráfico sale en puertos inusuales y en saber qué se está comunicando, pero tengo recursos para que ese análisis sea valioso para mí.

En primer lugar, los firewalls emplean un modelo de seguridad positivo, lo que significa que incluyen en la lista blanca el bien conocido y todo lo demás está bloqueado. La alternativa es un modelo de seguridad negativo, también conocido como lista negra. Los modelos de seguridad positivos son las mejores prácticas, punto.

¿Su administrador de firewall tiene un historial como administrador de red? Mi historial es que muchos administradores de red que se convirtieron en administradores de cortafuegos piensan de esa manera, ya que los administradores de red se dedican a permitir las comunicaciones y no tienen mucha seguridad. Muchos agujeros de seguridad se deben a que los administradores de red configuraron la arquitectura base de muchas compañías (antes de que las preocupaciones de seguridad fueran tan predominantes) y eso es algo muy difícil de revertir.

Tiene una preocupación legítima y NO es una buena práctica que los firewalls empresariales permitan todo el tráfico saliente. Esta es la razón número 1 por la cual la exfiltración de datos es exitosa.

En mi opinión, como profesional de la seguridad, también buscaría el descifrado SSL y el filtrado de la capa de aplicación para que no solo abra el puerto 443 u 80, sino también las aplicaciones específicas a través de esos puertos. Sin embargo, a veces es una venta difícil para organizaciones no centradas en la seguridad. Se producen falsos positivos (que deniegan el tráfico legítimo), especialmente con aplicaciones personalizadas.

Mi 2c del pirata informático estándar de su empresa. Tenga en cuenta que no, y nunca he hecho esto, solo es teoría . Bloquear puertos es inútil porque:

• Tienes que permitir HTTPS. Permitir HTTPS me permite omitir todas las restricciones y comunicarme con mi VPS personal en el puerto 443. Después de eso, puedo hacer todo lo que SSH habilita, incluido pero no limitado a: descargar archivos prohibidos por el proxy, navegar por la web usando mi VPS como un proxy y la creación de un túnel SSH inverso desde el servidor remoto que me permitiría acceder a cualquier puerto de mi computadora a través de Internet.

Por lo tanto, podría ser que la práctica estándar es "deshabilitar todos los puertos y sentirse seguro", pero es necesario habilitar las comunicaciones cifradas, que hacen que todas las reglas de firewall sean discutibles.

Además, hay excusas perfectas para usar SSH en el puerto 443 .

Una vez más, solo mi 2c, no vale la pena el dolor masivo en el culo para tus usuarios.