Segurança : Cliente de mobilidade Cisco AnyConnect Secure

Diferenças comportáveis em relação às perguntas DNS e definição do Domain Name em OS diferentes

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como perguntas diferentes do Domain Name System (DNS) do punho dos sistemas operacionais (OS) e as influências na definição do Domain Name com Cisco AnyConnect e Tunelamento rachado ou completo.

Contribuído por engenheiros de TAC da Cisco.

Separação contra o padrão DNS

Quando você se usa separação-inclua o Tunelamento, você têm três opções de DNS:

  1. DNS em divisão - As perguntas DNS que combinam os Domain Name que que são configurados no movimento adaptável da ferramenta de segurança de Cisco (ASA) através do túnel (aos servidores DNS que são definidos no ASA, por exemplo) e outro não fazem.

  2. Túnel-todo-DNS - Somente o tráfego DNS aos servidores DNS que são definidos no ASA é permitido. Este ajuste é configurado na política do grupo.

  3. Padrão DNS - Todas as perguntas DNS movem-se através dos servidores DNS que são definidos pelo ASA. No caso de uma resposta negativa, as perguntas DNS puderam igualmente ir aos servidores DNS que são configurados no adaptador físico.

Nota: O comando separação-túnel-todo-dns foi executado primeiramente na versão ASA 8.2(5). Antes desta versão, você poderia somente fazer o DNS em divisão ou o padrão DNS.

Em todos os casos, as perguntas DNS que são definidas para se mover através do túnel vão a todos os servidores DNS que forem definidos no ASA. Se não há nenhum servidor DNS definido no ASA, a seguir os ajustes DNS estão vazios para o túnel. Se você não tem o DNS em divisão definido, a seguir todas as perguntas DNS estão enviadas aos servidores DNS que são definidos pelo ASA. Contudo, os comportamentos que são descritos neste documento podem ser diferentes, dependente do operating system (OS).

Nota: Evite o uso do NSLookup quando você testa a resolução de nome no cliente. Em lugar de, confie em um navegador ou use o comando ping. Isto é porque NSLookup não confia no solucionador DNS do OS. AnyConnect não força o pedido DNS através de uma determinada interface mas permite-o ou rejeita-o dependente da configuração do DNS em divisão. A fim forçar o solucionador DNS para tentar um servidor DNS aceitável para um pedido, é importante que o teste do DNS em divisão está executado somente com os aplicativos que confiam no solucionador DNS nativo para a definição do Domain Name (todos os aplicativos exceto NSLookup, escavação, e os aplicativos similares que seguram a resolução de DNS sós, por exemplo).

Retifique contra o melhor DNS em divisão do esforço

A liberação 2.4 de AnyConnect apoia a reserva do DNS em divisão (o melhor DNS em divisão do esforço), que não é o DNS em divisão verdadeiro encontrado no cliente de IPSec do legado. Se o pedido combina um domínio do DNS em divisão, AnyConnect permite que o pedido esteja escavado um túnel dentro ao ASA. Se o server não pode resolver o nome de host, o solucionador DNS continua e envia a mesma pergunta ao servidor DNS que é traçado à interface física.

Por outro lado, se o pedido não combina alguns dos domínios do DNS em divisão, AnyConnect não o escava um túnel dentro ao ASA. Em lugar de, constrói uma resposta de DNS de modo que o solucionador DNS recue e envie a pergunta ao servidor DNS que é traçado à interface física. Esta característica não é chamada é por isso DNS em divisão, mas reserva DNS para o Split Tunneling. Não somente AnyConnect assegura que somente os pedidos que visam domínios do DNS em divisão estão escavados um túnel dentro, ele igualmente confia no comportamento do solucionador DNS do SO de cliente para a resolução de nome do host.

Isto levanta os interesses de segurança devido a um escape privado potencial do Domain Name. Por exemplo, o cliente de DNS nativo pode enviar uma pergunta para um Domain Name privado a um servidor DNS público especificamente quando o server de nome de DNS VPN não poderia resolver a pergunta DNS.

Refira a identificação de bug Cisco CSCtn14578, resolvida atualmente em Microsoft Windows somente, até à data da versão 3.0(4235). A solução executa o DNS em divisão verdadeiro: pergunta restritamente os Domain Name configurados que combinam e são permitidos aos servidores DNS VPN. Todas perguntas restantes são permitidas somente a outros servidores DNS, tais como aquelas configuradas no adaptador físico.

Escave um túnel tudo e escave um túnel todo o DNS

Quando o Split Tunneling estiver desabilitado (o túnel toda a configuração), o tráfego DNS está permitido restritamente através do túnel. O túnel que toda a Configuração de DNS (configurada na política do grupo) envia a todas as pesquisas de DNS através do túnel, junto com algum tipo de Split Tunneling, e a tráfego DNS é permitido restritamente através do túnel.

Isto é consistente através das Plataformas com a uma advertência em Microsoft Windows: quando todo o túnel todo ou escavar um túnel todo o DNS é configurado, AnyConnect permite o tráfego DNS restritamente aos servidores DNS que são configurados no gateway seguro (aplicado ao adaptador de VPN). Este é um aprimoramento de segurança executado junto com a solução verdadeira previamente mencionada do DNS em divisão.

Se isto prova problemático em determinadas encenações (por exemplo, a atualização DNS/requisições de registro deve ser enviada aos servidores DNS NON-VPN), termine então estas etapas:

  1. Se a configuração atual é túnel todo, a seguir permita separação-excluem o Tunelamento. Todo o host único, separação-exclui a rede é aceitável para o uso, tal como um endereço local de link.

  2. Assegure-se de que que escava um túnel todo o DNS não é configurado na política do grupo.

Edição de desempenho DNS resolvida na versão 3.0(4235) de AnyConnect

Esta edição de Microsoft Windows é na maior parte predominante sob estas condições:

  • Com a instalação home do roteador, o DNS e os servidores DHCP são atribuídos o mesmo endereço IP de Um ou Mais Servidores Cisco ICM NT (AnyConnect cria uma rota necessária ao servidor DHCP).

  • Um grande número domínios de DNS estão na política do grupo.

  • Túnel-toda configuração é usada.

  • A resolução de nome é executada por um nome de host NON-qualificado, que implique que o resolver deve tentar um número de sufixos DNS em todos os servidores DNS disponíveis até que esse relevante ao nome de host perguntado esteja tentado.

Esta edição é devido ao cliente de DNS nativo que tenta enviar perguntas DNS através do adaptador físico, que AnyConnect obstrui (dado túnel-toda configuração). Isto conduz a um atraso da resolução de nome que possa ser significativo, especialmente se um grande número sufixos DNS são empurrados pelo final do cabeçalho. O cliente de DNS deve andar através de todas as perguntas e servidores DNS disponíveis até que receba uma resposta positiva.

Este problema é resolvido na versão 3.0(4235) de AnyConnect. Proveja o Bug da Cisco ID CSCtq02141 e CSCtn14578, junto com a introdução à solução verdadeira precedente-mencionada do DNS em divisão, para mais informação.

Se uma elevação não pode ser executada, a seguir estão aqui as alternativas possíveis:

  • Enable separação-exclui o Tunelamento para um endereço IP de Um ou Mais Servidores Cisco ICM NT, que permita os pedidos do DNS local correr através do adaptador físico. Você pode usar um endereço da sub-rede linklocal 169.254.0.0/16 porque é improvável que qualquer dispositivo envia o tráfego a um daqueles endereços IP de Um ou Mais Servidores Cisco ICM NT sobre o VPN. Depois que você permite o Tunelamento da separação-exclusão, permita o acesso no perfil do cliente ou no cliente próprio do LAN local, e desabilite o túnel todo o DNS.

    No ASA, faça estas alterações de configuração:

    access-list acl_linklocal_169.254.1.1 standard permit host 169.254.1.1
    group-policy gp_access-14 attributes
    split-tunnel-policy excludespecified
    split-tunnel-network-list value acl_linklocal_169.254.1.1
    split-tunnel-all-dns disable
    exit

    No perfil do cliente, você deve adicionar esta linha:

    <LocalLanAccess UserControllable="true">true</LocalLanAccess>

    Você pode igualmente permitir este em uma base do por-cliente no cliente GUI de AnyConnect. Navegue ao menu da preferência de AnyConnect, e verifique a caixa de verificação do acesso do LAN local da possibilidade.

  • Use os nomes de domínio totalmente qualificados (FQDNs) em vez dos nomes de host incompetentes para as resoluções de nome.

  • Use um endereço IP de Um ou Mais Servidores Cisco ICM NT diferente para o servidor DNS na interface física.

DNS com o Split Tunneling em OS diferentes

O punho diferente DNS OS procura em maneiras diferentes quando usado com Split Tunneling (sem DNS em divisão) para AnyConnect. Esta seção descreve aquelas diferenças.

Microsoft Windows

Em sistemas de Microsoft Windows, os ajustes DNS são interface per. Se o Split Tunneling é usado, as perguntas DNS podem cair de volta aos servidores DNS físicos do adaptador depois que falham no adaptador do túnel VPN. Se o Split Tunneling sem DNS em divisão é definido, a seguir a resolução de DNS interna e externo trabalha porque cai de volta aos servidores DNS externos.

Macintosh

Em sistemas macintosh, os ajustes DNS são globais. Se o Split Tunneling está usado, mas o DNS em divisão não está usado, não é possível para as perguntas DNS alcançar servidores DNS fora do túnel. Você pode somente resolver internamente, não externamente.

Isto é documentado no Bug da Cisco ID CSCtf20226 e CSCtz86314. Em ambos os casos, esta ação alternativa deve resolver a edição:

  • Especifique um endereço IP de Um ou Mais Servidores Cisco ICM NT externo do servidor DNS sob a política do grupo e use um FQDN para as perguntas dos DN internos.

  • Se os nomes externos são solucionáveis através do túnel, a seguir navegue a avançado > Split Tunneling e desabilite o DNS em divisão através da remoção dos nomes de DNS que são configurados na política do grupo. Isto exige o uso de um FQDN para as perguntas dos DN internos.

O exemplo do DNS em divisão foi resolvido na versão 3.1 de AnyConnect. Contudo, você deve assegurar-se de que uma destas circunstâncias esteja estado conforme:

  • O DNS em divisão deve ser permitido para ambos os protocolos IP, que exige a versão ASA 9.0 de Cisco ou mais atrasado.

  • O DNS em divisão deve ser permitido para um protocolo IP. Se você executa a versão ASA 9.0 de Cisco ou mais atrasado, a seguir use o protocolo do desvio do cliente para o outro protocolo IP. Por exemplo, assegure-se de que não haja nenhum conjunto de endereços e que o protocolo do desvio do cliente está permitido na política do grupo. Alternativamente, se você executa uma versão ASA que esteja mais adiantada do que a versão 9.0, a seguir assegure-se de que não haja nenhum conjunto de endereços configurado para o outro protocolo IP. Isto implica que o outro protocolo IP é IPv6.

Nota: AnyConnect não muda o arquivo resolv.conf no Macintosh OS X, mas muda um pouco ajustes X-específicos do OS DNS. O Macintosh OS X mantém o resolv.conffile atual para razões de compatibilidade. Use o scutil--comando dns a fim ver os ajustes DNS no Macintosh OS X.

iPhone

O iPhone é o oposto completo do sistema macintosh e não é similar ao Microsoft windows. Se o Split Tunneling é definido mas o DNS em divisão não está definido, a seguir o DNS pergunta a saída através do servidor DNS global que é definido. Por exemplo, as entradas de domínio do DNS em divisão são imperativas para a definição interna. Este comportamento é documentado na identificação de bug Cisco CSCtq09624 e fixado na versão 2.5.4038 para o cliente iOS AnyConnect de Apple.

Nota: Esteja ciente que as perguntas do iPhone DNS ignoram domínios .local. Isto é documentado na identificação de bug Cisco CSCts89292. Os coordenadores de Apple confirmam que a edição está causada pela funcionalidade do OS. Este é o comportamento projetado, e Apple não confirma lá é nenhuma mudança para ela.

Informações Relacionadas



Document ID: 116016