mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-29 22:43:11 +00:00
126 lines
16 KiB
Markdown
126 lines
16 KiB
Markdown
# Protocolos Básicos de VoIP
|
|
|
|
{% hint style="success" %}
|
|
Aprenda e pratique Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Aprenda e pratique Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
|
|
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
{% endhint %}
|
|
|
|
## Protocolos de Sinalização
|
|
|
|
### SIP (Protocolo de Iniciação de Sessão)
|
|
|
|
Este é o padrão da indústria, para mais informações consulte:
|
|
|
|
{% content-ref url="sip-session-initiation-protocol.md" %}
|
|
[sip-session-initiation-protocol.md](sip-session-initiation-protocol.md)
|
|
{% endcontent-ref %}
|
|
|
|
### MGCP (Protocolo de Controle de Gateway de Mídia)
|
|
|
|
MGCP (Protocolo de Controle de Gateway de Mídia) é um **protocolo de sinalização** e **controle de chamadas** descrito na RFC 3435. Ele opera em uma arquitetura centralizada, que consiste em três componentes principais:
|
|
|
|
1. **Agente de Chamadas ou Controlador de Gateway de Mídia (MGC)**: O gateway mestre na arquitetura MGCP é responsável por **gerenciar e controlar os gateways de mídia**. Ele lida com os processos de configuração, modificação e término de chamadas. O MGC se comunica com os gateways de mídia usando o protocolo MGCP.
|
|
2. **Gateways de Mídia (MGs) ou Gateways Escravos**: Esses dispositivos **convertem fluxos de mídia digital entre diferentes redes**, como telefonia tradicional comutada por circuitos e redes IP comutadas por pacotes. Eles são gerenciados pelo MGC e executam comandos recebidos dele. Os gateways de mídia podem incluir funções como transcodificação, empacotamento e cancelamento de eco.
|
|
3. **Gateways de Sinalização (SGs)**: Esses gateways são responsáveis por **converter mensagens de sinalização entre diferentes redes**, permitindo comunicação contínua entre sistemas de telefonia tradicionais (por exemplo, SS7) e redes baseadas em IP (por exemplo, SIP ou H.323). Gateways de sinalização são cruciais para a interoperabilidade e garantem que as informações de controle de chamadas sejam comunicadas corretamente entre as diferentes redes.
|
|
|
|
Em resumo, o MGCP centraliza a lógica de controle de chamadas no agente de chamadas, o que simplifica a gestão de gateways de mídia e sinalização, proporcionando melhor escalabilidade, confiabilidade e eficiência nas redes de telecomunicações.
|
|
|
|
### SCCP (Protocolo de Controle de Cliente Magro)
|
|
|
|
O Protocolo de Controle de Cliente Magro (SCCP) é um **protocolo de sinalização e controle de chamadas proprietário** da Cisco Systems. É utilizado principalmente para comunicação entre o **Cisco Unified Communications Manager** (anteriormente conhecido como CallManager) e telefones IP Cisco ou outros terminais de voz e vídeo da Cisco.
|
|
|
|
O SCCP é um protocolo leve que simplifica a comunicação entre o servidor de controle de chamadas e os dispositivos finais. É chamado de "Magro" devido ao seu design minimalista e requisitos de largura de banda reduzidos em comparação com outros protocolos VoIP como H.323 ou SIP.
|
|
|
|
Os principais componentes de um sistema baseado em SCCP são:
|
|
|
|
1. **Servidor de Controle de Chamadas**: Este servidor, tipicamente um Cisco Unified Communications Manager, gerencia os processos de configuração, modificação e término de chamadas, bem como outros recursos de telefonia, como desvio de chamadas, transferência de chamadas e espera de chamadas.
|
|
2. **Endpoints SCCP**: Esses são dispositivos como telefones IP, unidades de videoconferência ou outros terminais de voz e vídeo da Cisco que usam SCCP para se comunicar com o servidor de controle de chamadas. Eles se registram no servidor, enviam e recebem mensagens de sinalização e seguem as instruções fornecidas pelo servidor de controle de chamadas para o manuseio de chamadas.
|
|
3. **Gateways**: Esses dispositivos, como gateways de voz ou gateways de mídia, são responsáveis por converter fluxos de mídia entre diferentes redes, como telefonia tradicional comutada por circuitos e redes IP comutadas por pacotes. Eles também podem incluir funcionalidades adicionais, como transcodificação ou cancelamento de eco.
|
|
|
|
O SCCP oferece um método de comunicação simples e eficiente entre servidores de controle de chamadas Cisco e dispositivos finais. No entanto, vale a pena notar que **o SCCP é um protocolo proprietário**, o que pode limitar a interoperabilidade com sistemas não Cisco. Nesses casos, outros protocolos VoIP padrão como SIP podem ser mais adequados.
|
|
|
|
### H.323
|
|
|
|
H.323 é um **conjunto de protocolos** para comunicação multimídia, incluindo voz, vídeo e conferência de dados sobre redes comutadas por pacotes, como redes baseadas em IP. Foi desenvolvido pela **União Internacional de Telecomunicações** (ITU-T) e fornece uma estrutura abrangente para gerenciar sessões de comunicação multimídia.
|
|
|
|
Alguns componentes-chave do conjunto H.323 incluem:
|
|
|
|
1. **Terminais**: Esses são dispositivos finais, como telefones IP, sistemas de videoconferência ou aplicativos de software, que suportam H.323 e podem participar de sessões de comunicação multimídia.
|
|
2. **Gateways**: Esses dispositivos convertem fluxos de mídia entre diferentes redes, como telefonia tradicional comutada por circuitos e redes IP comutadas por pacotes, permitindo a interoperabilidade entre H.323 e outros sistemas de comunicação. Eles também podem incluir funcionalidades adicionais, como transcodificação ou cancelamento de eco.
|
|
3. **Gatekeepers**: Esses são componentes opcionais que fornecem serviços de controle e gerenciamento de chamadas em uma rede H.323. Eles realizam funções como tradução de endereços, gerenciamento de largura de banda e controle de admissão, ajudando a gerenciar e otimizar os recursos da rede.
|
|
4. **Unidades de Controle Multiponto (MCUs)**: Esses dispositivos facilitam conferências multiponto gerenciando e misturando fluxos de mídia de múltiplos terminais. As MCUs permitem recursos como controle de layout de vídeo, comutação ativada por voz e presença contínua, tornando possível hospedar conferências em grande escala com múltiplos participantes.
|
|
|
|
H.323 suporta uma variedade de codecs de áudio e vídeo, bem como outros serviços suplementares como desvio de chamadas, transferência de chamadas, espera de chamadas e chamada em espera. Apesar de sua ampla adoção nos primeiros dias do VoIP, o H.323 foi gradualmente substituído por protocolos mais modernos e flexíveis como o **Protocolo de Iniciação de Sessão (SIP)**, que oferece melhor interoperabilidade e implementação mais fácil. No entanto, o H.323 continua em uso em muitos sistemas legados e continua a ser suportado por vários fornecedores de equipamentos.
|
|
|
|
### IAX (Inter Asterisk eXchange)
|
|
|
|
IAX (Inter-Asterisk eXchange) é um **protocolo de sinalização e controle de chamadas** usado principalmente para comunicação entre servidores Asterisk PBX (Private Branch Exchange) e outros dispositivos VoIP. Foi desenvolvido por Mark Spencer, o criador do software PBX de código aberto Asterisk, como uma alternativa a outros protocolos VoIP como SIP e H.323.
|
|
|
|
IAX é conhecido por sua **simplicidade, eficiência e facilidade de implementação**. Alguns recursos principais do IAX incluem:
|
|
|
|
1. **Porta UDP Única**: O IAX usa uma única porta UDP (4569) para sinalização e tráfego de mídia, o que simplifica a travessia de firewall e NAT, facilitando a implantação em vários ambientes de rede.
|
|
2. **Protocolo Binário**: Ao contrário de protocolos baseados em texto como SIP, o IAX é um protocolo binário, o que reduz seu consumo de largura de banda e o torna mais eficiente para transmitir dados de sinalização e mídia.
|
|
3. **Tronco**: O IAX suporta tronco, que permite que várias chamadas sejam combinadas em uma única conexão de rede, reduzindo a sobrecarga e melhorando a utilização da largura de banda.
|
|
4. **Criptografia Nativa**: O IAX tem suporte embutido para criptografia, usando métodos como RSA para troca de chaves e AES para criptografia de mídia, proporcionando comunicação segura entre os terminais.
|
|
5. **Comunicação Ponto a Ponto**: O IAX pode ser usado para comunicação direta entre terminais sem a necessidade de um servidor central, permitindo um roteamento de chamadas mais simples e eficiente.
|
|
|
|
Apesar de seus benefícios, o IAX tem algumas limitações, como seu foco principal no ecossistema Asterisk e menor adoção em comparação com protocolos mais estabelecidos como SIP. Como resultado, o IAX pode não ser a melhor escolha para interoperabilidade com sistemas ou dispositivos não Asterisk. No entanto, para aqueles que trabalham dentro do ambiente Asterisk, o IAX oferece uma solução robusta e eficiente para comunicação VoIP.
|
|
|
|
## Protocolos de Transmissão e Transporte
|
|
|
|
### SDP (Protocolo de Descrição de Sessão)
|
|
|
|
SDP (Protocolo de Descrição de Sessão) é um **formato baseado em texto** usado para descrever as características de sessões multimídia, como voz, vídeo ou conferência de dados, sobre redes IP. Foi desenvolvido pela **Força-Tarefa de Engenharia da Internet (IETF)** e é definido na **RFC 4566**. O SDP não lida com a transmissão real de mídia ou estabelecimento de sessão, mas é usado em conjunto com outros protocolos de sinalização, como **SIP (Protocolo de Iniciação de Sessão)**, para negociar e trocar informações sobre os fluxos de mídia e seus atributos.
|
|
|
|
Alguns elementos-chave do SDP incluem:
|
|
|
|
1. **Informações da Sessão**: O SDP descreve os detalhes de uma sessão multimídia, incluindo nome da sessão, descrição da sessão, hora de início e hora de término.
|
|
2. **Fluxos de Mídia**: O SDP define as características dos fluxos de mídia, como o tipo de mídia (áudio, vídeo ou texto), protocolo de transporte (por exemplo, RTP ou SRTP) e o formato da mídia (por exemplo, informações do codec).
|
|
3. **Informações de Conexão**: O SDP fornece informações sobre o endereço de rede (endereço IP) e número da porta onde a mídia deve ser enviada ou recebida.
|
|
4. **Atributos**: O SDP suporta o uso de atributos para fornecer informações adicionais e opcionais sobre uma sessão ou fluxo de mídia. Atributos podem ser usados para especificar vários recursos como chaves de criptografia, requisitos de largura de banda ou mecanismos de controle de mídia.
|
|
|
|
O SDP é tipicamente usado no seguinte processo:
|
|
|
|
1. Uma parte iniciadora cria uma descrição SDP da sessão multimídia proposta, incluindo os detalhes dos fluxos de mídia e seus atributos.
|
|
2. A descrição SDP é enviada à parte receptora, geralmente incorporada em uma mensagem de protocolo de sinalização como SIP ou RTSP.
|
|
3. A parte receptora processa a descrição SDP e, com base em suas capacidades, pode aceitar, rejeitar ou modificar a sessão proposta.
|
|
4. A descrição SDP final é enviada de volta à parte iniciadora como parte da mensagem do protocolo de sinalização, completando o processo de negociação.
|
|
|
|
A simplicidade e flexibilidade do SDP fazem dele um padrão amplamente adotado para descrever sessões multimídia em vários sistemas de comunicação, desempenhando um papel crucial no estabelecimento e gerenciamento de sessões multimídia em tempo real sobre redes IP.
|
|
|
|
### RTP / RTCP / SRTP / ZRTP
|
|
|
|
1. **RTP (Protocolo de Transporte em Tempo Real)**: O RTP é um protocolo de rede projetado para a entrega de dados de áudio e vídeo, ou outros meios em tempo real, sobre redes IP. Desenvolvido pela **IETF** e definido na **RFC 3550**, o RTP é comumente usado com protocolos de sinalização como SIP e H.323 para habilitar comunicação multimídia. O RTP fornece mecanismos para **sincronização**, **sequenciamento** e **marcação de tempo** dos fluxos de mídia, ajudando a garantir uma reprodução de mídia suave e pontual.
|
|
2. **RTCP (Protocolo de Controle de Transporte em Tempo Real)**: O RTCP é um protocolo acompanhante do RTP, usado para monitorar a qualidade do serviço (QoS) e fornecer feedback sobre a transmissão de fluxos de mídia. Definido na mesma **RFC 3550** que o RTP, o RTCP **troca periodicamente pacotes de controle entre os participantes em uma sessão RTP**. Ele compartilha informações como perda de pacotes, jitter e tempo de ida e volta, o que ajuda a diagnosticar e se adaptar às condições da rede, melhorando a qualidade geral da mídia.
|
|
3. **SRTP (Protocolo de Transporte em Tempo Real Seguro)**: O SRTP é uma extensão do RTP que fornece **criptografia**, **autenticação de mensagens** e **proteção contra repetição** para fluxos de mídia, garantindo a transmissão segura de dados de áudio e vídeo sensíveis. Definido na **RFC 3711**, o SRTP usa algoritmos criptográficos como AES para criptografia e HMAC-SHA1 para autenticação de mensagens. O SRTP é frequentemente usado em combinação com protocolos de sinalização seguros como SIP sobre TLS para fornecer segurança de ponta a ponta na comunicação multimídia.
|
|
4. **ZRTP (Protocolo de Transporte em Tempo Real Zimmermann)**: O ZRTP é um protocolo de acordo de chave criptográfica que fornece **criptografia de ponta a ponta** para fluxos de mídia RTP. Desenvolvido por Phil Zimmermann, o criador do PGP, o ZRTP é descrito na **RFC 6189**. Ao contrário do SRTP, que depende de protocolos de sinalização para troca de chaves, o ZRTP é projetado para funcionar independentemente do protocolo de sinalização. Ele usa **troca de chaves Diffie-Hellman** para estabelecer um segredo compartilhado entre as partes comunicantes, sem exigir confiança prévia ou uma infraestrutura de chave pública (PKI). O ZRTP também inclui recursos como **Strings de Autenticação Curtas (SAS)** para proteger contra ataques de homem no meio.
|
|
|
|
Esses protocolos desempenham papéis essenciais na **entrega e segurança da comunicação multimídia em tempo real sobre redes IP**. Enquanto RTP e RTCP lidam com a transmissão real de mídia e monitoramento de qualidade, SRTP e ZRTP garantem que a mídia transmitida esteja protegida contra escuta, adulteração e ataques de repetição.
|
|
|
|
{% hint style="success" %}
|
|
Aprenda e pratique Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Aprenda e pratique Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
|
|
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
</details>
|
|
{% endhint %}
|