Durante ataques de amplificação de DNS em um servidor DNS, observei que algumas solicitações de DNS têm para alguns IP/portas algo como 104.49.96.196:80. Entendo que este é um IP falsificado, mas posso considerar filtrar a porta da solicitação DNS? Acredito que não devemos esperar uma porta > 1023. É uma suposição segura? Nesse caso, acredito que seja uma vitória fácil de detectar e não responder ao ataque de amplificação de DNS (se o pacote chegar ao servidor DNS e não for descartado pelo WAF).
Responder1
Não, não é uma suposição segura. Não tente filtrar nas portas, isso não trará consequências úteis. O modo como um cliente lida com suas portas locais é da sua conta e, portanto, como servidor, você pode esperar obter tráfego de todas as portas. A divisão do Unix em 1024 é um legado arcaico do passado que basicamente não significa mais nada hoje.
Se você quer combater a amplificação de DNS, além de medidas "padrão" (como ter certeza de que você realmente precisa lidar com todo o tráfego que você recebe, ou seja, você não está totalmente aberto), uma das formas mais utilizadas hoje em dia é RRL ou basicamente limitação de taxa.
Olhe parahttps://www.infoblox.com/dns-security-resource-center/dns-security-solutions/dns-security-solutions-response-rate-limiting-rrl/para uma introdução sobre o assunto e emhttps://www.isc.org/docs/DNS-RRL-LISA14.pdfpara uma apresentação mais técnica.
Responder2
Os clientes DNS devem ter porta de origem > 1023.
Se for <1024, só deverá ser a porta de origem 53 se vier de algum outro servidor DNS - mas isso é improvável.
Verifique comtcpdump port 53
Ao olhar paraRFC6056esimplificação com algumas amostraspoderíamos ir além e dizer que qualquer pilha IP com bom comportamento não deveria ter (tinha) uma porta de origem inferior a 49152 (primeira porta efêmera). No entanto, a secção 3.2 contradiz isto, e o mesmo acontece com as amostras.
Mas até que alguém possa fornecer uma referência à RFC que redefina a RFC6056, é seguro dizer que esporte <= 1023 não é válido.
Se, por algum motivo, uma solicitação falhar, o cliente deverá tentar novamente e, esperançosamente, obter uma solicitação bem-sucedida. (Mesmo que isso falhasse, eu ignoraria essas implementações)