DNS Resolver и фильтрация портов запросов

Во время атак с усилением DNS на DNS-сервере я заметил, что некоторые DNS-запросы имеют для пары IP/порт что-то вроде 104.49.96.196:80. Я понимаю, что это поддельный IP-адрес, но можно ли рассмотреть возможность фильтрации порта DNS-запроса? Я считаю, что нам не следует ожидать порт> 1023. Это безопасное предположение? В этом случае я считаю, что это легко обнаружить и не отвечать на атаку с усилением DNS (если пакет достигает DNS-сервера и не отбрасывается WAF).

Нет, это не безопасное предположение.Не пытайтесь фильтровать по портам, полезных последствий это не даст. Как клиент обрабатывает свои локальные порты, это его личное дело, и, следовательно, как сервер вы можете ожидать получения трафика со всех портов. Разделение Unix на 1024 — это архаичное наследие прошлого, которое сегодня практически ничего не значит.

Если вы хотите бороться с усилением DNS, помимо «стандартных» мер (например, убедитесь, что вам действительно нужно обрабатывать весь трафик, который вы получаете, то есть вы не широко открыты), одним из наиболее часто используемых способов в настоящее время является RRL или в основном ограничение скорости.

смотреть на https://www.infoblox.com/dns-security-resource-center/dns-security-solutions/dns-security-solutions-response-rate-limiting-rrl/ для ознакомления с предметом и на https://www.isc.org/docs/DNS-RRL-LISA14.pdf для более технического представления.

DNS-клиенты должны иметь исходный порт> 1023.

Если он < 1024, это должен быть только исходный порт 53, если он исходит от какого-либо другого DNS-сервера, но это маловероятно.

Подтвердить с помощью tcpdump порт 53

Глядя на RFC6056 и упрощение с некоторыми примерами мы могли бы пойти дальше и сказать, что любой хорошо работающий стек IP не должен иметь (иметь) исходный порт ниже 49152 (первый эфемерный порт). Однако раздел 3.2 противоречит этому, как и образцы.

Но пока кто-нибудь не предоставит ссылку на RFC, который переопределяет RFC6056, можно с уверенностью сказать, что спорт <= 1023 недействителен.

Если по какой-либо причине запрос не выполняется, клиент должен повторить попытку и, надеюсь, получить успешный запрос. (Даже если это не удастся, я бы проигнорировал эти реализации)