Во время атак DNS amplification на DNS-сервер я заметил, что некоторые DNS-запросы имеют для пары IP/порт что-то вроде 104.49.96.196:80
. Я понимаю, что это поддельный IP, но можно ли рассмотреть возможность фильтрации порта DNS-запроса? Я считаю, что мы не должны ожидать порт > 1023. Является ли это безопасным предположением? В этом случае я считаю, что это легкая победа, которую можно обнаружить и не отвечать на атаку DNS amplification (если пакет достигнет DNS-сервера и не будет отброшен WAF).
решение1
Нет, это небезопасное предположение. Не пытайтесь фильтровать по портам, это не даст полезных последствий. То, как клиент обрабатывает свои локальные порты, это его личное дело, и поэтому как сервер вы можете ожидать, что получите трафик со всех портов. Разделение 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для более технической презентации.
решение2
DNS-клиенты должны иметь исходный порт > 1023.
Если он < 1024, то это должен быть только исходный порт 53, если он поступает с какого-то другого DNS-сервера, но это маловероятно.
Проверить сtcpdump port 53
Глядя наRFC6056иупрощение с некоторыми примерамимы могли бы пойти дальше и сказать, что любой хорошо работающий стек IP не должен иметь (иметь) исходный порт ниже 49152 (первый эфемерный порт). Однако раздел 3.2 противоречит этому, как и примеры.
Но пока кто-либо не предоставит ссылку на RFC, который переопределяет RFC6056, можно с уверенностью сказать, что sport <= 1023 недействителен.
Если по какой-то причине запрос не выполняется, клиент должен повторить попытку и, возможно, получить успешный запрос. (Даже если это не удастся, я бы проигнорировал такие реализации.)