Общедоступные рекурсивные DNS-серверы - правила iptables

Мы запускаем общедоступные рекурсивные DNS-серверы на машинах Linux. Мы были использованы для атак DNS-усиления. Существуют ли рекомендуемые iptablesправила, которые помогут смягчить эти атаки?

Очевидное решение - просто ограничить исходящие пакеты DNS определенным уровнем трафика. Но я надеялся найти что-то более умное, чтобы атака блокировала трафик на IP-адрес жертвы.

Я искал советы и предложения, но все они, похоже, "не запускают общедоступные рекурсивные серверы имен". К сожалению, мы попали в ситуацию, когда вещи, которые нелегко изменить, сломаются, если мы этого не сделаем, и это связано с решениями, принятыми более десяти лет назад, до того, как эти атаки стали проблемой.

Все это напоминает сценарий «не моя проблема», который на самом деле не является вашей ошибкой и должен / может быть решен на 100% путем принятия соответствующих действий, независимо от того, насколько «сложным» или «сложным» он является, и это прекращает вашу открыть рекурсивный сервер .

Пошаговый отказ: сообщите клиентам, что этот сервер уходит с даты X. После этого им нужно установить патч (если он у вас есть), чтобы он не использовал ваш DNS-сервер. Это делается все время. Сисадмины, сетевые администраторы, ребята из службы поддержки, программисты? Мы получаем это; это событие с истекшим сроком службы происходит постоянно, потому что его стандартная операционная процедура для поставщика / поставщика услуг / партнера, чтобы он сказал нам прекратить использование чего-либо после X date. Нам это не всегда нравится, но это факт жизни в IT.

Вы говорите, что у вас нет этой проблемы на текущих устройствах, поэтому я предполагаю, что вы решили эту проблему с помощью обновления прошивки или патча. Я знаю, что вы сказали, что не можете коснуться устройства, но, конечно, они могут? Я имею в виду, если они позволяют эти коробки , по существу , домашний телефона к вам, они не могут на самом деле быть , что анальным о том, кто делает то , что их устройство; вы можете настроить обратный прокси-сервер на все, что они знают, так почему бы не попросить их установить патч, который исправит это, или попросить их использовать свои собственные DNS-серверы . Конечно, ваше устройство поддерживает DHCP; Я не могу думать о сетевом устройстве (независимо от того, сколько лет / хрупких / странных), что это не так .

Если вы не можете этого сделать, то вам нужно контролировать, кто может получить доступ к вашему рекурсивному серверу : вы говорите, что «сложно сказать», кто его использует и как, но пришло время выяснить наверняка и начать отбрасывать трафик. не законно.

Это "квази-военные / правительственные" организации, верно? Ну, они, вероятно, являются частью законного сетевого блока, которым они владеют; эти устройства не являются домашними маршрутизаторами за динамическими IP-адресами. Узнай Свяжитесь с ними, объясните проблему и то, как вы экономите им много денег, не форсируя замену прошивки или продукта, если только они могут подтвердить сетевой адрес / IP-адрес, который устройство будет использовать для доступа к вашему DNS-серверу.

Это делается постоянно: у меня есть несколько клиентов, которые таким образом ограничивают доступ к экстрасети или слушателям HL7 для медицинских партнеров; это не так сложночтобы они заполнили форму и предоставили IP-адрес и / или сетевой блок, от которого я должен ожидать трафик: если они хотят получить доступ к экстрасети, они должны предоставить мне IP-адрес или подсеть. И это редко является движущейся целью, поэтому не похоже, что вы будете ежедневно получать сотни запросов на смену IP-адресов: большие сети больничных кампусов, которые владеют собственными сетевыми блоками с сотнями подсетей и тысячами и тысячами хост-IP-адресов, регулярно дают мне горстка IP-адресов или подсети, которую я должен был ожидать; Опять же, это не пользователи ноутбуков, которые постоянно бродят по всему университетскому городку, так почему я ожидаю увидеть исходные пакеты UDP с постоянно меняющимся IP-адресом? Очевидно, я предполагаю, что я здесь предположение, но держу пари, что это не так много, как вы думаете, для <100-х устройств. Да, это будет длинный ACL, и да,

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

Длительная работа tcpdumpдолжна работать с фильтрацией входящего UDP 53 и подробной регистрацией в приложении DNS-сервера. Я также хотел бы начать сбор информации об исходных IP-адресах / сетевых блоках / геоИП (все ли ваши клиенты в США? Заблокировать все остальное), потому что, как вы говорите, вы не добавляете никаких новых устройств, вы просто предоставляете наследство обслуживание существующих установок.

Это также поможет вам понять, какие типы записей запрашиваются, и для каких доменов, кем и как часто : чтобы амплификация DNS работала как задумано, злоумышленник должен иметь возможность запросить большой тип записи (1) для функционирующий домен (2).

1. «большой тип записи»: нужны ли вашим устройствам записи TXT или SOA, чтобы они могли быть разрешены вашим рекурсивным DNS-сервером? Вы можете указать, какие типы записей действительны на вашем DNS-сервере; Я считаю, что это возможно с BIND и, возможно, с Windows DNS, но вам придется немного покопаться. Если ваш DNS-сервер отвечает SERVFAILкакими-либо записями TXT или SOA, и, по крайней мере, этот ответ на порядок (или два) меньше полезной нагрузки, которая была предназначена. Очевидно, что вы все еще «часть проблемы», потому что фальсифицированная жертва все равно будет получать эти SERVFAILответы от вашего сервера, но, по крайней мере, вы их не забиваете, и, возможно, ваш DNS-сервер «исключается» из списка (-ов) сбора. Со временем боты не «сотрудничают».

2. «функционирующий домен»: вы можете включать в белый список только те домены, которые являются действительными. Я делаю это на своих защищенных центрах обработки данных, где для работы серверов требуется только Центр обновления Windows, Symantec и т. Д. Тем не менее, вы просто уменьшаете ущерб, который вы наносите в этот момент: жертва все равно будет подвергаться бомбардировке NXDOMAINили SERVFAILответам с вашего сервера, поскольку ваш сервер все равно будет реагировать на поддельный IP-адрес источника. Опять же, скрипт Bot может также автоматически обновлять свой список открытых серверов в зависимости от результатов, что может привести к удалению вашего сервера.

Я бы также использовал некоторую форму ограничения скорости, как предлагали другие, либо на уровне приложения (например, размер сообщения, количество запросов на клиента), либо на уровне брандмауэра (см. Другие ответы), но, опять же, вы собираетесь нужно сделать некоторый анализ, чтобы убедиться, что вы не убиваете законный трафик.

Система обнаружения вторжений, которая была настроена и / или обучена (опять же, здесь необходима базовая линия), должна также иметь возможность обнаруживать ненормальный трафик с течением времени по источнику или объему, но, вероятно, будет требовать регулярной няни / настройки / мониторинга для предотвращения ложных срабатываний и / или посмотреть, действительно ли это предотвращает атаки.

В конце концов, вы должны задаться вопросом, стоит ли все эти усилия того или иного, или вы просто должны настаивать на том, что все сделано правильно, и это в первую очередь устраняет проблему.

Это зависит от того, какое ограничение скорости вы хотите сделать.

iptablesОграничение скорости с помощью действительно больше предназначено для ограничения входящих пакетов, так как пакеты до предела будут соответствовать фильтру и применяют указанную цель (например, ACCEPT). Вероятно, у вас будет последующая цель для DROPпакетов, которые не соответствуют фильтру. И хотя у iptablesнего есть QUEUEцель, он просто передает пакет в пространство пользователя, где вам нужно предоставить свое собственное приложение для очередей. Вы также можете ограничить скорость исходящих пакетов, но мало кто действительно хочет начать отбрасывать исходящий трафик.

iptables снижение лимита скорости:

iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP

Использование, hashlimitа не limitдаст вам ограничение скорости на IP-адрес назначения. То есть, пять пакетов до 8.8.8.8, которые достигли предела, предотвратят отправку пакетов на 8.8.4.4, в то время как с hashlimitмаксимальным значением 8.8.8.8 вы все равно сможете достичь 8.8.4.4, что звучит больше как то, что вы хотите.

Если вы не хотите, чтобы пакеты, превышающие ограничение, были отброшены, тогда вы действительно хотите tc. tcбудет регулировать поток, чтобы получить хороший устойчивый поток, а не много бурного трафика. На входящей стороне пакеты доставляются приложению медленнее, но все будут поступать по порядку. На исходящих пакетах ваше приложение покинет как можно быстрее, но помещается на провод в согласованном потоке.

Я не использовал tcмного, но вот пример ограничения ICMP, который вы, вероятно, можете легко адаптировать для DNS.

Вот одна вещь, которую вы можете сделать, чтобы потенциально смягчить ответы на поддельные запросы, но это требует некоторой работы:

Во-первых, взгляните на свой журнал канала безопасности и найдите IP-адрес, который становится поддельным.

Затем запустите tcpdump, используя этот IP-адрес источника (10.11.12.13) следующим образом:

tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S

Вы получите что-то вроде этого:

18: 37: 25.969485 IP (tos 0x0, ttl 52, id 46403, смещение 0, флаги [нет], прото: UDP (17), длина: 45) 10.11.12.13.51169> 01.02.03.04.домен: 4215+ ЛЮБОЙ ? , (17)
        0x0000: 4500 002d b543 0000 3411 b9d9 0A0B 0C0D E ..-. C..4 .......
        0x0010: 0102 0304 c7e1 0035 0019 0e89 1077 0100 ....... 5 ..... w ..
        0x0020: 0001 0000 0000 0000 0000 ff00 0100 ..............

Теперь самое интересное! Откройте rfc1035 по адресу http://tools.ietf.org/html/rfc1035 и перейдите к разделу 4.1.1.

Пришло время преобразовать результаты tcpdump и выяснить шаблон, который мы можем использовать для создания фильтра на уровне пакетов.

Идентификатор заголовка начинается с 0x1C, поэтому у нас есть несколько флагов в 0x1E, QDCOUNT в 0x20, ANCOUNT в 0x22, NSCOUNT в 0x24 и ARCOUNT в 0x26.

Это оставляет фактический вопрос в 0x28, который в данном случае равен NULL (ROOT) для NAME, 0xFF для QTYPE = ANY и 0x01 для QCLASS = IN.

Короче говоря, я обнаружил, что добавление следующего правила iptables блокирует более 95% поддельных запросов, которые запрашивают ЛЮБЫЕ записи в ROOT:

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP

Ваш пробег может варьироваться ... надеюсь, это поможет.

Использование tcи организация очередей в linux для исходящего порта 53 UDP:

IFACE=eth0    
tc qdisc  add dev ${IFACE} root handle 1: htb default 0
tc class  add dev ${IFACE} parent 1: classid 1:1 htb rate   10mbit burst 20m
tc qdisc  add dev ${IFACE} parent 1:1 handle 10: sfq perturb 1
tc filter add dev ${IFACE} protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1

Будет установлен discлимит в 10 Мбит для любого пакета с меткой брандмауэра «1». Маркировка брандмауэра является только внутренней частью брандмауэра и не изменяет пакет. Просто обработка пакета дисциплиной очереди. Вот как вы используете iptablesдля маркировки брандмауэра:

iptables -A PREROUTING -o eth0 -p udp --sport 53 -t mangle -j MARK --set-mark 1
iptables -A PREROUTING -o eth0 -p udp --dport 53 -t mangle -j MARK --set-mark 1

Изменить по своему вкусу, чтобы исключить доверенные подсети и / или места назначения. -o eth0Ограничивает формирование только для исходящих пакетов. Надеюсь это поможет.

Я бы попытался составить список всех клиентов, которые полагаются на ваши рекурсивные распознаватели. Начните с дня или около того следов пакетов на ящиках DNS. Оттуда начните создавать правила iptables, чтобы разрешить трафик, который вы распознаете и авторизуете. По умолчанию в конечном итоге будет сбрасывать трафик до 53 / tcp и 53 / udp. Если это что-то нарушает, настройте свои правила.

в зависимости от «позиции» сети, в которой вы находитесь [имея несколько каналов bgp или находясь на «конце» Интернета - как тупиковая сеть], вы можете попробовать что-то вроде uRPF, чтобы предотвратить подделку адреса источника.

другой источник информации.

Эти устройства все еще находятся на контракте поддержки? Если это так, обратитесь к своим клиентам. Сообщите им, что в последнее десятилетие интернет немного изменился, и для того, чтобы продолжать обеспечивать разрешение имен для этих устройств, вам необходимо знать IP-адрес SRC, от которого ожидают запросы. Установите дату ~ 6 месяцев в будущем, когда вы больше не сможете обслуживать неизвестных клиентов, и придерживайтесь ее. Это довольно распространенное явление в отрасли. Если на эти устройства больше нет контракта на поддержку ... звучит как деловое решение. Как долго ваша компания намерена тратить ресурсы на древний продукт, который больше не приносит доход?

Они похожи на специализированные устройства, настолько ли они специализированы, что вы можете разумно предсказать, для каких доменов ожидать законных запросов? bind поддерживает представления, создает общедоступное представление, которое выполняет рекурсию только для этих доменов.

Используйте это как возможность обучения, если вы еще этого не сделали, прекратите выпускать продукты, в которых у вас нет возможности исправлять ошибки. Вот что это, ошибка. Тот, который, безусловно, EOL это устройство преждевременно, рано или поздно.

От Nanog где-то это:

iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP 

Это не идеально. Возможно, было бы лучше разрешить меньшее количество пакетов в секунду и иметь более высокий пакет.

Вот решение, которое я использовал пару раз против DDOS-атак, оно не идеально, но помогло мне. Решение состоит в том, что cron вызывает каждые N минут (например, 1,2,3 и т. Д.) Cron и блокирует IP-адреса, которые создают число соединений, превышающее заданное в сценарии:

#!/bin/sh

PORT_TO_CHECK="53"
CONNECTION_LIMIT="20"
IPTABLES="/sbin/iptables"

netstat -an > /tmp/netstat.tmp
Buf_var1=`cat /tmp/netstat.tmp | grep -v "LISTEN"| grep ":$PORT_TO_CHECK\ " | grep -v "0.0.0.0" | awk '{print $5}' | grep -v ":$PORT_TO_CHECK$" | sed -e 's/^::ffff://g' -e 's/:.*$//g' | sort | uniq`
i=0
banned_flag=0
for conn in `for i in $Buf_var1; do echo -n "$i "; cat /tmp/netstat.tmp | grep -c $i;done | grep -v "=\ 0"`;do
[ $i = 0 ] && connip=$conn && i=1
[ $i = 2 ] && {
connum=$conn
[ $connum -ge $CONNECTION_LIMIT ] && {
[ "$var_test" = "" ] && {
$IPTABLES -I INPUT -s $connip -j DROP
banned_flag=1
}
}
}
[ $banned_flag = 1 ] && i=0
[ $i = 1 ] && i=2
done
rm -f /tmp/netstat.tmp