В экспериментальную ветку linux-next, на базе которой будет формироваться ядро Linux 3.13, принят (http://marc.info/?l=linux-netdev&m=138203780210029&w=4) код Nftables (http://netfilter.org/projects/nftables/), новой реализации пакетного фильтра, идущего на смену iptables. Nftables отличается существенным пересмотром организации процесса обработки правил фильтрации пакетов, новым синтаксисом правил, унификацией интерфейсов iptables/ip6tables/arptables/ebtables и сокращением кода, выполняемого на уровне ядра.Ключевой особенностью Nftables является идеи близкой к реализации в BPF (Berkeley Packet Filters) - правила фильтрации компилируются в пространстве пользователя в байткод и передаются в ядро через API Netlink, после чего выполняются с использованием конечного автомата (pseudo-state machine) для принятия решения по дальнейшим действиям с пакетом. В качестве базовых блоков по-прежнему используются компоненты инфраструктуры Netfilter, в том числе существующие хуки, система отслеживания состояния соединений, компоненты организации очередей обработки и подсистема ведения лога.
Выполнение правил с использованием конечного автомата вместо применения логики сопоставления позволяет сократить размер кода фильтрации, работающего на уровне ядра и вынести все функции разбора правил и логики работы с протоколами в пространство пользователя. Кроме того, появляется возможность унифицировать работу с различными видами протоколов в едином наборе псевдокода, без необходимости поддержания в ядре отдельных расширений фильтрации для IPv4, IPv6, ARP и сетевых мостов. При необходимости поддержки фильтрации нового протокола, все изменения могут быть внесены на уровне пользователя без обновления кода ядра.
Все операции по определению условий и связанных с ними действий выполняются на уровне пользователя, в ядре производится только базовый набор операций, таких как чтение данных из пакета, сравнение данных и т.п. Присутствует поддержка словарного маппинга и поиска по наборам правил (sets), работа которых реализована через хеши и rb-деревья. При этом элементы наборов могут быть заданы в виде диапазонов значений (можно определять подсети).Для взаимодействия с кодом, работающим на уровне ядра, предлагается специальная связующая интерфейсная библиотека libnl, и построенный поверх неё фронтэнд, работающий на уровне пользователя. Для формирования правил фильтрации в nftables подготовлена утилита nft, которая проверяет корректность правил и транслирует их в байткод. Правила могут добавляться не только инкрементально, но и загружаться целиком из файла на диске.
Новый синтаксис правил (https://home.regit.org/netfilter-en/nftables-quick-howto/) в корне не похож на iptables и отличается использованием иерархических блочных структур вместо линейной схемы. Язык классификации правил основан на реальной грамматике, при обработке которой используется сгенерированный в bison парсер. Для обеспечения обратной совместимости с линейными правилами предоставляется специальная прослойка, позволяющая использовать iptables/ip6tables поверх инфраструктуры Nftables. Тем не менее, представленный для ядра 3.13 код, предусматривает сосуществование старой и новой подсистем, так как Nftables ещё требует доработки и тестирования.
Пример правил:
<font color="#461b7e">
table filter {
chain input {
table filter hook input priority 0;
ct state established accept
ct state related accept
meta iif lo accept
tcp dport ssh counter packets 0 bytes 0 accept
counter packets 5 bytes 5 log drop
}chain output {
table filter hook output priority 0;
ct state established accept
ct state related accept
meta oif lo accept
ct state new counter packets 0 bytes 0 accept
}
}</font>
URL: http://lwn.net/Articles/570921/rss
Новость: http://www.opennet.me/opennews/art.shtml?num=38209
А я ожидаю, что в 3.13-ом ядре будет из коробки работать подсветка в моём ноутбуке.
Оформил багу на ихней багзилле. Отметил, что с параметром acpi=off регулировка работает (в т.ч. числе горячими клавишами).
Жду.
Завидую тем, которые на багзилле получали фикс на следующий же день.
https://bugzilla.kernel.org/show_bug.cgi?id=62941
Попробуй добавить параметр acpi_osi="!Windows 2012"
Это не шутка!
Ох, я столько уже мучался с этим, что и забыл, что в первый раз это может выглядеть как глупая шутка.Суть в том, что ядро при загрузке вызывает (не знаю, как метод называется, пусть будет) метод _OSI из таблиц ACPI сообщая, что оно понимает все версии Windows и Linux. А тот параметр говорит ядру не сообщать firmware, что оно "совместимо" с Windows 8. В Windows 8 драйверы сами управляют подсветкой и код из таблиц ACPI не вызывается. Производители его не тестируют и поэтому код в ветках поддержки Windows 8 часто бажный. А вот Linux честно его вызывает, что у меня на системе приводит к зависаниям. acpi_osi="!Windows 2012" спасает. (Обрати внимание на восклицательный знак. Здесь он означает отрицание).
> Ох, я столько уже мучался с этим, что и забыл, что в
> первый раз это может выглядеть как глупая шутка.
> Суть в том, что ядро при загрузке вызывает (не знаю, как метод
> называется, пусть...Ваш способ не сработал, но подтолкнул меня к другому - http://forums.linuxmint.com/viewtopic.php?f=49&t=137738
У меня запахало и с параметром acpi_osi=Linux, и с acpi_osi=Linux acpi_backlight=vendor (во втором случае, как мне показалось, запахало изменение яркости в настройках, а не только через горячие клавиши)
Только на экране нет ползунков регулировки (так сказать, наглядного дополнения к меняющейся яркости).
Не переживайте так, ваши мучения напрасны. В одном из следующих ядер все равно поломают опять...
https://www.kernel.org/diff/diffview.cgi?file=/pub/linux/ker...
acpi_osi= [HW,ACPI] Modify list of supported OS interface strings
- acpi_osi="string1" # add string1 -- only one string
- acpi_osi="!string2" # remove built-in string2
+ acpi_osi="string1" # add string1
+ acpi_osi="!string2" # remove string2
+ acpi_osi=!* # remove all strings
+ acpi_osi=! # disable all built-in OS vendor
+ strings
acpi_osi= # disable all strings
+ 'acpi_osi=!' can be used in combination with single or
+ multiple 'acpi_osi="string1"' to support specific OS
+ vendor string(s). Note that such command can only
+ affect the default state of the OS vendor strings, thus
+ it cannot affect the default state of the feature group
+ strings and the current state of the OS vendor strings,
+ specifying it multiple times through kernel command line
+ is meaningless. This command is useful when one do not
+ care about the state of the feature group strings which
+ should be controlled by the OSPM.
+ Examples:
+ 1. 'acpi_osi=! acpi_osi="Windows 2000"' is equivalent
+ to 'acpi_osi="Windows 2000" acpi_osi=!', they all
+ can make '_OSI("Windows 2000")' TRUE.
+
+ 'acpi_osi=' cannot be used in combination with other
+ 'acpi_osi=' command lines, the _OSI method will not
+ exist in the ACPI namespace. NOTE that such command can
+ only affect the _OSI support state, thus specifying it
+ multiple times through kernel command line is also
+ meaningless.
+ Examples:
+ 1. 'acpi_osi=' can make 'CondRefOf(_OSI, Local1)'
+ FALSE.
+
+ 'acpi_osi=!*' can be used in combination with single or
+ multiple 'acpi_osi="string1"' to support specific
+ string(s). Note that such command can affect the
+ current state of both the OS vendor strings and the
+ feature group strings, thus specifying it multiple times
+ through kernel command line is meaningful. But it may
+ still not able to affect the final state of a string if
+ there are quirks related to this string. This command
+ is useful when one want to control the state of the
+ feature group strings to debug BIOS issues related to
+ the OSPM features.
+ Examples:
+ 1. 'acpi_osi="Module Device" acpi_osi=!*' can make
+ '_OSI("Module Device")' FALSE.
+ 2. 'acpi_osi=!* acpi_osi="Module Device"' can make
+ '_OSI("Module Device")' TRUE.
+ 3. 'acpi_osi=! acpi_osi=!* acpi_osi="Windows 2000"' is
+ equivalent to
+ 'acpi_osi=!* acpi_osi=! acpi_osi="Windows 2000"'
+ and
+ 'acpi_osi=!* acpi_osi="Windows 2000" acpi_osi=!',
+ they all will make '_OSI("Windows 2000")' TRUE.
Xosd вам в помощь. Благо Linux это не винды...
Все хорошо, но интересно, как у него со скоростью будет...
как у BPF
> Nftables, новой реализации пакетного фильтра, идущего на смену iptablesВот есть iptables - проверенный годами, стабильный, притертый...
И тут на тебе новая шняга!, которая идет на смену iptables.
Да и еще с новым стрёмным синтаксисом.
Чё опять читать 100500 строковый ман? Тут бы старый дочитать :))
Аха..а ещё к таблесам куча полезных модулей, например тот же самый ipt_netflow
> Аха..а ещё к таблесам куча полезных модулей, например тот же самый ipt_netflowГы-гы. Неосиляторы в треде.
Даёшь каждый год новый код!
> Аха..а ещё к таблесам куча полезных модулей, например тот же самый ipt_netflowipt_netflow давно пора слить в мейнстрим. Вот и повод появился.
Часть этих полезных модулей требует пересборки ведра, а это геморно (при его регулярном и автоматическом обновлениии). В сабже же же этим модули вынесут в юзерспейс. Профит!
Но скорость работы не в ядре вызывает ???
> Аха..а ещё к таблесам куча полезных модулей, например тот же самый ipt_netflowДерьма кусок Ваш ipt_netflow. Мы всеми силами выправляли его кривой код, рассказали автору как работают блокировки в ядре, прислали патчи.
Так нет же йопт, они в новой версии снова лезут создавать структуры ядра не из под лока! Оно и крашится в ответ через каждый час :/
а есть чем заменить? Только не говорите что покупать циску..
А так - 2 год крутится на около провайдерской площадке под нагрузкой ~2gb (бондинг из 2 портов) -- ни 1 креша не было. Как креш воспроизвести?
> а есть чем заменить? Только не говорите что покупать циску..
> А так - 2 год крутится на около провайдерской площадке под
> нагрузкой ~2gb (бондинг из 2 портов) -- ни 1 креша не
> было. Как креш воспроизвести?BSD и netgraph. =)
аха.. смените ос,руки,планету...
> аха.. смените ос,руки,планету...Ну если так хочется воспроизвести креш - то и BSD поставишь, и netgraph настроишь.
>>Как креш воспроизвести?
>BSD и netgraph. =)В смысле "и креши появятся"?
>> Nftables, новой реализации пакетного фильтра, идущего на смену iptables
> Вот есть iptables - проверенный годами, стабильный, притертый...
> И тут на тебе новая шняга!, которая идет на смену iptables.
> Да и еще с новым стрёмным синтаксисом.
> Чё опять читать 100500 строковый ман? Тут бы старый дочитатьiptables давно уже устарел, справедливо осмеян. Придется переучиватьсяю
> iptables давно уже устарел, справедливо осмеян. Придется переучиватьсяюЧем конкретно он устарел, старый стал запинаться стал, раньше пакеты фильтровал, а теперь нет нет да и пропустит парочку по рассеянности ?
> Чем конкретно он устарел, старый стал запинаться стал, раньше пакеты фильтровал, а теперь нет нет да и пропустит парочку по рассеянности ?Нет, просто уродец. Все попытки дальнейшего развития netfilter упирались в неимоверную кривизну x_tables.
Ждем аналогично экстерминатуса зоопарку им. Кузнецова (iproute2). С блекджеком и нормальной ограничивалкой трафика.
> Нет, просто уродец. Все попытки дальнейшего развития netfilter упирались в неимоверную кривизну x_tables.Многим нравиться.
Как бы не народился ещё больший "уродец". Да и трудно всем угодить, один любит systemd, а другой например предпочитает свиной хрящик.
> Ждем аналогично экстерминатуса зоопарку им. Кузнецова (iproute2). С блекджеком и нормальной ограничивалкой трафика.Ну да, прогресс не стоит на месте, и пожелания трудящихся ( "одминов" и программистов ) тоже...
> Многим нравиться.Мазохисты, сэр! Так давайте еще раз сделаем им больно, раз они это любят!
> Как бы не народился ещё больший "уродец".
Пока дизайн довольно красивый. Корень уродств x_tables растет еще из эпохи ipchains. Тогда еще думали, что несть протоколов, кроме IPv4, и несть ната, кроме маскарада. А потом выяснилось, что есть еще ARP, IPv6, Ethernet, всякие DNATы и SNATы. Старая оболочка все раздувалась и раздувалась...
> Да и трудно всем угодить,
А не надо кому-то угождать. Надо просто сделать технически лучше, чем было.
> А не надо кому-то угождать. Надо просто сделать технически лучше, чем было.Дорогой анонимный брат Аноним, эта твоя позиция лично мне близка и понятна, и я могу её только поприветствовать. Если действительно удастся сделать "технически лучше, чем было", то я думаю и противники данного шага в конце концов осознают преимущества и открывшиеся перспективы. К тому же хочется надеяться, что поддержка нового кода, в конечном итоге, будет проще, а соответственно менее склонна к "забагованности".
> Дорогой анонимный брат Аноним, эта твоя позиция лично мне близка и понятна, и я могу её только поприветствовать.Судя по резкому изменению вашей позиции, вы успели сходить по ссылкам в новости =)
>> Многим нравиться.
> А не надо кому-то угождать. Надо просто сделать технически лучше, чем было.Это уже попахивает изменой GNU/Linux. Вы так договоритесь до BSD way.
> Это уже попахивает изменой GNU/Linux. Вы так договоритесь до BSD way.BSD way - это когда не технически, а академически лучше. Но при этом никому нафиг не сдалось.
>> Нет, просто уродец. Все попытки дальнейшего развития netfilter упирались в неимоверную кривизну x_tables.
> Многим нравиться.
> Как бы не народился ещё больший "уродец". Да и трудно всем угодить,
> один любит systemd, а другой например предпочитает свиной хрящик.
>> Ждем аналогично экстерминатуса зоопарку им. Кузнецова (iproute2). С блекджеком и нормальной ограничивалкой трафика.
> Ну да, прогресс не стоит на месте, и пожелания трудящихся ( "одминов"
> и программистов ) тоже...ну вы сравнили блин, админы как раз знают bash отлично, и писать init в порядке вещей, да и для самопала часто вместо стандартного init выступает runit, поэтому на systemd и смотрят с недоверием. А вот с Nftables совсем другая штука, его давно ждали и кучя админов в курсе что это. И он делался с оглядкой на FreeBSD. Так что новшество новшеству рознь.
> и писать init в порядке вещейИ это печально.
> часто вместо стандартного init выступает runit
Примерно один раз из десяти тысяч, не?
> И он делался с оглядкой на FreeBSD.
Фига с два.
> ну вы сравнили блин, админы как раз знают bash отличноОй ли? over 99% на яндексовские задачи правильно ответить не могут.
> Ой ли? over 99% на яндексовские задачи правильно ответить не могут.Видимо, вин- и убунтоадмины.
> Вот есть iptables - проверенный годами, стабильный, притертый...Дедушка умер, похороните его уже.
> Да и еще с новым стрёмным синтаксисом.
А вот бздуны от такого синтаксиса кипятком писают, например.
> Чё опять читать 100500 строковый ман?
Не нравится - вперед, в дворники.
> Не нравится - вперед, в дворники.Это вот ты сейчас так защищаешь ТО, чем еще ниразу не пользовался и руками не щупал.
Я говорю о стабильности и надёжности, проверенных вещах. Ты говоришь о бздунах и дворах.
Делайте выводы господа :)
>> Не нравится - вперед, в дворники.
> Это вот ты сейчас так защищаешь ТО, чем еще ниразу не пользовался и руками не щупал.Откуда ты знаешь, мой юный друг? Может быть, я слежу за этим проектом с 2009 года, когда он только появился?
> Я говорю о стабильности и надёжности, проверенных вещах.
Хрущевки тоже проверены временем. Но это не значит, что там нужно покупать квартиру :)
> Делайте выводы господа :)
Напрашивается вывод, что перед нами человек, который не способен к обучению, и поэтому вынужден принимать в штыки все новые технологии.
> Откуда ты знаешь, мой юный друг? Может быть, я слежу за этим проектом с 2009 года, когда он только появился?Это очень замечательно, что на опеннете есть человек, который следил за этим проектом с 2009 года (~4 года, так?)
Буду очень признателен если ты поделишься своими познаниями и возможно развеешь все мои домыслы.> Хрущевки тоже проверены временем. Но это не значит, что там нужно покупать квартиру :)
Железный аргумент. С нетерпением жду более детальной выкладки материала по вопросу Nftables
> Напрашивается вывод, что перед нами человек, который не способен к обучению, и поэтому вынужден принимать в штыки все новые технологии.
Человеку свойственна лень. Вам нет?
> Это очень замечательно, что на опеннете есть человек, который следил за этим проектом с 2009 года (~4 года, так?)Четыре с половиной (официальный анонс был весной). Но в 9-11 годах следить было особо не за чем - несколько коммитов в год.
> Буду очень признателен если ты поделишься своими познаниями и возможно развеешь все мои домыслы.
На всезнание не претендую, но насчет ключевых моментов вроде в курсе. Спрашивай.
>> Хрущевки тоже проверены временем. Но это не значит, что там нужно покупать квартиру :)
> Железный аргумент.Не менее железный, чем "X работало 10 (20, 30, ...) лет, значит, X нельзя трогать".
> Человеку свойственна лень. Вам нет?
Чем удобнее и логичнее инструмент, тем больше простора для лени он предоставляет.
Там, где виндyзятник будет тысячу раз щелкать мышкой, юниксоид напишет скрипт. (На что виндyзятник, конечно, ответит - "а мне лень ваши скрипты изучать, я лучше мышкой". Что ж, это его выбор)
> На всезнание не претендую, но насчет ключевых моментов вроде в курсе. Спрашивай.Как оно из байткода выводит список текущих правил в человекопонятном виде (по аналогии с 'iptables -t nat -L POSTROUTING')? Можно ли засунуть в байткод правила, которые стандартная cli не пережует или интерпретирует неверно?
>> На всезнание не претендую, но насчет ключевых моментов вроде в курсе. Спрашивай.
> Как оно из байткода выводит список текущих правил в человекопонятном виде (по аналогии с 'iptables -t nat -L POSTROUTING')?Путем декодирования, очевидно же. См. src/netlink.c, list_chain_cb.
> Можно ли засунуть в байткод правила, которые стандартная cli не пережует или интерпретирует неверно?
Полагаю, можно. Только зачем ломать юзерспейнсую программу (ну выдаст nft сегфолт) через редактирование памяти ядра?
Да что-то гложат меня смутные сомнения. Теоретически, байткодом можно много чего наворотить, и хорошо если оно при просмотре хотя бы сегфолт выдаст, а не спрячет правило от админа. И ведь даже запрет на загрузку модулей не защитит от такой уязвимости...В общем, как-то слегка подозрительно всё это звучит.
> Да что-то гложат меня смутные сомнения. Теоретически, байткодом можно много чего наворотить,
> и хорошо если оно при просмотре хотя бы сегфолт выдаст, а
> не спрячет правило от админа. И ведь даже запрет на загрузку
> модулей не защитит от такой уязвимости…попробуй не давать всем подряд права на то, на что права должны быть только у администратора. решает кучу проблем.
ну, или проще: НЕ РАБОТАЙ ПОД РУТОМ!
> Да что-то гложат меня смутные сомнения. Теоретически, байткодом можно много чего наворотить,
> и хорошо если оно при просмотре хотя бы сегфолт выдаст, а
> не спрячет правило от админа. И ведь даже запрет на загрузку
> модулей не защитит от такой уязвимости...Байт-кодом, который имеет доступ только к сетевым пакетам? Ну-ну.
При наличии рутового доступа те же вещи можно сделать гораздо проще (например, на raw-сокетах, как в pcap).
> Байт-кодом, который имеет доступ только к сетевым пакетам? Ну-ну.
> При наличии рутового доступа те же вещи можно сделать гораздо проще (например,
> на raw-сокетах, как в pcap).Байткодом, который имеет доступ к фаерволу. Можно разрешить много лишнего на сетевом уровне, которое хрен отследишь снифером с этой же машины. Этакий руткит в дефолтной поставке - никаких левых процессов, подгружать левые модули ядра больше не нужно.
> Байткодом, который имеет доступ к фаерволу. Можно разрешить много лишнего на сетевом уровне, которое хрен отследишь снифером с этой же машины.Почему? Через тот же pcap - никаких проблем. У фаервола и raw-сокетов один и тот же сетевой стек, а не два независимых.
> Этакий руткит в дефолтной поставке - никаких левых процессов, подгружать левые модули ядра больше не нужно.
Для pcap тоже никаких модулей подгружать не нужно.
А еще можно хранить злохакерские явки и пароли в параметрах sysctl, например. Примерно такая же страшная угроза.
> Почему? Через тот же pcap - никаких проблем. У фаервола и raw-сокетов
> один и тот же сетевой стек, а не два независимых.Это я просто предположил так, какие там возможности у этого байткода и фильтра в целом - я не знаю. Если я ошибся, то хорошо. Но всё-равно, снифером ведь надо ещё знать что искать в общем потоке трафика.
> Для pcap тоже никаких модулей подгружать не нужно.Я пытаюсь акцентировать внимание на том, что - возможно - появится встроенная возможность скрыть некоторые правила фаервола от админа. Конечно, удобнее написать программу, которая будет работать в отдельном процессе, но её будет видно в списках процессов и в netstat (руткиты сейчас не рассматриваем - это отдельная история).
Опасные правила фаервола и сейчас можно спокойно написать, но они 100% отобразятся в выхлопе iptables в легко понятном человеку виде (про руткиты сейчас, опять же, не вспоминаем).
> А еще можно хранить злохакерские явки и пароли в параметрах sysctl, например.
> Примерно такая же страшная угроза.Про sysctl не понял. Что там можно хранить?
> Путем декодирования, очевидно же. См. src/netlink.c, list_chain_cb.А время вывода over9000 строк не станет больше чем просто вывод по сути текстовой информации ?
Если каждую строчку придется декодировать.
> А время вывода over9000 строк не станет больше чем просто вывод по сути текстовой информации ?
> Если каждую строчку придется декодировать.Большие наборы правил удобнее сворачивать в множества (sets), которые декодируются вполне тривиально (хеш->значение).
> Человеку свойственна лень. Вам нет?Человек которому свойственна лень больше, чем можно себе это позволить, неизбежно превращается в планктон и становится чужой едой...
>> Не нравится - вперед, в дворники.
> Это вот ты сейчас так защищаешь ТО, чем еще ниразу не пользовался
> и руками не щупал.
> Я говорю о стабильности и надёжности, проверенных вещах. Ты говоришь о бздунах
> и дворах.
> Делайте выводы господа :)Небось еще сендмылом почту рулите?
> Не нравится - вперед, в дворники.Павлик, залогинься.
>А вот бздуныИнтересы 1% никого не волнуют ))
> Павлик, залогинься.То, что личности с ограниченными интеллектуальными возможностями должны заниматься только простыми работами - факт, очевидный не только вашему Павлику.
> Интересы 1% никого не волнуют ))
Такой же 1%, как и у линуксоидов. Ничем не хуже.
> Вот есть iptables - проверенный годами, стабильный, притертый...И неподдерживающий кучу сетевых протоколов...
>> Вот есть iptables - проверенный годами, стабильный, притертый...
> И неподдерживающий кучу сетевых протоколов...Каких например ? каких из тех, с коими реально сталкиваются сисадмины ?
igrp, ospf, rip ?
> Каких например ? каких из тех, с коими реально сталкиваются сисадмины ?Начнем с простых: ethernet, ARP/RARP, IPv6 =)
Не надо ворчать. Если вы профессионал своего дела - вы каждый день маны читаете. Одним больше, одним меньше - какая разница? А удобочитаемые правила, и ускорение разбора этих правил за счёт использования бат-кода - это хорошо. Как и то, что основная нагрузка на разбор правил теперь в user space. Чем меньше кода работает на уровне ядра - тем лучше. Больше кода - больше вероятность что в нём есть уязвимости.
> Если вы профессионал своего дела - вы каждый день маны читаете.Маны каждый день читают админишки недоделаные, профессионалы их пишут.
> Маны каждый день читают админишки недоделаные, профессионалы их пишут.Это типа пропаганда расовой ненависти быдлoкодеров к админам?
> теперь в user space. Чем меньше кода работает на уровне ядра
> - тем лучше.Кстати сам Линус не считает что в линуксе должно быть микроядро, а все что можно по максимуму - вынесено за пределы ядра в его модули.
> Кстати сам Линус не считает что в линуксе должно быть микроядро, а
> все что можно по максимуму - вынесено за пределы ядра в
> его модули.Сам Линус никогда не был авторитетом в области проектирования и архитектуры ОС. Он так бы и остался не самым умным(он сам о себе так говорил в беседе с финскими студентами) студентом, который изобрёл ещё один велосипед. Если бы не стечение обстоятельств. Парни из Беркли, создавшие 4.4BSD огребли проблемы от патентных троллей в 1992 году, и срочно нужен был свободный клон Unix ему на замену. Minix не мог заменить 4.4BSD, GNU Hurd уже тогда был мертвеннорожденным проектом. И именно благодаря этому стечению обстоятельств в тот момент Linux стал уникальным и незаменимым. Он быстро занял место 4.4BSD, а потом потомки ОС из Беркли уже не могли его догнать. Они сбавили темп, и навсегда потеряли своё место под Солнцем. Не нужно с Линуса делать авторитета. Он написал ОС, которая работала. Но над ядром трудилось много гораздо более квалифицированных программистов. Линус - икона, как Стив Джобс или Билл Гейтс. Но, как и они, он далеко не самый авторитетный специалист в области IT. Я бы не стал считать его мнение(как и мнение Гейтса или Джобса), особо авторитетным.
>> Кстати сам Линус не считает что в линуксе должно быть микроядро, а
>> все что можно по максимуму - вынесено за пределы ядра в
>> его модули.
>Парни из Беркли, создавшие 4.4BSD огребли проблемы от патентных троллей в 1992 году,Ой, тогда именно патентных тролей в ПО не было. Не было _патентов_ в иске USL. Тот иск, собственно, заложил основы копиврайта в [более] современном его состоянии. Википедию почитай, что ли.
> заменить 4.4BSD, GNU Hurd уже тогда был мертвеннорожденным проектом. И именно
> благодаря этому стечению обстоятельств в тот момент Linux стал уникальным и
> незаменимым. Он быстро занял место 4.4BSD, а потом потомки ОС изОстальную часть GNU забыл. Агенты Z0Gа зарелизили 4.4BSD с GNU gcc! Голубоглазые, наивные коре-тиимеры не замечали "пoдставы" ещё 25~ лет.
> Беркли уже не могли его догнать. Они сбавили темп, и навсегда
> потеряли своё место под Солнцем.Чего-то на www.freebsd.org/releases/ особого застоя не заметно. Какие версии Вы считаете _особо застойными?
>Не нужно с Линуса делать авторитета.
>Линус - икона, как Стив Джобс или Билл Гейтс.Хорошо, что Вы поделились с нами Ваше Картиной Мира. Ваша точка стала более понятна.
>Я бы не стал считать его мнение(как и мнение Гейтса или Джобса), особо авторитетным.
Зато как тролит! Пaцаны на бoлоте уверены -- авторитет.
То, что все потомки 4.4BSD никогда не догонят теперь Linux по популярности(Mac OS X считать потомком 4.4BSD мы не можем, это ОС с другой архитектурой(как раз более близкой к микроядерным)), это уже неоспоримый факт. Своё время фанбои подделий из Беркли упустили.> Зато как тролит! Пaцаны на бoлоте уверены -- авторитет.
Линус - в первую очередь символ. Это человек-икона. А ещё он оказался гениальным организатором. И в этой роли(координатора и вдохновителя) он приносит намного больше пользы, чем в роли рядового программиста. Координировать работу тысяч программистов - это программисткий скил высшего уровня. При этом Линус - редкостный троль. Я бы не стал считать Линуса хорошим специалистом в области архитектуры ОС.
Да это и к лучшему, что он(в отличии от Столлмана и Таннебаума) так и не осознал, что такое хорошая архитектура. Потому что увлекшись перфекционизмом, он бы никогда не создал работоспособное ядро. Он бы испугался массштаба той работы, которую нужно было проделать. Или погряз бы в дебатах на тему совершенного кода, и не менее совершенной, архитектуры. Но то, что было хорошо для быстрого развития ядра(особенно на ранних этапах) - не будет оптимальным, когда ядро разростётся до невероятных массштабов. Оно и так уже слишком жирное. Рано или поздно всё лишнее начнут выносить из ядра в юзерспейс. Разрабы netfilter просто раньше других осознали это.
> Сам Линус никогда не был авторитетом в области проектирования и архитектуры ОС.И тем не менее - у него были аргументы того, каким должно быть _его_ ядро.
Я вот например считаю, что если что-то вынести за пределы ядра, то это облегчит задачу для всякого рода хакеров и крекеров, по запуску своего кода с привилегиями ядра. Как видно из статьи, цитата:
правила фильтрации компилируются в пространстве пользователя в байткод и передаются в ядро через API NetlinkТо есть теперь не нужны права рута, чтобы сообщать ядру какие-то параметры.
Я вижу 2 потенциальные угрозы безопасности:
То что можно будет запустить вредоносный код с правами ядра, найдя уязвимость в ядре и передав ядру "специально сформированный байт-код", но запустив вредоносную программу с правами пользователя.
Второе - "специальная связующая интерфейсная библиотека libnl" является дополнительным звеном в цепи, и сама по себе представляет источник уязвимости - теоретически ее можно подменить на такую же, но с бекдором.Все что я написал трудно выполнимо, но все-таки легче, чем в случае с iptables, который является надстройкой над netfilter - который монолитно вшит в ядро.
>[оверквотинг удален]
> Я вижу 2 потенциальные угрозы безопасности:
> То что можно будет запустить вредоносный код с правами ядра, найдя уязвимость
> в ядре и передав ядру "специально сформированный байт-код", но запустив вредоносную
> программу с правами пользователя.
> Второе - "специальная связующая интерфейсная библиотека libnl" является дополнительным
> звеном в цепи, и сама по себе представляет источник уязвимости -
> теоретически ее можно подменить на такую же, но с бекдором.
> Все что я написал трудно выполнимо, но все-таки легче, чем в случае
> с iptables, который является надстройкой над netfilter - который монолитно вшит
> в ядро.В целом, вы правы. Но не думаю, что любой пользователь может компилировать правила для файрвола. Думаю, данное действие будет доступно только пользователям определённой группы.
> То есть теперь не нужны права рута, чтобы сообщать ядру какие-то параметры.а вот с этого места — подробней давай. особенно интересно, чем это *принципиально* отличается от пинания ядра на предмет «распарзи вот этот вход» (кроме того, что парзер как раз и убрали).
> То что можно будет запустить вредоносный код с правами ядра, найдя уязвимость
> в ядре и передав ядру «специально сформированный байт-код», но запустив
> вредоносную программу с правами пользователя.точно так же, как *теоретически* это можно сделать, накормив парзер кривыми входными данными. только парзер сложнее в отладке, потому что в нём больше кода.
> теоретически ее можно подменить на такую же, но с бекдором
это означает, что рутовый доступ к системе уже есть. а, следвательно, ни о какой безопасности речь уже не идёт.
> который монолитно вшит в ядро
см. выше про парзер. чем меньше в ядро «вшито» кода — тем легче его отладить.
проше говоря: всё, тобой описаное, точно так же относится и к существующей реализации. местами даже сильнее, чем к новой. некоторое время новая будет — возможно — более забагована, чем существующая. но это не страшно, это починится.
некомпетентность Линуса - это миф
который подогревается всеми, кому не лень, в том числе и нашими бывшими разработчиками линуксового ядра
не стоит забывать, что именно Линус написал первые версии ядра, файловой системы
что именно линус координировал и сам переписывал первые модули ядра, написанные другими разработчиками
то, что он сейчас ничего не пишет, в этом нет ничего удивительного - нельзя обьять необьятное, тем более что что ядро начинает разрастаться до необьятных размеров
> некомпетентность Линуса - это миф
> который подогревается всеми, кому не лень, в том числе и нашими бывшими
> разработчиками линуксового ядра
> не стоит забывать, что именно Линус написал первые версии ядра, файловой системы
> что именно линус координировал и сам переписывал первые модули ядра, написанные
> другими разработчиками
> то, что он сейчас ничего не пишет, в этом нет ничего удивительного
> - нельзя обьять необьятное, тем более что что ядро начинает разрастаться
> до необьятных размеровНе спорю. Совсем некомпетентый человек не мог бы проверять чужой код, и координировать столько лет работу над ядром. Но не факт, что Линус - хороший системынй архитектор. Нужно у него самого спросить, что он думает по поводу своей компетентности в данном вопросе.
> Не надо ворчать. Если вы профессионал своего дела - вы каждый день
> маны читаете.А пацанам не нужен нормальный l7-filter, имя что-нить попроще, для домашнего роутера.
К 2113 году, когда в стабильную ветку будут переведены ядра 3.13 всё будет уже проработано и организовано ;-)
> К 2113 году, когда в стабильную ветку будут переведены ядра 3.13Всего лишь к 2014.
>> Nftables, новой реализации пакетного фильтра, идущего на смену iptables
> Вот есть iptables - проверенный годами, стабильный, притертый...
> И тут на тебе новая шняга!, которая идет на смену iptables.
> Да и еще с новым стрёмным синтаксисом.
> Чё опять читать 100500 строковый ман? Тут бы старый дочитать :))s/iptables/ipchains/g ну вы поняли... )
примерно также когда-то давно поклонники ipchains думали.
Совсем не так.
Вам, бсдишнегам, трудно понять, что iptables был просто логическим продолжением ipchains.
Увеличилась функциональность, добавились опции и... всё.
Проблем с переходом не возникло.
> Совсем не так.
> Вам, бсдишнегам, трудно понять, что iptables был просто логическим продолжением ipchains.
> Увеличилась функциональность, добавились опции и... всё.
> Проблем с переходом не возникло.Вот-вот. Вместо того, чтобы похоронить дедулю, к нему приделали экзоскелет с дистанционным управлением. Шевелиться - шевелится, но живее от этого не стал.
Трудно представить, чтобы вы, любители анимэ, сделали с старичком колесом.
> Трудно представить, чтобы вы, любители анимэ, сделали с старичком колесом.С колесом - не так много. А вот повозки эпохи первых колес, несмотря на их стабильность, притертость и беспроблемность, уже отошли в историю.
При этом колёса просто модифицировались, а не изобретались по-новой.
> При этом колёса просто модифицировались, а не изобретались по-новой.Человек - это модифицированная амеба.
>> При этом колёса просто модифицировались, а не изобретались по-новой.
> Человек - это модифицированная амеба.Пожалуйста, если уж очень неймётся -- делитесь такими откровениями (да и вообще) где-нить ещё, и так уже опять на триста сообщений флейм раздули...
> Ключевой особенностью Nftables является применение идеи, близкой к реализации BPF (Berkeley Packet Filters) - правила фильтрации компилируются в пространстве пользователя в байткод и передаются в ядро...
> Выполнение правил с использованием конечного автомата вместо применения логики сопоставления позволяет сократить размер кода фильтрации, работающего на уровне ядра...Выглядит положительным начинанием, но не опасна ли эта затея с байт-кодом. Кто может пояснить на пальцах и успокоить ?
> Выглядит положительным начинанием, но не опасна ли эта затея с байт-кодом. Кто может пояснить на пальцах и успокоить ?iptables сейчас работает примерно так же. Только вместо байт-кода - блоб хитрой структуры, который интерпретируется в реальном времени. В общем, разница в седьмой воде на киселе.
Только Lua, только хардкор!
Нет, серьезно: http://www.opennet.me/openforum/vsluhforumID3/92243.html
> Выглядит положительным начинанием, но не опасна ли эта затея с байт-кодом.не опасна. точнее, как минимум не более опасна, чем существующая реализация. сейчас правила тоже преобразуются в некоторое внутреннее представление, как понимаешь — не парзят же их заново каждый раз, когда надо проверить пакет.
в принципе, решение с отдельным автоматом, который только и умеет, что исполнять небольшой набор команд, потенциально имеет меньше проблем. байткод, например, можно подвергнуть статическому анализу в юзерспейсе перед тем, как скормить ядру (для альтернативщиков: я не сказал, что это будут делать или что это вообще будет нужно). из ядра можно выкинуть код, который занимается построением внутреннего представления правил, оставив один универсальный автомат. и ты пы.
поначалу, конечно, в новой реализации могут обнаружиться разной толщины баги, но это неизбежно с любым изменением. однако отладить ядерную часть новой системы — также теоретически — будет проще. а если грохнется какой-нибудь компилятор правил — это не страшно, он в юзерспейсе работает.
опять для альтернативщиков: это всё были упрощения и логические выводы, не основаные на детальном исследовании кода новой реализации. если есть возражения по существу, основаные на коде — добро пожаловать, показывайте, это будет полезно.
Твою дивизию! Я только что окончил читать мануал к iptables на 600 страниц...
А зачем? Я вот тоже опасался сложности написания правил iptables, а выяснилось, что основ там на пол странички, а все остальное изучается исключительно по необходимости.
> Твою дивизию! Я только что окончил читать мануал к iptables на 600
> страниц...Я тебе открою страшную тайну: заменяешь iptables на ntf ip, -A на add, -p на protocol, -s на saddr, -d на daddr, --sport на sport, --dport на dport, -j DROP на drop, и дальше в таком духе. И все будет работать.
Итого: вместо
iptables -t filter -A OUTPUT -d 1.2.3.4 -p tcp --dport 80 -j DROP
получается
nft add rule ip filter output ip daddr 1.2.3.4 tcp dport 80 drop
Тогда какого Х*я ваще было синтаксис менять, раз всего названия сущностей были изменены?!
Шо за треш!
> Тогда какого Х*я ваще было синтаксис менять, раз всего названия сущностей были
> изменены?!
> Шо за треш!Внутри тоже кой-чего поменяли. Например, слили четыре гигантских куска дублирующегося кода (ip_tables, ip6_tables, arp_tables и ebtables) в один.
А синтаксис - так, за компанию. Тем более, что действительно напрашивалось.
> А синтаксис - так, за компанию. Тем более, что действительно напрашивалось.Кому оно напрашивалось? Вот посмотрите на новый синтаксис с точки зрения эргономики - все сливается... не хватает разделителей (типа '-')... Трудно читабельно, и не похоже на стандартный синтаксис CLI.
> Кому оно напрашивалось? Вот посмотрите на новый синтаксис с точки зрения эргономики
> - все сливается... не хватает разделителей (типа '-')... Трудно читабельно, иУ вас, видимо, браузер не отображает пробелы. Наверное, стоит написать багрепорт разработчикам.
Иди отсюда, арчеребёнок. Синтаксис иптаблес лучше
> Иди отсюда, арчеребёнок.Не брюзжи, слакодедуля :)
> Синтаксис иптаблес лучше
Чем грузины? Или чем армяне?
Тем, что он соответсвует POSIX стандарту коммандной строки.
Кстати, как там о добавлении правил из коммандной строки? Порой бывает очень нужно, не перегружать же все 100500 из-за одного правила.
Зыж
>Кстати, как там о добавлении правил из коммандной строки?С точки зрения лаконичности и удобства имеется в виду.
> Тем, что он соответсвует POSIX стандарту коммандной строки.Я бы не сказал, что для фаервола это достоинство.
Вот ты бы очень обрадовался, если бы твою речь ограничили синтаксисом POSIX commandline?> Кстати, как там о добавлении правил из коммандной строки?
Сходи по ссылке, например. А то не прочитал нифига, а осуждать уже лезешь.
> Порой бывает очень нужно, не перегружать же все 100500 из-за одного правила.
В силу структуры iptables, невозможно добавить/удалить одно правило, не поменяв весь набор.
Правила хранятся в ядре в виде блоба, который формируется утилитами в userspace. При изменении одного правила, его нужно генерировать с нуля.
Именно поэтому разработчики iptables рекомендуют вместо скриптов с кучей команд iptables использовать iptables-restore (см. Jan Engelhardt, Towards to the perfect ruleset).
As of June 2009, iptables and its relatives are still bound by the kernel interfaces of the ip_tables etc. modules, which only provide means to get and set entire tables. Old-fashioned scripts execute /sbin/iptables over and over — once for each policy they want to set, once for each flush operation they attempt, and once for each rule they are adding to the system — spend a much higher time finishing execution than would normally be required. Every iptables invocation will download the ruleset from the kernel, perform the modification — in case of -A this is adding just one rule — and upload it back into the kernel. Repeat that n times, and you get a cost factor of O(n^2) to perform n operations.There is also a security risk, a window of opportunity where packets might pass halfway through while a ruleset is copied back and forth. Setting the policy to DROP before will not solve this problem, as this novice example shows:
С тех пор ничего не поменялось.
ссылочкой надеюсь не трудно будет поделиться?
http://inai.de/documents/Perfect_Ruleset.pdf
верно. что мешало ранее так сделать?зыж
но вот это из разряда вредных советов:
>There is also a security risk, a window of opportunity where packets might pass halfway through while a ruleset is copied back and forth. Setting the policy to DROP before will not solve this problem, as this novice example shows:проследил цепочку вызовов от юзер-спейса:
>ret = setsockopt(handle->sockfd, TC_IPPROTO, SO_SET_ADD_COUNTERS,
> newcounters, counterlen);до ядра:
>static int
>do_ipt_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
>{…все операции там вроде как атомарны и блокируются.
> все операции там вроде как атомарны и блокируются.Ага-ага, каждый раз при перезагрузке правил блокируется сетевой стек.
1. Про кэширование пакетов благородный дон не слышал?
2. Вы реально понимаете разницу в скорости сети и обработки вот таких вот макросов:
#define SET_COUNTER(c,b,p) do { (c).bcnt = (b); (c).pcnt = (p); } while(0)
#define ADD_COUNTER(c,b,p) do { (c).bcnt += (b); (c).pcnt += (p); } while(0)
которые вызываются так:
do_add_counters(struct net *net, const void __user *user, unsigned int len, int compat)
{
…
if (copy_from_user(paddc, user + size, len - size) != 0) {
ret = -EFAULT;
…
t = xt_find_table_lock(net, AF_INET, name);
…
xt_entry_foreach(iter, loc_cpu_entry, private->size) {
ADD_COUNTER(iter->counters, paddc[i].bcnt, paddc[i].pcnt);
++i;
Вся, уже скомпилированная(!!!) таблица копируется из юзер-спейса в ядро, только потом(!!!) блокировка, потом копирование указателей(!!!) и разблокировка.
>Я бы не сказал, что для фаервола это достоинство.Как примут ваш стандарт "не_сказал_бы" на правила командной строки, тогда и поговорим.
А заодно и реализуют кучку библиотек (от баша, до с++) по разбору параметров командной строки.
А то уже существует масса фронт-эндов от популярных, до моих собственных.
>Сходи по ссылке, например. А то не прочитал нифига, а осуждать уже лезешь.Я не зря после комменты "зыж" добавил.
Попробуйте там доказать насколько сабж лаконичней, удобней и грамотней получится.
> Как примут ваш стандарт "не_сказал_бы" на правила командной строки, тогда и поговорим.Строка есть? Есть. Командует? Командует. Что тебе еще надо?
> А заодно и реализуют кучку библиотек (от баша, до с++) по разбору параметров командной строки.Ты решил сделать несколько альтернативных реализаций /sbin/nft на разных языках?
Тогда фиг с ними, с параметрами командной строки! Лучше покажи, как ты трансляцию в байткод на баше напишешь. Это ж дичайшей красоты и понятности код будет! Уже побежал за попкорном.> А то уже существует масса фронт-эндов от популярных, до моих собственных.
Основная причина существования этих фронт-эндов - POSIX-совместимый синтаксис командной строки :)
> Попробуйте там доказать насколько сабж лаконичней, удобней и грамотней получится.
Сначала я хочу послушать твое доказательство, что твой фронтенд удобнее, хотя бы для тебя. Страниц на пять хотя бы.
>Строка есть? Есть. Командует? Командует. Что тебе еще надо?Я что, не доступным вам языком написал?
Мне нужен стандартный способ разбора командной строки.
А также кучка библиотек (от баша, до с++) по разбору параметров командной строки, чтобы самому не изобретать велосипед.
зыж
>> А заодно и реализуют кучку библиотек (от баша, до с++) по разбору параметров командной строки.
>Ты решил сделать несколько альтернативных реализаций /sbin/nft на разных языках?
>Тогда фиг с ними, с параметрами командной строки!Вам (кстати, это от природной скромности вы на «ты» перешли?) понятен смысл слова front-end?
> Вам (кстати, это от природной скромности вы на «ты» перешли?)Просто не поворачивается язык человеку с такими детскими манерами писать "ты". Если на самом деле ты старый дедуля - считай за комплимент :)
> понятен смысл слова front-end?
Боюсь, что смысл этого слова не доступен как раз тебе.
Фронтенд должен не _читать_ командную строку nft, а _писать_ ее.
Читать он будет ее вывод и код выхода. Кстати, как твои фронтенды ухитряются работать без специальных библиотек, парсящих вывод iptables?
>Просто не поворачивается язык человеку с такими детскими манерами писать "ты".Э… А не наоборот? Поворачивается, как у прыщавого подростка в сложный период своего самоутверждения.
Заговариваться сталИ, дедуля? :D
>> понятен смысл слова front-end?
>Боюсь, что смысл этого слова не доступен как раз тебе.
>Фронтенд должен не _читать_ командную строку nft, а _писать_ ее.Именно! (generate a perfect hash function from a key set)
У меня мало желания работать с 2-я разными синтаксисами и служить между ними переводчиком.
>Кстати, как твои фронтенды ухитряются работать без специальных библиотек, парсящих вывод iptables?Путаете параметры командной строки и вывод stdout.
Что для ребёнка, упорствующего в своём праве хамить, не удивительно
> Э… А не наоборот? Поворачивается, как у прыщавого подростка в сложный период своего самоутверждения.Ага, значит я не ошибся с определением твоего возраста.
> Именно! (generate a perfect hash function from a key set)
ШТО? Зачем тебе хеш?
> У меня мало желания работать с 2-я разными синтаксисами и служить между ними переводчиком.
А ты и не служи. Юзай iptables, оно все равно потом (после допиливания nftables) будет транслироваться в nft. А вот обратно низя - iptables просто не умеет, например, низкоуровневой работы с хуками netfilter (поэтому глобальные цепочки там невозможны).
> Путаете параметры командной строки и вывод stdout.
По-моему, это ты их путаешь.
Ззыж
Ах да! Воскресенье. :D
> Я что, не доступным вам языком написал?
> Мне нужен стандартный способ разбора командной строки.Зачем тебе разбирать командную строку программы, которая уже написана? Чтобы сделать велосипед?
Мне нужно её формировать.
Желательно однообразным, стандартным способом.
В худшем случая имея хотя бы какой-то стандарт.
зыж
Например, при стандартном способе обработки я могу построить релевантные отношения между параметрами и их доступном в данном случае количестве.
Т.е. если указан -а, то параметров может быть не более 10, доступны -б, -с… и т.д.
В сабжевом случае уже бы xml использовали что ли, его валидность хотя бы можно проверить.
> Например, при стандартном способе обработки я могу построить релевантные отношения между параметрами и их доступном в данном случае количестве.
> Т.е. если указан -а, то параметров может быть не более 10, доступны -б, -с… и т.д.nft ничем в этом плане не отличается от iptables (кроме отсутствия минусов).
Или ты не про командную строку, а про дамп правил?
>nft ничем в этом плане не отличается от iptables (кроме отсутствия минусов).Докажи.
Хотя бы на примере из сабжа выше — как проверить валидацию параметров до запуска. Формально конечно, не смысл самих правил.Зыж
>а про дамп правил?Во, о чём и речь. Пошли какие-то свои термины, своего (нарождающегося на ходу) стантарда, своих правил.…
Как проверить корректность сформированной командной строки ДО запуска?
а как это сделать в текущем интерфейсе iptables ?
как и у любого другого приложения, поддерживающего опции командой строки в стиле стандарта POSIX http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_...на основе этого стандарта (man getopts, getopt, getsubopt, getsubopt, popt и т.д.) были созданы библиотеки, дополняющие функциональность (но совместимые) практически для всех языков и на все случаи жизни. Например, для perl (который вполне не плохой выбор в рамках вашего вопроса) http://search.cpan.org/~ukautz/Getopt-Valid-v0.1.4/lib/Getop... :
>Implements an extended getopt mechanism relying on Getopt::Long but provides extended validation and filtering capabilities.или Getopt::Lucid http://search.cpan.org/dist/Getopt-Lucid/lib/Getopt/Lucid.pm :
>Getopt::Lucid - Clear, readable syntax for command line processingвот для С http://argtable.sourceforge.net/
>It enables a program's command line syntax to be defined in the source code as an array of argtable structs.Для С++ вот сюда http://habrahabr.ru/post/174347/ (там же и все мотивы, с которыми я солидарен)
Откройте для себя Bison.
И пишите свои парсеры вместо того, что отлажено за пару десятков лет? Ну-ну, желаю вам так и делать. наслаждайтесь граблями.
> И пишите свои парсеры вместо того, что отлажено за пару десятков лет?
> Ну-ну, желаю вам так и делать. наслаждайтесь граблями.да за каким фигом тебе вообще парзить правила-то? генерируем не приходя в сознание, а потом парзим, чтобы понять, что там нагенерилось?
я вот достаточно давно использую ferm. в том числе его правилами заведует несколько роботов. представь: мне ни разу не понадобилось парзить фермовые правила. вообще. только генерировать и собирать в кучку (что, кстати, сильно облегчается наличием в ferm такой штуки, как include).
зачем парзить-то? чтобы что-то править на системе, которой сто лет в обед и которая сконфигурирована пришельцами с Венеры? а может, лучше один раз переконфигурировать и не заниматься ерундой?
а зачем парзить параметры комстроки для файрвола? опять кто-то не приходя в сознание нагенерировал? могу посоветовать таки прийти в сознание и хранить нужные опции в более удобном виде, из которого параметры и создавать.
>> И пишите свои парсеры вместо того, что отлажено за пару десятков лет?
>> Ну-ну, желаю вам так и делать. наслаждайтесь граблями.
> да за каким фигом тебе вообще парзить правила-то?Забавно. Это ты ж так делать предложил! :D
Честно говоря, конкретно мне парсить не приходилось, но вполне могу представить ситуацию, когда надо сделать что-то вроде аудита, то есть собрать все правила в кучу и посмотреть, каким получается результирующее условие.Впрочем, меня гораздо больше раздражает "человекочитаемый" синтаксис как раз в плане хреновой читаемости человеком. Как по мне, неалфавитные разделители строки на отдельные единицы - большое благо. Проще нужный кусок увидеть.
С другой стороны - если это внешняя тулза правила компилирует - наверняка останется вариант с синтаксисом a-la iptables.
> Честно говоря, конкретно мне парсить не приходилось, но вполне могу представить ситуацию,
> когда надо сделать что-то вроде аудита, то есть собрать все правила
> в кучу и посмотреть, каким получается результирующее условие.это — решение задачи, которая ещё даже не появилась. при этом у меня есть стойкое мнение, что решать её намного проще будет при помощи «отладочной инфы» в полученом байткоде и юзермодового же симулятора с execution trace. которые наглядно покажут, сквозь какие правила что прошло.
> Впрочем, меня гораздо больше раздражает «человекочитаемый» синтаксис как раз в плане хреновой
> читаемости человеком. Как по мне, неалфавитные разделители строки на отдельные единицы
> — большое благо. Проще нужный кусок увидеть.если ты про то, что там терминаторы типа ';' убраны — так они не нужны. потому что перенос строки и без них отлично видно, а предложение вполне явно завершается указанием действия.
> С другой стороны — если это внешняя тулза правила компилирует — наверняка
> останется вариант с синтаксисом a-la iptables.ну да. для тех, кому жаль лет, потраченых на «$@#^%@%@».
p.s. забавно повоевать «с другой стороны», да.
> Впрочем, меня гораздо больше раздражает "человекочитаемый" синтаксис как раз в плане хреновой
> читаемости человеком. Как по мне, неалфавитные разделители строки на отдельные единицы
> - большое благо. Проще нужный кусок увидеть.Почему же вы не пользуетесь ими в обычной речи? Не ставите -- перед каждым словом, и всякие ))) или ... после каждой фразы?
Получается какой-то двойной стандарт - говорите, что удобно и вообще зашибись, но сами воздерживаетесь.
> И пишите свои парсеры вместо того, что отлажено за пару десятков лет?Почему-то в этом "отлаженном за пару десятков лет" до сих пор продолжают находить ошибки, связанные с тем, что iptables-save генерирует некорректные (даже с точки зрения iptables-restore) дампы. Одна из причин этого - использование для дампов синтаксиса команд POSIX.
> Ну-ну, желаю вам так и делать. наслаждайтесь граблями.
Как показывает практика, использование "отлаженных за пару десятков лет" решений дает ничуть не меньше граблей =)
> Откройте для себя Bison.кстати, закройте для себя bison и откройте для себя lemon.
Ну хвалятся они прикольно, а что оно _на_практике_ даёт по сравнению с бизоном? SQlite - это, конечно, неплохая заявка, но они вообще экзотику любят - тот же Fossil взять.
> Ну хвалятся они прикольнокто и чем «хвалится»? O_O
> а что оно _на_практике_ даёт по сравнению с бизоном?
как минимум — парзер, который можно кормить токенами, а не парзер, который из своего цикла настырно токены требует. синтаксис несколько удобней. выхлоп чуть компактней. есть удобная фича «деструктор токена» — вызов функции-деструктора, когда токен больше не нужен. ну и да: можно со своей софтиной его носить, там один сишный файл — иногда это удобно.
> SQlite — это, конечно, неплохая заявка, но они вообще экзотику
> любят — тот же Fossil взять.вообще-то — не любят раздутых монстров. поэтому периодически создают замены, которые выполняют большинство того, что от монстров надо, и при этом не лопаются от жира.
впрочем, как я сказал, лично для меня самая важные фичи те, что я на выходе получаю парзер, управляемый «снаружи», а не парзер, который самостоятельно жрёт в три горла, и что у токенов есть деструкторы. кстати, создание нескольких парзеров — тоже удобная штука: никаких глобалов в парзере не используется.
кое-что из вышеперечисленого можно и от бизона получить, конечно, но… не радует.
Хвалятся - авторы lemon его фичами. Что до перечисленного тобой - таки подходы разные. Я всегда нежно любил, когда потребитель сам данные требует - как-то лучше мне такая архитектура на мозг ложится - скормил ему источник данных и забыл, можно этот парсер, скажем, куда-то передать и он там дальше работать будет с тем же источником. Но я ж плюсовыми категориями мыслю, там это удобно, да и глобальных переменных там нет. Вот насчет деструкторов токенов в голову ничего особо не приходит, но вроде и нужды не было. Хотя гляну детальнее - может, правда с ними красивее получается.
> Хвалятся - авторы lemon его фичами.где? на всякий случай: перечисление != похвальба.
> Я всегда нежно любил, когда потребитель сам данные требует
такой подход нормально выглядит только при условии наличия в языке полноценных замыканий и генераторов. иначе выходят костыли или непредсказуемые монстры. особенно в случае, когда из парзера надо вызвать, например, другой парзер, новосозданый, но сидящий на том же лексере.
> — как-то лучше мне такая архитектура на мозг ложится — скормил
> ему источник данных и забыл, можно этот парсер, скажем, куда-то передать
> и он там дальше работать будет с тем же источником.штука в том, что объединить «управляемый» парзер и лексер в одну сущность совсем несложно. а вот «разорвать» лексер и парзер в случае, когда парзер сам всё решает — шибко сложнее.
> может, правда с ними красивее получается.
иногда — красивей. достаточно часто для простых грамматик делать zone allocator лениво, а хранить дополнительную информацию в токене удобно. используем malloc(), при этом не напрягаемся по поводу того, кто и когда позовёт free().
p.s. или мегахаки типа «предпросмотра на токен вперёд и вызова разных парзеров в зависимости от». согласен, это можно и грамматикой сделать. но иногда бывает нужно и вот так — проще получается.
>>nft ничем в этом плане не отличается от iptables (кроме отсутствия минусов).
> Докажи.
> Хотя бы на примере из сабжа выше — как проверить валидацию параметров
> до запуска. Формально конечно, не смысл самих правил.Бизон в помощь, очевидно же.
>>а про дамп правил?
> Во, о чём и речь. Пошли какие-то свои термины, своего (нарождающегося на
> ходу) стантарда, своих правил.…
> Как проверить корректность сформированной командной строки ДО запуска?Так дампа правил или командной строки?
>> Хотя бы на примере из сабжа выше — как проверить валидацию параметров
>> до запуска. Формально конечно, не смысл самих правил.
> Бизон в помощь, очевидно же.Не стоит слушать вышевыссказавшихся товарищей. Они бизон в сабже увидели и обрадовались.
А тем временем парсер на бизоне используется для трансформации сабжевого синтаксиса во внутреннее представление в самом сабже.
Это понятно?
Мне ТРАНСФОРМИРОВАТЬ ничего и никуда не нужно. Вы ещё xslt посоветуйте, угу.
В общем идиoтский совет.>>>а про дамп правил?
>> Как проверить корректность сформированной командной строки ДО запуска?
> Так дампа правил или командной строки?Вы тупoй, извиняюсь? Ответил уже.
зыжВот кстати пруф на оригинал http://lwn.net/Articles/324251/ :
>The userspace frontend is probably even more different to iptables than the kernel. The classification language is based on a real grammar that is parsed by a bison-generated parser (currently, it might have to be replaced) and converted to a syntax tree. Besides things like table and chain operations, the language elements are mainly:
>- runtime data describing expressions: "tcp dport", "meta mark", ...
>- constant data expressions: "ssh", "22", "192.168.0.1/24", ...
>- relational expressions and operations: "equal", "non-equal", "member of set", ...
>- combining expressions, like sets and flag lists: { 22, 23} and established,relatedИ да, предлагать использовать (в дополнение к своей) программу, предназначенную для автоматического создания синтаксических анализаторов, только для того, чтобы проверить валидность командной строки… э-э-э, как бы это помягче то… ОЧЕНЬ оригинально.
Что дальше? Баллистическую ракету при охоте на воробьёв?
> И да, предлагать использовать (в дополнение к своей) программу, предназначенную для автоматического
> создания синтаксических анализаторов, только для того, чтобы проверить валидность командной
> строки… э-э-э, как бы это помягче то… ОЧЕНЬ оригинально.
> Что дальше? Баллистическую ракету при охоте на воробьёв?А вы для анализа команд iptables предлагаете использовать какие-то дополнительные библиотеки, вместо strcmp. Тоже очень оригинально.
> Мне ТРАНСФОРМИРОВАТЬ ничего и никуда не нужно. Вы ещё xslt посоветуйте, угу.Тогда срочно выкинь все свои библиотеки для команд POSIX - они тоже по большей части ТРАНСФОРМИРУЮТ.
> Вы тупoй, извиняюсь?Просите, не мы, а вы.
> Ответил уже.
Вы постоянно перепрыгиваете с дампов на командную строку и обратно. Простите, не какой из этих ответов вы ссылаетесь?
Да-а-а, тяжёлый случай.
>В силу структуры iptables, невозможно добавить/удалить одно правило, не поменяв весь набор.Это ты про внутреннюю организацию всего этого хозяйства говоришь или говоришь о том, что из командной строки добавить/удалить одно правило невозможно?
>Правила хранятся в ядре в виде блоба, который формируется утилитами в userspace. При изменении одного правила, его нужно генерировать с нуля.
И тем не менее, одна команда с точки зрения пользователя добавляет/удаляет одно правило.
>Именно поэтому разработчики iptables рекомендуют вместо скриптов с кучей команд iptables использовать iptables-restore (см. Jan Engelhardt, Towards to the perfect ruleset).
Используем, но не всегда это возможно, т.к. некоторые правила изменяются динамически. В таких случаях при помощи iptables-restore загружается заготовка с пользовательскими цепочками, в которых потом динамически добавляются или удаляются правила по одному.
> Это ты про внутреннюю организацию всего этого хозяйства говоришь или говоришь о
> том, что из командной строки добавить/удалить одно правило невозможно?О внутренней. Пакеты фильтрует netfilter, а не iptables.
При этом в ядре таблицы меняются простой сменой указателей.
Вот, специально не поленился и посмотрел как это работает http://www.opennet.me/openforum/vsluhforumID3/92256.html#122Не, конечно готовить и компилировать по-новой таблицы в юзер-спейсе — это дольше, чем готовить только одну запись.
Но на ядро это не влияет, ему указатель даже проще поменять, чем одну запись целиком.
>> Синтаксис иптаблес лучше
> Чем грузины? Или чем армяне?Чем синтаксис pf. Это же любому админу локалхоста сходу понятно.
> Иди отсюда, арчеребёнок. Синтаксис иптаблес лучшеАрче-ребенок :))) ? ахахаххахха
Вы уважаемый, его установить то сможете хоть ? пфхазхахахаха.
> У вас, видимо, браузер не отображает пробелы. Наверное, стоит написать багрепорт разработчикам.Будьте последовательны. Убрали тире - уберите и пробелы, чтоб читалось быстрее. :))
> Будьте последовательны. Убрали тире - уберите и пробелы, чтоб читалось быстрее. :))Будьте последовательны. Вам нравится, когда слова визуально разделены? Не ограничивайтесь тире и пробелами, разделяйте их как минимум переводами строки.
> Будьте последовательны. Вам нравится, когда слова визуально разделены? Не ограничивайтесь
> тире и пробелами, разделяйте их как минимум переводами строки.Будет Маяковский-style.
> Будьте последовательны. Убрали тире - уберите и пробелы, чтоб читалось быстрее. :))-А --ВЕДЬ --верно --говоришь -, --ДРУК -!
-С --ТИРЕ --текст --действительно --читается --гораздо --ЛУЧШЕ -.
--Теперь --БУДУ --всегда --только --так --ПИСАТЬ -.
-А --СИНТАКСИС --iptables --все --же --надо --ПОПРАВИТЬ -.
--Некоторые --ЛЕКСЕМЫ --там --идут --без --ТИРЕ -.
--Например -, --ИМЕНА --цепочек -, --таблиц -, -а --еще --адреса -и --ПОРТЫ -.
--Это --СИЛЬНО --ухудшает --ЧИТАЕМОСТЬ -.
Зато сильно уменьшает количество возможных ошибок при программирования разбора параметров командной строки.
зыж
А вот это выдаёт вас как профана с головой:
>--Некоторые --ЛЕКСЕМЫ --там --идут --без --ТИРЕ -.
>--Например -, --ИМЕНА --цепочек -имя цепочки — это аргумент параметра -A, -D, -I,…
С учётом вышесказанного, как бы всё равно удобно профанам читать или нет.
> имя цепочки — это аргумент параметра -A, -D, -I,…-В --ЭТОМ -- --то -и --проблема -!
--Аргументы --ВИЗУАЛЬНО --сливаются -с --параметром -, --что --значительно --ухудшает --читаемость --ТЕКСТА -!
Да, для секретарш не удобно, я ведь уже говорил?
Но для них командная строка не удобна вообще, в силу только своего существования.Что-то ещё?
> Да, для секретарш не удобно, я ведь уже говорил?--Не --ТОЛЬКО --для --СЕКРЕТАРШ -.
Конечно-конечно.
Есть КУЧА профессий. Бухгалтера например.
> Кому оно напрашивалось? Вот посмотрите на новый синтаксис с точки зрения эргономики
> - все сливается... не хватает разделителей (типа '-')... Трудно читабельно, и
> не похоже на стандартный синтаксис CLI.--Все --ПРАВИЛЬНО --ГОВОРИШЬ -!
-Я --ПРОСТО --не --понимаю -, --как --раньше --мог --читать --текст --без --тире --перед --каждым --СЛОВОМ -!
>-Я --ПРОСТО --не --понимаю -, --как --раньше --мог --читать --текст --без --тире --перед --каждым --СЛОВОМ -!Э… Может потому что ты не iptables?
>>-Я --ПРОСТО --не --понимаю
> Э… Может потому что ты не iptables?Вам точно не надоело ещё?
> получается
> nft add rule ip filter output ip daddr 1.2.3.4 tcp dport 80
> dropА как сделать перенаправление пакета в другую цепочку типа:
iptables -t filter -A OUTPUT -d 1.2.3.4 -p tcp -g newchain ?
Когда они планируют выбросить поддержку iptables?
Никогда?
Нет смысла держать дублирующие подсистемы, от одной из них откажутся рано или поздно.
Синтаксис правил просто фееричен.
не ну то что они решили сделать чтото лучше это хорошо... только вот за каким лешим делать синтаксис да не сложный и логический но блин сливавшийся в 1 целое в глазах... Лично мне больше нравится старый синтаксис... просто он реально наглядней
> не ну то что они решили сделать чтото лучше это хорошо... только
> вот за каким лешим делать синтаксис да не сложный и логический
> но блин сливавшийся в 1 целое в глазах... Лично мне больше
> нравится старый синтаксис... просто он реально нагляднейТак вот откуда берутся люди, которые через каждые несколько слов лепят многоточия!
Только сейчас понял :)
смайлофаг закукарекал
> смайлофаг закукарекалДа-да))) вот)) таким)))) товарищам)))) новый)) синтаксис)) тоже)))) не) понравится)))))))))))))))))))))))
>> смайлофаг закукарекал
> Да-да))) вот)) таким)))) товарищам)))) новый)) синтаксис)) тоже)))) не) понравится)))))))))))))))))))))))(зато (лисперы оценят))
> (зато (лисперы оценят))Это -- да, бо скобочки в паритете. А тот безглазый истерический мусор предлагаю вымести.
>> смайлофаг закукарекал
> Да-да))) вот)) таким)))) товарищам)))) новый)) синтаксис)) тоже)))) не) понравится)))))))))))))))))))))))Вот смотрю я на вас и видится мне что тут 90% троллей, которым лишь бы других в тупизне обвинить, не важно в чем, главное доказать что их точка зрения не верна, а верна ваша.
А из аргументов только - зубоскальство.
Видимо это единственный известный автору знак препинания. Вот он и натыкал его побольше, чтобы не подумали, что он безграмотный.
> Видимо это единственный известный автору знак препинания. Вот он и натыкал его побольше, чтобы не подумали, что он безграмотный.Я раньше тоже так думал. А теперь понятно — ему просто нужно «визуально разделять слова»©.
интересно вот, планируется ли в нём поддержка фильтрации для заданных исполняемых файлов или их групп. А то 21й век идёт, а нет до сих пор нормальной реализации этого. То, что через SELinux делается - как-то костыльно. AppArmor-цы - обещают ток в 3й версии начать поддерживать подобное.
эм а с этого места можно поподробней...
ну типа разрешил в фаерволе ц:\\свалка програм\\опись\\ворд.exe, запустил… и вирусы полезли.зыж
хинт:
# mv /usr/bin/proga /usr/bin/proga.orig
# cat > /usr/bin/proga
iptables -A OUTPUT… <разрешаем чё надыть>
<ещё может чё надо>
/usr/bin/proga.orig
Ctrl-D
#
усё, 21 век наступил.
> усё, 21 век наступил.И шо, +x не надо и от юзера заработает? :)
Ну да, и его тоже.
> хинт:
> # mv /usr/bin/proga /usr/bin/proga.orig# mv /usr/bin/true /usr/bin/true.orig
mv: cannot move '/usr/bin/true' to '/usr/bin/true.orig': Permission denied> # cat > /usr/bin/true
zsh: permission denied: /usr/bin/true
упс.
А у тебя /usr/bin/true в интернет лазит?!!
Поздравляю.
> А у тебя /usr/bin/true в интернет лазит?!!/usr/bin/proga у меня вообще отсутствует. (пожимает плечами) замени true на wget, разрешаю. посмею тебя удивить: результат не поменяется. всё равно скажет, что прав нет. я понимаю: для тех, кто работает под рутом, это очень удивительно и непривычно. а вам сколько раз повторяли: «не работай под рутом»? вы отчего не слушали умных людей?
Видишь ли, любой вменяемый админ сразу (практически интуитивно) догадывается, что если речь идёт о файле в /usr/bin, то требуются рутовые права.
В общем то, админ — он и есть рут.
Ну не дали тебе рута, так какие твои годы? И фаервол ты тоже не можешь настроить… ну, пока тебе рута таки не дадут. Так что и тема сабжа пока не для тебя.
Такова селяви.>а вам сколько раз повторяли: «не работай под рутом»? вы отчего не слушали умных людей?
Ну, это мы именно вам говорили.
И будем говорить.
> # mv /usr/bin/proga /usr/bin/proga.orig
> # cat > /usr/bin/proga
> iptables -A OUTPUT… <разрешаем чё надыть>
> <ещё может чё надо>
> /usr/bin/proga.orig
> Ctrl-D
> усё, 21 век наступил.и как это поможет запретить исходящие на заданный порт только для /usr/bin/proga.orig?
вам поможет (как обычно) документация знание предметной области:
вот база для размышлений:# useradd --shell /bin/false --no-create-home myappuser
# iptables -A OUTPUT -p tcp --dport 80 -m owner --uid-owner myappuser -j ACCEPT
# sudo -u myappuser /usr/bin/proga.origв 2.4 был --pid-owner, но эту опцию признали бессмысленной
запретить вообще сеть для приложения:
# unshare -n ping 127.0.0.1
connect: Network is unreachable
> # useradd --shell /bin/false --no-create-home myappuser
> # iptables -A OUTPUT -p tcp --dport 80 -m owner --uid-owner myappuser
> -j ACCEPT
> # sudo -u myappuser /usr/bin/proga.origДа, это не костыльная система, запускать все приложения от отдельного пользователя...
подход в SELinux и то лучше будет. Особенно красота начнётся, когда части приложений нужны будут X-ы (может wayland/mir/etc. эту проблему и решат, но всё же).Правильный подход к конфигурированию подсистемы, это когда для изменения одного из её параметров (например, запрета отправки пакета на заданный порт для заданного приложения) нужно добавить опцию только в одном месте.
> Да, это не костыльная система, запускать все приложения от отдельного пользователя…прикинь: не костыльная. тут ссылка проскакивала на slated, так вот ещё одна: http://slated.org/the_straw_that_broke_the_penguins_hat
процитирую оттуда пару фраз: «These technologies are «solutions» to entirely fictitious problems, and the former in particular is closely related to the same issues surrounding the PackageKit scandal. If unprivileged users are never given elevated privileges in the first place, then there simply isn't any need for mandatory access controls - standard UNIX security methods are sufficient.»просто рассматривай пользователей и группы как механизм для security.
> Правильный подход к конфигурированию подсистемы, это когда для изменения
> одного из её параметров (например, запрета отправки пакета на заданный порт
> для заданного приложения) нужно добавить опцию только в одном месте.ага. а тут мне вдруг захотелось странного: вот сейчас этой программе доступ дать (на один запуск). а вот той — не давать (на один запуск). что я делаю в случае использования вышеприведённого? запускаю «эту» программу от пользователя, которому можно, а «ту» — от пользователя, которому нельзя. а что я делаю, если «всё в одном месте»? правильно: сначала переконфигурирую систему, потом запускаю софты, потом опять переконфигурирую систему. очень удобно и очень защищено от ошибок (например, от ситуации, когда я забыл всё переконфигурировать назад «как было»).
проблема всяких MAC, отделённых от механизма user/group в том, что они тупо добавляют новую сущность вместо использования старых там, где это вполне вписывается в логику.
> ага. а тут мне вдруг захотелось странного: вот сейчас этой программе доступ
> дать (на один запуск). а вот той — не давать (на
> один запуск).
> ...а что я делаю, если «всё в одном месте»?так кто сказал, что нужно "iptables -m owner --uid-owner..." отменить?
Я за то, что нужно сюда же добавить возможность задания что-то вроде "iptables -m path /path/to/bin ...". В таком случае для реализации упомянутого "странного" желания можно так же задать пользователей, которым можно для данного приложения иметь доступ, и которым нельзя, используя "-m owner" совместно с "-m path".
> Я за то, что нужно сюда же добавить возможность задания что-то вроде
> «iptables -m path /path/to/bin …».«это было-было-было, но прошло» (ц) был cmd-owner, но работало, говорят, фигово и вообще как-то лишним торчало.
ну и да: это уже скорее задача user-mode firewall. я PoC делал (да и не только я, думаю) — для динамически слинкованых софтин, которые не дёргают ядро напрямую, конечно. особо большой пользы в этом не увидел, честно говоря, равно как и в моих примерах выше.
не знаю, как-то оказалось, что вполне хватает разделения по пользователям/группам. мне, честно говоря, лень сейчас искать, почему точно cmd-owner выкинули. может, кто неленивый за меня найдёт и ссылки сюда кинет.
> вот база для размышлений:IMNSHO для такого уже становятся удобней контейнеры, поскольку изолирование на ФС с изолированием по сети ходят под ручку.
> ну типа разрешил в фаерволе ц:\\свалка програм\\опись\\ворд.exe, запустил… и вирусы
> полезли.
> зыж
> хинт:
> # mv /usr/bin/proga /usr/bin/proga.orig
> # cat > /usr/bin/proga
> iptables -A OUTPUT… <разрешаем чё надыть>Не, лучше так:
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -Fи лучше не в /usr/bin/proga, а сразу в rc.local
// inspired by "service iptables panic" в старых редхатах
Я то же мечтать, хотеть быть правила на бинарник!
> интересно вот, планируется ли в нём поддержка фильтрации для заданных исполняемых файлов
> или их групп. А то 21й век идёт, а нет до
> сих пор нормальной реализации этого. То, что через SELinux делается -
> как-то костыльно. AppArmor-цы - обещают ток в 3й версии начать поддерживать
> подобное.Ожидайте, в следующую итерацию в Линукс украдут и ipfw.
> украдут и ipfw.и как же bsd будет без ipfw тогда?
> Ожидайте, в следующую итерацию в Линукс украдут и ipfw.А зачем Линуксу фаервол, имеющий проблемы с производительностью и масштабируемостью?
Самым первым фаерволом и linux и был ipfwadm, фактически переписанный ipfw.
Наконец-то можно закопать кучу костылей.
Копалка пока ещё пока не отросла.
Лихорадочно искал в новости строки:
>Представленный для ядра 3.13 код предусматривает сосуществование старой и новой подсистем, так как Nftables ещё требует доработки и тестирования.А то пришлось бы повременить с ядрами >=3.13.
Нет желания переписывать 100500 правил.
как раз у страуструпа начал читать про парсер с++ и там пример в книге, как раз про такой синтаксис. ну очень он не удобный, нежели линейные правила.
Читать ещё пол-беды.
А вот сформировать, потом ещё и проверить валидность (до факапа при самом уже выполнении) сложнее.
Не говоря о том, что это фактически свой собственный язык разметки, который тоже нужно будет знать.
Посмотрим, довольно интересно, человеческий набор правил радует.
Ну наконец то вливают наработки, эпохальное событие года 2 ждем уже.
>Ну наконец то вливают наработки, эпохальное событие года джва ждем уже.//исправил, не благодари
>table filter hook input priority 0;Точка с запятой в конце - обязательны? Чем объясняется, что в дальнейших правилах её нет?
>ct state established accept
>ct state related acceptА как раньше ct state established,related accept уже нельзя?
Точка с запятой в конце - обязательны? Чем объясняется, что в дальнейших правилах её нет?C синтаксис xD
> А как раньше ct state established,related accept уже нельзя?Да пожалуйста: ct state {established, related}
Это из оперы - "Чем грузины лучше" ;)
# iptables -t filter -A OUTPUT -d 1.2.3.4 -p tcp --dport 80 -j DROPи
# nft add rule ip filter output ip daddr 1.2.3.4 tcp dport 80 dropвторое правилу ну никак не наглядней, хоть с какой стороны на него смотреть
> # iptables -t filter -A OUTPUT -d 1.2.3.4 -p tcp --dport 80 -j DROP
> и
> # nft add rule ip filter output ip daddr 1.2.3.4 tcp dport 80 drop
> второе правилу ну никак не наглядней, хоть с какой стороны на него смотретьК 2113 году всё изменится! :D Глаза смотрящего точно.
>[оверквотинг удален]
> # iptables -t filter -A OUTPUT -d 1.2.3.4 -p tcp --dport 80
> -j DROP
>
а вот интересно, такая перестановка в новом варианте заработает:
# iptables -d 1.2.3.4 -t filter -p tcp -A OUTPUT --dport 80 -j DROP
и
# nft daddr 1.2.3.4 ip tcp add rule ip filter output dport 80 drop
???
хуже, когда будет так:
# nft daddr 1.2.3.4 ip tcp add ip rule filter dport output 80 drop
и сразу в глаза не бросается, т.к. не понятно где параметр, а где его атрибут.
> # nft daddr 1.2.3.4 ip tcp add rule ip filter output dport 80 dropНет, это не заработает. daddr и saddr - уточняющие субселекторы селектора ip. А dport - уточняющий параметр субселектора tcp. И т.д.
Синтаксис nft подчиняется правилам, алогичным человеческой речи. А в ней тоже нельзя произвольно смешивать слова.
И ничему-то их SQL не научил... Тоже пытались сделать a-la человеческая речь.
> И ничему-то их SQL не научил… Тоже пытались сделать a-la человеческая речь.и верно. то ли дело какое-нибудь @#%^%@#%. или вон как у sendmail — образец удобства и понятности.
Ну так переборщить что угодно можно. Не пойму, чем тебя так смущает желание видеть явные отличия имен параметров от значений?
человек не понимает разницу между параметрами программы и фронт-эндом по настройке этих параметров.зыж
штоб править ему всю жизнь его виндовый (и бинарный) реестр хекс-эдитором! :D
> Ну так переборщить что угодно можно. Не пойму, чем тебя так смущает
> желание видеть явные отличия имен параметров от значений?потому что это совсем не обязательно при правильном построении грамматики. ты же не ставишь, например, дефис перед глаголами, снежинку перед прилагательными и плюс перед существительными? тем не менее, грамотно составленые предложения вполне читаются. без лишнего визуального мусора.
1. Абзацы, оглавления и т.д. не от хорошей жизни придумали.
2. Даже в белитристике сплошным текстом не пишут.
3. Фронт-энды удобством для пользователей должны заниматься.
Ну ты сравнил. Сколько усилий надо приложить, чтобы естественным языком овладеть?
> Ну ты сравнил. Сколько усилий надо приложить, чтобы естественным языком овладеть?я не сравнил, я намекнул, что даже несоизмеримо более сложные грамматики обходятся почти без лишней фигни.
> Ну так переборщить что угодно можно. Не пойму, чем тебя так смущает
> желание видеть явные отличия имен параметров от значений?Потому что эти "ясные" отличия де-факто являются визуальным мусором и только ухудшают читабельность.
В нормальной человеческой грамматике (например, русской и английской) их нет, что не мешает нам общаться.
В вашем комментарии есть и ".", и ",", и "(", и """, и "-".
Так что не нужно "заливать" про "визуальный мусор".
Мусор — это когда текст идёт "сплошняком", как в сабже. Где не понятно где параметр, а где его атрибут. И быстро вычленить в большом объёме правил это точно визуально не получиться.
> И ничему-то их SQL не научил... Тоже пытались сделать a-la человеческая речь.Ну расскажите нам о проблемах тысяч админов из-за синтаксиса (именно синтаксиса, а не архитектуры или внутренней реализации) pf и ipfw.
Когда будет этих правил пару тысяч, тогда поймете разницу.
это точно.
тогда выделение атрибутов от их параметров играет не малую роль.
>[оверквотинг удален]
> # iptables -t filter -A OUTPUT -d 1.2.3.4 -p tcp --dport 80
> -j DROP
>
> и
>
> # nft add rule ip filter output ip daddr 1.2.3.4 tcp dport
> 80 drop
>
> второе правилу ну никак не наглядней, хоть с какой стороны на него
> смотретьЕжишь петручио !!! а если мне нужно не "-d" а "-s"
как в этом вашем nft это указать ?
Я вижу строку ip daddr 1.2.3.4
Из которой не ясно - это адрес назначения или адрес источника, бывают ситуации, когда в цепочке OUTPUT нужно обрабатывать траффик по адресу источника.
Как будет на языке nft правило вида:
iptables -t filter -A OUTPUT -s 1.2.3.4 -p tcp --dport 80 ?
>>[оверквотинг удален]
> Как будет на языке nft правило вида:
> iptables -t filter -A OUTPUT -s 1.2.3.4 -p tcp --dport 80 ?Очевидно,
nft saddr 1.2.3.4 ip tcp add rule ip filter output dport 80 ...НО! То, что аргументы и параметры сливаются в одну кучу, никаким образом между собой ни визуально, ни логически не различимы - это очень плохо. Например, в случае синтаксиса iptables я спокойно могу называть цепочку любым нужным мне для словом (напр. "tcp", "udp", "ip", "rule", "add", "dport" etc). В случае же nft придется подбирать названия цепочек специально, чтобы они не пересекались с названиями параметров - это следствие отступления от POSIX, и это печально, что молодые горячие программисты ну никак не хотят учитывать опыт хождения по граблям старших коллег, им обязательно нужно самим получить по голове для остроты ощущений :(
> "dport" etc). В случае же nft придется подбирать названия цепочек специальноЯ вас умоляю, сделаете темплейты. Можно подумать серьезная конфигурация iptable без них обходится.
> НО! То, что аргументы и параметры сливаются в одну кучу, никаким образом
> между собой ни визуально, ни логически не различимы - это очень
> плохо. Например, в случае синтаксиса iptables я спокойно могу называть цепочку
> любым нужным мне для словом (напр. "tcp", "udp", "ip", "rule", "add",
> "dport" etc). В случае же nft придется подбирать названия цепочек специально,
> чтобы они не пересекались с названиями параметровС чего вы взяли? Такое ограничение пришлось бы вводить только в случае разрешенного хаотического перемешивания параметров и аргументов. Но оно же не разрешено.
походу вот так
nft add rule ip filter output ip saddr 1.2.3.4 tcp dport
Хмм... Поцтерингом попахивает!
Какие дебильные и длинные цепочки правил... Нет, чтобы доработать существующий iptables, они начинают пилить новый, ему замену с более убогим и неудобным синтаксисом, это пять!..
правила чем-то ferm напоминают.
Вообще, не знаю есть ли такое, но хотелось бы видеть что то вроде функционального языка программирования фаервола. Что бы ты написалmain(packet){
if(packet.port == 80 && packet.elf = "myrestrictedelfprogram"){
return null;
}}
Транслятор это дело в байткод прокинул и отправил я ядро. Судя по всему от этого нового нетфильтра до идеи парсить произвольный код в байткод фильтра, рукой подать. Что то типа llvm для пакетного фильтра, где фронтенд на произвольном языке, бекенд на байткоде. Что бы правила были совсем гибкими, честно сказать не люблю идею таблиц как таковую.
> Вообще, не знаю есть ли такое, но хотелось бы видеть что то
> вроде функционального языка программирования фаервола. Что бы ты написал
> main(packet){
> if(packet.port == 80 && packet.elf = "myrestrictedelfprogram"){
> return null;
> }
> }Много букаф слишком, нет?
Ну дак for, switch, while в руки и вперед. Просто взять скриптовый язык и прикрутить бекендом фаервол работающий с байткодом. Написать сотню правил и генератор правил к ним сложнее чем написать один цикл. Должно быть наоборот меньше букаф, да к тому же намного читабельнее, что немаловажно.А сколько туда накрутить таким методом можно всяких других фич, которые к таблицам ни боком ни раком, даже предположить трудно.
> Ну дак for, switch, while в руки и вперед. Просто взять скриптовый
> язык и прикрутить бекендом фаервол работающий с байткодом. Написать сотню правил
> и генератор правил к ним сложнее чем написать один цикл. Должно
> быть наоборот меньше букаф, да к тому же намного читабельнее, что
> немаловажно.
> А сколько туда накрутить таким методом можно всяких других фич, которые к
> таблицам ни боком ни раком, даже предположить трудно.Так то канеш красиво получается и не надо читать кучу манов, если синтаксис СИ-подобный. Но с другой стороны простейшие правила: permit host 192.168.0.1 потребуют больше текста. Мне кажется было бы классно совместить оба варианта.
Ну, текущую инфраструктуру все равно оставить можно, конечно, она живая и никому не мешает. Вот только мои тут "идеи" все равно разрабы ядра не слышат :) Между тем в других системах lua потихоньку встраивают...прогресс идет, пока прохожие плеваются :)
Главное, это дает резкое упрощение разработки для ядра, прототипирования, да и просто универсалный интерфейс к системам ядра. Меньше манов. Отсюда, думаю, взрывной рост разработки для ядра на скрипте, а потом перенос в С/С++ готовых продуктов для продакшена. В общем со всех сторон польза. Причем даже обычный юзер вроде меня сможет поковырять разработку для ядра на досуге.
> Главное, это дает резкое упрощение разработки для ядра, прототипирования, да и просто
> универсалный интерфейс к системам ядра. Меньше манов. Отсюда, думаю, взрывной рост
> разработки для ядра на скрипте, а потом перенос в С/С++ готовых
> продуктов для продакшена. В общем со всех сторон польза. Причем даже
> обычный юзер вроде меня сможет поковырять разработку для ядра на досуге.Кстати да, всякие DPI легче разрабатывать, наверное )
Шутки у вас :)
Но, сейчас документация на системы и конфиги систем ядра, огромна, а универсальный интерфейс по типу этого, ее резко уменьшит, что по моему приятно. Хоть не придется учить бесконечные новые синтаксиы конфигов нетфильтра.
Ведь как ни крути, а любому нетфильтру оперировать типом-классом packet, так что и синтаксис будет одинаков, что для одного нетфильтра, что для другого, в рамках такого скрипта. Отсюда уменьшение бесконечной головной боли. Так же и для других систем. В общем скрипты потому и придумали :)
> Ведь как ни крути, а любому нетфильтру оперировать типом-классом packet, так что
> и синтаксис будет одинаков, что для одного нетфильтра, что для другого,
> в рамках такого скрипта. Отсюда уменьшение бесконечной головной боли. Так же
> и для других систем. В общем скрипты потому и придумали :)java головного мозгу, вам термин overengineering поди не знаком?
Ну вы там это, учите новые правила нетфильтра, флаг в руки :) А потом снова и снова, это особый кайф я погляжу и никакого овер, да.
Унификация средств конфигурирования и простого расширения подсистем ядра отделит мечтательные мозги разрабов очередного нетфильтра от стандарта конфигурирования. Что даст возможность конфигурить любой сервис одним средством и создавать собственные сервисы поверх нескольких сервисов ядра. По моему удобно.
http://www.netbsd.org/gallery/presentations/mbalmer/fosdem20...
сложнейшую маршрутизацию и прочее все туда же. А сервисы ядра подключать как библиотеки языка. Типа если надо конфигурять нетфильтр, такая либа, если надо еще что то, такая. Унифицированный подход имеем таким образом.
Причем так как язык очень высокоуровневый надо, то выделений памяти, буферов и прочей муйни, нету. Подключив "либу" к проекту скриптового конфига ты подключаешь входной поток данных (пакеты для нетфильтра например) и встраиваешь проект в инфраструктуру подключенной "либы", то есть она начинает слушать твой выходной поток данных. Так что минимум лишних телодвижений. Потом байткод попадает в ядро и пашет как отдельный кусок конфигуряемой системы.Потом добавить туда JIT коНпелятор и счастье наступило :)
>А сервисы ядра подключать как библиотеки языка. Типа если надо конфигурять нетфильтр, такая либа,Не поверишь.
Называются модули ядра.
Подключать не к ядру, а к скрипту.
Когда коту делать нечего, он яйца лижет, а программисты разрабатывают принципиально новый wayland/gnome3/systemd/nftables/gtk3/clang и т.д.И в каждой такой новости мы видим рассказы, как предшественник устарел, плох, не безопасен и т.д. Ужас да и только. И как только линукс взлетел со всем этим?
> И как только линукс взлетел со всем этим?Дык 1% же, невысоко взлетел. Оказывается, это было из-за устаревшего iptables, но теперь-то жизнь наладится!
Рано ей налаживаться - вот впилят в каждый дистрибутив wayland(мы ведь все знаем, что в X11 даже не один фатальный недостаток нашли, а тысячи их!) в дополнение к systemd, вот тут-то и нагрянет вендокаец, а линукс захватит все 146%!
> вот тут-то и нагрянет вендокаец, а линукс захватит все 146%!Судя по тому как интел въе над линуксом начал - это не просто так.
> Дык 1% же, невысоко взлетел.Ну да, а вон те 50% серверов, 50% планшеток, 80% смартов, 90% суперкомпьютеров, почти 100% роутеров и прочей умной электроники мы проигнорируем. Ведь неудобно же замечать такие факты.
Для всех хейтеров на заметку: для nftables подготовлена прослойка, которая полностью совместима с ip/ip6/arp/eb tables на уровне синтаксиса команд и интерфейса extensions. Т.о. можно не переучиваться. Во-вторых, все эти ваши экстеншены можно использовать из-под nftables без переделки. Ну и плюс новые плюшки, типа уже встроенных таблиц для хранения наборов данных, маппинга (а-ля tablearg), более дружелюбный к СМП "движок" с минимумом локов, избавление от ненужных дёрганий (не используете хук, так и система не будет проверять пустую цепочку), ну и по мелочи. Концептуально всё это очень похоже на ОпенБСДшный NPF, который чуть позже вышел, но был быстрее интегрирован в систему. Как-то так.
Только он не в ОпенБСД, а в НетБСД: http://www.netbsd.org/~rmind/npf/И действительно, они как близнецы-братья.
Да сама фишка хорошая, синтаксис безумный. Правила ж не надо читать, их надо сканировать, быстро разбирая на составные части. Синтаксис iptables это отлично даёт со своими минусами. А здесь - глазу зацепиться не за что. То есть там нужно тебе -s - ты его и ищешь, и сразу видишь. А sport среди других слов не выделяется никак.
> Правила ж не надо читать, их надо сканировать, быстро разбирая на составные части.слушай, переложи уже работу фильтрации пакетов на машину. ну трудно же тебе каждый пакет ручками обрабатывать, упорно читая правила. надорвёшься.
для идиoтиков, тут про фильтрацию правил, а не пакетов.
переложить это можно только на более компетентного админа. в твоём — случае практически на любого другого человека. но не на машину.
о, ещё один представитель племени пишущих правила в бессознательном состоянии. сначала оно сидит на винде и ставит варез из помоек, потом перелазит на бубунту и… всё равно ставит варез из помоек. и думает, что проблему его безмозглости можно решить программно.
эт точно! :D
arizu one:
>слушай, переложи уже работу фильтрации пакетов на машину.arizu two:
>и думает, что проблему его безмозглости можно решить программно.да, вот так вы и живёте. хорошо хоть признаёшь свою ущербность. :D
а нам вот всё самим да самим правила писать приходится.
Хочешь сказать, что никогда пачку правил не смотрел глазами чтобы понять, что там подправить надо?
> Хочешь сказать, что никогда пачку правил не смотрел глазами чтобы понять, что
> там подправить надо?хочу сказать, что рапарзивать «$#%$^@^» шибко сложнее, чем слова: я именно поэтому и взял ferm. и здесь я вижу правила, похожие на ferm'овые. читаются без проблем. в отличие от однобуквенных аргументов.
мозг вообще читает фразы, составленые из слов, намного лучше, чем фразы, составленые из букв и закорючек. кто не верит — может попробовать прочесть какое-нибудь длинное регулярное выражение.
Ну так речь же не о том, чтобы сплошные значки были. Но вот эти sport/dport явно менее заметны, чем -s/-d. И -j, опять же, позволяет быстрее понять, где начинается rule target, если он с параметром (если без - тупо читаем последнее слово, конечно).Короче, ладно, разница в восприятии.
> вот эти sport/dport явно менее заметны, чем -s/-dПрочтя в черноморской вечерке объявление «Сд. пр. ком. в уд. в. н. м. од. ин. хол.» и мигом сообразив, что объявление это означает — «Сдается прекрасная комната со всеми удобствами и видом на море одинокому интеллигентному холостяку»…
> Да сама фишка хорошая, синтаксис безумный. Правила ж не надо читать, их
> надо сканировать, быстро разбирая на составные части. Синтаксис iptables это отлично
> даёт со своими минусами. А здесь - глазу зацепиться не за
> что. То есть там нужно тебе -s - ты его и
> ищешь, и сразу видишь. А sport среди других слов не выделяется
> никак.Синтаксис вашей речи не позволяет ее парсить, извините.
Пожалуйста, ставьте минусы перед каждым словом.
Еще один. Разницу между атрибутом и параметром понимаем? Hint: почему в SQL принято ключевые слова писать большими буквами, а имена полей/таблиц - малыми?
> Еще один. Разницу между атрибутом и параметром понимаем? Hint: почему в SQL
> принято ключевые слова писать большими буквами, а имена полей/таблиц - малыми?Наследие IBM System/360 и VAX/VMS, Фортранщеги ваще капслок гвоздём прибивают.
взаимоинтеграция
линукс на бздю и наоборот
дополнительный фактор развития
когда количество сущностей увеличивается, это не всегда баг системы
Документация представлена в виде коротко "How to" ?
вот и переписали ferm на C
не то, чтобы это тянет на файрвол, но хоть какая-то движуха, изменения/инновации.
но увы, для усложнения байпаса файрвола - прийдется сторонние "костыли" юзать вроде Zorp. два почти доведенных до ума, надежных файрвола - отпинали из Линукс, уже, к сожалению. а netfilter/iptables больше на анекдот похож. в роутере нормально(иногда;) а вот узлы и бордеры требуют мало-мальски, защиты, однако )
> не то, чтобы это тянет на файрвол, но хоть какая-то движуха, изменения/инновации.
> но увы, для усложнения байпаса файрвола - прийдется сторонние "костыли" юзать вроде
> Zorp. два почти доведенных до ума, надежных файрвола - отпинали из
> Линукс, уже, к сожалению. а netfilter/iptables больше на анекдот похож. в
> роутере нормально(иногда;) а вот узлы и бордеры требуют мало-мальски, защиты, однако
> )Ниасилил? А как должен выглядеть фаерволл? Выскакивать окошко и раздаваться звук раздавленной крысы?
DPI ему не хватает. начальство, видимо, приказало.
> DPI ему не хватает. начальство, видимо, приказало.Тогда ему не хватает не DPI а мозгов и квалификации.
>> не то, чтобы это тянет на файрвол, но хоть какая-то движуха, изменения/инновации.
>> но увы, для усложнения байпаса файрвола - прийдется сторонние "костыли" юзать вроде
>> Zorp. два почти доведенных до ума, надежных файрвола - отпинали из
>> Линукс, уже, к сожалению. а netfilter/iptables больше на анекдот похож. в
>> роутере нормально(иногда;) а вот узлы и бордеры требуют мало-мальски, защиты, однако
>> )
> Ниасилил? А как должен выглядеть фаерволл? Выскакивать окошко и раздаваться звук раздавленной
> крысы?не позволять себя обходить, для начала. ну а в идеале - написаным головой а не ж.
в крайнем случае - руками :)p.s.
про "выскакивать и звук крысы" порадовало, спасибо. напомнило один смешной продукт на оффтопике от Касперского )
> не позволять себя обходить, для начала.https://bugzilla.netfilter.org/
> конечного автомата (pseudo-state machine)точно не finite state machine?
Тут установка https://home.regit.org/netfilter-en/nftables-quick-howto/