O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
O Identity Services Engine (ISE) versão 1.3 suporta uma nova API chamada pxGrid. Esse protocolo moderno e flexível que suporta autenticação, criptografia e privilégios (grupos) permite uma fácil integração com outras soluções de segurança. Este documento descreve o uso do aplicativo pxLog que foi escrito como prova de conceito. O pxLog é capaz de receber mensagens de syslog do IPS (Sistema de Prevenção de Intrusão) e enviar mensagens pxGrid ao ISE para colocar o invasor em quarentena. Como resultado, o ISE usa a alteração de autorização (CoA) do RADIUS para alterar o status de autorização do ponto final que limita o acesso à rede. Tudo isso acontece de forma transparente para o usuário final.
Para este exemplo, o Snort foi usado como o IPS, mas qualquer outra solução poderia ser usada. Na verdade, não precisa ser um IPS. Tudo o que é necessário é enviar a mensagem de syslog para pxLog com o endereço IP do invasor. Isso cria a possibilidade de integração de um grande número de soluções.
Este documento também apresenta como solucionar problemas e testar soluções pxGrid, com os problemas e limitações típicos.
Isenção de responsabilidade: o aplicativo pxLog não é suportado pela Cisco. Este artigo foi escrito como uma prova de conceito. A finalidade principal era usá-lo durante os melhores testes de implementação do pxGrid no ISE.
A Cisco recomenda que você tenha experiência com a configuração do Cisco ISE e conhecimentos básicos destes tópicos:
As informações neste documento são baseadas nestas versões de software e hardware:
Aqui está o fluxo de tráfego, como ilustrado no diagrama de rede:
A solução é instalar um conjunto de aplicativos em uma máquina Linux:
O aplicativo pxLog usa estas bibliotecas:
Todas essas bibliotecas já estão no diretório lib do projeto, portanto não há necessidade de baixar mais arquivos Java ARchive (JAR).
Para instalar o aplicativo:
Este artigo não se concentra em nenhum IPS específico, e é por isso que apenas uma breve explicação é fornecida.
O Snort está configurado como em linha com suporte DAQ. O tráfego é redirecionado com iptables:
iptables -I FORWARD -j ACCEPT
iptables -I FORWARD -j NFQUEUE --queue-num 1
Em seguida, após a inspeção, ele é injetado e encaminhado de acordo com as regras iptable padrão.
Algumas regras personalizadas do Snort foram configuradas (o arquivo /etc/snort/rules/test.rules está incluído na configuração global).
alert icmp any any -> any any (itype:8; dsize:666<>686; sid:100122)
alert icmp any any -> any any (itype:8; ttl: 6; sid:100124)
O Snort envia uma mensagem de syslog quando o Tempo de Vida (TTL) do pacote é igual a 6 ou o tamanho do payload está entre 666 e 686. O tráfego não é bloqueado pelo Snort.
Além disso, os limites devem ser configurados para garantir que os alertas não sejam disparados com muita frequência (/etc/snort/threshold.conf):
event_filter gen_id 1, sig_id 100122, type limit, track by_src, count 1, seconds 60
event_filter gen_id 1, sig_id 100124, type limit, track by_src, count 1, seconds 60
Em seguida, o Servidor syslog aponta para a máquina pxLog (/etc/snort/snort.conf):
output alert_syslog: host=10.222.0.61:514, LOG_AUTH LOG_ALER
Para algumas versões do Snort, há bugs relacionados à configuração do syslog e, em seguida, as configurações padrão poderiam ser usadas que apontassem para o localhost e o syslog-ng poderia ser configurado para encaminhar mensagens específicas ao host pxLog.
O EPS deve ser habilitado (desabilitado por padrão) em Administração > Configurações:
Isso permite que você use a funcionalidade de quarentena/não quarentena.
A primeira regra é encontrada somente quando o ponto de extremidade está em quarentena. Então, o acesso limitado é aplicado dinamicamente pelo RADIUS CoA. O switch também deve ser adicionado aos dispositivos de rede com o segredo compartilhado correto.
O status do pxGrid pode ser verificado com o CLI:
lise/admin# show application status ise
ISE PROCESS NAME STATE PROCESS ID
--------------------------------------------------------------------
Database Listener running 6717
Database Server running 51 PROCESSES
Application Server running 9486
Profiler Database running 7804
AD Connector running 10058
M&T Session Database running 7718
M&T Log Collector running 9752
M&T Log Processor running 9712
Certificate Authority Service running 9663
pxGrid Infrastructure Service running 14979
pxGrid Publisher Subscriber Service running 15281
pxGrid Connection Manager running 15248
pxGrid Controller running 15089
Identity Mapping Service running 9962
Há também depurações separadas para o pxGrid (Administração > Log > Configuração do log de depuração > pxGrid). Os arquivos de depuração são armazenados no diretório pxGrid. Os dados mais importantes estão nos formatos pxgrid/pxgrid-jabberd.log e pxgrid/pxgrid-controller.log.
O aplicativo pxLog é implantado automaticamente quando o Tomcat é iniciado.
O pxLog deve processar mensagens de syslog e executar ações com base nele. Para adicionar uma nova regra, selecione Gerenciar regras:
Agora o módulo aplicador procura por esta Expressão Regular (RegExp) na mensagem do syslog: "snort[". Se encontrado, ele pesquisa todos os endereços IP e seleciona aquele que está antes do último. Isso corresponde à maioria das soluções de segurança. Consulte a seção Syslog para obter mais informações. Esse endereço IP (invasor) é colocado em quarentena através do pxGrid. Além disso, uma regra mais granular pode ser usada (por exemplo, pode incluir o número da assinatura).
A estação do Microsoft Windows 7 inicia uma sessão dot1x com fio. O Cisco Anyconnect NAM foi usado como um solicitante. O método EAP-PEAP (Extensible Authentication Protocol-Protected EAP) está configurado.
O perfil de autorização Dot1x Full Access do ISE está selecionado. O switch baixa a lista de acesso para conceder acesso total:
3750#show authentication sessions interface g0/17
Interface: GigabitEthernet0/17
MAC Address: 0050.b611.ed31
IP Address: 10.221.0.240
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
ACS ACL: xACSACLx-IP-PERMIT_ALL-53fc9dbe
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A01000C000037E6BAB267CF
Acct Session ID: 0x00003A70
Handle: 0xA100080E
Runnable methods list:
Method State
dot1x Authc Success
3750#show ip access-lists interface g0/17
permit ip any any
Isso mostra o que acontece se você enviar de um pacote do Microsoft Windows com TTL = 7:
c:\> ping 10.222.0.61 -i 7 -n 1
Esse valor é diminuído no Snort na cadeia de encaminhamento e um alarme é acionado. Como resultado, uma mensagem de syslog em direção ao pxLog é enviada:
Sep 6 22:10:31 snort snort[6310]: [1:100124:0] ALERT {ICMP} 10.221.0.240 ->
10.222.0.61
O pxLog recebe a mensagem do syslog, processa-a e solicita a quarentena desse endereço IP. Isso poderá ser confirmado se você verificar os logs:
O ISE relata que o endereço IP foi colocado em quarentena:
Como resultado, ele revisa a política de autorização, escolhe a quarentena e envia RADIUS CoA para atualizar o status de autorização no switch para aquele endpoint específico.
Essa é a mensagem de encerramento de CoA que força o solicitante a iniciar uma nova sessão e obter acesso limitado (Permit_ICMP):
O resultado pode ser confirmado no switch (acesso limitado para o endpoint):
3750#show authentication sessions interface g0/17
Interface: GigabitEthernet0/17
MAC Address: 0050.b611.ed31
IP Address: 10.221.0.240
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
ACS ACL: xACSACLx-IP-PERMIT_ICMP-53fc9dc5
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A01000C000037E7BAB7D68C
Acct Session ID: 0x00003A71
Handle: 0xE000080F
Runnable methods list:
Method State
dot1x Authc Success
3750#show ip access-lists interface g0/17
permit icmp any any
Neste estágio, o administrador decide cancelar a quarentena desse endpoint:
A mesma operação pode ser executada diretamente do ISE:
O ISE analisa novamente as regras e atualiza o status de autorização no switch (o acesso total à rede é concedido):
O relatório confirma:
O aplicativo pxLog foi gravado para demonstrar a funcionalidade da API do pxGrid. Ele permite:
Mais funcionalidade está planejada para o futuro.
Aqui estão alguns exemplos de capturas de tela do pxLog:
O cliente (usuário) pode ser membro de um grupo de cada vez. Os dois grupos mais comumente usados são:
Conforme mencionado anteriormente, ambos os aplicativos clientes, pxLog e o controlador pxGrid (ISE), devem ter certificados configurados para se comunicarem. O aplicativo pxLog mantém esses arquivos nos arquivos Java KeyStore:
Os arquivos são protegidos por senha (padrão: cisco123). O local do arquivo e as senhas podem ser alterados em WEB-INF/web.xml.
Aqui estão as etapas para gerar um novo Java KeyStore:
pxgrid store # keytool -import -alias ca -keystore root.jks -file cert-ca.der
pxgrid store # keytool -import -alias mnt -keystore root.jks -file cert-mnt.der
pxgrid store # keytool -import -alias ca -keystore client.jks -file cert-ca.der
pxgrid store # keytool -genkey -alias clientcert -keyalg RSA -keystore client.jks -
keysize 2048
pxgrid store # keytool -certreq -alias clientcert -keystore client.jks -
file cert-client.csr
pxgrid store # keytool -import -alias clientcert -keystore client.jks -file cert-
client.der
pxgrid store # keytool -list -v -keystore client.jks
pxgrid store # keytool -list -v -keystore root.jks
Cuidado: quando o nó do ISE 1.3 é atualizado, há uma opção para manter o certificado de identidade, mas a assinatura da CA é removida. Como resultado, o ISE atualizado usa um novo certificado, mas nunca anexa o certificado CA na mensagem SSL/ServerHello. Isso dispara a falha no cliente que espera (de acordo com o RFC) ver uma cadeia completa.
A API pxGrid para várias funções (como o download de sessão) executa validação adicional. O cliente entra em contato com o ISE e recebe o nome de host do ISE, que é definido pelo comando hostname na CLI. Em seguida, o cliente tenta executar a resolução DNS para esse nome de host e tenta entrar em contato e buscar dados desse endereço IP. Se a resolução DNS para o nome de host ISE falhar, o cliente não tentará obter nenhum dado.
Cuidado: Observe que somente o nome de host é usado para essa resolução, que é lise neste cenário, não o FQDN (Fully Qualified Domain Name, Nome de domínio totalmente qualificado), que é lise.example.com neste cenário.
A Cisco publica e suporta a API pxGrid. Há um pacote chamado assim:
pxgrid-sdk-1.0.0-167
Dentro dela, há:
Esta é a lista de soluções de segurança que enviam mensagens de syslog com o endereço IP do invasor. Eles podem ser facilmente integrados com o pxLog, desde que você use a regra RegExp correta na configuração.
O Snort envia alertas de syslog neste formato:
host[id] [sig_gen, sig_id, sig_sub] [action] [msg] [proto] [src] [dst]
Aqui está um exemplo:
snort[6310]: [1:100124:0] ALERT {ICMP} 10.221.0.240 -> 10.222.0.61
O endereço IP do invasor é sempre o segundo antes do último (destino). É simples criar um RegExp granular para uma assinatura específica e extrair o endereço IP do invasor. Aqui está um exemplo de RegExp para o 100124 de assinatura e a mensagem Internet Control Message Protocol (ICMP):
snort[\.*:100124:.*ICMP.*
Quando o ASA é configurado para inspeção HTTP (exemplo), a mensagem de syslog correspondente se parece com esta:
Mar 12 2014 14:36:20: %ASA-5-415006: HTTP - matched Class 23:
MS13-025_class in policy-map MS_Mar_2013_policy, URI matched -
Dropping connection from inside:192.168.60.88/2135 to
outside:192.0.2.63/80
Novamente, um RegExp granular pode ser usado para filtrar essas mensagens e extrair o endereço IP do invasor, o segundo antes do último.
Aqui está um exemplo de mensagem enviada pelo sensor da Sourcefire:
Jan 28 19:46:19 IDS01 SFIMS: [CA IDS][Policy1][119:15:1] http_inspect: OVERSIZE
REQUEST-URI DIRECTORY [Classification: Potentially Bad Traffic] [Priority: 2]
{TCP} 10.12.253.47:55504 -> 10.15.224.60:80
Novamente, é simples extrair o endereço IP do invasor porque a mesma lógica se aplica. Além disso, o nome da política e a assinatura são fornecidos, para que a regra pxLog possa ser granular.
Esta é uma mensagem de exemplo enviada pelo Juniper Intrusion Detection & Prevention (IDP) mais antigo:
dayId="20061012" recordId="0" timeRecv="2006/10/12
21:52:21" timeGen="2006/10/12 21:52:21" domain="" devDomVer2="0"
device_ip="10.209.83.4" cat="Predefined" attack="TROJAN:SUBSEVEN:SCAN"
srcZn="NULL" srcIntf="NULL" srcAddr="192.168.170.20" srcPort="63396"
natSrcAddr="NULL" natSrcPort="0" dstZn="NULL" dstIntf="NULL"
dstAddr="192.168.170.10" dstPort="27374" natDstAddr="NULL" natDstPort="0"
protocol="TCP" ruleDomain="" ruleVer="5" policy="Policy2" rulebase="IDS"
ruleNo="4" action="NONE" severity="LOW" alert="no" elaspedTime="0" inbytes="0"
outbytes="0" totBytes="0" inPak="0" outPak="0" totPak="0" repCount="0"
packetData="no" varEnum="31" misc="<017>'interface=eth2" user="NULL"
app="NULL" uri="NULL"
O endereço IP do invasor pode ser extraído da mesma forma.
JunOS é semelhante:
Jul 16 10:09:39 JuniperJunOS: asp[8265]:
ASP_IDS_TCP_SYN_ATTACK: asp 3: proto 6 (TCP),
ge-0/0/1.0 10.60.0.123:2280 -> 192.168.1.12:80, TCP
SYN flood attack
Aqui estão alguns exemplos de iptables Linux.
Jun 15 23:37:33 netfilter kernel: Inbound IN=lo OUT=
MAC=00:13:d3:38:b6:e4:00:01:5c:22:9b:c2:08:00 src=10.0.0.1 DST=10.0.0.100 LEN=60
TOS=0x10 PREC=0x00 TTL=64 ID=47312 DF PROTO=TCP SPT=40945 DPT=3003 WINDOW=32767
RES=0x00 SYN URGP=0
Você pode enviar informações de syslog para qualquer tipo de pacote com a funcionalidade avançada fornecida pelos módulos iptable, como rastreamento de conexão, xtables, rpfilters, correspondência de padrões e assim por diante.
Aqui está uma mensagem de exemplo para fragmentos de bloqueio IPFW:
Sep 7 15:03:14 delta ipfw: 11400 Deny UDP 10.61.216.50 10.81.199.2 in via fxp0
(frag 52639:519@1480)
O ISE é capaz de reconhecer o tipo de sessões em termos de tratamento de CoA.
O módulo EPS é simples. Quando executa uma quarentena, ele sempre envia um pacote de terminação de CoA. Para sessões com/sem fio, não é um problema (todos os solicitantes do 802.1x podem iniciar uma segunda sessão EAP de forma transparente). Mas quando o ASA recebe o término do CoA, ele descarta a sessão VPN e o usuário final recebe:
Há duas soluções possíveis para forçar o AnyConnect VPN a se reconectar automaticamente (configurado no perfil XML):
Mesmo quando a nova sessão é estabelecida, o ASA escolhe o novo ID de sessão de auditoria. Do ponto de vista do ISE, essa é uma nova sessão e não há chance de encontrar a regra de quarentena. Também para as VPNs, não é possível usar o endereço MAC do endpoint como a identidade, ao contrário de dot1x com fio/sem fio.
A solução é forçar o EPS a se comportar como o ISE e enviar o tipo correto de CoA com base na sessão. Essa funcionalidade será apresentada na versão 1.3.1 do ISE.
Esta é uma lista de parceiros e soluções pxGrid:
Aqui estão outros parceiros e soluções:
Consulte o Marketplace Solutions Catalog para obter a lista completa de soluções de segurança.
Há três tipos de API disponíveis no ISE versão 1.3.
Aqui está uma comparação:
REST | RESTful externo | pxGrid | |
---|---|---|---|
Autenticação de cliente | nome de usuário + senha (autenticação HTTP básica) |
nome de usuário + senha (autenticação HTTP básica) |
certificado |
Separação de privilégios | não |
limitado (ERS Admin) |
sim (Grupos) |
Acesso | MnT | MnT | MnT |
Transporte | TCP/443 (HTTPS) | tcp/9060 (HTTPS) | tcp/5222 (XMPP) |
Método de HTTP | GET | GET/POST/PUT | OBTER/POSTAR |
Ativado por padrão | sim | não | não |
Número de operações | poucos | muitos | poucos |
Término do CoA | compatível | não | compatível |
CoA Reauthenticate | compatível | não | compatível* |
Operações do usuário | não | sim | não |
Operações de endpoint | não | sim | não |
Operações de grupo de Identidade de Ponto de Extremidade | não | sim | não |
Quarentena (IP, MAC) | não | não | sim |
Sem quarentena (IP, MAC) | não | não | sim |
PortBounce/Shutdown | não | não | sim |
Operações de usuário convidado | não | sim | não |
Operações do portal de convidados | não | sim | não |
Operações do dispositivo de rede | não | sim | não |
Operações do grupo de dispositivos de rede | não | sim | não |
* A quarentena usa o suporte de CoA unificado do ISE versão 1.3.1.
O pxLog pode ser baixado do Sourceforge .
O SDK (Software Development Kit) já está incluído. Para obter a documentação mais recente de SDK e API para pxGrid, entre em contato com seu parceiro ou com a equipe de conta da Cisco.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
23-Dec-2014 |
Versão inicial |