RFC 3261 SIP: Session Initiation Protocol Junho 2002
Considere um caso em que um terceiro atacante captura algumas mensagens iniciais em um diálogo compartilhado por duas partes a fim de aprender os parâmetros da sessão (tag de To, tag de From e assim por diante) e então, insere uma requisição BYE na sessão. O atacante pode optar por forjar tal requisição que parecia vir de qualquer dos dois participantes. Uma vez que o BYE for recebido por seu alvo, a sessão será derrubada prematuramente.
Similar às ameaças de meio de sessão incluem a transmissão de re-INVITE's forjados que alteram a sessão (possivelmente para reduzir a segurança da sessão ou redirecionar fluxos de mídia, como parte de um ataque de escutas telefônicas).
A contramedida mais eficaz a esta ameaça é a autenticação do remetente do BYE. Nesse exemplo, o destinatário precisa só saber que o BYE veio da mesma parte com quem o diálogo correspondente foi criado (em vez de certificar a identidade absoluta do remetente). Também, se o atacante for incapaz de aprender os parâmetros da sessão devido à confidencialidade, não seria possível forjar o BYE. Contudo, alguns intermediários (como servidores proxy) precisarão inspecionar aqueles parâmetros quando a sessão for estabelecida.
26.1.5 Negação de Serviço e Amplificação
Ataques de Negação de Serviço foca em fazer um elemento de rede particular indisponível, geralmente dirigindo uma quantidade excessiva de tráfego de rede em suas interfaces. Um ataque de negação de serviço distribuído possibilita a um usuário da rede fazer que múltiplos hosts da rede inundem um host alvo com uma grande quantidade de tráfego de rede.
Em muitas arquiteturas, servidores proxy SIP se defrontam com a Internet pública, a fim de aceitar requisições de terminais IP de toda parte do mundo. O SIP cria inúmeras oportunidades potenciais para ataques de negação de serviço distribuídos que precisam ser reconhecidas e tratadas pelos implementadores e operadores de sistemas SIP.
Atacantes podem criar requisições falsas que contêm um endereço IP de origem falsificado e um campo-cabeçalho Via correspondente que identificam um host almejado como o originador da requisição e então envia essa requisição a um grande número de elementos de rede do SIP, e assim usa UA's ou proxy's SIP infelizes para gerar negação de serviço de tráfego apontando para o alvo.
De forma similar, os atacantes podem usar valores falsificados de campo-cabeçalho Route em uma requisição que identificam o host destino e então enviam essas mensagens a proxy's bifurcantes que vão amplificar a geração de mensagens enviadas ao alvo.
Rosenberg, et. al. Standards Track [Página 236]
Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:
User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.
Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:
MUST:
PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO,
NECESSITAR, É MANDATÓRIO.
MUST NOT:
NÃO PODE, É PROIBIDO, É VEDADO.
SHOULD:
DEVE, É RECOMENDADO.
SHOULD NOT:
NÃO DEVE, NÃO É RECOMENDADO.
MAY:
PODE, É OPCIONAL.
Nenhum comentário:
Postar um comentário