Configuración de PIX 5.1.x: TACACS+ y RADIUS

Introducción

La autenticación RADIUS y TACACS+ se puede realizar para conexiones FTP, Telnet y HTTP. Generalmente, se pueden hacer funcionar autenticaciones para otros protocolos menos comunes. Se admite la autorización TACACS+; la autorización RADIUS no. Los cambios en la autenticación, autorización y contabilización (AAA) de PIX 5.1 con respecto a la versión anterior incluyen la autenticación ampliada (xauth): autenticación de túneles IPSec desde Cisco Secure VPN Client 1.1.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Antecedentes

Autenticación vs. Autorización

• 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.

• La contabilidad es lo que hizo el usuario.

Supongamos que tiene cien usuarios dentro de la red y sólo desea que seis de estos usuarios puedan realizar FTP, Telnet o HTTP fuera de la red. Usted le diría al PIX que autentique el tráfico saliente y que proporcione las ID de los seis usuarios en el servidor de seguridad TACACS+/RADIUS. Con una autenticación simple, estos seis usuarios podrían ser autenticados con nombre de usuario y contraseña, y luego salir. Los otros noventa y cuatro usuarios no pudieron 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 y, dependiendo de la respuesta, abre o niega la conexión. Estos seis usuarios podían utilizar FTP, Telnet o HTTP.

Pero supongamos que uno de estos seis usuarios, "Festus", no es de fiar. Le gustaría permitir a Festus hacer FTP, pero no HTTP o Telnet hacia el exterior. Esto significa tener que agregar autorización, es decir, autorizar lo que los usuarios pueden hacer además de autenticar quiénes son. Esto sólo es válido con TACACS+. Cuando agregamos la autorización al PIX, el PIX primero envía el nombre de usuario y la contraseña de Festus al servidor de seguridad, luego envía una solicitud de autorización informando al servidor de seguridad qué "comando" está tratando de hacer Festus. Con el servidor configurado correctamente, Festus podría tener permiso para "ftp 1.2.3.4" pero se le negaría la capacidad de HTTP o Telnet en cualquier lugar.

Qué ve el usuario con la autenticación/autorización activada

Cuando intenta ir desde adentro hacia afuera (o viceversa) con autenticación/autorización activada:

• Telnet - El usuario ve una solicitud de nombre de usuario y luego una solicitud de la 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 local_username@remote_username para el nombre de usuario y local_password@remote_password para la contraseña. El PIX envía el nombre de usuario local y la contraseña local al servidor de seguridad local, y si la autenticación (y autorización) es exitosa en el PIX/servidor, el nombre de usuario remoto y la contraseña remota se pasan al servidor FTP de destino más allá.

• 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 que dispara el nombre de usuario y la contraseña almacenados en caché al PIX, que luego reenvía esto al servidor de autenticación. El registro del sistema PIX y/o la depuración del servidor muestran este fenómeno. Si Telnet y FTP parecen funcionar normalmente, pero las conexiones HTTP no, es por esto.

• Túnel: Al intentar tunelizar el tráfico IPSec en la red con VPN Client y xauth on, se muestra un cuadro gris para "User Authentication for New Connection" (Autenticación de usuario para nueva conexión) para el nombre de usuario/contraseña.

  Nota: Esta autenticación se admite a partir de Cisco Secure VPN Client 1.1. Si el menú Help > About no muestra la versión 2.1.x o posterior, esto no funciona.

Configuración del servidor de seguridad utilizado para todos los escenarios

Configuración de Cisco Secure UNIX TACACS Server

En esta sección se incluye la información necesaria para configurar el servidor de seguridad.

Asegúrese de que tiene la dirección IP de PIX o el nombre de dominio completo y la clave en el archivo CSU.cfg.

user = ddunlap {
password = clear "rtp"
default service = permit
}

user = can_only_do_telnet {
password = clear "telnetonly"
service = shell {
cmd = telnet {
permit .*
}
}
}

user = can_only_do_ftp {
password = clear "ftponly"
service = shell {
cmd = ftp {
permit .*
}
}
}

user = httponly {
password = clear "httponly"
service = shell {
cmd = http {
permit .*
}
}
}

Configuración del servidor RADIUS de Cisco Secure UNIX

Utilice la GUI para agregar la clave y la dirección IP de PIX a la lista del Servidor de acceso a la red (NAS).

user=adminuser {
radius=Cisco {
check_items= {
2="all"
}
reply_attributes= {
6=6
}
}
}

Cisco Secure ACS para Windows 2.x RADIUS

Siga estos pasos para configurar Cisco Secure ACS para Windows 2.x RADIUS.

1. Obtenga una contraseña en la sección User Setup GUI (Configuración de usuario).

2. En la sección GUI de configuración de grupo, establezca el atributo 6 (Service-Type) en Login o Administrative.

3. Agregue la dirección IP de PIX en la GUI de la sección de configuración de NAS.

EasyACS TACACS+

La documentación de EasyACS describe la configuración.

1. En la sección de grupo, haga clic en Shell exec para otorgar privilegios exec.

2. Para agregar autorización al PIX, haga clic en Denegar comandos IOS no coincidentes en la parte inferior de la configuración del grupo.

3. Seleccione Add/Edit new command para cada comando que desee permitir, por ejemplo, Telnet.

4. Si se permite la conexión a través de Telnet a sitios específicos, rellene las direcciones IP en la sección de argumentos con el formato "permit #.#.#.#". De lo contrario, para permitir Telnet, haga clic en Permitir todos los argumentos no enumerados.

5. Haga clic en Finalizar comando de edición.

6. Realice los pasos del 1 al 5 para cada uno de los comandos permitidos (por ejemplo, Telnet, HTTP o FTP).

7. Agregue el PIX IP en la sección GUI de configuración de NAS.

Cisco Secure 2.x TACACS+

El usuario obtiene una contraseña en la sección User Setup GUI (Configuración de usuario).

1. En la sección de grupo, haga clic en Shell exec para otorgar privilegios exec.

2. Para agregar autorización al PIX, en la parte inferior de la configuración del grupo, haga clic en Denegar comandos IOS no coincidentes.

3. Seleccione Add/Edit new command para cada comando que desee permitir (por ejemplo, Telnet).

4. Para permitir Telnet a sitios específicos, introduzca la dirección IP en la sección de argumentos con el formato "permit #.#.#.#". Para permitir la conexión Telnet a cualquier sitio, haga clic en Permitir todos los argumentos no enumerados.

5. Haga clic en Finalizar comando de edición.

6. Realice los pasos del 1 al 5 para cada uno de los comandos permitidos (por ejemplo, Telnet, HTTP o FTP).

7. Asegúrese de agregar la dirección IP de PIX en la sección GUI de configuración de NAS.

‘Configuración del servidor Livingston RADIUS’

Agregue la dirección IP y la clave PIX al archivo Clients.

adminuser Password="all" User-Service-Type = Shell-User 

Configuración del servidor Merit RADIUS

Agregue la dirección IP y la clave PIX al archivo Clients.

adminuser Password="all" Service-Type = Shell-User 

Configuración del servidor freeware TACACS+

key = "cisco"
user = adminuser {
login = cleartext "all"
default service = permit
}

user = can_only_do_telnet {
login = cleartext "telnetonly"
cmd = telnet {
permit .*
}
}

user = httponly {
login = cleartext "httponly"
cmd = http { 
permit .*
}
}

user = can_only_do_ftp {
login = cleartext "ftponly"
cmd = ftp { 
permit .*
}
}

Pasos de depuración

Nota: Ciertos comandos show son soportados por la Herramienta Output Interpreter (sólo para clientes registrados) , que le permite ver un análisis del resultado del comando show.

• Asegúrese de que la configuración PIX esté funcionando antes de agregar AAA. Si no puede pasar el tráfico antes de establecer la autenticación y la autorización, no podrá hacerlo después.

• Habilite el registro en el PIX.

  • La depuración de la consola de registro no se debe utilizar en un sistema con mucha carga.

  • Se puede utilizar la depuración guardada en la memoria intermedia del registro y luego ejecutar el comando show logging.

  • El registro también se puede enviar a un servidor syslog y ser examinado allí.

• Active la depuración en los servidores TACACS+ o RADIUS (todos los servidores tienen esta opción).

Diagrama de la red

PIX Version 5.1(1)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 pix/intf2 security10
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
hostname pix3
fixup protocol ftp 21
fixup protocol http 80
fixup protocol smtp 25
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol sqlnet 1521
names
pager lines 24
no logging timestamp
no logging standby
logging console debugging
no logging monitor
no logging buffered
no logging trap
no logging history
logging facility 20
logging queue 512
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto shutdown
mtu outside 1500
mtu inside 1500
mtu pix/intf2 1500
ip address outside 99.99.99.1 255.255.255.0
ip address inside 10.31.1.75 255.255.255.0
ip address pix/intf2 127.0.0.1 255.255.255.255
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 pix/intf2 0.0.0.0
arp timeout 14400
global (outside) 1 99.99.99.7-99.99.99.10 netmask 255.255.255.0
nat (inside) 1 10.31.1.0 255.255.255.0 0 0
static (inside,outside) 99.99.99.99 10.31.1.50 netmask 255.255.255.255 0 0
conduit permit icmp any any 
conduit permit tcp any any 
conduit permit udp any any 
route outside 0.0.0.0 0.0.0.0 99.99.99.2 1
route inside 171.68.118.0 255.255.255.0 10.31.1.1 1
route inside 171.68.120.0 255.255.255.0 10.31.1.1 1
timeout xlate 3:00:00 conn 1:00:00 half-closed 0:10:00 udp 0:02:00
timeout rpc 0:10:00 h323 0:05:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+ 
aaa-server RADIUS protocol radius 
aaa-server AuthInbound protocol tacacs+ 
aaa-server AuthInbound (inside) host 171.68.118.101 cisco timeout 5
aaa-server AuthOutbound protocol radius 
aaa-server AuthOutbound (inside) host 171.68.118.101 cisco timeout 5
aaa authentication include telnet outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
aaa authentication include telnet inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
aaa authentication include http outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
aaa authentication include http inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
aaa authentication include ftp outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
aaa authentication include ftp inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet timeout 5
terminal width 80
Cryptochecksum:b26b560b20e625c9e23743082484caca
: end
[OK] 

Ejemplos de PIX del comando authentication debug

Esta sección muestra ejemplos de depuraciones de autenticación para varios escenarios.

Entrante

El usuario externo en 99.99.99.2 inicia el tráfico al interior de 10.31.1.50 (99.99.99.99) y se autentica a través de TACACS (es decir, el tráfico entrante utiliza la lista de servidores "AuthInbound" que incluye el servidor TACACS 171.68.118.101).

PIX Debug - Buena Autenticación - TACACS+

El siguiente ejemplo muestra una depuración PIX con buena autenticación:

109001: Auth start for user '???' from 
    99.99.99.2/11008 to 10.31.1.50/23
109011: Authen Session Start: user 'cse', sid 4
109005: Authentication succeeded for user 'cse' 
    from 10.31.1.50/23 to 99.99.99.e
302001: Built inbound TCP connection 10 for 
    faddr 99.99.99.2/11008 gaddr 99.99.)

Depuración PIX - Autenticación incorrecta (nombre de usuario o contraseña) - TACACS+

El siguiente ejemplo muestra una depuración PIX con autenticación incorrecta (nombre de usuario o contraseña). El usuario ve tres conjuntos de nombre de usuario/contraseña, seguidos de este mensaje: Error: número máximo de intentos excedidos.

109001: Auth start for user '???' from 
     99.99.99.2/11010 to 10.31.1.50/23
  109006: Authentication failed for user '' from 
     10.31.1.50/23 to 99.99.99.2/11010 on 
     interface outside

Depuración PIX - Puede hacer ping al servidor, sin respuesta - TACACS+

El siguiente ejemplo muestra una depuración PIX en la que el servidor puede hacer ping, pero no se comunica con el PIX. El usuario ve el nombre de usuario una vez, pero el PIX nunca pide una contraseña (esto está en Telnet). El usuario ve Error: se ha superado el número máximo de intentos.

109001: Auth start for user '???' from 99.99.99.2/11011 
     to 10.31.1.50/23
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11011 failed 
     (server 171.68.118.101 failed) on interface outside
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11011 failed 
     (server 171.68.118.101 failed) on interface outside
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11011 failed 
     (server 171.68.118.101 failed) on interface outside
  109006: Authentication failed for user '' from 10.31.1.50/23 
     to 99.99.99.2/11011 on interface outside

Depuración de PIX - No se puede hacer ping al servidor - TACACS+

El siguiente ejemplo muestra una depuración de PIX donde el servidor no es ping. El usuario ve el nombre de usuario una vez, pero el PIX nunca pide una contraseña (esto está en Telnet). Se muestran los siguientes mensajes: Timeout to TACACS+ server y Error: Max number of tries exceeded (un servidor falso fue intercambiado en la configuración).

111005: console end configuration: OK
  109001: Auth start for user '???' from 
     99.99.99.2/11012 to 10.31.1.50/23
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11012 
     failed (server 1.1.1.1 failed) on interface outside
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11012 
     failed (server 1.1.1.1 failed) on interface outside
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11012 
     failed (server 1.1.1.1 failed) on interface outside
  109006: Authentication failed for user '' from 
     10.31.1.50/23 to 99.99.99.2/11012 on interface 
     outside

PIX Debug - Buena Autenticación - RADIUS

El siguiente ejemplo muestra una depuración PIX con buena autenticación:

109001: Auth start for user '???' from 
     10.31.1.50/11008 to 99.99.99.2/23
  109011: Authen Session Start: user 'pixuser', sid 8
  109005: Authentication succeeded for user 
     'pixuser' from 10.31.1.50/11008 to 
     99.99.99.2/23 on interface inside
  302001: Built outbound TCP connection 16 for faddr 
     99.99.99.2/23 gaddr 99.99.99.99/11008 
     laddr 10.31.1.50/11008 (pixuser)

Depuración PIX - Autenticación incorrecta (nombre de usuario o contraseña) - RADIUS

El siguiente ejemplo muestra una depuración PIX con autenticación incorrecta (nombre de usuario o contraseña). El usuario ve la solicitud de un nombre de usuario y una contraseña, y tiene tres oportunidades para introducirlos. Cuando la entrada no se realiza correctamente, se muestra el siguiente mensaje: Error: max number of tries exceeded.

109001: Auth start for user '???' from 10.31.1.50/11010 
     to 99.99.99.2/23
  109006: Authentication failed for user '' 
     from 10.31.1.50/11010 to 99.99.99.2/23 
     on interface inside

Depuración de PIX - Puede hacer ping al servidor, Daemon inactivo - RADIUS

El ejemplo a continuación muestra una depuración PIX donde el servidor es ping, pero el daemon está inactivo y no se comunicará con el PIX. El usuario ve el nombre de usuario, luego la contraseña, el mensaje de error del servidor RADIUS y el mensaje de error Error: Max number of tries exceeded.

109001: Auth start for user '???' from 10.31.1.50/11011 
     to 99.99.99.2/23
  ICMP unreachable (code 3) 171.68.118.101 > 10.31.1.75
  1ICMP unreachable (code 3) 171.68.118.101 > 10.31.1.75
  ICMP unreachable (code 3) 171.68.118.101 > 10.31.1.75
  ICMP unreachable (code 3) 171.68.118.101 > 10.31.1.75
  09002: Auth from 10.31.1.50/11011 to 99.99.99.2/23 
     failed (server 171.68.118.101 failed) on interface inside
  109002: Auth from 10.31.1.50/11011 to 99.99.99.2/23 failed 
     (server 171.68.118.101 failed) on interface inside
  109002: Auth from 10.31.1.50/11011 to 99.99.99.2/23 failed 
     (server 171.68.118.101 failed) on interface inside
  109006: Authentication failed for user '' from 10.31.1.50/11011 
     to 99.99.99.2/23 on interface inside

Depuración de PIX - No se puede hacer ping al servidor o a la discordancia de clave/cliente - RADIUS

El siguiente ejemplo muestra una depuración de PIX donde el servidor no es ping o hay una discordancia de cliente/clave. El usuario ve un nombre de usuario, una contraseña, el mensaje Timeout to RADIUS server y el mensaje Error: Max number of tries exceeded (un servidor falso fue intercambiado en la configuración).

109001: Auth start for user '???' from 10.31.1.50/11012 
     to 99.99.99.2/23
  109002: Auth from 10.31.1.50/11012 to 99.99.99.2/23 failed 
     (server 1.1.1.1 failed) on interface inside
  109002: Auth from 10.31.1.50/11012 to 99.99.99.2/23 failed 
     (server 1.1.1.1 failed) on interface inside
  109002: Auth from 10.31.1.50/11012 to 99.99.99.2/23 failed 
     (server 1.1.1.1 failed) on interface inside
  109006: Authentication failed for user '' from 10.31.1.50/11012 
     to 99.99.99.2/23 on interface inside 

Agregado de autorización

Si decide agregar una autorización, ya que la autorización no es válida sin autenticación, necesita una autorización para el mismo origen e intervalo de destino.

aaa authorization telnet inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
aaa authorization http inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
aaa authorization ftp inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound

Tenga en cuenta que no agrega autorización para tráfico saliente porque el tráfico saliente se autentica con RADIUS y la autorización RADIUS no es válida.

Ejemplos de Depuración de Autenticación y Autorización de PIX

Depuración PIX - Autenticación correcta y autorización exitosa - TACACS+

El siguiente ejemplo muestra una depuración PIX con buena autenticación y autorización exitosa:

109001: Auth start for user '???' from 99.99.99.2/11016 
   to 10.31.1.50/23
109011: Authen Session Start: user 'cse', Sid 11
109005: Authentication succeeded for user 'cse' 
   from 10.31.1.50/23 to 99.99.99.2/11016 on interface outside
109011: Authen Session Start: user 'cse', Sid 11
109007: Authorization permitted for user 'cse' from 
   99.99.99.2/11016 to 10.31.1.50/23 on interface outside
302001: Built inbound TCP connection 19 for faddr 99.99.99.2/11016 
   gaddr 99.99.99.99/23 laddr 10.31.1.50/23 (cse)

Depuración de PIX: autenticación correcta, autorización errónea - TACACS+

El ejemplo a continuación muestra la depuración PIX con buena autenticación pero sin autorización. Aquí el usuario también ve el mensaje Error: Authorization Denied.

109001: Auth start for user '???' from 
    99.99.99.2/11017 to 10.31.1.50/23
109011: Authen Session Start: user 'httponly', 
   Sid 12
109005: Authentication succeeded for user 'httponly' 
   from 10.31.1.50/23 to 99.99.99.2/11017 on 
   interface outside
109008: Authorization denied for user 'httponly' from 
   10.31.1.50/23 to 99.99.99.2/11017 on interface outside

Incorporación de contabilidad

TACACS+

aaa accounting include any inbound 
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound

Salida de software libre TACACS+:

Tue Feb 22 08:52:20 2000  10.31.1.75 cse PIX 
   99.99.99.2 start task_id=0x14 
   foreign_ip=99.99.99.2 local_ip=10.31.1.50 
   cmd=telnet
Tue Feb 22 08:52:25 2000  10.31.1.75 cse PIX 
   99.99.99.2 stop task_id=0x14 
   foreign_ip=99.99.99.2 local_ip=10.31.1.50 
   cmd=telnet elapsed_time=5 
   bytes_in=39 bytes_out=126

RADIUS

aaa accounting include any outbound 
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound

Salida Merit RADIUS:

Tue Feb 22 08:56:17 2000
        Acct-Status-Type = Start
        NAS-IP-Address = 10.31.1.75
        Login-IP-Host = 10.31.1.50
        Login-TCP-Port = 23
        Acct-Session-Id = 0x00000015
        User-Name = pixuser

        Tue Feb 22 08:56:24 2000
        Acct-Status-Type = Stop
        NAS-IP-Address = 10.31.1.75
        Login-IP-Host = 10.31.1.50
        Login-TCP-Port = 23
        Acct-Session-Id = 0x00000015
        Username = pixuser
        Acct-Session-Time = 6
        Acct-Input-Octets = 139
        Acct-Output-Octets = 36

Uso del comando Exclude

Si agregamos otro host externo (en 99.99.99.100) a nuestra red y este host es de confianza, puede excluirlo de la autenticación y la autorización con los siguientes comandos:

aaa authentication exclude telnet inbound 0.0.0.0 0.0.0.0 99.99.99.100
 255.255.255.255 AuthInbound

aaa authorization exclude telnet inbound 0.0.0.0 0.0.0.0 99.99.99.100 255.255.255.255 
AuthInbound  

Establecer el número máximo de sesiones y ver a los usuarios conectados

Algunos servidores TACACS+ y RADIUS tienen funciones que permiten establecer un número máximo de sesiones o ver a los 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 informe de control de "inicio" pero ningún informe de "detención", el servidor TACACS+ o RADIUS asume que la persona se encuentra todavía conectada (es decir, el usuario tiene una sesión abierta a través de PIX).

Esto funciona bien en conexiones Telnet y FTP debido a la naturaleza de las conexiones. Esto no funciona bien para HTTP debido a la naturaleza de la conexión. En el siguiente ejemplo, se utiliza una configuración de red diferente, pero los conceptos son los mismos.

El usuario establece una conexión Telnet por medio de PIX, autenticación en camino.

   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

Debido a 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 de Telnet está conectado. Si el usuario intenta otra conexión que requiere autenticación (quizás desde otro PC), y si max-sessions se establece en 1 en el servidor para este usuario (suponiendo que el servidor admita max-sessions), el servidor rechaza la conexión.

El usuario realiza su actividad de Telnet o FTP en el host de destino y, a continuación, sale (pasa diez 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

Ya sea que uauth sea 0 (es decir, autenticar cada vez) o mayor (autenticar una vez y no de nuevo durante un período uauth), un registro contable se divide para cada sitio accedido.

HTTP funciona de manera distinta debido a la naturaleza del protocolo. A continuación se muestra un ejemplo de HTTP:

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 la página web descargada.

El registro de inicio está fijado a las 16:35:34 y el registro de detención a las 16:35:35. Esta descarga tardó sólo un segundo (es decir, hubo menos de un segundo entre el registro de inicio y de detención). ¿Está el usuario conectado aún con el sitio web y la conexión está abierta aún cuando el usuario está leyendo la página web? No. ¿Funcionarán aquí el número máximo de sesiones o la vista de usuarios que han iniciado sesión? No, porque el tiempo de conexión (el tiempo entre la 'conexión' y la 'desconexión') en HTTP es demasiado corto. El registro de inicio y detención está en subsegundos. No hay 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 inicio y detención enviado al servidor para cada transacción, ya sea que uauth esté configurado en 0 o algo más grande. Sin embargo, las funciones número máximo de sesiones y ver usuarios conectados no funcionarán debido a la índole de las conexiones HTTP.

Autenticación y activación en el PIX mismo

La discusión anterior se refiere a la autenticación del tráfico Telnet (y HTTP, FTP) a través del PIX. Asegúrese de que Telnet al PIX funcione sin autenticación en:

telnet 10.31.1.5 255.255.255.255
passwd ww

A continuación, agregue el comando para autenticar a los usuarios que utilizan Telnet en el PIX:

aaa authentication telnet console AuthInbound

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. En este caso, dado que se utiliza la lista de servidores AuthInbound, el PIX solicita el nombre de usuario y la contraseña de TACACS+.

Si el servidor está inactivo, puede acceder al PIX ingresando pix para el nombre de usuario, y luego la contraseña de habilitación (enable password, lo que sea). Con el comando:

aaa authentication enable console AuthInbound

Se solicita al usuario un nombre de usuario y una contraseña que se envían al servidor TACACS o RADIUS. En este caso, dado que se utiliza la lista de servidores AuthInbound, el PIX solicita el nombre de usuario y la contraseña de TACACS+.

Dado que el paquete de autenticación para enable es el mismo que el paquete de autenticación para login, si el usuario puede ingresar al PIX con TACACS o RADIUS, puede habilitar a través de TACACS o RADIUS con el mismo nombre de usuario/contraseña. Este problema se ha asignado al Id. de bug Cisco CSCdm47044 (sólo para clientes registrados) .

Si el servidor está inactivo, puede acceder al modo de habilitación de PIX ingresando pix para el nombre de usuario y la contraseña de habilitación normal del PIX (enable password, lo que sea). Si enable password lo que sea no se encuentra en la configuración PIX, ingrese pix para el nombre de usuario y presione Enter (Aceptar). Si la contraseña de habilitación está establecida pero no se conoce, es necesario crear un disco de recuperación de contraseña para restablecer la contraseña.

Modificación de la línea de comando que ven los usuarios

Si tiene el comando:

auth-prompt PIX_PIX_PIX

los usuarios que pasan a través del PIX ven la siguiente secuencia:

PIX_PIX_PIX [at which point one would enter the username] 
   Password:[at which point one would enter the password] 

Al llegar al destino final, los usuarios verán el mensaje Nombre de usuario: y Contraseña: en el cuadro de destino. Esta indicación 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.

Personalizar el mensaje que ven los usuarios en Éxito/Fracaso

Si tiene los comandos:

auth-prompt accept "GOOD_AUTH" 
auth-prompt reject "BAD_AUTH" 

a continuación, los usuarios ven la siguiente secuencia en un login fallido/exitoso a través del PIX:

PIX_PIX_PIX 
   Username: asjdkl
   Password: "BAD_AUTH" 
   "PIX_PIX_PIX" 
   Username: cse 
   Password: "GOOD_AUTH" 

Tiempos de Espera Absolutos e Inactivos por Usuario

Esta función actualmente no funciona y se ha asignado el ID de bug de Cisco CSCdp93492 al problema (sólo para clientes registrados) .

HTTP virtual

Si se requiere autenticación en los sitios fuera del PIX como así también en el mismo PIX, a veces se puede observar un comportamiento inusual del explorador, ya que los exploradores colocan el nombre de usuario y la contraseña en la memoria caché.

Para evitar esto, puede implementar el HTTP virtual agregando una dirección RFC 1918 (es decir, una dirección que no se puede rutear en Internet, pero que es válida y única para la red interna PIX) a la configuración PIX mediante el siguiente comando:

virtual http #.#.#.# [warn]

Cuando el usuario intente salir de PIX, se le pedirá autenticación. Si está el parámetro de advertencia, el usuario recibe un mensaje de redirección. La autenticación sirve durante el período de tiempo en uauth. Como se indica en la documentación, no establezca la duración del comando timeout uauth en 0 segundos con HTTP virtual; esto evita las conexiones HTTP al servidor web real.

Ejemplo de HTTP Saliente Virtual

Configuración de PIX Virtual HTTP Outbound:

ip address outside 99.99.99.1 255.255.255.0
ip address inside 10.31.1.75 255.255.255.0
global (outside) 1 99.99.99.7-99.99.99.10 netmask 255.255.255.0
timeout uauth 01:00:00
aaa authentication include http outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
aaa-server RADIUS protocol radius
aaa-server AuthOutbound protocol radius
aaa-server AuthOutbound (inside) host 171.68.118.101 cisco timeout 5
virtual http 10.31.1.99

Virtual telnet

Es posible configurar el PIX para autenticar todos los mensajes entrantes y salientes, pero no es una buena idea porque algunos protocolos, como el correo, no se autentican fácilmente. Cuando un servidor de correo y un Cliente intentan comunicarse a través del PIX cuando todo el tráfico a través del PIX está siendo autenticado, el syslog PIX para protocolos no autenticables muestra mensajes como:

109013: User must authenticate before using 
    this service
109009: Authorization denied from 171.68.118.106/49 
    to 9.9.9.10/11094    (not authenticated) 

Sin embargo, si realmente hay una necesidad de autenticar algún tipo de servicio inusual, esto se puede hacer mediante el comando virtual telnet. Este comando permite que la autenticación se produzca en la dirección IP Telnet virtual. Después de esta autenticación, el tráfico para el servicio inusual puede ir al servidor real.

En este ejemplo, desea que el tráfico del puerto TCP 49 fluya desde el host externo 99.99.99.2 al host interno 171.68.118.106. Dado que este tráfico no es realmente autenticable, configure una Telnet virtual. Para Telnet virtual, debe haber una estática asociada. Aquí, tanto 99.99.99.20 como 171.68.118.20 son direcciones virtuales.

Entrada de Telnet virtual

Configuración de PIX Virtual Telnet Inbound

ip address outside 99.99.99.1 255.255.255.0
ip address inside 10.31.1.75 255.255.255.0
static (inside,outside) 99.99.99.20 171.68.118.20 netmask 255.255.255.255 0 0
static (inside,outside) 99.99.99.30 171.68.118.106 netmask 255.255.255.255 0 0
conduit permit tcp host 99.99.99.20 eq telnet any
conduit permit tcp host 99.99.99.30 eq tacacs any
aaa-server TACACS+ protocol tacacs+
aaa-server Incoming protocol tacacs+
aaa-server Incoming (inside) host 171.68.118.101 cisco timeout 5
aaa authentication include telnet inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Incoming
aaa authentication include tcp/49 inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Incoming
virtual telnet 99.99.99.20

PIX Debug Virtual Telnet Inbound

El usuario en 99.99.99.2 debe autenticarse primero mediante Telnet a la dirección 99.99.99.20 en el PIX:

109001: Auth start for user '???' from 
    99.99.99.2/22530 to 171.68.118.20/23
 109011: Authen Session Start: user 'cse', Sid 13
 109005: Authentication succeeded for user 
    'cse' from 171.68.118.20/23 to 
    99.99.99.2/22530 on interface outside

Después de la autenticación exitosa, el comando show uauth muestra que el usuario tiene "tiempo en el medidor":

pixfirewall# show uauth
                        Current    Most Seen
Authenticated Users       1          2
Authen In Progress        0          1
user 'cse' at 99.99.99.2, authenticated
   absolute   timeout: 0:05:00
   inactivity timeout: 0:00:00 

Y cuando el dispositivo en 99.99.99.2 desea enviar tráfico TCP/49 al dispositivo en 171.68.118.106:

302001: Built inbound TCP connection 16 
    for faddr 99.99.99.2/11054 gaddr 
    99.99.99.30/49 laddr 171.68.118.106/49 (cse)

La autorización se puede agregar:

aaa authorization include tcp/49 inbound 
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound

de modo que cuando se intenta el tráfico TCP/49 a través del PIX, el PIX también envía la consulta de autorización al servidor:

109007: Authorization permitted for user 'cse' 
    from 99.99.99.2/11057 to 171.68.118.106/49 
    on interface outside

En el servidor TACACS+, esto se ve como:

service=shell, 
  cmd=tcp/49, 
  cmd-arg=171.68.118.106 

Virtual Telnet de salida

Dado que el tráfico saliente está permitido de forma predeterminada, no se requiere estática para el uso de Telnet saliente virtual. En el siguiente ejemplo, el usuario interno en 10.31.1.50 se conecta mediante Telnet a la red virtual 99.99.99.30 y se autentica; la conexión Telnet se descarta inmediatamente. Una vez autenticado, el tráfico TCP se permite desde 10.31.1.50 al servidor en 99.99.99.2:

Configuración de PIX Virtual Telnet Outbound:

ip address outside 99.99.99.1 255.255.255.0
ip address inside 10.31.1.75 255.255.255.0
global (outside) 1 99.99.99.7-99.99.99.10 netmask 255.255.255.0
timeout uauth 0:05:00 absolute
aaa-server RADIUS protocol radius
aaa-server AuthOutbound protocol radius
aaa-server AuthOutbound (inside) host 171.68.118.101 cisco timeout 5
aaa authentication include telnet outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
aaa authentication include tcp/49 outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
virtual telnet 99.99.99.30

Nota: No hay autorización porque es RADIUS.

PIX Debug Virtual Telnet Outbound:

109001: Auth start for user '???' from 10.31.1.50/11034 
    to 99.99.99.30/23
 109011: Authen Session Start: user 'pixuser', Sid 16
 109005: Authentication succeeded for user 'pixuser' 
    from 10.31.1.50/11034 to 99.99.99.30/23 on interface 
    inside
 302001: Built outbound TCP connection 18 for faddr 
    99.99.99.2/49 gaddr 99.99.99.8/11036 laddr 
    10.31.1.50/11036 (pixuser)
 302002: Teardown TCP connection 18 faddr 99.99.99.2/49 
    gaddr 99.99.99.8/11036 laddr 10.31.1.50/11036 
    duration 0:00:02 bytes 0 (pixuser)

Desconexión de Virtual Telnet

Cuando los usuarios realizan Telnet a la dirección IP de Telnet virtual, el comando show uauth muestra su uauth. Si los usuarios quieren evitar que el tráfico pase después de que sus sesiones hayan terminado cuando queda tiempo en la autenticación, necesitan comunicarse vía Telnet con la dirección IP Telnet virtual nuevamente. Esto finaliza la sesión.

Después de la primera autenticación:

 pix3# show uauth
                         Current    Most Seen
 Authenticated Users       1          2
 Authen In Progress        0          1
 user 'pixuser' at 10.31.1.50, authenticated
    absolute   timeout: 0:05:00
    inactivity timeout: 0:00:00
 pix3# 109001: Auth start for user 'pixuser' from 
    10.31.1.50/11038 to 99.99.99.30/23
 109005: Authentication succeeded for user 'pixuser' 
    from 10.31.1.50/11038 to 99.99.99.30/23 on 
    interface inside

Después de la segunda autenticación (es decir, el orificio se activa o se cierra):

 pix3# show uauth 
                         Current    Most Seen
 Authenticated Users       0          2
 Authen In Progress        0          1

‘Autorización del puerto

Se permite la autorización para intervalos de puertos (como TCP/30-100). Si el Telnet virtual está configurado en el PIX y la autorización para un rango de puertos, una vez que el agujero se abre con el Telnet virtual, el PIX emite un comando tcp/30-100 al servidor TACACS+ para la autorización:

static (inside,outside) 99.99.99.75 10.31.1.50 netmask 255.255.255.255 0 0
conduit permit tcp host 99.99.99.75 host 99.99.99.2
static (inside,outside) 99.99.99.75 10.31.1.50 netmask 255.255.255.255 0 0
virtual telnet 99.99.99.75
aaa authentication include any inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
aaa authorization include tcp/30-100 inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
virtual telnet 99.99.99.30

Configuración del servidor freeware TACACS+:

user = anyone {
         login = cleartext "anyone"
         cmd = tcp/30-100 {
         permit 10.31.1.50
         }
         }

Contabilización AAA para cualquier otro tráfico que no sea HTTP, FTP y Telnet

Después de asegurarnos de que Telnet virtual funcionaba para permitir el tráfico TCP/49 al host dentro de la red, decidimos que queríamos contabilizar esto, así que agregamos:

aaa accounting include any inbound 
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound 

Esto resulta en tener un corte de registro de contabilidad cuando el tráfico tcp/49 pasa (este ejemplo es del freeware TACACS+):

Sun Feb 27 05:24:44 2000 10.31.1.75 cse PIX 
    99.99.99.2 start task_id=0x14 foreign_ip=99.99.99.2 local_ip=171.68.118.106 
    cmd=tcp/49 

Autenticación ampliada (Xauth)

Configuraciones de Ejemplo

• Finalización de túneles IPSec en interfaces Cisco Secure PIX Firewall múltiples con Xauth.

• IPSec entre Cisco Secure PIX Firewall y un cliente VPN con autenticación ampliada

Autenticación en DMZ

Para autenticar a los usuarios que van de una interfaz DMZ a otra, dígale al PIX que autentique el tráfico para las interfaces con nombre. En nuestro PIX la disposición es:

least secure 

PIX outside (security0) = 1.1.1.1 

pix/intf4 (DMZ - security20) = 4.4.4.4 & device 4.4.4.2 

pix/intf5 (DMZ - security25) = 5.5.5.5 & device 5.5.5.8 

(static to 4.4.4.15)

PIX inside (security100) = 10.31.1.47

 most secure 

Diagrama de la red

Configuración de PIX

Queremos autenticar el tráfico Telnet entre pix/intf4 y pix/intf5:

nameif ethernet0 outside security0 
nameif ethernet1 inside security100 
(nameif ethernet2 pix/intf2 security10 
nameif ethernet3 pix/intf3 security15) 
nameif ethernet4 pix/intf4 security20 
nameif ethernet5 pix/intf5 security25
ip address outside 1.1.1.1 255.255.255.0
ip address inside 10.31.1.47 255.255.255.0 
(ip address pix/intf2 127.0.0.1 255.255.255.255 
ip address pix/intf3 127.0.0.1 255.255.255.255)
ip address pix/intf4 4.4.4.4 255.255.255.0 
ip address pix/intf5 5.5.5.5 255.255.255.0 
static (pix/intf5,pix/intf4) 4.4.4.15 5.5.5.8 netmask 255.255.255.255 0 0 
aaa authentication telnet pix/intf4 5.5.5.0 255.255.255.0 
4.4.4.0 255.255.255.0 AuthInbound
aaa authentication telnet pix/intf5 5.5.5.0 255.255.255.0 
4.4.4.0 255.255.255.0 AuthInbound
aaa-server TACACS+ protocol tacacs+
aaa-server AuthInbound protocol tacacs+ 
aaa-server AuthInbound (inside) host 171.68.118.101 cisco timeout 5

Contabilidad Xauth

Si el comando sysopt connection permit-ipsec, no el comando sysopt ipsec pl-compatible, se configura en el PIX con xauth, la contabilización es válida para las conexiones TCP, pero no para ICMP o UDP.

Información Relacionada

• Página de soporte de producto PIX
• Referencia de Comandos PIX
• Página de soporte de RADIUS
• Solicitudes de Comentarios (RFC)
• Página de soporte de Secure para UNIX de Cisco
• Página de soporte de Cisco Secure ACS para Windows
• Soporte Técnico - Cisco Systems