Використовувати IPtables або нульовий маршрут для чорного списку близько 1 мільйона IP-адрес?

Я натрапив на ситуацію, коли клієнту потрібно вносити в чорний список набір трохи менше 1 мільйона окремих IP-адрес (без підмереж), а продуктивність мережі викликає занепокоєння. Хоча я здогадуюсь, що правила IPTables матимуть менший вплив на продуктивність, ніж маршрути, це лише припущення.

Хтось має якісь вагомі докази чи інші обґрунтування на користь або IPTables або нульової маршрутизації як рішення для чорного списку довгих списків IP-адрес? У цьому випадку все автоматизовано, тому простота у використанні насправді не викликає занепокоєння.

РЕДАКЦІЯ 26-листопада-11

Після деякого тестування та розробки виявляється, що жоден із цих варіантів не є працездатним. Здається, що пошук і маршрутів, і iptables роблять лінійний пошук через набір правил, і для обробки цих багатьох правил потрібно занадто багато часу. На сучасному обладнанні введення елементів 1М у чорний список iptables уповільнює роботу сервера до приблизно 2-х десятків пакетів за секунду. Тож IPTables та нульові маршрути вийшли.

ipset, як рекомендує Джиммі Хедман, було б чудово, за винятком того, що це не дозволяє відслідковувати більше 65536 адрес у наборі, тому я навіть не можу спробувати використовувати його, якщо хтось не має жодних ідей.

Мабуть, єдиним рішенням для блокування цього безлічі IP-адрес є індексований пошук у рівні програми. Це не так?

Більше інформації:

Випадок використання в цьому випадку блокує список IP-адрес "відомих правопорушників" від доступу до статичного вмісту на веб-сервері. FWIW, блокування через Apache Deny fromнастільки ж повільне (якщо не більше), як і лінійне сканування.

FYI: Остаточним робочим рішенням було використання mod_rewrite apache у поєднанні з картою DB Berkeley, щоб зробити пошук у чорному списку. Індексований характер БД Берклі дозволив списку масштабуватися з використанням O (log N).

спробуйте використовувати iptables та створити багаторівневе дерево, щоб зменшити кількість пошукових запитів.

iptables -N rules_0_0_0_0_2
iptables -N rules_64_0_0_0_2
iptables -N rules_128_0_0_0_2
iptables -N rules_192_0_0_0_2
iptables -N rules_0_0_0_0_4
iptables -N rules_16_0_0_0_4

iptables -A INPUT -p tcp --dport 80 -s 0.0.0.0/2 -j rules_0_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 64.0.0.0/2 -j rules_64_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 128.0.0.0/4 -j rules_128_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 192.0.0.0/4 -j rules_192_0_0_0_2

iptables -A rules_0_0_0_0_2 -s 0.0.0.0/4 -j rules_0_0_0_0_4
iptables -A rules_0_0_0_0_2 -s 16.0.0.0/4 -j rules_16_0_0_0_4

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

Це саме те ipset, для чого.

З його веб-сайту http://ipset.netfilter.org/ :

Якщо ти хочеш

• зберігати декілька IP-адрес або номерів портів і порівнювати їх з колекцією iptables одним махом;
• динамічно оновлювати правила iptables проти IP-адрес або портів без штрафних санкцій;
• висловити складні IP-адреси та набори правил на основі портів з одним єдиним правилом iptables та скористатися швидкістю наборів IP

то ipset може стати для вас правильним інструментом.

Він написаний членом команди Netfilter Jozsef Kadlecsik (який також написав ціль REJECT), тому це найкращий вибір, про який я можу придумати.

Він навіть включений до останніх ядер.

Я сам цього не перевіряв, але почувши опис вашої проблеми, миттєво подумав " pf" (як від OpenBSD).

pfмає концепцію адресних таблиць, яка може бути саме тим, що ви шукаєте.

Згідно з деякими дуже побіжними дослідженнями, які я робив, здавалося б, це має потенціал масштабуватися краще, ніж ipset. Згідно з розділом FAQ PF про параметри виконання , з полів без налаштування pf підтримує загалом 1000 таблиць із загальною кількістю 200 000 записів у всіх таблицях за замовчуванням. (100 000, якщо система має <100 Мб фізичної пам'яті). Це змушує мене вважати, що принаймні варто подумати про те, щоб перевірити це, щоб перевірити, чи працює він на якомусь корисному рівні.

Звичайно, я припускаю, що ви запускаєте свої сервери в Linux, тому вам доведеться мати окремий блок брандмауера, який працює з якоюсь ОС з pf (наприклад, OpenBSD або FreeBSD). Ви також можете вдосконалити пропускну здатність, відмовляючись від будь-якого стану справної фільтрації пакетів.

Чи проводили ви дослідження за допомогою FIB_TRIE замість FIB_HASH.

FIB_TRIE має значно покращувати масштаб ваших префіксів. (/ 32s null route - це все ще префікси, просто дуже конкретні)

Вам може знадобитися скласти власне ядро, щоб його використовувати, але це допомагає.

Примітки FIB_TRIE

Для нащадків: згідно з ipsetдокументами розмір за замовчуванням набору становить 65536, це можна змінити за допомогою параметрів.

maxelem Цей параметр дійсний для команди створення всіх наборів типів хешу. Він визначає максимальну кількість елементів, які можуть зберігатися в наборі, за замовчуванням 65536. Приклад:ipset create test hash:ip maxelem 2048.

Я ставлю це сюди, оскільки поки не можу коментувати.

Деякі корисні замітки для кожного, хто натрапить на цю проблему в майбутньому:

Перш за все, не аналізуйте трафік, який вам не потрібен. Якщо ви блокуєте TCP-трафік, наприклад, фільтруєте лише SYN-пакети, таким чином ви потрапляєте у фільтр лише один раз за з'єднання. Ви можете використовувати, -m stateякщо хочете, але відстеження з’єднань має власні накладні витрати, яких ви можете уникнути, якщо продуктивність не викликає проблем.

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

По-третє, мета - уникнути лінійних сканувань; але, на жаль, і iptables, і iproute2 за своєю суттю лінійні. Ви можете розділити свої правила на стиль бінарного дерева на велику кількість ланцюжків, що обмежує кількість правил, з якими вам доведеться проконсультуватися, але навіть все-таки iptables не дуже підходять для такого розміру проблеми. Це буде працювати , але це марнотрата цінних ресурсів.

По-четверте, і найголовніше - переміщення вашої навантаження на простір користувачів не є поганою ідеєю. Це дозволяє написати власний чіткий код або скористатись розрядним рішенням, налаштованим на ваш набір проблем. Як я вже згадував, моє власне рішення цієї проблеми полягало у використанні BDB-пошуку, викликаного через mod_rewrite-систему апачі. Це дало додаткову користь від запуску лише одного пошуку за сеанс, і лише після надсилання дійсного запиту. У цьому випадку продуктивність була надзвичайно швидкою, а вартість блоку - майже незначною.

Ви можете виконати аналогічні маніпуляції в просторі користувачів з iptables, використовуючи -j QUEUEціль спільно з libnetfilter_queue. Цей інструмент є потужним, простим і погано задокументованим. Я б рекомендував прочитати якомога більше з якомога більше джерел, оскільки у мережі є багато цікавого матеріалу, який не є частиною жодної офіційної документації.