Secure Conference Bridge

Nossa, agora me dei conta de como faz tempo que não escrevo aqui no blog! Desse jeito, como é que vou querer vender ele pra Cisco algum dia? hahaha! Enfim, escreverei hoje sobre um tema que me custou muito para fazer funcionar, simplesmente porque é extremamente difícil de encontrar boas referências sobre essa configuração na Internet: Conference Bridge com criptografia (usando a infraestrutura de certificados do cliente).

É um tema bastante similar ao que escrevi outro dia sobre SIP Trunk over TLS, só que criaremos outras chaves, outro trustpoint, etc. E novamente, reforçarei o que escrevi nesse post sobre Secure SIP: Isso definitivamente não é a minha área de especialidade, então certamente tem coisa que pode estar errada. O que mostro abaixo é como eu fiz e deu certo.

1. Crie um par de chaves (pública e privada) no Voice Gateway, dando um nome qualquer (diferente do nome que foi dado às chaves do Secure SIP). Sugiro o nome da própria Conference Bridge:

crypto key generate rsa general-keys label CFB_Teste_01 mod 2048 exportable

2. Crie um Trustpoint no Voice Gateway, e nomeie ele com o mesmo nome da Conference Bridge:

crypto pki trustpoint CFB_Teste_01
 enrollment terminal
 fqdn none
 subject-name CN=CFB_Teste_01  ! -- Aqui está o segredo. O CN do certificado deve conter o nome da Conference Bridge
 revocation-check none
 rsakeypair CFB_Teste_01

3. Autentique o trustpoint, incluindo certificado Root

crypto pki authenticate CFB_Teste_01

Ao dar o comando, o roteador vai pedir para você colar o certificado root. Esse certificado você deve pedir ao cliente:

Enter the base 64 encoded CA certificate
<COLE A STRING CONTENDO O CERTIFICADO ROOT>

4. Gere o CSR (Certificate Sign Request) do roteador para ser assinado pelo cliente:

crypto pki enroll CFB_Teste_01
%Start certificate enrolment ..
Include serial? No
Include IP Address? No
Display CSR? Yes

O roteador vai gerar uma string no terminal. Você deve copiar toda ela num TXT e encaminhar para o cliente assinar no CA dele. Caso seja um Windows, o template deve conter as funções TLS Web Server Authentication, TLS Web Client Authentication e IPSec End System.


5. Quando o cliente enviar o certificado assinado pelo CA dele, importe de volta para o Roteador:

crypto pki import CFB_Teste_01 certificate
Enter the base 64 encoded certificate
<COLE A STRING CONTENDO O CERTIFICADO ASSINADO>

6. Importe os certificados Root no CUCM como CallManager-trust, e assine os certificados do CUCM no CA do cliente. O passo-a-passo desse procedimento está detalhado no post sobre Secure SIP.

7. Crie uma nova Conference Bridge no roteador, como de costume, porém, seguindo os comando abaixo:

sccp local GigabitEthernet0/0
sccp ccm <CUCM1> identifier 1 version 7.0 trustpoint CFB_Teste_01
sccp ccm <CUCM2> identifier 2 version 7.0 trustpoint CFB_Teste_01
sccp ip precedence 3
sccp

sccp ccm group 1
 bind interface GigabitEthernet0/0
 associate ccm 2 priority 1
 associate ccm 1 priority 2
 associate profile 1 register CFB_Teste_01

dspfarm profile 1 conference security
 trustpoint CFB_Teste_01
 codec g729br8
 codec g729r8
 codec g729abr8
 codec g729ar8
 codec g711alaw
 codec g711ulaw
 maximum sessions 2
 associate application SCCP

8. Ao criar a CFB no Call Manager, marque a opção "Encrypted Conference Bridge".

Pronto, a sua Conference Bridge já está encriptada!

Criptografando o seu SIP Trunk com TLS

Fala pessoal!!!
Primeiramente, gostaria de desejar um feliz 2014!!

Faz bastante tempo que eu num faço um post no blog que não seja relatos de pessoas que passaram na prova. Confesso que é uma forma bastante prática de manter o blog atualizado! hahaha... só que num é só disso que pode viver o blog, né? Por outro lado, o blueprint atual está quase no fim, e não tenho o intuito de ficar me atualizando no blueprint novo para postar coisas relativas à próxima prova (a não ser que eu capitalize o blog e comece a ganhar dinheiro com isso! hahaha).

Portanto, hoje farei um post sobre um assunto que num tem nada a ver com a prova (pelo menos não a atual), mas que eu achei extremamente difícil achar referências boas na Internet quando precisei fazer. É sobre a configuração de um voice gateway SIP criptografado (TLS), usando certificados da estrutura do cliente. O que tem bastante na internet é sobre como fazer usando certificados self-signed do CUCM e Gateway, mas convenhamos que num deployment real, dificilmente isso vai acontecer. Geralmente o cliente tem toda uma estrutura de certificados da empresa para os seus serviços, e pede que a gente utilize essa estrutura.

Ok, serei sincero. Isso definitivamente não é a minha área de especialidade, então certamente tem coisa que pode estar errada. O que mostro abaixo é como eu fiz e deu certo.

Importando os certificados no Roteador

1. Crie um par de chaves (pública e privada) no Voice Gateway, dando um nome qualquer. Sugiro nomear com o próprio Hostname do roteador:

crypto key generate rsa general-keys label <HOSTNAME> mod 2048 exportable

2. Crie um Trustpoint no Voice Gateway, e nomeie ele com o Hostname:

crypto pki trustpoint <HOSTNAME>
 enrollment terminal
 fqdn HOSTNAME.domain.example.com ! - hostname e domínio
 subject-name CN=HOSTNAME.domain.example.com
 revocation-check none
 rsakeypair <HOSTNAME> ! - referencia às chaves criadas  no passo 1

3. Autentique o trustpoint, incluindo certificado Root

crypto pki authenticate <HOSTNAME>

Ao dar o comando, o roteador vai pedir para você colar o certificado root. Esse certificado você deve pedir ao cliente:

Enter the base 64 encoded CA certificate
<COLE A STRING CONTENDO O CERTIFICADO ROOT>

4. Gere o CSR (Certificate Sign Request) do roteador para ser assinado pelo cliente:

crypto pki enroll <HOSTNAME>
%Start certificate enrolment ..
Include serial? No
Include IP Address? No
Display CSR? Yes

O roteador vai gerar uma string, que você deve copiar toda ela num TXT e encaminhar para o cliente assinar no CA dele. Caso seja um Windows, o template deve conter as funções TLS Web Server Authentication, TLS Web Client Authentication e IPSec End System.


5. Quando o cliente enviar o certificado assinado pelo CA dele, importe de volta para o Roteador:

crypto pki import <HOSTNAME> certificate
Enter the base 64 encoded certificate
<COLE A STRING CONTENDO O CERTIFICADO ASSINADO>

Agora vamos fazer a parte dos certificados do CUCM.

Importando os certificados no CUCM

1. No CUCM, entre no OS Administrator. Vá em Security >> Certificate Management

2. Clique em Upload Certificate, e faça upload do Certificado Root para CallManager-trust e tomcat-trust.

3. Clique em Generate CSR e gere os CSRs do CallManager e tomcat.

4. Clique em Download CSR para baixar os arquivos

5. Envie para o cliente assinar no CA dele. Caso seja um Windows, o template deve conter as funções TLS Web Server Authentication, TLS Web Client Authentication e IPSec End System.

6. Quando o cliente mandar os certificados assinados, importe novamente como CallManager e tomcat (sem o trust).

7. Faça isso em todos os servidores do cluster, e depois reinicie tudo.

Configurando o SIP Trunk no CUCM

1. Crie um SIP Trunk Security Profile, marcando a opção Encrypted, com transport type TLS. No X.509 Subject Name, coloque o Hostname e Domain name do roteador, como no exemplo abaixo

2. Crie um SIP Trunk como o usual, mas marque a opção SRTP Allowed, aplique o Security Profile criado acima, e utilize a porta 5061 como Destination Port. Como Device Name do trunk, utilize o Hostname do roteador.

Configurando o SIP Trunk no Gateway

1. Crie a dial-peer voip normalmente, porém com os dois comandos destacados abaixo:

dial-peer voice X voip
 destination-pattern <XXXX>
 session protocol sipv2
 session target ipv4:x.x.x.x:5061
 session transport tcp tls
 srtp fallback
 (...)

2. Configure o SIP-TLS:

sip-ua
 crypto signalling remote-addr <CUCM-Pub> 255.255.255.255 trustpoint <HOSTNAME> strict-cipher
 crypto signalling remote-addr <CUCM-Sub> 255.255.255.255 trustpoint <HOSTNAME> strict-cipher

E pronto!

Troubleshooting

Esses debugs são muito úteis para fazer o troubleshooting do TLS

debug ssl openssl errors
debug ssl openssl msg
debug ssl openssl state
show sip-ua connection tcp tls detail

Cluster em Mixed Mode

Já que o assunto da moda é a espionagem digital que os EUA andaram fazendo e tal, tive a ideia de começar a fazer uns posts sobre segurança. Até onde eu sei, não faz parte do blueprint atual do CCIE Voice, mas certamente é um conhecimento importante para qualquer profissional da área no dia-a-dia de projetos.

No primeiro post da série, vou mostrar como deixar o cluster em Mixed Mode, ou seja, habilitar a criptografia da sinalização e áudio nos telefones. É bem fácil de fazer, mas existe um pré-requisito, que é adquirir pelo menos dois tokens de segurança (part number KEY-CCM-ADMIN-K9=). Tendo isso, o resto é muito fácil. Vamos lá!

1. Primeiramente, você deve habilitar os serviços de CTL Provider e Certificate Authority Proxy Function (CAPF) no CUCM.

2. Feito isso, baixe do CUCM e instale no seu notebook o CTL Client. O caminho para baixar o plugin é indo em Applications >> Plugins. O notebook deve estar na rede para executar o programa, com o CUCM acessível.

3. Ao executar o CTL Client, insira o IP do Publisher, login e senha

4. Após a autenticação, a seguinte tela aparecerá. Escolha a opção "Set Cisco Unified CallManager Cluster to Mixed Mode"

5. O aplicativo pedirá para você inserir um Security Token. Faça isso e pressione OK. (obs: Insira apenas 1 dos tokens!)

6. As informações do Token serão exibidas. Pressione Add.

7. O programa vai coletar todos os certificados (CAPF, CCM e TFTP) dos servidores do cluster e exibir na tela, juntamente com o próprio Token, mostrando os certificados do CTL. Removi as informações do cliente no print screen abaixo:

8. Clique em Add Tokens para adicionar o seu segundo Token no CTL. O programa o alertará para remover o primeiro token antes de inserir o segundo:

9. As informações do segundo Token serão exibidas. Clique Add.

10. E o segundo token será adicionado ao CTL. Clique em Finish.

11. O programa vai pedir agora a senha do eToken. Você tem apenas 15 tentativas, e depois disso o Token é inutilizado. A senha default é Cisco123.

12. Com isso, a chave privada do eToken será utilizada para assinar o arquivo CTL, que será "upado" para cada servidor do cluster.

13. Reinicie os serviços de CallManager e TFTP (ou dê logo um boot no servidor, afinal, um bootzinho sempre vai bem, né! hehe)

14. Agora o seu cluster já está em Mixed Mode! Para habilitar a criptografia em um telefone, você deve criar um Security Profile (System >> Security >> Phone Security Profile), como abaixo, habilitando a criptografia:

15. Aplicar o profile no telefone, e configurar as opções de CAPF nele. Para os telefones novos, que já vem de fábrica com um certificado MIC, você pode usar a o método "Por certificado existente (prioridade para MIC)". Caso seja um telefone antigo, modelo 7940, 7960, você tem que usar o "By Authentication String", e aí é muito mais trabalhoso, pois você tem que ir telefone por telefone e digitar uma senha para ele poder baixar os certificados. Ou seja, para deployments grandes, é inviável! No exemplo, estou considerando um dos telefones de modelo mais recente.

16. Após o reset do telefone, você verá que o Certificate Operation Status está como Upgrade Sucess:

17. Agora se você fizer uma chamada com esse telefone, ele mostrará um desenho de cadeado na tela, indicando que a chamada está sendo criptografada.

18. Uma observação. Quando você deixa o Cluster em Mixed Mode, o Auto-Registration deixa de funcionar!

Esse foi um post super simples. Tem diversas referências na Internet mostrando como se faz isso, e os guias da Cisco também são bem explicativos. Nos próximos posts da série de segurança, abordarei outros temas como SIP over TLS, Secure Conference Bridges, VG224, utilizando um Certificate Authority da empresa (e não os Self Signed do Call Manager). Esses são temas que eu pelo menos não encontrei nada muito explicativo na Internet. Até a próxima!