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

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

Есть ли у кого-нибудь обоснованные доказательства или другое обоснование в пользу использования IPTables или нулевой маршрутизации в качестве решения для внесения в черный список длинного списка IP-адресов? В этом случае все автоматизировано, поэтому простота использования не вызывает особой озабоченности.

EDIT 26-Nov-11

После некоторого тестирования и разработки кажется, что ни один из этих вариантов не работает. Похоже, что и поиск маршрутов, и iptables выполняют линейный поиск через набор правил, и слишком много времени обрабатывают многие правила. На современном оборудовании размещение 1M элементов в черном списке iptables замедляет работу сервера до примерно 2 десятков пакетов в секунду. Таким образом, IPTables и нулевые маршруты отсутствуют.

ipset, как рекомендовал Джимми Хедман, было бы здорово, за исключением того, что он не позволяет отслеживать более 65536 адресов в наборе, поэтому я даже не могу использовать его, если у кого-то нет идей.

По-видимому, единственным решением для блокирования этого множества IP-адресов является индексированный поиск в прикладном уровне. Разве это не так?


Дополнительная информация:

Случай использования в этом случае блокирует список «известных преступников» IP-адресов от доступа к статическому контенту на веб-сервере. FWIW, делая блокировку через Deny from Apache, одинаково медленный (если не более), так же как и линейное сканирование.


FYI: окончательным рабочим решением было использование mod_rewrite от apache в сочетании с картой DB для бербелей для поиска в черном списке. Индексированный характер Бэркелей DBs позволил списку масштабироваться с производительностью O (log N).

21 голос | спросил tylerl 26 62011vEurope/Moscow11bEurope/MoscowSat, 26 Nov 2011 02:31:24 +0400 2011, 02:31:24

6 ответов


15

попробуйте использовать 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

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

ответил pQd 27 72011vEurope/Moscow11bEurope/MoscowSun, 27 Nov 2011 02:38:21 +0400 2011, 02:38:21
10

Это именно то, что означает ipset.

С веб-сайта http://ipset.netfilter.org/:

Если вы хотите

  • хранить несколько IP-адресов или номеров портов и сопоставлять их с коллекцией iptables одним махом;
  • динамически обновлять правила iptables против IP-адресов или портов без ущерба для производительности;
  • выразить сложные IP-адреса и пакеты на основе портов с одним единственным правилом iptables и воспользоваться скоростью IP-пакетов.

, тогда ipset может быть подходящим инструментом для вас.

Это написано членом группы netfilter Core Jozsef Kadlecsik (который также написал цель REJECT), поэтому это лучший выбор, о котором я могу думать.

Он даже включен в последние ядра.

ответил cstamas 26 62011vEurope/Moscow11bEurope/MoscowSat, 26 Nov 2011 13:10:49 +0400 2011, 13:10:49
5

Я не тестировал это сам, но когда я услышал ваше описание проблемы, я сразу подумал «pf» (как из OpenBSD).

pf имеет концепцию таблицы адресов , которые могут быть только тем, что вы ищете.

В соответствии с некоторыми very курсовыми исследованиями, которые я сделал, казалось бы, что это может улучшить масштаб, чем ipset

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

ответил Per von Zweigbergk 27 72011vEurope/Moscow11bEurope/MoscowSun, 27 Nov 2011 02:42:56 +0400 2011, 02:42:56
2

Вы исследовали с помощью FIB_TRIE вместо FIB_HASH.

FIB_TRIE должен масштабироваться намного лучше при подсчете префикса. (/32s пустые маршруты все еще являются префиксами, очень специфичными)

Возможно, вам понадобится скомпилировать собственное ядро ​​для его использования, но оно поможет.

Заметки FIB_TRIE

ответил Joel K 27 72011vEurope/Moscow11bEurope/MoscowSun, 27 Nov 2011 03:53:31 +0400 2011, 03:53:31
1

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

  

maxelem Этот параметр действителен для команды create всех наборов типов хэшей. Он определяет максимальное количество элементов, которые могут быть сохранены в наборе, по умолчанию 65536. Пример: ipset create test hash:ip maxelem 2048.

Я помещаю это здесь, так как я не могу комментировать.

ответил plitter 14 62015vEurope/Moscow11bEurope/MoscowSat, 14 Nov 2015 22:53:09 +0300 2015, 22:53:09
0

Некоторые полезные заметки для всех, кто наткнется на эту проблему в будущем:

Прежде всего, не анализируйте трафик, который вам не нужен. Например, если вы блокируете TCP-трафик, фильтруйте только SYN-пакеты, так что вы попадаете в фильтр только один раз за соединение. Вы можете использовать -m state, если хотите, но отслеживание соединений имеет свои собственные накладные расходы, которые вы можете избежать, если производительность является проблемой.

Во-вторых, положить миллион правил в iptables занимает много времени: несколько минут. Если вам нужно отслеживать многие объекты, вы, вероятно, лучше всего это избегаете netfliter. Огромный размер набора правил действительно имеет значение.

В-третьих, цель состоит в том, чтобы избежать линейного сканирования; но, к сожалению, как iptables, так и iproute2 по своей сути линейны. Вы можете разделить свои правила на двоичный-дерево-стиль на большое количество цепочек, которые ограничивают количество правил, с которыми вы должны консультироваться, но даже при этом iptables не подходит для такого размера проблемы. Он будет работать , но это пустая трата ценных ресурсов.

В-четвертых, и самое главное, нажатие вашей рабочей нагрузки на пользовательское пространство - неплохая идея. Это позволяет вам написать собственный жесткий код или использовать готовое решение, настроенное на ваш набор проблем. Мое собственное решение этой проблемы, как уже упоминалось, состояло в том, чтобы использовать поиск BDB, запускаемый через систему mod_rewrite от apache. Это имело дополнительное преимущество при запуске только одного поиска за сеанс и только после того, как был отправлен действительный запрос. В этом случае производительность была очень быстрой, а стоимость блока была почти незначительна.

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

ответил tylerl 19 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 19 Sep 2013 08:40:29 +0400 2013, 08:40:29

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132