Uno de los problemas a los que nos enfrentamos en organizaciones con una complejidad de red media o alta es la gestión de los permisos que implican a elementos de comunicaciones (switches, cortafuegos, routers, etc.); me gustaría esbozar algunas de las cosas hay que tener en consideración para que la gestión sea posible.
Primero de todo, ante la solicitud de una petición de acceso desde un servidor a otro por parte de algún responsable técnico de algún proyecto TIC de la compañía, hay que tener en consideración dos tipos de aspectos bien diferenciados:
- Aspectos funcionales: Si alguien solicita por ejemplo acceso al puerto de Oracle de un servidor de BBDD, lo primero que hay que evaluar es si desde el punto de vista de negocio, ese permiso debe de ser concedido. Este tipo de accesos deben ser validados por un responsable o autorizador funcional, que puede o no coincidir con el propietario del activo dentro de la organización. Es muy habitual que por agilidad en las gestiones, compañerismo mal entendido, o ausencia de procedimientos formales, este punto se pase por alto y se pase a los aspectos técnicos directamente, sin entrar a considerar la conveniencia de la solicitud desde el punto de vista del negocio.
- Aspectos técnicos: Una vez la autorización funcional ha sido concedida, hay que revisar los aspectos técnicos de los permisos solicitados, para detectar sus implicaciones técnicas sobre otros servicios, el perímetro de la red, problemas de seguridad, etc. Algunas de las cuestiones son: ¿la red origen esta controlada por la organización, o es una dirección externa ajena sobre la que no tenemos información? ¿El protocolo utilizado para la conexión es seguro? ¿Va cifrado? ¿Implica este acceso abrir accesos con redes no confiables? ¿Afectan a la DMZ? ¿Es posible utilizar soluciones alternativas? En cualquier caso, la recomendación es que si el cambio es de cierta relevancia, tiene que haber una auditoria, tanto de caja blanca como de caja negra; esto debería ser obligatorio para cualquier acceso externo a la red corporativa, como por ejemplo el de un nuevo proveedor.
Un punto que siempre es necesario tener en cuenta es la política de filtrado, algo que es un tema recurrente en organizaciones medianas o grandes. Suele habitual que hayan varios cortafuegos, en distintos segmentos de red y en diferentes niveles, protegiendo diferentes redes, conectando delegaciones entre sí, y éstas a su vez con otras organizaciones colaboradoras (proveedores, clientes, etc.). Desde el punto de vista de la seguridad más estricta deberían configurarse los permisos necesarios en todos los cortafuegos intermedios por los que pase la conexión solicitada. Sin embargo, esto suele conducir a una pesadilla de revisión de permisos y quejas por parte del personal de comunicaciones, además de que aporta escaso valor respecto a otras aproximaciones como cerrar únicamente en el cortafuegos que protege la red, dejando la salida abierta desde los otros cortafuegos, para de esta manera facilitar la gestión. Sin embargo esto no es adecuado cuando lo que se quiere es proteger desde una red externa y existen diversos cortafuegos, e incluso tecnologías diferentes para proteger la entrada; en estos casos los permisos deben estar replicados en todos los cortafuegos, para tener la máxima seguridad aportada por estos elementos. Como pueden imaginarse, las configuraciones son múltiples y para cada una la solicitud puede resolverse de diferentes maneras, en función de la infraestructura y las tecnologías implicadas.
No obstante, por lo general deben haber reglas globales que definan ciertos aspectos de la política: si sólo se puede navegar a través del proxy, deberá haber una regla que niegue el tráfico HTTP para cualquier otra IP. Para acabar, hay algunas normas que en mi opinión siempre hay que seguir:
- Las reglas de acceso desde toda Internet a la DMZ deben venir precedidas de una auditoria de ese servicio, tanto de caja blanca y caja negra.
- Las reglas de salida de la DMZ únicamente las necesarias para los servicios que se ofrecen en cada máquina.
- No deberían haber reglas de salida de la DMZ hacia otras redes de la organización, salvo algunas excepciones puntuales, y las estrictamente necesarias.
- Las reglas de salida de otras redes a Internet, solo las necesarias. En equipos de usuario, estas reglas deberían tender a cero, ya que todos los accesos se deberían de realizar a través de un proxy, dns corporativo, etc.
- Tiene que haber una regla que deniegue todo el tráfico que no haya sido habilitado exprofeso. No olviden esto.
- No deben existir reglas de acceso desde una determinada IP a todos los puertos de otra IP (IP -> IP:PTO_ANY), salvo razones justificadas. Esto suele ser habitual cuando surgen problemas de comunicaciones y se quiere descartar al cortafuegos (que tiene el sambenito de ser siempre el problema de todo), pero en ocasiones, cuando se ha descartado como problema, se olvida reestablecer los permisos correctamente.
- Una regla de acceso que permita todo el tráfico desde una IP hacia cualquier puerto de cualquier IP (IP -> IP_ANY:PTO_ANY)
suele seres un indicativo de malas prácticas, porque nadie nunca necesita eso. Por supuesto, su equivalente IP_ANY -> IP_ANY:PTO_ANY es lo mismo que no tener cortafuegos, y debería ejecutarse (figuradamente) al responsable de aplicar esa regla. - Hay que ser muy escrupuloso en la definición y cambio de lo que son las redes protegidas, redes externas, red DMZ, y asegurarse que no hay una configuración errónea en estos conceptos, ya que los problemas pueden ser muy grandes si hay fallos en esto, y más cuando tratamos con sistemas en cuyo funcionamiento influyen mucho estas asignaciones.
- Como última recomendación, debe aprovecharse el cortafuegos para controlar o eliminar cosas que no deberían de existir, como telnet, http, acceso remoto de administración, u otros protocolos que estén prohibidos por política.
En definitiva, en los permisos de los cortafuegos nos encontramos con los problemas habituales de seguridad en los que se juntan los asuntos técnicos, con los asuntos de negocio, y deben considerase siempre ambos aspectos, para gestionar de manera correcta estos aspectos de la seguridad perimetral tan importante en nuestras organizaciones. ¿Alguna otra norma que quieran compartir?
