Я использую авторитарный сервер bind dns. Я следую всем рекомендуемым практикам, и мой сервер является только авторитарным (не рекурсивным) с включенным ограничением скорости.
BIND отвечает на запросы для неавторитетных зон кодом REFUSE. Ограничение скорости делает свою работу, не давая моему серверу участвовать в любой крупномасштабной атаке udp amplification, однако я бы предпочел исключить любые и все ответы для зон, которые я не являюсь авторитарными.
Есть ли для этого возможность настройки?
решение1
Хотя не отвечать в точности в том сценарии, который вы описали в вопросе (поддельный запрос в потенциальной атаке с усилением, или же проверять, можно ли использовать ваш сервер в такой атаке) было бы нормально, поскольку на самом деле ни один резолвер не ждет вашего ответа, проблема в том, что не отвечать на запросы может вызвать реальные проблемы, а предлагаемое вами решение шире, чем точный сценарий, который вы описали вначале (учтите, что некоторая зона, которой у вас на самом деле нет, может быть делегирована вашему серверу имен, как случайно, так и намеренно).
Не отвечать на запросы обычно не считается хорошей практикой для авторитетных серверов имен. Причины этого включают:
- Серверы-резолверы отслеживают отзывчивость/надежность авторитетных серверов, с которыми они работают, чтобы улучшить свою собственную отзывчивость. Это делается на основе сервер-за-сервером, а не на основе запроса-за-запроса. То есть, вы можете нанести ущерб текущей воспринимаемой надежности вашего сервера имен, если в конечном итоге не будете отвечать на (потенциально неправильно направленные) запросы из законных источников. Возможно, можно обмануть резолверы, заставив их считать ваш сервер имен полностью отключенным (временно, но, возможно, снова и снова)
- Если не отвечать, это может также повлиять на «хорошие» запросы (например, из-за высокой частоты запросов?), что может вызвать дополнительные проблемы, которые могут быть не очевидны на первый взгляд, например, повышенный риск успешных атак по отравлению кэша для любых неподписанных зон, которые вы обслуживаете (особенно если злоумышленник может достаточно надежно вызвать падение вашего запроса).
Вместо этого вы, как правило, хотите ограничить размер ответов, чтобы фактически не обеспечивать усиления, которого добиваются злоумышленники (что, судя по всему, вы уже делаете):
- Запросы, не соответствующие ни одной зоне (как в вашем примере), должны получать пустой
REFUSEDответ (раньше было принято отправлять полный ответ-реферал для корня) - При реализации ограничения скорости вы, вероятно, захотите отправлять пустые усеченные (
TCset) ответы, а не не отвечать, тогда как если реальный законный сервер-разрешитель окажется с ограничением скорости, он получит ответ, а пометка его как усеченного просто заставит его повторно отправить свой запрос по TCP. - Этот
ANYтип запроса изначально имеет ограниченную фактическую полезность, а иногда и еще больше ограничивается в целях избежания способов генерации больших ответов. (Например,minimal-anyв BIND) - (И, конечно же, категорическое недопустимость рекурсии в Интернете в целом)
Что касается неответа с BIND, то функция, которая позволяет не отвечать, — это ограничение скорости ответа (RRL), имеющее slipпараметр конфигурации для управления соотношением усечения и отбрасывания, когда кто-то достигает ограничения скорости. Однако следует отметить, что отбрасывание в основном актуально для сервера-разрешителя, а не для авторитетного сервера (согласно предыдущему объяснению). Это также отмечено вРаздел RRL руководства BIND:
(Примечание: отброшенные ответы от авторитетного сервера могут снизить сложность успешной подделки ответа третьей стороной рекурсивному резолверу. Лучшая защита от поддельных ответов заключается в том, чтобы авторитетные операторы подписывали свои зоны с помощью DNSSEC, а операторы резолверов проверяли ответы. Если это невозможно, операторы, которых больше волнует целостность ответа, чем предотвращение флуда, могут рассмотреть возможность установки slip на 1, в результате чего все ответы с ограниченной скоростью будут усекаться, а не отбрасываться. Это снижает эффективность ограничения скорости против атак с отражением.)
Если вы находитесь в тяжелой ситуации, когда другой компромисс действительно имеет смысл, вы можете рассмотреть slipручку, упомянутую выше, или какой-либо инструмент с другим набором ручек ограничения скорости, напримерdnsdist.
Однако если это всего лишь нормальный уровень фонового шума, то, пытаясь решить его, вы, вероятно, создаете новые проблемы, не получая при этом никакой выгоды.