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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, offset 0, flags [none], proto: UDP (17), length: 45) 10.11.12.13.51169 > 01.02.03.04.domain:  4215+ ANY? . (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, который в данном случае равен нулю (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 поддерживает представления, создайте общедоступное представление, которое выполняет рекурсию только для этих доменов.

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

Откуда-то наног это:

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 и т.д. минут) и блокирует 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