mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-24 12:03:37 +00:00
116 lines
15 KiB
Markdown
116 lines
15 KiB
Markdown
# Protocolos Básicos de VoIP
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprenda hacking da AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Especialista em Equipe Vermelha AWS do HackTricks)</strong></a><strong>!</strong></summary>
|
|
|
|
Outras formas de apoiar o HackTricks:
|
|
|
|
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
|
|
|
</details>
|
|
|
|
## 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** delineado no RFC 3435. 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 o processo 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 digitais 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 transcoding, packetization 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). Os gateways de sinalização são cruciais para interoperabilidade e garantem que as informações de controle de chamadas sejam comunicadas adequadamente entre as diferentes redes.
|
|
|
|
Em resumo, o MGCP centraliza a lógica de controle de chamadas no agente de chamadas, o que simplifica o gerenciamento de gateways de mídia e sinalização, proporcionando melhor escalabilidade, confiabilidade e eficiência em 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** de propriedade da Cisco Systems. É usado principalmente para comunicação entre o **Cisco Unified Communications Manager** (anteriormente conhecido como CallManager) e telefones IP Cisco ou outros endpoints 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 de endpoint. É chamado de "Magro" por causa de 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, normalmente um Cisco Unified Communications Manager, gerencia o processo de configuração, modificação e término de chamadas, bem como outras funcionalidades de telefonia, como encaminhamento de chamadas, transferência de chamadas e espera de chamadas.
|
|
2. **Endpoints SCCP**: Estes são dispositivos como telefones IP, unidades de videoconferência ou outros endpoints 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 gerenciamento 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 transcoding ou cancelamento de eco.
|
|
|
|
O SCCP oferece um método de comunicação simples e eficiente entre os servidores de controle de chamadas da Cisco e os dispositivos de endpoint. No entanto, vale ressaltar que **o SCCP é um protocolo proprietário**, o que pode limitar a interoperabilidade com sistemas não-Cisco. Em tais 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ências de dados em 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**: Estes são dispositivos de endpoint, 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 interoperabilidade entre H.323 e outros sistemas de comunicação. Eles também podem incluir funcionalidades adicionais, como transcoding ou cancelamento de eco.
|
|
3. **Gatekeepers**: Estes 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)**: Estes dispositivos facilitam conferências multiponto gerenciando e misturando fluxos de mídia de vários endpoints. As MCUs permitem recursos como controle de layout de vídeo, comutação ativada por voz e presença contínua, possibilitando a realização de conferências em grande escala com vários participantes.
|
|
|
|
O H.323 suporta uma variedade de codecs de áudio e vídeo, bem como outros serviços suplementares como encaminhamento 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 sendo 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 de PBX de código aberto Asterisk, como uma alternativa a outros protocolos VoIP como SIP e H.323.
|
|
|
|
O IAX é conhecido por sua **simplicidade, eficiência e facilidade de implementação**. Algumas características-chave do IAX incluem:
|
|
|
|
1. **Porta UDP Única**: O IAX usa uma única porta UDP (4569) para o tráfego de sinalização e 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 o consumo de largura de banda e o torna mais eficiente para transmitir dados de sinalização e mídia.
|
|
3. **Troncos**: O IAX suporta troncos, o que permite combinar várias chamadas em uma única conexão de rede, reduzindo a sobrecarga e melhorando a utilização da largura de banda.
|
|
4. **Criptografia Nativa**: O IAX possui suporte integrado para criptografia, usando métodos como RSA para troca de chaves e AES para criptografia de mídia, proporcionando comunicação segura entre os pontos finais.
|
|
5. **Comunicação Ponto a Ponto**: O IAX pode ser usado para comunicação direta entre pontos finais sem a necessidade de um servidor central, permitindo 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 uma adoção menos difundida 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ências de dados, em redes IP. Foi desenvolvido pelo **Internet Engineering Task Force (IETF)** e é definido no **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 suas 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 de mídia (por exemplo, informações de 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. Os atributos podem ser usados para especificar várias funcionalidades 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 para a 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 para a parte iniciadora como parte da mensagem de protocolo de sinalização, completando o processo de negociação.
|
|
|
|
A simplicidade e flexibilidade do SDP o tornam 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 em redes IP.
|
|
|
|
### RTP / RTCP / SRTP / ZRTP
|
|
|
|
1. **RTP (Protocolo de Transporte em Tempo Real)**: RTP é um protocolo de rede projetado para a entrega de dados de áudio e vídeo, ou outras mídias em tempo real, em redes IP. Desenvolvido pelo **IETF** e definido no **RFC 3550**, o RTP é comumente usado com protocolos de sinalização como SIP e H.323 para habilitar a comunicação multimídia. O RTP fornece mecanismos de **sincronização**, **sequenciamento** e **timestamping** de fluxos de mídia, ajudando a garantir a reprodução suave e oportuna da mídia.
|
|
2. **RTCP (Protocolo de Controle de Transporte em Tempo Real)**: O RTCP é um protocolo complementar ao RTP, usado para monitorar a qualidade de serviço (QoS) e fornecer feedback sobre a transmissão de fluxos de mídia. Definido no mesmo **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 Seguro em Tempo Real)**: O SRTP é uma extensão do RTP que fornece **criptografia**, **autenticação de mensagem** 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 no **RFC 3711**, o SRTP usa algoritmos criptográficos como AES para criptografia e HMAC-SHA1 para autenticação de mensagem. 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 de Zimmermann)**: O ZRTP é um protocolo de acordo de chaves criptográficas que fornece **criptografia de ponta a ponta** para fluxos de mídia RTP. Desenvolvido por Phil Zimmermann, o criador do PGP, o ZRTP é descrito no **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 proteção contra ataques de intermediários.
|
|
|
|
Esses protocolos desempenham papéis essenciais na **entrega e segurança da comunicação multimídia em tempo real em redes IP**. Enquanto o RTP e o RTCP lidam com a transmissão real de mídia e monitoramento de qualidade, o SRTP e o ZRTP garantem que a mídia transmitida esteja protegida contra escuta, manipulação e ataques de repetição.
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprenda hacking da AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Especialista em Equipe Vermelha AWS do HackTricks)</strong></a><strong>!</strong></summary>
|
|
|
|
Outras formas de apoiar o HackTricks:
|
|
|
|
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Adquira o [**swag oficial PEASS & HackTricks**](https
|