NGFirewall Evolution: Políticas reputacionales por usuario

Hoy he estado en un evento de uno de esos gigantes de la informática que arrastran tanta historia como portfolio. El asunto es que entre sus filas cuentan con gente muy orientada a la innovación en los sistemas integrados.
Desde el principio los sistemas informáticos pertenecían a las empresas y los trabajadores hacían un uso más o menos personal, para acceder a información corporativa básicamente.  El ocio se realizaba con el teléfono, el salas, en el bar....
Ahora todo esto se desarrolla dentro de nuestros sistemas de información y bajo nuestra responsabilidad, pero además tenemos muchos más sistemas exógenos. Por ejemplo los móviles, las "tablet" o los portátiles personales. Sin contar las legiones de consultores externos conectados en salas adhoc vía wifi o con NAC de lógica "boleana".

De forma que parte de la infraestructura no es de la organización, parte de la información almacenada y transportada tampoco y se presupone la utilización de los recursos de la empresa para ocio y networking empresarial.
Por si faltase algo a esta mezcla explosiva, tenemos que añadir que los usuarios son móviles, tenemos oficinas distribuidas en diferentes países y aplicaciones publicadas en la nube.

Con todo este escenario he proyectado una nueva innovación en IPs a los firewalls, políticas de usuario por reputación:

1. Asignar una cuota en una SAN, en función del contenido y antiguedad de los ficheros de forma automática.
2. Penalizar o proteger el uso de ancho de banda en función de la categorización de las recursos visitados.
3. Aplicar inspecciones, auditorías y capturas de tráfico en función del histórico de un usuario.
4. Restringir el acceso a redes o servidores en función de comportamientos de modificación de usuarios con comportamiento similar en la red. 
5. Aplicar policy based routing hacia líneas de bajo coste para aquellos usuarios con categorización histórica no productiva.
6. Desencriptar el tráfico de aquellos usuarios que tengan incidentes de fuga de información.

Como os podéis imaginar este producto no existe, pero sería increíblemente fácil gestionar una dispositivo con cierta inteligencia para evolucionar la configuración inicial.

hth,

Robclav

Diez conceptos básicos para configurar JUNIPER SA o MAG SSL VPN

Formalmente hablamos de Juniper Secure Access y Junos Pulse Server.

Sin duda el producto más flexible, potente y maduro del mercado. Es el rey de las VPN SSL, siendo un appliance dedicado donde hay que tener en cuenta el precio de la licencia y mantenimiento y no del hardware.
Bueno sin más rollo, os dejo el resumen de los diez términos clave para configurar y entender estas maravillas:


-Recursos.  Los recursos son aquellas aplicaciones, ficheros o sistemas a los cuales se va a dar permiso de acceso.  La definición de estos recursos deben ir acompañados de una política de seguridad de acceso a ellos. Y posteriormente para ser utilizado se debe asociar a un rol como mínimo.

-Role. Es una agrupación lógica de  acceso a recursos a los que se van a dar acceso así como de los mecanismos para hacerlo. S
Resource-Policy(Utilizar mejor la autopolicy). Es las reglas de seguridad que se aplican a los roles para poder acceder a los recuros. Las mismas pueden ser modificadas en tiempo real por comprobaciones del host-checker.
-Role-Mapping. Es una serie de reglas consecutivas, de más específico a más genérico, que asignan finalmente unos roles. Estas reglas se pueden hacer por:
-Nombre de usuario
-Nombre de grupo del directorio activo
-Nombre de atributos de LDAP/certificados de usuario.
-Dia y/o hora de conexión.
-Ubicación.
El resultado es la asignación de los roles a los Realms o perfiles de conexión.Comprueba todos los roles, siempre y cuando no se especifique lo contrario.

-REALM. Conjunto de usurios o escenario de autenticación, que es lo que más se parece a un perfil de conexión que engloba desde sign-in page, a la forma de autenticación, los roles, los recursos, las reglas de host-checker o la personalización de la web.
Dentro se configura:
-Las Authentication Policies.
-Host checker
-Evaluar las condiciones.
-Requerirlo y aplicarlo.

-Sing-in Pages (Puntos de entrada). Agrupados en Sing-in Policies de los cuales por defecto existen dos:
-Path de administración "http://x.x.x.x/admin"
-Path de entrada de los usuarios "http://x.x.x.x"
Pero pueden ser tan variados como queramos, permitiendo una asociación de realm por puntos de entradas. Eso implica separación por idioma, recursos publicados, países, o servidor de validación.
Un usuario solo puede entrar a un solo REALM.
-Tipos de tunelización disponibles.
-Client-less(Webification). Portal Web donde se publican las aplicaciones disponibles para ese realm. Acceso vía navegador.
-Network Connect. Modo tunel SSL emulando un cliente IPSEC clásico.
-JSAM-.Port forwarding por puerto. Queremos solo las conexiones a Citrix, de forma que localmente se escucha al localhost:3389, se encapsula y se envía. Javascript multiplataforma.
-WSAM. Port forwarding muy fléxible. Se puede interceptar puertos pero sobretodo útil a nivel de aplicación. Por ejemplo, se puede monitorizar el proceso iexplorer.exe, y todos los puertos que abra, se encapsulan y se envía. Es un active-X, limitado a Windows.
-Aplicaciones cliente-servidor integradas. Se puede inyectar texto en la aplicación cliente para emular un single-Sign-ON. Muy potente.
-End-point-Security(Host checker). Javascript para la pre/post-comprobaciones del cliente. Puedes comprobar el idioma del cliente, el navegador, si tiene un fichero abierto, los parches del sistema actualizados. Se suele utilizar para seleccionar el REALM adecuado para el usuario.

El log, con un simple click, vas haciendo queries. Muy práctico y potente.