Рекурсивні сервери DNS з відкритим обличчям - правила iptables

Ми запускаємо загальнодоступні рекурсивні DNS-сервери на машинах Linux. Ми використовувались для атак посилення DNS. Чи є рекомендовані iptablesправила, які допомогли б пом’якшити ці напади?

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

Я шукав поради та пропозиції, але всі вони, здається, "не запускають загальнодоступні рекурсивні сервери імен". На жаль, ми опинилися в ситуації, коли речі, які нелегко змінити, зламаються, якщо ми цього не зробимо, і це пов'язано з рішеннями, прийнятими більше десяти років тому, перш ніж ці напади були проблемою.

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

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

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

Якщо ви не можете цього зробити, наступне, що потрібно зробити - це контролювати, хто може отримати доступ до вашого рекурсивного сервера : ви говорите, що "важко сказати", хто ним користується і як, але саме час дізнатися напевно і почати скидати трафік, який не є законним.

Це "квазівійськові / урядові" організації, правда? Що ж, вони, ймовірно, є частиною законного сіткового блоку, яким вони володіють; ці пристрої не є домашніми маршрутизаторами за динамічними IP-адресами. З'ясуйте. Зверніться до них, поясніть проблему та те, як ви економите їх чимало грошей, не змушуючи замінювати мікропрограмне забезпечення чи продукт, якщо лише вони зможуть підтвердити netblock / 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, offset 0, прапори [немає], протокол: UDP (17), довжина: 45) 10.11.12.13.51169> 01.02.03.04.домен: 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 ..... ш ..
        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, RXT для NAME, 0xFF для QTYPE = ANY і 0x01 для QCLASS = IN.

Щоб зробити короткий історію короткою, я виявив, що додавання наступних правил iptables блокує понад 95% підроблених запитів, які вимагають будь-яких записів у корені:

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 цього пристрою передчасно, рано чи пізно.

З наногу десь:

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-атак, воно не ідеальне, але мені допомогло. Рішення полягає в скрипті, який викликає кожні 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