EN ESTA PÁGINA
Recuperación de roles de usuario y proceso de búsqueda de directivas
Obtener información de nombre de usuario y rol a través de la autenticación de firewall
Configuración de un firewall de rol de usuario para la redirección del portal cautivo
Ejemplo: configuración de un firewall de rol de usuario en un dispositivo serie SRX
Rol de usuario específico de la plataforma Comportamiento de las políticas de seguridad de firewall
Rol del usuario Políticas de seguridad de firewall
Las directivas de firewall de roles de usuario permiten a los administradores permitir o restringir el acceso a la red para los usuarios en función de los roles que se les asignan. Los firewalls de rol de usuario permiten una mayor mitigación de amenazas, proporcionan recursos forenses más informativos, mejoran el archivado de registros para el cumplimiento normativo y mejoran el aprovisionamiento de acceso rutinario.
Descripción de los firewalls de rol de usuario
La aplicación de la seguridad de red, el monitoreo y la presentación de informes basados únicamente en información IP pronto no serán suficientes para la fuerza laboral dinámica y móvil de hoy. Mediante la integración de políticas de firewall de usuario, los administradores pueden permitir o restringir el acceso a la red de empleados, contratistas, socios y otros usuarios en función de las funciones que se les asignen. Los firewalls de rol de usuario permiten una mayor mitigación de amenazas, proporcionan recursos forenses más informativos, mejoran el archivado de registros para el cumplimiento normativo y mejoran el aprovisionamiento de acceso rutinario.
Los firewalls de rol de usuario desencadenan dos acciones:
Recuperar información de usuario y rol asociada con el tráfico
Determinar la acción a realizar en función de seis criterios de coincidencia en el contexto del par de zonas
El campo de identidad de origen distingue un firewall de rol de usuario de otros tipos de firewalls. Si la identidad de origen se especifica en cualquier política para un par de zonas determinado, se trata de un firewall de rol de usuario. La información de usuario y rol debe recuperarse antes de que se produzca la búsqueda de directivas. Si la identidad de origen no se especifica en ninguna directiva, no es necesario buscar usuarios ni roles.
Para recuperar información de usuario y rol, se busca en las tablas de autenticación una entrada con una dirección IP correspondiente al tráfico. Si se encuentra una entrada, el usuario se clasifica como usuario autenticado. Si no se encuentra, el usuario se clasifica como un usuario no autenticado.
El nombre de usuario y los roles asociados a un usuario autenticado se recuperan para que coincidan las directivas. Tanto la clasificación de autenticación como la información de usuario y rol recuperada se usan para que coincida con el campo de identidad de origen.
Las características del tráfico se ajustan a las especificaciones de la directiva. Dentro del contexto de la zona, la primera directiva que coincida con el usuario o rol y los cinco criterios de coincidencia estándar determinan la acción que se aplicará al tráfico.
En las secciones siguientes se describe la interacción de la recuperación de usuarios y roles y el proceso de búsqueda de directivas, métodos para adquirir asignaciones de usuarios y roles, técnicas para configurar directivas de firewall de roles de usuario y un ejemplo de configuración de directivas de firewall de roles de usuario.
Recuperación de roles de usuario y proceso de búsqueda de directivas
Para la búsqueda de políticas, las políticas de firewall se agrupan por pares de zonas (la zona de origen y la zona hasta). En el contexto del par de zonas, las políticas de firewall basadas en IP se corresponden con el tráfico según cinco criterios: IP de origen, puerto de origen, IP de destino, puerto de destino y protocolo.
Las políticas de firewall de rol de usuario incluyen un sexto criterio de coincidencia: la identidad de origen. El campo de identidad de origen especifica los usuarios y roles a los que se aplica la directiva. Cuando se especifica el campo de identidad de origen en cualquier directiva del par de zonas, se debe recuperar la información de usuario y rol antes de poder continuar con la búsqueda de directivas. (Si todas las directivas del par de zonas se establecen en any o no tienen ninguna entrada en el campo de identidad de origen, no se requiere información de usuario y rol y se usan los cinco criterios de coincidencia estándar para la búsqueda de directivas).
La tabla de identificación de usuarios (UIT) proporciona información de usuario y rol para un usuario activo que ya se ha autenticado. Cada entrada de la tabla asigna una dirección IP a un usuario autenticado y a cualquier rol asociado a ese usuario.
Cuando el tráfico requiere datos de usuario y rol, se busca en cada UIT registrada una entrada con la misma dirección IP. Si un usuario no se ha autenticado, no hay ninguna entrada para esa dirección IP en la tabla. Si no existe ninguna entrada UIT, el usuario se considera un usuario no autenticado.
La búsqueda de directivas se reanuda después de recuperar la información de usuario y rol. Las características del tráfico se comparan con los criterios de coincidencia de las políticas. El campo de identidad de origen de una política puede especificar uno o más usuarios o roles, y las siguientes palabras clave:
| authenticated-user | Usuarios que se han autenticado. |
| unauthenticated-user | Usuarios que no se han autenticado. |
| any | Todos los usuarios, independientemente de la autenticación. Si el campo identidad de origen no está configurado o se establece en ninguna de las directivas del par de zonas, solo se cumplen cinco criterios. |
| unknown-user | Los usuarios no pueden autenticarse debido a una desconexión del servidor de autenticación, como un corte de energía. |
Por ejemplo, considere user-c que está asignado al rol de administración. Cuando se recibe tráfico de la zona de confianza a la zona que no es de confianza del usuario-c en la dirección IP 198.51.100.3, se inicia la búsqueda de directivas. En la tabla 1 se representan tres directivas en un firewall de rol de usuario para el par de zonas de confianza a no confiable.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
confianza |
desconfianza |
192.0.2.0 |
203.0.113.0 |
cualquier |
HTTP |
negar |
– |
P2 |
confianza |
desconfianza |
cualquier |
cualquier |
Administración |
cualquier |
permitir |
– |
P3 |
confianza |
desconfianza |
198.51.100.3 |
cualquier |
empleado |
HTTP |
negar |
– |
En primer lugar, todas las directivas del par de zonas se comprueban para una opción de identidad de origen. Si alguna de las directivas especifica un usuario, un rol o una palabra clave, la recuperación de usuarios y roles debe realizarse antes de que continúe la búsqueda de directivas. En la tabla 1 se muestra que la directiva P2 especifica mgmt como identidad de origen, lo que lo convierte en un firewall de funciones de usuario. El usuario y los roles deben recuperarse antes de que la búsqueda de directivas pueda continuar.
La recuperación de usuarios y roles no se realizaría si la palabra clave alguna o si no se especificó ninguna identidad de origen en todas las directivas del contexto de la zona. En tales casos, solo los cinco valores restantes se corresponden con los criterios de la política.
La UIT representada en la tabla 2 se comprueba para la dirección IP. Dado que se encuentra la dirección, el nombre de usuario user-c, todos los roles enumerados para user-c (en este caso, mgmt y employee) y la palabra clave authenticated-user se convierten en datos utilizados para hacer coincidir el tráfico con el source-identity campo de una política.
Dirección IP de origen |
Nombre de usuario |
Papeles |
|---|---|---|
192.0.2.4 |
usuario-a |
empleado |
198.51.100.3 |
usuario-c |
mgmt, empleado |
203.0.113.2 |
usuario-s |
contratista |
La búsqueda de directivas reanuda y compara los criterios de coincidencia de cada política de la tabla 1 con el tráfico entrante. Suponiendo que todos los demás criterios coincidan, la primera política que especifique user-c, mgmt, employee, authenticated-user o cualquiera en el campo de identidad de origen podría coincidir con este tráfico. La política P1 coincide con uno de los roles recuperados para el usuario-c, pero la dirección IP de origen no coincide; por lo tanto, la búsqueda de políticas continúa. Para la directiva P2, todos los criterios coinciden con el tráfico; Por lo tanto, se sigue la acción de la política y se permite el tráfico. Tenga en cuenta que el tráfico también coincide con la directiva P3, pero las políticas de firewall de usuario son terminales: la búsqueda de políticas finaliza cuando se encuentra la primera coincidencia de directivas. Dado que la directiva P2 coincide con todos los criterios, la búsqueda de directivas finaliza y no se comprueba la directiva P3.
Las directivas también se pueden basar en la clasificación asignada a un usuario a partir de los resultados de la recuperación de usuarios y roles. Considere un conjunto diferente de políticas para el mismo par de zonas representado en la Tabla 3. Si se recibe tráfico del usuario-q en IP 198.51.100.5, es necesario recuperar el usuario y el rol porque el campo de identidad de origen se especifica en al menos una de las directivas.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
confianza |
desconfianza |
cualquier |
cualquier |
usuario no autenticado |
HTTP |
negar |
– |
P2 |
confianza |
desconfianza |
cualquier |
cualquier |
Administración |
cualquier |
permitir |
– |
P3 |
confianza |
desconfianza |
198.51.100.3 |
cualquier |
empleado |
HTTP |
negar |
– |
Cuando se comprueban las entradas UIT de la Tabla 2 , no se encuentra ninguna entrada para la dirección IP 198.51.100.5. Por lo tanto, el usuario se considera un usuario no autenticado. Cuando se reanuda la búsqueda de directivas, el tráfico coincide con la directiva P1 y se deniega el tráfico.
Descripción de la tabla de identificación de usuario
En el firewall de la serie SRX, la tabla de identificación del usuario (UIT) contiene la dirección IP, el nombre de usuario y la información de rol de cada usuario autenticado. Las entradas se ordenan por dirección IP. Cuando una política de seguridad requiere información de nombre de usuario y rol, se comprueban todas las UIT. Encontrar la dirección IP en una entrada en una de las UIT significa que el usuario en esa dirección ya se ha autenticado correctamente.
Cada fuente de autenticación mantiene su propia UIT de forma independiente y proporciona funciones de consulta para acceder a los datos. Se admiten tres tipos de UIT: la tabla de autenticación local, la tabla de autenticación de control de acceso unificado (UAC) y la tabla de autenticación de firewall.
| Local authentication table | UIT estática creada en el firewall de la serie SRX, ya sea manual o programáticamente mediante comandos de CLI. Todos los usuarios incluidos en la tabla de autenticación local se consideran usuarios autenticados. Cuando se encuentra una dirección IP coincidente, la información de usuario y rol se recupera de la entrada de la tabla y se asocia con el tráfico. La información de usuario y rol se puede crear en el dispositivo manualmente o portar desde un servidor de autenticación de terceros, pero los datos de la tabla de autenticación local no se actualizan en tiempo real. |
| UAC authentication table | Una UIT dinámica insertada desde el servicio de control de acceso de Junos Pulse al firewall de la serie SRX. La tabla de autenticación UAC de un servicio de control de acceso de Junos Pulse contiene una entrada para cada usuario autenticado. Los datos de esta tabla se actualizan y se envían al firewall de la serie SRX cada vez que se actualiza su tabla de autenticación. Según la configuración del dispositivo, la autenticación podría producirse en el propio servicio de control de acceso de Junos Pulse o en un servidor de autenticación de terceros. Si el servicio de control de acceso está transmitiendo datos desde un servidor de terceros, el servicio de control de acceso reestructura los datos para que coincidan con el formato de archivo de su tabla de autenticación y se insertan en el firewall de la serie SRX. |
| Firewall authentication table | UIT dinámica creada en el firewall de la serie SRX cuando El |
- Tabla de autenticación local
- Tabla de autenticación de UAC
- Tabla de autenticación de firewall
- Aprovisionamiento de políticas con usuarios y roles
Tabla de autenticación local
La tabla de autenticación local se administra mediante comandos de CLI que insertan o eliminan entradas. Una tabla de autenticación local se puede utilizar como solución de copia de seguridad cuando no hay una UIT dinámica disponible, o para asignar información de usuario y rol a dispositivos que no pueden autenticarse en la red, como impresoras o servidores de archivos. La tabla de autenticación local se puede utilizar para probar o demostrar cómo funciona un firewall de rol de usuario sin la autenticación de firewall o el servicio de control de acceso configurado.
Las direcciones IP, los nombres de usuario y los roles de un origen de autenticación de terceros se pueden descargar y agregar a la tabla de autenticación local mediante programación mediante comandos de CLI. Si un origen de autenticación define usuarios y grupos, los grupos se pueden configurar como roles y asociarse con el usuario como de costumbre.
Para cumplir con la tabla de autenticación de UAC, los nombres de usuario están limitados a 65 caracteres y los nombres de rol están limitados a 64 caracteres. La tabla de autenticación local tiene un máximo de 10.240 entradas de autenticación en dispositivos SRX1500 y superiores, 5120 entradas de autenticación en dispositivos SRX650 y versiones anteriores, según la versión de Junos OS de su instalación. La tabla de autenticación local tiene 5120 entradas de autenticación en el firewall virtual vSRX. Cada entrada de autenticación se puede asociar con hasta 200 roles. La capacidad máxima se basa en un promedio de 10 roles asignados a cada usuario. Esta es la misma capacidad especificada para una tabla de autenticación de UAC.
Utilice el siguiente comando para agregar una entrada a una tabla de autenticación local. Tenga en cuenta que cada entrada está codificada por dirección IP.
user@host> request security user-identification local-authentication-table add user user-name ip-address ip-address role [role-name role-name ]
La opción de rol en un solo comando de CLI acepta hasta 40 roles. Para asociar más de 40 roles con un solo usuario, debe introducir varios comandos. Tenga en cuenta las siguientes características al agregar o modificar entradas de autenticación de usuario y rol.
Los nombres de rol no pueden ser los mismos que los nombres de usuario.
El uso de la
addopción con una dirección IP y un nombre de usuario existentes agrega las entradas de rol. La tabla puede admitir hasta 200 roles por usuario.Al usar la
addopción con una dirección IP existente y un nombre de usuario nuevo, se sobrescribe el nombre de usuario existente para esa dirección IP.La agregación de roles no afecta a las sesiones existentes.
Para cambiar la lista de roles de una entrada existente, debe eliminar la entrada existente y agregar una entrada con la nueva lista de roles.
Para cambiar la dirección IP de una entrada existente, debe eliminar la entrada existente y agregar una entrada con la nueva dirección IP.
Una entrada se puede eliminar por dirección IP o por nombre de usuario.
user@host> request security user-identification local-authentication-table delete (ip-address | user-name)
La tabla de autenticación local se puede borrar con el siguiente comando:
user@host> clear security user-identification local-authentication-table
Para mostrar el contenido de la tabla de autenticación local, utilice el siguiente show... comando:
user@host> show security user-identification local-authentication-table all (brief | extensive)
La brief opción (predeterminada) muestra información en formato tabular secuenciado por dirección IP. Los nombres de usuario y las listas de roles se truncan para ajustarse al formato.
user@host> show security user-identification local-authentication-table all
Total entries: 2 Source IP Username Roles 198.51.100.1 user1 role1 203.0.113.2 user2 role2, role3
La extensive opción muestra el contenido completo de cada campo. Otras opciones limitan la visualización a un solo nombre de usuario, dirección IP o rol.
user@host> show security user-identification local-authentication-table all extensive
Total entries: 3 Ip-address: 198.51.100.2 Username: user1 Roles: role1 Ip-address: 203.0.113.2 Username: user1 Roles: role2 Ip-address: 192.0.2.3 Username: user3 Roles: role1, role2
Tabla de autenticación de UAC
Un firewall de la serie SRX puede actuar como ejecutor de un servicio de control de acceso de Junos Pulse. En esta implementación, el firewall de la serie SRX actúa como un punto de cumplimiento de capa 3 y controla el acceso a los recursos con políticas de recursos basadas en IP que se han insertado desde el servicio de control de acceso.
Cuando se implementa como un firewall de rol de usuario, el firewall de la serie SRX puede acceder a la red UAC de manera similar para la recuperación de roles de usuario. En este caso, la información de usuario y rol de todos los usuarios autenticados se inserta desde el Servicio de control de acceso.
La configuración del firewall de la serie SRX es similar a la de un ejecutor. Para establecer la comunicación, ambos dispositivos requieren ajustes de configuración y contraseña para reconocer al otro. Desde el firewall de la serie SRX, conecte el servicio de control de acceso como un controlador de infranet.
[edit] user@host# set services unified-access-control infranet-controller ic-name address ip-address user@host# set services unified-access-control infranet-controller ic-name interface interface-name user@host# set services unified-access-control infranet-controller ic-name password password
Desde el Servicio de control de acceso, defina el firewall de la serie SRX como un nuevo ejecutor. Utilice la misma contraseña especificada en el firewall de la serie SRX.
Los usuarios y las contraseñas se definen en el Servicio de control de acceso como en una configuración de autenticación estándar. Uno o más roles también se pueden asociar con los usuarios. Cuando se autentica un usuario, se agrega una entrada que contiene la dirección IP, el nombre de usuario y los roles asociados a la tabla de autenticación de UAC en el Servicio de control de acceso.
La tabla de autenticación de UAC se inserta desde el Servicio de control de acceso al firewall de la serie SRX cuando se inicializa la conexión entre los dos dispositivos. Cada vez que se agrega, quita o actualiza una entrada en el Servicio de control de acceso, la tabla de autenticación de UAC actualizada se inserta en el firewall de la serie SRX.
Las directivas de acceso a recursos no son necesarias en el Servicio de control de acceso para una implementación de firewall de rol de usuario. El comportamiento de acceso se proporciona en las configuraciones de directivas del firewall de la serie SRX. Si las directivas de acceso a recursos se definen en el Servicio de control de acceso, se insertan en el firewall de la serie SRX, pero no se usan a menos que una directiva de firewall específica implemente directivas de UAC en el campo de acción de la directiva.
El siguiente show services comando muestra el contenido de la tabla de autenticación de UAC en el firewall de la serie SRX, lo que confirma que la tabla se ha insertado correctamente desde el servicio de control de acceso:
user@host> show services unified-access-control authentication-table extended
Id Source IP Username Age Role name 3 192.0.2.1 april 60 Users 6 192.0.2.2 june 60 Employeees Total: 2
El firewall de la serie SRX supervisa las conexiones y detecta si se ha perdido la comunicación con el servicio de control de acceso. Según la configuración de UAC, el firewall de la serie SRX espera una respuesta durante un intervalo configurado antes de emitir otra solicitud. Si se recibe una respuesta, el Servicio de control de acceso se considera funcional. Si no se recibe respuesta después de un período de tiempo de espera especificado, la comunicación se considera perdida y se aplica la acción de tiempo de espera. La siguiente sintaxis de comandos de UAC configura la acción de intervalo, tiempo de espera y tiempo de espera:
user@host# set services unified-access-control interval seconds user@host# set services unified-access-control timeout seconds user@host# set services unified-access-control timeout-action (close | no-change | open)
Durante una desconexión, si se intenta buscar usuarios y roles para el dispositivo desconectado, se devuelve un código de error independientemente de la acción de tiempo de espera. Si se pierde el acceso a todos los orígenes de autenticación, la palabra clave unknown-user se asocia con la dirección IP. Cuando se reanude la búsqueda de directivas, una política con un usuario desconocido como identidad de origen coincidiría con el tráfico. Mediante la implementación de una directiva específica para usuarios desconocidos, puede crear un método para controlar la pérdida de orígenes de autenticación.
Tabla de autenticación de firewall
La autenticación de firewall requiere que los usuarios se autentiquen en el firewall de la serie SRX antes de permitir el acceso entre zonas y dispositivos. Cuando se recibe tráfico, se solicita al usuario un nombre de usuario y una contraseña, y se verifica con un perfil especificado de usuarios válidos. Según la configuración del dispositivo, la autenticación de firewall verifica que el tráfico Telnet, HTTP, HTTPS (para dispositivos SRX5800, SRX5600 y SRX5400) y FTP se haya autenticado localmente o mediante un servidor de autenticación RADIUS, LDAP o SecureID.
Si la autenticación de firewall está en uso en un dispositivo, el proceso de autenticación también puede proporcionar la información de nombre de usuario y rol necesaria para los criterios de coincidencia de firewall de rol de usuario. En este caso, la información se recopila y mantiene en una UIT denominada tabla de autenticación de firewall. Una o más directivas de acceso de la jerarquía definen los métodos de autenticación que se utilizarán para la edit access autenticación de firewall.
La tabla de autenticación de firewall debe estar habilitada como origen de autenticación para la recuperación de información de roles de usuario. La priority opción especifica la secuencia en la que se comprobarán todas las UIT.
user@host# set security user-identification authentication-source firewall-authentication priority priority
En una directiva de firewall para un par de zonas determinado, el firewall-authentication servicio especificado para la acción inicia la permit autenticación del tráfico coincidente. El user-firewall tipo de autenticación genera la entrada UIT para el usuario autenticado. El nombre especificado en la access-profile opción identifica el perfil que se utilizará para autenticar usuarios válidos.
[edit security policies from-zone zone to-zone zone policy policy-name] user@host# set match source-identity unauthenticated-user user@host# set then permit firewall-authentication user-firewall access-profile profile-name
La entrada de la tabla UIT contiene la dirección IP del tráfico asignado al usuario autenticado y a los grupos asociados del usuario. Cuando el usuario ya no está activo, la entrada se elimina de la tabla. Dado que las entradas se agregan y quitan continuamente a medida que cambian el tráfico y los usuarios autenticados, la tabla de autenticación de firewall se considera dinámica.
Cuando las políticas dentro del mismo par de zonas especifican el source-identity campo como parte de sus criterios de coincidencia, se busca en todas las UIT habilitadas una entrada correspondiente a la dirección IP del tráfico. Si se encuentran, el nombre de usuario y los grupos asociados se recuperan para que coincidan entre la identidad de origen. (Los nombres de grupo de autenticación de usuario se consideran nombres de rol para la coincidencia de identidad de origen).
Aprovisionamiento de políticas con usuarios y roles
Todos los usuarios y roles, independientemente de si se definen en el firewall de la serie SRX o en el servicio de control de acceso, se mantienen en un archivo de funciones de usuario en el firewall de la serie SRX. Para mostrar todos los usuarios y roles disponibles para el aprovisionamiento, use los siguientes show security... comandos.
Los nombres de usuario y los roles de la tabla de autenticación de firewall no se incluyen en las siguientes pantallas.
Para mostrar todos los roles que están disponibles para el aprovisionamiento, use el
show security user-identification role-provision allcomando. Tenga en cuenta que los roles de todas las UIT se enumeran juntos.Para mostrar todos los usuarios que están disponibles para el aprovisionamiento, utilice el
show security user-identification user-provision allcomando.Para mostrar todos los usuarios y roles que están disponibles para el aprovisionamiento, use el
show security user-identification source-identity-provision allcomando.
Cuando se confirma una configuración de directiva, se comprueba el archivo de roles de usuario para determinar si todos los usuarios y roles especificados en la política están disponibles para el aprovisionamiento. Si no se encuentra un usuario o rol, una advertencia identifica al usuario o rol que falta para que pueda definirlo más adelante.
La política se confirma incluso si un usuario o rol aún no está definido.
Obtener información de nombre de usuario y rol a través de la autenticación de firewall
Las directivas de firewall de rol de usuario se pueden integrar con la autenticación de firewall tanto para autenticar usuarios como para recuperar información de nombre de usuario y rol. La información se asigna a la dirección IP del tráfico, se almacena en la tabla de autenticación de firewall y se utiliza para la aplicación de directivas de firewall de rol de usuario.
Las siguientes instrucciones de CLI configuran la autenticación de firewall para el cumplimiento del firewall de rol de usuario.
Configuración de un firewall de rol de usuario para la redirección del portal cautivo
Para redirigir automáticamente a los usuarios no autenticados al Servicio de control de acceso, use la característica de portal cautivo de UAC. La siguiente sintaxis define el perfil del portal cautivo:
set services unified-access-control captive-portal profile-name redirect-traffic [unauthenticated | all] set services unified-access-control captive-portal profile-name redirect-url host-url
El protocolo Kerberos, usado para el cifrado de autenticación, identifica el servicio de control de acceso solo por su nombre principal de servicio (SPN). El protocolo no acepta una dirección IP. Por lo tanto, el formato de la URL de redireccionamiento debe ser
service://hostname/options
En esta implementación, el servicio es HTTP y el nombre de host es el FQDN del servicio de control de acceso. Las opciones especificadas después del nombre de host pasan información adicional al Servicio de control de acceso para dirigir al usuario al destino original, al firewall de la serie SRX o a la directiva que originó la redirección. Puede configurar las opciones utilizando los siguientes pares de palabras clave y variables:
| ?target=%dest-url% | Especifica el recurso protegido al que el usuario intenta tener acceso. |
| &enforcer=%enforcer-id% | Especifica el identificador asignado al firewall de la serie SRX cuando el servicio de control de acceso lo configura como ejecutor. |
| &policy=%policy-id% | Especifica el identificador de directiva cifrado para la directiva de seguridad que redirigió el tráfico. |
Las siguientes instrucciones definen el perfil del portal cautivo denominado auth-redirect. El portal cautivo redirige a los usuarios no autenticados a la URL del Servicio de control de acceso para su autenticación. Después de una autenticación correcta, el tráfico se dirigirá de vuelta al firewall de la serie SRX.
[edit] user@host# set services unified-access-control captive-portal auth-redirect redirect-traffic unauthenticated user@host# set services unified-access-control captive-portal auth-redirect redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%"
Se muestra un perfil de portal cautivo definido como parte de la configuración de UAC.
[edit] user@host#show services
unified-access-control {
captive-portal auth-redirect {
redirect-traffic unauthenticated;
redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%";
}
}
Una vez definido el perfil, una directiva puede aplicar el portal cautivo como un servicio de aplicación cuando se cumplen determinados criterios. Siempre que un rol de usuario no esté autenticado, el portal cautivo de redireccionamiento automático desvía el tráfico de la zona de confianza a la zona de no confianza. En el ejemplo siguiente se define la directiva P1 para aplicar el perfil de portal cautivo de redirección automática a cualquier tráfico HTTP de confianza a no confianza:
[edit] user@host# set security policies from-zone trust to-zone untrust policy P1 match application http user@host# set security policies from-zone trust to-zone untrust policy P1 match source-identity unauthenticated-user user@host# set security policies from-zone trust to-zone untrust policy P1 then permit application-services uac-policy captive-portal auth-redirect
Ejemplo: configuración de un firewall de rol de usuario en un dispositivo serie SRX
En el ejemplo siguiente se configura un firewall de funciones de usuario en un firewall de la serie SRX. El firewall controla el acceso desde la zona de confianza a la zona que no es de confianza en función de los usuarios activos y autenticados o sus roles asociados. Las directivas de firewall de rol de usuario establecen las siguientes restricciones:
Solo se permiten usuarios autenticados desde la zona de confianza a la zona que no es de confianza.
Los usuarios no autenticados son redirigidos a un servicio de control de acceso para su autenticación.
El tráfico de IP 192.0.2.0 a IP 203.0.113.0 dentro del contexto de la zona está restringido. Solo se permite el tráfico de usuarios con el rol dev-abc, http-juniper-accessible o ftp-accessible. El tráfico permitido se evalúa más a fondo mediante las reglas de AppFW.
Se deniega el tráfico permitido identificado como tráfico de la aplicación junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK o junos:MEEBO.
Se permite el tráfico permitido para cualquier otra aplicación.
Se permite el resto del tráfico de la zona de confianza a la zona de no confianza.
Requisitos
Antes de comenzar, asegúrese de que el firewall de la serie SRX con Junos OS versión 12.1 o posterior esté configurado e inicializado.
En este ejemplo, la información de usuario y rol asociada con la dirección IP del tráfico la proporciona un servicio de control de acceso. Para obtener instrucciones sobre cómo configurar el servidor de control de acceso, consulte Configurar Active Directory como origen de identidad.
Visión general
En la tabla 4 se describe un firewall que cumple los requisitos de este ejemplo. El firewall de rol de usuario consta de cuatro políticas.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
usuario-rol-fw1 |
confianza |
desconfianza |
cualquier |
cualquier |
usuario no autenticado |
HTTP |
permitir |
Portal cautivo de UAC |
usuario-rol-fw2 |
confianza |
desconfianza |
192.0.2.0 |
203.0.113.0 |
dev-abc http-juniper-accesible ftp-accesible |
HTTP |
permitir |
Conjunto de reglas de AppFW RS1 |
usuario-rol-fw3 |
confianza |
desconfianza |
192.0.2.0 |
203.0.113.0 |
cualquier |
HTTP |
negar |
|
usuario-rol-fw4 |
confianza |
desconfianza |
cualquier |
cualquier |
cualquier |
HTTP |
permitir |
|
Dado que el campo se especifica para al menos una de las directivas de este firewall, se debe recuperar la source-identity información de usuarios y roles antes de realizar la búsqueda de directivas. La IP de origen del tráfico se compara con los elementos de la UIT. Si se encuentra la dirección IP de origen, la palabra clave authenticated, el nombre de usuario y cualquier rol asociado a este usuario se almacenan para su uso posterior en la búsqueda de directivas. Si no se encuentra una entrada coincidente para la dirección IP en la UIT, la palabra clave unauthenticated-user se almacena para la búsqueda de directivas.
Después de recuperar el nombre de usuario, los roles y las palabras clave, comienza la búsqueda de directivas. Las características del tráfico entrante se comparan con los criterios de coincidencia de cada política. Si se encuentra una coincidencia, se realiza la acción especificada en esa directiva.
Una coincidencia de política es un evento terminal y no se comprueba ninguna política después de la coincidencia. La secuencia de políticas influye en la acción que se debe realizar para hacer coincidir el tráfico. En este ejemplo, las directivas se aplican en la siguiente secuencia:
| user-role-fw1 | Aplica el servicio de portal cautivo de UAC para hacer coincidir el tráfico HTTP con la palabra clave de usuario no autenticado y lo redirige al Servicio de control de acceso para su autenticación. También se debe configurar un perfil de UAC para identificar las especificaciones del portal cautivo. |
| user-role-fw2 | Aplica un conjunto de reglas de AppFW a cualquier tráfico HTTP desde la dirección 192.0.2.0 hasta la dirección 203.0.113.0 que tenga un nombre de usuario o rol coincidente. También se debe configurar un firewall de aplicaciones para definir el conjunto de reglas. |
| user-role-fw3 | Deniega todo el tráfico HTTP restante desde la dirección 192.0.2.0 a la dirección 203.0.113.0 para este par de zona. |
| user-role-fw4 | Permite todo el tráfico HTTP restante para este par de zona. |
Configuración
En el ejemplo siguiente es necesario navegar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.
- Configuración de la redirección para usuarios no autenticados
- Creación de una directiva de roles de usuario con un firewall de aplicaciones
- Creación de políticas de seguridad restantes basadas en el usuario y el rol
Configuración de la redirección para usuarios no autenticados
Procedimiento paso a paso
Cuando una dirección IP no aparece en la UIT, la palabra clave usuario no autenticado se utiliza en la búsqueda de directivas. En lugar de denegar el acceso a este tráfico, una directiva puede redirigir el tráfico a un portal cautivo de UAC para su autenticación.
Es importante colocar una directiva de redirección para usuarios no autenticados antes de una directiva para "cualquier" usuario, de modo que la autenticación de UAC no se vea ensombrecida por una directiva destinada a usuarios autenticados.
Para configurar la redirección desde el firewall de la serie SRX al servicio de control de acceso:
Desde el modo de configuración, configure el perfil de UAC para el dispositivo acs del portal cautivo.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-traffic unauthenticated-user
Configure la URL de redirección para el Servicio de control de acceso o una dirección URL predeterminada para el portal cautivo.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-url “https://%ic-url%/?target=%dest-url%&enforcer=%enforcer-id%”
Esta directiva especifica las variables predeterminadas de destino y ejecutor que usará el Servicio de control de acceso para dirigir al usuario de vuelta después de la autenticación. Esto garantiza que los cambios en las especificaciones del sistema no afectarán a los resultados de configuración.
Nota:Cuando se incluyen variables, como
?target=, en la línea de comandos, debe poner la dirección URL y las variables entre comillas.Configure una directiva de firewall de rol de usuario que redirija el tráfico HTTP de confianza de zona a zona no confiable si la identidad de origen es unauthenticated-user. El nombre de perfil del portal cautivo se especifica como la acción que se debe realizar para el tráfico que coincida con esta directiva.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-identity unauthenticated-user user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 then permit application-services uac-policy captive-portal acs-device
Cuando haya terminado de configurar las directivas, confirme los cambios.
[edit] user@host# commit
Resultados
Desde el modo de configuración, confirme la configuración introduciendo los show services comandos y show security policies . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.
[edit]user@host#show services unified-access-control { captive-portal acs-device { redirect-traffic unauthenticated; redirect-url “https://%ic-ip%/?target=%dest-url%&enforcer=%enforcer-id%”
user@host# show security policies
from-zone trust to-zone untrust {
policy user-role-fw1 {
match {
source-address any;
destination-address any;
application http;
source-identity unauthenticated-user
}
then {
permit {
application-services {
uac-policy {
captive-portal acs-device;
}
}
}
}
}
}
Creación de una directiva de roles de usuario con un firewall de aplicaciones
Procedimiento paso a paso
Esta política restringe el tráfico de IP192.0.2.0 a IP 203.0.113.0 en función de sus usuarios y roles, y también de su aplicación. La configuración define un conjunto de reglas de aplicación y lo aplica al tráfico de roles de usuario coincidentes.
Configure el conjunto de reglas de AppFW rs1. El siguiente conjunto de reglas deniega el tráfico de aplicaciones junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK o junos:MEEBO. Aplica la configuración predeterminada, permitir, al tráfico restante.
[edit security application-firewall rule-sets rs1] user@host# set rule r1 match dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK junos:MEEBO] user@host# set rule r1 then deny user@host# set default-rule permit
Configure una política para aplicar el conjunto de reglas de firewall de aplicación rs1 al tráfico de IP 192.0.2.0 a IP 203.0.113.0 con el rol de usuario dev-abc, http-mgmt-accessible o ftp-accessible.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match source-address 192.0.2.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match destination-address 203.0.113.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match source-identity [dev-abc http-mgmt-accessible ftp-accessible] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 then permit application-services application-firewall rule-set rs1
Cuando haya terminado de configurar la directiva, confirme los cambios.
[edit] user@host# commit
Resultados
Compruebe que el conjunto de reglas de AppFW esté configurado correctamente. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.
[edit]user@host#show security application-firewall rule-sets rs1 { rule r1 { match { dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK junos:MEEBO] } then { deny; } } default-rule { permit; } }
Creación de políticas de seguridad restantes basadas en el usuario y el rol
Procedimiento paso a paso
El siguiente procedimiento configura directivas para el tráfico restante.
Configure una política para denegar tráfico con la misma dirección de origen y destino, pero con criterios de usuario y rol diferentes a los especificados en la directiva user-role-fw2.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match source-address 192.0.2.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match destination-address 203.0.113.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match source-identity any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 then deny
Configure una política de seguridad para permitir el resto del tráfico HTTP de la zona de confianza a la zona de no confianza.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match source-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match source-identity any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 then permit
Resultados
Compruebe el contenido y la secuencia de las directivas de firewall de roles de usuario. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.
[edit]user@host#show security policies ... from-zone trust to-zone untrust { policy user-role-fw1 { match { source-address any; destination-address any; application http; source-identity unauthenticated-user } then { permit { application-services { uac-policy { captive-portal acs-device; } } } } } } from-zone trust to-zone untrust { policy user-role-fw2 { match { source-address 192.0.2.0; destination-address 203.0.113.0; application http; source-identity [dev-abc http-juniper-accessible ftp-accessible] } then { permit { application-services { application-firewall { rule-set rs1 } } } } } } from-zone trust to-zone untrust { policy user-role-fw3 { match { source-address 192.0.2.0; destination-address 203.0.113.0; application http; source-identity any } then { deny } } } from-zone trust to-zone untrust { policy user-role-fw4 { match { source-address any; destination-address any; application http; source-identity any } then { permit } } }
Configuración de directivas de recursos mediante UAC
Cuando se usa la característica de firewall de rol de usuario, no son necesarias directivas de recursos en el Servicio de control de acceso. Sin embargo, si existen políticas de recursos, se insertan en el firewall de la serie SRX en el momento de la conexión. Puede crear directivas que usen estas directivas de recursos aplicando el servicio de aplicaciones de UAC en la configuración de directivas. En la tabla 5 se muestran tres directivas de firewall que usan exclusivamente las directivas de recursos de UAC:
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
zona1 |
zona2 |
cualquier |
192.0.2.1 |
cualquier |
HTTP |
permitir |
Seguridad de contenido |
P2 |
zona1 |
zona2 |
cualquier |
neto2 |
cualquier |
HTTP |
permitir |
IDP |
P3 |
zona1 |
zona2 |
cualquier |
cualquier |
cualquier |
cualquier |
permitir |
UAC |
Las directivas para el tráfico de zona1 a zona2 no inician la recuperación de usuarios y roles, ya que se especifica ninguna en el campo de identidad de origen de cada directiva. En este ejemplo, se permite el tráfico a la dirección IP 192.0.2.1, pero debe cumplir los requisitos de procesamiento para el servicio de aplicación especificado, en este caso, Content Security. El tráfico a net2 está permitido y procesado por los requisitos de procesamiento de IDP. Los requisitos de procesamiento de UAC permiten y procesan cualquier tráfico restante.
La configuración de esta directiva de firewall sería la siguiente:
[edit]user@host#show security policies from-zone zone1 to-zone zone2 { policy P1 { match { source-address any; destination-address 192.0.2.1; source-identity any; application http; } then { permit { application-services { idp; } } } } } from-zone zone1 to-zone zone2 { policy P2 { match { source-address any; destination-address net2; source-identity any; application http; } then { permit { application-services { utm; } } } } } from-zone zone1 to-zone zone2 { policy P3 { match { source-address any; destination-address any; source-identity any; application any; } then { permit { application-services { uac-policy; } } } } }
En esta configuración de ejemplo, los campos de acción de P1 y P2 aplican todos los requisitos configurados para IDP y Content Security, respectivamente. Al especificar la opción uac-policy, las políticas de recursos insertadas en el firewall de la serie SRX determinan si se puede acceder al destino.
Un firewall de rol de usuario puede implementar tanto directivas de rol de usuario como las políticas de recursos insertadas desde el Servicio de control de acceso. La Tabla 6 muestra las políticas para tres pares de zonas.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
zona1 |
zona2 |
cualquier |
cualquier |
usuario no autenticado |
cualquier |
permitir |
Portal cautivo de UAC |
P2 |
zona1 |
zona2 |
cualquier |
192.0.2.1 |
rol2 |
HTTP |
permitir |
IDP |
P3 |
zona1 |
zona2 |
cualquier |
neto2 |
usuario autenticado |
HTTP |
permitir |
Seguridad de contenido |
P4 |
zona1 |
zona2 |
cualquier |
cualquier |
cualquier |
cualquier |
permitir |
|
P5 |
zona1 |
zona3 |
cualquier |
cualquier |
cualquier |
cualquier |
permitir |
UAC |
P6 |
zona2 |
zona3 |
cualquier |
cualquier |
cualquier |
cualquier |
permitir |
UAC |
El tráfico de la zona 1 a la zona 2 está sujeto a una de las cuatro directivas de rol de usuario. La primera de estas directivas usa el portal cautivo de UAC para redirigir a los usuarios no autenticados al Servicio de control de acceso para su autenticación.
El acceso del tráfico de la zona 1 a la zona 3 y de la zona 2 a la zona 3 se controla mediante las directivas de recursos insertadas desde el Servicio de control de acceso.
Rol de usuario específico de la plataforma Comportamiento de las políticas de seguridad de firewall
Use el Explorador de características para confirmar la compatibilidad de la plataforma y el lanzamiento de características específicas.
Use las tablas siguientes para revisar el comportamiento específico de la plataforma para su plataforma:
- Comportamiento de autenticación local específico de la plataforma
- Comportamiento de autenticación de firewall específico de la plataforma
Comportamiento de autenticación local específico de la plataforma
| Plataforma |
Diferencia |
|---|---|
| Serie SRX |
|
Comportamiento de autenticación de firewall específico de la plataforma
| Plataforma |
Diferencia |
|---|---|
| Serie SRX |
|