RFC 3261 SIP: Session Initiation Protocol Junho 2002
Não importa quais soluções de segurança são implantadas, enchentes de mensagens dirigidas aos servidores proxy podem bloquear recursos do servidor proxy e evitar tráfego desejável de alcançar seu destino. Há um custo computacional associado ao processamento de uma transação SIP em um servidor proxy, e esse custo é maior para servidores proxy stateful do que para servidores proxy stateless. Portanto, proxy's stateful são mais suscetíveis a inundações que servidores proxy stateless.
UA's e servidores proxy DEVEM desafiar requisições questionáveis com apenas um único 401 (Unauthorized) ou 407 (Proxy Authentication Required), renunciando o algoritmo de retransmissão de resposta normal, e, assim, comportar-se de forma stateless para as requisições não autenticadas.
Retransmitir a resposta status 401 (Unauthorized) ou 407 (Proxy Authentication Required) amplifica o problema de um atacante usar um valor de campo-cabeçalho falsificado (como o Via) para direcionar o tráfego a uma terceira parte.
Em resumo, a autenticação mútua de servidores proxy por mecanismos como o TLS reduz significativamente o potencial de intermediários desonestos introduzir requisições ou respostas falsificadas que podem negar serviço. Isso torna de forma comensurável mais difícil aos atacantes tornar nó's SIP inocentes em agentes de amplificação.
26.4 Limitações
Embora esses mecanismos de segurança, quando aplicados de forma criteriosa, possam frustrar muitas ameaças, existem limitações no âmbito dos mecanismos que precisam ser compreendidos por implementadores e operadores de rede.
26.4.1 HTTP Digest
Uma das limitações primárias de usar o HTTP Digest no SIP é que os mecanismos de integridade no Digest não funcionam muito bem no SIP. Especificamente, eles oferecem proteção do Request-URI e do método da mensagem, mas não protege nenhum dos campos-cabeçalhos que UA's desejariam muito provavelmente proteger.
Os mecanismos de proteção de repetição existentes descritos na RFC 2617 também possuem algumas limitações para o SIP. O mecanismo next-nonce, por exemplo, não suporta requisições em pipeline. O mecanismo nonce-count deve ser usado para proteção de repetição.
Outra limitação do HTTP Digest é o escopo de realms. O Digest é valioso quando um usuário deseja se autenticar a um recurso com o qual ele tem uma associação pré-existente, como um provedor de serviços
Rosenberg, et. al. Standards Track [Página 247]
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