La autenticación RADIUS y TACACS+ se puede realizar para conexiones FTP, Telnet y HTTP. Se admite la autorización TACACS+; la autorización RADIUS no.
La sintaxis para la autenticación cambió ligeramente en el software PIX 4.2.2. Este documento utiliza la sintaxis para las versiones de software 4.2.2.
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
En este documento, se utiliza esta configuración de red:
Configuración de PIX |
---|
pix2# write terminal Building configuration : Saved : PIX Version 4.2(2) nameif ethernet0 outside security0 nameif ethernet1 inside security100 enable password 8Ry2YjIyt7RRXU24 encrypted passwd OnTrBUG1Tp0edmkr encrypted hostname pix2 fixup protocol http 80 fixup protocol smtp 25 no fixup protocol ftp 21 no fixup protocol h323 1720 no fixup protocol rsh 514 no fixup protocol sqlnet 1521 no failover failover timeout 0:00:00 failover ip address outside 0.0.0.0 failover ip address inside 0.0.0.0 failover ip address 0.0.0.0 names pager lines 24 logging console debugging no logging monitor logging buffered debugging logging trap debugging logging facility 20 interface ethernet0 auto interface ethernet1 auto interface ethernet2 auto ip address outside 9.9.9.12 255.255.255.0 ip address inside 171.68.118.103 255.255.255.0 ip address 0.0.0.0 0.0.0.0 arp timeout 14400 global (outside) 1 9.9.9.1-9.9.9.9 netmask 255.0.0.0 static (inside,outside) 9.9.9.10 171.68.118.100 netmask 255.255.255.255 0 0 conduit permit icmp any any conduit permit tcp host 9.9.9.10 eq telnet any no rip outside passive no rip outside default no rip inside passive no rip inside default timeout xlate 3:00:00 conn 1:00:00 udp 0:02:00 timeout rpc 0:10:00 h323 0:05:00 timeout uauth 0:00:00 absolute ! !--- The next entry depends on whether TACACS+ or RADIUS is used. ! tacacs-server (inside) host 171.68.118.101 cisco timeout 5 radius-server (inside) host 171.68.118.101 cisco timeout 10 ! !--- The focus of concern is with hosts on the inside network !--- accessing a particular outside host. ! aaa authentication any outbound 171.68.118.0 255.255.255.0 9.9.9.11 255.255.255.255 tacacs+|radius ! !--- It is possible to be less granular and authenticate !--- all outbound FTP, HTTP, Telnet traffic with: aaa authentication ftp outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 tacacs+|radius aaa authentication http outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 tacacs+|radius aaa authentication telnet outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 tacacs+|radius ! !--- Accounting records are sent for !--- successful authentications to the TACACS+ or RADIUS server. ! aaa accounting any outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 tacacs+|radius ! no snmp-server location no snmp-server contact snmp-server community public no snmp-server enable traps telnet 171.68.118.100 255.255.255.255 mtu outside 1500 mtu inside 1500 mtu 1500 Smallest mtu: 1500 floodguard 0 tcpchecksum silent Cryptochecksum:be28c9827e13baf89a937c617cfe6da0 : end [OK] |
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
La autenticación es quién es el usuario.
La autorización es lo que el usuario puede hacer.
La autenticación es válida sin autorización.
La autorización no es válida sin autenticación.
Por ejemplo, suponga que tiene cien usuarios dentro y que solo desea que seis de estos usuarios puedan hacer FTP, Telnet o HTTP fuera de la red. Dígale al PIX que autentique el tráfico saliente y proporcione los seis ID de usuarios en el servidor de seguridad TACACS+/RADIUS. Con la autenticación simple, estos seis usuarios pueden ser autenticados con nombre de usuario y contraseña, y luego salir. Los otros noventa y cuatro usuarios no pueden salir. El PIX solicita a los usuarios un nombre de usuario/contraseña, luego pasa su nombre de usuario y contraseña al servidor de seguridad TACACS+/RADIUS. Además, dependiendo de la respuesta, abre o niega la conexión. Estos seis usuarios podían utilizar FTP, Telnet o HTTP.
Sin embargo, supongamos que uno de estos tres usuarios, "Terry", no es de confianza. Le gustaría permitir a Terry hacer FTP, pero no HTTP o Telnet hacia el exterior. Esto significa que debe agregar autorización. Es decir, autorizar lo que los usuarios pueden hacer además de autenticar quiénes son. Cuando agrega autorización al PIX, el PIX primero envía el nombre de usuario y la contraseña de Terry al servidor de seguridad, luego envía una solicitud de autorización que le dice al servidor de seguridad qué "comando" Terry está tratando de hacer. Con el servidor configurado correctamente, Terry puede ser autorizado a "FTP 1.2.3.4" pero se le niega la capacidad de "HTTP" o "Telnet" en cualquier lugar.
Cuando intenta ir de adentro hacia afuera (o viceversa) con autenticación/autorización en:
Telnet: el usuario ve una pantalla de solicitud de nombre de usuario, seguida de una solicitud de contraseña. Si la autenticación (y autorización) resulta exitosa en el PIX/servidor, el siguiente host de destino le pide al usuario el nombre de usuario y contraseña.
FTP – El usuario ve aparecer un mensaje de nombre de usuario El usuario debe ingresar "nombredeusuario_local@nombredeusuario_remoto" para el nombre de usuario y "contraseña_local@contraseña_remota" para la contraseña. El PIX envía el “nombredeusuario_local” y “contraseña_local” al servidor de seguridad local y si la autenticación (y autorización) resulta exitosa en el PIX/servidor, el “nombredeusuario_remoto” y “contraseña_remota” se envían al servidor FTP de destino posterior.
HTTP: se muestra una ventana en el explorador que solicita un nombre de usuario y una contraseña. Si la autenticación (y la autorización) se realiza con éxito, el usuario accederá al sitio Web siguiente. ¡Recuerde los nombres de usuario y contraseñas de la memoria caché del explorador. Si parece que el PIX debería estar agotando el tiempo de espera de una conexión HTTP pero no lo está haciendo, es probable que la reautenticación se esté llevando a cabo realmente con el navegador "disparando" el nombre de usuario y la contraseña almacenados en caché al PIX. A continuación, lo reenvía al servidor de autenticación. Los debugs del sistema PIX y/o del servidor muestran este fenómeno. Si Telnet y FTP parecen funcionar normalmente, pero las conexiones HTTP no, esta es la razón.
En los ejemplos de configuración del servidor TACACS+, si solo la autenticación está activada, los usuarios "all", "telnetonly", "thttponly" y "ftponly" funcionan. En los ejemplos de configuración del servidor RADIUS, el usuario "all" funciona.
Cuando se agrega la autorización al PIX, además de enviar el nombre de usuario y la contraseña al servidor de autenticación TACACS+, el PIX envía comandos (Telnet, HTTP o FTP) al servidor TACACS+. El servidor TACACS+ luego verifica si ese usuario está autorizado para ese comando.
En un ejemplo posterior, el usuario en 171.68.118.100 emite el comando telnet 9.9.9.11. Cuando esto se recibe en el PIX, el PIX pasa el nombre de usuario, la contraseña y el comando al servidor TACACS+ para su procesamiento.
Por lo tanto, con la autorización activada además de la autenticación, el usuario "telnetonly" puede realizar operaciones Telnet a través del PIX. Sin embargo, los usuarios "hotponly" y "ftponly" no pueden realizar operaciones Telnet a través del PIX.
(De nuevo, la autorización no se soporta con RADIUS debido a la naturaleza de la especificación del protocolo).
Aquí se muestran las estrofas del usuario.
Agregue la dirección IP de PIX o el nombre de dominio completo y la clave a CSU.cfg.
user = all { password = clear "all" default service = permit } user = telnetonly { password = clear "telnetonly" service = shell { cmd = telnet { permit .* } } } user = ftponly { password = clear "ftponly" service = shell { cmd = ftp { permit .* } } } user = httponly { password = clear "httponly" service = shell { cmd = http { permit .* } } }
Utilice la interfaz gráfica de usuario (GUI) avanzada para agregar la IP y la clave PIX a la lista del servidor de acceso a la red (NAS). La estrofa del usuario aparece como se ve aquí:
all Password="all" User-Service-Type = Shell-User
La sección Configuraciones de muestra de la documentación en línea y web de CiscoSecure 2.1 describe la configuración; el atributo 6 (Tipo de servicio) sería Conexión o Administración.
Agregue la IP del PIX en la sección de configuración del NAS usando la GUI.
La documentación de EasyACS proporciona información de configuración.
En la sección de grupo, haga clic en Shell exec (para otorgar privilegios exec).
Para agregar autorización al PIX, haga clic en Denegar comandos IOS no coincidentes en la parte inferior de la configuración del grupo.
Seleccione Add/Edit para cada comando que desee permitir (Telnet, por ejemplo).
Si desea permitir Telnet a sitios específicos, ingrese las IP en la sección del argumento. Para permitir Telnet a todos los sitios, haga clic en Permitir todos los argumentos no enumerados.
Haga clic en el comando finalizar edición.
Realice los pasos del 1 al 5 para cada uno de los comandos permitidos (Telnet, HTTP o FTP, por ejemplo).
Agregue la IP del PIX en la sección de configuración del NAS usando la GUI.
La documentación de Cisco Secure 2.x proporciona información de configuración.
En la sección de grupo, haga clic en Shell exec (para otorgar privilegios exec).
Para agregar autorización al PIX, haga clic en Denegar comandos IOS no coincidentes en la parte inferior de la configuración del grupo.
Seleccione la casilla de verificación command en la parte inferior e ingrese el comando que desea permitir (Telnet, por ejemplo).
Si desea permitir Telnet a sitios específicos, ingrese la IP en la sección del argumento (por ejemplo, "permit 1.2.3.4"). Para permitir Telnet a todos los sitios, haga clic en Permitir argumentos no enumerados.
Haga clic en Submit (Enviar).
Realice los pasos del 1 al 5 para cada uno de los comandos permitidos (Telnet, FTP o HTTP, por ejemplo).
Agregue la IP del PIX en la sección de configuración del NAS usando la GUI.
Agregue la IP y la clave PIX al archivo de clientes.
all Password="all" User-Service-Type = Shell-User
Agregue la IP y la clave PIX al archivo de clientes.
all Password="all" Service-Type = Shell-User
# Handshake with router--PIX needs 'tacacs-server host #.#.#.# cisco': key = "cisco" user = all { default service = permit login = cleartext "all" } user = telnetonly { login = cleartext "telnetonly" cmd = telnet { permit .* } } user = httponly { login = cleartext "httponly" cmd = http { permit .* } } user = ftponly { login = cleartext "ftponly" cmd = ftp { permit .* } }
Asegúrese de que las configuraciones PIX estén funcionando antes de agregar autenticación, autorización y contabilidad (AAA).
Si no puede pasar el tráfico antes de instituir AAA, no podrá hacerlo después.
Habilite el registro en el PIX:
El comando logging console debugging no se debe utilizar en un sistema con mucha carga.
Puede usarse el comando logging buffered debugging (depuración guardada en la memoria intermedia del registro). El resultado de los comandos show logging o logging puede enviarse a un servidor syslog y examinarse.
Asegúrese de que la depuración esté activada para los servidores TACACS+ o RADIUS. Todos los servidores tienen esta opción.
PIX Debug - Buena Autenticación - RADIUS
Este es un ejemplo de una depuración PIX con buena autenticación:
109001: Auth start for user '???' from 171.68.118.100/1116 to 9.9.9.11/23 109011: Authen Session Start: user 'bill', sid 1 109005: Authentication succeeded for user 'bill' from 171.68.118.100/1116 to 9.9.9.11/23 109012: Authen Session End: user 'bill', sid 1, elapsed 1 seconds 302001: Built TCP connection 1 for faddr 9.9.9.11/23 gaddr 9.9.9.10/1116 laddr 171.68.118.100/1116 (bill)
Depuración PIX - Autenticación incorrecta (nombre de usuario o contraseña) - RADIUS
Este es un ejemplo de una depuración PIX con autenticación incorrecta (nombre de usuario o contraseña). El usuario ve cuatro conjuntos de nombre de usuario y contraseña. Se muestra el mensaje "Error: número máximo de reintentos excedidos".
Nota: Si se trata de un intento de FTP, se permite un intento. Para HTTP, se permiten reintentos infinitos.
109001: Auth start for user '???' from 171.68.118.100/1132 to 9.9.9.11/23 109006: Authentication failed for user '' from 171.68.118.100/1132 to 9.9.9.11/23
Depuración PIX - Servidor inactivo - RADIUS
Este es un ejemplo de una depuración PIX con el servidor inactivo. El usuario verá el nombre de usuario una vez. A continuación, el servidor se "cuelga" y solicita una contraseña (tres veces).
109001: Auth start for user '???' from 171.68.118.100/1151 to 9.9.9.11/23 109002: Auth from 171.68.118.100/1151 to 9.9.9.11/23 failed (server 171.68.118.101 failed) 109002: Auth from 171.68.118.100/1151 to 9.9.9.11/23 failed (server 171.68.118.101 failed)
PIX Debug - Buena Autenticación - TACACS+
Este es un ejemplo de una depuración PIX con buena autenticación:
109001: Auth start for user '???' from 171.68.118.100/1200 to 9.9.9.11/23 109011: Authen Session Start: user 'cse', sid 3 109005: Authentication succeeded for user 'cse' from 171.68.118.100/1200 to 9.9.9.11/23 109012: Authen Session End: user 'cse', sid 3, elapsed 1 seconds 302001: Built TCP connection 3 for faddr 9.9.9.11/23 gaddr 9.9.9.10/1200 laddr 171.68.118.100/1200 (cse)
Depuración PIX - Autenticación incorrecta (nombre de usuario o contraseña) - TACACS+
Este es un ejemplo de una depuración PIX con autenticación incorrecta (nombre de usuario o contraseña). El usuario ve cuatro conjuntos de nombre de usuario y contraseña. Se muestra el mensaje "Error: número máximo de reintentos excedidos".
Nota: Si se trata de un intento de FTP, se permite un intento. Para HTTP, se permiten reintentos infinitos.
109001: Auth start for user '???' from 171.68.118.100/1203 to 9.9.9.11/23 109006: Authentication failed for user '' from 171.68.118.100/1203 to 9.9.9.11/23
Depuración PIX - Servidor inactivo - TACACS+
Este es un ejemplo de una depuración PIX con el servidor inactivo. El usuario verá el nombre de usuario una vez. Inmediatamente, se muestra el mensaje "Error: Max number of tries exceeded".
109001: Auth start for user '???' from 171.68.118.100/1212 to 9.9.9.11/23 109002: Auth from 171.68.118.100/1212 to 9.9.9.11/23 failed (server 171.68.118.101 failed) 109002: Auth from 171.68.118.100/1212 to 9.9.9.11/23 failed (server 171.68.118.101 failed) 109002: Auth from 171.68.118.100/1212 to 9.9.9.11/23 failed (server 171.68.118.101 failed) 109006: Authentication failed for user '' from 171.68.118.100/1212 to 9.9.9.11/23
Debido a que la autorización no es válida sin autenticación, se requiere autorización para el mismo origen y destino:
aaa authorization any outbound 171.68.118.0 255.255.255.0 9.9.9.11 255.255.255.255 tacacs+|radius
O bien, si los tres servicios salientes se autenticaron originalmente:
aaa authorization http outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 tacacs+|radius aaa authorization ftp outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 tacacs+|radius aaa authorization telnet outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 tacacs+|radius
PIX Debug - Autenticación y autorización correctas - TACACS+
Este es un ejemplo de una depuración PIX con buena autenticación y autorización:
109001: Auth start for user '???' from 171.68.118.100/1218 to 9.9.9.11/23 109011: Authen Session Start: user 'telnetonly', sid 5 109005: Authentication succeeded for user 'telnetonly' from 171.68.118.100/1218 to 9.9.9.11/23 109011: Authen Session Start: user 'telnetonly', sid 5 109007: Authorization permitted for user 'telnetonly' from 171.68.118.100/1218 to 9.9.9.11/23 109012: Authen Session End: user 'telnetonly', sid 5, elapsed 1 seconds 302001: Built TCP connection 4 for faddr 9.9.9.11/23 gaddr 9.9.9.10/1218 laddr 171.68.118.100/1218 (telnetonly)
PIX Debug - Buena autenticación, pero falla en la autorización - TACACS+
Este es un ejemplo de una depuración PIX con buena autenticación pero falla en la autorización:
109001: Auth start for user '???' from 171.68.118.100/1223 to 9.9.9.11/23 109011: Authen Session Start: user 'httponly', sid 6 109005: Authentication succeeded for user 'httponly' from 171.68.118.100/1223 to 9.9.9.11/23 109008: Authorization denied for user 'httponly' from 171.68.118.100/1223 to 9.9.9.11/23
Depuración de PIX: autenticación incorrecta, no se ha intentado la autorización - TACACS+
Este es un ejemplo de una depuración PIX con autenticación y autorización, pero no se intenta la autorización debido a una autenticación incorrecta (nombre de usuario o contraseña). El usuario ve cuatro conjuntos de nombre de usuario y contraseña. Se muestra el mensaje "Error: se ha superado el número máximo de reintentos."
Nota: Si se trata de un intento de FTP, se permite un intento. Para HTTP, se permiten reintentos infinitos.
109001: Auth start for user '???' from 171.68.118.100/1228 to 9.9.9.11/23 109006: Authentication failed for user '' from 171.68.118.100/1228 to 9.9.9.11/23
Depuración PIX - Autenticación/Autorización, Servidor Caído - TACACS+
Este es un ejemplo de una depuración PIX con autenticación y autorización. El servidor está inactivo. El usuario ve el nombre de usuario una vez. Inmediatamente, se muestra el mensaje de error "Error: Max number of tries exceeded.".
109001: Auth start for user '???' from 171.68.118.100/1237 to 9.9.9.11/23 109002: Auth from 171.68.118.100/1237 to 9.9.9.11/23 failed (server 171.68.118.101 failed) 109002: Auth from 171.68.118.100/1237 to 9.9.9.11/23 failed (server 171.68.118.101 failed) 109002: Auth from 171.68.118.100/1237 to 9.9.9.11/23 failed (server 171.68.118.101 failed) 109006: Authentication failed for user '' from 171.68.118.100/1237 to 9.9.9.11/23
aaa accounting any outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0: tacacs+
La depuración tiene el mismo aspecto independientemente de si la contabilidad está activada o desactivada. Sin embargo, en el momento del "Built", se envía un registro contable de "inicio". Además, en el momento del "Desmontaje", se envía un registro contable de "detención":
109011: Authen Session Start: user 'telnetonly', sid 13 109005: Authentication succeeded for user 'telnetonly' from 171.68.118.100/1299 to 9.9.9.11/23 109011: Authen Session Start: user 'telnetonly', sid 13 109007: Authorization permitted for user 'telnetonly' from 171.68.118.100/1299 to 9.9.9.11/23 109012: Authen Session End: user 'telnetonly', sid 13, elapsed 1 seconds 302001: Built TCP connection 11 for faddr 9.9.9.11/23 gaddr 9.9.9.10/1299 laddr 171.68.118.100/1299 (telnetonly) 302002: Teardown TCP connection 11 faddr 9.9.9.11/23 gaddr 9.9.9.10/1299 laddr 171.68.118.100/1299 duration 0:00:02 bytes 112
Los registros de contabilidad de TACACS+ son similares a este resultado (provienen de CiscoSecure UNIX; los registros de Cisco Secure Windows pueden estar delimitados por comas en su lugar):
Tue Sep 29 11:00:18 1998 redclay cse PIX 171.68.118.103 start task_id=0x8 foreign_ip=9.9.9.11 local_ip=171.68.118.100 cmd=telnet Tue Sep 29 11:00:36 1998 redclay cse PIX 171.68.118.103 stop task_id=0x8 foreign_ip=9.9.9.11 local_ip=171.68.118.100 cmd=telnet elapsed_time=17 bytes_in=1198 bytes_out=62 Tue Sep 29 11:02:08 1998 redclay telnetonly PIX 171.68.118.103 start task_id=0x9 foreign_ip=9.9.9.11 local_ip=171.68.118.100 cmd=telnet Tue Sep 29 11:02:27 1998 redclay telnetonly PIX 171.68.118.103 stop task_id=0x9 foreign_ip=9.9.9.11 local_ip=171.68.118.100 cmd=telnet elapsed_time=19 bytes_in=2223 bytes_out=64
Los campos se desglosan como se puede ver aquí:
DAY MO DATE TIME YEAR NAME_OF_PIX USER SENDER PIX_IP START/STOP UNIQUE_TASK_ID DESTINATION SOURCE SERVICE <TIME> <BYTES_IN> <BYTES_OUT>
aaa accounting any outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 radius
La depuración tiene el mismo aspecto independientemente de si la contabilidad está activada o desactivada. Sin embargo, en el momento del "Built", se envía un registro contable de "inicio". Además, en el momento del "Desmontaje", se envía un registro contable de "detención":
109001: Auth start for user '???' from 171.68.118.100/1316 to 9.9.9.11/23 109011: Authen Session Start: user 'bill', sid 16 109005: Authentication succeeded for user 'bill' from 171.68.118.100/1316 to 9.9.9.11/23 109012: Authen Session End: user 'bill', sid 16, elapsed 1 seconds 302001: Built TCP connection 14 for faddr 9.9.9.11/23 gaddr 9.9.9.10/1316 laddr 171.68.118.100/1316 (bill) 302002: Teardown TCP connection 14 faddr 9.9.9.11/23 gaddr 9.9.9.10/1316 laddr 171.68.118.100/1316 duration 0:00:03 bytes 112
Los registros de cuentas RADIUS tienen este aspecto (provienen de Cisco Secure UNIX; los de Cisco Secure Windows están delimitados por comas):
Mon Sep 28 10:47:01 1998 Acct-Status-Type = Start Client-Id = 171.68.118.103 Login-Host = 171.68.118.100 Login-TCP-Port = 23 Acct-Session-Id = "0x00000004" User-Name = "bill" Mon Sep 28 10:47:07 1998 Acct-Status-Type = Stop Client-Id = 171.68.118.103 Login-Host = 171.68.118.100 Login-TCP-Port = 23 Acct-Session-Id = "0x00000004" User-Name = "bill" Acct-Session-Time = 5
Los campos se desglosan como se puede ver aquí:
Acct-Status-Type = START or STOP Client-ID = IP_OF_PIX Login_Host = SOURCE_OF_TRAFFIC Login-TCP-Port = # Acct-Session-ID = UNIQUE_ID_PER_RADIUS_RFC User-name = <whatever> <Acct-Session-Time = #>
Algunos servidores TACACS y RADIUS tienen funciones de "sesión máxima" o "visualización de usuarios conectados". La posibilidad de establecer un número máximo de sesiones o verificar los usuarios conectados depende de los registros de contabilidad. Cuando se genera un registro de "inicio" de contabilización pero no hay un registro de "detención", el servidor TACACS o RADIUS asume que la persona aún está conectada (es decir, tiene una sesión a través del PIX). Esto funciona bien en conexiones Telnet y FTP debido a la naturaleza de las conexiones. Por ejemplo:
El usuario utiliza Telnet desde 171.68.118.100 hasta 9.9.9.25 a través del PIX, autenticándose en el camino:
(pix) 109001: Auth start for user '???' from 171.68.118.100/1200 to 9.9.9.25/23 (pix) 109011: Authen Session Start: user 'cse', sid 3 (pix) 109005: Authentication succeeded for user 'cse' from 171.68.118.100/12 00 to 9.9.9.25/23 (pix) 302001: Built TCP connection 5 for faddr 9.9.9.25/23 gaddr 9.9.9.10/12 00 laddr 171.68.118.100/1200 (cse) (server start account) Sun Nov 8 16:31:10 1998 rtp-pinecone.rtp.cisco.com cse PIX 171.68.118.100 start task_id=0x3 foreign_ip=9.9.9.25 local_ip=171.68.118.100 cmd=telnet
Dado que el servidor ha visto un registro de "inicio" pero no un registro de "detención" (en este momento), el servidor muestra que el usuario "Telnet" ha iniciado sesión. Si el usuario intenta otra conexión que requiere autenticación (quizás desde otro PC) y si max-sessions está configurado en "1" en el servidor para este usuario, el servidor rechaza la conexión.
El usuario realiza negocios en el host de destino y, a continuación, sale (pasa 10 minutos allí).
(pix) 302002: Teardown TCP connection 5 faddr 9.9.9.25/80 gaddr 9.9.9.10/128 1 laddr 171.68.118.100/1281 duration 0:00:00 bytes 1907 (cse) (server stop account) Sun Nov 8 16:41:17 1998 rtp-pinecone.rtp.cisco.com cse PIX 171.68.118.100 stop task_id=0x3 foreign_ip=9.9.9.25 local_ip=171.68.118.100 cmd=telnet elapsed_time=5 bytes_in=98 bytes_out=36
Si uauth es 0 (es decir, autentificar cada vez) o más (autenticar una vez y no de nuevo durante el período uauth), habrá un corte de registro de contabilidad para cada sitio al que se acceda.
Pero el HTTP funciona de manera diferente debido a la naturaleza del protocolo. Aquí tiene un ejemplo:
El usuario navega de 171.68.118.100 a 9.9.9.25 a través del PIX.
(pix) 109001: Auth start for user '???' from 171.68.118.100/1281 to 9.9.9.25 /80 (pix) 109011: Authen Session Start: user 'cse', sid 5 (pix) 109005: Authentication succeeded for user 'cse' from 171.68.118.100/12 81 to 9.9.9.25/80 (pix) 302001: Built TCP connection 5 for faddr 9.9.9.25/80 gaddr 9.9.9.10/12 81 laddr 171.68.118.100/1281 (cse) (server start account) Sun Nov 8 16:35:34 1998 rtp-pinecone.rtp.cisco.com cse PIX 171.68.118.100 start task_id=0x9 foreign_ip=9.9.9.25 local_ip=171.68.118.100 cmd=http (pix) 302002: Teardown TCP connection 5 faddr 9.9.9.25/80 gaddr 9.9.9.10/128 1 laddr 171.68.118.100/1281 duration 0:00:00 bytes 1907 (cse) (server stop account) Sun Nov 8 16:35.35 1998 rtp-pinecone.rtp.cisco .com cse PIX 171.68.118.100 stop task_id=0x9 foreign_ip =9.9.9.25 local_ip=171.68.118.100 cmd=http elapsed_time=0 bytes_ in=1907 bytes_out=223
El usuario lee una página web descargada.
Anote la hora. Esta descarga tardó un segundo (hubo menos de un segundo entre el registro de inicio y el de detención). ¿El usuario ha iniciado sesión en el sitio web y la conexión sigue abierta? No.
¿Se utilizarán aquí las funciones que permiten establecer un número máximo de sesiones y ver a los usuarios conectados? No, porque el tiempo de conexión en HTTP es demasiado corto. El tiempo entre el registro "Built" y "Teardown" (inicio y parada) es de menos de un segundo. No habrá un registro de "inicio" sin un registro de "detención", ya que los registros se producen prácticamente en el mismo instante. Seguirá habiendo un registro de "iniciar" y "detener" enviado al servidor para cada transacción sin importar si el valor de uauth es 0 ó un valor mayor. Sin embargo, el número máximo de sesiones y la vista de usuarios que han iniciado sesión no funcionarán debido a la naturaleza de las conexiones HTTP.
En nuestra red, si decidimos que un usuario saliente (171.68.118.100) no necesita ser autenticado, podemos hacer esto:
aaa authentication any outbound 171.68.118.0 255.255.255.0 9.9.9.11 255.255.255.255 tacacs+ aaa authentication except outbound 171.68.118.100 255.255.255.255 9.9.9.11 255.255.255.255 tacacs+
La discusión anterior es sobre la autenticación del tráfico Telnet (y HTTP, FTP) a través del PIX. Con 4.2.2, las conexiones Telnet al PIX también pueden ser autenticadas. Aquí, definimos las IP de las cajas que pueden conectarse vía Telnet al PIX:
telnet 171.68.118.100 255.255.255.255
A continuación, introduzca la contraseña de Telnet: passwd ww.
Agregue el nuevo comando para autenticar a los usuarios que utilizan Telnet en el PIX:
aaa authentication telnet console tacacs+|radius
Cuando los usuarios realizan Telnet al PIX, se les pide la contraseña Telnet ("ww"). El PIX también solicita el nombre de usuario y la contraseña de TACACS+ o RADIUS.
Si agrega el comando: auth-prompt YOU_ARE_AT_THE_PIX, los usuarios que pasen a través del PIX verán la secuencia:
YOU_ARE_AT_THE_PIX [at which point you enter the username] Password:[at which point you enter the password]
Al llegar al destino final, se mostrarán los mensajes "Nombre de usuario:" y "Contraseña:". Este mensaje sólo afecta a los usuarios que pasan a través del PIX, no al PIX.
Nota: No hay registros contables cortados para acceder al PIX.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
10-Dec-2001 |
Versión inicial |