Configurando o PIX 5.1.x: TACACS+ e RADIUS

Introdução

A autenticação RADIUS e TACACS+ pode ser feita para conexões FTP, Telnet e HTTP. Em geral, é possível implementar autenticação para outros protocolos menos comuns. A autorização TACACS+ é suportada; a autorização RADIUS não é. As alterações na autenticação, autorização e auditoria (AAA - Authentication, Authorization, and Accounting) do PIX 5.1 em relação à versão anterior incluem a autenticação estendida (xauth - Extended Authentication)— autenticação de túneis IPSec do Cisco Secure VPN Client 1.1.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Informações de Apoio

Autenticação vs. Autorização

• A autenticação é quem é o usuário.

• Autorização é o que o usuário pode fazer.

• A autenticação é válida sem autorização.

• A autorização não é válida sem autenticação.

• Contabilização é o que o usuário fez.

Suponha que você tenha cem usuários e queira que apenas seis desses usuários possam fazer FTP, Telnet ou HTTP fora da rede. Você instruiria o PIX a autenticar o tráfego de saída e daria aos seis usuários IDs no servidor de segurança TACACS+/RADIUS. Com autenticação simples, esses seis usuários podem ser autenticados com nome de usuário e senha e, em seguida, sair. Os outros noventa e quatro usuários não puderam sair. O PIX solicita o nome de usuário/senha aos usuários e, em seguida, passa seu nome de usuário e senha ao servidor de segurança TACACS+/RADIUS e, dependendo da resposta, abre ou nega a conexão. Esses seis usuários podem fazer FTP, Telnet ou HTTP.

Mas suponha que um desses seis usuários, "Festus", não seja confiável. Você gostaria de permitir que o Festus fizesse FTP, mas não HTTP ou Telnet para o exterior. Isso significa ter que adicionar autorização, ou seja, autorizar o que os usuários podem fazer, além de autenticar quem são. Isso só é válido com TACACS+. Quando adicionamos autorização ao PIX, o PIX envia primeiro o nome de usuário e a senha de Festus ao servidor de segurança e, em seguida, envia uma solicitação de autorização informando ao servidor de segurança que "comando" Festus está tentando fazer. Com o servidor configurado corretamente, a Festus poderia ter permissão para "ftp 1.2.3.4", mas seria negada a capacidade de HTTP ou Telnet em qualquer lugar.

O que o usuário visualiza com o modo de autenticação/autorização Ligado

Quando tentar ir de dentro para fora (ou vice-versa) com a autenticação/autorização ligada:

• Telnet – O usuário vê um prompt de nome de usuário ativado e, em seguida, a solicitação para a senha. Se a autenticação (e autorização) for bem-sucedida no PIX/servidor, o usuário está pronto para obter nome de usuário e senha pelo host de destino.

• FTP - O usuário vê a exibição de um prompt de nome de usuário. O usuário precisa digitar local_username@remote_username para o nome de usuário e local_password@remote_password para a senha. O PIX envia o local_username e o local_password ao servidor de segurança local e, se a autenticação (e a autorização) for bem-sucedida no PIX/servidor, o remote_username e o remote_password são passados para o servidor FTP de destino além do PIX/servidor.

• HTTP - Uma janela é exibida no navegador solicitando um nome de usuário e uma senha. Se a autenticação (e autorização) for concluída com sucesso, o usuário chega ao web site de destino. Lembre-se de que os navegadores armazenam nomes de usuário e senhas no cache. Se parecer que o PIX deveria estar atingindo o tempo limite de uma conexão HTTP, mas não estiver fazendo isso, é provável que a reautenticação esteja realmente ocorrendo com o navegador disparando o nome de usuário e a senha em cache para o PIX, que, em seguida, encaminha isso para o servidor de autenticação. O syslog de PIX e/ou a depuração de servidor mostra esse fenômeno. Se o Telnet e o FTP parecerem funcionar normalmente, mas as conexões HTTP não, esse é o motivo.

• Túnel - Ao tentar fazer o túnel do tráfego IPSec para a rede com o VPN Client e xauth ativado, uma caixa cinza para "User Authentication for New Connection" é exibida para o nome de usuário/senha.

  Observação: esta autenticação é suportada a partir do Cisco Secure VPN Client 1.1. Se o menu Help > About não mostrar a versão 2.1.x ou posterior, isso não funcionará.

Configurações de servidor de segurança utilizadas para todos os cenários

Configuração do servidor Cisco Secure UNIX TACACS

Nesta seção, você verá as informações para configurar seu servidor de segurança.

Verifique se você tem o endereço IP do PIX ou o nome de domínio totalmente qualificado e a chave no arquivo 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 .*
}
}
}

Configuração do servidor Cisco Secure UNIX RADIUS

Use a GUI para adicionar o endereço IP e a chave do PIX à lista do NAS (Servidor de Acesso à Rede).

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

Cisco Secure ACS para Windows 2.x RADIUS

Siga estas etapas para configurar o Cisco Secure ACS para Windows 2.x RADIUS.

1. Obtenha uma senha na seção User Setup GUI (GUI de configuração do usuário).

2. Na seção da GUI de configuração do grupo, defina o atributo 6 (Service-Type) como Login ou Administrative.

3. Adicione o endereço IP do PIX na GUI da seção de configuração do NAS.

EasyACS TACACS+

A documentação do EasyACS descreve a configuração.

1. Na seção de grupo, clique em Shell exec para conceder privilégios de exec.

2. Para adicionar autorização ao PIX, clique em Deny unmatched IOS commands na parte inferior da configuração do grupo.

3. Selecione Add/Edit new command para cada comando que você deseja permitir, por exemplo, Telnet.

4. Se o Telnet para sites específicos for permitido, preencha o(s) endereço(s) IP na seção de argumento no formato "permit #.#.#.#". Caso contrário, para permitir Telnet, clique em Permitir todos os argumentos não listados.

5. Clique em Finish editing command.

6. Execute as etapas de 1 a 5 para cada um dos comandos permitidos (por exemplo, Telnet, HTTP ou FTP).

7. Adicione o IP do PIX na seção da GUI de configuração do NAS.

Cisco Secure 2.x TACACS+

O usuário obtém uma senha na seção User Setup GUI (GUI de configuração do usuário).

1. Na seção de grupo, clique em Shell exec para conceder privilégios de exec.

2. Para adicionar autorização ao PIX, na parte inferior da configuração do grupo, clique em Negar comandos IOS não correspondentes.

3. Selecione Add/Edit new command para cada comando que você deseja permitir (por exemplo, Telnet).

4. Para permitir Telnet para sites específicos, insira o endereço IP na seção de argumento no formato "permit #.#.#.#". Para permitir Telnet para qualquer site, clique em Permitir todos os argumentos não listados.

5. Clique em Finish editing command.

6. Execute as etapas de 1 a 5 para cada um dos comandos permitidos (por exemplo, Telnet, HTTP ou FTP).

7. Certifique-se de que o endereço IP do PIX seja adicionado na seção da GUI de configuração do NAS.

Configuração de servidor Livingston RADIUS

Adicione o endereço IP e a chave do PIX ao arquivo Clients.

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

Configuração de servidor Merit RADIUS

Adicione o endereço IP e a chave do PIX ao arquivo Clients.

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

TACACS+ Configuração do programa gratuito de servidor

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 .*
}
}

Etapas de depuração

Observação: determinados comandos show são suportados pela Output Interpreter Tool (somente clientes registrados) , que permite exibir uma análise da saída do comando show.

• Certifique-se de que a configuração do PIX esteja funcionando antes de adicionar AAA. Se você não puder passar o tráfego antes de instituir a autenticação e a autorização, não poderá fazê-lo posteriormente.

• Ative o registro no PIX.

  • A depuração do console de registro não deve ser usada em um sistema muito carregado.

  • A depuração de registro colocado em buffer pode ser usada; em seguida, execute o comando show logging.

  • O registro também pode ser enviado a um servidor syslog e examinado lá.

• Ative a depuração nos servidores TACACS+ ou RADIUS (todos os servidores têm essa opção).

Diagrama de Rede

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] 

Exemplos de debug de autenticação a partir de PIX

Esta seção mostra exemplos de depurações de autenticação para vários cenários.

Entrada

O usuário externo em 99.99.99.2 inicia o tráfego para o interior 10.31.1.50 (99.99.99.99) e é autenticado através do TACACS (ou seja, o tráfego de entrada usa a lista de servidores "AuthInbound", que inclui o servidor TACACS 171.68.118.101).

Depuração de PIX - boa autenticação - TACACS+

O exemplo abaixo mostra uma depuração de PIX com boa autenticação:

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

Depuração de PIX - Autenticação Incorreta (Nome de Usuário ou Senha) - TACACS+

O exemplo abaixo mostra uma depuração de PIX com autenticação incorreta (nome de usuário ou senha). O usuário vê três conjuntos de nome de usuário/senha, seguidos por esta mensagem: Erro: número máximo de tentativas excedidas.

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

Depuração de PIX - Pode Fazer Ping no Servidor, Sem Resposta - TACACS+

O exemplo abaixo mostra uma depuração de PIX em que o servidor pode receber ping, mas não está falando com o PIX. O usuário vê o nome de usuário uma vez, mas o PIX nunca solicita uma senha (isso está no Telnet). O usuário vê Erro: número máximo de tentativas excedido.

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

Depuração de PIX - Não é Possível Fazer Ping no Servidor - TACACS+

O exemplo abaixo mostra uma depuração de PIX em que o servidor não pode receber ping. O usuário vê o nome de usuário uma vez, mas o PIX nunca solicita uma senha (isso está no Telnet). As seguintes mensagens são exibidas: Timeout para o servidor TACACS+ e Error: Max number of tries beyond (um servidor falso foi trocado na configuração).

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

Depuração de PIX - boa autenticação - RADIUS

O exemplo abaixo mostra uma depuração de PIX com boa autenticação:

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)

Depuração de PIX - Autenticação Incorreta (Nome de Usuário ou Senha) - RADIUS

O exemplo abaixo mostra uma depuração de PIX com autenticação incorreta (nome de usuário ou senha). O usuário vê a solicitação de um nome de usuário e senha e tem três oportunidades para inseri-los. Quando a entrada não é bem-sucedida, a seguinte mensagem é exibida: Erro: número máximo de tentativas excedido.

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

Depuração de PIX - Pode fazer ping no servidor, daemon desativado - RADIUS

O exemplo abaixo mostra uma depuração de PIX em que o servidor pode receber ping, mas o daemon está desativado e não se comunicará com o PIX. O usuário vê o nome de usuário, a senha, a mensagem Falha do servidor RADIUS e a mensagem de erro Erro: número máximo de tentativas excedidas.

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

Depuração de PIX - Não é possível fazer ping no servidor ou incompatibilidade de chave/cliente - RADIUS

O exemplo abaixo mostra uma depuração de PIX em que o servidor não é passível de ping ou há uma incompatibilidade de Client/key. O usuário vê um nome de usuário, uma senha, a mensagem Timeout to RADIUS server e a mensagem Error: Max number of tries beyond (um servidor falso foi trocado na configuração).

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 

Autorização de adição

Se decidir adicionar autorização, já que a autorização não é válida sem autenticação, você precisará de autorização para o mesmo intervalo de origem e 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

Observe que você não adiciona autorização para saída porque o tráfego de saída é autenticado com o RADIUS e a autorização do RADIUS não é válida.

Exemplos de depuração de autenticação e de autorização do PIX

Depuração de PIX - boa autenticação e autorização bem-sucedida - TACACS+

O exemplo abaixo mostra uma depuração de PIX com boa autenticação e autorização bem-sucedida:

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)

Depuração de PIX - boa autenticação, falha de autorização - TACACS+

O exemplo abaixo mostra a depuração de PIX com boa autenticação, mas com falha de autorização. Aqui o usuário também vê a mensagem 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

Relatório de adição

TACACS+

aaa accounting include any inbound 
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound

Saída do freeware 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

Saída de RADIUS de mérito:

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 do comando Exclude

Se adicionarmos outro host externo (em 99.99.99.100) à nossa rede e esse host for confiável, você poderá excluí-lo da autenticação e da autorização com os seguintes 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  

Max-sessions e visualização de usuários que fizeram login

Alguns servidores de TACACS+ e RADIUS possuem recursos “max-session” ou “visualizar usuários que fizeram login”. A habilidade de realizar max-sessions ou verificar usuários que fizeram login depende dos registros de contabilidade. Quando há um registro “start" (de relatório gerado, mas não há um registro "stop", o servidor TACACS+ ou RADIUS admite que a pessoa ainda está conectada (ou seja, o usuário tem uma sessão no PIX).

Isto funciona bem para conexões Telnet e FTP devido à natureza das conexões. Isso não funciona bem para HTTP devido à natureza da conexão. No exemplo a seguir, uma configuração de rede diferente é usada, mas os conceitos são os mesmos.

Usuário estabelece um Telnet por meio do PIX, autenticando no caminho:

   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

Como o servidor viu um registro de início, mas não um registro de parada, neste momento, o servidor mostra que o usuário Telnet está conectado. Se o usuário tentar outra conexão que exija autenticação (talvez de outro PC), e se max-sessions for definido como 1 no servidor para esse usuário (supondo que o servidor suporte max-sessions), a conexão será recusada pelo servidor.

O usuário realiza suas atividades de Telnet ou FTP no host de destino e, em seguida, sai (passa dez minutos lá):

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

Seja o uauth 0 (isto é, autenticar sempre) ou mais (autenticar uma vez e não mais durante o período de uauth), um registro de contabilidade será cortado para cada local acessado.

O HTTP trabalha de forma diferente devido à natureza do protocolo. Abaixo está um exemplo de HTTP:

O usuário navega de 171.68.118.100 a 9.9.9.25 através do 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

O usuário lê a página da Web baixada.

O registro de início foi lançado às 16:35:34, e o registro de interrupção, às 16:35:35. Esse download levou um segundo (ou seja, houve menos de um segundo entre o início e o término da gravação). O usuário continua conectado ao site e a conexão continua aberta quando o usuário está lendo a página da Web? Não. As sessões máximas ou os usuários conectados serão exibidos aqui? Não, porque o tempo de conexão (o tempo entre “Built” (Construção) e Teardown (Destruição)) em HTTP é muito curto. O registro de início e término está em subsegundos. Não há um registro de início sem um registro de parada, uma vez que os registros ocorrem praticamente no mesmo instante. Ainda haverá registro de início e parada enviado ao servidor para cada transação se uauth estiver definido como 0 ou algo maior. Entretanto, os usuários que efetuaram logon em visualização e máximo de sessões não funcionarão devido à natureza das conexões de HTTP.

Autenticação e habilitação no próprio PIX

A discussão anterior diz respeito à autenticação do tráfego Telnet (e HTTP, FTP) através do PIX. Verifique se Telnet para o PIX funciona sem autenticação em:

telnet 10.31.1.5 255.255.255.255
passwd ww

Em seguida, adicione o comando para autenticar usuários que utilizam Telnet para o PIX:

aaa authentication telnet console AuthInbound

Quando os usuários executam Telnet para o PIX, eles são solicitados a fornecer a senha de Telnet (WW). O PIX também solicita o nome de usuário e a senha TACACS+ ou RADIUS. Nesse caso, como a lista de servidores AuthInbound é usada, o PIX solicita o nome de usuário e a senha TACACS+.

Se o servidor estiver inoperante, você poderá acessar o PIX digitando pix para o nome de usuário e, em seguida, a senha de ativação (senha de ativação seja qual for o ). Com o comando:

aaa authentication enable console AuthInbound

O usuário é solicitado a fornecer um nome de usuário e uma senha que são enviados ao servidor TACACS ou RADIUS. Nesse caso, como a lista de servidores AuthInbound é usada, o PIX solicita o nome de usuário e a senha TACACS+.

Como o pacote de autenticação para enable é o mesmo que o pacote de autenticação para login, se o usuário puder efetuar login no PIX com TACACS ou RADIUS, ele poderá ativar através de TACACS ou RADIUS com o mesmo nome de usuário/senha. Este problema recebeu a ID de bug Cisco CSCdm47044 (somente clientes registrados) .

Se o servidor estiver inoperante, você pode acessar o modo enable do PIX inserindo pix para o nome de usuário e a senha enable normal do PIX (enable password qualquer que seja o ). Caso a habilitação de senha não esteja na configuração PIX, digite pix como nome de usuário e pressione Enter. Se a senha de ativação estiver definida, mas não for conhecida, um disco de recuperação de senha precisará ser criado para redefinir a senha.

Alterando o prompt que os usuários visualizam

Se você tiver o comando:

auth-prompt PIX_PIX_PIX

os usuários que passam pelo PIX veem a seguinte sequência:

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

Ao chegarem ao destino final, os usuários verão o prompt Nome de usuário: e Senha: exibido pela caixa de destino. Esse prompt afeta apenas os usuários que passam pelo PIX, não o PIX.

Observação: não há registros contábeis cortados para acesso ao PIX.

Personalizando a mensagem que os usuários visualizam no êxito/na falha

Se você tiver os comandos:

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

os usuários verão a seguinte sequência em um login com falha/êxito através do PIX:

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

Tempo ocioso e intervalos absolutos por usuário

Esta função não está funcionando no momento e o problema recebeu a ID de bug da Cisco CSCdp93492 (somente clientes registrados) .

HTTP Virtual

Se a autenticação for necessária em locais fora do PIX, bem como no próprio PIX, um comportamento incomum do navegador poderá ser observado algumas vezes, uma vez que os navegadores armazenam o nome do usuário e a senha em cache.

Para evitar isso, você pode implementar o HTTP virtual adicionando um endereço RFC 1918 (isto é, um endereço que não é roteável na Internet, mas válido e exclusivo para a rede interna do PIX) à configuração do PIX usando o seguinte comando:

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

Quando o usuário tenta sair do PIX, a autenticação é necessária. Se o parâmetro de advertência estiver presente, o usuário recebe uma mensagem redirecionada. A autenticação é boa para a durante o tempo do uauth. Como indicado na documentação, não defina a duração do comando timeout uauth como 0 segundos com o HTTP virtual; isso evita conexões HTTP com o servidor Web real.

Exemplo de saída HTTP virtual

Saída HTTP Virtual de Configuração de PIX:

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

Telnet Virtual

É possível configurar o PIX para autenticar toda a entrada e saída, mas não é uma boa ideia porque alguns protocolos, como o correio, não são facilmente autenticados. Quando um servidor de e-mail e um cliente tentam se comunicar através do PIX quando todo o tráfego através do PIX está sendo autenticado, o syslog PIX para protocolos não autenticáveis mostra mensagens 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) 

No entanto, se houver realmente uma necessidade de autenticar algum tipo de serviço incomum, isso pode ser feito com o uso do comando virtual telnet. Esse comando permite que a autenticação ocorra no endereço IP do Telnet virtual. Após essa autenticação, o tráfego do serviço incomum pode ir para o servidor real.

Neste exemplo, você deseja que o tráfego da porta TCP 49 flua do host externo 99.99.99.2 para o host interno 171.68.118.106. Como esse tráfego não é realmente autenticável, configure um Telnet virtual. Para Telnet virtual, deve haver um estático associado. Aqui, 99.99.99.20 e 171.68.118.20 são endereços virtuais.

Entrada de Telnet Virtual

Entrada de Telnet Virtual de Configuração de PIX

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

Entrada de Telnet Virtual de Depuração de PIX

O usuário em 99.99.99.2 deve primeiro autenticar-se usando Telnet para o endereço 99.99.99.20 no 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

Após a autenticação bem-sucedida, o comando show uauth mostra que o usuário tem "tempo no 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 

E quando o dispositivo em 99.99.99.2 desejar enviar o tráfego TCP/49 para o dispositivo em 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)

A autorização pode ser adicionada:

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

de forma que quando o tráfego TCP/49 é tentado através do PIX, o PIX também envia a consulta de autorização para o servidor:

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

No servidor TACACS+, isso é visto como:

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

Saída Telnet Virtual

Como o tráfego de saída é permitido por padrão, não é necessário estático para usar a saída Telnet virtual. No exemplo a seguir, o usuário interno em 10.31.1.50 executa Telnet para o virtual 99.99.99.30 e autentica; a conexão Telnet é imediatamente interrompida. Depois de autenticado, o tráfego TCP é permitido de 10.31.1.50 para o servidor em 99.99.99.2:

Saída de Telnet Virtual de Configuração de PIX:

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

Observação: não há autorização, pois este é RADIUS.

Saída de Telnet Virtual de Depuração de PIX:

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)

Desconexão de Telnet Virtual

Quando os usuários executam Telnet para o endereço IP Telnet virtual, o comando show uauth mostra o uauth. Se os usuários desejarem impedir que o tráfego passe após a conclusão de suas sessões quando ainda houver tempo no uauth, eles precisarão executar telnet para o endereço IP do Telnet virtual novamente. Esta ação desliga a sessão.

Após a primeira autenticação:

 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

Após a segunda autenticação (isto é, o orifício é alternado para fechado):

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

Autorização da porta

A autorização é permitida para intervalos de porta (como TCP/30-100). Se o Telnet virtual for configurado no PIX e a autorização para um intervalo de portas, uma vez que o furo é aberto com o Telnet virtual, o PIX emite um comando tcp/30-100 para o servidor TACACS+ para autorização:

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

TACACS+ Configuração do programa gratuito de servidor:

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

Relatório de AAA para tráfego diferente de HTTP, FTP e Telnet

Depois de garantir que o Telnet virtual funcionasse para permitir o tráfego TCP/49 para o host dentro da rede, decidimos que queríamos contabilizar isso, então adicionamos:

aaa accounting include any inbound 
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound 

Isso resulta em um registro de contabilidade cortado quando o tráfego tcp/49 passa (este exemplo é do 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 

Autenticação estendida (Xauth)

Configurações de exemplo

• Terminando os túneis de IPSec de várias interfaces de firewall de PIX do Cisco Secure com Xauth

• IPSec entre o Cisco Secure PIX Firewall e um VPN Client com autenticação estendida

Autenticação no DMZ

Para autenticar usuários indo de uma interface DMZ para outra, instrua o PIX a autenticar o tráfego para as interfaces nomeadas. Em nosso PIX, o arranjo é:

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 Rede

Configuração de PIX

Queremos autenticar o tráfego Telnet entre pix/intf4 e 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

Relatório Xauth

Se o comando sysopt connection permit-ipsec, não o comando sysopt ipsec pl-compatible, estiver configurado no PIX com xauth, a contabilização será válida para conexões TCP, mas não para ICMP ou UDP.

Informações Relacionadas

• Página de Suporte do Produto PIX
• Referências de comando PIX
• Página de suporte RADIUS
• Solicitações de Comentários (RFCs)
• Página de suporte de UNIX Cisco Secure
• Cisco Secure ACS para página de suporte do Windows
• Suporte Técnico - Cisco Systems