Разработчики подсистемы NetFilter выставили на обсуждение патчи с начальной реализацией нового пакетного фильтра bpfilter, который со временем может заменить ныне поддерживаемые механизмы фильтрации пакетов nftables и iptables. Несмотря на все свои достоинства интенсивность внедрения механизма Nftables оставляет желать лучшего и iptables до сих пор остаётся более востребован и не желает повторять судьбу ipchains и ipfwadm.В nftables логика фильтрации и специфичные для протоколов обработчики компилируются в байткод в пространстве пользователя, после чего данный байткод загружается в ядро при помощи интерфейса Netlink и выполняется в специальной виртуальной машине, напоминающей BPF (Berkeley Packet Filters). При этом последние годы в ядре Linux поставляется универсальная встроенная виртуальная машина BPF с JIT, для которой активно ведётся работа по улучшению производительности, функциональности и безопасности. Чтобы не поддерживать две разные виртуальные машины, выполняющие сходные задачи, и для достижения более высокой производительности у разработчиков возникла идея построения пакетного фильтра на основе штатного BPF-движка ядра Linux.
В итоге был подготовлен прототип нового пакетного фильтра bpfilter, иллюстрирующий идею применения BPF для фильтрации пакетов. Наиболее важным решением в предложенном прототипе стало желание обеспечить полную совместимость с наборами правил iptables, т.е. bpfilter сможет выступить в роли прозрачной замены iptables, полностью совместимой со всеми существующими конфигурациями (администраторам не придётся изучать новый синтаксис правил). Для достижения данной задачи планируется обеспечить совместимость на уровне API, который использует утилита iptables для взаимодействия с ядром (штатную утилиту можно будет пересобрать с реализацией API на базе bpfilter).
Bpfilter обрабатывает запросы API iptables и транслирует их в программы BPF, привязываемые к различным подсистемам. Например, при помощи XDP (eXpress Data Path) можно запустить BPF-программу на уровне сетевого драйвера, с возможностью прямого доступа к DMA-буферу пакетов для высокопроизводительной обработки. Трансляция правил выполняется целиком в пространстве пользователя, что упрощает отладку и повышает безопасность. Для повышения производительности также может применяться JIT-компиляция BPF в машинные инструкции для архитектур x86_64, arm64, ppc64, sparc64, mips64, s390x и arm32, или задействование аппаратных механизмов выполнения BPF на уровне сетевого адаптера (например, Netronome NFP SmartNIC).
Харальд Вельте (Harald Welte), один из основных разработчиков netfilter/iptables, поставил под сомнение идею полной эмуляции API iptables через BPF для обеспечения прозрачной замены iptables, так как полностью повторить поведение iptables будет слишком трудно, а наличие различий при обработке существующих наборов правил iptables может привести к возникновению неожиданных проблем с безопасностью.
К тому же некоторые элементы дизайна iptables нельзя назвать удачными и повторение API iptables в bpfilter может привести к тому, что допущенные 18 лет назад ошибки проектирования iptables закрепятся ещё на 10 лет. Например, API iptables не предоставляет способа добавления/замены единичного правила или небольшого набора правил, а может только целиком очистить и перезагрузить всю конфигурацию. Данная особенность делает внесение изменений в межсетевой экран неудобным и существенно усложняет координацию одновременного внесения изменений несколькими обработчиками. Недовольство также вызывает необходимость разделения наборов правил для IPv4 и IPv6.
Вельте предложил не фокусироваться только на повторении iptables, а реализовать в bpfilter эмуляцию nftables API, который спроектирован с учётом недостатков iptables и больше соответствует современным реалиям. Возможность использования API nftables позволит поддержать тех, кто уже перешёл на nftables, а для остающихся на iptables будет стимулировать миграцию.
Дэвид Миллер (David Miller), мэйнтейнер сетевой подсистемы ядра, возразил, что iptables до сих пор существенно более распространён и реализация его интерфейса позволит достичь широкого охвата при тестировании. Вельте парировал тем, что в наиболее крупных областях применения, таких как Docker и Kubernetes, используются утилиты командной строки, а не iptables API, поэтому нет смысла в эмуляции API как такового для проведения тестирования в подобных системах.
Миллер также обратил внимание на то, что nftables так и не решил проблемы с производительностью подсистемы фильтрации пакетов, сместив вместо этого внимание на сетевые технологии в пространстве пользователя. Nftables может стать одним из тех экспериментов, которые позволяют разобраться в некоторой проблемной области, но никогда не получают распространения в реальной практике. При этом, bpfilter ещё очень далеко до интеграции в ядро, так как представления о его производительности пока носят лишь теоретический характер, код достаточно сырой, отсутствуют многие возможности, а некоторые функции не могут быть реализованы через BPF и требуют дополнительной поддержки в ядре (например, отслеживание соединений).
URL: https://marc.info/?l=linux-netdev&m=151878844503670&w=2
Новость: https://www.opennet.ru/opennews/art.shtml?num=48117
Какая у них интеллектуальная дискуссия, а был бы Линус обозвал бы всех макаками
Если б они сказали "Мы запилили новый bpfilter, с новой версией все старые iptables и nftables правила перестанут работать", то конечно назвал бы, и весьма заслуженно.
> Если б они сказали "Мы запилили новый bpfilter, с новой версией все
> старые iptables и nftables правила перестанут работать", то конечно назвал бы,
> и весьма заслуженно.Да их и сейчас не лишне назвать. Потому что если вгружать мутные блобы из юзермода в ядро - потом окажется что ядру машинный код подпихнули и после пары финтов ушами у атакующего выполняется его ядерный код. Ухитрившись обойти новомодные изоляции юзерского адресного пространства от ядра и все такое прочее.
> идею применения Berkeley Packet Filter для фильтрации пакетовкакая свежая идея, бинго
И почему-то не слышно воплей что бсд не нужен.
Все аналитики в школе?
В Беркли всё ещё химичат с алгоритмами TCP/IP, так-как у них актуальны проблемы с TCP-шумом.Знаю одного чела, которого пригласили в офис компании, и из "энтузиаста Creative Commons" сделали оплачиваемым сотрудником... так вот: он говорил, что в Лос Анджелесе и Вашингтоне интернет хуже, чем в сельской хате.
Короче, у них там внaтyрe лютo бoмбит, потому они и пытаются вечно инфраструктуру оптимизировать (апдейты вeнды перевести в p2p, или линyпсoвый пакетфильтер поправить)
> И почему-то не слышно воплей что бсд не нужен.А что, нужен? Кому и нахрена? Они могут делать хоть что-то лучше других? Грантоедство чур не считается.
А как жо Firewalld?..
надстройка над Iptables же
вот-вот. Сразу видна квалификация *-d разработчиков: только очередную обертку и могут сделать
Кроме оберток и не нужно ничего (да и обертка не нужна, впилили бы механизмы загрузки конфигов для определнных интерефейсов при их поднятии и других событиях и все).
Вон сионеры насоздавали, сами не могут понять зачем. Если пипл не оценил инноваций, значит старый добрый лучше.
Может пиплам некогда заниматься тестированием, да и рисковано!
Механизмы есть, см как реализовано в redhat. Пипл оценил, что в "новом" фаерволе многовато правил в старом стиле надо писать. Впрочем, для нужнд защиты типового сервера сойдет, т.к. ускоряет. А как фаервол уровня организации линукс все равно мало кто способен настроить.
> вот-вот. Сразу видна квалификация *-d разработчиков: только очередную обертку и могут сделатьБлин, httpd - обертка над протоколом http оказывается. А что до квалификации, firewalld - это кусок бидона. Чего ты от него при этом ожидал?
> надстройка над Iptables жекоторый в свою очередь надстройка над netfilter
тык чтоже?: nftables учить или нет?
systemd-tables учи заранее..
> systemd-tables учи заранее.....Который будет всего-лишь парсером конфигов с их ивент-активацией... "Pulse vs ALSA"
Эврика, пойду фичреквест на гитхабе закатаю!
"Например, API iptables не предоставляет способа добавления или замены единичного правила или небольшого набора правил...." - Вельте бредит?
Не путайте API iptables и утилиту iptables.Из FAQ:
4.5 Is there an C/C++ API for adding/removing rules?
The answer unfortunately is: No.
We are well aware that there is a fundamental lack for such an API, and we are working on improving that situation. Until then, it is recommended to either use system() or open a pipe into stdin of iptables-restore. The latter will give you a way better performance.
Спасибо за грамотный ответ! Не думал, что всё так запущено.> Не путайте API iptables и утилиту iptables.
> Из FAQ:
> 4.5 Is there an C/C++ API for adding/removing rules?
> The answer unfortunately is: No.
> We are well aware that there is a fundamental lack for such
> an API, and we are working on improving that situation. Until
> then, it is recommended to either use system() or open a
> pipe into stdin of iptables-restore. The latter will give you a
> way better performance.
Года 4 назад обсуждали тут.
Обсуждали код, не слова из мануала, а код.
Логика работы при добавлении правила такая — строится новая таблица, добавляемое правило занимает своё место, после чего в ядре меняется указатель на новую таблицу.
Что и где тут запущено — на совести очередного нового открывателя америки.
Как соблюсти последовательность и логику при добавлении правила
и не запороть?
> Как соблюсти последовательность и логику при добавлении правила
> и не запороть?ДДобавляй user define chains на каждый случай.
ну, все операции атомарны и thtrad safeа логику — а вам то за что з/п платят? не, может и терминатор наверное конечно. но лично я предпочту как-то сам.
Зыж
iptables все равно лучший на данный момент.
а там,.. хоть jit, да хоть в контейнеры,.. — академический интерес.
что 4 года назад писал, что сейчас.
> Как соблюсти последовательность и логику при добавлении правила
> и не запороть?Использовать "-I CHAIN номер-правила" вместо "-A CHAIN".
> Что и где тут запущено — на совести очередного нового открывателя америки.Что, всего половину логики программы iptables надо написать, а не всю? Офигительное API - перестраивать самому таблицы для изменения 1 правила. Очень удобно и код простой и компактный.
> Не путайте API iptables и утилиту iptables.а в чем и зачем там вообще весь "api", если правила добавлять он не умеет?
И кому он вообще нужен, если нет никакой проблемы выковырять нужный код из iptables (afair, он использует кернельный сокет, величайшая трагедия для манки-кодера, столь сложный код придется ему самому вставлять, а не тягать из готовой библиотеки)
в общем, одна попытка заставить всех использовать уродливый непригодный для ручного управления (потому что структура правил такая, что ее глазами просмотреть и осознать за пределами локалхостового администрежа почти нереально) апи провалилась, пытаются подъехать с другой стороны.
(да, вы сделаете кривой и косой эмулятор iptables -A, и может быть даже -R - а как вы собрались _обратно_ транслировать ваш BPF для _просмотра_ того, что получилось? А, я знаю: никак.)
К сожалению, разработчики всего этого ненужного хлама - не админы ни разу, даже не бывшие. Им в голову не приходит, как на самом деле люди используют эти фильтры. И они, похоже, искренне не понимают, почему предыдущая попытка не прокатила.
Это очередные "еще не совсем готово для десктопа". И интерфейс они пишут не для людей, а для очередного кривого-косого гуевого чудо-файрвола, клик-клик-клик, вот, все работает. Ну и что, что ты хотел совсем не это - если такой умный, иди пиши bpf-правила руками.
> (afair, он использует кернельный сокет, величайшая трагедия для манки-кодера,
> столь сложный код придется ему самому вставлять, а не тягать из
> готовой библиотеки)простите, что именно используется и где?
> (да, вы сделаете кривой и косой эмулятор iptables -A, и может быть
> даже -R - а как вы собрались _обратно_ транслировать ваш BPF
> для _просмотра_ того, что получилось? А, я знаю: никак.)мысль о том, что где-то можно хранить оригинальный набор правил вам не приходила в голову?
> К сожалению, разработчики всего этого ненужного хлама - не админы ни разу,
> даже не бывшие. Им в голову не приходит, как на самом
> деле люди используют эти фильтры. И они, похоже, искренне не понимают,
> почему предыдущая попытка не прокатила.вы совершенно не понимаете как устроен и работает netfilter
> мысль о том, что где-то можно хранить оригинальный набор правил вам не приходила в голову?нет, я не идиот.
Это не "оригинальный набор правил", в этом все и дело. Если я изменю напрямую правила в чудо-фильтре в обход вашего "оригинального набора" (добавив себе отличную дырку в обход вашей системы проверок) - вы этого даже не увидите. Потому что "оригинальный" - он в ядре. (лет через десять додумаются его "подписывать", а чо, щас так модно. Ну что же, и подпишем, вы ж как-то собираетесь им управлять? Значит и все ключики где-то недалеко лежат.)
Все то же самое еще и возможно из-за ошибок в коде чудо-транслятора, как вы это дебажить собрались? ("вы" - это к админам, если что, а не к гени[т]альным разработчикам еще-не-совсем-готового-для-альтернативно-одаренных хлама)И при этом в таком виде, что проверить, какой он на самом деле - вы не можете, он не человекочитаем в принципе. Удобно для кульхацкеров, чо.
> вы совершенно не понимаете как устроен и работает netfilter
где уж нам, действительно.
>Если я изменю напрямую правила в чудо-фильтре в обход вашего "оригинального набора" (добавив себе отличную дырку в обход вашей системы проверок) - вы этого даже не увидитесложно вам, наверное.
начать можно с того, что просто хранить текущий рулесет в ядре в сжатом виде as is.
>сложно вам, наверное.Просто только простейшим. Вон амёбы, как выяснили британские учонные(Tm) - всегда улыбаются ;)
>начать можно с того, что просто хранить текущий рулесет в ядре в сжатом виде as is.И как это поможет от прямых бинарных изменений (см новость)? :)
При добавлении еденичного правила, iptables выгружает через api весь набор правил, добавляет одно и загружает назад. Наверное, это и имелось в виду, а не возможности утилиты командной строки iptablesК сожалению, не помню где именно прочитал об этом. Вероятно, могут возникать проблемы при множественном конкурентном использовании этого api
> При добавлении еденичного правила, iptables выгружает через api весь набор правил, добавляет
> одно и загружает назад. Наверное, это и имелось в виду, а
> не возможности утилиты командной строки iptables
> К сожалению, не помню где именно прочитал об этом. Вероятно, могут возникать
> проблемы при множественном конкурентном использовании этого apiНу дык это "блобик" загружаемый в ядро. И только особо приближенные понимают как этот "блобик" получился при компиляции, а с учетом всяких там оптимизаций (если они есть) вообще становится очень сложно понять как вырезать одно (или несколько) правил из этого "блобобика" и добавить в него другие правила. ИМХО.
> К сожалению, не помню где именно прочитал об этом. Вероятно, могут возникать
> проблемы при множественном конкурентном использовании этого apiтам есть "commit" (то есть оно "почти-атоммарное"). И внутри оно немножко менее уныло, чем ты описал.
А проблемы при попытках в четыре руки поковырять файрвол - я тебе гарантирую без всяких дополнительных условий и при любой его конструкции, хоть с реплейсом по одному правилу, хоть с его имитацией через полный парсинг и вставку обратно, хоть с атоммарными коммитами и автооткатом.
Ну то-есть ты сам описал предпосылки почему systemd должен стать центральным диспетчером фаера. Так и запишем! :)
> API iptables не предоставляет способа добавления или замены единичного правилаКогда пробую новую конфигурацию добавляю правила по-одному.
Неужели при этом все правила сбрасываются и перезагружаются заново, с новым добавленным?
Да, именно так все и происходит
Да, но пофиг, - реальных проблем с производительностью это не создает
Только накопленная статистика слетает, а так ничего.
раньше, вплоть до 2.6.27 не слетала
>Неужели при этом все правила сбрасываются и перезагружаются заново, с новым добавленным?Тут проблема в чем? В том, что многие забывают, что система слегка не однозадачная. :)
Пока ты добавляешь/удаляешь/заменяешь правила она разбирает пакеты. И поэтому система с copy on write list имеет серьезное преимущество. С какой таблицей начат разбор пакета - с такой и закончится. На ходу никто подковы менять не будет. При этом новый пакет не будет ждать, окгда закончится обработка предыдущего и начнет работать с новой таблицей.
Но это пол беды. Вторая - система слегка не однопользовательская. Пока Вы хотите заменить правило №5 (с разрешить входящие на 127.0.0.1 порт 80, на запретить это безобразие), Вася из соседнего ssh решил удалить правило №3. Внимание вопрос - как не получить состояние, когда в новой таблице правилом №4 будет старое №5 (разрешить), новым №5 станет новое №5 (запретить), а старое №6 канет втуне. Простой способ - через глобальную блокировку. Но сетевики их не любят всеми фибрами своей души. Поэтому используется простая схема - атомарная замена указателя на правильную таблицу с проверкой. Но процедура замены правила №5 не сможет сама понять, что делать если таблица поменялась. Единственный вариант попросить Вас заново сформулировать задачу. А нафиг тогда эта процедура? Вот и нет ее. Просят всегда согласованную таблицу правил.
>и выполняется в специальной виртуальной машине, напоминающей BPF (Berkeley Packet Filters)Опять этот троян.
>Несмотря на все свои достоинства интенсивность внедрения механизма Nftables оставляет желать лучшего
Усложненный синтаксис и встроенный троян, сомнительные такие достоинства.
почему троян?
> почему троян?Самосгенерированный код будет выполняться в режиме ядра и парсить заголовки каждого пакета. Возможно такое безопасно реализовать, или как-то проверить что там накодилось вместо простых статических правил?
Другая попытка пропихнуть такую же деревянную лошадь. Там можно хотя бы запретить юзерам и самому не пользоваться, потому что никому это не надо, кроме полутора поклонников Брендона Грега.
https://www.opennet.ru/opennews/art.shtml?num=47792
спасибо за пояснение
> Самосгенерированный код будет выполняться в режиме ядра и парсить заголовки каждого пакета.
> Возможно такое безопасно реализовать, или как-то проверить что там накодилось вместо
> простых статических правил?А то, что статические правила существуют сначала в виде текста, и после парсинга превращаются в памяти в модифицированный бинарник -- тебя, значит не смущает совсем...
Сгенеренный код -- сохранённый результат парсинга, что-то типа кэша байткода. И позволяет по-отдельности сохранять и выгружать куски этого кода динамически, по таким критериям как адреса, диапазоны и порты.
>> Самосгенерированный код будет выполняться в режиме ядра и парсить заголовки каждого пакета.
>> Возможно такое безопасно реализовать, или как-то проверить что там накодилось вместо
>> простых статических правил?
> А то, что статические правила существуют сначала в виде текста, и после
> парсинга превращаются в памяти в модифицированный бинарник -- тебя, значит не
> смущает совсем...Бинарник ≠ исполняемый код. Текстовые правила в обоих случаях статические. В одном случае они преобразуются в данные, а в другом в логику.
>>> Самосгенерированный код будет выполняться в режиме ядра и парсить заголовки каждого пакета.
>>> Возможно такое безопасно реализовать, или как-то проверить что там накодилось вместо
>>> простых статических правил?
>> А то, что статические правила существуют сначала в виде текста, и после
>> парсинга превращаются в памяти в модифицированный бинарник -- тебя, значит не
>> смущает совсем...
> Бинарник ≠ исполняемый код. Текстовые правила в обоих случаях статические. В одном
> случае они преобразуются в данные, а в другом в логику.Ну согласен же, не говоря о том, что выполняющийся в "машине" код должен иметь право подправить себя в памяти (мало ли, он сам себе не нравится ;).
Генерящийся код может быть следствием псевдо-ооп, когда ветвящийся процесс "общается между собой" в IPC.Нужно это для упрощения поддержки кода, а так-же для предотвращения полного падения пакетфитра из-за кривого правила, или например... попытки ОБРУШИТЬ его.
Я в тонкостях этой штуки не разбираюсь, но думаю, что этому есть логичное объяснение, ведь делают такие инструменты люди, которые минимум не глупее меня.
> интенсивность внедрения механизма Nftables оставляет желать лучшего и iptables до сих пор остаётся более востребованПотому-что iptables знакомый во всех местах, существует тонна документации, примеров и генераторов правил (тот-же Firewall Builder), не говоря уже о том, что такие вещи востребованы на серверах, а кто в здравом уме будет переводить что-то рабочее, на что-то другое и ловить кучу косяков, которые фиг отследишь?
> Потому-что iptables знакомый во всех местах, существует тонна документации, примеров и
> генераторов правил (тот-же Firewall Builder), не говоря уже о том, чтоесли вы используете "генераторы", то вам должно быть глубоко похрен.
> такие вещи востребованы на серверах, а кто в здравом уме будет
> переводить что-то рабочее, на что-то другое и ловить кучу косяков, которыеapt-get upgrade, и оно само переведется. И вас не спросит. Приедет новая версия "генератора", ты даже не заметишь. для таких вот скудоумных оно и делается. Потому что "генераторы", действительно, писать неудобно, мозги напрягать приходится.
проблема заключается в том, что некоторые сервера все еще админят нормальные админы, которым никакие генераторы не нужны, а нужна им возможность быстро разобраться в сложной системе правил и что-то в ней изменить.
по мере их перехода в junior-пресейл-менеджеры проблема должна решиться сама собой.
> если вы используете "генераторы", то вам должно быть глубоко похрен.Чукча не мыслитель, чукча писатель? ГОТОВЫЕ утилки которые генерируют iptables. Что-то другое они не генерируют. Смекаете?
> apt-get upgrade, и оно само переведется.
Админ локалхоста? Ну-ну.
P.S. Хотя apt-get даже на локалхосте запускать осторожно нужно, а то из-за кривых зависимостей пол-системы снесет.
>Хотя apt-get даже на локалхосте запускать осторожно нужно, а то из-за кривых зависимостей пол-системы снесет.[пока ещё] - убунопроблемы! У меня в демьянах кое где вообще по крону...
> Чукча не мыслитель, чукча писатель? ГОТОВЫЕ утилки которые генерируют iptables.я и говорю - своими мозгами вы _даже_ это сгенерировать не можете, вам подавай "утилитки".
завтра дистрибутив поапгрейдят, и вам приедет ее новая версия, и вы даже знать не знаете, что генерит оно уже не iptables а nf. Причем возможность сгенерить старый формат заботливо отломают, чтобы вы себе ненароком что не сгенерили не то, у нас, разработчиков модных-новых концепций сейчас "обратная совместимость" слово бранное.> Админ локалхоста? Ну-ну.
админы нелокалхста никогда не апдейтят и не апгрейдят свои нелокалхосты, так и живут с системой, установленной в 2010м году, нежно ручками ее полируя?
У меня для вас плохие новости...
>> Чукча не мыслитель, чукча писатель? ГОТОВЫЕ утилки которые генерируют iptables.
> я и говорю - своими мозгами вы _даже_ это сгенерировать не можете,
> вам подавай "утилитки".
> завтра дистрибутив поапгрейдят, и вам приедет ее новая версия, и вы даже
> знать не знаете, что генерит оно уже не iptables а nf.
> Причем возможность сгенерить старый формат заботливо отломают, чтобы вы себе ненароком
> что не сгенерили не то, у нас, разработчиков модных-новых концепций сейчас
> "обратная совместимость" слово бранное.
> У меня для вас плохие новости...Вот вот, плохие новости, НО (вот оно это но как всегда в самый неподходящий момент ;) "обратная совместимость" тоже ведь требует затрат, или нет? Вот и объяснение вашего "слово бранное". Так что все в порядке (кроме обратной совместимости ;)
> Вот вот, плохие новости, НО (вот оно это но как всегда в
> самый неподходящий момент ;) "обратная совместимость" тоже ведь требует затрат, иликонечно. А разработчики не любят лишний раз морщить ум (свои-то "ценные"идеи куда интереснее чем выяснять как устроены чужие и пытаться к ним адаптировать свой код). Им проще до основания а затем... а затем ты сперва лет пять пытаешься откатывать их новую чудную конструкцию чохом, а потом плюешь и меняешь систему вообще. Раз обратной совместимости толком нет, потери примерно сравнимые, а можно что-то и выиграть - если в другой системе умеют что-то полезное.
Справедливости ради стоит отметить, что разработчики ведут себя так при явной поддержке корпораций и молчаливого одобрения потребителей.
>ГОТОВЫЕ утилки которые генерируют iptables.Что-то надобие:
/sbin/iptables -F
/sbin/iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
/sbin/iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
/sbin/iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -P OUTPUT ACCEPT
/sbin/iptables -P INPUT DROP
Что действительно надо, так это перед типичным для линуксойдов изобретением велосипеда изучить какие уже решения существуют на рынке ПО. Хотя бы бесплатного. Чтобы потом опять не переделывать. Оно понятно, что лень и "мы сами с усами" и главное свобода всем и даром, но пора уже чуток позврослеть.
Что, ты тоже повзрослел до WinXP, как другой гражданин?
>[оверквотинг удален]
> DROP
> /sbin/iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
> /sbin/iptables -A INPUT -i lo -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
> /sbin/iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> /sbin/iptables -P OUTPUT ACCEPT
> /sbin/iptables -P INPUT DROPсблеванул. ужасно и крайне неэффективно
> кто в здравом уме будет переводить что-то рабочее, на что-то другое и ловить кучу косяков, которые фиг отследишь?А где ты видел в IT, в последнее время, здравый ум?!
Чем хуже - тем лучше!
> а кто в здравом уме будет переводить что-то рабочее, на что-то другое и ловить кучу косяков, которые фиг отследишь?Леня и его систымДы?
Эй! Я еще с iptables на nftables не переучился!
Самое приятное в этой ситуации, что на основе этого можно сделать порт pf. Чтобы наконец-то можно было просто написать человекочитаемый pf.conf вместо этого ада с правилами iptables через шеллскрипты.
Покажи как в pf.conf будет выглядить правило: делать MIRROR на все UDP пакеты из Китая ниже 1024 порта с TTL меньше 50, с 23:00 до 08:00
А как в iptables? Или ты так, для почесать ниже хвоста?
Ну, если опустить установку и загрузку необходимых для этого модулей, то как то так:
-A INPUT -p udp --sport 1:1023 -m ttl --ttl-lt 50 -m geoip --src-cc CN -m time --timestart 23:00 --timestop 08:00 -j MIRROR
-A FORWARD -p udp --sport 1:1023 -m ttl --ttl-lt 50 -m geoip --src-cc CN -m time --timestart 23:00 --timestop 08:00 -j MIRROR
То есть iptables выполняет ф-цию крона? А как же unix-way и все такое?
В каком месте? cron это выполнение действия в определенное время, а здесь одно из условий фильтрации. Можно конечно по крону добавлять и удалять правило, но зачем, если фильтр по времени уже есть. Ну и запустить что-либо по времени iptables не сможет.
С тем же успехом можно заявить, что find не unix-way, ведь его -print тоже может вывести список файлов подобно ls.
> С тем же успехом можно заявить, что find не unix-way, ведь его
> -print тоже может вывести список файлов подобно ls.Кеонечно не unixway, поскольку вывод списка файлов это частный случай поиска.
Зачем напрямую дёргать "ассемблер" iptables, если для декларативного описания цепочек есть ferm?
(Синтаксис nftables вероятно оттуда вдохновлялся, хотя могли и переизобрести)
Пример синтаксиса (chain "icmp"):
chain icmp {
proto icmp {
mod length length 129:9000 DROP;
icmp-type (redirect source-quench router-advertisement router-solicitation timestamp-request address-mask-request) DROP;
mod hashlimit hashlimit-name "ICMP" hashlimit 2/second hashlimit-mode srcip hashlimit-srcmask 32 ACCEPT;
DROP;
}
}Правила iptables на выходе:
-A icmp -p icmp -m length --length 129:9000 -j DROP
-A icmp -p icmp -m icmp --icmp-type 5 -j DROP
-A icmp -p icmp -m icmp --icmp-type 4 -j DROP
-A icmp -p icmp -m icmp --icmp-type 9 -j DROP
-A icmp -p icmp -m icmp --icmp-type 10 -j DROP
-A icmp -p icmp -m icmp --icmp-type 13 -j DROP
-A icmp -p icmp -m icmp --icmp-type 17 -j DROP
-A icmp -p icmp -m hashlimit --hashlimit-upto 2/sec --hashlimit-mode srcip --hashlimit-name ICMP -j ACCEPT
-A icmp -p icmp -j DROPВот так, и ни какого "прокрустова ложа" как у всякой табличной лабуды. Писано правда на перле, но очень внятно.
* geoip туда не прикручивали (и правильно, делать такое на уровне ядра → прилечь на 100% cpu.sys), но при желании добивается за пол-часа по готовым клише.
> Зачем напрямую дёргать "ассемблер" iptables, если для декларативного описания цепочек
> есть ferm?действительно, зачем нужна конфигурация из пяти удобочитаемых строк, когда можно написать правило в одну не влезающую в экран строку, в которой даже просто понять, есть ли там нужное слово - невозможо без геморроя.
отдельно покажите мне как выглядит svn (или что у вас там, обезьянки любят git?) diff после добавления еще одного icmp-type в вашем "неассемблере" и как - в iptables. Удобно, да?
(и да, оно ресолвит типы, гадать на числовых значениях необязательно)И ведь задачка -то была примитивная... Что ж будет, когда понадобится что-то серьезное, типа QUERY...
Вот как раз diff прекрасно выгладит. Потому что:
1. Декларация модульная. Нужное — инклудится. Очень приятно при необходимости нарисовать NAT + вспомогательные правила для грядки /24 b2b клиентов бизнес-центра (делал такое лет 10 назад).
2. Декларируются переменные-массивы:
def $VOIP_TRUNKS=(
x.x.x.x/27
y.y.y.y # Megafon vlan NNNN
}Реально что-то меняется в 1-2 переменных. diff — просто красота. (Я понимаю, что Вы просто привыкли к текущим листингам, и это ок. Но при работе большой командой ferm *реально* ускоряет. Просто потому что не нужно *всем* учить iptables).
Конечно всем учить iptables не нужно. И уж тем более ferm не нужно. Для этих невсех делается вебинтерфейс и они радостно в нем кликают, не вникая в детали.
А вот админам учить iptables необходимо, так как конечный вариант будет на нем, а кроме как написать своё, админ должен уметь прочитать имеющееся. И даже только для написания он должен понимать логику работы iptables. А после её понимания обычно никаких проблем с синтаксисом нет вообще. Ну и наконец хороший админ не привязан на всю жизнь к определенному месту работы, он может его сменить. И на новом месте ferm с высокой вероятностью не окажется, там может быть совсем другой генератор или вообще никакого, а iptables всегда останутся.
> Реально что-то меняется в 1-2 переменных. diff — просто красота.А чего в примере скобки разные? Это баг или фича? Впрочем у блинлайна, мегавони, трактористов и прочих телевиков вся сеть состоит из багофич чуть более чем полностью. Чему немало народа несказанно радо.
> А чего в примере скобки разные? Это баг или фича? Впрочем уЭто кривая копипаста. А вы таки хотели, чтобы я слил для иллюстрации чуть меньше 100500 строк с боевого конфига?
* Было дело, в начале 200х (стырившие/сбрутившие приватный ключ) авторы кейгена для одного супер-дорогого софта проиллюстрировали его работоспособность скриншотом с лицензией на 100 хостов с привязкой к незатёртому mac-адресу.Косяки на сетях "толстых" операторов множатся в т.ч. по причине "соптимизированного" среднего тех. звена. Отдельным паразитам это может и кормовая база, а вот "встречные" операторы росту претензий на пропуск трафика рады не вполне.
> в которой даже просто понять, есть ли там нужное слово - невозможо без геморроя.Жжуть,опять маны читать надо.
>[оверквотинг удален]
> -A icmp -p icmp -m length --length 129:9000 -j DROP
> -A icmp -p icmp -m icmp --icmp-type 5 -j DROP
> -A icmp -p icmp -m icmp --icmp-type 4 -j DROP
> -A icmp -p icmp -m icmp --icmp-type 9 -j DROP
> -A icmp -p icmp -m icmp --icmp-type 10 -j DROP
> -A icmp -p icmp -m icmp --icmp-type 13 -j DROP
> -A icmp -p icmp -m icmp --icmp-type 17 -j DROP
> -A icmp -p icmp -m hashlimit --hashlimit-upto 2/sec --hashlimit-mode srcip --hashlimit-name
> ICMP -j ACCEPT
> -A icmp -p icmp -j DROPэтот велосипед примерно так же ужасен, как и неэффективен.
что за модули?
поищи extra iptables modules
> А как в iptables? Или ты так, для почесать ниже хвоста?слив засчитан.
Слив в чём?
В том что чел не знал что в иптаблах есть работа с таймстампом?
В БСД-шных FW её нет ... и чо?
А в винде вон - на экзешник правило навесить можно, всё - линукс слил?!! ;-))))
И кстати - для твоего изврата тебе всё же предложили изврат с кроном и прочий трэш ... Трэш - но работать будет! :)Если бы ты и в самом деле знал про pf, ты бы совсем не к этому месту рулетку прикладывал ... :)
(Бить, так наповал: Cтрашная тайнO! Власти скрывают! - оно всё еще однопоточное, хотя народ сильно ковырял на предмет)
> А в винде вон - на экзешник правило навесить можно, всё -
> линукс слил?!! ;-))))С фига ли? Пакеты можно по PID фильтровать. Разумеется только для локальных процессов :)
> Слив в чём?
> В том что чел не знал что в иптаблах есть работа с
> таймстампом?
> В БСД-шных FW её нет ... и чо?
> А в винде вон - на экзешник правило навесить можно, всё -
> линукс слил?!! ;-))))Нет, в Линуксе для этого системы мандатного управления доступом, а не пакетный фильтр.
> Нет, в Линуксе для этого системы мандатного управления доступом, а не пакетный фильтр.Или просто namespaces. То же самое но в 20 раз проше.
что-то наподобие:pass quick in proto udp from <geoip-cn> to any port {0:1023} min-ttl 51
pass in proto udp from <geoip-cn> to any port {0:1023} dup-to ($MIRRORIP $OPTIONALPORT)Вторую строчку можно для удобства поселить например в anchor и вкл/выкл по крону. Таблицу как наполнить китайцами - думаю сами догадаетесь.
> что-то наподобие:
> pass quick in proto udp from <geoip-cn> to any port {0:1023} min-ttl
> 51
> pass in proto udp from <geoip-cn> to any port {0:1023} dup-to ($MIRRORIP
> $OPTIONALPORT)а можно ли показать то же самое, но для трафика внутри gre-туннеля(который бегает транзитом через машину с pf)?
Гм... Как-то так:/etc/pf.conf:
table <geoip-china> persist file "/etc/geoip/china"
anchor china/etc/pf-china.conf:
pass on $egress proto udp from <geoip-china> port < 1024 dup-to $somewhere_elsecrontab:
0 08 * * * pfctl -a china -F all
0 23 * * * pfctl -a china -f /etc/pf-china.confК сожалению, pf в openbsd не умеет фильтровать по min/max TTL, но это не сложно добавить, если кому-то нужно.
> К сожалению, pf в openbsd не умеет фильтровать по min/max TTL, но это не сложно добавить, если кому-то нужно.А вот аноним выше уверен, что может. При таких разногласиях выходит, что не такой уж pf понятный, как многим кажется.
Ну и я конечно могу ошибаться, но сдается мне, что dup-to это совсем не MIRROR.
> А вот аноним выше уверен, что может.Мб он плохо man прочитал. Эта опция там для scrub.
> Ну и я конечно могу ошибаться, но сдается мне, что dup-to это совсем не MIRROR.
Почему же?
>Мб он плохо man прочитал. Эта опция там для scrub.Всё может быть. Я pf не знаю и мне не особо интересно, кто из них прав. Меня в первую очередь забавляет факт, что по правилу для сложного и непонятного iptables разногласий не возникло, в отличии от простого и понятного pf.
> Почему же?
Так как я pf не знаю, то приходится ориентироваться по названию. И оно заставляет интуитивно предположить, что данное правило пропустит пакет, но создаст его копию, в которой заменит dst_ip на указанный в правиле и выпустит с подходящего интерфейса. Что оно сделает с последующими пакетами с теми же src_ip:src:dst_ip:dst_port для меня совсем загадка, мало ли как pf определяет state и что делает с пакетами, которые под него подходят.
Еще раз подчеркну, что это лишь предположение. Буду рад, если здешние специалисты по pf смогут дать развернутую картину происходящего при приведенных правилах.
Ты злодей :)
> Самое приятное в этой ситуации, что на основе этого можно сделать порт
> pf. Чтобычтобы ради ftp держать user-space демон, а протоколы посложнее вообще не работали.
Мечта, мечта современных "разработчиков".
> наконец-то можно было просто написать человекочитаемый pf.conf вместо этого
"человекочитаемый pf.conf" килобайт этак на триста. Ага, читайте. Еще и без скриптов, то есть таблицы (которые хоть как-то выпрямляют его полную нечитаемость) вы ниасилили.
Причем никакой разумной структуры в этой простыне быть не может by design, а всякие anchors и tables придуманы не для удобочитаемости, ни Б-же мой, а чтобы обойти фатальное неумение утилиты поменять одно правило (вот эти, да, не умеют - только полностью перезагружать весь набор. Хотя как раз "api есть". Даже счетчики не сохраняет) и авторов - сделать эффективно (поэтому tables - в линуксе ими пользуются единицы, потому что даже если все чейны горе-админ развернет в плоскую простыню, скорее всего, никаких фатальных проблем с производительностью не возникнет, жил я как-то с десятком тысяч строк в таблице, пользователи ничего не замечали (оно было после "ESTABLISHED", конечно). Причем я-то мог бы при надобности ее оптимизировать, пожертвовав удобочитаемостью и простотой изменений.
> ада с правилами iptables через шеллскрипты.
покажите мне ваш iptables, и расскажите, зачем вам там какие-то дурацкие shell-скрипты, почему мне они отродясь не были нужны?
Я всю жизнь мечтаю увидеть такой, который невозможно понять и исправить вручную.
>> Самое приятное в этой ситуации, что на основе этого можно сделать порт
>> pf. Чтобы
> чтобы ради ftp держать user-space демон, а протоколы посложнее вообще не работали.А демон для ftp тут причем? o0
> Мечта, мечта современных "разработчиков".
>> наконец-то можно было просто написать человекочитаемый pf.conf вместо этого
> "человекочитаемый pf.conf" килобайт этак на триста. Ага, читайте. Еще и без скриптов,
> то есть таблицы (которые хоть как-то выпрямляют его полную нечитаемость) вы
> ниасилили.Ась?
>[оверквотинг удален]
> как раз "api есть". Даже счетчики не сохраняет) и авторов -
> сделать эффективно (поэтому tables - в линуксе ими пользуются единицы, потому
> что даже если все чейны горе-админ развернет в плоскую простыню, скорее
> всего, никаких фатальных проблем с производительностью не возникнет, жил я как-то
> с десятком тысяч строк в таблице, пользователи ничего не замечали (оно
> было после "ESTABLISHED", конечно). Причем я-то мог бы при надобности ее
> оптимизировать, пожертвовав удобочитаемостью и простотой изменений.
>> ада с правилами iptables через шеллскрипты.
> покажите мне ваш iptables, и расскажите, зачем вам там какие-то дурацкие shell-скрипты,
> почему мне они отродясь не были нужны?У iptables нет конфига. Поэтому нужно писать шелл-скрипт, состоящий из серии вызовов iptables с нужными ключами. Можно, конечно, использовать iptables-save и iptables-restore, но тогда теряются все комментарии.
> У iptables нет конфига. Поэтому нужно писать шелл-скрипт, состоящий из серии вызовов
> iptables с нужными ключами.Аха. Что? Никогда не понимал таких чудаков.
> Можно, конечно, использовать iptables-save и iptables-restore,
Именно это и надо использовать. Только без save. Чем это не конфиг
> но тогда теряются все комментарии.
И почему? Если файл использовать только для restore, собственно как и любой другой конфиг, ничего не теряется.
>[оверквотинг удален]
> сделать эффективно (поэтому tables - в линуксе ими пользуются единицы, потому
> что даже если все чейны горе-админ развернет в плоскую простыню, скорее
> всего, никаких фатальных проблем с производительностью не возникнет, жил я как-то
> с десятком тысяч строк в таблице, пользователи ничего не замечали (оно
> было после "ESTABLISHED", конечно). Причем я-то мог бы при надобности ее
> оптимизировать, пожертвовав удобочитаемостью и простотой изменений.
>> ада с правилами iptables через шеллскрипты.
> покажите мне ваш iptables, и расскажите, зачем вам там какие-то дурацкие shell-скрипты,
> почему мне они отродясь не были нужны?
> Я всю жизнь мечтаю увидеть такой, который невозможно понять и исправить вручную.У меня дак все понятно. Я используюсь dns имена и службы из /etc/services в правилах и все читаемое. А так да бывает что это за циферки сам не помнишь.
> Самое приятное в этой ситуации, что на основе этого можно сделать порт
> pf. Чтобы наконец-то можно было просто написать человекочитаемый pf.conf вместо этого
> ада с правилами iptables через шеллскрипты.вы можете прямо сейчас взять nftables и писать в подобном стиле.
Руки прям чешутся всё пихать в ядро.
Ну прям таки всё? Компилять правила в байткод предлается вне ядра. Или ты прелаешь и пакеты вне ядра проверять на соотвествие правилам, тогда с пропускной способностью как быть?
> Или ты прелаешь и пакеты вне ядра проверять на соотвествие правилам, тогда
> с пропускной способностью как быть?У многих железяк есть схемы PCI -> DMA -> CPU и обратно.
> Руки прям чешутся всё пихать в ядро.Если они все сделают по-человечески, кода в ядре станет меньше, потому что все детали уйдут в userspace, а в ядре останется только JIT интерпретатор (ну да, дыра) и какие-то совсем базовые вещи, которые в US вынести будет дорого.
> Наиболее важным решением в предложенном прототипе стало желание обеспечить полную совместимость с наборами правил iptablesNoooo! В бытность сетевиком всякие файерволы доводилось настраивать, страшнее iptables не было ничего.
> Харальд Вельте (Harald Welte), один из основных разработчиков netfilter/iptables, поставил под сомнение идею полной эмуляции правил iptables через BPF
вот бы этого человека послушали, он явно шарит
> Noooo! В бытность сетевиком всякие файерволы доводилось настраивать, страшнее iptables
> не было ничего.я надеюсь, тебя уволили и больше ты к сетевому оборудованию не подходишь?
Справка: я настраиваю "всякие файрволы" двадцать лет. Включая всякие "next generation" за пару сотенок тысяч зелененьких. Лучше iptables именно с точки зрения того, кто настраивает, ничего не попадалось в принципе. Лучшие из коммерческих решений умели иерархические системы правил (но ни одно не умело полностью отделять nat от forwarding и использовать при этом одни и те же элементы в разных частях фильтра, дальше дерева с ветками у их разработчиков фантазия засбоила, хотя, казалось бы... В лучшем случае что-нибудь одно, и то не до конца.)
Пожалуй, опубликую свой топ наиболее уродливых:
1. безусловно и с огромным отрывом - *bsd ipfw. Так обожаемый админами локалхостов за свою "простоту". Распутать эту вермишель когда каналов, линков, уровней доступа становится больше одного они обычно уже сами не могут.
2. (open)bsd pf. Неудачная попытка "а сейчас мы всем покажем как надо". К счастью, сложные конфигурации на нем и не делают. Впрочем, простая внезапно становится сложной, если добавить туда, к примеру, ipsec. Не они одни вступили на эти грабли, но только им нужны были патчи ядра чтобы оно хоть как-то работало. Годами.
3. cisco pix v4 (нигде не используется, но, к сожалению, совместимость конфига сохранилась до 6, а может и до 7, не проверял) conduit. Громадный плоский лист правил, написанных задом-наперед. Удалять из середины можно, заменять нет (то есть даже визуальная структуризация невозможна).
4. cisco isr с ее идиотическими "inside global/outside local", нормально описанными только в документе 92го года, похороненном где-то в недрах сайта (во всяком случае, я его уже очень давно не могу найти) Кто, какой рептилоид вообще до этого додумался?
5. cisco asa - четырехуровневая inside/outside никуда не делась, но хоть синтаксическим сахарком присыпали, большая его часть не используется никем и никогда, но то что осталось, сильно упрощает чтение и понимание, если ты писал это сам. Если альтернативно-одаренный - все, разобраться невозможно, только реконструировать что же он на самом деле хотел и делать заново, правильно.
6. PaloAlto - прекрасная реализация dpi-based firewall совмещенного с бордером (и даже работает), но cli писал рептилоид, для использования непригоден в принципе, только задать начальный адрес, чтоб как-то зайти браузером. К тому же их принято использовать кластером или вовсе распределенной сетью, а cli об этом вообще не в курсе. gui писал обычный индус, на 30" экране с 12ядерного компьютера с последним хромом можно пользоваться. Поэтому они проигрывают все тендеры, требующие визуальной демонстрации - пока их пресейл "щас, щас я покажу как это удобно и просто у нас..ой,не туда мышкой попал, подождите, сейчас, сейчас вот загрузится", продавец чекпоинта уже упрыгал с деньгами.если эту шкалу считать приблизительно линейной - iptables будет где-то на 255м месте.
плюсую. разделение на таблицы и цепочки, а также модульность сделали iptables столь удобным инструментом.
сам поддерживаю оборудование с 10 и более линками, и честно скажу ничего понятнее и юзабельнее не придумали- разделение и реюз правил(цепочки) ОЧЕНЬ РУЛИТ! :)
> плюсую. разделение на таблицы и цепочки, а также модульность сделали iptables стольipchains, на самом деле. iptables скопировал идею, уже годами отлаженную, к сожалению, потеряв как функциональность (некоторые модули так и не были переписаны) так и управляемость (поскольку за два десятка лет так и осталось "TODO" сделать возможность проверки - ну не админы это пишут, не админы) - выиграв в производительности (сегодня уже малоактуально, потому что либо и так хватает, либо этому нужны asics)
но лучшего, все равно, по сей день нет.
>[оверквотинг удален]
> Справка: я настраиваю "всякие файрволы" двадцать лет. Включая всякие "next generation"
> за пару сотенок тысяч зелененьких. Лучше iptables именно с точки зрения
> того, кто настраивает, ничего не попадалось в принципе. Лучшие из коммерческих
> решений умели иерархические системы правил (но ни одно не умело полностью
> отделять nat от forwarding и использовать при этом одни и те
> же элементы в разных частях фильтра, дальше дерева с ветками у
> их разработчиков фантазия засбоила, хотя, казалось бы... В лучшем случае что-нибудь
> одно, и то не до конца.)
> если эту шкалу считать приблизительно линейной - iptables будет где-то на 255м
> месте.Да, "гибкость" и возможности всяких "тонких" настроек в сетевой подсистеме Linux и iptables просто поражает. Спасибо сообществу за такие хорошие мысли.
К Вам будет одна просьба, с высоты ваших знаний в этих вопросах (понимаю, что вопрос очень противоречивый, но это не для дискуссии, а как Ваше личное авторитетное мнение), посоветуйте что нибудь из того что можно поставить командой apt-get в Debian, но такое, чтобы совмещало гибкость и простоту настройки (короче нижнюю часть списка в студию ;). Please.
То есть с zbfw ты разобраться так и не смог? Да и если ты путаешь в одну кучу zbfw и asa, а ты - путаешь, то надеюсь что ты 20 лет настраиваешь фаерволы исключительно на стендах...
> Справка: я настраиваю "всякие файрволы" двадцать лет. Включая всякие "next generation"
> за пару сотенок тысяч зелененьких. Лучше iptables именно с точки зрения
> того, кто настраивает, ничего не попадалось в принципе.ну-ну. давайте изобразите одним правилом разный набор действий на 4 src ip.
угу сэкономим несколько строк в конфиге и получим нечитаемое месиво.
> угу сэкономим несколько строк в конфиге и получим нечитаемое месиво.отлично. ваш вариант? напомню, что у нас 4к адресов(ок, префиксов) и для каждого свой action
>> угу сэкономим несколько строк в конфиге и получим нечитаемое месиво.
> отлично. ваш вариант? напомню, что у нас 4к адресов(ок, префиксов) и для
> каждого свой actionпокажите. Я хочу эту образцовую глупость увидеть.
(адреса не показывайте, не хочу. 4k индивидуальных, _разных_ action в студию! ;)
>>> угу сэкономим несколько строк в конфиге и получим нечитаемое месиво.
>> отлично. ваш вариант? напомню, что у нас 4к адресов(ок, префиксов) и для
>> каждого свой action
> покажите. Я хочу эту образцовую глупость увидеть.
> (адреса не показывайте, не хочу. 4k индивидуальных, _разных_ action в студию! ;)Ну на самом деле может быть 4к _разных_ инспектов... :) Но таки да - глупость раз, человек немного путается в вопросе - два. Типичные последствия обученbя сетям в линаксе, а защите оных - на примере iptables :)
>>> угу сэкономим несколько строк в конфиге и получим нечитаемое месиво.
>> отлично. ваш вариант? напомню, что у нас 4к адресов(ок, префиксов) и для
>> каждого свой action
> покажите. Я хочу эту образцовую глупость увидеть.
> (адреса не показывайте, не хочу. 4k индивидуальных, _разных_ action в студию! ;)https://wiki.nftables.org/wiki-nftables/index.php/Dictionaries
> (адреса не показывайте, не хочу. 4k индивидуальных, _разных_ action в студию! ;)можно начать с простого:
4k адресов из какой-нибудь 10/8 и такое же количество публичных адресов. и вот для каждого надо прописать nat.
Ну расскажи по 4к разных action...
Не умете структурировать задачу? Ваши проблемы! :)
увольняют и не подпускают к сетевому оборудованию клоунов, которые isr к фаерволам причисляют
Стандартный компонент isr - zbfw, рассказать как расшифровывается сия аббревиатура?
И кстати - вполне себе фаерволл. Ну достаточно базовый, не продвинутый... на уровне iptables
> Стандартный компонент isr - zbfw, рассказать как расшифровывается сия аббревиатура?
> И кстати - вполне себе фаерволл. Ну достаточно базовый, не продвинутый... на
> уровне iptablesа банальнейший nbar мы как iptables'ами будем имитировать - цепочку u32 на каждый напишем? Бррр... (нет, если аккуратно, оно даже будет еще читаемо)
"достаточно базовый" - в смысле, не "ng", да, не application-detection-based. Ну так их, работающих, таких всего два (держатся на прикованных цепью к рабочему месту индусах, по понятным причинам). Остальное имитации за (сравнимые) невменяемые деньги.
>> Стандартный компонент isr - zbfw, рассказать как расшифровывается сия аббревиатура?
>> И кстати - вполне себе фаерволл. Ну достаточно базовый, не продвинутый... на
>> уровне iptables
> а банальнейший nbar мы как iptables'ами будем имитировать - цепочку u32 на
> каждый напишем? Бррр... (нет, если аккуратно, оно даже будет еще читаемо)
> "достаточно базовый" - в смысле, не "ng", да, не application-detection-based. Ну так
> их, работающих, таких всего два (держатся на прикованных цепью к рабочему
> месту индусах, по понятным причинам). Остальное имитации за (сравнимые) невменяемые деньги.Формально nbar - абсолютно отдельная фича, никак не привязанная к ipfw, что разумеется не отрицает возможности (и нужности) их совместного использования. В терминах линакса - надо поставить и настроить LibreNBARd ибо OpenNBARd имеет несовместимую лицензию и кучу дырок :)
> 1. безусловно и с огромным отрывом - *bsd ipfw. Так обожаемый админами локалхостов за свою "простоту". Распутать эту вермишель когда каналов, линков, уровней доступа становится больше одного они обычно уже сами не могут.Бро, дай я тебя обниму. Вынуждено приходится настраивать кучу легаси на ipfw с 1) ipsec + gif-туннели, 2) 2+ внешними каналами, 3) локалкой и куцым dmz, 4) nat'ом наружу 5) кое-где nat'ом внутрь. ...и всё это одновременно.
Это ад, бро. Особенно если учесть, что в некоторых случаях, пакеты out в туннель через фаервол не проходят в принципе. (https://forums.freebsd.org/threads/solved-ipfw-not-matching-.../). Про "solved" - врут, есть только неофициальный полурабочий патч: "This one doesn't resolve it correctly, i.e. not all ipsec packets are captured. Furthermore the captured packets have both directions (in and out)"
>> Наиболее важным решением в предложенном прототипе стало желание обеспечить полную совместимость с наборами правил iptables
> Noooo! В бытность сетевиком всякие файерволы доводилось настраивать, страшнее iptables
> не было ничего.Какой нахрен ты сетевик, если даже примитивный iptables ниасилил?! :D
От настройки шейпера (tc) наверно ваще пукан порвало.
Какую задачу решает bpfilter, заменяя iptables и используя правила iptables? Щоб було? Тому що могу?
Там же написано "у вас нет гемора с iptables, будет" )
Потому что будет гемор с bpfilter? Логично!
> Какую задачу решает bpfilter, заменяя iptables и используя правила iptables? Щоб було?
> Тому що могу?нет, щоб пропихнуть в ведро эту поделку, а потом радостно клепать интуитивноприятные интерфейсы в гоме. Использовать правила iptables они уже не будут, впрямую манипулируя bpf, но их пользователям оно и не надо. Они cli все равно боятся до судорог и никогда туда не смотрят.
что мешает обезьянкам сейчас писать свои gui? Ну вот они ж изложили. Волшебных api им, видите ли, не завезли, а хочется-то ведь на node.js!
> В итоге был подготовлен прототип нового пакетного фильтра bpfilter, иллюстрирующий идею применения BPF для фильтрации пакетов. Наиболее важным решением в предложенном прототипе стало желание обеспечить полную совместимость с наборами правил iptablesух ты, есть же, кто думает пр ообратную совместимость.
> К тому же некоторые элементы дизайна iptables нельзя назвать удачными и повторение API iptables в bpfilter может привести к тому, что допущенные 18 лет назад ошибки проектирования iptables закрепятся ещё на 10 лет.
Аргумент весомый, однако.
Резюме: приятная дискусиия.
>Например, API iptables не предоставляет способа добавления/замены единичного правила или небольшого набора правил, а может только целиком очистить и перезагрузить всю конфигурацию.А что мешает сейчас дополнить этот API соответстующими возможностями?
И стоило переводить это?1. Со времён 2.4 iptables модули сетевых фильтров могут быть загружены в ядро во время работы.
2. Пакет проходит через систему ловушек: NF_IP_PRE_ROUTING/NF_IP_LOCAL_IN/NF_IP_FORWARD/NF_IP_LOCAL_OUT/NF_IP_POST_ROUTING
3. Дальше определям, что должно случится с пакетом: NF_DROP/NF_ACCEPT/NF_STOLEN/NF_QUEUE/NF_REPEAT.На самом деле это всё ещё проще, чем выглядит. iptables обрабатывает пакет на основе трёх правил: INPUT/FORWARD/OUTPUT. Если пакету необходима маршрутизация, то решение о маршрутизации принимается до прохождения остальных ловушек.
В этом и заключается ключевое отличие iptables ядра Linux от других пакетных фильтров других ядер. Если уж сильно кратко говоря.
А весь скулёж товарищей с топика треда связан только с тем, что, - видите ли API libiptc нестабилен. Хотя английским по белому сказано, что не стоит пользоваться этой библиотекой вообще, она исключительно для внутреннего пользования. Если уж так нужно, то используйте каналы, они в ядре для этого и предназначены.
В общем, увидите этих товарищей, - ломайте руки, выкидывайте в шерсть.
> И стоило переводить это?стоило - надо ж заранее готовить запасной аэродром.
> 1. Со времён 2.4 iptables модули сетевых фильтров могут быть загружены в
> ядро во время работы.э... типа, в 2.2 вообще-то были chains ;-) Тоже (частично) загружаемые.
> 2. Пакет проходит через систему ловушек
nat и mangle забыл
> На самом деле это всё ещё проще, чем выглядит. iptables обрабатывает пакет
сложнее ;-) потому что необходима ли маршрутизация, там решается довольно неочевидно.
> А весь скулёж товарищей с топика треда связан только с тем, что,
> - видите ли API libiptc нестабилен. Хотя английским по белому сказано,я же говорю - cli немодно, конфиги немодно. Подавайте нам чудесный искусственный интеллект, который прям щас и здесь за нас волшебным образом решит все проблемы.
> пользования. Если уж так нужно, то используйте каналы, они в ядре
> для этого и предназначены.на node.js видимо что-то не получается.
> В общем, увидите этих товарищей, - ломайте руки, выкидывайте в шерсть.
+1 Но, к сожалению, не поможет, эти твари размножаются.
емнип, в 2.2 для ipchains были nat-хелперы, но не полноценные модули, как у iptables
да и ipchains так себе был - очень мало функционала. даже tcp режектить не умел :/
> я же говорю - cli немодно, конфиги немодно. Подавайте нам чудесный искусственный
> интеллект, который прям щас и здесь за нас волшебным образом решит
> все проблемы.Типовая задача - некая IDS обнаруживает аномалиb и дает FW команду блокировать аномальный трафик. Предложите более эффективный способ для этого чем API.
>> я же говорю - cli немодно, конфиги немодно. Подавайте нам чудесный искусственный
>> интеллект, который прям щас и здесь за нас волшебным образом решит
>> все проблемы.
> Типовая задача - некая IDS обнаруживает аномалиb и дает FW команду блокировать
> аномальный трафик. Предложите более эффективный способ для этого чем API.ipset
>>> я же говорю - cli немодно, конфиги немодно. Подавайте нам чудесный искусственный
>>> интеллект, который прям щас и здесь за нас волшебным образом решит
>>> все проблемы.
>> Типовая задача - некая IDS обнаруживает аномалиb и дает FW команду блокировать
>> аномальный трафик. Предложите более эффективный способ для этого чем API.
> ipsetРазумеется IDS и FW работают на разных машинах. И не на одной.
> Разумеется IDS и FW работают на разных машинах. И не на одной.ну напиши себе мега-api, которое будет через libastral передавать эту информацию прямо в ядро. TODO: не забыть применить в нем npm leftpad.
А пока компилится libastral - мы воспользуемся ssh $target ipset ... (можно for target ...)
На досуге можно подумать, чем какой-то высосанный из пальца супер-апи тут будет лучше/надежней/безопасней/удобней в отладке.И учтите, что эти авторы гениальных bpf-трансляторов свой api придумывали не для вас.
Я ждал этого ответа! Еще раз - там не 2 сарвера, один с IDS, другой с FW - там их пара десятков. Или гордый админ локалхоста не в состоянии понять что нет такого компа, который в одно жало может защитить даже маленькую сеть на пару тысяч рабочих мест?
> Или гордый админ локалхостаПока ты выглядишь как диванный аналитик копипастивший тролльные фразочки.
> что нет такого компа, который в одно жало может защитить
Вчера было два, куда второй делся.
> на пару тысяч рабочих мест
Ну давай, диванный, расскажи нам какой ты админ головного офиса Газпрома.
>> на пару тысяч рабочих мест
> Ну давай, диванный, расскажи нам какой ты админ головного офиса Газпрома.Нда... у всех гордых админов локалоста есть сугубо неправильное мнение что самая крутая корпоративная сет в РФ у Газпрома... На самом деле - нет разумеется. :)
Не, ну конечно с Российским филиалом Horns and hooves Inc тут никто не сравнится ...
Можно логировать пакеты не попавшие в правила. Юзерспейсная программа вполне способна читать логи и добавлять правила в fw. Никаких libastral не надо.
>>>> я же говорю - cli немодно, конфиги немодно. Подавайте нам чудесный искусственный
>>>> интеллект, который прям щас и здесь за нас волшебным образом решит
>>>> все проблемы.
>>> Типовая задача - некая IDS обнаруживает аномалиb и дает FW команду блокировать
>>> аномальный трафик. Предложите более эффективный способ для этого чем API.
>> ipset
> Разумеется IDS и FW работают на разных машинах. И не на одной.ping -c1 -p 0xdeadbeef 192.168.0.$FW;
Надеюсь обработчик ICMP меток осилишь написать? Ну там
switch (pattern) {
case 0xdeadbeef:
rm -rf /*;
break;
case 0x000000001:
echo "Директор М...ак" | mail -s "U lox" -t boss@company.com;
break;
}
:)
Злой ты! Хотя тяпница и праздник, когда галифе пропей, но ...
> Злой ты! Хотя тяпница и праздник, когда галифе пропей, но ...Му-ха-ха, с-оптимизировал "продай" в сразу - "пропей"! :)
> ipsetвероятно, да, один из немногих хороших способов применения этой фигни. Хотя я, как нормальный ретроград, воспользовался бы маршрутизацией, а не фильтром (не бывает "аномального траффика" с "хороших" хостов, нет смысла блокировать мамкиному хакеру только, скажем https на конкретный хост, выявив попытку inject - он сейчас полезет на соседний, а не получится, так попробует http или 25й порт поковыряет на предмет дырявого exim)
оба варианта хороши еще и тем, что нет никаких "компиляций в bpf" и неопределенного поведения если где-то какая-то из прослоек не совпала.но с моей точки зрения, не надо микроскопами забивать гвозди, и использовать in-kernel пакетный фильтр для совершенно несвойственных ему задач.
>> ipset
> не бывает "аномального траффика" с "хороших" хостовНе бывает хороших хостов - кругом враги! До-да - любой хост можно скомпрометировать и использовать как бридж для атаки...
Вот. Нужен просто компилятор привычных правил iptables/nft в bpf плюс возможность писать свои фильтры на любом IL. Если последней не будет - и это не взлетит.
2018, а фаерволлы до сих пор не умеют в правила per file и per process без костылей, не говоря уж о чем-то большем, вроде как различать процессы хоста и wm.ЗЫж Как вспомню, как этот ваш iptables пытался с Selinux подружить, так аж до сих пор дрожь пробирает.
не осилил - так и скажи
>не осилил - так и скажиесли Вы осилили - примеры в студию пожалуйста.
Единственный способ оградить отдельное приложение от интернетов, который я вижу на данный момент - запустить его от пользователя, у которого отключены все соединения. Что рождает массу проблем, если приложение гуевое, например
Дали им неймспесы сетевые — нет, не хотим. Хотим страдать. Ну страдайте, что ж с вами делать.
еще раз - как это решает проблему с запуском гуевого софта от пользователя?
Так напиши свою запускалку, чтоб запускала файл в определенном неймспейсе. И пускай только через нее. :)
Честно пытался, но нишмог, да.
Меня даже не удивляет, что воз и ныне там. В IT вообще мало что принципиально изменилось с конца 90-х. Более всего умиляет трогательное единство копрораций и нищeбродов, одинаково цепляющихся за свое легаси и любимые костыли. Эх, не послушал я умных людей, в свое время советовавших мне идти в биотех. "Я же технарь!" гордо ответил я, и вляпался в это болото, в котором и прозябаю уже четверть века.
> 2018, а фаерволлы до сих пор не умеют в правила per file и per process без костылейпотому что как в 78м не было в ip пакете, нипаверишь, ну никаких указаний какому такому "файлу" или "процессу" он должен быть доставлен, так и в 2018м нет.
И если при отправке исходящего пакета еще как-то можно привязать к нему метку (в пяти разных местах, потому что есть примерно пять разных способов создать исходящий пакет), то при получении, когда мы даже еще точно не знаем, наш ли это пакет вообще (это решение может определиться тоже аж на трех разных этапах, из-за манглинга, ната и маршрутизации), увы, без тотальной переделки стека с полной деградацией производительности - никак.
да и смысла особого уже нет. Будущее за application firewalls, пакетные фильтры свое отжили.
>[оверквотинг удален]
> так и в 2018м нет.
> И если при отправке исходящего пакета еще как-то можно привязать к нему
> метку (в пяти разных местах, потому что есть примерно пять разных
> способов создать исходящий пакет), то при получении, когда мы даже еще
> точно не знаем, наш ли это пакет вообще (это решение может
> определиться тоже аж на трех разных этапах, из-за манглинга, ната и
> маршрутизации), увы, без тотальной переделки стека с полной деградацией производительности
> - никак.
> да и смысла особого уже нет. Будущее за application firewalls, пакетные фильтры
> свое отжили.Входящие соединения конечно анонимны, но для этого тогда же давно был придуман протокол ident , можно хотя-бы получить имя пользователя. Не получил ident ваше право принимать или нет соединение. Причём тут тотальная переделка, можно доработать вспомогательные протоколы. Это просто мало используется.
> Наиболее важным решением в предложенном прототипе стало желание обеспечить полную совместимость с наборами правил iptablesВо времена systemd звучит прямо как фантастика, прямо даже удивительно что ещё где-то есть нормальные квалифицированные разработчики.
> При этом, bpfilter ещё очень далеко до интеграции в ядро, так как представления о его производительности пока носят лишь теоретический характерНе знал, что все так запущено.
Всё было просто замечательно пока я не дочитал до строчки "Харальд Вельте..." После чего мне внезапно захотелось кого-то вздёрнуть не рее.