RFC 3261 SIP: Session Initiation Protocol Junho 2002
Record-Route poderia ser usado para efeito similar quando o atacante está certo que o diálogo SIP iniciado pela requisição resultará em numerosas operações se originando na direção contrária.
Inúmeros ataques de negação de serviço iniciam se requisições REGISTER não são devidamente autenticadas e autorizadas pelos registradores. Atacantes poderiam desregistrar alguns ou todos os usuários em um domínio administrativo, evitando assim esses usuários de serem convidados para novas sessões. Um atacante poderia também registrar um grande número de contatos que designa o mesmo host para certo endereço de registro a fim de usar o registrador e todos os servidores proxy associados como amplificadores em um ataque de negação de serviço. Atacantes pode também tentar esgotar os recursos disponíveis de memória e disco de um registrador, registrando um grande número de bindings.
O uso de multicast para transmitir requisições do SIP pode aumentar significativamente os ataques potenciais de negação de serviço.
Esses problemas demonstram uma necessidade geral para definir arquiteturas que minimizem os riscos de ataques de negação de serviço, e a necessidade de estar atento as recomendações sobre mecanismos de segurança dessa classe de ataques.
26.2 Mecanismos de Segurança
Das ameaças descritas acima, nós compreendemos que os serviços fundamentais de segurança exigidos pelo protocolo SIP são: preservar a confidencialidade e integridade de trocas de mensagens, impedir ataques de repetição ou spoofing de mensagens, fornecer autenticação e privacidade dos participantes em uma sessão, e prevenir ataques de negação de serviço. Corpos dentro de mensagens do SIP separadamente necessitam dos serviços de segurança de confidencialidade, autenticação e integridade.
Ao invés de definir novos mecanismos de segurança específicos ao SIP, o SIP reusa sempre que possível, os modelos de segurança existentes derivado do espaço HTTP e do SMTP.
Criptografia completa de mensagens fornece os melhores meios para preservar a confidencialidade de sinalização - ela também pode garantir que mensagens não sejam modificadas por qualquer intermediário malicioso. Contudo, as requisições SIP e as respostas não podem ser ingenuamente criptografadas de fim-a-fim em sua totalidade porque os campos de mensagem como Request-URI, Route e Via precisam ser visíveis aos proxys em muitas arquiteturas de rede, de modo que requisições SIP sejam roteadas corretamente. Note que servidores proxy precisam modificar algumas características de mensagens também (como adicionar valores de campo-cabeçalho Via), para que o SIP funcione. Servidores proxy precisam portanto ser confiáveis, até certo ponto, por UAs SIP. Para esse propósito, mecanismos de segurança de camada baixa ao SIP são recomendados, que
Rosenberg, et. al. Standards Track [Página 237]
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