10 000 записей в iptables на CentOS 4 ГБ Работали, двухъядерные 2.3 ГГц?

Не волнуйся, в худшем случае это будет железный возраст. (grin)

Большое количество правил netfilter, которые ядро должно выполнять для каждого отдельного пакета, окажет негативное влияние на производительность системы и потребление ресурсов (как CPU, так и памяти). Приятно то, что существует ряд трюков, которые можно использовать для минимизации проблем.

1. Правила "короткого замыкания" для распространенных случаев: 90+% получаемых вами пакетов будут частью существующего установленного или связанного с ним соединения. Таким образом, вы можете избежать необходимости пропускать все эти пакеты через длинный список фильтров, имея правило -m state --state ESTABLISHED,RELATED -j ACCEPT перед любым из правил списка фильтров.

2. Только фильтрование определенных портов: если вы используете веб-сервер, но на самом деле беспокоитесь только о SSH-атаках грубой силы, вы можете избежать необходимости обрабатывать весь HTTP-трафик через список фильтров, поместив список фильтров в отдельную цепочку, а затем посылать через фильтр только трафик 22 порта, например:

   iptables -N геофильтр
   iptables -I геофильтр -s  -j DROP
   [и т.д. и т.п.]
   iptables -I INPUT -p tcp --dport 22 -j геофильтр
   

3. "Древовидная структура" ваших правил фильтрации: у вас может быть 10,000 правил фильтрации, но только одно из них когда-либо будет соответствовать. Таким образом, вы можете использовать древовидную структуру, чтобы уменьшить количество правил, которые должен пройти каждый пакет, поместив все правила для, скажем, каждого /8 в свою цепочку. Расширение на предыдущем примере geofilter:

   iptables -N geofilter_1
   iptables -N геофильтр_2
   [и т.д. и т.п. вплоть до геофильтра_223]
   iptables -I геофильтр -s 1.0.0.0/8 -j геофильтр_1
   iptables -I геофильтр -s 2.0.0.0/8 -j геофильтр_2
   [и т.д. и т.п.]
   iptables -I геофильтр_1 -s 1.2.3.0/24 -j DROP
   iptables -I геофильтр_1 -s 1.5.9.0/18 -j DROP
   [и т.д. и т.п. для всех правил в 1/8]
   iptables -I геофильтр_2 -s 2.42.0.0/16 -j DROP
   [и т.д. и т.п. для всех правил в 2/8]
   [продолжить картину для всех /8s]
   Это означает, что любой пакет, который должен пройти через правила фильтрации, должен будет, в лучшем случае, пройти через 223 правила (все правила  геофильтра ), плюс, сколько бы правил ни было в любом из списков фильтров per-/8. (Почему в цепочке geofilter осталось 223, а не 254, 255 или 256 правил, как упражнение для дальновидного читателя). Вы можете сделать это еще более эффективным, имея несколько уровней дерева: разделение на /4, затем на /8, затем на /12, или что-то в этом роде. Вы можете добавить столько уровней, сколько пожелаете, в соответствии с вашим компромиссом между стоимостью и выгодой. Вы даже можете сделать это по-разному для разных цепочек: начните с разделения на один уровень в /4, затем на любую цепочку с более чем несколькими сотнями правил, на /8, и на любую цепочку, которая до сих пор  имеет более чем несколько сотен правил, на /12. 
   

4. Сложите правила: Я бы поставил разумную ставку, что списки адресов, которые вы используете, не были оптимально объединены. Даже если они были для одной страны, после того, как вы получите списки нескольких стран вместе, могут быть соседние блоки, которые приходят из разных стран, которые вы могли бы собрать вместе. Например, кто-то в Китае получил 192.0.2.0/25, а кто-то в Гонконге получил 192.0.2.128/25 (да, не реалистичные блоки, но RFC5737 дает нам только /24 для документации). Вы можете объединить это в 192.0.2.0/24 и сохранить правило.

   Как только вы начнете это делать, вы часто можете обнаружить, что вы можете значительно уменьшить количество правил в вашем списке . (В сочетании со следующим правилом вы можете уменьшить список правил наполовину или больше.) Реализация агрегации проста; инструмент netmask возьмёт произвольный список блоков и вернёт вам минимальный список блоков CIDR:

   netmask -c 192.0.2.0/25 192.0.2.128/25 192.0.3.0/24 192.0.1.0/25
    192.0.1.0/25
    192.0.2.0/23
   

5. Отрицательные правила: Часто можно встретить, что большое количество маленьких блоков объединяются в один, гораздо больший блок, за исключением за один маленький кусочек в середине. В некоторых случаях почти весь /8 или /10 приходится на одну страну, за исключением нескольких маленьких /22, которые каким-то образом сбежали в другую часть мира. В этом случае, вы можете поставить правила ACCEPT для этих двух маленьких белых блоков, за которыми следует правило DROP для покрывающего большего блока. Разработка оптимальных блоков потребует некоторой степени программирования, но это не ракетостроение.